RubyGeek

Alright, ok! I am setting my ruby and rails down for a bit to give python and django a spin. I’ve been bored with programming lately and need to try something new. So what the heck! Lets see how this goes.

Since I am not a guy — I read the instructions first! (haha). I open the README file and it says to read install.txt then proceed to the tutorials in the docs section. Sweet! Being as I an off-the-grid commuter, I have to rememember to download all documentation BEFORE I leave the house in the morning.

First thing I had to do was install Django. I already had Python 2.5.1 installed on my mac. You have to be connected to the net to install Django, unless you already have the python utility “setuptools”. Oh crap! Hopefully I have it! I did a search and found it was already installed. Whew! I untar the Django tarball and type “python setup.py install” … rock and roll!

Now, proceeding in orderly fashion to tutorial01.txt I see the command to create a django site:

django_admin.py startproject samplesite

BURN!!!!

-bash: django_admin.py: command not found

HUH! … ok.. so maybe django didn’t install right. I do a search and I found it installed in Python/2.5/site-packages/django/bin .. oh, doh! I used an _ (underscore) instead of a - (dash).

*smack forehead* … as often happens with a new thing, I get way to excited and forget the small details. The devil is in the details!

Lets try again:

django-admin.py startproject samplesite

HEY! It works, imagine that. Using the right command works. yay

Hmmm.. contrast the starting struture of an new Django site with Rails:

Django:
—
-rw-r–r– 1 nstowe 499 0 Apr 14 08:10 __init__.py
-rw-r–r– 1 nstowe 499 153 Apr 14 08:12 __init__.pyc
-rw-r–r– 1 nstowe 499 546 Apr 14 08:10 manage.py
-rw-r–r– 1 nstowe 499 2812 Apr 14 08:10 settings.py
-rw-r–r– 1 nstowe 499 1763 Apr 14 08:12 settings.pyc
-rw-r–r– 1 nstowe 499 233 Apr 14 08:10 urls.py
-rw-r–r– 1 nstowe 499 253 Apr 14 08:13 urls.pyc
—

Rails:
—
—

Interesting… Moving on! Next part of the tutorial is starting the server:

python manage.py runserver

Yay, the server starts right up.

I edit the settings.py file and tell my site to use sqlite3 and dbfile of samplesite_development.db (wondering, does django use different dbs like rails? dunno, but I am used to this convention now!)

The last section of the settings file has a list of installed apps (seems like the Rails equivalent of a plugin):

INSTALLED_APPS = (
‘django.contrib.auth’,
‘django.contrib.contenttypes’,
‘django.contrib.sessions’,
‘django.contrib.sites’,
)

According to the tutorials these are included for convenience and each of them have at least one table. So we need to create the tables –

python manage.py syncdb

This creates all the missing tables for anything in the INSTALLED_APPS. When I did it, it asked for an admin name, password and email. Thats pretty cool, I don’t recall any interactive propmpts for any rails plugins

Quote from the docs:
” Django comes with a
utility that automatically generates the basic directory structure of an app,
so you can focus on writing code rather than creating directories.”

Great, I hate creating directories. Actually, I believe one of the benefits of having a tool create a basic site structure is consistancy. Another Django developer can walk in and go “oh yeah, I know where stuff is.”

As I read the tutorial01.txt I realize that i just created a django project — not an app. Now to create my app, a voting application.

It creates a directory containing the following:

-rw-r–r– 1 nstowe 499 0 Apr 14 17:05 __init__.py
-rw-r–r– 1 nstowe 499 57 Apr 14 17:05 models.py
-rw-r–r– 1 nstowe 499 26 Apr 14 17:05 views.py

Interesting, a different concept then rails. In Rails when you do

rails my_awesome_site

It create a webapp structure or one site. Not very easy to combine two Rails apps into one.. In fact, as I know it, damn near impossible. Best way to do that is subdomains as I see it.

Moving right along.

Time to create model files.

To define a model for a pol in Django:

class Poll(models.Model):
question = models.CharField(maxlength=200)
pub_date = models.DateTimeField(’date published’)

A migration file in Rails

create table as |t|
t.column :question, :string
t.column :pub_date, :datetimeo
end

and then the model file simply is:

class Poll
end

Rails, as you probably know, uses instrospection to figure out the field names…contrary to the approach that Django takes.

One of the differences is that with this one file, Django has the creation of teh table AND the model defination, where was Rails has two files. Interesting.

Ah, here we go. Since we created this application Polls we need to “add” it to our projects, you know where we saw those default “plugins” I called them.

INSTALLED_APPS = (
‘django.contrib.auth’,
‘django.contrib.contenttypes’,
‘django.contrib.sessions’,
‘django.contrib.sites’,
’samplesite.polls’,
)

There is our poll app.

Now we need to generate the sql:

python manage.py sql poll

Thats the command that shows you what the SQL will look like, you need to run this command to actually execute that code — sync up the db!

python settings.py syncdb

In Rails, to run a database migration you would do:

rake db:migrate

In Rails all the database migration have a version number, making it easy for you to go “up” a version and “down” a version. This is a nice concept, but its a nightmare with a team more than 2 people! So this is no longer a novel concept to me. I think I’d rather let subversion do my version control.