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

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

Вот не поймешь, хвалят коллеги или ругаются... (с)
1. "Punishing failure makes it worse. Unshared failures are the experience of one individual. They are not institutional learning." ( by Jessica Kerr tweet)

2. The problem with root cause analysis is there’s always going to be another root cause.
Robustness happens at a higher level. And resilience at a higher level still. (by Jessica Kerr tweet)

3. Очередная история про Git от Сергея Сергеева, беседа в подкасте "Подлодка". Напомню ссылку на отличную лекцию Сергея.

4. "Тимлид — это сержант в IT-подразделении" - хорошее интервью с Романом Ивлиевым.

5. Неплохая панелька тимлидов с инсайдами из известных компаний.  Отлично смотрится на скорости х1.5


пятница, 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-ов в компании очень важная составляющая ее работы. Их нужно растить, искать, развивать. Без этого все очень сложно получается. Но, млин, так редко на моей памяти это происходит. Часто, а развитие чаще всего, это ложится на плечи самого лида. В целом то оно и правильно, но с помощью всегда лучше получается обычно. Если кому интересно, то тут вот в Питере правильная конфа будет в сентябре "Профессиональная конференция про тимлидов и для тимлидов".






пятница, 27 июля 2018 г.

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

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

1. Software architecture is about the design of your system and the impact it has on the system’s qualities, qualities like performance, security, and modifiability.  This definition discusses how architecture differs from detailed design and how some of your biggest design decisions can have implications deep into the code.

2. 3 типа архитектурного подхода:
Imagine that your performance requirements say that your system must respond to requests within 50ms.
Here are some possible ways that you could approach the system’s architecture, given the three design approaches:
• Architecture-indifferent design. If you followed architecture-indifferent design, you could copy the distributed processing architecture from your last system and discover, hopefully not too late, that its inter-machine messaging over head eats up most of that 50ms, leaving little time to do the real processing. To succeed, you either change the architecture or write very efficient code that can complete in 10ms.
• Architecture-focused design. If you followed architecture-focused design, you would deliberately choose an architecture that is compatible with that requirement, such as a client-server architecture. The single remote call to the server might take 10ms, which leaves you a reasonable 40ms to do the real processing.
• Architecture hoisting. If you hoist the performance goal into the architecture, you would ask yourself how the architecture could ensure that a 50ms response was always achievable. Perhaps your investigation reveals that there are peak demand times that could overload your servers, so you build software to recruit additional processing, perhaps from a cloud of servers.

3. How much design and architecture should developers do?
There is much active debate about this question and several kinds of answers have been suggested:
No up-front design. Developers should just write code. Design happens, but is coincident with coding, and happens at the keyboard rather than in advance.
Use a yardstick. For example, developers should spend 10% of their time on architecture and design, 40% on coding, 20% on integrating, and 30% on testing.
Build a documentation package. Developers should employ a comprehensive set of design and documentation techniques sufficient to produce a complete
written design document.
Ad hoc. Developers should react to the project needs and decide on the spot how much design to do.

4. The risk-driven model guides developers to apply a minimal set of architecture techniques to reduce their most pressing risks. It suggests a relentless questioning process: “What are my risks? What are the best techniques to reduce them? Is the risk mitigated and can I start (or resume) coding?”
The risk-driven model can be summarized in three steps:
1. Identify and prioritize risks
2. Select and apply a set of techniques
3. Evaluate risk reduction

5. Прочитал первые 3 главы. Пока не впечатлен. Продолжение следует. Дальше идут примеры. Посмотрим, как зайдет. 

пятница, 20 июля 2018 г.

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

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

1. Harvest, Yield, and Scalable Tolerant Systems (PDF)
Обычно мне тяжело даются такие "около академические" труды, CAP-теорема и вот это все. Но тут хорошо зашло: новые термины для того, что уже раньше использовалось в работе и обозначалось "на пальцах".

We assume that clients make queries to servers, in which case there are at least two metrics for correct behaviour: yield, which is the probability of completing a request, and harvest, which measures the fraction of the data reflected in the response, i.e. the completeness of the answer to the
query. Yield is the common metric and is typically measured in “nines”: “four-nines availability” means a completion probability of 0.9999 . In practice, good HA systems aim for four or five nines. In the presence of faults there is typically a tradeoff between providing no answer (reducing yield) and providing an imperfect answer (maintaining yield, but reducing harvest). Some applications do not tolerate harvest degradation because any deviation from the single well-defined correct behaviour renders the result useless.

2. За все время работы в разработке я часто сталкивался с верой в магическую должность "Архитектор" (Архитектор ПО, Системный архитектор и прочее). Видимо мне не повезло встретить и поработать с настоящими архитекторами, если они существуют. А сам я, IMHO, как-то хреново "архитектирую".
Тем не менее, вот вам несколько полезных ссылок про архитектуру ПО "на подумать-почитать":
3. "Программный комитет HolyJS изнутри" - подробный рассказ про процесс подготовку докладов (= содержательной части конфы) к конференции HolyJS. В нашем ПК Heisenbug конфы процессы очень похожие.

4. Немного истории из своего блога "Популярная психология в IT и не только".

5. Интересная цитата, надо книжку почитать
An Approach to Cybernetics (1961) by Gordon Pask
"Observers are men, animals, or machines able to learn about their environment and impelled to reduce their uncertainty about the events which occur in it, by dint of learning... [We] shall examine human observers who, because we have an inside understanding of their observational process, belong to a special category. For the moment, we shall not bother with HOW an observer learns, but will concentrate upon WHAT he learns about, i.e. what becomes more certain."




пятница, 13 июля 2018 г.

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

Привет. Очередные ссылочки и мысли за неделю.

1. Огненный доклад "Эффективность не работает" (осторожно мат).
Основная мысль: "Все люди работающие в IT больше 5 лет страдают расстройствами психики." Жестяк :)
"...ставьте в центр комнаты стул и сидите на нем целый день...ничего не делайте, вам будет очень плохо... но вы по крайней мере увидите, что если вы целый день них*** не делаете, то них*** не изменяется".


2. Неплохой тред в твиттере про правильную организацию "монолита".
source
3. И еще  одна статья про "микросервисы" vs "монолит": Goodbye Microservices: From 100s of problem children to 1 superstar

4. Забавная, но дорогая шарманка Catchpoint, которая поможет проверить вам, как ваше веб-приложение работает в разных локациях.  С UX там беда, но очень информационно полезная, как для дебага производительности сайта, так и для мониторинга доступности.

5. До сих пор перевариваю результаты Heisenbug 2018 Piter:
  • если у вас есть хоть малейшие сомнения в том, что вас могут неправильно понять - вас 100% неправильно поймут и немалое количество людей.
  • "ручное" тестирование все понимают по-разному
  • да чего уж там, вообще "тестирование" все понимают по-разному ;))) (привет, КО)

пятница, 6 июля 2018 г.

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

Чуть было не зафейлил начинание в самом начале. Заехал вечером в гости к бывшим коллегам (вы - крутые). И на радостях и эмоциях почти пропустил пост.

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

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

2. Тема SRE (Site Reliability Engineering) продолжает держаться в топе современных базвордов, отнимая пальму первенства у DevOps. При этом, по-прежнему, ее "готовят" по собственным рецептам, не всегда ведущим к ожидаемым результатам. Статья на эту тему "Google Explains Why Others Are Doing SRE Wrong"

3. Полезняха: "Сервис, позволяющий протестировать внешний вид любого сайта с разными веб-шрифтами. Просто вводишь адрес сайта, выбираешь шрифт из списка и видишь результат в реальном времени." (с) @HexletHQ

4. Application of modern testing for testing a modern application
Про культуру качества.
There are those who proclaim “automation is not real testing” and those who insist “manual testing is just a waste of time, automate all the things”. Both groups are right, yet wrong. You need automation and you need manual testing, but you need much more to create a product that is of shippable quality.

Классная картинка
Оригинал тут (с) by Redgate

5. Как одним слайдом отобразить архитектуру ИТ-проекта
Слайд может один, но вариантов проекций много. Очень актуально сейчас по работе.

пятница, 29 июня 2018 г.

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

Попробую новый формат: списочек из 5 интересных статей или видео пролетавших за 5 рабочих дней.

Скорее для себя в виде архивчика, но может и вы найдете себе что-нибудь полезное. Продолжение истории с "солянкой".
  1. Отличная лекция "Git — инструмент для совместной работы, с нуля и до регламента в команде" от Сергея Сергеева

  2. "The Problem You Solve Is More Important Than The Code You Write"
    Статья, основная мысль которой, "часто разработчики пишут код, ради кода":
    "Regardless of the path programming has taken since then, there's still a problem with the separation between business and software development — or "engineering"... If developers become too narrowly focused on development, they can miss the purpose behind the software they write. They may not see hidden solutions that don’t require any code." (читать дальше)

  3. Концептуальная карта и методы её визуализации
    "Концептуальная карта (concept map), предложенная в 60-70-е годы Джозефом Новаком из Корнельского университета(США) техника, сегодня активно используется в качестве простого инструмента визуализации предметных областей. Понятия предметной области отображаются вершинами графа, а отношения — ребрами. В отличии от еще более широко известных интеллектуальных карт (mind maps), концептуальная карта представляет собой именно граф, а не дерево(кстати, картой не является ни первое, ни второе). И как для любого плотного графа, для карты предметной области характерно катастрофическое возрастание сложности восприятия по мере роста количества вершин ....(читать дальше)

  4. Unit tests versus the unit tested
    Asking “what information does this test give me that no other test does?” is great heuristic for determining whether a test, especially an automated one, is worth keeping. It’s also a convenient go-to when evaluating whether a tester knows what they’re doing, and when trying to understand what a test does.
    Нужно уметь разделять тестирование юнитов и юнит-тестирование :). Хотя в целом терминологию часто путают. Но, главное, для себя понимать, что и для чего ты тестируешь. (читать дальше)

  5. "A STARVING MAN CANNOT LEARN TO FISH…"
    “Give a man a fish, he’ll eat for a day. Teach a man to fish and he’ll feed himself for a lifetime.” ... “But a starving person isn’t in the position to learn how to fish. You have to feed them before he can be taught.”...
    "Instead of trying to get the team to engage with testing models, templates and practices straight off the bat through coaching and pairing, perhaps instead we should focus on running the testing ourselves until the team is fed, happy and ready to learn." (читать дальше)

понедельник, 23 апреля 2018 г.

Конференция C++ Russia 2018 Санкт-Петербург - отзыв

20-21 апреля 2018 в Питере прошла очередная конференция C++ Russia.
В прошлый раз я был нахаляву, сейчас, спасибо SEMrush, не страдал от того, что мое участие хоть как-то не возместило трудозатраты Сергея Платонова, бессменного организатора C++ Russia.

Сам С++ я не вижу уже больше года :( , поэтому извините за уход от контента в сторону качества докладов с точки зрения подготовки докладчиков и слайдов, и просто атмосферы, которую попытался передать фоточками.

пятница, 23 марта 2018 г.

Тестирование в продакшене - миф или реальность?

На самом деле, вопрос стоит скорее так: "почему у вас его еще нет"?


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

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

Ну вот, я вас предупредил. Ссылки все равно есть, поэтому можете уверенно двигаться к их списку.

среда, 14 марта 2018 г.

Heisenbug 2018 Piter - подарок внутри статьи

Всем привет.

У нас закончился первый этап подготовки к Heisenbug 2018 Piter: костяк программы сформирован, начинаем работать с отобранными докладчиками, кидаем кости серьезно выбираем кандидатов на последние вакантные места в программе.
Читаем до конца...

Напомню, что конференция пройдет 17-18 мая в Петербурге. Акцент при выборе докладов делается на технический аспект. Не умаляя необходимости и важности процессов, метрик и прочего, мы стараемся выбрать те заявки, которые имеют практическую инженерную ценность.

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

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

Но Heisenbug - это конференция про тестирование, не только для тестировщиков.

Тут можно посмотреть те доклады, которые уже точно будут:

Michael Palotas – спикер многих конференций по программированию и тестированию. На Heisenbug выступит с докладом про использование Selenium в энтерпрайзе;

Виталий Фридман – фронтенд-гуру, создатель и главный редактор Smashing Magazine. Доклад будет посвящен тестированию различных привычных элементов responsive веб-дизайна;

Станислав Башкирцев – инженер из EPAM с докладом о строителях Древнего Египта и пирамидостроении в тестировании;

Adam Goucher – The Mobile Experience Company. Расскажет о тестировании облачных приложений.

Мы очень ждем встречи с Michael Bolton, рассказывать о котором, я думаю, смысла нет.

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

Купить билет со скидкой (по цене предыдущего месяца) можно воспользовавшись промокодом MaxShulgaPromo

Что было на предыдущих конференциях:

От танков до АЭС: оглядываясь на Heisenbug 2017 Moscow
TOП-10. Разбор лучших докладов в свободном доступе. Heisenbug 2017 Moscow
23 лучших доклада Heisenbug 2017 Moscow
Гейзенбаг 2.0: как прошла в Петербурге конференция по тестированию