° С чего мы начинали;
° Все способы адаптации;
° 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, хотя в этом фреймворке активно используется понятие "контроллер"? Чем эти три архитектуры отличаются друг от друга, и зачем, вообще, о них нужно знать фронтендеру?

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

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

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

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

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