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

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

Недавно вышла статья "Agile мёртв" (https://www.linkedin.com/pulse/agile-dead-matthew-kern).
Мне хотелось бы рассказать о том, почему, на мой взгляд, это признак взросления agile и отрасли IT в целом.

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

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

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

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

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

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

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

Что круче — Тесла или Лада Эллада?
Пассажирское квадрокоптер-такси.
На чем на самом деле выгоднее ездить — на бензине или на электричестве?
Ждет ли нас революция электротранспорта и, если ждет, то когда?
Какой транспорт самый популярный в мире?
Правда ли, что не ломается?
Ждут ли нас принципиально новые виды транспортных средств?
Как самому собрать электровелосипед?
Как не платить за электричество?
Бьет ли меня током, когда идет дождь?

Ответы на эти и многие другое вопросы — в моем докладе с теорией и практикой про личный опыт. Приходите. Будет интересно.

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

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

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

Deep Dive в онтологию систем мобильной аналитики — как сделать свою и начать ей доверять.

- Бессерверная архитектура бэкендов.
- Микросервисная архитектура.
- Мобильные бэкенды.
- Облачные технологии.

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

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

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

Цель моего доклада — рассказать о том, как использовать LLVM в связке с языком Swift и показать, что это не "rocket science".

В своем докладе я расскажу о том:

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

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

- WatchDog. Что это такое? Схема реализации с таймером и схема реализации на RunLoop'e.
- Как собирать результат работы WatchDog. Примеры того, что можно таким образом найти, и что мы нашли на проекте ICQ.
- Как работать с полученными результатами. Анализ стеков потоков. Профилирование с учетом расходов на синхронизацию.
- Проблемы при работе с WatchDog. Системные механизмы и популярные библиотеки, вызывающие проблемы. Методы обхода этих проблем. Итоговые параметры, применяемые на проекте ICQ.

- Что такое "чистая" архитектура приложений. Чем грозит "грязная" архитектура, чем от нее отличается "чистая" архитектура, и какой от нее профит.
- История появления VIPER.
- Идея VIPER. Как изменяется структура приложения при применении этого подхода.
- Опыт использования VIPER в Rambler&Co. Что мы изменили и добавили.
- Работа с VIPER на примере user story из реального приложения.
- Выводы: чем помогает VIPER и когда его использовать не стоит.

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

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

А чтобы теория не была такой утомительной, вместо скучных слайдов будет интерактивное демо с примерами!

В данном докладе рассмотрим, как сегодня чувствует себя вредоносный программный код на устройствах с ОС iOS без jailbreak. И конечно, ответим на вопрос о том, дают ли последняя версия ОС и отсутствие jailbreak на устройстве гарантию, что на нем нет вредоносного кода.

В своём докладе я расскажу о подходе к построению навигации в больших приложениях на примере демо-проекта, приближенного по архитектуре к приложению Avito.

Данная архитектура позволяет поддерживать DeepLink’и и iPad в существующем приложении, показывать плашки Push-уведомлений в верхнем видимом модуле, совершать переходы из верхнего видимого модуля, вызванные корневым модулем приложения, а также централизовано управлять анимацией переходов.

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

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

1. Описание предметной области, объектов и понятий, с которыми работает приложение.
2. Выделение сущностей и связей между сущностями, представление в терминах ORM.
3. Описание конфигурации ORM и ObjectCache.
4. Работа с БД
- применение паттерна Команда и Компоновщик для выполнения операций на БД;
- конфигурация исполнителя команд;
- команда как транзакция в БД;
- инструменты, доступные ORMLite для реализации транзакций.
5. Проблема доступа из UI потока к данным, изменяемым в других потоках.
6. Memoization подход для решения проблемы доступа из разных потоков.
7. Описание архитектуры кэшей с применением memoization.
8. Задача поддержания когерентности кэшей;
- использование HaMeR framework для актуализации UI кэша;
- использование механизма блокировок и батч-операций над данными в кэшах.
9. Ограничения ORM ObjectCache при работе с объектами DAO.
10. Реализация DAO с расширенными возможностями работы с ObjectCache.

1. Обзор паттернов и средств, которые применялись для построения архитектуры android приложений.
2. Обзор "новых старых" паттернов программирования, которые сейчас модны в построении архитектуры — Clean architecture, MVP, MVVM, DI. Краткий их обзор, чем они лучше/хуже предыдущих паттернов.
3. Обзор новых инструментов, которые сейчас используются при написании приложений — Dagger 2, RxJava и других.
4. Как все эти паттерны и инструменты помогут нам написать "тестируемый код".
5. Рассмотрение самых различных примеров, которые помогут понять, как конкретную задачу необходимо декомпозировать на различные уровни ответственности (какая часть должна быть в data, какая в business, какая в ui), и как должно происходить взаимодействие этих уровней. И как тесты помогают "выпрямлять" архитектуру.

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

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

Доклад будет полезен абсолютно всем android разработчикам.

Opus, Ogg, NDK и другие подводные камни.

1) Зачем иногда необходимо использовать нативный код в Android разработке;
2) когда не нужно этого делать;
3) что для этого необходимо настроить в проекте;
4) кодек для сжатия аудио Opus (чем хорош, кто использует);
5) контейнер Ogg (преимущества перед другими);
6) практический пример записи голоса, сжатия кодеком opus и упаковка в Ogg контейнер.

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

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

В процессе разработки нашего Enterprise-ready продукта HyperHive — http://eigenmethod.com/products/hh/ (бренд EigenMethod создан для продвижения продукта на Запад, не удивляйтесь другому домену) мы столкнулись с необходимостью реализации ряда задач на нескольких платформах: iOS, Android, Cordova (Android и iOS), а в перспективе и под Windows для мобильных устройств.

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

Функционал фреймворка:
1. Параллельные потоки загрузки данных с сервера и записи в базу (sqlite) и передачи на сервер в рабочих потоках (без блокирования UI).
2. Поддержка Дельта-обновлений при передаче данных (пересылается только разность между двумя версиями данных).
3. Шифрование трафика и базы данных алгоритмами ГОСТ и RSA.
4. Сжатие трафика.
5. Аутентификация и авторизация на сервере, поддержка сессий.
6. Обработка push-уведомлений (MQTT).
7. API для мобильных приложений для предоставления данных, в том числе в оффлайн-режиме.
8. Логирование действий мобильного клиента на сервере.

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

— Космическая скорость разработки приложения (iOs-приложение за неделю);
— Сравнение типичного экрана со списком данных на Objective-C и React Native;
— Поддержка приложения, Debugging;
— Ограничения React Native, которые следует учитывать;
— Бонус: при написании приложения для iOs — 80% Android приложения в подарок :)

° С чего мы начинали;
° Все способы адаптации;
° JavaScript-adaptive;
° Опыт создания собственной библиотеки;
° История панели управления;
° Сервис оптимизации изображений;
° Чему мы научились.

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

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

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

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

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

Недавно запустили новый сайт Тинькофф.

У нас есть желание поделиться с аудиторией подходом и опытом разработки большого изоморфного приложения на React.js и Flux. Меньше чем за год мы разработали новый сайт и интернет-банк, заложив платформу на ближайшие несколько лет для быстрой разработки фронтенда новых продуктов.

Сейчас tinkoff.ru насчитывает более 3000 компонентов и сотни страниц.

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

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

“Страница должна загружаться быстрее чем за 1 секунду; количество серверных запросов должно быть сведено к минимуму; CSS и JS файлы должны быть сжаты и не превышать 50 килобайт…” — это лишь малая часть технических решений и рекомендаций, которыми нас снабжает индустрия в погоне за производительностью. Но во всем этом есть одна проблема — пользователям нет никакого дела до килобайтов, миллисекунд и количества запросов.

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

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

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

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

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

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

Совместно с университетом ИТМО мы запустили курс, посвященный основам HTML и CSS. Уже на момент регистрации на этот курс записалось более 12 тысяч студентов. Перед нами стояла задача разработать систему, которая будет автоматически проверять итоговые проекты на соответствие заранее подготовленному макету. В качестве основной техники для проверки было выбрано регрессионное тестирование.

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

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

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

Доклад будет построен вокруг разбора примеров.

Тезисно:
- Путь проектировщика в проекте. От начала и бумажных тигров, жизненных ситуаций и сценариев, вариантов использования и эскизов до самих прототипов. Про последний этап и будет весь рассказ.
- Акценты. Якорные элементы. Правильное построение визуальной иерархии в прототипе.
- Вертикальный ритм. Выбор кеглей и интерлиньяжей для построения базовых блоков. Расстояния между блоками. Построение заголовочных и третичных текстов по базовым блокам. Использование полученной сетки для определения расстояний между объектами и текстами на странице.
- Аккуратность в прототипах. Верное использование внутренних и внешних кавычек. Длинных тире, коротких, дефисов. Корректное расположение союзов и предлогов.
- Цвета. Выбор базового цвета. Выбор пары комплиментарных цветов по базовым. Подбор верных оттенков серого по базовому цвету.

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

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

1. Логирование.
2. Мониторинг.
3. Алертинг.
4. Бета-пользователи.
5. Саппорт.
6. Плагины.
7. Антивирусы.
и т.п.

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

Доклад посвящен новому open-source проекту — base.network — распределенному независимому пиринговому вебу. Расскажу про общую схему работы сети, немного о работе с криптографией на JavaScript, о создании приложений на JavaScript без использования центральных серверов.

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

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

- Что такое реинжиниринг и зачем он был нужен в tutu.ru.
- Как мы подошли к выбору нового технологического стека.
- Как мы выбрали архитектуру новых приложений.
- Почему мы пришли к TypeScript и React.
- Шаблонизатор для компонентов Reactа, серьезно?
- Выкидывать legacy код жестоко, но нужно же с ним что-то делать.
- Как удовлетворить seo без лишних усилий.

Не так страшен Angular 2, как его малюют.

Первая реакция о нем весьма негативная. Круглые скобочки, квадратные, что это, зачем? Но что, если я вам скажу, что эти скобочки позволяют избавиться от проблем, которые не может решить React v15.x?

Знаете ли вы, что Angular 2 ближе к функциональному программированию, чем Redux?

В этом докладе мы обсудим:
1) Что нового даёт нам Angular 2?
2) Рассмотрим его архитектуру и поймём ценность этих решений.
3) Реактивное программирование с Angular 2.
4) В чём Angular 2 превосходит React и Redux?
5) Как перейти на Angular 2 и спать спокойно.

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

Но если вы простой фронтендер, занимаетесь js, html и css, то 3D-графика для вас покажется совершенно иным миром со своими законами. Так это случилось с нами во время разработки нашего продукта.

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

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

- Всесильны ли препроцессоры?
- Можно ли дать CSS второй шанс?
- Наследуемость или БЭМ?
- А что с обратной совместимостью? Решение есть!

В рамках доклада будут детально рассмотрены практические примеры применения CSS Custom Properties. Также будут рассмотрены новые спецификации CSS Extensions (Сustom selectors) и CSS @apply Rule в рамках перспективы отказа от препроцессоров.

Современный Веб всё больше стремится к динамичным, похожим на приложения, сайтам.
Оперативно строить быстрый и динамичный интерфейс на проекте N1.RU нам помогает Vue.js.
Однако, как и многие современные библиотеки и фреймворки, Vue.js не умеет рендериться на сервере.
При этом иметь такую возможность бывает полезно по нескольким причинам: начиная от вопросов SEO и заканчивая красотой загрузки страницы.
Чтобы реализовать такую возможность для Vue.js мы создали его дополнение — Vue-server.js.

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

React(JS) — это современная библиотека для разработки UI компонентов от Facebook, по праву считающаяся самой трендовой технологией среди JavaScript разработчиков на 2015/16 год.

Но каким образом React стал настолько популярен в среде разработчиков, учитывая что библиотека покрывает только View из необходимого минимума MVC архитектуры? Ответ таится в экосистеме технологий, в рамках которой нам открываются совершенно новые способы разработки приложений, не только для веба, но и нативных платформ с родным UI (iOS, Android, Win 10, OSx).

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

Уже много лет все говорят о компонентном вебе и мире, где новые интерфейсы строятся из готовых блоков на раз-два, но чего мы в итоге достигли? Пока БЭМ, Polymer, Angular и создатели других технологий ищут лучшие пути организации клиентского кода, создавая сложные абстракции, сообщество React уже давно наслаждается отличными и простыми инструментами для работы с UI компонентами.

В рамках доклада Роберт поделится опытом мирового React-сообщества в создании удобных и простых в обращении библиотек UI компонентов.

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

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

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

SERP или просто страница результатов поисковой выдачи — это действительно большой проект с огромной аудиторией. Над ним работают около 40 фронтендеров из разных городов. Эта страница показывается больше 200 000 000 раз в день. При таких размерах даже модульная архитектура уже не слишком спасала нас от странных, неочевидных зависимостей, лишних стилей и нескольких разных реализаций почти одинаковых компонентов.

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

Стала закрадываться мысль, что пора что-то менять. И мы поменяли.

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

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

Responsive web design, HTML5, CSS3, IDE, API, React, Angular, веб-компоненты, БЭМ... Опытным фронтендерам эти слова давно знакомы. А как насчет таких классических архитектур как MVC, MVP или MVVM? Знаете ли вы, что такое MVP, и почему Angular.js построен на паттерне MVVM, а не MVC, хотя в этом фреймворке активно используется понятие "контроллер"? Чем эти три архитектуры отличаются друг от друга, и зачем, вообще, о них нужно знать фронтендеру?

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

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

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

Большие одностраничные приложения тоже устроены сложно. Чтобы их починить или обвесить новым функционалом, требуется вникнуть в их устройство. Для этого нередко приходится засучивать рукава и с головой погружаться в самую глубь проекта. И немалая часть проблем связана именно с бизнес-логикой и потоками данных. Но что, если у нас будет возможность проникнуть в структуру данных, способ увидеть связи между ними и отслеживать то, как они влияют друг на друга? Такой способ, чтобы не требовалось вскрытия черепной коробки — все как с МРТ.

В докладе речь пойдет о собственных разработках в этой области.

Команда Ultimate Guitar буквально сидит друг у друга на головах: рабочая обстановка у нас напоминает все что угодно, кроме «офиса международной компании». Однако эта теснота и атмосфера рукотворны и имеют четкие бизнес задачи:
- постоянное увеличение скорости и количества проводимых экспериментов,
- безбарьерное распространение знаний,
- подталкивание к совместной работе,
- возникновение нетривиальных идей.

Такая модель работы необходима для обеспечения первенства сервису Ultimate Guitar, но совершенно не совместима с «работой из дома». Поговорим об этом, а также:
- о том, почему не стоит работать с мудаками,
- зачем нужны систематические увольнения,
- как увольнения соотносятся со "ставкой на таланты",
- о повышении "фактора странности" компании и превращении менеджера в ведущего шоу.

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

Многие из этих практик и инструментов организационного дизайна применимы в других индустриях и организациях — от стартапов и корпораций до университетов и государственных структур. Один из ярких примеров такой практики — это система OKR (Objective - Key Results: человеческая замена KPI, применимая в Agile-процессах).

С 2014 года мы с группой единомышленников из GameChangers.ru проводим исследование “Организационный дизайн динамичных организаций” и готовы предоставить анализ и рекомендации по использованию наиболее эффективных инструментов и методов стратегического планирования в следующих сферах:
- как организовано управление информацией и принятие решений,
- как распределены обязанности и ответственность,
- как организовано получение обратной связи сотрудников,
- как культура и основные ценности организации воплощаются в конкретных инструментах и практиках,
- как люди, которые лучше всего подходят для определённых позиций оказываются именно на них — практики приема новых сотрудников и ротация персонала внутри компании.

На текущий момент в фокусе исследования в IТ: Google, Valve, GitHub, LinkedIn, Atlassian, Яндекс, ВКонтакте, JetBrains.

Другие сферы: НИУ ИТМО, Иннополис, РосАтом, СБерБанк, Zappos, Uber, Tesla.

Захотят ли суровые админы принять модный тренд за основу своей работы? И получится ли изолированно от разработки принести пользу бизнесу?

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

Я покажу, что находится за горизонтом событий службы эксплуатации. Опишу признаки DevOps, которые служили ориентирами на пути к результату. И опишу инструменты, которые сработали: за 3 года стабильность работы сайта hh.ru выросла в 10 раз.

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

«Адаптируйся или умри» — говорил Дарвин, и это не только про эволюцию видов, но и про эволюцию компаний. Многие компании просто боятся вводить новые процессы, т. к. думают, что это всегда связано с кризисом или большими рисками. На самом деле, если подходить к этому процессу разумно, в этом нет ничего страшного.

Но всем ли нужны четкие бизнес-процессы, регламентированный workflow, автоматизация бизнеса и прочее?

- Зачем нужны бизнес-процессы для малого бизнеса? Каким компаниям они нужны, а каким — нет?
- Кому внедрять workflow, а кому можно пренебречь?
- Внедрение регламентов: теория и практика.
- Инструменты автоматизации: когда пора отказаться от Excel?

Как часто вы слышали эти мифы об обучении и развитии сотрудников: «обучение — это очень дорого»; «наймите тренера-эксперта — у него есть правильные ответы на всё»; «а вот мы сейчас обучим сотрудника, а он уйдет к конкурентам»? Они очень распространены, но при этом неверны, а местами даже вредны.

Я расскажу, как мне на практике пришлось столкнуться с ними, и как я с ними боролась. И вот на каком реальном примере: год назад Parallels приобрела крупного разработчика ПО для удаленного доступа к приложениям и виртуальным рабочим столам — компанию 2X Software со штаб-квартирой на Мальте. В связи с этим возникла необходимость предоставить бизнес-поддержку для нового продукта. Но задача осложнялась тем, что до этого момента сопровождение этого софта осуществлялось силами мальтийских сотрудников интуитивно, а наша основная команда специализировалась на клиентской поддержке.

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

Пытаясь развеять эти мифы и подготовить специалиста с качественно иными навыками и умениями, я поняла следующее:
- Найти необходимого специалиста новой формации сложно, а переподготовка и традиционные формы обучения текущих кадров не работают. Я расскажу о формах, которые в итоге сработали и принесли достойные результаты. Например, нам удалось сократить время обучения новых сотрудников с 6 до 2 месяцев. А команда, состоящая лишь из 6 инженеров обрабатывает заявки теперь не за 10 часов, а за 1.5 часа.
- Техническая подготовка и “прокачка" сотрудников информацией не повышает эффективность команды, а высокие показатели специалиста по результатам аттестации не гарантируют качественную поддержку: быстрое время ответа клиенту, 100% качество обработки заявок, удовлетворенность клиента более 90%.
- Для переподготовки специалистов не обязательно требуется значительный бюджет и привлечение внешнего тренера-эксперта. Обладая минимальным бюджетом и активно используя внутренние резервы компании, такие как разработка персональных планов обучения ведущими внутренними специалистами, анализ case study, подготовка самими инженерами тренингов по компонентам, проведение Q&A с разработчиками продукта — можно значительно повысить уровень подготовки команды.

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

В этом докладе мы порассуждаем над реалистичными принципами управления компанией и IТ-продуктами в период неопределенности.

• Главное — не потерять всех клиентов, которые хотят перечислить нам деньги.
• Низкая цена — наше преимущество.
• Мы не можем поднять цену, потому что на рынке такой уровень.
• Нам нужен большой PR.

Базой для доклада станет опыт работы Акселератора ФРИИ с 200+ IT-компаний. Будут разобраны наиболее показательные кейсы.

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

Выход в Европу — особенности ведения операционной деятельности в ЕС, выбор юрисдикции для создания операционной компании, сравнение по налогообложению и затратам на организацию и ведение бизнеса. Подробно рассмотрим страны Балтии (Латвия, Эстония), северной Европы (Англия, Ирландия), южной Европы (Кипр, Португалия).

Выход в Азию — классика (Гонконг и Сингапур), особенности бизнеса в Азиатском регионе. Развенчиваем миф о том, что Азия — это путь к быстрым деньгам. Основные "грабли" российского бизнеса на пути ведения бизнеса в азиатском регионе.

Латинская Америка — Бразилия. Такая далекая по территории и такая близкая к России по "зарегулированности" и административным препонам. Когда стоит серьезно рассматривать этот регион.

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

Я хотел бы рассказать:
а) как правильно оценить потенциальный сегмент потребителей, как оценить проблемы и бонусы, которые клиент ожидает.
б) как составить бизнес-модель, которая пройдет тест на выживание в реальной жизни и позволит вам проверить необходимость в вашем бизнес-проекте с минимальными затратами.
в) каким образом попасть в 10% удачных стартапов и как выбраться из ямы 90% провальных проектов.

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

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

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

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

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

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

Безопасность — второй не менее важный вопрос в персональных данных. Можно защищать по закону, можно по "IТ понятиям". Рынок средств защиты данных большой, но что выбрать? Покупаем готовое или создаем свое? Мы поговорим о том, какие плюсы и минусы у данных подходов.

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

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

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

Затем будут разобраны основные мифы, касающиеся выполнения данного закона.

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

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

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

Как распознавать благоприятные для обращения в суд моменты?
Как оценивать шансы на выигрыш и проигрыш? Что делать, если тебе предъявлен иск?

Идти в суд самому, найти нормального юриста или поручить штатному? Сколько стоит Харви, и не лучше ли отдать эти деньги детям?

Я проиграл. Что делать?
Я выиграл. Что делать?

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

Jira всем и каждому, и пусть никто не уйдет обиженным.

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

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

Плюсы внедрения Jira в проекты любого типа.
- Безопасность.
- Удобство и скорость формирования отчетов.
- Быстрый анализ эффективности команды и проекта.
- Экономия времени и порядок в финансовых расчетах.

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

В докладе я показываю, что современная производительность серверов позволяет не думать о нагрузке для 95% "highload" проектов, знания из конференций не нужны в реальной жизни. Для разработки почти любого, даже очень крупного сайта достаточно PHP+MySQL, здравого смысла и совсем-совсем базовых правил, не обсуждающихся даже на Highload Junior.

План выступления.

1. Ликбез о производительности. RPS, latency — что это значит, как считается, к каким числам надо стремиться? Из чего складывается время отклика? База данных, фронтенд, верстка или мобильное приложение.

2. Замеры достижимой производительности теплого LAMP-ового сервера. Бенчмарк без индексов в базе.
Бенчмарк с индексами в базе. Сравнение с требуемыми цифрами.

3. Перечисление возможных детских ошибок, которые могут испортить эти результаты в жизни. Все эти ошибки объясняются не в академии Highload или институте Highload Junior, а в школе.
Примеры ошибок:
- выгрузка всей базы, а не нужных 20 элементов;
- паразитный вызов тяжелой страницы;
- плохой хостинг;
- чужие тормозные элементы;
- неадекватный объём html/js-кода.

4. Отсутствие детских ошибок позволяет эффективно программировать 90% крупных сайтов, 3-4 приема превратят 90% в 95%.
- nginx;
- репликация;
- кэширование и предрасчет.
Этому, кстати, тоже почти не учат на highload junior, но этому я вас уже научил.

5. Примеры продуктов, в которых на самом деле нужен highload?
- Очень-очень-очень много хитов, дешевле highload, чем новое железо.
- Очень много очень хитрых хитов, без highload хит отработать не успеет.
- Наш сервис — не конечный сайт клиента, а сервис для сервиса, требования к производительности выше обычных.
- Наш сервис тормозит из-за тормозного партнера, на партнера повлиять не можем, highload — костыль вокруг него.
- Фронтенд на любом проекте

В других местах highload не нужен, это просто очередной buzzword за ваши деньги.

21 век по праву называют веком Азии. С этой частью света связано множество бизнес-мифов и "страшилок".
Так ли сложно завоевать любовь восточной аудитории?

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

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

В докладе я хочу поделиться нашим (http://erlyvideo.ru/) опытом по международным продажам b2b ПО, разрабатываемого в России. Зарубежный доход — это 80% наших денег при предельной диверсификации наших доходов, нам платят люди из почти 100 стран.

Структура доклада:
1. Что мы продаем и как зарабатываем.
2. Как получилось вывести на международный рынок.
3. Почему наш софт покупают.
4. Как мы продаем и поддерживаем.
5. Кто клиенты, как с ними общаемся.
6. Как принимаем деньги и платим налоги (карты, пейпал, банковский счет, recurrent).
7. Сравнение российского ООО и зарубежной компании: юридические, налоговые аспекты.
8. Перспективы и вызовы.

1) Что такое HR-бренд.
- Основные задачи которые он решает.
- Как понять, есть он у вас или нет?

2) Если бренда нет или его нужно подкорректировать. Как построить стратегию развития бренда и с каких шагов следует начать.
- Что мы сейчас имеем и какими мы хотим быть.
- Выявляем свои сильные стороны.
- Меняем подход к коммуникациям.
- Как работать с негативом.

3) Как оценивать изменения результатов?
4) Кто в компании развивает HR-бренд. МИФ: ставим задачу HR, нанимаем PR-менеджера, и работа сделана.
5) Какие результаты мы получили, работая над HR-брендом 2,5 года

Согласно исследованию Forbes, пять из десяти ТОП компаний, которые «нанимают, как сумасшедшие», так или иначе относятся к сфере IT.

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

Работает принцип «деньги — самое дешевое средство» для привлечения лучших.

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

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

Большинство профессиональных рекрутеров скажут — это невозможно, так нельзя, это незаконно. Тем не менее, эти практики из опыта наиболее передовых IT-компаний.

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

Речь пойдет об опыте Mail.Ru Group в области организации масштабного обучения студентов на базе ВУЗов и привлечения junior программистов в компанию.

Основные вопросы:
- зачем бизнесу нужна стажерская программа?
- зачем бизнесу нужно сотрудничество с ВУЗом?
- какие оптимальные схемы сотрудничества, как продать ВУЗу обучение на его базе?
- кто должен преподавать, и как продать своим сотрудникам обучение студентов?
- как организовать обучение и как привлекать студентов ВУЗа?