Я уже упоминал в предыдущих статьях, что посетил конференцию GeekOUT 2013, которая проходила 12-14 июня в Таллине. Таллин оказался очень приятным городом: старый город особенно хорош и красив, достаточно много парков, недалеко море, не такое насыщенное автомобильное движение как в Киеве. К Таллину мы еще вернемся в конце статьи, а пока о конференции.

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

Отдельного внимания заслуживает холл. Он был отлично оборудован плазмами в центре зала, благодаря чему с балконов второго этажа можно было легко наблюдать за демонстрациями продуктов. Это еще одна интересная идея организаторов – в перерывах на кофе давать возможность разным компаниям показывать свои продукты, которые имеют отношение к разработке на Java. Очень удобно – пьешь кофе и смотришь демо. Сами же стенды компаний располагались в холле и каждый мог подойти пообщаться и посмотреть демо от сотрудников компании, задать интересующие вопросы и набрать сувениров.

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

Обед и кофе-паузы тоже были неплохие, кейтеринг работал четко и слаженно. Мне понравилась идея с графинами холодной воды с кусочками лимона, лайма и апельсина. Достаточно просто и удобно.

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

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

Открывал конференцию Geert Bevin, который в своем докладе продемонстрировал достижение современных технологий – музыкальный инструмент, который судя по демонстрациям может все. Причем снимает данные о движении рук, самого музыканта и окружающей обстановке, а потом из всей этой информации делает музыку. Это реально круто!

За ним выступил Attila Szegedi с философским докладом о сложности систем и вычислений. Главный вывод – не создавайте сложности там, где это не нужно и пишите простые системы для решения задач бизнеса.

Доклад Kohsuke Kawaguchi я пропустил, потому что не вижу смысла в Jenkins когда есть TeamCity. Следующий доклад был от Juergen Hoeller о будущем Spring 4 и Java 8. Я ожидал чего-то нового и интересного, но в очередной раз прошлись по больным местам Java, узнали что Spring 4 выпустит поддержку Java 8 раньше самой Java 8, а еще что Java 8 уже работает неплохо в заявленной комплектации. Самым интересным фактом стало то, что разработчики Spring спрыгивают с Eclipse и переходят на IDEA, потому что в ней уже есть ранняя поддержка Java 8.

Последний доклад в первый день был от Tobias Lindaaker об инструментах в JDK, которые могут помочь делать разные хаки с вашим кодом. К примеру, при падении теста поставить туда break point или добавить поведение к методу. И даже затронули класс Instrumentation с его методом getObjectSize для любителей позамерять. Такие вещи полезно знать, но они редко применимы, если только вы не разрабатываете инструмент для разработчиков или библиотеку.

Во второй день работало уже два потока, поэтому приходилось выбирать. Первым докладом я выбрал Attila Szegedi с его отчетом о состоянии дел в работе других языков на JVM. Сам Atilla трудится над Nashorn чтобы дать разработчикам удобный инструмент для запуска JavaScript. В докладе было много живого кодирования и демонстраций. Получился очень полезный обзор для расширения кругозора.

Дальше я остался на главной сцене на совсем не технический доклад от Sven Peters из Atlassian. Доклад назывался «How To Do Kick-Ass Software Development» и не имел никакого отношения к Java. Это был рассказ о том, как в компании Atlassian строят процессы разработки, какие практики применяют и как использую Agile подходы и принципы. Agile не умер, вы просто не умеете с ним жить! Доклад был мега-ярким и позитивным.

После обеда заглянул на доклад Вовы Иванова о JIT. В очередной раз понял, что JIT много чего умеет и с каждым годом берет на себя все больше работы по ускорению кода на JVM. А это немаловажно для скептиков относительно скорости работы Java.

Дальше был доклад Andres Almiray об AST трансформациях и как классно они работают в Groovy. Действительно, можно одной аннотацией генерировать кучу кода или реализовывать шаблоны дизайна: @Singleton, @Immutable, @Lazy и другие. Это сильно упрощает код приложения, уменьшает число потенциальных ошибок и открывает возможности к повторному использованию целых решений. Да и сам докладчик был очень бодрый и активный, что добавило докладу живости.

Последнее выступление было от Talip Ozturk на тему его детища Hazelcast. Если вы еще не знаете, что это такое, то обязательно посмотрите. Очень простое распределенное хранилище данных с натуральным доступом через Java API многим приложениям очень бы пригодилось. Я не имел возможности послушать этот доклад на JEEConf 2013, поэтому тут наверстал упущенное.

Отдельное спасибо хочу сказать ребятам из ZeroTurnaround (особенно Антону Архипову и Олегу Шелаеву) за отличную конференцию, пригласительный для меня, много интересного общения и полезные советы по проведению времени в Таллине. Мы посетили практически все интересные места в старом городе, я забрался на самую высокую башню, погуляли по большому и очень красивому парку с фонтанами, увидели какое оно северное море, я организовал себе несколько пробежек, посетили морской музей и отлично провели время. Буду рад приехать в следующем году!

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

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

У меня очень негативное отношение к слову «стартап». Причин несколько. Одна из них заключается в том, что большая часть из того, что называют в современном мире «стартапами» – просто унылое никому не нужное говно, которое появилось на свет благодаря буму социализации и невнятным попыткам некоторых разработчиков «сказочно разбогатеть». Это касается как зарубежных, так и отечественных стартапов. Достойных проектов среди них 0.01%, а технически грамотно реализованных и того меньше.

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

Итак, чем же мне насолили? Давайте сначала, чтобы не быть голословным, я приведу ссылку об отношении сервиса к «звездным» отечественным стартапам. Речь пойдет о tickets.ua, который как вы видите занимает почетное 15-ое место, а также о его «собрате» – senturia.ua. Оба сервиса предоставляют возможности бронирования и покупки билетов.

Начнем с senturia.ua. Я вообще стараюсь как можно меньше пользоваться отечественными приложениями по заказу билетов и предпочитаю сайт авиакомпании (если нет большой разницы в цене) или проверенные сервисы как Kayak, Expedia, Orbitz и т.д. Но тут возникла сложность – лететь надо было в Эстонию с Estonian Air (только у них есть прямой рейс в Таллин) и все мои попытки заказать билеты на сайте компании заканчивались неудачно. Но об Estonian Air пожалуй отдельно.

Итак, я нашел рейс, ввел все данные о пассажирах, информацию для оплаты кредитной картой, проверил правильность данных о рейсе и смело нажал на кнопку оплаты. Каково же было мое удивление, когда ни через минуту, ни через 10 минут я не получил никакого письма от сервиса о судьбе моего заказа. Вообще ничего! При этом деньги с карты снялись мгновенно. Я подождал еще и понял, что надо обращаться в службу поддержки.

Тут начинается классический знакомый многим не по наслышке отечественный сервис. Раза 3-4 мне обещали разобраться в проблеме в течение 30 минут, максимум часа. На вопрос что случилось и почему с моей карты сняли деньги без реального бронирования билетов никто ответить не мог. Прошли почти сутки. В результате моих многократных звонков в службу поддержки и угрозе сообщить в банк о пропаже денег с моего счета (что можно довести до внесения получателя в черный список) мне вернули деньги, прислав сухое письмо об отмене моего бронирования, подписанное Юлией 559. Шикарно!

После этого я совершил вторую ошибку и воспользовался tickets.ua. Мне понравился простой интерфейс, где после выбора маршрута с датами, заполнения информации о пассажирах и карте на той же странице, оплата была совершена. Выбор полей был минимальным и никакая дополнительная информация не отвлекала. Деньги сразу не сняли, прислали уведомление о бронировании. После этого часть денег ушла напрямую компании Estonian Air, а часть tickets.ua. Сразу после этого мне прислали билеты на рейс. После опыта с senturia.ua я остался доволен. Но не тут то было…

Спокойно улетев из Киева в Таллин, на обратном пути в аэропорту у стойки регистрации выяснилась неприятная особенность – обратный рейс у меня был без багажа. Сотрудники авиакомпании объяснили, что билет заказан на разные типы сервиса в оба конца и что эконом у них бывает разный. Вспоминаете ту минималистичную форму заказа билетов? За ее внешним удобством для покупателя скрывается система, которая принимает решения на свое усмотрение. Узнать о том, что обратный рейс предоставляется без багажа, можно было по записи 0PC в одном из полей детальной маршрутной квитанции на обратный рейс. Никаких предупреждений, просто одно из полей мелким шрифтом в маршрутной квитанции. Можно было такое предположить? Я за многие годы полетов с такой проблемой сталкиваюсь впервые!

В результате, заказ на tickets.ua обошелся мне в дополнительные 40 евро, потраченное время и кучу головняка. Ну, думаю, по возвращение обращусь к ним и выслушаю извинения с компенсацией потраченных средств. Вместо этого получилось совсем наоборот. Я вернулся в режим отечественного сервиса. Мне начали доказывать, что во всем виноват я, который сам выбрал такой тип билета. Потом, в ответ на мой аргумент о невозможности его выбрать на сайте, виноватой вдруг стала авиакомпания, которая так забронировала билет. А потом мне и вовсе ответили, что их сервис заключается просто в передаче брони авиакомпании, а все остальное их просто не касается. Ах да, и мне же выслали маршрутную квитанцию с 0PC на обратный рейс.

Очень смешно рассказывать эту чушь разработчикам. Мы то прекрасно понимаем, что у авиакомпаний есть сервис, торчащий наружу, который делает то, что его попросили. Все ошибки, состыковки, обработка и подготовка данных, ложится на вызывающую сервис сторону. В данном случае это tickets.ua. Но оказывается она не несет за это ответственности.

Мне кажется, все дело в том, что у отечественных «стартаперов» отсутствует понимание сервиса и его целей, не говоря уже о лояльности к своим клиентам. Ошибки нужно признавать и принимать меры, чтобы клиент остался доволен в любом случае. Если ты берешься за определенную нишу, то надо в ней предоставлять именно сервис, делающий жизнь проще для клиентов. И не только тогда, когда все пошло по плану, но и когда появились проблемы.

В конце душеизлияния хотелось бы пару слов сказать о компании Estonian Air. Я достаточно часто летаю и привык оценивать уровень авиакомпании по цене на билеты. Дешевые билеты – вероятнее всего лоукостер и не стоит ничего ждать от него, дорогие – ты можешь ожидать неплохого сервиса. Estonian Air поломала стереотипы. Стоимость самого дешевого билета Киев-Таллин-Киев составляет около $300 при времени полета 1 час 30 минут. Его нельзя ни вернуть ни поменять. Что же вы получаете за эти деньги? А ровным счетом ничего:

• Компания настолько экономит, что в Борисполе обслуживается в самом углу терминала B, не смотря на то, что вылет из терминала D.
• На борту самолета все, включая обычную воду, исключительно за дополнительную плату.
• С августа этого года за невыполнение онлайн регистрации будут брать штраф 10 евро.
• Самолет ооочень маленький и шумный, некоторые пассажиры проходят в салоне только боком.
• Туалет на борту один и такой маленький, что даже при моем росте 180 см мне приходилось изгибаться чтобы туда поместиться.
• «Гибкие» опции помогают тебе улететь без багажа, когда ты этого не хотел.

А теперь самое интересное. В кармашке кресла как обычно можно найти журнал авиакомпании. И обычно на первой странице там руководство компании рассказывает о том, как их авиакомпания развивается, что хорошего ждет пассажиров, какие новости позитивные есть. И тут главные новости были о сокращении расходов. О том, что компания полгода провела в разработке стратегии по снижению затрат во всех областях, много людей уволили, урезали все что можно. Какое мне до этого дело? Стоимость услуг осталась такой же! Только пострадало качество предоставляемого сервиса. Так что в этом позитивного для пассажиров? Должны порадоваться, что теперь компания больше зарабатывает? И это очень напомнило мне наш отечественный сервис…

В общем, будьте аккуратны в своем выборе сервиса и не повторяйте моих ошибок.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Новые проекты постоянно стартуют, новые продукты начинают разрабатывать, а значит постоянно нужны новые хорошие команды, которые смогут привести проект к успеху. И тут появляется очень интересный вопрос: «кого нанимать в команду первым?». Казалось бы, что тут сложного в этом вопросе? Оказывается, что ситуация на проекте может очень сильно измениться от одного или иного решения.

Давайте предположим, что первым вы решили взять в команду очень крутого специалиста, так сказать «звезду». У вас как раз был такой на примете, вы его заинтересовали и пригласили в проект. Естественно, он будет принимать участие в отборе остальных членов команды. Но кого он будет пытаться отобрать? Вероятнее всего, таких же «звезд» как и он или немножко слабее. Для проекта это может превратиться в бесконечную волокиту в попытках расширить команду. Причины такого поведения просты – сильным разработчикам интереснее работать с другими сильными разработчиками. Зато, если вам повезет, вы получите небольшую, но очень сильную и замотивированную команду. Ведь каждый будет понимать, что это отличный шанс поработать действительно со «звездами». Если же не повезет, то вы не сможете набрать быстро людей, проект загнется или же вы не выдержите и переключитесь на второй вариант.

Во втором варианте вы берете первым в команду хорошего середняка. И тут вступает в силу второй интересный принцип – середняк не будет нанимать людей сильнее себя. Это будут либо люди слабее его, на фоне которых он будет чувствовать себя «звездой», либо такие же как он. В результате, вы можете достаточно быстро укомплектовать среднюю команду, но вам будет очень тяжело затащить туда сильного разработчика. Демотиватором для него будет уровень других членов команды. Да и для команды одного уровня приход такого сильного разработчика будет демотиватором. Но не факт, что средняя команда сможет сделать именно ваш продукт или проект на высоком уровне качества. А дальше может сложиться так, что середняки уйдут и уровень команды по тому же принципу упадет еще больше. И наступит болото…

Вот такой сложный выбор стоит перед тем, кто собирается набирать команду. Поэтому будьте внимательны и найдите для себя верную комбинацию.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Давненько я не писал провокационных статей. Сегодня хочу поднять очень интересную тему программистов/разработчиков в возрасте. Обычно к данной категории относят представителей нашей индустрии, которым 40+ лет и кто по прежнему непосредственно занимается разработкой. IT сообщество делится на 2 лагеря: считающие возрастных разработчиков очень грамотными, полезными в компании и те, кто наоборот считает их бесполезной массой, от которой давно пора избавиться. Тема спорная, но я постараюсь осветить свой взгляд на нее.

Я являюсь сторонником второго лагеря, но только по отношению к отечественным разработчикам. И мне кажется, что причина в них самих. За рубежом все совсем не так. Итак, начнем. Во-первых, для большей части долго проработавших на отечественном рынке разработчиков в определенном возрасте работа перестает приносить драйв и становится просто способом зарабатывать деньги. На первых позициях давно семья и хобби. Это значит, нет времени на самообразование, да и смысла в нем они не видят особого. Пилят старый проект на аутсорсе и деньги получают.

Вторая причина очень тесно связана с первой. Наш рынок очень специфичный, на нем возрастные разработчики с высокими требованиями по зарплате и малой отдачей попросту невыгодны. Поэтому они ищут способ оставаться при деле. Очевидный выход – разбираться в древних технологиях, которые молодым поколениям практически неизвестны. Тогда ты всегда будешь оставаться востребованным специалистом, ведь старых больших проектов пруд пруди и многие из них отдают на аутсорсинг (не так много людей хотят за границей такой дрянью заниматься). При таком подходе можно найти себе «тепленькое место» и не переживать за ближайшее будущее.

Следующая причина – это публичная активность. Если хочешь, чтобы о тебе было хорошее мнение, надо его заслужить. Если ты много знаешь, то поделись знаниями с коллегами, научи молодое поколение уму-разуму. И где все «опытнейшие разработчики»? Почему их нет на встречах сообществ и конференциях? А там где есть, большая часть слушателей остаются недовольными? Может быть не такие уж они и опытнейшие? Все с удовольствием слушают Мартина Фаулера, дядю Боба, J. B. Rainsberger, David Evans и других представителей зарубежной IT индустрии. А где наши гуру? Окучивают EJB 2.0 на WebSphere или переливают данные из внешних вебсервисов в старенькую версию Oracle, продолжая работать на Java 1.4?

Ну и последняя причина – это сопротивление изменениям. На многих проектах я наблюдал одну и ту же картину как разработчики в возрасте становились большой преградой на пути внедрения новых подходов и технологий. Оно и понятно – эти изменения выбивают их из привычного окружения, требуют учить что-то новое, снова становиться начинающим из «эксперта». Мы все сопротивляемся изменениям, которые выбивают нас из зоны комфорта. «Эти ваши Agile-шмаджайл, чего общаться? Код надо писать вместо этого!». «Какой NoSQL? А ты потом будешь отвечать за потерянные транзакции?». «Кто будет поддерживать эти open source поделки? Завтра их может уже не быть…».

Я считаю, что для хорошего мнения о себе надо многое сделать. Возраст и опыт не создаст на ровном месте хорошего мнения. Его надо заслужить! Хотелось бы услышать ваше мнение на данную тему в комментариях.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Решил написать маленькую пятничную статью, целью которой является предупредить всех, кто дует щеки и через слово вставляет Big Data. Сколько бы я не читал статей или не общался с товарищами, которые претендуют на использование действительно больших объемов данных у себя в приложении, никто из них не упоминает миграцию данных. Говорят о скорости чтения и записи, масштабировании, шардинге и прочих важных вещах. А о миграции ни слова.

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

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

Чтобы избежать подобных проблем, стоит в самом начале задать себе вопрос: «а что будет, если понадобится перенести данные для одного пользователя/клиента/проекта/заказчика/… в другое место?». Еще более полезным вопросом при проектировании вашего хранения данных и выборе хранилища будет: «а какие данные у нас являются независимыми и как мы обеспечим эту независимость при хранении?». Это гораздо более продуманный путь чем взять бездумно MongoDB или Cassandra только потому, что это модные технологии. Помните, успех проекта принесет новые, часто неожиданные задачи и проблемы…

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Сегодня в который раз убедился, что самоорганизация существует и она свойственна людям. История очень короткая, чтобы не утомлять в пятницу чтением длинных заумных статей. Так вот, по дороге на работу уже второй день не работает светофор. Причем на пересечении двух достаточно активных дорог по 3 полосы в каждом направлении. Движение всегда оживленное, особенно в часы пик. И что вы думаете? Пробки не образовываются. Водители медленно подъезжают к перекрестку, пропускают группу машин и потом едут. И никто не сигналит как бешеный, что он находится на главной дороге. Водители на главной ведут себя очень корректно, не парализуя движение на второстепенной.

Это ли не яркий пример самоорганизации? Почему так происходит? Ведь обычно в таких случаях приходит микро-менеджер в лице регулировщика. В результате все недовольны, стоят и нервничают. Да и ГАИ водители недолюбливают также как разработчики менеджеров. А тут раз и все само собой работает. Мне кажется, что водителями движут несколько вещей, которые и дают эту самоорганизацию:

• Каждый понимает, что он может завтра оказаться на второстепенной и точно так же стоять.
• Никому не нужна авария на ровном месте, цель каждого – приехать побыстрее и без проблем в пункт назначения.
• Внутреннее стремление доказать, что ты – классный водитель и «разрулишь» такую ситуацию легко.

Конечно, иногда находятся «мудаки», которые пытаются нарушить этот процесс. Но «мудаки» есть всегда и везде, с этим ничего не поделаешь. Избавляйтесь от таких людей в своих командах, проектах, компаниях и самоорганизация будет получаться гораздо проще.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Недавно снова вспомнил свой любимый Hibernate и извечный спор что использовать: XML или аннотации. Я в этом споре придерживаюсь старомодной позиции XML и в этой коротенькой статье объясню почему. Изначально весь маппинг писался в XML, но потом в Java 5 пришли на радость людям аннотации и большая часть ORM фреймворков тут же предложили решение для маппинга с их использованием. Вроде бы современный подход, но…

Давайте вспомним такой замечательный принцип как Single Responsibility Principle. Он гласит о том, что код должен иметь минимальное количество ответственностей, в идеале – ровно одну. Тогда он может меняться только по одной причине и это делает его более устойчивым, а значит ваше приложение и база кода будет меньше подвержена изменениям. Что же получается в случае использования аннотаций с ORM? В этом случае на наш POJO ложится сразу две ответственности – отвечать за объект доменной модели и хранить знания о способе хранения информации в БД. Некоторые сюда же добавляют еще одну ответственность – хранение запросов для вычитки данных (при использовании именованных запросов). Не слишком ли много всего для бедного маленького POJO? Да и после манипуляций с аннотациями это уже не такой и POJO.

Все перечисленные ответственности, собранные в одном месте делают классы доменной модели очень сильно подверженными изменениям, хотя в хорошем приложении должно быть наоборот – доменные объекты меняются крайне редко. В чем же тут дело? Неужели разработчики ORM инструментов толкают нас на нарушение правильных принципов дизайна? Вовсе нет! Кто читал документацию не между строк, заметил, что везде фигурирует понятие Entity. И это не объект доменной модели, а специально заведенный объект для уровня хранения данных, на котором и работает ORM. И тогда Entity имеет только одну ответственность – предоставлять доступ к хранилищу данных.

Но в этом случае вам понадобится отдельный набор доменных объектов и механизм трансформации Entity < -> доменный объект (в простонародье трансформер). И тогда все будет честно, никакие правила хорошего дизайна страдать не будут. Также можно будет избежать добавления дурацких equals и hashCode в доменные объекты, которым это совершенно не нужно. Можно будет делать доменные объекты максимально immutable и не плодить пустых конструкторов и get/set методов для всех свойств. Правда в этом случае придется платить дублированием данных и дополнительной работой над слоем трансформеров. Выбор за вами…

Мы все стремимся сэкономить время и разрабатывать быстро, поэтому многие прикручивают ORM прямо на доменные объекты. И вот в этом классическом случае аннотации являются скорее злом чем добром. А мы должны оставаться на стороне добра!

P.S. Кто еще не смотрел видео моих выступлений на тему Hibernate, можете найти много для себя интересного. Найти их можно на странице материалов.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Я вот на днях подумал, что трудно придумать лучший тимбилдинг, чем поехать командой на конференцию в другой город. Приведу несколько доводов, которые мне по опыту кажутся очень вескими:

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

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

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

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

Каждый раз когда я еду на конференцию с кем-то, я привожу гораздо больше с нее. Новые идеи, планы, знакомства, материалы… Поэтому, организуя JEEConf, Selenium Camp, XP Days Ukraine в Киеве, я немного вам завидую.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

За последнее время несколько раз столкнулся с одной и той же странностью – организаторы конференции выдвигают требования к докладчикам на тему уникальности контента. Это значит, что докладчик должен подготовить для конференции новую тему, с которой он нигде не выступал до этого. Я считаю это полнейшей глупостью и постараюсь в этой статье объяснить почему.

Один из главных доводов организаторов: каждый может зайти и посмотреть видео старого доклада с прошедшей конференции. А значит, доклад не будет таким интересным и на него никто придет. Давайте начнем издалека, с далеких от IT областей. Зачем люди идут на концерты популярных исполнителей? Ведь они же есть в записи. Сел себе спокойно и посмотрел в записи концерт пока занимаешься другими делами. Круто ведь? На самом деле не очень, явно драйва от такого просмотра будет на порядок меньше чем от живого выступления, не говоря уже про возможность сфотографироваться с кумиром, взять автограф и просто хорошо провести время в компании людей с похожими музыкальными предпочтениями. Точно так же и в выступлении – у вас есть возможность лучше проникнуться докладом, задать свои вопросы докладчику, открыть новые грани темы доклада, пообщаться на в кулуарах, лично познакомиться и взять контакты. И вы гораздо лучше воспримите доклад в живую потому что время для самообразования выделено вами специально, а не за другими делами.

Теперь давайте посмотрим, насколько может пересечься аудитория на одном и том же докладе на разных конференциях. Тут вступает в действие множество факторов. Я перечислю лишь несколько из них. Наиболее очевидный фактор – географический. Конференция в Питере и Киеве рискует пересечься по аудитории меньше 1%. Даже в пределах Украины при небольших масштабах конференции вы можете практически не встретить людей, видевших ваш доклад на конференции в другом городе. Следующий фактор – направление конференции. Конференции для менеджеров, админов, разработчиков и тестировщиков практически не пересекаются по аудитории (поверьте моему многолетнему опыту выступлений).

Видеозаписи докладов публикуются, но не на всех конференциях и не всегда быстро. Мы делаем это уже 3 года для всех наших мероприятий и я бы не сказал, что тысячи человек ждут этого и пересматривают все доклады. У большей части людей для этого нет ни времени ни желания. Но это уже совсем другая проблема.

Давайте задумаемся, почему докладчик выступает с одной и той же темой несколько раз. Во-первых, эта тема ему интересна и он ей занимается. Во-вторых, в этой темой он чувствует себя профессионалом и может очень уверенно делиться своими знаниями и опытом. Да и сам доклад по мере выступления изменяется, оттачивается и впитывает новые и новые полезности. У хороших докладчиков конечно. А еще докладчик, которого приглашают на несколько мероприятий в месяц, просто не в силах все время выдумывать новые темы для докладов. За такой короткий срок не случается чего-то нового, нельзя углубиться в новые практики и технологии. И что получается из таких попыток? Чаще всего притянутые за уши темы, скучные доклады, неграмотные ответы на вопросы участников и испорченное впечатление о докладе и самом докладчике.

Для меня как организатора выступление докладчика не первый раз с выбранной темой решает сразу много проблем. Я могу посмотреть как он выступает, может ли держать аудиторию, насколько много людей собирается на его доклад. Я могу почитать отзывы и даже найти участников, которые видели живое выступление и могут поделиться своими ощущениями. Дополнительно убирается много рисков, связанных с подготовкой презентации, продумыванием тайминга, объемом и качеством материала. Все это сильно упрощает жизнь организаторам и делает конференцию ярче и качественнее.

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

В заключение хочу отметить, что при текущем количестве публичных образовательных мероприятий (конференций, тренингов, семинаров, курсов, встреч и т.д.) новые темы стали настолько редкостью, что их приходится выискивать очень долго. Гораздо важнее уметь тему правильно раскрыть и подать, дать людям тот заряд энергии, которого им хватит для изменения своих подходов и практик. А это всецело зависит от докладчика, а не от уникальности темы. На днях я посмотрел запись доклада Мартина Фаулера «Введение в NoSQL». Тема избитая и я уже слышал много выступлений, читал-перечитал и сам попробовал большую часть решений на рынке NoSQL. Но Фаулер заставил меня посмотреть на вещи и концепции немного под другим углом, подумать над спецификой проблем и решений к ним, над которыми я раньше так детально не задумывался. И это круто, я из одного доклада узнал больше чем часто с целой конференции! Хотя тема далека от уникальности…

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!

Как ожидать элементы или определенные состояния на странице? Наверное, один из самых интересных вопросов, которые могут возникать при первом использовании WebDriver. Разработчики инструмента потрудились на славу, чтобы сделать этот процесс максимально комфортным и гибким.

В статье рассмотрены самые важные типы ожиданий, используя WebDriver API.

Ожидание времени загрузки страницы

Как известно WebDriver работает с DOM. Потому ожидание загрузки страницы происходит через ожидание состояния document.readyState == complete. Это происходит автоматически после открытия страницы driver.get(), перезагрузки driver.navigate.refresh(), перехода на другие страницы посредством нажатия на веб элементы и т.д. WebDriver ожидает загрузку DOM-а страницы автоматически, потому уже не нужно вызывать waitForPageToLoad() после каждого действия, как это было в Selenium RC. Если же загрузка страницы длится очень долго и нужно прекратить ожидание, предусмотрена конфигурация pageLoadTimeout. Но стоит принимать во внимание, что если DOM не загрузился к тому моменту, вы получите TimeoutException.

driver.manage().timeouts().pageLoadTimeout(60, TimeUnit.SECONDS);

На момент написания статьи работает только для Firefox и InternetExplorer.

Ожидание выполнения JavaScript

Используя JavascriptExecutor, есть возможность выполнять любой JS на Web странице. Для функции executeAsyncScript мы можем задать граничное значение времени ожидания завершения запроса:

driver.manage().timeouts().setScriptTimeout(30, TimeUnit.SECONDS);

Неявные или скрытые(Implicit) ожидания.

Их особенность в том, что ожидания указаны глобально на уровне объекта driver. И все вызовы элементов driver.findElement() будут продолжаться то тех пор, пока элемент не будет найден или будет достигунта граница времени ожидания.

driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);

В данном примере, при вызове функции driver.findElement(), если элемент не присутствует в DOM страницы, на протяжении 10 секунд будет происходить опрос браузера на наличие элемента. Это очень помогает при работе с AJAX компонентами.

Явные(Explicit) ожидания

Самая интересная тема – конфигурируемые ожидания.

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

Создание объекта WebDriverWait

private final Wait<WebDriver> wait = new WebDriverWait(driver, 5, 1000);

Второй параметр принимает время timeout в секундах, третий параметр принимает время в milliseconds, которое нужно ожидать перед очередным вызовом проверки наличия элемента (500 milliseconds by default).

Вывод сообщения в случае неуспешного завершения ожидания

private final Wait<WebDriver> wait = new WebDriverWait(driver, 5).withMessage("Element was not found");

Игнорирование определенных событий во время поиска

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

• Если элемент доступен в DOM на момент поиска, но спустя время, в момент его вызова, DOM может измениться. Тогда мы получим StaleElementReferenceException.
• Если элемент отсутствует в DOM на момент вызова – получим NoSuchElementException.
• Если элемент был найдем в DOM, но не видим на странице – получим ElementNotVisibleException.
• Если элемент изменил координаты – получим MoveTargetOutOfBoundsException.

Когда пойман один из таких случаев, то цикл остановится и выбросит исключение.

Для того чтобы игнорировать исключения в объекте Wait предусмотрен метод ignoring:

private final Wait<WebDriver> wait = new WebDriverWait(driver, 5).ignoring(StaleElementReferenceException.class, ElementNotVisibleException.class);

Еще один вариант создания объекта Wait

private final Wait<WebDriver> wait = new FluentWait<WebDriver>(driver).withMessage("Element was not found").withTimeout(10, TimeUnit.SECONDS).pollingEvery(1, TimeUnit.SECONDS);

Вызов объекта Wait

Объект содержит в себе всего одну функцию until, которая представляет собой правило, по которому стоит ожидать элемент. Существует набор уже определенных правил для ожиданий. Находятся они в классе ExpectedConditions:

wait.until(ExpectedConditions.visibilityOf(driver.findElement(By.id("table"))));

Часто используемые правила:

• titleContains(String title)
• presenceOfElementLocated(By locator)
• presenceOfAllElementsLocatedBy(By locator)
• visibilityOfElementLocated(By locator)
• visibilityOf(WebElement element)
• textToBePresentInElement(By locator, String text)
• invisibilityOfElementLocated(By locator)
• invisibilityOfElementWithText(By locator, String text)
• elementToBeClickable(By locator)
• stalenessOf(WebElement element)
• alertIsPresent()

Есть возможность использовать негативные правила:

wait.until(ExpectedConditions.not(ExpectedConditions.presenceOfElementLocated(By.id("link"))));

Список всех функций доступен по ссылке.

Создание индивидуальных ожиданий

В тех случаях, когда ни одно из готовых правил не подходит, нужно создавать свое:

Function<? super WebDriver, Object> isTextPresent = new ExpectedCondition<Object>() {
  @Override
  public Boolean apply(WebDriver webDriver) {
    return  webDriver.findElement(By.tagName("body")).getText().contains("New topic");
   }
};

Если использовать объект типа WebDriverWait:

//Link
private final WebDriverWait wait;

//Initialization
wait = new WebDriverWait(driver, 1);

Можно создавать правило используя класс Predicate:

Predicate<WebDriver> isTableLoaded = new Predicate<WebDriver>() {
  @Override
  public boolean apply(WebDriver webDriver) {
    List<WebElement> rows = webDriver.findElement(By.id("table")).findElements(By.tagName("tr"));
    return rows.size() > 1;
  }
};

WebDriver API очень богат разного рода ожиданиями, для часто-встречающих ситуаций в автоматизации тестирования Web приложений. Чтобы упростить конфигурацию значений времени для ожиданий, их обычно выносятся в параметры запуска или сохраняют в property файл.

Используйте эти примеры для своих функциональных тестов с целью повысить их производительность и стабильность. Если какая-то из возможностей WebDriver API осталась не раскрытой, пожалуйста, напишите пример в комментариях.

Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!