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

Встречайте FancyArgumentParser

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

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

Когда вы пишете вот такую строчку:

const N: u64 = fib(50);

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

И вот вопрос, на который мало кто может ответить с ходу: а кто конкретно это исполняет? Где живёт тот интерпретатор? Почему 255 + 1 в const падает с ошибкой компиляции, а в рантайме просто паникует? Почему можно посчитать таблицу из тысячи элементов циклом, но нельзя написать if a < b для дженерика? И почему 0.0 / 0.0 в const официально разрешили вести себя недетерминированно?

Погнали разбираться.

Меня зовут Самир, мне 16 и я хотел бы поделиться с вами одним из моих текущих проектов: Veo (https://github.com/SamirShef/veolang). Veo это системный язык программирования. Я хочу использовать его для написания своих программ в будущем. А ещё я разрабатываю его потому что мне интересны комплияторы и потому что мне нечего делать.

Я больше года занимаюсь компиляторострением.

Привет, на связи Влада, веб-специалист ЮMoney. Год назад я рассказывала на Хабре, как контент-менеджеру пригодятся терминал, Git и несколько десятков строк кода.

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

Расскажу, как из одного bash-скрипта вырос набор внутренних инструментов для контент-команды. Идеи пригодятся техническим писателям, контент-менеджерам и всем, кто регулярно работает с Markdown, XML и CMS.

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

В моем, весьма специфическом случае такой нереализованной мечтой детства долгое время оставался... компилятор Watcom, дорваться до которого удалось лишь спустя почти тридцать лет.

Рассказываю об этом удивительном проекте.

Уважаемые читатели, в этой статье я хочу рассказать о проверке обещанного регресса LINQ в .NET 10 — и представить свои выводы.

В dotnet/runtime с лета висит issue #117717: после перехода на .NET 10 метод с First(предикат) просел к девятке — у автора issue на Intel 13-го поколения до 19%, у Энди Эйерса из JIT-команды на Zen 4 порядка 10%. Причину команда назвала сама: связка PGO и инлайнинга, делегат предиката перестал инлайниться.

Решение тоже озвучили: в десятке чинить не будем — сломаем другое, переносим в .NET 11. Был частичный фикс (PR #117816), после которого issue переоткрыли как #119425. Десятка при этом LTS, и в комментах закономерный вопрос: обновляться на десятку или ждать одиннадцатую.

Уважаемые читатели, в этой статье я хочу рассказать о том, что происходит внутри values.Sum() в современном .NET — там нашлись векторные инструкции, контроль переполнения и список процессоров, которым рантайм намеренно ограничивает ширину вектора, — и представить свои выводы.

В прошлых статьях серии самописные циклы уже проигрывали BCL в поиске по строке, JIT сам выкидывал проверки границ, а foreach прятал аллокации. Тут случай интереснее: values.Sum() — это LINQ, который при оптимизации первым делом меняют на цикл.

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

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

Мы вынесли компактную карточку банковской карты в entities/card/ui: маска номера, баланс и статус — решение казалось очевидным.

Через два спринта в карточке появились действия «заблокировать карту» и «изменить лимит». В итоге entity начала импортировать features/block-card, features/change-card-limit и проверку прав доступа мимо public API. Когда ту же карточку понадобилось показать в выборе счёта списания, вместе с ней приехали ненужные зависимости и проверки ролей.

Пользовательских инцидентов не случилось, но исправление отняло время. В entity оставили чистый CardPreview, сценарии подключили выше, композицию дашборда перенесли в widgets/card-summary, затем заново прогнали ролевые тесты.

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

Какие будущие изменения выбранная граница позволит оставить локальными?

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

Я собираю своего кодинг‑агента поверх моделей OpenAI. Базовый агентный цикл написал сам на Pydantic AI, и он быстро заработал. А потом начались сложные узлы: как сжимать распухший контекст, как не дать агенту делать заново уже сделанное, как понять, что он правда закончил, а не выдохся. На каждом таком узле я застревал и шёл смотреть, как это решают взрослые. Благо исходники Codex, OpenCode и Pi лежат открыто, а архитектуру Claude Code Anthropic описывает сама.

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

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

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

В этой статье мы подробно сравним три ведущих бэкенда для инференса: vLLM, LMDeploy и экосистему NVIDIA Triton Inference Server в связке с TensorRT-LLM. Мы разберем, как они управляют памятью, какие методы квантования используют и как распределяют запросы, а также оценим результаты их бенчмарков на актуальных архитектурах NVIDIA Hopper и Blackwell.

Это моя первая статья на хабре, потому что хотелось поделиться своим опытом объединения знаний из разных сфер, ну и в целом, рассказать, что вот и такое бывает.
Для начала вводная, я почти всю послеуниверситетскую жизнь работал в энергетике, а конкретно в службе релейной защиты в Ленэнерго. Но ближе к началу 22 года стал задумываться о вечном, ситуация стала ухудшаться и я, как тогда было «модно», тряхнул стариной (благо в школе и универе увлекался программированием) и начал вспоминать как кодить. Довольно быстро попал в коммерческую разработку, специализирующуюся на урбанистике и застройке, где успешно и работаю по сей день.

В определенный момент мне стало жалко, что столько лет накопленного опыта в энергетике улетают в трубу и я решил, что хорошо было бы объединить опыт, полученный в РЗА с опытом, полученным в разработке. Т.к. основной проект на работе был связан с генерацией застройки, работой с картами и алгоритмами генерации, я решил особо не мудрить и сделать что-то похожее, но связанное с подстанциями. В нашем проекте электрические сети были условными и шли из внешней границы территории, из тумана войны. И я подумал, в реальности ведь у нас нет волшебных питающих сетей – городские районы часто питаются через расположенные неподалёку понижающие подстанции. Поэтому хорошо было бы, чтобы пользователь, который задумал какое-то строительство, и который понимает какая мощность ему требуется, чтобы запитать новый район, мог с ходу за пару секунд сгенерировать несколько вариантов расстановки условной и усредненной типовой понижающей подстанции с основным оборудованием, с кабель-каналами, охранными зонами и необходимыми расчетами и прочими штуками, чтобы понимать реально ли это на данной территории и что ему для этого потребуется. Потребуется ли это в действительности меня не очень волновало, хотя я знал, что есть подобные программы для проектантов, но идея уже запустилась в мозге и просто так уже оставить было нельзя. К тому же получив схему подстанции, можно было реализовать другие функции для других сфер. Т.е. первое, что специалист по территориальному планированию мог бы быстро проверить, помещается ли подстанция на разных участках и заранее заметить проблемы. Второе, для сетевой компании или заказчика генератор мог бы быть полезен на стадии обсуждения технического присоединения. Например, чтобы сравнить несколько заранее заданных вариантов класса напряжения и типовой схемы, оценить требуемую площадь, ожидаемые токи КЗ и возможные ограничения по оборудованию. Ещё одно возможное применение (и наверное чуть-ли не главное) - это обучение. На готовой схеме можно показывать и объяснять, как расположение оборудования связано с электрической моделью, что меняется при включении секционного выключателя, откуда берутся токи короткого замыкания, почему для проверки защиты выбирается определённый режим и как первичная схема затем представляется в файле IEC 61850 SCL для каких-нибудь цифровых подстанций.

Strict‑режим включён, схема валидна, ответ успешно парсится — а в проде всё равно всплывают None, пропавшие ограничения и аргументы инструментов не тех типов.

В статье разберём пять ситуаций, где Structured Outputs создают ложное ощущение надёжности, и посмотрим, какие проверки действительно стоит добавить в LLM‑пайплайн.

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

В Wails основными файлами, с которыми проходит 90% работы это index.html, styles.css, main.js, app.go. Остальные файлы мы либо не трогаем, либо настраиваем один раз в самом начале.

Для фронтенда я использовал стандартный html, css, js без современных фреймворков (так как я в них не разбираюсь). Frontend часть подробно рассматривать в этой статье не планируется, a html будет использоваться только чтобы показать, где используются js функции.

Приветствую, Хабравчане.

Предлагаю вам, окунуться в ретро программирование на С++ 23 и модулях. Да вы не ослышались. Это вполне возможно и я готов вам рассказать это и показать на практике.
Но сначала мы напишем движок для моей любимой игры Arcanum. Но мы не остановимся на спрайтах и старой графике, я добавлю 3D.

Если хотите узнать как. Заходите. Я рад всем.

Программисты, работающие с языком C, несомненно, узнают стандартную функцию malloc(). Это главный аллокатор памяти в языке, который тесно связан со всем известными ошибками сегментирования. Функция malloc() – именно то средство, при помощи которого программы приобретают память во время выполнения. Зачастую она также превращается в основной инструмент создания объектов и управления ими. Учитывая такой центральный статус malloc(), удивлён, что большинство программистов обращаются с ней как с чёрным ящиком. Этот пост призван немного исправить ситуацию, и в нём рассказано, что именно происходит под капотом. Также рассмотрим одну из возможных реализаций этой функции.

Сегодня практически любую задачу компьютерного зрения пытаются решить нейронной сетью. Геометрическая ректификация документов — не исключение: современные модели умеют распрямлять даже скомканные листы бумаги.

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

В Smart Engines мы пошли другим путем: вместо универсальной нейросети построили математическую модель документа, сложенного втрое. В результате получили алгоритм, который не только превосходит современный геометрический трансформер DocTr по качеству, но и работает до 60 раз быстрее.

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

Локально Testcontainers запускается за секунды, тесты стабильно зелёные, а в CI тот же набор начинает падать в трёх запусках из ста и каждый раз по новой причине.

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

Уже с первого курса университета — или даже раньше — вы могли догадаться, что писать arr[len(arr)] — плохая затея. И вряд ли так кто-то может ошибиться, правда? Мы тоже так думали, пока не проверили 1000 проектов.

Как известно существуют учебно-тренировочные электронные платы серии Nucleo. Там всегда есть вмонтированный программатор ST-link. Эти платы дешевы и очень удобны для отладки большой прошивки по частям. Однако родной программатор ST-Link долго прогружается и пошаговая отладка часто срывается прямо из-под IDE. Потом нет способа перезагруpить прошивку из-под отладчика ST-link. В связи с этим возникла потребность отлаживать прошивки на плате другим программатором: отладчиком Segger J-link.