Tuesday, February 27, 2007

ソフトウェアアーキテクチャ その11 - 健全なドキュメントを書く7つのルール [arch]

今回は少し趣向を変えて,ドキュメントの書き方について取り上げたいと思う.

"Documenting Software Architectures" に記述されている,「健全なドキュメントを書く7つのルール (Seven Rules for Sound Documenation)」を紹介する.

ところでこのエントリーを書きながら,e-mail や Blog を書く時にも当てはまることがいくつもあると思った.

Reference:
Documenting Software Architectures: Views and Beyond,
by Clements, et al. Addison-Wesley 2003

--> Page 24 - 30

タイトル通り,アーキテクチャのドキュメント記述方法に関する本で,SEI の Product Line Systems Program の成果物の1つとして出版された.Product Line とは,SEI の代表的貢献として有名な CMM (Capability Maturity Model) に比べれば後発だが,最近注目されているソフトウェア開発の新しいアプローチの1つであり,本シリーズでもいずれ取り上げる予定.

本書には,Appendix に ECS Software のアーキテクチャ仕様書がそのまま例として載っており,私もアーキテクチャ仕様書を記述する際に大いに参考にしている.

但し,本書には関わっている著者が多く,全体的に若干繁雑な内容になっていることは否めない.最初から最後まで読了するというよりは,必要に応じて適切な内容を参照するカタログ代わりに利用すると良いかもしれない.

こちらがその和訳本.
多くの技術書がそうであるように,この和訳書も日本語が非常に奇怪だ.特に本書はその傾向が顕著で,例えば linked list (リンクリスト) が「結合した一覧表」などと訳されている.特に本書に関しては,極力オリジナルを読まれることを強くお勧めする.


Rule 1: Write Documentation from the Reader's Point of View
(読み手の視点で書くこと)

当たり前のことに聞こえるが,驚くほど考慮されていないポイントである.

ドキュメントは,書かれる回数より読まれる回数の方が多いのだから (リビジョンを数えなければ書かれる回数は1回),読み手にやさしい方がドキュメントとして効果的と言える.読み手に対する配慮が感じられるドキュメントは「そもそも読まれる」し,繰り返し読まれる可能性が高い.内部的な専門用語なども使わないこと.

書き手中心の一方的なソフトウェアドキュメントは,"stream of consciousness" か "stream of execution" の構成を取ることが多い."Stream of consciousness" とは,書き手が考えた順に記すこと (書き手の頭の中の時系列)."Stream of execution" とは,ソフトウェアが実行される順に記すこと.どちらの構成も読み手が必要な情報を探すのに苦労する.

Rule 2: Avoid Unnecessary Repetition
(不必要な繰り返しを避けること)

同じ種類の情報は,1つの場所に記録されるべきである.これはドキュメントの利用性を高めるだけでなく,ドキュメントを変更する際の容易性を高める.

同じ情報が繰り返される時は微妙に違う表現になっていることが多く,「意図的に繰り返しているのかどうか,そうであるなら違いは何なのか…」と,読み手を混乱させてしまう.

あえて反復することで読み手の理解を深めさせることもできるだろうが,やはり基本は同じ情報を1個所に集約させること.

但し「不必要な」繰り返しというところがポイント.例えば,同じ情報を違う視点で説明する時などに情報が集約されていると,読み手がいちいちページをめくって前の記述を参照しなければならない.読み手の「コスト」を考えて,情報を繰り返すことが有効なのかどうか判断しよう.

Rule 3: Avoid Ambiguity
(曖昧な表現を避けること)

そもそもアーキテクチャとは,ある程度細かい内容 (例えば実装時に気にすべきことなど) を排除し,システムの上流設計方針を決めるものだから,多少の曖昧さは持つものである.しかしながら,意図しない曖昧さ,特にドキュメントから2つ以上の解釈ができてしまうような曖昧さは避けるべきである.

表記は厳密に定義し,正確な意味付けを心がけること.

例えばただの箱と線で書かれた図を良く見るが,その「箱」は何を意味するのか (モジュール,オブジェクト,クラス,プロセス,関数,手続き,プロッセッサなど) ? その「線」は何を意味するのか (サブモジュール関係,継承,同期,排他,コール,利用,データフロー,プロセッサマイグレーションなど) ?

凡例を設ける,異なる視点を混ぜない (違う viewtype を同時に語らない),図を書きっぱなしにするのではなくそれが何を意味するか解説する…などして,読み手ができるだけ簡単に表記の意味を捉えられるように心がけること.

Rule 4: Use a Standard Organization
(標準的な構成を取ること)

標準的,かつ計画的な構成の体系を確立すること.これは読み手にとって情報を探しやすくするだけでなく,書き手にとっても文書化のプランを立てやすくする.ドキュメントの各セクションで明かされる要素を明確にし,レビューしやすくすること.

内容の参照が容易になるようにし (ドキュメントは,端から端まで読まれるよりも,一部が参照されることの方が多いだろう),未完成部分や分からない部分は白紙にするのではなく,TBD (作業途中) ということが分かるようにしておく.

ちなみに,本書が言うところの「標準的な構成」の例については 本書 I.2 (Page 39) を参照.

Rule 5: Record Rationale
(根拠を示すこと)

決定事項だけではなく,そこに至るプロセスも非常に重要である.将来同じような議論・検討をする可能性があるからだ.

決定に至るまでにどんな選択肢が他にあり,なぜそれらが選ばれなかったのか,といった記録を残しておくこと.これは長期的な運用において,時間の節約につながる.

Rule 6: Keep Documentation Current But Not Too Current
(最新を反映するべきだが,極端に最新を追いかけないこと)

不完全な,あるいは内容が古いドキュメントは真実を表していないし,使いものにならない.常に最新にアップデートされた,精密なドキュメントこそ有効なものである.

一方で,変わるかもしれない決定を反映して時間を浪費する必要はない.特に設計時は方針が頻繁に変わるだろうが,ドキュメントをその度に改編するのではなく,むしろソフトウェアと同じようにドキュメントに対しても明確なリリース方針を立てるべきだ.

Rule 7: Review Documentation for Fitness of Purpose
(目的に適合しているかレビューを行うこと)

書きっぱなしは良くないので,レビューを行うことは当然だとして.

そのドキュメントが必要な情報を含み,分かりやすく表現されているかどうか,本当に判断できるのは読み手側であろう.ならば,リリース前に極力対象とする読み手 (例えばコミュニティの代表者など) のレビューを受けることが望ましい.


Sunday, February 25, 2007

効率的なテキスト編集の7つの習慣 [vim]

去年から Google にジョインしている vim の作者,Bram Moolenaar が,先日 Google 本社にて "Seven habits of effective text editing 2.0 (効率的なテキスト編集の7つの習慣)" と題してプレゼンを行った模様.

プレゼンは約45分,質疑応答含めて80分.
7 Habits For Effective Text Editing 2.0 - Google Video

プレゼンビデオをファイルとしてダウンロードしたい方はこちら (DivX 507MB).
ftp://ftp.vim.org/pub/vim/stuff/7Habits20.avi

プレゼン資料はこちら (PDF 640KB).
http://www.moolenaar.net/habits_2007.pdf


Vimmer にとってはヨダレもの.また,Emacs を始めとする他のエディター愛用者にとっても興味深いプレゼンだと思うので,以下に要点を意訳しておく.



日々,様々なテキスト (ソースコード,ドキュメント,e-mail,ログファイルなど) を編集するのに,時間が足らない!

このプレゼンは「いかに多くの作業を少ない時間でこなすか」について.

良いエディタを選択することが最初のステップ
(もちろんここでは Vim を用いて説明)

もし既に自分の手に馴染むエディタを使っているなら,他のエディタを試すのは時間の無駄 (このプレゼン終了後に,あなたは自分が使っているエディタが本当に良いか悩むかもしれないけど…).

もし自分にピッタリのエディタを見つけられていないなら,Vim を使うこと.ガッカリはさせないから.

3つの基本ステップ:
Step 1. 非効率な作業を認識する
Step 2: より良い方法を見つける
Step 3. それを習慣にする

以降このプレゼンは,この3つのステップをベースに「7つの習慣」を説明する.

Step 1 は非効率な作業,つまり繰り返し行ったり,時間がかかる作業を見つけること.

Step 2 は,それをいかに改善するかについて.パワフルなエディタであれば,作業を高速化するコマンドがあるはず.スクリプトを組めたり,外部プログラムを呼んだりもできるかもしれない.

また,より良い方法を見つけるのは簡単ではないので,各習慣の Step 2 の部分では,いかにそれを見つけるかの例も一緒に紹介する.

Step 3 はそれを習慣にする,つまり指が勝手に動くようになるまで,その方法を使い続けること.

なぜ「7つ」の習慣?

今回7つという数字を選んだのは,"The 7 Habits of Highly Effective People" という本にインスパイアされたから.この本は本当にオススメです.

ところで "Seven years of highly defective people" というのもある.こちらは息抜きがてらに.

さて本題.

Habit 1: 高速に移動する

Step 1:
検索する際に,対象語をいちいちタイプしていないか?

Step 2:
-> searching のヘルプセクションを参照してみる

検索する際に,"hlsearch" オプションを有効にして,検索語をハイライトし,視認性を高める."*" コマンドでカーソル位置の単語をサクッと検索する.

Step 3:
.vimrc に ":set hlsearch" を記述し,"*" を使い続けること.

folding なども非常に有効.例えば関数毎に全て fold してしまい,一覧性を高めるとか.

Habit 2: 2回タイプしない

Step 1:
長くて複雑な関数名などはミスタイプしやすい.前の記述をコピペしている人もいるようだが,それだって非効率だ.

Step 2:
-> 他の人に聞いてみる (実は聞いてしまうのが結構良い方法だったりする.自分で全ての方法を探し出す必要はない)

インサートモードコンプリーション (CTRL_N) を使う.

Step 3:
使い続けていると,どれだけタイプすればコンプリーションに十分かコツがつかめるようになる (あまりに短いと,候補がたくさん出すぎる).

変わった名前の人に e-mail を書く場合など,辞書ファイルを作ってそこからコンプリーションをするのも有効.

Vim 7.0 以降では,omni completion も追加されている.

Habit 3: 間違いはすぐに修正する

Step 1:
文章を書いた後は,ミススペルしていないか見直さなければいけない.スペルチェッカーを使ってもいいけど,それだって非効率だ.

Step 2:
-> Vim の ML を検索してみる (とても多くの質問と回答,tips などが投稿されている)

スペルコレクション用のマクロを定義する.

:iabbrev teh the
:syntax keyword WordError teh

Step 3:
スポットされた単語は自分の辞書ファイルに随時追加していく.さらにそれを行うマップを定義してもいい.

Habit 4: 関連ファイルを渡り歩く

Step 1:
新しいプロジェクトに参加する時など,ファイルの依存関係を理解する必要がある.

Step 2:
-> quick reference guide を見てみる

tags と quickfix を使う.

:!ctags -R .
:tag init
:tnext
Exuberant ctags を推奨.

そのアイテムが使われている全ての場所を探すには,grep が使える.
:grep "\<K_HOME\>" **/*.h
:cnext

他にもいろいろな方法がある.
"gf" でそのファイルに飛んでいける.
"[I" でカーソル位置の単語を含むファイルを見つけ,"[<Tab>" で飛んでいける.

Habit 5: 他のアプリとの親和性について

Step 1:
MS-Word,OOo Calc,Outlook などのエディタが使いにくい.いつのまにか ":wq" してしまう.

多くのアプリは整形されたテキストを扱うことができるが,エディターが使いにくい.Vim は良いエディターだが,レイアウトにまでは関与しない.この両者の良い点を繋げることができれば良いのだが…

Step 2:
残念ながらこれを解決する最善の方法は無い.

2番目に良い方法としては,

:set tw=0 wrap linebreak
して,コピペすること.

Step 3:
これを習慣にしても,やはりいろんなところで :wq してしまう…

Habit 6: テキストは構造化されている

Step 1:
プレインテキストでも,多くの場合はなにかしらの構造 (規則性) を持つはず.これを利用して編集作業の生産性を上げることができる.例えば lint の不必要な warnings やログファイルの余分な情報をを除去する.

Step 2:
-> スクリプトで解決する

lint をクリーンアップしたいなら,

map _cl :call CleanLint()<CR>
func CleanLint()
        g/gtk_x11.c:.*enum/d
        g/if_perl.*conversion to.*proto/d
endfunc
を定義して,_cl 実行後に :cfile % して error list に変換する.

Step 3:
lint を通した後は,_cl する癖をつける.必要な情報まで除去しないように気をつけること.

この要領で,必要なコマンドをどんどん追加していけばいい.

Habit 7: いつも刃を研いでおくこと

自分のコマンドは必要に応じてチューニングを怠らないこと.
自分自身の行動から,改善点を見つけること.

- folding
- 自動インデント
- プラグイン
- ネットワーク越しの編集
- アドバンスド スクリプティング
- などなど
を駆使して刃を研ぎすませておこう.

最後の「習慣」は,これまで紹介した習慣をどのように「習慣」にするかについて.

これまでの Step 3 (「習慣にする」の部分) は,「ただやれ」と言っているようで,当たり前のように聞こえるかもしれないし,重要ではないように思えるかもしれないが,必要なタスクを習慣にしてはじめて高速に編集作業ができるようになるのである.何も考えずにエディタを使い続けるのではなく,少しずつ洗練させて行こう.

例えば車の運転と同じ.最初はギアチェンジすること,ワイパーやライトをオンにすることなどを覚えていくが,そのうち無意識に行うようになる.ただエディタには車よりもたくさんのコマンドがあるから,1つ1つ,必要に応じて着実に習得していこう.

「コマンドを知らないことによって,どれだけの時間が無駄にされているか」「今より優れた方法を探すのに,どれだけの時間がかかるか」「そのマクロを書くことによって,どれだけの時間が短縮されるか」といったことを基準にして,将来何が必要かを考えてみよう.

非効率的なテキスト編集のしかた

- ドキュメントを読んだり,新しいコマンドを覚える時間が無い
- エディタの全ての機能が知りたがり,その一部しか使わない

つまり,「習わなければ使えない」ということ.それから「使わないコマンドまで覚えようとしない」こと.

Vim を使った効率的なテキスト編集

ユーザーマニュアル大事.

:help user-manual


…とまあこんなところ.

質疑応答の部分は割愛するが,基本的な質問から,「あなたの .vimrc を見せて下さい」との質問に Moolenaar 氏が「ヤダ」と答える場面までいろいろあった中で,1つ興味深かったのは「Open Source と Closed Source についてどう考えるか?」という質問.

Moolenaar 氏の回答は,

Open Source は基本的に楽しい.
私自身も Open Source をエンジョイしているし,これはみんな同じはず.

問題は,金を稼がなければいけないという事実.
Open Source は,どうやってビジネスに繋げるかが非常に難しい.

もちろん不可能だとは言わないが,難しい.

Open にしたいのは山々だが,様々なしがらみから Closed にしているコードもあるはず.

何をフリーにして,何をしないか,というグレーゾーンはいつも難しい.

実は Google にも同じ問題がある.
多くの Google 社員は,コードをオープンにしたいと思ってるんだ.

というものだった.


【2007/02/28 追記】
多くの方にブクマして頂いているようなので,ちょっとだけ補足.

Vim に詳しい方は,内容を見て「意外と普通のこと言ってるな…」と思ったかもしれない.確かに tips の1つ1つは,びっくりするような内容ではない.

オーディエンスが全員コアな vimmer とは限らないので,ある程度無難なところを選んだというのもあるだろうが,それよりこのプレゼンは「vim の便利な使い方」ではなく,あくまでも「効率的なテキスト編集の7つの習慣」ということ.

つまり,他のエディタ使用者も含めて,"what" よりも "how" の部分,考え方やアプローチについて言及したかったのではないかと思う.

具体的には Step 2で示しているような,「人に聞いてみる」とか「ML を検索してみる」といったアプローチ,そして各 Step 3の考え方,特に Habit 7の「刃を研ぎすませよう」というのがこの日の彼の一番のメッセージだと個人的には受け止めた.

まあ Habit 4のところで Step 3を資料に入れ忘れて,「おっと,そこはキミらで考えといてくれたまえよ」とか言ってたぐらいだから,そこまでの思惑があったかどうかは分からないが…


Friday, February 23, 2007

しがらみの向こうに [diary]

DSC01300.JPG

以前紹介した "The Winds of GOD" で映画デビューを果たした私の友人,タケウチコウが,現在演劇に挑戦している.

松本 匠さん作・演出の「しがらみの向こうに」という演劇,今日が公開初日ということでさっそく観に行ってきました.

私がタケウチコウの友人ということを差し引いても,本当にオススメで是非観に行ってほしい演劇だったので,以下ネタバレしない程度に.


これは,様々な「しがらみ」を持つ男達の物語.

なにより印象的だったことは,世の中の芝居が,定番通りのハッピーエンドか,意表をつくバッドエンドかに分かれるとしたならば,この演劇はそのどちらでもなく,ある意味エンディングが無いということ.ラストシーンで観客にボールを投げかけて終わるのだ.

私なりの言葉で表現させてもらうなら,今までオーディエンスとして演劇を見ていたはずなのに,急にステージに引きずり上げられ,「acting ではなく,real life の中で,この先をどう考えるんだい?」とつきつけられて,そのまま幕が閉じるのである.

そして,いつまでも心にひっかかったセリフ.

ホンマ,いつから「しがらみ」という言葉の意味が分かりはじめたんやろなぁ


きっとしがらみを持たない人間なんていないんだろう.

今この文章を書いてる私も.
今この文章を読んでるあなたも.

それでもジュンは,しがらみが無い世界を夢見た.まるで,「夢かもしれない,でも…」と語りかけていた John Lennon のように.


「しがらみの向こうに」は 新宿スペース107 で,2月27日まで公演中.ぜひこの週末にでもいかがでしょう.


今日は終了後の打ち上げにも参加させて頂いたが,とにかくもうみんなの圧倒的なエネルギーに感動.みんなホントにカッコいい.特に西田 武史役のマサルさん,初対面なのに,なんだかソウルメイトに会ったようでした.

DSC01287.JPG


Tuesday, February 20, 2007

100点満点の人生 - 陳 大済 [lifehack]

韓国の情報通信省大臣 (当時) である陳 大済が,とある朝食会で「100点満点の人生を作る方法」を紹介したとのこと.

まず,アルファベット順に番号をつける.A に 1,B に 2,C に 3,D に 4 …としていくと,Z は 26 になる.それからある英単語を選び,そのスペルのアルファベットの数字を全部足す.

例えば,一生懸命働けば100点満点の人生になるだろうか?
"hard work" は 98 (h・8 + a・1 + r・18 + d・4 + w・23 + o・15 + r・18 + k・11) 点.おしいが一生懸命働くだけでは100点満点になるわけではない.

ならば,知識が多ければ?
"knowledge" は96点.

運は?
"luck" は47点.

お金があれば?
"money" は72点だ.

陳長官が朝食会の参加者に聞いた.
「では100点満点は何でしょう?」

答は "attitude" です.
人生は自分の態度,すなわち「取り組み方」や「考え方」によって 100点満点になります.

というのが陳長官の結論だった.

ちなみに後日,「ストレス」(stress) と,「休みをとる」(take a rest) も100点満点になる,という指摘を受けた陳長官は,「人生自体がストレスだが,休みをとってそれをなくすことも人生だという意味ではないだろうか」とかわしたのだとか.

さらに陳長官は,人生哲学だけではなく,ゴルフがうまくなる方法もこれに隠されていると話したらしい.「ドライバー」(driver) の74点,「アイアン」(iron) の56点も重要だが,最も大事な「パター」(putter) が100点になるのが実に面白いと.


この話は 以前レビューした,「2015年のサムスン」という書籍の中のコラムで紹介されていたもの.その時は本の内容と直接関係無かった為に書かなかったが,先日この本を読み返していて,やはり目にとまったので今回紹介してみることにした.

成 和鏞
価格

サムスンブランドの未来
サムスンの過去と現在、そして未来の姿について書かれた一冊。次期総帥として内定している2005年現在...
あまなつShopあまなつで見る同じレイアウトで作成


Sunday, February 18, 2007

Blog にラベルを導入 (と,記事内に AdSense をつける時の注意点) [blogger]

この Blog にラベル (カテゴリー) を導入しました.サイドバーの "labels" 部分になります.

Blogger がバージョンアップしてからその新機能をほとんど使ってなかったけど,最近テンプレートを新しくして少しずついじり始めてます.

前と同じスタイルのテンプレートを使用しているので見た目はあまり変わってないけど,あいかわらず書く内容がてんでバラバラの Blog なので,ラベル導入により検索エンジン等で飛んできて興味を持って頂いた方には関連記事が辿りやすくなったと思います.

過去記事のラベル付けは相当テキトーだったりするけど…


Blogger がバージョンアップしてからずいぶん月日が経っており,新テンプレート導入についても分からないことは検索すれば大体解決できました.

海外の Blog を Google 検索する時は,

("new blogger" OR "beta blogger" OR "blogger beta") 検索したいこと
みたいにすると,ヒットしやすかったように思います.

日本の Blog で特にお世話になったのは,やっぱりクリボウさんと @aka さん.
クリボウの Blogger Tips
clmemo@aka: Blogger

1点,少しひっかかったこととして,各記事の中に Adsense や Amazon のアフィリエイトを設置する時のこと.

ウィジェットとして追加する場合はメニューの "Add a Page Element" から追加すればいいんだけど,記事内に埋め込みたい場合等,直接 HTML を編集する際に,これまで使用していたコードをそのまま埋め込むと "<!-- //-->" がコメントアウトされてしまう模様.

"<!--"   は   "&lt;!--"   に,
"//-->"   は   "//--&gt;"   に,
それぞれ変換すれば OK でした.


Saturday, February 17, 2007

ソフトウェアアーキテクチャ その10 - プロダクトラインでのパターン選択ケースタディ [arch]

本シリーズも前回から「実践編」というフェーズに入ったが,今回は実開発における pattern 検討の例として,第7回で reference としたケーススタディ群の別のケースを紹介したいと思う.

Reference:
Software Architecture: Perspectives on an Emerging Discipline,
by Mary Shaw and David Garlan, Prentice Hall 1996

--> Chapter 3.2

ソフトウェアアーキテクチャを最初に定義した本.

1996年発行と内容は少し古く,今日の開発に実践できる内容は少ないが,ソフトウェアアーキテクチャのいわゆる「クラシックエッセンス」に触れることができる.

エンジニアとして「自分の引き出しを増やす」という意味では,ぜひ手元に置いておきたい1冊だ.



本書第3.2章では,実際に Tektronix 社で行われた,3年越しのオシロスコープ開発プロジェクトの事例を紹介している.

このプロジェクトは,再利用性の高いオシロスコープのソフトウェアを構築し,Tektronix 社の製品ラインアップにおいてプロダクトラインを実現することを目的としてスタートした.

本書では,このソフトウェアアーキテクチャを検討するにあたり,Object-oriented pattern,Layered (N-tiers) pattern,Pipe-filter pattern を順に検討している.それぞれに,どんな問題があって採用に至らなかったのかが解説されており,実開発で pattern を選択する上で,またプロダクトラインを実践する上で,参考になるかもしれない.

そして本当に興味深いのは,彼等の出した結論が,「Pipe-filter pattern の亜種を作り上げること」だったことだ.つまり常識に縛られることなく,その組織に特化して,一般的な方法論を開発目的に沿うような形にアダプトしたことが素晴らしい.

このオシロスコープ開発の詳細や,各候補 pattern についての分析,最終的に提案された Pipe-filter の亜種と一般的な Pipe-filter の違いなどについては本書を参照頂くとして,ここでのメッセージは,どんなに優れた開発手法や本に書いてあることも「道具」にしかすぎないということである.

開発において「王道」というものは存在しない.
「道具」は使いこなして始めて意味を持つのである.

知識を得るだけで満足せずに,それを自分の環境でどう実践するかというところまで消化して,始めて役に立つと言えるのだと思う.

もちろんそれには,そもそもエンジニアとして多くの引き出しを持っていることが前提なわけだが…


もう1つ付け加えておきたいことは,開発を行う際,特に今回紹介したようなプロダクトラインを行う際には,技術面以外に重要な要素がたくさんあるということ.

具体的には,
1. プロトタイプの開発と戦略
2. 開発環境と組織形態
3. デザインレビューなどのプロセス的アプローチ
4. 適切なスペックを持った人員の確保
  (特にインテグレータやドメインエキスパート)
5. 既存アーキテクチャに対する取捨選択の見極め
  (場合によってはそれを壊す勇気)
6. 適切なツールの導入
7. マネージメントの開発組織に対する関わり方
などといったところだろうか.

特にプロダクトラインにおける,4の「適切なスペックを持った人員の確保」については,SEI の Software Product Line Adoption Roadmap というレポートの3.2.6章が非常に参考になるので,合わせて紹介しておく.

プロダクトラインに関しては,本シリーズでもいずれ取り上げる予定.


Wednesday, February 14, 2007

Google の TV に対するアプローチの真意は? [ce]

日本ではあまり話題になっていないが,海外では最近の Vincent Dureau 氏の発言が話題を集めているようだ.
Google and cable firms warn of risks from Web TV - Reuters.com

Google で "Head of TV Technology" という肩書きを持つ Dureau 氏は,OpenTV の CTO という立場から去年 Google に移籍し,去年末の「デジタル・テレビの新たな挑戦」 でも来日講演していた人.

この記事は,「YouTube などの動画配信サービスが,ネットワークを破壊しかねない」と警鐘を鳴らしている.1時間のビデオ試聴に必要なデータは1年分の e-mail に相当し,現状のインターネット上り回線のトラフィックの60%は peer-to-peer で,そのほとんどが動画であるとのことだ.

そして議論の中心は,(YouTube を買収した) Google の,TV のヘッドである Dureau 氏が,「インターネットは TV の為にデザインされたものではない」と発言したことである.

The Web infrastructure, and even Google's (infrastructure) doesn't scale. It's not going to offer the quality of service that consumers expect

(ウェブのインフラは,例え Google が持つインフラを使っても,スケールするものではない.ユーザーの期待を満たせるだけのクオリティは出せないと考える.)


さらに,とある (Google に TVビジネスの利益まで支配されると懸念していた) ケーブル会社の経営者が「Google がビデオをスケールできないなんて最高のニュースだ」と語ったというエピソードまで紹介されている.

USA TODAYPC MagazineCNET なども同様の報道をしているし,Google の主張に懐疑的な 記事 や,「数々のビジネスを破壊してきたインターネットが,その限界にきている」としている 記事 なども見受けられる.


…と,実はここまでは前置きで,本当に興味深いのは以下の記事だ.
GigaOM >> Google: Web is OK for TV (despite what you may have read)
「Google 曰く Web は TV に問題ない (あなたが何を読んだかしらないけど)」というタイトル (意訳) がつけられたこちらの記事は,世間の報道は Google が言うことを真に受けすぎだと忠告している.

この筆者が他の Google 社員に裏を取った結果,「Dureau 氏の発言はその文脈を無視して報道されており,この発言はたまたまケーブルセットトップボックスと Google 間のインフラについてのボトルネックの可能性を質問された回答として語ったもので,現実には Google のインフラは問題無くスケールするし,web で TV を見ることにもまったく問題は無い」とのことだった.

そして筆者は,この発言はむしろ「(ケーブル会社のせいで) Google が家庭まで手を延ばせないからスケールできない」という主張を語ったのではないか,と予想している.

筆者も Dureau 氏の発言を直接聞いたわけではなく,これ以上は想像の域を超えないと認めているが,まともに捉えるにはあまりに Google らしくない発言だとしている.


この記事のコメント欄にもあるが,TV 放映がブロードキャストであるのに対して,インターネットの動画配信がユニキャストであるのは事実.Google がそのインフラを活かして,Google のサーバー経由でケーブルを取り込みたい意図はあるのかもしれない.


いずれにしても,Google だけでなく,Microsoft や Apple,Yahoo など,数々のインターネット・PC 企業が,それぞれのアプローチで TV の座を狙っていることは間違いない.もちろん,これまでその位置を占めていた家電メーカーも黙ってはいない.これから,これらの企業間でどんな凌ぎ合いがあるのだろうか.我々の10年後のリビングルームは,ライフスタイルは,どんなものになっていることだろうか.


Monday, February 12, 2007

タイガー…!? [diary]

後輩の mixi 日記で知った,とあるサービス.
顔写真をアップロードすると,画像認識をして似ている有名人を割り出してくれるらしい (要ユーザー登録).
MyHeritage face recognition


これはさっそくやってみるでしょう.


まずは最近の写真で試してみると…



いや,髪型だけだろ…


坂本 龍一ぃ?


安倍 晋三て…



あまりにも微妙すぎるので,髪が短かった頃のさわやかな (?) 写真で再チャレンジ.



いや,絶対ないですから…


あんた誰?



怖いもの見たさで,その昔アフロだった頃の写真をアップしてみると…



た,た,た,タイガーウッズ…



…ふん,くだらねぇサービスだ.


Sunday, February 11, 2007

R-1ぐらんぷり2007 準決勝東京大会 [diary]

DSC00570.JPG
M-1グランプリのピン芸人版,R-1ぐらんぷりの準決勝東京大会を,ルミネtheよしもとで観戦してきました.

今年の R-1 は,去年末の M-1 で優勝したチュートリアルの徳井がピンで出場しており,二冠達成なるかと世間の注目を集めている様子 (彼は大阪準決勝大会の方に出場).


さすがに33人のピン芸を,ぶっ通しで見るのは始めて.
今日見るまで知らなかった芸人さんだけど,個人的には川村 エミコが大ヒットでした.決勝に残ったらぜひご注目を!

決勝大会は2月18日にテレビ放送です.
R-1ぐらんぷり2007


Saturday, February 10, 2007

ソフトウェアアーキテクチャ その9 - アーキテクチャ設計の実際 [arch]

これまで8回に渡って,ソフトウェアアーキテクチャの基本コンセプトを説明し,前回はその集大成としてケーススタディを紹介した.これからは,それらのコンセプトを実際にどう使うかというフェーズに入っていきたいと思う.

今回は実際に「アーキテクトのガイダンス」になるような設計の進め方について,紹介できればと思う.

Reference:
Software Architecture in Practice, Second Edition,
by Len Bass, Paul Clements, and Rick Kazman, Addison-Wesley 2003

--> Chapter 7

価格

Software Architecture in Practice (Sei Series in Software En
ソフトウェアの方式設計について実践を目的に、丁寧な解説を行っており、我が国のソフトウェア技術者が必...
あまなつShopあまなつで見る同じレイアウトで作成
アーキテクトのバイブルとされる本.SWEBOK (Software Engineering Body of Knowledge) でも推奨書籍とされている.

タイトルの "in Practice" (実践における) が示す通り,様々なケーススタディを交えつつ,非常に具体性のある内容になっている.


こちらがその和訳本.



本書第7章では,
- ライフサイクルにおけるアーキテクチャ
- アーキテクチャ設計
- チーム構成と,組織がアーキテクチャに及ぼす影響
- スケルタルシステムの構築
を扱っている.
それぞれに非常に興味深い内容だが,今回はライフサイクルについて軽く触れた後,ADD というアーキテクチャ設計手法を簡単に紹介したいと思う.


開発におけるライフサイクルについては,big-ban (waterfall) や cyclic という言葉で語られることが多いが,本書ではアーキテクチャを中心に考えた "Evolutionary Delivery Life Cycle" というモデルを定義している.
http://users.atw.hu/softarchpract/ch07lev1sec1.html

このライフサイクルモデルでは,設計は "Preliminary Requirements Analysis" (要求の予備分析) を伴う反復的なものだとしている.なにかしらのシステム要求が存在しない限り設計は始められないが,設計を始めるにあたって全ての要求が明確になっている必要はない.

まず最も重要なビジネスゴールを特定し,それらを品質特性シナリオ,もしくはユースケースに変換する.さらにこのリストからアーキテクチャに大きな影響を持つものを抽出する.

この抽出されたものが Architectural Drivers (アーキテクチャ決定要因) となる.そしてその数は10個未満にするべきだと述べられている.個人的にはシステム規模に関わらず「10個未満」と数を限定することに賛同はしかねるが,いずれにしても設計の初期段階でアーキテクチャ的に重要な要件を抽出することは必要だろう.

ちなみに本書の第11章では,"utility tree" というものを使って,ビジネス目標を品質特性シナリオに変換しているので,参考にしてもよいかもしれない.

Architectural Drivers が判明した時点で,設計は開始できる.もちろん設計の過程で生じた懸念事項が,要求分析に影響を及ぼすことはあり,それがこのモデルの反対向きの矢印が示すところだ.


では実際の設計を見てみよう.

本書第7章の大半は,今回のメインテーマである「アーキテクチャ設計」について,「品質特性駆動型設計」(ADD: Attribute Driven Design) という設計手法の解説に費やされている.

ADD は,RUP (Rational Unified Process) に代表されるその他の設計手法の拡張と位置付けられ,品質特性と機能要件の両者を満たす手法として知られている.

ADD は,Architectural Drivers をインプットとして扱い (特に品質特性は,システムに特化したシナリオとして書かれている必要がある),品質特性を基にモジュール分割を再帰的に行う.各段階で,一連の品質シナリオを満足する tactics と pattern を選択し,次に pattern によって提供されるモジュールタイプに機能責務を割り当ててインスタンス化する.

ADD のアウトプットは,モジュール分割 view の初期段階のレベル,そしてそれに対応したその他の view である.全ての詳細が ADD によってもたらされる訳ではなく,必然的に粒度も粗くなるが,これは設計プロセスにおける最初の明確なアーキテクチャの表現であり,機能要件を実現する為のフレームワークを提供する.

以下に ADD の各ステップを示す.

1. 分割するモジュールの選定
全てのモジュールは,「システム」「サブシステム」「サブモジュール」であると言える.モジュール分割は全体システムから始められ,そこからサブシステム,サブモジュールへと,細かい要素に分割されていく.

2. 選定されたモジュールの詳細化
a) Architectural Drivers の選択
システムに特化した品質特性シナリオと機能要件から,アーキテクチャの方針を決定する Architectural Drivers を選択する.つまりこの分割における重要事項の特定を行うことになる.これらは要件の優先順位の高いものから見つけることができる.トップダウンのアプローチだけではなく,例えばプロトタイプを構築し,その検証の過程で見つけることもあるだろう (特に performance など).

b) Architectural pattern の選択
Architectural Drivers を満たす pattern を選択する.この選択は,要求を満たすのに利用可能な tactics が基となる.本シリーズ「その5」で述べたように,tactics は特定の品質特性を促進するが,pattern に tactics が実装されると他の品質特性に対する影響 (多くの場合はトレードオフ) も発生する為,この点も考慮する必要がある.この時に,tactics を実装するサブモジュールも特定しておく.

c) モジュールのインスタンス化と責務割り当て
選択された pattern から,システムに特化する形でモジュールをインスタンス化する.さらに,そこにユースケースから機能要件を割りあてる.この過程で,サブモジュールを追加したり削除したりすることもあるだろう.この作業の結果,必然的に「情報交換の必要性」が明確になってくる為,次のステップではインターフェースの定義をすることになるが,その前にここでのアウトプットは,複数の view を使って表現しておくことが重要だ.

d) サブモジュールのインターフェース定義
モジュール分割は,モジュール,及びモジュールの相互作用関係に制約をもたらす.少なくとも設計の初期段階においては,「どんなサービスや知識を必要としているか,与えるか」を認識する.各モジュールごとに,この情報をインターフェース仕様書に記述する.ステップ c) で複数の view を記述したが,例えば module viewtype では producers-consumers の情報やモジュールが提供する必要があるインタラクションの種類を,concurrency view ではモジュール間のスレッドの相互作用やコンポーネントが active component (自分でスレッドを持つコンポーネント) かどうか,同期型か,シーケンスを持つのかブロックコールを使うのかといった情報を,deployment view ではハードウェアの要求やタイミング要求,通信要求などを記述することになる.

e) ユースケースと品質特性シナリオの検証,詳細化
ここまでのステップを通して,対象としていた機能要件と品質特性シナリオが満たされているかの検証を行い,必要に応じて要件の詳細化を行い,そしてそれらをサブモジュールの制約条件とする.このステップは,重要案件が抜けていないかを確認するだけではなく,サブモジュールを更なる詳細化に落とし込む,あるいは実装する為の準備段階となる.

3. 上記ステップを,分割が必要な全てのモジュールに対して繰り返す

これだけではピンとこないかもしれないが,今回は ADD の雰囲気だけでも伝わればと思い,各ステップの紹介に留めるが,本書では各ステップについて詳細な解説がされているばかりか,「ガレージ扉開閉機の設計」という例題を使って実際に ADD を実施している.

さらにこの章の後半では,この次の段階としてのチームビルディングや,設計を反映したチーム構成の重要性,組織がアーキテクチャに与える影響,またさらに次のステップとしてのスケルタルシステムの構築についてが語られているので,興味のある方は,ぜひ本書を手にとって頂きたい.


もちろんこれが設計の "how-to" になる訳ではないが,冒頭で述べたように「ガイダンス」として,なにかしらのヒントになるのではないかと思う.


ソフトウェア業界に必要な3つのこと - Edward Yourdon [software]

「デスマーチ」を提唱した Edward Yourdon が,自身の Blog で日本のエンジニアに対する印象を語っていることを 先日紹介した が,彼はその後も日本の滞在期間中に「日本について」の記事をいくつか書いていたようだ.

The Yourdon Report: Blogging Japan, part 2: three things for taming the quality monster
The Yourdon Report: Blogging Japan, part 3: Even the Japanese make mistakes…
The Yourdon Report: Blogging Japan, part 4: Tokyo Admiral's Club
The Yourdon Report: Blogging Japan: final impressions

興味深いのは,"part 2" (上記リンクの一番上) で書かれている,来日中のパネルディスカッションで彼が受けた「ソフトウェア業界が,抜本的な品質向上の為に行う必要がある,3つの最も重要な改善点は?」という質問について.

彼の回答は,

My three proposals for improving the overall state of software quality focused on these areas: politics, collaboration, and negotiating tradeoffs.

つまり,「政治」「協調」「交渉トレードオフ」だというのだ.

まーったくソフトウェア工学っぽくないところが,さすが (?) 「デスマーチ」の提唱者といったところだろうか.


ところがこれらの言葉が与える印象と,実際の内容は若干ニュアンスが違うようだ.

詳細については元記事を読んで頂くとして,各々についての彼の主張を要約すると,

(政治)
どの分野においてもソフトウェアの位置付けが重要になってきているのに,企業のトップは財務やマーケティングなど,ソフトウェア以外の出身であることが多い.我々はもっとソフトのことが分かっているマネージメントを持つべきだ.

(協調)
「協調」という話は,Web 2.0の世界では良く聞くが,昔ながらの企業ではそれほど浸透しておらず,少なくとも品質と一緒に語られることは無い.これまでの組織論は通用しなくなってきている.もっとオープンにするべきだ.

(交渉トレードオフ)
機能,時間,工数,コスト,品質のトレードオフは非線型である.マネージャーや顧客はこの現実を理解していないどころか,そもそもトレードオフがあることすら認めようとしない.建設的なトレードオフの議論をするには,モデルやツールを使って,論理的に分析するべきである.

ということだ.

つまり,そのまま「政治・協調・トレードオフ」と直訳してしまうと,「社内政治・チームワーク・妥協」のように聞こえてしまうが,中身をよく読んでみると,それぞれ「ソフトのことを分かっている人が企業の舵取りをするべき」「Linux や Wikipedia のように,群集の叡智を開発に持ち込むべき」「モデルやツールを積極的に利用し,それによる論理的な分析を行うべき」というのが言いたかったことのようだ.


Friday, February 9, 2007

嘘のようなほんとのトリビア [memo]

既に300近いはてブがついているので見た方も多いとは思うが,個人的に非常におもしろかったので紹介してみる.

嘘のようなほんとの話(またしてもトリビア) - P O P * P O P

右利きの人は左利きの人より平均して9年長く生きる。

へぇー

電話を発明したベルさんは生涯、彼の奥さんと母親に電話をかけることはなかった。なぜなら2人とも耳が聞こえなかったから。

へぇー へぇー

女性は男性の二倍、まばたきをする回数が多い。

へぇー へぇー へぇー


元ネタはこちら.
Strange but Real

元ネタには108のトリビアが紹介されているが,P O P * P O P さんが紹介しなかったものとして,81番目に,

It is impossible to lick your elbow.

(自分の肘を舐めることはできない)

というのがある.

それで最後の108番目は,

And finally 99% of people who read this will try to lick their elbow.

(そして最後に,これを読んだ99%の人は自分の肘を舐めてみようとする)

と締めくくられているのが粋なところだ.


え? 私?
もちろん試しましたとも.


Thursday, February 8, 2007

mixi の日記に新 Blogger を設定 [blogger]

私は mixi の日記に外部 Blog (この Blog) を設定しているのだが,ここ最近それが反映されていないことに気付いた.

先日,Blogger を新 Blogger にバージョンアップしたことにより,サイトのフィードが Atom0.3 から1.0になったが,これに mixi が対応していなかったことが原因のようだ.

Blogger は Atom1.0 の他に RSS2.0 も配信している (フィード URL の末尾に "?alt=rss" をつける) が,これを mixi に設定しても更新されなかった為,mixi は現時点で少なくとも Atom1.0/RSS2.0 には対応していないと思われる.
⇒ 以下,最後の「追記」部分を参照して下さい (2007/03/07)


そこでフィード中継サービス,FeedBurner を使って,Blogger が配信する Atom1.0 を RSS1.0 に変換した.やり方は,
1. FeedBurner に加入し,Blogger のフィードを登録する
2. 「スマート・フィード」を無効にする
3. 「フィード形式変換」で "RSS1.0" を選択する
4. 「コンテンツ形式変換」で "application/rdf+xml" を選択する
(2 - 4 はいずれも FeedBurner の設定,「最適化」メニューより)
5. mixi の「RSS の URL」に,FeedBurner のリンクを登録する
というだけ.

これでめでたく mixi への反映が再開された.

FeedBurner には,「共有ブックマーク」や「共有フォトサービス」など,追加情報を一緒に配信できる便利な機能があるが,今回は mixi への反映だけを目的としている為これらは使用しておらず,FeedBurner のフィードはこの Blog の link 要素に追加すらしていない.


Blogger が配信するフィードに関しては,
clmemo@aka: Blogger Beta の各種フィードのまとめ
PurpleMoggy's Blog: Blogger Beta Feeds
あたりを参考に.
PurpleMoggy's Blog を見ると,新 Blogger にはラベルごとのフィードもあるようなので,日記エントリーのみ mixi に反映するなんてこともできそうだ (そもそもまだラベルつけてないけど…).

FeedBurner のフィードが自動検出されるように Blog の link 要素に追加したい場合は,
clmemo@aka: FeedBurner 用 link 要素を追加
を参考に.

clmemo@aka さんの tips には,いつも助けられてます.


【2007/03/07 追記】
結論から言うと,mixi は RSS2.0 に対応しており,mixi の日記に新 Blogger を反映させるには,
http://XXX.blogspot.com/feeds/posts/default?alt=rss
を設定すれば OK のようです.

本エントリーを投稿した時,...?alt=rss の RSS フィードを mixi で試して,一晩以上 mixi に反映されなかった為 (mixi の仕様では最大4時間),「mixi は RSS2.0 に対応していない」と勘違いしてしまいました (mixi が Atom1.0 に対応していないことは mixi 事務局に確認済みです).

ちょうど同じようなことを書かれている方がいらっしゃいました.
blog.桜井@猫丸屋: 新Blogger(Blogger Beta)でRSSフィードを吐き出す方法
blog.桜井@猫丸屋: mixiに日記が反映されるようになった

本件,ご指摘下さったのは 鰯に言わして さんです.ありがとうございました.

また,何人かの Blogger ユーザーの方が,本エントリーを基に FeedBurner の設定をしたかと思います.どうもすみません.


Monday, February 5, 2007

リアル スネオ & ジャイアン [memo]

なんて心温まる画像なんだ…
pya! (リアル)スネ夫&ジャイアン


Saturday, February 3, 2007

Google 技術講演会 [seminar]

DSC01137.JPG

Google の技術講演会・懇親会に呼んでもらったので,行ってきました.
Google がリクルーティングを兼ねて様々な講演会を開催しているとは聞いていたけど,帰りに頂いたお土産の中にも Google Japan の job openings の案内が入っていたことから,少なからずその要素もあったのかもしれない.

エンジニアリングディレクターのマグラス みづ紀氏や Debian Developer の鵜飼 文敏氏を始め,Google のエンジニアも多数顔を見せていた.

内容については,Blog で公開しても良いとのことなので,簡単にサマリーをレポートします.


Google の職場環境について
1人目のプレゼンターは南野 朋之氏.東工大出身の工学博士で,"blogWatcher" や "なんでもRSS!" などの開発者としても有名.

20%ルールなどから生まれたアイデア・実験から,デモを通して社員の声を集め,チームを増員して Beta 公開し,さらにユーザーの声を集める…といった,プロジェクトが生まれてからローンチされるまでの過程を説明.

- 1つのプロジェクトにエンジニアは 4 - 5名程度
- 四半期ごとに目標 (短期・長期) を立て,成果を評価
- エンジニアリングチームは世界で1つ
- 世界中の Google 社員の週報が読める
 (同じ興味を持つエンジアや開発グループを見つけることができる)
- 全ての Google のソースコードにアクセス可能
- 数千台のクラスタや Peta-bytes 級のストレージといった Google のインフラにアクセス可能で,やりたいことが簡単に試せる環境

など,既に聞いたことのある話も多かったが,印象的だったのは,しっかりドキュメントを残す文化があるということ.

Google には「百聞は "デモ" にしかず」という言葉がある通り,とにかく動くモノをまず見せることが要求されるそうだが,「デモを見せろ」という言葉と同じぐらいよく言われるのが「ドキュメントを見せろ」という言葉だそうで,ソースコードを書く前にまずドキュメントを書かなければいけないらしい.

懇親会で南野氏と少しお話して,「Mountain View の本社と東京オフィスで環境は違いますか?」と聞いたところ,「もちろん (本社で有名な) シェフの料理とかは東京にはないけど,基本的に職場の雰囲気は変わらない」と言っていた.


Gmail の開発について
2人目のプレゼンターは Gmail の初期開発メンバーで,Google のシニアエンジニアの Darick Tong 氏.

「人々のメールの使い方を再定義したかった」
- Google のサーチテクノロジーの応用
- メールのマイクロマネージメントの終焉
 (フォルダではなくラベルへ)
- かしこいスパムフィルター
- カンバセーションモデル
- チャットとの融合

などという動機から始めたプロジェクトにおいて,ストレージ,サーチ,スパム,UI といった側面から,様々な技術課題とその解決方法,さらに今後の展望を説明.

特にサーチの部分で,"Everything is a search" と話していたが,例えば Inbox や Sent Mail などを表示する時も,内部的にはメールを検索しているだけらしい.

私も Gmail を利用しており,そのシステムが availability と performance の両立という難しい課題を見事に表現しているだけでなく,例えば返信メールの引用部分を隠すといった細かい部分の usability まで行き届いていることに非常に感心していたが,彼の話を聞いて改めて 「デスクトップアプリケーションライクな "better webmail"」を作るという理念とその細かい配慮を感じた.


Bigtable について
3人目のプレゼンターは,ITPro で連載していた 作って理解する Ajax@IT のインタビュー なでもお馴染の工藤 拓氏.

内容は Google のデータベース,"Bigtable" について.
コストやスケーラビリティの問題だけでなく,「必要なものは自分達で作る」という Google の方針に則り,データベースも MySQL やオラクルなどを使うのではなく自前で作っているのだとか.

現在では,MapReduce, Google Reader, Google Maps, Google Book Search, My Search History, Google Earth, Blogger など,様々な Google のアプリケーションで利用されている.

構造は基本的にシンプルで,言わば大きなスプレッドシートのようなものだが,縦軸・横軸だけではなく,「時間」という軸があり,さらに横軸は辞書順にソートされている,"multi-dimensional sparse sorted map" であるとのこと.

BigTable の詳細については,Google から 正式論文 が出ているので,興味のある方はそちらを参照すると良いだろう.