фреймворк для разработки нативных приложений
AnkiAI-Cards - мобильное Android приложение с помощью ИИ генерирует карточки по шаблону и отправляет их напрямую в AnkiDroid внутри смартфона. Помогает изучать иностранные слова ассоциируя с контекстом фраз и предложений.
В статье представлен разбор создания CRM-системы, разработанной с применением искусственного интеллекта для ускорения кодинга и архитектурного планирования. Проект представлен как будущий полигон для построения хорошего фреймворка для автотестирования с помощью Python.
Привет, Хабр. Это история о том, как я делал ставки 7 лет, потом бросил, а потом написал приложение, которое помогло бы мне бросить раньше. Расскажу и про продуктовые решения, и про техническую часть: React Native + Expo, полностью офлайн-архитектура без бэкенда, шесть языков, и как сейчас выглядит публикация в Google Play для нового индивидуального аккаунта разработчика.
Разбираем очень неприятный баг в React Native + iOS: почему push-уведомления сохраняются на Android, но теряются на iOS в background/killed state. В статье обсудим как на самом деле устроены APNS, Notification Service Extension, App Groups и почему проблема вообще не в React Native. Будет интересно…
Пришла мне как-то идея сделать мобильное приложение на базе Telegram. Полез в npm и сразу нашёл react-native-telegram, но это оказалась обёртка над Bot API и тут я понял, что будет весело.
У Telegram с инструментами для разработчиков в целом нормально — Bot API, MTProto, TDLib. Только под RN ничего нет и вряд ли когда-то будет, насколько я знаю уже есть популярные Telegram-клиенты на React-Native, но видимо они не стали упаковывать это в библиотеку и делиться опытом с народом.
Кто пробовал запилить свой клиент Telegram на RN, тот знает, что без хороших навыков нативной разработки особо ничего не получится. В какой-то момент я устал мучиться с patch-package и кучей натива внутри RN проекта, поэтому решил, что пора это упаковать в либу. Через два года и одиннадцать релизов она оказалась в официальной документации TDLib.
Это девятая статья про инженерные решения в ONEMIX. Тема узкая, push-уведомления. Но я её давно хотел разобрать, потому что туториалов в интернете много, а production-граблей в них почти нет.
Если коротко, туториал по push выглядит так. Регистрируешь токен через Notifications.getExpoPushTokenAsync(). Отправляешь на бэкенд. Когда приходит пуш — addNotificationResponseReceivedListener ловит тап, навигируешь в нужный экран. Всё.
В реальном мессенджере таких туториалов недостаточно. Появляется десяток узких проблем. Пуш приходит когда юзер уже в этом чате. Пуш приходит когда приложение убито системой. Navigation после открытия из пуша добавляет дублирующийся экран в стек. На iOS звонки идут через отдельный канал VoIP который требует совершенно другой инфраструктуры. Эти грабли я и разберу.
Это седьмая статья про инженерные решения в ONEMIX. Тема узкая, но болезненная для каждого кто делал мобильное приложение с отправкой сообщений или файлов.
Сценарий с которого всё началось у меня. Пользователь в чате выбирает большое видео, нажимает отправить. Видео начинает грузиться. Пользователь нетерпеливый, прокручивает вверх посмотреть переписку, потом переходит в другой чат, потом возвращается. Что должен он увидеть?
В Telegram он увидит свой видео‑бабл с прогрессбаром, как и оставил. В большинстве самописных мессенджеров он увидит пустой чат без своего сообщения, потому что upload жил в state экрана, а экран размонтировался. XHR продолжал работать в фоне, файл загрузился на сервер, но результат пришёл в null, потому что setter уже не существует. Сообщение фактически отправлено, но пользователь об этом не знает.
Это боль которая лечится не «правильным useState», а отдельным архитектурным слоем. Этот слой называется outbox. В этой статье разберу свою реализацию из ONEMIX, это 820 строк TypeScript которые делают то что в Telegram кажется естественным.
Привет, Хабр. Меня зовут Карим, я 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 такая же история была. Мы пробовали: