Notes on a Django Migration
Milan Andric
http://birdhouse.org/blog/2008/11/19/notes-on-a-django-migration/
This isn't directly related to the newsroom project, but it's a great
overview on Django and frameworks. The article gives insight into why
you or someone might choose Django for their next web project.
--
Milan
John Tynan
In addition to being a measured and persuasive case for moving to
django, Scot makes some excellent points which I think can help to
inform the discussion around django newsroom. In particular:
The idea of writing the documentation clearly, so that "from a
newbie's perspective" it will be easier to follow. Thankfully,
Milan's documentation for setting up python, mod_wsgi, django support
for cPanel hits just the right tone in this respect and serves as a
good example for future documentation.
Among other things, I also liked your pointing out that "It's all
about the data model. Get this right and you win." This reminded me
of a project I had started awhile back, where I wanted to port a
database application I had written using ASP into Rails. I had only
made it so far, but I still had the SQLite database sitting around.
Yesterday, I started working on defining the models in Django and it
prompted some questions:
What is the best way to start defining your model? Do you write it in
django first and then rely on syncdb to build the database? What if
you have an existing model? After some looking around, I found the
command django-admin.py inspectdb here:
http://www.djangobook.com/en/1.0/chapter16/ (another example of "know
what to search on to find answers to specific problems" as well as
further reinforcing the need to spend "many, many hours reading
documentation" to give your mind that "hard restart" so that you can
be productive in django).
In the end, I decided to start defining the database from scratch
again, but this has me thinking: what is the best way for the group to
talk about defining models for applications through django code, the
way they've done here:
http://www.djangodb.org/blog/index.php?/archives/162-WorldBorders.html
Or, should we share the exported SQL from MySQL or SQLite? Or would
we simply check out each other's code through subversion or git?
Or, is there some other way that would be productive, such as:
http://code.djangoproject.com/wiki/DjangoGraphviz
The article also provoked other thoughts (such as how to set up
development environments / production servers for django-newsroom)
which might be a discussion for further down the road...
But kudos to Scot for the great writing!
Scot Hacker
On Nov 23, 2008, at 7:21 AM, John Tynan wrote:
>
> Milan, thanks for pointing this out.
>
> In addition to being a measured and persuasive case for moving to
> django, Scot makes some excellent points which I think can help to
> inform the discussion around django newsroom. In particular:
Thanks for the kudos John.
> The idea of writing the documentation clearly, so that "from a
> newbie's perspective" it will be easier to follow. Thankfully,
I like the concept of "write documentation first, code later." Not
that I've ever actually done that, but I like the concept :) . Maybe
something to consider.
>
> Milan's documentation for setting up python, mod_wsgi, django support
> for cPanel hits just the right tone in this respect and serves as a
> good example for future documentation.
I've been thinking about this a bit. The django-newsroom proposal says
we'll be able to deliver some form of auto-installer. But will that
auto-installer assume Python/Django/Apache/Database are already
configured and ready to go? As noted in the article, Django deployment
on a web server is no picnic, and could be a show-stopper for a
newsroom without experienced Unix sysadmins to tap. Unfortunately I
think we're in the territory of irreducible complexity here, since the
vast majority of the standard web hosting world is Python-ignorant.
Maybe our recommendation for newsrooms without sysadmins would have to
boil down to "Get a Webfaction account."
> What is the best way to start defining your model? Do you write it in
> django first and then rely on syncdb to build the database?
Yep, that's the usual workflow.
> What if
> you have an existing model? After some looking around, I found the
> command django-admin.py inspectdb here:
> http://www.djangobook.com/en/1.0/chapter16/ (another example of "know
> what to search on to find answers to specific problems" as well as
> further reinforcing the need to spend "many, many hours reading
> documentation" to give your mind that "hard restart" so that you can
> be productive in django).
I recently used inspectdb for the first time and it rocked in a way -
it did accurately reflect the structure of the legacy tables. But
while working with it, I quickly realized that this was the time to
rearrange a lot of stuff, rename fields, remove fields, etc. So I
still ended up doing a couple of hours of hand-massaging in order to
get it "right." If I hadn't, it would have worked, but would not have
been Django-elegant.
> In the end, I decided to start defining the database from scratch
> again, but this has me thinking: what is the best way for the group to
> talk about defining models for applications through django code, the
> way they've done here:
>
> http://www.djangodb.org/blog/index.php?/archives/162-WorldBorders.html
Cool site! Hope it gets some traction.
But unless we can create some kind of GUI model builder, we have to
accept the fact that newsrooms are going to need at least one person
on staff whose not wary of code. For custom story definitions, they're
just going to have to learn enough about Django models to write their
own. We need to be careful about over-promising, giving the impression
that we're creating something so easy to use that anyone can do
anything without tech skills. A django-newsroom based newsroom will
still need a developer on staff.
>
./s
Milan Andric
>
>
> On Nov 23, 2008, at 7:21 AM, John Tynan wrote:
>
>
>>
>> Milan's documentation for setting up python, mod_wsgi, django support
>> for cPanel hits just the right tone in this respect and serves as a
>> good example for future documentation.
>
> I've been thinking about this a bit. The django-newsroom proposal says
> we'll be able to deliver some form of auto-installer. But will that
> auto-installer assume Python/Django/Apache/Database are already
> configured and ready to go? As noted in the article, Django deployment
> on a web server is no picnic, and could be a show-stopper for a
> newsroom without experienced Unix sysadmins to tap. Unfortunately I
> think we're in the territory of irreducible complexity here, since the
> vast majority of the standard web hosting world is Python-ignorant.
> Maybe our recommendation for newsrooms without sysadmins would have to
> boil down to "Get a Webfaction account."
Actually lots of providers support django. All you really need is to
support fcgi. mod_wsgi is another thing, but support for that is
growing rapidly. Also I think mod_wsgi deployment on a web server is
a picnic, unless you're using cpanel. In debian for exmaple the
mod_wsgi package is available and up to date. So you just need to
issue one command to install it.
Here's a list of providers who can support django from the django wiki
http://code.djangoproject.com/wiki/DjangoFriendlyWebHosts#Django-friendlyWebhostsnon-VPSdedicated
Also don't forget about sqlite and the the python web server. Running
on apache may not even be necessary in the future. All you may need
is python.
>
>> What is the best way to start defining your model? Do you write it in
>> django first and then rely on syncdb to build the database?
>
> Yep, that's the usual workflow.
Yep yep, just start writing python. There has been a few times where
someone needs an app or has an app idea and I immediately start asking
questions and building a data model in python. After about an hour of
back and forth questions there is a valid data model possibly with
some managers implemented as well.
>
>> In the end, I decided to start defining the database from scratch
>> again, but this has me thinking: what is the best way for the group to
>> talk about defining models for applications through django code, the
>> way they've done here:
>>
>> http://www.djangodb.org/blog/index.php?/archives/162-WorldBorders.html
>
> Cool site! Hope it gets some traction.
>
> But unless we can create some kind of GUI model builder, we have to
> accept the fact that newsrooms are going to need at least one person
> on staff whose not wary of code. For custom story definitions, they're
> just going to have to learn enough about Django models to write their
> own. We need to be careful about over-promising, giving the impression
> that we're creating something so easy to use that anyone can do
> anything without tech skills. A django-newsroom based newsroom will
> still need a developer on staff.
It's true a django-newsroom based newsroom will need a technical
person if they want to do custom stuff. But we can work on
streamlining this endeavor or make it go away all together by
providing newsrooms with exactly what they need. Providing 5
different configurations of the same app for example, because there is
enough demand for those custom apps.
The idea of a model repository is in line with the idea of an app
repository, both are great ideas and can work together. But the app
repository will mirror a wordpress type of system so you can install
one with a mouse click. Just as now you have pinax compatible
applications that are pluggable with a urls.py and settings.py tweak,
we could have a django-newsroom compatible repository. We'll just
take care of the settings.py and urls.py tweaks for you. I'm hoping
to keep django-newsroom mostly pinax compatible so we can use apps
from that project since it's taking off. One django project that is
already getting its settings and url configs from a db rather than a
file is review board. So they already have a gui configuration tool
built for django: http://www.review-board.org/
This idea of a gui config tool for settings.py and urls.py could be
its own app or separate open source project. We can incubate it here
at django-newsroom until there is a reason to break it out.
Also several models and apps will float to the top, or become more
popular than others. Based on what journalists are looking for.
Hopefully this will cover the 80% ... just like wordpress, certain
plugins become defacto for a certain type of site, so will certain
apps. Custom apps are great and people may come looking for them or
build their own. If they want to build their own then sure, they have
to learn django or some subset of it. One of our goals is to make
that as easy as possible for them, most projects struggle to get that
last 10% of easy of use and customization. It's just difficult ...
but in the end we still have a better pattern/framework for custom
apps than wordpress and drupal.
Don't forget about some really cool projects like web2py which does
everything in the browser. including code editing and debugging. I
even know this guy and he's a professor at depaul and is another
project to leverage from.
Please check this out: http://mdp.cti.depaul.edu/
So the idea of a GUI model builder in my mind really turns into an MVC
builder, because the model is just one part of it. web2py has done
that, and it may or may not be out of the scope of django-newsroom. I
think that's yet to be determined. I love the idea but not sure if we
will get to it. It's out of the scope of wordpress to build a GUI
module builder for good reason. It's a technical exercise. But
having models, templates and views that use the same patterns will
make this job much easier and allow for more code sharing and reuse.
I'm hoping the problem of custom apps will get solved with a prolific
community and app repository that has everything you need, including
variation x of app y. Forking/branching is encouraged. ;)
--
Milan