이번 주는 이력서와 코테준비로 전체적으로 프로젝트에 많이 소홀했다. 밀린 일기 쓰듯 작성할 수도 있지만 반성하는 의미에서 그냥 적는다. 바쁘다는것도 사실 핑계라 생각이 들었기때문이다.
우선순위가 있는건 당연하지만 우선순위가 생긴다고 안 하면 결국 안 하게 된다. 지금같은 상태나 더 바빠지는 상황이 올 수도 있는데, 그럼 평생 못하는거 아닐까?
계속 생각했던 후기 작성이나 포스팅도 마찬가지다. TODO도 의미가 별로 없는 것 같아 따로 정리하기로 했다.
이력서 쓰며 TIL 도움을 많이 받았다. 당시에 어떤 의도로 만들었는지, 어떤 고민을 했는지 기록해둔것들이 중요하다는 것을 새삼 느꼈다. 1월에 TIL을 처음 쓰기로 했던 때를 다시 떠올려보자.
이번 주에 구현한 부분은 거의 없었다. 쿼리 조금 짜고 테스트 만든 정도? 고민이 됐던 부분은 인수테스트에서 JSON이 아닌 객체로 검증하다보니 정확한 JSON 폼인지 검증이 되지 않는다. 결국 직접 확인해야 하는 부분이 돼버렸다.
방법은 JSON으로 테스트 케이스를 관리하거나, 컨트롤러 테스트를 새로 만드는 것. 뭐가 좋을지는 모르겠다. 일단 지금 하는 단위에서 작성해서 팀원들에게 예시를 보여주며 얘기해봐야겠다. 팀원들이 지금보다 구현에 더 부담을 느낀다면 좋지 않을 것 같다.
날짜에 관한 고민도 계속됐다. 지난 주 부터 날짜 관련 알고리즘 문제를 계속 풀어서 그런 것 같기도 하다. 현재 결론은 UTC 시간으로 저장하고 클라이언트의 로케일에 따라 보내주는 것이다. 또 한가지, epoch 타임은 2038 이슈가 있다고 한다. 지금은 문제 없지만 문제가 있다는걸 인지했다면 피해가는게 좋지 않을까. 그렇지 않다면 결국, 내가 싫어했던 새로운 개발에서 레거시를 만드는 행위일 것이다.
김영한님 인프런 강의 답변중 지금까지 개발한 애플리케이션들은 국제화를 고려하지 않았고 그렇다면 한국표준시를 쓰지 않았을때 곤란한 부분이 꽤 생긴다고 하는게 보였다. 실제 운영이 아니니 이 참에 체험해보는 것도 좋을 것 같다. 벌써 어렵긴 하지만 초기에 고민하다 만 예외메세지같은 부분도 함께 생각해볼 수 있을 것 같다.
새리가 작성한 코드가 깃헙액션에 달아둔 테스트 환경에서 제대로 돌지 않는 모습을 보였다. 그레이들 빌드를 하니 로컬도 같은 오류가 발생했는데, 잘 되던게 안되는 걸 보니 원인이 더티컨텍스트(dirty context)를 달아둔데에 있을 것 같다. 정확한 원인은 모르겠다. 더티컨텍스트의 작동방식을 따로 봐야할 확실한 원인을 찾을 수 있을 것 같다. 일단은 setup시 db 초기화를 해주는 것으로 해결된다. 그리고 db초기화 모듈도 만들어야할 것 같다.
지난 주 부터 빼먹은 부분이 많이 생겼다. 바쁘기도 해서 통으로 쉴까 생각도 했지만, 이 프로젝트는 웬만하면 타협 안 했으면 하는 마음으로 수목금은 조금씩이라도 계속 진행했다. 이번 주의 이슈는 Content-Length였다. 일차적으로 찾아봤던 이유는 대소문자를 가려야 하는지와 같은 단순한 이유에서 시작됐다.
rfc 문서를 보니 Content-Length는 Transfer Encoding이 헤더에 있으면 포함시키지 않아야 한다고 한다. 머리에는 느낌표가..ㅎㅎ. 그리고 지난 번 GET Message의 Body에 관해서도, 의미가 없는 바디는 Content-Length를 제공하면 안 된다고 한다. Content-Length가 없으면 어떻게 알아내야할까? 하는 의문은 Message Body 파트에 정리되어 있었다. 아직 읽어본게 아니라 정답이 있을지는 모르겠지만 힌트는 들어있을것같다. 스펙문서를 꼼꼼히 읽으니 해소되는 의문점들이 많았다. 예전에는 이런식의 접근은 아예 하지 못했는데, 프로젝트하며 이런부분이 많이 발전한 것 같다. 항상 명확한 근거가 있어야 하고, 대부분 공식 문서에 친절하게(그렇게 느껴지지 않지만) 작성되어 있다. 나는 그냥 받아들이던 부분을 노을이 물어봐줘서 얻어가는 것도 많다.
추가로 HEAD 메소드와 INFO 메소드 그리고 304같은 상태는 GET 메소드의 body 부분에 대한 길이를 제공해야 한다고 한다. 이걸 읽다 101 상태의 쓰임과 웹소켓을 살펴보게 됐다. 어렴풋이 알았는데 겉할기는 어느정도 된 것 같다.
얘기를 하던 중 노을이 소켓과 HTTP에 대해 예전에 내가 했던 것과 비슷한 의문점이 든 것을 확인하고 이 것을 짚고 넘어가기 위해 여러가지를 살펴봤다. 페어프로그래밍의 묘미는 계속 대화하면서 빈칸을 꼼꼼히 채워가는 것이라는 생각이 들었다. 재밌다.
주말에 코테가 몰려있어 카카오 기출 위주로 봤다. 겹쳐진 블럭을 비교하며 나가는 문제가 있었는데, 예전에 코테에서 접근도 아예 못했던 문제와 유사하게 보였다. 큰 판을 하나 만들고 거기를 채우면서 비교해가는 것이다. 그 동안 생각 못 했던 새로운 접근이었는데 좋은 것 같다.
추석트래픽같이 조회범위가 엄청 큰게 아니면 누적합을 이용할 수 있다고 한다. DP의 완전탐색 버전? 말이 이상한데 그런 식으로 이해됐다. 비슷한 유형을 좀 더 봐야 할 것 같다. 카카오 코테에서도 효율성을 맞추지 못한 부분에 2차원 누적합을 사용하면 된다고 하는데, 꼭 풀어보자. 비트마스킹도 많이 미뤄뒀는데, 어떤건지 어렴풋이 알지만 정확히 알지 못해 구현에 사용하지 못하고 있다. 이 것도 다음주에 꼭 살펴보자.
Powered with by Gatsby 2.0