스마트스터디처럼 Django 쓰지 마세요

1. DO NOT USE
AS LIKE AS
SMARTSTUDY

2. 사실
•파이썬, 잘 모릅니다!
•원래 윈도우 게임 개발자.
•야매 LAMP 스택 경험자.
•하지만 웹 프레임워크 경험은 흐리멍텅

3. 조건
•불투명한 회사의 미래.
•모바일 브라우저의 특성도 잘 모름.
•그거 말고도 할 일이 너무 많은데,
•크고 아름답지 못한 X을 만들긴 싫어서.

4. The Web framework for perfectionists with deadlines

7. 마감일을 잘 지키고 싶은 이들을 위한 웹 프레임워크
쟁고

8. 개밥 먹는 Django 인증샷

9. 일단 시작했는데
•누구한테 물어봐야 하는지 모르겠네.
•‘쉽고 빠른 웹 개발 Django’ 구입.
•요즘 버전과 달라서 쬐끔 아쉬움.
•그래도 끝까지 자세히 잘 읽어볼껄...

10. 그 무엇보다
#langdev
irc.ozinger.org
마음씨 곱고 착한 아저씨들이 득실 득실

11. 어떻게 하면 좋다
이렇게 해서 멋지다
이런건 많이 있으니까

12. “사람들은 말이죠,
원래 자기가 잘 모르는 걸
추천합니다.
잘 알면 절대 추천 못해요. ”
#langdev 채널의 d님

13. 잘못한 것
• syntax
• views.py
• layout
• deploy
• compressor
• debug-toolbar
• cache
• session
• orm
• database

14. 그나마 잘한 것
• fabric
• celery

16. 1. Syntax

17. •무엇보다 PEP8 부터 보고 시작할 껄...
• http://www.python.org/dev/peps/pep-0008/

18. •pyflakes / pyflakes.vim
• http://pypi.python.org/pypi/pyflakes
• http://www.vim.org/scripts/script.php?
script_id=2441
•pep8
• http://pypi.python.org/pypi/pep8
•pylint
• http://pypi.python.org/pypi/pylint

20. 2. views.py

22. •만능 파일을 만들지 맙시다.
•뷰에는 제발 뷰 코드만.
•파일을 기능 단위로 분리하세요. utils.py 등
•models.py 의 모델 클래스를 활용하세요.

23. •비교적 양호한 예제를 참고합니다.
•DjangoResources
• https://code.djangoproject.com/wiki/DjangoResources
•django-basic-apps
• https://github.com/nathanborror/django-basic-apps

25. 3. Layout

26. •역시, 비교적 양호한 예제를 참고합니다.
• http://www.deploydjango.com/django_project_structure
• https://github.com/garethr/django-project-templates

28. •templates / static 을 분리하니까,
•언뜻 좋아보이긴 하는데, 은근히 불편.
•어차피 collectstatic 해야하니까!
•모든 css element 이름과 static file 이름에
prefix를 붙이는 방식으로 회피.

29. 4. Deploy

30. 개발할 땐 단순하지만

31. 배포할 땐 아니란다

32. ... an he said, “Deployment is fucking hard.”
Text
http://rdegges.com/deploying-django

33. •개발 환경과 실제 환경 맞추기.
•서비스가 병렬로 늘어나는 경우 규격화.
•h님과 같이 패키지화하여 개인 저장소 사용.
•supervisord / daemontools 조합.
• http://kill.devc.at/node/323

34. • http://www.djangobook.com/en/2.0/chapter12.html
• http://www.deploydjango.com/
•heroku 기반이긴 하지만 좋으니까 읽어봅시다.

35. 5. Compressor

36. •할 꺼면 전부 다 하고, 안할 꺼면 넣지 말자.
•{% css %} / {% js %} 블럭을 고정.
•가끔 쓰는 css / js 들은 그냥 따로 쓰자.
•그리고, 어지간하면 지우지 마세요!

37. 6. django-debug-toolbar

38. •정말 debug 용. 성능 모니터링은 아닙니다.
•프로덕션에서 이것 또는 linesman 돌리면 사망.
•개발 환경에서만 쓰세요.
• http://werkzeug.pocoo.org/docs/debug/

40. •django-statsd
• https://github.com/andymckay/django-statsd
•이것 저것 보기 위한 UDP 기반 statsd 사용
•그래프를 출력하기 위해 graphite 사용
•graphite 도 django project. (아?)
•좋긴 한데, 왜케 복잡한가...
•django-easy-profiler app 누가 만들어 주세요.

41. •혹시라도 써보고 싶으시면,
• http://django-statsd.readthedocs.org/en/latest/
• http://www.robgolding.com/blog/2012/01/14/django-
in-production-part-3---automation-and-monitoring/

42. •한 번의 리퀘스트에 뷰가 두 번 호출되는 버그.
• https://github.com/django-debug-toolbar/django-
debug-toolbar/pull/204

43. 7. Cache

44. •편리합니다, 하지만 잘 써야 합니다.
•뷰에서만 하지 말고 템플릿에서도 캐시.
•여러 웹 서버가 있어도, 캐시 서버는 하나로!
•사용자의 요청에 따라 캐시 갱신(?)
•가끔 위험합니다.
•정말 오래 걸리는 일은 되도록 celery로 넘기기.
• https://gist.github.com/3656474

46. •이미 만들어져 있는 데코레이터를 잘 쓰자.
•@vary_on_headers / @vary_on_cookie
•@never_cache
•@cache_control
public
private
no_cache
no_transform
must_revalidate
proxy_revalidate
max_age
s_maxage

47. 8. Session

48. •사용자 탈퇴 처리 후, 로그아웃을 시켜야 하는데,
•세션을 무효화 할 수가 없네!
•모든 세션을 뒤져서 user_id 확인 후 삭제.
•세션이 80만개, 인덱스 없음.
•어떡하지?

49. 9. ORM

50. select_related
prefetch_related
꼭 쓰세요
prefetch_related는 Django 1.4 에서 추가

51. 30 sec
7924 queries

52. 10. Database Sharing

53. •기존 서비스의 계정을 공유하는 서비스를 추가.
•기존 코드에 추가로 작성할까,
•fork 할까 고민하다
•페이스북에 물어봄.

55. fork 하는거다!
FAILED

56. •공통 정보를 다른 데이터베이스로 분리했는데,
•Cross-database-relations 제한!
• http://blog.naver.com/ez_/140164805705
from django.db.backends.signals import connection_created
from django.dispatch import receiver
@receiver(connection_created)
def disable_constraints(sender, connection, **kwargs):
connection.disable_constraint_checking()

57. •마이그레이션이나 여타 이슈로 신경쓰임.
•같이 써야 하는 서비스나 모델이 있으면,
•별도의 외부 서비스로 분리하고,
•RESTful 처리하는게 낫지 않나 생각합니다.

58. 이게 사는건가...

59. 그나마 잘한 것
• fabric
• celery

60. 1. Fabric

61. •원격지에 ssh로 붙어서 할 수 있는 모든 것
•그리고 그 전에 준비해야 하는 모든 일
•모두 fabric으로 통합하세요.
• http://fabfile.org

63. •모든 서비스 각자의 fabfile 을 가진다.
•각종 대몬은 upstart로 규격화.
•개발 서버와 실 서버 환경의 동일하게 유지.
•필수 명령어 정의 init / start / stop / restart
•배포 서버에서 전역 fab 명령어 f로 원격지 작업.
•f <service_name> <command>
•/etc/bash_completion.d 활용.

66. 2. Celery

67. •Celery : Task Queue
•각종 백그라운드 작업 관리 / 구동
•celeryd : 실제 작업을 수행함
•celerybeat : cron과 같이 주기적 작업을 발생
•celerycam : celeryd의 작업을 수집
• http://celeryproject.org/
• http://docs.celeryproject.org/en/latest/django/index.html

68. •옛날에는 수동으로 SQL 하던 작업을,
•Django command로 바꿔서 crontab으로 호출.
•이제는 해당 command의 내용을 task로 바꿔서,
•celery에 periodic task로 등록.

70. 감사합니다

71. DO NOT USE
AS LIKE AS
SMARTSTUDY