Log

Today I Learned 날짜 2023년 12월 20일 수요일 내용 데모 관련 Task 끝 어제 발견했던대로, DB에 commit이 일어나면 object가 refresh되었다. Loading Relationships In the last step, we called [Session.commit()](https://docs.sqlalchemy.org/en/14/orm/session_api.html#sqlalchemy.orm.Session.commit) which emitted a COMMIT for the transaction, and then per [Session.commit.expire_on_commit](https://docs.sqlalchemy.org/en/14/orm/session_api.html#sqlalchemy.orm.Session.commit.params.expire_on_commit) expired all objects so that they refresh for the next transaction. SQLAlchemy docs에서 찾은 내용이다. db에 commit하면 현재 session의 object들이 expired되고, object를 새로 로드해야 한다. 로그인할 때, object로 계정 정보로 DB에서 관련된 shop들을 가져오는데, 데모 로그인떄는 데모 스토어로 사용할 shop만 가져오도록 로직을 작성했다. 이 object가 동기화되면서 내가 선택한 shop이 무용지물 되버린건데.. 내가 몰랐던 SQLAlchemy의 기능인 것 같다. ...

Today I Learned 날짜 2023년 12월 19일 화요일 내용 너무 힘들다. 흑흑 SQL 데모 로그인은 로그인의 로직을 이용해 만들었다. 로그인 함수가 호출되면, 해당 계정 정보가 관계를 갖고 있는 shop들을 불러와 shops 라는 배열에 담는다. 데모 로그인 때는, 가져온 후 데모로 설정한 shop_id와 일치하는 것만 남기도록 처리하였다. 이 과정이 DB에 영향을 끼치지 않도록 하기 위해, DB에 최근 접근 시간을 업데이트하고 commit하는 이후에 해당 로직을 추가하였다. shop들을 가져와 배열에 담는 joinedload에 특정한 조건을 추가하는 코드를 작성해야 했다. 사실 이 부분에서도 많이 헷갈렸는데, joinedload가 일반 join과 다른 점은 eager loading이라느 것이다. 간단히 말하자면 lazy-loading은 레코드를 조회할 때 연관관계가 있는 데이터들의 조회를 필요한 순간까지 미루는 것이고 eager-loading은 레코드를 조회할 때 연관이 있으면 다 가져와놓는 것이다. 지금 고민하는 부분과는 다른 이야기이니 차치하고, join과는 언제 연관된 데이터를 갖고 오느냐만 다르다는 의미이다. ...

Today I Learned 날짜 2023년 12월 18일 월요 내용 데모 어드민 페이지 만들기 지난 주에 했던 회고대로, 데모로 설정할 어드멘 계정을 환경변수로 설정할 이유가 없었다. 슈퍼관리자 페이지에 데모 계정을 설정 하는 기능을 만들고자 하였다. 그런데 내가 생각을 너무 얕게 했었다. 이 기능은 결국 DB에 현재 누가 데모 계정인지를 저장해야 한다. 이에 따라 두가지 방법이 떠올랐다. 데모 계정을 표시하는 새로운 테이블을 생성한다. 기존 계정(혹은 샵)이 저장된 테이블에 데모임을 표시하는 새로운 Column을 추가한다. 두 경우 모두 일이 생각보다 많이 커질 것 같았다.. 데모 계정 하나를 등록하자고 새로운 테이블을 만드는 것도 비효율적이라고 생각했고, 기존에 존재하는 Table을 수정하는 것은 더 최악으로 느껴졌다. 괜히 내가 잘 할 자신이 없어서 겁 먹은 건지, 진짜 이 방법들이 효용성이 떨어지는 지 확인받았다. ...

Today I Learned 날짜 2023년 12월 15일 금요일 내용 진행중인 Task가 마무리된듯 마무리 되지 않고 있다. 일사천리가 드문게 당연지사지만, 내가 미연에 방지할 수 있었을 텐데 그러지 못했다는게 문제다. 데모 사이트 만들기 이번주에 데모 관련된 작업을 마무리 하려고 했지만 다 못했다.. 형식상으론 마무리 되긴 했지만..? 어제 로딩페이지 관련된 CSS도 마무리 해서 테스트 서버에서 확인했는데, 코드와 관련해서 추가적으로 고칠 필요가 있었다. 우선 중복된 코드가 존재했다. 기존에 있던 로그인과 내가 새로 만든 데모용 로그인은 검증 성공시(엄밀히 말하면 데모 로그인엔 검증이 없지만) 똑같은 로직이었다. 복붙으로 만든 것이니 당연한 말이지만.. 따라서 성공 시 처리되는 로직을 새로운 함수로 분리시켰다. 5~6줄 정도 되는 짧은 로직이지만 그런 것들이 모여 전체 코드를 더럽게 만드는 거니까.. ...

Today I Learned 날짜 2023년 12월 14일 목요일 내용 테스트 서버에 데모버전 어드민 페이지 기능이 배포되었다. 환경변수 이전 TIL에서도 언급했듯, 유저에게 체험할 기회를 줄 데모 쇼핑몰과 데모 어드민 사이트는 우리가 환경변수로 계정 정보를 설정해야 했다. 이 계정 정보가 Shopify인지, 알파리뷰인지가 헷갈렸다. local에서 입력했던 정보로 알파리뷰와 Shopify 에서 각각 로그인했을 때, Shopify에서만 로그인이 되길래 Shopify 계정 정보라고 생각했다. 그런데, “우리가 Shopify 계정을 검증할 수 없는데 왜 받아야 하는가?”에 대해 대답할 수 없었다. 관련 코드를 열심히 찾다가 내가 간과했던 사실을 깨달았다. 데모버전 로그인에서는 비밀번호에 대한 검증 로직을 지웠다! 계정 정보를 우리가 설정한다는 이유로 지웠던 기억이 이제야 났다. 내가 테스트 했던 계정은 같은 ID로 알파리뷰와 Shopify에 모두 가입되어있다보니 헷갈렸던 문제였다. ...

Today I Learned 날짜 2023년 12월 14일 수요일 내용 데모버전 어드민 페이지 생성과 관련된 PR의 머지를 기다리던 중, 새로운 Task를 받아 파악하고 있었다. Notification Email Activation 문제 인지 우리 서비스에선 소비자에게 보내는 메일이 다양한데, 이 중 하나가 무언가 통지하는 이메일이다. 3가지로 분류되는데, 회원이 아닌 사람이 작성한 리뷰에 인증(Verification)을 요구하기 위해 보내는 메일이 그 중 하나이다. 다른 2가지와는 다르게 이 기능에만 활성화(activation) 조절 기능이 없는 상황이라 만들어야 한다. 여기에, 활성화 조절 시 현재 발송될 예정인 메일들에 대한 조치를 묻는 과정도 추가해야 한다. ...

Today I Learned 날짜 2023년 12월 12일 화요일 내용 Session 현재까지 데모버전으로 로그인을 한다는 것은 우리가 원하는 계정(데모 스토어를 위한 계정)에 자동으로 로그인 해주는 것 외에는 딱히 차이가 없었다. 해당 스토어를 체험을 위해 잘 구성하기만 하면 되겠다고 생각했다. 하지만 어드민 페이지에서 기타 store나 account에 대한 setting을 변경할 수 있다는 문제를 인지했다. 꼭 critical 하지 않은 정보들도 있겠지만, 쇼핑몰의 위젯이나 리뷰 관련된 컨텐츠들만 제공해야할 데모 버전이기 떄문에 불필요한 수정을 방지하는 것이 필요하다고 생각했다. 내가 탐색해본 결과, 알파리뷰 어드민 페이지에서 Settings에 들어가는 버튼은 2곳에 있다. 좌 하단과 우측 상단 user 아이콘을 클릭하면 나타나는 버튼. 데모버전에서는, 이 둘을 무력화해야했다. ...

Today I Learned 날짜 2023년 12월 11일 월요일 내용 구현 방향 데모용 어드민 페이지를 들어갈 때 로그인이 없어야 한다. 우리 서비스를 경험해 보고 싶은 사람에게 제공되는 기능이기 때문이다. 그 외의 것들은 우리 서비스와 동일해야 한다. 따라서 특정 쇼핑몰을 데모용 쇼핑몰로 만들고, 데모 로그인은 그 쇼핑몰로 접속하는 것을 의미한다고 판단했다. 로그인 로직을 아예 없앨지, 서버가 알아서 처리해주도록 할지가 고민되었다. 우선 알파리뷰 어드민 페이지로 접속하는 로직을 파악하기로 했다. 간단히 말하면, Shopify에서 unique 하게 설정하는 여러 값들이 존재한다. 내가 데모 로그인을 요청하는 유저의 verification을 대신 해주기엔 너무 복잡했다.. 따라서 기존 유저가 해야할 일을 내가 대신하는 방향으로 계획을 잡았다. ...

Today I Learned 날짜 2023년 12월 8일 금요일 내용 새로운 Task를 시작했다. 데모 사이트 고객들이 알파리뷰를 체험해볼 수 있도록 데모 쇼핑몰과 그 관리 페이지를 만들기 시작했다. 기존 어드민페이지는 로그인이 필요한데, 알아서 데모를 위한 계정으로 로그인하도록 구현할 예정이다. 기존에 있는 Shopify 계정에 데모용 쇼핑몰을 추가하여 설정하려고 했는데, 생각해보니 알파리뷰에는 계정에 속해있는 다른 쇼핑몰로 이동할 수 있는 기능이 있다. 따라서 고객이 다른 페이지에 접근할 수 있다는 위험성이 존재했다. 따라서 새로운 구글 계정과 shopify 계정을 만들고 여기에는 데모용 쇼핑몰만 설치할 예정이다. 이번 Task의 핵심 목표는 2가지 정도로 추려진다. ...

Today I Learned 날짜 2023년 12월 7일 목요일 내용 어제 확실히 해야하는 부분을 정리했기 때문에 질문으로 해결할 수 있었다. 기간을 2주로 잡았는데, 더 빨리 끝났다. 굿 Task 완료! Shopify에서 변경한 샵 정보를 shop 테이블에도 반영해야 하는가? 기존 코드에선, Shopify에서 샵의 정보가 변경되면 shop_detail 테이블만 업데이트 되었다. 샵의 이름은 2종류인데, Shopify에서 설정한 것과 알파리뷰에서 설정한 것이다. 기존에 파악했던 대로 shop 테이블은 Shopify에서 받아온 데이터를 그대로 저장해주는 테이블이고, shop_detail은 알파리뷰에서 생성된 데이터를 저장하기 위한 테이블이다. 그런데, Shopify에서 수정된 데이터를 shop_detail 에만 반영되는 기존의 코드는 이해가 잘 안됐다. 내가 모르는 또 다른 뜻이 있진 않을까 걱정됐다. 여쭤보니 없었다. 그래서 바로 고쳐버렸다. 슈퍼관리자 페이지에서 병기되는 두 이름 중 무엇이 우선인가? 기존 Shopify에서 설정한 이름만 출력되는 상황에서 두 종류의 이름 모두 출력하도록 변경해야 했다. 둘 중 하나는 괄호 내에 출력되야 하는데, 어떤 것을 집어넣야 할까? 질문을 통해 알파리뷰 이름이 우선인 것을 확인하고 Shopify 에서 설정한 이름을 괄호안에 집어넣었다. Shopify에서 샵의 이름을 변경하였을 때, 알파리뷰에서 설정한 이름도 변경되야 하는가? 1번 질문과 연계되는 이야기인데, Shopify에서 수정 시 웹훅을 통해 shop_detail 이 수정되기 때문에 기존에도 두 이름은 연관이 있었다. 혹시 아예 따로 관리되도록 해야 하는 지에 대해 궁금했지만, 질문을 통해 이대로 두는 것으로 결정했다. 좌상단에 나타나는 이름은 어떤 이름이여야 하는가? 좌상단에는 ALPHA REVIEW FOR { 샵 이름 } 이 나타난다. 기존에는 Shopify에서 설정한 이름이 나타나도록 되어있었으나 알파리뷰에서 설정한 이름이 출력되도록 변경하였다. 로그인 과정에서 해당 계정과 연관된 Shop들을 가져와서 세션에 저장한다. 이 데이터를 바탕으로 출력하기 떄문에, 세션에 알파리뷰에서 설정한 이름도 추가로 저장해주었다. 회고 개발 개꿀잼!!! 발목 깁스한건 노잼 ...