오늘은 게시판 객체 간의 구조 설계를 위해 @ManyToOne과 @OneToMany에 대해서 공부했다. 현재 진행 중인 게시판 프로젝트를 예시로 User(사용자)가 1개 이상의 Post(게시글)을 작성할 수 있기 때문에 아래처럼 테이블 구조를 설계했다. 우선 간단하게 OneToMany와 ManyToOne을 먼저 맛보면 아래 구조에서 User 입장에서는 @OneToMany이고 Post입장에서는 @ManyToOne이다. 우선 두 객체를 연결하기 위해서 Pos 객체에 User 객체를 만들고, User 객체에는 User가 쓴 글 모두를 담을 수 있는 List타입의 posts를 만들었다. Post객체에 User에는 @ManyToOne 붙여주고 User객체에 Post List에는 @OneToMany를 붙여주었다. ..

이번 주 스프린트의 핵심 게시글 작성할 때 이미지 업로드하는 기능을 오늘 구현했다. 어제 AWS 가입이 되지 않아 S3를 이용해 이미지를 업로드하는 것을 포기하려 했지만 오늘 일어나서 메일함을 보니 어제 그렇게 기다리던 가입 완료 메일이 새벽 5시에 정상적으로 도착한 것을 확인할 수 있었다. S3를 이용해서 이미지 업로드할 수 있다는 기쁨을 느꼈다. (이미지 업로드를 위해 수많은 삽질을 할 나의 미래를 모른 채..) 게시글에 이미지 업로드를 위한 spring에 AWS S3 연동방법 1. AWS S3 버킷 생성하기 S3 서비스로 이동 후 버킷 만들기로 이동한다. 그다음 버킷 이름(소문자)을 입력한다. 모든 퍼블릭 액세스 차단 체크를 풀어준 다음 밑에 두 개만 다시 체크해준다. 첫 번째 새 ACL(액세스 제..

게시글 상세 페이지 구현중 보여야 하는 정보들을 나열해 보는데 게시글의 조회수가 필요했기 때문에 조회수 기능을 구현해보기로 했다. 처음에는 조회수 기능을 어떻게 구현해야 하지 막막했었는데 생각보다 간단하게 구현할 수 있었다. 조회수 기능 구현 과정 1. Post Entity 조회수를 위한 hit를 Long 타입으로 설정해주었다. 처음에는 조회수를 나타내는 건 자연수이기 때문에 int타입을 사용했었는데 생각해보니 id값도 자연수인데 Long타입을 사용하고 있었다. 원시 타입이 아닌 참조 타입을 사용하는 이유는 null값을 담기 위해서이다. 원시 타입인 int를 사용하면 값이 없을 때 0이 설정된다. 반면에 참조 타입인 Long은 값이 없으면 null을 담는다. 만일 값이 없을 때 0을 담게 되면 값이 들어..

오늘은 글 작성 기능 구현을 목표로 작업 설계를 시작했다. 글 쓰기에 대한 인수 테스트 작성부터 하고 useForm을 이용해서 글 작성 폼을 만드는 것을 먼저 하는 것으로 순서를 잡았다. 글 작성시작성 시 기본적으로 필요한 내용으로는 글 제목, 글 내용, 카테고리 선택 그리고 사진은 선택사항으로 계획했고 글 작성 페이지의 URI는 write로 정했다. 그래서 REST API 설계 시에도 게시글 작성 시 URI를 POST /write로 정했었다. 그런데 REST API 설계 시에 규칙이 있다는 것을 알게 되었고, 내가 사용한 write가 동사형태라 설계 규칙에 위반되었기 때문에 /post로 바꿔야 했다. REST API URI설계시 유의할 점 URI는 정보의 resource(자원)를 표현해야 한다. 1. ..

작업설계 어제 프론트엔드 세팅을 끝냈기 때문에 오늘 시작을 백엔드를 세팅하는 작업으로 하루를 시작했다. 작업을 시작하기 전에 설계를 먼저 하는 원칙이 있었기 때문에 세팅하는 작업도 먼저 간단하게 설계(?) 아닌 설계를 먼저 해봤다. 우선 기본적으로 강의에서 배웠던 것을 떠올리며 7가지 dependencies를 추가해주고 스프링이 제공해주는 security도 사용하지 않을 거라 로그인 폼을 막는 세팅도 해줘야 한다. 아무튼 백엔드 세팅을 스토리 포인트로 2 뽀모로 잡았는데 1뽀모하고 조금 지나서 기본 세팅을 다 끝낼 수 있었다. 이제 본격적인 작업이 시작하는데 맨 처음 구현해야 할 기능이 전체 게시판(홈 화면)을 읽을 수 있도록 하는 것이었다. 역시 이 작업도 시작하기 전에 설계를 먼저 했다. 일단 전체 ..

어제 피드백을 받고 수정한 기획안을 바탕으로 다음 스프린트(다음 주 월)까지 구현해야 할 기능 리스트와 얼마 큼의 시간을 투자하고 구현할 수 있는지 스토리 포인트를 매겨보는 시간을 가졌다. 다음 주 스프린트까지 구현해야 할 기능을 정하는데 내 서비스 중에서 가장 핵심 기능부터 구현해야 했다. 그래서 커뮤니티 서비스의 핵심이 게시글을 읽고 쓰는 것이라 생각해서 게시물을 읽는 것을 가장 먼저 구현해야 할 기능으로 잡았다. 그리고 해당 기능의 스토리 포인트 점수를 매기는데 스토리 포인트 점수를 매기는 기준을 1 뽀모(40분/10분/10분)를 이용해서 잡았는데 생각보다 기능 하나를 구현할 때 몇 뽀모가 필요한지 측정하기가 쉽지 않았다. 기능 하나를 대강 기준을 잡고 그 기준을 이용해 다른 기능들을 구현하는데 상..