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

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

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

React Native прошел путь от решения с фундаментальными архитектурными ограничениями до платформы с современным, производительным ядром. В этой статье мы разберем, как работала старая архитектура на основе Bridge, как ее заменили JSI, Fabric и Hermes, и в каких случаях React Native - оптимальный выбор для проекта.

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

Делимся практическим кейсом рефракторинга автотестов учетной системы: от линейных скриптов к архитектурному подходу, который ускорил написание тестов в три раза.

Современные комплексы бизнес-приложений отличаются высокой сложностью, из-за чего могут происходить сбои - сообщения теряются, consumer’ы падают, очереди переполняются. Поделимся реальным кейсом, в котором Eventual Consistency удалось обеспечить без серьезной переработки существующих систем.

В каждой крупной компании со временем накапливается огромное количество ценной информации — инструкций, регламентов, технологических карт, аналитических отчетов. Однако в большинстве случаев эти данные висят «мертвым» грузом в архивах и папках. Все необходимое где-то есть, но найти вовремя невозможно. Чтобы знания действительно начали работать на бизнес, нужен инструмент, который сможет оперативно доставить их тем, кому они нужны. И именно такую задачу решает ИИ чат-бот на основе технологии RAG (Retrieval-Augmented Generation).

Когда знаний много, но они не работают

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

Проблема не в нехватке данных — проблема в доступе к ним. Как итог:

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

Почему так происходит? И главное - что именно в таблице мешает работать с ней быстро и уверенно?

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

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

MDN Baseline badges и влияние на поддержку браузеров в Angular

Начать стоит не с самого Angular, а с важного обновления в веб-документации MDN (Mozilla Developer Network). Там появились Baseline badges (метки), которые позволяют быстро оценить, насколько целесообразно использовать новую фичу — например, часть браузерного API.

Trunk Based Development (от англ. trunk – «ствол дерева») – метод разработки кода на основе одной главной ветки. В отличие от Gitflow, TBD позволяет разработчикам добавлять новые модули сразу в master. Второстепенные feature-ветки также могут создаваться, но они имеют короткий срок жизни.

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

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

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

Для начала коротко о том, какие технологии легли в основу платформу. Про многие из них мы подробно рассказывали в отдельных статьях.

Некоторое время назад мы решили перестроить управление доступом к рабочему пространству мобильных команд. Изучили рынок и обнаружили, что бесплатная Google Cloud Platform вполне может составить конкуренцию платным решениям. В этой статье мы делимся своим опытом и даем инструкции по подключению. 

Уже около года команда поддержки одного из наших высоконагруженных продуктов использует ML-систему нашей собственной разработки – Problem Detection Platform (PDP). Этот сервис умеет анализировать логи и автоматически классифицировать возникающие ошибки. В результате саппорт получает из логов не тонны сырой информации, а данные, с которыми можно быстро и удобно работать.

Когда мы начали создавать платформу True Engineering, в компании не было единых правил для оформления архитектуры. Разные команды – разные инструменты, разные обозначения и уровни абстракции. Значит, даже подобные решения сравнить между собой не получится, а тому, кто смотрит на архитектуру проекта в первый раз, обычно нужен проводник, который расскажет, что же тут изображено. Мы решили унифицировать подходы с помощью модели С4, которая обеспечивает всестороннее описание программных архитектур.

Некоторое время назад появилась задача обновить монолит фронтенда большой высоконагруженной системы, работающей 24/7 – перевести с устаревшего фреймворка Knockout на современный React. Задача возникла, когда старая архитектура перестала соответствовать требованиям бизнеса. Команде поставили задачу реализовать новые функции, но в существующей архитектуре сделать это оказалось практически невозможно.  Хотим поделиться своим опытом, как сделать такой проект проще.

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

Технология Backend-for-Frontend упрощает разработку сервисов, с которыми одновременно работают множество разных клиентов: компьютеры, смартфоны и планшеты со всеми возможными ОС.

В прошлом, аналоговом мире корпоративными системами пользовались только сами компании. Чем больше развивалась цифровизация и омниканальность, тем больше фокус перемещался из корпоративной инфраструктуры вовне. Покупатели стали покупать товары онлайн и со смартфонов, бизнес-партнёры – взаимодействовать с компанией через веб-платформы. Бизнесу стало важно выстроить такую архитектуру, которая позволила бы открывать такой доступ к корпоративным ресурсам.

Serverless-вычисления и работающие на их основе решения Function-as-a-Service помогают разработчикам развивать продукты, ориентируясь на бизнес-фичи. Мы поэкспериментировали с этими технологиями и пришли к выводу, что для боевого применения существующие решения сыроваты. Пойдём по порядку.

Термин «бессерверные вычисления» отчасти вводит в заблуждение – конечно, в основе продукта сервера остаются, но разработчикам не приходится о них заботиться. По сути своей Serverless продолжает те же идеи виртуализации, что и более ранние aaS-технологии: позволить команде сосредоточиться на коде и развитии функций. Если IaaS – это абстракция оборудования, контейнеры – абстракция приложений, то FaaS – это абстракция бизнес-логики сервиса.