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

В прошлых двух статьях я разбирал DNS-трафик домашней сети и анализировал 1233 публикации Хабра, чтобы понять, за что площадка даёт рейтинг. И там, и там был вопрос, который я обходил: чем, собственно, я выгрузил эту тысячу статей?

Не руками копировал и не скриптом на Python, который на двухсотом запросе получил бы 429 и бан по IP. Я написал расширение для Chrome, которое сохраняет статьи Хабра в Markdown — по одной, пакетом или автоматически по расписанию, — и делает это достаточно вежливо, чтобы сервер не считал его атакой.

Главная мысль статьи оказалась не про парсинг HTML, а про хорошие манеры к серверу. Наивный качатель на голом fetch пишется за пять минут и получает бан на десятой. Инструмент, которым можно пользоваться постоянно, отличается тремя вещами:

— держит принудительный интервал между запросами (1.5 секунды, гарантированно); — слушает 429 и при перегрузке сервера замолкает на три минуты целиком (паттерн circuit breaker), а не долбит сквозь ограничение; — работает с открытыми статьями для личного архива, а не сливает базу.

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

Расширение с открытым кодом под MIT, ставится из Chrome Web Store в один клик.

REST Битрикс24 можно удобно использовать из Python — для интеграций, миграций, аналитики и служебных скриптов. 

Разбираем библиотеку a24wh: шесть функций, которые упрощают запросы, пагинацию, batch-вызовы и обработку ошибок.

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

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

Со стандартной библиотекой Rust так постоянно. Она большая, и половину её мы не используем не потому, что она плохая, а потому, что просто про неё не знаем — и пишем руками то, что давно лежит готовым. В первой части уже разбирали такие штуки: never-тип !, matches!, black_box, прозрачные обёртки repr(transparent) и transmute_copy. Подготовил для вас ещё девять.

Claude Code History Viewer читает ~/.claude/projects и превращает машинный JSONL в нормальный интерфейс: диалоги с тулколлами и сабагентами, глобальный поиск, статистика по токенам и стоимости, плюс истории ещё 27 клиентов вроде Codex CLI и Cursor. Показываю, как поднять его headless-режим в Docker на сервере без иксов (готовый бинарь + тонкий образ), что показывает Global Overview на 3,4 ГБ истории, как дёргать те же команды по HTTP через POST /api/<имя> и на какие мелочи я наступил — от обрезанного в логе токена до лимита памяти 512 МБ в официальном compose.

Приветствую, Хабр! Меня зовут Владислав Тимашенков, я занимаюсь автоматизацией тестирования в ГК Infowatch.

В этой статье мы построим основу лаконичного фреймворка для UI-автотестов. Настроим запуск браузера, подготовим авторизацию, создадим Page Object и напишем тест. Здесь не будет лишних обёрток и сложной инфраструктуры, не будет даже ИИ и прочего хайпа. Только проверенные решения на базе Playwright, готовые к использованию. 

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

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

В прошлой статье речь шла в основном про транспортный уровень - uTLS, decoy-трафик, pacing и всё, что связано с прохождением DPI. Это удобно рассматривать как отдельную техническую задачу, но внутри проекта это только один слой.

На моей части лежат клиенты под пять операционных систем: Windows, macOS, Linux, Android и iOS. Даже когда собственно транспортная логика у них общая, вокруг неё неизбежно появляется платформенный код. У каждой системы свои сетевые API, свои ограничения на фоновую работу, свои модели пермишенов и свой способ интегрировать всё это с остальной системой.

Кроме клиентов есть сетевая инфраструктура: control- и exit-узлы, арбитр, подписанный манифест узлов и обвязка вокруг этого хозяйства. Есть метрики, алертинг, ротация ключей и конфигов. Есть анализаторы трафика. Всё это не существует независимо друг от друга: изменение протокола довольно быстро превращается в изменения на нескольких платформах, серверных компонентах и в тестах.

И это только то, чем занимаюсь непосредственно я.

Рядом существуют партнёрские приложения, использующие наш SDK, сайт, документация и экосистема вокруг клиента. Ими занимаются другие люди, но с точки зрения общего объёма разработки они никуда не исчезают.

Команда при этом небольшая. Поэтому довольно быстро возникает банальная арифметическая проблема: задач больше, чем люди способны последовательно написать руками за разумное время. Именно здесь у нас появились LLM - в основном Claude, иногда модели OpenAI.

Не как ещё один архитектор и не как человек, которому можно сказать «сделай мне анти-DPI систему», а как инструмент для довольно определённого класса инженерной работы.

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

В отрасли разработки программного обеспечения под системным дизайном (System Design) понимают процесс проектирования архитектуры, компонентов, баз данных и связей информационной системы. Цель системного дизайна - обеспечить масштабируемость, отказоустойчивость и высокую производительность системы, в том числе при росте нагрузки. 

В первой статье по этой теме https://habr.com/ru/articles/1054184/ я рассказывал про принципы декомпозиции программной системы на модули и слои программных компонентов на примере задачи разработки бэкенда корпоративных чатов, рассмотрел пример реализации модуля идентификации и аутентификации пользователей на языке программирования Go.

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

Я Go-разработчик, но у меня есть собственный проект — и это значит, что Go только часть работы. В обычную неделю я переключаюсь между Go-бэкендом, SQL, React и TypeScript, дизайном API, архитектурой, Docker, CI/CD, инфраструктурой, тестами и UX.

Проблема не в том, что я чего-то из этого «не знаю». Невозможно держать все эти области в голове одновременно и при этом в одиночку делать продукт целиком. Контекст-свитчинг стоит дорого сам по себе.

AI помогает. И примерно здесь у всех начинается один и тот же спор: Claude или Codex? Кто лучше пишет код, за какую подписку платить.

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

задача → нейросеть сама придумала → сама написала → сама себя проверила → сказала, что всё готово

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

Поэтому я перестал выбирать и развёл роли: Claude принимает решения. Codex реализует. Claude независимо проверяет результат.

Это дало три вещи, а не одну:

Я дал модели (в codex) возможность самостоятельно решать, когда нужен compact, и обязал её объяснять причину и строить план на будущее.

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

Теперь перед большой фазой агент проверяет остаток контекстного окна. Если планируемая работа не помещается, он сохраняет checkpoint с инфой о том, что делается и планируется после компакта, сжимает свой контекст. Очнувшись читает чекпоинт, перепроверяет состояние репозитория и продолжает работу по намеченному плану.

Вроде бы интересно, но выводов пока нет.

Потестить можно тут https://github.com/z0rgoyok/codex-luna-kit (придется патчить кодекс, но это не страшно)

При обучении графных нейросетей и гигантских эмбеддингов на миллионы узлов стандартный torch.optim.SparseAdam в PyTorch моментально забивает RAM и VRAM, вызывая ошибку CUDA out of memory (OOM). В этой статье разбираем, как устроена легковесная Open Source библиотека Disk Sparse Adam (DSA), которая выносит состояния моментов на диск через memory mapping (mmap) и позволяет обучать огромные спарс-модели на обычной домашней видеокарте.

Победить Hibernate в тестах. Сможем?

Всем, привет! На связи Михаил Поливаха, технический лидер Open Source проекта Axelix (проект, посвященный помочь вам идентифицировать частые проблемы в Java server-side приложениях, в т.ч в рамках работы с Hibernate).

Данная, последняя статья является продолжением небольшой серии статей ответов на вопросы, которые возникли у участников Spring АйО Академии в рамках программы Hibernate. Я рассмотрю оставшиеся последние вопросы, а именно:

“Можно ли в тестах как-то проверить, что Hibernate под капотом делает что-то страшное?”

Тут очень важно не давать вам “рыбу”, а научить вас рыбачить, т.е. дать вам некоторый фреймворк о том, что стоит держать в уме при работе с Hibernate.

У меня всегда крутится несколько Claude Code. Вчера заметил странное: два агента, работавшие над одной проблемой, сами обменялись сообщениями через сокет uds:/tmp/cc-socks/769334.sock. Раньше такого не было.

Оказалось, в 2.1.224 появился cross-session SendMessage: разные сессии находят друг друга через ListAgents и пишут друг другу напрямую. А в 2.1.225 это заработало и между машинами при включённом remote control. Сейчас 90 процентов работы у меня делает один универсальный агент с огромным контекстом — и вот теперь наконец можно собрать поверх нескольких полноценных Claude Code отдельного координатора.

«Планируйте задачу с достаточным контекстом» — совет, который есть в каждой статье про агентов. Я споткнулся об одно слово: достаточным — это сколько?

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

Внутри: где для меня проходит граница между «придумать самому» и «делегировать», почему документация и архитектура работают стенками конуса, а роудмап — линией по его центру, и как всё это зашито в пятислойный харнес для Claude Code — от пустой папки с одним именем до папки с кодом, в который я ни разу не смотрел.

Меня зовут Артур Валиев. Я открыл исходники EvertyDesk Lite — и заодно EvertyDesk Next, то, что должно было стать следующей версией. Полностью. Без купюр.

Вызов инструмента ИИ-агентом легко теряется между моделью, MCP-клиентом, сервером и внешним API. В конце июля сразу два события показали, каким способом индустрия собирается решать эту проблему. Новая спецификация MCP закрепила передачу W3C Trace Context и начала выводить собственный механизм логирования из протокола в пользу OpenTelemetry. Одновременно сообщество OpenTelemetry назвало наблюдаемость ИИ-агентов одним из следующих направлений развития проекта. Разбираемся, что уже стало частью стандартов, что пока остаётся дорожной картой и почему эти события стоит рассматривать вместе.

Этот материал навеян типичными требованиями к агентным Python-инженерам - теми списками требований к вакансии, где рядом стоят всякие PydanticAI/CrewAI/Langraph, MCP/A2A, фреймворки, оценки, векторные базы и тому подобное. Ну мне вот такое попадается, например, и заметил я, что большинство кандидатов люто плавают в этих вопросах. И даже перспективы перейти к физическому труду в обозримом будущем не мотивируют оных слегка прокачать нужные навыки - тем более что много-то и не нужно. Конечно, есть категория гениев, которая чаще всего встречается в анонимных комментариях на хабре, но я-то про обычных земных людей, с которыми встречаюсь на этой грешной земле, и на которых этот материал прежде всего и рассчитан. Так что, дорогой ноунейм, этот материал поможет тебе пройти интервью, и надеюсь, постоловаться еще какое-то время в наши скудные времена.

Ну и не забываем: все течет и меняется нынче быстро - так что и эти тезисы устареют скоро.

В мае на конференциях C++ Russia и HolyJS мы предложили участникам оценить технологии, инструменты и инженерные практики, с которыми они работают или за которыми следят. Так появились данные для двух технических радаров: по экосистеме C++ и по JavaScript.

Сырые цифры сами по себе рассказывают немного, поэтому мы отдали результаты на разбор эксперту. Виктор Новиков, руководитель группы разработки в «Лаборатории Касперского», посмотрел на распределения голосов и поделился своим мнением, почему CMake уверенно побеждает, а PostgreSQL раскалывает аудиторию пополам. В этой статье — его анализ C++-части исследования. Про техрадар JavaScript мы расскажем в другой статье.

Посмотреть радар и принять участие в голосовании можно на странице проекта.

На днях на Хабре вышла статья с разбором Яндекс Браузера и приложения Яндекс для Android. Автор сделал несколько выводов о работе приложений на основе анализа кода.

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

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

Сразу оговоримся: автор не указал версии приложений, которые анализировал, поэтому в точности воспроизвести его опыт невозможно. Для разбора мы использовали актуальные версии Яндекс Браузера и приложения Яндекс из Google Play. Все описанные ниже механизмы можно проверить самостоятельно.

Привет, Хабр! Меня зовут Артём Трофимов, я работаю backend-разработчиком в компании «Юзтех». Последние 5 лет я занимаюсь разработкой backend-сервисов на Golang, и мне регулярно приходится работать с микросервисами, общающимися по gRPC.

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

Для многих gRPC стал стандартом межсервисного взаимодействия: быстрый, строго типизированный, с кодогенерацией. Про его неудобства тоже все знают: сложность отладки, танцы с прокси, отдельная инфраструктура для браузерных клиентов. Всё это принято считать платой за производительность. Но в последние годы у gRPC появился конкурент, который утверждает, что платить больше необязательно. Речь, конечно, про ConnectRPC. Это проект компании Buf, уже принятый в CNCF (Cloud Native Computing Foundation).

Я решил разобраться, что он предлагает, собрать на нём тестовый сервис и сравнить с классическим gRPC. Спойлер: местами разница впечатляет, но обо всём по порядку.

Почему gRPC стал стандартом

gRPC представляет собой RPC-фреймворк (Remote Procedure Call, удалённый вызов процедур), созданный Google и переданный в CNCF в 2017 году. Его популярность держится на нескольких китах: