• Django Development Mistakes In 2014

  • 2014년에 Django로 개발하면서 실수한 부분

  • - Use Postgres As Your Primary Data Store
  • 1. Postgres를 주 DB로 선택하세요
  • I know in the previous article I was advocating using MongoDB for your primary database, but after 1.5 years of using it, I would no longer suggest it for a number of reasons:
  • 네. 제가 이전 글에서 주 DB로 MongoDB를 추천했던 사실을 잘 알고 있습니다. 그런데 1년 반 정도 사용하다 보니 추천하지 않을 이유들이 좀 생겼습니다.
  • - As of Django 1.7, there is still no built in support for MongoDB via the Django ORM. You need to utilize Mongoengine/PyMongo. Both of those projects are amazing, but because Django doesn’t support MongoDB, you cannot use Django admin — this really sucks and it is one of the reasons why I’ve stopped using MongoDB as a primary data store.
  • - Django 1.7에서도 Django ORM은 여전히 MongoDB를 지원하지 않습니다. Mongoengine나 PyMongo를 사용해야 하죠. 이 두 라이브러리는 훌륭하지만, Django admin 같은 도구를 사용할 수는 없습니다. 이건 정말 끔찍하며, 제가 MongoDB를 주 DB로 사용하지 않게 된 이유이기도 합니다.
  • - As of 12/18/2014, Postgres now supports the JSONB data type, which means you can store “documents” in Postgres and run similar queries (with indexing) to MongoDB, without taking a performance hit.
  • - 2014년 12월 18일부터 Postgres는 JSONB 데이터 타입을 지원합니다. 이를 통해 Postgres에 "문서"를 저장할 수 있으며, MongoDB에서처럼 비슷하게 쿼리를 실행할 수도 있습니다. 성능 문제를 겪지 않고서도 말이죠.
  • - Most third party libraries are useless because they assume you are using the Django ORM. This makes utilizing the Django ecosystem almost impossible. The Django ecosystem is amazing and getting better every day — this is a real bummer.
  • - (MongoDB를 선택하는 순간) Django ORM을 사용한다고 가정하는 대다수 서드파티 라이브러리가 쓸모 없게 됩니다. 이는 Django의 생태계 대다수를 사용할 수 없다는 의미입니다. Django 생태계는 매우 훌륭하며, 매일 발전하고 있습니다. 이걸 사용할 수 없다니!
  • note icon
    이해하기 쉽게 원문에 없는 구절을 추가했습니다.
  • If you are developing on OSX, don’t waste time building Postgres from source, use Postgres App — it will save you a lot of time.
  • OSX에서 개발하고 있다면 Postgres 코드를 다운받아 빌드하지 마시고, Postgres 앱(http://postgresapp.com/)을 사용하세요. 시간을 많이 절약해줄 겁니다.
  • 2. Build a unit testing infrastructure that makes writing unit tests easy
  • 2. 유닛 테스트를 작성하기 쉽게, 유닛 테스트 인프라를 구성하세요.
  • There are a lot of articles, both positive and negative regarding test driven development(TDD) and Django. I’m not taking a side in that fight, but one thing I try to do in every project is setup a framework that makes writing unit tests easy and fun (yes fun). Every project I work on has a class which acts as a mixin for all TestCases. Each unit test (class) then inherits from this mixin and has instance based methods to create data for each test. Fake data is generated using the excellent django_faker project. Data is created in setUp() and removed in tearDown(). If you’re interested in learning more — please read my blog post on unit testing in Django.
  • Django와 테스트 주도 개발(TDD) 방식에 대해 수많은 찬반 논쟁이 벌어지고 있습니다. 저는 어느 한 쪽 편을 들 생각은 없지만, 모든 프로젝트에서 유닛 테스트를 작성하기 쉽게(또한 재미있게) 해주는 프레임워크도 구성을 해두려고 노력합니다. 프로젝트에는 먼저, 모든 테스트 케이스에 대해 믹스인처럼 작동하는 클래스를 하나 만듭니다. 이 믹스인을 상속받는 각 유닛 테스트(와 클래스)에는, 테스트용 데이터를 생성할 인스턴스 메서드도 만듭니다. 이러한 가짜 데이터를 만드는 데는 django_faker 프로젝트가 안성맞춤입니다. 데이터는 setUp() 메서드에서 생성된 후, tearDown() 메서드에서 삭제됩니다. 여기에 좀더 관심이 있다면 제 블로그에서 'Django에서의 유닛 테스트(http://josephmisiti.github.io/unit-testing-best-practices-in-django/)'라는 글을 읽어 보세요.
  • note icon
    옮긴이 - django_faker 말고 model_mommy나 factory_boy 등도 있습니다.
  • 3. Build RESTful interfaces with Django Tastypie
  • 3. Django Tastypie를 사용해서 Restful 인터페이스를 만드세요.
  • With the proliferation of client side MVCs such as Ember.jsBackbone.js, and Angular.js, having RESTful support in your web application is now pretty much required. Django has two excellent frameworks which can be used to build REST APIs: django-rest-framework and django-tastypie. Although I get the feeling that django-rest-framework is more popular, I’m still a huge fan of django-tastypie. It seems to be more straight forward, and it has been around a bit longer. With that said, if you are building a public API — absolutely use django-rest-framework, as it provides API documentation for free. If you need help getting started with django-tastypie, check out this tutorial I wrote on how to setup a Django project using it.
  • Ember.js, Backbone.js, Angular.js 등 클라이언트 MVC 프레임워크의 수가 급증하는 시기이므로, 여러분의 웹 애플리케이션에서도 RESTful을 지원하면 좋습니다. Django에서 REST API를 구현한 두 개의 훌륭한 프레임워크가 있는데요, django-rest-framework와 django-tastypie입니다. django-rest-framework가 더 많이 사용되고 있는 것 같지만, 저는 아직 django-tastypie를 사용합니다. 이유는 django-tastypie가 좀더 간명해 보이며, 제가 경험도 많이 해봤기 때문입니다. 하지만 여러분이 공개 API를 만들고 있다면 두말 할 필요 없이 django-rest-framework를 사용하세요. 문서화 기능도 제공됩니다. 혹시나 django-tastypie를 시작해야 한다면 제가 쓴 튜토리얼(http://josephmisiti.github.io/using-django-tastypie-to-create-RESTful-APIs/)을 참고하세요.
  • 4. Use Django model field’s help_text attribute as a form of documentation
  • 4. 문서화 작업이라고 생각하고, Django 모델 필드의 속성인 help_text를 사용하세요.
  • Django model fields accept a help_text attribute which is used in Django forms/admin for display purposes. I highly suggest using it even if you do not plan on utilizing Django forms or Django admin for one reason — It also serves as great form of documentation for your models. If you need to on board a new developer in the future, help_text will save you endless amount of hours bringing someone up to speed.
  • Django 모델 필드에는 help_text 속성이 존재합니다. 이 속성은 Django의 폼 화면이나 admin 화면에 나타나죠. 설령 폼 화면이나 admin 화면에 사용하지 않는다하더라도 이 속성을 꼭 사용하길 권합니다. 왜냐하면 여러분이 만든 모델의 문서화에도 안성맞춤이거든요. 앞으로 새 개발자를 채용할 예정이라면, help_text 속성이 인수인계에 드는 수많은 시간을 단축시켜 줄 겁니다.
  • 5. Do not use query parameters in customer facing URLs, use Django’s URL module to force constraints
  • 5. 사용자에게 드러나는 URL에는 쿼리 문자열을 사용하지 말고 Django의 URL 모듈을 적용하세요.
  • This may be obvious to experienced web developers, but whenever possible I no longer use HTTP query parameters in urls — I pass them as url parameters instead. My reasoning is you can use Django’s url dispatcher to enforce parameter constraints.
  • 웹 개발자들에겐 너무 당연한 사실이겠지만, 어쨌든 저는 url에 더이상 쿼리 문자열을 사용하지 않습니다. 대신 url 파라미터로 전달하죠. Django의 url 디스패처를 사용하여 이렇게 할 수 있습니다.
  • As an example, the following URL:
  • 예를 들어 다음의 URL은
  • can be re-written as
  • 다음과 같이 바꿀 수 있습니다.
  • You will have to write less type-checking code in your controllers because the Django URL module will throw an HTTP 404 for any non-integers passed in the “id” field. I realize you cannot always do this, but whenever I can do it, I prefer to use this design pattern.
  • 이렇게 하면 컨트롤러에서 타입 검사 같은 코드를 덜 작성해도 됩니다. id 자리에 정수가 없다면 Django의 URL 모듈이 404 HTTP 오류를 던질 테니까요. 간혹 이 규칙을 따르지 못할 사정이 있을 수도 있겠지만, 저는 할 수 있는 한 이 규칙을 따릅니다.
  • 6. Use Django’s ORM to enforce database constraints:
  • 6. Django ORM으로 DB의 제약 조건을 지정하세요.
  • I know, I know — another dumb one — but honestly I have seen this time and time again. You can solve a lot of problems for yourself down the road if you use database constraints correctly
  • 네, 네, 이제와서 또 언급하기엔 바보 같은 말이죠. 여러분이 DB의 제약 조건을 정확히 지정해 둔다면, 수많은 문제들을 해결할 수 있습니다.
  • - if a field can never be null, do not set null=True
  • - null 값을 가질 수 없는 필드에는 null=True를 설정하지 마세요.
  • - use unique_together to enforce unique constraints and preventing dups
  • - 고유한 값을 저장하는 필드들은 unique_together로 지정해주세요.
  • - use the unique parameter when applicable
  • - unique 파라미터도 적절히 사용해 주세요.
  • - set max_length field appropriately
  • - max_length도 알맞게 지정하세요.
  • Basically, spend a considerable amount of time designing your database schema correctly, and use Django ORM to enforce this schema to the fullest extent possible! Make it impossible to save incorrect data!
  • 데이터베이스의 스키마를 설계하는 데 공을 들이고, Django ORM을 최대한 사용하세요. 그러면 잘못된 데이터가 저장되는 일은 없을 겁니다.
  • 7. Use django_model_utils + django_extensions in every project
  • 7. 모든 프로젝트에 django_model_utlis와 djagno_extensions를 사용하세요.
  • Django-extensions is a third party library that provides a number of amazing piece of functionality: printing settings, shell_plus, dumping scripts, encryption, etc. I find myself using more and more of this functionality on a daily basis.
  • django-extensions는 settings 출력, shell_plus, 덤프용 스크립트, 암호화 등 굉장한 기능들이 담긴 라이브러리입니다. 저는 이 기능들을 날이 갈수록 더 많이 사용하고 있습니다.
  • Django-model-utils contains a bunch of useful functionality not currently available in the Django ORM (or implemented differently): TimeStampField, MonitorField, Choices, etc
  • django-model-utils는 Django ORM에서 지원하지 않거나 구현 방식이 조금 다른 유용한 기능들을 제공합니다. TimeStampField, MonitorField, Choices 등이 있습니다.
  • Before reinventing the wheel, make sure to throughly check out both of these projects.
  • 바퀴를 새로 발명하기 전에 이 프로젝트들을 꼭 살펴보세요.
  • 8. Use Sentry For Both Front-End and Backend Errors Monitoring
  • 8. Sentry는 프론트엔드와 백엔드의 오류를 검출하는 데 사용하세요.
  • Sentry is a piece of open source monitoring software written in Django. You can either pay for a subscription at getsentry.com or self host it. Sentry is an absolutely indispensable tool for diagnosing both front-end and back-end errors. You can track all sorts of useful information such has
  • Sentry는 Django로 만들어진 모니터링용 오픈소스 소프트웨어입니다. getsentry.com에서 비용을 지불하고 사용하는 가입형과 직접 운영하는 설치형으로 나뉩니다. Sentry는 프론트엔트와 백엔드의 오류를 진단하는 데 없어서는 안 될 도구입니다. Sentry로 다음과 같은 유용한 정보들을 추적할 수 있습니다.
  • - how many times this error occurred in the past
  • - 이 오류가 몇 번이나 발생했었나
  • - browser information
  • - 브라우저 정보
  • - time/location of occurrence
  • - 시간/지역에 따른 발생 빈도
  • - stack traces from 500s
  • - 500 오류 등의 스택 트레이스(stack traces)
  • - 404s/403s
  • - 404/403 오류
  • - front-end javascript undefines
  • - 프론트엔드 자바스크립트의 undefines 오류
  • Plans start at $24/month — and this is definitely money well spent.
  • 가입형은 한 달에 $24부터 시작하며, 이 돈을 낼 만한 가치가 충분합니다.
  • 9. Use the django-debug-toolbar for debugging and optimizing your site
  • 9. 최적화와 디버깅에는 django-debug-toolbar를 사용하세요.
  • Django-debug-toolbar is an amazing debugging tool. You can use it to track down performance problems in SQL queries, requests, templates, cache, etc. I am not a big advocate of premature optimization, but as soon as things still start to slow down, the django-debug-toolbar will help you identify the problems. For more information on how to install this project, please read the following blog post.
  • django-debug-toolbar는 놀라운 디버깅 도구입니다. 성능에 문제가 있는 SQL 쿼리와 요청, 템플릿, 캐시 등을 모두 추적할 수 있습니다. 저는 미리부터 최적화를 시도하는 편이 아니지만, 뭔가 느려졌다 싶을 땐 django-debug-toolbar가 문제점을 찾도록 도와줄 겁니다. 이 프로젝트에 대해 더 알고 싶다면 다음 블로그 글(http://josephmisiti.github.io/unit-testing-best-practices-in-django/)을 읽어 보세요.
  • 10. Use Django Custom User Model From Your First Commit
  • 10. Django의 커스텀 User 모델을 첫 번째 커밋부터 도입하세요.
  • Django 1.6 introduced custom user models and I highly recommend you start with this rather than using Django’s build-in model. Adding fields to the user model is much more intuitive than the alternative method, which was to extend the model using another model with a OneToOne field. If you’ve been using Django for a while, you might find out the that 30 characters allocated for the email and username field on the built-in User model are not enough. If you start with a custom user model, resolving these issues and adding new fields is a migration away! Migrating a built-in user model to a custom user is still possible, but it’s not fun — take my word for it.
  • Django의 기본 User 모델을 사용하기보다는 Django 1.6에서 도입된 커스텀 User 모델(https://docs.djangoproject.com/en/1.7/topics/auth/customizing/)을 사용하길 적극 권합니다. User 모델에 필드를 추가할 때도 기존의 방법(기본 User 모델과 OneToOne으로 엮인 새 모델을 만드는 방법)보다 직관적입니다. Django를 이미 사용하고 있다면 기본 User 모델의 email과 username 필드가 30 글자로 제한되어서 답답했을 겁니다. 커스텀 User 모델을 도입하면 이런 문제들이 모두 해결됩니다. 기본 User 모델을 커스텀 User 모델로 마이그레이션할 수도 있겠지만 재미는 없을 겁니다. 제 말을 명심하세요.
  • 11. Considering using an alternative to django-admin
  • 11. Django admin에 대체품을 도입해보세요.
  • Django admin is great — but the design is pretty outdated. If you are building a site for a customer and they are paying for it, there are a number of alternative options that look a lot more professional and are very easy to install. Two of my favorites are django-greppelli and django-suit. For a larger list, click here:
  • Django의 admin은 훌륭하지만, 겉모습은 철 지난 디자인입니다. 외주 일을 맡아서 진행했다면 admin 화면을 좀더 전문가 답게 바꿔줄 도구들이 있습니다. 저는 django-grapelli와 django-suit를 애용합니다. 더 많은 목록은 링크(https://github.com/rosarior/awesome-django#admin-interface)를 참고하세요.
  • I tend to blog about Django and Machine Learning from time to time, so if you are interested in this type of content — give me a follow on twitter@josephmisiti
  • 저는 Django와 머신 러닝에 대해 블로깅합니다. 이 주제에 관심이 있다면 제 트위터 계정 @josephmisiti를 follow해주세요.
  • Shameless Plug: If you need help with Django or Machine learning — I’m available for consulting: Math & Pencil
  • Django나 머신 러닝 관련 업무를 도와드립니다. 컨설팅도 가능합니다. Math & Pencil 홈페이지를 참고하세요.
0 Comments