Groovy & Grails *

По ходу написания небольшого проекта для себя на Groovy & Grails встала острая необходимость в использовании все различных shell-скриптов. То сервер перезапустить, предварительно передеплоив только что созданный проект, то логи ото всюду собрать, то новые версии конфигов залить и прочее. По началу писал всё на bash-скриптах, но, в силу того, что использую его, помимо своего pet-проекта, крайне редко, каждый раз сталкивался с долгими поисками в интернетах необходимых функций, правил синтаксиса и т.д., что, несомненно, сильно тормозило разработку собственно самого проекта.

И так как с языком программирования Groovy уже хорошо ознакомился, решил писать на нём. Но разводить огромное количество *.groovy файлов очень не хотелось, а хотелось как раз наоборот — иметь один скрипт управления back-end'ом, который уже включал бы в себя все необходимые команды, что бы можно было как во «взрослой» консольной программе иметь возможность и историю команд посмотреть и цепочку последовательно выполняемых команд задать и легко добавить, при необходимости, новые. Это хотелка ещё появилась потому, что вспомнил я про cmd, которым некогда пользовался осваивая Python. Но оказалось что для Groovy такого cmd никто не написал (позже я даже понял почему), что и подтолкнуло меня к очередному велосипедостроению, а именно к созданию небольшого Фреймворка Cli приложений на Groovy.

Последнее время часто приходится работать с такой мощной возможностью Groovy как Compile-time AST Transformations.

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

def someVariable = new ConstantExpression("someValue");
def returnStatement = new ReturnStatement(
    new ConstructorCallExpression(
        ClassHelper.make(SomeCoolClass),
        new ArgumentListExpression(someVariable)
    )
);

До боли знакомые конструкции, не правда ли? Хотите, чтобы было вот так?

def someVariable = macro { "someValue" }
def returnStatement = macro { return new SomeCoolClass($v{ someVariable }) }

Или даже так?

def constructorCall = macro { new SomeCoolClass($v{ macro { "someValue" } }) }

В данной статье речь пойдёт о моём решении этой проблемы, максимально близком к родному решению Groovy — github.com/bsideup/MacroGroovy

Исторически сложилось, что Groovy берет много хорошего у Ruby. В первую очередь, конечно Grails (от Rails), но и Spock (от Spec) и даже где-то Gradle (от Buildr, хотя никто не признается). Сегодня я вам расскажу про еще одну толковую «спертую» штуку — web framework Ratpack.

Списан Ratpack с Sinatra, о котором много написано на Хабре, например вот тут.
На мой взгляд, главное преимущество Синатры — что он талантливый певец что это простейший в использовании и моментальный в разработке фреймворк. Создать несколько простых страниц, менять их и видеть результаты налету, и за несколько часов сваять достаточно нетривиальный сайт с динамическим контентом — это как раз то, для чего и был придуман Синатра. Это, своего рода, ответ «ожиревшим» Рельсам. Точно в такой же роли (ответа «ожиревшим» Грейлзам) Синатра и перекочевал в Груви.

Должен заметить, что на сей раз сообщество Груви были не первыми, кто передрал Синатру. Первыми были Scala, со своей Скалатрой (ага, ответ на «ожиревший» Play). Насколько я знаю, решение не делать название похожим на слух, а искать ассоциацию по смыслу, было принято в первую очередь, придя в ужас от звучания названия версии Скалы :)

Ratpack переводится на русский как Крысиная стая, и привязка к Синатре в том, что это тусовка, в которой тусовался Франк Синатра.

А причем тут Java?

Ну, тут, мне кажется, все ясно. В отличие от Руби, где когда-то был lightweight RoR, или от Груви с его Грейлз, в Джаве никогда не было мейнстримных «легковесных» фреймворков*. У нас есть либо громоздкие server-side component фреймворки типа JSF и Wicket, либо MVC фреймворки, которые, конечно, легче компонентных монстров, но все равно, требуют нагородить MVC для простейшей странички. Тут, конечно, я говорю о Spring MVC и Struts2. И всё это с жутко медленным циклом разработки «поменял слово? перезагрузи!». Бррр.

Как справедливо заметил antonarhipov, можно воспользоваться фреймворками для REST APIs, такими как Jersey и RESTlet, но это, на мой взгляд, абьюз.

В Джаве уже есть клон Синатры, который называется Spark, так почему бы не воспользоваться им? Я вижу для этого несколько причин:

• Freemarker или Velocity для темплейтинга. Первый, конечно, не так ужасен, как второй, но тоже не подарок. Оба хуже, чем Groovy Templates
• Hot Swap — клон Синатры должен уметь «поменял, F5, увидел». Если нет, то увы.
• Ratpack — прекрасная возможность плавно погрузиться в Груви. И я считаю, это главное преимущество.

Как всегда, преимущество Груви для программистов Джава — что они чувствуют себя как дома. 99% Java кода работает в Грувях без изменений, поэтому любой Груви фреймворк или инструмент может быть немедленно использован Java программистом.
Ситуация и с ratpack еще лучше — разработчики специально постарались, чтобы можно было писать на чистой Джаве, не задействуя Груви ни на одном этапе разработки. Таким образом вы можете начать не зная о Груви ничего, и потихоньку открывая для себя фичи Ratpack-а, начать писать на Груви. Один из примеров в этой статье будет написан 100% на Java. Кого на первом этапе не интересует всё это Грувийное шаманство, перекручивает прямо на последний пример. Остальные начинают здесь:

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 и о том, как это работает. Но для полного понимания немного углубимся в основы.