Booklog 2024

2024-11-20

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 144 ~ 151

第 6 章 プロパティ駆動開発。 1つ目のプロパティでカバーできなかったケースのテストを新たに作る。複雑化しないように小分けにする。 これはジェネレーターも同じで、テストしたいパターンを構成する最小の要素のジェネレーターを作る。 それらを組み合わせて複雑なパターンを網羅する。 ここまでは想像の範囲で期待の挙動をするかテストするポジティブテスト(ハッピーテスト)。次節からネガティブテスト。 単純で本実装とは違う形で実装ってのが結構むずそうよなーやり方は色々あるってのはわかるんやけどバイアスかかりそう。

2024-11-19

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 137 ~ 144

第 6 章 プロパティ駆動開発。 TDD と同じように PDD する。 ポジティブテスト(テストがスべきことの検証)とネガティブテスト(プログラムが処理できないことのテスト)の技法を探っていく。 最初に簡単なプロパティを書き、それを green にするために最小実装、実装後統計を見て妥当性のチェック。 プロパティ書いてジェネレータを書いて実装してって流れは F# だとコンパイルエラーうざそうで先に空実装しちゃいそう。 TDD もなんか苦手やし。

2024-11-18

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 121 ~ 136

第 5 章 信頼できるテスト。 ココまでで出尽くしてるかのようで特に気づく点なかった。 FsCheck で同じような実習してみるのが練習になりそうやけどまだやってない。

2024-11-17

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 111 ~ 121

第 5 章 信頼できるテスト。 PBT のアイデアを使った事例テスト。 総当たりの範囲が狭く実行時間も許容できる場合は PBT より事例を列挙するほうが良いケースもある。 この場合原因の追跡のしやすさは劣るが、実例が網羅されるためランダム性は必要なくより信頼性も高くなる。

2024-11-16

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 93 ~ 111

第 5 章 信頼できるテスト。 これまで学んだ内容を実践する。 モデル化、事例テストの汎用化、不変条件、対象プロパティと事例テストによる固定化(anchor 錨)。 ここでは CSV のプロパティを書くためにまずジェネレータからかいてるが、仕様のコード化という点で TDD に通じる。 プロパティを定義するとその仕様の曖昧さが生み出すというのもいいな。 避けられない既知のバグを正解ケースとして、またプロパティの実装上避けられない暗黙の仕様のテストも事例テストが向いてる。 こういう事例テストの用途はリグレッションテストも該当する。

2024-11-15

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 84 ~ 92

第 4 章 カスタムジェネレーター。 シンボリックコール。失敗したプロパティの出力が解読不能なバイト列などのデータ形式の場合に使える。 関数呼び出しやその引数をシンボルとして記録し、失敗時にその履歴が追跡できる感じ。 FsCheck にはシンボリックコールそのものはないみたい。それっぽいものを代替手段で実装することはできそうなので参考にはなるか。

2024-11-14

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 76 ~ 84

第 4 章 カスタムジェネレーター。 再帰ジェネレーター。 繰り返しで作れるデータは概ね可能。 ただし正格評価で呼び出し階層が深くなりすぎる場合があり、そのときは遅延評価することで回避する。 確率的に再帰の終了条件を設定する場合、確率が固定されたり異常なサイズのデータが生成されることもある。 その場合繰り返し回数だけランダムに生成して、データの生成を通常の関数で記述することで軽くできる。 Erlang 力低くてピンとこんが正確評価は FsCheck も同じだし、他のエッセンスも似たようなもんだろうと推測する。

2024-11-13

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 65 ~ 76

第 4 章 カスタムジェネレーター。 リサイズジェネレーター。生成される値の範囲を狭める。ただし狭めた分ばらつきが得られなくなる点に注意する。 変換ジェネレーター。データの生成と変換がジェネレーターとプロパティに分かれてしまうようなケースをジェネレーターにまとめられる。 またフィルタとして働く制約条件を設けるジェネレータもある。ただし除外されるデータの量が大量だと変換で賄う方が速いケースもあるので注意する。 生成・変換のいずれにしても効率的に欲しいデータを生成するには十分でなく、その場合確率を調整して狙いのデータに近づけることもできる。 ただし CSV や XML のような構造化データの生成には十分でないため更にテクニックがいる。 ここまできたら実際にテスト対象に必要なデータを試行錯誤するのが実践的で良さそうやな。勘所は練習しないとつかめなさげ。

2024-11-12

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 54 ~ 64

第 4 章 カスタムジェネレーター。 まんべんなくランダムなデータでは発見できると限らない。 限られたエッジケースに焦点を絞るようなテストに最適なデータを、カスタムジェネレータで生成する。 まず統計情報をとりデフォルトジェネレータで生成された値がテストに十分か見極め、不十分ならカスタムジェネレータを利用する。 カスタムのデータ生成はそら欲しくなるよなという印象。

2024-11-11

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 46 ~ 53

第 3 章 プロパティで考える。 正順の処理に対して逆順の処理を書ける場合はそれが対称プロパティとなる。 対称プロパティそれだけでは整合性を保証するのみだが、不変条件を組み合わせることで強固なプロパティが得られる。 コツとして、複雑な処理をプロパティ 1 つだけで信頼性を高めようとせず、複数のプロパティに分けて段階的に検証していくのが望ましい。 この辺は従来のテストと同じかな。

2024-11-11

入門・倫理学, read count: 1, page: 27 ~ 35

輪読会のやつ。Ⅰ倫理学の基礎 第 2 章 倫理理論。 倫理理論というツールを使うことで直観的に難しい場面での合理的な判断を補助する。 規範倫理学→帰結主義→功利主義。 帰結主義は良い結果で良し悪しを判断する立場であり、功利主義の良い結果とは関係者の幸福。 功利の原理と結果で判断する行為功利主義の限界を修正するために道徳規則を追加した規則原理主義。 二層理論では直観レベルと批判レベルの二段階で判断する。 多分ザクッと理解する意図の章なので用語を覚えるのからスタートかな。

2024-11-10

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 36 ~ 46

第 3 章 プロパティで考える。 優れたプロパティの実装は標準的なテストよりも難しいが、習熟するためのテクニックはある。 まずモデル化。単純で正しいと信用できる代替の実装。実行速度に問題があったとしても初手としては意味がある。 複数の実装パターンがない場合には従来のテストケースの汎化をする。どこまでを信頼するかは開発者の判断。 次に小さく分解した部分で常に真となるはずの不変条件を使う。単一の不変条件だと役に立たなくても他の部分の不変条件と組み合わせで信用を高められる。 テクニックがあるとはいえこの辺は実装しつつ習熟するしかないやろな。

2024-11-09

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 25 ~ 36

第 2 章 プロパティを書く。 備え付けジェネレータとコード化したルールを組み合わせてどテストを書くかってところ。 最初はサクッと書いてその結果からジェネレータを変える等プロパティを調整してく。 結構試行錯誤な印象。あとこの段階では組み込みのジェネレータ知らんことにはどうにもならなそう。 使うツールに習熟する必要あるって話の片鱗かな。

2024-11-08

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 19 ~ 25

第 2 章 プロパティを書く。 コード化されたルール、ジェネレータ、フレームワークが揃ってプロパティが得られる。 PBT には基礎的なステートレスプロパティとより複雑なステートフルプロパティがある。 あとは PropEr の使い方とか。後ほど FsCheck ではというあたりも自習しておく。

2024-11-07

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 11 ~ 18

第 1 章 プロパティベーステストの基礎。 従来のテストは単純なツールと多くのコード。 PBT は強力なツールと少しのコード化されたルール。 そのためツールの支援がなければ話にならんということで本で使うツールの紹介。 .NET もテストプロジェクトを分離するし FsCheck も同じ感じでやれそうやな。

2024-11-06

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: 1 ~ 11

第 1 章 プロパティベーステストの基礎。 プロパティベーステストは従来のテストと根本的にアプローチが異なる。 従来のテストは事例を並べるが、プロパティベーステストは「どのような入力を与えても常に同じであるような振る舞い」≒プロパティを定義する。 プロパティベーステストが適さないケースもあり、従来のテストより考えることが多くなり技能も必要だが、素晴らしい結果をもたらしてくれるって感じか。 事例ベースのテストは想像の範囲の仕様を記述するが、プロパティベーステストは想像の失敗をあぶり出す。そうそう、それこそ求めてるものよ。

2024-11-05

実践プロパティベーステスト PropEr と Erlang/Elixir ではじめよう, read count: 1, page: i ~ xii, 目次, 索引

前から FsCheck を使いたいと考えてたが手探りすぎたのでなんか手引が欲しく、ちょうど良さそうな本が出たので積読してた。 少なくとも和書だと PBT について書いてるのがこの本しかないっぽいし。 はじめ PBT 基礎を習って、その後は演習等実践を通して理解を進めていくみたい。良さそうや。

2024-11-04

本を読む本, read count: 1, page: 256 ~ 265

日本人の読書 - 訳者あとがきにかえて。あとがきのフリしたエッセイ。 短編を行ったり来たりして読む、訳書が悪文でも何度も読み込む。そのため読書技術が発展しなかったといった日本的な読書の特徴について触れられてた。 ただ時代の変化でそのような技術が有用であろう、という締め。なんか感想文チック。読書技術が発展しなかった背景でどう向き合うかみたいな話ではないんか。 読後の感覚的には、(まともな)技術書やビジネス書に限れば読書技術が活かせる気もするので、独学で実践するしかないか。

2024-11-03

本を読む本, read count: 1, page: 247 ~ 255

15 読書と精神の成長。残すはあとがきのフリしたエッセイぽいので、実質この章で終わり。 良書は読者に多くを求め、積極的な読者も自身に多くを求める。良書は多少難しかろうが脳が衰えない限り読者の成長に寄与する。 そのような本は希少であり、読むたびに新しい発見がある。この限られた良書がシントピコンにつながるわけやな。 個人的に定期的に読み返す本はあるが、それがシントピコンになるかはわからんな。 アカデミックな読み方を修練するしないに関わらず、本を読み続ける習慣の後押しになった気がする。

2024-11-02

本を読む本, read count: 1, page: 241 ~ 246

14 シントピカル読書―読書の第 4 レベル。 著者の言葉を読者の言葉に翻訳することを良しとしない反対派への反論みたいな感じ。 書籍が正確で読者によって翻訳可能あれば書籍同士は「語り合う」ことができ理性的なコミュニケーションは可能だというのを「原理」と指しているぽい。 なんとなく、書籍は著者・その時代背景や言語の違いがあろうが誤読のない限りは読者の言葉で表現されて然るべきだろうから、反対派の方が的外れな気はするな。 そしてシントピカル読書の段階のまとめの便利な一覧。

2024-11-01

本を読む本, read count: 1, page: 235 ~ 241

14 シントピカル読書―読書の第 4 レベル。 シントピカル読書の実例。同じ言葉でも意味を違えた使い方をしている著者のグループがあり、 読者の問に即した方をより意味を明確にした読者の言葉で表現したグループとしてとらえ、その中での論争に注目する。 そしてシントピカル読書の手引としてのシントピコン(The Great Books of the Western World)。これ和訳ないのが残念よな。 西欧の思想というか概念の索引ぽいし、現代的な思想の源流を知るのに絶対いいやろ。

2024-10-31

本を読む本, read count: 1, page: 227 ~ 235

14 シントピカル読書―読書の第 4 レベル。 シントピカル読書の5つの段階。関連箇所を見つける。著者に折り合いをつける。質問を明確にする。論点を定める。主題についての論考を分析する。 分析読書とシントピカル読書で違うのは主体が読者にあること。読者の言葉で著者の理解を顕し、読者の問いに対する著者の答えから論点を見出し、その論考を分析する。 分析の中で意見が対立するとき、独善的に答えを判断しようとするのでなく、客観的で公平な立場でもって分析しなければならない。これが難しいと。 著者の言葉を自分の言葉に翻訳する時に読み違えるなよってことと思うが、読み込むこと以外でどうバイアスを除くかは難しいよな。

2024-10-30

本を読む本, read count: 1, page: 219 ~ 227

14 シントピカル読書―読書の第 4 レベル。 1 つの主題を定めることの難しさ。曖昧な同一主題をはっきりするためにもまず読書量が必要になる。 ここで点検読書をすることで短い時間で主題に関連した書物を見つけることができる。 技術書の場合、ある意味点検しやすいのかもな。自分の経験でだ身がしょぼい本を「点検」時に見分けれたことないのは多分スキル不足かな。

2024-10-29

本を読む本, read count: 1, page: 208 ~ 218

13 小説・戯曲・詩の読み方。 小説はなるべく短時間に没入して読んだほうが良い。現実を離れその世界を経験するところに意義がある。 戯曲も同じ様に読むべきだが、舞台を前提としている点で小説のような背景の描写がないので、想像力が求められる。 戯曲も詩も声に出してみると良い。リズムや韻を通して理解できるものがある。 大人になってから戯曲とか詩とか読んだことないわ。挑戦してみるか。

2024-10-28

本を読む本, read count: 1, page: 197 ~ 208

13 小説・戯曲・詩の読み方。 文学を読むのは教養書を読むのより難しい。なぜ面白かったかを知るのが難しい。 ある意味積極的な受け身でもって感動を妨げぬよう「文学の影響力に抵抗してはならない」 また教養書と同じ接し方で「分析してはならなず」、同じ尺度で「批判してはならない」。 とはいえ教養書と同じ規則が適用できる点もある。 カテゴリ・あらすじ・全体の構成の把握や解釈、作品を楽しんだうえで批判する努力など。

2024-10-27

本を読む本, read count: 1, page: 180 ~ 196

12 読書の補助手段。 付帯的読書。名著が前の時代の知識を引き継ぐ大きな流れの一部ってのは、技術書でも同じやな。 注釈書や抜粋はチートたりうるため読者自身の思考の機会を奪う可能性がある。 辞書・百科事典は知識の補完に使うが、使うには良い方を知っていたり質問できる知識が必要になる。 今どきだとわからない言葉に対しては検索で済ますこと多いな、と思った。 表面的な理解になるからそこは物理・電子の参考図書でも同じか。

2024-10-26

男のスコッチウィスキー講座 100 蒸留所 巡礼試飲旅, read count: n+1, page: 152 ~ 253

少し前に Angus Dundee 社の The Double Peat って酒を手に入れたのだけど、アイラとスペイサイドのブレンドらしく、スペイサイドのピーテッドモルトって何だ？と思ってリファレンスとして調べた。 結局わからなかったが。この本はこの本でとてもおもしろいので価値はあるのだけど、 10 年以上前に買ったやつだし、より網羅的な定番の本も欲しいなと思った。

2024-10-25

本を読む本, read count: 1, page: 177 ~ 180

12 読書の補助手段。 読書に、ある本一冊だけを読む本質的読書と他の助けを借りる付帯的読書とする。これまでの規則は前者に適応される。 しかし誰しもそれまでに読んだ本や経験からの知識があるので、全くの本質読書はない。 経験には日常で得られる普通経験と科学実験のような限られたシーンでしか得られない特殊経験がある。これらは本の種類に応じて関わりが違う。 経験で以て評価するってのは特に手法を説くタイプの技術書に対してよくやるな。結局どっかの誰かの持論なので経験が増えるほどそういう本は批評しやすくなる。

2024-10-24

本を読む本, read count: 1, page: 160 ~ 176

11 著者に賛成するか反論するか。 反論や判断保留の詳細を述べてる。 反論の根拠として、知識不足・誤認識・推論間違いを示すか、或いは全体的な分析の不完全を明らかにする。 前者のいずれの根拠もなければ、即ちそれは著者の意見にある程度賛成しなければならない。 反論の根拠のケースを挙げると、新事実による情報の陳腐化や、著者自身の時代背景によるバイアス等。 そして分析読書の規則のまとめ。この箇条書き便利やけどもっと早く気づきたかったな。点検読書してたら見つけてたなコレ。

2024-10-23

本を読む本, read count: 1, page: 144 ~ 159

10 本を正しく批評する。 分析読書の第三段階。批評。批評の第 1 規則。本を理解したと確実に言え、そのうえで賛成・反対・判断保留の立場を明らかにする。 批評の第 2 規則。反論は筋道を立ててすること。けんか腰は良くない。 批評の第 3 規則。反論は解消できるものだと考えること。 読書は著者との対話であるので、最低限理解して著者と同じ目線まで登ってからでないと対話にならない。 「わからない」も批評的判断だが、単に読み方が悪いだけだったり、その本だけで理解が難しいこともある。 読書の成功は知識を得ることにあり、その目的を見失わないこと。誤解と無知による反論がほとんどである。 賛成・反対・判断保留にしてもその根拠を示さねばならない。 まじめにちゃんと読み込んで誠意を持って批評しろよって感じか。

2024-10-22

本を読む本, read count: 1, page: 126 ~ 143

9 著者の伝えたいことは何か。 第 6 規則 もっとも重要な分を見つけ底の含まれる命題を見つける。命題を自分の言葉で表現できて初めて見つけたといえる。 第 7 規則 一連な分から基本的な論証を見つけ組み立てる。パラグラフ(日本語でいう段落でなく意味段落か)から論証が見つからない場合は命題を拾い集めて組み立てる必要がある。 著者自身の判断(肯定/否定)が 6 で、その理由が 7 。 第 8 規則 著者の解決が何であるかを検討する。解釈の 3 規則(第 5 ~ 7 の規則)から解決できたこと・ぶつかった課題・できなかったことを知る。 この 8,9 のセクションあんまピンときてなくてふわっとしてる。実際に本を読むときにここは〇〇で～みたいに意識的にしないと身にしみて感じられないかも。

2024-10-21

入門・倫理学, read count: 1, page: 1 ~ 26

輪読会のやつ。はじめに、とⅠ倫理学の基礎 1 章 倫理学の基礎。 現代的な倫理学の基本的な考え方について。 直観(感ではない)はそれだけで自明足りうるが、衝突する場合には理論的に解決する必要がある。 また直観は経験や常識に基づくため旧来の偏見を含むことがある。 合理的な倫理的判断は、事実と価値(観)を区別し、一貫性、公平性が必要となる。 おもしろい。日本の文脈に則した英米系の倫理学入門書という立ち位置みたい。あと BOX に書かれてる内容が本文で出た話を深めて良い。

2024-10-21

People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け, read count: 1, page: 286 ~ 318

輪読会のやつ。今回は宿題。 日本語版解説と書いてるが当書籍のモデル Code for Japan に当てはめて説明してる。 あんま解説って感じではないかな。そういう一例だと思って読むのが良い。

2024-10-21

本を読む本, read count: 1, page: 109 ~ 125

8 著者と折り合いをつける。 分析読書の第 2 段階、第 5 規則。重要な言葉を手がかりに著者と折り合いをつける。重要な言葉を見つけ、その言葉の指す意味を正確に掴む。 言葉自体は曖昧であり、その言葉を著者と読者の間で同じ使い方をして初めて思想を共有できる。 重要な言葉の探し方は色々ある。日常語でないもの、著者が強調しているもの、他の著者と違った使い方をしているもの。 重要な言葉の意味を掴むには前後の単語を総動員してパズルのように掴む。決まった方法はない。 重要な言葉は複数の意味で使われることもあるが、読み手にわかるようはっきり使い分けているなら曖昧さを含まない。 重要な言葉は単語・短い句・長い句で同じものが表されることもある。これはよりはっきりと読者に理解させたい意味を示す。 この章の規則はちょっと難しいな。概ね何度も繰り返し使われる言葉だったりする気がしてたけど。技術書はそのへん曖昧な言い回し少なくて優しい部類なのかも。

2024-10-20

本を読む本, read count: 1, page: 87 ~ 108

7 本を透視する。 分析読書の第 2 規則。自分の言葉で要約する。これは「どんな分類か」では主題や目的を把握すること。 分析読書の第 3 規則。本の各部分がどのように統一性を持って順序付けらた構成をしているか示す 。 2 つの規則は密接に関係しているが、分けることで段階的に理解できる。第 2 規則は本の全体像を、第 3 規則は本の骨格を把握する。 分析読書の第 4 規則。著者の問題としている点は何かを知る。意図を組まずして統一性を見出すことはできず、骨格が何のためのものか知ることはできない。 ここまでの 4 つの規則を実践できて、分析読書の第一段階となる。 ここまでひとつの本に深く切り込んで考えようとしたことなかった気がするわ。あーなるほどねという他の知識とのグラフ的な繋がりを作りイメージはあったけど。

2024-10-19

本を読む本, read count: 1, page: 66 ~ 86

6 本を分類する。分析読書の第 1 規則。フィクション・ノンフィクション、教養書か否か、教養書であれば理論的なのか実践的なのか。 この本は「実践的な」本に分類される。 なるべく早い段階で、できれば事前に点検読書で分類が把握し、特定のカテゴリの中で役に立つ本なのかを見極める。 書名・表題について深く考える。直接的に分類できなくても序文・目次・索引から(それでも分からなければつまみ読みから)のシグナルで分類できる。 ただしシグナル自体にも疑問を以て受け取る必要がある。 ここまで分類に注意するのは、科目によって教師の教え方が変わるのと同じく、分類によって本の読み方が変わるから。 そうか～という感じ。無意識にやってたであろう分類、意識的にやろか。

2024-10-18

本を読む本, read count: 1, page: 52 ~ 66

5 意欲的な読者になるためには。 何に関する本で、何がどのように詳しく述べられていて、全体として真実またはある部分が真実なのか、それにはどんな意義があるのか。読者は積極的に問わなくてはならない。 書き込みでもって本と対話する。 読書の規則を 1 つずつ練習して滑らかにつなげて習慣とする。 書き込みは付箋貼って昔はやってたけどは長らくやってないなあ。 メモを取っても PAA はやめて PDA 的にやるようになった。時代の流れかの。

2024-10-17

本を読む本, read count: 1, page: 39 ~ 51

4 点検読書ー読書の第二レベル。 読むに値する本か組織的に「点検」する。表題・序文、目次、索引、帯のキャッチコピー、結び、重要そうな章をつまみ食いする。 表面読みは、一度で理解できなくても最後まで読み通すことで次の読書の土台になる。 目次の点検苦手でやってないからもうちょい気合い入れてやろう。索引は結構気になって見るねんよな。 索引がしょぼい本はあとから読み直すときにつまみ読みしにくねんよな。

2024-10-16

本を読む本, read count: 1, page: 32 ~ 38

3 初級読書ー読書の第一レベル。 高等教育までには身につけるであろう読書スキルを想定してる。 愚痴が多いけど、そんだけ身についてないやつが多いってこっちゃろな。 素朴に読んでだらこのレベルに留まってんやろからこの先に進も。

2024-10-15

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 242 ~ 269

Part 4 Chapter 13 コーディングにおける共同作業 新しい開発者のオンボーディング。これで終わり。 シニア開発者とジュニア開発者の間には、大量の長期記憶の差があり、結果としてシニア開発者の与える大量の情報が認知的負荷をかけ過ぎてしまうことがある。 初心者プログラマの行動を新ピアジェ主義モデルで理解する。初心者プログラマの理解のプロセスは意味波(理解のため抽象と具象を行き来する)に従う。 これらを踏まえたうえでオンボーディングを行うと。 いまこういうことに関わる機会ないのでそういう機会が万一あった時に備えて心の中に留めておく。 一通り読んだので、自分や誰かの理解がイマイチでも認知プロセスのどのへんに問題があるのかくらいは気を使うきっかけは持てたかもな。

2024-10-14

本を読む本, read count: 1, page: 26 ~ 31

2 読書のレベル。 初級読書(本が何を述べているか理解する)、点検読書(短い時間で素早く全体を把握する)、分析読書(時間の制限なく本の理解を深める)、シントピカル読書(1 つのトピックで何冊も相互に関連付け理解を深める)。 どうも今の理解度だとうまく言葉にできてなそうや。

2024-10-13

本を読む本, read count: 1, page: 1 ~ 25

積読消化。1 読書技術と積極性。 完全に受動的な読書はなく、情報を受け取るにも積極的に頭を思考して著者の意図を理解する。高度な本であればなおさら。 読書はある意味、教師から学ぶ行為である。ただし問いなおすことはできず、ただ与えられた情報から自発的に理解を深める点では、発見する行為といえる。 今がむしゃらに本読んでるだけなのでこういう本で読み込みのレベルが上がると更に良さそうよな。

2024-10-12

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 225 ~ 241

Part 4 Chapter 12 コーディングにおける共同作業 より大きなシステムの設計と改善。 コードベースの認知特性を予測する術として Chapter 11 で出た CDN(Cognitive Dimensions of Notation) から派生した CDCB(Cognitive Dimensions of Code Bases) がある。 13 の次元を持つ。エラーの発生しやすさ、一貫性、拡張性、隠れた依存関係、暫定性、粘性、段階的評価、役割表現力、マッピングの近接度、ハードな心的操作、副次的表記、抽象化、視認性。 エラーの発生しやすさを下げると粘性が高まる等、特性はトレードオフの関係にある。 特性はプログラミング言語・フレームワーク・エディタのようなツールの選択で決まるような制御しにくいものもあれば、コードの構造的・言語的な問題で改善できるものもあるのは救いか。 どの特性を重視するかはチームのスキルセットや好みの問題やろな。言語の選択によってエラーの発生しやすさを上げてまで粘性を高めたいとは思わんかな。 暫定性と段階的評価は REPL でカバーできそうやなと見えるし、言語やフレームワークの選択は固く、それで下げた特性はツールでカバーて感じが好みか。

2024-10-11

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 209 ~ 224

Part 4 Chapter 11 コーディングにおける共同作業 コードを書くという行為。 プログラミングは 5 つの活動で構成される。検索・理解・転写・増強・探索。それぞれに異なる認知システムを利用するので適したアプローチが異なる。 プログラミングではゾーンに入るのに時間がかかり、一度割り込まれると戻るのに約 25 分かかるので、戻るための目印を置く＝ロードブロックリマインダ。これは後述のテクニックを使ってる。 割り込みから復帰しやすくするための 3 つのテクニック。 1 コードのメンタルモデルを保存する、 2 展望記憶(TODO のような未来の記憶)を補助する、 3 下位目標のラベル付け(解決ステップを細分化したテキスト)。 割り込みを防ぐための FlowLight わろた。集中してる時赤色点滅してたら気になりそう。マルチタスクできないのはもう昔からわかってるもんね。やらぬが吉。

2024-10-10

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 188 ~ 208

Part 3 Chapter 10 より良いコードを書くために 複雑な問題をより上手に解決するために。 問題解決を構成する要素はゴール状態・スタート状態・ルール。最適な方法で状態空間を遷移してゴール状態に到達するのが問題解決。 問題解決能力向上には自動化と範例というテクニックが使える。 自動化は、潜在記憶(手続き記憶)≒無意識にタイプする等の肉体的な記憶。認知不可をかけないが、負の転移を起こしがちなので学びほぐしが要る。 潜在記憶は長期記憶を形成するテクニック(間隔を空けて反復する)で強化できる。 範例は、問題解決のためのレシピを利用した学習。レシピが学習関連負荷を下げて脳が忙し過ぎて記憶できない状態を避け、長期記憶を形成しやすくする。 なんか何事も練習あるのみって感じやなやはり。

2024-10-09

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 173 ~ 187

Part 3 Chapter 9 より良いコードを書くために 汚いコードとそれによる認知負荷を避けるための 2 つのフレームワーク。 コードの臭いは構造的アンチパターンで、名前は言語的アンチパターン(概念的)。 構造的アンチパターンはワーキングメモリに負担をかけ、誤ったチャンク化を引き起こす。言語的アンチパターンは負の転移を引き起こす。 コードの臭い。一部は OOP の文脈に依存してたりあまり一般化できるものではないねんよな。エッセンスは FP とか他の文脈にも活きるねんけど。 恐らくそのエッセンスと思ってきたところが認知プロセスに関わる部分なんやろな。

2024-10-08

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 161 ~ 172

Part 3 Chapter 8 より良いコードを書くために よりよい命名を行う方法。 略語が指す意味がそれほどコンセンサスが取れてないから略さない方がいい。 キャメルやスネークそれぞれ一長一短あるが全体として一貫性がとれてたらどっちでも良い(でもゼロから始めるならキャメル推しらしいが)。 誤った名前がバグを導くかは因果関係があるとは限らない。 雛形を少なくし、フェイテルソンの 3 ステップで名付けることで品質の高い命名ができる。 コレだけ読むと、キャメル＆ケバブで推奨される動詞が決まってる PowerShell の cmdlet 命名アプローチは勝ち筋やん。

2024-10-07

People Powered 「ビジネス」「ブランド」「チーム」を変革するコミュニティの原則 遠くへ行きたければ、みんなで行け, read count: 1, page: 269 ~ 285

輪読会のやつ。 これまでの総集編という感じなので特に新しいキーワード等はなかった。 ただ、できませんでしたじゃないねんぞッてあたりや、完璧でなくてもいいが追い求めろよというあたりは、強い気持ちを感じる。 また、もう一度この本を読み直せよって、学び続けることの重要さを示してるあたりもエモくて良かった。 あとは日本語版解説だけなので、これで本編は終わり。

2024-10-07

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 147 ~ 160

Part 3 Chapter 8 より良いコードを書くために よりよい命名を行う方法。 名前はコードの大部分を占める。名前の文法を適用することで名前の品質を高め、チャンクを促す、ビーコンになる等して短期記憶・長期記憶を助ける。 命名の難しいのは linting できないとこと感じてるのでバトラー方式の linter ないんかな。

2024-10-06

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 131 ~ 146

Part 2 Chapter 7 コードについて考える 誤認識：思考に潜むバグ。 学習した知識が他の分野でも役に立つのを転移(transfer)という。 同じ領域の学習が容易になるのを学習中の転移(transfer during learning)という。 長期記憶に格納された知識が学習に役立つのは学習の転移(transfer of learning)という。名前似過ぎてややこし... 転移にも種類がある。 無意識にスキルを伝達する一般道の転移(Low Road Transfer)、意識して伝達する高速道路の転移(High Road Transfer)、対象の領域の遠近で近転移、遠転移、 学習に良い影響を与える正の転移、悪い影響を与える負の転移。 遠転移はほとんど自然発生することなく、適切に近い領域に転移することがよい学習効果につながる。 負の転移が誤認識を生む。これを抑制するために概念変化(conceptual change)でメンタルモデルを置き換えたり、抑制によって正の転移を促す。 ただし正しいモデルを構築しても古いモデルが邪魔をすることも常に起こり得る。

2024-10-05

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 109 ~ 130

Part 2 Chapter 6 コードについて考える プログラミングに関する問題をよりうまく解決するには。 コードの読解にメンタルモデルを利用する。メンタルモデルはデータ構造やパターン。 想定マシンはプログラミング言語が何をしているかを抽象化するモデル。理解の際に記憶に定着した誤ったモデルが利用されることもある。 これらのメンタルモデルは互いに競合せずに問題に適用することもできる。長期記憶のスキーマと強く関連づくものほど有用。 結局のところ身近な概念で振る舞いを表現するから、自身の持つ語彙力が貧弱だと貧弱になりうる。 つまりちゃんと勉強しろよって話に聞こえるよな。メンタルモデルそれ自身もどれだけ手札があるかという話だし。

2024-10-04

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 93 ~ 108

Part 2 Chapter 5 コードについて考える コードの深い理解に到達する。 コードの読解に関してクヌース先生だけ別格でわろた。 Coders at Work 家のどっかに積んでるわ。 プログラムの読解には言語能力が強く関係しており、自然言語を読むためのテクニックがコード読解にも使える。 過去の知識の活性化、読解の監視、コードの重要性の判断、変数から推論、コードの可視化、自問自答、コードの要約。 こうやってキーワードを羅列するとフレームワークのようになるけど、こうなると個人的に全然やらなくなるタイプのやつ。 特に手で表を書き出すとかが字も図も下手で苦手なのでなんかいい感じに自分のスタイルに組み込みたいな。

2024-10-03

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 77 ~ 93

Part 2 Chapter 5 コードについて考える コードの深い理解に到達する。 変数の役割フレームワークは読み解くときにマーキングの方法だけでなく書くときにも使える。 チャールズ・シモニーのハンガリアン記法の正しい使い方にも可能性がある。 ただいずれも強制力がないからなあ。 どこからコードを読み始めるかという起点がフォーカルポイント。 これってエラーログとかの外的要因で明確なら困らなさそう。 読解するのが目的だとエントリポイントや関数の先頭からとか、より難易度高くなる選択肢しかないんやろな。

2024-10-02

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 57 ~ 76

Part 1 Chapter 4 コードをより良く読むために 複雑なコードの読み方。 コードが複雑だとコレまでの手法は通用しない。問題の処理に用いられる短期記憶＝ワーキングメモリが 2~6 個しか同時に処理できないため。 課題内在性負荷＝問題自身の複雑さ、課題外在性負荷＝コードの書き方や読み手の知識不足に起因する複雑さ。 複雑で読めないコードには認知的リファクタリングを施すか、依存関係グラフ、状態遷移表といったツールで理解を深める。 仕事なら認知的リファクタリングという選択はあるかな。趣味プロであえてやる意味ないし好きじゃないな。 妙にリスト内包表記が槍玉に上がっててかわいそう...

2024-10-01

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 41 ~ 56

Part 1 Chapter 3 コードをより良く読むために プログラミング言語の文法を素早く習得する方法。 現在の科学でわかっているのは、長い期間期間をかけて勉強した方が長く記憶に留まるということ。 記憶には貯蔵強度と検索強度があり、すぐ記憶から引き出せないのは検索強度が低いから。 この状態を web の検索とかでカバーしてしまうと検索強度が上がらないままになる。 意図的に思い出そうとすること≒想起記憶、また覚えたての概念を他の既知の概念につなげる精緻化≒推敲が強度を高めるのに有効に働く。 素早く習得できたことないので参考にしよ。

2024-09-30

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 15 ~ 40

Part 1 Chapter 2 コードをより良く読むために コードを速読する チャンク、感覚記憶、アイコニックメモリ。 パターン、コメント、ビーコンの適切な利用がチャンクを形成するのを助ける。 長期記憶にパターンが充実してるほど、短期記憶のスロットを節約でき、効率的に記憶できるってか。

2024-09-29

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: 1 ~ 14

Part 1 Chapter 1 コードをより良く読むために コーディング中の混乱を紐解く 知識不足 = 長期記憶、情報不足 = 短期記憶、処理能力不足 = ワーキングメモリ。 長期記憶がストレージ、短期記憶 = RAM、ワーキングメモリ = CPU 。これらはわかりやすく抽象化してるだけであることに注意。 実際は、例えば短期記憶に欠落する情報でも長期記憶内でパターン化された情報を参照して推測したり、相互に作用している。

2024-09-28

プログラマー脳 優れたプログラマーになるための認知科学に基づくアプローチ, read count: 1, page: iii ~ xviii

積読消化回。 10 年以上前にリファクタリング・ウェットウェアを読んだ時からこういう本は好きなので。 見た感じワーキングメモリにも触れてるぽい。脳のワーキングメモリを鍛える！もだいぶ前読んだので学びほぐしみたいな感じで臨む。 ファストアンドスローも持ってるけどどこに行ったかわからなくなってるしこの機会に探し出そう。

2024-09-27

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 222 ~ 242

付録。ドキュメンタリアンの採用、ドキュメントに取り組み続けるためのリソース等。 htmltest は知らなかったがすぐ使えそうなので試してみる。あとがきにもあるがあとは実践あるのみよな。 仕事と趣味プロでドキュメントライティングを実践していこう。

2024-09-26

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 208 ~ 221

chapter 11 保守と非推奨化。これで本編は終わり。お気持ち表明みたいなのなくあっさり終わったのが本書らしい気もする。 サービスとドキュメントのリリースを同期するのとか、リファレンスの生成、保守作業の自動化らへん。 7 章でもそうだったけど本書は自動化に慎重派で、 toil を見極めてやれよと。 web ドキュメントが標準の原題だと削除って選択肢はなかなかないやろうな。実際よくページが無くなって困るし。ページ残して新しいのに流すか、自動でリダイレクトか...

2024-09-25

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 192 ~ 207

chapter 10 構成。情報アーキテクチャ出てきた。ずっとやらずに来てるなー。 情報アーキテクチャで利用者がコンテンツのメンタルモデルを作り上げるのを支援するらしい。 作って終わりじゃないので保守に本質があると思うしメンタルモデルを検証し続けるって書いてるけど、それは次の章みたい。

2024-09-24

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 172 ~ 191

chapter 9 品質測定。前半は知らないことが多く、ほーという感じだった。 Textlint は使ってるけど、 HemingwayEditor も試してみよう。測定するまでもなく機械的に改善できるならあらかじめやっておきたいよな。 なんかプロジェクトの KPI を定めるのと同じような印象を受けた。

2024-09-23

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 157 ~ 171

chapter 8 フィードバックの収集とその対応。 課題の完了をユーザに通知するのを推奨してるが、しないとこ結構ありそうな印象。どこぞのクラウドも皆無だったし。 ユーザーコミュニティの設立についてはサラッと触れられてる程度。 People Powered 読んだ感じ思いつきで始めれるもんでもないし、ここで深追いする話ではないからそんなもんか。

2024-09-22

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 145 ~ 156

chapter 7 公開。 結構重厚なフローやけど会社のサービスのドキュメントともなればそういう感じかも。 CD してないと詰むなと思ったが、はじめは toil を実感するためにシンプルに手動でやるとのこと。そうなのか... 自作のツールはリリースノートちゃんとやってないしはじめてみるかー。

2024-09-21

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 125 ~ 144

chapter 6 画像や動画といったビジュアルコンテンツ。 視覚的により読者に理解しやすいが、アクセシビリティの配慮と陳腐化の速さに難しさがある。 インフラ構成図とか書くといつも線が絡まるので、そもそも図を書くの難しいねんよなと思っている。

2024-09-20

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 107 ~ 124

chapter 5 サンプルコード。 目的が明確で簡潔で正確で拡張可能であること。テストされてて自動生成でサンドボックスがあって、みたいな話。 そーいや前 .NET のドキュメントの repo 見たときもスクリプトは分かれてたなー、そういうあれか。つながった。

2024-09-19

ユーザーの問題解決とプロダクトの成功を導く エンジニアのためのドキュメントライティング, read count: 1, page: 93 ~ 106

chapter 4 編集。 技術的な正しさと必要うな情報の完全性はやってそうやけどその後の構成とか簡潔さの編集は中々訓練してない難しそう。 フィードバックの受け方送り方。 plussing は覚えとこう。 ストーリーにもあるけどコードレビューと同じなので HRT を意識したいところ。

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

冒頭を読んだだけ。なんとなく丁寧な印象を受けた。