Give a Great Tech Talk


Published on

Published in: Technology
  • Be the first to comment

No Downloads
Total views
On SlideShare
From Embeds
Number of Embeds
Embeds 0
No embeds

No notes for slide
  • (Josh looks around for Ian and starts the talk.)
  • (Josh reads awkwardly from the slide.)
  • (Ian rushes in late, apologizes, fumbles with notes, and reads awkwardly from the slide.)
  • (Ian rushes in late, apologizes, fumbles with notes, and awkwardly reads from the slide.)
  • Tutorials require a TOC. Few other kinds of talks do.
  • Example of managing audience expectiations for questions. SInce we have a tight schedule, push them to the end.
  • In exercise #1, we give one speaker a random topic card and a random audience card. They have to do a 60-second presentation about that topic.
  • Your topic needs to be something you know well and are excited about or your talk can't be great. Excitement is often more important than content.
  • When is your talk? TIme and day? What is it before/after? Is there a break? Will the audience be tired? And how long is it?
  • There are 4 basic timeslots. Scale your cotent to the timeslot you have; don't try to cover too much or too little for it.
  • Example fo same topic in 3 different timeslots with different scopes of coverage each.
  • You need to pace yourself to the time. Use a timer so you know how you are doing. There are many techologies available: Presenter screens on softtware Clicker remotes with timers iphone presentation control application
  • The biggest thing is to correctly target your audience with your talk. You have to know who they are and speak to them, not some generic audience.
  • Know whom you're talking to. If you haven't been to the conference before, try asking the organizers for demographic information. An audience of 22-year-old brazillian drupal developers is very different from an audience of 60-year-old midwestern professors.
  • Your audience is going to have expectations about what they will learn. You need to figure out those expectations and try to fullfill them. Otherwise they will be frustrated and hate you.
  • An example of giving the same core content to 3 different audiences. This is about a new query analysis tool for PostgreSQL. OSB is mostly web developers and younger hackers. They don't care so much about database internals or theory. They're more interested in making their apps work better.
  • pgCon is a bunch of database gear-heads who are already familiar with the problem and the existing tools. They want only technical details and a demo of the new tool and how it can be used.
  • SIGCSE is a bunch of computer science educators, many of them older. They expect a more academic presentation of topics. Note the passive voice in the title. And you need to relate your topic to education and theory, NOT to production environments.
  • Preparing for a talk is a multi-step process. It'll take you quite a bit of time; at least 5 hours for every hour presented, and ofter up to 12. We probably spent a combined 35 hours preparing this tutorial.
  • you start with freeform notes. These are our notes from Googledocs while we were designing this presentation. It gave us an idea of the points we wanted to cover and how to consolidate them.
  • Once you know what you are covering your presentation needs a “story” or a plot to string it together. Otherwise it can seem random and chaotic. There's really only 5 “stories” for technical presentations.
  • Once you have a story, you can write a script with timings for your presentation.
  • Timings are especially important if you're covering a lot of material. You need to break down the presentation by item to know if you are getting behind. Only then can you work on slides.
  • You can't possibly know if the presentation is going to work or not unless you rehearse. Run through it, at regular speed, out loud. Really! You'll discover major things which need to be changed that way. And test your timing.
  • For exercise #2 we take a 2 nd speaker and have them give a 60-second talk on a random topic to a random audience. Hopefully after the mental prepartion this is better than the last speaker.
  • In the next section we explore slideless presentations, starting with an audience exercise and then moving on to the options around slideless presentations, including: demos video whiteboards & easels audience exercises
  • I hope Josh has convinced you that you, not your slides, are the star of the show. That said, please treat yourself and your audience to good, readable slides.
  • It's fashionable for the presentation blogs to obsess over Steve Jobs's slides and technique. But you don't have to be Steve Jobs to use good slides.
  • Don't base your slides on short phrases just because Presentation Zen told you to. Instead, start by making each slide about just one thing. You'll find that your slides will drift to a simple style on their own.
  • [citation needed] Take note of any slides that contain a specific detail you need the audience to see (photo, chart, etc.). Later, when you're presenting, you'll take on a more subdued body language for those slides.
  • The easiest way to restrict yourself to a simple palette of slide types is to use your software's master slide feature. This is also the place to add a template for slides that contain code snippets.
  • Some conferences require you to use a specific, overly busy slide theme. Call the organizers and ask for an exception. Show them you've done your homework. You might even stealthily use your own, cleaner version for your actual talk (but don't alienate the organizers).
  • There's lots of readability research on dark vs. light backgrounds. But little of that has to do with showing code on a projector. You can make either of these work; anecdotally, light on dark is a little more legible.
  • When you're thinking about color visibility, you might take a page from the medieval playbook. Back then, heralds knew how to make sure contrast was visible 100 feet away. They used a set of rules based on “colors” and “metals”.
  • In this scheme, metals are gold (yellow) and silver (white). Everything else is a color. You can put a color on a metal or a metal on a color, but not a metal on a metal or a color on a color.
  • For a modern example of this phenomenon, see your local highway department. All the signs in this intersection are either metal on color, or color on metal.
  • We're not going to give you an ironclad “thou shalt not” point size. Start with master slides that go down to about 36 pt or so. If you find yourself needing to make the font smaller to fit more words, consider breaking the slide up.
  • You've all seen presentations which suck. You may have given them. While suckitude comes in a lot of flavors, I've found that there's 7 characteristics which all sucky presentations will have some or all of.
  • Step 1 is to hide behind the podium. Don't come out for anything! Especially don't walk out and interact with the audience. That podium or table protects you. Just sit behind it and read your notes.
  • Always have an about us slide. It's useful either as a way to bore the audience or as a form of boasting. Hint: if the audience doesn't know who you are before they walk in the room, they don't care. Also have picture. Since they may need to ID you to the police.
  • Even better is the corporate about us slide. The ideal version recounts the entire history of the company starting at Genisis. With this, you can waste enough time that you don't have to have any presentation content.
  • The third habit caters to a select portion of the audience at the expense of everyone else.
  • It's what I call “presenting for the blind”.
  • Read the slide verbatim in a monotone.
  • You can't be a really bad presenter without screwing up the slides themselves. The best way is this one.
  • DR. Bronner jams every square millimeter of his soap labels full of bizarre propaganda. You should treat your slides the same way! Leave no square inch of whitespace!
  • Here's a good example of way-the-heck too much text. It's full of acronyms and runs off the page. And what the hell is that picture?
  • You can also overcrowd your slides with other things. Five graphs on one page!
  • But to really exploit the too much crap theme, you need to use some architecture diagrams. No matter what they are designed to portray, arch diagrams always look like a plate of spaghetti from the back of the room.
  • More arch diagrams
  • More arch diagrams
  • More arch diagrams
  • You create expectations in the audience when you post your talk descritpion in the conference catalog. If what you present is very different from the description, then you will frustrate them and they will hate it. Even if it is otherwise a good presentation.
  • Covering only half the material you promised is one way to piss people off. Some of them will have attended your talk just to hear the stuff in the other half.
  • This is the one I see the most, and the best way to make yourself look like a tool. If you promise working code, you'd better have it … or don't get invited back to that conference.
  • See how you've pitched your talk: is it pitched to experts or beginners? If you provide the wrong level of information, people will either be disappointed or confused.
  • Like working code, if you promise in-depth hacking you;d better provide it. Otherwise you're a corporate drone. This is the trouble you'll be in if you present on something you don't know aboutl.
  • Oh, and glassfish is really cool. You should use it.
  • that was an example of grab-bag presenting, where your talk has a mish-mash of unrelated stuff which you threw in because you changed your mind, or want to please your coworkers.
  • One of the most common presentations mistakes is to lose track of time.
  • Your audience has a schedule to maintain, too. And if you only cover half the material in the time allotted, they won't forgive you. Even less if you make them late for lunch!
  • Panicking in front of the audience is a guarenteed way to lose them and their opinion of you. Stuff goes wrong while presenting. You need to keep your cool.
  • These 6 stages mark the descent into panic and loss of audience. If you find yourself apologizing a lot,you need to get a grip and move on.
  • Summary of the flavors of sucking.
  • Opposites of sucking; how not to screw up.
  • Keeping your cool is the biggest thing.
  • Just ask a professional actor.
  • Good presentations require audience interaction, not just slides.
  • Most basic audience interation is eye contact. Make fleeting eye contact with several members of the audience. Don't just look down. On the other hand, don't stare at one audience member all the time. You look like a stalker.
  • Now that you've gotten out from behind the podium, be aware of your body language. Use “open” body language, not “closed”. Check yourself for various bad habit body language: Covering genitals Flapping hands Hands in pockets Turning away from the audience
  • Make sure to ask the audience for responses. At least ask them about who they are and level of experience with topic. Then you can adjust your presentation as you go. A response near the beginning of the talk helps engage the audience.
  • Jokes are really vital to wake up the audience, especially after lunch But are the hardest thing … you have potential to derail the whole presentation if your joke is especially bad or offensive. Don't use a joke without “testing” it. Especially on someone of another gender/culture.
  • You can take questions any way you like, the audience just has to know what to expect. For UGs and workshops questions throughout preso work better. For formal presentations, especially with short time, questions at end tend to work better.
  • You'll always get some questions you can't answer. Don't BS. Say “I don't know that right now, let me get back to you after the presentation.”
  • You know this guy, or you will. He sits towards the front, asking questions, interrupting. Insisting on tangents. Remember that your presentation is for the whole audience, not just him. Ask him to save his questions for after the talk. If he won't, rudely ignore him.
  • This is a different kind of problem audience member. This is the person who could give your presentation better than you, knows more than you. Two things you can do: (1) pretend they're not there, (2) address questions to them – but not too much!
  • Of course, you've seen the audience participation exercises elsewhere in this talk. The imporant thing about audience participation is to scope it correctly; you can't let it derail your talk if it doesn't work well. Be ready to drop back to something else. Do NOT have open-ended solicitations. Always have a simple set of responses in mind, or a very carefully defined task.
  • You need to carefully consider which code snippets you're going to show on your slides.
  • This example is too much to absorb. It also uses a color theme that's good on screen, but hard to read on a projector. Green on white is particularly projector-unfriendly. The grey comment doesn't provide enough contrast.
  • Here's a small part of that slide, reformatted to fit the screen and skinned with a higher-contrast theme.
  • Wow, that's going to be a lot of work, isn't it?
  • If you naturally code in short lines, you won't have much to do. (Geoffrey Grosenbach tells the story of the crew, who use a coding standard that tops out at 40 characters per line!)
  • Here are a few reasonable defaults for the TextMate editor. Don't miss the Create HTML command, which hands syntax-highlighted code over to a browser window – so you don't lose your colors when you copy / paste.
  • For other editors, you can get a similar effect by running the Pygments syntax highlighter as an external program. We suggest setting up a keyboard shortcut for this.
  • Copy and paste are fine for a lightning talk. But if you've got dozens of code slides, you'll want to keep them in sync with your latest tested code. I have a Rube Goldberg contraption that may help with this process.
  • Actually, let's fire up that contraption right now.
  • In PragPub magazine, Andy Lester advises starting with the Big Three, unless your needs are really specialized. And he's right.
  • So, what do you do if your needs are really specialized? For instance, what if your talk is nearly all code and demos of text commands?
  • Scott Chacon has a nifty project called Showoff that's geared toward presenting code and shell sessions. It works by serving up a local web page, which you then view in a full-screen browser.
  • You're not going to be able to show all your code in your talk. There will always be more that your audience will want to see later. So don't forget to throw in a GitHub or Bitbucket link.
  • Demos always crash. In unpredictable, unrepeatable ways. No matter how much you prepare. You need to be mentally prepared for this.
  • Presentation Laptops fail in interesting ways. Software you're demoing develops new and novel bugs at the podium which you will never see before or again. And conference internet never ever works if you need it for your preso.
  • Demo only stuff you know well and can repeat reliably. Do not demo the latest new features just checked in the night before. Test your laptop, projector, etc. on the demo. Run the demo at least 10 times. Rewindable Virtual machines like VMWare, Vbox, Parallels allow you to restore your demo machine to “predemo” state. Even better, you can fake your demo … more later. Have an alternative demo in case one fails. And never do demos which depend on other demos working.
  • Thanks to advancing technology there are a lot of ways to fake your demos. First there's screenshots – mainly good if demo fails. Video is a better way to fake a demo, especially if demo depends in internet. For text-console demos, there are several techniques: Bash history Recording shell sessions using script or ttyrec and playing them back. Interactive “fake” shell programs like Perl's IO::Prompt.
  • Don't forget that there are lots more people who want to see your slides, but couldn't be there in the room with you. There are several things you can do for these folks.
  • Despite their name, speaker notes are not for the speaker.
  • You don't want your speaker notes to read like this. Just have a couple of sentences to give people an idea of what you said.
  • When you post your presentation, you can either include the speaker notes at the bottom of the page, or you can use your software's built-in audio recording ability.
  • Don't get analysis paralysis when you're deciding where to post your slides. Just stick with one of the most common options.
  • SlideShare is the granddaddy of presentation hosts. Two of its nicest features are audio sync (where you mark when the slides should advance) and embedded YouTube video (so home users can still see your demo).
  • You can also just export your whole show as a movie and upload it to YouTube. Google for one of the various tutorials on getting the screen resolution just right.
  • If you've already got a podcast, you might consider posting your talk as an enhanced podcast, which has the slide images and timings embedded in it. This is a little more work, but results in a small-ish file that works in both audio-only and audio+image settings.
  • Give a Great Tech Talk

    1. 2. Give a Great Tech Talk Josh Berkus Ian Dees
    2. 3. Table of Contents <ul><li>About Us </li><ul><ul><li>Software Developers
    3. 4. Experienced Speakers
    4. 5. Thought Leaders </li></ul></ul><li>How to Prepare For a Talk </li><ul><ul><li>Finding rehearsal space is important.
    5. 6. Hiring a Professional Designer to Make Sure Your Slides Are GREAT! </li></ul></ul><li>Giving a presentation </li><ul><ul><li>Effective Slide Reading
    6. 7. The Lectern is your Friend </li></ul></ul><li>After Your Talk </li><ul><ul><li>Monetizing Your Content
    7. 8. AdSense
    8. 9. Selling in the Kindle Store </li></ul></ul></ul>
    9. 10. About Us <ul><li>Josh </li><ul><li>Education </li><ul><li>Brentwood Elementary, Gainesville, FL
    10. 11. Claremont Colleges – Degree in Art! </li></ul><li>Projects </li><ul><li>Postgres, CivicDB, NoiseBridge </li></ul></ul></ul><ul><li>Ian </li><ul><li>Pets </li><ul><li>Cats </li><ul><li>Osiris
    11. 12. Black
    12. 13. Peanut
    13. 14. Harley </li></ul><li>Dogs </li><ul><li>Maybe one day! </li></ul></ul><li>Hobbies </li><ul><li>Lots, just ask! </li></ul></ul></ul>
    14. 15. About Us <ul><li>Josh </li><ul><li>Education </li><ul><li>Brentwood Elementary, Gainesville, FL
    15. 16. Claremont Colleges – Degree in Art! </li></ul><li>Projects </li><ul><li>Postgres, CivicDB, NoiseBridge </li></ul></ul></ul><ul><li>Ian </li><ul><li>Pets </li><ul><li>Cats </li><ul><li>Osiris
    16. 17. Black
    17. 18. Peanut
    18. 19. Harley </li></ul><li>Dogs </li><ul><li>Maybe one day! </li></ul></ul><li>Hobbies </li><ul><li>Lots, just ask! </li></ul></ul></ul>
    19. 20. Give a Great Tech Talk <ul><li>How to prepare for a talk
    20. 21. Nobody cares about your slides
    21. 22. … but make good ones anyway
    22. 23. Seven Habits of Ineffective Speakers
    23. 24. Audience Interaction 101
    24. 25. Curate your code examples
    25. 26. When the demo crashes
    26. 27. Audience outside the lecture hall </li></ul>
    27. 28. Q&A period at end <ul><li>We'll make sure to have time
    28. 29. Write down your questions
    29. 30. or put them on the wiki: </li><ul><li> /Give_a_Great_Tech_Talk </li></ul></ul>
    30. 31. 1. Preparing for Your Talk Speaker Exercise #1
    31. 32. Know Your Topic <ul><li>You know a lot about
    32. 33. Currently topical
    33. 34. You're enthusiastic about
    34. 35. You can cover in the time allotted </li></ul>
    35. 36. Know Your Timeslot
    36. 37. Basic Timeslots <ul><li>5 Minutes Lightning Talk </li><ul><li>one small topic very briefly </li></ul><li>45 Minutes Regular talk, no Q&A
    37. 38. 1 Hour Regular Talk with Q&A </li><ul><li>one major topic with some depth </li></ul><li>2-3 Hours Tutorial </li><ul><li>entire tool or technology </li></ul></ul>
    38. 39. Basic Timeslots <ul><li>5 Minutes Lightning Talk </li><ul><li>“5 CSS Tags You Didn't Know” </li></ul><li>45 Minutes Regular talk, no Q&A
    39. 40. 1 Hour Regular Talk with Q&A </li><ul><li>“Simple CSS Techniques to Improve Your Site” </li></ul><li>2-3 Hours Tutorial </li><ul><li>“Introduction to CSS-based Web Design” </li></ul></ul>
    40. 41. Use a timer!
    41. 42. Know Your Audience
    42. 43. Who Are They? <ul><li>Professions?
    43. 44. Ages?
    44. 45. Culture?
    45. 46. From where?
    46. 47. Groups? </li></ul>
    47. 48. What do they want? <ul><li>Why are they at the conference?
    48. 49. What is their interest in your topic?
    49. 50. How much do they know already?
    50. 51. What style/format do they expect?
    51. 52. Do they have things in common you can refer to? </li></ul>
    52. 53. OpenSourceBridge “ Analyze query plans to find the “go faster” button”
    53. 54. pgCon “ Find chronic performance issues in your discarded query plans”
    54. 55. SIGCSE “ Discarded plan analysis as a method for teaching query optimization”
    55. 56. 8 Steps for Talk Preparation <ul><li>Create some notes
    56. 57. Come up with a story
    57. 58. Write a script
    58. 59. Work out timings
    59. 60. Create slides
    60. 61. Rehease
    61. 62. Revise
    62. 63. Rehearse again </li></ul>
    63. 65. 5 Basic Stories for Talks <ul><li>From Ignorance to Knowledge
    64. 66. Quest / Solving a Problem
    65. 67. Top-to-Bottom or Bottom-to-Top
    66. 68. Theme & Variations
    67. 69. The Catalog </li></ul>
    68. 72. Rehearse! <ul><li>Do a run-through of the entire presentation </li><ul><li>out loud, standing up </li></ul><li>You'll figure out the timings
    69. 73. You'll discover things which need to be changed
    70. 74. Video helps! </li></ul>
    71. 75. Speaker Exercise #2
    72. 76. 2. Nobody Cares About Your Slides
    73. 77. 3. But Make Good Ones Anyway
    74. 78. You Don't Have To Be Me
    75. 79. One Idea, One Slide
    76. 80. When You Stand, They See Slides When You Move, They See You
    77. 81. On Themes
    78. 82. Do I Have To Use Their Theme?
    79. 83. Light on Dark, or Dark on Light?
    80. 84. Heraldry
    81. 85. Metal vs. Color <ul><li>Metals </li><ul><li>Yellow
    82. 86. White </li></ul></ul><ul><li>Colors </li><ul><li>Black
    83. 87. Blue
    84. 88. Red
    85. 89. Green
    86. 90. Purple
    87. 91. Brown </li></ul></ul>
    88. 93. Point Size Is Your Barometer
    89. 94. 4. The 7 Habits of Highly Ineffective Speakers
    90. 95. 1. Chained To Your Chair (or Podium)
    91. 96. 2. About Me <ul><li>Education </li><ul><li>Brentwood Elementary School, Gainesville Florida
    92. 97. Claremont Colleges – Degree in Art! </li></ul><li>Projects </li><ul><li>PostgreSQL database project
    93. 98. CivicDB
    94. 99. Noisebridge
    95. 100. pgReplay </li></ul></ul><ul><li>Accomplishments </li><ul><li>Founded first company at age of 28
    96. 101. Once shook hands with Esther Dyson
    97. 102. Predicted the dot-com crash
    98. 103. Nobel Prize for Peace for ending vi/emacs flamewar </li></ul></ul>
    99. 104. About Us
    100. 106. 3. Presenting For The Blind
    101. 107. Presenting for the Blind <ul><li>Presenting for the Blind is where you read every line of every slide.
    102. 108. It is extremely boring.
    103. 109. It also gives the audience the impression that you either think that they're illiterate, or that you've never seen these slides before. </li><ul><li>Maybe you haven't. </li></ul><li>You can also read your notes directly off the page.
    104. 110. A monotone is recommended. </li></ul>
    105. 111. 4. Dr. Bronner's School of Slide Design
    106. 119. 5. Bait & Switch
    107. 120. 7 points in description vs. 3 points covered
    108. 121. Working Code & Demo vs. Just Slides
    109. 122. Expert Level vs. Beginner Level
    110. 123. Beginner Level vs. Expert Level
    111. 124. In-depth Technical vs. Brochureware
    112. 126. Grab Bag Presenting <ul><li>Including random crap which has nothing to do with the main topic of the presentation. </li><ul><li>(often at the behest of your employer) </li></ul></ul>“ Hey, Josh has a presentation at Open Source Bridge! We can get him to include a slide about Glassfish!”
    113. 127. 6. Time is an Illusion
    114. 128. You don't need to watch the clock <ul><li>Your audience will wait for you! </li><ul><li>No matter how long it takes. </li></ul><li>Don't worry about pacing
    115. 129. Don't worry about rehearsing
    116. 130. Don't worry about the next speaker
    117. 131. Don't worry about lunch </li></ul>
    118. 132. 7. Panic
    119. 133. Six Stages of Panic <ul><li>Apologize to the audience
    120. 134. Keep trying to get the demo or slides to work
    121. 135. Apologize to the audience again
    122. 136. Sit down and start hacking on your laptop to get it to work
    123. 137. Apologize some more
    124. 138. End the session early </li></ul>
    125. 139. 7 Ineffective Habits <ul><li>Chained to chair/podium
    126. 140. About Me/Us
    127. 141. Presenting for the Blind
    128. 142. Too Much Crap on Each Slide
    129. 143. Bait & Switch
    130. 144. Lose Track of Time
    131. 145. Panic </li></ul>
    132. 146. 7 Effective Habits <ul><li>Move Around
    133. 147. Get Right Into the Talk
    134. 148. Don't Read
    135. 149. Sparse, Well-Designed Slides
    136. 150. Stick to the Topic
    137. 151. Pace Yourself and Track Time </li></ul>
    138. 154. 5. Audience Interaction 101
    139. 155. Eye Contact
    140. 156. Body Language
    141. 157. Asking for a Response <ul><li>Wakes the audience up
    142. 158. Ask about them </li><ul><li>change your talk emphasis </li></ul><li>Find out if you're boring them </li><ul><li>critical in after-lunch and end-of-day spots </li></ul></ul>
    143. 159. Jokes <ul><li>Even better way to wake up the audience </li><ul><li>and relax them </li></ul><li>Hard to get right </li><ul><li>many jokes fall flat
    144. 160. some can offend people </li></ul><li>Investigate current affairs for your audience
    145. 161. Beta-test your jokes </li></ul>
    146. 162. Taking Questions <ul><li>Throughout talk
    147. 163. End of each section
    148. 164. End of the talk
    149. 165. … just let audience know! </li></ul>
    150. 166. Questions you can't answer
    151. 167. That Guy in The Third Row
    152. 168. Jesus in the Audience
    153. 169. Audience Participation <ul><li>Small-medium audiences
    154. 170. Choose the right person
    155. 171. Plan it carefully </li><ul><li>limited scope
    156. 172. timing
    157. 173. materials </li></ul><li>Be ready to abort & do something else </li></ul>
    158. 174. 6. Curate Your Code Examples
    159. 175. def snippetize (self): with ZipFile( 'all.key' ) as original: with ZipFile( 'out.key' , 'w' ) as updated: for item in original.filelist: if item.filename ! = 'index.apxl' : contents = updated.writestr(item, contents) raw = 'index.apxl' ) # Find snippets in the source tree doc = minidom.parseString(raw) pattern = '//sf:shape[starts-with(@sf:href,'http://localhost/')]' strip = 'http://localhost/' finder = Finder(doc, pattern, strip)
    160. 176. # Find snippets in the source tree doc = minidom.parseString(raw) pattern = &quot;//sf:shape[starts-with(&quot; &quot;@sf:href,'http://localhost/')]&quot; strip = &quot;http://localhost/&quot; finder = Finder(doc, pattern, strip)
    161. 177. Does That Mean I Have To Rewrite All My Examples?
    162. 178. YES!
    163. 179. Using TextMate? <ul><li>Slush & Poppies (light)
    164. 180. Blackboard (dark)
    165. 181. Inconsolata / Consolas
    166. 182. Bundles ‣ TextMate ‣ Create HTML ... </li></ul>
    167. 183. Using Something Else? <ul><li>Convert to HTML with
    168. 184. Copy and paste from browser </li></ul>
    169. 185. Lots of Slides? <ul><li>Auto-update your snippets
    170. 186. </li></ul>
    171. 187. Demo
    172. 188. Start With the Big Three <ul><li>“Create your slides in some standard slide software like Keynote, OpenOffice Impress or PowerPoint.”
    173. 189. Andy Lester </li></ul>
    174. 190. But If You're Ready to Move On
    175. 191. Showoff <ul><li>Code and shell sessions
    176. 192. </li></ul>
    177. 193. There's Always More Code!
    178. 194. 7. When Your Demo Crashes
    179. 195. Your demo will crash
    180. 196. 3 things to count on <ul><li>Conference internet will fail … during your talk
    181. 197. The hardware will fail … in unprecedented ways
    182. 198. The software will fail … in unreproduceable ways </li></ul>
    183. 199. 7 ways to avoid demo failure <ul><li>Be unambitious
    184. 200. Test the hardware
    185. 201. Drill demo repeatedly
    186. 202. Rewindable VMs
    187. 203. Fake your demo
    188. 204. Alternative demo
    189. 205. Never do “cascading” demos </li></ul>
    190. 206. Fake your demos <ul><li>screenshots
    191. 207. video
    192. 208. shell history
    193. 209. recorded shell sessions (ttyrec)
    194. 210. interactive shell scripts (IO::prompt) </li></ul>
    195. 211. 8. The Audience Outside the Lecture Hall
    196. 212. Speaker Notes Who are they for? Not the speaker!
    197. 213. Speaker Notes If the speaker notes for this slide were to include literally everything I plan on saying, like what you see here on the slide, then it would be way too much text for that tiny little text window at the bottom of the screen.
    198. 214. Audio Audio or notes; you don't need both
    199. 215. Sharing
    200. 216. SlideShare
    201. 217. YouTube Export slides + audio to movie
    202. 218. Your Podcast Host Wiki for “Enhanced Podcast”
    203. 219. More Information <ul><li>Josh Berkus </li><ul><li>[email_address]
    204. 220. </li></ul></ul><ul><li>Links on OSB Wiki: </li><ul><li> /Give_a_Great_Tech_Talk </li></ul></ul><ul><li>Ian Dees </li><ul><li>[email_address]
    205. 221. </li></ul></ul>This presentation copyright 2010 Josh Berkusa and Ian Dees, licensed for distribution under the Creative Commons Share-Alike License, except for photos, most of which were stolen from other people's websites via, and Sun presentations, the copyright on which is available at low, low rates.