Project

adidas clone 프로젝트 소개 스포츠 브랜드 adidas 한국 웹사이트를 클론하는 프로젝트. 모든 카테고리가 아닌 남성 신발로 범위를 한정하여 구현. Frontend와 처음으로 협업을 진행을 하고 github을 처음으로 사용. 구성원 Frontend 2명 B

modeling을 진행하며 각 테이블에 대해 다양한 관계를 생각하게 되었다.해당 제품이 어떤 category, sport, tag 등에 속하는지 생각을 해야 하며 이를 통해 어떤 테이블까지 접근할 수 있는지 고려해야 된다는 점을 알게 되었다.각 테이블들이 어떤 관계(o

modeling한 관계도를 보며 models.py를 구현하였다. 초기 관계도와는 많이 달라졌다.Models.py 코드를 작성하며 많은 수정이 이루어졌다. 하나의 상품의 경우 다양한 카테고리에 속해 있기 때문에 Foreignkey 설정을 하며 새롭게 이해한 부분이 많았다

실제로 select_related, prefetch_related를 사용하였다.각 Table들의 연결을 통해 다양하게 접근하여 원하는 데이터를 조회할 수 있다는 점이 재밌게 느껴졌다.처음에 역참조에 대한 부분이 이해가 되지 않았지만 실제로 사용을 해보고 shell을 통

이번 프로젝트의 경우 해당 화장품 아이템들이 다양한 카테고리에 중복으로 포함되는 부분이 많은 생각을 하게 하였다. 하나의 제품이 다양한 카테고리에 중복되어 포함되기 때문에 categories라는 테이블에 다양한 조합의 카테고리를 생성하고 products 테이블 중간에

회원 가입을 구현하기 위하여 다음과 같이 models.py를 구성하였다.password와 phone_number의 경우 social_login 유저들의 경우 해당 정보들을 알 수가 없어 null=true로 설정을 하였다.일반 회원 가입에 성공하면 회원가입 시 입력한 폰

Decorater를 사용하여 웹사이트 내 다양한 곳에서 로그인을 검증하였다.이때 객체를 통째로 토큰화 시키는 것과 객체에 대한 id_number만 보내는 것에 큰 차이가 있는 것을 알았다. 이번 프로젝트의 경우 객체를 토큰화 시켜 사용을 하였는데 다양한 곳에서 활용도가

이번 프로젝트에서 가장 힘들었던 부분이다. unittest에 대한 중요성은 이해가 되었지만 어떻게 구현할지 막막하게 다가왔다. 내가 구현한 기능들을 어떤 방식으로 test 할지 코드를 어떻게 시작해야 할지 망설였다.그리고 현재 DB에 저장된 데이터와 setup을 통해

장바구니와 결제를 구현하고자 models.py를 만들었다.처음 생각한 부분은 order 테이블을 만들어 주문이 생길 경우 하나의 order 데이터를 만들어 구현을 하고자 하였다. 하지만 이런 방식은 데이터의 중복이 많이 생길뿐더러 효율적이지 못한 방법이였다. 제품과 주

장바구니 기능을 구현하면서 login_decorater 기능을 test 할 때 생각한 가짜 토큰 값을 사용하였다. client에 HTTP_Authorization 값을 임의로 설정하여 header에 id 토큰 값이 담긴 것 같은 효과를 내었다. 다른 부분들은 크게 다르

laneige clone 프로젝트 소개 뷰티 브랜드 laneige 웹사이트를 클론하는 프로젝트. 스킨케어, 옴므 카테고리로 한정하여 구현. 웹사이트 자체에 장바구니 기능이 없어 frontend 팀원분들과 상의하여 구현. Github Githubadidasclone