Расскажем и покажем решения, созданные в коллаборации психологами и 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". Это интерактивный онлайн-тренинг, цель которого заставить человека выйти из зоны комфорта и дать ему возможность попробовать побыть в "роли" синьора или тимлида на короткий период. Этот тренинг отличается от классических аналогов тем, что он полностью проходит онлайн, распределен во времени и, будучи групповым, фокусируется на индивидууме.

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

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

Но как организовать архитектуру мобильного приложения с платформенным UI и логикой на C++? Как разделить ответственность компонентов, организовать навигацию, написать кучу биндингов к Swift и Java, и при этом иметь возможность кастомизировать поведение разных платформ? Какие различия в UI iOS и Android и как с этим жить?

Ответы будут на примере развития архитектуры UI одного из наших важнейших приложений.

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

Kotlin/JVM, Kotlin/Native, Gradle, MPP - эта комбинация позволит создавать мобильные приложения, на фреймворках родных для iOS и Android, и при этом не писать весь код дважды.

Доклад акцентирован на разработке под iOS и Kotlin/Native, так как эта сторона мобильной разработки с использованием Kotlin менее известна широкой публике.

TCP был впервые имплементирован в 70-х годах и прекрасно справлялся со своей задачей в эру проводного Интернета. Но беспроводные сети отличаются переменной пропускной способностью, высоким random packet loss, сменой IP и MTU на лету и прочими вещами, которые приводят к деградации TCP-соединения. Поэтому Одноклассники и Google активно занимаются оптимизацией сетевого взаимодействия (новые алгоритмы congestion control) и, в качестве крайней меры, переводом сетевого взаимодействия с TCP на UDP.

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

Мы поговорим о сетевых стеках iOS/Android, проблемах TCP и полностью пройдем путь перевода приложения на UDP.

В докладе будут:
- проблемы беспроводных сетей и стека TCP/IP;
- перевод с TCP на UDP сетевого взаимодействия (API, images, video streaming);
- написание своих UDP-протоколов.

А также: как отменить запрос на фото в своем приложении, если это фото больше не нужно, а запрос уже ушел на сервер, что при этом произойдет с вашим TCP-соединением?

Будут раскрыты: Head-of-line blocking, forward error correction (FEC), fast retransmit vs negative ack, MTU discovery, IPMigration, packet pacer... и многое другое:
- рассмотрим особенности и +/- протокола QUIC от Google;
- напишем протокол, ориентированный на беспроводные сети Wi-Fi и 2/3/4G.

Все будет рассказано на примере OKLive — первого Android-приложения для мобильного стриминга в качестве 1080p и основного клиента Одноклассников.

Пример для тех, кто дочитал ;)
У вас есть приложение — аналог Инстаграм. Открывая приложение, пользователь видит ленту из первых 3 фото на экране ;)
Вам надо как можно быстрее отобразить фото в плохой сети (как Wi-Fi на некоторых конференциях).
RTT 200 мс, фото 200 кб, сеть 1 Мбит/сек, packetLoss 5% (bulk loss) ;)
Варианты решения:
- скачать последовательно по TCP/HTTP1.1 без pipeline, тогда, пока выполняется следующий запрос (за RTT), канал будет простаивать;
- скачать параллельно в 3 потока по TCP/REST;
- скачать последовательно в pipeline HTTP2/TCP;
- скачать по QUIC/UDP.

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

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

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

Как выполнять 1000+ UI тестов на каждый Pull Request и не сойти с ума?

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

I truly believe that quality is not what programmers should care about. They must care only about speed—close tasks as soon as possible— which means make money. Won't this attitude ruin the project and turn the code base into a mess? Yes, it will. If the project doesn't care about its quality either. There must be a permanent conflict between a project and its programmers: 1) the project must be configured to reject anything that lowers the quality of its artifacts and 2) programmers must be interested in making changes to those artifacts. The project cares about the quality, the programmers care about fast delivery of modifications. I wrote about this: http://www.yegor256.com/2018/03/06/speed-vs-quality.html

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

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

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

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

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

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

Мы поговорим:
1. О проектировании API библиотеки: какие особенности и подводные камни могут встретиться.
2. На что обратить внимание при написании кода и тестировании.
3. Как облегчить жизнь своим пользователям и, как следствие, себе.
4. Об особенностях релизного цикла и взаимодействии с другими командами.
5. Что необходимо для публичного релиза, и какой постпродакшн ждёт разработчика библиотеки.

Рассказ будет полон неподдельными историями из жизни команды мобильной библиотеки YandexSpeechKit :)

Истории про разработку игр, от Паскаля до Свифта, от СССР до РФ, от 10 рублей до миллиона долларов. Без нравоучений, запинок и бестолковых советов.

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

Вы получите ответы на любые вопросы, кроме вышеперечисленных.

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

Ответы на эти и другие вопросы под катом.

История развития continuous integration в команде мобильной разработки Авито.

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

Технологии: Google Assistant, Alexa, Алиса, DialogFlow.

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

On the paper, everyone agrees that tests are important. And yet, more often than none, tests are still considered the poor cousin in the development industry. In the rare case when we actually take time to write them, we more often than not consider it a cumbersome task, and give it less thoughts than the "real code".

But tests are often as important, if not more, as the code that will be shipped on the Play Store. After briefly explaining the basics of testing, this talk will go through various common mistakes and bad practices found in real-life unit tests, and will give techniques and tips to make those tests cleaner and better.

Часто можно услышать фразу: «Вот, если переписать все с нуля» или «Здесь слишком много legacy-кода, мы тонем. Проще переписать все». Но что значит «переписать работающее приложение с нуля»? Как его улучшить и сделать технологичным и масштабируемым? Так ли это просто?

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

Поделимся bad-практиками с использованием RxJava, Dagger. Покажем на примерах, как unit-тесты спасали нас от непредвиденного изменения кода, и на примере app.zeplin.io расскажем, как дизайнеры помогли разработчикам интегрировать UI.

В App in the Air самописные View и ViewGroup используются и в хвост и в гриву.

На докладе я расскажу о том, что интересного можно делать с Custom View и ViewGroup, почему это может здорово помочь достижению 60 FPS, какие правила по написанию и поддержке этого кода я выработал для себя, и, в качестве бонуса, расскажу о некоторых интересных оптимизациях и о нюансах того, что лежит под капотом.

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

Methods to increase app stability, lesser crash rates, observe app behaviours using AndroidVitals.

Расскажу, что такое технологическая платформа Spotify, и как с помощью кастомных Gradle-плагинов мы лечим (делаем) головную боль других разработчиков в компании. Помимо разбора кейсов использования самописных плагинов, поговорим о практических вещах: best practices и способах публикации.

We all have heard stories about modularization, faster builds, quicker iterations and all the good things we get through it. But when it comes to actually breaking your legacy into modules, your code can give you a serious run for money. In this talk I will share how 60+ Android Devs at Booking got together to defeat the legacy and modularized the app to get 10 times faster builds. If you attend this talk you will be able to learn the best practices about modularizing your large code bases and avoid the pitfalls that we discovered in journey.

When promoting Kotlin over Java to your friend the first argument you’ll probably use will be its powerful syntax: in-house nullability support, default arguments, delegated properties, data & sealed classes, etc. These features are really the stuff we’re benefiting from everyday, but if we’ll take Java annotation processors then sadly the only information they can get about our code will be Java-related and no info about Kotlin-specifics. In this talk we’ll find out how to use Kotlin metadata added to the bytecode to get info about Kotlin-specific features in the code and utilise it during annotation processing.

- Чем single-activity лучше чем multy-activity (скорость, анимации, ЖЦ и др.);
- как можно перевести любое приложение на новый подход;
- как выстраивать DI-скоупы для оптимального использования памяти;
- как выстраивать навигацию, чтобы не сойти с ума;
- как обрабатывать deep-link'и;
- как делать общий BottomNavigationBar (и другие общие элементы);
- как делить приложение на модули;
- как обрабатывать клавиатуру и статус-бар...

...список может быть дополнен.

In this talk we are going to see the internals of the new Dexing Compiler D8, introduced in AS 3.0 as experimental, D8 will give us faster and smaller outputs of dex files. We will understand better how is the Dex Processing in Oreo/P from the ART perspective, and how is affected in the new bundle apps.
Additionally, we will see more about R8 a replacement for Proguard used in AS 3.2

При создании приложения под Android есть множество связанных продуктов Google, где наше приложение может быть интересно пользователю. Мы обсудим интеграцию пуш-уведомлений в приложение, интерактивную поисковую выдачу в лаунчере, ассистенте и меню "Share", свои экшны в контактной книге, обработку основных системных интентов с экшнами, виджеты в лаунчере, шорткаты, свой собственный экшн для голосового ассистента, приложение для часов на WearOS, приложение для Android TV.

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

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

SRP, OCP, YAGNI, KISS, SOLID... Чем больше занимаешься разработкой, тем больше новых акронимов узнаешь и тем больше тебя убеждают, что им нужно следовать прямо и неукоснительно. При этом о каждом паттерне или принципе можно сказать:

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

В докладе поговорим о границах применимости пяти основных принципов объектно-ориентированного программирования и о том, к чему может привести over-SOLID engineering.

People are getting interested in functional programming now and designing their software as functions that transform data from one type to another, rather than recipes that sequentially modify some state. The claim is that we can "reason about" our software better, design by contract is about capturing that reasoning as statements about the inputs and outputs of our functions, and connecting those together to make sure that our software works correctly for _any_ valid input, not just the few cases we thought about in unit tests.

Swift is not a functional programming language. Pushing too hard to make it one fights Swift and breaks Cocoa.

But Swift has absorbed some fantastic lessons from the functional world, and while value types may not quite be the present, they are clearly the future. We’ll explore how decades of work in functional languages have influenced Swift, and how you can use those features best while staying true to Swift.

Anatoly will drop some knowledge bombs on how to do ASO, how reviews affect your ratings, how to work with your users in order to get to the top of app stores. Will teach you how to get on the App Store Today tab and why it may be not for the best.

Doubt if you should attend? Doubt no more if you want to learn all insides of ASO and how to develop apps that get to the top of the charts.

"Latency Numbers Every Programmer Should Know". Надеюсь, и вы с ней знакомы. Но, тем не менее, она датируется 2012-м годом и ориентирована на десктопы. А как бы она выглядела для современного iPhone?

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

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

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

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

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

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

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

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

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

А также мы более подробно остановимся на различных вариантах реализации частей видеоредактора для платформы iOS на основе AVFoundation, а также посмотрим, как можно применять обычные подходы проектирования к нашей предметной области.

In a perfect world many of us would choose to have a 100 % Swift codebase, while others would choose to have a 100 % Objective-C codebase - both of which are perfectly fine. Would you choose to maintain a mixed codebase? Probably not, but that‘s the reality many of us live in. Legacy Code, don‘t we all love it?

While Mix & Match between Swift and Objective-C works great out of the box, there are many rough edges. Let‘s explore some tricks we can use to bring first-class APIs to both worlds - restoring our sanity, and harmony between both languages.

Поговорим о модели акторов - вероятном будущем модели конкурентности в Swift. Расскажу, кто такие акторы и какие проблемы языка они призваны решить. Что об этом думает К. Латтнер? Есть ли применение модели в iOS-разработке? На сколько граблей нужно будет наступить, чтобы реализовать модель уже сейчас? Расскажу на собственном опыте.

Let's discuss how to use Cipher, what is AES and how to authenticate a message. Dive deep into basic cryptography basic primitives. Let's make it a group therapy session.

Designing simple and expressive libraries is hard, but is a worthy goal. It's too easy to accidentally add complexity. Math can fix that. Math can give us guide-rails that point us to an ideal simple and expressive design. In this talk, we'll use basic abstract algebra to guide us toward a simple and expressive animation library. We'll use animations to help us understand abstract algebra as we discover the true algebraic structure of animations. Only after thinking hard about the structure, do we begin an implementation. In the end, I'll present some examples of working with this animation library we derived over the talk.

Презентация

Accessibility is a very important topic, that is often overlooked or, at best, added as an after-thought. This is very unfortunate, as Apple is doing a great job at providing good and simple to use APIs to make our apps accessible. Apple is fully committed to Accessibility and in providing an equal user experience for all their users, and so should we. The goal of this talk is to give an in-depth look at Accessibility on iOS, as well as outlining the reasons on why to use Accessibility by giving real-world examples of its importance.

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

* Бизнес каждый день участвует в борьбе за пользователей. В высококонкурентной среде во главу угла ставится скорость реализации бизнес-идей. Если выпуск новых фич затягивается, то вы можете потерять своих клиентов — самое ценное, что есть у любого бизнеса.
* В нашем процессе слабым звеном было тестирование, которое затягивало время прохода задачи на прод от нескольких недель до нескольких месяцев.
* За последние полгода мы автоматизировали, изменяли приемочное тестирование, отменили ручное тестирование на промежуточных этапах выливки задачи и отказались от тестирования того, что не имеет ценности для бизнеса.
* В результате нам удалось увеличить среднюю скорость прохода задачи с 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 получил значительное развитие. Пришла пора поделиться текущими результатами. В докладе изложен как продуктовый, так и технический взгляд на поиск Авито, а также взаимосвязь этих аспектов.

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

В докладе попытаюсь сравнить архитектуру и технические решения, используемые в современных 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/

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

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

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

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

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

Традиционно для оценки эффективности компании используются показатели выручки и прибыли. Для компаний, получивших инвестиции и продающих 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. Львиная доля времени по созданию того или иного сервиса уходит на подготовку ТЗ. Своевременное взвешивание ответственности от последствий со стороны бизнес-заказчика в ряде случаев сводит надобность ТЗ к нулю.