Мы открыли подачу докладов на конференцию XP Days Ukraine 2018. Изначально она была посвящена сугубо инженерным практикам, но со временем выросла до тематики Engineering Excellence, куда мы включаем дополнительно направления архитектуры и DevOps культуры.

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

Мы также существенно обновили программный комитет, поэтому программа обещает быть интересной. Если вам есть что рассказать по тематике инженерных практик (CI/CD, TDD, code review и т.д.), архитектуры (serverless, cloud native, масштабируемые высоконагруженные системы и т.д.), DevOps культуры (инструменты, подходы, практики), то мы будем рады видеть вас в команде докладчиков. Мы верим в отечественных докладчиков и помогаем им готовить доклады международного уровня. https://xpdays.com.ua/speakers/

Группа 40 человек на семинар Deep Dive: Testing Strategy набралась за 3 дня. Теперь можно записаться только в лист ожидания на следующую дату или на случай освободившегося места. :) https://xpinjection.com/trainings/deep-dive-testing-strategy/

У меня для вас решительно приятная новость! Теперь можно добавлять файлы в треды слака. Вроде маленькое, но очень полезное улучшение, которого многие уже и не чаяли увидеть. :) Отмучились, товарищи! https://twitter.com/slackhq/status/1021442226344415233?s=12

Гугл до 23 августа раздаёт на шару книгу The Site Reliability Workbook: http://services.google.com/fh/files/misc/the-site-reliability-workbook-next18.pdf.

Вышло свежее обновление IntelliJ IDEA 2018.2. Много всего полезного, а также приятные плюшки для владельцев новых макбуков. :) https://www.jetbrains.com/idea/specials/idea/whatsnew.html?landing&utm_content=newsletter&utm_campaign=idea&mkt_tok=eyJpIjoiTTJRNVpUTXdOak0wT1RWaCIsInQiOiI5V2dlbnQyQitsaHBoZlZQb1RXU1JaWHR2VlkwbmVUckZcLzJnYWVDUFwvNTFEQWk2VHNUdG9ORnl1RHB4ZVYwMVpkZ29JclVwWXEzYmdEdm5za0liSnZkU2t0WTUwMURsc3BsVWtiNDVuMHUwMGFMcFByRU5GYmZMWEU5bDlRUjdFIn0%3D

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

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

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

Я даже когда-то назвал это поведение «эффектом мудака»: при любой проблеме проще обвинить того, кто не с нами, так как назвать его мудаком за глаза очень просто. Вот так и живём... :(

Spring 5.1 уже на подходе. Пару релиз кандидатов и всё. https://spring.io/blog/2018/07/26/spring-framework-5-1-goes-rc1

Продуктовая разработка - особый мир. Тебе приходит в голову тысяча идей и сложно принять, что все они говно, а шанс выстрелить имеет только одна и то если повезёт. :) https://mc.today/my-pridumyvali-nikomu-ne-nuzhnye-uslugi-10-fakapov-daniila-tonkopiya-delfast/

Отличная статья о тестировании контрактов. Все по полочкам разложено со ссылками для более глубокого погружения. https://www.infoq.com/articles/contract-testing-spring-cloud-contract

Забавно, когда кто-то топит за тотальную автоматизацию тестирования и даже не допускает мысли, что в некоторых случаях она не нужна и даже вредна, так как тратит время попусту. https://m.habr.com/post/418491/#habracut

Интересно, а многие ли адепты Scrum помнят эту статью дяди Кона, который любит стори поинты и написал про них много чего, но в спринт задачи предлагает набирать по оценкам в часах? :) https://www.mountaingoatsoftware.com/blog/why-i-dont-use-story-points-for-sprint-planning

Товарищи, Kafka 2.0 уже почти с нами. Возрадуемся! https://lists.apache.org/thread.html/ba8fc98076fbbdcb5c125ece6c92e90bf6695794410752876f084bb4@%3Cusers.kafka.apache.org%3E

Ну и ещё есть время купить любую IDE от JetBrains со скидкой 50%. https://blog.jetbrains.com/blog/2018/07/30/celebrate-this-friendship-day-with-jetbrains-and-unwrap-your-presents

Большая часть IT компаний, которые представлены в Украине, имеют долгосрочную и краткосрочную стратегию развития. А в ней фигурируют «цели», основанные на ценностях компании и показывающие выбранное направление развития. Эти самые цели и представляют интерес в нашей сегодняшней заметке. В кавычки слово взято не случайно, ведь очень часто мы видим там вещи наподобие «поднять уровень самоорганизации», «улучшить ситуацию с качеством продуктов», «развить компетенцию ХХХ»...

Это слишком абстрактные цели и не факт, что они достижимы в абсолюте. Результаты тяжело померить, чётко продемонстрировать и превратить стратегию в тактику. Что ещё сложнее - это привязать к таким абстрактным целям личные цели и план развития сотрудника в компании. Как результат, они не связаны и менеджмент беспокоится об одном, а сотрудники совсем о другом.

Есть ряд подходов для исправления ситуации и один из них OKR (Objectives and Key Results). Упрощенно, подход выглядит так:

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

Подход используется во многих известных компаниях и неплохо себя зарекомендовал. Вот тут можно почитать чуть подробнее: https://www.talent-management.com.ua/3295-metodika-okr-objectives-and-key-results/.

Жизненная проблема большинства разработчиков. :)

Набор очень простых, но полезных советов для разработчика Spring Boot приложений. https://www.e4developer.com/2018/08/06/spring-boot-best-practices/

Хорошая подборка книг по Hibernate. Я читал 3 из 5 и все 3 могу сильно рекомендовать. https://javarevisited.blogspot.com/2018/08/top-5-hibernate-books-for-java.html?m=1#ixzz5Nb53TmEH