Docker в каждый дом

Стрим FastAPI+Docker породил бурное обсуждение, а нужен ли докер в таком небольшом проекте. Наш ответ — обязательно! В современном мире разработки docker является такой же неотъемлемой частью разработки, как и git. Есть некоторые области без докера, например, разработка GUI, операционных систем или микроконтроллеров. Но весь backend, frontend и data science без докера вообще не живут. Давайте посмотрим, какие прямые выгоды даёт докер:

1. Всегда понятно, как запустить код. Dockerfile является однозначной инструкцией по сборке проекта. Bus-factor не мешает жить.

2. Легко включать новых людей в разработку. Инструкция в ридми сводится к docker build & docker run, что понятно даже junior-разработчикам.

3. Деплой можно производить где угодно. В пару команд можно запуститься на компе разработчика, на test или prod сервере, у заказчика на ноутбуке – и везде всё будет одинаково, нужен только сам Docker.

4. Проект одинаково себя ведёт везде. Это упрощает воспроизведение проблемы и сокращает время на багфикс.

5. Нет проблем с конфликтом зависимостей-библиотек. Вы можете на одной машине запустить проекты с условным django 3 и django 4, они никак друг другу не помешают.

6. Легко поднимать зависимости-компоненты. Для любой базы данных берётся готовый докер-образ, меняется конфиг и в одну команду запускается. С выходом на docker compose можно одной командой поднимать сборную солянку из backend, frontend, базы данных, nginx и Let's Encrypt.

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

8. Понятные внешние эффекты проекта. В команде docker run указаны проброшенные в контейнер каталоги и порты. Всё остальное изолированно.

В общем, со всех сторон одна польза. Минусы? Требуется изучить новый инструмент и best practices. Кажется, на этом всё. Даже дополнительных накладных расходов на виртуализацию нет. И помните – если docker вам мешает, скорее всего, вы что-то делаете неправильно.

Для запуска нескольких связанных контейнеров пользуйтесь compose, гайд тут. Если ещё нужно управлять множеством серверов, то посмотрите на kubernetes.

#skills #sudo #devfm

Задача на собеседовании — проектируем динамическую фильтрацию

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

При поиске товаров на любой торговой площадке есть разухабистые возможности фильтрации товаров. Ваша задача — спроектировать функционал фильтрации результата поиска товаров.

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

После уточнения задачи получаем следующие вводные:
— имеется клиент-серверное приложение интернет-магазина с возможностью поиска товаров

— количество записей в результате поиска может доходить до 1кк

— к полученным в результате поиска товарам можно применять множественные фильтры, у каждого фильтра есть набор значений

— у разных категорий товаров разный набор фильтров

— после применения конкретного фильтра появляется новая выборка и для нее также должны отображаться только актуальные фильтры
Рассмотрим пример. Для телефонов должны быть фильтры "производитель" и "операционная система". После применения фильтра "производитель: Apple" в фильтрах ОС уже не может быть значения Android.

— для каждого значения фильтра необходимо отображать количество подходящих товаров. После выбора одного фильтра все счетчики должны пересчитываться.
Было "производитель": "Apple: 10", "Xiaomi: 20", "Встроенная память": "128 Гб: 10", “256 Гб: 20". Выбрали "128 Гб", после применения станет, например, "производитель": "Apple: 7", "Xiaomi: 19". То есть 3 модели Apple и 1 модель Xiaomi не попали под выбранный фильтр.

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

Как на настоящем собеседовании, уточняющие вопросы можно задать в комментариях. Наше решение задачи в 15:00 понедельника.
#devfm #systemdesign #резюме

DevFM подкаст 3: Роли в ИТ-проекте (youtube / podster / yandex)

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

Подкаст 2. Кто такой тимлид тимлидов
Подкаст 1. Ретроспектива силами команды разработки
#devfm #podcast #teamwork

Наш бесплатный курс "Командная строка для разработчиков"

Мы много лет готовим python-разработчиков. Подготовку начинаем с базовых знаний Linux, где прививаем желание и умение работать в терминале. Вдохновляясь курсом "Поколения Python" на степике, сделали бесплатный курс Командная строка для разработчиков, посвящённый терминалу в Linux. Начинающим разработчикам поможем преодолеть неловкость перед текстовым терминалом, опытным разработчикам покажем неочевидные и полезные в работе фишки для увеличения продуктивности.

Уроки курса:
— Команды и работа с файловой системой из терминала
— Модифицируем файловую систему
— Управляем сотнями файлов и пишем первый скрипт
— Знакомимся с текстовыми редакторами nano, mcedit, gedit, vim
— Разбираемся с процессами, jobs, fg, bg, ps, grep и конвейером
— Настраиваем терминал "под себя"
— Разграничение прав доступа и работа с учётными записями

#devfm

Простой приём: Как ускорить принятие решений в команде

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

В этом случае может помочь простой приём — попробуйте предложить радикальное, обоим сторонам неудобное решение.

Приведу пример:
Мы недавно стартовали проект. В качестве базы использовали Postgres. Но так получилось, что новые требования не укладывались в текущую модель данных, обсуждали трейдофы, на которые нужно идти. Время поджимало, обсуждение затянулось на час. Конечно, если обсуждение длится час — его пора заканчивать.

И в один момент я абсолютно серьёзно предложил использовать нереляционную базу. Также серьёзно обосновал своё предложение, почему это может быть хорошим вариантом. И тут случилось чудо – уже через минуту инженеры дружно доказывали мне, что это плохая идея, а заодно быстро пришли к устраивающему всех решению.

В итоге решение найдено, хотя в глазах ребят я предлагаю очень странные идеи.

#teamwork #devfm

В продолжение поста про правила коммуникации от 37signals

Пример из практики.

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

И это катастрофа. По факту — частная договоренность, которую никто больше не видел, без фиксации в соответствующих артефактах.

Но это сейчас я рассказываю так всё коротенько. Когда через некоторое время словили проблему, команде пришлось разбираться, кто на ком стоял. В итоге вывели два простых правила:
— Никаких обсуждений в личке. Все вопросы в рабочем мессенджере, в тредах. Там можно публично обсудить проблему, привлечь других участников команды для принятия решения.
— Не начинаем работу без фиксации. Решения должны быть отражены в системных требованиях. Эти артефакты — основа, которую используют все: разработчики, тестировщики и аналитики.

Но самое интересное в другом. Эти правила уже были в команде, но инцидент показал, что они плохо зафиксированы или донесены до новых сотрудников.

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

#devfm #teamwork

Как я провожу синки с тимлидами

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

Формат
Обычно, такие встречи проходят раз в неделю. Цель – синхронизация по текущим задачам, проблемам и приоритетам.
Каждый синк – отдельная повторяющаяся приватная таска в таск трекере (как я веду задачи писал тут), либо приватная страничка в вики (в нашем случае конфлюенсе), где фиксируется повестка. Важно, что повестку наполняют оба: руководитель и подчиненный.

Структура
Повестка состоит из трёх частей:
1️⃣ Обязательная часть
Фиксированный список тем, которые обсуждаются на каждой встрече. Этот раздел редко меняется.
Как правило это:
– Посмотреть action points с предыдущего синка
– Общий статус по задачам в работе
Для разных лидов обязательная часть может отличаться. Например, с некоторыми лидами у нас есть пункт по тайм менеджменту, потому что с этим часто бывают вопросы.

2️⃣ Опциональная часть
Эта такой живой раздел. Сюда каждый из участников записывает темы/вопросы, накапливающиеся в течение недели. Темы могут быть самыми разными: какой формат перфоманс ревью в этом полугодии, обсудить новую идею по изменению шаблонного сервиса, внедрение новых метрик и т.д.

3️⃣ Action points
Самый важный раздел. Здесь фиксируем договоренности с синка с указанием дедлайнов и ответственных.

Соответственно, такой скелет повестки с пояснениями по каждому разделу создается для каждой встречи и наполняется в течение недели.

Почему именно так?
Кому-то может показаться, что такой формат слишком бюрократичен. И в целом, когда у тебя пара подчиненных, действительно можно держать многое в голове, но когда их становится больше, то подобный формат мне дает:
✅ прозрачное отслеживание всех вопросов и договоренностей
✅ возможность накидывать темы заранее, не теряя их
✅ отсутствие стихийных созвонов, когда появляется какой-то вопрос. Всегда есть понятное место, куда его можно припарковать
✅ наличие повестки заранее, что позволяет лучше подготовиться к встрече
✅ лучше работает на асинхронное взаимодействие – если какая-то тема потеряла актуальность за неделю, можно просто её удалить, не тратя время на обсуждение

О применении ТГ для асинхронной работы была отдельная статья.

#teamwork #devfm

Оперативный постмит

Качественная встреча всегда завершается постмитом. Я обычно тезисно фиксирую ключевые моменты в своих заметках по ходу обсуждения. В конце озвучиваю их вслух для подтверждения, затем немного шлифую текст и отправляю участникам в мессенджер.

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

Это оказалось супер удобно:
– Сразу видно, что записывается, а участники могут поправить, уточнить, добавить
– Все сразу понимают, кто на ком стоял, кто за что отвечает
– Не нужно тратить время после встречи и что-то дооформлять
– Шаблон постмита позволяет ускорить процесс ещё больше

#devfm

Как проводить встречи эффективно

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

Подготовка
– Избегай звонков без необходимости – большинство вопросов решаются в чате
– Не дергай “на минутку” – если прод не упал, значит не срочно
– Анонсируй: кто, когда, зачем. Иногда достаточно треда в чате
– Проверяй доступность участников через календарь
– Ограничивай время – 30 минут обычно хватает, 1 час — максимум
– Готовь повестку заранее: тема, пункты обсуждения, цель встречи, уважай чужое время
– Рассылай материалы и документы до встречи
– Предупреждай об отмене или задержке как можно раньше
– Опаздываешь? Не опаздывай 🙂

Старт встречи
– Начинай вовремя – без «ждём ещё кого-то»
– Проверь комнату ожидания и список участников
– Напомни повестку – это фокусирует команду

Фасилитация
– Держись повестки и возвращай к цели встречи
– Дай слово молчунам, притормози болтунов.
– Подводи итоги каждые 10–15 минут: «Итак, договорились, что…»
– Следи за чатом и поднятыми руками
– Делись экраном, глаза – тоже канал восприятия
– Включай камеру по возможности
– Не перебивай – сначала дослушай, потом задавай вопросы.
– Паркуй спорные темы после трёх заходов
– Уважай выделенный слот – если нужно больше времени, спроси
– Веди пост-мит в реальном времени

После встречи
– Напиши постмит, опубликуй до конца дня, тегнув участников

#devfm

Еще один способ организовать рабочие чатики

Я пробовал организовывать рабочие чатики самыми разными способами: иногда просто в отдельную папочку, иногда – в папки по проектам.

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

И некоторое время назад я придумал (вряд ли я, но в моем мире – именно я), как иначе организовать рабочие чатики – по срочности.

Сделал 4 папки:
🔹Now – то, на что мне нужно реагировать незамедлительно. Таких чатов всего 1–2, но стремиться нужно к нулю
🔹Hourly – то, на что нужно посмотреть в течение часа
🔹Daily – пробежаться раз в день, узнать, что происходило
🔹Later – оно же «никогда», оно же «когда-нибудь». Это чаты, где просто нужно присутствовать :)

В результате стало гораздо легче ориентироваться и не отвлекаться на лишний шум.

#devfm