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

Я разработал плагин, чтобы помочь разработчикам Telegram ботов.

Он работает поверх aiogram – не нужно будет переписывать уже имеющийся код.

И если ты хоть раз писал ботов, эта статья сэкономит тебе много времени и нервов.

Всем привет. Меня зовут Александр, у меня сервисный центр по ремонту техники.

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

Долгое время жил на облачных CRM, от работы в excel создавая каждый раз папку с датой и файлик с данными клиента и заявкой, далее что то удалось сделать на Microsoft Access, далее полноценно на лет 5 перешел на remonline и вроде все устраивало но очень долго они вводили новые функции, и как всегда те которые мне не нужны были, ну и далее всем известные события и они отвалились навсегда из российского сегмента, потом перешел на helloclient тоже просидел пару лет пока не начали вводить белые списки, к сожалению из за постоянных проблем с сетью у провайдера при включении белых списков система был недоступна часами, и в голове уже много лет была мысль создать свою CRM для себя , с возможностью быстрой доработки под конкретные задачи и хотелки мастеров и меня, сначала решил учить языки программирования), около года учился на пайтон разработчика, и под конец понял что это затянется надолго и решил использовать Cursor для дополнения кода, ну и затем вовсе перешел на полноценную работу в агенте , и спустя 4 месяца работы выпустил релиз в работу, мастера оценили , мы сидели и придумывали новые фишки на лету чтобы ускорить приемку , выдачу, шаблоны печати и расчет зарплаты, от идеи до ее реализации одна ночь, вечером мы что то обсуждали по нововведениям и уже утром все было готово, так однажды из за отключения сети мы придумали чат в браузере со звуком сообщения Аськи), до сих пор многие клиенты думают что мы используем ICQ в работе.

Хороший инструмент должен быть незаметен, и разработчикам следует к этому стремиться.

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

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

FrozenDictionary сделан под словари, которые заполняют один раз при старте, а дальше только читают. Замерил на четырёх машинах и трёх рантаймах — разброс вышел от ×0,76 до ×1,9, и зависит он не от версии .NET, а от того, сколько ключей и как они устроены.

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

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

OpenRouter - самый крупный и известный в мире агрегатор нейросетей. C 26 июля стал пытаться блокировать пользователей из России. Вцелом, с учетом простоты регистрации и возможностью оплаты криптовалютой - это не такая большая проблема. Но только вот пользование сервисом из 3 букв может добавлять определенные задержки к ping-у. А если на агрегатор завязано достаточно много сервисов, то сервис из 3 букв должен работать как часы. Эту проблему можно решить именно так, но откровенно говоря ценность OpenRouter как агрегатора в данном случае сводится практически в нулю, поэтому я решил поискать альтернативу - кто уже озаботился решением этого вопроса, попутно получив и другие полезные плюшки, вроде использования российских моделей если в агентах светит 152 ФЗ (строго для этих запросов) и более простой оплаты без переводов на зарубежную карточку.

Для тех, кому лень читать, краткий итог ниже:

AI-агенты отлично решают локальные задачи, но часто теряют связи между частями большой кодовой базы. Из-за этого изменение одной функции может незаметно сломать frontend, backend-роут, сервис, repository, background task или тест.

В статье разбирается CodeSlicer — локальный CLI, MCP-сервер и визуальный анализатор, который строит проверяемый граф влияния проекта. Он связывает функции, классы, DI-провайдеры, HTTP-endpoint’ы, frontend-компоненты и тесты, сохраняя evidence chain, provenance, confidence и причины каждой связи.

Показывается полный pipeline: inventory, extraction, semantic resolution, support packs, unknown regions, mutation testing, runtime observation и impact analysis. Отдельно разобрано, почему система не должна превращать предположение AI в подтверждённое ребро.

На размеченных Python-сценариях протестированы 21 тестовый сценарий, 29 mutation-сценариев, 20 обязательных semantic edges, 0 false positive и 0 false negative. Для TypeScript и frontend-backend bridge проверены 12 сценариев, 15 мутаций и 4 cross-language цепочки с endpoint precision 1.0.

Также рассматриваются интеграции с AI-агентами через CLI, MCP и skills, отличие CodeSlicer от обычных графов кода и дальнейшее развитие проверенного registry библиотек

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

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

Привет от команды Яндекс Практикума! Приёмная кампания в онлайн-магистратуру «DevOps‑инженер облачных сервисов» ИТМО в партнёрстве с Практикумом уже идёт. Рассказываем, что входит в программу, что нужно, чтобы поступить в 2026 году и как устроено обучение. 

Отмена задачи кажется простой, пока сервис не зависает при остановке, таймаут не оставляет запрос работать в фоне, а CancelledError исчезает внутри обработчика исключений. Разберём, как устроена кооперативная отмена в asyncio, где ставить точки ожидания и как использовать TaskGroup, timeout и shield, чтобы задачи завершались предсказуемо.

На планировании оценивают задачу: «добавить бейдж VIP на карточку клиента». Разработчик открывает CustomerCard.tsx, молчит и говорит: «Дня три». Никто не смеётся — все открывали этот файл. В нём почти семьсот строк, и он умеет всё: грузит клиента и его заказы, кэширует, валидирует форму, различает три роли, экспортирует CSV и не падает. Сцена собирательная, но файл — нет: для этой статьи я вырастил его сам, шаг за шагом, и каждый шаг сохранил.

Вопрос к такому файлу — не «почему он большой?». Вопрос — «сколько у него причин измениться и кто их считает, кроме ревьюера?»

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

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

Правило из CLAUDE.md агент забывает на длинной сессии - это текст, а не механизм. Я разобрал слои дисциплины Claude Code и прибил критичные правила хуками: три гейта, после которых коммит без свежего зеленого прогона тестов не проходит, правка теста поднимает флаг, а завершить работу с грязными тестами нельзя. Под катом механика хуков, код всех трех гейтов с живыми прогонами и эксперимент, где гейт пересилил прямую инструкцию пользователя.

Структура в роли ключа Dictionary — частый случай. Забыл IEquatable — и каждый TryGetValue в 4,4–5,7 раза медленнее, плюс 96 байт в куче на каждый поиск.

Проверил на четырёх машинах и трёх рантаймах, снял дизасм FindValue и разобрал, откуда берутся ровно три упаковки, почему override Equals не спасает и при чём тут хэш record struct. Сам рантайм этот разрыв не закроет — и это не баг.

Пять пробелов, которые не видны на архитектурных блок-схемах.

Пользователь нажимает «Place Order» (Сделать заказ).

API возвращает 200 OK. Заказ появляется в базе данных. На странице оформления заказа выводится сообщение «success» (успех). Извне всё выглядит нормально.

А потом в службу поддержки прилетает тикет.

Агент проходит все проверки и сносит то, что трогать было нельзя. Промпт это не лечит — лечит среда вокруг модели. В ноябре я начал собирать такую среду и называл её просто фабрикой разработки. Меньше чем за год из неё выросло почти десять конвейеров, а у занятия, оказывается, есть название: harness engineering. Рассказываю, как оно росло, и показываю схему и скелет в github.

В первой части мы успешно вскрыли чёрный ящик LINQ: написали Where вручную, разобрались, как компилятор превращает yield return в конечные автоматы, и посмотрели на методы с частичной буферизацией. Но LINQ был бы не собой, если бы на этом всё закончилось.

Во второй части переходим к «тяжёлой артиллерии» — OrderBy, GroupBy и Join. Эти методы вынуждены нарушить главный завет ленивых вычислений: они материализуют данные в памяти, прежде чем отдать хоть один элемент. Но как именно?

После этой статьи LINQ перестанет быть чёрным ящиком: вы будете точно понимать, сколько памяти съест каждая цепочка методов и в каком порядке следует вызывать эту цепочку.

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

Важно: я пока не нашел времени и сил подготовить скрипты сборки пакетов для разных дистрибутивов и не придумал название для форка (GPL позволяет использовать старое название, но с указанием что это форк и даты отпочковывания)

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

В форке Midnight Commander с амбициозным номером версии v6.0.1 появилось несколько крупных нововведений:

Локальный запуск dev-окружения в крупном проекте может превратиться в отдельный квест: несколько процессов, Docker-контейнеры, переменные окружения, порядок старта, ожидание готовности сервисов и отличия между ОС. Даже если у вас есть подобный опыт, это может быть неудобно, долго и утомительно. Новичку же обычно не обойтись без длинной подробной инструкции.

Привет, Хабр! На связи Сергей Зверьков, старший разработчик в «Лаборатории Касперского». Хочу рассказать, как мы решили эту проблему, написав собственный open-source-инструмент — Runium. Суть его в том, что он позволяет описать dev-окружение в JSON-файле. После этого проект можно запускать, останавливать и проверять одной командой.

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

Всем привет! На связи Михаил Поливаха, технический лидер проекта Axelix.

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

А что насчет натуральных ключей в БД? Если, допустим, у меня есть поле, по которому я могу явно идентифицировать запись, стоит ли его использовать как Primary Key?

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

Несколько месяцев пилил pet-проект, который зашёл дальше, чем планировал: файловый ASGI-фреймворк, где дерево папок — это и есть таблица роутов. Сегодня вышла версия 1.0 — с адверсариальным security-аудитом (нашёл у себя pickle RCE и CSWSH), 2329 тестами и нативным async на PostgreSQL. Рассказываю, что внутри и что было больнее всего сделать правильно.

Promise, setTimeout и async/await часто работают совсем не в том порядке, которого ждёшь по коду, а тяжёлая синхронная функция способна заморозить весь интерфейс. Разберём модель цикла событий, которая объясняет эти эффекты и помогает понимать, где возникают блокировки, гонки запросов и лишние задержки.