* 自分にとってアツいもの

着目している技術

C10Kやイベント処理	備考
libevent	高性能イベントループのライブラリ。ソケットやタイマ処理を多数多重化できる
libev	同上。高性能らしいがlibEventにメジャー度で負けている。node.jsの中身
D-Bus	Gnomeデスクトップ環境で用いられているプロセス間メッセージ交換基盤
thrift	マルチプログラミング言語RPC。Facebookチームが開発
Linda	イベントスプールにタプルや条件マッチを取り入れた概念
node.js	ついにJavascriptはサーバ側へ...

libeventは古くはXツールキット、あるいはGNU Zebra等で使われた手法と同じ、非プリエンプティブな多重処理方式です。IISのWebサービス等、イベントごとにスレッドを割り当てる手法がCPU性能を活かしきれないことが明らかとなったため、その対抗概念としてC10K(クライアント1万問題)の認知と共に、温故知新で注目を集めています。

旧来と違うDB(NoSQL等)	備考
SQLite	オンメモリ or ファイルDBにSQLでアクセスできる。
FastDB	オンメモリ or ファイルDBで、オブジェクト型。SQLiteに水を空けられたか
NoSQLを超えるSQLデータベース「VoltDB」	オンメモリDBで、Ingresの作者さんだそうです
IMAP4	メール受信用プロトコルとしてだけでなく、クラウド応用ができる

私は従来の"order by"の概念を壊して、最終的なソート処理をクライアント側へ持っていかないと、もはや時代にそぐわないと考えています。2層DBのフロントエンドDB処理(タスク分配と、バックエンドDBから返った結果をマージソートする)と、その後のプレゼンレイヤ処理を、かな漢字変換の高速化策のように、随時やるイメージ。Webシステムのクライアント側でソートの最終調整をするためにはAjaxなりCometなりで後から挿入できることが必要。
おっと、ACID緩めるのも必要です。

ドリームの話	備考
ガベージコレクションせず、かつ利用が簡単なプログラミング言語	GCは結局プログラマを楽にしない
CPUコアを限定することでロックを減らすマルチスレッドプログラミング	クルー指向とか言って検討中

• ガベージコレクションせず、かつ利用が簡単なプログラミング言語

I am one of "Gabage Collection Hater." その対案は、CPythonやC++等、デストラクタ起動タイミングが明確な言語でのauto_ptr風パターンと、「言語文法レベルで定義されたコレクションライブラリ」を使うこと（で、解放処理を簡単にする手法）です。
Javaは確かに生産性が高いですが、Stop the World問題をクリアできない。
「プロがつくるプログラム」としてのソフトウェアは、オブジェクトを作ることより破壊することを制御できるべきであると考えます。ヒープオブジェクトのGCに反対。スタックオブジェクトのautoポインタに賛成。->"+ アペタイト フォー デストラクション"
「言語文法レベルで定義されたコレクションライブラリ」については…別途書きます。

• CPUコアを限定することでロックを減らすマルチスレッドプログラミング

libeventにしろ、node.jsにしろ、非プリエンプティブな擬似多重化ライブラリは、とても筋がいい技術。ただしイベント発火が全部別スレッドだと、遅くなるしメリットを活かせない。一方イベント発火が全部同一スレッドだと、速いし排他不要だし割り込まれるポイントが明確だしで良い点が多いが、マルチコアCPUを活かせない可能性がある。ならば、イベント発火スレッドは数個として、プログラマが、イベントコールバックの「グルーピング」を指定し、どのイベント処理スレッドで起動するか指定できればよい、という話。できますよね。
要は「RunnableにCPUコアをbindしたもの」を○○(例えばcrew)などと呼んで擬人化(擬物化)し、イメージしやすくする、ということ。(まぁ、普通にマルチプロセスでもいいんですけども)

リンク:

• + Crew指向プログラミング言語
• # GCなし、コルーチン、node.js、Lindaを合体