상반기 시간이 너무 빨리 흘러간 것 같기도 하고 .. 이래저래 많은 일이 있었어서 상반기 회고록을 작성했다.!가장 큰 사건 위주로 보면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;이라고 하면

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

오름차순으로 정렬을 한다. left, right로 각각 한명씩 선택하고, 만족을 못하면 이동하는 방식으로 한다. left 인덱스가 right보다 커지면 종료하므로 전체를 다 돌게 된다. 가장 가벼운 사람 선택하고, 가장 무거운 사람과 합쳐서 limit보다 작거난 같으면

문제 보기푼 방법이중 연결리스트를 구현했다. Stack<Integer> deleted : 삭제된 노드를 보관하는 스택 int\[] prev : i번째 노드의 이전 값들을 보관하는 배열, 첫번째 노드는 이전 노드가 없으므로 -1을 넣는다.int\[] next : i

문제 보기초기화: 세로 라인별로 stack을 만들어서 리스트에 저장한다. 스택에 먼저 넣기: n-1이 제일 끝부분에 들어가야 하므로 n-1,n-2 이렇게 해서 해당 라인 stack에 저장한다. 크레인을 돌아다니면서 뽑기: 뽑은 것을 picked stack에 넣는다. 이

세계적인 호텔인 형택 호텔의 사장인 김형택은 이번에 수입을 조금 늘리기 위해서 홍보를 하려고 한다.형택이가 홍보를 할 수 있는 도시가 주어지고, 각 도시별로 홍보하는데 드는 비용과, 그 때 몇 명의 호텔 고객이 늘어나는지에 대한 정보가 있다.예를 들어, “어떤 도시에서

효주는 포도주 시식회에 갔다. 그 곳에 갔더니, 테이블 위에 다양한 포도주가 들어있는 포도주 잔이 일렬로 놓여 있었다. 효주는 포도주 시식을 하려고 하는데, 여기에는 다음과 같은 두 가지 규칙이 있다.포도주 잔을 선택하면 그 잔에 들어있는 포도주는 모두 마셔야 하고,

스타트와 링크 - 실버1처음에 팀을 따로따로 만들어서 잘 안됐다.. 그래서 하나만 만들고 나머지 팀원은 링크 팀에 들어가도록 하고,dfs를 재귀로 돌리면서, 백트래킹하도록 구현했다.