React Native *

Привет, Хабр. Меня зовут Карим, я Flutter разработчик уже 7 лет и последний месяц я делаю фреймворк для server-driven UI на Dart.

Зачем еще один SDUI

У всех реализаций, которые попадались мне на глаза, есть общая черта - собственный DSL. JSON-схемы, кастомные конфиги. Для каждого решения приходится учить новый язык.

При этом Flutter-разработчики уже знают хороший язык описания UI. Он называется Flutter.

Это третья статья из серии про инженерные решения в ONEMIX — моём мессенджере на React Native. В первой я разбирал трёхуровневый кэш сообщений, во второй — реализацию Double Ratchet E2E. Сегодня — про звонки.

Звонки в мессенджере — это та функция, которая работает либо отлично, либо никак. Пользователь привык что WhatsApp/Telegram звонят мгновенно, показывают входящие на заблокированном экране, переживают переключения Wi-Fi/LTE, и работают из фона. Если твоя реализация делает хоть что-то из этого хуже — пользователь это сразу заметит и переключится на "нормальный" мессенджер.

Я потратил несколько месяцев на то чтобы довести звонки в ONEMIX до production-уровня. В процессе пришлось изучить WebRTC изнутри, разобраться с iOS CallKit и VoIP push notifications, и собрать десяток граблей которые в туториалах не упоминают. В этой статье — как это устроено, какие решения оказались критичными, и что бы я сделал по-другому.

Сразу оговорка. Я не использую готовые SDK типа Agora, Twilio, 100ms. У них отличное качество и поддержка, но они не дают полного контроля над процессом — а для мессенджера контроль критичен. Когда звонок не проходит, пользователь винит приложение, а не "SDK от третьей стороны". Плюс готовые SDK стоят денег, которые на раннем этапе продукта лучше направить в другие места.

В прошлой статье про трёхуровневый кэш сообщений я уже упоминал, что делаю мессенджер ONEMIX на React Native. Базовое E2E у меня было простое: ECDH P-256 для обмена ключами при первом контакте, AES-GCM для шифрования каждого сообщения общим секретом. Это работает, но имеет одну проблему: общий секрет один на всю переписку. Если у одной из сторон скомпрометируют приватный ключ — все сообщения за всё время превращаются в открытый текст.

Это называется отсутствием Perfect Forward Secrecy (PFS). И это значит, что человек, к которому в руки попадёт твой телефон через год, может прочитать переписку из прошлого года. WhatsApp, Signal, и серьёзные части Telegram давно используют другую схему — Double Ratchet — которая ключи переизбретает заново на каждом сообщении. Так делают потому, что любой ключ компрометируется в один момент времени, и компрометация не должна давать доступа ни к прошлому, ни к будущему.

Я реализовал Double Ratchet с нуля для ONEMIX. В этой статье разберу:

Я делаю мессенджер ONEMIX на React Native. К моменту, когда я начал писать этот пост, в нём уже больше десятка экранов, групповые WebRTC-звонки через LiveKit, E2E на Double Ratchet + Sealed Sender, push-нотификации с cold-start навигацией и десктоп-версия на Electron. Но самым важным куском, который определяет ощущение от приложения, оказался не звук и не видео. А то, насколько быстро открывается чат.

Если вы хоть раз делали список сообщений на React Native, вы знаете эту боль: открыл чат — пустой экран на 200–800 мс, потом подгрузка, потом скачок при докрутке наверх. В Telegram такого не бывает: открыл — мгновенно увидел последние сообщения, прокрутил наверх — никаких пустот, история идёт сплошной лентой.

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

Как я с помощью AI автоматизировал процессы своей мини‑пекарни — 3,5 месяца разработки, 2 071 коммит, два ИИ‑ассистента и VPS с 2 ГБ RAM

Тема разграничения доступности действий в рамках конкретного тенанта выходит далеко за рамки ERP домена и требует особо пристальной реализации. Это особенно применимо для коммерческих систем (коей и является Kroncl - название системы), в которых классический RBAC требует определённых доработок, включающих адаптацию к упрощённой features-based access control (в народе - FBAC, является своего рода реализацией ABAC). Кроме того, технологические компании крайне редко (уникальные случаи всё же есть) посвящают публичные статьи внутреннему устройству своих систем тарификации, что крайне печально, ведь это буквально могли быть рассказы о том, как архитектурные решения напрямую влияют на маркетинг и как следствие доходность компании.

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

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

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

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

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

Сидел я значится между двумя ноутбуками, на одном из которых играла музыка. Динамики старые и стерео выдают в неприкрытом моно. Между звуками барабанов и синтезаторов в моей голове прозвучала мысль — «А давай‑ка одновременно включим музыку на двух ноутбуках, получу ли я музыкальное наслаждение?» — Получил это музыкальное наслаждение я аж целых три года назад, тогда же появилась идея оформить сеё чудо в виде приложения, которое бы захватывало системный звук устройства и раздавало бы его на динамики любых других устройств (Компьютеры, планшеты, телефоны…), включая устройство захвата.

В этой статье я разберу паттерн Entity Registry — плоский реестр сущностей на базе Zustand, который автоматически нормализует любые ответы API, хранит данные в едином словаре по ID и обеспечивает точечный ре-рендер только тех компонентов, чьи данные действительно изменились. Отдельно разберём трюк с enumerable: false для мягких удалений — пожалуй, самую изящную часть паттерна.

Меня зовут Виталий, я из команды ArcaneGaming.
Сегодня я хочу рассказать вам о своем пет-проекте, который немного вышел из-под контроля и превратился в полноценный продукт.
Встречайте - Snuffer!

😫 С чего всё началось?
Знаете это чувство, когда вам пишет клиент (или, что еще хуже, мама):

Ключевые аспекты проектирования и реализации SCADA-систем в автоматизированных системах управления технологическими процессами (АСУТП). Основное внимание уделяется интеграции с базами данных, такими как SQL Server, и использованию протокола OPC UA для взаимодействия с контроллерами.

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

Знаете это чувство, когда сидишь на очередном спринт-планировании, команда пытается оценить таски, а планинг покер тормозит так, что успеваешь кофе сварить, пока карточка загрузится?

Вот у меня в AGG TEAM такая же история была. Мы пробовали:

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

И будет здорово, если их первая реакция будет не «ну, работает», а «вау, это выглядит как полноценный продукт».

Почему разработчикам вообще стоит задумываться о пользовательском опыте? Кажется, что это зона ответственности product/project-менеджеров, UX-дизайнеров и аналитиков. Но на практике у разработчиков в мобильных проектах есть довольно большая свобода влиять на UX-детали.

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

Меня зовут Алексей Цуцоев, я Frontend TeamLead в KODE. В этой статье разберу несколько библиотек, которые позволяют быстро улучшить UX React Native-приложения без значительных затрат на разработку.

В горнодобывающей промышленности точный учёт рейсов карьерных самосвалов — ключевой фактор управления производительностью. Традиционные системы диспетчеризации (DISPATCH от Modular Mining, Wenco, российская «Карьер») опираются на GPS-зоны: система фиксирует въезд самосвала в зону экскаватора или пункта разгрузки и по факту пересечения геозон формирует рейс. Однако этот подход не улавливает аномалии внутри цикла — простои, заторы, сбои датчиков, затянувшиеся обеды — и не позволяет классифицировать тип рейса по его «форме».

Альтернативный подход реализован в системе «Симуляция и детекция рейсов» — серверно-клиентском приложении (Go + React + PostgreSQL), которое распознаёт рейсы в реальном времени путём шаблонной векторизации телеметрических данных скорости и веса. Вместо привязки к координатам система строит вектор из скользящего окна телеметрии и сравнивает его с заранее сохранёнными эталонными шаблонами через меру сходства (косинусное сходство или нормы L1/L2). Когда степень совпадения превышает порог — рейс считается обнаруженным.

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

В этой статье я расскажу о том, на каком этапе сейчас находится разработка нашего устройства: о литье пластиковых деталей, создании приложения для iOS и Android, поездке аппарата в США и работе над новым прототипом.

Сначала коротко о том, зачем нам это было нужно.

Мы в основном пилим решения для фудтеха, а для мобилок используем React Native (почему, рассказывали тут). 

В одном из таких проектов (российская сеть ресторанов по франшизе) нам нужно было прикрутить Яндекс Карты. Изначально хотели взять либу react-native-yamap (респект тем, кто ее делал) — но как выяснилось, она работает только на старой архитектуре RN. 

После обновления до 0.76 версии, где Fabric стала использоваться по умолчанию, приложения на iOS начали падать: карта не рендерится, события не доходят до JS, приложение крашится при взаимодействии с картой и вот это вот всё. И судя по открытым тикетам, мы не одни, кто столкнулся с этой проблемой. 

Полезли искать, написал ли кто-то уже библиотеку под новую архитектуру — но либо таких людей нет, либо ни с кем не делятся. Спойлер: мы пока тоже не будем, ещё обкатываем либу на своих проектах — но уже сейчас хотим рассказать, как собрали новый пакет с помощью Claude Code за два дня.

B4 - инструмент обхода DPI на Go с веб-интерфейсом.

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

Эта статья - перевод поста в блоге Alex, Baton Corporation Team Lead, вышедшего 20 февраля 2026 г.

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

Меня зовут Алексей Цуцоев, сейчас я Frontend TL в KODE. Эту статью я писал, когда только устроился в компанию и мне нужно было систематизировать навыки, передать свой опыт стажерам и просто высказать свои мысли относительно styled. Вижу, что до сих пор многие начинающие разработчики сталкиваются с такой же проблемой, как я в прошлом, поэтому статья вышла из нашей внутренней конфы в мир. 

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