2013/12/29(日)白金賢者二段のQMA不具合考察日記

2013/12/29 22:30

今日から帰省する予定だったのですが、膝が痛くて駅まで歩ける気がしなかったので延期しました。近所ではないにせよ、普通列車で帰れる範囲の帰省なので予定変更も簡単ですw

さて、予定がなくなってしまったため、Kindle化されていた@ITのエンジニアライフで連載されていたリーベルGさんの作品を一気に読み返していました。

ITエンジニア小説 人形つかい・ビギニング

ITエンジニア小説 人形つかい・ビギニング

@ITでの連載時に一度読んでいるのですが、やはり面白い。最後の最後に日付計算ライブラリの初歩的な計算ミスなどでピンチに陥りますが、それを冷静に捌いていく東海林さんカッコいい。

さて、日付計算の初歩的なミスといえば、今日こんなことがあったようです。

年末年始にまでネタを仕込むとはコナミさんさすがです。このツイートを見たときには「イベントの発生日を2013年1月1日の前後3日間にしてたんじゃねーのwww」と思ったのですが、続報を見た感じではそんな単純な問題ではなかったようですね。

これは本格的に日付処理を間違えている疑惑が……。

パッと思いつくのは年跨ぎの処理が上手くいっていない可能性です。わざわざ自前でバグ入りの日付計算ライブラリを作ってしまい、2014年1月1日の3日前を2014年の12月29日としてしまったり、そもそも存在しない0月にしてしまったり。ただ、これはあまりにも初歩的すぎるミスですし、わかってしまえば数時間で修正できそうなものです。

じゃあほかにどんな理由が考えられるかというと……。

年ごとにイベントテーブルが別に分かれていて、それを跨ぐことができないというのはどうでしょう。データを保持しているのがDBなのか設定ファイル的なものなのかはわかりませんが、event2013(仮)とevent2014(仮)という別のテーブル(ファイル、設定値……)として管理しているため、同一のイベントを年跨ぎで登録できない、ということです。

これならば公式の「解決に時間が掛かる」というツイートにも矛盾しませんし、1月1日からイベントを開始するという解決策とも整合性が取れています。これだ! これしかない!

……と思ったのですが、冷静に考えれば、12月28日~12月31日と1月1日~1月4日を「見た目は同じで獲得アイテムは一緒だけど別のイベント」として登録すれば解決する問題でした。これも解決まで数時間のオーダーでしょう。ということは、これよりもっと酷い不具合ってことですよね。

すごいな、コナミ。どうやったんだ?

OK キャンセル 確認 その他