デザインパターンのよさが分からない人は設計に自信が持てるようになるのか問題
自分語りを少々。1
目の前にあった HTML と JavaScript と PHP と SQL が渾然一体となったコードと戦うことから始め、テスタブルなコードを自分が死なないように習得していった自分にとって、鬼門の一つは
再利用のためのデザインパターン
だった。
何しろ再利用可能なコードなんてほとんど何もなかったのだ。そんなもの分かるわけがない。
ところが世の中の「ためになる本」はオブジェクト指向やデザインパターンの知識が前提になってしまっているところが結構あって、歯がゆい思いをすることもそれなりに多かった。
そんなところに、少ない設定、少ない知識でもプロダクティブな開発ができる Ruby on Rails というフレームワークが登場したことで、自分にできることが広がった。2
Rails の支援していないもののうち、RDBMS, SQL については『楽々ERDレッスン』や『Webエンジニアのための データベース技術[実践]入門』など前提となる知識を数多く要求せずに済ませていてかつしっかりした内容のよい本がいくつもあった。JavaScript については jQuery の前に Ecma 262 を把握し、jsUnit で TDD を回すところから書き始めているので、おかしなクセがつく前にそこそこメンテナブルなコードを書けるようになっていたように思う。
それ以外の設計部分は Rails MVC の外に道を踏み外すべきと決断することはなかなかできないので「より良い」を実現できるように ActiveDecorator や Cells のような gem を足すことで避けてきたようなところがある。
それでも自分が書く分には Fat Controller や気ままな Helper はある程度避けることができ、満足しているが、しかし事前に「こう設計すべき」という明確な根拠があって避けることができているわけではないので、レビューや検収の段になって「なんでこんなことになる？」といったコードを受け取ってしまうことがままあった。3実装のレビューは「せっかく実装したし、もう時間もない」というプレッシャーとの戦いになりがちで、勢い「今回だけは」みたいなことで破綻が始まりやすい。
物理的な距離の近いレビューについては、
- コードの前に設計をレビューをする
ことである程度防ぐことはできるようになったが、それでもいざ実装となると「うぉ、そうきたか」みたいなコードを受け取ってしまうことはやはりある。
テストを書いてリファクタリングすることはできるが、理想は最初から大規模なリファクタリングは発生しない方がよいに決まっている。しかしそれには高い設計力とそれを事前に共有するための表現力が必要だ。
そんなことが可能とは、なかなか思うことができなかった。最近で言うと DDD なんかも苦手意識がある。そこまで開発開発していないというか、もっとライトに早く、という要請に応えることが多かったので、じっくり腰をすえて勉強しなきゃと思いつつ、（その感覚を得るまでは）難しいだろうなぁみたいな気がしている。
Clean Architectureを読んだ
冬休みの宿題で Clean Architecture を読んでいた。これについてはいくつか段階があって、
- ブログエントリとそれを受けての感想を読んだ状態
- Hanami を触りながらドキュメントを読んだ状態
- 書籍を半分くらい読んだ状態
で、今は3段階め。
Clean Architecture には以前から興味はあるにはあったんだけど、実は Uncle Bob 本て似たようなタイトルでそこそこ厚めの本がたくさんあって苦手意識を持っていた。どちらかというと
- Dart 2 面白そう
- クライアントサイド（Web フロントエンドやモバイルアプリ）の世界では最近 Clean Architecture が話題っぽい
みたいな流れと、それとは別にこれも以前から興味のあった Hanami について「マイクロサービス指向と言われるとなんか嘘くさいけど、Clean Architecture 意識してるとかいうものも見かけたような？」と思い直して
- Hanami 触って読んでみよう
となり、Controller と View と Template の巧みさが、
- 「あれ？ これおれが欲しかったやつなのでは？」になり、
- じゃあやっぱちゃんと Clean Architecture 読んでみるか
に至った次第。
ブログエントリとその感想みたいなものを読んでいた時は正直「詳細から抽象に依存する？ なにそれ？」みたいな感じだったんだけど、今は「あぁ、なるほど。これは一つの大きな指針になるなぁ」と感じている。
Clean Architectureは全体的には現実との戦い方の示唆に富む良書
ただし、読み手は選ぶような気がする。4
自分の場合、まず「緊急」と「重要」の違いの説明から鷲掴みであった。首がもげるほど頷いた。
また中途半端に知っていたり分かった気になっていた
- プログラミングパラダイム
- モジュール設計の原則
- コンポーネント設計の原則
についてまとまっていたのはとても助かった。併せてこれらがより良い「制約」をもたらすものという考え方にとても共感を覚えた。
何かができるようになるための考え方ではなく、何をやったらいけないか、やらないようにすべきかを考えるというのはこれまでの自分の考え方ととてもマッチしている。これは恐らく最初に刷り込まれた「他人が自由気ままに書いたコードと対峙し続けるのは人間の精神を破壊するのに十分な威力を持つ」という恐怖からきているんだと思う。Rails を始めとする「よいレール」に強くこだわっていたのはまさにそのためだ。「やればできちゃうけど、やらない」という選択だ。
そんな自分に最も沁みたのは以下の言葉。
速く進む唯一の方法は、うまく進むことである。
そして
アーキテクチャの形状の目的は、そこに含まれるソフトウェアシステムの開発・デプロイ・運用・保守を容易にすることである。
それらを容易にするための戦略は、できるだけ長い期間、できるだけ多く選択肢を残すことである。
どうしてお前はおれの大事な言葉を知っているんだい？ まさかまったく同じ考えだとは思わなかった。もちろん、恐らくすでに Uncle Bob 大好きな人の言動を見聞きしていて影響を受けている可能性はある。でも「選択肢」の考え方は自分が開発を生業として学ぶに至る前から重きを置いている言葉であり、迷いが消えていく感じがした。
いま自分の欲しいものはよいInteractorのプラクティス
Hanami の Controller と View と Template の割り切りは見事だなぁと思った。Model では command の分離がよいと思った。同時にここに当てはまらない部分、そして Entity でも Repository でも表現し切れない部分に強い関心が残った。
例の図 の右下の Use Case Interactor である。
これまでもユースケースという言葉は知っていたが、抽象的な設計のための言葉だと思っていた。しかし Use Case Intercator を起こすことができれば設計から実装を地続きに考えることができる。これはとても大きい。これまで URI 設計とデータベース設計の間にもやもやを抱えていたが、Interactor を意識し、
- Hanami::Interactor
- Interactor
などで習作を作っていくことでよりクリアに頭を整理できそうな気がしている。
※ Rails では Trailblazer::Operation でもよいかもしれない。
手離れを加速できそう
上の修練によって設計の言語化がよりスムーズにできるようになれば、これまで目の前で動くコードを見せながら一緒に触りながらでなければ伝えにくいと感じていたキモの部分について、もっと非同期に伝えることができるようになるのではないかという期待がある。
これができれば、どうしても目の前で動くものを先に見せないといけないという制約を外せる。これが外せれば、実装のレビューも設計のレビューもしやすくなるだろうし、事前に方針を伝えることもやりやすくなるはずだ。
楽しみが増えた。
あと参考
みんな大好き ngrep. でも ngrep はそのままでは localhost へのアクセスの様子は抽出できない。man にはこのように書かれているので、
-d dev By default ngrep will select a default interface to listen on.
Use this option to force ngrep to listen on interface dev.
例えば
sudo ngrep -d lo port 80 (Linuxはこうだと思う)
とか
sudo ngrep -d lo0 port 80 (BSD系はこうだと思う)
とすれば localhost に立てた Apache への通信の様子をみることができる。
ちなみに default interface の決まり方、localhost を意味する loopback interface についている名前、これらは使っている OS によって異なるので、実際にどうなっているかは各自で調べてちょ。
以前作った簡単なWebサイト向けRakefile で lftp mirror を使って一部のサイトの更新をしてるんだけど、ドットファイルが正しくミラーリングの対象になっていなかったので、この問題を修正した。正確には
全部アップするときにはドットファイルは対象になるけど、remote の list を取得するときに無視されてしまうので、問答無用でアップするだけで、local で削除しても反映されない。
という状態で、これは具体的には
.htaccess で認証を掛けていたものを外すことができない
というかなりおバカな状態になっていた。これへの対処は
set ftp:list-options -a
と設定を変更するコマンドを与えること。細かい方法はリンク先の Rakefile を grep してもらうとして、基本的には
lftp -e 'set ftp:list-options -a; mirror --delete FROM TO; bye'
って感じで使う。
うん、これで安心して使えるようになった。
ふと気になってみんなのうた製品を探し始めたのだが、CD-BOX はあっても DVD-BOX は見つからなかった。
しかし意外なところで発見。
NHKみんなのうたの映像集大成版 DVD12巻セット【ユーキャン】
どうも権利が NHK の方にないのか（そんなわけないよな）、NHK のショップにも Amazon にもない。存在するのは嬉しいんだけど、これはちょっともったいないね。まさかユーキャンには探しに行かないって。（というかユーキャンて通信教育専門ではなく通信販売もやってたのね。）
「.emacs」でいろいろ細かい設定ができるのだが、それは入門段階を済ませてから。
んー。.emacs を適切に設定しておかないと日本語の読み書きできなくねすか？ そこの部分だけは適当にコピペしてスタートしちゃうってのがよい手順かと。
あと
- Ctrl キーは A の左にないと絶対つらい
- Meta キーも Esc ではなく Alt がオススメ
- backspace がヘルプ(C-h) になる場合がある
- その場合は C-d で delete になることを覚えておくとたぶん助かる
- C-r でインクリメンタルの後方検索
- C-spc での選択範囲中にコマンドを実行するとその範囲内（リージョン）に影響する
というのは知っておくといいかも。
TrackBack に一回失敗して再送信したらなぜか本文が二重になってしまったので調整用のセクションです。
むー。
まぁ基本的にニコンの場合はマウントを変更してないから、古いボディに新しいレンズを組み合わせることもその逆も可能なので、マニュアルのレンズにこだわるのはその「まったり感」以外にはないんだよな。1そうは言いつつも、自分の場合は金ないから AF のボディに MF のレンズ組み合わせて使ってたけど。
カメラは中古市場が成熟してるし（つか手元のものはほとんど中古）、なんとかなるんだろうけど、デジタル一眼がまだちょっと納得いかない自分としてはここらでちょっとなんか手を入れるなり手を加えるなりしておいた方がよさげ。
こういうのが続いてくるとフィルムスキャナもそろそろコンシューマレベルではお役御免になってくるのかな？ それも困るなぁ。
一部ラインナップが異なるものもあるけど、だいたいは AF のレンズは MF のレンズと同等以上のものが揃ってるし。待てよ、受注生産のレンズはそのままなのかな？ ↩
from jarp.
知らなんだ。たぶん自分は面倒くさがって細かい設定はやらないけど。
http://www.fuji-climb.org/pf/news.html
日本語の方のページがあまり更新されていませんが、ついに ssh 2 に対応しました！ これで forward 目的だけで ssh 2 を使うことができるようになります。いやー、正直 Port Forwarder の開発が継続されていると思っていなかったので結構びっくり。
レイアウト変更よりもまずポットがない、ガスが電気になった、という2点が大きい。あと、朝礼が激しくうざくなった。
- しばらく前から Wiki フォーマットの標準化に関する Wiki に関するスラドの記事が面白くてちらほら書いている。Wiki に対する様々な捉え方を見ることができて興味深い。
- Win98 のサポートは終了するんだか延長するんだかイマイチ判然としない。サポート延長はデマと信じたい。イギリスのマイクロソフトは本社の意向を無視したダメ会社なのか？
- まさか出ると思っていなかった PortForwarder の ssh2 対応版。これで ttssh も対応したら喜ぶ Windows ユーザーは多いんだろな。
厨クラスではない。注の番号をいちいち気にするのが面倒なのでクラス化して番号振りを PHP で自動化しようと考えた。（12日にね。）あらかたできたんだけど、ページ末尾で注のリストを一気に出力するのと、本文脇にちまちまと出力する処理で整合性がうまいこと取れない。うぬぬ。