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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Бэкенд / другое
Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

Программный комитет ещё не принял решения по этому докладу

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

Основы успешной кампании оптимизации web-приложения. Пошаговая стратегия на примере крупного Интернет-магазина

Николай Червоненко

- Куда смотреть - вширь или вглубь? Как принять решение по оптимизации работы вашего приложения.
- Определяем цель и границы шагов по оптимизации. Как могут помочь логи web-сервера?
- Достижение целей оптимизации в кратчайшие сроки или глубина и качество оптимизации.
- С чего начать оптимизацию? Какая из используемых технологий проекта даёт сбой и когда?
- Выявление ключевых узлов приложения и воспроизведение проблем в лабораторных условиях. Визуализация проблем с помощью графиков и системы мониторинга.
- Исправление ошибок проектирования. Рекомендации.

Программный комитет ещё не принял решения по этому докладу

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

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

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

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

API
,
Аналитика / другое
Программный комитет ещё не принял решения по этому докладу

You Suck at Postgres

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

Вся работа с Linux/Unix/BSD базируется на работе с файлами. GUI для администрирования – зло.

С СУБД PostgreSQL то же самое.

Используя вашу любимую «программу для работы с СУБД», вы меня очень расстраиваете. Вы создаёте кучу ошибок. Прячете от себя важные делали работы системы за визуальным GUI-шумом, нарисованным каким-то умником. В общем, вообще не понимаете, что там творится.

Хватит.

Хватит ныть про медленное выполнение запросов и непонятки с работой СУБД. Пора взять в руки себя, psql, vim и tmux, нырнуть в недра PostgreSQL и начать действовать like a pro.

P. S. Apologies to Matt Bledsoe, Troy Hitch [1], and Joel Spolsky [2].

[1] https://en.wikipedia.org/wiki/You_Suck_At_Photoshop_(web_series)
[2] https://www.youtube.com/watch?v=0nbkaYsR94c

Программный комитет ещё не принял решения по этому докладу

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
,
Оптимизация производительности
,
Распределенные системы
,
Технологии виртуализации и контейнеризации
,
Непрерывное развертывание и деплой
Программный комитет ещё не принял решения по этому докладу

Аппаратно-организационные сложности запуска сервиса видеонаблюдения

Максим Лапшин

Мы смогли сделать продукт Flussonic Watcher, позволяющий за месяц запустить у оператора связи сервис по абонентскому видеонаблюдению: это когда пользователи платят за хранение видео с IP-камеры у оператора.

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

Я хочу поделиться опытом, который мы получили при выходе из internet-only продукта в физический мир абонентских устройств. Этот опыт может быть интересен не только в контексте IP-камеры, но и остальных IoT-устройств.

WebRTC, WebGL и веб-медиа в целом
,
Защита информации
,
Бизнес на стыке онлайн и офлайн
,
Онлайн-медиа (видео/аудио)
Доклад принят в программу конференции

Как построить документирование на базе Sphinx, ReST, Git, LaTeX и PHP

Елена Василенко

Sphinx Docs собирает документацию из файлов в формате reStructuredText. Многие разработчики используют его в своих проектах. Но как быть, если нужен инструмент документирования для всей компании - руководителей, маркетологов, разработчиков, офис-менеджера и т.д. Расскажу, как мы решили это для себя, используя нехитрые технологии - Sphinx, ReST, Git, LaTeX и PHP, запилив на их базе редактор документаций "для всех", который активно используется уже более года.

Из доклада вы узнаете, как мы выбирали техническую базу, пройдя через Wiki и Google Docs. Какие грабли можно словить при реализации и внедрении и как их обойти. Отдельно остановлюсь на генерации в форматах LaTeX и PDF, на организации git в документациях.

Программный комитет ещё не принял решения по этому докладу

Apache Spark Streaming - потоковая обработка событий клиентов и их отображение на интерактивной карте

Александр Сербул

Расскажем о тонкостях проектирования и реализации высоконагруженного лямбда-сервиса потоковой обработки хитов (событий) клиентов Битрикс24 и их отображения на "живой карте" на основе API Яндекс.Карты.

Поделимся опытом приручения Amazon Kinesis, непростым выбором между Apache Kinesis/Kafka/Storm/Flume и кейсами эффективного использования Apache Spark Streaming.

Отдельно остановимся на реализации серверной кластеризации/растеризации для быстрой работы Яндекс.Карт. Ссылка на проект: https://www.bitrix24.ru/online-domains-map

Взаимодействие с серверной стороной (API)
,
Веб-графика, оптимизация изображений
,
Machine Learning
Программный комитет ещё не принял решения по этому докладу

Сопутствующие разделы

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

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

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

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

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

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

Удалённая работа с иностранным заказчиком. ИП, валютный контроль, патент

Дмитрий Воронин

- Удалённая работа как таковая. Зачем и почему
- Средства взаимодействия с заказчиком. Мониторинг времени, заданий
- Юридический договор с заказчиком. Наши и его интересы. Тонкости юр. перевода
- Выбор банка для ИП. Валютный контроль
- Отчетность для налоговой. Патент

Работа с зарубежным заказчиком/рынком
,
Юридические вопросы
,
Взаимодействие с государством
Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

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

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

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

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

Бэкенд / другое
Программный комитет ещё не принял решения по этому докладу

Простота хуже воровства: как не дать Hibernate положить твою базу

Александр Буянов
Юрий Горынцев

ORM, наверное, самый популярный паттерн для работы с реляционной СУБД, но, как и любая абстракция, нередко протекает. Обучаясь по tutorial'ам в интернете можно быстро собрать работающее приложение на Spring/Hibernate, но с развитием проекта и усложнением доменной модели простые решения в начале оборачиваются ужасными запросами и под нагрузкой система падает. Учитывая, как сильно обычно маппинг всё связывает, рефакторинг становится непростым и в какой-то момент возникает стойкое отвращение к ORM и к Hibernate, в частности.

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

API
,
Java
,
Базы данных / другое
,
Организация доступа к базам данных, ORM, собственные драйвера
Программный комитет ещё не принял решения по этому докладу

Время использовать Serverless — разбираем наиболее интересные кейсы

Кирилл Потехин
Василий Сочинский

Serverless-архитектура становится всё более доступной и популярной, потому что позволяет сконцентрироваться на программировании, а не на администрировании. В рамках данного доклада мы разберём основные кейсы использования serverless:
- создание REST API;
- реализация системы аналитики приложения;
- event-driven-системы (анализ логов, оптимизация использования ресурсов, системы учёта и пр.).

Кроме того, мы расскажем про фреймворк, с помощью которого можно удобно разрабатывать serverless-решения для платформ AWS, Microsoft Azure и Apache OpenWhisk.

Фреймворки
,
API
,
Бэкенд / другое
,
Проектирование информационных систем
,
Бэкенд мобильных приложений
Программный комитет ещё не принял решения по этому докладу

Консервативный 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
Доклад принят в программу конференции

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

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

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

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



Программный комитет ещё не принял решения по этому докладу

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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