«前の日記(2005年03月01日) 最新 次の日記(2005年03月03日)» 編集

Matzにっき


2005年03月02日 [長年日記]

_ [知財] iPodショックから日本企業は何を学ぶのか

「笠原一輝のユビキタス情報局」より。

前回筆者は、今の日本のコピーワンス方式は容認できないと書いた。なぜなら利便性や自由度を損なうという、ユーザー側の論理だけでなく、日本の産業界にとっても、そして結果的にはそれを強いている放送業界の側にとっても有害なモノであると思うからだ。

(中略)

日本の機器ベンダが日本独自の事情に振り回されているうちに、海外のベンダがどんどん魅力的な製品を作り、それを海外でどんどん投入されたら、どうなるか。今後、デルなどのIT系企業がデジタルAVに参入してきた時に、高コストの日本企業は太刀打ちできなくなる可能性がある。日本向け製品と海外向け製品で別の製品を作らされることになれば、それだけ日本の機器ベンダの競争力が低下していくからだ。

(中略)

その結果、日本企業は広告に回せる費用が無くなり、広告を出すことが難しくなる。そうなれば、広告収入に頼っている放送業界にとってもかなり痛い状況になるのではないだろうか。これは言ってみれば“最悪のケース”だが、このまま突き進めば、こうなるのは目に見えているのではないだろうか。

それなのになぜ、良い点だけしか視聴者に示さず(放送業界からコピーワンスの件について聞いたことはない、隠しているとは言わないまでも、触れたくないとは思っていそうだ)、「破滅への道」を突き進むのか。

音楽業界でも同じようなことが起きた(起きつつある)。

なぜ、ネットワークウォークマンが受け入れられなかったのか、それはソニーの幹部が認めているとおり、サポートするコーデックの著作権保護(DRM)を厳しくしすぎたため、ユーザーにそっぽを向かれたからだ。

しかし、そんなことになる前に、もっと緩やかな著作権保護を採用するなどの選択肢はなかったのだろうか? おそらく、ソニーの関係者も心の中では「こんなモノだめだ」と思っていたのだと、筆者は思う。実際、筆者もある機器ベンダの社員に「こんなのじゃ受け入れられないと思いますよ」と何度も言ってきた。そうした時に、機器ベンダの関係者から帰ってきた答えは「それはよくわかっている、でも駄目なんです」というものだった。

駄目だとわかっているのに、できなかったのだ。なぜかと言えば、レーベル側が強行に駄目だと言い続けてきたからだ。

目先の利益しか見えない経営者たちによってコンテンツホルダー、ベンダー、ユーザーすべてが不幸になる。 それがコピーワンスや強DRMのたどる道だ。手遅れにならないうちに手が打てないものか。

_ [言語] カールとターボリナックスがリッチ・クライアントソリューションで提携

本国で不調な言語ビジネスを引き取った(株)カールが生き残るために模索を続けている。

最近のAjaxやJSON*1のようなテクノロジートレンドの前にはますますCurlは不利のような気がするけど、それでもなお、Matzにっきは言語ビジネスに果敢にチャレンジする(株)カールを応援します。

*1  正確にはJSONはAjaxではなく、XMLやYAMLと同類のテクノロジーである。Ajax的アプローチでXMLの代わりにJSONを使うことが注目されているというだけのこと。

_ [Ruby] The Internet Company − Special Offer for Ruby Users

年$50でホスティングを、というのはあまり珍しくないし、単にRubyが使えるというのだと普通の話だが、

  • Ruby CGI
  • FastCGI
  • proxy-integrated WEBrick
  • mod_ruby
  • PostgreSQL

までサポートするのはちょっと珍しい。それだけではない。ここは更に

  • Ruby on Rails (either with PostgreSQL or MySQL)
  • IOWA

までサポートしているそうだ。なんと勇気があることだ。

_ ピアノの移動

出社前に妻と二人で電子ピアノを二階の子供部屋からリビングへ移動。 子供たちが最近一階にばかりいてちっとも練習しないから、というのが理由だが、 練習嫌いの子供たちには別の動機づけが必要なのかもしれない。

それはそれとして、電子ピアノとはいえ結構重い。 腰を壊すかと思った。

_ Computer History Museumに見る小型化の歴史(その1)

「本田雅一の週刊Mobile通信」より。

カリフォルニア州マウンテンビューにあるComputer History Museumに見るコンピュータの歴史。 ハードウェアが着実に、安く、速く、小さくなっていく歴史を目で見ることができる。 この博物館には一回行ってみたいな。

しかし、ソフトウェア、特にプログラミング言語の方はさほど進化していないなあ。 少なくともFortran、COBOL、Lispが生まれた50年代のコンピュータと現代のコンピュータほどの違いはない。 それどころか時代がやっとLispに近づいてきた程度ではないかと。

まあ、言語ってば基本的には「思考のための記法」なので、 人間がすぐには進歩しない以上、そんなに急激には変われないんだけど。

_ [OSS] 効果的なリリースの仕方

アップルは年に2〜3回新製品を発表するが、その度にマック・ファンが熱狂して、マスコミの目を引く。アップルは、その狂騒に乗じて広報活動を行っている。オープンソース・プロジェクトは、こうしたアップルのやり方に学ぶべきである。広報こそ新しいユーザーを獲得する鍵であり、新しいユーザーはオープンソース開発モデルの活力なのだから。

なるほど。考えてもみなかった(だからダメなんだ)。

となると、1.8.4のリリースはOSCONの会場からというのはどうだろう。

問題は宣伝文句だな。完全安定期に入った1.8系では目新しい機能は入りそうにない。 人目を引くためには、もっとたくさんの機能が追加されたリリース、つまり1.9系を打ち上げるしかない、か。

それは開発者サイドにはあんまりうれしくないかも。

_ [言語] JSON: The Fat-Free Alternative to XML

上のエントリでも触れたJSONはJavaScript Object Notationで、 JavaScript(やPython)で読み込める記法でオブジェクトを表現しようという試み。

過去に私が「私はなぜXMLを愛していないか 〜 言語屋の視点から」で書いた XMLへの不満に対する答えにもなっている。

JSONは以下のような「XMLは優れている」という主張ひとつひとつについて、 「少なくとも同程度には優れている」ことを丁寧に示している。

詳細は上記JSONページを見ていただきたいが、 要約すると「JSONはXMLと違って拡張(新規タグの定義)とかはできないし、 ドキュメントマークアップ言語ではないが、 データ表現フォーマットとしては単純性、相互運用性、可読性において同等か、より優れている」ということだ。

Rubyに変換するのも簡単だ。 YAMLとどっちが優れているか、決めるのはちょっと難しいかも。

単純さではJSONの勝ちだが。


«前の日記(2005年03月01日) 最新 次の日記(2005年03月03日)» 編集