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.
Here are a few hints if you want your reports to be treated more promptly.
When testing fails, try unstable
If you are running testing, not all bug reports are interesting. More specifically, the relevant ones are about insufficient dependencies that let slip into testing a non-working combination of packages. Think of the I upgraded foo, then bar broke category.
Otherwise, the reason why reportbug looks for newer versions of a package in unstable is that, in most cases, the bug is fixed in unstable. If you can, always try the unstable version before reporting the bug.
Report bugs against the failing package
This is related to printing in a GNOME program, so I report this against libgnomeprint.
Always file reports against the failing program. If there is a library involved, reportbug will include the necessary information so that the maintainer can easily reassign. If you re not sure of the affected package, use a metapackage (for example, gnome for GNOME-related packages).
Do not second-guess the origin of the bug
After upgrading libfoo, bar starts crashing, so I m reporting it against libfoo.
Unless you can tell which function is at fault and how this is ABI breakage, you should report the bug against the program that crashes. The program s maintainer will reassign if needed, and will hit the library s maintainer with a hammer if needed.
Don t forget to explain what s wrong
The frobniz in libfrob is broken, you should change /usr/share/libfrob/blah line 13 to something else. I don t know what libfrob is about, but I have some problems that look frobniz-related.
Do not second-guess, always start explaining what bug you are seeing first. Your attempts at investigating it can be interesting, but don t forget to explain what bug lead you on investigating.
What is the use case we should cover?
I m trying to do that with your package and it looks extremely complicated/doesn t work as expected/fails miserably. Your package is clearly broken!
If your attempts to do something that should be trivial, given the purpose of the package, fail, then you are probably looking at the problem at the wrong angle. There may be a much simpler, though radically different, way to do what you are trying to achieve.
In these situations, always include in your report what you are trying to do and why you want to do it.
strace is not a general-purpose debugging tool
Whether you observe a crash, a deadlock or a livelock, strace is not the tool that will give us information. The only thing you do by adding a strace log to the bug report is making it unreadable with its thousands of lines of output.
For the specific cases that require strace for debugging, these traces are welcome but if you re not sure, don t attach them. The developers will ask them for you. Otherwise, the general-purpose debugging tool is 
Wow! 
Ever since I bought 
The monthly board meeting of 
Etch -> Lenny
I performed the first successful installation of Debian on the QNAP
TS-219 using the Debian installer today. Everything is in place now
but the Linux 2.6.29 kernel has to move to testing so installations will
work.
It's taken a lot longer than I expected (mostly due to getting other things done in Emdebian etc.) but now that Lenny is out, 
I have prepared an epiphany-webkit source package some time ago, and it has finally got out of NEW, thanks to the work Ganeff did this weekend on processing the queue =).
The good thing about those packages is I have patched them heavily to allow for easy parallel installation with Epiphany/Gecko, so you don t need to give up your current browser to experiment and test Epiphany with the WebKitGTK+ backend. The gconf tree used for this package is /apps/epiphany-webkit, separate from the normal /apps/epiphany, for extra safety, but notice that your ~/.gnome2/epiphany will be shared between the Gecko and WebKit versions, even though the files used by each of them are different most of the time.
Go ahead and install the epiphany-webkit package, and have fun. Notice that if you have an already running session of Epiphany/Gecko, running epiphany-webkit will not be enough to launch Epiphany/Webkit, since Epiphany will just request that a new window be opened through D-Bus. The easiest way to test, if you just want a quick peek, is to run epiphany-webkit -p; this will run a private instance of Epiphany/WebKit, which doesn t touch your history, bookmarks, and passwords.
If you are feeling adventurous and want to make Epiphany/WebKit your default Epiphany you can do so using the following command, and selecting epiphany-webkit:
Dear students, the Community Bonding Period is