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

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

Это событие не стоило бы упоминать - но "впечатлило" оформление и воплощение теста - как можно видеть ниже - из-за неаккуратности составителей даже и ответ где-то иной подходит. Попытался об этом написать приватно, почтой - но, кажется, безуспешно. Может заметку на Хабре заметят быстрее?

Что мы увидим, если посмотрим на монитор разработчика в разгар рабочего дня? Там наверняка будет открыта IDE, Git, таск-трекер, документация, корпоративный мессенджер. И еще какая-нибудь мелочевка — в зависимости от того, что принято в команде.

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

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

В Stack Overflow Developer Survey 2025 разработчиков впервые попросили посчитать, сколько отдельных инструментов они используют в работе. Из 27 378 ответивших 54% назвали шесть и более приложений или платформ. Операционная система и браузер в этот подсчет не входили. Для сайд-проектов картина оказалась несколько другой —  65% из 25 391 разработчика используют пять инструментов или меньше.

Согласитесь, шесть инструментов — не так уж много. Особенно если учесть, что речь, вообще-то, идет про современную разработку.

Но тогда возникает еще более интересный вопрос — в какой момент сам по себе полезный набор инструментов начинает сам мешать работе? В количестве ли дело или, может быть, в том, что разработчику приходится постоянно переключать внимание между несколькими системами для решения одной задачи?

В словарь добавляют 101 ключ — поиск занимает 8 763 наносекунды. Добавляют 102-й — 718.

Ключей стало больше, а времени в 12 раз меньше. Разбираемся, что происходит на 102-й вставке.

В .NET есть метод, который всегда возвращает false. Есть очистка списка, которая ничего не очищает. И есть new, после которого в куче пусто.

Разберем пять таких мест: что написано в исходнике, что от него остаётся в машинном коде и зачем так сделано.

Core War — культовая игра, где коды сражаются друг с другом. С приходом LLM она получила новую жизнь: исследователи из Sakana AI и MIT создали эволюционную стратегию для ИИ-воинов. Разбираем, как это работает.

У нас есть скрипт, который каждый день просит Google переиндексировать свежие страницы двух сайтов через Search Console — вручную по одному URL это бы никто не тянул, а сайтов и статей достаточно, чтобы запускать это руками было бы отдельной работой. 3 сентября я посмотрел в лог и увидел: за прогон дошло 59 проверок по доставке и 4 отказа «превышена квота», а адреса avitoma, помеченные как приоритетные в gsc_pinned.txt, за сутки не отправились ни разу. Не «отправились с опозданием» — ни разу, вообще.

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

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

Строка внизу терминала Claude Code показывает модель, ветку и проценты контекста. Я на неё смотрю сотни раз в день, пока агент думает. В какой-то момент стало жалко: такое внимание, а тратится на информацию, нужную дай бог раз в час. Заменил их на билеты ПДД и очередь непрочитанных статей. Ниже, как это устроено и что ещё туда кладут люди.

Каждый Java разработчик в том или ином виде сталкивается с проблемой выбора инструментария для работы с БД. Если говорить про ORM-ы, то выбор у нас невелик: Spring Data JDBC или Hibernate. И тут часто возникает набор вопросов:

- Когда выбирать Hibernate, а когда Spring Data JDBC?

- Как дизайнить Aggregate-ы в Spring Data JDBC?

- Что из DDD просто теория, а что реально важно на практике? и т.д.

Мы оттекстовали доклад Михаила Поливаха с прошедшего Spring I/O Barcelona. В докладе обсуждаются все эти и многие другие вопросы, с которыми часто сталкиваются люди при проектировании доменной модели в целом.

Будет полезно, если присматриваетесь к Spring Data JDBC или уже используете его и накопили вопросы.

⚠️ А если хочется глубже погрузиться в разработку реальных приложений, у нас в Академии скоро стартует новый поток «Java в продакшене». 

Go показывает стабильную память, heap-профиль молчит, а Kubernetes всё равно убивает под по OOM. Разберём, откуда берётся это расхождение, как на поведение под лимитами влияют cgroup, GOMAXPROCS и GOMEMLIMIT и что изменилось в последних версиях Go.

Одна и та же операция — дедупликация списка типов — написана двумя способами: на шаблонах и на статической рефлексии из C++26. Обе реализации живут в одном дереве и проверены на идентичность результата, поэтому их можно честно вычесть друг из друга. Получилось так: шаблонная версия съедает 7,9 ГиБ памяти компилятора там, где рефлексивная не съедает ничего измеримого — ±21 МиБ на 32-кратном диапазоне размеров. А по времени обе квадратичны, и рефлексия выигрывает всего пятую часть. Разбираю, откуда берётся такая асимметрия, и заодно пять компиляторных стен, в которые упираешься по дороге, — включая sizeof…, который молча возвращает неверное число.

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

Но из-за большого потока постов, качественные статьи по нужной теме теряются среди других, и если нужно найти какие-то системные тренды, увидеть как меняется отношения к Rust, AI или Open Source, а не просто “почитать что-то интересное” - это сделать сложно. Можно да, скопировать кучу ссылок и отправить в LLM, попросив отсортировать, но это занимает время и не так удобно, если нужно проанализировать большое количество тем.

И тут мне пришла идея - создать программу на Python, которая будет парсить через официальный API Hacker News, строить эмбеддинги постов с комментариями, кластеризовать посты и при помощи LLM суммаризировать этот кластер по ссылкам.

Сказано - сделано. Я смог спарсить 100 000 постов с Hacker News за последние 693 дня, получив более 1000 кластеров, более 10 миллиона апвоутов, более 27 тысячи авторов и всего 0.1% выбросов. В этой статье мы разберем, какие тренды были активны в мировом IT-сообществе последние два года.

eBPF‑программы проходят статический анализ до загрузки в ядро Linux. Верификатор должен доказать, что программа не выходит за границы памяти, не работает с неверными указателями и не нарушает ограничений, без которых код нельзя безопасно выполнять в ядре. Но если прогнать один объект через разные верификаторы, картина меняется. Один анализатор принимает BPF‑объект, а другой считает его небезопасным и запрещает загрузку.

Именно так и вышло...

Статья для тех, кто исследует eBPF и статический анализ. Ошибку в программе мы искать не будем — её там нет. Нас интересует другое: почему два верификатора расходятся в выводах.

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

Код в этом проекте пишет ИИ. Целиком. Бэкенд на Go — язык, которого я не знаю: я не писал на нём ни строчки ни до, ни во время проекта. Фронт на TypeScript и Vue — тут я в теме и мог бы читать, но не читаю. В код я не смотрю вообще: ни в реализацию, ни в тесты, ни в диффы. Я пишу задачу и проверяю результат — всё.

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

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

Привет, Хабр! На связи команда разработки Just AI. Хотим рассказать, как мы автоматизировали часть рутинных задач вокруг разработки с помощью LLM-агента. Не генерацию функций и не написание кода — нас интересовало то, что происходит с задачей до и после написания кода: создание merge request, сборка, обновление Jira, передача задачи на тестирование и другие повторяющиеся действия.

На небольшой задаче таких шагов набирается около десяти. Нужно помнить порядок действий, договоренности команды и постоянно переключаться между разными инструментами. Мы решили передать эту рутину агенту: описали правила команды текстовыми инструкциями и подключили инструменты для работы с Jira, GitLab, Jenkins и Sentry.

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

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

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

Возможно ли распознать на смартфоне многостраничный УПД со сложной таблицей, исправить перспективу, прочитать мелкий шрифт и рукописные пометки — и сделать все это без подключения к внешней инфраструктуре? Короткий ответ: да. Однако для безопасной системы распознавания первички недостаточно написать в презентации «работает локально». Нужно правильно выстроить весь маршрут документа — от камеры смартфона до 1С или ERP.

Лень — двигатель прогресса. Я очень ленив, поэтому прогресс должен был выйти впечатляющим. Спойлер: он и вышел, но с ленью что-то пошло не так.

Началось с того, что я предложил взять go-playground/validator — и услышал, что рефлексия нас замедлит. Бенчмарки показали единицы микросекунд на структуру: примерно столько же, сколько json.Unmarshal того же тела, и на три порядка меньше похода в базу двумя строками ниже. Решение всё равно осталось прежним.

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

Ниже — как это выглядит, чего генератор делать отказывается и чем я за это заплатил.

В 2016 году EA закрывает свой последний оплот разработки в Питере, и народ начал разбредаться по разным студиям и командам. Тогда мировой игрострой ещё благосклонно смотрел на обладателей красных паспортов, и несколько моих бывших коллег "со связями" организовали мини-галеру и умудрились получить контракт на поддержку движка для прототипа новой игры Arkane. Причем схема взаимодействия была достаточно мутная, из-за нежелания Остинцев работать напрямую с пост-СНГ конторами, поэтому основной контракт у них был через каких-то корейцев за три рубля, которые делегировали часть работы французкой конторе за рубль, а те наняли каких-то ребят за десять копеек из восточной Европы, ну вы поняли каких:)

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

С этого момента и началось моё знакомство с идеями, которые мы внутри команды прозвали "арканутым C++", и с их реальным применением в разработке игр. Я и раньше сталкивался с жёсткими требованиями к разработке на плюсах на своей доигростростроевской работе, но за шесть лет как-то раздобрел и перестал сильно жестить с оптимизацией, так что знакомство с командой из Остина вызвало стойкое дежавю разработки начала нулевых.

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

Здесь вас ждут код эмулятора и краткое описание архитектуры троичного компьютера «Сетунь 70».

Возможно вы слышали о троичных ЭВМ семейства «Сетунь», читали о них на Хабре или где-нибудь еще. Материал подавляющего большинства публикаций не отличается достоверностью и преследуют цель привлечения внимания. Их авторы не стесняются хохмить размещая в публикации фотографию здоровенной ЭВМ «Стрела», занимающей отдельный зал, поместив под ней подпись малая ЭВМ «Сетунь». Они не видят разницы между троичной системой счисления, троичной схемотехникой и трехзначной логикой. А зачем, все равно же и там и там есть что-то про «три», верно?

Не моргнув глазом могут написать про неведомое в то время импортозамещение или что эти машины были построены на основе троичной логики, ссылаясь на статью англоязычных дворников в Википедии (это мнение для них куда важнее мнения автора архитектуры и конструктора машины, и здравого смысла). Они не знают что под названием «Сетунь 70» в разное время существовали две заметно разные машины, и не слышали про существование «Сетуни 72».

У нас есть конвейер, который раз в день собирает кадр для Stories в Instagram (фото + выжженная поверх подпись) и публикует его через Graph API на два бренд-аккаунта. 2 сентября в моей ленте всплыла своя же сторис, и подпись «посчитал сколько стоит перевезти сестру в москву» была обрезана с обеих сторон — первые и последние буквы срезаны краем экрана. Я это почти сразу починил. 5 сентября мне снова написали, что сторис «кривые». Я почти сразу починил снова. Обе правки были правильными и обе не имели отношения к тому, что жаловались на самом деле.