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

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

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

Я начинал с простого AI-аудита заметок, а в итоге Vault Audit AI вырос в систему с двумя индексами, поиском по смыслу, Similar Notes, semantic duplicates и RAG по собственному хранилищу. В статье разбираю, как всё это устроено, что ломалось по дороге и почему почти 700 тестов всё равно не спасли от сюрпризов в реальном Obsidian.

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

Покрывают его тестами и пишут документацию.

Делают ревью, находят баги и исправляют их.

Параллельно работают над разными задачами.

Так почему же некоторые люди продолжают вручную набирать каждую строчку кода?

Почему они не хотят делегировать это ИИ агентам?

Вечером 02.09 у нас не вышел плановый пост в TenChat. В логе задачи планировщика — ничего осмысленного, просто ненулевой код возврата и алерт «слот не закрыт». Разбор растянулся на весь вечер, потому что там оказались не одна поломка, а три, и каждая маскировала следующую.

Команда — шесть разработчиков, полтора десятка параллельных проектов. Задачи жили в Excel, чатах и головах. В какой-то момент стало понятно, что «а кто это делает?» задаётся чаще, чем «как это сделать», — пора заводить трекер.

Дальше случилось то, что случалось у многих: мы честно прошлись по рынку, везде что-то мешало, и в понедельник я открыл пустой репозиторий. Во вторник команда уже вела задачи в своём трекере.

А самое интересное произошло между этими точками: канбан-доска — то, ради чего всё затевалось, — прожила в интерфейсе два с половиной часа. По истории коммитов видно точно.

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

Почему не готовое

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

Jira и Linear отпали первыми: данные о внутренних проектах не должны жить во внешнем облаке, а с обслуживанием российских аккаунтов у обоих вендоров всё сложно. Kaiten, YouGile, Weeek — приличные российские альтернативы, но это опять облако с чужим хранением, а по деньгам на команду — подписка за то, чем мы будем пользоваться на пять процентов.

Self-hosted Plane был ближе всего, но тащить и обслуживать чужой комбайн ради шести человек не хотелось.

GitHub Issues мы используем и любим, но тут споткнулись о главное: трекер нужен не только разработчикам. Руководителю нужны карточки, сроки и картинка загрузки — а не list view с лейблами. Фраза, убившая этот вариант, звучала так: «Issues не умеют пользоваться менеджеры». Это не претензия к менеджерам — это факт о интерфейсе.

В Go 1.27 encoding/json стал тонким слоем поверх нового encoding/json/v2. Собрал тулчейн из исходников, прогнал один и тот же код в четырёх конфигурациях и разобрался, почему разбор в any стал медленнее в полтора раза.

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

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

В дату релиза проект деплоится в прод. Но почему-то там все также один пользователь — сам создатель.

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

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

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

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

Начинал я как все, со связки Obsidian и Claude.

Первые свои выводы начал делать после того, как загружено было 219 353 файла. Я не знаю как для вас, но для меня Obsidian теперь - это просто программа для просмотра, а не то что я раньше про него думал. Вся ценность всего этого массива моих данных - в трёх вещах: обычные текстовые файлы на диске, ссылки, перелинковки между ними и агент, который читает и пишет их напрямую.

Как это у меня устроено сейчас и сколько токенов на это потрачено

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

Я поставил Obsidian, завёл хранилище, стал туда складывать заметки, документы, истории - да все подряд.

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

Из этого сбылось только то, что граф действительно приятно смотреть, и заметки удобно читать глазами. Но Obsidian это не база знаний. Для меня сейчас это программа для просмотра папки с текстовыми файлами. Она красивая, с графом и плагинами.

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

Откройте почти любую статью про FFI на Rust. С вероятностью девять из десяти там написано: «паника, вышедшая за границу с C, — это неопределённое поведение». Эту фразу повторяют пять лет, я и сам её цитировал, в том числе в одной из прошлых статей. Она перестала быть правдой почти два года назад: с Rust 1.81, вышедшего в сентябре 2024-го, такая паника гарантированно и предсказуемо завершает процесс.

Причём это не единственный протухший совет. Второй я поймал на себе буквально недавно. Есть присказка, живущая в статьях лет десять: поставь panic = "abort" — и бинарник похудеет процентов на десять. Написана она в релиз-нотах 1.10 за июль 2016 года, я повторил её в чужом пулреквесте, а потом сообразил, что ни разу не проверял. Собрал одну программу тремя способами, посмотрел в size -A и получил шесть десятых процента вместо десяти. Причём в сборке, где раскрутки быть не может по определению, преспокойно лежали одиннадцать килобайт таблиц, существующих исключительно ради раскрутки.

Но всё это финал истории, а начинается она с того, что паника — вовсе не «программа крякнулась». Это полноценный механизм исключений на той же машинерии, что и в C++. Раскрутка идёт не в один проход, а в два. Каждое исключение метится восемью байтами b"MOZ\0RUST", доставшимися в наследство от Mozilla, где Rust когда-то жил. catch_unwind ловит не через personality routine, как принято думать, а через отдельный компиляторный интринсик. А ещё есть дыра, про которую почти не пишут, потому что вылезает она только при раскрутке между двумя независимо собранными копиями стандартной библиотеки — и защищает от неё канарейка, живущая прямо внутри исключения.

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

Разберём подход «управляемого хаоса», который помогает превратить наставничество из передачи знаний в развитие самостоятельного мышления: через дефицит подсказок, работу с черновыми решениями и разбор собственных решений.

31 августа в 14:32 по Москве у нас вышла последняя штатная публикация. Дальше cron честно стартовал по расписанию, генератор успевал выбрать тему и написать текст, но в ленте ничего не появлялось. Так повторилось четыре раза: три запуска 1 сентября и утренний запуск 2 сентября.

LLM умеет отвечать на вопросы, но не знает особенностей вашего проекта и внутренней документации. В статье разберём, как с помощью RAG подключить собственные данные к модели: от подготовки документов и эмбеддингов до поиска нужного контекста и генерации ответов.

Привет, Хабр! Мы — Настя, Эвелина и Михаил — бэкенд-разработчики Т-Банка, пишем код на Scala и горим желанием его популяризировать. Мы собираем и агрегируем новости из разных источников, включая Scala Times, блог Petr Zapletal, добавляем дополнительные материалы и собственные комментарии. Мотивацию черпаем из желания развиваться и делиться полученными знаниями.

Всех поздравляем с наступившим сентябрем. Поздравьте учителей, переверните календарь — и вперед, читать наш дайджест! 

Приветствуем любую обратную связь! (づ ◕‿◕ )づ

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

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

24 коллектора, 111 ATS-досок компаний, 345 тестов, ноль API-ключей и ноль ИИ. Windows-exe, который считает совпадение резюме с вакансией и приносит 1–3 живых человека, которым можно написать самому. Внутри — архитектура, три бага, из-за которых я чуть не отправил письма сотрудникам чужих компаний, и раздел «честные ограничения», без которого это была бы реклама.

Всем привет! 

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

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

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

Давайте разбираться по порядку!

Пошаговое руководство по развертыванию JupyterLab на GPU-сервере. Рассказываем про настройку JupyterHub, драйверов NVIDIA, безопасности (Nginx/SSL), лимитов ресурсов и мониторинга.

2 сентября Qwen3.8-Max-0902 поднялась на первую строку общего зачёта Code Arena WebDev. На момент исходной новости модель набрала 1691 очко и опережала Claude Opus 5 Max на три пункта.

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

Разберёмся, что действительно произошло, как Code Arena строит рейтинг и достаточно ли первого места для смены рабочего инструмента. Собственного сравнительного теста я не проводил. Это разбор открытой методики, живой таблицы и документации Alibaba.

Полгода назад я начал писать веб-лист персонажа для D&D 5e, и почти весь код в нём пишет Claude Code. В какой-то момент лимиты подписки стали заканчиваться к обеду, и я распарсил транскрипты сессий, чтобы понять, куда уходят токены. Выяснилось: ответы модели — полпроцента расхода, а две трети съели 22 длинные сессии, в которых контекст рос на каждом шагу. В статье — скрипт замера на тридцать строк, разбор того, почему одна длинная сессия дороже пяти коротких, и восемь приёмов, которые я после этого внедрил: лимит сессии в Stop-хуке, карта кода вместо разведки грепом, запрет на повторное чтение файлов, вынос браузерных проверок в сабагента и рутины — на дешёвые модели.

Всем привет!

Почти каждый, кто работал с Git больше пары недель, хоть раз сталкивался с одной и той же путаницей: почему git add — это не сохранение, зачем нужен какой‑то отдельный индекс, если есть коммит, откуда вообще берутся конфликты при мерже, если мы просто оба поправили один файл. И почему иногда git status показывает файл как изменённый, хотя вы точно ничего не трогали.

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

В этой статье cначала покажем, как Git на самом деле хранит файлы и их изменения, что такое индекс и почему он существует отдельно от рабочей директории и коммитов. Далее — как устроены ветки на уровне данных, а не только как указатель текущей линии разработки. После этого разберём, как Git определяет, какие именно строки поменялись, и как из этого механизма следует слияние т.е merge и, самое главное, конфликты при слиянии.

Изучив модель, пройдёмся по основным командам работы с файлами: add, rm, mv, restore, diff, log, stash, работу с .gitignore и с большими файлами.

А в конце мы вам покажем, как это всё применяется на практике.