FLEXible блог

Напоролся сегодня на такой Exception. Его генерирует Grape. Причину не знаю, но знаю решение:

:::: WARNINGS
        problem while listing resources in file:C:/Users/R/.m2/repository/org/codehaus/groovy/
modules/http-builder/http-builder/ with localm2:

          java.lang.NullPointerException null

        problem while listing resources in file:C:/Users/R/.m2/repository/org/codehaus/groovy/
modules/http-builder/http-builder/ with localm2:

          java.lang.NullPointerException null

        problem while listing resources in file:C:/Users/R/.m2/repository/org/codehaus/groovy/
groovy/ with localm2:

          java.lang.NullPointerException null

        problem while listing resources in file:C:/Users/R/.m2/repository/org/codehaus/groovy/
groovy/ with localm2:

          java.lang.NullPointerException null

                [NOT FOUND  ] commons-collections#commons-collections;3.2.1!commons-collections.jar (2ms)

        ==== localm2: tried

          file:C:\Users\R/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar
:: USE VERBOSE OR DEBUG MESSAGE LEVEL FOR MORE DETAILS

Правильное решение скрыто во тьме веков, а быстрое решение - скачать файл, например, отсюда и положить его к вам в локальный репозитарий m2, в моём случае путь к файлу ~/.m2/repository/commons-collections/commons-collections/3.2.1/commons-collections-3.2.1.jar. Мне этот файл был нужен для поддержки HttpBuilder в Groovy. Такие дела.

Для Grails есть замечательный плагин console. Один минус у него: при структуре проекта чуть сложнее Hello World, когда в проекте десятки или сотни пакейджей, например — надо обязательно осуществлять импорт доменных классов вручную. А это — лишнее время, причём тратится оно не разово, а раз в рестарт сервера.

К сожалению, добраться до GroovyShell, в котором выполняется введённый пользователем код — кажется, нереально, Хотя силён и могуч Groovy, но вроде бы там даже кложеров не используется, которые было бы можно заменить. Тогда я пошёл другим путём, через фильтры.

Производительность Grails

Рано или поздно, любой программист слышит, что производительность инструмента, который он использует или инструмента, который он сделал — невысока. Будь то какой-нибудь синтетический бенчмарк, или сложные распределённые вычисления. Будь то работа с базой данных или с файлами.

Все хотят максимальной производительности! Всегда! Немедленно!

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

Но насколько серьёзны потери? Насколько их можно избежать? Как можно выжать из проекта побольше производительности? Давайте посмотрим на примере Grails.

Я уже писал, что считаю Groovy одним из самых перспективных языков программирования и даже приводил тому примеры.

Но этот разговор не имеет ни начала ни конца, и интересные примеры всегда могут придумываться «по ходу дела». Так, например, подвернулся такой код на Groovy:

string = 'hippopotamus'
assert string - 'hippo' - 'mus' + 'to' == 'potato'

Считаю, что это просто гениально :) Когда-то давным-давно, когда я ещё учился в школе и ничего толком программировать не умел, я ушёл с Basic к Pascal из-за более качественной работы со строками. Ах, если бы в то время существовали такие прикольные штуки, как Groovy или хотя бы Java!

Моё первое знакомство с 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.

Около пары месяцев назад свет увидела IDEA X, десятая версия IDEA. Я, как обычно, довольно пристально следил за развитием любимой IDE: как у PHPStorm 2.0 (после, на мой взгляд, откровенно провального PHPStorm 1), так и полноценной IDEA X. У PHPStorm я без зазрения совести пользуюсь вечным trial, так как пользоваться честно купленной IDEA для редактирования PHP проектов неудобно: она и тормозит посильнее, и многообразие пунктов меню (которые все равно не работают при редактировании PHP файлов) мешается.

А вот вышедшая IDEA X была для меня, мягко говоря, разочарованием. Во-первых, я не заметил никаких отличий от EAP, которыми пользовался. Постоянно мигающая красная лампочка, медленная и неотзывчивая работа. Быстрее стало только индексирование и запуск программы, а в целом производительность ухудшилась.

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

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

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