이렇게 쓰면 됩니다.

모델.get_or_insert(키, 값들)

Hannal 이라는 모델을 예로 들지요.

class Hannal(db.Model):
	name = db.StringProperty(required=True)

name이라는 프로퍼티만 있는 클래스이지요. 이 모델에 자료를 하나 넣어보지요.

Hannal.get_or_insert(‘key_0000001′, name=u’Hannal Cha’)

이러면 key_0000001 를 키(id)로 갖는 자료를 찾아보고 있으면 그걸 가져오고 없으면, key_0000001를 키로 하고 name 은 u’Hannal Cha’인 자료를 집어넣습니다.

주의할 점은 바로 이 키인데요. 이 키 문자열 맨 앞이 숫자로 시작하면 Names may not begin with a digit 라는 오류가 납니다. 키 자료형이 문자형이어도 마찬가지입니다. 자료형을 따지는 게 아니라 키 문자열의 맨 앞 문자가 숫자인지를 따집니다.

유레카! 를 외칠만큼 위대한 발견을 한 건 아닙니다. 오류 내용에서도 비록 영문이긴 하지만 숫자(digit)으로 시작하면 안 된다고 알려주니까요. 다만, 보통은 키라 하면 일련번호 id로 관리하기 때문에, 그리고 저처럼 초보들은 눈에 익지 않은 오류가 나면 겁부터 먹기 때문에 종종 당할 듯 해서 적어둡니다. 저는 친절하거든요.

그래서 저 강좌를 토대로 후속편, 아니 정확히 말하자면 확장판을 준비하고 있습니다. 저번처럼 새로 다 쓰는 건 아니고요. 지난 글 중 1.0판에서 제대로 쓸 수 있게 일부 내용을 보완하는 겁니다.

연재 시작하면 다시 알릴게요.

저야 진작 0.97시험판이나 1.0시험판을 써오던 터라 큰 불편없지만, 혹 0.96판을 쓰던 이라면 0.96판을 기반으로 하는 자신의 코드를 1.0으로 손보는 안내 문서를 참조하면 무난히 처리할 수 있습니다.

바뀐 부분이 꽤 많습니다. 가장 반가운 점은 Django 내부에서 문자열 처리는 유니코드로 통일한 점입니다. 예를 들면 0.96에서는 UTF-8 문자열을 받고, 이를 모델로 넘겨서 DB에 넣을 때는 encode(‘utf-8′) 메소드를 이용하여 ASCII 문자열로 인코딩한 UTF-8 문자열을 넣어야 했습니다. 그러나 이제는 그냥 바로 넣으면 됩니다. 또 이와 관련하여 모델에서 쓰던 __str__ 메소드도 없어지고 __unicode__ 만 쓸 수 있습니다.

두 번째는 폼(forms)이 newforms 로 바뀐 점입니다. 이전까지는 0.96에써 쓰던 forms 를 oldforms 로 쓸 수 있었는데 이젠 아예 없어졌습니다.

세 번째는 admin mode 입니다. 예전엔 admin mode 를 사용하려면 models.py 등을 건드려서 코드가 이곳 저곳에 흩어졌는데, 이제는 admin.py 으로 정리하면 됩니다. 그래서 admin mode 를 열고 웹에서 접근하는 방법(urls.py 등)이 꽤 바뀌었습니다.

다국어 환경(i18n) 기능 중 po 파일과 mo 파일 만드는 방법도 살짝 바뀌었습니다. 예전에는 make-messages.py 가 po 파일을 만들고, compile-messages.py 가 mo 파일을 만들었는데, 이젠 이 두 파일에 있던 기능이 django-admin.py 안으로 들어갔습니다. django-admin.py makemessages 나 compilemessages 라고 하면 됩니다. 근데 make messages는 여전히 파일 확장자가 py 인 것만 잘 추려내서 po 파일로 만드네요. -e html 이렇게 추가 확장자를 넣어도 html 것은 잘 안됩니다. django 쪽 문제는 아닌 것 같지만요.

request 객체도 눈 여겨볼 만 합니다. request 객체는 urls.py 에 연결해놓아서 이용자 요청을 처리해주는 view 콜백함수(callback)에 인자로 넘어오는데, 예전엔 별 기능이 없었습니다. 그러나 0.97부터는 이용자가 ajax 방식으로 접근한 것인지를 확인할 수 있는 is_ajax 메소드 등 편리한 기능이 많이 생겼지요. 이용자가 form 으로 올리는 파일을 받아 처리하는 파일 업로드 부분도 깔끔하게 정리 됐습니다.

재밌는 건 GeoDjango 라는 모듈입니다. 예전엔 몰랐는데 이런 게 들어가서 /django/contrib/gis 에 예쁘장하게 자리 잡고 있군요. GeoDjango는 간단히 말해서 위치(Geographic) 정보를 다루는 GIS를 지원하는 추가 모듈입니다. 예전에 지도와 연동되는(mash up) 시험용 서비스를 만든 적이 있는데, 위치값 처리가 영 귀찮았습니다. 근데 이런 걸 처리해주니 한결 편해지겠네요. 거리 관련 쿼리(Distance queries) 내용을 보시면 쓰임새를 바로 이해하실 수 있습니다. 제 관심사와도 맞는 모듈이라 무척 흥미롭습니다.

이외에도 많은 부분이 개선되고 추가 되었습니다. 단지 제가 0.96을 안쓴 지 좀 돼서 비교를 더 하기 힘들군요. ^^;

아쉬운 점은 이번에도 다중 DB 접속 기능이 안들어갔고, 모델 API로 group_by 가 안들어갔네요. 1.0시험판에도 들어가있지 않았기에 별 기대는 안했지만, 막상 정말로 추가 안된 걸 보니 아쉽긴 합니다.

0.96판도 꽤 좋았지만, 1.0판에 들어서면서 정말 편하고 강력한 모습으로 탈바꿈 했네요. 비록 0.96판을 기준으로 했지만, 실제 코드 작성은 0.97판을 기반으로 해서 1.0정식판에서도 강좌 내용에 별 영향이 없는 날로 먹는 Django 웹 프로그래밍 강좌를 보며 보다 강력해진 Django 1.0을 써보세요. 추천합니다.

이미 비슷한 서비스가 있는데 굳이 직접 만들어서 고생할 필요 있나 생각이 들기도 하지만, 내 기획을 또 한 해 넘겨 묵히며 죽일 순 없다는 오기도 들어서 만들지 않을 수가 없더라. 지향점이 저 서비스와 다른 점도 큰 이유이다. 내가 만들고자 하는 건 “책 많이 읽는 도서관 사서 같은 서비스”이기 때문이다.

어쨌든 만들고 있다. 작동 환경은 웹이다. 파이썬용 웹 프레임워크인 django 로 뒷단(back-end)을 만들고 있으며, XHTML 1.0과 CSS, 그리고 javascript 로 앞단(front-end)을 만들고 있다. 일부 있어보이는 조작 체계(Rich Interface ? 하하)는 javascript 로 처리하는데 이를 jQuery에 맡겼다. 책 정보는 Aladdin (알라딘)에서 제공하는 검색 Open API를 이용하고 있다.

파이썬과 django

django 는 아직도 우리나라에 쓰는 사람이 많지 않다. 관련 자료도 적다. 얼마 전에 연재를 마친 날로 먹는 Django 웹 프로그래밍 강좌는 여러 모로 많이 부족한데도 이 강좌가 그나마 볼만한 문서처럼 되고 있는 실정이다. ㅜㅜ 물론 영문 자료는 참 많지만, 아무래도 부담이 가는 것은 사실이다.

그런 부담을 걷어내면 django 는 정말 훌륭한 웹 프레임워크이다. 현재 배포 중인 안정판인 0.96은 참 불만스럽지만, 곧 정식 발표되는 1.0은 시험판인 지금 것도 꽤 편하고 강력하다. 더욱이 파이썬이라는 언어가 강력하고 매력 있어서 개발이 참으로 즐겁다.

좋은 점 몇 가지를 꼽으라면 관리자(admin) 기능과 모델(model) 기능, 이용자 인증 모듈, 그리고 꽤 작고 직관성 높은 django 구조를 들 수 있다. 관리자 기능, 이용자 인증 모듈은 내가 무척 좋아하는 기능으로 이 둘 덕분에 개발 기간이 크게 줄어들었다. 관리자 기능은 rails(레일스)에서 scaffold 와 비슷한데 그보다 더 실용성 있고 강력하다. 개발 초기부터 개발 완료 후 운영 과정에까지 쓸 수 있다. 이용자 인증 모듈(기능)은 이용자 추가, 관리, 인증 기능을 따로 만들 필요가 없어 좋다. 이게 의외로 손이 가는 부분이라서 이용자 인증부를 다 만들때까지는 연계되어 돌아가는 다른 부분 개발이 난감할 수 있는데, django 에서 제공하는 이용자 인증부를 쓰면 바로 적용할 수 있다.

파이썬이 갖는 장점 덕에 django 가 더 좋은 점도 있다. 파이썬은 코드 예외성이 무척 적은 언어이다. 파이썬 언어 철학 자체가 문제를 해결하는 방법은 최소화 하기 때문이다. 그래서 파이썬에서는 같은 일을 하는 코드를 짰을 때, 누가 그 코드를 쓰더라도 대체로 비슷하게 생겼다. 쉽고 간결한 코드, 그리고 문법(들여쓰기 같은 문법 강제성은 종종 귀찮음을 일으키곤 하지만) 덕에 개발 자체가 즐겁다. 고작 15kb 로 알라딘에서 책 정보를 가져와서 DB에 저장, 이용자 인증(로그인 등), 책 검색, 책 소유/읽음/관심 여부를 표시하는 기능들을 예외처리(Exception)까지 해서 만들었다. django 에서 제공하는 편리함도 무시할 순 없지만, 파이썬 언어 자체가 가진 특성이 가장 큰 영향을 미쳤다.

누가 짜더라도 대체로 비슷한 코드가 나오는 코드 예외성이 적은점은 인터넷 검색으로 자료를 찾을 때 매우 좋다. 고수가 짠 소스 코드든 아니든 상관없다. 파이썬으로 문제를 해결하는 방법은 거의 비슷하여 초보자가 공부하고 자리잡기 좋다. 성향이나 취향이 이유겠지만, 난 루비스러운 코드를 짜기 위해 정작 루비 언어 철학을(인간 중심 프로그래밍?) 위배하는 코드들이나, 문제를 해결하는 다양한 방법을 언어 철학으로 삼는 펄(perl)의 암호같은 코드는 초보자가 공부하기에 썩 좋지 않다고 생각한다.

이렇듯 파이썬과 django는 초보자가 다루기에도 좋고 초기 시연판(prototype)을 만들기에도 아주 좋다. 파이썬이라는 언어가 가진 가볍고 간단함, 그리고 django 가 가진 가벼움과 명료함을 버무리면 장난감 만들기 정말 좋은 환경이 탄생한다. 물론 대형 서비스에서도 쓸 수 있겠지만, 내가 그런 서비스를 직접 개발하진 않으니 무어라 말을 할 순 없다. ^^;

jQuery

jQuery는 prototype javascript framework 못지 않게 많은 인기와 사랑을 받고 있는 Javascript framework 이다. 조금 써보니 정말 강력하고 편해서 꽤 많이 만져온 prototype js 로 돌아가고 싶지 않을 지경이다.

jQuery 장점은 강력한 기능이나 성능을 들 수 있다. 기능은 워낙 많은데다 부족하거나 없는 기능은 확장기능(plug ins) 형태로 보충할 수 있다. 손이 많이 들어가는 귀찮은 작업들을 이미 다양한 확장기능으로 만들어 제공하고 있다. 기능이 많으면 덩치가 커서 느리거나 둔하지 않을까 걱정이 될 수도 있지만, jQuery의 많은 부분들이 prototype js 를 성능으로 제치고 있으며, 높은 성능으로 유명한 dojo 나 extjs 와 비교를 해도 크게 뒤처지지 않는다.

뿐만 아니라 jQuery 소스 코드를 보면 주석이 정말 잘 달려 있어서 Javascript 에 깊게 파고 들어 공부할 사람에게도 많은 도움을 준다. 나처럼 의심 많은 사람은 대체 이건 내부에서 어떻게 돌아갈까? 생각을 하며 내부 소스를 들여다 보는데, 친절하게도 코드 대부분에 주석이 달려 있어 조금만 시간을 들이면 흐름을 이해할 수 있다.

일관성 있는 문법도 마음에 든다. prototype js를 보면 어떤 것은 객체여서 생성 할당(instance)을 해야 하고, 어떤 것은 함수라서 바로 실행이 가능하다. 또한, 각 기능부(component)가 별도 객체처럼 나뉘어져 있어서 혹 같은 이름을 쓰는 기능부가 있는 라이브러리를 쓸 경우 충돌을 일으키거나 혹은 이것이 prototype js의 것인지 아닌지 구분하기가 까다롭다. 그에 반해 jQuery 는 jQuery 라는 이름으로 대동단결 되어 있다.

간단히 예를 들자. hannal 이라는 엘레먼트를 마우스로 끌어다 놓을 수 있는 조작(control) 기능을 제공한다고 치자(prototype js 와 jquery 둘다 그런 기능을 제공하는 확장기능을 써야 한다). prototype 은

new Draggable(‘hannal’);

이런 식이다. jquery는

$(‘#hannal’).draggable();

이렇다. 기능부 쪼개는 장점을 이해 못하는 것은 아니나, 어떤 일을 하려는 대상인 객체(object)를 기준으로 코드를 구현하는 jQuery의 문법이나 코드가 좀 더 일관성 있다.

아쉬운 점은 자료 대다수가 영문이라는 점이다. jquery.com 에서 제공하는 문서들과 예제들이 워낙 잘 되어 있어서 굳이 강좌같은 연재글이 아니더라도 쓰는 데 불편함은 없지만, 기본부터 차근 차근 익히고 싶은 사람에겐 우리말/글 자료가 별로 없는 점은 아쉽다. 하지만 최근에 인사이트 출판사에서 jQuery in Action 번역서를 출간해서, 가뭄에 단비를 내려주고 있다. jQuery를 쓰고 싶은데 영어가 부담되던 이라면 꼭 이 책을 사서 접하길 권한다.

두 번째 아쉬운 점은 장점이기도 한데, 상당히 빠른 판올림을 들 수 있다. 빠른 판올림 때문에 예전에 코드가 문제를 일으킬 가능성이 좀 있다. 실 예를 들면, jQuery in Action 원서는 jQuery 1.2.1판을 기준으로 쓰여져 있는데, 1.2.1판에는 jQuery 선택자(selector)에 contains 라는 메소드(method)가 있지만, jQuery 최신판인 1.2.6판에서는 이것이 메소드가 아닌 필터(filter)가 되어 해당 메소드가 존재하지 않는다. 하지만 번역서에서는 옮긴이께서 보완하셨다고 한다. 만세~

이외 jQuery에 대한 얘기(특히 prototype js와 비교하는 얘기)는 내가 Prototype에서 jQuery로 옮긴 이유라는 글을 보길 권한다. jQuery 특징을 잘 나타내고 있다.

예전 같으면 정말 손이 많이 가는데다 성능도 보장되지 않아 지레 포기하던 많은 것들을 요즘엔 django 와 jQuery 를 이용해서 아주 편하고 간편하게, 그것도 어느 정도 성능이 보장되는 환경에서 처리하고 있다. 물론 이 둘이 아니더라도 php 나 ruby 언어를 서버 환경으로, 그리고 dojo 나 prototype js 등을 클라이언트 환경으로 하여 성능과 편리함을 취할 수 있다.

이들 모두 개성있는 좋은 도구들이다. 하지만 이런 저런 장난감을 다양한 도구로(php(cakephp), ruby(rails), python(django, turbogears), prototype js, yui, jQuery) 만들어보고 만져본 느낌은 나한텐 역시 django 와 jQuery 가 짱이라는 것이다. ^^

덧쓰기 : 당연한 말이지만 이는 어디까지나 개인 성향과 취향에 따라 다르다.

몇 년 동안 내버려두듯 손 보지 않았던 한날의 보금자리, 그러니까 내가 운영하는 블로그들 공간의 대문 역할을 하는 첫 화면을 어제 살짝 손 봤다. 분명 내 머리 속에는 매우 깔끔하고 삼삼했는데 정작 만들고 보니 우중충하기 이를 데 없다.

또, 이 블로그와 한날은 생각한다 블로그에도 약간 변화를 줬는데 “한날의 보금자리”에 있는 블로그들을 이동할 수 있는 길라잡이 막대를 만들어 넣었다. 역시나 우중충하다. 실은 더 우중충했다가 여자 친구 구박을 받고 한.결. 화면과 어울리게 손 본 것이 저렇다.

나도 예쁘고 화사한 빛깔, 구성을 만들어내고 싶다.

파이썬 쟁고(장고)와 루비 레일즈

프로그래밍을 취미로 즐긴다. 그런 성향에 비추었을 때 가장 손에 잘 맞는 프로그래밍 언어는 파이썬(python)이다. 여러 프로그래밍 언어를 다룰 줄 알지만 파이썬을 가장 좋아한다. 내공이 얕아서 내가 파이썬을 좋아하는 이유를 말하는 걸 듣는 것만으로도 그 매력에 취해 글 한 줄 한 줄 따르다보니 어느 덧 듣던 이들 모두가 파이썬 프로그래머가 되어 있는 마술을 부릴 수 없는 것이 안타까울 따름이다.

장고(쟁고, django)는 파이썬 진영에서 각광 받고 있는 웹 프레임워크로 나 역시 꽤 좋아한다. 지금도 쓰고 있고 앞으로도 장난감 만들 때 쓸 것이다. 장고를 처음 접한 계기는 RoR로 불리는 레일즈 웹프레임워크를 접한 것이 계기였다. 매력을 느끼긴 했는데 루비라는 언어 자체에 끌리질 않아서 별 관심을 안가졌다.

아마도 오늘 집에 가면 노트북에 RoR 꾸러미를 깔고 hello world 를 뿌려볼 것이다. 오늘부터 공부하기로 마음 먹었다. 길게 보지 않고 집에 달랑 한 권 있는 RoR 책인 웹 개발 2.0 루비 온 레일스를 2주 안에 마칠 생각이다. 잘 될까?

C#

사실 RoR 보다는 C# 공부를 먼저 하고 싶다.

환경 변화

세상이 참 빨리 변해서 따라가기 참 힘들다는 생각이 든다. 이름을 정말 기억 못하기도 하지만, 나날이 새로 선뵈는 이름과 낱말들이 매 끼니 밥알만큼 많은 것 같다. 관심사를 좁히고 좁혀 이 정도까지 좁혔는데도 벅차다. 어째야 할까. 더 좁혀야 하나, 아니면 더 넓혀야 하나. 아니면 지금 것에 충실할까.

쉽지 않다.

unknown encoding: X-MAC-KOREAN

위와 같은 문자열이 들어간 오류 화면이 뜹니다. 저는 맥 언어 환경을 우리말로 했기 때문에 X-MAC-KOREAN 이라고 뜨는 것이죠.

이것은 Django에 있는 tzinfo.py (timezone 정보 관리하는 역할)가 기본 locale 을 가져와서 그럴싸한 문자열을 만들려 하기 때문에 맥 환경에서 발생하는 문제입니다. 이게 0.97 언제쯤 고쳐질지는 모르겠으니 일단 아쉬운대로 고쳐서 써봅시다. (음냐. 이러면 svn update 할 때 conflict 뜨는데 그 해결은 알아서 하세요)

대상 소스 파일 : django/utils/tzinfo.py

위 파일을 열면

try:
    DEFAULT_ENCODING = locale.getdefaultlocale()[1] or 'ascii'
except:
    # Any problems at all determining the locale and we fallback. See #5846.
    DEFAULT_ENCODING = 'ascii'

이런 부분이 나옵니다. 소스 파일 안에서 거의 맨 위에 있지요. 여기서 문제가 되는 부분이 바로 try 안에 있는 녀석입니다. 맥에서는 저걸 실행하면 X-MAC-뭐시기라고 가져옵니다. 그런 게 없으니 오류가 나는 것이고요. 그 아래에 DEFAULT_ENCODING = ‘utf-8′을 넣어주면 오류 안납니다.

try:
    DEFAULT_ENCODING = locale.getdefaultlocale()[1] or 'ascii'
    DEFAULT_ENCODING = 'utf-8'
except:
    # Any problems at all determining the locale and we fallback. See #5846.
    DEFAULT_ENCODING = 'ascii'

이러면 django의 디버깅 화면이 잘 나옵니다. 찝찝하면 DEFAULT_ENCODING = locale.getdefaultlocale()[1] or ‘ascii’ 를 주석으로 하세요.

여기서 교훈 한 마디. 역시 시험판, 특히 미리맛보기판(pre version)은 안쓰는게 정신 건강에 좋다.

python 을 이용하여 아가씨를 구해내 보자.

2. 함수 선언

def save_my_sweetheart(seminar, heaven):
    if seminar == []:
        return heaven
    elif type(seminar[0]) != type([0,1]):
        heaven += seminar[0]
        return save_my_sweetheart(seminar[1:], heaven)
    else:
        return save_my_sweetheart(seminar[1:], heaven)

3. 함수 실행

>>> a_seminar_has_her = ['g','i','r','l','f','r','i','e','n','d']
>>> hannal = ‘oh, my ‘ + save_my_sweetheart(a_seminar_has_her, ”)

4. 함수 실행 결과

>>> hannal
‘oh, my girlfriend’

5. 결론

이리 저리 빙빙 돌지(loop, 반복문) 않고, 열심히 파고 들어 한 번에 아가씨를 구출해냈다.