@Id 설정과 @GeneratedValue를 작성하다보니 auto_increment에 대해서 더 자세하게 알고 싶어져서 작성하게 되었다.확인을 하다가 mysql 과 postgresql 작동 방법이 다르다는 것을 알게 되었고추가적으로 auto_increment를비슷하게

stash: 감추다, 숨겨두다.branch를 사용하여 작업을 하다보면 다른 브랜치로 checkout을 해야하는 상황이 발생이때까지 작업한 내용물을 미완성인 상태로 커밋을 하기에도 혹은 어딘가에 복사해 놓기에도 애매하다.그래서 git stash 를 사용할 수 있다.git

하계 현장실습을 SI업체에서 하던 도중단위 테스트를 받게 되었는데알 던 단위테스트와 상이한 부분들이 있고단위테스트가 아니고 다른 테스트 인 것 같아 한번 실무의 테스트를 유형을 찾아보고 정확한 개념을 잡고 가려고 적게되었다.(왜 단위테스트라고 한건진 의문.... 디자이

나는 이전 프로젝트에서 이메일 인증 시 redis 를 사용하고 최근 우아한 redis 를 보면서 Redis에 관한 공부를 하였다.그래서 Redis를 이번 토이프로젝트에 적용해보고 싶었는데 하계 인턴을 같이하는 팀원은 Redis를 처음 접해본다고 하여 바로 PPT를 만들

협업을 다시 진행하면서 팀 컨벤션을 일치시키려고 노력한다.자유 분방하게 작성하여 여러명이 작성한 것이 티나는(?) 과거의 버릇을 고치고 후에 봐도 무슨 코드를 작성했는지 알 수 있도록 틀을 정하고 있었다.하지만 Git 브랜치 규칙에서 해당 규칙을 추가하니 본래 뜨던

InnoDB는 기본적으로 트랜잭션을 관리한다.동시성과 일관성을 보장 default 값으로 repeatable Read 방식으로 커밋된 데이터만 읽는다.InnoDB 는 모든 바이너리 배포판에 default 로 포함되어 있다.트랜잭션 처리가 필요하다.이후 살펴볼 MyISA

최근에 테스트 코드 작성 문화를 손에 익을려고 노력하고 있었다.하나의 테스트 코드에는 하나의 검사만 해야한다 등 통일하면 좋은 요소들이 있는 것 같아 이번 기회에 더 나은 테스트 코드를 작성하고자 공부를 하였다.테스트는 유연성, 유지 보수성, 재사용성을 제공한다.테스트

객체를 생성해서 카프카에 보내는 것은 잘되지만 객체를 받아오는 과정에서 문제가 발생하였다.2023-05-14T16:48:02.653+09:00 ERROR 39835 --- \[ntainer그래서 검색을 해서 찾아보니 직렬화와 역직렬화를 하는 과정에서직렬화, 역직렬화 과

현재 팀원이 refactoring을 거친 상품 상세 페이지의 커밋된 코드를 보다가 생각하게되었다.추가로 현재 로직에서의 Entity 조회와 Dto조회에 대해서 고민을 하다가 작성을 한다.(JPA 2편에서는 선 Entity를 추천했지만 우아한 테크에서는 조회시에는 Dto

현재 상황은 상품 상제 조회할때 쿼리가 10개가 나갔다.그리고 한번의 최적화 후 4개로 줄어들었다.1\. item view 증가를 위해 itemId를 통한 item 탐색update 문dto 조회문 item url 조회문 그리고 현재 Repository 하나의 메소드에서

상품 상세 페이지 조회를 짜던 팀원이 좋아요 여부를 Long likeMemberId 로 넘기는 코드를 보았다.또한 상세페이지 한번에 10개의 쿼리문이 나가는 현상을 발견해서 다른 팀원이 issue로 올렸다.바로 물어 보았다.Coodori: 혹시 likeMemberId

2022 KAKAO BLIND RECRUITMENT - 양궁대회 https://school.programmers.co.kr/learn/courses/30/lessons/92342일단 문제의 어휘가 조금 애매한 부분이 많았던 문제였다.라이언이 가장 큰 점수 차이

문제https://school.programmers.co.kr/learn/courses/30/lessons/92341구현, 문자열 파싱 문제였다. 풀이 방법 자체는 문제를 읽으면서 빠르게 생각났고 문제 자체에서 연산하는 방법도 명확하게 표현되어있어 그대로 구현

수상한 녀석을 발견 일본을 4박 5일 다녀온 이후 밀렸던 코드 PR을 확인했다. 그 코드 리뷰하면서 몰랐던 것이나 다르게 작성해야하는 코드 몇개를 발견하였다. 그래서 공부를 하면서 정리를 하려고 한다. OncePerRequestFilter란? 흔히 Filter 와

문제 발생 해당 시리즈 10번에 글을 썼지만 조금 부족하다는 느낌이 들어서 새롭게 정리를 하려고한다. 크게 3가지를 보려고하는데 통합테스트와 단위테스트의 차이 TDD와 BDD의 차이 Mockito 와 BDDMockito 차이(추가 사용법) 이렇게가 앞으로 내가 테

팀원에게 코드리뷰를 하던 도중평소에 나는 리포지토리 인터페이스를 작성할때 Jpa Repostiory 와 CustomRepository(Querydsl)을 사용하기위해 두가지를 상속 받았다.하지만 처음보는QuerydslPredicateExecutor 를 발견하게되었고 팀

일단 테이블과 자바의 클래스를 연결해주는 어노테이션이다.근데 최근 어노테이션 기능에 대해서 전체적으로 다시 공부해보는 중인데 신기한 사실을 발견하고 주의할 점이 있을 듯하여작성을 해보려고한다!기본 생성자는 필수다(파라미터가 없는 public 또는 protected 생성

@RequestBody로 받아오는 Dto에서 바인딩되지 않는 오류가 발생하였다.현재 Dto는 모두 @Data처리가 되어있다.하지만 왜 우리의 Dto에 바인딩이 되지 않을까? 일단 내가 알고있는 지식으로 저번 편에 이어 JAVA객체가 JSON으로 변환될때는 JACKSON

기존 코드빈 값에 대한 validation@NotNull: 제한된 CharSequence , Collection , Map 또는 Array 는 null이 아닌 한 유효하지만 비어 있을 수 있습니다.@NotEmpty: 제한된 CharSequence , Collection

에러가 나진 않지만 매우매우 불편한 로그가 나를 반겼다.대충 읽어보면 2023-04-02T18:00:14.921+09:00 INFO 52154 --- \[ restartedMain] .RepositoryConfigurationExtensionSupport : Spr