17 ноября 2022 г. Умер Фредерик Брукс.

Наиболее известен своими двумя культовыми произведениями.
Книгой "Мифический человек-месяц." Книга написана в 1975 году, но многие описанные ситуации можно видеть и по сей день. На 20 летнюю годовщину ее переиздали и добавили 4 новые главы.

Оттуда же родился закон Брукса. "Если проект не укладывается в сроки, то добавление рабочей силы задержит его ещё больше.". Второй раз рекомендую эту книгу, но она реально того стоит.

Второй труд - статья "Серебряной пули нет", фраза стала почти заклинанием в сфере разработке ПО. Многие принципы стали аксиомами (для тех кто их понимает и принимает). Например - использовать массовый рынок, чтобы избежать создания того, что можно купить; использовать итеративную и инкрементальную разработку, добавляя к системам все большую функциональность по мере их запуска, использования и тестирования.

Зачем стоит читать эти два произведения? Чтобы понять образ мыслей успешных менеджеров в сфере разработки ПО, понять какие процессы происходят при разработке и как их можно менять. Предупрежден значит вооружен.

Grafana анонсировала на ObservabilityCON 2022 новый продукт. Grafana Phlare - новое хранилище для данных по профайлингу

Их keynote доклад на конференции про все свои продукты.

https://vimeo.com/767154420

#observability

Классный пост от Mobile Developer Experience team в Slack (DevXp). В прошлый раз я уже писал как другая dev xp team внедрила удаленные окружения для команд в Slack.

За 5 лет команда поработала с многими вещами влияющими на производительность.
- Время сборки проектов на iOS/Android. iOS - Уменьшили время почти в два раза. c 9 минут до 4.5. Android - c 50 минут до 20.
- Мигающие тесты. уменьшили количество сбоев тестов с 57% до 4%

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

Картинка расчета ценности которую может принести такая работа над dev experience. Из расчета 100$/час.

Очень нравится продуктовый подход, только так и никак иначе надо делать любые внутренние улучшения для разработчиков. Продукт для разработчиков = тоже продукт.

https://slack.engineering/mobile-developer-experience-at-slack/

#developerexperience

Fearless Responsible Development: How to Move Quickly without Compromising on Quality (Wix engineering)

"But still, we don’t have pre-production or testing environments, we test our changes directly on the production environment, and when a developer pushes a code change, it can reach production in hours or even minutes, without a manual QA in the process.

So how can it be done while also making sure we are being very cautious and responsible? Let’s see…"

- High-coverage of tests;
- E2E production tests;
- Performance testing;
- Feature toggle;
- Gradually roll-out a change to production;
- Monitoring during roll-out;

Завидую компаниям у которых продукт не состоит из миллиона интеграций и его реально можно затестить.

https://www.wix.engineering/post/fearless-responsible-development-how-to-move-quickly-without-compromising-on-quality

На мой взгляд это замечательная история о том, что если руки прямые, то решить можно любую проблему. Разработчики одного стартапа решили не вносить себе в схему новые компонент с которым у них мало опыта (позже напишу еще один пост про это). А воспользоваться понятной базой. Они протестировали решение и оно справилось с поставленной задачей!

p.s. Это не агитация так делать, это всего лишь хорошая статья про то, что надо взвешивать все решения и понимать плюсы и минусы во всех случаях.

https://dagster.io/blog/skip-kafka-use-postgres-message-queue

Netflix умудряется автоматизировать совершенно неожиданные вещи. Сделали инструмент который помогает видеоредакторам создавать трейлеры. Он находят самые удачные кадры (одинаковое движение, яркость/фон, силуэты) и выводит их для анализы первыми.

А еще они стали делать минивидосы на свои тех статьи, этакие мини тех фильмы. Хороши конечно.

https://www.youtube.com/watch?v=7jJs5ATcH0w

https://netflixtechblog.com/match-cutting-at-netflix-finding-cuts-with-smooth-visual-transitions-31c3fc14ae59

Мастер-класс от команды Gitlab как найти проблемы с инфраструктурным компонентом. Кстати график на скриншоте и правда характерный, тоже встречал в работе, теперь буду знать.

https://about.gitlab.com/blog/2022/11/28/how-we-diagnosed-and-resolved-redis-latency-spikes/

Хорошая памятка по System Design. Основные вещи про которые надо помнить проходя этот этап интервью.

#systemdesign

Простой и понятный вижуал по git. 8 команд в одной картинке.

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

Проект начался именно как читальный клуб в начале Апреля 2022 года и за это время очень хорошо вырос и активен. Есть архив всех встреч (кроме 3-4 первых), можно просмотреть в своем темпе. Видео\Аудио
https://xn--r1a.website/backend_megdu_skobkah

Книжный клуб Tinkoff был долго время внутри компании, потом естественным образом стал доступен всем. Есть видео записи встреч.
https://xn--r1a.website/its_reading_club

Инициатива разработчиков из Dodo Engineering, ребята очень бодро начали, но с начала года новых анонсов небыло, будем думать что на паузе. Можно посмотреть\послушать старые записи. Тут есть аудио версии встреч с обсуждениями в виде подкастов.
https://xn--r1a.website/readingtogetherdev

И небольшая подборока по теории (включая мой опыт), если вдруг захотите организовать у себя в компании такое событие:

- https://zendesk.engineering/recipes-for-running-a-successful-technical-book-club-at-work-4a7f18ffab42
- https://www.capitalone.com/tech/culture/team-building-with-technical-book-clubs/
- https://circleci.com/blog/if-you-want-your-engineers-feedback-on-your-stack-start-a-book-club/
- https://xn--r1a.website/neverendingit/330

Решение проблем в разработке (troubleshooting). По мнению автора статьи есть 4 основных шага:

1. Идентификация проблемы
2. Сбор информации
3. Применение решения
4. Проверка решения

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

https://www.oreilly.com/content/4-steps-to-solving-any-software-problem/

Какие технические роли есть после Senior, как туда можно прийти и к чему быть готовым. Отличное интервью с классными спикерами. Настоятельно рекомендую, много интересных мыслей.

https://www.youtube.com/watch?v=n9Wjlei7MYE

К 2017 году кодовая база Uber очень сильно разрослась. 10+ языков программирования, 4000+ сервисов, 500+ веб приложений. На каждое, отдельный репозиторий. Такое количество репозиториев породило проблемы: фрагментация версий библиотек, фрагментация инструментов сборки, управление зависимостями. Было решено перейти на монорепо.
Но монорепозиторий породил другие проблемы - подкачка новых изменений, сборка проекта, IDE очень долго создаёт индекс для репозитория. Как решение этой проблемы создали удалённую окружение разработки.  Разработчик выбирает сервисы, в "облаке" скачивается копия нужная копия монорепо (dev, prod). Его IDE подключается к удалённому хранилищу, и разработчик может продолжить работу. Как и в любом кейсе, не забыли посчитать результаты (на сколько улучшили ситуацию) и эффективность (buy vs build).

https://www.uber.com/blog/devpod-improving-developer-productivity-at-uber/

Попался на глаза официальный анонс в блоге Google о запуске сервиса gmail от 1 Апреля 2004 года. Пользователям предоставлялось 1 GB хранилища бесплатно. Сравните как запускают сервисы сейчас.

"The inspiration for Gmail came from a Google user complaining about the poor quality of existing email services, recalled Larry Page, Google co-founder and president, Products. "She kvetched about spending all her time filing messages or trying to find them," Page said. "And when she’s not doing that, she has to delete email like crazy to stay under the obligatory four megabyte limit. So she asked, ‘Can’t you people fix this?’"

The idea that there could be a better way to handle email caught the attention of a Google engineer who thought it might be a good "20 percent time" project. (Google requires engineers to spend a day a week on projects that interest them, unrelated to their day jobs). Millions of M&Ms later, Gmail was born."

http://googlepress.blogspot.com/2004/04/google-gets-message-launches-gmail.html?m=1

Команда gitlab решила проверить можно ли с помощью chatgpt решить простую задачу из беклога gitlab. Получилось интересно. Спойлер - да можно, но помощь человека все ещё нужна, кроме того на данном этапе код получается, очень элементарный. Так что без работы не останемся.

https://about.gitlab.com/blog/2022/12/15/can-chatgpt-resolve-gitlab-issues/

What is The Law of Demeter (LoD) : LOD is a software design principle that was first described by Ian Holland at Northeastern University in 1987. The principle is named after the Greek goddess of the harvest, Demeter, and is also known as the “principle of least knowledge” or the “principle of least coupling”.

https://medium.com/@connect2grp/java-programming-principles-law-of-demeter-d097e6d60df0

Хороший диалог с CTO компании Puppet о platforms engineering. Также как и в случае с DevOps есть большой риск в неправильной имплементации идеи, потому что также как и с девопс DevOps нет четких границ и правил для таких команд/платформ. Плюс к тому даже внутренняя платформа это продукт, со всеми вытекающими атрибутами.

A lack of definition for DevOps enabled early adopters but didn't allow late-majority enterprises to be successful in their adoption of DevOps. The platform engineering community is in danger of repeating this mistake.

Most enterprises fail at transformations like this because they implement them via project management instead of product management.

https://www.infoq.com/articles/platform-engineering-roadmap

Дорогие подписчики!

С наступающим вас новым 2023 годом! Счастья, здоровья и благополучия вам всем!
🥂🎄:🎅🎁