Приятно, что мероприятий для разработчиков в Украине проводится все больше и больше. А еще приятнее, что много из них непосредственно касаются Java. Организаторы как будто договорились сделать май супер-насыщенным. 18 мая в Одессе компания Lohika проведет Java Breeze – самую масштабную Java конференцию в южном регионе.
Вы увлекаетесь Java и изголодались по конференциям, посвященным сложным техническим вопросам в своей области специализации? Добро пожаловать на Java Breeze! На протяжении целого дня известные Java гуру и ведущие технические специалисты будут презентовать доклады, основанные исключительно на их практическом опыте.
Java Breeze пройдет при поддержке одесской Java Group. Все детали вы увидите на сайте конференции.
Регистрационный взнос составляет 100 гривен (информацию по оплате вы получите в письме после регистрации). На Java Breeze гарантировано будет комфортная, положительная и вдохновляющая атмосфера для обучения и обмена опытом, добро пожаловать!
Сегодня в который раз убедился, что самоорганизация существует и она свойственна людям. История очень короткая, чтобы не утомлять в пятницу чтением длинных заумных статей. Так вот, по дороге на работу уже второй день не работает светофор. Причем на пересечении двух достаточно активных дорог по 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!
Я уже второй год хочу попасть на конференцию GeekOut в Эстонии, но никак не получается. Вот и в этом году повздыхал и думал не ехать из-за неудобств с визой и катастрофичной нехватки времени, но потом решительно настроился: “Какого черта! Не все так сложно!”. Так что 13-14 июня я вероятнее всего буду в Таллине наслаждаться солнышком, интересными докладами и Эстонией, где ни разу к своему стыду не был.
Что же там такого классного, на этой GeekOut? Прежде всего, там собирается очень интересная программа. Это тот редкий случай, когда есть только один поток и ты об этом ни капельки не жалеешь. Я ярый фанат Attila Szegedi, доклады которого про JVM смотрел еще во времена его работы в Twitter. Будет выступать с докладом сам Juergen Hoeller, с которым можно поздороваться и потом не мыть еще полгода руку. А еще можно послушать в живую акцент Kohsuke Kawaguchi, хоть я и не фанат Jenkins. Да и остальные доклады не уступают…
Во-вторых, на этой конференции можно встретить старых знакомых, погулять по старому городу, сходить на пляж и отлично провести время. По словам Антона Архипова, есть 2 времени в году, когда есть смысл приезжать в Таллин – Рождество и июнь. Вот я и проверю это на своем личном опыте. У кого еще нет планов на июнь, присоединяйтесь!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Я вот на днях подумал, что трудно придумать лучший тимбилдинг, чем поехать командой на конференцию в другой город. Приведу несколько доводов, которые мне по опыту кажутся очень вескими:
Во-первых, поездка на конференцию ценна как источник новых знаний и пинок под зад в сторону самообразования. Причем, командой можно все обсуждать и обдумывать в применении к компании и проекту сразу на месте, а не пересказывать потом по приезду. Можно разделиться по разным докладам и собрать еще больше полезных знаний и интересных мыслей. Все это можно будет хорошенько пережевать по дороге домой.
Во-вторых, сама совместная поездка в другой город является своего рода командной работой. Заказать билеты, отель, продумать план поездки, что посмотреть, посетить. Это же очень интересно. В детстве мы мечтали поехать в лагерь хорошей компанией, без родителей и отлично провести время. Еще лучше снять большую квартиру на всю команду и пожить вместе пару дней. Ничего не может быть лучше для понимания друг друга.
В-третьих, вы отрываетесь от повседневных дел и суеты. Вместо этого у вас появляется возможность пообщаться на интересные темы с коллегами. Едете вы на поезде или летите самолетом, времени на общение у вас будет предостаточно. А это и возможность лучше узнать друг друга, обсудить вещи в проекте, на которые никогда не хватает времени, получить много новой информации.
Ну и наконец, чтобы не томить вас длинной статьей, последний довод: путешествовать и знакомиться с новыми людьми – это интересно. А делать это хорошей командой еще интереснее. Ведь у вас будет не только возможность посетить конференцию, но и погулять по достопримечательностям, попить пива в новом месте, развиртуализироваться с людьми, которых вы вроде и знаете, но никогда не видели.
Каждый раз когда я еду на конференцию с кем-то, я привожу гораздо больше с нее. Новые идеи, планы, знакомства, материалы… Поэтому, организуя JEEConf, Selenium Camp, XP Days Ukraine в Киеве, я немного вам завидую. 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Мы упорно трудились, чтобы составить действительно достойную программу в этом году. Впервые конференция проходит в 2 дня, но тем не менее было подано очень много заявок от докладчиков и их хватило с лихвой на 3 параллельных секции. Оказалось очень трудно выбрать из них самые лучшие, но мы это сделали. Первая версия детальной программы уже опубликована. В ней по-прежнему возможны небольшие изменения, но мы надеемся обойдется без них.
Что же интересного в программе? Интересного действительно много:
И это далеко не все интересное, что ждет вас в программе JEEConf 2013. Если вы еще не с нами, то присоединяйтесь. Если вы уже участник конференции в этом году, то высказывайтесь по поводу программы. Мы будем рады услышать конструктивную критику и сделать программу еще лучше!
По многочисленным просьбам участников, мы решили провести несколько тренингов для Java разработчиков перед конференцией. Они будут публиковаться на сайте конференции по мере появления.
Свободных мест с каждым днем все меньше! Количество участников конференции постоянно растет. На текущий момент их уже 500. Основной этап регистрации по цене 1600 гривен заканчивается 19 апреля. Осталось всего меньше двух недель, чтобы успеть зарегистрироваться на этом этапе. Потом начнется обратный отсчет и регистрация закроется как только все билеты будут распроданы. Второго шанса уже не будет!
Вы можете получить скидку 10% при групповой регистрации (группа от 5 человек). Поэтому собирайте своих товарищей и коллег и мы будем рады видеть вас на конференции! Присоединяйтесь, будет интересно!
Не хочешь пропускать ничего интересного? Подпишись на ленту 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.
Используя JavascriptExecutor, есть возможность выполнять любой JS на Web странице. Для функции executeAsyncScript мы можем задать граничное значение времени ожидания завершения запроса:
driver.manage().timeouts().setScriptTimeout(30, TimeUnit.SECONDS);
Их особенность в том, что ожидания указаны глобально на уровне объекта driver. И все вызовы элементов driver.findElement() будут продолжаться то тех пор, пока элемент не будет найден или будет достигунта граница времени ожидания.
driver.manage().timeouts().implicitlyWait(10, TimeUnit.SECONDS);
В данном примере, при вызове функции driver.findElement(), если элемент не присутствует в DOM страницы, на протяжении 10 секунд будет происходить опрос браузера на наличие элемента. Это очень помогает при работе с AJAX компонентами.
Самая интересная тема – конфигурируемые ожидания.
Ведь очень сложно угодить всем компонентам на странице используя только стандартные средства неявных ожиданий. Особенно в тяжелых AJAX приложениях.
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 модели. При этом существует ряд исключительных ситуаций
Когда пойман один из таких случаев, то цикл остановится и выбросит исключение.
Для того чтобы игнорировать исключения в объекте Wait предусмотрен метод ignoring:
private final Wait<WebDriver> wait = new WebDriverWait(driver, 5).ignoring(StaleElementReferenceException.class, ElementNotVisibleException.class);
private final Wait<WebDriver> wait = new FluentWait<WebDriver>(driver).withMessage("Element was not found").withTimeout(10, TimeUnit.SECONDS).pollingEvery(1, TimeUnit.SECONDS);
Объект содержит в себе всего одну функцию until, которая представляет собой правило, по которому стоит ожидать элемент. Существует набор уже определенных правил для ожиданий. Находятся они в классе ExpectedConditions:
wait.until(ExpectedConditions.visibilityOf(driver.findElement(By.id("table"))));
Часто используемые правила:
Есть возможность использовать негативные правила:
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!
Только вчера прошла 26-ая встреча “Клуба анонимных разработчиков” и мы уже готовы объявить о следующей встрече. Она состоится 18 апреля и темой выбрано тестирование Java веб-приложений. Веб-приложений мы пишем все больше и их тестирование становится очень актуальной проблемой. Мы также опубликовали видео с последних встреч, их можно найти на официальной странице клуба.
Одним из докладчиков выступит Алексей Резчиков, который расскажет и покажет на практических примерах как тестировать Spring MVC приложения с помощью новых возможностей Spring 3.2 без запуска веб-сервера. Николай Алименков расскажет про альтернативный подход тестирования напрямую с использованием браузера и WebDriver/Selenium. Мы приглашаем других докладчиков поделиться своим опытом тестирования веб-приложений и применяемых инструментов, подходов и практик.
Встреча пройдет в четверг 18 апреля. Местом проведения выбран офис компании ЕПАМ, который располагается по адресу ул. Кудряшова 14-Б. Наши встречи собирают все больше и больше участников, поэтому мы выбрали более просторный зал.
Внимание!!! Всем участникам нужно иметь при себе документ, удостоверяющий личность для прохождения поста охраны.
Официальное начало встречи по-прежнему в 19:00, завершение в 23:00. Стоимость участия 80 гривен при оплате заранее, 120 гривен при оплате на месте. Пива, пиццы и кофе с печеньками хватит на всех. Регистрация обязательна. Все детали по оплате будут высланы вам после успешного прохождения регистрации. Количество мест ограничено 60 участниками.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
