Docker란? 도커는 리눅스의 App들의 프로세스를 격리하여 컨테이너로 실행하고 관리하는 오픈소스 프로젝트입니다. 막상 사용해보면 VM과 같은 내 컴퓨터에 독립된 리눅스 운영체제 환경이라고 생각할 수 있습니다. 틀리진 않은 설명입니다. VM은 아니지만 VM같은 무언가가 설치되기는 하거든요. 그리고 무엇보다 매우 가볍습니다. VM을 돌려보신분들 이라면, VM을 하나 키면 잡아먹는 리소스가 상당히 거대하다는 걸 알 수 있습니다. 어떻게 이렇게 가볍냐고 하면, 여러 VM은 Linux Kernel이 따로 존재하는 반면에 도커는 여러개의 컨테이너가 하나의 Linux Kernel을 공유합니다. 하나의 머신에 여러 이미지를 사용할 수 있게 만들었습니다. 개발환경이나 특정 프로그램을 도커에 설치하는 이유는 간단합니다..
SpringBoot/프로젝트 게시판 만들기
웹에서 로그인을 어떻게 판별할까? HTTP의 특성중에는 무연결, 무상태성이 존재합니다. 즉, 해당 특성들로 인해서 연결의 정보를 잊어버립니다. 그래서 요청할 때마다 새로 연결을 해주어야 합니다. 이 말인 즉슨, 매 페이지마다 로그인이 되어있는 상태인지를 확인하는 로그인 인증 방식이 필요합니다. Sessoin이란 유저가 웹 서비스에 접속해 있는 상태를, 하나의 단위로 취급하고 그 자체가 session 이라 칭한다. 이 각 단위(session) 마다 id를 부여하고 브라우저에서 구별한다. 이 브라우저가 닫히거나, 관련 쿠키가 삭제되면 해당 session이 제거된다. 1. 브라우저에서 로그인을 위한 정보를 서버에 전송합니다. 2. 서버는 메모리에 사용자를 저장합니다, 그 후 세션 아이디를 Cookie로 전달합..
웹 사이트를 제작하다가 보면, 현재 로그인한 유저 정보를 한번, 두번, 수십번씩 끌여다 쓰게 된다. 내 정보를 불러올때, 내 주문 정보를 불러올때 등등, 대부분이 " 현재 로그인한 유저 정보 " 를 수집하게 된다. React를 사용하고 있는 현재로써, 내가 했던 코드들은 아래처럼 props 를 보내서 선언하고 지정하고를 반복했다. function MyInfo() { const token = getAuthToken(); const decodedToken = tokenUserInfo(token); const memberUid = decodedToken.UID; const [selectedTab, setSelectedTab] = useState('profile'); // 기본값 설정 const ProfileS..
만들고 있는 사이트에 쿠폰기능이 필요하다. 관리자가 사용 가능한 일자를 등록한 후 완료하면 기간동안 유저들에게 배포된 쿠폰이 유효기간 동안 지정한 할인율 만큼 적용할 수 있어야 한다. 결제페이지에 넘어와서 완전히 결제완료가 반환되기 전까진 사용처리가 되면 안된다. 쿠폰 상세 정보: 관리자가 쿠폰을 생성할 때 입력해야 하는 정보는 다음과 같습니다: 쿠폰 이름 할인율 발행 개수 적용 카테고리 발행 시작일 발행 종료일 사용 시작일 사용 종료일 유저 정보와는 위와 같이 매칭된다. 작성해 놓았던 ERD를 기준으로 해당 테이블들을 JPA 로 작성한다. 존재해야 하는 기능들을 정리해보면 아래와 같다. 1. 전체조회가 가능해야 한다 2. 발급 일자별 조회가 가능해야 한다. 3. 쿠폰 상태별 조회가 가능해야 한다. 4...
이전 포스트에서 요구사항을 정의하던 것을 마무리하고, ERCLOUD를 이용해 설계까지 진행했다. 스타일이 조금씩 다르지만, 설계단계에서 충분히 합의하고 진행할 수 있는 부분이기 때문에 세부적인 부분까지 통일하진 않았다. 어느정도 필요한 필드들과 테이블을 빼 설계해보니 아래와 같은 ERD 설계도가 나왔다. JPA를 사용하여 설계할것이기 떄문에 직접 rdbms를 켜서 테이블을 생성하진 않지만, entity를 구성하고 알맞은 참조관계를 적용시키기 위한 erd 설계는 한눈에 알아볼 수 있는 관계도라는 것이 메리트가 크다고 생각한다. 물론 각 rdbms 툴마다 테이블들을 가시화해주는 기능들이 생기지만 무거워서 잘 안써봤다. 또한, 생성 된 후 관계를 보는것과 생성하기 위한 관계를 보는 것은 많이 다르기 때문에 d..
구현해야하는 페이지, 화면 구현은 대부분 끝이났고 이제 백엔드를 개발하기 전 DB를 구성할 시간이다. DB는 앞에서도 몇번 언급했지만, 변경하기 힘들다. 물론 NoSQL을 사용하면 그에따른 장점도 분명히 생긴다. 그러나, NoSQL을 써야하는 이유가 굳이 없다면, 자신의 DB에 관계조건이 필요하다면 반드시 RDBMS를 사용하는것이 좋다는 의견이 명백하다. 구상단계에서 NoSQL을 사용해보기 위해, MongoDB나, PostgerSQL을 사용해보자 했는데 다음 기회에, 명확한 이유가 생각나지 않았기 때문이다. MySQL을 사용해서 DB를 구현하기 전, 단계적으로 진행하려고 한다. 페이지별로, 혹은 기능별로 필요한 요구사항을 정의하여 Atribute와 field를 나누고, 정리 한 후에 ERD 다이어그램을 ..
현재 진행중인 프로젝트는 피그마로 설계를 끝낸 후, 현재 화면구현 단계를 진행중이다. 본 일정은 23-11-07 까지, 애초에 설계대로 페이지 7페이지 정도씩, 10일이라는 기간을 두고 진행했는데 진행하던 도중 생각지 못하게 필요한 팝업페이지나 모달 창 들이 생겨서 23-11-10 까지 기간을 늘렸다. 3일정도 더 늘린 결과, DB를 설계해야 하는 기간과 맞물렸지만, 일단 총 기한은 틀어지지 않게 할 예정이다. 2명이서 하는 프로젝트이다 보니, 의견 조율은 쉽지만 작업도가 크게 진전되질 않는다. 생각보다 개인이 맡아야할 페이지가 많았던 탓에. 오전 오후 가리지 않고 매번 접속해있는 Figma 상태창에 팀원을 보며 나도 진행해보지만 생각보다 일이 크다. React에 대해서 잘 알지못하는 탓도 있지만, 애초..
쇼핑몰의 물건을 등록할 경우, 어떤 데이터 정보들이 필요할까. 당장 Front에 보이는 정보들도 하나하나 세어본다면 상당히 많은 항목들을 차지한다. 검색했을 경우 나오는 태그들도 별개로 입력이 될 수 있고, 비슷한 제품을 홍보하기 위한 코드들이 존재하는 경우도 많다. 네이버쇼핑에 물건을 한번보자 보이는 정보들을 나열해보자면 아래와 같다. 이미지 카테고리 상품이름 상품배송종류 할인율 가격 할인정보 포인트정보 최대구매개수 배송정보 개수 배송정보 해당 정보들이 어떤 테이블을 가지고 어떤 관계를 가지는지는 알 수 없지만, 얼핏 보더라도 단순히 한두가지의 테이블이 아니라는 것은 알 수 있다. DB를 설계한다면 매핑관계도 신경써야하며, 최소한의 데이터를 쓰기위해 중복될 수 있는 정보들은 최대한 추려나가야 한다. 테..
