пятница, 17 августа 2018 г.

5 за 5 (история 8)

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

1. Building and Testing Resilient Web Applications with Toxiproxy.
Статья, видео.
"A resilient system is one that functions with one or more components being unavailable or unacceptably slow. Applications quickly become intertwined with their external services if not carefully monitored, leading to minor dependencies becoming single points of failure.
For example, the only part of Shopify that relies on the session store is user sign-in - if the session store is unavailable, customers can still purchase products as guests. Any other behaviour would be an unfortunate coupling of components. This post is an overview of the tools and techniques we used to make Shopify more resilient in preparation for the holiday season."

2. What is Soak Testing?
"Soak testing (otherwise known as endurance testing, capacity testing, or longevity testing) involves testing the system to detect the performance-related issues such as stability and response time by requesting the designed load on a system."

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

4. Тред в твиттере про то, что для влияния инженеру не нужно становиться менеджером.

5. Небольшой тред-слайды в твиттере "Chaos Engineering is about engineering around the chaos inherent in the system".



пятница, 10 августа 2018 г.

5 за 5 (истории 6-7)

Последняя неделя отпуска прошла в режиме "без связи", поэтому предыдущий выпуск пропустил.
В этом нагоняем, продолжая читать "Just Enough Software Architecture" и добавив интересных ссылок.

1. Работа команды над решением задачи снижения риска ухудшения архитектуры путем прояснения текущего ее состояния для новых членов команды:
we were aware of providing coverage of the three primary modelsthe domain, the design, and the code models —and also the three primary architectural viewtypesthe module, runtime, and allocation views.
We started with the easiest documentation to produce and gradually added in more expensive parts. After each one, we asked ourselves if the risk had substantially reduced and we calibrated that evaluation based on our coverage of the viewtypes and models. When possible, we built representative and textual models rather than fully general and graphical ones. We decided to create a graphical model of our modules and component assembly since they were relatively easy to produce and conveyed more information than our textual models. We stopped when we had covered the primary models and viewtypes, trusting that the new developers would be able to use what we provided as a skeleton of understanding and would hang detailed knowledge from it.

2. Risk-driven approach to software architecture consists of identifying risks, deciding the best set of techniques to mitigate the risks, and then evaluating the remaining risk...
Instead of applying architecture techniques until we ran out of them, until the documentation binder was complete, or until the project was canceled, we regularly re-evaluated the remaining risks and stopped when they had subsided.

3. The core of architectural understanding is to be able to get at the “why” questions. Having the understanding does not mean you must follow a certain process, or program in a certain language, or write diagrams on paper. Understanding software architecture means that you have internalised the (admittedly incomplete and imperfect) knowledge and abstractions that have been built up, and that you can apply that understanding when building new systems or analysing existing ones.

Дальше книга не идет :( Отложил пока в сторону.



Новости:
1.  Анонс Heisenbug 2018 Moscow. Ждем докладчиков, и можно уже планировать билеты и поездку.

2. Отличная статья про машинное обучение для тех, кто не знает, но стеснялся спросить: "Машинное обучение для людей. Разбираемся простыми словами".

3. Андрей Сатарин зафигачил хороший тред про тестирование.

4. How to measure exploratory tests?

5. Мысли вслух: институт team lead-ов в компании очень важная составляющая ее работы. Их нужно растить, искать, развивать. Без этого все очень сложно получается. Но, млин, так редко на моей памяти это происходит. Часто, а развитие чаще всего, это ложится на плечи самого лида. В целом то оно и правильно, но с помощью всегда лучше получается обычно. Если кому интересно, то тут вот в Питере правильная конфа будет в сентябре "Профессиональная конференция про тимлидов и для тимлидов".