지금까지 알고 있던, 업무상으로 해오던 스프링 배치에 대해 정리했다. 배치란 대량 일괄 작업을 뜻하며 몇 시간에 한번씩 실행되는 등의 스케줄 개념은 포함되지는 않는다.  이점 스프링 웹 MVC와는 달리 스프링 배치를 사용하면 편리한 이유는 아래와 같다.   특정 작업 단위만큼 트랜잭션 처리를 하여 메모리에 한번에 올리는 양이 적기 때문에 OOM으로부터 상대적으로 안전하고 작업에 문제가 있으면 근방에서 다시 시작할 수 있다. (Chunk Oriented)성공한 작업 건에 대해서 실수로 재실행을 하더라도 작업이 수행되지 않는다. (ItemStream)작업을 세부적으로 나누어, 성공/실패시에 어떤 작업을 할 지 쉽게 지정할 수 있다. (Flow)무엇이 잘못되었는지 기본적으로 제공하는 이력 테이블을 통해 쉽게 ..

큰 건 아니지만, 난 지금까지 kotlin-jdsl에 약 3개 정도의 작은 PR을 반영한 적이 있다. 가장 염원한 것은 중위 연산, 연산자 오버로드였지만 아쉽게도 해당 논의건은 승인되지 않았다 .. ㅎ 이 글은 기여하면서 느끼고 배운 것들에 대해 작성했다. 느낀 것 코드 내부가 정말 이쁘다 아름답지 않은가? 얼마 전에 조사한 JPA 내부구조와 비교하면 정말 아름답다.. (미안하다 하이버네이트) 처음보는 데도 어떤 클래스가 무슨 역할을 하는지 지례 짐작하는 것이 어렵지 않았다. 무엇보다 OCP를 바로 떠올릴만큼 확장에 유연했다. 아, 그리고 Lint라던가 Commit 규약이라던가 하나라도 안 맞으면 PR을 못올린다 ㅠ 잘 체크해볼 것! 정성이 담긴 리뷰 우테코 이후 이런 리뷰는 오랜만인 것 같았다. 거기선..

운전 면허를 취득하고 알게된 사실은, 되려 경험이 많은 운전자일 수록 도로 법규나 운전 예절에 대해 망각하는 경우가 종종 있다는 것이었다. 최근 나와 JPA의 관계가 그렇게 되었다는 생각이 문득 들었다. 내 JPA에 대한 실무적인 이해도는 어느 정도일까? JPA나 DB를 개발하는 코어 개발자가 아닌 이상 실무에서 사용하는 기술의 이해도와 응용 능력이 보다 더 중요하지 않을까? 대다수의 개발자는 프레임워크나 라이브러리보다는 현실에 존재하는 특정 도메인에 대해 개발하거나 유지보수를 한다. 그래서 이 글을 보는 여러분들도 필자와 같이 JPA의 동작에 대해 다시 한 번 되짚어 보면 좋을 것이라는 생각이 든다. 퀴즈 자, 아래와 같은 코드가 있다고 하자. 그리고 임의의 컨트롤러가 method1을 호출한다고 가정한..

[주의] 이 글은 Common Sense의 범주에 벗어난 내용들이 일부 있을 수 있음을 알립니다. 그렇게 생각한 항목에 대해선🎃이모지로 표시하겠습니다. 3월에 바쁜 일이 너무 많이 있어서 밀린 포스팅이 한 가득이지만, 우선 DDD 세미나가 가장 최근에 있었기 때문에 여운이 아직 남아있을 떄 올리는 것이 좋다고 생각했다. 나는 DDD를 좋아한다. 그러나 아쉽게도 좋아한 세월에 비해 이해의 정도는 낮은 것 같았다. 공유 커널과 안티 코렙션 계층 등을 이용해서 무언가를 설계해 본적은 없기 때문이다. 이건 내가 코드 레벨에서의 이해도가 낮았기 때문에 도전 조차 못했던 것으로 느껴졌다. 그래서 그런지 평상시 좋아하는 모임에 DDD 강의가 열린다는 소식을 들었을 때는 무척 반가웠다. 발표한 사람은 평상시 모각코에서..

조사 계기, 트랜잭션 발원지에 대한 궁금증 @EventListener / @TransactionalEventListener (+ @Async 유무)에서 트랜잭션의 동작에 대해 알아보고 있었다 그러가다 아래 트랜잭션 로그의 발원지가 궁금해졌다 로그를 따라가다 보니 친숙한 얼굴들이 보였다 그만 조금만 보고 나온다는게, 끝을 봐보자는 마음으로 살펴보게 되었다 사전 지식 나는 이미 어느 정도 코드의 내막을 알았지만 처음 본 사람은 어려울테니, 알게된 내용을 미리 정리했다 이걸 보고 들어가면 코드를 읽어나가기 좀 더 수월할 것이다! TransactionAspectSupport (org.springframework.transaction.interceptor) 스프링의 AOP 기능으로 트랜잭션을 처리해주는 역할 실제..

샘플 코드는 이곳에 있습니다 (Kotlin + Spring + JPA) 인터넷의 많은 문서들을 읽었으나 클린 아키텍처 등 고전 명서를 정독하지 않고 적은 글입니다 :) 감안 부탁드립니다.. ^^ 마침내 1년 가까이 한 번은 작성후 알아봐야지… 하고 생각만 했던 것을 작성해서 올렸다 (사실 구글링을 조금만 해보면 방대한 예시 코드들이 나온다… 어렵지 않게 공부할 수 있었다) 고대하던 헥사고날 예시코들 작성하면서 느낀 점을 기술한다… 요약 여러 형태의 설명을 해보자면 버전 1 DIP를 이용해서 비즈니스 로직을 클린하게/순수하게 두었음 버전 2 각 레이어간 인터페이스를 두어서 변경에 유연하게 만듬 구조 나처럼 레이어 아키텍처를 알고 있는 사람은 그걸 리펙터링한다고 생각해도 좋을 것 같다 기존의 레이어드 아키텍..

게이트웨이 코드를 작성하다 보면, 이게 제대로 작동은 하는 것인가? 하고 의문이 들때가 있다 이러한 의문은 개인 프로젝트를 진행할 때뿐만 아니라 회사에서 동료들과 일할 때도 자주 떠올랐다 그리고, 비슷한 URI와 Route들의 순서 배열에 따라 몇몇 Route들이 동작하지 않기도 했다 길어진 Route 명세를 파악하기 위해 모니터를 위 아래로 훑는 시간도 많이 들고, 이 과정에서 실수할 소지가 많다는 것을 느꼈다 그래서 시간을 내서 리펙터링을 했고 성공적이었다 아래는 그때의 노하우를 좀 더 가다듬은 방식으로 진행한 것이다 문제의 YAML 명세 spring: cloud: gateway: routes: - id: ITEM-SERVICE uri: lb://ITEM-SERVICE predicates: - Pat..

내가 처음 리액티브를 많이 듣게 된 건 토비의 봄이었다 토비님도 이 Rx를 공부하는 데 많은 어려움이 있었고 몇 개월이 지나서야 감을 찾기 시작했다고 한다 Rx (Reactive Extensions)를 만든 MicroSoft 엔지니어들은 기존의 옵저버 패턴의 한계를 크게 2가지 지목했다고 한다 1. 도대체 이벤트는 언제 완료 되는가? 2. Error 핸들링을 어떻게 하는가? 옵저버 패턴에는 위 2개에 대한 기본 골조(아이디어)가 없다고 한다 이 2가지가 추가된 확장된 옵저버 패턴인 Observable이 Rx의 세 가지 축 중 하나의 축이 된다 (세 가지 축은 Observable, Scheduler, Observer를 말하는 것 같다) Reactive System 클라이언트와 맞장구를 잘 쳐주는 시스템 클..

채용 과제를 하면서 급하게 웹플럭스를 익혔다 이전에는 머릿속으로만 희미하게 존재하던 그 녀석을 집적 손으로 다루니 여러모로 느끼게 되었다 거의 2.5일에 걸쳐서 짧은 강의를 완강하고 500page의 책을 75% 정도를 속독한 것 같다 이게 가능한건 토비의 봄 리액티브 편을 종종 누워서 보아왔기 떄문이다 리액티브는 평소 관심은 있었지만 이걸 먼저 공부하면 성장 순서에 악영향을 미칠 것 같았기 때문에, 본격적인 공부는 미루어 왔었다 자, 이제 느낀 걸 적겠다 :) 얼마 전에 알게 된 사실들이라 틀린 내용이 많을 수 있다 느낀 것들 반드시 Mono를 반환해야 한다 무슨 얘기나면 컨트롤러의 Return type이 없거나, Unit이어선 안됀다 즉, Mono.empty() 라도 반환해야 한다 처음에는 이걸로 정말..

이 글은 이 전 글의 내용들을 토대로 재구성되었습니다 https://blog.naver.com/progress0407/222068926986 https://blog.naver.com/progress0407/222074132611 완성본 만들게 된 계기 당시 SI 철수 이후 부장님, 차장님, 사원님 등 본인을 포함한 5~6명이 작성해야할 엑셀 시트가 있었다 이전 동일 작업하셨던 차장님 말씀으로는 이틀 정도는 부지런히 작업해야 끝낼 수 있다고 하셨다 그 업무가 주어질 당시, 다른 팀원들은 다른 태스크가 있었고 신입이었던 내가 가장 먼저 하게 되었다 (중견 이상 기업의 신입은 입사 초기에 일이 없는 경우가 많았다) 내용은 간단했던 걸로 기억한다 각 테이블과 관련된 쿼리의 갯수를 고려해서 기입하면 되는 것이다 ..

종종 배포할때 느린 마이크로서비스 등록 과정 때문에 빠르게 확인할 수 없어서 답답했다 단독 모놀리스면 바로 확인이 가능했지만 마이크로서비스는 정상 기동 후 1분 정도를 기다려야 503 Service Available이 없어진 후 확인이 가능했다 그러나 이건 잘못됐다. 등록은 사실 바로 된 것이다. 문제는 다른 곳에 있었다. 이걸 위해서는 Spring Cloud Nexflix이자 Service Discovery인 Eureka에 대해 알아야 한다 Eureka는 Service Discovery의 Server로, Netflix가 MSA에 관련해서 만든 것 중 하나이다 (Gateway 등) 그건 중요하지 않다 (응?) 등록 과정 Eureka에는 Server 와 Client가 있다 client는 자신의 IP, Po..

코드는 이곳에 :) https://github.com/progress0407/jvm-tools-2.7.x/tree/main/querydsl-sample 코틀린을 도입하기로 결정했는데 자바 코드를 유지할 부분(공통)과 코틀린 코드를 분리할 일이 생겼다 그때 사용한 방법이다 참고로 나의 경우 자바를 사용하는 모듈, 코틀린 사용 모듈을 모두 나누었다 (즉 한 모듈에 자바, 코틀린이 있는 경우는 없었다) 참고로 코틀린, 롬복, QueryDsl이 모두 있는 상황에서 정상 동작하게 만드는 것은 너무나도 힘들다... 여러분은 굳이 그렇게 하지 말고 나처럼 모듈별로 개별 적용하면 그게 차라리 마음의 건강에 좋을 것이다... Gradle 스크립트 우선 아래와 같은 Java, Kotlin 별 QueryDSL 적용을 위한 ..