ライブラリからフレームワークへの去勢
いろんな想像（いやむしろ妄想？）が湧いてくる記事。
Rails はまだ本格的に使ってないので（ってか本業が忙しくなったので放ってある）この記事に対する直接の感想は書けないが， もっと広く「フレームワーク」という観点からこの記事の周辺について妄想をめぐらせてみる。
プログラム・コードを書く動機には色々あると思うが， プログラム・コードを書く行為自体が「万能感」を満たすものであるという点は指摘しておくべきだろう。 そしてその万能感故に行為に耽溺してしまうのであるが， ハマり過ぎると「ライブラリからフレームワークへの去勢」に適応できなくなる。
「Rails的世界の「安心」と「信頼」の力学」 では「オープンソースの世界は、「知らない他人を信頼した方が得になる世界」」とあるが， これはたぶんに利己的な要素を含んでいる。 すなわち， その言葉に裏にあるのは「いざとなったら俺様がやる！」という自負であり， その自負を担保として持ち寄ることで「信頼」を形成している部分もある （もちろんそれだけじゃないけどね）。 この自負のベースにあるのは（上述した）万能感なのだが， この万能感を維持するためにはソフトウェアを構成するプログラム・コードについて知っている必要がある。 たとえそれがカーネルであれライブラリであれコンパイラであれ， である。 故にプログラム・コードに執着というか耽溺するのである。 （もちろん全能感だけで書いているわけではない。 実際には全てを知って書いてる人なんていないと思うし。 後述するけど， 結局どのレイヤで断念するかってことなんだよねぇ）
ところで， 開発企業におけるソフトウェア資産の運用を考えたときに考えなければいけないのは， あるプロジェクトで生成したプログラム・コードをどのように持ち出して他のプロジェクトに流用するか（再利用可）ということだ。 この命題に対する一番安直な答えが「ライブラリ化」であるが， （この業界でちょっとでも禄を食んだ人なら分かると思うが）この運用方法は大抵破綻する。 何故ならライブラリ化する際はその使われ方をあらかじめ知っていなければならないが， （ごく簡単なプログラム・コードを除けば）現実的にそんなのは不可能だからだ。
ここで発想を転換する。 プロジェクトからプログラム・コードを持ち出すのではなく， 複数のプロジェクトをひとつの枠に入れて一緒くたに管理するのである。 これが「フレームワーク」の基本的な考え方だ。 「複数のプロジェクトを一緒くたに管理」というのは危険に見えるかもしれないが， バージョン管理やバグトラッキング等のツールを使えば思ったより簡単に運用できる。 ワークフレームの内部ではプログラム・コードの自然淘汰がおきる。 使い勝手の悪いプログラム・コードは忘れ去られる一方で， 良いプログラム・コードはどんどん改良され汎化する。 ワークフレーム内部でこのサイクルが成立すると非常に強力な武器になる。
しかし「ライブラリ」から「フレームワーク」への移行はある種の苦痛を強いられる。 自分が関与しない様々なプロジェクトまでちゃんぽんになるワークフレーム内部での作業は万能感を得にくいのだ。 「Rails的世界の「安心」と「信頼」の力学」 では「Rails的世界は、「知らない他人を信頼しないと地面が見えてこない世界」」とあるが， Rails をワークフレームの一種と考えると， その意味するところが何となくわかるような気がする。 他者のプログラム・コードをあるがままに受け入れ， 万能感を断念しなければ一歩も身動きできなくなる。 ラカンっぽく言えば「去勢」と考えてもいいかもしれない。 でもそれは「去勢」であると同時に新たな「信頼の輪」の構築への第一歩である。 「Rails的世界の「安心」と「信頼」の力学」 で語られる Rails は， そうしたフレームワークの特性を Web 全体を取り込むかたちで実装してしまっているように見えて面白い。
コントローラブルな事象のみを信じてそれ以外を排除していくか， コントロールへの幻想を捨ててアンコントローラブルな「他者」を受け入れていくか。 まるで人生のようである。 （あー， またオチがイマイチ）