Intro Postgresql 에서는 특이하게도 배열 타입을 사용할 수 있다. 개인적으로는 이걸 선호하지는 않는데, 일반적인 다른 데이터베이스와 다른 형태의 쿼리작성이 필요하고 좀 더 복잡해지기 때문이다. 만약에 DB 마이그레이션이라도 해야 한다면 참 골치아프겠다. 특히 이런경우 ORM과의 호환성이 큰 문제가 될 수 있다. 업무에서 JPA를 주로 사용하고 있는데, 예상했던대로 자체적으로는 Postgres의 배열타입을 지원해주지 않았다. 대신 UserType을 구현하여 새로운 타입을 정의할 수 있긴 했는데 그 방법으로 문제를 해결해보려 한다. 준비 작업 시연을 위해 샘플 프로젝트 및 샘플 데이터베이스를 준비하였으나, 이미 진행중인 프로젝트와 DB가 있다면 건너뛰어 코드 및 엔티티 부분만 참고해서 문제를 해..

intro 웹 프로젝트를 진행하다보면 외부 설정값을 어플리케이션 내에서 활용할 일이 많다. 하드코딩을 해두면 후에 변경하기 쉽지 않기 때문에 외부에 설정값으로 빼는게 좋은데, 설정값이 한두개 일 때야 크게 어렵지 않지만 설정값이 점점 늘어나고 심지어 계층형 구조를 가진다면 점점 복잡해진다. 스프링에서는 편리하게 여러가지 설정값을 관리하기 위한 방법을 제공하는데 그 중 @ConfigurationProperties는 특히 프로퍼티의 값을 Bean으로 매핑하는 강력하고 직관적인 기능을 제공한다. 본 글에서는 @ConfigurationProperties의 기본 사용법과 주요 특징 및 주의할 점에 대해 다루어보려고 한다. main 프로젝트 생성 스프링부트 3.x 버전으로 먼저 생성하고 추후 2.x 버전으로 낮추며..

Intro 엑셀파일이나 zip 압축파일을 서버에서 생성해 다운로드를 제공할 때, 최초 응답시간에 대한 고려가 필요하다. 물론 미리 준비되어 있는 파일이라면 브라우저에 바로 응답을 보낼 수 있겠지만 DB에서 데이터를 조회하고, 이를 바탕으로 엑셀 파일을 생성하는 경우 사용자에게 여러 개의 파일을 압축된 형태로 제공하는 경우 이러한 상황에서는 파일을 준비하는 데 시간이 상당히 소요될 수 있다. 데이터의 크기에 따라 응답시간이 크게 달라지기 때문에 예상되는 응답 시간을 구체적으로 제공하기도 어려운 상황에서, 화면에 스피너만 딸랑 띄워놓는 것 만으로는 어지간한 사용자들의 인내심을 달래기 쉽지 않다. 서버에서 아무리 바쁘게 준비하고 있다고 뜨거운 열을 뿜어내며 소리쳐도 사용자는 서버가 멈춘 것으로 오해할 수 있다..

Intro 소프트웨어 개발을 하는 과정에서는 다양한 서드파티 라이브러리를 사용하게 된다. 이들 라이브러리는 우리가 직접 작성해야 할 코드의 양을 획기적으로 줄여주며 이미 검증된 라이브러리를 사용하면 코드의 안정성 향상에도 많은 도움을 준다. 하지만 각 라이브러리는 자체 라이센스 정책을 가지고 있으며, 개발자로서 이를 이해하고 준수하는 것은 법적이나 윤리적인 측면에서 매우 중요하다. 이번에 사용중인 모든 서드파티 라이센스 정보를 프로젝트에 기입해야 하는 일이 필요했다. 수동으로 관리하고 문서화 하는 것은 실수하기도 쉽고 시간도 많이 소요되기 때문에 자동화 할 수 있는 도구를 찾아보았고, 다행히도 제법 잘 만들어진 몇 도구들이 있어 어렵지 않게 라이센스 정보를 한번에 생성할 수 있었다. 지금부터 이 글을 통..

Intro 코틀린을 사용한 프로젝트에서 Mockito를 사용해서 테스트 코드를 작성했는데 아래와 같은 에러가 나며 코드가 동작하지 않았다. Cannot mock/spy class com.tistory.shanepark.dutypark.security.domain.dto.LoginMember Mockito cannot mock/spy because : - final class org.mockito.exceptions.base.MockitoException: Cannot mock/spy class com.tistory.shanepark.dutypark.security.domain.dto.LoginMember Mockito cannot mock/spy because : - final class at app//..