О чем: frontend, backend, database, DevOps, highload, мобильная разработка, безопасность, управление проектами, тестирование, продакшн, передовая инженерия и машинное обучение.

Для кого: руководители проектов, веб-продюсеры и программисты.


Мой доклад будет состоять из нескольких мини-докладов, в которых я постараюсь рассказать про новую функциональность/улучшение/исправление и добавлю немного бэкграунда для лучшего понимания. Например, в 12 версии ожидаются поддержка KNN для SP-GiST и B-tree, но все ли знают или помнят, что такое SP-GiST и что такое KNN и как им пользоваться ? К моменту конференции будет уже известно наверняка, что попадет в PG 12 и я очень надеюсь, что удастся закомитить долгожданный SQL/JSON (по-крайней мере, мы над этим усиленно работаем), но даже если что-то пойдет не так, я расскажу о проблемах, возникших у нас при реализации стандарта в постгресе.

В докладе я проведу обзор отдельных примеров мало кому известных систем управления базами данных. Некоторые из них устарели, некоторые прекратили своё развитие и заброшены. Мы попробуем найти интересные архитектурные решения в этих примерах и разобраться в их судьбе. Будут даны ответы на вопросы: - почему некоторые open-source продукты перестают развиваться; - что нужно для успешного open-source продукта.

Подробно разберем нехитрый (казалось бы) полусинтетический пример про обработку простенького CSV, и даже на нём традиционно вскроются бездны, а глаза задёргаются от грязных трюков, я гарантирую это. Узнаем, что "лучше", bash, PHP, Python, node.js, Go или С++ (спойлер: необязательно C++). Посмотрим, где работает алгоритмическая оптимизация, а когда уже перестает. Убедимся, что даже в самом простом случае есть несколько вариантов решения, и что вариант "строго по книжке" (даже Кнуту, ага) вовсе необязательно хорош. И, пожалуй, самое интересное: умеренно подробно (по бюджету времени, а то вечно не хватает) разберем на части топовое по скорости решение - и все дающие (или нет) в нём эффект оптимизационные фокусы. Звучит скучно и уныло, так как ты и так все это знаешь и умеешь, поэтому доклад заведомо неинтересен? Это отлично! Побей мой топчик по скорости (спойлер: ты не сможешь) и получи дикую уважуху плюс вкусный жидкий приз. ;)

Aleksandr Serbul
Head of Integration and Implementations Quality Control @ 1C-Bitrix
Moscow

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


Метод Kanban в России постепенно набирает популярность.Но то, как его запускать всё еще остаётся секретом. Есть ли какой-то способ, как запустить Kanban-систему и не попасть впросак? Да, это метод STATIK (System Thinking Approach to Introduce Kanban) - это простой воркшоп из 8 шагов, результатом которого будет понятная и работающая система. Я расскажу из каких шагов он состоит, почему там нет ничего лишнего, как его можно проводить, чего от него ожидать и чему я научился за несколько десятков проведенных воркшопов!


Посмотрим вместе на современный PHP и фреймворки. Разберём что Yii за свою историю сделал хорошо и что плохо. Поговорим о будущем. О версии 3.0.

JIT (Just in Time) компиляция – неотъемлемая часть многих популярных платформ (JavaScript, Java). Задача компиляции в момент выполнения существенно отличается от классической AOT (Ahead of Time) компиляции. Эволюция технологий JIT и AOT компиляции во многом идут параллельными путями. В докладе будет рассказано о новейших достижениях JIT компиляторов для Java и JavaScript платформ, а так же о фундаментальных отличиях JIT и AOT компиляторов.

С ростом скорости мобильного интернета выросла и популярность видеозвонков. Сейчас трудно представить мессенджер или соцсеть без этого сервиса. Сегодня мы поговорим о том, как сделать свой сервис конференц-звонков на 100 участников своими руками. Попутно рассмотрим, как устроены звонки, как их запилить, и как сделать ваши – лучше звонков конкурентов. Нас ждет: - разбор технологий и сравнение конкурентов - внедрим звонки на WEB, iOS, Android - сделаем лучше за счет искусственного интеллекта и доработаем установку p2p соединения - сделаем конференции на 100 участников

The market for games is rapidly expanding, in terms of the number of users, their age, and gender demographics - their are now more adult females playing games than teenage boys. In order to understand these changing demographics we need to look at development of new play testing techniques.


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


Это вторая инкарнация моего доклада о том какие ошибки допускают разработчики при работе с Postrges'ом. Я с моими коллегами из Data Egret являемся Postgres-консалтерами и регулярно наблюдаем как команды разработки осознанно или нет, но допускают ошибки при работе с Postgres'ом. В этом докладе я постараюсь разобрать разные ситуации, которые допускают команды разработки, и даже иногда видят их как решение своих задач, но при этом DBA видят в них источник потенциальных проблем здесь и сейчас либо в обозримом будущем. В докладе я рассмотрю: - проблемы, связанные с планированием, мониторингом и дефолтными конфигурациями, которые встречаются практически везде и всегда; - антипаттерны, связанные с проектированием схем данных; - проблему длинных транзакций, которая часто становится сюрпризом; - еще будет про самописные системы очередей, HTAP workload, "бигдату", docker/kubernetes. По ходу доклада слушатели узнают про некоторые best и worst practices при работе с СУБД и, уже смотря на свои базы, смогут заранее спрогнозировать возникновение неприятных ситуаций и предпринять меры. Доклад будет полезен широкому кругу технических специалистов, вовлеченных в разработку ПО и обслуживание баз данных.

У нас в компании эксплуатируются тысячи микросервисов на .NET. Мы стараемся делать качественные продукты, поэтому особое внимание уделяем телеметрии: логам, метрикам и распределённым трассировкам. Проект Vostok - это инструменты и практики, зарекомендовавшие себя внутри Контура, которые мы делаем частью OpenSource. Сегодня поговорим о той части Востока, которая обеспечивает централизованную обработку телеметрии. Ключевые технологии:
 - Apache Kafka 
- Apache Cassandra 
- Apache ZooKeeper
 - Graphite 
- ELK

Тезисы доклада уточняются


Незаметно для самих себя мы в Ecwid доросли до 100Gb (и 200 миллионов строк) логов каждые сутки. Unix-утилиты, конечно, дают жару, но grep/sed/awk на таких объемах увы, не справляются. Мы запихнули все эти десятки терабайт за несколько месяцев в ClickHouse, написали свой простой язык запросов, подкрутили тут, там и получилась очень простая и быстрая система работы с логами. В докладе я объясню как за пару дней на коленке построить себе такое же счастье.


MariaDB давно переросла своего родителя MySQL за счёт функционала добавляемого в MDB. Одной из фичей стал engine для аналитической нагрузки - Columnstore AKA MariaDB AX, который отлично укладывается в парадигму MariaDB: каждой нагрузке свой движок. В рамках доклада я познакомлю аудиторию со строением и возможностями Columnstore.

На данный момент (февраль 2019) у нас, компании Флант, в production-окружениях Kubernetes функционируют 55 проектов, в состав которых входят более 1000 различных приложений в 70+ кластерах.

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

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

  • Какие метрики нам важны для оценки ресурсов, требуемых приложениям?
  • Как соблюсти требования к SLA и SLO приложения?
  • Как, используя полученные метрики, обеспечить работу сервиса, применив механизмы автомасштабирования Kubernetes?

Ответив на эти вопросы и обеспечив их реализацию в production, мы поделимся практическими рекомендациями, как, используя Kubernetes в качестве фундамента, обеспечить высокую доступность приложений (PDB, QoS, PriorityClass...) и гарантировать их максимальную производительность (VPA, HPA, cluster-autoscaler).

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


Как начать писать игры на WebGL в браузере? Стоит ли вообще начинать? Пишем игры почти не изучая сложных API. Как взять взять Canvas или React и достичь быстрого рендеринга в 2D.

Все знают, что WebGL это очень быстро. Хочется сразу все на него переписать, но технология выглядит так, будто, она прилетела в веб с другой планеты. Стандарту уже почти 9 лет, а специалистов в нем крайне мало.

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

Доклад будет полезен тем, кто знает, что WebGL это быстро, но не знает с какой стороны к нему подойти.


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

Два года назад мы ввели в эксплуатацию новую платформу нашей платежной системы. Компонентно, наша платформа разделена на три больших подсистемы - платежная страница, подсистема связи с банками и МПС (мы ее называем PLUS) и непосредственно ядро платформы. В качестве шины данных для ядра мы используем Apache Kafka, а в качестве сервера очередей для подсистемы PLUS мы хотели использовать Tarantool. Почему мы выбрали эти инструменты, с какими проблемами мы столкнулись в процессе эксплуатации этих систем, как мы их решали, а также про то, что мы в итоге отказались от Tarantool - об этом и поговорим.

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

Расскажу про GAN сети, что они сейчас генерируют картины, которые на аукционах продаются за 400к долларов. И про много других применений.

Расскажу про transfer learning - перенос "знаний" об одной задаче для решения другой.

Расскажу про то, что называется weak supervision - обучение на не качественных данных.

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

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

И уж в самом конце, когда даже задача автоматически формулируется.


В докладе я сравню процессы перехода на Go в двух компаниях с совершенно разными технологическими стеками (PHP и .NET). Я постараюсь сделал доклад сбалансированным и в равной степени осветить техническую и организационную сторону этого вопроса. Чего в этом докладе не будет: рассказа о том какой Go замечательный язык, об этом уже достаточно сказано.

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

Может лучше просто будем код писать?

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

Нет, это не серебряная пуля, просто математика работает всегда. Приходите на доклад – расскажу ;)


Каждый раз, когда я слышу слово DevOps, по спине бегут странные мурашки. С одной сторны - это модно, консультанты с удовольствием расскажут вам как DevOps внедрить, а если на консультантов денег нет, вам поможет пол дюжины книжек. А с другой - каждый вкладывает в это слово своё, периодически прикрывая им дыры в организационной структуре и нежелание системно решать проблемы. Я расскажу об истории эксплуатации нашей информационной системы, взаимодействия "сисдаминов" и "программистов" в Dodo, о том как мы шли от классического отдела эсплутации из пары сисадминов, ходили под флагом DevOps и эволюционировали до Site Reliability Engineering команды, состоящей почти целиком из программистов. Расскажу какой профит и какую боль мы собрали по пути, и какие инженерные решения принимали. Как мы пытаемся сохранить гибкость дерзкого стартапа при росте команды разработки до 250 человек.

iOS-разработчик должен в равной степени владеть двумя языками программирования: проверенным временем Objective-C и активно развивающимся Swift. Языки совместимы и допускают создание проектов, содержащих файлы, написанные на любом из них. Но взаимодействие двух языков, позволяющее легко вносить изменения в проект и поддерживать достаточную гибкость - задача нетривиальная и требующая пристального внимания. В докладе поговорим о создании приложений на разных языках и о принципах их взаимодействия.