ECサイトの重複注文チェック

Amazonをよく使う。そして同じ本を２冊注文してしまうことがたびたびある。
前に購入したことを忘れて新たに注文したというわけではない。
操作ミスで２冊注文してしまう。おそらくクリックを２回してしまうのだと思う。２度押したつもりがないので、注文時に確認することを怠ってしまうのもいけないのだろう。
このような誤った注文は売上を伸ばすため、歓迎するECサイトもあるかもしれないが、多くの場合は信用を失う結果につながるだろう。
簡単な重複注文のチェックがあるとよい。

Executable Storage

クラウドが浸透するとデータはサーバ側に置くようになる。
そのときクライアント側にダウンロードし、処理した結果をアップロードするというのは無駄が多い。
非力なクライアントに遠回りしてデータを届けるのだから、きわめて無駄な処理と言わざるを得ない。
しかし、現在のオンラインストレージサービスのほとんどは、そのような使い方を強要する。
理想的には、ストレージに近いところのプロセッサを借りて実行するべきだ。その場合、データはクライアントまでダウンロードされることはない。すべてがサーバ側で処理したように見える。つまり、ストレージ側で実行したことになる。
実行可能なストレージというわけだ。
しかし、すべての処理をストレージで行うのは現実的でない。対話が必要な処理はクライアント側で行った方がよい。その役割分担をどうすべきかが課題となる。

Gearsで学ぶSQL

このようなタイトルの本が出版されてもおかしくない。
GearsとはGoogle Gearsのことだ。Webアプリをオフラインで実行可能にする。
GearsにはSQLiteというDBMSが内蔵されている。
つまり、Gearsを介してDBを利用することができる。
通常では、自分でJavaScriptのプログラムを書いて、このDBにアクセスしなければならない。
しかし、同じことを考える人はいるもので、このDBをJavaScriptなしにアクセスできたらよいと考えた人がいた。
Google GearsのサイトからGoogleGears_SampleAndTools.zipをダウンロードするとdbquery.htmlが含まれている。これでSQLを直接入力することができる。

UMLの多重度をターゲット側に書く理由

最近、児玉公信著「UMLモデリング入門」という本を読んだ。
この中で氏はUMLの多重度をターゲット側に書く理由をER図に由来すると説明している（ように読めた）。ソースからターゲットへの対応がカラスの足のように見え、それがターゲット側に位置するというわけだ。
面白い意見だと思った。
しかし、もっと単純な理由ではないかと思う。それは"A student attends a/many course/s"という英文を考えると、a/manyという多重度はターゲットに相当する目的語を修飾している。つまり、英文で自然に考えるとターゲット側に多重度を書くことになるのだと思う。
UMLに限らずCSの表記では、しばしば英文法に由来するものが見受けられる。これもその１つだと思う。

論文か患者か

医者の業績評価は難しい。
研究者なら論文、教師なら教育で評価される。学者は両方だが、一般的には両立できると考えられている。
しかし、医者の場合、論文と患者（臨床）を両立させるのは難しいだろう。
例えば、京大の山中教授が臨床に時間を費やしていたらiPS細胞の開発に後れを取っていただろう。もっとも山中教授が臨床をしているのかどうかを私は知らない。たぶんしている時間はないだろうと推測する。
病院の臨床は大学の授業より多くの時間を費やすだろう。特に外科手術は数時間に及ぶことも珍しくない。
そのため、論文か患者かで業績の傾向が二分されると思う。これを公平に評価するのは難しい。
極端な言い方をすれば、人命と何本の論文が釣り合うのかということだ。
しかし、iPS細胞のように１本の論文が何人の命を救うかもしれない（今はまだ可能性だけだが）。
最近の世論は論文より臨床を重視してきているように思える。しかし、論文も重要であることを忘れてはいけないだろう。

UPS不要のPC

サーバの運用ではUSPはかかせない。
しかし、UPSのコストも管理も無視できない。可能ならUPSなど使いたくない。そういうサーバ管理者も少なくないだろう。
そのようなニーズに答える製品を作ればよい。
例えば、ノートPCのようにバッテリを内蔵する。UPSより安くて管理が容易ならよい。コンピュータを休止させるわずかな時間をかせぐことができればよい。
SSDを高速化し、休止に至るまでの時間を極力短縮する。
仮想化をせず、小さな物理メモリのマシンを多く使った方がよいのかもしれない。
休止時間が短くなれば、バッテリも変わる。リチウムイオンでなくてもコンデンサのようなものでもよくなるかもしれない。そうなれば全く消耗しないのでメンテナンスフリーになる。
抜本的な対策としてはフラッシュメモリのように記憶の消えない、DRAM相当の速さのメモリを開発することだ。

スキャナとSaaS

文書の電子化にスキャナは欠かせないツールになっている。
しかし、程度問題ではあるが、スキャナは手軽に使うことができない道具の１つだ。
HDDはドライバ不要で、接続してすぐに利用できる。
しかし、スキャナを使うには、ドライバは勿論ビューアなどのツールまでインストールする必要がある。最低限の使い方ならWindowsの標準ツールでもTWAINはサポートしているが、いまどきPDFくらいまで変換してくればければ（文書管理の目的では）使い物にはならない。
そこで、このような面倒なインストールを一切不要にする方法がないか考えるとSaaSに行きつく。
非標準なツールはサーバ側に用意し、スキャンデータをサーバに転送して加工すればよい。WIFI対応なら結線も不要だ。
また、サーバへの回線が細い場合は、スキャナにストレージを内蔵することも考えられる。Linuxサーバを内蔵すればアプリケーションを実行することもできる。
コストは増えるだろうが、それほど大きくはないだろう。