月別アーカイブ: 2022年9月

academistで研究支援

クラウドファウンディングと言うと、CampFireなどいろいろなサイトがありますが、科学技術系に特化したクラウドファウンディングサイトとしてacademistというサイトがあります

academist
https://academist-cf.com/

以前、なにかのタイミングでサイトの事を知って、結構面白い取り組みだな、と思ったわけですよ。
その時に支援こそしなかった(したつもりになっていた?)ものの、登録はしていたので定期的にメールは届いていて、少額でもいいから支援をしてみようと物色していて、面白そうなものを見つけた

こういう考古学って、正直自分がやることは出来ないけど、ちょっとロマン的な感じで憧れます。

ものづくり系のクラウドファウンディングと異なり、学術系のクラウドファウンディングの場合、見返りはそれほど金銭的な価値はなく、レポートだったりZoomでの会話だったりするのでこちらは本当におまけですね。

支援すると言っても、本当に少額から開始出来るのはいいとして、この支援量で本当に支援の意味になっているんだろうか?という疑問が湧いてきてしまう。
このあたりはこういうもののクラウドファウンディングの難しさを感じますね。

ちょっと一点困っているのは、月額支援型プロジェクトに対しての金額変更方法がよくわからんのですよね。。。
ちょっと色々と分かりづらい気がする。。。

台風こんちくしょうという生産性のない恨み節

週末のご予定は?

キャンプですよ!キャンプ。
夏の思い出にと、8月に予定していたキャンプを台風が来るということで泣く泣く延期。キャンセル料を取られながらも、悲惨なキャンプになるよりは良いかと。。。
なかなかキャンプ場の予約が取れない中でようやく取った今週末!!

嫌がらせのように、台風が関東を直撃しそうです

今回の台風は、勢力的にはそれほど強くなさそう。

とは言え、完全に関東直撃コースではあるので、雨はしっかり降るんだろうなぁ
ただ、ここまでピンポイントでキャンプ予約したタイミングで連続台風となると、売られた喧嘩は買わなければいけないという謎の使命感が生まれてきているのも事実。

すでにレンタル品のキャンセル期限は過ぎてしまっているので、費用はもうかかる。
どうなるか・・・

明日、もう一日考えます・・・

シャングリラフロンティア (10)

今週は、マンガ最新刊が目白押し

腸よ鼻よの7巻

キングダム66巻

そしてシャングリラフロンティアの10巻

どれも面白いのですが、個人的な最近のHITは断然シャングリラフロンティアです

題材もそうですが、こういうバトル物は読んでいてワクワクしますね。
10巻は特に、1巻からの因縁の相手となるリュカオーンとの戦いということもあるし、様々な奥の手とも言える技が目白押し。

いや、なんというか、もういい歳なんですけど未だにこういったものを楽しめるというのは自分としてはいいな、と思います。

単純なギャグ漫画みたいなものは、だんだん読まなくなってしまっていますが、こういう熱くさせるマンガは、ホント、いいです。
いや、語彙力ないな。。。。

展開も早いので、これから先もどういった物語が続くのか、楽しみです
ほんと、少年漫画好きにはおすすめです

snyk を少し触ってみた

SecurityReportを読んだことで知った、snykというセキュリティプラットフォーム。
無料版もあるようなので、ちょこっと触ってみた

https://snyk.io/

凛々しいドーベルマンがトレードマークです。名前はPatch。

価格体系はこんな感じ。
ちょっと個人で使ってみるのであれば、Freeプランで十分なのではないかと思う。

何をセキュリティチェックやテストの対象とするのかは、結構選ぶことが出来る

基本的にはGithubなどのソース管理ツールを登録し、その中のプロジェクトを選ぶ形になると思う

せっかくなので試しに、過去にチュートリアル的に作って放置されているプロジェクトを対象に含めてみた

Code analysis ではミディアムが6件検知されているけど、問題はpackage.json。
作ってから放置されているので、そりゃ問題があるバージョンが定義されているんだろうな。

選択すると、何が問題かを教えてくれる。そこで「Fix this vulnerability」を選択する

一番下にある「Open a Fix PR」を押すと、自動でPRを作ってくれる。
ちなみに、出来ることと出来ないことはやっぱりあって、下の3つは自動では無理のようだ

expressのバージョンが変わったことがわかる。

無事に、驚異が取り除かれていることがわかります。

PRの作成まで自動でやってくれるのはいいですね。
あまり、この手のツールを使ったことがないので、snykが特別に優れているかどうか。比較という意味ではわかりませんが。。。

今回はCode analysis上は問題なかったですが、コード上での指摘も今度見てみたいですね。

自動検知設定

初回にGithubと関連付けた際に表示が出ていたのですが、snykでのチェックを自動的に走らせることが設定で出来ます

ここではGithubを選択した際の設定を表示しています。

例えば以下のような設定があります

  • 対象とするリポジトリはパブリックのみか、プライベートも含めるか?
  • インポートされたプロジェクトにセキュリティとライセンスの問題がないかどうか
  • 新たな脆弱性や既知の脆弱性を検知した際に自動的にPRを作るか
  • 脆弱性を修正するために、最新のベースイメージを使用するようにDockerfileを更新するPRを作るか

自動的に色々と検知してくれるのはいいのですが、そのたびにテストが走ることを考えると、それなりの規模で開発をされている方ではやはりFreeプランでは心もとないと思います。

最後に

これまで実際にセキュリティ系の製品を触っては来なかったので、なかなか新鮮ですね。
作って終わりというわけではなく、継続して開発していくことを考えると、このあたりの脆弱性を自動的に検知して知らせてくれるというのは心強いものです。

実際に、OSSを使わないなんてことは現実問題難しく、そのOSSが別のOSSを使っていて、更にその先で脆弱性が。。。なんて話はざらにありそうですし、それを「頑張って」で終わらせるのは厳しいものです。

製品全体を考えた際に、どのフェーズでどうやってこれら脆弱性に対する対抗策を整備していくのか。これからはしっかりと考えないといけませんね。

The Merge

日本時間の9/15 PM 3:42 に無事、Ethereumの The Merge が完了しました

そもそもEthereumとは?

当初、私も混同してしまっていたのですが、Ethereumは仮想通貨のEthを指すのではなく、Blockchain上で動作するアプリケーションのプラットフォームのことを指します。

そういう話をすると、クラウドを思い浮かべてしまいますが、現状のクラウドは、あくまでクラウドベンダー。大手で言うところのAmazon提供のAWS。Google提供のGCP。そしてMicrosoftのAzureといったように、企業が提供している、いわゆる中央集権的な仕組みが取られています。

さらに、実サーバーとしてはリージョンだとかゾーンといったように、現実世界の国や地域の影響も受けてしまうというのが現状です。
中国なんてまさにそれ。

Ethereumが目指すところというのは、そういった企業や国・地域の影響から脱却した。真に制限のないプラットフォームの構築となります。

もちろん、プログラムを動作させるには現実世界のコンピュータが必要となりますが、特定のコンピュータに依存することなく、分散実行・検証を行い、情報を保存することで、非常に多くのコンピュータを使った一つの大きなプラットフォームを形成するようなイメージですね。

現状の課題

実行するプログラムのことをスマートコントラクトやdAppsと呼ぶことになりますが、利用者の増加に伴って当たり前の話ですが、処理速度が低下するという問題が発生しています。

また、ブロックチェーン上にブロックを追加する際、いわゆるマイニングという行為が発生し、これが電力需要を圧迫しているという指摘もあります。

それら以外も、スマートコントラクトをEthereum上で動作させるには、その処理量やデータ保存量によって、手数料がかかるのですが、この手数料がその時のEthereumチェーン上が混み合っているかによって大きく変動します。

色々ありますが、要するにこれ以上Ethereum上でスマートコントラクトを動かしたりしていくにはスケーラビリティが足りない状態なわけです。

そして、それを解決するべく様々なロードマップがあるのですが、一つの大きな節目となるのが今回実施された The Merge と呼ばれるアップデートです。

The Merge

一番の大きな変更は、これまでPoW(プルーフオブワーク)と呼ばれていた、いわゆるマイニング行為を行って早くより複雑な計算を行ったら報酬がもらえるという仕組みをやめたことだと考えています。

では、どうやってブロックの承認を行っていくのかというと、PoS(プルーフ・オブ・ステーク)という仕組みに切り替わります。
これは、PoWで膨大な計算を早く行ったものが勝利するというものから、よりEthを多く持っている人からブロックの承認者を選出するという仕組みです。

つまり、ブロックの承認者選出に対して、膨大な電力を必要としない仕組みとなるわけです。

これまで、マイニングを行っていた報酬として配られていたETHも、より多くステーキングした人に対しての報酬へと切り替わるとともに、新規の発行枚数は減る見込みです。

つまり、ETHの流入量が現在と比較すると減っていく形となるため、場合によってはETHの値段は上がるのではないか?と思います。

何はともあれ、今回の The Merge 後、ETHの価格もそうですが、ガス代やスケーラビリティの問題が想定通り解決されるのか?

これから楽しみですね

Cloud Security Report 2022 by snyk

Twitterを物色していたら、こんなものを見かけた

把握していなかったのだけど、セキュリティプラットフォームを提供するsnyk(スニーク)という企業があり、そこが出しているセキュリティレポートということ。
レポートの中身としては、エンジニアやセキュリティの専門家に対してのリサーチを行った結果をまとめたようなものだ

早速ダウンロードして読んでみた。
簡単な登録で読むことが出来るので、興味がある人は手にとっていただければと思う。

クラウドにおけるリスクの代表

開発者目線でクラウドのリスクって何かな?と考えると、やはり情報漏洩だろうな、と思ったらやはりそのあたりだった。

P4. serious cloud security

data breach(データ侵害), data leak(データ漏えい)、Environment intrusion(環境侵入)が多い。
もちろん、クラウドのダウンタイムも34%ということでリスクと言えばリスクだけど結局のところ対応しなければいけないリスクとしてはセキュリティなのだという。

もちろん、これは snyk というセキュリティプラットフォームを提供している企業が出しているレポートなので既定路線ではあるんだろうけど、考えなければ行けない大きなテーマであることには変わりない。

リスクへの対応

本レポートでは、それらセキュリティリスクに対応するためにIaC(infrastructure as code)を大きく取り上げている。

IaCはどちらかというと環境構築においての効率化的な側面のほうが開発者から見た場合には大きい。

初期の環境構築ではIaCで構築はするものの、実際に動かしていく中での追加変更は、クラウドコンソール上で設定変更していくスタイルだ。

レポートでは、それではダメなんだと。
問題への対応に関してもIaCを追従させていき、IaCに対してのチェックを行っていく必要性を掲げている。
そして、それに関しては、組織のポリシーに従った形であるかをチェックできるツールを使って監査・検査できるようにしていく必要があると。
更に、ポリシー自体もちゃんとコードで表すべきだと。

When security policies are expressed solely in human language and exist
in PDF documents, they might as well not exist at all

P.32 ALIGN AND AUTOMATE WITH POLICY AS CODE (PAC) より

思わず笑ってしまったのが上記、「ポリシーが人間の言葉でPDFとしておいてあるだけなんて、言ってしまえばなにもないのと同じじゃないか!」
うん、PDFなんて読まないよね。。。

IaCに関して

インフラの構築はだいぶ、コードによって管理できるようになっているのは間違いない。
クラウドの環境構築においてはもちろんのこと、Dockerやk8sなどのコンテナ環境に関しても基本は定義ベースで構築する形になってきている。

一方で、構築した後に手を加えることもよくあって、それは構築時のコードに反映されているだろうか?に関してはできているとは言えない場面もよくある。

特に、簡易的なクラウド構築に関してはなれないIaCでやるよりもクラウドコンソール上から実施したほうが早い気がするんだよね。

ぶっちゃけてしまうと、両方できなければいけないというのが答えになるんだろう。
ただ、その中でもIaCで環境を構築するということに慣れていき、そこに対してのチェックを行うことが出来るくらい知識が付けば、しばらくご飯は食べていけるのだろうと思った。

家庭菜園向けのアプリを検討

先日紹介した、技術書店で以下の本を購入してしまいました

https://techbookfest.org/product/7Pzm4nWMKg9iAuX9Vz8Cbh?productVariantID=99cwTnd0rHckbcCgQCKRTf

本書を読みながら、紹介されているGlideと言うのはなかなか面白そうだな、と。

もちろん、ローコードツール独特の融通の効かなさみたいなものはあるんだろうけど、サクッと作ってみるという点では面白そう。
とは言っても、何を題材にするのか?ということに関してがやはり問題になるわけなんだけど、色々考えた結果家庭菜園向けのアプリなんて面白いんじゃないだろうか?と思った。

解決したい課題

私自身が、かれこれ10年以上それなりの広さの場所を借りて家庭菜園をやっている。
本格的な農家と、私のような趣味で家庭菜園をしている人との大きな違いは、当たり前だけど常日頃から見ていることなんてできないということだ。

なので、どのタイミングで何をするのか?
また、収穫の目安となる日程はなにか?
というところが、ズボラな私はいつもわからなくなる

ということで、解決したい課題を列挙してみる

  • なんの品種をいつ植えたのかの記録をしておきたい
  • その品種によって、標準的な今後の作業を知りたい
    • 追肥の時期
    • 実が付き始める時期
    • 収穫時期

その野菜なりがどういうタイミングで追肥が必要となるかや、実が付き始めるのか?は、種販売の場合はよく、種袋の裏に書かれていたりする。

実ができてから、収穫が見込まれるまで何日とか。植え付けから何日とかとか。
その情報を、植え付け段階で記録をしておいて、実際に日付が来たら通知が来る。

対象とする野菜に対して、考えなければいけない害虫やその対策なんかもあるといいかもしれない。

スイカとかを育てると、いつが収穫タイミングなのかが本当にわからない。
実ができ始めてから何日みたいな形なので、そういった記録を、苗単位、実単位で記録することができればいいんじゃないだろうか。

場所や天候によって、実際のところの収穫タイミングとかは変わってくるだろうからそういった情報も参考にして補正をかけることができれば面白そうだ

最終的に、そういった情報をいろいろな人が入力してくれることで、なにか面白い分析ができやしないだろうか。

追加妄想機能

とは言っても、初期段階での入力には課題が残る。
まずは、種袋の後ろを。。。と言っても面倒くさいのだ。

これに関しては、商品情報ではあるのでどこかしらにDBなりAPIになっていないかを考えたいところだし、袋裏を写真にとって画像解析から持ってくることができないだろうか。。。

天気のデータに関してはアメダスがあるので、そちらから。
天気や気温からくる生育のズレなんてのは正直、今後の蓄積されていくデータに期待となってしまうだろうなぁ。

あくまで家庭菜園という規模感で考えるのであれば、そこまで大規模なデータは手に入らないだろうけど、そこにはそこなりの面白さもありそうだ。

妄想アーキテクチャ

データの入力口としては、Glideで作ってみる。
Glideで入力したデータは、スプレッドシートへ書かれることになる。

スプレッドシート上のデータに関しては、外部データに関してはGASを用いてAPI叩くなりスクレイピングしてくるなりしたい

さっき書いたような画像解析なんてのも面白そうだ

どこまでを何が担当するのか?などなど、考え出すと色々出てくるなー

こうやって考えるのって結構楽しいですよね

DQW 3周年ガチャ 爆死

9/12からDQWで3周年記念イベントが開催されています。
今回のガチャの目玉はメタルキング装備。デイン属性とイオ属性390%全体ダメージということで、目下のところ全く歯が立っていないボーンナイト覚醒千里行に使える!

ということで、これまで貯めたジェムをすべて使う勢いで臨みます

途中、気を失いそうになりながら回し続けるも、キングメタルの剣は出ず。。。
防具は逆に鎧下以外は揃いました。

ここのところ武器運が結構良かっただけに、厳しい結果に打ちひしがれています。

残り開催期間中に、あと2回回すことができればピックアップ確定!
もしくはふくびき券でなんとか。。。!!!

一気にやる気が萎えてしまいましたが、これもしょうがない。運が悪いのは今に始まった話ではないので、強く生きるしかない。

頑張れ、俺!

技術書店13を物色

毎年開かれている技術書店13が今年も開催。
オフラインも開かれているようですが、ちょっと足を運ぶには遠いのと予定が合わない&オンラインで十分だろうとオンライン書店を物色しています

技術書典13 オンラインマーケット
https://techbookfest.org/event/tbf13/market

技術書店で出されている本は、基本的にテーマがマニアックなものが多いので、

「そんな着眼点があったのかー!」

と思わずニヤッとしてしまう本を探してしまいます。

今迷っている本をいくつか紹介します

ノーコード・ローコードで作る!QRを使った『じゃがいも収穫管理アプリ』の作り方

https://techbookfest.org/product/7Pzm4nWMKg9iAuX9Vz8Cbh?productVariantID=99cwTnd0rHckbcCgQCKRTf

ちょうど最近さわり始めたGAS、それにノーコードツールであるGlideというものを利用して実現しているらしい。
Glideってのは正直初めて聞いた

Glide(ノーコード)の使い方を徹底解説!無料でアプリを作成しよう!
https://nocodedb.world/archives/1180

無料でアプリが作れる?
と、見てみると、機能制限があって課金で解放ということですね。
スプレッドシートをもとに簡単にアプリが作れたり、豊富なテンプレートを使ってサクッとアプリを作るという点では面白そう。

本書ではQRコードも使っているので、Glideで作ったアプリで農作物の情報を入力。
スプレッドシートに記載されたその情報をQRコードにしてプリントアウト。
検品に利用する。。。ということなのかな?

倉庫で山のように農作物があるような場合だと、いつ収穫したものなのかをそういう形で記録しておくことは、トレーサビリティの観点からもいいのかもしれないな。

AWS Amplifyで作るIoTバックエンド

https://techbookfest.org/product/ph4YMFR31tnMxEnWrba0Wd?productVariantID=sTL00W9EW0fB5V0DnxYJ20

IoTのバックエンドをAWSで考えるのであれば、 AWS IoT 使うんじゃないのかな?と思わなくもない。
ただ、Amplifyはちょっと気になっているサービスではあるので、実際の用途としては見てみたい気もする

しかし、フロントエンドがそれなりにわかる人を対象としているようなので、ぶっちゃけ読んでもわからない可能性が高いかな・・・?

Amazon CloudWatch[本格]入門 ~クラウドネイティブオブザーバビリティストーリー~

https://techbookfest.org/product/uJL2pyLHyk92xYv4P25cJ7?productVariantID=2K5S2wagDLsyFytmk2RG77

以前にこのサークルの本を買ったことがある。
CloudWatchは重要性というものは認識しているものの、自分自身がそこまで大規模なAWS システムに携わっていないということもあってちゃんと身についている気がしない。

逆に言うと、この本を読んだからといって身についた気がするのか?は怪しいんだけど、変に教科書めいたものよりは可能性があるのではないだろうか?と思わなくもない。

うーん、迷う。

Hands-on LINEBOT

https://techbookfest.org/product/3EUnJ5WbexvCDyMgSJS1qb?productVariantID=x9zhcn94SKg2qqHz2yHTga

DynamoDBやLambdaを使った形でのLINE BOT

実際のところ、LINE BOTを作って何に利用するのか?が一番頭を悩ませそうだ。
でも、LINEにしろ、SlackにしろTwitterにしろ、まだBOTを作ったことがない私としては、なにか一つは試してみたいところではある。

と、ここまで来てぐぐってみたら似たようなのが出てきた

試験日まで毎日励ますサーバーレスLINE Botを作ろう(マネジメントコンソール編)
https://blog.usize-tech.com/encourages-serverless-linebot/

こ、これでいいじゃn

でも、AWSを勉強することではなく、LINE APIの方に重点を置くのであれば本書は良いように思える。
そういう意味では、やはり気になる

Fintechで儲かりたい! -発展編-

https://techbookfest.org/product/v8F3n1vdSwBz5FwXyPjV4L?productVariantID=gPchYDCNHcyNvvCDREw2hJ

こちらも、過去に買ったことがあるサークルの出版。
読み物として面白かった。

株取引BOTみたいなものは、それはそれで面白そうではあるんだけど、基本的にインデックス投資をメインで行っている身としてはそれほどの魅力を感じていない面もある。

紹介文にかかれている、「J-Quants API」と言うのはちょっと面白そうだと思ってみてみた

株式分析チュートリアル | 日本取引所グループ
https://japanexchangegroup.github.io/J-Quants-Tutorial/

ちょーーっと、読み進めたり取り組んだりするのにはしっかりとした時間が必要そうだ。。。

と言うか、この分析の先に果たして投資方面で良い未来が待っているのだろうか。。。

結局何を買おうか

色々と見て回ったけれど、なんというか、「これだ!」と即買いするものにまだあえてない。

前回、前々回とかは結構買ったには買ったんだけどな。
今、一番気になるのはLINE BOTかな?

AWSとLINE。両方ともの事例としても使えるし、もしかしたらその先にCloudWatchが待っているかもしれない。
でも、LINE BOTを作ったとしてもそれが果たして日々を潤してくれるのだろうか?ということに関しては正直分からない。
下手をすると、AWSの費用だけが膨らんでいきやしないだろうか?

ちょっとモヤモヤしないわけでもないが、動き出さなければ何もわからないし始まらないのだ。
ちょっとどこかで試してみようかなと思っている

Google Apps Script を Gitub Actions で簡単デプロイ

GASをさわり始めては見たものの、GAS標準で備わっているコードエディタは悪くはないんだけど、せっかくなのでローカルのVSCodeで開発をしてGithubへPush。
Github Actions を利用してデプロイまでやってしまおうかと。

GASのコードエディタだと、弄り倒してもGithubに草生えないし

Claspのインストール周り

claspという、Apps Script をローカル開発するためのコマンドラインツールをインストールします

clasp
https://github.com/google/clasp

インストールは以下のコマンドを叩くだけ

npm install -g @google/clasp

インストール完了後、claspを使ってログインを行います

clasp login

上記コマンドを打つと、Googleへのログイン情報を取得することができます。
Github Actions では、ここで取得する情報を用いて、Apps Script側へDeployすることになります。

その際、Apps Script の API を呼ぶことが出来るように、Apps Script側でAPIを有効にしておきます

GASの設定値を入手する

作成済みのGASのコードを入手するために、claspを使ってプロジェクトをcloneします

clasp clone "スクリプトID

スクリプトIDは対象とするApps Scriptのプロジェクト詳細から確認することができます

単純に、AppsScriptを表示した際に表示されるURLの一部でもあります。「https://script.google.com/d/**ID**/edit?mid=hoge&uiv=fuga」

clone をすることで、下記のファイルが取得されます

appsscript.json
.clasp.json
コード.js
.clasp.json

コード.jsはAppsScriptのエディタで編集していたJavaScriptファイルです。
HTMLファイルなどを追加している場合は同様にcloneされてくるはずです。

appsscript.json には、プロジェクトに関する設定が記載されていて、対象とするApps ScriptをWebアプリとして利用する場合にはこんな記述になっていると思います

{
  "timeZone": "Asia/Tokyo",
  "dependencies": {},
  "exceptionLogging": "STACKDRIVER",
  "runtimeVersion": "V8",
  "webapp": {
    "executeAs": "USER_DEPLOYING",
    "access": "ANYONE_ANONYMOUS"
  }
}

初回デプロイ時にWebアプリとするのか、APIとするのかなどを選択することになるので、実際にcloneする際には初回デプロイ後のほうがいいかもしれません。

また、.clasp.jsonファイルではディレクトリの指定が可能です。
Github Actions のフォルダなどを作ることを考えると、ソースファイルはsrcフォルダに移動しておいたほうがいいです。

{"scriptId":"XXXX スクリプトID XXXXX","rootDir":"./src"}

必要事項をGithub Secrets へ保存する

clasp login コマンドを実行したことで、ホームディレクトリ配下に.clasprc.jsonファイルができているはずです。
注意しないといけないのは、clasp clone で取得した.clasp.jsonファイルとは別となります。名前が似ていますが。
Windowsであれば、「C:\Users\XXX\.clasprc.json」に保存されている形です

{
    "token": {
        "access_token": "XXXXX",
        "refresh_token": "XXXXX",
        "scope": "https://www.googleapis.c...",
        "token_type": "Bearer",
        "id_token": "XXXXX",
        "expiry_date": 1662717440887
    },
    "oauth2ClientSettings": {
        "clientId": "XXXXX",
        "clientSecret": "XXXXX",
        "redirectUri": "http://localhost"
    },
    "isLocalCreds": false
}

上記の中から、Deployに必要となる下記の値をGithub Secretsへ登録します

  • access_token
  • refresh_token
  • id_token
  • clientId
  • clientSecret

さらに、デプロイを管理メニューで表示されるデプロイIDも登録します

Github Actions用の定義追加

ここまで来たらあと一息。
というわけで、workflowを定義します

name: CD

on:
  push:
    branches:
      - main
  workflow_dispatch:
jobs:
  deploy:
    runs-on: ubuntu-20.04
    timeout-minutes: 15
    steps:
      - name: Checkout
        uses: actions/checkout@v2
      - name: Setup Node.js 16.x
        uses: actions/setup-node@v2
        with:
          node-version: '16.x'
      - name: Install Clasp
        run: |
          npm init -y
          npm install clasp -g
      - name: Create claspc.json
        run: |
          echo \{\"token\":\{\"access_token\":\"${{ secrets.ACCESS_TOKEN}}\",\"scope\":\"https://www.googleapis.com/auth/userinfo.email https://www.googleapis.com/auth/drive.metadata.readonly https://www.googleapis.com/auth/script.projects https://www.googleapis.com/auth/script.webapp.deploy https://www.googleapis.com/auth/logging.read openid https://www.googleapis.com/auth/userinfo.profile https://www.googleapis.com/auth/drive.file https://www.googleapis.com/auth/script.deployments https://www.googleapis.com/auth/service.management https://www.googleapis.com/auth/cloud-platform\",\"token_type\":\"Bearer\",\"id_token\":\"${{ secrets.ID_TOKEN }}\",\"expiry_date\":1620870307822,\"refresh_token\":\"${{ secrets.REFRESH_TOKEN }}\"\},\"oauth2ClientSettings\":\{\"clientId\":\"${{ secrets.CLIENTID }}\",\"clientSecret\":\"${{ secrets.CLIENTSECRET }}\",\"redirectUri\":\"http://localhost\"\},\"isLocalCreds\":false\} > ~/.clasprc.json
      - name: Push
        run: |
          clasp push
      - name: DEPLOY
        run: |
          clasp deploy --deploymentId ${{secrets.PROD_DEPLOYMENT_ID}}

mainブランチに対してのpushで起動するようになっています。

将来的に、デプロイ先を分けられるように、DEPLOYMENT_IDはPRODをつけて定義しています。
上記yamlファイルを

.github/workflows

フォルダに配備します。
最終的なディレクトリ構成としては下記の様に私はしてみました

PROJECT_FOLDER
  └── .github
       └── workflows
              └── cd.yaml
 └── src
       └── .appsscript.json
           コード.js
  .clasp.json
  README.md

これで動いていることを確認できます。

うまくいかなかった時

Github ActionsのFlowが成功したからと言って、実際にAppsScriptがちゃんとデプロイされるとは限らないです。

Run clasp push
  clasp push
  shell: /usr/bin/bash -e {0}
? Manifest file has been updated. Do you want to push and overwrite? (y/N) 

上記の様なログがclasp push 時に発生していました。

原因としては、clasp clone 後にAppsScriptのコンソール上から、AppsScriptを初デプロイした際にWebアプリの選択を行いました。

デプロイ後にclasp clone していれば問題なかったのですが、Webアプリを選択したことで、appsscript.jsonの中身が更新されたのです。

clasp push 時にその差分が検知されてしまい、上書きするのかどうかを問われて、返答なしでそのまま終わってしまったのですね。。。

現状の不満

なんとか目論見通り、ローカルでの開発とPushすることでのDeployまで持っていくことができました。

一方で、ローカルで作ったものを動かすことができていません。。。
そのため、毎回デプロイして本番確認。デプロイして本番確認を行っています。。。

Githubに無駄に草がわんさか生えることになっているんだけど、実際のところ、ただのタイプミスだったりすることも多くて、少し悲しい。
できれば、動作確認してからcommitしたい。。

というのも、フロントエンドが不得手な私はサンプルを探してきて使ってみているんですが、なかなかこれがうまく動かない。
そして、恐ろしくエラーの原因調査・デバッグが難しい。。。

Vue.jsで書かれたサンプルを改造しようとしていますが、正直心が折れそうで、見た目とか気にせずにものすごく単純なHTMLにしてしまおうか迷っているところです。
とは言え、なんかこのまま引き下がるのも悔しいんですよね~。

というわけで、Vue.jsに関して少し勉強してみようかな・・・?

参考