Archive for category OSCON 2005
OSCON 2006: Day Two Recap
Posted by Brad in OSCON 2005 on 27 July 2006
On day two of OSCON 2006 I attended Real World Web Services by Scott Davis and More Perl Best Practices by Damian Conway, both of which were good. In RWWS, I don’t remember seeing how to do authentication and authorization over REST, but it must be possible. Damian’s tutorial was a continuation of last year’s tutorial and was quite good as well.
Tuesday night there was reportedly a BoF named “Beers of a Feather”, where someone was apparently organizing a pub crawl, so some of us from IRC went. The lack of any organization didn’t stop us, and we started off in Kells Irish Restaurant and Pub. It was a good start to the evening, especially when the live talent (one guy with a guitar) played Spirit of the West‘s Home For A Rest, whose chorus goes:
You’ll have to excuse me, I’m not at my best
I’ve been gone for a month, I’ve been drunk since I left
These so-called vacations will soon by my death
I’m so sick of the drink, I need home for a rest
The night proceeded from there, including hilights from a guy who rapped for us on the street, Chris forgetting his credit card at one of the bars, and a relatively seedy Russian-ish bar to close out the trek.
All in all, a good day.
Edit: I can’t believe I forgot the Tuesday Night Extravaganza! Larry Wall gave his annual State Of The Onion address, making it the tenth one now. It was a good talk about how Perl is growing up and will be ready to “set out on her own” when Perl 6 comes along. Kathy Sierra gave an engaging talk about creating passion in your users. And as always, Damian Conway was excellent with his parody titled “The Da Vinci Codebase”. A Perl one-liner that downloads an illegal prime and converts it into a gzipped program that can decrypt DVDs? Yes please!
Edit2: Flickr user ptufts uploaded a better picture of Damian Conway’s twisted twisted code.
OSCON 2005: Best Practice Perl, Damian Conway, second half
Posted by Brad in OSCON 2005, Unclassified on 02 August 2005
The second half starts off with a discussion about built-in functions. Damian Conway‘s most important recommendation about built-in functions is to use built-in functions, as there’s a lot of them and they’re incredibly useful and generally better than anything you can write yourself. In modern versions of Perl, the values function can be used as an lvalue, something I didn’t know (I think my Perl books are too old). Always use a block with functions like map and grep because the transform/test stands out more clearly.
There are also a load of functions that aren’t core but are in modules that are incredibly useful. Use things like List::Util and Scalar::Util instead of reinventing the wheel.
Subroutines are the single-most important problem decomposition tool available in Perl. They should be used to abstract out behaviour and be short enough to fit in the human brain (Conway says ten to twelve lines). Always unpack @_ first, don’t use things like $_[0] and $_[1]. Named arguments should be used if you have more than three arguments to a subroutine. It’s perfectly okay to mix positional and named arguments, and use a hash reference to pass in named (or optional) arguments. Don’t use prototypes. Always return with an explicit return. Use a bare return to return failure, don’t return undef because it doesn’t work properly in list context.
Moving to I/O, input and output are especially important. Don’t use bareword filehandles. Ever. They’re a bad bad idea because they clobber any other filehandle opened to the same name anywhere else in the same package. Use lexical filehandles instead. Use three-argument open because it doesn’t get subverted by bizarre filenames (say, filenames that start with a >). Putting braces around your lexical filehandle makes it stand out in print statements.
Regular expressions: always use the /x flag on every regex you write (it allows you to break up regexes onto multiple lines, and it allows you to put comments in them). It makes regexes more maintainable and readable. Always use the /m flag (it turns ^ and $ into matching the start and end of a line, instead of the start and end of a string). If you want to match the start and end of the string, use \A and \Z (or \z). Always use the /s flag (it modifies . to match any character instead of any character but newline). If you want to bundle all of these together, use the Regexp::DefaultFlags module. If you want to group, use (?: ... ). Don’t use $1, $2, etc., use something like my ($statement) = $source =~ m{\G ([^;]+) ;}gcxs;.
Error handling is necessary because programs are built by humans and operated by humans. When you detect an error the only safe thing to do is to go up-scope. Prefer exceptions over special return values, because it’s incredibly easy in Perl to ignore return values. Throw an exception as soon as you have the chance. Use croak instead of die. Write your error messages in English so that the user can understand what’s gone wrong.
Use CPAN.
When writing a module, design the interface first. When refactoring code, it’s always okay to cut, it’s never okay to paste. Perl 5.10 will come with a core module called version that will handle versioning much easier than before. Consider the Perl6::Export::Attrs module for exporting subroutines from modules. Have a standard module template for any modules you write.
That’s the end of the tutorial.
OSCON 2005: Best Practice Perl, Damian Conway, first half
Posted by Brad in OSCON 2005 on 02 August 2005
Is there actually a right way to do things in Perl? Of course not, but Damian Conway just wants to give his impressions of what the best practices might be. “Best practices” refers to writing code that is maintainable, robust, efficient and concise. Best practices is a set of rules to combat “Intuitive Programmer Syndrome,” where a programmer programs by using The Force instead of following some standard set of rules.
Damian Conway wants us to become lady and gentlemen programmers who, six months down the line, don’t hurt anybody unintentionally. That’s what best practices are about, not hurting the person who’s going to have to maintain the code we write today.
Uhoh. “Nobody wants Perl programs more than 10,000 lines long.” ORAC-DR sits at over 300,000 lines of code, but a lot of that is documentation.
None (or at least, very few) of the rules Conway will be presenting are absolute. Consider them guidelines. Use them as a starting point, not a finishing point. Negotiate the rules with your fellow developers, and enforce them strictly and rigidly once they’ve been established.
Starting with the most controversial part of coding standards: layout. It doesn’t matter which style you choose, as long as when you pick a style you stick to it. Conway suggests bracketing and parenthesizing in K&R style, separating control keywords from the following opening bracket, not separating subroutines or variable names from the following opening bracket, and separating complex key/index computations from the surrounding brackets. Semicolon after every statement, comma after every list element, 4-column tabs. Code in paragraphs, meaning put an empty line between distinct chunks of code that do one thing. Each one thing might have a few lines of code, but if you separate these things by blank lines, the code becomes easier to read. If you’re breaking up long expressions into multiple lines, Conway suggests breaking before the operator (which is something I don’t do).
Only slightly less controversial: naming. Conway claims that a consistent naming convention will make your code at least twice as maintainable. Using underscores_in_variable_names insteadOfInterCaps is considered easier to read, as is abbreviating names by prefix instead of removing vowels. Name hashes in the singular and arrays in the plural.
“Thinking causes problems.” So don’t think, use templates for forming identifiers.
Moving on to variables, watch out for the so-called “punctuation variables” — nobody is comfortable with all of them. Don’t use package variables unless you absolutely have to. One thing I didn’t know is that $a and $b (variables used for sorting) are completely immune to use strict. Lexical variables should be used within modules, and subroutines used to modify those variables. Watch out for modifying $_.
Conway doesn’t like postfix-style control structures (do this if that), and prefers it the other way around (if that do this). He doesn’t like the C-like three-statement for loop, prefering the more Perlish for loop (for my $n ( 4..$max )), because he doesn’t have to think. Don’t subscript within loops; if you’re going through values in an array then ideally do something like for my $client ( @clients ) { ... }, or at worst take a copy of that value within the loop (suppose you need the iterator variable to print out client numbers), then do operations on it. Same for the values of a hash, as long as you’re using Perl 5.6 or higher. (Note for self for when I get back to work: look into Data::Alias)
When you write a for loop, don’t use explicit $_, use an explicit iterator instead (i.e. for my $candidate (@candidates) { ... }). Never leave off the my when naming an explicit iterator. Also, don’t trust use strict. Use it, but don’t trust it. “Perl will shoot you in the head if it possibly can. Doesn’t believe in the body shot.”
This coming section would be Tim’s favourite: when to use map instead of for (I always use for and Tim always changes them to map). You get more compact code, use less memory, and it’s probably going to be faster. Use map when you want to generate a new list from an old one, and use for to transform a list in-place.
When producing a value that depends on a series of tests, use the ternary operator, and line things up so the question marks line up in a column and the colons line up in another column.
Documentation! Development programmers hate documentation, maintenance programmers love it. Since we’re both, just do documentation. “Documentation is a love letter we write to our future self.” Create a standard POD template and just fill it in — h2xs -X, ExtUtils::ModuleMaker and Module::Starter (or Module::Starter::PBP) can do this for you. The DIAGNOSTICS section should be pulled directly from every die, croak, and carp statement in your module, as long as every output to STDERR. Document what’s already broken. Remember: “the primary use of user documentation is so you don’t have to interact with the user.” A disclaimer of warranty is probably the most important thing to put in these days. Acknowledgements are a good thing to put in as well, because it makes people happy.
Develop a consistent commenting system and use it. I was the only person to stick their hand up when Conway asked who has colleagues who write good comments (I’m thinking primarily of Malcolm’s code here, although most of the Starlink code is extremely well-commented). Use =for sections comments for larger discussions. A comment belongs anywhere something has puzzled you or tricked you. “If it fooled you once, it will fool you, or whoever comes after you, again.”
Thus ends the first half.
OSCON 2005: Presentation Aikido, Damian Conway, second half
Posted by Brad in OSCON 2005 on 01 August 2005
Starting off the second half of Damian Conway’s presentation titled “Presentation Aikido” with visual style. Again, it’s about simplicity, using shadows and underlining and whatnot subtly. He’s done shadowing so subtly that we can’t even see it. Clearly one needs to check monitors and projectors before doing a presentation. :-) Luckily his second example worked, although I don’t really care for his choice of colours (yellow on green).
Which transitions nicely into colour schemes. Contrast is essential. Contrast is essential. Contrast is essential. There are many tools that allow you to generate complementary colour schemes: use them. Keep in mind that about 10% of the population has some difficulty with colour perception, so don’t use colour as a tool for discriminating between different texts, use brightness instead (or maybe different fonts). There’s a tool at vischeck.com that one can use to view webpages under different types of colour impairment.
It’s essential to keep people interested, so every so often surprise your audience. Tell them a story, use examples, make comparisons, change your pace and style (but don’t change your pace just for the sake of it). And every so often, give your staircases landings to give people a chance to digest what they’re injesting. You can also use those landings to let people know that a new topic is coming up, to keep the audience oriented with the flow of the presentation.
“Just because you can doesn’t mean you should.” He’s talking about transitions. Make them smooth and elegant, and use the obvious transitions in special occasions, possibly when you come to a “landing.” And for the love of Pete, don’t use transitions between slides, either fade in or just switch to the next one. Don’t zoom in, don’t do cube rotation, don’t do any of that rot.
Don’t use architecture charts. I’ve been guilty of this, and nearly every presentation I’ve seen has one. “Show a chart, lose an entire audience.” If the audience needs to know it, put it in the notes. Ditto for graphs.
If you’re going to put your name and title on your slides (which isn’t a bad idea), make them subtle and ignorable so they don’t interfere with the information on your slides. Lose the logo from each slide, because putting the logo on is distracting and it makes you look like a salesperson. If you have to have a logo because of corporate policy, watermark it.
Moving on to presentation, make it look effortless. Make it look like you’re on TV so your audience doesn’t feel pity for you. That’s something that’s learned and comes with practice. Make it look easy, even if the actual material is difficult, because the audience wants it to look easy and not threatening. And be yourself, but be yourself-less. The presentation isn’t about you, it’s about your material. You’re a conduit for relaying the information to the audience.
“Don’t be paralyzed by the butterflies.” Use your nervousness and turn it into nervous energy. Rituals can help you focus, get you into the same groove. Rituals can be anything, but as long as it takes you back to the familiar it’s good, it’s less frightening. He recommends not ignoring the audience before doing your presentation, but if you talk with someone, talk about them instead of yourself.
Have a backup plan. Always carry backups of your material. Conway’s a little anal about backups (he says “sophisticated”), with five backups in five different locations, but it works for him. It may only save you once, but that’s enough.
Dress how your audience expects you to dress. If you’re a CEO, dress like a CEO. If you’re a hacker, dress like a hacker.
Don’t read your presentation. The audience is perfectly capable of reading the presentation, they don’t need it read for them. Unless you’re reading to 2-year olds, of course. To do this, make sure you rehearse your presentation, and rehearse it aloud. You can have a cheat sheet, but it’s not the script, it’s a list of points you are going to make.
Demonstrations beat descriptions, because it’s easier for the audience to get the point. Make sure that your demonstrations work, though, and make sure that you’ve got local copies of your demos, if they normally live on the Internet somewhere. Use IO::Prompt if at all possible.
Use a microphone, drink water, and make a pitstop before you start. Watch the time, and make sure you stick to your intended schedule.
For handling questions, have a policy. Don’t just take questions randomly, decide where and when and if you’ll take questions, and let the audience know about this policy. When you answer questions, repeat the question and try to paraphrase it. If you don’t know the answer, don’t fake it, say something clever instead like “I don’t know the answer,” or try to redirect the question to someone who might know the answer.
And try to do presentations fairly often. Even if they’re not formal presentations, there are many situations you can use to improve your skills. “The only way to speak better is to speak.”
OSCON 2005: Presentation Aikido, Damian Conway, first half
Posted by Brad in OSCON 2005 on 01 August 2005
I don’t give presentations all that often, but when I do I generally tend to get nervous and flustered and do all the bad things that you’re not supposed to do to give a good presentation. When I saw that Damian Conway was giving a tutorial at OSCON 2005 titled Presentation Aikido, I was jazzed. Conway always does a good talk, and a presentation about giving presentations was just too good to pass up.
20 minutes in and the main point seems to be “be confident.” To be confident you need to know your material beforehand and know it well. If you don’t know it well then you’ll be up there giving a presentation, stumbling all over the place. You need to prepare your presentation and notes beforehand and practice it. You need to talk about what you care about.
You should take quite a bit of time to come up with your presentation. Conway suggested 10 hours of prep for each hour of presentation. 20:1 if you’ve got something relatively tough. He said for this three hour tutorial he took 80 hours to come up with it, and was still fiddling with it the night before.
Oh, and you need to be entertaining: “Entertaining always trumps informative.” Tell a story. Even if it’s made up, it’ll keep the audience interested and keep the presentation topic grounded in reality. Use metaphors, but use good metaphors: “I’ve never considered time as a non-renewable resource.”
Sidenote: This must be a good presentation because in a room full of geeks only a handful have their laptops out, and there are only two or three typing. End sidenote.
You should have five major points that the listener is going to take away with them. Humans don’t have a very big buffer so any more information than this will just leak out of their ears.
He’s currently making the point that presentation is more important than the information: “having great information on a shoddy-looking slide is actually worse than shoddy information on a great-looking slide.” I agree with his point, but for the most part I think he should be making the point that simplicity is more important than attacking the user with graphics. Actually, it looks like he is, but doing so in a bit of a roundabout fashion instead of outright saying it.
Yes, he is promoting simplicity. For presentation style, don’t use the Microsoft standard PowerPoint templates. “Steal from the cool kids: Apple, Bang & Olufsen, The Perl Journal… no substance, but lots of style.” For fonts, don’t use many. Give each font a meaning: italics for headings, classic serif for content, fixed width for code. Don’t use Papyrus (it’s overused) or Comic Sans (it looks amateurish). If you use images, use them meaningfully and in moderation, “like seasoning.” Ditto for animations, but use them even more sparingly: “if I can’t do it easily with the limited facilities in PowerPoint, it’s probably too complex to bother with.” Ditto for video, but use video even less often than animations.
We’re now at the half-way point. Time to get some coffee.
-
You are currently browsing the archives for the OSCON 2005 category.
recent photos
Recent Comments