くまちゃを飲もう2.7

自分の備忘録です。

某ゲームをプレイしてみた

culture

12/31、1/2　と　1/10に暇なので某ゲームをプレイしてみた。
ゲームを入手した経緯には悲しくなる出来事があって、多くは語るまい。

　 |l､{　 　j}　/,,ｨ//｜　　　　　／￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣￣
　 i|:!ヾ､_ﾉ／ u {:}//ﾍ　　　　　|　あ…ありのまま 今　起こった事を話すぜ！
　 |ﾘ u' }　 ,ﾉ　_,!V,ﾊ |　　 　 ＜　『ビックカメラに言ったら初回限定版PSPセット
　 fト､_{ﾙ{,ィ'ｅﾗ　, ﾀ人.　　　　|　　のタグを持ってレジに並んでたんだ』
　ヾ|宀| {´,)⌒`/ |<ヽﾄiゝ　　　|　催眠術だとか超スピードだとか
　　ヽ iLﾚ 　u' |　| ヾｌﾄﾊ〉. 　　|　そんなチャチなもんじゃあ　断じてねえ
　　 ﾊ !ニ⊇　'／:} 　V:::::ヽ.　│　もっと恐ろしいものの片鱗を味わったぜ…
　 /:::丶'T'' ／u'　__ /:::::::/｀ヽ ＼＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿＿

まぁ　いうなればポルナレフ状態だったわけだ。
もうちょっと正確に言うとPSPを布教活動で貸し出しているので、色違いを買
いたいと思っていると言ってしまった事が原因。


で何を買ったのかと言うと『今をときめくあのアイドルグループの47人を振っ
て1人を手に入れる』というリア充なゲーム。


ここから多少ネタばれもあるので読みたくない人は読まないように。




クリア順

柏木由紀　→　篠田麻里子　→　小森美果　→　高城亜樹　→　平嶋夏海
→　多田愛佳　→　佐藤すみれ　→　前田敦子　→　板野友美　→　渡辺麻友
→　宮崎美穂　→　大島優子　→　北原里英　→　宮澤佐江　→　小野恵令奈
→　渡辺麻友(2)　→　小嶋陽菜　→　仲川遥香　→　内田眞由美
→　佐藤亜美菜　→　河西智美

渡辺麻友(2)は偶然の2回目。
押しメンは誰かというのはさておき、かなり順不同です。ゲーム流れでなんと
なくの順番に近いかな。




感想
１時間プレイしてやっと１人クリアって感じ。中身は少し薄いかなという印象。
イベントの中身が共通(音声込みで考えれば全員違うと考えても良い)なものが多
い。まぁそこの感じ方は人それぞれ。
例えば、宮澤佐江のボーリングイベントとかは特有なのかな？
47人本当に振らなきゃいけないのかと考えてたので、大変なのかな？と思ってい
た部分もあったが、いわゆる「自然消滅」というのもあるので、そんなに大変で
はなかった。

しかし　ここまでやってまだ20名。選抜メンバーが大体、16〜21名なので選抜に
選ばれた事のある人は　大体一通り終わったのかと思いきや実際には、
　倉持明日香、秋元才加　指原莉乃
などをクリアしてない。
っていうか全48名なので　半分も終わってない。やっぱり先が長いなぁ。
もろもろコンプリート目指すと、もっと掛かるので、時間短縮方法をいくつか。




■全体の短縮

  • 一回見た会話は「×」を押し続けるとスキップ可能。
  • 目的のメンバー以外とにかく振りまくる。
    • (良心の呵責に耐えられるならばやるべし。俺には出来ない。性格出るねぇ)


■クリア回数を稼ぐ

  • 「明日会える？」と聞かれたら、「明日は予定があって」を選ぶ。
  • これで高感度をMAXのフラグを立てた事になる。
  • ポラロイド写真の色でわかるよ！
  • 高感度MAXが立ってれば　直接会って振らないと消えないので、この状態を複数名立ててセーブ。
  • ロードから再開して　告白　されれば回数が稼げる。
  • ちなみにムービーは告白　→　成功　or　失敗　の３種類なので、コンプリートを目指すなら両方見れば良い。
  • ちなみに一回クリアした人は各種画面で明示されるのでわかるよ。

ブラウザの挙動が少しずつ違う事にハマる。

Tech

ブログを書くのに時間が空いてしまいましたが前回のエントリで記述した通り、Responseが「200」と「304」で食い違う事で画面の崩れが起こる事までは調べる事が出来た。


そこで各ブラウザのRequestの出し方、およびResponseについて調査をする。
調査は、IE=ieHTTPHeaders／Firefox=Firebug／Opera=DragonFly／Chrome、Safari=Webkitで実施。
結果を「正常系」「異常系」「しょうもない系」に分類する。
結果だけをみると、以下の通り分類することができた。

ブラウザ HTML CSS JavaScript 画像 想定される結果
IE/Opera × × ○ × 古い画面が表示される(しょうもない系)、ただしJavaScriptが画像を呼ぶ場合は別
Firefox ○ × ○ × 画面が崩れる(異常系)
Chrome/Safari ○ ○ ○ ○ 新しい画面が表示される(正常系)

調査中に気付いた点、と疑問が発生
気付いた事　＝　同一ブラウザでもURLへアクセスする方法によってRequestの出し方が若干異なる事。
疑問　　　　＝　今回の問題提起が、safariに起因していることを忘れるべからず！！
という事。



そこで改めて（さらに細かい）調査をする事にした。


２度目はロード時のRequestの発行回数およびファイル種類を重点的に調査。
同一ブラウザでもURLへアクセスする方法によってRequestの出し方が若干異なる点については、果てしなく面倒だけど両方とも調べる。
具体的には

  • 空のWindow(ないしTAB)からブックマークで開く(もしくはURLを入力する)
  • どこかのサイトを開いているWindow(ないしTAB)からブックマークから開く(もしくはURLを入力する)

の掛け合わせで１ブラウザ4回調査。


結果としては最初の調査より大きな変化がなく、やはりSafariでは問題が起きてないとなる。
これはもはや端末とか設定の固有な問題なんだろうか。何か見落としてないか悩む。

WebkitのResource Consoleを眺めながら悩む事３０分ぐらい。ふとある事に気付いた。


CSSや画像のResponseに含まれる時刻が古い。
ぇ？いやいや。そんなバカなと思い、もう一度リロードしてみる
やはり古い。強制リロードしてみたら、ほぼ同じ時間に変わった。


少し時間をおいて試す。
同じ時刻にRequestを出した(はずの)ファイルに対する、Responseの結果。
HTMLに対するもの

CSSに対するもの


WebkitのResource ConsoleってRequest出してない時でも、過去に200を取った結果を表示するのか？？？？
ものすごい脱力感に見舞われて急激にやる気が減退(誰か求む追試)


改めて全部再調査の結果、以下の通りであることが分かった。
○＝リクエストが出る。△＝パラメーター付きだとRequestが出る。×＝でません。

ブラウザ 状態 動作 HTML CSS JavaScript 画像 想定される結果
IE8 空Window(タブ) ブックマーク ○ ○ ○ ○ 新しい画面が表示される(正常系)
ＵＲＬ直打 ○ ○ ○ ○ 新しい画面が表示される(正常系)
利用中Window ブックマーク × × △ × 古い画面が表示される(しょうもない系)
ＵＲＬ直打 × × △ × 古い画面が表示される(しょうもない系)
Firefox3 空Window(タブ) ブックマーク ○ × △ × 画面が崩れる(異常系)
ＵＲＬ直打 ○ × △ × 画面が崩れる(異常系)
利用中Window ブックマーク × × △ × 古い画面が表示される(しょうもない系)
ＵＲＬ直打 × × △ × 古い画面が表示される(しょうもない系)
Opera／safari／Chrome 空Window(タブ) ブックマーク ○ × △ × 画面が崩れる(異常系)
ＵＲＬ直打 ○ × △ × 画面が崩れる(異常系)
利用中Window ブックマーク ○ × △ × 画面が崩れる(異常系)
ＵＲＬ直打 ○ × △ × 画面が崩れる(異常系)


ついでに開発用のサーバをお借りして、再現テストを一通りやっておく。



今までの調査結果をPPTにまとめてレポートを提出。
結果、最初に調べてた
Pumpkin Moonshine JavaScriptやCSSの更新時にキャッシュから読ませないと同じようにスタイルシートの名前を変える方法が採用されそうです。
まぁ　最初からそれがゲフンゲフン　なんでもないでござるよ。


運用方法まとめて展開しないとなぁ。とか考えてた時に、自動で出来ねーかなとか考えてしまう。
暇つぶしの楽しみにそれは取っておこう。


参考

調査のついでにブラウザ毎のRequestにのる内容を調べてまとめた。

ブラウザ 動作 If-Modified-Since If-None-Match Cache-Control Pragma 備考
IE8　　 ロード　　　 ― ― ― ―　　 　
　　　　 リロード　　 ○ ○ ― ？*1
　　　　 強制リロード ― ― no-cache ？*2
Firefox3 ロード　　　 ― ― ― 　　　 ―　　　 　
　　　　 リロード　　 ○ ○ max-age=0 ― 　
　　　　 強制リロード ― ― no-cache no-cache 　
Opera10 ロード　　　 ― ― ― 　　　 ―　　　 　
　　　　 リロード　　 ○ ○ ― ― 　
　　　　 強制リロード ○ ○ ― ― 強制リロード＝リロード
Safari5(Win) ロード　 ― ― ―　　　 ―　　　 　
　　　　 リロード　　 ○ ○ max-age=0 ― 　
　　　　 強制リロード ○ ○ max-age=0 ― Windows版だと、リロードと同じ？
Chrome　 ロード　　　 ― ― ―　　　 ―　　　 　
　　　　 リロード　　 ○ ○ max-age=0 ― 　
　　　　 強制リロード ― ― no-cache no-cache ―

*1:InternetExplorerの確認に利用した、ieHTTPHeaders で見れないのか、吐き出してないのか不明

*2:InternetExplorerの確認に利用した、ieHTTPHeaders で見れないのか、吐き出してないのか不明

なぜデザインが崩れるのか調査開始

Tech

どういうときに崩れるのか調査

なぜ崩れを起こすのか、原因を想像してみる。
担当者の報告による「画面が崩れる」を改めて詳しく聞いてみると
　・画面に追加したパーツは正常な位置に反映されていた。
　・画像は新規リリース分だったが、正しく表示されていた。
　・上記からHTMLは正しくリリースされているように見えた。
　・スタイルシートに追加した新しいスタイルが適用されなかった。
という報告が得られた。
報告内容をまとめると「css(たぶん画像とJavaScriptも)をキャッシュから読んでいて、HTMLをサーバから取得しているから。」という仮説を立てることが出来る。
ではなぜその現象が起こるのか整理してみると下表のようになる。

ケース HTML　 CSS　 結果
ケース１ 古い　 古い　 古い画面が出る
ケース２ 新しい 古い　 デザインが崩れる
ケース３ 古い　 新しい デザインが崩れる*1
ケース４ 新しい 新しい 新しい画面が出る


今回の依頼はケース２（またはケース３、ただし担当さんの証言からはケース２の方が有力）が起こっていた事になる。
前回のエントリで記述した「リリースの問題」を含めて考えると、

  • ケース１＝全部リリースに失敗
  • ケース２＝HTMLのリリースが先行もしくはCSSのリリースが失敗
  • ケース３＝CSSのリリースが先行もしくはHTMLのリリースが失敗
  • ケース４＝リリース成功

になるけど、リリースは「同じ時刻」だったことを考えると「ケース４」だったことになる。


他にどんな時に「ケース２」「ケース３」が発生するのか考えてみると『HTTP Responseの返却値』が正しくない(想定していない動作をした)時という事になる。
改めて整理してみると下表のようになる。

ケース HTMLに対するResponse CSSに対するResponse 結果
ケース１ 304 304 古い画面が出る
ケース２ 200 304 デザインが崩れる
ケース３ 304 200 デザインが崩れる*2
ケース４ 200 200 新しい画面が出る

リリース直後の正常な状態は、ケース４のみで、ケース１〜３は想定外の事が起こっていると言えるだろう。
ここまでをいったん偉い人にレポート。疑うべきはまず身内からということで、Response返却方法の調査に進む。


自社のWEBサーバの構成調査

HTMLとCSS(その他)の扱い方。

  • HTMLは動的生成されるのでTOMCAT側で管理。
  • CSS(その他)はApacheで管理。Apache側が返却方法を決めている。

図に起こすと↓のような感じです。

「HTMLを動的生成しているので、Requestが来ればHTMLに関しては常に200が返るので、ケース３は発生しないのでは？」という指摘があった。
・ブラウザはRequestを送ってくるのが普通である*3。
・リリースが正常であることを確認済み
・担当さんの証言からもケース２の可能性が濃厚。
整理してみれば、確かにケース３は可能性がかなり低いと考えられ、ケース２が怪しい事になり、Apacheのキャッシュチェックの挙動を調べるのが進むべき道としては正しそうだよね。

*1:古い画面が出るだけで崩れないケースもある

*2:古い画面が出るだけで崩れないケースもある

*3:つまりキャッシュがないなら普通のRequestを送ってくるし、キャッシュを既に持っていれば、そのキャッシュが正しいか確認のRequestを送ってくる

WEBリリース時のデザイン崩れに対処してほしいという依頼

Tech

またも社内「なんでも屋」の出番です。しつこいですが、所属はマーケティング部です。
今回の依頼は「WEBリリース時にデザイン崩れが起こるので、解決方法はないのか」というものでした。

現象

起こっている現象について担当さんから報告をもらう。

  • WEBデザインの大幅な修正をリリースするとデザイン崩れを起こす。(かなりの確率で！)
  • 明確に報告をもらったことがあるのは、Firefoxとsafari(Windows版)のみ。
  • IE、Opera、safari(Mac版)、Chromeでは報告なし。(が起こっている可能性あり。つまりよくわからんとｗ)
  • safari(iPad版)もらしい。今日の依頼のきっかけがたぶんこれ。


まず真っ先に疑ったのが「リリース手順の問題では？」

リリースの手順

担当さんにヒアリングした順番は以下の通り。

  1. 画像
  2. JavaScript
  3. css
  4. HTML

ふむ、まぁ妥当だよね。
と思いきや、順番に作業しているだけで、最新版がリリースされているか恐らく確認していない。＠管理担当者
その順番に作業しているだけとか言われると、タイミングでリリースが前後する可能性が否定できない気がするんですが。
まさに仕事ではなく「ボタンをぽちぽちする簡単な作業です。」って事かい。


しょうがないのでシステムの人にリリースのログを調べてもらってリリース時刻を確認。
本番サーバへの反映は２分毎のため、ほぼすべてのファイルが、同じ時刻にリリースされてました。
しかし同じ時刻にリリースされているなら、画面崩れを起こす理由がないはず。(過去は知らんが、少なくとも今回は！)


じゃあ、残る可能性は
・css(たぶん画像とJavaScriptも)をキャッシュから読んでいて、HTMLをサーバから取得しているから。
に絞られるのかな。

簡単に解決出来る方法を探してみたら、「Pumpkin Moonshine JavaScriptやCSSの更新時にキャッシュから読ませない」という方法を見つけた。


ということで偉い人に「この方法でどうですか？」と持っていったら、「ダメ」と言われますた。
えーっとダメですかｗ


「ダメ」＝恒久的解決方法が無いか探して欲しい


という意味です。
私の提案は、「運用で何とかしてください」だったため、「最終的にこの方法しかないなら、それは仕方がないけど、何かあるんじゃないの？」と。
ここから怒涛の２日間が始まりました(^_^;)

OB会

various

高校剣道部のOB会で池袋の土風呂にいって来た。
この店、最近なんかで飲んだような記憶があるけど。。。

参加したのは

  • 78-79　1名
  • 79-80　2名
  • 80-81　4名
  • 81-82　1名
  • 82-83　1名
    • 合計9名

19時スタートで飲み始めて、まぁ社会人だけなんで、なかなかスタートで全員というのも難しいけどね。
ぱらぱら集まりながら、9名そろったのは20時半頃だったかな。


測量のお仕事、建設機器の設計、溶接工、ホテルマン、不動産の営業とか、みんないろいろな仕事してて、それぞれに感心したりしてました。

結婚してたり、子供ができてたり、離婚してたり（離婚率が高い！）、自分の話もやっとカミングアウトしたり(ぉ

昔の話も、今の話もそれなりに楽しくしてきました。

23時ごろお店を追い出されてお開きでした。


カミングアウトしたおかげで、OB会のあと小一時間ほど、池袋駅の改札付近で、お説教（？）されたりしてたら、丸の内線が茗荷谷行きしか残ってなく、若干悲惨な目にあいましたが。

帰りの電車の中でTwitterのTLみてたら、お説教されてる時にリアル友人がほろ酔いでその付近を通過していたようなことをつぶやいてて冷や汗ものだったり。


今回は誰かのメールアドレスの変更がきっかけで集まることになったようだけど、もう少し定期的に集まりたいよね。
参加できなかった人は次回は参加してほしいです。
その前にどうやって連絡先を調べるかそれが問題。