hashMem.com – сервис заметок для разрабочиков, написанный на Grails

Written by fedor.belov on . Posted in Uncategorized No Comments

Всем привет. На правах рекламы хочу рассказать о сервисе, который я делаю в свободное время. Начнем чуть-чуть из далека. Когда-то давно я попробовал работать во всех трех популярных средах разработки. После Eclipse Intellij IDEA кажется просто небом – продуманный, лаконичный интерфейс, возможность делать большую часть действий с клавиатуры – что еще нужно? Необходимо открыть класс? ctrl-n – часть названия – enter. Необходимо открыть файл? Ну, вы знаете…

Несколько лет назад мне пришла идея хранить таким же образом короткую текстовую информацию (заметки, закладки и т.д.)? Ввел часть названия (в терминологии hashMem “ключа”) – получил данные. На этой простой идее родился hashMem.com. После этого возник вопрос “Зачем всегда открывать сайт? Я же могу все это делать из браузера” и я написал два плагина – для Chrome и для FireFox. В итоге я практически не захожу на сайт, а делаю все (открываю и добавляю заметки) через плагин для Chrome. Ну, и, наконец, последний вопрос – “А почему бы не добавлять заметки прямо из Intellij IDEA?”. Как вы догадались, плагин для сред разработки от Jetbrains на подходе…

Итого:

  • сейчас у меня 233 заметки (большая часть из них закладки)
  • я каждый день использую hashMem.com в работе
  • 90% времени я использую плагин для Chrome
  • на добавление закладки я трачу 5-7 секунд
  • на открытие заметки – 3-5 секунд

Сначала я думал на этом заработать немного денег. Но убедить народ в гениальности своей идеи оказалось не так уж просто =) Так что я решил сделать сервис полностью бесплатным.

Если вы используете в работе Intellij IDEA и стараетесь использовать больше клавиатуру, чем мышь, то, вполне возможно, hashMem.com я написал для вас!

Читать дальше...



Короткое интервью Graeme Rocher’a

Written by fedor.belov on . Posted in Интересное за последнее время No Comments

Прочитал тут недавно короткое, но при этом довольно интересное интервью Graeme Rocher’a. Из него можно узнать, что:

  1. Перед Grails 3.0 будет Grails 2.4, в котором обновят Spring до версии 4.0 и Groovy до 2.2
  2. Первая версия Grails 3.0 планируется в следующем году
  3. Grails входит в тройку самых популярных фреймворков на JVM (остальные два, я так полагаю, Spring и Play)

Читать дальше...



Grails: все за и против

Written by fedor.belov on . Posted in Grails 3 Comments

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

Итак, начнем мы с против.

  1. Долгие выпуски новых версий Grails. Очень грустно, но приходится признать, что Grails пишут довольно медленно. Последняя major версия (2.2.0) вышла почти 9 месяцев назад! Конечно, в 2.3.0 будет много новых вкусностей, но 3/4 года это очень много. А сколько они будут писать версию 3.0?
  2. Небольшое комьюнити. Я стараюсь использовать Grails по максимуму. Основной функционал фреймворка уже давно вылизан. Но довольно часто встречаются настолько сложно воспроизводимые баги, что надеяться не на кого – приходится самому разбираться и править (это по-большей части связано с тем, что я стараюсь писать различные плагины для Grails). Это довольно сильно тормозит процесс разработки. Я уверен, что эта проблема решается только ростом комьюнити
  3. Система сборки. Почему-то система сборки у меня вызывает всегда очень негативные эмоции. Сюда я бы отнес мой отвратительный опыт с maven’ом (IDEA, почему-то очень не любит такую связку) и постоянные проблемы при обновлении зависимостей / плагинов (хотя это я поборол – теперь при любом изменении в BuildConfig.groovy я вызываю grails refresh-dependencies).
  4. Нет нужных мне плагинов. Например, liveralod или же нормального compass компялитора. Конечно, можно жить и без этого. Но всегда хочется лучшего =)
  5. Groovy. Groovy (пока что) медленнее Java. Подсознательно это приходится всегда учитывать. Так что сильно нагруженные проекты я бы не советовал писать на Grails (хотя наш сервис с 8млн показами в сутки нормально живет).

Итак, что же Grails может противопоставить всем этим «против»?

  1. Convention over configuration. Это очень большой бонус Grails’у. Вы открываете чужой проект и вы уже знаете, что где лежит, как запускается и как работает. К тому же, ваш код выглядит чище и не захламлен лишними аннотациями, например.
  2. Плагины. Второй огромный плюс Grails’у. Много уже было решено раньше. Часто нужно всего-лишь поискать правильный плагин. Нужны уведомления на почту? Пожалуйста. Компиляция less? Есть такое. Управление статическими ресерсами? NoSQL? Безопасность?…
  3. Auto reloading (grails run-app). Третья киллер фича. Часто (но не всегда!) вам не требуется перезапускать приложение, чтобы протестировать изменения. Просто пишите, f5 и готово. Конечно, иногда auto reloading не работает, иногда глючит, но я все-равно это огромный time saver.
  4. Groovy. Groovy замечательный и мощный язык. Он позволяет писать чистый, читабельный и красивый код. Конечно, тут необходимо следовать правильным соглашениям, чтобы не превратить проект в макаронную фабрику. Возможно, этот пункт отпадет с выходом Java 8, но пока это большущий плюс.

В конечном счете решать вам, писать на Grails или же на каком-то другом фреймворке. Могу сказать про себя – я перешел со Spring MVC и ни разу об этом не пожалел – обратно я не вернусь. Для написания MVC приложений я считаю Grails одним из лучших фреймворков.

ps
Через 2-3 дня чтения книг я уже мог нормально работать. Так что переход со Spring’а очень прост и не требует больших усилий. Время, потраченное на изучение нового фреймворка, вы уже отобьете через месяц работы.

Читать дальше...



Grails asset-pipeline plugin

Written by fedor.belov on . Posted in Grails 4 Comments

Прошло уже очень много времени с момента последнего поста. Связано это с высокой загруженностью и с тем фактом, что пришло лето. Кстати, такое впечатление, что лето наступило и у разработчиков Grails – они все так и не выпустили версию 2.3. Тем не менее один человек трудится, как пчела. Похоже на замену resources плагину приходит asset-pipeline плагин. Как автор справедливо утверждает, этот плагин имеет ряд преимуществ перед resources плагином:

  1. Компиляция при сборке, а не при запуске – на мой взгляд это самый большой выигрыш перед resources плагином. Во-первых, это уменьшает время запуска приложения. Во-вторых, для компиляции некоторых файлов (например .less или .sass) могут потребоваться специфические библиотеки, которые не нужны в конечном war файле. В-третьих, в момент компиляции могут возникнуть ошибки. Гораздо лучше, если эти ошибки возникнут при сборке приложения, а не при запуске
  2. Более быстрая работа в Development mode
  3. Подключение в модуль всего содержимого папки, а не только отдельных файлов

Лично для меня главное преимущество asset-pipeline – это то, что он очень активно развивается (в отличие от resources плагина, который, фактически, мертв). Достаточно взглянуть на твит-ленту пользователя Grails Plugins, чтобы понять, о чем я говорю. Надеюсь, автор будет продолжать в том же духе.

Читать дальше...



Grails snippet. Получаем доступ к grailsApplication.

Written by fedor.belov on . Posted in Grails snippet No Comments

Зачастую требуется получить доступ к объекту grailsApplication в статическом контексте или же в обычном POGO объекте (не Spring бине). Раньше для этого служили различные *Holder классы (ApplicationHolder, ConfigurationHolder и т.д.), но с версии 2.0 эти классы помечены как deprecated. Однако, начиная с той же версии, появился замечательный класс, который объединяет все устаревшие Holder’ы – grails.util.Holders. Советую вам потратить 5 минут и изучить методы этого очень полезного класса.

Читать дальше...



Grails и Gradle

Written by fedor.belov on . Posted in Grails 1 Comment

Grails – это в первую очередь фреймворк для построения Web приложений. Но исторически так сложилось, что часть функционала Grails скорее можно отнести к какой-нибудь системе сборки, а не к Web фреймворку. Grails:

  • Управляет зависимостями (используя Ivy или Maven, начиная с версии 2.3)
  • Собирает исходники в war файл (grails war)
  • Даже может запустить собранный war во встроенном контейнере (grails run-war)

Проблемы начинаются, когда вы хотите использовать Grails проект с полноценной системой сборки. Официальная поддержка Maven’а все-таки есть. Но Maven, на наш взгляд, морально устаревает. Сейчас в нашей компании стараются собирать большинство проектов, используя Gradle. Не так давно мы переводили наш большой Grails проект с Maven’а на Gradle. Хотя официальной поддержки Gradle, насколько я знаю, пока еще нет, наш проект сейчас отлично собирается Gradle’ом.

Итак, нам нужно уметь собирать Grails проект при помощи Gradle. Как мы можем поступить? Насколько я знаю, существуют два Gradle плагина, которые позволяют это делать – grails-gradle-plugin и gradle-grails-wrapper. Давайте рассмотрим, что между ними общего и что их различает:

  1. Оба плагина добавляют команды grails-* для сборки Grails проекта
  2. На самом деле сборка все так же осуществляется при помощи Grails — например, команда gradle grails-war вызовет сборщик, используемый командой grails war
  3. Оба плагина не требуют установленного на компьютере Grails – для сборки проекта необходим только Gradle
  4. Основное отличие в плагинах – плагин gradle-grails-wrapper использует Grails для управления зависимостями. Это имеет свои преимущества и недостатки. Например, в этом случае вам не придется переносить зависимости из BuildConfig.groovy, но у вас все так же останутся проблемы со SNAPSHOT зависимостями и не будет поддержки многомодульной сборки в Gradle (project зависимости). Плагин grails-gradle-plugin, наоборот, использует Gradle для управления зависимостями. Таким образом, вам придется перенести все зависимости из BuildConfig.groovy в файл build.gradle

Как видите, различие всего одно, но зато очень значительное. Для сборки нашего проекта мы выбрали gradle-grails-wrapper. Почему?

  • Он простой. Все что делает плагин – скачивает необходимый Grails для сборки и собирает проект, используя код Grails’а
  • Следствие из предыдущего пункта – у вас скорее всего не возникнет проблем при сборке. Если ваш проект собирается Grails’ом, то он так же будет собран и Gradle’ом. Пока мы пытались интегрировать grails-gradle-plugin в наш проект, у нас была куча проблем, в основном из-за некорректной работы с Logback плагином.
  • Вы по-прежнему можете собирать ваш проект, используя Grails. Это очень удобно в процессе разработки, т.к. IDE хорошо знает как работать с обычным Grails проектом, а вот Grails проект, в котором зависимости управляются через Gradle ей совсем непонятен

Что в итоге?

  1. Grails проект можно собирать Gradle’ом.
  2. grails-gradle-plugin пытается перенести часть функций сборки на Gradle, но получается это не всегда хорошо, а главное, непонятна целесообразность такого похода.
  3. gradle-grails-wrapper – очень простой, рабочий плагин, на котором мы остановились и, думаю, будем использовать в дальнейшем.

Читать дальше...



Grails и SPANSHOT зависимости

Written by fedor.belov on . Posted in Grails 1 Comment

Часто бывает необходимо забирать всегда последнюю версию зависимости из репозитория (а не из кеша, как это обычно бывает). Grails учитывает эту ситуацию – вы можете добавить к версии зависимости SNAPSHOT или явно указать, что зависимость нужно всегда брать из репозитория – changing = true. Все это очень подробно и красочно расписано в документации. Один момент – это не работает. Или работает не всегда. Эту проблему уже правили, но, похоже, не до конца. Судя по всему, эта проблема будет кардинально решена в версии 2.3 – Ivy заменят на Aether. А пока совет один – старайтесь не использовать SNAPSHOT зависимости в своих проектах.

Читать дальше...



Grails snippet. Как правильно исключить библиотеку из проекта?

Written by fedor.belov on . Posted in Grails snippet No Comments

Иногда бывает необходимо исключить библиотеку из проекта. Хорошо, если от нее зависит только один плагин/библиотека – можно явно указать excludes для данной зависимости. Но что делать, если у вас проект большой, и от этой библиотеки зависят 4-5 других зависимостей? Для каждой зависимости указывать excludes? Не самое красивое решение. Как эта проблема решается в Gradle / Ivy / Maven отлично описано в этой статье (другая ссылка, если не работает). Но как это сделать в Grails? Недавно я задал такой же вопрос в Grails Mailing List. Оказалось, что это очень просто сделать, используя метод excludes в блоке inherits("global") { ... } (хотя из документации, лично мне, это абсолютно не очевидно).
Например,

grails.project.dependency.resolution = {
    inherits("global") {
        //globally exclude commons-logging
        excludes "commons-logging"
    }
}

В каких случаях данный функционал может вам потребоваться? Например, при перенаправлении сообщений из commons-logging в slf4j.

Читать дальше...



Куда движется Grails?

Written by fedor.belov on . Posted in Grails No Comments

Последняя версия Grails вышла уже довольно давно. Сейчас мы ждем Grails 2.3, в которой будет добавлено несколько классных плюшек (Async API, улучшенное REST API). Но что дальше? Не так давно Peter Ledbrook написал довольно бестолковый по содержанию (на мой взгляд), но очень резонансный пост Where next for Grails? Радует, что сообществу не безразлично будущее Grails – множество интересных комментариев, интересное видение от David Dawson – хорошая пища для размышления разработчикам Grails.
Сегодня Graeme Rocher ответил Peter’у и всем интересующимся, что скорее всего будет в версии 3.0 (в целом он подтвердил все тезисы, сказанные в докладе Road to Grails 3.0).
Если вам не безразлично будущее Grails вы все еще можете написать свое видении в комментариях к постам Peter Ledbrook’а или Graeme Rocher’а

Читать дальше...



Интересное за последнее время. 04/04/13

Written by fedor.belov on . Posted in Интересное за последнее время No Comments

Давно уже ничего мы не писали о Grails. Конечно, за это время сообщество сгенерировало огромный поток информации. Попробуем выбрать самое интересное:

  • Буквально вчера анонсировали проект GProf – простенький профайлер для Groovy кода. Думаю, довольно полезная вещь, если вы хотите ускорить ваши сервисные компоненты… Хотя найти узкие места в Grails-приложении таким инструментом будет, все-таки, сложно.
  • Барт Беквис создает плагин за плагином. Последний позволяет интегрировать Grails с Netty. Но его пост привлек мое внимание не по этой причине – в нем содержится ссылка на сравнение фреймворков по производительности. Вопрос, конечно, холиварный, но очень интересный.
  • Вам знакома проблема, когда один проект на Grails 2.0.3, а второй на Grails 2.2.0? Вы запускаете `grails run-app` и получаете предложение обновить версию Grails в приложении (чего делать, естественно, совсем не нужно). Решить эту проблему помогает Grails Wrapper, о котором очень подробно рассказано здесь. Лично мне не приходилось использовать Grails Wrapper (потому что я один раз уделил 5 минут на знакомство с GVM tool), но из статьи получается, что чтобы создать Wrapper вам нужен Grails той версии, Wrapper которой вы хотите получить. Это… печально.
  • А вы знаете разницу между split и tokenize? Короткое и интересное сравнение.
  • Полезная заметка про буфер обмена в Intellij IDEA – мне очень часто помогает в работе. А вот к переключению между недавно измененными файлами я себе приучить еще не успел.
  • И, напоследок, – самое-самое: Грэм Рочер знакомит нас с новинками Grails 2.3. Среди них:

    1. Управление зависимостями через Aether.
    2. Исполнение команд Grails отдельно от кода приложения.
    3. Улучшенная поддержка асинхронного кода.

На этой мажорной ноте мы и закончим. До новых встреч!

Читать дальше...