当たり前じゃん、と思うじゃろ？ それが他の言語のコンテキストを強く頭に持っているとすぐに発想できんのじゃよ、という話。
やりたいこと
長時間実行するのを前提にした Web アプリ、Web アプリというか単にバッチ処理を PaaS で動かす際に entry point が HTTP に露出しているだけのものがあって、その際、時間の掛かる処理の完了を待たずに 202 Accepted や処理中を意味する status をさっさと返してしまいたい。
前提
- HTTP request については適切にアクセスが制御されており、不必要な request が大量に来ることはない
- 長時間掛かるので内部で state を管理する必要があるが、その部分は完成しているものとする
例えばRubyだと
最もカジュアルな方法を、例えば Sinatra っぽい何かと日本語で書くとするとこんな感じになるかな。
post '/' do
if (state は処理中ではない)
Thread.new {
storage に処理中の state を保存
longrun_process()
storage に完了の state を保存
}
[202, {}, []]
else
[412, {}, []]
end
end
def longrun_process
...
end
Thread を使って一応期待通りの挙動になることは確認できた。
これを JavaScript でやりたい。
結論
express っぽい何かと日本語の擬似コードで書くとこんな感じになる。
post('/', async (req, res) => {
if (state は処理中ではない) {
await (storage に処理中の state を保存)
longrunProcess().catch((e) => { throw e }) // <- await を付けない!
await (storage に完了の state を保存)
res.status(202).send()
} else {
res.status(412).send()
}
})
ポイントは「待たない処理について await を付けない」これだけ。
ただし、ちゃんとケアしないと UnhandledPromiseRejectionWarning が出るので注意。
間違った考え方
async/await の世界に慣れて、非同期も待てるのが前提の頭になってしまって以下のように考えていたが、これは間違っていた。
- Thread を使えばよいのか？
- Fiber を使えばよいのか？
- え、もう setTimeout({}, 0) でよくない？
JavaScript でのこれらの言葉は Ruby や他の同期的な処理を基本にした言語で考えていた使い方とはだいぶ異なることが分かった。
- Thread
- JavaScript の Thread は Worker を形成するための JavaScript のファイルを用意してそこから Worker を立ち上げることから始まる。当然名前空間は完全に丸ごとベツモノになり、呼び出し側で require 済みの module なども何も利用できない。
- カジュアルさに欠けるし、やりたいことを実現するためのコード量はだいぶ多くなる。
- Fiber
- https://github.com/laverdet/node-fibers
- 名前からしてこれっぽいし、挙動としても完全に期待通りだったが、ドキュメントにはできれば使うなと書かれていて、確かに不要だった。
ちなみに node-fibers を使ったコードはこんな感じになる。
Fiber(async () => {
// ここにバックグラウンドで動いてほしいコードを書く
}).run()
「await を付けない」よりは明示的でとても嬉しいコードに見える。現在の Promise 前提のコードでも意図的にこういう wrapper を作ることは恐らく可能だと思う。
ちなみに、setTimeout({}, 0) を使う方法でも概ね似た挙動を実現できるんだけど、時間の掛かる処理に入る前にその下に書いたコードが動いてしまうのと、意味合いをつかみにくいのであんまりよくないかなぁということを現時点では考えている。なんとなくイヤなにおいがする。
まとめ
JavaScript はもともと非同期でした。async/await に慣れてほとんどすべての場合で await を付けて処理を書くようになってしまった今こそ、await を付けない挙動を今一度確認し、必要な場合は外しましょう。
おまけ
Worker Thread の上の特徴を理解したうえで完全に CPU bound な処理だけを background に回したい場合は以下の microjob という npm が使える。
https://wilk.github.io/microjob/
データだけは data や ctx で渡せるので、必要な module が何もない場合は以下のように簡単に使える。これはREADME のコードを端折ったもの。
(async () => {
const { job, start, stop } = require("microjob");
try {
// start the worker pool
await start();
// this function will be executed in another thread
const res = await job(() => {
..
});
console.log(res);
} catch (err) {
console.error(err);
} finally {
// shutdown worker pool
await stop();
}
})();
依存しているものが一切ないことはほとんどないと思うけど、単に await を付けないだけよりは分かりやすく安全なコードを書けそうに見える。
Allow と Require の両方が使われているときの アクセスポリシーを設定します。パラメータは All か Any です。このディレクティブはある場所へのアクセスがユーザ名/パスワード とクライアントのホストのアドレスで制限されているときにのみ 役立ちます。デフォルトの動作 (All) はクライアントがアドレスによる アクセス制限を満たし、かつ正しいユーザ名とパスワードを入力することを 要求します。Any では、クライアントはホストの制限を満たすか、 正しいユーザ名とパスワードの入力をするかをすればアクセスを許可されます。 これは、ある場所をパスワードで保護するけれど、特定のアドレスからの クライアントにはパスワードの入力を要求せずにアクセスを許可する、 というようなときに使用できます
ということは
AuthType ...
Require ...
Order deny,allow
Deny from all
Allow from IP_ADDR
Satisfy Any
にすると、
特定の IP アドレス以外からのアクセスは認証を要求される
という形になるわけだ。Satisfy のとる値は All か Any なんだけど、これはアクセスを許可するための条件が And になるか Or になるかの違いなんだなと思ったら急に分かりやすくなった。
実際には特定のユーザーにだけアクセスを許可する場合はそのユーザーが固定 IP を持ってて、それに該当しないユーザーは丸ごと 403 の方がスマートなんだけど、なかなかそうもいかんわね。少なくとも URL がバレていないのならこの形で我慢するのが現実的か。
週末必死に未読feedを消化しているうちに出会った本。
cf. 2008-09-03 - 思っているよりもずっとずっと人生は短い。
以前取り上げた本は、内容的にはいいんだけど、ちょっと硬派で人によっては拒絶反応が出てしまいかねないのと、学習の過程の設計がそれほど上手ではなく、学習曲線がいびつな感じがしていた。最終的にちゃんと全部目を通せば結構な量を網羅できるが、完全なわけでもないし、実際に手を動かす部分が弱かった。
つまり、これ渡して「はい、これで勉強して」と言えないわけではないんだけど、練習問題不足。こちらで「補助輪」として練習問題を用意した方がいいな、という印象。あと取っ掛かりとしてはちょっと情報量が多すぎる。取り上げておいてなんだけど、どっちかというと教材作りのための資料的な使い方やチョコチョコと断片的に知識を仕入れていた人がブラッシュアップするのに向いてそうな感じだった。
そこにこの これからはじめる HTML&スタイルシートの本 (自分で選べるパソコン到達点) を持ってくるとちょうどギャップが埋まりそうな気配。なんと言っても一冊丸ごと練習問題。
編集はスクリーンショット貼りまくりで個人的には目がチカチカしてきらいなタイプなんだけど、まぁこの方がキャッチーだし、自分がこれで勉強するわけではないので(笑。
何より、本の大きさ、情報の詰め込み具合、一通りのことを順に経験できる内容、といった辺りは非常にこなれていていい感じ。安心して渡せる。まず問題なく一人で最初から最後までやり遂げられて、かつ達成感を味わってもらえると信じられる。もちろん不足分は先日の本や自分で用意した資料などで補ってやる必要はあるけど、最後までやり遂げて成果が出そうっていう辺りが自習教材としてとてもよさげ。
やり始め用の資料を自分で整理とかしてたんだけど、とりあえず初期段階はこれに丸投げしてしまおう。
ただなぁ。時代は PyYAML だっつってんのに今ごろ Syck なのかよという気はするんだけど。この辺、PHP 界隈はどうにも弱い印象だなぁ。
もっとも速さに関しては、そもそもはっきり差が出るようなでかい YAML を毎回パースさせるっつーのがおかしいので、気になるなら serialize(), unserialize() を使ってキャッシュすりゃいいんじゃないかとは思っている。あんまり真面目に計測したことはないけど、parse_ini_file() でまかなえない構造のものを扱いたくて速度もそれなりに気になりますって場合はそれが今のところベストじゃないかしらん。設定ファイルなんてそんな毎回書き換えるもんじゃないんだから。
まぁ YAML ファイルそのものをストレージとして使いたいとか JSON みたいにレスポンスとして使いたいとかいうんだったら話は別なんだろうけど。
なんか今までサクっとコマンドで phpdoc を生成するってのはなぜかやったことがなかったので。
- CLI 版 PHP バイナリが入っている
- Pear で PhpDocumentor をインストールしている
状態を想定。以下のように叩く。
php PHPDOC-MODULE -d SOURCEDIR -t OUTPUTDIR
オプションは
- -f
- parse 対象ファイル名の指定
- -d
- parse 対象ディレクトリの指定（たぶん、普通使うのはこっち）
- -t
- HTML などの出力先
- -h
- ヘルプを出力
-t じゃなくて -o じゃないのかとか、-f と -d を分けるのってちょっとどうなんだとか、CLI 好きとしてはなんか少し他のいろいろあるコマンドと比べてオプションの体系に違和感がある。やっぱもともと Web インターフェイス + 設定ファイル（PHP直書き）という文化圏のツールなんだなぁって感じがしないでもない。
phpdoc のモジュールは OSX 標準の PHP に対して Pear でインストールしたときには /usr/lib/php/PhpDocumentor/phpDocumentor/phpdoc.inc にある。alias を設定しておけ。1と思ったら Debian で入れたら勝手に phpdoc コマンドができた。あれれ。まぁ便利だからいいけど。
しかしこれ未だに多言語対応は考えてないんだな、きっと。iso-8859-1 に決め打った HTML が生成されてしまう。まぁオープンソースものなら Pear の規約に照らし合わせても us-ascii 以外をコード内に入れない方がいいんだろうけど、手元で使う分には日本語書けないとさすがに不便なのよね。
みんなに使わせたいなら shell script の方がよい。 ↩
Lightweight Language Day 2005アンケート集計(1)
他の言語の人があまりよその言語の人と交流を持とうとしていないのか？ あるいは他の言語のコミュニティではあまり話題にならないのか。実際現場で使われている率で言うと Perl と PHP の方が断然高そうだもんな。（自分勝手に Ruby や Python を使っている人は多そうだけど。）
それとも、関東では実は Perl, PHP よりも Ruby がキテるのか？ まさかね。
意外と awk が健闘しているのがなんか嬉しかったり。（XML をいじろうとは思わないけど。）
Firefox は SSL 2.0 を切る方向らしいので、どういうことになるのか確認するために 1.0.6 で SSL 2.0 を off にしてみた。
Web メールで広告が出なくなった。素晴らしい :-)
一部必要から、一部趣味から。
- Mail(mailread.rb)
- 複数 UNIX From 形式に対応
- header を hash に収めてくれる
- body を配列に収めてくれる
- TMail
- mh 形式（not UNIX From）
- かなり細か操作ができる
- Tempfile
- テンポラリのファイルは自分で適当に作らずにこれ使えと
- curses
- テキストとカーソルだけのゲームとか作ったら面白いかも
- Ruby Cursesモジュール
セキュリティ情報リリーススケジュール (microsoft.com)
今日は日本時間では第2水曜ですが、アメリカ時間では第1火曜です。だから来週なの。
ヤフー、オールアバウトに資本参加 (ITmedia)
その前に、オールアバウトって社名変更してたのね。というか本家はオールアバウトじゃなくてアバウトなのね。なんだろう、この微妙な違いは。
早い話がリクルートと Yahoo! の協業の第2弾とも言えるのかな？（第1弾はたぶんリクナビNEXT）なんとなくだけど、これがリクルートなりの初期投資回収方法なんだろうという感じ。そりゃそうだよな、ISIZE も持っててオールアバウトもやって、、、ってポータル頑張りすぎやろって話だ。ISIZE もそのうち縮小していくんじゃないかな。ゼクシィとか独立ブランドで頑張れるところだけが生き残れると思う。あとはベネッセと客層がかぶる辺りをどうするか、かな？
アメリカの時間で9月7日ってことかな。6周年だそうで。そうか。あーそんなもんかー。日本語beta 見つけたのが 98年か 99年辺りだもんな。その頃はググるなんて言葉は当然なかったが、まさかこんなに浸透するとはちょっと思わなかったな。Google のレスポンスの良さ、キャッシュ、そしてブロードバンド化がすっかりコンピューティングを変えたって感じですか。
Gmail はまたコンピューティングを変えてくれるんだろか。個人的には news の方に期待してますが。
シンプルさが Google の売りだったのに、この見にくさはどうだ。ということで RSS をうまいこと利用すると。その際は空気嫁ってことになってますが。あ。テキスト版あるね。これでいいじゃん。
もう落ち着いた。やっぱリンクの効果って1日なんだ。それにしてもみんなマメにサイト巡回してんだな。
まだちらほら、まったくこれまで見たことのないところからリンクされている模様。しかし意味のあるコメントとともにリンク張ってる人ってほんとに少ないのな。みんななんでそれを見てたどってみようと思うんだろうか。不思議だ。
ライブドア、「AAA! CAFE」の無料レンタル掲示板などを1億円で譲り受け (INTERNET Watch)
事業の中心がライブドアに持って行かれたあとの AAA!CAFE っていったい。。。バナー免除と、有料の Web スペースと無料チャット、無料メールが残るってことかな？ バナー免除と有料のスペースの違いが分かりにくいな。
ふーん。てことはいずれこのスペースの URL も変わるのかな？ 短い名前になって、妙な制限がなくなるのは歓迎するけど、ライブドア傘下になってますます重くなるなんてことがありませんよーに。
自分は別に根っからの吉野家ファンというわけではないし、できることならこういうところにお世話にならない生活がしたい。キャラクターものもそんなに好きじゃない。でもなんか今回はほしかったのだ。
しかしキャンペーン期間中の4回っつーがもう限界で、すぐさま引き換えのためにまた吉野家に食いに行くということはできませんでした。そして引き換え期間ギリギリの昨日、食べに行ったらもうストラップはないとさ。
おれはさー。別に冷凍の牛丼はほしくないのよ。むしろストラップくれと。つけないよ。携帯につける気はさらさらないけどね。でもほしかったの、ストラップ。
ちくしょー。
position: absolute の指定について、包含ブロックが明示的に大きさを定義しているか否かで動作が異なる。例えば明示的に幅を定義していない場合、包含ブロックはなぜか初期包含ブロックと同じ幅を持つことになる。
ばかですか？
英語フォントがなぜか日本語の記号類の一部に影響を与えてしまうのはどうも Gecko のバグっぽい。OOo でも似たような現象が起きるが、IE では起きない。Unicode フォントの扱いのまずさのような気がしているが、詳細は不明。ブラウザ側で回避方法があるなら知りたいところだが…。
えーい、くそ。
ふーん。
info-arch ML に現れた新居雅行さんの退社した会社が出してる。なかなか地味ながら面白い仕事をしている。