WIN5初体験の反省会

やはりハープスターは飛びました、予想通りです。
現役最強馬のキズナは大阪杯を予定しているので、ここは落とす可能性はあると思っていましたが相手が弱すぎるので確勝だと思っていたのですが。。。。
どスロー前残り天国はどうにかして欲しいものですね。
誰も4角まで捕まえにいかないんだから、そりゃど下手の戸崎君が勝ちますわ。
本来は4角までに番手の馬達が前を捕まえに行かないといけないのに、直線向くまで誰も動かない競馬になると後ろの馬は届きません。

しかしハズれたとはいえWIN5面白いですね。
初戦の京都10Rが小頭数かつ強い馬がいたのでWIN5にしてみましたけど、最初から購入予定だったキズナの複勝だけだったら1.5倍も付いてたんですね。
5レース中2レースしか的中しなかったですが、勝負は小倉11Rと京都11Rでした。

まず京都10Rですが、前残り天国の糞レースでした。
武さんはもう少し前に付けて欲しかったですね。
直線平坦な京都で、馬が抜けているとはいえ後ろから行くのは好ましくありません。
結果論ですが、キズナくらい抜けている馬でも届かない馬場なんですから。
これは本来的中しているハズの事故だと考えてオッケーでしょう。
悪いイメージを引きずって穴狙いに走る方が悪い方向にいくと思います。

次に東京10Rは当たったので文句ありません。

次に勝負の分かれ目小倉11R
ここは2桁人気の馬を抑えていたように、軽斤量・内枠先行の馬が怖いと思っていました。
予想通り内枠先行した2番が勝っていますが、競馬ブックの展開予想では差しになっているんですねw
5頭までは普通に強そうで人気になっている馬を買いました。
3と7は内から逃げ・先行予想になっていた馬を抑えました。
結果的に競馬ブックの展開予想さえあっていれば2番を抑えれていたという話なので、読みは当たっていたのでオッケーです。

次に京都11R
これはキズナに託していたので何の問題もありません。
大阪杯でリベンジしましょう。

最後に東京11R
当たったので文句ありません。
福永今日はどん詰まりせずに進路取れましたねw

さて、当たったのはたった2Rですが、気分的には京都10R以外は想定の範疇でかなり手ごたえを感じました。
月に1回くらいはWIN5を買ってみたいと思える内容でしたね。
今日みたいに最初に小頭数のレースがあるような日をまた狙ってみたいです!

win5を生まれて初めて買ってみた!

今日はキズナのカムバック戦!
世間ではハープスターとの2強ムードですが、実質キズナの1強レースです。
WIN5では、後ろの方のレースで固いレースがある方が点数が抑えれますからね。
キズナの複勝にブチ込むか悩んだ末に初めてWIN5を購入してみました。
これでも4万円近くかかるのですから、普通に頭の痛いレースだと10万円じゃ足りなさそうですね。
WIN5をメインに買っている人の軍資金は余裕で100万円以上無いとやってられないんじゃないでしょうか?

初WIN5

テイルズオブゼスティリアという名の糞ゲー

これ酷過ぎるんですけど、どこか初めての会社に外注したんですか?>バンナムさん

キャラクターに話しかける>○ボタン:話しかける
ディスカバリーポイントを調べる>○ボタン:調べる
といった、ある座標に対する判定が異常にシビアでおかしいのでストレスが溜まります

○ボタン:調べるといったオペレーションウインドウが一瞬だけ表示されて消えてしまう。
キャラの周りをグルグル回っても○:話しかけるが表示されるポイントが特定の角度でしか反応しないなど。

そして会話のセリフ飛ばしの挙動もおかしいです。
私は声優なんて興味がないので、表示されているセリフを読んでしまったら、キャラが喋っていてもスキップするのですが
スキップの挙動が、セリフが消えて固まります。
本来○ボタンを1回だけ押下すればスキップできるシチュエーションで、画面が固まったのに気付いて2回目を押下しないといけません。
100%画面が固まる訳ではないので、2回押すクセをつけてしまっては、次のセリフを読まずにスキップしてしまう事もあるというトラップ付きの極悪仕様です。

エクシリアではちゃんと出来ていた事が改悪されているって、完全にスキルの低い作り手に変わったとしか思えないんですけど?
ストレスたまるからパッチ出てくれないかなぁ・・・・?

ファイナルファンタジー零式の読み方について

ファイナルファンタジー零式の読みは「ぜろしき」ではなく「れいしき」らしい
スクエニの人のtwitterが公式見解みたいですね。

理由は零式というのは、戦時中の戦闘機とかの読みで「れいしき」という読みしかないからだみたいです。
この見解は正直見誤っていると思いますね。
「ぜろしき」でググった方が圧倒的に多く出るように「れいしき」は既に死後と言えます。
これは覚悟のススメで零式防衛術(ぜろしきぼうえいじゅつ)という言葉で浸透したのかもしれません。
現代社会では零式と書いて「れいしき」と読む人はいないと言う事です。

重複という読みは「ちょうふく」が正しく、昔の広辞苑には「ちょうふく」という読みしかありません。
ですが「じゅうふく」という誤った読みが浸透してしまった為に、現在ではどちらで読んでも構わない物となっています。

零式と書いて「れいしき」と読む年齢の人はほとんど他界されている、この現代社会で「れいしき」が正しい読みとするのはちょっと非常識でしょう。
ほとんどの人間が「ぜろしき」で読む事が浸透しているのですから、ユーザーを混乱させる事なく「ぜろしき」という言葉に統一しておけば良かったと思いますけどねぇ。

nullの読み方

個人的に読み方なんてものは、通じればどうでも良いです。

これは単語なので正しい読み方はナルで確定です。
ですが、私はヌルと読みますね。
ヌルポ > ガッの流れを見てもヌル派が圧倒的でしょう。

pingの読み方

個人的に読み方なんてものは、通じればどうでも良いです。

これは単語なので正しい読み方はピンで確定です。
ですが、私はピングと読みますね。
ピン打ってじゃ通じない方が多いので、ピングと読んだ方が通じるというだけの理由です。

cronの読み方

個人的に読み方なんてものは、通じればどうでも良いです。

クロン、クーロン、クローンとか色んな読み方をする人がいます。
私はクロン派です。
理由はーと伸ばすのが面倒だからです。
これは大昔から存在していた仕組みなので、仕組みが登場した時にググるとか無いですね。
ですが10年以上前からクーロン派が多かったです。
なので私も昔はクーロンと読んでいましたが、読み方なんて通じればどうでも良いので今はクロンと言うように変わりましたね。

yumの読み方

個人的に読み方なんてものは、通じればどうでも良いです。

CentOS4?5?くらいでyumコマンドが登場した時に、ググって読み方を調べるとヤムしかなかったのでヤムで統一されている物だと思っていました。
yumコマンド登場後から数年間、もう5年以上は余裕で経ってますよね?出会う人は皆ヤムで統一されていたのですが、今回ユムと読む人に初めて遭遇したのです。
で、興味をもって調べるとヤム?ユム?という質問もあるくらいユムと読む人間が増えていたみたいですね。

2002-7年くらい?のアバウトすぎる範囲でaptに対抗してyumコマンドが出てきたと記憶してますけど、当時はyum 読み方でググって出てくるのはヤムだけでした。
なのでヤム派の方が多いとは思います。

ゲーム業界はオワコン

そろそろゲーム業界から卒業すべき時がきたでしょうか?

私が携わっていたのは、AppStoreセールスランキングで上位の有名アプリでしたので、負荷は半端ないものでした。
ところが今携わっている案件で納品されてきたプログラムは質が低すぎて、これで実績のあるゲーム会社が作ったの?と目を疑うレベルです。
モバゲーアプリの開発実績もある会社なので、このレベルの低さは理解できなかったのですが、どうやらモバゲーは想像以上にオワコンらしいです。

私がモバゲーアプリを開発したのは、モバゲーAPIがサードパーティに提供された時の初期参入アプリです。
API公開時に参入した数社だけが当時の地獄を経験したのでしょうかね?
分間50万アクセスとか当たり前のようにくるのが、ソーシャルゲームという戦場だったんですがねぇ?
どうも話を聞いていると、今はモバゲーもゴミみたいな作り方で、まったく問題なく動くようです。
memcached使いました!ドヤァみたいな程度で動くみたいです。
なので、質の低いサーバーサイドエンジニアが量産されてしまっているのはあるんだと思います。

スマホアプリもセールスランキングトップのアプリ以外は全然負荷も高くないみたいです。
どの程度の順位までが負荷が高いのかは分かりませんが、少なくとも100位以内に入ってないようなのはゴミみたいなプログラムで動くみたいです。
ゴミで良いのなら、ゲーム業界なんていても良い事ありませんよねぇ。

トランザクションを理解する

さて、昨日書いた補足説明をしたいと思います。

まずレイドボスの場合は、倒したかどうか?という判断が必要になります。
読んでいる数値が保証されていなければどうなるか?
通常は討伐報酬が発生しますが、報酬の2重付与が発生してしまいます。
悲しい事に、ここまで書かないと何が悪いの?と理解できない人間が多いのがゲーム業界のサーバーエンジニアです。

ですから、プランナーがサーバーエンジニアをただのweb屋レベルのペチパーと勘違いするのも仕方ないと思います。
本当は数が少ないだけで、最も知識が必要で高いレベルが要求されるのがサーバーエンジニアです。
アプリ側は人間が余っていますが、マトモなサーバーエンジニア・インフラエンジニアは数が少ないのでどこの会社も人材を求めている所でしょう。

で、次に減らしてから増やすという話も説明しないと理解できない人が大勢いるでしょう。
そもそもA処理が終わってB処理が終わらない。
このシチュエーションが起こるケースは
1.トランザクションを利用していない。
2.B処理が別の保存先(例えばキャッシュ)
という事が考えられます。

もう1つ考えられる最もアホな発想についてまずは潰しておきます。
3.トランザクション中にコミットして片方が切り捨てられるという発想です。
はい、WALとか知らないんだったら勉強しましょうね。
insert文やupdate文を実行した時にそのデータはどこにいくとお考えですか?
メモリ上を更新するだけです。
そしてコミット処理を受け付けた時にmysqlが何をしているか知っていますか?
REDO(トランザクション)ログをシーケンシャルに書き出してメモリ上のデータが仮で無くなるだけです。
(設定されていればbinlogも)
binlogがredoログだと思っている人が多いですが、binlogはbinlogです。
多分レプリケーションの関係で後から付けた仕組みなんじゃないですか?>binlog
ib_logfile0とib_logfile1というのがmysqlのトランザクションログです。
チェックポイントに到達するとログファイルを切り替えて、実際にディスクに書き込むのでそれまではオンメモリなんですよ。
ですのでmysqlのリカバリのメカニズムは、ディスクに書き込まれていないデータはトランザクションログから復旧を試みます。
コミットに途中で?失敗する=トランザクションログの書き込みに途中で失敗する=mysqlサーバーのディスク逝ってるレベル。
2行目のクエリ書き込みタイミングでディスク逝く確率はゼロじゃないけど、このパターンの障害はファイルも救い出せないレベルじゃねーの?って事。
仕組みを知らずにケース3を想像してた人は、せいぜい意地になって超低確率のレアケースを想定してなさいってこった。

次にケース1
トランザクションを利用していない。>アホか、氏ね。

次にケース2
片方だけ更新しちゃう>アホか、氏ね
キャッシュだったとしても、ロールバック出来る形で実装していないのは設計が間違ってるだけ
キャッシュだったとしたら、キャッシュを消せば次回はDBから読み込んでキャッシュ化する作りになってなかったらアホ
ロールバックするの仕組みを実装するのが面倒だったら、DBへのコミット失敗したらキャッシュ消せ
つまり減らして増やすじゃなくて、DBコミット→キャッシュコミットという順番なら正しい
キャッシュコミットに失敗する=キャッシュサーバーがフェイルオーバーするから、DBから読み直して動くので全く問題なし
問題があるなら設計に問題がある、消えて困るデータをキャッシュするな

唯一筋が通りそうなのは、キャッシュじゃなくて
ケース4.垂直分割とかDBが分かれているケース
XA-TRANSACTION使えアホと言いたい所だが、Transactionマネージャーを自作するのが面倒くさいので自力Commitループしてるパターン。
このパターンだったら片方だけコミットされるというのはあり得るから、最終的にはエラーログからデータは戻すんだけど
それまでの間の問題にならないように減らす→増やすの順番でコミットせーよ!ってのは有りかもしれませんね。