한 동안 포스팅을 못했다. 그간 있었던 일을 요약하자면,
- 팀이 바뀌었다
- 모 게임의 서버를 새로 짜는 작업을 하고 있다
- 회사에서도 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/ )를 써봤다..
홈페이지의 첫 예제를 여기 가져와보자면,
{% 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의 생산성을 다른 형태로 살렸다고도 할 수 있다. ((DB –> UI 로 넘기는 형태의 프로그래밍에서 작업할게 거의 없다))
경험담:
- python 코드 크기 절반으로. 기능도 추가했는데! (…)
- Jinja의 템플릿 언어가 python과 비슷하다. 적응하는데 5분이면 충분함.
- 페이지 레이아웃을 python 함수로 표현하는 건 무모했다. 적당한 hook을 만들기가 영; Jinja2의 템플릿 페이지 상속 기능으로 다 대체하는 편이 편했음.
- vim 용 문법 강조 파일도 제공함.
- JSON 응답도 템플릿 처리가 가능; 텍스트 형태의 응답이면 대부분 쉽게 될듯함.
라서 매우 편하게 작업했다. 팀 동료 몇 명에게 보여줬는데, 반응도 나쁘지 않았음.
내가 전에 작업했던 얘길 했더니 팀 동료 한 명은 이렇게 표현했음:
"이 생퀴 python으로 CGI 프로그래밍하지 마라"
Orz. 하..하지만 나 C로 CGI짜본 남잔데! (어이)
요약(?)
- 새 도구 좀 빨리 씁시다
- 머리가 나쁘면 손발이 고생
저도 예전에 ruby로 리포팅 프로그램을 만들었을 때, 결국 yaml을 적용하고서 엄청나게 편했던 기억이 있네요. web framework는 안쓰더라도, template 언어야 대체로 비슷비슷하니, 뭐가 되었든 얼른 적용하는 것이 효율적인 것 같네요. (그러고보니, C 계열에도 template 라이브러리가 있으려나..)
세라비 / 프로그래머가 편한 만큼의 추상화(=중력 줄이기?)가 있어야 역시 뭐가 되는 것 같아요. 아무래도 저처럼 하나에서 다 하려고 하면 캐망 Orz.
C 계열에도 템플릿 라이브러리도 몇 개 검색되긴 하네요 (…). C 컴파일이 좀 더 빨랐다면 (…), C Server Page 같은 걸 만들지도 모르지만… (도망간다)