Компания ScrumTrek и сообщество AgileRussia уже начали готовить для всех поклонников Agile подходов очередную конференцию Agile Days 2014 — крупнейшую восточно-европейскую конференцию Agile и Lean сообщества. Основная цель конференции — обмен передовым опытом использования гибких методологий разработки программного обеспечения. В прошлом году мероприятие посетили 700 участников из более чем 300 различных компаний, а в этом планируется еще больше.
Благодаря неформальной обстановке, все, начиная от менеджеров проектов и скрам-мастеров и заканчивая теми, кто только присматривается к этим методам, получили возможность обсудить любые проблемы и вопросы. Конференция позволяет встретиться с коллегами, изучить передовой мировой опыт гибкой разработки и даже открыть новые возможности карьерного роста.
Как и во все предыдущие годы, на конференции выступают с докладами специалисты мирового уровня. Например, в главной секции Agile и Lean выступит David J. Anderson, глава Lean Kanban INC. Сцену с ним разделят Dragus Dimitriu и Bjarte Bogsnes, признанные профессионалы в области методов Kanban и Agile.
В этот раз на конференции запланировано 5 параллельных потоков, посвященные отдельным аспектам разработки ПО: Agile/Lean Mindset, Experience Reports, Product Development, DevOps. Отдельная секция отведена под игрофикацию процессов, являющуюся мировым трендом.
Вот несколько отзывов от участников прошлого года:
«Очень позитивное впечатление. Будто-то очень хорошую книгу прочитал по Lean/Agile за 2 дня. Очень хорошо видна сходимость основных проблем зрелости Agile в РФ» – Илья Кузнецов, зам. руководителя управления разработки, Лаборатория Касперского.
«Среди участников AgileDays очень много людей, разделяющих близкие нам ценности» – Виктор Ламбурт, директор по разработке, Объединенная компания Афиша—Рамблер.
У меня с прошлого года остались тоже очень позитивные эмоции, поэтому в этом году я снова подал заявку на доклад. Возможно, буду очередной раз одним из представителей Agile тусовки Украины на AgileDays’14. 🙂
Мы работаем над тематикой следующей встречи «Клуба анонимных разработчиков», которую анонсируем на следующей неделе. Пока же мы решили опубликовать расписание инженерных тренингах, которые пройдут в ноябре-декабре этого года.
Тема архитектуры и дизайна собирала больше сотни участников на встречах клуба, поэтому мы пригласили опытного тренера из Москвы Евгения Кривошеева прочитать отличный курс на эту тему. Тренинг называется “Дизайн и архитектура в Agile” и предназначается для разработчиков, архитекторов, лидеров команд и менеджеров проектов. Это отличный способ закрыть все пробелы в архитектуре и дизайне современных приложений. Ознакомьтесь с детальной программой, оно того стоит. Тренинг состоится 10-11 декабря, стоимость 2500 гривен.
Опытный TDD-гуру и .NET-практик Сергей Калинец в очередной раз соберет .NET разработчиков на свой тренинг “TDD в .NET”. Сергей построил действительно очень практический тренинг, на котором большую часть времени участники пишут код под руководством тренера. Через практику TDD дается гораздо проще. При этом есть возможность узнать много нового от профессионала своего дела. Тренинг пройдет 15-16 ноября, стоимость участия составляет 2000 гривен.
Это один из самых информативных наших тренингов. Его проводит Николай Алименков и он приготовил для участников увлекательный рассказ о 8-ми инженерных практиках. За два дня тренинга вы можете получить целостную картину эффективного процесса разработки с точки зрения его технической составляющей. В программу вошел весь многолетний опыт и знания тренера в области применения и внедрения инженерных практик. Вы можете оценить программу тренинга. Он состоится 6-7 декабря, стоимость участия 2000 гривен.
Тематика DevOps в последнее время обретает все большую популярность. Автоматизация настройки окружения стало обыденной работой, особенно в случае развертывания приложения в облачной инфраструктуре. Chef является одним из самых популярных инструментов в этой области. Андрей Самиляк уже выступал в клубе на эту тему. Но теперь он решил собрать весь опыт воедино и подготовил практический курс из 5-ти занятий по 3 часа. Занятия будут проходить по средам с 19:00 до 22:00, начиная с 20 ноября, и ориентированы сугубо на практическое применение техник и инструментов. Стоимость 2000-2400 гривен в зависимости от даты регистрации.
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
На конференциях мне несколько человек задало один и тот же вопрос по поводу выпуска рубрики полезного чтива. Значит кто-то ее читает и кому-то она нужна. Поприветствуем очередной выпуск:
А вот список интересного видео для просмотра:
Читайте и набирайтесь новых знаний!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Вчера я сходил на первую встречу DevOps клуба и был расстроен напрасно потерянным временем. Дело не в задумке и не в организации, а в подходе докладчиков к своим выступлениям. Я в этой короткой статье постараюсь выразить свое видение полезного доклада на текущий момент. Оно не всегда было таким, а эволюционировало по мере того как я посещал и сам организовывал множество разнообразных мероприятий. Ниже вы найдете несколько простых правил хорошего доклада.
Первое правило можно сформулировать так: “если ты делаешь доклад только для того, чтобы сделать доклад, то лучше его не делать”. Если тема доклада для вас не является важной и вы не стремитесь поделиться своими идеями с другими, не считаете их реально клевыми, то вы не сможете заразить этим ощущением аудиторию. В итоге, доклад может получиться сухим, безэмоциональным и не сильно практическим.
Второе правило гораздо важнее: “не пытайтесь рассказать обо всем сразу”. На эти грабли я сам неоднократно наступал. Хочется рассказать целиком обо всем подходе, об инструменте, библиотеке или решении, дать как можно больше “полезной” информации слушателям. А получается совсем наоборот. Во-первых, вы начинаете торопиться, чтобы все успеть рассказать, упускаете детали, недостаточно времени уделяете основам. Во-вторых, за лесом не видно деревьев – на фоне многих “полезностей” теряется сама суть доклада. Как результат, на половине доклада половина аудитории еще переваривает вступление, а вы уже кидаете в нее “очередную классную фичу”.
Гораздо больше пользы получит участник, если вы полностью продадите ему одну или несколько самых важных идей, при этом показав дорогу для дальнейшего развития и нахождения деталей. Именно проданная идея заставляет поставить себе заметку после доклада о том, чтобы обязательно попробовать тему доклада на практике. Если вы освещаете фреймворк, библиотеку, подход или инструмент, то начинайте с проблем. Причем тех проблем, которые волнуют ваших слушателей. Если вы не угадали с проблемами, то в конце доклада можете получить вопросы наподобие: “а зачем вообще этот подход использовать, если …?”, “а почему вы не избавились от проблемы целиком с помощью …?”, “но это же совершенно неактуально в …!”.
Третье правило можно сформулировать так: “продавайте идеи”. Вашей целью должен быть не просто рассказ на людях, а попытка продать ваши идеи аудитории. Чтобы что-то продать нужно приложить усилия. Это не так просто как читать материал своего доклада. Если вы доказываете инновационность чего-то, то покажите как было раньше и как будет теперь. Покажите на ярких примерах, используя проблемы, знакомые каждому в аудитории. Если вы делаете обзорный доклад, покажите как на практике решить важные задачи, продемонстрируйте несколько крутых сценариев применения, сравните с другими аналогами. Фразы “ну там еще есть роли, это понятно”, “тут можно делать наследование, если вы захотите”, “как обычно пишем рецепты вот в такую структуру директорий” для большей части аудитории может звучать как “бла-бла-бла”…
Четвертое правило: “старайтесь как можно меньше использовать субъективное мнение в технических докладах”. С необоснованным субъективным мнением нужно быть всегда очень аккуратным, а особенно в технических докладах. Все знать невозможно и не стоит этого скрывать. А говорить, что этот фреймворк или подход правильный только потому, что лично вам он нравится – это совершенно бессмысленно для ваших слушателей. Вы могли просто не знать об аналогах, не разобраться с ними или просто еще не наступить на кучу граблей.
Следующее правило: “не отрицайте существования других решений и подходов”. Ситуаций бесконечное множество и универсальных вещей не существует. Никогда не пытайтесь продавать очередную “серебряную пулю”. Это снова может указывать на узость ваших взглядов и ставит под сомнения те вещи, о которых вы говорите в своем выступлении.
Заключительное правило: “отвечайте на все вопросы, но не вступайте в дискуссии”. Впечатления от любого доклада могут испортиться бесполезной дискуссией, в которой чаще всего обсуждаются мелочи, слишком глубокие детали или альтернативные подходы. Аудитория на таких дискуссиях обычно начинает скучать, поэтому лучше всего их сразу переносить на перерывы и сдерживать себя. Отвечать нужно на все вопросы участников, даже если не все успели их задать во время доклада. Незаданные вопросы лучше тоже перенести в перерыв, но обязательно на них ответить. Иначе у некоторых участников может сформироваться неправильное видение и он будет его распространять под “вашим флагом”.
А какие бы вы советы дали докладчикам? Буду рад услышать их в комментариях!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Неделя после прошедшей 9-12 октября конференции XP Days Ukraine 2013 была очень насыщенной и никак не хватало времени сесть и написать организаторский отчет. Хотя, по сути, и писать то особо нечего. Это была первая конференция, в которой мне с точки зрения организации все понравилось. А я ооочень редко остаюсь доволен, потому что везде вижу недостатки. 🙂
Начнем пожалуй с тренингов. В этом году мы решили немного сократить их количество и провели только 4 параллельных тренинга. Как обычно это TDD в Java и .NET, инженерные практики в Agile и Agile тестирование. Тренинги поселили около 70 участников. Мы все еще ищем удобное помещение для того, чтобы проводить все тренинги в одном месте. Это бы сильно упростило жизнь и нам и участникам.
На саму конференцию мы в этот раз заведомо ограничили количество мест, выставив на продажу 300 билетов. Все они были распроданы за 2 недели до мероприятия, что не может не радовать. Не смотря на переход к двухдневному формату, количество участников растет с каждым годом.
Мы уже достаточно много провели конференций, чтобы набить шишки с регистрацией участников. Поэтому в этот раз все прошло очень гладко и без очередей. Очереди за два дня конференции были только в гардероб в первый день и рассосались за 5-7 минут, а также в мужской туалет (серьезное отличие от конференций для тестировщиков). В этом большая заслуга наших замечательных волонтеров, за что им огромное спасибо!
Мы перестаем влазить в стены конференц-центра в БЦ “Парус”, поэтому в перерывах между докладами в холле было немного тесновато. Это является стоп-фактором роста конференции и мы тщательно ищем альтернативные места проведения. Но зато в этот раз мы еще лучше продумали расстановку докладов по залам. В итоге, ни на одном докладе сцена B не была переполнена и в обоих залах были свободные места. Позитивную атмосферу передает небольшой фотоотчет с места событий:
Мы не имели возможности обеспечить участников обедами, но постарались компенсировать их отсутствие вкусными и обильными кофе-паузами. За что получили немало позитивных отзывов от участников. Было и вкусно и много.
Мы практически решили проблемы с интернетом. В этот раз был подключен выделенный канал 50 MB/s и профессиональное оборудование Cisco. Единственной проблемой за 2 дня стал DHCP сервер, который не удалял старые IP адреса и поэтому часть участников не могла присоединиться. Жаль что в первый день мне никто не сказал об этом, потому что проблему быстро решили как только стала понятна ее причина.
Скажу пару слов о докладах. Во-первых все докладчики очень хорошо подготовились. И те, кто выступает уже не первый раз, и те, кто на сцене впервые. Большое им спасибо за их труд! Все они с честью выдержали наши стадии процесса ревью докладов и приложили максимум усилий к своим презентациям. О выборе основных направлений и тем для этой конференции я уже писал. Лично я остался очень доволен тем, как эти темы были раскрыты. Мы обработали анкеты обратной связи и выбрали лучших докладчиков по отзывам участников. В этом году мы впервые запустили еще одну отдельную форму обратной связи по программе конференции. Мы хотим собрать мнения и отзывы участников, чтобы в следующем году сделать программу еще более интересной и полезной.
В оба дня конференции мы позаботились об afterparty и заказали столики в Натюрлихе. Первый день конференции совпал с матчем на ЧМ между Украиной и Польшей, что добавило веселья. Около 70 участников болели вместе с нами. Была очень теплая и дружеская атмосфера. Об успехе вечерних посиделок можно было судить по ленивому утреннему потоку участников на следующий день. 🙂 Во второй день людей на вечеринке было поменьше, ведь очень много участников приехали их других городов. Но, тем не менее, afterparty удалось на славу!
На закрытии конференции мы по традиции разыграли призы и подарки от нас и спонсоров конференции. В этом году впервые столько компаний нас поддержали. Мы очень благодарны за поддержку! Спонсоры два дня развлекали участников, дарили подарки и сувениры, а на закрытие подготовили ценные призы. Дисковые накопители, вертолет, майки, книги – много кто ушел с конференции не с пустыми руками. Я даже забыл о том, что мы собирались разыграть 3 лицензии на Intellij IDEA. Пришлось сделать это уже позже случайным выбором анкет обратной связи.
Я бы хотел отдельное спасибо сказать участникам за их конструктивную обратную связь. С каждым годом мы совершенствуемся, а ваши подсказки дают нам возможность это делать. А такое количество позитивных отзывов и благодарностей позволяет понять, что мы делаем действительно полезное и важное дело. Спасибо вам!
В заключение, немного о моих докладах. Их должно было быть два, но судьба распорядилась иначе. У нас снова произошел форс-мажор и один из докладчиков вынужден был срочно улететь из Киева. Поэтому я заменил его и рассказал свой старый доклад о Continuous Delivery:
Второй мой доклад был в секции мини-докладов и я рассказывал о важности роли Technical Lead для успеха Agile проекта:
Последний доклад был на тему тестирования уровня доступа к БД в Java и особенно работе над этим уровнем по TDD:
Мы с нетерпением ждем XP Days Ukraine 2014. Уже есть много новых задумок по программе и формату конференции. Ждем вас в следующем году!
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
Давненько я ничего не писал. Было много конференций, тренинги и надо было еще и просто отдохнуть. Эту статью я хотел бы посвятить достаточно простому вопросу, который будоражит мир Java достаточно давно – использование оператора ‘+’ для строк. Как известно, раньше это считалось правилом дурного тона, потому что в ответ на применение ‘+’ для двух строк создавалась новая строка и содержимое первых двух копировалось в новую. Это добавляло как в использовании памяти, так и к работе CPU. Вдобавок страдал и сборщик мусора, работы которому мы подкидывали изрядно больше. Вопросы на эту тему были практически на каждом собеседовании и за незнание ответа “сурово карали”. 🙂
В качестве альтернативы Java разработчик должен создавать StringBuilder и добавлять в него строки, после чего вызывать toString() для формирования результата. Прошло время и компилятор научился в некоторых случаях заменять использование оператора ‘+’ на использование StringBuilder. Это отлично работает при самых распространенных случаях “плоских сложений” без какой-либо логики и ветвлений. И тут Java разработчики расслабили булки и подумали, что теперь все заживут счастливо. Но не тут то было…
StringBuilder прячет за собой работу с результирующей строкой (на деле с массивом char) и там не все так просто. Достаточно заглянуть внутрь реализации AbstractStringBuilder чтобы увидеть как осуществляется операция добавления строки. Если текущий размер массива символов маловат, то он расширяется на необходимое значение (но не меньше чем в 2 раза) с копированием уже имеющихся данных в новый массив. По умолчанию начальный размер массива составляет 16 либо равен длине первого переданного фрагмента. Получается, при неудачном стечении обстоятельств вы можете получить многократное расширение внутреннего массива с полным копированием. И это лишь немногим лучше старого сложения строк с созданием новой строки.
Выходит проблема никуда не исчезла, а просто притаилась. Но кого она может затронуть? Затрагивает она тех, у кого операции сложения со строками производятся в местах очень частого использования. Например, при генерации ключей или логировании в DEBUG режиме. И тот и другой случай легко обходятся: для ключей стоит использовать составной ключ в виде отдельного класса, а для логирования в DEBUG режиме проверять isDebugEnabled() (это возможно откроет глаза тем, кто не понимал зачем нужны эти методы, если уровень логирования и так конфигурируется). Более общее правило можно сформулировать так: “Каждый раз, используя сложение строк, задумайтесь над тем, как часто будет вызываться этот код. Если предполагаются частые вызовы, оптимизируйте решение или откажитесь от сложения.” Это простое правило сохранит вам много нервов и времени. 🙂
Не хочешь пропускать ничего интересного? Подпишись на ленту RSS или следи за нами в Twitter!
