Сергей Константинов (Яндекс)

1,378 views
1,270 views

Published on

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

  • Be the first to like this

No Downloads
Views
Total views
1,378
On SlideShare
0
From Embeds
0
Number of Embeds
864
Actions
Shares
0
Downloads
6
Comments
0
Likes
0
Embeds 0
No embeds

No notes for slide

Сергей Константинов (Яндекс)

  1. 1. JS API Яндекс.Карт 2.1 Почему и зачем мы меняем API? Сергей Константинов руководитель службы разработки API Яндекс.Карт
  2. 2. Обратная совместимость • Экономит деньги • Держит карму в чистоте • Клиенториентировано!
  3. 3. API 2.1 Встречайте: JS API 2.1: • Мы сломали обратную совместимость*
  4. 4. API 2.1 *На самом деле, нет
  5. 5. API 2.1 *На самом деле, нет • Мы продолжаем поддерживать предыдущие мажорные версии • Мы не озвучиваем сроки прекращения поддержки, потому что их нет
  6. 6. API 2.1
  7. 7. Зачем? • Новые технологии • Новые тренды в дизайне • Новые времена • Нам надоело поддерживать старый код, мы хотим писать новый • Прост))
  8. 8. Зачем? Правильный ответ: • Чтобы решать задачи пользователя
  9. 9. Задачи По большому счёту, есть два типа задач: • поддержка "железа" • поддержка кейсов
  10. 10. Задачи С поддержкой кейсов всё сложнее, чем кажется. Кейсы есть: • у нас • у вебмастеров • у пользователей
  11. 11. Задачи Давайте лучше на конкретных примерах
  12. 12. Элементы управления В API 2.0 у нас есть прекрасный набор элементов управления
  13. 13. Проблема
  14. 14. Проблема
  15. 15. Что делать? • Добавить fullscreen • Заодно чуть лучше станет на мобильных
  16. 16. Что делать? • Адаптивные контролы
  17. 17. Что делать? • Добавить стандартные наборы элементов управления • Лучший программный интерфейс – хорошо подобранный default
  18. 18. Что делать? • История успеха: http://tech.yandex.ru/events/yac/2013/talks/1113/
  19. 19. Вывод? • Иногда разработчику нужно дать свободу так, чтобы он ей не пользовался
  20. 20. Ещё проблема • Объём кода в API давно вышел за пределы разумного • Долго грузится, долго парсится, долго исполняется • 800+ различных сущностей
  21. 21. Решение 1.0 • Грузим всё сразу: • Не айс
  22. 22. Решение 1.1 • Выделяем дополнительную функциональность в подгружаемые модули:
  23. 23. Решение 1.1 • Однако за время пути базовая функциональность успела подрасти • Гигантский файл с данными • Лишние запросы за CSS и картинками
  24. 24. Решение 2.0 • Режем по живому: – делим функциональность на пакеты – самый "маленький" пакет (package.map) содержит самый минимум – только карту
  25. 25. Решение 2.0 • Грузим по требованию: – данные по масштабам и копирайтам теперь не грузятся, а запрашиваются при смене центра – пользователь может подгружать функциональность, когда она ему реально потребовалась
  26. 26. Решение 2.0 • Экономим запросы: – CSS теперь отдаётся вместе с JS – Картинки кодируем прямо в CSS
  27. 27. Решение 2.0 • У нас получилось? – минимальная сборка: – максимальная сборка:
  28. 28. Решение 2.0 • Отгадайте, сколько пользователей грузит минимальную сборку?
  29. 29. Решение 2.0 • На самом деле, так не работает • Не нужно надеяться на то, что пользователь решит проблему, которую вы сами решить не смогли
  30. 30. Решение 2.1 • Один package.full • Модели грузим сразу, отображения – по требованию
  31. 31. Решение 2.1 • Например, пользователь включил линейку: • Ушёл запрос за графикой:
  32. 32. Решение 2.1 • Для этого нам пришлось очень существенно изменить интерфейсы – getOverlay() -> Promise – balloon.open() -> Promise
  33. 33. Решение 2.1 • Под капотом: новая модульность https://github.com/ymaps/modules • Асинхронный require • Асинхронный provide • Работает на клиенте и на сервере
  34. 34. Ещё проблема • Мы стараемся держаться плотного графика, выпуская релиз раз в 3-4 недели • Но мы не хотим при этом что- нибудь сломать пользователям
  35. 35. Решение 1.0 • Можно подключать API с указанием мажорной (1.0) или полной (1.0.8) версии • Мало функциональности – мало багов
  36. 36. Решение 1.1 • А что, схема времён 1.0 по- прежнему работает! • А если что, мы выпустим релиз 1.1.5-а, никто же и не заметит
  37. 37. Решение 2.0 • Теперь у нас три версии: – 2.0 – последняя выпущенная – 2.0-stable – последняя "стабильная" – 2.0.xx – прямая ссылка на конкретную версию
  38. 38. Решение 2.0 Да, но… • Откуда у нас возьмётся "стабильная" версия? • В каждой версии мы правим баги и выкатываем фичи
  39. 39. Решение 2.0-с-половиной Мы разделяем релизы • За фичовым релизом обязательно следует дебажный • stable переключается только на дебажный
  40. 40. Решение 2.0-с-половиной Теперь у нас всё просто • stable – это тот же 2.0, только без последних фич • Отгадайте, какой ответ на вопросы в техподдержку стал самым популярным
  41. 41. Решение 2.0-с-половиной Тогда мы стали делать RC • Версия-релиз кандидат доступна только по прямому URL-у и тестируется несколько дней • Потом переключается 2.0
  42. 42. Решение 2.0-с-половиной Отгадайте, сколько багов нам зарепортили в версиях-релиз кандидатах?
  43. 43. Решение 2.1 Мы держим два алиаса: • 2.1-dev: релиз-кандидат, последняя выпущенная версия • 2.1: если в RC не найдено ошибок, 2.1 переключается на него
  44. 44. Решение 2.1 Будет ли оно работать? Да кто же его знает. Практика – критерий истины.
  45. 45. Теория vs. Практика В отличие от задач пользователей, проблемы "с окружающим миром" имеют свойство случаться ВНЕЗАПНО.
  46. 46. Например • Экраны с device pixel ratio > 1 победоносно шествуют по планете
  47. 47. Решение • Каждую картинку, каждый фончик, каждый источник тайлов отрисовываем в нескольких разрешениях • Каждый программный интерфейс принимает ImageSet
  48. 48. Решение Сколько существует разных DPR? • 1x (спасибо, кэп) • 2x
  49. 49. DPR Сколько существует разных DPR? • 1.5x (старые Андроиды) • 3x (новые Андроиды)
  50. 50. DPR Сколько существует разных DPR? • 1.7 (LG Optimus) • 1.8 (Samsung Galaxy Mega 6.3) • 2.25 (Opera Mobile)
  51. 51. DPR Сколько существует разных DPR? • 1.325 (Asus Nexus 7) • 5:3, 15:9 (Nokia)
  52. 52. DPR (здесь должна быть картинка "да, мы упоролись", но всё понятно и так)
  53. 53. DPR • Мы переписали всё на SVG и <canvas> • Для IE < 9 осталась старая вёрстка • (/me с ужасом ждёт того дня, когда кто-нибудь запустит старый IE на ретиновом мониторе)
  54. 54. SVG метки Игла в яйце, яйцо в утке… • Берём шаблон SVG • Подставляем нужные цвета • Формируем CSS-класс, которому в background выставлен этот SVG • … • PROFIT!
  55. 55. SVG метки
  56. 56. SVG метки Пробуем на практике: • Берём шаблон SVG • Подставляем нужные цвета • Формируем CSS-класс, которому в background выставлен этот SVG • … • Слайдшоу!
  57. 57. SVG метки Добавляем пару шагов: • Берём канвас • Делаем drawImage, передавая закодированный SVG как data:uri • Преобразуем в закодированный PNG • … • Вот теперь PROFIT!
  58. 58. SVG метки К сожалению, обратная совместимость пала смертью храбрых 
  59. 59. Или вот ещё проблема • В версии 2.0 мы используем промисы https://github.com/dfilatov/vow • В ECMAScript6 включены промисы как примитив языка
  60. 60. Или вот ещё проблема • Промисы "по стандарту" не совпадают ни с одной из существующих реализаций, включая нашу • (какая ирония)
  61. 61. Это, конечно, не всё Конечно же, мы заодно очень хотели полечить и свои косяки внедрить решения, время которых ещё не пришло на момент выпуска 2.0.
  62. 62. Это, конечно, не всё • Рисовать все метки на одном канвасе • Управлять видимостью объектов в кластеризаторе • Решить проблемы с производительностью
  63. 63. 2.1 Причины изменений в API: Сделать хорошо пользователю Сделать хорошо разработчику Идти в ногу со временем Уныние и отчаяние
  64. 64. Мораль Ты, как разработчик API, должен: • Следить за юз-кейсами • Следить за практикой внедрений • Читать техподдержку
  65. 65. Мораль Ты, как разработчик API, должен: • Периодически выпускать новые версии
  66. 66. Всем спасибо! Вопросы? • clubs.ya.ru/mapsapi • (facebook|vk).com/ymapsapi В крайнем случае: • Сергей Константинов twirl@yandex-team.ru

×