вторник, 7 сентября 2010 г.

Eclipse, Gwt и Maven - Как сделать свою жизнь проще

Недавно у меня был research проект в котором мы изучали возможности GWT 2.x, а также изучали способы интеграции maven и GWT. Тремя самыми интересными решениями я хочу поделиться. Используемые компоненты:
  • Eclipse 3.6
  • GWT 2.0.4
  • Maven 2.2.1
  • gwt-maven-plugin 1.2.0

1. Hot redeploy клиентского кода


Как известно GWT из java кода клиентского интерфейса генерирует JS-код. Даже на небольших проектах такой цикл compile + deploy занимает 30+ секунд времени.

Путем небольших настроек maven проекта это время можно свести к нулю, обеспечив hot redeploy клиентского кода.

Как написано на официальном сайте GWT - работа над интеграцией GWT и Maven ведется, но еще не закончена. Основной проблемой в данный момент является расположение генерируемых файлов и web.xml. Поэтому для корректной работы hot redeploy необходимо достигнуть взаимопонимания между GWT, Maven и Eclipse.

пятница, 23 июля 2010 г.

Интегрируем Windows + Eclipse Helios + Git (GitHub)

  Совсем недавно вышла очередная верси Java IDE Eclipse под номером 3.6 и кодовым названием Helios. Одним из долгожданных нововведений стало включение поддержки распределенной системы версий Git в основной релиз Eclipse.

  Стоит отметить что поддержка Git для Eclipse была реализована намного раньше и включала в себя 2 модуля:
  • JGit - реализация Git на Java
  • EGit - собственно сам plugin для Eclipse
 Но включению этих модулей в Eclipse мешали лицензионные проблемы в несовместимости текущей лицензии J/EGit и Eclipse. Но за последнее время их удалось разрешить и EGit был включен в Eclipse Helios как Incubation проекты.

Некоторые Eclipse разработчики в своих блогах пишут что включение EGit в Eclipse стало поводом для миграции некоторых подроектов Eclipse c Svn/Cvs на Git. Вот и я решил попробовать новые возможности Git в маленьком R&D проекте. Но, как оказалось чтобы подружить Windows  + Eclipse + Git (GitHub) надо потратить немного времени на настройку и Gogglение. Я свое время уже потратил и расскажу о результатах.

  1. В первую очередь нам нужен Eclipse 3.6 Helios (или более новая версия). Скачать его можно на сайте Eclipse Foundation. Я использовал редакцию Eclipse IDE for Java EE Developers.
  2. Небходимо установить JGit и EGit, т.к. по умолчанию они не установлены. Для этого в Eclipse идет в  меню Help->Install New Software...
    1. В разделе Work With выбираем Helios
    2. В появившемся дереве плагинов выбираем раздел Collaboration
    3. Помечаем для установки модули JGit и EGit
    4. Нажимаем Finish
  3. Ставим Git
    1. Оффициальных сборок Git для Windows все еще нет
    2. На сайте проекта msysgit можно скачать специальную сборку для Windows.
    3. Я использовал вариант Git-1.7.0.2-preview20100309.exe 
    4. В процессе установки можно оставлять все опции в значениях по умолчанию
    5. После установки необходимо настроить 2 ключевых параметра
      1.   git config --global user.name "Pavel Vinogradov"
      2.   git config --global user.email pavel.vinogradov@email.com
    6. Также необходимо сгенерировать ssh ключ для работы с удаленными репозитариями по ssh
      1. для этого необходимо в проводнике Windows через контекстное меню открыть Git Bash
      2. В Git Bash нужно выполнить: ssh-keygen -C "pavel.vinogradov@nixdev.net" -t rsa
      3. Сгенерированный ключ будет храниться в вашем Windows профиле в папке .ssh
  4. Если у вас еще нет аккаунта на GitHub, тогда самое время его завести. GitHub на данный момент является самым популярным хостингом git репозитариев. Вы совершенно бесплатно можете хранить на нем до 300Mb кода в публичных репозитариях, а вот дальше придется платить.
    1. Создаем аккаунт
    2. Создаем проект с публичным репозитарием
    3. Загружаем публичный ключ из .ssh/id_rsa.pub
  5. Теперь в консоли мы можем не только работать с локальным git репозитарием, но и синхронизироваться с репозитарием на GitHub
  6. Соединяем проект Eclipse и GitHub
    1. Настраиваем ssh в Eclipse
      1. Eclipse в Windows самостоятельно работает с ssh, поэтому по умолчанию не видит ключей, которые мы сгененировали раннее. Это описано в Issue 104: SSH problem on Windows
      2. Идем в Window->Preferences->General->Network->SSH2 и в качестве Ssh Home указываем папку .ssh в вашей домашней директории
      3. После этого переходим на вкладку Key Management и выбираем Load Existing Key и указываем сгенерированный ключ
    2. Импорт проекта с GitHub
      1. Выбираем Import->Git->Projects from Git
      2. Вариант Clone
      3. В url указываем адрес репозиратрия: git@github.com:/.git
        1. В качестве протокола выбираем git+ssh
        2. В имени пользователя указываем git
      4. Eclipse автоматически воспользуется вашим ssh ключем для авторизации на GitHub
    3. Экспорт проекта на GitHub
      1. Выбираем Team->Push
      2. В качестве URLа назначения указываем адрес репозитраия проекта на GitHub
      3. Выбираем протокол git+ssh
  7. Профит. Работаем и радуемся.
Для дальнейшего ознакомления с EGit и Git рекомендую:

07.09.10: Небольшой бонус. Настройка Git Server на Vindows 7.

Книги/Рецензии: Том Демарко - Deadline. Роман об управлении проектами

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

Deadline. Роман об управлении проектами


Книга не имеет прямого отношения к разработке на каком-либо языке программирования. Она посвящена управлению разработчиками. Главной особенностью книги для меня является стиль изложения. Книга написана легким и нетехническим языком и представляет собой некий IT-роман.

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

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

понедельник, 31 мая 2010 г.

Agile. Гибкие методологии разработки. Мое выступление на конференции IzhDevelopers

С недавнего времени у нас в городе Ижевск регулярно проводятся встречи разработчиков ПО в виде мини-конференций. На прошлой неделе на этой встрече выступал я, темой выступления стали Agile и Scrum.

Сейчас Agile и Scrum это очень популярные слова в мире разработки ПО. При этом весь Agile подход состоит из набора рекомендаций, которым можно следовать, а можно и игнорировать. Поэтому результат получается разным. Кто-то получает "SRUM", а кто-то сплоченную команду разработчиков и повышение производительности.

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

К сожалению записи нет, но доступны слайды доклада: Agile. Гибкие методологии разработки

понедельник, 5 апреля 2010 г.

Лучшая первоапрельская шутка о Java

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

The Apache Software Foundation Receives Approval for Sale to Oracle Corporation

Если перевести на русский - Oracle купил всю интеллектуальную собственность ASF за 1.5 биллиона $. Напомню что в ASF входят - Apache, Ant, Maven. Perl, Subversion и очень много других популярных проектов.

Сам я увидел кросспост этой новости в другом блогt и датировано это было 4м апреля, поэтому даже повелся и пытался понять как это удалось Oraclу.

понедельник, 8 февраля 2010 г.

Что нового в Subversion 1.7

Основой для этого поста послужила презентация "Subversion in 2010 and Beyond", ссылка на которую будет приведена в конце текста.

В 2010 году планируется выпуск новой версии популярной систему управлениям версиями (VCS) Subversion 1.7. Многие люди пророчат скорую смерть централизованным системам управления версиями, но это не мешает другим людям использовать эти VCS а системам соответственно развиваться. Я расскажу вам что нового обещают разработчики в грядущем svn 1.7.

Использование HTTPv2:
На самом деле протокол HTTPv2 это полностью переписанный протокол общения svn-клиента и сервера по HTTP. Изначально для этого svn использовала WebDav/DeltaV.
Согласно заявлением разработчиков - этот метод доступа оказался сложным и не очень эффективным, потреблял много трафика и его сложно было расширять. В результате было принято решение реализовать HTTPv2.

Основные преимущества и характеристики:
- повышение производительности
- потенциал для дальнейшего развития
- лучшее кеширование на прокси-серверах

Working Copy - Next Generation (WC-NG):
Еще одно значительное улучшение в грядущем релизе. Сейчас svn хранит служебную информацию рабочей копии в каждой директории. Там хранится служебная информация, лог изменений, создаются файлы блокировки и многое другое. Управление этой метаинформацией в больших репозитариях очень неудобно и требует много ресурсов.

Поэтому было предложено решение, названное WC-NG. Основные преимущества нового формата:
- Для хранения метаинформации используется база данных SqlLite
- Вместо логов используются workqueues
- обратная совместимость

Это позволяет обеспечить:
- Более быстрые блокировки
- Возможность удалять папки в рабочей копии
- Снижение зависимости от файловых сиситем не различающий регистр букв в названиях файлов

Пока работа еще продолжается и еще многое предстоит сделать.

Obliterating:

Obliterating history - возможность внесения изменений в историю коммитов и полное удаление частей или конкретных версий из репозитария.

Основных применения два:
- уничтожить случайно закомиченный файл с приватными данными
- уничтожить устаревшую ветку чтобы освободить место на диске

Вы можете сказать что это уже было реализовано в виде svn del или svn merge, но это не так. Все изменения проводимые над репозитарием сохраняются в истории и могут быть восстановлены. Пользователь легко может получить версию репозитария до того как вы удалили файл с паролями, а удаление целой директории - сохраняет всю историю изменений и совсем не освобождает занимаемое место.

Планируется реализовать этот функционал в рамках svn клиента, а это значит что доступ на машину с репозитарием будет не нужен. При этом разработчики обещают позаботиться о жестком разгараничении прав - кому и что можно делать с историей и по умолчанию этот функционал будет отключен для всех пользователей.
Ктоме этого будет вестись лог изменений в истории. По этому логу можно будет узнать кто, когда и что менял в истории. Но вот откатить изменения возможности уже не будет.

SubversionJ:
Еще одна реализация протокола для тоступа к subversion серверу, в этот раз на Java. Ожидается что этот протокол позволит использовать современные Java EE контейнеры для хостинга svn-репозитария и сделает svn более привлекательным для java разработчиков. При этом автор обещает полную совместимость со стандарным протоколом, вплоть до повторения всех багов:). При этом разработчики нацелены на реализацию поддержки HTTPv2, а только потом WebDav.

Более подробно об этих новшествах вы можете послушать в презентации Subversion in 2010 and Beyond:

четверг, 7 января 2010 г.

Что нового в JDK 7 - Часть вторая

Вторая часть повествования о новом в JDK7, в первой части повествования о новинках в JDK 7 я говорил расширенной поддержке поллекций, автоматическом управлении ресурсами, diamond операторе и некоторых других новшествах.

Сейчас я расскажу о других новшествах (за исключением Closures, их я оставлю для 3ей части).

Новый сборщик мусора - Garbage First GC (“G1”)
Новый сборщик мусора предназначенный для работы в эру многопроцессорных систем с большим количеством оперативной памяти. Старый сборщик мусора работал со всей оперативной памяти и с ростом количества оперативной памяти его работа становилась все более и более заметна. Новый сборщик мусора должен решить эту проблему за счет разбиения памяти на маленькие регионы, внутри которых будет выполняться сборка мусора по специальным алгоритмам.

Это большое нововведение, которое ожидалось многими разработчиками. Вы можете прочитать подробно о технических аспектах реализации G1 в статье Garbage-First Garbage Collection. Те кому нетерпится побыстрее испытать его в деле - могут это сделать уже JDK 6 update 14 и старше с помощью ключей -XX:+UnlockExperimentalVMOptions -XX:+UseG1GC

JSR 308: Аннотации
В JDK 6 аннотации были ограничены применением только при декларации пременных, методов, пакетов. В JDK 7 эти ограничения будут сняты и их можно будет использовать для любых типов. Но при этом аннотации не могут быть использованы для изменения семантики языка.

JSR 294: Project Jigsaw - Модулизация
В недрах SUN ведется разработка проекта Jigsaw, который должен повысить модульность JDK. Во многом это повторение работы, выполненной в рамках разработки стандарта OSGI. В JDK7 будет реализовано новое ключевое слово module. С помощью этих возможностей планируется реализация профилей JDK (аналог профилей JEE), позволяющих адаптировать JDK для работы в различных уловиях. За счет уменьшения зависимостей планируется решить проблему размера JDK, время её старта а также размер потребляемой памяти.

JSR 203: NIO2 - New I/O API
В рамках работы над новым API для ввода/вывода планируется решить 3 основных задачи:
  • Новый API для работы с файловой системой, групповой работой с атрибутами, сокрытие API специфичного для конкретной файловой системы или операцинной системы.
  • Обновление API socket-channel, позволяющее работать с каналами без использования классов из java.net
  • Асинхронный ввод/вывод (самое главное)
Подробнее о NIO2 на странице проекта NIO Обновление API XML-стэка Обновление JAXP, JAXB, и JAX-WS API до последних стабильных версий


В третьей части я рассмотрю подробно замыкания (Closures).

среда, 2 декабря 2009 г.

Maven - Использование библиотек, которых нет в официальных репозитариях

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

Когда я переводил на Maven свой первый проект я столкнулся с большой проблемой - а где взять библиотеки, которые не представлены в официальном maven репозитарии, но от которых зависит проект? Честно признаться в первый момент меня этот вопрос поставил в тупик и пришлось призвать на помощь накомых maven-оводов.

Сначала немного теории. Для разрешения зависимостей в Maven используются репозитарии зависимостей, где размещены собранные версии различных библиотек и приложений. При этом в большинстве репозитариев все эти бобилиотеки содержат специальную мета-информацию о своих зависимостях, в формате понятно Maven. Поэтому вы можете в своем проекте сказать что ваше приложение использует API сервера jetty и Maven при сборке автоматическе выкачает сам jetty указанной версии и необходимые для его работы зависимоcти.

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

Самым большим конечно яляется основной репозитарий, там собрана огромная коллекция Java библиотек, она регуряно обновляется и имеет метаинформацию. Но там есть не все. В таких случая нужную библиотеку иногда можно найти в каком-то специализированном репозитарии, тут вам на помощь придет MVNRepository, Maven Search или другой поисковик Maven артифактов, таких сайтов сейчас не один десяток.

И все-же бывают случаи когда нужной библиотеки в репозитариях нет или вы используете какие либо библиотеки собственной разработки. Тут вам на помощь придет локальный и проектный/корпоративный репозитарий. Разберемся что это такое.

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

Настройки репозитария находятся в файле settings.xml, который хранится в домашней папке пользователя ($HOME/.m2 для Linux и $USER_HOME/.m2 для Windows.
Путь к локальному репозитарию задается переменной localRepository и по умолчанию репозитарий находится в папке .m2

Для установки собранных артифактов в локальный репозитарий необходимо выполнить команду mvn install. Для установки в локальный репозитарий кастомных библиотек необходимо использовать расширенный синтаксис поканды install:

mvn install:install-file -DgroupId=com.oracle -DartifactId=ojdbc -Dversion=11.1.0.7.0 -Dpackaging=jar -Dfile=ojdbc6.jar

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

Чтобы указать эту библиотеку в заивисмостях необходимо написать следующее:


<dependency>
<groupId>com.oracle</groupId>
<artifactId>ojdbc</artifactId>
<version>11.1.0.7.0</version>
</dependency>


Недостатки:
  • Репозитарий локален, другие разработчики не имею к нему доступ
  • На другом компьютере использовать нельзя
  • Проблемы на серверах автосборки
  • Нет централизованного места для хранения стабильных версий компонентов проекта
Плюсы:
  • Не требует настройки, администрирования
  • Прост в использовании

На одном из проектов мы некоторое время использовали локальные репозитарии для хранения custom-артифактов, в svn-репозитарии у нас была отдельная папка extlib и bat-файл, который при запуске деплоил все эти библиотеки в локальный репозитарий. Но проблемы с серверами автосборки и необходимость писать письмо на команду "Запустите batник перед сборкой" после каждого обновления библиотеки пересилило лень и мы развернули проектный Maven репозитарий.

Проектный / корпоративный репозитарий

В определенный момент функционал локального репозитария перестает устраивать и начинаются поиски более функционального решения. Тут ваиантов несколько:
  • расшарить папку с репозитарием, и настроить maven на остальных компьютерах на использование этого расшаренного репозитария
  • развернуть свой Maven репозитарий

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

Сейчас существует большое количество продуктов (как закрытых и клатных, так и Open Source), позволяющих развернуть свой Maven репозитарий. Приведу ссылки на некоторые: Apache Archiva, Artifactory, Nexus и другие.
Сейчас я не буду описывать настройку этих продуктов, скажу только что на развертывание Archiva я потрали часа 3.

Для того чтобы задеплоить кстомную библитоеку в репозитарий необходмо будет выполнить следующую команду:

mvn deploy:deploy-file -DgroupId=com.oracle -DartifactId=ojdbc -Dversion=11.1.0.7.0 -Dpackaging=jar -Dfile=ojdbc6.jar -DrepositoryId=archiva -Durl=http://mavenrep:8889/archiva/repository/oracle

Здесь мы указываем:
  • Группу библиотеки
  • Её идентификатор
  • Версию
  • Расположение на диске
  • Адрес репозитария

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


<repositories>
<repository>
<id>oracle</id>
<url>http://mavenrep:8889/archiva/repository/oracle</url>
<snapshots>
<enabled>false</enabled>
</snapshots>
</repository>
</repositories>


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

Maven репозитарии кроме всего проечего предлагают и некоторые дополнительные функции:
  • Прокси для вышестоящих репозитариев
  • Поиск по репозитарию
  • Права доступа
  • и другие

Заключение:

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

И один раз настроив репозитарий - вы решаете большинство проблем с управлением зависимостей и можете сосредоточиться на разработке.

среда, 25 ноября 2009 г.

Что нового в JDK 7 - Часть первая

На днях завершилась конференция Devoxx.com, где Mark Reinhold официально объявил - замыкания (closures) будут в JDK 7. Для многих замыкания были очень важным нововведением - с одной стороны они должны значительно расширить выразительность языка и привнести некоторую долю функционального программирования в Java. В вот с другой стороны это усложнит язык - и не все разработчики смогут в полной мере использовать эти возможности.

Но замыкания это отдельная тема для отдельной статьи, сейчас могу предложить только оригинальную статью Closures in JDK 7. Я постараюсь написать об этом позже.

А теперь вернемся к теме - А что-же еще нового в JDK 7, которая должна выйти в сентябре 2010 года?

Намнем с 7ми нововедений в языке, которые были реализованы в рамках проекта Coin (это перевод статьи New language features in Java 7):

вторник, 17 ноября 2009 г.

Что почитать Java разработчику - Блог №1 - Geek Explains

Я начинаю новую верию постов, в которых буду давать краткие аннонтации лучшим, на мой взгляд, блогам о Java-разработке.
И сегодня в первом выпуске я хочу вам представить блог Geek Explains.

Язык: английский
Автор: An Indian, a Software Engineer, a Web Addict, and a Blogger.
Тематика: Различные тонкие моменты и особенности Java
Частота обновления: Несколько раз в месяц
Оценка: 10/10

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

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