Здравствуйте, меня зовут Дмитрий Карловский и я... серийный убийца устоявшихся стандартов. Сегодня я выследил и нанёс критический урон UTF-8. И сейчас я расскажу, как я его переиграл и уничтожил новым стандартом кодирования текста — Unicode Compact Format.
Есть магия: взять число, разделить на ничто, умножить на ничто — и получить исходное. Не иллюзия, а математика уровней. Paradox библиотека — проводник в мир, где ноль бесконечно глубок, бесконечность структурирована, а запретные операции ведут не к краху, а к новым измерениям. Заклинание на C++ прилагается.
Всем привет! В первой части мы разобрали теорию: почему LLM «забывают» информацию в середине промпта, как на это влияет архитектура внимания и при чём здесь ротационные кодирования (RoPE). Мы выяснили, что эффект Lost in the Middle — это закономерное следствие того, как устроены современные трансформеры и как они обучаются.
Но насколько всё плохо на практике? Если разработчик модели заявляет контекстное окно в 128k или даже 1M токенов — можем ли мы на него рассчитывать в реальном продакшене?
Во второй части мы переходим от теории к цифрам на бенчмарках. Мы разберём, почему стандартные тесты "иголка в стоге сена" (NIAH) безнадёжно устарели и как новые метрики вроде RULER и NoLiMa показывают реальное «рабочее» окно моделей, которое иногда в 60 раз меньше заявленного.
В финале этой статьи я соберу практические архитектурные принципы, которые помогают проектировать LLM-системы так, чтобы длинный контекст действительно повышал качество, а не превращался в источник ошибок.
Привет, Хабр!
Сегодня я расскажу про библиотеку Python River, которая позволяет обучать модели машинного обучения в потоковом режиме.
В классическом варианте мы собираем весь датасет целиком, делим на обучающую и тестовую выборки, обучаем модель, измеряем качество — и внедряем в прод. Здорово, если данных немного и они разом доступны. А если данные льются непрерывно?
Новые пользователи приходят каждый день, события генерируются каждую секунду. Модель в продакшене устаревает, если не переучивать её регулярно. Переобучение с нуля нарастающим объёмам данных — удовольствие ниже среднего: долго, ресурсозатратно, да и не всегда возможно, если данные бесконечны (например, поток кликов или показателей датчиков).
C++ — язык с долгой памятью. В нём до сих пор живут идиомы и приёмы, которые когда-то спасали разработчиков, а сегодня нередко мешают писать безопасный, быстрый и поддерживаемый код. Мы продолжаем использовать макросы, CRTP или iostream «по привычке», не всегда задумываясь о цене — сложности поддержки, скрытых багах, просадках производительности и времени команды. Разобраться, что в современном C++ действительно стоит брать в прод, а что пора оставить в прошлом, — важная задача для инженера, который не хочет тащить legacy в 2026 год.
Привет, Хабр! Недавно мы запустили шоу «АйТир Лист». В каждом выпуске берём одну тему из мира разработки и раскладываем её по тир-листу — от FAIL до GOD. В первом выпуске разбирали open source для фронтенда, а во втором выпуске — обсудим непростую тему фич и идиом С++.
Приглашённые эксперты — Антон Полухин, эксперт-разработчик C++ платформы городских сервисов Яндекса, и Даниил Черепанов, архитектор редакторов МойОфис.
Будет субъективно, местами провокационно и точно полезно — чтобы вы посмотрели на привычные инструменты свежим взглядом и осознанно выбирали, на чём писать следующий проект.
Привет! Меня зовут Евгений, я инженер в JetBrains.
Долгое время я занимался разработкой Rider - IDE для .NET: от первых обсуждений идеи в 2014 году до роли тимлида команды в последние годы. Да-да, можете ругать меня в комментариях и в личке за те самые баги, которые висят открытыми по 7 лет 🙂
В середине прошлого 2025 года я оставил позицию тимлида Rider и перешёл в команду IntelliJ AI. Последнее время я много работаю с AI-агентами и агентской разработкой - мы занимаемся их интеграцией в IDE. Было бы странно не пробовать такие инструменты в реальной работе.
Привет, я Александр Дудукало, фронтенд-разработчик. Сегодня я расскажу об обработчиках событий. Если коротко, вы узнаете о самом удобном способе управлять откликом на действия пользователя или браузера.
Эта статья — часть базового курса, где я простым и доступным языком рассказываю о том, как научиться писать свои первые сайты и веб-приложения на JavaScript. Все детали под катом.
Есть много интересных способов провести новогодние праздники, но поскольку я уже старенький — вместо классических алкогольного угара, ведра оливье и просмотра «Иронии судьбы» выбрал себе более редкое и необычное занятие.
В октябре 1998 года, разочарованный упрощенным пониманием ООП, Алан Кей написал сообществу Squeak знаковое письмо. В нем он напомнил, что главная идея Smalltalk, о которой все забыли, — это не классы, а отправка сообщений. Это письмо стало манифестом, отделяющим оригинальную философию объектов от ее популярной интерпретации. Публикуем перевод этого короткого, но исторически важного документа.
Чем мощнее становятся языковые модели, и чем шире они распространяются, — тем больше на нашу бедную головушку проливается дождей из лягушек. Еще десять лет назад можно было с уверенностью отличить графомана от литературно-одаренного человека, а хорошего разработчика — от вкатуна с претензией на экспертизу. Достаточно было посмотреть на пару абзацев текста (кода) — и становилось понятно: этот рифмует «кровь–любовь», а вон тот — сортирует коллекции брутфорсом.
Хороший прозаик никогда не поставит в одно предложение три прилагательных подряд, а хороший программист — не станет использовать связные списки вместо массивов под большой нагрузкой на доступ по индексу. Согласно банальной логике, эти кванторы существования обратимы: написал единожды алгоритм O(n³) там, где можно обойтись O(n·log(n)) — иди учи матчасть, а потом возвращайся к нам в теплый коллектив джунов.
Лекала в те времена были золотыми, а сито — мелкоячеистым, мышь не проскочит. Мы просили в качестве тестового задания решить простейшую задачку, строчек на сто кода. По этой сотне строчек было видно, насколько зрело владеет кандидат языком (программирования). Декомпозиция, идиоматика, да вон хоть именование переменных — все, как на ладони. Если человек на руби вместо редьюса — объявляет аккумулятор вне скоупа, а потом его мутирует внутри цикла — нам не по пути (в других компаниях могут быть другие любимые песни, но общий посыл — понятен).
Spec Kit - это один из самых амбициозных фреймворков для наведения порядка в разработке с использованием ИИ. В нашем предыдущем посте о spec driven development мы обсуждали его потенциал для закрытия давних пробелов в рабочих процессах с ИИ-ассистентами за счет обеспечения соблюдения стандартов проекта, контекста на уровне функций, принудительной декомпозиции для управляемого объема работ и контрольных этапов (review gates) для контроля качества.
Но исполнение - это то, где теория сталкивается с сопротивлением. Документация Spec Kit - это сильная отправная точка, с понятными видео, подробными руководствами и предписывающими шагами, которые позволяют развернуть его за считанные часы. Сложности начинаются, когда вы покидаете «песочницу». Подобно примерам Animal → Dog → Labrador в учебниках по ООП, примеры учат синтаксису, а не промышленной разработке программного обеспечения.
Пробел заключается не в документации, а в контексте и реальной экспертизе. Чистые примеры прекрасно работают для greenfield-проектов (проектов с нуля), но большинство команд работают с существующими (brownfield) кодовыми базами, сформированными месяцами эволюционирующих решений, компромиссами разработчиков, конкурирующими паттернами и не подлежащими обсуждению стандартами качества.
Этот пост отражает наш путь через эти испытания. Это не отполированная история успеха, а честный рассказ о том, что сработало, что нет, и как мы заставили Spec Kit работать в живой производственной системе, где компромиссы в качестве были недопустимы.
Почему команды отказываются от подхода «сначала код, потом исправления», когда ИИ ускоряет поставку сверх всякого контроля? Spec-Driven Development (разработка на основе спецификаций) представляет шестиэтапную модель, которая переносит архитектурные решения, ограничения и ясность на более ранние стадии (upstream). Узнайте, как это улучшает качество выходного результата, сокращает циклы очистки кода и позволяет AI-агентам работать согласованно в рамках мультисервисных систем.
Поставка программного обеспечения была ориентирована на реализацию большую часть своего существования: команды открывали редактор, пробегали глазами бриф спринта и начинали писать код. Этот рабочий процесс имел смысл, когда основными создателями были люди, репозитории развивались медленно, а конвейеры релизов были линейными и предсказуемыми. Теперь AI-агенты, такие как Copilot, Cursor и Windsurf, генерируют код быстрее, чем успевают реагировать архитектура, управление (governance) и интеграция. Код перескакивает от бэкенд-логики к конфигурациям инфраструктуры и CI/CD за часы, на что раньше уходили месяцы.
Когда такой подход «сначала код, разберемся позже» опережает архитектуру, безопасность и управление, система в конечном итоге рушится под собственным весом.
Модель, ориентированная на спецификации (spec-first), обращает этот коллапс вспять с помощью живых, исполняемых артефактов. Вместо того чтобы код вел процесс, спецификации становятся якорем (и источником), на основе которого действуют ИИ и люди. Они содержат решения о структуре, библиотеках, паттернах, соответствии требованиям и интеграции еще до того, как будет сгенерирована хоть одна функция.
Когда поведение меняется, команды обновляют спецификацию, и все последующие выходные данные следуют за ней. Поломки также устраняются путем обновления исходной спецификации, а не латанием симптомов в разных файлах. Чтобы увидеть, как Spec-Driven Development меняет темп и качество разработки с использованием ИИ, давайте разберем, что это такое на самом деле.
В настоящее время многоядерные процессоры с гетерогенными архитектурами, в которых сочетаются ядра с различной производительностью, становятся всё более и более распространенными. Если ещё пару лет назад такие архитектуры были в основном распространены в мобильном сегменте (см. ARM BIG.little), то с анонсом в 2022 году компанией Intel процессоров 12-го поколения линейки Intel Core, такие процессоры стали распространяться в сегменте десктопов и рабочих станций. Однако, до сих пор остается открытым вопрос — необходимо ли каким‑то специальным образом учитывать особенности данных архитектур для достижения максимальной многопоточной производительности?
Python-решения для AI-безопасности добавляют 50-200мс задержки и сотни зависимостей. SENTINEL Shield — слой на чистом C: 0 зависимостей, <1мс латенси, 194 CLI-команды. Расскажу зачем и как.
Привет, Хабр. Всех с наступившим Новым Годом.
На днях наткнулся на статью Махмуда Хашеми, в которой обсуждаются некоторые недостатки методологии семантического версионирования (SemVer), и в качестве решения этих недостатков предлагается использовать календарное версионирование (CalVer). В организации, где я работаю, по стандарту разработки требуется обязательно версионировать приложения по SemVer. Из собственного опыта использования SemVer скажу, что нашёл в ней ещё ряд недостатков, для исправления которых пришлось искать новый способ версионирования.
Генератор паролей из /dev/random: от one-liner'а к Rust CLI
В этой статье хочу поделиться процессом написания собственного генератора паролей, использующего энтропию /dev/random. От pipe команды до Rust утилиты.
Автоматизированное тестирование API часто начинается с простых решений в виде коллекций Postman или скриптов на коленке. Такой подход работает на старте, но быстро исчерпывает себя.
Создание собственного проектного фреймворка является осознанным переходом от хаотичной, фрагментарной автоматизации к устойчивой, гибкой предсказуемой и масштабируемой системе тестирования. Такой фреймворк дает полный контроль над архитектурой, обеспечивает строгую валидацию контрактов API, безопасную работу с базой данных, генерацию осмысленных тестовых данных и простую интеграцию в инфраструктуру разработки.
Статья поделена на три части.
В первой части дается обоснование преимуществ создания полноценного проектного фреймворка по сравнению с использованием готовых универсальных инструментов по типу Postman. Вы узнаете, какие принципы легли в основу архитектуры фреймворка и какой был подобран технологический стек для их реализации на практике.
Статья техническая и адресована инженерам-программистам в тестировании (SDET) и инженерам по автоматизации тестирования, которые перешли от написания обособленных тестов к осознанному проектированию тестового фреймворка или только начинают этот переход.
Эта статья поможет новичкам в программировании (и, может быть, не только им) понять законы логики и почему они важны при создании приложений, а также в повседневной жизни. В статье приведены примеры того, как эти законы могут нарушаться в реальных приложениях и в нашей жизни. Также есть ссылки на видеоверсию статьи и бесплатный онлайн курс по теме.
Недавно снова услышал вайб: да все эти принципы это только направление и их можно не придерживаться. И таких людей не переубедишь. Приводи им примеры или нет - свой опыт им не передашь. Да и слушать у нас как-то стало не модно. У нас же все теперь гибко и как договоритесь. И требовать каких-то стандартов отрасли - это уже абьюз…
Интеграционные тесты тормозят и не нужны, линтер можно и не использовать. Нарушение архитектурных принципов - так мы ж делаем MVP - зачем оно нам?
Я в корне не согласен с таким подходом и буду это разбирать на примере SOLID и перфораторной дрели...
Когда речь заходит об open source, многие сразу думают: «Это для энтузиастов».
Контрибьют в Open Source это способ расти как разработчик, завести полезные связи и заявить о себе.
Разбираемся, как найти свой проект, использовать AI для чтения кода и сделать первый контрибьют без боли!
