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

Вы наверно знаете что высший пилотаж он же Высокий Слог С++ это шаблоны и метапрограммирование. Вы обязательно должны нагородить кучу несовместимых типов и самозабвенно искать для них универсальный алгоритм.

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

Но я хочу рассказать вам историю одного детективного расследования в недрах крупного OpenBMC-проекта (экосистема серверных платформ swtSyst). Это история о том, как безудержное желание перенести всё в compile-time (constexpr), помноженное на ультрасовременный синтаксис C++20, породило идеальный «молчаливый баг» (silent failure). Он мог бы годами жить в продакшене, успешно компилировался, не выдавал ни одного ворнинга, но полностью ломал логику работы приложения.

Если вы любите метапрограммирование, шаблоны, операторы свёртки (fold expressions) и тонкости работы с памятью в C++ — устраивайтесь поудобнее. Мы отправляемся в шаблонный ад.

Алгоритм вывода цветного текста в консоль и как его можно написать на AutoHotkey. Погрузимся в язык, рассмотрим оптимизацию кода и улучшение читабельности (применимо к любому высокоуровневому языку).

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

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

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

Википедия

В статье мы будем рассматривать моделирование упругих столкновений на примере атомов одноатомного газа в двумерном пространстве.

Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.

Задача краулера была простой: отслеживать посещённые URL, чтобы не краулить одну и ту же страницу дважды. После обработки 1 миллиона URL (средняя длина 80 байт) хэш-таблица, в которой хранились эти URL, разрослась до 96 МБ плюс оверхед.

«Можем ли мы обменять точность на память? Нас вполне устроит несколько дублированных операций, если это позволит сэкономить большой объём памяти», — сказал мне мой менеджер во время ревью кода.

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

Несколько недель назад мы обсуждали Java-компонент, запускающий кластер Spark. Его основная задача — координация. Он поднимает всю необходимую инфраструктуру, прокидывает конфигурацию, дожидается нужных сигналов и отходит на второй план.

Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.

У меня обычно так: я довожу проект до прототипа, доказываю себе, что моя идея работает — и теряю интерес. Проект lifemodel — один из таких. Это ИИ-агент, которого я строил не как чат-бота, отвечающего на вопрос, а как «цифрового человека»: с сердцебиением, энергией и желаниями, которые возникают сами и сами побуждают его действовать. Прототип заработал. А потом, как обычно, мотивация кончилась. Этот пост — две вещи сразу. Для тех, кто пришёл за технической частью: разберу архитектуру проактивного агента — heartbeat-цикл, желание вместо опроса, многослойность с системой безопасности, душу и личность с конституцией и парламентом. Для тех, кто годами читает в режиме read-only — будет и вторая, честная часть: почему такие проекты застревают, и почему в одиночку их не вытащить.

Началось всё примерно так. Я сидел над своим проектом: пока работал, общался по нему с нейросетками и параллельно искал в интернете разную информацию, которая могла бы пригодиться. И вот тогда у меня впервые начала закладываться мысль, что я хотел бы читать код быстрее. Что мне не нравится, сколько времени на это уходит.

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

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

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

В первых двух статьях я сделал две вещи и обе — честно.

Описал движок graphlens: как он берёт исходники на Python, TypeScript, Go, Rust и PHP и нормализует их в единый типизированный граф — узлы-символы, type-aware рёбра (CALLS, HAS_TYPE, INHERITS_FROM), детерминированные SHA-256 ID, межъязыковые границы.

И померил его: 936 прогонов на apache/superset (~400k строк, Python + TypeScript, граница /api/v1/...). Вывод — на задачах анализа влияния структурный граф бьёт grep по стоимости в 10–23 раза, а на точечных запросах разница почти нулевая.

Но была дыра, о которой я в обеих статьях молчал. Движок — это не продукт. Чтобы реально подключить graphlens к агенту, недостаточно pip install и API. Нужно написать кучу обвязки. Эта статья — про то, как я эту обвязку оформил в отдельный продукт graphlens-mcp, который ставится одной командой и сразу начинает работать. Он в alpha, он бесплатный (MIT), и его можно потестить на своём проекте за пять минут.

Кейс первый, на собеседовании феерит и крутая. Вышла на работу и сидит как серая мышь, будто её нет. А потом в какой-то день тупо не выходит на работу. Звоню, а вы где? На что мне объясняют, мол, я ждала одобрение от крутой компании, его получила и туда вышла работать. А где деловая этика? Как такую наняли на работу, если она даже предыдущие соглашения и договорённости чисто по-человечески и по деловому этикету не закрыла? Просто испарилась и забила.

Кейс второй, работал у меня тестировщик, и как-то раз он приходит и говорит: я купил горящую путёвку и еду на 11 дней. А я его спрашиваю, а как бы надо было заранее предупредить, у нас же релиз запланирован. А мне отвечают: ну я уже купил, завтра вылет.

Третий кейс, человек работает 1–2 месяца, классный. Начинаю платить выше рынка ЗП. А потом раз, и исчез. Пытаюсь дозвониться и т.д. В итоге он через неделю мне говорит, что у тебя работа такая, что я боялся проспать, и начал принимать спиды, и через неделю так устал, что уснул на несколько дней. В итоге его брат приехал и сказал, что ему ЗП давать нельзя, всё через него, иначе он сторчится.

Кейс четвёртый, потом был случай: нахожу нормального программиста, работает качественно и т.д. Уговор, что 1–2 месяца, до получения инвестиций, я не смогу ему платить. В итоге он хорошо работал, я его лично встретил в Астане в аэропорту, прокатил на ЛРТ, потом заказал такси. Он хоть и отбивался, мол, у него заказ такси не работает, он забыл карты в Бишкеке, но мне было всё равно, он гость, и я его встретил. Отдельное спасибо ему за пахлаву и другие сладости, что он моей жене привёз и мне. А потом, на следующий день, сказал, что не может дальше работать на таких условиях.

Попался вот тут интересный проект https://habr.com/ru/articles/1052536 - дай, думаю, потестирую, как оно работает?

А потестировать сходу нельзя, в релизах имеются разные сборки под разные платформы, вот только для моей arm64 (aarch64) нет.
Надо бы собрать - но оно написано на Rust, с Rust я не работаю, поэтому на компьютере ничего нужного для сборки нет, устанавливать всё это на настроенный компьютер как-то не очень хочется - но ведь можно сделать это в контейнере!

И получилась вот такая пошаговая инструкция:

Вайб-кодер в чистой форме — человек, который вообще не имеет отношения к разработке — физически не способен оценить код. Для него работает = работает. А я утверждаю: код, сгенерированный нейронкой, всё равно будет более плоским, более ущербным и менее оптимальным, чем код живого разработчика. Проблема в том, как это доказать человеку, который код читать не умеет. Поэтому зайдём через аналогию, которую может проверить КАЖДЫЙ — через тексты.

Привет, Хабр! Меня зовут Сергей Бережной, я директор по взаимодействию с разработчиками в Яндексе и эксперт онлайн-магистратуры «Фронтенд-, бэкенд-разработка и ИИ-решения» ИТМО в партнёрстве с Яндек с Практикумом. В этой статье хочу поговорить о том, почему, если вы хотите стать востребованным разработчиком в 2026 году, одной практики может быть мало, чего ждут от соискателей крупные компании и поможет ли онлайн-магистратура стать разработчиком уровня мидл.

Если совсем коротко: я написал свой VPN на Rust — побайтово-корректный TLS 1.3 с заёмом чужого сертификата, гибридное постквантовое рукопожатие, пять режимов маскировки и под 700 Мбит/с на скачивание. Ниже — как это устроено изнутри и десяток шишек, на которых я учился. Но начать хочется издалека.

Все обзоры меряют одно — как быстро агент работает с кодом. Но на моём боевом Java-проекте на тысячи строк самый «быстрый» агент выдал решение за 12 секунд, а потом 40 минут гонял сборку в терминале, пытаясь заставить код компилироваться.

Кто быстрее работает с кодом — тот дольше его чинит, а типовые сравнения этап починки не считают вовсе.

Чтобы проверить это, я взяла одну и ту же задачу «добавь фичу и покрой её тестами» и дала её трём типам агентов: CLI в терминале (Claude Code, Codex, OpenCode), кросс-IDE плагинам (Cursor через ACP, Copilot, Cline, Kilo Code, Windsurf) и агенту, встроенному в JetBrains Platform (Veai). Меряла не секунды на генерацию, а число итераций до зелёной сборки и расход токенов. Ниже — шесть метрик, которые я добавила, и почему они переворачивают выводы типовых обзоров.

Spring Batch - проект в рамках экосистемы Spring Framework, который, как правило не получает должного внимания. Тем не менее, это хорошее решение для Enterprise Batch Processing.

Долгое время Spring Batch требовал SQL-базу для хранения общего состояния, шагов перехода, статусов выполнения и время запусков. Даже если проект жил на MongoDB, рядом часто приходилось держать Postgres или MySQL только ради метаданных.

В Spring Boot 4.1 стало проще: появился spring-boot-starter-batch-data-mongodb. Теперь Spring Batch научился работать с MongoDB.

В статье Josh Long рассказывает про новинки в рамках Spring Batch, в том числе и новую интеграцию с MongoDB, а также работу с GraalVM

«Разработчики больше не нужны»? Так читается вывод нового исследования Anthropic — ~400 000 реальных сессий Claude Code за полгода. По их данным, с AI-агентами выигрывает не тот, кто умеет кодить, а тот, кто разбирается в своём деле: у не-программистов 26% успеха против 30% у разработчиков, разница всего 4 пункта. Эксперт запускает в 2.4× больше действий агента и вчетверо чаще вытаскивает зависшую сессию. А вот с их выводом я не согласен. С цифрами вопросов нет — но вытащили из них не то. Эксперт-одиночка и правда соберёт прототип быстрее инженера. Только без инженера он не покроет это тестами, не заложит масштабирование и безопасность — и продукт ляжет при первой же нагрузке. Разбираю исследование по цифрам, рассказываю, где это сходится с тем, что я писал раньше, и почему рабочая связка одна: эксперт предметной области + инженер, который знает harness вокруг агентов.

Когда Docker Hub и другие платформы стали ограничивать доступ для российских пользователей, многие разработчики почувствовали то, что раньше казалось абстрактной угрозой. Но к тому моменту инфраструктура уже готовилась - платформа GitVerse, зеркала Яндекса и VK. Подробный разбор что делать разработчик в случае реальных блокировок.

Представьте, что вы едете в ночном поезде. Чтобы гарантированно выйти на нужной станции, придется не спать всю ночь и внимательно отслеживать остановки. Свою станцию вы не пропустите, но сойдете с поезда уставшим. Другой способ: узнать из расписания предполагаемое время прибытия поезда, поставить будильник на нужное время с небольшим запасом и лечь спать. Этого вполне достаточно, чтобы не пропустить свою станцию, но, если поезд задержится, пробуждение окажется слишком ранним. Идеальным решением было бы лечь спать, положившись на то, что кто-нибудь или что-нибудь разбудит вас незадолго до реального прибытия поезда на нужную станцию...

Какое отношение этот пример имеет к работе с потоками в программировании? Дело в том, что решить задачу синхронизации конкурентных операций можно также несколькими способами, близкими к ситуации выше. Меня зовут Александр, я разработчик на С++ в YADRO, и в этой статье я разберу несколько вариантов эффективной организации ожидания потоков. 

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