Today I Learned 날짜 2024년 12월 2일 월요일 내용 제공되지 않는 키워드 데이터 아임리포트에서 지속적으로 특정 계정의 데이터 업데이트 속도가 상당히 지연되는 문제를 겪고 있다. 그동안 확인해본 바에 의하면, 보고서에서 찾은 키워드 데이터가 우리 데이터베이스에 없어서 네이버에서 새로 불러오는 과정이 추가되었기 떄문이다. 그런데 왜 이 계정의 데이터만 유독 많이 불러와야 하며, 매일 매일 불러와야 할 정도로 키워드 데이터가 많이 추가되는지가 의문이었다. 이 부분을 확인하기 위해 로깅문을 찍어봤는데 원인을 알아냈다. 키워드 데이터가 없어서 네이버에 키워드 요청을 보냈지만 받는 응답이 비어있다. 다른 경우에는 작동하고 있기 떄문에 코드 자체의 오류도 아닐 뿐더러 요청에 대한 status_code 는 200인 것으로 보아 요청 자체가 문제가 있는 것은 아닌 듯 하다. 이리저리 찾아본 바에 의하면, 현재 시점에선 삭제된 키워드일 경우 보고서에는 나타나지만 해당 키워드의 상세 데이터는 조회할 수 없는 것으로 추측된다. 더 명확히 하기 위해 네이버 검색광고 github repository에 남겼으니 답을 기다릴 수 밖에 없겠다. ...

Today I Learned 날짜 2024년 11월 29일 금요일 내용 무한증식 커넥션 그저께, 커넥션 풀 문제가 생겨 한도를 늘려줘서 해결했다. 그런데 갑작스레 오늘 점심 쯤에 같은 오류가 발생했다. 그렇게 유저가 바글바글하지도 않은데 뭐지 싶어 RDS에서 커넥션 풀 그래프를 찾아봤다. 처음 50정도로 늘렸을 때 였다가 그저께 올리자마자 급격히 상승해서 유지됐다. 항상 연결이 많은걸로 보이는데, 피크타임도 없이 그렇다는게 뭔가 납득이 안됐다. RDS에서 어떤 경고(?)가 떠서 확인해보니 유휴 상태로 쓰이지 않는 트랜잭션이 너무 많이 유지되고 있다는 에러다. 유휴 상태는 데이터베이스에 접속해서 현재 유휴 상태인 트랜잭션을 확인했다. ...

Today I Learned 날짜 2024년 11월 28일 목요일 내용 중복 잘 되는 줄 알았는데… 중복 데이터가 나타난다는 테스터의 제보를 받았다. 딱 데이터 생성시점을 기준으로 30일 전 ~ 40일 전이 문제가 되었다. 아임리포트에서 데이터를 업데이트할 때는, 최근 30일 데이터만 가져오고 나머지는 S3에서 가져온다. 이걸 40일로 수정했는데 혹시나 S3에 누락된 데이터가 발생할 수 있기 때문이다. 그래서 40일치를 가져오고, 그중 30~40일 사이 데이터를 S3에 저장해서 혹시나 빈 것이 있더라도 잘 채워지도록 해놨다. 이 코드가 문제가 되었는데 (네이버 에서 가져온 140일차 데이터) + (S3에서 가져온 31365일차 데이터)가 합쳐지면서 3140일 차가 데이터가 두번 들어가게 되었던 것.. S3에서 가져올 때, 3041일차의 데이터는 빼도록 바꿔져서 해결했다. ...

8장 프로파일 현재까지 공부한 API 설계의 규칙 프로토콜 의미 체계의 문제 해결법 내 문제에 맞는 도메인 특화표준이 있다? ⇒ 사용 애플리케이션 특화 확장은 문서화 내 문제에 맞는 컬렉션 패턴이 있다? ⇒ 사용 애플리케이션 특화 용어를 정의하고 문서화 둘 다 해당되지 않으면? ⇒ 일반적인 하이퍼미디어 유형 사용 애플리케이션을 상태 전이로 나누고 문서화 애플리케이션 의미 체계의 문제 해결법 내 문제에 맞는 마이크로데이터 아이템이나 마이크로포맷이 있다? ⇒ 사용 문서화 없으면 애플리케이션 특화 용어를 정의 문서화 결국 문서화는 필요하다. ...

Today I Learned 날짜 2024년 11월 27일 수요일 내용 DB Connection Pool QueuePool limit of size 25 overflow 5 reached, connection timed out, timeout 30.00 (Background on this error at: https://sqlalche.me/e/20/3o7r) 왠 처음보는 에러가 자꾸 뜬다. 메시지가 참 심상치 않은데, 주로 뜨는 곳이 웹훅을 처리하는 부분이다. 마침 쇼피파이에서 앱 상태를 확인해보는데, 웹훅 처리율이 너무 낮아 사태가 꽤 심각하다고 느꼈다. 관련 메시지를 찾아보니, 데이터베이스에 연결하는 클라이언트가 동시에 너무 많아서 발생한 문제라고 한다. ...

Today I Learned 날짜 2024년 11월 26일 화요일 내용 HTML 검사 네이버 배너 이미지의 실 사용 상태를 스프레드시트에 업데이트 해준다. 거의 대부분(80~90%)가 미연동상태로 표시된다. 미연동 상태라 함은 우리 어드민에 접속해 배너이미지 삭제하기 버튼을 누르진 않았지만, 유저 본인이 네이버 상품 수정 페이지에서 우리 이미지를 삭제했다는 뜻이다. 우리 서비스를 이렇게 안 쓸리 없다는 희망을 품고 실제 미연동상태인 데이터들을 확인했다. 역시 실제로는 쓰는데, 미연동 상태로 표시되는 것들이 대부분이었다. 배너 이미지는 매 주 자동 업데이트 및 업로드 되는데 미연동상태로 처리되어 업데이트조차 되지 않았다. 뭔가 로직에 이상이 생겼다. ...

Today I Learned 날짜 2024년 11월 25일 월요일 내용 코드 정리하기 아름다운 사람은 머문 자리도 아름답다 카더라. 국내에서 개발을 어느정도 마치고 마무리하고 있다. 나중에 기능을 완전하게 활성화 할 때, 내 코드를 보는 사람이 누구더라도 알아 볼 수 있도록 했다. 엔드포인트 정리하기: 사실 이제와서 바꾸면 프론트 입장에서 화딱지가 나겠지만, 그렇다고 더러운 엔드포인트 이름은 두고 볼 수 없다. 처음부터 제대로 했으면 된다고? 생각이 안나는걸 어떡함? 함수 쪼개기: 코드가 기~인 함수는 보면 함수부터 나온다. 기능에 따라 최대한 나누어줬다. 인스타그램에서 데이터를 받아온다고 가정하면 받아오기 ⇒ 있는지 조회하기 ⇒ 저장하기 쯤으로 나눌 수 있겠다. 각주 적기: 클린 코드의 저자는 각주를 적을 필요가 없을 만큼 깔끔한 코드를 작성할 생각을 하라고 하셨다. 난 어느덧 그럴 수 없으니 각주를 적는다. 클래스 다시 확인하기: 코드를 쓰면서 종종 피어나는 클린 코드 독자로서의 자부심은 열심히 클래스를 정의하도록 만들었다. 정신차리고 보면 클래스에 온갖 잡다한게 다 들어간 강아지 장난감 보관함같다. 기능 별로, 작동하는 테이블명 별로 잘 나눠주자. 회고 PR 올리고 도망가려다가 코드리뷰에 붙잡혔다. 오랜만이라 무섭다. ...

Today I Learned 날짜 2024년 11월 22일 금요일 내용 장고에서 요청 본문 설정하기 인스타그램에서 게시글을 가져오고 있다. 이것저것 만들면서 엔드포인트를 만들어야 하는데.. 내가 원하는대로 되질 않는다! 1 2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 19 20 21 22 23 24 25 26 27 28 class InstagramFeed__InstagramFeedPostSerializer(serializers.ModelSerializer): class Meta: model = ... fields = "__all__" class ...View(BaseAPIViewMixin, APIView): def get_serializer_class(self): return ..._Serializer @extend_schema( operation_id=..., description=..., tags=..., ) def post(self, request: Request, shop_id: int): try: account_data = .. instagram_posts = ... serializer = self.get_serializr(instagram_posts, many=True) return Response( { "result": True, "detail": serializer.data, } ) except Exception as e: return Response({"result": False, "detail": str(e)}) 이렇게 해놨는데.. 저 InstagramFeedPost 가 반환되는 형태라고 가져다 놨더니 요청의 본문 바디에 저게 들어가고 앉았다. FastAPI에선 직렬화와 역직렬화는 신경쓰지 않아도 됐었다보니, 제대로 못쓰고 있는 것 같다. 게다가 응답도 객체 배열이어야 하는데, 그냥 객체로만 처리되고 있다. ...

Today I Learned 날짜 2024년 11월 21일 목요일 내용 장고 하이 국내 알파리뷰에 인스타그램 게시글을 가져와 위젯으로 만들어줘야 한다. 그동안은 FastAPI만 쓰다가 처음으로 장고를 쓰고 있는데.. 진짜 GPT 없었으면 큰일날 뻔했다. 미리미리 공부도 하고 질문도 좀 했는데, 막상 또 해보려니 쉽지 않다. 그나마 다행인건, 현재 국내 앱이 각 기능별로 잘 나눠져있다는 점이다. 내가 만드는 기능을 위해 내 디렉토리 내에서 모델, 직렬화, 뷰, 피쳐등을 생성하면 되니 다행이다. 그리고 기능 자체가 기존과 엮일 일이 많지는 않아 이미 존재하고 사용하고 있는 코드에 짜맞출 필요도 없고… 내 맘대로 하면 된다! ...

7장 순수 하이퍼미디어 설계 왜 HTML인가? HTML은 세상에서 가장 인기 있는 하이퍼미디어 유형이다. HTML의 기능 텍스트 문서의 중첩 구조를 표현할 수 있다. 택스트 콘텐트와 기타 태그를 표현할 수 있다. 하이퍼미디어 컨트롤 HTML은 다음과 같은 하이퍼미디어 컨트롤을 내장하고 있다. <link>, <a>, <img>, … 플러그인 애플리케이션 의미 체계 HTML은 사람이 이해할 수 있는 문서를 다룬다. HTML은 원래의 용도 외의 목적으로 사용하기가 매우 쉽다. HTML4는 세 가지 일반 속성을 더 가진다. rel : 연결되는 리소스와 지금 리소스 사이의 관계를 정의 id : 문서 내 한 요소를 식별하는 고윳값 class : 태그의 애플리케이션 의미 체계를 전달하는 용도(속하는 클래스를 정의) 마이크로포맷 hCard같은 마이크로포맷은 HTML에 추가적인 애플리케이션 의미 체계를 더하게 해준다. hMaze 마이크로포맷 새로운 hCard같은 마이크로포맷을 정의하는 것은 쉽다. 몇개의 클래스의 의미만 정의하면된다. 마이크로데이터 마이크로데이터는 HTML 5용으로 마이크로포맷을 다듬은 것이다. 다섯 개의 새로운 속성이 있다 itemprop : 마이크로포맷이 class 속성을 사용하던 방식으로 사용 itemscope : boolean. 태그에 마이크로데이터가 있는가를 표시 itemtype : 해당 마이크로데이터의 의미를 확인할 수 있는 곳 itemid itemref 마이크로포맷을 사용할땐 class=hCard 가 붙은 태그 내부가 모두 hcard 포맷임을 알 수 있다. 마이크로데이터는 그렇지 않다. itemscope 내부는 itemtype 이 가리키는 문서로 작성되어 있다고 표현된다. 예시 1 2 3 4 5 <div itemscope itemtype="https://www.naver.com/..."> <div itemprope="cell"> ... </div> </div> 마이크로포맷은 rel로 연결 관계를 정의할 수있지만 마이크로데이터는 그렇지 않다. itemtype 문서에는 나타날 것. 리소스 상태 변경하기 스위치를 누르면 리소스의 상태와 관계가 변경된다고 해보자 이 스위치를 조작하는 요청은 하이퍼미디어로 어떻게 구현될까? 폼에 애플리케이션 의미 체계 추가하기 rel 속성은 두 리소스 사이의 관계를 나타낸다. ‘리소스 상태를 변경하라’는 의미를 가진 rel 값을 만들 수 있을까? 리소스들이 나열되고 그 리소스를 요청하는 것은 GET 요청이다. 하지만 리소스 상태 변경은 GET 요청을 쓸 수 없다. POST를 써야한다. 이때 HTML이 정의한 하이퍼미디어 폼을 사용하면 된다. 대신, rel 속성은 지원하지 않는다. 이 switch 클래스도 hMaze 마이크로포맷에 추가할 수 있겠다. 1 2 3 <form action="/switches/4" method="post"> <input class="flip" type="submit" value="Flip it!"/> </form> 하이퍼미디어의 대체재는 미디어다 요즘 API 문서들에는 많은 메서드가 개별 API 호출로 노출되고, 상세하게 문서화되어 있다. 이는 다시 말해, 사람이 읽을 문서를 하이퍼미디어 대체재로 사용하고 있다는 것이다. 사람 대신, 이 정보를 받도록 의도된 대상(소프트웨어)에 맞춰 작성해야 한다. 스위치를 나타내는 두 버전을 살펴보자 1 2 3 4 스위치를 조작하려면 다음 주소로 POST 요청을 보낸다. https://api.example.com/swithches/{id}?action=flip {id}는 스위치 ID다. 스위치가 있는 셀에 있을 때에만 스위치를 조작할 수 있다. 1 2 3 4 5 6 7 <div class="swithch"> <span class="position">down</span> <form action="/swithches/4" method="post"> <inpuit class="flip" type="submit" /> </form> </span> </div> 애초에 하이퍼미디어 컨트롤을 사용할 수 있을 때만 제시되므로, 셀에 있을때에만 조작할 수 있다는 경고문구는 제공할 필요도 없다. HTML의 제약 기술적으로 HTML은 일반 하이퍼미디어 포맷이 아니라 도메인 특화 표준이다. 여기서 발생하는 한계들이 있다 PUT, DELETE는 HTML 하이퍼미디어 컨트롤로는 표현할 수 없다. HTML 4의 폼은 두 가지 종류의 엔티티 바디만 만들 수 있다. application/x-www-form-urlencoded multipart/form-data HTML 4는 JSON과 달리 숫자와 문자열을 구분하지 않는다. HTML 4는 날짜를 표시할 방법을 정의하지 않는다. HTML5가 문제를 해결해 줄까? 보완점 날짜 문제 ⇒ time 태그로 해결 숫자 문제 ⇒ 일반적으로 동작하지 않음 몇 가지 컨트롤을 더 정의하나, 여전히 유용하지 않음 input 태그 검증을 위한 방법 정의 일부는 보완되나, 하이퍼미디어 포맷으로서의 HTML을 급격히 변화시키지는 않는다. 하이퍼텍스트 애플리케이션 언어 웹 API에 특화되어 설계된, HTML의 기본 개념인 하이퍼링크만 가져온 HAL(Hypertext Application Language)가 있다. HAL은 두 가지 방식으로 제공된다. XML(application/hal+xml) JSON(application/hal+json) HTML과 HAL의 차이 HTML에는 여러가지 경우에 따라 <a>, <img>, <form> 을 사용한다. ...