ぜんぶに目は通してないけど、日本人は FSIJ に二人、 ES Operating System に一人、 WebKit に一人の計4人かな。もっといる?
あんまりあれこれ言うのも何なんですが(あと応募したけど落ちちゃった人に鞭打つつもりはないんですが)、少ない気がするなあ。みんなこういうことに興味ないんだろうか？ 前も書いたけど、 SoC はオープンソースソフトウェアの振興というよりはコミュニティの振興が目的なので、生み出されるソースコードそれ自体は、そんなに重要じゃないんだよね。だからこそ、どうやったら応募が増えるのかということが気になっているのだけど。しかし単に興味がないのだとすると、これは難しいよね。
ともあれ採択された皆さん、おめでとうございます。ぜひ採択されたプロジェクトを楽しんでください。ってこんなとこに書いても読まないか。
土曜はSFファン交流会へ。大森望、柳下毅一郎、樽本周馬というゲスト陣だったからか、60〜70年代SFという企画がよかったからか、ともかくえらい大盛況。昼間も狭い部屋にひしめいていたが、二次会は店に入りきらないほどでエライことになっていた。
そんななか、こっそりとさいのさんから《魔王子》全5巻を譲り受ける。傑作であることと入手難であることで有名なシリーズだが、個人的にもすごく思い入れがある。ただ最初に読んだときは高校の図書館でのことだったので、既読なんだけどずっと持っていなかった。ようやく手元に持っていられる。よかったよかった。よかったといえば国書刊行会からはヴァンスコレクション全3巻が出るのだそうでこれも楽しみ。
そういえばジーン・ウルフの《新しい太陽の書》は新装版を買うべきかどうかで悩む。旧版の4冊は持っているのだが未読。今回ので訳も変わっているらしいし、新訳となる5巻も出るからなぁ……。
会が終わったら移動の途中で抜け出し、新宿のブックファーストへ。ひとつ前の購入本リストはそのときのもの。渋谷ブックファーストも悪くはないのだが、やはり見落としが増えたなあという印象。
二次会では林哲矢さんがファイアボールなどを勧めていた。のでさっき見たけどなかなかよかった。webで1話と7話が見られる。お姫様のドロッセルと従者のゲデヒトニスという二人(二体?)の噛み合わない会話がちょっとツボ。
ちょっとツボといえば同じく林さんのお勧めのウサビッチも面白い。なぜかロシアでのんきに囚人をやっているウサギ二人(二匹?)と看守とその他の話。淡々と面白い。個人的には第5話「ダンスの時間」がよかった。
テレビがブッ壊れてから基本的にテレビなるものを見ていないのだが、こういうようにwebでも見られるものがあるのは嬉しい。
ここ最近、 Becker’s の「粗挽き200Gバーガー」というのをときどき食うのだが、あれはいいね。あんまり食うと太りそうだが。
アメリカで食ったハンバーガーはボリュームも物凄かったがなかなか美味しかった。あれは日本のファーストフードではまず食えないといっていいものだと思うが、200Gバーガーはわりといいセンを行っているような気がする。とにかく肉！肉！肉！という感じで、しっかりと肉を食ってる感覚が味わえる。完全にアメリカナイズされてるわけじゃなくて味付けは日本人好みに調整されている感じなのもよい。
ところで、ハンバーガーは完全食であるという妄言を知っているだろうか。あれは完璧に妄言だと思っていたが、最近はそーでもないと思っている。つまるところ、アメリカ人の日常的な食事というのは、パンがあって、肉があって、サラダを食うといったところであり、これをぜんぶを一緒くたにするとハンバーガーになるわけだ。一食分をまとめて食すので完全食。つまり牛丼とかのような丼モノも完全食だというリクツだな。
栄養バランス的にどうなの、というマトモな指摘はごく真っ当なのだが、元からして妄言なのだから気にしたら負けだ。
ところで Becker’s の自家製ジンジャエールはなかなか良いね。
http://slashdot.jp/askslashdot/article.pl?sid=08/04/14/2235245
むかし Gentoo を使ったとき、標準で cron が入ってなかったときの痺れるような衝撃を忘れることはできない。 Gentoo は cron のパッケージだけで数種類はあるので自分が好きなものを入れることになる。ぼくは vixie-cron を入れたのだが、「cron すら自分で使いたいものを決めさせる」という思想にビビったことであるよ。さすがにそんなところは選ばせなくていい。
しかしまあ、それ意外は何がなくてももう驚かないよ……たぶん、きっと。
あるなしで言えば、最初から入っているものよりは、パッケージシステムを使ってインストール可能でないのは何か、ということの方が重要だよなあ。
いちぶで話題らしいのですが、 Google という会社のプログラマというのは実に高給取りだそうで。ちなみに indeed.com というところで同じように調べてみたという話を同僚に教えてもらいましたが、
http://www.indeed.com/salary?q1=google+programmer&l1=94043&q2=google+software+engineer&l2=94043&tm=1
ソフトウェアエンジニアじゃなくてプログラマにならなければ。
ちょっと追記(やや真面目モード?):
GIGAZINE も同じネタを取り上げてるみたいですね。あーああ、って感じ。これでもう完璧に誤解は広まっていって消えないんだろうね。前にあった面接の問題の話も、鵜飼さんが「そんな質問はしない」って明言してたのに未だに信じている人いっぱいいるからなぁー。
http://ocaml.jp/ が、これまでの管理者の真耶さんから ocaml-nagoya に移ってリニューアル＆活動再開とのこと。
http://www.freeml.com/ocaml/41?sid=d6890d111556417dd319aad65f323b1f いやーこのメーリングリスト、オレまだ入ってたんや……という感じでした。
あとで時間があったら、1ずつ増加してるとかキーは文字列だろ常考とかいうあたりをつつこうかと思っているだけでやってくれる人がいるので世の中というのは楽に出来ている。
http://www.kt.rim.or.jp/~kbk/zakkicho/08/zakkicho0804a.html#D20080409-4
ハッシュ表でも拡張可能なものがあったり(むかーし技術評論社から出ていた雑誌で読んだ記憶が。誌名は忘れました。SoftwareDesignとかプロセッサではないです)、全要素のハッシュ値を再計算してより大きな表に切り替える(PerlとかRubyでやってますね) という手段があるわけですけど、連想配列の、「数値以外のオブジェクト(という表現でいいのだろうか)で添え字付けする」という性質にのみ着目した場合にハッシュ以外の手段を採用した方がよい場面もあるんじゃないのかなあという考えが念頭にありました。
データ量が漸進増加するときに遅くなる可能性は確かにあるけど、平衡木だって回転させるコストも発生する。もちろん木の探索と回転は O(log n) なのに rehash は全要素を再配置するため遅くなりそうだが、新しいサイズをうまく取るとならしコストは O(1) になりそうな。検証してないけど(これと同じリクツ)。
ちなみに Haskell (GHC) では Data.Map がよく使われる気がしていて、これは AVL 木なんですが、なぜかというと関数的に書きやすいから(たぶん)。ハッシュ表も GHC には標準で存在するものの、関数的ではないので IO を伴い、書きづらい。ただし圧倒的に速いです。ちなみに GHC には IntMap なるものもあり、これはパトリシア木(Trieの一種)を使っていて速いらしいのだが IntMap はほとんど使ったことないな。
それから dbm では単純なハッシュのものもあればツリーのインデックスを使うこともあって、前者は gdbm とか ndbm とか cdb とか qdbm の Depot とか。後者は Berkeley-DB とか qdbm の Villa とか。でも BDB も qdbm も B+tree だね。 Tokyo cabinet はどうだったかと思ったけどやっぱりハッシュとB+tree と両方が用意されるらしい。
dbm がツリーのようなデータ構造を利用するのはまさに順序が重要だからで、特定のプレフィクスをもつキー集合とか、特定の範囲内のキーに対応する値を取り出すとか、 sql の where 節に書ける程度の演算はそこそこ速くやってほしいのでそのようになっているのだと思われます。一方たとえば skk の辞書みたいなやつは完全一致以外を考えなくていいので、こういうのはハッシュで充分なわけで、 cdb を使った skk サーバみたいなのが出回っていてこれがめちゃくちゃ速かったりする。
http://www.kt.rim.or.jp/~kbk/zakkicho/08/zakkicho0804a.html#D20080408-2
詳しくは後で書くかもだけど、とりあえず SGI のページを見るに hash_set は Hashed Associative Container であり(ちなみに set は Sorted Associative Container)、その説明には
A Hashed Associative Container is an Associative Container whose implementation is a hash table. [1] The elements of a Hashed Associative Container are not guaranteed to be in any meaningful order; in particular, they are not sorted.
なんてのっけから書いてあるわけですから(強調は引用者)、 hash_set が順序を保持しなければならないというのは間違いですよ。
実際、ハッシュ表は探索木のようなものと違ってデータが全順序である必要がないことが重要だと思うわけですよ。
http://ascii.jp/elem/000/000/122/122037/
それ skk でできるよ的な。
というわけで、日付/時刻、アノテーション、自動学習、専門辞書セット、方言などへの対応、キーカスタマイズと半分くらいは完全に出来ている。予測入力もまあできるといえばできるし。
こうやって簡単に列挙できるようなものは実際にはそれほど重要ではなく、変換エンジンにとって重要なのは精度だろうと思う。 skk はその点でも優れていておおむね問題ないのだが、同音異義語でだけ苦労する(意外と以外が代表格)。そういえば skk の変換にバイグラムの推定をすると同音異義語が以外とクリアに処理できるんじゃないかというアイディアを持っているのだが、まだかたちにできていないなあ(bayesian-skk と発想は似てるけどちょっと違います、いちおう念のため)。
それにしてもだな、 ATOK って 2008 になってからやたらと記事を見かけるような気がするけど、いったいなぜ?
どれくらい珍しいのか知らないがうちに来た。こんな感じの文面。
To: ——– Subject: Our programme terms have changed. From: "AdWords-NoReplay"<adwords-noreply@google.com> Date: Fri, 4 Apr 2008 15:11:59 +0000 X-Mailer: The Bat! (v2.00) Business Reply-To: flowerpuffs90@yahoo.com X-Priority: 3 (Normal) Message-ID: <235281029.93939588069892@yahoo.com> MIME-Version: 1.0 ————————————————————————— Dear AdWords Customer, As part of our ongoing efforts to improve the Google AdWords programme for advertisers and users, we have updated our Terms and Conditions. Please review the new Terms and Conditions below, then indicate your acceptance. Yes, I accept the above Terms and Conditions. —————————————————————————– This message was sent from a notification-only email address that does not accept incoming email. Please do not reply to this message.
実際には HTML メールになっていて、 HTML パートには「Yes, I accept the above Terms and Conditions」が偽ページへのリンクになっている。 From は詐称しているが Reply-To が元のママだったりとツメが甘すぎるが、あんまり見かけない気がするので貼ってみた。
