Netwalker

SharpのNetwalkerはブラウジングに特化したモバイル端末だ。電子辞書と同サイズでありながら、一般的なOSがインストールされている。かつてのZaurusが蘇ったようだ。
iPhoneなどのスマートフォンと異なる点は、広い画面とフルキーボード、その代償としての重さと大きさ、そして汎用OSが動くことによる汎用性と拡張性だ。OSはUbuntuであり、そのアプリケーションを利用できる。例えばOpenOfficeがインストールされている。もちろん3Gで通話できない。
ネットブックとの違いは、CPU、OSだ。CPUはAtomでなくArmだ。OSもWindowsでなく、Ubuntu Linuxだ。そのため、Netwalkerにはネットブックほどの機能や便利さ、アプリケーションはない。
つまりはスマートフォンあるいはPDAとネットブックの中間に位置する製品だ。PDAより広い画面、つまりPCと同等の画面でPCと同じブラウザを使える。ただしOSの違いからできないことも多い。また、ネットブックより小さく軽いので、持ち運びが楽だ。
かつてのZaurusはOSこそ汎用であったが、ブラウザもOfficeもPCとは大きく異なっていた。画面も小さかった。ZaurusはPDAに分類されていた。今、Netwalkerが新たなカテゴリを提案している。
実際、このカテゴリはこれから有望だ。Google Chrome OSが狙うカテゴリとも一致する。ただしChrome OSの方がネットワークに対する依存度が高い。
Netwalkerは確かにiPhoneよりブラウジングに適している。不完全ながらFlashが使える点も大きい。NetwalkerのFlashはバージョン8だ。
しかし、少し使っただけだが、問題点も見えてきた。以降は長所と短所を織り交ぜながらコメントする。
マウス代わりのOptical Pointはスムーズに使える。トラックボールが機械式マウスを逆さにしたのと同様に、Optical Pointは光学式マウスを逆さにしたようなものだ。Netwalkerは画面が広ためポイントするには高い精度が必要になる。これにはぎりぎり合格といったところだ。ウィンドウを閉じる時に神経を使う。秀逸なのは、位置決めとスクロールの2つのモードがあることだ。しかも、このモードをボタン1つで切り替えることができる。
画面はタッチパネルになっているが、ほとんど使っていない。解像度が高くて指で押せないからだ。付属のスタイラスペンで指せばよいのだが、本体に収納できないので、持ち運ばない。
バッテリは折り曲げ部分に位置するので、重量配分もそこに集中している。両手で持って使う時にキーボードの両端をつかむと、バッテリの重みを意識する。ポインタはキーボード上部に位置し、両手の親指で操作する。その状態では人差し指がバッテリ下を支えるので、きちんと保持できる。問題はキーボードをタイプする時だ。広いピッチのキーボードといえば使いやすいように思えるかもしれないが、広すぎて親指だけではカバーできない。片手を離す度に、重量バランスがくずれる。要するに両手で持つには申し分ない重さだが、片手で持つには重い。さらにキーを両手で同時に押さなければならないこともある。そのような場合、液晶側から落ちそうになる。要はバッテリから手を離すとバランスが悪いのだ。
個人的には、キーボードは親指が届くところに集中していた方がよいと思う。無意味にキーが大きいと感じる。キーとキーの間隔をきちんと開けることで押し間違いをなくすようにしていればよい。本体のサイズにキーボードのサイズを合わせる必要はない。むしろ、キーの組み合わせを減らすためにキーの数を増やした方がよい。
例えば、ウィンドウを切り替えたり、アイコン化したり、閉じたりするキーが欲しい。これらをOptical Pointで行うのはいささか細やかな作業になるからだ。
アプリケーションの起動には若干時間がかかる。間違って2回起動してしまいそうだ。Chrome OSの起動時間にも匹敵する。これはCPUが非力なせいだろう。駆動時間との兼ね合いもあるが、もう少しパワーが欲しい。
実際Eclipseを動かそうと試みたが、うまくいかなかった。フリーズしたようなので再起動せざるを得なかった。完全なUbuntu PCにはならない。

Google SpreadsheetをODBC/JDBCから使いたい

ODBCを使ってAccess/Excelのデータをアクセスするというのは、Officeの基本的な使い方の１つといってもよいだろう。年賀状の印刷でも、このテクニックは必須だ。
Google DocsにはAccessに相当するデータベースはないが、Spreadsheetがあり、これで十分だ。しかし、Spreadsheetとしてオフラインのアプリケーションからも使えるようになって欲しい。別にGearsで動作して欲しいという意味ではなく（もちろんその方がよいが）、オンラインの状態で使えればよい。
ODBCからSpreadsheetを使えるなら、データをクラウドへ移すことができる。マクロを含むWordを、そのままDocsに保管し、必要に応じてダウンロードして使えばよい。
ODBCからSpreadsheetが使えるなら、JDBCでも使えるようにして欲しい。両方共ドライバを用意するだけでよい。

ニフティクラウド

ニフティがクラウドを始めたようだ。Amazon EC2タイプのクラウドだが、EC2の欠点を補う工夫がなされている。
仮想マシン自体はEC2より貧弱だ。メモリは512MB、ディスクは30GBしかない。EC2の1GB、160GBに比べるとかなり小さい。しかし、実用上の問題はないだろう。
料金は１時間あたり12.6円/hとのことだが、円高の今ではEC2より高い。なぜ10円にできなかったのか。しかし、月額料金や待機状態料金5.25円/hも容易されている。待機状態でも課金されるということは、待機状態のまま残しておけるということだ。EC2ではS3に保存するが、これには別途課金される。サービスが統合されているともいえる。
トラフィックには15.75円/GB課金される。価格が高いのはCPUよりネットワークがネックだということだろう。トラフィック課金がなければ、クラウドはホスティングサービスとしても最高のものになる。しかし、残念ながら現状ではコスト的にはホスティングサービスの方が有利だ。なお、通信性能に関しては、利用者が日本企業なら、欧米のデータセンターを使用するEC2より応答が早いかもしれない。
サーバOSは代表的なものを揃えているが、Windows Serverをサポートしているなら日本語版もあるとよいと思う。おそらく主な市場は日本だろうから、日本語版のサポートは当然だろう。もっともサーバOSで言語に依存することは少ないとは思う。特にShift JIS問題があるので、日本語版は鬼門かもしれない。
また支払い方法も請求書払いなのがよい。故人が支払うならクレジットでよいが、仕事で支払うなら請求書でないと都合が悪い。
次のステップは、さらなるサーバOSのサポートと、そのカスタマイズだろう。

Google Docsの保存形式

Google Docsでどんなファイルでも保存できるようになった。
これによって従来のファイル形式との非互換性が問題になる。
つまり、.docファイルは変換されるが、そうでないワープロファイルは変換されず保存される。閲覧はできないが倉庫としては役立つ。
逆にいえば、.docファイルは正確に保管することができない。
この矛盾を解消するようなオプションが欲しい。
一番簡単な解決方法は常にzipに圧縮して保管することだ。

後で気づいたが、ちゃんとオプションが存在した。最初からあったか？
気づかなかったので、よくわからないが、これで安心してストレージとして使用できる。
しかも、単にファイルが有るとわかるだけでなく、プレビューを見ることができる。これはPDFファイルに変換されて見えるようだ。PDFと同じように操作できる。

Modular Data Centerのコア数

Modular Data Center(MDC)は、コンテナ型データセンターともいわれる。現在モジュールとして最も注目されているのがコンテナだからだ。
このコンテナは一般的に20フィートの大きさがある。40Uのラックが15個格納できるらしい。これが平均的なMDCの仕様のようだ。
これからMDCの計算パワーを算出してみよう。本当の計算パワーはCPUに依存するが、ここではコア数を求めることにする。
古典的なサーバは1Uあたり1台なので、40Uなら40台になる。ここではUPSなど一切無視だ。
しかし、ブレードサーバを使えば、もう少し集積度を上げることができる。代表的なブレードサーバでは7Uあたり14ブレードだ。40Uの中35Uをブレードサーバにすれば、70ブレードまで実装できる。ここではブロードの発熱量など一切無視だ。
残りの5UはUPSや従来型サーバが入るだろう。これらは端数として無視する。
すると、70 blades/rack * 15 rack = 1050 bladesになる。
ブレードが将来Core i5/i7を採用すれば、ブレードあたり4コアになるので、4200 coresになる。2 CPU/bladeも珍しくはないので、8400 coresも可能かもしれない。
また、42Uラックを用いて、20 blades/3Uのブレードサーバを採用すれば、280 blades/rackになり、15ラックで4200 blades、Core i5/i7なら16800 coresだ。しかもCore i7なら並列度（スレッド数）で33600にも達する。これは20年くらい前のスパコンに匹敵する数だ。
しかし、実際にはこれほどたくさん実装することはできないだろう。最大の課題は熱交換だろう。

自治体クラウドは中途半端

霞ヶ関クラウドに対向してか、自治体クラウドの立ち上げが活発だ。しかし、自治体クラウドという発想自体が正解とは言えない。
クラウドにはパブリックとプライベートがある。個人情報を扱う自治体クラウドがパブリックとなる可能性は低い。それができるなら、住基ネットはもっとまともになっていただろう。
自治体クラウドをプライベートクラウドとして実現しても、サーバ数の削減など導入コストを削減する微々たる効果しか期待できない。もしパブリッククラウドで作ろうという思い切った決断ができていれば、もっとコストダウンできたろう。
そこで、他の自治体と経費を分担するためにシステムを提供する自治体が増えている。このような拡大は県境を超えることはまずないだろう。
しかし、県が主導で開発したクラウドを県内の市町村が利用すれば、市町村にとっては大きな節約になる。決して悪いことではない。単に中途半端なだけだ。
本来は国家レベルでクラウドを開発するのが理想だ。それに比べるとスケールメリットが小さい。しかし、このようなシステムの移行は段階的に行う方が無難でもある。その意味では方向性は間違っていない。
問題は、複数の異なるクラウドを統合する次のステップだ。かなり大掛かりなプロジェクトになりそうだ。

Google Docsの容量

Google Docsで任意のファイルを保存できるようになった。このタイミングでの、この変更は、個人的にとても嬉しい。というのは、GoogleとMicrosoftのどちらのサービスを導入するべきか、検討している最中だったからだ。実際には、Googleに決めていたのだが、MicrosoftのSkyDriveは捨てがたいサービスだった。しかし、この変更でGoogle Docsが遜色ないことが示された。しかも、ファイルシステムのモデルとしてはGoogle Docsの方が優れている。なぜなら、効率良く共有できるからだ。
同時にGoogle Docsの容量もわかるようになった。10GBらしい。私はすでに4GBを使っている。
SkyDriveの25GBに比べると見劣りするが、容量は将来的に増えるだろう。半分以下の容量だが、システムとしては優っていると思う。
今後はMicrosoftにもがんばってもらいたい。Microsoftの問題点は、不必要に装飾された画面デザインだろう。それが無駄になっているだけでなく、欠点にもなっている。ユーザ経験は大切だが、ネットブックには合わない。