As developers progress along the path from Django grasshopper to Django master and beyond, it slowly (or rapidly) dawns on them that Django's project concept is something that really only exists as a convenient kickstart mechanism. It's a great way to help you get your initial work started and arrive at the point where you can start writing code.

The usefulness of the project concept is reinforced by the fact that django-admin.py startproject exists and does all this work for you. Surely, we are meant to use projects all the time.

No! A project is certainly a convenient "getting started" concept. It's also a handy development aid (the meaning of which, I'll describe later). However, the core of Django-based software is the application, not the project. When you distribute Django software to other people, you are generally distributing one or more applications.

So, here are a few tips and tricks for using a collection of Django applications without needing to create a Django project.

(Read more...)

Topics: software/django/tips

[#]

I recently received an email from somebody asking for about experiences using git to do development for Django. It turned out they weren't interested specifically in git, but in how it was working using a different system from the upstream master repository.

Well, I can write a few words about that. I've written about some of my previous experiences here and here, so this is an update based on accumulated experience.

(Read more...)

Topics: software/django, software/version control

[#]

A recent thread on django-developers discussed one style of laying out views, whereby the handling of different request methods to the same URL end up in different functions. This isn't a requirement or even a good idea in some cases (since there's frequently a lot of common code), but when it is a good solution, doing it frequently can become repetitive.

Fortunately, adding any extra code to Django's core isn't necessary to handle this. We can write a helper method that's less than twenty lines of code (and could be much shorter if I wanted to be less readable). This article is about the design of such a feature (at least, about my design, since different people want different hings). Code is included.

(Read more...)

Topics: software/django/tips

[#]

Considering the late finish yesterday, I feel surprisingly good today. This can't last.

Still, let's do some more ticket closing. The liveblogging continues...

(Read more...)

Topics: software/django

[#]

A follow-on from yesterday's experience. The Django sprint continues.

(Read more...)

Topics: software/django

[#]

Today (for values of today that mean "Friday") is the Django sprint.

Since I'll be around and online most of the day (and probably tomorrow), I thought I'd keep an entry updated with what's going on from my end.

(Read more...)

Topics: software/django

[#]

Less than 48 hours ago, Adrian floated the idea of having a Django code sprint next Friday. One might have thought the even though it was a Friday and only a week away would have meant we might get a few dozen people attending.

As I write this, 73 people have indicated they'll be attending (in at least a virtual sense) on the wiki page! Very encouraging. A little scary, too. We're going to have to be a bit organised before hand to avoid looking like the online equivalent of the car chase scene from the first Blues Brothers movie (although Adrian, being enthusiastically a man of Chicago, probably wouldn't mind that happening).

Personally, I'm going to write down some triaging and testing tips and see if some "guide to Django codebase" notes I have are in a form I could put them up without looking like an idiot. Somehow I have to do this without taking time off from rewriting queryset code. Guess that's why I have two hands.

(People interested in participating should remember that Friday is a long day once you start in New Zealand and finish in Hawaii. So you can still participate even if you can't take a day off work or get your employer's blessing to participate. Plus, the odds of it rolling into Saturday and/or Sunday out of momentum aren't too bad, either.)

Topics: software/django

[#]

It might turn out to be a week of posts related to software development. I have a few half-written pieces and lists of ideas in a folder, whence was born yesterday's initial debugging post and today's design observations.

Software design (and its ties to implementation) is not a new topic and there are few clearly right or wrong answers. I'd like to focus a bit on the internal process; what I go through when I'm tackling a design problem. The dirtily practical over the theoretical and recommended, so the speak.

(Read more...)

Topics: software/design, software/django

[#]

I'm a big believer that a large part of the art of successful debugging is attitude. If you adopt the attitude that you can fix the problem and you're not getting to let this piece of technology make you look feeble and unworthy, you'll usually win.

There's more to write about that another time. Today I want to write a bit more about the flip side of this: being a responsible debugger and making sure you are fixing the real problem, not merely making the symptoms go away.

(Read more...)

Topics: software/design, software/django

[#]

(This a follow-up to this item, which may not have been syndicated to all the same places, since it isn't in exactly the same categories.)

Selected moments from the last couple of days of OSCON:

• The Python BOF on Wednesday night. Excellently moderated by David Goodger. Probably around 20 or so people there. Many being fairly experienced Python users. A general consensus that selling Python to the PHB level of management is still senselessly hard. It's almost an argument for certification. All involved in the hiring process seemed to agree that wouldn't change the way they hired, though. Teaching Python to good people is easy and Python's the type of language where you can get a good feeling about an existing developer's work in a number of ways. A piece of paper won't change that. Other topics including code organisation, other languages used, promoting certain packages as reference implementations were all interesting. Over two hours of good conversation (and beers).

• The Django BOF on the following night was well attended, too. Around 18 people, ranging from a few who were just starting out to some who were using it in high profile site. Conversation mostly driven by the more experienced users. I came away with a list of about 15 things that we can look at that I need to write up as an email to django-dev over the next day or two. Hallway conversation after the hour-long BOF went for another 90 minutes with a different group of people.

• A talk on 37signals' experiences with using Amazon's S3 for mass storage was interesting. Mostly it was a litany of woes about "what can go wrong will", but it provided some very constructive lessons learnt about the extra work you have to do and expectations if you're going to hitch your business implementation to something like S3.

• r0ml is a very entertaining speaker and I enjoy hearing him talk. Always something to learn about presentation. However, his point and generally excellent arguments are sometimes obscured by his entertainment style and this is a shame. It took a lot of work to sort wheat from chaff in his Preventing Code presentation.

• Greg Kroah-Hartman's talk on the state of the Linux kernel in 2007 will be useful as data for the future. He's done a lot of crunching of numbers with regards to number of contributors (including nice chart), number of lines of code, proportion of change in various subsystems, and so forth. The simple conclusion is that anybody trying to maintain a parallel branch of the kernel is looking impossibility in the face. Pushing things into the mainline is the only way to go, because it's just too frantic. And yet, the system mostly works. The kernel remains healthy and solid.

• Having contact with other Django developers and users during the day was very motivating. I got a lot of coding done during downtime between talks and in the evening back at the hotel. Some big ticket items, too (since the little ticket stuff tends to take care of itself).

The last few days have been a bit of a blur, so there might be an OSCON, part III post once my brain settles down and organises things.

Mostly recovering today and doing very little. Off to New York City tomorrow to enjoy ... I don't know ... stuff. Weather. Central Park. Manhattan Restaurants. Things like that.

Topics: software/django, conferences/OSCon, travel

[#]