Booklog 2024
2024-09-18
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 69 ~ 92
chapter 3 ドラフト。 ドキュメントの構成要素を使い分け、流し読み上等で簡潔に、重要なことははじめに書く。 完璧を目指さず満たすべき要素を網羅してるか注意して初版を書き上げたら一歩踏み出せたと。 なかなか普段ここまで考えて書いてないなって気がするわ。
2024-09-17
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 47 ~ 68
chapter 2 終わり。 ドキュメントのタイプとパターンというのは意識して考えたことなかったので学びになった。 届けたい先に合わせて提供するパターンが変わる。ここは何度か噛みしめるように読もう。
2024-09-16
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 29 ~ 46
chapter 1 終わり。 この本でも届けたい相手のペルソナを作る。「遠くへ行きたければ、みんなで行け」でも「インディゲームサバイバルガイド」でもそんな感じだった。 仕事ではガチでやるのは当然として趣味レベルでサクッと始めるには重いな。呼吸をするようにペルソナを作れるようになれってことなのか。 社内向けにはあえて知識の呪いにかかったまま文書を書くこともあるけど、どうなんやろね。ペルソナにそぐうならいいのかな。
2024-09-15
ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 1 ~ 28
前回が軽かったので今回は積読消化回。積み過ぎて日があたってたところのオレンジが褪せてる。 わたしは仕事でサブシステムを作ったら文書や障害対応の手引なんかを書くのは結構好きだ。 それに対し称賛されることもあるけど、逆にしょーもないことすんなと批判されることもある。 書いてもコイツラ読まへんなーという状況も常にあるので、なんかきっかけを掴めたらいいな。 「ドキュメントは機能の 1 つ」、いいなあ。はじめに、は入門 Kubernetes の人。 この本はツールになるべく触れてないらしく、良い。ツールで解決できたら誰も困ってないもんな。
2024-09-14
世界一流エンジニアの思考法, read count: 1, page: 234 ~ 270
第 7 章とあとがき。コレでこの本は終わり。 わたしは生成 AI の出現で何も不安感じなかったのであんまこの感覚わからんのよな。 実際に仕事でシステムに組み込んだり日常的に ChatGPT や Github Copilot 使って楽させてもらってるが、それ以上のものを感じたことはないな。 中盤のエモいところも、そういうのとは距離を取ったらいいってだけだとアラフォー入る頃知ったわ。 総じてパラダイムシフトに遭っても自分が楽しんで進める道を行こうって話だと認識した。自分の人生は自分で決めろってやつ。 最後に、氏はラッキーという言葉を何度も書いてるが、 Luck is what happens when preparation meets opportunity. と言われるようにそれも積み重ねがあってのことなので見習いたい。
2024-09-13
世界一流エンジニアの思考法, read count: 1, page: 203 ~ 233
第 6 章。所謂ライフハック。昔 MIND HACKS を読んで以降色々試行錯誤してるのでかなり浅く読む。 休息時間を作るためのタイムボックスとか、エネルギーロスの縮小、フィジカル強化みたいなところ。 氏はテスト値上げるのにサプリ使ってるけどわたしはサプリはなんとなくアダプトゲンしかやらない。 実際にギター弾いたり自重トレしたり読書したりで気分切り替えていくと効果あるよな。 家族いると家事育児で必然的に仕事の枠決まるしある意味生産性は上げざるを得なくなる。
2024-09-12
世界一流エンジニアの思考法, read count: 1, page: 165 ~ 202
第 5 章。自己組織化されたチーム。 自己組織化されたチームは結構勉強したのでせやなってかんじ。良くない組織だと従業員も子供扱いを求めてるフシあってやな。 「自分以外のものになる」ことは期待されないの、マッコールさんみあるわ。こういう信頼で機能するの、みんなやる気があって真摯に取り組むからやねんよな。
2024-09-11
世界一流エンジニアの思考法, read count: 1, page: 131 ~ 164
第 4 章。コミュニケーション。 シンプルに伝え、知らないことを恥じずに聞き、 HRT で以て議論する。 特別なことはないが、楽しんだもの勝ちってのはホントよくわかるわ。
2024-09-10
世界一流エンジニアの思考法, read count: 1, page: 96 ~ 130
第 3 章。脳の負荷を減らす。 この章の話に沿うとわたしは殆ど Level 2 で知識に対して何も制御権を持ってない。 イラチの話はわからんでもないが悪しき大阪のせいちゃうやろｗ 時間をかけて確実に 1 つずつ積み上げていって完全な制御権を得る。理解・記憶・反復やと。
2024-09-09
世界一流エンジニアの思考法, read count: 1, page: 56 ~ 95
第 2 章は Be Lazy 。コレを 2016 年に読んで、その後ブログに載ってたエッセンシャル思考も読んだんだった。 いま 100% 身についたかというとそうではないかも知れんけど、これがきっかけで自分のやり方が再構築されたのよな。 やっぱいいな Be Lazy は。
2024-09-08
世界一流エンジニアの思考法, read count: 1, page: 1 ~ 55
メソッド屋のブログで Be Lazy 読んだころからファンなので読み始めた。とりあえず 1 章。 目次見る感じ概ねブログや note で見た内容なのでサラッと読む。
2024-09-07
プログラミング F#, read count: n+1, page: 267 ~ 287
なんか降りてきてコード引用符の章を行ったり来たりして読んだ。 古いので Microsoft Learn で code quotation のページも合わせて見る。 pocof のクエリに code quotation 使えるよな。動的に関数生成したら速いかはわからんので試さないといけない。 読後、訳者の人 dmmf 本のレビュワの人だと気づいた。
2024-09-06
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 267 ~ 287
設計を更新するのに型駆動でコンパイルエラー活用してやるって話。 このときにはじめに作ったドメイン文書には触れないんかー。これで本は終わり。 本を通して、 computation や active pattern の F# 機能を活用することあれど、データと処理が分割された FP の特徴を活かして静的型駆動でドメインを表現するテクニックの話だったと理解した。 個人的に気になった F# でのパフォの改善等は触れられてない(link は多少あるか)ので自分でやれってことやろな。
2024-09-05
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 252 ~ 266
RDB への永続化。 少しテーブル設計に触れてるけど、元々キレイな世界とその他で分けてるのだし、テーブル設計は RDB の事情に合わせてやればいい。 ORM 使わないのはわたしの好みなので良い。補償トランザクションは知ららなかったので調べておく。
2024-09-04
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 240 ~ 251
永続化。CQS と CQRS は違うと。モデル自体が分かれてるのが CQRS でいいかな。 イベントソーシングのも当然触れられてるが、十分に説明できないとスルーされる。
2024-09-03
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 219 ~ 239
シリアライズは地道に手で書く感じ。キレイな世界に出入りするための通過儀礼みたいなもんか。 高級なモデルから平易なデータ構造に落とすため single case union すらもシリアライズ用の DTO に丁寧にマッピングする。
2024-09-02
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 188 ~ 218
FP 的エラーの扱い。 ようやく railway oriented. 明示的エラーといえば Java の検査例外を思い出す。
bind, map からの独自 computation って流れだがわたしはあんま使いこなせてないからなじませたいな。
結局のところエラーの扱いがクリーン()なコードを汚すからその複雑性を DSL に寄せるという理解。
それ自体は好きだが Go のように愚直にエラー処理書くのもわかりやすいといえばそうやと思うので流派かなあ。
2024-09-01
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 167 ~ 187
FP のテクニックでドメインのパイプラインを繋ぎ終えた。 lifting してて良い。 例外避けたいから次章出直すとのこと。Expecto と FsCheck は試せてないからそのうちやりたい(と言いつつ随分経った)。 部分適用による依存性の注入はわたしもよくやるのだけど、多過ぎると面倒なので Record に詰め込むことをしている。 この章のアプローチでは引数に羅列しているのが、どうなんだろ。 この本でモナドでの実装は詳細に触れないようなので自分で考えな。
2024-08-31
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 155 ~ 166
パイプラインでドメインを繋ぐ。
例だからか知らんが failwith 使ってるので、好みじゃない。バキバキ副作用やん。更に失敗する可能性のある関数と示せないのがな。
不安になったので先の章を見たら computation で Result 使いつつどうにかする話が出てそうなので、ちょっと安心した。
エラーをどう扱うかも設計時から考えてほしかったな。
2024-08-30
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 139 ~ 154
FP の話。パイプラインでドメインを繋いぎた本なので後半に進む前にどうしても話したかったんやろなと思った。
ゼロ除算を愚直にサポートするならわたしは愚直に Either(Result) を使うかなと思ったが、 違った。
引数用に 0 存在しない型を作っとくみたい。DDD では多分キレイなドメインの世界ではエラーなぞ存在せぬという意思表示なんやろな。
どこで match で切り分けるかの違いだけなんで、そういう流派という理解。
2024-08-29
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 131 ~ 138
型だけで設計したので、最終的に関数合成しないのかなとかあんまピンとこないところもある。 Saga という言葉は知らなかった。 長時間稼働するやつは DDD 関係なく必然的にそうなるよなという感じ。
2024-08-29
People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け, read count: 1, page: 248 ~ 269
輪読会のやつ。 ミートアップのレシピみたいな感じ。 あと採用について。やぱ方向性と情熱が同じ方向向いてないと何やっても無理よなと思った。
2024-08-28
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 113 ~ 131
ワークフローをパイプラインに落とし込む。 サブステップをパイプ処理に当てはめて in/out の型も作る。型しか出てきてない。 依存関係は高階関数でやるのは FP ならそうよなという感じ。
2024-08-27
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 98 ~ 112
型システムを利用してドメインに不正な値が入らないようにする等。
private construct のくだりはまあわかるが match 使えないの痛いのとテストも書きにくくなるのでそこはあまり好かん。
整合性の部分はまあせやろなという感じ。
整合性を保たねばならないトランザクション自体エンティティでは？というのはそうかも知れん。
2024-08-26
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 83 ~ 97
レシピをべースにモデル化していく続き。
値オブジェクト・エンティティ・集約はここで例示しつつ触れられた。
NoEquality を使う辺り .NET と一緒に使うことを考えなければその方が simple で楽なのはわかる。
でもいつまでどこまで .NET から離れれるかよな。資産を使った方が楽なものもあるし。
2024-08-25
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 72 ~ 83
レシピをべースにモデル化していく。
パフォ問題に対するための Unit of Measure が出て来ず Struct とコレクションの単純型だけか。
数値しか使えんし触れないのかな。
2024-08-24
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 54 ~ 71
定義したドメインをモデルにするための F# のレシピ。 単純型と言う名で single case DU 使ったりしてるがデータ量によっては遅いし、氏の blog であるよな Unit of Measure 使うトコじゃないかなという気はする。
2024-08-23
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 42 ~ 53
FP 的にコンテキストの構造とかコードの構造とかこうするよなという話。 必要になるまで MSA やらず monolith よなというのはまとも。
2024-08-22
People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け, read count: 1, page: 224 ~ 247
輪読会のやつ。 この章はコミュニティの人をアゲさせるインセンティブ設計について。 会社のエンゲージメントとかと似た印象を受けた。
2024-08-22
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 30 ~ 41
一通りモデリングのステップをなぞった。 わたしの DDD の理解はかなり浅いが、 Evans に始まりそれいいなと思った人々の我流をまとめてる広義にそう呼んでる認識なので、この dmmf のそれも FP でやるならこうよな、という感じを受けてる。パイプラインのメタファーは好きなのでいいけど。
2024-08-21
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 15 ~ 29
イベントストーミング終わった。 原著者が Railway Oriented の人なのもあってワークフローを中心にしてる印象で、モデリングにもパイプラインのメタファーが基礎にありそう(勘)。 次モデリングのステップの理解を深めてく感じ。
2024-08-20
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: 6 ~ 14
DDD の紹介。イベントストーミングの途中。 先をざっと見た感じ第 1 部はモデリングに徹するみたいなのでやはり丁寧な印象。
2024-08-19
Domain Modeling Made Functional 関数型ドメインモデリング ドメイン駆動設計と F# でソフトウェアの複雑さに立ち向かおう, read count: 1, page: vi ~ 5
冒頭を読んだだけ。なんとなく丁寧な印象を受けた。