Работя четири дни в седмицата на „истинска работа“ и прекарвам около един ден в седмицата в решаване на проблеми, които ме интересуват, с малки софтуерни приложения. „Сглобявах набор от инструменти“ за бързо надграждане срещу архитектурни модели, които намирам, че продължават да се появяват в малки приложения. Технологията, която избирам, трябва да реши тези проблеми:

  • Искам да плащам само за това, което използвам (мащаб до нула)
  • Нямам много налично време за учене или изграждане (без стръмни криви на учене без значителни спестявания на време)
  • Нямам време за дейности по поддръжка (без корекции на сървъри, автоматизирано мащабиране)
  • Не съм добър UI дизайнер или фронтен инженер (системите за проектиране са страхотни)

Отдавна се интересувам от използването на една от големите платформи за продуктивност в офиса за изграждане на вградена добавка. За соло разработчик това е безпроблемно: платформата се грижи за изискванията по-горе и когато платформата има пазар, дори има готов за работа канал за разпространение, който да я изведе на пазара! Единствената истинска причина, поради която съм се съпротивлявал досега, е страхът от забавянето на процесите на одобрение на платформата и необходимото обезпечение. В тази история ще обясня как изпитах страха и въпреки това го направих 😀. По-долу е списъкът на продукцията за JIT Time.

Google Workspace

„Google Workspace“ е последното име за продукта, известен преди като GSuite, известен преди като Google Apps. Gmail е частта от пакета, с която повечето хора са запознати. Той също така включва Календар, Google Диск и подпакета Google Документи. Използвам Workspace в моя собствен домейн за имейл, чат и календар за моето семейство. Ние също го използваме „в ежедневната си работа“ като наш основен пакет за продуктивност в офиса.

Google Workplace има „пазар“, където потребителите могат да намерят и инсталират добавки, които разширяват функционалността на всички приложения. По-голямата част от съдържанието на пазара е интеграция с популярни приложения на трети страни като CRM и други инструменти за производителност, но има и специално създадени добавки.

Бизнес проблемът

Заетите хора трудно намират време на работа за редовни нужди като обяд, ходене на фитнес или просто отделяне на време за размисъл. Лесно ми е да се появя в понеделник само за да открия, че благодарение на други хора, които искат срещи, нямам време за обяд през следващата седмица. Някои хора се справят с това, като определят фиксирано време за обяд всеки ден. Намирам обаче това за проблем, защото намалява гъвкавостта и затруднява координирането с графиците на колеги и приятели. Това, което искам, е нещо, което:

  • Отнема идеално време, най-късно възможно време и най-ранно възможно време
  • Гледа напред за определен период от време (напр. следващите 14 дни)
  • Работи около всички съществуващи резервации
  • Предпочита идеалното време, но ще използва различно време, ако е необходимо, спазвайки най-ранните и най-късните възможни часове

Организациите стават все по-предпазливи с поверителността на потребителските данни и моят работодател не прави изключение. Единственият начин, по който мога да разширя поведението на своя календар, е като използвам легитимна, одобрена добавка, която е публикувана в пазара на Google Workspace.

Решението

Създадох самостоятелно приложение Node.js от страната на сървъра, което решава проблема ми преди няколко години. Той работеше на екземпляр EC2 и държеше токените за OAuth връзка към календар и потребителските предпочитания в база данни MongoDB. Имаше основно уеб приложение за конфигурацията. Реших да:

  • Вземете логиката от това приложение и го преархитектирайте като добавка на Google Workspace за Календар
  • Изправете се срещу моя страх и опитайте да преминете през процеса на одобрение и публикуване на пазара

Познайте кое от тези две неща отне повече време?

Изграждане на добавка за работно пространство

Попаднах на много добър блог от екипа на Lucid Chart, наречен „„6-те смъртни гряха на разработката на добавки за Google Apps Script““. Уважах повечето от тях, но пренебрегнах най-важното: „Кодиране на вашата добавка за Google Apps Script във вградения редактор на скриптове“. Досега беше добре, но подозирам, че в един момент ще съжалявам. Въпреки това, статията е на пет години и някои от основните оплаквания в статията в блога всъщност са разгледани. Онлайн редакторът има повечето от основните функции, които намирате в редакторите като VS Code с автоматично допълване на скоби, „intellisense“, откриване на синтактични грешки и т.н.

„Официалният урок за „първи стъпки““ е много добър и отне само петнадесет минути, за да имам работеща (доста глупава котешка тема) добавка „здравей свят“ и инсталирана в Google Календар по подразбиране в моя личен акаунт в Google. Единствената грешка в урока беше, че когато отидох да внедря добавката, открих, че елементът от менюто за внедряване е деактивиран, докато не избера да стартирам функция. Всъщност няма самостоятелни функции в урока, които да се изпълняват (всичко се основава на реагиране на събития в календара), но като щракнете върху бутона за изпълнение и „изпълните“ общия скриптов файл и всичко беше наред.

Добавките за работно пространство се изпълняват в среда за изпълнение на Apps Script. Apps Script е базиран на JavaScript, работи във V8 и поддържа всички съвременни функции на езика ECMAScript. Оригиналното ми приложение е доста лесно. Алгоритъмът работи всеки ден, започва с идеалното време и след това се придвижва по-късно и по-рано на стъпки от пет минути, за да се опита да намери достатъчно място за насрочване на събитието. Бях използвал Lodash и Moment, но за да опростя нещата, пренаписах извикванията на Lodash, за да използвам вградени ES извиквания, и премахнах препратките към Moment, като се придържах към целочислена аритметика върху стойностите на времевия печат от епохата.

Потребителският интерфейс е изграден с помощта на система „карти“. Плавният интерфейс използва верижно свързване на методи, за да изгради разрешените компоненти в междуплатформен потребителски интерфейс, който ще работи в рамките на ограниченията на страничната лента на работното пространство. Обичам да съм ограничен в потребителския интерфейс. Като човек без талант за визуален дизайн е много полезно да се държите в рамките на модели, които „просто ще работят“.

Интегриране с Календар

Платформата Apps Script поддържа стандартните „публични API на Google Workspace“ като „разширени“ API. Има минимална документация за това как да получите достъп до разширен API, но има и „основни“ API, които са много по-лесни за използване. Започнах с „основния API на календара“. Не са необходими допълнителни стъпки за това в кода освен извикването на вграден клас, напр.:

Осъществяването на повикване като това по-горе изисква да бъдат конфигурирани правилните OAuth обхват(и). Те се намират във файл с метаданни, наречен appsscript.json в проекта Apps Script. Моят блок за обхвати изглежда така:

Основният API почти задоволи всичките ми нужди. За съжаление съкратените обекти за събития, върнати от него, липсваха един наистина важен атрибут за моите цели — полето, което показва дали потребителят е маркирал или не съществуващо събитие като „заето“ или „свободно“. Потребителите на Google Календар често добавят целодневни събития, които са „безплатни“, така че другите, които правят резервации, знаят, че все още могат да използват това време. напр. Може да имам целодневно събитие, наречено „Рожден ден на мама“, маркирано като безплатно. Той е там, за да ми напомня да правя необходимите неща в такъв важен ден, но не възнамерявам да действа като блокер за добавяне на други събития този ден.

Едно от предварителните условия за използване на разширения API за календар е преобразуването от проекта по подразбиране на Google Cloud Platform (GCP) на Apps Script в стандартен GCP проект. Извършването на това също е предпоставка за публикуване на проекта, така че беше време да продължим с това.

Преобразуване в стандартен GCP проект

Както споменах по-рано, започването на работа с Apps Script е бързо и лесно. Част от причината за това е, че той автоматично създава специален вид GCP проект във фонов режим. Този проект е заключен и не функционира като нормален GCP проект, така че не е възможно към него да се добавят стандартни API на Google като пълния API на календара или API на пазара на Workspace.

„Следвах документацията на Google за преминаване“ към стандартен проект, като започнах със създаването на нов празен проект. Лошото тук е, че когато следвате връзки извън средата на Apps Script, има тенденция да отидете до специалния проект по подразбиране. Чудех се защо все още не мога да започна да конфигурирам екрана за съгласие за OAuth за моя нов проект, когато разбрах, че седя в проекта по подразбиране на Apps Script с много подобно име!

Използването на усъвършенствания API за календар не се различава от добавянето на друг API към GCP проект. Активирах го от библиотеката в API конзолата в моя нов проект и след това успях да извикам пълния API от Apps Script, така:

Процесите на одобрение

Има две стъпки за получаване на одобрение за публикуване на списък в пазара на работното място. Първият е обща 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 и имам много подробни отчети за отстраняване на грешки за моя алгоритъм: време е за малко наблюдение!