ソフトウェア開発」カテゴリーアーカイブ

Invalid number of parameters for “mint”. Got 1 expected 2

ジェネラティブNFTの画像生成、スマートコントラクト、Mintサイト作成をする上で、HashLipsが提供しているコードは最初の題材、テンプレートとしてよく出てくる。

HashLips
https://github.com/HashLips

エンジニアのむなかたさんが提供している、「誰でもできる!ジェネラティブNFT開発」を見ながら進めていたのですが、Mintサイトでmint実行時に表題のエラーが出てしまいました

誰でもできる!ジェネラティブNFT開発
https://crypto-code.jp/materials/create-generative-nft

エラー詳細

Error: Invalid number of parameters for "mint". Got 1 expected 2!
▼ 2 stack frames were expanded.
InvalidNumberOfParams
c:/Dev/darejene/hashlips_nft_minting_dapp/node_modules/web3-core-helpers/lib/errors.js:33
_createTxObject
c:/Dev/darejene/hashlips_nft_minting_dapp/node_modules/web3-eth-contract/lib/index.js:669
▲ 2 stack frames were expanded.
claimNFTs
c:/Dev/darejene/hashlips_nft_minting_dapp/src/App.js:132
  129 | console.log("Gas limit: ", totalGasLimit);
  130 | setFeedback(`Minting your ${CONFIG.NFT_NAME}...`);
  131 | setClaimingNft(true);
> 132 | blockchain.smartContract.methods
      | ^  133 |   .mint(mintAmount)
  134 |   .send({
  135 |     gasLimit: String(totalGasLimit),
View compiled
onClick
c:/Dev/darejene/hashlips_nft_minting_dapp/src/App.js:360
  357 |   disabled={claimingNft ? 1 : 0}
  358 |   onClick={(e) => {
  359 |     e.preventDefault();
> 360 |     claimNFTs();
      | ^  361 |     getData();
  362 |   }}
  363 | >

この手のチュートリアルでエラーの原因はチュートリアル上の工程をすっ飛ばしてしまったり、誤字脱字によるタイポなわけです。

ただ、問題なのは、言われるがままにコードを修正する形になるので、そのあたりがつけづらいという点ですね。
特に今回のように、ゼロからコードを書くのではなく、テンプレートから作る場合はそもそも書いていないコードが多いので余計に原因にたどり着きづらいことが多いです。

質問しても良いのですが、それでは理解の助けにならないので自力で解決することを考えます。

mint関数の定義

コード内容としては、Reactで書かれたフロントエンドからスマートコントラクトの呼び出し時にエラー。
エラーメッセージからは「mint」関数の引数が、コード中では “mintAmount”一つに対して2つの引数を期待していると言われています。

というわけで確認するべきはmint関数の定義です。

mint関数の呼び出しとしては

blockchain.smartContract.methods.mint(mintAmount)

という呼び出しになっています。

スマートコントラクト上のコードとしては

// public
  function mint(uint256 _mintAmount) public payable {
    uint256 supply = totalSupply();
    require(!paused);
    require(_mintAmount > 0);
    require(_mintAmount <= maxMintAmount);
    require(supply + _mintAmount <= maxSupply);

    if (msg.sender != owner()) {
      require(msg.value >= cost * _mintAmount);
    }

    for (uint256 i = 1; i <= _mintAmount; i++) {
      _safeMint(msg.sender, supply + i);
    }

と、引数を一つで定義されているので、呼び出しの仕方が問題というよりも、Mintサイトから見たスマートコントラクト上の定義では引数は2つと判断されている、ということなのでは。

という訳で、そのあたりを参照していけば良いはずですが。。。
少なくとも blockchain や smartContract をimport してはいないので、探します。
バックエンド主体で動いてきた私にはなかなか興味深いです

追っかける

blockchain 変数は App.js 内で useSelector によって値が入っています。

function App() {
  const dispatch = useDispatch();
  const blockchain = useSelector((state) => state.blockchain);

useSelectorに関してはこちらを参照

Reac初心者でも読めば必ずわかるReactのRedux講座
https://reffect.co.jp/react/react-redux-for-beginner#useSelector_Hooks

なるほど、さっぱりわからん。

わからんが、スマートコントラクトの定義っぽいところを探すと、bockchainActions.jsに

          const SmartContractObj = new Web3EthContract(
            abi,
            CONFIG.CONTRACT_ADDRESS
          );

という記述がある。

引数として渡しているabiは誰ジェネでも説明されている

ABIとは「Application Binary Interface」の略で、Webアプリからコントラクトへアクセスするために必要な設定となり、HashLipsのWebアプリではabi.jsonというファイルで管理しています

https://crypto-code.jp/chapters/create-mint-dapp/update-setting#index_0-3-0

ん。これが原因っぽい気がする

abi.jsonを見ると、HashLipsデフォルトの記述が書かれていて、更新し忘れていることがわかった。やはりこれが原因だった

という訳で、ここを正しく更新することで問題なくMintできるところまで行けた

最後に

ABIに関しては、公式に仕様が書かれていた

Contract ABI Specification
https://solidity-jp.readthedocs.io/ja/latest/abi-spec.html

とりあえず、なんとなく進め方はわかったけど、実際のところ各工程で行っている作業に対して正しく理解できている場所は少ない気がする。

数こなしていけば自然と覚えるものもあれば、調べて納得して覚えるものもある。

これなんだっけ?となる部分を少しでも減らしていければと思う。

Cloud Native Days Tokyo 2022 にオンライン参加

11/21-22と、オフラインでは有明セントラルタワー。同時にオンラインでも開催された、Cloud NativeにフォーカスしたCloud Native Days Tokyo 2022 にオンラインで参加しました。

といっても、普通に平日の日中帯なので、リモートで業務をしながら流していた形にはなりますが。(流石にMTG中はミュート)

業務中ということもあるし、セッションも同時並行で行われていたこともあるので全然見れていません。
ありがたいことにセッション動画は残されているし、一部は資料も提供されているのでのんびりと見ていきたいところです。

その中でもちょっと気になるセッションを抜粋

エンジニア育成

クラウドネイティブ関連の技術はどんどん増えていくし、新しい考え方や考慮しないといけないことは日に日に増していく一方。
それに対して、そういった業務に巡り合う機会というのは必ずしも多いとは限らず、増えていく技術量・スピードに対して実戦経験を積むスピードは間に合わない。

また、それらの役割を担うエンジニアの裾野が広がらないので、一部のリードエンジニアに集中してしまうことも、更に裾野が広がらない状況を生んでしまい負のスパイラルが起きている。

これらに関するセッションがいくつかあった

クラウドネイティブエンジニアの育成について実践していること
https://event.cloudnativedays.jp/cndt2022/talks/1540
株式会社カサレアル 伊藤さん

SIerで実践!クラウドネイティブを普及させる取り組み
https://event.cloudnativedays.jp/cndt2022/talks/1527
TDCソフト株式会社 島田さん

カサレアルの伊藤さんのセッションは途中まで聞くことはできたのだが、すごい賛同したくなるような内容だったので、見返したい。

今後、技術を学ぶ上でどういう形で向き合っていく上で、一つの参考としたい。
もちろん、正解はそれぞれの場面によって異なるとしても。

Observability

Cloud Native。特にKubernetesやMicroServiceを考える上ではObservabilityは切り離せない考えと思う。
それはわかるが、そんなにこのあたりの案件をこなした経験があるわけではないので、ぶっちゃけ「ふーん」というところではあるんだけど、いざとなったときに「何も知りません」とは、流石に言えなくなってきている昨今。

何も知りません

ということで、このあたりは言葉の意味から把握しておきたいところ

実践!OpenTelemetry と OSS を使った Observability 基盤の構築
https://event.cloudnativedays.jp/cndt2022/talks/1571
逆井さん

しきい値監視からの卒業! Prometheus による機械学習を用いた異常検知アラートの実装
https://event.cloudnativedays.jp/cndt2022/talks/1558
GMO ペパボ株式会社 高橋さん

特に逆井さんの話は途中まで聞いていて、結構気になる単語が目白押しだったので再確認しておきたい。
このあたりは、Kubernetes関連だとどうしてもPrometheusが出てくる印象だなぁ

クラウドリフト

現実問題、一番ありがちな話としては既存システムのクラウドリフトだとは思う。その中でどうしていくのかを取り上げていたいくつかセッションがあった。

なぜ貴方のモダナイゼーションは評価されないのか ~傾向と対策~
https://event.cloudnativedays.jp/cndt2022/talks/1574
株式会社NTTデータ 菅原さん

【既存アプリをコンテナ化したいのじゃが】-Kubernetesへリフトする開発者が乗り越える壁-
https://event.cloudnativedays.jp/cndt2022/talks/1565
RedHat K.K. 北山さん

どれもろくに聞くことができなかったので、見ておかないと。。。

最後に

これ以外にも気になるセッションが目白押しだったのでなかなか面白かった。実際問題、これらを活用する案件がものすごい多いのか?という話になると、所属企業の方向性やらなんやらによって大きく変わるんだろう。

ただ、このあたりの知識や技術を追いかけておくということは、エンジニアにとっては当然のことになっていくと考えているし、そう考えるとやっぱり自分はまだまだだなと、日々痛感してしまう。

だからといって腐らず、前に進むには何をしていくか。

水星ちゃんを見習って前に進むしかないのか。

LINE-BOTで遊んでみた

先日あった、技術書店13で購入した「HANDS-on LINEBOT」に従う形ではあるんだけど、一通りのLINE-BOTを作る工程を学んだ

HANDS-on LINEBOT
https://techbookfest.org/product/3EUnJ5WbexvCDyMgSJS1qb?productVariantID=1bFbTUsxUPrDGXzGCQQNUF

BOTというと、LINEだけでなくTwitterやSlackなど、様々なところで昔からあるんだけど、恥ずかしながらこれまで作ったことはなかったんですよね。

興味自体はあったといえばあったんだけど、あくまでなんとなくであって、特にそれを使って何かをしたいかな?とも思わなかったというのが理由ではあります。

じゃ、今回なにかそういう新しいきっかけがあったのか?と言われると、特にはないんだけど、LINEの公式アカウントだったりミニアプリは結構面白いかな、と思っているんですよね。
iOSなりAndroidなりにアプリを提供しようとすると、AppleやGoogleに対して審査を通す必要が出てきてしまいますし、何より手間がかかる。
そこをLINEに乗っかることが出来るのであれば、結構楽にいいコミュニケーションチャネルを構築できるのでは?と前々から思っていました。

そういう事をしようと考えると、LINE-BOTは抑えておきたい内容です

学んだこと

当然のようにLINE-BOTの本なので、LINEメッセージの受け答えや、メッセージの種類。それぞれの表現などに関して学ぶことが出来たのは言うまでもないですが、他にもいくつか収穫はあったかな、と思います。

AWSサービス(Lambda+DynamoDB)とその開発の仕方

今回の最終形は、バックエンドをAWSのLambdaとDynamoDBで構築するというもの。
ただ、開発としてはローカルで行っていきます。

Lambdaに関してはnodeで動かすわけですが、DynamoDBに関してはDockerで提供されているものを使う形でした

amazon/dynamodb-local
https://hub.docker.com/r/amazon/dynamodb-local/

aaronshaf/dynamodb-admin
https://hub.docker.com/r/aaronshaf/dynamodb-admin

こんなのがあったんですね~。
クラウドネイティブなサービスを開発するうえで、ローカルでの開発をどうするのか?は正直わかっていませんでしたが、こういうものを利用することで、ローカルとプロダクションを同じように出来るんだな、と。

さらに、Serverless用の環境構築ツールとしてServerless Frameworkを使っていました

Serverless framework
https://www.serverless.com/framework

正直これに関しては、例えば AWS であれば Cloud Formation だったり、CDK ( Cloud Development Kit ) を使うのに比べてのメリットってなんだろう?がそこまでよくわかっていません。
マルチクラウド環境で使える・・・?でも定義に思いっきりAWSとか描いたりしているもんなぁ。。。と。

CDKとの比較で考えると、YAMLかコードか?というところが大きい気もする。
ただ、このあたりのCaIは私は経験値が少なすぎます。
積極的に、こういう場合はどうなるんだろう?をやっていくべきなんでしょうね

Express実装例

もう一つは、それなりに対応が可能なLINE-BOTの実装例としてのサンプルコードですね。
今回の実装はExpressを使っているので、あくまでその一つのサンプルにはなりますが。

そもそもの話として、LINEで出来るのは基本的にはメッセージのやり取りではあるので、今回の構成はそれほど大きく変えることなく使い回せるのでは?と思います。

もちろん、今回の実装例をもとに、別のフレームワークなどで実装してみて練習するというのもいいな、と思いました。

LINE-BOT関係でいうと、次はこのあたりを使って見ると、よりいろいろなサービスを使う形ができて面白そうだ

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

手元で動くと面白いんですよね

もちろん、何かしらのチュートリアルみたいなものをやって、それをブラウザで見るというのは一つの経験ではあるんだけど、LINEのような普段使っているプラットフォームで、自分が組んだプログラムが応答を返してくれるというのは、素直に面白いと思うのです。

先日、友人から子供に対してレゴのプログラミング教室か、Unityのプログラミング教室とか、そういうところに通わせようかと思っているんだけど、どう?って聞かれたのです。

その時には、何がしたいのか次第だよな・・・とか、実際にオフラインで教わることが出来るのであればレゴとかがいいけど、オンラインであれば物理的な部品が絡んでくるレゴはやめたほうがいいんじゃない?と返したのですが、こういう、リアクションが返ってくるようなプログラムから、プログラミングの世界に入っていくのも結構ありなんだろうな、と思ってしまいました。

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叩くなりスクレイピングしてくるなりしたい

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

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

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

技術書店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に関して少し勉強してみようかな・・・?

参考

Google Apps Script (GAS) をさわり始めた

ちょっとしたきっかけで、妻から「こんなの作れたりする?」として見せられたサイトがGASでできていた。

GAS。。。一時期結構話題に登ることはあって、結構便利という話ではあったんだけど、結局のところ必要となる場面もなかったので触ったことないんだよな、ということで簡単に調べてみた。

GASの用途

Googleサービスと連携させることが比較的ラクなので、データを保存する場所としては基本的にはSpredsheetもしくはDriveへの保存になると思う。

軽く検索してみた限りでは、GASの利用用途としては

  • 簡易的なWeb API
  • スクレイピングしてSpredSheetへ保存
  • 簡易Webアプリ

みたいなところだろうか。
スクリプトを走らせることが出来る以上、やろうと思えばある程度のことはできそうだけど、あまり凝ったことをしようとすると、できなくはないが面倒なことになるかもしれない。

確か、以前LINE公式アカウントに関して調べた際も、GASで作ったAPIを呼び出すような例もあった気がする。
それを考えると、API設計なんかを含めて考えて作ることができれば、スピードとかを気にしなければ用途の幅は広がりそうだ

簡易Webアプリ

今回、できないか?と言われたのはWebアプリに分類されるもの。
端的に言えば、スプレッドシートの情報を公開するのと、その情報を使って計算し、結果を表示させるようなものだ。

それだけであれば、すぐにできそう

基本的なGASで作るWebアプリのコンセプトとしては簡易的なもので、ページとしてもHTML一つ。
色々と調べてみるとReactやVueなどでつくってWebpackなどでまとめることでGAS上で動かすことも出来るようだが、あまり凝ったことを今回やってもなぁ、と思ってしまう。

今回のオーダーとしては、最終的には妻の職場で使ってみたいということなので、ある程度自分たちでメンテナンスができないといけないのだ。

というわけで、簡単なWebのフォームを使った計算結果の表示と、データ入力。
また、スプレッドシートの表示みたいなことができればいいのかな?と思っている。

実際のところ、もう少しやりたい事を聞いてまとめて、最終的な完成形というか、業務フローというか。そういったものを考えた上でアプリをどう使っていくのかの動線を考えたいところ。

ReactにしろVueにしろ、凝ったことは出来るんだろうけど、そもそも自分がその領域に関して明るくないわけだし、今回の要求からはオーバースペックなわけだ。
まずは、簡単なところで試してみつつ、これまで手でやっていた自分の作業をGASを使って、より良い方向に向かわせることができれば面白いかな、と思っている。