Напочитать: Хабарок

В этот раз очень уж много с Хабра скопилось.

1. Мой добрый друг  и коллега Максим Шульга поведал о том как они делают интеграционное тестирование vGate на базе Jenkins и FitNesse.
2. Про то как быть реактивным с Project Reactor и чуть-чуть Java 8.

Going Reactive - High Performance JVM Code with Reactor from JAX TV on Vimeo.
3.  Не помню было или нет, но вот вам штукес, который используется при отладке High-Frequency Trading систем (биржевые роботы то бишь) и позволяет сбрасывать на диск кучу всякого. В связке с предыдущим пунктом может быть  ого-го-го!.

4. Все начаали страдать API. И как следствие все начали думать над тем как его версионировать. Про способы, их преимущества и недостатки - раз и два.
5. Перевод часов случился, так что тем кто еще (а таких поверьте мне много) - курите.
6. Quick Start Guide по Robot Framework - no comments.
7. Продолжая тему Fault Injection которую я поднимал не так давно - ребята из Netflix тоже делают хитрые декораторы.
8. Как сделать расширение для Chrome если вы хипстер.
9. Десктопное приложение с блекджеком и шлюхами с видео и звуком внутри Docker-контейнера - да, можно.

Ну и на гуманитарные темы.
10. Про то как вставить группу тестирования в SCRUM
11. Еще раз про холократию.  - ну не готовы вы еще к этому, и не будете , если не попробуете :) 

А еще вчера вечером я был на CodeFreeze с Борисом Вольфсоном про ретроспективы и думаю что я напишу ряд постов про эту практику.

Книга: Роджер Сайп. Развитие мозга.

Прочитал. Точнее осилил. 
Книга представляет собой весьма странный винегрет. 
Начнём с того что само название книги в оригинале (Train Your Brain for Success. Read Smarter, Remember More, and Break Your Own Records) отражает суть винегрета внутри, однако МИФ почему-то (и действительно, почему ж это) это название переиначили. 

Книга действительно расскажет вам о том как запоминать больше. Это пожалуй самая большая её ценность. Техника тренировки памяти описанная в книге лично для меня заработала.
Вот только одно но - зачем мне помнить столько всего ненужного? 
 
Также книга претендует на некое вводное пособие по освоению скорочтения. 
Может быть это тоже кому-то пригодиться. Я лично пока никакую технику скорочтения не освоил и не планирую, судить не могу.

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

Отдельно буду утюжить так называемую практику силового часа. Перепечатывать кусок книги лень, суть вкратйе сводиться к последовательному выполнению утренних  ритуалов на ежедневной  основе, учитывании каждого из выполненных ритуалов себе как небольшого достижения. Таким образом, почти цитирую, вы начинаете утро со счётом по делам 15:0 в вашу пользу . Практика конечно не бесполезная , но сомнительно что невыполнение одной из шести главных задач на день(это тоже в книге есть) просто останется для практикующего счётом 15:1.

Оценка 5/10. Не рекомендуется к прочтению. Рецензент по чьей рекомендации была куплена эта книга отхватил минус в карму до нуля.

Напочитать: пред-SQADays-ное

1. Интереснейший полет мысли от Сергея Мартыненко

При наличии идеального тестового набора и идеального процесса отладки, автоматизация тестов  после написания кода – бессмысленная трата времени. Вредительство.И, да, рекордер не нужен.
С другой стороны, написание кода тестов до написания кода приложения вполне себе хорошая практика, прекрасно уживающаяся с идеальными тестовым набором и процессом отладки.
«Чем более хороша команда, тем от большего числа автоматизированных регрессионных тестов они должны отказываться. Написание кода тестов после написания кода приложения – удел …»

2. Прекраснейшая няшка для определения того что дольше всего грузится на странице.
3. Один из немногих рассказов про то как строили автоматизацию тестирование встройки. А вот тут уже кровушка, кишочки, все как мы любим.
4. Про то как Netflix начал тестировать своей Chaos Monkey хранилища на Cassandra.Круты, чо.
5. Ansible теперь кстати умеет Windows.
6. Длинная портянка от Twitter о том как они тестируются.
7. Никакой современный фреймворк или  библиотека нафиг никому не нужны если к ним нет нормальных  примеров и/или документации , а лучше когда есть все.
Robot Framework интенсивно таковой обзаводится - отличный гайд.
8. Наверное о том как надо преподавать тестирование. Хотя конечно хрен его знает как его надо преподавать - чем дальше живу, тем больше понимаю что это ремесло. В любом случае - автор статьи молодец, хотя бы уже потому что попробовал.

И да, уже совсем скоро будет конференция SQA Days.
Я вообще от нее не в восторге и для того чтобы придти в это состояние мне потребовалось посетить ее всего лишь раз.
Но другой - у нас (пока, по крайней мере) нет.
Надеюсь будет.

Книга: Henrik Kniberg. How to run an internal unconference

Доступна на LeanPub.
Прочитал за 2 часа.

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

Книга кстати дает отличное представление о том почему конференции стоят столько и почему
столько проблем с проведением каждой из них - читайте разделы Pre-event preparation и Onsite preparation.

И еще один нюанс на который хотелось бы обратить внимание - в книге есть отсылка на law of 2 feet и транзитом на http://en.wikipedia.org/wiki/Open_Space_Technology#Guiding_principles_and_one_law.
Почитайте внимательно. И запомните - Whatever happens is the only thing that could have

Оценки не будет потому что за книжку я ничего не заплатил.

Напочитать: постотпускное

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

После отпуска очень тяжело взять себя в руки.

1. Небольшой пример как тестировать accessability с помощью Selenium
2. Отличная презентация про Model-Based Testing 
3. Navigation Timing API теперь няшно и на node.js. Смотреть на гитхабе.
4. Небезызвестная компания Crisp (это там где Хенрик Книберг и Матиас Скарин) запустила свой канал на YouTube.
И продолжая тему Crisp вообще и Книберга в частности.
Два видео про инженерную культуру в Spotify
https://labs.spotify.com/2014/03/27/spotify-engineering-culture-part-1/
https://labs.spotify.com/2014/09/20/spotify-engineering-culture-part-2/
5. О том почему не нужно запускать ssh-сервера в Docker-контейнерах. Честно я даже до такого не додумался бы, но кого-то уже видимо прижало.
6. MySQL обзаведется REST API  - возрадуемся же этому.
7. О том как расово-правильно писать сообщения к коммитам в Git - отличная статья.
8. Хороший пример того что такое testability - Firefox позволяет подставить значения геолокации и как это делать с помощью WebDriver.
9. Очень многие люди в один день прокричали про эту вот вики с паттернами автоматизации тестирования как будто там прям сокровенное знание. Хотя может и сокровенное.
10. Мои коллеги  - Олег и Саша - взяли и прикрутили ACID к Cassandra.  Молодцы, чо.
11. MapDB. Занимательная хрень, которая видимо должна хорошо вписываться в задачи миграции данных между хранилищами.
12. Запустить десктопное приложение внутри Docker - можно. Мсье знает толк в извращениях.
13. Вот прям просто процитирую

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