_ 詳細設計書は死んだ。とっくの昔に死んでいる。でも生き返る必要はある 流儀や呼び名はいろいろあるだろうが、ここでは3種類あることにする。 ・要件定義書 要件を定義したもので、ユースケースについて記述したものだ。 ・機能設計書 要件を機能として記述したものだ ・詳細設計書 機能を実装に落とし込むものだ で、詳細設計書って何それおいしいの？ ということだが、もちろん不味い。むしろ毒だと言うべきで、そんなものを記述するよりさっさとプログラムを書けば良いし、その時間を使ってテストプログラムを書けばさらに良い。 特に、1990年以降、オブジェクト（あるいはクラス）ライブラリが拡充され、APIがほとんどなんでもやってくれて、コンポーネントがそこら中に転がり始めてからは、単にそれらをグルーでつないでいくのがほとんどなのだから、そんなものを書いてもまったく意味がない。 しかし、実はそう単純でもない。 問

_ 伽藍、バザール、ノウアスフィア、おなべ(4) というわけで、1997年の伽藍とバザールがトリガーとなり、ネットスケープがバザール開発へ（内実はともかく）移行し、1998年にはオープンソースという言葉が走り出した。 マイクロソフトの状況はおおざっぱには次のような感じだ。 まず1995年にはWindows95が大成功した。ってことは、IBM=OS/2を叩きのめしたということだ。 次に社内でBBS（ブラックバード=MSN）かインターネットかで内ゲバ勃発。Windows95の最初のリリースには、MSNというインターナショナルなBBSのサインアップ用アイコンがついていたのだが（つまりBBS派が優勢だったのだが）、すぐにインターネット派の猛攻が始まり、モザイク由来のブラウザーSPYGLASSを買ってきてIEとして頒布開始（このあたりも、ちゃんとお金を払ってない――無料ダウンロードさせたので販売して

_ ユーザ入力の住所は怖い データベースには、ADDRESSみたいなカラムがあり、そこはvarchar(64)みたいになっているとしよう。 で、これまでは従業員が入力していた（たとえば、客が書いた配送先住所を手打ちで入れていたりとか）とする。 「これまで」というくらいだから、何も考えずにシフトJIS（でもその実体はWindows-31J）にしていたことだろう。 で、なぜかそれをユーザーがWebから直入力できるようにしてしまったとする。 これは、つくづくと相当な死亡フラグなのだが、問題となったという事例を見ない。 不思議だ。他の人たちはどうやっているのだろうか？ ユーザーは、こちらが驚くほど多様だ。 たとえば、「ザ・グレート歌舞伎町」というマンション名があるとする。 「・」を知っている人は「/」を変換するだろう。知らなくても普通はそう入力するような気がする。全然知らなくても「中黒」という用語

_ 伽藍、バザール、ノウアスフィア、おなべ(1) エリック・レイモンドの伽藍とバザールが19991997年(翻訳版の日付を最初書いていた。以降修正済)なので、もう15年も昔のことなのか。それだけ年月がたてば、ソフトウェア開発者でも、プレジデントやダイヤモンド並のいい加減な知識でいい加減なことを書いたりしたりするのだなぁと感慨もある。 感慨もあるが、少なくともソフトウェア開発そのものを仕事にしているのなら、もう少しまともな知識を持つほうが良いんじゃないか？ とも思う。 というわけで、読まずに済ませるOSSの歴史入門を簡単に書いてみたり。 ただ、どれも読めばささっと読めるものばかりなので（山形浩生の訳も読みやすい）、リンクもつけたし本物を読んでももちろん良い。 まずは、『伽藍とバザール』だ。 さて、1997年。Linuxが実用的なOSになってきたころの話だ。FSF（GNUの組織）が1980年代

_ 生存戦略そこが聞きたい secondlifeさんの『なぜ XXX がダメか』を読み、いろいろ去来するものがあるのだ。胸ではなく脳を。 特に、なぜMochiKitの選択で謝っているのかは知りたいところだ。進化が止まった点なのか、それとも別の問題なのか。前者なら、SI的な視点からは逆に安定性という意味で問題ない選択ということになるし（つまり、それはそれで参考になる選択であったわけだし）、後者ならそれはケーススタディとして知りたいところだ。 で、まあ過去10年以上、おれさまプロトコルかHTTPかとか、DCOMかおれおれXML-RPC over HTTPかとか、貴族なXMLとボヘミアンなXMLつまりDTDかWXSかRelax-NGか無手勝かとか、おれさまかStrutsかとか、おれさまかSpringかとか、ASP.NETのWebFormかMVCかとか、WFCかASMXかとか、XMLかJSONかと

_ ソフトウェアのコペ転 バージョン管理の歴史を読んでいて、そうそうSCCSと違ってRCSは最新持ちなんだよなぁとか思い出して、それからふと愕然とする。 もし、今、山奥で50年間くらいこもっていたプログラマ仙人(つまりgithubはもちろんのことrcsもsccsも知らない)が、ソース管理ツールを作るとしたら、どう作るだろうか？ 最初のコミットはソースそのものの保存となる。 次のコミットは元のソースと最新のソースの差分と……どちらの原型を保存するか？ もし、そこで次のコミットのことを考えたら、そりゃ最新を保存するだろう。 そうすれば、次にコミットも最新のソースとレポジトリから取り出したソースの差分の保存で済む。 つまり、一番頻繁に行われるのは、常に最新の取得と最新のコミットなのだから、原型としてレポジトリに保持するのは最新の内容が低コストだ。ソースコード管理という観点からは、そのほうが自然な

_ コードが無いってすげぇ ONKYO DLNA対応ワイヤレススピーカーシステム 15W+15W GX-W70HV(B) /ブラック(-) なんか、【レビュー】音声ケーブル無しで音が出る新世代スピーカー－オンキヨーDLNAスピーカー「GX-W70HV(B)」を試すというのを何気なく読んでしまって、こりゃすげぇと感じてしまった。 で、DLNAってなんだ？ って、業界団体じゃん。ということは、IEEE 802.3をなんか意味なく略してIEEEとか言うようなもんかな？ プロトコルがHTTPベースってことは、なんのことはなくTCP/IPなのか？ (HTTPは下層をリライアブルであることを必須としているわけだし） なんか音は悪そうだが、ミニステレオジャックの付け根が折れて断線する病とおさらばできるのなら、それだけでもすごいメリットだなぁと、自分のクリスマスプレゼントに買ってしまおうかといきなり悩んで

_ 電子書籍について思うところをつらつらと 実際のところ、紙の本は肉体的にいまや相当辛い状態なのだが、その一方で置き場にはそれほどは困っていない（と書いたところで、寺田に段ボール箱を何箱も預けていることに気付き愕然としたりするのだが）し、割と気楽に紙で本を買っているので、たださんみたいに電子書籍を取り巻く状況をしっかりと観て回っているわけではない。 ので、TLとか経由で目につく範囲の印象論になるのだが、どうにもまともな論議がされているようには思えない。 メディアが変わるっていうのはすさまじいチャンスが360方向に転がっているはずなのに、なんか「紙の本と値段が同じ」とかのような、はっきり言って乞食かお前はとしか言いようがない低レベルな感想とかが目についてうんざりだ。黙れ貧乏人としか言いようがないね。 電子化のメリットといえば、何をさておいても、表示の自由（拡大、縮小、反転、なんでもだ）、抽出

_ svn=織田信長説 CVSの天下が（ぼろぼろだったとは言え）長かったのは、RCSの発展解消版だからだなぁというか、いつの間にかGitが普通になっている、というところから、次のような歴史物語を思いつく。 SCCSが京都の天皇なのは良いがもちろん実権は鎌倉の北条RCS幕府にあって、それがBSDとSYSVの融合のどさくさのうちに足利CVS幕府が天下を治めることになり、長い時代が続くのであった。幕府（武家政治）は一見安定支配をしているように見えるもののエクセル管理派後南朝だの名前の後ろにyymmdd.bakという戒名付けるぞ高野山だの山名宗全VSSだのとの戦いに疲弊しているところに、ついに過去の遺物をきっぱり捨てた鉄砲伝来バイナリDBの織田信長が天下SVN（Arch今川とかClearCase武田とかをすべて撃破）。が、あっという間にBitKeeper光秀が取ってかわったのは良いものの君主弑逆ラ

_ Mingw on Eclipse もちろん、おれはWindowsではVC++を使うし、ましてEclipseは使うはずはないのだが、でも、EclipseにMingwを統合したやつが出現してVisual C++の市場を蚕食して欲しいなぁとは強く思う。 IE7, 8, 9, 10を眺めたり、WP7を眺めたりして、実に強く思うのだが、マイクロソフトは尻を力いっぱい蹴飛ばす強力な敵がいないとダメな会社なんだな。 で、VC++がC89のままってのは、やはりいろいろ厄介だ。が、おれはポリシーとしてVC++を使うわけなので、とすればEclipse＋MingwがマイクロソフトがびびるくらいにVC++の市場を奪えば、やつらは死にもの狂いで最高のC99環境をVC++に載せるだろう（それ以外の組み合わせはちょっと考えにくい）。（コマンドラインのMingwってのは趣味の世界なので敵にはならないのは、インテルのや

_ 10年 WEB+DBの1～60総集編をいただきました。というか、僕もかって寄稿したから、勝ち取りましたと言ってもいいのかも知れません！ というくらいに、価値ある1冊というかDVD1枚というか。 WEB+DB PRESS 総集編 [Vol.1～60](森田 創) DVDにはpdx（知らなかったけど、PDFのインデックスなのかな。ダブルクリックしたらAdobe Readerの検索ツールが起動した）が入っていて、それなりの速度で検索できる。 試しにartonと入れてみたら、13冊ヒットした。けど、そんなに寄稿した覚えないし？と思ったら、RubyのインストーラとしてASRが紹介されていたりするからだった。（で、今は亡きinfoseekのURIが出ていたりするけど、今はRuby MSI Packagesです） メディアがDVDだから検索そのものは早いけど、結果のPDFの表示までは多少待たされたり

_ JavaScriptで定義済みオブジェクトを使いまわす なんとなく単に遅れているだけのような気もするが、JavaScriptというプログラミング言語の特性を理解せずに使っているとしか考えられない例を見ていろいろ考える。 あるシステムを作っているのだが、そこでJavaScriptで作られたフレームワークが使われていて、そのフレームワークそのものは実に巧妙で良いのだが、利用している側がどうもJavaのウルトラサブセットくらいのつもりで利用しているみたいでぎょっとするようなコードを見て、使い方を提案してみたり。 たとえば、次のようなコードがあって、びっくりする。 function SomCommonObject(_caller) { this.caller = _caller; FrameworkObject.registerObject(this); } SomeCommonObject.

_ Javaには良い点があるのか？ Javaは本当に良く使われているプログラミング言語だから、プログラミングを知らない人でもプログラムを記述できる。プログラミングを知っているというのは、この場合、ケースバイケースで記述することができるってことだ（というか、正直なところおれが知っているプログラミングはそのあたりまでで、ケースはわかってもプログラミングがわからなくて、まずいプログラミングをすることもたくさんある）。 そのため、プログラムとは言えないソースコードをたくさん目にする機会があってうんざりした。 どのくらいうんざりしたかと言うとコーディングの掟というケーススタディ本を上梓できたくらいだ。 コーディングの掟(最強作法) 現場でよく見る不可解なJavaコードを一掃せよ! (開発の現場セレクション)(arton) というわけでうんざりしているのはJavaで書かれた妙なコードであって、Java

_ Rubyで誰がいつ呼んだか調べる Railsが、どのタイミングでWEBrickに決めているのか調べようとしたのだが、rackまで入り込んでてやたら面倒なことになっている。で、ソースを頭から読むのは早々に諦めた。 で、WEBrickの先頭にp Thread.current.backtraceと書いてRackのhandlerってやつだと突き止めた。 最初、Exception.new.backtraceと書いたらnilだったのでJavaとは違うなと、あらためて思ったりした。

_ 大辞林は無駄にはならなかった まあ、拡大した時のフォントが汚いのは我慢できるが、そうは言っても嬉しくはないなぁというか、なんと贅沢になったことか。でもやっぱり嫌だな、今となっては（アップルのデバイスに期待しているのは結局、「きれいさ」だということのようだな、と自己分析）。 一方、小さいの（オリジナルサイズ）は読めないわけではないのに、どうして、こうも気分が悪いのか考えてみると、どうも画面全体に対する小ささのバランスが気に食わないという感覚レベルでの拒否反応のようだ。というか、往年のサイドキックみたく、何かボタンを押すと、現在実行しているアプリケーションの上にポップアップされるのなら、オリジナルサイズのほうが具合がよさそうだが、もちろんiPadはそういうデバイスではない。そういう意味じゃ、極端なタイルウィンドウのウィンドウシステムを採用していると言えるのかもな。そこがつまるところは気に食

_ RESTafarian ジャー レスタファーライ レスタマン コミュニケーション イヤーア シンプル ザッツ ア シンプル ウェイ トゥ ライヴ オールモスト シンプル コミュニケーション ウェイ ジャー ラヴ レスタマン コミュニケイツ レスタマン サッチ ア シンプル ウェイ アイ アンド アイ コミュニケーション イズ アドレッサブル コズ アイ アー レスタマン アンド アイ アー レスタファーライ ジャー ラヴ ホエン ゼイ セイ ウイ マスト テイク ア コンプレックス ウェイ ウーアー レスタマン ノウズ ステートレス イズ ザ ベスト フォー デカップリング ソウ ヒット ミー ヒット ミー ヒット ヒット ヒット ヒット ヒット バット レスタマン フィールズ ノー ペイン コズ キャッシュ ミー キャッシュ ミー キャッシュ キャッシュ キャッシュ ジャー ジャー

_ 情熱と熱情 ちょっとだけレビューに参加したので、チャドファウラーの情熱プログラマーの見本刷りをもらいました。 情熱プログラマー ソフトウェア開発者の幸せな生き方(Chad Fowler) ものとしては前作のインド本の第2版だけど、よりプラクティカルなものに変わっていて（題も変わったし）、買いなおしても後悔することはないとおれは思う。特にどちらかというと成功者仲間（GitHubのファウンダーとか）のアドバイスというか自慢話というか苦労話というかのコラムがいくつか入っていて、複眼的な点もある。 というわけで、ちょっと最初に書いた文のことでも考えてみようか。 おれがちょっとだけレビューに参加できたり、その結果として見本刷りをもらえるのは、やはりそれなりの理由があるわけだ。誰かが名指しでおれをレビューに参加させようぜ、と言ってくれたということだ。 でも、おれは、それほど大したやつではない。普通

_ 自治体による電子データの扱い 住所表記について調べていたのだが、自治体によってえらく情報の出し方が異なることにびっくりした。 具体的には、地番表記から番地・号にる街区方式へ移行した場合の情報の出し方だ。 今のところ、文句なしに素晴らしいのは町田市だ。2005年から公開データは地番と番地・号を併記した地図のPDFと、地番と番地・号の対照表のPDF（テキストベースなのでコピペはできる。リードオンリーのファイルとしては適切な落としどころだと思う）を両方提供している。 例）相原小山土地区画整理事業の換地処分に伴い、小山ヶ丘一〜六丁目を新設しました。 同様なデータを提供している自治体に、茨城の牛久市がある（ひたち野地区（牛久北部地区)地番変更）。 電子データを提供するというのは、こういうことだ。 それに比べると、横浜市(港北区かも)はちょっと情けない。 港北区太尾町の大倉山1〜7丁目化だが、公開

_ 大野台3丁目の行方 相模原市の政令都市化について調べていて疑問に思った。 大野台3丁目の一部は南区と中央区に泣き別れるらしいのだが、地番はもちろん丁目名も変わらないようだから、すると相当変だと思うのだが。 書いてあるものを読むと、中央区にはいきなり大野台3丁目が登場して（1、2丁目抜きで）、南区には大野台1丁目、2丁目と普通にきて、いきなり大野台3丁目13番が出現することになる。 デジタル的には別段問題ないけど、地図とかで大野台3-13とかを探そうとすると相当やっかいな感じだ。 1年くらいたつと、名前を変えたりするのかな？

_ 手作りでSOAPしますか？ O'REILLYにJava Seb Services: Up and Runningという本がある。 Java Web Services: Up and Running(Kalin, Martin) オライリーの動物クォリティーだけあって、良い本だ。 では、万人にお勧めできる、あるいは千人がこぞって買うか？ と訊かれると悲観的な感じになる。 おもに2つの観点からだ。 この本は特にJAX-WSに焦点を当てたSOAPベースのWebサービスについて書かれている。 もし、SOAベースのシステムでSOAP連携を前提にアーキテクチャを考えるとなったら、この本は必携……となるはずだが、おれにはそうは考えられない。 つまり1つ目の観点は、JAX-WSというミドルェアを直接利用した連携にどれほどの需要があるか、ということだ。おれがこの観点から否定的なのは、IBMやMS（をイン