YaC 2013
Основные цели посещения
YaC
• Послушать доклады про проектирование и
поддержку API

• Послушать доклады про производительн...
Итоги YaC
• 68 докладчиков

• 6 залов

• 7 секций

• 54 доклада

• 9 прослушанных докладов

• 5 интересных докладов

• 2 п...
Какие доклады оказались
интересными?
• Рекомендации по проектированию API

• Вклад Adobe в Web

• API Design at GitHub

• ...
Чем же они были
интересны?
Рекомендации по
проектированию javascript API
• Программный код – пользовательский интерфейс. 

• Но все меняется когда мы...
Вклад Adobe в Web
• Было рассказано про:

1. css-regions – перетекание текста работает уже в ios7

2. css-shapes

3. blend...
API Design at GitHub
• Если нужно в api поменять формат выдачи ресурса в соответсвии с добавлением новой
информации, не ну...
API для людей: как создать API, которым
по-настоящему пользуются
1. Моделирование за лидером

1. две компании – два типа A...
А какие оказались на
удивление полезными?
• Добро пожаловать в SoundCloud!

• Когда загрузится страница нам нужно знать
на...
Добро пожаловать в
SoundCloud!
• Ребята используют Requre.js + Almond, Backbone.js (Trombone), Handlebars и много самодель...
Дополнительно о
структуре SoundCloud
• Для каждой страницы собирается 3 пакета скриптов:

1. Вендорные скрипты (jQuery, Ba...
Когда загрузится страница нам нужно знать наверняка
• Загрузка страниц:

1. До 100 мс – мгновенно

2. До 1с – ожидание…

3...
Что в итоге я для себя
вынес?
• Появилось много идей по усовершенствованию архитектуры
Фогейма и процесса разработки (скор...
Upcoming SlideShare
Loading in …5
×

YaC 2013 Notes

591 views

Published on

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

Published in: Technology
0 Comments
3 Likes
Statistics
Notes
  • Be the first to comment

No Downloads
Views
Total views
591
On SlideShare
0
From Embeds
0
Number of Embeds
4
Actions
Shares
0
Downloads
3
Comments
0
Likes
3
Embeds 0
No embeds

No notes for slide

YaC 2013 Notes

  1. 1. YaC 2013
  2. 2. Основные цели посещения YaC • Послушать доклады про проектирование и поддержку API • Послушать доклады про производительность и разработку • Пообщаться с разработчиками и узнать их мнение на некоторые аспекты разработки
  3. 3. Итоги YaC • 68 докладчиков • 6 залов • 7 секций • 54 доклада • 9 прослушанных докладов • 5 интересных докладов • 2 полезных доклада • 2 человека с которыми было полезно пообщаться
  4. 4. Какие доклады оказались интересными? • Рекомендации по проектированию API • Вклад Adobe в Web • API Design at GitHub • API для людей: как создать API, которым понастоящему пользуются • How to Destroy The Web
  5. 5. Чем же они были интересны?
  6. 6. Рекомендации по проектированию javascript API • Программный код – пользовательский интерфейс. • Но все меняется когда мы добавляем API. Программный код – программный интерфейс – пользовательский интерфейс • Обязательно должна быть обратная совместимость • Пользователь не должен переписывать свой код, когда вы свой код должны переписывать (версионирование?) • Абстракции в API Рекомендации • Уровни должны знать только о своих соседях. Каждый уровень – это информационный контекст • Максимальное разграничение обязанностей • Работа через события – На каждое действия придумываем события и потом контролы подписываются лишь на нужные • Программные интерфейсы. Интерфейсы могут наследоваться • Продумываем сначала абстракции потом пишем код используя методы интерфейсов • Значения по умолчания
  7. 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. 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. 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. 10. А какие оказались на удивление полезными? • Добро пожаловать в SoundCloud! • Когда загрузится страница нам нужно знать наверняка
  11. 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. 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. 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. 14. Что в итоге я для себя вынес? • Появилось много идей по усовершенствованию архитектуры Фогейма и процесса разработки (скоро будут описаны в wiki) • Выяснил что разработчики думают про использование localStorage для кеширования статики. Какие плюсы и минусы на реальных проектах/прототипах • Узнал все особенности по оптимизации скорости отрисовки страницы в конкурсе от Яндекса • Появилась идея MVC подобного фреймворка для разработки модулей. В скором времени закончу описание принципов работы.

×