TIL

오늘은 Git-Kraken 을 활용하여 어제 역할을 분담한 대로 각자 개발을 시작해나갔다.ERD와 API명세를 세세히 적어둔 덕에 Entity 나 DTO 를 작성하는 시간도 금방이었고, Controller 와 Service 구현도 기억을 더듬어가며. 모르는 부분은 찾아

소수 만들기문제 설명주어진 숫자 중 3개의 수를 더했을 때 소수가 되는 경우의 개수를 구하려고 합니다. 숫자들이 들어있는 배열 nums가 매개변수로 주어질 때, nums에 있는 숫자들 중 서로 다른 3개를 골라 더했을 때 소수가 되는 경우의 개수를 return 하도록

오늘은 Request 값을 제한하기 위한 예외처리 InputLengthException 을 만들었다. Service 에서 예외처리 조건문을 작성하고 잘못 입렬된 경우 throw 로 에러를 발생시키도록 하였다.제대로 에러메세지를 출력해주는 것을 확인하고 이제 Update

주요 기능의 구현을 마치고, 안정성을 높이기 위해 예외처리의 방법에 대해 더 공부하는 시간을 가져보았다. 현재 우리 팀의 프로젝트에서는 Service에서 request의 값이 유효한 값인지 확인하고 예외 발생시키는 방법으로 예외처리를 하고 있었다. 단순하게 보면 제

AOP란 Aspect-Oriented Programming 으로 "관점 지향 프로그래밍"으로 번역된다.핵심 로직과 부가기능을 분리하고, 부가기능을 모듈화 하여 재사용할 수 있도록 하는 프로그래밍 패러다임.핵심은 Cross-Cutting 으로, 객체지향 관점에선 하나의

Spring Security 를 학습하던 중 PasswordEncoder 인터페이스를 구현하고 @Bean 객체로 등록하는 과정이 잘 이해가 되지 않아 과정을 분석하고 정리한 내용을 작성해 보았다.스프링에서는 어떤 객체를 사용할 때 마다 생성하지 않고, @Bean으로 스

Spring Security 를 공부하면서 이를 구현하기 위해 용어와 인터페이스, 클래스를 정리하고, 각 기능을 요약해보려고 한다.Json Web Token 의 줄임말로, 사용자의 인증정보를 문자열로 구성된 "토큰" 으로 만들어 헤더에 전송하고, 받는 측에선 이를 분해

인증/인가 를 중점으로 일반 유저와 관리자의 역할을 구분하고 처리할 수 있도록 기능을 구현해보는 프로젝트이다.우리 팀은 커뮤니티 사이트에서 관리자의 인가를 받아 게시판을 생성하고, 사용자들이 게시글과 댓글을 남길 수 있는 페이지를 기획하고 구현해보기로 하였다.ERD를

내가 담당한 User 와 Board 의 기본 CRUD 를 구현한 뒤 필수 요구사항 중 하나를 구현해보기 위한 과정을 기록해보려 한다.사용자가 비밀번호를 변경할 때 최근 비밀번호 (3개) 와 겹치지 않는 지 확인.비밀번호 변경시 변경한 비밀번호를 저장하고, 오래된 비밀번

팀원들과 공용 DB에 작업하기 전, 개인적으로 API 를 테스트 해보기 위해 H2 CONSOLE 을 사용하고 있었다.어제 저녁부터 작업에 들어간 SpringSecurity 의 기능이 어느정도 구현되고, 테스트를 위해 h2 console 에 접근하려는데 어라..? 왜 순

게시판을 관리하는 백오피스 프로젝트를 진행하며 데이터의 삭제에 대한 고민을 했었는데, 실무에서 데이터 = 회사의 자산이기 때문에 삭제에 대해 엄청나게 보수적이라는 말을 들었다. 그래서 보통 Soft-delete 방식으로 데이터를 삭제 '처리' 한다고 한다.지난 News

지난 작업에서 SoftDelete 를 구현하기 위해 각 객체들에 isDeleted = boolean 항목을 추가했었고, 해당 값만 true 로 저장하여 삭제를 구현했었다. 하지만 이 객체와 1:N 관계에 있는 객체들의 isDeleted 도 true 로 바꿔주어야 하는데

아래의 두 포스트와 연결되는 내용https://velog.io/@jangcoding/Spring-DI%EC%9D%84-%EC%9C%84%ED%95%B4-interface%EB%A5%BC-%EA%B5%AC%ED%98%84%ED%95%98%EA%B3%A0Bean%

Spring 에서 DB와 연동하여 사용해야 할 때 Repository 를 만들고, JPA 를 상속받도록 하여 JPA 가 기본적으로 제공하는 메서드를 사용할 수 있도록 한다. JPA의 메서드 명명 규칙에 따라 find, remove, delete 등의 메서드를 자유롭게

지난 프로젝트에서 어떤 객체를 생성할 때 생성일과 수정일의 기록을 남겨두는 것도 중요한 데이터가 될 수 있으니 createdAt 과 modifiedAt을 구현해볼 것을 피드백 받았었다.그땐 단순히 생성할 때, 업데이트될 때 마다 아래와 같은 방법으로 값을 지정해주었었다

이전 포스트에서 Auditing 기능을 활용하여 생성일자와 수정일자를 자동으로 지정하는 BaseEntity 를 생성하고 이를 다른 Entity 에서 상속받아 사용할 수 있도록 하였다. 여기에 추가로 @CreatedBy 와 @LastModifiedBy 를 통해 생성한 사

gg

테스트 코드란 ? 그동안 각종 Service 와 메서드를 구현하면서 예상대로 동작하는지 확인해보기 위해 수없이 테스트를 해왔다. 하지만 매번 실행해보면서 결과를 눈으로 확인하여 해석하고, 다른 값을 넣고 다시 빌드하는 것은 번거롭기도 하고 귀찮기도 하기 때문에 점점

이번엔 팀원들과 함께 대용량 트래픽 관리 프로젝트를 진행해보기로 하였다.137,000 여 건의 데이터가 저장되어있는 csv 파일로부터 값을 받아와 DB에 업로드하고, 필터 기능과 Pageable 기반으로 값을 불러오는 작업을 해볼 예정이다.대상이 되는 자료는 서울시 인

이번 프로젝트에서 다룰 Entity 는 서울시의 인터넷 쇼핑몰 업체에 대한 정보를 담고 있는데, 생각보다 필드가 너무나 많고 일반적인 상황에선 필요하지 않은 정보들도 너무 많이 포함되어 있었다. 매번 이런 정보들까지 포함하여 호출하는 것이 비효율적이라고 판단되어 처음

Cache 란? 데이터나 정보를 빠르게 접근할 수 있도록 메모리에 저장하는 임시저장소 네트워크를 통해 DB 에 접속하여 값을 가져오는 것보다 메모리에 미리 저장해둔 값을 반환하면 응답 시간을 줄이고 성능을 향상시킬 수 있다! ( 별도의 쿼리문도 생성하지 않는다! )

Cache 란? 데이터나 정보를 빠르게 접근할 수 있도록 메모리에 저장하는 임시저장소 네트워크를 통해 DB 에 접속하여 값을 가져오는 것보다 메모리에 미리 저장해둔 값을 반환하면 응답 시간을 줄이고 성능을 향상시킬 수 있다! ( 별도의 쿼리문도 생성하지 않는다! )

이번 프로젝트는 그동안 공부해본 기능들을 종합하여 가능한 완성도 높은 프로젝트를 개발해보기 위해 차근차근 기획을 시작해보았다.이번에는 특이하게 각자 관심 있는 부분이나 구현해보고 싶은 내용을 먼저 이야기해보고, 이를 적용해볼 수 있는 프로젝트를 구상해보는 것으로 시작해

맨 처음 티켓팅을 주제로 잡고, 필요한 구성요소들을 생각했을 때 크게 네 가지로 나뉘었었다.유저 / 이벤트 / 티켓 / 리뷰유저나 리뷰는 자주 다뤘던 내용이라 금방 넘어갔지만, 공연과 티켓에 어떤 내용을 담을 것인지, 어떻게 설정할 것인지에 대한 회의가 계속 되었다.카

어떤 이벤트(공연)에 대해 사람들의 선호도를 확인하고, 인기 이벤트를 기록하기 위해 좋아요 기능을 구현하기로 했다. 기능 자체는 아주 간단한 것 같다. 좋아요를 누르면 True 다시 누르면 False 만 하면 되는거 아닌가?

@Cacheable self-invocation (in effect, a method within the target object calling another method of the target object). The cache annotation will be ig

직렬화(Serialization)와 역직렬화(Deserialization)는 객체를 데이터로 변환하고, 다시 데이터를 객체로 변환하는 과정을 의미한다. 주로 네트워크 통신이나 파일 저장 등에서 객체를 전송하거나 저장할 때 사용된다. 직렬화(Serialization)

캐싱할때 entity 바로쓰지말고 dto 쓰자

@Cacheable 어노테이션을 사용하면 아주 간단하게 캐싱을 구현할 수 있었다. 스프링부트가 자동으로 메서드를 호출할 때의 인자를 확인하여 지정한 키로 캐시를 확인해주기 때문이다. 하지만 이 방법은 메서드 자체에 자동으로 설정되기 때문에 내가 원하는 시점, 원하는

지난 포스트에서 @Cachable어노테이션 없이 Cache등록하기를 사용해보았고, 캐시의 적중 여부에 따라 Boolean 형태로 응답하는 과정을 구현해 보았다. 이번엔 적중 여부에 따라 실제 저장된 값을 가져와 반환하도록 하는 기능을 구현해보자.

이번 프로젝트에서 가장 핵심이 되는 부분을 꼽자면 바로 티켓 예매 메서드라고 할 수 있다. 단순히 티켓 필드를 하나 추가하면 되는 것이 아니라, 동시성 제어, 캐싱, 정합성 검사 등의 과정이 여럿 포함되기 때문이다. 설명에 들어가기 전, 간략히 내용을 요약하자면 아

3주정도의 개발기간이 지나고, PPT로 정리하며 다시 한번 작업물과 앞으로의 일정을 점검해보는 중간발표 시간을 갖기로 하였다.사실 처음 프로젝트명은 티켓을 쟁취하기위해 돌격하는 TicketRaider 로 지었었는데 같은 발음의 TicketRadar 도 티켓팅과 어울리는

Vue 에서 로그인을 이야기하기 전 Spring 에서 어떻게 로그인을 구현해두었는지 먼저 살펴보자면