Dirty Tricks of Presentors

A reader writes "Perl expert Mark Jason Dominus gave a great talk last month in St. Louis on how to give a good conference presentation. There's nothing specific to Perl, and a lot of people said they thought it was the most useful talk at the conference even though they didn't think they'd be doing a conference presenation any time soon. Mark also wrote up some notes that explain the parts he forgot to put on the slides."

This is useful too.

[User 956]

I've always found this site to be useful when preparing presentations. http://www.tomw.net.au/2000/pt.html. It's basically a troubleshooting/tip guide for those preparting a presentation using digital media and/or overhead transparency media.

Cached talks page.

[Christopher Thomas]

If you've already gotten coffe and made a sandwich and the slides still haven't loaded, here's something to keep you occupied in the meantime:

Google cache of a list of talks the same authour has done [google.ca]

Turn off images before loading this page, as they're taken from the same server that we melted down with slides requests.

Too bad Google Cache links don't work

[Skreech]

But this [google.ca] is a link to a search page, which you may then click on "cached" to get some desired output. Better than nothing... but turning images off is still recommended.

Interesting!

[Megumi_Slashbot]

On the subject of conference presentations, I was browsing the University of Kent [ukc.ac.uk]'s website when I found this [ukc.ac.uk] excellent article in their Psychology section, entitled the Do's and Don'ts for Conference Presentors.
This might be of interest to the other slashdotters, because though it's a 1998 article, it deal with the psychological impact of Conference presentations, which do not change with year-to-year revisions of the Powerpoint series and the like.
/quit
Megumi

Re:Now THAT is Ironic

[Fastolfe]

To be fair, while I've never been in one of his tutorial sessions, I've found mjd to be a very bright guy and a very entertaining speaker. His presentations at YAPC were heavily attended, and I found them interesting and easy to follow, especially this one.

Would you rather he not have spoken up before the tutorial began, in this case? Let people throw their $800 away without knowing that they already know the material until it's far too late?

Re:Now THAT is Ironic

[mjd]

Before it starts he says "How many people have taken $OTHER_TUTORIAL_NAME I gave last year?" .... to those who raise their hands he says "Well, you should go find something else to do, because $THIS_TUTORIAL is the same as $OTHER_TUTORIAL, only the name has changed"

I'm really sorry you were inconvenienced. The tutorial description that I sent to O'Reilly in my proposal stated very clearly (and I quote):

Caution; This tutorial is substantially the same as last year's "Advanced Programming Techniques" class. People who took that class last year whould not take this one.

However, the O'Reilly folks, for whatever reason, omitted this from the brochure. I was not sent the brochure for proofreading or correction beforehand. I did send them mail on April 18 to ask them to add the warning back to the description on the web site. I believe this was the first day that the brochure was available online.

I will cheerfully own up to many faults, including that of being a condescending, obnoxious elitist asshole. But this particular problem really wasn't my fault. I understand how annoying it must have been to have to switch classes, but I don't think there was any way I could have handled this better.

Again, I'm sorry you were inconvenienced. If there was something I could have done differently that I haven't thought of, I hope you'll send me email to tell me what it could have been.

Best regards,

Mark Dominus

Re:God what a crappy presentation

[mjd]

Second, put all of your fucking points on a slide - don't make me click through 5 fucking html pages just so that I can read the contents of one pathetic slide.

Hi. You may not be clear on the idea of a conference presentation. In a conference presentation, a speaker, such as me, stands in front of the audience and shows the slides to everyone at once while explaining the content in detail and answering occasional questions.

These are slides from a conference presentation, which means that the speaker (that's me, remember) would be doing the clicking. The audience members (that's you) typically do not click the 5 fucking HTML pages. So the number of clicks is not normally a matter of concern for the audience.

I hope this clears up your misunderstanding.

According to the slide notes, there are 43 slides in that presentation, which I presume took 45 minutes. That means about 1 slide per minute - wow!

Actually it was a 22 minute talk. (Double wow!) Perhaps you might like to meditate on the difference between a complex technical talk (not this one) and a humorous nontechnical talk (this talk). Here's a hint: After I show the pictures of the happy baby or the unhappy Japanese lady, I don't need to leave them on the screen for five minutes for the audience to absorb the full import.

Hope this helps.

oh god, the "bullshit" slide is too much

[Preposterous Coward]

is that actually a picture of a bull caught while taking a dump? can you imagine that thing up on a 10-foot projection screen? aaargh, shades of goatse.cx...

actually I am laughing so hard at the fact that he actually had the balls to include a slide like that...

Re:OT: Slashdotting your content providers

[twoshortplanks]

I've done lots of tests with lots of different servers. IIRC, for a simple webpage without graphics (about 30Kish) I could get 300 so requests a second with thttpd (at which point you do start to max out your 10Mb network card.) This of course is static files. I think this was served on a PIII 600Mhz (it was a wile back.)

As you point out, simultaneous requests is a problem - especially if your users start to run out of bandwidth. However, a well hardened server should be able to cope with a mild slashdotting wihtout too much effort.

Anyway, as I was pointing out above, you really need notice to be able to do this kind of thing. My really interesting content can probably be summerised in a static page (that thttpd can serve efficently) if given notice (though we'll lose some of the niceness, it's an acceptable sacrifice so that we can handle the load of people trying to view it.) But without that notice I'm not going to be able to do that and everyone will lose.

It's just a thought

Re:OT: Slashdotting your content providers

[SuiteSisterMary]

How you set up a webserver depends very much on the expected audience.

Of course.

You can only produce so much dynamic content per second, so how much dynamic content you create (assuming you're creating as much as possible to enrich the visiting user's experience) depends on how much traffic you're expecting.

Thank you for answering your own question. Let me postulate.

Let us assume, for the sake of argument, that your server can quite happily do five of these things at once. It's breaking a sweat, but it's a good, happy, 'in the zone' sort of sweat. Let us also assume that the demo will run for two minutes.

Also note that this is the 'difficult' way; the 'cheap hack' way would be to check system load at the beginning of the demo, and display a static 'try again later!' page if system load is too high to run the thingy without repercussions.

At the beginning of your app, you check a variable, you run through an array you populate later, checking to see if any timestamp is more than five minutes ago. If so, you clean that entry of the array out, and shift everything up; it's somebody who timed out, or quit halfway through, or something. You also decrement, for each array element you empty out, your 'current number of people watching' variable.

If, after going through the array, your number-of-people-watching variable is less than 4, you increment it, put a timestamp into the above-mentioned array, and proceed to run the demo. At the end of the demo, you remove the timestamp (this can be made easier if you have a two-column array, and also throw in a little unique identifier, which the demo stores in a 'local' variable while it's running), decrement the number-of-people-watching variable, and off you go.

This way, and assuming your webserver itself is set up to handle things properly, the worst thing a slashdoting could ever do to you is chew up your bandwidth. But your application itself will never ever exceed it's own safe running limits.