Slashdot Mirror
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."
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.
The theory of relativity doesn't work right in Arkansas.
..don't bar your fans from coming to your presentation.
Right Apple?
now if only that server wasn't slashdotted ;)
that if you prepare your presentation to rely on some technology, then said technology will find some way to stop working just long enough to ruin you presentation. Mind you hot stage lights can also be damaging... ("Developers!Developers!Developers!...")
If you can do a technical presentation without fancy do-dads and nothing more than your articulate descriptions and perhaps a white board, then you will be able to engage your audience much more effectively. they will listen, rather than watch...
It's effective communication that makes a good presentation, not what media was used.
"The large print giveth, and the small print taketh away" -Tom Waits
Examples: "Dirty Tricks of Presentors"
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
Turn off images before loading this page, as they're taken from the same server that we melted down with slides requests.
Haha.. Kind of reminds me of Jim Blinn's Things I Hope Not to See or Hear at SIGGRAPH. Read it for a chuckle..
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"
Never mind that by the time these people get back to registration, find another tutorial they want to see, exchange their materials, and get to the new tutorial, they'll have missed a good chunk of the "replacement" tutorial which they paid good money for. Nevermind those folks who don't want to do some-other-tutorial, so now they're completely out the money and have to try and fight the conference organizer to get their money back.
Dominus is the last person who should be giving pointers on presenting. He's the only person on my list of presenters for whom "Hell will freeze over, Satan will ice-skate to work, before I go see him speak".
This has been covered in the main FAQ and on several other occasions, but I'll recap and expand on your points.
First of all, if ANY single host starts slamming my site with HTTP requests, I'll instantly assume that its a DOS attack. This means I'll either block that address, or I'll shut down completely until the "attack" passes. What would the results of this "test" be from the point of view of the one doing the testing. Granted, if you're testing CNN, you'll probably never notice. But if you're testing some small site, they might pay more attention.
Mirroring the site in advance creates a potential legal grey area. If permission to mirror is required, and legally it is unless the author provies a GNU type license for the material, then the author would need to be contacted in advance, a process that can take hours easily. Who wants to wait 6 hours when you can link NOW?
Google caches are only available for those sites that have been around for more than a couple months, and even then the content is probably out of date. If slashdot is linking to something that's been around for a while, this isn't a problem, but if they're linking to something that's happened hours or minutes ago (which 90% of the slashdot headlines refer to), then google won't help much. And google won't cache the images, they still hit the original site, and typically 90% or more of the data from a site is graphics anyways. There are plenty of karma whores who will copy/paste the text part of articles/pages, and submitters will include google links on the occasions that they're available.
And the best solution to the slashdot effect is for the website administrators to configure the webserver properly. Bandwidth is only part of the problem. The other problem is caused by servers locking up due to excessive resource allocation. Once a server starts thrashing, all hope is lost, the server will be receiving requests faster than it can respond to them.
-Restil
Play with my webcams and lights here
On the subject of conference presentations, I was browsing the University of Kent's website when I found this excellent article in their Psychology section, entitled the Do's and Don'ts for Conference Presentors.
/quit
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.
Megumi
:)
Peter Norvig on the benefits of the Microsoft Powerpoint Autocontent Wizard.
and lots of em too.
sheesh, for a room full of frustrated geeks you'd think this would've been obvious.
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.
I could have wanted more "physical appearence" tricks, but it seems to deal mostly with putting slides together. If you are making presentations often, you (hopefully) are aware of how you react in such situations, but if you, like me, give perhaps one presentation every third year you might find these few tricks handy. I know they work for me.
As I said in my comment, the live demos were cool and more useful than static ones. What do you suggest I do? Always remove useful stuff like this just incase the entire of slashdot pops by uninvited?
-- Sorry, I can't think of anything funny to say here.
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
-- Sorry, I can't think of anything funny to say here.
Of course.
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.
Vintage computer games and RPG books available. Email me if you're interested.