Last time I had to use S3 uploads in Django was in 0.96 and I am happy to report that it is simpler than ever to upload files to S3 in Django. The recent storage-engine refactoring in Django 1.0 makes it a breeze to implement - no need for custom field types or anything like that.

David Larlet has put together a very good collection of Django storage-engines that looks very well-written compared to some naive implementations that I happened to stumble across elsewhere on the web. In addition, it includes a library for MogileFS - looks very exciting indeed and I hope I’ll have an opportunity (or reason rather) to play around with it one day!

To use, simply download Amazons S3 api, along with Larlet’s storage-engines (I just placed them in site-packages), and then your model would look something like the following:

import S3Storage

class UserProfile(models.Model):
    storage = S3Storage()
    profile_image = models.ImageField(upload_to='some-dir', storage=storage)

I’ve been quite busy lately, but I decided I’d share a few lines of code on how to do JSON (as well as XML) serialization in Django - its very simple.

I like the REST-based approach that Rails takes, so I kind of incorporated that in my code. It allows you to do something like this:

Regular view:

http://foo.com/banners/list/

JSON serialized data:

http://foo.com/banners/list/?format=json

XML serialized data:

http://foo.com/banners/list/?format=xml

On to the code:

# models.py
class Banner(models.Model):
	title = models.CharField(max_length=64)
	url = models.URLField()
	image = models.ImageField(upload_to='img/banners/')

# views.py
from django.core import serializers
from django.http import HttpResponse, QueryDict
from django.shortcuts import render_to_response

def request_format(request):
	default_format = 'http'
	q = QueryDict(request.META['QUERY_STRING'])
	format = q.get('format', default_format)
	if(format not in ['http','json','xml']):
		format = default_format
	return format

def list_banners(request):
	banners = Banner.objects.filter()
	format = request_format(request)
	if format == 'http':
		return render_to_response('list_banners.html', {'banners':banners})
	else:
		serialized_data = serializers.serialize(format, banners, fields = ('title', 'url', 'image'))
		return HttpResponse(serialized_data, mimetype='application/'+format)

So, I’m sure most of you heard about Chrome, Google’s new browser by now. Well I have to tell you - as a developer - the idea of having to support yet another browser is outright frightening to me. On the other hand, anyone who has any experience closing Firefox multiple times a day due to gigantic JS memory leaks can attest to the potential benefit that this new browser can bring to the table.

Chrome has found its place among an impressive and ever growing line-up of beta services and products that have been rolled out just in the last year.

• Android

  Will this be an iPhone without fascist limitations?

• KNOL

  Are Google going to be able to battle it out with Wikipedia?

• Google Apps

  Ok, this isn’t that recent, but its free. Microsoft Office anyone?

• Google Health

  Going after Microsoft Health Vault?

• Google App-Engine

  Ouch! Amazon EC2, Slicehost & co - you just got sliced.

• OpenSocial

  Could be a threat to Facebook?

• Lively

  Second-life with mass-appeal?

So, what do you make of it? Some endeavors obviously stand out having more potential than others, and one thing is clear: the 20% of Employee Innovation time is paying off in way of innovation. The big question on my mind, however, is how Google manages these projects internally and exactly what financial homework is made before a project gets a green light.

The concept of grid-based layouts has been around since the 1950’s and the first time I came across it was actually in an old book about print design that I picked up while I was in college. Early on, I kind of developed my own conventions with regards to grids and tended to design sites to be 780px in width, since this number leaves enough margin for a vertical scrollbar on 800×600 resolution and more importantly, can be divided in 1, 2, 3, 4, 5 or 6 columns giving you a flexible, symmetric grid design for your layout.

Most e-commerce sites I work on still have about 10-15% of users using 800×600 resolution, but when we built futurevacations.com, the designer we used for the project used a layout that was 960 pixels wide, which from the look of it didn’t look out of the ordinary to me until all the HTML and CSS was done and I realized we might have problems.

Now, I do have to admit that I rarely browse too many web-design blogs these days - its an area that I have been knowingly neglecting the past 6 years since I started developing a greater interest for programming languages and software design. Anyhow, for futurevacations.com, we decided to keep our layout at 960px in width since it gives us more screen-estate to work with and those 800×600 users will likely diminish significantly over the lifespan of the site, so we felt pretty good about how this worked out.

So, the past month after we rolled out the site, I have to admit I was curious to find out why this seemingly arbitrary number of 960px was chosen, but ironically, I was not curious enough to look for answers. Today however, I stumbled across a blog that made a reference to the 960 Grid System, developed by Nathan Smith. Upon reading more, everything started making more sense; 960 is in fact an ideal width for a grid-based layout since it is divisible by 2, 3, 4, 5, 6, 8, 10, 12, 15, 16, 20, 24, 30, 32, 40, 48, 60, 64, 80, 96, 120, 160, 192, 240, 320 and 480. If you are interested, his site contains a download that contains some useful stuff like a .psd and some HTML and CSS to go with it. Enjoy!

I have been contemplating switching to Mako templates for my Django projects for quite some time, partly because I found some of the template syntax in Django slightly awkward.

Today, a question about recursion support in Django templates came up on the #Django IRC channel, which made me think for a minute. Off the top of my head, I couldn’t think of a quick way of accomplishing this in Django, short of using a template tag. However, some examples that I had seen in Mako came to mind, which illustrates the flexibility and power of this templating language.

I decided I would put together some code just to showcase how it could work. The example I chose is to print an organizational chart using the simple Employee class below:

models.py:

class Employee(models.Model):
    name = models.CharField(max_length=64)
    reports_to = models.ForeignKey('self', related_name='employees')

organizational_chart.html:

<ul>
    ${render_employee(ceo)}
</ul>

<%def name="render_employee(person)">
    <li>${person.name}
    <ul>
    % for employee in person.employees:
         %{render_person(employee)}
    % endfor
    </ul>
    </li>
</%def>