
Django Best Practices - krat0sprakhar
http://lincolnloop.com/django-best-practices/index.html
======
boolean
I just read Two Scoops of Django and wished I read it when I first started
developing Django apps. Highly recommended.

<https://django.2scoops.org/>

HN discussion: <http://news.ycombinator.com/item?id=5074026>

~~~
deservingend
I bought that book too. I was skeptical after reading some of the author's
blog but decided to take the plunge. Just twelve bucks, so whatever. After
reading it I'm certain most of those reviews are faked or the work of the
author's friends.

This book is just a slideshow. The chapters are tiny, and there's very little
useful content, just a bunch of "do it this way because we say so." No real
justification or understanding here. Author hasn't made anything substantial
with Django, and his understanding of Python itself is lacking.

People have been request a free sample chapter since the beginning, and he
keeps saying that he's getting one ready. You see a free chapter, and you're
much less likely to want to buy the rest.

~~~
pydanny
First of all, there are two authors of the book, and I'm the one you are
mentioning. Audrey Roy is the other one, I'm just the one who spends more time
on Twitter, HN, and blogging.

In any case, thank you for this mini-review. We can't make the book better
without feedback, including negative commentary. So far most of what we've
gotten back has been extremely positive. While gratifying to our egos, it's
the brutally honest critical reviews like yours that have given us the best
information for improving the book. In fact, we ask for honesty in reviews of
our work, and are willing to take soul-crushing criticism so we can improve
it.

As for the existing reviews, with the possible exception of Barry Morrison,
they were not written by our friends. We didn't know any one besides Barry who
wrote them, and his private feedback to us as a technical reviewer was pretty
negative in places.

I find your point about not enough justification for our practices very
interesting. We talked to a lot of core/senior Django developers about them,
but I think you might have a good point that we need to explain the
background. I thought we addressed this in the Beta release, and I would like
to hear your feelings about that version.

Some more points:

The chapters seem tiny because we self-published and there is no fluff. This
time I didn't have a publisher telling us, "This chapter needs 20 pages of
content, add some more content!". This happens to book authors working with
mainstream publishers, which is why tech books are often so thick and heavy
and sit mostly unread on shelves. Instead, because we controlled the book 100%
each chapter is as long as the material needs to be. Hence your feeling that
this is 'light-reading', even though it has as much content and code examples
as a thicker, denser book.

What do you consider substantial with Django? Should I have built Disqus,
Mozilla, Pinterest, or Instagram on my own? Or is there some other level of
work that I should have done? I'm curious, because unlike some people I don't
hide behind a pseudonym (I'm Daniel Greenfeld and it's easy to find
information about me). Unfortunately a lot of the work I've done for the past
18 months is in private github accounts. This really sucks, and I hope to fix
it this year.

As for my actual Python and Django skills, I'm humble enough to acknowledge
that I can always learn more. This is part of why I worked so hard on the
Django CBV documentation refactor in 2012 (especially the reference docs), to
expand my own knowledge of them. The day I call myself the absolute authority
is the day I stop improving, and I apply this to everything I do. In fact, I
used to give a talk on this exact topic. ;-)

Finally, as for the free chapter, here goes: Since the book was released in
Alpha and Beta states, we want our book in a perfect state. This is why we
offered the book at a discount (O'Reilly and other mainstream publishers do
the same), so early adopters could try it out and provide feedback and we
could get paid for our hundreds of hours of work. In return for the early
adopter discount, you and many others have given us useful feedback (not
enough justification for our practices), and now we can improve.

~~~
andy_boot
I enjoyed two scoops. I appreciated the terseness of it.

If I had one criticism it would be the 'do it this way' style felt a little
strong. I would have liked to see a 'some people dont do it this way' star on
some of your coding style choices.

I'd quite like to hear about how you marketed it - I seemed to hear about the
book from multiple sources all at once - you clearly did a good job there.

~~~
pydanny
Any suggestions about what coding style choices you think should have
alternates?

As for marketing, we hit HN, blog, twitter, and linkin. Then the word spread
and we found it in other places. It was pretty awesome. We can't wait for it
to get on Amazon. :-)

------
arocks
Some more tips to maintain your sanity once you are past the beginner level:

* Use South before you start deploying

* Use an automated deployment tool like Fabric or more powerful ones like Chef/Puppet

* Get a better debugger and other niceties with django-command-extensions

Of course, a lot more apps can be considered must have depending on what you
are working on.

~~~
hdra
I have been trying to get a grasp on your second point, but to this day, I
still haven't been able to really come to terms with it.

Is there any _total noobs_ guide to automated deployment? Everything I have
seen to this day assumes some knowledge of sysops and the whole ecosystem of
that specific deployment tool (e.g. like it assumes I knew what is a
'cookbook', or where to find them, etc). It would be great if there is a guide
for people like me that doesn't assume any knowledge from the reader aside
from development / basic local deployment.

~~~
raverbashing
Try fabric

It's a lightweight management tool, like writing a shell script in python, but
easier and targeted towards system deployment, really

you only have to get around its _unintuitive_ calling convention (not inside
the script - it's the way you use the cmd line tool) but otherwise it's a
breeze

Chef/Puppet are harder (as in, you really have to fit their paradigms)

~~~
hdra
I haven't really looked into it, but how does that differ from using say, a
shell script file?

~~~
btipling
It's similar to using a shell script except you're using Python and have
access to all of Python's modules and fabric is written with roles and remote
management in mind so it makes tasks easier. I love it and even use it to
deploy my jekyl blog.

------
flashingpumpkin
I've got to disagree with the chapter about settings files. Instead of
maintaining multiple different settings for different environments, make your
default settings file pull modifications for each environment from
_os.environ_ , e.g.:

    
    
      STATIC_URL = os.environ.get('STATIC_URL', '/static/')
    

This is a lot saner and won't descend into a mess that is keeping multiple
settings files around. It's also a lot easier to explain.

~~~
raverbashing
That's a very nice idea, but you would still end up with: start_debug.sh,
start_prod.sh, etc

It is a good idea nonetheless, so you can inject the variables needed from the
outside

~~~
DrJ
start.sh debug

------
praptak
Using pip the way they recommend is careless. It makes your deployment
dependent on: 1. a working network connection and 2. All the remote
repositories being up. 3. nobody having messed with the remote repos. The 3.
is admittedly less of a concern, but all 3. are beyond your control and re-
downloading the dependencies on each install is wasteful.

Fortunately pip has the --find-links option which, combined with having all
dependencies downloaded locally makes it possible to have a fully local
install.

~~~
pekk
Most people will not need to use pip --find-links on a regular basis. Hence,
it is not "careless" to fail to do so.

If you are focused on "more nines" than this kind of paranoia is well
justified. Network outages are not totally unknown, sometimes PyPI goes down.
But these things really aren't all that regular as you seem to suggest.
Usually the network is up and PyPI is up. And we haven't had an instance of 3.
yet, assuming that you trust the authors of your dependencies.

Let's please not convey that it's just completely crazy to use pip in the
normal, simple way. It really isn't.

------
btipling
This is great, I especially like the discussion about Managers which I haven't
used before, but I have never been impressed by the technical chops of
Smashing Magazine so to see that as an endorsement is actually a bit of a
drawback. :/

------
fatiherikli
I like the chainable queryset methods.

