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

Всем привет, недавно я написал симулятор логических гейтов или вентилей на С++ (sfml для графики + sol2 для интеграции луа скриптов), которые можно программировать на луа таким образом: ```

Здравствуйте. Надеюсь, тут есть люди, которые интересуются вайбкодингом (хотя в списке тем рассылки такой не нашёл, что для меня странно), и уж точно есть те, кто занимается разработкой мобильных приложений. Да, сегодня эти слова очень часто встречаются рядом, что неудивительно. Я большую часть жизни проектировал фронтенд для b2b веб-приложений, но руки всегда чесались в сторону мобильной разработки, случай никак не подворачивался. А тут, как из рога изобилия, посыпались различные ИИ, которые способны после пары абзацев произвольного текста буквально за 5 минут сделать готовое мобильное приложение. Да, я не устоял и попробовал. И доложу я вам, это так. Приложение работает! Но, как говорится, есть нюанс: оно не сильно похоже на то, что вы себе представляли. А уж мне, как дизайнеру, было вообще грустно. Эту грусть я пока не победил, но победил кое-что другое, и это не про дизайн.

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

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

В Python при выборе библиотеки для работы с MQTT почти всегда приходишь к paho-mqtt. Это зрелый и самый популярный клиент, но его API построен на колбэках, а современное Python-приложение живёт в asyncio: FastAPI, фоновые воркеры, асинхронные клиенты и всё это в одном общем event loop.

В одном из IoT-проектов я столкнулся ровно с этим. Мне нужен был MQTT-клиент, который без сложной адаптации встраивается в асинхронное приложение и позволяет работать с подписками как с управляемыми объектами, а не через набор колбэков.

Главная проблема работы с LLM в реальном проекте — не качество модели, а контекст. Рассказываю, как с помощью RAG-индекса репозитория (векторы + граф вызовов) и плагина для Claude Code автоматически собирать правильный контекст по задаче из трекера — без ручного сбора и лишних токенов.

Заметил такую особенность во многих учебных статьях и туториалах: в популярных объяснениях паттернов часто не хватает оговорки, что ради упрощения объяснения в примере нарушены принципы SOLID.

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

Особенно часто это происходит с Factory Method. В этой статье мы разберём несколько популярных примеров этого паттерна, посмотрим, где именно возникает проблема, и обсудим альтернативы в реальных проектах.

У студенческих проектов часто есть проблема: после защиты они отправляются в архив. Студент получает оценку, преподаватель — отчёт, но результат редко кто-то использует.

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

Ранее мы уже рассказывали на Хабре, как начать контрибьютить в YDB и какие задачи могут подойти для первых опенсорс-вкладов. Эта статья — продолжение той же темы, но с фокусом на студентах: в ней мы делимся, как подбираем темы для дипломов и учебных проектов, как сопровождаем работу и почему стараемся делать так, чтобы результат был полезен не только на защите.

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

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

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

Что такое Git-конфликт?

Во-первых, Git позволяет нам, разработчикам, независимо работать над одним проектом в отдельных ветках. Пока изменения затрагивают разные файлы или разные независимые участки одного файла, Git обычно способен объединить их автоматически. Но что произойдет, если они затронут одинаковый участок файла? Давайте разберемся.

Наш загрузчик оказался слишком медленным. Требование было чётким: загружаться менее чем за 500 миллисекунд. Показатели оставались не менее чёткими: 720 миллисекунд. Мы отставали от нужного значения на 44%.

Это требование не было «мягким». Загрузчик должен был работать в промышленном контроллере, обязанном реагировать вскоре после включения питания. Каждая секунда времени загрузки — это потерянная продуктивность. В спецификации к изделию был указан максимум в 500 мс. Мы обязаны были их обеспечить.

Задача загрузчика была простой:

1. Инициализировать оборудование (UART, SPI, DDR-контроллер)

2. Загрузить ядро из флэш-памяти

3. Спарсить дерево устройств

4. Перейти ко точке входа ядра

Реализация казалась логичной: стандартные структуры данных из библиотеки C. Проблема выявилась при профилировании: 45% времени загрузки тратилось на malloc/free! В загрузчике всего с 64 КБ ОЗУ динамическое распределение роняло производительность.

Привет, Хабр! (И тебе, школьник, который пришёл на YoungCon за панамкой и Slava Marlow, и тебе, опытный разраб, который читает это и крутит пальцем у виска: «Зачем ты вообще туда поехал?», и тебе, представитель Яндекса, который, я надеюсь, дочитает это до конца.)

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

Поехали.

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

Вот очередная статья о том что метапрограммирование и код с шаблонами не такие уж и плохие.

Но я хочу рассказать вам историю одного детективного расследования в недрах крупного OpenBMC-проекта (экосистема серверных платформ swtSyst). Это история о том, как безудержное желание перенести всё в compile-time (constexpr), помноженное на ультрасовременный синтаксис C++20, породило идеальный «молчаливый баг» (silent failure). Он мог бы годами жить в продакшене, успешно компилировался, не выдавал ни одного ворнинга, но полностью ломал логику работы приложения.

Если вы любите метапрограммирование, шаблоны, операторы свёртки (fold expressions) и тонкости работы с памятью в C++ — устраивайтесь поудобнее. Мы отправляемся в шаблонный ад.

Алгоритм вывода цветного текста в консоль и как его можно написать на AutoHotkey. Погрузимся в язык, рассмотрим оптимизацию кода и улучшение читабельности (применимо к любому высокоуровневому языку).

Существуют готовые решения для измерения скорости работы на клавиатуре, например typespeed. Прекрасная программа с различными опциями.

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

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

Википедия

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

Наш веб-краулер потреблял 128 МБ ОЗУ только на отслеживание посещённых URL. На встраиваемом устройстве с 256 МБ это была половина всей памяти.

Задача краулера была простой: отслеживать посещённые URL, чтобы не краулить одну и ту же страницу дважды. После обработки 1 миллиона URL (средняя длина 80 байт) хэш-таблица, в которой хранились эти URL, разрослась до 96 МБ плюс оверхед.

«Можем ли мы обменять точность на память? Нас вполне устроит несколько дублированных операций, если это позволит сэкономить большой объём памяти», — сказал мне мой менеджер во время ревью кода.

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

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

Моё изначальное предложение прозвучало просто: «Ему вполне должно хватить одного ядра и 2 ГБ RAM. Это же всего лишь лаунчер». Хотя даже 2 ГБ казалось будто бы мало, ведь речь о продакшене, а не о каких-то экспериментах на личном ноутбуке. Но как раз в таком мышлении и кроется проблема. В процессе развития сферы вычислений мы постепенно перестали всерьёз воспринимать небольшие числа при обсуждении ресурсов, так как дорожим устойчивостью системы. Но в продакшене нужно, наоборот, распоряжаться ресурсами более аккуратно.

У меня обычно так: я довожу проект до прототипа, доказываю себе, что моя идея работает — и теряю интерес. Проект lifemodel — один из таких. Это ИИ-агент, которого я строил не как чат-бота, отвечающего на вопрос, а как «цифрового человека»: с сердцебиением, энергией и желаниями, которые возникают сами и сами побуждают его действовать. Прототип заработал. А потом, как обычно, мотивация кончилась. Этот пост — две вещи сразу. Для тех, кто пришёл за технической частью: разберу архитектуру проактивного агента — heartbeat-цикл, желание вместо опроса, многослойность с системой безопасности, душу и личность с конституцией и парламентом. Для тех, кто годами читает в режиме read-only — будет и вторая, честная часть: почему такие проекты застревают, и почему в одиночку их не вытащить.

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

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

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

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

В первых двух статьях я сделал две вещи и обе — честно.

Описал движок graphlens: как он берёт исходники на Python, TypeScript, Go, Rust и PHP и нормализует их в единый типизированный граф — узлы-символы, type-aware рёбра (CALLS, HAS_TYPE, INHERITS_FROM), детерминированные SHA-256 ID, межъязыковые границы.

И померил его: 936 прогонов на apache/superset (~400k строк, Python + TypeScript, граница /api/v1/...). Вывод — на задачах анализа влияния структурный граф бьёт grep по стоимости в 10–23 раза, а на точечных запросах разница почти нулевая.

Но была дыра, о которой я в обеих статьях молчал. Движок — это не продукт. Чтобы реально подключить graphlens к агенту, недостаточно pip install и API. Нужно написать кучу обвязки. Эта статья — про то, как я эту обвязку оформил в отдельный продукт graphlens-mcp, который ставится одной командой и сразу начинает работать. Он в alpha, он бесплатный (MIT), и его можно потестить на своём проекте за пять минут.

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

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

Третий кейс, человек работает 1–2 месяца, классный. Начинаю платить выше рынка ЗП. А потом раз, и исчез. Пытаюсь дозвониться и т.д. В итоге он через неделю мне говорит, что у тебя работа такая, что я боялся проспать, и начал принимать спиды, и через неделю так устал, что уснул на несколько дней. В итоге его брат приехал и сказал, что ему ЗП давать нельзя, всё через него, иначе он сторчится.

Кейс четвёртый, потом был случай: нахожу нормального программиста, работает качественно и т.д. Уговор, что 1–2 месяца, до получения инвестиций, я не смогу ему платить. В итоге он хорошо работал, я его лично встретил в Астане в аэропорту, прокатил на ЛРТ, потом заказал такси. Он хоть и отбивался, мол, у него заказ такси не работает, он забыл карты в Бишкеке, но мне было всё равно, он гость, и я его встретил. Отдельное спасибо ему за пахлаву и другие сладости, что он моей жене привёз и мне. А потом, на следующий день, сказал, что не может дальше работать на таких условиях.