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

1.Красивые warning-и при компиляции через аннотации http://habrahabr.ru/post/247509/

2. О том как бывает Code-Review в Google http://www.quora.com/What-is-Googles-internal-code-review-policy-process
3. Подборка YouTube-каналов с лекицями по вэб-разработке.
4. Заблуждения о времени и именах людей.
5. Огромная подборка java-библиотек по визуазации графов.
6. Интересная подборочка библиотек и фреймворков за 2014 год. Лично для себя узнал про Jamon, awaitlitiy, может быть гляну на кое-что еще.
7. У этого человека есть много очень похожих выступлений, но это одно из наиболее развернутых и акцентирующих внимание на техническом аспекте.

8. Отличное выступление Chad Fowler про то что Legacy - это то, чем можно гордится, а не то что вы все про это думаете.


9. Кто еще не видел эту замечательную картинку про инструменты для мониторинга и диагностики состояния системы - смотрите.

10. Отличный обзор того каким бывает mutation testing. С подборкой библиотек по языкам.

11. Придурковатый наброс на тему "почему вам надо обязательно опенсорсить". Но привел по ссылкам к вот этой вот штуке в вики. ИМХО - опенсорсить нужно только то, что решает не только ваши проблемы. 95% если не 99% кода на гитхаб просто лежат и никому, кроме как создателям, этого кода не нужны. Оставшиеся 1-5% действительно несут кое-какую пользу, но большей частью присутствуют в открытом доступе по политическим соображениям нежели, потому что кто-то это форкнет и начнет вам слать pull-request-ы c хорошими фичами и еще покрытием тестами.

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


12. Ну и немного юмора

simple — It solves my use case.
opinionated — I don’t believe that your use case exists.
elegant — The only use case is making me feel smart.
lightweight — I don’t understand the use-cases the alternatives solve.
configurable — It’s your job to make it usable.
minimal — You’re going to have to write more code than I did to make it useful.
util — A collection of wrappers around the standard library, battle worn, and copy-pasted from last weeks project into next weeks.
dsl — A domain specific language, where code is written in one language and errors are given in another.
framework — A product with the business logic removed, but all of the assumptions left in.
documented —There are podcasts, screencasts and answers on stack overflow.
startup — A business without a business plan.
hackday — A competition where the entry fee is sleep deprivation and the prize is vendor lock in.
entrepreneur — One who sets out to provide a return on investment.
serial entrepreneur — One who has yet to provide a return on investment.
disrupt — To overcome any legal, social, or moral barrier to profit.

GTAC 2014 Post-Mortem

Вместо предисловия.
Второй год пытаюсь попасть на GTAC, второй год меня не приглашают.

Уже второй год с командой отсматриваем видео с пожалуй самой лучшей конференции по автоматизаированному тестированию - Google Test Automation Conference.
В этот раз решил написать и сюда.

Про саму конференцию читать здесь.
Видео докладов здесь.

Я буду писать только о тех выступлениях что мне понравились или хоть чем-то зацепили.

1. Opening Keynote - Move Fast and Don't Break Things - рассказ о том как на самом деле все в Google в области автоматизации тестирования. Сурова правда жизни состоит в том что и у них есть нестабильные тесты, они тоже релизят с известными багами, если те не мешают релизу. Очень понравилась идея Robosheriff - автоматический анализатор нестабильных тестов.
2. Make Chrome the best mobile browser - рассказ о том как тестируется мобильная версия Google Chrome. Очень впечатлила инфраструктура построенная вокруг процесса тестирования и работа проведенная в области Testability продукта. И да - эти ребята тестируются на реальных устройствах (Android/IPhone).
3. Test coverage at Google - рассказ о том как меряют покрытие кода в Google.  Ничего принципиально нового по сравнению с их же статьей нет. Понравилось то что в IDE подсвечиваются строчки непокрытые тестами.
4. I Don't Test Often ... But When I Do, I Test in Production - рассказ от Netflix о том как они используют приматов для тестирования своей amazon-based архитектуры.  Отличный пример того как понимание важности устойчивости на ранних этапах привело к созданию и регулярному использованию весьма специфичных инструментов.
5. The Importance of Automated Testing on Real and Virtual Mobile Devices - ничего интересного кроме яркого (пусть даже немножко "продажного") освещения проблем разработки на мобильных устройствах  и тестирования там же. 
6. Free Tests Are Better Than Free Bananas: Using Data Mining and Machine Learning To Automate Real-Time Production Monitoring - поиск инвариантов на production-среде с использованием техник Machine Learning.
7. Test Automation on an Infrared Set-top Box - блестящий доклад от том как инженерное мышление и Raspberry Pi помогли тестировать телевизионные приставки автоматически. Молодцы!
8. Never Send a Human to do a Machine’s Job: How Facebook uses bots to manage tests - рассказ от качка из Facebook о том что следить за автотестами тяжело поэтому они придумали систему ботов которые мониторят и анализируют результаты автотестов и дают обратную связь авторам автотестов об их поделиях. Аналогично Robosheriff из п.1.
9. The Testing User Experience - продолжение темы из п.1 и п.8  - анализ результатов автотестов и их стабильности.
10. Going Green: Cleaning up the Toxic Mobile Environment - эта гоп-бригада там уже второй год подряд - костюмированное представление на тему того как все непросто при тестировании Android приложений. Я бы не имел ничего против если б эти ребята были не из Google, но когда инженеры Google говорят о том что другие инженеры Google вот тут и тут сделали неправильно и плохо, то может хотя бы одни сходят и исправят ситуацию? 

Вот тут вот один товарищ смачно резюмировал 

Whilst there seemed to be some suggestions for dealing with flaky tests (like Facebook running new tests x times to see if they fail and classify them as flaky and assign to the owner to fix), there didn’t seem to be a lot of solutions for avoiding the creation of flaky tests in the first place which I would have liked to see.

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