先日からとても久しぶりにGoogle Apps Scriptを使ってアプリケーションを開発しています。

こちらのアプリ自体は、YoutubeのsbcオープンマイクやポッドキャストのSBCast.のリンク一覧を表示するツールで、もともとはPythonでデスクトップアプリとして作っていたんですが、あまりにも取り回しがしづらいなということで、今回Webに移行しました。

今回のアプリケーション開発についてはお試しライブ配信を行っており、 Youtubeで開発の様子を見ることができるようになってます。

一応毎回一時間前後を目標に。配信を行うのは作業内容を記録に残すという意味もありますが、一日の予定時間を大幅に超過しないようにというガードレール的な役割を果たしてたりもしています。

また。やってみて気づいたのですが、言葉遣いを丁寧にしたり、独り言で作業内容を説明するクセがつくなど、今何をやろうとしているのかを明文化できるという効果もあるなと感じました。
とりあえず一区切りついたあと、そのうちどこかでダイジェスト動画でも作れたら面白いかななんて思ってたりしてます。
プログラミングライブ配信・SBC.コンテンツサーチツール - YouTube

YouはどうしてGoogle Apps Scriptを？

さて本題。そもそもなんで今回Google Apps Scriptを使ったのか？
Google Apps Scriptはほかの実行環境と比べて、YouTubeなどのGoogle系サービスのデータを非常に扱いやすいという利点があります。

サービスとしてYouTubeなどのGoogleサービスを追加すると、Google Apps Scriptの組み込みライブラリのような感覚でYouTubeのデータを処理することが可能となります。

今回はSBC.オープンマイクの番組情報をYouTubeから得たいと思ったため、Google Apps Scriptを使用しました。RSSの取得だけで一覧表示ができるSBCast.の方は、どこの環境でやったとしても問題なく表示できますしね。

Google Apps Scriptと従来のJavaScript開発の違い

Google Apps ScriptをNodeJSやElectronなどでのアプリケーション開発と比較すると、大きく違う点は次の通り。

使用できるJavaScript以外のリソースファイルがHTMLのみ(CSSやPNG画像を同じサーバにアップロードして参照するみたいなことができない)。
最終的な実行・デバッグ環境はGoogle Apps Script上のみ
HTMLはGoogle Apps Script独自の処理が追加されたHTMLの中にiframeで埋め込まれて表示される。そのため、HTMLタグの解釈など、一部単純にHTMLファイルを表示した場合と動作が異なることがある。
テストフレームワークがない。基本的にはNodeJSなどのJavaScript開発に用いられるJestなどのフレームワークも使用することができない(はず・・・)。
Claspというツールを使ってローカル環境との同期は出来る(ローカル環境ではファイルの編集やGitでのファイル管理などが行える)
グローバルレベルの変数および関数は、たとえファイルが違っていても名前を重複させることができない。
使用できるファイルの拡張子がjsではなくgs

使用できるJavaScript以外のリソースファイルがHTMLのみ

特にこれについてはなかなか厄介で、CSSを使いたい場合は何らかの方法でHTMLファイルにstyleタグで組み込む必要があります。
Javascriptも、ファイル自体を上げてしまうとサーバー上で実行されるファイルとして認識されてしまうので、HTMLファイル内でJavaScriptを実行したい場合は、これもまたHTMLファイルにScriptタグで組み込む必要があります。

実行・デバッグ環境はGoogle Apps Script上のみ

実行やデバッグの環境が、Google Apps Scriptのエディター上のみになっているのも大変な所でした。
Google Apps Scriptのスクリプトエディタは入力補完機能こそなかなかに優秀なのですが、デバッグ中の変数のモニタリングや、条件付きのブレークポイントなど、Visual Studio Codeなどで割と当たり前にある機能がないというのも、つらいところでした。
幸いコンソールへの出力はある程度Visual Studio Codeなどと同様に動くので、コンソールログなどを使ったテストなんかも適宜実行していく必要があります。

テストフレームワークが存在しないという難点もそうですが、色々な方法を身に付けておいて、その時その時で最適な手法を使ってデバッグしたり、プログラミングしたりするというスタイルが重要になりますね。

※ テストについては昔はGASUnitというものもあったそうですが、今見たらアーカイブになっておりプロジェクトをIDで参照することができなませんでした。

グローバルレベルの変数および関数名が重複できない

これも地味に厄介な仕様です。

例えばテスト用の関数を作成するときなど、A.gsとB.js両方にtest()という関数を作成することができません。
特に大きめなプログラムを書こうと思うと、この問題は結構厄介になってくるんではないでしょうか(まあそもそもGoogle Apps Scriptでそんなに大規模なプログラムを書くなという意味かもしれませんが)？

自分のGoogle Apps Script開発環境

自分の場合、PC上でファイルの編集やコミット作業を行うため、GoogleのClaspというツールを利用しました。

claspを使ったGoogle Apps Scriptのソース管理を試してみた | DevelopersIO

このツールはプロジェクトを指定して、Google Apps Script上のファイルをPCにダウンロードしたり、その逆ができるツールです。

このため、サーバー上の処理は入力補完機能の強いGoogle Apps Scriptのスクリプトエディタ上で作成し、クライアント上の処理やGitへのコミット作業はローカルで行うというような使いわけが可能になります。

クライアント上で動作する処理については、Pugで作成しclasp pushを行う直前にHTMLを作成するようにします。
そしてこのとき、styleタグの中にCSSファイルを、scriptタグの中にJavaScriptファイルを埋め込むようにすればOK。

doctype 
html(lang='ja')
  head
    meta(charset='utf-8')
    style
      include index.css
  body
    ... 中略 ...
    script 
      include index.js

忘れないようにPowerShellスクリプトを書いて、「clasp pushを行うときは直接clasp pushコマンドを使わず必ずこのファイルを実行する」みたいなルールにしておけば良いでしょう。

npx pug .\res\index.pug --pretty
clasp push

なお、ここでPugファイルで読み込むJavaScriptはGoogle Apps Script上にアップロードされないようにする必要があります。
.claspignore というファイルをプロジェクトのルートフォルダに作成し、その中にJavaScriptファイルの名前を指定しましょう。

クライアント上で動作するスクリプトのデバッグ

わたしの場合、このプロダクトは元々オープンソースにする予定だったので、CodePen上でJavaScriptの検証を行い、それをコピーする形で対応しました。

このため、今回のプログラミングでは特にJavaScriptとしてのテストは行っていません。

オープンソースにできないプロダクトなどでは、WebMakerを使ったり、ローカルでのテスト環境を構築するなど、適宜対応するとよいでしょう。

サーバー上で動作するスクリプトのデバッグ

Google Apps Scriptには前日のとおりテストフレームワークというものがないので、それぞれのサーバースクリプトファイルにtest○○という関数を作り、その関数の最後にTest OK|NGという文言が表示されるようにしています。

function getRSS() {
  // 本来の処理
}

function testSCGetRSS(){
  const rss = getRSS();
  let success = true;
  console.log("getRSS() Finished");
  console.log(`Test ${success ? "OK": "NG"}`);
}

Google Apps Scriptの全体的な動作を確認するにはいちいちデプロイを行わねばならずとても面倒なので、関数単位で気軽に動作の確認ができると非常に楽ですね。

とりあえずGoogle Apps Scriptにあまり過度な期待はするな

とりあえず今回使ってみて思った感想としてはこれに尽きます。
Google Apps Scriptにあまり過度な期待はするな。「これこれこんな、大きなことがやりたい」と思ってもGoogle Apps Script上では制限があって動かせないということは割とありそうです。

また、HTMLにCSSやJavaScriptをマージしなければいけないという都合上、どうしてもアプリの規模はちっちゃいなものになってしまいがちでな感覚です。

なのでとにかく、過度な期待はするな。でもこれでやった方が明らかに楽というシチュエーションもあるにはあるので、その時はためらわず使え。といったところでしょうか。

Discussion