Spring 2.0 release vs. JetBrains announces
Произошло! Два значительных, на мой взгляд, события призошло.
Первое (в порядке хронологическом) – выход двух продуктов одной очень мной уважаемой компании – новой, шестой, версии всеми нами горячо любимой IntelliJ IDEA, а так же первой версии интегрированной среды командной разработки TeamCity (этакого Continuous Integration инструмента в видении разработчиков JetBrains).
Второе (в том же порядке, но не по значимости) – релиз второй версии самого популярного на сегодняшний день full-stack Java/Java EE application (как это сказать по-русски?) фреймворка – Spring. Даже не знаю, какое из них меня порадовало больше.
JetBrains announces
Первым делом удалось попробовать новую версию ИДЕИ. Честно говоря, того чего я ожидал я и увидел – много нового, вкусного и интересного, но продукт не готов к использованию на сто процентов, хотя все претензии чисто субъективные, а недоделки наверно косметические. Первым делом «лег» в том числе и плагин интеграции TestNG (к счастью это уже поправили), в чем разработчики IDEA конечно никак не виноваты, просто им очередной раз пришлось изменить public API (к чему, после использования Tapestry, относишься как к само собой разумеющемуся). Затем, диалоговые окошки никак не хотят сохранять свой размер при их закрытии, приходится их постоянно растягивать, что бы не потеряться на своих 1280×1024. А вот к новому виду окна сохранения изменений в SCM наверно придется довольно долго привыкать. Ну почему бы не дать пользователям выбирать самим между старым-и-привычным и новым-но-прогрессивным? Почему опять решили все за нас (к чему после долгих лет проведенных в Беларуси относишься как к само собой разумеющемуся)? Специальных замеров не проводил, но по ощущениям пятая версия работала пошустрее. Остается ждать того, что будет после и наслаждаться тем, что было до того.
Впечатления от использования TeamCity совсем другие – того чего я ожидал, я не нашел. Вместо этого я увидел очень удобный в установке, настройке и использовании продукт. Ничего лишнего, лишь то, что надо для автоматизации сборки, тестирования и анализа исходного кода проекта. Очень порадовало разделение системы на подсистему управления сборками и на агенты, непосредственно их выполняющих. Причем последних агентов может быть любое количество (все их множество ласково называется Build Grid), ограниченное лишь требованиями проекта, возможностями организации да фантазией разработчиков. Каждый из агентов выполняется в своей собственной среде, характеризующейся набором системных переменных и переменных среды, версией JDK и т.д. При необходимости выполнения сборки (по расписанию, при изменении кода в SCM или же инициированной вручную) система выбирает одного из свободных в данный момент агентов, параметры среды которого удовлетворяют требованиям сборки, и инициирует сам процесс.
Кроме этого система предлагает много всяких деликатесов, типа инспекций кода на стороне сервера, code coverage анализа, отложенного сохранения в SCM и удаленного запуска сборки, а так же интеграция с IDEA. Ну и, конечно же, сам интерфейс системы выполнен в лучших традициях компании.
Spring 2.0 release
В отличие от предыдущих событий, выход второго релиза Spring не был таким неожиданным, но был весьма ожидаемым – настолько, что в первые часы после планируемого выхода (где-то с 15:00 и до 18:00) попасть на страницу проекта, а тем более скачать сами исходники, было просто невозможно. К счастью ажиотаж уже спал и новая версии продукта готова к скачиванию и использованию.
Изменен

Dmitry Jemerov заявил:
Добавлено 7 октября, 2006 в 09:04По поводу IntelliJ IDEA 6.
Во-первых, TestNG плагин (как и многие другие) использует не только наше OpenAPI, но и закрытые классы из реализации продукта. Естественно, что мы даже не пытаемся обеспечивать совместимость их между версиями.
Во-вторых, несохранение размера диалоговых окошек - это баг, посаженный в последний момент перед релизом. Он будет исправлен в ближайшем багфикс-апдейте.
В-третьих, появление фичи changelists привело к тому, что существенную часть начинки version control интеграции пришлось переписать. Поэтому просьба “дать возможность выбрать” реально означает то, что нам пришлось бы сначала написать новый интерфейс, сделанный так, как мы считаем наиболее удобным, а потом ещё раз переписать старый интерфейс поверх новой начинки. И это отняло бы время от разработки и доведения до хорошего состояния других фич продукта.
lucker (чел в теме) заявил:
Добавлено 9 октября, 2006 в 08:50По поводу TestNG - к счастью брешь уже устранили - жить становится легче. Что там падало, я не выяснял, но тенденция ясна. Если разработчики плагинов используют закрытые классы, значит им не хватает функциональности, заложенной в открытое АПИ.
По-поводу баги перед релизом - выглядит очень подозрительно получить такой подарок от компании-произодителя TeamCity….
Оценить все прелести фичи changelists пока не получилось, но надеюсь, что оно того стоит.
В любом случае, Дмитрий, спасибо за работу над лучшим, по моему мнению, Java-продуктом эпохи.
Alexey Efimov заявил:
Добавлено 9 октября, 2006 в 10:47На самом деле Changes достаточно удобен. Я по началу тоже ругался и просил вернуть Ctrl+K взад. Но потом Ctrl+K вернули, но я стал пользовать этим окошком. Удобство в нем следуюещее. Вы можете пемещать изменения в сеты - тем самым групируя их по комиту в VCS. Например, если у вас трекер используется и вы корпите над багой TTT-123, а тут прибегают и говорят зафикси срочно TTT-321. Берете, делаете из текущих изменений Change List - TTT-123 и работает над новой багой. Потом Ctrl+K и комит будет только по новым изменениям, потом еще раз Ctrl+K чтобы закомитить TTT-123 - и в комент автоматом проставляется имя ченджсета - TTT-123.
lucker (чел в теме) заявил:
Добавлено 9 октября, 2006 в 11:26Интересно. Т.е. если при работе над TTT-321 ты что-нибудь поменяешь в тех файлах, что менял при работе над TTT-123, то закомитятся только изменения из TTT-321, а из TTT-123 остануться висеть в Changes? Если да, что что будет, если например изменения из TTT-321 зависят он изменений TTT-123?