바우처 과제를 하면서 테스트 때문에 눈물나는 일이 많다.동료들도 그렇고 멘토님도 그렇고 테스트에 대해서 많은 관심을 가지고 시행착오를 겪는 모양이다.동료 중에 테스트 코드 작성하기 전에 보면 좋을 것 같다고 공유한 블로그가 있다. 잘 정리해서 알차게 써먹고 싶어서 요약
빡세게 과제 중이던 오후슬랙에 멘토님의 함성이 들렸다. 이거 왜 컴파일 에러가 날까요??ㅠ나는 당최 모르쇠였는데 팀원 중에 한 분이 좋은 정보를 들고 오셔서 이걸 정리해본다.먼 훗날 같은 이유로 컴파일 오류가 날 때내 소중한 하루를 지켜줄 치트키가 되기를 바란다.Gen
URL의 Collection, ElementRESTful 한 API일련 특징, 규칙 지키는 API 지칭왜 필요할까?독립적 진화서버, 클라이언트가 독립적으로 진화서버 기능 변경 ←X→ 클라 기능 변경독립적 인터페이스REST 시작 계기가 웹을 쪼개기 위함어떻게 unifor
재고량을 감소시키는 메소드를 여러 스레드(요청)에서 동시에 접근하게 된다면?재고량 감소 = select + decrease + update한 스레드가 select 하고 update 하기 전, 다른 스레드에서 select 를 하게 되어 동시성 문제 발생메소드에 synch
좋은 테스트란 무엇일까?정답은 없다.다만, 좋은 테스트로 느껴지는 코드가 공유하는 몇 가지 특성이 있다. FISRT 속성은 그런 편-안한 테스트가 갖는 공통 특성이다.FastIsolatedRepeatableSelf-validatingTimely빠른 테스트외부시스템(DB
팀플 MVP를 모두 구현 완료한 시점에서 해야할 것은 명확했다.리팩토링성능 개선기능 추가일단 리팩토링으로 꼴보기 싫은 코드를 모두 새로 맞춰놓고, 성능 개선을 하기로 했다.성능 개선을 위해서 정량 지표를 얻어 비교하는 과정이 필요했다.막막하던 차에 그라파나, 프로메테우
💡 인덱스는 검색을 위해 나머지를 희생하는 것어디선 쓰지마라, 어디선 왜 안 썼냐.이제 인덱스 고민은 그만!MySQL의 인덱스를 바탕으로 알고리즘과 인덱스 활용을 알아보며, 코드에 녹여봅시다.인덱스가 검색에 좋은 이유를 알아보려면 우선 I/O 방식에 대해서 간단히 알
트랜잭션들이 동시에 수행될 때 일관성을 해치지 않도록 데이터 접근을 제어하는 DBMS 기능같은 데이터에 다른 Read / Write 가 있다면 예상치 못한 동작 가능성DB에서 활용 가능한 동시성 제어 기술 = LockNonSerializable같은 데이터에 대한 여러
DBMS가 다수의 사용자 사이에서 동시에 작용하는 다중 트랜잭션 상호간섭 작용에서 Database 를 보호하는 것락 기반 동시성 제어는 읽기 트랜잭션 끼리만 동시 접근 가능UntitledMVCC 를 사용하면 동시성 제어가 읽기 ↔ 쓰기 트랜잭션 동시 접근 가능쓰기 트랜
프로세스/스레드가 동시에 같은 데이터 조작 시 타이밍, 접근 순서에 따라 결과가 달라지는 현상프로세스/스레드를 동시 실행해도 공유 데이터 일관성 유지공유데이터 일관성 보장위해 하나의 프로세스/스레드만 진입해서 실행 가능한 영역 (mutual exclusion)mutua
mutual exclusion 보장조건 따라 스레드 대기 상태 전환 기능 제공한번에 하나의 스레드만 실행해야 할 때여러 스레드와 협업 필요할 때!\[Pasted image 20240117181942.png]critical section 내 mutual exclusion
팀프로젝트에서 JWT 를 이용해 인증 기능을 구현했다.지난번 \[카페인 캐시와 캐시 추상화] 포스팅은 JWT 관리를 로컬 캐시에서 처리하는 내용을 다뤘다.이번 포스팅에서는 로그인, 토큰 갱신, 로그아웃, 회원탈퇴 같은 인증 관련 기능을 다룰 예정이다.회원탈퇴 기능을 구
🎯 사건의 발단 Docker Compose 를 활용해서 서비스 아키텍처를 구성하는 과정에서 발생한 문제다. 결론부터 말하자면, > docker compose 의 depends_on 속성 만으로는 컨테이너 간 의존성을 만족할 수 없다. 🔍 톺아보기 Docker
저번 Docker Compose 포스팅 2편이다.글 쓴 목적은 두 가지.Docker Compose 써야할 이유를 보강해왔다DB 컨테이너랑 Server 컨테이너랑 실행 시점 함정 해결법을 보강해왔다Flyway 적용한 걸 보여주고 싶었다한마디로, 도커를 써야하는 명분작을
첫 직장 다닐때 우리팀은 CI는 커녕 테스트 코드도 안 만들고 작업을 했었다.그때를 생각하면 도대체 어떻게 굴러갔던건지 이해가 안 된다.애초에 개발을 하고 개발자가 직접 테스트를 하던가, 아니면 QA 분들이 엄청 고생했겠지.심지어 제대로 동작하지 않는 코드 머지해서 한