вторник, 2 ноября 2010 г.

PostgreSQL 9.0 is out

Наконец вышла долгожданная девятая версия PostgreSQL !

вторник, 5 октября 2010 г.

Книга: Enterprise Software Without the BS

Что за бойкое перо! Господи Боже! как пишет этот человек!

Н.В. Гоголь, Миргород


Прочитал на одном дыхании книгу широко известного в узких кругах специалистов по Java и Adobe Flex Якова Файна. Это книга больше про жизнь, чем про софтвер. Как наниматься на работу и как правильно уйти из компании, что нужно говорить и о чем лучше молчать, как строить карьеру - обо всем этом поведал автор c присущим ему чувством юмора.

понедельник, 4 октября 2010 г.

Мартин Фаулер жжот

Я всегда читаю Мартина Фаулера с удовольствием, вот нашел его статью о системах контроля версий. Рекомендую всем.

четверг, 23 сентября 2010 г.

Build Adobe Flex projects with Apache Maven and Groovy

I have released the first version of GMF. GMF stands for Groovy Maven Flex. This is an Apache Maven plugin to build Adobe Flex projects. I developed it for my needs, hoping that someone will find it useful. Why to develop another plugin when there are already 2 or 3 available ? While working on Flex projects, I felt that using Flex SDK as Maven dependency is not handy. I have also found that using external swc libraries with Maven is also not handy, because most of them are not available in public Maven repositories.
I think that people should not write Maven plugins in Java, because Groovy fits better for small projects. Another reason is that I don't think that we have to use XML to configure Maven plugins. So I have implemented GMF in Groovy, and it is configured with a Groovy-based domain-specific language. Finally, I discovered that Plexus which is dependency-injection container in Maven is very out-of-date compared to modern DI containers, so I used Guice instead of Plexus.

вторник, 21 сентября 2010 г.

Tagging successful builds with Mercurial

I have shared a script which tags successful builds.

This is configuration for Hudson:

вторник, 14 сентября 2010 г.

Apache Maven - взгляд изнутри

Хочу поделиться опытом написания плагина для Apache Maven. Хотя 99 процентов плагинов написаны на java, я убедился что лучше писать плагины для Maven на языке Groovy. Так получается быстрее и меньше кода. Второе открытие - Maven использует устаревший и неуклюжий dependency injection container который называется Plexus. Работать с ним можно, но противно. Поэтому я отказался от Plexus и использовал Guice.

вторник, 24 августа 2010 г.

В поисках e-mail клиента для Linux

Наконец, я нашел себе e-mail клиент по душе. За 10 лет пробовал их много, Pine, Evolution, Thunderbird, KMail... Но вот недавно установил Claws Mail и эта програмулина мне очень понравилась. Доступ по IMAP в Сlaws Mail реализован лучше, чем у других клиентов, интуитивно понятный и удобный интерфейс , работает очень шустро. Отлично конектится к GMail.
Да и это не удивительно, потому что Сlaws Mail очень похож на лучший email client всех времен и народов - The Bat. Мне удалось запустить The Bat под wine, но все-таки отдал предпочтение Сlaws Mail.

суббота, 14 августа 2010 г.

Книги В.В. Ершова

Открыл для себя замечательного писателя - ходи сюда.
В.В. Ершов - русский Экзюпери.

воскресенье, 8 августа 2010 г.

Что такое NIO и как с ним бороться

Коротко физику природного явления NIO можно выразить формулой:

NIO = IO + select + E

Кликните в браузере поочередно на первые три переменные. Четвертая переменная, E, является энергией еквивалентной усилиям потраченным на синхронизацию между selecting thread и worker thread, а также протокол обмена в не-блокирующем режиме, в том числе учитывая дефрагментацию TCP пакетов.

Мне нужно было написать простой java server который принимает сообщения от Adobe Flash Player по протоколу XmlSocket. Задача выглядела очень простой - получай запросы и отсылай ответы, поэтому решил не прикручивать готовый application server типа томката, а написать свой маленький сервер. За день я сделал реализацию на блокирующих сокетах. Дальше решил сделать эксперимент и переписать на не-блокирующих сокетах, тоесть NIO.

Оказалось что c NIO все намного сложнее, сразу стало ясно что Е совсем не маленькая величина. Остановился на самоой простой реализации с единственным selecting thread, это заняло в два раза больше времени чем блокирующие сокеты. Последняя стадия эксперимента: безжалостно убил материализцию темной енергии Е в коде и и использовал Apache Mina. И тут я понял насколько полезна Mina для написания распределенных систем, и что нет смысла реализовывать взамодействие между частями системы на сокетах с нуля. Mina создает уровень абстракции который сводит E к минимуму. После того как прикрутил Mina, количество кода уменьшилось в три раза: было 6 классов, осталось 2.

Поэтому, если надо работать с сокетами, то лучше делать это используя Mina, это будет быстрее и надежнее.

Вот пример Mina сервиса на Groovy:

воскресенье, 11 июля 2010 г.

Гитарные гуру

Что это я все о работе да о работе. Давно не писал о музыке. Представляю вашему вниманию троих гитарных гуру.





суббота, 10 июля 2010 г.

Самодокументируемый код - миф или реальность ?

Для каждого проекта важно иметь документацию. Существует два уровня документации.
Уровень первый или базовый уровень - это комментарии в коде. Также существует документация в виде Wiki, это-следующий уровень. Есть люди которые убеждены что самодокументируемый код не нуждается в комментариях. Идея самодокументируемого кода в том чтобы давать названия переменным и функциям таким образом, чтобы при взгляде на код было понятно как он работает, то есть комментарии как бы не нужны. На своем опыте я убедился что эта идея не работает. Комментарии обязательно нужны. В чем-то защитники самодокументируемого кода правы - автор кода может понять как работает его код. Но другой человек все равно не поймет. Не поймет потому что самодокументируемый код может дать ответ как этот кусок работает. но не даст ответ зачем чем этот кусок был написан, какие ограничения на параметры, поэтому полной картины в голове не будет. Должен быть самодокументируемый код плюс комментарии к нему :)

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

Поэтому проверка наличия комментариев должна быть частью code review. Если нет комментариев значит, на этапе code review код должен быть забракован.

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

пятница, 9 июля 2010 г.

Линукс, Open Source и патриотизм

Три года назад на мероприятии организованном компанией Sun в Киеве выступали докладчики из Китая. В перерыве я подошел к одному китайцу и спросил, правда ли что в Китае существует государственная ОС, называется Red Flag ? Китайский специалист подтвердил что у них закон обязывает использовать Red Flag Linux в государственных учреждениях. В России тоже занимаются созданием национальной OC. Нужна ли национальная ОС государству ? Я считаю что национальная ОС необходима, потому что это гарантия суверенитета государства, такая же как и вооруженные силы. Стратегия развития государственных компьютерных сетей должна основываться на использовании государственной ОС и open source software. Почему я так считаю ? Допустим, у государства XXX все компьютеры работают под ОС W, все программное обеспечение в министерстве образования, министерстве обороны написано под W. В один прекрасный момент фирма-производитель OC W, назовем ее M, говорит что у нас уже вышла новая версия W, поддержка старой версии заканчивается через 3 года. Государство уже подсело на иглу W и через 3 года будет вынуждено заплатить M сумму денег чтобы проапгрейдить W. Далее, Государственная Налоговая Инспекция использует формат файла .PUK, который является закрытым форматом и принадлежит компании M. то есть государство попадает на деньги по схеме vendor lock-in. Значит государство будет покупать X-Office у компании M. за бюджетные. тоесть наши с тобой, читатель, денежки. Это еще цветочки. Давайте представим что у государства XXX возник конфликт с государством в котором находится компания М, назовем его YYY. До столкновения вооруженных сил пока что дело не дошло, стороны используют не боевые методы, а именно, каждый день производятся атаки на сервера. Через некоторое время все компьютеры в государстве XXX перестают работать, хакеры из министерства обороны YYY нашли уязвимость в ОС W. Возникает совершенно дикая ситуация, теперь министерство обороны страны XXX обращается в компанию M с просьбой чтобы уязвимость в OC W была устранена. Но компания M находится в государстве YYY, то есть в стране противника. В результате компьютерные системы страны XXX выведены из строя, деятельность госучреждений парализована, информация о конфликте в интернете представлена исключительно с точки зрения YYY. Все, война проиграна. Вот к каким ужасным последствиям может привести отсутствие национальной ОС. Война в киберпространстве уже стала реальностью. О современных специальных операциях как форме геополитического противоборства можно почитать тут, очень познавательно.

среда, 19 мая 2010 г.

Хто сломал билд ?!

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

В Subversion есть команда svn-bisect из пакета subversion-tools, инсталируется так:
sudo apt-get install subversion-tools

Счастливые пользователи Hg или Git используют hg bisect и git bisect.

Выражаю соболезнования пользователям CVS, бинарный поиск не работает.

понедельник, 3 мая 2010 г.

from CVS to Hg

Два месяца назад наша компания отказалась от CVS и перешла на Mercurial.
Давно было понятно что продолжать использовать CVS не имеет смысла. Как жестко сказал Linus Torvalds "If you like using СVS, you should be in some kind of mental institution or somewhere else". Было два варианта: Subversion или DCVS. Провели анализ, оказалось что действительно cовременные DCVS такие как Mercurial или Git превосходят Subversion, особенно в branching и merging. В некоторых экзотических случаях Subversion лучше подходит, например если нужно делать sparse checkouts потому что размер репозитория настолько огромен что он не помещается на диске, или если нужно скрыть папки от одних юзеров и наоборот, дать доступ другим юзерам. На практике такое случается редко, у нас размер CVS репозитория был 800 Mb, понятно что sparse checkouts никому не нужны. Дальше, у нас кросс-функциональная команда, каждый девелопер имеет право записи в любую папку,поэтому вторая мега-фича Subversion - ограничение доступа тоже для нас не актуальна. Зато для нас очень важно иметь хороший branching и merging, а здесь DCVS рулят.

Еще один важный момент, интеграция VCS с другими тулзами. Есть Mercurial плагин для Eclipse, он работает медленно при апдейтах на больших проектах (35 000+ файлов). Поэтому лучше использовать черепаху для коммитов и апдейтов, а Mercurial плагин юзать для просмотра истории изменений файла или аннотации. CruiseControl и Hudson интегрируются отлично. Сode Review tool тоже поддерживает Mercurial. Интеграция с JIRA есть, но для нас не имеет значения, потому что Mercurial имеет команду поиска , и если надо найти коммиты по номеру тикета то это всегда можно сделать через веб морду или с командной строки.

При конверсии репозитория СVS в HG главная ветка (head) сконвертилась нормально, остальные 3 ветки сконвертировались не совсем правильно, пришлось их фиксить руками. Проблема с ветками в том, что в СVS невозможно определить время создания бранча, можно только определить время первого коммита в бранч. Поэтому после конверсии в бранчах не хватало файлов которые не были изменены в бранчах. Проблему решил так: после конверсии нашел старые СVS теги которые тегают код непосредственно перед созданием бранча и смерджил бранчи с этими тегами. После этого в бранчах появились все файлы.

Затраты на миграцию. Вечером в конце рабочего дня мы закрыли СVS репозиторий на запись. На следующий день девелоперы потратили пол-дня чтобы настроить environment, после обеда пошли первые коммиты в новый репозиторий. Можно сказать что процесс прошел без потерь. У некоторых девелоперов будет культурный шок, потому что они пытаются применить навыки работы с CVS которые не работают в HG, но после первых коммитов и мерджей это пройдет.

HG дает возможность делать сode review до того как код попадет в сentral repository. Мы коммитим локально, создаем соde review topic на review board, только после того как коммит одобрен, мы пушим в сentral repository. Такой подход трудно реализовать в Subversion, надо возиться с патчами, практически это не реально.

Если вы используете СVS, то я бы советовал перейти на Git или Mercurial, ни в коем случае не Subversion.
Если вы уже используете Subversion, то вопрос миграции не так актуален как с СVS. Если сильно хочется работать с DCVS, то можно не ждать пока компания перейдет на DCVS (мне пришлось ждать полтора года) и использовать две системы одновременно, делать всю работу в DCVS а потом заливать результат в Subversion.

пятница, 2 апреля 2010 г.

И все же TestNG лучше чем JUnit

Сегодня я скачал последнюю версию JUnit, а именно 4.8.1 и еще раз убедился что JUnit не догнал TestNG. Есть 4 причины почему TestNG лучше:

Parameterized tests

DataProviders в TestNG удобнее чем статические методы с аннотацией @Parameters в JUnit. Мне не нравится что JUnit требует чтобы метод, который создает параметры для теста, был статическим, также в TestNG есть возожность задавать параметры в файле.

Concurrent tests

В JUnit аннотация Test не позволяет указать что тест должен высполняться в разных потоках одновременно.

Dependency between tests

В JUnit фича отсутствует.

Документация

Сравните http://junit.sourceforge.net/doc/cookbook/cookbook.htm и http://testng.org/documentation-main.html.

суббота, 13 марта 2010 г.

Самый популярный != лучший

Не всегда самый популярная технология есть лучший выбор. Например, в мире Java самый популярный фреймворк для тестов был и есть JUnit. Но до четвертой версии JUnit'а c 2004 по 2006 год лучшим однозначно был другой фреймворк, а именно TestNG. Четвертый JUnit, кажется, догнал TestNG позаимствовав у него много идей, можно выразить это такой формулой: JUnit 4.x = TestNG + Junit 3.8 . TestNG как минимум не хуже JUnit, и я выбираю TestNG.

Какая опен сорс база данных является самой популярной ? Правильно, MySQL. Я никогда не буду использовать MySQL, только PostgreSQL. Мне не нужна база данных которая не может построить правильный план для запроса с subqueries.

Какая самая популярная система контроля версий ? Конечно, это Subversion. Я спрыгнул с Subversion на Mercurial в 2009 году и ни разу об этом не пожалел, надеюсь, что больше никогда не буду работать с Subversion.

Самый популярный continuous integration server это CruiseControl. Я не понимаю как это случилось, потому что Hudson намного лучше.

воскресенье, 21 февраля 2010 г.

Picture Driven Computing, Java и Python

Мне стало интересно какая ситуация в проекте Jython, когда я заглядывал на их сайт год назад он был скорее мертв, чем жив. Но не все так плохо, проект ожил и развивается ! На cайте Jython вы можете увидеть ссылку на проект Sikuli который меня просто поразил. Sikuli применяет концепцию Picture Driven Computing для программирования скриптов.

Допустим, нам нужно написать скрипт который реализует какой-то сценарий тестирования для GUI приложения под Windows. Традиционный подход - запустить тулзу которая записывает наши действия а потом воспризводит их посылая на GUI элементы такие события как клик мышью, перевод фокуса, ввод текста, нажатие на кнопку, выбор меню и т.д. Чтобы правильно воспроизвести сценарий тулза запоминает координаты контролов, значения которые вы вводите в контролы, последовательность операций. Например , "кликнуть на пятую иконку в третьем ряду таблицы". Вместо того чтобы запоминать позицию иконки, Sikuli использует распознавание образов, запоминает образ иконки которая была нажата, снимает скриншот с экрана. Когда вы воспроизводите сценарий, Sikuli найдет на окне иконку по ее образу и кликнет.

Еще одна приятная новость - можно запускать Django на Jython! Можно использовать Django на платформе Java, Django это отличный web framework, аналог Ruby реализован на Питоне.

пятница, 22 января 2010 г.

Нужна ли Java на веб-морде или зачем зайцу пятая нога

Я пришел к выводу что язык Java не есть лучший выбор для web интерфейса.

Причины:
  • Внесение изменений в контроллеры требует перезагрузки приложения в аппликейшен сервере (кроме простых случаев когда достаточно java hot swap ).
  • Сам язык Java является представителем семейства C++ подобных языков и плохо подходит для Web, нужно делать слишком много лишний движений сравнительно со скриптовыми языками. На ruby, python или groovy получается в два-три раза меньше строк кода чем на Java, работа с коллекциями, мапами на скриптовых языках намного приятнее, операции с строками тоже лучше, а нам для веба больше ничего и не нужно потому что вся логика вынесена в business logic layer (BLL)
  • По вышеуказанным причинам продуктивность работы web девелопера ухудшается. Когда я стал программировать на grails, то скорость разработки возросла примерно в полтора-два раза.
Поэтому есть смысл использовать
  • Grails (проверено опытом)
  • Spring MVC c контроллерами на cкриптовых языках (проверено опытом)
  • Wicket Groovy (нужно еще разобраться)