개발자 모드

프로젝트를 생성하고 엔티티의 골격만 짜보았다. 자바는 트렌드를 따라가기 위해 더이상 11을 사용하지 않고 17을 사용해보기로 했다. 스프링부트도 3.2버전으로 생성했다. 프론트가 없는 관계로 템플릿 엔진을 이용해야한다. 우리는 머스테치와 타임리프를 두고 고민하였다. 머스테치는 쉬운 문법이 강점이라고 하였지만, 현재 김영한 선생님의 강의를 듣고 있는데 자꾸 타임리프 칭찬을 하신다.. 아무리 봐도 문법이 쉬워보이지는 않은데 쉽다고 하신다... 우리도 타임리프로 하기로 했다. (줏대없어 ㅋㅅㅋ) DB는 국룰 mysql로 가지 않을까 싶긴하다. 개발용으로는 단연 h2. 앞선 글에서 변경된 erd를 소개했다. 정말 좋은 것 같아서 그 erd를 반영하여 골격을 세팅했다. 아직, 임베디드 타입의 적당한 패키지를 정하..

ERD가 변경되었다. 내가 없는 사이 팀원이 ERD를 다시 구상하였다고한다. 우선, 우리가 초기 구성한 ERD를 살펴보자. 우리가 이 ERD를 구상하면서 가장 고민이 되었던 부분이 바로 old_XX 엔티티이다. old_XX 엔티티를 만든 이유는 사용자에게 과거 사진 교환 목록을 제공하기 위함이다. sending과 matching에 과거 사진 교환이 성공한 이력을 저장하고자 하였지만 테이블이 누적되는 것도, status를 갖고 있어야하는 것도 조금 걸렸다. 그래서 완료된 데이터를 저장하는 테이블과 진행 중인 테이블을 분리하였는데.. 위와 같은 erd에서는 user_id가 주어졌을 때, 사진 교환 이력을 불러오는데 다음과 같은 복잡한 과정을 거친다. user_id 기반으로 old_sending_id를 찾는다..

현재까지 고안해낸 ERD이다. 내가 작성하는 방식과는 다르지만, 이것도 꽤나 잘 눈에 들어오는 것 같아서 좋은 것 같다. 우선 User가 존재한다. 회원가입을 할 예정이며 소셜 로그인같은 기능보다는 간단한 아이디, 패스워드로 시작해보려고 한다. User는 Sending이라는 행위를 한다. 사진을 매칭할 대상을 찾는 과정인 것이다. 서버 내부에서 real time algorithm으로 인해 서로 사진을 주고받은 User 두 명이 검색되었다면, Sending 2개의 데이터가 묶여 Matching에 등록된다. Matching에 등록된 데이터들은 서로 사진을 교환하는 과정을 거친다. 이러한 일련의 과정(사진 교환)을 거치게 되면 matching과 sending에서 앞선 처리된 상황의 데이터가 삭제되고 old_X..

Random Photo Matcher라는 이름의 RPM. 과거 팀원의 경험을 떠올려 기억에 남았던 어플의 핵심 기능을 가져와서 우리만의 서비스로 만들어 보려고 한다. Rando. 랜덤으로 사진을 교환하는 서비스이다. 현재는 서비스를 중단하였다고 한다. 우리는 이러한 핵심 기능을 구현하고 그로부터 필요한 부가기능을 넣어서 4월 한달동안 구상해보려고 한다. 화이팅..!! 새로운 마음으로.