Plans for 2010

I don't intend to write much about my just announced pregnancy over on the thoughts/geeky side of my weblog, but there are a couple of geek implications, assuming all goes well:

• it's unlikely in the extreme that I will make it to OSDC 2009 in Brisbane in November (it's very close to the deadline when airlines will stop letting me fly, in addition to discomfort and so on); and
• it's completely impossible that either Andrew or I will make it to linux.conf.au 2010 in Wellington in January.

I'll not be especially available for additional volunteer tasks in 2009, since I will be trying to finish my PhD work with a small human trapped in my abdomen.

For Andrew's other 2009 and 2010 availability check with him, I can't see that I'll be volunteering to travel before at least April 2010 and that might depend on someone donating a nanny to accompany me.

I am cut about lca2010, especially considering the effort I'm sinking into it. I really hoped that wouldn't happen, but it's turned out to have the worst possible timing. If a generous donor offers to fly, say, 20 of the speakers to Sydney afterwards and re-stage the conference for the sole benefit of me, I will not say no.

Syndicated 2009-06-17 03:00:13 from puzzling dot org: thoughts

Possible structures for a technical talk

Edited version of a private email I sent about linux.conf.au 2010 preparation, but not conference-specific. The email discussion led to me enumerating the kind of talks that I think you can give about technical subjects at a linux-conf.au-style (non-academic developer-oriented) conference. <h3>Recitation of facts; or the architecture diagram talk</h3>

In this kind of talk, the speaker walks the audience through, say, the architecture of a project. The talk contents are dictated by the architecture. Five minutes on the input module, five minutes on preprocessing, five minutes on transforming into a new set of matrix bases, five minutes on postprocessing, five minutes on sanity checking, five minutes on rendering.

This is the most obvious structure for a technical talk. It's also the driest structure. It is useful mostly for audience members who want to work on or with the project code, which is for most talks a small fraction of the audience. It best suits very major projects with years of cruft in their architecture and a wide potential userbase. <h3>Insane hack adventure; or "hacking the Tivo", Andrew Tridgell, linux.conf.au 2001</h3>

In this kind of talk, the speaker usually talks about a project he or she personally undertook and structures it as a battle against the odds. So of course Y is the most obvious solution, although not trivial. So I tried Y for a couple of months. And then it turns out that the X protocol absolutely makes Y impossible for these reasons [dramatic pause] and at this point any normal human being would have given up, but I retired to a monastery for six months and returned refreshed and a lotus blossom I saw on my return inspired me to try Q...

This is probably the most effective structure for a technical talk and it's surprisingly widely applicable (you can frame a lot of things in terms of here's the current problem, here's what you think the obvious solution is, here's what happened when I tried it). The biggest limitation is that it's very hard to do it about work you didn't do yourself so it's not available to all speakers. And you can misjudge it: so of course I tried Y says the speaker uh, Y is obviously dumb, why didn't you go straight to Q? asks the audience (at some conferences, they might well ask it out loud, repeatedly). It doesn't work for speakers who don't have expertise (at least narrowly on this one topic) over that the audience has. <h3>Demonstration of surprising ease</h3>

In this talk, the speaker proposes a task which sounds too formidable to complete in the talk slot. (Pretty much any task, for some talk slots.) They then proceed to show how it can be done despite the odds using their tool. Edward Hervey edited a video PiTiVi at linux.conf.au 2008. At OSDC 2008 Thomas Lee added a 'unless' keyword to the Python language.

This structure can be fun but it has a lot of pitfalls. Edward was continually battling to type while dealing with a handheld microphone. Speakers should recruit an assistant for these talks. The Python keyword talk was kind of fun, but it was also hard to follow: and now I am going over to this totally other tree and adding several lines to this other file at line 1099 and 1346 and is obviously required: he did not succeed in making me think I could easily edit the Python language. In all cases, it needs a decent amount of rehearsal: even more so than other talks. <h3>Dropping of wisdoms</h3>

These talks are generally (at linux.conf.au anyway) talks about the social/community/artful aspects of coding. For example, Jonathan Corbet's talk about how kernel hacking actually works in terms of the trees and maintainers etc at 2009. (One of Linus Torvalds's bigger 2009 contributions was being in the audience for that talk and adding occasional commentary on his various prejudices.) Andrew Bennetts has had some good luck with a series of talks that began at OSDC 2008, in which he essentially lists every tool he can think of to help you make your Python programs faster. I didn't see it but I would guess Paul Fenwick's talk about awesome things you've never heard of in Perl was the linux.conf.au equivalent in 2009.

These are useful talks, the main pitfall is that they require considerable expertise over the bulk of the audience. Otherwise someone is just listing a bunch of stuff you do every day back to you. They also need to be about tasks or tools that a lot of people actually use or want to use. No one wants the hidden tricks to using libnousersexceptme.

Syndicated 2009-06-17 01:33:20 from puzzling dot org: thoughts

linux.conf.au 2010 miniconf idea

I'm not taking on additional tasks for linux.conf.au 2010 (above co-chairing the presentation selection committee with Michael Davies) and so won't run with this, but an idea for someone with more time on their hands: a FOSSCoach miniconf or co-located event. I'm not sure whether you can call it FOSSCoach precisely (or would want to, I dislike the FOSS acronym), but the idea is an event teaching people how to work on Free Software projects. It could possibly be extended into, say, editing Wikipedia. If anyone wants to do this, go for it.

The linux.conf.au 2010 call for miniconfs is out now and is open until July 17. linux.conf.au 2010 will be held from 18–23 January 2010 in Wellington, New Zealand.

Syndicated 2009-06-16 03:02:11 from puzzling dot org: thoughts

The meaning of the word 'healthy'

I'm not opposed to words having multiple meanings or even skipping around and settling on whole new meanings. As a matter of selfishness, I support polysemy, because my research field is lexical semantics. The more ambiguity, the better, say the ranks of computational linguists needing employment. And language change should be as fast as possible. No, faster.

Nevertheless, after a heated discussion around Health At Any Size/fat acceptance issues (see Don’t You Realize Fat Is Unhealthy? for one statement of what is up with that, note that I'm less competent to argue the merits than Kate Harding, or, possibly, you dear reader, so do your own research) I noticed one ambiguity that got in the way: the word 'healthy'.

Here's one definition: a person who is healthy does not have disease.

Here's another definition: a person who is healthy is doing things correlated (or thought to be) with not having disease, or at least not developing further disease very rapidly.

And people slide around between these all the time, both as a matter of deliberate rhetorical strategy and as a matter of sloppiness. And there is thus some genuine confusion in which people almost slide right along from I work out three times a week to I will never die, or, actually, now that you mention it, age. Pretty much no one is completely healthy under either definition of the word, but best efforts under the second do not automatically make you healthy under the first (or vice versa). Nothing will. There is no magic bullet. As someone pointed out to me in an, alas, unquotable location, life, in fact, is something of an anti-magic bullet, in that the greatest risk factor for many diseases is age.

I think the biggest place this confusion happens is people saying I am so much healthier when they mean either I am so much fitter or I weigh so much less. Which becomes a problem when they actually think they mean I have less diseases now. Only possibly.

Syndicated 2009-05-15 00:47:25 from puzzling dot org: thoughts

Suppressing Python 2.6 DeprecationWarning

Since Python 3.0+ is backwards incompatible (or, if you like, a new Python-esque language), Python 2.6 is enormously grouchy about announcing that everything under the sun has been deprecated. For example:

$ python
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import md5
__main__:1: DeprecationWarning: the md5 module is deprecated; use hashlib instead
>>> 

While this is very helpful for one's own code, my email is now filling with warnings about how Twisted, Venus and several other libraries have deprecated elements (import md5 being a particularly common offender). There's nothing I can do about that, and being warned hourly about some of them is therefore unhelpful. Here's how you turn it off: call python with -Wignore::DeprecationWarning.

$ python -Wignore::DeprecationWarning
Python 2.6.2 (release26-maint, Apr 19 2009, 01:56:41) 
[GCC 4.3.3] on linux2
Type "help", "copyright", "credits" or "license" for more information.
>>> import md5
>>> 

As you can probably guess, by doing this you run the risk of your code failing to work with some future version of Python and you not getting much warning about it. But your inbox or error logs may thank you.

Syndicated 2009-05-03 10:20:32 (Updated 2009-05-04 00:08:32) from puzzling dot org: thoughts