Субботний вечер пропаганды маргинальных технологий: Статистический анализ с помощью clojure и incanter

Начну из далека. Все прекрасно знают, что Java код компилируется в платформа независимый java bytecode. Sun'ики этого не планировали, но, так же как и для CLR, появились альтернативные языки, компилируемые под JVM. Зачастую это порты других известных языков: Jython (Python), JRuby (Ruby), Kawa (Scheme). Они пользуются небольшой популярностью по очевидной причине, люди предпочитают использовать не порт, а настоящий язык. Но есть языки разработанные специально для JVM. Например Groovy, солянка Ruby и Java, заполучил своё место под солнцем как скриптовый язык, часто используется, как основа более гибких конфигураций, нежели статический xml и вроде веб на нём тоже делают. Ещё есть Scala, мельтипарадигменный язык, который совмещает в себе огромную кучу фич из ООП и ФП. Мне он не очень нравится перегруженностью синтаксиса, но он набирает популярность как замена Java. Но сегодня я хотел бы поговорить о Clojure - это функциональный язык, диалект великого Lisp'а. Ах, нет, я хотел обмануть, про замечательный язык clojure я не стану рассказывать детально в этой статье, лучший способ с ним познакомиться это одноименный раздел на сайте Алекса Отта. Там же есть постоянно обновляющаяся вводная статья написанная Алексом для журнала fprog.

Я участвую в проекте по обработке данных. Предыдущая версия использовала MS Sql Server для своей работы, поэтому анализ работы системы сделать было достаточно просто, можно было обойтись и простым t-sql скриптом или, если нужно было графическое представление, то можно было использовать Reporting services. Сейчас же, для того компонента, которым я занимаюсь, никакие СУБД не используются, поэтому какие-то выводы можно делать исключительно по логам. Поэтому даже был сделан отдельный структурированный лог в csv формате обо всех важных событиях, произошедших в системе. К примеру, к нам приходит много файлов, поэтому для каждого из этих фалов, этот лог содержит упрощённо 3 записи: файл найден, файл отправлен на обработку, файл обработан. Как то у Ярослава возникла идея попробовать язык R, чтобы нарисовать какие-нибудь интересные аналитические графики. Меня идея заинтересовала, я скачал книгу и впал в ступор. В общем и целом, язык этот мне не понравился (можно сказать не осилил:)). Но месяц назад в очередном порыве изучения clojure, у Алекса наткнулся на упоминания о проекте incanter. Лучше всего его описали сами авторы:

Incanter is a Clojure-based, R-like platform for statistical computing and graphics.

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

Две стороны одной медали: удобство разработки

Хотел немного подробнее раскрыть упомянутый в предыдущем посте антипаттерн "Immutable Class", изобретение которого принадлежит моей клавиатуре. В данном конкретном случая, это была попытка в Java реализовать Immutable object. И тут возникла проблема, которая всегда актуальна в спорах "динамическая типизация vs статическая типизация". Т.е. с одной стороны можно сделать конечный код (который использует этот класс) более простым, с другой стороны мы получаем ошибки, которые, как правильно в исходном посте заметил Андрей не находятся компилятором. И это действительно произошло, у людей были проблемы с модификацией этого класса, из за чего он и был наречён immutable. Хотел бы более развёрнуто описать почему я так решил, вернее почему мне кажется, что ответ на это вопрос не так однозначен. В самом исходном посте одну из причин я уже указывал, это наследования с огромным количеством переопределенных методов. Тут хотел рассмотреть вопрос удобства изменения только этого класса. Комментарии и в особенности критика приветствуются.

О поиске простого решения или как я писал JobStore для Quartz

Java очень хорошо известна своим разнообразием различных Open Source frameworks, одни ребята из Apache наверно несколько десятков сгенерировали. Причём всегда есть много альтернатив (к сожалению, зачастую все равно выбрать нечего :))). Но есть планировщик задач Quartz, которому нет альтернативы, почти стандарт, так сказать. Причём с архитектурной точки зрения он довольно прост и хорош. У нас есть Scheduler в котором мы регистрируем Trigger'ы и Job'ы и связи между ними, таким образом каждый триггер может активировать одну или несколько работ.

Данная библиотека одна из ключевых в одном из наших подпроектов. Важный вопрос как всегда это persistence. Т.е. возможны следующие случаи к примеру:

• Если триггер должен сработать только несколько раз. То после рестарта приложения Scheduler должен знать об этом и не активировать его.
• Если у нас есть триггер, который должен срабатывать каждый час, но спустя, например, 59 минут наше приложение упало. То когда его перезапустили, этот триггер должен сработать через минуту, а не через час.

Это вопрос в Quartz так же решён. Есть интерфейс JobStore, к которому обращается Scheduler за всеми нужными данными и он должен обеспечивать сохранность данных. По умолчанию существуют две реализации RAM и JDBC. Как нетрудно догадаться, RAM никакой сохранности не обеспечивает, но JDBC по сути должно хватить всем, так как почти любая СУБД к вашим услугам. К сожалению для нас это не так, мы не используем СУБД. Поэтому пришлось реализовывать JobStore самостоятельно. И вот тут, тот, кто также успел сходить по ссылке на api JobStore, мог ужаснуться, так как JobStore - это интерфейс наверно на полсотни методов. Поэтому под катом, моя история, как я пытался малой кровью реализовать этого бегемота для наших нужд :)

Субботний вечер пропаганды маргинальных технологий: Анемичная модель

Ох, эта статья будет ещё более сумбурная, чем они бывают обычно у меня. Просто есть какие-то мысли и надо их немного устаканить.

Есть такой человечище, зовут Мартином. Когда я ещё только играл в HoMM 3, он уже написал статью про анти-паттерн AnemicDomainModel. И не смотря на то, что я запоем читал некоторые его книги и статьи, с этим я совершенно не согласен.

java.lang.Process баги

Хотел бы в очередной раз поругать Java'у. В этот раз по делу :)

Есть такой интерфейс java.lang.Process и класс Runtime, которые позволяют  запускать другие приложения, скажем так. У нас это достаточно частая штука. Скажем даже основная функция (:

Поэтому следующие два взаимодополняющих бага в JVM прочувствовали очень сильно на себе.

Process.waitFor() fails to return. Проблема заключается в том, что waitFor может упасть, если никто не вычитает stream'ы процесса. Я не зря употребил слово _может _, так как это например у нас первый раз появилось спустя несколько месяцев тестирования. Ладно, его типа закрыли, так как можно перед вызовом waitFor прочитать потоки процесса и всё будет хорошо. Ага, только в каком-либо другом, идеальном мире.

"IOException: Stream closed" if more data sent after Process.destroy. Тут мы приходим ко второму багу. Так как если применить выше указанный способ, т.е. запускать процесс, открывать потоки и читать их до завершения у работающего процесса, то в случае если его кто-нибудь kill'нёт, что для ряда процессов у нас нормальное явление, то мы получаем ещё один прекрасный exception при чтении. И этот баг не закрыт.

Да, варианты конечно всегда есть, даже несколько. Можно глотать exception, можно использовать цикл и exitValue, вместо waitFor. Но оба смотрятся по уродски.

Вот такая нелёгкая жизнь у Java программиста :) И я бы Sun Oracle всё бы простил, если бы это происходила на какой-нибудь Windows, так нет, тут всё хорошо, а происходят эти баги на той самой SunOS.

Новогоднее обещание :)

Не привычный пост :) Обычно пишу всякий рабочий треш, куча которого скопилась ещё и в draft'ах :) Но тут другое дело. Некоторый поток сознания приведший к этому можно почитать в buzz'е. Но если кратко. Часто видел/читал про американскую традицию давать в новый год всякие обещания на следующий, типа бросить курить или похудеть. Я решил, что надо поумнеть. Не знаю как у кого, но у меня знания очень трудно усваиваются после прочтения книжки, даже если делать задания в конце глав (а в некоторых таких заданий и нет). Вообщем было решено написать проектик, конечно же open source. Ничего нового и никаких startup'ов, просто проект, в котором можно было бы попробовать немного того, что прочитал или увидел в книгах, конференциях, статьях, подкастах и пр. Как всегда часто возникает вопрос, почему бы не присоединиться к существующему проекту. Всё просто, я хочу учить, попробовать много фишек, вообщем это не для проектов, которые ставят цель создать продукт, в конце я конечно надеюсь к декабрю 2010 получить продукт, но всё же основная цель поиграться, понабивать шишек, которые недоступны в hello world приложениях.

Больше двух с половиной лет, я каким то образом занимаюсь ETL и обработкой данных. И знаете, мне это нравиться. Вот и решил написать свою ETL :) Их тыщи, ещё одна не повредит. Ах да, и спасибо Андрею и Вите, вместе проработали много, делали PoC такой ETL на .NET.  Да и вся с кем я работа(л/ю). Получил бесценный опыт и большинство, что я тут напишу я знаю благодаря им. И конечно Ване, который меня познакомил со всеми этими отличными людьми.

Под катом, немного подробностей, если кому интересно.

И конечно же всех с наступившим Новым годом и успехов вам в ваших проектах!

Java Generics vs Наследование

Вообщем по просьбе Viktor Davion объясняю (в 140 твиттеровских символов не уложился), отчасти, что побудило к посту ненависти. Под катом, т.к. содержит плоды работы воспалённого мозга.