Today I Learned 날짜 2024년 7월 10일 수요일 내용 데이터 상태 처리 가져올 데이터가 많다보니, 처리에 시간이 꽤 걸린다. 따라서 유저에게 요청에 대한 응답을 보낸 후, 백그라운드에서 처리되야 한다. 대신 계속 유저에게 상태값을 알려줘야 한다. 기존에는 로우데이터가 가지는 상태의 종류는 두 가지였다. 유저가 로우 데이터 포맷을 만들면, 즉시 데이터를 임포팅해온다. 유저는 이 임포팅 상태를 알아야 한다. 진행 중인지, 대기중인지, 뭔가 잘못되서 실패했는지, 완료했는지를 임포팅 상태라고 부르고 관리하기로 했다. 위에서 말했듯, 요청은 꽤 많은 데이터를 주고 받는 작업이기 떄문에 동시에 하나씩만 처리하기로 했다. 유저가 짧은 시간내에 여러개의 로우데이터 포맷을 만들더라도 하나만 진행하고 나머지는 대기열에 두어야 한다. 클라이언트는 서버에 어떤 로우데이터 포맷의 임포팅 상태를 묻고, 서버는 그 상태를 반환하되 대기열이 있다면 대기열을 보내주도록 구현했다. ...

Today I Learned 날짜 2024년 7월 9일 화요일 내용 추상클래스 처리형식 여러 형태의 필요한 데이터들을 가져와 스프레드시트에 추가하는 기능을 만들었다. 대동소이하기 떄문에 추상클래스로 나름 깔끔하게 만들어봤다. 음청나게 길긴 하지만 결국 마지막 update_spreadsheet() 만 불러오면 된다. 이 클래스를 상속받아 데이터 타입별로 클래스를 생성했다. 그떄그떄 그 클래스를 불러오기 불편해서, 데이터타입에 맞게 알맞은 클래스를 불러오는 클래스를 추가했다. 저 변수 넣는것만 보기좋게 다듬으면 좋겠는데.. 어쩄든 클래스로 관리하니 요청 라우터는 깔끔해졌다. 회고 생각보다 구현이 잘되서 당황스럽다… ...

Today I Learned 날짜 2024년 7월 8일 월요일 내용 검색광고 데이터 가져오기(2) 기본적인 기능 구현을 완료했다. NSA_GTD, NSA_CTD 로우 데이터를 만들 때는 2가지 대용량 보고서를 만들고 데이터륿 참조해야한다. 네이버에선 100개 이상 보고서가 생성되면 가장 오래된 것을 기준으로 삭제해버린다. 이 두 가지 로우데이터는 최대 400일치 분량의 데이터를 가져와야하므로 하루에 2가지, 총 800개 보고서를 만들어서 데이터를 가져와야 한다. 보고서의 날짜는 하루짜리밖에 안된다. 100개 이상의 보고서를 만들 수 없으므로 나누어서 100개를 만들고 데이터를 취한다음 다음 100개를 다시 만들어야한다. 이때 기존에 만들어 놨던 100개는 삭제된다. ...

화씨 451 지은이: 레이 브래드버리 옮긴이 : 박상준 출판사: 황금가지 감상 페이커 추천 도서 목록에서 읽은 두번째 책. 53년에 발간된, 상당히 오래된 디스토피아적 미래를 그린 소설이다. 책은 소유하거나 읽어선 안된다는 법 떄문에, 소방서와 소방수 대신 방화서와 방화수가 존재한다. 책이 있다는 신고를 받은 집으로 찾아가 집을 불태워 버리는 존재들이다. 미래 소설이기 떄문에, 등장인물들은 현재의 우리를 구전으로만 내려오는 과거 이야기로 치부하며 말도 안된다고 여긴다. 예를 들어, 불을 지르는 방화수 대신 신고를 받고 불을 꺼주는 소방관이 있었다던가 하는 이야기들. 주인공을 제외하고 가장 주요해보이는 등장인물은 방화서장이다. 사회가 어떤 흐름으로 모든 책을 불태워버리자는 극단적인 사회로 변하게 되었는지, 이로 인해 얻은 것이 무엇인지 적나라하게 말해주는 인물이다. ...

Today I Learned 날짜 2024년 7월 5일 금요일 내용 프리커밋 하나의 레포지토리에 여러 사람이 코드를 쓰는일이야 너무나 흔하다. 사람이 쓰는 자연어야 맞춤법을 규정하는 기관이 있지만(국립국어원), 코드는 꼭 그렇지는 않다. 팀마다, 사람마다 다르다. 들여쓰기는 4칸을 쓸것인가 2칸을 쓸것인가? import 문의 순서는 어떻게 둘것인가? 왜 중요할한가? 내가 변경사항을 깃에 올렸을때, 파일 전체의 들여쓰기가 원래 2칸이였다가 4칸으로 변경됐다면? 깃허브에서 파일의 변경점을 보여줄 때 파일 전체를 보여줄거다. “유의미한, 기능상 실질적인 변화”만 보여주는 건 불가능하다. 실제로 봐야할 곳은 1줄인데, 기록상으론 파일 전체가 바뀐셈이 되버린다. 모든 들여쓰기가 2칸 늘어났기 떄문이다. 코드 리뷰 하는 사람 입장에선 도대체 어디가 바뀐건지 눈이 빠지게 찾아야한다. 나중에 커밋 기록을 보려는 사람은 도대체 어디가 바뀐건지 알 턱이없다. 특히 깃렌즈를 쓰면 더욱. 그래서 코드 맞춤법을 맞춰야한다. ...

Today I Learned 날짜 2024년 7월 4일 목요일 내용 임베디드 앱은 다르다. 큰일났다. 인스타그램 댓글을 가져오는 스프린트가 다 끝나고, 검수만 남아있었다. 무려 10번의 요청 끝에 렙틸리언 에게 앱 허가를 받아냈는데, 쇼피파이가 복병이었다. 임베디드 앱은 우리가 몰랐던 규칙이 있었다. 바로 shopify app birdge를 사용해야 한다는 것. 이걸 이용해, 사용자의 세션 토큰을 검증해야 한단다. 우린 전혀 쓰지 않는데… 뭔지도 모르겠고 어떻게 해결해야할 지도 몰랐다. 기존대로라면, 정해진 검증이 끝나면 우리가 설정한 곳으로 유저를 리다이렉트 시킨다. 유저는 아이프레임 내에 우리가 구현한 화면을 볼 수 있게된다. 근데, 앱 브릿지로 검증할 때 앱 설정에서 입력한 URL과 우리가 이동시키는 URL이 일치해야 한다. 말하면서도 어렵긴한데… 풀어서 설명하자면 ...

Today I Learned 날짜 2024년 7월 3일 수요일 내용 데이터륿 받아오는 시점 아임 리포트 개발을 진행중 예상치 못한 부분이 나타났다. 유저가 네이버 검색광고 계정을 등록하면 필요한 데이터를 가져오도록 개발했다. 순서대로 관리자 계정 → 관리자 계정에서 관리하는 모든 계정들 → 각 계정들 내에 존재하는 모든 캠페인 → 각 캠페인 내에 존재하는 모든 광고그룹 → 각 광고그룹 내에 존재하는 모든 키워드 를 가져오도록 해놨다. 필요한 데이터를 조회할 떄, 키워드별도 존재하고 광고그룹 별도 존재하고 여러가지가 있는데 매번 필요한걸 네이버 API에서 가져오는게 불필요하다고 생각했다. 어차피 매일 쓸건데 가지고 있는게 낫지 않을까? ...

Today I Learned 내용 열심히 스프린트 진행중. 페이스북 앱 검수 9차 요청 또 페이스북 앱 검수 요청에 또 실패했다.. 인스타그램 댓글을 가져오기 위해 필요한 권한은 총 3가지인데, 그래도 그 중 2개까진 통과했다. instagram_basic 권한이 필요한걸 확인이 안된다는데.. 아니 인스타그램 댓글을 가져오는 기능을 보여줬는데도 모르겠다 그러면 어쩌라고… 일단 만들기 새로운 앱 서비스를 만드는데, 일단 기능만 완성하려고 열심히 함수위주로 만들고 있다. 만들면서도 이건 클래스로 잘 묶어보면 보기 좋겠다 싶은데, 구글 API Docs 읽으면서 안되는게 되게 하느라.. 일단 구현이 우선이라 생각하고 빨리 만들려고 한다. 구글 드라이브 에서 파일과 폴더를 조회하고, 내부 서브디렉토리를 조회하는 함수를 만들었다. ...

Today I Learned 날짜 2024년 7월 1일 월요일 내용 활성화 유저 체크 우리의 서비스(프로덕트 리뷰, ai, 리스트디자이너)를 사용하는 유저들을 탐색해서 저장하는 기능을 만들었다. 코어스크립트 활성화 여부, 앱블록 활성화여부를 확인하는 작업이라 이것저것 오류가 많이난다. 원인은 쇼피파이에서 테마를 가져와 우리의 앱블록(위젯)을 사용하는지 확인하는 과정에서 테마가 원하는 형태가 아닐 때가 많기 때문이다. 심지어 json 타입이아니라 string으로 올때조차 많은지라 온갖 예외처리가 덕지덕지 붙어있다. 브라우즈 부스터를 개발하고, 이 데이터에서 브라우즈부스터도 추가해주었다. 어느 순간 확인해보니 작동이 안되고있다! 또 뭐가 말썽인가 싶어 열심히 들여다 본 결과를 찾아냈다.. 로직이나 문법이 잘못된게 아니라 스키마를 최신하 안해줬다.. 진짜 별것도 아닌데, 오류 메시지도 뜨지 않고 멈춰서 찾기 힘들었다. ...

Today I Learned 날짜 2024년 6월 28일 금요일 내용 스프린트 계획 스프린트 계획이 완성됐고, 다음주부터 시작된다. 플래닝미팅을 위한 공수를 작성하다가 놓치고 있는 부분을 몇 개 알게 되었다. 브랜드는 진짜 브랜드가 아니었다. 관리자 계정에 엮여있는 여러 계정들 하나하나를 브랜드라고 불렀던 것이고, 계정 내에 있는 캠페인을 분류할 필요가 없었다. 따라서 브랜드 테이블은 필요가 없게 되었고 고민은 해결되었다. 구글 드라이브 디렉토리 정보를 저장할 필요가 없었다. 구글 드라이브 내에 폴더들을 가져와 데이터베이스에 저장하려고 했는데, 생각해보니 굳이..? 싶다. 그냥 하위폴더나 상위 폴더를 열때 그 디렉토리 정보를 가져오도록 구글에 보내는 요청을 만들 계획이다. 각 계정(위에서 말한 브랜드)가 어떤 템플릿과 로우데이터를 사용중인지 알고 있어야 한다. 그에 대한 테이블도 만들었다. 데이터 임포트 상태를 표시하기 위한 작업이 필요하다. 임포트가 진행되는동안 또 다른 요청이 발생하지 않도록 상태를 추적하기 위해, 임포트 로그를 위한 테이블이 필요하다. 3주간 레츠고 ...