Some thoughts on making slides for technical presentations
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.
- 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.
- 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.
- Enlarge the font-size.
- Again.
- 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.
- 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.
- 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.
- 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.
Visualization tools
Via Guy Kawasaki’s Twitter feed, I just discovered an interesting video about “How visualization changes everything”. Among Alex Lundy’s slides there’s one on dataviz tools. I didn’t know most of them:
Here’s the video:
Seven facts about me
gmax challenged me to participate in this game. The rules:
- Link your original tagger(s), and list these rules on your blog.
- Share seven facts about yourself in the post – some random, some weird.
- Tag seven people at the end of your post by leaving their names and the links to their blogs.
- Let them know they’ve been tagged by leaving a comment on their blogs and/or Twitter.
And here some facts about me:
- I was blessed by the opportunity of writing an introductory book about Perl, published in Italy by Apogeo. I wrote most of it by night, in two continents and four countries (or during flights).
- I live in Barcelona since April 2008. I speak Italian and English, and I’m learning Spanish (now I can express things just to some extent). Other languages I’ve been exposed to are French and Portuguese.
- I work as a programmer, and that’s more or less what I’ve always done. I have some experience as a teacher, too.
- I’m left-handed.
- I studied classical guitar for quite a long time. Shame on me for not keeping study.
- I love to read. My reading pace and favourite genres vary a lot, but giving me a book is usually a simple way to make me happy.
- While everyone calls me Stefano (and larsen on the net, usually), my parents, my sister and my relatives call me Lorenzo. That’s due to some family facts it’s boring to explain here.
I don’t believe interrupting this kind of “memes” could cause damage, severe injury or death, therefore I won’t tag anyone specifically. Everyone among my followers in Twitter can consider himself tagged.
Il meglio dal mio feed del.icio.us (prima metà di Agosto)
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.
Maintenance programming
$ history|awk '{a[$2]++} END{for(i in a){printf "%5d\t%s \n",a[i],i}}'|sort -rn|head
215 cd
121 ls
97 vim
41 grep
4 find
3 vimdiff
3 touch
2 tail
2 perl
2 less
Things
In questi giorni sto usando parecchio Things, un’applicazione per Macintosh per il task management al momento in beta. Secondo me è molto indovinata, per un po’ di motivi:
- L’interfaccia è pensata bene, e benchè manchino ancora alcune cose comode, si raggiunge ogni cosa rapidamente.
- Gli attributi legati a ciascun task sono sufficienti per organizzare il lavoro tipico (almeno, a me non vanno stretti): si possono organizzare i task per progetto, task e progetti si possono a loro volta organizzare per area di responsabilità. Ad ogni task sono associabili dei tag, e l’interfaccia consente di usarli per scremare rapidamente la lista delle cose da fare. Il punto quando si usano programmi di questo genere è la concentrazione sul singolo punto, senza essere soverchiati da troppe informazioni, e al tempo stesso senza perdere la possibilità di passare rapidamente alla vista generale.
- In qualunque momento, e con il focus su qualunque altra applicazione, è possibile richiamare una finestra dalla quale aggiungere un task alla propria lista. È veloce, non è intrusivo, e si infila perfettamente nel flusso di lavoro di tutti i giorni, per il quale tipicamente si usano tanti programmi contemporaneamente. Bravi.
- I dati vengono memorizzati in formato XML. Oltre all’ovvio vantaggio di non perdere nulla se un domani si decide di cambiare programma, mi aspetto che questa caratteristica porti ad un proliferare di utility di terze parti per fare qualcosa di ancora più utile con i dati prodotti con questo software. Ad esempio sto pensando ad uno script che trasformi l’XML in una pagina web da mostrare ai propri colleghi e collaboratori: una pagina che dica “ho fatto questo, manca quest’altro”.
- Si integra con l’address book, e permette di memorizzare un task assegnandolo ad uno dei propri contatti. Non esiste una vera e propria funzionalità di comunicazione, ma è comunque utile per mantenere aggiornata la propria visione di “chi deve fare cosa”.
Tra le cose che mi piacerebbero per le future versioni, la possibilità di organizzare i task gerarchicamente (cosa fattibile tutto sommato con i progetti, ma fatta questa considerazione sono al punto di prima, e sento il desiderio di organizzare gerarchicamente i progetti).
IPW2008 – Idee per talk
Non so se quest’anno riuscirò ad essere presente all’Italian Perl Workshop, ma sto lo stesso pensando a quale (o quali) potrebbe essere l’argomento di una mia eventuale presentazione. Ecco le idee avute finora, e che ho già sottoposto al vaglio della mailing list:
- Movable Type Open Source (20 minuti)
Six Apart ha intrapreso il progetto di una versione opensource di Movable Type, basata sulla versione 4 di MT. Quali sono le novità della piattaforma, come contribuire, perchè (e perchè no).
- Tecniche di debugging (20-50 minuti)
Tutorial su tecniche e trucchi per il debugging in Perl. Come sfruttare a proprio vantaggio le feature più dinamiche di perl.
- “Non è mai troppo tardi” (20 minuti)
Adozione di best practice là dove prospera il lato oscuro. Come pagare il debito tecnologico senza l’aiuto di Bono Vox. Storia di un sopravvissuto.
- Marketing Perl (10-20 minuti)
Come può funzionare il marketing di Perl? Ha senso? Chi lo sta facendo? (con scampoli della versione 2008 di “Perl.it wants you!”)
Zero inbox?
I need to rationalize my inbox.
Nobody knows shoes
Ho pensato di provare Shoes, un toolkit per GUI scritto in Ruby da whytheluckystiff. Non che per le mie attività correnti ne abbia bisogno, ma la lettura del breve manuale è stata divertentissima, e per molti aspetti Shoes mi ricorda Hypercard, un programma che desideravo usare ai tempi in cui non avevo ancora un Macintosh.
1, 2, 3… prova
Installazione minimale di WordPress per cominciare a pubblicare qualcosa. Penso che più avanti migrerò a Movable Type, che conosco meglio e che considero superiore quanto a versatilità e maneggevolezza, ma ho voluto adottare da subito il tema Hemingway, che successivamente porterò a MT.
