stdray: (Default)
Хотел в заголовок поставить слово "микросервисы", но все же не про них речь.

Дело такое. Есть у меня сервис, обеспечивающий первые 2 этапа ETL-процесса: загрузка сырых данных с источников и трансформаця их в каноничный внутренний формат. Этот формат потом жрет платная сложная тула, которая раскидывает из него данные по табличкам детального слоя, data vault и всё такое.

Сервис представляет из себя планировщик quartz, в который пихаются задачи на загрузку и трансформацию. При этом с одного источникам мы можем загружать разные документы, и, скорей всего, это будут разные процессы. В простейшем случае (всего один тип документа и один "реестр") имеем 2 джоба (загрузка и трансформация), в сложном - 2-3 десятка. Есть еще такой момент, что может существовать одна реализация YobaLoaderJob, которая в конфигах тиражируется на 12 задач с разными параметрами.

С точки зрения кода, если отбросить весь common и utility код, имеем ОДНУ библиотеку, где по папочкам разложены реализации всего этого зверинца. В целом, это было достаточно удобно:
- простая и понятная структура проектов (хост, реализация, тесты)
- элементарное добавление нового источника (запилил реализацию, накалякал тестов, занес задачи в конфиг планировщика нужного контура и погнали)
- удобный рефакторинг (с точки зрения унификации - все рядышком, посмотрел, подумал, обобщил; с точки зрения правок базовых классов - всё, что можно сломать, лежит в этом же проекте)
- легкий деплой (один раз настроил сценарий разворачивания хоста и всё)

К сожалению, минусы стали такими жирными, что теперь каждый новый источник делает меня грустить. А именно:
1. правка одного источника приводит к необходимости рестартовать все (аналогично, если надо отключить один конкретный процесс)
2. библиотека с реализациями обросла диким количеством зависимостей, а ее выхлоп весит много мегабайтов
3. когда хост запущен, он штатно жрет память в пределах 8-14 Гб, что сильно осложняет снятие и исследование дампов
4. когда какие-то процессы штатно не реагируют на сигнал завершения работы (сервис не тормозит ни за 2, ни за 5, ни за 15 минут) очень трудной найти причину (см. п3)
5. примитивные мониторинги (состояние сервиса, его потребление ресурсов) становятся абсолютно бесполезны, поскольку на фоне больших и ресурсоемких источников мелкие не видны
6. все задачи кроме своего штатного расписания имеют триггер "выполниться при запуске", что реально нагибает базу, из-за чего треть процессов получает отлуп и логи краснеют
7. долгий цикл CI/CD (для одного контура оно строится 3-4 минуты, примерно столько же идут тесты, еще 3-10 минут уходит на деплой). Итого, между запуском билда и наблюдаемой активностью проходит минут 10 минимум.

Логично, что всё это дело надо распилить, но у меня нет четкого понимания, как это сделать, чтобы не усложнять разработку. Как организовать структуру проектов и как правильно выбрать гранулярность. То есть, можно представить вот такую шкалу, на какое количество логики надо создавать отдельный сервис:
1. один для всех (текущий вариант)
2. один на источник
3. один на группу зависимостей (идея примерно такая: все джобы которые, к примеру, ходят на ftp, наследуют один класс ведут себя одинаково и им не нужен остальной хлам)
4. один на каждый джоб (другая крайность)
* п2 и п3 могут только чуть облегчить боль, но проблему они не решают


Понятно, что хотелось бы иметь п2 ОДИН ХОСТ НА КАЖДЫЙ ДЖОБ. Но как этого добиться?

По поводу сценариев сборки и развертывания я беспокоюсь мало, в худшем случае всегда можно на коленке собрать "сервер приложений", который будет мониторить папки, находить изменения, стопарить процесс и запускать с новыми сырцами. Это просто. Написать билд, который что-то соберет по определенным паттернам названий проектов еще проще.

Но я не понимаю, как это организовать в коде. Я уже выше писал, одна имплементация может иметь несколько инстансов в конфиге. И так выходит, что у меня 350+ джобов, и на каждый на выходе должен получиться типо отдельный запускаемый бинарник? Очень стремно. На каждую реализацию делать по одному проекту, прикладывать туда все необходимые конфиги, а сервер приложений из них запустит по отдельному хосту?


Я в растерянности. Не знаю, акторы-хуякторы и прочие трендовые микросервисы не помогают.
Может, у кого есть подобный опыт? Ну или соображения на этот счет?

Code review

Jun. 8th, 2017 04:27 am
stdray: (Default)
Регулярно читаю в твитттуре, что мол парни, чей код просматривают, неадекватно реагируют на критику. Ну или не только парни, может и девушки, но этот нюанс не раскрыт. И все эти росказни сводятся к тому, что люди типо реально начинают переживать. Дальше идет пояснение, что не надо воспринимать критику своего кода на свой счет. Дескать, ты не тупой мудак, просто код твой - говно. А затем разворачивается не сильно большая, не особо маленька, а такая, прямо в меру, дискуссия, как же правильно ревьюить чужой код. Набегают профессионалы самых разных высот квалификации, высказывают авторитетные мнения, которые начинают интерферировать. Ну это же понятно, что анскилед лелкам в твитторг путь заказан, потому там только ревьюверы сидят, а не ревьювируемые. И какбэ все хорошие ревьюверы хороши одинаково, а вот ревьювируемые мудаки - мудаки по своему.

ревью - это просто праздник какой-то )
stdray: (Default)
ну ты же робот ёбана

А кто-то пытался на основе лога обычного чата построить некое подобие древовидного форума?

Я к тому, что у нас же тут развиваются лингвистические продукты, машинное обучение, в том смысле, что изначально древовидных форумов хватает, и есть за счет чего добивать эвристики.

Очевидные эвристики: обращения к конкретному нику, цитирования части сообщения, использования редко встречающихся слов (с точностью до N-го расстояния Левенштейна), скоростной постинг одним юзером нескольких сообщений подряд (скорей всего они должны составлять единое целое), разбивки по приветствиям, разбору содержимого линков (опять же в поиск редких слов) и тд и тп.

Понятно, что в первом приближении это не очень полезно и удобно, но должны же быть какие-то наработки. Ведь никто не вычитывает чаты дальше N-го сообщения с конца, НО увиденные обрывки обсуждений могут быть интригующими.

Интересен еще такой момент. Предположим, у нас есть такая система. А мы ее натравливаем на обычный пост в ЖЖ, где каждое предложение ОПа трактуем, как отдельно сообщение в чате. И тогда для нытико-технического поста вида "Вот мой опыт, что дураки-идиоты, так сяк робят плохо. А я туда-сюда с {technology_name} стою в белом пальто" чудо-технология сможет побить дискуссию на {technology_name} и сочувствующих "а у меня инитакоебыла" с прочими технофелософами.

Так где?
stdray: (Default)
Как писали в твитторе, в интересные времена живем:
- Microsoft без лишней скромности вкатился в Linux Foundation
- Заманил Google в .NET Foundation, который запиливает подержку дотнета для своего облака
- Показал Visual Studio для маководов. Студия уже приветствует неофитов
- Выложил для проб SQL Server, который v.Next, который можно пускать на линунксах
- Бомпанул Слек
- Сообщил, что Samsung отвлекся от производства взрывчатки, и опубликовал .NET SDK для Tizen
- Обратил внимание на проекты сообщества, такие как BenchmarkDotNet и NancyFX, приняв их в .NET Foundation
- Довел ASP.NET Core до такого состояния, что мы можем увидеть дотнет во всем известном некорректном бенчмарке


MS, правда, как я понял, прикончил WinPhone. Зато запустил совершенно непонятную мне ёбу. С другой стороны, пишут, что всё правильно MS делает




Сможешь ли ты совладать с ним?
stdray: (Default)


Хочу написать парсер поисковых запросов. Набор возможных операций мал: "и", "или", "не", группировка скобками (изменение приоритета), группировка кавычками1 (фразовый поиск), группировка кавычками2 (точное совпадение), пробел/табуляция/что-то еще - разделитель (он же implicit "и"), перевод строки - разделитель (он же implicit "или"), escape-символ (возможно, это будет '\').

Сложным мне представляется обработка ошибок. Пользователи будут вводить любую ерунду и удивляться любому поведению. Тут политика партии ещё не ясна: либо будем сыпать ошибки, либо достраивать до корректного запроса, либо и то и другое. Сыпать ошибки придётся, инфа под сотню, а значит они должны быть разумными и понятными. Это, как я понимаю, отсекает возможность применения парсер-комбинаторов и генераторов (TDOP, PEG, EBNF и прочих).

Выходит, что мне нужно ручками, кровью и потом писать лексер, выписывая автомат (регулярки не помогут) и все его состояния. Потом руками ходить по порожденной лексером коллекции токенов, с целью починить или внятно поругаться. И, наконец, руками же написать автомат парсера.

Что-то выглядит очень громоздко и скучно. Может, чего не знаю и есть короткий путь? Или, может, кто из вас видел красивые и компактные реализации чего-то подобного? В общем, я достаточно далек от разбора текста и надеюсь на любую помощь.


ЗЫ: зря я не читал дракона, да?

REPL LEL

Mar. 15th, 2016 06:04 am
stdray: (Default)



Достаточно занятная тема, которую я обычно избегаю, ибо синдром утёнка, начинал сразу с C в IDE (тогда в borland c++ 3.1). Но вот вчера внезапно выслушал монолог о том, как REPL ускоряет разработку. Знакомо, ведь я тоже радовался так когда-то. А потом всё встает на свои места.

Похоже, что радоваться REPL'у могут либо измученные тяжелой инфраструктурой программисты, которые устали создавать ConsoleApplication1488, чтобы проверить какую-нибудь ерунду, либо ребята, у которых вообще ничего нет.

Read more... )

Про api

Mar. 10th, 2016 01:17 am
stdray: (Default)



Регулярно всплывает тема запиливания хорошего годного интерфейса к ентим нашим оперденям. И все глубокомысленно отвечают, что вопрос давно решен, и REST API - наше все. А потом все столь же глубокомысленно кивают, мол всё так, всё так. Хотя по факту имеем набор нечетких рекомендаций вида:
- http в качестве транспорта
- json в качестве данных
- url в качестве идентификаторов сущностей
- http verbs в качестве действий.

Это ответ на вопрос? Я считаю, что это лел. Это как в известной песне: "Думайте сами, решайте сами". Если у вас нет обещаний, то и некому их нарушать.

Read more... )
stdray: (pic#896193)
Написал, точнее переписал (процесс продолжается) весь слой загрузки данных из внешних стрёмных источников. Переписал не из чувства прекрасного, а по следующим причинам:
1. целиком и полностью изменилось внутренне представление данных
2. невозможно поддерживать существующий код
3. невозможно анализировать работу существующих процессов загрузки

Я с некоторых пор не любитель писать с нуля, но здесь вынужденно во все тяжкие. И если с первым пунктом все понятно, то про два других подробней. Это про то, почему «написал», а не «переписал». )
stdray: (Default)
Часто слышу от своих знакомых, программирующих на C# и использующих ReSharper, что едва ли не самой полезной возможностью решарпера является проверка стиля кодирования. То есть решарпер проверяет правильность именования переменных, всякие там Pascal Casing для имен типов, Camel Casing для переменных и прочее такое. В этом есть смысл, поскольку многие программисты style guide не читают, а я читал, но почти ничего не помню. И тоже полагаюсь на ReSharper, хоть и регулярно возникают с ним разногласия.

А вот для Nemerle никакого решарпера нет, более того, нет никакого style guide. Размышляя над этим по дороге, я пришел к выводу, что второе существенно, а первое - не очень. Поскольку многое можно сделать на макросах. Например, захотел я удостовериться, что названия всех типов начинаются с большой буквы. Да еще чтоб я мог выбирать, что делать с несоответствием: выдавать ошибку компиляции, предупреждение или просто проинформировать. Несложно. Для этого надо лишь объявить макрос-атрибут уровня сборки

[MacroUsage(MacroPhase.BeforeInheritance, MacroTargets.Assembly)] \

macro CapitalTypeNames(alertType : string)

NameConventionImpl.CapitalTypeNames(Macros.Manager(), alertType)


А при его вызове, собрать типы, объявленные в сборке, отфильтровать имеющие некорректные названия и вывести информацию указанным образом. Read more... )
stdray: (Default)
В комментариях к энторпрайз БАЙСИКУ proofit404 дал линк на свой пост, где рассказывает, про негативный опыт со средами разработки для Haskell, ну и предлагает выпилить люк, создав хитрющую прослойку между редакторами и конпелятором.

Я так полагаю, дело вовсе и не в редакторе и не в способах хранения цветов и автокомлитов каких. Если говорить о компилируемых языках программирования, то никто не может знать о программе больше чем сам компилятор. И вопрос упирается в то, проектировался ли компилятор с учетом работы в режиме IDE или нет. Если да, то написание качественной интеграции большая, но понятная задача. Надо лишь выбрать IDE, изучить документацию и нарисовать плагин, который просто будет заниматься вызовами API компилятора и среды разработки.

При этом "проектировался" означает не только умение принимать / возвращать какие-то данные, но и работать в разных режимах. Потому как шевелиться все это должно достаточно быстро, а если какой-нибудь компилятор Haskell сначала начнет типизировать 100500 файлов проекта, потом займется оптимизацией, позвав на помощь LLVM-бекенд, то ничего хорошего из этого точно не получиться. Выходит, что в режиме IDE ему нужно лишь распарсить и типизировать AST, опуская непосредственную компиляцию, или компилируя без оптимизаций, если редактируемый проект у кого-то в зависимостях и есть потребность в метаинформации сборки (для языков по типу C#). Если язык имеет макроподсистему, то информацию о режиме работы компилятора надо пихать и туда. Также не считаю, что возможно реализовать какой-то stateless протокол обмена между компилятором и IDE, сделав компилятор сервисом или вроде того, поскольку работы у него действительно много. И если при каждом изменение текста гнать ему все файлы проекта для обработки - все будет весьма печально. Потому компилятору нужен стейт, чтобы иметь возможность кешировать результаты своей работы.
Read more... )
stdray: (Default)
Пока в сети продолжаются споры от том нужны DSL или не очень, я решил разобраться, как на макросах Nemerle реализуются встраиваемые языки. Потребность такая может возникнуть, даже при наличии макросов, расширяющих синтаксис языка. Дело в том, что менять правила лексера и препарсера нельзя, а значит определенные последовательности символов будут невалидными, например непарные скобки, хотя я подозреваю, что ими ограничения не исчерпываются. Для выхода из ситуации используются рекурсивные строки, внутри которых пишется код на интересующем языке, а потом транслируется в AST Nemerle. Подобным образом реализованы xml-литералы и linq query syntax.

Я был уверен, что создание подобных макросов является очень сильным колдунством. Но на практике все оказалось достаточно просто. Правда есть некоторые нюансы, которым надо уделить внимания. Я расскажу, как сделать игрушечную реализацию BASIC'а.


Реализация МИКРОБЕЙСИКА )
stdray: (Default)
Бывает, ради эксперимента пишу какие-то макросы, чтобы разобраться что позволяет макро-подсистема Nemerle, а что - нет. Если будет получаться что-то забавное, стану выкладывать это сюда.


Расширяемые анонимные типы

По мотивам хотелок [personal profile] metaclass. На сколько я понял, ему нужны анонимные типы, которые можно расширять, добавляя новые элементы, а также передавать за пределы той области видимости, в которой они были объявлены. В языке Nemerle нет анонимных типов, однако ими все пользуются, поскольку они реализованы через макросы.

def obj = new(name = "anon", age = 10, created = DateTime.Now);


В общий чертах, работает это так: макрос new по переданным параметрам генерирует генерик-класс с макро-атрибутом [Record] вида

[Record] class AnonType[name, age, created] {

public name : name;

public age : age;

public created : created;

}


Макрос [Record] создает конструктор с аргументами для всех полей, а потом вызов макроса переписывается в конструктор только что созданного класса.
После раскрытия макроса new
Read more... )
stdray: (Default)
боль и унижение )

Твиттерочек фп-блогов приносит иногда феерические откровения. Золотой в жж, мудризм... Один тут недавно MVC разгадал, другой гвозди в "крышку их устоев непоколебимости ООП" забивает. Атаковали бойцы невидимого фронта некошерную парадигму. Урон "врага" пока оценить трудно, но вот атакующая сторона уже несет серьезные имиджевые потери. Надеюсь, планета ФП и дальше будет держать нас в курсе событий.
stdray: (Default)
Проблемы описание маршрутов в ASP.NET MVC известны:
- это слишком многословное описание
- это строки и отсутствие проверки в compile-time корректности маршрута
- это отсутствие хелперов для генерации ссылок

Есть, правда, шаблоны T4MVC, предоставляющие статические хелперы для генерации url'ов по action'ам и доступа к разнообразным view. Однако, проблема со строками в маршрутах остается, проблема проверки соответствия параметров описанных в маршруте и параметров обработчика тоже.

Хотелось бы сделать нормально, чтобы было кратко, интуитивно понятно, с проверками в compile time. Я достаточно давно в фоновом потоке размышляю на этим вопросом. И пока у меня сформировался такой краткий список требований к DSL описания маршрутов:
- внутри строки маршрута должно происходить связывание имен
- необходимо иметь возможность указать слово ХТТП
- необходимы ограничения на связываемые имена (прямо внутри маршрута? отдельно?)
- необходим вывод маршрутов по контроллеру
- возможно, необходима группировка маршрутов по общей части пути
- необходимы параметры по умолчанию
- необходимы имена для маршрутов (опционально?)

Возможно, требуется что-то еще. Однако в силу малого опыта разработки веб-оперденей, я не могу составить полный список потребностей, которые надо покрыть возможностями данного DSL.

Я смотрел описание маршрутов в Django - не очень понравилось. В качестве ограничений регулярки, убивающие читаемость. Из плюсов, пожалуй, возможность "подключить" сразу группу маршрутов и именованные маршруты.

Глядел на описание в Play Framework. Описание достаточно краткое и лаконичное, но нельзя сказать, что богатое возможностями.

И, конечно, я смотрел, как сделано в Ruby on rails. Это, пожалуй, самая продвинутая система описания маршрутизации веб-приложения. Там есть все из моего списка и даже больше. Сложно сказать, насколько удобно оно на практике, но читать такие декларации маршрутов, мне не очень приятно (видимо, из-за непривычности синтаксиса Ruby).

Смотрел какие-то другие поделия, регулярно натыкаясь на описание маршрута, приклеенное к обработчику. Такого счастья точно не надо.

Самая большая проблема, пожалуй, RESTful routes. Идея, лежащая в основе, достаточно проста - есть некоторый набор HTTP Verbs и с их помощью можно отобразить один путь на разные методы контроллера, имитируя действия (CRUD) над объектом (ресурсом). При этом, сразу возникает желание иметь вложенные объекты. И для этого, требуются какие-то специфичные средства описания. Для ASP.NET MVC уже достаточно давно была сделана библиотека, позволяющая несколько сумрачным синтаксисом на лямбдах описывать подобные иерархии. Потом, c выходом четвертой версии фреймворка, оно вроде стало не нужно, поскольку WebApi сам генерирует маршруты. Правда, это не касается вложенных ресурсов. При этом видно, что в дочернем ресурсе происходит накопление параметров от всех родителей. В Ruby, как я понял, принято забирать параметры из словаря, для целей реализации проверок в compile time это подходит мало. Не знаю, существуют ли красивые решения.

По сути, хотел просто сформулировать свои мысли по этому поводу. Но, заодно, пожалуй, спрошу у читающих меня:
- есть ли фреймоворк, где описание маршрутов сделано идеально, который можно взять как пример?
- какие задачи должен решать dsl описания маршрутов, то есть чем вы пользуетесь часто, чем редко, чем хотели бы пользоваться, но не имеете средств?
stdray: (Default)
Решил посмотреть, чем ребята из соседнего комьюнити F# в плане unit-тестов промышляют. И нашел вот такой шаблон проекта. Скачал, установил, стал смотреть, чего там в файле проекта такого особенного. А ничего! То есть вообще самый обычный проект библиотеки классов!

Ну ок, качаю сборку Nemerle для 2012 студии. Это кстати оказалось труднее, чем я думал. Самое новьё сейчас доступно по ссылке http://tc.rsdn.ru/, там надо выбрать интересующую платформу и версию студии, потом выбрать последний удачный билд и на вкладке Artifacts уже можно забрать желанный msi. Я какбэ с TeamCity никогда не сталкивался, потому достаточно долго разбирался что и где.

Ладно, поставил Nemerle и интеграцию с 2012 студией. Создал проект библиотеки, добавил в зависимости уже поднадоевшую VisualStudio.QualityTools.UnitTestFramework.dll, написал два теста, собрал и... ВСЕ ТЕСТЫ ПОЯВИЛИСЬ САМИ. И даже отладка доступна и вообще все робит из коробки. То есть, я там вытанцовываю с бубном вокруг студии в стиле прыщавого админа, а прогресс рядом. MS, видать, переработали систему, избавившись от тех невменяемых ограничений и теперь все хорошо.

Правда, сама интеграция Nemerle с 2012 студий пока нестабильна, хотя большую часть времени работает весьма сносно. И я как-то побаивался переходить, но, думаю, безгеморройные тесты являются весомым аргументом.
stdray: (Default)
Написал про вуду-тесты для Nemerle в студии и уже хотел смотреть зомбоящик, как внезапно в голову пришла мысль, что возможно студия фильтрует проекты с тестами банально по расширению файла проекта. А ради совместимости с сишарповским тулзами Nemerle умеет компилировать достаточно большое подмножество C# и, соответственно, работать с проектами csproj.

Отлично, как и в прошлый раз создаю немерлевую библиотеку, добавляю Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll, пишу тесты. Компилирую - все собирается. Теперь удаляю проект из решения. Меняю ему расширение с .nproj на .csproj. Открываю файл проекта в текстовом редакторе и в самую первую секцию PropertyGroup копирую:

<ProjectTypeGuids>{3AC096D0-A1C2-E12C-1390-A8335801FDAB};{FAE04EC0-301F-11D3-BF4B-00C04F79EFBC}</ProjectTypeGuids>


Пулучился .csproj следующего содержания: пример. Добавляю проект обратно в решение, компилирую и, вуаля, тесты доступны без всяких лишних проектов.

Отличия от предыдущего метода:
1) Там есть лишний проект, тут - нет
2) Там нельзя дебагером отлаживать тесты, тут - можно.
3) Там работал немерлевый автокомлит, тут - нет.

Я думаю, что так-то поудобней будет. Даже с учетом того, что автокомплит поломался. Но может и этот вопрос решаемый.
stdray: (Default)
Для написания unit-тестов я пользуюсь стандартными студийными возможностями - "Создать тестовый проект Visual C#" и пихаю туда тесты (суть классы и методы помеченные специальный атрибутами). Я не то чтобы фанат тестирования, просто писать тесты быстрее и проще, чем каким либо иным способом проверять написанную функциональность. И хотя я понимаю, что надо бы прочитать что-то про разработку через тестирование, про лучшие средства для него и тд, текущее положение дел меня вполне устраивает.

Однако, этот подход перестает работать, если пишешь код на чем-то отличном от C#/VB.NET/C++.NET, поскольку то ли в студию, то ли в mstest зашито данное ограничение. И хоть писать тесты на C# вполне приемлемо, это сильно раздражает. Как вообщем-то и ставить какие-то сторонние тулзы вроде NUnit большого желания нет, поскольку, во-первых, я уже привык к студийным возможностям вроде ведения списков тестов, ко всяким связанным с ними окошкам, а, во-вторых, предпочитаю по мере возможности пользоваться средствами из коробки.

Вообщем, мне надоело писать тесты к Nemerle на C# и я решил разобраться в проблеме. И хочу рассказать про вуду-решение, подходящее не только для Nemerle, но и для любых других языков .Net, не заапрувленных MS, вроде того же F#.

Первое, надо добавить в решение проект библиотеки на Nemerle (в моем случае это Nemerle.Mixins.Tests). К ней в зависимости добавить Microsoft.VisualStudio.QualityTools.UnitTestFramework.dll, открыть соответствующее пространство имен и написать пару тестов. Что-то вроде такого:

using Microsoft.VisualStudio.TestTools.UnitTesting;

[TestClass]

public class SimpleTest {

[TestMethod] public Fail() : void { Assert.IsTrue(1 == 2); }

[TestMethod] public Win() : void { Assert.IsTrue(1 == 1); }

}


Read more... )
stdray: (Default)
В вики Nemerle существует вот такая страничка, на которой рассказывается, как могли бы вести себя трейты, будь они реализованы в языке. Но пока что "not yet done", хотя тема неоднократно поднималась на форуме. Как я полагаю, это все следствие размышлений на тему "Как бы нам вернуть обратно множественное наследование". То есть сейчас в дотнетах оно есть, но в значительно урезанном виде: интерфейсы позволяют наследовать только требования к объектам, а уж реализацию приходится пилить вручную, что конечно же раздражает.

Мне в этом описание понравилась идея выставлять требования для объектов, к которым возможно "подселять" трейты. Однако, мне не очень нравится идея реализовывать это дело внутри интерфейсов, поскольку такой объект будет некорректным с точки зрения, допустим, C#. К тому же такие трейты не смогут иметь собственное состояние, что очень сильно ограничивает варианты их использования.

Если не фокусироваться на описанном синтаксисе, то можно сказать, что задача реализации примесей состоит из трех этапов:
- проверка требований
- обеспечение отношения подтипирования
- наследование реализации
При этом, можно считать, что наследование реализации - это такое хитрожопый макрос, занимающийся переписыванием полей из одного определения в другое. А поскольку Nemerle обладает развитой макросистемой, вполне возможно такое реализовать.

Для описания примеси я использую модуль, помеченный атрибутом [DefMixin], внутри которого описывается интерфейс (он представляет собой требования) и класс (он представляет реализацию). Простейшее описание примеси может выглядеть так:

[DefMixin]

public module Foo {

public interface Require {

getX() : int;

setX(v: int) : void;

}

public class Provide[T] where T: Require {

public inc() : void { self.setX(self.getX() + 1); }

}

}


Узнать больше про примеси в Nemerle )
stdray: (Default)
Когда читаешь в интернете разные программистские дискуссии, постоянно натыкаешься на некоторые шаблонные суждения. Например,
- когда говорят про high load, ведут речь за хорошую горизонтальную масштабируемость;
- когда говорят про embedded, обсуждают, как станцевать вальс на площадке размером с пятирублевую монету;
- когда говорят про enterprise, имеют в виду либо оскорбление, либо CRUD.

Хотя в последнем случае разница довольно условна. То есть «энторпрайз» - это такие сферические неудобные медленные приложения в вакууме, а круды — это продукт деятельности макак, школьников и индусов. Это значит, например, что индийцы не индуисты круды писать не могут. То есть круды — это что-то плохое и простое.

Хотя, конечно, только от того, что какую-то деятельность заклеймили как простую и бесполезную, проще от этого она точно становится. Чем дальше, тем важнее становится информация. И все, кому не лень (и кому лень тоже) занимаются её накоплением, структурированием и анализом. При этом мой опыт таков, что данные — вещь удивительно не гибкая. Поскольку есть информация сама по себе, а есть ее представление, выбранное для решения конкретной задачи. Эти представления являются первой сложностью. Первой, в том смысле, что все начинается c выбора представления: как данные разделить на маленькие кусочки, как выразить эти кусочки в терминах своего инструментария (модель данных приложения, модель постоянного хранилища), как обеспечить их согласованность и определенную сложность доступа к ним. Хотя по этому поводу написано достаточно много, от нормальных форм реляционной базы данных до паттернов Фаулера, эта задача все же не является тривиальной. Слепое следование рекомендациям ни к чему хорошему не приводит, потому приходится постоянно оценивать свои решения, насколько они кажутся удачными, начиная с момента разработки и заканчивая текущим моментом (если апликуха до него дожила). И тут большую роль играет опыт, поскольку он позволяет учесть значительно больше вариантов использования и сложных граничных случаев.
Read more... )

July 2017

S M T W T F S
      1
2345678
910 1112131415
16171819202122
23242526272829
3031     

Syndicate

RSS Atom

Most Popular Tags

Style Credit

Expand Cut Tags

No cut tags