電子辞書でLinuxを

電子辞書が売れている。
電子辞書は立派にコンピュータだ。
いま、Eee PCなど廉価ノートが話題になっているが、電子辞書ほど安い物はない。
ただし、電子辞書のCPUではWindowsは動作しないだろう。よって、一般的なPCのOSは使えない。しかし、Linuxなら使えるだろう。
電子辞書をLinux PCとして販売すれば、受け入れられるのではないだろうか？
個人的には、Zaurusユーザだったので、ぜひLinux電子辞書が欲しいところだ。
課題も多いだろうが、ぜひシステムを拡張できるような設定で、売り出してほしいものだ。

トランクルームでデータセンター

トランク１つでデータセンターを作る実装技術を各社が研究・開発している。
（他の国は知らないが）日本にはトランクルームの会社がいくつかある。中には空調なども完備し、ワインなどを保存できるトランクもあるという。
そのようなトランクならば電源容量さえあれば十分トランク型データセンターを構築できるのではないだろうか？
日本の会社、特に中小企業は小型サーバを利用することが多い。そのようなサーバはすべてトランクルームに収納できる。
ユーザ企業側が動くのではなく、トランクルームの会社が動くべきだろう。自ら開発して、売り込むと、新たな市場を開拓できるだろう。

1.4KLOC/人月

少し古い記事だが、ThinkITで複数のプロジェクトの統計から平均的な開発を1.4KLOC/人月としていた。
これはかなり微妙な数値だ。普通にプログラムを書いていれば1日100LOCは余裕だろう。しかし、バグがあればなかなか進まなくなる。3KLOCになるはずのところが、その半分にしかならない。そのように見て取った。
とすれば、テスト駆動などバグの出にくい開発方法を採用し、効率を改善する必要があるだろう。

デジタルフォトフレーム

Sony DPF-V900はデジタルフォトフレームという商品だ。
デジカメの写真をスライドショーで見せてくれる。
デジカメ時代に入ってアルバムに残すには多すぎる写真をとっていると気づく。そのような時にデジタルフォトフレームという選択肢が登場したということだろう。
しかし、まだまだこの商品は改良の余地がある。
スライドの再生がランダムか、時間順でしかできない。ときには再生順序を指定したいことがある。そのような時にはファイル名の順番にしたい。時間順は非常に不便だ。いずれにせよデジカメでは時間順＝名前順となるファイル名が振られる。それが生かせないのは痛い。
おそらく、このような商品の次のステップはFlickrなどの画像共有サイトと連動することだろう。DFP-V900には1000枚入るが、それでも限りはある。利用者は何度を設定しなおしたりしたくない。Flickrなどでアルバムを作っているなら、それを再生できたほうがよい。
おそらく次はネットワークフォトフレームが出てくるだろう。
また、ビデオなどが再生できればさらによい。デジタルフォトフレームは広告にも応用できる。ＰＣなしにプレゼンテーションできるツールにもなる。しかし、今の仕様では難しい。

SkyDriveのファイル検索

SkyDriveは便利で使うのだが、ファイルを探すのに苦労している。
5GBも容量があるので、たくさんのファイルをアップロードするが、どこに置いたか忘れてしまう。
しかし、検索ができない（ように思える）。
検索欄はあるが、単にMSNの検索らしい。
肝心のファイル検索がないようではオンラインストレージサービスとしてはいまいちだ。

コーヒーとお茶

北京で宿泊したホテルの近くにスターバックスがあった。これはコーヒー党の私としてはありがたかった。というのも、このホテルだけかもしれないが、コーヒーには最初からミルクと砂糖が入っている。個人的には、いずれもコーヒーには不要のものだと思っているので、ちっともおいしくない。もっとも日本でもスターバックスがあれば他のコーヒーなどいらないのだが。
同じ飲み物としてお茶についても記しておく。たびたび水筒を持っている人を見かけた。水筒が透明だったこともあり、中身を見るとことができた。それが葉をいれたままのお茶だった。前にも述べたが北京の夏は暑い。そこで水分が欲しくなる。お茶は一番よい水分補給だ。コーヒー党の私でもコーヒーだけ飲み続けるのはかなりきつい。お茶なら一番抵抗がない。冷たいミネラルウォーターも普及していて、水筒のない人は利用していたようだ。しかし、値段と健康を考えるとやはりお茶がよい。中国の茶はうまい。日本ではウーロン茶が主流で苦いという印象があるが、本来はほんのり甘い。その味が生かせれば日本でも中国茶がもっと普及するだろう。

中国の物価

書き忘れていたことがあったので追加する。
中国の物価だ。
私の個人的な感覚では日本の半額という気がする。つまり、10元(170円)で340円分の価値のあるものが買えるということだ。
もっとも、この感覚は微妙なので、すべてに当てはまるわけではない。つまり、まだ日本より安いが、それほど安くはないという段階に達している。
このまま元の切り下げが進めば、やがて円とほとんど変わらなくなるだろう。日本の企業は生産拠点を再考するべきだ。ただし、中国には良質の労働者が大勢いるので、なかなか代替地は見つからないかもしれない。少なくとも人件費の割合が多くない産業は中国から移転する可能性は高い。もう少し水資源の豊富な地域へ移転するかもしれない。あるいは日本へ回帰するかもしれない。

北京の夏

北京の夏は熱い。今頃の時期はまだましだと思うが、それでも結構熱い。日本ほどではないが、蒸し暑いという感じだ。ヨーロッパの乾燥した暑さではない。
海に近い東京でさえヒートアイランドの対策を始めているのに、陸地の北京が何もしなければ大変なことになるかもしれない。これからますますアスファルト舗装が進み、高層ビルが風を遮り、車が増え、エアコンが普及し、水不足が進むとなれば、かなり問題だ。
ただし、エアコン自体はかなり普及しているようでアパートの各部屋についているようだった。もっとも高い外に室外機が設置してあると地震の時どうなるのかと心配してしまう。おそらく地震はないのだろう。しかし、四川の例を見れば、あり得ないとはいえないのだから対策はするべきだろう。
閑話休題。すでに普及しているエアコンをなるべく早くヒートポンプ式に切り替えるべきだ。それだけでかなりの省エネになる。また、温水もヒートポンプがよい。対策ははっきりしているので一気に進めれば早い時期にCO2の削減目標をクリアできるはずだ。中国が京都議定書の批准にためらう理由はないように思える。ただし、これは北京に限っての話かもしれない。1990年当時まだエアコンを使っていない地域だとすれば、単純に電気を消費する分だけCO2は増えるだろう。

ガイドブックには英語名を

地球の歩き方には日本語と中国読みが書かれているが、英語名はない。ツアーに行くとき非常に不便だ。ほとんどのツアーは英語だが、何を指しているのかわからない。せめてガイドブックには英語名を載せて欲しい。
北京周辺の代表的な観光地の英語名を掲載しておく。
（万里の）長城(great wall)。単にgreat wallというと最も観光地化している八達嶺(badaling)を指すことが多いようだ。しかし、他にも司馬台(si ma tai)、慕田峪(mu tian yu)などもある。
明十三陵(the ming tomb)。
故宮(the forbidden city)。
天壇公園(the temple of heaven)。
頤和園(the summer palace)。

中国のコンビニ

中国の7-11はかなり人気のようだ。昼には長蛇の列になる。店の中を一週するくらいだ。おにぎりなど日本食らしいものが売られているが、味付けは中華だ。このあたりは台湾に似ている。違うのはその場で調理したような総菜をカフェテリア方式で選ぶ弁当だ。値段も安い。日本ではビジネスホテルの近くにコンビニがあることが当然のようになっているが、外国でコンビニがあると本当に助かる。

中国の道路の横断

中国では横断歩道は意味がない。:-)
皆、車の合間をぬって道を横断する。
３回目にしてようやく中国の道路を横断するのに慣れた。最初はタイミングがつかめず、そして横断歩道をわたるべきだという思い込みで抵抗があった。もちろん、よいことではないが、しかたない。中国の都市は碁盤の目のように整理されている。ずっと昔からそうだ。そして、そのスケールが日本とは違う。横断歩道は交差点にしかない。そこまでが非常に遠い。どう考えても横断した方が楽だ。
しかし、歩行者の横断は危険なので、中央分離帯に柵を設けて制限するようになっているようだ。これは実際のところかなり厳しいだろう。非常に不便に感じるはずだ。柵だけでなく歩道橋の整備も同時にするめる必要がある。少し高望かもしれないが、200m以上は歩かないで済むようにしてほしい。200mというとだいたい日本のコンビニの割合に相当するので無理はないだろう。

中国のナンバープレート

中国の車のナンバーは漢字１字＋英字１字＋英数字５字のようだ。このシステムなら漢字を除いても15億まで表せる。日本は地域名や区分の数字を変更して対応しているようだが、数字だけなので少々無理がある。だから例外的に枠を広げたり、新しい地名を導入しなければならなくなる。もっともご当地番号もいきな計らいではあるが。このようなナンバーの不足は英字を入れれば抜本的に解決できる。日本の行政を簡素化するには、ご当地番号の増加は逆効果だ。もっとも市民サービスの質的向上という面からは悪くない。
また、少し話題がそれるが、中国の車に新車が増えたようだ。まだ地方はわからないが、高速を走る車はいずれもりっぱだ。東京と変わらない。経済発展の様子がはっきりと認識できる。おかげで朝夕の渋滞がかなり激しくなっているらしい。それでも日本に比べればましに見える。というのも、こちらの道は、昔からの歴史的な都市計画と土地の私的所有がないおかげで車線数が多いからだ。しかし、無理な車線変更が横行しているので、クラクションが聞こえることが多い。このような運転マナーも次第に慣れて落ち着いていくだろう。しかし、日本のようになるとは思わない。むしろ欧米のようになるだろう。

北京

しばらくブログの発信が空いたのは出張があったからだ。今回から、数回にわたって、中国の期になる点を述べる。
出張時期としては、北京オリンピック直前の大変よい時期だった。オリンピックに行く人にも多少は参考になる顔知れない。
成田から４時間弱で北京に着く。北京空港は広い。そしてきれいだ。到着ターミナルから手荷物受け取り所のあるT3まで連絡シャトルで移動する。この連絡シャトルがすごいスピードで走る。移動距離が長いのでスピードも必要だと思うが、暴走気味にも思えた。入管は込まなかったが、シャトルは混んだ。T3で手荷物を受け取る。そのレーンだけで50くらいはある。ハブとして設計されていることがよく分かる。成田とは大違いだ。こういう空港に来るたびに成田のダメさを痛感する。
タクシーでホテルに直行した。慣れない場所では高くてもタクシーに限るというのが今までの渡航経験で得た教訓だ。いわゆる白タクには注意する必要があるらしい。周りにそれらしい人はいなかったが、引っかかった人もいた。今でもまだあるということだろう。タクシーの運転は意外と安全運転だった。ホテルまで約１時間の道のりで100元だった。日本の感覚でいえば決して高くない。途中で少し渋滞があった。渋滞の有無はあまり関係ないのかもしれない。

省エネエレベーター

エレベーターで±１階に行くのはよくない。なるべく階段を使った方がよい。
そこで、あえて±１階に行けない設定をする。
たとえば奇数階あるいは偶数階のいずれか一方にしか止まらないようにする。この方法は複数のエレベーターが必要となり不便が多い。
そこで、２階以上離れた階のボタンしか押せないようにする。この方法なら簡単な設定だけでできそうだ。
しかし、重い物を移動するときにはエレベーターでないと困る。そういう場合は、いったん行き過ぎてから戻る。２階以上離れれば、目的地としてボタンを押せる。
しかし、考えてはみたものの、このようなエレベータが便利とは思えない。つまり、省エネなど気にせずに、あるものは使った方がよいということだ。
エレベーターの利用を少なくするには、エレベーターの速度を抑える方が有効だろう。寒暖で歩いた方が速いなら、そうする人も少なくない。

MiEV

三菱自動車のiはデザインの秀逸さで評判だった。私も候補に考えたうちの一台だ。しかし、発表間際だったのと、不祥事の印象で避けた。
それが今度、電気自動車になるという。これは一気に買い替えの最有力候補になったかもしれない。
いつかはハイブリッドと思っていたが、一足飛びで電気自動車もよい。
しかし、初期不良が心配なので、初年度は避けるのも賢明かもしれない。もっともみんなが避けては改良もあり得ないので、買い替えのタイミングが合えば即買いもよいだろう。
他社も追随するだろうから、しばらく新車ラッシュが続くのかもしれない。もっとも来年の話のようだが。
残る問題は走行距離だ。1回の充電で高速を走り切るくらいでないと困る。渋滞して高速で立ち往生というのは最悪のシナリオだ。クーラーを使いながら、どのくらい走れるのか、カタログではわからない実用的な走行距離が算出されないと心配は消えない。

参加型鉄道サイト

国土交通省は識者の提言を受けて「参加型鉄道サイト」を作るという。
そんなことを提案する識者に見識があると言えるのだろうか？
そもそも鉄道はもはや完全に民営化しているはずで、民間の事業を支援するために国が予算を使うのは筋違いだろう。そして民間が同様のサイトを運営するメリットがあると思っているなら、もっと早くから始めているだろう。
このようなサイトができれば新幹線を引いてくれという陳情のために使われるのが落ちではないだろうか？
もし作るなら、無料のSNSやサイト構築サービスがあるのだから、そのようなサイトを活用してほしいものだ。また、何百万を費やしてホームページを作るなどということのないようにしてほしい。

Processing.js

Processingという言語がある。Javaで実装されたLogoあるいはBasicという雰囲気の言語だ。ようするに初心者向けにグラフィックスが使える言語だ。しかし、本格的に使えばアートにまで消化できる潜在的な能力を持っている。
これをJavaScriptとcanvas要素を使って実装したのがProcessing.jsだ。本家よりこれに注目している。
Processing.jsではJavaの変数宣言のキーワードintなどがそのままつかえるようだ。ただし、実装を見るとintやfloatを単純にvarに変換しているだけだ。しかし、エラーを起こさないことが重要だ。
これをもう少し修正するとProcessingだけでなく、Java自身をProcessing.jsで動作させることができるかもしれない。そうなればJavaアプレットがJavaScriptだけで動作するかもしれない。
また、Javaと似た文法の言語なら何でもよくなると、Cも実行できるようになるかもしれない。細かなセマンティクスは完全に再現できないだろうが、初心者教育には十分使えるものになるだろう。
このような将来性を考えてProcessing.jsには注目している。

Roadrunner

IBMが開発したRoadrunnerが1Pflopsを達成した。BlueGeneの2倍となり、ようやくtop500の1位が入れ替わりそうだ。
日本の京速プロジェクトが目標とする10Pflopsには及ばないが、一番近いところにいる。
RoadrunnerはCell BEを大量に使用している点に特徴がある。
京速プロジェクトはどんなアイデアで10Pflopsを達成するのだろう。いまのところ目新しいものはなさそうだが、本当に10Pflopsまでいくのだろうか？10倍の予算を使えばいくかもしれない。
ちなみに、Roadrunnerの開発費が1億ドルだそうだから、100億円として、1000億円必要なことになる。これだけの予算を確保することは不可能だろう。
プロジェクトを立ち上げた以上は勝算があるのだろう。しかし、一時的にtopに入るくらいでは、失敗といわれそうだ。なかなか難しいプロジェクトになりそうだ。野次馬の一人として注目している。

耳から目へ、そして耳へ

赤ちゃんは耳で言葉を覚える。決して文字を読んでから言葉を覚えるわけではない。
しかし、やがて学校で文字を学び、本を読んで学ぶことを覚える。
そうなれば自立したことになる。耳で覚える学習には親が付ききりでかかわる必要があるが、目で覚える学習には親は不要だ。
しかし、目による学習は目を酷使するため近視などの問題を生む。
やがて年を取ると目で読むことも難しくなる。同時に耳も遠くなる。しかし、補聴器を使う方が眼鏡よりたやすい。よって目による学習より耳による学習の方が利点が多くなる。最近ではiPodなどもある。目を休めて耳を使う方が何かと都合がよい。
高齢化社会へ向けて耳による学習を普及する努力がもう少し多くてもよい。
そのためには電子ブックの普及と読み上げ技術の向上が必要だ。
読み上げは音声合成だ。音声合成は音声認識に比べればはるかに実用化の近い技術だ。一部の分野、たとえばDTMのVOCALOIDなどでは、ブレークスルーを迎えつつあるように思える。今後いっそう開発に拍車がかかり自動化が進めば、耳による学習の時代となるかもしれない。

昆虫画像の人力検索

商売になるかどうかはさておき、こんなサイトがあると面白いと思ったアイデアを書いておく。
それは、昆虫画像の収集及び検索サイトだ。
昆虫には多くの種類があり、素人にはわかりにくい。また、専門家でもすべての種類を網羅することは難しいだろう。そこで、みんなが自分の周りの珍しい昆虫写真を持ち寄って、どういう種類なのが議論できるサイトがあると役立つ。
昆虫マニアは少なくない。このようなサービスは多くの一般ユーザ向けではないが、マニアに特化することで意外な成果、たとえば新種の発見など、が得られるかもしれない。
また、その昆虫がどのような種類なのかも人力でタグ付けし、分類する。多くのタグに該当したものが種類と認定される。
やがてデータが充実すれば自動的に識別することも可能となるだろう。もちろん100%ではないだろう。しかし、かなりの確率で同定できれば、それだけで十分役立つ。
多くは既知の昆虫だろうが、珍しい種類も報告されるかもしれない。また、撮影場所をGoogleマップで示すと貴重な資料になる。ただし、珍しい種類の場合、絶滅しないように乱獲には注意する必要がある。

P2Pのたそがれ

P2Pが有効であるためには前提がある。それはクライアントとサーバの性能差が小さいことだ。
CPUメーカーのIntelもP2Pを推進している。これは一見不思議に思える。なぜならIntelはサーバ用CPUが売れたほうが収益がよくなるからだ。しかし、クライアント同士が連携するP2Pに価値を見出している。その理由はサーバ用CPUとクライアント用CPUでそれほど性能差がないからだ。つまり、ASPなどをサーバサイドで提供するにはクライアントと１：１に近い比率でサーバを用意しなければならない。それはあまりに無駄なのでサーバの負荷をクライアントに振り替える技術が重要だ。その結果、P2PやAjaxが重要となる。
しかし、最近その前提が崩れつつある。クライアントではULCPC、MIDのようなネットワーク端末に特化した形態も増えている。その結果、サーバにはmany coreが採用され、クライアントでは省電力型シングルコアが採用される。これはクラウドでは必然の流れだ。両者の性能比はかなり大きくなってきた。PS3のようなマルチコアのゲーム機は例外だ。
非力なクライアントではサーバの代替にはならない。そのようなクライアントはP2Pの輪からはずれる。もっともそのようなクライアントまでP2Pに取り込む研究もあるにはある。しかし、性能差の慣性は大きいだろう。
したがって、PCからULCPC、MIDへのシフトが進めば、P2Pは衰退せざるを得ない。ただし、すべてのクライアントがULCPCやMIDになるはずがない。その意味では、P2Pには一定の市場が残る。もしかしたらサーバサイドP2P(S2S？)を真剣に検討する時期に来ているのかもしれない。

アメリカシロヒトリ

庭の椿にアメリカシロヒトリが繁殖してしまった。
この梅雨で繁殖に気付かなかったため、ほとんどの葉を食べられてしまった。
しかし、それほど深刻な問題ではない。簡単に駆除できるからだ。
ちょっとしたコツがある。
日中はほうぼうの葉に分散して葉を食べる幼虫が日没または早朝には幹の根本に集まる。そこで、幹に殺虫剤を噴霧すればよい。これで一網打尽だ。
この方法に気付くまでは葉ばかり見張って、そのつど殺虫剤を噴霧していた。大変だった。
しかし、根本に集まっているのを見つけてからは２～３度噴霧すればおおむね駆除できるようになった。
何事にも方法というものがある。

ハンバーガーがまずい理由

最近、ハンバーガーを食べることが少なくなった。ファストフードのハンバーガー店に行かないのではない。いってもハンバーガーを注文しなくなったということだ。
日本にはおいしい食材が多い。コロッケやカツなどがあると、それを選んでしまう。ハンバ－グにしてもシーフードがある。めずらしさも理由の１つだ。
しかし、最大の理由はハンバーガーの肉がまずいためだ。わざと肉汁をおさえたかのようなパサパサしたものを食べるより他を探してしまう。
ハンバーガーショップは最大の売りがちっとも魅力的でない。最近ではチーズを売りにしているチェーン店もあるが、肝心の肉がおそまつではつりあわない。
そこでどうすればよいかだが、ソーセージを薦めたい。歯ごたえのあるパンに挟めば最高のホットドッグだ。空気ばかりの軟弱なパンは嫌いだ。
ソーセージといえばドイツだろう。実はオイツでなくても十分うまい。ヨーロッパではあちこちのスタンドでホットドッグを売っている。どんな場所でもハンバーガーよりよほどうまい。
アメリカの食文化はまだまだヨーロッパに及ばない。

O/Rマッピングの階層

O/Rマッピングが普及してきた。しかし、O/Rマッピング自体にくせがあったり、インストール上の制約があったりして、実際には問題も多い。
O/Rマッピングは階層を明確にするべきだ。
例として以下のような階層を考える。
言語層　Java,Ruby,PHP,Perl,Pythonなど各言語のAPI
サービス層　言語に依存しないAPI。Webサービスとして実現されるだろう。SOAPとRESTなどが考えられる。
SQL層　DBMSに依存しないSQL
DB層　DBMSに依存するSQL

私がiPhoneを買うとしたら

SBMからiPhoneがでるらしい。
SBMの携帯とiPod touchを使っているが、別にiPhoneを欲しいとは思わない。
そもそもiPod touchで十分だ。携帯として使ったらバッテリーが持たないだろう。
SBMの携帯を使っているのは、特に深い理由があるわけではない。最初に買ったとき、たまたま安かっただけだ。しかし、ホワイトプランはありがたいと思っている。
そのような私がiPhoneを買うとしたら、iPhone自体よりその料金体系にひかれるかもしれない。iPhoneを使いこなすには定額データ通信と組み合されなければならないだろう。もしホワイトプランと大きく違わない料金でデータ通信できるならiPhoneでなくても買う価値がある。

住所を表すDNSあるいはURL

DNSで国を示すことはできる。ccTLDだ。その段階ではURLでも同じだ。
しかし、その先の細かな住所まで一意に表す方法が欲しい。
調べればあるのかもしれないが、ここでは調べずに思いついたことを書いている。後で分ったら、訂正を入れるつもりだ。
住所を特定するには郵便番号が便利だ。しかし、全部を特定できるわけではない。郵便番号はあくまで郵便配達が便利なように作られただけのコードだ。行政区域と正確に対応しているわけではない。また、名称変更もわからない。もっとも名称変更のたびにコードを変えたら不便だろう。そのまま書くのと変わらないか、それより長くなる符号化も却下だ。
可能なら数字だけで全部表せるとよい。そうなるとURLではなく電話番号かもしれない。しかし、SIPというものもあるので、電話番号がURLであってもおかしくない。
国コードは英字2桁/数字3桁でよい。
日本の場合は、国の下に都道府県コードが続く。2桁必要だ。
その下は市区町村コードだが、これは相当差がある。3桁必要だろう。
ここまでは、電話番号と同じようなものだ。
しかし、町目、番地、集合住宅の部屋番号まで含めると違ってくる。
後はコードと名称の相互変換のしくみが必要だ。
この程度なら既存の符号があるだろう。それをもう少し日常的に利用した方がよいかもしれない。

SaaSとASPの違いは回線？

あるブログ（リンクしてもよいのだが、批判的にコメントするので、ふせておこう）に、SaaSとASPの違いは回線であるかのように書いてあった。ASPは専用線で接続し、SaaSはインターネットで接続するのだそうだ。こんな分類は初耳だ。
確かにASPの事例を多く知っているわけではないし、ましてや（お金もないので）それを使ってもいない。だから専用線でしかサービスされないASPがあるのかもしれない。しかし、インターネットでサービスされるASPはいくらでもあると思う。
私はあくまでSaaSとASPの違いは、SaaSがサービスであるのに対して、ASPがアプリケーションであることだと思う。この定義もSaaSの拡大解釈（Webサービスから一般サービスへ）でかならずしも適切ではないかもしれないが、本来の（狭義の）意味はそうだと思う。
結局、突き詰めれば言葉を使う本人がどちらで呼ばれたいかということになってしまうので、最近では皆SaaSになってしまう。

xVM VirtualBox

普段はVMwareを使っているが、基本的には有料だ。
無料のSun xVM VirtualBoxがあると聞き、試してみた。
Windows XP SP2をインストールしようとしたところ下記のようなエラーが出た。

Unable to allocate and lock memory. The virtual machine will be paused. Please close applications to free up memory or close the VM..

それ以上、インストールが進まなかった。
まだまだ、使えるものではないのかもしれない。