Я работаю четыре дня в неделю на настоящей работе и провожу около дня в неделю, решая интересующие меня проблемы с крошечными программными приложениями. Я собираю набор инструментов, чтобы быстро строить на основе архитектурных шаблонов, которые, как я обнаружил, продолжают появляться в крошечных приложениях. Выбранная мной технология должна решить следующие проблемы:
- Я хочу платить только за то, что использую (масштабирование до нуля)
- У меня не так много времени для обучения или создания (нет крутых кривых обучения без существенной экономии времени)
- У меня нет времени на техническое обслуживание (нет исправлений серверов, автоматизированное масштабирование)
- Я не хороший UI-дизайнер или фронтенд-инженер (дизайн-системы — это здорово).
Я давно интересовался использованием одной из крупных офисных платформ для создания встроенного дополнения. Для одиночного разработчика это не составляет труда: платформа заботится о вышеперечисленных требованиях, а когда у платформы есть рынок, есть даже готовый канал распространения, чтобы вывести ее на рынок! Единственная реальная причина, по которой я до сих пор сопротивлялся этому, — это страх перед утомительным процессом утверждения платформы и требуемым обеспечением. В этой истории я объясню, как я почувствовала страх и все же сделала это 😀. Ниже приведен листинг продукции для JIT Time.
Рабочая область Google
Google Workspace — это последнее название продукта, ранее известного как GSuite, ранее известного как Google Apps. Gmail — это часть пакета, с которой знакомо большинство людей. Он также включает Календарь, Google Диск и дополнительный пакет Google Docs. Я использую Workspace в собственном домене для электронной почты, чата и календаря для своей семьи. Мы также используем его в моей повседневной работе в качестве основного офисного пакета для повышения производительности.
В Google Workplace есть торговая площадка, где пользователи могут найти и установить надстройки, расширяющие функциональность всех приложений. Большая часть контента на рынке представляет собой интеграцию с популярными сторонними приложениями, такими как CRM и другие инструменты повышения производительности, но есть и специально созданные надстройки.
Проблема бизнеса
Занятые люди изо всех сил пытаются найти время на работе для повседневных нужд, таких как обед, посещение спортзала или просто время для размышлений. Мне легко прийти в понедельник и обнаружить, что благодаря другим людям, которые просят встречи, у меня нет времени на обед на следующей неделе. Некоторые люди справляются с этим, устанавливая фиксированное время для обеда каждый день. Однако я нахожу это проблемой, потому что это снижает гибкость и затрудняет координацию с расписанием коллег и друзей. Я хочу что-то, что:
- Берет идеальное время, самое позднее возможное время и самое раннее возможное время
- Заглядывает вперед на фиксированный период времени (например, следующие 14 дней)
- Работает вокруг любых существующих бронирований
- Предпочитает идеальное время, но при необходимости выбирает другое время, соблюдая самое раннее и самое позднее возможное время.
Организации становятся все более и более осторожными в отношении конфиденциальности пользовательских данных, и мой работодатель не является исключением. Единственный способ расширить возможности моего календаря — это использовать законное одобренное дополнение, опубликованное на торговой площадке Google Workspace.
Решение
Несколько лет назад я создал отдельное серверное приложение Node.js, которое решает мою проблему. Он работал на экземпляре EC2 и содержал токены для подключения OAuth к календарю и пользовательские настройки в базе данных MongoDB. У него было базовое веб-приложение для настройки. Я решил:
- Возьмите логику этого приложения и перестройте его как надстройку Google Workspace для Календаря.
- Сразитесь со своим страхом и попробуйте пройти через процесс утверждения и публикации на рынке.
Угадайте, какая из этих двух вещей заняла больше времени?
Создание надстройки Workspace
Я наткнулся на очень хороший блог команды Lucid Chart под названием 6 смертных грехов разработки надстроек для скриптов Google Apps. Я уважал большинство из них, но проигнорировал самый важный: Создание надстройки скрипта Google Apps во встроенном редакторе скриптов. До сих пор все было хорошо, но я подозреваю, что когда-нибудь пожалею об этом. Тем не менее, статье пять лет, и некоторые из основных жалоб в статье в блоге действительно были рассмотрены. Онлайн-редактор имеет большинство основных функций, которые вы найдете в редакторах, таких как VS Code, с автоматическим завершением скобок, интеллигенцией, обнаружением синтаксических ошибок и так далее.
Официальное руководство по началу работы очень хорошее, и потребовалось всего пятнадцать минут, чтобы установить работающее (довольно глупое на кошачью тематику) дополнение hello world в Google Calendar по умолчанию в моей личной учетной записи Google. Единственная проблема в руководстве: когда я начал развертывать надстройку, я обнаружил, что пункт меню развертывания отключен, пока я не выберу функцию. На самом деле в учебнике нет каких-либо автономных функций для запуска (все основано на реагировании на события в Календаре), но при нажатии кнопки запуска и выполнении общего файла сценария все было хорошо.
Надстройки рабочей области запускаются в среде выполнения скриптов приложений. Apps Script основан на JavaScript, работает в V8 и поддерживает все современные функции языка ECMAScript. Мое оригинальное приложение довольно простое. Алгоритм работает каждый день, начинает с идеального времени, а затем перемещается все дальше и раньше с шагом в пять минут, пытаясь найти достаточно места для планирования события. Я использовал Lodash и Moment, но для простоты я переписал вызовы Lodash, чтобы использовать встроенные вызовы ES, и удалил ссылки Moment, придерживаясь целочисленной арифметики для значений меток времени начиная с эпохи.
Пользовательский интерфейс построен с использованием «карточной» системы. Гибкий интерфейс использует цепочку методов для создания из разрешенных компонентов кроссплатформенного пользовательского интерфейса, который будет работать в рамках ограничений боковой панели Workspace. Мне нравится быть ограниченным в пользовательском интерфейсе. Человеку, не имеющему таланта в визуальном дизайне, очень полезно придерживаться шаблонов, которые будут «просто работать».
Интеграция с календарем
Платформа Apps Script поддерживает стандартные общедоступные API Google Workspace в качестве расширенных API. Существует минимальная документация о том, как получить доступ к расширенному API, но есть и базовые API, которые намного проще в использовании. Я начал с базового API календаря. Никаких дополнительных шагов в коде для этого не требуется, кроме вызова встроенного класса, например:
Выполнение вызова, подобного приведенному выше, требует настройки правильной области действия OAuth. Они находятся в файле метаданных с именем appsscript.json в проекте Apps Script. Мой блок областей выглядит так:
Базовый API почти удовлетворил все мои потребности. К сожалению, в возвращаемых им урезанных объектах событий отсутствовал один очень важный для меня атрибут — поле, показывающее, отметил ли пользователь существующее событие как «занято» или «свободно». Пользователи Календаря Google часто добавляют «бесплатные» мероприятия на весь день, чтобы другие, записывающиеся на них, знали, что они все еще могут использовать это время. Например. У меня может быть мероприятие на весь день под названием «День рождения мамы», помеченное как бесплатное. Оно должно напоминать мне о необходимых вещах в такой важный день, но я не собираюсь блокировать добавление других событий в этот день.
Одним из обязательных условий использования расширенного API календаря является преобразование проекта Apps Script Google Cloud Platform (GCP) по умолчанию в стандартный проект GCP. Это также является необходимым условием для публикации проекта, поэтому пришло время заняться этим.
Преобразование в стандартный проект GCP
Как я упоминал ранее, начать работу с Apps Script можно быстро и легко. Частично это связано с тем, что он автоматически создает особый вид проекта GCP в фоновом режиме. Этот проект заблокирован и не работает как обычный проект GCP, поэтому к нему невозможно добавить стандартные API Google, такие как полный API календаря или API торговой площадки Workspace.
Я следовал документации Google по переходу на стандартный проект, начав с создания нового пустого проекта. Суть в том, что когда вы переходите по ссылкам из среды Apps Script, вы, как правило, переходите к специальному проекту по умолчанию. Мне было интересно, почему я все еще не мог начать настройку экрана согласия OAuth для моего нового проекта, когда я понял, что сижу в проекте Apps Script по умолчанию с очень похожим именем!
Использование расширенного API календаря ничем не отличалось от добавления любого другого API в проект GCP. Я включил его из библиотеки в консоли API в своем новом проекте, а затем смог совершать вызовы к полному API из скрипта приложений, например:
Процессы утверждения
Есть два шага, чтобы получить одобрение публикации листинга на торговой площадке Workplace. Первый — это общая проверка OAuth, а второй — одобрение публикации и перечисление фактического дополнения.
Google ведет список областей действия OAuth, некоторые из которых классифицируются как конфиденциальные. Поскольку календари пользователей считаются конфиденциальной информацией, области OAuth для доступа к ним и управления ими являются конфиденциальными. Конфигурация согласия на вход в систему GCP OAuth предоставляет мастеру, через который можно пройти, чтобы предоставить Google информацию, которая затем проверяется людьми. Они в основном следят за тем, чтобы вы не пытались вытащить быстрый и украсть данные без ведома пользователя.
В первый раз я получил одобрение очень быстро, но когда я отправил листинг торговой площадки, он был отклонен, потому что мое приложение не работало. Это не сработало, потому что я не настроил необходимые области OAuth для календаря в консоли GCP. «Но как же вы могли этого не заметить?», — скажите вы. Сложность надстроек Apps Script заключается в том, что они используют область действия OAuth, определенную в метаданных appsscript.json, а не области действия в конфигурации экрана согласия OAuth в GCP. Но… это работает во время тестирования, но не работает в опубликованном приложении. Необходимо вручную настроить области GCP, чтобы они соответствовали списку в appsscript.json.
Я скопировал и вставил области из appsscript.json в конфигурацию согласия GCP OAuth и повторно отправил.
Одним из требований для процесса утверждения является загрузка на Youtube видеозахвата экрана, демонстрирующего назначение областей действия OAuth. Моя демонстрация показала это, но через пару дней она была отклонена, потому что рецензент не смог увидеть идентификатор клиента OAuth. Мое приложение не управляет отображением идентификатора клиента: URL-адрес обратного вызова для надстройки Workspace создается приложением Workspace. Календарь генерирует очень длинный URL-адрес, и если идентификатор клиента не отображается в первых 100 или около того символах:
Я смог получить идентификатор клиента для отображения, выбрав некоторый текст из URL-адреса и используя сочетание клавиш в конце строки, чтобы перейти к концу. На этот раз после того, как я повторно представил его, он был принят.
Я воспользовался советом статьи о шести смертных грехах и заранее подготовил все свои маркетинговые активы для листинга на рынке. Минимальные требования разумны, я собрал:
- Карточка для листинга (для этого я использовал шаблон визитки Canva)
- Иконки 32 и 128 пикселей квадратные
- Скриншот работающего приложения (раздражающие размеры надстройки календаря, но я добрался туда методом проб и ошибок)
- Длинные и короткие описания
- Условия использования — я использовал найденный шаблон, вырезав все лишнее
- Политика конфиденциальности — я создал минимальную из них для более ранней серверной версии.
Одобрение пришло через пару дней.
Поскольку у меня есть только день или два в неделю, чтобы работать над своими сторонними проектами, а время утверждения обычно составляет не менее 24 часов, мне потребовался месяц, чтобы пройти весь путь с самого первого OAuth. доведение до окончательной публикации. Стоит иметь в виду, если вы спешите!
Следующие шаги
Мне удалось установить надстройку в моей учетной записи Google для повседневной работы, поэтому теперь я буду тестировать ее, чтобы убедиться, что она работает без сбоев. Операторы ведения журнала из среды Apps Script появляются в консоли ведения журнала GCP, и у меня есть очень подробные инструкции по отладке для моего алгоритма: время для некоторого мониторинга!
