Продолжение первой статьи про взрослый вайб-код для тех разработчиков, которые уже перешли на тёмную сторону. Рассказ про фреймворк, который насильно заставляет писать ИИ хороший код с хорошими тестами.
Go-код никогда не исполняется напрямую.
Любая строка Go превращается в машинные инструкции, которые выполняет CPU.
В этой статье мы разберём:
1) Какие инструкции генерирует компилятор Go
2) Как выглядит Go assembler
3) И что на самом деле выполняет процессор
Думаю с обзором и общими положениями мы закончили, поэтому начнем с фундамента – что происходит в CPU когда мы запускаем наше Go-приложение. Конкретно в этой статье разберем основные инструкции, которые может выдать для нашего CPU компилятор Go, что они из себя представляют и как соотносятся с кодом Go. Сразу оговорюсь, что это НЕ гайд по Go Assembler, а разбор того, что из себя представляет Go End 2 End. Попытка докопаться до истины
Напомню, что сам CPU определяет:
Что делать, если синхронные REST-вызовы превращают ваши микросервисы в карточный домик? Пора вспомнить проверенные временем паттерны обмена сообщениями. В этой статье разбираем архитектуру Pipes and Filters, Content-Based Router и Idempotent Receiver — те самые кирпичики, на которых держатся надёжные системы. Схемы, best practices для проектирования устойчивых интеграций для Enterprise-разработки.
Вот уже 18 лет статический анализатор кода PVS-Studio находится на рынке. За это время он обзавёлся поддержкой языков C, C++, C# и Java. Разумеется, останавливаться на этих языках мы не планируем, и в этой статье расскажем про разработку нового JavaScript/TypeScript анализатора, который выйдет уже совсем скоро.
Ручное управление серверами, «фиксы по SSH» и конфигурации, которые живут только в голове ушедшего в отпуск админа, — это не просто боль, это прямая угроза бизнесу. В этой статье разбираем, почему Infrastructure as Code перестал быть «модным словом» и стал единственным способом спать спокойно. Реальный кейс: как Knight Capital потерял $440 млн за 45 минут из‑за отсутствия воспроизводимой инфраструктуры. Практические советы, пайплайн с GitOps и лучшие практики внедрения IaC в 2026 году.
Когда я впервые внедрял LLM в production-сервис, схема безопасности выглядела примерно так: написать хороший system prompt, поставить галочку «мы всё предусмотрели» и жить дальше. Жизнь не дала долго наслаждаться этим спокойствием — первый же тест показал, что пользователи довольно быстро находят способы заставить модель «забыть» всё, что мы написали в системном промпте.
Проблема фундаментальная: system prompt — это инструкция, которую LLM старается выполнить, но не обязан. Модель может её переинтерпретировать, «забыть» при длинном контексте или просто обойти через специальные конструкции. Guardrails — это другой уровень: они работают на уровне кода, до и после вызова LLM, и модель физически не может их обойти.
Приветствую всех!
У меня было обилие мыслей на тему того, что можно сюда написать и решил разобраться в фундаменте мироустройства языков программирования. Копнуть в самую суть с разбором когда американских дедов(и их же репозиториев), которые вполне себе могли написать нечто и под знаменитым кукурузным XXX самогоном.
Решил я фундаментально разобрать то, как работает Golang, потому что в интернете(YT, Конфы и пр.), на мой взгляд, крайне много откровенно поверхностной и верхнеуровневой информации. Я, конечно, буду рад, если вы укорите меня в моих слабых навыках поиска и покажете мне, что реальность не такая, какой я её выдумал, но субъективно это так.
Разборы здесь будут скорее про то, что лежит в порождении сумрачного американского гения по ссылке github.com/golang/go с периодической синхронизацией с официальной документацией.
Моя главная цель – разобрать всё максимально исчерпывающе, насколько я это смогу.
Чтож, поехали!
Ах, да. В этом цикле не будет особо веселых рисуночков с гоферами, а скучные блок-схемы, диаграммы и вырезки из кода.
Структурная схема
В распределенной системе понять, что именно произошло во время выполнения запроса, бывает сложнее, чем исправить саму ошибку. Логи показывают события по отдельности, метрики — общую динамику, но без связки между ними картина остается фрагментарной. Мы решили выстроить наблюдаемость на базе OpenTelemetry и использовать Sentry для анализа трейсов.
Микросервисная архитектура решает проблему масштабируемости, но почти всегда создает новую — потерю прозрачности. Один пользовательский запрос может пройти через десяток сервисов, очереди, сторонние API и фоновые процессы. Если где-то возникает ошибка, найти ее источник без полноценной трассировки — задача на часы, а иногда и на дни.
Чтобы избежать этого, мы выстраиваем связку OpenTelemetry + Sentry. OpenTelemetry позволяет стандартизировать сбор телеметрии, а Sentry — централизовать ее анализ. В результате появляется целостная картина работы системы.
Введение в OpenTelemetry: traces, metrics, logs
OpenTelemetry объединяет три типа телеметрии — логи, метрики и трейсы — и задает для них спецификации.
Трассировки. Трейс показывает, как выполнялся конкретный пользовательский запрос. Запрос разбивается на шаги, каждый шаг в терминологии трассировки называется span, они фиксируются с указанием времени начала и окончания. В итоге можно увидеть не просто факт ошибки, а последовательность действий, которая к ней привела.
Метрики отражают общее состояние системы: время отклика, количество запросов, долю ошибок, загрузку ресурсов. По ним видно, стабильна ли система и есть ли отклонения.
Заходят как-то в бар Битрикс24 и Диадок — и быстро выясняется, что работать вместе им пока сложно. Битрикс24 отвечает за сделки и коммуникации, Диадок — за документы и статусы. А бизнесу нужна единая цепочка: документ появился в Диадоке — менеджер сразу видит его в CRM без переключений и ручных сверок.
Мы реализовали такую интеграцию с нуля. Настроили автоматическую передачу документов из Диадока в Битрикс24. Документы создают лиды, а статусы, файлы и история изменений отображаются в CRM.
История о том, как я выпустил популярный ORM в 2012 году… потом похоронил его… потом осознал, что база данных должна быть единственным источником правды. И к чему это привело.
На связи Сергей Скирдин, технический директор компании «Белый код». Поставил себе цель — сделать обзоры на шины данных из реестра отечественного ПО. Сегодня в обзоре Compo ESB.
С 2024 года я встречаюсь с вендорами и делаю обзоры продуктов, которые относятся к классу ESB. За это время удалось пообщаться с разработчиками 20+ разных решений. Для всех, кто интересуется шинами данных, я также создал сообщество в Телеграме «Шины не для машины». Это площадка для диалога между российскими разработчиками ESB и компаниями, которым нужна интеграционная шина.
Всем привет! Меня зовут Егор Ермаков, я бэкенд‑разработчик в группе разработки процессинга Техплатформы городских сервисов Яндекса.
Техплатформа — это инфраструктурная платформа для всех городских сервисов Яндекса: Такси, Еды, Лавки, Доставки, а также для различных шеринговых сервисов — каршеринга, зарядных станций, самокатов и других.
Один из ключевых сервисов нашей команды — ProcaaS (Processing as a Service). Он предназначен для асинхронного выполнения динамических сценариев. Подробнее о самом сервисе, его архитектуре и роли в сетке микросервисов Такси мы рассказывали в предыдущей статье. В этом материале я хочу поделиться опытом решения одной непростой и при этом очень интересной технической задачи, с которой мы столкнулись в рамках развития ProcaaS, а именно — рассказать, как мы написали свой транслятор кода.
В феврале 2025 года один из основателей OpenAI Андрей Карпатый написал несколько строк в X (бывшем Twitter), которые быстро разлетелись по всему IT-сообществу. Он описал свой новый подход к программированию: «Я полностью принял вайбкодинг, где забываю, что код вообще существует. Я просто вижу то, что хочу, говорю ИИ, и оно появляется». Так слово вайбкодинг попало в обиход.
С тех пор прошло больше года, и вайбкодинг стал практикой, которую используют и опытные разработчики, и люди, никогда не писавшие код. Давайте смотреть, что это такое, зачем нужно и где этому учиться.
Самый неприятный тип инцидента — когда база данных не падает полностью, а просто начинает работать медленнее.
Пользователи замечают это сразу. Жалобы начинают поступать. Технически всё по-прежнему работает, но явно что‑то не так.
И обычно самое сложное здесь не заметить проблему, а понять, что на самом деле происходит.
Привет, Хабр!
Каждый, кто работал с бухгалтерией, CRM или просто заводил контрагента вручную, знает эту боль. Вам присылают карточку компании в PDF, договор в DOCX или просто текстовый файл с реквизитами. Задача: достать оттуда ИНН, КПП, расчётный счёт и БИК, чтобы не схлопотать штраф за неверные данные.
Можно нанимать стажёра, который будет перепечатывать это в Excel. А можно довериться машине.
Мы в нашей компании долгое время решали эту проблему для своих внутренних задач (интеграция с 1С и автоматизация документооборота), а в итоге обкатали решение и выпилили в отдельный публичный сервис. Сегодня расскажу, как наш API извлечения реквизитов работает под капотом, покажу примеры кода на 6 языках (включая 1С, куда без него) и честно расскажу о таймаутах и подводных камнях.
В поиске способов построения монад мы уже рассматривали сопряжения и расширения функторов. Свойства обеих абстракций выражаются естественными преобразованиями, но ещё не был представлен универсальный метод их получения. В этот раз мы познакомимся с техникой, позволяющей решать такие задачи.
В предыдущих частях мы видели, что все манипуляции в категориях происходят между морфизмами и совокупностями морфизмов. Для теории типов это вообще очевидный факт — любые конструкции (типы) являются функциями, преимущественно высокого порядка. В контексте вычислений обе теории представляют собой различные точки зрения на этот процесс, и между ними есть немало общего. В частности, функторы являются в первую очередь функциями на морфизмах, из которого следует (нефункциональное в общем случае) сопоставление объектов. Поэтому ожидается, что должен существовать конструктивный вывод возможностей описанных ранее абстракций.
Давайте рассмотрим технику исчисления концов через призму теории типов с использованием языка программирования Scala.
Сначала казалось, что всё это временно. IT же всегда «куда‑то растёт», значит, рано или поздно ситуация отыграется назад. К концу 2025‑го стало понятно: пока не отыгралась и сложно прогнозировать, когда рынок найма снова начнет рост.
Вакансий меньше, откликов больше, в подборе участвует не только тимлид и HR, но и алгоритмы, которые фильтруют резюме. Даже сильным ребятам стало ощутимо сложнее получать офферы, а джунам — тем более.
Мы поговорили с четырьмя экспертами: руководителями разработки, HR и карьерными консультантами, которые регулярно смотрят резюме, помогают искать работу, проводят собеседования и решают, кого позвать в команду, а кого — нет. Из этих разговоров собрали срез рынка и стратегию выживания.
Дальше будут цифры, кухонные истории из найма и советы: как собирать резюме и портфолио, готовиться к собеседованиям и пользоваться ИИ так, чтобы он помог, а не подставил.
Иногда баг оказывается не ошибкой реализации, а ограничением API. Разбираем кейс из imageproc и image-rs.
Почему фикс оказался невозможен без изменения контракта библиотеки.
Девятый выпуск еженедельных IT-новостей от OpenIDE.
Милла Йовович выложила свой проект в open-source, Claude Code нашел баг в Linux, которому 23 года, Anthropic показали Claude Mythos и сразу закрыли доступ.
А Skill Caveman внезапно оказался самым простым и самым эффективным инструментом недели.
Я никогда не понимал, как именно traceroute обнаруживает каждый сетевой переход. Оказывается, всё дело в хитром трюке с TTL и примерно в 80 строках на Rust.