nhn시험대비로 한 바퀴 돌리려고 한다.
네이글(Nagle) 알고리즘 : TCP/IP 패킷 너무 작으면 핸드쉐이킹 많이 해야돼서 버퍼에 넣은다음 한꺼번에 처리해야한다고 한다.
페이징과 세그먼테이션 : 세그먼테이션은 x86에서 사용되다 현재는 레거시로 남아있다고 한다. 리눅스는 원래부터 페이징을 사용했고 세그먼테이션은 제한적으로 허용했다고 한다.
정수표현 : 예전에 공부했던 부분을 다시 봤다. 기억이 잘 안 난다... ㅋㅋ 전부터 느낀 것이지만 주기적으로 정주행을 해줘야겠다.
부동소수점 : 예전에는 이해가 잘 안가 그냥 넘어갔는데 이참에 다시 봤다. 최소~최대 값의 중간값만큼 더해주는 bias 상수가 필요하다. 이 부분이 너무 이해가 안 되서 오래걸렸다. 저렇게 자세하게 써놓은 곳이 없었다.
isXXX라는 변수명일때, boolean은 isXXX, Boolean은 getIsXXX와 같이 getter메소드를 생성해준다. 리플렉션에 대응하기 위해 일관성을 조금 버린 것인지... 이유를 잘 모르겠다. 리플렉션이 필요 없는 경우는 isXXX로 메소드를 만들어주는게 일관성있긴하다. 그래서 그런건지 canXXX와 같이 다른 접두사를 붙였을때 prefix를 없애주는 어노테이션도 있다고 한다.
https://www.inflearn.com/questions/15876
부모를 기준으로 필터링을 해야하는 단계가 됐다. fetch join 대상을 조건으로 사용하면 안 된다고 막연하게 알고 있었는데 나의 경우는 상관없다. 문제가 되는 부분은 컬렉션 조회에서 조건을 거는 상황이다.
해당 경우 컬렉션이 모두 조회되지 않는다. 만약 이대로 저장하면 기존 데이터는 다 날아갈 것이다.
네트워크 찾아보다가 하위 계층으로 가면서 캡슐화시키는 부분 보고 생각해봤다. 맞는지 좀 더 생각해보자.
캡슐화 -> 택배상자
택배기사 -택배 배송하려면 송장 필요. -내부에 뭐가 들었는지 알 필요 없음 -박스만 전달하면 됨.
수신자 -송장보고 내 택배가 맞는지 확인하고 나면 박스(캡슐) 필요 없음 -택배 박스까서 확인
컴퓨터 구조를 이어서 봤다. 폰 노이만 구조만 쓰고 있는 줄 알았는데 알고보니 내부에 하버드구조를 함께 사용하고 있었다. 데이터 캐시와 명령어 캐시.
레지스터 종류는 다 까먹을 것 같다. 대충 짐작할 수 있게 키워드만 생각해봐야겠다.
어제 패리티 비트를 그냥 넘어갔는데 내일 다시 봐야겠다.
기능 명세에 대해 생각해봤다. 많이 흩어져있어 한군데로 모아놓아야 좋을 것 같다는 생각이다. 내일 얘기해봐야겠다.
패티리비트와 해밍코드를 살펴봤다. 패티리비트를 여러개 합친게 해밍코드 같은 느낌이다. 생각보다 진도가 안나가는데 할 수 있는만큼만 해야겠다.
헤로쿠 배포가 잘 안 된다. 의심되는 상황은 REST Docs때문에 서버에서도 테스트가 돌아가는 것이다. 따라서 테스트에 프로필을 넣어줘야 한다.
이외에도 문제점들이 있는데, 우선 디버깅이 안 된다는 점. 그리고 미리 스크립트를 실행시켜야 한다는 점이다.
스크립트 실행은 그냥 포기하고 서버에서 환경변수를 관리하는 방향으로 우회해볼 수 있지만 디버깅은 답이 안 보인다.
내일 빌드팩을 좀 더 살펴봐야겠다.
오늘은 인터럽트와 파이프라인에 대해 학습했다. 원시적인 방식은 폴링처럼 입출력을 감지하는데, 감지비용이 비싸다. 그래서 인터럽트로 입출력을 감지한다. 인터럽트에 진입하면 돌아갈 주소를 저장하고 인터럽트 시작점으로 PC를 옮겨준다. 처리후 저장해뒀던 돌아갈 지점으로 PC를 옮긴다.
파이프라인은 병렬처리 방법의 일종인데, 프로세스를 나눠서 세그먼트라는 일종의 서브프로세스를 만든다. 각 세그먼트는 작업을 한 뒤 할당된 레지스터에 값을 저장하고 다음 세그먼트에 넘겨준다. 이러면 공장에서 라인 조립하는 것 처럼 연산을 수행할 수 있다.
내일은 벼락치기 느낌으로 전체적으로 훑는 식으로 가야겠다. 번외로 1주일간 공부해보니 꾸준히 공부하기에 진도가 나쁘지 않은 느낌이다. 하루 두~세 시간 정도 투자해서 OS, 컴퓨터 구조, 네트워크를 2주 사이클로 계속 돌려봐도 괜찮을 것 같다. 복습하는거라 효율이 생각보다 괜찮은 느낌이다.
어제 안 되던 배포문제를 해결했다. 많은 시행착오가 있었다.
우선 어제 생각했던대로 서버에 환경변수를 설정해줬다. 하지만 제대로 동작하지 않았는데, 일단 디버깅은 포기하고 그레이들 태스크에 로깅을 넣어줬다. 환경변수가 설정됐음에도 제대로 동작하지 않았는데, 이유는 프로필 설정이 제대로 되지 않아서다.
asciidoctor 실행에 test를 디펜던시로 연결시켜놨는데, 그러면 프로퍼티를 설정한 컨텍스트를 벗어난 것 처럼 테스트가 실행 된다. 컨텍스트를 벗어난건지 순서때문에 그런건지는 내일 다시 살펴보면 좋을 것 같다.
아무튼 이 부분이 제대로 이해가 되지 않아 예전에도 삽질을 많이 했던 것 같다.
대충 도식화해보면 내가 생각했던 흐름은
프로퍼티 설정 -> 테스트 실행 -> asciidoctor -> jar만들기 인데, jar만들기 asciidoctor 테스트 생략 과 같이 진행됐다.
같은 이유로 bootjar는 static 파일이 제대로 카피되지 않은 채 만들어졌다. 따라서 태스크마다 mustRunAfter를 이용해 순서를 지정해줬다. 그리고 asciidoctor에는 test 디펜던시를 빼주고 별도로 호출하도록 바꿔줬다.
아무튼 해결돼서 서버에 올라갔는데, 원인은 파악했으니 메인에 머지시킬 코드는 좀 더 생각해보고 따져가며 작성해봐야겠다.
그리고 헤로쿠 배포 과정을 예전에 포스팅해놨으면 연재하는 느낌으로 쓸 수 있었을 것 같은데, 아쉽다. 지금이라도 처음부터 써나가야겠다.
리퀘스트리졸버도 마찬가지인데 좀 아쉽다. 귀찮아도 좀만 더 부지런하게 움직여보자
지금 테스트가 잘 되고 있나? 싶어서 테스트 커버리지를 봤는데 생각보다 낮은 수치였다. 적어도 80퍼센트는 되지 않을까 했는데, 60퍼센트였다. DTO와 Q클래스가 큰 몫을 하고 있었는데, 좀 더 정확한 검증을 위한 필터가 없을까 하고 찾아봤다.
정적 코드 분석 도구를 이용하면 이런 부분의 답을 찾을 수 있을 것 같다. 소나큐브를 이용하면 이외에도 성능적 결함이나 코드스멜같은 부분도 잡아준다고 한다. 단점은 서버를 구성해야 협업하기 좋다는 점이다. 헤로쿠에 도커를 올리면 과금 걱정 없이 쓸 수 있을 것 같은데, 고민을 해봐야겠다.
최근에 나의 강점에 대한 고민이 많았다. 분명 개발이 재밌고 좋은데 그래서 뭐가 그렇게 좋고 또 뭘 잘하냐고 물어보면 선뜻 대답을 못하겠다. 이전에 봤던 면접에서는 내가 주장했던 나의 강점을 개발외의 상황에서도 해본적이 있냐는 질문을 받았는데 주제에서 조금 벗어나는 느낌이었다.
같이 개발했던 사람들에게 물어보면 피드백을 좀 받아보면 말을 잘 들어주고, 깊이 파고들고, 라이브러리 직접 까보거나 세세한 부분도 신경쓰고 그런 장점이 있다고 하는데 사실 내 스스로 저런 부분들에 대한 자신이 많이 없었다. 말 들어주는건 협업 하려면 당연한거고, 깊이 파고드는건 진짜 변태같이 파고드는 사람들에 비하면 평범한 수준이라 생각한다. 다른 부분도 마찬가지다.
얼마전 친구들이 위로겸 위드코로나로 조금 자유로워진 것을 겸사겸사해서 술을 사줬다. 양꼬치를 먹으며 떨어지려하는 양꼬치를 다시 집어서 끼웠는데, 친구들이 참 너답다는 소리를 했다. ㅋㅋ 잘 생각해보면 이런 점이 나의 강점이 아닌가 싶다. 작은 문제라도 더 좋은 방법을 찾고 해결해보려하는 것. 이 것도 개발자라면 당연히 가져야 하는 덕목이지만, 내가 가장 잘 할 수 있는 부분이고 좋아하는 것이다. 물론 같이 술먹었던 친구도 너는 깊이 파고드는게 강점이라고 얘기를 해줬지만 당당하게 어필하기에는 조금 부족한 느낌이다.
어찌됐건 이렇게 생각해보니 내가 왜 그렇게 테스트에 집착하는지도 자연스레 연결이 됐다. 테스트를 해야 좋은 방법을 적용하기 쉬우니까. 안정성을 추구하는 성향 탓도 있겠지만, 테스트에 매력을 느낀 이유는 리팩토링을 자유롭게 할 수 있다는 점이 가장 컸던 것 같다. 진짜 꼼꼼하고 안전하게 작성하려면 테스트코드는 지금 작성하는 것의 배 이상으로 작성을 했어야 했을거다. 될 때까지 물어뜯는 것도 더 좋은 방법으로 하고 싶으니 고집을 부리고 있었던게 아닐까 싶다. 이 부분도 나의 강점인 것 같다. 깊이 파고드는 것 보다는 될 때까지 하는 것.
아무튼 나름의 생각정리가 되니 마음이 한 결 가볍다. 요즘 워낙 답답해서 자기이해 과정같은거도 신청해보고 했었는데 갈지말지 고민된다. 일정보고 결정해야겠다.
Powered with by Gatsby 2.0