入門書「Google Workspaceで始める・・」で解説されていた休暇申請アプリを作ってみて

結論： AppSheetでアプリを組む時、最後は関数を駆使する必要があるので、AppSheetをNoCodeと言っていいのかどうか疑問ですが、AppSheetはシンプルなアーキテクチャで、Googleの各種サービスとも連携が容易なので、使いこなせたら強力な武器になると思っています。（だから？？先人のサンプルで引き続き勉強したい）

補足：今回の試作を通して理解できたのは、、AppSheetではスプレッドシートによるデータ構造がまず存在する。Viewはシート上のデータをほぼそのまま見せる機能であり、SELECT * FROM table WHERE XX = NN 等の条件に合致したレコードを選択的に表示させたい場合は、Sliceと呼ばれる仮想的なシートを作って、シート上でデータを整えてからViewで表示させる。
　AppSheetでアプリを組む流れとして、スプレッドシート上にまずデータを作り、データをAppSheetに読み込ませてVIewで表示、Viewを見ながら目的に合うようシートを分割したりVirtual Columnを作成、Sliceで表示をカスタマイズして作り上げていくフローなのかと思っています。

今後の取り組み：
心の状態（気持ちは元気？？しんどい？？）を日記に付けつつ、グラフ化できるアプリをAppSheetで作ってみたい*1。機能が多すぎますが、、テンプレの、WorkOut Sampleが参考になるのではと思っています
Workout Log
あとは、、部屋にクーラーが無くて暑すぎるので、温湿度センサの値をWebAPIでスプレッドシートにPOSTして、AppSheetで表示したい。

■追記
AppSheetで扱えるデータ型
Column data types - AppSheet Help
Y/Nというのが何型か分からないのだが、普通ならbool型かと思うが、上記のデータ型で確認したけど、そういう型は無いようだ。SpreadSheetではTRUE/FALSEで表現されるらしい。

■ご参考URL
App templates
Setting up Google Sheets REST API Integration Simplified 101
Google Cloud FunctionsでREST APIを作って、SpreadSheetに書き込む
A Guide on Google Sheets with Python API using Google Cloud Platform

*1:子供に頼まれてFlutterで作りかけたものの、きれいなグラフを描画するのが難しく、頓挫した

NoCodeのアプリ作成ツール、AppSheetは易しいか？

要約：C/Java/Python等、手続き的なプログラミング言語で実装をしてきた人間がNoCodeツールを使ってロジックが含まれるアプリを作るには、NoCode独自の記述方法を理解する必要があると思う*1。

詳細：AppSheetはコードが不要と言われいてる。名簿やアルバム程度のビジネスロジックが含まれないアプリならGUIでボタンを数回押すだけでそれほど苦労なく作れると思う。一方で、在庫管理や、売上管理システム等、集計等、ビジネスロジックが含まれるアプリを作ろうと思うとどうやってアルゴリズムを実装したらいいのか考えつかない*2。Sheetと関数の組み合わせでアルゴリズムを実現するためのノウハウは必要と思う*3。それに、、Sheetの設計はDB正規化のノウハウが必要と思う。全部入りのデカいSheetを作ってしまうと、後から改修や拡張が困難になると思う。

背景：技術支援のような話で、集計システムの相談を受けて、Python/Flask/SQLiteで組める目途が立ったけど、細かい実装部分が多くて、作る方にとっても苦労が多いと思われ、AppSheet等のNoCodeツールだったらどう実装できるのかを調べています。が、、AppSheetでアルゴリズムを書こうと思ったら、あらかじめ用意された関数を使い、どちらかというとセルに対する宣言的な書き方が前提となる（Exceのマクロか、SQLのような関数）。自分は昔から手続き的なプログラミングが染みついており、宣言的なプログラミングが分かっていない。またDB(SQL)に対して深い見識がないので、SQL文でビジネスロジックというか、算出アルゴリズムをさくっと書く力がなく、AppSheet的な実装ができず止まっています。手続き的なことがやりたかったら、GASを使えということなんでしょうが、、できるだけAppSheetで完結するのが理想の形と思われ、まだまだ理解が足りないと思っています。AppSheetのサンプル集があるのでそれをよく見てどう実装するのが良いのか、ベストプラクティスを学ばないと、泥臭い、手間ばっかりかかった実装になりそうな予感がする。

■追記
これまでプログラミングに時間を使ってきたが、自分が作ったものは、どちらかというと一直線に動作し、ほとんどユーザとの対話操作がないアプリであった。対話操作が入ると途端に処理複雑になり、入力が中断した場合の対応、複数の項目の整合性を取るチェック機構、一旦登録した値の編集、取り消し、削除、そういったありとあらゆる末節？？なコードをテンコ盛りで作る必要がある。さらに、混乱させないためのメニュー体系や、遷移も必要だ。そして、認証認可も必要だ。コアなビジネスロジックの実装は言うまでもないが、「混乱なく使えるね」と言ってもらえるためには、対話操作のための必須機能がテンコ盛りになるのであった。

■結論
AppSheetでアプリを作る際、売上入力や帳票作成等、テンプレート＋αで実現できるのであれば、非常に楽。一方、大量発注で割引とか、販売条件とか、利用者独自のビジネスロジックが入ってくると難易度が上がる。ビジネスロジックをAppSheetの範囲で実現しようとなると、関数を駆使して実現する必要があり、手続き的な実装に慣れている人間には難しい。SpreadSheetのマクロ用関数群で処理を書く必要がある。AppSheetの関数群では表現しきれない複雑な処理の場合(あるいはスキル上、関数的に実装するのが慣れない場合)、Google App Scriptを使って手続き的にロジックを組むことになる（と理解）

*1:NoCodeを謳うだけだけあって、Code記述はシステムの奥の方(仮想カラムやView、Action等)に収まっている。しかも関数プログラミングな印象

*2:特に、、ビジネスフローや、入力結果がビジネスルールを満たしているかどうかを判定する方法、複数のシートから条件付きで情報を集めるとか

*3:Excelマクロを使いこなせる人ならできるのかも

AppSheetのRefについて

AppSheetのRefがよくわからなかったが、「Google Workspaceで始めるノーコード活用入門」でRefについて少し述べられていて、いろいろ試した結果の理解をまとめます。現在の理解は以下

• テーブルを参照する際、紐づけるためのカラム名は同一でなくても良い
  • サンプルでは、親子両方のテーブルに同じカラム名（ID等）が使われいてる場合が多いけど、カラム名が同一でなくても紐づけは可能
• Refで設定して参照先のテーブル（親）と親子関係が結ばれる時、Keyの属性の付いたカラムが使われる。（名前が異なっていても、Key属性が付いたカラムを使って親子の対応関係が作られる）*1
• Virtualカラム等で、 [ID].[ADDR]で、親のADDRが得られます等と説明があるが、、この[ID]は子のテーブルのカラムであり、ドットから後ろの.[ADDR]は紐づけされた親のテーブルのカラム*2

上記のように、REQ_ERカラムにRef(名簿テーブル)と設定すると、名簿テーブルのKEY属性であるP_IDと [REQ_ER]の値で親子の対応関係が作られる（と理解）
また、このような親子の対応関係が作られると、Virtualカラムで=[ACK].[P_ADDR]とすると、子のテーブルのカラム[ACK]と一致する名簿テーブルのレコードが引かれ、該当レコードの[P_ADDR]が取得されると理解しました(8/7の時点の理解度)

AppSheetでの以下の表記は

= [ACK].[P_ADDR]

SQL文風に書くと以下と理解しました(クオートとか変数とか適当です)

SELECT P_ADDR  from  名簿テーブル   where  P_ID = $ACK;

AppSheetの関数で表現すると以下と思っています（テスト不十分）

select( 名簿テーブル[P_ADDR],  ( [P_ID] = [_THISROW].[ACK] ))

※自分の理解が間違って、嘘まき散らかしていたら申し訳ないです

■追記
親子関係のテーブルに対してselect文を使う時、一致条件のカラム指定では、テーブル名の指定が不要なようであった。両方のテーブルにおいてカラム名が重複する場合もあるので、テーブル名を修飾する方法もあるのでは？と思えるのだが*3。

Documentによると、 条件文はデータセットに対して行われると書かれている。逆参照したければ、_THISROWを指定しろと((逆参照というのがちょっとよくわかりませんが、ごちゃまぜになってしまったデータセットに対して、値を逆にたどって、作られた元のレコードにたどり着き、そのレコードのカラムを参照するという感じでしょうか。。(親のテーブルに追加されている、REF_ROWSを使って子どものテーブル（レコード）に到達するのだろうか。。)))。

2 番目の引数であるselect-row?式内では、すべての列参照は、式が実行されるデータ セットの観点からではなく、
検索されるデータ セットの観点から解釈されます。現在の行から列を参照するには、
逆参照 _THISROWする必要があります。

だから、、VirtualColumに書く場合は、以下の形式になると思われる。（仮に、親と子で同じカラム名(UID)を使っている場合)

select(名簿[PNAME], ([UID] = [_THISROW].[UID]))

■参考URL
support.google.com

*1:複数のカラムにKEY属性が付けられるようだが、、複数付けたらどうなるのか！？

*2:親子だけでなく、親＞子＞孫の関係もありそうで、この場合、３世代以上の参照はどうなる！？

*3:Documentより。。。selectで指定する一致条件のカラム指定は、すでに作成されたデータ集合に対するカラム指定であり、テーブルという概念は無くなっている。だから、テーブル指定はできない（と理解）

うっかりKinesisを放置しといたら月額が跳ね上がった件

社内勉強会の準備で、IoT のチュートリアル（AWS IoT Core 初級ハンズオン）をやってみた。問題なく動作したので、安心してそのまま置いといた*1。日々の使用料も確認できるので、そこで確認すべきだったのだが、７月分の請求書届いて、4,500円になっていて驚いた。調べると、Kinesisを動かしっぱなしにしたせいだった。データが流れていないはずなのだが、、ストリームが存在するだけで基本料金が取られるのだろうか！？！？
反省点：EC2ならまだ単価が大体分かるが、ストリームサービスは料金の計算方法がよくわからない(1GB単位の受信データと送信データごとに従量制と思っていたが)。試算ツールもあるにはあるが。料金がよくわからない場合は、最低でも一日の料金は確認して、数百円／日だったら、月額数千円になるので、すぐに止めるべし（必要なら動かしておく必要あるけど、、個人でKinesis代が数千円って。。）。ヨメに怒られる・・・
以下はCostExplorerで確認した画面

請求書の抜粋

■ご参考URL
AWS IoT Core 初級ハンズオン
https://catalog.us-east-1.prod.workshops.aws/workshops/b3e0b830-79b8-4c1d-8a4c-e10406600035/ja-JP

*1:もちろん、ラズパイとかは停止させたが。。今から思うと、Kinesisはすぐに解約すべし

GoogleのAppSheetが気になる

要約：
フルスクラッチでWebサービスを作るのは骨が折れる。最近の流行りのNodeCodeサービスを使ってみたい。GCPとも相性がよさそうな、GoogleのAppSheetが非常に気になる

詳細：
Mentaという支援サイトでメンターとして、技術的なお手伝いをさせてもらっています。
相談者から、業務管理のWebサービスをPythonで作りたいと要望を受けて、説明のために自分でも作ってみました。プロならJava+SpringBootなのかもしれませんが、、Javaでまともに組んだことがなく、相談を受けた言語もPythonなのでPython+Flask+SQLiteとコンパクトな組み合わせで試作しました。まだ作り終えていませんが、それほど複雑ではない要求仕様なのに、作っていくとコード量がどんどん膨れ上がっている状況です。
flaskとテンプレートエンジン*1使っているけど、それ以外のフレームワーク使ってないので、、GET/POSTでHIDDENで渡して・・セッション管理も・・と仔細だけどWebサービスをまともに動かすために必要となるコードが多くて、これを全部理解して学んでもらうのはちょっとオーバースペックではないかと思ったりもしました。
最終的には相談者と決める事ですが、これがもし、NoCodeサービスだったらどれだけサクサクと業務管理サービスが実現できるのか興味が沸いている所です。という背景から、AppSheetを理解してみたいと思っています。相談を受けている前提なので、今回は途中で飽きずに最後まで行けるはず。。

■追記
AWSからHoneyCodeというノーコードのサービス(β版)が提供されているらしい。まずこちらをやってみたい。ただし、AWSサービスとの連携はあまりできないらしい。詳細未確認
Amazon Honeycode を使ってコーディングなしで経費管理アプリケーションを作成する方法 | Amazon Web Services ブログ

■追記
HoneyCodeを使ってみようと思ったが、情報がかなり少なく有償化しないとAWSサービスとの連携ができないようなので、、AppSheetを学ぶことにしました。AppSheet/HoneyCodeはレゴブロックのような気楽さがありますね。だけど、、どうしたら思ったような画面が作れるのか、かなり不明点が多い。とりあえずサクッと勉強するために買った本

Google AppSheet ではじめるノーコード開発入門

■追記
正規化のためにテーブルを二つに分けて、IDで連携させた場合、refをつけると関係づけられるのまでは分かったが、参照先の情報をselect文等で取ってくる方法が分からない。。 まぁそもそもCやPython等の手続き的な方法で実装するのはやってきたが、SQL文のような宣言的な言語で構造を定義するのがかなりできない。宣言的に書けないと、AppSheetではうまく機能を実現できないように思える。(最後はGASでテーブルを書き換える関数を書くというもあるようだが、、それはちょっと最後の手段だろう・・)
AppSheetによるアプリ開発について、おおよそ考え方は分かったのだが、テーブル間の関連をどう扱うか(あと、、関数を駆使してほしい情報をまとめる方法)が分からず、もう一冊本を買った。

Google Workspaceではじめるノーコード開発［活用］入門 ――AppSheetによる現場で使えるアプリ開発と自動化

休暇申請アプリの作成事例(P253)では複数のテーブルを関連付けて参照する方法が説明されています。この本をよく読んで、細かい仕様がよく分からないRefを理解したい。

なぜここまでノーコードなのか？？　定年後の次の仕事として、農業DXに可能性があるか？？が気になっていて。。。短期間に手間をかけずIoTシステムやWebアプリを試作する上で、サーバサイドのデータ蓄積、管理、表示システムが課題。データ収集や見える化の手段として、IoT用のダッシュボードサービスを使う方法もあるけど、AppSheetでデータを集約する方が、データが手の内化しやすく(DBに保存されるよりGoogleDriveのスプレッドシート方がアクセス容易)、温湿度データや日射量等のグラフ化、分析等、Googleのリソース(GCP)を活用しやすいのでは？と思えて。

*1:flaskと一緒に動作するjinja2

IoT技術の適用例・・・・スマート農業

朝のニュースでやっていたのでメモ
www.pref.osaka.lg.jp
交流会 2022/8/19 （金）　13:00～17:00
「楽しく楽に儲ける農業」
https://www.pref.osaka.lg.jp/attach/29765/00000000/2022_smartfair_leaf.pdf

次の仕事のネタになるか、、会議に行ってみる予定。

Amazon ECSがよくわからない

EC2は時々使うが、できたらAmazon上でコンテナを使いたい。ECSがコンテナサービスらしいが、どう使ったらいいのか全く分からない。
black beltの解説動画があるようなので、これを見て勉強してみる
[AWS Black Belt Online Seminar] CON201 ECS 入門 資料公開 | Amazon Web Services ブログ
ひょっとして、ECSはコンテナイメージ管理＋稼働管理のみ担当で、コンテナが稼働するのはEC2上なのか？？
だとすると、EC2上でDocker走らすのとほとんど変わらないのでは？？