프로젝트를 많이 해보면서, 예외처리의 구조나 가장 좋은 예외처리? 방식에 대해서 연구해본 적이 없고 그냥 전역 예외처리를 최대한 해보는 것 말고는 없었던 것 같아서 정리해본 글이다.조금 두서없음주의..throw하는 순간 Throwable 객체가 생기고, 네이티브 메서드

생성자 주입수정자 주입(setter 주입)필드 주입일반 메서드 주입생성자를 통해서만, 의존관계가 주입되며 외부에서 수정할 수 있는 방법이 없다. 생성자 호출시점에 딱 한번만 호출되는 것이 보장된다. 불변, 필수 의존관계에 사용된다. 생성자가 한개만 있으면 @Autowi

@Bean으로 하나하나 설정 정보 등록하면 번거롭기 때문에, 반복을 줄이는 것이 필요하다. 그래서 스프링은 이러한 설정 정보 없이도 자동으로 스프링 빈을 등록하는 컴포넌트 스캔이라는 기능을 제공한다. 의존관계를 자동으로 주입해주는 @Authowired 기능도 제공한다.

웹 애플리케이션과 싱글톤 memberService라는게 있는데, 이걸 호출할 때마다 객체를 생성하도록 AppConfig에 요청하게 되면 매번 다른 객체를 생성하게 된다. 내부에 memberRepository도 생성자에 담고 있다면 더 생성된다. 그러면 메모리 낭비가

이 프로젝트는 UMC 8기에서 시작되었다.처음에 8기를 하면서 UMC SpringBoot 시니어로 참여했다. 'NOOK'에 지원한 이유는 디자인이 예뻐서였다! 목표가 캐릭터가 이쁘고, 분위기있는 디자인이 있는 (나는 백엔드지만) 프로젝트를 하는게 8기 목표였다. 백엔드

제어의 역전이란 외부에서 프로그램 제어 흐름을 관리하는 것이다. AppConfig가 프로그램의 제어권을 가져간다. 즉 서비스의 구현 객체는 자신의 로직을 실행하는 역할만 담당하고, 제어 흐름은 AppConfig가 가지고 있다. 구현 객체는 필요한 인터페이스를 호출하지만

원 서버가 미국에 있을 경우 느리기 때문에 한국 어딘가에 프록시 캐시 서버를 두고, 해당 서버를 거쳐서 올 수 있도록 한다. 그러면 웹브라우저가 프록시 캐시 서버에 접근하게 된다. 응답 시간이 훨씬 빨라진다.프록시 캐시는 public, 로컬 캐시는 privateCach

field-name은 대소문자 구분이 없다.HTTP 전송에 필요한 모든 부가정보다.메시지 바디 내용, 바디 크기, 요청 브라우저 정보, 캐시 관리 정보 등등..필요 시 임의의 헤더 추가가 가능하다. Content-Type: 표현 데이터의 형식 설명, 미디어 타입,문자

요청 완료하기 위해 클라이언트 프로그램(웹브라우저)의 추가 조치가 필요할 때 보내는 상태코드이다.웹 브라우저는 3xx 응답의 결과에 Location 헤더가 있으면 Location 위치로 자동 이동한다.요청을 하고 /event라는 엔드포인트로 요청했는데, 이 엔드포인트가

equals() : 두 객체 비교, true면 hashCode()도 같아야 함객체 주소가 같으면 True== 는 값만 판단 가능, 같은 객체인지 판단하려면 equals 사용 필수String 객체에서는 주소가 같으면 True, 오버라이딩된 equals 함수를 사용하기 때

이번에 모니터링을 평소 하던 AWS가 아닌 Railway와 연결해서 하면서, 어떤 모니터링 방식으로 메트릭 수집을 하면 좋을지 생각해보게 되었다.메트릭은 매 이벤트를 전송하는 게 아니라, 애플리케이션 메모리 안에서 숫자를 계속 누적하거나 갱신하다가 일정 주기마다 스냅샷

상반기 시간이 너무 빨리 흘러간 것 같기도 하고 .. 이래저래 많은 일이 있었어서 상반기 회고록을 작성했다.!가장 큰 사건 위주로 보면UMC 9기 수료 및 데모데이 새로운 프로젝트 백엔드 합류, 8월 런칭 예정UMC 스프링 파트장, 안드로이드 챌린저로 스터디 진행개발동

sealed class는 상속 가능한 범위를 같은 파일로 제한하는 클래스다.컴파일러가 모든 하위 타입을 알고 있기 때문에, when 분기에서 else 없이도 모든 케이스를 강제 처리할 수 있다.나중에 Triangle을 추가하면, 처리하지 않은 when에서 즉시 컴파일

증상 생성/수정 후 Gemini 기반 패턴 분석을 비동기로 갱신하고 있었다.기존 흐름은 다음과 같았다.이 구조에는 두 가지 문제가 있었다.Gemini 호출이 DB 트랜잭션 안에서 실행된다.오래 걸린 이전 비동기 작업이 나중에 끝나면서 최신 분석 결과를 덮어쓸 수 있다.

이번에 테스트 환경을 보다가 찝찝한 지점이 있었다.운영은 PostgreSQL을 쓰고 있는데, 테스트는 H2의 PostgreSQL mode로 돌고 있었다.처음에는 PostgreSQL mode면 어느 정도 비슷하지 않나?라고 생각할 수 있다.그런데 Repository 테스

커서 페이징을 다시 보다가 갑자기 헷갈렸다.PageRequest.of(0, size)를 쓰면 offset이 0이니까 cursor 기반 조회에서 사실상 limit size처럼 동작하는 것 아닌가?그럼 Limit.of(size)랑 뭐가 다른가?또 Slice는 hasNext

User마다 한개씩만 생성되어야 하는 엔티티들이 있다. 기존에는 기본키를 따로 두고 user를 FK로 두는 방식으로 진행했다. 그렇지만 기본키를 많이 안쓰고 findByUserId 식의 메서드를 많이 사용한다면 컬럼 방비라고 생각하여 전략을 변경해보게 되었다. 기존 방

자바 스프링 -> 코틀린 스프링으로 갈아타면서, Slf4j을 당연하게 사용했는데 코틀린은 롬북을 잘 사용하지 않기도 하고, 이참에 다른 로거와의 성능을 비교해서 써보자 하고 다른 로그 작성 방법을 찾아보게 되었다. 로그 수준에 따라서 로그가 남겨진다. 즉 logger.

UMC 안드로이드 8주차 미션 블로그 챌린지입니다.RecyclerView, Adapter, ViewHolder, 각 항목의 레이아웃 XML이 필요하다. 즉 XML파일, 코틀린 파일 분리해서 관리해야 한다. LazyColumn, LazyRow로 전부 대체 가능Compos

자바 개발자를 위한 코틀린 입문해당 강의를 듣고 작성하였다. 안드로이드,스프링에서 코틀린을 많이 사용하게 되었는데, 자바랑 비슷한 것 같다가도 너무 다른 것 같은데 지식 없이 사용하자니 어떤 실수를 하는지도 모르는 것 같아서 빠르게 기초를 공부하고자 한다. var, v