パソコン・インターネット

Twitterで医療IT関連ニュースを流すアカウントを作った

さて、さらに同工異曲なのだが、医療、医学関係のIT、インターネット、ソーシャルメディアの利用に関するニュースをつぶやくことにした。
@medicalitnewsjp
にて。

| | コメント (0) | トラックバック (0)

iphone news on twitter

iPhoneに関する日本語ニュースをtwitterでつぶやくことにしました。

@iphonenewsjp

昨日公開したものと同工異曲です。

| | コメント (0) | トラックバック (0)

Twitterで医療業界ニュースを流すアカウントを作った

Twitterで医療ニュースをつぶやくアカウントを作った。アカウント名は@medicalnewsjp

基本的には、日本国内の一般メディアのウェブページで、医療、医学関連のニュースが報じられると、それへのリンク入りでつぶやくというもの。

以前、ついったーについては、RSSリーダーの代わりとして使っていたのだけれど、単純なRSSリーダーとしてはあんまり使い勝手がよくなくて、最近は、またGoogleReaderに戻って放置していた。
でも、どうも、Twitterの世界には、いわゆるニュースサイトみたいなものが足りないと思い、自分が関心のある分野についてニュースをつぶやくアカウントを作ると、他の人にも重宝するのではないかと思い、今回のものの作製することになった。

ちなみに、今回のもののバックエンドは、twitterfeed, feedburner, Yahoo! Pipesでできている。

| | コメント (0) | トラックバック (0)

実は、ウィンドウズ95のUIは、マックより遥かに優れていた。




ブログネタ: あなたにとってWindowsの魅力ってなに?count


ここから書きます↓

すくなくとも、ある種のユーザーに対しては、当時のウィンドウズ95のインターフェースは、もっとも適したものだったのだろ思うようになった。
もちろん、歴代のマックOSなんかと比べても、遥かに優れている。
そう思うようになった。

僕は、ウィンドウズ95よりも昔からウィンドウズとDOSを使っていたけれど、そのころ、ウィンドウズってのは、なんとなく、マックに比べてかっこ悪かった。
ウィンドウズのパワーユーザーも含めて、ウィンドウズってのは、結局のところマックのできの悪いコピーでしかなくて、マックのほうが直感的な操作ができて、デザインが垢抜けていて、そうそう、ウィンドウズはマッキントッシュと違って「魂がない」なんて言われ方もしていた。

でも、憧れのマックは値段が高くって、なかなか買えなくって、「代用品」としてのウィンドウズを使っているうちに、いつの間にか、日常的に使うソフトなんかのマック版は姿を消していって、、、

結局、僕の初めてのマックは、仕事でUNIXのソフトウェアを動かさなくちゃいけなくなって購入したOSXになった。

それ以降、マックもウィンドウズも、両方使っているんだけれど、いろいろいじくってみて、マックのほうが直感的でセンスもいいなぁとずっと思っていたところ、最近、思いがけないウィンドウズのよさを見つけて、ウィンドウズを、特に、ウィンドウズ95を見直している。

最近、このブログにも書いたことだけれど、とある医療関連ソフトウェアのユーザーインターフェイスの設計を引き受けた。このソフトウェアは、業務用に使われるものなんだけれど、このソフトウェアの使われる職場は、以下のような特徴があった。


  1. この業務に携わる人たちの労働市場はきわめて流動的で、したがって、このソフトウェアのユーザーは、頻繁に転職をくりかえす。

  2. 転職してきたばかりの新人は、ソフトウェアの使い方を覚えるまでは、ほとんど仕事ができない。

  3. したがって、ソフトウェアの操作を覚えるために必要な期間が長いと、実際に業務に携わることができない従業員を作ることになる。つまり、操作を簡単に覚えられるものを使うことで、効率を引き上げることができる。

  4. また、十分にソフトウェアの使い方を覚えた従業員も、ひとつの職場に定着することは少なく、結果、うろ覚えでソフトウェアを使っている者が多い。

  5. したがって、操作するために覚えなくてはならない項目を減らすことで、操作ミスに起因する事故を防ぐことになる。

  6. このソフトウェアでする仕事の中には、いくつか、相当複雑な手順を必要とする操作がある。しかし、その操作は、それほど頻繁に行うわけではない。

  7. 今回、ベンダーは、ユーザーサポートにかける予算がほとんど用意できない。

  8. したがって、ユーザーには、操作方法がわからないという思いをさせてはならない。

そんなわけ。僕は、使いやすいインターフェイスといえば、つまり、「直感的」で、「センスのいい」デザインがいいとおもって、で、「直感的」、つまり、アイコンで、直接操作できるような感覚を大事にしたいと思って、で、できるだけ「センスのいい」デザイン、つまり、マックとかiPodとかでよく見かけるアイコンとかメニューのデザインをパクッて使うつもりだった。センスがいいのはアップルだと思っていたからね。

で、そういうデザインを紙に書いて、ペーパープロトタイピングしてみたんだけれど、あんまり、テストユーザーの反応が芳しくない。

「直感的」なはずなんだけれど、みんな、はじめてみると使い方がよくわからないみたいなんだ。

いろいろ試行錯誤して、わかったこと。

  1. 「直感的」に利用できるためには、そもそも、操作する対象について、ユーザーが心理的なモデルを持っていなくてはならない。「はじめてそのカテゴリのソフトウェアを使う人が説明なしでも使える」ことを目標にするならば、「直感的」であることに頼ってはいけない。
  2. 「直感的」であることに頼る代わりにウィザードを用意するとよい。特に、はじめての操作、あまり頻繁でない操作が複雑な場合、たとえ冗長に感じられてもウィザードを用意すべきである。
  3. はじめてソフトウェアを見た人が使いやすいために、画面上にあるものは、クリックできるものなのか、そうでないものか、見た目でわかるようでなければならない。クリックできるものは、可能な限りボタンらしく、四角くて出っ張って見えるものだと良い。丸みを帯びたデザインに比べて無骨なデザインになるが、やむをえない。無骨な四角という前提の範囲内で可能な限りかっこよくするべきである。
  4. ボタンは、何をするためのボタンなのか「何をするためのボタンなのか」初見者にわかりやすく書かれているべきである。その際、そのボタンの機能を表すアイコンは、あまり役に立たないことが多い。絵文字は、心理的なモデルに依存することが多く、また、誤解を招きやすい。
  5. したがって、そのボタンの機能を言葉で書くべきである。「スタート」ボタンとか、「削除」ボタンのように。こうすることで、ボタンの機能について誤解を少なくできるし、また、操作方法について、実演しなくても言葉で説明できる。

というわけで、マック風デザインは、大幅な変更を余儀なくさせられ、いつのまにか、ほとんど、ウィンドウズ95風クラシックデザインになってしまった。
僕の記憶が正しければ、はじめてウィザード(あるいは、アシスタント)を大規模に採用したのも、「スタート」ボタンを採用したのもウィンドウズ95だ。

当時は、こういうのは、ダサいと思っていた。直感的で直接にオブジェクトを操作できる(ように見える)インターフェイスにくらべて、ウィザードは、アドホックで安直な解決策に思えたし、角ばったデザインは、無骨で重苦しく感じられた。簡潔でポップな絵文字に比べて、日本語がかかれたボタンはゴチャゴチャしてセンスが悪く感じられた。

でも、あのデザインは、少なくとも、「その種類のソフトウェアをはじめて見る人」にとっては、大変に優れたデザインだったんだと思う。たぶん、あの当時、ウィンドウズ95が想定した典型的ユーザーは、「これまでグラフィカルユーザーインターフェイスというものを触ったことがないユーザー」だったんだろうとおもう。

たぶん、ウィンドウズ95のデザインのミッションは、あのOSを立ち上げることがパソコン初経験になるというような人が、大きな問題を経験することなく「パソコンユーザー」になれるようにする、ということだったんじゃないか?

その後の状況の流れを考えると、たぶん、その狙いは、完全に当たっていたのではないかと思うのだ。
あれから15年たって初めて、あのころのマイクロソフトのデザインのすごさに気づいた。そういう自分の鈍さにため息が出る。

| | コメント (0) | トラックバック (0)

診療所用の電子カルテの最小構成のメモ

ここしばらくで、診療所用の電子カルテをカスタマイズ不要にするために、「電子カルテの最小構成」について、考えてみる。
ここで言っている、「最小構成」というのは、オプション機能を取り除いた「最小限必要な機能のセット」という意味ではなくて、「診療所のスタイルにかかわらず必要な構成」のこと。違いがわかりにくいか?

こんなこと考えている理由は、
1、電子カルテをカスタマイズするのには、結構なコストがかかる。
2、そこで、多くのベンダーが、可能な限りカスタマイズをしなくてもすむ構成を考えている。
3、でも、病院や診療所のサービスや経営のスタイルはさまざまなので、それにあわせて、多少のカスタマイズは必要なことが多い。
3、ところで、実のところ、多く売られている電子カルテには、不要、あるいは冗長な機能が多い
4、冗長な機能と受け取られがちなのは、結局、カスタマイズが必要な部分になることが多くて。。。

というわけで、「システムを使うための最小限の機能」という、「最小構成」ではなくて、「ほとんどの診療所のサービスや経営のスタイルで、カスタマイズしないで使えるような機能のセット」、つまり「最大公約数構成」のような意味の「最小構成」を検討してみた。

たぶん、
1、レセコン部分
公費治療のための医事システムってのは、どこでも必須の機能。
2、医師入力部分
結局、レセコン入力を、医師が診察室で済ませてしまうって言うのが、電子カルテのキモなわけで
3、受付部分
診察室に入る前に受付を済ませるというのは、まあ、普通の診療所では当たり前なわけで、とすると、そのときに、カルテの表書きだのなんだのってのは、処理してもらいたい。
4、検査伝票、処方箋などのプリントアウト
5、処置用に看護師が見る支持受け端末
くらいを使うのが、最小のユースケース。

とすると、多分、あれとかこれとかは不要になる。

| | コメント (0) | トラックバック (0)

「自動診断ソフトウェア」の悲劇1

学会とかでもいろいろ発表したネタだし、知っている人は知っていることなんだけれど、僕は、3年前から昨年にかけて、医者のかわりに「診断」をしてくれる「自動診断システム」を作っていた。
この自動診断システムはウェブで動く、プライマリケアに特化したシステム。
なにか体調が悪くて、でも医者にかかるほどでもないからネットで調べたいって思っているような人がターゲット。

このシステムの動作について簡単に説明すると、


  1. まず、ユーザーは、自分の年齢、性別、最もつらい症状を、フォームに入力する。
  2. すると、システムは、その制約の中で、可能性の高い疾患を確率順に列挙し、また、疾患を絞り込むために質問を生成する。
  3. ユーザーが質問に回答すると、システムはその質問の結果を使って、さらに疾患を絞り込み、質問を繰りかえす。
  4. かんたんな質問だけで、これ以上、可能性の高い疾患を絞り込めなくなったら質問を終了する。
    という動作をするシステム。

これだけで、プライマリケアでの正診率は、おおむね80~95%に達する。

ベンチマークとして、医師国家試験の臨床実地問題を解かせてみると、おおむね、75~80%程度程度の正答率になる。医師国家試験では、ボーダーラインは60%台なので、これは、コンピュータのソフトウェアが、国家試験に合格する(可能性が高い)レベルに達しているということを意味している。この成績は、実は、この種のソフトウェアとしては、ほとんど最高レベルである。

医師国家試験に合格するレベルの自動診断システムっていうと、みんな、すごいっていってくれたんだけれど、とはいえ、このシステムは、特別複雑なことをしていたわけではない。推論エンジンは、単純なベイズ推論、つまり、その年齢、性別で「よくある病気」の症状にあてはまらないか質問するだけの安直な推論でしかなかったし、推論のためのデータは、ネットで自動で集めただけ。
データ収集は、どうやったのかというと、


  1. このサイトを使う前には、このソフトウェアは、医師の代わりになるものではないので、なにかあったら必ず医師に相談するようにメッセージを出す。
  2. このサイトから離れる際に、ふたたび、メッセージを表示する。内容は、なにかあったら必ず医師に相談してほしいこと、また、このシステムを改善する目的で、受診した医師が行った診断についてメールで質問することがあること、その際、同意いただけるならば、質問には答えてほしいことの3点。
  3. システムの利用者には、システム利用から1週間後に、その後、医療機関に受診したか、もし、受診したならば、どのような診断をされたか、質問する。

この質問の結果をそれそれの疾患に罹患した際に各症状が起こる確率をしめす基礎データとして推論に使った。特別なデータクレンジングなどの操作はしなかった。

さて、このシステムの話をすると、


  • 一般の人に話すと、たいてい、このシステムの精度、つまり、「医師国家試験に合格する水準」という点に素直に驚いてくれた。
  • 統計やデータマイニングの専門家に話すと、このシステムが、データクレンジングなどの操作をさっぱりしていないこと、それにもかかわらず、それなりの精度を持っていることに驚いてくれた。
  • 医師に話すと、ほとんどの医師は驚かなかった。特に、システムの推論メカニズムについて話すと、「ま、俺たち人間の医者がやってることも、そんなもんだろ。」って反応が一般的。

ここまでの経緯から僕が得た教訓

  1. 人工知能やエキスパートシステムなど、過去のコンピュータ技術で使われた方法論のうちで、使い物にならないとされたものは多い。でも、それらの多くは、当時のハードウェアでは使い物にならないとみなされただけに過ぎない。現在のハードウェアの計算能力と記憶容量を利用すれば、案外使えるものも多い。
  2. ネットの生のデータは、きちんとデータクレンジングしないと使えないというのが常識。たとえば、ユーザーが間違えて入力したり、時には故意にウソのデータを入れたりするから。でも、これは状況によっては正しくない。
    • たとえば、専門的な「病名」などについては、ユーザーは入力時に間違いを犯しやすいのだけれど、でも、事前に、「診断名を質問するよ」って伝えておくことで、記憶違いなどは、相当抑制できる。
    • また、体の調子が悪くて、どうすればいいかネットで調べたい人は、ウソのデータで検索したりはしない。

  3. そういう社会的、心理的方法を十分に配慮したら、データクレンジングはほとんど不要になり、自動化できる部分をふやすことができる。
  4. 実のところ、医者のやっている推論は、そう複雑な推論ではない。そして、ほとんどの医者がそれを知っているし、それを指摘されても不快には思わない。
  5. にもかかわらず、医療関係でない人たちは、医者のしている「診断」を実際以上に専門的で複雑な推論だと思っている。

次回、このシステムの開発の悲劇的結末について(いずれ書く)。

| | コメント (0) | トラックバック (0)

hiroyukikojimaの日記、一気読み

yhiroyukikojimaの日記の過去ログ読了。
数学関連のエントリーの面白さはさすが。
数学のあまり得意でない人に対しての配慮が見える書き方が、暖かい。

| | コメント (0) | トラックバック (0)

SDIとMDI タブブラウザやIDEは時代の流れに逆行しているのか?

SDIとMDI

むかし、GUIアプリケーションはSDIとMDIのどちらがいいかという論争があった。

MDIってのは、ひとつの親ウィンドウがあって、親ウィンドウの中に、子ウィンドウが入っている形式のもの。SDIってのは、その親ウィンドウにあたるものがないもの。よくわからなければ、こちら
とか、こちら
をみてほしい。

本来、複数のアプリケーションを同時に使わなくてはいけない局面では、ユーザーがアクセスしているドキュメント単位で操作するSDIが自然。MDIのように、自分が利用しているアプリケーションの区別を不必要に意識させるのは、操作や表示が複雑になるだけで、あまり好ましくない。

ユーザーが操作している本質的なオブジェクトは、結局、アクセスしているドキュメントそのものだから。アプリケーションは、そのオブジェクトの操作方法、メソッドの集合でしかない。

それでもアプリケーションの違いを強調するようなMDIが昔は便利だった。その理由は、

1、昔、メモリが効果であった時代、メモリを節約するためには、多数のアプリケーションを同時に立ち上げることを控えなくてはならなかった。そのため、自分の立ち上げているアプリケーションを意識させるインターフェースはメモリ節約のためにも有用であった。

2、OLE(もしくはActiveX)が不完全で、異なるアプリケーションの間で、カットアンドペーストなどで、データのやり取りをすることが、今ほど簡単ではなかった。そのため、ユーザーは、データを作成したのが、いったい、どのアプリケーションなのかを意識しておく必要があった。

3、各アプリケーションのインターフェースがいまほど、統一性がなかった。

といったところだと思う。理由のほとんどは、すでに、過去のもの。

現在、MS-ExcelなどMS製品も、MDIを避けて、SDIに移行してきている。

ただ、ものには例外がある。

時代に逆行して、むしろ、SDIからMDIに変化してきたのは、たとえば、ウェブブラウザ、開発環境、ファイラといったところ。

ブラウザについて

近年のブラウザは、いわゆるタブブラウザという方式が主流になっている。これは一種のMDI。これは、SDIに対するほかのアプリケーションの流れに逆行している。

ブラウザの場合、どうして、MDIのほうが、便利だと感じるのだろう?

ブラウザは、ひとつの理由はブラウザがemacsのように万能のアプリケーションに変化したことだと思う。最近は、何をするときでも、ウェブブラウザさえあれば事足りるようになってきた。ほとんどの仕事が、1種類のアプリケーションでできるため、SDIでもMDIでも、ほとんど違いがないのだ。

こうなると、むしろ、ウィンドウの数を減らせるという、MDIのメリットが効いてくることになる。

開発環境について

MDIの開発環境、いわゆるIDEが普及したのはなぜだろう?

IDEのMDIは、ただ単にウィンドウが複数あるだけではない。ファイラ的な動作をするプロジェクトマネージャやクラスブラウザがついてくる。このプロジェクトマネージャが扱うプロジェクトというのは、コンパイルや配布の単位でもある。

たぶん、Javaなどのようなmake動作が必要な言語でIDEが優勢で、perlやrubyのようなインタプリタ言語では、それほどでもないのは、そこに理由がある。

反対に、SDIのメリットは、複数の種類のアプリケーションで、複数の種類のファイル、たとえば、画像とテキストとかを同時に扱うときに画面がシンプルで統一的になること。プログラマが扱うのは、テキストという単一の種類のファイルだけのことが多い。この点でも、MDIと相性がいい。

主流のMDIに対して、僕が、開発環境としてSDIのテキストエディタを使うのは、僕の開発案件に、次のような条件がそろっているからだと思う。

1、たいてい、コンパイルが不要なインタプリタ言語を使う。

2、手元に、クラスブラウザの代わりになる、扱いやすいファイラがある。

3、プログラムと同時に画面デザインもしなくてはいけない。画像ファイルなども、開発時に同時に扱う必要がある。

LLが主流になるにつれ、IDEでの開発にこだわらない人が増えてきた。今後は、開発もSDIの時代だ思う。

| | コメント (0) | トラックバック (0)

S言語ファミリーとUNIX

友人に、SAS使いの統計家がいるのだけれど、そいつがS言語を学びたいというので、しばらく前に、彼とR言語について話をした。で、彼が言うには、どうも、彼にとってはS言語は(そしてR言語も)非常に難しいってこと。

R言語も、S言語も、比較的シンプルな言語で、ま、難しい使い方をすれば、難しいこともできるけれど、簡単な仕事は、簡単にできる言語。

彼は、僕をはじめとするR使いたちを見ていて、
「いったい何をしたいのかわからないことがある。」
という。
R使いの流儀では、まとまったプログラムをはじめに作らないで、ごちゃごちゃと、短いプログラムを作っているうちに、統計的な結論が出てくる。
あれは、いったい何を作っているのだ?
と彼は聞く。

僕には、彼が、Sの何が分からないのか、よく分からなかった。で、いつも、口数が多い僕にしては珍しく、相手の言っていることをじっと聞いていたのだが、聞いているうちに、なるほどと理解したことがあった。

たぶん、これは、GUIは分かるけれどもUNIXのコマンドラインが難しいっていう初心者rootと同じ原因で起きている症状だと思う(あるいは、PerlやPythonを使ったシステム管理が苦手な人たち。)。というのは、S言語について、彼が使いにくいって言っている部分は、S言語のUNIX的な部分のことなんだ。

もちろん、勉強がすすめば、他にも、いろんな壁があるかもしれないけれども、とりあえず、どうも最初の壁は、UNIX的な考え方になじみにくいってところみたいだ。UNIX的な考え方のツールってのは、それなりの利便性があるから、ああいう形になっているのだけれど、UNIX的な考え方になじみのない人にとっては、ユーザーフレンドリとは言いがたい。

でも、みたところ、SとかRの参考書で、その背景にあるUNIXの思想に触れているものはあんまりない。

で、以下は、S言語とR言語のどんなところが、UNIX文化の影響を受けているかの話。

歴史の話だけれど、確認しながら書いているわけじゃないし、現在のSやRから、僕が想像して書いている部分もある。だから、この文章を読んだ人で、間違いに気がついた人がいたら、教えてほしい。

R言語ってのは、S言語のファミリーのひとつだ。

もともと、S言語ってのがあって、で、それのGNUによる拡張がR言語。

で、その、元になったS言語ってなんだってことになると、これは、統計解析に特化した機能をもった言語ってのが、答えになる。

というわけで、ここでは、まず、S言語の話をする。

S言語は、UNIXやC言語を生み出したベル研究所で、それらよりも若干遅れて1980年代初めに開発された。当時のSの開発目的は、探索的データ解析を支援することであったらしい。

探索的データ解析ってのは、統計の研究スタイルのひとつ。1960年代から、Tukeyって人が、提唱していたやりかた。いろんな点で、古典的なスタイルと異なるのだけれど、そのひとつの特徴がモデルを作る前に、データをいろんな視点から見ることが大事だって考え方。

つまり、結論を急がず、とりあえず、元のデータをいろんなグラフにしたり、表にしたり、いろんな見方でじっくり見ようってこと。いわば、データを使って実験するみたいなもの。

そのためには、


  1. いろんなデータ処理をインタラクティブにすばやくできなくてはいけない。
  2. 必要に応じて、既存のデータ処理方法を組み合わせて、手軽に新しい処理方法を作れなくてはいけない。

そうしなくては、データを、思いつくままにいろんな見方で見ることはできない。

当時、大規模なデータ処理ってのは、たいてい、IBMの大型機で行われるものだった。そして、大型機はどのような計算をしたいかあらかじめ計画を立てて、バッチ処理で動かすものだった。だから、探索的データ解析みたいに、いろんなデータを使った実験を手軽に行うのは困難だった。

SASっていう統計言語は、当時のIBMの大型機の文化を引きずっている。この言語は、fortranや昔のBASICに似た言語。で、必要な処理は、すべて、バッチプログラムにして解析を行う。これでは、探索的データ解析は難しい。

探索的データ解析には、シェルを使ってインタラクティブに操作できる端末と、データを蓄積したサーバーのネットワークが必要だったんだ。

S言語は、そういうニーズから生まれた環境のひとつ。ベル研の連中は、UNIXワークステーションが開発されたとき、このマシンを使えば、つまり、UNIX端末からデータを扱うためのシェル環境があれば、探索的データ解析が簡単に可能になることに気がついた。この統計用シェル環境のアイデアは、1984年、Sシステムとして発表されることになる。

Sシステムのシェルコマンドの構文には、C言語の構文を真似たものが採用された。おそらく、C言語は、当時のベル研のUNIXエンジニアにとって、もっともなじみやすい言語であったからだと思う。

また、Sシステムのシェルからは、コマンドを入力すればインタラクティブにデータを操作できたし、コマンドを並べることでスクリプトを作ることもできた。

つまり、この新しいSシステムは、スクリプト言語としても利用可能なコマンドインタプリタであるという点で、UNIXシェルに似ていたが、制御構文などの文法はC言語に似た、いかにもUNIXとC言語の文化を引き継いだものだった。

また、Sシステムは、統計データの取り扱いの機能以外はほとんどなく、統計処理のために必要ないと考えられたオペレーティングシステムの機能へのアクセスは、ほとんどできなかった。Sシステムは、初期のUNIXツールらしく、問題の80%を解くためのシンプルな機能のみ実装するという方針で作られていたため、統計処理に必要性が少ないと考えられた機能は、実装されなかったのだろうと思う。

もし、そういったSシステムが実装していない機能が必要なユーザーがいたらどうすればよかったのだろうか?この場合のSシステムの解決策も、いかにも、UNIXツールらしい方法が用意されていた。つまり、必要な機能を持った他のUNIXツールと組み合わせて利用するのである。その目的のため、Sシステムの出入力は、他のUNIXツールに理解できるよう、シンプルで、短いものが多い。同時に不慣れな人間にとっては不親切である。

やがて、Sシステムは様々な拡張の結果、コマンドインタプリタから、完全なプログラム言語へと進化した。1988年には、プログラム言語仕様としてのS言語の仕様がまとめられた。

現在、よく使われるSの実装には、2種類。オリジナルのS言語を簡単に扱えるようにした、サポート付きの商業ベース環境のS-PLUSと、GNUによるSの拡張言語、R言語である。

R言語は、ほとんどの点でS言語互換であるが、GNUらしく、Lisp風の文化の影響を受けている。つまり、R言語は、見た目は、C言語風だが、実際は、LispとかSchemeのような、関数型言語なのだ。scheme風の言語に、S言語風のステートメントを追加したと言ってもいいかもしれない。

さらに、Sに比べ、大幅に機能が追加されている。なので、本来のUNIX風の禁欲的な匂いよりも、emacsとかと同じような雰囲気、つまり、頭頚関係なら、なんでも一つの環境でやってしまおうってノリを感じる。つまり、統計関係のキッチンシンク。

さて、というわけで、彼にはLife with UNIX―UNIXを愛するすべての人に

UNIXという考え方―その設計思想と哲学

を薦めた。これらの本で出てくるUNIX的な考え方ってのは、現在でも、コンピュータで仕事をする人たちには重要で、役に立つ。効率的に仕事ができるようになること請け合い。

| | コメント (0) | トラックバック (0)

ボディマップの進歩が止まってしまった。

登場時には、感動したサービス、ボディマップ
昔こんな風に書いた。


これはすごい。こんなのがほしかったんだと、一瞬で理解した。感激!
BodyMap
ブラウザ上でぐりぐり動かせる解剖図。

これで、
1、各臓器の断面を自由に見ることができる。
2、コトバをタグ付けできる。(google mapみたいに)
となれば、いま、医療関連で問題になっている、オントロジー関連の問題のうち、解剖関連のものは、自然に決着してしまうだろうな。

圧巻。

これのAPIが発表されたら、ぜひ、これを利用したウェブサービスを作ってみたい。


それから2年近くたって、ぜんぜん進歩していない。
この種のサービスの進歩が遅いのはなぜなんだろう?
何が問題なのだろう?

| | コメント (0) | トラックバック (0)