Презентация о самых интересных моментах YaC 2013, которые я видел и услышал

1. YaC 2013

2. Основные цели посещения
YaC
• Послушать доклады про проектирование и
поддержку API
• Послушать доклады про производительность и
разработку
• Пообщаться с разработчиками и узнать их
мнение на некоторые аспекты разработки

3. Итоги YaC
• 68 докладчиков
• 6 залов
• 7 секций
• 54 доклада
• 9 прослушанных докладов
• 5 интересных докладов
• 2 полезных доклада
• 2 человека с которыми было полезно пообщаться

4. Какие доклады оказались
интересными?
• Рекомендации по проектированию API
• Вклад Adobe в Web
• API Design at GitHub
• API для людей: как создать API, которым понастоящему пользуются
• How to Destroy The Web

5. Чем же они были
интересны?

6. Рекомендации по
проектированию javascript API
• Программный код – пользовательский интерфейс.
• Но все меняется когда мы добавляем API.
Программный код – программный интерфейс – пользовательский интерфейс
• Обязательно должна быть обратная совместимость
• Пользователь не должен переписывать свой код, когда вы свой код должны переписывать (версионирование?)
• Абстракции в API
Рекомендации
• Уровни должны знать только о своих соседях. Каждый уровень – это информационный контекст
• Максимальное разграничение обязанностей
• Работа через события – На каждое действия придумываем события и потом контролы подписываются лишь на нужные
• Программные интерфейсы. Интерфейсы могут наследоваться
• Продумываем сначала абстракции потом пишем код используя методы интерфейсов
• Значения по умолчания

7. Вклад Adobe в Web
• Было рассказано про:
1. css-regions – перетекание текста работает уже в ios7
2. css-shapes
3. blend modes – круто, но все еще нет multiply
• Adobe купил PhoneGap
• Topcoat использует BEM и он создан для пользователей PhoneGap
• В кратце рассказано про Brackets, который использует Apache Cordova (cordova.io)
• Web Platform (webplatform.org) – соц.платформа – wiki по веб разработке
• Дмитрий Барановский показал короткое демо своей новой библиотеки по работе с SVG,
которая будет официально представлена 22 октября на HTML5DevConf

8. API Design at GitHub
• Если нужно в api поменять формат выдачи ресурса в соответсвии с добавлением новой
информации, не нужно ломать старый формат или добавлять версии. Нужно смерджить новый
формат в старый
• Совместимый api куда важнее чем красивый api
• Если вы выпустили бета api, для того что бы пользователи это поняли при обычном
использовании необходимо:
1. В ответе на запрос возвращаем 415 (Unsupported media type) с сообщением о том что
это бета версия с ссыкой на документацию.
2. В документации указан кастомный заголовок с котором будет возвращаться правильный
ответ.
Например – Accept: application/vnd.github.com.preview+json
• api.github – это приложение написанное на sinatra (ruby)

9. API для людей: как создать API, которым
по-настоящему пользуются
1. Моделирование за лидером
1. две компании – два типа API
1. Flick
2. Twitter – его и выбрали
1. RESTfull
2. JSON
3. OAuth
4. Convention over configuration
2. Моделирование информации
1. Разбивка на логические классы
2. Выдача фото с коментариями как 2 запроса – это дешевле для серверов + пользователь видит результат быстрее
3. Версия 1.0
1. Read-write
2. Базовые возможности сайта
3. Аутентификация
4. Постоянное развитие (v1.0 прожил 2 дня)
4. RTFM – документация превыше всего!
1. Документация находится на github – разработчики могут предлагать правки
5. Решение проблем с API с помощью аналитики
1. Server perf
2. Оптимизация под массового пользователя
3. Среднее время запроса 100-120мс
6. Feedback driven development

10. А какие оказались на
удивление полезными?
• Добро пожаловать в SoundCloud!
• Когда загрузится страница нам нужно знать
наверняка

11. Добро пожаловать в
SoundCloud!
• Ребята используют Requre.js + Almond, Backbone.js (Trombone), Handlebars и много самодельных
тулзов
• css в amd – стили собираются, как js компоненты, которые могут добавляться и удаляться из страницы
• Передача экземпляра модели в разные вью – identity map (паттерн Object Pools).
• Используется ручной GC – делает зачистку identity map раз в минуту убедившись, что объекты долгое
время не использовались
• Есть утилита memory-leak-finder (вдохновлена JSWhiz – расширением для Google Closure Compiler)
которая анализируя код и ищет возможные утечки
• Используют api window.performance каждые 30 минут для сбора статистики
• С помощью AST для девбилдов добавляют в каждую функцию дебаг вызов что позволяет составлять
расширенный stack trace при ошибках
• Для определения производительности страниц используют враппер над devtools – Telemetry (написана
на Python)

12. Дополнительно о
структуре SoundCloud
• Для каждой страницы собирается 3 пакета скриптов:
1. Вендорные скрипты (jQuery, Backbone и т.д.)
2. Шаблоны и стили
3. Модули
• Стили указываются в качестве зависимостей для View.
• Это позволяет точно знать какие стили нужны для конкретного модуля/виджета и позволяет легко контролировать
дерево стилей
• Css файлы не используют импорты
• Стили компилируются в AMD модули на лету при запросе с сервера
• Вложенные вью можно указать в шаблоне через хелпер Handlebars – {{view "views/name" id="123"}}
• Модули пишуться в нотации CommonJS с последующей компиляцией на лету в AMD – позволяет убрать из модулей
лишние обертки + использовать модули на node.js
• Identity Map реализуется через коллекцию синглтонов, которые можно вернуть по уникальному id при инициализации
модели во вью. Во вью передается коструктор модели, а не экземпляр.
• Модификация js кода на основе AST делается по схеме Esprima (составление дерева) → estraverse (изменение нужных

13. Когда загрузится страница нам нужно знать наверняка
• Загрузка страниц:
1. До 100 мс – мгновенно
2. До 1с – ожидание…
3. Больше 1с – переключение внимания
• У Яндекса есть утилита под названием Шутилка, которая делает следующее:
1. Внедряется в процесс браузера
2. Запускает процесс открытия указанной страницы начиная делать скриншоты страницы каждые 10мс
3. По завершению визуальных изменений на странице отфильтровывает дублирующиеся изображения и передает
оставшиеся изображения в программу анализа
4. Программа анализа строит граф изменения изображения и позволяет анализировать загрузку во временых отрезках
• Задача для измерения – узнать время начала/окончания визуальных изменений у пользователя
• Как измеряли:
1. Скрипты на странице (end of body – start of head)
1. Есть кореляция
2. Зависит от сети, браузера + погрешность
2. Navigation Timing API
1. perfomance.timing – много полезной информации, но в ней нет того момента, когда браузер начал что-то
отрисовывать
2. domContentLoad – navigationStarted?
3. Эксперементальные API
1. performance.timind.firstPaint – IE (все супер круто)
2. chrome.loadTimes().firstPaintTime – Chrome (почти идиально – погрешность 100мс)
3. Пока нет поддержки в FF (хотя можно выставить флаги на машинах разработчиков)
4. Не правильные данные в Opera
4. SpeedIndex

14. Что в итоге я для себя
вынес?
• Появилось много идей по усовершенствованию архитектуры
Фогейма и процесса разработки (скоро будут описаны в wiki)
• Выяснил что разработчики думают про использование
localStorage для кеширования статики. Какие плюсы и минусы
на реальных проектах/прототипах
• Узнал все особенности по оптимизации скорости отрисовки
страницы в конкурсе от Яндекса
• Появилась идея MVC подобного фреймворка для разработки
модулей. В скором времени закончу описание принципов работы.