Фестиваль РИТ++ 2017 завершён. Ждем вас на РИТ++ следующего года!

Заявки на доклады

Конференция BackendConf проходит в рамках профессионального фестиваля "Российские интернет-технологии". Вам, как участнику конференции, доступны все доклады этой конференции.

Кроме этого, Вы cможете посетить все общие доклады фестиваля, интересные широкой публике, и специализированные доклады конференций блока серверных технологий: конференции "RootConf 2017", "HighLoad++ Junior 2017".

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

Участники конференции Backend Conf также имеют возможность бесплатного прохода на любой из докладов смежной конференции HighLoad++ Junior. Конференция будет проходить параллельно в соседнем зале. Такое решение принял Программный комитет, когда устал ломать голову над тем, куда отнести тот или иной доклад :)

Поиск по тегам:

Базы данных

Брокер сообщений Kafka в условиях повышенной нагрузки

Артём Выборнов

Kafka - распределённый брокер сообщений, нашедший широкое применение как универсальная шина для больших данных. Kafka позволяет как реализовать realtime-обработку большого числа событий, так и построить батчевый pipeline по доставке логов.

Почему мы используем Kafka? Если коротко - унификация. А если чуть подробнее - десятки поставщиков, терабайты логов каждый день, онлайн- и офлайн-pipeline'ы - без единой высокопроизводительной шины данных с этим крайне сложно совладать.

Из доклада вы узнаете о том, почему мы перешли на Kafka, и как она вписалась в наш pipeline. Поймёте, как обеспечить exactly once доставку данных. Узнаете о том, как из-за одной опечатки в несколько раз выросла нагрузка на Kafka, и что мы из этого выяснили. Выясните, какие метрики Kafka стоит мониторить и как по ним понять, что что-то идёт не так.

Бэкенд / другое
,
Базы данных / другое
,
Распределенные системы
,
Администрирование баз данных
,
Devops / другое
,
Hadoop
,
ETL
Доклад принят в программу конференции

Postgres vs Mongo

Олег Бартунов

Я хочу немного порушить стереотипы, что Postgres - это чисто реляционная СУБД из прошлого века, плохо приспособленная под реалии современных проектов. Недавно мы прогнали YCSB для последних версий Postgres и Mongodb и увидели их плюсы и минусы на разных типах нагрузки, о которых я буду рассказывать.

На самом деле, Postgres довольно давно может работать со слабо-структурированными данными, в том числе и с json, и довольно быстро, по крайней мере, на одном сервере он обгоняет Mongodb на всех видах нагрузки из известного бенчмарка YCSB, который был разработан и используется для тестирования NoSQL-баз данных. При всем этом Postgres представляет полный ACID и развитую функциональность, проверенную временем, что дает возможность очень большому количеству проектов использовать просто его.

Я также расскажу про наши проекты по улучшению json - реализацию SQL/JSON стандарта в Postgres и компрессию jsonb.

PostgreSQL
,
MongoDB
Доклад принят в программу конференции

Как ускорить MySQL Handler Socket в 9 раз посредством репликации в Tarantool

Александр Яковлев

Мы использовали MySQL Handler Socket в качестве интерфейса к данным пользователей на высоконагруженном проекте Wamba.ru. Почему Handler Socket? Потому что стандартный SQL-интерфейс не выдерживал наши нагрузки. Время шло, нагрузки росли, и в итоге и HandlerSocket перестал справляться. Мы только успевали доставлять и доставлять реплики MySQL, чтобы распределять увеличивающуюся нагрузку между ними.

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

К счастью, мы нашли способ решить эту проблему одним выстрелом и без закупок вообще. Наоборот, даже высвободили железо и не знаем, куда его девать. Как нам это удалось? Узнаете в моем докладе.

Доклад принят в программу конференции

Наш ответ Uber'у

Александр Коротков

Опубликовав в своём блоге знаменитую заметку о переезде с PostgreSQL на MySQL, Uber наделал много шума в постгресовом сообществе. Для многих из разработчиков PostgreSQL это стало толчком к осознанию несовершенства постгресового табличного движка (который пока всё ещё один). В результате было разработано множество патчей, нацеленных на преодоление проблем, указанных Uber'ом, которые в чём-то пересекаются, а в чём-то даже противоречат друг другу. Среди этих патчей можно отметить indirect indexes (индексы, которые ссылаются на значение primary key), WARM (write-amplification reduction method – уменьшение избыточности записи), RDS (recently dead storage – хранилище для недавно устаревших версий). Также ведётся обсуждение подключаемых табличных движков и undo log'а.

В данном докладе будет разобран пост Uber'а глазами разработчика PostgreSQL. Я расскажу, с какими пунктами "обвинения" я согласен, с какими не согласен, а с какими – согласен частично. Также я разберу разработки сообщества в данном направлении и то, насколько они, на мой взгляд, позволяют преодолеть указанные недостатки.

PostgreSQL
,
MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

Что нужно знать об архитектуре ClickHouse, чтобы его эффективно использовать

Алексей Зателепин

ClickHouse - высокопроизводительная аналитическая база данных с открытыми исходниками, разработанная в Яндексе. Изначально ClickHouse создавался для задач Яндекс.Метрики, но постепенно нашёл множество применений как внутри Яндекса, так и в других компаниях. Я расскажу, как ClickHouse устроен внутри с акцентом на то, какие у выбранной архитектуры следствия с точки зрения прикладного разработчика.

Будут затронуты следующие темы:
- Как ClickHouse хранит данные на диске и выполняет запрос, почему такой способ хранения позволяет на несколько порядков ускорить аналитические запросы, но плохо подходит для OLTP и key-value нагрузки.
- Как устроена репликация и шардирование, как добиться линейного масштабирования и что делать с eventual consistency.
- Как диагностировать проблемы на production-кластере ClickHouse.

Базы данных / другое
,
Оптимизация производительности
,
Распределенные системы
Доклад принят в программу конференции

Мониторинг и отладка MySQL: максимум информации при минимальных потерях

Света Смирнова

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

В докладе я хочу обсудить, какие опции должны быть включены всегда, какие опциональны и при каких обстоятельствах их включать. Мы рассмотрим встроенные возможности MySQL, Percona-серверов и внешние решения.

Администрирование баз данных
,
MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

Полнотекстовый поиск в PostgreSQL

Александр Алексеев

Не всем известно, что в PostgreSQL есть полнотекстовый поиск. Притом, в отличие от некоторых других РСУБД, в PostgreSQL этот поиск совершенно полноценный и способный посоревноваться в скорости и качестве со специализированными решениями. Что не менее интересно, используя полнотекстовый поиск PostgreSQL, вы можете избавиться от дублирования данных, экономя тем самым место на диске, трафик и обеспечивая согласованность данных.

Из этого доклада вы узнаете, как использовать для полнотекстового поиска PostgreSQL GIN, GiST, а также новый RUM-индекс, в чем заключаются преимущества и недостатки названных индексов, как с их помощью сделать поиск по документами или, например, саджестилки, и не только.

Поисковые системы
,
PostgreSQL
,
Базы данных / другое
Доклад принят в программу конференции

Что нового в MySQL 8.0?

Дмитрий Ленев

8.0 - это следующая крупная версия СУБД MySQL Server, которая на данный момент находится в активной разработке. Цель данного доклада - познакомить слушателей с новыми возможностями и улучшениями производительности,которые реализованы в этой версии.

В частности, мы поговорим о:
- новом словаре данных, связанных с ним изменениях в INFORMATION_SCHEMA, а также поддержке атомарного DDL;
- новых возможностях в выполнении запросов - поддержке Common Table Expressions и Window функций, "невидимых" и descending индексах;
- улучшениях в поддержке Unicode;
- возможностях более гибкой работы с блокировками в запросах (SKIP LOCKED/NOWAIT);
- ролях и других изменениях в системе привилегий;
- улучшениях в репликации.

Доклад принят в программу конференции

Обзор перспективных баз данных для highload

Юрий Насретдинов

В этом докладе я рассмотрю несколько перспективных, на мой взгляд, баз данных, которые пока еще не очень популярны, но которые определенно ждет успех в будущем, особенно для highload-проектов. Я расскажу о Tarantool, ClickHouse и CockroachDB, о том, как они устроены, и почему я считаю, что они в будущем станут стандартом де-факто, как раньше был MySQL, а сейчас — MongoDB.

Коротко о каждой из них:
1. Tarantool — разработка mail.ru, позволяющая обрабатывать до 1 млн транзакций в секунду на одном ядре процессора за счет «конвейерной» архитектуры. В данный момент SQL не поддерживается, но можно писать хранимые процедуры на LuaJIT, что позволяет делать сложные выборки и преобразования, не жертвуя производительностью.
2. ClickHouse — это real-time аналитическая база данных от Яндекса с поколоночным хранением данных и невероятной производительностью работы. Основной язык запросов — SQL. Авторами заявляется скорость вставки на уровне 100 мб/сек и скорость сканирования в 1 млрд строк в секунду. Также поддерживается работа в кластере с репликацией и шардированием, приближённые выборки по части данных, ограниченные джойны и многое другое.
3. CockroachDB — база данных от создателей Google Spanner. Авто-масштабируемая распределенная SQL-база данных, написанная на Go и использующая RocksDB для хранения данных на диске. Если вы устали от необходимости ручного шардирования и отсутствия распределенных транзакций в SQL-базах данных и от неконсистентности и неуправляемости NoSQL-решений, то CockroachDB нацелен именно на вас. База данных сама масштабируется на выделенные узлы, сама поддерживает заданный фактор репликации, может работать в нескольких ДЦ, и многое другое.

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

MongoDB
,
Tarantool
,
Базы данных / другое
,
Аналитика / другое
,
MySQL (MariaDB, Percona Server)
Доклад принят в программу конференции

Простая и дешёвая бизнес-аналитика на базе Google BigQuery

Алексей Паршуков

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

На примере DocDoc я расскажу о плюсах и минусах различных подходов: как выбрать систему хранения, почему мы остановились на Google BigQuery. Как правильно организовать данные, записать свой clickstream, отказаться от сэмплирования в GA, а также строить простые и понятные отчеты.

Базы данных / другое
,
Архитектура данных, потоки данных, версионирование
,
Продажи, конкуренция и аналитика
Доклад принят в программу конференции

NewSQL: SQL никуда не уходит

Константин Осипов

Что такое NewSQL, почему NoSQL-движение превращается в NewSQL, и что эта трансформация привносит в SQL?

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

Рассмотрим новые диалекты языка SQL, такие как:
- Cassandra QL
- Couchbase NQL
- Elastisearch
и сравним их с подходом MongoDB & RethinkDB, добавляющим новый язык работы с данными.
Останется ли в мире СУБД что-то ценного от NoSQL-движения?
Ну и, наконец, рассмотрим новый вызов реляционной модели: multi-model databases.

Доклад принят в программу конференции

Организация разработки

Реверс-инжиниринг архитектуры Amazon S3 по документации API и реализации

Владимир Перепелица

В этом докладе я хочу подробно рассмотреть анализ API Amazon S3 по описанию и поведению и как я проектировал и создавал аналогичный сервис в рамках Облака Mail.ru.

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

Доклад будет состоять из следующих тем:
- как следует анализировать внешний API, на что обращать внимание;
- как построить модель и проверить её;
- отличия хорошей и плохой архитектуры облачного сервиса;
- как проверять свои гипотезы и предсказывать нагрузку.

API
,
Архитектурные паттерны
,
Работа с Amazon
,
Критерии выбора технологий для проекта
Доклад принят в программу конференции

TDD: когда нужно и, самое главное, когда не нужно

Павел Калашников

TDD - Test Driven Development. Разработка через тесты.
Очень многие знают про эту методологию, очень многие хотели бы использовать, далеко не все используют.

На этом докладе мы разберём:
* когда стоит использовать TDD в разработке проекта;
* когда НЕ стоит использовать TDD, потому что он будет мешать;
* несколько аргументов для тимлида, заказчика, PM и т.д., которые помогут разработчику продвинуть TDD в проект;
* о применении TDD в продуктовой разработке и в аутсорсе.

Бэкенд / другое
Доклад принят в программу конференции

Как потратить 4 года и мешок денег на рефакторинг и ничего не запустить

Максим Чистяков

Итак, вам повезло - у вас большой проект с многолетней историей. Проблема в том, что многолетняя история - это чаще всего значит много legacy кода, на который стыдно смотреть и тяжело делать всё остальное. И вот в один прекрасный момент все понимают, что так жить больше нельзя и нужно (всё) менять. Здесь самое опасное - начать всё переписывать заново. Почему это плохо и к чему это привело у нас, в Ultimate Guitar, и будет посвящён этот доклад.

В докладе будет:
- разбор типичных ошибок, которые допускаются при рефакторинге;
- как "выйти " из затянувшегося рефакторинга;
- нехитрые техники и приёмы, которые используются в Ultimate Guitar для улучшения кодовой базы;
- как сделать так, чтобы программистам не приходилось "продавать" рефакторинг;
- как и когда выкатывать рефакторинг, чтобы не было всем (по-крайней мере большинству) мучительно больно$
- jMeter, Graylog, Pinba, Zabbix и прочие демоны, или как рефакторить бэкенд без $$.

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

Фреймворки
,
Миграции данных
,
API
,
Платёжные системы, обработка платежей
,
PHP
,
Рефакторинг
,
Методы и техника разработки ПО
,
Непрерывное развертывание и деплой
,
Большие проекты/команды
,
Продуктовая разработка
Доклад принят в программу конференции

Сложный проект с нуля: сквозь воду, огонь и медные трубы

Филипп Дельгядо

Последние два года я делаю платежную систему с нуля.

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

В нашем проекте мы последовательно прошли через:
* "Воду" - разработку проекта внутри без точного понимания требований потребителей и клиентов, с долгими итерациями, нечеткими постановками, редкими демо и долгосрочным планированием;
* "Огонь" - период запуска с частыми выкладками, очень краткосрочным планированием и легким ощущением постоянного напряжения;
* "Медные трубы" - работу с живым проектом, с регулярными безопасными обновлениями, заботой о клиентах и ритмичной работой с четкими, но многочисленными и разноплановыми задачами.

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

Доклад принят в программу конференции

Рабочие ситуации и задачи

Миллион WebSocket и pub/sub

Сергей Камардин

Большое количество живых соединений с сервером требует решения интересных и порой неоднозначных задач. Речь будет идти о том, как в условиях доставки тысяч уведомлений в секунду миллионам пользователей иметь возможность управлять потребляемыми ресурсами, производить безболезненные рестарты и при этом иметь "план Б" на случай непредвиденных проблем.

Доклад расскажет историю запуска системы уведомлений между сервисами mail.ru и их пользователями.

Тезисы:
- Какие проблемы несет в себе большое количество соединений.
- Как не допустить ситуации self-ddos.
- На чем можно экономить память.
- Как все это дело реализовать с помощью Go.

Доклад принят в программу конференции

API AppMetrica изнутри, или SQL без SQL'я

Ефим Пышнограев

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

На чём мы остановимся:
1. Архитектура сервиса.
2. Разные способы хранить и обрабатывать события.
3. Как выглядят данные, по которым мы строим отчеты.
4. Примеры задач и соответствующие запросы к API.
5. Как обработка запроса выглядит в коде.
6. Выводы: прелести и ограничения своего языка запросов.

API
,
Аналитика / другое
Доклад принят в программу конференции

REST-сервисы на ASP.NET Core под Linux в продакшене

Денис Иванов

С релизом .NET Core для программистов, использующих .NET-стек, открылись все возможности Unix-мира. .NET-приложения могут отлично работать на Linux, а значит, мы можем использовать Docker и Kubernetes для развертывания сервисов.

В своем докладе я расскажу, как сделать REST-сервис на ASP.NET Core и запустить его в продакшн на платформе Kubernetes.

Мы погрузимся в детали инфраструктуры ASP.NET Core и нескольких популярных библиотек, поговорим про многопоточность, оптимизацию и кэширование для уменьшения времени ответа сервиса. Обсудим, как решать задачи билда приложения и сборки Docker-образов. И, конечно же, подробно остановимся на том, что такое Kubernetes, как эта технология может быть нам полезна и как ее использовать.

Фреймворки
,
API
,
Бэкенд / другое
,
Микросервисы, SOA
,
Оптимизация производительности
,
Распределенные системы
,
Технологии виртуализации и контейнеризации
,
Непрерывное развертывание и деплой
Доклад принят в программу конференции

Элементы архитектуры

Поиск наоборот: материализуем результаты поиска

Николай Сивко

Наш сервис мониторинга постоянно обрабатывает миллионы метрик от агентов, установленных на серверах наших клиентов.

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

Я расскажу, как нам удалось материализовать результаты поиска для повторяющихся запросов:
* материализация запросов в хранилище;
* перколяция ("обратный" поиск; ищем, каким запросам соответствует документ) при записи метрик;
* чтение из кэша;
* вымывание устаревших метрик.

Немного о системе:
* основное хранилище: cassandra;
* поиск: elasticsearch (100 млн. документов без учета репликации);
* поток записи: ~100 тысяч метрик в секунду.

Организация системы кеширования
,
Оптимизация производительности
Доклад принят в программу конференции

Консервативный Backend на Node.js

Дмитрий Ляпин

Я расскажу об опыте разработки REST API сервиса одной рекрутинговой платформы. Стремясь найти простое и масштабируемое решение, мы выбираем PostgreSQL и Node.js, а вместо сессий используем JWT-токены. Избегая ORM, мы пишем большие и сложные, но эффективные SQL-запросы. На помощь приходят SQL-представления, триггеры и небольшая собственная JS-библиотека.

Проделав несколько неудачных итераций, мы находим такое решение по организации структуры проекта, благодаря которому весь код Backend'а умещается в 4 директории без вложенных папок. Мы используем сервисы Amazon: EC2, RDS, SES; и написали небольшой медиасервис, работающий поверх S3. Он умеет масштабировать картинки на лету и является единой точкой загрузки файлов.

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

API
,
PostgreSQL
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Архитектурные паттерны
,
Работа с Amazon
Доклад принят в программу конференции

Как мы отказались от Skype и внедрили WebRTC на основе janus-gateway

Сергей Сафонов

Мы строим платформу (vimbox) для проведения уроков английского один на один.

Наши учителя и ученики общаются на платформе. Видеосвязь построена на WebRTC с использованием janus-gateway (https://github.com/meetecho/janus-gateway).

В докладе будут раскрыты следующие вещи:
- почему нам не подходит skype & hangouts;
- что мы пробовали до janus-gateway;
- что такое janus-gateway, и какие возможности у него есть;
- что сделать, чтобы все видеовстречи записывались;
- как на основе записанных данных получить видео обычного формата;
- как масштабировать;
- проблемы такой видеосвязи;
- какие существуют аналогичные решения.

Бэкенд / другое
Доклад принят в программу конференции

Система подготовки видео для стриминга на платформе ivi

Евгений Россинский

Для того чтобы подготовить видео к стримингу на большое количество типов устройств, нужно сделать несколько шагов - от подготовки метаданных до упаковки в разные контейнеры (MP4, DASH, HLS) с разным битрейтом.

Мы построили гибкую систему с приоритетами, которая учитывает потребности бизнеса в скорости подготовки видео и умеет работать с пятью DRM-системами. Архитектурное решение основывается на жонглировании Docker-контейнерами и включает в себя как аппаратные средства для кодирования видео, так и софтверные.



Доклад принят в программу конференции

Linux API с точки зрения разработчика высокопроизводительного веб-сервера

Валентин Бартенев

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

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

Тестирование, A/B-тестирование

Держим дизайн системы под контролем, используя изолированное юнит-тестирование

Андрей Коломенский

Код наших систем со временем загнивает из-за низкого качества обратной связи, которую дают интегрированные тесты.

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

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

Обеспечить непрерывное повышение качества системы с помощью быстрых изолированных юнит-тестов можно только с помощью дисциплины Test Driven Development или написания тестов до кода (Test First). Это утверждение можно проверить, выбрав не покрытую тестами часть системы, которая выглядит качественно, и попробовав зафиксировать её поведение с помощью изолированных тестов. Степень легкости процесса будет соответствовать степени тестопригодности системы.

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

Интеграционное тестирование
,
Юнит-тестирование
Доклад принят в программу конференции

TDI: высокочувствительная метрика для A/B экспериментов с поиском

Роман Поборчий

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

Однако проверить более высокую эффективность нового алгоритма экспериментом оказывается непросто: разрешающая способность классических метрик A/B-тестирования часто недостаточна, чтобы увидеть результат работы нового алгоритма.

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

В докладе я рассмотрю уже ставший классическим алгоритм Team-Draft interleaving, дающий возможность проводить эксперименты на пользователях поиска и получать высокую значимость при сравнительно небольших объёмах данных. Также я расскажу о нескольких проблемах, с которыми столкнулся при эксплуатации этого алгоритма, и об их решениях.

Алгоритмы и их сравнение
Доклад принят в программу конференции