우리집앞마당

JPA 를 이용하면 엔티티의 상태를 변경해주는 것만으로 update 쿼리를 실행시키게 된다. 이때 발생하는 쿼리는 모든 컬럼을 대상으로 update 를 실행한다. @Entity @Table(name = "person") public class Person { @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "person_id") private Long id; @Column(name = "person_name") private String name; @Column(name = "person_age") private int age; // 생성자 생략 public void setAge(int age) { this.age = age;..

# 이슈 코틀린에서 테스트 작성시 mock 객체가 필요하면 mockk 를 사용하고 있다. 아마도 가장 대중적인 mock 프레임워크 아닐까 싶다. 얼마전 mockk 를 이용해 테스트를 작성하다가 동료 개발자와 신기한 현상을 발견했는데 간략화하면 아래코드와 같다. class Simple1 { fun simple1(): String { return "hello world" } } class Simple2( private val simple1: Simple1, ) { fun simple2(): String { return simple1.simple1() } } class MockkApplicationTests { @Test fun mocking() { val simple1 = mockk() val simple2..

# producer property 설명 default key.serializer key 를 직렬화할때 사용할 클래스. org.apache.kafka.common.serialization.Serializer 를 구현해야함 value.serializer value 를 직렬화할때 사용할 클래스. org.apache.kafka.common.serialization.Serializer 를 구현해야함 bootstrap.servers 연결할 kafka cluster 서버 정보 host:port,host:port 형태로 여러개 전달 가능 "" buffer.memory 프로듀서가 전달할 레코드들을 버퍼링할 수 있는 총 메모리. 프로듀서 애플리케이션에게 할당된 메모리보다 작아야함. 단위는 바이트 33554432 comp..

모두다 등장한지 오래된 개념들이지만 몇년 전부터 DDD 의 바람이 부는듯 하더니 요즘엔 클린 아키텍처, 헥사고날 아키텍처 등에 대한 관심이 많은 것 같다. 관심이 많은 것과 잘 하는건 분명 다르지만 잘하기 위해서는 일단 관심을 가져야하기에 마냥 나쁘게만 볼 현상은 아니라고 생각한다. 나도 관심을 갖고있는 사람 중 하나인데, 이런저런 이름으로 소통되고 있지만 이들이 주장하는건 결국 도메인에서 기술을 분리하는 것이다. 애초에 spring 프레임워크가 등장했던 것 자체가 POJO 를 지키기 위함이었는데 언젠가부터 우리의 도메인엔 spring 이 침투하고 있다. 이런 내용들을 책이나 자료를 통해 공부하고, 구두로 의견을 나누는건 어렵지 않은데 막상 현업에서 하려고하면 다양한 고민거리들을 마주하게 된다. - 정말..

이전에 builder pattern 에 대한 생각을 포스팅한 적이 있다. 이번엔 무심코 많이 작성하는 ~ByParameter 에 대해 얘기해보고자 한다. 개발자가 가장 많은 시간을 보내는 것은 코드 고민, 코드 작성보다 네이밍이라는 우스갯소리가 있을 정도로 네이밍은 많은 고민이 되는 부분이다. 근데 문제는 부여할 이름 후보가 너무 많아서 고민인게 아니라 도저히 쓸 이름이 없어서 고민인게 문제다. 그러다보니 요즘엔 ~ByParameter 형태의 네이밍을 메서드에 많이 이용하는 것 같다. 특히 service layer 나 repository layer 에서 많이 사용된다. @Service public class ProductService { private ProductRepository productRepo..

처음 코틀린을 접한지 5년이 다되어가고 있다. 물론 실제 현업에서 사용한건 그 반정도 밖에 안되지만 말이다. 그동안 코틀린이라는 언어에 대한 본연의 기능과 그 외 코틀린용 라이브러리, 자바 프레임워크와 코틀린과의 궁합 등등에 대해 학습은 하면서도 테스트만큼은 계속 Junit 만을 이용해오고 있었다. mock 라이브러리인 mockito 와는 이런저런 궁합문제로 진즉에 mockk 로 넘어갔지만 Junit 과 assertion 라이브러리인 AssertJ 에 대해선 크게 불편함을 못 느꼈던게 그 이유가 아닐까 싶다. 여튼 kotest 자체는 오래전부터 알고있었으나 뒤늦게 한번 훑어보기로했다. kotest 는 크게 3개의 모듈로 구분된다. 이 모듈들에 대해 간단하게 알아보자. 1. Test Framework 테스..

이전에 이런 포스팅을 한 적이 있다. ( kotlin(+JPA) entity 에서 setter 를 막을 수 있을까 ) 결론을 암울하게 끝낸 것 같아서 몇가지 해결법을 포스팅하고자 한다. 1. 프레임워크에 의존하지 않는 domain layer @Entity @Table(name = "product") class Product( @Column(name = "product_name") var name: String, @Column(name = "product_price") var price: Long, @Id @GeneratedValue(strategy = GenerationType.IDENTITY) @Column(name = "product_id") val id: Long? = null, ) { fun up..

자바 백엔드 진영에서 로그는 이미 slf4j 가 평정했다. slf4j 를 기반으로 log4j, logback, log4j2 등 구현체들이 사용되고 있는 중이다. 코틀린에서도 유사하게 사용하면 되는데 아래와 같이 로깅할 수 있다. logger.info("1+1 = {}", variable) 기존 로거에서 {} 와 같이 템플릿을 지원한건 로그 레벨에 따른 레이지 연산을 지원하기 위해서였다. 가령 예를 들어 logger.info("1+1 = " + variable) 이렇게 작성하면 메세지와 변수 variable를 더하는 연산이 무조건 실행된다. 이 무조건이라는 표현은 애플리케이션 로그 레벨이 warn 으로 설정되어 info 레벨의 메세지를 로그를 남기지않아도 되는 환경에서도 실행된다는 의미이다. 다만 첫번째 ..

spring batch 를 이용해 많은 batch job 을 만들지만 배치를 테스트하기란 쉽지않다. 하지만 배치도 분명한 하나의 애플리케이션인만큼 테스트 작성에 대한 욕구가 있었는데 그것들을 정리해보고자한다. 먼저 spring batch reference 에서 테스트 코드에 대해 가이드하고있는 부분이 있는데 가이드 문서가 불친절해 제대로 테스트를 작성하기 힘들었다. 실전 엔터프라이즈 애플리케이션에서는 해당 가이드대로 했을때 도저히 테스트를 구동할 수 없었고, 많은 삽질끝에 얻은 결론을 정리하려한다. # batch job 작성 @Configuration class SampleBatch( private val jobBuilderFactory: JobBuilderFactory, private val stepB..

요즘 자바코드를 보면 클래스를 정의할때 무조건적으로 builder pattern 을 적용하는걸 심심찮게 볼 수 있다. 회사코드에서도 그렇게 작성된 코드를 쉽게 접하기도 한다. 더욱이 롬복에서 @Builder 라는, 아주 간편하게 빌더 클래스를 만들어주는 기능을 제공해주다보니 빌더 클래스를 만드는 것에 대한 부담도 없다. @Builder class Person { private String name; private int age; } 사용하는 쪽에선 이렇게 사용한다. Person p = Person.builder() .name("LichKing") .age(34) .build(); 언제부턴가 이렇게 빌더패턴이 거의 디폴트가 되다시피 한거같은데 개인적인 추측으로는 빌더패턴이 이렇게 퍼지게된건 이펙티브 자바의..