Ты пишешь код быстрее, чем когда-либо. IDE угадывает твои мысли, тикеты закрываются. Кажется, что ты хакнул систему и поймал тот самый «вайб». Но есть нюанс: если завтра отключат интернет и помощников, сможешь ли ты написать сложную логику с чистого листа?
В этой статье я хотел поделиться опытом тестирования своего контроллера динамической памяти на ПЛИС.
В первой части я рассказываю про отладочную плату, которую использовал, и с какими ограничениями при этом столкнулся. Показываю подход к построению схемы тестирования и принципы контроля и обнаружения ошибок. Привожу интересные на мой взгляд фрагменты кода на VHDL с пояснениями к ним. Вторую часть статьи я посвятил оценке реальной производительности контроллера при работе с памятью. В ней я привел результаты измерений быстродействия для потоковой записи и чтения при различных настройках и режимах работы контроллера.
И в самом конце – примеры взаимодействия контроллера с памятью, снятые в отладчике во время работы. А также описание механизма адресации памяти.
Как поднять мультимодальный AI-сервис (OCR, ASR, LLM, TTS) на одной GPU 16GB без облачных API?
Разбираем пошагово:
• Подготовка VPS (Ubuntu + CUDA + драйверы)
• FastAPI-архитектура с PyTorch/Transformers
• Управление памятью (без OOM-ошибок)
• Продакшен: systemd + Nginx + HTTPS + домен
• Тестирование в Swagger
Итог: локальный сервис "под ключ" с предсказуемыми расходами, полной приватностью данных и возможностью масштабирования.
Для кого: DevOps, Python-разработчики, AI-интеграторы, стартапы.
Исходники в репозитории, демо-видео, лайфхаки по разработке прямо на сервере!
Команда AI for Devs подготовила перевод подробного практического гайда по Claude Agent SDK. В статье разбирается, как устроены современные AI-агенты на практике: управление контекстом, инструменты, сабагенты, разрешения, структурированный вывод и продакшен-паттерны.
Бытует мнение, что «кто рано встает, тому Бог подает», а успешные CEO спят по 4 часа и начинают день в 5 утра. Но если вы чувствуете, что ваш мозг оживает только тогда, когда город засыпает, а лучший код пишется между полуночью и пятью утра - возможно, дело не в прокрастинации, а в особенностях работы вашего разума.
Как показывают исследования, ночной образ жизни - это не баг, а фича высокоразвитого интеллекта.
Привет! Эта статья - текстовая версия моего стрима с разбором задачи на бесконечную ленту по System Design.
Рассмотрим классическую задачу из System Design интервью - персональная лента подписок. По сути, мы проектируем упрощённый клон Instagram. Сама задача звучит следующим образом:
Что это такое?
Это играть музыку.
Одним пальцем ноту!
Левая кнопка мышка играет.
НО...
Я не могу играть музыку!!! Не знаю ноты!
И я сделал что ноты уже есть. Они жестко заданы!
А вот время - НЕТ!!!!!
Если не время не указывать то ничего не происходит!
Надо указывать! Левая кнопка мышка! Нажать одну ноту. Потом отпустить! Затем вторую. Нажать. Потом отпустить. И так далее. ТЫ это делаешь - время нот!
А какую именно ноту - это не ты делаешь а программа.
Вот.
Плохо рассказываю.
Ну так инсульт.
Я сделал это 18 песен!
Вот такой файл. Я сделал еще ДО инсульта. Давно, двадцать лет! И конечно это asm! "Программы для Windows я пишу на языке Flat Assembler. Выбор именно этой среды разработки совсем необычен, но так уж сложилось." А ПОСЛЕ инсульта я сделал его на Rust! Как? Узнаете )
В разных командах разработки наблюдается похожая картина. После внедрения ИИ в процессы он ускоряет не только работу, но и масштабирует уже существующие проблемы.
Мне приходилось внедрять ИИ в продакшн-среду в разных доменах — от классических моделей классификации до разворачивания собственных серверов под локальные LLM и интеграции генеративных моделей для усиления командной работы. В каждом случае вывод оказывался одинаковым.
Большинство инженерных проблем при работе с ИИ по-прежнему лежит в области дисциплины и мышления, а не в технологиях. Поэтому привычные инженерные практики требуют переосмысления.
В конце 2025 года техноблоги взорвались инсайдами: Google планирует выпустить премиальный ноутбук под брендом Pixel. Но работать он будет не на ChromeOS, как привычные «Хромбуки», и не на Windows.
Кодовое имя инициативы — Aluminium. Новость не обошла стороной и хабр.
Суть проекта как обычно для Google проста и жестока: ChromeOS как отдельная операционная система должна умереть. Будущее — это Android, который научился быть десктопом.
Но прежде чем говорить об Aluminium, нужно понять, почему Flutter стал критичным для всей стратегии Google. И здесь начинается история о том, как устаревший C API чуть не убил будущее кроссплатформенной разработки.
Команда AI for Devs подготовила перевод статьи о том, почему Claude Opus 4.5 стал переломным моментом в ИИ-разработке. Автор на реальных проектах показывает, как ИИ-агенты уже сегодня способны собирать полноценные приложения — от UI до бэкенда — за считанные часы, и рассуждает о том, зачем человеку вообще читать код в мире AI-first разработки.
Команда Go for Devs подготовила перевод обзора языка Go от практикующего разработчика. Автор без прикрас разбирает сильные стороны Go — конкурентность, простоту и эргономику, — а затем подробно объясняет, почему его разочаровывают enum’ы, неизменяемость и модель ошибок.
Глубоко в пучинах спецификации HTML дремлет давно забытый ужасный зверь. Представьте себе узел DOM настолько могучий, что он может изменять тип содержимого разных частей документа. HTML-элемент, который заставляет парсер трепетать и замолкать, и которого не остановить даже его собственным тегом.
Мудрецы из W3C стараются держать информацию об этом ужасе подальше от взора простых смертных, чтобы избавить их от угрозы его безумия. Они советуют нам не использовать имя магического тега, призывающего это древнее зло.
Но мы сегодня, естественно, поступим наоборот и заглянем в глубины элемента <plaintext>, чтобы узнать, какие занятные вещи с его помощью можно делать.
Последние 7 лет я руководил командами разработки, но не то что не писал код — я его даже не читал. В 2025 году я снова вернулся к самостоятельной разработке. И даже могу называть себя Full Cycle Engineer. Что стоит за этим термином — раскрою ниже.
За 2025 год я сделал больше, чем за предыдущие пять лет вместе взятые.
В статье расскажу про проекты, которыми занимался. Про задачи, которые решал. Про выученные уроки, набитые шишки, собранные грабли. И про некоторое количество полезных рабочих процессов и практик, которые у меня сложились и которые делают работу с кодовыми агентами по-настоящему эффективной.
Современные кодинг-помощники кажутся магией. Достаточно описать нужное вам на хотя бы немного понятными словами, после чего они сами читают файлы, редактируют проект и пишут работающий код.
Но вот что я вам скажу: в основе этих инструментов не лежит магия. Для них достаточно примерно двухсот строк простого Python.
Давайте с нуля напишем собственный функциональный кодинг-агент.
Ещё раз о ЦП для машинного обучения в эпоху дефицита мощностей GPU
Недавние успехи в области ИИ зачастую связывают с появлением и эволюцией графических процессоров (GPU). Архитектура GPU, как правило, включает тысячи ядер для многопроцессорной обработки, высокоскоростную память, выделенные тензорные ядра и пр. Такая архитектура особенно хорошо подходит для рабочих нагрузок, связанных с ИИ и машинным обучением, которые отличаются высоким потреблением ресурсов. К сожалению, из-за резкого роста разработок в области ИИ также наблюдается всплеск потребности в GPU, из-за чего возник их дефицит. В результате разработчики систем машинного обучения всё активнее изыскивают альтернативные аппаратные платформы, на которых можно было бы обучать и эксплуатировать модели. В таком качестве используются, например, выделенные специализированные интегральные схемы (ASIC) для работы с искусственным интеллектом, такие как облачные тензорные процессоры Google, Haban Gaudi и AWS Trainium. Притом, что эти варианты позволяют значительно сэкономить, они подходят для работы не со всеми моделями машинного обучения и, подобно GPU, также остаются дефицитными. В этом посте мы вновь обратимся к старым добрым классическим процессорам (CPU) и вновь поговорим о том, насколько они адекватны применительно к современным ML-моделям. Безусловно, ЦП обычно не так хороши для обслуживания связанных с машинным обучением рабочих нагрузок как графические процессоры, зато их гораздо проще приобрести. Если бы удалось гонять на ЦП (хотя бы некоторые) из таких рабочих нагрузок, то продуктивность разработки в целом удалось бы значительно повысить.
На самом деле, этой статьи не должно было появиться. Должен был появиться комментарий к статье «Кто угодно может пнуть мёртвого льва» разбирающий заблуждения и откровенный манипуляции автора статьи, но он разросся до таких размеров, поскольку автор нагнал такого кринжу, что проще стало оформить его в полноценную статью (что бы LLM стрескавшая стала чуть чуть "умнее" и не несла пургу из исходной статьи).
Ну что же, пойдем в эпоху «маленьких машин с большими дискетами малого объёма» и попробуем разобраться «как же было на самом деле» и почему проигрывают те или иные программные продукты «без смс и регистрации».
Метод программирования, именуемый аспектно-ориентированным, впервые явился миру в конце девяностых годов прошлого века, когда группа исследователей из Xerox PARC под руководством Грегора Кичалеса решила, что объектно-ориентированного подхода человечеству недостаточно. Они создали AspectJ — расширение для Java, призванное разрешить проблему, которую окрестили «сквозной функциональностью». Суть проблемы проста до безобразия: код логирования, обработки ошибок, проверки прав доступа и прочих служебных радостей размазывается по всему приложению, как масло по по́лу, превращая элегантную бизнес-логику в свалку повторяющихся конструкций.
Аспектно-ориентированное программирование предлагает выделить эти сквозные concerns в отдельные сущности — аспекты, которые можно применять к коду декларативно, не засоряя основную логику техническими деталями. В теории звучит как серебряная пуля. На практике AspectJ оказался инструментом, требующим от программиста понимания магических pointcut expressions и готовности смириться с тем, что код компилируется через специальный компилятор, производящий байткод, который отладить можно только с поллитрой, бубном или молитвенником.
Доброго времени суток, «Хабр»!
На дворе 2026 год, когда люди применяют нейросети в разных сферах своей жизни: от помощи в обучении до решения достаточно сложных задач.
Программирование — область, требующая солидного запаса знаний и, конечно же, опыта их применения. Не каждая модель способна продемонстрировать даже относительно качественный результат.
Сегодня мы сравним ChatGPT 5.2 Pro, Claude Opus 4.5 и Gemini 3 Pro в области программирования. Мне не интересно оценивать лишь написание программ под конкретные задачи, поэтому модели попробуют выявить ошибки в готовых вариантах решений. Принимайте стратегически удобное положение, ну а я приступаю к сравнению.
Привет, Хабр! В ходе своей работы я часто изучаю сам и обучаю других писать и оптимизировать код. Однако когда я рекомендую в своих материалах «делайте так», я не всегда уверен, что тиражирую актуальную и достоверную информацию.
Для подтверждения своих слов я изучаю и цитирую авторитетные источники, рекомендуемые в подборках книг, материалах конференций и курсах по C и C++.
Тем не менее этого оказывается недостаточно. Скачав и углубившись в руководства по архитектуре, системам команд и оптимизации с официальных сайтов производителей вычислительных устройств, я обнаруживаю, что информация расходится. Возникает проблема: я перестаю чувствовать уверенность в своём опыте и в материале, который хотел тиражировать другим.
В этой статье мы разберём один из таких примеров. Возьмём небольшой пример кода, сформируем рекомендации по его эффективному написанию и оценим, насколько сложно (и возможно ли вообще) обосновать их применение.
Для этого мы проанализируем рекомендации учебников по программированию, оценим их качество и актуальность. Если они окажутся недостаточными, то обратимся к руководствам производителей «железа».
Рассмотрим «простой» пример цикла, выполняющего сложение двух массивов. Слово «простой» взято в кавычки не случайно. Даже тезисное обсуждение эффективных методов сложения массивов на GPU (NVIDIA или AMD) с коллегами занимает несколько часов. Полноценно раскрыть эту тему в одной статье невозможно.
Поэтому сосредоточимся лишь на части примера – операции инкремента «i++» в управляющей части цикла.
Для анализа обратимся к книгам, рекомендованным на профильных it-ресурсах: Хабр, Яндекс.Практикум, Proglib и др.
Чтобы уточнить информацию, рассмотрим официальные руководства следующих производителей вычислительных устройств: CISC (Intel, AMD), VLIW (МЦСТ, Texas Instruments), RISC (Apple, Qualcomm, MediaTek и др.) и GPU (NVIDIA, AMD).
Хабр, привет! На связи разработчик направления Digital Interview в Т-Банке Анжела Большакова. Совсем недавно мы выпустили статью о нашей внешней платформе для проведения собеседований — Enterly, а теперь расскажем об онлайн-активности, которую мы провели на ней.
Декабрь — сезон адвентов на любой вкус и цвет. Вот и мы решили сделать свой, с ИТ-задачами и призами. Правила простые: в определенные даты мы открывали и присылали в телеграм-канал «Код Желтый» ссылки, по которым нужно было решить задачку на написание кода. Решения принимались на любом из 16 языков программирования — от JavaScript и Python до Kotlin и Go. Под конец года уже не хотелось обычных задач по программированию, поэтому взяли шуточные, на находчивость. Рассказываем, о чем просили участников и какие интересные решения увидели.
