[B! バグ] higedのブックマーク

オーバーフローが引き起こした面白いバグの話｜Rui Ueyama

一度聞いたら忘れられないような印象深いバグというものがある。僕は数値のオーバーフローと聞くと必ずこの2つのバグを思い出してしまう。どちらも面白いエピソードなのでちょっと紹介してみよう。一つ目は、初代Civilizationにあったバグである。Civilizationは文明間で戦う戦略シミュレーションゲームで、チンギスハンとかエリザベス女王みたいなプレイヤーを選んで、世界制覇か宇宙開発競争での勝利を目指すというゲームだ。初代Civilizationにあったバグは、非暴力主義のガンジーが突然核攻撃してくるというものだった。原因は文明が民主主義を採用すると攻撃性が2下がるというロジックだった。初代Civではガンジーの攻撃性は全プレイヤー中で最小の1なのだが、ゲームが進んでインド文明が民主主義を採用すると、攻撃性がマイナス2されてオーバーフローで255になり、ガンジーがゲーム中で突如、極度に攻

higed 2017/11/17

バグ

リンク

「ゼルダの伝説 BotW」にバグが少ない理由

素晴らしいオープンワールドゲームならいくらでもある。「The Elder Scrolls V: Skyrim」、「ウィッチャー3 ワイルドハント」、「グランド・セフト・オートV」、「Fallout 4」など、巧妙に作り込まれた膨大なスケールのゲームは特に海外のタイトルが多いように思う。それらと比べても遜色のない国産タイトル「ゼルダの伝説ブレスオブザワイルド」（以下、BotW）だが、他のオープンワールドゲームより優れている点があるとすれば、バグの少なさなのではないだろうか。僕はハイラルの世界を150時間以上冒険しているが、バグらしいバグに遭遇したのは片手で数えられる程度の回数しかないのだ。では、なぜBotWはこんなにもバグが少ないのか。「何年も入念に開発してきたからだ」とか「細かいところを丁寧に作り込む日本人の職人魂が備わっているから」とか、そんな理由でも片付けられそうな気がするが

higed 2017/09/03

リンク

【悲報】客先常駐システム開発で今もステップ数によるバグ検出数基準が使用されていることが判明 | 株式会社アクシア

お盆休みに入る前にTwitterに以下のツイートを投稿しました。ステップ数で評価しようとするどこかのシステム開発会社みたいだなｗ https://t.co/67ujbhVoUn — 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) August 10, 2017 あるんですよ。一番困ったのはステップ数に応じて「検出されるはずのバグ数」という指標もあって、その数の分だけバグが検出されないと試験が正しく実施されていないと判断されてしまうことがありました。プラグインで自動生成されるコードにまでその指標を押し付けられ…バグなんて出るはずもなく…。 https://t.co/oM4zT3oolb — 米村歩@日本一残業の少ないIT企業社長 (@yonemura2006) August 10, 2017 私自身が客先常駐の現場でシステム開発に携わったのはフリーランスの頃なのでも

higed 2017/08/17

リンク

バグのないプログラムを作るための技術 - eomole blog 4 くらい

2015/12/10 追記: バグを本気で無くしたい方はこんな良く辺鄙なブログなんて見ずにソフトウェアエンジニアリング系の国際学会に行くなり、そこの論文を読むなりするといいと思います。ICSEなんかは日本語の勉強会資料もあってとっつきやすいでしょう。バグのないプログラムを作る方法について色々聞きかじったことを, 脈絡なく訳の分からない説明でつらつらと書きならべます. テスト割と古典的な方法ですね. プログラミングコンテストでもお馴染みの方式です. Java だと JUnit (4) みたいなのを使います. 手作りケースとりあえず試してみるケースコーナーケースミスの発生しやすそうなところを突くためのケースランダムケースランダムに爆撃するためのケースみたいなものを作って, 仕様とマッチするか確認します. 当たり前ですが, 基本的には下手な鉄砲も数撃ちゃ当たる方式なので, 運が悪

higed 2017/02/08

リンク

Gitのコミットメッセージの書き方 - Qiita

Gitのコミットメッセージの書き方自分なりにまとめてみました。Git歴浅いので、意見募集中です。（2014年12月17日追記）想像以上にたくさんの方にストックなりはてブなりいただいたので、はてブでなるほど！と思ったコメントをもとに少し修正・加筆してみました。（2022年1月4日追記）最新の書き方をこちらに書きました。 https://zenn.dev/itosho/articles/git-commit-message-2023 原則以下のフォーマットとします。 1行目：変更内容の要約（タイトル、概要） 2行目：空行 3行目以降：変更した理由（内容、詳細）日本語でも英語でもOKですが、リポジトリで統一してください。 1行目コミット種別と要約を書きます。フォーマットは以下とします。 [コミット種別]要約コミット種別以下の中から適切な種別を選びます。（多すぎても悩むので