About half way through the week I was accused of being a prolific blogger. Just how prolific, I wondered. So I went through the list of all of my posts prefixed with “OSCON 2008,” including this one. As it turns out, I wrote a grand total of 17,270 words. The post for Damian Conway’s Perl Worst Practices has the dubious distinction of containing the most words, at a scale-tipping 1,209. Other posts I made during the conference, but not directly related to any sessions totaled 1,608 additional words. Prolific? Perhaps.

My primary reason for writing so much about the sessions is for my own reference. These posts allow me to go back and remind myself of what I did and what I learned. I just happen to post my notes publicly, because I hope they may be useful or informative for others. In particular, anyone who couldn’t join me at OSCON. Naturally, I was a bit curious to know if anyone was actually reading my articles. So I checked.

I typically receive about four visits per day. Google’s Analytics service uses JavaScript to collect data, so I’m fairly comfortable declaring that my visitors are probably real people using real Web browsers, rather than search engines or even feed readers. The regularity of visits is curious, though. I’ll have to investigate my traffic a bit more closely. Visits to my site began to rise dramatically on the first day of OSCON, peaking mid-week when the main conference got started. Hopefully, people are enjoying my writings, because I enjoy doing it. I’ve tagged all of my 2008 OSCON posts with the oscon08 tag, which will make it easy to refer to them later.

Thinking back over what I’ve written, I’m not completely pleased with the finished product. I don’t think attempting to post entries so immediately after each session is the best approach. In the end, I don’t believe I’ve done the topic or the speakers justice. Next time, I may simply take notes in preparation for a proper article after the fact. The Tuesday night keynotes, in particular, would have benefited from this treatment.

I’ve been a fan of Damian Conway since I first attended one of his talks at a San Diego Perl Mongers meeting in late 2005. Since then, I’ve been fortunate enough to see him speak at two OSCONs as well as attending his Perl training at my place of employment. There must be something about Australians, because one of the best presenters at OSCON this year was Paul Fenwick, also from Down Under. I highly recommend them both. Entertaining and educational, a far too uncommon combination.

This year I found that I wasn’t as excited about OSCON as I have been in the past. It’s been more than just this past week, too. A lot of things that once brought me joy have left me feeling empty. I didn’t know why, and assumed that I was simply too busy, trying to juggle too many balls again. I was wrong, though.

Near the end of the Perl Worst Practices tutorial, Dr. Conway was asked how he became so proficient at what he does. In response he asked who in the room practiced martial arts. No one in front of me raised their hand, but I suspect at least one person behind me, in addition to myself, raised their hand. Disappointed, he cycled through a couple other sports (cycling and tennis, I think) until he received a reasonable response. The point, of course, was that, like these sports, programming requires passion and should be practiced every day.

That’s when it hit me. I don’t write code every day anymore. I’ve been writing code as long as I can remember. My first Hello World was written in BASIC at the tender age of four. Lately, I haven’t spent any time at all writing code. I’ve been waking up early, working long hours, going to bed early, and spending what free time I have left with my pregnant wife. That has to change. So now I’m back to staying up late, doing more work from home, and stealing moments to write code; even if it’s just a few lines. I’m also working on a talk I plan on presenting to my coworkers and would also like to give at SCALE 7x next year.

Conferences are not always about the tutorials or the sessions. Sure, they offer plenty of opportunities to learn something new, but that’s almost a complement to the main event. It’s about networking with our peers. Most importantly, it’s about revitalization. My annual pilgrimage to Portland replenishes my spirit. I return refreshed and full of creative energy. The trick is maintaining the momentum.

I suppose O’Reilly is targeting the same market as Gartner. Companies willing to spend what, to an individual, is a lot of money to have experts tell them what to think.

Every conference I’ve attended—though that hasn’t been many—have used the same gimmick in an attempt to get people to visit vendors. Each markattendee is given a “passport” with a number of vendors listed. The goal is to visit each of them and receive a sticker for the effort. The reward is entry into a contest, the odds of winning being proportional to the number of people who fall for the scam. I always start out collecting stickers, but quickly realize why I’ve never gotten as far as entering the contest. I really hate talking to salespeople. I’m not interested in any of the products being pitched and, even if I were, there’s nothing they can’t tell me that I can’t discover for myself on the Web. At one point, I’m pretty sure Eric S. Raymond even tried to hand me a flyer—I’m unsure if it was about Free Software or sex—but I politely declined and went on my way.

I was pleased to run into Alyson at the Ticketmaster booth. We met at SCALE6x in February, where she was again working the Ticketmaster booth, but also assisting us with the Perl Mongers booth. It was good to catch up with her. I was sure to tell her how much I admire what she does for the Los Angeles Perl Mongers and how I wish we had someone like her in San Diego.

Sun actually had a nice booth this year. They provided a place to relax, snacks, and a wifi network with a hidden ESSID for people fed up with the one provided by the conference. I didn’t spend much time there, but I did take advantage of the wifi as I lounged in the O’Reilly booth.

Amazon was running what I found to be an interesting gimmick in their booth. “Ninja” code. It was just a bit of self-modifying Perl written out on some poster board. Tell them what it did and get entered into a raffle. It was actually a fairly clever way of advertising for talent to hire. Heck, it got me coming back to the booth a few times, if only to make fun of it. I did spot some potential improvements.

Intel’s gimmick this year was actually kind of interesting. Everyone who visited their booth could receive a sticker with a number on it to wear. The goal then is to find the person wearing the matching number. People would post a phone number or Twitter handle on a cork board at the Intel booth for others to find. I posted my Twitter information but unfortunately my default view only includes friends, not replies. That, and the ever present fail whale made me miss my partner’s tweet. Mere minutes after the raffle on Wednesday, as I was getting ready to throw away my sticker, I hear Jonathan call out to me that he’s found my partner. As it turns out, there would be another drawing on Thursday, so we went ahead and entered. That led to an extremely annoying sales pitch. He wanted us to tell him about Moblin. Just to spite him, I told him about Snapdragon instead. What do I keep telling myself? Stupid gimmick contests aren’t worth it. What I did like about it was the social aspect. I met someone new, had a pleasant conversation, and he’s now following me on Twitter.

On Thursday at the O’Reilly booth, Brad was interviewed on camera by chromatic. I expressed my desire to see it play during a keynote, but that wasn’t meant to be. Brad uses Perl to do cool things with telescopes and munge astronomical data, which is of interest to the O’Reilly editors. He’s been asked to write an article about it, and I’m trying to convince him to give a talk at next year’s Open Source Conference.

[tags]oscon, oscon08, oscon2008[/tags]

Based on past experience, this is likely to be a fast-paced, highly-entertaining talk. One which will be impossible to summarize, or no doubt even to explain, here. Needless to say, if you’re not here, you’re missing out. I intend to sit back, relax, and enjoy.

He’s talking about the defining characteristic of a hacker. Particularly when they’re told that something is impossible and can’t be done. The reaction is typically, “you wanna bet?”

He just presented a slide that read, “Let’s leave behind the shackles of sanity…”

Now I’m scared.

This is a great talk. It’s a series of examples of things “you can’t do in Perl.” At least, not until Damian shows us how.

I think Brad may have taken notes. Which is good, because now I wish I had.

[tags]oscon, oscon08, ocon2008, Perl, Damian Conway[/tags]

There are so many holy wars debates about whether one language is better than another. Instead, the right question to ask is whether or not the developer’s skill set is right for the job. I agree. When I look for a developer, I’m more concerned with how they think than in what language they think.

Unfortunately, Tim is preaching to the converted in this talk. Nearly the entire attendance already uses Perl and don’t believe the myths. With that, let’s conquer them anyway.

Perl is Dead

No it isn’t. It’s two decades old and still growing strong. The books aren’t flying off the presses with great speed because the Perl community already has excellent books.

The trend when searching for “web development” jobs shows Perl growing very slowly in relation to other languages, particularly PHP. However, searching for “developer” jobs shows Perl growing very strongly and holding its own extremely well.

As a lurking member of the Perl community and an active member of my local Perl Mongers group, it’s been my experience that Perl programmers tend to be quite happy with their jobs. Which, unfortunately, has made it very difficult for me to find talent.

In fact, Perl is growing faster than ever. A simple look at how much work is going into CPAN will show that. The community is strong and Perl is everywhere.

Perl Is Hard to Read / Test / Maintain

Only if you’re doing it wrongly. We have Perl Best Practices, to use as the default documentation for coding standards, leaving developers with the need to only document when they deviate from the norm. There’s Perl::Tidy, to force any Perl code into one’s own personal style. Perl::Critic for ensuring that code is being well-written and follows best practices. And there’s no end to the Test::* modules and the work being done to make testing easy. There’s even a coverage analysis tool.

Perl 6 is Killing Perl 5

In fact, Perl 6 saved Perl 5, but one has to be close to the center of the community to see that. One should notice that Perl 5.8 and 5.10 have both been released in the time that Perl 6 has been in development.

There is a culture of testing around Perl. So many tests have been written for Perl 6, and the language is being defined by its test suite. This culture has leaked out to the community. In fact, I find there now exists a lot of peer pressure in the community to do proper testing.

Perl 6 Is Not Perl

Yes, and no. Unfortunately, I was so busy trying to catch up with the last section that I missed most of the points Tim made. In the end, I feel that this is fine. If Perl 6 was supposed to be Perl 5, why not just use the perfectly decent, already existing Perl 5? Which is still being actively developed.

Perl 6 Will Never Be Ready

It’s not on a schedule and, if it were on a schedule, it would be crap. It will be ready when it’s ready. Better to do it right than screw it up. The development model encourages a lot of experimentation, and it’s difficult to schedule experimentation.

There’s No Perl 6 Code

Sure there is. Thousands of lines of Perl 6 code exist in the test suite that came about from Pugs. These very same tests are being used in Perl 6 development today in the form of Rakudo, Perl 6 on Parrot.

The important thing to note is that Perl 6 refers to a specification. It does not refer to a particular implementation. Any implementation that passes the test suite may call itself Perl 6.

From an authority in the audience (who I don’t recognize, unfortunately), we have been told that there will be a useable Perl 6 by this Christmas. A round of applause ensued.

[tags]oscon, oscon08, oscon2008, Perl, Tim Bunce, myths[/tags]

First up this morning Allison introduced Benjamin Mako Hill of the MIT Center for Future Civic Media. He will be speaking about Advocating Software Freedom by Revealing Errors. He seems to be far too highly caffeinated for the room this morning, and is speaking very quickly, and the sound system is too loud, so I don’t entirely know what’s going on.

The gist of the talk is that, when errors become visible to the user, it exposes something about the underlying technology. He’s provided several obvious examples of ATMs crashing with Windows errors. He runs the Revealing Errors Blog, too.

Next up is Dawn Nafus of Intel, speaking about Three Challenges. Unlike most speakers at OSCON, she is an anthropologist. There is a notion, particularly in the mobile devices industry, is that adding more and more data is equivalent to adding context. This is phenomenally untrue. Data without context is, more often than not, useless.

Her second challenge is the global food crisis in food and water, particularly in the developing world. We Open Source folks are quite good at decentralizing power, just look at how so many of our projects are organized. Technology is fast going mobile, and as these devices become cheaper, they are more easily put into the hands of people in the Third World. There are many applications for this technology, we just need to be creative about how we go about taking advantage of this proliferation in technology.

The third challenge is to strengthen global growth in technology producers, not just consumers. We must better understand where growth is coming from.

Annoyingly, we have another speaker from Microsoft this year, Sam Ramji. He’s, apparently, here to tell us about Open Source Heroes. He’s telling us about platform trends, something we already know about. There’s some slide about applications moving into Internet moving into Web applications over the time frame 1995 through 2005.

Microsoft sees Open Source growing strong over the next decade, but it’s hard to take him seriously, given the company’s history. While he’s talking about Microsoft’s contributions to Open Source projects and the work they’ve done to improve their ability to work on Windows, I’m constantly on edge around Microsoft, wondering what they really have planned. In fact, I may have just answered my own question. Improving the use on Windows, thus attempting to ensure the continual use of Windows. They’re desperate to hold on to the market share they’ve so deceitfully gained.

This talk can be summed up as, Hey look, we’re not evil, look at this boringly enumerated list of Open Source stuff we’ve done.

He’s announced that Microsoft has become a “platinum” sponsor of the Apache Software Foundation. That doesn’t sound good to me. Do people forget the embrace-extend-extinguish history of the company? Should we really trust them so much?

Next up, refreshingly, is Tim Bray of Sun Microsystems, speaking to us about Language Inflection Point. There’s background music, and he’s speaking very quickly. He’s going over slides demonstrating various ways of measuring the popularity of programming languages. From search engines to book sales.

He took a survey of the room. A show of hands for who is using various languages and if we would still use it in an ideal world. Python and Ruby were the only two languages with a positive delta, more people raised their hands to show that they’d use it in an ideal world than those who currently use it.

From there, he launched into a discussion of each language and their benefits and drawback as he sees them. Obviously subjective, but they’re not entirely bad points. He never got to Perl, so I’m a bit disappointed.

Finally, we have Jeremy Ruston of BT Design, who created TiddlyWiki. He’s here to tell us about Learning from Airports.

At airports today, the actual actions of taking off and landing is more a side-show. There are more shops and things like security lines (and waiting), and the actual arrivals and departures are a very short part of anyone’s visit.

Airports do serve as an excellent analogy for technology standards. Single sign-on: passports. Access tokens: boarding passes. Standard documentation: universal signage.

The keynotes wrapped up with a question and answer session with each of the morning’s speakers. The first question, unsurprisingly, was about patents, and what will it take for Microsoft to commit to not using patents against Open Source. The speaker claims that developers should never have to worry about it, but it was unconvincing.

Unsurprisingly, the majority of the questions were directed to the Microsoft representative. They ranged from (and I’m paraphrasing), why Microsoft is evil and patent bashing thinly veiled as questions. Unfortunately, the presence of the Microsoft shill speaker on stage led to a completely wasted question and answer session.

But now it’s break time, so I’m off in search of more coffee. OSCON starts way too early in the morning.

[tags]oscon, oscon08, oscon2008[/tags]

SourceForge held a couple of parties for us last night. One was at the Jupiter Hotel and the other, branded BeerForge, was at a party venue down the block from the hotel. Obviously, we attended both—twice.

Josh and I started out at BeerForge. After a while we got hungry and found Brad, Alice, and Sam over at the SourceForge awards party. As things got too crowded, we all went over to BeerForge. As the venue grew too hot and loud, we ended up back at the SourceForge location, where we could be outside at least. After that venue closed down, Josh and I went back to my hotel room to polish off a growler—a half gallon—of beer I had picked up at Rogue the night before.

I’m now at breakfast, after a whole four hours of sleep, and extremely thankful for the coffee, fruit, and pastries that have been laid out for us. The fresh air and the walk to the convention center helped, too. This week’s festivities make me almost want to take a pass on the Oregon Brewers Festival. I said, almost.

Fortunately, there are only two sessions today, leaving me with only two decisions to make. However, after a more careful review of the schedule, the choices seem obvious.

First, Tim Bunce is giving a talk on Perl and Parrot: Baseless Myths and Startling Realities. I’m not as enthusiastic about Perl 6 as I once was, but I quite enjoy Tim’s sessions. Following Tim, in the same room, is Damian Conway. He’ll be presenting—oh, does it even matter?

I will be faced with a bit of a dilemma tonight. My flight home is scheduled for 6:40am tomorrow morning. However, the MAX light rail ends its service at midnight and doesn’t resume until 4:30am. Several years ago this may have been acceptable, but not in the airports of today. So my options are to get a couple hours of sleep followed by calling a town car, or check out of the hotel tonight and make my way to the airport before the MAX service terminates for the night. Quite honestly, arriving at the airport six and a half hours early is still shorter than some of the layovers I’ve had.

Well, I’m going to finish my breakfast and tag some photos. In just under an hour, the final day of keynotes—and thus of OSCON—get started.

If he had Perl to do all over again, what would he do different? Only two things, nothing, and everything. Perl 6 is the everything part of the answer.

In Perl 5, one of the problems that creeps up is that regular expressions (regexes) are strings. The best example of this is variable interpolation in regexes. In Perl 6, this has been fixed. They are now their own language.

Like cargo-cult programming, parsing has turned into its own cargo-cult. Perl 6 breaks the mold when it comes to copying languages (the old lex/yacc loop), and instead uses polymorphism in its sub-language design.

Both regexes, double quoted strings, and single quoted strings are examples of sub-languages in Perl 6. Each of these sub-languages has its own parsing rules and therefore parsing implementations. This allows is code reuse. Parsers can derive behavior from other parsers, but treat the tokens differently as necessary.

Fundamentally, Perl 6 is very simple. It has no CORE. It has no built-ins and no operators. What Perl 6 has given us (will give us?), in effect, is a just in time lexer. Tokens and their behavior can be defined on the fly, on a per-sub-language basis.

There are quite a few changes to the regularity of regular expressions. Mostly what this means is that Perl 6 regexes are incompatible with those used in Perl 5, and that Perl-compatible regular expressions (PCRE) aren’t (or won’t be).

All languages tend to fall into the One True Syntax trap. Perl 6 has aimed to break out of that trap. By giving the user enough power over the syntax (rope) to design the language that suits them (hang themselves).

I didn’t enjoy the State of the Onion as much as I have in the past. I suppose that’s to be expected. Larry did warn us at the top of the talk that it would be serious and contain only a single joke. For as great a writer as Larry is, his ability as a public speaker is lacking. That’s okay, though. I’d rather he not shift focus away from the design and development of Perl.

[tags]oscon, oscon08, oscon2008, Perl, State of the Onion, Larry Wall[/tags]

Sorry guys, these are five minute talks. If I start summarizing, I’ll fall way behind. You’re lucky I even take the time to write this.

If you really want to know what’s going on, there’s a schedule.

For those of you still reading, here’s a bit of stream-of-consciousness for you. Note, if trying to match these up to the schedule, they are in order, but I didn’t comment on all of them.

Testing databases with TAP is cool. You really can test anything with it.

Nice to see The Perl Foundation get some slots in Google’s Summer of Code this year.

It’s interesting to see how much Perl is used to compile USA Today every day. Without Perl, it would be a very empty paper. Though I’m not convinced the content would be much different.

Schwern tells us that, in thirty years, time will wrap.

$time = 2**31 - 1;
print scalar gmtime $time;

Tue Jan 19 03:14:07 2038

$time = 2**31;
print scalar gmtime $time;

Fri Dec 13 20:45:52 1901

Wait, that’s not good. But he’s fixed it.

Sweet, Perl on Google App Engine!

Use autodie instead of Fatal. It’s better.

Also, Paul Fenwick is one of the best speakers I’ve seen in ages. I hope he becomes an OSCON staple.

F*ck, the F*cking thing is F*cked had the best slides.

IPv6Experiment.com (warning: there may be porn).

[tags]oscon, oscon08, oscon2008, Perl, lightning talks[/tags]

Paul’s preferred title for this talk is Human Interfaces for Geeks. Most geeks think of things like keyboards, mice, and monitors when it comes to interfaces. But that’s not what this is about. Those are human-computer interfaces. We’re here to talk about human interfaces. Things like aural or visual communication.

Geeks can be quite awkward when it comes to interfacing with other people.

There are normal people out there who do make sense to geeks do make a lot of sense to geeks, Sims. They have wants, fears, and needs. These are easy to see, because they have status bars. Unfortunately, real people don’t have status bars.

One thing learned from the sims, if you want something done, ask a happy person to do it. They will be far more willing to do it and will end up being far more helpful. How do you make people happy? Coffee and chocolate will go a long way towards making people happy and giving a higher priority to your requests.

Even without this kind of base bribery, we can make people happy. By matching one of their goals to one of our needs. Humans, when they’re instantiated, have a set of default goals, and no one ever changes these. One of the best goals for this is a feeling of importance. How can you make someone feel important? Talk about them.

It’s easy to talk about someone. Practice active listening. Essentially, be an Eliza bot. Listen to what someone is saying, then repeat it back to them in the form of a question. If they’ve been on vacation, ask them about it. If they’ve accomplished something, ask them about it. This makes people very happy.

Another way to make someone happy is to make them feel important in front of their peers. If someone submits a patch, recognize that in front of the community. I did this once (because I’ve only ever received one patch for my one and only CPAN module). Someone from Australia submitted a patch and I put his name in the Changes file. I know I feel amazingly good when I’ve done a good job, so I do my best to point out when people have done a good job.

People, particularly in the United States, tend to look at situations in an adversarial way. When someone wants something and someone else is standing in their way, he will want to force his way past. This is rarely an effective method. Instead, those standing in the way are people, too. The best method is to take action to make that other person feel good about themselves. When they are happy and feel good about themselves, they are far more likely to go out of their way to help.

This was a good talk. Geeks rarely read books aimed at management types. A lot of these books place a lot emphasis on the concept of win-win and interpersonal communication. It’s nice to see a geek taking these lessons and putting them into terms other geeks can understand. We definitely need more geeks with people skills.

[tags]oscon, oscon08, oscon2008, people[/tags]

The Devel::DProf module is old and a waste of time and is broken. Stop using it. Take it out and shoot it.

The first obvious distinction between profilers is CPU time versus real time. CPU time tends to be highly granular, but doesn’t include I/O, context switching, or other kinds of blocking. That’s where real time comes in. It’s far more useful in the real world.

Tim, as with many of us, is interested in line-based profiling. It provides a high level of granularity The total subroutine time is not always useful, particularly in larger subroutines.

The NYTProf module is exremely fast, discounting the time taken by profiling overhead, making it quite a bit more useful for real world analysis. It also allows profile times per block, and can be aggregated up to the subroutine level. It’s a module with dual profilers: line-based and subroutine-based.

It gets better, every location that calls the subroutine keeps separate track of the subroutine time. This allows us to determine where the majority of the subroutine calls are coming from. For control flow statements, the decision expression is not taken into account when profiling the block that is executed. This is useful if the loop control itself takes time that should be discounted.

And that’s it for the description. Now we have half an hour to play with it.

The HTML-based reporting is inspired by Devel::Cover‘s reporting. Reported for each file are the number of statements executed, the time spent in the source file and the line, block, and subroutine reports. The subroutine reports include the amount of time spent within the subroutine and the amount of time spent in other called subroutines. The coloring of each line of the report—red, orange, yellow, and green—give a relative measure of deviation from the norm. Very impressive.

Even more impressive, Devel::NYTProf is capable of reporting exactly what a subroutine reference is called, even when it’s an anonymous subroutine compiled within an eval. With a handy link also provided, the called code can be easily inspected.

In summary, Devel::NYTProf is awesome. Use it. I know I will.

Tim Bunce is even more impressive than most people think he is. He is the only presenter I’ve seen so far who has managed to use IRC while giving his talk. Well, he didn’t actually type on IRC, but he had Colloquy running in the background. This particular IRC client uses Apple’s Growl feature to display notifications when you are mentioned in a channel. After he’s opened up the session to questions, one of those notifications pops up on the projected display:

<sirhc> Adam Kennedy (to Tim Bunce): Why are you so awesome?

It got a laugh, and Tim seemed to take it all in stride, even joking that he was not looking very professional on his screen cast. Important safety tip for session presenters, don’t leave your IRC client open.

[tags]oscon, oscon08, oscon2008, Perl, programming, profiling[/tags]

Pudge is, quite famously, a Republican, so he wants poor people to die, he asserts his right to shoot people who jaywalk, and he hates puppies. Now that we have that out of the way, this will not be a political talk. Instead, it will be a talk that just happens to use politics as the problem domain for which Perl was the solution (but isn’t it always?). Pudge happens to volunteer for the Republican party in Snohomish county, Washington. I actually know the area fairly well, as my grandmother happens to live there.

Winning elections is all about knowledge. And blackmail. But, mostly knowledge.

This session is essentially about data mining. There are a number of disparate data sources available with information about voters. From registration and voting history to contact information and preferences—can or can they not be contacted. This data is not always easy to access. For example, there is something called the Voter Vault, which is a super secret database of voter information controlled by the Republican party (there’s an NDA involved, so we won’t see any of it).

Essentially, Voter Vault is a really crummy Web application that only works for IE (hence the crummy part). That’s where WWW::Mechanize comes in. Using this brilliant module, data on any Web site can be retrieved, even if it requires a certain amount of user interaction to access. This, along with other sites, like the Washington State Public Disclosure Commission, provide all the raw data Pudge needs.

However, raw data is, by itself, not useful to anyone. This is the reason behind Pudge’s efforts. He uses Perl (and some JavaScript) to collect and aggregate all of this data. Then, once it’s all compiled, he can use a bit of Perl glue to use the data in Apple’s Address Book and Mail applications. But, more importantly, he can visualize it.

For the visualization, Pudge uses everyone’s favorite new tool, Google Maps. Using the Ajax API provided by Google, he can embed a map in his own Web application and, next to it, provide controls to enable and disable different views of the data on the map. For example, candidate donations by city and how much each candidate received.

It gets better. With the Google Earth APIs available to Google Maps, KML files can be generated (again, with Perl) to provide even better data visualizations. For example, precinct boundaries can be imported and colored based on voting history.

Initially, I wasn’t sure how I’d feel about this talk, but I ended up enjoying it. It was an excellent presentation on how to take data and display it to users in a useful manner.

[tags]oscon, oscon08, oscon2008, Perl, politics, visualization[/tags]

A computer once referred to a human worker who would perform calculations. This was a fairly easy thing to cluster and “run” several computers in parallel. As time progressed, more and faster work was desired. Enter the electronic computer, and specifically for this talk, the Cray. As with anything, the inner workings of the Crays of old can be recreated in Perl. Just use the Cray module, no problem (if only it existed).

After the history lesson, we move into high level overviews of parallelism and pipelineing, and a note about Amdahl’s Law. This was followed up with an example for detecting prime numbers by partitioning the work.

The slide presentation was over in under 20 minutes. Instead, we’re jumping straight into code examples. Awesome.

Or so I thought. Unfortunately, he’s been interrupted by multiple people in the audience, who keep wanting to move off into tangential conversations. Eric is having difficulty bringing the talk under his own control—it’s no longer his talk, but that of the somewhat rude fellow in the front row. Neither is Eric as eloquent when he switches from a prepared talk to demonstrating and explaining real code. It’s become far more difficult to pay attention to this session, and I find myself looking at the clock to see how much time we have until the next session.

For real fun, be sure to check out Brad’s post on Schwern’s session about skimmable code.

[tags]oscon, oscon08, oscon2008, Perl, programming[/tags]

Our first speaker this morning is Keith Bergelt of the Open Invention Network, speaking about Open Invention Network and Its Role in Open Source and Linux. He’s speaking about patents and intellectual property in Open Source, the realities of it today and where he sees it going tomorrow. He’s big on the buzzwords, and this is not the right audience for it. In fact, a game of Buzzword Bingo has already broken out in the IRC channel.

In summary, “Blah blah patent blah blah buzzword blah blah we care blah blah.”

Oh wait, he droned his way to a point. One of the things the Open Invention Network does, and I should have known because I’ve seen this before, is to buy up patents and keep Open Source safe from them. At least, until their funding dries up and they turn to their patent portfolios to squeeze money out of everyone.

I seem cynical this morning. Maybe I didn’t get enough sleep. Or maybe the first keynote today is boring. The back-channel conversation on IRC is actually quite entertaining, though. I need to whip up a quick IRC log file analyzer to correlate IRC traffic to keynote speaker. Then I can use it as a tool to rate speakers.

The pain is finally over, and the program chair has caught buzzworditis from the last speaker. Next up is Peter H. Salus to speak to us about Anniversaries. I’m told by Nat Torkington that Peter is an Unix historian. He’s started off by showing us a picture of the first transistor, which is about 20cm and a bit more than that around. It’s amazing to see how far we’ve come in 60 years—how many iPhones can fit in the same volume?

Anniversaries, in this case, are major milestones in computer history. The first electronic computer; the first time-sharing system; the first Unix paper by Ritchie and Thompson; the GNU project. One of the interesting things to learn is that history repeats itself. Back in the days of ARPANET, there was an issue involving the exhaustion of address space on the network. Short-sighted problems like that would never happen today, right?

I enjoyed this keynote speech, but probably because I really enjoy history.

Next up, Supporting the Open Web with David Recordon of Six Apart. It’s not just the open nature of the software or the platform that matters, but the openness of the data. Without open data, the Open Web can’t work. Interoperability and open specifications are vital to moving forward with the technology. The Web must be accessible, not just available on one device or another.

The majority of the talk is dedicated to talking about the various organizations doing work to keep everything free and open, including the Open Source Initiative, Creative Commons, and the Apache Foundation. There are also quite a few people donating a lot of their time to help.

He’s announcing the formation of the Open Web Foundation. They don’t necessarily want to form their own foundation, but they have had little luck finding an existing one to do what they’ve asked.

The Open Web Foundation will focus on four areas: incubation, licensing, copyright, and community. Many companies, such as Google and Yahoo have already shown support for this new foundation.

Following David is Danese Cooper of the Open Source Initiative and Intel Corporation to speak about Why Whinging Doesn’t Work. A catchy title, and she introduced her talk with a funny video of a choir of Finnish women singing about all of the complaints they have (search YouTube for “complaints choir“).

She’s making a very good point. There are so few women in Open Source. Geek are often intimidated by women and women are so often objectified. It’s true, there is a huge gender imbalance in the geek community. Of all the geeks I know, I can name very few women. I’m having a daughter soon, and you know what, she’s going to learn to code.

However, the feminist angle is merely a way of personally relating to the main point of her talk. People complain. I do it, you do it, the guy sitting next to you does it. But whinging doesn’t help. Mostly, all whinging does is beget more whinging. That energy used to complain needs to be channeled into something constructive.

For seven years, Danese was the only female member of the Open Source Initiative’s board. Now 30% of the board members are female. Progress.

Finally, Nathan Torkington, former OSCON program chair and recently of He Hononga Software, Limited and his keynote, fork() && exec(): Spawning the Next Generation of Hackers. Thank goodness, this talk is not about geeks having sex.

I’ve been looking forward to this keynote for a couple of reasons. First, I’ve missed hearing Nat speak this year. Second, I’m expecting my first child in a couple of months. Not only that, two other members of my local Linux User Group are either recent or expecting fathers. Suddenly, topics involving children are much more interesting to me.

Nat recently moved his family back to New Zealand. One of the things he does now is to help teach children about computing. In his school district, the computing infrastructure was awful—and used Windows. So he got a handful of Macs and became the Bastard Operator from Hell for his kids’ school. Then he started teaching the schoolchildren. Quickly, he discovered that the teachers needed teaching as well.

One more thing he wanted to do was to teach programming. He feels it’s a very important skill. But it has to be done right. Avoid the frustration that so many of us experience with computing and programming, but something consistent, easy-to-learn, but still powerful. Nat’s introduced Scratch. The kids loved it.

Lessons learned:

• Lectures suck (you have two minutes to say what you want)
• The gender gap is not what you think (girls are smarter and more focused than boys)
• Keyboards are a challenge
• Not a lot of experience with math
• Robots are lame

So please, volunteer in schools. Perhaps remove Windows and bring the joy of Linux to their lives. Find, or create, good courseware, such as Scratch. Post it on your blog, so everyone can find it. Finally, don’t profit. Do this for the good of the children, our future generation of geeks.

With that, we’re off to the expo hall for the break.

[tags]oscon, oscon08, oscon2008[/tags]

Sadly, yesterday during the morning keynotes, Al was called back home abruptly. Hopefully, he made it back to the UK quickly and safely.

After all the sessions were said and done for the day, we found our way to the expo hall, where beer and appetizers were being served. Alas, we did not stay long. We caught wind that Google would be hosting pizza across the river at Old Town Pizza, an event we never made it to. It turned out to be a pizza dinner for Summer of Code participants. We finally ended up at Rogue for dinner, and I finally got myself a growler for my collection—currently being held (safely?) in Brad’s hotel room refrigerator.

After dinner, we swung by the supposed Amazon party. Only, there wasn’t one. It was only held between 8:00pm and 9:00pm. Seriously? This is how Amazon throws a party?

Fortunately, the Sun party was a better this year. First of all, they had no stupid lolspeak flyers. Second, bottled beer instead of kegs, which is difficult for incompetent bartenders to over-prime and serve nothing but head. Third, sumo wrestling! Brad and I also participated; those photos are coming soon, I promise.

However, as I actually enjoy attending the keynote sessions—scheduled far too early in the morning—I was back in my hotel just after 11:00pm. I ran into Dan and his fellow TierraNet colleagues in the hotel bar. Unfortunately, I had missed last call, but I sat down for a bit anyway. We had some laughs with Margaret, the bartender. I tried to get her to slap Tyler, but sadly it never happened.

Today’s session tracks begin with a dilemma. Unfortunately, I’d like to be in three places, simultaneously.

• Skimmable Code: Fast to Read, Safe to Change (Michael Schwern)
• Open Source Microblogging (Evan Prodromou)
• Stick a fork() in It: Parallel and Distributed Perl (Eric Wilhelm)

Fortunately, Brad wants to go to Michael Schwern’s talk, so I’ve agreed to attend Eric Wilhelm’s talk. We’ll write summaries and both be happy. The microblogging session was just a curiosity for me anyway.

The rest of the day won’t require quite as much rolling of dice.

• Perl for Political Campaigns (Chris Nandor)
• Ultimate Perl Code Profiling (Tim Bunce)
• Hacking Wetware for Fun and Profit (Paul Fenwick)
• Perl Lightning Talks
• State of the Onion Address

The only potential conflict is during the second half of the Perl lightning talks, A Tasting Tour of Haskell (Bryan O’Sullivan).

Just about time for the morning keynotes, and I’m looking forward to seeing Nat Torkington speak. If I can reconnect to the wifi network, I can even post this entry.

Paul has started out by describing the world’s oldest computer in terms of modern computing.

From there, he’s providing examples of major computing and engineering failures throughout modern history. It’s amazingly entertaining. I can’t summarize it. If you’re not here, you fail. I’m just going to sit back and enjoy it.

[tags]oscon, oscon08, oscon2008, history, failure[/tags]

I work for a small telecommunications design company, so this venture into Linux on mobile platforms holds quite a bit of interest for me. Granted, I work in a support capacity for the folks who do real work, but knowledge is always a good thing, right?

Intel has chosen a Fedora- and GNOME-based platform for Moblin. I’ve contributed a couple of packages to Fedora, which means users of these Intel mobile systems can play Zork.

Dirk wasn’t able to have any sample devices with him, so he was left to describe what a “net book” is. Fortunately, in a room full of geeks in a mobile computing presentation, several people had ASUS EEE PCs, which he could show off to the audience. There were also a Nokia N800, N810, and of course several iPhones in the crowd. Obviously I mobile-savvy audience.

Linux is often touted as the obvious first choice for these mobile devices because of its price. One of the more important reasons is the ability to strip down Linux so much to fit on these devices, but still be incredibly usable.

This session ended up being exactly what I thought. It’s essentially a marketing spiel masquerading as a technical talk. The slides are far too slick, and the only reason any technical details are being given at all is because of the last-minute speaker substitution. Our new speaker is a technical guy who has been promoted to a managerial role. The presentation was apparently designed by a marketing guy with enough technical knowledge to be dangerous. I hope Brad is having more fun in the Moose talk.

I’m really regretting where I’ve chosen to sit. Someone in front of me is wearing way too much pungent cologne. I may be sick.

[tags]oscon, oscon08, oscon2008, Intel, Moblin, mobile, Linux[/tags]

There are a multitude of troubles with using a proprietary operating system, as anyone attending OSCON is familiar. From cost to forced upgrades to vendor lock-in. Suddenly, companies are at the mercy of the vendor, and have lost so much of their own self-direction.

Not only has John’s company benefited from the Open Source community, they’ve contributed back to the community. That’s key, I feel. I’d like to see my own company contribute much more than they do.

I’m not sure who this talk was targeted for. It wasn’t really a good sales pitch to business-type people, and it wasn’t very high level for IT-type people. I don’t know what I expected from it, but I don’t think I got what I wanted out of it. Most of the challenges they faced, we’ve already solved. We’ve already created a standard image and can already deploy it on standard hardware. We already have Windows virtual machines for anyone who still needs to run Windows applications. We already have enough management buy-in for the project, too.

I do, however, like the sound of this “seamless RDP” he talked about. I will need to investigate it further. Also, it’s refreshing to hear from someone who has successfully (mostly) removed Windows from their enterprise.

[tags]oscon, oscon08, oscon2008, Linux[/tags]

my $code = qq{
    print 1+1 . "\n";
    $code =~ m/(\d+)\+(\d+)/;
    $new = $1 + $2;
    $code =~ s/\d+\+(\d+)/$2+$new/;
};

for ( 1 .. 10 ) {
    eval($code);
}

What’s the first bug? Yes, it should use q{}, or the variables will interpolate on the initial assignment to $code. To their credit, they initially used single quotes, but people said it was too hard to read.

I wasn’t content with just figuring out what the code did and fixing a small bug. I think it can be written better.

eval($code = q{
    print 1+1 . "\n";
    $code =~ s/(\d+)(\+)(\d+)/"$3$2" . ($1 + $3)/e;
    eval $code;
});

Much better. Not only is it more concise, I was able to remove that pesky loop, so I wouldn’t be bothered by any silly upper bounds.

So what does it do? Should be obvious. Head over to the Amazon booth and let them know.

Nearly everyone agrees that code reviews are a good idea, so why aren’t they done more often? In fact, this is the very same problem we’ve had at work. We’ve been talking about code reviews for two years, but we’ve never had one.

There are some barriers to entry to doing code reviews. If revision control is not in use or automated tests aren’t being run, tackle those problems first. Also, the need for a team process is necessary, from ticket tracking to release plans.

Pair programming, that tenet of XP, is a poor substitute for code reviews. Two people working together will not magically turn one or the other into what is essentially a disinterested third party, who may catch bugs simply because they weren’t there when it was written.

Test-driven development is also a great way of coding, but not a substitute for reviews. Often for the same reasons. Tests are often just more code and the code tested is only when someone thinks to test it.

Even during a code review, a reverence for authority can get in the way of getting things done. A poor, intimidated programmer may not have the courage to criticize a more senior programmer. Instead, this can be turned around with something I use a lot myself. I like to call it, “playing dumb.” Instead of saying, “this won’t work,” ask what will happen for a suspicious case.

Socially, the only way for code reviews to work is universal buy-in. Everyone is subjected to code reviews by everyone else. No exceptions. Make them a habit, a regularly-scheduled meeting. At work, I’ve even suggested bi-weekly, or perhaps monthly, catered, lunch time code reviews. Just to get us into the habit of doing it.

Code review time should not be wasted on things such as code formatting, best practices, or test coverage. This is stupid. These are objective tasks that can be automated.

Instead, look for subjective things, which can’t be automatically found. Such as code readability, algorithmic clarity, and consistent identifier naming. Other targets for code reviews are the usual things we here over and over again as development best practices: consistent documentation that follows the internal standard, that kind of thing.

The remainder of the talk is essentially an enumeration of all the things to look for in code reviews. All of them are, at least to me, common sense. So I’m not going to spend any time writing them down. If you don’t already know them, well go find some common sense.

One thing that he recommends that I like is code reviews by e-mail. It’s an old, well-understood, and (usually) reliable tool. So why not combine e-mail with a version control system—particularly one of the newer distributed version control systems—to perform out-of-band code reviews. It actually sounds like a good idea to me, and I’ve done it at work a couple of times with code written by an intern.

What I’m starting to notice is that many of the later the recommendations for reviewing code are personal opinions of the presenter. I think the way in which code reviews are performed are highly dependent on what works best for the group reviewing code. It’s like so many things, from cameras to backup solutions: the best one is not the shiniest or the one with the most bells and whistles, it’s the one that’s actually used.

[tags]oscon, oscon08, oscon2008, programming[/tags]

Erlang is a pure functional language (and thus no side-effects) with strong dynamic typing and syntax similar to Prolog and ML. Most notably, it contains concurrency primitives, which is what we’re here to hear about today.

Erlang concurrency primitives include spawn, to create a process, !, to send a message to a process, and receive, to listen for a message. These are not system level processes, but other Erlang processes. It’s a lot like using fork in imperative languages, but less messy.

Erlang, like many functional languages, can implement quick sort in three lines of code. I was having a discussion with a friend of mine about this topic yesterday. It’s very nice, and demonstrates the power of functional languages to trivially solve an already solved set of problems, but is it any use in the real world? Maybe. While I’ve not seen any non-trivial examples, I’m reserving judgment.

The first example is a demonstration on how simple it is to parallelize the quick sort algorithm. It’s not a worthwhile example, in fact, it’s a particularly bad idea, but it serves as a reasonable example of the ease of use of the concurrent features in Erlang. So far, it seems like changing a map call—something I love from Perl—to pmap.

The pmap function is not a built in function (BIF), but a library function built on top of the built in concurrency primitives. The code implementing the function is actually quite simple, and should be available in the slides available at the end of the conference. Conceptually, it spawns as many processes as necessary and uses them to call the function being mapped. It then gathers the results, waiting for each process to complete. It’s quite similar to code I’ve written to do scientific processing using MPI, but I’ve always thought functionally when coding.

After explaining concurrency, we make the jump to distributed systems. What’s everyone’s favorite distributed system? Twitter! Twitter, while not designed as such, is essentially a messaging system. Erlang does message passing very well, and almost all programs are designed using this paradigm. So Kevin took a stab at implementing a Twitter-like system in Erlang, the key ideas of which he will present to us.

The lightweight and convenient process architecture of Erlang lends itself to the problem. Every user can be represented as a process. Each process can then send and receive messages. In effect, the problem—the messaging part anyway—is now solved. But, what about scaling to multiple machines?

It turns out to easy (but you knew it would, right?). All we need to do is pull in the global module and we can bind our users not only to a process identifier, but combine that with a given machine as well.

However, we still don’t have a reliable system. If a process dies, that user is no longer in the system. So it really is a lot like Twitter.

OTP, the Open Telecom Platform (a legacy name from Erlang’s history at Ericcson), provides a set of common behaviors and patterns for writing reliable and distributed system. The programmer simply declares what interface they would like to use, then implement a set of callbacks defined for that behavior. Reminds me a bit of roles (because I have an unhealthy need to relate everything back to Perl).

As with everything in Erlang, it is almost impossibly easy to set up this reliability. I still can’t get over how well the syntax maps to how I actually think about code.

A question was raised about how to go about setting up the necessary cluster of hosts used in Erlang’s mesh network. Kevin went into it briefly, but it’s unfortunately out of scope for this session.

And, with that, it’s time for lunch. Thanks, Kevin!

[tags]oscon, oscon08, oscon2008, Erlang, concurrency, programming[/tags]

Recently, Adam has been funded by The Perl Foundation, Perl in Israel, and Stonehenge to use Perl from nothing but his flash drive. This provides an excellent motivation to get Strawberry Perl working in a highly portable way.

Originally, Perl was awesome and worked everywhere—except Windows. That was okay, because Windows didn’t matter. No one did any real work on Windows. Then, around 1995, Windows started to matter. A brief history of Perl on Windows followed, resulting in what is today ActiveState.

Much of what Adam wrote for PPI does not work in ActivePerl, which makes it a non-starter for him, as he tends to work on Windows. Anything depending on Scalar::Util or List::MoreUtils modules will not work with the ActivePerl build system. This led to an embarrassing problem for Adam when he gave a talk three years ago at OSCON. He couldn’t give his demo, because PPI would not build in ActivePerl. In fact, ActiveState’s package manager has gotten so much worse that almost any module that is at all useful does not exist—and thus nothing useful can be done on Windows (big surprise).

Moving away from ActiveState, this talk is essentially about Adam trying to get his own laptop to work. That’s really all he wants. It’s a modest desire. More importantly, the CPAN module has to work. Without that, what’s the use of Perl?

So Adam offered a prize: a yard-high stack of cases of any beer desired by the first person who could provide a fully-installable and working (by the above definition of working) version of Perl for Windows. After six months and no sign of a winner, he changed the prize to “craploads” of beer. In 24 hours, he received two entries. The winner cheated a lot, but the loser was Vanilla Perl, which has become a testing ground for experimentation.

Strawberry Perl is the Perl for Windows designed for people who don’t use Windows. That is, the people who do all of their work on Unix or Unix-like systems—Linux, Solaris, and Mac OS X. The main goal of the project is to make it easy—it is Perl, after all.

In the future will come Chocolate Perl—completing the holy trinity of neopolitan flavors—for people who know Windows, but don’t know Perl, and thus the Unix-like characteristics of Perl.

The target of Adam’s financial support is Portable Perl: Perl for flash drives. Carry it around, install CPAN modules onto, or from, the flash drive. It’s network-aware, does the right thing, and juliennes fries. An excellent standard being developed for portable apps is, in fact, PortableApps.com, where applications such as Firefox or Putty can be downloaded and installed to those ever-growing flash drives.

Available Thursday at the Perl Foundation‘s booth in the expo hall will be branded flash drives with Portable Perl on them. At least, I think I heard that correctly.

I really like the work Adam is doing. He’s accomplished so much to get Perl everywhere. That’s a cause I can get behind.

“The main problem today is Vista.”
— Adam Kennedy

Okay, I took that out of context, but I couldn’t resist capturing the quote. What he really means is that changes made to Windows in Vista have made things not work, in particular the access control. It’s not an unusual problem when upgrading to new systems, but it is more difficult with proprietary platforms, which Open Source authors have very little access to.

Allison is back to tell us that the morning break will be sponsored by Intel, and lunch is sponsored by Google. That gives me some hope for a decent lunch, at least. Don’t let me down, Google.

Next up, Tim O’Reilly with an update on Open Source on the O’Reilly Radar. He started out with an overview of the history of this conference, in particular the predecessors: the Freeware conference, and the Perl conference.

He offers an important safety tip: keep your history. Be an e-pack-rat. Some day you’ll look back and appreciate that you have it. It’s like the photo album on the coffee table. It’s the story of us and how we became who we are today. So keep everything. Please. Even if it’s embarrassing. Those are always the best memories, the ones that make us laugh.

The big point he’s here to make today is how big Open Source has come in the last decade. But, don’t become complacent. There are three big challenges and opportunities coming up: cloud computing, the (open) programmable Web, and open mobile.

Cloud computing is on the tip of everyone’s tongue today. From Amazon Web Services to Google’s App Engine. Individuals and start-ups now have the ability to build applications on top of these wonderful, decentralized, and most importantly cheap platforms.

Web does not mean “http.” It is, in fact, the entire Internet, the “web” of systems that communicate and inter-operate. There are Web applications that provide platform-agnostic solutions, but there is also XMPP, mobile devices, and even non-Web APIs for those very Web applications that are often so impressive.

“The Web is 72 subsystems in search of an Operating System.”
— Tim O’Reilly

Data is the value-add by so many of the so-called open web companies. While the APIs are open and the data can be queried, the data itself is owned by the provider, to do with as they please. We need a truly Open Web Platform. Apple, as popular as the iPhone is, has created an essentially closed platform. Google, with Android, understands this. Without a truly open mobile platform, all of Google’s market share could potentially disappear overnight.

Back to Allison who introduced our next speaker, Christine Peterson. She takes the stage to tell us about Open Source Physical Security: Can We Have Both Privacy and Safety?

We passed up an opportunity with “e-voting.” The Open Source community should have been able to rise up and solve that problem. I’m not sure how or in what way. I’ve had many discussions with friends on the subject, and we’re still not convinced that computers are even a good idea when it comes to voting.

This is the political activism segment of the conference. That said, she brings up very real concerns. There are very real reasons to care about detecting weapons or other hazards. But, the very same technologies, in particular surveillance, that are used to defend against very real dangers can be used—abused—to monitor law-abiding citizens.

Terrorism is a “bottom-up” problem, which the state is attempting to solve with “top-down” solutions. We need so-called bottom-up solutions. The solutions that involve the very same openness, security and privacy that the Open Source community is already so concerned about and already so vocal about.

The take home message, if there is one, is that all this public sensing data and the information they gather should be open. Our elected officials (this is a very US-centric talk) are well-meaning, but do not have the tools or the knowledge or the experience to really understand the need for all of this to be open.

“No secret software for sensing public data.”
— Christine Peterson

Allison came back on stage to introduce our last, but certainly not least, speaker, Dirk Hohndel, Intel’s Chief Linux and Open Source Technologist. He’s here to talk about Moblin, Linux for Next Generation Mobile Internet. Given that I work for Qualcomm, this is, or at least should be, a very interesting topic for me (I work in support of the engineers, who do the actual work).

Intel is putting their money where their mouth is with Moblin (Mobile Linux, get it?). There is a new class of computers on the market, which have become affordable for the mass market: ultra portable notebooks, hand-held tablet computers, and “smart” phones. The driving force making these devices so successful is the Internet. They are connected and our data is accessible from anywhere.

But what about vendor lock-in of the platform and the data. Intel believes that the platform should be open. This is where Moblin comes in. It’s Intel’s idea of an open platform and an open software stack, allowing the community to develop applications and create new systems and services.

It’s excellent preaching to the choir, but I suspect that from a business perspective, it’s also a way of getting other people to do work for free and really get entrenched in the mobile market. After all, Intel is not the giant in the mobile space the same way that they are in the server, desktop, or notebook spaces. In fact, Qualcomm has a very impressive microprocessor, called Snapdragon, targeting the mobile market (shameless plug).

Allison is back, once again introducing Tim O’Reilly, who will be talking to Monty Widenius and Brian Aker about their work with MySQL and the acquisition by Sun Microsystems. This is a Q&A session, and I always find these difficult to blog. With any luck, a summary or transcript will be posted to the O’Reilly Radar site.

That brings us to the end of this morning’s keynotes. I’ll drop by the expo hall for a few minutes before my first session. But first, I really need to find a restroom.

Oh, Brad also wrote a few words about the keynote.

The morning keynotes begin in approximately 45 minutes. After that, I have only a vague idea of which sessions I’d like to attend. My current line up looks a little like this,

• Strawberry Perl: Achieving Win32 Platform Equality
• Beautiful Concurrency with Erlang
• Perl 6 Update
• Rakudo: Perl 6 on Parrot
• Moose: A Postmodern Object System for Perl 5
• An Illustrated History of Failure

Of course, any of this is subject to change without notice.

Originally, I hadn’t planned on arriving at the keynote until 9:00pm, when Damian Conway is schedule to speak on Temporally Quaquaversal Virtual Nanomachine Programming In Multiple Topologically Connected Quantum-Relativistic Parallel Timespaces…Made Easy!. I mean, granted, I’m sure I already know all there is to know about it, but it still might be a little interesting.

Anyway, the keynotes got started with Mark Shuttleworth, the founder of the Ubuntu project. He’s here to speak to us about “Free software and the art of software engineering.” It (whatever “it” is) boils down to three things: innovation, methodologies, and economics.

Innovation. Society has a responsibility to stimulate it. Innovation is extremely non-linear and the key to this is disclosure, as is done in (or was once done in) academia. Free Software is the scaffolding for innovation. The real successes are accessible. The Mozilla products are examples of wildly successful open platforms, with the extension architecture they have provided.

Methodologies. The purpose of methodologies is to organize talent. How is Free software changing the direction of these methodologies. The Free Software people, that is us, are organized and motivated by interest. A second driving factor is that developers are almost never located near each other, so things like pair programming completely fall apart. Creating architecture for collaboration and participation is essential to the success of any Free Software process. While a common set of tools can never be forced upon the community, the ability for a diverse set of tools to communicate with each other is vital.

Economics. It is the combination of the technical change and innovation in economics that really moves the world forward. For example, we had the Web for years before the business models started to spring up around it and really drove us forward, both technologically and economically. Today, there is an increasing use of online services, which both drive technology forward and allow platforms to work together, and more often than not, these services are built on Free Software.

Our great task over the next two years is to lift the Linux desktop from something that is stable and works and is not-so-pretty, to something that is art. At this point, someone started clapping, and a couple of people joined in. As Jaime Zawinsky once said, “We should design software that helps our users get laid.” But really, we need to make software that is phenomenally useable, beautiful, and functional.

Next up, Chris DiBona, the Open Source program manager at Google, joined Allison on stage to present the Google O’Reilly Open Source Awards.

Next up, with Exceptional Software Explained: Embrace Error is Robert “r0ml” Lefkowitz. He is fast becoming one of my favorite speakers. He’s here to talk about software development methodologies in Open Source. This talk is almost a sequel to one he gave last year, An Open Source Lexicon. He has a real penchant for language, particularly classical language, and how to apply it to themes in the Open Source community. Unfortunately, because of this very quality, it’s extremely difficult to write about it as he speaks. It’s hard to summarize as he speaks, and he’s far too entertaining to chance missing what he’ll say next.

Josh McAdams then took the stage to continue the long standing tradition—10 years now—of the White Camel Awards. So here’s something I don’t understand. What is it that drives people to design award trophies that have a high potential for lethality? Honestly, don’t run with them. They’re worse than scissors.

Finally, it’s time for Damian’s keynote. But you know what? I’m not going to miss any of it to write about it here. If you missed it, well, you should have been here.

Over 90 people registered for this tutorial, and the room is almost full. Save for the handful of available chairs, I’d feel guilty about auditing it instead of attending the Real Time 3D on the Web with Open Source I had originally registered for. This will be a two and a half day course compressed into three hours. Should be fun, and useful for Kevin’s session tomorrow, Beautiful Concurrency with Erlang. After seriously considering the relative merits and general usefulness of the tutorials, I decided Erlang would be much more interesting. I had made my original choice with the equivalent of a dart board, so I don’t feel too bad about changing my mind.

The tutorial started with a quick tour of Erlang’s syntax. It looks odd, but I’ve used Lisp and ML in the past, and I’m a rather good Perl hacker, so it isn’t proving too difficult to pick up. The concept of pattern matching intrigues me. It appears to use equivalency, in the mathematical sense to handle both boolean and assignment operations with the same syntax. For example,

[A,B,C] = [1,2,3]    % A is 1, B is 2, C is 3
[A,B,C] = [1,2]      % error, size mismatch
[A,B,A] = [1,2,3]    % error, A already bound to 1
[A,B,A] = [1,2,1]    % okay, A bound to 1, then equivalent to 1

Shortly into the discussion of syntax, Francesco asked that anyone who hasn’t yet installed Erlang do so. I executed yum install erlang, which pulled in unixODBC, tcl, and tk as dependencies. Well, 45 megabytes and 45 minutes later—an impressive speed of 1 MBpm—I now have Erlang installed and ready to run. Just in time for a 10 minute break.

During this first break, we were asked to do a simple exercise in Erlang: write a module, boolean.erl, that implements b_not(), b_and(), b_or(), and b_nand(), without using the built in logical operators. I’ve been able to define the structure of the module, but I don’t know how boolean values are represented in Erlang, so I may have to wait until he gives us the answer. Vim’s syntax highlighting tells me that true and false are reserved words, so I can use those.

The solution for this involves writing a simple truth table. In Erlang, functions are subject to pattern matching in the same way that many programming languages allow for function overloading. For the logical or, we start with the basic truth table:

b_or(true,true)   -> true;
b_or(true,false)  -> true;
b_or(false,true)  -> true;
b_or(false,false) -> false.

That’s downright simple and extremely easy to grasp on a conceptual level, particularly for anyone with any background in mathematics. However, and this appeals to me as Perl hacker, Erlang allows the programmer to be lazy, but in a good way. The null variable—as I’m calling it due to the analogy with /dev/null on Unix-like systems (or undef in Perl)—_, allows a kind of lazy matching:

b_or(false,false) -> false;    % the only false case with OR
b_or(_,_)         -> true.     % any other case is true

The other functions can be written in a similar way.

Back from the break, and the population of the room has thinned very slightly. Francesco immediately jumped into conditional evaluation, starting with the case clause. I suspect this may be one of the answers to the exercise. He followed that with the if clause. I find it interesting that he’s done it in that order. In most languages, the if statement is a much simpler case (no pun intended) and is covered first, before moving into more complex territory. I think I understand why, the two clauses are implemented in a very similar fashion. I’m not sure how equivalent they are, I’d have to play with them a bit.

As with any functional language, Erlang has strong support for recursion as well as a handful of built in functions (BIFs) implemented in C to accomplish things that are difficult or impossible to do directly in Erlang. After all, at a certain point, things like date and time require system calls. Also available are convenience functions to do things like convert tuples to lists or back.

At the second, official, break—taken after an official entered the room to scold Francesco for being 15 minutes late—we were presented with two more exercises. First, to write a function, sum/1, which, given a positive integer N, will return the sum of all the integers between 1 and N. As an extension, write a function, sum/2, which, given two integers N and M, return the sum of the interval between them, first ensuring N <= M. Second, write a function, create/1, which will return the list 1 through N given N as its argument. As an extension, write a function, reverse_create/1, which does the same in reverse.

As I suspected, both exercises are perfect candidates for recursion, which is quite simple to do in Erlang:

sum(N) when N > 0 ->
    N + sum(N-1);
sum(0) ->
    0.

The simpler list creation function is actually the second, and is solved similarly, but by accumulating a list instead of adding to a sum (which is, actually, also a method of accumulation):

reverse_create(0) ->
    [];
reverse_create(N) ->
    [N|reverse_create(N-1)].

The first thing I notice is, again, how mathematical Erlang is. The solution is written in exactly the same way I do it when I’m jotting down notes while thinking about how to solve the problem. To me, the syntax is quite elegant.

After going over the solutions to the exercises, we moved into concurrency. As with most languages worth using, Erlang has a spawn() BIF, used to create processes. What’s interesting about spawning processes in Erlang is that the function to do it does not take a system command. Rather, it takes another Erlang function to run. It’s quite a bit more elegant (there’s that word again) than the equivalent fork() dance done in most imperative languages.

Communication between Erlang processes is done via message passing; data is never shared. As with everything else, the method for doing so is quite elegant: Pid2 ! {self(), foo}. Okay, maybe someone has to be me to find that elegant.

The whole process concept in Erlang is quite nice and, again, elegant. It’s plain that it is the primary method by which systems in Erlang are designed. So far, though, we’ve only seen trivial examples. That’s okay, because this is only a three hour tutorial. However, as Larry Wall once said about Perl: It makes the easy things easy and the hard things possible. It’s a good litmus test for any language. It’s far too early for me to pass any judgment on Erlang. I’d like to use it in anger sometime, to see how it performs for me. Perhaps I can get my local Perl Mongers interested in chatting about it.

Most of us are, of course, aware of the concept of best practice when coding. Writing code that’s maintainable, predictable, and follows the rules. Oh, and uses Java.

Worst practice is, by contrast, code that is obfuscated, unmaintainable, and breaks all of the rules. Today, we will be studying code that Damian has submitted to the Obfuscated Perl contest. This promises to be very, very scary.

Damian’s entry to this contest was SelfGOL, a program capable of self-replication, rewriting other Perl programs to themselves self-replicate, detecting un-rewritable programs, playing Conway’s “Game of Life,” and, as if that wasn’t enough, animating any text as a cycling marquee banner. The main constraint of the contest is that the entry must be under 1,000 bytes of code, so it shouldn’t be too difficult to understand. Obviously it doesn’t use any modules, because that would be too easy. Not only that, but it doesn’t use a single control structure. This is going to be great.

Following an amusing demonstration of SelfGOL, we moved into treating it as a case study for a set of principles. Principles that will focus on the very practices SelfGOL embodies, and why they should never, ever be used. As I intend to enjoy the discussion, I won’t spend much time writing about the discussion and examples accompanying these principles, but rather simply note the principles for my own benefit (documentation for the win). After all, sharing all my new tips and tricks would suck all the fun out of it.

Principle 1: Sane and consistent layout makes code more maintainable (but it isn’t a magic bullet if the code itself is beyond help).

Principle 2: Using built-in features isn’t necessarily smarter or cleaner (even though fellow developers’ futile struggles to recall those features can be highly amusing).

Principle 3: Obscure obsolete features are obscure and obsolete for a reason (and restasking them for even more obscure purposes is not helping).

Principle 4: Each statement should do one thing only (since that’s the upper limit most brains can comprehend).

Principle 5: Relying on default behavior makes code very slightly easier to write and vastly harder to read (because most readers can see better than they can think).

Principle 6: Randomly placed subroutine definitionss are static (in the radio interference sense).

Principle 7: Choose data structures that simplify your task (even if the task is to make those data structures incomprehensible).

Principle 8: Just because you use some operation frequently doesn’t mean it should be in a utility function (especially if it’s in a function merely to abbreviate its name).

Principle 9: Encapsulating the familiar can decrease maintainability (refactoring isn’t a substitute for sanity).

Principle 10: Treat any clever one-line solution as an alarm bell (or as an antipersonnel mine with a six-month delay fuse).

Principle 11: Familiarity breeds comprehension (it breeds contempt (but hey, what’ doesn’t?)).

Principle 12: Table-driven solutions are clean, efficient, and extensible (as long as you don’t mind losing a little comprehensibility).

Principle 13: Building a messy data structure and then cleaning it up is often easier than building it cleanly in the first place (and to hell with the purists).

Principle 14: Some code is better compiled at run-time (but the urge to use eval is Nature’s way of letting you know there’s not yet enough pain or misey in your life).

Principle 15: Parentheses are our friends (cos, if you can remember all 24 levels of Perl’s precedence, you gotta get a life, dude!).

Principle 16: Edge cases suck (and edge cases of familiar constructs suck worst of all).

Principle 17: Code should do what it seems to be doing (especially when it seems to be doing something subtle).

Principle 18: Conceptual elegance is no guarantee of actual maintainability (nor a good substitute for it).

Principle 19: If you’re going to have default values, define them near the place they may actually be used (or, at least, somewhere they have a slim chance of being discovered).

Principle 20: No matter how good you think your error messages are, they’re still too brief, too obscure, and too hard to decipher (even if you’ve already taken Principle 20 into account).

Principle 21: Avoid using obsolete and arcane magic punctuation variables with unfamiliar default values and unexpected global effects (even if you happen to enjoy a little self-inflicted pain in other recreational activities).

Principle 22: The fundamental complexity of any problem is irreducible (optimizations merely redistribute the pain differently).

Principle 23: Code that breaks when it’s reformatted is already broken (though on a much more profound and interesting level).

Principle 24: If it’s impossible to understand, it’ll be impossible to maintain (on the bright side, of course, such code is highly stable).

This last one should, but often doesn’t, go without saying.

Principle 25: Phenomimetic retrodeterministic nominativism generally does not improve code comprehension (then again, did it sound like it would?).

Principle 26: Don’t allow dynamic behavior to violate static expectations (and the easiest way to do that is reusing over-scoped variables for unrelated purposes).

Principle 27: Explicit behaviors are better than implicit behaviors (especially when the specification of the implicit behavior is syntactically baroque and hard-to-spot, and the behavior itself is unknown to the majority of developers).

At this late point of the tutorial, Brad pointed out to me that all of these principles are in the included materials. Now that I’ve already transcribed so much from the slides, I don’t have the heart to delete it all. Of course, since I haven’t been commenting on all of the black magic to this point, there would then be very little in the end to post. Brad also has a much better post about this tutorial, since he actually took real notes.

Principle 28: Code that pre-caches or precomputes its data is much easier to maintain than code that caches or computes on-the-fly (when you’re running at multiple gigahertz, acquiring your data a few thousand operations early is still plenty JIT enough).

Principle 29: Coding is an art, but code shouldn’t be art (evolution made programmers boring, pedestrian, and aesthetically challenged for good reasons).

It’s mesmerizing to listen to the thought process behind Damian’s obfuscated code. I can’t help but wonder if this well-organized, well-thought-out explanation is anything close to how Damian designed this program. Or, rather, if there are extremely convoluted, scary, and most importantly, evil gears grinding away inside his head. In fact, I suspect this entire tutorial may have been designed purely as a way of documenting SelfGOL so Damian himself can remember how it works. Clever.

This kind of programming is silly and fun, but it serves a real purpose. Pushing the limits of a language teaches about its dark places. The understanding that comes from it vastly improves the skills of the programmer, even if—especially if—the bad things are never, ever used. Perl, even more than other languages, encourages this kind of play, thanks to its rich diversity and culture.

Important safety tip: keep these tricks and contrivances for recreational purposes only.

I don’t know what’s more disturbing, how much of the tutorial I understood, or how much I already knew coming in.

[tags]oscon, oscon08, Perl, Damian Conway[/tags]

I have a fun day lined up. This morning I will attend Perl Worst Practices in Portland 252. I’m looking forward to this tutorial, particularly because it’s being taught by Damian Conway. I—as well as my boss, I’m sure—am excited about the prospect of putting these practices to work when I return to my job next week.

After the lunch break, which will probably be spent across the river again, I am signed up for Real Time 3D on the Web with Open Source in E143/144, being taught by Matthew Edwards. I’m not sure what to expect from this session. A week prior to the conference, I received an e-mail instructing me to download a set of programs, including Blender and Inkscape. This is well out of the ordinary for me, so I’m not sure what to expect. I hope it will be fun, but if not, I may duck out and into the Practical Erlang Programming in Portland 256, which Al is attending.

A half hour now until my first tutorial. Time enough for more coffee.

We started the night at Kells Irish Restaurant and Pub on the other side of the Willamette. The hostess there was extremely attractive, even if some in our party made note of how young she appeared. As it’s rude to ask a woman her age, I refrained from doing so. After a few beers and sweet potato fries, we needed to find food. So we decided on Italian, and Mama Mia Trattoria fit the bill. Near the end of dinner, I received a text message from Dan. He and his fellow Tierranet attendees were at Paddy’s Bar and Grill. So we made our way over there for a few more pints.

We called it a night before the MAX stopped running, and made our ways back to our respective hotels. Dan and I happen to both be staying at the Marriott and, as we passed by the bar, we saw his fellow coworkers. Not only that, but the barmaid, at that very moment, announced last call. Not wanting to pass up such a coincidence, Dan and I sat down for another pint.

Not satisfied with the early hour, Dan and I decided to walk down to American Cowgirls, a bar across the street from the Oregon Convention Center. Unfortunately, the bar is closed on Sunday and Monday, so we ended up calling it a night and heading back to our rooms.

Ah, but it’s only Monday night, and OSCON runs through Friday. It will be a good week.

“A computer is secure if you can depend on it and its software to behave as you expect.”
—Simson Garfinkel and Gene Spafford in Practical UNIX & Internet Security

In a nutshell, that’s what security is. If a computer behaves as expected, it is secure. That is, unless it’s expected to be insecure, I suppose. I’m not sure I’d enjoy that situation, so I’ll assume the assumption of expected behavior is both expected and secure.

Most security boils down to common sense. Unfortunately, this mythical state of being is far less common than its name would imply. Sad, but true. People are often lazy or distracted, and these usually lead to really stupid mistakes.

There is a key acronym when thinking about security: CIA. No, not that CIA. Yes, I thought so, too, at first. What it really means is, Confidentiality, Integrity, and Accessibility. Confidentiality, because information will not remain secure if it does not remain confidential. Integrity, because information must remain known and trusted to remain secure. Accessibility, because denial of access to information may result in insecurity. I may not have done justice to this acronym, because the tutorial moved on quickly after this point. I’m sure there are web sites dedicated to security that can better define the term.

Perhaps the most important piece of advice for the unwitting Perl programmer is to always perform data validation. Never, ever trust input, regardless of where it came from. Fortunately, Perl provides Taint Mode, which forces the program to mistrust input.

Paul shared with us a variety of examples to demonstrate why input should not be trusted, as well as a number of examples of how to properly untaint data. As with anything, it’s easy to become lazy when untainting data, which can sometimes be as bad as not using Taint Mode at all.

The tutorial continued into what is essentially a list of best practices to follow when programming securely with files.

• Do: Use the three argument version of open(), to prevent attacks using file names with magic characters in them.
• Do: Use sysopen() instead of open(), which provides ways to avoid overwriting a file, thus helping to prevent symlink attacks often as a result of race conditions.

The common attack vector in so many of the examples given so far has been via file names. Wouldn’t it be great if we could write programs without file names at all? Well, when working in a Unix-like environment, we can. Perl has the ability to use anonymous files by passing undef as the third argument to open(). He was even kind enough to provide us with a way of passing these anonymous file handles to child processes, by disabling the close-on-exec flag prior to calling system(). Sorry, the slide went by too quickly for me to transcribe the method. It, along with all the other examples, are available online.

Calling system() and using backticks make Paul really, really angry. Why? Because doing it right is hard. In fact, just correctly checking the result in $? requires 10 lines of code, according to the documentation for system() in the perlfunc manual page. So, 10 lines just to verify that a single line of code executed successfully.

I briefly became distracted by news of a fire back home. However, what I was able to get is that Paul has written a module, IPC::System::Simple, which, as the name implies, makes the process of calling system commands quite simple.

After the mid-afternoon break, we ventured into setuid and setgid programs. Perl provides ways to determine who is really running the program ($<, $() and who is effectively running the program ($>, $)). Perl is, however, ignorant of the saved UID, which is the third UID in Unix, along with real and effective. Unfortunately, the standard for setuid scripts is confusing and implemented differently on various systems, so don’t use it. Really.

Even worse, the $< and $> variables are cached by Perl, so they may lie to the program, especially when using the setresuid() system call to properly drop privileges, as recommended. Fortunately, another useful module from Paul, Proc::UID provides a solution to this caching problem.

Now we move into DBI security. SQL injection attacks are very similar to the file name or shell attacks covered previously. Any database programmer worth his salt should be aware of the hazards of composing SQL, so I won’t go into the examples here. Programmers should, of course, use placeholders if they’re available. The DBI module itself provides its own Taint Mode, both for input and output, adding all the benefits of Perl Taint Mode to database interface code. Even better, it can be controlled on a per-statement basis.

All of this careful taint checking we’ve done and Perl may end up sabotaging us anyway. When presented with files on the command line, Perl is happy to just open them using the simplistic, dangerous, single argument open() call. Typically, this is done when using the <> operator in a while loop. Also, everyone forgets to use Taint Mode in cron jobs. Don’t do that. Really.

Because Perl is written in C, the null byte becomes very interesting. While it is a perfectly valid character in Perl strings, it marks the end of a C string. In most circumstances, this is not a problem. However, it can mean bad things when making systems calls, which are written in C. Normally, at a terminal, null bytes don’t occur in user input, unless that input comes from the Web. Null bytes can be trivially represented by the %00 escape sequence.

I need to go through the list of Paul’s modules, since they appear to be ideal for the type of programming I tend to do, as an IT developer. In fact, he’d like to see some Solaris patches for Proc::UID, so I can probably help him with that.

I noticed during the tutorial that Paul must read the Fail Blog and I Can Has Cheezburger, or at least knows someone who does. Quite a few of the images that have appeared on his slides have graced the pages of those web sites.

As an added bonus, the tutorial ended 40 minutes early, and Paul had bonus material. What a guy.

The tutorial, and with it the day, is now over. It’s time for dinner, then maybe a BOF session or maybe just a trip to a pub.

[tags]oscon, oscon08, perl, security[/tags]

The idea behind Mastering Perl is not to talk about Perl to a group of Perl masters. Instead, it’s about mastering Perl in the guild sense (and not of the SCA variety). Back in the day, and still existing in some professions today, there was an apprentice system. A neophyte—in today’s nomenclature, a noob—would begin acquiring skills under a master of the art. As he progressed, he would be entrusted with more and more responsibility, until finally he became a master himself and took people under his own wings.

This apprenticeship system, somewhat unfortunately, does not exist in the computing world. That’s where brian d foy feels that Mastering Perl fits. Lacking true masters, the book acts as a substitute. Someday, we may even create a guild system. But then we’d probably have to pay dues and follow rules, and that’s not very attractive. That said, it’s the model I’m hoping to use at my own place of work. I’d like to hire one or two developers who I can take under my own wing and mentor them in the ways of Perl and the grid.

The first two topics covered are tools for optimization, profiling and benchmarking. Often mis-attributed to Donald Knuth, Tony Hoare once said, “Premature optimization is the root of all evil.” What this means is that one should never assume what requires optimization. Let the testing be the guide.

While profiling is objective, benchmarks, like statistics, are not always objective. Everyone has an agenda and benchmarks are subjective. Often, benchmarks are short-sighted. For example, benchmarking code run time and attempting to optimize for it may not be worth the expense of the developer time required to make the requisite changes. It’s worth analysing what is important before blindly following benchmarks.

I’ve been on the receiving end of misplaced premature optimization. I worked with a development group that put far too much emphasis on achieving perfect results on their Devel::Cover reports. This led to strange bugs in their code, and a strong belief that “new() doesn’t work that way.” As it turns out, their test suite was calling new() in two ways. I forget what the second method was, but it was not used anywhere else in their code. However, in order to get this test code to run, and get 100% coverage, they added code to the constructor for every class. Code that prevented inheritance of the method. The team then convinced themselves that constructors could not be inherited in Perl, rather than realizing that their own habits were the problem.

After the mid-morning break, we wrapped up the discussion on profiling and benchmarking, and moved into configuration. This is a vital topic for anyone who desires the ability to pass a program off to users without being bothered to modify it later in response to users’ desire to customize the program for a slightly different use.

External configuration, particularly via the command line, is something I depend on heavily, even in very simple Perl or Bourne shell scripts. I almost always create command line options for performing a dry run or output debugging information. Not only are these useful for development, they can live on in the final program, providing help to the final user, who more often than not is me. Sometimes I will even add configuration to values that never change, just for when they eventually do.

Jumping past configuration, we move on to logging. It’s really easy to add to a program, and it’s really useful to leave in a program when it’s released. The ability to enable logging on the fly sure beats adding a bunch of print() calls in the code when it inevitably breaks at three in the morning. The Log::Log4perl module is a particularly powerful method of adding logging to programs. It’s well worth investigating for anyone who wants to easily add logging functionality to their code.

The final topic of the day is lightweight persistence. It’s always nice to have data stick around between program invocations. The easy way (and everything in the second half of the tutorial is easy) to add persistence to code is to not use DBI. While DBI is powerful, it also tends to require a database server (ignoring SQLite for the moment). Modules such as Data::Dumper, YAML or Storable are ideal for easily storing and retrieving data in code.

After the tutorial, brian will be available at the Powell’s Books mini store, located near the registration desk, to sign copies of Mastering Perl. I already have a copy, thanks to my local Perl Mongers group, but it’s all marked up with the group name, and I wouldn’t mind having a signed copy.

Now it’s time for lunch, which is good, because I’m quite hungry. I hope the conference-provided lunch is decent during the tutorials, as it was last year.

[tags]oscon, oscon08, perl[/tags]

As is my habit, I arrived at the San Diego airport extra early—two and a half hours in this case. I was extremely pleased to see no lines, at the check-in counter or security, when I entered the terminal. Unfortunately, I was immediately told by a customer service agent that there are air traffic control delays for flights in and out of San Francisco today. As a reward for my promptness, I was rebooked on an earlier flight, which was supposed to depart at 10:21 in the morning—approximately half an hour before I arrived at the counter. Once I got through to the gate, which was pleasant with only one person in front of me in the security line, I discovered that it had been scheduled for 11:45. As I wrote these words, it was announced that the flight had been released and boarding would being immediately, at 11:25.

The flight itself was pleasant, if boring. The plane was not full and I was fortunate to receive an aisle seat with a small Asian girl next to me. While complimentary soft drinks were provided, I couldn’t help but notice that the snacks, so common on domestic flights, were nowhere to be found. Another example of airline cost savings, no doubt.

We touched down in San Francisco about 10 minutes after one in the afternoon. My connecting flight to Portland won’t depart until approximately 5:30 in the evening. That leaves me with some four hours to kill in an airport without free wifi. I need to compile a list of airports that offer free access to the Internet, so I can be sure to book trips only through those.

It’s still too early for my connecting flight to be displayed on United’s monitors, so I’ve sat down in an uncrowded restaurant, the Buena Vista, where I’m writing this. I’ve ordered a Gordon Biersch Marzen and a reuben with cole slaw. It’s actually quite good.

I had considered attempting to stand by on an earlier flight to Portland, but the lines are long, and I have baggage checked through. I’ll just enjoy the time I have available to me to both relax and jot down whatever comes to mind my my new Moleskine notebook. Hopefully, the monitors will display my flight’s gate soon, so I’ll know the best place to find a seat.

I’m writing this now from my seat on the MAX light rail, heading to the Oregon Convention Center stop. I’m staying in the Courtyard by Marriott, a couple blocks north of the OCC. The flight out of San Francisco was delayed, but only by about 20 minutes. I managed to sleep for most of the time we were in the air, so I’m feeling pretty good right now. I’m looking forward to checking into my room and finding something for dinner.

As I was composing this final piece of my entry, I received a call from the fraud prevention department of my bank. At least now I know why the MAX ticket kiosk wouldn’t accept my credit card. How annoying.

Tomorrow, OSCON.

Though I don’t do it very often, I really do enjoy visiting places away from home. Unfortunately, I don’t often enjoy the act of getting there. It seems that the sole purpose of the US airline industry is to make things as inconvenient as possible for travelers. They’re not alone, however. When they’re not up to the task, the US government, in the form of the TSA, steps in to take up the slack.

Most of the time, my trips are uneventful and I end up getting worked up for nothing. Last year, though, my checked luggage ended up on a different flight than I did. Fortunately, both of those flights were bound for Portland, so my suitcase was delivered to the hotel later that same evening. Here’s hoping my trip tomorrow is uneventful.

View Larger Map

I’m sure I’ll add more to this map later. Such as the locations of all the good (and not so good) bars, not to mention the Oregon Brewers Festival.