Julia Evans сделала всем подарок и заопенсорсила песочницу для nginx конфигов

https://jvns.ca/blog/2023/07/08/open-sourcing-the-nginx-playground/

Вы еще не пользуетесь rector? Тогда мы идем к вам!

Способ уменьшения боли при рефакторинге для обновления (да и не только, там тысячи сценариев для анализа и исправления кода).

Подробности тут https://habr.com/ru/companies/oleg-bunin/articles/720216/

Понимание PHP-FPM: полное руководство

В этой статье изучается мир PHP-FPM, изучая его функции, преимущества и то, как он может повысить производительность приложений на основе PHP.

Хорошая статья об организации прокси (шины данных) между клиентами и kafka от Ozon
https://habr.com/ru/companies/ozontech/articles/749328/
И еще недавняя статья от Авито об их реализации https://habr.com/ru/companies/avito/articles/726564/
Мы же в Zoon используем kafka-pixy с небольшими доработками https://github.com/zoonru/kafka-pixy

Да, в PHP тоже нужно следить за памятью
https://habr.com/ru/articles/748352/

Когда будет сделано

Ключевой контринтуитивный вопрос в планировании не «сколько проект делается в днях», а «когда будет сделано». У меня ушел день на понимание разницы в свое время. Сегодня был первый раз когда я смог дать такой обоснованный ответ с данными.

Обычно, для планирования проекта мы берем старшего инженера и просим проект запланировать. Человек уходит на неделю в пещеру, изучает, разбивает проект на задачи, выясняет зависимости, оценивает каждую задачу в днях и возвращается с числом: 42.

Чем более опытный профессионал тем больше буфера заложено в оценку. Потому что лучше выкатить раньше, чем протянуть срок. Здесь кроется первая ошибка. Если вы не допускаете проскальзывания сроков, то ни о каком точном планировании речи быть не может. Вы постоянно будете добавлять буфер, чтобы успеть наверняка. В английском есть идиома to sandbag — дословно — огораживаться мешками с песком. Чтобы защититься от наводнения или пуль.

Точное планирование, как и любое предсказание дается со степенью уверенности:

 — 85%, что мы выкатим проект к указаной дате.
 — Клиент вредный, давай по 95% посчитаем. Сколько надо еще времени

Как получить оценку, да чтобы еще с разной степенью уверенности. Не просить же инженера выдумать такое распределение?

Выдумывать не нужно. Все необходимое у вас уже, скорее всего есть. 1) Вам нужно знать сколько тикетов в неделю закрывает команда. Для этой статистики нужно брать проектные тикеты, а не все подряд, типа багфиксов. Такой статистики нужно как минимум за 7 прошлых недель. 2) Дальше вам нужно знать сколько тикетов предстоит сделать. Важно, чтобы тикеты были нарезаны в разумном диапазоне и не отличались на 500% друг от друга. 3) Вам нужно знать, сколько всего людей будет работать на проекте минимум и максимум.

Вот и всё.

Если вы хотите улучшить качество предсказания, то желательно добавить 1) время, которое вы тратили на тикеты в прошлом (lead time) и 2) расхождение с планом в прошлых проектах. Иногда начинаешь проект на 10 задач, а заканчиваешь с 40.

Эти данные загружаем в симулятор Монте-Карло. Этот симулятор я подсмотрел в рассылке для менеджеров в Амазоне. Сам симулятор работает прямо в браузере и никуда ваши данные не отправляет.

Симулятор прогоняет десятки тысяч возможных исходов вашего проекта и дает вам график распределения вероятности исходов. Те самые проценты, которые можно показывать заинтересованным лицам.

[иллюстрации так же в комментариях]

Таблица вероятности.

График распределения вероятности.

По моему опыту заинтересованным лицам и парировать нечем. Данные выглядят очень убедительно и взяты не с потолка, а из статистики работы команды.

В моем случае 100% совпали с оценкой программиста, только дата была далеко дальше дедлайна и нас гарантировано бы начали уговаривать придумать дату ближе к дедлайну. Крыть бы нам было нечем.

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

Не откладывайте на потом, как это сделал я. Вам нужно всего 7 недель данных. Попробуйте в понедельник, хоть прямо на том проекте, который у вас уже в процессе.

Пост: https://teamleadtalks.com/koghda-budet-sdelano/

Вступайте в сообщество.

Код-ревью: cookbook от Google
- Цель код-ревью - убедиться, что код со временем улучшается.
- Рецензенты должны одобрять CL, если он улучшает код.
- Не существует идеального кода, есть только лучший код.
- Рецензенты не должны требовать от автора полировки каждой строчки CL.
- Рецензент должен стремиться не к совершенному коду, а к постоянному совершенствованию.
- Не следует использовать многопоточность, если она может вызвать deadlock или race condition.
- Рецензент должен быть благожелательным, объяснять свою мысль и указывать на проблемы.
- Рецензент должен быть полезным, но не давать детальных инструкций или писать код за разработчика.

https://habr.com/ru/articles/737012/

Конспект книги «Создание микросервисов»
• Создание микросервисов: идея, преимущества, недостатки.
• Микросервисы: особенности, преимущества, недостатки.
• Разделение монолита на части: причины, проблемы, решения.
• Тестирование: виды, особенности, рекомендации.
• Мониторинг: важность, особенности, рекомендации.
• Безопасность: принципы, решения, рекомендации.
• Масштабирование: вертикальное, горизонтальное, кеширование.
• Обнаружение сервисов: DNS, DNS-серверы, API-шлюзы.
• Документация: важность, связь с кодом, примеры.

https://habr.com/ru/articles/499386/

9 Методов проверки работоспособности команды для раскрытия потенциала команды

• В статье представлены различные подходы к проверке работоспособности команды, такие как Parabol, Spotify "squad", Atlassian Team Health Monitor, Agile, Радар здоровья команды и другие.
• Эти подходы помогают командам оценить свое эмоциональное благополучие, динамику межличностных отношений, баланс между работой и личной жизнью и эффективность.
• Регулярные проверки работоспособности команды помогают выявить проблемы на ранней стадии и улучшить производительность.
• Вопросы для проверки работоспособности команды могут быть разными, но все они должны оценивать текущую ситуацию, вдохновлять на размышления и поощрять беседу между членами команды.
• После проведения проверки работоспособности команды можно предпринять такие действия, как разбор полетов, установление целей и планов действий, отрегулировать командные процессы, обеспечить обучение и поддержку, а также создать графическую сводку результатов.

https://www.parabol.co/blog/team-health-check-methods/

– Онлайн-митап для бэкендеров — Avito Backend United meetup #7: Долма

31.08 | 18:30 (UTC +4) или 17:30 по Москве
Спикеры: AvitoTech | Yandex Cloud | Тинькофф

Поговорим об инфратестах в Kubernetes, рассмотрим аналоги ПО для небольших проектов. Обсудим линтеры и форматтеры кода, подходы к миграциям как к микросервисам.

Смотреть из любой точки мира в прямом эфире. Чтобы получить напоминание о нём ➡️ зарегистрируйтесь.

PHP Fibers: практический пример

• Fibers в PHP 8.1 - новая функция для асинхронного программирования.
• Fibers позволяют выполнять несколько задач одновременно, экономя время на ожидании внешних ресурсов.
• Fibers работают только с внешними ресурсами, не затрагивая PHP-код.
• Пример использования Fibers: переборка каталога видеофайлов и создание 30-секундных клипов с помощью FFMpeg.
• Синхронный код занимает 243,1 секунды, асинхронный с Fibers - 143,7 секунды.
• Ограничение параллелизма в 3 позволяет процессору выполнять больше задач одновременно.


https://habr.com/ru/articles/756642/

​«Тимлид по сути — это сейчас мета-роль. Матрешка из обязанностей. Многие думают что им выпала великая честь чем-то там управлять. Но неплохо для начала начать с себя».

Автор руководитель уже 4 года. Он рассуждает о том, каким тимлидство бывает, а каким должно быть. В конце статьи дается один важный совет для тех, кто сейчас работает лидом в России.

Вот, ниче лучше по go в открытом доступе не видел на тему чистой архитектуры
https://evrone.ru/blog/open-source/go-clean-template

Обзор NativePHP. Инструмент для создания собственных нативных desktop приложений на Laravel
https://habr.com/ru/articles/761740/

PHP 8.3 released! 🐘
https://www.php.net/releases/8.3/en.php