Основное предназначение A/B тестов — оценить эффективность вносимых изменений и, в случае увеличения целевых метрик, зафиксировать эти изменения, а в случае снижения — откатить. Как правило, один из критериев хорошего дизайна A/B-теста — это конкретное и реалистичное с практической точки зрения время его проведения.

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

Рост команды требует большего вовлечения в процессы и договорённости, которые, в свою очередь, требуют автоматизации и инспекции. Можно взять bash‑скрипты и закрыть ими эту потребность, но насколько это будет удобно? Тут нужен инструмент, который упростит разработку и будет поддерживать команду в будущем. Сегодня расскажу про один из таких инструментов — Fastlane — и его возможности.

Статья будет полезна для ознакомления с Fastlane, тем, кто ищет решения для разработки автоматизации или рассматривает альтернативные решения по автоматизации сборок и процессов внутри компании. Для наглядности все примеры запускаются локально, это же решение можно перенести на CI/CD (Gitlab, Jenkins, Github Actions и тп).

Всем привет! Меня зовут Игорь Титов, я системный инженер в компании Garage Eight и сегодня я расскажу о том, как мы увеличили скорость разворота в два раза и значительно повысили эффективность нашей dev-инфраструктуры.

Звучит как начало истории про успешный успех, где в конце будет предложение купить курс… Но нет!

Каждая стратегия масштабирования имеет свои плюсы и минусы. Почему бы не начать комбинировать их и оставить только плюсы? Поговорим об этом — как сделать хорошо, когда нельзя просто закопать — в контексте PHP. 

В этой статье мы рассмотрим, как и почему изменилась реализация примитивов синхронизации из стандартной библиотеки Java и пакета java.util.concurrent для Kotlin Coroutines и для языка Kotlin в целом.

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

Оценим готовность текущих решений к использованию в Kotlin Multiplatform.

Разработаем аналоги нескольких полезных классов пакета java.util.concurrent, до которых еще не добрались разработчики корутин.

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

«Он рассмеялся, весьма довольный своим остроумием. Но смеялся он один», — Рафаэль Сабатини.

Очень давно мне хотелось опубликовать эту статью, но я откладывал и публиковал технические материалы. Если вы видите ее в ленте, значит, пришло время. Статья не несет интеллектуальную нагрузку, кроме, возможно, той, которую придадите ей вы. Любители ставить минусы за низкий технический уровень материала — можете смело пролистывать (но мы-то знаем: вы мимо не пройдете). А остальным предлагаю заглянуть под кат и ознакомиться с репортажем про жизнь морских свинок в IT-компании Garage Eight. Репортаж отражает мою личную интерпретацию событий.

В начале 2021 года в Garage Eight было 900+ тестов, около 80 job в pipeline с автотестами на RobotFramework и больше 15 фича-команд. Отчёты о прогонах мы отправляли в Slack, при этом не использовали системы сбора и отображения отчётов (Allure, Report Portal и др). Всё работало отлично, пока… пока часть наших микросервисов не была перенесена в Kubernetes, и пока однажды нам не пришлось искать причину регулярных падений двух десятков тестов из разных сьютов.

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

Ниже будет инструкция по поиску проекта для ML-инженера с амбициями PM или для PM с пониманием ограничений сферы ML. Хотя для тех, кто «просто спросить», тоже есть что почитать. 

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

Далее речь пойдет о системе, которая работает на основе стека prometheus alertmanager + с учетом того, что микросервисы развернуты в кубере. Итак, приступим.

В незапамятные времена, когда еще не вышла последняя серия «Во все тяжкие», алерты чаще всего хранились в одном месте — будь то icinga, zabbix, TICK stack или тот же самый Prometheus. В этом есть свои плюсы — можно легко отслеживать изменения, грепнуть нужный алерт, накидать CI и так далее. Но когда речь заходит о микросервисной архитектура, где бизнес логика представлена отдельными сервисами, было бы логичным держать бизнес алертинг рядом с микросервисов.

Что ж, давайте попробуем реализовать такой подход.

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

Привет, Хабр! Меня зовут Даниель, я занимаюсь машинным обучением в Garage Eight.

Решил рассказать о работе ML команды в горизонтальной структуре и особенностях такого подхода.

Всем привет! 

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

Всем привет. Меня зовут Женя, я работаю, как это сейчас модно говорить, DevOps-инженером в компании Garage Eight. 

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

Однажды перед нами встала задача максимально быстрой доставки сообщений из пункта A в пункт B. Условия были таковы:

* Перед тем как сообщение достигнет пункта назначения, оно проходит ряд сервисов;

* Каждый сервис выполняет определенный набор действий над этим сообщением;

* Скорость прохождения сообщений через весь путь должна быть минимальной;

* Брокер сообщений должен работать стабильно 24\7.

В статье я расскажу, как мы это делали

Привет, Хабр! Меня зовут Андрей Гончаров, я дата-инженер в Garage Eight, и сегодня я расскажу о том, как мы подходим к батч-процессингу и нашей self-service платформе данных. Почему self-service? Традиционный подход к работе с данными подразумевает, что данные готовят и перемещают между информационными системами дата-инженеры.

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

Давайте посмотрим, как мы решаем описанные проблемы.

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

Привет, Хабр! Меня зовут Юра Кучанов, работаю Android разработчиком в Garage Eight и сегодня хочу рассказать о том, как мы делали Retrofit-подобную библиотеку для JSON-RPC протокола. Началось всё с того, что нам потребовалось для общения сервера и Android приложения использовать протокол JSON-RPC. Что значит “потребовалось”? Если кратко – бэкендеры предложили, а сильных аргументов против, в сущности, не нашлось =) Возможно, тут сработала, например, вот эта статья с хабра про выбор между REST и JSON-RPC. В итоге я пошёл искать библиотеки в сети и… И обнаружил, что готовые решения не подходят (так как там, конечно же, есть хотя бы один фатальный недостаток). В итоге сделал свою библиотеку в стиле Retrofit. Ниже расскажу, почему не подошли готовые решения, как реализовал своё через рефлексию и как копался в исходниках Retrofit и OkHttp для реализации нужного нам функционала.