So, full disclaimer: I was one of the editors of this book.
This is a really great 'best practices' book for Django developers of all skill levels.
In the Django community, there are a variety of practices that people tend to use: webapp structure, coding conventions, library preferences, etc. As a Django developer, finding out 'which way should I do X' is often harder than it seems: there are tons of articles on Google, but it's difficult to make sense of which recommendations are right.
This book takes a really great approach to the problem by introducing readers to a great deal of information: which way you should do X, why, and how it works. Instead of just getting a solution, you'll understand why things should be done that way, and how it works.
Furthermore, I can tell you that as an editor of this book, both Danny and Audrey (the authors) took quite a lot of feedback, and made a lot of progressive changes to the content. This (in my opinion) is a huge selling point, as you know all the book's content has been reviewed by numerous influential Django developers and users.
Anyhow, this is a really great book, and quite cheap for the asking price. I'd highly recommend you read it, regardless of your skill level.
Having recently started Django for a small gig, I have found searching for Django documentation, tips, and practices, to be extremely difficult and confusing, especially coming from the Rails world where blog posts seem a dime a dozen.
I spent a long time looking for good info only to find outdated or poorly maintained docs, and a very little sense of "community".
I'll probably grab this book to get me jumpstarted. I'm happy, yet sad that I have to find my information this way -- says something about the community IMO (not a bash on you, but just a nag on the Django community as a whole as I feel it doesn't really like helping beginners).
This is really surprising to hear. I think Django has some of the best documentation out there. I rarely have to go to blogs or Stack Overflow because that answer usually exists right in the docs.
Could you give an example or two of issues you had that you couldn't find the answer to in the docs?
I haven't been working with django recently and having completely read the book, I am now up to date.
* The book has a lot of practical advice having developed using django for years. For example, the book recommends, whenever you have a custom manager, always explicitly define `objects` as the default manager, before the custom manager.
* The book makes a recommendation; but also mentions alternatives where applicable. The authors prefer a 3 tier project layout but also suggest that a lot of people prefer the 2 tier layout where the `manage.py` is in the root of the repository. Similarly in the chapter on the Class Based Views. The book suggests an approach and also includes other ones.
* Includes the latest and the new changes in the django 1.5 wrt the User model and how to inherit.
* Recommends and suggests many good third party applications. More books need to do this.
* Provides good review material (if you already know) about Security, Deployment, performance etc.
All of this, just over the top of my head.
Real world advice is often hard to come by. Whether you are a professional or a novice or just checking out django, you should buy this book.
I posted it on reddit first off the top of my head directly.
Then I noticed the thread on Hacker News and started writing a comment; deleted it and copy-pasted from my own reddit comment and went to bed peacefully.
One of my big concerns is user / session security.
I have tried to follow and reason through discussions on stackoverflow and much of tpatchek's notes. I would be interested in how "high level" the security chapter is from anyone who has shelled out already.
For example I assume I will
1. only use persona or openid (avoids storing passwords in my servers thus making a lot of things much much easier)
2. sessions - store absolutley nothing in a session cookie other than a nonce session id, and lookup everrything I need from cache on servers form that sessionId
3. That seems to be it really
I just do not know where to go to have this discussion sensibly - any hints?
I'm not sure what this has to do with the focus of the book, Django has session support so I doubt a book about Django would fully cover re-writing one of its components. Django used to only be able to store nothing in the session cookie other than the ID so that part can definitely happen (new in Django 1.4 are Cookie Based Sessions that used signed cookies to store data in cookies, but it's something you have to turn on).
This is all fully documented, if you're curious you should read it.
As for tying into OpenId or other similar systems, it's a piece of cake. There are numerous Django apps out there to accomplish it. I have used django-social-auth for a project and had no problems getting things running:
A brief read of the sessions docs throws up three concerns
1. Stuffing a lot into a session cookie (the term can easily exceed he 4096 bytes limit suggests that this is not designed just to store session ids)
2. There is implication of one site secret key - a flaw in Flask which it's dangerous was supposed to fix - but even so there is the implication the MAC check guarantees
No one has played with the cookie. This is flat eke bread and butter breaking those
3. It still is making the base assumption that the developer can willingly stick whatever he likes in a python duct and have that magically comeback from the client untouched - of that seems to be so.
Just I prefer having caching problems on my server than never knowing if the information from the cookie can be trusted
That seems disingenuous - a read of the docs indicates to me that the default is to store a lot of app specific info on an encrypted cookie - what is stored on that cookie? Admin rights? Total credit in dollars? Discount codes? That's app specific but if the implication is its trustable then a lot of attack vectors just opened up. who chooses the encryption? Is a new key generated per user / session? If so how is that stored and looked up? Any lookup drops the secure vs speedy trade off and so you need not store anything in the session cookie
Yes it is possible to make a app insecure - we do it all the time. My question is how to generically and sensibly reduce the attack surface - you know, best practises.
I just do not see the trade off of "encrypt everything onto a cookie and use that instead of cache lookups" as one I am willing to take - but I would like to know if I am in a minority, if there is evidence backing either side etc
Edit: this appears to have been typed out of my bottom - the parents has pointed out the clearly marked defaults for django that meet seemingly most or all of my concerns above - but I cannot reply just yet (not sure why it might be a enforced Cooling off period) so this is the best way to say mea culpa
The book covers 7 pages that gets you started down the road of understanding security. We provide you the stuff you have to know, and point you towards better resources.
Keep in mind we aren't professional security experts. If your site needs to be that secure, the best thing you can do is to hire the services of a carefully vetted security expert.
1. Using recent django (1.4+) will get you _very good_ password storing security. Use HTTPS and you're "as good as anybody else". no persona/openid needed
2. Django has signed cookie sessions (optional to be used) and a solid signing library. This ensures that the data that is returned is the same as the data that was stored. This doesn't mean that a cookie can't be hijacked, so you should take care to have acceptable timeouts and such.
These two things are the building blocks of secure sessions and passwords that work well in distributed systems.
It does use the 'do fancy things with HMAC signed tokens' to handle password reset though, which (as a general scheme) has been criticised vs the 'store random dumb token, details in the DB' method, for being difficult to do right and open to subtle flaws.
Obviously I'm not aware of any Django-specific issues with it (or I'd have reported them already), but it's a design decision I've wondered about.
There was some discussion in a thread a few days back[1] in which I asked a similar question.
It boils down to "possible, but very easy to screw up, and for what is probably relatively small benefit."
The only benefits I can think of for the info-in-token approach are:
* Less database hits to validate a token. Given that password resets are probably only a small part of your site load, I'm dubious as to the utility of this optimisation.
* No server-stored tokens to secure - If an attacker manages to dump or partially break your database (SQLi, logic bug, whatever), they could extract the reset tokens and use them to gain access. Obviously, a full db exploit would make this unnecessary, and a proper reset implementation (that expires the tokens after use, sends confirm emails on use, etc) means unauthorised use would hopefully be detected.
In the info-hash-token, the only place it's ever actually stored is in the user's mail-box (and every email server involved in the process along the way, potentially), which might reduce the risk of disclosure, especially bulk (server dump) disclosure.
Any other advantages I might have missed? It's possible to do things like token expiry, invalidate on use, invalidate outstanding tokens using hashed tokens, but all of those things are fraught with danger.
If you're interested in security and have been following tptaceks notes, then no doubt you will have seen his recommendation for reading The Web Application Hackers Handbook.
I'm just a rank-and-file web developer, but I would also strongly recommend reading this book, regardless of what language or framework choice you've made.
Your 2nd point has significant performance implications, so I wouldn't take that for granted.
Your 1st point is pretty controversial and has significant UX implications. Using OpenID instead of just the built-in Django auth or bcrypt is hardly "much much easier" either, it's far more complex to integrate.
I don't think the 2nd point has significant performance implications. If you're not serving up static pages then there's always network calls to be made on the backend.
Storing a nonce on the client and looking everything up on the backend is an easy solution which means you don't have to worry about what data you're storing and if that'll be available in the browser.
I think it's cheaper to optimize on the backend for a simpler (and safer) solution.
I cannot trust anything returned from a client so it seems best to Only return one thing from the client
As for a carefully vetted security pro - that's great but I am looking for basic generic best practises (we know that has evolved from md5 hashes to bcrypt but what else is there?)
It seems either a hole in my education or a hole in general common knowledge
Just finished the first chapter and I'm probably not putting it down again (after I write this comment). This feels like something Django really needed (or I needed for Django), despite its extensive documentation. I find analogies are very helpful for my understanding and the ice cream one is perfect. The fact that "Each Chapter Stands On It's Own" is the great too!
Of course! I really appreciate the time you all put in this book and I keep finding huge changes I can make in my code (ch.2 on db and ch.3 on layout -a very difficult topic to research a few months ago) I'm at webpowerlabs.com for reference. Thanks again and great job!
I will purchase your book as well, but with a hope that there will be an ePub version released in the future. I have a junky Sony e-Reader that is not so great at touch controls for things like zooming and panning (necessary with most PDFs) and an ePub would reflow the text as needed based on font size.
This is a really great book. The formatting does need a lot of work (I see no chapter or section headings in the PDF) and an ePub version would be very useful.
The actual content of this book is excellent though. I feel like I keep up with new developments in the Django community pretty well, but there's a lot of advice in this book I hadn't heard before.
Alright then, I'm one of the authors of this book.
There are chapter and section headers in the book, but we've had a couple people using PDF readers on Linux who don't see them. Can you email me at pydanny@cartwheelweb.com and let me know which PDF reader you are using so we can test and hopefully fix the issue?
I'm having trouble on Linux Mint stock pdf reader (Evince).
No chapter numbers appear on the table of contents, and the chapter title doesn't appear on the chapter pages
By the way, if you update the book, will we get the updates as well?
I develop Django professionally, bought the book, and just finished a quick read through. I am very impressed. Some may rightly say you can get all the information in the book elsewhere and for free, I wouldn't want to. This book would have saved me many hours over the last few years. $12 is a bargain. I think the depth and breadth is just right and would highly suggest it for (nearly) every level of Django developer.
My one complaint, to not just this book, but pretty much the community at large is there exists scant documentation dealing with 'enterprise grade'database migration (..both data and schema, for some reason data is always left out) with Django and South.
Nice work.
P.S. - I've made a small pull request to your django template as it doesn't work in it's current form.
First suggestion: show the 2nd level in your Table of Contents.
That's helpful for customers like me who would buy the book if they knew a bit more details about what's inside (I don't want to buy something and then find out I know most of the contents already).
Another suggestion that would get me to buy the book: does the book addressed particular issues that I know I need to figure out (and will save me from having to do my own research).
In particular, would be useful if the marketing of the book told me that it would discuss specific tasks/decisions. Some examples of tasks:
-how to code my django app so it works in both python 2.7 and python 3? What's the best way to do that? Django six? How do I setup virtualenv to support my dual configuration? I think this is what the django core team is doing nowadays so I can also adopt the same strategy, right?
-what's the best way to replace django templates with jinja2?
-for python 3, what is the alternative to PIL?
-as mentioned elsewhere, how do I do database migration when the models change. Especially, what are the different alternatives for doing the migration (django south seems too complicated -- can I just make sure the manage.py db schema and the actual db schema are the same as the docs suggest?)
-should I use store much of my model data in a json field so I don't have to deal with db migration? Any software packages or coding tips about this?
-how do I use SQL Alchemy with django? Issues with doing this (besides not getting a lot of django goodies).
1. For Python 2/3 compatibility, we recommend SIX.
2. We recommend using Jinja2 where you need it, not as a replacement.
3. PIL on Python 3 is not yet solved. This is part of the reason why the Python web world has not transitioned over completely. It's a huge blocker.
4. We plan to cover South in depth. In the BETA or FINAL editions of the 1.5 book.
5. You implement SQLAlchemy in DJango via "import sqlalchemy". You do lose lots of goodies (ModelForms, Admin, a bunch of views, etc)
6. django-social-auth is something we hope to cover before FINAL
7. On web hosts (webfaction, Heroku, et al), we didn't want to turn the book into a tome about deployment. Each provider does things differently, and we would have to keep track of all that and update when host providers change their services. So rather than describe deployments in depth, we're going to link to their documentation and let them handle it.
I purchased this book because Audrey and Danny put on great events in LA area. I've been to one of them and they were extremly helpful and the event was great :)
I'm sure the book has a ton of useful information and I will definitely be reading it.
You should purchase the book if you believe in giving back to the people who give there time to open source and helping others.
- You may to consider using PayPal in addition to Gumroad. Gumroad is awesome, but some people may only be able to use PayPal (e.g. no International Credit Card) or prefer it. I use both for my book and I sell way more copies on PayPal.
+1 on payment options. As someone with a British credit card, the site won't verify my card (I suspect I need to be able to put my name as per card and address on it). So much for being able to buy it :(
Had to go speak to my bank, turns out that Gumroad came up as fraud and HSBC froze my entire account! The bank said it should work now but I'm pretty put off.
I had exactly the same issue with my Royal Bank of Scotland account - Gumroad was flagged as fraud (the security people at RBS said they had several complaints about Gumroad) and I had to get my account unlocked.
People using British accounts - be VERY wary about making payments to Gumroad. I'm waiting till this is available on PayPal or Amazon.
# Normally you should not import ANYTHING from Django directly
# into your settings, but ImproperlyConfigured is an exception.
from django.core.exceptions import ImproperlyConfigured
The humor in this book makes it a joy to read, but the content is what makes it a must read!
Purchased! This looks awesome, I literally just set up django yesterday and had a huge amount of unanswered questions while setting it up. Like you have mentioned, I had a real hard time finding the 'best' practices to set up the environment. Anxious to get home and start reading.
Just bought the book, not really spelunked it much yet but looks pretty cool so far - I'm just getting to grips with django and other python web frameworks generally.
One tiny annoyance is the lack of pre-generated bookmarks based on the contents page. See [1] for example of how Uncle Bob's clean code PDF ships with these (my PDF reader is Foxit). These bookmarks save a hell of a lot of time navigating back and forth in a large PDF document such as books.
Unfortunately, the tool we used to format the book doesn't do this for us, so we either have to use a third-party product to do it manually OR write a Python script to generate the bookmarks.
We intend to start working on the Python script tomorrow, and I really want to get it into the BETA release.
I did purchase this because I will find it very useful, but I do want to say that providing an ePub format is clutch. Please, please do what you can to provide this format in the future!
I definitely look forward to reading this over the weekend. Just purchased. I've already learned quite a bit from pydanny's blog over the years, so hopefully the book follows suit.
I bought it and after a quick view of it seems to be a good catch! I am a beginner to Django and before this I have read the "The Definitive guide to Django"
I've done some own small projects based on django. Read the turorial, read alot of best practises on the tubes and a lot of trial and error. I did just buy this out of curiosity and for $12 and after reading the book for about a hour now, I think this is a great summary of best practise with explanations _why_ something is considered best practise.
Haven't read more than 50 pages yet but I like it. Great job!
As a new django user, one of the most confusing issues to deal with is deployment. Many guides say a few hand-wavy things about deployment, and then move on. Can anybody summarize what this book says about deployment?
By the way, congratulations on releasing this! I've been looking forward to seeing what the "mad secret project" was.
Is it only for 1.5? Will the best practices carry over for someone looking to understand more about structuring 1.4 projects?
I'm working on a 1.4 project right now and while 1.5 sounds great, I'm not sure we're quite ready to upgrade. But we've been looking for a best practices book more recent than the ones covering 1.0 on amazon.
We decided that until there are working implementations of Django running on heavily trafficked Python 3 site, it would be best to focus on Python 2.7. Heck, for that matter, Python 3 is experimental in Django 1.5. We wanted to keep our readers in a safe spot and advocate safety over cutting edge.
That said, we tried to make things as Python 3 friendly as possible. :-)
> Does it mostly focus on Django on Python 2, or is there a good portion that deals with Django on Python 3 as well?
Since the book is focused on Django 1.5, which only experimentally supports Python 3, it would be difficult for the authors to focus on Python 3 without a ton of caveats and/or issues for readers.
Django 1.6 will bring "official" support for Python 3.2.3 and 3.3[1]
I was going to buy this book but it doesn't seem like django.2scoops.org/ uses HTTPS. I'm not comfortable giving away my credit card numbers and CSV without it. Strangely, the website shows "HTTPS Secure" on the top left corner.
This looks fantastic and the timing couldn't have been better for me. It's been a while that I started a new Django project and I was looking for exactly this type of best practices just this afternoon.
Because of the formatting issues of Kindle and ePub, the negative reviews Python books get when formatting breaks in those formats, we're not sure yet it we'll publish it in mobi/epub.
That said, if you have any advice on getting Python to look good in those formats, we would love to hear it. :-)
I see you used Pages to write the book. AFAIK Pages can export to ePub automatically (but I don't know if the result is any good). Maybe you could consider to export the ePub and distribute it with the PDF even if the ePub is a "beta" version. I think it could be useful for a lot of people.
This is great. As a new Django developer one of my most frequent Google queries is "best practices about x in django". I am thrilled to finally have so much of that stuff in one place.
I've been looking for django books that use 1.4 but didn't find anything, so great news for me. Purchased it right away and can't wait to give it a read this weekend. Thanks!
Is this useful for Django 1.4.3 development? I know this is a 1.5 book so I'm not sure how much of the API/stack has changed and how relevant the book will be for me.
Most of the book will work with Django 1.4.3. There are some exceptions such as use of the {% url %} template tag, the custom user model, and some other areas.
Looks like ePub if you're going to add re-flowing text (I see in the other thread what a pain that can be, but I think it works fine for Programming Python which I have through Google Books).
They also support PDF, which I'd still prefer to purchase through Google directly if only to keep my stuff in one place.
I found the checkout process needlessly confusing. The split between the first and second page once I clicked was not clear to me, and the name of the button beside the price box was "Gift". With the arrow above it specifying a price, I didn't understand if I was entering the price of the book, or an additional sum. Could I have paid less and still received the book?
Finally, once I have paid for the book, it seems I can't get back to the page again, so I guess I'm not supposed to be able to buy another copy?
I would look over the usability of the checkout process, I almost didn't buy it because of the perceived ambiguity. And I would have preferred to use Paypal.
Feedback from a 4 month newbie: I've read several chapters. Overall the book is great but I have some specific suggestions, which I'll wrap in the context of what my biggest barriers to learning Django and web development have been.
Background: I starting learning web development with Django 4 months ago. I knew nothing but procedural programming (from late 80s) and a little CSS (Wordpress) before starting. I did Learn Python the Hard Way for a week then dove in.
Barriers to learning Django and Web dev:
1) Setting up the development and production environments has taken up at least 1/3 of my last 4 months of learning. This book would have helped with that significantly.
Suggestion 1: It would help even more if, in addition to your sample setup on github, there was a virtual machine or Vagrant file intended for beginners to get up and running quickly.
I've developed a VMware VM for myself along these lines (based on bitnami's Django stack on top of Ubuntu 12.04) and will use your book to improve it - especially changing my project layout template.
Suggestions 2: Answer a specific question the book didn't address: Is a virtual machine (one per project) a fine alternative to using virtualenv? If not, why not?
2) Django docs do a great job telling me what each command does, but rarely which of many alternatives is best to use (and why), and how best to structure projects. So I end up doing hours of searching each week (Google, Stack Overflow). This is where Two Scoops really nails it - would have shaved at least 2 weeks off my 4 months learning time. [can use this as a direct quote on your site, if you like]
Suggestion 3: Chapter 4 talks about keeping apps small and loosely coupled but not how to bind multiple reusable apps together, especially ones where tight coupling seems natural. I know there are techniques for this but I don't know which is best.
Suggestion 4: Chapter 6 briefly discusses when to drop down to SQL. Would love to see this expanded to several pages, with perhaps a long list of common situations where it does make sense to drop down to SQL. Either that, or a link to an excellent external resource.
3) Django is a tour de force in OOP. If you're weak on OOP, the tutorial and most other parts of Django is tough going. Practice and learning how to use my IDE (PyCharm) to navigate code eventually got me over this hurdle. This is not something addressed by your book, which is fine.
Suggestion 5: In Before You Begin section, perhaps add a single sentence that urges beginners to learn Python and (importantly) OOP before starting the Django tutorial.
4) No Django doc clearly explains the basic concept of web pages with no state, but context passed around to keep track of things. I still don't 100% understand why there are so many different ways of dealing with context, and which Django commands are best for given situations. Not currently in your book and maybe it doesn't fit in. But just want to mention that this was, and continues to be, a hurdle.
5) Deployment is way too hard for a beginner. I'm using dotcloud so that made it easier but again - having a virtual machine for distribution to beginners would be super helpful.
Suggestion 6: Expand chapter on deployment.
6) Would love to see an entire book devoted to building a single, substantial project that did a lot of typical things, but with all best practices implemented and explained in context. The project would use 2-3 existing Django apps and create 2-3 additional ones from scratch, and would show how to have intermediate apps to tie together 2 apps that need tight coupling. It would show this apps environments of dev, testing, staging, and deployment on either dotcloud, heroku, or gondor.io. It would show how to make the app look reasonably attractive, perhaps using Zurb or Twitter Bootstrap. I think this would make a terrific companion book to Two Scoops.
Hope some of this is helpful. Thanks for writing this book! I've had it for less than a day and I've already learned a lot.
It always puts a bad taste in my mouth when information/knowledge is locked behind a pay-wall. It frustrates me when I think that someone somewhere is getting turned down from what they want to learn from because they had no money to pay for it or doesn't have the means to pay for it. I know the authors should profit but why can't they do something like https://mitpress.mit.edu/sicp/ or http://debian-handbook.info/ or http://www.aosabook.org/en/index.html or http://philip.greenspun.com/seia/ or http://learncodethehardway.org/ or http://10print.org/ etc etc etc... Aren't the authors of these books making money? Or is it the fear that people just won't pay for it if its also free to download even if they can?
EDIT: I didn't 'click-through' to the book's original site because there was no mention that the book is also available to those who can't afford on this announcing page. My mistake.
First, if you can't afford to buy the book, then do as we asked on http://django.2scoops.org. Email us and we'll send you a copy. Money should never be in the way of education.
Second, this book took hundreds of hours to write. For weeks we've put in 12-14+ hour days putting it together. We did it instead of working in an office or doing consulting. If we don't charge then we can't put this sort of thing together and maintain it.
Unless, of course, you want to sponsor us to do this sort of work. ;-)
If you look further down the page it says that they are happy to send free copies to people that can't afford it. Which shows you didn't even bother to read their website before complaining.
Tell me. Do you donate all your time to sharing knowledge for free, or do you work a nine to five job like most people?
Have you written a book yourself that you subsequently released for free, or you just trying to dictate what other people should do with their hard work?
Clarification: The info about getting free copies is on http://django.2scoops.org/ rather than the blog post
Can't Afford the Book?
If you're struggling with finances and can't afford it, let us know and we'd be happy to send you a free copy. Drop us a note at 2scoops@cartwheelweb.com.
This is a really great 'best practices' book for Django developers of all skill levels.
In the Django community, there are a variety of practices that people tend to use: webapp structure, coding conventions, library preferences, etc. As a Django developer, finding out 'which way should I do X' is often harder than it seems: there are tons of articles on Google, but it's difficult to make sense of which recommendations are right.
This book takes a really great approach to the problem by introducing readers to a great deal of information: which way you should do X, why, and how it works. Instead of just getting a solution, you'll understand why things should be done that way, and how it works.
Furthermore, I can tell you that as an editor of this book, both Danny and Audrey (the authors) took quite a lot of feedback, and made a lot of progressive changes to the content. This (in my opinion) is a huge selling point, as you know all the book's content has been reviewed by numerous influential Django developers and users.
Anyhow, this is a really great book, and quite cheap for the asking price. I'd highly recommend you read it, regardless of your skill level.