Программирование

Моё первое знакомство с Groovy было не вполне удачным. Так, обнаружилась достаточно невысокая производительность, тормоза при использовании статической типизации, и отсутствие масштабных плюсов по сравнению с Java. В тот момент единственное, что я был готов отдать на откуп Groovy, была отладочная консоль сервера. Например, у нас в сервере используется JavaScript от Mozilla (Rhino), ещё с тех пор, когда его не было в JRE.

Однако позднее пришлось «допиливать» проект, написанный на Groovy с использованием фреймворка Grails, и тогда в этот язык я влюбился.

Я могу часами (ну ладно, не часами — минутами) придумывать, как сделать рефакторинг Java кода, чтобы он стал более читаемым, более производительным, более грамотно организованным. Но на Groovy можно зайти ещё дальше. В сети есть интересный пример, как программу на Java (конечно же, являющуюся и валидной программой на Groovy), можно переписать.

Кстати, самое первое и очень важное преимущество Groovy заключается в том, что программа на Java — это программа на Groovy. Вовсе необязательно переписывать код! То, что все библиотеки Java, написанные за последние ≈15 лет, можно использовать и в Groovy — и так понятно. Но этот факт тоже не стоит недооценивать. Ну да ладно, вернёмся к рефакторингу:

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

Именно благодаря Perl, не сносит кукушечку у меня, в общем-то Java’иста, когда я смотрю на чьи-то творения на JavaScript, или того хуже, на каких-нибудь Erlang или Scala. Perl вообще подходящий язык для того, чтобы тренировать кукушечку, я считаю. Тем более, если им заниматься 12 лет.

Сегодня решил-таки сделать скриптец на Groovy. Причём именно что такой скриптец, который почти идеально смотрелся бы на perl.

Сначала создадим проект в Мейвене: mvn archetype:create -DarchetypeGroupId=org.apache.maven.archetypes -DgroupId=ru.bytexgames.test -DartifactId=server

Редактируем pom.xml. Нам нужно добавить наркотическую зависимость проекта от Hibernate, для чего мы идём на http://mvnrepository.com/ и находим там параметры для зависимости hibernate:

<dependency>
<groupId>org.hibernate</groupId>
<artifactId>hibernate-core</artifactId>
<version>3.6.4.Final</version>
</dependency>

Уже настолько вжился в наши мегабайты кода, что забыл, что где-то существует что-то еще. Пишу простенькое приложение, параллельно изучая Griffon (млять, уже часов 7 пишу, фигасебе простенькое). Большую часть времени потратил на то, чтобы создать собственный плагин, аналог плагина GlazedLists.

Про то, что можно унаследоваться от нужного класса, сообразил лишь к двум часам ночи. К трем сообразил, что унаследоваться не получится, но можно скопировать класс целиком и немножко поменять фабрику.

Так сложились звёзды, что меня потянуло в сторону Enterprise Java. Спринги, Хибернейты, серверы приложений - всякая такая фигня. Словом, жизнь цикличная. Так и вспоминаются старые деньки, когда я впервые столкнулся с этой областью программирования. У меня в то время был Duron 900 Mhz и 512Mb оперативки (впрочем, пришлось скрепя сердце, докупить еще 512 - и всё равно тормозило).

Поковырявшись в последнем Spring, могу заметить, что он стал лучше. Для небольших проектов - очень удобна настройка без бешеной кучи XML, например.

А будущее… оно, конечно, может и не наступить, но всё же:

Невероятно, но факт! Помимо GORM, в Grails есть и обычные SQL запросы (сарказм!). И, соответственно, обновление базы частенько приходится делать именно через них. До этого момента базу я обновлял через командную строку psql. Но совсем недавно подумал “Какого чёрта? Есть же Groovy Console” (это такой полезный плагин для Grails, который позволяет выполнять любые Groovy скрипты на вашем сервере).

Для начала установим плагин console:

grails install-plugin console

Зайдя на ваш сервер http://localhost:8080/console/, мы увидим консоль Grails. В этой консоли можно просто ввести небольшой скрипт, который всё сделает за вас.

И снова извечный вопрос выбора. В наше героическое время PHP-фреймворков – хоть жопой жуй. В планах реализация нового проекта (точнее, первый этап – реализация движка для нескольких новых проектов), соответственно в который раз встает вопрос выбора.

Фреймворки рассматриваются с разных позиций, а именно:

• Легкость создания нового проекта, чтения и поиска документации
• Продуманность объектной модели, возможность расширения
• Потребление памяти
• Скорость
• Роутинг
• Удобство настройки и отладки

Тесты производились на неком “Hello world”-проекте, типичном для MVC фрейморков. Проект включает в себя 1 контроллер, 1 модель, 1 представление, 1 роут. Модель загружается из базы средствами ORM. Поскольку во всех фреймворках скорость выполнения тестового проекта высока, для оценки использовались результаты apache benchmark (ab) на loopback-интерфейсе (127.0.0.1).

Для тестов использовался VDS (1 Гб памяти, бёрст до 1.5 Гб). Процессор: по 666 Мгц от каждого из 4х ядер “старого” Xeon X3350.

Настройки всех фреймворков “по умолчанию”. Для KO3 включен caching (это не кэширование запросов, это кэширование путей для автозагрузки классов. Ближайший аналог, наверное, prod режим в Symfony2). Для Symfony2 включен prod режим, отключен дебаг.

Пост писался 5 июля 2010, но так и не увидел свет в день своего рождения. Публикую спустя месяц.

Если кажется, что Webmoney перестала работать – это вовсе не так. Дело в том, что истек срок действия сертификатов, которыми сервер подписывал свои ответы клиенту. Истекший сертификат не считается валидным, поэтому был выпущен новый сертификат. На этот раз сроком на 20 лет.

Но все проблемы с сертификатом можно легко решить. И вот как это сделать:

И зачем мы вообще подписались на этот проект… Точнее, взялся за проект товарищ и коллега по работе. ТЗ на 20 листов. 20 пишем, 80 листов в уме. И не откажешься уже – партнерам делаем. В два раза дольше по времени, чем задумано.

Но вроде, большая часть работы позади. Уже интегрировали дизайн, подкорректировали стили… Дошло до почты. Оказывается, текстовая простая почта наших друзей не устраивает. ХэТэЭмЭль им подавай. Конечно, можно сформировать HTML сообщение и в обычном mail() в PHP, но раз уж у нас в распоряжении Kohana – зачем юзать костыли?

Сегодня я узнал, что я – необразованный ретроград – изобрел велосипед. Точнее, пародию на велосипед. Как известно, я программирую на Java и в данное время мы работаем над новой игрой, konklav.ru. Собственно, мы решили избавиться от архитектурных недостатков сервера Берсерка, и несмотря на то, что в новом движке используется множество старого кода – он довольно сильно переработан.

Рефакторинг несет в себе две основные цели: первой из них является повышение производительности под высокой нагрузкой (избавляемся от ненужных синхронизаций, переходим на блокирующие коллекции, где это возможно). Вторая цель – улучшение модульности. Уже сейчас скелет сервера Конклава Бессмертных можно использовать для программирования любой онлайн игры.