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

こんにちは。能動的音楽好き・挫折カテ所属のタナベです。

梅田望夫さんのブログ経由で知った丸山茂雄氏のmF247について、現時点での感想を書いてみたいと思います。

いきなりですが、今mF247について感じているすべてをきれいに言い切ってくれている文章があるので引用します。

最初の疑問には暗黙の前提がある。「無料で配布されているソフトウェアからは収入を得ることができない」というものだ。過去においては確かにそうだった。しかし、現在ではこれはもうあてはまらない。

私はソフトウェアを開発している。私のソフトウェアには価値がある。それがたとえ無料で配布されていても。価値があるソフトウェアには、それからお金を生む方法がある。

私のソフトウェアに価値があり、それからお金を生む方法があるならば、無料で配布されているかどうかに関係なく、それから収入を得ることができる。なにもソフトウェアをシュリンクパッケージで販売しなくても、ソフトウェアビジネスはできるのだ。というか、もはやシュリンクパッケージビジネスができるのはマイクロソフトなど限られたビッグプレイヤーだけだろう。

ソフトウェアビジネスのほとんどのプレイヤーはソリューションを提供する。オープンソースソフトウェアはそのコンポーネントである。彼らにとって、そのコンポーネントが存在し続けることは価値があり、開発を支援することには意味がある。

これは音楽に関する言及ではありません。Rubyというプログラムの産みの親、まつもとゆきひろ氏がご自身のソフトウェアとオープンソースというものについて語った言葉です。

http://www.rubyist.net/~matz/20031006.html#p01

Rubyはオープンソースと呼ばれる形態で無料配布されているソフトウェアであり、まつもと氏はこのRubyを開発すること自体からは直接の利益を得ていません。（今は職務としてRubyの開発をされているかもしれません。ただ、少なくとも開発開始〜普及の当初はそういう状況ではなかったと思います。）

しかし、文中で言われているとおり、まつもと氏はオープンソース開発者として生活の糧を得ています。それが可能となる理由が「私のソフトウェアには価値がある。それがたとえ無料で配布されていても。」であり、生み出したソフトウェア自体が持つ価値が、お金を生み出す原動力になっています。

これが、私から見たmF247の基本コンセプトと同じ方向性を持っていると感じるのです。（mF247サイトイメージ参照）

まず価値のある音楽を生むこと。そして、その価値から湧き出るところで収益性を持たせてビジネスを成り立たせること。

その根底にあるのは、「もはやシュリンクパッケージビジネスができるのはマイクロソフトなど限られたビッグプレイヤーだけだろう。」の発想でしょう。シュリンクパッケージビジネス＝CDなどによる楽曲自体の販売というモデルが機能するのか？という疑問だと思います。

そして、その後に続く、

ソフトウェアビジネスのほとんどのプレイヤーはソリューションを提供する。オープンソースソフトウェアはそのコンポーネントである。彼らにとって、そのコンポーネントが存在し続けることは価値があり、開発を支援することには意味がある。

という文章は、オープンソースのプログラムよりの書き方ですが、その本質的な部分はやはりmF247にも共通する姿勢だと思います。つまり、ソフトウェアをエンジンとして、その周辺に生まれる無限の可能性をビジネスとして生かしていくことで、ソフトウェア自身が生き残る道を探るという姿勢です。

"プログラム"や"録音された楽曲"という、デジタル環境下では容易にコピーが可能となる二つのソフトウェアが、将来像として同じ方向性を見せているのはとても興味深く、また納得のいくものでした。

「コンテンツビジネスは月額固定のサブスクリプションモデルで決まり！」という声の根強い中、新しい収益モデルを試行錯誤であろうmF247の今後の動向は非常に楽しみです。（個人的にはmF247はスタートしてからどんどん新しいスタイルに脱皮していくだろうと思っています。）

以下は、能動的音楽好きのロングテールをごっそりとすくい上げるかもしれないmF247話のリンク。

すべて「丸山茂雄の音楽予報」から。

mF247の設立のまえがき
http://d.hatena.ne.jp/marusan55/20050803

ｍＦ２４７をなぜ作ろうと思ったのか？
http://d.hatena.ne.jp/marusan55/20050805

ネットの開放性は危険で悪なのか？
http://d.hatena.ne.jp/marusan55/20050813

一夜明けて
http://d.hatena.ne.jp/marusan55/20050819

ブログの反響
http://d.hatena.ne.jp/marusan55/20050821

更なる援軍が
http://d.hatena.ne.jp/marusan55/20050823

能動的音楽好きはたくさんいる筈だ！！
http://d.hatena.ne.jp/marusan55/20050825

余談　たぶん、路上ライブやライブハウスで知らなかったアーティストを見て起こる「うわ、これすごいよ。サイコー！誰かに聴かせてー！！」っていう無意味に熱い気持ちをインターネットで増幅して皆ハッピーになりましょうっていう話なんだろうなぁ。昔、元SMEのいしのだなつよ見てそんな気になりましたよ。今でも好きだけどね。

うれしすぎる！羽生章洋さんによるDB設計の乱取り稽古連載が開始。

ちょうど勉強しなおさにゃあってかんじで羽生さん太鼓判の佐藤正美氏本（廃刊のRADじゃないけど・・・）と羽生さん著のWEB+DB PRESS過去記事を読み漁りまくり中（もう何度目やら）だったところへ、このお知らせ。

[RDBMS][執筆]CodeZine：楽々ERDレッスン 第1回：「お持ち帰りご注文用紙」編
http://d.hatena.ne.jp/habuakihiro/20050829#1125289906

そして、そこからリンクされる本題記事はこちら。
http://codezine.jp/a/article.aspx?aid=154&res=2

Rails話。とりあえずメモメモ φ（．．） 。

僕は Rails のところで、Rails で作ったアプリケーションはどういう環境で動かすのが一般的なの? mod_ruby みたいなのを使うの? という質問をしました。前々からすごい気になってて、質問で積年の疑問が解消されてすっきりしました。答えとしては FastCGI、mod_ruby、lighttpd、みたいな感じ。

Lightweight Language Day
http://d.hatena.ne.jp/naoya/20050828/1125201739

それから 川o・-・）＜2nd lifeな方のエントリからも。

あとid:naoya:20050828:1125201739について補足。Railsではデフォルトで、dispatcherがdispatch.cgi, dispatch.fcgiと二種類作られて、開発する側はdispatch.cgiを使えばcgiとして、dispatch.fcgiを使えばFastCGIとしてまったく意図せず切り替えが可能。なのでそこらへんは全く頭悩ますことなくていいんだよね。mod_rubyで動かす場合、mod_ruby開発者の前田さんがrails-dispatcher.rb を作っているのでそれを利用すればOK。

LLDN
http://d.hatena.ne.jp/secondlife/20050828/1125208676

ひさしぶりの更新が手抜きですいません。。

THE WHOは好きですか？The Jamは好きですか？thee michelle gun elephantは好きですか？

つまりはそういうことです。THE BLUE VANを聴いてください。

ブリブリした骨太のグルーヴに乗るポップセンス。そして、ブラックミュージックへの傾倒。隠し切れないTHE WHOへの深い愛情。

飽きのこないしゃがれたボーカル。タンタンと乾いた音のドラム。ヘナヘナした音の腰くだけオルガン。はねまわるベースはきっちりメロディも刻み、ギターはなんとも言えない魅力的な鳴きを見せる。

ここにはモッズのための大切な要素がすべて詰まってます。アルバムとしての統一感も絶妙で、ラスト12曲目の"NEW SLOUGH"が8分以上もジャムっているんですが、冗長なかんじは皆無。最高。

これで、トータル39分34秒。あっという間の12曲。

ひさしぶりにこんなに人をハッピーにさせる力を持ったバンドに会いました。イメージとして一番近いのは、mover。黒さ、そして他にはない圧倒的なメロディのセンス。聴いているだけで踊りだしたくなるグルーヴ。60年代ロックの要素を強く持ちながら、けしてそれだけで終わらせず、ちゃんと現代の音楽としてまとめているバランス感覚はすばらしいの一言。そう、これが聴きたかったんです。

リバプールにはThe La'sがいましたが、どうやらデンマークにはTHE BLUE VANがいたようです、とまで言ったら言い過ぎでしょうか。

The Art of Rolling

posted with amazlet at 05.08.21

The Blue Van
TVT (2005/04/05)
売り上げランキング: 8,180

Amazon.co.jp で詳細を見る

追記）このアルバムの一番の凄さは実は「音」そのものかもしれない。ここには、他のすべてのバンドが失ってしまった「あの時代のあの音」がなぜかきっちりと鳴らされている。ひとつひとつの音がブリブリと弾力性を持って跳ね回っている。音自体にこんなに魅力を感じたのは、thee michelle gun elephantの超傑作シングル "Get up Lucy"以来かも。（シングルの方。アルバム収録のものとはまったくの別モノ）

Get up Lucy

posted with amazlet at 05.08.21

Thee michelle gun elephant チバユウスケ
コロムビアミュージックエンタテインメント (1997/08/01)
売り上げランキング: 65,939

amazlet.com で詳細を見る

ちょうどHarvard Business Reviewで気になって書こうと思った内容が梅田さんのブログにアップされたいた文章とシンクロしたので、こちらを手がかりにしてエントリしてみようと思う。

まずは、Harvard Business Reviewの話をご紹介しよう。DIAMOND Harvard Business Review 2005.9号の「摩擦のマネジメント」(John Hagel III/John Seely Brown)中のコラムだ。

現代の「企業の本質」とは何か

　企業の存在意義とは何か。一つの論文が、研究者や経営者たちの考え方を長らく支配してきた。ノーベル経済学者のロナルド・コースが、一九三九年に発表した”The Nature of the Firm"(企業の本質)である。

　 この論文のなかで、コースは「経済活動には必ず取引コスト、もしくはインタラクション・コストが伴う。そこで企業という組織が存在したほうが、市場よりも低コストで資源を調達できる場合がある」と主張した。つまり、企業の存在意義は、主に取引コストの効率化であるというのだ。

　 しかしその後、ＩＴが発展し、企業内および企業間のインタラクション・コストは、徐々に低減していった。そこで、そろそろ企業の存在意義について再考すべきときではなかろうか。

　むろん、企業の存在が不要になったというわけではない。むしろ、経済価値を創出する上で、以前とは異なる形で重要な役割を果たし続けるだろう。

　我々が思うに、企業の存在意義は、既存の資源を効率的に利用することから、ケイパビリティの構築と組織的なイノベーションの創出へと変わってきている。

　単に、コア・コンピタンスは戦略の基盤という意味ではない。それよりも―たしかにそれとも関係するが―「コア・コンピタンスは企業の存在意義そのもの」なのだ。

　これからは、最も効率よくケイパビリティを構築できる企業だけが価値を創造し続ける。それ以外の企業は、朽ち果てるしかない。

これを読んで思ったのが、たしかにすべてではないにしても、少なくとも一部の分野については確実に企業としての形態をとるメリットは薄くなっていくであろうということだ。

コースの主張した「企業という組織が存在したほうが、市場よりも低コストで資源を調達できる場合がある」という話は、いわゆる規模の経済である。これが、ITの発展によりインタラクション・コストが大幅に低下したことで、従来ほど大きな差（競争優位性）として働かなくなってきたという内容だ。

このコラムでは、新しい企業の存在意義は「ケイパビリティの構築」と「組織的なイノベーションの創出」だと言われているが、これは企業という形態を維持するならば、少なくともこれが必要になる、というものだろう。

もし企業という形態にこだわらないとしたら、将来的にスケールメリットがかぎりなく０（数値的にゼロなのではなく、相対的にゼロとみなせる程度に抑えられる）になる分野であれば、そこでは個人と企業が対等に競いあうことが可能になるかもしれない。

「三人寄れば文殊の知恵」は今でも大事な教えだが、これは何も企業という組織の形態をとらなくてもその成果を得ることができるということを、インターネットは教えてくれた。むしろ組織や委員会よりもよっぽど効果的であることも多いのだ。組織を組むことは必要条件ではないだろう。

ビジネスモデル、コア・コンピタンス、継続的な利益回収の仕組み、どのような言い方でもいいが、競合する相手よりも優れたものを持っていれば、他はアウトソースすることで個人が企業と戦うことができる時代が来るかもしれないのである。

そして、そのようなコンテキストの下で梅田さんのブログを読んだため、意外と本当に「インターネット上にできた経済圏に依存して生計を立てる生き方」は近い将来の現実なのかもしれないと思ってしまった。

「ネット副業の達人」書評
http://d.hatena.ne.jp/umedamochio/20050816/p2

　私がいま最も注目している「次の十年」の大変化の「芽」は、「インターネット上にできた経済圏に依存して生計を立てる生き方」である。インターネット上に自分の分身(ウェブサイト)を作ると、リアルな自分が働き、遊び、眠る間も、その分身がネット上で稼いでくれるようになる世界。

(snip)

本書は「インターネットを使った副業で本当に稼いだ20人の記録」である。「副業」という言葉からもわかるように、現代の常識はこの20人を傍流としてしか見ない。日本で最も先端的な生き方をしているにもかかわらずだ。益子焼和食器、ミャンマーの天然石、手作りの「犬服」を売るビジネスは、ネット販売と言うよりもプロデューサーと呼ぶべき性格の仕事だ。

(snip)

検索エンジンや広告配信インフラの登場によって、リアル社会では結びつく可能性すらなかった個と個の間の微細な需給関係までをもきめ細かくマッチングできるようになった。それらが、小口決済インフラ、日本中に行き渡ったリサイクル・ショップや宅配便等のリアルなインフラとも結びつき、経済圏としての可能性は大きく広がった。(snip)こうした一連の変化によって、個人が不特定多数無限大の人々とつながるコストは限りなく小さくなり、元手(資本)がほんのわずかでも、何かを始めることができるようになったのだ。

そして、話は大きく跳んでしまうのだが、SOAの語られるべきコンテクストも実はこの辺りにあったりするんじゃないかと思ったりしている。

SOAとWeb2.0
http://www.arclamp.jp/blog/archives/000652.html

　SOAをWeb2.0のように、シェアと再構成という文脈で考えればいろいろなアイデアが浮かぶ。Web2.0のオープン・データのコンセプトを企業内で行えばどうなるのだろうか？SOAの元々のコンセプトは、APIを公開しレポジトリを通じて様々なサービスを提供することにある。なぜ、こんなにも Web2.0と乖離しているのだろうか。SOAがイノベーティブな価値を生み出す可能性をもっと語るべきではないだろうか。

SOAはサービスどうこうという切り分けよりも、データの再利用を図りましょうということだと捉えている。そして、「SOAがイノベーティブな価値を生み出す可能性」としてはそれ自体がイノベーションとなるというよりも、色々な可能性を実現するプラットフォームを築くものなのだと考えている。

つまり、今までは企業のようなスケールを持つものしか利用できなかったようなデータが、Webサービスを介して容易に再利用できるようになってくる。例えば、GoogleMapsのように。これまでの常識では個人がmap.rails2u.comのような優れた地図ソフトを作れるような可能性はなかったのだ。

こうして実現されるのは、やはりインタラクション・コストの大幅な低下であり、個人であれ企業であれ、「一つの競争優位な仕組み」自体の相対的な価値の向上なのだと思う。

Harvard Business Review (ハーバード・ビジネス・レビュー) 09月号 [雑誌]

posted with amazlet at 05.08.17

ダイヤモンド社 (2005/08/10)
売り上げランキング: 1,407

amazlet.com で詳細を見る

Alex Bosworth's Weblogで面白いものが紹介されていた。

http://sourcelabs.com/ajb/archives/2005/08/gated_community.html

del.icio.usのプライベートブックマークだ。

URLs saved with this bookmarklet will not appear to anyone that you have     bookmarked them.

との言葉のとおり、フォークソノミーやWeb2.0の理念を見事に逆行しているものだけど、実際あまりおおっぴらにしたくないブックマークもある。

今まではこっそりはてなブックマークと併用したりして、はてなの方にプライベートなブックマークを入れたりとか自分で使い分けていたのだけど、これでdel.icio.usで統一できるかもしれない。

問題は、今の仕様だとタグから辿って自分がブックマークしていることが知られることはないけど、URLで直接開かれると自分のプライベートブックマーク自体は極めてオープンな状態で見られることだろうか。　（ウソでした。loginした状態でないと自分のIDのプライベートブックマークは見られません。）

ともかく、del.icio.usユーザーの方は一度試してみてもいいかも。こちらからどうぞ。

Ringo's Weblogさんの言語のネットワーク外部性を読みながら思ったのだけど、このご時世に「たかがツール」である言語に人間の思考やその他諸々が制限されるのはなんともくだらないことだと思う。たとえそれが人間の生み出した最も偉大なツールの一つだとしても、だ。

ringoさんも

  この動きは、メタデータを活用した自動翻訳の普及などによってさらに加速されるだろう。

と書かれているが、より直接的に表す意味自体を定義するフォーマットが出てくるのかもしれない。メタデータというよりもむしろそれ自体が生データで、各言語がそのビューというようなイメージで。

どうもこういう話を考えるとすぐにエスペラントが思い浮かんで、現実味が薄れてしまうな。

Days of Lirisさん経由で知った、eGroupWareすごすぎです。たしかに「なんじゃこりゃ」ですね。

とりあえず、デモを動かしてみてください。

ブラウザ内ブラウザ辺りになると、もう何がなにやら。

今日（もう昨日になってしまいましたが）8/14、ZEPPET STOREが最後のワンマンライブを終えました。

ライブレビューは 色々と思いがありすぎて何書けばいいかわからないので、最初のアルバム "Swing, Slide, Sandpit"から最後のアルバム   "BLACK BERRY BED"までを順番にレビューしてみようかと思ってます。その最後に何か書くことがまとまっていればいいな、と。

ちまちまと更新するので、読んでくださる方は気長に読んで頂けるとうれしいです。（何週間？何ヶ月？いやまさか何年？）

このブログが目に触れる機会があるかはわからないけれど、本当にどうもありがとう、ZEPPET STORE。

これからもずっと聴き続けます。

※ 　残念ながら、幻の再結成ライブ「RISING SUN ROCK FESTIVAL 2005 in EZO」は行くことができません。行かれた方は感想などをトラックバックくださるとうれしいです。あと、Last   Tour "4 - for -"の感想などもコメント、トラックバックなんでも大歓迎です。

様子だけ見てみたくて、友人に誘ってもらい仮名で徘徊してみた。

そして実感。

あれだけプライベートな人間関係や友人関係が駄々漏れなところで本名晒す度胸はないな。

どうしても企業の人事が本名で検索かけた場合のケアとかを考えてしまう。（いや、別に転職予定とかないけど）

ここは一応そういうことをフィルターかけてから書いているから見つかってもいいけど、mixiだと友人関係の馬鹿話が全部見られるのがあまりにイタイ。色んな意味でイタイ。

資料が出ている。

http://conferences.oreillynet.com/pub/w/38/presentations.html

まだ、ほとんどの資料を読めていないのだけど、Jim Weirichの"10 Things Every Java Programmer Should   Know About Ruby"はRubyのとっかかりとして魅力をわかりやすく伝えていて、とてもよかった。Ruby好きの人には新しい情報はあまりないけど、丁寧に整理さ れていて何より説明が理解しやすい。

上記にあるのはアーカイブなんで、直接見たい人はこちらから。

http://onestepback.org/articles/10things/index.html
  (via. RedHanded   "OSCON Goods from Matz, Weirich")

これから読みたいのをメモっとく。

• 45 Things to Do with RSS and Atom
• Enterprise IT: Open Source Powerhouse
• How to Safely Participate in an Open Source Project
• Keep It Simple with PythonCard
• Leveraging Open Source for SOX Compliance
• Tech Trends: Hard Numbers Behind the O'Reilly Radar
• The Evolution of Web Application Architectures

とりあえずこんなかんじで。

インターネット時代は文化を楽しむのに適した時代だと思う。

本でも音楽でも絵画でも、良いものを見たい、面白いものを知りたいと思ったら、その道に精通した人が良いと感じたものを試してみるのが一番だ。

今の時代なら、ブログやらMLやら趣味のサイトやらいろんなところから、それが大好きで見続けている人の生の意見を見ることができるから、本当に面白いものの情報を手に入れやすい。

文化的なものについても、自分ですべてを試さなくてもあるフィルターをかけた上で楽しむことができるのは効率的な時代だと思う。（幸せかはちょっと別の問題だけど。）

投稿欄とか管理画面とかが大幅にリニューアル。
全般に使い勝手の悪かったところが、丁寧に変更されていて好印象。

WYSIWYG型のエディタが追加されたのはうれしい。

と、使用してみたけど、全部<br>タグで改行してくのか。。「HTMLを確認」が非同期でパカパカ切り替えられたりいいかんじなんだけどおしいなぁ。これだとまだはてなダイアリーの方が使いやすいかな。まぁ、上を見ればキリがないってことで。

個人的なメモ。Windowsでネットワークドライブの割り当てをバッチで復元するに は。

net use [ドライブレター] [パス名] /PERSISTENT:YES

ex) net use M: \\xxxxxx\samplefolder /PERSISTENT:YES

Ruby Mix-inの詳細については、まつもとゆきひろさんの日経Linux 2005年7月号の連載「まつもと直伝プログラミングのオキテ　第３回　多重継承の光と影」に詳しいので、気になった方には強くおすすめ。

日経BPの記事検索サービスでこの記事だけのダウンロード購読もできます。（値段高いけど、このシリーズに関しては払う価値あります。）

Mix-inの解説の一部だけを抜粋。

　Mix-inというのは元々Lisp界で始まった多重継承の使い方です。Mix-in手法には次の2つの条件があります。

• 通常の継承は単一継承に限る
• 2つめ以降の継承は，Mix-inと呼ばれる抽象クラスからに限定する

　Mix-inクラスは以下のような特徴を備えた抽象クラスです。

• 単独でインスタンスを作らない
• 通常のクラスから継承しない

　これらの規則に従うことで，クラス階層は単一継承と同じ木構成になりますし，機能の共有を実現するには，共有する機能だけを持つMix-inをクラス階層木に「差し込む」ことで達成できます。

この回は他にも実装の継承(Javaのextends)と仕様の継承(Javaのimplements)についての話など、とてもわかりやすくまとまっていて良い内容でした。（Rubyファンでない方は、「けっきょくRubyを誉めるのかよ！」て思うかもしれませんが、そこはご愛嬌）

Mix-in話は過去の「Matzにっき」にもためになる話がありました。

http://www.rubyist.net/~matz/20040127.html#p02
http://www.rubyist.net/~matz/20040128.html#p01
http://www.rubyist.net/~matz/20040128.html#p03

それぞれコメントも面白いので、お好きな方はぜひどうぞ。

fladdict.net/blogさんの「OOP全盛期だけど、手続き型がマイブームになってる（前）」を読んで、んー、これってMix-in的なあれなんだろうか、とかうだうだ考えていたんだけど、ちゃんと考える時間がなくなったんで、とりあえずメモだけして寝ることに。

OOP全盛期だけど、手続き型がマイブームになってる（前）
http://www.fladdict.net/blog-jp/archives/2005/08/oop.php

じゃあ、なんで「手続き型」がいいのかというと、手続き型だと他人のライブラリを導入するときや、自分のライブラリを再設計するときに、既存資産の運用がく柔軟にできるのではないかと思ったりしたんです。

oo的な方は、Colorの実装の継承をしてColorHSBを。Colorの実装の継承をしてColorGrayを。んで、両方を利用できる新しいクラスを作りたい、と。でも内容的に多重継承はNGなんだろうな。

で、これを手続き型の方で解消している手段として、ColorUtil.setHSBの中にColorHSBクラス的な処理を閉じ込めていると。

そして、ここからが面白い。

で、ここからが応用。
「手続き型」は関数の呼び出し作業が煩雑なのがネックなわけですが、これをOOPで解消するっていうのはどうでしょう？手続き型関数ColorUtilを作成した上で、Colorクラスを拡張してColorHsbを作ります。そして、ColorHsbのsetHSB()の処理では、内部的に ColorUtil.setHSB()を呼び出すように処理するわけです。

function setHSB(h, s, b){
ColorUtil(this, h, s, b);
}

こうすると、ユーザー的には手続きを意識しないでOOPで作業ができます。またColorGrayのような他人のクラスであっても、 ColorGrayを拡張して内部でColorUtilにバイパスしてやれば、ColorGrayにsetHSBを実装するのも一瞬ですみます。超楽チン。変に多重継承するわけでもないので、オブジェクトツリーがレガシーで埋まることもなく、自分のライブラリをブラッシュアップとかするのも凄い楽になります。

こうすると、OOPの利便性を機能を保ちながら、オブジェクトとアルゴリズムを分離できるんじゃないかと思ったわけっす。処理は微妙に重くなるけど、最近のパソなら大丈夫っしょ。

これって、ちょっと実装上は違っているけど、発想は完全にRubyのMix-inですよね？

「なんだ車輪の再発明じゃん。」ていう意味ではなくて、自分で考えてここまで来ているってすごくないですか？

私は答え（Mix-in）を先に知ってしまったので、あー、なるほど。うんうん。というかんじでしたが、Ruby＆Mix-inを知らずに何もヒントなしにこれを自分で応用できたかというと疑問です。（いつかは何かを読んでたどり着いたかもしれませんが）

読みながら純粋に感動してました。

で、Ruby的な模擬コードを書いてみたので、書いておく。

こいつが元々の状態。

で、ColorGrayが出てくる。

このsetHSBの手続き型プログラミング的な解法をRubyのMix-inを利用してやると、こんな風にまとまる。

これでどうなるかというと、ColorHSBのインスタンスからもColorGrayのインスタンスからもsetHSBが呼び出せるようになる。

わかりやすいようにここではColorHSBというクラスをそのまま拡張して作成したが、実際にRubyでプログラミングする場合はColorHSBは作らずにColorクラスに追加でinclude ColorUtilだけしてやると思う。（ケースにもよるとは思うが。）

そうすると、Colorを継承しているColorGrayは自動的にsetHSBを使えるようになる。

なんやかんやで最終的なイメージはこんなかんじ。

てなかんじ。Love Ruby!

「OOP全盛期だけど、手続き型がマイブームになってる（後）」もあるようなので、期待してます。

# うわぁ、全然「メモだけして寝ることに」にならんかったー！

「ふっかつのじゅもんがちがいます。」さんの「ペアプロと上司でないマネージャはすっぱいブドウ」から。

僕の知る限り優秀なプログラマは大抵就業時間の30%くらいしか労働しない。

こういう話を読むと、マネジメントな人はこう思うに違いない。

「なんだって！？そんなにサボっていたのか。残りの70%も働かせれば大儲けじゃないか！」

それは違う。プログラマはこの30%に宝石のようなコードを吐き出すのだ。

残りの70%は大抵バグやらいらないコメントやらブログへの落書きやら自分用ツールやら今日の晩飯やらしか生み出していない。

残りの70%も働かせたとき、プログラマは宝石を産まないニワトリとなるだけだ。

（と、スーツにはバレないように誰かが書いておくべきだと思うのだが。たとえそれがウソだとしても。）

めずらしく単なる商品紹介。

いや、これ面白いんですよ。機械いじりが好きな人はついついはまりますよ。

Hands on Science: Get in Gear (Hands-On Science (Innovative Kids))

posted with amazlet at 05.08.08

Sholly Fisch Mark Oliver
Innovative Kids (2002/10/01)
売り上げランキング: 75,135

amazlet.com で詳細を見る

Amazonの紹介文のとおり、

『Get in Gear』の特徴
・本物の電気モーターと交換式バッテリー
・実際に使える19個の歯車と部品
・たくさんの装置を自分で組み立てられる
・色分けしてあるので組み立てが簡単
・読みやすい文章
・歯車に関する驚くべき事実
・らせん形のデザインが作れるPlanetary Picture Producer［遊星歯車を使用するデザイン定規のような作図キット］
・自分だけのオリジナルデザインが作れる
・歯車や部品をすべて収納できる便利なトレイ

てことで、大小のギアを組み合わせて動くのを眺めて一人にやにやするというネクラなおもちゃなんですが、特徴に「・自分だけのオリジナルデザインが作れる」とあるように最後のページではフリーレイアウトでギアやらなんやらを組み合わせられるようになっていて、これが楽しいです。

対象年齢はたぶん結構小さい子対象なんだろうけど、疲れた頭で休憩代わりにウィンウィンやってると休憩で済まなくなって困ります。

※一応、英語の本ですが、図解だけ見てれば簡単に組み立てられます。（というか、とても単純なんで目の前にギアがあって、完成図が見られれば大人ならすぐ作れちゃいます。）

retreatと呼ぶのか。

「Life is beautiful」さんより。

http://satoshi.blogs.com/life/2005/08/post_1.html

これはトップダウン型の戦略で進んでいるプロジェクトでは実はとてもとても大事なものになると思う。これがないと、一年、二年もののプロジェクトなんてあっという間に「日々の作業」に成り果てるよな。

会社で日々の仕事に追われていると、「自分が今している仕事は、プロジェクト全体の中でどんな役割を果たすのか」、「そもそもこのプロジェクトは会社にとってどんな意味を持つのか」などを考えたり話し合ったりする時間も機会をなかなか作ることができないので、あえて会社から離れた所でミーティング（英語では off-site meeting）をすることによって、その辺りの意識合わせをしっかりとしようという試みである。

　マイクロソフトでは、この手のミーティングを retreat （直訳は「退去」）と呼んでいたが、これはビジネスを戦争に例えるのが好きなビル・ゲイツが、最前線で戦う戦士たちを敵の弾の届かない所まで一旦退去させ、体を休ませながら次の戦略を練るイメージで使い始めた言葉だ。破竹の勢いで敵を打ち倒しておきながら、時々「退去」して戦列を立て直す、というあたりが、ビル・ゲイツを超一流の武将にしている由縁だな、つくづく関心したものである。

温泉に行くというような余暇的な意味合いを持たせるかはともかく、ちょっと気分を晴れやかにさせられる場所で

「自分が今している仕事は、プロジェクト全体の中でどんな役割を果たすのか」、「そもそもこのプロジェクトは会社にとってどんな意味を持つのか」

を整理するのって重要。

定量的に計測してみないと何とも言えないけれど、アウトプットの品質に大きく関わるんじゃないか。特に長いプロジェクトであればなおさら。

これを実際にプロジェクトの渦中でやるのであれば、単なる愚痴大会で「あー、なんだかんだ言っても結局やるしかないんだよねー」っていうありがちな結論に落ち着くのを防ぐのために、「すごい会議」的にちゃんと流れをマネジメントしてやる必要がありそうだな。

おおいゆうすけさんの「とりとめもなく日記的雑記」の「馬場さんご本人？へのご回答」へトラックバック。

日経コンピュータの馬場史郎氏の連載への意見を書いたら、Babaさんという方から返事が来ていましたよ。という話だ。

どうも単に問題意識のずれが根っこにあるだけで、どちらも求めているものはあまり違わないような気もする。
馬場氏＆Baba氏は「社会人なんだからビジネスのルールくらいは知っとけよ。」という意見だし、おおいゆうすけさんは「エンジニアなのになんでこんなことも知らないんだよ！？（最低限必要な技術は身に付けようよ）」という意見のようだ。

つまり、ビジネスルールをわきまえないエンジニアへの意見と、技術力不足のエンジニアへの意見がごっちゃになっている。おそらくどちらも想定される過去の誰かへの思いがイメージにあるのだろう。

現実にはどちらのパターンの人もたしかに居て、一緒に働く身としては、どちらのパターンもそれぞれぜひとも改善してほしいので、この話自体への感想は、「うんうん、どっちもその通り！」といったところ。

実はようやくここからが本題なのだが、テーマとずれた箇所が面白かった。

http://www.yusukeoi.net/archives/2005/08/post_115.html

僕の（馬場氏より格段に少ないですが）経験から言えば、技術的にベストでないソリューションを、人間力でなんとかしようとするSEが多すぎると思います。

技術的な質が高いとはいえないデザインでシステムを作り、プロジェクトがトラブルになるとします。そして、そこで活躍する火消しSEがいますよね？そういう人って、トラブルプロジェクトを救ったスーパーSEとして、賞賛されますよね？特に日経コンピュータなんかは、そういう風潮が強いように思います。確かにその火消しSEさんもすごい人なんでしょうが、本来必要なのは、高度な知識と専門性を持って、その技術力でトラブルが起こらないようにデザインや実装を行うSEさんではないでしょうか。

これもおっしゃるとおり。そして、言い尽くされてきたように上流での良い仕事が下流での問題を防ぐわけで、火消しをしないでいいプロジェクトであるに越したことはない。

「越したことはない」わけなんだが、実はこの火消しスタイルの根底には低価格化が進むこの業界の構造的な問題があるような気がしている。

それは、こんなデスマスパイラル。

1. 営業的に勝つために、安く請け負う。
2. 請け負ったはいいが、当然赤字は避ける必要がある。
3. まずはそこそこ黒字になるように、安い人材から投入。
4. 安い人材＝経験不足の若手 or 実力のないベテラン
5. 当たり前のように炎上
6. 仕方なく火消し（最初よりはいいベテラン、優秀な若手の投入、人員増、コストも跳ね上がり）
7. 赤字

なんだかそりゃ失敗プロジェクトも量産されるよなーと思う。

だいたい、「技術的にベストでないソリューションを、人間力でなんとかしようとするSEが多すぎると思います。」どころか、「技術的にベスト」かどうか検討しようともせず、問題意識すらない人だっている。それはきっとベターなものがあるという経験がないから、ずっと「最初に思いついたデザイン＝答え」で行ってしまうのだと思う。

それじゃ、どうやったらそのベターなものを検討する機会が得られるかというと、自分のよりも優れたデザインと出会うしかない。そのためには、自分よりも力のある技術者と仕事をするか、あるいは文字情報としてでも優れたデザインを吸収できるよう本やWebを漁りまくるしかない。

そうすると、やっぱり安いフィーでほいほいと働かせられる人材ではなくなってくるのではないかと。

こう技術者もその製造物もコモディティ化してくると、（人月スタイル自体の問題は置いておくとしても）人月単価で見積りをして、その金額はすべて発注元がかぶるというスタイルは破綻しつつあるような気がする。そのスタイルで「いい製品」を提供するにはかなり厳しいラインにまで単価が下がってきているのかな、と。

「だから、ASPだ。salesforce.com万歳！」というような短絡的な解決策は挙げないけれど、システム開発で食い扶持を稼ごうという人は、「どこで利益をあげられるのか」をそろそろ真剣に考えなければいけないのだろうと思う。

どのようにすれば、シンプルで効果的なデザインの製品をコンスタントに作り上げることができ、かつ自社もばっちり儲けられるのか？

このまま顧客の信頼をなくすようなスタイルでシステム開発をしていくような企業は、上記の問いにかっこいい解答をあみ出した企業に追い落とされますよ、きっと。

del.icio.usの動作でとても好ましいものがある。それはブックマークのdeleteだ。

たまにしか使わないし、小さなことなんだけど、非常にユーザビリティが高い。

deleteの機能自体はどのサービスにでもあるだろう。del.icio.usのやつは実装に小技が効いている。

これが通常の状態だ。

そして、deleteをクリックするとこのようになる。

この状態で'YES'を押せばそれでdeleteは終了だ。'NO'を押せば何事もなく一覧に戻る。

ちなみにこの操作は別画面でこの項目だけをいじれるのではなく、リスト表示されている状態で動的に動く。これが小気味良い。

たしか昔のdel.icio.usはdeleteの際も画面が遷移して、確認画面でのYES/NO選択だったはずだ。この使い勝手の違いはとても大きい。

さっさと済ませたいつまらない作業だからこそ、スムーズに終わらせられるような一工夫がとてもうれしいのだ。

職場で雑誌の記事紹介を書いている。社費での購読雑誌の利用促進策らしい。

で、今月はDB Magazineの9月号についてこんなことを書いてみた。

--

DB Magazine 9月号の紹介です。

〜記事紹介〜

DB Magazine　２００５．９

『身近なXML利用でますます高まる実践レベルの知識と技術力の価値』
（P150〜P159）

基本的にはXMLマスターの試験広告です。サンプル問題の掲載などもあります。

XMLマスターの話に行くまでに最近のXML活用事例が軽くまとまっています。（内容はそれなり）


”身近なXML”に必要なこと

さて、この記事からは見えないXMLの本質的な部分をちょこっと解説しましょう。

記事冒頭の最近のXML活用事例でもわかるように、基本的な活躍の分野は二種類に分けられます。

・Javaとの連携
・構造データの表現フォーマット

・Javaとの連携

この用途でXMLが使用される理由の指摘に面白いものがあります。

http://www.rubyist.net/?matz/20050105.html#p01

XMLはJavaよりもずっとagileでflexibleなので、「Javaアプリケーションのスクリプティング」の標準的言語の地位を確立しているのだ。

Javaではちょっとしたことを書くのにもかなりの量の「おまじない」が必要です。
で、それはわずらわしいから、もう少しやわらかいXMLを多用して、そのJavaのデメリットを吸収してしまおう、という理由で使われているという説です。

・構造データの表現フォーマット

一方の構造データの表現フォーマットとしてのXMLは上記のリンク先で言う、「interoperability」を実現する使い方です。

この使い方についてはXMLが不向きだという意見があります。

http://www.rubyist.net/?matz/?date=20030507#p02
http://www.rubyist.net/?matz/20030508.html#p04

まつもとゆきひろさんの主張のとおりYAMLを使うかどうかはともかく「ちょっと使いたい」時にXMLが冗長だというのはたしかです。（そして、たしかにYAMLは気楽に使える。）


業務アプリケーションの開発という視点に立てば、単純に”標準としてのXML”という利用も馬鹿になりませんが、「とにかくなにがなんでもXML」と考えるよりは、なぜそこでXMLを使うのかを理解すること、そしてよりよい使い方はないのかを意識することこそ”身近なXML”に必要になるでしょう。

※　もう一つのピックアップ記事。
　　P44-47のイーシー・ワンCEOのインタビューは面白いです。

--

さっぱりDB Magazine自体の利用促進になっていない。

イーシー・ワンのCEOインタビューは時間があったら、こっちで少し触れたいと思っている。

今週の週刊ダイヤモンドから。

これってたぶんあの去年読んで行きたくて仕方なかったけど、店が特定できなかった店のことなのだ。

ダイヤモンドの飲み屋紹介記事で紹介されていたのは、「けむり」

所在地：東京都千代田区神田須田町1-11-5
ＴＥＬ：03-5294-0035
営業時間・定休日：11:30〜14:00/17:00〜23:00(LO)
土曜日はランチタイムなし
日曜・祝日休

この店がたぶん去年の岸田日記に登場していて、うちでもちょっと触れたこの「燻製専門のレストラン」なのだと思うのだ。

11/18(木)

　よく行くリハーサルスタジオの隣に、燻製専門のレストランがあり、最近よく行く。厚焼き玉子の燻製にはびびった。これぞほんまもんの和洋折衷やと思った。ビックリするほど美味いよ。あと、半熟玉子の燻製を生ハムで巻いたやつや、リ・ド・ヴォーを生ハムで巻いたやつ、チキンや魚介類から豆腐まで、世の中の食い物全部スモークしてくれと思うくらい美味い。

いずれにせよ、食べに行かねば！

世間のITと音楽の関係は将来の楽曲配布の方式とその収益モデルのような話で盛り上がっている。

この点についてはあまり確定的な案を出せないし面白い意見も今のところ出せないので、一音楽好き＆IT好きとしての別視点の話を書こうと思う。

テーマは、インターネットと相性のいい”音楽の売り方”だ。（あくまでもこれは音楽好きのための未来予想図だ）

• カタログ方式とおつかい方式
• Music Tree
• Music Treeとカタログ方式
• WikiとMusic Tree

カタログ方式とおつかい方式

インターネットでの販売業を利用の仕方から分類すると、大きく分けて二種類の利用の仕方がある。それがカタログ方式とおつかい方式だ。

カタログ方式は通販カタログのようなものだ。商品を魅力的に展示し、利用者はあれこれ気になるものを眺めながらほしいものをショッピングカートへと放り込んでいく。ウィンドウショッピング方式と言ってもいい。ポイントは何を見せるか（いかに利用者にとって魅力的なものを見せられるか）とどのように見せるかだ。

もう一方のおつかい方式は、もっとわかりやすい。これは検索方式だ。利用者はすでに欲しい商品を決めてサイトに来ている。その商品を買ったら用事は終了、だ。

現在のインターネット販売業を見ていると、たいていこの両者に対応できるハイブリッド方式となっている。トップにはずらずらとお勧め商品やお買得商品が並び、その一角には検索用のスペースがこじんまりと構えられている。

Music Tree

音楽ファンに最適な販売方式の話へと進む前に一つ音楽ファンの傾向を紹介しよう。

音楽を好きで、家に地震のたびにひやひやするような量のCDを積んでしまっているような人はどうやって音楽の趣味の幅を広げていくのだろうか？

この答えは、Music Treeにある。

Music Treeは音楽ファンならなんとなく言いたいもののことが分かると思うのだけど、言い換えるとすれば、「ルーツミュージックを探る」だとか「TOWER RECORDS発行のbounceのpeople tree」だとかがイメージと重なる。こういった音楽のつながりを全部ひっくるめたものがMusic Treeだ。

まず始まりとなる好きなアーティストがいる。好きなアーティストなので、たくさん聞き込む。とても好きなので、そのアーティストが好きだといっているアーティストや音楽性を形作っているような昔のアーティストを探して聴いてみる。

また、好きなアーティストはたいていあるジャンルに分類されている。グランジだったり、あるいはパンクだったり、ヒップホップだったり、レゲエだったり、ジャズだったり。さらにそこから細分化されてその時代時代でよくわからない音楽性にカテゴライズされている。そうすると、自分が好きなアーティストと同じジャンルに分類されている人たちは好みの音を鳴らしているかもしれないと思ってそれも聴いてみる。

あるいは好きなアーティストが活躍していたのが古い時代の場合、そのアーティストのチルドレンと言われるような影響を受けた人たちが以降の時代で見つけられる。これらも自分の好きな音楽と近い音楽性であることが多いので、探して聴いてみる。

あとは、アーティスト自身がある程度キャリアがあると、そのキャリアの過程でいっしょに音楽をやった人たちがいる。その人づてでたどってもやっぱり好みに近い音が見つかることがある。

おおまかに説明すると、このように連鎖して関係を結ぶ音楽性の近いつながりをMusic Treeと呼ぶ。

もちろん偶然ラジオやレコード屋で聴いた曲がよくて好きになるというようなこともある。ただ、偶然に頼るとなかなか貪欲な音楽ファンの欲求を満たすことはできないので、ある程度音楽好きな人なら誰でもこんな自分の好きな音楽のMusic Treeを持っているものだ。

Music Treeとカタログ方式

そして、このMusic Treeとカタログ方式が相性がいい。最新のおもしろい音楽カタログが読め、そこからアーティストの深い情報までリーチできる。そして気になったらいつでもCD（なり曲なり）をワンクリックで購入できる。

今、一番このイメージに近くて個人的に楽しんでいるのは、HMVのミュージックストアだ。

たとえばoasisでアーティスト名をクリックするとこんな気合の入ったアーティスト解説が読める。そして、そこかしこに関連する気になるアーティスト名が散りばめられリンクされている。

惜しいのは、リンク先がすべてCDの販売画面となっている点だ。これでは気になってもよくわからないまま画面を閉じてしまう。リンク先はやっぱりそのアーティストの解説ページへと跳び、同じ画面でCDや曲の発注ができる方がより利用者の気持ちに沿うのではないかと思う。

このMusic Treeプラス最新ニュースやインタビューなんかが中心の文字通りカタログなデータがあれば、音楽ファンの必要とする情報は一通り網羅できてしまうと思う。

WikiとMusic Tree

このMusic Treeの情報は必ずしも販売側が提供しなくてもよいと思う。むしろここは音楽好きの血が騒ぐがままに草の根的に情報を育てていくほうが向いているような気がする。現在の仕組みで最適なのはおそらくWikiだろう。

なんとなくぼんやりと見えているだけなのだけど、この辺りの音楽好きがずぶずぶと深みにはまっていく仕組みをWeb上で良好なインターフェースで実現できたとしたら、そりゃもうぼくのようなタワレコで店員のコメント読んで視聴するだけで４〜５時間をあっさりと潰せるような音楽廃人は降参するしかないと思うのである。

ちょっとWikiを調べてみたくて、自宅のPCにHikiを入れて動かしてみた。

単にHikiのソースと動きが追えればいいので、Windows+WEBrick+Hikiの簡易環境。

こんなかんじでできあがり。Hikiの設定は、Hiki公式サイトのインストールページの通り。楽な時代になったもんだ。