Kafka сейчас на таком хайпе, что её добавляют во все проекты без исключения. А чтобы было легче интегрироваться с уже используемыми системами есть проект Kafka Connect. https://www.confluent.io/product/connectors/

Отличное видео очень полезного доклада на тему улучшения ваших модульных/интеграционных тестов, особенно при работе по TDD. Реальные советы от практика своего дела. https://youtu.be/NzknrbrV8BY

Selenium IDE восстаёт из мертвых как птица Феникс. ;) https://seleniumhq.wordpress.com/2018/08/06/selenium-ide-tng/

Аджайл, спринты, стори, continuous delivery, все дела... :))) https://youtu.be/SDWqwlsGJCQ

А вот видео посерьёзней последнего, из которого помимо общеизвестных подходов CI и CD можно почерпнуть практических примеров как Docker помогает разработчику в быту. https://youtu.be/DL6stEqYH_g

Мы тут открыли blind birds этап регистрации на конференцию XP Days Ukraine, а значит первые 100 билетов доступны по минимальной цене. Обычно они расходятся за пару дней, так что не тормозим. ;)

Данную конференцию мы проводим уже 7 лет. Изначально она задумывалась как площадка для обмена опытом людей, использующих хорошие инженерные практики в разработке. Тогда речь шла в основном о практиках XP (eXtreme Programming), откуда зародилось название конференции.

Шли годы и архитектурные подходы стали сильно влиять на реализацию инженерных практик, а также особенности их внедрения. Дальше на все это наложилась DevOps культура и мы получили связку направлений, от которых зависит то, насколько быстро, надежно, эффективно и качественно команды и компании могут разрабатывать свои продукты и сервисы. Как нельзя лучше на текущий момент ее описывает термин Engineering Excellence. А команда спикеров будет этим самым excellence делиться с участниками на основе своего опыта. Присоединяйтесь!

https://xpdays.com.ua/registration/

Интересно, что уже больше года доступна и активно развивается новая версия JUnit 5. Тем не менее, по моему опыту в разных компаниях и сообществах, переходят на него очень медленно. Вот прямо совсем как черепахи. Почему?

Кто-то сильно завязан на конкретную версию остальными фреймворками и библиотеками, кто-то просто не парится, кому-то достаточно функциональности JUnit 4...

И вот случилось то, о чем так много говорили когда вспоминали недостатки JUnit: появилась поддержка параллельного запуска тестов из коробки. Как думаете, ускорит ли эта мощная фича переход на JUnit 5?

https://junit.org/junit5/docs/5.3.0-RC1/release-notes/

Из своего опыта я вижу 3 основных причины, по которым проваливается внедрение DevOps культуры в компаниях Украины (по факту я знаю до 5 компаний, где эта культура есть не только на словах):

1. Нежелание людей и компании делать серьезные изменения. Люди не любят меняться и натурально сопротивляются. А многим компаниям важно задекларировать ценность, а не достичь чего-то путём сложных изменений.

2. Непонимание как должен выглядеть этот самый DevOps в конкретной компании, в конкретной команде, в конкретном проекте. Абстрактные ценности всегда тяжело адаптировать к реалиям.

3. Коммуникационный барьер. Разработчики и инфраструктурные инженеры - не самые коммуникабельные группы в IT. А налаживать эту коммуникацию часто никто не берётся, потому что сложно.

Так вот, я о чем подумал. Похоже пора вводить новый job title наподобие DevOps Coach или DevOps Evangelist, задача которого будет каждый день решать перечисленные проблемы. Он должен чётко понимать как должно выглядеть вопрошение DevOps культуры в конкретном контексте, отталкиваясь от решаемых проблем и ограничений. Каждый день он должен работать над построением и улучшением коммуникации между разработчиками и инфраструктурными инженерами, а также помогать людям и компании меняться.

Мега-полезная роль, как по мне!

Отличная статья про отличия CTO от VP of Engineering и Program Manager. Если бы все выполняли свои функции согласно такому пониманию ролей, жить было бы куда проще. https://medium.com/engineering-leadership/defining-roles-cto-and-or-vp-engineering-f1c7563643a3

Забавная метрика покрытие кода тестами. У неё есть 2 моих любимых момента, которые вызывают больше всего удивления:

1. Люди свято верят в 80% покрытия как важную цель и «стандарт по индустрии», хотя ещё никто не смог объяснить, откуда этот «стандарт» взялся. Есть только вариант про принцип Парето, но кто и зачем притянул его к коду и покрытию тестами вообще непонятно. Но люди меряют, конролируют, допокрывают, радуются...

2. Гордость за близкое к 100% покрытие тестами и убеждённость, что это говорит о качестве продукта. Покрытие, к большому сожалению, говорит нам лишь о том, что написанный код покрыт тестами в том виде, как он работает сейчас. А работает ли он правильно и решает ли проблемы бизнеса - это большой вопрос. А также открытый вопрос: стоило ли тратить столько усилий именно в этом продукте/сервисе на написание такого количества тестов? Или стоило лучше сконцентрироваться на новой функциональности?

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

И снова рубрика «шёл 2018 год...». Появился адекватный плагин для визуализации отчётов по покрытию кода в Jenkins. :) https://jenkins.io/blog/2018/08/17/code-coverage-api-plugin-1/

Мне кажется, что “no meetings day” - это одна из лучших практик для команды разработки чтобы поднять эффективность работы. Все просто: выбираете один, а лучше два дня в неделе, в которые запрещены любые митинги за исключением работы в микрогруппах по 2-3 человека.

Особенно полезна данная практика для команд, работающих в большом оупенспейсе, где и так трудно сосредоточиться на работе. А что делать, если срочно хочется поставить митинг в этот день? Перехочется! ;)

А у нас тем временем осталось только 7 билетов на первом этапе регистрации на конференцию XP Days Ukraine 2018. Ещё есть шанс ухватить билет по низкой цене. https://xpdays.com.ua/registration/

Ну теперь уже точно будет стыдно не ответить на собеседовании как устроен HashMap в Java. Инструкция «на пальцах». :) https://m.habr.com/post/421179/

Code Review сам себя не организует. Нужны SLA, инструментарий, боты с нотификациями в чат/почту, описанные стандарты, статический анализ для автоматизации и т.д. https://m.habr.com/company/yandex/blog/421129/#habracut

За долгие годы консалтинга я сделал один важный жизненный вывод: никакая качественно сделанная работа или услуга не должна делаться бесплатно или дёшево. Причина в том, что люди не уважают и не ценят то, что достаётся им «на шару». Многие даже не относятся к бесплатной работе серьезно. «Раз это бесплатно, там нет ничего ценного» - думают они. Но что если вам важно сделать что-то для будущего сотрудничества или для демонстрации своего уровня? Есть два варианта:

1. Явно задекларировать, что при дальнейшем сотрудничестве вы включите уже выполненную работу в общую стоимость услуг. Если дальнейшего сотрудничества не будет, то оплата должна быть отдельной.

2. Клиент имеет право не платить за работу или услугу при официальной аргументации причин.

В обоих случаях стоит помнить о том, что долг != оплата и многими воспринимается на уровне «мы за это не платим». Поэтому не советую накапливать долг со стороны клиентов.

Ну и конечно же, речь идёт именно о качественной работе, услуге или сервисе...

У многих неопытных водителей бытует заблуждение, что чем быстрее гонишь, тем быстрее приедешь в конечный пункт назначения. И они делают простые расчеты наподобие: ехать 400 км, буду лететь 200 км/ч и приеду в пункт назначения через 2 часа. Более опытные водители понимают, что важна именно средняя скорость на всей протяженности пути, так как именно она определяет за какое время вы доберетесь до цели. Можно лететь 200 км/ч, но большая загрузка трассы, постоянные торможения и аварийные участки не дадут развить среднюю скорость выше 150 км/ч. В результате, практически не было смысла в такой точечной скорости и вполне могло быть достаточно ехать 150-160 км/ч для такого же результата. Затраты топлива, нервов и сил в этом случае будут гораздо ниже.

Ровно такие же размышления есть у некоторых представителей менеджмента: нужно выдавать высокие показатели скорости разработки в каждой конкретно взятой итерации. Но ради этих показателей команда идет на определенные жертвы в области качества, накапливает технический долг, у членов команды накапливается усталось и даже растет шанс выгорания. Зато можно похвастать точечным достижением в одной отдельно взятой итерации. Именно поэтому я никогда не любил название Sprint из Scrum. Суть итеративного подхода не в том, чтобы "пробежать" одну итерацию на максимум усилий и потом "умереть", а в том, чтобы научиться бежать в определенном темпе "длинную дистанцию".

Сегодня мы поговорим о пользе собеседований. Я сам регулярно нахожу время сходить на собеседование и всем советую это делать. Даже если вам хорошо на текущем месте работы. Даже вас не интересует смена работы в принципе. Зачем же тогда ходить на собеседования? Есть несколько причин:

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

2. Узнавать так называемые unknown unknowns - это те области, которые вы не знали что не знали. Возможно, они не были релевантны вашему опыту, а может быть вы пропустили какие-то важные и интересные новинки.

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

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

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

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

Я могу перечислять и дальше, но уже видно, что собеседования - достаточно полезная активность. Нужно только выбирать подходящие к вашим целям предложения и не тратить на это слишком много времени. :)

В соседнем канале поделились новостью о выходе онлайн IDE для GitHub. В рабочих проектах мало применимо, на мой взгляд, а вот для быстрых точечных правок и навигации по коду чужого репозитория очень даже может быть полезным. https://medium.com/gitpod/gitpod-gitpod-online-ide-for-github-6296b907a886

Несмотря на то, что до закрытия Call For Papers на нашу конференцию XP Days Ukraine 2018 остается еще более месяца, мы активно ищем докладчиков по выбранным направлениям и уже получили достаточно много заявок на доклады. Скоро программный комитет проведет первый раунд ревью поданных заявок и мы начнем публиковать предварительную программу. Если вы знаете кто из ваших знакомых мог бы поделиться своим интересным и полезным опытом, то обязательно напишите нам. В случае успешного приема докладчика мы готовы дать вам индивидуальную скидку на билет. ;) https://xpdays.com.ua/speakers/