読者です 読者をやめる 読者になる 読者になる

なつやすみのにっき 9/10

デレステios版に翻弄された一日だった。結局課金してしまったしちょっと侵食されすぎな気がする……まずい。

それはそれとして一応勉強内容。数学はやっぱりよっぽど疲れてない限り一気に(目安10ページ)やってしまったほうがいいな。というかこれやるときはリビングじゃなし、娯楽も封じたほうがいい。中学生かよってくらいの気付きだけど、本当に長い間(自主的かつ興味がないことの)勉強なんてものをしてなかったからなあ。猛省。

locationディレクトリのパス指定については昨日貼ったリンク参照。prefixに優先度があることがわかった(そもそもアレが何が)のでよかったよかった。

正規表現についての解説がなかったけど、今までちゃんとしらなかったけど正規表現ってどこでも割と一緒なのな。というわけでこの辺を参考にすればいいと思う、

サーバー関係/nginx - 神嶋教授の独白

正規表現の構文

[jpeg|css] と (jpeg|css)みたいな違いにだけ注意したい。[]は文字レベルなので"j or p or e or……"みたいになる。()は一連のつながりを認識してくれる。

あとセッションについてちゃんと覚えてなかったので普通に復讐した。 要は通信自体はステートレスで、でも「状態」はどこかにもっとかないといけないよねー => ブラウザにクッキーという鍵を持たせて、鯖側でその鍵と状態を紐付かせればいいじゃん、という話(だと思う) sinatraとかが便利なようにsessionという抽象概念で包んでくれてるんだけど、そのおかげで実際に何をやっているか透過的でない。

クライアントがログイン成功する

クライアントのクッキーにsession_idを仕込む

以後そのクライアントの「そのアクセス」に紐付けたい情報が存在する場合はそのsession_idに適当に情報を紐付ける。多分それがmemcachedだったり云々みたいなところだと思う

クライアントがログアウトしたらそのsession_idに紐づく情報を削除して、クライアントのクッキーからsession_idを削除する

みたいな感じ。 なおiSUCON3の参考実装にあったanti_csrfメソッドで使用されているtokenなるやつはユーザーがちゃんと意図したページからリクエストを投げているかをsession_idを利用して確認しているだけで本質的にはセッション管理とは関係ない(と思う)。

ちゃんと読んでないけどこれが詳しそうだった。

qiita.com

すべてのデータをクライアント側のクッキーに保存するやり方もあるらしいが、非推奨らしい。というかそれなんかのアンチパターンで読んだな……Railsか。

qiita.com

このへんのやつはSinatraというかRackで用意されてる機能っぽい。Rack、Sinatraあたりのソース読んでもいいかもなあ、そこまでボリュームないみたいだし。

ちなSinatra参考ページ

Sinatra: README (Japanese)

とはいえ日本語だと情報少ないのでこの辺も見たほうがいい。というかDallo使ったセッション管理の情報どこにもなかったな……

Sinatra Recipes - Middleware - Share Session With Memcached

Sinatra: Documentation

明日はちょっと時間取って一人で一回予選といてみることにしようかな。あ、じゃあ今日と帰れないじゃん…… というか通帳届かないとだめというか受け取り証送り返さないとだし ん〜〜〜〜〜〜〜〜〜

そういえば同窓会があるらしい。恥を忍んで参加を申し出たので楽しみ、というかもうみんな外の世界で色々なものをみてきて私はもはや特別な存在ではないのだな、ということをしみじみ感じる、もっとも「もはや」という部分がおこがましいし、実際そうだったという保証はどこにもないんだけど。

ありがとうサイゲームズ、ありがとうバンダイナムコ、ありがとうクロームキャスト

ところでもう英語の日課は消えてる感じなってるけど、なんとかしないとなあ。景気付けに本でも買うか。