Our Django Book is Launched
pydanny.com
pydanny.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.
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).
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.
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.
Which part of this is not right?
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?
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.
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
It's good to understand why it does the things it does, but without a certain amount of trust in the framework, you can lose a lot of it's advantages.
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.
I look forward to reading this- Thanks.
This is all fully documented, if you're curious you should read it.
https://docs.djangoproject.com/en/1.5/topics/http/sessions/
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:
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
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
> "By default, Django stores sessions in your database"
These two things are the building blocks of secure sessions and passwords that work well in distributed systems.
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.
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.
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.
If I buy the PDF now, and you eventually release an EPUB or other format, will I get access to those files (with updates) as well?
(I'm aware I can convert it to ePub myself)
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.
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?
Thanks!
By the way, if you update the book, will we get the updates as well?
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.
Your observation about enterprise grade migrations is interesting. We'll see what we can do to add to the book.
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).
-how do I configure django-social-auth ( https://github.com/omab/django-social-auth ) beyond the default setting (ie: the pipeline)
-what is a good web host for django. Answer: webfaction. How do I set up virtualenv on webfaction?
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'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.
Thanks again, Fernando
- How about adding a sample in the web page?
- 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.
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!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.
I agree with you 100%.
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.
Thanks for the feedback!
Haven't read more than 50 pages yet but I like it. Great job!
By the way, congratulations on releasing this! I've been looking forward to seeing what the "mad secret project" was.
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.
"This book should work well with the Django 1.4 series, less so with Django 1.3, and so on."
That said, we tried to make things as Python 3 friendly as possible. :-)
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]
[1]: https://docs.djangoproject.com/en/dev/faq/install/#can-i-use...
Might be worth a shot later down the road when you are trying to sell to a less captive audience (as compared to the HN crowd).
Would there be another payment method?
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. :-)
But yes, there are a lot of poorly formatted ebooks, which is especially problematic for Python code.
I've already reached out to Danny via other mechanisms, so perhaps there will be a properly formatted Amazon version...
(Reading an A4 PDF on an iPhone isn't really comfortable.)
I've written about using Sphinx to write technical books, you may find it useful: http://pedrokroger.net/2012/10/using-sphinx-to-write-books/
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.
I understand the aversion to negative reviews. Maybe you can offer this with a disclaimer for those who bought the PDF.
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.
They also support PDF, which I'd still prefer to purchase through Google directly if only to keep my stuff in one place.
http://support.google.com/books/partner/bin/answer.py?hl=en&...
http://support.google.com/books/partner/bin/answer.py?hl=en&...
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.
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.
Thanks!
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.
Another great resource: http://gettingstartedwithdjango.com/ and videos here: http://gettingstartedwithdjango.com/pages/gigantuan/
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.
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. ;-)
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