［読書］WEB+DB PRESS Vol.132
WEB+DB PRESS Vol.132 を読んでのメモ。
池澤春菜の SF 小説の歩き方 第3回「古今東西、SF が描いた AI たち」
- アイザック・アシモフ『サリーはわが恋人』
- 筒井康隆『お紺昇天』は自薦短編集『睡魔のいる夏』に収載の由
- トーマス・M・ディッシュ『いさましいちびのトースター』
- 久永実木彦『一万年の午後』は Genesis 一万年の午後 創元日本 SF アンソロジーに収載
- ウィリアム・ギブスン『ニューロマンサー』
- テッド・チャン『ソフトウェア・オブジェクトのライフサイクル』は『息吹』に収載
知性を持った車といえばなんといってもエクスカイザーはじめ勇者ロボシリーズ、と思ってしまう世代。あと2輪車ならバトルホッパーやオートバジンなども外せない。この手のものは総じて大好き。
今の話として考えると、AIごとスクラップにしなくてもクラウドなりなんなりに上げておけばいいじゃん？ ってなって、あんまり情緒がないのだけれど……
つまり SF の AI ってある時期までハードウェア実装だったということですよね、たぶん。キカイダーの良心「回路」しかり。
サバンナ便り ソフトウェア開発の荒野を生き抜く 第4回「テストダブル 忠実性と決定性のトレードオフを理解する」
- テストダブル：テストのために「偽物」を使う技術の総称
- スタブ
- スパイ
- モック
- フェイク
- テストダブルの利点
- テストしにくいものをテスト可能にする→網羅性の向上
- テストの速度と決定性を向上させる
- テストダブルは本物より動作が高速
- テストダブルの動作からは外部環境への依存性やランダム性を除去できる
- テストダブルの注意点
- テストが脆くなり、変更を妨げる
- テストしにくいのは設計が悪い兆候。ただテスタブルにして現状を追認するのでなく設計を改善すべき
- テストの偽陰性を招く
- モックドリフト：テストダブルを使ったために、本物のふるまいが変わったことをテストで検知できないこと
- テストが脆くなり、変更を妨げる
テストダブルは、テストに偽物を使うことで、本物を模した度合い（忠実性）を下げる代わりに、速度と決定性を向上させる技術です。これはテスト設計におけるトレードオフであり、正解はありません。 具体的には、テストダブルは、テストサイズの観点ではテストサイズを下げ、テスト範囲の観点ではテスト範囲を狭めるための技術と言えます。
ユニットテストを書き始めたころ、モックやスタブを使えばおおよそどんなものでも力技でテストできてしまう万能感に駆られて突き進んだ結果、モックドリフトを頻発させてシュンとした思い出。
特集1 オブジェクト指向神話からの脱却
きしださんの力作。
目的について。
本特集を読んでいるみなさんは、オブジェクト指向がちょっと気になりながらも、後回しにして優先度の高い事柄を勉強するということが多いのではないかと思います。そして本特集を最後まで読んでも、特に今の開発方針を変える必要はないという結論になるのではないかと思います。ただ、少しもやもやが晴れたらうれしいです。
[...]今筆者が問題だと思っているのは、プログラミングの勉強を始めた人が必要以上にがんばってオブジェクト指向しようとするところを見かけることです。[...]本特集でオブジェクト指向技術の現在の扱われ方をまとめることで、すぐにではないにしても、オブジェクト指向を神話のように扱って過度にもてはやすことなく、プログラミング教育の場で適切に教えられるようになればと思っています。
クラスには多彩な機能がある。
- 抽象データ型
- モジュール
- 構造体の拡張
- 部分型
- 多態
- 実装の共有
オブジェクト指向方法論での図のほとんどは、システムをどのように作るかといったシステムの内容を表すものでした。[...]しかし、実際にシステム開発でコードを書く前にまとめておくべきことは、システムの内容ではなく、むしろシステムの外側です。どのようなユーザーがどのような状況でどのような要求を満たしたいのかといった、システムが使われる問題領域を知ることが大切です。システムが使われる問題領域のことをドメインと言います。問題領域に対して、システムをどのように組むかということを解決領域と言います。
GUIコンポーネントではコンポーネントの状態と操作をまとめることは重要でした。また、コンポーネントを派生させて別のコンポーネントを作ることも必要でした。しかしながら、GUIコンポーネントの性質はソフトウェアのすべてに当てはまるような性質ではなかったわけです。
ソフトウェア開発全体では別の方法論が適した領域もあった。
リクエストを受け取って処理を行ってレスポンスを返すというサーバの処理は、状態を持たないことで信頼性や並列性を上げました。そこでは処理は関数的になり、オブジェクトとして考える必要性は減っています。[...]データベースではデータと操作をまとめる必要性は薄く、複雑なデータ構造はオブジェクトではなくドキュメントとして保存されるようになりました。
現代的な言語仕様や開発技法はモジュールと型を分離する。クラスは両方の機能を備えるが、両方の機能が同時に必要とは限らない。
クラスにモジュールと型の性質を見いだされたことからオブジェクト指向設計方法論がはじまりました。しかし現実的には、クラスをモジュールとして扱う場合には型の性質はほとんど不要です。
それがよく現れているのがJavaなどのWebフレームワークで使われるDIコンテナです。
しばしばオブジェクト指向とともに語られる GoF のデザインパターンには、プログラミング言語の発展に伴って不要になったものがある。
- テンプレートメソッドパターン…ラムダ式の導入により関数的に共通化できるようになった
- シングルトンパターン… Scala や Kotlin にはシングルトンオブジェクトを定義する
object構文が導入された。Swift にはスレッド安全な遅延初期化がある。またそれらがない言語でも DI コンテナでシングルトンを管理することができる
（デザインパターンを用いることで）短期的には、言語機能が足りない場合に運用でカバーするときに、そのパターンを共有し整理して利用すれば自分たちの書くコードの品質を効率的に高めることができます。そして長期的には、言語やフレームワークの設計者にフィードバックしてパターンを多数の利用者が書く必要がないように改善してもらい、パターンを個別の開発者が使う必要がなくなるというのが、デザインパターンのライフサイクルと言えるかもしれません。
ソフトウェア開発技術の進展・拡大により、ある言語の全体に特定の「パラダイム」を適用することは現実的でなくなった。パラダイムにこだわるのでなく、個々の言語機能をどう活用するかに注目しよう。
プログラミング言語のパラダイムと呼ばれたものは、結局のところ言語機能のパラダイムであって、言語全体を説明できるものでもありません。「この言語はオブジェクト指向言語か関数型言語か？」という言語の分類に意味はなくなっています。[...]オブジェクト指向や言語のパラダイムにはこだわらず、利用する言語の言語機能をいかに活用するか、ソフトウェア開発のさまざまな特性をそれぞれどう解決するかに集中するほうがよいのではないかと思います。
ソフトウェア技術の歴史にひとつの見方を示すことで、「オブジェクト指向」の重要性を相対化してくれる記事だと思いました。かといって「オブジェクト指向の名の下で語られていた理屈や技術がすべて不要になった」という主張がされているわけでもなく、むしろ「いつどんな目的で学ぶべきか」もまた歴史を参照することで見えてくるのかもしれません。「オブジェクト指向大事らしいけどつかみどころがなくて勉強できてない」と迷っている人には、「さしあたりそれでもいい」と安心させてくれる記事でもありつつ、オブジェクト指向を学ぶとっかかりを示す記事にもなりうると思いました。
22周年記念エッセイ 私が大切にしていること
寄稿は売れっ子のお三方。
PHP で複雑さに立ち向かう 第10回 PHP8.2の新機能・変更点を追う readonly クラス、 DNF 型、新たな乱数機能など
インフィニットループの五十嵐さんの記事。PHP は仕事でよく使うので、こういうサマリーはたいへんありがたい。
- readonly クラスはあればあったで使う
- ローカルな状態を持つ乱数生成器は Fiber など非同期処理をもりもり使うようになるとありがたくなるのかな
nulltruefalseの各型もまあ使いそう- DNF 型宣言は…これに限らず、複雑な方を宣言するための言語機能は「古いコードに型宣言を追加する」ためにあるのかな、と思っている。新規のコードであまり複雑な型宣言をされるのはつらいんだけど、こういう認識であっているのか
- トレイトでの定数定義は、現場でも使いたいという声があった
#[\SensitiveParameter]も必要な場面で。というかアトリビュート自体まだあんまり活用できていないかもしれない- 定数式での Enum プロパティアクセスはぜひできてほしかったもの
- 動的プロパティの非推奨化は CakePHP 使いとして気になるところ。周囲の「CakePHP から PHP に入門した」系プログラマー（謎）はそもそも「プロパティは動的なのが当たり前」と思っている節があるので、意識改革が必要…
${variable_name}なんて記法は知らなかったし、他人のコードでも見かけたことがなかった。非推奨でよしcallableの記法の整理もよし。今回非推奨になった記法はいずれも知らなかったし、なんでこんなのサポートしてたんだろう、という気持ち
フロントエンドコンポーネント駆動開発 第5回 Figma と Storybook を強力に連携する
現場に最近このへんの分野に強い人が来て、Figma や Storybook の活用が始まっていたところだった。個人的にありがたいタイミング。
