Fist you need to install Django. I will not repeat the documentation on Django. So you should read the Django’s Installation Guide.

There is to note that I am using the bleeding edge version from their subversion repository. This is done in anticipation of their 1.0 release, which is scheduled for beginning of September. You can use the 0.95 version, but It lacks some juicy bits.

All Django project (website) starts the same way:

django-admin.py startproject rioki

This will create a template, but usable website.

On of the nifty features is that Django comes with a embedded web server that can (and only should) be used for development. This feature really cuts down development time.

To use it launch the server (in the project directory):

./manage.py runserver

You will now find your website under http://127.0.0.1:8000/.

Well it actually is only a page that tells you have not “configured any urls”. We will get to that soon.

Well the first step is to configure your site. This is a simple process, open settings.py in your favorite text editor and edit the file as appropriate.

Mine looks about so:

from os.path import join, dirname

DEBUG = True
TEMPLATE_DEBUG = DEBUG

ADMINS = (
    ('Sean "Rioki" Farrell', 'i.dont.think@so.com'),
)

MANAGERS = ADMINS

DATABASE_ENGINE = 'sqlite3'
DATABASE_NAME = join(dirname(__file__), 'database')

TIME_ZONE = 'Europe/Berlin'

LANGUAGE_CODE = 'en-us'

SITE_ID = 1

USE_I18N = False

MEDIA_ROOT = join(dirname(__file__), 'media')

MEDIA_URL = '/media/'

ADMIN_MEDIA_PREFIX = '/admin_media/'

SECRET_KEY = 'Mine, not yours...'

TEMPLATE_LOADERS = (
    'django.template.loaders.filesystem.load_template_source',
    'django.template.loaders.app_directories.load_template_source',
)

MIDDLEWARE_CLASSES = (
    'django.middleware.common.CommonMiddleware',
    'django.contrib.sessions.middleware.SessionMiddleware',
    'django.contrib.auth.middleware.AuthenticationMiddleware',
    'django.middleware.doc.XViewMiddleware',
)

ROOT_URLCONF = 'rioki.urls'

TEMPLATE_DIRS = (
    join(dirname(__file__), 'templates')
)

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

I used a nifty trick for the different paths. For security and stability reasons, you are to give absolute paths for the values such as MEDIA_ROOT. Well I use join(dirname(file), ‘media’), which makes it relative to the settings.py file. As a result I can move the entire package around and always be right and an absolute path.

Now is a good time to create the initial database:

./manage.py syncdb

Well this will load the initial tables and ask you if you want to create a super user.

One of the most powerful features is the admin backend. You might not see that in this post.

To use the admin you need to add 'django.contrib.admin‘ to the INSTALLED_APPS. You need to rerun syncdb, wich you must almost always do after you add something to INSTALLED_APPS.

./manage.py syncdb

In addition uncomment lines for the admin in urls.py. You urls.py should about look like that:

from django.conf.urls.defaults import *

urlpatterns = patterns('',
    (r'^admin/', include('django.contrib.admin.urls')),
)

You can see the admin interface under http://127.0.0.1:8000/admin/

Here you can see one of the nice features of Django: Instant pretty URLs. This comes from the fact that all incoming requests are matched against a table of regular expressions.

You might want to change the Sites entry from example.com to your website, but that’s all for now.

Django comes with a module for static content, that is django.contrib.flatpages.

To use it add 'django.contrib.flatpages‘ to INSTALLED_APPS and 'django.contrib.flatpages.middleware.FlatpageFallbackMiddleware‘ to MIDDLEWARE_CLASSES.

Rerun syncdb:

./manage.py syncdb

Now you can add some pages via the admin. I added ”/” for the portal page and ”/imprint/” for the imprint. You can find the pages you created at http://127.0.0.1:8000/ and http://127.0.0.1:8000/imprint/.

Well actually, you can’t. It is still complaining about a missing template. Let’s create that.

Create the file templates/flatpages/default.html:

<html>
    <head>
        <title>{{ flatpage.title }}</title>
    </head>
    <body>
        <h1>{{ flatpage.title }}</h1>
        {{ flatpage.content }}
    </body>
</html>

As you can see the content is copied verbatim. You got two solutions you either write the content HTML or use one of the built-in markup languages.

Django comes bundled with 3 markup languages, that is Textile, Markdown and ReST. To enable those you need to add 'django.contrib.markup‘ to your INSTALLED_APPS. And change the template to look like this:

{% load markup %}
<html>
    <head>
        <title>{{ flatpage.title }}</title>
    </head>
    <body>
        <h1>{{ flatpage.title }}</h1>
        {{ flatpage.content|textile }}
    </body>
</html>

As you can see we are using textile.

During debug we are using the builtin server. That has the consequence that media files are not explicitly served. To fix this we we extend urls.py file:

from django.conf.urls.defaults import *
from django.conf import settings

urlpatterns = patterns('',
    (r'^admin/', include('django.contrib.admin.urls')),
)

if settings.DEBUG:
    urlpatterns += patterns('',
        (r'^media/(?P<path>.*)$', 'django.views.static.serve', {'document_root': settings.MEDIA_ROOT})
    )

As you can see, the media files are only server through Django when in debug mode. In production mode, on the production website media is server through apache. This is a obvious performance issue.

Well so far we are “done”, except that the site looks really crappy. I took the design from this site, as it will replace it and just adapted it to Django.

I created the site rump templates/default.html:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE html PUBLIC "-//W3C//DTD XHTML 1.1//EN" "http://www.w3.org/TR/xhtml11/DTD/xhtml11.dtd">
<html xmlns="http://www.w3.org/1999/xhtml" xml:lang="en">
    <head>
        <title>{% block title %}Rioki{% endblock %}</title>
        <link rel="stylesheet" type="text/css" href="/media/design/default.css" />
    </head>
    <body>
        <div class="page">
            <div class="header">
                {% block header %}
                    <a href="/">Start</a> |
                    <a href="/blog/">Blog</a> |
                    <a href="/about/">About</a> |
                    <a href="/proejcts/">Projects</a>
                {% endblock %}
            </div>
            <div class="sidebar">
                {% block sidebar %}
                    <h3>Sidebar:</h3>
                    <ul>
                        <li><a href="http://www.libqgl.org">libQGL</a></li>
                        <li><a href="http://www.sf.net/projects/lunar-exodus">Lunar Exodus</a></li>
                        <li><a href="/stl_algorithm_shortcuts">STL Algorithm Shortcuts</a></li>
                        <li><a href="/tstring">std::tstring</a></li>
                        <li><a href="/blog:itx_rock_my_web_app">ITX Rock my Web App</a></li>
                        <li><a href="http://www.motivator-generator.com">Motivator Generator</a></li>
                    </ul>
                {% endblock %}
            </div>
            <div class="content">
                {% block content %}No content here.{% endblock %}
            </div>
            <div class="footer">
                {% block footer %}
                    © 2006-2008 Sean Farrell<br/>
                    <a href="/about/">Imprint</a> |
                    <a href="/contact/">Contact</a>
                {% endblock %}
            </div>
        </div>
    </body>
</html>

I also put CSS style sheet and the images into /media/design.

This is nice, but the flatpages need the design. To do this I altered the template for the flatpages to be the following:

{% extends 'default.html' %}
{% load markup %}

{% block title %}{{ flatpage.title }}{% endblock %}

{% block content %}
    <h1>{{ flatpage.title }}</h1>
    {{ flatpage.content|textile }}
{%endblock %}

And viola, the beauty of reuse.

As far as it comes to static content, we are done. To be honest for many sites this is enough; but not for mine.

Firs of all we need the blog. This site is 90% blog, so it will really miss. I could realize it via flatpages, but that is slightly awkward.

An other issue is that media files need to be uploaded to the server via some file transfer process, I want to be able to do that via the admin, since I may not have access to the server directly.

As you can see the menus are hardwired to the template, this is Ok if they don’t change often. (Which might be the case here…) But I want to be able to change them at any time via the admin.

Finally textile is okish, but I don’t like it too much. The other markup languages are worse. I have once tried to implement the dokuwiki syntax in python, let’s see if that works out as template tag.

What needs to be done:

• blog
• handling of media files via admin
• handling of menu via admin
• integrate dokuml

In my dally work I am astounded as how little your average programmer or rather software engineer knows about the common tools of the trade.

Under some of the books I own is:

• Pragmatic Programmer - Andrew Hunt and David Thomas
• Mythical Man Month - Fred Brooks
• Design Patterns - Erich Gama et al.
• Test Driven Design - Kent Beck

And thew discuss a number of issues and tools every programmer should know1).

Can you imagine that, as far as I have seen, at least 50% did not know about unit testing or design patterns?! I am not saying that you need to use them all the time, which is absolute folly. But not even knowing that they exist is a sin.

What is even more depressing is that the younger generation should and probably had these subjects mentioned during their university courses. How can people not take their job seriously and thus make their job herder and more turblesome.

As I was playing with the height maps I needed Vectors and Quaternions. So I shamelessly copy and pasted the implementation from libQGL. After a while I suddenly realized that I had something useful on its own and decided to release only the math stuff from libQGL as libqgl-math.

After thinking for a while I noticed that the packeting strategy I have for libQGL is crap. I have a bunch of stuff that is useful on its own, but together is incomplete. As a result I decided to split libQGL up in relative little clearly contained packages.