今のところのWidgetの書き方まとめ

2022年の3月あたりからFlutter製アプリを本格的に作り始めて1年半過ぎて、Widgetの書き方の今のところの型をまとめておく。

  • PageとWidget
  • 1画面、1データクラス
    • 画面クラス
    • データクラス
    • データプロバイダークラス
    • Widgetの分離
  • CustomWidgetクラス

Flutter製アプリを作り始めていたころ、"Everythins is a Widget"という考え方のWidgetはとても強力でKotlinでAndroidアプリを書いていた私にとってはとても衝撃だった。 とても自由だったし、Kotlinで書いてた頃は面倒だったリストの実装もサクサクできたのはとても魅力で、Widgetの思想の強力さを実感していた。

ただ、何も考えずにWidgetを書いていくとネスト地獄になっていく。 一人で個人開発で書いてる分ではいいかもしれないけど、仕事でチーム開発してると他人が書いたコードをレビューしたり、自分のコードをレビューしてもらったりするときにネスト地獄のWidgetのコードを見るのは苦痛だし、見てもらうのは申し訳ない気持ちになるし、効率的ではない。 そこから、いろいろ型を作っていくことにした。

続きを読む

今年飲んだビール

www.instagram.com

www.instagram.com

www.instagram.com

www.instagram.com

www.instagram.com

www.instagram.com

www.instagram.com

設計と道路

未熟ながらお仕事でモバイルアプリケーションの設計を考えさせてもらって、チームと議論してるときに「ガードレール」という言葉を好んで使っている。 交通量が少ない道ならあまりガードレールが無いだろうし、アスファルト舗装してるだけかもしれないし、センターラインも無いところもある 。 逆に交通量が多い道はガードレールがしっかり設置されているだろうし、道も大きくなっているだろうし、センターラインもしっかり引いて、交通標識もたくさんある。

交通量はモバイルアプリケーションだと開発するエンジニアの数で、エンジニアの数に比例して、設計によるガードレールや交通標識を増やしていかないとエンジニアの人たちが迷ってしまったり、衝突してしっまったりするかもしれない。 エンジニアの数以外にもサービスのフェーズにもよるだろうな。PMFするかどうかわからない検証しながらのサービスに対して、ガチガチのガードレールを敷いて設計でProductを作っていてはスピーディーな仮説と検証ができないかもしれない。 あとは、サービスの性質も関連するかもしれない。人の命やお金に関わるサービスの場合、できるだけ堅牢な設計にして不具合ができるだけ混入しない、混入しても迅速に対処できるようにしておかないといけないと思う。 道路で例えるなら普段の生活で使う道と迅速に遠くの目的地に着くための高速道路では構造も違うし、法定速度も違う。

私はDDDが好きだけど、DDDを完全にプロジェクトに適用させるのが正義とも思わない。 肝心なのはプロダクトが以下にユーザに早く届けて、ユーザが持っているイシューを解決するか。 現状の環境(エンジニアの数とかレベル感とか)でどういう設計が適切か?が大事なんだと思う。

そんなわけで、毎日チームメンバーと「どんな道で走りたい?」と話し合いをする日々です。

トキメキ

子供と大人で1日の時間の感覚が違うの(大人になるにつれ、1日が音速のように過ぎ去ってしまう現象)はトキメキがなくなることで起こるそうです。 つまり、子供は1日のうちいろんなことに感動したり、興味を持ったりするので1日が長く感じのに対して、大人になると1日のうち、感動したり、興味を持ったりすることが減る事によって1日があっという間に過ぎ去ってしまったような感覚に陥るそうです。

そんなことを妻とビールを飲みながら話していたら、「やりたいことリストを作ろう!」ということになり、ビールでいい感じにぐるぐるになった脳みそで色々考えてみたら色々出てきたので忘れないように書いてみようと思います。

  • 銀婚式する
  • 船旅をする
  • サバゲーをする
  • キャンプをする
  • オーダーメイドのスーツを作る
  • 着物を来て出社する
  • ドイツに行って本場のオクトバーフェストに参加する
  • 大学に行く
  • 北海道に行く
  • 楽器を習う(今だとぼっちざろっくの影響でギターやりたい)
  • 生前式をやる(自分のお葬式の挨拶動画を撮る。まだやるモチベーション皆無だけどそういう風なことを考えられるように老いていきたい)
  • なにか資格を取る
  • オーロラを見にくい

ブレストでいろいろ考えてみるのもいいものです。それだけでトキメキがある。

子育てとエンジニアを幸せに両立するためのマインドとか行動について(第2版)

この記事は子育てエンジニア Advent Calendar 2022の14日目の記事です。(今日は17日だけど)

adventar.org

2年前に「子育てとエンジニアを幸せに両立するためのマインドとか行動について」という記事を書きました。 今回はその第2版として変わった部分などを書いていこうと思います。

kou-hon.hatenablog.com

簡単に我が家のことをお話すると、私は39歳のFlutterアプリエンジニアです。不惑にリーチがかかってますが惑だらけです。デザイナの妻と最近はスイミングスクールに通い始めた小学3年生の娘と来年小学生の息子がいます。最近の我が家のブームはスプラトゥーン3です。(私はやってません)

他人と比べない

子供や自分自身のことを見つめるのは変わりないです。 以前はSNSサービスを使って、情報収集したり、すごいなと思うエンジニアの方をフォローして「世の中にはこんなにすごいエンジニアもいるんだ。頑張ろう」とモチベーションを上げていました。 が、あまりSNSをおいすぎて心の余裕がなくなってきている気がしたり。子供の事故など辛い事件に遭遇したり。なのでスマフォからSNS系アプリをアンインストールしました。 まあ、時々はやってるのですがアンインストールするだけどSNSに触れる敷居が上がるので少しSNSデトックスができます。 自分と子供と家族に集中しましょう。

子供と一緒に寝てしまおう

子どもたちも大きくなったので寝る時間も固定されました。 我が家は22時くらいにはみんな寝るようにしています。 早く寝て、早く起きて、やりたいことや仕事をしましょう。そのほうが多くの人にとって効率は良いはずです。 ちなみにダイエットにもいいし、精神衛生としてもいいことしかないはずです。

子供と一緒に勉強しよう

娘も小3になり、学童で宿題を済ませたり、友達と一緒に済ませたりと子供と一緒に勉強というシーンが減っているような気がします。来年は息子が小1なのでまたそういうシーンが復活してきそうですが。 最近は習慣トラッカーで勉強ややりたいことを管理しています。

kou-hon.hatenablog.com

とてもシンプルは方法ですが、不思議と習慣続くのでおすすめです!

怠けよう、許そう。

どんなことにでも当てはまると思いますが、100%を求めて何もできないより、不完全でも何かできたほうが価値があると思います。 100%を求めると「こんな自分ではだめだ」と自分を否定しがちになったり、追い詰めてしまったり、こと育児に関わってることでついつい完璧を求めてしまう人って多いのではないかなと思います。 まず完璧な人はいません。不完全でも少しづつ進んで、日々の仕事や生活をやっていきましょう。怠けよう、許そう精神です。

余談ですが、タスカジというサービスを我が家では導入して、2週に1度おかずの作り置きをしてもらってます。QoLがだいぶ上がりました。おすすめです。

taskaji.jp

最後に

第1版から

子育てもエンジニアとしての人生もアジャイルな長いプロジェクトな気がしています。 試行錯誤は繰り返して、自分や家族に合うよりベターな方法を見つけて、幸せになりましょう! それではハッピークリスマス!

子育てとエンジニアを幸せに両立するためのマインドとか行動について - kou_hon’s diary

習慣トラッカー

この本で紹介されている「習慣トラッカー」という方法をやり始めた。長年の3日坊主グセを改善したかった。

Amazon.co.jp: ジェームズ・クリアー式 複利で伸びる1つの習慣 eBook : ジェームズ・クリアー, 牛原眞弓: 本

やり方は簡単でこんな感じで習慣づけたいこと毎にカレンダーを用意して、やったら✗をつけていくだけ。

www.instagram.com (やり始めたのが今年の後半だったのでカレンダーを買いに行ったら2023年のカレンダーしかなかったので手書きで作った)

ポイントは「習慣のハードルを下げること」と「カレンダーを見えるところに置いておく」こと。 「習慣のハードルを下げること」については私は「個人開発」と「読書」は25分やればOK,「ウォーキング」はとりあえず、外に出て歩き始めればOKとしている。これで軽い気持ちで始められるし、習慣が途切れたとしても再開しやすい。 「カレンダーを見えるところに置いておく」については私はカレンダーを書斎の席の目の前に貼ってある。スマフォアプリでも似たようなものがあるが、物理で強制的に視線に入れることで「昨日のやったから今日もやるか」という気持ちになるし、習慣が途切れたら「昨日やってない・・・今日はやるか」という気持ちになる。それに✗が続くことで小さな達成感が生まれて習慣づけにいい影響を与える。 こういう、習慣が続きやすい環境を作ることで習慣が継続する状況を作ることができる。

この本も習慣トラッカーで読み切れたのでおすすめです。 kou-hon.hatenablog.com

LeanとDevOpsの科学を読んだ。

もともと、仕事しやすい環境ってなんだろう?と妄想することが多く、仕事がしやすい環境であるなら生産性が高いはず、生産性を測る物差しがあれば仕事しやすい環境かどうかが分かるはずといろいろ調べていたら、Four Keysという指標があることを知り、それをもっと理解するために「LeanとDevOpsの科学」を読み始めた。

「LeanとDevOpsの科学」の内容をざっくり言うと、組織のパフォーマンスを改善を促すケイパビリティ(組織の機能や能力)は何なのか?をテーマに全世界のIT企業などからアンケート調査を行い、そのデータを解析しその結果、判明したケイパビリティとそのケイパビリティがどのように組織のパフォーマンスに影響を与えているかを紹介している。その後紹介した組織のパフォーマンスの改善を促すケイパビリティの正確性の証明として調査・分析方法の紹介や実際にケイパビリティを応用して組織のパフォーマンスを上げている企業の紹介などが記されている。 本の半分を調査・分析で判明したケイパビリティの説明に当てているのでそこを見るだけでも価値があると思う。(というか、後半は調査・分析のためにどのような手法を取った?かの紹介なので専門性が高くてちょっと何言ってるのか良くわからない状態だった・・・)

Four Keysは本の最初の方に登場する。開発組織のパフォーマンスを的確に計測できる指標として、デリバリのリードタイム、デプロイの頻度、サービス復旧の所要時間、変更失敗率を詳細と理由とともに紹介している。 紹介されているケイパビリティは聞いたことがあるものも多いし、読めば納得できるものばかりだった。なので、組織のパフォーマンスを上げたいと悩んでる人にとってはこれを読めば、足りないケイパビリティを導入することでどのようにパフォーマンスが上がっていくのかを把握しながら進めていくことができるんじゃないかなと思う。

LeanとDevOpsの科学[Accelerate] テクノロジーの戦略的活用が組織変革を加速する impress top gearシリーズ | Nicole Forsgren Ph.D., Jez Humble, Gene Kim, 武舎広幸, 武舎るみ | 工学 | Kindleストア | Amazon