いろいろ見ていた中で拾ったネタです。21世紀ももう７年が過ぎましたのですが、

21世紀における科学の達成は？

と大上段に構えた問いをすると、「ポアンカレ予想」の解決とかいろいろありますけど、コンピュータと密接に関連するもので実はこんなのがあるのです。

決定的でかつ多項式時間で終わる素数判定法

が、2002年に出ています。これを発見したのはインド工科大学の Agarwal 教授と２人の学生による、AKS素数判定法というやり方です。まあ、素数判定法というと、いわゆる「フェルマーテスト」と、そのウラを掻いてしまう合成数をなくす改善をした、ミラー・ラビン判定法があって、これらは簡単に実装できるので、暗号ライブラリなどでよく使われているわけです。

しかし、フェルマーテストやミラー・ラビン判定法は、「確率的」な判定法です。言い換えると、「１００％ではないが、独立に試行できる判定法を繰り返し適用することで、合成数が返ることを極めて低い確率にできるアルゴリズム」のわけです。まあ、勿論これで実用上は問題がないわけですね。

しかし、「確率的ではなく、決定的なやり方で、しかも本当に素因数分解するようなやり方ではない」やり方があるのだろうか....という謎に解決がついた、ということなんですね。まあ、計算量理論の上では、「Ｐ問題」と「ＮＰ問題」というような言い方で区別するわけですが、このAKS判定法によって、

決定論的な素数判定は、Ｐ問題である

ということになった、というのが非常に興味深いところです。このやり方は私が理解する範囲だと、「チェックすべき範囲を有効に制限でき、その範囲でのチェックが通ることが、素数である必要十分条件だ」ということが証明できる、ということのようです。

とはいえ、実際にこのアルゴリズムを適用するには、やはりステップがかかり過ぎる、というのがあって、必ずしも既存の確率的素数判定法を駆逐する、というわけにはいかないようですが、それでも、

素数判定が本質的に「やさしい」（実際には時間がかかるのですが）問題だ

ということが厳密に証明された、というのは面白いことです。で、やはり更に興味深いのは...やはり「インド」というあたりでしょうか。「未来のＩＴ大国？」などと注目されるインドですが、やはり神秘の人ラマヌジャンの国でもあり、もう少し身近なあたりだと、ドラゴンブック（そういえば洋書では第２版が出てますね...メチャ高いんでびっくりしますけど）の Ravi Sethi がやはりインド出身だったりします。Ravi Sethi だって、その名のついた「Sethi - Ullman数」で有名なわけですし....というわけで、「インドの神秘」というのを、何か個人的に印象強く感じます。 

以前の記事で「プログラミング Gauche」の話をしましたが、発売記念イベントがあるみたいです。オライリージャパンの「オラの村」に出てました。

プレスリリース

で....これの主催者が「へそまがり算法騎士団（gauche.knights）」だそうです....

ま、その昔ＭＩＴで「λ算法騎士団」という有名？な秘密結社（というほど大げさなものではないようですが）があったこともあって、これにアイデアを受けてアニメの「serial experiments lain」で、「東方算法騎士団」なんていうネットを操る秘密結社なぞのネタになったこともあって、どうも「算法騎士団」って言い回しにヨワいです（あ、勿論「秘密結社」はジョークで、単なる Lispハッカーのグループです。実は京都にλ算法騎士団の総本山があります）。

いいなあ....けど、東京ですものねえ。

とはいえ、ハッカーの極みみたいな Lisp 系ハッカーのパーティが、お台場のおしゃれっぽいクラブ（TOKYO CULTURE CULTURE）のイベントになる....というのも、何か lain っぽい世界のような気もします。ま、意外にこういうノリが先端になるかもしれませんね。

さて、今回は仕事で出てきたネタです。

Java のWebアプリでリアルタイムに作っていたデータがあるのですが、この処理が重過ぎるので、「予約」だけを Web アプリ上で行わせるようにして、結果は後で取りにいくことにしました。じゃあ、実際にその「重過ぎる」処理をさせるのは、サーバの上で別に動くデーモンプロセスです。

親和性とか考えますから、そのデーモンプロセスはやはり Java アプリです。これは起動に時間がかかることもあって、cron 仕掛けではなくて、java.util.concurrent.ExecutorService を使い倒したマルチスレッドで動くデーモンにしてあります。で...問題はこれを停止したい、という時の話です。

今までは単にプロセス kill で殺してました。が...やはりこれ、偶然、作業中ですと大変まずいです。ＤＢの一貫性がなくなっちゃうかもしれません。ここで「どうしよう？」で考えたのが、「自前の MBean によるシャットダウン」です。

まあ、MBean はアプリ開発のレベルだと「とっても地味な」機能です....あることは知っていても、「どう使うんだろね...そりゃサーバを管理するんだと使うけどね」という感じの方が多いのではないでしょうか。

実際、デーモン側でこれを導入するのは、実はすごく簡単です。ここあたりを参考にして書くと、ShutdownBoxMBean とかいうようなインターフェイスを定義して、実際のサービスの名前（MBean規約でこれが固定されるのは妙ですが...）は、これを implements して ShutdownBox とでもしましょうか。で、このメソッドの中で shutdown() が MBean サーバの中（そのスレッド）から起動され、ループ停止予約をする...というかたちでいいでしょう。

この段階で、たとえば

http://localhost:8082/

といったＵＲＬでのブラウザ経由でのＧＵＩ的な管理ができるようになります。

これ、逆に言えば、「HttpClient とか使えば、そういうコマンド書いていいんじゃない？」ということになります（まあ、手を抜いてそれこそ wget とかでもＯＫですよね）。実際この MBean サービスでの shutdown() の起動のURL は、

http://localhost:8082/InvokeAction//ShutdownBox%3Aname%3DShutdownBox/action=shutdown?action=shutdown

というかたちになります。このURLを GET メソッドで叩きさえすれば、デーモンの shtudown() が起動される...ということになって、「安全なシャットダウン」が出来るようになるわけです（もう少しURLが簡潔だといいけどね...）。

このように「操作をURLにマップする」というのが、汎用的なやり方で出来るようになっている....というのは、実はとても重要なことなのかもしれません。REST と RPC の違い...というのも実は、

動作をURL（だけに）にマッピングできるか？

という点だったりするわけです。実は MBean とは、REST の仲間なのかも...と実感しちゃったわけです（苦笑...でも副作用のあるGETはイケてませんが）。

参考：ソース　mbean.zipをダウンロード

そういえば、オライリーのＨＰを見ていたら、こんな記事がありました。

プログラミングGauche 鋭意製作中

だそうです。あ、Gauche って、日本で作られた Scheme 処理系です。

勿論オライリーといえばハッカー御用達のコンピュータ書の版元です。それこそ「何冊オライリーを読んでるか？」で実力が判る...と言ってもそうそう誇張じゃないくらいですよね。ですから、オライリーの扱うジャンル、ってかなり幅広くて私も完全にすべてのジャンルをカバーなんてできっこないのですが....それでも、

関数型言語についての入門書がない！

というのは、ちょっとヘンテコなことでもあったわけです。現行のカタログを見てみると...

C, C++, Java, Perl, Python, Ruby, sed/awk, bash, csh, ksh, JavaScript, PHP, C#

と大概のメジャー言語入門書があるにも関わらず、

Lisp, Scheme, ML, Haskell, Erlang などの関数型言語についての本

はまったく無かったわけです。まあ、オライリーは「プログラマの実用書」っぽいノリがありますから、やや「理屈寄り」な関数型言語はスコープの範囲外...みたいに感じていたのはないでしょうか。

まあ、どうもこのところ、

関数型言語の風

みたいなものが吹き出したような気がしないでもないです。影響力の強いレイモンドの「ハッカーになろう」でも、ハッカー特選言語とされているのは、

Python, Java, C/C++, Perl, Lisp

の５つが挙げられているのはほぼ常識の部類です。そういう「古典」レベルの話ではなくて、たとえば、

• Javaスクールの危険(Joel Spolsky)
• 普通のやつらの上を行け(Paul Graham)

といった人気記事が一貫して「関数型言語は重要！」と強調しており、JavaScript を「Ｃの皮を被ったLisp」と呼んだ「JavaScript: 世界でもっとも誤解された言語」（Douglas Crockford）が、JavaScript のパワフルな側面（それもLisp起源の機能を使っての）を世に知らしめた...というような流れがあるのでは？などと感じます。

まあ、このところの Haskell ブームもこういう流れが基調にあるのでしょう....ちょっと今年は

関数型言語復権の年？

みたいな色彩を帯びるのかもしれませんね。

ひょっとして仕事で使うか？というアテ込みで勉強しだしたのが、例の「comet」です。こんなシナリオかな。

1. 1. 時間のかかる処理を予約する。たとえば集計したのをExcelで出力する...とかイメージするといいかも。
2. 2. 予約を受け付けたら、そのまま他の作業。
3. 3. 集計が出来たら、ポップアップが「勝手に表示」して、「出来たよ！」と伝える。
4. 4. （たとえば）Excel をダウンロードして結果を見る。

要するにキモは「（擬似）非同期処理」です。クライアントプルではなくて、一見サーバプッシュに見えるような、「依頼→通知」モデルの擬似イベント処理ですね。

勿論この3.で「勝手にポップアップ」するのは、常識的に Ajax です。汎用的に使う JavaScript ライブラリにでも、この comet 使いのAjaxスクリプトを入れておけばいいでしょう。で、その接続先であるサーバは、どんな風に出来ているのでしょう？

これ、Tomcat 6 の新機能である、CometProcessor インターフェイスと event() メソッドが担当します。要するに、Ajax から CometProcessor を implements したサーブレットにアクセスすると、event() メソッドがコールバック的に呼ばれ（ここらへん doGet() とかと感覚一緒）、レスポンスを返したりできるのですが、

接続を切らない....

のがサーバ側でのポイントです。ですから最初のアクセスの後、「繋ぎっぱなし」になります。そこで主導権はサーバ側に移ります。勿論クライアント側では Ajax で接続をするので、たとえ「繋ぎっぱなしで結果が返らない...」でも少しも困らないわけです（ま、タイムアウトしないようにすべきですけどね）。サーバ側ではたとえば「データが出来たよ！」というタイミングで、何かクライアントの間で決めたレザルトを返すのがいいでしょう。で、接続切断、という流れです。

結構使えそうな気がしますよね....イベント処理のやり方の都合もあるので、渡したいパラメータは、body として流すよりも URL に畳み込んで REST 風に設計するといいのでは...とも思います。

この comet の処理のベース、というのは、実は java.nio パッケージだったりします。使ってます？ NewIO ？ 私もこれが「ある」ことは知っていても、使ったことなかったです.....JDK1.4 で登場しているんですけどね。要するに「select(2) 可能なソケット」というのが、java.net とかでは出来ないこともあって、この java.nio.channels.Selector などを使って実現しているのです。まあ、いちいち接続ごとにスレッドを作ってたらたまらないですからね。いわゆる C10K 問題、というものです。

現実の仕事でこれ、使ってみたいですね、面白そう！

やたらと気の長い話で恐縮です。

2022年というと、今から 14 年後です....何でこの年かというと、

HTML 5の開発はいつ終わるのですか？

HTML5は、2022年以降にW3C勧告に至ると見込んでいます。2004年半ばから始めましたので、だいたい18年から20年の開発となるでしょう。

ということなのですね。去年１１月に「HTML Design Principles (翻訳)」が出て話題になり、こんな風に section だ header だ footer だaside だのと構造要素が増える..というのを知って「へえ～」な状況のわけですけども....今日付けでも新しく  A vocabulary and associated APIs for HTML and XHTML という大きな WorkingDraft が出てました。

例のREST本でも、「HTML5だとこうなるぞ！」なんて話が結構載ってたわけで、何かすぐにでも「来る？」というような気分は盛り上がるのですが、実際の開発スケジュールは先も先のいいところなのです。ま、REST だと、form タグの method 属性で PUT や DELETE を使える！としてくれないと困るわけですが、これはもう既にいろいろなブラウザは対応済み（規格を自前で先取り...）ですから、規格がないと実装が進まない...なんて話ではまったくないのですが。

とはいえ、2022年という年は一体どんな年になっているのでしょうか....

REST 話とも関連するネタです。そういえば「RESTful Web サービス」って、業界内の「話題の書」みたいな感じで、続々「読んだ！」ってブログ記事が出てるようですね（たとえばはてなだと...）。やはりこれ「冬休みの指定課題図書」になっちゃった人多数...のようです（苦笑）。

そういえば例の「Javaスクールの危険」でも指摘していることですが、

関数プログラミングを理解していなければ、GoogleをあれほどスケーラブルにしているアルゴリズムであるMapReduceは発明できない。MapとReduceという用語はLispと関数プログラミングから来ている。純関数プログラムは副作用がなく容易に並列化できるということを6.001に相当するプログラミングの授業で聞いて覚えている人には、MapReduceは容易に理解できる。

と、「関数プログラミングとスケーラビリティ」というのは、かなり密接な関連性があります。Lisp（ま、書き方には依りますが）とか Haskell みたいな関数プログラミング言語は、「副作用がない」という重要なポイントがあります。手続き型言語の場合は、「すべて副作用で計算が進行する」というのが演算原理になるわけですけども、関数型言語（特に極端なのは Haskell ですが）だと、

演算原理に一切副作用を含まない
→だから、容易に並列化が可能であり、サービスを拡大するには単にサーバを追加するだけでＯＫ。

という側面を持つわけで、こういうスケーラビリティの「ねらい」の部分で、実は REST とも共通する問題が見受けられるように思います。たとえば、

1. 1.GET は副作用がないので、いくらでも（どのレベルでも）キャッシュできる
2. 2.PUT, DELETE は べき等に動作するので、何度同じリクエストが到来したところで、サーバ状態は（更には）変わらない

というあたり、「スケーラビリティありき」な設計のわけです。まあ、ここらへん、Web サービスが「現実のサービス」としてのリアリティをこのところ帯びてきている、という状況が、「REST ブーム」の基調となっているのかもしれません。

で....スケーラビリティという視点で考えてみると、やはり「開発言語」レベルでのアイデア、というものもありそうです。Java という言語は一応「並行処理」についての言語仕様（synchronized とか Thread クラスとかのマルチスレッド機構）を備えた言語ですが、やはりコレちょいと勉強（たとえば Doug Lea とか）が必要なものです。ですから、Tomcat+Struts とか使うと「とりあえず平行性は、なし、ね！」で設計することで、これほどの普及を見たわけですが...

いくら平行処理かつ分散処理したって、問題が複雑化せず、簡明に記述できてスケーラビリティについて配慮不要な（言語的）やり方

というのも、実は今後重要かもしれません。で...こんなのどうです？ Erlang です。

この Erlang については まつもとゆきひろ氏の記事が一番判りやすいかな。これによると、Erlang は分散・平行処理指向な関数型言語で、

1. 1. とにかく副作用がない言語仕様で、変数代入も1回しかできないし、グローバル変数もない。
2. 2. ＯＳプロセスや既存のスレッドモデルに拠らない、独自の「超軽量プロセス」を作れる。１プロセスあたり 300byte くらいしか消費しないので、いわゆる「C10K問題」を考えなくてＯＫ。
3. 3. その超軽量プロセス同士は、一切「状態の共有がない」。で、プロセス同士の通信として、「メッセージベースのプロセス間通信」によって相互にデータを受け渡す。

というような面白い特徴を備えてます。今まで「趣味の関数型プログラミング（失礼）」だったのですが、意外に

非技術者に説明可能なメリットがあっての関数型プログラミング言語

というかたちで、広まるのかも....

明けましておめでとうございます。

さて、今日から仕事始めなので、今からこのブログを書きましょう。

で、やはりハッカーですから、

年に１つ新しい言語をおぼえるべし

というのは昔からの常識です。去年(2007)は Haskell でしたし、その前(2006)は何だろ...強いて言えば MovableType とかのマクロかな（失礼）。で、その前の2005年は遅ればせながらの PHP じゃないかしらん（PHPでの仕事を請けた）。で、その前2004年はMeyer 大先生の本を読んで Eiffel だと思う（あと比較対象として Eiffel に影響のある Ada）.....としてみると、やはり今年は

Ruby

ということになりそうです。何かこれも今更...な気がしないでもないですが、「RESTful Web サービス」の実装が Ruby on Rails を使って解説した...というのもありますから、まあ潮時かも。どうもスクリプト言語って

必要になったから覚える

という傾向がある（少しナメてるかなぁ）ので、かなり前（新刊だったから2000年頃？）に Windows の勉強を兼ねて、

Ruby を２５６倍使うための本 邪道編

を読んで面白がったけど、実践の機会がなかったせいか、あまり COM 使いにはならずじまいでした....（ま、.NET 以前の話だし）

そういえば Ruby って結構「何でも言語」の傾向がある（COMをいじり倒せるのもそうだけど...）から、少し Ruby のクロージャとか継続を研究してみるのもいいかな（継続は Scheme で憶えたけどねぇ）。→ここの解説面白いです。

既に終了したスタックフレームを黄泉の国から引きずり出してスタックにぶちこめるわけである。このときcall/ccが返す「スタックなどのコンテキストを記憶したもの」をContinuation（継続）と呼ぶのだ。