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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

Будущее rich text editing.

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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



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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

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

1. Вводная информация о развитии/тенденциях IT-отрасли в Беларуси.
По прогнозу Международной финансовой корпорации к 2020 г. доход IT-отрасли Беларуси может достигнуть $3-4 млрд.
2. Успехи отрасли: Продукты (в том числе с белорусскими корнями): PandaDoc, Kino-mo, World of Tanks, Viber, MAPS.ME, MSQRD, Banuba, «Зомби Ферма», «Рыцари и Принцессы», «Клондайк», Texas Holdem Poker Free, Weather Live, My Alarm Clock, Notepad+. Успешные сделки в белорусском IT (Facebook vs MSQRD, Apalon vs IAC, Viber vs Rakuten и др.).
3. Модели использования кадрового потенциала Беларуси нерезидентами (РФ): фрилансер - ИП - дочерняя компания. Плюсы и минусы каждой модели.
4. ПВТ - специальный правовой режим для стимулирования развития IT. Сравнение ПВТ и Сколково.
5. Налоговая нагрузка на компанию в Беларуси и льготы ПВТ.
6. Требования для резидентства ПВТ и процедура вступления.
7. Охрана исключительных прав на ПО в Беларуси.

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

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

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

«Надо фокусироваться!» — эту фразу как мантру повторяют большинство основателей и менеджеров по продажам, которых я встречал. При этом до 80% своего времени они тратят на работу, которая приносит их компаниям минимум выручки. Против коллег работают культ клиентоориентированности и святая вера в то, что нужно работать со всеми заказчиками.

Чтобы помочь предпринимателям по-настоящему сфокусироваться на том, что приносит прибыль их бизнесу, в Акселераторе ФРИИ мы разработали методологию ABCDX-сегментации — на основе опыта 300+ IT-компаний.

На РИТ++ я поделюсь с вами основами ABCDX-сегментации. Расскажу, какой тип клиентов стоит за каждой из букв в названии методологии, и по каким признакам их можно различать. Поговорим о том, как работать с клиентами, которые приносят вашей компании максимум прибыли (сегменты A и B). Отдельно — о том, как автоматизировать работу с теми, кто приносит мало денег (сегменты C и D). В заключение, стоит ли тянуться к «звездам» — клиентам, с которыми вы хотели бы работать, но ваш продукт к этому еще не готов (сегмент X).

— Добавьте вау-эффектов!
— Вы же профессионалы! Я за что вам ДЕНЬГИ ПЛАЧУ?!
— Пришлите еще вариантов!
— Почему вы сделали, как я сказал?
— Почему вы сделали, не как я сказал?
...

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

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

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

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

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

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

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

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

Краткое содержание доклада:
1. Определите, какой саппорт вам необходимо построить: 24х7 или пятидневка, поддержка физ. лиц или корпоративных клиентов:
- особенности;
- основные отличия.

2. Поиск и найм сотрудников:
- основные требования к кандидату;
- как и где искать.

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

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

5. Оценка эффективности посредством KPI:
- какие метрики использовать?
- как работать с цифрами?
- мотивация команды.

Заказчики (клиенты, руководители) хотят видеть красивые отчеты, а не длинные таблицы. Проблема - как визуализировать данные, чтобы заказчику "понравилось"? Ведь топ-менеджер не поставит подробную задачу, какие KPI, в каком виде показать в отчете, и что для него значит "красиво".

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

Во-вторых, технологии дали новый носитель – дашборды (информационные панели). Я разберу типовые ошибки их построения, дам правила и лучшие практики из 10-летнего опыта внедрения BI-проектов. И покажу, как на дашборде провожу совещание отдела продаж, при вас построю годовой отчет службы HelpDesk.

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

Я начинал с ковыряния just for fun в том, что мне было интересно, потом был готов всё бросить (особенно после общения с несколькими менторами и бизнес-консультантами).

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

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

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

Также хочется рассказать о том, какие вопросы оказалось совершенно неважно решать на старте и какие стоит.

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

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

3. Как повысить лояльность и доверие сотрудника, а сотруднику - получить доверие компании (и роль Хабрахабра в этом).

4. Работа с будущими евангелистами: мотивация, демотивация, типичные ошибки (+ кейс про внутрикорпоративных авторов Хабра).

5. Итоги, статистика, опросы, выводы.

В круглом столе примут участие эксперты: Михаил Клюев, Avito, Александр Сербул, 1С-Битрикс, Саша Белоцерковский, Microsoft, Ольга Белая, Тech Media “Мой Круг“

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

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

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

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

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

Будучи директором IT-компании, в которой использовался широкий стек технологий (порядка 40 библиотек, фреймворков, СУБД и языков), я столкнулся с проблемой управления проектами и менеджерами-"непрограммистами". В этой ситуации очень помогло создание нескольких метрик. Одна из них формализует уровень сложности задач, а вторая – уровень владения разработчиком той или иной технологией.

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

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

Китай - огромный и быстроразвивающийся IT-рынок, по размеру сопоставимый с IT-рынком США и на порядок превосходящий по объему IT-рынок России. Однако, российские предприниматели не рвутся работать на нем, хотя потенциально могут там заработать не меньше, чем на Западе. Скорее всего, этому мешают привычки и укоренившиеся стереотипы о Китае и китайцах.

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

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

В этом докладе нет теории и идеологии, а только конкретные приемы, повышающие эффективность работы команды и бизнеса.

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

Ultimate Guitar - самая рок-н-ролльная команда мирового интернета - нашла свой СПОСОБ работы, который:
- отличает от конкурентов;
- гарантирует разработку продуктов мирового качества;
- помогает набрать звездных сотрудников.

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

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

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

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

А в качестве бонуса я расскажу о том, какой вклад в эволюцию бизнес-процессов вносит поколение миллениалов.

1. Учет и анализ финансов.
2. Структура доходов и расходов.
3. Бюджетирование подразделений компании.
4. Финансовая политика.
5. Планирование денежного потока.

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

Сергей Рыжиков, генеральный директор "1С-Битрикс", порассуждает на тему стратегических возможностей рынка и потенциальных путей развития IT-компаний разного уровня.

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

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