파이썬 실용 예제. 무역과 공공데이터

본 시리즈의 지난 포스팅에서 관세청 API XML parsing을 위한 연결가이드를 훑어 보았는데요. Parsing 코딩을 들어가기 앞서서, 최근 작업을 진행한 Django Rest Framwork(이하 'DRF')를 이용한 TradeNPU의 API 서비스 작성에 관련한 얘기를 좀 해볼까 합니다.  JSON의 형태로 Data를 return하는데 있어서, 편의성을 갖추고 있는 DRF를 통해 TradeNPU의 API 서비스에 대해 좀 살펴 보면, 관세청에서 제공하는 API에 대해서도 JSON과 XML의 형태차이로 인한 parsing법의 차이를 이해하는데, 도움이 되시리라 생각됩니다.    TradeNPU API 서비스 개략  TradeNPU는 통관 중에 발생되는 데이터를 활용하기 위한 다양한 기능들을 가지고..

지난 포스팅까지 ORM Read를 훑었고, 이번에는 나머지 Create, Update, Delete를 빨리 훑어보고자 합니다.  Django ORM Create, Update, Delete Django ORM의 Create이나 Update에 대해서는 공식문서를 통해서 방법을 상세히 안내하고 있습니다. 필자는 코딩과정에서 Create, Update와 Delete은 Class화하여 사용이 가능하겠다는 접근으로 코딩을 진행해 보았는데요.필자가 만든 서비스에서는 Model마다 field type, 갯수가 다 다르고, 각 View마다 고려할 요소가 많았습니다.  Class화 하기엔 너무 많은 고려요소를 반영해야 한다는 것을 느낀 순간, Class화 없이 View function마다 그냥 코드를 그대로 짜는 것으로..

지난 포스팅에 이어, Django ORM에 대해 계속 얘기해 보겠습니다.    Django ORM 객체 전달과 Custom Template Tag 활용하기   Django ORM은 all(), filter(), get() 메소드와 return시 순서정렬을 목적으로 한 order_by()정도만 있어도, READ에 있어서는 거의 모든 요구사항을 충족시킬 수 있습니다.   먼저, 아래와 같은 model을 정의해서 DB 테이블을 하나 구성했다고 해보겠습니다. class AdMon(models.Model): ad_owner = models.CharField(max_length=255, null=True, blank=True, default="NPU", verbose_name="광고주") ad_filen..

관세청에서는 민원인들을 위해 민원인들의 정보와 영업비밀을 보호할 수 있는 선에서만 개방된 OpenAPI 서비스를 제공하고 있습니다. 업무상 애플리케이션을 자체 개발해 활용할 수 있도록 다양한 데이터셋을 제공하고 있는데요.   TradeNPU에도 무역업체들이 공익성이 강한 이러한 데이터들을 쉽고 빠르게 접근해 활용하도록 도울 방법들을 구상 중에 있었습니다. 그리고, 이제 해당 프로젝트를 착수하여 TradeNPU를 통해 서비스를 제공할 예정인데요. 관련된 내용을 포스팅을 진행해 보고자 합니다.    관세청 OpenAPI 신청방법  관세청 OpenAPI 신청을 위해서는 관세청 Unipass 계정이 우선 필요합니다. 관세청 Unipass 계정을 최초로 만들 때엔 각종의 정보입력을 요구 받게 되는데요. 세금납부 ..

본 시리즈의 지난 포스팅에서는  {% block content %} 에 들어갈 내용을 가지고 상술하는 것으로 예고하고 글을 마감하였는데요. 해당 내용에 대해 다루기 위해서 이제, ORM에 대해 먼저 언급할 필요가 있어서 이번 글에서는 ORM 얘기를 이어 나가볼까 합니다.    Django ORM은 편리한가?   End-User와 어느 정도 소통하고, 업데이트가 끊임없이 발생하는 서비스를 만드는데 있어서, DB는 필수 불가결입니다. 정적페이지 하나 띄워놓고 특정 회사나 아이템에 대해 일방적으로 정보를 전달하고 마는 랜딩페이지 같은 것들이라면 당연히, End-User로부터 Data를 받아야 할 일이 없기 때문에, DB가 없어도 서비스가 가능합니다.  하지만, 조금만 기능을 넓히고 서비스영역을 확장하려고 해도..

Django의 Front-End 구성에 관한 얘기를 계속 이어 보겠습니다.  제가 Django를 처음 접했던 게 유튜브 컨텐츠를 통해서였고, 그때가 말그대로 본격적으로 HTML과 CSS를 만지기 시작한 최초의 순간이었습니다. 말을 좀 멋드러진 수사를 쓰긴 했지만, 말그대로 Front-End 코딩 Newbie도 아니고, Noob 였다고 해야되는 수준이었습니다.  그 전엔 PyQt5를 통해 GUI의 구성방식과 click event를 listening한다던가 하는 아주 처절하게 기본적인 개념을 대강 머릿속 어딘가에 때려 넣어 놓고 있던 때였습니다.  그래도 다행인건, PyQt5를 통해 쌓았던 것들이 많은 도움이 되어서 개념을 연결하고 이해하는데 큰 어려움은 없었던 것으로 기억합니다. 게다가, 든든한 'Stac..

지난 포스팅에서 back office를 구성하기 위한 로그인 기능 구현을 진행했습니다. 이제 원하는 방식의 페이지 표출을 위해 프론트엔드를 슬슬 만질 차례가 되었습니다.  사실 개인적으로 재밌기는 백엔드 코드 만질 때가 제일 재미있기는 합니다만, 어찌되었든 End-User는 Back-end에서 무엇이 돌든 내가 보고 싶은걸 당장 볼 수 있어야 하고, 원하는 정보에 빠르고 쉽게 도달할 수 있기만을 바란다는 것은 너무나도 명백한 사실입니다.  해서 개취는 백엔드이지만, 프론트엔드 구성에 있어서 불가피하게 심혈을 기울이는 시간을 더 쏟게 되는 것 같습니다.  실제 웹개발을 해보면 DB CRUD와 data manipulation 그리고, function의 결과물을 잘 return하도록 하는 것만 잘 되면 백엔드..

지난 포스팅 말미에서 말씀 드렸던 것처럼, 금번에는 JGTP 사이트에 back office를 만들기 위한 작업관련 내용을 기록해 보겠습니다.   Back office라는 표현이 맞는지는 모르겠는데, 제가 언급하는 Back office는 관리자를 위한 컨텐츠 관리용 페이지를 의미합니다. 해서, End-user에게 노출되진 않고, 관리자 및 관리자가 허용한 권한 있는 user가 접속하여 End-user가 홈페이지를 통해 보게될 각종의 컨텐츠를 관리하는 Admin page를 의미한다 하겠습니다.   TradeNPU가 기본적으로 Data manipulation 및 결과 Visualiztion 자동화까지를 추구하여 기능개발을 진행했던터라, Admin page를 만드는 것에 있어서는 이미 방대하다 할만큼의 코드를 ..

TradeNPU를 개발해 나가면서 가장 고민했었고 지금도 고민하고 있는 부분을 얘기하라면, "어떻게 해야 회원사들을 혁신에 참여 시킬 수 있을 것인가" 였습니다.  꽤나 고민을 거듭해 보면서, 이거 저것 시도하다보니, TradeNPU내에도 그러한 시도의 흔적들이 좀 남아있기도 하네요. 정말 다양한 시도를 해보았지만, 완전하다 할 수 있는 답은 아직도 찾지 못한 상태이긴 합니다. 다만, 가장 답에 가깝다고 여겨서 자체적으로 내린 결론은 결국 회원사들에게 실질적인 이득이 되는 일종의 '꿀'을 제공해야 한다는 것이었습니다.  동기를 유발 시킬 수 있는 이득이 되는 그 무언가가 있어야 혁신을 한번 시도해 볼만하다라고 여기리라 생각 되었습니다.  그래서, Knowledge Basket에 등록된 컨텐츠를 완전 오픈..