스파르타 Java 단기심화 6기 TIL

스파르타 단기심화 6기 오늘부로 스파르타에서 진행하는 AI를 활용한 백엔드 아키텍처 심화 과정을 시작하게 되었다. 본격적인 심화과정을 참여하기에 앞서 오늘부터 2주간 사전 캠프가 진행된다. 팀 노션 작성 MBTI와 각자 한마디씩 적고, 각자의 오늘 목표를 공유했다. 멤버카드 작성 단기 심화 동기들에게 자신을 설명하는 멤버카드를 작성했다. 나는 나의 성격...

기술 블로그 작성 첫 날 학습 매니저께서 공유해주신 아티클을 읽어보았다. 내용은 기술 블로그의 중요성과 함께 기술 블로그 작성을 장려하는 글이었다. 사실 많은 실력있는 개발자 분들이 이미 기술 블로그를 작성하는 것을 봐 왔고, 나도 또한 기술 블로그를 작성하기로 마음

입문주차 강의 (고민) 이전에 이미 한 번 배운 내용이라 강의 수강하는 데에 시간이 별로 안 걸릴 것이라고 생각했는데 생각보다 시간이 많이 걸리고 있다.

사전캠프 기간 동안 다음 내용으로 미니 프로젝트를 구현하게 되었다.💡상품을 등록하고 → 사용자가 주문하고 → 주문 정보를 조회한다

ORM (Object-Relational Mapping) 반복적이고 번거로운 애플리케이션 단에서의 SQL 작업을 줄여주기 위해서 객체와 DB의 관계를 매핑 해주는 도구 기존 JDBC 방식으로 DB를 직접 조작할 때 문제 1. 테이블을 직접 SQL에 따로 접속해 만들

학습관리 매니저님이 정성들여 써주시는 아티클을 읽고 배운 점과 느낀 점을 정리해 보았다.

SpringBoot 환경에서는application.properties에 DB 정보를 전달해 주면 이를 토대로 EntityManagerFactory와 EntityManager를 자동으로 생성해준다.

사전캠프 기간 미니 프로젝트를 마저 구현하기로 했다.

REST API는 HTTP 응답의 status와 header를 의미에 맞게 사용하고, 필요한 경우 body를 포함해 응답해야 한다.Spring MVC에서는 HTTP 응답을 표현하기 위해 ResponseEntity를 제공한다.응답 객체를 작성하기 위한 다양한 static

기술적인 문제나 여러 컴포넌트에서 공통적으로 사용하는 관심사를 처리하는 객체들은 수동으로 Bean을 등록하는 것이 바람직하다.이러한 객체들은 보통 기술 지원용 Bean으로, 공통 로그 처리와 같이 비즈니스 로직을 직접 담당하지 않으면서도 이를 보조하는 부가적이고 공통적

JWT 다루기 회원가입 로그인 구현 필터 Spring Security 프레임워크 Spring Security 로그인 Spring Security JWT 로그인 접근 불가 페이지 Validation Validation 예외 처리 CRUD 프로젝트에 적용하기

오늘부터 사전캠프 이후 본 캠프가 시작되었다.출석과 강의, 취업지원 등 캠프 진행과 운영에 대해 OT를 통해 설명을 받고 팀을 배정받아 팀원들과 자기소개를 하고 팀 규칙을 정하고, 나머지 시간에 강의를 들었다.오늘의 목표는 Validation까지 실습하는것! 오늘 일과

1️⃣ 기본 원칙👉 작은 타입 → 큰 타입 : 자동👉 큰 타입 → 작은 타입 : 강제 캐스팅2️⃣ 숫자 타입 크기 순서 (중요 ⭐)3️⃣ 자동 형 변환 (업캐스팅)✔️ 데이터 손실 가능성 없음4️⃣ 강제 형 변환 (다운캐스팅)✔️ 소수점 버림⚠️ 데이터 손실 가능5

if, else, for, while 등 제어문 내 실행문이 한 줄일때 {} 생략이 가능하다.그러나 나중에 코드가 추가되는 경우가 있고,제어문 범위를 명확히 하기 위해 중괄호는 사용하는것이 좋다.처음엔 x만큼 늘어나는 변수를 따로 두고 배열에 저장해줬는데 배열 인덱스로

아침부터 속이 불편해서 깼다. 독감을 옮았는지 몸살기도 있어서 오늘은 캠프에 결석을 하고 휴식을 취하고 저녁에 조금 공부를 했다.

오... 쓰고 나서 보니 오늘이 13일의 금요일이다. 어제 잠을 많이 잤더니 몸 상태가 훨씬 나아진 것 같다. 어제 JWT 로그인 강의를 듣다 말았는데 JWT로그인 부분은 어제 TIL에 합쳐서 작성했다.

오늘의 갈 길이 멀다!일단 강의를 듣는다😭회원가입을 진행할 때 사용자가 자신의 주소를 검색해서 전달하는 등 라이브러리 사용만으로 구현하기 힘든 부분을 미리 만들어진 주소 검색 API를 활용하면 해당 기능을 간편하게 구현할 수 있다.이러한 다른 API서버로의 요청을 간

Naver Open API 네이버 오픈 API 목록 오픈API 사용 신청 로그인 후 애플리케이션 등록을 한다. 다음 양식을 채워준 후 애플리케이션 등록을 마무리 해 준다. 내 애플리케이션 - 해당 애플리케이션 이름 에서 요청에 필요한 Client ID와 Clien

다른 Entity를 참조하기 위해 하나의 엔티티가 다른 엔티티 타입의 필드를 포함하는 형태로 표현된다. (이 관계가 DB 테이블에 실제 컬럼으로 존재하지는 않는다.)

이번 설 동안엔 꼭 Spring 강의를 끝내려고 했지만 이번 주 진짜 최악으로 컨디션이 안좋았다..🤯 다음 주엔 최상의 컨디션이 되길 바라며..😢

코드 카타 1. 나누어 떨어지는 숫자 조건맞는 요소 추가 + 가변배열->정적배열 List 방식 대신 stream을 사용할 수 있다. 2. 음양 더하기 배열[i] 앞에 부호를 붙여도 되나 싶어 해봤는데 이게 되네? 했던 코드😅 확인 결과 양수에 +를 붙여도 동작한

코드카타 1. 핸드폰 뒷자리 4자리만 남기기 처음에든 생각은 뒷자리 4자리를 저장한다. 앞 자리 수 만큼 *를 반복한다. 두 문자열을 합친다. 그런데 Java에서 Python의 '문자'*횟수 문법이 있는지 확실치 않았고, 문자열 더하기를 반복하면 시간이 오래 걸리기

오늘부터 3/12일까지 팀 프로젝트를 하게되었다.새로 만난 팀원들과 자기소개를 하고, 팀 규칙과 컨벤션을 작성하고 프로젝트 구현을 위한 기능 리스트와 ERD를 작성했다.

배열을 탐색해 가장 작은 수와 그 위치를 찾는다. 원본 배열을 하나 하나 복사하며 찾은 수라면 스킵한다.

코드 카타 문자열에서 가운데에 있는 글자 문자열로 반환 substring()을 사용하면, charAt() 두 번 쓸 필요 없이 계산을 직관적으로 할 수 있다. 조건문 없이도 가능:

코드카타 수박수박수박수~ 홀수일때 수, 짝수일때 박 와 이번 문제는 5분만에 풀었다! 코드카타를 매일 하니 코딩 감이 다시 살아난것 같다. 내적 예....? 저는 선량한 코더입니다만... 다행히 문제에 정의 식이 친절하게 주어져있었다. >a와 b의 내적은 a[0]

각자 원하는 도메인을 골라서 분배하는 방식으로 역할 분담을 맡았다. API구현에 경험이 적어 나는 구현이 늦는 편이라 생각해 먼저 팀원의 코드를 참고해 감을 잡을 수 있도록 후반부에 구현해도 괜찮을 리뷰 도메인을 맡고싶다고 했다.

오늘은 코드카타 대신 고봉밥 PR을 보며 오늘의 학습을 시작했다.

팀원이 작성한 회원가입, 로그인 코드를 통해 JWT인가 요청을 어떻게 처리하는지 공부하고 나머지 API에 인가 로직을 포함시켜 작성하기로 했다.

Review 도메인의 CREATE API 명세서를 다시 작성하면서 아주 자연스럽게 생각했다."아, 리뷰 화면엔 당연히 작성자 닉네임이 보여야지!"API 명세서를 수정하고 개발을 진행하는데,앞서 리뷰를 생성할 때는 로그인한 유저의 정보를 Security Context에서

오전 회의 오전 튜터님 피드백 >정리해서 주말중에 완성해 팀원들과 공유하기로! PR 머지 후에 내용에 대해 수정할 부분을 기록해두었다. 리뷰 작성시 N+1 문제 해결을 위해 설계 단계에서 분리한 통계 테이블에서의 Race Condition

이전에 create Service 코드를 짤 때 생각하지 못한 조건이나 잘못 구현한 것을 갈아 엎느라 너무 많은 시간이 소요됐다.때문에, 먼저 프랩 코드와 구현 방식을 구상한 뒤에 코드를 작성하기로 했다.(토요일 출근길 지하철에서 지피티와 함께...ㅎㅎ;)

새벽에도 개발은 계속된다~ 😪(졸면서 코딩중) 이미지 파일을 왔다갔다? 배달 앱 후기를 남길 때, 음식에 대한 사진을 올릴 수 있다. 그렇다면 이러한 음식을 프론트에서 보여줄 때, 사진파일이 직접 왔다갔다 하는 걸까? 정답은 따로 이미지를 호스팅하는 곳을 두고, 그

Spring Batch는 대량 데이터를 일괄 처리(batch processing) 하기 위한 프레임워크이다.Spring Batch는 보통 3단계 실행 구조,(데이터 읽기/가공/조작)5단계로 동작한다.근데 어디서 많이 본 기억이 나는데..? 뭔지 기억이 안난다Job은전체

새로운 팀과 함께 각자가 책임지고 할 수있는 주된 역할을 미리 정해두는 게 좋을 것 같다는 의견에 따라, 역할 분담을 했다.

Postman에는 요청을 여러 번 동시에 쏘는 기능이 있다.Postman 왼쪽 상단의 Collections 탭에서 API가 담긴 폴더를 클릭우측 상단의 Run 버튼Iterations: 10~20 (요청 횟수)Delay: 0ms (딜레이 없음)요청 횟수보다 적은 수량으로

코드카타 (오백년만) 부족한 금액 계산하기 원본 훼손 + 오버플로 위험 처음에 이 코드를 사용했는데 일부 테스트케이스에서 실패를 했다. 원본 잔액인 money를 훼손하고 또 계산 과정에 오버플로우가 날 수 있을 것 같아 long 변수로 뺐더니 테스트케이스는 통과되었다

더 최적화 할 방법이 있을까? 싶어서 AI에 물어보니 배열의 각 row를 변수로 해 참조하는 방식이 미세하게 더 빠르다고 했다. (+ 배열 포인터를 이동시키는거라 할당 비용 적음)(그런데 JVM에 따라 알아서 최적화 하기도 한다고 한다.)지난번에 발견한 java11 문

코드카타 3진법 뒤집기 3진법은 처음 봐서 대체 어떻게 구하지.. 하다가 문제에서 주어진 답을 도출하는 과정을 보고 2진법을 구하는 방식의 규칙을 대조해 3으로 나눠가며 나머지를 모으면 3진법이 되는것을 알았다.

코드카타 이상한 문자열 만들기 이상한 코드 만들기 30분 간 노력은 했다... (코테 합격 <- 이거 다음 생 이야긴가요?😭) StringTokenizer는 공백을 따로 처리해줘야해서 이 문제엔 적합하지 않다.

주석과 같은 아이디어로 코드를 짰다.하지만 인덱스 범위를 이렇게 정하면i == j == k 같은 학생 3번 선택되는 경우도 포함된다.그래서 다음과 같이 고쳐야 했다.i &lt; j &lt; k그리고 불필요한 반복을 줄이기 위해(a,b,c 합을 구할 때 a 반복문에서는

카프카 설치 가이드 카프카 도입 목적 카프카를 사용하는 이유는 단순한 데이터 파이프라인이 아니라 고가용성(High Availability) 확보에 있다. 비용 부담이 있으므로 t3.micro 서비스를 사용하는 것을 추천

DDD 설계 어렵다.😂

발제문에 이렇게 적혀있어서 주문이 당연히 배송ID를 가져야한다고 생각했는데,주문이 배송 정보를 필요로 하지 않고, 배송이 주문ID를 가지고있다면 주문에 대한 배송 정보를 가져올 수 있다.

Delivery Manager를 엔티티로 관리하고있었는데, 현재 구조에서 Role 타입구분 외에는 User와 별다른 특성이 없어 따로 관리하지 않는다. 처음에 프롬프트 템플릿을 crud로 사용자가 (알림 관리자) 수정할 수 있어도 좋겠다 싶었지만 경로 계산이나 경로의

코드카타 최소직사각형 >가장 긴 가로 길이와 세로 길이가 각각 80, 70이기 때문에 80(가로) x 70(세로) 크기의 지갑을 만들면 모든 명함들을 수납할 수 있습니다. 하지만 2번 명함을 가로로 눕혀 수납한다면 80(가로) x 50(세로) 크기의 지갑으로 모든 명함

시저암호 문제분석 먼저 조건을 꼼꼼히 읽고 문제가 어떤 풀이를 요구하는지 생각해보았다. > 문자열 s와 거리 n을 입력받아 s를 n만큼 민 암호문을 만드는 함수 s는 알파벳 소문자, 대문자, 공백으로만 이루어져 있습니다. "z"는 1만큼 밀면 "a"가 됩니다. → 원

implementation으로 선언된 의존성은 공통 모듈 내부에서만 유효하며, 해당 모듈을 참조하는 하위 프로젝트에서는 접근할 수 없다 api 프로젝트 전반에 공유될 공통 의존성은 api 방식으로 추가한다.

오늘 안에 유저 CRUD 만들기를 모두 끝내야한다. 진짜 거짓말 같다... 만우절인데 거짓말이었으면 좋겠다.SSO 지원, 세션 관리인증, 권한 부여가 적용되는 범위를 나타내는 단위이다.SSO를 적용한다고 했을 때 해당 SSO가 적용되는 범위는 Realm 단위이다.인증,

배송 생성 과정에서 배송이 허브가 (허브간 경로는 물론) 주문, 유저 정보까지 가져와야하는지 의문이었다.배송 서버가 생성 시점에 유저 서버로 직접 데이터를 조회(API Call)하도록 설계하면, 배송 서비스는 유저 서비스의 가용성에 종속된다.문제 상황: 유저 서버가 점

개념: 데이터 변경(Command)을 담당하는 모델과 조회(Query)를 담당하는 모델을 물리적으로 분리.장점: 조회 성능 최적화, DB 부하 분산, 읽기/쓰기 스케일링 개별 가능.활용: 읽기 모델은 도메인 이벤트를 구독하여 데이터를 미리 구성해두는 방식(Project

사용자 서비스에서 CQRS 기반 조회를 구현하던 중, 도메인 정의 자체가 잘못되어 있었다는 사실을 깨달았다.문제의 시작은 기획 단계에서 작성한 도메인 정의 문서였다.허브에 직접 귀속되지 않는 역할임에도 불구하고, 허브 배송 담당자(HUB_DELIVERY_MANAGER)

Consumer 쪽에서 같은 메시지가 두 번 오면 중복 처리를 막는 어노테이션이다.위의 공통모듈을 사용한다.이벤트가 발생했을 때 다른 서비스로 보내줄 정보를 담는다.여태껏 조회에서 DTO를 만들었듯이 받는 부분이 어떤 부분이던, 모두 포괄하는 내용을 담도록 해 공통으로

flyway 영속 공간 만들어서 라운드 로빈에 사용하기 NPE - DB 컬럼이 nullable이면 엔티티도 래퍼타입을 써야한다.

stash 날려서 git임시파일 하나나 뒤적거렸던 때를생각하면 아직도 눈앞이 흐려진다....(결국 임시파일에도 없었다)🥹프로젝트 외적으로 발생했던 문제들을 기록해 놓는다.stash pop 할 때 feat/ffeeaatt의 파일 A와 stash 속 파일 A가 충돌해서,

코드 카타 문자열 내 마음대로 정렬하기 Comparator | 반환값 | 의미 | | --- | ---- | | 음수 | a가 앞 | | 0 | 같음 | | 양수 | b가 앞 | compareTo() a.charAt(n) - b.charAt(n)

최종 프로젝트 시작 전 이전 프로젝트 정리 스스로 사용한 기술을 명확히 정리 왜 그 기술을 선택했는지 설명 어떤 문제를 어떻게 해결했는지 구조화 이력서 / 포트폴리오 / 면접 답변까지 연결되는 형태로 정리 [회고] 모놀리스부터 MSA까지

코드 카타 K번째수 문제에 따라 대체적으로 틀을 잡았다. 자르기 배열을 범위에 따라 잘라낼 때는 copyOfRange(array, start, end) 를 사용하면 된다. 반개방 구간 : [start, end) 을 사용한다. 주어진 i 는 ~"번째" 이고 메서드에서

프로젝트를 진행하면서 모임 평가, 판매 평가, 구매 평가라는 세 가지 유형의 리뷰(평가) 시스템을 구현해야 하는 상황에 직면했다.위의 구성도를 보면 알 수 있듯이, 이 세 가지 평가는 필드 구성이 완전히 동일하다.모임/판매글/구매글 ID, 평가 일자, 평가자, 평가자

독후감이 개인 독후감, 모임활동에서 독후감으로 나뉘는데단일 테이블로 구성할 경우 모임활동과 관련된 모임 ID와 회차는 nullable 한 필드가 된다.표현계층 예외처리를 애플리케이션 계층과 분리해야 맞지만 헥사고날을 바로 도입하기보단 시간 상 초록색 부분의 구현에 집중

어제 배운 내용을 팀원에게 공유했다.MSA 인프라를 설계하다 보면 엣지 레이어에 놓을 수 있는 후보가 세 개 나온다. (어제는 ALB, Nginx만 고려해봤지만, API Gateway도 올 수 있다는 것을 회의중에 알게 되었다.)ALB, Nginx, API Gatewa

Copilot 사용 살펴보기git 레포지토리 생성 및 브랜치 설정공통 모듈에 들어갈 의존성 이야기하기IDE 코드 포매팅 설정각 서비스의 포트 번호 공유프론트엔드에서 body에 success 필드로 boolean 값을 주어서 굳이 header를 파악하지 않고 성공 여부에

가장 가까운 같은 글자 (앞에 있는) 가장 가까운 같은 글자 데이터베이스 마이그레이션 분리되어있는 여러 서비스가 하나의 DB를 바라볼 때: 우리는 비용문제로 인해 각 서비스에 DB를 두지 않고, 학습하는 과정에서 하나의 DB인스턴스를 통해 MSA 애플리케이션을 운영(

시간과 관련된 Audit는 서비스 내부에서 처리할 수 있지만,Gateway로부터 받아온 헤더 정보를 통해 현재 로그인한 정보를 받아와야했다.그래서 어떡하지..? 하다가 임시로 빈 값을 넣도록 설정하고게이트웨이가 헤더를 넣어주는 기능을 구현 한 뒤,유저 서비스를 게이트웨

GW - 인증 필터 구현 jjwt 의존성 추가 유지보수가 쉽도록 변수로 버전을 관리 JwtClaims JwtTokenProvider application.yml 현재는 설명을 위해 디폴트 값을 주었지만 이럴 경우 application-dev.yml에만 적용해야

🎓 OAuth 2.0 표준 형식표준을 따르면클라이언트 라이브러리 호환이 쉽다. (axios interceptor 등 자동 인식)추후 RefreshToken 추가 시 OAuth 2.0로 쉽게 확장할 수 있다.표준은 snake_case(access_token) 이지만,서

조회 (CQRS + Query DSL) 이전 프로젝트에서와 마찬가지로, CQRS 스타일로 조회를 분리해 구현하기로 했다. (DB는 동일) 대신 이번에는 동작 원리를 확실히 이해하고 넘어가려고 한다. (CQRS) 왜 분리하나? 읽기는 @Transactional(re

조회 구현에서 권한 작업을 하고 나니 수정 구현도 동일하게 권한을 위주로 생각해보게 되었다.닉네임 변경과 같은 경우, 사용자의 악의적 변경을 막기 위해 30일에 한 번만 변경할 수 있는 로직이 추가될 수 있다.이 로직을 구현하려면 닉네임 변경 이력 시간을 관리해야 하는

이벤트 발행: 상태와 행위 사이의 고민 API 구현이 마무리되어가면서 UserCreated, UserUpdated, UserWithdraw 이벤트 발행 로직을 추가해야 했다. 통계 테이블에 주로 사용될 Created와 Withdraw 같은 경우 식별자인 UserId만

최종 시연을 준비하면서 관리자 권한의 시나리오를 추가하게 되었는데, 갑자기 원래 기대하던 응답이 나타나지 않아 의아했다.문제는 올바른 토큰을 주었음에도 권한 인증 처리가 안된 것이었는데, 원인은 게이트웨이에서 해당 경로를 public path로 취급해 인증 검증 필터를

다시 학습하기 일단 Outbox 테이블을 만들고, 도메인 이벤트를 발행하고 이 이벤트에 발행에 대해 Outbox로 영속 저장을 해서 이벤트 처리가 중간에 실패하더라도 서비스에서 이벤트가 전달되어 정합성을 보장한다는 것은 알았는데, 빠르게 구현하느라 구현의 세부적인 내용

나는 OutBox 패턴을 적용하면서 kafka 직렬화 대신 ObjectMapper를 통해 이미 직렬화 된 객체를 Outbox에 넣고 나서 kafka 이벤트를 발행했다.결과적으로 이벤트 생성을 나타내는 OccuredAt이 ISO8601 방식으로 직렬화됐다.TypeId 헤

Outbox가 BaseEntity를 상속 받는것이 맞는가? 이벤트 발행과 Outbox에 대한 이해가 크지 않은 상태에서 구현을 했더니 이벤트 발행 실패 재처리를 위해서 row가 수정되는 값이라고 생각되어 BaseEntity를 상속받게 했는데, 이벤트 발행 로직을 리펙토링하며 보니, 다음처럼 테이블에 쓸데없는 정보가 저장되고있는 것 같았다. 이벤트 발행의...

배열의 'a' 의 앞 공간 (0~96) 은 낭비되지만 인덱스 매핑 연산을 피할 수 있다.

오늘부터 부트캠프과정이 2주일밖에 남지 않았다. (주 5일이니까 딱 10일!)그래서 오늘부터는 과정 마무리에 집중하면서 매일 9시까지 빠이팅🙌(🤦🏻‍♀️)하지만 StringBuilder.insert()를 반복해서 사용하면 시간 복잡도가 오히려 증가한다.문자열 중간

RTR, 화이트리스트 구현 몬가... 몬가 처음부터 다시 하는 느낌인데... 낡고 지치고 말아...😂 JWT + 블랙리스트 방식 어제 토큰기반 인증 방식을 세션 방식과 비교하면서 "이미 발급된 토큰에 대해 즉각적인 제어를 할 수 없다"는 토큰기반 인증방식의 허점을 보완하기 위해, 블랙리스트와 화이트리스트 도입을 생각해 문서를 작성해 팀에 공유했었다. ...