Java *

MongoDB — документо-ориентированная NoSQL СУБД, не требующая описания схемы таблиц. Больше о ней можно узнать на оф. сайте, а в данной статье я опишу пример использования MongoDB в Java EE 6 приложении.

В процессе работы на одним проектом, возникла необходимость разработать консольное приложение для удаленного доступа к системе. За подобное взялся впервые в таких масштабах, раньше все было на окошках или если консоль, то точно известно число, тип и порядок передаваемых параметров. А здесь возникла необходимость в большом количестве команд, каждая со своими параметрами, или вовсе без них, соответственно для обеспечения гибкости возникла потребность в парсере, переданных параметров.

Дабы не изобретать велосипед, решил взять готовую библиотеку. Выбор остановил на commons-cli, для нее удалось найти пару примеров и использование ее казалось не очень уж сложны.

Как оказалось примеров не так уж много и покрывают они только базовые потребности разработчика. Попробую заполнить этот пробел своими пояснениями.

Последнее время Play! framework набирает особую популярность среди Java разработчиков. Конечно все мы мечтали о таком фреймворке для Java и вот он наконец появился.

Одной из фишек фреймворка является компиляция на лету, эту фичу они взяли и eclipse(jdt). Благодаря этому отпадает нужда в IDE и всяких ant'ах. Можно программировать в простом текстовом редакторе типа Gedit. Хотелось бы поделится с вами портом Play! framework Textmate бандла для Gedit. Проект выложен на github'е и базируется на gmate, списке плагинов и тем делающий Gedit схожим с Textmate. Буду рад вашей помощи в добавлении новых возможностей.

P.S. Скоро будет добавлен ppa для пользователей ubuntu.

 

Эта статья о:

• О применении функционального стиля программирования в языке Java.
• О некоторых базовых паттернах для работы с коллекциями данных из функционального программирования в примерах на Java.
• Немного о библиотеке Google Collections.

Если вы программируете на языках Java, C#, C++, PHP, или любом другом ОО языке, хотели бы познакомиться с функциональным программированием, но не имеет возможности/желания изучать Haskell/Scala/Lisp/Python, — эта статья специально для вас.

Тем, кто знаком с функциональным программированием, но никогда не применял его в Java, думаю, это будет тоже интересно.

Хоббит или туда и обратно

Некоторое кол-во времени назад мне срочно потребовалось найти возможные способы получения переменных из js и браузера, чтобы передать их значение в моем приложении на java. К сожалению, на хабре данный вопрос не был раскрыт или возможно сила покинула меня и поиск дается уже не так легко.
Как бы то ни было сегодня я постараюсь в какой то мере пролить свет на данный вопрос. Итак приступим!

Play! framework набирает популярность и на Хабре уже есть следующие топики:
Отличный Java MVC фреймворк — Play Framework
‘Hello World’ tutorial — Ваше первое приложение на Play framework (Часть 1)
‘Hello World’ tutorial — Ваше первое приложение на Play framework (Часть 2)
Мои 5 любимых фишечек в Play Framework

Одна из замечательных возможностей Play! — развертывание приложения в облачную инфраструктуру App Engine от Google.

На приложения, которые исполняются в GAE накладываются довольно жесткие (по сравнению с обычными Play! приложениями) ограничения, в основном, это связано с модулем сохранения данных (JPA / Hibernate). Для того, чтобы приложение без проблем заработало в GAE следует отказаться от JPASupport/Model хелперов и использовать только базовые возможности JPA.
Альтернативой также может стать использование модуля Siena.

В данном топике я пошагово опишу процесс развертывания приложения Play! в Google AppEngine.
Процесс установки и использования описан применительно к ОС Linux, но существенных различий при использования других ОС возникнуть не должно.

«Вы счастливчики. Мы по три месяца жили в мешках из дерюги в грязных сараях. Мы вставали в шесть утра, стирали мешки, съедали по корке чёрствого хлеба и шли работать на мельницу, по 14 часов в день, с понедельника и до воскресенья, и когда мы возвращались домой, наш папа порол нас своим ремнем»
— Летающий цирк Монти Пайтона, Четыре йоркширца


Ленивая молодёжь.

Что может быть хорошего в тяжёлой работе?

Верный признак моего старения — моё ворчание и жалобы о «современной молодёжи» и о том, как не хотят или не могут больше делать ничего сложного.

“Есть ложь большая, есть маленькая, а есть статистика производительности Java.”

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

Многим понятно, что такие тесты это часть маркетинга. И те кто его заказывает, заказывают и результат. Но удивительность ситуации в том, что упрекнуть во лжи некого. Нельзя отказать в истинности тех тестов в которых Java на порядок уступает C#, ни тем тестам в которых Java превосходит С++ (не Си). Проблема в том, что такие тесты ориентированны в основном на начинающих разработчиков с целью переманить в свой стан побольше программистов и тем самым увеличить коммерческую привлекательность платформы для бизнеса. И в таких тестах намеренно упускаются сложные для понимания подробности работы динамической JIT компиляции и адаптивной оптимизации HotSpot, в которые начинающие программисты редко вдаются.

Чем это чревато? Банальным когнитивным диссонансом.

Groovy — объектно-ориентированный язык программирования разработанный для платформы Java как альтернатива языку Java с возможностями Python, Ruby и Smalltalk.

Groovy использует Java-подобный синтаксис с динамической компиляцией в JVM байт-код и напрямую работает с другим Java кодом и библиотеками. Язык может использоваться в любом Java проекте или как скриптовый язык.

Возможности Groovy (отличающие его от Java):

— Статическая и динамическая типизация
— Встроенный синтаксис для списков, ассоциативных массивов, массивов и регулярных выражений
— Замыкания
— Перегрузка операций

[http://ru.wikipedia.org/wiki/Groovy]

Более того, почти всегда java-код — это валидный groovy-код.

Думаю, почти каждый сталкивался с таким мнением: писать тесты сложно, все примеры написания тестов даны для простейших случаев, а в реальной жизни они не работают. У меня же за последние годы сложилось впечатление, что писать тесты — это очень просто, даже тривиально. Продолжаю начатое в первой части.

Думаю, почти каждый сталкивался с таким мнением: писать тесты сложно, все примеры написания тестов даны для простейших случаев, а в реальной жизни они не работают. У меня же за последние годы сложилось впечатление, что писать тесты — это очень просто, даже тривиально^*. Автор упомянутого выше комментария далее говорит, что неплохо было бы сделать пример сложного приложения и показать, как его тестировать. Попробую именно этим и заняться.

^*)Писать сами тесты — действительно элементарно. Создать инфраструктуру, позволяющую легко писать тесты — чуть сложнее.

Наверняка все знакомы с таким понятием как test-driven development(TDD). Наряду с ним также существует такое понятие, как data-driven testing(DDT, не в обиду Шевчуку) — техника написания тестов, при которой данные для тестов хранятся отдельно от самих тестов. Они могут храниться в базе данных, файле, генерироваться во время исполнения теста. Это очень удобно, так как один и тот же функционал тестируется на различных наборах данных, при этом добавление, удаление или изменение этих данных максимально упрощено.

В предыдущей статье я рассмотрел возможности JUnit-а. Там примерами такого рода подхода могут служить запускалки Parameterized и Theories, в обоих случаях один тест-класс может содержать только один такой параметризированный тест(в случае Parameterized несколько, но все они будут использовать одни и те же данные).

В этой статье я заострю внимание на тестовом фреймворке TestNG. Многие уже слышали это название, и перейдя на него, вряд ли желают вернуться к JUnit-у(хотя это только предположение).

Я часто и много работаю со Swing и, как следствие — очень часто приходится создавать
слушателей самых различных видов и форм. Однако некоторые виды встречаются чаще других,
и ниже я приведу свой рецепт автоматизации их создания.
Возможно, предложенный мной подход не оригинален, но в литературе я его не встречал.
UPD: спасибо pyatigil за ссылку на статью, в которой описывается аналогичный подход, но немного в другом стиле.

Совсем недавно, в статье Сервлеты — маленький трюк с Reflection, разбирался прием, с помощью которого можно получить url вида:
host/servletName/methodName.

Если пойти дальше, то с помощью Reflection можно реализовать конструкцию следующего вида:


Где, у нас в проекте есть несколько классов контроллеров, и у каждого из них свои действия. А самое главное, в методы контроллеров мы можем передавать параметры из URI. Например:
host/servletName/projects/add?title=hello

Любите ли вы GWT так, как люблю его я? Недавно возникла задача, повесить Sonar на проект, где используется GWT. Проблема возникла в тот момент, когда врубается Clover. Подробности этой истории под катом.

Зачем это надо?

В enterprise-разработке часто бывает необходимо отслеживать процесс редактирования каких-нибудь таблиц.
Скажем, завели у вас документ в системе. Потом кто-то поменял ему серию. Потом номер. Потом сменил тип с паспорта РФ на загран. паспорт Германии. Хотелось бы иметь возможность отследить историю изменений и, скажем, настучать по шапке пользователю, который совершил ошибку.

На прошлогодней конференции JavaOne в Сан-Франциско компания Oracle анонсировала технологию JavaFX 2.0. А несколько дней назад мир увидел Java FX 2.0 Beta. JavaFX — это естественный шаг в эволюционном развитии клиентской платформы Java. Технология обеспечивает разработчиков кросс-платформенным инструментом для создания функционально насыщенных и привлекательных приложений.
Встроенная в технологию Java, JavaFX предлагает богатый графический и медийный API с поддержкой аппаратных графических ускорителей и большой выбор новых компонент: элементов управления, графиков, мультимедиа и встроенного браузера.
Из очевидных плюсов JavaFX 2.0 — возможность создания приложений без изучения новых технологий, применение привычных средств разработки и, конечно, все традиционные плюсы Java. Для корпораций — использование технологии Java на серверной и клиентской сторонах снизит интеграционные риски.
Из минусов: к сожалению, бета версия вышла только для Windows, но к релизу состав поддерживаемых платформ расширится.

Но лучше один раз увидеть, чем 100 раз услышать.
Давайте попробуем вместе написать панель задач с кнопками в стиле Mac

Сегодня все большую популярность приобретает test-driven development(TDD), техника разработки ПО, при которой сначала пишется тест на определенный функционал, а затем пишется реализация этого функционала. На практике все, конечно же, не настолько идеально, но в результате код не только написан и протестирован, но тесты как бы неявно задают требования к функционалу, а также показывают пример использования этого функционала.

Итак, техника довольно понятна, но встает вопрос, что использовать для написания этих самых тестов? В этой и других статьях я хотел бы поделиться своим опытом в использовании различных инструментов и техник для тестирования кода в Java.

Ну и начну с, пожалуй, самого известного, а потому и самого используемого фреймворка для тестирования — JUnit. Используется он в двух вариантах JUnit 3 и JUnit 4. Рассмотрю обе версии, так как в старых проектах до сих пор используется 3-я, которая поддерживает Java 1.4.

Я не претендую на автора каких-либо оригинальных идей, и возможно многим все, о чем будет рассказано в статье, знакомо. Но если вам все еще интересно, то добро пожаловать под кат.

Только вернулся с JeeConf о котором уже ранее писал — и очень хочется поделиться впечатлениями. Если кратко — было очень круто — ну а чуть подробней — под катом