Google Apps Scriptを取り巻く環境のおさらい

claspを利用した開発がそれなりにまともに動くと言ってよい状況になりそうなので、前提の情報をまとめておく。

これまでのApps Scriptの開発はパッチワークだった

以前 Google Apps Script + Node.jsで簡単なツールを作ってみた - あーありがち(2015-10-31) や Google Apps Script開発をもうちょっとモダンにしてみる - あーありがち(2017-05-27) で取り上げた際には以下のような状況だった。

  1. 実行は Script Editor 上で手作業で行うかそれを実現する Web API を publish しておく
  2. ログは Script Editor 上で表示するか BetterLog - Google Apps Script Examples などを利用して Spreadsheet 上で確認する
  3. Drive API を利用して Standalone Script を local <-> remote ( Google ) で同期が可能
    • いわゆる local 開発が可能と言われていた部分はここ。この local 開発の成果物を VCS で管理できるという話
  4. テストの自動化 は 1 と 3 を組み合わせて local 開発しつつ remote でそのまま動かす Home | QUnitGS2 のようなアプローチか、リンク先で挙げたように stub/mock しまくるかのいずれか
  5. 4 をどこまで頑張るかは置いておくとして GitHub ポチーで merge してリリースすることはできる
  6. GAS側のバージョン（Herokuのdeployment IDのようなもの）管理は手動

なんとか、あれとこれを組み合わせればできんことはないですよ、というレベル。しょっちゅうやっているならともかく、たまにしかやらないとまぁ忘れてしまうし、手間が掛かる割にそこまでよくなっていないようにも見える。

結局、手元でやりたいことの多くは API アクセスではなくて純粋なロジックの部分だけだったりするのでそこには Node.js 流の開発手法を持ち込みたいけど、いざ実行して確認するためには GAS 固有の手法もちゃんと頭に入れた状態で行う必要があって、やってることはそんなに複雑でもないはずなんだけど妙に頭のリソースを使うものになってしまっていた。

※ また Google Apps Script開発にstaging環境を用意してContinuous Deployment - あーありがち(2017-06-19) で説明したように、production と staging などの情報をいわゆる普通の Web ホスティングのように環境変数で設定するようなことはそんなに簡単じゃないので、逆に CI までその情報を引っ張ってきて CI 上でどうにか頑張って判別して前処理を行うなどの涙ぐましい努力が必要だった。この部分は Cloud Build を利用することで多少マシにはなる。また Cloud Build を前提にするのであれば、環境変数しか利用手段のなかった秘密情報の部分については Secret Manager を利用することでかなり管理しやすくなる。これは Apps Script 周りの話ではないが、Google のインフラ全体が改善されたことで得られたメリットなので補足として挙げておく。参考は あーありがち - GCPのサービスアカウントの鍵を作って持ち出す必要がなくなった

Apps Script APIが登場した

2018年頃の話だったかな。

これからは clasp やでぇ、試してみたでぇという話で溢れかえった。

実際にはツールとしての clasp 以前の話として API が追加されていて、そっちが重要になってくる。大きく変わった部分は以下の二つ。

  • Apps Script API が登場し、Apps Script Dashboard というもので Apps Script の情報を俯瞰できるようになった
  • Apps Script Project というリソースを整理し、これを GCP Project と紐づけることで他のアプリと同じように Stackdriver で実行の状況を管理できるようになった

Apps Script API  |  Google Developers

これまでは Apps Script の情報を取得するのに Drive API しか使えなかったため、Apps Script だけを抜き出した画面などは存在しなかったが、Apps Script API の登場でだいぶ管理しやすくなった。

また GCP Project と紐づけることができるようになったことで、これまで Script Editor 上でしか確認できなかったログの情報、エラーの情報を他の GCP Project と同じように Stackdrive で管理できるようになった。これは非常に大きい。やっとまともにログを扱えるようになったと言っていい。

加えて script の run が API で可能になった。つまり Web API の publish という無理やりな技は不要になった。

そしてclasp

この Apps Script API を利用する CLI として clasp が登場した。これまでバラバラだった

  • script の読み書きとそれに必要な credentials の取得
  • script の実行
  • script の GAS 上でのバージョン管理
  • project の deploy ( add-on として配布できるようにするとか )

などがすべて手元の CLI から可能になっており、開発体験は非常に良好になったと言える。

加えて clasp push の際には grant/ts2gas: A function that transpiles TypeScript to Google Apps Script. を利用した TypeScript から Apps Script への変換も自動で行われるようになったので、clasp を利用した Apps Script の開発はモダンな書き味での読み書きを提供してくれる。

※ ついでになってしまうが 2020年に V8 runtime が登場したことにより、Script Editor 上でもそのままモダンな書き味で Apps Script を読み書きできるようになった。Script Editor 自体のシンタックスハイライトなどの対応レベルはまだ改善の余地があって、それは2021年に行われるようだが、ts2gas が ES3 に変換を行うことで Script Editor 上では非常に古めかしく刺々しいコードになってしまうという問題はいずれ解消されるかもしれない。（個人的には ts2gas を使わない方法にしてしまう方がよいと思っているのであまり関係ないが。）

cf. Apps Script’s new V8 runtime | Google Cloud Blog

手っ取り早くgcloudコマンドでGoogle Apps Scriptの出力を扱う準備

Logger APIはツラカッタ

Google Apps Script には Script Editor もあるし、デバッガもついているし、G Suite が使えれば無料で使えるし、Time-based Triggerもついてるし、かなりできるやつではあるんだが、真面目に使おうと思うといろいろやっかいな問題を抱えていた。

その一つがログ、特にちょっとでも大きめな、例えば1画面に収まらないデータを扱おうと思うと途端に面倒くさくなってしまう。

自分が気になっていた Logger API の問題は以下のようなものだ。

  • Object を食わせると謎の独自 Stringify を行う
  • 一つのログが大きすぎると勝手に端折ってしまう

結構しんどい。

時代はStackdriver Logging

で、かつては Spreadsheet に吐くとかいろいろ工夫がなされていたわけだが、今はありがたいことに標準で Stackdriver Logging に対応している。

Stackdriver Logging for Google Apps Script is now available | Google Cloud Blog

日本語の公式発表が見つからないので英語の方のリンクを貼っておく。

使い方

特に事前準備は必要なくて、コード上の記法が増えただけと言ってよい。

  • これまでもあった Logger.log() はそのまま Script Editor 上のログに
  • console.log() は Stackdriver Logging のログに

それぞれ送られる。普段 Google Apps Script は書いていないが JavaScript を書いているという人が何気なく使うと Stackdriver Logging の方へ送られるという寸法だ。1

料金の話

基本的には無料で使える。

というのも、GCP プロジェクトとして課金アカウントに紐づけてなくても使える からだ。容量の話などを気にしている人もいたが、そもそも課金アカウントと紐付いていないと請求はされないわけで、業務でその辺の管理をしっかりやっていくぞという場合でもなければ気にする必要はないと思う。

でもWeb UIはダルい

本題はここから。

常に 20" 以上のモニタを広く使ってコード書いてる人にはあまり関係ないかもしれないが、13" クラスの画面と terminal が主戦場の人間にとっては全部 Web UI というのは暴力でしかないし、実際に取得できた JSON のデータを解釈してどう整形しようか考える段階では普通に手元のエディタで処理したいわけですよ。

そこで Stackdriver Logging のデータを gcloud logging read することにする。

gcloudコマンドの準備

Google Cloud SDK のインストール | Cloud SDK のドキュメント | Google Cloud

自分の mac にどうやって入れたかは忘れたけど、たぶん最新版を inteactive に入れたような気がする。2

  1. gcloud コマンド入れる
  2. gcloud auth login
    • ブラウザでログイン
  3. OAuth2 の認可を明示

これで自分が owner になっているプロジェクトのログは自由に見れるので3、

実際にreadする

Command Line Interface | Stackdriver Logging | Google Cloud

にしたがって

gcloud logging read --project <projectId>

と打ってあげればログを terminal で閲覧できる。快適。

default formatは実はYAML ?

Stackdriver Logging に JavaScript Object を渡すといい具合に jsonPayload という形でログが残る。これは非常に便利な機能なんだけど、gcloud logging read で取得できるログはどうも標準では YAML 形式っぽい。

JSON のデータが取得できると思って目grep しているとスルーしてしまうので注意が必要。または

gcloud logging read --format json

すれば JSON でログを取得できるので、こっちの方が目の引っかかりはよいかも。4

tailできない問題

もう一つ、gcloud logging サブコマンドでは tail -f のようなことはできない5ので、そこら辺は –limit と組み合わせるなりする必要がある。

payloadだけクレ

jq使え。

jq

| jq '.[].jsonPayload'

みたいな感じ。

実は jq の出力はそのままだと正しい JSON にならない。もうちょっと頑張って正しく JSON にしたい場合は jq -cとawkでndjsonを本来のJSONにする - あーありがち(2018-11-13) をどうぞ。

感想

なんでも揃ってるクラウドインフラの中に G Suite があるのマジで強い。でも Advanced Service オメーはダメだ。リファレンスをください。API とのマッピングどうなってるのかわっかんないよ。

  1. 実は自分が久しぶりに GAS を書いたら console.log() を使っているのに Script Editor のログが表示されずに悩んだ。 ↩

  2. 自動化する場合は versioned archive を使うといいんだけど、今回の話題と違うので割愛。 ↩

  3. 個人だとこんなもんで十分だけど、業務の場合は IAM Role の設定で悩んでください。 ↩

  4. JSON は手で書くのはつらいが、読む分にはそうでもない気がする。YAML は逆に小さいうちはとても書きやすいがでかくなると目で追うのがつらくなってくる。 ↩

  5. App Engine の log は可能 ↩

タスクマネージャが役に立たないときのために

※ CPU を食いつぶしてタスクマネージャが動かない場合のことじゃありません。タスクマネージャの表示する情報だけでは問題解決に役に立たない場合のことです。

タスクマネージャは Windows を管理するうえで最も基本的なツールの一つだと思うんだけど、これ、結構役に立たないことが多い。プロセスという考え方が Un*x と違うからなのか、結局誰が悪さしてるのかが分からないケースが以前より増えているような気がする。1

ということで困ったなと思っていたら以下のようなツールがあることを知った。いやはや、もう Windows のことは分からなくなってきたなぁ。まぁ一人でなんでもできるわけはなく、どこかに力を入れればどこかはもうついていけなくなって当然なんだけど。

話がそれた。

tasklist

Windows XP 以降、標準で使えるコマンドラインツール。

＠IT：Windows TIPS – Knowledge：svchost.exeプロセスとは？

これはWindows XPおよびWindows Server 2003に用意されているtasklist.exe（タスクの一覧を表示させるコマンド）を使った例である。

Windows 2000の場合は、サポート・ツール（インストールCD-ROMの\SUPPORT\TOOLSフォルダに含まれるツール集）に含まれるtlist.exeを使えば同様の情報を知ることができる。

と書かれているので、2000 でも若干制限はあっても使えるらしい。

もう今どきクライアントマシンは Windows XP 以降と考えて差し支えないと思うので、どんどん使ったらいいんじゃないかと思った。

ちなみにこんな使い方をしてる人もいて、

バッチ（TASKLISTコマンド）でWindowsのプロセスを監視 - Windowsを使い倒せ

なるほど ps | grep と考え方は基本的に同じですな。

Process Explorer

Process Explorer

XP 以降でインストール不要でいきなり動くツール。Sysinternals のシリーズなのでその筋の人にはとっくに有名だったんだと思う。コマンドラインアプリではないので組み合わせて使うのは難しいと思うけど、その分ビジュアルで分かりやすそう。

本気の Windows 管理者ならこいつを持ち運ぶくらいのことはした方がいいのかも。

  1. 特にアンチウィルスとぶつかっている場合など。 ↩

Debian でパッケージを欲張りすぎてハマる

※ 例によって過去日記。

lenny がいつまでもリリースされないので業を煮やして testing(lenny) のパッケージを追加で使うことを試みた。毎回どこでその情報を見たのか忘れてしまうんだけど、

Twitter / Takeru Naito: @wtnabe [testing や unstabl …

今回も教えてもらった。

AptGet - Debian GNU/Linux スレッドテンプレ

で、利用できるパッケージを追加して apt-get update してみたが、今度は

Problem with MergeList

と言われて止まる。何事かと思ったが

Fulldigit - [Debian FAQ]更新リストが多すぎてapt-get updateが失敗する

によるとメモリ不足？ MergeList のサイズが大きくなりすぎないように制限を付けてやると update できるようになる。

なんか確か libfreeimage を入れて OpenFL を動かそうとしてたっぽいけど、影響範囲がでかすぎて結局これはやってみただけで戻してしまった。

OSX 10.5 の nfs client でハマる

10.3 のときも Linux の nfs client でも問題なかったんだけど、OSX の nfs client でどうしても bad net address で mount できないサーバが出てきた。

いろいろやってみたところ、hostname が数字から始まっていることだけが違いっぽい。試しに hostname ではなく IP address で mount してみたら問題なくイケた。

そうかそういうことなのか。

実践実用Perl

著者からいただいちゃったのでレビューを書かねばなるまいて。思ったよりボリュームがあるのでびっくり。文字がちょっと大きめってのもあるけど、これは見やすくてよい。

しばらくお待ちください。。。

サントリーオーナーズカスク

ほう。

カスクはうまいよね。でもサントリーのカスクに金出すのはもったいないというか。。。カスク置いてあるバーに行けって話ですよ。こういうプッシュの仕方って基本的には個人ユーザー対象なんだろうけど、カスクなんか飲めないでしょ、フツー。ただのブランド戦略か？

ひょっとしてサントリーって今までカスクなしの瓶出荷のみ？ そんなわけないよねぇ？ 詳しい人の blog をそのうち眺めれば何か分かるかもしんないな。

ruby-list が荒れとる

MoonWolf 台風が吹き荒れている。他人を簡単に馬鹿呼ばわりする馬鹿がコミュニティにとって害悪ってのが分からない人なのかな？ こういうのは年齢に関係なく、ほんとに素で分からない人がいるからなぁ。

ただまぁなんだ。いいね、やろうぜ！的な流れには Ruby 界隈はならないんだな。必ずブレーキを掛ける。ダメ出しする。そして自分はアクションは起こさないって人はやはり多い。ように見えちゃう。1Python コミュニティにパワーを感じ、Ruby コミュニティに感じないのはこういうところかな。（実際の行動力という意味ではない。）

なんですかね。ちょっと古い日本的な感じなのかなぁ。そゆとこは「面白くねー」に共感できる。まぁ頑張りは認めるけど（なぜあそこまで頑張れるのかは理解できない）、コミュニケーションをもっと頑張りましょうってことだろうか。間違ったこと言ってるわけじゃなし。視野を広く冷静に対処できれば、と思うと実に惜しい。

あとやっぱ中心の方に居る人は寄付金で Ruby だけで生活できる程度にならないとダメなんかねぇ。まだ日本で実現するのは難しいと思うけど。やっぱフルタイムで参画できるかどうかって大きいもんな。本業がテンパるとボランティアの方はすぐにペース落ちざるを得ないもの。あと大事なのは「開発者」じゃない「デキる人」がコミュニティに参加できる体制というか環境というか体質が要るよねぇ。マネージャというか潤滑材になれる人。もちろん Mozilla Japan みたいに開発の邪魔になるようじゃ困るけど。

うーん。

難しいよね、コミュニティって。だからできるだけ運営サイドに入りたくないのよね。

  1. まぁ少なくとも MoonWolf 氏くらいに頑張れる人はそうはおらんわな。 ↩

Software Design 2004/11 の表紙から WebDAV についてグチ

Software Design 2004/11

久しぶりに買っておくか。なんか LL Magazine のようなラインナップになってる。

しかし、この表紙に見える「WebDAVで簡単！HTTPベースのファイル共有術」てのは、ちょっとそろそろどうにかした方がいいんじゃないかと。

WebDAV はいい加減Windows 用のクライアントが貧弱すぎてせっかくの WebDAV を活かしきれないってのが声高に言われていいんじゃないかなぁ。ロックもできないんじゃ SMB 共有と何が違うねんて話になりませんか。Windows しかいなくてロックしない環境なら SMB で十分だし、インターネット越しに利用したいなら今度は SSL の方の知識がないと怖くて使えないし、それって WebDAV 特有の話じゃない。

WebDAV って以前はすごい期待してたんだけど、なんか今は半端な感じが拭えないです。流れとしては Apache 2 で Subversion と連携ってことになるんだろうけど、mod_encoding がねぇ、いつでも Apache 2 の最新に追随できる体制じゃない感じだし。日本語ファイル名禁止にできる「分かる人の現場」ならいいんだけど、普通のところはそういうわけにいかないし、Windows の Webフォルダじゃ mod_encoding の有無に関わらず問答無用で日本語ファイル名を無作法に作ろうとするから結局 mod_encoding 頼みにならざるを得ない。てゆーか Apache 2 はいつになったら安心して使えるのかな。PHP 5 が安定したら？ 文字コード問題はどうなったんだろう（古いか？）

むずいんですよ。WebDAV を実現するだけなら簡単、でもみんなが気持ちいい運用を実現するのは難しい。ツーカーで話の通じる仲間内なら SSL さえ分かっちゃえばいいんだろうけど。

オーバーヘッドがどれくらいになるか分からないけど、共有したいだけなら工夫してウプロダ作るって手もあるしねぇ。まー自分はそんなことする気ないけど、ほんと、WebDAV 界隈の人って Windows の WebDAV クライアントの貧弱さが気にならないんですかねぇ？

ポップアップ広告

http://www.zdnet.co.jp/news/0311/11/nebt_12.html

IE にポップアップ広告遮断機能がつくかも、って例の XP 搭載版のみの話かな？ ポップアップ + ページ上下というものすごい畳み掛けっぷりだった isweb も最近ポップアップ広告をやめたし、そろそろポップアップ広告は減ってくるのかな。個人的にはもうずっとポップアップ広告を開かないブラウザなのでこれが一般的にどういう影響として出てくるのかよく分からないんだけど。

ポップアップ広告なんてうざいだけで広告効果出てないんじゃないんすか？ Web 広告は TV CM みたいに見る側の意識を分断する形じゃなくて、読み手の求めるコンテンツの中に巧妙に埋め込まれる形じゃないとダメだと思うんだけどなぁ。

そうなると、コンテンツプロバイダの内部セクションとして広告戦略を練る部隊がいないとダメなんだよね。新聞広告とか雑誌広告の形から模索してユーザーの行動を巧みにコントロールする仕掛けがないと。

保存料とか合成着色料がどんなものかよく分からない

ファミマでサンドイッチを買った。そこの棚に大きく保存料や合成着色料は一切使用していない、という趣旨のことが書かれていた。ほぉ。サンドイッチは一度気づいてからずっと気になっているが、ものすごい種類の添加物が入っている。「そうか、あれが減ったのか」と思い買ってみた。

減ってないな。ということはここに書かれているのは天然着色料だから大丈夫です、という意味なんだろうか。まぁそう言われれば確かにそうなのかもしれないが、なんだか腑に落ちないと思うのはきっと自分だけではないはずだ。pH 調整とかって天然なんですか。ほんとですか。「合成」って言葉がひょっとしてマジックワードなのか？ 恰好の隠れ蓑になっているのか？ 保存料だってよく考えたら厚生省（今は厚生労働省か？）が保存料と定義していないものなら使ってたって保存料と謳う必要ないかもしれんしなぁ。厚生労働省のサイトはちゃんとチェックしろってことか？

About

例によって個人のなんちゃらです