Take the following URL:
http://my.server.tld/wow/summary/2009/05/21/?style=boxed
and imagine the following
Python
function:
def summary(request, year, month, day):
response = HttpResponse()
// do something
return response
If you see a relation between the two, then
Django is for you. The missing part
is a
URL mapping, a list of
regular
expressions, which transforms a URL into a keyword list, and
maps it to a function (a
HTTP
view, as it s called):
(r'^wow/summary/(?P<year>\d 4 )/(?P<month>\d 2 )/(?P<day>\d 2 )/$',
mysite.wow.summary, 'additional':'information' )
You do not have to use keyword arguments, positional parameters
will work as well, and you can do anything you like within the
powers of regular expressions, but the result is always along the
same lines:
When someone visits the above URL, Django calls the above
summary( ) function (defined in the modules
mysite/wow.py) and passes an object encapsulating the
request, along with the components from the URL as parameters:
summary(request, 2009, 05, 21, 'additional':'information' )
It then renders the return value. The function can also throw an
exception if it need to communicate e.g. a 404 error. Very clean,
and there are even
generic
views if your data doesn t need any massaging, of if you just
want to do standard things like
generate
PDFs.
This is the core idea of Django, which I ve gathered from
one talk and four hours of invested time. It s a truly thin
layer, and its elegance made me bouncey.
The
QUERY
STRING of the request will be passed in the
request
object, along with all the other
CGI
variables you re familiar with. Django provides a large number of
helpers and
shortcuts
to save you from having to do the ugly work, including topics such
as
internationalisation,
syndication,
authentication,
file
uploads, and
caching.
In addition, Django gives you an
object-relational_mapper
to map the data into, and manage the data definition within your
favourite
RDBMS, a
templating
language designed to fit in with the whole philosophy, and
widgets to
work with forms.
You do not have to use any of those. You are free to use any
other Python module for the task, just as you can use all of the
other features of and modules written for Python. This is
particularly powerful in the context of the
middleware
layer.
There s also a large number of
pluggable applications and
snippets for
re-use.
The only concern I have at this point is whether features like
tagging
are going to find their way into the framework, because tracking
numerous external plugins for a site and keeping them working
across versions reminds me of the nightmares I had with
Zope and
Plone
(I stopped working with (and on) those before I had a chance to
dive into version 3 of each).
The fact that Django leaves data storage to other tools (in
fact, it s entirely up to you) makes those nightmares seem further
distant.
All in all, I am excited to have had a chance to take a brief
glance at the software, and I am looking forward to doing more with
it. Unfortunately, it looks like it will take quite some time to
wade through existing plugins and design the rest of an application
that can
finally replace the horrific dung-pile that is
my homepage.
As I am attempting to focus on writing projects that are more scholarly
and academic on the one hand (i.e., work for my day job at MIT) and
more geared toward communicating free software principles toward wider
audiences on the other (e.g., Revealing Errors), I have little
choice but to back away from technical writing.
However, this last month has seen the culmination of a bunch of work
that I've done previously: two book projects that have been ongoing for
the last couple years or more have finally hit the shelves!
The first is the fourth edition (!) of the bestselling Official Ubuntu
Book. Much to my happiness, the book continues to do extremely well
and continues to receive solid reviews. This edition brings the book up
to date for Jaunty/9.04 and adds a few pieces here and there.
Although I was less active in this update than I have been in the past,
Corey Burger continued his great work and Matthew Helmke of Ubuntu
Forums fame stepped up to take a leading role. As I plan to retreat into
a more purely advisory role for the next edition of this book, I'm
thrilled to know that the project will remain in such capable hands.
I'm also thrilled that this edition of the book, like all previous
editions, is released as a free cultural work under CC BY-SA
For years, I have heard people say that although they like the Official
Ubuntu Book, it was a little too focused on desktops and on beginners
for their tastes. The newly released Official Ubuntu Server Book is
designed to address those concerns by providing an expanded guide to
more "advanced" topics and is targeted at system administrators trying
to get to know Ubuntu. Kyle Rankin planned and produced most of this
book but I was thrilled to help poke it in places, chime in during the
planning process, and to contribute a few chapters. Kyle is a
knowledgeable sysadmin and has done wonderful job with the book. I only
wish I could take more credit. The publisher has promised me that, at
the very least, my chapters will be distributed under CC BY-SA.
Many barriers to the adoption of free software are technical and a good
book can, and often does, make a big difference. I enjoy being able to
help address that problem. I also truly enjoy technical writing. I find
it satisfying to share something I know well with others and it is great
to know that I've helped someone with their problems. I'll assure I'll
be able to do things here and there, I'll miss technical writing as I
attempt "cut back."
I released a new 0.9.7.2 version of DAViCal yesterday. This reflects quite a lot of stability and small fixes for some subtle problems, and quite a lot of work with the iPhone, adding the possibility of a simpler configuration experience for iPhone users.
One long-standing, but less obvious problem (well, less obvious to me) was the handling of usernames with odd characters in them. In the round-trip these needed to be urlencoded, and that wasn't happening correctly in all places, but it hopefully is now. People who want to use e-mail addresses in usernames, or spaces in calendar names, or both, etc., should all work now.
One newer problem I've been seeing the effects of a little recently is that PHP 5.3 deprecates call-time pass by reference, which I had used in a few places. That's fixed now, so it should be OK to upgrade to PHP 5.3 without breaking DAViCal or having to explicitly turn those warnings off.
The iPhone is a curious beast. Lots of people love them, and it is about the only mobile device that supports CalDAV (though I'm hoping the Nokia N900 also will), so it's important to support it as transparently as possible regardless of my personal loathing for it's horribly locked down state. It was pointed out to me that it is possible for it to be configured by entering three pieces of data (domain name, username, password) so I decided to make DAViCal support that process. In order for it to work for you you will need to have DAViCal running on an SSL server on port 8443, which isn't too big a deal. You can also plain http on 8008 which it will also attempt after prompting when the SSL connection fails. You'll also have to enable mod_rewrite and use some rewriting rules like the 
A while ago, I thought: I seem to be less productive than I used to be. Why might that be? Do I spend more and more time with e-Mails? Or is it something else? I couldn t tell, so I needed a time tracking tool. There are a few of those for Linux that allow you, while working, specify what you are doing and then generate statistics about it. This approach has a few disadvantages:
In Spain this summer, I gave a talk about new features in
The idea of breaking programs into functions was taught to some of
us with the metaphor of "divide and conquer." That is, make several
smaller problems and solve those instead.
This approach is now so deeply ingrained that I can just think
"partition and solve" which is of course a much more positive and
accurate description.
One might think of the "partition your program into functions"
principal as "the divide and conquer" principal. But of course, they
are both instance of the more general "partition and solve". I dare
say that "partition your program into functions" is even a more pure
and accurate instance of the principal.
Evolution may also be an instance of the principal. Different
species evolved to solve different problems, or to solve the same
problem (survival) in different ways.
Of course, when you partition a program into functions, you also
define those functions' relationships to each-other. Just because
you're partitioning doesn't mean that the problems are not related.
When people see several competing projects in the "free software
community" trying to solve the same problem, some might say, "Good.
We have divided them, now we will conquer them!" In their marketing
material (or more likely press-release ranting) they will say that a
house divided against itself will not stand [1].
Such people are probably purposefully ignoring the "partition and
solve" principal. They ignore the fact that different projects have
chosen different paths to solve different problems. They ignore the
relationships between the projects, and that we feed each-other much
more often than we actually compete. But no good programmer will
ignore the relationships between her functions.
Even within the 
Yesterday's
po4a creates the meta files needed to generate the manpages but the actual generation process is a little awkward and tends to become heavily customised.
) will come to the rescue.
As there're several, more or less well working howtos about creating udev rules to allow access to the USB debug devices of Android phones out there in the wild, I decided to write my own one. It works at least for Debian Testing/Squeeze. The udev rules file I provide here works at least for the HTC Dream models (aka T-Mobile G1 and Google Devphone).
As a computer may be used by more than one user, I've decided to create a group called androiddev. Members of the group will be allowed to access the debug interface. Running (hint: become root first)
addgroup --system androiddev
will create the group for you. Add your developers to the group with
adduser username androiddev
(of course replace username with the user you'd like to add) and we're ready to configure udev. Open /etc/udev/android.rules in an editor and add the following lines:
Thanks to TauPan from #debian/freenode.net who gave me the idea for this blog post.