救急三連戦@横浜
巨人-横浜が横浜スタジアムで３連戦してるのと同じタイミングで
横浜のR病院というところで救急の実習をしてます。
飯くうタイミングもないですが、充実してて素晴らしーです。
さて、せっかく横浜に行ったからには、
今年からファンになった横浜ベイスターズの応援に行こうぜ俺よ。と。
ダントツ最下位だけど横浜は同世代の選手が頑張ってるから応援しがいがある。
一押しは1986年生まれの細山田選手！
早稲田のキャッチャーだったらしい。
こんなことなら早慶戦見とけばよかったぜ。
実習しながらワクワクしてたんですが、
良く考えたら３日連続東京で６時から予定があった。
見て負けたら悔しいけど、
見ずに勝って悔しいことはない。
というわけなので３日とも見ない選択肢で行くぜ。
横浜のR病院というところで救急の実習をしてます。
飯くうタイミングもないですが、充実してて素晴らしーです。
さて、せっかく横浜に行ったからには、
今年からファンになった横浜ベイスターズの応援に行こうぜ俺よ。と。
ダントツ最下位だけど横浜は同世代の選手が頑張ってるから応援しがいがある。
一押しは1986年生まれの細山田選手！
早稲田のキャッチャーだったらしい。
こんなことなら早慶戦見とけばよかったぜ。
実習しながらワクワクしてたんですが、
良く考えたら３日連続東京で６時から予定があった。
見て負けたら悔しいけど、
見ずに勝って悔しいことはない。
というわけなので３日とも見ない選択肢で行くぜ。
進捗はIframeで実現すべき
「処理の進捗状況」がWeb上にバーで現れることがあるよね。
その実装方法を自分なりに考えていろいろ作ってみた。
1.Ajax＋Ajax
2.Iframe＋Ajax
3.Iframe＋flush()＋javascript
1について。
１は、簡単に言うと、処理しているAjaxの状況を、別なAjaxが報告するパターンである。
まず、長い処理をさせるプログラム自体をAjaxで開始させる。
そのことによって、ブラウザが「待ち」状態を抜け出せるわけだ。
この長い処理を開始させるAjaxを今から「処理Ajax」と言おう。
そしてその進捗を、別なAjaxが問い合わせればよいのだ。
進捗は、長い処理の側が定期的に吐き出したログを参照すれば把握できる。
このログを取得するAjaxを「問い合わせAjax」と言おう。
この実装方法では、なぜか「問い合わせAjax」は「処理Ajax」の処理が終わるのを
永遠に待ち続けてしまう。
同じAjaxは同時に処理されないのかい？
それともログ取得のロックとかの問題なのかい？
ともかく、１はうまくいかなかった。
２について。
２は、１の「処理Ajax」を「処理Iframe」に変えたものである。
処理するプログラムはIframeにすれば、
Ajaxは一本だから問い合わせできるんじゃね？ってことで。
だがこの実装でも、「問い合わせAjax」は「処理Iframe」の処理が終わるのを
永遠に待ち続けていた。
ログファイルの共有の問題かとも思えるが、
例えばmemcachedなどのリソースに置き換えてログを管理しても上手くいかなかった。。
なんか、あるんだろうね。
ともかく２もうまくいかなかった。
３について。
３は、問い合わせAjaxを廃止し、処理Iframe側がflush()というPHPの関数を用い、
ログをブラウザに吐き出す方法である。
「すげーじゃん。リクエストがないのに何度もレスポンスを送ってくれるなんて
最初っからこいつにしろよ」と思う人もいるだろう。
だがIframeは、
・CSSが共有できない
・javascriptが共有できない
という点でAjaxよりも数段使いにくいのだ。
よって、「Iframe内はどうみても別ページやん」という感じに見えて寂しいという欠点があるのだ。
だが、javascriptをうまく使うことでこの欠点を克服することができた。
まぁ誰もが考えることだが
「JSON式コールバックで親画面にデータを反映させる」
ことである。
そしてIframe内はdisplay:none;にする。
ログデータを親側に送信し、進捗の表示は親側に任せるのである。
毎回<script type="text/javascript">window.parent.callback({numerator:3,denominator:100,percent:3})</script>
のようなデータをIframe側のPHPがflushするのである。
そうすることでCSSやjsが共有できない問題が解決するのである！
（まあwindow.parentが使えるという意味ではjsは共有できていると考えてもよいのだが）
まぁ要するに、「また車輪の再発明したよ。」っていう話でした。
その実装方法を自分なりに考えていろいろ作ってみた。
1.Ajax＋Ajax
2.Iframe＋Ajax
3.Iframe＋flush()＋javascript
1について。
１は、簡単に言うと、処理しているAjaxの状況を、別なAjaxが報告するパターンである。
まず、長い処理をさせるプログラム自体をAjaxで開始させる。
そのことによって、ブラウザが「待ち」状態を抜け出せるわけだ。
この長い処理を開始させるAjaxを今から「処理Ajax」と言おう。
そしてその進捗を、別なAjaxが問い合わせればよいのだ。
進捗は、長い処理の側が定期的に吐き出したログを参照すれば把握できる。
このログを取得するAjaxを「問い合わせAjax」と言おう。
この実装方法では、なぜか「問い合わせAjax」は「処理Ajax」の処理が終わるのを
永遠に待ち続けてしまう。
同じAjaxは同時に処理されないのかい？
それともログ取得のロックとかの問題なのかい？
ともかく、１はうまくいかなかった。
２について。
２は、１の「処理Ajax」を「処理Iframe」に変えたものである。
処理するプログラムはIframeにすれば、
Ajaxは一本だから問い合わせできるんじゃね？ってことで。
だがこの実装でも、「問い合わせAjax」は「処理Iframe」の処理が終わるのを
永遠に待ち続けていた。
ログファイルの共有の問題かとも思えるが、
例えばmemcachedなどのリソースに置き換えてログを管理しても上手くいかなかった。。
なんか、あるんだろうね。
ともかく２もうまくいかなかった。
３について。
３は、問い合わせAjaxを廃止し、処理Iframe側がflush()というPHPの関数を用い、
ログをブラウザに吐き出す方法である。
「すげーじゃん。リクエストがないのに何度もレスポンスを送ってくれるなんて
最初っからこいつにしろよ」と思う人もいるだろう。
だがIframeは、
・CSSが共有できない
・javascriptが共有できない
という点でAjaxよりも数段使いにくいのだ。
よって、「Iframe内はどうみても別ページやん」という感じに見えて寂しいという欠点があるのだ。
だが、javascriptをうまく使うことでこの欠点を克服することができた。
まぁ誰もが考えることだが
「JSON式コールバックで親画面にデータを反映させる」
ことである。
そしてIframe内はdisplay:none;にする。
ログデータを親側に送信し、進捗の表示は親側に任せるのである。
毎回<script type="text/javascript">window.parent.callback({numerator:3,denominator:100,percent:3})</script>
のようなデータをIframe側のPHPがflushするのである。
そうすることでCSSやjsが共有できない問題が解決するのである！
（まあwindow.parentが使えるという意味ではjsは共有できていると考えてもよいのだが）
まぁ要するに、「また車輪の再発明したよ。」っていう話でした。
吉野家で住所を書かされた奴の話
吉野家で自分の住所を書いたSというバカがいるんで、
そいつの話をしようかと思う。
0:00 友人Mから電話があり、「今から泊まりに行くわ」
0:30 M到着。
0:31 M「Iが別れたらしい。そいつんちで飲むぞ」
0:32 移動
0:50 I宅到着
1:50 Iの別れた話もほどほどに、酔っぱらう。
2:30 Iはペットボトルに放尿なさる。
3:30 Sは完全に酔い潰れて寝る。
6:00 IとMは合宿で江ノ島へ向かう。Sは放出される。
6:05 S「あぁ具合わりー。でもなんかくいてー。よしぎゅー行くか。」
6:10 吉野家で牛丼並盛食べる。
6:17 S「会計をお願いします」
6:18 Sはポケットに手を突っ込み、フリーズする。ない。財布がない。
6:19 店員「・・・ではこちらに住所氏名電話番号を・・・」
6:22 住所氏名電話番号を記載して謝りまくって店を出る。
6:23 S「財布・・・財布・・・あれ？まさか？」
6:30 Iの家に財布を忘れたことに気づく。Iは既に合宿へ向かっている。
6:31 Iの家にケータイと自宅の鍵を忘れたことに気づく。Iは既に合宿へ向かっている。
6:32 このままでは何もできないことに気づく。
6:33 S：上パーカー 下ジャージ 靴下なし、ケータイなし 財布なし 鍵なし。
6:34 9時から大学で予定があったため徒歩で大学へ向かう。
7:00 とりあえず大学で寝る。
9:00 ようやく知り合いに出会うことが出来、Iに連絡を取る。
9:01 I「取りに来てもらうしか・・・」
ということで、わざわざ江ノ島に行って帰ってきましたよ。
一緒に行ってくれたTには感謝してもしきれません。
22:00 S、380円を払いに吉野家へ。
22:01 店員「またご利用くださいませ（苦笑）」
そいつの話をしようかと思う。
0:00 友人Mから電話があり、「今から泊まりに行くわ」
0:30 M到着。
0:31 M「Iが別れたらしい。そいつんちで飲むぞ」
0:32 移動
0:50 I宅到着
1:50 Iの別れた話もほどほどに、酔っぱらう。
2:30 Iはペットボトルに放尿なさる。
3:30 Sは完全に酔い潰れて寝る。
6:00 IとMは合宿で江ノ島へ向かう。Sは放出される。
6:05 S「あぁ具合わりー。でもなんかくいてー。よしぎゅー行くか。」
6:10 吉野家で牛丼並盛食べる。
6:17 S「会計をお願いします」
6:18 Sはポケットに手を突っ込み、フリーズする。ない。財布がない。
6:19 店員「・・・ではこちらに住所氏名電話番号を・・・」
6:22 住所氏名電話番号を記載して謝りまくって店を出る。
6:23 S「財布・・・財布・・・あれ？まさか？」
6:30 Iの家に財布を忘れたことに気づく。Iは既に合宿へ向かっている。
6:31 Iの家にケータイと自宅の鍵を忘れたことに気づく。Iは既に合宿へ向かっている。
6:32 このままでは何もできないことに気づく。
6:33 S：上パーカー 下ジャージ 靴下なし、ケータイなし 財布なし 鍵なし。
6:34 9時から大学で予定があったため徒歩で大学へ向かう。
7:00 とりあえず大学で寝る。
9:00 ようやく知り合いに出会うことが出来、Iに連絡を取る。
9:01 I「取りに来てもらうしか・・・」
ということで、わざわざ江ノ島に行って帰ってきましたよ。
一緒に行ってくれたTには感謝してもしきれません。
22:00 S、380円を払いに吉野家へ。
22:01 店員「またご利用くださいませ（苦笑）」
なぜかしかっりはどんくできる
こんちには みさなん おんげき ですか？ わしたは げんき です。
この ぶんょしう は いりぎす の ケブンッリジ だがいく の けゅきんう の けっか
にんんげ は もじ を にしんき する とき その さしいょ と さいご の もさじえ あいてっれば
じばんゅん は めくちちゃゃ でも ちんゃと よめる という けゅきんう に もづいとて
わざと もじの じんばゅん を いかれえて あまりす。
どでうす？ ちんゃと よゃちめう でしょ？
ちんゃと よためら はのんう よしろく
どうよ？ネットからひっっぱてきたんだけど。
この ぶんょしう は いりぎす の ケブンッリジ だがいく の けゅきんう の けっか
にんんげ は もじ を にしんき する とき その さしいょ と さいご の もさじえ あいてっれば
じばんゅん は めくちちゃゃ でも ちんゃと よめる という けゅきんう に もづいとて
わざと もじの じんばゅん を いかれえて あまりす。
どでうす？ ちんゃと よゃちめう でしょ？
ちんゃと よためら はのんう よしろく
どうよ？ネットからひっっぱてきたんだけど。
みんなの未来を覗き見
今日は学校で卒業アルバム用の写真を撮ったんだが・・・
「志望する科ごとに写真を撮る」というイベントがあり、
誰がどの科に興味持ってるかがわかって楽しかった。
この楽しみはスポーツとかの個人成績を眺める楽しみに近い。
まぁ２年半後に決めるときは、全然違うことになってるんだろうが。
自分もまだまだ人生決めかねてるよ。
医学部は世間より４年遅れて人生を選べるのが得、なのかな？？
それとも世間より４年早く選んでいるというべきか。
「志望する科ごとに写真を撮る」というイベントがあり、
誰がどの科に興味持ってるかがわかって楽しかった。
この楽しみはスポーツとかの個人成績を眺める楽しみに近い。
まぁ２年半後に決めるときは、全然違うことになってるんだろうが。
自分もまだまだ人生決めかねてるよ。
医学部は世間より４年遅れて人生を選べるのが得、なのかな？？
それとも世間より４年早く選んでいるというべきか。
iidaがカッコいい
iidaていうケータイがあるらしくて、
そのサイトを見に行ったら・・・
Flashがすごくcool!
iida 公式サイト
みんなも行ってみてね。
別に回し者ではないよ。そもそも自分auじゃないし。
ちなみに名前の由来は
「KDDI本社が飯田橋にあるから」
とかいう説があるらしい・・・でもネットで調べたら社長は否定してるらしい・・・。
ネーミングセンスって、わからんもんだね。
ほかにカッコいい地名といえばなんだろうねぇ。
cozyで麹町
elmで襟裳岬
arkで荒木町
RPGで六本木
gakugeidaigakuで学芸大学
yoyoで代々木
jojoで叙々苑
jomoでレギュラーを入れるとこんなにお得！
あなたにぴったりのカードは Plus派？ Light派？ メリット診断 ↓ JOMOカードプラス ポイント還元率が業界1位のお得なカード · JOMOカードライト 年会費永年無料のお得なカード. JOMOカード会員メニュー
そのサイトを見に行ったら・・・
Flashがすごくcool!
iida 公式サイト
みんなも行ってみてね。
別に回し者ではないよ。そもそも自分auじゃないし。
ちなみに名前の由来は
「KDDI本社が飯田橋にあるから」
とかいう説があるらしい・・・でもネットで調べたら社長は否定してるらしい・・・。
ネーミングセンスって、わからんもんだね。
ほかにカッコいい地名といえばなんだろうねぇ。
cozyで麹町
elmで襟裳岬
arkで荒木町
RPGで六本木
gakugeidaigakuで学芸大学
yoyoで代々木
jojoで叙々苑
jomoでレギュラーを入れるとこんなにお得！
あなたにぴったりのカードは Plus派？ Light派？ メリット診断 ↓ JOMOカードプラス ポイント還元率が業界1位のお得なカード · JOMOカードライト 年会費永年無料のお得なカード. JOMOカード会員メニュー
同じ状況ならプログラムの実行結果は同じ？
プログラムの実行結果は、同じ状況なら常に同じになる。
これは正しい。というのは、プログラム自体は論理だから。
しかし・・・。
残念ながらプログラムの実行は
ハードウェア（物理）で行うという制約がある以上
同じ状況とは二度とありえないのでした。
え？じゃあいつもレポートで使ってるMicrosoft Wordも環境によっては
おかしな挙動をしだすのかい？
って話になるよね。
まぁ、流れ的にそうと言わざるを得ないよね。
詳しく言うと・・・
数学の定理は日本でもアラスカでも、１９０９年でも２１０９年でも常に成り立つ（し、そう保証できる）。
一方物理学の法則が将来にわたって、どの場所にあっても常に成り立つという保証はない。
これは数学が純粋な論理からなるのに対し、
物理学というのは物理＝「現実のあらゆるパラメータから起きている現象」からなるからである。
時間、空間的パラメータの影響が小さい場合に、
将来にわたって成り立つだろう、といえるのである。
さらに物理学の場合「状況は、不定である（確率である）」ということがあるので
「同じ状況である」ということもできなくなり、プログラムよりも不確かなものになるわけだが、この話は置いておこう。
さて、何でこのような話をするかというと、
ここ３日間ずっと苛まれてきた問題のヒントとなったからです。
（というとカッコいいかもしれんが現実にはパソコンに向かってるニート的人間であることに留意せよ。）
私はネット上のシステムを作っていたわけです。
mixiとかみたいに、ログインしたり書き込んだりできるシステムです。
そしたら、
「全くおんなじ状況なのに、なぜかプログラムの結果がランダム」
という意味不明な事態に見舞われました。（乱数とか使ってるわけじゃないです）
ときどきうまくいってときどきうまくいかないので、バグを消しようがない。
論理的に間違った部分も見当たらない。
神様、助けて・・・。
そんな気持ちでiTunesかけながらおかしいとこを探してたわけです。
結局原因は、わかりやすくいうと、
「バスの到着時間を信用しすぎてて遅刻した」
って感じかな。
自分としては毎朝おんなじ状況でバスに乗りに行くけど、
混んでたりするとバスは当然遅れるわけで、
そうするとそのあとの予定もおかしなことになるわけで。
参ったね。
関係ないけど中学校のときは雪で大幅に遅れたバスに乗って学校に行ったが
あまり信じてもらえなかったという話もあるよ。
こういう問題は並列化プログラミングでは当然考慮されているわけだが、
こっちはクライアントとサーバーの処理時間の差が影響するもんで、同期なんて取れませんよって話。
詳しい話をするとこんな感じ。
画像のセキュリティを実装するべく、画像をいったんPHPを介してセッションで認証してから
取得させることにしたんです。
画像ファイルってのはPHPで吐き出したHTMLを解釈しブラウザがHTTPリクエストすることで
取得されるじゃないですか。
そうすると、「HTMLを吐き出すメインのPHPがセッションの情報をクッキーとして（？）書き込むタイミング」（スクリプト終了時）と
「画像を出力するPHPの新しいセッションが確立されるタイミング」のどちらが早いかは、
Windowsさんがプリエンプティブに決めてるんですね（まぁつまり、Windowsのそのときの状態によりけり）。
だからうまくいかなかったのでした。残念。
ということで今はmemcachedを使うことを考えています。
もしくはsession_regenerate_id()を画像側では呼び出さないことによってファイルのロック解除を待ったりとか
しないのかなぁなんて一瞬思ったりしてます。それはまだPHPのセッションの内部設計が分かってないからです。
そんなの意識する必要はないはずなのにね。腹立つけど頑張ります。
これは正しい。というのは、プログラム自体は論理だから。
しかし・・・。
残念ながらプログラムの実行は
ハードウェア（物理）で行うという制約がある以上
同じ状況とは二度とありえないのでした。
え？じゃあいつもレポートで使ってるMicrosoft Wordも環境によっては
おかしな挙動をしだすのかい？
って話になるよね。
まぁ、流れ的にそうと言わざるを得ないよね。
詳しく言うと・・・
数学の定理は日本でもアラスカでも、１９０９年でも２１０９年でも常に成り立つ（し、そう保証できる）。
一方物理学の法則が将来にわたって、どの場所にあっても常に成り立つという保証はない。
これは数学が純粋な論理からなるのに対し、
物理学というのは物理＝「現実のあらゆるパラメータから起きている現象」からなるからである。
時間、空間的パラメータの影響が小さい場合に、
将来にわたって成り立つだろう、といえるのである。
さらに物理学の場合「状況は、不定である（確率である）」ということがあるので
「同じ状況である」ということもできなくなり、プログラムよりも不確かなものになるわけだが、この話は置いておこう。
さて、何でこのような話をするかというと、
ここ３日間ずっと苛まれてきた問題のヒントとなったからです。
（というとカッコいいかもしれんが現実にはパソコンに向かってるニート的人間であることに留意せよ。）
私はネット上のシステムを作っていたわけです。
mixiとかみたいに、ログインしたり書き込んだりできるシステムです。
そしたら、
「全くおんなじ状況なのに、なぜかプログラムの結果がランダム」
という意味不明な事態に見舞われました。（乱数とか使ってるわけじゃないです）
ときどきうまくいってときどきうまくいかないので、バグを消しようがない。
論理的に間違った部分も見当たらない。
神様、助けて・・・。
そんな気持ちでiTunesかけながらおかしいとこを探してたわけです。
結局原因は、わかりやすくいうと、
「バスの到着時間を信用しすぎてて遅刻した」
って感じかな。
自分としては毎朝おんなじ状況でバスに乗りに行くけど、
混んでたりするとバスは当然遅れるわけで、
そうするとそのあとの予定もおかしなことになるわけで。
参ったね。
関係ないけど中学校のときは雪で大幅に遅れたバスに乗って学校に行ったが
あまり信じてもらえなかったという話もあるよ。
こういう問題は並列化プログラミングでは当然考慮されているわけだが、
こっちはクライアントとサーバーの処理時間の差が影響するもんで、同期なんて取れませんよって話。
詳しい話をするとこんな感じ。
画像のセキュリティを実装するべく、画像をいったんPHPを介してセッションで認証してから
取得させることにしたんです。
画像ファイルってのはPHPで吐き出したHTMLを解釈しブラウザがHTTPリクエストすることで
取得されるじゃないですか。
そうすると、「HTMLを吐き出すメインのPHPがセッションの情報をクッキーとして（？）書き込むタイミング」（スクリプト終了時）と
「画像を出力するPHPの新しいセッションが確立されるタイミング」のどちらが早いかは、
Windowsさんがプリエンプティブに決めてるんですね（まぁつまり、Windowsのそのときの状態によりけり）。
だからうまくいかなかったのでした。残念。
ということで今はmemcachedを使うことを考えています。
もしくはsession_regenerate_id()を画像側では呼び出さないことによってファイルのロック解除を待ったりとか
しないのかなぁなんて一瞬思ったりしてます。それはまだPHPのセッションの内部設計が分かってないからです。
そんなの意識する必要はないはずなのにね。腹立つけど頑張ります。