Организация конференции Selenium Camp в самом разгаре. Напоминаем вам, что состоится она 26 февраля в Киеве. Это будет первая конференция, целиком посвященную продукту для тестирования web-приложений Selenium. Selenium Camp – это конференция, целью которой является собрать вместе всех, кто так или иначе использует Selenium. Selenium Camp будет интересен как отличная стартовая точка для тех, кто только задумывается о применении Selenium, а также для профессионалов, использующих его долгое время.
Конференция соберет около 200 участников из Украины, России, Беларуси, Эстонии. Будет представлено множество различных компаний: EPAM Systems, 908.ua, Argentum IT Lab, KSF, Odyssey Logistics, Softheme, GlobalLogic, Softengi, Ameria, Intego Group, AltexSoft, Ciklum, Рамблер, Эй Си Онлайн, Intersog, Luxoft, XBSoftware, TeamDev, DIMALEX, Archer Software, Dialog Webdesign, BumpNetworks, Stella Systems, Zoral Labs, Green Ice, VIACode, OWOX, Bercut, Skype, ИСМ Украина, SEC Open Code, Инком, SysIQ, Exigen Services, ReklamaPort, WaysGo, Астротэк, Ukrsibbank, Ardas Group, DMS Consulting, Ardas Group, Крок, Intetics, Lohika, U-wiss, Svitla, РИА Аллегро, Aquasoft, Softjourn, Видео Интернет Технологии, Railsware, Altexsoft, NIX Solutions, Madcap BV, TEAM International, Ciklum, Archer Software, XTLabs, TargetProcess, Sphere Consulting, Интервэйл, Миратех, Partner Outsourcing, SDL International, Briteam, Logic Software, Golden Planet, Circle Development, MadCap, Aricent, Postindustria, Arkadium, Maxima Group, Cupid, Daxx.
Такое количество компаний свидетельствует о большом интересе к тематике конференции, потому как автоматизация тестирования является насущной проблемой практически каждой компании, а Selenium – один из лучших инструментов с данной сфере. Конференция станет уникальным событием, собравшим столько тестировщиков, имеющих отношение к Selenium, в одном месте. Участникам представится великолепная возможность поделиться своим опытом и проблемами с коллегами из других компаний.
Прием заявок от докладчиков закончен и программа конференции уже доступна. 17 докладчиков из различных стран представят вниманию участников 3 мастер-класса и 15 докладов. В качестве приглашенного гостя выступит David Burns – один из ключевых разработчиков Selenium, занимающийся драйверами под .NET и Python. Помимо этого David уже долгое время работает Senior Software Engineer по тестированию в Mozilla, являясь лидером команды по автоматизации тестирования. Также David – автор известного блога http://www.theautomatedtester.co.uk и одной из двух существующих на данный момент книг, посвященных Selenium – Selenium 1.0 Testing Tools: Beginner’s Guide. На конференции он выступит с докладом на тему “Selenium 2 : The future of Selenium is now!”.
В дополнение, участники смогут услышать, как осуществляется тестирование в известных больших компаниях, таких как Яндекс и Skype. Программа конференции очень насыщенная. Участники смогут узнать о различных аспектах автоматизации тестирования:
Накануне конференции, 19 и 25 февраля пройдут специализированные тренинги, посвященные тестированию веб-приложений с Selenium. С программой тренинга и отзывами участников вы можете ознакомиться на сайте тренинг-центра XP Injection. Этот тренинг очень хорошо покрывает все части продукта Selenium, имеет практическую часть, освещает методики тестирования и интеграцию с другими инструментами тестирования. Он предназначен как для новичков, так и для профессионалов – каждый гарантированно узнает много нового. Эти тренинги дополнят конференцию, сделав ее еще более полезной и интересной.
Конференция Selenium Camp – это уникальный шанс пообщаться вживую и задать интересующие вопросы известным докладчикам и профессионалам в применении Selenium для автоматизации тестирования. С 1 февраля начинается последний этап регистрации. Только до 14 февраля вы сможете присоединиться к участникам конференции по цене 600 гривен. Торопитесь, количество мест ограничено!
Вчера на территории компании Ciklum прошла первая в Украине встреча Agile PechaKucha. Это была встреча в неформальной обстановке с пивом, пиццей и насыщенным общением. Собралось немало людей, заинтересовавшихся данным форматом встреч. Некоторое время назад я описывал как проходят такого рода мероприятия. Мои впечатления сугубо положительные. Формат понравился – все очень быстро и динамично, без скучных долгих докладов. Времени хватает и на то, чтобы послушать докладчика и задать все интересующие вопросы. Докладчики тоже порадовали своей подготовкой, презентации получились очень живые. Большое спасибо организаторам за то, что пригласили поучаствовать и выступить с докладом. Я подготовил доклад “Agile. The way from chaos to flow” на тему эволюции Agile подходов и важности всех шагов на пути каждой команды.
Алексей Солнцев выступил с докладом “Agile: вид из окна тренажёрного зала”, в котором провел параллель между Agile подходами и занятиями в тренажерном зале. В докладе прозвучало множество конкретных примеров и аналогий из жизни, интересные советы и практики. Данная аналогия заставила взглянуть под другим углом на процесс разработки и управления командой.
Хотелось бы пожелать организаторам успехов в этом начинании и еще много интересных встреч в формате PechaKucha!
Очень много времени в разработке отводится написанию кода. Над кодом работают разные люди, часто несколько “поколений” программистов меняются в течении жизненного цикла одного проекта. Поэтому вопрос относительно комментариев возникает достаточно часто. Стоит ли их писать? Когда и кто должен их писать? Я решил написать о моем личном подходе к комментариям.
Начнем с самого определения к комментариям. Для меня они образно делятся на два типа: документация публичного API и все остальные комментарии. С публичным API все просто – без комментариев в нем зачастую просто никак. Связано это в первую очередь с тем, что для публичного API не всегда доступны исходники, но при этом нужно предоставить информацию пользователям о правилах использования. Как бы классно вы не называли интерфейсы, классы, методы и параметры, это не даст представления об общей логике использования API, частных случаях и особенностях применения. Могли бы помочь модульные и интеграционные тесты, но они не всегда включаются в поставку или отсутствуют. Да и представьте себе насколько возрастут усилия по применению API, если вам нужно будет постоянно разбираться с чужими тестами. В итоге мой вердикт таков – если у вас есть API, который для кого-то является публичным, то вы просто обязаны снабдить его документацией в виде комментариев. Чтобы эти комментарии не устаревали и не теряли своей актуальности, внесите пункт об их обновлении в критерии готовности кода.
Теперь перейдем ко всем остальным комментариям. С моей точки зрения они абсолютно бесполезны и позволяют разработчикам “дать слабину”. Написали вы сложный и запутанный кусок кода, который понятен только вам, и думаете что же делать. И тут приходит решение – добавил комментарий и готово. Просто и быстро. Реализовали вы “hack” вместо нормального решения и написали рядом: “Лучше не трогайте этот код, если дорожите своим местом работы”. И вроде все хорошо. Если у вас есть время и желание посмеяться, то я настоятельно рекомендую почитать примеры такого рода комментариев. Отлично проведете время! Но давайте задумаемся для чего мы пишем комментарии? В основном для того, чтобы сообщить следующему разработчику некую важную информацию. Для этого мы выбираем текстовый формат комментария, который будет жить параллельно с самим кодом. Именно это и является причиной всех бед с комментариями: устаревание, неактуальность, бесполезность и так далее. Вместо этого нужно искать лучший способ передачи информации.
Таким способом является использование самого кода. Ведь нам доступно множество способов сохранить информацию для следующего разработчика: имя класса, имя метода, имя переменной, имя параметра и многие другие элементы кода. Не стоит экономить на длине имен, современные средства разработки очень хорошо визуализируют программный код. Я приведу небольшой пример из недавней практики. При сохранении сущности в базу данных в той же транзакции сохраняются ее дочерние сущности, которые в свою очередь являются связками к существующим сущностям (отношения многие ко многим). К сожалению, в реализации MySql вставка блокирует внешний ключ на таблицу, что легко приводит к дедлоку (deadlock) при одновременной вставке нескольких сущностей с одинаковыми дочерними. Помогает в данной проблеме сортировка дочерних сущностей по первичному ключу, чтобы блокировки захватывались в одинаковом порядке. В код перед сохранением была добавлена сортировка, которая с виду казалась абсолютно бесполезной. Думаю, очень скоро ее бы запросто удалили при рефакторинге кода. Первая мысль, которая возникла у многих – нужно добавить комментарий с описанием причины происходящего. Вместо этого сортировка была вынесена в отдельный метод с названием orderXXXToPreventDeadlock, название которого содержала точно такую же информацию как и комментарий, но при этом оставаясь частью самого кода. Дополнительный плюс указанного решения в том, что этот метод по сортировке стал хорошим кандидатом на повторное использование в других местах с подобной проблемой.
Второй отличный способ избежать комментариев – это модульные и интеграционные тесты. Они являются одновременно и документирующим и контролирующим органом. Имея тесты хорошего качества, очень просто выяснить с какой целью был написал конкретный кусок кода и как им пользоваться. Дать совет писать и поддерживать в хорошем состоянии свои тесты гораздо проще, чем это делать. Но поверьте мне – ваши усилия вернуться оправдают себя в ближайшей перспективе, особенно при изменений существующего кода. Лучший способ контролировать использование комментариев в коде – это практика Code Review. Она способствует приведению кода к такому состоянию, в котором комментарий просто становится ненужным. Вы вкладываете все байты необходимой информации в код, попросту меняя способ ее представления.
Каково ваше отношение к комментариям в коде? В каких случаях вы не могли обойтись без них?
Мы уже упоминали о том, что 27 января в Киеве пройдет первая Agile PechaKucha. Я думаю что мало кто представляет, что это такое. Поэтому я решил написать поподробнее об этом событии, тем более от нашего тренинг-центра заявлено два докладчика. Agile PechaKucha – это неформальная встреча, посвященная вопросам гибкого управления проектами и всему, что с этим связано: планирование, тестирование, люди, инженерные практики и прочие темы. Формат встречи продиктован принципами, заложенными в PechaKucha. Каждый докладчик представит презентацию в формате 20 слайдов по 20 секунд. С одной стороны это достаточно жесткие рамки для докладчика, но с другой стороны данные ограничения заставляют лучше готовиться и не тратить попусту время слушателей. Таким образом за 2 часа вы сможете прослушать 8 презентаций от разных докладчиков: 6 минут 40 секунд презентация и столько же времени на вопросы докладчику. Подобные мероприятия с разнообразной тематикой проходят по всему миру. Теперь PechaKucha есть и в Киеве, а значит данный формат может быть опробован для проведения встреч на тему гибкой разработки.
Я был приглашен в качестве докладчика и с радостью принял это предложение. Тема для доклада была выбрана “Agile. От хаоса к состоянию потока.”. Речь в докладе пойдет о том, какие шаги проходит команда в процессе эволюции, применяя Agile методологии. Как от хаоса придти к состоянию потока (некое подобие Continuous Delivery), какие методологии и практики используются на промежуточных шагах, какова цель их использования. Попутно будут освещены последние тенденции в мире Agile и мое отношение к ним. Надеюсь, что формат встречи отлично подойдет для подобного выступления. Также с докладом выступит и Алексей Солнцев. Он расскажет о схожих факторах в применении Agile методологий практик и жизненных активностях человека, таких как занятия спортом.
Количество участников ограничено, стоимость участия невелика – 50 гривен. Это позволит отсечь людей, которым мероприятие не так интересно, а организаторам упростит финансовую сторону организации. Приходите, будет интересно!
Я неоднократно слышал вопросы о том, как научиться хорошо оценивать. Эта тема бурно обсуждается и будет продолжать обсуждаться в Agile сообществе. Ведь все хотят поменьше ошибаться и давать точные оценки постоянно. Но как этого добиться?
Речь пойдет не о какой-то определенной технике оценивания. Все гораздо банальнее. Хотите научиться хорошо оценивать – оценивайте как можно чаще. Давайте вспомним школу – мы решали множество примеров на одну и ту же тему, делали домашнее задание, писали самостоятельные и контрольные работы. И все это для закрепления определенных знаний, переданных нам учителем. Точно так же и с оценками. Для того, чтобы понять и набрать достаточный опыт, нужно оценивать постоянно и анализировать результаты своих оценок.
Для этого у нас все есть, нужно только найти в себе силы начать. Первая возможность оценивать нам предоставляется на этапе планирования итерации. К ней стоит подойти с особым вниманием, потому что на данном этапе у вас будет возможность не только дать свою оценку, но и сравнить ее с другими. А это огромный плюс. Обязательно пометьте себе все задачи, по которым были расхождения в оценках, запишите основные аргументы других членов команды. Это поможет вам в анализе результатов итерации. Его можно провести в конце итерации или непосредственно перед планированием следующей итерации. Проверьте все оценки, пересмотрите аргументы и несогласованности для задач, оценки на которые оказались неточными. Таким образом вы тренируете свой мозг на автоматическое принятие решения об оценке на базе имеющегося опыта.
Следующая возможность дать оценку появляется у вас в момент начала работы над задачей или разбиения ее на подзадачи. Подумайте и дайте оценки, исходя из своего опыта в работе над подобными задачами и профессионального чутья. Подобных оценок будет больше всего, а значит это огромное количество практики. По мере работы над задачей контролируйте правильность оценок и делайте выводы. Некоторые техники организации ежедневной работы заведомо предполагают оценивание в качестве обязательного атрибута, к примеру техника Pomodoro, о применении которой я рассказывал на одной из конференций. Очень помогает автоматизация проверки оценок. Для этого подойдет таблица Excel или специализированный инструмент, к примеру Pomodairo. С помощью данных инструментов можно легко посчитать процент точности оценок и различные показатели отклонений. Контролируя эти метрики, можно отслеживать свои успехи и неудачи. Используя технику оценивания каждый день, вы начинаете оценивать гораздо быстрее и точнее, а значит реже попадете в стрессовые ситуации, вызванные спешкой.
Еще одна отличная возможность пооценивать предоставляется вам на планировании релиза или даже целого продукта. Это может быть как ваш проект, так и экспертная группа для нового проекта. Постарайтесь принять участие, даже в качестве второстепенного участника. Данный процесс станет отличной проверкой имеющихся навыков.
В заключении хотелось бы подытожить: для того, чтобы делать что-то действительно хорошо, нужно либо иметь талант к этому либо долго и упорно работать. И тогда все обязательно получится!
В этом году 10 лет со дня подписания переломного документа для индустрии программной разработки – Agile-манифеста (www.agilemanifesto.org)! Этому событию будет посвящена целая серия конференций AgileBaseCamp в 2011 году. Первая из них состоится во Львове 5 февраля. Не так много конференций проходит в западной части Украины, поэтому надеюсь эта конференция положит начало новой положительной тенденции.
Сейчас идет активная работа над программой конференции. На сегодняшний день подтвердили свое участие в качестве докладчиков:
Конференция AgileBaseCamp – это хорошая возможность найти ответы на свои вопросы, познакомиться с практиками гибкой разработки, узнать про новые веяния и хорошие практики в индустрии от практикующих экспертов, поделиться своим опытов и услышать об успехах и проблемах коллег, хорошо и весело провести время в мире Agile. Торопитесь зарегистрироваться на конференцию по цене ранней регистрации – 350 гривен. Данное предложение действует только до 24 января!
