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

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

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

В этом году в рамках общих докладов РИТ++ пройдут шесть специальных секций:

  • Микросервисы;
  • Облачные вычисления;
  • ChatBots;
  • Информационная безопасность;
  • Базы данных;
  • Интернет-вещей.

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

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

Профессиональная конференция по применению психологии в управлении и бизнесе Aletheia Business

Разрешение противоречий

Лояльность vs. Вовлеченность или почему проще вовлечь, чем обратить в свою веру

Екатерина Артюшина

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

А что же с невовлеченными работниками? В организации всегда есть определенный процент таких людей. Невовлеченность – это выбор в пользу своего комфорта. Почему специалисты становятся невовлеченными, есть 4 проблемы: хаос в задачах и стандартах, недостаток ресурсов, люди не на своем месте, отсутствие признания успехов. Решить их можно, устранив барьеры: Неизмеримость. Анонимность. Бессмысленность.
Поделюсь секретами вовлечения ключевых сотрудников, неформальных лидеров и агентов влияния в жизнь компании. Приведу примеры того, как мы в своей работе используем знания о Теории поколений: в чем причины борьбы поколений, чем люди X отличаются от людей Y. Как их правильно вовлекать и на что делать ставки.

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

Новая культура организации

Резюме конференции / Четыре вектора ускорения изменений

Александр Зиза
Вирна Штерн

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

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

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

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

Круглый стол, подведение итогов и закрытие конференции.

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

Организации в бирюзовом цвете, или Как придать изменениям смысл, если они пришли сверху…

Мария Груздева

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

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

Представьте, что в понедельник с утра вы приходите на работу, и ваш босс с широкой улыбкой объявляет:
«С сегодняшнего дня мы – бирюза!». Именно с этого момента начинается реальная трансформация, когда все руководители собираются в одной комнате и, что называется, все кладут свои бейджи на стол, только сейчас понимая, что так, как было вчера, ни сегодня, ни завтра уже не будет.

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

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

Вступление в конференцию / Как ускорять изменения в людях, командах и культуре организации?

Вирна Штерн
Александр Зиза

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

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

Мы начнем разговор и попытаемся разобраться в вещах, которые находятся на «кончиках пальцев», о том, как soft-экспертизу перенести в культуру организации. Затронем принципы и правила трансформации, чтобы быстро и без потерь пройти «долину смерти» и получить результат. Постараемся увидеть то, что находится «за» результатами и событиями, то, что определяет скорость изменений.

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

Как построить эффективную систему управления корпоративными знаниями?

Марина Корсакова

1) Создание СУЗ - системы управления знаниями - это рациональная трата времени и денег или... мода? Что отличает по-настоящему эффективную СУЗ от "декоративной"? Каким образом компании становятся успешнее, используя грамотно построенные СУЗ?

2) Кто владеет знаниями? Где хранятся знания? Как они передаются? Как "навести порядок" в уже имеющихся в компании знаниях и привлечь лучшие корпоративные умы к созданию знаний инновационных?

3) Почему не все проекты по внедрению системы управления знаниями оказываются удачными? Как максимально точно спрогнозировать все риски проекта по внедрению СУЗ и избежать их? Примеры удачных проектов: как правильно поставить задачу и эффективно её решить.

4) Почему говорят, что "управление знаниями - это культура"? Какие люди могут работать в "знаниевых" культурах, какими навыками они обладают, что их мотивирует и демотивирует, как меняются в "знаниевой" культуре руководство и лидерство?

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

Why Russians don’t smile

Люк Джонс

Меня зовут Люк Джонс, я живу и работаю в России более 20 лет. Я расскажу вам об опыте, который приобрел в России за это время. Поделюсь секретами, которые по каким-то причинам не вошли в мою книгу «Почему русские не улыбаются», где я рассказываю об особенностях ведения бизнеса в России. Поведаю о разнице в деловом общении, которая отличает работу в России и Силиконовой долине. Расскажу о том, что делать, если кажется, что «пора валить», и есть ли работа на Западе для россиян.

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

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

Эмоциональный интеллект

Как за 10 минут избавиться от стресса в любых условиях

Юлия Петрик

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

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

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

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

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

Свобода в рамках большой цели

Александр Богданов

В AGIMA работает более 100 человек. Очень разные и яркие индивидуальности. Именно они сделали компанию такой, какая она есть, и без остановки продолжают ее развивать. Я расскажу, как мы создали такую слаженную команду. Какими принципами руководствовались.

Основные вопросы, которые я затрону:
- В чем ключевая разница нехватки рук и голов.
- За что работают талантливые.
- Роль лидера в успешной команде: амбиции, пример и др.
- Принципы арбитража в компании или принципы справедливости: кто когда прав и почему, чей вариант лучше, чью сторону должен принять лидер в каких ситуациях.
- Мотивация разная, цель одна. Всеобщее вовлечение в основные KPI компании.
- Раздача власти. Как и сколько ее передать, чтобы делегировать участок, но не потерять контроль.
- Основные ошибки на пути к демократизации, которые могут превратить управление в хаос и дальнейший крах компании.

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

Психологические инструменты

Как мы при помощи IoT измеряли эмоциональное состояние сотрудников крупной организации и какие неожиданные результаты получили

Александр Евдокименко

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

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

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

Взаимодействие с серверной стороной (API)
,
Оптимизация производительности
,
Логирование и мониторинг
,
Корпоративная культура и мотивация
,
Выбор стратегии долгосрочного развития, KPI
,
Бизнес на стыке онлайн и офлайн
,
Теории и техники анализа
,
Аналитика / другое
,
Agile-практики в госкомпаниях, банках, предприятиях
,
Разработка CRM и ERP
,
Internet of Things
,
Нестандартные устройства и периферия
Доклад принят в программу конференции

Раскрытие талантов

Как лучше разбираться в людях

Сергей Котырев

1. Зачем разбираться в людях, особенно если ты менеджер.
2. Обзор популярных и новейших теорий типирования людей.
3. Психософия Афанасьева как мой любимый инструмент.
4. Психопортрет типичного айтишника.
5. Почему Шелдон Купер такой странный? И почему Говард женился на Бернадетт?
6. Практические упражнения :)

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

OKRs: опыт внедрения

Дмитрий Криков

Objectives & Key Results - методика целеполагания, позволяющая сконцентрировать усилия всех подразделений компании на достижении общих целей.

В отличие от жёсткого планирования и KPI, данная методика не предполагает 100%-ного выполнения целей, являющихся заведомо амбициозными и трудновыполнимыми, и не является "performance evaluation weapon". OKRs определяет векторы приложения усилий, позволяет сосредоточить усилия на главном и двигаться в общем направлении, что в совокупности с гибкими методиками управления позволяет повысить эффективность работы команды.

В Россию данная методика пришла не очень давно. Команда NGENIX начала пробовать работать по OKRs около года назад без привлечения внешних специалистов. За это время мы прошли интересный путь, набили некоторое количество шишек и получили команду, сконцентрированную на действительно важных для компании целях и задачах. Хочется поделиться данным опытом, рассказать про важные требования для успеха подобного предприятия, обозначить основные ошибки и сложности. Цель - помочь последователям решиться сделать первый шаг в данном направлении и сделать его уверенно.

Корпоративная культура и мотивация
,
Выбор стратегии долгосрочного развития, KPI
Доклад принят в программу конференции

Из разработчика в тим-лиды. Прокачка в ЦИАН

Максим Мельников

Многие стремительно развивающиеся компании переживают болезни роста. Одна из них – нехватка управленцев. ЦИАН - не исключение. Поговорим о том, как в такой период жизни компании не потерять, а приобрести.

1. Трансформация компании ЦИАН, или изменения – это лучший катализатор для роста людей.
2. Ввысь или вширь? Обсудим горизонтальный и вертикальный рост, или как смешать, но не взбалтывать.
3. Нанимать или обучать? Что выгоднее: нанять тим-лида с рынка или прокачать эксперта внутри?
4. Учить нельзя уволить! Обучение – один из способов борьбы с выгоранием. Расскажем о том, почему иногда спасение утопающего - дело рук не только самого утопающего.
5. Soft skills и Нard skills. Что важнее?
6. Профиль менеджера и оценка управленческих компетенций - блажь или необходимость? Поговорим о том, почему это важно, и как не наломать дров по дороге.

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

Одна история в двух лицах: как HR вовлекает инженеров в рекрутмент

Артем Каличкин
Ольга Давыдова

2010 год: Enterprise из продающей себя ценности превратился в отталкивающий фактор для соискателей, означающий работу с legacy, долгими циклами разработки, ограничениями в использовании новых технологий. Поток пассивных кандидатов иссяк. Для компании, входящей в TOP-5 крупнейших разработчиков ПО в России, с численностью более 2,5 тысяч сотрудников это стало серьезным вызовом. Требовались новые подходы к рекрутингу.

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

Пережив ряд структурных изменений, сгруппировавшись после неудачи, мы начали строить новый HR на новых принципах.
1. Ставка на внешние proffevents.
2. Эксперты Компании - главные амбассадоры HR-бренда: как на внутренних площадках, так и вовне.
3. HR - плохой сервис, но отличные партнеры.

С этой отправной точки запустили 5 proffevents, направленных на формирование Экосистемы перманентного привлечения кандидатов. Произошла внутренняя трансформация восприятия роли инженеров в HR.
Было замечено: трансформация найма значительно помогла в трансформации технологического стека!

Сейчас имеем регулярный качественный рекрутинг в прогнозируемые сроки. Свои планы строим на необходимости постоянного поиска новых решений.

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

Трансформационные изменения

Нейрографика - творческий метод трансформации XXI века

Павел Пискарев

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

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

Мозг – сложнейшая часть организма и доступ к мозгу возможен с помощью рукописи. Рукотворное письмо – каллиграфия – организовывает сознание пишущего точнее и направленнее, чем лента новостей. Что такое рукопись ХХI века? Это Нейрографика! Метод связи с организмом и скрытой частью сознания, метод управления реальностью организовывает влияние на себя так, что окружающая среда становится пластичной и дружелюбной.

Внимание!
Для участия взять с собой 7-8 листов А4, пачку маркеров 0,7-1мм.

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

Развитие осознанности

От осознанности руководителей к организационной осознанности

Екатерина Шаповалова

• «Мы их развиваем, а они уходят» - почему индивидуальное развитие и команд (коучинг, тренинги) часто не дает результата?
• Инвестирует ли себя человек в организацию потому, что он знает, умеет, понимает, или потому, что хочет, или не хочет? Возможно именно внутреннее ощущение «Каково это быть частью этой организации» определяет желание человека вкладывать, вовлекать себя в бизнес-результат
• Организации сами порождают желание либо нежелание людей внутри работать эффективно и на бизнес-результат: как они это делают?
• Смысл есть во всем: и в том, что мы делаем, и в том, что не делаем в организации. Важно понять смысл того, что происходит в организации на самом деле – это первый шаг к изменениям и развитию
• Лидеры и управленческая команда задают настроение и тон всей организации. Зачем руководителям нужна способность исследовать эмоции и смыслы организационной жизни?
• Пример крупной российской компании, проходящей путь осмысления своей системы взаимоотношений с головы до пят: опыт руководителя.
• Выделение в организации времени и места для исследования и осмысления происходящего – не менее важно, чем для со-творчества и инновационных задач
• Что можно взять с собой: посидим-порисуем-порефлексируем.

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

Принцип экономии мыслетоплива или Как сделать больше, а устать меньше

Максим Дорофеев

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

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

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

Конец прокрастинации

Петр Людвиг

Испытываете ли вы проблемы, начиная новые задачи? Откладываете ли вы решение задач, над которыми работаете? Есть ли у вас проблемы с самоконтролем?

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

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

Конференция для разработчиков мобильных приложений Apps Conf

Архитектура

Чистая архитектура. Погружение

Евгений Мацюк
Александр Блинов

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

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

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

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

ApplicationCoordinator для навигации между экранами

Павел Гуров

Навигация между экранами - задача, которая появляется в приложении когда экранов становится больше чем один, то-есть сразу. Стандартные подходы к её решению в iOS (segues, present(_:animated), UINavigationController) обычно используются внутри кода экранов, что приводит к их жесткой привязанности друг к другу и к сценарию, в котором они участвуют.

Доклад о том, как вынести решение этой задачи из Presentation-слоя с использованием паттерна Application Coordinator. Основан на опыте построения навигации между экранами в профессиональных приложениях Avito. Будет интересен тем, кто ищет способ сделать экраны независимыми, переиспользуемыми и легко трестируемыми.

Архитектура платформы iOS
,
Архитектура мобильного приложения
Доклад принят в программу конференции

Современная архитектура Android-приложений - Archetype

Степан Гончаров

Clean architecture в связке с MVP - самый распространенный подход к архитектуре Android-приложений. Но подойдет ли он всем? Скорее всего, нет.

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

Асинхронное программирование, реактивное программирование
,
Архитектурные паттерны
,
Разделение представления и бизнес-логики, шаблонизация
,
Технологии и языки для Android: Java, Kotlin
,
Особенности процессов разработки и тестирования мобильного ПО
,
Архитектура мобильного приложения
Доклад принят в программу конференции

Технологии iOS

Оптимизация размера приложения

Дмитрий Куркин

* Почему размер приложения это важно.
* Как формируется размер приложения в AppStore.
* Оптимизация на уровне файлов внутри IPA-пакета. Структура IPA, степень сжатия файлов внутри пакета.
* Оптимизация на уровне исполняемого файла. Структура исполняемого файла. Объектные файлы и их влияние на размер приложения с учетом разных языков (Swift, Objective-C, C++).

Технологии и языки для iOS: ObjectiveC, Swift
,
Распространение приложений, магазины приложений
Доклад принят в программу конференции

Нужны ли бэкендщики в iOS-разработке, когда есть Swift

Самвел Меджлумян

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

Изучим имеющиеся фреймворки и сравним лучший из них с серверными компилируемыми языками. Также будут затронуты вопросы микросервисной архитектуры, проблемы и best practices в серверной разработке.

Технологии и языки для iOS: ObjectiveC, Swift
Доклад принят в программу конференции

Масштабируемый VIP архитектурный дизайн на React Native

Дмитрий Евстратов

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

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

Что вас ждёт:
* Дискуссия: гибридные технологии — хорошо это или плохо?
* Опыт: создаём мобильную платформу. Быстро. Качественно. Недорого.
* Архитектура: VIP + React Native + Sberbank = <3
* Live coding: быстрая разработка с платформой — легко!
* Best practices: советы бывалых разработчиков. По колено в React Native.
* Вперёд в будущее: куда дальше двигается платформа?

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

Как релизить концепты каждую неделю и не сломать проект

Владислав Дугнист

Доклад сделан с большим упором на особенности Objective-C.

Мы поговорим про:
* анализ ошибок средствами llvm;
* статический анализ кода;
* макросы, которые повышают устойчивость вашего кода к рефакторингу;
* Runtime и Unit-тесты;
* проверочные скрипты на этапе сборки.

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

Дополненная реальность в Swift (Augmented Reality in Swift)

Вадим Дробинин

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

Доклад будет разбит на три части: в первой посмотрим на историю развития AR и сравним дополненную реальность с виртуальной, во второй разберем различные способы взаимодействия, покопаемся в SDK и немного коснемся iBeacon'ов, а в последней подведем итоги и обговорим наиболее интересные способы использования, а также их плюсы и минусы.

Фронтенд / другое
,
Internet of Things
,
Технологии и языки для iOS: ObjectiveC, Swift
,
Работа с графикой, 3D Моделирование
,
Мобильные приложения / другое
Доклад принят в программу конференции

Backend на Swift. Существует и работает! Взгляд со стороны iOS-разработчика

Роман Мочалов

- Рассмотрим случаи, когда нам было бы полезно самим писать backend...на Swift'e, конечно же!
- Разбор open-source библиотек, позволяющих вам писать только Swift-код для работы с реквестами. Остальную REST, OAuth, HTTP-магию они делают сами.
- Напишем с вами API для работы с "юзерами", будем записывать данные в базу, делать Basic-авторизацию. В общем, демо будет максимально приближено к "боевым проектам" )
- Выльем наш бэкенд на Heroku и Digital Ocean (что это за звери, я тоже расскажу).
- Ну и, конечно же, в конце похоливарим на тему: "Зачем вам, как Swift-разработчикам под iOS, писать еще и backend". Дискуссия обещает быть жаркой!

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

UI-тесты в iOS-проекте. Есть ли профит, и для чего их, вообще, внедряют?

Михаил Домрачев

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

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

Оптимизация времени запуска iOS-приложений

Николай Лихогруд

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

Рассказ основан на личном опыте оптимизации запуска Яндекс.Карт, описывает весь процесс от осознания проблемы до получения результата, подкреплен множеством технических подробностей и реальных примеров. Доклад является концептуальным, содержит конкретные предложения по разработке мобильных приложений с быстрым запуском и будет полезен iOS-разработчикам любого уровня.

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

Переход с Objective-C на Swift — все ли так просто?

Олег Алексеенко

Ни для кого не секрет, что Swift — это mainstream: его активно продвигает Apple, на нем пишутся все новые фреймворки, многие разработчики начинают именно с него. Но так ли просто мигрировать c Objective-С, если твоему приложению 5 лет и оно имеет большую аудиторию? В докладе мы расскажем о том, как сделать это без ущерба для бизнеса.

Вы узнаете об этапах такого перехода:
1. Какую бизнес-проблему решали? - Ускоряем разработку, уменьшаем количество багов, проще и быстрее находим новых сотрудников, ограждаем от будущих рисков (старых не поддерживаемых фреймворков, устаревших АПИ).

2. Подготовка текущего Objective-С кода в Swift:
а) Поддержка в Objective-С nullabity для всех интерфейсов.
б) Замена старых Objective-С библиотек без поддержки Swift или поиск замены для них.
в) Описание код стайл для Swift внутри команды.
г) Настройка работы storyboard, assets через swiftgen.

3. Улучшение архитектуры приложения для Swift:
а) Не было слоя routing как такового, для Swift добавили его.
б) Перестройка под protocol oriented programming.

4. Подводные камни и интересные моменты, которые вскрылись по пути:
а) Старый код для работы с АПИ очень сложно переписать - нашли решение, как через extension постепенно переписывать.
б) Увеличилось время загрузки приложения.
в) Настройка swiftgen.
г) У ReactiveCocoa нет типизации у сигналов, и без этого работать в ними в Swift не удобно. - разработали решение, как получать типизированые значения.
д) При сериализации ответа от сервера нет уверенности, что поле существует, хоть оно и помечено как nonnull.
е) Генерация из struct классовых proxy-объектов для работы со struct в Objective-С с помощью Sourcery.

iOS-приложения Superjob это:
• 3 приложения в AppStore для B2C и B2B-аудиторий;
• более 1 млн. пользователей;
• стабильные позиции в ТОП-3 приложений в категории «Бизнес»;
• ~60% кода проекта переведено на Swift.

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

Технологии Android

Kotlin Perfomance on Android

Александр Смирнов

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

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

Технологии и языки для Android: Java, Kotlin
Доклад принят в программу конференции

Lint в помощь

Григорий Джанелидзе

Кодревью – как много в этом слове! Согласитесь, было бы здорово, если бы кодревью было сосредоточено чисто на архитектурных проблемах и потенциальных багах в логике, забыв про всякие небольшие нюансы в духе контрактов определенных классов. И как было бы здорово, если бы про эти нюансы можно было бы намекнуть разработчику ещё в процессе разработки, при этом не стоя у него за плечом и не заглядывая в его монитор.

Уверен, что почти все используют при разработке Lint. Это прекрасный инструмент, который довольно легко расширяется абсолютно любыми проверками. Есть только одно "но" – у Lint очень плохо с документацией и, чтобы разобраться с его расширяемостью, придется довольно много времени потратить за поиском хоть какой-то документации.

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

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

Android как основа для реализации мобильного паспорта

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

Операционная система Android на устройствах, поддерживающих технологию NFC, теперь может рассматриваться в качестве основы для реализации электронных, машино-считываемых персональных идентификационных документов, наподобие заграничного биометрического паспорта гражданина РФ. Благодаря использованию технологии Host-based Card Emulation (HCE), регулирующейся организацией NFC Forum, мобильный телефон теперь может заменить любое приложение, выполняющееся на интеллектуальной карте (смарт-карте) стандарта ISO7816, сохраняя при этом всю инфраструктуру инспекционного контроля неизменной.

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

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

Защита информации
,
Безопасность в мобильных приложениях
Доклад принят в программу конференции

Flutter vs React: взгляд нативщика

Александр Смирнов

Не так давно Google представил собственное решение для кроссплатформенной разработки, которое выглядит очень интересно. Но стоит ли на него обратить внимание и пробовать использовать? Особенно когда уже есть есть React от Facebook? Как будет работать необходимое вам решение на одной из платформ?

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

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

Moxy. Как правильно пользоваться?

Юрий Шмаков

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

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

Мобильный Virtual Reality - что это такое и как работает

Алексей Рыбаков

Поговорим о Virtual/Augment/Mixed/Merged Reality - что это такое и как работает.

Более подробно рассмотрим Mobile VR:
- Samsung Gear VR Powered by Oculus Rift;
- Google DayDream и Cardboard;
и обсудим, как и с помощью какого инструментария можно разрабатывать приложения.

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

Процессы разработки

Как выйти с проектом на рынок райдшеринга и выжить?!

Марсель Муртазин

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

Очень часто эти проекты становятся серьезными конкурентами или просто умирают, так и не выйдя на рынок.

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

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

Автоматизация тестирования в iOS-проекте на примере ICQ

Дмитрий Куркин
Максим Манаев

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

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

Ловля сетями. Инструменты отладки сетевых запросов приложений

Дмитрий Рыбаков

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

Я расскажу и покажу весь диапазон современных средств для мониторинга и отладки сетевых запросов: от самых простых до узкоспециальных - с плюсами/минусами каждого из инструментов и областями их применения.

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

Toggle your app

Евгений Кривобоков

С быстрым ростом команды и приложений мы столкнулись с новыми для нас вызовами. Стало труднее экспериментировать, code review не решал своих задач, а стабилизация релиза занимала непредсказуемое время. Поскольку мы хотим чаще выпускать новые версии приложений и спать при этом спокойно, то, как инженеры, начали решать эти проблемы с технической стороны, активно используя feature toggles.

Расскажу, когда уместен этот подход, как применяем для стабилизации продукта и приближения к сontinuous delivery. Обсудим приемы борьбы с тех. долгом без ущерба корректности работы.

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

Просыпаешься, а твоё приложение на главной в App Store: как правильно готовить pet-project'ы

Вадим Смирнов

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

Зачастую эти идеи так и пылятся в головах людей по самым различным причинам.

В этом докладе поделюсь историями из жизни:
– Как, потратив несколько выходных за год, удалось сделать пять разных проектов (парочка из которых пропиарилась на тематических ресурсах рунета и даже удостоилась внимания Apple, став Featured в App Store).
– Сколько миллионов заработали (нисколько).
– Почему не разочаровались и не прекращаем работать над pet-project'ами.

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

Кросс-платформенная разработка

Ужасы мобильной графики

Филипп Кекс

Современные мобильные устройства по уровню "железа" достигли игровых консолей. Почему же уровень real-time графики мобильных игр заметно отстаёт от консолей и ПК?

Из доклада вы узнаете о неожиданных особенностях разработки мобильной графики с такими современными API, как OpenGL ES и DirectX, о типичных проблемах и способах их решений. Также о том, как разработчики ведут кровавую войну за каждую миллисекунду и о надежде на светлое будущее в роли графических программных интерфейсов нового поколения Vulkan и Metal.

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

По заветам Франкенштейна. Продолжаем автоматизацию тестирования SDK AppMetrica

Алексей Витенко

Мы продолжаем свой рассказ о тестировании мобильного продукта, у которого нет UI.

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

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

Профессиональная конференция для серверных веб-разработчиков Backend Conf

Базы данных

Брокер сообщений 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 тысяч метрик в секунду.

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

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

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

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

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

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

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

Консервативный 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.

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

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

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

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

Конференция фронтенд-разработчиков FrontendConf

Адаптация

Адаптивная верстка 5 лет спустя

Сергей Кузнецов

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

Тезисы:
* Ограничения и трудности - трансформация десктопа в мобайл (таблицы, картинки, видео и изображения).
* Оптимальное количество брейкпоинтов - какие значения самые важные и что делать с промежуточными?
* Удобные единицы измерения - вычисляемые значения в CSS3 (calc, vh, vw и прочие).
* Расположение навигации на экране - про пальцы.
* Best practice: простые способы снижения нагрузки.
* Worst practice - как делать не надо.
* Мультитач, тапы и свайпы - чтобы работало.
* Детали настройки - вендорные префиксы и прочие системные директивы.

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

Адаптивный сайт. Как грамотно сделать муху из слона и слона из мухи

Дмитрий Шагаров

- Статистические данные на основе сайта tutmee.ru.
- Подтверждение важности и актуальности качественной адаптивной верстки (на основе статистики).
- Подходы при разработке иностранных и отечественных проектов. Преимущества и недостатки.

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

Адаптивные дизайн и вёрстка
,
Совместная работа дизайнеров и верстальщиков
Доклад принят в программу конференции

Как технология AMP HTML ускоряет сайты и повышает бизнес-метрики

Артём Цымпов

* История проекта Accelerated Mobile Pages.
* Как это работает.
* Западные кейсы и результаты.
* Отечественные кейсы и результаты.
* Как правильно внедрить AMP.
* Будущее технологии.

Адаптивные дизайн и вёрстка
,
Мобильные сайты и приложения на веб-технологиях
,
Оффлайн и кэширование в локальных хранилищах
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
Браузеры
,
CSS модули и веб компоненты
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

Приложения

Клиенту и серверу нужно поговорить

Никита Прокопов

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

Более современная версия — server push, SSE, веб-сокеты — лучше, но всё еще на очень низком уровне абстракции. Это биты и байты, ассемблер распределенных систем. Однако давно хочется делать это и проще, и надежнее, и качественно лучше.

В этом докладе мы поднимемся на следующий уровень абстракции и посмотрим, как можно делать клиент-серверную коммуникацию нового поколения: расширенные модели данных, высокоуровневые API, логи событий и т.д. Мы рассмотрим сложные сценарии, проблемы, как их можно решать и какие для этого есть инструменты. Ключевые слова: event sourcing, операционные трансформации, CRDT, Meteor, Apollo, PouchDB, Firebase, Relay, Swarm.js, Logux.

Single page application, толстый клиент
,
Взаимодействие с серверной стороной (API)
,
Оффлайн и кэширование в локальных хранилищах
,
Интерактивные приложения
,
Архитектура данных, потоки данных, версионирование
,
Синхронизация данных, параллельная обработка, CDN
Доклад принят в программу конференции

Как масштабировать сложный Single Page Application

Алексей Катаев

В своем докладе я расскажу, как мы преодолели рубеж в 100 тысяч строк в нашей платформе Vimbox (SPA для интерактивного взаимодействия учитель/ученик) без потери качества. Сейчас нам удается работать командой из 10 человек над одним приложением, улучшая код и проводя рефакторинг с небольшими накладными расходами на конфликты, коммуникацию и подключение новых разработчиков к проекту. Я расскажу, с какими проблемами мы столкнулись при увеличении сложности / размера нашего приложения и при увеличении команды.

Основная проблема, которая перед нами стояла, — это сложная система организации зависимостей и состояний в приложении, которая только ухудшалась / усложнялась со времени. Ее мы решили новым подходом — глубокой иерархией состояний вместо pubsub.

Также я отвечу на вопросы: как мы подключаем разработчика в команду за 1 день, расскажу о нашей инфраструктуре (в том числе о тестировании и CI) и о том, как мы за 10 дней сделали платформу для проведения олимпиады Skyeng Super Cup на 100.000 учеников.

Single page application, толстый клиент
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
JavaScript
,
Фронтенд / другое
,
Code Review
,
Большие проекты/команды
Доклад принят в программу конференции

Разработка Rich Text Editor: проблемы и решения

Егор Яковишен

Краткая история редактирования текста в браузерах. Родовые проблемы WYSIWYG-редакторов. Типы и функции современных веб-редакторов.

Обработка различных способов ввода (клавиатура, голос, copy&paste, autocomplete/autocorrect, gesture input). Проблемы с использованием contenteditable и execCommand. Браузерные API: Selection, Input Method Editor, Clipboard, MutationObserver, CompositionEvents. Спецификация W3C Input Events.

Хранение состояния документа (document state): модель данных, виды сущностей, рендеринг в разных форматах, семантика HTML-кода. Способы изоляции CSS в редакторе (iframe, БЭМ-нотация, CSS reset, Shadow DOM). Привычный UX: выделение текста, copy&paste, горячие клавиши, undo/redo. Адаптация контента под разные устройства и экраны. Многопользовательское редактирование и синхронизация изменений. Работа в оффлайн-режиме.

Public API редактора и подключение плагинов. Примеры современных редакторов: Quill от Salesforce, Trix от Basecamp, Draft.js от Facebook. Обзор крупных проектов: Google Docs, iCloud Pages, Office 365.

Будущее rich text editing.

JavaScript
,
Интерактивные приложения
,
Дизайн и работа с изображениями
,
Браузеры
,
Совместная работа дизайнеров и верстальщиков
,
Фронтенд / другое
Доклад принят в программу конференции

Как мы запустили offline-версию сайта RG.RU

Алексей Чернышев
Максим Чагин

Мы расскажем о построении работы действующей offline версии сайта на примере СМИ с миллионной аудиторией. О выборе стека технологий для решении поставленной задачи. О результатах эксплуатации с момента запуска.
В том числе: * Стратегия обновления данных в Service Worker * Проблемы и их решение при работе с оффлайн-средой * Сбор аналитики при отсутствии интернета

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

Объектное Реактивное Программирование

Дмитрий Карловский

- Как современные библиотеки (KnockOut, CellX, MobX, $mol_atom) и фреймворки (MeteorJS, VueJS) обеспечивают эффективное оркестрирование вычислений и берут на себя львиную долю рутины;
- какие проблемы есть у популярных паттернов коммуникации компонентов (Angular, FLUX), и как выглядят правильные двусторонние реактивные связи между компонентами;
- как и почему ОРП позволяет писать короткий, понятный, а следовательно и менее багоёмкий код по сравнению с ФРП и, уж тем более, с ручной актуализацией состояний приложения;
- как принцип тотальной ленивости в применении к загрузке, вычислениям и рендерингу позволяет создавать по-настоящему шустрые приложения, не жрущие батарейку и трафик;
- как писать неблокирующий автоматически распараллеливаемый код в синхронном стиле благодаря ОРП.

Single page application, толстый клиент
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
JavaScript
,
Интерактивные приложения
,
Асинхронное программирование, реактивное программирование
,
Архитектурные паттерны
,
Разделение представления и бизнес-логики, шаблонизация
Доклад принят в программу конференции

Разработка React-компонентов

Павел Силин

1) Использование принципов SOLID для react-компонентов.
2) Использование stroybook для разработки react-компонентов.
3) Как мы бьем приложение на react-компоненты.
4) Тупые и умные react-компоненты.
5) React-компоненты и стили/

Шаблонизаторы и препроцессоры
,
Single page application, толстый клиент
,
Пакетные менеджеры и организация модульности
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
JavaScript
,
CSS модули и веб компоненты
,
Фронтенд / другое
Доклад принят в программу конференции

Интерактивные 3D-карты своими руками

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

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

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

JavaScript
,
WebRTC, WebGL и веб-медиа в целом
,
Интерактивные приложения
Доклад принят в программу конференции

Портируем существующее Web-приложение в виртуальную реальность

Денис Радин

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

Должны ли мы использовать CSS или WebGL для проброса приложения в VR?
Какие решения доступны на текущий момент, и каких ошибок стоит остерегаться?
Почему HTML так же хорош для разработки VR-интерфейсов, как и для обычного, плоского Web?
Как веб-разработчик может быть частью VR-революции?

Single page application, толстый клиент
,
Веб-графика, оптимизация изображений
,
WebRTC, WebGL и веб-медиа в целом
Доклад принят в программу конференции

Оптимизация производительности фронтенда

Игорь Алексеенко

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

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

Новинки

Make form validation fun again

Павел Ловцевич

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

Современные браузеры предоставляют разработчику широкий набор встроенных методов для работы с данными пользователя. Разработка собственных велосипедов и использование тяжелых библиотек со множеством зависимостей остались в прошлом. В отдельных случаях можно даже обойтись без написания Javascript-кода!

В рамках доклада будут рассмотрены основные аспекты работы с HTML5 Constraint Validation API:
- семантика полей форм;
- доступные методы API;
- прогрессивное улучшение валидации (CSS → JS);
- глубина и особенности реализации API в браузерах.

Адаптивные дизайн и вёрстка
,
JavaScript
,
Браузеры
,
Фронтенд / другое
Доклад принят в программу конференции

Сага о yield. Скрытые возможности

Евгений Евсеев

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

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

Мобильные сайты и приложения на веб-технологиях
,
Single page application, толстый клиент
,
JavaScript
,
Интерактивные приложения
,
Фронтенд / другое
Доклад принят в программу конференции

Пора начинать фыркать – Grid Layout уже здесь

Сергей Попов

Про Grid Layout сказано уже много. Большое количество статей, примеров, инструментов. Однако только сейчас мы можем начинать свободно пользоваться этой спецификацией. Пора заканчивать читать справочники и начинать использовать Гриды в реальном мире.

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

Адаптивные дизайн и вёрстка
,
Фронтенд / другое
Доклад принят в программу конференции

Прогрессивный рендеринг и Catberry.js

Михаил Реенко

Знаете ли вы, что такое прогрессивный рендеринг?
Почему вам стоит его использовать?
Какие есть варианты сегодня?

Single page application, толстый клиент
,
Node.js и io.js
,
JavaScript
Доклад принят в программу конференции

Качество

Что делать, когда у вас 100 партнеров? Как в Lamoda устроен фронтенд системы аналитики

Иван Потапов

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

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

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

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

Оценка фронтенда: моя история о том, как сдавать задачи вовремя

Александра Шинкевич

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

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

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

Вам нужен крутой разработчик. Нам тоже

Владимир Гриненко

Работая в одной из крупнейших IT-компаний в Европе, мы все время нуждаемся в крутых разработчиках.

В докладе я расскажу, как мы их ищем (и не находим), «выращиваем» вне компании, нанимаем, а затем продолжаем растить уже внутри.

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

Экосистема или зоопарк? Как работать с дизайном и frontend десятков связанных систем

Федор Щудло

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

Как от “стихийной” разработки и уймы повторяющегося кода перейти к написанию библиотек для самих себя, сделать своими пользователями своих же разработчиков, а что-то даже выложить в open source. И почему выкладывать в open source важно, и вам тоже следует это делать.

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

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

Адаптивные дизайн и вёрстка
,
Single page application, толстый клиент
,
Пакетные менеджеры и организация модульности
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
Совместная работа дизайнеров и верстальщиков
,
Фронтенд / другое
Доклад принят в программу конференции

Тестируй это

Виктор Русакович

Как писать тесты?
Как запускать тесты?
Кто все сломал?

Все три вопроса рассмотрены в докладе. Также будет демо интеграции проекта, покрытого тестами, и cloud-based-сервиса по запуску этих тестов (github+travis).

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

JavaScript
,
Фронтенд / другое
,
Автоматизация тестирования
,
Интеграционное тестирование
,
Юнит-тестирование
,
Приёмочные и функциональные тесты
,
Тестирование фронтенда
Доклад принят в программу конференции

Дизайн-система. Идеальный компонент

Роман Ганин

— Почему типографика — это важно;
— принципы построения интерфейса и дизайн-систем, основанные на шрифте;
— дизайн, построенный на базовом размере шрифта, «из коробки» pixel perfect;
— модульная шкала для управления размерами;
— зачем нужны макетные сетки и вертикальный ритм;
— сколько компонентов нужно для «счастливой жизни».

Адаптивные дизайн и вёрстка
,
Accessibility
,
Совместная работа дизайнеров и верстальщиков
Доклад принят в программу конференции

Как жить на острие технологий в продакшне и не сойти с ума

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

Сегодня популярно осуждать гонку за технологиями, много говорится о том, как плохо это может закончиться, и почему стоит об этом забыть. Я же хочу рассказать, как можно жить на bleeding edge в продакшне, как я сам это сделал в Uploadcare, и почему не стоит бояться такого подхода.

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

Особенности разработки API

Всеволод Шмыров

Разработка API/Framework/встраиваемого контента сильно отличается от разработки обычного frontend-приложения. На примере нашего API Яндекс.Карт я расскажу, чем именно.

+ Какие задачи обычно решают разработчики API?
+ С каким проблемами сталкиваются?
+ Какие есть ограничения в разработке?
+ Чем еще должен заниматься разработчик API, кроме непосредственно разработки?

Взаимодействие с серверной стороной (API)
,
JavaScript
,
Браузеры
,
CSS модули и веб компоненты
,
Фронтенд / другое
Доклад принят в программу конференции

Инструменты

Компонент-платформа

Александр Лобашев

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

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

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

Паразитируем на React-экосистеме (Angular 4+)

Алексей Охрименко

Паразитизм — форма взаимоотношений между организмами различных видов, из которых один (паразит — aka Angular 4+) использует другого (хозяина — aka React) в качестве среды обитания и источника питания, нанося ему вред, но при этом не убивая.

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

Мы рассмотрим оба подхода — о том, как выживать в суровом мире Angular 4+ с помощью React-экосистемы (оставляя ее в живых), и о том, как в конечном счете "убить" своего "хозяина".

Из этого доклада вы узнаете, как работать с Redux, Mobx, GraphQL и рядом других основополагающих кирпичиков React-экосистемы.

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

Рефакторинг клиентского кода или как отрефакторить миллион строк кода и не сойти с ума

Алексей Золотых

+ Реафакторинг - понятие.
+ Когда нужен, когда не нужен.
+ Как правильно ставить цели для рефакторинга.
+ Средства для рефакторинга в IDE и простейшие средства.
+ Рефакторинг из консоли.
+ Применяем JavaScript для того, что рефакторить JavaScript.
+ Подводные камни.

Очень много примеров.

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

Бешеные псы: Angular 2 vs React

Евгений Гусев
Илья Таратухин

Angular 2 отрелижен, React и подавно. Копья поломаны, мечи перекованы на орала, страсти уже поутихли и, вроде как, статус кво восстановлен. Кто-то использует один инструмент, кто-то другой, разве что, иногда раздаются возгласы: "А у них...!"

Однако не всё так просто. В конце концов, мы не только пишем код, но и решаем однотипные проблемы:
* Как сделать наше приложение быстрым?
* Как писать понятнее и проще?
* Как писать быстрее?

Кто-то может сказать: "Эту тему уже миллион раз обсасывали, зачем опять?". Но, все же, если вы стартуете новый проект или решили переписать старый, перед вами всё равно встанет проблема выбора. И даже если вы считаете, что всё очевидно — это далеко не так.

Вот уже год как Wrike использует Angular 2 в бою. И вроде всё хорошо, но иногда закрадываются сомнения: “А вдруг мы свернули не туда?”

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

Мистер Красный (Евгений Гусев) и мистер Синий (Илья Таратухин) спорят, доказывают, демонстрируют примеры, пытаясь понять, что же лучше.

Будет боль, будет спор, будет вывод.

AngularJS, Backbone.js и другие JavaScript-фреймворки
Доклад принят в программу конференции

Ваш CSS нас не устраивает, мы придумаем свой

Роман Прудников

Нам постоянно нужно от CSS больше того, что в нём (или браузерах) есть прямо сейчас.

История, рассказывающая о том, какими способами мы решали(ем) проблемы недостающих нам возможностей (css frameworks, css polyfills, preproccessors, “post”-proccessors) и о Houdini, который должен положить конец этой ерунде, позволив описывать разработчикам с помощью JavaScript не просто полифилы, а полноценные реализации, не мешающие производительности.

Расскажу о том, что мы можем контролировать в CSS сейчас, что сможем с Houdini, и что в нем есть на текущий момент с примерами демок.

Адаптивные дизайн и вёрстка
,
JavaScript
,
Фронтенд / другое
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

Где кончается react native?

Павел Кондратенко

Познакомлю вас с тем, как библиотека бумажных книг в нашей компании переехала в онлайн, причем тут react native, что из него можно выжать, и как он работает с "железом" мобильных устройств: считывание qr-кодов через камеру, хранение данных и так далее. Я сконцентрируюсь на том, чтобы донести до вас самые соки из моего опыта работы с этой технологией.

p.s. Задавайте свои вопросы по теме на iam@kondratenko.me, я постараюсь вписать ответы на них в свой доклад!

Мобильные сайты и приложения на веб-технологиях
Доклад принят в программу конференции

Обучающая конференция разработчиков высоконагруженных систем HighLoad++ Junior

Оптимизация баз данных

MySQL: чек-лист для новичка в highload

Анастасия Распопина
Света Смирнова

В рамках данного доклада в диалоговом формате будут рассмотрены наиболее распространённые вопросы по MySQL - от краткого обзора возможностей основных вариантов этой СУБД (актуальное состояние Oracle MySQL, Percona Server и MariaDB) до выбора наиболее оптимальных значений для конкретных параметров, чтобы справиться с ростом вашего проекта.

Подтемы доклада:
- обзор форков MySQL (для каких специфических задач подойдут форки вместо оригинального MySQL);
- что такое highload в современном мире (где ещё не highload, а где уже highload);
- что храним в памяти, что на диске;
- кэширование;
- кластеризация;
- репликация/шардинг базы данных;
- умеет ли СУБД кросс-датацентр репликацию;
- MySQL-индексы;
- настройка MySQL под нагрузку;
- лог медленных запросов в MySQL + анализ запросов;
- как понять, что "тупит" не MySQL.

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

Профилирование

Погружение в виртуальную память и большие страницы

Константин Новаковский

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

* Как ядро работает с этими страницами?
* Как аппаратная часть помогает ядру ОС работать с виртуальной памятью?
* Какова цена виртуальной памяти?
* Для чего нужны большие страницы и почему их "прозрачное" использование может сделать хуже?
* Сколько памяти на самом деле потребляет приложение?

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

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

Балансировка нагрузки

Балансировка HTTP-трафика

Антон Резников

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

Мы рассмотрим три самые распространённые задачи: распределения запросов
динамического контента (HTML, API), раздачу статического контента и загрузку
данных от пользователя. На примере этих задач мы будем добиваться масштабируемости,
высокой доступности, затронем проблемы эксплуатации и гео-балансировку.

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

Выбор технологий

Как сделать сложное простым. История создания Проект1917

Сергей Спорышев

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

Каждый web-программист мечтает написать свой фреймворк, CMS или соцсеть, и современный стек технологий дает настолько широкий выбор инструментов, что очень легко построить переусложненное архитектурное решение.

В докладе я расскажу, как не распыляться на новые технологии. Как, пользуясь проверенной временем связкой Nginx+MySQL+Laravel+AngularJS, в кратчайшие сроки построить сложный проект, рассчитанный на большую нагрузку и при всем этом имеющий простую, легко поддерживаемую и расширяемую архитектуру.

В программе:
- Организация фронта, архитектурные решения, чтобы все работало очень быстро, и стоимость изменений была минимальна.
- Организация пользовательской части "социальной сети" минимальными средствами: организация фидов/ленты, организация системы комментариев, организация системы лайков.
- Сложная, функциональная админка с постоянно работающими 100 редакторами.
- Разработка системы пуш-уведомлений в ночь перед запуском.
- Точно в срок без канбан и прочих методологий.

Single page application, толстый клиент
,
Генераторы статики
,
Взаимодействие с серверной стороной (API)
,
AngularJS, Backbone.js и другие JavaScript-фреймворки
,
Фреймворки
,
PHP
,
Организация системы кеширования
,
Оптимизация производительности
,
Критерии выбора технологий для проекта
Доклад принят в программу конференции

Принципы масштабирования

BigMemory - работа с сотнями миллионов бизнес-объектов в управляемых средах

Дмитрий Хмаладзе

Наш доклад описывает способ использования больших объемов памяти, которые стали доступны в последние годы. К сожалению, эта память обычно остается незадействованной в управляемых средах исполнения в связи с принудительной сборкой мусора. Разработчики прибегают к внешним хранилищам данных ( i.e Memcached), что несет дополнительные расходы.

Описываемый нами способ BigMemory Pile обкатан и применим для большинства современных приложений, связанных с социальными графами, обработкой потоков, IoT, stateful-алгоритмов/анализ, системами кэширования и отслеживания причинно-следственных связей.

BigMemory Pile основан на прозрачной сериализации нативных объектов среды исполнения с сохранением данных в пред-аллокированных массивах большого размера, тем самым достигается "невидимость" объектов предметной области для сборщика мусора.

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

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

Антипаттерны, ошибки проектирования

ТОП ошибок в инфраструктуре, мешающих высоким нагрузкам

Андрей Половов
Андрей Колаштов

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

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

Доклад затронет следующие области:
* базы данных,
* код,
* архитектура,
* деплой,
* и самое неизбежное — человеческий фактор.

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

Ошибки проектирования высоконагруженных проектов

Максим Ехлаков

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

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

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

Фреймворки
,
PHP
,
Прочие языки
,
MongoDB
,
Микросервисы, SOA
,
Оптимизация производительности
,
Профилирование
,
Синхронизация данных, параллельная обработка, CDN
,
Проектирование информационных систем
Доклад принят в программу конференции

Database First! О распространённых ошибках использования РСУБД

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

Любой Full Stack Developer сегодня обязан иметь в своём арсенале опыт и умение работы хотя бы с одной популярной РСУБД. Но без понимания основ — того, какие задачи решают СУБД, как происходит работа с данными, какие есть базовые возможности для этой работы, — такие умения превращаются в воздушный замок, быстро разрушающийся при росте проекта.



Этот доклад — попытка разбудить интерес слушателей к тщательному изучению основ теории и практики реляционных баз данных и к применению всей мощи РСУБД по прямому назначению.

Мы обсудим несколько фундаментальных ситуаций использования РСУБД (каждая из которых неоднократно встречалась автору), попутно разбирая возможные ошибки:
- элементарная модификация данных;
- работа с датой, временем и временными зонами;

- проверка ограничений целостности;
- очередь заданий;
- пакетная работа с данными (например, удаление пачки записей в таблице);
- полнотекстовый поиск;
- относительно новые задачи (создание API, machine learning).

Для каждого кейса мы сравним плюсы и минусы реализаций «на стороне СУБД» и «снаружи / на стороне приложения», прежде всего с точки зрения производительности. Постараемся понять, почему современные разработчики часто боятся использовать мощь РСУБД. Откуда пошёл миф «хранимки — зло».

Ну и, наконец, представим чеклист знаний (с перечнем полезных ссылок!), которые, по мнению автора, необходимо иметь, чтобы чувствовать себя увереннее при работе с РСУБД.

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

Прочие темы

Приключения проекта от компьютера разработчика до серьезных нагрузок

Андрей Минкин

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

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

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

Как заранее соломки подстелить или путь к 99,99% uptime проекта

Игорь Мызгин

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

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

В своем докладе я буду говорить о том, о чем надо не забывать пока маленьким проектам, чтобы смочь вырасти большими и при этом не потратить все ресурсы на создание инфраструктуры проекта. Я детально проговорю то, о чем 99% клиентов хостинга задумываются по факту:
- о разграничении ответственности между клиентом и хостером,
- о том, что написано в SLA и как этот / эти документы читать,
- что должен сделать проект сам, и почему за проект это не будет делать хостер,
- как спланировать свой рост и не стать заложником изначальной инфраструктуры при активном росте,
- о чем надо спросить "на берегу" провайдера/провайдеров.

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

Отказоустойчивость
,
Распределенные системы
,
Разделение представления и бизнес-логики, шаблонизация
,
Архитектуры / другое
,
Управление конфигурацией
,
Технологии отказоустойчивости и катастрофоустойчивости, бэкапы
,
Менеджмент в эксплуатации
,
Большие проекты/команды
,
Работа со внешним заказчиком/исполнителем
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
Доклад принят в программу конференции

SOA: послать запрос на сервер? Что может быть проще?!

Иван Круглов

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

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

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

Проксирование HTTP-запросов web-акселератором

Александр Крижановский

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

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

- Как работает HTTP-проксирование без кэша;
- Что такое персистентные соединения и чем они отличаются от HTTP keep alive;
- Как, когда и сколько соединений может устанавливать HTTP-акселератор с апстримом;
- Что становится с запросами, которые ждут очереди на отправку в соединение с апстримом, но апстрим "из коробки" и сбрасывает соединения каждые 100 запросов;
- Что такое HTTP pipelining, и как им пользуются современные HTTP-акселераторы;
- Что такое неидемпотентные запросы, и почему нужно о них беспокоиться.

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

После подключения DDoS-защиты: как "положат" Ваши ресурсы

Рамиль Хантимиров

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

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

Как устроены базы данных

Илья Космодемьянский

Хранить и обрабатывать данные нужно везде, неслучайно, как минимум последние полвека, интенсивно развивались специализированные для этой задачи фреймворки - сервера управления базами данных (СУБД). Как они выглядят сейчас и почему, несмотря на разницу в реализации, одни СУБД принципиально похожи на другие?

В этом докладе мы начнем с основ: транзакции, алгоритмы сериализации, контроля конкурентного доступа и восстановления. Как они реализованы в современных СУБД? Что нужно знать о них разработчику или администратору высоконагруженных систем? Как устроен WAL, и как это помогает обеспечивать резервное копирование и отказоустойчивость? Как СУБД работает с памятью и диском? Почему SQL до сих пор жив как технология, и как работает оптимизатор?

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

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

Чеклист по клиентской оптимизации

Николай Лавлинский

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

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

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

В докладе разберём пример ускорения реального сайта, по шагам замеряя эффект.

Вот примерный чеклист по клиентской оптимизации, покрывающий большинство проблем среднего веб-проекта:
1. Базовая конфигурация Nginx для эффективной раздачи статики.
2. Клиентское кэширование: заголовки, сброс кэша, особенности браузеров.
3. Сжатие текстового контента: gzip, zopfli, brotli, статическое сжатие, поддержка Nginx и браузеров.
4. Быстрый TLS: конфигурация Nginx, нагрузка на сервер и клиент, наиболее оптимизированные шифры, типы сертификатов, stapling, кэширование сессий, HTTP/2.
5. Настройка TCP/IP-стека в Linux для веб-приложений.
6. Оптимизация картинок: для JPEG, PNG, SVG, применение WebP.
7. Веб-шрифты: форматы, подходы к оптимизации.
8. Общий подход к ускорению рендеринга страниц (синхронная/асинхронная загрузка CSS, JS, объединение ресурсов), клиентские SPOF.
9. Использование CDN: когда нужно, зачем. Влияние задержек сети на скорость.
10. Средства синтетического тестирования клиентской скорости.

Веб-графика, оптимизация изображений
,
Сетевое администрирование
,
Производительность и мониторинг фронтенда
Доклад принят в программу конференции

Рост с нуля до 15000 сообщений в секунду. Мучительный и поучительный

Юрий Колесов

Компания TIMCONNECT процессит банковские смс-сообщения, по возможности отправляя их как push.

Расскажем, как мы за 2 месяца небольшой командой масштабировались в 15 раз, минимально переписывая код, применяя паттерны из хайлоада методом проб и ошибок. На примерах проиллюстрируем, что хайлоад может быть достижим просто и быстро. Если повезет.

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

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

Профессиональный фестиваль Российские Интернет-технологии

Интернет-вещей (IoT)

Делаем заводы умнее, или Как мы научили станки разговаривать

Александр Лизунков

There are no shortcuts to any place worth going (Helen Keller, «К достойной цели нет коротких путей»).

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

С этого все начиналось и могло бы закончиться, если бы мы не поставили перед собой самую важную задачу: не останавливаться на достигнутом. Дальше – больше: после мониторинга появилась аналитика, сначала простая, потом – сложнее и сложнее, сейчас мы можем сделать практически любой отчет на основе тех данных, что мы получаем с оборудования. Самое главное – для чего все это?

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

Путь от истоков до нынешнего формата занял почти 4 года, мы много чего уже сделали, но количество задач в пуле на грядущие релизы неизменно растет, что говорит о правильности выбранного нами пути.

Ставя перед собой амбициозные цели, мы все же поняли, что не сможем в одиночку покрыть все потребности современного предприятия. С другой стороны, мы, позиционируя себя как одного из драйверов идей Индустрии 4.0, понимаем, что каждый наш шаг должен быть направлен на снижение числа элементов бизнес-процессов, в которых задействован человек. Выход только один – максимально гибкая интеграция с существующими ERP и MES-системами. Как интегрироваться: файловый обмен, прямые коннекты, RPС, асинхронная передача? Если еще учесть определенные концептуальные и технологические различия, то получается для каждого клиента это фактически своя история.

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

You haven’t fear of perfection; you’ll never reach it. (Salvador Dali, «Вам не следует бояться совершенства, Вам его не достичь»).

Прослушав доклад, вы сможете:
1) Понять, что даже маленькая команда с очень смелой идеей может выйти на Industrial Market и начать менять к лучшему организацию труда в отрасли.
2) Не делать ошибок, в погоне за тем, чтобы включить в ближайший релиз всё, что хочется, а в большей степени сосредотачиваться над стабилизацией решения.
3) Узнать о проблемных и местами забавных аспектах интеграции IIoT-решений с внешними системами.

Бизнес на стыке онлайн и офлайн
,
Взаимодействие с государством
,
Процессы и инструменты в enterprise
,
Импортозамещение
,
Internet of Things
,
Мобильные приложения / другое
Доклад принят в программу конференции

Строим mesh-сети 6LOWPAN на основе Contiki OS: теория и практика

Владислав Зайцев

1. Применение сетей стандарта 802.15.4(6lowpan) в интернете устройств и промышленном интернете устройств: делаем систему умного дома и систему диспетчеризации и управления уличным освещением.
2. Что такое сети на основе 6lowpan, чем они отличаются от обычных компьютерных сетей. Что внутри устройств: микроконтроллеры CC1310/CC2650 и Contiki OS.
3. Кейс 1: делаем устройства с питанием от батарей. Энергосбережение, contiki-mac, radio duty-cycle, время жизни маршрута.
4. Кейс 2: строим большую (100 устройств) и протяженную (2 км) сеть. Как не увязнуть в маршрутах, использование симулятора и сниффера для диагностики сети.
5. Кейс 3: делаем ОТА-обновление с использованием внешней памяти. Версии, передача больших образов в малых пакетах, механизм отказоустойчивого обновления, golden-image.

C/C++
,
Встраиваемые системы
,
Internet of Things
Доклад принят в программу конференции

Интернет станков

Андрей Ловыгин

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

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

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

Бизнес на стыке онлайн и офлайн
,
Будущее рынка разработки ПО
,
Управление / другое
,
Импортозамещение
,
Разработка CRM и ERP
,
Internet of Things
Доклад принят в программу конференции

Интернет ненужных вещей

Сергей Мясников
Александр Несслер

Альтернативное видение того, как не будет и как будет развиваться индустрия IoT.

Хотя термин "интернет вещей" появился ещё в 1999-м году, распространение он получил только 10 лет спустя. С тех прошло ещё 8 лет, но технология так и не получила развития, несмотря на довольно серьёзные усилия, приложенные как крупными корпорациями, так и рядовыми участниками рынка. Рядовому потребителю пока ещё так и не доступен интернет кофеварок и парных носков. Мы считаем, что на то есть фундаментальные причины.

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

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

Микросервисы

Микросервисы для Machine Learning

Дмитрий Ходаков

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

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

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

Преимущества и недостатки микросервисной архитектуры в HeadHunter

Антон Иванов

Раньше HeadHunter был большим монолитным приложением. Несколько лет назад мы приняли решение выделять из него микросервисы. За несколько лет мы поняли, что микросервисы - это не серебряная пуля и при неправильном "распиле" создают существенные проблемы: сложность разработки, деплоя, эксплуатации и др. Иногда эти проблемы сводят на нет преимущества от использования микросервисов.

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

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

От сырых данных до отчета. Архитектурные подходы в проекте Автотека

Николай Балакирев

Автотека (autoteka.ru) - новый проект, с помощью которого можно проверить историю автомобиля. Для получения данных по конкретному VIN за секунду сервису нужно посетить более 10 сторонних API, а также извлечь заранее собранные данные от дилеров и из других источников, предоставляющих статичную информацию. На этом сложности не заканчиваются, структура данных у каждого источника своя, встречаются пересечения записей по времени. Используя VIN и дату события в качестве уникальных идентификаторов, мы производим слияние по определенному набору правил, что позволяет нам получить выборку событий, интересных для конечного потребителя, исключив оттуда всё лишнее.

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

PHP
,
Микросервисы, SOA
Доклад принят в программу конференции

Микросервисы в продакшн. От коммита до релиза: полная автоматизация в Kubernetes

Елена Граховац
Игорь Должиков

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

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

В демонстрации будет использована система управления контейнерами Kubernetes.

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

На мастер-классе участникам предлагается попробовать себя в решении следующих задач:
- написание простейшего REST-сервиса на Go;
- доработка сервиса под специфику конкретных задач;
- взаимодействие сервисов между собой;
- упаковка сервиса в минимальный необходимый Docker-контейнер;
- настройка процессов Continuous Integration и Continuous Delivery;
- подготовка шаблонных конфигураций сервиса для менеджера релизов Helm;
- автоматические релизы сервиса на разные окружения в Kubernetes.

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

Прочие языки
,
Микросервисы, SOA
,
Технологии виртуализации и контейнеризации
,
Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
Доклад принят в программу конференции

Legacy в коробочке. Dev-среда на базе Kubernetes

Илья Сауленко

Новые микросервисы появляются, но монолит никуда не исчезает. Мы в Avito разрабатываем и деплоим сервисы с помощью связки Docker и Kubernetes. Зачастую интегрировать монолит с сервисами довольно проблематично. А что, если монолит тоже завернуть в Docker+Kubernetes и применять те же практики, что и для микросервисов?

В докладе речь пойдёт о том, как изменилась Dev-среда в Avito в связи с переходом на микросервисную архитектуру. В частности, поговорим про:
- подход "legacy in a box";
- то, как мы решали проблемы с базами и sphinxsearch;
- то, как Docker и Kubernetes помогли нам сократить различия между окружениями;
- Developer Experience.

Доклад будет полезен как командам, планирующим или переживающим распил монолита, так и всем тем, кому приходится работать со сторонними legacy-системами.

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

Управление секретами в кластере Kubernetes при помощи Hashicorp Vault

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

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

В докладе будет сделан краткий обзор Hashicorp Vault, рассмотрены случаи автоматического и безопасного управления секретами с помощью puppet+hiera. Особое внимание будет уделено встроенным секретам Kubernetes: я обозначу проблемы управления ими и недостатки существующих решений для связки с Vault, а также расскажу, как мы преодолели все эти трудности с помощью простого самописного решения.

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

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

Мониторинг в микросервисной архитектуре

Владимир Колобаев

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

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

Микросервисная Архитектура: проблемы и решения

Сергей Орлов

Большое количество современных веб-проектов переходит на микросервисную архитектуру.

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

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

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

События, события и ещё раз события. Опыт построения Event Stream Processing

Антон Сухов

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

Из доклада вы узнаете, как устроен Event Stream Processing (ESP) в Avito. В том числе я расскажу, какие требования были заложены на этапе проектирования, почему мы были вынуждены отказаться от fluent в пользу NSQ, как реализован единый регистр типов событий и окружений для всех команд, как экспортировать схемы событий в различные форматы, как мы боремся за эффективное расходование железа и масштабируем ESP.

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

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

Информационная безопасность

DDoS-атаки: тектонические изменения в 2016-2017 году

Артём Гавриченков

Осенью 2016 года DDoS-атаки, уже, казалось бы, ставшие досадной обыденностью, вновь выплыли на первые полосы журналов и онлайн-изданий. Атаки с использованием ботнета Mirai и подключенных к Интернету камер сумели создать серьёзные проблемы с доступностью целого ряда сайтов, включая Twitter, Spotify и Reddit.

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

Обсудим нынешнее состояние Интернета, те угрозы, которых можно ожидать для функционирования Интернет-ресурсов, а также методы защиты от них.

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

Опасная сериализация

Иван Юшкевич

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

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

Внедрение SDLC в боевых условиях

Егор Карбутов

Наш доклад на тему, которая практически не имеет подробного описания в интернете. Мы хотим рассказать, как мы (Digital Security) - компания, которая специализируется на анализе защищённости и исследованиях в области ИБ - внедрились в цикл разработки продуктов. Посвятим немного времени SDLC.

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

Single page application, толстый клиент
,
Защита информации
,
Большие проекты/команды
,
Внедрение и поддержка
,
Безопасность в мобильных приложениях
Доклад принят в программу конференции

Практика безопасной разработки в СберТех

Дмитрий Янченко

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

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

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

Не типичные и критичные

Глеб Чербов

Устали слушать о том, как с помощью SELF-DOM-XSS можно захватить предприятия? Повсеместно одни SQL-инъекции в формах логина и полях поиска? Надоел маркетинг инновационных решений, которые позволят защититься от кликджекинга?

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

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

AppSec, ключ на старт!

Юрий Сергеев

В сложной экосистеме разработки программного обеспечения, даже если инициатива Appllication Security получила зеленый свет и надлежащий бюджет, множество проблем остаются нерешенными для успешного старта: множество дорогостоящих инструментов SAST / DAST / IAST / RASP, минимальное количество appsec-специалистов на рынке труда, несовершенные инженерные процессы, отсутствие метрик и измеримых индикаторов успеха и т.д.

В рамках данной сессии будет продемонстрирован тактический подход для запуска центра компетенций (Software Security Group), адресующий вопросы как приоритезации, масштабируемости, управления портфелем разрабатываемых приложений в контуре AppSec, так и аспекты мотивации команд. Будет презентована структура фреймворка BSIMM как основа практик AppSec и представлена типовая дорожная карта развития зрелости инженерных организаций. Также будут представлены ключевые слагаемые успеха, необходимые для построения концепции SecDevOps в рамках цикла разработки защищенного ПО (Secure Software Development Lifecycle) вместе с практическими рекомендациями.

Непрерывная интеграция
,
Devops / другое
,
Code Review
,
Автоматизация разработки и тестирования
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Большие проекты/команды
,
Тестирование безопасности
Доклад принят в программу конференции

Application Security - ответы на ежедневные вопросы

Сергей Белов

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

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

Машинное обучение

Cкоринговые модели нового типа: анализируем действия клиента

Максим Савченко

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

Кейс 2: сегментация клиентов на основе их финансового поведения (анализ данных высокой размерности и большого размера).

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

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

Ранжирование откликов соискателей с помощью машинного обучения

Сергей Сайгушкин

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

В докладе прозвучат ответы на следующие вопросы:
— Какие бизнес-требования перед нами стояли, и какие решения мы выбрали.
— Какие особенности внедрения в production сопровождали эту задачу (как быстро отранжировать 1М резюме).
— Как мы выбирали алгоритм классификации (LogisticRegression, GradientBoosting, RankSVM, XGBoost).
— Какие результаты мы получили и как их измеряли.
— Какие типы поведения рекрутеров мы обнаружили.

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

Применение машинного обучения для генерации структурированных сниппетов в поисковых системах по трудоустройству

Никита Спирин

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

Чтобы помочь пользователям быстрее находить релевантные результаты, поисковые системы показывают на странице результатов ссылки и краткие описания результатов (2-3 строчки), называемые сниппетами. Сниппеты позволяют различать результаты друг от друга, таким образом помогая минимизировать просмотры повторяющейся информации, и определять релевантность каждого отдельного результата. Если же сниппеты неинформативны, пользователи вынуждены просматривать все результаты один за другим и терять ценное время. Например, таковыми являются сниппеты многих ведущих поисковиков работы --- они содержат лишь должность и место работы, опуская важную информацию о требованиях, обязанностях, навыках и др.

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

Фронтенд / другое
,
API
,
Python
,
Поисковые системы
,
Бэкенд / другое
,
Нагрузочное тестирование
,
A/B-тестирование
,
Machine Learning
Доклад принят в программу конференции

Сегментация объектов на спутниковых снимках (Kaggle DSTL)

Артур Кузин

В докладе я расскажу про решение задачи сегментации объектов на спутниковых снимках, которая была поставлена в рамках Kaggle-соревнования Dstl Satellite Imagery Feature Detection. В этом соревновании я в команде с Романом Соловьёвым занял 2 место.

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

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

Поиск признаков мошенничества в убытках по медицинскому страхованию

Василий Рязанов

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

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

Страховая компания Allianz первой в России решила применить для этой цели технологии машинного обучения. На сегодняшний день создана пилотная версия системы автоматического поиска аномалий, обученная на результатах проверки экспертами за несколько последних лет. Результаты пилотных тестов показали перспективность дальнейших разработок.

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

Машинное обучение в электронной коммерции - практика использования и подводные камни

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

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

Особое внимание уделим технике использования популярных платформ и библиотек:
- Apache Spark,
- Spark MLlib,
- Hadoop,
- Amazon Kinesns.

Отдельно остановимся на особенностях обработки "больших данных", выборе и разработке параллельных алгоритмов.

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

Общая программа

Документация REST API

Артём Кузвесов

Часто возникает ситуация, когда нужна документация для API. Например, если вы работаете в команде, где роли backend- и frontend-разработчиков исполняют разные люди. Или нужно дать доступ к API сторонним разработчикам.

Такая документация должна быть всегда актуальной и легко читаемой. Как показывает практика, хранение её в google docs/Markdown/reStructuredText/etc. неудобно, и программисты часто забывают её вовремя актуализировать. Лучше всего, если документация API будет храниться максимально близко к коду.

Взаимодействие с серверной стороной (API)
,
Node.js и io.js
,
API
Доклад принят в программу конференции

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

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

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

Работа с зарубежным заказчиком/рынком
,
Юридические вопросы
,
Взаимодействие с государством
Доклад принят в программу конференции

Профессиональная конференция по эксплуатации и devops RootConf

Технологии отказоустойчивости и катастрофоустойчивости

Пряморукий DNS: делаем правильно

Лев Николаев

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

Несмотря на все свои крутые преимущества, вроде split horizon, bind, к сожалению, далек по своей производительности от оптимального выбора.

В докладе рассматриваются следующие конфигурации:

1. Просто (быстрый) резольвер. Области применения: организация, провайдер, ЦОД

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

Здесь властвует unbound. Важные пункты:
- никаких форвардов на Яндекс или Гугл
- SO_REUSEPORT
- prefetch
- DNSSEC-валидация обязательно
- что мониторить?

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

2. Свои зоны. Области применения: организация, провайдер, иногда ЦОД

Своя DNS-зона рано или поздно появляется у каждого. Здесь, конечно, только PowerDNS. Важные пункты:
- почему только база данных, только хардкор
- почему никаких XFR, а только уровень базы данных
- почему репликация БД тут плохо, и что тут хорошо?
- и как насчет хранения зоны, гм, в git-репозитории?
- что мониторить?

3. Сочетание своих зон и резольвера

У провайдеров, да и часто в крупных организациях, возникает необходимость блокировать резолвинг каких-то записей. Причин тому масса - от требований закона до вирусов. Здесь нужно использовать PowerDNS и unbound в режиме Apache + nginx.

- PowerDNS принимает запрос изначально
- если может ответить на него, то отвечает
- а если не может, то отдает unbound для обработки

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

Управление в эксплуатации

Мифы о DevOps

Александр Титов
Иван Евтухович

Про DevOps, как и про Agile, сейчас говорят все, но все равно ничего не понятно. Часто послушаешь доклад и ощущение, что все в компании и так по DevOps, и не надо ничего делать, или, наоборот, ощущение, что это совершенно дикая история, и DevOps-практики категорически противопоказаны.



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


1) DevOps может делать DevOps-отдел или DevOps-инженер.
2) DevOps — это про то, что надо нанимать специалистов-многостаночников, которые умеют все.

3) Мы разрабатываем корпоративную ИТ-систему, и у нас DevOps уже с 1995 года.
4) DevOps — это "правильные" инструменты.
5) DevOps — это "философия", специальная культура, которая уникальна и не может быть повторена.
6) В ITIL уже этот ваш DevOps заложен и не надо старое выдавать за новое.
7) DevOps — это маркетинговое словечко, за которым ничего нет.

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

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

Продуктовые проблемы при создании очередной Docker PaaS

Владимир Ярцев

Благодаря Docker'у, контейнеры стали доступны каждому. Однако, чтобы развернуть production-систему на Docker'е, нужно решить ряд инфраструктурных задач: логи, мониторинг, бэкапы, отказоустойчивость, апдейты, безопасность. Решить эти задачи "для себя" не сложно, но при попытке превратить свое контейнерное решение в программный продукт возникают проблемы: "глупые" пользователи, нестабильный хостинг, коварные конкуренты и неясное будущее продукта. Эти трудности - системные, и лучше о них знать заранее. Я расскажу о них на примере проекта dockhero.io.

Devops / другое
,
Методологии и процессы разработки ПО; Сроки и приоритеты
,
Продуктовая разработка
Доклад принят в программу конференции

Как подружить команду админов с N командами разработки

Денис Яковлев

Web-отдел 2ГИС - это 5 команд разработки и более 20 проектов разного калибра. Это означает множество релизов каждый день и постоянные изменения.

Что мы имели раньше? Команда - bottleneck из нервных админов, работающих часто сверхурочно.
Что сейчас - команда инфраструктурных инженеров, предоставляющая сервисы для команд разработки.

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

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

Управление конфигурацией

Everything as a Code

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

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

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

В докладе будет представлен личный опыт автора по автоматизации различных элементов разработки ПО.

Управление конфигурацией
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
Доклад принят в программу конференции

Непрерывное развертывание и деплой

Наш опыт с Kubernetes в небольших проектах

Дмитрий Столяров

Опыт эксплуатации Kubernetes в production есть пока далеко не у всех. Компании «Флант» удалось за последний год внедрить Kubernetes многим клиентам, и именно об этом мы хотим рассказать. Широкий и систематизированный опыт, собранный в этом докладе, должен вызвать интерес у всех тех, кто только слышал о Docker или начинает его использовать, или выбирает «платформу» (Marathon, Rancher, Kubernetes)… или уже давно что-то использует!

В последний год мало кого можно удивить такими словами, как Docker Swarm, Rancher, Marathon или Kubernetes. Очень многие крупные и динамично развивающиеся проекты или уже переехали на Docker (под управлением одной из систем) или всерьез прорабатывают этот вопрос, а уж у всех DevOps-специалистов эти слова тем более давно на слуху.

Но как это выглядит на практике? Мы поделимся своим опытом перехода на Kubernetes и его дальнейшей эксплуатации в проектах среднего размера (до 50 серверов), а именно:
- Расскажем, что потребуется для перехода на Kubernetes и как к этому подготовиться.
- Приведем несколько примеров архитектур, ставших уже типовыми для нас.
- Покажем, как мы обычно выстраиваем CI/CD (с использованием GitLab и dapp), и какие могут быть варианты.
- Постараемся ответить на вопрос, зачем Kubernetes может быть нужен вашему проекту, систематизировав и разложив по полочкам все (известные нам) плюсы и минусы.
- И, наконец, поделимся сведениями о расположении и размерах подводных камней.

Мы так довольны результатом внедрения Kubernetes, что всерьез планируем уже в этом году перевести на него еще ~50 существующих проектов.

Микросервисы, SOA
,
Архитектурные паттерны
,
Технологии виртуализации и контейнеризации
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Автоматизация разработки и тестирования
Доклад принят в программу конференции

От репозитория до CI/CD-инфраструктуры в продакшне за неделю

Дмитрий Чумак

В докладе я разберу развертывание CI/CD в сжатые сроки на реальном технологически нагруженном проекте. Несколько PostgreSQL, кластер Neo4J, нейронные сети, dev-stage-prod окружения.

Планирование архитектуры проекта с точки зрения приложения, мотивация выбора конкретной схемы.
Как настроить связку Ansible+Docker+Consul на живом проекте за три дня. Почему Amazon не всегда хорошо, проблемы с балансерами, VPC и нюансы ECS.

Этапы разворачивания CD, планирование, концепции, реальность. Коррективы со стороны разработчиков и влияние требований разработки на итоговую инфраструктуру.

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

Технологии виртуализации и контейнеризации
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
Доклад принят в программу конференции

How to build solid CI-CD pipeline

Илья Беда

На основе своего опыта работы в консалтинге я расскажу, как избавить разработчиков от рутинных задач и как сэкономить на ресурсах команды с помощью правильно настроенного CI-CD pipeline.

Единствено верный способ упаковки приложений - это Docker-контейнеры, благодаря этому способу вы сможете унифицировать процесс деплоя. Нужно деплоить приложения с помощью Ansible-плейбука, запакованного в Docker-контейнер, это снижает требования к окружению CI-ранера. Вам нужен только Docker.

Полная интеграция между между таск-трекером, хранилищем исходного кода, CI, хранилищем Docker-образов и CD позволит команде иметь всю информацию о состоянии staging- и production-окружений в одном единственном веб-интерфейсе. Такие современные SaaS, как github.com, travis-ci.org, circleci.com не дают достаточного контроля над окружением, поэтому я выбрал Gitlab-CE и Gitlab-CI для построения CI-CD pipeline.

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

Технологии виртуализации и контейнеризация

Самоорганизующаяся сервисная инфраструктура на базе Docker

Данила Штань

Я расскажу об удачной попытке сделать современную распределённую экосистему для эксплуатации софта на базе Docker-контейнеров, которая собрана из базовых и довольно простых компонентов, без переусложнённости Kubernetes или Mesos+Marathon.

Мы обсудим, как можно упростить сетевой слой, как без особых проблем работать с Docker Swarm, как построить service discovery, мониторинг, rolling updates и прочие красивые слова, максимально отдав это на уровень разработчиков.

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

Использование Docker в CI

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

В своём докладе я расскажу о том, почему мы решили использовать Docker в рамках Continuous Integration: ускорить тесты, повысить стабильность, улучшить контроль над окружением и используемыми библиотеками.

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

В конце доклада я покажу, как именно мы следим за стабильностью Docker в нашей инфраструктуре. И насколько Docker стабилен на больших объемах (>100k билдов в сутки).

Технологии виртуализации и контейнеризации
,
Непрерывная интеграция
Доклад принят в программу конференции

SDN & DEVOPS ?= ❤: Практики использования SDN в реальной жизни DevOps

Александр Шалимов

Об SDN/OpenFlow говорят давно и много: разделение уровней управления и передачи данных, сетевая логика выносится в отдельный централизованный узел, называемый контроллером сети. На выходе получаем удешевление оборудования, автоматизацию и упрощение управления сетями. Уже сейчас эти технологии применяются и в ЦОД, и у операторов связи, и в больших корпоративных сетях. Но возникает справедливый вопрос: "Мы, конечно, рады за Google, AT&T и Microsoft, но что они дают нам, простым пользователям? Где мы можем их применить в наших задачах и можем ли мы вообще?". Короткий ответ: "Да, можем!".

В докладе будут рассмотрены практические примеры использование SDN/OpenFlow в реальной жизни и решение своими силами следующих задач: ACL (черные, белые списки), DPI (URL filtering), зеркалирование, QoS (приоритезация, ограничение полосы пропускания), балансировка нагрузки ("IPVS" на 10Gbps), защита от DDOS. Будет представлен используемый инструментарий (программные коммутаторы - Open vSwitch, Lagopus и OpenFlow контроллеры - Ryu, ODL, Runos), примеры скриптов и кода.

Цель такого workshop'а показать простоту, удобство и, главное, полезность существующего инструментария из мира SDN/OpenFlow.

Технологии виртуализации и контейнеризации
,
Сетевое администрирование
,
Devops / другое
Доклад принят в программу конференции

Логирование и мониторинг

Переезжаем с Zabbix на Prometheus

Василий Озеров

- Почему prometheus?
- быстрый (golang)
- time series database
- простота развертывания через scm (ansible/chef/puppet/salt)
- готовые exports & dashboars for grafana

- Внедряем
- переносим базовый мониторинг систем в prometheus (cpu/disk/net/mem)
- настраиваем discovery новых хостов и сервисов
- подключаем визуализацию
- настраиваем алертинг

- Дополнительно
- резервируем prometheus (alertmanager + prometheus instance)
- получаем информацию из собственных приложений
- получаем статистику из логов

- Заключение
- возможности масштабирования
- какую нагрузку держим

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

Мониторинг быстродействия web-проекта

Владимир Буянов

Знаете ли вы, что видят пользователи после деплоя вашего кода на продакшн?

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

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

Насколько жив ваш CI

Андрей Кононов

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

Логирование и мониторинг
,
Непрерывное развертывание и деплой
,
Непрерывная интеграция
,
Devops / другое
Доклад принят в программу конференции

MathOps или математика в мониторинге

Павел Труханов

Мониторинг — это и cpu usage, iowait, load average, и времена ответа сайта и отдельных сервисов.

Тайминги ответа — среднее по всем запросам? Нет, подайте лучше медиану, а то и 99-перцентиль!

Но что такое перцентиль? Посмотрим в википедии и всё поймём! Не совсем.
Там тьма проблем, зачастую скрытых от наивных пытливых умов:
- При подсчете любой статистики от тысячи таймингов, будь-то среднее, перцентиль или что угодно, в любом случае теряются данные о распределении. Что нужно не терять и почему — зависит от решаемой задачи: когда и среднее сойдёт, а когда и перцентиль не поможет.
- Как это всё хранить и отображать на графиках? Для данных за неделю не хватит пикселей на вашем мониторе — как выбрать что оставить? А если много серверов ­— с каждого своя перцентиль?
- Вы, кажется, слышали, что за усреднение перцентилей выгоняют из приличного общества…

Когда со всем этим разобрались, то вы решили задать SLA на тайминги ответа сайта, допустим на 99-перцентиль. Не мало? Сколько 9-ок взять? 3, 5, 10? Что на самом деле происходит со временем ответа сервиса за пределами этих девяток?
Какое распределение у самих этих перцентилей? Насколько они шумные? Какая ошибка в минутных перцентилях накапливается за день, за неделю?
Может, есть что-то получше? Гистограммы! Но они не так гибки — надо заранее выставлять и угадать пороги.

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

Отказоустойчивость
,
Распределенные системы
,
Логирование и мониторинг
,
Devops / другое
,
Выбор стратегии долгосрочного развития, KPI
,
Проектирование информационных систем
,
Внедрение и поддержка
,
Теории и техники анализа
Доклад принят в программу конференции

Zabbix 3.4 - простая непростая дружба с сообществом

Алексей Владышев

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

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

Я расскажу о том, как мы работаем с сообществом, мониторим и реализуем запросы. Всегда ли мы это делаем эффективно или что-то можно улучшить?

Приходите! Доклад будет интересен не только тем, кто интересуется Zabbix и мониторингом в целом, но, надеюсь, что и разработчикам открытых программных продуктов.

Логирование и мониторинг
,
Управление конфигурацией
,
Сетевое администрирование
,
Devops / другое
Доклад принят в программу конференции

Конференция Web-scale IT Conference

Реальное импортозамещение

Мир. Восход. Эльбрус. PostgreSQL

Илья Космодемьянский
Игорь Чижевский

В докладе пойдет речь о запуске ГС Мир/ГС ПВДНП (Государственной системы изготовления, оформления и контроля паспортно-визовых документов нового поколения) не просто на Open Source-стеке, а еще и на отечественных процессорах Эльбрус.

Изначальная архитектура системы уже включала Open Source-решения (например, Linux в качестве основной OS и PostgreSQL в качестве основной СУБД на территориальных объектах), но важный компонент системы - ЦОД - был реализован с помощью привычных промышленных решений: мейнфреймы, IBM DB2, for z/OS,IBM WebSphere MQ, IBM Tivoli. Но время внесло свои коррективы, и сейчас система полностью переведена на PostgreSQL, Ceph, Apache ActiveMQ, Redis, Zabbix, OTRS и другие элементы Open Source-стека. Вдобавок ко всему, это первая столь масштабная система, полностью переведенная на платформу МЦСТ Эльбрус.

Как можно взять и перевести такую критическую систему на непривычный стек? Какие есть плюсы и минусы у традиционного и нового стека технологий? В чем различия в эксплуатации и разработке? С какими трудностями столкнулись и какие архитектурные подходы пришлось поменять? В чем различия в структуре стоимости владения такой системой? Как обеспечить zero-downtime миграцию такой системы?

Обо всем этом пойдет речь в нашем докладе.

PostgreSQL
,
Критерии выбора технологий для проекта
,
Архитектуры / другое
,
Сравнение enterprise и web
,
Legacy системы, жизненный цикл продуктов
,
Процессы и инструменты в enterprise
,
Импортозамещение
,
Big Data и Highload в Enterprise
,
Интеграция web и enterprise-решений
Доклад принят в программу конференции

Процессы

Реальный DevOps в энтерпрайзе

Александр Тараторин

Что такое DevOps? Очередной модный термин? Методология? Набор инструментов? Культурные практики?

Для Райффайзенбанка DevOps - микс из всего перечисленного (смешать, но не взбалтывать!), применяемый чтобы:
- ускорить разработку и внедрение новых решений не в ущерб качеству;
- вовлечь админов в работу девелопмента;
- заинтересовать разработчиков жизнеспособностью их творений в реальной жизни.

DevOps в Райфе - одна из ключевых историй в ИТ-стратегии Банка, разветвленная программа, включающая в себя три больших стрима:
- Культура.
- Организация.
- Технологии.

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

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

Devops / другое
,
Коллаборативная работа
,
Процессы и инструменты в enterprise
,
Управление и персонал в enterprise
,
Agile-практики в госкомпаниях, банках, предприятиях
Доклад принят в программу конференции

Эволюция масштабирования Agile на примере трех продуктовых групп

Денис Тучин

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

Когда мы стартовали масштабную трансформацию, мы были сильно вдохновлены опытом компаний Spotify и ING, кроме того, "старшие товарищи" нас убедили, что SAFe - чуть ли не единственный способ построить Agile в такой большой организации как Сбербанк. Конечно, когда мы начали Agile-трансформацию в банке, мы столкнулись с множеством вызовов, но в докладе расскажу про опыт трансформации трёх продуктовых групп, каждая из которых состояла из трёх Scrum-команд.

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

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

Но были и другие вызовы в масштабировании Scrum: понятно, раз уж команды работают над одним продуктом, то между ними есть зависимости и стоит их отслеживать почаще, чем раз в неделю. Попытки организовать PO Sync, как в SAFe, не везде увенчались успехом. Каждая из продуктовых групп пришла к своему решению: одна группа адаптировала встречи из прошлой жизни, вторая взяла церемонии синхронизации из SAFe, третья - из LeSS.

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

Кроме того, постараемся успеть обсудить, как такой подход применяется в зависимости от распределённости команд.

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

HR 3.0: цифровые технологии управления персоналом

Тарас Полищук

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

Digital HR / HR 3.0 — это подход к управлению человеческим капиталом как активом, построенный на принципах измеримости, интеграции данных, анализа в реальном времени и технологической гибкости.

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

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

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Выбор стратегии долгосрочного развития, KPI
Доклад принят в программу конференции

Культура

Как государство видит IT-тренды?

Герман Клименко

Распознавание образов, телемедицина, интернет-вещей, bigdata, блокчейн и уберизация меняют нашу жизнь.

Как к IT-трендам относится государство? Что из технологий мы планируем регулировать, что будем использовать и на что делать ставку?

Выбор стратегии долгосрочного развития, KPI
,
Будущее рынка разработки ПО
Доклад принят в программу конференции

Государственный Enterprise

Николай Бобров

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

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

Как же построить правильный государственный сайт?

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

Технологический стек

Как Mail.Ru и AT Consulting перевели профили абонентов Beeline на Tarantool

Андрей Дроздов
Юлия Гейниш

Платформа виртуализации данных на основе Tarantool - система, созданная в Mail.Ru Group в прошлом году. Cовместно с АТ Consulting было создано и запущено в production решение для хранения 100 млн. профилей абонентов компании Beeline, выдерживающее значительные нагрузки.

За этот год обе команды собрали уникальный опыт работы на стыке web и enterprise. В докладе мы расскажем о процессе совместной работы вендора и интегратора на реальном примере с каждой из сторон: взглядах команд на проект, целях, процессах разработки, подходах к решению задач, QA и эксплуатации получившегося продукта. Подробно опишем проблемы, с которыми мы столкнулись на каждом из этапов (от составления ТЗ до production), как их решали, как разделяли обязанности и как в итоге пришли к четкому и прозрачному процессу работы.

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

Сравнение enterprise и web
,
Legacy системы, жизненный цикл продуктов
,
Big Data и Highload в Enterprise
,
Интеграция web и enterprise-решений
Доклад принят в программу конференции

Миграция БД >10Тб с DB2 на PostgreSQL без простоя БД (почти)

Дмитрий Погибенко

Вводные:
1) Необходимо переносить данные с минимальным простоем БД.
2) Необходимо произвести трансформацию данных из-за отличий между DB2 и PG и перемещением BLOB'ов в Ceph.
3) Перенос должен быть произведен за приемлемое время.
4) Нужно учесть зависимости между таблицами.

Технологии:
1) Отслеживание изменений с помощью триггеров.
2) Анализ зависимостей с помощью доработанного SchemaSpy.
3) Перенос с помощью Spring Batch.
4) Разбиение на партиции (два подхода: деление диапазона id между min и max на равные части; деление на диапазоны с равным числом строк).

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

Эволюция enterprise

Машины баз данных: таксономия, анатомия, эволюция, ареал, воспроизведение

Андрей Николаенко

Teradata, Exadata, Netezza и другие представители мира машин баз данных в этом докладе будут классифицированы, препарированы, а также будет обсуждена задача создания новых таких машин.

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

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

PostgreSQL
,
Oracle
,
Базы данных / другое
,
Сравнение enterprise и web
,
Импортозамещение
,
Big Data и Highload в Enterprise
,
Интеграция web и enterprise-решений
Доклад принят в программу конференции

Эпоха кровавого web-driven enterprise - современный подход к IT-инфраструктурам

Андрей Рыжкин

Тема: Web-driven enterprise инфраструктура в современных ДИТ (департаменты информационных технологий).

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

Тезисы:
- Что такое web-driven enterprise инфраструктура.
- Самые горячие проблемы ДИТ и варианты их решений.
- Каким должно быть современное ИТ-подразделение.
- Сравнение old school и new age подходов ДИТ в разрезе специалистов, расходов и time-to-market.

Сравнение enterprise и web
,
Конвергентность
,
Процессы и инструменты в enterprise
,
Интеграция web и enterprise-решений
,
Web-scale IT / другое
Доклад принят в программу конференции

Краудсорсинг в городском управлении

Денис Костров

1. Краудсорсинг - один из лучших инструментов привлечения жителей города к его совместному управлению.
2. Вы не представляете, сколько идей, о том как сделать город лучше, есть у его жителей.
3. Хочешь лояльного жителя - предложи ему вместе управлять городом.
4. Elon Musk (Илон Маск) в своем интервью назвал краудсорсинг одним из инструментов, который обязательно должен быть в любой компании.

В докладе:
1. Проблематика, для решения которой внедрялся краудсорсинг.
2. Система городских решений "Вместе": как взаимодействуют городские проекты краудсорсинг (crowd.mos.ru), система электронного референдума "Активный гражданин" (ag.mos.ru) и портал "Наш город" (gorod.mos.ru).
3. Подробнее о краудсорсинге: как устроена проектная схема - от формирования темы проекта до контроля реализации идей.
4. Как устроен проект изнутри: три схемы проведения проекта с пошаговым разбором основных вех.
5. Примеры, как надо делать и как не надо делать при внедрении краудсорсинга.

Взаимодействие с государством
,
Управление / другое
Доклад принят в программу конференции

Digital Transformation: от цифр аналитиков к примерам из практики

Константин Кичинский

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

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

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

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

«Все нормально, падаем!» - как мы, нарушив все традиции, использовали Agile в крупном производственном холдинге

Дмитрий Смоляров

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

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

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

Что мы получили:
- Кучу шишек!
- Ни с чем не сравнимый опыт!
- Уроки и открытия на будущее.
- Работающую систему, внедренную за непривычно короткие для нас сроки и с минимальными ресурсами!

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

Омниканальность в рознице (синергия offline- и online-продаж). Переходим от слов к делу

Михаил Заборов

Термин "омниканальность", пришедший на смену "мультиканальности" стало одним из самых модных и популярных слов , которое упоминают последние несколько лет, когда обсуждают направления развития розничных сетей. Он возник как ответ на попытку интернет-игроков вытеснить бывших оффлайн-гигантов, например, Amazon vs Walmart.

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

Мы с Вами:
* попытаемся от пустых лозунгов перейти к обсуждению возможных механизмов реализации этой концепции;
* обсудим, какие решения необходимо принять, и что на них влияет;
* рассмотрим, что действительно является ядром омниканальности, а что туда свалено до кучи (как это обычно бывает с общеупотребительными Buzzword'ами);
* рассмотрим варианты ИТ-архитектуры;
* выясним, какие подходы работы в online очень хочется применять в offline, и почему технологии пока не позволяют этого сделать;
* обсудим, куда это будет двигаться дальше, в частности, омниканальные и персонализированные коммуникации. И да, это о том, как в будущем Ритейлеры и Производители товаров будут следить за каждым вашим шагом.

Это доклад о проектировании бизнеса на стыке онлайн и оффлайн.

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

Три истории микросервисов

Игорь Беспальчук

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

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

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

Микросервисы, SOA
,
Архитектурные паттерны
,
Распределенные системы
,
Критерии выбора технологий для проекта
,
Архитектуры / другое
,
Большие проекты/команды
,
Управление / другое
,
Инфраструктура как сервис (IaaS), платформы как сервис (PaaS)
,
Legacy системы, жизненный цикл продуктов
,
Процессы и инструменты в enterprise
,
Web-scale IT / другое
Доклад принят в программу конференции

Сотрудничество

Веб-технологии для бизнеса в цифровую эру. Интеграторы vs Digital-агентства. Кто победит?

Ольга Куликова

1. Почему мне надо верить? Мой опыт снизу и сверху.
2. Что умеют интеграторы и не умеют digital-агентства.
3. Что умеют digital-агентства и не умеют интеграторы.
4. Ошибки интеграторов и агентств на проектах.
5. Что и как выбирать клиентам? Что лучше – уверенность сейчас? Или эффективность в перспективе?
6. Чем сердце успокоится? Экосистема веб-разработок через 5 лет.

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

Профессиональная конференция по управлению и предпринимательству WhaleRider

Бизнес и финансы

Финансовый менеджмент компании, оказывающей профессиональные услуги

Сергей Оселедько

1. Учет и анализ финансов.
2. Структура доходов и расходов.
3. Бюджетирование подразделений компании.
4. Финансовая политика.
5. Планирование денежного потока.

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

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

Денис Кочергин

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

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

А в качестве бонуса я расскажу о том, какой вклад в эволюцию бизнес-процессов вносит поколение миллениалов.

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

От сайтов на заказ к Enterprise-продуктам

Кирилл Новиков

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

История о том, как путем проактивного накопления экспертизы мы трансформируем заказную разработку в продуктовую, почему это работает и продаётся, какие результаты приносит нам, и как от этого выигрывает клиент.

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

Истории успеха

Рок-н-ролл и Способ работы, при котором прибыль растет каждый месяц

Михаил Трутнев

В этом докладе нет теории и идеологии, а только конкретные приемы, повышающие эффективность работы команды и бизнеса.

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

Ultimate Guitar - самая рок-н-ролльная команда мирового интернета - нашла свой СПОСОБ работы, который:
- отличает от конкурентов;
- гарантирует разработку продуктов мирового качества;
- помогает набрать звездных сотрудников.

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

Ни хао, Мосике!

Ярослав Городецкий

Китай - огромный и быстроразвивающийся IT-рынок, по размеру сопоставимый с IT-рынком США и на порядок превосходящий по объему IT-рынок России. Однако, российские предприниматели не рвутся работать на нем, хотя потенциально могут там заработать не меньше, чем на Западе. Скорее всего, этому мешают привычки и укоренившиеся стереотипы о Китае и китайцах.

Также бытует мнение о каких-то огромных различиях между нами и китайцами. Однако, по факту Пекин отличается от Москвы только размерами, Интернет-сервисы в Китае развиваются схожим образом с Россией, да и методы ведения бизнеса тоже вполне похожи (например, пугающее иностранцев слово "гуанси" в переводе означает привычное русское "связи").

В докладе мы подробнее расскажем о том, как все-таки надо взаимовыгодно работать с Китаем и почему это мало у кого получается из наших соотечественников. У нас есть опыт, которым можно поделиться: выручка CDNvideo от китайских клиентов превысила выручку клиентов из других стран, за исключением России. А совсем недавно у нас появился успешный опыт взаимодействия с китайскими инвесторами.

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

Проектный офис

Две метрики для оптимизации распределения ресурсов. Опыт применения

Андрей Плетенев

Будучи директором IT-компании, в которой использовался широкий стек технологий (порядка 40 библиотек, фреймворков, СУБД и языков), я столкнулся с проблемой управления проектами и менеджерами-"непрограммистами". В этой ситуации очень помогло создание нескольких метрик. Одна из них формализует уровень сложности задач, а вторая – уровень владения разработчиком той или иной технологией.

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

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Оценка сложности проекта
,
Управление / другое
Доклад принят в программу конференции

Разработка

Развитие и оценка программистов в продуктовых компаниях

Игорь Устюжанин

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

В докладе будет рассказан живой опыт одной из компаний России, где удалось внедрить систему подходов к оценке и развитию разработчиков, которая прижилась и приносит свои плоды. Послушав доклад, вы станете ближе к ответам на такие вопросы:
* От разработчика: "Что мне надо сделать, чтобы получать больше?".
* От руководителя: "Как надо выстроить систему оценки так, чтобы она признавалась сотрудниками справедливой и мотивировала их на развитие в нужном для компании направлении?".

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Продуктовая разработка
,
Управление / другое
Доклад принят в программу конференции

Человеческий капитал

Внедрение системы грейдов разработчиков в IT-компании

Алексей Флоринский

В докладе рассказывается реальный опыт внедрения системы оценки знаний и опыта разработчиков, начиная от разработки самой системы оценки и заканчивая проработкой методов оценки. Система оценки уровня специалистов содержит в себе не только технические пункты, но и, в большей степени, оценку опыта и soft skills, что позволяет по-новому развивать систему обучения специалистов и строить индивидуальный план развития.

Раскроем связь системы оценки специалистов с культурой компании: сочетание ценностей компании с личностным развитием специалиста, важность носителей культуры и методы распространения культуры среди новичков.

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

Большие проекты/команды
,
Модели руководства
,
Корпоративная культура и мотивация
,
Поиск и развитие команды
,
Управление и персонал в enterprise
Доклад принят в программу конференции

Команда

IT-евангелизм: как вырастить Бабу-ягу в своём коллективе

Виктория Гонгина

1. Эволюция сотрудника как технологического евангелиста: от джуниора до адвоката бренда. История о том, как сотрудник может измениться в отношении к продукту компании или остаться нейтральным.

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

3. Как повысить лояльность и доверие сотрудника, а сотруднику - получить доверие компании (и роль Хабрахабра в этом).

4. Работа с будущими евангелистами: мотивация, демотивация, типичные ошибки (+ кейс про внутрикорпоративных авторов Хабра).

5. Итоги, статистика, опросы, выводы.

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

Рост компании

Как программисту вырастить компанию

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

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

Я начинал с ковыряния just for fun в том, что мне было интересно, потом был готов всё бросить (особенно после общения с несколькими менторами и бизнес-консультантами).

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

Ряд некоторых решений смог принести долгожданный поток денег, достаточный для ровного расширения компании до оборота в миллион долларов в год и роста команды до 15 человек.

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

Также хочется рассказать о том, какие вопросы оказалось совершенно неважно решать на старте и какие стоит.

Работа с зарубежным заказчиком/рынком
,
Управление / другое
Доклад принят в программу конференции

Анализ

Инфографика: как визуализировать сложные данные для клиентов и партнеров

Алексей Колоколов

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

Темы, которые я хочу осветить в своем выступлении:

- что такое дашборд, чем он отличается от отчета;
- какие вопросы следует задать себе перед созданием информационной панели;
- виды отчетов;
- дашборд в "пищевой цепи" анализа данных.

Управление изменениями, управление требованиями
,
Проектирование информационных систем
,
Теории и техники анализа
,
Общение с заказчиком, извлечение требований
Доклад принят в программу конференции

Процессы

Эффективная техподдержка 24х7: инструкция по применению

Юлия Синянская

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

Краткое содержание доклада:
1. Определите, какой саппорт вам необходимо построить: 24х7 или пятидневка, поддержка физ. лиц или корпоративных клиентов:
- особенности;
- основные отличия.

2. Поиск и найм сотрудников:
- основные требования к кандидату;
- как и где искать.

3. Обучение новичков и уже работающих инженеров:
- какие качества и навыки необходимо развивать;
- способы обучения;
- геймификация.

4. Режим работы и рабочие процессы:
- сколько человек нужно для того, чтобы покрыть 24х7?
- какое расписание оптимальное?
- как правильно передавать заявку от одного инженера другому?
- как эскалировать заявки в разработку?

5. Оценка эффективности посредством KPI:
- какие метрики использовать?
- как работать с цифрами?
- мотивация команды.

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

Тривиально о тривиальном: электронные средства поддержания трудовой дисциплины в географически распределенной команде инженеров

Даниил Подольский

Компания GitInSky, также известная как ООО "Жить в небе", действует на рынке, который мы назовем "аутсорсинг системного администрирования", более трех лет.

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

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

Я посвятил анализу сложившихся в компании практик, их результатов и перспектив довольно много времени в начале 2017 года. Человеко-месяц, в общей сложности, если не больше. В основном размышлениям над вопросом, который, я уверен, регулярно задает себе руководитель любого звена: "Почему я так много работаю, а результат такой скромный?". Ответ, кстати, прост и неприятен: "Потому, что я не работаю, а трачу время".

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

Итак, я намерен рассказать:
* Что такое "трудовая дисциплина". Это, забегая вперед, совсем не "приходить на работу вовремя". Ну, или именно "приходить на работу вовремя", если правильно понимать это "вовремя".
* Что такое трудовая дисциплина в команде "удаленщиков". Надо сказать, что все это время мы набираем инженеров исключительно на "удаленку", и успешно — по большей части успешно — справляемся решать такой командой довольно сложные и интересные задачи.
* Почему на удаленке не работают традиционные средства поддержания дисциплины: личная харизма руководителя, бамбуковая палка, наручники и батарея.
* Какие формы принимает в такой ситуации традиционный процесс, и насколько эти формы уродливы.
* Подбираясь к теме доклада — как развивались наши представления о дисциплине, и какие средства мы пытались использовать на разных этапах становления компании.
* Наконец, к чему мы пришли. Что именно внедрено сейчас, как оно повлияло на наш доморощенный процесс. Что думают об этом менеджеры, и что говорят инженеры.
* Самое важное — для меня, уж точно: где провисает, и что мы собираемся с этим делать.

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

Стратегия

Глобальные стратегии интернет-игроков. Ваше место в пищевой цепи

Сергей Рыжиков

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

Сергей Рыжиков, генеральный директор "1С-Битрикс", порассуждает на тему стратегических возможностей рынка и потенциальных путей развития IT-компаний разного уровня.

Выбор стратегии долгосрочного развития, KPI
,
Антикризисный менеджмент
,
Будущее рынка разработки ПО
,
Управление / другое
Доклад принят в программу конференции

Growth hack разработка

Станислав Ажоткин

В Силиконовой Долине growth hacking обсуждают повсеместно уже не первый год. В России ситуация обстоит примерно так же. И с каждым днем все больше людей обращают внимание на эту таинственную технику роста бизнеса. Правда, как часто бывает с новой терминологией, далеко не все понимают, что же это такое и как именно, а главное, зачем это применять в бизнесе?

Когда мы говорим о том, чтобы применить growth hack подход в разработке, прежде всего речь идет о работе на основе постоянных тестов и экспериментов на пике технологического стека. В данном докладе вы услышите, что же такое growth hack разработка, когда ее нужно внедрять и познакомитесь с релевантными примерами.

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

Клиенты и продажи

Работа с возражениями при сдаче проекта

Владимир Завертайлов

— Добавьте вау-эффектов!
— Вы же профессионалы! Я за что вам ДЕНЬГИ ПЛАЧУ?!
— Пришлите еще вариантов!
— Почему вы сделали, как я сказал?
— Почему вы сделали, не как я сказал?
...

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Модели руководства
,
Корпоративная культура и мотивация
,
Работа со внешним заказчиком/исполнителем
,
Продуктовая разработка
,
Обслуживание клиентов, техническая поддержка, обратная связь
,
Управление / другое
Доклад принят в программу конференции

ABCDХ-сегментация — самый эффективный инструмент увеличения выручки стартапов ФРИИ

Артём Азевич

«Надо фокусироваться!» — эту фразу как мантру повторяют большинство основателей и менеджеров по продажам, которых я встречал. При этом до 80% своего времени они тратят на работу, которая приносит их компаниям минимум выручки. Против коллег работают культ клиентоориентированности и святая вера в то, что нужно работать со всеми заказчиками.

Чтобы помочь предпринимателям по-настоящему сфокусироваться на том, что приносит прибыль их бизнесу, в Акселераторе ФРИИ мы разработали методологию ABCDX-сегментации — на основе опыта 300+ IT-компаний.

На РИТ++ я поделюсь с вами основами ABCDX-сегментации. Расскажу, какой тип клиентов стоит за каждой из букв в названии методологии, и по каким признакам их можно различать. Поговорим о том, как работать с клиентами, которые приносят вашей компании максимум прибыли (сегменты A и B). Отдельно — о том, как автоматизировать работу с теми, кто приносит мало денег (сегменты C и D). В заключение, стоит ли тянуться к «звездам» — клиентам, с которыми вы хотели бы работать, но ваш продукт к этому еще не готов (сегмент X).

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

Повышаем рентабельность заказной разработки через эффективное ТЗ

Евгений Савицкий

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

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

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

Методологии и процессы разработки ПО; Сроки и приоритеты
,
Оценка сложности проекта
,
Продажи, конкуренция и аналитика
,
Работа со внешним заказчиком/исполнителем
,
Управление / другое
Доклад принят в программу конференции

Юриспруденция

IT-Беларусь: привлекательность для IT-бизнеса, модели работы с Беларусью, налоговые льготы в белорусском Парке высоких технологий, защита авторских прав на программное обеспечение

Елена Мурашко

1. Вводная информация о развитии/тенденциях IT-отрасли в Беларуси.
По прогнозу Международной финансовой корпорации к 2020 г. доход IT-отрасли Беларуси может достигнуть $3-4 млрд.
2. Успехи отрасли: Продукты (в том числе с белорусскими корнями): PandaDoc, Kino-mo, World of Tanks, Viber, MAPS.ME, MSQRD, Banuba, «Зомби Ферма», «Рыцари и Принцессы», «Клондайк», Texas Holdem Poker Free, Weather Live, My Alarm Clock, Notepad+. Успешные сделки в белорусском IT (Facebook vs MSQRD, Apalon vs IAC, Viber vs Rakuten и др.).
3. Модели использования кадрового потенциала Беларуси нерезидентами (РФ): фрилансер - ИП - дочерняя компания. Плюсы и минусы каждой модели.
4. ПВТ - специальный правовой режим для стимулирования развития IT. Сравнение ПВТ и Сколково.
5. Налоговая нагрузка на компанию в Беларуси и льготы ПВТ.
6. Требования для резидентства ПВТ и процедура вступления.
7. Охрана исключительных прав на ПО в Беларуси.

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