New Django Website

Same theme, different backend

The Pyramid version of aclark.net was almost two years old and needed an overhaul. Django appeared attractive because:

• I know Django, but I don’t know enough Django. Like with Pyramid and Plone before, I learned a lot of Django while developing this site over the last few weeks.
• There was no “content” with the previous (Pyramid) site. The idea of putting my “content” in Django models was appealing to me.
• The new Django project website is awesome! An awesome website makes me want to build another awesome website with an awesome web framework. Awesome.

I hate code generators

I typically hate using code generators, full stop. But somehow Django’s startproject and startapp don’t make me want to vomit. So I used them in an organic [1] way, to make some obnoxiously long package names, and I miraculously don’t hate the results! This can only mean:

• I am more tolerant of boilerplate code when learning a new framework, and/or:
• The process of creating the boilerplate code and the resulting boilerplate are so elegant/minimalistic that my insatiable desire for elegance/minimalism is at least partially satisified.

No Postgres? No problem

The idea of having to develop locally with Postgresql (or some other “real” database) feels “heavy” to me. With sqlite, I don’t have to worry about database setup until I’m ready to worry about database setup [2].

I even pushed to Heroku with the sqlite database checked in, until I was ready to deploy Postgres. And I still use sqlite locally.

Bootstrap all the things

Sure Bootstrap is ubiquitious now, but it remains attractive nonetheless. One of the first tasks I performed was add django-admin-bootstrapped to my INSTALLED_APPS [3].

And because it’s 2015, I Bower-installed Bootstrap and Fontawesome for my theme development.

Make like a tree and file

Lately I’ve gotten into the habit of using good-ol’ Make to automate various tasks [4]. This project was no exception:

dump:
    curl -o latest.dump `heroku pgbackups:url`
push:
    git push
    git push heroku master
sync:
    heroku run python aclarknet/manage.py syncdb
publish:
    git commit -a -m "Update"

Add-ons, Apps, Eggs, Distributions, Packages, Products, Wheels

I am literally annoyed by the figurative abomination that is Python packaging terminology. The proliferation of terms is understandable though because of the many layers of technology, each with its own terminology, that may or may not overlap:

• The Python language
• Various packaging frameworks
• Software written in Python

And all of that was just so I could tell you I pip-installed the following:

Django
Pillow
django-admin-bootstrapped
django-cumulus
dj-database-url
dj-static
gunicorn
psycopg2
-e aclarknet

Buildout, Conda, easy_install, pip

On a related subject, why do I have a setup.py? I get the feeling that Django projects in the wild sometimes have one and sometimes don’t. And the Django documentation has only a few mentions of setup.py. So why do I have one?

In short, because I want my code in sys.path. I have another feeling that when Django projects/apps/etc don’t have setup.py files, they are somehow manipulating sys.path manually to include themselves. There is slightly more mentioning of sys.path in Django’s documentation, at least.

Anyway, I use setup.py because I’m familiar with setuptools.

Contact Form

Enough packaging rants, back to the rest of the Django story.

Every business website needs a contact form, right? And contact forms are tedious and boring to create, right? Yes and yes. That’s why I thought using django-contact-form would be a good idea. Unfortunately I ran into an issue I couldn’t easily work around, so I gave up and made my own [5].

ORM I really on my own?

That’s right. After adding an ImageField I expected the image to be stored in the database and not the file system, and I’m not ashamed. Since that was not the case, I ended up using django-cumulus [6].

Overall

Overall, this was a great experience. As such, I’m now considering another pythonpackages.com reboot with Django; to further exercise my Django chops and fullfill the packaging-automation-vision I’ve had since late 2011.

Please let me know your reaction to my experiences in the comments.