なんか違和感が…
元ネタ
Cookieを利用したセッション維持(Sticky)の問題点
http://itpro.nikkeibp.co.jp/article/Watcher/20080728/311618/
直近に違和感を感じたのは、この文章。
IE(Internet Explorer)のCookieサイズはおおよそ4〜5kbyteなようです(他のWEBブラウザーもほぼそのくらいなようです)。最近はこの容量制限をオーバーするケースが非常に増えてきたように思います。この制限をオーバーすると当然のことながらCookieを利用したセッション維持に失敗します。
ではなぜ最近容量制限をオーバーするケースが増えたのか。それはタブブラウザの普及が原因なようです。他のブラウザはよく知りませんが、IE7では全てのタブでCookie情報を共有するようです。これは1つのタブでログインしておけば他のタブでもログイン状態が続くので便利という側面もあるのですが、わずか4〜5KBしかないCookieサイズを1つのブラウザで共有するのでタブを開けば開くほど限られたCookie容量がひっ迫してくることになります。
えと…「なんでタブ開くたびにCookieが増えるよ？」とかいう突っ込みになるわけなのですが。
よくよく冷静に読んでみると。ヒントはここ。
ロードバランサーの機能のうち、セッション維持は重要な役割な一つです。
なるほどねこれか。
で、解説。
元文章には、重大な「不足部分」があるです。
前提条件は…ここがいいかな。
第4回 ロードバランスクラスタの実装
http://www.atmarkit.co.jp/flinux/rensai/cluster04/cluster04.html
内にある
■http CookieによるSticky
プロキシ経由では同じソースIPアドレスになってしまうため、ロードバランス装置の中でクライアントごとに異なるCookieを生成します。その Cookieをクライアントに送ることでクライアントを識別し、ノードに分散させると同時にセッション維持のためのキーとして利用します。
つまり。前提条件として
わけです。
…うん斜めに読むと、ロードバランサの部分さらりと読み飛ばしておいちゃん一瞬びっくりしたよ orz
で、おいちゃん的(或いは我留流的)回答。
「ンな重い事ロードバランサにやらすんな」。
各種異論はあろうかと思いますが。最終的に横ちょに広げるときに、ボトルネックは出来るだけ作りたくない主義なので。それを考えると「ロードバランサ使って１ユーザを１マシンに紐づける」よりも「全部DBでセッションもってあとはフリー」のほうが圧倒的に楽なわけです。
DBはやり方次第で「かなり無限に近い量まで横ちょに増やせる」やり口があるので。
それにしても…うんもう少しちゃんと前提条件書かないと、わからない人っつか気づかない人とか誤解する人多いんじゃないかなぁ？
寒すぎる携帯系Webサイトの現実
まぁとりあえず何はともあれ、高木先生の
無責任なキャリア様に群がるIDクレクレ乞食 ―― 退化してゆく日本のWeb開発者
http://takagi-hiromitsu.jp/diary/20080727.html#p01
ご覧いただければ終わるっちゃぁ終わるのですが。或いはすでに終わってる現状がよく見えるのですが orz
おいといて。
とりあえず、ここでキモになる部分をざくりんこと抜き出すと。
- どう考えても「偽装出来そうなルート」が多々ある契約者固有IDとか機種固有IDとか
- そも「偽装なんて存在しない」と言わんばかりの -検閲削除- な開発者(きっと多分ごく一部のはづ
- 「IPアドレスでチェックすれば大丈夫」って例えばIPアドレスの偽装とか。或いは「DoCoMoのIP帯域でAUなuser-agentと詐称した契約者固有IDってちゃんとはじけてますか？」とか
- 大体キャリアの「IPアドレスはここだけだよん」は「本情報はあくまでも目安としてご参照ください」と３キャリアともコピペ状態
- っつかその情報がhttpって時点で色々偽装できるよねぇとか
- でも「検索用に検索エンジンのクローラ用のIP」ってこじ開けてるよねぇそこから入れない？
などなど。
平たくまとめると「限定区域だから大丈夫とか言ってるけどその限定区域になる柵がだめだめのぼろぼろの幻だから平たく言って危険に過ぎるよねぇ」というのがおおよその中心部。
そも「限定区域だから大丈夫」の限定区域がほんとうに限定であった試しなどほとんど以下略。
それもまたおいといて。
普通に冷静にまっすぐに考えて。通常のPCサイトと同じような発想で、セッションなり何なりを維持するのが一番だと思うのですが。
例えば、IDの代わりに契約者固有ID、ってのはまぁありだと思うんですよ。プラスしてパスワードがあれば。
で、当然ながらセッション維持には契約者固有IDを使わない、と。
そうするとですねぇ。当然の帰結としてセッションIDを引き回す必要があるわけなのですが。
………大変に -検閲削除- な事に。DoCoMo端末、Cookie使えません。
どうでしょういっそ「DoCoMo端末を抹消する」ってのは。いいなぁサイトのTopに「DoCoMo端末からはご利用いただけません」らいぶりぃだなぁｗ
まて落ちつけ。
まぁ非常に残念かつ遺憾な事に、そうも言ってられません………多分。
とはいえ。セッションIDをGETパラメタに持つなどという狂気の沙汰はまず大抵以下略です。
となると…あとは「全部formとかにしてhiddenで持ち回す」そうですこれです！！
Aエレメント一切使えなくなりますがぐっじょぶです！！
………そろそろ限界 orz
わりとマジな話として。
そうも言ってられない現実は山盛りてんこ盛りです。
とりあえず、直近としては。
- 認証(authentication と authorization http://d.hatena.ne.jp/gallu/20080203/p1 )の処理は一箇所にまとめておく
- とりあえず当面、苦渋の選択として「契約者固有ID」使うとして、いつでも乗り換えられるように準備しておく
ってのが、この辺でおまんま食ってる人間の真っ当な…逃げ道だと思うです。はい。
っつかね…うんこのエントリ、本気で精神負荷高いわ orz
馬鹿話的妄想
注意：限りなく ピー な内容ですご注意ください。
んと。作ってみたいサービスがあるです。Web系のフロントでクラスタリング３台くらい、後ろのDBサーバも３台くらい用意。
まずフロント。
一台はWindowsでIISな.NET C#で実装。
一台はLinuxでlighthttpdなRoRで実装。
一台はSolarisでApacheなPHPで実装。
の三台を「クラスタリング」。え？ Webだもん「同じhttpリクエスト」なら同じ動きするよねぇ？(笑
バックってかDB。
１台は更新用。オラコーとかかな。で、更新されると参照系の２台にレプリ。
参照系の１台はMySQLで１台はPostgreSQL。
Webサーバがどっちの参照系を見るかはランダムとかかしらん？ 適当に負荷分散とか言ってみるｗ
え？ ちゃんと「標準的なSQL」使えばいけるでしょ？*1 *2
うんまぁですね。
「１つのアプリケーションやらデーモンやらがなにがしか問題があっても別のソリューションでヘッジ出来る」とかなんとか色々「それっぽい言い訳」は出来るのですが。
ぶっちゃけ一言で片付けて「こんな気の狂った有り得ない設計の実装してみたい」ってのがストレートに本音でございますｗ
なんていうか…技術者として。一本筋の通った「お馬鹿」をやってみたいなぁとか時々ｗ
iPhoneのuser-agent
篤志(笑)の友人にお願いしてたものです。
Mozilla/5.0(iPhone; U; CPU iPhone 2_0 like Mac OS X; ja-jp) AppleWebKit/525.18.1KHTML, like Gecko)Version/3.1.1 Mobile/5A345 Safari/525.20
なるほど本気で普通にSafariなのですな。
JavaScript(ジャバスク) JavaScript(ジャバスク) 楽しいな〜♪
…あんなクラックやこんなクラックｗ
いやまぁ近日色々書き連ねたいのですが。
いい加減「携帯サイトだからセキュリティは甘くてもよいんだよ」とか言うてられる状況ではまったくもってないと思われます。
とか微妙に余談っつか雑感込み。
B-CAS社が素敵すぎる件について
んと。地デジのために無くてはならない会社さん……………の、はづ、なの、ですが。ね。
ちなみに一応。
B-CASカードとは何ですか？
B- CASカードは、デジタル放送受信機に同梱されているICカードです（台紙に封止された状態で同梱されています）。BS・110度CS・地上デジタル共用受信機には赤色のB-CASカードが、地上デジタル専用受信機には青色のB-CASカードが同梱されています。B-CASカードは、デジタル放送の有料放送、自動表示メッセージ、番組の著作権保護、データ放送の双方向サービスなどで利用されています。
という、地デジのためのまさに必須アイテムなのですが。
http://d.hatena.ne.jp/JavaBlack/20080713/p2
http://ja.wikipedia.org/wiki/B-CAS
http://blog.goo.ne.jp/ikedanobuo/e/e3b44ae168cda176cb937bf809bfe8ec
http://gigazine.net/index.php?/news/comments/20080625_bcas/
http://slashdot.jp/yro/article.pl?sid=08/07/09/1013217
http://gigazine.net/index.php?/news/comments/20080709_bcas_financial/
まぁお好きなところから。
とりあえず、 id:JavaBlackさんの
史上*1を独占して巨額の資金が流れ込んでいながら財務状況も存在も謎に包まれてるって，一体どこの犯罪組織のダミー会社ですか．
この一言が楽しいくらいにぴったしカンカン。
*1:市場だと思われる
とりあえず駄目すぎるorz
ネタもとはここ。
Vol.46 システム品質より プライドを優先 開発を混乱させる
http://itpro.nikkeibp.co.jp/article/COLUMN/20080321/296728/
さぁ眠さにまかせて突っ込んでみようｗ
M子さん（29歳）は，ITベンダーのB社で働く中堅エンジニアである。
この「中堅エンジニア」ってのが後半の突っ込みに大切なスパイスとなりますｗ
彼女が「中堅エンジニア」であることを心に留め置いて以下ご覧ください。
M子さんが所属するのは，契約システム開発チームだ。一口に契約システムといっても，新規契約だけではなく途中解約や事故による契約解除業務などを含み，開発規模は大きい。チーム編成は，Nリーダーのほかエンジニアが7人。女性はM子さん1人である。
とりあえず状況を明示、っと。
ところが，12月に入って状況は一変した。結合テストで，15ものバグが発覚したのだ。それも，ほとんどがM子さんの担当部分だった。
「なんで結合まで気づかないかね？」ってのがまず初手の突っ込みとして。どう考えてもユニットテストの類がろくすっぽ出来てないとしか思えない。
Nリーダーは急きょ，メンバーを会議室に召集した。「総合テストは6週間後だ。それまでに，システム品質を確保しなければならない。見通しはどうなんだ」。Nさんの問い掛けに，ベテランのPさんが答えた。「バグの数から言って，3週間は見ておくべきでしょう。理想的には，4週間あれば…」。慎重派のP さんらしい発言だった。
Pさんは多分チームメイト。バグの粒度がわからんので、とりあえずこの台詞は鵜呑みにするとして。
そこに，M子さんが割って入った。「私にやらせてください。責任を持って2週間で片付けます」。メンバーの視線が，M子さんに集まった。Nリーダーの顔に一瞬，不安がよぎった。M子さんは，さらに言い張った。「私の担当で発生しているバグです。皆さんに迷惑はかけません」。チームの足を引っ張りたくない一心だった。そんなM子さんを，Pさんたちは心配そうに見ていた。
んとね気持ちはわかるけど。
Nリーダーは，しばし考え込んだ。確かに，まだ手付かずのテスト項目は山積みで，バグ修正に手を取られるのは痛かった。
って状況もわかるけど。せめて、Pさんをレビュアーとして突っ込まなきゃ。
新人研修は，決して楽ではなかった。「TCP/IP」や「ミドルウエア」といった耳慣れない言葉が，M子さんを当惑させた。プログラミングにも手を焼いた。それでも，M子さんは必死についていった。文系だからといって，同期には負けたくなかった。理解できないことはすぐ講師に質問したし，ITに詳しい同期をつかまえて解説してもらうことも度々だった。
聞き慣れない単語なんざすぐ慣れる。文系が云々とか関係ないし。まぁ「質問したおす」その姿勢はよし、なのだが。
…なら「なぜ今回もちゃんと周囲を質問攻めにしてでも理解しようとしない？」
3年前，金融サービス事業部に異動した際も，徹夜をいとわず作業して経験不足を補った。入社以来，年末年始やゴールデンウィークでさえも，まともに休んだ記憶はない。「女性であることをハンデにしたくない」という思いが，M子さんのがんばりを支えていた。
ダウト。「徹夜をいとわず作業して経験不足を補った」あのねぇ。不足を時間で補える業界じゃないからITって。
駄目な人が16時間やったらちゃんとした人の８時間分の作業には、間違ってもならないの特に品質の部分が。
入社以来，年末年始やゴールデンウィークでさえも，まともに休んだ記憶はない。
いいから休め。休みの間に本でも読んでろ。
さて，契約システムのバグが見付かってから2週間が経過した。M子さんは連日，深夜までバグと戦っていた。しかし，進ちょくは思わしくなかった。総合テストの日程は，容赦なく迫ってきていた。
いち。当たり前「時間費やしたからバグがつぶれる」ならみんな困りません。っつか「中堅エンジニア」ならそれくらい気づこうよ？
に。Mさん「２週間」言うてたんでしょ？ リーダーさんいい加減介入しないと。っつか普通「１週間で進捗が芳しくなければ介入」だよねぇ甘めに考えても。
さらに1週間が過ぎたころ，NリーダーがM子さんの席にやってきて進ちょくを尋ねた。
遅すぎ。ちゃんとクリティカルパスとかそういうあたり意識してる？
「緊急事態だ。バグ修正が遅れている。P君，M子さんのサポートに回ってくれ。P君の作業分は，他のメンバーでカバーする。どんなことがあっても，3週間後に始まる総合テストに間に合わせるんだ。以上！」
これが３週間前に言えてりゃいいんだけど。このタイミングじゃ「駄目管理者」の烙印押されるよ？
男性エンジニアに負けまいと，体力の限界までがんばってきた。
だからこの仕事体力じゃ片付かないって。論点間違えすぎ。
うんなんていうか駄目な人が多すぎて「どこが駄目？」って聞かれたら「全部」とか答えちゃいそう(苦笑
答えのない世界
んと。なんかテレビで大学生をインターシップにして云々いう番組をやっていまして。
なんでも「想定力が足りない」とかなんとかいう話をしていたのでふと気になって。
割合に多くの、特に「学生さん」「教育関係者」がはまるのですが。
学校のお勉強は、基本的にゴールもあれば正解もある世界観です。
でも、現実IT系のお仕事やってると、ゴール設定がないに等しくて答えが存在しない、なんて事も少なくありませんっていうかそっちのほうが普通です。
ある程度慣れてくればよいのですが、とくになれないうちや個人の資質、性格などの問題から「どこか正解がある事を前提にした考え方をしている」人は少なくなくて。ただ、それをやると大抵どこかで大きく失敗します。
で、想定力、という話なのですが。正直言いますと「想定なんて出来ない」と思ってます。この業界。
このあたり…私が趣味にしている、TRPG、というゲームに似ているのですが。
人間、自らの経験や人の話を聞いたあたりから、可能な限りの「全ての可能性」を想定しようとするのですが。
ハッキリと暴言を吐きますと「大抵の人はおかしい」です。
より正確には。
全面的におかしい事は希ですが、１〜２割前後くらいは「なんでンなことしたいの？」と聞きたくなるような、おかしな発想を持っています。
んで。どんなに頑張って鍛えても「その斜め上を行く想定外な発想」っていうのは少なくなくて。でも、その発想こそがビジネスに大きな意味合いを持ったりする事もまた少なくありません。
そこで「どれだけか想定して自らの想定内に落とそうとする」と、想定外の発想に対して対応できなくなります。
しかし、多くの「正解がある世界観の人々」は、どうしても「想定すればいつかは100%網羅出来る」って思ってるように見えるんですね。
なので、奇抜な、でも面白いクライアントのアイデアに、どちらかというと嫌悪感すら抱くような印象を時々受けます。
なので。ある程度大筋はいくつか想定しておくとしても。
「まぁそうはいっても想定外な話も来るんだろうなぁ」と、そのあたりは緩く柔らかい発想力を持ってみてください。
あんまりにもあんまりな想定外のお話なら「ンであんた何したいの？」ってお客様に素直に聞けばいいんです。
アイデアの発露たる「やりたい事」は突拍子もなくても、そこに至る道は、案外に順当なものですから。
なので。
想定力なんてぇものを磨くくらいなら、神経の太さと「質問力」を磨いた方が、多分有利なんじゃないかと私は思います。
…まぁ私の経験範囲内での話なので「甘〜い!!」と突っ込まれる可能性も多々ありますが。
