영화 사이트 제작

이전 학교에서 진행한 부트캠프에 참여한 후 내가 이전에 만들었던 영화 예매사이트가 얼마나 개판인지를 알게되었다...전혀 객체지향적이지 않고 restful하지도 않으며 기능을 거의 혼자 개발하다보니 로컬db, 로컬 스토리지 사용등 협업에도 좋지 않은 환경으로 구성이된 프

우리가 이용하기로 한 개발환경은AWS RDSAWS S3AWS EC2DOCKERGITNOTION등이며 개발환경 세팅을 내가 담당하게 되어 하나하나 세팅을 진행해주었다.우선 데이터베이스를 저장할 aws rds를 만들어주었다.I. 공용 데이터베이스 사용변경사항을 즉시, 자동

1차 개발환경 세팅후 팀원분과 각자 맡은 파트에 개발 시작전 시퀀스 다이어그램과 api명세를 작성하기로 하였다. 자세한 로직은 블랙박스 처리를 하고 최대한 간결하게 그려보았다.그리고 위의 시퀀스 다이어그램을 참고하며 api명세 또한 작성을 하였다나중에 프론트 부분을 작

저번의 시퀀스, api명세에 이어 오늘은 회원가입 api를 개발해보았다. 📌 로직과 명세 먼저 회원가입 api의 블랙박스 시퀀스 다이어그램을 작성해주었다. 클라이언트가 회원가입 정보를 전송함 dto로 랩핑하여 서비스 레이어에 전달 서비스 레이어에서 중복 검사

오늘의 작업 목록:1\. 회원 정보 단건조회(내 정보 확인)2\. 회원 정보 수정(비밀번호, 휴대폰 번호)저번의 회원가입에 이어 이번엔 회원정보 조회 api를 만들어봤다.먼저 시퀀스 다이어그램을 먼저 그려주었다.로그인된 유저의 Id값을 전송하는것을 가정하였고 로그인된

이번에 만든 기능은 회원탈퇴 기능 + 회원 데이터 백업 기능이다.데이터 백업의 경우 관리자의 실수로 인한 삭제 및 혹여나 회원정보가 필요할 경우를 대비해 데이터를 보관한다는 가정을 하여 구현했다.회원 데이터의 id로 삭제 요청을 하고 데이터베이스에서는 회원정보를 백업후

원래는 회원의 아이디, 비밀번호 찾기를 개발할 예정이었으나 인증번호 확인후 아이디 출력등 프론트 파트에서 작성해야하는 부분들이 있다.팀원분의 리뷰 기능 개발에 실제 영화 데이터가 있으면 좋겠다는 말씀위 두가지 이유로 영화 관련 기능을 먼저 개발하기로 결정했다.왓챠피디아

영화 데이터 create 기능을 구현하려는데 영화에 대한 기본 정보 외에포스터 이미지와 프리뷰 이미지를 등록하는 기능을 만들려고 한다.파일 저장소는 경제, 편의의 이유로 aws s3를 선택했다우선 이미지 파일들을 담을 aws s3 버킷을 먼저 생성해주었다설정의 경우 리

📌 문제 상황 이미지 파일의 경로가 길어서 에러가 발생함 영화 줄거리 길이가 길면 에러가 발생 영화 장르를 어떻게 처리할지 결정해야함 나머지 Api 개발전 영화 정보 등록 api를 테스트하던중 1, 2번 문제가 발생을 하였고 그리고 장르별 조회를 구현하기위해 3번

더미데이터로 영화 데이터 조회 테스트를 완료했으나 실제 영화 데이터를 넣어서 테스트하고 싶음직접 등록하려니 너무 시간이 많이 소비됨 한 1년전쯤 했던 데이터 크롤링을 해보기로함이용툴 : Colab언어 : python라이브러리 : requests, BeautifulSou

이번에는 영화 데이터의 조회 기능 API들을 개발해보았다.전체 조회(페이지네이션을 이용한), 장르별 조회, 상세조회(단건 조회) 세가지 조회 api로 나누어서 개발을 하게 되었다.페이지네이션 조회장르별 조회상세 조회페이지네이션 조회장르별 조회상세 조회I. 페이지네이션

문제상황: RDS의 리전을 버지니아 북부로 설정을 해놓은 상태로 작업시 계속 리전을 변경하면서 작업을 해야하는 편의성 문제와 쿼리문의 실행시간 단축을 기대하며 RDS의 리전을 서울로 변경하기로 하였다. 📌 리전 변경 과정 1. 스냅샷 생성 기존의 RDS를 복사해서

문제 상황: 나의 코드외의 팀원분의 코드들을 직접 병합하고 테스트하기가 번거로워졌음\-> 팀원분께서도 병합을 하시게하되 테스트를 자동화 할 수 있게해보자는 생각\-> CI(지속적인 통합)을 구현하자라는 생각으로 CI를 구축해보기로 했다.CI/CD에 구축에 이용툴이 주로

CI를 설정한데에 이어서 CD 환경을 만들기전 수동 배포를 먼저 진행해보았다.로컬에서 jar 파일을 추출 도커로 jar 파일을 이미지화 도커 허브에 push EC2 서버에서 pull하여 실행 위의 4단계를 생각하고 배포를 실행해보았다.tool window의 gradle

이전 포스팅이전 포스팅의 테스트이후 깃액션, 도커를 이용해 EC2 서버에 자동으로 배포를 진행하는 환경을 구성해보았다.CD라 거창해보일수 있지만 이전에 했던 수동 배포를 workflows를 작성하여 배포과정을 자동화 해주는 단계이다1\. 깃허브 레포지토리에서 지속적인

상영일정의 설계는 CGV를 참고해서 진행했다.상영관(ex. 3관)에 소속되며 날짜와 분단위까지 24시간제로 저장되고 현재 남은 좌석수가 출력된다. 실제 영화관을 가정하여 설계하려함영화관이 아닌 상영관에 소속됨 영화관 <- 상영관 <- 상영 일정 이런 모양으로

이전글에서 작성한 엔티티 설계대로 엔티티를 작성하고API 명세대로 기능 구현을 하였다.여러 상영일정이 하나의 상영관, 영화를 참조하므로 @ManyToOne으로 관계를정의하였다.그리고 최적화를 위해 FetchType.LAZY 옵션으로 지연로딩 설정을 걸어주었다.그리고 상

실질적인 판매 상품이 되는 영화관 좌석에 대한 테이블 설계와API의 시퀀스 다이어그램을 작성하였다.위에부터 차례로 설명을 하면테이블의 기본키상영일정 <- 좌석 의 참조관계를 맺는 외래키좌석의 행 좌석의 열좌석 가격예매 가능 여부판매 상태 여부와 생성, 수정시간으로

이전 포스트에서 설계한대로 좌석 엔티티와 API의 실제 구현을 하였다.설계에 변경사항 없이 그대로 적용했으며 생성자에서예매가능 여부와 판매 상태를 지정 해주도록 했다.다른 사람의 이해를 돕기위해 블랙 박스 시퀀스 다이어그램을 그려놓고 구현을 했다.dto로 좌석 정보를