canspice.org

The title of Larry’s talk is “Rules that are meant to be broken”. He says that he’s breaking his rule of giving funny talks, and there’s only one joke in the whole talk, and that wasn’t it.

He wants us to break Perl by coming up with new syntax for it.

People keep asking him “if you had to do it all over again, what would you change?” Two answers: nothing and everything. Perl 6 is the “everything” answer.

In Perl 6 regexes are a sub-language, not strings (as they are in Perl 5). Perl 6’s goal is to be a collection of many languages.

But in Perl culture we’re not told how to think. After all, TMTOWTDI.

Larry proposes that we deal with derived languages sensibly. Instead of copy-and-paste, use polymorphism.

I think I’m losing the plot here, so I’m going to pay attention to the talk now. Sorry!

Lightning talks are five-minute presentations about virtually anything related to Perl. They’re supposed to run for an hour and a half, so there should be plenty of speakers and plenty of topics.

First up is David Wheeler talking about testing your database with pgTAP, which is a bunch of stuff that is pretty much Test::More for PostgreSQL. Perl tests and SQL tests all in one bundle.

Next up is Eric Wilhelm with the 2008 The Perl Foundation Summer of Code update. There’s a lack of Perl in universities — 40 mentors, only 12 proposals, and 6 funded slots. The number of proposals needs to increase. This year’s projects are: flesh out the Perl 6 test suite (Adrian Kreher), wxCPANPLUS (Samuel Tyler), Native Call Interface Signatures and Stubs Generation for Parrot (Kevin Tew), Incremental Tricolor Garbage Collector (Andrew Whitworth), Math::GSL (Thierry Moisan), and… uh, did I miss the sixth?

Next up is Fred Meyers who works at USA Today, talking about what would be missing from the newspaper if Perl stopped working: bar code, news snippet for each state, AP “results at a glance” for election info, best selling books info, TV Nielsen ratings, week’s top stocks, stock tables, sports standings and results, upcoming games, box scores, team stats.

Next up is Michael Schwern, talking about “Who’s Afraid of 2038?” Remember Y2K? Total mass hysteria that didn’t happen. Now we’re home free. Right? Nope. “Critical and Significant Dates” In 2038 the Unix epoch is going to end — using 32-bit signed double floating point numbers. To fix this in Perl, Schwern suggested that there’s no reason for a Perl programmer should care what the underlying system uses. Schwern can solve the 2038 problem with code at svn://svn.schwern.org/svn/y2038

Next up is Brad Fitzpatrick who works at Google. He’s talking about the Google App Engine and how he’s going to get Perl implemented on it.

After Brad comes Paul Fenwick to talk about autodie. Error handling in Perl sucks. Typical error handling code (or die …) is longer than your code. Wouldn’t it be nice if we can get Perl to generate errors automatically if e.g. your open failed? There’s the Fatal module, but it’s ugly and horrible. autodie is pretty much the same, but it’s lexical and it gives you better error messages. You can put use autodie inside an eval and then use a given/which to figure out which statement inside the eval failed. It can be subclassed too!

Now comes some guy who didn’t say who he is, talking about Net::SMTP::ESMTP, a modern email client.

Brook Wilcox is talking about a module called Devel::REPL and Continuity, which kind of gives you a Perl shell in a browser.

Jerry Gay is going to write a Turing-complete language in five minutes using Parrot. And he did! Well, he didn’t type it all live as that would’ve taken too long…

And now someone else is going to wrap this language into an Apache module — in five minutes. Live demo! And it culminated with the first LOLCAT sighting of OSCON.

Now comes Tatsuhiko Miyagawa talking about Web::Scraper. Lots of screen-scraping going on, mostly with LWP and regexps. Bad! Fragile, hard to find bugs, unmaintainable. Use Web::Scraper instead. DSL-ish syntax, CSS selectors and XPath, DOM and Unicode handling. Comes with a command-line interface. Looks really cool and useful.

Chia-liang Kaw is up talking about the Secret of Success of Open Source: plagiarize. An homage to Tom Lehrer. Well done!

Now comes the swearing portion of our show: “Fuck, the Fucking thing is Fucked” by Jos Boumans. RIPE is one of the five Regional Internet Registries. Jos Boumans works for RIPE, in case you’re wondering about the connectin. IPv4 is finite and is running out of space: IPv4 D-Day is 22/05/2010. So deploy IPv6 then! That was the plan, but plans don’t match reality. But nobody wants to move to IPv6 because nobody is using IPv6.

Now Elizabeth Cortell with “Pulp Perl” — O’Reilly’s other publishing line. ORA is famous for “anvil books” that don’t really rake in the cash. Pulp Perl is the most fun you can have reading with two hands. (spoof on pulp fiction novels and magazines with a Perl theme)

Adam Kennedy is up next, and he’s from the future (Australia). Adam likes first principles. About five years ago he wanted to find out if he could find a way to make Hollywood movies suck less? Since he can’t change Hollywood, he had to change himself. He’s going too fast so I can’t type to follow along. Alas. Oh, takeaway statement: do not watch trailers.

And now pudge with a singalong. Woo!

Why log? Logging can help you debug during development, go back in time and figure out what happened, measure performance, and to trace activity on live systems.

So why use Log4perl? It doesn’t have any CPAN dependencies. It’s easy to use, but scales with complexity. And it has some unique features.

There are four different kinds of remote controls: levels (log/suppress priority/level), loggers (locate it in the system), layouts (format it), and appenders (write it out).

In your code, you can set different levels by doing things like:

DEBUG "Starting up";
ERROR "Cannot open file $file";

The output layout can be modified:

Log::Log4perl->easy_init( {
  level => $DEBUG,
  layout => "%r %M %F-$L>%m%n",
});

If you’re doing more complex things like this, Schilli recommends using a config file: Log::Log4perl->init( “l4p.conf” );. The benefits of config files is that you can modify them independently from the program, modify it while the program is running, and it can be modified by people who don’t know (or can’t access) the code.

You can set Log4perl up so it looks for a specific configuration file. Not only that, you can set it up to reload that configuration file at any given frequency, which allows your logging to be modified while your program is running.

The available appenders are: Screen, File, Socket, DBI, Synchronized, RRDs, and a bunch more supplied by Log::Dispatch. You can set up rotating logfiles via Log::Dispatch::LogRotate.

Layouts support all kinds of different information, and if there’s a layout pattern that you want that’s not available, you can define new ones.

Log4perl isn’t “free” in the speed sense: 50k logged messages per second gives you some overhead in your program.

Wouldn’t it be nice if more CPAN modules were Log4perl-enabled?

Tim Bunce is the author of the recently-released NYTProf v2.

I unfortunately missed the first five minutes of this seminar, as I was tied up giving an interview for O’Reilly News with chromatic. Tim, chromatic says hi and thank you for the help with XS.

NYTProf v2 does subroutine profiling, meaning it is a statement and a subroutine profiler, at the same time. The subroutine profile tracks time per calling location. It calculates exclusive time on-the-fly, and discounts the overhead of statement profile. To minimize disk I/O, it does everything in memory and writes to a file at the end. It’s also extremely fast. Statement profiler gives correct timing after leave operations.

v2 does sub microsecond resolution. It reports correct timing for mod_perl, handles forks with no overhead. Profiling can be enabled and disabled on the fly, and can profile compile-time activity.

When Tim asked for questions, Adam Kennedy asked, “The only question is, ‘Why are you so awesome?’”

The plan is to merge multiple runs, so say from running code through a test suite.

Reporting is only done via HTML or a CSV file. Tim isn’t too happy with this, thinking that he could come up with some pluggable class structure.

Trace file size depends on how long the profiler runs on your program. For example, running perlcritic on the NYTProf source code created a 360MB to profile 26 million statements. This ran for a minute and a half (which normally takes 30 seconds).

The full title of this talk is “Skimmable Code: Fast to Read, Safe to Change”, and it’s presented by Michael Schwern.

What does Schwern mean by “skimmable”? He means in terms of like skimming a book — you skim through the book to find info you want, rather than studying the entire thing, because you want to find the info fast.

Why skim? It allows you to focus on a single task. It lets you slice through hairy code. It lets you free up brainpower. This talk is essentially applied best practices, it explains the reasoning behind best practices.

How do you skim? It all comes down to narrowing your focus. How do you do that? Your primary weapon is “lexical encapsulation” — look at the stuff that’s right in front of your face. Not the subroutine calls, not method calls, just the stuff between the braces (that’s in your lexical scope).

Tests are useful for making code skimmable, because at the touch of a button you can see if your modifications have broken anything. When refactoring code, refactor, then test, then commit, then repeat. If you fail a test, you can find out where you’ve broken things (and always test before committing).

Rename refactoring: use good names. For example, calling something $arg isn’t useful; call it something that describes what it is actually used for. This way you don’t have to keep referring back up to the top to figure out what the argument is.

Extract refactoring: extract routines and methods out to prevent other routines from doing too much that you can’t keep it all in your head. After you extract routines out to subroutines, it cleans up the structure of your program and you may be able to extract more routines out to subroutines again.

Whitespace allows clarity. Vertical whitespace can be used to differentiate between major blocks in your code. Similar things should look similar, so if you’re using a hash constructor try lining up the fat commas.

Different things should be displayed differently, e.g. $lexical vs $Global.

Red flags: No documentation. No tests. Things are deeply nested. Compound names (e.g. make_waffles_and_pancakes. Generic names (e.g. @list, $arg, $data). Overly verbose (e.g. $total_amount_spent_on_food). Globals. Scope closing comments. Long routines.