Hacker News Reader

Comment by pydanny | Hacker News Reader

As one of the authors, I'm not sure what to say to this. I would honestly love to get your feedback.

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. :-)

View on HN

Thanks for the reply! I'd love to go more in-depth with my critique. Keep in mind that, while I'm new to Django and Python, I've worked with PHP, Java, C++, C, and Objective-C for years. I'm familiar with writing reusable code and how to write code that is able to be read by others. I'm also an OOP fanatic, so I'm already on board with most of the conventions that are suggested by most frameworks like Django and Rails. My previous experience with Django was going through the official Django tutorial.

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!

If I might make a suggestion, I think a lot of these problems would have been solved by reading the Django project docs before Two Scoops. Unlike many open source projects, Django's docs are of extremely high quality. Their main shortcoming is that while they tell you a great deal about what Django's pieces are and how they work, it leaves out a lot of practical usage stuff. That's where Two Scoops picks up. To me it's less of a book for a pure beginner and more so intended for turning someone who knows the basics into someone who can deploy a real site into production.

That's a fair point. I went through the tutorial and totally overlooked the rest of the docs (with the exception of the ones that I needed). Even still, I think Two Scoops could be a lot more concise and spend less time focusing on why and more time focusing on how. Best practices are means to an end; if someone's reading a book about them, chances are that they're aware of the benefits of following best practices anyway and don't need the constant reminder of why portable, readable code is important.

Reply on news.ycombinator.com