YaC 2013 Notes
Upcoming SlideShare
Loading in...5
×
 

YaC 2013 Notes

on

  • 650 views

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

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

Statistics

Views

Total Views
650
Views on SlideShare
650
Embed Views
0

Actions

Likes
3
Downloads
1
Comments
0

0 Embeds 0

No embeds

Accessibility

Categories

Upload Details

Uploaded via as Adobe PDF

Usage Rights

© All Rights Reserved

Report content

Flagged as inappropriate Flag as inappropriate
Flag as inappropriate

Select your reason for flagging this presentation as inappropriate.

Cancel
  • Full Name Full Name Comment goes here.
    Are you sure you want to
    Your message goes here
    Processing…
Post Comment
Edit your comment

YaC 2013 Notes YaC 2013 Notes Presentation Transcript

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