Напочитать: Про разработку

Разгребаю скопившееся летом. 

1. Отличный доклад с обзором проблем распределенных систем.
2. В очередной раз про Property-Based Testing 
3. Как писать интеграционные тесты с ElasticSearch и LDAP рассказывает Micha Kops. Вообще, надо сказать, что его учетка на Bitbucket вызывает во мне чувство, которое можно передать только одной картинкой. Но молодец, да.

4. Отрелизили 20 версию Guava, в  которой появилась кучка нового, в том числе и пакетик с классами про графы.
5. Весьма интересный и крайне простой инструмент  - Architectural Decision Records. Только я бы не оформлял каждое  решение в отдельный документ, их надо слегка смантически структурировать.
6. Пространный набор предъяв к Docker. Обоснованно, чо.
7. О том как тестировать код с RxJava - тут.
8. Отличная байка от Тагира Валеева про лямбды и анонимные классы.
9. Тяжелая наркомания про генерацию исходного кода или диалекты Java - recaf
10. Рассказ про нюансы ProtoBuf
11. Бенчмарк (несмотря на то что Шипилев не велит) 114 алгоритмов хэширования.
12. Rocket Data и Falcor - два очень интересных проекта под IOS и Android от LinkedIn и Netflix соответственно которые представляют собой Middle-Tier для данных  в мобильных приложениях.
13. В Google уже совсем охуели в атаке перестали заморачиваться на тему вопроса "зачем оно надо?" и захерачили еще один фреймворк для DI - Tiger.
14. Yahoo (жив, курилка) заопенсорсил Pulsar - своя Kafka с преферансом и куртизанками.

Ну и напоследок - философское :

Probably the biggest problem is the state-space. Software is highly non-linear and discontinuous, unlike for example a bridge, or most other physical objects. If you change or remove a single bolt from a bridge, it is still the same bridge and its characteristics are largely the same. You need to remove quite a number of bolts for that to change, and the effects become noticeable before that (though they do get catastrophically non-linear at some point!). If you change one bit in a piece of software, the behavior is completely unpredictable. It could be the same, it could just crash, it could quietly corrupt data. That's why all those corner cases in the layers matter so much. Again, coming back to the bridge, if one beam has steel that has a slightly odd edge-case, it doesn't matter so much, you don't have to know everything about every beam, as long as they are within rough tolerances. And there are tolerances, and you can improve your odds by making things with tighter tolerances than required. Again, with software it isn't really the case, discrete problems are much harder than continuous ones.