Introduction 새로운 프로젝트를 생성하면서 그동안의 Swagger 을 사용한 문서화 방식 대신 Spring REST docs 를 활용해보고자 했고, 이전에 사용하지 않은 플러그인을 추가했다. 개요 Gradle 로 빌드 시 발생한 에러를 자세히 읽어본 후 관련 코드를 찾아보다가 플러그인 중 ''org.asciidoctor.convert'' 가 추가된 것을 발견할 수 있었다. 해결 구글링을 하는 도중 asciidoctor 는 Spring Rest Docs 에서 사용하는 플러그인이라는 사실을 알게 되었다. Spring Rest Docs 공식 문서에서는 다음과 같이 build.gradle 파일을 작성하라고 되어 있다. plugins { (1) id "org.asciidoctor.jvm.convert" ..
Goal 캐시를 적용하여 같은 키워드 사용하여 검색 시 캐시에 저장된 쿼리문과 엔티티를 사용하도록 하여 검색 속도 개선 캐싱 적용하기 위한 준비 * 환경 - Spring Boot 3.x - Hibernate 6.x 우선 Hibernate 의 버전을 확인하고 버전에 맞는 EhCache 의존성을 build.gradle 에 추가해주었다. 출처의 첫 번째 링크를 참조해서 JCache 와 EhCache 의 의존성을 모두 추가 후 yml 파일을 설정해 1. L2 캐시를 사용하며 2. 콘솔 로그에서 L2 캐시가 적용이 올바르게 되었는지 확인하겠다고 명시했다. 아래는 build.gradle 에 추가한 dependencies 이다. implementation 'org.hibernate.orm:hibernate-jcach..
Introduction 프로젝트를 하던 중, DB 에서 테이블을 조회하는 코드가 중복이 많다는 것을 알게 되었다. 이후 중복을 없애기 위해 디자인 패턴을 적용하자고 마음을 먹고 전략 패턴을 적용해보았다. 패턴 적용 전 코드 public SearchPageGetResponse findTracksWithKeyword(Pageable pageable, String searchKey, String memberEmail) { Member member = validateMember(memberEmail); Page tracks = trackRepository .findAllByTrackTitleContainingOrAlbumAlbumTitleContainingOrArtistArtistNameContaining(ke..
기본 클래스를 찾거나 로드할 수 없다는 에러가 자꾸 발생해, 에러를 해결하고자 구글링을 계속 해야 했다. 에러 상황 해결 우선 스택 오버플로우에 Settings-> Build, Execution, Deployment-> Build Tools-> Gradle 에서 설정을 바꾸라는 식의 조언이 있어서 참고했지만 에러는 여전했다. 하지만 도무지 원인을 알 수 없었다. 분명 main 클래스를 건드리긴 했지만, 이름을 변경한 것이 아닌데 왜 인식을 하지 못하고 있을까? 그러던 중 걸리는 것이 딱 하나 있었는데, 프로젝트가 위치한 폴더 명이 한글로 되어있다는 점이었다. 이전에도 한글로 한 적이 있었던 것 같았지만 지푸라기라도 잡는 심정으로 폴더명을 영어로 변경해보았고 바로 해결되었다 🤣 결론 프로젝트 폴더명은 영어..
Introduction Spotify Web API 를 사용하던 도중, Album 과 Track 은 불러오는데에 성공하면서도 Artist 를 불러오지 못하는 문제가 발생하였다. 💥 문제 발생 아무리 코드를 둘러봐도 문제점을 발견하지 못했고, 빈 값으로 가져오는 이유가 명확하게 찾아지지 않았다. 혹시나 tracks/{offset}/artists/name 의 경로 설정이 다를 수도 있겠다고 판단이 되어서 로직 수정이 아닌 오타를 찾는 데에 집중했다. 하지만 찾을 수 없었다. 온갖 수정을 하던 차에 Json 데이터 값에서 key artist 의 value 를 추출하여 JsonNode 객체에 할당할 때 문제가 있을 수도 있으니 추출하는 코드를 변경하고 있었다. 그리고 기존 at 메서드 사용에서 get 메서드를 ..
🔍 리팩토링 전의 코드 프로젝트 중 테스트를 작성하면서, 기계적이고 반복적으로 하나의 패턴을 여러 상황별 테스트 메서드에 공통으로 사용하고 있음을 발견했다. 아래 두 코드 블럭들과 같이 모든 코드가 동일하고 ErrorCode 의 종류와 HTTP 상태를 나타내는 status() 만 차이가 있는 메서드들이 있었다. 기능 구현 메서드들을 작성할 때에는 템플릿 콜백 패턴과 같이 인터페이스를 활용해 중복을 제거하고 관심사를 분리할 수 있었는데, 테스트 코드에서는 한 번도 매개 변수를 가진 메서드를 정의해본 적이 없다는 단순한 이유로 하나의 메서드에서 작성한 코드를 ctrl+c, ctrl+v (복사 후 붙여넣기) 하여 다른 메서드에서 쓰는 비효율적인 프로그래밍을 했다. 리팩토링을 거쳐서 어떻게 중복을 줄이고 공통된..
🔍 현 상황 프로젝트 진행 과정 프로젝트를 하면서 스프린트를 두 개로 나누었다. 각 스프린트를 브랜치로 만들었다. 첫 스프린트 단위는 브랜치 이름으로 sprint1 을 사용했다. sprint1 을 source 브랜치로 각 기능 구현을 할 때마다 1개 브랜치씩 만들었고, 기능 구현을 마칠 때마다 sprint1 으로만 병합을 하고 main 은 놔두었다. sprint1 의 모든 작업을 마친 후 main 브랜치에 병합을 할 생각이었다. 문제 발생 스프린트가 끝나기 전까지 모든 기능 단위에 대한 브랜치는 sprint1 에만 병합, 즉 merge 가 되어야 했다. 근데 무슨 생각이었는지, 실수로 Target branch 를 바꾸어주지 않고 main 에 기능 한 개를 merge 하고 말았다. 이후 main 에 스프린..
- Total
- Today
- Yesterday
- JPQL
- 코딩 테스트
- 기지국 설치
- ResponseEntity
- N+1
- docker
- 지연 로딩
- JOIN FETCH
- json web token
- 깃랩
- 서버 호스팅
- 프로그래머스
- gitlab
- LazyInitializationException
- 역직렬화
- Java Data Types
- 알고리즘
- spring security
- DTO
- 가상 서버
- Spring Boot
- 인증/인가
- JPA
- @RequestBody
- Jackson
- 코테
- ci/cd
- DeSerialization
- google cloud
- 도커
일 | 월 | 화 | 수 | 목 | 금 | 토 |
---|---|---|---|---|---|---|
1 | 2 | 3 | 4 | |||
5 | 6 | 7 | 8 | 9 | 10 | 11 |
12 | 13 | 14 | 15 | 16 | 17 | 18 |
19 | 20 | 21 | 22 | 23 | 24 | 25 |
26 | 27 | 28 | 29 | 30 | 31 |