Книга: Мир в 2050 году

Для начала видео на котором Рей Курцвейл рассказывает о том каким будет наше с вами будущее.

Смотреть на TED

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

Почему я пишу про Курцвейла ? Потому что от просмотра его выступления вы получите больше пользы чем от прочтения книги "Мир в 2050 году".

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

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

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

В остальном книга бесполезна. 

Оценка 4/10.

P.S. жалко нельзя сдать обратно.

Автоматизация тестирования: Как падать более элегантно

Если нельзя, но очень хочется - то можно.

Решил написать про отложенные ассерты.
Эта техника появилась у нас более года назад.
Аналогичная техника есть в TestNG - там она называется SoftAssert.
Прочитать про нее можно вот тут и тут.
От TestNG мы отказались и их SoftAssert-ами никогда не пользовались, а вот техника прижилась.
Мне очень не нравится слово SoftAssert - ассерт не может быть мягким.
Мы называем это Delayed Assert - ассерт все равно случится и если условие не выполнено тест упадет, но сделает это позже, пройдя через еще пару точек проверки (может быть :)).

Зачем оно надо? 

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

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

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

Таким образом тест у нас проверяет одну точку функционала по одному критерию  обычным assert-ом, а ряд дополняющих - с помощью отложенных assert-ов.

Как оно работает? 

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

В натуре

Проект выложен на гитхабе.
https://github.com/kronar/delayed-asserts

Gist c примером того как оно падает.
https://gist.github.com/392a0f488127f811d7a2.git

Книга: Дэвид Стрейкер - Быстрое решение проблем при помощи стикеров

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

Объясню почему - использование бумаги и ручки связано с процессами визуализации образов, которые находятся в вашей голове. Сам процесс визуализации достаточно энергозатратным - вам нужно достать нечто метафизическое из своей головы и, с достаточно высоким уровнем потерь детализации, перенести это нечто на бумагу (квадратики,  кружочки, стрелочки - это максимум наших способностей к визуализации,  даже несмотря на суровый курс черчения в ВУЗе карандашом на бумаге :)) . 

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

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

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

Теперь о книге. 
Книга не про это. Да это и не книга вовсе - это методичка (150 страниц) . Хорошая,  добротно написанная методичка. Она нужна для того, чтобы быть пошаговым руководством к отработке на практике приемов решения проблем с использованием такого инструмента как стикеры.

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

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

Я хочу чтобы таких методичек было больше.

Дима Лазарев - издавай еще.

Максу Дорофееву - спасибо, что подарил!

Майнд-мапа по книжке.

Оценка 9/10.

Напочитать: Java выпуск

Так уж сложилось что выпуск почти полностью про Java. Извиняйте.

1. Как же иногда хочется своими шаловливыми кривыми ручонками какую-нибудь гаечку подкрутить в продакшене.
Хорошо что этого часто сделать нельзя.
Но все меняется - многие уже научились встраивать маленькие http-сервачки внутрь своих продуктов для того чтобы их можно было мониторить/обслуживать. Кто-то идет дальше - и встраивает целые shell-оболочки.

Статья на хабре в качестве апперетива.
Репозитории на гитхабе - раз и два.

2. Контейнеры. Сколько про них кричали 10 лет назад, а сейчас все развернулось в обратную сторону - долой их!!!
Красочная презентация с JAX Conf о том почему долой.

3. 56 страниц диаграмм и текстов о том чем сейчас дышит мир разработки на Java. Некоторые цифры прям вообще неожиданны для меня.

4. Вот тут вот я рассуждал про большие кодобазы. Мои рассуждения не остались не замеченнымии мой коллега по цеху  - Саша Баяндин  - прислал пару ссылочек в продолжение тематики репозиториев кода размерности более XXXL - вот про Git и про Mercurial тоже есть.
Вот тут еще одно страшное и непонятное место но по той же проблеме от Facebook.

5. В мире Java случалось несколько больших ошибок - одна из них API для работы с датой и временем.
Сейчас это исправляют, по факту внедряя API от JodaTime.
JodaTime разрабатывается уже очень давно и разобраться в нем весьма непросто.
Это пожалуй пока самая лучшая статья которую я видел, но она не про JodaTime, а про Date and Time API Java 8.

6. Вокруг POJO/Java Beans/Value Objects  уже поломана куча копий а сверху преизрядно нагажено. И конца не видно.
Существуют такие вещи как Project Lombok, Project Auto от Google. Вот и еще один - Rekord.

7. Надо и мне пройтись по теме Java 8. Очень рад что она вышла наконец - это действительно что-то большое с момента релиза 5-ки. Переходить пока на нее не буду по двум причинам - не верю я в релизы  с 0 на конце (:-)) и нужно будет кое-что переколбасить внутри своего хозяйства.
В частности многие велосипеды типа RxJava и Guava теперь не нужны - Stream API, Optional и предикаты теперь официально есть в 8-ке.
Молодцы что выпустили. Long live, Java!
Обзорные статьи про возможности.
раз 
два
три
И совершенно отдельно хочется отметить Nashorn - возможность запускать скриптовые языки вообще и JavaScript в частности внутри JVM.
Жду первых  портов node.js проектов на JVM стэк :-D
Обзор того как оно выглядит у Steve Jin

На этом на сегодня все. Любите джаву - это ведь не только язык программирования но и сорт кофе.