Apollo 11 Lunar Landing Visualization, 1969 (2011) from Yanni Loukissas on Vimeo.

MIT Laboratory for Automation, Robotics, and Society
Directed by David Mindell

Visualization Design: Yanni Loukissas
Research Assistant: Francisco Alonso

The Apollo 11 visualization draws together social and technical data from the 1969 moon landing in a dynamic 2D graphic. The horizontal axis is an interactive timeline. The vertical axis is divided into several sections, each corresponding to a data […] Specific events are labeled, such as computer program changes and program alarms. During a real-time playback, the white line moves across the horizontal axis as audio plays, and the crew’s specific utterances are spelled out to the right. In sync with the human dialog, the AGC and DSKY display values and modes. In these dynamics, one can trace the trading of workload and authority during the critical final phases of landing, and how that workload was offloaded from the LEM to Houston in response to the program alarms.

I recently attended YAPC::Europe 2010 (and helped a bit organizing it), and I’d like to share some advices I was thinking on, for those speakers who will present at technical conferences in the future. These advices are mostly about how to prepare your slides, with something on how to deliver your presentation. There’s plenty of stuff available on the net about this topic, but I feel like stressing some points.

1. When you decide your colour palette, don’t consider its impact only on your own display. As a matter of fact, I think this should be the last of your concerns. Your slides will be projected with a beamer, or reproduced on a big monitor: they could both spoil the colours you spent lots of hours on.
2. If you can’t make up your mind about the colours, keep it simple: black text on white background is very likely to perform well on every situation.
3. Enlarge the font-size.
4. Again.
5. Ask the conference staff to check your equipment, and verify the impact of your chosen colour scheme. Check it also from the rear rows, if you think the room will be crowded. Check nevertheless: there could be people entering the room late, staying behind to avoid disturbing the other attendees.
6. Use the right tool to make your slides: if, after the check, you think your choices (colours, font size, etc) were not that sound, you should be able to change them rapidly. Styles are great.
7. If you think you are going to give a live demo, think twice. If you’re still convinced, you have to plan carefully also this part. First advice: the 190×100 terminal window that’s so practical for your daily job will be almost unreadable for the audience. Even more with the usual black background many hackers seem to favour. And a total failure if the organizers will record your talk. I suggest keeping a terminal setting designed specifically for demo delivery: 80×25, big font, high contrast, possibly white background.
8. You’re surely familiar with what I call the “demo effect”: something you rehearsed so carefully at home, will miserably fail during the real thing. Especially if you want to write code on stage to demonstrate a technique or a library. A nice trick I saw to avoid this problem is based on version control (dakkar++). Write the code in advance, keep it in your favourite version control system, and tag the relevant steps of the development. During your talk, checkout those tagged revisions while you proceed with the explanation: doing so, you can still show the audience how the mini-project is evolving, but you won’t need to write any code “live” (with a considerable probability of messing it up). Also, you can go back and forth if someone ask to clarify some point.

Causa peripezie varie della configurazione di questo spazio web, sono saltati i post automatici da del.icio.us.

Ora che ho un po’ di tempo per rivedere il materiale registrato su del.icio.us, però, segnalo a mano un paio di pezzi che a me son piaciuti molto:

• Programmer as a writer. Do it right the first time (note di Ehud Lamm) Gli appunti di Lamm sul discorso tenuto da Neal Stephenson all’apertura di USENIX 2003. Stephenson è uno scrittore (per combinazione, ho comprato Cryptonomicon proprio in questi giorni), ma ha qualcosa da dire anche su come i programmatori dovrebbero scrivere i programmi.
• 36 steps to success as technical lead Da un po’ di mesi mi trovo anche io in questa sorta di limbo professionale, che spiego di solito così: “Se qualcosa funziona è perchè l’ho fatto fare a qualcun altro. Se qualcosa non funziona, è colpa mia”. Ogni occasione per imparare qualcosa di nuovo, o per mettere meglio a fuoco un’impressione, è oro.