たとえば天下りマネージャーがやってきて、今度のプロジェクトでバグを撲滅すると言い出す。 そのため、バグを出したプログラマやベンダーはペナルティを課すと宣言する。そして、バグ管理簿を毎週チェックし始める。 すると、期待通りバグは出てこなくなる。代わりに「インシデント管理簿」が作成され、そこで不具合の解析や改修調整をするようになる。「バグ管理簿」に記載されるのは、ドキュメントの誤字脱字など無害なものになる。天下りの馬鹿マネージャーに出て行ってもらうまで。 天下りマネージャーが馬鹿なのは、なぜバグを管理するかを理解していないからだ。 なぜバグを管理するかというと、テストが想定通り進んでいて、品質を担保されているか測るためだ。沢山テストされてるならバグは出やすいし、熟知しているプログラマならバグは出にくい（反対に、テスト項目は消化しているのに、バグが出ないと、テストの品質を疑ってみる）。バグの出具

この記事の目的 自分は、とある会社様の元でソシャゲの API 開発をさせていただいています。 ソシャゲは、リリース時やイベント時などに集中アクセスされやすく、負荷軽減の知識がない状態で開発を行ってしまうと、運用時に緊急メンテ祭りになりやすいジャンルかなと思っています。 これまで培ってきた MySQL の知識ですが、脳内メモリ量の関係上、暗記できないのでメモしておこうというのが主目的です。 ここ数年ほどソシャゲ開発しかしていないため、偏っている感がある内容ですのでご注意ください。 概要 ストレージエンジンは InnoDB。メインで扱っている MySQL バージョンは 5.6。 記事の内容ですが、これらのキーワードを見て、おおよそ分かる方は読む必要はないかと思います。 インデックス系 クラスタインデックス カバリングインデックス EXPLAIN で注意するべき値 トランザクション系 MVCC

Point ■レトロゲームには容量不足や技術的制約を解決するため、現代の我々から見ても解析できない謎の技術が使われていることがある ■今回、ATARI2600から82年に発売されたゲーム『Entombed』に、全くロジックが不明の迷路自動生成プログラムのコードが発見された ■迷路の壁を完全ランダムに配置すればクリア不能になってしまうが、このプログラムがなぜ通行可能なパターンで迷路を生成しているかは、まったくの謎だという ほんの数十年前、コンピュータ関連の技術が飛躍的に向上しました。 特にデータ容量の向上はめざましく、現代の若い人たちにとって容量の単位は「ギガ」が標準になっています。 しかし初代のスーパーマリオの全ゲーム容量は40KB、初代ドラゴンクエストの全容量は64KBでした。 これはこの記事のトップに貼られている画像の容量よりも遥かに小さい容量です。 レトロゲームの開発は、そんな小さな