Groovy & Grails *

Shortcuts: github, tiles.js tiles.groovy tiles.ruby

Не секрет, что объектов в играх на порядок больше чем их возможных поведений. При прототипировании описания объектов можно составлять прямо в коде на Java, С++ или C#, но там всё довольно быстро запутается. Потом объекты выносят в базу данных, либо в XML или JSON конфиг. Это сильно помогает, ведь после редактирования конфигурации пересобирать код не требуется, и этим могут заниматься не только программисты, но и спецы по предмету (для игр это гейм-дизайнеры и контентщики). Когда разрастается команда либо количество объектов переходит какую-то черту, программисты пишут удобный редактор, который позволяет визуально править этот JSON-конфиг. В результате на выходе получается какой-то трудно поддерживаемый монстр.

Если вы не собираетесь нанимать множество людей которые вообще не умеют кодить, то можно попробовать пойти другим путём: описывать метаданные с помощью Domain Specific Language.

Liquibase — это система управления миграциями базы данных. Это вторая статья о Liquibase, на этот раз содержащая советы «боевого» использования системы. Для получения базовых сведений подойдет первая статья-перевод «Управление миграциями БД с Liquibase» (ссылка).

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

Вот 10 вещей, которые в определенный момент работы с Liquibase были для меня открытием.

1. Версионность приложения должна быть отражена в структуре папок миграций

Если вы не будете следовать этому правилу, файлы чейнджлогов быстро украсят папку миграций своим количеством и необычными именами.
На данный момент для себя я выработал оптимальную стратегию именования файлов и папок. Вот она:

/db-migrations
    /v-1.0
        /2013-03-02--01-initial-schema-import.xml
        /2013-03-02--02-core-data.xml
        /2013-03-04--01-notifications.xml
        /changelog-v.1.0-cumulative.xml
    /v-2.0
        ...
        /changelog-v.2.0-cumulative.xml
    /changelog.xml

Подробнее:

Не так давно мы начали внедрять Liquibase в качестве инструмента миграций схемы данных в большинстве наших проектов, новых и уже существующих. Система миграций схемы базы данных Liquibase хороша тем, что позволяет использовать системы контроля версий, VCS, (например, Git) для управления ревизиями базы данных приложения. Говоря более точно, VCS содержит описание изменений, необходимые для миграции схемы базы данных из одной ревизии в другую.

Хотя миграция схемы базы данных кажется довольно простой задачей изначально, задача становится сложнее после того, как появляется желание откатывать изменения схемы без ее создания заново.
Кроме схемы и операций DDL, Liquibase позволяет мигрировать данные приложения, с поддержкой наката изменений данных и их отката.

Основная проблема императивных языков программирования — их низкая приближенность к естественным языкам.

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

Например, у меня есть иерархия классов работы с заказами на продукты для клиентов:

// Клиент
class Customer {
    int inn
    String name
    String address
    String phone
}

// Клиенты
class Customers {
    Customer findByInn(inn)
    void add(Customer customer)
}

// Продукт
class Product {
    String article
    String name
    double price
}

// Продукты
class Products {
    Product findByArticle(article)
    void add(Product product)
}

// Заказ
class Order {
    int num
    Customer customer
    List<OrderDetail> details = []

    OrderDetail findByPos(pos)
    void add(OrderDetail detail)
}

// Товар заказа
class OrderDetail {
    int pos
    Product product
    def count = 1
    def getSum() { count * product.price }
}

// Заказы
class Orders {
    Order findByNum(num)
    void add(Order order)
}

Сама бизнес логика описания работы будет выглядеть вот так:

Всем привет.

Познакомившись с библиотекой MockMvc, я обнаружил "наличие отсутствия" её упоминаний на Хабре. Постараюсь восполнить этот пробел, тем более, что наше приложение ContactManager как раз нуждается в автоматизированном тестировании.

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

Меня давно волновал вопрос — на чём проще всего сделать веб приложение ява программисту неискушенному в веб разработке.

Меня смущали несколько вещей — во первых — регистрация пользователей, логин, права доступа и так далее. Не хотелось с этим много возиться. Решение здесь я нашел в Grails с плагином Spring Security.

Во вторых — хостинг. Если писать на Яве (а мне так комфортнее всего, я на Яве с 1996 года), то хостинг дорогой. Платить по 15-20 долларов в месяц за сайты-эксперименты не хотелось.

И вот, наконец я нашел решение. Это — Gaelyk. Groovy фреймворк для Google App Engine.

Чтобы понять что он даёт и как его использовать давайте посмотрим на простейший проект.

Простейший проект можно сделать скачав template project или воспользовавшись maven archetype

Однако же первый из них использует gradle, а не maven и оба используют стандартный groovy компилятор, а не экслипсовский, который позволяет не создавать стабы, и оба не создают пример работы с Google datastore

Поэтому я создал свой maven archetype. Давайте с его помощью и создадим Gaelyk проект:

Я недавно наткнулся на статью, описывающую простейший грувлет, позволяющий исполнить любой код на Groovy у Вас на сервере. Мне это показалось очень удобным для организации отладочного бэкдора.

Проблема в то, что грувлеты — это всё таки сервер, а у нас есть еще толстый клиент на Swing. Для него мне хотелось бы сделать нечто похожее, но встраивание какого нибудь embedded Jetty или Tomcat только для этого в клиент выглядело как то слишком.

По счастью, мне попалась на глаза и другая статья — про наличие в стандартной библиотеке Java простейшего веб сервера. Вот им то я и решил воспользоваться.

Предыстория

Мы разрабатываем небольшой портал на Grails и используем Spring Security для управления безопасностью. Плагин spring-security для Grails достаточно удобен и до последнего момента от него не требовалось сложной функциональности.

Недавно был обнаружен неприятный момент в использовании аннотаций @Secured для методов контроллеров Grails. Проблема заключается в том, что аннотации обрабатываются во время исполнения и преобразуются в набор правил для адресов «Адрес -> Набор требуемых ролей». Такой подход порождает ряд проблем в Grails-контроллерах в действиях сохранения/удаления данных, поскольку они отправляют данные на основной URL контроллера, то приходиться во-первых аннотировать контроллер, во вторых — невозможно задать различные ограничения для таких запросов.

Речь пойдёт о том, как решить проблему и приобрести хороший инструмент для управления правилами безопасности.

Groovy можно использовать по разному — для скриптов, для Grails, для быстрого написания прототипов, для DSL и т.д.

Меня же Groovy всегда привлекал как улучшенная Java. В самом деле — почти любой Java код будет валидным кодом Groovy — т.е. если не помнишь как что то делать в Groovy-way, можно всегда писать так, как принято в Java, а если помнишь — вот тебе и Closures, и удобные списки, и много других замечательных вещей.

Единственное, что мешало использовать Groovy для разработки production кода — отсутствие ошибок компиляции в большом числе случаев. Например если вызываешь несуществующий метод, обращаешься к несуществующей переменной и т.д.

Для многих Groovy фреймворков и библиотек это реально нужно (см. например работу с XML в Groovy), но если я пишу обычный код, мне это серьезно мешает.

Так вот, наконец в Groovy 2.0 появилась возможность сказать — проверяй в этом классе типы, существование методов и переменных!

Зачем?

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

Наверное, самыми простыми примерами таких сценариев, с которыми все сталкивались в том или ином виде, могут служить обычные пакетные файлы — bat или sh.

В одну телегу впрячь не можно
Коня и трепетную лань
                        А.С. Пушкин

Всем привет!

В данной заметке я хочу рассказать, как интегрировать язык Groovy в существующее JEE приложение на основе Maven. Выражаю благодарность Антону Щастному schaan за разрешение на использование исходного кода его проекта в качестве отправной точки. Поэтому данный топик можно считать продолжением его статьи Учимся готовить: Spring 3 MVC + Spring Security + Hibernate.

Начнем.

О грустном

Сидел я вчера на очередном интервью, грустил, что javax в меня какашками кидается, и слушал печальную историю соискателя о том, как он мучался пытаясь прикрутить сериализацию в JSON к модели на Java не имея ее исходников. От вида его попыток настроение мое не улучшилось.
Мы попробуем лучше, потому что, в отличие от него, мы знаем про Groovy.
Этот пост является более-менее продолжением вчерашнего. Им хотелось бы убить мешок зайцев:

1. Показать реальный пример мета-программирования на Groovy
2. Показать немного более навороченный способ работы с мета-классами
3. Показать работу с json-lib в Groovy
4. Рассказать про dependency management для бедных

Вместо посвящения

Всегда… Нет. Никогда не выходи в пургу пиши такой код ни для чего, кроме подобных забав.

_{Гийом — lead разработки языка Groovy}

Reflection во зло

Один мой друг — большой любитель головоломок. Всяких, и программистких в том числе. Вот его последняя забава:
Напишите нужный код в static initializer, чтобы assert перестал падать:

public class Test {
 static {
//Write some code here
 }

public static void main(String[] args) {
 Integer a = 20;
 Integer b = 20;
 assert (a + b == 60);
 }
}

Если вы решите попробовать, не забудьте включить assertions (флагом -ea).
Дальше будет решение и кое какие рассуждения на тему, так что если вы уже справились, или вам влом -смело под кат.

В одном из своих проектов мне понадобилось автоматизированно формировать документы договоров для клиентов. Договор представляет собой юридический документ длиной около 10 страниц и является шаблоном: в нужных местах подставляются данные конкретного клиента.

Задача

Первичные требования были такими:
В сложном стилизованном документе doc или docx вывести нужную информацию в помеченных местах.

В дальнейшем они были уточнены и расширены:

• В сложном стилизованном документе docx вывести данные в помеченных местах.
• Разметка вывода данных должна быть похожа на скриптлеты: ${}, <%%>, <%=%>.
• Данными для вывода могут быть объект. Нужна возможность обращения к полям.
• Для вывода использовать один из скриптовых языков: Groovy, JavaScript.
• Нужно иметь возможность выводить списки объектов в таблицы, в каждой ячейке отображая поля.

Имеющиеся решения

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

Jasper reports

В качестве шаблона использует файл xml-разметки *.jrxml. Файл разметки документа + данные (как из БД, так и Map параметров) отдаются процессору, который формирует любой из следующих форматов: PDF, XML, HTML, CSV, XLS, RTF, TXT.
Не устроило:

• Это не WYSIWYG, даже при наличии iReport — визуального средства формирования jrxml-файлов.
• Надо хорошо изучить JasperReports API, чтобы создать и стилизовать сложный шаблон.
• Не выводит в нужном формате. Можно и PDF, но хотелось бы иметь возможность потом поредактировать выходной документ.

Geb на практике

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

Browser.drive(driver: new InternetExplorerDriver()) {

    go "http://www.google.com"

    $('form', action:endsWith('/search')).q = 
                    'тестирование при помощи geb и spock'
    $('button', value:'Поиск').click()
    waitFor { $('#search') }
    assert $('#search').size() == 1
    assert $('#search').find('li.g a.l').size() > 0
    println "Первый результат: " + $('#res').find('li.g a.l', 0).text()
}.quit()

Мне кажется, у таких тестов высокая степень читаемости — неважно даже, какой это язык. Можно по такому вот образцу написать еще несколько подобных же тестов, не имея вообще никакого понятия о Geb, Groovy и о том, как это работает. Но для полного понимания немного углубимся в основы.

Не так давно я задавал вопрос в Groovy mail-list — есть ли какой-то устойчивый список вещей, которые надо избегать при написании высокогопроизводительного на Groovy. Среди прочих советов, один из главных разработчиков Groovy, Jochen «blackdrag» Theodorou указал, что в общем случае, зачастую использование конкретного типа при объявлении переменной (например, MyType var =… вместо def var = ...) может ухудшить производительсть из-за накладных расходов на проверку типов и, если нужно, их приведение.

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

Перед этим экспериментом будет полезно просмотреть следующую статью — groovy.codehaus.org/From+source+code+to+bytecode, где рассказывается про то, как по шагам исходный код на Groovy преобразуется в байткод JVM, а так же почитать какую-нибудь вводную статью в собственно байткод, например эту — www.ibm.com/developerworks/ibm/library/it-haggar_bytecode.

В какой-то момент проявилась одна заметная проблема, мешающая мне осуществить абсолютно 100% замену PHP на Groovy для веба без использования относительно тяжеловесного MVC-фреймворка Grails.

Это касается *.gsp страниц (Groovy Server Pages), представляющих собой html-страницы со вставками вида <%… %> с произвольным кодом на Groovy или Java, или на языке оригинала: "GSP means GroovyServer Pages, which is similar to JSP (JavaServer Pages)."

Зачем нужен deploy-скрипт

Grails-приложения очень легко собираются в WAR. Делается это так:

grails war

Помимо того, что WAR собирается, очень хочется этот WAR еще и установить на сервер. В нашем случае это Tomcat. Установка вручную требует некоторой возни:

1. Остановить сервер. Убить процесс, если он не остановился сам.
2. Удалить старые файлы приложения (на всякий случай)
3. Скопировать новый WAR на сервер. Иногда его нужно переименовывать (скажем, в ROOT.war)

В Maven эту работу может проделать, например, cargo plugin. Но с ним много приключений и настройки, причем он не особо учитывает особенности сервере.

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

Подключить полнотекстовый поиск в Grails — задача довольно легкая. Для этого используется плагин Searchable, который делает все сущности Grails-приложения индексируемыми. Searchable позволяет абстрагировать весь процесс индексирования и поиска. При этом сам плагин использует библиотеку Compass, которая следит за тем, чтобы при изменении объекта (т.е. при сохранении в БД) он автоматически переиндексировался. Сам по себе Compass по сути является довольно мощным средством «поискового ORM»: