2009年9月30日水曜日

Google Docsで計算式

ようやくGoogle Docsで計算式を使えるようになった。
TeXに準拠しているので、論文作成にも申し分ない。
もっともDocsに十分なスタイル機能がないために、そのまま論文作成には使えない。
しかし、式を含む文書をブログに添付するなどの用途として大いに利用できるだろう。
利用者は限られるが、必要な機能である。このような機能が充実するのは喜ばしい。
しかもインターン学生が作成したものだという。優秀な若手が育っているようだ。

点対称

iMOW!
osso
dqbp
zzz
huny ちょっと苦しい
x

CO2を25%削減する方法

鳩山総理は2020年までにCO2を1990年比25%削減すると宣言した。他国も真剣に取り組むならという条件付きだが。
この目標が高いという説もある。確かに6%すら削減できていない状況を考慮すると高い目標には違いない。
しかし、不可能な目標でもない。このようなときは困難という。
不可能でない理由は技術的には可能だからだ。しかし、その技術を普及させるだけの投資が必要だ。それには産業界と家庭の両方で達成しなければならず、それを促すだけの政治的な支援が必要だ。
必要な技術には、家庭用太陽光発電と燃料電池、ハイブリッド車ないし電気自動車などだ。他にもスマートグリッドなども望ましい。これらだけでも100%近く普及すれば十分だろう。
家庭の光熱費はすべて自然エネルギーでまかなう。
交通手段もすべて電気に変え、しかも電子力と自然エネルギーを主とする。電気にならない交通手段は飛行機ぐらいだ。そのうち電気飛行機について研究開発が必要になるだろう。もしかしたらホンダが既に開発しているかもしれない。電気で燃料をリサイクルした方が現実的かもしれない。
自然エネルギーの発生源は発電所より家庭が多くなる。スマートグリッドは家庭で発電した電力を再配分するためのしくみとなる。
いずれも今の時点では夢物語だが、不可能ではない。ただし、2020年に普及させるには2010年には技術が存在していなければならない。これらの技術のうちスマートグリッドは未だ遠い。これが最大のボトルネックだろう。

八ッ場ダム

なぜ「やんば」と読むのかわからない。変わった名前だ。しかし、今や多くの人に知られるようになり、政治的なシンボルになりつつある。
部外者の視点では無駄ならやめた方がよいと思う。しかし、関係者の視点では不都合があるのだろう。
まず、完成させた方が安いという意見がある。これに対しては2つの反論があった。1つは計画変更によるコスト増を考慮していないこと、2つ目は維持費のコストを無視していることだ。いずれも水道代で回収するのだろうが、その場合の水道代がいくらになるかはわかっていない。それを明らかにして判断する必要がある。その場合、利害関係者は水没地域の住民と水道利用者であり、日本全体ではない。おそらく地元住民に同情する人の中で自分がその経費を支払うことになると知っている人は多くないと思う。そのような人が実際に払う水道代を知ったときにも果して同情できるだろうか。
次に地元住民に対する補償は妥当か明らかでない。既に補償されていれば新たな補償は二重補償になる。もちろん計画延期に伴う物価変動は考慮してしかるべきだ。既に移転先を入手しているとも聞くと補償金は支払われているようにも思えるが、そうなら追加の補償に何の意味があるのかわからない。個々の補償金はプライバシーに属するが、全体の額は重要な政治指標であり、公開されるべきだろう。それによって平均がわかっても個別の金額がわかるわけではない。
これらの情報が公開され、それでも継続の方がよいと判断されれば、そのときは誰もが喜んで継続に賛成するだろう。

2009年9月29日火曜日

DS Phone

DSはもっとも普及しているコンピュータといってよい。一つの機種に限れば、これを超える携帯はないだろう。やがてiPhoneがDSを超える日がくるかもしれないが、そうなるとゲームが変わる。
任天堂もDSをWiFiから携帯に変える日を想定しているだろう。そのときどのようなDS Phoneが登場するのか予想するのも面白い。
任天堂のことだから全く違うインターフェースを採用するかもしれない。その場合DSという名前は使わないだろう。一番簡単なのはDSにデータ通信モジュールをつけることだ。手軽だが面白みがない。そこで、インターフェースが変わるとしたら、どうなるか考えたい。
Phoneの本道は音声だ。音声インターフェースに確信がないと面白くない。それこそ、Wearableに近いものが出てくるかもしれない。大胆に予想すれば、ヘッドセットに没入型でないHMDなどだろう。VRではなく、むしろARだろう。この方式だとWiiとも補完できる。WiFiはなくなるのでなく選択肢の一つになる。

2009年9月28日月曜日

つばさ

しばらく見なかったらNHKの「つばさ」が終わっていた。川越がらみで見ていたが、何を伝えたいのかさっぱりわからないドラマだった。案の定、視聴率は最低だったらしい。やっと埼玉に順番が回ってきて、それも川越だからと期待したが、最悪の結果になってしまった。何がしたかったのだろう。

Honda U3-X

ホンダが全方位に進める一輪車を開発した。これで完全にセグウェイを超えたことになる。やればできるとは思っていたが、実際にやった意義は小さくない。
一輪車にする必要があったかどうかは大いに疑問だが、全方位に低コストで進めるようにするためだろう。セグウェイと異なり座った姿勢で運転できるのもよい。これで安定し、楽に小回りがきく。問題は、手放しあるいは片手で運転できるかどうかだ。セグウェイは少なくとも片手で運転できる。
ホンダがなにもしなくてもセグウェイは終息しただろうが、これで決定的になったろう。ホンダがその気になればセグウェイの市場を継承できる。問題は、それほどの市場かどうかということだ。

政治制度

選挙の結果をみると間接民主制は必ずしも民意を反映しないように思える。別に民主党に意義があるわけではない。むしろ逆だ。しかし、選挙では争点があり、すべての政策が争点となるわけではない。そこに大きな問題がある。
争点がぼけるために仮説民主制では大雑把にしか民意を反映できない。より正確に民意を反映する必要がある。現在のインターネット技術は直接民主制を実現できる。もちろん課題は非常に多いが、少なくとも不可能とはいえなくなってきた。実際、国規模で直接民主制を実施している国もあり、それも徐々に増えると予想される。
ただし、直接民主制では相矛盾する政策が実施される可能性がある。そこが最大の課題だ。整合性は少数の専門家でなければチェックできない。その役割を持つのが議員だ。それゆえ議員は必要だ。ただし、いまほど多い必要はない。意志決定に必要な人数がいればよく、問題提起は国民自身がすればよい。
政治のスピードを上げるには国民自身が提言できなければならない。そのようなしくみとシステムを組み合わせると新しい時代がおぼろげながら見えてくるように思える。

イノベーションは逆三角形

フロンティアは常に広がる。よって、フロンティアは逆三角形の上辺に相当する。
限られた人金物でフロンティアを網羅することは次第に困難になる。そこで集中と選択が必要になる。
当たり前のことを指摘しているように思えるかもしれないが、よくフロンティアについて開設した図では、先端的なイメージから三角形の先端に例えられる。しかし、そのような先端は既に集中と選択が行われた結果であり、真のフロンティアではない。
別のイメージとしては、同心円の周辺と考えてもよい。逆三角形でも、ある程度の方向性を意図しているが、同心円では方向性がないので、もっともフロンティアの意味を表すのにふさわしい。

テープ/MD型ソリッドオーディオ

小ネタを一つ。
カーステレオにもソリッドオーディオが増えてきた。最近の機種では問題ないが、古い機種を買い換えずにソリッドオーディオを使いたいというニーズがある。そのようなニーズにはFMで飛ばす方法が主だが、プレイヤーを別途必要とする。
そこで、カセットテープやMDなどの疑似デバイスを用意してはどうかと思う。基本的には磁気ヘッダに情報を読み取らせることができればよいはずだ。これらのメディアは広く普及している(いつまで持つかわからないが)し、大きさもSDメモリを収納するのに十分だ。
電源は電池でもよいが、駆動部があるので発電できればなおよい。

2009年9月19日土曜日

SaaSとソフトウェアの生産性

日本のサービス業は生産性が低いという。ソフトウェア業界もサービス業に含まれるので、同様と言える。圧倒的な(人)物量にものをいわせるオフショア開発に対抗できないのは確かだが、日本自身の商習慣に問題もある。それはいわゆるシステムがカスタマイズなしに受け入れられないことだ。カスタマイズだけならまだしも、その都度再開発を行うようではコスト高になり、その結果生産性が低いと見なされるのも当然だ。しかし、これは開発業者の問題だけでなく、発注側の問題でもある。しかし、それも含めて開発側が対応しなければならない。
そのような背景の中でSaaSは有効な手法だ。パッケージソフトの開発は、それが汎用的なものでも専用であってもパッケージ数で開発費を回収する必要がある。特に特定向け専用システムのソフトは、ほぼその受注だけで開発費を回収する必要があるため、人月がそのまま経費となる。そのような支払いに応じられない発注主もいる。ほとんどすべての依頼者はコストダウンを望んでいる。そのような場合、専用ソフトの開発コストを改善する必要がある。
具体的には、専用ソフトといってもすべてが専用なのではなく再利用可能なコードが少なくない。しかし、専用ソフトで著作権が発注主に譲渡されると、容易に利用できない。著作権を開発側が保留すると、それを利益と見なされるため、すべての開発費を請求しにくい。そこで、SaaSのライセンス形態が解決の糸口になる。
SaaSでは、利用料という形で収入を得る。著作権はあくまで開発側が持つ。開発側は、仕様に応じたシステムを開発し、それを運用とともに提供する。導入費だけでなく運用費も請求する。開発経費が導入費だけでなく運用費にも分散できる点が大きい。
しかし、SaaSにも問題がある。大手開発業者は自前のSaaS環境を運用できても、中小開発業者には難しい。Amazonなどのクラウドを用いても、容易ではない。理由は、中小開発業者は開発に特化しており、運用のノウハウがほとんどないからだ。運用にも人月でコストがかかる。それだけのスタッフを常時雇用することがなかなかできない。
ソフトウェア会社は従来開発者を重視していたが、これからは運用者も重要になってくる。運用者を提供する人材派遣会社も必要になるだろう。

2009年9月17日木曜日

Webから考えるInternet 3.0

Internet 2.0は既に現在進行系なので、3.0について考えてみたい。
Web 2.0はユーザ参加だが、Internet 2.0はユーザ参加ではない。よって、Webの類推は当てはまらない。ちなみに、Web 3.0はSemantic Webだという話もあるが、それがInternet 3.0にはならないだろう。もっとも、多少なりとも知的にはなるだろう。
プロトコルから考えると、レガシーを切り捨てる方がよい。不適切なプロトコルが廃除されることは望ましい。
プロトコルではOSI参照モデルが使われるが、ほとんどがアプリケーション層なので、階層化の意味がない。3.0ではアプリケーション層を整理する必要があるだろう。
そこで、アプリケーション層の下にWeb層をおいた方がよいと思う。Web層はTCP/IPの代わりになる。ネットワーク全体がHTTP P2Pオーバーレイになる。現在の技術は十分それを可能にする。
ただし、この場合、HTTPは従来のものと多少異なるだろう。具体的にはUDPに相当する仕様を追加する必要があるだろう。いまでもHTTPは基本的にステートレスなので、難しくないだろう。

象の耳パン

秋葉原の駅前屋台で象の耳パンというものを食べた。私自身はグルメではないが、素直においしいと思ったので紹介する。
看板の世界初製法という言葉にひかれて興味本位で食べてみた。
食べ物にしても新しいものを作り出していくことは大変なことであり、意義深いことだと思う。それが、成功すれば何よりよい。あまり急速に発展させようとせずに地道に営業してほしいと思う。息の長い商品にしないと成功はしない。

2009年9月16日水曜日

ミニプロジェクタを集めてタイルディスプレイ

最近、タイルディスプレイの研究が盛んにおこなわれている。そこで、使えるかどうかわからないアイデアを1つ提供しよう。
タイルディスプレイは、高精度で手軽に臨場感を演出できるが、やはりフレームが気になる。シームレスな結合は技術的にもかなり難しい。
そこで、ミニプロジェクタを併用する方法が考えられないだろうか?
ミニプロジェクタは、まだまだ輝度が足りずに近距離で小さな画面しか投影できない。逆にいえば、たくさん集めれば高精度の画面をシームレスに構成できる可能性がある。
おそらくコスト的には通常のディスプレイを組み合わせたほうが安いだろう。例えば、32インチの液晶ディスプレイが10万円とすると、ミニディスプレイは5インチ2万円くらいなので70万円くらいになってしまう。ミニディスプレイの大型化、高精度化が進行すれば候補になり得るかもしれない。

2009年9月11日金曜日

Google Docs Batch Upload

欲しいプログラムが1つ手に入った。
Google Docsを利用している。また、SkyDriveなども使っている。どちらもアップロードが面倒臭い。SkyDriveはIEを使えば、ActiveXで便利にアップロードできる。しかし、Google Docsには解決策がなかった。それを可能にするのがGoogle Docs Batch Uploadだ。Javaで実装されているので、マシンを選ばない。
まだ、使いこなしていないが、フォルダー全体をアップロードできるらしい。しかし、そのときサブフォルダーのラベルまで作ってくれるのかどうか試していない。
少し注文をつけると、ダウンロードもできるようにしてほしい。実は、Google DocsやSkyDriveはダウンロードが面倒だ。Zipでまとめてダウンロードできればよいが、そのような機能はない。他のツールで実現することもできるだろうが、なるべくツールは少なくしたい。今後に期待したい。

Googleグループにサブグループを

Googleグループは便利なサービスだ。これでメーリングリストはすべてまかなえる。
しかし、グループを単なるメーリングリストに留めておくのはもったいない。グループにアクセス権を関連付ければよりよい共有が可能になる。ドキュメントには一部グループによる共有が実現されている。しかし、全部ではない。この問題は以前にも投稿したので、ここでやめておく。
今回はメーリングリストとしてもっと便利に使うにはどうすべきか考える。メーリングリストも組織であり、組織を運営するには管理が必要だ。その管理人は組織の一部であり、サブグループである。現在のグループには、このような階層関係がサポートされていない。
もっともこれには理由もある。組織の関係は階層だけではないので、サポートするだけのニーズがあるか確信がもてない。
階層関係を導入する方法がトップダウンのアプローチだとすれば、既存グループを組み合わせる方法はボトムアップのアプローチだといえる。ボトムアップの方が柔軟性があり、汎用性も高い。
ボトムアップ方式でサブグループを実現したときの利用イメージを考える。相互に関係を設定する必要がある。例えば、スーパーグループユーザはサブグループの記事を閲覧できる。逆に、スーパーグループにオプション名を付けて投稿するとサブグループに割り振られるように設定する。スーパーグループからは自身の管理用投稿とサブグループの記事をディスカッションを区別して閲覧する。

埋蔵金発掘サイト

本当の埋蔵金のことではない。民主党の公約を実現するために必要な税金の節約のことだ。
民主党政権が発足しても、それが国民の支持を受け続けることができるかどうかは大きな問題だ。自民党の負けっぷりが酷かったため、民主党には余裕が生まれているかもしれないが、かつての小泉人気にあやかった自民党がどうなっているかを考えれば、うかうかしていられないはずだ。
そのためには政策を実現して見せる必要がある。すべての政策がよいとは限らないが、本気で実現するつもりであることを示す必要があるだろう。そのためには財源が必要になる。
選挙中に自民党からも指摘されたように、今の公約は砂上の楼閣だ。すべては財源の有無にかかっている。
しかし、既得権の力は強く、抵抗も大きい。国民性からもハードランニングよりソフトランニングを好む。
必然的に財源確保は難しい。そこで途中経過を示す必要があるだろう。埋蔵金発掘サイトとは借金時計のように無駄な税金使用を指摘し、その合計を公開するサイトだ。
このようなサイトを用意して時間を稼ぐ必要があるだろう。

2009年9月8日火曜日

IPhoneアプリをPCに

iPhoneアプリは、現在もっとも開発が活発なソフトウェア市場かもしれない。そこでは優秀なソフトが数多く開発されており、そのようなiPhoneアプリをPCでも利用したいと思う人は少なくないだろう。なんと言っても世の中の大半のPCはWindowsなのだ。
PCでiPhoneアプリを開発するツールなどはそろってきた。開発面では問題がなくなってきているが、しかし利用面ではまだまだだ。
本質的な問題点はマルチタッチというiPhone独自のインターフェースにある。iPhoneアプリは、このインターフェースを生かした設計がなされている。しかし、そのように作成してしまうとマルチタッチでないPCでは使えない。
キーボードと組み合わせてエミュレーションする方法も考えられなくはない。それでもOSへの設定が必要だ。やがて、Windowsにもマルチタッチが導入され、APIが整理されるだろう。それまで待つと、現在の勢いを失ってしまうかもしれない。
現実的な対応は、マルチタッチでなくても使えるようにiPhoneアプリを設計することだろう。
もし、iPhoneアプリがPCで動けば、それこそ小型ネットブックの時代が到来するかもしれない。

2009年9月4日金曜日

Chrome OS

Chrome OSについてはいつかコメントしたいと思っていたが、その正体がつかめずにコメントを控えていた。いまでも、その正体を正確に把握しているわけではない。今回は、Chrome OSの正体を想像してみるという企画だ。
Chrome OSは、その名の通りGoogleのブラウザであるChromeをOSにしたものだ。ネットブックなどインターネットに常時接続する用途の端末に特化している。本来ブラウザであるChromeをベースにしているので基本的にはWebしかアプリケーションはない。しかし、今日ではWeb上にあらゆるアプリケーションが移植されているので、Webだけで十分という判断だろう。
同じような発想のOSにWeb OSがある。Web OSにはいくつかあるが、いずれもブラウザの中だけで動作する。しかし、既存Web OSでは、ブラウザを変更しないため、ストレージはサーバ側にある。サーバ側にフルセットのプラットフォームを用意しなければならない。また、Web APIを用いてアプリケーションをWeb OS用に修正しなければならない。この2つの問題点によりなかなか普及しない。
実は、Web OS以前にもMicrosoftに挑戦し敗れたOSがあった。それはJava OSだ。Java OSではJVMさえ動作すればよい。しかし、Javaアプリしか動作せず、Javaへの移植も進まなかったため失敗に終わった。Web OSは同じ失敗を繰り返しているともいえる。少しはましといえるのは、Javaアプリに対してWebアプリの方が種類が多く、少なくともブラウザ機能はあるため、全くアプリがないという状況ではないことだ。
もしChrome OSが単なるWeb OSだとすればGoogleといえども失敗すると断言できる。
しかし、私の考えではChrome OSはWeb OSではない。ある意味ではWeb OSと近いが発想はまるで逆だと思う。Web OSがサーバ側の資源を使うのに対して、Chrome OSはクライアント側の資源を使うはずだ。それこそが勝利のカギと言える。
Chrome OSの正体を予想すると、それはおそらくPOSIX互換ないし代替のアドオンAPIだろう。これによりChromeアドインおよびJavaScriptアプリからPCの資源へ直接アクセスする道を開く。
代表的なデバイスに対する標準的なデバイスドライバを備え、しかもインターネットから常時最新のドライバをダウンロードして更新するのだろう。そのためには少なくともネットワークデバイスのドライバだけでは汎用的でなければならない。このあたりのドライバの整理はAndroidで培ったものだろう。Androidが十分軽量にできたため、ブラウザに梱包が可能となったという言い方もできるのかもしれない。
しかし、OSの機能にはデバイスドライバだけでは不十分なものもある。例えば、ファイルシステムだ。ディスクドライバだけではなく、ファイルシステム(サーバ)も必要となる。これもフォーマットを限定することでコンパクトに実現できたのだろう。そのため大したファイルシステムは期待できない。exFATだけしかサポートしていなくても驚くには値しない。

ディスクとファイルにおけるアクセスの違い

ディスクとファイルは明らかに違うので、それを比較する方がおかしいと思う人も多いだろう。
ここでいう、ディスクは仮想ディスクであり、ファイルで実現されたもののことだ。
仮想ディスクは特定の形式のファイルであるが、ここでは形式だけでなくそのアクセス方法に注目して違いを論じる。
実はこれは失敗談でもある。あるシステムを設計しているとき、その違いを意識せずに同じように設計したところ、後で再設計するはめになった。
ファイル、それもオープンされたファイルはファイルポインタで指定された場所を中心にアクセスされる。基本的にファイルポインタは一つであり、それゆえに逐次アクセスとなる。それを並行アクセスしなければならないときには、かなり工夫を要する。
一方、ディスクはCPUやDMAなど複数の手段で並行にアクセスされることを想定したデバイスであるから、本質的に並行アクセスである。ファイルがseekとread/writeを分割しているのに対して、ディスクではseekとread/writeは不可分だ。
この単純なことに気付かずファイルのようなディスクを設計してしまったことがあった。3世代前の設計の話だ。

紙の磁気カード

最近でこそICカードが多くなってきたが、磁気カードにはまだまだ便利な用途を考えられる。
その磁気カードを身近に使えるようにするには、磁気カードを自作できるようにすることだ。
信頼性の高いサービスはICカードへまかせ、信頼性が低くてもよいサービスに安価な磁気カードを使えばよい。
そこで、あらかじめ磁気ストライプを印刷したプリンター用紙があるとよい。カード用にミシン目を入れてあるとなおよい。
このカードを読み書きする装置も必要だ。これは既製品でよい。
場合によっては新しい独自企画にすることも考えられるが、かえってコスト増になりかねない。

電話の公平な受信

チケットの予約など電話をかけてもなかなか繋がらないことがある。そのようなとき長く待たされるが、先に待っている人から順につながるなら我慢のしようもある。しかし、全くの運に任され、後からかけた人が先につながるようでは不満がつのる。このような待ち時間の公平さが電話でどれだけ考慮されているのか疑問に感じる。NGNとなり、なお一層不公平になるようでは困る。

Googleカレンダーのトラブル

Gmail障害があったばかりだが、今度はGoogleカレンダーの障害が起きたようだ。
この記事執筆時では回復していない。
後日原因が発表されるだろうが、おそらくGmailと似たような理由ではないかと想像する。
つまり、Googleの予想を超えて利用者が多いと言うことだ。
採算性を考慮すれば、ソフトバンクのようにサービスの質を落とすか制限することも考えられるが、Googleはそうしないと信頼している。逆に、その信頼を損なうようなら、Googleの将来は見えたも同然だ。次第にユーザーが離れていくだろう。そうなれば歯止めはきかない。
こうしたトラブルの一つ一つがGoogleにとってもユーザにとっても試金石となる。

もうひとつ原因が考えられる。数日前からGoogle Calendar Syncが失敗することがあった。大幅な改訂がなされた可能性がある。そのバグのせいかもしれない。