Как тестировать несколько мобильных приложений в одном «Appium‑проекте». Показываю архитектуру фреймворка, запуск тестов через аннотации, потокобезопасный контекст и подключение новых приложений без дублирования кода.
Помните времена, когда пуш-уведомление реально что-то значило? Телефон вибрировал, и ты точно знал: случилось что-то важное. Такси подъехало. Деньги списались. Начальник написал что-то срочное (ладно, обычно не срочное, но хотя бы по делу).
Это был 2016 год.
На дворе 2026-й. Шторка уведомлений среднего пользователя превратилась в мусорный бак, куда маркетологи сбрасывают свои KPI с маниакальным упорством.
Мы умудрились взять гениально простой инструмент доставки ценности и превратить его в систему психологического давления. Давайте разберем, где конкретно мы свернули не туда, и как разработчику не участвовать в этом цирке с конями.
Худшая новость для многих SaaS‑команд в ближайшие годы (думаю, уже в этом году заметим) пользователь может перестать пользоваться вашим приложением, но продолжить пользоваться вашим сервисом.
Еще недавно цифровой продукт был устроен предельно понятно. Компания делала приложение, проводила продуктовые исследования, проектировала пользовательские сценарии, раскладывала кнопки, экраны, роли и ограничения. А пользователь либо принимал эту логику, либо уходил.
То есть сама модель была такой:
«Вот наш интерфейс. Вот наш сценарий. Пользуйтесь так, как мы задумали».
Эта модель не исчезнет завтра. Да и на текущий момент она устраивает болшинство пользователей, благодаря сформировавшейся десятилетиями потребительской привычке «используй что дают». Но именно сейчас она начинает терять монополию, потому что между пользователем и сервисом появился новый слой – агенты. Не просто чат-боты, которые подсказывают, а инструменты, которые уже умеют искать данные, ходить по сайтам, нажимать кнопки, связывать сервисы между собой и выполнять цепочки действий. OpenAI вывела Operator как браузерного агента, Anthropic продвигает Computer use и MCP, Microsoft на Build 2025 прямо говорит об open agentic web, а OpenAI отдельно документирует работу с remote MCP servers и коннекторами для доступа к внешним сервисам. 
И вот здесь начинается главное изменение – раньше продуктом был интерфейс, теперь продукт всё чаще смещается в три других слоя:
В новом выпуске замена циклов рекурсией и Android на десктопах, нарезание Android-монолита и промпт-контракты, снижение комиссии в Play Store, потери органики и что с этим делать, скрытый bottleneck сборок и многое другое. Заходите!
Когда регулярно ревьюируешь чужой код или менторишь младших коллег, начинаешь замечать паттерны. Есть ошибки, которые кочуют из скрипта в скрипт, и совершают их не только джуны, но и вполне уверенные специалисты.
Сегодня разберем пять неочевидных нюансов SQL, которые могут незаметно исказить бизнес-метрики, сломать воронку или просто заставить базу выполнять лишнюю работу.
Вы спокойно работаете, и тут к вам приходит продакт с вопросом по A/B-тесту, который запустили две недели назад. «Ну что, мы уже набрали достаточно трафика? Можно подводить итоги?».
И всё бы ничего, но есть нюанс: на встречу по дизайну этого эксперимента вас позвать забыли. Длительность никто не считал, MDE (Minimum Detectable Effect) не фиксировал.
Чтобы ответить на вопрос продакта, вам нужно посчитать MDE с учетом текущего размера выборки и дисперсии, а затем сравнить его с порогом практической значимости. Выгружать сырые данные только ради того, чтобы посчитать дисперсию в моменте — занятие довольно муторное, особенно если речь идет о неконверсионных (непрерывных) метриках. Даже на highload-проектах, где данных море, тратить время на лишние ETL-операции ради промежуточного чека совсем не хочется.
Но, к счастью, у вас под рукой есть A/B-платформа, которая уже услужливо посчитала доверительный интервал. Например, она показывает вам отложенный эффект: 2% ± 1.5%.
Держите лайфхак: берем половину ширины доверительного интервала (те самые 1.5%), умножаем на 1.43 и получаем наш текущий MDE.
Давайте разберем математику, которая за этим стоит.
CJM в аналитике: почему ваши клиенты уходят и как это увидеть в данных
Вы наверняка видели красивые CJM-картинки с эмоциями, лицами и стрелочками, это красиво, но бесполезно, потому что настоящая карта пути клиента строится на данных, CJM – это не про «нарисовать портрет клиента», это про цифры, воронки и узкие места.
В этой статье я рассказываю:
- Что такое CJM с точки зрения данных (и почему это не про эмоции);
- SQL-скрипты для построения воронки, расчета времени между этапами и анализа переходов;
- Как искать узкие места, где клиенты реально страдают (и теряются деньги).
👉 Без абстракций, с кодом и готовыми данными для проверки.
Ситуация вокруг форка телеге откровенно подзадолбала. Одни пишут статьи из трех пунктов в духе «все плохо, пользоваться ОПАСНО», но без конкретики: где нашли уязвимость и как она применяется — непонятно. Блогеры же, наоборот, топят за «положительные примеры», но аргументация у них на уровне «поверь мне, брат».
Всё это выглядит неоднозначно. Даже так называемые «детальные разборы» не убеждают, потому что написаны в том же стиле, что и реклама у стримеров, хоть и есть какие никакие аргументы. но их мало для нормизов, а осведомленные люди сами могут все зачекать. Статьи от задрота для заброта
Я не эксперт, не профессиональный автор и уж точно не претендую на звание грамотея. Но раз уж мы живем в эру нейромусора, решил вкинуть "свой" анализ. Я провел два аудита декомпилированной программы через JADX с помощью VS Code Copilot (модель Opus 4.6).
Ниже привожу всё, что выдала нейронка в качестве финального вывода. Версия программы 2.3.1
Как превратить ваше приложение в инклюзивный продукт, который используют ВСЕ - от слабовидящих до людей с когнитивными нарушениями. Плюс секретные фишки, о которых молчит документация Apple.
Это руководство создано не для того, чтобы вы просто поставили галочку в Jira. Мы поговорим о том, как код может стать мостом или стеной для миллионов людей.
Создание комфортной среды для жизни — это не только архитектура и дизайн. Технологичность — такая же часть комфорта, как удобство двора или качество сервиса. Сегодня жители ожидают, что всё, что связано с домом, доступно из смартфона: от оплаты счетов до вызова мастера. В этой статье поделимся нашим опытом — как в Sminex мы создаём собственную цифровую экосистему Sminex — нативное мобильное приложение и единый бэкенд, построенные на современном стеке. Расскажем, почему мы отказались от коробочных вариантов, как выстраивали архитектуру и какие инженерные решения легли в основу продукта.
Почему мобильное приложение — это база
Мобильное приложение стало основным каналом коммуникации между жителем и управляющей компанией. Для жителей это привычный, удобный и быстрый способ решать любые вопросы. Для компании — прозрачные процессы и снижение нагрузки на кол-центр.
В Sminex за обслуживание домов отвечает своя Служба комфорта. Это больше, чем классическая управляющая компания. Служба комфорта Sminex — это команда, обеспечивающая премиальный уровень сервиса, инфраструктуру и цифровые инструменты для комфортной жизни. Очевидно, что приложение для клиентов должно соответствовать этим стандартам — быть современным, удобным и технологичным.
Как мы работали раньше и почему ушли от готовых решений
Раньше мы работали с личным кабинетом на SharePoint и нативным мобильным приложением. Оно выполняло базовые задачи, но со временем стало очевидно: архитектура достигла предела масштабируемости, производительность просела, а развивать функционал стало сложно. Требуемую доступность 24/7 оно не обеспечивало.
Снова привет, Хабр
разоблачение телеграм клиента Telega, что скрывается за оберткой обхода блокировок
В новом дайджесте происходит что-то серьезное: наложенные окна и 37 000 unit-тестов против Gradle, новый Flutter и эксперимент с эмоциональным банкингом, Developer Knowledge API от Google, опасности в Android, подводные камни миграции на Swift и многое другое. Заходите!
Это говорят не слабые дизайнеры.
Это очень распространенная проблема:
• Стартап без аналитики
• Отдел в корпорации, в котором есть только верхнеуровневые метрики или вообще никаких
• Клиент, который просто хотел красиво
И вот ты сидишь с кейсом, а в графе результаты у тебя пусто и как то даже стыдно.
В общем то решил я как-то попробовать перейти на Linux phone. Но решил сделать это тестово и дешевым способом, купил себе Xiaomi Poco X3 NFC за 5 тыс. руб на Авито, хорошенько потанцевал с бубнами и накатил себе Ubuntu Touch.
Как часто бизнес задает вопрос о результатах A/B-теста уже на второй день после запуска? В классической статистике основной ответ: необходимо ждать набора фиксированной выборки, иначе риск ложноположительного результата становится неконтролируемым. Однако современные подходы позволяют не только проводить мониторинг данных без риска математической ошибки, но и останавливать эксперименты значительно раньше срока. В основе такой гибкости лежит методология mSPRT, которая превращает эксперимент из закрытого процесса в прозрачный поток данных.
Вместо пассивного ожидания можно использовать концепцию доверительных последовательностей и всегда валидных p-значений. Эти инструменты сохраняют свою математическую силу независимо от того, как часто проверяются промежуточные итоги. Ключевую роль в настройке системы играет параметр смешивания тау, который помогает найти тонкий баланс между чувствительностью к минимальным изменениям и скоростью получения итогового результата.
Работа с реальным трафиком требует адаптации теории к специфике бизнеса. В статье разбирается, как метод линеаризации помогает применять последовательный анализ к сложным показателям вроде конверсии или среднего дохода на пользователя. Также рассматриваются ситуации, когда стандартная математика может давать сбои из-за экстремальных выбросов с тяжелыми хвостами распределения или изменения характеристик трафика во времени. Чтобы исключить ложные срабатывания, вводится система защитных механизмов, которая делает выводы устойчивыми к случайному шуму.
Такой метод позволяет сократить время проведения тестов на 30-50%, не жертвуя при этом достоверностью. Это способ сделать процесс проверки гипотез более гибким и быстрым, сохраняя безупречную математическую строгость в каждой точке принятия решения.
В AB-тестах нередко возникает желание смотреть на результат по ходу эксперимента: метрики обновляются, решения ждать долго, а если эффект уже очевиден, то зачем тянуть до конца. Но в этом месте легко допустить серьезную ошибку: регулярно пересчитывать обычное p-значение и завершать тест при первом p < 0.05. Такой подход повышает долю ложных срабатываний: иногда статистическая значимость появляется просто из-за случайных колебаний данных, даже когда реального эффекта нет.
В этой статье разбираем, почему так происходит, и что с этим делают в прикладной аналитике. Покажу, как устроено групповое последовательное тестирование (group sequential): вы заранее задаете несколько контрольных точек для подглядывания, а пороги принятия решения подбираются так, чтобы общий уровень ошибки первого рода по всему процессу оставался на заданном уровне alpha.
На простых формулах и наглядных графиках из симуляций сравним наивное подглядывание с корректной процедурой. А затем разберем два самых популярных набора порогов - Pocock и OBrien-Fleming: чем они отличаются, почему один вариант чаще завершает эксперимент раньше, а другой почти не дает принимать решения в начале, и как выбрать подходящий вариант под продуктовый процесс.
АБ-тесты — это дорого. Как проверять гипотезы, если у вас нет времени или трафика. АБ-тестирование давно закрепилось как «золотой стандарт» проверки гипотез. Но у него есть обратная сторона: это дорого, долго и требует огромного трафика для достижения статистической значимости. Иногда бизнес просто не может позволить себе ждать месяц, чтобы узнать, что кнопка «Купить» должна быть синей.
Показана численная близость 
-значений 
-теста, 
-теста и 
-критерия Манна-Уитни в А/Б-тестах вероятностям лучшей группы байесовских моделей. Соотношения выполняются несмотря на различия в определениях.
Возвращаюсь с первым дайджесте в этом году. В нем про SwiftLint в масштабах компании, Android и ICMP, стабильный Compose Hot Reload и следующие два года в области разработки программного обеспечения, японская игра о скачках, электроналиватор и многое другое. Заходите!
Когда релиз раскатан не на всех, классическая схема "до" и "после" начинает рушиться: метрика растет или падает одновременно из-за сезонности, внешнего фона и изменений в каналах, а не только из-за продукта. При этом AB теста может не быть, но данные по группам есть почти всегда: по гео, сегментам, кластерам, витринам.
В этой статье разбираю два практических подхода, которые позволяют оценить эффект релиза в таких условиях. Первый - diff-in-diff: сравниваем, насколько изменилась метрика в затронутой группе относительно контрольной, и тем самым вычитаем общий фон, который влияет на всех. Второй - синтетический контроль: строим базовую линию для затронутой группы как сумму метрик нескольких контрольных групп с весами, подобранными так, чтобы до релиза эта конструкция максимально повторяла историю затронутой группы.
Отдельный акцент на том, что обычно искажает выводы: заметный рост или падение разницы между группами до релиза, изменения состава, локальные акции или технические инциденты в контрольных группах, а также ситуации, когда базовая линия плохо повторяет период до релиза и тогда мы измеряем в основном ошибку модели, а не эффект релиза. В конце показываю, какие проверки стоит сделать, чтобы результат не держался на удачно выбранных границах периода или на одной контрольной группе.
Если в первой части мы работали с одной временной линией метрики, то здесь переходим к более распространенному случаю: несколько групп, частичная раскатка и необходимость отделить влияние релиза от общего шума.
