Python Jinja2

한 동안 포스팅을 못했다. 그간 있었던 일을 요약하자면,

  • 팀이 바뀌었다
  • 모 게임의 서버를 새로 짜는 작업을 하고 있다
  • 회사에서도 linux 서버를 만지기 시작

첫 번째 일과 두 번째는 사실 한 몸이고; 나머지에 대해서 기록;

저 linux 서버 위에 예전에 짰던 크래시 덤프 수집하는 녀석을 올렸다. Windows + IIS + MSSQL Server + WSGI  (isapi 사용) application 이던 걸 linux + apache2 + MySQL (or CouchDB) + WSGI (mod_wsgi) 로 옮겼다. 실제 서버는 아마 nginx proxying + gunicorn 같은 애를 쓰게 되지 않을까 싶지만;

저기로 옮기면서 페이지도 페이스 리프팅. 원래 좀 중구난방이던 크래시 덤프 보기 페이지에 시간 대 별 보기라거나, 카테고리 기능이라거나, failure bucket id (windbg 얘기) 로 분류하기 등등을 넣었다. 덕분에 거의 0이던 jquery 프로그래밍 경험치가 충전된 듯 (…).
아무래도 이건 혼자 쓸 것만 만들다가 Firefox / Chrome이 아닌 웹 브라우저에서도 동작하게 해서 그런 거지만;

내가 처음 짠 코드의 문제가 CherryPy 에서 html 코드를 직접 토해낸다는 점. 간단한 건 그냥 문자열 혹은 문자열의 list로, 좀 복잡하면 문자열 yield return으로 때웠는데, 코드가 좀 길어지니까 감당이 안되더라. 일단 이걸 내가 계속 진행할 수 있는 처지가 아니라서 – 요약 1 참조 – 다른 프로그래머에게 넘겨주게 생겼는데 얘기하다 나온 게

  • 유지 보수가 가능한가? Python을 중점적으로 쓰는 나와 ipkn 말고 유지가 가능한가?
  • 굳이 linux 서버를 쓸 이유가?

이 두 가지. 그래서 목표가 "다른 프로그래머가 적응하는 시간을 줄이자", "문서를 최소한만 쓰자"로  데, 이건 대략 만족한 듯. 만약 이걸 asp.net 으로 옮긴다고 해도 로직 / 화면 두 가지만 분해되어 있으면 어떻게 될 거라고 믿기로 하고 (하략). 매우 저 수준으로(…) html을 직접 토해내던 WSGI application을 좀 분해하기로 했다. ipkn의 조언에 따라 – 그리고 손에 든 것만으로 문제를 푸는 나의 나쁜 습관을 가까스로 극복하고 – 템플릿 언어를 하나 골라서 써 보기로 했다. 그래서 flask 쓸 때 잠시 봤던 신사 (jinja2; http://jinja.pocoo.org/ )를 써봤다..

홈페이지의 첫 예제를 여기 가져와보자면,

{% extends “layout.html” %}
{% block body %}
  <ul>
  {% for user in users %}
    <li><a href={{ user.url }}>{{ user.username }}</a></li>
  {% endfor %}
  </ul>
{% endblock %}

 

정도인데; layout.html의 내용을 상속하고, (아마도 이중 일부인) body 블록을 override하는 예제. {{ }} 안의 내용은 print, {% %} 안은 제어문이 들어간다. 대략 있을 건 다 있음. 제대로 만든 PHP 같다고 누가 얘기했는데 누구였는지 까먹었다. 참고로 저 for 문 마지막에 : 찍어도 된다 (…). 레이아웃 코드에 제어문이 있는 걸 싫어하는 사람도 있지만 난 PHP도 싫어하지 않는 성향이라; 이 정도면 오히려 적절한 조합이 아닌가 싶다.

html 템플릿 파일 쪽만 봐도 내용을 어느 정도 알 수 있고, 중복 제거도 쉽고, python 쪽에서 미리 데이터를 구워(?)두기도 편한 편. 극단적으로 말하면 2000년 즈음의 VBA의 생산성을 다른 형태로 살렸다고도 할 수 있다.[1]

경험담:

  • python 코드 크기 절반으로. 기능도 추가했는데! (…)
  • Jinja의 템플릿 언어가 python과 비슷하다. 적응하는데 5분이면 충분함.
  • 페이지 레이아웃을 python 함수로 표현하는 건 무모했다. 적당한 hook을 만들기가 영; Jinja2의 템플릿 페이지 상속 기능으로 다 대체하는 편이 편했음.
  • vim 용 문법 강조 파일도 제공함.
  • JSON 응답도 템플릿 처리가 가능; 텍스트 형태의 응답이면 대부분 쉽게 될듯함.

라서 매우 편하게 작업했다. 팀 동료 몇 명에게 보여줬는데, 반응도 나쁘지 않았음.
내가 전에 작업했던 얘길 했더니 팀 동료 한 명은 이렇게 표현했음:

"이 생퀴 python으로 CGI 프로그래밍하지 마라"

Orz. 하..하지만 나 C로 CGI짜본 남잔데! (어이)

요약(?)

  • 새 도구 좀 빨리 씁시다
  • 머리가 나쁘면 손발이 고생
  1. DB –> UI 로 넘기는 형태의 프로그래밍에서 작업할게 거의 없다 []

Published by Jinuk Kim

SW Engineer / gamer / bookworm / atheist

Join the Conversation

2 Comments

  1. 저도 예전에 ruby로 리포팅 프로그램을 만들었을 때, 결국 yaml을 적용하고서 엄청나게 편했던 기억이 있네요. web framework는 안쓰더라도, template 언어야 대체로 비슷비슷하니, 뭐가 되었든 얼른 적용하는 것이 효율적인 것 같네요. (그러고보니, C 계열에도 template 라이브러리가 있으려나..)

    1. 세라비 / 프로그래머가 편한 만큼의 추상화(=중력 줄이기?)가 있어야 역시 뭐가 되는 것 같아요. 아무래도 저처럼 하나에서 다 하려고 하면 캐망 Orz.

      C 계열에도 템플릿 라이브러리도 몇 개 검색되긴 하네요 (…). C 컴파일이 좀 더 빨랐다면 (…), C Server Page 같은 걸 만들지도 모르지만… (도망간다)

Leave a comment

Leave a Reply