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

Логирование есть практически в каждом C++ проекте. Почти любой сервис, демон или библиотека рано или поздно обрастает строками вроде LOG_INFO(...) или logger.debug(...).

Чаще всего библиотека выбирается по привычке или популярности — spdlog, quill, easylogging++ и т.п. При этом редко кто проверяет, какую цену приложение платит за логирование.

В высоконагруженных системах логирование может выполняться:

У меня двадцать лет в IT. Большую часть этого времени я проектировал и эксплуатировал инфраструктуру на PostgreSQL. Сейчас работаю архитектором: Go, Python, Postgres, Redis, ClickHouse, мониторинг на десятки тысяч баз. До этого писал на Ruby, пробовал Rust. Классический бэкенд-инженер со всеми вытекающими привычками: императивный код, мутабельное состояние, постоянные if err != nil { return err }.

А потом я начал писать бэкенд на Gleam — молодом функциональном языке на BEAM (Erlang VM), который появился в стабильной версии только в 2024 году. Навык ещё в разработке, но бэкенд уже работает, и я не жалею. Путь был... познавательным.

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

Сезон Heavy Digital длился на Хабре с 30 января по 15 марта. В нём приняли участие 48 материалов о цифре в промышленности, набравших в сумме сотни комментариев и более двухсот тысяч просмотров.

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

Что ж, пора подвести итоги сезона и посмотреть, что эти сорок с лишним текстов добавили к дискуссии о заводской цифре на Хабре.

Иногда одна незаметная фича может сжигать гигантский объём ресурсов. В Netflix именно так и вышло: скоринг серендипности в Ranker оказался дорогой горячей точкой, а попытка слегка его ускорить в итоге привела к большой инженерной перестройке — от батчинга до SIMD через JDK Vector API.

В новом переводе от команды Spring АйО разберем, как SIMD AVX инструкции на практике позволили снизить потребление CPU.

На Хабре — регулярные посты в духе «проклятые HR’ы, 500 откликов, ноль ответов». На hh.ru — число джуниорских позиций сократилось вдвое. При этом, в нашу HR-службу приходят ребята с горящими глазами, проходят обучение — и через месяц кладут заявление, потому что надо ходить в офис (а иногда — сюрприз! - еще и в клиентский). Параллельно ходят байки про синьоров, которых сократили из крупных компаний, и теперь они соглашаются на зарплату вчерашнего стажёра — но живьем таких никто не видел, блин. А тут ещё вайбкодинг, которому едва исполнился год — и он, якобы, уже пишет за троих, и без ошибок. дададад.

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

9 марта 2026 года Microsoft выпустила VS Code версии 1.111 — первый стабильный еженедельный релиз. Ведущий инженер Кай Мецель объявил, что финальное тестирование будет «встроено в еженедельный процесс». Каждая новая функция в v1.111 связана с ИИ. Главное нововведение: режим Autopilot, в котором ИИ-агент работает автономно до завершения задачи — сам одобряет вызовы инструментов, сам повторяет попытки при ошибках, сам отвечает на собственные вопросы, чтобы «агент не простаивал в ожидании ответа».

Я пишу код в той или иной IDE с начала 2000-х. Видел, как Eclipse замедлялся до ползания, как IntelliJ поглотил мир Java, как VS Code стал редактором по умолчанию для целого поколения. Это — другое. Это не добавление функции. Это изменение самих отношений между разработчиком и инструментом.

Kafka часто воспринимается как система, гарантирующая доставку сообщений и Exactly Once Semantics. Однако в реальных распределённых системах эти гарантии заканчиваются на границе брокера.

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

В этой статье разберём:

Эпоха 1: Точность на обучении 21.10%, на валидации 94.55%
Высокая валидация на первой эпохе — случайное совпадение. Модель ещё не обучилась, но случайная инициализация весов дала хороший результат на маленькой валидационной выборке.

Эпоха 2-3: Точность на валидации упала до 0%
Модель начала переобучаться на обучающей выборке. Это нормальное явление на ранних этапах обучения.

Эпоха 20: Стабилизация на уровне 78.90% (train) и 27.27% (val)
Начало сходимости модели. После этой эпохи точность на валидации начинает расти.
....
и это всё было на ресурсах Goole-Colab, даже не всегда получалось попасть на GPU. От сюда и выбор размерности батча, для обучения

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

В начале 2026 года индустрия столкнулась с неожиданным кризисом: искусственный интеллект стал достаточно хорош, чтобы работать без надзора, но слишком хаотичен, чтобы работать в команде. Пока одиночные агенты вроде Felix (создан разработчиком Нэтом Элиасоном) приносили своим создателям более 100 000 долларов выручки, управление роем из пятнадцати или двадцати подобных ботов превращалось в логистический кошмар. Разработчики теряли сотни долларов из-за зацикленных скриптов и забывали, какую задачу выполняет каждая из открытых вкладок терминала.

Ответом на этот «координационный налог» стал запуск Paperclip — системы с открытым исходным кодом, которая переносит принципы корпоративной бюрократии на управление нейросетями.

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

Для всех юридических экспертов, читающих это: моя компания подала форму SB/43 в USPTO и оплатила пошлину за отказ от конечной части срока действия патента № 10 373 352, действующий с 17 марта 2026 года.

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

В целом работа шла хорошо, до того момента, пока не звонил телефон. Часто при разговоре могло звучать название объекта, либо его цифровая маркировка.

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

Тут и выявилась проблема отсутствия единого понимания о расположении объектов на территории завода. Которую, как уже упоминалось выше, можно было выразить вопросом: «Где это находится?». Вопрос как выяснилось непростой и важный, особенно для предприятия площадью несколько квадратных километров с множеством объектов, в режиме круглосуточной стройки, словно муравейник, с числом строителей, как в небольшом провинциальном городке нашей необъятной страны.

Оценка величины зерна является одной из базовых задач количественной металлографии, поскольку размер зерна напрямую связан с комплексом механических свойств металла: прочностью, пластичностью, ударной вязкостью, склонностью к хрупкому разрушению и стабильностью свойств после термической обработки. В промышленной практике для определения величины зерна широко применяются стандарты ASTM E112, ISO 643 и ГОСТ 5639.

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

В данной статье рассматривается практическая реализация системы автоматизированного анализа зеренной структуры стали на Python с использованием OpenCV. Цель разработки состояла не в замене стандартизованных методов их упрощённой цифровой имитацией, а в создании воспроизводимого инструмента, который позволяет приблизить лабораторный анализ к количественной обработке изображений и обеспечить прослеживаемость результата.

В марте 2025 Claude Code был в бете без plan mode, Codex CLI не существовал, а топовая модель решала 65% задач на SWE-bench. Я выгрузил все данные за год - и цифры пугают. Cursor вырос до $2B выручки, контексты раздулись в 5 раз, цена frontier-кодинга упала в 16 раз. А Cursor уже гоняет тысячу агентов, которые за неделю написали браузер без людей.

Привет, Хабр!

Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК InfoWatch. Мы разрабатываем DLP-систему для защиты контента и предотвращения утечек информации.

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

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

Параметризация Pytest позволяет сделать из теста каркас, шаблон, который принимает данные для конфигураций, для assert и т.д.

Пример из документации Pytest:

Каждый раз, когда вы вставляете рабочий код в чат с ИИ, в голове мелькает вопрос: «Не попадут ли мои данные не в те руки?» Единственный способ сохранить свои нервы — развернуть модель на собственном железе. А на фоне новости о переходе создателя OpenClaw в OpenAI сделать это хочется еще быстрее.

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

12 093 метода из 19 880 в моём проекте — ни одного комментария. Покрытие документацией — 39%.

Это не чужой легаси-код. Это мой собственный проект, который я пишу прямо сейчас. Я направил свой инструмент на самого себя и увидел то, от чего у любого техлида дёргается глаз: кодовая база растёт быстрее, чем документация. 1183 файла на Python. 480 коммитов за полгода. 21 аналитический сценарий, которые я наваял за это время. А документация покрывает меньше половины.

Новый разработчик приходит в проект, открывает src/workflow/scenarios/audit_composite.py — а там 6318 строк, 114 вызовов в другие модули, цикломатическая сложность 80. И задаёт первый вопрос: «Кто мне объяснит, как это работает?»

Раньше ответ был: «Спроси Мишу». Теперь — запрос к графу свойств кода. И я наконец-то могу заниматься своей работой, а не быть живой документацией.

Привет, Хабр!

Сегодня рассмотрим Send и Sync. Не «что это такое» (это вы в book прочитаете за пять минут), а как именно компилятор принимает решения, почему &mut T внезапно Sync, и что происходит, когда вы пишете unsafe impl Send.

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

Это не отдельная статья, а продолжение статьи про теорию объектов в с++, почему объекты в плюсах такие какие есть. Все завершенные главы я также выкладываю на github'e в английском и русском варианте. Продолжаем разбираться в теории С++...

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

Чтобы отразить это в программе, объекты, представляющие конкретные сущности, нуждаются в своём определении идентичности, которая отделена от текущего состояния. Удобный способ ввести такую идентичность будет сделать некий токен идентичности, уникальное значение, которое выражает "кто это", а не "в каком он сейчас состоянии". Таким токеном может быть, например, адрес объекта в памяти, индекс в массиве, или табельный номер сотрудника в кадровой системе и проверяя равенство токенов идентичности, мы фактически проверяем тождественность объектов: один и тот же объект или разные. 

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

Я думал, у меня всё чисто. Bandit стоял, правила регулярно обновлялись, pipeline на каждый PR ругался на опасные места. Ну, знаете, как это бывает: где-то что-то подсветит, мы правим, живём дальше, чувствуем себя молодцами, прикрыв тыл статическим анализом.

А потом я решил копнуть глубже. Не для галочки, а руками, с инструментом, который умеет ходить по коду не линейно, а как по графу.

Знаете, сколько нашлось?