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

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

Противоречия, которые раньше казались чем-то редким и «вне» системы работы организации, стали ежедневной нормой.
- Как возможно соединить индивидуальные и групповые цели?
- Как могут сосуществовать кооперация и конкуренция?
- Как можно сочетать функционирование и развитие?
- Как могут одновременно жить лидерство и самоуправление/самоорганизация?

Теории, предназначенные для системного описания решений еще не до конца сформированы! Кто является субъектом изменений, и как они происходят? В чем парадокс и как управлять изменениями?

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

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

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

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

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

Что такое ретроспектива и зачем её проводить – много раз обсуждалось и всем понятно.

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

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

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

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

Необходимо включить в понятие коммуникаций понятие контейнирования - управления эмоциями/эмоциональным откликом в ответ на изменения. Есть три причины, почему изменения вызывают тревогу:
1) точка А (текущее положение) - представляет собой всегда некое равновесное состояние, в том числе и с точки зрения эмоций (какие бы сложные они ни были), и с этим равновесием предлагается расстаться;
2) точка Б (в которую движемся) - какой бы четкой она ни была, всегда вызывает тревогу и страх неопределенности;
3) сам способ информирования об изменениях и их реализации часто травматичен - "все наверху уже решили, делают вид, что советуются" воспринимается сотрудниками как «я не важен, я - ничто, я ничего не решаю».

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

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

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

Задача при «образовании» ЛПР – отделение представлений и механизмов принятия решений от самих решений. Когда эти представления «зафиксированы», возникает возможность их смены/развития для принятия управленческих решений нового уровня.

Мы поговорим о технологиях и методах работы с представлениями в нашей практике:
• Упражнения на управленческую действительность в игровом режиме – боль и унижение два раза в день.
• Деятельностный подход – «дом» состоит не из «г*вна и палок», а из деятельности по созданию «г*вна», «палок» и их доставке в одно место.
• Схема шага развития – способ конструировать будущее. Выкопать реку, чтобы было где плыть трупу врага.
• Схематизация – перевод деятельности в знаковые формы и работа с ними. Умножение и деление схем. Без гарантии результата и смысла.
• Групповая динамика - у кого круче прибор, кто перепрыгнет забор.
• Задачи модератора – заградительный огонь, акупунктура и спасение утопающих.

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

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

Мы, конечно, коснемся понятий и теории, но лучше ответим на ваши вопросы!
Прямо с ваших вопросов и начнем, пусть они будут самыми обычными или «с подвохом», например:
* Что есть коучинг и чем он не является?
* Почему мы не любим, я, кстати, тоже, слово коучинг!
* Коучинг, управленческий коучинг, executive-коучинг - что стоит за набившими оскомину словами.
* Каких результатов с его помощью можно достичь.
* Сколько стоит хороший коуч.
* Сколько клиентов может вести коуч?
* Нужен ли свой коуч в организации или приглашать, или своих растить?

Главное, это не будет доклад - это будет практическая коуч-сессия, и проверьте все сами!

Что объединяет врачей, психологов, педагогов и менеджеров? Нет, зарплата у них всех разная, а вот с людьми им приходится работать одинаково много. Что создает благодатную почву для эмоционального выгорания, которое:
-----
Проявляется нарастающим безразличием к своим обязанностям и происходящему на работе, дегуманизацией в форме негативизма по отношению как к клиентам (пациентам), так и к коллегам (сотрудникам), ощущением собственной профессиональной несостоятельности, неудовлетворенности работой, в явлениях деперсонализации, а в конечном итоге в резком ухудшении качества жизни. В дальнейшем могут развиваться невротические расстройства и психосоматические заболевания.
(c) Wikipedia
-----
Помню, много эмоций принес переход в компанию, где мы работали с Sun Microsystems. Продукт, который стоит у каждого в телефоне, командировки по три месяца в Кремниевую долину, легенды отрасли с тобой на совещании, зарплата в разы больше, чем до этого! Энтузиазм!

Не успел опомниться — переход в менеджеры. Новый статус! Теперь у тебя есть команда! Теперь у тебя больше зарплата! Энтузиазм! Это ли не признаки счастья?

Однако, проходит несколько лет, и ты обнаруживаешь себя в «Дне сурка». Приходишь на работу, открываешь Outlook, там тебя уже ждут. Десятки писем от заокеанских и сибирских коллег. Начинаешь разгребаться, приходят местные товарищи со своими задачками. Так проходит день. Вечером дома думаешь: надо что-то умное почитать. Но сил остается на телевизор и интернет. Дети? Блин, точно!..

Утром приходишь на работу, открываешь Outlook… День сурка.

Проходит какое-то время, и в голову закрадывается вопрос: "Эй, парень, так и будет все происходить до пенсии? И ничего не изменится?.. А для чего это все?..".

Выход нашелся под надписью “Свой бизнес”. Новый статус! Свобода! Теперь у тебя нет команды! И бесконечные перспективы по деньгам! Энтузиазм!

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

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

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

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

В современном мире часто приходится слышать о сравнении подходов к работе:
• Корпорации или стартапы.
• Технари или продажники
• Российский подход или международный.
• Поколение X или поколение Y.

Часто эти сравнения становятся поводом для holywars с многочисленными жертвами и отсутствующими победителями. Где лучше работать - в корпорации или стартапе? Кто важнее для компании – тот, кто делает продукт или тот, кто его продвигает? Где лучше строить карьеру – в России или на Западе? Как работать с поколением Y (и могут ли они работать вообще)?

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

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

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

Именно эти проблемы и решают специальные настольные игры.

* Как сделать так, чтобы тебя заметили и взяли на работу в компанию твой мечты?
* Как «пройти» собеседование?
* Как находить и привлекать специалистов?
* Как формировать культуру ответственности?
* Как определять осознанность и «химию» на собеседовании?
* Как увидеть и предотвратить эмоциональное выгорание?
* Как поддерживать состояние потока в работе?
* Как удерживать специалистов?
* Какие программы развития работают сегодня?
* Как находить специалистов в новых экспертных областях, когда даже не ясно, с чего начать!
* Как развивать HR-бренд.
* Траектории развития сотрудника в организации.
* Зачем и когда нужен HR?
* Как и где искать HR-профессионала (лидера/партнера/директора)?

Да мало ли что можно спросить у HR-профессионалов IT-компаний!

Начнем с формирования списка ваших вопросов и ответим на все!

До 70% работы руководителя связано с установлением и исправлением балансов:
- инвестиции / польза;
- цели / ключевые результаты;
- личные интересы / интересы организации;
- личные интересы / работа в команде;
- работа / отдых;
- результаты сейчас / долгосрочные результаты;
- идеи / цели;
- получение знаний / знания для достижения результата;
- удовольствие от работы / ориентация на результат;
- сотрудника все устраивает / организацию это не устраивает…

One-to-one встречи, performance review, работа с целями и мотивациями - все это инструменты настройки балансов, которые имеют свойство постоянно изменяться и ускользать…

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

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

5 кейсов в подборе в ИТ-команду:
1. Заявление на увольнение принес лучший сотрудник. План действий.
2. Вы нашли подходящего кандидата, а ему сделали оффер конкуренты. Ваши шаги.
3. Как действовать, когда долгое время не удается найти идеального кандидата.
4. Разнообразие команд (diversity) - компании, состоящие из одинаковых людей, менее эффективны.
5. Неудачный найм в команду. Какие дальнейшие действия.

В феврале этого года завершился конкурс Лидеры России. Финалистами стали 103 молодых управленца. Конкурс составил около 1:2000!

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

Мы встретимся с финалистом и полуфиналистом конкурса и ответим на все ваши вопросы:
* Зачем это все?
* Как это было?
* Может ли пройти в финал «человек с улицы»?
* 
Как проверяли?
* Трудно ли было?
* Кто может стать Лидером России?
* Какими качествами нужно обладать, чтобы стать финалистом?
* Почему среди финалистов так много корпоративщиков и так мало представителей IT?
* Как нужно готовиться мне, чтобы выйти в финал конкурса, который начнется уже в этом году!

Задайте свой вопрос!

Мне как владельцу и руководителю компании есть, что сказать по самой больной для ИТ-компаний теме: “Кадры”.

Реалии городов-миллионников (и не только) таковы:
- много аутсорсинговых компаний и фрилансеров, есть и продуктовые компании, но меньше;
- неплохие ВУЗ-ы, обучающие ИТ-шников;
- большая текучка в компаниях - мало кто работает дольше 2-3 лет на одном месте;
- многие уезжают в столицы или из страны, поработав в 1-2 компаниях.

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

Мы тоже задавались этими вопросами 5 лет назад, когда пытались искать разработчиков на рынке. Видели много недостаточно компетентных людей с высокими зарплатными ожиданиями, потому что возраст 30+, ипотека, жена и дети. И мы начали учить себе сотрудников сами, за 5 лет построив систему с хорошими воронками для студентов, отличной окупаемостью нового сотрудника, быстрым ростом до middle, развитием у сотрудников soft skills и продуктовой направленности.

За несколько лет мы обкатали на себе MVP, выпуская 10-12 курсантов в год. С этого года можем увеличить набор в несколько раз, обеспечивая кадрами не только себя.

Придя в Booking.com, любой разработчик (дизайнер, копирайтер и другие) начинает задаваться вопросом роста в компании. Траектории роста, как правило, направлены либо в техническую сторону (core -> senior developer), либо в сторону менеджмента (core developer -> team lead). Рост в обоих направлениях подразумевает наличие определенных навыков и способностей у человека, и никак не связан с "выслугой лет" или указаниями сверху.

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

Одним из способов решения данной проблемы стала так называемая "Game of Roles". Это интерактивный онлайн-тренинг, цель которого заставить человека выйти из зоны комфорта и дать ему возможность попробовать побыть в "роли" синьора или тимлида на короткий период. Этот тренинг отличается от классических аналогов тем, что он полностью проходит онлайн, распределен во времени и, будучи групповым, фокусируется на индивидууме.

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

* Бизнес каждый день участвует в борьбе за пользователей. В высококонкурентной среде во главу угла ставится скорость реализации бизнес-идей. Если выпуск новых фич затягивается, то вы можете потерять своих клиентов — самое ценное, что есть у любого бизнеса.
* В нашем процессе слабым звеном было тестирование, которое затягивало время прохода задачи на прод от нескольких недель до нескольких месяцев.
* За последние полгода мы автоматизировали, изменяли приемочное тестирование, отменили ручное тестирование на промежуточных этапах выливки задачи и отказались от тестирования того, что не имеет ценности для бизнеса.
* В результате нам удалось увеличить среднюю скорость прохода задачи с 65 до 19 дней и определить направления для дальнейшего ускорения без потерь для бизнеса.

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

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

Популярные реализации cdc-тестирования создают дополнительные проблемы программистам: трата времени на описание контрактов взаимодействия, неактуальность этих контрактов, собственный DSL.

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

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

Unit-тестирование — это замечательно, но его одного часто недостаточно. Часто хочется дополнительно убедиться, что запущенное предложение будет работать. На помощь приходит интеграционное тестирование.

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

Облачные сервисы для баз данных (Amazon RDS, Google Cloud SQL) уже автоматизируют существенную часть DBA-задач: разворачивание и базовую настройку новой БД, добавление реплик, создание бэкапов, автоматический failover. Но, в то же время, задачи, связанные с тонким тюнингом, контролем производительности и её оптимизацией, в данный момент не то, что не автоматизированы, но и требуют глубоких знаний «потрохов» конкретной СУБД и множества повторяющихся ручных действий.

Этот доклад будет состоять из двух частей. В первой я представлю новый проект с открытым исходным кодом — "postgres_dba" (https://github.com/NikolayS/postgres_dba). Это набор инструментов для Postgres, обеспечивающий полуавтоматическую диагностику узких мест производительности БД, не требующий глубоких знаний реализации Постгреса.

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

Пройдя по следующим пунктам, вы сможете построить Continuous Database Administration pipeline в своём проекте из доступных компонентов:
- почему сейчас так непросто находить узкие места производительности Postgres, если вы не являетесь экспертом;
- какие конкретно действия делают эксперты, осуществляя поиск узких мест и соответствующих решений;
- как эти действия можно и нужно автоматизировать;
- проведение автоматизированных экспериментов в облаках;
- доступные на данный момент opensource-компоненты для построения Continuous Database Administration pipeline: pg_stat_statements, pg_stat_kcache, auto_explain, pgBadger, pgreplay, docker, patroni.

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

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

Мы разрабатываем платформу IPTV/OTT-телевидения. У платформы около 10 миллионов пользователей.

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

Существующие решения, такие как Elastic Search или Tarantool, нам не подошли либо по функциональным возможностям, либо по производительности.

В результате мы создали и опубликовали в Open Source новую in-memory БД - Reindexer, которая по поисковому функционалу не уступает Elastic или MongoDB, а по скорости работы превосходит их в разы, а иногда и на порядки.

Я расскажу о том, что "умеет" Reindexer, покажу примеры использования в проектах и, конечно, в докладе будет сравнение производительности с существующими на рынке БД.

MySQL 8.0 - это новая версия СУБД MySQL, которая недавно объявлена стабильной. Одними из интересных возможностей MySQL, которые доступны, начиная с этой версии, являются обобщенные табличные выражения (Common Table Expressions) и оконные функции.

Данный доклад расскажет о том:
- Что такое обобщенные табличные выражения?
- В чем разница между нерекурсивными и рекурсивными выражениями?
- Как можно использовать рекурсивные выражения для работы с иерархическими данными?
- Зачем еще могут пригодиться нерекурсивные и рекурсивные табличные выражения?
- Каким именно образом в MySQL реализована поддержка табличных выражений, и что стоит иметь в виду при их использовании.

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

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

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

Этот доклад не будет наполнен внутренней технической информацией, интересной только для DBA, он целиком ориентирован на разработчиков backend-систем, так как они самые главные пользователи баз данных. И именно им придется иметь дело с DBA и DevOps, чтобы устранить возникшие проблемы в связке БД - приложение.

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

В докладе расскажем об особенностях lambda-архитектур, платформе микросервисов Amazon Lambda, а также подводных камнях и победах с Node.JS и многопоточной Java. Затронем тему эффективной разработки и тестирования надежного и устойчивого многопоточного кода. Поделимся опытом организации промежуточного дифференциального хранилища и непростым выбором между LMDB (lightning memory-mapped database), LevelDB (используется в Bitcoin blockchain), Apache Derby и Berkeley DB. Подробно расскажем о тонкостях использования инфраструктуры очередей на базе Amazon SQS, NoSQL в DynamoDB и мониторинге системы для предотвращения потерь данных клиентов и минимизации рисков последствий отказов и аварий дата-центров.

Несмотря на то, что данных сейчас много почти везде, аналитические БД все еще довольно экзотичны. Их плохо знают и еще хуже умеют эффективно использовать. Многие продолжают "есть кактус" с MySQL или PostgreSQL, которые спроектированы под другие сценарии, мучиться с NoSQL или переплачивать за коммерческие решения. ClickHouse меняет правила игры и значительно снижает порог вхождения в мир аналитических DBMS.

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

Конкурентный доступ к данным является одним из основных преимуществ современных реляционных СУБД. С точки зрения пользователя всё происходит легко и просто. Очевидно, что внутри всё становится несколько сложнее и СУБД проделывает существенный объем работы для обеспечения удобства.

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

Эта тема будет, безусловно, полезна всем, кто администрирует базы данных. Разработчики также смогут почерпнуть для себя много полезной информации, т.к. я постараюсь объяснить почему ДБА “хотят странного” от разработчиков.

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

Расскажу про базовые канонические подходы к снаряду, про ряд опробованных за 15+ лет регулярного написания хэшей вручную ловких трюков, возможно, успеем немного поговорить про связанные штуки типа блокчейна (trollface) или там какого DHT.

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

Я расскажу, что такое корутины, и в чем отличие stackful и stackless.
Далее мы опустимся в недра исходного кода различных библиотек (libcoro, libtask и protothreads), чтобы понять, какими способами можно создать корутины на низком уровне.

Интернет, к которому мы привыкли, обречён.

На том, что принято называть Internet protocol suite, не осталось живого места. Протокол IP уже вовсе не тот, что раньше, HTTP тоже сменил версию, замена TCP активно готовится, а SSL вообще больше не существует. Эту ползучую революцию в сообществе принято встречать с энтузиазмом, в крайнем случае - со сдержанным оптимизмом.

Автор общается с идеологами этой революции и, как обычно, придерживается мнения, что у всего без исключения есть как достоинства, так и недостатки. В докладе предлагается перемыть косточки IPv6, QUIC, DNS-over-HTTPS, TLS v1.3 и HTTP/2, включая их историю, особенности дизайна и известные нюансы внедрения; политические моменты разработки протоколов нового поколения и психологию толпы инженеров.

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

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

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

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

Распознаванием лиц сейчас никого не удивишь, если у вас не:
- 330 миллионов пользовательских аккаунтов;
- ежедневно заливается 20 млн пользовательских фотографий;
- максимальное время на обработку одного фото не должно превышать 0.2 сек (забегая вперед, скажу, что нам удалось сделать это быстрее);
- ограниченные объемы оборудования для решения задачи.

В докладе будут рассмотрены:
- pipeline для: построения векторов пользователей и поиска пользователя на загруженном фото;
- обучение нейросети: построение dataset'а > обучение нейросети > построение датасета > варить до готовности;
- детектор лиц на каскаде нейросетей и его оптимизация;
- построение нормализованного вектора пользователя на GPU;
- железо и оптимизации, запуск в облаке, отказоустойчивость.

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

В докладе я поделюсь накопленным за последний год опытом и отвечу на следующие вопросы:
* В какой момент микросервисы становятся тем же монолитом и наносят ответный удар?
* Где найти ответственных, когда у тебя 30+ сервисов в ecom-платформе “общаются” с 60+ другими внутренними системами?
* Что ни в коем случае не стоит делить на микросервисы?

В Badoo так сложилось, что разработчик несет ответственность за те фичи, которые он "приручил".

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

- Не спамом единым или ситуация с рассылкой почты в 2018 году. Сколько можно терпеть "современные" MTA?
- Гарантия доставки, прелести SMTP, обход ограничений почтовых служб, жонглирование IP-адресами и прогрев серверов – поговорим об архитектуре.
- Почему мы выбрали Elixir, как нам это помогло, и где мы наступили на грабли.
- ТТХ полученного решения и сравнение с другими подходами.

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

Популярный веб-сервер nginx вы уже наверняка знаете. В этом докладе мы расскажем про другие проекты, которые мы разрабатываем в России, США, Англии и Ирландии. Вместе эти проекты составляют платформу для запуска, масштабирования и доставки приложений.

По порядку:

* Crossplane (5 минут). Часто случается необходимость понимать и разбирать конфигурацию NGINX. Эта библиотека занимается парсингом конфига и составлением из него JSON-объекта. Она специально разработана как отдельный продукт и используется внутри Amplify и Controller. Разрабатывается в Сан-Франциско.

* Amplify (5 минут). Система мониторинга для различных инсталляций NGINX и сопутствующего ПО. Умеет работать с любыми конфигурациями, разбирается в настройках NGINX и, кроме красивых графиков и аналитики, умеет подсказывать, как улучшить ваш конфиг. Разрабатывается в Москве и Сан-Франциско.

* njs (10 минут). Проект по внедрению JavaScript в конфигурацию веб-сервера nginx. Изначально разработан Игорем Сысоевым, сейчас поддерживается командой в Москве. Сделан как отдельный модуль и используется для создания сложной логики запроса и ответа. Мы покажем примеры использования и преимущества njs перед известными скриптовыми альтернативами - Lua, Perl.

* Unit (10 минут). Динамический сервер нового поколения, поддерживающий запуск приложений на разных языках и управление ими через удобный REST API. Unit разрабатывает непосредственно Игорь Сысоев в Москве.

* Kubernetes Ingress Controller (5 минут). Плагин, позволяющий использовать NGINX в качестве прокси и балансировщика нагрузки в Kubernetes. Существует два разных проекта с похожими задачами, но с несколько разным функционалом. Мы рассмотрим Ingress Controller, который делает сообщество kubernetes, и нашу собственную разработку. Наш Ingress Controller разрабатывается в Кембридже, Великобритания.

* nginMesh (10 минут). Проект по использованию NGINX в качестве сервисного прокси в Istio Service Mesh. Данный подход - Service Mesh - это новый баззворд 2017-2018 года. Istio, Service Mesh от Google, занимается управлением трафиком между большим количеством сервисов и поддерживает широкий набор плагинов и модулей. Проект nginMesh разрабатывается нашими инженерами в городе Саннивейл, Калифорния.

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

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

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

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

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

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

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

Мы рассмотрим типовые структуры базы данных для tagging search и проведем оценку достоинств и недостатков каждой структуры, далее проведем сравнение со специализированным функционалом на базе серверов полнотекстового поиска на примере Apache Solr. Замеры производительности будут производиться на основе базы данных тегов из StackOverflow за 5 лет.

Мы посмотрим как решения для tagging search можно использовать для faceted navigation и какие могут возникнуть подводные камни.

Наконец, будет рассмотрена текущая архитектура решения tagging search в крупном enterprise-проекте с 10000 тысячами запросов в секунду и 1000 пользователей, работающих одновременно, проблемы данного решения, и как мы собираемся решать их в будущем.

IPIP.net is the first and only Geo-IP database company based on real time BGP/ASN data computing. We'll share how we make Geo-IP data accurate and use cases in different industries.

The untold truth is there is no standard of Geo-IP location. Enterprises, carriers and data centers are more centralized, and end/mobile users are widely distributed and moving frequently which significantly increase the complexity of Geo-IP accuracy.

IPIP.net will introduce the way how we make our Geo-IP DB accurate including:
1. Global monitoring platform and how it works;
2. Data inaccuracy triggering and fixing;
3. Global WHOIS / BGP / ASN / RADB reference;
4. Global Internet Exchange DB;
5. IPIP.net rDNS and backbone IP db;
6. Cooperation between ISPs, clients, partners and community.

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

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

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

Основные проблемы, которые мы решили:
- Ускорили процесс разработки.
- Уменьшили время ручного тестирования и автотестов.
- Стали внедрять все больше новых технологий, так как смогли быстро обкатывать их в реальных проектах.
- Увеличили читабельность кода, каждый сервис получился достаточно простым и сделанным по определенному шаблону.
- Тот код, что мы пишем на фронте, полностью смогли использовать в наших Android и iOS.
- Имеем возможность быстро с нуля переписать проект.
- Значительно уменьшили порог входа в проект.

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

Прогрессивные веб-приложения становятся все популярнее. А современные возможности браузера поражают.

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

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

The primary subject is CSS Fonts 4, which primarily deals with how to use Variable Fonts on the Web, and restyling Color Fonts. That specification has changed a lot in the last few months, and continues to do so; I am actively involved in developing that specification, and I will be explaining the latest changes.

70% of websites use downloadable fonts now, at least at a basic level. But with CSS Fonts 4 support for OpenType Variable Fonts — a single font file that behaves like multiple fonts, or even an infinity of morphing fonts — and for restyling the palette of Color Fonts, the capabilities opening up for typography on the web are extraordinary. In this session, Chris Lilley explains the most recent, cutting-edge developments and also recaps OpenType font features from CSS Fonts 3, to further improve typography with CSS. Learn what's possible today, and in the near future.

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

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

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

Первая мысль - давайте перепишем приложение на Elm!
Первый вопрос - а что это такое?
Первое сомнение - а возможно ли переписать приложение не сразу, а по "кусочкам"?

Elm - это не фреймворк. Elm - это язык, который компилируется в JavaScript. За 40 минут я расскажу вам, что именно у нас тормозило, что не устраивало в архитектуре, какие решения мы пробовали, и они нам не понравились (спойлер: React, TS, Vanilla.js, coffeescript) и как, наконец-таки, мы переписываем наше приложение по частям на Elm и планируем в будущем оставить только его в приложении (долой AngluarJS!).

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

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

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

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

В своем докладе расскажу об опыте миграции нашего большого и сложного приложения с Backbone (и иже с ним jQuery/underscore) на Vue. Как мы смогли это осуществить, с какими проблемами сталкивались и почему нам это удалось без вреда для бизнеса (а даже наоборот). Доклад будет интересен всем без исключения разработчикам, а не только ценителям jQuery и Vue.

Кажется, что разработчикам очень нравится Vue, но мало кто решается использовать его на большом проекте.
Чего боятся разработчики, пожелав выбрать Vue в крупной разработке?

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

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

Как использовать изоморфность для написания абсолютно любых веб-приложений - от простых сайтов до сложных SPA. Что делать, если нужно, чтобы веб-приложение загружало мегабайтные бандлы без ущерба для скорости загрузки и индексировалось поисковиками. Как сделать полноценный Progressive Enhancement, чтобы даже юзеры с выключенным JS могли использовать ваше сверхсовременное веб-приложение. Как при правильном подходе добиться 100% общего кода в любом окружении. А также другие интересные кейсы.

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

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

Сегодня многие клиенты хотят получить персонализированную библиотеку элементов, созданную под их стиль. Мы разберемся с тем, какие плюсы и минусы есть у разных решений, и, вообще, всегда ли стоит создавать библиотеку элементов или в некоторых случаях это бесполезно? Разберем принципы, нюансы и подводные камни, а также раскроем следующие темы:
1) Кому и зачем нужны библиотеки элементов;
2) Частые требования к реализации;
2) Как грамотно реализовать репозиторий под библиотеку;
3) Компоненты: правильная верстка - это еще не всё;
4) Настраиваем сборщик: меньше действий, больше удобства;
5) NPM-пакеты на практике;
6) Документация - это важно!

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

Тесты, тесты, кругом тесты. Этот доклад снова про тесты. Но не про привычные нам юниты, а про е2е.

Мы рассмотрим, что же за зверь такой эти "е2е-тесты". Как правильно их писать, что такое PageObject pattern, какие инструменты нам для этого доступны, и какие выбрали мы.

Также поговорим про BDD-подход в тестировании. Разберем cucumberjs как инструмент для использования BDD и посмотрим, как его использовать для написания тестов.

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

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

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

Многие годы являясь ярым поклонником текстового редактора Sublime Text, я провела небольшой эксперимент, в ходе которого пользовалась несколькими популярными редакторами и IDE (Atom, Visual Studio Code и Web Storm), и хочу поделиться своими впечатлениями от работы в каждом из них. Я сравню их функциональные возможности, расскажу об их особенностях для различных проектов и технологий, кратко коснусь производительности этих редакторов для больших и сложных проектов. А в конце я подведу итог, чем же простые текстовые редакторы могут быть лучше интегрированных сред разработки.

Войны о необходимости статической типизации в мире JavaScript не утихают ни на минуту. Автор и сам регулярно выступает с одной из баррикад, распекая TypeScript за их слабый вывод типов, Flow - за отсутствие экосистемы, а обычный JS - за то, что он еще существует. Но что, если отставить вопросы веры и задаться простым вопросом - а позволяют ли типы работать продуктивнее? Существующее исследования говорят, что нет. Интуиция и личный опыт автора - что да.

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

Удаление неиспользуемого CSS-кода – одна из задач Frontend-оптимизации на сайте Booking.com. Суммарно по всем пользовательским сценариям и их вариациям – на сайте более 50K различных CSS-селекторов. Определить, какие из них актуальные, просто проанализировав кодовую базу – невозможно. А ввиду большого количества сценариев/вариаций (более 2000) с возможными динамическими изменениями страницы невозможен и вариант ручного тестирования.

Мы получили code coverage CSS-кода, используя crowd source-подход. Я расскажу, на чем основан выбор такого подхода, и как при его использовании мы минимизировали негативное воздействие на пользовательский опыт (а в некоторых случаях и избежали).

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

В качестве результата от такой работы можно видеть улучшение времени на Critical Rendering Path. А также повышение velocity нашей команды разработчиков.

У нас в Uploadcare основной сайт — монолит на Django. Разрабатывать клиентскую часть в экосистеме монолита было неэффективно, и мы приняли волевое решение сделать отдельное приложение для фронтенда на Node.js.

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

Спойлер: всё получилось хорошо, бэкендеры и фронтендеры счастливы!

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

В докладе поговорим о том, что такое RUM (real user monitoring), и как он может помочь современному веб-разработчику делать свою работу лучше, а именно:
- какие метрики измерять и мониторить;
- что нужно знать про агрегацию собранных данных;
- какие инструменты могут со всем этим помочь.

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

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

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

Backbone, Knockout, Ember, React, Angular, Vue — количество фронтенд-фреймворков растёт каждый день. Но задумывались ли мы когда-либо над тем, что всё это время двигало вперёд их развитие?

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

Более того, эти проблемы специфичны не только для фронтенда и уходят корнями в эпоху становления computer science — 80-90-e годы прошлого века. В докладе вы узнаете, как вопросы реализации FRP и различных видов DSL связаны с тем, как сейчас устроены фреймворки и со способами оптимизации их работы.

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

Приложения на стеке React-Redux стали уже одним из стандартов в современной фронтенд-разработке. Вместе с Redux в проектах используют redux-thunk, redux-saga или какой-нибудь другой похожий инструмент. Они позволяют общаться с API, обрабатывать сложные случаи. Эти решения объединяет то, что они все — middleware с определенным форматом. Middleware в Redux — это очень мощный инструмент, который позволяет решать любые задачи по построению бизнес-логики, разделить уровни MVC.

Мы поговорим о том, как кастомные middleware упрощают нашу жизнь в различных случаях и заменяют redux-thunk, sagas.

Загрузка, кэширование и обработка данных усложняет работу с состоянием приложения. Такие библиотеки, как Redux/MobX, помогают решить эту проблему, особенно, если вы работаете с REST API. Но что, если мы будем использовать GraphQL для общения с сервером? Нужны ли будут нам эти библиотеки, и какие мы преимущества от этого получим?

В докладе я расскажу о том, как можно контролировать сложность React-компонентов и повторно использовать логику с помощью компонентов высшего порядка (HOCs).

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

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

Делаем open-source проект интуитивно привычным для разработчиков.

В частности, вы узнаете:
- Что обозначают все эти бейджи на проектах.
- Что такое code style и какой из них выбрать (standard, airnbnb и т.п.).
- Что такое code climate.
- License- and Contribution-файлы.
- Gitignore and npmignore.
- Продвижение проекта (как бесполезный компонент набрал больше 100 звёзд, и почему полезный плагин не набрал даже 30).

До того, как написанный нами код будет исполнен, он проходит довольно долгий путь. Мы рассмотрим каждый шаг на этом пути на примере движка V8 и поймём, что даёт нам понимание того, что происходит с кодом.

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

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

CSS Secrets was a series of talks that were loved by audiences all around the globe and led to Lea's bestselling book “CSS Secrets”. The premise is simple: Ten surprising yet practical things you didn't know you could do in CSS, live-coded in Lea's trademark interactive presentation style. This third installment of the series will include new juicy secrets related to CSS Variables, grid layout, variable fonts, among other things. Prepare to be inspired again as Lea debuts ten all-new feats of advanced CSS wizardry, which will help you understand CSS at a much deeper level.

Знакомый js, инструменты и многое другое сделали Nodejs популярной платформой для разработки.

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

В докладе расскажу про архитектуру, событийный цикл, I/O, как работает загрузчик модулей и что происходит, когда выполняется js-код. Разбираемся с устройством платформы Nodejs.

Начать стоит с того, что было:
5 разных UI-китов, около 400 сайтов на shared-хостингах, битрикс, спагетти-код на jquery.

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

Мы выбрали написание собственного самоката, с оглядкой на существующие фреймворки. Спустя год нам удалось перевести 2 из 5 китов на новые рельсы, выкатить новый дизайн на 150 сайтах, выработать подход по работе с компонентами, научить бэкендеров БЭМ-у, попробовать рендерить pug на node.js через битрикс (!), развернуть свой npm-сервер и систему сборки и деплоя.

У javascript насквозь асинхронная природа, но при этом один поток - как же так? Как пользоваться асинхронностью и не выстрелить себе в ногу?

Мы рассмотрим, что такое event loop, и с чем его едят, поглядим, чем таски отличаются от микротасок, как браузеры управляют приоритетами задач, и что говорит на этот счет спецификация. Также узнаем, в чем отличия в работе event loop в Node.js, и проведем параллели с браузерами.

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

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

Мы потратили больше 100 часов на обсуждения, эксперименты и код. Если у вас есть похожая задача, вы сможете их сэкономить.

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

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

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

- Как работает транспиляция.
- Как написать свой плагин.
- Простой пример: assert'ы.
- Транспиляция ES2015-модулей в свою модульную систему.
- Автоматические понифилы при использовании TypeScript.

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

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

Разберемся, в каком состоянии сейчас CSS, что именно он может заменить от препроцессоров и ответим на главный вопрос — готов ли CSS заменить препроцессоры.

Headless-браузеры уже давно стали незаменимым инструментом разработчиков. С их помощью можно проводить тестирование кода, проверять качество и соответствие верстки и другое. Но проблема в том, что разработчики мало знают про то, как устроен и работает их инструмент. Расскажу про Headless Chrome, его компоненты, их устройство. Покажу интересные сценарии использования Headless Chrome. Вторая часть будет про Puppeteer - удобную Node.js-библиотеку для управления Headless-режимом в Google Chrome и Chromium.

В докладе попытаюсь сравнить архитектуру и технические решения, используемые в современных SQL- и NoSQL-системах, в частности, Couchbase, MongoDB, Cassandra, CockroachDB и, конечно, Tarantool.

Как разбиваются данные - по диапазону, хэш-функции или bucket id? Как выбирается размер бакета? Какая хэш-функция используется? Как происходит перебалансировка при переполнении? Где хранится информация о распределении данных и их текущим местоположении? Есть ли выделенный программный компонент для роутинга запросов, или роутинг осуществляется самими узлами хранения? Ответы на эти вопросы, а также на вопрос, почему разработчики приняли то или иное решение, плюсы и минусы различных подходов я раскрою в своём докладе.

P.S. Несколько лет назад мы с Алексеем Рыбаком делали совместный доклад про шардинг с использованием MySQL или PostgreSQL. Видео и слайды доклада можно найти здесь: https://www.youtube.com/watch?v=MhGO7BBqSBU&t=2317s
https://habrahabr.ru/company/oleg-bunin/blog/313366/

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

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

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

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

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

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

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

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

Также я расскажу о 2-3 внедрениях:
- минимально необходимый комплект метрик, собираемых с VM и мастер-серверов;
- инструменты для сбора метрик и хранения их;
- какие трудности возникали при внедрениях;
- как различные дополнительные требования могут влиять на результаты оптимизации размещения VM;
и дам практические советы по внедрению подобного ПО.

Адепты DevOps утверждают, что этот подход применим только для больших команд, работающих со сложными проектами, желательно без UI. Мобильные приложение, вроде как, поменьше, команды всего по 3-5 человек на платформу, чистого Ops почти нет, однако проблем в проектах меньше от этого не становится. На помощь приходит Mobile DevOps!

Что такое Mobile DevOps? Очередная маркетинговая химера или реально полезный набор практик, которые могут упростить и ускорить процесс разработки мобильных приложений?

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

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

Речь пойдет про iOS/Android без привязки к технологическому стеку: Objective C/Swift для iOS; Java/Kotlin для Android; ReactNative для iOS/Android; Xamarin для iOS/Android; Cordova для iOS/Android. В довесок немного рассмотрим, кто и что есть на рынке Mobile DevOps.

Continuous Integration — важная часть современного процесса разработки. Сборка на каждый коммит, интеграционные тесты, деплой каждого коммита в продакшн, фиче-флаги — выглядит как идеальный пайплайн? Однако чаще всего разработка приложения не ограничивается написанием кода и запуском тестов.

Я расскажу о том, как и зачем внедрить в CI процессы разработки, которые там обычно не представлены: написание документации, обновление зависимостей, аудиты безопасности, capacity management и даже дизайн интерфейсов. Сравню возможности, которые предоставляют для этого популярные CI-серверы, разобью пайплайны на самые базовые составляющие и расскажу, чем TeamCity принципиально отличается от Concourse.

Команды с работающим процессом Continuous Deployment получат из доклада информацию к размышлению о том, каких процессов не хватает в их существующих пайплайнах, а разработчики, только планирующие внедрять CI — критерии для выбора наиболее подходящего для них сервера интеграции.

Многие команды до сих пор мучительно выкатывают 1-2 релиза в неделю. Часто с остановкой сервиса. А потом ещё неделю исправляют ошибки.

Я расскажу, как мы в DocDoc прошли путь от 1 релиза в неделю до 30 релизов в день. Зачем мы это сделали, сколько это стоит, и самое главное: как это работает.

В 2018 году людей трудно удивить самим фактом наличия худо-бедно работающего CI/CD, благо, что всевозможных технических средств реализовать его сейчас хватает: SCM, контейнеры, всевозможная оркестрация и т.д.

Однако все становится интересней, когда приходят какие-нибудь скептично настроенные люди (аудиторы, безопасники, просто какое-нибудь начальство) и начинают задавать неудобные вопросы: а насколько это у вас автоматизировано? а кто может деплоить? а как это все логируется? а что вы будете делать, когда все сломается?

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

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

С переходом на Kubernetes появляется возможность очень быстро и просто создавать новые сервисы, поэтому их количество начинает расти «как на дрожжах». Вместе с ними увеличивается и число окружений, из-за чего даже в небольшом проекте с десятком сервисов мы очень быстро оказываемся в ситуации, что в кластере уже 50 namespace’ов и 500 pod’ов. Что все они делают? Как понять, что все работает хорошо?

Я поделюсь обширным опытом настройки мониторинга, полученным в результате эксплуатации 21 проекта на Kubernetes (в production), в состав которых входят более 200 различных приложений, написанных на 8 языках программирования.

В частности, в докладе будут даны ответы на следующие вопросы:
* Что именно в Kubernetes нужно мониторить (кроме состояния pod’ов и результатов выполнения job’ов)?
* Какие компоненты самого Kubernetes стоит мониторить и на что стоит обращать внимание?
* Какова специфика мониторинга Ingress Nginx?
* Как мониторить инфраструктурные компоненты (Redis, RabbitMQ, MongoDB и т.п.)?
* Почему мы используем именно Prometheus, и какие вопросы он решает?
* Как правильно интегрировать Prometheus с Kubernetes (и сделать Service Discovery всех метрик)?
* Как сделать удобные дашборды в Grafana?
* Как отделить разные окружения, чтобы получать только нужные алерты?
* Как видеть тренды на больших периодах и оптимизировать затраты на инфраструктуру мониторинга?

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

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

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

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

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

В последнее время во все сферы разработки ПО все больше проникает концепция "Everything as a Code" - CI (Jenkins pipeline), инфраструктура (Ansible playbooks), тестирование (сценарии Cucumber и Spock), документация (AsciiDoc(tor)) и многое другое. Весь этот код, наряду с основным кодом разрабатываемого приложения, так же находится под управлением системы контроля версий, собирается на билд-серверах, участвует в автотестах.

В докладе я могу рассказать, как этот подход применим к разработке и сопровождению БД, и что под эту схему подходят не только старые-добрые инкрементальные миграции (liquibase, flyway), а также исходный код объектов (baseline), код манипуляции объектами и самим сервером(инстансом) БД.

Еще расскажу о своем opensource-проекте, в котором я пытаюсь воплотить некоторые описываемые идеи.

Наши сервера - в основном Windows и немного Linux’ов.
Наше приложение - 160 проектов на C#, которые собираются в ~30 разных сайтов.

Год назад весь процесс деплоя представлял 150 шагов в TeamCity. И требовал даунтайма. Теперь у нас есть деплой-скрипт, который позволяет деплоиться быстрее, выше, сильнее, но всё ещё требует разработки и поддержки.

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

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

Идеи continuous delivery можно применять не только к процессу разработки приложений, но и к управлению инфраструктурой.

Я расскажу:
- как управлять виртуальными машинами так же, как и кодом продуктов - с компиляцией, тестированием, публикацией артефактов и релизами;
- как HashiCorp Packer помогает создавать машины и настраивать софт;
- чем immutable infrastructure отличается от классического configuration management с Ansible/Chef/Puppet;
- какие сложности возникают, когда машин становится сотни, а параллельных сборок - десятки. И как TeamCity помогает нам с ними справляться;
- как мы привлекаем разработчиков к администрированию инфраструктуры и внедряем DevOps-культуру.

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

А что же с коробочными продуктами? Они с их релизами раз в полгода в стороне?

Мы не в стороне. Несмотря на релизы раз в месяц, у нас в Эрливидео внедрены полезные практики:
1) жесткое правило на отгружаемость мастер-ветки;
2) сборка в пакет каждого коммита;
3) регулярный прогон тестов;
4) методика ежедневной установки мастера клиентам.

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

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

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

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

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

Такой подход позволяет сократить количество сюрпризов для наших клиентов и багов для нас.

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

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

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

В докладе я расскажу, как выглядит World of Tanks Server (кластер кластеров) со всеми веб-сервисами, которые существуют вокруг. Какие узкие места с точки зрения отказоустойчивости есть внутри кластера, между кластерами, во взаимодействии с внешними веб-сервисами. Как мы решаем возникающие проблемы технически, процессно, проектно.

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

Я расскажу о не очень популярных (пока) аспектах балансировки нагрузки:
- политика повторных попыток (retries);
- таймауты: connect/read/write/request timeout, tcp keep-alive* (чем они отличаются, как выбрать конкретные значения для своего сервиса);
- backoff, circuit breaker: как не убить нижележащие серверы в момент аварии/перегрузки;
- health checks: нужны ли они, достаточно ли их, что сервис должен проверять, прежде чем отдать HTTP-200;
- outlier detection в балансировке: способ работать при более сложных (плавающих) поломках нижележащих серверов.

В плане технологий: сначала мы мельком рассмотрим nginx, haproxy (а так же haproxy за nginx:), потом расскажу про наш опыт работы с envoy и балансировке внутри приложения (будет немного примеров на golang).

Весной 2018 года к нам обратилась крупная производственная компания, которая попросила нас провести R&D-проект, в рамках которого мы попытались бы опробовать современные технологии контейнеризации, Continous Integration и понять, какие из них применимы для создания платформы приложений и обработки данных.

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

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

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

Используемые технологии:
k8s, consul, openstack, kafka, flink, cassandra, tarantool, ignite, mesos, marathon, grafana, gitlab, jenkins, zipkin, prometheus

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

Сложности с разворачиванием кластера из множества серверных нод ложится на матёрых системных админов или «поручается» публичным облачным провайдерам. Локальная разработка основывается на minikube или kubetbetes in docker. А все это приводит к тому, что порой задаешься вопросом: «Как и почему это работает?», и так необходимые базовые сетевые понятия никому не знакомы.

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

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

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

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

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

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

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

В докладе я расскажу про основные метрики оценки эффективности бизнеса, которые мы использовали на разных этапах развития нашей компании. Объясню, почему наша отчетность в 1 год жизни компании умещалась на 10 строчках, а теперь занимает 10 листов Excel. Расскажу, какие особенности подсчета метрик мы учитываем, так как продаем SaaS-решение. На что мы обращаем внимание при оценке основных показателей для разных моделей продаж - прямых и через партнеров.

1. Компания находится в точке невозврата. Разрыв между лидерами рынка и точкой Х – «одна промышленная революция». Продолжая дальше бизнес в устоявшихся традициях, мы идем под уклон.
Пока медленно. Но скорость возрастает с удешевлением и распространением цифровых практик в РФ.
Как преодолеть разрыв без революций и тотальных вложений? Какие препятствия возникают на пути форсированной эволюции?

2. Внутренняя причина №1
Правильный состав своих кадров и наличие у них навыков, необходимых для будущего процветания в цифровой компании. Сейчас команды из прошлого. С обозами.
Ключевые решения: партнерство с HR в стандартизации процессов, массированное развитие внутреннего тренерства, партнерство с PR в массированной продаже идей, бизнес развитие ИТ-команды и "внешние пророки", сегментирование по XYZ-признаку разные ценности.

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

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

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

Например, мы решили повысить конверсию сайта, с помощью которого мы привлекаем клиентов.

Для этого мы выбрали решение: новый сайт с новой структурой навигации для более эффективной конверсии. После инициации проекта у команды в голове цель подменилась с “нам нужно увеличить конверсию сайта” на “нам нужно сделать сайт согласно ТЗ с заданным качеством в заданные сроки”. Чем длиннее проект, тем больше шансов на такое развитие ситуации, если не задумываться об этом специально.

Чем это плохо? По идее, ну сделаем сайт качественно и достигнем исходной цели. Да, все так. С одним НО. В процессе реализации проекта возникает множество мелких вопросов и, если на эти вопросы отвечать в контексте другой цели, можно довольно сильно отклониться от оптимальной траектории. Например, в контексте достижения цели “нам нужно увеличить конверсию” можно прийти к выводу, что call to action на какой-то конкретной странице может быть разным (нужны эксперименты), и нужно заложить возможность относительно дешевых экспериментов, в контексте же достижения цели “нам нужно сделать сайт согласно ТЗ” такой вопрос даже не будет задан.

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

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

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

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

Большинство стартапов закрываются через 3-4 года. И не потому, что не справились с программированием, управлением или масштабированием.

Чаще всего проблема в компасе. Куда вы идете? Какая у вас стратегия? Почему вас должны хотеть инвесторы и большие компании?

Поговорим о стратегии для компании и вашем месте в пищевой цепи.

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

Смысловой единицей становится не страница сайта и не абзац, а микротекст — одно или несколько предложений. Это требует пересмотреть отношение к текстам, производству контента и роли копирайтера в проекте.

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

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

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

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

1. Анализ данных и формулировка гипотез.
2. Визуализация дашборда.
3. Проверка гипотез.
4. Упаковка продукта.

Не зря есть выражение “стрелять из пушки по воробьям”. В IT это применимо как нельзя кстати: мы любим писать новые фреймворки на ровном месте, автоматизировать всё подряд и использовать супермощное железо. А что насчёт людей? Как мы выбираем, кто будет делать новую задачу, и делаем ли это правильно? Особенно это важно, когда задач, как обычно, больше, чем людей.

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

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

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

25 мая 2017 года. Очередное падение системы, 4 часа она лежала, поднималась минут на 10 и снова падала. И это на "Последний звонок". Потеряли кучу клиентов. Проблемы со стабильностью, команда инфраструктуры была загружена на 200%, QA толком не было, разработка велась по компонентам, часто не соответствуя приоритетам бизнеса.

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

При этом:
* Надо отдавать техдолг, накопившийся за годы и угрожающий стабильности. По расчетам в августе-сентябре падения стали бы просто ежедневными.
* Повысить качество, ибо не получалось выпустить и 3-х релизов подряд без серьезных сбоев.
* Продолжать разработку и выпускать новые большие фичи, мобильное приложение, запуск кастомизации в США и научиться грамотно управлять приоритетами.
* Растить команду количественно и качественно, иначе не видать нам международных рынков.

В начале 2018-го мы стабильны, у нас фичакоманды, проблемы при релизах стали нонсенсом, мы деплоим в любое время без остановки, идем в .NET Core в линукс-среду, IT-команда выросла в 2 раза.

Это рассказ о том, как мы умудрялись меняться одновременно по всем фронтам.

1. Как понять объем и привлекательность рынка?
2. Как определить, кто ваши конкуренты?
3. Из каких источников надо собирать информацию и как ее читать?
4. Кто ваша аудитория и чего она хочет?
5. Как сегментировать покупателей и бить точно в цель.
6. На десерт: 4 инструмента продвижения, которые может применить каждый, и они точно работают!

1. Как изменились системы продаж крупнейших вендоров: переход в клауд.
2. Эволюция IT-продукта из технологии в сервис.
3. B2B is dead. Основной принцип формирования ядер клиентских сегментов: business value и не только.
4. Упаковка IT-продукта: работающее ценностное предложение UVP.
5. Что на самом деле такое «успешная сделка» и какой KPI ставить продажам.
6. Customer Success — мировой тренд управления продажами в IT.

1. GDPR - новый общеевропейский регламент о защите персональных данных: что за зверь, и как он влияет на весь бизнес в мире - от уведомлений об утечках данных до штрафов в 20 млн евро или 4% оборота компании.
2. Какие российские компании попадают под действия GDPR?
3. Что нужно и что можно сделать ИТ-бизнесу, чтобы закон не помешал реализовывать проекты и продажи в Европе?

По данным патентных брокеров США, средняя цена сделки по покупке одного софтверного патента на 2016 год составила $235,000. Количество софтверных патентов в России измеряется тысячами и каждый год растет, а все потому, что патенты становятся инструментом конкуренции за инвестиции, маркетинга и неотъемлемым условием для выживания на развитых рынках.

В докладе будет дан краткий ликбез по патентам, ориентированный на IT-отрасль, в частности: что такое софтверный патент с примерами, что он дает, как выглядит патентная заявка и как ее правильно читать, критерии патентоспособности и распространённые заблуждения, связанные с ними. Данная часть аккумулирует всю боль вопросов от senior-менеджмента компаний, которые «разбираются в теме».

Также доклад развенчает миф о том, что софт в России не патентуется, расскажет о злоключениях наших IT-компаний в патентных джунглях США и о сделанных выводах. Для тех, у кого пока нет своего проекта, будут предложены причины участвовать в создании патентов для работодателя, которые сработали на инженерах Ingram.

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

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

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

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

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

У нас было:
- куча отделов;
- хаос в задачах;
- непонятные сроки;
- во всем виноваты заказчики / разработчики / pu-teen.

Но мы знали, что рано или поздно это надо изменить.

Чтобы изменить, надо понять. Чтобы понять, надо померить... и мы померили!

Оказалось. Чтобы производство работало как надо, достаточно просто...

1. Борьба за ресурсы монолитного ИТ-отдела компании есть бутылочное горлышко в реализации задач.
2. Когда в каждом департаменте есть свой ИТ-отдел, появляются возможности быстрого подтверждения прибыльности того или иного проекта.
3. Львиная доля времени по созданию того или иного сервиса уходит на подготовку ТЗ. Своевременное взвешивание ответственности от последствий со стороны бизнес-заказчика в ряде случаев сводит надобность ТЗ к нулю.