chang12 / django-todo Goto Github PK

문제

• 지극히 개인적으로 느낀 할일 기록의 힘든 점은, 유익할 것 같아서 기록해둔 많은 할일들이다.
• 처음에는 유익할 것 같아 나중을 기약하며 적어두지만, 우선순위에 밀려 바닥에 차곡차곡 쌓이기 시작하면 골칫거리가 된다.
• 전체 할일의 개수가 늘어나고, 일정 수준 이상으로 늘어나면 애초에 할일을 지워나갈 원동력이 떨어지게 되는 것이다.

아이디어

• Agile Kanvan 방법론을 벤치마킹한다. 즉, 할일들을 하나의 리스트로 유지하는 것이 아니라 그 생명 주기에 따라 단계별로 분류하는 것이다.
• 방법론을 그대로 차용한다면 Backlog > In Preparation > Doing > In Review > Finished 정도로 구성해볼 수 있을 것이다. IT 서비스가 아니므로 Released 같은 단계는 존재하지 않는다. 더 담백하게 가자면 In Preparation은 지울 수 있을 것이고, In Review는 고민해볼만 하다. 일을 최초로 마치는 것과, 리뷰를 통해 더 개선시키는 단계는 필요에 따라 구분지을 만 하기 때문이다.
• 결정된 초안을 유저들에게 설명하는 용도와, 기본값으로 사용한다.

생각해볼 거리

• 만약 유저가 생명 주기를 변경하고 싶은 경우, 변경 전 Task 들의 생명 주기 소속과, 변경 후 Task 들의 생명 주기 소속을 맞춰줘야한다.
• (지금 잠깐 고민해본 바로는) 유저가 새로운 생명 주기를 생성하고 옮겨가는 과정에서, 기존의 생명주기의 각 탭과 새로운 생명주기의 각 탭 사이에 대응을 시켜도록 강제해서 Task들의 마이그레이션을 진행할 수 있겠다.

Task 상세 내용을 볼때는 내용물에 맞춰서 modal 이 커진다. 편집 화면에서도 <textarea> 태그가 내용물에 따라서 크기가 커질 수 있으면 좋을 것이다.

하고 싶은 것

연쇄적인 상승/하강이 가능하도록 UX를 변경하고 싶다. 이에 맞는 개발을 진행한다.

구체적인 방법

AJAX로 할 수 있겠지만, 가능한 피해보고 싶다. 그러므로 index.html 파일을 띄울때 옵션을 줄 수 있도록 변경한다. 만약 Task의 상승/하강 이후 리다이렉트로 인한 index.html 이라면 어떤 Task에 대한 상승/하강 이었는지 정보를 view에 알려줘서 해당 Task는 list-group-item-warning으로 설정하고 띄울 수 있도록 한다.

Task의 개수가 많아서 스크롤이 생성될 경우에도 상단 navbar와 버튼 그룹은 고정될 수 있도록 UI를 수정한다.

현재상황

메인 페이지에 Task 들의 title만 나온다.

개선방안

• Task를 클릭하면 상단에 "상세" 버튼이 보여진다. (#16 에서 구현완료)
• 버튼을 클릭하면 모달 팝업. (#16 에서 구현완료)
• 모달에서 Task의 상세한 정보를 볼 수 있다. (#16 에서 구현완료)
• 모달에 달려있는 "수정" 버튼을 클릭하면 상세 정보가 Form으로 변환되어 수정할 수 있다.

현재상황

Task의 title 길이가 max_length를 초과한 상태에서 submit 한 경우 입력한 데이터를 모두 상실하고, Task는 등록되지 않는다.

원인

index 뷰에서 Task ModelForm으로 인스턴스를 저장할때, 에러가 발생한 경우 처리 로직이 없다.

해결방법

뷰에 적절한 로직을 추가해서, 템플릿 폼에 입력한 내역을 상실하지 않은 상태에서, 에러 메시지를 띄워준다.

• Back Log 로 보내도 Back Log 페이지로 이동하지 않고, 원래 페이지에 남아있기

Django 공식 문서 를 참고해본다.

문제의식

매일 혹은 주기적으로 해야할 일들을 기록하고 관리하고 싶을때는 어떤식으로 접근할 수 있을까?

• 매일 Effective Java 책의 1절씩 읽는다.
• 매주 취미 개발 프로젝트의 issue 를 하나씩 해결한다.

등등이 생각해볼 수 있는 예시들이다.

접근 1

반복 주기마다 새로운 Task 를 생성해서 리스트에 추가한다. 아마 별다른 설정이 불가능할 것 같으니, 최상단에 추가되게 하는것이 유일한 방법일 것이다.

• 매일 반복되는 Task = 자정에 추가
• 매주 반복되는 Task = 일요일->월요일 넘어가는 자정에 추가

이에 더하여 이러한 주기성을 지니는 Task 스트림(?)들은 따로 관리할 수 있도록 탭을 제공한다. 반복 주기 대비 실제 완료되는 시기를 비교하여 다양한 통계를 내주는것이 가능할 것이다.

같은 스트림에 속하는 Task 들이라는 것을 명시하기 위해서, 이름을 통일한다던가, 라벨링을 한다던가 식의 작업이 필요할 것.

좀 큰 작업이겠지만, advanced 보다는 enhancement 가 맞겠다.

달력에 대한 얘기들이 들어가야 할 것이다~!!

Task 클릭 전

• 새로운 Task를 추가할 수 있는 추가 버튼만 존재한다.

Task 클릭 후

• 상세 : 해당 Task의 상세정보를 모달 팝업으로 보여준다 (수정 버튼 내재)
• 상승 / 하강 : 해당 Task를 이동
• 완료 : 해당 Task를 완결

navbar 가 넘나커서 추가 버튼이 가려진다. 그래서 새로운 Task 를 추가할 수 없다.

Bootstrap의 Component 문서에서 우측 배치에 대한 내용이 있었던걸로 기억한다.

• 수정 상태에서 Enter 누르면 수정 되도록 엔터 누르면 줄바꿈이 되어야지 수정이 되면 안된다.
• Task 클릭 상태에서 화살표 누르면 상승/하강 Task 선택을 이동시키는게 더 편리할듯. 중요도 상승/하강은 화살표가 필요할정도로 빈번한 작업은 아니다. 그리고 버튼 클릭이 그다지 불편하지 않을듯. 아니면 중요도 이동에 대해서는 다른 단축키를 지정할 수 있다.
• Task 클릭 상태에서 엔터 누르면 팝업
• Task 완료시 밑의 Task 선택 상태로 변경
• 상세 페이지에서 링크 클릭하면 새 탭에서 실행

Task 보여질때 URL를 인식해서 클릭할 수 있게 해주고, 엔터는 줄 바꿈을 인식해준다.

일단락 짓고 마무리 작업으로 하면 될 듯!

- [ ] 추가 버튼을 클릭하면 modal이 뜨고 input 태그와 추가 버튼이 다시 뜬다.
- [ ] modal의 추가 버튼을 누르면 새로운 Task 생성이 요청되고, 성공할 경우 메인 페이지로 리다이렉트

• 추가 버튼을 클릭하면 Task 생성 form이 나타나고, 생성/취소 버튼이 나타난다.
• 생성 버튼을 누르면 Task 생성 view에게 요청을 보낸다.
• 취소 버튼을 누르면 생성/취소 버튼이 사라지고, Task 생성 form이 사라지고, 다시 추가 버튼이 나타난다. (적어놨던 form 내용 보관)

지금은 Task 모델에 updated_at 필드뿐이 없는데, 완료시각을 따로 기록할 필드가 필요하다. 아마 보류시각이랑 재개시작도 필요할듯.

의미

메인 탭(index.html)에서는 Task 들의 관리(생성, 수정, 완료, 우선순위 변동) 작업이 이뤄진다. 이에 반해 통계 탭에서는 메인 탭에서 이뤄진 각종 액티비티에 대한 로그를 분석해서 유의미한 통계 정보를 유저가 확인할 수 있도록 돕는다. (사실 navbar에 로그아웃 버튼뿐이라 좀 허전해서....)
그러므로 어떤 유의미한 통계 정보가 추출 될 수 있을지 먼저 생각해봐야한다. 이 또한 GitHub의 Pulse나 Graphs 탭을 벤치마킹 할 수 있을 것이다.

내용

• 시간을 지정해놓는다
• 해당 시간이 되면, 해당 Task 가 가장 큰 priority 를 갖게되어 최상단으로 이동한다.

구현

• Linux OS 의 Cron 기능
• 그리고 이를 감싼 Python 의 무언가가 있었는데, 이름이 기억나지 않는다.

한국어에 대해서만 준비한다. 다른 나라 언어의 경우 영어를 그대로 보인다.

• Form에서 발생하는 에러

• Sentry가 좀 엣지있어보여서, 경험삼아 써보고 싶다. Django 프레임워크도 역시나 제공한다.
• 그런데 사실 막상 Sentry를 어떤 목적으로 사용할지에 대한 생각이 없다.
• Sentry가 유용한 경우를 파악하고, 이를 적용해볼만한 토이 프로젝트를 고안해보자.

• 추가 버튼 누르고 Form 작성하다가 Task 클릭하면 Form은 그대로 두고 버튼 그룹만 바뀐다.
• Task 선택 해제하면 Form의 보임 여부에 따라서 추가 버튼을 보일지, 생성/취소 버튼을 보일지 선택한다.

검색해준다.

삭제

무의미한 Task라 생각하면 삭제한다. DB에는 가지고 있는다.

보류

메인 화면에는 안보이지만, 킾해두고 싶을때 보류.
일종의 백-로그 역할을 수행.
그러므로 백-로그 탭도 추가해야 한다.

JIRA 의 issue 개수에 대한 그래프랑 비슷하게 가져갈 수 있겠다. 시간에 따른 누적 그래프.

Task 생성 과정에서 에러가 발생할 경우, 이를 index.html의 해당 form에 반영해서 유저에게 알려줍니다.

• 브라우저의 세션 유지 기간이 얼마나 되는지 우선 파악
• 그 기한을 그대로 따르지 않고, 특정 시간 이후에는 세션을 파괴하도록 한다.

맥락

혼자 쓸때는 멀티 디바이스로 동시에 작업할 일이 없다. 만약 여러명이 하나의 Task 목록을 공유한다면? 그런 경우를 생각했을때도 사실 실시간 동기화가 꼭 필요하지는 않다. 그렇지만 학습 목적으로 한번 시도해볼만 하다.

목표

여러명이 작업중인 상황에서, 누군가가 새로운 Task를 추가하거나 위치를 이동할 경우 다른 사용자들의 Task 목록에서도 그 내역이 반영되도록 한다. 즉, 핵심은 서버->웹 브라우저로 무언가 푸시를 할 수 있냐는 것이다.

nginx 단에서 해야 할까?

• post:finish
• post:modify

현재상황

todo.fakenerd.kr 로 도메인 이름이 그대로 뜬다.

개선방안

적절한 이미지와 적절한 텍스트가 보이도록 수정해준다. 이게 혹시 그 얘기로만 듣던 favicon이라는 것일까?

정리

• 지금은 DB 테이블을 EC2 머신에 가지고 있다. 이것보다는 RDS에 연결하는 것이 좋을 것 같다. 이 작업을 먼저 한다.
• 데이터를 RDS에 넣은 경우, 이를 어떻게 효율적으로 백업할 수 있는지 방법론들을 찾아본다.

GitHub의 Label을 본따서 만든다.

• Label 모델 설계
• Label 생성/수정/삭제 뷰 구현
• Label 탭 UI 구현
• UI와 뷰 연동

해결해야할 것들

• Task 리스트 아이템 하나를 클릭한 상태에서, 다른 아이템을 클릭할 경우 기존 클릭이 해제된다.
• Task 리스트 아이템 하나를 클릭한 상태에서 웹 페이지의 여백을 클릭할 경우 기존의 모든 클릭이 해제된다.

로그를 남겨서 사용 패턴을 분석한다. 단순한 기능을 제공하는 서비스이므로, 기능별 분류가 쉬울 것이다. 간단한 패턴들(예: N개의 Task가 완료될 동안, M번의 move가 발생)을 정리하고, 이를 통해 서버에서 생길 수 있는 트레이드-오프 중에서 어떤 선택을 내릴지 결정할 수 있을 것이다.

생각할 것

• 로그 남기는 코드를 어디에 작성할 것인가?: API 엔드포인트 코드의 말미에 삽입할 수도 있겠지만, Python이므로 데코레이터로 예쁘게 만들어볼수도 있을 것이다.
• 로그를 어디에 저장할 것인가?: AWS S3?
• 로그를 분석하는 도구는?: 아직 별 생각이 없네. 이번 기회에 Linux OS에서 cron 작업을 등록하는 법이나, Python으로 한다면 celery를 도입해볼 수 있을 것이다.