満足せる豚。眠たげなポチ。

今月二度目のliquidroom ebisu。そして、今月二度目のZEPPET STORE。

最後から二番目のZEPPET STORE。

だんだんと最後になる実感湧いてきたよ。

こんなの実感してもちっとも喜べないのだけど。

せめて悔いの残らないライブを。。

先日、Duck Typing というエントリで紹介したDuck Typingについてさらに有力な情報が日経Linuxの2005/08号に載っていた。

「まつもと直伝　プログラミングのオキテ」のテーマがまさに「Duck Typingが生まれるまで」。

ということで、日経BPの記事検索サービスでPDFを購入してみた。（いつも思うが、もう少し安くならないものなのか・・・）

記事によると、Duck Typingとは、

If it walks like a duck and quacks like a duck, it must be a duck.
（アヒルのように歩き、アヒルのように鳴くものはアヒルに違いない）

が元であり、"達人プログラマー"の著者・Dave Thomasが言い出したらしい。

Duck Typingに関するポイントになりそうなのはこの辺りだろうか。

　静的型は、プログラム開発者が型宣言としてたくさんの情報を提供するために、エラーの検出が早く、確実に実行できます。そのかわり、型を設計した時点の前提が変化すると、指定したたくさんの情報（型）を一貫性を保ちながらすべて更新しなければなりません。動的型は、最初からそのような指定を行っていませんから、変化に強い傾向があります。
　 では、動的型の言語でＤｕｃｋ　Ｔｙｐｉｎｇを実践するにはどのような指針に従えばよいのでしょうか。基本的な原則はたった一つ、最低限これだけを覚えておけば大丈夫です。

• 明示的な型チェックを避ける

たしかに、Duck Typingの特長を考えると型チェックはしてはいけないのは自明だ。Rubyを使っていると、自然とDuck Typing的な書き方になっているようにも思う。

※　あ、そうそう元記事の中には誤植(？)が一つ。図8のメソッドによる型チェックの例は、obj.kind_of?("to_str") でなくて、obj.respond_to?("to_str") ですね。

リファラから。

これはなんだろう？RubyOnRailsアンテナ？

http://a.hatena.ne.jp/RubyOnRails/

でも、どうも今のところ登録はうちだけらしい。

あー、あれか！Ruby on Railsの翻訳があまりにとろとろしているんで、アンテナ立ててウォッチせざるを得なくなったっていうどなたかの・・・

ごめんなさい。駄記事書く前に最後のpage5の訳がんばります。

なんとも手抜きなもので申し訳ないのですが、自分用に作ったので一応公開しておきます。

個別のエントリについて、はてなブックマークのブックマーク状況を見るブックマークレットです。

上記のJavascriptをブラウザのブックマークへURLとして登録するか、このリンクをブラウザのブックマークに登録してください。（Firefoxユーザーは個人用ツールバーへ登録してももちろんOKです。）

使い方は、はてなブックマークの様子を知りたいエントリを個別のリンク（permalink）で開いて、上記のブックマークレットを起動するだけです。

中身はわざわざサーバーサイドに持たせる必要があったのか疑問なほど簡単です。ただ、” bookmarkletの文字数制限を無くす”がやってみたかっただけなんです。すいません。

あと、テストしている過程で見つけたんですが、はてなブクマの隙間がこんなことになってました。この方たちは何があったんでしょうか？

これは世に出ている資料が偏っているせいだと思うけど、近藤さんのポーズは腕を

/_

こうして考えたポーズをしているか、

＝

こうして腕組をしているポーズが多い気がする。

いや、それで？と言われてもそれだけなんだが。

『ブログ資本主義』−えらく扇情的な表紙の言葉とはてなの近藤さんの写真に惹かれて週刊東洋経済を購入。（中の写真ではダースベーダーが一人眼をひく素敵仕様）

• 楽天はブログサービスを持っていたのか。知らんかった
• どうも一番言いたかったことはロングテールに言われるような埋もれていた個人のニーズにリーチできる時代が来るという話らしい
• 次に来るのはWikiだそうな

情報量は多いのでそれなりに楽しめるが、なんとも言えず内容的にはあれなでき。

Wikiについては、、、まぁ、いいや。

今週、三本目のライブ。

ZAZEN BOYS, くるりと続いて今日はZEPPET STORE。

横須賀のhide MUSEUMに隣接するCafe Le PSYENCEで開始待ち中。

解散話がまだリアルに感じられなくていつもどおりにライブが楽しみなだけなんだけど、帰りも同じ気分でいられるかな？

来週にはビジネスブログに戻るので、今週はご勘弁を。

先日紹介したばかりのまつもとさんの筑波大講義資料から、今日はオープンソースの話。

http://www.rubyist.net/%7Ematz/slides/tsukuba-seminar1/

Page 12からPage 16までオープンソースとフリーソフトウェアの比較として書かれている。とても興味深い内容だ。

特にオープンソースの安心感というPage 14は面白い。

http://www.rubyist.net/%7Ematz/slides/tsukuba-seminar1/mgp00014.html

オープンソースの安心感

• 利用の範囲と限界が明確
• 開発者に問い合わせる必要がない
• 協力体制を維持しやすい

「利用の範囲と限界が明確」の部分ていうのは意外とポイントかなーなどと感じた。

そして、それに対するフリーソフトウェアは「自由獲得の武器」であり、「フリーダム」のフリーソフトウェアだという話があるPage 15。

http://www.rubyist.net/%7Ematz/slides/tsukuba-seminar1/mgp00015.html

この話を受けて、うだうだと考えていたのだけどあまりまとまっていないので今回はパス。メモするだけに留めておく。

salesforce.comのフォーラム・Summer '05が公開されていた。

Marc Benioffの音声データやプレゼン資料なども気前よく公開されているので興味のある方はご覧ください。

当日の各講演の内容を音声付きスライドでご覧いただけます。
大変ご参考にしていただける内容になっておりますので是非ともご覧ください。

◇イベントおよび講演のご視聴はこちら
http://www.salesforce.com/jp/summer05/summer05-session.jsp

ちゃんと確認はしていないのだけど、どうも熱弁を振るったデモンストレーションの方は内容に含まれていないような・・・

ウェブサービス＋multiforceというアプリケーションプラットフォームがもたらす新世代ＩＴというマーク・ベニオフの思いは、デモの方で強く現れていたように感じたので、もし本当に含まれていないようならちょっと残念。

よく意味のわかっていなかったDuck Typingのことが理解でき、非常にすっきり。

Duck Typing

アヒルのように歩き、アヒルのようになくものはアヒルだ

• 型でなくメソッドによる整合性
• ポリモーフィズムの可能性の追求
• 将来の変更に強い

元は、まつもとさんの筑波大での講義から。資料の公開に感謝。

http://www.rubyist.net/~matz/slides/tsukuba-seminar2/mgp00038.html

一日目の資料トップ　http://www.rubyist.net/~matz/slides/tsukuba-seminar1/

二日目の資料トップ　http://www.rubyist.net/~matz/slides/tsukuba-seminar2/

　毎日、酒をのむ。そして夕暮になると酒をのみながら、人生は面白くないと一人で仏頂面をしている。酒をのみ終ってから一人で食事をする。食事をしてから一人で自分の部屋に戻り、何もかも面白くないと仏頂面をする。

『海と毒薬』、『沈黙』といった名作を著した遠藤周作の文である。

インターネット時代のスピード感に乗せられるままに走っていると、ふとよくわからないイライラ感というか、ままならない感を感じることがあるが、そんなときにこういう文に出会うとほっとする。

あれだけ重苦しい文章を書いて人生を考え続けていたような遠藤周作もこうしてみると、けっこうつまらない、そして魅力的な一人の人間だなぁと思う。

（「ぐうたら人間学　狐狸庵閑話」の「酒のさかな」からの引用。）

そうかと思えば、一転、シロウトブログ書きとは一線を画す凄みを感じるような一編もある。

同じ「ぐうたら人間学　狐狸庵閑話」の「雪の夜、書斎に“無言の友”」は知人がちょっと変わった鳥を自分にくれに来たというだけのエピソードで、昨今の日記ブログと大差ないネタである。それが、文章を書ける人間が書くとこう書くのかと感心する。

本当にたいしたことないエピソードがそれなりにきちんと文章になっているのである。これがお金をとって人様に読ませる文章というものなのだなぁと感じ入る。隆慶一郎の「時代小説の愉しみ」という本のエッセイを読んだときにも感じたことだが、文章力というのはおそろしい。ほんの数行の中に違いが明白に現われる。

プレジデントの新刊書評をチェック。今号は梅田さんではないようだ。

と、普段ならさらりと読んで終わるところが、驚きのあまりこんなところに書いてしまう。

　で、ですね、この二作に共通する特徴が、本田透『電波男』（三才ブックス）の啓蒙によって徐々に人権を獲得しつつあるキモメンを扱っ てることなんですの。プレジデントな皆さまにおかれましては、今時代の風がイケメンではなくキモメンに吹いていることをご存知でございましょうか。

もうツッコミどころが多すぎるんだが。

古くは大前研一氏の「企業参謀」を見出したプレジデントですよ。先取りしすぎ。しかもかなり事実誤認があるから。（それともなんか意図的に吹き込んでるのか？）

まぁ、とにかくビックリしましたよって話でした。

『マーク・ベニオフとsalesforce.comの示す業務システムの未来（１）』の続き。今回のテーマは、「マーク・ベニオフには何が視えているのか？」だ。

マーク・ベニオフはこの日本でのフォーラムによほど気合が入っていたのだと思う。スピーチも熱の入ったものだったし、デモンストレーションも担当の方のデモが終わった後に、わざわざ自ら再度ポイントを強調しながらデモを行っていた。たしかにマーク・ベニオフによるデモの方が、このsalesforce.comの魅力の核心を突いたものだったと思う。

さて、マーク・ベニオフの考えていることを反映させた上で、このsalesforce.comがユーザー企業へもたらすベネフィットを説明しておこう。

salesforce.comが実現するのは従来では考えられなかった圧倒的なスケーラビリティとスピードだ。

salesforce.comの実現するスケーラビリティ、それはERPシステムで地道に行ってきたデータの統合などで得られるそれを凌駕するものだ。

sforceとmultiforceにより、自社の他のシステムはもちろん、取引先や子会社のようなあらゆる企業とのデータ連携が可能になる。しかもこれは柔軟なデータ連携であり、既存の資源を最大限に生かした形での連携を可能とする。

ERPシステムはデータのスケーラビリティを提供し、グローバリゼーションの流れの中でその促進に大いに貢献してきた。だが、このsalesforce.comの考え方では従来型のERPシステムは不要になる。

データはそれぞれが持ちながら、なお柔軟に連携し活かすことが可能になる。

そして、salesforce.comの実現するスピード。これはこれからの業務システムでは顕著にビジネスのスピードへ影響し、数年後にはsalesforce.com型のシステムが当然となるところまで淘汰が進むのではないかと思う。

先ほどはてなフレームワークやRuby on Railsを引き合いに出したように、実はsalesforce.comは現在最高クラスの業務システム構築システムである。RADツールなのである。

今でもウィザードによるカスタマイズをベースにはしているものの、multiforceとsforce、customforceの提供が示すものは明らかだ。salesforce.comはWebアプリケーション構築フレームワークなのだ。しかも、フレームワーク上でアプリケーションを構築する細かなツールもそろっている。それがcustomforceであり、管理者用のウィザードである。

このフレームワークを利用して業務システムを開発し、既存のデータはすべてウェブサービス経由で再利用する企業と、従来型のスクラッチ開発を行う企業がどれだけビジネスのスピードにおいて差が出てくるかについては説明の必要はないだろう。

IT Doesn't Matterという話もあるが、これでまた一つ最低限装備しないといけないITのレベルは上がるだろう。

そして、これらを通じてマーク・ベニオフが描くsalesforce.comの未来の姿は、Googleがパーソナルユースを対象にやろうとしていることと同じだ。ビジネスアプリケーションのOSである。multiforceでそのものOSという表現まで出てきている。

全ての情報はsalesforce.comを通じてリーチできるようになる。必要なアプリケーションはsalesforce.com上で動作する。これがマーク・ベニオフがこのsalesforce.comという野心的な製品で視ている未来なのだと思う。

一つ一つのパーツは目新しいものではない。むしろ新しいもの好きで追いかけている人にとっては、今さらという概念ばかりだろう。だが、そのパーツの選び方、そして組み合わせ方、実現するベネフィットの方向性、それらがそれぞれ絶妙に正しい方向を向いていると感じる。

ところで、スピーチの中でマーク・ベニオフが使っていた単語で特に印象的だったものが二つある。

それは、POWERとTRANSPARENCYだ。どちらもsalesforce.comやそれが体現する新しいITを表現した言葉だ。なるほど、納得。

7/7にsalesforce.comのフォーラムへ行ってきた。
このフォーラムで行われたマーク・ベニオフの基調講演と、その後行われたsalesforce.com summer '05のデモンストレーションは未来の業務システムへの示唆溢れる内容だった。セミナーでSOAの抽象論を何度も聞くよりもこのsalesforce.comを理解することに努める方がSOAの理解はよっぽど早いに違いない。

まず、salesforce.comの新バージョンSummer '05の概要を説明し、それからこのシステムから読み取れるsalesforce.com、そしてマーク・ベニオフが視ている業務システムの未来を解説することにしよう。

salesforce.comはアプリケーションホスティング型のCRMだ。salesforce.comのサーバー上でアプリケーションが動作しており、ユーザーはWebブラウザなどからsalesforce.comへアクセスし、認証を受けることで同社の提供するサービスを受けることができる。アプリケーションホスティングスタイルの特徴を生かし、オンデマンドサービス（使った分だけ料金を支払う）であることを謳い文句にしている。

salesforce.comの新バージョンの大きな特徴は、次の３つだろう。

• multiforceによるアプリケーションプラットフォームの提供
• sforceによるウェブサービスを利用したやわらかいデータ連携
• customforceによる強力なカスタマイズ性能

salesforce.comは、summer '05からサービスを各レイヤーにおいて提供するようになった。

salesforce.com オンデマンド・アーキテクチャ（SODA）
http://www.salesforce.com/jp/products/ondemand-architecture.jsp

§what's multiforce?

わかりにくいが、資料の文句をそのまま引用しておこう。

すべてのアプリケーションをたった一つのオンデマンド環境で

Multiforceはsalesforce.comのオンラインモデルを次の段階へと進化させるものです。新しいMultiforceオンデマンドオペレーティングシステムを使えば、全く新しいアプリケーションを作り出すことができます。CRMに限らず新しいビジネス分野や組織でもオンデマンドのメリットを享受することができるようになります。新しいMultiforceのメニューを使えば、Salesforce、Supportforceと同じデータ、セキュリティ、インターフェースを使いながら複数のアプリケーションに１クリックでアクセスすることができるのです。

つまり、Multiforceはsalesforce.comのオペレーティングシステムとの呼び方のとおり、異なる複数システムの共通のプラットフォームとして動作する。セキュリティや共有データの制御、複数アプリケーション間の遷移の制御といったWebアプリケーションの制御として不可欠なものについて共通して利用できるサービスを提供する。これにより、multiforceに則ったカスタムアプリケーションを作成しさえすれば、salesforce.comはCRMの枠を越えてあらゆる業務システムの共通プラットフォームとして動作することが可能になる。そして、これらのアプリケーションはすべてsalesforce.comの一部機能かのように呼び出すことが可能だ。

§what's sforce?

これもまずは資料の文章を引用する。

Sforceを使えば、Webサービスが現実のものとなることをお約束します。企業は従来のクライアントサーバー型のシステムの数分の一のコストと労力で、オープンで標準に準拠したアプリケーションの統合ができるようになるのです。Sforce6.0は更に強力なインテグレーション能力と新しいSforce6.0のWebサービスAPIを提供しています。

これは文章のままで理解可能だと思う。salesforce.comのための各種APIを提供するのがsforceだ。

§what's customforce?

salesforce.comの革新的なカスタマイズツール、CustomforceならどなたでもCRMを完全にお客様のビジネスプロセスにあわせてカスタマイズできます。いまやProfessionalEditionでも利用可能なCustomforce2.0の新しい機能を使えば、以前よりずっと間単にずっと強力に、全く新しいオンデマンドアプリケーションを瞬時に作り出すことができるのです。

そして、customforceは計算式やタブ、リストなどのカスタマイズを提供する。

デモの中ではGoogle Mapsをmultiforceで制御されたアプリケーションとしてsalesforce.comの中の機能として呼び出していた。これははてなマップやmap.rails2u.comの地図などがあるのでイメージしやすいと思う。はてなやmap.rails2u.comで、はてなフレームワークやRuby on Railsというプラットフォームの上でGoogle MapsをAPIから呼び出して実現しているのと同様に、salesforce.comはmultiforceをプラットフォームとしてGoogle Mapsを利用しているのだろう。

次回は『マーク・ベニオフとsalesforce.comの示す業務システムの未来（２）』として、マーク・ベニオフが視ている（であろう）業務システムの未来を解説する。

そうそう、salesforce.comのフォーラムは、なかなか刺激を受ける内容だったので、きちっとエントリ起こす予定です。

ウソみたいなんですが、「すごい会議」の大橋禅太郎さんからコメントを頂いてしまいました。

「すごい会議」の本質を読み解く。
http://blog.livedoor.jp/zep716/archives/26180505.html

なんかカワイゲのないコメントを返してしまってますが、裏ではうれしくて何度もコメントを読み返してしまいました。

うちの場合、気合を入れて書いたエントリほどスルーされ、割とささっと書いたものが喜ばれたり、という傾向があるので、こういう形で思いを込めたエントリにリアクションがあるとうれしくなります。書いてよかったー。

※　ちなみに、比較的やる気とリアクションがリンクしたのがRolling with RoRの邦訳。ビックリするほど反比例して、どうしていいかわからなかったのが、アイデア出しの話。

梅田さんとある編集者さんという異業種のお二方が共に絶賛していたため、ずっと気になっていた一冊。一日でむさぼり読んでしまったので、感想など書いてみる。

近年の最高傑作。
その精緻な筆力にぐいぐいと惹き込まれた。

痛烈にスリリングでエキサイティング。
十二分にエンターテイメントとして成り立つ要素を備えながら、あくまで知的で重厚な内容。
それでいて絶妙に読みやすい文章のバランス。

最初から最後まですべての文章が構想されてから書かれたのではないかと思う（実際にそうかもしれない）圧倒的な統一感。

真実の是非はともかく、日本の外交にこういう思想を持った人物が居たということはぜひとも知っておくべきだと思う。

佐藤優氏の「国家の罠」は、他の本を中断してでも読むべき本だ。

鈴木宗男議員の逮捕に絡め、前後の対露外交、北方領土問題、そして外務省の外交スタンスなどを語る前半部、
そして、この本の醍醐味とも言える検察との詳細なやりとりの記録となる後半。
一貫して語られる佐藤の情報収集・分析者としての職業観。
そのすべてが鮮烈な印象を与える。

国家の罠 外務省のラスプーチンと呼ばれて

posted with amazlet at 05.07.07

佐藤 優
新潮社 (2005/03/26)
売り上げランキング: 184

amazlet.com で詳細を見る

以下、ネタバレ（と感じるかもしれないこと）を含みます。

ただ、気をつけなければいけないなと感じるのは、「国益に殉じた国士」という佐藤氏の印象はあくまで「国家の罠」というノンフィクション小説の主人公・”佐藤優”に対して抱いたものだという点だ。

この意味では、この本に書かれていることは真実だろうし、”佐藤優”は紛れもない愛国者なのだろう。

一方で、この本の著者である佐藤優氏については、この本の言い分をそのまま受け取ってしまうのは、情報屋である佐藤氏へ失礼とも思える。

実際、彼の現在の立場は控訴中というものだ。書中で佐藤氏自身が述べている「ヒュミントの原則」から言っても彼の言はそのまま信じるべきではない。

情報の世界で、ヒュミント（人間からとる情報）の原則は二つである。第一は、情報源がこちら側が関心をもつ情報を知ることができる立場にいるということだ。そして第二に、情報源が自分の得た情報を私に正確に教えてくれるということだ。（p19）

佐藤氏は情報を正確に教えることを読者に保証する立場にいない。

私には残念ながらこの書の内容を逐一裏付けをとれるようなパイプはないのだが、最低限論理的な思考により真実を求めるのは、最高に面白い小説を提供してくれた著者に対する礼儀のような気がしている。

いくつか読後に気にかかった点を。

佐藤氏が国益を最重要視したという印象は避けられないように書かれているのだが、その国益の基準となる思想についてはほとんど語られることがなかった。

たんに本の主旨から外れるということや、ページ数の制限という問題は明らかにあったと思う。それでもあまりにこの件に関する具体的言及は少ない。

意地悪い見方をすれば、国益へ殉じたという点を強調しておけば、とにかく日本のためにがんばった人。という印象だけを植え付けることができる。

本当に大切なのは、なにがどう国益となるのか？という佐藤氏（を含む当時の外務省）のヴィジョンであったと思う。これが本来、国益と呼ぶべきものでなければ、それはやはり”背任”だろう。（書中での背任とは意味が異なる。そして逮捕されるべきでもないだろう。）

どうも国益というきれいな響きを使って、うまいこと本全体を通しての正義をコントロールしているな、というのは正直な印象として受けた。

これが佐藤氏流のレトリックなのかもしれない。という疑念と言ってもいい。

レトリックに関する佐藤氏の説明を引用しておこう。

同じことでも言い方によって相手側の受け止めは大きく異なる。例えば、「お前、嘘つくなよ」と言えば誰もがカチンとくるが、「お互いに正直にやろう」と言えば、別に嫌な感じはしない。伝えたい内容は同じである。（p175）

そしてもう一つ、検察や公判の結果が世論に引っ張られる傾向があるという本書の指摘は興味深い。

国策捜査の適用基準のハードルが近年下がってきているという話に続いて、このように述べられていた。

「そうだろうか。あなたたち（検察）が恣意的に適用基準を下げて事件を作り出しているのではないだろうか」
「そうじゃない。実のところ、僕たちは適用基準を決められない。時々の一般国民の基準で適用基準は決めなくてはならない。僕たちは、法律専門家であっても、感覚は一般国民の正義と同じで、その基準で対処しなくてはならない。（後略）

この理屈に従えば、世論に佐藤はシロだという声が強くなれば、検察も司法も強いて佐藤氏を有罪にするべき理由がなくなってしまう。（少なくとも国策捜査としては。面子云々は残るだろうが、それは末節の論理だ。）

そして、この「国家の罠」を読むことによって醸成される気持ちは、まさに「佐藤はシロだ」なのである。

彼は国益のために奔走した愛国者であり、情報収集・分析のプロフェッショナルとしての職業倫理をもった男である。そんな彼が多少、イレギュラーな操作はあったかもしれない（なかったかもしれない）が、いずれにせよ私腹を肥やすための犯罪に手を染めるはずがない。

いったい誰が愛すべき”佐藤”を憎むことができるというのだろう？これが本書の読後に多くの読者が得られる偽らざる感想なのだ。

控訴中の佐藤氏にとってこの本は、公判へ向けての一つの有効な戦術であるというのは穿ちすぎた考えだろうか。

上記の二つの見方は単なる可能性であり、あえて意地悪に想定したものだ。別にこの見方が正しい！などと言い張るつもりはまったくない。

ただ、確実に言えるのはこの本の中の佐藤氏はきれいすぎるということだ。

たしかに、彼の思想としては書中の言の通りなのかもしれない。（これがすべて口からでまかせなら、むしろ歓迎すべき大作家だ。）

しかし、実際の彼の仕事はここまできれいに意思を統一してできたものだったのだろうか？
そうは思えない。それだけで通用するような世界に佐藤氏が生きていたのであれば、三井物産は正攻法のみで押してきただろう。

あまりにきれいで、しかも全体にそれが整いすぎている。情報の質として言えない話が多くあるというのはわかる。
ただ、それにしても佐藤氏自身に関する汚い話（やむをえないものも含め）があまりになさすぎる。

これは鵜呑みにはできないな、というのが心証なのである。

プロフェッショナルな職人は、自分の仕事については正直なものだ。悪いことも端的に伝える。少なくとも技術畑の職人はこれがモラルだ。

その意味で、この最高のエンターテイメントと魅力的な主人公・”佐藤優”と現実の世界に生きる生身の佐藤優氏を混同するのは、注意した方がいい。
（これは佐藤氏の語る外務省のロジックや検察のロジックについても言える。一つの見方を伝えてはいるだろう。ただ、すべてではないと思う。この辺り、今後詳しく知っていそうな知人に別の側面を聞いてみたい）

CNET NEWS.COMの"Microsoft previews next-generation CRM"を見ていて思い出した。

salesforce.comのマーク・ベニオフが来日して基調講演をするとのことなので、7/7のsummer '05 Customer Success Forumへ参加を決定。

https://www.salesforce.com/jp/summer05/register.jsp/

基調講演：
『最新の米国のITトレンドと新しいビジネスモデルについて』
米国セールスフォース・ドットコムCEO　マーク・ベニオフ

面白い話が聞けたら、ここでレポします。

Pages: 1, 2, 3, 4, 5

何が起こっていたのか？

一行のscaffold :recipeがすべてを実現した。その一行がぼくらのデータモデルを実際に動くようにした。ほとんどぼくらには何も作業をさせずに、この一行はlist, show, edit, そしてdeleteの機能を作成した。そして、それぞれの機能のデフォルトビューのテンプレートも作成した。

もちろん、その機能やビューはとても単純なものだ。あなたがユーザーに見てもらいたいようなたぐいのものじゃない（ユーザーが皆、ギークなんじゃないかぎり)。でも、嬉しいニュースがある。ぼくらは足場（scaffolding）を残したままで、時間をかけて一つ一つに独自のアクションとビューを提供することができる。あなたがアクションやビューを新しく作成するたびに、それらはscaffoldバージョンの定義をオーバーライドする。あなたがすべての作業を終えたら、単にあなたのコントローラークラスからscaffold 文を削除するだけでいい。

さてそれをする前に、あなたの新しいcookbookで使っているURLには気をとめただろうか？Railsでは、ユーザーに少しでも見やすいURLを見せるようにしている。RailsのURLはシンプルでわかりやすい。けして長く難解なものではない。

アクションとビューを定義する

すべてのレシピを一覧表示しているページは、かなり改良する必要がある。どうやればいいかというと、Scaffoldされているlistを上書きしてやればいい。

recipe_controller.rb を編集して、list メソッドをFigure 40のように追加してほしい。

Figure 40. 新しいlist メソッド

http://127.0.0.1:3000/recipe/listを見てみると、Figure 41のように見えると思う。

Figure 41. 新しいlist メソッドの表示結果

ぼくたちが独自のlist の動作を定義したので、Railsはもうscaffoldされたものを使わなくなった。Railsはぼくらのlistメソッドを呼び出し、レンダリングするためにビューのテンプレートを見つけ出そうとした。でも、ぼくらはテンプレートを作成していなかったので、この"テンプレートが見つかりません"（template missing） エラーを受け取ることになったのだ。

それじゃあ、list に独自のビューテンプレートを作成することにしよう。これは、レシピのタイトルと日付だけを表示するものにしよう。

ぼくらがレシピコントローラーを作成したとき、generate controller スクリプトは、レシピコントローラーが表示するHTMLテンプレートを入れておくためのviewディレクトリも作成していた。list.rhtml という名のテンプレートファイルをc:\rails\cookbook\app\views\recipe の中に作成しなければならない。あなたがJSPやASPのページを作ったことがあるようなら、これは同じように見えるだろう。このテンプレートファイルは、単純なHTMLファイルで、Rubyのコードが<% %> と<%= %> のタグで埋め込まれている。

c:\rails\cookbook\app\views\recipe の中に、次のような内容のlist.rhtml という名前でファイルを作成しよう。

<html>
<head>
<title>All Recipes</title>
</head>
<body>

<h1>Online Cookbook - All Recipes</h1>
<table border="1">
 <tr>
  <td width="80%"><p align="center"><i><b>Recipe</b></i></td>
  <td width="20%"><p align="center"><i><b>Date</b></i></td>
 </tr>

 <% @recipes.each do |recipe| %>
  <tr>
   <td><%= link_to recipe.title, :action => "show", :id => recipe.id %></td>
   <td><%= recipe.date %></td>
  </tr>
 <% end %>
</table>
<p><%= link_to "Create new recipe", :action => "new" %></p>

</body>
</html>

recipe_controller.rb を編集し、Figure 42のようなコードを一行list メソッドへ追加する。

Figure 42. 全てのレシピを表示する

ブラウザを更新すると、Figure 43のように見えるだろう。

Figure 43. ちょっとよくなったレシピリスト

これで、確実に見た目がよくなった。どうやって動いているんだろう？

def list
  @recipes = Recipe.find_all
end

ユーザーがブラウザでhttp://127.0.0.1:3000/recipe/listを見ると、Railsはぼくらが作ったばかりの新しいlist メソッドを呼び出す。メソッド内の一行のコードがRecipeクラスにデータベースからすべてのレシピのコレクションを返すように要求を出す。そしてその結果をインスタンス変数@recipesへ入れる。

次に、Railsがレンダリングするテンプレートを探し、それをブラウザへと返す。listの表示テンプレートの中身はほとんどが普通のHTMLだ。実際のアクションは、テンプレートのこの部分になる。

<% @recipes.each do |recipe| %>
  <tr>
   <td><%= link_to recipe.title, :action => "show", :id => recipe.id %></td>
   <td><%= recipe.date %></td>
  </tr>
 <% end %>

この埋め込みRubyコードがコントローラー内のレシピコレクションを繰り返し処理する。テーブルの行の始めのセルは、レシピ表示ページへのリンクを作成する。レシピオブジェクトに使われているアトリビュートに注意してほしい。（title, id, date）これらは、recipes テーブルの列名からそのまま名付けられている。

クックブックにカテゴリーを追加する

レシピには、カテゴリー（デザートのような）を指定できるようにしたい。そして、特定のカテゴリーに属するレシピだけを一覧できるようにしたい。これをできるようにするためには、データベースへのカテゴリーテーブルの追加と、所属するカテゴリーを示すフィールドのレシピテーブルへの追加が必要になる。

MySQL-Frontでcategories テーブルを作成しよう。自動的に生成されるId フィールドをidへと変更するのを忘れないように。そしてname フィールドをvarchar(50)で作成する。テーブルはFigure 44のようになるはずだ。

Figure 44. categories テーブル

さらに、カテゴリーコントローラーとカテゴリーモデルも必要だ。コマンドプロンプトをcookbookフォルダで開いて、コマンドを実行しよう。(Figure 45)

ruby script\generate controller Category
ruby script\generate model Category

Figure 45. カテゴリーモデルとコントローラーの作成

最後に、足場（scaffolding）をカテゴリーコントローラーへ追加しよう。c:\rails\cookbook\app\controllers\category_controller.rb を編集して、Figure 46のように足場（scaffolding）を追加する。

Figure 46. カテゴリー用のscaffold

ブラウザでhttp://127.0.0.1:3000/category/new を開いて、二つのカテゴリーSnacks とBeverages を作成しよう。それが終わったら、Figure 47のように見えると思う。

Figure 47. すべてのカテゴリーの一覧

Pages: 1, 2, 3, 4, 5

ビジネスをしていてベストのアイデアを出さなければいけない場面というのは、（幸か不幸か）意外と出くわしません。

天才的に良いアイデアが必要とされていることが少ない代わりによく出くわすのが、人よりもちょっと優れているアイデアを必要とする場面です。

そう、だいたいそんなもんなんだけど、なんかもう一押し足りないなぁというようなケースです。

これは、わりとよく出くわします。たぶん、明日出社したら一つや二つくらいはこのようなことがあるんじゃないでしょうか。

ということで、こんなときに使える、あと「もう少し」のためのアイデア術をご紹介。

1. 答えをとりあえず２０コ挙げてみる
2. さらに３０コ挙げてみる
3. 答えをカテゴリごとに分類し、足りないアイデアをさらに書き足す
4. 効果があがりそうなアイデアと一番やりたくないアイデアを一つずつ選んで、自分のアイデア候補にする

ステップ１、２をやるときに気をつけるのは、いいものも、悪いものも、人が考えそうなものも、とりあえず書き出してしまうこと。深く考えたり、かっこつけると、数が挙げられなくなります。とにかく手を動かしてみるといいようです。

ステップ３では、カテゴリは３つくらいに分けられるといいです。多くても５つくらいに抑える方がいいと思います。たいてい、１、２のステップをやっているうちにカテゴリが見えてきています。自分の中で考えが薄かったなーというカテゴリは、この時点でいくつか補強します。

ステップ４、いよいよ最後のチョイスです。いいアイデアを選ぶのは当然として、悪いアイデアも頭の中に残しておきます。悪いと考えるのは、何かしらの固定観念がジャマしている場合があるからです。（固定観念をひっくり返せるような場合は、その悪いアイデアがベストのアイデアへ化けるかもしれません。）

これ、特に元ネタはありません。これまでに学んだ色々な手法から少しずつエッセンスが混ざっているようです。

ただ、自分の中でそれなりのパフォーマンスのアイデアを出したいときには十分に役立ってます。３０分ほどで、けっこうなんとかなりそうなアイデアを出すことができます。漠然と「いいアイデアを出そう」とウンウン唸るよりは、手早く目の前を片付けられますよ。