タオルケット体操

サツバツいんたーねっとでゲームとかガジェットのレビューとかをします

Flutterでスケールするアプリ設計 Store編

hachibeechan.hateblo.jp

前回の続き

そういえば、前回の記事のブコメで

  • Behavior = TransactionScript?
  • 実践CQRS

という感じの元ネタばらし鋭い指摘をしてくれた方がいました。
90%方その通りなのですが、実装の平易さ、許容できるパターンの広さを優先するために元の定義からかなり離れてしまっており、混乱を招くかもしれないと感じたので別の用語で説明している次第です。

読み返すと文字の密度が高くて読むの大変な記事ですね。
今回は具体的な話になるのでサンプルコードとか載せられるといいなとおもいます。

スケーラブルなデータ設計の基本アイディア

ここで目指すものは至極シンプルです。

続きを読む

駆け出しプログラマーが効率よく成長するために必要なたった一つの習慣

動いたところで満足して終わりにしない

はい。

書き上がったあとに何をするべきか

あなたにチケットが割り振られているとする。
駆け出しの貴方にとってはどれも初めて実装するような機能ばかり、あれこれ試行錯誤してようやく動くようになったッッ……!!とする。

続きを読む

努力と勇気と人間讃歌

努力ってのは何も資格をとってどうこうだとかアイティーフリランで高収入!みたいな意識高い詐欺師のフィールドだけで使われるもんじゃなくて、日々の生活で呼吸と同じくらいに自然と行われるべきもんだよね。
例えば僕は数年前にある日突然魚の三枚おろしができるようになりたくなってしまい、一時期は毎日のように安いアジやなんかを買ってきて三枚おろしの練習をしていたんだけど、そういう些細な努力の種は日常にいくらでも転がっているわけで。こういうところで小さい努力を重ねているとできることが増え、必然的に楽しみの質が上がる。あのとき三昧おろしを練習したおかげで最近ハマっている釣りという趣味が料理という趣味と繋がりをもってQoLをあげてくれたり。

「努力」って言葉は無駄に神聖視されている嫌いがあるせいでこの言葉がチロっと出てくるだけで拒絶反応を示す人が結構な割り合いでいるんだけど、ような技能の獲得や上達のためのプロセスを雑にくくっただけのクソ単語なんだから構える必要なんて全くない。事実、努力なんて言葉は嫌いだーなんていいながら生き方に努力と等価な姿勢が染み付いてる人は一定数存在している。
とはいえ真実努力と縁のない人もかなりいるわけで、その辺の違いってどこからくるんだろうか。

個人的な考察をするに、これも結局「勇気」というクソ単語に集約されてしまう。
僕を含めて多くの人たちから努力フェーズに入るための気力を奪うのは「やってみて、もし何も身につかなかったらどうしよう」「時間の無駄になるんじゃなかろうか」「他人に無能だとおもわれないだろうか」というようなノイズであろう。
事実、大抵の技能はちょっとやそっと練習したところで身につくほど生易しくなかったりする。例えば僕はいまだに魚をおろすのは下手くそですぐなめろうに仕上がってしまう。

ところで、時間を無駄にしたから、無能だとおもわれたからなんなんだろうか。
マクロな視点で俯瞰すれば人生はそもそも無駄なものだし、人類のうち世界を動かしているのは一握りの天才だけであとは替えのきく無能ばかりだ。
自分がとんでもない飽き性なのでもしかしたらそこに存在する、なにかスルメのような噛み甲斐を見逃している可能性がないわけではないんだろうけど、無能が無駄の無駄使いを嫌って過去の再現で遊んでも何も面白くないし、ここは勇気を支払って時間を無駄使いしていこうじゃないかと、昨日らへんにそうおもいました。

人間讃歌は「勇気」の讃歌ッ!! 人間のすばらしさは勇気のすばらしさ!!

勇気とは何か。勇気とは恐怖を知り、それを乗り越える……我が物とすることです。

努力とは投資なので時には損切りもそのプロセスに入ってきます。
貴方が今やっていること、その第一歩がまさしく勇気の産物で努力であったとして、それが今そのままであるとは限りません。陳腐化した努力はあっという間に惰性へと成り下がるわけです。
勇気に満ちた状態、恐怖を克服し乱れぬ呼吸法を身に付けた波紋の戦士であれば継続と惰性を鋭く見抜き、過去の努力を捨てるという努力が可能になります。

何事においても達人というのは柔軟な思考の持ち主が多いですが、それはこのような勇気のプロセスが呼吸のように身についているからなのでしょう。

Luck and Pluck(DVD付)

Luck and Pluck(DVD付)

  • アーティスト:Caravan
  • 発売日: 2009/09/30
  • メディア: CD

Flutterでそこそこ規模の大きいプロダクションアプリを作ったのでスケールする設計についてまとめる

あわせて読みたい

FlutterでBLoCだChangeNotifierと振り回されて消耗するまえに - タオルケット体操

筆者のFlutterに対する印象は半年前にこのエントリーを書いたときから驚くほどに何も変わっていないので、逆にFlutterは非常に明快でわかりやすいライブラリなのかもしれないですね。 hachibeechan.hateblo.jp

筆者の主張の事前まとめ

  • Reactの学習は実質Flutterの予習
  • クライアントアプリを設計するにあたってはActiveRecordパターンの再発明をしてはいけない
  • 結局MVX
  • RXSteamとはなんだったのか
  • DDDの勉強をすると多くの示唆を得られる
  • Remi wareを信じろ
続きを読む

FlutterのRoutingを型安全に扱いたい!!

標準Routerのつらみ

Flutter標準のRouterの仕組みと書き方はだいたいこんな感じです。

flutter.dev

はい。つらいですね。
具体的にいうと

  • 定義が単純な Map<String, WidgetBuilder>

    • なので補完が効かない
    • なのでタイポで全てが終わる
    • なので後からrouterのkeyを変更するのが大変
  • 引数の渡し方がcontext越しのdynamicでヤバい

    • 普通に渡し忘れる
    • 普通に引き取り忘れる
    • 引数の型を変えてもコンパイルエラーが教えてくれない

などなど、画面が3つくらいしかないTODOアプリなら別にこれでいいとおもいますが、画面が10とか20とかを越えてくるあたりからもうちょい安全なソリューションが欲しくなるとおもいます。
じゃあ簡単なラッパーを書きましょう。

続きを読む