Become a fan of Slashdot on Facebook

 


Forgot your password?
Close
typodupeerror
×
News

Dirty Tricks of Presentors 92

Posted by Hemos from the well-done-good-sir dept.
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 discussion has been archived. No new comments can be posted.

Dirty Tricks of Presentors More

Dirty Tricks of Presentors

Comments Filter:
  • So are you saying there is more to it than woo'ing audiences with flashy PowerPoint(tm) shows?

  • I for one, was disappointed. (Score:2, Funny)

    by Anonymous Coward
    I thought the talk would be on underwater treasures. Needless to say, with the scuba gear I was wearing and the oxygen tank, I stood out from the rest of the crowd.

    I did get quite a few offers from the ladies to examine their bearded clams though.

    Cowabunga.

  • Powerpoint with 4 bullets per slide! ... and start off with a joke

  • This is useful too. (Score:4, Informative)

    by User 956 ( 568564 ) on Sunday July 07, 2002 @04:01PM (#3837747) Homepage

    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.

  • Rule #1.. (Score:4, Funny)

    by Anonymous Coward on Sunday July 07, 2002 @04:08PM (#3837773)
    ..don't bar your fans from coming to your presentation.

    Right Apple?

  • the best advice I ever recieved was... (Score:5, Insightful)

    by idfrsr ( 560314 ) on Sunday July 07, 2002 @04:10PM (#3837784)
    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.
    • I can confirm the parent postrs advice.

      Last year, I gave a lil' presentation on game development, prepared some funky lil' demos and so on. I arrived to the presentation on time, plug my laptop into the projector, and what happens? X decides to crash on start up.

      Reboot, make a few changes to the config, and try again. Second crash. To make things worse, the crash happened during a sync, causing the X config to completed fuck itself up :/

      No laptop for rest of presentation, which isn't a good thing when the presentation is on graphics-related stuff.

  • First Tip (Score:2, Funny)

    by jonman_d ( 465049 )
    First tip on giving a good presentation:

    Don't have the server with your presentation materials linked on slashdot, for it will not last five minutes into the conference.

  • huh (Score:1, Offtopic)

    by cascino ( 454769 )
    Google.com Search
    Web | Images | Groups | Directory
    Searched the web for Dirty Tricks of Presentors. Results 1 - 2 of 2. Search took 0.57 seconds.

    Did you mean: Dirty Tricks of Presenters
  • Intended as helpful content from a slightly annoyed reader- Could the Slashdot crew work up some solution to prevent linking to easily slash-dotted servers? A couple of ideas:

    1. Load test the link using a little utility to generate a lot of requests on the link. Pre-slashdotting them to some extent to determine their robustness. If they are susceptible, see item #2.
    2. Add a function to Slashdot to mirror the site about to be slashdotted while the story is active and link to the original as well as the mirror.
    3. At least add a link to the Google/whoever cache if a site is smaller or susceptible to being crushed by slashdot traffic. Be merciful.

    Since the forum usually provides the Google cache or mirroring functionality themselves, I think it would be prudent to make these improvements to Slashdot/Slashcode. Volunteers?

    • RTF'n FAQ

      You've been a member as long as I have, so you have no excuse.
    • 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
      • And the best solution to the slashdot effect is for the website administrators to configure the webserver properly.

        This of course is an option, but only if they are given warning. For example, Slashdot once linked to something running on my server that created dynamic Flash movies with Perl. Now, this is a slow process (it's a slow process in any language - it involves lots of bit packing) and takes up a lot of resources. There simply is no way to speed it up[1].

        Now as this was intended for a small audience we had live demos on the site - type some text in and it would be turned into a twirly text that rotates in a Flash movie. Cool! And fine if five or so people try it at the same time. When all of slashdot try it...well, our server went up to a load of 45.

        Now had we been given notice I might have yanked the live demo and changed it for something else - for example creating spinning text periodically from the slashdot RSS feed. This way I could have served static files (which we had the bandwidth for) and everyone would have been happy. But, alas, we didn't get the notice.

        It would be really nice if Slashdot did give webmasters of small sites who showing non time sensative material a couple of days notice to harden their servers.

        [1] well, there are ways to speed it up, but that's a work in progress.

        • This of course is an option, but only if they are given warning.

          They can't configure their webserver properly from the get-go? That's like saying 'Sure, they could wear seatbelts, but only if they're warned that they're about to slam into a concrete wall.'

          • They can't configure their webservr properly from the get-go?
            What is this "properly" you talk of? How you set up a webserver depends very much on the expected audience. 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.

            That's like saying 'Sure, they could wear seatbelts, but only if they're warned that they're about to slam into a concrete wall.'
            No. It's more like driving around in a convertable and someone chucking a bucket of water over the car. Sure, this wouldn't really be a problem if you'd had time to put the hood up, but since it was sunny you were trying to enjoy the sunshine.

            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?

            • 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.

              • Thank you for answering your own question. Let me postulate.
                Ooops, my aplogies if I misinterpreted your response. And feel free to postulate away, this is Slashdot after all..;-) Thanks for the big old post, most useful.

                Anyway, okay, you've got me. This is actually a sensible thing to do, and it's what I should have done in the first place. Bad me. (well, actually it's what the person who set up the demo should have done, but anyway...)

                However, this is all pretty non trivial stuff to implement. Plenty of race conditions with multiple Apache children trying to update the same file here! Hmm, I suspect there's a Perl (and probably C) module for getting around this very problem however...hmm mod_throttle and mod_bandwidth sound like a good idea. More concrete suggestions gratefully received.

                I still stand by my original statement however - it'd be nice if you got some warning before slashdot popped by. I'm more than happy to go to the extent of implementing lock files which monitor what's being consumed. However, I'm a busy person (arn't we all) and half the things I put up on the web (which are intended for a small audience, e.g. a demo of something that we're currntly working on) would never get up there if I had to panic about the whole of slashdot running it.

                • Aye, there's all sorts of ways to do it. My example was based on the idea of an 'application server' such as ASP, Tango, ColdFusion, whatever. There'd be differences with perl/CGI apps, but again, at that point, run an 'uptime' system command, and check the appropriate load number. If it's less than a happy threshold, go nuts.

                  Hell, bugger updating a file. Make a subdir in your temp directory, and drop in a zero-length file, instead of incrementing a variable. Check the file dates, instead of going through an array of timestamps. And so on.

                  Yes, it would be nice to be warned, but you build your bridge to hold tanks, even if it's only supposed to carry bicycle traffic. :-)

                  However, I'm a busy person (arn't we all) and half the things I put up on the web (which are intended for a small audience, e.g. a demo of something that we're currntly working on) would never get up there if I had to panic about the whole of slashdot running it.

                  Then, and pardon my flippancy here, they shouldn't be public. :-)

                  • Then, and pardon my flippancy here, they shouldn't be public. :-)
                    That's hard to do if you're discussing them on a public mailing list for example...

                    Well I supose I could always check the referer and block anyone coming in from slashdot from the really heavy stuff (of course this only works one click down, or with cookies...it's getting complicated again, isn't it ;-)).

                    Aside: forking to uptime probably a bad idea...I suspect GTop.pm (or whatever your system can) might be a less resource hungry resource checker...

                    • Aside: forking to uptime probably a bad idea...I suspect GTop.pm (or whatever your system can) might be a less resource hungry resource checker....

                      Aye, there's all sorts of ways to do it, it all depends on your environment, language, blah blah blah. Point being, it's an easy and off-the-cuff way to determine if you SHOULD run whatever. :-)

      • First of all, if ANY single host starts slamming my site with HTTP requests, I'll instantly assume that its a DOS attack.

        But that doesn't help with a /.ing. Many hosts making a few requests is the cause of the site bogging down.

        I don't think proper configuration is enough to withstand ~10000 simultaneous requests. While using a throttling http server like thttpd may help, I doubt even that is enough.
        • 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

  • Tip Number 1 (Score:5, Funny)

    by ziriyab ( 549710 ) on Sunday July 07, 2002 @04:28PM (#3837851)
    Don't have typos in your title

    Examples: "Dirty Tricks of Presentors"

    • It should be "Dirty Tricks of Pretenders".

    • Re:Tip Number 1 (Score:4, Funny)

      by Lac ( 135355 ) on Sunday July 07, 2002 @04:56PM (#3837952)

      Don't have typos in your title

      Would it be appropriate to point out that it only qualifies as a typo if he actually knows how to spell it?

  • find google caches by searching for:
    conference presentation judo

  • Cached talks page. (Score:4, Informative)

    by Christopher Thomas ( 11717 ) on Sunday July 07, 2002 @04:41PM (#3837889)
    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.

  • Reminds me of Jim Blinn (Score:5, Funny)

    by Stiletto ( 12066 ) on Sunday July 07, 2002 @04:43PM (#3837897)
    Haha.. Kind of reminds me of Jim Blinn's Things I Hope Not to See or Hear at SIGGRAPH [siggraph.org]. Read it for a chuckle..

  • Now THAT is Ironic (Score:3, Interesting)

    by Anonymous Coward on Sunday July 07, 2002 @05:22PM (#3838041)
    I was at OSCON last summer, when Dominus was giving a talk, one of the 1/2-day tutorials that are like $800.00 a pop...

    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".

    • Re:Now THAT is Ironic (Score:2, Informative)

      by Fastolfe ( 1470 )
      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?
      • I'd say that a sentence in the program "This talk was previously given as old_title" would probably have satisfied all parties. I was actually sitting in that session as I was tutorial-hopping, and was amazed that MJD hadn't thought enough of the attendee to document that fact BEFORE the attendee had coughed up the money.

        I have no doubt MJD is bright, but his attitude, from my experience reviewing different talks, seems to be very condescending, and his lack of any real care for the effects of his "tutorial rename" on its attendees was a pretty good demonstration of that to me.

    • Re:Now THAT is Ironic (Score:5, Informative)

      by mjd ( 12596 ) on Monday July 08, 2002 @12:53AM (#3839790) Homepage

      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
      • This probably ought to be modded up.
      • 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.

        In deferrence to my response elsewhere in the thread... you can obviously see where said attitude might have led someone to believe that you simply hadn't cared that the "name switch" might have caused problems.

        I'm glad to see it WASN'T your fault, though... (well, not really, you make a much better villain than ORA *grin*).

  • If you need to goto the bathroom, remember to turn off your microphone that is attached to you.

    Remember the scene from The Naked Gun :D

    • I played pit orchestra for a musical... during one of the rehersals a lead forgot to turn her microphone off when she went to the bathroom.

      Imagine her surprise when we all crack up when she comes back on stage... :-D
  • Look at the dialation of those guys pupils in the picture at the top! If that isn't gimped [preferable modification to the generic term photoshopped] than he was on enough LSD to to supply a minor rainbow gathering!

  • I have yet to look at his latest slides (i'll give his server a chance to recover), but I've been in at least tutorials Mark has taught at the Perl Conferences. All were excellent - Mark is always very prepared and knows more about the subject than anyone could ask. Also, and most important to someone of my perl ability (not very good), he usually makes the slides available after the class (via his server). This gives me the chance to look them over and help my brain catch up to everyone else...

  • Interesting! (Score:3, Informative)

    by Megumi_Slashbot ( 585223 ) on Sunday July 07, 2002 @05:57PM (#3838140) Homepage Journal
    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
  • I always liked this doc telling the story of Demoing for Fun and Profit. [userland.com]
  • At what point in a presentation should you realize you have nothing intersting to say, and just start playing video games on stage?
  • called "How to get people to buy your book for $50"
  • that's right, I want Presentation Babes.
    and lots of em too.

    sheesh, for a room full of frustrated geeks you'd think this would've been obvious.

  • If you want to improve your presentation skills, join your local toastmasters club [toastmasters.org]. It's one of the best and cheapest way to learn how to speak in public and/or give public presentations.
  • Boobs, curvy surfaces, if you do it right, you might induce some bump-mapping if you get my drift

  • God what a crappy presentation (Score:1, Interesting)

    by Anonymous Coward
    Jeez, first off, that presentation SUCKS. Second, put the fucking presentation somewhere so that you can download the freaking html so that I could have barfed all over it while reading it in real-time, rather than having to wait 5 fucking minutes before each fucking slide would load. Learn how to use squid as a reverse proxy, for god's sakes - it will save your ass from a slashdotting, especially for such a trivial amount of content to display.

    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.

    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! A good idea for real presentations: If you're doing 45 minutes, have NO MORE THAN 13 SLIDES. Rule of thumb: expect each slide to take about 5 minutes to talk to. Anything less than that and you're boring your audience, because you're (a) reading your slides instead of talking to the crowd, which is BORING, or (b) you're spending too much time at the podium clicking your fucking mouse. The more time you spend behind the podium, the choppier your presentation is, and more bored your audience gets. I'd prefer 10 slides for a 45 minute talk, because then you have some time for Q&A, but 13 is doable, because you go faster over your title slide, intro slide, and thank you slide.

    If this guy is winning "best presenter" awards, then I shudder at how low the standards have become.

    • Re:God what a crappy presentation (Score:5, Informative)

      by mjd ( 12596 ) on Monday July 08, 2002 @01:01AM (#3839815) Homepage

      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.

  • 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...

  • More tricks... (Score:3, Interesting)

    by bentriloquist ( 125570 ) on Monday July 08, 2002 @05:16AM (#3840430) Homepage
    I was finally able to read this after many tries. Lots a good points which I will try when the times comes.

    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.

    • Prepare! Prepare! Prepare!
    • Don't hide yourself behind a desk. Come out in the open where people can see you. This also solves the problem of presenters taking to the desk instead of the audience.
    • If you're nervous you might tend to do a lot of weight shifting from one leg to the other... don't. There's really no need to show the audience that you are almost pooping your pants. It helps if you make yourself aware that you are nervous. You could start off with a joke, make the audience laugh and make the tension less.
    • If you have to hold a piece of paper in your hands make sure you are not shaking. The shaking will really attract the audience's attention, drawing focus away from what you're saying. If the shaking is a problem for you, put the paper on a desk, look at it once in a while or memorize it.
    • Walk around. Too much = too nervous. Too little = just another piece of dead meat.
    • Don't say "eh..." or other pause words. There's no need to, because you followed my first advice!
  • Know thy audience.

    If you don't know what the audience wants to find out from you, you have very little hope and neither have they.

    I enjoyed this article - particularly the rubbishing of Tell them what you're going to tell them; then tell them; then tell them what you told them.

    This is the mantra they teach you on any presentation course, and yup, it's mostly rubbish. On the other hand, if you are presenting to a group of managers, it is probably valid enough...

Slashdot Top Deals

8 Catfish = 1 Octo-puss

Close