http://gihyo.jp/magazine/SD/archive/2025/202504
CDNとDNSの話は詳しくないし, なかなか聞かない話なので助かった.
伝わらないことを相手のせいにして自分を顧みないのはよくないけど, 分かり合えないことに無意味に責任を感じる必要もないと思う. 「時間をかけて伝えれば相手は絶対にわかってくれるはず」というのは逆方向の無理解でしかない.
とてもよかった. この特集ではドメイン駆動開発のような実際の知識の落とし込みやプログラミングパターンのような話は全く出てこない. とにかく具体的な業務ドメインの話ばかりなので, 人によっては全くピンとこないまま流し読みしてしまうかもしれない. しかし見方を変えればドメイン知識を活かした開発アプローチの具体例がたくさん載っているので, 他では得られない体験になるはず. 「自分だったらどうやってアプローチするだろうか」を考えながら読むとよさそう.
freee 人事労務の話をどっかで読んだことあるなと思ったら, 認知を優先す るか、作り込みを優先するか - freee Developers Hub だった.
「ドメイン知識に対する向き合い方」もどっかで読んだことあるなと思ったが, 似ているだけだった.
複雑なドメイン知識を身につける7つの方法 - エムスリーテックブログ
https://www.m3tech.blog/entry/2025/03/07/142214
「英語で書かれた難しそうなドキュメントを読んで何でも答えてくれるMさん、めちゃくちゃカッコいい……!!!」
これです.
全く関係ないけど, トラ技でもデータシートの読み方みたいな特集があったりして, どこもエンジニアは似たようなものだなと思った.
公式リファレンスにしろ, RFCにしろ, ある程度文脈をわかっている必要があるとは思っていて, すでに使ったことがあるような慣れているものから初めるととっつきやすいと思う.
真性乱数のメリットは最も安全に乱数を生成できることですが、生成に非常に時間がかかるというデメリットもあります。
本筋ではないけど, ここがよくわからなかった. RNGがない一般的なコンピュータだとそうなの?
カスタムインスペクションの具体例はあればあるほど良いとされている.
『レガシーソフトウェア改善ガイド』を読んだときも具合が悪くなったことを思い出した. リファクタリングをしなくて済むように日頃から慎重に設計すべきということかもしれない.
最近話題の MCP. チェックしておこう.
それなりに使うわりに上手くいかないし, 仕組みもあまりよく理解していないのでこれを機に勉強しよう.
読んでるだけで辛くなってきた. パターンマッチの難しさが身に染みる.