One thing that Django suffers from is having a long history which means that old best-practices (which no longer are best practices) still float around on blogs and it's hard to know what is what. I understand that the fact that so many people swap out core components with 3rd party libs can make it confusing, but I would disagree that in order to get to production quality it is required. I would even recommend avoiding swapping out core pieces whenever possible and work within the framework.
Just so you know, when the book was more direct we had reviewers saying it was too direct and they wanted more flavor text. Our answer was an appendix of libraries in the back that listed all the recommended packages. Perhaps we should point readers to that earlier?
Also, if you are using Django, using third-party libraries is part of using Django. We feel this is a good thing because you don't want critical libraries standing still waiting for the next major Django release (a roughly yearly event). A good example is OAuth authentication - if Facebook or Twitter changes it's methods, you can upgrade to the latest django-social-auth or django-allauth and expect things to work.
However, as I said, I would love to hear more detailed feedback. That way we can make the book better. :-)
So, while I may be a weird outlier (not a beginner, but I only have a basic understanding of Python), I felt that the book was never really written for me. It lacks an authoritative tone that I want in a "best practices" manual, and the fact that the book spends so much time explaining why best practices are important really made me think that the book was meant for programming beginners. Paradoxically, the book will then randomly drop in a Python package or two without explanation and expect me to know what it is.
Here are some examples:
Using explicit relative imports -- The section explains why explicit relative imports are good. Fair enough. Then, the book provides an example of "bad code" with "implicit relative imports". Keep in mind that you still haven't defined "explicit relative imports." Then, you explain how un-portable and un-reusable these "hard coded" imports are. After that, you convert the snippet to "explicit relative imports". Still no definition. From here, I try to compare the two snippets. Did the authors really spend 2 pages explaining a "best practice" that could easily fixed by just omitting the package name? I honestly thought I was missing something. Then, the fact that "implicit" relative imports had more code than "explicit" relative imports really started messing with my head, so I decided to move on.
Chapter 2 Fixtures -- I wasn't wondering why we weren't using fixtures because I had no idea what they were (they weren't covered in the tutorial). Simply defining fixtures would help here.
The rest of the chapter was all info that applies to every language and isn't specific to Django (dev and prod should be identical, use git, etc.), so I wasn't really getting much out of the chapter.
Chapter 3
Other Alternatives -- why?! I'm trusting you with my life here! Tell me what to do! I am yours to mold into a brilliant Django developer!
Chapter 6
Model managers -- This is where the narrative style really lead to ambiguity for me. Example 6.6 isn't labeled as a BAD EXAMPLE, yet you lead into it with a rhetorical question. My e-reader happened split the page right after the example, so if I had stopped reading there (which is common for me with reference books), I may have not seen that, on the next page, you explain that Example 6.6 is an example of what not to do.
General My problem getting acclimated to Django isn't the third party libraries necessarily; it's more my lack of knowledge about them at all. Throughout the book, there are tips for libraries to add to Django, but there's hardly ever a thorough explanation or description of the product, just that you think it's important.
Hope that helps! Just in case it needs to be said: none of this is an attack on you at all; I totally appreciate the work that went into this book. Thanks for listening to feedback and let me know if you have any other questions!
The Hitchhiker’s Guide to Python![1] explains a number of Python related things which beginners(in my experience and opinion) generally either tend to overlook. You do not need to read it all at once. Chapters can almost be read independently and in no particular order.
Secondly, go through Python Ecosystem - An Introduction[2](shameless plug) once. .
[1]http://docs.python-guide.org/en/latest/ [2]http://mirnazim.org/writings/python-ecosystem-introduction/
This is not necessarily true. Everything in Django is production quality as you will see in several sites in the wild (including the very first Django sites).
No framework will give you the most optimal set of components for every possible scenario. In most cases Django components are swapped out for performance reasons, especially when they are high traffic sites. In other cases, it is due to the NIH syndrome where almost every component has been homegrown (perhaps trying to become more standalone).
where did you hear that? its outright non-sense. everything that ships with django is good enough for production right out of the box.
Hartl's Rails tutorial is comprehensive, but does not spend enough time explaining the underlying principles IMO. Writing a test for everything also muddies the water in that tutorial (which does not mean TDD is not good for you).
By the way, though the feedback on the inclusion of TDD has generally been positive, it can get tedious, even for me. I do hope to produce a simpler, test-free Rails intro at some point as a complement to the present tutorial.
Just track the changes you make to your models and make the same changes to the database.
As soon as you are doing something that anyone relies on and to save you endless effort you should use South, IMO. Even if it's a one-person project (I have a few of those) South saves you both a lot of time and aggravation.
Aside from being a great habit to get into, South (or whatever other migration tool you want to use) will keep your database consistent and predictable to the framework. If you add or alter columns on your own, you run the risk of slight differences between what you've done and what the framework would've done left to its own devices. You may not have done anything wrong, but you don't want that inconsistency.
The biggest upside to it is that it fully documents all of your chances, and even allows rollbacks if necessary. Editing the database directly doesn't give you any kind of change log unless you do it manually, which is not really sustainable, even while working solo.
That sounds more like a problem of php. Tools like composer should be more widespread and when they are switching to virtualenv probably isn't going to be so much of a hassle.
I've tried to get into both Rails and Django twice now (I'm a PHP guy usually), but every time I seem to get going, I get bogged down by StackOverflow after StackOverflow that have seemingly contradictory information or offer a third party solution rather than solving the problem within the framework.
In Rails, for example, Rails is easy enough, until you're dealing with RVM * , Passenger * , and installing correct dev versions of database drivers.
In Django, you deal with South migrations when you want to update your database schemas, virtualenv * , virtualenvwrapper * ; in fact, I've heard that one of the criticisms of Django is that, in order to get to production quality, you essentially have to switch out every component of it with a third party.
* The starred apps don't technically have anything to do with the framework; they're more utilities for managing multiple framework instances. Still, you're likely to find tutorials that use them as a de facto standard, which only adds to noob confusion.
I've started reading Michael Hartl's Rails tutorial, which seems promising. I found that the highly-recommended "Two Scoops of Django" book was a little too narrative for me (just tell me what to do, dammit!); there's definitely a need for more Django tutorials than just the Django website's basic one -- kudos to the author for that.