Seeds of Seeds: 2008/01

2008年1月30日水曜日

ネットワークゴミ箱

ネットワークドライブならぬネットワークゴミ箱があったら便利ではないだろうか？
ゴミ箱は削除するファイルを保存する特殊なフォルダだ。
ときどきゴミ箱を空にしないとHDD空き容量は増えない。
そこで、ゴミ箱に捨てると、自動的にネットワークゴミ箱へ転送し、転送が完了するとHDDの空き容量を増やしてくれる、しかもゴミ箱から取り出せばネットワークからダウンロードして復活してくれる、無限の容量を持ったゴミ箱があったら、気軽にファイルを整理できるだろう。
技術的には難しくないと思う。
ゴミ箱サイトを用意して、BitTorrentのように常駐タスクとして徐々に転送する。転送が完了すれば削除する。元のフォルダ名を記録しておく。転送が容易なように、削除ファイルはzipにまとめておく。同じパスでも日付で区別できるようにする。
通信をバックグラウンドで行うので、通信条件を設定できるようにする。有料の通信は増やしたくない。
Omnidriveが割と近いだろうか？もっともOmnidriveはネットワークドライブであって、ゴミ箱ではないが。

LAMPのM&A

LAMPとは、Linux, Apache, MySQL, PHPのことだ。WebアプリケーションはLAMPであることが多い。LAMPによって完全なOSSが実現する。
しかし、LAMPの自由に変化が現れている。
PHPはZend社が開発している。
MySQLも会社が開発しているが、その会社をSunが買収した。
Apache自体はまだ非営利プロジェクトだが、関連会社の買収が進んでいる。SpringSourceがCovalent Technologiesを買収した。Covalent TechnologiesはApacheでASP.NET互換サーバを提供している。
Linuxでは、RedHat, Novelなどが開発をサポートしている。
営利企業のサポートはOSS開発に必要なものだ。だから、それによって自由が損なわれるということはないだろう。しかし、質的な変化は起こるだろう。例えば、どのような機能を優先的に開発するかは、その企業の都合になるかもしれない。市場が求めているともいえるので、それ自体が悪いことではない。
次に大きな買収はZendかも知れない。Zendを買収した企業は非常に大きな力を持つ。SunはJavaと競合するZendを買収しないだろう。IBMもJava指向だ。Microsoftは.NETを持つ。Zendに興味を持つのはサーバでサービスを提供する事業を営み、豊富な資金を持つ会社だろう。GoogleはどちらかといえばJava指向だろう。Yahooは資金がなく従業員を解雇しているほどだ。こう考えると意外に買い手がいない。

エミュレータでFirefoxを動かす

x86でないLinuxで、native executableがない場合、エミュレータでx86 executableを動かすことができれば便利だ。
基本的にはシステムコールでバイトオーダーを変換するくらいだろう。
性能は悪いが、少なくとも動作する。
Linuxは非x86環境ではメジャーなOSであるから、このようなOSSはぜひ欲しい。
ちなみにBochsやQEMUはだめだ。これらを使うにはOSごと用意しなければならない。そうでなくても非x86系CPU（とそれを使う機器）は非力なのでそんな余裕はない。

と記事を書いた後で、ニュースを読んだら、IBMがPowerVMという製品を作っていた。ただし、これはUNIXサーバ向けだ。ここで考えている非x86系CPUはPDAなどに使えるローエンドのものだ。

MIDに期待

学校で使える情報端末を探している。
いくつか条件がある。
(1) インターネットにアクセスできる。
(2) Ajaxが動作するまともなブラウザが搭載されている。
(3) 授業で１日中使ってもバッテリがなくならない。
(4) Word,Excel,PowerPoint（互換）ファイルの読み書きができる。
(5) 小さくて軽い。
(6) フルキーボード
順番は優先順位を表す。SaaSを使えばブラウザだけでもOffice文書は読み書きできる。しかし、直接操作できるかどうかで使い勝手は大きく変わる。
このような商品はUMPCとPDAの境界にあたる。
UMPCのように何でもできる必要はない。また、PDAのようにほとんどできないのでも困る。
UMPCは最低でも600g以上する。ポケットに入れておける重さではない。また、値段も高い。
PDAではWindows Mobileが有望だが、WM5の場合(2)が問題だ。WM6でよくなったのかどうか確認していない。
PDAに類する候補１つがiPod touchだが、これがまったく使えない。SafariのAjaxは中途半端でGoogleを完全に再現できない。Wordが読めないのはしかたないが、Ajaxが使えないので、もちろんSaaSも使えない。仮想キーボードはタイプミスを連発する。フルキーボードかタッチペンが必要だ。
機能が１つでも欠けると満足に使えないので、いずれも不十分になる。
そこで期待しているのがIntel MID(Mobile Internet Devices)だ。
300gでフルスペックのFirefoxなどが使える。LinuxベースなのでOffice文書が問題だが、これはSaaSで何とかするしかなさそうだ。もしかしたらOpenOfficeを組み込めるかもしれない。

今後、MIDが一定の市場を形成すると予想するが、実は上記のスペックのほとんどを満足する機種が過去に存在した。それはSHARPのZaurusだ。OpenOfficeではないが、Office互換ソフトが搭載されていた。バッテリも１日は持たないが、バッテリパックを交換すればよい。しかし、Firefoxは動作しない。よって完全にMIDとはならない。残念ながらSHARPはZaurusを育てる道を放棄してしまったようなので、今後再登場することはないだろう。

追記
Skyfireというモバイルブラウザがあるそうだ。Windows MobileでもFlash, Ajaxなどが利用できるらしい。まだβ版のようだが、日本で使えるとうれしい。

何をOSSにするべきか

様々なOSS(Open Source Software)がある。
同種のアプリケーションにも複数のOSSがある。
企業が商品をOSSにしている。
しかし、欲しいOSSはなかなかない。
OSSを開発する動機は様々であり、もちろん功名心も立派な動機の１つだ。既存のOSSが使えないと思うと新しいOSSを作ろうとする。しかし、その前に既存のOSSに新機能を組み込むように提案するほうが先だろう。まして、OSSはソースが公開されているのだから、自分で改造したソースを提供すればよい。このようにしてOSSアプリケーションを整理する必要がある。
また、同種のアプリケーションで共通のモジュールを使えるようにし、サブモジュールとコアを明確に区別することも重要だ。Open Plug-in/Add-onを考える時期に来ているだろう。競争もよいが、時に協調があってもよい。
また、企業が製品を続々OSSとして提供している。しかし、あまり使えない。いくつかの理由が考えられる。１つは、それぞれのソフトがその企業文化に根ざして開発されているからだ。ユーザインターフェースやワークフローに独特の考えがある。極めて個性が強い。また、その企業のソリューションでは重要な部品かもしれないが、他社は競合商品を既に持っているので利用できないということもある。
単純に製品をOSSにするのではなく、機能に分割して個別にOSSにするなど配布方式も工夫する必要があるように思える。せっかくの貢献が全くの無駄になっているようでもったいない。

映画 Harry Potter

ハリーポッターは全世界でベストセラーだが、その映画の話をしたい。
最初に原書を手に取ってから、日本語版、映画と読んできた（映画を読むといえるか分からないが）。
第１作の映画は原作が映画化されたという期待感もあって、見ていておもしろかった。
しかし、最新刊に近づくにつれ、映画がおもしろくなくなっている。これは個人的な感想なので、違う意見の人もいるだろう。
いくつかの理由が考えられる。
１つは飽きてきたことだ。映画だけでなく原作にも飽きてきた。執着がないので、どちらも面白いと感じない。まだ、原作の方は惰性で読む気になるが、見る気のない映画を見続けるのは結構苦痛だ。能動的にかかわるメディアと受動的にかかわるメディアの差が出てきたという気がする。
１つは原作の長さだ。第１巻は２時間の映画で十分に表現できていたように思える。しかし、その後どんどん厚くなり、ページ数が増えた。元々１年の話である。様々なイベントが起きるが、細かく描画していたら２時間では収まらない。映画館の都合にせよ、DVDの都合にせよ、いずれにせよ映画で２時間を越えるのは難しい。おそらくTVシリーズならもっと満足出来たろう。しかし、思い入れのあるエピソードが削除された抜け殻のような映画は、原作を読んだ人には物足りない。
特に最新の映画をDVDで見ると、集中してみなかったせいもあるが、ストーリーが全くわからないかった。原作を読んでいてさえ、話の流れについていけない。２時間に収めるためのやむをえない編集だと思うが、失敗作だと思う。どんなにSFXがすばらしくても、それだけで映画が成立するわけではない。ストーリーのない映画は、そもそも作品として成立しない。
少し残念な気がしたので、あくまで個人的な感想として記録をつけておく。
時間のあるときに集中して見直せば、面白いのかもしれない。とフォローしておく。

駅宅

駅中が活発だ。
駅中とは、駅の中のショッピングモールだ。飲食系が中心だが、今後はファッション系も登場するだろう。
駅の再開発というと、駅前の開発を意味することが多いが、土地取得などの問題でなかなか思うように進まない。そこで、JRが積極的に行っているのが、駅の中を開発してしまうという駅中だ。
駅中が進むと客は駅から出ないため駅周辺の商店街には大打撃だろう。それがいやなら駅前開発に協力しろというメッセージも含まれているかもしれない。

前置きが長くなったが、今回取り上げたいのは駅中ならぬ駅宅だ。駅宅は勝手に作った造語だ。２つの意味をこめている。１つは駅の宅配、もう１つは駅の託児所だ。
宅配を受け取る場所は、自宅、コンビニ、郵便局しかなかった。自宅は日中留守だと受け取れず、コンビニは通り道でないこともある。郵便局はもっと遠いかもしれない。
そこで、必ず通勤に使う最寄り駅で荷物を受け取るオプションがあってもよいと思う。これがよいのは鉄道輸送できるため、トラックを全く使う必要がないことだ。環境にやさしい宅配だ。Amazonのような書籍中心の宅配なら出勤前に受け取り、通勤中に読むこともできる。
もう１つは託児所だ。女性の社会進出（むしろ社会復帰というべきかもしれない）はいまや必要条件になっている。その社会進出を阻む壁が育児だ。育児期間は出産期間よりはるかに長い。育児を支援しなければ社会進出は進まない。駅は理想的な託児所となる。もともと乳幼児は無料なので駅の中に入ってもよい。駅の外に入り口があってももちろんよい。企業ごとに託児所を設けるより、駅に共同で設置するほうが安い。駅ビルには結構スペースがある。
駅の機能は工夫次第で様々に発展する。

2008年1月28日月曜日

Eclipseの問題点

EclipseはOSSの標準IDEといってよいだろう。
JavaだけならNetBeansも考慮の対象となるが、C/C++も含めると他に選択肢はない。
Windowsアプリ開発なら有料のVisual Studioがよい。しかし、WebアプリやLinuxまで含めると他に選択肢はない。
つまりソフト開発でEclipseを無視することはできない。
しかし、Eclipseにも問題点がある。
１つは独特のUIだ。パースペクティブに慣れる必要がある。しかし、それはまだよい。
２つめはインストール方法だ。雑誌やWebの紹介記事ではいとも簡単にインストールしているが、これは初回だけだ。まず、日本語化、そして数多くの非標準モジュールを追加しなければ実用的な環境にならない。
最近ではAll-In-One-Eclipseが配布され、容易になってきたとはいえ、すべてのモジュールをプリインストールしているわけではない。
このインストールを初心者にさせるのはかなり厳しい。
初心者は限られたモジュールしか使わない、などというのは過去の話だ。今は初心者もいきなりプロなみのプログラムを書く。
初心者はコマンドラインからという考えの人もいる。どちらがよいかは主観と時間の問題だ。
Eclipseのモジュール管理は、ほとんど管理されていないといってよい状態だ。Eclipseプロジェクトのものは、一応整合性は取れているが、サードパーティのものはアドレスもまちまちだ。EclipseにもCPANのようなサイトが必要だ。
CPANがベストというわけではないが、少なくとも何もないよりよいだろう。

電子ペーパーによる外装

電子ペーパー搭載の携帯が発表された。
普通なら文字表示を電子ペーパーで行うところだが、日本のようにワンセグなど高度な動画表示が要求される市場に適さない。
そこで、電子的に変わる外装として電子ペーパーを使ったようだ。
そこまで外装にこだわる気持ちは正直理解できないが、希望する消費者がいるのだろう。
ならば将来的には、平面的な外装だけでなく、局面的な外装も電子ペーパーで実現するようにする（なる）だろう。
電子ペーパーは元来折り曲げに強い。
それに強度を本体で補うように曲面的に加工すればうまく実現できるように思える。

VIA Isaiah

VIA Isaiahは刺激的なプロセッサだ。
ホワイトペーパーによると1Vで2.2GHz動作が可能であるという。
これこそイノベーションといえるだろう。
x86互換CPUがいよいよPDA市場に進出するかもしれない。
携帯を毎日充電するなら、このままでも十分いけるだろう。
携帯でVistaが動くという日が数年内にくるかもしれない。
ただし、それまでVistaが生き残っていればの話だ。:-)

Internet Archive

Internet Archiveに過去のホームページのほとんどが記録されている。
このような試みは大変有意義で、これを活用すると貴重な知見が得られると期待している。
しかし、問題はクローリング能力だ。クロールできずに未収録となったホームページも多いと思う。
この問題は今ならRSS、少し前なら分散検索などで改善できる。
ちなみに、学科のホームページを検索したら1997-5-1が最古であった。しかし、実際には1994年にはサーバを立ち上げているので、プロジェクトの始動が1996年からであったとしても大規模なクローリングに１年近くを要していることがわかる。

2008年1月26日土曜日

Googleブックマークのその後

数日前にGoogleブックマークが消えたという記事を書いた。
その後、データが復活した。
どうやら接続状態がかなり悪いようだ。
しかし、問題なのは、未接続の間？（正確には登録できたので未接続というわけではない、未認識というべきか）登録したデータが、旧データが復活した際に消えたということだ。
あわてて修復しようとするとかえってひどい目にあうということらしい。
一応復活したのでGoogleブックマークを使っているが、もう信頼はしていない。
面倒でもdel.icio.usにバックアップするようにしている。

マクドナルドのコーヒー

オリコンによると、マクドナルドのコーヒーが、買いたいコーヒーのNo.1に選ばれたそうだ。
個人的には信じがたい話だ。
値段が安いだけの理由だと思っていたら、あの薄いアメリカンコーヒーがスターバックスとほとんど変わらない味だからだという。その感覚が信じがたい。
100円でも飲みたくないランキングならわかるが、どうして同列に並べることができるのだろう。
いったいどんな調査をしたのか不思議でならない。
マクドナルドのコーヒーではなくマックカフェのコーヒーならまだ理解できる。
それとも知らない間にマクドナルドのコーヒーは進歩したのだろうか？
ぜひ確かめてみたい。

2008年1月25日金曜日

子供の目が悪くならないTV

TVの大画面化が進む中で、薄さや大きさばかりが問題となっている。
目に優しいこと、健康的であることは、単なるカタログスペック以上に重要なことだと思う。
このようなアプローチのTVは開発されていないのだろうか？
開発されていても宣伝では薄さや大きさばかり問題にするのだろうか？
そこで、少し考えてみた。
視力が悪くなる原因は、（確信はないが）おそらく２次元的に表示されているためだろう。
いくら画面を大きくしても目の焦点距離はだませない。遠くのものを遠くにあるように見せる3D化が必要だ。3D化については多くの研究事例があり、遠くない将来実用化されると確信している。しかし、目に優しいかどうかは技術の成熟を待つ必要があるだろう。
また、現実の大きさに忠実であることも重要だと思う。解像度が同じままで画面を大きくしたら荒い画面になってしまう。
このとき、仮想的な距離と実際の距離を自動的に同期する仕組みが必要になる。デザイン分野ではディスプレイやプリンタの色の再現性が異なることが問題となり、ColorSyncなどの技術が誕生した。同じように距離を同期する仕組みの開発が必要だ。

コンビニでカフェ

都心のコンビニと郊外のコンビニでは戦略を変える必要がある。
客の多い都心では回転を早める。しかし、客の少ない郊外では客単価を高める。
郊外のコンビニに客は車で来る。そのため広い駐車場がある。ときどき広すぎる駐車場を作っていることがある。
その駐車場の一部をオープンカフェにしたらどうか。
コンビニには各社のコーヒーが豊富にある。コーヒー専門店ではないが、飲食可能なコンビニは少なくないので、同様の戦略を採用すればよい。
売り物を消費できる場を提供することで、次々消費してもらう。車の中で食べるのは味気ない。
カフェの雰囲気を売ることが重要だ。
別の視点から議論してみよう。
カフェがコンビニになったらどうだろう。例えば、スターバックスは今やどの駅にもあるといってよいほど普及している。スターバックスのない場所は珍しい。もし、スターバックスが食料以外を販売し始め、しかも営業時間を拡大したら、コンビニと衝突するかもしれない。
ならば、弱点を突かれる前に攻める必要がある。

Googleブックマークが使えない

Googleブックマークを使っているが、トラブルが続いている。
時々、ブックマークが消えてしまう。
集めたブックマークが消えるのは非常に困る。
このようなトラブルが2度あった。
最初は、Googleノートブックにブックマークの内容が移動し、その後消えてしまった。
次は、GMarksから消えた。普通は更新すれば元に戻るが、このときはきれいさっぱり消えてしまった。ただし、これはGMarksが原因ではないかもしれない。最近OperaやSafariなど様々なブラウザからアクセスしているためかもしれない。
いずれにせよGoogleブックマークには根本的なバグがあるように思える。
データが消えるサービスなど論外だ。Googleブックマークよりdel.icio.usの方が安定している。
del.icio.usが日本語化されればよいが、そうでなければはてなも試して見なければならないだろう。

2008年1月23日水曜日

海という悲劇の共有地

共有地の悲劇というものがある。
共有地に好き勝手に放牧させるとただでえさを与えることができる。自分の懐が痛まないので土地を回復させようとしない。その結果、草が生えない砂漠のような土地になってしまう。
ただ乗りを戒める話だ。
海は世界の共有地だ。そこに悲劇が生まれる。
海にゴミを投棄したり、漁業資源を乱獲したりする。

グローバル通信の無駄

現在、多くのデータセンターはアメリカにある。広い土地と安定した電力源があるからだ。
データセンターはアメリカ人だけが使うものではない。企業の所有物なので、どこに作ろうと企業の勝手だが、企業とてコストを考えなければならない。
データセンターは世界中から使われる。通信はただではない。金額ではなくエネルギーが問題だ。
エネルギーを最小化するようにデータセンターを配置するなら消費地に近い方がよい。
最大の消費地はアジアだ。中国とインドだけで世界人口の1/4を占める。経済力も間違いなく増加する。いずれもアメリカを抜くのは間違いない。ただし、アメリカも移民などで先進国では珍しく人口が増加している国なので、アメリカの人口増によっては優位が続く可能性もないではない。
日本がアメリカに及ばなかった原因の１つは人口だ。人間の生産性などそれほど差はない。せいぜい２倍だ。中国、インドにはアメリカの２倍以上の人口がある。
以上のことからデータセンターはアジア、特に中国ないしインドにあった方がよい。どちらかといえば、政治の民主化度、人口の増加率を考慮するとインドだろう。
しかし、今すぐインドにデータセンターを移す必要はないし、またできない。なぜなら、電力源が安定していないからだ。
インドが原子力（インドは核保有国だ）、自然エネルギーを組み合わせて、安定した電力供給を実現すれば、一挙にデータセンターの移動が起きるかもしれない。

宝くじを当てるアルゴリズム

人間はだまされたくてだまされるのかもしれない。あるいは、だまそうという人が後を立たないのは、容易にだまされてしまうからかもしれない。
いまだに宝くじを当てるアルゴリズムを作る人がいる。
宝くじは完全な乱数なのでいかなるアルゴリズムも的中させる確率は等しい。よく考えたアルゴリズムでも、ないも考えてないアルゴリズムでも結果は同じだ。アルゴリズムの問題ではない。
冗談でなく開発費を使って開発しているなら、それは詐欺のようなものだ。正規の教育を受けたプログラマーなら、それが不可能であることを承知しているはずだ。にもかかわらず無駄な努力をしているなら、金をもらって何もしない、つまり詐欺と同じだ。もっとも、その無駄を何らかの娯楽に転化しているなら、わからないでもない。娯楽はそもそも無駄なものだ。
なお、完全な乱数といえないギャンブルもある。生物の個体差が影響するもの、集団の意思が影響するものなどだ。後者の代表は株だ。

2008年1月22日火曜日

コンビニの機会損失

コンビニを利用していると欲しいものがないことが多い。
また、ユニバーサルサービスを謳いながら店によって品揃えが違う。
これは誰もが一度は経験していることだろう。
これは機会損失だ。ビジネスチャンスを失い、本来得られるはずの利益を失っている。
コンビニという狭い店舗における商品は限られている。その中で最大公約数的な品揃えをしている。利益を最大化するには最適化を最大にする必要がある。
顧客の全体集団に対して品揃えを用意するのは過去の戦略だ。
現在では、今の顧客に対して品揃えを用意する必要がある。つまり、時間軸に沿って商品を動的に配置する必要がある。
そのためのは顧客の振る舞いや動向を把握する必要がある。
そして、そのためには個人を特定する必要がある。
このためにポイントカードを利用できる。ポイントは負債になる。だから価格に転嫁する。
ポイントカードは客より店のほうにずっと大きな意義がある。
客にメリットがあるのは電子マネーなどだ。nanacoがその典型だろう。現金を扱う必要がなく、信頼性が向上し、決済がスピーディになる。
その上で、顧客の購買パターンを予測し、それに合わせた商品を入荷する。購買パターンから顧客の心理分析を行い、行動を予測する。
そこまでしないと利益を最大化することはできない。

SaaS型プリンタ

プリンタをSaaSにしよう。
例えば、自分のプリンタをサイトに登録する。
そして、そのサイトからのリクエストしか受け付けない形でインターネットに接続する。
後は、サイトがIPPを受理して、自分のプリンタに印刷する。
わざわざインターネットを経由するのは、そのほうが自由度が高いからだ。プリンタスプールもいらない。

ドライバレス・プリンタ

プリンタはドライバのインストールが面倒だ。
自分のプリンタならあらかじめドライバをインストールしておけばよいだろう。
しかし、出張や故障など自分以外のプリンタを使わなければならないときもある。
そのようなときドライバのインストールは面倒だし、不可能なことがある。
それでも使えるプリンタが欲しい。
ドライバレスか、あるいはドライバ内蔵のプリンタだ。
前者は標準ドライバで使えるプリンタであり、後者はサーバ機能を内蔵したネットワークプリンタだ。
現実には、後者の方がよいかもしれない。無線LANに対応し、全自動でプリントサーバとなり、使いたいときにドライバをインストールできる。
そんなプリンタが欲しい。

Javaの弱点

Javaの弱点の１つは間違いなくサーバサイドの機能不足だ。
サーバサイドJavaはJavaの売りの１つだが、その機能は決定的に不足している。
具体的には、JavaというよりTomcatの機能不足が原因だ。
Tomcatはコンテンツをユーザごとに分割管理できない。そのため共用レンタルサーバでJavaを運用できない。
有用なJavaのWebアプリケーションは多いが、そのほとんどが使われることがない。もったいない話だ。
Tomcatはサーブレットコンテナであり、１つのJVMで動作する。あるサーブレットが全体を停止させることができる。これは一種の脆弱性だ。
しかし、サーブレットごとにJVMを起動していたら、悲惨なほど遅くなる。
Tomcatは抜本的に考え直す必要がある。きちんとしたサンドボックスを提供するべきだ。

2008年1月20日日曜日

電気代の従量制を見直す

一般的な家庭では電気代を重量電灯で契約しているだろう。
これが現代の電気化された世の中に合わなくなっていると感じる。
CO2削減のために、あるいは石油資源の節約のために、石油製品から電気製品に切り替える家庭は多いだろう。特にガソリン、灯油の値上げが決定的だと思う。
すると電気の使用量は増えるのだが、これは悪いことではない。なぜなら、石油自体の消費は減っているからだ。
発電方法は多様化しているので、電気を使ったほうが、直接灯油を燃やすよりCO2は少なくなる。
しかし、重量電灯のために電気代は高くなる。もっとも灯油よりは安いかもしれない。
電気代を高くしているということは、CO2の削減に貢献できる可能性を摘むものだ。
具体的には従量制の３段階の上限を引き上げるなどが考えられる。
電力会社は電気代のメニューを工夫しているが、十分ではない。いずれも発電量のバランスをとるための方策であり、あるべき社会の姿を反映するものではない。

Googleグループのすすめ

GoogleグループはGoogleによるメーリングリスト（＋α）だ。
通常のメーリングリストの他にUsenet(NetNews)を管理することができる。
もっとも普通のユーザはUsenetに関心はないだろう。
自分でもいくつかのGoogleグループを作成し、メーリングリストを管理している。
Googleグループのうれしいところはメーリングリストのアーカイブを残せることだ。
アーカイブを閲覧するにはGoogleアカウントが必要だ。
そうでなければ通常のメーリングリストとして使う。
グループに登録するには[グループ名]-subscribe@googlegroups.com宛てに送信するだけだ。
また、グループを別のユーザに受け渡すこともできる。所有者を切り替えることで受け渡せる。
Googleグループには多くの機能があり、実はまだ使いこなせていない。
特に、いくつかのグループではディスカッションにサブセクションを設けているが、この方法がよく分からない。

2008年1月18日金曜日

プログラミング言語の人気ランキング

プログラミング言語を評価するのは難しい。
記述可能な問題で評価したり、問題を簡素に表現できることで評価したり様々だ。これらの評価は計算機科学的な評価だが、社会的な評価もある。どれだけ利用されているか、どれだけ受け入れられているかだ。
TIOBEはプログラミング言語の人気をランキングしている。代表的なサーチエンジンの検索結果で順位付けしているらしい。
ランキングは順当に思える。Javaも次第に評判を落としているようだが、しかし活発な開発が続いている。開発が続く間は人気が高いだろう。
興味深いのでブックマークしておく。

[1] TIOBE http://www.tiobe.com/index.htm?tiobe_index

OpenIDの時代

OpenIDの普及が進んでいる。
Yahoo!がOpenIDに対応した。
これは大きな波及効果を持つだろう。
ただし、勘違いする人もいるかもしれないが、これによってYahoo!のアカウントがあればGoogleが使えるようになるというわけではない。また、OpenIDさえあればYahoo!のサービスを使えるというわけでもない。
例えば、OpenIDに対応したブログがあり、それにコメントする際、Yahoo!のアカウントを持つ人が投稿できるようになる（かもしれない）。それを許すかどうかは、それぞれのサービス提供者に依存する。
Yahoo!自身、ユーザの身元を保証しているわけではないので、これでspamがなくなるというわけではない。
それでも、OpenIDには大いに期待している。

コンビニで少子化対策

少子化対策は子育て対策でもある。
日本の各地にあるコンビニが子育てを支援してくれれば心強い。
乳児を連れて外出すると困ることがいくつもある。
例えば、オムツ換えの場所がない。コンビニのトイレにオムツ換えシートを備えてくれればありがたい。ついでにオムツをばら売りしてくれればさらにありがたい。
また、粉ミルクは小分けにして持参できるが、適温のお湯が入手できない。コンビニで調合できればありがたい。コンビニも商売なので粉ミルクのスティックを販売し、購入した客に対してミルク用温度に保温したお湯を使わせてくれるというのはどうだろう。
これだけで育児中の母親の行動範囲はかなり広がる。
また、最近では駅中が人気だ。電車で移動する場合、コンビニに頼ることはできない。主要な駅に同様の設備を用意してもらえるとありがたい。トイレはともかく、ミルクは自動販売機を作れないものだろうか？ミルクメーカーが協力し合えばできるのではないだろうか？

$200 PC続々

$200のPCが次々と発売されている。
Eee PCもそうだが、デスクトップPCにもある。
これらのPCは性能はそれほど期待できないが、シンクライアントの代わりには十分なる。
とすれば、5万で販売しているシンクライアントのほとんどは高すぎるということだ。

2008年1月17日木曜日

次世代シンクライアント２：　USB仮想端末

最近ではUSB接続マルチディスプレイアダプタの登場により、USBでディスプレイを拡張できるようになった。
USBでディスプレイを拡張する製品にはSyncMasterがあるが、これらのアダプタを使えば通常のモニタを接続できる。例えば、「サインはVGA」の場合、1台のPCに3台まで接続できる。また、「USB-RGB」の場合、ドライバをインストールすることで1台のPCに6台まで接続できる。
そして、キーボードやマウスもUSBで接続できるのは周知の事実だ。
これらのことから、USBで6台までの仮想端末が構成できることになる。
しかし、現在のシステムでは連続した画面になってしまう。それをあえて独立した画面にし、複数のデスクトップを実現する仮想化ソフトを開発すれば、1台のPCが極めて安価に7台のPCに化ける。
これでシンクライアントを実現すると、1台のコストは1万程度になる。前の記事で（ディスクプレイ、キーボードなしの）シンクライアントが5万と見積もったのと比較すると1/5だ。仮想化の度合いは同じなので性能劣化も等しい。
これこそ今考えられる究極のシンクライアントだ。
このようなソフトはぜひ開発するべきだ。今はまだない（と思う）。両製品のメーカーが開発してくれればありがたい。
問題の１つはディスプレイとキーボード、マウスの組をいかに設定するかだ。USBハブで1組に認識されればうれしい。

次世代シンクライアント１：　仮想化ネットブート・シンクライアント

シンクライアントは内部統制の御旗の元に勢いづいている。
シンクライアントには様々な実現方法があるが、コストを優先すればネットブート方式がよい。
ネットブート方式は基本的にサーバを使わない。それ以外の方式はシンクライアントの他にサーバを必要とする。サーバを仮想化することで利用率を高めることができるが、サーバをなくすことはできない。
ネットブートのクライアントは必ずしもシンではない。HDDを使わないファットクライアントのこともある。しかたがって、ネットブート・シンクライアントはシンクライアントより高い。しかし、サーバ＋シンクライアントより安い。
一般的に、シンクライアントは5万、ファットクライアントあるいはサーバは20万と考えてよいだろう。サーバの見積もりが小さすぎるかもしれない。しかし、サーバとっても安いものもある。
シンクライアントだけでシステムを構成できるなら理想だが、それは不可能だ。
よって、コストの優劣は以下の順になる。
1) ファットクライアント（ネットブート）
2) シンクライアント＋仮想サーバ
3) シンクライアント＋サーバ
性能を犠牲にすれば1),2)は逆転する可能性もある。
クライアントの台数をC、サーバの台数をS、仮想化の多重化率をn=C/Sとすると、
1) 20C
2) 5C + 20C/n
3) 5C + 20C
となる。20C = 5C + 20C/nとすると、15C = 20C/n、ゆえにn=4/3となる。この比率で逆転する。n=2なら、2)の方が有利になる。この場合、性能は1/nになる。
性能を犠牲にしてよいなら、ネットブート方式をさらにコストダウンできる。それが提案する仮想化ネットブート・シンクライアントだ。ネットブートするファットクライアントの上で仮想マシンを動かし、その下に複数のシンクライアントをぶら下げる。
そのコストは簡単に表記すると以下のようになる。
0) 5(1-1/n)C + 20C/n
別の見方をすれば、サーバ室からサーバを追い出し、クライアントとして動作させるようにしたと考えることができる。
コスト的な優位性はダントツなので、今後このようなシステムが登場してくる可能性は大いにある。

au W05K

W05Kはauの定額データ通信カードだ。
どこでもPCを使うために購入した。
auにはフルサポートとシンプルの料金体系がある。
普通は割引の多いフルサポートを選択するところかもしれないが、今回はシンプルを選択した。
実はあまり長く使うつもりがない。
定額データ通信にはemobileもある。emobileの方が安いし速いが、通信地域が狭い。しかし、言い換えれば地域を限定すれば安くつかえるということだ。
つまり普段は安い方を使い、必要なとき（おそらく出張のとき）だけauを使う。使わないときは契約を解除する。
このような使い方は一般的でないかもしれないし、また面倒なだけかもしれない。しかし、試すにはちょうどよい。そのためにはシンプルの方がよい。
インストールの印象を伝えよう。
インストールは面倒だ。emobileがゼロインストールなのに比べると雲泥の差がある。初心者にはとても推奨できない。
こういうとW05Kが悪いようだが、持ち上げているemobileではなくW05Kを購入したことからしても、現在のところ唯一ともいえる定額モバイルの解だ。

Emobile - Phone + WiFi = PDA

Emobileの携帯（というよりPDA？）は非常によさそうだ。
iPhoneよりemobileが欲しい。iPod touchで懲りたので、iPhoneはいらない。
しかし、emobileは携帯としては地域が狭い。どうしても見劣りする。
emobileもせっかくの機種を売ることができない。
そこで、通信機能を削除し、WiFiをつけてはどうかと思う。
WiFiはmini SDカードでもよい。
通信機能なしで携帯を売ることに意味がある。emoileはそれで資金を得て、通信範囲を広げればよい。また、WiFiだけで十分な利用者は安く利用できる。
月額基本料なしの従量制で、両方の通信をその都度選択できれば理想的だ。

2008年1月16日水曜日

EC2でテストベッドを

最近では研究のため大規模なテストベッドを構築する動きが多い。
テストベッドを持つとシミュレーションではなく実機で評価を行える。実装は困難だが、問題点の発見が早くなり、競争相手より有利な立場に立てる。
実機というが一部に仮想化技術が使われる。問題ごとに実機を用意するわけにはいかないので共用する。問題による差を仮想化で隠ぺいする。実機そのものほど正確ではないが、シミュレーションより多くの事実がわかる。
このように現在の大掛かりな研究では、３つのステップを踏む。
1. シミュレーション
2. テストベッド
3. 実機
EC2はテストベッドに適している。予算が許せばいくらでも大規模のテストベッドを構築することができる。料金はHWより安い。使った分しかかからない。
EC2内の通信は無料なので経済的にネットワークを構築することができる。セキュリティの問題もほとんどない。
同種のサービスにPlanetLabなどがあるが、それより容易だ。
大規模なテストベッドをその都度構築するのは面倒なので、それを支援するツールが必要だ。
インスタンスイメージは共通とし、S3に格納すればよい。共通なので台数に依存しない。研究用なら十分5GBに収まるだろう。収まらなければ専用ノードを常時稼働させ、イメージを転送してもよい。
差分をデプロイするツールは必要だ。基本的にはFTPまたはHTTPでよい。スレーブノードが自発的にマスターノードからダウンロードすればよい。

均一化する世界

「フラット化する世界」が注目されている。
フラット化はグローバル化によって進行している。
グローバル化は均一化の側面を強く持っている。
すると行き着く先は「均一化した世界」であろう。
しかし、世界には均一化を阻む要因が数多く存在する。土地、気候、文化などだ。
これらの要因は川に沈む岩のようだ。大きな抵抗ではあるが、いずれは川によって侵食される。川の力の根源は欲だ。これは人間の根幹でもある。
しかし、世界をみれば川は一部でしかない。我々は多様性に囲まれている。川がすべてを侵食しない理由は、格差だろう。水は低きに流れる。
世界にも格差があるが、日本にも格差がある。世界の格差は均一化しつつあるが、国内の格差は拡大しつつある。いずれ世界の格差が均一化すれば国内の格差の方が大きくなる。
格差は人が作り出す。経済では人が法則だ。
温暖化の例を出しても人は自然を凌駕することがある。自然の偉大さに畏敬の念をいだく敬謙さと同時に自らの力を過小評価することなく自然に対するいたわりを持つ必要がある。
内部格差が増大し、外部格差を超えると、それを埋める流れが生じる。しかし、それまでは生じない。
ここで問題となるのは、外部格差と内部格差の時間差もさることながら、内部に格差が残るかどうかだ。格差がなければ、格差は埋まらない。全員貧乏では格差を埋めるお金がない。
よって企業の国際競争力を維持することは極めて重要だ。国内に世界に誇れる山を作る必要がある。今は自動車や半導体だ。これらの山を高く維持する必要がある。同時に新しい山を作り出す必要がある。

Language benchmark

どのプログラミング言語がよいのか迷うことがある。
ライブラリなど使いたい機能があれば迷わないが、どれでもよいときには迷う。好きに決めればよいが、少なくとも明確な理由がない。
機能に差がないときの１つの基準は性能だ。
マシンの性能を測るにはベンチマークテストを行う。同様に言語の性能を測るためのベンチマークが必要だ。
ベンチマークがなければ同じ基準で比較できない。
しかし、ベンチマークがあってもアルゴリズムが異なったり、実装が異なると正確な評価が難しい。特にアルゴリズムに差があると公平ではない。一般的に実装の差は定数的に影響するが、アルゴリズムの差はオーダーの違いとなる。

無給水加湿のエアコン

ダイキンのエアコンは無給水加湿だそうだ。
これならやっかいな水の交換（給水）もなく、むやみに温度をあげる必要もない。
省エネ効果がどの程度のものかわからないが、買い替えのときにはチェックしたいと思っている。
次世代エアコンの決め手は湿度管理だと考えていた。しかし、給水をどうすればよいのか疑問だった。そして半分あきらめていた。無給水加湿まで到達するとはさすがに専門家は違う。
これで掃除機能も標準装備なら買い替えの最有力候補になる。

250GB SSD

2008年度に各社から250GBのSSDが発売するらしい。おそらく当初はとんでもなく高い値段だろう。しかし、2～3年のうちに普及価格へ落ち着くものと考えられている。
そうなるとHDDは安さか大容量かのいずれかを選択しなければならない。それ以外の機能はSSDの方が上だ。安さでは収益が得られないので、主なメーカーは大容量化を促進するはずだ。
おそらくHDDはTBを単位とするようになる。SDDが数年内にTBへ移行するのに対抗して、HDDは常にSSDに対して10～100倍の容量比を維持しなければならない。
また、長期的に見るとHDDの技術革新よりSSDの技術革新の方が速く、いずれは追いつかれる。よって、いつHDDに見切りをつけるかが重要だ。HDDにはまだ市場があるので、今すぐやめるのは早計だろう。しかし、容量比が10を切ったら直ちに見切りをつけたほうがよいだろう。

Spicebirdに期待

OSSの情報を発信してくれるMOONGIFTでSpicebirdというソフトがあることを知った。
このブログではGoogle版Outlookが必要だという意見を主張している。
Google製ではないがGoogle指向の強いThunderbirdをOutlookに仕立ててくれるソフトがSpicebirdだ。
まだ、英語版だけのようなので使ってはいないが、少し期待して様子を見ている。

次世代DVDとMacBook Air

BD(Blu-ray Disc;なんてわかりにくい名前だろう)とHD DVDの競争はBDの勝利に傾きつつある。
そのような中でAppleから「DVDは不要」というメッセージが発信されたのはなんとも皮肉な話だ。
日本企業がDVDという従来技術でしのぎを削っている間に、アメリカ企業はそれを不要にするイノベーションを起こす。過去に何度となく現れた構図が今回も再現されようとしている。
もっともDVDはなくならない。TVがなくならないのと同様だ。だからDVDに力を入れてもかまわない。しかし、その市場はかつてほど大きくないということを理解する必要がある。無理な商売ができなくなっているということだ。
また、ユーザを見ないで著作権者ばかり見ていると売れない商品になる。
ノートPCにDVDが不要かどうかといえば、私の意見では「ほとんど不要」だ。その「ほとんど」がかなり微妙だ。
いつもはなくても困らない。所有のDVDデータはサーバにコピーしておけばよい。しかし、まれに出張先でDVDの資料が配布されることがあり、それを見る必要がある。そのような機会はある程度限られるので外部接続のDVDを持ち運べばよいのだが、荷物は増やしたくない。また、忘れると困る。そのような理由で常にDVD付きのPCを購入している。しかし、割り切れれば確かに不要ともいえる。
また、DVDは使い勝手の悪いメディアだ。1GBのフラッシュメモリが100円くらいになればCDは完全に不要となる。さらに4GBのフラッシュメモリが安くなればDVDも不要になる。しかし、次世代DVDにはなかなか勝てない。当面、大容量光ディスクとフラッシュメモリの競争が続くだろう。しかし、安いメディアは次第にフラッシュに侵食される。それもやがてはネットワークとサーバに飲み込まれる。サーバ側では磁気ディスクとフラッシュメモリしか使われない。
こう考えるとDVDの将来は決して安泰ではない。
東芝はHD DVDを見切り、フラッシュメモリの低価格化に方針転換したほうがよい。松下から社名を変更するPanasonicがSDに力を入れているが、東芝こそSDに集中したほうがよい。

EC2の用途

Amazon EC2には向き不向きがある。
以前、PC教室を構成する試算を行った。しかし、通信が多量に発生するPC教室は本来EC2に適していない。
一番、EC2に向いているのはGridだろう。特にComputational Gridだ。
EC2でサーバを運用するにはいくつかの問題がある。まず、マシンを停止するとデータが消去されてしまうことだ。したがって、この前のPC教室の運用プランのように毎日起動停止を行うならS3にバックアップする必要がある。その費用も本来は計上しておかなければならない。しかし、PC教室の場合は、ある程度の初期設定は必要だが、基本的に初期化されてもよい。そこがWebサーバとは異なる。
WebサーバをEC2で運用するのは推奨できない。特にトラフィックが増えるほどサーバ運営側に負担が大きくなる。Webサーバはそれ用のレンタルサーバを使ったほうがよい。

2008年1月14日月曜日

iGoogleでタブの並べ替え

iGoogleを使っているが、一度使ったタブの並べ替えをどうすればよいのかわからない。
Googleドキュメントのときのように、できるのにできないと思い込んでるのかもしれないが、いまのところ方法が分からない。
できないなら問題だと思う。

OUPC

OLPC(One Laptop Per Child)が難航しそうだ。
WindowsでなくLinux、しかも独特のインターフェースが問題らしい。
OLPCでは、安くPCを作成することで子供たちにPCを配布しようとする。
しかし、よく考えれば世の中には無料のPCがたくさんある。
例えば、中古品(Used)だ。中古＝無料ではないが、減却済みの中古は無料としてもよい。企業にはそのようなPCがたくさんある。
現在、それらの中古PCはリサイクルされ、資源的に再利用される。それはとても重要なことだが、CSRの一環としてPCを寄付してもよいだろう。
日本の学校のPCも古い物が多い。それらはLinuxでリユーズされようとしている。途上国の支援も必要だが、自国の支援もまだまだ必要だ。
OLPCとは別の目的で、別の方法で、子供たちにPCを与える事業があってもよい。
中古PCを使うなら、さしずめOUPC(One Used Per Child)ということになるのだろう。

Office Cloud

少し前にPC教室をEC2上に実現できるかもしれないという話をした。
同じくオフィスをCloud上に実現できるかもしれない。
ただし、こちらの場合はPC教室より導入理由が明確だ。
価格の問題というより安全性の問題だ。
しかし、影響範囲がより広い。
すべてのアプリケーションをCloud上で実行するという形式ではなく、事業継続のために必要な機能のみをCloud上に実現する。つまり、社内にはシンクライアントが残るだろう。
現在、ほとんどのアプリケーションがWebブラウザで利用できる。その傾向が今後も進行すればオフィスがCloud化する未来は現実化するかもしれない。

2008年1月13日日曜日

Googleドキュメントの階層フォルダ

Googleドキュメントを使っているが、使いこなしていないことが分かった。
フォルダ＝タグだと考えていたので、階層構成ができないと思っていた。
しかし、実際にはフォルダを選択した状態で、フォルダを作成するとサブフォルダになる。
これでかなり便利に使えるようになる。
以前、Googleドキュメントはワープロではないと述べたが、それは依然として変わらない。
しかし、実際にはワープロのZohoよりGoogleドキュメントの方をよく使う。
用途に対して機能が十分なら使いやすいほうがよいということだろう。

2008年1月12日土曜日

EC2とシンクライアントで作るPC教室

学校のPC教室では、PCの管理がいつも問題になる。
いっそのことPCなどなくしてしまうことを検討してみたい。
どうすればよいかというと、シンクライアントとEC2を組み合わせる。
アプリケーションはEC2で実行し、画面をシンクライアントで表示する。
インターネット経由で距離が問題かもしれないが、仮想マシン方式のシンクライアントと基本的には変わらない。
性能面は実際に試すまでわからないが、ここでは予算について検討しておく。
予算的に割高なら、それ以上検討しても無駄だ。
EC2の価格は1台あたり$0.10/hだ。ただし、データ転送代金を含まない。
仮に500台のPCを毎日12時間、利用率50%で利用するとする。
休業期間中は無視できるものとし、年間8ヶ月(8*30=240日)使用するものとする。
すると、500*$0.10*12*0.50*240=$72000になる。$1:120円とすると864万円となる。
これは1台のPCを年間2万円で使えるというわけだから、驚異的な安さといえる。
おまけに、共用を許すなら1/2～1/10ぐらいにコストダウンできる。
しかし、問題はこれからだ。これで済むならとっくに誰かが行っている。
上記の計算にはデータ転送代金が含まれていない。
通信料はアップロードが$0.10/GB、ダウンロードが$0.18/GB(<10TB)だ。
シンクライアントではダウンロードが相当多いはずだ。
仮に1MbpsのADSLで十分だとすれば、月間通信量は0.001/8*60*12*0.5*30=81GBだ。500台でも40TBを超えるので$0.16/GBが適用される。
年間通信料は500*81*$0.16*8=$51840、約620万円になる。これはクライアントなので台数を削減できない。これは1台のPCを年間1万円で使えるというわけだ。
しかし、これに500台のシンクライアントが加わることを忘れてはいけない。
実際には、シンクライアント＋ディスプレイが加わる。両方まとめて10万と仮定する。5年リースとすると年2万となる。これは少し高めの設定だ。
よって、EC2＋シンクライアントは2+1+2=5万円/年となる。
一般的なPCを約20万とすると、5年リースでは4万円/年であるから、EC2はそん色ない。しかも、管理費を含めるとEC2の方が有利かもしれない。
もっとも、この試算は通信量を低く考えすぎているかもしれない。また、EC2で使えるOSはいまのところLinuxだけなので、WindowsのPC教室にはできないかもしれない。これらが課題だろう。

AWSのアカウント作成法

Amazon Web Serviceのアカウントを作成しようとしたらエラーが出た。
何度やってもうまくいかない。
ネットで検索したら、Zipを3桁までしか受け付けないと書いてある記事を見つけた。
Zipを3桁で入力したら、無事成功した。
これはなかなか気が付かないことだ。
なので、ここにメモを残しておく。
いつか同じようなトラブルにあったとき、思い出すために。

2008年1月11日金曜日

デジカメ+Web

FlickrやPicasaに対応したデジカメが次々販売されている。
絶対に必要な機能とはいえないが、あれば便利ではある。
デジカメを使えば、どんどん写真がたまる。2GBもあっという間になくなる。特にビデオを使うと消費が早い。
現在のデジカメはまだYouTube対応が少ない。今後は増えるだろう。
しかし、Webのサービスはデータに依存する。静止画はFlickr/Picasa、動画はYouTubeでは統一性がない。
単に公開するだけなら統一されている必要はない。しかし、個人のアルバムを作るには、統一する必要がある。
デジカメの多機能化にWebが追いついていないともいえる。
統合サービス自体はマッシュアップで可能だろう。誰が統合サービスを提供するかが問題だ。デジカメメーカーがするしかないだろう。

28万円の自動車の意味

インドのタタ自動車が28万円の格安車を披露した。
日本の軽自動車と同程度の大きさで、価格は1/3だ。
この意味は決して小さくない。
人件費だけではない。同じインドでも他のメーカーは格安車を作っていない。正確には作れていない。作れるのかもしれないが、まだ作ろうともしていないし、作れてもいない。
徹底的に無駄を省いたからこそできたものだろう。
ラジオもないし、エアコンやパワーウィンドウもないそうだ。しかし、これは問題ではない。昔の日本車もそうだった。ラジオなど車になくても、ラジカセを持ち込めばよい。今ならiPodを持ち込める。気候が暖かければヒーターはいらない。涼しければエアコンもいらない。私が最初に乗った車にもエアコンはついていなかった。そんなに昔の話ではない。
エンジンだって走ることができればよい。スピードは出さない。
部品も最も大量に出回っているものを使う。特別な注文は一切しない。
デザインは特に妥協してくてもよさそうだ。
心配なのは安全性だ。これはあまり手を抜いて欲しくない。しかし、ABSやエアバッグは必須ではない。ブレーキさえ故障しなければ基本的に止まる。
細かい点をあげれば、先進国の法律をクリアしているかどうかは不明だ。しかし、基本モデルを安くし、それにオプションを追加することで各国対応を作ることができる。
やがて日本にも輸入されるようになるだろう。なにより安さは最大の武器だ。

これにはもう１つの意味があるだろう。
以前の記事で、車から運転する楽しみがなくなるとモジュール型商品になると述べた。既に格安車はモジュール型商品だ。手間をかけてチューニングするコストなどない。このような商品でも市場が満足するようになれば、日本企業は大いに苦戦するだろう。トヨタといえども倒産する日が来るかもしれない。

2008年1月9日水曜日

SSDとSDD

当初SSD(Solid State Drive)と呼ばれていたものが、最近SDD(Silicon Disk Drive)に変わってきたようだ。
私が誤解していなければ同じものだと思う。
問題は、SSDとSDDは似ているが、違う言葉なので検索しにくいということだ。
早く用語が統一されて欲しい。
今のところHDDに似たSDDが優勢だろう。

No more memory card

Sonyはいつまでメモリスティックを続けるつもりだろう。
もう完全に意味はないと思うのだが、赤字ではないのかもしれないが、確実に損をしていると思う。
SDだけでも十分すぎるほど多くの製品を提供している。miniやmicroはもっと考えてから製品化して欲しかった。
USBカードリーダは不便なので何とかして欲しい。
嘆いていてもしかたないので、すこしアイデアを出そう。
直ぐに思いつくのはアダプターだ。使わないスロットに刺しておけば埃も入りにくい。
SD関係はSDHC互換のアダプタがあればよい。
メモリスティックは長さや幅がまちまちで始末に困るが、PRO DUOアダプタがよいだろう。
大きな面積を占めるスマートメディアやCompact Flashだが、なくしても実害はなさそうだ。
念のためCompact FlashにSDアダプタがあればよい。
今度はアダプタを収納するケースも欲しくなる。

と思って調べてみたら、すでにbuffalo-kokuyoからそのような製品が出ていた。

Thinに期待

以前、Ruby on Railsの問題点について指摘した。
Mongrelの作者の記事「Rails Is A Ghetto」にも400回再起動するなどの逸話が掲載されている。
やはり、オリジナルのRailsは使えなかったのだと納得した。
しかし、MongrelやThinなど新たな「使える」Ruby版Webサーバが登場したのはうれしい。残念ながらMongrelについては今後の発展を望めそうにないが、Thinには期待している。

2008年1月7日月曜日

ポータブルSSD

40GBなどの低容量HDDが未だに販売されている。在庫処分というわけでもない。
その理由は大きさだ。今市場に出ているのは3.5インチではなく、2.5インチや1インチのHDDだ。
しかし、どれほど小型化してもSSDの小型化の方が容易なはずだ。
SSDはまだ高価なために一時的にHDDが市場を占有しているだけだ。
小型HDDもそれなりに重要かもしれないが、SSDの大容量化および小型化に注力したほうがよいだろう。
はやくポータブルSSDが普及して欲しい。

2008年1月6日日曜日

ディスプレイは厚さより幅

最近、マルチディスプレイが増えてきた。
VGA端子が１つでもUSBでディスプレイを拡張できるからだ。
そうなると、横長のディスプレイが欲しくなるし、さらに横長を超えてマルチディスプレイが欲しくなる。
マルチディスプレイの場合、幅が問題になる。横長でなくてもよい。
その幅とはフレームの幅だ。フレームの横幅をかぎりなく薄くできればよい。フレームの上下はそのままでもよい。フレームの上にはカメラをつけるスペースが必要だ。
ディスプレイは薄さを競っているが、これ以上の薄さは壁にかけない限り必要ない。すでに台座が薄さを制限している。

スーパーで初音ミク

スーパーには、魚、きのこなど商品宣伝の歌が流れている。
このような歌を初音ミクに歌わせたらどうだろう。
これは既に行われているかもしれない。
というのは先日スーパーに行ったら初音ミクによく似た声で歌が聞こえた。
ただし、初音ミクなのか同じ声優なのか他人なのか確認はしていない。

2008年1月5日土曜日

多重ループによる場合の数

ここで、講義例を披露しよう。

ここでは、一般的な問題を考える。あらゆる問題は、すべての場合から条件を満たす場合（すなわち解）を探索することによって解くことができる。場合の数には、重複順列、順列、重複組合せ、組合せなどの種類がある。これらをプログラムで表現することができれば、すべての場合を列挙することができるようになる。
例えば、4から3とる重複順列は以下のように表すことができる。


void main() {
    int a, b, c;

    for(a=1; a<=4; a=a+1) {
        for(b=1; b<=4; b=b+1) {
            for(c=1; c<=4; c=c+1) {
                printf("%d %d %d\n", a, b, c);
            }
        }
    }
}

実行結果は以下のようになる。

1 1 1
1 1 2
…
4 4 3
4 4 4

行数にして4^3=64通りである。
一般にnからrとる重複順列は1からnまでのループのr重ループとなる。場合の数はn^rである。
順列とは、重複順列から重複を省いたものである。例えば、4から3とる順列は以下のように表すことができる。


void main() {
    int a, b, c;

    for(a=1; a<=4; a=a+1) {
        for(b=1; b<=4; b=b+1) {
            if (a == b) continue;
            for(c=1; c<=4; c=c+1) {
                if (a == c || b == c) continue;
                printf("%d %d %d\n", a, b, c);
            }
        }
    }
}

ここで、8行目はaと重複するbを省いている。10行目はa、bと重複するcを省いている。内側のループほど省くためのチェックが多くなる。チェックする項目が多くなると||演算子を使うよりif文を並べたほうがわかりやすい。
実行結果は以下のようになる。

1 2 3
1 2 4
…
4 3 1
4 3 2

行数にして4!/(4-3)!=24通りである。
順列では、1 2 3と3 2 1を区別するが、組合せでは区別しない。同じ要素に対して並びを区別しない数え方が組合せである。区別しないということは一つに決まっていると考えても良い。そこで、昇順の並び順を選ぶ。昇順とは、小さいほうから大きいほうへ並べることである。つまり、a≦b≦cが成り立つ。これはb(c)のループがa(b)から始まると考えても良い。
組合せにも要素の重複を許す重複組合せと重複を許さない組合せがある。最初にプログラムが簡単な重複組合せの例を示す。
例えば、4から3とる重複組合せは以下のように表すことができる。


void main() {
    int a, b, c;

    for(a=1; a<=4; a=a+1) {
        for(b=a; b<=4; b=b+1) {
            for(c=b; c<=4; c=c+1) {
                printf("%d %d %d\n", a, b, c);
            }
        }
    }
}

重複順列のプログラムと比べて7行目と8行目のfor文の初期値が異なる。
実行結果は以下の通りである。

1 1 1
1 1 2
1 1 3
…
4 4 4

組合せは順列と同様に重複を排除すればよい。例えば、4から3とる組合せは以下のように表すことができる。


void main() {
    int a, b, c;

    for(a=1; a<=4; a=a+1) {
        for(b=a+1; b<=4; b=b+1) {
            for(c=b+1; c<=4; c=c+1) {
                printf("%d %d %d\n", a, b, c);
            }
        }
    }
}

bとaは等しくならないので、bはa+1から始めればよい。cとbも同様である。
実行結果は以下の通りである。

1 2 3
1 2 4
1 3 4
2 3 4

他社にされると困ることを自社で先にしよう

企業にとって最大のリスクはライバル企業だろう。
ライバル企業が今いなくてもいつか現れるかもしれない。
イノベーションによって今の主力商品があっという間に時代遅れになるかもしれない。
Webサービスは既存アプリケーション企業にとって脅威となる。
それに対処するには自社が先取りすることだ。それによって自社商品の真の価値が理解できる。また、新商品の方が競争力があると分かれば直ぐに切り替えることだ。
攻撃は最大の防御だ。常に先手を打つことが重要だ。
自社製品が売れなくなることを恐れて研究・開発を怠れば、そこに隙が生じる。後発企業はその隙をついて攻撃してくる。

My PC History (5) DOS/V

就職して初めて購入したマシンはPC/AT互換機、いわゆるDOS/Vマシンだ。
DOS/Vという言葉は死語かもしれないが、これには非常に大きな意味があった。
DOS/V以前の日本市場は日本語の壁に守られ、外国製パソコンの流入を阻んでいた。日本製パソコンは高価なハードウェアで日本語を表示していたのだ。
DOS/Vはソフトウェアにより日本語をグラフィックスとして表示する。CPU性能の向上により特別なハードウェアを使わなくても十分早く日本語を表示できるようになったのだ。
DOS/Vが登場したことで、日本市場にPC/ATが参入してきた。これに対して特殊なハードウェアを用いた日本製パソコンは価格的な全く対抗できなかった。ソフトが次々DOS/Vに対応する中で、その存在意義は次第に薄れていった。
近い将来PC 9801がなくなるだろうことを予想して、早めにDOS/Vを使ってみようと考え、新しいパソコンを買った。飯山電気製の互換機だった。
このパソコンで様々な実験をした。DOS/Vはもちろん、出たばかりのWindows 3.1を使い、最後は386BSDをインストールした。
386BSDはまだ未熟だったので、最後はWindows 3.1に戻った。また、シミュレーションなどに使うときにはDOS/Vで起動し、余計なプロセスにCPUパワーを奪われないようにした。このシミュレーションではメモリは問題ではなかった。
これ以降はWindows時代だ。仕事ではSunを使い、自分ではWindowsを使った。Macintoshを使った時期もあったが、未だになぜMacintoshを使う必要があるのかわからない。なぜなら使いたいソフトがないからだ。少なくともWindows 95以降、Macintoshを使う理由は何もないと思う。16ビットWindowsはハングすることで有名だったが、Windows NT以降は逆にMacintoshの方がハングすることで有名になった。ジョブスを呼び戻してiMacを出すまでAppleの低迷は続いた。

My PC History (4) PC-9801RA

大学院に進学し、いよいよPC 9801を購入した。80386のRAであった。
5インチFDDが搭載され、MS-DOSを使うことができた。
しかし、MS-DOS用のプログラミング言語は高価だったので、SMC 777のように多くのコンパイラをそろえることはできなかった。しかし、既に研究室に所属しており、その研究室では当時まだ珍しかったVAX, SunでUNIXが稼動していた。コンパイラは十分に揃っていた。自宅のパソコンでコンパイラを使う必要はなかった。
卒論でCのプログラムを作成したため、Cコンパイラだけそろえた。
80386を一言で表現すると中途半端なCPUだ。80386の原型である8086のメモリアクセス方式はセグメント方式で64KBの領域をセグメントレジスタで切り替える。セグメントレジスタは16ビットでしかも下位4ビットは0なので全体では1MBしかアクセスできない。そのためPC 9801のメモリは1MBが上限で、通常640KBだった。たかだか8ビットマシンの10倍でしかない。80386はそれを超える32ビットリニアアドレスをサポートしていたが、DOSではその機能を十分に使うことができなかった。CPU自体の責任ではないが、16ビット時代から32ビット時代に移行する過渡期であったためにPC-9801RAの性能は十分に発揮されることはなかった。
ちなみにPC UNIXとしてLinuxが有名だが、それと双璧をなすFreeBSDの原型である386BSDというOSもある。いずれも80386でUNIXを実現したものだ。つまり、OSさえまともならもっとすごいことができるマシンだった。
しかし、当時はそのようなOSSの流れはまだ湧き出たばかりで全く感じられなかった。私はMS-DOSでメモリの壁に悩まされながらプログラムを書いていた。セグメントの壁を超えるためにhuge pointerという概念が導入され、セグメント内のポインタとセグメント間のポインタを明示的に区別する必要があったのだ。
ところで、PC 9801は確かにプログラミングスキルを向上させてくれたかもしれない。しかし、どちらかといえばPC 9801のおかげというより研究室のUNIXのおかげのように思える。典型的なプログラミング作法の見本がそこにはあった。
PC 9801は勉強の道具でも合ったが、遊びの道具でもあった。私のゲーム暦は以外に浅く、市販ゲームをたくさん買ってプレイするようになったのは、アルバイトをはじめた大学院生時代からだ。それ以前は数少ないゲームを長く遊ぶか、自分で作ることを楽しんだ。自分で作っても大したゲームができるわけではないが、ゲームを作る過程がゲーム以上に楽しかった。
このとき、自分で作ったゲーム？はRPGツクールのようなゲームエンジンだ。cursesを真似てマップを２画面用意し、デュアルバッファでリアルタイムに表示する。C言語だけでも十分スムーズにスクロールできた。もっとも、よく見ると多少ぎこちない感はあったし、最終的にはイメージをVRAMに書き込むときだけマシン語を使った。
凝ったのはシナリオシステムだ。シナリオファイルにキャラクターの台詞やイベント記述するとそれで任意のゲームを表現できる。もっとも、ドット絵を作るのが面倒だったので、敵キャラを増やすところで中断してしまった。ボタンなどのGUI部品も自作し、簡単なウインドウシステムになっていた。このような特徴は、実はすべて修士時代の研究テーマから取り入れたものだ。
大学院時代は学部時代より長かったが、すべてPC 9801で作業した。

My PC History (3) Sony SMC 777

VICは推奨できない。しかし、このパチンコのような名前のパソコンSMC 777は推奨できる。
もし、SonyがSMC 777をシミュレータとして復刻するなら、今でも買う（かもしれない）。
数ある日本のパソコンの中でも名機中の名機だと思う。
唯一の欠点がメモリが少ないことだった。しかし、これは8ビットCPUを使っている以上、当然のことだ。しかし、他のメーカーは8ビットでも64KBの壁を無理やり超えていたので、どうしても見劣りがする。
777ではCP/Mを使うことができた。CP/MはOS（正確にはDOS）だ。コマンドプロンプトのようなものだと思えばよい。コマンドプロンプトでは何もできないので、CP/Mの何がありがたいのかわからなにかもしれない。CP/MのようなOSがあるとアプリケーションを自由に切り替えることができる。つまり、当時のパソコンはBASICしか使えなかったが、777はBASICをはじめ、LOGO, FORTRAN, C, Forth, Lisp, Prologなどが使えた。おかげで、大半のプログラミング言語を勉強することができた。
そのためか、かえって何もプログラムを作らなかった。すでに表計算ソフトなども含まれていたので自分で作る必要がなかったという理由もある。もう少しこのマシンでプログラミングを続けていればスキルが向上したかもしれない。
しかし、全くスキルが向上しなかったわけではない。事実、いくつかプログラムは作った。学校の演習の課題のようなプログラムだった。しかし、それらを作っていくうちに64KBの壁にぶつかった。つまり、VIC 1001では16KBを使いこなせなかったのに、いつのまにか64KBで満足できなくなっていたわけだ。
また、777にはフロッピーディスクが標準装備されていた。CP/Mとコンパイラ一式をフロッピーに入れると残りのスペースはわずかしかなかった。データが増えるとフロッピーに収まらなくなってきた。
このようにディスクやメモリの制限を感じて8ビットマシンはもう限界だと感じた。
777は64KBを超える8ビットパソコンより安かったが、VICよりははるかに高かった。これは確か大学の入学祝いに買ってもらったのだと思う。大学時代の友人はPC-9801を使っていた。当時PC-9801は本当に車（ただし中古車）に匹敵する値段だった。プリンターまでそろえると60万近くしたと思う。とても手が出なかった。
ちなみにPC-9801では一太郎などのワープロが登場していた。卒論をパソコンで書いた人もいた。しかし、私の場合、777では卒論を書けるようなワープロがなかった。そのため、いわゆるワードプロセッサで卒論を書いた。
このように大学（学部）時代はSMC 777と共に過ごした。

My PC History (2) VIC 1001

高校パソコンクラブ時代に自分のパソコンが欲しくなり、当時一番安いパソコンを買った。
それがVIC 1001だ。一番安いパソコンといっても、ワンボードマイコンにはもっと安いものも会った。CRCというマイコンは39800円くらいで販売していた。かなり迷ったあげくVICに決めた。この決断は間違っていなかったと思う。マイコンを買ったら直ぐに使わなくなっただろう。ハードウェアには詳しくなったかもしれないが、ソフトウェアを学ぶことはできなかっただろう。
VIC 1001はBASIC内蔵とはいえ、ユーザメモリは4KBくらいしかなかった。8KBの内蔵メモリ中、モニタとBASICが4KB使っていた。しばらくはそのまま使っていたが、どうしてもがまんできずに16KBのメモリカートリッジをつけた。結局、このメモリは宝の持ち腐れに終わった。当時の私のプログラミング能力では16KBのメモリを使い切ることはできなかった。
VIC 1001では、市販のゲームもしたが、はじめて自分でゲームを作った。どんなゲームかというと格子状の盤面で巡回する障害物を避けながらゴールを目指すゲームだ。これはある程度動いたが、マシン語にはまってしまい、あまり納得の行く出来にはならなかった。
BASICを習ったときIF,FORが何の役に立つかわからなかったが、ゲームを作ってはじめて役に立つことがわかった。
初心者がゲームを作るとき最初に思いつくアルゴリズムはキャラクタの動きをFOR文で表すものだ。例えば、ミサイルが移動するなら、消して書いてを繰り返す。しかし、物体ごとにFOR文を書いても、その物体だけしか移動しない。だから、それぞれの物体が少しずつ移動する処理全体をループにする。これがはじめて自分で学んだアルゴリズムだった。当時の雑誌にはゲームのアルゴリズムがフローチャートで示されていたものだ。どのゲームを見ても同じようなアルゴリズムになっていた。それがわかるまでは、どうやってゲームを作ってよいかわからなかった。
次の壁は、プログラムを完全に動作するようにすることだった。つたないプログラマーだったからバグは山のように出た。全く思ったとおりの動作にならなかった。それを少しずつ直していった。
最後の壁は、プログラムのスピードだ。一応動くが、どうも遅い。結局、BASICでリアルタイムゲームを作るのは無理だとわかり、マシン語を学び始めた。マシン語をハンドアセンブリして、DATA文に並べ、メモリにPOKEする。USR関数を使ってマシン語を呼び出す。最初のうちは簡単に暴走する。非常に根気の要る作業だ。そのうち全部マシン語にするのは、自分の手に余るとわかった。
このように簡単なパソコンでBASICとマシン語を学んだのはとてもよい経験だった。
しかし、VIC 1001というパソコン自身は決して他人には推奨できない代物だ。友人のPC 6001がうらやましかったし、PC 8001にあこがれた。VIC 1001が69800円なのに対してPC 8001は168000円で、10万円の差があった。

入門書と教科書

入門書と教科書は違う。
一般的に入門書はテクニカルライターが書き、教科書は教授が書く。テクニカルライターと教授の最大の違いは教育経験の有無だ。それが決定的な差になることがある。
つまり、入門書は純粋に学ぶ側に立って書かれるが、教科書は教える側に立って書かれてもいるということだ。その意味では、教科書より入門書の方がわかりやすいことがある。これは入門書がわかりやすい理由の１つでもある。しかし、入門書では独力で学ぶ必要がある。教科書は二人で学ぶようにできている。教師と学生の対話が盛り込まれている。
出版社は教科書が売れないという、それは授業で使えない教科書だからだ。教える側もそのような教科書には頼らない。必然的に強く推奨もしない。参考書と何ら代わりがない。出版社はもっと教えやすい教科書を作るべきだ。
教えやすい教科書とは、授業時間を意識した教科書だ。例えば、大学では90分で１コマとなる。よって、教える内容は90分で学べる単位にまとまっていなければならない。それ以上でもそれ以下でもいけない。入門書は純粋に内容でわけるため、時間配分ができない。
入門書を教科書に採択すると、入門書を講義用に再編集する手間がかかる。この手間は大きく無視できない。また、練習問題が少ないなどの問題もある。練習問題は時間調整に欠かせない。

My PC History (1) 序章

私のパソコン履歴は長いようで少ない。コンピュータに触れたのは高校からだ。入学した高校に当時としては珍しいパソコンクラブがあり、そこでコンピュータを知った。
当時の認識では「コンピュータでプログラムを作ればゲームができる」という程度のものだった。逆の言い方をすれば、ゲームをするためには自分でプログラムを組む必要があった。余り関心がなかったので覚えてないが、ゲーム専用機もあっただろう。しかし、特定のゲームしかできない専用機よりプログラムさえ作ればどんなゲームもできるコンピュータの方が魅力的だった。
当時はボードコンピュータとパソコンの端境期で、クラブにあったパソコンは（おそらく先輩の私物であった）Hitachi Basic Master Level 2だ。これで初めてBASICを学んだ。今の学校のように先生から学ぶのではなく先輩から受け継ぐような指導だった。最初はLET,IF,FORも何の役に立つのか全く分からなかった。それでもこれは大変役に立った。事実、大学に進学した後、プログラミングの授業についていけたのはひとえに高校時代からの蓄積があったからだろう。逆に、これで自分はプログラムができると勘違いしたかも知れない。今では、自分が大したプログラマーでないことを自覚している。上には上がいるものだ。
私が所有したパソコンは以下の通りだ。
　Commodore VIC 1001
　Sony SMC777
　NEC PC9801RA
　DOS/V(Iiyama製)
おそらく他の人に比べると意外なほど少ないだろう。経済的な理由で高価なパソコンは買えなかった。常に安い代用品を使っていた。
しかし、それでも初期のVIC以外にはずれはなかったと思っている。これらのパソコンは実に役に立ってくれた。

2008年1月4日金曜日

Gmailで自分宛メールを受信する方法

Gmailの問題点として指摘していた自分宛メールを受信（しても表示）できない問題に一応の対策ができたので報告する。
しかし、Gmailだけではうまくいかない。他にもう１つメールアカウントを必要とする。これは、それほど困難なことではない。例えば、foo@gmail.comとfoo@yahoo.co.jpがあればよい。
準備として、foo@yahoo.co.jpからfoo@gmail.comに転送するよう設定する。Gmailの[設定]-[アカウントの設定]でfoo@yahoo.co.jpを追加する。foo@yahoo.co.jpをデフォルトに設定する。普段はfoo@yahoo.co.jpを使い、foo@gmail.comは使わない。その後、メーリングリストにfoo@yahoo.co.jpを登録する。
自分宛に送りたいときはYahoo! Mailから送信する。そうすればGmailで受信できる。
この方法なら無料のアカウントだけで実現できる。
すでにGmailのアドレスが流布している人は他のアドレスに切り替える必要がある。メールアドレスの切り替えは面倒だが、全部切り替える必要はなく、メーリングリストだけ切り替えればよい。
Yahoo以外でも転送可能なメールアドレスがあれば実現できる。

Googleのドメイン

以前、Googleのドメイン名のつけ方に疑問があることを述べた。
最近になって思うことを付け足しておこう。
gmail.comのようにgoogle.comより短くなるドメインには意味がある。
しかし、googlepages.comのように長いドメインならpage.google.comでも同じだろう。むやみにドメインを消費して、かえって混乱しているように思える。
基本的にservice.goole.comで統一し、ショートカットのドメイン名を追加するのがよいように思う。
また、Googleクラスの有名企業ならそのままTLDでもよいだろう。例えば、mail.GOOGでどうだろう。

Gmailの問題点　自分への送信

Gmailでは自分宛（メーリングリストを含む）メールが受信リストに表示されない。
送信済みリストにしか表示されない。
必ず届くという前提なのかもしれないが、あるいは二重表示が望ましくないという意味なのかもしれない。いずれにせよ不便だ。
Gmailには大いに満足しているが、この点だけは不便さを感じている。
別のアドレスから送信したりSMTPサーバを変えたりする方法が紹介されているが、それではGmailを使う意味がなくなってしまう。
ぜめてオプションで切り替えるようにして欲しいものだ。

Programming by Gadget

ガジェット(Gadget)のプログラミングではなく。ガジェットによるプログラミングだ。
ガジェットはマイクロアプリケーションともいえる。
小さな機能はガジェットとして実現するのがスマートだ。
プログラミングのツールには小さなものがあり、ガジェットで実現することができる。
Google Gadgetには、JavaScript ConsoleやGoogle Gadget Editorがある。
これらだけでガジェット時代のプログラミングを予測するのは無謀かもしれない。
しかし、今後確実に増えていくだろう。
Rubyが対応してくれれば大変うれしい。

HotRuby

以前、「クライアントRuby」という記事で「JavaScriptで動くRubyは反則だ」と書いたが、それを実現した兵（つわもの）がいたようだ。
その名はHotRubyという。
心配していた実行速度は、それほど低下しないらしく、これなら反則とはいえない。
HotRubyが実現できた背景にはRuby 1.9のVMがある。サーバ側でコンパイルされたコードをクライアント側にダウンロードして実行するしくみらしい。確かに、この方式ならばある程度の実行速度を実現できるだろう。
クライアントRubyの記事では、インタプリタをJavaScriptで実現するのは速度的に無理があると判断たが、コンパイル方式なら無理ではない。
しかし、HotRubyでは一度サーバ側にソースを転送してコンパイルする必要がある。そのためオフラインでは使えない。その意味ではJavaScriptに対抗できるものではない。そもそもJavaScriptで実行するので対抗してもいないのだが。
HotRubyの使い方としては、マシンにRubyをインストールすることなく実行できることだろう。
しかし、そのためにはライブラリをネットワーク経由でrequireするしくみが必要だ。自分で書けばよいだろうが、それでは不親切だ。そのあたりのライブラリ管理も今後の課題だろう。
個人的にはHotRubyがGoogle Gadgetになって欲しい。

宮崎吾朗監督に期待

ずいぶん時期はずれだが、ようやく宮崎吾朗氏のゲド戦記を見る機会があった。
宮崎吾朗氏は宮崎駿氏の子息で、何かと比較されることもあり、その重圧は大変だと思う。
しかし、ゲド戦記を見ると初期の宮崎駿氏の作品を見ているようで、大変気に入った。
むしろ最近の宮崎駿氏の作品の方がおもしろくない。
もちろんこれは多分に好みの問題でもある。しかし、宮崎駿監督の作品は評価が二分されるというのはよく聞く話だ。私は芸術作品よりエンターテイメント作品の方が好きだ。しかもスケールの大きな冒険活劇が特に好きだ。ゲド戦記はそのつぼにはまっている。
吾朗監督には今後もおもしろい作品を作り続けて欲しいと思う。

2008年1月3日木曜日

まぎらわしい用語その２　ストリーミング

以前、紛らわしい用語としてクラウドを取り上げた。
ここでは、ストリーミングを取り上げる。
ストリーミングといえば、少し詳しいものなら、ビデオや音声をRTSPで配信することと考えるだろう。さらに詳しいものは必ずしもRTSPに限らないとも考えるだろう。
しかし、ストリーミングというときにもう１つデスクトップ仮想化の流れからアプリケーション配信を指すこともあるということを覚えておく必要がある。
今後は、企業内では後者のストリーミングが一般的になると考えられる。

2008年1月2日水曜日

ガス会社の将来

将来、石油が枯渇したとき、どのような社会になるのか考えてみよう。
まず、ガス会社だ。
まず、ガス＝石油ではないことに注意する必要がある。しかし、ガスも石油も化石燃料であるから、枯渇の恐れがある。ガスの枯渇は石油より遅いだろう。しかし、今のペースで使い続けていけば確実に枯渇する。
ガスのないガス会社は成り立たない。よって、電力会社に身売りするのがよいかもしれない。ただし、買ってくれるならばだ。ガスがある間は経営が成り立つ。しかし、相手に見切られる前に売る抜ける必要がある。
ガス会社がいつまでもガスを供給するサービスを続けるなら、今の化石由来のガスではなく持続可能なガスに切り替える必要がある。
ガスが継続する限り、様々なサービスが成り立つ。例えば、家庭の燃料電池に水素を供給するインフラは、今のところガスしかない。また、発酵ガスを生産することも考えられる。どのような燃料に切り替えるのかが成功の決め手となる。おそらく直接水素を輸送するより、水素を含む燃料を輸送し、何らかの装置で水素を取り出したほうがよい。このようにガス管は複数のガスを配送する媒体となりえる。競合しない限り、多くの種類を混合することで、ガスの価値を高めることができる。
このようなサービスを考える限りガス会社の未来は明るい。株を手放す必要はない。
問題は過渡期だろう。
ガス管のインフラを再整備するコストはかけたくない。となれば、バイオエタノールのように、どこまで混ぜても従来のガス器具が正常の動作するかを見極める必要がある。そして、複数の混合気体でも正常に動作するガス器具に徐々に切り替えていく必要がある。さもなければ、石油ファンヒーターや湯沸かし器のような事故が多発する。ガス会社の命取りとなる。
ガス器具は基本的にどのような混合比率でも正常に燃焼できるようにする必要がある。さらに、気体フィルタの機能を持たせ、有益な用途に特定の気体を使用できるようにする。例えば、水素だ。
ガスの切り替え期間はかなり長期にわたる。事前の告知をしつつ、何年までに切り替えるように注意を出しながら、段階的に行う必要がある。通常ガス器具は故障しなければ十年以上使うものだ。一般には家の寿命と等しい。よって、100年かかることも覚悟すべきだ。それだけの長期戦略を立てる必要がある。したがって、今から計画を立てていく必要がある。

以下に追加する。
上で100年と述べたが、いかにも長すぎる。それに毎年ガス管はどこかしらメンテナンスを行うので新しいガス管を敷設するにしても100年はかからないだろう。営業担当を総動員して注意を喚起すれば10年くらいでガス器具の入れ替えはできるかもしれない。もっと短く5年となると機器の耐久年数を下回るかもしれないので、賠償問題が発生する可能性もある。しかし、10年周期で次々と買い換えるわけにもいかないので、サービス向上と顧客満足度の維持をいかにバランスさせるかが難しいところだろう。

納豆の容器

納豆の容器には発泡スチロールがよく使われる。
これが原油価格の上昇に伴い納豆の価格を上げているらしい。
しかし、納豆の容器には発泡スチロール以外も使われている。紙の容器もあるし、硬いプラスチック容器もある。
硬いプラスチックはトウモロコシが原料だと思う。しかし、その製造過程に石油由来の薬剤を使うとやはり値上げせざるを得ない。紙は基本的に再生可能だ。しかし、どちらも透明フィルムで覆う必要があるし、しょうゆやからしのパッケージも石油由来のプラスチックだろう。
利用者の立場からは、納豆をかき混ぜるとき破れないほうがよい。だから、紙や硬いプラスチック容器の方が便利だ。人によっては味気ないと感じるかもしれないが、慣れの問題だろう。
トウモロコシで容器を作ってもバイオエタノールで原料が高騰するので、将来性は低い。そうすると紙が最有力候補になる。
ただし、トウモロコシ以外の原料で容器を作れば問題ない。１つ有望だと思えるものは納豆自身である。納豆のねばねばから容器を作れれば、すべて大豆で完結する。しかし、大豆を容器に使うか食料に使うかは考えどころだ。

乳幼児用冷凍食品

乳幼児の食品にはレトルトが多い。
しかし、レトルトは独特のとろみがあり、それを嫌う子も多い。
レトルトでなく日持ちする食品は何かと考えると冷凍食品に行き着く。
しかし、赤ちゃんの専門店にいっても冷凍食品を扱っていることはない。ましてやスーパーの冷凍食品売り場にもない。
何か大きな問題点があるのか、それとも誰も考え付かなかったのか、どちらかだろう。
後者ならよいが、前者なら考える必要がある。
まず、冷凍食品にするには水分が多いと適さない。氷は体積を増すだけでなく、細胞を破壊し、味を落とす。したがって、水分の少ない食事に適している。
しかし、乳幼児の食品は柔らかいものが適するので水分を含むものが多い。レトルトの場合は、その水分にとろみが多すぎることが問題だった。
水分の少ない乳幼児用メニューを考え付くかどうかにかかっているのかもしれない。

冷気で冷やす冷蔵庫

冷蔵庫がヒートポンプ型になり、既に相当効率は高くなっている。
しかし、ヒートポンプは常に稼動し続けるので、電力消費はゼロではない。
冷蔵庫の中には冷凍庫がある。このように冷蔵庫の中にも温度差がある。
この温度差を用いて段階的に冷気を再利用すると効率がよいだろう。
このような方法はとっくに行われているはずだ。昔は冷凍庫が一番上にあった。それが使い勝手を考えて場所が変わった。
一番上にあれば、そのまま冷気が下るに従って他の場所も冷やすことになる。しかし、今の冷凍庫は一番下にある。冷気が逃げないので冷やさなくてもよいため効率がよい。話が脱線するが、セブンイレブンのアイスクリーム売り場にはふたがない。それでもそれほど効率は悪くない（のだろう）。その理由は冷気を逃がさないからだ。
一番下にたまった冷気を再利用するには、空気を運ぶ必要がある。つまりファンを使う。そのコストはヒートポンプよりずっと小さい（だろう）。

Seam CarvingとワイドTV

昔のTVは縦横の比が3:4だった。ワイドTVになり9:16になった。
一般的にワイドTVはハイビジョンであることが多い。
しかし、画質が高い割りに縦横比がでたらめな画像を再生していることがよくある。人物が太って見える。こういう場合は画面の横を使わずに正しい比率で再生すればよい。しかし、それではワイドの意味がほとんどない。せっかく買った大画面TVを小画面で使うしかない。
そこで、従来の単純な拡大・縮小アルゴリズムではなくSeam Carvingで拡大・縮小してはどうかと考える。Seam CarvingはSIGGRAPH 2007で登場したばかりだが、多くの実装が出ているようだ。しかし、まだ動画のSeam Carvingやリアルタイム処理はまだまだ研究段階だろう。
TV企業は、そのアルゴリズムを開発し、LSI化してTVに組み込むべきだ。そうすれば自然な画像が自動的に創造される。もちろん、再生時に従来方式と選択できるようにする。多くの場合、リアルタイムSeam Carvingの方が適切だと思うが、正確な描写が求められる場合もある。例えば、科学番組や教育番組などだ。物理実験の番組で定規の長さが変わってはおかしい。

2008年1月1日火曜日

Yahoo! Japanの問題点とその対策

読者の中にはYahoo! Japanのメールを使用している人もいるだろう。
しかし、多くの人はYahoo! Japanのアカウントを持っていても実際に使ってないのではないかと推測する。理由は、自分がそうだからだ。
インターネットの黎明期から存在するYahoo!およびYahoo! Japanには多くのユーザが登録している。その登録数は決して減少していないだろう。そして、そのメールアドレスに届くメールも決して減少していないだろう。しかし、実際には使われず、それらのメールはYahooを素通りしてGmailて転送される。理由はYahoo! JapanのメールよりGmailの方があらゆる点で優れているからだ。つまり転送設定を面倒だと思ったり、知らなかったりするユーザ以外は、転送しない理由がない。
これはYahoo! Japanにとって一長一短である。長所としては、ストレージ資源に不必要な投資をしないですむことだ。短所としては、やがてポータルサイトの地位を失うかもしれないことだ。事実、日本国内ではYahoo! Japanは検討しているが、世界的にはYahoo!からGoogleへサーチエンジンの主流は移っている。よって、コスト削減を喜んでいる場合ではない。
Yahoo!は世界戦略にあたって地域化を行った。しかし、Googleは多言語化を行った。この差は大きい。地域化は決め細やかなサービスを提供できる反面、人件費や設備費などの経費が増大する。多言語化はプログラム（あるいはレポジトリ）の修正だけで済む。この点ではUnicodeが普及する以前から活動しているYahoo!にハンデがある。しかし、今までなんら対策を講じてこなかった点はやはり問題だ。
Yahoo! Japanはサービスの質を向上させるために、メールなどのMy YahooサービスをYahoo!にアウトソーシングするべきだ。Yahoo! JapanよりYahoo!の方が豊富なサーバ資源を持っている。利益に結びつかないサービスは資源を集中させ、それ以外の新規サービスに既存資源を振り向けるべきだ。例えば、動画配信は日本の方が進んでいるだろう。少なくともビジネスとして成り立っている。
My Yahooがアウトソーシングする場合、Yahoo! Japanのメールアカウントfoo@yahoo.co.jpはfoo@jp.yahoo.comのようになればよい。無理やり別名(例えばfoo2@yahoo.com)に統合しないほうがよい。同様に日本以外の地域化Yahoo!もYahoo!にアウトソーシングすればよい。
Yahoo!のメールはGmailにそん色ないばかりか、ストレージ容量が無制限である。ただし、細かなサービスはまだまだ改良すべき点が見受けられる。しかし、個別に対応するより１つの組織が対応したほうが早い。

車の燃費対策

車の燃費対策は重要な問題だ。
今、メーカーはエンジンの改良に力を入れている。次世代ディーゼルでも30%燃費が改善されると聞く。ハイブリッドも同様だ。
燃料電池やバイオエタノールは燃費と無関係だ。燃料を浪費しても環境に悪影響がない。しかし、ハイブリッドにせよ石油燃料を使う場合、燃費対策は絶対に必要だ。
エンジンだけでは十分な燃費を実現できないため、車体の軽量化が進んでいる。各社とも10%以上の軽量化を目標にとりくんでいる。
おそらくアルミや炭素繊維の割合が増えるのだろう。また、思い切って部品を減らすという考えもある。
車体軽量化は、非石油エンジンでも重要だが、安全性が低下する可能性がある。一般的に車同士が衝突すると軽い車がつぶれる。軽量化が優先されると、衝突時の安全性はしばらく現状維持のまま停滞する（向上しない）かもしれない。それを補うようにエアバッグのフル装備や事故を未然に防ぐ対策に力を入れるだろう。
単純な思いつきだが、フルブレーキ時にタイヤの接地面積を増やす仕組みができないものだろうか。

2007年のまとめ

あけましておめでとうございます。
2008年のはじめに、2007年のまとめをしておく。
投稿数の統計は人手で集約せずとも自動的にしてくれるが、それにコメントするのは人にしかできない。
まずはデータを以下に示す。
　2007年 (496)
　12月 (81)
　11月 (66)
　10月 (82)
　9月 (126)
　8月 (54)
　7月 (42)
　6月 (31)
　5月 (2)
　4月 (9)
　3月 (3)
2007年は、ブログを始めた最初の年だ。始めた月は３月だ。そのころは日記のようなつもりだったので、三日坊主だった。本当に３件しか書いていない。GWで時間があるはずの５月にも投稿数は増えていない。このころは、まだ何のためにブログをしているのかわかっていなかった。６月ごろから記事の内容や数が一定してきた。７月には割り切った考えをすることができるようになった。
やはり１つの物事を追求するには少なくとも半年は経験する必要がありそうだ。そうでないと表層的な理解で終わってしまう。しかし、すべてのサービスを半年も使い続けるのは大変なので、どうしても類推するしかない。

登録: 投稿 (Atom)