Программирование *

Дели код на области (scope) - второй принцип. Полный список принципов здесь

Получил задачу, нужно подумать о области реализации. Иерархия областей такая: бизнес домен -> поддомен -> ... -> поддомен -> модуль(пакет) -> функция.

Чем глубже задача в иерархии декомпозиции, тем глубже область реализации в иерархии областей/слоев. Если ты разработчик, твоя зона: поддомен -> модуль(пакет) -> функция. Может быть так:

• эпик содержит общее описание, покрывает несколько поддоменов, про модули тут ничего не понятно

• история(сторя) в эпике описывает конкретный вариант использования, покрывает модуль поддомена. Если история покрывает больше одного модуля или поддомена, нужно подумать над декомпозицией.

• техническая задача из истории - слой вниутри модуля на фронте или модуль на бэке.

Сore domain и всякие другие domain - это лирика-теория для аналитиков. Для разработчика это лишний информационных шум.

Здесь нужно быть внимательным, потому что:

1. границы субъективны, зависят от понимания смысла, целей, отвественности компонента,

2. для бэка и фронта границы областей проходят по разному в рамках одной системы:

   • для бэка поддомен->модуль совпадает с сервис->модуль/пакет или микросервис. Сервисы типа BFF и GraphQL - исключения, их можно считать частью глобального слоя контроллеров;

   • для фронта в слое контроллеров UI компоненты имеют свои границы, отличные от границ поддомен->модуль, но в остальных слоях совпадают.

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

Допустим, я разработчик бэка. Задача: сделать фасетный и текстовый поиск товаров. Есть сторя с описанием контракта. Тогда моя зона: поддомен -> модуль(пакет) -> функция модуля. Мысли такие:

1. Поддомен уже понятен - обсудил в процессе декомпозиции эпика с аналитиком. Это будет Каталог. Сделаю его отдельным сервисом.

2. Модуль примерно понятен: мне нужно сделать фасетный поиск. Скорее всего кроме поиска Каталог-сервис будет выдавать категории, продукты по отдельности и еще что-то. Фасетный поиск - модуль.

3. Фасетный поиск должен возвращать значения для фасетов и результаты. Кажется, у модуля 2 функции. Может стоит сделать 2 модуля, или это будет 2 интерфейса внутри одного модуля? Решу, когда буду думать над логикой, там станет понятна связанность этих функций. Нужно будет обсудить с коллегами.

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

Область и ограниченный контекст - разные вещи. Поэтому мы здесь его не обсуждаем.

Деление на слои и области выглядит как "решетка":

Весь код должен быть раскидан по ячейкам. Рано или поздно у вас появится общий для нескольких модулей код. Он хочет занять несколько ячеек по горизонтали. Скорее всего он выполняет общую служебную функцию внутри слоя. Здесь можно поступить по-разному: вынести в отдельный пакет, модуль с одним слоем, как договоритесь с коллегами.

Как физически организовать решетку и общие пакеты разберемся дальше.

О компиляторах.

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

Ядро Linux по этому определению может называться очень большим проектом. Под него специально затачивается gcc.

У IBM есть даже специальный язык PL/S, используемый специально для написания операционной системы. Компилятор PL/S не доступен вне IBM.

О языках программирования.

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

Исключением из этого правила является C++, который, несмотря на довольно почтенный возраст, до сих пор представляет собой полигон для игры ума авторов.

С другой стороны, стандарт Scheme принимают голосованием программистов по спорным вопросам.

Чем дольше живу, тем больше ценю Лисп и Фортран.

Магические квадраты с произведением

 О магических квадратах известно, наверное, всё. А возможны ли магические квадраты, в которых равны не суммы значений в строках, столбцах и на диагоналях, а их произведения? Оказывается – возможны. В дальнейшем буду называть такие квадраты «магическими квадратами с произведением» (сокращённо – МКП).

Интересно, что, как и «обычных» магических квадратов, возможно бесчисленное множество вариантов МКП. В общем случае для трёх чисел a, b и n МКП размером 3 × 3 имеют вид:

При этом a ≠ b, a ≠ 1, b ≠ 1, a ≠ b², b ≠ a²,

Интересно, что любой МКП размером 3 × 3 может быть основой для формирования бóльших МКП. Одно из возможных решений заключается в том, чтобы поместить такой  квадрат в центр квадрата 5 × 5 и потом подобрать такие остальные числа, чтобы они соответствовали свойствам МКП. Это означает, что МКП являются также так называемыми «рамочными магическими квадратами» – магическими квадратами, которые сохраняют свое магическое свойство, если в них отбросить окаймляющие «полосы» в две клетки.

После комментариев  @miksoft я удалю сей свой пост

Преимущества реализации цикла FOR в Modula-3

Цикл FOR в Modula-3 был значительно улучшен по сравнению с его аналогами в Pascal и Modula-2. Эти изменения сделали его более безопасным, гибким и удобным для разработки. Вот ключевые преимущества:

1. Гибкость диапазона и шага

В Modula-3 цикл FOR позволяет задавать произвольные начальное, конечное значения и шаг, а не только ±1, как в Pascal.
Пример:

FOR i := 10 TO 1 BY -2 DO
  ...  // обратный счёт с шагом -2
END;

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

2. Локальная область видимости переменной цикла

Переменная цикла объявляется непосредственно в конструкции FOR, ограничивая её область видимости телом цикла. Это предотвращает случайные конфликты имён и уменьшает риск ошибок.
Пример:

FOR i := 1 TO 10 DO
  ...  // переменная i существует только здесь
END;

3. Защита от модификации переменной цикла

Переменная цикла внутри тела цикла доступна только для чтения. Её нельзя изменить, что исключает случайные ошибки, характерные для Pascal и Modula-2.

FOR i := 1 TO 5 DO
  i := 10;  // Ошибка компиляции: присваивание запрещено
END;

4. Поддержка различных типов данных

Цикл FOR в Modula-3 работает не только с целыми числами, но и с другими типами, такими как:

• Перечисляемые типы (ENUM).

• Диапазонные типы (например, поддиапазоны [1..10]).

• Даже символы (CHAR), если это имеет смысл.

Пример с перечислением:

TYPE Color = {Red, Green, Blue};
FOR c := FIRST(Color) TO LAST(Color) DO
  ...  // итерация по всем элементам перечисления
END;

5. Безопасность и контроль типов

Modula-3 строго проверяет границы цикла на этапе компиляции. Если начальное значение превышает конечное при положительном шаге (или наоборот), цикл не выполняется, что предотвращает бесконечные циклы или ошибки времени выполнения.

6. Улучшенная читаемость

Синтаксис FOR в Modula-3 более выразителен, особенно при работе с массивами или списками. Например:

FOR i := 0 TO LAST(a) DO
  a[i] := ...  // явный обход массива
END;

Это делает код понятнее, чем использование циклов WHILE.

Сравнение с другими языками

• Pascal/Modula-2:

  • Ограничен шагом ±1.

  • Переменная цикла может быть модифицирована внутри тела.

  • Неопределённое поведение после завершения цикла.

• Ada:
  Modula-3 позаимствовал многие принципы безопасности из Ada (например, защита переменной цикла), но сохранил простоту синтаксиса.

Итог

Цикл FOR в Modula-3 сочетает гибкость, безопасность и выразительность. Его реализация отражает общие принципы языка: строгий контроль типов, минимизацию ошибок и удобство для разработчика. Это делает Modula-3 предпочтительным выбором для задач, где важна надёжность и читаемость кода.

3 ключевые метрики, которые спасут микросервисный проект

Современные системы — это сложные экосистемы, где каждая ошибка может стоить бизнесу денег и репутации. Рассказываем, какие метрики нельзя игнорировать, чтобы не пропустить критичные сбои.

Инфраструктурные метрики

Базовые показатели вроде CPU и RAM уже не спасают. Для микросервисов важнее:

Статус подов в Kubernetes:

• Количество рестартов.

• Фейлы readiness/liveness проб.

• Используйте метрику kube_pod_status_ready в Prometheus, чтобы находить «битые» поды.

Трассировка запросов: время выполнения каждого этапа через Jaeger.

Пример: Если поды перезапускаются чаще 5 раз в час — это сигнал к немедленной проверке.

Бизнес-метрики

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

• Конверсию платежей (например, от корзины к оплате).

• Время обработки заказов.

Код для .NET-сервиса:

using App.Metrics;

public class PaymentService {
    private readonly IMetrics _metrics;
    public PaymentService(IMetrics metrics) => _metrics = metrics;
    
    public void ProcessPayment() {
        try {
            // Логика платежа...
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);
        } 
        catch {
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);
        }
    }
}

Эти метрики интегрируются в Grafana, чтобы вы видели, как каждая транзакция влияет на бизнес.

Пользовательский опыт

Даже 1 секунда задержки может увеличить отток пользователей на 7%. Контролируйте:

• Время отклика API (p95, p99).

• Частоту ошибок 5xx/4xx.

• Структурированные логи с контекстом:

{
  "timestamp": "2023-10-05T12:34:56Z",
  "level": "ERROR",
  "userId": "a1b2c3",
  "operation": "process_payment",
  "message": "Failed to charge card: insufficient funds"
}

Теги вроде userId помогают быстро найти все связанные с ошибкой события.

Text smell

Народ обленился. Раньше было понятие «code smell» как признак плохого кода – дублирование кода, длинные методы, сложные условия, отсутствие комментариев, бестолковые комментарии, слишком много комментариев.

Сейчас можно говорить о «text smell» – генерация бестолкового, бессвязного текста с помощью LLM. Если в тексте есть и «буллет поинтов»

«Буллет поинты» и 😊 😃 😍 🤔 😭 😡 😎 🙄 🤷‍♂️ 🙃 🙈 🙌 🧠 💪 в тексте, это верный признак того, что портянка была сгенерированна с помощью AI. Бесполезная трата машинных циклов и кредитов. Если не хочется писать самому, то лучше ничего писать.

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

Cline — это AI-ассистент, который превращает твой VS Code в умную среду для разработки. Он не просто подсказывает код, а реально помогает его писать: исправляет ошибки, запускает команды, тестирует изменения и даже сам предлагает решения на основе твоего проекта.

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

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

OpenRouter — это как единый шлюз ко всем популярным AI-моделям. Вместо того чтобы прыгать между разными API (OpenAI, Anthropic, Google и т. д.), можно подключиться один раз и получать доступ сразу ко всем — включая свежие и нишевые модели.

Работает просто: выбираешь модель в настройках, указываешь API-ключ от OpenRouter — и всё. Система сама считает токены, показывает стоимость запросов и даже подсказывает, какая модель лучше подойдет под твой бюджет или задачу.

Особенно удобно для разработчиков: если твой проект использует AI (как тот же Cline), OpenRouter избавляет от головной боли с роутингом запросов и обновлениями API. Плюс можно тестировать разные модели без переподключения — просто сменил название в конфиге и поехал дальше.

OpenRouter принимает крипту.

Порождающие паттерны: какие они и в чем их назначение?

В новой серии третьего сезона курса «Паттерны и практики написания кода» перейдём от теории к практике и погрузимся в мир прикладных паттернов. В предыдущем видео мы узнали, что паттерны делятся на три группы: сегодня вместе с бэкенд-инженером Юрой Афанасьевым начнём рассматривать первую из них — порождающие паттерны. 

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

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

schemaspy

SchemaSpy поддерживает разные БД. Для PGSQL необходимо скачать драйвер JDBC.

PG JDBC driver

java -jar schemaspy-6.2.4.jar -t pgsql -host localhost -db yourdatabase -u user -p password -o output_dir  -dp ./postgresql-42.7.5.jar

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

Например проект, который станет альтернативой популярным платформам вроде hh.ru и GetMatch. В отличие от них, он изначально создается как API-first решение, где весь функционал строится вокруг API. Платформа не просто предоставляет интерфейс для пользователей, но и полностью готова к интеграции с другими системами, включая искусственный интеллект. Такой подход позволяет AI напрямую взаимодействовать с базой данных вакансий, анализировать резюме, предлагать персонализированные рекомендации и автоматизировать процесс подбора кандидатов.

5 книг, чтобы прокачать скиллы в SRE 📚

Со всеми, кто развивает инженерные практики, подборкой делится Антон Быстров — SRE-инженер Cloud․ru.

📖 SRE Table of Contents OT Google. Это своего рода «путеводитель» по принципам Site Reliability Engineering (SRE). Он объясняет, почему определенные методы и процессы должны использоваться в разработке и эксплуатации систем. Книги служат отличной базой для понимания философии и практических аспектов SRE, включая мониторинг, автоматизацию, управление инцидентами и многое другое.

📖 Проект «Феникс». Книга, которая рассказывает историю трансформации крупной компании через призму внедрения методов DevOps. Автор романа Брайан Дэрроу показывает, как команда разработчиков и операционных сотрудников объединяется для достижения общей цели — создания и запуска нового продукта. Хотя «Проект „Феникс“» — это прежде всего художественное произведение, оно содержит множество реальных примеров и идей, которые будут полезны как разработчикам, так и менеджерам, стремящимся внедрить современные подходы к управлению проектами и процессами.

📖 Грокаем алгоритмы. Иллюстрированное пособие для программистов и любопытствующих — Бхаргава А. Алгоритмы играют ключевую роль в работе любой системы, и эта книга поможет вам глубже понять их принципы. Она проиллюстрирована и написана понятным языком, что делает её идеальной даже для начинающих.

📖 Запускаем Prometheus. Мониторинг инфраструктуры и приложений: Пивотто, Бразил. Одна из базовых книг по мониторингу. Она подробно описывает, как использовать Prometheus для сбора и анализа метрик, что является неотъемлемой частью работы SRE. Понимание экосистемы Prometheus значительно упростит вашу повседневную работу.

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

Уже читали книги из списка? А какие готовы порекомендовать от себя? Делитесь в комментариях 👇

Дели код на слои - первый принцип. Полный список принципов здесь

Я еще не знаю задачу, но уже знаю, что в коде будет 3 слоя: приложение, инфраструктура, контроллеры. Отдельно конфигурация.

Этого достаточно, ведь у меня даже нет задачи. Я начну думать о моделях, адаптерах, объекта‑значениях, когда приступлю обдумыванию бизнес логики и реализации.

Слой приложения «главный». Он устанавливает правила и требования к интерфейсам других слоев. Он никому ничего не должен. Он не знает, как устроены другие слои, и что внутри, потому что он главный. Слой приложения не может требовать от других слоев навыков работы с закрытыми данными. Он не может передать объект с приватными свойствами в другой слой и хотеть, чтобы эти свойства были обработаны.

На фронте слой содержит код, который хранит и управляет состоянием независимо от отображения: сохраняет состояние между переходами по страницам, дает доступ к состоянию из разных шаблонов и т. п.

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

— как модель, которые хранят состояние пока запрос обрабатывается;

— сервис без состояния

— функция с валидации целостности

Контроллеры — это все, что касается ввода и вывода.

Этот слой обязан знать, что нужно слою приложения, обязан это предоставить в нужном формате. Он не может ничего требовать от слоя приложения, обязан работать с тем, что отдал слой приложения.

На фронте в этот слой попадает всё, что касается взаимодействия с пользователем и обработки событий:

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

— обработчики событий

— обработчики роутов, потому что роутинг — это интерфейс ввода данных.

— слушатели сокет соединений

На бэке это код, который принимает входящие запросы и отдает ответ, фоновые контроллеры:

— контроллеры gRPC, HTTP,

— слушатели очередей,

— конструкторы ответа, мапперы данных в нужный формат и т. п.

— описание протоколов.

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

Инфраструктура

— обязана работать с тем, что отдает слой приложения

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

Здесь лежат:

— клиенты к хранилищам, другим сервисам, кэшам, очередям и т. п.

— конструкторы запросов к БД, очередям или другим сервисам

— мапперы данных слоя приложения в нужный формат и обратно

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

Это может быть конфигурация di‑контейнера, место ручного создания компонен. Конфигурация может присутствовать как дополнительные нотации в UI компонентах. Фреймворки и языки имеют разные методы конфигурирования, поэтому конфигурация не является слоем или может быть не явной.

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

На фронте слой контроллеров может часто меняться, контракт с бэком более стабилен — инфраструктура главная.

На бэке формат хранения может измениться после MVP, а контракт описан и стабилен — слой контроллеров главный.

Слои зависят друг от друга. Правила организации кода и внедрения зависимостей будут в отдельном посте.

Хочу зафиксировать принципы проектирования, которыми я пользуюсь ежедневно. В этом посте будет обновляемый список, расшифровка каждого принципа - отдельный пост. Это мой личный опыт. Я не претендую на универсальность.

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

Принципы сформированы на основе практического применения информации из книг:

• Эрик Эванс. Предметно-ориентированное проектирование. Структуризация сложных систем.

• Вон Вернон. Реализация методов предметно-ориентированного проектирования - DDD.

• https://www.infoq.com/minibooks/domain-driven-design-quickly/

• Влад Хононов. Изучаем DDD – предметно-ориентированное проектирование.

• Роберт Мартин. Чистая архитектура.

В оригиналах некоторые вещи трактуются объемно и широко.

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

Погнали:

1. Дели код на слои

2. Дели код на области (scope)

Опубликовали программу infra.conf'25 — конференции про работу с высоконагруженными системами и инфраструктурой

Итоговая программа ежегодной infra.conf'25 объединит доклады про платформенную разработку, применение больших языковых моделей, решения с открытым исходным кодом, обеспечение безопасности, инфраструктуру для машинного обучения и мобильной разработки.

Спикерами infra.conf'25 станут ведущие инженеры и разработчики Яндекса, Купера, MTS Web Services, Positive Technologies, AvitoTech, Sber AI и других компаний. Организаторы мероприятия — команда Yandex Infrastructure, которая создаёт и предоставляет внутреннюю инфраструктуру Яндекса.

Конференцию откроет главный доклад от Андрея Година, руководителя Yandex Infrastructure, и Александра Чубинского, руководителя Yandex Platform Engineering.
Также среди спикеров infra.conf'25:

• Александр Николаичев и Николай Гриценко из Yandex Infrastructure — «Все дороги ведут в Internal Development Platform (IDP)».

• Роза Морозенкова из Купера — «ML‑платформа: зачем она нужна вам, нам и ML‑инженерам».

• Кирилл Сюзев из команды платформы для разработчиков SourceCraft — «Облачный CI/CD — 5-звёздочный отель для особо опасных любимых пользователей».

• Валерий Евдокимов из ecom.tech (ex. Samokat.tech) — «Превозмогая opensource: опыт внедрения OpenTelemetry, Qryn и Coroot для выстраивания системы наблюдаемости».

• Виталий Шишкин из Positive Technologies — «Tetragon: лучшие практики и нюансы разработки Tracing Policy».

• Эдуард Оболенский из Yandex Infrastructure — «Опыт построения инфраструктуры вокруг мобильной разработки».

Также гости мероприятия смогут посетить воркшоп по Surface Mount Device‑пайке — это процесс пайки электронных компонентов поверхностного монтажа к печатным платам.

infra.conf'25 пройдёт 5 июня в Москве в Loft Hall #8. Также доклады можно посмотреть онлайн на сайте конференции. Для участия нужно зарегистрироваться на сайте и получить приглашение.

Новый тайпчекер для Python от авторов ruff и uv, написанный на Rust

Вышло видео про новый тайпчекер и lsp: ty (старое название red-knot) от авторов ruff и uv. Пока по первым впечатлениям – бомба! Не смотря на версию 0.0.0a8 🌚

Из плюсов:

• Быстрый

• На расте

• Куча новых фичей для типов

• Полная спецификация

• Интеграция с ruff и IDEшками

Из минусов:

• Пока есть баги (но их поправят, конечно же)

• Нет плагинов (и скорее всего никогда не будет)

• Софт от молодой и маленькой компании

• Как сделать поддержку ty и mypy вместе? А если использовались ty_extensions?

Обсуждение: а как вам проект? Успели попробовать?

Рэймонд Чен — ветеран компьютерной индустрии, который работает в Microsoft c 1992 года. Рэймонд участвовал в разработке OS/2, Windows 95, DirectX и оболочки Windows, а последние десятилетия отвечает за сохранение обратной совместимости системы. В своём блоге Old New Thing Чен регулярно делится забавными историями из разработки софта, но также показывает действительно полезные примеры.

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

// В целях наглядности вся проверка ошибок опущена
#include <windows.h>

void SetClipboardText(HWND hwnd, PCWSTR text)
{
    OpenClipboard(hwnd);
    EmptyClipboard();
    auto size = sizeof(wchar_t) * (1 + wcslen(text));
    auto clipData = GlobalAlloc(GMEM_MOVEABLE, size);
    auto buffer = (LPWSTR)GlobalLock(clipData);
    strcpy_s(buffer, size, text);
    GlobalUnlock(clipData);
    SetClipboardData(CF_UNICODETEXT, clipData);
    CloseClipboard();
}

// Чтобы они были под рукой, разместим эти строки в истории буфера обмена
static constexpr PCWSTR messages[] = {
    L"314159", // номер бага, который мы хотим исправить
    L"e83c5163316f89bfbde7d9ab23ca2e25604af290", // коммит, к которому привязываем ошибку
    L"Widget polarity was set incorrectly.", // комментарий, который нужно добавить
};

int wmain([[maybe_unused]] int argc,
          [[maybe_unused]] wchar_t* argv[])
{
    auto tempWindow = CreateWindowExW(0, L"static", nullptr, WS_POPUPWINDOW,
            0, 0, 0, 0, nullptr, nullptr, nullptr, nullptr);

    for (auto message : messages)
    {
        SetClipboardText(tempWindow, message);
    }
    DestroyWindow(tempWindow);
    return 0;
}

Код записывает в буфер обмена последовательно три строковые переменные. Однако при запуске утилиты в истории буфера обмена оказывалась лишь одна — последняя. Куда делись две остальные?

Дело в том, что служба истории буфера обмена работает асинхронно через механизм Clipboard Format Listener, существующий с эпохи Windows Vista. В этом механизме через функцию Add­Clipboard­Format­Listener приложение добавляет себя в качестве листенера. После этого никаких дополнительных опросов буфера обмена проводить не нужно — система сама оповестит приложение, если буфер изменился.

При получении уведомления служба истории буфера обновляет собственно историю буфера обмена. Но из-за асинхронности событие может происходить с задержкой. Как объясняет Чен, из-за асинхронной природы обновлений при получении WM_CLIPBOARD­UPDATE от Clipboard Format Listener буфер может успеть обновиться ещё раз.

Как считает Рэймонд, это даже не баг, а фича. Так получается избегать приложений, которые быстро спамили бы в буфер обмена множество изменений. Если даже пользователь не успевает воспользоваться содержимым буфера, то сохранять это для истории смысла нет, указывает Чен.

В другом посте из своего блога Рэймонд объяснил механизмы утилит-просмотрщиков буфера обмена с синхронными обновлениями буфера. Здесь периодически выполняется опрос GetClipboardSequenceNumber. У данного подхода тоже есть проблемы: редкий опрос угрожает привести к пропуску изменения буфера, но слишком частые запросы создадут лишнюю нагрузку на систему.

Рэймонд обещает в следующий раз показать, как исправить код выше.

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

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

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

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

А у меня нет дедлайна. Думаешь тебе повезло? Нет. Это повод задуматься. Скорее всего у источника задачи нет стратегии, целей, долгосрочных планов, ожидания не соответствуют действительности. Он не понимает, что хочет. Задача - это идея, без понимания практического применения. Скорее всего ты в "болоте". Если компания "живая", дедлайн тебя настигнет. А может быть тебя хотят "слить" и это ловушка? Я видел такое, так бывает.          

Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability

Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.

Главные проблемы классического подхода:

1. Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.

2. Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.

3. Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.

Решение — Observability:

Объедините метрики (Prometheus), логи (EFK) и трейсы (Jaeger), чтобы система сама «объясняла» свои сбои.

Пример кода

Отслеживание конверсии платежей в .NET-сервисе:

// Отслеживание конверсии платежей  
using App.Metrics;  
public class PaymentService  
{  
    private readonly IMetrics _metrics;  
    public PaymentService(IMetrics metrics) => _metrics = metrics;  

    public void ProcessPayment()  
    {  
        try  
        {  
            // Логика обработки платежа...  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentSuccessCounter);  
        }  
        catch  
        {  
            _metrics.Measure.Counter.Increment(MetricsRegistry.PaymentFailedCounter);  
        }  
    }  
} 

Код автоматически фиксирует успешные и неудачные платежи. Эти метрики интегрируются в Grafana для анализа бизнес-показателей.

📖 Нужны подробности? Читайте статью на хабре: «Эффективная стратегия мониторинга: ключевые метрики для успешного наблюдения»

ГОСТ Р 56939-2024 – Разработка безопасного программного обеспечения (РБПО)

20 декабря 2024 года введён ГОСТ Р 56939-2024 взамен ГОСТ Р 56939—2016. Хотя уже прошло около полугода, не все про это знают, осознают это или как-то подстраиваются под произошедшие изменения :) А изменения есть, так как новый ГОСТ ориентирован на построение и контроль процессов, обеспечивающих цикл безопасной разработки в компании.

Несколько информационных моментов.

1. Цикл публикаций в моём канале "Бестиарий программирования" на тему РБПО

Я начинаю большой цикл публикаций в Telegram, посвящённый РБПО и ГОСТ Р 56939-2024. Приглашаю подписываться всех, кто хочет постепенно знакомиться с этой темой и разбираться в ней.

2. Вебинары РБПО-направленности

Мы уже провели совместно с другими компаниями два вебинара, связанных с ГОСТ Р 56939-2024:

1. Интеграция статического анализа и DevSecOps: PVS-Studio и AppSec.Hub в действии.

2. Внедрение процессов безопасной разработки. Интеграция PVS-Studio и SGRC SECURITM.

Приглашаем принять участие в следующем совместном с "ИНСЕК" вебинаре "Регулярный статический анализ по ГОСТу" (21 мая 12:00 по Москве), где они презентуют InSeq RBPO.

Приглашаем и другие компании к технологическому и/или информационному сотрудничеству. Напишите нам в поддержку или моему ассистенту.

3. Сертификация ФСТЭК

В последнее время нас спрашивают, подходит ли PVS-Studio для сертификации, и есть ли у нас сертификат ФСТЭК?

Для PVS-Studio нет сертификата ФСТЭК, так как он не нужен (для статических анализаторов процедура сертификации является добровольной).

PVS-Studio может использоваться как инструментальное средство статического анализа кода при построении процессов РБПО по ГОСТ Р 56939-2024.

PVS-Studio успешно применяется испытательными лабораториями, аккредитованными в системах сертификации средств защиты информации ФСТЭК России в рамках работ по сертификационным испытаниям программных продуктов, так как соответствует необходимым критериям (для заказчиков и сертификационных лабораторий мы подготовили информационное письмо):

• PVS-Studio включён в Реестр российского ПО (запись № 9837 от 18.03.2021);

• PVS-Studio удовлетворяет функциональным требованиям к инструментам статического анализа кода, описанным в Методическом документе "Методика выявления уязвимостей и недекларированных возможностей в программном обеспечении" (издание второе, доработанное, утверждён ФСТЭК России 25 декабря 2020 г.);

• продукт разрабатывается с учётом требований, предъявляемых к статическим анализаторам в ГОСТ Р 71207–2024.

Подробнее: Сертификация ФСТЭК. Если у вас есть вопросы, напишите нам в поддержку или позвоните по телефону +7(903)844-02-22.

Как правильно работать с паттернами кода?

Всем привет! Это третий сезон курса «Паттерны и практики написания кода». Первая серия вводная: в ней бэкенд-инженер Юра Афанасьев знакомит вас с историей паттернов и их функциями, а также рассказывает, как с ними правильно работать.

Смотреть VK
Смотреть YouTube

Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.

Кардинальное упрощение привязки GitHub, GitLab, Bitbucket в Amvera Cloud

Привязка репозиториев GitHub, GitLab, BitBucket вызывала у наших пользователей затруднения, и мы обещали упростить процесс.

Теперь для привязки репозитория достаточно указать токен и выбрать ветку и репозиторий.

Способ позволяет организовать максимально простой деплой и обновление приложений через git push. Для обновления приложения достаточно сделать коммит в привязанный репозиторий, и оно соберется и бесшовно запустится автоматически.

Подробная инструкция по подключению доступна по ссылке.

Amvera Cloud — это облако для простого деплоя приложений через git push (или интерфейс). Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS.