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

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

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

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

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

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

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

Привет, Хабр!

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

Привет, Хабр! Сегодня хочу поделиться небольшим примером того, как можно проводить кластерный анализ. В этом примере читатель не найдет нейронных сетей и прочих модных направлений. Данный пример может служить точкой отсчета для того, чтобы сделать небольшой и полный кластерный анализ для других данных. Всем заинтересованным — добро пожаловать под кат.

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

Под катом приглашаю посмотреть, как легко писать свои ограничения и расширять имеющиеся на примере базовой валидации и валидации сравнения двух полей. Статья может быть интересна тем, кто еще мало знаком с валидацией в Symfony или пока обходил стороной возможности написания своих валидаторов.

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