Re:Jacob Kaplan-Moss: Real World Django
by tvon on Saturday March 28, 2009 @10:28PM
(#537033)
FWIW, not paying attention to the date I didn't realize PyCon was in-progress. If memory serves, videos usually don't end up online till after PyCon has completed, though I could be wrong.
Re:Jacob Kaplan-Moss: Real World Django
by ashot on Saturday March 28, 2009 @04:37PM
(#536754)
It seems django would benefit by brining some of this "in-house", either officially or through blessed third-party tools in the same way that rails does.
If deployment and testing is something that everyone has to do in a very similar way should it not be a problem that is solved by the framework the same way that sessions are?
Re:Jacob Kaplan-Moss: Real World Django
by jacobian on Saturday March 28, 2009 @11:53PM
(#537078)
The thing is that actually very little of this is unique to Django. The types of tools you need to deploy dynamic-language-based web applications don't differ depending what the "P" in LAMP stands for.
Re:Jacob Kaplan-Moss: Real World Django
by ashot on Sunday March 29, 2009 @12:49AM
(#537118)
That maybe true (Capistrano which you reference was pulled out of 37 signals) but I think my general criticism still stands (+ standardization in and of itself has benefits in that it helps people help each other).
The rails community from the beginning has had a more holitstic view of the problem it is solving.
The third tab on the rails site is about deployment. There are three performance monitoring companies and 6 different rails specific hosts.
Other examples: db schema evolution (migrations) and rake tasks. There is also a litany of useful maintance tools you can find on github.
This is not just in reference to code either, its everything else too, including documentation.
I like django, I prefer django, but in this one critical area, the last mile, rails does better. And its frustrating because its not a hard problem.
Re:Jacob Kaplan-Moss: Real World Django
by njharman on Saturday March 28, 2009 @09:06PM
(#536977)
sessions are in contrib, not part of the framework.
Some of the testing stuff is "in-house".
It's not even close to true that everyone's deployment is (or should be) very similar. It's a bit more arguable that everyone's testing should be similar. But forcing one way is not the Django way and one of the big reasons it is loved.
Re:Jacob Kaplan-Moss: Real World Django
by erlanger on Sunday March 29, 2009 @02:42AM
(#537178)
This document is covered with "FAIL" stamps, but they didn't even mention HAProxy as a load balancer! Anyway, I think that slide 135 is what most people do, maybe adding a DB cluster.
Is there any audio/video available from the PyCon presentation?
If deployment and testing is something that everyone has to do in a very similar way should it not be a problem that is solved by the framework the same way that sessions are?
The rails community from the beginning has had a more holitstic view of the problem it is solving.
The third tab on the rails site is about deployment. There are three performance monitoring companies and 6 different rails specific hosts.
Other examples: db schema evolution (migrations) and rake tasks. There is also a litany of useful maintance tools you can find on github.
This is not just in reference to code either, its everything else too, including documentation.
I like django, I prefer django, but in this one critical area, the last mile, rails does better. And its frustrating because its not a hard problem.
Some of the testing stuff is "in-house".
It's not even close to true that everyone's deployment is (or should be) very similar. It's a bit more arguable that everyone's testing should be similar. But forcing one way is not the Django way and one of the big reasons it is loved.