Анонс: Выступление в DevClub в Таллине 29 декабря.

В следующий вторник, 29 декабря, планирую быть в Таллине и поговорить в DevClub.EU о том как мы используем микросервисы для автоматизации тестирования.

Напочитать: Java-related issues

Очень много работы, поэтому бложек выходит не регулярно. 

 По крайней мере, до конца года.

1. Spotify слил в open-source свои наработки по микросервисам и мониторингу.
2. Еще один проект Мартина Томпсона - Argona.
3. Еще одна реализация библиотеки для формирования dot-файлов. Если вы думаете что этого г.... на каждом углу, то мои вам соболезнования.
4. Следующая порция хардкора про ресолвинг зависимостей, с благой целью - ресолвингом зависимостей на лету в уже работающее приложение. Читать тут.
5. Пара хороших overview-шпаргалок про коллекции и стримы в Java. Раз и два.
6. Концентрированный рассказ что же такое этот ваш Kubernetes.
7. Про тонкости отличий вертикального от горизонтального декорирования. Для эстетов, так сказать.
8. Динамическая инъекция кода в Java. Для этого правда нужно запускаться на JDK. Но можно и без этого.
9. Весьм интересный проект - byte-buddy.
10. Рекурсия безопасная для стэка. Ничего нового, но мало ли.
11. Промисы на Java - JDeferred.
12. О том почему ненавидят Spring - со многими пунктами согласен.
13. Хороший hello world по Spark а вот тут по Hadoop
14. QBit - Everything is a queue
15. инструменты для работы с JVM - топ-6 + bonus section.

Книга: Грег МакКеон. Эссенциализм

Эта книга несмотря на все свои обещания не даст вам чего-то практического. 

Это скорее методичка по теории. 

Она хорошо напомнит вам о том, что:

1. Выбор всегда за вами и если вы не делаете свой выбор его делают за вас
2. Нужно понимать что такое уступка. В первую очередь для себя. Ты не можешь сделать все что хочется, чем-то придется поступиться.
3. Чем больше размер проекта который вы делаете, тем больше над ним нужно просто думать. В тишине. Наедине с самим собой.
4. Записывай свои решения, не полагайся на память. Про этот тут недавно Максим Дорофеев хорошо набросил.
5. Игра и сон. Игры являются необходимой составляющей развития собственного потенциала. Сон -  это как топливо. Очень зацепила фраза «Сон как предмет роскоши»
6. Радикализм в части критериев. «Нельзя быть немножко беременной» - цель либо заводит, либо нет.
7. Нужно отбрасывать неудачное - склонность к невозвратным издержкам - инвестировать в проекты которые уже не удались. Иногда нужно пересмотреть то что ты сделал, переоценить это с чистого листа.

Все это очень красиво звучит, и очень отдаленно от практики. Скорее это все ориентиры к которым нужно стремится.

Оценка 6/10.

Напосмотреть: Всякое душеспасительное

Что-то давно не было концентрированных видео-выпусков.

Нужно исправить.

1. О том что это за зверь такой - инженер?


2.Martin Thompson о том как проектировать под производительность


3. Alex Liu рассказывает о том как Netflix запускает кучу A/B тестов на UI


4. Ад-жесть-трэшугар автоматизированного тестирования set-top box-ов


5. О том что такое холакратия в российских условиях

Напочитать: Тестовый инструментарий антигуманитария

1. Хороший дайджест для тестировщиков со всем XML-технологиями.

2. Объяснение на пальцах что такое CQRS и Event Sourcing.

3. Долгий но полезный рассказ о том как уничтожать плохие продуктовые идеи. Если вы тестировщик и не понимаете зачем вам это - слушайте старших.

4. Amazon запускает свой device cloud для тестирования Android и своей Fire OS.

5. Старый рассказ с Google Tech Talks о том как Dependency Injection/ Inversion of Control влияет на тестируемость.

6. Ребята из Яндекса рассказали о том как они балансируют Selenium Grid-ы. То что Selenium Grid хреново масштабируется известно давно, нам тоже пришлось сталкиваться с этой проблемой. Может быть когда-нибудь и мы расскажем о нашем подходе.

7. Twitter опубликовал свою Diffy - утилиту для back-to-back тестирования сервисов.

8. На Indiegogo успешно прошла краудфаундинговая компания по сбору средств на создание JUnit Lambda - следующей версии JUnit. Бюджет собрали аж дважды (216% если быть точным), есть надежда что скоро процесс пойдет, а пока можно почитать вики проекта на GitHub. Ребят проблема настолько актуальна для всех ?  Поделитесь болью в комментах.

9. ExtentReports - Очередная библиотечка для генерации репортов от автотестов. Кстати выглядит на первый взгляд весьма сексуально. Код тут.

10. Про кучу возможностей для тестирования и fault-injection testing в докладе Игоря Сухорукова, который на самом деле про аспекты.

11. О том как тестируют качество звука в WebRTC. Отличный и довольно простой пример привнесенной testability.

12. Как всегда, красочно и про самую  писечку - он иначе не умеет - Алексей Лупан про регрессионное тестирование.

13. Что не является тестируемым кодом - с примерами.

14. Как писать юнит-тесты на многопоточный код.

15. Facebook запилил WebDriverAgent - A WebDriver server for iOS that runs inside the Simulator. Ну вы поняли - скоро будут гриды на архитектуре WebDriver-а.

16. Про тестирование безопасности API раз, два, три.

Мероприятия: Joker Conference 2015

В этом году, после настоятельных  приглашений Алексея Федорова в прошлом году, решил посетить Joker.

Место

Санкт-Петербург,Park Inn Пулковская
Огромная гостиница, и если сравнивать ее с организмом человека, то конференц-зал находится в прямой кишке.
Сама по себе площадка неплохая, все что нужно - все есть.

Организация.

Тут что-то говорить бессмысленно.
Чай-кофе, печеньки, обед, вентиляция, навигация  - все хорошо.
Ребята из JUG.ru делают все хорошо и не в первый раз. (Можете считать это неприкрытой рекламой в моем бложике, труд  этих людей мне рекламировать не стыдно)
И другим у них есть чему поучится.

Доклады

Martin Thompson - Practicing at the Cutting Edge
Второе выступление Мартина Thompson, которое я слушал с великим удовольствием. Мартин один из немногих  англоговорящих спикеров которых можно слушать долго и с удовольствием особенно если он не уходит в дебри.
Олег Анастасьев - просто потому что больше не понял куда идти.
Nicolas Fränkel,Evgeny Mandrikov Improve Testing Code Quality with Mutation Testing - хороший рассказ про PIT - инструмент мутационного тестирования с раскрытием многих граблей. Правда аудитория пришла подготовленная поэтому пришлось раскрывать граблей больше, чем предполагалось :).
Алексей Рагозин - отличный рассказ о том что нужно знать при работе с сетью. Я б хотел это все знать раньше :).
Martin Thompson Adventures with concurrent programming in Java: A quest for predictable latency - вот тут слюна текла на пол.  Мартин нырнул в такую жесть, что треть аудитории перестало воспринимать происходящее.
Josh Long - Бодро, весело, но на второй день было лучше.

День  второй

Кирилл Толкачев,Александр Тарасов про дикость микросервисов - бодро, весело, с грувями и spring boot, не хватало только хипстерских бород и смузи. Но по делу и классно.
Ted Neward про что такое Amazon - отличный crash course про то, что есть Amazon. Видимо Amazon думает открываться в России или рядом и начал щупать рынок.
Nicolas Frankel про Spring Boot и DevOps - действительно больше про DevOps. Попробую кое-что у нас прикрутить.
Josh Long с мегапродажный спичем про Spring Boot - неподготовленные умы после этого выступления пойдут и наклепают это в прод. Джош очень сильно подготовился потому что количество шуток на 50 минут написания кода было запредельным. Очень крутой спике.

Ted Neward, Iconoclasm - закрывающий keynote. Очень глубоко, очень круто.

Недоумение. 

Вот вам наверное в почтовый ящик  - я имею ввиду железный, который в подъезде вашего дома или на заборе перед домом - периодически закидывают всякий бумажный спам. Иногда там есть что-то полезное, например буклетик от новой пиццерии. Все остальное - хер знает что. У меня уже давно есть вопрос к тем людям, которые идут на такие отчаянные шаги как засылание такого спама в почтовые ящики  - вы с этого реально получаете хоть что-то ? Кто-то реально к вам приходит через это ?? Ну кроме пиццерий, конечно.

И вот после Joker-а появилась вторая ипостась этого вопроса. Люди, которые в больших IT-компаниях принимают решения поставить стенд на конференции - вы реально задумываетесь что вы хотите получить с этой конференции? Вы реально меряете конверсию ? Хрен с ним, забудем про конверсию. Вы не хотите никого массово нанимать, вам нужно чтобы в профессиональной среде о вашей компании думали хорошо. Вы для этого ставите стенд, на котором с помощью пары-тройки каторжанок из HR, раздаете ручки и блокноты, магнитики, иногда конфеты? Поставьте свой биллборд и play-station с Mortal Kombat - так будет лучше всем, даже вам. Или крутую кофе-машину.

Итог

Конференция отличная.

Напочитать: Maven, Gradle - соберитесь, тряпки

1. Gradle отрелизился до версии 2.7. Добавили поддержку Play Framework,  обвеска для тестирования gradle плагинов, диковинная обвеска для запуска тестов, ну и еще кучка всякого, мутного. А на сайте Gradle можно нахаляву получить пару книжек про этот самый Gradle от O'REILLY
2. Одно из немнгогих адекватных сравнений Gradle и Maven c которым даже мне не хочется спорить.
3. Интересное про продвинутые возможности maven сборки.
4. Отличный обзор расширений Maven от Takari, которые фиксят некоторые фундаментальные проблемы. И вот в этом месте хочется сказать что если даже такие вещи можно пофиксить в maven снаружи - это значит что спроектирован он очень хорошо. Вторым доказательством на мой взгляд является его долголетний успех.
5. Отличное видео о том что Google - это 2 миллиарда строчек кода,  и какие инструменты пришлось построить чтобы не сдохнуть.

6. Очередное расширение для Maven которое может быть сделает чью-то жизнь лучше - Versions.
7. Очень специфичный плагинчик от ребят из Spotify по анализу зависимостей.
8. О том как вашу половую жизнь может разнообразить перепаковка артефактов под Android рассказано тут. От себя могу добавить что таки это еще нифига не предел.
9. Как закатывать собранный Java код на машинки в виде  deb-пакетов. Тоже про maven.
10. Ну и чтобы не было совсем как-то только про Maven/Gradle. Cedric Beust (тот который создал JCommander и TestNG ) окончательно накурился и создал Kobalt - новую систему сборки, написанную на Kotlin. Зачем? Just because I Can!

Мероприятия: Самолюбования и PR пост

Буду краток.
1. В июле побывал в Питере и посетил собрание Питерского сообщества тестировщиков.
Видео (немонтированное, в 5 частях) можно посмотреть тут.
А презентацию - тут

тестирование распределенных систем from Nikita Makarov

2. Перед конференцией SQA Days будет проходить серия тренингов, подробности тут. Ценник разный, полезность  будет тоже разной. Особенно могу порекомендовать это все начинающим подаванам. Но только помните - только тот тренинг будет для вас в пользу, который вы посетите за свой счет. Хотя бы частично. Ибо ничто так не обостряет внимание и не придает остроты вашим мыслям и вопросам тренеру, как тягостное ощущение того, что тренинг и за ваш личный счет тоже.
3. Уже на следующей неделе, 16-17 октября в Питере пройдет конференция Joker. А 18 числа будет студенческий день. Это для всех тем кому не безразличен Java мир и кто еще не зарегистрировался.
4. 9 октября то есть послезавтра в далеком и знойнойм Новосибирске пройдет  DevDay под эгидой компании 2GIS. Но говорить будут про тестирование. Обещают трансляции и запись потом.

Скоро авось еще напишу.

Напочитать: 11 друзей гуманитария

1. Хорошая презентация от Etsy о том как адаптировать и адаптировать к удаленным работникам. Ну и вообще пересказ книжки Remote.
2. О том что интервью сломаны и что все тлен и безысходность.
3. Три закона критики от Максима Ильяхова.
4. Задача Васона как пример того что все люди - нелогичны.
5. Выход из комнаты и очистка памяти - все логично, да.
6. Про сон. Очень актуально и проверено на себе.
7. Весьма легкое выступление которое можно разобрать на цитаты вырванные из контекста. О том почему в офисе можно  завести собаку, таскать туда маленьких детей и вот это все. Слушал с удовольствием.
8. про ад и трэшугар внутри Amazon и их ответ Чемберлену.
9. О эффекте SEME и том как Google/Facebook могут влиять на выборы. Но нам-то не о чем волноваться, у нас-то все стабильно.
10. О практике безоценочного суждения и postmortem-ов от Etsy.
11. Занимательное про зарплаты "The more I think about salaries, the less I like them. They are usually pitched like "as long as you get your tasks done, it doesn't matter how much you work," but for some reason it seems like most salaried people end up working more hours and not less. "

Напочитать: Design Patterns Gang Bang

Чот поднакопилось про всякое design-related.

1.  Как менять уровни логирования в Runtime (java inside). Раз и два.

2. Зачем и как делать сериализацию ламбда-выражений. Мне вот почему-то в голову сразу пришла фраза "Давай заMap-Reduce-им это по-быстрому" но продолжать эту мысль я не буду - меня могут читать дети и Junior Developer-ы.

3. Создатель Null Reference о своей трагической ошибке.

4. Использовать Repository вместо DAO. Наброс про новую точку зрения на яйцо.

5. О том как делать продукт с высокой степенью кастомизации и какие бывают подходы. От себя  - в жизни наблюдал как работают  Feature Toogle и что выходит из бранчевания продуктовых линий. С плагинами/расширениями - тоже еще тот адок.

6. Интересная презенташка про малоизвестные паттерны проектирования.
7. CRDT на Java. Видео с Goto Conference и статья.
8. Как программно на лету снять jstack и  почему так бывает нужно.
9. Отличное видео про обзор возможностей Hazelcast.

Пока все.  Скоро бложек (надеюсь что и я тоже) вернется к нормальному режиму публикаций Напочитать.

Книга: Энтони Лаудер - Культуры программных проектов

Наткнулся на упоминание этой книжки недавно, со ссылкой на сайт happy-pm.com где был выложен ее перевод на русский.
Закинул на Kindle, и вот как-то перед отпуском начал ее читать, а а вчера открыл киндл и понял что висит маленькая недочитанная книжица, решил добить.

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

Сама по себе книга мне показалась неоправдано затянутой.
Книга расскажет вам о трех (с половиной) культурах разработки - инженерной, дизайнерской и сервсиной (и в качестве половинки - научной) -  и расскажет вам о каких-то метафорах связанных с этой культурой.

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

Оценок по традиции не будет, потому что книжка бесплатная, но читать бы не рекомендовал - не тратьте время.
Более подробно лучше прочитать рецензию Стаса Фомина

Анонс: QaMeetup в Нижнем Новгороде 17 сентября

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


Ну и да, нижегородцы - расскажите куда в вашем городе сходить, что посмотреть , где посидеть ?

Quality Assurance Tools: Паранойя в квадрате или как проверить собственный код на вшивость.

Преамбула

В пылу работы, особенно если могут отвлекать, люди могут забывать очевидные вещи.
Не потому что они плохие или некомпетентные, не потому что мало времени,а просто потому что вот забыли и всего делов.
Особенно больно становится когда твой код на Java, а люди забыли про определение методов equals и hashCode у объектов представляющих собой сущности в домене. toString конечно еще, но с ним чуть больше нюансов - современные IDE предоставляют хорошую интроспекцию объектов в дебаге, поэтому найти то, что toString продолбан чаще всего получается уже в логах с прода, где он не дает никакой информации.

А вот с equals и hashCode все веселее и проще - они иногда приводят к дням веселой отладки в попытках понять что же происходит.

И все это начинает пестрить красками особенно ярко в тот самый момент, когда проблема закопана в библиотеке, которую вы используете  в другой библиотеке, а эту в свою очередь уже где-нибудь еще.

И я решил что нужно попробовать сделать хоть какой-то инструмент для борьбы с этой проблемой.

Почему не статический анализ кода? 

Инструмент для обнаружения проблемы можно построить и не с нуля, используя средства статического анализа кода типа findbugz, checkstyle, pmd.
Все они предоставляют возможность расширения набора правил анализа, и все они open-source.
И все они обладают избыточным набором правил анализа на все случаи жизни, который можно и приходится настраивать.
И ни один из указанных инструментов не может проверить нужные мне условия прямо из коробки.
И самое главное - редко когда и мало кто ставит этот статический анализ кода в таком месте своего жизненного цикла разработки так чтобы он прерывал сборку проекта.
Мне же хотелось иметь средство, которое по умолчанию будет останавливать сборку проекта.

Почему именно так ? 

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

Идея решения проста - в процессе написания кода нужно поставить одну аннотацию, остальное компилятор при помощи процессоров аннотаций сделает сам.
Естественно процессор аннотации нужно написать, естественно аннотацию нужно повесить на класс, и если этого не сделать, то никакой процессинг не сработает.
Но аннотацию нужно поставить одну, а методов про которые нужно не забыть  - три, так что уже выигрываем.
Аннотаций я пока реализовал две:
@Pojo - проверяет что у класса определены  equals, hashCode, toString
@Helper - проверяет что класс соотвествует идее хэлпера (все методы статические, конструктор приватный, все поля константы, никакого состояния иметь не должен).

В натуре

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

При попытке компиляции тестового проекта вы увидите вот такую вот своершенно неизящный вывод в консоли.

Для тех кто не поленится сходить и почитать код сразу предупреждение - там есть говнокод, особенно в местах  по анализу и сравнению типов возвращаемых методами.  Сделано отвратительно, самому не нравится, но пока живет.  Как исправлю - обязательно выложу.

Мысли по ходу.

Мыслей в связи с этим вот pet project у меня накопилось больше, чем сам проект.

1. Казалось бы фундаментальнейшая и низкоуровнвая вещь, такая как процессор аннотаций, должна быть вылизана, задокументирована и спроектирована очень хорошо. Но вот с документацией вообще швах.
2. Информации и примеров того как это делать правильно в интернете не очень много. Свою подборку ссылок приведу в конце.
3. Я не нашел ни одного вменяемого метода для тестирования этих процессоров аннотаций, кроме как создать отдельный проект в котором эти самые аннотации будут развешаны на классах дающих нужные кейсы.(смотри апдейт ниже) В мыслях крутиться использования инфраструктуры для тестирования плагинов к maven, но этот ад мы прибережем для следующей серии нашей мыльной оперы.
4. Если отбросить лично мои заморочки и скомбинировать подход с построением AST, то анализатор может получится весьма и весьма мощный.
5. Сразу нужно думать про нормальный репортинг, посколько API процессора аннотаций ничего кроме как минималистичного вывода в консоль делать не дает. То есть проанализировать код, найти плохое место в нем вы конечно можете но вот отрапортовать об этом будет сложно. Нужно писать что-то сбоку.
6. Чтобы вся эта радость нормально работала библиотеку с аннотациями и процессорами нужно подключать к мавену в scope = provided. Так и только так!!! Иначе зависимость на аннотации и анализатор полезет дальше транзитивно, а мы помним что это всего лишь инструмент, не более того.

Ссылки

1. Пост на хабре вдохновивший меня сделать это.
2. Туториал по похожему кейсу.
3. Фундаментальная статей про процессинг аннотаций в Java. Все разжевано и разложено по полочкам.
4. Еще один хороший туториал в трех частяхпостах (раз, два, три)

UPD 22.11.2016 В процессе археологических раскопок кургана Гитхаб наша экспедиция нашла древний артефакт для тестирования кода процессоров. Подключили, попробовали - работает!

Напочитать: Околосервисный выпуск

1. Gradle отрелизил версию 2.5. Две основные плюшки в релизе - непрерывная сборка при изменении исходников и правила замены исходников чтобы не компилить все и каждый раз.Ну и отличная презенташка на тему того что Gradle умеет.
2. Хорошая статья про монады. Оказывается я давно ими пользуюсь.
3. Amazon выпускает свою имплементацию TLS  - s2n.
4. Отличный маленький и жутко полезный инструмент от Алексея Рагозина - jvm-tools.
5. Интересная оберточка для транслирования исключений - ET (github).
6. Может быть в Java 9 выпилят Unsafe. Непонятно зачем, но понятно что из этого будет.Тут вот контрнаброс про это.
7. Отличное выступление Чеда Фаулера про то как они Wunderlist на микросервисы распиливали.


8. Случилось что-то страшное или Скайп начал поворачиваться лицом к людям. Вот даже релизят АПИ.
9. Maven Best Practices.
10. Отличное  live-demo того что можно сделать с помощью Spring Boot (это если кто не знает платформочка для создания микросервисов)

11. Транзакции в распределенной (как правильно - распределенная или распердЮленная? :)) системе - ну может быть. Паттерн Saga под капотом (еще тут от MS про него же). 

Напочитать: Странный выпуск про тестирование

Лето. Затишье. Да и мне уже в отпуск хочется.

1. Долго и нудно о том что такое исследовательское тестирование. От авторов самой концепции исследовательского тестирования. 
2. О полуавтоматизации для тестирования локализаций в Netflix - тут. 
3. Netflix Test Studio уже как-то попадала ко мне в напочитать, но вот тут про нее более развернуты рассказ. Точнее про то почему в нее пришлось воткнуть Kafka.
4. Еще один рассказ как преуспеть с интеграционными тестами - на этот раз из мира .NET - но да суть неизменна.
5. Недотестировали. забили, забыли на 500 миллионов долларов - баги в космосе дорогие.
6. Большая книжка про то как начать автоматизировать на Python - тут.
7. Онлайн-конференция TestLabs пройдет 25 июля. Инфа тут.
8. Мне вот порой кажется что тестировщики без пирамид не могут. Нуващеникак!!! Вот еще раз про пирамиды и качество. 
9. Коротенько и емко про то что стоит за тестированием на основе моделей - состояния и их диаграммы.
10. Рассказ про кошерный BDD от John Ferguson Smart - того самого который сделал Thucydides (ныне Serenity)
11. Рассказ от Etsy о том как они на LXC+Chef строили свою тестовую инфраструктуру - раз и два.
12. Infer. Статический анализатор кода от Facebook. Ссылочки (раз, два, три).
    Из последнего  white-paper-а вы можете узнать что:
    - большие продуктовые компании инвестируют в инструменты статического анализа.
    - Infer был изначально сделан не в Facebook, Facebook попробовал его и решил купить компанию, стоящую за Infer (Monoidics).
    - этот инструмент анализирует код композитно - то есть не весь каждый раз, а только изменения и натягивает эти изменения на предыдущие результаты и за этим стоит математика.
    - есть отдельная система которая по хэшам определяет места в коде чтобы понимать какой changeset что дает на продашене.
    
    К чему это все здесь?  К тому, что не нужно стесняться делать свои инструменты для обеспечения качества своего кода. Статические анализаторы кода могут поймать только общие вещи, расширять их можно (и даже нужно), но иногда приходится писать и свои. Если у вас получится, то вас купит Facebook :). 

Книга: Сэм Кейнер. Руководство фасилитатора. Как привести группу к принятию совместного решения

Дочитал.

Это не просто книга, а почти что фундаментальная книга.

Пару лет назад мне довелось присутствовать на двух мероприятиях, которые для нас проводили тренеры (фасилитаторы) из одной Очень Известной Компании.
Оба мероприятия были двухдневными, оба фасилитатора были профессионалами своего дела.
Но оба не довели группу до момента инсайта.
Точнее даже так - им обоим было не суждено это сделать, но они старались.

Читая книгу Кейнера, я то и дело наталкивался на описание приемов фасилитации, техник и подходов, которые использовали те двое фасилитаторов.
Я по памяти насчитал полтора десятка приемов и методик из книги, которые они использовали.
Теперь картинка разложилась по полочкам, я смог увидеть суть того, что они делали, и касательно как минимум одного из мероприятий могу сказать, что цель все же была достигнута.  Та цель которую ставил заказчик всего этого мероприятия.

О самой книге.

Книга очень хорошо структурирована.
Это лучшая на сегодняшний день книга с иллюстрациями, которую я держал в руках (естественно, за исключением учебника физики :) На самом деле иллюстрации в современных книгах незаслуженно забыты - они могут помогать доносить детали и большие идеи лучше. Единственный нюанс - это сложная и дорогая работа.

Книга очень хорошо погружает вас в модель дискуссии Кейнера, на которой он собственно и учит фасилитировать.
Модель - жизнепригодная, я часто вижу именно такую модель развития дискуссий в коллективе. (Хотя это конечно же не значит что она единственная.)

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

Приводить свой конспект книги я не вижу никакого смысла - книга несмотря на свой небольшой объем (300 страниц) набита практическими знаниями и примерами.

Это настольная книжка на долгое время потому что фасилитация практический навык, который нужно просто тренировать.

Оценка 9/10.


Отдельное спасибо хочу сказать Диме Лазареву, который согласился привезти мне экземпляр этой книги на CodeFest в Новосибирск в этом году.

Напочитать : Накипевший выпуск.

1. Если слова  Java +  JNI + С++ вам знакомы и вызывают боль то вам может быть полезно тут.
2. Отличный перевод манифеста Twelve-Factor-App  на Хабре.
3. Stefan Tilkov на Craft Conference 2014 рассказывал об архитектуре, архитекторах и пичальках. Смотреть тут.
4. О том что Hola ссучилась и какие угрозы могут нести расширения в браузерах  - как для пользователей, так и для продуктов , с примерами и картинками.
5. Очень пространное эссе о трудностях общения компилятора Java и JVM.
6. Step-by-step guide про то как начать с node.js, если вам конечно не противно.
7. Новый статический анализатор кода от Facebook. Правда вроде как без правил по которым анализировать, зато опенсорс, OCaml под капотом и все понты, дада.
8. Простые правила написания безопасного кода. Ну совсем простые.
9. Как дебажить maven сборку - написано тут, несмотрите на слова Eclipse.
10. Рассказ от Spotify о том как они мигрировали базу данных  пользователей без downtime c PostgreSQL на Cassandra.
11. Как пользоваться FUSE через С и Java и вроде бе даже без крови. 
12. Вопросы которые нужно задать себе когда хочешь странного SOA микросервисов.
13. Release plan на Java 9 готов, осталось взять и написать. Плохая новость - не будет JSON API, Money & Currency API. Хорошие новости - тут уж на суд каждого. 
14. О том как хорошо потрахаться с try-with-resources через мутационное тестирование с pitest.
15. О том как устроен UI десктопного плеера Spotify, причем здесь богомерзкий javascript и Chromium Embedded Framework. И такого будет дальше только больше. (Лавеча слышал цифру что Facebook переиспользует более 50% кода какого-то компонента в iOS и Android приложениях через этот ващ  Javascript).

Следующий про тестирование.

Mad Minsk - SQA Days 2015

Первый раз я был на SQA Days в Киеве в 2012 году.
Но так то Киев, 2012 год, апрель, и вообще первый раз на SQA Days, первый же раз на конференции вне Москвы.

До сих пор не забуду тот совершенно нетомный вечер, который мы отгуляли с Лешей Лупаном, Шницель-Хаус на Саксаганьского, прогулку по центру Киева, шарж на наши довольные бородатые морды лиц и неумолимо теплый (+20 градусов после захода Солнца), ромовый антураж Киева, который стучит в висках до сих пор. Аххх!

Место : Президент-Отель, Минск, Республика Беларусь.
Площадка средненькая (Президент-Отель).
Основное нарекание вызывает только площадка для трека C - 11 этаж, отвратительная вентиляция, при условии попадания в трек 100+ человек вызывает желание слушать доклад прямо из лифта.
В треках А и B такого не было.

Организация
Для конференции в 900 человек (планово, не знаю сколько было по факту) организация на троечку. От коллег слышал нарекания по обеду - во вторую или третью смену обеда не всем доставалось еды, при том в оба дня. Кофе + печеньки + место для общения было всегда, на официальное афтепати мы не поехали, предпочтя ему "Раковского Бровара".
В первый же день стало ясно что распределение докладов по аудиториям (500 большой зал, 200 малый зал, 200 еще один малый зал на 11 этаже) никак не соотносится с интересностью докладов. То есть несколько интересных докладов были в зале С с плохой вентиляцией и народу туда приваливало больше плановой емкости, в то время как основной зал на 500 человек был почти пустым. Я, конечно, могу ошибаться, но банальная голосовалка за 2-3 недели до конференции решила бы проблему распределения людей по залам.
Ну и сбор фидбека - бумажный листочек в сумочке, который надо заполнить и отдать. Который даже я естественно не заполнил и не отдал.



Доклады - день 1.
Rex Black, Test Estimation - слайдоменты, ад, трэшугар про вотерфолы.
Игорь Хрол про автоматизацию тестирования - весело, задорно, половина про Grail, уже видел.
Андрей Мясников про Gherkin и Ruby - сам доклад наверное хорошо, но Ruby и Gherkin заставили меня ретироваться.
Павел Асанов про автоматизацию тестирования API в 2GIS - очень хорошо.
Андрей Стахевич про appium в облаках - сравнительный обзор облаков работающих с аппиумом, на этом все.
Катерина Овеченко - отличнейший доклад про фаззинг.
Евгений Кривошеев про Points Of View - выступал Женя очень живо, но я не уверен что аудитория восприняла хотя бы даже часть.
Роман Иовлев про Micro Model Based Testing - мне не очень, из нового - названия каких-то инструментов для SBT.

Доклады  - день 2.
Алексей Лянгузов, беседа про тестовые данные. Действительно беседа.
Дмитрий Гуменюк Report Portal - интересная презентация продукта, очень похож на наш Watson, но более ориентирован на то, чтобы туда еще и внешний заказчик смотрел.
Илья Фомин про Chef, Puppet,  и прочее и как с этим жить - доклад хороший.
Никита Макаров, Микросервисы для автоматизации тестирования - пришлось сходить :).

Мой доклад.
Был сильно упрощенным, без технических деталей, как например, на прошлогоднем CodeFest. Причин на то две - хотелось поделится именно идеей и рассказывать техническое мясо в течении 35 минут слота трудновато.
Много вопросов про ботов, про ограничения, несколько подрывов шаблонов на тему " - Вы что бл@#$ продакшен тестируете ??? - Да, тестируем :)".

Впечатления
Отрасль тестирования у нас никуда (в этом году уж точно) не движется. Вообще. Практиков, которые исследуют что-то новое, пытаются встроить это в себя и поделится потом с окружающими опытом - мало, катастрофически. И соотношение сторон даже не 10 на 90, а 2 на 98. Грусть, печаль, беда.

Про Минск и Беларусь
Первый раз  был в Беларуси.
Как только проехал скульптуру зубра на выезде из аэропорта сразу пропадает ощущение того что ты в Беларуси - дороги как в Германии, ни швов ни ям в асфальте, обочина чистая, одуванчики растут по линеечке, лес ухоженный. И так до первого дорожного указателя :).
В целом все очень культурно - продавать пиво можно до 23, а вот пьяных и бутылок на улицах нет. Сфера обслуживания конечно не ахти -  официанты/официантки не сильно мотивированы.

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

Но не все так хорошо (по крайней мере для меня) - нет в Минске чего-то основополагающего, смысла что ли. Все хорошо, но смысла как-то нет. Потому наверное и возвращаться не особо хочется.

Напочитать: Test... Test me harder!!!

 Уже на этой неделе в Минске состоится SQADays. Ну а пока не наступила - выпуск с сильными уклоном в тестирование.

1. Автоматизированное тестирование JavaFX приложений - с примерами и картинками.
2. Очень многие сейчас увлекаются всякими Chef-ами, Puppet-ами и прочими Ansible-ами. А ведь это все надо тоже тестировать  - инфраструктура как код - это небесплатно.
3. Замечательный набор подсказок для тестировщиков что можно делать с консолью Google Chrome.
4. О непростых взаимоотношениях разных версий Opera и как с ними жить из-под webdriver - Алексей Баранцев.
5. О том как построить схему связей модулей в проекте на PowerShell и Graphviz - тут. Причем здесь тестирование и обеспечение качества - а вот сами должны догадаться!
6. Замечательный, хоть и длинный пост про TDD и что "невсетакпросто" и флейм в комментах.
7. Ребята из LMAX Exchange (это контора, которая дала миру Disruptor, если чо) плюют в морду ребятам из Gooogle, которые говорят что end-to-end тесты - это дорогостоящая фигня.
Плюют обоснованно. От себя могу добавить - обращение с большим массивом end-to-end тестов требует принципиально других инструментов и подходов. Существующие инструменты (Continuous Integration решения, большей частью) не обладают теми свойствами которые нужны для постоянно работы с большим количеством end-to-end тестов (отчеты, логи, анализ запусков на разных окружениях, продолжать можно долго). И либо вы дальше строете/пристраиваете/достраиваете что-то свое (как мы - микросервисы), либо начинаете кричать о том, что end-to-end тесты = ( долго + дорого + хрупко + неэффективно * и вообще говно).  Меняйте mindset.


На SQA Days в Минске я как раз буду рассказывать о том как мы строим и используем микросервисы для наших (в том числе end-to-end) автоматических тестов.

Напослушать: CodeFest, RadioQA и продолжение банкета

Началось все еще на CodeFest, когда Таня Писчасова предложила поговорить про Мир без тестировщиков. Что из этого получилось - на видео ниже, там и моя говорящая (с трудом %)) тушка тоже присутствует. Однако, результаты квартирника не устроили ни меня (форматом большей частью), ни Татьяну, поэтому Таня предложила повторить - Леша Виноградов как раз организовал подкаст про тестирование, в первый выпуск которого мы и вписались. Ну и в качестве десерта - Роман Сергеевич Ивлиев, там же, на кодефесте вещал про то как они боролись со скачками активности - здесь все - Черные лебеди, теория ограничений, Битрикс.

Напочитать: Пятнашки

1. Сразу две статьи про легковесные реализации многопоточности в Java - раз и два.
2. С релизом 1.6 Docker ступает на тропу Windows. Ну и еще куча всякого в релизе. 
3. Еще не до всех дошло что можно ускорять Android эмулятор за счет тупого изменения архитектуры процессора в настройках. Будем повторять, чо.
4. Мутация JSON от Google  - jsonnet. Интересно, выживет ли.
5. Интересная возможность отлаживать вэбчик в разных мобильных браузерах.
6. Набор прикольных утилитарных библиотечек от Zero Turnaround - zt-zip, zt-exec, zt-process-killer. Молодцы,чо.
7. Пара интересных статей про Traceability на Large-Scale - про то как Facebook делает это через  логи и про то как Google делает это через интроспекцию.
8. Еще раз про Ansible. Имхо на масштабах до 100 машин - хорошая штука.
9. Вышел Guice 4.0 с улучшенным саппортом Java 8.
10. Интересный инструмент для анализа бинарной совместимости релизов - jQAssistant.
11. Windows будет теперь релизится по-другому - это если суть. Детали тут.
12. Отличный обзор Continuous Delivery от Google/Amazon/Facebook если кто-то еще не читал/смотрел. Исполняет Noah Sussman.
13. "Вы не любите JavaScript? Вы просто не умеете его готовить! " и тому подобное.
14. Вышел новый technology radar от Thoughtworks.
15. Интересная фигня от Airbnb - Airpal.

Книга: Норм Керт "Ретроспектива проекта"

Вторая книга от издательства Дмитрия Лазарева, в издании которой я участвую.
Очень трудно писать на тему ретроспективы проектов, особенно после того как начал писать цикл постов про то как делать ретроспективу в команде. Но попробую.

Итак, структура книги мне в целом понравилась.
Единственное что кажется нужно править - это главу про упражнения ретроспективы - очень уж  она объемная, и в голову не влезает никак.
В остальном - структура книги отлично расскажет вам "карту территории" - как подготовится, как продать, как начать, мелкие, но полезные тонкости проведения ретроспективы.


Про содержание (субъективно).

Эта книга не про Agile, от слова совсем. Трудно себе представить здоровый гибкий процесс, в котором люди испытывали бы такой градус недоверия или необщение друг с другом и ничего  с этим бы не делали. Эта книга не про маленькие (до 5-7 человек) команды, хотя сам автор пишет что больше 30-35 человек он не фасилитирует в рамках ретроспективы, обычно до 15.

Эта книга, наверное, о самом важном чем может обладать "стая товарищей" называемая "командой разработки" - доверие и способность учиться на своих ошибках через их признание и анализ.
Скажу честно, что мне ни разу не приходилось работать  в таком коллективе, где были бы напрочь отбиты оба этих аспекта. (Хотя вру - приходилось,  но мы там ретроспектив не делали.) Работа над установлением доверия - действительно догий и тяжелый труд.  А для того чтобы "сломать психику" человека в сторону признания своих ошибок и адекватного анализа их - вообще требуется очень много времени. Но опыт автора книги по части проведения ретроспектив в различных коллективах сильно больше моего, поэтому нет оснований не верить ему.
Книга делает очень много акцентов на прошлом проекта для понимания и выявления причин тех или иных действий/явления на проекте, чтобы показать одним участникам ретроспективы, что с другой стороны баррикад сидят "тоже люди".
Пожалуй эта книга является самой крутой методичкой по части icebreaker-ов.
И пожалуй эта книга лучше всего продает роль фасилитатора ретроспективы - при том продает объективно.

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


Эту книжку обязательно стоит иметь под рукой.
Особенно если вы только начинаете.


Оценка 7/10

Ретроспективы в командах: Артефакты ретроспектив

Это предпоследний пост в данном цикле.

Итак, вы провели ретроспективу, но радоваться рано.
Реально процесс встанет на (какие-то) рельсы когда вы будете делать в интервале между ретроспективами делать все те улучшения/изменения, которые захотели сделать.

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

Вернемся к артефактам.
Артефактов у вас будет (условно) три типа:

1. Список задач и/или карта их выполнения - это из предыдущего поста.
2. Конфликты и социальные игры в процессе ретроспективы - про них я первоначально писал тут.
   
   Социальные игры и конфликты являются для вас довольно ценным материалом. Вообще, наблюдение за людьми в процессе того, как они делают ретроспективу для фасилитатора этой самой ретроспективы является ценнейшим материалом, особнно если фасилитатор проводит ретроспективу с командой не в последний раз.
   
   Ретроспектива сама по себе является дополнительной нагрузкой. Люди, на уровне подсознания, довольно быстро запоминают что это труд, поэтому "внутренний лентяй" каждого человека старается максимально быстро и жестко уйти от вопросов и тем на ретроспективе которые могут нагрузить его, лентяя, какими-то улучшениями. Мне даже кажется что это один из отличных примером того как работает быстрое и медленное мышление описанное Каннеманом в Thinking Fast and Slow и Талебом в Черном Лебеде.
   
   Социальные игры и прессинг могут рассказать вам о том, как на самом деле обстоит рабочий процесс в команде (не сваливают ли разработчики недоделанные таски на тестирование ? все ли хорошо с требованиями и декомпозицией задач?).
   Процессные и организационные "дырки" и костыли, которые всплывают на ретроспективе безусловно нужно обсуждать и решать сразу - это и есть улучшения.
   Но вот игры и взаимоотношения порешать на ретроспективе не получится - это то, что должно выстраиваться в процессе ежедневной работы. И это вполне возможно может стать вашей работой за рамками ретроспективы.
   
   Еще один нюанс  - социальные игры происходят не только на ретроспективе, но и за ее пределами, поэтому не стоит удивляться что команда пришла к вам на ретроспективу "перейдя на следующий уровень игры". 
3. Нежданчики - задачи и мероприятия, проведение которых не планировалось на ретроспективе, однако в процессе проведения улучшений/изменений оказалось необходимым - это, пожалуй, самая интересная категория, особенно для тех кто только начинает.
   
   Неожиданно может всплыть все что угодно. Правда чаще всплывает то, что все старались забыть. но не исправить :).
   Краткая типология нежданчиков:
   
   Нежданчики-задачи.Плаинровали сделать А, но выяснилось что это блокируется B и С, которые  в свою очередь упираются в задачу D соседнего подразделения.  Или А увеличилась в размерах на порядок. Вывод: плохой анализ на ретроспективе, плохое понимание взаимосвязей в проекте.
   
   Нежданчики-люди. Таск поручили делать Васе, но Вася не понял что нужно делать, впряг в это Колю. Коля мог сделать или не сделать свои задачи по результатам ретроспективы, попутно выполнить Васины. В общем с точки зрения внешнего наблюдателя задачи могут быть выполненными или не выполненными, но явно не теми людьми, которыми планировалось. Такое вот неожиданное поведение от людей может сыграть как в лучшую так и в худшую сторону. Все, что оно дает вам как фасилитатору - лучшее знание о команде и способностях людей. Бывает так что самый молчаливый и забитый интроверт в команде является самым суровым "real fuckin do'er-ом" - это нужно знать и использовать во благо.
   
   Нежданчики-информация. Решили что-то улучшить, но нашли такое, что не знаем что делать дальше. Тут ве очень зависит от контекста. Встречал такую ситуацию пару раз в жизни когда приваливал проект который до этого делали другие люди и оставляли за собой "мины". Вообще, любой "угловое знание" о том, что вы делаете обычно идет в плюс нежели в минус. Другой вопрос - почему вы этим знанием не обладали ранее ?
4. Любые рисунки, схемы, описания процессов - все что создается на ретроспективе руками участников - должно быть тщательно (но не навязчиво!!!) задокументировано и сохранено. Я обычно использую для этого телефон и забираю с собой листы флипчарта. Результаты любой из ретроспектив могут пригодитя вам при проведении следующей. поэтому лушче хранить их в электронном виде и структурировано.  

Данный список и классификация никоим образом не претендуют на истину в какой бы то ни было инстанции - дополняйте, расширяйте , переделывайте под себя.

Буду рад ответить на вопросы.

Напочитать: Тестируй меня полностью

1. Google выпустила ARC - App Runner for Chrome, который позволяет запускать Android приложения на Windows, Linux, Mac. Угадайте при чем тут тестирование.
2. Еще один мануал по PowerShell. Тестировщикам и иже с ними будет полезно.
3. Давеча я тут расписался в сторону ROI в тестировании да так что графики посещения бложека пошли вверх. Вот тут есть более менее внятное объяснение почему ROI к тестированию не приклеить - на сей раз не мое.
4. Подписываться на должность менеджера за зарплату QA  - грешновато! Почему - разжевано тут.
5. Жирное - опрос про автоматизацию тестирования. Читать тут. ИМХО: этот опрос характеризует отрасль чуть более чем полностью. И в хорошем. и в плохом смысле. В хорошем  - потому что 620 ответивших человек  - это реально показывает масштаб распространения автоматизированного тестирования. А вот первые же циферки по части того кто же на самом деле этим занимается - уже удручают - более половины опрошенных людей являются QA-инженерами или инженерами по автоматизации тестирования. Это значит что бизнес предпочитает выделять это в отдельную компетенцию, а никак не перепрошивать мозги разработчикам (что нужно уметь тестировать, хотя бы минимально) и тестировщиками (что нужно уметь автоматизировать и понимать архитектуру приложения которое ты тестируешь).
6. Некий молодой человек при поддержки дедушки Фаулера нарисовал infodeck про тестирование и тестируемость микросервисов. Из этого самого infodeck-а вы узнаете про то куда совать mock-и и стабы, in-memory базы данных, что такое синтетические транзакции и прочее.
7. Интервью с Джеймсом Бахом. Зато про тестирование, чо.
8. Автоматизация бывает не только тестирования но и других вещей, с тестированием непосредственно связанных. В случае с андроидом все не так плохо, а вот в случае с iOS может быть сильно хуже. Но вот люди сделали да - Pythonista. Питон внутри, естественно.
9. Один из главных помоников многих тестировщиков  - VirtualBox обновился до 5.0.1 beta.

И на этом все. А все потому что в области тестирования интересный контент генерируют мало и редко.

Книга: Питер Фердинанд Друкер. Менеджмент. Вызовы XXI века

Дочитал. После предыдущей книги эта мне сначала показалась странной, но все встало на свои места позже, когда я выяснил что Друкер написал ее в 1999 году.

Данная книга не является монолитной, хотя и хорошо структурирована. Эта книга - сборник из 6 довольно больших эссе, темактика которых довольно широка:

1. Новая парадигма менеджмента
2. Новые реалии и стратегия и организации
3. Лидер перемен
4. Задачи в сфере информации
5. Производительность работников умственного труда
6. Роль менеджмента в карьере и жизни

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

Друкер наверное одним из первых понял и смог раскрыть силу сущности "организации" в ХХ веке, но согласится с ним на XXI век уже сложно - Интернет и глобализация бизнеса так сильно поменяли ландшафт за последние 15 лет, что сила отдельно взятого специалиста в скором времени может сравняться с силой организации. Также следует вспомнить и о законе Конвея, который угнездился в организациях и не никуда оттуда не хочет выходить.

Книга хорошая, потому что заставляет думать свои мысли пока ее читаешь, и смотреть на то что происходит вокруг тебя глазами Друкера.
Практическая (немедленная) полезность - низкая.
Конспект тут.

Оценка 8/10.

Напочитать: В копилку гуманитариям

1. Асхат Уразбаев рассказывает об особенностях национальной культуры разработки.


2. Эпический тред на Quora с довольно тупым набросом "Как заставить программеров работать 60-80 часов в неделю", но эпичными  ответами почему так сделать низзя.
3. Увлекательно о химии геймдева.
4. Весьма интересный инструмент подвернулся под руку - смесь покойного Google Wave и принципов GTD Аллена.
5. Недавнее социологическое исследование в США показало, что современное общество в целом готово к подобным манипуляциям. Взрослым задавали вопрос — согласны ли они на то, что с генами их ребёнка будет выполнена генетическая модификация с тем, чтобы он стал «умнее» и был бы менее подвержен серьёзным заболеваниям. Значительное число респондентов высказались положительно - ну вот, генетические модификации людей уже не за горами. Самое главное - общество готово.
6. Когда-то давно я старался прочитать Эрика Берна. До конца не осилил. Зато теперь есть видео "для самых маленких".
7. Сумбурно. Но про "Эффект Наблюдателя" наверное. Раз, два и три.
8. О том почему резюме женщин хуже. Никакого сексизма, голая статистика (чорд!).
9. Странная статья про ретроспективы, но куча полезных ссылок в ней.
10. Непростая тема "Как ты себя чувствуешь когда тебя уволили?" в исполнении Zach Holman из GitHub.
11. Еще один ambient-noise генератор - никогда не думал что лучше всего код пишется под звук дожда и раскаты грома.

И самое сильное пожалуй.

Примерно на рубеже 50-60-х годов ХХ века произошло нечто фатально важное для человечества, но до сих пор мало кем понятое — цели, поставленные перед собой аграрно-индустриальными социумами, были достигнуты. Человечество пришло к тому, к чему стремилось всю многотысячелетнюю историю и теперь не знает, что делать дальше.

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

Напочитать : Выпуск внезапной весны

1. Весьма странная смесь, но тем не менее - кому-то может оказаться полезной. Jodd.

2. Удивляетесь что вышла новая версия либы в maven central а вы не в курсе?  Я тоже. Но мечты стали реальностью - artifact listener.
3. Сравнительная таблица Dropwizard vs. Spring или что вам большу подходит для микросервисов. Dropwizard конечно же :).
4. Отличный и короткий гид по заголовкам кэширования  в HTTP. Люблю такие,
5. RoboVM - это чтобы на Java под iOS. Правда платно, и наверное даже стремно.
6. Про стратегии герметизации, mock-анья и за-stub-ливания для тестирования Android приложений от гугла.
7. Maven теперь может не только XML. Хипстеры, хуле.
8. Старинное от Влада Балина

Создать свою структуру и пришлепать ее сбоку может любой дурак. Квалифицированный инженер-программист (с упором на первом слове, не путать с "программером") умеет проводить анализ "чужой" подсистемы, восстановит мысль и идею автора, сможет мысль автора развить, продолжить ее, и эффективно решить свою задачу в рамках чужого подхода к проблеме. Все это - работая с кодом. Это отличительная компетенция архитектора, высший уровень инженерного мастерства. И это имеет весьма отдаленное отношение к "рефакторингу". 
Толу на самом деле было все равно, есть документация или нет. В совершенстве владея reverse engineering, он в уме потрясающе легко умел переходить от кода к архитектуре, и наоборот. В результате, проектируя, он всегда детально представлял, в какой код превратятся его мысли, и поэтому был способен быстро прокручивать в голове огромное количество вариантов, отбрасывая "плохие". В его понимании, архитектор, не умеющий читать чужой код с "листа", и не пишущий своего - подобен инвалиду, пытающемуся бегать на костылях. Он довольно быстро закончит очень плохим архитектором - вопрос нескольких лет.
Второй важный аспект этой философии - понимание того, что код пишется в первую очередь для человека, и только во вторую - для компьютера. Это приводит нас к идеям, близким по духу к literate programming, за которое ратует Кнут. Как может человек, который не в состоянии внятно выразить свою мысль на неформальном, знакомом ему с детства естественном языке, выразить эту же мысль понятным образом на существенно более формальном языке программирования? Но это уже другая история.

9. Куча статеек про то как правильно пользоваться JUnit, но я обратил внимание только на пару и те про Rule-ы - первая и вторая. И еще вот тут хоршее-архитектурное про JUnit.
10. Одна из десятков тысяч статей про няшки в Guava - UnsignedInts, CHarMatcher, MurmurHash, InternetDomainName,ClassPath utils.
11. Google заопенсорсил свой внутренний билдтул bazel.io. Найдите 10 отличий от buck в исполнении Facebook, который пилит бывший инженер Google :D Пожалуй разрожусь-ка я статейкой про Not Invented Here синдром.

Что такое CodeFest?

Что такое CodeFest?
Можно, конечно, написать что это крупнейшая IT-шная конференция за Уралом, бла-бла-бла.

Но нет, это не то.
CodeFest можно только описать.

CodeFest это когда ты летишь в самолете набитым IT-шниками в 9 утра из Москвы нихрена не выспашись. И только потом понимаешь что, то, что этот самолет долетел с кармой всех этих (тестировщиков) людей - это уже отлично!

CodeFest это когда ты летишь в Новосибирск и у тебя в чемодане есть виски, ты летишь из Новосибирска и у тебя в чемодане опять есть виски, но уже другой и тебе противно о нем думать.

CodeFest это когда ты летишь на конференцию, и возвращаешься с книжками и футболкой.

CodeFest это встречи со старыми знакомыми.

И с новыми

CodeFest это 4 хороших доклада из 6 в одном треке, тем более в одном треке по тестированию.

В общем CodeFest в очередной раз удался.
Хочется сказать спасибо:
Роме Ивлиеву  - за стойкость.
Тане Писчасовой - за квартирник.
Паше Сташевскому и Лене Романчук - за то что делаете офигенный трек по тестированию уже несколько лет к ряду.
Андрею Солнцеву, Леше Виноградову, Коле Чабановскому, Косте Каплинскому, Игорю Хролу, Сергею Высоцкому  - за интересные беседы в кулуарах, до/после/вместо докладов.
Всей команде организации CodeFest - без вас всего этого бы не было.

Колллективу 2GIS - за отличную атмосферу в офисе и посиделки.

Будем надеятся до встречи в следующем году.

Книга: Питер Фердинанд Друкер. Эффективный руководитель.

Эта книга стояла в списке на прочтение года три или четыре.

Зря не прочитал раньше.

Эта книга расскажет вам о фундаментальных вещах.
При том довольно простым языком - языком консультанта.
Данная книга на мой взгляд является одной из основополагающих  по части личной эффективности.
Питер Друкер первым (из тех кого я читал) обратил внимание на несколько очень важных вопросов:
1. Мы живем в эпоху организаций. Огранизации стали решать все, если не многое. (Очень интересный экскурс в размер администрации президента США до начала 20 века).
2. Научно-технический прогресс сделал работника физического труда неконкурентноспособным.
3. Конкурентноспособными стали работники труда умственного.
4. Работник умственного труда, который принимает решения и несет ответственность за результат своих решений является руководителем.
5. Эффективность организации определяется ее руководителями (по Друкеру) и этой эффективности можно научится.


В написанном выше для нашего нынешнего уровня знаний о природе организаций (хех, а прям вот так вот много мы занем, да ? :)) наверное ничего нового-то и нет.
Но, на минуточку, - первое издание книги "Эффективный руководитель" Питера Друкера было в 1967 году.

В 1967(!!!!) году этот мужик уже видел и понимал сильно больше чем его современники.
Читать. (тут мой конспект)
На один уровень с Фредериком Бруксом.
10/10.

Ретроспективы в командах: Отбор проблем и анализ

Проолжаем начатое тут и продолженное тут.

Отбор проблем.

Подошли к самому сложному моменту.
Итак перед вами доска/флипчат набитый проблемами (мнениями? домыслами?), маркер в руках, и коллектив людей которым (я надеюсь на это) не пофигу что будет дальше.

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

Традиционно, большую часть работы занимает колонка плохо.
Первое что с ней нужно сделать  - это сфотографировать на телефон, или сделать ее бекап любым другим удобным (какой интересно удобнее ?) способом.
Почему ? Потому что дальше вы будете ее корежить, и бэкап нужно иметь всегда =).

Второе - не кидайтесь сразу что-то с ней делать, остановитесь, посмотрите на нее, прочитайте все пункты/стикеры еще раз, убедитесь, что все что там написано вам и всем остальным понятно.

Второе с плюсом (только для фасилитатора) - попробуйте проанализировать есть ли или могут ли быть связи между проблемами.
Если есть хоть малейшее подозрение что да - надо привлекать весь коллектив к анализу.
Даже если описанные проблемы кажутся независимыми - то лучше все равно задать вопрос всем.
Тут можно просто прямо послать вас читать замечательную статью Хенрика Книберга про Root-Cause Analysis, и я конечно это сделаю, но надо дополнить.
В любой команде есть определенная емкость терпения/сил/времени/бюджетов для решения любых проблем. И эти бюджеты очень плохо переносят дефициты.
С одной стороный эта емкость ограничивается заказчиком/владельцем продукта который вряд ли одобрит улучшайзинг на политерации, а с другой отсутствие поставки ценности для заказчика - это очень сильный демотиватор для команды.
Поэтому выявление корневой причины и анализ причинно-следственных связей - важен, потому что точное и точечное улучшение лучше чем генеральная уборка во всех углах.

Окей, для простоты картины представим, что взаимосвязей между проблемами у вас нет и они изолированы.

Третье - выбираем проблемы. Тут опять же есть место для социальных игр, про которые я писал ранее.
Я предпочитаю голосование точечками - каждый участник ретроспективы ставит точку (или магнитную точку, такие тоже есть в канцелярских магазинах) напротив той проблемы, которую считаает самой важной для решения.
У каждого члена команды есть право поставить три точки. Почему три ? Опять же правило по-умолчанию.
Если ваша команда настолько крута в области улучшений своего собственного процесса - то можете взять хоть 7.
Только аккуратно - предпочтительно внедрять улучшения по-одному, чтобы понимать какое улучшение какой эффект дает. Если у вас три улучшения в разных областях или даже два из них пересекаются, то отделить эффект одного от другого довольно просто. Если у вас их 7 - то уже сложно.

Второй аспект который касается количества отбираемых проблем для решения состоит в том что это только те проблемы которые вы ХОТИТЕ решить, но не факт что решите. и что еще
хуже не факт, что решите ДО КОНЦА. Это ваши эксперименты с вашим собственным процессом работы, которые вы сами над собой, коллегами и процессом будете ставить. И не факт, что эксперименты будут успешными. Вполне возможно что их придется откатывать, при том делать это не после следующей ретроспективы, а "на горячую", в процессе основной деятельности.

Процесс голосования довольно важный момент - на нем можно увидеть есть ли у команды единодушное мнение о главных проблемах, или это мнение размыто.
Опять же, это отличный момент для фасилитатора "попробовать продавить" решение "главной" проблемы команде  - только помните что делать это нужно не на первой ретроспективе и ОЧЕНЬ аккуратно.

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

Итак, голосование завершено, топ-3 проблем собран, переходим к следующему этапу, предварительно сделав фото доски.

Анализ проблем.

Берем проблему с наибольшим количеством голосов и пишем в верхней части доски/флипчарта.
Дальше начинаем анализ проблемы любым удобным вам способом.
Тут я хочу сослаться на книгу Дэвида Стрейкера - она будет являться отличным методическим пособием для вас на этой стадии - в ней есть кусочек методологии в связке с инструментом (стикерами).

Достаточно часто бывает так, что проблема "проседает" под тяжелым взором всех участников команды - это значит что все чего им не хватало для решения этой проблемы - это собраться вместе и поговорить. Радуйтесь - вы только что получили +1 в карму фасилитатора. Эту "просевшую" проблему нужно разложить на таски и впихнуть в бэклог.

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

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

Ваша задача в таком случае - за минимальное количество времени и ресурсов максимально достоверным способом отсечь ветви не достойные дальнейшего внимания.

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

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

Итого по результатам анализа вы должны получить:
1) список задач которые прольют свет  на непонятные вам моменты (гипотезы и предположения), либо напрямую  улучшат ваш процесс
2) схему увязки этих задач в единое целое, как путь от частных задач к большому улучшению.

Схема может прижиться у вас не сразу, может и не прижиться вообще.
Но если вы пытаетесь решить большую проблему - то лучше ее иметь ее, иначе есть шанс запутаться или просто забыть о какой-то вещи.

Сформированные задачи вам нужно будет воткнуть в бэклог, но тут уже у каждого все по-своему.

Оформленные результаты ретроспективы (карту, блок-схему, список задач, прочее) нужно разослать на всех участников ретроспективы.
Опять же полезная практика - в отправляемом письме обозначить список задач и кто за них ответственный.


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

Продолжать повествование относительно данного этапа ретроспективы считаю непродуктивным, если какие-то вопросы остались неосвещенными - добро пожаловать в комменты.