JuniorPython Developer > Основы Python > Документация
Короткий ответ Документация помогает другим разработчикам (и вам через полгода) быстро понять назначение, входные данные и ограничения кода или эндпоинта без чтения всей реализации. Как это работает подробнее Для функций и модулей документация обычно описывает назначение, параметры, возвращаемое значение и возможные исключения. Для API — это формат запроса и ответа, коды ошибок, обязательность полей и примеры вызовов. Такая документация выступает контрактом между частями системы или между командами, снижая зависимость от того, что автор кода помнит детали и доступен для вопросов. Пример кода Что использовать на практике Практика. Докстроки и комментарии стоит писать там, где поведение не очевидно из названия и типов, а не дублировать код словами. Для REST API удобно поддерживать OpenAPI/Swagger-спецификацию — она же может использоваться для автогенерации клиентов, валидации запросов и построения интерактивной песочницы для других команд. Подводные камни Риски. Частая ошибка — документировать «что делает код»
apidocstring
JuniorData Analyst > Метрики и эксперименты > A/B-тесты Короткий ответ Случайная рандомизация делает группы статистически сопоставимыми по всем характеристикам — и видимым, и невидимым, — поэтому разница в метриках объясняется только тестируемым изменением. Деление по неслучайному признаку вносит систематическое смещение (selection bias). Как это работает подробнее каждый пользователь попадает в группу с фиксированной вероятностью независимо от своих свойств; при достаточном объёме выборки группы в среднем становятся похожи по возрасту аккаунта, активности, платформе и прочим признакам. Пример плохого дизайна: пользователи, зарегистрированные после 1 марта, автоматически попадают в группу B (новая версия), а до — в группу A. Проверка: сравнить распределение «возраста» аккаунта в группах — если оно радикально отличается, рандомизация нарушена и SQL-запрос на сравнение created_at по группам покажет явный разрыв дат. Что использовать на практике рандомизацию обычно делают по хэшу user_id с солью эксперимента, чтобы один пользователь стабильно попадал в одну группу на
kogortyrandomizatsiya
JuniorSMM Manager > Общее > Публикация и кампании Короткий ответ История версий позволяет видеть, какие правки вносились в пост на каждом этапе, кто их внёс и когда, что помогает восстановить предыдущий вариант при ошибке и разобраться, на каком этапе согласования произошла проблема. Как это работает подробнее инструменты планирования и документы (Google Docs, Notion, специализированные планировщики) сохраняют снимки текста на разных этапах редактирования, включая автора правки и время изменения; это создаёт аудиторский след для всей команды. Что использовать на практике На практике. история версий особенно важна при командной работе с несколькими согласующими — она позволяет быстро откатиться к одобренному варианту, если в финальную версию случайно попали несогласованные правки; стоит регулярно проверять, что инструмент действительно сохраняет историю, а не только последнюю версию. Пример. В Notion-документе с черновиком поста видно: версия 1 — исходный текст автора, версия 2 — правки редактора, версия 3 — правки бренд-менеджера с добавленным слоганом. Пров
publishing-campaignssocial-media-marketing
MiddleData Analyst > SQL и данные > Статистика и теория вероятностей Короткий ответ При проверке нескольких гипотез одновременно вероятность получить хотя бы один ложноположительный результат растёт с числом тестов; поправка Бонферрони ужесточает порог значимости (альфа/количество тестов), а метод Бенджамини-Хохберга контролирует долю ложных открытий (FDR) менее консервативно, сохраняя больше мощности при множестве гипотез. Как это работает подробнее Бонферрони делит альфа на число сравнений m, контролируя вероятность хотя бы одной ложной находки (FWER) — это строгий, консервативный подход, особенно при большом m. Benjamini-Hochberg сортирует p-value по возрастанию и сравнивает каждое с порогом (i/m)×альфа, контролируя ожидаемую долю ложных находок среди всех отвергнутых гипотез, что обычно даёт больше статистической мощности при множестве тестов. Пример кода Что использовать на практике На практике. поправки нужны, когда одновременно сравнивается много метрик, много сегментов или много вариантов в одном эксперименте (multi-armed test). Выбор метода зависит от цены ошибки: есл
benjamini-hochbergbonferroni
JuniorSMM Manager > Общее > Площадки и основы SMM Короткий ответ Закреплённый пост остаётся первым в списке публикаций независимо от времени размещения новых постов, поэтому его используют для самой важной и долгоживущей информации — приветствия, навигации по сообществу, текущей акции или правил, — чтобы новый посетитель сразу видел её, не прокручивая ленту вниз. Как это работает подробнее закрепление — это настройка конкретной публикации, которая технически «поднимает» её визуально наверх страницы или канала, не влияя на ленту подписчиков и не являясь новой публикацией с точки зрения алгоритма. Что использовать на практике Рекомендация. закреплённый пост стоит периодически обновлять (например, менять акцию или навигацию), иначе он быстро теряет актуальность и может вводить новых посетителей в заблуждение устаревшей информацией. Подводные камни Риск. держать закреплённым пост с прошедшей акцией месяцами; закреплять рекламный пост без полезной навигационной информации, из-за чего новый посетитель не понимает, что это за сообщество и чем оно полезно.
platform-strategyranking-algorithms
SeniorData Analyst > SQL и данные > Статистика и теория вероятностей Короткий ответ Долгосрочный holdout — группа пользователей, намеренно не получающая накопленные со временем изменения продукта, чтобы можно было измерить совокупный долгосрочный эффект множества последовательных изменений, который невозможно увидеть в коротких отдельных A/B-тестах; размер и длительность holdout — всегда компромисс между качеством измерения и упущенной выгодой для пользователей в нём. Как это работает подробнее отдельные A/B-тесты измеряют эффект одного изменения на коротком горизонте, но не улавливают совокупный эффект десятков последовательных улучшений, их взаимодействие между собой, и отложенные эффекты на удержание и лояльность, которые проявляются только через месяцы; holdout-группа, не получающая изменений, даёт точку сравнения для такого совокупного эффекта. Sanity check: ежемесячно сравнивать guardrail-метрики holdout-группы с остальной базой — если расхождение становится слишком большим и явно вредит пользователям раньше запланированного срока, предусмотренный план должен позволять д
experimentationholdout-group
JuniorPython Developer > Основы Python > Git и Pull Request Короткий ответ Атомарный коммит содержит одно логически законченное изменение, а понятное сообщение коммита объясняет, что и зачем изменено — это упрощает ревью, откат и поиск причины бага в истории. Как это работает подробнее Коммит — это единица истории изменений: если в одном коммите смешаны рефакторинг, новая фича и исправление опечатки, откатить или понять только одну часть изменений становится сложно. Атомарность означает, что каждый коммит можно откатить независимо, не сломав остальное, а значит историю изменений можно безопасно использовать как инструмент диагностики, а не только как архив. Пример кода Что использовать на практике Практика. Сообщение коммита принято писать в повелительном наклонении и кратко: что изменилось и, при необходимости, почему (не «как», это видно из diff). При поиске бага через git bisect или git blame понятные сообщения экономят часы — особенно когда баг возвращается спустя месяцы, а автор изменения уже не помнит деталей. В крупных командах также принято ссылаться в сообщен
commitsgit
MiddleDevOps Engineer > Контейнеры и доставка > Мониторинг, логирование и observability Короткий ответ Recording rule — это заранее вычисляемое и сохраняемое в TSDB PromQL-выражение (новая метрика), которое Prometheus пересчитывает по расписанию (evaluation_interval), а не при каждом открытии дашборда; это ускоряет часто используемые тяжёлые запросы (с агрегацией по множеству рядов) и делает алерты более предсказуемыми по времени выполнения. Как это работает подробнее без recording rule каждое открытие дашборда с тяжёлым запросом (например, histogram_quantile по агрегации сотен рядов за несколько часов) заставляет Prometheus пересчитывать всё "на лету" из raw-данных. Recording rule выполняет такой расчёт один раз за evaluation_interval (например, раз в минуту) и сохраняет результат как новую простую метрику, которую дашборд или алерт читает почти мгновенно, как обычный временной ряд. Пример кода Что использовать на практике Практика. recording rules особенно полезны, когда одно и то же тяжёлое выражение используется в нескольких местах (дашборд + алерт на основе того же SLI), чтобы не пересчитыв
alertingdashboards
MiddleDevOps Engineer > Контейнеры и доставка > Kubernetes и оркестрация Короткий ответ ResourceQuota ограничивает суммарное потребление ресурсов (CPU, память, число объектов определённого типа) всем namespace целиком, а LimitRange задаёт ограничения и значения по умолчанию для отдельных Pod/контейнеров внутри namespace (минимум, максимум, значения requests/limits по умолчанию, если они не указаны явно) — это защита от разных проблем: ResourceQuota от исчерпания ресурсов кластера одной командой, LimitRange от подов без явных requests/limits. Как это работает подробнее если в namespace установлена ResourceQuota с лимитом на суммарные requests.cpu, то любое создание Pod, которое привело бы к превышению этой суммы, будет отклонено API сервером ещё на этапе создания объекта, независимо от реальной свободной ёмкости кластера. LimitRange, в свою очередь, применяется к каждому отдельному Pod/контейнеру при его создании: если в манифесте нет resources, LimitRange может подставить значение по умолчанию, а также заблокировать создание объекта, если указанные значения выходят за допустимый д
kuberneteslimit-range
MiddleDevOps Engineer > Контейнеры и доставка > Мониторинг, логирование и observability Короткий ответ Standalone Prometheus хранит данные локально на одном диске с ограниченным retention и без встроенной высокой доступности или глобального view между несколькими Prometheus-инстансами; такие системы добавляют долгосрочное хранение (через объектное хранилище S3/GCS), дедупликацию данных между репликами и единый запрос по множеству Prometheus сразу. Как это работает подробнее каждый Prometheus продолжает делать scrape локально, но дополнительно отправляет данные через remote_write в удалённое хранилище (Mimir, VictoriaMetrics) или использует Thanos Sidecar, который выгружает локальные TSDB-блоки в объектное хранилище. Дальше отдельный компонент (Thanos Querier, Mimir Query Frontend) объединяет данные из множества источников и отдаёт их в Grafana как единую точку запроса, включая исторические данные за месяцы/годы. Пример кода Что использовать на практике Практика. такие решения нужны, когда требуется retention дольше, чем разумно держать на локальном диске одного Prometheus, либо нужен единый дашб
long-term-storagemonitoring