Впечатления о JavaDayKiev 2013

Попал я на это мероприятие от жажды халявы: знакомый дал мне промокод на 50% скидку и не пойти стало на порядок сложнее. И хотя я достаточно далек от мира J2EE в целом мне понравилось.

Итак, начнем! На первый доклад я опоздал. И это было очень кстати, поскольку делал его чувак из Оракла, на английском и это было очень скучно (не потому что на английском, а потому что просто перечисление нововведений). Звали чувака David Delabassee. Он определенно шарящий, но доклады смертельно скучные. Хотя кое-что мне удалось запомнить:

• J2EE 7 - первый релиз EE, который выпустила Oracle, а не Sun. Он это особенно подчеркивал, почему-то
• в данный момент у них следующие приоритеты развития:
• поддержка HTML5
• продолжать поддержку Enterprise решений (ясен пень)
• повышение продуктивности разработчиков
• добавили поддержку WebSocket'ов. Теперь она есть в стандарте и это хорошо
• Добавили API и стандартную реализацию для работы с JSON. Запилили два парсера: аналоги StAX'а и DOM'а
• Улучшили поддержку REST для клиентской стороны
• Ввели нечто Batch Application 1.0 (беглое гугление показало, что это для этих ваших гридов и для прочих ресурсоемких, но не интерактивных задач. Подробнее тут)
• Добавили плюшек для работы с многопоточностью, ориентированных именно на EE
• Обновили Java Message Service 2.0 и JPA 2.1

Второй доклад начался с внезапно вышедшего мужика в костюме Пипца (это русская локализация названия фильма Kick-Ass). Мужика зовут Sven Peters (и как у любого порядочного евангелиста у него есть сайт), работает он в Atlassian (если вдруг кто не в курсе, то это ребята, которые делают Jira, Bitbucket, HipChat и ещё кучу крутейших штук). Основное его занятие, насколько я понял, разъезжать по мероприятиям и рассказывать насколько всё круто у них в конторе и что неплохо было б перенимать передовые наработки (тем более, что у них и софт подходящий имеется ;) хотя, справедливости ради, стоит сказать что никакой рекламы в докладе не было вовсе). Итак вот о чем он говорил:

• Чё это он в таком странном костюме? А это потому что ему нравится основная идея фильма, в котором главный герой в таком костюме. Она такая: не нужно думать, что ты ничего не можешь, просто бери и делай. Скорее всего сначала зафакапишь, но если это тебя не сломит, то всё будет ништяк.
• Agile хорошая штука, но решает не все проблемы
• Даже если вы в легаси команде (имеется в виду у вас огромная куча кода, который нужно поддерживать), то всё равно нужно постоянно стремиться использовать новые технологии, ибо иначе застой. Считается, что все решения уже приняты, политику партии менять нельзя, да и не хочет никто, а это скука смертная, а от неё все беды.
• Нужно делать прототипы. Крутые бумажные прототипы (это когда устанавливают камеру статично, вырезают основные UI элементы из бумаги, рисуют детальки и потом делают вид, что получился настоящий интерфейс). Делать их нужно потому, что это самый дешёвый способ зафейлится на раннем этапе (а следовательно исправить ошибку и цена исправления будет небольшой). Идея не нова, но хорошо, что о ней напоминают (типа, все знают, но никто не пользуется - Kick-Ass, guys! Ноги в руки и арбайтен ножницами по бумаге!)
• Не стоит ограждать разработчиков от пользователей приспособлением типа "shit umbrella" (прикольный термин :) ) из менеджеров. То есть стоит, но в случаях, когда на одного разработчика приходится стотыщ пользователей (как в Gmail, например). Но проектов с такими пропорциями не много, а потому нужно чтоб была прямая связь. В Atlassian этим очень заморачиваются: каждый разраб, должен пройти недельную практику в first line help desk, чтоб проникнуться.
• Разработчики не должны полагаться на QA отдел. То есть первичное тестирование написанной фичи должно проводиться самим автором (опять же - девы проходят практику в QA отделе). QA по большей части не занимаются ручным тестированием, а пишут test recipes, которые прогоняются разработчиками.
• В Atlassian работают по большей части супермены, которые не только программируют, но ещё и дизайнят (причем неплохо). Но вот они сначала подумали: "Зачем платить больше, если девы сами дизайнят и даже неплохо выходит?" В результате получили стопиццот видов дроп-даун меню, каждое из которых неплохо выглядело по отдельности, но фигово в системе в целом. Мораль: можно давать разработчикам дизайнить (если руки откуда надо), но должны быть гайдлайны, которые составляются дизайн-отделом.
• В этой чудо-компании есть дизайнеры, которые сами умеют сверстать интерфейс (просто рай на земле у них там). Это снижает уровень расстроенности дизайнеров при просмотре реально получившегося дизайна. Круто, что сказать...
• Для каждой таски (именно таски) создаётся своя веточка (ну ессно у них git). Веточка сливается в основной поток пул реквестом. Его должны одобрить двое членов команды (любых) и тогда автор мержит его с основной веткой (специально у него переспрашивал кто мержит - именно автор, одного аццки мейнтейнера нет).
• У них в офисе есть "порталы" - афигенски большие телики для которых в стене вырезается крут (получается фигня как из Star Gate). Удобно проводить митинги и видно, что тут гики работают, а не какие-то левые чуваки.
• Всё что можно нужно автоматизировать: билды должны быть быстры, тесты нужно паралелить, тестировать можно слои, а не приложение в целом (с разной периодичностью), постоянный доступ к статистике (у каждой команды свой телик, отведённый под это дело).
• Мораль: Agile это круто! Но круто самой концепцией - нужно постоянно меняться, иначе застой. Все в команде должны хотеть улучшить любую деталь.

В общем и целом, вещи всё понятные, но презентация всё равно афигенская. Вот слайды. Рекомендую.
Третий доклад был про веб-сокеты и делал его чувак из Оракла (тот же, что и первый доклад читал). Скучно было, пришлось чатиться и твиттер читать :)

Четвертый доклад был афигенен. Делал его лысый парень из питерского офиса Оракла, который занимается Core Java. Зовут Алексей Федоров. Его доклад состоял из баек. К примеру, есть много людей, которые не переползают на новые версии джавы. Реально много. А критические уязвимости находятся постоянно новые. Результат: секюрити апдейты выпускают под 5, 6, 7 джавы и это адъ.

Оказывается, фиксить баги это дело неблагодарное ибо есть софт, который полагается на баги (явно или не явно). То есть поправят они баг - у кого-то в продакшене что-то рухнет и будет грусняшка. В результате некоторые баги не фиксятся, поскольку специально собранная комиссия говорит "эт слишком рискованно, ребята".

Оказывается есть джава машина, которую пишут в Новосибирске и которая джава код компилирует в бинарный код (не jit, а именно настоящая компиляция). Называется Excelsior. Не знал, что такое бывает.

Пятый доклад был о Gradle. Тут всё стандартно - введение в новую тулзню, так что пересказывать смысла нет. Рассказывал Евгений Борисов.

Шестой доклад был о TDD и базах данных. Название заманчивое. Докладывал аццки крутой Николай Алименков (надеюсь правильно перевел, а то в расписании все на английском). Я, к сожалению, прослушал только теоретическую часть, а с лайв кодинга сбежал. Но основные идеи, кажется, всё же уловил:

• Данные это самое дорогое что есть у пользователей. Нет ничего хуже, чем потеря пользовательских данных, ибо они огорчаются, перестают пользоваться + набрасывают антирекламу на вентилятор, в результате теряются потенциальные пользователи. Пичалька.
• Поэтому нужно тестировать всё, что связанно с БД: ORM-маппинг, хранимые процедуры, триггеры, целосность данных и тд и тп
• Тестировать БД просто, поскольку в ней нет скрытой логики.
• Тестировать нужно на реальном конфиге БД, иначе где гарантии, что на тестовом серваке всё зашибись, а в продакшене - кака?
• Можно выделять для каждого теста отдельную транзакцию, а потом делать ролбек, но это не всегда подходит (иногда нужно что-то реально записать в базу, иначе что-то не сработает).
• Бывают ситуации, когда на таблицу навешана куча констреинтов и чтоб подготовить БД к тесту нужно сделать массу телодвижений (к примеру, нужно протестировать таблицу иголок, а для этого нужно добавить дуб, в таблицу дубов, ларец - в ларцы, потом утку, потом зайца, потом яйцо, а потом уж, наконец, иголку). В таком случае имеет смысл модифицировать констрейнты на время теста и оставлять только те, которые, собсно, тестируются.

Вот такие пироги. Мне понравилось!

ЗЫ Вот тут есть страничка с программой конфы.