Ikke's Blog

As I wrote in my last entry, I did some presentation on Django yesterday.
I started creating this presentation some days ago, but still had to write most stuff yesterday. So in the afternoon, I took my laptop, sat back, and added new slides to the presentation.

I must confess, I'm not a frequent saver (will change now, read on). Anyway, when I had written +- 30 new slides, I pressed ctrl-s in OpenOffice Impress. Disaster strikes. All of a sudden, Impress crashes, and the OOo document recovery dialog pops up. Before recovering the document, I created a copy of the on-disk original file, then did the recovery. Result: same file as I had before the save, 30 slides lost.

The problem: my / partition (on which /tmp resides) was at 100% (only some bytes left). The reason: some beagled-helper got >150MB .tmp files left in there.
I almost went insane.

So:

• OOo guys, *please* make your app not crash when a user attempts to save a file and /tmp is at 100%. Use some other scratch location, warn the user (and make a quick backup/recovery dump automagicly in case something goes wrong),... whatever, but do not crash on a save operation, that's completely irrational.
• beagled-helper, please remove cruft earlier and don't flood my /tmp, thanks

//EOR

Ikke • Desktop 13 comments

Yesterday I had to give some introduction presentation on Django, a Python-based web-application development framework (really cool, if you don't know it yet, take a look!).
The goal was to build some simple blog-like application during the presentation to give the audience an overview of the framework and some of it's basic capabilities (whilst still hand-coding everything, not using newforms/generic views/..., providing pointers to these great features though).

Obviously, at several points of the presentation, you got to show some example code. As most of the time you work on one source file during several stages of the presentation, you don't want to show the end file from the beginning, you want to incrementally add code.

There are some obvious ways to do this:

• Type everything by hand at every stage
• Have a source tree for each state in different directories
• Give files a special name, like blog/models.py_slide19

These "solutions" got several problems though:

• The first one is slow, error-prone and boring for the public
• The second one is acceptable but uses a lot of diskspace
• The last one is not acceptable as (in this case) because of the "wrong" filenames, you won't be able to run the django development server at the separate stages of development

The way I did it: put the code of your first slide in a (local) Git repository, create a new branch whenever you change code, check-out the branch, change the code and commit. Then when the presentation starts, git-check-out master, then everytime you're at a slide where you changed some code, git-check-out (name of the branch for this slide). I used "slideXX" as branch names, using just 1, 2, 3 etc might be better as my schema'd break if I had inserted a slide somewhere.

Really quick and easy to work this way!

Ikke • Technology 2 comments