Successfully reported this slideshow.
We use your LinkedIn profile and activity data to personalize ads and to show you more relevant ads. You can change your ad preferences anytime.

Remote (dev)tools своими руками

870 views

Published on

Рано или поздно возникает необходимость в собственных инструментах по разным причинам: либо не хватает готовых, либо есть какая-то особенность в проекте. Разработка инструментов, работающих в браузере, является непростой задачей. Самое сложное — чтобы они умели работать удаленно, вне страницы. Это многих пугает — нужно много сделать и во многом разобраться. Но если большая часть проблем уже решена, и можно сосредоточиться лишь на основной функции инструмента? Что если такие инструменты смогут работать в произвольном WebView, будь оно встроено в браузер, редактор или другое приложение на любом устройстве? Доклад про удалённые инструменты: какие есть сложности и как их обойти, как перестать бояться и начать делать инструменты под свои задачи и технологический стек.

Published in: Technology
  • Be the first to comment

Remote (dev)tools своими руками

  1. 1. Remote (dev)tools своими руками Роман Дворнов Avito HolyJS Москва, 2016
  2. 2. Руководитель 
 фронтенда в Avito Основной интерес – SPA Open source:
 basis.js, CSSO, 
 component-inspector, 
 csstree, rempl и другие
  3. 3. Инструменты
  4. 4. Что значит инструмент? «Инструменты» бывают разные!
  5. 5. В рамках доклада, «инструмент» – 
 программа, которая наблюдает за приложением (страницей, окружением etc), собирает данные и предоставляет к ним графический интерфейс 5
  6. 6. React Developer Tools github.com/facebook/react-devtools
  7. 7. React Developer Tools github.com/facebook/react-devtools
  8. 8. Redux DevTools Extension github.com/zalmoxisus/redux-devtools-extension
  9. 9. github.com/reactotron/reactotron/ Reactotron
  10. 10. github.com/reactotron/reactotron/ Reactotron
  11. 11. github.com/basisjs/basisjs Basis.js DevTools
  12. 12. Забудьте не сможете 10
  13. 13. Анатомия инструментов
  14. 14. 12 Runtime ИнструментApp Простой случай Инструмент работает 
 в том же runtime, что и приложение – в нем же отображает интерфейс
  15. 15. Удаленный инструмент 13 RuntimeRuntime App Инструмент
  16. 16. Удаленный инструмент 13 RuntimeRuntime App Инструмент ???
  17. 17. Почему удаленные инструменты? 14
  18. 18. Developer Tools
  19. 19. Developer Tools runtime #1
  20. 20. Developer Tools runtime #1 runtime #2
  21. 21. Developer Tools runtime #1 Удаленное взаимодействие runtime #2
  22. 22. Мобильные устройства
  23. 23. Мобильные устройства Удаленное взаимодействие
  24. 24. Несколько экранов App Приложение или сайт Editor and devtools Редактор и инструменты
  25. 25. Несколько экранов Удаленное взаимодействие App Приложение или сайт Editor and devtools Редактор и инструменты
  26. 26. Удаленное взаимодействие = больше сценариев использования 18
  27. 27. Идем к удаленным инструментам
  28. 28. 20 Runtime ИнструментSubject Вернемся в начало Очевидно, что одна часть инструмента собирает данные, 
 а другая визуализирует
  29. 29. 21 Runtime Data Subject Разделение ответственности Хорошо ложится на паттерн publisher-subscriber UI
  30. 30. 21 Runtime Data Subject Разделение ответственности Хорошо ложится на паттерн publisher-subscriber UI Publisher собирает и публикует данные
  31. 31. 21 Runtime Data Subject Разделение ответственности Хорошо ложится на паттерн publisher-subscriber UI Publisher собирает и публикует данные Subscriber визуализирует полученные данные
  32. 32. Общая схема работы 22 RuntimeRuntime Publisher Subscriber (UI)Subject Транспорт С этой моделью subscriber (UI) может быть вынесен в произвольный runtime
  33. 33. Терминология • Subject – то, за чем наблюдаем • Publisher – собирает и публикует данные • Subscriber – получает данные и строит интерфейс • Transport – канал и протокол взаимодействия • Host – интеграция в другие приложения (плагин), создает sandbox • Sandbox – окружение для UI 23
  34. 34. Создавая инструмент, нужно создать publisher, subscriber, transport, host и sandbox 24
  35. 35. Например: транспорт
  36. 36. WebSocket 26 Publisher Subscriber (UI)Server Протокол #1 Протокол #2 Соединение publisher-subscriber = 2 соединения
  37. 37. Транспорт не всегда WebSocket
  38. 38. Транспорт не всегда WebSocket DOM event based communication
 Сервер явно не нужен
  39. 39. Extending DevTools 28 developer.chrome.com/extensions/devtools
  40. 40. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject
  41. 41. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject Content script
  42. 42. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject Content script DevTools Tab
  43. 43. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject Content script DevTools Tab Runtime Background page
  44. 44. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject Content script DevTools Tab Runtime Background page
  45. 45. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject Content script DevTools Tab Runtime Background page
  46. 46. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject Content script DevTools Tab Runtime Background page
  47. 47. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject Content script DevTools Tab Runtime Background page
  48. 48. Runtime (devtools) Что это значит для нас? 29 Runtime (page) Publisher Subscriber (UI)Subject Content script DevTools Tab Runtime Background page Соединение publisher-subscriber = 4 event-based соединения
  49. 49. Транспорт – pain points • Минимум 2 типа коммуникации • 2-4 соединения между publisher-subscriber • Соединения могут разрываться и восстанавливаться • Нужен протокол взаимодействия • Коммуникация асинхронная, нужен механизм callback'ов • Обмен данными в JSON (на самом деле строками) 30
  50. 50. Проблемы разработки инструментов
  51. 51. Ключевые проблемы • Сложность реализации инфраструктуры • Неудобство процесса разработки • Версионирование 32 habrahabr.ru/company/jugru/blog/317060/
  52. 52. Пример: изменение в DevTools плагине • Перезагрузить плагин (в Chrome это Extensions) • Перезагрузить страницу • Закрыть Developer Tools • Открыть Developer Tools • Открыть закладку плагина 33
  53. 53. Самое печальное – 
 разные разработчики инструментов решают одни и те же проблемы 35
  54. 54. Свет в конце тоннеля
  55. 55. Сначала нужно сделать: хосты, транспорты и возможность запускать UI удаленно 38
  56. 56. И только после этого приступить к разработке самого инструмента 39
  57. 57. 40 Полезная функциональность Инфраструктура (оверхед)
  58. 58. Rempl спешит на помощь 41 RuntimeRuntime Publisher Subscriber (UI)App
  59. 59. rempl (remote platform) – 
 платформа для получения контролируемого удаленного доступа к JavaScript runtime используя UI 42
  60. 60. Rempl обеспечивает • WS и DOM event транспорты, организует автоматическое соединение • Простое API обмена данными/командами для Publisher и Subscriber • Хосты: developer tools, electron app, web interface, editor plugins etc • Обеспечивает песочницу, самостоятельно получает UI и инициализирует его 43
  61. 61. Одна из задач проекта – 
 снизить порог входа в разработку собственных инструментов 44
  62. 62. С rempl не нужно думать об инфраструктуре 45
  63. 63. Фокус на самом инструменте – нужно написать только 
 Publisher и Subscriber 46
  64. 64. Минутка кода
  65. 65. Publisher 48 <script src="node_modules/rempl/dist/rempl.js"></script> <script> function getUI(settings, callback) { callback(null, 'script', '/* subscriber code */'); } var myTool = rempl.createPublisher('myTool', getUI); setInterval(function() { myTool.publish(Date.now()); }); </script>
  66. 66. Subscriber 49 // subscriber создается песочницей автоматически // не нужно ничего подключать/создавать – получаем готовое API rempl.subscribe(function(data) { document.body.innerHTML = new Date(data); });
  67. 67. Удаленный инструмент – готов! 50
  68. 68. Publisher и Subscriber могут обмениваться командами 51
  69. 69. Обмен командами 52 endpoint.define({ method: function(a, b) { console.log('call smth', a, b); }, … }); На одной стороне На другой стороне endpoint.invoke('method', 'hello', 42); endpoint – publisher или subscriber декларируем методы вызываем метод
  70. 70. API 53 publish(data) define(methods) invoke(method, ...args, cb) ns(name) publish/define/invoke subscribe(fn) define(methods) invoke(method, ...args, cb) ns(name) subscribe/define/invoke Publisher Subscriber
  71. 71. Новые горизонты
  72. 72. Не только браузер
  73. 73. Озарение #1: Publisher работает только с данными, значит его можно запустить в node.js 56
  74. 74. Publisher 57 var fs = require('fs'); var rempl = require('rempl'); var myTool = rempl.createPublisher('myTool', getUI); function getUI(settings, cb) { cb(null, 'script', fs.readFileSync('./ui.js', 'utf8')); } ...
  75. 75. И мы получаем ту же инфраструктуру и для node.js (за исключением браузерных Developer Tools, возможно временно) 58
  76. 76. webpack-dashboard 59 github.com/FormidableLabs/webpack-dashboard
  77. 77. rempl-webpack-analyzer 60 github.com/smelukov/rempl-webpack-analyzer аналог webpack-dashboard на rempl
  78. 78. Преимущества • Можно открыть в любом rempl-хосте • Построен на web-технологиях • Проще делать UI • Возможность сделать более богатый UX • Можно прикрутить готовые решения для анализа и пр. 61
  79. 79. Например, source-map-explorer 62 github.com/danvk/source-map-explorer
  80. 80. Озарение #2: 
 ServiceWorker, WebWorker, … 63
  81. 81. Идея для «стартапа» • Разрабатываем frontend раньше backend • Не хотим захламлять frontend моками – 
 мокаем серверное API в ServiceWorker • Добавляем publisher в ServiceWorker • Делаем UI для управления моками
 в ServiceWorker 64
  82. 82. 65 Мы это уже запатентовали. Если у вас проблемы с этим – увидимся в суде!
  83. 83. 66 Мы это уже запатентовали. Если у вас проблемы с этим – увидимся в суде! Это Open Source – пробуйте, делайте
  84. 84. Озарение #3: 
 Теоретически, Publisher может жить не только в JavaScript – 
 веб-интерфейс для любого процесса? 67
  85. 85. Source + Runtime
  86. 86. Есть прекрасные инструменты для работы с кодом 69
  87. 87. Есть хорошие инструменты заглядывающие под капот приложений (runtime) 70
  88. 88. Но эти два мира инструментов существуют раздельно 71
  89. 89. Представьте, что у вас есть информация о коде, контексте редактирования и состоянии runtime в одном месте… 72
  90. 90. За сложной схемой… 73 Editor Rempl host (editor plugin) Rempl sandbox Subscriber (UI) Browser Publisher App Rempl transport
  91. 91. … простая идея 74 AppSource …
  92. 92. … простая идея 74 AppSource … Связь двух миров
  93. 93. Несколько идей • Подсвечивать на странице то, на что влияет редактируемый файл • Доступные в шаблоне биндинги или текущие значения • Во что ресолвится ссылка на модуль и переход к нужному файлу • Во что транспилируется редактируемый файл • … ограничивается лишь вашей фантазией 75
  94. 94. rempl хост в Atom 76 github.com/rempl/host-atom
  95. 95. Remote devtools → remote apps
  96. 96. Инфраструктура универсальна 
 и позволяет создавать разноплановые решения (приложения) 78
  97. 97. «Безумные» идеи • Управление презентацией (например, Shower) • Стриминг медиа с одного устройства на другие • Свой файлообменник • … 79
  98. 98. rempl не для коммерческих решений или сервисов 80
  99. 99. Но отличная основа 
 для экспериментов 
 и персональных решений, 
 где требуется удаленный доступ 81
  100. 100. Планы
  101. 101. rempl в фазе MVP – 
 многое на подходе 83
  102. 102. В первую очередь • Стабилизировать API • Документация, туториалы, примеры • Обкатать ключевые компоненты (хосты, транспорты и т.д.), реализовать недостающее • Больше опций для поставки UI 84
  103. 103. В долгосрочной перспективе • SDK для наиболее частых задач (данные, DOM etc) • Перевести существующие инструменты на rempl • Безопасность • Connection specific content • Возможность авторизации и разделения прав • … новые идеи появляются постоянно ;) 85
  104. 104. Подводим итоги
  105. 105. rempl (remote platform) – 
 платформа для получения контролируемого удаленного доступа к JavaScript runtime используя UI 87
  106. 106. rempl предоставляет инфраструктуру и упрощает создание удаленных инструментов 88
  107. 107. 89 Subject Subject in-pageSubscriber (UI) Browser Non-browser host Browser's Developer Tools Browser Editor Subscriber (UI) Subscriber (UI) Electron app Subscriber (UI) Subscriber (UI) in-pagePublisher in-pagePublisher
  108. 108. 90 Subject Subject Subscriber (UI) Browser Non-browser host Browser's Developer Tools Browser Editor Subscriber (UI) Subscriber (UI) Subscriber (UI) Publisher Publisher
  109. 109. Это лишь начало – впереди много интересного 91
  110. 110. может стать 
 трендом 2017 года 92
  111. 111. 93 Просто подумайте в этом направлении
  112. 112. github.com/rempl 94 Присоединяйтесь, поддерживайте, помогайте, задавайте вопросы, расскажите о ваших идеях
  113. 113. 95 Интересно,
 что получится у вас
  114. 114. Роман Дворнов @rdvornov rdvornov@gmail.com Спасибо! github.com/rempl

×