Life is Really Short, Have Your Life!!

ござ先輩の主に技術的なメモ

WTFormsで GETで飛んできたパラメータを捕捉する

ちょっとハマった。結論から言うとこれで動いた。

@app.route("aaa")
def user_summary():
    form = UserForm(request.args)

request.argsを引数に入れると、フィールドの変数と同じ名前のパラメータのデータを紐付けてくれる。 この引数が入っていないと、フィールドのdata変数が全部 Noneになってしまう!

class UserForm(FlaskForm):
   keyword = StringField("キーワード")

HTMLはこんな感じ。

  <form action=" method="get">
        <div class="row g-1 inline">
            <div class="col-auto">
                {{form.keyword.label}}
            </div>
            <div class="col-auto">
                {{ form.keyword(class_="form-control")}}
            </div>
            <div class="col-auto">
              <input type="submit" value="検索" class="btn btn-primary" class="form-control" />
            </div>
        </div>
    </form>

Cloud Runのアイドル時間課金がすごく大きくなってしまった話

今月の半ばから、VPS/Herokuを卒業して、全てGCPに移してCloudSQL x Cloud Runに切り替えた。

BtoB向けのシステムをやっている関係上、営業時間がすぎるとほとんどアクセスされない。CloudRunの最小インスタンスを1にしておくと、アイドル時間にもメモリとCPUがAllocateされるため、課金対象になることに今更気づく。

アイドルの課金額が実際にリクエストを処理している課金額より圧倒的に高くなってしまい、これは・・・と。

  • 最小インスタンスをゼロに(これでアイドルしてるインスタンスが消えるはず)
  • 営業時間(*/30 8-19 * * 1-5)内にヘルスチェックするだけのスケジューラーを仕込んだ。

20時以降にダウンタイムが発生した所で、多分2〜3秒だし。

そんな所で。

Tailwind CSSを学習しているメモ

MITなBootstrapテンプレートをゴニョゴニョして今ひとつな管理画面テンプレートを場当たり的なCSSjQueryでカオスになる人生に終わりを告げたいので、Svelte/Reactでリスキリングしている。

というわけで、CSSの再学習にちょうどよいなと思ったのが、ユーティリティのCSSがたくさん詰まっているTailwind。ショートハンドなクラス名の意味や指定を学びつつ、今どきのCSSだとこうやって書くんだなという文法の整理をしている。

確かに覚えないといけないCSSクラスはいっぱいあるけど、チートシート的なサイトはいっぱいあるのでそこまで辛くない。CSS in JSみたいなハードコアなやり方に比べると良さげ。

flexを知らないと何も出来ないな

ちょっとレイアウトを組もうとすると、display:flexをちゃんと知らないと何も出来ないね。まぁ大して覚えることもないけど。

focusなんて疑似要素忘れてた

Tabなどでinput要素にフォーカスが当たった時のものだ。思い出した。

odd,evenなんかも用意してある

<tr class="odd:bg-white even:bg-slate-50"> みたいな書き方ができる。便利〜。

インプット要素のスタイリング

  • disable
  • invalid
  • required
  • checked

formのinput要素の状態に応じてスタイリングをまとめて組むことができるみたい。

一旦終わり。随時追記。

Google Playにリリースする時だけ、Firebase Authenticationが動かない

Firebase Authenticationに限らないと思いますが、半日ハマったので備忘録。こちらにすべてが書いてあった。

minpro.net

Google Play」を経由してAndroidアプリとしてリリースする場合は、Android Studioで取得した「SHA-1」「SHA-256」ではなく、Google Play Console」で設定されているものをFirebaseのコンソールに追加する必要があります。

https://minpro.net/wp-content/uploads/%E3%82%B9%E3%82%AF%E3%83%AA%E3%83%BC%E3%83%B3%E3%82%B7%E3%83%A7%E3%83%83%E3%83%88-2022-09-07-6.33.58.png

おーん。まじか。知らなかった。道理で直接インストールしたRelease Buildが動くわけだ。

公式ドキュメントもう1回見てくる。探せなかった。

モダン・フロントエンドに慣れるとWPFクソだるい

2014〜2015年頃はWPFのMVVMを面白がっていたのだが、2022年の今となってはだるい。もっと言うとオワコン。

宣言的な書き方ができないし、バインディングの補完が効かない(できるのかな?)

XAML側でバインディングを書く時に、脳内でこのパラメーターだよねって補完するのだるい。実行時にエラーが発生して気づくことになる。BindingしているSourceに対するコンパイルエラーが入ればいいんだけど、多分無理だよね。Bindingってdynamicのようだし。サクサク書けない。Commandインターフェイスですら、もうだるい。ロジックの書けないXML形式でビューを表現するフォーマットのせいでボイラーテンプレートワークフローからの凡ミスが出てしまう。かったるい。

Recoilのような、グローバルなデータストアを保持できる機構が原則ない。ViewとViewModelが1対1なので。シングルトンなクラスを1個作ってWindow.Resoureで共有すると出来るっぽいけども力技。

stackoverflow.com

また、環境の切り分けもIDEに詳しくないとできないっぽい。Visual Studioの技術的情報ってかなり少ないので、わからないことが多い...Debug/Releaseというビルドスキームを増やして対応するしか無いのかな?

テスティングについても情報が... FriendlyでE2Eを書けば良いんだけども、いわゆるCI/CDに乗せることが難しそう...と思ったらやれば出来るようだ。

zenn.dev

まとまった情報が本当に少ない。WPFは今年いっぱいで終わりにして、Svelteで焼き直すぞ。

ドットインパクトプリンタに印刷するためだけに10年近く前にWPFを選んだ(正確にはPrintDocumentで座標指定する印字方法しかわからなかった)が、Windowsのドライバを入れてユーザ定義で用紙サイズの設定をし、ブラウザから印刷する時にその用紙サイズでPDFを印字かければ、理論的には行けそうなんだけど。

とりとめのないメモ。

StatefulWidgetを一切使わずRiverpodだけで頑張りたいお気持ち

2年近くFlutterをやっていて、データストアにRiverpodを使っている場合 StatefulWidgetはまじで要らない子なんじゃないかと思い始めている。disposeする対象の管理が面倒でメモリリークする可能性があり、良いことがない。コードも色々増える。

StatefulWidgetを使いたい=initStateを使いたいだと思うけど、画面が表示される度にイベントを発火したい的なことであれば、操作するデータストアのあるProviderをrefreshするとか、autoDisposeで破棄するとか、listenでリスナーを作るなどを組み合わせれば、同等のことが出来る。

個人的にはautoDisposeを使うケースがほとんどなくて、子画面に遷移する時に常に最新化したい場合と、Streamを取り扱う時。StreamによってUIを構築する場合、そのUIがスクリーンから消えた時にStreamを自動的に閉じたいのと、ref.onDisposeでやりたいことがある時ぐらいか。

今までやった中でStatefulWidgetの扱いが難しく感じたのは、アプリ内課金(in_app_purchase)の所。公式サンプルコード、はっきり言ってグチャグチャ。これでちゃんと動くんかいって思う。

github.com

これをConsumerWidgetで一本化するのが、Riverpod中級者になるための壁だなと思っている。今はConsumerStatefulWidgetでベタベタにやっている。サブスクとアプリ内アイテムで画面が分かれているので、IAPのゴニョゴニョを解決するだけを作りたみ。

アプリ内課金はサーバーサイドのコードが複雑なので(レシート検証やサブスクのイベント通知に伴うハンドリングなど)予算が許すのあればRevenueCatのようなアプリ内課金管理サービスに抱かれる方が断然楽です。月間収入が$1000未満なら無料。それ以上は、$1000単位で$8です。1万ドルだと80$。148円換算で、月間148万の売上に対して利用料が11840円。0.8%ですか。かなり安い原価率のように感じました。

だいたいのことはFlutterで出来るようになった。やっていきだ。

Reactの学習を辞めてSvelteで開発しようかなというお気持ちが

lealog.hateblo.jp

こちらの記述がピンズドだった。

原初の時代からReactな案件をそれなりにこなしてきたけど、今でもReact-wayですべてを考えるのはやっぱり小難しいな〜って思うし、このEasyではなくSimpleに極振りしたAPIセットを使いこなすのまじムズいな〜って思う。

Reactって全然簡単じゃない。これほど習得するのに苦戦したフレームワークは初めてで、独学で進めることに限界を感じた。入門書も全く参考にならない。Simpleではあるけど、Easyではないから、ということだろう。

責務を小さく単純化するために関数型を駆使したり、コンポーネントに外からHooksで状態を与えて管理したりと、SoCを保ってシンプルにしていくAPIセットがたくさんあるけど、メンターがいないと使いこなせる気がしない。

その時のユースケースにフィットするようなAPIセットが有るけど、色んな書き方が世の中にあふれているので「React-Way」が見えてくるのにどれだけの時間を費やせばよいのだろうか。まわりにReactに長けている人がいない自分は不安に思う。

CSS in JSを使う意味もよくわからないし、Reduxも重たく感じる。Contextだけでやっていける気がするけど、そうでもないとしたらどこに地雷があるのかな...とか。

言葉を変えると「とりま、こういう書き方で戦える」という実感がなかなか出てこない。

FlutterはSimpleとEasyが絶妙なバランスで設計されていたので、すぐ戦えた。その香りを、Svelteにも強く感じている。まずはSvelteをやってみようかな。