rack-timeoutはasyncな挙動を許さないので情報を引き出すのが難しい
NewRelic など agent 方式のものでは可能だったはず1なので、agent をサクッと作れる人は作ればいいんだけど、そうじゃない場合どうなっているのか、という話。
例えば Rails と rack-timeout を組み合わせる場合、他のエラーと同じように
rescue_from で timeout エラーを拾って処理を行いたい
と思うかもしれない。結論から言うとエラーを拾って処理を kick することは可能だが、
rack-timeout 自身が Thread 丸ごと全部 kill しようとするので async な logger などは期待通りに動作しない
という挙動になる。
The Oldest Bug in Ruby: Why Rack::Timeout Might Hose Your Server - DZone Performance
参考記事は 2017年のものだが、Ruby 2.6.x + Rails 6.0.x でも同じ動作だったので、"バグ"は直っていないっぽい。まぁ timeout で全処理をキャンセルするのが目的なので仕方ないっちゃ仕方ないんだけど。
rack-timeout自身がobserversを提供してくれている
どうにも情報が引き出せなかったのであれこれ rack-timeout のドキュメントを読んでいたら observers というものがあることを知った。
rack-timeout/observers.md at master · sharpstone/rack-timeout
- Rack::Timeout.register_state_change_observer に名前と Proc オブジェクトを与える
- Proc オブジェクトには rack env が渡ってくる
- Proc オブジェクトは state change のたびに呼ばれる
- state change は lifecycle のページに書かれている以下の5パターン。rack-timeout をそのまま使っていると log にこれらの情報が出力されているはず。
- expired ( error )
- ready ( info )
- active ( debug )
- timed_out ( error )
- completed ( info )
これらのうち実際に何かしたいとなった時に利用するのは timed_out のタイミングだろう。timeout の情報は rack env の 'rack-timeout.info' という key に Struct として収められているので、observer 全体では以下のような形になる。
Rack::Timeout.register_state_change_observer(:a_unique_name) do |env|
if env['rack-timeout.info'].status == :timed_out
..
end
end
とは言えあくまで取得できる情報は簡素なもので、設定してあった時間と実際に計測した時間くらいのものである。どの URI にアクセスした結果 timeout が起きたかといったことすら分からない。
その辺は
- Rails の作る rack env オブジェクトの中身に精通していないといけない
- 例外そのものを拾うことはできないので backtrace はない
ので注意が必要である。
最近使っていないのでどうだったか覚えていない ↩
いや、実際にはちゃんとプロダクションコードを書いていないので、他にも気をつけるべきポイントはあると思うのですが、とりあえずついったーで「 Google Functions はなぜ未だに Node 6 なのか」みたいなを見かけて、
そういや、Node 8 LTS を基準に環境作ってて Node 6 要求されたら面倒くさいな
と気になったので調べてみました。
調べたのは二つで、
- babel-preset-node6
- eslint-plugin-node
です。
最初「node 8 で書きつつデプロイ時に node 6 で動くコードに変換できればいんじゃね？」と思って、それっぽい名前の babel-preset-node6 を試してみましたが、そんなことは無理でした。こいつの役割は V8 native で動くコードはそのままに、node6 で ES2015 compat じゃない部分を補うためのもので、目的は、transpile の高速化ですね。
で、変換でどうにかするのは早々に諦めて、じゃー lint だなと。
mysticatea/eslint-plugin-node: Additional ESLint's rules for Node.js
できました。
package.json で示すと以下のような感じで指定すれば ok.
{
"engines": {
"node": ">= 6" // <- ここで対象バージョンを指定
},
"devDependencies": {
"eslint": "*",
"eslint-plugin-node": "*"
}
"eslintConfig": {
"plugins": ["node"],
"extends": ["plugin:node/recommended"]
}
}
これで例えば以下のように怒られます。
error Async functions are not supported yet on Node >=6.0.0 \
node/no-unsupported-features
うんうん。
package.json の engines 指定の意味が増えるのはちょっとどうなのかなという気はするのですが1、まぁとりあえず方法は分かったのでよしとします。
例えば徐々にバージョンを上げていこうとなった場合などに ↩
- ホスト名はみんなが引ける名前をつける
- 自分だけなら ssh_config で付けられる alias でも接続できるけど、それは共有できない
- deploy を実行する機械の時計は正確に合わせておく
- releases/ 以下のディレクトリは capistrano を叩いた機械の時計をもとにディレクトリを作成するので、未来すぎたり過去すぎたりするとうまく deploy できなかったり次の deploy に支障が出たりする
時間の方は最近こういうのでガードするようにした。これはたまたま LAN 内の NTP サーバに HTTPD も起きていたので、そこから時間を取得して cap 叩いた機械の時計と比較している。
| require "open-uri" | |
| NTP_SERVER = xxxx | |
| ntp_time = Time.parse(URI("http://#{NTP_SERVER}").read.meta['date']) | |
| local_time = Time.now | |
| if ( (local_time.to_i - ntp_time.to_i).abs > 5 ) | |
| abort "Your machine is wrong !\nIs it #{local_time} now ?\n" | |
| end |
まぁ cap 叩く機械を統一して Webistrano でやりますっていうんならこういうのは要らない。人数が増えて上のようなミスを減らそうと思ったら Webistrano 入れるといいのかも。認証通さないといけないし、deploy のログも残る。
GUI が必要ないなら ssh の proxy とかで同じようなことができるんじゃないかなぁと思ってるんだけど、できるかどうかよく分からないし、そこまで考えるなら Webistrano の方が楽かな。ブラウザでポチポチするのがちょっとダルいけど。
故あって本屋でWeb制作の入門向けの本を探していて、実際に手に取って確認した中でまともなものをちょっと紹介してみますよ。
全般
ウェブの仕事力が上がる標準ガイドブック2 Webデザイン は数少ない網羅的な本。画像形式とその特徴の違いなど、本来触れていて当然の内容がちゃんと入っている。HTML だけとか HTML + CSS だけとかを扱う本は多い1が、それだけでは当然 Web の作り手としての知識には十分でない。なのにこういう本が少ないのはとても不思議。ズブの素人の人はいったいそういう大事な知識をどこから得ているの？ 学校で教えてくれるの？ そんなわけないよね？
じゃあ逆になんでこの本はこんなにしっかりしているんだろうと思ったらそれもそのはず、これは「Web検」の教科書的な位置付けの本なのだ。「Web検」てそう言えば聞いたことあるなーと思ってはいたけど、今サイトを見ると一応試験は始まっているみたい。システム寄りの方はまださっぱり内容もないけど。
社団法人 全日本能率連盟登録資格「Web検定（ウェブケン）」 - Webに関わるすべての人の標準知識
正直Web検には別に何も期待していなかったんだけど、まともに使える本が出るだけでもかなり大きな意味があるような気になった。自分が徐々に、断続的に手に入れてきた知識をまとめて相手に伝えることは難しい。そのまとめの作業をそれなりに肩代わりしてくれる本の存在はとてもありがたい。
制作／デザイン寄り
HTML を組むには以下のような感じですか。
世の中の HTML の解説には、かなりひどい間違いを含むものが大量に出回っていることは皆さんご承知の通り。その一つ一つについてちゃんと検証したわけではないので、ぶっちゃけこの本がそんなに「正しい」かどうかは分からない。基本的には「姿勢」で選んだ。
- 下手に漫画調にしてごまかしていないこと
- それでいて図が豊富で分かりやすい
- スクリーンショットだらけでブラウザの挙動ばかりを気にするのではなく、構造などの基本を大事にしている
てな辺り。
最近 Web の入門系の本なんか見る機会がないから知らなかったけど、探すと結構「Web標準」という言葉を目にする。「あー認知度上がったんだなー。」と感慨ひとしお。そういう中で探すと割とまともな本にたどりつきやすかった。ただやっぱ見やすさ、扱いやすさという、内容以外の要素も重要で、実際上に挙げた本は割と見た目を重視している。要は一人でこの本でめげずに独学していける2と直感できる本を選んだつもり。
cf.
祭りも収まってきたことだし、その間に読んだり書いたりしたことをもう一度思い返してみる。
自分が書いたものは主に Dan の中の人の発想に同調して「ハッカーが使いたくなる言語か否か」、「『使える』かどうか」だったんだけど、その方向で気になったポイントとしては、
PHP を PHP で拡張できないことに異論を唱える人はほとんどいない
という点。「そこは割り切って使うのが PHP 使い」というのが大勢だったかなと思う。
あとは
- 関数ばっかいっぱいあって邪魔くさい
- そんなのリファレンス見ればいいじゃん
- 名前空間がなくて扱いにくい、一個一個の名前が長くてダサイ
というフラットで巨大な関数群の話。
個人的にはリファレンスとか IDE の補完があればオッケーという話ではないと思うな、これは。予約語もけっこう多いし、そういう意味でも扱いにくいと思う。
たぶん PHP モジュールを作る人が増えてこないのはこの辺も関係してるんじゃないかなぁ。例えば面白いツールがあっても PHP のバインディングだけない、っていうケースは少なくない。PHP 以外を知らない人はこの事実、気づいてないのかな。
それと
- Web に特化しちゃってて他のバックエンドツールとか書きにくいじゃん
- Web に特化しているからこそ目的を素早く達成できるんじゃないか
- Web に特化していることを肯定したうえで、であればもっと素人でもセキュリティを確保しやすい仕組み、あるいはサンプルを提供してくれたらもっといいのに
という特化話。特化していることの善し悪しは要するに目的によって変わってくるのでそこら辺は置いとくとして、自分が気になったのは
本当に特化して楽ちん簡単なのか？
という辺りかしら。
以降はとてもなんとなくな思いつきをダラダラ書くだけなのであまり気にしないでほしいんだけど、ここ数年の PHP 開発の流れって、基本的に大型開発に耐えられるツールを指向していると思うのね。
PHP が Perl で書かれたツールだった頃の話は知らないんだけど、その後の PHP は Perl っぽさというよりは素朴でポインタのない C のような雰囲気を身にまとって C 系のプログラマが移行しやすくなり、その後オブジェクト指向風の機能を追加し、5 ではますます Java 風の機構を取り入れてくる、というのが大まかな流れなわけです。そして今いちばんアツイのは PHP そのものではなく PHP 上に乗っかるライブラリと PHP を利用した Web 開発を支援する環境である、と。つーことは他の言語の流れと基本的にはおんなじところに向かっているように見えるんだな。乱暴に言うとオブジェクト指向を取り入れてライブラリを整理しましょう、という流れ。
もちろん主戦場が Web であるというところは疑う余地はないと思うんだけど、PHP そのものの開発をするうえで Web に特化するということを第一としているのかというと、そうでもないような。というかその辺の機能はすでに実装済みというか1。で、最近特に問題になることが多いセキュリティ周りは、言語そのもので対応するよりライブラリ、フレームワークで対応する方が効率がいいと判断しているような感じがする。（もちろんクラッシュする類いのものは PHP では対処不能なのでそこは直すけど。）
一方でバージョン 3 の頃のような牧歌的なノリで PHP は導入も簡単で学習コストも低く、初心者にオススメです、という人たちも居て、そういう人たちは残念ながら Web プログラミング特有の難しさにはあまり頓着がなかったりしているように見える。
PHP にいっちょかみする人って、PHP 好き派ときらい派に分かれるのは当然として、PHP は初心者にも簡単でいいよ派と、PHP を大型案件もこなせるツールにしたい派にも分断しちゃってるような、そんな風に見えるんだなぁ。
自分としては「（生の）PHP は Web に特化しているし、簡単でいいんです」、というのは安全なネットワークの中で閉じたツールを作る分には当てはまるけれど、インターネットという危険な大海原では当てはまらないと思うんだな。それでも PHP を薦めるのは
初心者に対してではなくプロの共通語として
なら理解できるかなーと思う。これは PHP くらい使えなきゃダメよと言っているんではなくて、恐らくプロは PHP で書かれたサンプルを読める程度になら半日もあれば到達できるだろう、という感じの意味ね。巨大なライブラリを読みこなせるとか自由に書けるとかいうことではないです。例えば XSS や CSRF 対策の基本はこんな感じです、みたいなサンプルを提示する際に PHP はそれなりに使いやすいんじゃないかな、くらいの意味。もう一つは求人の多さかな。求人の話はニワトリタマゴだけど。
例えば cli でも cgi でも mod_php でも fastcgi でも、他のフレームワークなどの助けを借りずに基本的に同じコードが動くのは結構すごいと思う。 ↩
うーん。一部機能が利用できませんとか言うならいいんだけど、コンパイルエラーじゃ対処のしようがない。
ちょっとの修正で動くという話もあるんだけど、具体的な方法が分からないorz
MochiKit も試してみたけどやっぱダメ。コンパイルエラーっつーのは困るなぁ。はてなとかどうやって対処してんだろ。とりあえずこれも急ぎじゃないので置いとく。
試しに iCab 3 beta を動かしてみたら Classic 版でも OSX 版でもコンパイルエラーは起きない。XMLHttpRequest には対応してないっぽいけど、DOM の操作とかは普通にできた。ただし CSS の解釈にあやしいところがまだある感じ。上のカレンダーのポップアップのポジショニングは明らかにおかしい。しかし Classic版より OSX版の方がバシバシ落ちるっつーのはどうかなぁ…。
Classic をあえて選ぶ人はもうみんな IE 捨ててiCab に乗り換えてくれって言った方がいいのか？ まぁ恐らく通用しないんだろうけど、でもあれだ。正直、なんか懐かしくてかわいいらしい感じはするね。
ドクター取得後の就職にはどんな支援が必要？ (/.-j)
結局、どの組織、どの分野でもダメな人がいて、出来る人がいて、ダメな上司、ダメな部下に悩む人が居て、隣の芝生が青くしか見えない人も居る一方で、どうしても自分より下の人間を見つけてこき下ろしたい人が居ると。
まぁいつものスラドのパターンだなと思った次第。ポスト不足なんてどこにでもある話さ。1
勝手な妄想を並べておくと、年齢、学歴、実績を「順番に積み上げて行く」っていう以外のルートがもっと認知されるべきじゃないかなと思う。キャリアを活かして新天地ってことじゃなくて、いつでも学び直せるしやり直せる世界。まぁ寝言と思われるかもしれないけど、そんなにとんでもない話じゃあないと思うんだよな。
学問の世界は企業に就職したら遠のくのか？ 逆に学問を究めようとしている人間は企業社会で通用しないのか？ どちらも極端な話だと思う。（それっぽい傾向があることまで否定はしないけどさ。）キャリアパスって言葉があるけど、学問の世界にも企業社会にも、つーかもっと広い意味においても、パスは本来何本も描けるはず。それを狭めているのはスキルや制度だけじゃなくて、自分と周囲の世間体や常識でもある。2
と、具体的な支援策を書かずに逃げるのであった。だってさぁ、今日やって明日効果が出るような対症療法で解決するとは思えないし。だったら価値観とか、そんなすぐにはどうにもならない話を持ち出してもいいかなーなんて。
自分の中では「説得スキル再び」な話。
えーと。naoya さんはどこでソフトウェア工学を否定したんでしょうか？ 否定したのはウォーターフォールモデルではないのですか？ naoya さん自身の言葉でソフトウェア工学について書いているのはこれだけでしょ。
もうひとつ僕が引け目を感じていた原因として、ソフトウェア工学というものを学んだことがないというのもありました。僕は大学で物理を専攻していたこともあって、いわゆるソフトウェア開発の方法論やアルゴリズムといったものをまともに勉強したことがありません。
ソフトウェア工学を学んだことがないことを引け目に感じているだけ。否定的なことを書いているのはここか。
しかし、独創的なソフトウェアを"創りながら創る"という方法においては静的型付けの言語よりも動的型付けの言語の方が有利だと思うし、スーツを着て設計書を書いてからものを作るなんて作業は、今の僕には耐え難い作業です。もう後戻りはできなそうです。
言語の話が一つ、開発体制の話が一つ。ソフトウェア工学そのものはやっぱり出てこない。
ソフトウェア工学そのものは分からなくてもボトムアップ（あえてことの言葉を使いましょう）で XP にたどり着いた、ということですな。
これに対して orionae さんがいやいやソフトウェア工学は大事なんだよと言うのは別に問題ないと思うし、まぁ実際 naoya さんはソフトウェア工学そのものを大事にしているわけじゃーないでしょうな。ないがしろにしているのではないかという指摘は正しいと思います。でも反論のための例の出し方がまるで「XP では欠陥住宅ができますよ」みたいに読めちゃうんだな。この辺とか。
もしある人が「自分は薬品を混ぜていろんな物質を作るのを愛してるんです。
いろんなアイデアがわいてきて、そうやって作ったこの薬はこの症状にはすごく効くんですよ。」って言って提供する薬を、それを作った人が一切薬学や分子工学の知識が無いとわかっていて、あなたは人に薦められますか？？
また、ある人が「自分は日曜大工が好きで、どんな家でも作れるんだ。いろいろアイデアが浮かんでさ。こんど10階建てのホテルを自分で作ったんだけど、泊まりに来る？建築工学？構造力学？そんなの好きじゃないからぜんぜん知らないや。」
あなたはそのホテルを責任を持って沢山の人に紹介できますか？
極端なようですが、上記ブログでnaoyaさんが述べられているのは、まさに同じことです。
そして
なぜ設計が必要か。なぜドキュメントが必要か。なぜ静的型付けが必要か。
あれ。ソフトウェア工学の必要性の話が設計、ドキュメント、静的型付け言語の必要性の話にすり替わろうとしている。
ところで。
ソフトウェア工学を押さえておかないとなぜ XP の手法が有効なのかは説明できない。そりゃそうだ。でも現場で生き残るのは理論じゃなくて手法だっていうのも自明じゃないですかね。1理論ではソフトウェアは生まれないのだから、ソフトウェア工学の必要性を解くためには論破ではなく、アジャイルの手法を選択した経緯をソフトウェア工学の豊富な知識を以て補完して説明してあげる方が有効なんじゃなかろうか。つまり、あなたが否定したつもりのソフトウェア工学で以てあなたの選択を説明することができる、という釈迦の掌論法だ。（くどいようだけど、naoya さんは明確にソフトウェア工学の否定はしてないはず。）
もう一つの方法は、あなた方の知見をみんなで共有するためにソフトウェア工学が役に立つ、というアプローチかな。つまり、「はてなメソッドの確立」のために工学的手法が使えますよ、という話。これはソフトウェア工学の人（って誰）にも Web アプリを開発している他の人たちにも嬉しい話になると思う。はてな内部の人がどれだけ嬉しいかはちょっと分からないけど。
ところで今回あちこち見て気に入ったのはこれ。
まぁ要するにソフトウェア工学について、古くて、今ではそんなに重視されていない話の方が有名になっちゃってるんじゃないかなーと勝手に解釈したんだけど、考えてみたらいわゆる「学」のつくものって多かれ少なかれこの手の問題を抱えているんだよな。みんな学校で習った段階でその分野の情報が固定されて、自分の中で常識化してしまうから。
えーと。
オチがねーな。まいっか。
だからこそ <a href="http://japanese.joelonsoftware.com/Articles/TheJoelTest.html">ジョエルテスト</a> なんかも大事になってくるんだと思う。 ↩
メタモデしか回ってこないし、知らない分野の話が多いので。
最近は比較的プラスモデが増えているような気がするけど、どうだろう。 そろそろ閾値を元に戻そうかな。
キーワードは
- 消費電力
- 処理速度
- ノイズ（画質）
- 製造コスト
ですか。画質さえ向上すれば CMOS の方がメリットは大きそうですな。超広域ダイナミックレンジ CMOS とかすでにあるしね。EOS-1 のデジタル版は EOS-1D markII（CCD版）と EOS-1Ds（CMOS版）がある。ということはプロユースでも CMOS が十分に使いものになるという自信があるんだろう。
これらの発売はこの春なので、今後は徐々に高画質版コンパクト CMOS デジカメっつーのが出てくると見てよいかもしんない。
参考
いろいろあります Opera ですが、どうやら Mac 版は結局出たようです。OS X で beta を試したときにはそのあまりの重さにめまいがしたものですが、そういえば Classic では試してみませんでした。8.6 から対応ということで、Mozilla, Netscape 7 の重量ブラウザか iCab, Netscape 4 などの先端技術についてこれないブラウザしかない Classic 環境では救世主になって、、、くれないかな？