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

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

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

В единстве сила: как мы пишем тесты всей командой

Светлана Алексеева

Девопс кажется недостижимой мечтой, а лечь в направлении цели хочется уже сейчас?
Нам тоже.

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

Расскажу нашу историю успеха и поделюсь лайфхаками и подводными камнями.

Python
,
Code Review
,
Автоматизация разработки и тестирования
,
Функциональное тестирование
,
Автоматизация тестирования
Программный комитет ещё не принял решения по этому докладу

Тестирование ClickHouse, которого мы заслуживаем

Александр Сапин

ClickHouse это не только популярная поколоночная СУБД, но и быстроразвивающийся open source проект на языке C++. В неделю мы вливаем около 40 пул-реквестов, 15% из которых привносится внешними контрибьюторами. Такие темпы развития требуют хорошей автоматизированной инфраструктуры тестирования кода на всех уровнях.

В докладе я расскажу о том, как устроен CI ClickHouse и из каких компонент состоит pipeline тестирования. Сначала речь пойдёт об особенностях покомитных сборок ClickHouse с разными конфигурациями в различных OS. Затем будут рассмотрены все этапы тестирования начиная от статического анализа кода и заканчивая интеграционными тестами и тестами производительности. В заключении я расскажу о преимуществах, которые нам дает CI: удобство в обнаружении багов, организация двухнедельного релизного цикла и улучшение работы с контрибьюторами.

Технологии виртуализации и контейнеризации
,
Непрерывная интеграция
,
Функциональное тестирование
,
Нагрузочное тестирование
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
Программный комитет ещё не принял решения по этому докладу

Языки программирования

Функциональный подход в Enterprise .NET

Третьяков Антон Романович

1. Какие плюсы имеют функциональные языки вообще и конкретно F#.
2. Почему на данный момент невозможно взять и переписать своё приложение на F# либо использовать его как отдельный модуль.
3. Что бы хотелось перенять из F# в C# уже прямо сейчас, без каких фишек F# сейчас действительно сложно.
4. Какие на данный момент существуют самописные решения, библиотеки для написания кода в стиле "функциональщины".
5. Как у себя мы пытаемся решить такие проблемы и с какими неприятностями сталкиваемся.
6. Наконец, как можно использовать кодогенерацию Roslyn совместно с анализаторами кода, что бы получить преимущества функционального подхода и перекрыть минусы существующих решений.
7. Пример разработки простенького анализатора для реализации функционального Pipe

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

Аsync и await в production

Сергей Борисов

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

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

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

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

Оптимизация скорости интернет-магазина на Битрикс

Антон Тузлуков

- Какие инструменты мы используем.
- Самые узкие места, и как мы их обходим.
- Как измеряем скорость.
- Отдельно оптимизация google page speed.

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

Как устроена backend разработка высокотехнологичного стартапа

Константин Юревич

В докладе я расскажу о нюансах организации backend разработки в стартапе:

— Каковы принципиальные отличиях выбора технологий и архитектуры в рамках стартапа, где время играет против тебя и приходится идти на компромиссы;

— Критически необходимый набор скиллов, которыми должен обладать каждый backend разработчик в команде и о том, как мы подходим к выбору разработчиков;

— Как мы создавали MVP, а потом итеративно масштабировали его на сотни клиентов и тысячи запросов в секунду;

— Почему DevOps это не профессия, а часть культуры backend-разработки и что позволяет нам деплоить код по несколько раз в день;

— Сколько стоят ошибки и баги на продакшен-серверах и как они могут поставить крест на бизнесе, какие техники мы используем, чтобы этого не допустить;

Критерии выбора технологий для проекта
,
Архитектуры / другое
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Корпоративная культура и мотивация
,
Продуктовая разработка
,
Big Data и Highload в Enterprise
Программный комитет ещё не принял решения по этому докладу

Гибкое управление проектами в области машинного обучения и BigData

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

В докладе простыми словами расскажем, как применять популярные гибкие методологии (Agile, Scrum) в сложных проектах, связанных с машинным обучением, математикой, большими данными. Пройдем все этапы от проектирования, анализа, защиты бизнес-идеи и подбора команды, до оценок качества и конверсии сервиса «на бою». Разберем возможности быстрого запуска подобных проектов с использованием готовых облачных сервисов «Amazom Sage Maker», а также поделимся успешным опытом реализации ML-проектов внутри компании.

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

Backend-For-Frontend в мобильной разработке

Влад Крылов

В докладе расскажу о достоинствах паттерна Backend-For-Frontend на примере разработки мобильного API для iOS- и Android- приложений. 

- Рассмотрим организацию процесса, когда разработчик API и его продукт живет внутри команды мобильной разработки
- Сравним готовые движки для создания API движением мышки
- Определим, какие задачи покрываются только "честной" разработкой API c нуля

В результате увидим, насколько трудоемко создавать отдельное API для каждого клиента и какие выгоды это несет.

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

Тимлид вылупился: что дальше?

Вячеслав Циунчик

В “KODE” мы сами выращиваем тимлидов. Собираем грабли, делимся ими друг с другом, вырабатываем лучшие практики, пробуем признанные инструменты, итеративно развиваемся.

Автор доклада, как тимлид отдела backend-разработки, около года находится на тернистом пути становления профессионала в новом для себя амплуа.

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

Совместная работа, система контроля версий, организация веток
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Управление / другое
Программный комитет ещё не принял решения по этому докладу

Гитлаб на всю катушку

Антон Тузлуков

1. Какой функционал существует в гитлабе. О чем вы точно еще не знали.
2. В чем преимущество использования одного инструмента для разнородных задач.
3. Примеры использования CI, task менеджера, registry и wiki

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

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

Как мы эффективно масштабируем нейронные сети в продакшне

Иван Голованов

Нейронные сети всё больше и больше набирают обороты в самых разных областях. И это уже не тестовые проекты, а реально использование в продакшне с SLA и прочими радостями жизни. Как всего этого достичь, если уже имеется порядка 40 различных моделей на разных фреймворках? А если у вас ещё и несколько независимых команд машинного обучения?

В докладе я расскажу о нашем самописном сервисе DLFrame, который управляет нейронными сетями в продакшне, автоматически скалирует их, надёжно разделяет сети между командами.

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

Как разработать сервис и не разбиться о монолит

Александр Данковцев

Пару лет назад мы в Авито решили распилить монолит на микросервисы и с энтузиазмом принялись за эту задачу, которую, как мы думали, легко затащим за год. На деле всё оказалось куда сложнее. Мы даже не представляли поначалу, что нам предстоит.

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

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

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

API
,
Микросервисы, SOA
,
Архитектурные паттерны
,
Отказоустойчивость
Программный комитет ещё не принял решения по этому докладу

Хранилища данных на службе BI

Александр Крашенинников
Алексей Еремихин

Когда в компании надо принимать решения на основании показателей, отдел BI — главный помощник.

В ход идут пересечения потоков данных, витрины, data research и просто метод пристального взгляда.

Для решения всех возникающих случаев манипуляции данными не всегда существует универсальное хранилище, которое является серебряной пулей. Hadoop — это, как правило, высокий показатель latency, аналитические базы данных — не OLTP, в каких-то решениях отсутствует поддержка транзакционности.

В докладе рассмотрим, как мы в BI используем связку Exasol и Hadoop. Рассмотрим аспекты ETL и технические решения, которые мы используем для интеграции этих хранилищ.

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

Как использовать AWS, не обанкротиться и не уронить проект

Андрей Костенко

1. Почему short.cm выбрал AWS, и что мы за это платим.
2. Правильное использование EC2, ECS, load balancers, в том числе в условиях России.
3. Работа с системами хранения данных: RDS, Aurora, Dynamo DB, DMS.
4. Работа с lambda, API gateway и потоковой обработкой данных.
5. Мониторинг и масштабирование, в том числе со стороны финансов.

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

Cross DC services: problems and issues?

Андрей Маркелов
Сергей Бобков

В данном докладе мы расскажем про несколько подходов построения микросервисной архитектуры, в случае когда микросервисы расположены в нескольких дата центрам и они обмениваются данными с большой интенсивностью. Мы расскажем про паттерны и их реализацию:
- sidecar
- data provider
- client-side balancing

Фреймворки
,
Java
,
Бэкенд / другое
,
Базы данных / другое
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Непрерывная интеграция
Программный комитет ещё не принял решения по этому докладу

Воркшоп "Получаем Bounded Contexts с использованием Event Storming"

Евгений Пешков
Дамир Атыгаев

Мы расскажем про Event Storming — отличный способ проектировать, используя Domain Driven Design.

Поговорим про DDD и обсудим опыт использования. Попробуем спроектировать систему с помощью Event Storming.

Чем хорош Event Storming?

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

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

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

Разработка микросервиса для заготовки изображений на лету

Степан Потапов

Okko – онлайн-кинотеатр, поддерживающийся на огромном количестве устройств: web, iOS, Android, SmartTv, Play Station. Каждый из этих клиентов, а также каждый из производителей соответствующих моделей часто отличаются один от другого: размером диагонали, соотношением сторон экрана, UI и направлениями в решении бизнес-задач. Доставка улучшений в интерфейсе каждому клиенту со временем превратилась в долгий, негибкий процесс, в том числе связанный с необходимостью заготавливать изображения разного качества, размеров и смыслового наполнения.

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

Переход от Rest API к GraphQL на примере реальных проектов

Антон Морев

Разбор трех реальных кейсов внедрения GraphQL.

• Доводы за и против перехода на GraphQL.
• Как безопасно делегировать логику группировки данных на frontend и разгрузить backend-разработчиков.
• Использование на примере проекта с микросервисной архитектурой, монолита.
• Недостатки, которые мы осознали, только столкнувшись с ними.
• Инструменты для разработки с сервисов GraphQL в продуктах от Jetbrains.

Взаимодействие с серверной стороной (API)
,
API
,
PHP
Программный комитет ещё не принял решения по этому докладу

Как переписать фасетный поиск с Solr на Elastic и выдержать 4K RPS

Денис Сотников

* Что такое фасетный поиск, общие принципы работы.
* Как это было реализовано на Solr. Как мы обновляли данные в поиске. Почему мы решили взять ElasticSearch. * Как работать с legacy-кодом. Какая конфигурация кластера нам подойдет. Как обновлять данные в реальном времени без downtime.

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

On-boarding пользователей из CSV-файла - за пару дней сделаете?

Сергей Чеботарев

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

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

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

Отладка, эффективный поиск и устранение багов

Борис Козуб

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

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

В своем докладе я рассмотрю важность отладки, помогу структурировать ее. Поделюсь рядом идей, правил, которые помогут ускорить этот сложный процесс.

- Отладка — один из сложнейших этапов разработки.
- Влияние отладки на стоимость работ.
- Проблемы с отладкой у программистов.

- Типы ошибок.
- Логические ошибки — самые сложные.
- Обзор существующих методологий отладки.
- Отладка как двигатель профессионального роста.

- Итоговой алгоритм отладки.
- Метод утенка (Rubber duck debugging).
- "Правило 30 минут".
- Применение макросов.
- Отсекай, исключай.
- Делегируй специалистам.
- Костыли — допустимо, но не всегда и везде.

В конце рассмотрим несколько реальных кейсов.

PHP
,
Python
,
Прочие языки
,
Бэкенд / другое
,
Профилирование и отладка кода
Программный комитет ещё не принял решения по этому докладу

Голосовое управление в облачных веб-проектах с помощью "Яндекс.Станции" и "Google Assistant"

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

В докладе мы расскажем, как используем устройства и технологии Яндекс.Станции, Google Home, Irbis A и DEXP Smartbox для управления корпоративным порталом Битрикс24. Поговорим об алгоритмах и возможностях Google Ассистента и Яндекс.Алисы для распознавания голоса, определения намерения и разбора текста. Расскажем, как мы подружили эти технологии с нашими для создания Задач, событий в Календаре, Встреч, Совещаний и отправки Сообщений сотрудникам компании. Отдельно рассмотрим практики применения технологий машинного обучения для решения возникающих при голосовом управлении задач и как обходить подводные камни. Проанализуем возможности библиотеки deeppavlov.ai.

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

Фаззинг или тестирование мусорными данными

Максим Бакиров

Поисковый запрос в 2ГИС содержит 25+ параметров, начиная c введенного текста и заканчивая персональными предпочтениями пользователя. Чтобы обеспечить стабильную работу приложения, мы решили не ограничиваться тестовыми запросами, сгенерированными человеческой логикой. Так в нашей жизни появился фаззинг — тестирование приложения на неправильных, неожиданных или случайных данных.

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

C/C++
,
Поисковые системы
,
Бэкенд / другое
,
Отказоустойчивость
,
Оптимизация производительности
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Профилирование и отладка кода
,
Big Data и Highload в Enterprise
Программный комитет ещё не принял решения по этому докладу

Хороший специалист в эпоху кадрового голода. Выращиваем синьоров из студентов.

Антон Тузлуков

1.Наши кандидаты - кто они?
2.Школа программистов. Сколько времени и какие усилия нужны для становления полноценного разработчика из студента - hello world
3.Онлайн обучение как ключевой канал обучения программистов из регионов и привлечения талантливых ребят в коммерческую разработку
4.Развитие штатных специалистов внутри компании, внутренняя политика основанная на обучении
5.Выявление талантов на ранних этапах и быстрый путь в тимлиды. Какими качествами должен обладать разработчик, чтобы быстро расти

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

Нейросеть вместо художника: как мы автоматизируем производство «штучных» изделий с помощью машинного обучения

Иван Голованов

В нашей компании Adalisk (подрядчик крупнейшей в США компании по зубному протезированию GlidewellDental) мы занимаемся автоматизацией производства зубных протезов – коронок, мостов, имплантов и т.д.

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

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

Low-code и RAD-разработка enterprise-систем и приложений: преимущества и ограничения

Алексей Оприщенко

1) Можно ли, вообще, организовать процесс создания программных продуктов так, чтобы каждый раз не изобретать велосипед?
2) Как и почему high productivity aPaaS так развивается во всем мире? Что в России?
3) Возможно ли разработать рабочий программный продукт БЕЗ программирования? Причём тут Visual integrated development environment (IDE)? Какие есть ограничения с точки зрения стандартов решений, глубины проработки и бизнес-логики.
4) Проблема традиционной разработки (мировой опыт, цифры).
5) Что такое RAD и Low-code (примеры).
6) Преимущества Low-code для разработки сложных enterprise систем.
- Case: объединение нескольких IT-систем крупного холдинга в одну с помощью low code.
- Case: Мобильное приложение для удержания клиентов и low code.

Шаблонизаторы и препроцессоры
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
JavaScript
,
Разделение представления и бизнес-логики, шаблонизация
,
Методы и техника разработки ПО
,
Автоматизация разработки и тестирования
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Технологии “быстрых решений”, “быстрого прототипирования”
,
Разработка CRM и ERP
Программный комитет ещё не принял решения по этому докладу

Почему вам не нужны микросервисы

Антон Тузлуков

1. Сколько нужно ресурсов и компетенций для организации микросервисной архитектуры
2. Когда стоит и не стоит использовать микросервисы
3. Сколько стоят микросервисы для бизнеса
4. Почему иногда лучше использовать CMS
5. Плюсы и минусы монолитной и микросервисной архитектуры

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

Базы данных

Массовый скоринг в CRM - секреты и подводные камни. (технический)

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

В докладе расскажем, как мы делаем скоринг Лидов и других сущностей в массовой CRM Битрикс24. Подробно разберем процессы алгоритмического и математического проектирования, создания действующего пилота, анализа данных, управления рисками проекта, тюнинга облачного сервиса "Amazon Machine Learning". Рассмотрим возможности "Amazon Sage Maker" и его технологического стека. Поговорим о несбалансированных данных, как с этим жить, выборе фич и действительно работающих оценках качества классификации. Углубимся в продвинутую оптимизацию с помощью байесовского поиска через hyperopt, байесовскую статистику, вероятностное программирование, MCMC (Markov chain Monte Carlo) и открывающиеся новые возможности машинного обучения для бизнес-применения.

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

MySQL 8 vs MariaDB 10.3 - сравнение возможностей

Петр Зайцев

В 2018 году после нескольких лет интенсивной разработки вышли MySQL 8 и MariaDB 10.3. Каждая из этих DBMS предоставляет уникальные возможности, недоступные в альтернативе.

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

MySQL (MariaDB, Percona Server)
Программный комитет ещё не принял решения по этому докладу

nbtree-индексы в PostgreSQL. Полезные новинки

Виктор Егоров

nbtree-индексы существуют в PostrgeSQL более 20 лет, это основной и самый используемый тип индексов. В 12-й версии были внесены существенные изменения в то, как работают эти индексы.

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

Затем поговорим о том, какие изменения были сделаны для 12-й версии PostgreSQL (выйдет осенью 2019 года) и о заложенных возможностях для будущих улучшений.

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

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

Отказоустойчивый кластер Postgreql+ Patroni. Реальный опыт внедрения

Виктор Еремченко

Я расскажу, как мы комплексно подошли к проблеме отказоустойчивости Postgreql, какие варианты мы рассматривали и как остановились на Patroni. Доклад содержит этапы тестирования этого решения и примеры, как мы обеспечили быстрое внедрение на production.

PostgreSQL
,
Отказоустойчивость
,
Управление конфигурацией
Программный комитет ещё не принял решения по этому докладу

Стендбай в бою: масштабируем приложение в топ 2 мировом классифайде.

Константин Евтеев

В данном докладе я хочу поделиться опытом Авито, полученным за годы эксплуатации бинарной репликации и стендбаев. Мы многое переосмыслили, разработали свои подходы и техники, планы восстановления после аварий в распределенных системах.
Первая часть о подходе для горизонтального масштабирования с помощью репликации. Это может быть очень эффективно и не требует больших трудозатрат, но есть нюансы и вызовы, требующие решения. Для некоторых приложений возникновение stale reads допустимо и это ок, я же хочу рассказать о паттерне для систем, где stale reads недопустимы, и нашей имплементации.
Вторая часть выступления о подводных камнях, о которых многие даже не подозревает, а другие принимают все риски. Речь пойдет о различных кейсах, которые могут привести к деградации вашего приложения и способах решения, а именно:
- высокий уровень TPS;
- применение DDL;
- отправка большого кол-ва WAL файлов в архив и восстановление из архива
- и др
Расскажу про использование пула стендбаев и переключения запросов между ними. Также о планах восстановления после аварий для приведения в согласованное состояние мастера, стендбаев и архива.

PostgreSQL
,
Tarantool
,
Организация системы кеширования
,
Архитектурные паттерны
,
Отказоустойчивость
,
Оптимизация производительности
,
Распределенные системы
,
Архитектура данных, потоки данных, версионирование
,
Масштабирование с нуля
,
Критерии выбора технологий для проекта
Программный комитет ещё не принял решения по этому докладу

Обзор решений для PostgreSQL High Availability

Алексей Лесовский

Как обстоят дела с High Availability в PostgreSQL в 2019 году.

Очень коротко и быстро посмотрим на решения, которые были созданы в до-облачную эпоху... pgpool, bucardo, postgres-xc/xl. Разберем их недостатки (и преимущества?) и почему эти решения остались за бортом прогресса.

Более подробно остановимся на современных молодых решениях, таких как repmgr, patroni, stolon. Рассмотрим их перспективы, преимущества и недостатки, отличия и ниши для применения.

PostgreSQL
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Администрирование баз данных
Программный комитет ещё не принял решения по этому докладу

Дизайн GraphQL-схем — строим схемы правильно (версия 2)

Павел Черторогов

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

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

Версия 2, доработанная с учетом правок от комьюнити и ревью от GraphQL-гуру Михаила Новикова и Ивана Гончарова.

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

Организация программного кода

Работаем с транзакциями в БД правильно: какие анти-паттерны любят разработчики, и чем это заканчивается для базы и для кода

Сергей Новиков

Работа с транзакциями в базе данных — одна из больных тем при разработке backend-приложения. При кажущейся простоте процесса ("сначала BEGIN, в конце COMMIT") в разных проектах периодически возникают одни и те же ошибки. Причина в одинаковых подходах к работе с транзакциями, которые правильнее назвать анти-паттернами. Я расскажу, как решать основные проблемы:
• Зависание транзакций (с помощью автоматизации операций ROLLBACK).
• Вложенные транзакции (средствами СУБД, и почему это опасно делать на уровне приложения).
• Выбор нужного сервера (мастер или реплика) в зависимости от ситуации.
• И ряд проблем поменьше, но от этого не менее важных.

Все решения я проиллюстрирую живыми примерами (PHP+PostgreSQL), взятыми из практики. Итогом доклада будет общая стратегия организации кода, позволяющая обойти рассмотренные грабли, и связывающая воедино транзакции, подключения к базе данных и обработку ошибок. Доклад будет полезен разработчикам, а также тем DBA, которые всё ещё страдают от выходок разработчиков.

PostgreSQL
,
Организация доступа к базам данных, ORM, собственные драйвера
,
Разработка библиотек, включая open source библиотеки
Программный комитет ещё не принял решения по этому докладу

Комплексное использование анализаторов для повышения качества кода

Юрий Минаев

Нет смысла искать серебряную пулю, которая одновременно найдёт потенциальные уязвимости, проверит оформление кода, предупредит о запахах кода и вообще сделает "хорошо". Есть возможность собрать коллекцию инструментов, которая будет решать те задачи, которые стоят перед разработчиками. Однако, собрать коллекцию мало, нужно ещё иметь возможность единообразно работать со всеми отчётами, предоставляемыми разнородными инструментами, такими как статические анализаторы кода, санитайзеры, компиляторы, инструменты анализа покрытия кода и так далее. Поэтому поговорим о SonarQube, который может стать такой обобщающей платформой и посмотрим на примерах, как осуществляется интеграция различных средств.

Java
,
C/C++
,
Стандарты кодирования
,
Непрерывная интеграция
,
Code Review
Программный комитет ещё не принял решения по этому докладу

Как разрабатывать поддерживаемые приложения: переносимые блоки, контракты взаимодействия, паттерны проектирования и их проблемы

Артем Кудряшов

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

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

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