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

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

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

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

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

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

Меня зовут Виталий, я из команды 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 или только начал их изучение этого стека.

Мы хотели запустить приложение в нише 18+ всего за неделю. Звучало как идеальный план, но на деле это вылилось в три года работы и вечный бан в Google Play. В статье я расскажу, как мы пытались обмануть систему, набивали шишки с React Native и в итоге заменили отдел маркетинга на скрипты в n8n. Это история о том, как потерять аккаунт разработчика, но все-таки построить прибыльный продукт

Процесс разработки

Выбор между классическим подходом и Expo – одно из первых архитектурных решений в проекте. Разберем оба варианта.

Bare React Native

Процесс требует настройки окружения (Xcode для iOS, Android Studio для Android). В упрощенном виде процесс запуска приложения для разработки выглядит следующим образом:

Старая архитектура с Bridge

В основе этой архитектуры лежат асинхронный Bridge. Нативный код и JavaScript работали в отдельных потоках. Общение между ними происходило через Bridge, который передавал сообщения в формате JSON.

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

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

Изначально может показаться, что здесь сложного практически ничего нет: есть toFixed() и toLocaleString(), но практика показывает, что реальные интерфейсы почти никогда в это не укладываются.

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

Именно с этим сталкиваются разработчики при работе с таблицами, отчётами, финансовыми данными и аналитикой.

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

Ниже опишу требования к форматированию, которые легли в основу функции, и покажу, как они отражаются в коде и в интерфейсе.

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

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

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

В статье представлена подборка ресурсов с качественными и интересными UI-компонентами. Список будет дополняться по мере появления действительно достойных сайтов и сервисов.

❕ - пометка нового контента в статье.
[Статья обновлена 7 марта 2026 года]

Итак, 5 ноября команда JFrog опубликовала предупреждение об уязвимости CVE-2025-11953 в инструментах командной строки проекта React Native Community CLI. React Native — это платформа которую используют тысячи разработчиков для создания мобильных приложений, которые мы видим в App Store или Google Play. А React Native Community CLI через командную строку предоставляет инструменты для разработки и сборки этих приложений, куда как раз и входил злополучный пакет.

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

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

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

Отпуск, целых две недели, без программирования.
К вечеру первого дня уже не знал чем себя занять. Работать мне запретили.. гады.
Как ещё может отдыхать программист? Делать новый pet-project.

Надеюсь на картинке не я...

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

Чтобы совместить полезное с полезным, заодно соберём небольшое приложение — простой трекер веса и тренировок — и посмотрим, как на практике работает мультиплатформенная разработка на React с Expo. Спойлер: почти то же самое, что и обычная разработка на React — и, похоже, именно она окончательно забивает гвоздь в гроб Dart/Flutter и прочих попыток конкурентов сделать вид, что React — это страшный сон, который можно забыть.

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

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

Привет, Хабр! На связи снова Саша Мищенко, тимлид платформенной команды в Профи.ру. И сегодня я хочу поделиться нашей поучительной историей переезда с нативного кода на React Native.

Если кратко, то было интересно и иногда даже страшно...

Привет, Хабр! Меня зовут Георгий, и я тимлид команды платформы в компании Купер. Мы специализируемся на разработке IT-приложений для маркетинга и бизнеса, включая кроссплатформенные мобильные решения на базе React Native. В этой статье я хочу поделиться опытом работы с пуш-уведомлениями. Расскажу, с чего мы начинали, какие проблемы встретили и к чему пришли на текущий момент. Все примеры возьму из свежего проекта, исходники которого доступны на GitHub — ссылку оставлю в конце.

Привет, на связи снова я – React-разработчик Дмитрий. Сегодня отвлечемся от теории и разберем конкретный случай и какое решение для него использовалось.

При работе с готовыми UI-библиотеками часто возникает небольшая проблема —  компонент хорош, но его поведение нельзя настроить под требования конкретного случая. Я столкнулся с этим на практике, когда в используемой версии UI Kit не было возможности кастомизировать тексты выводимых ошибок, а бизнес-требования четко задали формулировки.

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

Собственно, выглядит компонент загрузки файла вот так:

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

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

Поэтому компании все чаще обращаются за кастомными решениями. Но у самих разработчиков могут возникнуть вопросы: 

Недавно нам нужно было добавить чат в админку одного из проектов. Забавно, но решения вроде Jivo или LiveChat мы даже не рассматривали. Так были уверены, что сможем без проблем собрать кастомный чат прямо внутри Admiral.

Эксперимент завершился удачно и теперь мы хотим поделиться его результатами. В этой статье мы предлагаем вам готовый туториал по интеграции сложной функциональности на примере real-time чата.

Если хотите перестать выглядеть полными профанами и дать юзерам что-то, что не падает при первом же обрыве связи — welcome to local-first apps. Здесь всё про то, чтобы сделать локальную базу, а синхронизация — это такая себе приятная бонусная функция, а не священный грааль.

В этом гайде я покажу, как без боли и слёз запустить связку Laravel + Admiral с полной авторизацией. Ни строчки лишнего кода, и ни минуты на сомнительные патчи.

Всем привет! Меня зовут Дмитрий, и я руководитель фронтенд-разработки в компании Интелси.

Сегодня хочу рассказать о принципе единственной ответственности (Single Responsibility Principle) — первом из пяти принципов SOLID, сформулированных Робертом Мартином в его книге "Agile Software Development: Principles, Patterns, and Practices". Суть этого принципа звучит так: «Класс должен иметь только одну причину для изменения» (A class should have only one reason to change).

Как мы в Купере переписали CodePush для React Native. Быстрее, легче, удобнее

Всем привет! Меня зовут Евгений Прокопьев, я разработчик на React Native с 9-летним стажем. В этой статье расскажу, как мы в Купере написали собственный CodePush, который совсем не похож на продукт Microsoft.

React Native не справился. Flutter — как глоток свежего воздуха.

Рассказываем, как наша команда переписала большое приложение (60+ экранов, оффлайн режим, карта, камера) на Flutter, с чем пришлось повозиться и почему теперь не жалеем.

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

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

В 2022-м мы окончательно задолбались.

Каждый новый проект все по кругу: таблички, формы, фильтры, CRUD. Всё снова, как в Groundhog Day. Копипастить старое было больно, собирать с нуля – ещё хуже. И главное, ощущение абсурда: 2022 год, а мы продолжаем лепить админки вручную, будто на дворе 2015.

Окей, логичный шаг – найти готовое решение.

Мы правда пытались не изобретать велосипед

Первым делом пошли смотреть на CMS. Попробовали Strapi – мощный зверь, но если вам просто нужно бэку выдать пару CRUD’ов, то тянуть за собой целую экосистему с философией и особым образом жизни, это как стрелять из базуки по воробьям.

Дальше, дизайн-системы вроде Salesforce Lightning, Fluent UI и Fusion Design. Компоненты красивые, но по факту это просто UI-кирпичики. Всю бизнес-логику, связи между сущностями, обработку данных всё равно пишешь сам. Хотели сэкономить время, а получили “ты теперь ещё и архитектурой займись”.

React-Admin показался перспективным. Но мы быстро поняли, что он хочет, чтобы ты делал вещи его способом. А мы хотели делать их по-своему. Онбординг тяжёлый, кастомизация сложная, UI на любителя. Как часто бывает: сначала кажется, что ты взял инструмент, а потом он берёт тебя.

Мы поняли: компромиссы – это медленно