MacとGmail

MacでGmailを呼んでいると「あ」の字が文字化けしていることがある。
Gmail以外のメーラーで処理されたメールが混じってしまうためか？
それにしてもJISで交換できなければ不便だ。
これもバグと言ってよいのだろうか？

ブログに、その日の天気を

ブログに、その日の天気を付けることができたら、ますます日記風になってよいだろう。
どうせブログなら、自分で天気を調べて書くより自動的に天気情報が添付された方がよい。
ただし、いくつか問題がある。
天気は時間にも依存するが、場所にも依存する。時間は国内なら一定だが、場所はGPSでもなければわからない。つまり、自動と言っても半自動でなければならない。
Bloggerの編集ボタンに時刻や天気などの定型句を挿入するボタンがあればうれしい。

iPhoneのカレンダー

iPhoneを買ってしまった。まだ、手放しで「よい」とも言えないし、かといってそれほど悪くもない。
当初心配していたバッテリーの問題は、液晶輝度を最低にすることで十分実用的な駆動時間が得られた。iPod touchに比べてスピーカーがついているところがよい。もちろん、カメラやGPSもあるが、これらはまだ使いこなせていない。デジカメをiPhoneで代用する気にはなれない。
決め手はソフトだろう。ソフトの期待感ではAndroidの方が上かもしれないが、登場まで待てなかった。Windows Mobileのソフトは、自分の機種で動くものが少ないので、ほとんど意味がない。
また、単純に画面の大きさもよい。最近、視力が落ちてきている（老眼か？）ので、小さな画面は厳しい。HTC Touch Proを選ばなかった理由の一つだ。
iPhoneでメールやカレンダーをGoogleに統一できると思っていたのだが、どうもうまくいかない。メールはSMSが別になる。海外でiPhoneでメールを読み書きしたときの請求書が今から怖い。
日本でもカレンダーが問題だ。Outlook経由で同期するのは一般的なWindows Mobile PDAと同じだが、iPhoneなら直接Googleカレンダーをアクセスできる。しかし、iPhoneからGoogleカレンダーに追加した予定がリアルタイムに反映されない。PCで確認すれば、新しい予定が追加されていることがわかる。しかし、その場でiPhoneから見る限りは全く予定が追加されていない。これはどうしたことだろう。バグとしか思えない。
また、予定を削除する方法がわからない。単なるビューアなら予定を追加する機能がある理由がわからないし、せっかくの通信機能も意味がない。
このような細かな問題はあるが、GoogleのiPhone対応は確実に進んでいるので、安心して対応を待つことができる。

うまいエスプレッソを缶コーヒーで

缶コーヒーの技術力が停滞しているように思える。
近年、缶コーヒーの品質は急速に高まり、過剰に思える製法まで登場した。しかし、最近の缶コーヒーは、そのアピールに比べて実際の味が追いついていない。単なる広告倒れのものが多い。
特に、缶コーヒーにはミルクと砂糖が入っているものが多く、食事と一緒には飲みにくい。また、食後の一杯にも適さない。
無糖やブラックのコーヒーもあるが、味が薄い。
私が求めたいのはスターバックス並みのエスプレッソだ。缶コーヒーで、そこまで濃いブラックは多分まだない。保存などの技術が伴わないのか、それともコストが見合わないのか、よくわからない。しかし、後者なら200〜300円で売ればよいのだから、技術の問題だろう。
今コーヒーメーカーが真っ先に開発品しなければならない課題だと思う。

意味振り英文原書の出版

出版業界では古典小説のリニューアルが盛んに行われている。その過程で文字を大きくしたり、ふりがなを振ったりしているらしい。
出版におけるもう１つの問題は、翻訳の遅さだろう。海外の優秀なコンテンツを日本語で読むのに時間がかかる。これは残念だ。
しかし、英文原書を読破する気力もない。
しかし、よく考えてみると、日本人は義務教育で長く英語を学んでいるので、少なくとも読む力はそれなりにあるはずだ。しかし、習っていない単語が出るとつかえ、いちいち辞書を引くのが面倒くさい。英語学習の教材の中には、わかりにくい単語の意味を示しているものもある。つまり、その程度のことがなされていれば、ある程度読むことができると言うことだ。
そこで、英文の原書に、文中のわかりにくい単語の意味をふりがなのように振った疑似翻訳書を出すことを提案したい。完全な翻訳ではないので、訳者は不要だ。極端な話、機械的に単語の意味を示すだけでもよい。その結果、出版のスピードが高まり、新たな市場が形成され、出版社の利幅も大きくなる。
このような出版（意味振り英文原書と名付けた）は、本格的な翻訳が出るまでのつなぎの意味もある。良書であれば２つとも買うだろう。また、翻訳すべきかどうかの経営判断も下しやすい。

Google DocsにBLOBファイルを

BLOBとは、Binary Large OBject、要するに大きなデータファイルのことだ。
Google Docsは特定形式のファイルしか保管できない。それが利点でもあり、欠点でもある。
MicrosoftのSkyDriveは25GBもの任意のデータを保管できる。しかも、ファイルのサイズの上限は50MBだ。
Google DocsとSkyDriveは似て異なるものだが、あえて比較するとすれば、この２つを比較せざるを得ない。
そして比較すれば、ファイル形式とサイズの点でGoogle Docsが不利になる。
しかし、Google DocsはSkyDriveより便利な点も多い。特にグループによるファイルの共有機能などはSkyDriveにはまねできないだろう。
だとすれば、欠点を補うだけで優位に立てる。そして、欠点を補う簡単な方法はBLOB形式をサポートすることだ。

好況時における不況の予測

不況が始まってからあわてても後の祭りといえる。
好況時に不況に備えることこそリスク管理といえる。
そのためには好況時に次の不況を予測する必要がある。
サブプライムにしろバブルであると予測した人が皆無とは思えない。しかし、好況時には不吉な予言は戯れ言としか受け取られない。いつの世でも予言者は孤独だ。
しかし、本気でなくても多少の関心をもって予言を受け入れていれば、心の準備はできたかもしれない。また、まじめに受け取っていれば、対策も万全にできたかもしれない。
好況時には万全の対策のためのかかる多大なコストもある程度受け入れることができるはずだ。しかし、利益を減らしてまで保険をかけることはなかなかしないものだ。１つには保険が予測を外せば単なる掛け捨てになってしまうからだろう。つまり、せっかくの利益をそのまま無駄にしてしまうことになる。結局は予言の確度の問題だ。
また、誰が不況の対策を考えるかも問題だ。
企業が従業員を守るなら、利益を留保していてもよいが、現代ではそれほど高い雇用意識を事業者も労働者も持っていないように思える。それならば利益を労働者に還元しておき、自衛させた方がよいが、それほど高い危機感を持った労働者というのも少ない。
企業でも労働者でもだめなら国に税金として納めておき、セーフティネットを手厚くしてもらうという方法があるが、昨今では国もあまり信用できない。しかし、信用しない限り話は進まないのだから、信用せざるを得ない。あるいはオンブズマンなどの監視を強めるしかない。

入試問題データベース

入試のシーズンは終わりつつあるが、いつも入試の頃になると入試問題のデータベースがあればよいのにと思う。
入試問題は、それ自体が赤本などとして出版されていることから著作物なのだろう。もっとも、国語などは他の著作を引用しているが。国語の現代文も、音楽のクラシックに相当する例文があればよいのにとも思う。もっとも古典では意味がないが。
入試データベースがあれば、受験生も出題者も役に立つ。出題者の立場に立てば、同じ問題を出題していないというチェックは大きな負担だろう。それを簡単に検索できるメリットは大きい。
おそらく有料のデータベースは存在していると思う。それらしいサイトがある。著作物だから難しいとは思うが、できれば無料のデータベースとして公開して欲しいものだ。
もし、有料でなければ運営できないのだとすれば、AdSenseなどを使えばよい。受験産業からいくらでも広告が取れるだろう。

累進法による日時の表現

日時を表現するとき、それぞれの単位の最大値に合わせた累進法を組み合わせることで簡潔に表現できる。
例えば、月は１月から１２月までなので１桁の16進数(1-C)で表せる。12進数0-Bでもよい。
次に、日は１日から３１日までなので１桁の32進数で表せる。正確には31進数でよい。10進数より大きな累進法はアルファベットで表すことが多い。数字10文字とアルファベット26文字を組み合わせると36進数まで表せる。32進数は0-9,A-J,K-S,Tで表す。
時間も24進数0-9,A-J,K-Nで表せる。
分、秒は60進数であるからアルファベットでは足りない。しかし、アルファベットには大文字と小文字があるので、これを区別すれば10+26+26=62進数まで表現できる。ASCII符号の順に、数字、英大文字、英子文字の順に大きくなるとする。すると60進数は0-9,A-Z,a-xで表せる。
ただし、年は無限に大きくなるので累進法の拡張でもうまく表現できない。
いうまでもないが、このような英字を用いた累進表現は計算機屋でなければ使わないので、一般的に広まることはないだろう。あえて日時を簡易的に符号化するときにしか使わないかもしれない。

温暖化を望む国

地球温暖化は世界規模の問題だ。温暖化を防ぐためには、世界中の誰もがCO2の排出を抑制しなければならない。しかし、誰もが一様に抑制できるわけではない。
地球には、暑い国もあれば寒い国もある。寒い国の人にとっては、正直な話、多少温暖化してくれた方がありがたいだろう。しかし、暑い国の人にとっては、そのわずかな気温上昇でさえ致命的（本当に生き死にの問題となると言うより深刻な被害が出るという意味）となる。
寒い国とは高緯度の国だ。先進国と言われる国は、ほとんどすべて高緯度にある。よって、先進国にとっては温暖化した方がエネルギーを節約できる可能性がある。一般に、冷房より暖房の方がエネルギー消費が大きいという。それならばなおのこと平均気温が高いほど暖房を減らすことができる。
また、低緯度の国には発展途上国が多い。これらの国は、これから経済発展をするので、エネルギー消費を押さえるより、消費して経済を発展させたいところだ。
つまり、どちらの立場でも温暖化を真剣に防ごうという気持ちにはなれないということだ。
思うに温暖化防止には２つの壁がある。１つは国の壁、もう１つは個人の壁だ。
上記の国によるエゴが国の壁だとすれば、個人の壁は個々の人間の心構えにある。
温暖化取引が実際に有効かどうかはわからないし、第２のサブプライム問題をはらんでいるようにも思える。しかし、消極的な国や個人に一定の方向性を与える上で経済ほど強力なものはない。だから全面的に認めるというわけではないが、うまい方法ではあるだろう。逆に言えば、他に手がないという言い方もできる。

Linuxはインスタントと仮想化に特化すればよい

Linuxがデスクトップに普及しない。一方で、サーバOSとしては検討しているが、Windows Serverの攻勢に有効な手がない。
デスクトップとしてのLinuxは、起動の早さを生かしてインスタントOSとなるのがよいだろう。もっともインスタントOSになるには代表的なディストリビューションでさえまだ重い。もっと軽くなる必要がある。要は、そのPCの仕様でだけ起動すればよいのだ。
また、デスクトップでも有効だが、サーバでは仮想化の機能が不可欠だ。LinuxはVMMのDomain 0を目指すべきだろう。あるいは、少なくともそのようなディストリビューションが選択肢にあってもよいはずだ。仮想化では、もちろんDomain 0以外のOSも動作する。Windowsだって動かせる。しかし、いつもWindowsを動かす必要はない。
起動と仮想を制覇すれば、Windowsを包囲することができる。逆に、Windowsとしては、その包囲網を突破する製品を開発する必要がある。

USB内蔵スロットでPCの差別化を

今のPCには特徴がない。あるとしてもわずかだ。特徴のないPCはコスト戦略しかとれずに、採算が悪い。PCに付加価値を与えることができなければ、PCの製造そのものが困難となる。すでにPC製造から撤退した日本メーカーも多い。
今は、不況である。不況の時にはネットブックなど低価格のものしか売れない。事実、ネットブックは人気がある。しかし、軽自動車しか売れない自動車業界が急速に業績を悪化させていることでもわかるように、コスト戦略はすべての企業にとって有効な戦略ではない。
不況の時代には複合製品が売れるだろう。つまり1.5倍の価格で２つの機能を買えれば、お手軽感が高まるという理屈だ。数ある複合商品の中でもPCは最も機能を複合かさせるのに適した商品といえる。HWコストを最小化し、SWでまかなうことができるからだ。
しかし、そこで冒頭に述べたような問題が生じる。
PCに複合的な機能を追加し、付加価値を高める戦略はそれなりに有効だろう。しかし、高いコストで高い価値を付加しても収益は伸びない。低いコストで価値を付加できなければならない。日本のPCはそれに失敗していると思う。
それでは、どうすればよいか？１つの方法はUSBデバイスを活用することだろう。ワンセグ、地デジ、ラジオなどほとんどのデバイスはUSBで提供される。しかし、外付けは非常に使いづらい。また、インストールの手間がかかる。このような商品形態では家電として失格だ。
そこで、USBを内蔵できるようにし、そのデバイスを用いるSWをプリインストールする。これだけでPCは全く異なる商品に変化する。OSもWindowsでなくてもよい。

大学野球をYouTubeに

当然だが、プロ野球は商業化している。しかも、収入の大半はTV中継から得られる。
一方で、楽天・ソフトバンクなどIT企業はコンテンツを求めてプロ野球球団を求めている。
しかし、野球で商業化されていないコンテンツはまだまだ多い。プロ野球と高校野球以外はほとんど手つかずだといえるだろう。
高校野球はのぞいて、それ以外のアマチュア野球は営業目的ではないので、その中継を無料で行ってもよいはずだ。むしろ、支持層の拡大のために積極的に行うべきだろう。
だとすれば、YouTubeなどの動画共有サービスを用いて中継（実際にはオンデマンド）するのがよいだろう。
このような中継を最初に手がけるには大学野球がよいように思われる。ある程度の視聴者が見込めて、ある程度のコストをかけることが許されるのは、他になかなかないだろう。YouTubeならコストはGoogleのターゲッティング広告で回収できるかもしれない。

JavaScriptはOOPのSchemeになれるか

Schemeという言語がある。Lispの一種だが、今では最もよく使われるLispといってもよいかもしれない。
Schemeの特徴は、単純さにある。単純な概念の組み合わせで、あらゆる機能を実現する。Schemeでは必要な機能をプログラマー自身で拡張できる。そのため、最初からすべての機能を提供する必要がないというわけだ。
単純な仕様の組み合わせで複雑な仕様を構成するという意味では、JavaScriptも同様かもしれない。元々のJavaScriptは決して複雑な仕様ではない。しかし、いまや様々なライブラリの登場により、高度なことも比較的容易に実現できてしまうようになった。
しかし、JavaScriptにはSchemeほど徹底した単純化の思想はなさそうだ。しかし、Schemeの拡張性をJavaScriptでも実現できれば、JavaScriptのエンジンを単純な機能の高速化に振り向け、高機能化をライブラリに任せることができる。これには大きな利点がある。
S式のないJavaScriptだが、JSONがある。JSONをS式なみに一般化できれば（それは比較的容易に思えるが）このアイデアは容易に実現できる。
まずは、JavaScriptによるeval(JSON)インタプリタが欲しいところだ。

iPod classicドック付きPC

PCにはHDDが内蔵されている。最近ではSSDも増えてきた。ネットブックはSSDを採用した者も多い。しかし、SSDを用いたネットブックは容量が不足しがちだ。
一方、iPodにはHDDを採用したclassicがある。iPodシリーズの中では最強ともいえる機種だが、HDDの重さのためか、最近ではnanoやtouchの方が売れているだろう。
SSDネットブックの容量不足をiPod classicで解消することを考えてみる。
iPod classicをUSBでPCと接続するのでは、安定せずに不便だ。PC本体にドックを付け、直接接続し、しかも固定できるようにしたい。
次の問題は、HDDのフォーマットだ。iPod classicはFATでフォーマットされている。そのため、ファイルの最大サイズは4GBに限られる。もっともこれはほとんどのUSBメモリでも同様だ。これが我慢できるなら最大の問題点を克服できたことになる。
もっともよいのはiPod側がexFATなどに変更し、ファイルの最大サイズの上限を引き上げてくれることだろう。iPodでもDVD並のコンテンツをみたいという要求はあるだろうから、将来的には大いに期待できるだろう。しかし、それまでは難しいかもしれない。

Google Mapカーナビ

月並みなアイデアだが、Google Mapカーナビがあればよいと思う。そうすれば常に最新の道路地図を確認できる。
しかし、Google Mapの地図はカーナビとしては不十分かもしれない。というのは、カーナビの地図には一方通行などの道路情報が付随していなければならないからだ。
まずは、Google Mapでドライブナビゲーションを実現し、その次のステップとして単純な通信機能を備えたGoogle Mapビューアによるカーナビが実現する。
そのためには地図の高機能化が必要だろう。

自己フォローしておく。
あまり意識して使っていなかったので気づかなかったが、Google Mapで「車で行く」をクリックすると運転ルートが表示される。ただし、まだ主要２点間のルートだけに見える。カーナビのように任意の２点で可能になるには、まだ少し時間がかかりそうだ。

ベロタクシー

自転車通勤はエコになる。
しかし、車に比べると自転車は不便なこともある。一番の不便は雨に濡れることだろう。
ベロタクシーという三輪車には、屋根があり、雨でも乗れる。自転車に比べれば車体も重いが、電動アシストもある。
実際に漕いだことはないので、どれだけ乗りやすいのかわからない。しかし、元々のベロタクシーはその名の通りタクシーなので複数人が乗れるが、それを１人乗りに小型化・軽量化すればもっと乗りやすくなるだろう。宅配バイク程度になるかもしれない。
そうなれば、近距離通勤には十分使えるのではないだろうか。

納本制度の電子化

国立国会図書館は出版された書籍を保管している。これが納本制度だ。
しかし、紙の書籍を保管する意義は年々薄れている。歴史的な意味を持つ書籍以外は電子的に保管するべきだろう。
既存書籍の電子化は大きな問題だ。逆に書籍の電子データを保管するようにすればよい。
Googleの社是は世界中の情報を検索可能にすることだという。だとすれば、国立国会図書館の社是？は日本中の情報を検索可能にすることだと言ってもよいだろう。しかし、それにはほど遠い有様だ。
また、ゲームなどのソフトウェアも書籍に含まれる。しかし、これらのソフトウェアはそれ自体では使えず、HWを必要とする。しかし、HWを長期間保管することは難しい。全く使わなくてもそのうち故障してしまう。これを避けるにはゲーム機自体のシミュレータを更新していく必要がある。このようなことまで含めて情報を収集していかなければ、あまり意味がない。

失業リスクに対する自己防衛

現在の不況下では、どの企業も倒産の可能性がある。そのような時代の中で、個人が生き抜くためには、失業リスクを管理する必要がある。失業してしまったあとでは、もう遅い。失業する前に失業リスクを低減する対策が必要だ。
最上の策は、会社の業績を上げることだ。しかし、そのような一般論は存在しない。よって、失業が避けられないものとして、失業するまでに、どのような準備をしておくかを検討する。
参考になるのは、コラム「暮らしに潜むリスク」第51回(http://www.nikkeibp.co.jp/sj/2/column/ca/51/index.html)だろう。これによると緊急予備資金が必要だという。全く同感だ。就職した者は誰でも緊急予備資金を蓄えるまでは生活レベルを上げるべきではない。
緊急予備資金は、再就職するまでの生活資金と言える。再就職までの期間は６か月といわれるが、１年は見積もるべきだと思う。なぜなら、６か月では転職に必要なスキルを身につけることはできないからだ。不況下では同じ職種への転職は、少なくとも全員は無理だ。
失業保険では、十分賄えない。上記コラムによると、４０歳で給与が３５万なら、１６万が６か月支給されることになる。それでも、年収の3/4しか賄えない。
言い換えれば、まず年収分の貯蓄が必要だ。そして、失業保険は転職スキルの向上に当てるべきだ。転職スキルに関しては、通信講座などが安い。しかし、通信講座程度のスキルでは、競争相手も多く、決め手とはならないだろう。それ以上のスキルアップを行うためには、かなりの費用が発生する。
また、このような資金はある程度長期保持することになるが、必要な時に換金できなければならない。おそらく定額貯金などがよいだろう。緊急予備資金をマイホームの頭金に当ててしまうことは危険だ。そのとき家計のリスクは最大となる。

Webページの検証は難しい

検証するだけならツールを使えば簡単にできる。
RightWebPageというツールが紹介されていたので、実際に使ってみた。
RightWebPage自身のサイトをチェックしてみたら、accessibiltyでエラーがでた。ツール制作者のサイトでも、このような有様なのだから完璧なサイト作りは至難の業だ。
しかし、このツール、かなり細かいチェックをしてくれる。このツールにパスするのはかなりハードルが高そうだ。
ちなみに大学のサイトをアクセスしたら２件のエラーが出た。フォームに名前がないと言われた。
さらに、自作のページをアクセスしたら、２５件のエラーが出た。相対参照はだめらしい。

Google Docsのオフライン機能

Google DocsがGearsに対応し、オフラインでも編集可能になった。
小さな一歩かもしれないが、人によっては大きな意味がある。
個人的には、作業環境をクラウドに全面的に移動しつつあるので、大変ありがたい。
しかし、難を言えば、Google Docs自体をもう少しまともな文書作成ツールにしてほしい。
書式が乱れたり、ブラウザによって表示が変わったり、結構問題が多い。
しかし、それでも便利で使ってしまう。

グループ学習における国民性

グループ学習が注目されているが、どうも国によって国民性の違いに根ざす差があるように思える。
フィンランドメソッドに代表される欧米流のグループ学習では、まず個々で自分の意見をまとめ、それを集団の場で議論する。つまり、アイデアを出す過程は純粋に個人主義だ。また、グループ討論の場では、相手が一生懸命考えた意見を尊重し、きちんと耳を傾ける。しかし、自分の意見と違うと思えば、遠慮なく批判する。その際、常に合理性に基づいて議論するという態度が求められ、それを学ぶ場がグループ学習でもある。もちろん、各自の得意を生かし、不得意を補う効果もある。
一方、日本のグループ学習では、いきなり雑談が始まり、雑談の中からアイデアを拾い出す。まったく考えがないというわけではないが、不十分なアイデアでも開示し、相手の反応を見る。思考あるいは発想の過程を補助してもらおうという考えが含まれている。そして、そのまま議論に流れ、意見交換をするが、合理的に判断するより多数決に依存する傾向が強いように思える。あるいは声の大きい者の意見に集約される傾向といってもよい。このような方法は合理的とはいえないが、ある意味では今はやりの集合知にも似ている。つまり、合理性より実用性を重視した意志決定とも考えられる。
このような差は、学校の教室の中だけでなく、会社の会議、果ては国会でも行われている。日本式議論は、おおむね正しい結論に迅速に到達するが、必ずしも合理的ではない。しかも、議論の場に、合理的に判断し、方向性を示せるリーダーがいないと、議論が空回りすることも多い。
このような方式の違いは、どちらが優れているかが問題ではなく、明らかに存在するということを意識することが重要だ。日本人が特別というわけではなく、広く行われている方式だ。グループで意志決定しようとしているときに、どちらの方式が適しているのか、あるいはどちらの方式で進行しているのかを判断して、適切に進める必要がある。

LoadrunnerからSequoiaへ

IBMのLoadrunnerが1PFLOPSの壁を越えて間もないが、次のSequoiaが早くも20PFLOPSを実現するという。
Loadrunnerが稼働したのは2008年、Sequoiaは2011年稼働予定であるから、わずか3年で20倍に進歩したことになる。
基本的には、CPUの電力当たりの性能を向上させつつ、その数をひたすら増やすという方法でどんどん性能が高まる。もっともそのためにはボトルネックであるネットワークを同時に解消しなければならない。よって、正確に言い換えるなら、CPUとネットワークの技術革新がある度に、順調に性能を向上させることができる。
一方、日本では2011年に10PFLOPSをめざそうとして、極めて困難といわれている。別の方式では、この単純な方式に勝つことはなかなかできないだろう。

SBMがEmobileでMVNOする

SBMはiPhoneがありながら、一般的な定額データ通信をする体力がなかった。それをEmobileのMVNOで乗り越えようという戦略だ。これは両社にとってメリットがある。
SBMはデータ通信を補強でき、Emobileは大きな収入源を得ることになる。今後、EmobileとSBMが合併することもありえるだろう。
これでSBMは安心してさらなるサービス向上に努めることができる。
しかし、Emobileの通信網は地方をあまりカバーしていない。これは、あまり大きな問題ではないかもしれないが、競合他社に対して見劣りすることは否めない。
個人的には、両社の提携は大歓迎なのだが、よく考えると直接的なメリットはあまりない。iPhoneでポケット中継ができないかぎり二重投資になってしまう。
そう考えるとEmobileによる端末の販売は今後少なくなるのかもしれない。それは同社がキャリアに特化していくという意味では正しい選択のように思える。

UQ WiMAX

KDDIのWiMAX「UQ WiMAX」の本サービスが7/1から始まるらしい。
気になる料金は定額4480円/月らしい。
最低価格のiPhone 3Gより高くなるのは気になるが、久々にKDDIと契約する気になってきた。
もっともウィルコムと比較してからでないと決められないし、実際の接続状況も気になる。
欲を言えば、２段階定額など料金体系にも幅があればうれしい。おそらくLANやWiFiのあるところでは使わないので、利用は限られると思う。ならば常日頃の料金は最低に抑えたい。

同字形系文字の埋め込み符号化法

Unicodeで標準以外の文字を利用するには外字などを使う。また、外字を用いても16ビットのUnicodeでは10万文字を表現することは不可能だ。そこで、サロゲートペアという方式で32ビットの符号を表現する。
しかし、異体文字や誤字を含む同字形系文字（これは字形が類似の文字の集合という意味の筆者独自の造語だ）をサロゲートペアで表すと、検索プログラムはすべての類似性判断を行うために非常に複雑になる。あるいは、そのような複雑なプログラムのライブラリが普及するのには長い時間がかかる。
簡単な異体文字を例に考えると、例えば、澤と沢は正式な氏名では区別されるが、通常の利用では区別する必要はほとんどない。意味も読み方も等しく、一般的には澤の簡略形が沢だと思われているだろう。しかし、両者は文字コードが異なるため、沢で検索しても澤は見つからない。そのために澤の名が付く人をしばしば見逃してしまうこともある。澤は、それでもまだ知らない人がいないくらい有名な文字だからよい。それこそ誤字はほとんど知る人がいない世間では通用しない文字であるにもかかわらず、その本人にとっては正式な文字である。これが検索でないのでは電子化の恩恵に預かることができない。
そこで、以下のような符号化法を考える。
ESC, 外1, 外2, 同
ここで、ESCはいわゆるエスケープシーケンスである。外1, 外2は両方で１つの外字を表す。ESCを省略し、２つの外コードで拡張サロゲートペアを形成してもよい。いずれにせよ可変長の処理は必要となる。最後の「同」はBMP内での代替文字だ。真の文字コードの他に代替コードを埋め込む所がポイントだ。これによって、外字コードを無視するだけで通常の検索プログラムが動作する。

外字のオープンソース化

自分の氏名を正しく入力する権利は誰もが持つ基本的な権利ではないだろうか？
しかし、この当たり前のことがいまだにできていないことは驚くべきことだろう。
住基ネットの開発を通じて10万以上の外字が発見されたことを前の記事で述べた。しかし、この成果が我々のパソコンに反映されてはいない。
発見された外字は各社が独自に外字ライブラリとして販売している。国家プロジェクトの成果が各社の利益だけに還元されているのも問題だろう。
しかし、実際には10万を超える外字コードが明らかになっても、それらに対応するフォントがなければ意味がない。
最近ではオープンソースとして提供されるフォントがある。しかし、これらオープンなフォントでは、必要最小限の文字しかサポートしていない。今後、10万文字のフォントを作成しようとしても、そのコードが決まらなければ互換性がない。
そこで、まず10万文字の外字のコードを整理し、標準化する必要がある。次に、それらの代表的な字体を公開し、オープンソースによるフォント作成が可能な状態とする必要がある。ここまで行えば、それをビジネスとして行うものやフリーで作成するものなど多様な提供者が現れるだろう。一般ユーザはそれらの成果物を用いるだけでよい。
そろそろ当たり前のことができてよい頃だ。

住基ネット≒外字プロジェクト

住基ネットは、定額給付金で再びやり玉に挙がっている。つまり、大枚はたいて開発した住基ネットが定額給付金の支給でほとんど役立たないことが判明したからだ。
確かに住基ネットは活用されていない。実際に調べてみると、その使われなさが痛々しいほどだ。役所では端末がほこりをかぶっている。最近、ようやくe-Taxで復権の兆しが見えてきたが、活用されるにはまだまだ時間がかかるだろう。
そこで、住基ネットの意義は何だったのか考えてみる。
そもそもの基本設計が抜本的に間違っていたと思うが、百歩譲って当時の（今も変わっていないが）制度下ではやむを得なかったのかもしれない。
しかし、１つ認めてもよい部分がある。それは日本人の名前の文字をほぼ完全に電子化することに成功した点だ。「ほぼ」というのは、残念ながらそれでも完全ではなく、一部では文字コードの代わりにイメージが使われているらしいからである。
漢字がいくつあるかという問題は、文字符号が登場する前後でよく議論されることだ。Unicodeには多くの批判があったが、グローバル化の流れの中で無視できない存在となった。一方、超漢字など日本独自仕様は埋もれていった。しかし、地方自治の現場では名前の電子化は最も重要な基本処理である。とても標準Unicodeだけでは対応できないことは明らかだ。
住基ネットの開発によって、全日本人の氏名が電子化された。すべての文字にコードがつけられたわけではないが、少なくとも電子的に表現可能となった。この意義は大きい。その数は10万文字を超えるという。
なぜ、このように大きな数になってしまうかと言えば、誤った漢字も多く登録されてしまっていたからだ。例えば、出生届に手書きで氏名を書くとき、間違って点を１つ多く記入すると、それで新しい漢字が誕生することになる。今では、もうそのようなことはないが、チェックが不十分であり、識字率も高くなかった頃には多くの誤字が登録されていたのだろう。不見識かもしれないが、異体文字にも歴史的には一種の誤字が含まれると思う。
この作業に対して400億かかったわけだが、これを高いと考えるか安いと考える方は個人差があるだろう。ちなみに、すべての国民の氏名を電子化するのに400億かかったのに対して、すべての国民に12000円給付するのに800億かかるとすれば、どちらが有意義だろうか？

Ajax時代のMVCモデル

Webアプリケーションの開発では、MVCモデルというソフトウェアパターンが使われている。アプリケーションを本質的なデータであるModel、それを表示するView、それらの制御をつかさどるControllerに分けて作成する方式である。
MVCモデルには思い出がある。もともとMVCはSmalltalk-80で使われたモデルだ。このモデルに取り組んだのは修論の頃だ。当時のSmalltalkではViewとControllerの区別があいまいというより概念的な意味での区分しかなかった。理論を優先し、実行効率を軽んじていたため、批判がなされた。当時の非力なマシンでは当然の批判だ。その結果、Smalltalkの後継では、ViewとControllerが統合され、MVモデルになってしまった。
しかし、Webアプリケーションでは再度MVCモデルが復活した。マシンの性能が飛躍的に向上したことも大きな違いだが、WebアプリではViewが完全に独立している点も大きい。Javaの代表的なフレームワークStrutsでは、Controllerを１つのサーブレット、Viewを複数のJSPで構築する。さらに、Viewはクライアントにも延長している。このような遠隔アプリの発想はオリジナルのSmalltalkにはなかった。
さらに時代は変わり、今やAjaxアプリの時代である。Ajaxアプリは2階層への回帰ではなく、3階層の進化である。Ajax時代には、再度MVCモデルを変更する必要がある。
Ajaxアプリでは、サーバ側はクライアントから呼び出されるAPIおよびデータの集合となる。理想的なAjaxアプリでは、プログラムはほぼ完全にクライアント側に移行する。すなわち、Controllerの主要な部分はクライアントに移る。クライアント側のControllerはイベントハンドラを中心としたJavaScriptプログラムになる。しかし、サーバ側にもアプリケーションとモジュール、メソッドを区別するアクションサーブレットは残る。したがって、Controllerはクライアントとサーバの両方に偏在する。
主なModelはサーバ側に存在する。これは誤解され易い考えかもしれない。一貫性を維持するにはデータはサーバ側になければならない。ゆえに、サーバ側のデータを主とする。一方で、普段はクライアント側のデータを処理する。クライアント側のデータはサーバデータの複製もしくはキャッシュである。よって、従のデータと言える。本質的にはクライアント側にデータはなくてもよい。ただし、効率を考えると、余計な通信を抑制するためにキャッシュとしてクライアントにデータを持つ方がよい。しかし、常にサーバのメインデータを更新する必要もある。
Viewは完全にクライアント側に移行する。APIを介してModelをアクセスする。その意味ではキャッシュとしてのモデルはViewの一部ともいえる。そう解釈すればModelはサーバ側にしかないという言い方もできる。しかし、前述のAPIはWebサービスのAPIを意味した。しかし、実際にはJavaScriptのAPIが提供され、キャッシュされたモデルとViewを密結合するだろう。この場合、Viewは完全にModelから独立する。

メールによる投稿

メールでブログを投稿してみた。
Bloggerでは、メールアドレスを指定して、ブログの記事を投稿できる。
直接投稿は手軽だが、注目度の高いブログでは危険だろう。このブログのように目立たないブログではおそらく問題ない。
実際に投稿してみて、気づいたことがいくつかある。
まず、メールの署名は不要だ。標準では署名を使っているが、逆にブログでは邪魔になる。かといって自動的に署名を削除することも難しい。
次に、HTMLタグが挿入される。通常、Bloggerではタグを意識する必要はない。しかし、メールから投稿したものはタグが明示されるようだ。これは改良の余地があると思う。