Technotext

Ну как, вы уже обновили свои приложения для поддержки новых требований Google? Если нет, то эта статья будет вам особенно полезна =) Напомню, что с 1 ноября 2025 года приложения, таргетирующиеся Android 15 и выше, должны поддерживать 16-килобайтные страницы памяти.

Как вы помните по предыдущим статьям, я работаю в МойОфис в команде разработки мобильной версии высоконагруженного корпоративного мессенджера Squadus (бэкенд на Node.js, NestJS и Meteor, а веб-интерфейс на React). Мы уже успешно перестроились на новые стандарты Google, и поэтому могу компетентно рассказать, что именно требуется, как адаптировать под это React Native-приложение и что делать, если используемая библиотека ещё не успела обновиться.

Ещё Достоевский на примере своих героев-картёжников показал: быть должником удовольствие сомнительное в любую эпоху. В разработке тоже есть своя «долговая яма» — технический долг. Если продукт большой и развивается годами, полностью избежать его невозможно. Функциональность реализована, всё математически корректно работает, но из-за накопившихся архитектурных компромиссов всё сложнее укладываться в пользовательские ожидания по скорости и отзывчивости.

Меня зовут Дмитрий Шубин, я занимаюсь оптимизацией производительности в компании МойОфис — конкретно в Ядре редакторов (о нём ранее рассказывал мой коллега в статье «Как мы создаём редакторы документов. Ядро и его роль в кроссплатформенной разработке»).

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

В этой статье разберём, почему возникает такой долг и как мы с ним работаем на практическом примере оптимизации редактора «МояТаблица».

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

Меня зовут Антон Леонтьев, я старший разработчик в команде ядра редакторов МойОфис. Мы создаём офисные приложения, которыми ежедневно пользуются более 12 500 организаций, и совместное редактирование — одна из ключевых возможностей наших продуктов.

И знаете, что самое обидное в этой теме? За 35 лет исследований были опубликованы сотни научных работ. Google Docs работает с 2006 года. У Figma, Notion и Linear свои реализации. Казалось бы, задача давно решена, но стоит копнуть глубже, и становится понятно: универсального решения нет.

В Google Drive и Dropbox до сих пор всплывают баги с одновременным перемещением папок. В Notion при параллельном редактировании одного и того же абзаца можно потерять часть изменений. Даже Yjs — самая популярная CRDT-библиотека — не хранит полную историю документа в привычном для нас виде.

В этой статье разберём теорию, узнаем, какие проблемы решают Operational Transformation (OT) и Conflict-free Replicated Data Types (CRDT), на каких математических идеях они основаны, чем отличаются архитектурно и какие компромиссы неизбежно возникают в каждом подходе.

Интересно узнать, почему даже Google не смог сделать идеальное решение? Детали под катом.

Приходят к нам мужики из цеха и говорят эту фразу.

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

Во-вторых, конвертер, который надо фотографировать. Если что, то конвертер — это такая печка в виде большого горшка восемь метров высотой. Мы туда заваливаем металлолом и заливаем жидкий чугун, затем всё это продувается кислородом, а потом на выходе получается сталь. Смысл операции — при температурах выше 1 600 градусов продуть кислородом на сверхзвуке так, чтобы он связал ненужные нам примеси.

Чего хотят цеховые: каждый раз, когда сталь готова, этот горшок наклоняется, и из него выливается расплав в ковш на железнодорожной платформе.

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

Кстати, она еще и бороду снаружи отращивает.

Пока конвертер наклоняется к платформе, горловина сзади красиво подсвечивается расплавом. Если мы сможем повесить камеру под 45 градусов и ловить точный момент во время наклона, то они будут очень счастливы. Данные наклона есть в АСУТП и, соответственно, в шине, потому что мы знаем положение механизма.

Мы сделали синхронизацию через шину: как только градус доходит до расчётного, камера делает фотографию, определяет степень зарастания и отправляет её в диспетчерскую цеха.

Заодно мы стали разбираться, зачем им это, и из этого пошла ещё серия проектов.

В результате нашей командой мы реально повлияли на количество выплавляемой в стране за год стали: парой шажков — тут, парой — там, но в итоге прямо значимо. Сейчас расскажу.

Всем привет! Меня зовут Алексей Пронский, я отвечаю за архитектуру в AI-департаменте группы компаний БКС. Мы строим агентные системы, AI-ассистентов, OCR-системы, речевую аналитику и Classic ML модели. Поскольку мы работаем по принципам enterprise разработки, за каждым таким проектом стоит архитектурное решение (далее — арх.решение) — документ, который проходит согласование с бизнесом, корпоративной архитектурой, ИБ и владельцами смежных систем. Арх. решения мы ведём в Confluence, диаграммы рисуем в Draw.io. Типичный цикл от получения бизнес-требований до согласованного арх.решения в среднем занимает две-три недели.

За последний год LLM-ассистенты произвели настоящую революцию в написании кода. В этой статье я покажу, как добиться такого же эффекта в архитектуре — перейти на подход Architecture as Code и передать рутину LLM. Мы используем Structurizr для описания архитектуры и Claude Code как LLM-ассистента. Буду показывать примеры на их основе, демо-репозиторий можно будет посмотреть на GitHub.

Всем привет! На связи Александр и Артем — ML-инженеры из Т-Банка. Мы делаем copilot-инструмент для разработчиков.

Статья будет не про агентов. Расскажем, как отрезали лишние и бесполезные подсказки в Code Completion и усилили доверие пользователей.

Около 10 лет назад у меня возникла идея написать игру именно на Java, поскольку я использую этот язык в работе. Это был своего рода челлендж. Хотел попробовать себя, посмотреть, возможно ли это. И спойлер – возможно. Но проект дал мне больше, чем я мог рассчитывать.

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

Этот опыт настиг меня в самом начале карьеры Руководителя ИТ-проектов (далее – РП). Поэтому все истории мне пришлось пройти, не имея ни многолетнего опыта управления проектами, ни вообще какого-либо образования менеджера.

Все что у меня было — это большое желание расти и достигать поставленных целей. А инструменты мне пришлось искать по пути) И я не о типичных пунктах из PMBoK!

Меня зовут Алина Прасковина, я руководитель проектов в MONS, «КОРУС Консалтинг». И прежде чем раскрыть секреты своей системы, расскажу предысторию: как же так случилось, что на еще совсем юного РП свалилось такое количество проектов?

Периодически я ищу в Интернете что-то вроде «красивый дашборд», «отличный дашборд» и т.п. (в том числе и на английском языке). Нахожу самые разнообразные решения, но, к сожалению, многие из них опасны для использования в качестве образца.

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

Привет. Я Дима Рагозин, фронтенд-разработчик в KTS. Эту статью я хочу начать с предыстории.

Полтора года назад на проекте для одного крупного клиента мы получили задачу — ускорить главную страницу. К тому моменту в кодовой базе уже жили два отдельных фронтенд-приложения под две разные платформы — CSR-версия (Client Side Rendering) и SSR‑версия (Server Side Rendering), — а MobX‑сторы все время жизни проекта разрастались вместе с функциональностью.

Каждый новый экран приносил еще один класс (а то и несколько), еще кучу связей, и в какой‑то момент мы стали замечать снижение воспринимаемой скорости приложения, избыточные HTTP‑запросы, сложности с поддерживаемостью и другие проблемы, которые становились критичнее по мере роста проекта. В статье я расскажу о том, как мы шаг за шагом перевели такие сторы на React Query, сократили код вокруг запросов на ≈50 % и практически избавились от повторных GET‑ов. Попутно поведаю о наших граблях и поделюсь советами по миграции.

У нас была рабочая видеокарта, драйвер для нее, Linux, полный набор кода, который заставлял работать нашу видеокарту, возможно, была даже прошивка. Не то чтобы это был необходимый запас для запуска AMD GPU на ПЛИС с RISC-V. Но если начал запускать видеокарту на ПЛИСе с RISC-V Linux, становится трудно остановиться…

Привет, Хабр! Меня зовут Илья Знаменский, я ведущий инженер в группе оптимизации алгоритмов искусственного интеллекта в AI-дивизионе YADRO. 

Популярность RISC-V растет стремительными темпами, и на рынке появляется все больше новых отладочных плат. Моей команде поставили задачу: узнать, как эти платы будут справляться с простыми AI-нагрузками (задачи запуска LLM-on-device не стояло). В процессе работы мы внесли вклад в развитие собственного тензорного компилятора и создали библиотеку математических ядер, которая позволила существенно увеличить производительность инференса моделей на RISC-V. С какими трудностями мы столкнулись и что в итоге из всего этого получилось — читайте в статье.

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

Мы начнем с вводной части о статическом и динамическом полиморфизме, рассмотрим факторы, влияющие на девиртуализацию, и ее примеры разной сложности — в том числе те, что мы используем в реальной разработке. А напоследок познакомим вас со спекулятивной девиртуализацией и дадим рекомендации, как подходить к виртуальным функциям в разработке на C++.

Привет, Хабр! На связи Дима Мандельштам, мобильный разработчик в core‑команде Яндекс 360, и Лёша Карпенко, руководитель команды дизайн‑системы. Дизайн — часть повседневной работы наших команд, и он не живёт отдельно. Поэтому сегодня в статье мы вместе поговорим о том, как мы собирали компонент List‑item.

Мобильные разработчики в этой статье найдут метод, с которым можно достичь баланса между гибкостью кода и простотой поддержки. Мы расскажем, как применили data‑driven‑подход к рефакторингу UI: написали анализатор AST для поиска реальных паттернов использования и вывели математическую метрику сложности API. А ещё расскажем о том, как аргументировать и провести масштабную переработку legacy‑кода, не останавливая продуктовую разработку.

Продуктовым дизайнерам будет интересен альтернативный взгляд на проектирование List‑item в дизайн‑системе. Мы разберём, как собирать List‑item — как универсальный компонент с максимальной гибкостью или как набор семантических шаблонов под конкретные сценарии.

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

Привет, Хабр! Меня зовут Матвей Быстрин, я старший инженер в команде BSP (Board Support Package) YADRO. Мы занимаемся системным софтом, который необходим для загрузки и работы SoC: от загрузчиков до драйверов блоков.

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

Начну я с самой идеи механизма обхода стека и ее применения. Затем сфокусируюсь на том, как обход производится в архитектуре RISC-V. И наконец, перейду к той самой поломке, что легла в основу статьи, и к ее ремонту.

Всем привет, это Тимур. Сейчас в YADRO я разрабатываю сетевую операционную систему для коммутаторов KORNFELD. В ходе этого проекта летом я получил сложную задачу: реализовать установку опции PROTO_DOWN для Ethernet-интерфейсов в ядре Linux. «Из коробки» ядро поддерживает эту опцию только для vxlan и macvlan-интерфейсов, а для Ethernet поддержка определяется драйвером сетевого устройства.

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

Привет, Хабр! Меня зовут Дмитрий, я старший инженер-программист в департаменте разработки мобильных приложений YADRO. В этой статье я расскажу о нашем опыте работы со стандартным AOSP-приложением «Контакты». Это базовая версия телефонной книги, разработанная в рамках Android Open Source Project (AOSP). На этапе ревью дизайна мы решили, что можно улучшить UI, не трогая бизнес-логику. Это дало начало увлекательной истории...

Привет, Хабр! Меня зовут Илья, я работаю в команде физического дизайна в дивизионе полупроводников YADRO. Проектирую цифровые микросхемы, помогаю с образовательными программами и привлекаю студентов в наше дело. В этой статье я расскажу про разработку современных микросхем с фокусом на этап проектирования топологии, объясню, что такое SoC (System-on-Chip, cистема на кристалле) и как мы проектируем их в нашей команде. А напоследок покажу, где об этом всем можно узнать на собственном опыте.

"Поскольку вы программист на C++, вероятность того, что вы слегка одержимы производительностью, выше среднего. А если нет, то вы, вероятно, по крайней мере с пониманием относитесь к такой точке зрения. (Если производительность вас совсем не интересует, аудитория Python разработчиков дальше по коридору)"
— Из пункта 42 книги С. Майерса “Effective Modern C++”, 2015.

Эта заметка описывает мой личный взгляд на то, как писать эффективный и надежный код для CPU. Статья ориентируется на С++, но значительная часть обсуждения CPU, кэшей, паттернов доступа к памяти и профилирования применима к Rust, Go и другим компилируемым языкам. Статья задумана как краткое введение и больше всего подходит студентам, имеющим опыт программирования на занятиях, но не в реальных проектах. Для профессионалов статья может быть полезной в качестве референса, чтобы не пугать новичков чем-то в духе Что каждый программист должен знать о памяти.

В статье опишу "набор новичка": godbolt.org, профилирование, бенчмарки, особенности CPU и его взаимодействия с памятью, когда есть смысл от асимптотических оптимизаций и почему важно при этом пользоваться санитайзерами, отслеживать coverage и вообще более трепетно относится к надёжности.