제어의 역전이란 외부에서 프로그램 제어 흐름을 관리하는 것이다. 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

매월 1일에 생성되는 Report에서 OOM 원인을 분석하고, 스프링 배치 도입을 고려한다.OOM은 out of Memory로, 힙 메모리를 더 이상 확보하지 못해서 터지는 상황이다. 다음 코드에서 예상 원인의 흐름을 찾아보면 다음과 같다. findAll()로 유저를

SQL 게임이 있다고 해서, 특히 추리 게임이라는 게 흥미로워서 풀어봤다. SQLite 기반인데, 자주 사용한 MySQL이랑 유사해서 금방 풀었다. 전체 ERD가 주어지고, 그걸 보고 알아서 sql문을 작성해서 solution 테이블에 insert하고 최종 확인하는 그

Kotlin으로의 전환을 연구하면서, DTO는 어떻게 구현해야하는지 생각해보게 됐다. 자바 코드 다음과 같은 자바 코드를 Kotlin으로 전환해 볼 것이다. private final 필드와 public getter, 생성자 할당을 합친 게 val이다. var로 선언하게

java에서 코틀린으로 spring boot 프로젝트를 전환하면서 가장 기초적인 BaseEntity 작성부터 접근 제어자나 getter, setter 측면에서 다른 점이 은근히 많아서 정리해보고자 했다. 자바에서는 LocalDateTime createdAt;이라고 하면

책이랑 조금 다르게 배포 전까지의 최소 날짜를 큐에 넣었다. 먼저 끝내도 배포를 못하기 때문에 순서대로 큐에 넣고, 다음 작업의 최소 남은 일수가 현재 끝낸 작업의 일수보다 작거나 같으면 같이 배포하는 걸로 처리한다. 큐를 써서 풀긴 했는데 꼭 쓸 필요는 없는 것 같다