これは以外と面倒くさい。なぜなら、html のタグ名とタグ属性とを チェックして限られたもののみを通すようにしなければならないし、 書き換えられた html タグが後の html をダメにしないよう 閉じタグが足りないときは閉じタグを新たに追加してやらねばならないからである。 結局、フル HTML パーザをつけたす必要があるってことになる。
ところで (てくるで)、安全に使える html タグ (とその属性) ってのはどんな種類があるんだろう。インラインに限定すると、
やれやれ、また htmlparser3.py の出番か!
(ちなみに htmlparser3 という名前の由来は、すでに htmllib, HTMLParser があるのに加えて
3番目の html パーザだからである。もちろん、誰か絶対すでにほかの html パーザを Python 用に
つくっているだろうが、そんなことは関係ない)
ちなみに、自前で好きにいじれる html パーザをもっているとほんとうに便利。 自前の形態素解析器をもっているのも便利ですね (研究には使ってナイけど!)。 chasen がもうすこしまともな実装なら、あれを python モジュールにして使う気になるのだが… (しかし品詞体型が腐っているのでアレか。Juman の実装はさらにひどくてとても期待できないので、 どのみち自前で作るしかないんだよね)
Traiss をはじめてからほぼ 1ヵ月たったので、統計をとってみる。 3月 27日からきょうまでの数字:
重要なことは 1ヵ月やってもディスク容量はわずか 6MBytes しか消費しないということだ。 これなら容量的には十分スケール可能である。 Slashdot と LWN がいまと同じペース・容量の記事を流し続けるとして、 10年間やっても合計 1GBytes に満たない。 maa,編集する人が増えてくれば履歴も増えるだろうけど…。
ぜんぜん関係なひが、去年のいまごろ買ったバックアップ用の 120GB ハードディスクは
1年たったいまも 12% しか使用していない (毎日差分ダンプしている) :
#!/bin/sh
ymon=`date +'%Y%m'`
day=`date +'%d'`
rsync -auvb --exclude 'NOBACKUP' --exclude 'Cache' --backup-dir=/backup/old/$ymon/$day /home/yusuke /backup
exclude を使っているのは、一時的に生成したデカいデータ ("NOBACKUP" というディレクトリをつくって その下に置いておく) と "Cache" と以下のディレクトリ (mozilla のキャッシュ) をバックアップしないせい。
ちなみに、某バックアップツールを作成した某氏は、rsync の使い方を知らなかったと見える。 車輪の再発明ばんざい!
だうでもいいが、新山がしってるエスペラントの単語は saluton だけだ。
Speaker: George Candea, Stanford Title: A Reboot-based Approach to High Availability
きょうのトークは「再起動によってアプリケーションの downtime を下げる」というものだった。 ミッションクリティカルなアプリケーションでは、downtime の長さは 売り上げに直接影響する非常にヤバい障害である。今日の研究のキモは "micro-reboot" という 概念を導入したことで、これは「JVM やアプリケーションサーバ全体を再起動するのではなく、 EJB のいくつかだけを再起動することによって downtime を短くすることができる」というもの。 ここからわかるように、すでに OS やハードウェア層の問題は対象にしていない。 おまけに、アプリケーションはすべて J2EE のコンポーネントモデルで書かれることを 前提としている。でも、ま、それはいい。とりあえずそういうものを「Enterprise な」 アプリケーションと呼ぶことにしよう。で、この人の研究は、各コンポーネント間の 依存関係を自動的に分析してグラフ化することで、障害が起きたコンポーネントと、 それを再起動することによって影響されるコンポーネントだけを選んで再起動することができる (再起動/初期化のメカニズムはすべて EJB に依存している、これもえらく偏った仮定だが、まあいい)。
で、障害といってもいろいろあるワケで…ここでは OS もアプリケーションサーバ (JBoss) も 堅牢であるという仮定なので、問題は各企業の書く「ビぢネス・ロぢっく」だけだ。 そして何人かのプログラマにインタビューしたところによると、この層で アプリケーションをダウンさせる原因で、もっとも多いのは以下の 3つだという:
でも、ホントかね???
google://Abode Photoshoq/ (1件)
また、ツウちゃんねるをひっかけてしまった…。反省しています。
選択を間違った? その可能性はある。だがどのみち完璧な選択などできないし、 その場の流れで選択肢が限られていることも多い。結論としては「死なない程度にせいぜいガンバルだけ」 ということが結局のところ一番の選択肢でしかない。
(ブツ切れた)
あんがい、存外、桜貝。
うとふ (UTF)。
うとふはち (UTF-8)。
これをやってしまうと厳密な翻訳ではなく、 Slashdot の規約に微妙に違反してるような気もするが、どうなんだろ。 まあそれを言いだせばそもそも勝手に翻訳するのが著作権的にグレーな気がするが、 この問題はもうちょい翻訳が長続きしてから考えることにする。 そもそも RSS の使用条件というものがよくわからんよな。 RSS にも著作権はもちろんあるだろうが、使用条件は RSS 自身の中には書かれてないし、 Slashdot の Terms and Conditions をみてもよくわからない。
問. 使えなくなったハードディスクをどこに捨てるべきか?
答. ゴミ箱へ。
問. なんか、罪悪感があるんだけど。
答. ゴミ箱へ。
検索エンジンはそのうち衰退するだろうが、コミュニケーション関連ビジネスは 今後 10年でさらに繁栄しそうな気がする。というのは、 世の中がますます分散するにつれて、個々人の意思疎通は なおさら重要なものになると思うからだ。(集中的な)検索エンジンのない世界は可能だろうが、 通信のない世界は考えられない。 物理的なインフラだけでなしに、ソフトウェアの面でも何らかの変化がありそう。 ひと昔前にはやった「ソーシャルネットワーク」やらブログロやらは、 いずれもっと特定の個人との関係に特化した「コミュニケーションツール」として 進化するんではないか?
困ったことに (いやぜんぜん困らん)、オレはそういったものにまったく興味ない。
フトンのうえに寝っころがってるときにふとそんなことを思った。
暗い暗い
セキネさんから、IJCNLP に論文出せや、といわれ、あからさまにムカつく。 新山はこのワークショップの委員のひとりにされているのだが、 これは前々からうすうす感じていたことなのだけど、なーんか 「委員がそのワークショップに自分の論文出す」のって自作自演っぽくない?? まあ、その論文を査読するのはオレじゃないにしてもだ…。それに今のところ大した成果も 出ていないのに、ただ水増し用にセコい論文を出すというのも気に入らん (そういう人が沢山いることは知っているのでその仲間入りしたくない、そもそも論文数がいったい何の役に立つんだよ?)。 しかし、これらすべてのことは学会の場所が自分にとってスバラしければ許される。何もかも。 でも今回は開催地が韓国だ…はっきりいって、そんなに行きたいという気はしないんだよな。 新山は中国には興味あるんだけど、韓国にはほとんど興味がない。 おまけに、どっかの観光地でしょ? ますます興味ない。しかも NY から遠いじゃねーーか! がんばって真面目に査読するからカンベンしてよって感じ。 つーか自分の研究のインチキ性に気づいた今となっては、もはや米国の税金をつかって海外旅行しよう、 というのだけが新山のモチベーションなのだが…。だいたいねー、職業研究者ならともかく、 オレはまだ学生なんだすよ (それに将来この研究でメシを食ってく気もない)。 そんなに論文数を稼ぐことに必死になる必要もないんじゃないの?? と考えると、 まあなんというか、非常に疑問さね。これは。…ということを本人の前でぐちったが、 まあ、セキネさんが出してほしいというなら出しますがね。 しかし締め切りまであと 1ヵ月しかないので、これでは授業と発表が終わったあとも休むヒマがない。 まったくよう。
(追記: ようするに、かれの論拠は 「しばらく論文出してないと、死んだかと思われる」 ということらしいが、まあアーティストもしばらくアルバム出してないと 死んだかと思われるから、同じようなもんだな。しかしアルバムを出すほうが 論文書くよりはるかに大変だと思いますが…)
ガキ向けだらば童話で、大人向けだらば寓話なのか??
ガキでなければ大人という間違った/退避/対比。
てくるで、C で例外処理するにはどうするか? 新山は平気で goto を使う。
さもないとメモリを解放したりポインタを無効にしたりその他の作業を
毎回 if (失敗) { } のあとに同じように書かねば
ならないからだ。しかし成功したときは逆にその処理の一部だけを実行することがあるので
ややこしい。こんな感じだ:
しかしこういうことをやっていると、アセンブラを使っていたころを思いだす。
これとは逆に、if の中に or や and 節を並べるという方法もあるが、
どうも新山はそういった方法には潜在的な危険性を感じる。
エラー処理はクリティカルなものであり、
そのフローの流れは可能なかぎり明示的にしておくべきだ。
同じようなことは Python でも起こるのだけど、Python の場合は
例外があるし、いきなり関数から
if (!proc(1)) goto fail;
if (!proc(2)) goto fail;
...
if (!proc(n)) goto fail;
goto success;
fail:
free(foo);
p = NULL;
success:
free(bar);
return p;
return しても
べつに害がないことが多い (が、新山はなるべく「関数からの抜け出しは一箇所」にこだわる)。
しかし C ではメモリ解放しなければならない場合が多いので、
これはむずかしい。どうしても goto が必要になる。
まあ、do { ... } while(0); で break を使うという手もあるけど、
なんか好きじゃないんだよな…。
どうでもいいけれど、今回の宿題はラクすぎた。問題は 「ある Diffie-Hellman と電子署名を使った (にもかかわらず) 欠陥つきの通信プロトコルを Man-in-the-middle 攻撃するための実装を書き、そのあと同様の攻撃が不可能になるよう プロトコルを修正して実装せよ」というものなのだが、実際には署名する範囲が アホいだけのことであり、C のコードでは数十行 変えるだけですんでしまうのだ。 しかしこのメッセージパーサの書き方は気にいらないなあ。おもわず書き直したくなってしまうが、 そんなことすると余計なバグの原因を増やすだけなのでやんない。 (テスト環境は OpenBSD で動くことが要求されている、こっちは Linux でコンパイルしてるから、 ヘタにあまりいじらないほうが無難)
ze-nzeん関係ないが、さいきん iTunes Music Store の素敵な使い方を発見した。 誰でも知ってる曲で検索して、その違ったバージョンをかたっぱしから試聴するのである。 "My favorite things" なんかは 100曲ぐらいあるが、これをきくと 「ほえー、みんないろいろガンバルよなー」と思う。 iTunes も Safari のようなタブ機能をサポートしてくれると検索結果をいろいろ表示して あっちこっち見れるのだが…
ふら
きょうは寝不足の屈辱をはらすために早く寝よっと。
さて、あまり翻訳できなかったが、今日のアホ slashdot はこれだ: カタツムリが ADSL を圧倒。 しかし実験が安っぽすぎて、これじゃハト版のほうがぜんぜん面白いよ。
ところで(てくる)「閂」という字は和製漢字ではなかろうか?
最後の論文は SSH のタイミング検査について。 SSH は暗号を使っており安全だと考えられているが (しかし以前のバージョンでは穴のあるプロトコルがたくさんあった、 これは SSH2 になってからも最初のうちはしばらく改善されない)、 実際には暗号化されていても「タイミング測定」によるパスワード破りが可能である。 つまり、ユーザの指がキーからキーへ動くには一定の時間がかかるので、 ある文字の順列の組み合わせはおおまかな時間の分布が存在する。 また、ユーザが su や sudo などでパスワードを打っているときには その文字はエコーされないため、行きのパケットしかこない。 こういう通信パターンを記録してそのタイミングを使い、 文字と文字間の遷移確率を求めて打鍵時間 (これは正規分布にしたがうと仮定) が 最適になるよう HMM でモデリングする (!) と、じつはランダムなパスワードでも かなり探索空間が絞りこめてしまうという話。あいかわらず brute force は 必要みたいだけど。それから ssh ログイン時のパスワードが 6文字以下だと、 これは 1パケットでぜんぶ送られてしまうので、これだけで「パスワードは 6文字以下だ」という事実が 盗聴側にバレてしまうとのこと
もうねる
っったく、なんでこんなに寒暖の差がはげしいですか? DMCA法違反で文藝春秋に訴えてやる!!
あるいはピンポ〜ン。、
だ、むったく。
翻訳してる時間がねーよ!
(追記) ラウンジにおいてあった 20日付の Post には一面にデカデカとこのおっさんの顔が載っているが、 絶対ヤバイって。これじゃカトリックもカルト教祖に逆戻りだよ! ほんとに。 西洋人にとっても「悪人ヅラ」ってのはあると思うのだが、その基準は日本とは違うように思える。 しかしアジアでみたらどうなのか。やっぱり違っているのか。中国や韓国ではどうなんだろう?
つうことで (何がつうことでだ?) 今日の (そんなにアホでもない) slashdot 抜粋:
こうして並べてみるとややカタカナが多い。しかしカタカナを書かないことにはしょうがない。 カシモカ病。Put soup mix in your cup. (スープをカップに入れます。) Add 8 oz. of really hot water. Stir. (8オンスの非常に熱いお湯を注ぎ、かきまぜます。) We recommend stirring in a counter-clockwise direction. (かきまぜる方向は、私たちは反時計廻りをおすすめしますが、) But it's not like we're watching you or anything. (別にそれを私たちが見ているわけではありませんので、念のため。)
日本のインスタント食品でつくづくよくできていると感心するのは、 こういう粉末状のスープがじつにお湯に溶けやすくできているということである。 そしてパッケージも開けやすい。 こっちにきてダメなインスタント食品を見て初めてこのことに気がついた。 この Lipton のスープもそうだが、よく注意しないと粒が細かすぎて お湯のなかで固まってしまい、最後のほうでコナを飲むはめになることが多いのである。 でも日本のインスタント食品だとそういうことはまずない。 ついでにいうと、スープが入っている紙のパックも明らかに日本製とちがう。 中にポリエチレンでコーティングしてあるのだが、こいつがなかなかキレないために、 袋を開けるときに「うにーーーーーーーっ」とひっぱってやらねばならないのである。 これにひきかえ、日本製のパックはサっと横に切れる。 いやー、実は日本のインスタント食品ってのはすげえ技術だったんだな。 そういう細かいところをアメリカンは気にしないのだろうが、 オレが気づいてしまうっていうところに、日本人としての「血」を感じる。
おっ、ところで (てくるで) いま Google News のタイトル間違い を発見 ("YOUR E-MAIL ALERTS" という部分)。 日本語版ではまだよくみるが、英語版で、しかも CNN のようなメジャーなサイトでこうなるのは珍しい。 しかし、こいつのアルゴリズムはあいかわらず謎なんだよなあ。 なぜこんな部分の文字列をとりだしてくるんだ? 記事ともぜんぜん関係ねいだろが。 タイトルとして取る部分が毎回違っているというのも謎である。 こいつらがどんな素性を使っているかは知らないが、 たぶんあんまり HTML の情報は使ってないのだと思われる。 MSN Newsbot も学習のさいに HTML タグは全部とっぱらってるという話だったしな。 そういえば日本語版は、一時期の変態的なタイトルの切り出しはやめたのかね? あいかわらず Google はこっそりと迷走していておもろい。
連日こんなことを書いていると Google ウォッチサイトになり下がってしまう。やめねば。
最近、英語でも Google の検索精度はどんどん落ちているような気がするので、 ときどき Teoma を使うことがある。しかし Teoma はインデックス数がすくないし、遅い。 こっちがまともに日本語対応してくれたらなあ。 しかし、いまだに速度と安定動作という点で Google にまさる検索エンジンはない (ま、Lynx ではときどき向こうがおかしなステータスを返すことがあるケド)。 結局、こいつらは優秀なシステム屋 (と、優秀な弁護士) に救われてるんだろう。 つまり、Web 上で商売するならこうした足まわりはいくら頑丈に固めてもしすぎることはないってこった。 ちなみに新山がさいしょに Google の評判を聞いたのは「この検索エンジンは速い!」というものであった。
新山が Traiss をはじめたのは、日本人も LWN を読むべきだと 思うからである。ChangeLog.net が停止して何年もたったが、いまだに日本語で書かれた Linux 関連のニュースの数はたいして増えていない。いや、japan.linux.com などはあるのだが、 「どこそこの企業が新しい Linux ソリューションを発表!」みたいなエラい人向けの記事ばっかりで、 ぜんぜん現場の人向けではない。ITmedia などにはまともな記事もあるが、これもほとんどは ZDNet からの翻訳である。草の根レベルで日本語の情報を発信しているところがまったくないのだ。 こいつはどういうわけなのか。しかし新山にもそんな時間はないので、それならすなおに LWN の記事を翻訳したほうがまだましだ。
Traiss のデザイン上のゴールはいくつかある (ちなみに Traiss は translate + RSS + trace の適当な合成語である 、発音は「とれいす」)。まず、なにより簡単・お手軽に翻訳できなければならない。 LWN の翻訳をしようと思ったとき、いちいち情報をとってきて、 翻訳して、また HTML でどっかにコピーするなんていうことはやりたくなかった。 お昼ごはんを食べながら、ブラウザ上からちょろっと翻訳できるようなツールが欲しかったのだ。 だから何もしなくても RSS の取得と、翻訳の公開はほとんど 自動的にやってくれるものでなければならなかった。そうでないと長続きさせるのはむずかしい。 そして、とにかく機能を単純にすること。ただ翻訳を入力してボタンを押せばすぐに公開されます、 というのであれば、誰がみてもわかる。いちおうヘルプは作ってあるが、 いちいちヘルプを読まなきゃ使えないようなサイトでは人は集まらない。 そしてすべての編集履歴を絶対に残すことが必要だった。これは荒らし対策ではなく、 人為的ミスをふせぐためのものである。とにかく Web アプリは failproof が しっかりできてないとダメだと思う (Google の成功は、インタフェイス部分の完成度によるものがかなりあると思う、 もっとも最近は凝りすぎていることが多いと感じるけれど、Google News のカスタマイズは 使ってる人いるのだろうか?)。そうしてもうひとつは、 これは基本的には記事を編集するので Wiki に似ているのだが、Wiki には 以前に誰がどんな編集をしたのか、その文脈が読みとりづらいという欠点があった。 だから、編集結果は「時間がたつにつれて色あせる」ようにしようと考えた。 こうすれば以前にどのあたりで活発な変更が起こっていたかわかるだろう。 これも履歴を保存しておけばできる。もっとも、RSS の翻訳程度だと短いからほとんど 動かないけれど。
つづく
そしてスケールする必要がある。RSS エントリは個別のファイルに保存されている。
1日に 20個のエントリが追加されるとすると、1つのサイト用に
1年間で 7000以上のエントリができることになる (todo: これはもうすこしたってから統計をとること)。
つうことは、すくなくとも数万〜数十万のエントリ数ですべての過去の
編集履歴を保存する必要があるわけだ。記事 ID は基本的に RSS の
<link> タグを MD5 したものを使っている (ま、こんなのに SHA1 を使う必要はないだろう)。
最初は description もふくむすべての項目を MD5 に入れていたが、
これだと途中で description が変更された場合 (Slashdot などではよくある)、
ID が変わってしまう。<link> はユニークであることが保証されているので、
たぶん大丈夫だろう。ひとつのエントリは原文と取得時間につづいて
0個以上の翻訳文 (途中の変更も含む) をふくんでいるが、
標準の RSS 1.0 には「その記事がいつ投稿されたか」という日付に相当する情報が
規定されていない。(dc:date は標準といいきっていいのだろうか?)
そしてデータベースについて。
最初は SQL を使うことを考えてたし、いま考えてみてもその方がラクだったと思うのだが、
なるべく「素の python だけ」で動かせるようにしたかった (さ来週あたりにはソースごと公開する予定である)。
MySQL とか SQLite を要求するのは管理に手間がかかりすぎる。し、最悪の場合 (ひどい spam 書きこみがあった場合など)、
管理者がデータベースを直接エディタで編集できるようにしておきたかったのである。
だからデータ形式はすべてテキストだ。中身は xml だが、履歴管理があるので、実際のファイルには
もう一層下の構造がある。ここでは過去の履歴に一発頭出しできるよう、
バイト単位のオフセットがものをいうので、だから厳密にフリーな
テキストではない (が、手編集は例外的な操作だと思うので、このときはファイル構造を consistent にする
ツールを用意している、実際にはまだ一度もこのデータベースを手で書き換えたことはない)。
実際のリポジトリの中身はファイルのハッシュ値上位 2ケタをつかって、256分割された
ディレクトリ中にテキストファイルを格納している。だからエントリ数が数万のオーダーになっても、
lookup にはそれほど時間がかからない (これは reiserfs にすればさらに速くなるだろう、
いまはまだ ext3 だが)。一度の編集・公開でスキャンするファイルはせいぜい 20 なので、
これはディレクトリのキャッシュがメモリ中にある場合ならトランザクションは一瞬で終わる。
データのロックはエントリごとにおこない、これはたんにファイル名を "ファイル名.locked" に
rename できるかどうかで判断する (これは新山がよく使うロックで、UNIX のファイル操作の
意味論ではこれはアトミックになるはずだ)。
このようになにか新しいことをやりだそうと考えるとき、 重要そうなファクターを洗いだしてそこから理づめで問題を解きデザインするというのは とってもおもしろいね。まだ規模が小さいから一人でできるのだろうけど。
つづく
しかし、LWN.net の記事でほんとうに翻訳する価値のあるのはじつは RSS で取ってこれるヘッドラインではなくて、 有料の Linux Weekly Edition である (なお、この有料というのは「最新情報」に払う寄付のようなものであり、 2週間以上前の記事は http://lwn.net/Archives/ へ行けばタダで読める)。 まあ、ヘッドラインだけでも、 www.linux.or.jp の ニュース から リンクされてる記事よりは使えるものが多いが、Linux Weekly Edition はまじめにすごい。 たしか rsync のバグだかのときは、exploit がどういうふうにスタックを破壊するかまで 詳細に (図入りで) 技術的解説を加えていた。こうした記事はかなり専門的な知識がなければ書けないし、 しかもセキュリティ関連はタイムリーでなければいけない。紙の媒体ではどうにもだめなのだ。 もし新山が日本で Linux を仕事に使ってて、英語をよむ速度が 今より 3倍くらい遅かったなら、 きっと金を払ってでも和訳を読みたがるだろう (しかしまあ、ユーザベースが小さいので、 商売にはならんだろうけど)。NewsForge の記事もわりといいのだが、こちらのほうが 「エラい人向け」だ。LWN のほうがわずかに現場寄りである。そして新山にとっては こっちのほうが堅実に見える。ソフト紹介記事もこれまたいい。 こだわり編集者の図形編集ソフト・ガイド なんかは じつによく書けている。 こういう「現場っぽい」 Linux 情報が日本で出てこないというのはなんでなのかな。
それはいいとして。
新山は博士学生のなかでもわりかしあっちこっちの関係ない分野に 顔をつっこむほうだと思うが (まだ学生だしさ)、計算機科学のいろいろな研究分野をみていて 気づいたことがある。いちおう、うちの学科では OS やらソフトウェア工学やら 暗号やら CG やらバイオやらのそれなりに多様な研究をやっているのだが、 どうも、全体としてみると、かなりそれぞれの分野が「バラバラ・すかすか」して見えるのである。つまり、
とりわけ新山の知ってる範囲でいえば、自然言語処理の研究者にしてはわりとあっちこっちに 手を出す“あやしい”タイプであるセキネさんを見ていても、基本的には彼は自然言語処理の範疇で 扱える問題だけしか見ていない。それは情報検索や文書理解 + αってとこだが、 ま、たしかにそれが専門だからそれはそれで堅実な態度だとは思うが、 たとえば「自然言語処理 + DB」とか、「自然言語処理 + ソフトウェア工学」とか、 一見ぜんぜん違っていそうな分野と手を組むと、まったくべつの問題が実は現れてくるかも しれないのだ。こういう「結婚」をしないと計算機科学というのは (まあ、これをひとかたまりの「分野」と呼ぶとして) このままどんどん衰退していきそうなのだが、ほとんど誰もそういうことをしていない。 機械学習はたしかに自然言語処理にのっそり入りこんできたが、これは「結婚」というよりは、 「感染」という感じであった。これは言語にまつわる問題をほとんど何も解決しておらず、 さらに深刻なことに何の問題も作りだしていない。 学問としての地平は何も広がってはいないのだ。すべての問題をタグとか素性とか classification として 扱うというのは、これが退化でなくて何なのか? しかし、いまさらこんなことをいってもしょうがない。 とにかく、学問の生命線というのは何をおいても「問題を発見する」ことにあるのだ。 解決が重要なのじゃないの? と思う人がいるかもしれないが、問題がひとたび発見されてしまえば、 解決は簡単なのである (解決できる問題はよってたかってみんな解決してしまうし、 解決できない場合はしばらくやってみて諦めるか、しばらく放置するしかない)。 むしろ、まだ気づかれていない問題を問題と認識するのが本当に大変なところなのだ。 こういうのはワインバーグの本をちょっと思い出すね…。そう考えると、 研究者もコンサルタントもその根本的な動きは同じである。 計算機ってのはもっと世の中に対していろんな役にたつことができるはずで、 ただその可能性がまじめに発見・認識されていないだけだと思うのだ。 問題は、こうした異分野の交流ってのがなぜ少ないのかということ。 異分野ったって、べつに法学部の人々と手を組むわけじゃなしさ。同じ学科で同じフロアなんだけど。 日本でそういう変なセクショナリズムが幅をきかせるのは理解できるとしても、 ここアメリカでもそうなのはなんでだろう? それでも東工大にいたときは、 タナカ先生はとなりのフルイ先生の研究室となんとかして連携しようと苦労していたぞ (フルイ先生は音声認識をやっている先生で、外部からみると自然言語処理と音声認識ってのは かなり近そうにみえるが、じつはほとんどお互いに理解できない世界なのである! これが専門というモノだ…)。 MIT あたりではたしかに計算機科学といろいろヘンなものを融合させていそうだが、あそこだけじゃつまらんな。
ひとむかし前なら、こういうのは「学際」って呼ばれるのかもしれないが (そういうのが一時期ハヤってた、そういやなんにでも「なんとかシステム学」って 名前をつけるのが異様にはやったことがあったな、そんなこともあったよ)、 これはほんとに「学際」なのか? 同じ計算機科学じゃねーか! なんだか、お互いに「自分のやってる分野はこういうモノだ」という固定観念が できてしまっていて、それをもとに問題を決めているようなところがある。 こういう態度だと、今後の学問的研究というのはどうなってしまうのだろうか。 これじゃ衰退してもしょうがないと思う。
くりかえしますが、新山は学術研究者になるつもりはありませんよ。
なぜかっつうと、まともに研究するには米国に残らねばならず (日本じゃあと 30年たってもダメそうだ)、 オレにとっては日本に帰って山菜食うほうが重要だからである。 まあ、何とでも言うがいいさ。
てくるで、さっき非常カッコいい「PATH ロゴ入り Tシャツ」を着ているインド人を発見した! PATH とはとーぜんあの地下鉄の PATH のことである。 左腕に「NJ」、右腕に「NY」、そして胸のところにはデッカイ「P」の文字が!!
