TIL - 0416~0420

Posted on | In | 0 comments

0416

트러블 슈팅

  1. WishList 모델명 변경하기 -> WishTravel
    • list, detail 이런거 구분하는데 힘들기 때문에.
  2. 위시리스트 삭제부분의 경우 APIView를 2개로 분리
    • ListCre
    • Delete
  3. blog의 경우 select_related 사용해서 구현해보기
    • GenericAPIView 사용

오늘의 한 일

  • 트러블 슈팅 관련 코드 수정
  • 크롤링 수정 및 TravelInformation 테이블 필드 추가 , serialize 수정

오늘의 고민

  • 제네릭뷰를 막상 사용하려니 왜 바꾸는지에 대해 잘 모르겠다.

해야 할 일

  • 위시리스트 test 코드 작성하기

0417

오늘 할 일

- 검색 부분 구현 논의
  • Django rest - SearchFilter 알아보기
  • 검색 결과 출력을 어떻게 할 것인지 (1. 상품, 2. 여행지이런식?)
- 이미지 여러 개 넣었을 때 후기 생성되는 부분

내일 할 일

  • 예약할 때 해당 날짜에 스케줄이 없으면 생성하는 루틴 만들기

0418

오늘 할 일

  • 검색 부분 구현
  • 상품 제목, 상품 내용에서 ‘검색 키워드’있는지 검색해서 출력하는 식으로
  • 상품 가격별, 인기순 이런식으로도 필터 사용해서 검색 출력
  • 예약
  • 나의 예약 현황 , 나의 예약 취소 현황
  • GitBook 작성하기

트러블 슈팅 물어 볼 것

  • get_queryset으로 결과물을 받은 경우의 예외처리

내일 해야 할 것

  • [예약취소] 예약 pk 가 없는 경우 (예로 예약 pk 44번까지있는데 45입력)
  • [예약] 시작날짜 오늘 이전 날짜, 3개월 이후 날짜 인 경우 예외처리 -> 석재님
  • [예약] 여행상품 pk가 잘못 된 경우 (pk가 없는 경우)/날짜/ -> 석재님

0419

오늘 한 일

  • [예약취소] 예외처리 , update의 경우 instance도 serialize에 함께 넘겨줘야 한다.
  • [위시리스트] 삭제시 디테일 문구 넘겨줌
  • 후기 작성 및 리스트 출력 부분 GenericAPIView로 변경

트러블 슈팅

  • 예약하기 부분 manager 사용해서 변경하기
  • 제네릭뷰 관련 수정 (blog)
    • to_representation - serialize 여러개 쓰니까 이부분에서 사용할 것
    • 결과적으로 제네릭뷰에는 get_queryset으로 해결할 것
  • search 부분 Django Search Filtering 사용하기

해야 할 일

  • to_representation 정리
  • generic view 와 api_view 차이 부분

0420

오늘 한 일

  • search 부분 search_fields으로 변경
    • 배포 후에 gitbook search 부분 parameter search 로 바꿔야 함
  • Search, blog 정리하기
    • to_representation
    • search_fields

바꿔야 할 부분

  • search url 바꾸기

해야 할 일

  • test코드 작성하기

테크멘토링 - 정경업님

  1. Django의 미래?
    • Node.js 로보다는 자바스크립트 수요로 생각하는 편이 낫다.
    • 프레임워크에 얽매이지 말자 계속해서 변화되는 상황에 적응해야 한다.
    • 파이썬을 더 잘 익히려고 노력하자. HTTP통신 분야에 대해 더 생각해보자
    • 사용법보단 원리를 좀 더 공부하자 ex) REST로 왜 사용하는가? , 도메인 지식을 파자
  2. 커뮤니티
    • 파이썬 코리아
    • 배운걸 발표하는 것도 좋을 듯 [목표로 삼자]
    • 협업을 하기 때문에 인맥도 중요하고 함께 의논하는 부분이 중요하다. [인사이트를 얻는 것]
    • 대화를 통해 회사 정보도 알 수 있다.[크레딧잡]
    • 파이콘 스텝
  3. 취업 부분
    • 내가 아는 것 vs 읽는 사람이 아는 것 - 글의 전달력이 중요하다./ 상대방이 정확하게 내가 무엇을 했는지 아는게 중요함(표준용어)
    • 글을 많이 쓰는 것이 중요함 -> 리뷰 -> 재작성 -> 이력서를 통해 내 이미지가 어떤지도 알아 볼 것
    • 내가 쓴글에 대한 자부심을 좀 줄이고 남에게 맞춘 글을 써보자
  4. 기술 면접 및 연봉
    • 우리 회사에 맞는 사람인가 아닌가에 대해 거르기 위한 것 같다. 그러니 유리 멘탈 방지!
    • 경험을 잘 표현하는게 중요하다.
    • 동등한 입장이라고 생각하자!
    • 회사가 줄 수 있는 금액이지 돈은 내 실력이랑은 무관하다.
    • 매출 10억 10명 / 투자규모로 알아 볼 수도 있다.
    • 인성 면접이 늘고 있다
    • 질문을 하자! (투자 금액으로 무언가를 하고 있는가? 복지? 야근 문화?)
  5. 자기계발
    • 결과적으로 잘쓴 글과 잘짠 코드의 속성은 비슷하다.
    • 동기, 의도, 목표
    • 많은 시도
    • 환경
    • 추가적 지식공유, 좋은 책, 강의, 등등
    • 기본적으로 세가지 것이 내게 주어졌는가에 대해 한번 생가해보기
    • 의도적 학습
  6. 잘 짠 코드
    • 잘쓴 글 (동의어라고 생각함)
    • 읽는 사람이 잘 받아드리는 것을 잘쓴 글이라고 생각됨 = ‘수용성’ = 이해
    • 코드에서는 정확하게 동작하게하는 명령어를 쓰는 것이 중요함 -> 명확하게쓰자! / 오해할만한 것들을 배재하자! = 결국 규칙을 잘 지켜야 한다.
    • 위와같은 것을 잘 하면 결과적으로 일의 효율성이 올라간다. 왜냐하면 이해하는데 쉬워지고 그렇다보면 더 발전 될 것!
  7. 캐시
    • select_related에서의 캐시는 약간 쿼리 최적화 이런식과 관련되어있다.
    • 임시로 저장하는 것이라고 생각 할 것

주말

물어 볼 것

  • property에 대해 : 원래의 경우 변수변경할때 get,set 방식으로 접근하는걸 편리하게 사용하려고 이용했던 것으로 아는데, 프로젝트에서 사용한 부분은 따로 필드를 만들지 않았는데 생성해서 사용한다. 원래 이런 용도로도 사용하는가?에 대해서도 그렇다면 왜 필드를 만들지 않고 이렇게 사용하는지도 여쭤보기
  • generic view -> update 부분 바꾸는것
  • test코드에서 예외처리 하는 부분