Carry On Progamming Carry On Progamming

JpaRepository를 상속받은 인터페이스에서 default method를 활용할 수 있는데, 그 방법에 대한 포스팅이 많이 보이지 않아 정리해본다. JpaRepository를 상속받은 interface에서 아무렇지 않게 디폴트 메서드를 구현해서 서비스에서 호출을 하면 jpa에서 쿼리 생성을 못했다는 에러메시지가 나온다. jpa를 이미 사용하고 있는 사람이라면 query creation을 알고 있을 것이다. 바디가 없는 메서드에 한하여 메서드명을 바탕으로 쿼리를 생성해내는 jpa의 편리한 기능이다. 이 포스팅의 제목처럼 우리는 기본적인 조회처리나 조회 후 데이터 자체의 유무에 대한 exception 처리를 굳이 서비스 로직에서 처리하고 싶지 않다. interface인 repository에서 defau..

신입 때부터 관용어처럼 'null은 나쁘다'라는 말을 들어왔다. '왜 null은 나쁜가?'라는 궁금증을 가지고 있으면서도 막연히 객체, 값의 불안정함, null 처리를 위해 생기는 지저분한 코드들을 만들어내기에 나쁘다고 하는거겠지? 라며 근거없이 혼자 추측해서 짐작만 하고 있었다. 근원적인 질문에 대해 이해하고 정리해두고 싶어서 null이 왜 나쁜지 몇가지 레퍼런스들을 읽어보기로 했다. 1. Null이란 1-1. 개념 먼저 null이란 무엇인가? 영국의 컴퓨터 과학자인 Tony Hoare(토니 호어?라고 읽어야하나)가 만든 개념으로 위키백과를 참고하자면, In computing, a null pointer or null reference is a value saved for indicating that ..

9월 중순부터 자소서를 써가며 공부를 하기 시작했고, 출근을 12월 중순에 했으니 재취업까지 대략 2달반 정도 걸렸다. 지원한 회사를 세아려보니 총 24개의 회사에 지원했었다. 지원 회사의 기준은 아래처럼 정했다. 내가 자주 사용하거나 사용할 서비스인가 기술(또는 개발)에 대한 중요성을 높이 평가하는 회사인가 개발 문화가 좋아보이는가 또는 개발자들 사이에서 수평적인 소통 구조를 가졌는가 24개나 썼지만 하나하나 다 들어봄직한 회사라 2017년 하반기에 첫 지원할 당시와 달리 이름 있는 it회사가 많아졌다를 새삼 느꼈다. 전형을 진행했던 과정은 아래와 같다. 서류탈락 또는 연락없음: 8개 코딩테스트 또는 전화면접에서 탈락: 6개 1차 면접에서 탈락: 5개 2차(최종) 면접에서 탈락: 2개 최종 합격으로 1..

작년 2021년 3월에 퇴사를 했었다. 세상에 계획대로 되는게 없다고 하는데 이렇게 모든게 계획대로 되는게 없었던 건 작년 한 해 뿐이었다. 집안에 굉장히 안 좋은 일이 생겨 퇴사하며 계획했던 것을 중단하고 개인적인 일을 해결하는데 집중해야했다. 그렇게 6개월의 시간이 지났고 더이상내게 남는 것 없는 시간을 흘려보낼 수 없었다. 재취업을 위해 고향에서 서울 자취방으로 올라왔다. 그게 9월쯤이었다. 지난 반년 동안 코드를 보거나 코딩 한 번 제대로 못해본 상황이었다. 불안했다. 6개월 동안 사회생활과는 단절되어 있었고 무엇보다 개발에 관한 일이나 공부를 하지 못한 상황이었으니까. 그렇다고 이 나이에 무서워서 계속 도망칠 수 없었다. 내 인생 대신 책임져 줄 사람은 없으니까. 결론은 카카오모빌리티에 합격하..

요즘 회사에서 기존 서비스를 새로운 언어로 마이그레이션 작업을 하고 있다. istio를 통해 기존 서비스의 api를 신규 서비스에 새로 작성된 api로 라우팅을 해줘야하는 상황이었다. prefix를 통해 편하게 작성하면 좋았겠지만, 피처별로 완료한 개별 api 단위로 넘겨야했다. api를 작성하면 api url에 path variable이 끼어있는 케이스가 많기 때문에 중간에 path variable이 들어가도 정상적으로 라우팅 해주는 방법을 찾아야했다. 결론적으로 Virtual Service에서 제공하는 Regex(정규식) 방식으로 라우팅을 해주면 된다. 공식 레퍼런스에서 구글 Re2 정규식 스타일로 작성하면 된다고 표기 되어 있다. 근데 공식 레퍼런스에서는 딱히 예시가 보이지 않았고, 구글링을 해봐도..

gateway에 인증서를 설치해서 통신하도록 하는 설정 방법이다. 도메인에 맞는 인증서를 먼저 다운받아야한다. 1. 다운받은 인증서 파일 압축을 풀고 key와 crt를 쿠버네티스의 secret으로 등록해주어야한다. (네임스페이스는 istio-system 아래 생성) $ kubectl create -n istio-system secret tls {secret 이름} --key={인증서 key 파일명} --cert={인증서 crt 파일명} 아래는 예시. zorba.com이라는 도메인을 사용한다는 전제 $ kubectl create -n istio-system secret tls zorba-com-credential --key=STAR.zorba.com_key.pem --cert=STAR.zorba.com_c..

istio-ingressgateway는 아래에서 설명할 gateway와는 다른 개념이다. istio-ingressgateway는 Cluster의 entry point가 된다. 쿠버네티스에서 nginx ingress controller와 동일하게 ingress controller 역할을 수행한다. 로드밸런서 역할을 수행하며 pod로서 동작한다. istio 공식 사이트에 설명이 잘 나와있긴 하지만, 일단 정리해둔다. istio에서는 gateway와 virtual service를 통해 트래픽을 컨트롤 한다. virtual service로 패턴에 맞춰 어느 호스트 또는 서비스로 라우팅할지, 트래픽 비중(weight)을 어느정도로 할지 룰을 지정하고, gateway는 단어처럼 어느 호스트의 요청, 포트 등을 처리..

이제까지 공식 다큐먼트가 틀릴 수도 있을거라는 의심은 해본 적이 없었다. 현재 회사에서 Spring이 아닌 Jetbrains에서 만든 프레임워크인 Ktor를 사용하고 있다. 회사 프론트엔드 개발자분이 서버에서 403이 발생한다고 문의가 들어왔다. curl로 날리면 정상동작하는데 스웨거 UI에서 요청을 날리면 403이 발생하고 있었고, 서버에 CORS를 적용한 다음날이었다. CORS 이슈일거라 의심하고 보다보니 왜 안되는지 알 수 없어 일단 허용할 수 있는 설정을 다 추가해보니 동작했다. 소거법으로 하나하나씩 제거하면서 원인이 되는 설정을 찾아보았다. 찾아보니 헤더에 ContentType의 허용이 없으면 CORS가 발생했다. 응? 근데 공식 다큐먼트에서는 default로 ContentType을 제공한다고 ..