210720 TIL

Feeling

• 항해 부트캠프 크루원들 중에서 진도가 뒤에 쳐져 있다는걸 알지만 생활 패턴을 바꾼뒤로 머리속에 들어오는 학습내용이 전보다 훨씬 나아서 재밌으면서도 가끔 에러가 떠서 삽질을 할때면 수면에 의한 안좋은 컨디션은 나를 몰아 붙이지 않기 위한 자기 합리화인가라는 의문이 들때도 있지만 나에게 맞는 방법은 최소한 집중력의 문제가 게임을 하고 싶거나 놀고 싶거나 다른 이유가 아닌 수면 부족에 의한 흐름의 끊김이이까 공부하는 시간에는 졸지 않을 정도의 수면을 취하는게 현명한 방법이다. 말이 이상하기 하지만 일단은 마음 편히 자려고 노력하자! 각자에 맞는 전략이 있는거다.

금일 목표

- [x]  CRUD 게시글 조회
- [x]  게시글 수정
- [ ]  게시글 삭제

구현과정 로깅

- 게시글 조회하기 구상시작
    - 전체 게시글 각항목마다 고유 아이디로 해당 내용으로 이동하는 api만들기
        1. 서버에서 전체게시글 ejs로  데이터를 넘겨줄때 몽고디비에 있는 고유한 아이디값도 넘겨 주는지 서버에 콘솔 찍어서 확인을 한다.
        2. for loop 안에 각 데이터가 출력이 되니 forloop안에서 해당 게시글 클릭시 이동하는 api주소에 쿼리값으로 몽고 db Id를 넣어준다.
        3. 해당 쿼리를 받았을시에 이동하는 get 서버에서 쿼리값을 뽑아서 몽고디비에서 쿼리값과 일치하는 데이터를 찾아서 상세정보를 보여주는 ejs파일에 값을 보내준다. 물론 상세정보 ejs파일에 보여주고자 하는 값의 그림을 그려줘야된다.
- 게시글 조회하기구현시작
    - ejs에서 쿼리 보내주기
        - 오래 걸린 이유
            - 처음에는 각 줄마다 적혀있는 데이터가 있는 부분을 클릭하면 해당하는  데이터의 사이로 쿼리를 담아 보내려고 했는데 html그니까 프론트를 잘 몰라서 해맸는데 그냥 a테그 옆에 추가해서 보내는 방식으로 전환 일단 구현이 먼저니까
            - a태그방식에서 쿼리를 보내주는 법을 잘 몰라서 해매다가 ejs문법이 관련이 되어있고 a태그에서  ejs문법 사용하는 법을 구글링해서 찾은 것 같았는데 <%=데이터아이디값%>에서 뒤에있는 '%>'가 잘못된 위치에 있었음
            - 오류 줄이는 법!
                - 괄호와 태그의 마지막 위치를 주의할것!
    - ejs에서 서버로 보내는 쿼리값 받아내기
        - 오래 걸린 이유
            - 아마도 req로 선언했는데 request라고 적어서도 있고 /reqading/:id로 본것 같아서 적었는데 해당 주소는 없다고 뜸...
        - 찾은 경로
            - api에 /reading/:id중에 :id를 빼고 /reading으로 해서 ejs에서 보내준 reques를 받고 req를 콘솔로 찍어서 id값을 주는 부분을 crtl+f단축키로 처서 찾은다음 쿼리안에 id를적어서 보내주는걸 보고 console.log(req.query.id로 받아냄
    - 해당 id받았으니 인제 해당게시글 ejs만들고  해당 쿼리에있는 id값과 일치하는 데이터를 몽고디비에서 조회한다음 해당게시글 ejs에 값을 보내고 ejs파일에서 <%=변수값%>문법을 써서 그려주기!
    - mongoose schema find by id 사용법 구글링
    - 찾은 함수에 쿼리로 받은 아이디 값 인자로 넣어서 데이터 잘 나오는지 확인
        - ok 계획대로 되고있어~
    - 게시글 조회하기 구현 완료!!!!!!!!!!!!!
- 게시글 수정하기
    - 게시글 조회하기와 게시글 수정하기1의  와이어 프레임이 겹치는걸 깨닫고 와이어프레임 하나로 합치는중
    - 게시글 수정하기 구상
        1. **게시글 조회 페이지에서 수정하기 버튼을 눌렀을때 게시글 수정페이지로 이동한다**
        2. **게시글 수정페이지에서 해당 게시글의 작성할때의 형식에 데이터를 비밀번호만 빼고 그대로 채워준다.**
        3. **수정완료 버튼을 만들어준다**
        4. 수정완료 버튼을 누를시 두가지 경우 
            - 비밀번호가 맞을 경우
                - 입력한 비밀번호값과 데이터에 적혀있는 비밀번호값이 같을 경우에 입력된 모든 데이터들을 고유한 id값과 일치하는 데이터에다가 업로드 해준다.
                - 게시글조회로 이동해준다.
                - 옵션 - 게시글조회페이지에서 alert로 게시글이 수정되었다고 띄워준다.
            - 비밀번호가 다를 경우
                - 게시글 수정페이지로 다시 이동하고 alert로 비밀번호가 틀렸다고 띄워준다.
    - 게시글 수정하기 구현시작
        1. 수정하기 버튼을 만든다
        2. 수정하기 버튼에 해당 id를 쿼리로보낸다
        3. 서버에서 ejs에서 설정한 수정하기 url을 만들어서 쿼리 값을 받아내는지 만든다
            1. 콘솔에 원하는 값이 찍히기는 하지만 응답을 하지 않을시 브라우저에서는 계속 일을 하고 있다 따라서 res.send({})로 빈값을 내려줘서 일단 마침표를 찍어준다.
            2. 쿼리값에 일치하는 데이터를 'editing.ejs'에 입력한다.
            3. 받은 데이터로 editing.ejs서 채워져야 되는 글을 다 채워준다.
            4. 다시 유저에게 입력받은 값을 수정하는 api로 보내준다.(form 사용) 해당 데이터 - 아이디 그리고 입력한 값을 보내면 되겠다.
        4. form으로 데이터 보기 성공
            - 오래 걸린 이유
                - 데이터를 수정하는 것이니까 REST api 원칙에 의하면 put이나 patch를 써야되는데 html에  form 문법에서 put method를 쓰려고 적었는데 해당 api에 접근을 못했던것이다 이유는 모르겠지만 시간이 너무 지나가서 지난번에 가이드 받았던것에 post라고 적혀 있길래  혹시나 f**orm method가 put으로 쓰면 안되는 걸까하고 post로 치니 되었음....어이가 없지만 왜 이런건지 궁금하다. 나중에 꼭 알아보자**
            - 로깅 스킵
            - 드뎌 수정 완성 아직 노드에 warning 뜨고 비밀번호 아닐씨 고쳐야 되는 부분은 내일 하기!!!!!!
            - 내일 이어서 봐야될 부분
                - 

                PS C:\Users\dldms\hanghae99\ReviewBasicAssignment> ^C
                PS C:\Users\dldms\hanghae99\ReviewBasicAssignment> node app.js
                listening at [http://localhost:3000](http://localhost:3000/)
                { title: '집가자', writer: '집가자', password: '집가자', content: '집가자' }
                (node:8824) UnhandledPromiseRejectionWarning: CastError: Cast to ObjectId failed for value "{
                title: '집가자',
                writer: '집가자',
                password: '집가자',
                content: '가즈아~~~',
                date: 1626782505752
                4498:21)
                ry.js:4592:15)                                                                                             4498:21)
                at processTicksAndRejections (internal/process/task_queues.js:95:5)                                    ry.js:4592:15)
                (Use `node --trace-warnings ...` to show where the warning was created)
                (node:8824) UnhandledPromiseRejectionWarning: Unhandled promise rejection. This error originated either by
                throwing inside of an async function without a catch block, or by rejecting a promise which was not handledthrowing inside of an async func-rejections=strict`(see <https://nodejs.org/api/cli.html#cli_unhandled_rejections_mode>). (rejection id: 1) the node process on unhandledomi se rejections that are not handled will terminate the Node.js process with a non-zero exit code. li_unhandled_rejections_mode)ect PS C:\\Users\\dldms\\hanghae99\\ReviewBasicAssignment> ^C PS C:\\Users\\dldms\\hanghae99\\ReviewBasicAssignment> node app.js listening at <http://localhost:3000> (node:21952) DeprecationWarning: Mongoose:`findOneAndUpdate()`and`findOneAndDelete()`without the`useFindAndModify`option set to false are deprecated. See: <https://mongoosejs.com/docs/deprecations.html#findandmodify> (Use`node --trace-deprecation ...`to show where the warning was created) PS C:\\Users\\dldms\\hanghae99\\ReviewBasicAssignment> node app.js listening at <http://localhost:3000> PS C:\\Users\\dldms\\hanghae99\\ReviewBasicAssignment> node app.js listening at <http://localhost:3000> (node:13600) DeprecationWarning: Mongoose:`findOneAndUpdate()`and`findOneAndDelete()`without the`useFindAndModify`option set to false are deprecated. See: <https://mongoosejs.com/docs/deprecations.html#findandmodify> (Use`node --trace-deprecation ...` to show where the warning was created)
                f

TimeTracking

- 2:26
    - 금일 목표작성
    - 2:35
    - **6시간 30분 몰입 가능**
    - 9:00
    - 정리
    - 10:00
- 2:30
    - init 게시글 조회하기 - **1시간15분**
- 3:45
    - BR
- 3:50
    - ing 게시글 조회하기 - **42분**
- 4:32
    - BR
    - 미용실 전화
- 4:53
    - cmplt 게시글 조회하기! - **12분**
    - 5:05
        - init 게시글 수정하 - **2시간 18분**
- 7:23
    - BR
    - 7:32
    - 저녁
- 7:49
    - cmplt 게시글 수정 구현 완료!!!!!!! - **1시간 27분**
    - 내일 게시글 수정 vscode에 warning 뜨는것하고 비번 매치 아닐경우 나오게 하는 루트 보수공사좀 하기
- 9:16
    - 졸려서 집중이 안되는게 아니니까 기분이 좋다 ㅎㅎ
    - 크루원과 소통
- 9:24
    - 다이소
- 9:45
    - 집으로
- 9:57
    - REST
- 12:57
    - 하루 몰입도 잠깐 분석
        - 6시간 30분중에 **5시간24분몰입**
        - 2시30분부터 시작
            - 순공시간 84퍼센트
            - 점시시간 고려하면 순공시간 12시간 중 9시간30분 가능
                - 오늘 몰입중 졸림횟수 대강3번이였던것 같음
                - 잠은 충분히 그리고 너무 규칙적이지 않으면 집중을 못할때 수면을 취하는 전략으로 가도 나쁘지 않을듯 안해봐서 모르지만 오히려 이게 더 효율적일 수도 있음 단 수면이 불규칙 적이여서 잠을 깨는 기준은 눈이 떠질때 하는 것과 눈을 떳을 때 피곤하지 않고 개운한 상태 이 두가지 경우를 테스트 해보고 맞는걸 적용해보는게 좋을듯
    - 크루원과 소통
        - 수면에 부족으로 인한 집중력 저하 있는지 체크 및 수면취하는 방식과 정도 분석

    9 am to 9pm을 지키면서 몰입하는 시간을 오늘처럼 84퍼센트 정도를 유지하려면 일단 9 to 9시간의 참석을 가능하게 만들어야되는데 9 to 9을 실행하기 위한 전제 조건은 졸려서 집중 못하는 상태가 아닌 상태 그러려면 숙면은 무조건 피곤하지 않을 정도로 취해야되고 어느정도인지 모르니까 일단 대략 9시간을 잡아 놓고 계획을 짠다 그러면 3시간의 자유시간이 있는데 집으로 왔다갔다하는시간 **30분**, 조식 및 양치  30분, 샤워 30분, 하루 분석 및 정리,  rest30분, 크루원과 소통시간 널널히 30분 하면 2시간 30분 너무 빡빡하게 시간을 잡지는 말고 틈세로 30분 남는데 대신 멍때리는 시간이 없어야 함...괜히 너무 조급해 지지는 않을까 걱정이 되긴 한데 수면시간은 무조건 확보를 해놔야 하루 일과중에 졸려서 집중을 못하는 상태가 나타나지 않는다. 오늘도 시간 패턴을 망치긴 했다. 너무 규칙적이게 일상 패턴이 흘러가지 않는다면 집중못해서 잠이 올때 피곤하지 않을때까지 푹 자는 패턴으로 가보고 이방법이 비효율 적이거나 오히려 시간이 더뺏긴다면 피곤할때 자다가 눈뜰때 공부하고 다시 졸릴때 바로 자는 패턴으로 가는 법 3가지 중에 나에게 맞는 방법으로 가보자.. 시간이 제한적이라 시행착오가 걱정이긴한데 오히려 3가지중에 제일 비효율 적인 방법으로 가는 것보다 3가지 방법중 나에게 맞는 방법을 찾고 그것을 꾸준히 유지하는게 맞는 올바른 전략이면서 나에게 이득이 되는 방법일수도

    암튼 그만 자자

- 3:04
    - 자러감
        - 아침에 개운해질 때까지 누워있을거임
            - 낮에 안자는거 중요!
            - 자기 합리화인가?
                - 학습 량과 효율을 봤을때 충분한 휴식을 취했을때가 오히려 진행속도가 더빠르다는걸 경험한것에 의한 전략임
                -