11 Feb 2009
예전엔 남이 만든 게임이나 웹 서비스를 비평하거나 비판하곤 했다. 대체로 회사에서 프로젝트를 시작하느라 유사 서비스를 분석하고 나서 그 일부를 슬쩍 써먹는 식이었다. 이 말은 내가 비판하던 점들은 내가 기획하는 서비스에서는 해소한 점이었다. 그래야 말 앞뒤가 맞기도 하다.
요즘엔 되도록 비평이나 비판을 하지 않는다. 경력이 쌓여서 아는 사람도 많아져서 인맥 관리하느라 그러는 건 아니다. 비평이나 비판은 칭찬하는 것 못지 않게 많은 노력이 필요하다. 뭘 알아야 깔 수 있는 것이다. 제대로 알지 못하거나 제대로 된 근거도 제시하지 못하면서 자신의 추측만으로 비판을 가하면 설득력을 싣기 어렵다. 한 마디로 사기치는 것이다.
하지만, 이제는 비판을 잘 하지 않는 진짜 이유는 따로 있다. 내가 꼬집어내는 문제는 그 결과물을 만들어낸 사람들도 이미 알고 있는 경우가 대부분이기 때문이다. 비판이나 비평을 하는 이유가 잘난 척을 하기 위함이 아니라면, 굳이 나도 알고 그들도 아는 걸 꼬집어내서 불필요한 소모를 일으킬 필요가 없다. 아무리 좋은 뜻을 갖고 도움을 주고자 비판을 한 것이라도 그 비판을 받는 이는 마음이 편치 않다. 그가 소인배이거나 고집쟁이라서 그럴수도 있지만, 문제를 알고도 고치지 못하는 상황 때문에 속상해 할 수 있기도 한 것이다.
물론, 만든이가 문제 자체를 모르는 경우도 있다. 이런 경우엔 비판을 해봐야 나나 그들이나 별 소득이 없는 경우가 많다. 해봤자 득을 보기 보다는 괜한 오해를 사는 식으로 손해보기 쉽상이다.
가끔 진심으로 비판을 듣고자 하는 이도 있다. 그럴 때도 비판을 하는 건 조심스럽다. 왜냐하면 그런 사람은 이미 무엇이 문제인지 알고 있으며 어떤 비판을 들을 지 예상하고 있기 때문이다. 그래서 그가 알고 있고 예상하는 바를 내 입으로 확인시켜 주는 정도로 말을 마치려고 한다.
말은 청산유수 같은데, 다소 꺼칠한 성격 탓에 남이 듣기엔 충분히 가시 돋힌 비판으로 들릴 수 있다. 내딴엔 가리고 가려서 비판하는 느낌나지 않게 말을 하는데 냉정하게 비판한다는 말을 들은 적도 있다. 아, 그럼 비판을 적극 지지하던 시절에 내가 하던 비판은 대체 어느 정도 수위였을까.
애정 어린 비판. 이젠 그런 것도 하지 않으려 한다. 비판을 하지 않고도 충분히 뜻을 전달할 수 있다고 생각한다. 아직 확신을 하진 못하기에 비판을 하나 하나 줄여가고 있다. 우선 남이 만든 결과물을 비판하지 않는 것부터. 다름을 비판하지 않는 것도. 틀림을 비판하지 않는 것...은 아직 못하겠다. 아휴, 이놈의 성격.
01 Feb 2009
안녕하세요, 한날입니다.
오랜만에 Django 강좌 글로 뵙습니다.
지난 2008년 8월에 강좌 연재를 마친 뒤 얼마 후에 Django 1.0판이 새로 나왔습니다. 꽤 많은 점이 바뀌었더군요. 대체로 이전 정식판인 0.96를 기준으로 개발한 코드라도 잘 작동하는데, 일부 기능은 아예 작동하지 않기도 합니다.
이 연재글은 “날로 먹는 Django 웹 프로그래밍 강좌” 을 보완하여 현재 정식으로 배포되고 있는 Django 1.0판에서 제대로 작동시키는 내용을 담습니다. 또, 본 강좌에서 다루지 않은 내용 일부를 추가하려 합니다. 즉, 새 강좌 연재는 아니고, 부록에 해당하는 것이지요.
그럼 바로 시작하겠습니다.
Admin 영역 사용법 변화
admin.py 만들기
“청) 컨트롤러(뷰) - 글 목록과 글 보기 기능 (5편 1/3)”에서 Django의 Admin 영역/기능을 다룹니다. 그런데 1.0판부터 Admin 기능을 쓰는 방법이 크게 바뀌었습니다.
기존에는 각 모델마다 Admin 이라는 클래스를 만들어서 썼습니다.
class Entries(models.Model):
Title = models.CharField(max_length=80, null=False)
class Admin:
pass
이런 식이죠. 하지만, 1.0판부터는 admin.py파일을 따로 만들어야 합니다.참고1)
이 파일은 각 어플리케이션마다 씁니다. 본 강좌에서 우리는 blog 라는 어플리케이션을 만들었는데(manage.py startapp blog), 이 어플리케이션 안에, 그러니까 어플리케이션 디렉토리(폴더) 안에 admin.py 파일을 만들면 됩니다.
admin.py 파일을 만든 뒤 관련 모듈을 가져오겠습니다.
from django.contrib import admin
이 admin 모듈을 써서 Django admin 영역에서 다룰 모델을 등록할 수 있습니다. 바로 admin.site 에 있는 register 메서드, 즉 admin.site.register 로 하는 것이지요.
먼저 Admin 영역에서 다룰 모델을 가져옵니다. 편의상 Entries 를 해보겠습니다.
from hannal.blog.models import Entries
from 경로는 여러분이 어떻게 프로젝트를 만들고 어플리케이션 이름을 지었는지에 따라 다릅니다.
이렇게 가져온 모델을 admin.site.register 로 등록합니다.
admin.site.register(Entries)
이렇게 하면 Django admin 영역에서 Entries 모델을 다룰 수 있습니다.
Admin 영역에서 좀 더 예쁘게 하기
Django admin 영역에서 다룰 모델을 등록하는 것 말고도 화면에 나타나는 영역을 바꿀 수 있습니다. 본 강좌에서는 “admin 영역에서 자료 좀 더 예쁘게 나타내기”라는 단락에 나와있지요. 이 부분도 Django 1.0판에서 조금 바뀌었습니다. Entries 모델을 기준으로 예를 들어서, 우리는 글 번호와 제목, 작성일시만 뜨게 해보겠습니다.
admin.site.register 위에 아래와 같이 클래스를 하나 만듭니다.
class EntriesAdmin(admin.ModelAdmin):
pass
이 클래스는 Admin 영역에서 Entries 모델을 어떻게 출력하고 다루게 할 것인지에 대한 정보를 담는 역할을 합니다. 자세한 내용은 잠시 뒤에 하기로 하고 우선 pass 로 빈 클래스를 만듭니다.
이 클래스를 방금 admin.site.register 로 Entries 모델을 등록하는 부분에 추가합니다.
admin.site.register(Entries, EntriesAdmin)
이렇게 register 메서드에 두 번째 인자로 넣는 겁니다.
이제 글 번호, 제목, 작성일시가 뜨게 해보겠습니다. 간단합니다. EntriesAdmin 클래스에 아래 내용을 써넣습니다.
list_display = ('id', 'Title','created',)
list_display 라는 클래스 프로퍼티에 튜플 자료형으로 출력할 모델 요소를 문자열로 담는 겁니다. 기존 방법과 같습니다.
class EntriesAdmin(admin.ModelAdmin):
list_display = ('id', 'Title','created',)
코드는 이렇게 생겼습니다.
이외에도 좀 더 다양한 변화를 줄 수 있습니다. 자세한 내용은 공식 문서(The Django admin site)를 참조하시길 바랍니다.
urls.py 내용 바꾸기
이걸로 끝이면 좋겠는데, urls.py 에서 Admin 영역에 접근하는 방법도 바뀌었습니다.
먼저 urls.py 맨 위에다가
from django.contrib import admin
admin.autodiscover()
를 넣습니다. 그런 뒤 주소 체계는 아래와 같이 넣으면 됩니다.
(r'^admin/(.*)', admin.site.root),
Django 1.0판에서 프로젝트를 만들면(django-admin.py startproject hannal) 이러한 내용은 이미 반영되어 있으니 크게 어렵진 않을 겁니다.