주말에 시험을 치고 컨디션이 계속 좋지않아 어제까지 쉬었다. cs시험은 낚시 문제에서 다 낚인 느낌이라 결과가 좋지 않을 것 같다. 그래도 작년에 비하면 찍어서 맞춘다기보다 실수해서 틀린다는 느낌이 많아졌다. 앞으로도 꾸준히 해보자.
지난주에 했던 것 처럼 Test 태스크를 만들고 거기에서 필요한 작업들을 하도록 했다. 기본 태스크는 최대한 건드리지 않기 위해서다.
처음에는 변수로 받아온 뒤 수정하는 식으로 했는데, 생명주기가 맞지 않는지 모든 인스턴스가 수정이 되는 현상이 발생했다. 복사한뒤에 해야 하는건지...
디펜던시가 있었던 부분은 최대한 mustRunAfter로 순서 보장만 시켜주고 꼭 필요한 부분에서만 dependsOn을 사용하도록 바꿨다. 마찬가지로 기본 태스크에 영향을 주기 싫었다.
그레이들의 생명주기때문에 많이 헤멘 것 같은데 따로 공부를 해봐야 하는 시점이 다가오는 것 같다.
그간 묵혀뒀던 숙변같은 이슈들을 처리했다. 그래도 아직 많이 남았지만 천천히 하나씩 처리해가보자
지난주에 했던 벨리데이션도 잘 작동해서 내심 뿌듯했다. 글로 정리좀 해보자
오늘은 Trie 문제를 풀어봤다. 트리맵을 보다가 이걸로 쉽게 구현할 수 있지 않을까? 하는 생각으로 풀었는데, 타고 타고 내려가는 식으로 노드가 연결되야 해서 의미가 없다. 그래서 일반적인 접근을 해봤는데, 이번에는 종료 플래그를 넣지 않고 빈 문자열을 넣는식으로 종료를 표현해봤다. 좀 더 좋은 것 같기도 하고. 구현은 편했다.
어쩌다 volatile키워드를 보게 됐다. 가지고 있는 기본서에 volatile 설명이 있었는지 기억이 나지 않아 찾아보다 스트림의 병렬처리를 봤다. 내부적으로 포크 조인 프레임워크라는 것을 쓴다고 한다. 병렬처리에 쓰이는 커먼한 용어인듯 하다. 따로 찾아봐야겠다. 아무튼 포크-조인의 말만 보면 자식 프로세스 같은걸 생성할 것 같은 느낌이다. 자바는 프로세스가 하나니 스레드를 만들 것이다. 어찌됐건 이런 이유로 쪼개는데 오버해드가 발생한다. 쪼개는 만큼 스레드가 만들어져야 하니까.
비슷한 내용을 스트림과 이터레이터의 차이에서도 본 적 있었는데, 결론은 단순 작업이면 클래식하게 작성하는게 좋고 복잡해질수록 스트림이나 병렬스트림을 사용하는게 빛을 발한다. 다만 이는 ArrayList일 경우이고 다른 컬렉션은 그렇지 않은데, 이유는 쪼개는게 애매하고 접근하기 힘들기 때문이다. 절반을 가를때마다 그만큼 이동해야 하니 추가 오버헤드가 발생한다. 해쉬나 트리를 사용하는 컬렉션도 마찬가지다.
오늘은 특이하게 다대다 면접이었다. 생각보다 분위기가 무겁지는 않았다.
로드밸런서 L4는 IP + 포트까지 확인할 수 있다. 다시 보자.
다른 지원자에게 갔던 질문 중 DB에서 대용량 감당하기 위한 방법에 대한 것이 있었다. 나는 메모리 DB로 캐싱하는 것을 생각했는데, 디아블로 사례가 떠올라서 복잡한 상황에 대해서도 생각해봐야할 것 같다. 프런트에서도 어떻게 처리하는지 나중에 물어봐야겠다.
스프링 싱글톤은 인스턴스를 하나만 써서 비용을 줄이는 역할을 하는 듯 하다. 객체지향, 클린코드 빨리 마무리하고 토비의 스프링 읽어보자.
정규화도 다시 공부하자. BCNF까지는 알아야하니까
Powered with by Gatsby 2.0