Golang 테스트 편하게 하기
언제나처럼 테스트 좀 편하게 실행할 방법이 없나 찾다가 gotestsum 이라는 괜찮은 프로젝트를 발견했다. 내가 원하는 것들을 상당 수 갖추고 있더라. CLI 환경 기반1 테스트 성공/실패를 쉽게 알아 볼 수 있을 것2 Watch 기능- 구현 코드나 테스트를 변경하면 테스트 실행. 가능하다면 바꾼 부분에 영향 받는 것만. 두번째 항목이 조금 부족하긴한데, gotestsum/contrib 에 있는 기능과 macOS terminal-notifier를 같이 쓰면 쓸만하다. VSCode에서 코드를 수정하고 저장하면 watch 모드로 돌고 있던 테스트들을 실행하고, 성공/실패는 알림 메시지로 받는다.
새 MacBook 설정(2023)
회사 랩탑 이전한 기록을 정리. MacBook Pro 16″ (intel)을 쓰다가, 지난 달 부터 M2 Pro로 옮길 수 있다고 해서 옮김. 다만 기기에 미리 설치된 소프트웨어가 처리하는게 있어서 기기 간 동기화 기능 없이 이전했다. 이전 과정에서 기존 소프트웨어 설정, 명령어나 웹 방문 기록을 옮기려고 했고, 상당히 의도대로 된 것 같다. 특히 원했던 게 명령어나 웹 서비스 방문 기록들을 최대한 유지하는 것이었다. 이건 자주 쓰는 명령어면 script로 빼놓고 자주 방문하는 주소면 북마크로 남겨놓지만, 그렇지 않은건 history에만 남아있는거라 이 부분을 놓치지 않으려고 했다.
Blog 이전하기 (2023)
10년도 더 전에 static site generator를 쓰는 것으로 이전해보겠다했었는데, 정작 이제야 실행에 옮겼다. 모든 걸 다 옮긴 것은 아니고 아래처럼 옮겼다. 2011년 및 그 이후의 (거의 모든) 글들. 그 이전 글들은 draft상태로 저장만 해놨는데 언제 살릴진 모르겠다. 페이지로 작성한 글들. 아직 공개하지 않았고 차차 살릴 생각. 이전 permalink. /blog/archives/{numeric-post-id} 형식의 링크는 모두 유지. 이걸로 Google 검색은 가능한 범위 내에서 안깨보려고 노력했다. 댓글 포함한 일정 부분은 포기. DB 백업이 있으니 되살릴 순 있지만 당장은 계획이 없다.
2022년 돌아보기
2021년에는 창업하고 8년간 다녔던 회사를 떠나고, 아예 다른 업게인 스타트업 회사에 들어갔다. 새 회사에서 받은 느낌들을 여기 정리해보겠다. (입사 첫 해에 반 년 다닌 걸로는 내가 새로운 환경에 신나서 쓰는 것과 구분이 안될것 같아서 올해 몰아서 쓴다) 아래는 떠오르는대로 쭉 써본 내용. 게임 회사랑 게임 관련된 것을 만드는 회사를 다니다가 웹 서비스 만드는 회사로 가면서 걱정은 좀 했는데, 생각보다 바뀌는 것은 없더라. 프로세스나 VM이 죽었을 때 신경을 훨씬 덜 써도 되는 정도의 차이가 있고.
macOS에서 음원 파일 노동요 모드로 재생하기
집중하기 어려울 때 후크송(?)이나 전파계(?) 음원을 빠른 템포로 반복 재생하면 좀 나아서 그런 음원 검색해서 듣곤 했다. 그런데 오늘 macOS의 afplay 명령을 보다가 좋은 옵션을 발견했다. man 페이지엔 별거 없던데 -h 플래그론 쓸모 있는 옵션이 꽤 나오더라. > afplay -h Audio File Play Version: 2.0 Copyright 2003-2013, Apple Inc. All Rights Reserved. Specify -h (-help) for command options Usage: afplay [option...] audio_file Options: (may appear before or after arguments) {-v | --volume} VOLUME set the volume for playback of the file {-h | --help} print help { --leaks} run leaks analysis {-t | --time} TIME play for TIME seconds {-r | --rate} RATE play at playback rate {-q | --rQuality} QUALITY set the quality used for rate-scaled playback (default is 0 - low quality, 1 - high quality) {-d | --debug} debug print output -r 을 1보다 큰 값을 주면 그만큼 빨리 재생하고, -q 1 을 주면 품질 손실이 심각하진 않더라.
Vim에서 XML 포맷팅하기
적당히 큰 (100 MiB 초과 1 GiB 이하 정도) XML 파일을 종종 봐야할 일이 생겼다. 그런데 이게 포맷팅이 전혀 안되어있어서 — 사람 읽으라고 만든 파일이 아닌듯 — 불편하다. 이걸 vim으로 전부 블럭 잡고 = 로 포맷팅하니 느려서 쓰기 어려워서 다른 방법을 찾아봤다. CLI를 찾다가 xmllint 를 발견. 이걸 써서 vim buffer를 수정하니 속도도 빠르고 꽤 쓸만했다. 실제 명령어는 이렇게 줬다: :%!xmllint --format -
TIL: ffmpeg으로 비디오 채널 분리하기
며칠 전에 고속도로 정체로 서 있다가 뒷차가 추돌하는 일을 당했다. 보험금 청구(?)를 위해서 대시캠 영상을 달라고 해서 그 영상을 가져와보니, 3개 채널로 된 미디어 파일이더라. mediainfo 로 열어보면 아래와 같다. General Complete name : SomeFileName.avi Format : AVI Format/Info : Audio Video Interleave File size : 49.2 MiB Duration : 20 s 301 ms Overall bit rate : 20.3 Mb/s Video #1 ID : 0 Format : AVC Format/Info : Advanced Video Codec Format profile : High@L4.
블로그 설정 개편: ECDSA 인증서 체인
지난 달에 이어서 블로그 설정 개편 계속. 지난 5월엔 HTTP2 / TLS 1.3 / ECDSA 인증서 발급을 했다 이 시점에는 웹 서버가 사용하는 공개키는 ECDSA 키지만, 이걸 서명하는 중간 단계 인증서는 Let’s Encrypt의 RSA 인증서(R3)를 썼다. 이제 그걸 ECDSA 인증서로 교체하는 작업을 진행했다. 지난 달에 Let’s Encrypt production ECDSA allowlist 에 등록 신청을 했다. 시점은 대략 블로그 글을 작성했던 2021-05-14 즈음. 그리고 이거에 대한 완료 메일을 오늘 아침에 받아서 적용해 봤다.
구직 과정 기록(3): 선택의 시간
지금이 2010-2011년 사이의 모바일 관련 소프트웨어 서비스가 폭발하던 시기 이후로 다시 찾아온 소프트웨어 개발자의 구인난 시기 같다. 이런 이유에서, 끝까지 진행한 모든 회사에서 오퍼를 받을 수 있었다. 이것에 대해서 몇 가지를 고려해서 개별 선택지를 평가했다. 다만, 내가 평가한 방법은 내 취향의 문제 라고 이해해주면 좋겠다. 그러니 “읽는 분 본인의 선택의 시간”이 왔을 때 유사한 척도가 아닌 적절한 척도를 세워서 평가하시기 바란다. 내가 하고 싶은 일인지 / 같이 일하는 사람들에게 내가 배울 수 있는 게 많을지 연봉 및 기타 옵션(스톡옵션, 복지 혜택).
코딩 테스트에 대한 생각
며칠 간 구직 활동 관련한 글을 썼다. 그 중에서 “코딩 테스트”에 대한 부분은 쓰다보니 길어져서 이렇게 별도 글로 쓴다. 나는 코딩 테스트는 당연히 필요하다는 입장이다. 다만, 어떤 방식을 쓸지, 어떤 문제가 더 좋은 문제인지에 대해선 개선할 부분이 있다고 생각한다. 그 생각을 이번 구직 활동 기간 동안의 경험과 함께 써보려고 한다. 크게 세 종류의 코딩 테스트를 경험했다. 온라인 자동화 테스트 온라인 공유 문서를 통한 코딩 테스트 (컨퍼런스 콜 중에 공유 도구 사용)