О компиляторах.
Если проект не содержит в себе один или несколько проприетарных компиляторов, предназначенных для сборки именно этого проекта - то это не очень большой проект.
Ядро Linux по этому определению может называться очень большим проектом. Под него специально затачивается gcc.
У IBM есть даже специальный язык PL/S, используемый специально для написания операционной системы. Компилятор PL/S не доступен вне IBM.
О языках программирования.
Язык программирования обычно становится конфеткой через 40-50 лет активного использования, когда из него устраняются все абстрактные идеи авторов и привносятся свойства, реально нужные программистам.
Исключением из этого правила является C++, который, несмотря на довольно почтенный возраст, до сих пор представляет собой полигон для игры ума авторов.
С другой стороны, стандарт Scheme принимают голосованием программистов по спорным вопросам.
Чем дольше живу, тем больше ценю Лисп и Фортран.
Магические квадраты с произведением
О магических квадратах известно, наверное, всё. А возможны ли магические квадраты, в которых равны не суммы значений в строках, столбцах и на диагоналях, а их произведения? Оказывается – возможны. В дальнейшем буду называть такие квадраты «магическими квадратами с произведением» (сокращённо – МКП).
Интересно, что, как и «обычных» магических квадратов, возможно бесчисленное множество вариантов МКП. В общем случае для трёх чисел a, b и n МКП размером 3 × 3 имеют вид:
При этом a ≠ b, a ≠ 1, b ≠ 1, a ≠ b2, b ≠ a2,
Интересно, что любой МКП размером 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 помогают быстро найти все связанные с ошибкой события.
Порождающие паттерны: какие они и в чем их назначение?
В новой серии третьего сезона курса «Паттерны и практики написания кода» перейдём от теории к практике и погрузимся в мир прикладных паттернов. В предыдущем видео мы узнали, что паттерны делятся на три группы: сегодня вместе с бэкенд-инженером Юрой Афанасьевым начнём рассматривать первую из них — порождающие паттерны.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
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 или чистая архитектура. Скорее это смешение и личный опыт. Попытаюсь выдавать информацию без "воды".
Погнали:
Опубликовали программу 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. В этом механизме через функцию AddClipboardFormatListener приложение добавляет себя в качестве листенера. После этого никаких дополнительных опросов буфера обмена проводить не нужно — система сама оповестит приложение, если буфер изменился.
При получении уведомления служба истории буфера обновляет собственно историю буфера обмена. Но из-за асинхронности событие может происходить с задержкой. Как объясняет Чен, из-за асинхронной природы обновлений при получении WM_CLIPBOARDUPDATE от Clipboard Format Listener буфер может успеть обновиться ещё раз.
Как считает Рэймонд, это даже не баг, а фича. Так получается избегать приложений, которые быстро спамили бы в буфер обмена множество изменений. Если даже пользователь не успевает воспользоваться содержимым буфера, то сохранять это для истории смысла нет, указывает Чен.
В другом посте из своего блога Рэймонд объяснил механизмы утилит-просмотрщиков буфера обмена с синхронными обновлениями буфера. Здесь периодически выполняется опрос GetClipboardSequenceNumber. У данного подхода тоже есть проблемы: редкий опрос угрожает привести к пропуску изменения буфера, но слишком частые запросы создадут лишнюю нагрузку на систему.
Рэймонд обещает в следующий раз показать, как исправить код выше.
Всегда спрашивай дедлайн у заказчика, директора, менеджера, руководителя проекта, у любого, кто пришел к тебе с задачей, проектом. Прямой вопрос может остаться без ответа. Задавай разные вопросы. Основная задача - выяснить дедлайн. Он нужен.
Дедлайн есть всегда. Если ты его не знаешь, тебе его не сказали или сказали, что его нет - он все равно есть. Он настигнет тебя в самый неподходящий момент. Он будет для тебя "сюрпризом".
Даже размытый дедлайн - это хорошо: конец следующего года, через 3 месяца. Он создает основу для диалога, порождает вопросы и предложения. Он систематизирует, расставляет приоритеты, помогает принимать решения, показывает дистанцию. Ты можешь планировать работу, нагрузку, периоды ускорения и замедления, вехи.
Периодически уточняй дедлайн. Дедайн может измениться. Ты его не контролируешь. Это нормально. Он может измениться в силу внешних обстоятельств. Твоя задача - держать руку на пульсе и уточнять изменения в дедлайне. Не жди, что тебе скажут первым о изменениях - не скажут.
А у меня нет дедлайна. Думаешь тебе повезло? Нет. Это повод задуматься. Скорее всего у источника задачи нет стратегии, целей, долгосрочных планов, ожидания не соответствуют действительности. Он не понимает, что хочет. Задача - это идея, без понимания практического применения. Скорее всего ты в "болоте". Если компания "живая", дедлайн тебя настигнет. А может быть тебя хотят "слить" и это ловушка? Я видел такое, так бывает.
Почему классический мониторинг не работает для микросервисов и облаков? Переход к Observability
Современные системы давно перестали быть монолитами — теперь это сложные экосистемы из микросервисов, облачных сервисов и распределенных баз. Но если ваш мониторинг всё ещё фокусируется только на CPU и RAM, вы рискуете пропустить критические сбои.
Главные проблемы классического подхода:
Невидимые бизнес-сбои: Сервер «живой», но конверсия платежей падает.
Поиск иголки в стоге сена: При ошибке в цепочке из 10 микросервисов метрики инфраструктуры не укажут на источник проблемы.
Ручная настройка: Часы на алерты для каждого сервиса вместо автоматизации.
Решение — 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:
Интеграция статического анализа и DevSecOps: PVS-Studio и AppSec.Hub в действии.
Внедрение процессов безопасной разработки. Интеграция 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.
Как правильно работать с паттернами кода?
Всем привет! Это третий сезон курса «Паттерны и практики написания кода». Первая серия вводная: в ней бэкенд-инженер Юра Афанасьев знакомит вас с историей паттернов и их функциями, а также рассказывает, как с ними правильно работать.
Подписывайтесь на канал AvitoTech в Telegram, там мы рассказываем больше о профессиональном опыте наших инженеров, проектах и работе в Авито, а также анонсируем митапы и статьи.
Кардинальное упрощение привязки GitHub, GitLab, Bitbucket в Amvera Cloud
Привязка репозиториев GitHub, GitLab, BitBucket вызывала у наших пользователей затруднения, и мы обещали упростить процесс.
Теперь для привязки репозитория достаточно указать токен и выбрать ветку и репозиторий.
Способ позволяет организовать максимально простой деплой и обновление приложений через git push. Для обновления приложения достаточно сделать коммит в привязанный репозиторий, и оно соберется и бесшовно запустится автоматически.
Подробная инструкция по подключению доступна по ссылке.
Amvera Cloud — это облако для простого деплоя приложений через git push (или интерфейс). Встроенный CI/CD, бэкапы и мониторинг позволяют развернуть проект тремя командами в IDE и не думать о настойке инфраструктуры. Amvera проще, чем использование VPS.
Поддержка должна быть бесплатной. Всегда!
Последнее время замечаю тенденцию, что многие хостинги и публичные облака вводят платную поддержку.
Позиционируется поддержка как дополнительная опция и гарантия времени ответа. Но на мой взгляд это выглядит как вымогательство денег, когда компания может оказывать качественную поддержку, но если вы их не “подкупите” дополнительно, не будет.
Я основатель облака для простого деплоя проектов через Git push – Amvera Cloud. И вижу, что пользователи пишут нам в поддержку. И говоря честно – люди пишут только тогда, когда другие способы не помогли и они не знают, как решить их насущную проблему. А это значит мы не доработали и сделали что-то непонятно или неудобно. И это наша обязанность постараться им помочь. И я не вижу морального права просить за это с них деньги.
Поддержка может работать не идеально, можно даже разделять клиентов во время высокой нагрузки на постоянных или новых, с высоким или низким чеком или любым другим образом, чтобы кому-то помочь в первую очередь. Но помочь нужно всем.
И главное, я не верю, что на платной поддержке можно сильно заработать. Это просто предлог, чтобы работать хуже, чем может компания.
Поддержка должна быть бесплатной, всегда, и без всяких но!
Читаемость Си-кода: грустный ликбез, чтобы жить стало веселее
Многие коллеги по цеху подтвердят, что читаемость кода на языке Си иногда оставляет желать лучшего. Как подтвердят и те, кто им плохо владеет, но так или иначе сталкивается в связи с рабочими задачами.
И всему виной (ожидаемо) выражения препроцессора и, как следствие, макросы. Да, вы правильно подумали. Именно те части кода, в которых вызываются такие легенды как:
Последние два очень легко спутать, если читать код невнимательно. Вместо них иногда рекомендуют использовать
#if defined // вместо #ifdef
#if !defined // вместо #ifndefНо если же в компании/проекте/отделе нет определенного код-стайла, или он не предполагает написание длинного варианта, то, естественно, разрабы пишут короткую форму (я, честно признаться, тоже).
Чего далеко ходить - все open source проекты пестрят именно сокращенными вариантами этих выражений и с этим уже ничего не поделаешь.
А вот первое выражение из первой тройки игроков иногда вообще открывает врата ада, когда используется многострочный макрос с бэкслэш-символами (\) на концах строк.
Конечно же выражения препроцессора - это очень гибкий и полезный инструмент, позволяющий делать всё:
условную компиляцию;
выравнивание структур;
предотвращать повторные включения файла;
работать со строками;
грамотно оборачивать повторяющийся код и т.д. и т.п.
Но бывают случаи, когда упрощение кода с точки зрения алгоритма делает его слабо читаемым для того самого бедного программиста, пытающегося прочесть этот шедевр машинописного текста:
struct {
const char *name;
const char *value;
#define _SPECIAL(x) { .name = #x, .value = b->x, }
} specials[] = {
{ .name = "object", .value = b->object_string, },
_SPECIAL(host),
_SPECIAL(endpoint),
#undef _SPECIAL
};*ну все, можно начинать грустить*
Чтобы разобраться, давайте очистим код от макросов, но сохраним суть:
struct {
const char *name;
const char *value;
} specials[] = {
{ .name = "object", .value = b->object_string, },
{ .name = "host", .value = host, },
{ .name = "endpoint", .value = endpoint, },
};Что понятно из очищенного варианта:
инициализируется массив specials[];
типом данных этого массива является структура с полями *name и *value;
поля элементов массива задаются вручную.
Но как можно этот процесс немного автоматизировать и не прописывать вручную одинаковые строки?
Правильно, с помощью макроса:
#define _SPECIAL(x) { .name = #x, .value = b->x, }который определяется после объявления полей структуры.
Как обрабатывается аргумент x:
имя аргумента преобразуется в строку с помощью макроса "#x" и присваивается полю *name;
полю *value присваивается значение поля структуры b с названием аргумента x (тут нужно убедиться, что поле с именем x действительно существует в структуре b).
То есть чтобы при заполнении массива не писать каждый раз одинаковые строчки:
{ .name = "host", .value = host, },
{ .name = "endpoint", .value = endpoint, }можно вызвать выражение _SPECIALS:
_SPECIAL(host),
_SPECIAL(endpoint),Ну и в самом конце вызываем удаление созданного макроса, чтобы оно не было использовано в коде в дальнейшем:
#undef _SPECIALТеперь после прочтения этого небольшого ликбеза вы можете смело пользоваться макросами и создавать более сложные и нечитаемые шедевры наконец-то разобрались в том, насколько гибкими могут оказаться выражения препроцессора ( вообще не понимаю, как вы жили без них раньше...)
А какие выражения и макросы в Си видели вы?
PEP 750: t-строки в 3.14
Недавно ревьюил один интересный PR в CPython: в питон добавили еще один способ форматировать строки. Теперь – со специальным АПИ для внешних интеграций. Расскажу: как и зачем.
Основная причина: использовать f строки удобно, но нет никакого АПИ для перехвата момента "вставки" или интерполяции значений. Например, при форматировании html или sql – требуется специальным образом делать escape для значений. И раньше код вида f"{template}" представлял собой дыру в безопасности и потенциальное место для XSS.
string.templatelib.Template
Новый префикс t не будет создавать объект str, он будет создавать объект класса string.templatelib.Template:
>>> user = 'sobolevn'
>>> template = t"Hi, {user}"
>>> template
Template(strings=('Hi, ', ''), interpolations=(Interpolation('sobolevn', 'user', None, ''),))
>>> from string.templatelib import Template
>>> isinstance(template, Template)
True
Обратите внимание, что при создании template – у нас не произошло форматирование сразу. Мы создали объект, у которого есть свойства strings и interpolations, из которых можно собрать финальную отформатированную строку.
Давайте посмотрим на примере. Допустим, мы хотим формировать URL из наших данных:
>>> domain = 'example.com'
>>> query = 'python string formatting is too complex'
>>> template = t'https://{domain}?q={query}'
И сам код логики форматирования, где мы будем вставлять значения разным способом. Если у нас шаблон query, то мы будем использовать quote_plus для его форматирования. Остальные значения – будем вставлять как есть:
>>> from string.templatelib import Template, Interpolation
>>> from urllib.parse import quote_plus
>>> def format_url(template: Template) -> str:
... parts = []
... for part in template:
... match part:
... case str() as s: # regular string
... parts.append(s)
... case Interpolation(value, expression='query'):
... parts.append(quote_plus(value))
... case Interpolation(value):
... parts.append(value)
... return ''.join(parts)
И вот результат:
>>> format_url(template)
'https://example.com?q=python+string+formatting+is+too+complex'
Только теперь наш Template был отформатирован. Нами. Ручками.
У нас есть полный контроль за процессом форматирования. Вот в чем суть данного ПЕПа.
Фичи одной строкой
Работает = как обычно в f строках: t'{user=}'
Есть привычные определители формата: !r, !s, .2f, тд
t строки можно конкатенировать: t'Hello' + t' , world!' и t'Hello, ' + 'world'
Поддерживается режим raw строк: rt"Hi \n!"
Как устроено внутри?
Интересные места имплементации:
Новые классы Template и Interpolation написанные на C
Новый байткод BUILD_INTERPOLATION и BUILD_TEMPLATE
>>> import dis
>>> user = 'sobolevn'
>>> dis.dis('t"Hi, {user}"')
0 RESUME 0
1 LOAD_CONST 2 (('Hi, ', ''))
LOAD_NAME 0 (user)
LOAD_CONST 1 ('user')
BUILD_INTERPOLATION 2
BUILD_TUPLE 1
BUILD_TEMPLATE
RETURN_VALUEОбсуждение: как вам еще один способ форматирования строк?
Если понравилось – заходи в тг, где я рассказываю, как я делаю CPython.