Ерванд Агаджанян, бэкенд-разработчик в EMCD Tech, рассказывает о планировщике Go

Основываясь на материалах из книги Уильяма Кеннеди Ultimate Go, автор сначала кратко уделяет внимание планировщику ОС, после чего уже переходит к планировщику Go.

Читать

Разработка data-driven приложения с использованием Go и Kafka

Разбираемся, как написать простую копию Twitter, где у каждого пользователя есть временная шкала и лента рекомендаций.

Читать (pdf-файл для тех, у кого не открывается Medium)

Защита вашего PHP-приложения: лучшие практики

Здесь представлен небольшой список для начинающих разработчиков, который покажет, что надо учесть для сохранения безопасности вашего приложения, например:
✔️Проверка ввода
✔️Предотвращение SQL-инъекций
✔️Управление сессией

Топ-10 архитектурных стилей и паттернов: шпаргалка для разработчика, основанная на статье в блоге ByteByteGo System Design Alliance.

1. Layered
2. Component-Based
3. Service-Oriented
4. Distributed System
5. Domain-Driven
6. Event-Driven
7. Separation of Concern
8. Interpreter
9. Concurrency
10. Data-Centric

Семь принципов хорошего программиста

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

Тут как раз ведущие подкаста «РАДИО-Т» обсудили каждый из принципов (01:08:43-01:55:35). Залетайте и слушайте👇

1️⃣ DRY (Don't Repeat Yourself)
2️⃣ KISS (Keep It Simple, Stupid)
3️⃣ YAGNI (You Ain't Gonna Need It)
4️⃣ SLAP (Single Level of Abstraction Principle)
5️⃣ SOLID
6️⃣ Law of Demeter
7️⃣ Law of Conservation of Complexity

🎧 Слушать

#подкасты

Отличная серия видео о паттернах и практиках в программировании от Авито Тех

https://www.youtube.com/watch?v=149Hdpqx3Gc&list=PLknJ4Vr6efQHvhvlGcBSD4KHa4ekAn0DS

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/

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