Разработка

В этом посте будут объяснены две стратегии оптимизации WebAssembly, которые не так давно были реализованы в движке V8 и вошли в версию браузера Google Chrome M137. Речь пойдёт о спекулятивном встраивании call_indirect inlining и о поддержке деоптимизации в WebAssembly. В сочетании два этих приёма помогают генерировать более качественный машинный код, так как основаны на допущениях, которые строятся, исходя из обратной связи, поступающей от среды исполнения. Благодаря этому, WebAssembly выполняется быстрее, особенно это касается программ WasmGC. Например, проверив эти приёмы на наборе микробенчмарков, написанных на Dart, видим, что комбинация двух оптимизаций даёт ускорение в среднем более чем на 50%. В более крупных и реалистичных приложениях и на тех бенчмарках, которые рассмотрены ниже, достигается ускорение между 1% и 8%. Деоптимизации — также очень важная составляющая для дальнейшей оптимизации в будущем.

Привет!

Разберём ReadyToRun (R2R) — технологию предкомпиляции в .NET. Многие включают её, надеясь на супер ускорение, а потом удивляются результатам. Посмотрим, как это работает на самом деле и где реально помогает.

ReadyToRun — это AOT-компиляция для .NET. Обычно приложение поставляется в IL-коде, который JIT превращает в машинный код во время выполнения. R2R компилирует код заранее при публикации проекта — в итоговых DLL лежит и IL, и готовые машинные инструкции. При запуске CLR просто берёт нативный код без пауз на компиляцию.

Когда изучил историю двоичных файлов Quake, их логика стала мне понятна. quake.exe был первоначальным релизом, который мог работать в DOS и Windows 95. Затем появился vquake.exe для поддержки чипа Vérité 1000 с аппаратным ускорением. Позже выпустили glquake.exe, позволивший использовать аппаратное ускорение любого чипа с драйверами OpenGL. А чтобы совершить революцию в Интернет-deathmatch, id Software выпустила сервер и клиент QuakeWorld (qwsv.exe и qwcl.exe).

Однако я не мог понять смысл winquake.exe... до недавнего времени. В статье я расскажу, что понял, изучив его работу.

Всем привет! Меня зовут Щепетков Константин, я TechLead бэкенд разработки компании ZeBrains, работаю в роли TeamLead бэкенда на проекте мобильного приложения Бургер Кинг.

Почти год назад мы запустили полную переработку бэкенда: распиливаем монолит на множество сервисов, всё пишем с нуля. Работы много, сроки плотные — классика.

Чтобы ускорить разработку, решил в качестве эксперимента делегировать часть задач ИИ-инструментам. Негативных кейсов поначалу было много, но со временем качество результата заметно выросло.

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

Тут не будет инструкций к конкретным ИИ-иструментам, но при этом поделюсь практическим опытом применения ИИ. Статья будет полезна не только бэкенд‑разработчикам, но и всем, кто хочет использовать ИИ-инструменты осознанно.

На Хабре тысячи статей про OCR, IDP, ML и искусственный интеллект. Все они сходятся в одном: «качественная разметка данных — ключ к точности модели». Но что это значит на практике?

Меня зовут Снежана Игнатенко, я руковожу отделом разметки данных в SL Soft AI. Каждый день моя команда работает с самыми разными документами: печатными, рукописными, строгими формами, свободными текстами, сканами и фотографиями, в которых встречаются печати, подписи, штампы, затертые области, перекосы и артефакты. Наша задача — создавать качественный, точный и контекстно корректный набор размеченных данных, который служит фундаментом для всех интеллектуальных систем класса IDP.

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

Мы с командой проанализировали 25 мобильных приложений лидеров рынка электронной коммерции в России и в мире в четырех категориях, где риск возврата особенно чувствителен к точности выбора, — и выбрали 14 UX-решений, которые способны значительно его снизить.

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

Мы много работаем с компаниями, которым необходимо использовать отечественное ПО для баз данных. В таких проектах часто уже есть инфраструктура на MS SQL Server, PostgreSQL или Oracle Database. Основной конфликт — требования регуляторов и высокая стоимость миграции логики приложений на другую СУБД.

Мы создали продукт, который нативно понимает диалекты и позволяет работать с существующими базами без переписывания кода. В статье расскажем, как развернуть Digital Q.DataBase для начала работы с базами без долгой и затратной миграции.

Всем привет! Меня зовут Андрей, с Банки.ру я связан уже больше 14 лет, а сейчас руковожу командой Платформы и забочусь о гильдии девопсов.

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

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

Привет, Хабр! Меня зовут Илья Парамошин, я ведущий инженер в МТС Web Services. В первой части мой коллега Владимир Дробот рассказал, зачем нам понадобился ИИ‑помощник для техподдержки и почему мы выбрали архитектуру на RAG. В этой статье я раскрою техническую сторону и разберу, как мы собирали данные, выбирали эмбеддинги, настраивали поиск и какие подводные камни встретили на пути. Спойлер: без костылей не обошлось, но система работает в проде и ежедневно помогает нашим инженерам.

Привет, я Павел Таланов из команды Yandex Infrastructure. Вместе с командой мы создаём SourceCraft — платформу для полного цикла разработки IT‑продуктов. Хочу рассказать о прикольной задаче на стыке бэкенда и IDE, которую мы решали, чтобы сделать ещё более удобную навигацию по коду в SourceCraft — когда индексация кода проходит с нужной скоростью, а подсказки и другие фичи навигации всегда готовы к открытию пул‑реквеста.

Расскажу про требования, которые мы выявили для поиска по коду, чуть‑чуть про предметную область, а также о том, какая архитектура индексации у нас в итоге получилась — и почему.

В предыдущей статье я показал, как документ можно превратить в сеть смыслов и получить «живую» онтологию знаний. С помощью своего семантического ритуала я разбираю текст на термины и связи, и документ растворяется в графе, оставляя после себя осмысленную модель. Такой подход к знаниям убирает двусмысленность: ключевые понятия вынесены в онтологию, язык проекта становится частью архитектуры, и команда работает в едином контексте. В итоге сложные системы перестают зависеть от «шума» неверно понятых слов и начинают вести себя предсказуемо.

Теперь я иду дальше и развиваю концепцию живых онтологий – на этот раз применяя её к управлению процессами. Что, если моделировать процессы так же, как семантику текста? Могу ли я описать процесс как совокупность понятий, связей и состояний – и сделать так, чтобы эта модель реально исполнялась?

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

Кажется, что оборачивать BigDecimal и String в отдельные классы — это overengineering и преждевременный DDD. Но именно из-за этих «лишних» типов в прод не пролезают посылки в ПВЗ, проценты внезапно превращаются из 0.8 в 80, а деньги теряют валюту и смысл. В статье на реальном примере логистики разбираем, как один небольшой record Weight и несколько аккуратных Value Object’ов наводят порядок в бизнес-логике: инварианты перестают жить в комментариях, проверки перестают дублироваться, а код начинает читаться как текст предметной области. Без внедрения полного DDD, без религиозного фанатизма — только практические шаги.

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

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

В этой статье я покажу, как относиться к LLM не как к "герою-одиночке", а как к команде ролей (аналитик, ресерчер, архитектор, разработчик, ревьюер, QA, техписатель, валидатор) и собрать полноценный AI-Driven Development (AIDD) процесс с понятными договорами и quality-гейтами на каждом шаге.

Это практический how-to: от минимальной версии до более строгого процесса с ролями, гейтами и интеграцией с CI. Все примеры - на базе Claude Code, но принципы подхода можно перенести и на другие инструменты (Cursor, Copilot, локальные агенты и т.п.).

Меня зовут Александр, я fullstack разработчик с 20+ годами опыта (php+js+golang и всякое по мелочи). Количество мифов и заблуждений о разработке через ИИ превысило, на мой взгляд, все разумные пределы.

Я хотел бы порассуждать о причинах таких заблуждений.

Типичные заблуждения не-разработчиков звучат так:

Стабильность E2E-тестов: как добиться 100% успешных прогонов ?

Практика, проверенная на реальном проекте.

Флаки-тесты убивают доверие к автоматизации. В этой статье — проверенные подходы, которые помогают превратить нестабильные E2E-прогоны в надёжный инструмент проверки продукта.

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

Раньше для этого можно было использовать только строку User‑Agent, которую браузер отправляет автоматически, но её избыточность и сложность парсинга стали сдерживать развитие веба. Client Hints предлагает другой подход: вместо того чтобы сразу раскрывать всю информацию, браузер передаёт только те данные, которые действительно нужны сайту.

На связи Степан из команды Яндекс Браузера. Сегодня поговорим о том, как мы переходим от устаревшего User‑Agent к современной технологии Client Hints. В статье разберём, почему User‑Agent стал проблемой, как работают хинты под капотом и какие перспективы у перехода на новую технологию.

Как говорится, в споре рождается истина. И этот случай не стал исключением. Часто проектирую запросы, консультирую аналитиков, сама консультируюсь у разработчиков и заметила, что иногда мы по-разному понимаем некоторые аспекты REST. Когда я стала погружаться в тему, то материала набралось столько, что одной статьей не обойтись. Понимание мифов позволяет делать более осознанный выбор при проектировании.
С вами Дарья Борисова, системный аналитик из ПСБ, и я начинаю цикл статей «Мифы о REST».

Скриншот-тестирование — это метод автоматической проверки пользовательского интерфейса на визуальные регрессии. В этой статье — практическое руководство по внедрению такого подхода в Android-приложение с использованием библиотеки Roborazzi. Рассмотрим базовую настройку, интеграцию с CI, а затем расширим возможности тестов с помощью кастомизации Roborazzi.

Многие компании в процессе своего развития успешно осваивают начальные этапы TOGAF ADM: формируют видение, разрабатывают целевые модели, создают планы переходов. Но настоящая ценность архитектуры рождается не на слайдах, а в ежедневной работе ИТ-команд. Именно здесь возникает критический разрыв: хорошие архитектурные артефакты остаются невостребованными, потому что непонятно, как их применять в реальных процессах разработки, тестирования и эксплуатации. Стратегические архитектурные решения (принципы, стандарты, целевые состояния) формализованы, но не оказывают реального влияния на операционную деятельность команд. Причина — отсутствие четких механизмов внедрения этих решений в рабочие процессы.

Этот разрыв преодолевается там, где архитектурное мышление интегрируется с методологией управления ИТ-процессами. Агрегация компетенций корпоративного архитектора и ИТ-методолога превращает ADM из теоретического цикла в работающий механизм трансформации.

Как в 2ГИС/Яндекс.Картах/Google Maps аккуратно смещать камеру и маркер в “сцену” при нажатии, даже когда карта повернута: определить видимую область, проверить положение точки, вычислить сцену с учётом паддингов, при необходимости сдвинуть или центрировать маркер.

С математическими расчетами и картинками.