TIL 0311, 0주차 미니 프로젝트 #2
실제 일과 시작 전
운동을 의식적으로 해야한다고 정글 적응 팁 중에 적혀있더라. 그래서 용인의 공기를 숨쉬는 동안에는 그렇게 해야한다고 느낀다.
일과 시작 후
오늘은 실제 구현에 더해 주변에 의사소통에 도움이 될 수 있는 부가적인 것도 같이 생각했다. 그리고 아이디어에 대한 발표가 있었다. 다행히 가장 참신 한 것 같다는 코치분의 칭찬에 제안한건 아니지만 구체화를 도운 나도 어깨가 들썩했다. 네이스 네이스
- Discord
정글 내부에서 사용하기로 한 Slack이 전부 준비 된게 아니다 보니 어거지로 사용 할 겨를이 아니었다. 다행이 모두가 Discord를 사용 할 줄 알았으니 맘편하게 채널 하나 파서 거기서 쭉 이어 나갔다. - Github Desktop
첫 개발을 시작한지 8년차지만 부끄럽게도 git commands 중 말끔히 설명 할 수 있는게 별로 없다. GUI가 있는 프로그램은 신이야. 어쨌든 기록이 남는거니까 무작정 push/pull을 해보기로 했다. - Notion
내 고찰을 미친듯이 써내려가는 용도로 썼다. 이건 어제 오늘 쓴 종합 내용이다. 실제로 도움 된 것도 있고 기획 단계에서 끝난 것도 있고, 아무래도 욕심도 욕심이지만 시간 문제도 다소 들어가는 듯 하다.
- 로그인 회원가입 회원관리를 개발 할 때
- 메인 페이지가 있고 여기선 로그인 여부에 따라 나오는 페이지가 다르도록 구현한다
- jinja2 의 {% if %} 문을 사용하면 해당 내용을 구분지어 표시 할 수 있다
- 메인 페이지에서 로그인을 하진 않고 로그인 전용 페이지가 존재한다
- 로그인을 수행하거나 회원가입하는 선택지가 제시된다
- 회원가입 화면에서는 회원가입을 수행한다
- 회원가입이 승인되면 아이디, 비밀번호, 닉네임, 성공한 퀴즈 목록, 퀴즈 갯수 정도가 개인에게 배정된다. 성공한 퀴즈 목록으로, 문제를 저장하는 배열 (문제 갯수인 20개)가 만들어진다.
- 뿐만 아니라 문제 통과 갯수를 저장하는 부분도 만들어진다.
- 아이디 비밀번호 닉네임은 사용자가 요청한대로 반영이 되고 성공퀴즈목록과 퀴즈갯수는 반드시 0으로 초기화된다.
- 당연한 것이 아이디를 만들자마자 아무것도 퀴즈가 없는게 맞으니까..
- 메인 페이지가 있고 여기선 로그인 여부에 따라 나오는 페이지가 다르도록 구현한다
- 퀴즈 영역이랑 랭킹쪽 개발에 관한 고찰
- DB에서 구성하기로 이야기 된 성공한 퀴즈 목록과 퀴즈 갯수로 위 기능을 좀 더 가독성 있게 구현 할 수 있다.
- 퀴즈 영역의 페이지는 크게 두 가지가 있다.
- 퀴즈 목록 확인
- 여기서 성공한 퀴즈 목록을 참조해야한다. 해당 내용을 바탕으로 이미 성공한 퀴즈와 그렇지 않은 퀴즈를 구분한다.
- 퀴즈 수행
- 사진과 정답을 매핑하는 수단을 딕셔너리 형태로 구현되면 사진이랑 답을 보다 보안상의 문제를 덜 가져가면서 구현을 완성 할 수 있다.
- 퀴즈의 정답이 입력된다면 사용자의 퀴즈 목록을 갱신하고 동시에 퀴즈 갯수도 갱신한다.
- 퀴즈 목록 확인
- 랭킹 쪽 개발
- 혼자 생각해봤는데
- 랭킹 전용 DB를 만들어두고 퀴즈를 풀때마다 사용자의 _id와 닉네임, 성공 퀴즈 갯수를 Update하는 방식으로 구현 할 수 있을 것 같다.
- 예를 들어 :
- _id, 닉네임, 점수 순
- a1af, cola, 10
- ap10, duap, 10
- aq1q, pizza, 4
- 순이라고 했는데 내가 duap 닉네임으로써 1점을 더 달성하는 즉시 DB에서 지정한 데이터들을 모두 넘겨서 DB가 갱신되게끔 한다.
- 랭킹 쪽 화면에 들어올 때 DB를 받아오게 한다. 이 때 get을 sort by score 순으로 수행한다면 어렵지 않게 정렬된 데이터를 끌어올 수 있다.
- 랭킹 쪽에서 개발할 영역은 크게 두 가지이다.
- 내 주변 랭킹
- DB를 끌어올 때 자기 자신과 일치하는 곳을 찾고, +1과 -1 순위인 사람을 추적한다. 이걸 구현하려면 순위 번호도 필요하겠네..
- 탑 랭킹
- 단순히 DB에서 내림차순 정렬 후 3-5개만 표기하도록 한다.
- 내 주변 랭킹
- 혼자 생각해봤는데
- 퀴즈 영역의 페이지는 크게 두 가지가 있다.
- DB에서 구성하기로 이야기 된 성공한 퀴즈 목록과 퀴즈 갯수로 위 기능을 좀 더 가독성 있게 구현 할 수 있다.
- 랭킹 시스템을 어디까지 구현하냐에 따라 이야기가 참 많은데 같은 팀원분이 욕심이 많아서 그런지 이것저것 많이 제시하고 계신다. 도울게 있으면 좋겠는데 당장 떠오르는건 옆에서 구체화를 해주는게 전부일듯 하다.
로그인 시스템 개발 당시 닉네임을 포함한 더 많은 데이터를 포함하고 있었다. 하지만 이후의 개발을 더 가독성 있게 가져가려면 해당 내용들을 제거하고 사용자가 입력 가능한 영역을 id, pw 딱 두 개로 가기로 상의해서 결정했다.
Jinja2를 이용한 서버 사이드 렌더링에 기반한 구현을 하라고 했는데 이게 무슨 이야기일까?
결국 미니 프로젝트가 끝나고 나서야 이걸 찾아 보는 시간을 가질 수 있게 되었다.
Jinja2를 이용한 서버 사이드 렌더링은 결국 틀을 제외한 모든 부분을 서버에서 처리 할 수 있도록 하라는 지시였다. 그 의도를 모르고 그냥 아무렇게나 만들다보니 클라이언트 베이스 렌더링이 된 내가 조금 짜증이 나는 중.
서버 사이드 렌더링은 클라이언트 사이드 렌더링처럼 데이터만 백엔드에서 받아오는것에 좀 더 저급(low-level) 영역까지 나아가서 더 많은 부분의 렌더링을 서버에게 맡기는 방식이다. 즉 서버에 결정된 값에 따라 클라이언트에 보여질 값이 정해진다. 이것만 보면 당연하다고 생각 할 수 있다. 당연히 클라이언트는 어딘가에서 내용을 받아와야 실 사용자에게 보여 줄 수 있지 않겠는가, 하지만 그런 영역이랑 많이 다르다.
클라이언트 사이드 렌더링에서 숨기는 개념은 소스 코드 안에는 여전히 남아있어 사용자가 호기심이 많다면 해당 코드를 굳이 열람 하게 된다. 하지만 서버 사이드 렌더링은 값에 따라 조건문을 걸 수 있고, 그에 따라 작성되는 html 코드 자체가 달라진다. 데이터만 받아오는 1차원 적인 서버 - 클라이언트 관계에서 더 서버 의존형이 됐지만 보다 보안성이 강하고 실 사용자의 사용 범위를 개발자 측에서 제어 할 수 있도록 한다는 점에서 상당히 개선점이 있다고 볼 수 있다.
하지만 서버 사이드 렌더링은 클라이언트 사이드 렌더링보다 다소 까다로운 문법을 사용하는게 사실이다. 그래서인지 기술 스택에 완전히 익숙하다고 할 수 없는 상황에서 클라이언트 사이드 렌더링으로 우선 완성한 시스템을 수 일 내로 서버 사이드 렌더링으로 새롭게 개발하려고 했다는 점이 무겁게 다가왔다고 생각한다. 물론 익숙해지면 당연히 괜찮겠지만 처음 보는 입장에서 기존의 html + 백엔드 코드보다 부담스럽게 여겨질 수 있겠다고 느낀다.
Jinja2를 선택지로 둘 수 있는 정도면 레퍼런스 문서는 금방 찾을 수 있을 것이라고 생각한다.