After my near complete lack of interest in the keynotes I saw on Wednesday and Thursday mornings, I paid little attention to those on Friday. I thought the message Karen Sandler had about open health was good, but that’s about all I can say about them.

By far I was the most pleased by the sessions I attended on Friday. First, Kevin Falcone’s Shipwright: Application Distribution Simplified. Kevin works for Best Practical, a company with the best shirts. I plan on doing some evangelizing of Shipwright at work, as it would help a lot of people, including me, to better develop and deploy their applications.

I wasn’t planning on attending OSCON this year. I was perfectly happy skipping it and staying home during the last week of July. Then I happened to be looking over the list of Perl sessions and saw, at the very end of the list, Easy Distributed Computing with Perl and Grid::Request. It seems that Victor Felix has released a module that does exactly the same thing as some of the modules I’ve maintained at work, only the design is much better. However, it doesn’t support the batch system we use. I emailed Victor to discuss some collaboration and registered for OSCON so I could meet him. So yeah, I attended OSCON for one session. But it was worth it. The module looks great and Victor seems happy that I have an interest to contribute. It will be much better use of my time to contribute to a module on the CPAN than to continue pouring effort into what we have today.

Since, after chatting for a bit with Victor, I was already standing outside the room well into the next time slot, I popped into Git for Ages 4 & Up. Michael Schwern and Ricardo Signes demonstrated the Git commands everyone should know to get started with the version control system. As an added bonus, they used tinkertoys to help the audience visualize what Git’s internal representation of the repository looked like after each command. It was definitely a different and entertaining talk.

Prior to the closing keynote, Piers Cawley was invited to sing his library song, which I mentioned in Thursday’s post, again for the benefit of all OSCON attendees.

Paul Fenwick delivered the closing keynote. If you haven’t seen one of his talks, shame on you. Here, to help you fix that, I’ll refer you to his keynote, All Your Brains Suck—Known Bugs and Exploits in Wetware.

After three days in Portland, I finally ate at Burgerville. Eating at this regional chain is something I look forward to every time I’m in the area. Though, I suppose my change in diet may have suppressed my eagerness and led me to put it off until Friday. In any case, I ordered a cheeseburger with grilled onions (ditching the bun) and a large raspberry shake. While I prefer their blackberry shakes when available, the meal was delicious.

The high point of the conference happened, oddly enough, after it had ended. For whatever reason, I happened to wander into a different area of the convention center, in which a sock knitting conference was taking place. Outside of their expo hall was the Sockgate, a cardboard replica of a Stargate. As we were waiting to take pictures with it, Paul Fenwick happened by and offered to take some photos. He’s a really nice guy and I enjoyed finally getting the chance to meet him. After the photo op, he headed into the knitting expo hall. In retrospect, I should have done the same. It would have been interesting to see what it was like.

Photo Credit: Paul Fenwick

Finally, I learned that when I attend OSCON, I really do need to go for the entire week. Apparently, it takes me about two days to acclimate myself to the environment and really start interacting with people. Of course, by arriving Tuesday night, I was ready to interact on Friday, just as everyone was heading home. It didn’t help that I was staying in a hotel way out by the airport, with MAX service ending before 11:00 PM. With a new baby at home, I certainly don’t regret my choice to be away for a shorter period of time, but if I go next year, I’ll probably go for the entire week.

In any case, the Thursday morning keynotes were far better than those foisted upon us on Wednesday morning. Gabe Zichermann’s talk, in particular, caught my attention. In Game theory applied to user engagement in Open Source he talked about using so-called gamification techniques to draw people into using Open Source software. Many of his examples had to do with using game theory to alter real life behavior, such as a lottery to reward good drivers in Sweden or the use of consumption graphs in hybrid vehicles. On a separate note, I tend to grow annoyed at the latter, having been stuck behind too many hypermiling drivers.

Getting into the sessions, I favored those more in line with the work I do as a Perl programming system administrator. Also, it didn’t hurt that The Conway Channel 2011 happened to take place during the first time slot of the day. I’m a bit sorry I passed up DIY Clinical Trials (Or: How to Guinea Pig Your Way to Scientific Truth and Better Health), if only for the reason that it would have been completely different from anything I normally do. But, I attended those types of sessions on Wednesday, so it was back to business, so to speak. Damian Conway was in his usual top form, as entertaining as he is educational. I won’t go into too much detail, only to note that he demonstrated four of his modules, using a theme I’m sure most will recognize. First, something old, updates to the Regexp::Grammars module. He then introduced something new, the IO::Prompter module, which supersedes his older IO::Prompt. There was something borrowed, the Data::Show module, which serves as a convenience wrapper around the Data::Dump module. And finally, something blue, the Acme::Crap module, which seems oddly cathartic.

I like to think I’m a halfway decent Perl programmer, but that doesn’t mean I think I can ignore things like Jacinta Richardson’s Perl Programming Best Practices 2011. The talk was a round-up of the tools and modules that are generally considered to be the best practices by the Perl community today. Yes, generally. People will have their differences of opinion, and I don’t always agree with the advertised best practices. However, if followed, the practices will lead to better code, and if violating a practice, I like to be able to back that up with a well thought out reason (it doesn’t necessarily have to be a good reason). The first of two, possibly pithy, examples of this is the local::lib and it’s default use of ~/perl5 as its include path. I prefer to use ~/local/lib/perl5 and, sure, the module allows me to do that easily enough, but it’s an extra, non-standard step. Second, the cpanm has been touted as the best way to install modules from CPAN. As a control freak with a highly customized CPAN configuration, I’ve never liked the way cpanm seems to do things its way. Admittedly, it may be customizable, but I’ve never had the need to look into it.

There’s been some noise around the office about testing Amazon’s EC2 offering. To that end, I thought James Loope’s Utility and Automation: Low Overhead Operations with Amazon & Puppet would be educational, possibly giving me some ideas about how to managing our own potential EC2 environment. Unfortunately, it didn’t work out that way for me. The talk was heavily focused on the way the web application was designed and pieces of Amazon’s infrastructure were used. We’re not creating or running web applications, so none of it was beneficial to me. There was nothing about Puppet aside from explaining that using it (or another configuration management tool) is vital for keeping everything running.

At this point, I was turned off from any cloud talks at OSCON. There seems to be, with probably good reason, an inextricable tangling of cloud and web applications. Because of this, I decided to pass on Achieving Hybrid Cloud Mobility with OpenStack and XCP and instead attended Piers Cawley’s Polymorphic Dispatch—It’s Not Just a Good Idea, It’s the Law. I’m glad I did, because there were definitely some very useful ideas presented. The idea, taken from Smalltalk, of passing messages to objects has a lot of merit. Combining this with polymorphism, sending a message and allowing different objects to act on it differently, vastly simplifies code. Simple code, of course, is easier to test and easier to debug when things go horribly wrong (and actually is less likely to go horribly wrong in the first place). Of particular interest to me were the Null Object pattern and what Piers referred to as the key tenant of object-oriented programming: tell, don’t ask. That is to say, if I understood correctly, instead of querying an object for information and using it to determine which action to perform, give the information to the object and have it perform the action. Finally, Smalltalk Best Practice Patterns was recommended as the best book on good coding practices out there. According to Piers, it “will change the way you think about programming.”

I was in way over my head in Tom Christiansen’s Unicode in Perl Regexes. The only thing I managed to learn is that I don’t know nearly enough about Unicode to actually understand using it. I’ll leave it at that. It was a very information-dense session and it’s possible that Tom knows more about Unicode than those who designed it. Other choices during this time slot, which may have been better for me, were Connecting iOS to the Real World with Arduino, presented by my friend Alasdair Allan, or, venturing again into the realm of health geekery, Open Source Preventive Medicine: Citizen Science Genomics

The last session I attended on Thursday had so much potential, but, for me, it fell flat. I expected A. Sinan Unur‘s Visualizing Economic Data Using Perl and HTML5′s Canvas to focus far more on visualization than it did. Instead, the majority of the presentation was about the difficulty of parsing public data published by the United States government. For this, Sinan uses Spreadsheet::ParseExcel and explained a few of the techniques he uses to extract data from tables designed primarily for visual consumption. Unfortunately, very little time was spent showing how Canvas was used. We were given one static example and an explanation that there is no method available for determining the height of text in a Canvas element. I had hoped to return to work with some ideas for using Canvas to visualize data from our batch scheduling system, but ultimately left disappointed.

After the last session, I met up with a coworker, an old friend, and a new friend to have dinner at Chipotle. Normally, I like to avoid chain restaurants—national chains in particular—when traveling, preferring to sample the local cuisine. But, we wanted a quick dinner and it was nearby. My opinion was requested, on the relative healthfulness of pinto versus black beans. I simply stated that I would be ordering my carnitas bowl without any beans.

After dinner, we returned to the convention center for the Perl Lightning Talks and the State of the Onion. As always, the talks were quite entertaining. Of note was a juggling demonstration, illustrating various programming languages and databases. Near the end, Ricardo Signes recounted a conversation he had with a couple of women from the knitting conference sharing the convention center with us. Its presence provided a wonderful juxtaposition. While OSCON is male-dominated and many don’t know how to act when women brave their way into our midst, the knitting convention is completely opposite. Ricardo’s message to us was, take the time to look up from our laptops and chat with those around us. We might just have a better time and make new friends.

Finally, Piers Cawley favored us, as he does every year, with a song. This year, however, he did not bear a tale of levity, but a message of deadly seriousness. The United Kingdom is closing libraries in an attempt to reduce public spending. As a protest, Piers wrote a song, “Child of the Library”. There doesn’t appear to be any video (yet) of Piers performing at OSCON, but I’ve gone ahead and embedded one that I found. It’s catchy, I had it stuck in my head for a couple of days after the conference.

We could easily see the same thing happen in the United States—and in fact I have already seen it proposed in San Diego. I’ll first admit that I have not set foot inside a library since college, over a decade ago (high school, if only counting public libraries). Do libraries still matter, or is the concern over their closing merely the knee-jerk nostalgia of those of us who came of age in a world that didn’t yet know the Internet? I can’t, and won’t, take a side on this issue until I’ve taken the time to visit my local library. If I can recognize it as something I saw in my childhood, perhaps it should be closed. If it has adapted to the so-called Information Age, maybe it’s worth funding.

As a final, humorous note, I almost didn’t make it back to my hotel. At least, not without finding an alternate method of transportation. At 10:22 PM, excusing myself and apologizing for staying so far away from the conference, I left Media Temple party at the Jupiter Hotel, arriving at the convention center MAX station at 10:32 PM. The schedule at the station listed 10:42 PM as the last red line train to the airport, with Google Maps concurring that a train was 10 minutes away. About two minutes later an unmarked blue line train arrived at the station, traveling east. At this point, Google Maps had decided it would rather show me its trip planner instead of the previous screen which showed the impending arrival of the red line. Forced to make a split-second decision, I hopped on the train. I knew that I could take it at least as far as the Gateway station, where I could transfer to the red line if it was still behind me. Around 11:00 PM I arrived at Gateway, after spending the ride thinking about how much a cab would cost. This station had a real-time display with train arrival times. The last red line of the day was only three minutes out. Whew.

I had breakfast in my hotel’s restaurant this morning, a mistake I won’t make again —over half the plate was composed of potatoes and toast, leaving little room for the eggs and sausage—. It was an easy walk to the Cascades MAX station, until I saw the train arriving before me. I likely could have made it onto the train had I sprinted, but I also had to buy a ticket, so I let it go. Fortunately, it was the beginning of the morning commute, so another train was not far behind.

This morning’s keynotes were dry. At least, I didn’t find them at all interesting. Well, except for one. I enjoyed Ariel Waldman’s brief talk about Hacking Space Exploration. It reminded me that I don’t spend nearly enough time on Galaxy Zoo.

The final keynote was a so-called surprise announcement. We were first treated to a video in which a bunch of big names in technology—Bill Joy, Tim O’Reilly, and Al Gore to name a few—gushed over the possibilities of commodity cloud computing. All that build up ended up being nothing more then a lead-in to an overblown advertisement for something called Nebula. While the idea of open and commodity elastic compute is cool, I have difficulty taking something seriously when it’s surrounded by as much hype as I saw during the keynote. Maybe I’m alone in this, but OSCON doesn’t really seem like the right venue to go heavy on marketing and light on technical detail. Maybe those of us sitting in the ballroom weren’t the real audience for the announcement. Perhaps they were just using the large and popular conference as a way of getting media attention.

So, what sessions did I attend?

About half way through OSCON last year, I realized that attending Perl sessions was mostly a waste of my time. They tended to fall into two categories: stuff I already knew and web development (which I don’t do). Where do I end up for the first session of this conference? In Perl 5.14 for Pragmatists, presented by Ricardo Signes. For anyone who has read the Perl release notes (perl*delta), very little of what was presented will be novel. However, it was very useful to see the relative emphasis placed on different features by someone as familiar with Perl as Ricardo. In particular, fully half of the session was dedicated to Perl’s improved Unicode support. As Ricardo stated, Unicode isn’t going away, so we need to get better at working with it.

After attending a session of some relevance to my profession, I wanted to take advantage of a series of back-to-back sessions of a more personal interest. My passions of late have leaned towards health, fitness, and, in particular, a more so-called primal lifestyle. So I was excited to see the session Geeking in a Cabin in the Woods, presented by Ryo Chijiiwa on the schedule. Previously employed as a software engineer at Yahoo! and then Google, Ryo took us through the history and motivation behind quitting his job, buying 60 acres of barren land in northern California, and simplifying his life by living on it. It was a fascinating tale of overcoming challenges. Part of me would love to do exactly what he did. Ryo has a blog (with a really cool domain name) where he writes about his experiences.

Following in the same basic genre, I next attended Sarah Sharp’s talk on Growing Food with Open Source. Sarah is a Linux kernel hacker who also enjoys gardening. Being a lazy hacker (I can relate), she wants to automate all of the mundane, tedious work that comes with a hobby like gardening. She’s written code to manage planting calendars, hoping to eventually integrate it with a service like Remember the Milk, and an Android app to alert her of impending weather conditions that could affect her garden. The most impressive piece was the work she’s done to create an automatic watering system, using home-made moisture sensors and Arduinos. More information can be found on a site I will soon be spending a lot of time on, Garden Geek.

My earliest computer-related memory is playing text adventures on our Apple Macintosh, circa 1984. For that reason, I was excited to attend Ben Collins-Sussman’s talk on The Unexpected Resurgence of Interactive Fiction. So excited, in fact, that I passed up a session r0ml was presenting. Ben took us through a brief history of interactive fiction, from Adventure to present day. He talked about both the science and the art of the genre as both have evolved over the years. He focused primarily on the Inform language and the Glulx virtual machine (not to mention current efforts to produce a web browser-based player), which leads me to think that there isn’t much point in putting any more effort into playing with TADS. He also mentioned the annual Interactive Fiction Competition, which I love and have participated as a judge in for the last several years. This session has gotten me excited about interactive fiction again, after mostly ignoring it as a hobby for the last few years. I have a couple of ideas for games that I’d like to enter into the competition, which I should finally get started on.

For the final two sessions of the day, I decided to return to my core competency, and arguably the whole reason I’m here, and sat down in the Perl room. Damian Conway talked about (Re)Developing in Perl 6. I’ve previously attended his six hour class on this topic, but it was a nice refresher, since I don’t use Perl 6 regularly. He guided us through porting a handful of his modules—Acme::Don't, IO::Insitu, IO::Prompter, and Smart::Comments—from Perl 5 to Perl 6. Each of these modules was selected as a representative of a given method used to port the code. In the simplest case, a basic transliteration can be used. For some modules, new features of Perl 6 can be used to replace long pieces of code; argument lists are a great example. Finally, the ability to extend the grammar removes the need for source filters and allows the programmer to seamlessly add language features.

I ended my day with a session on improving code performance: Sooner, Cheaper, Better — Optimization on a Budget, presented by Eric Wilhelm. I didn’t find it very well organized or delivered, which is a shame, because I’ve seen him present before and he was rather good. After introducing us to the Rules of Optimization Club, Eric took us through a number of real world examples in which optimization might prove to be a waste of time. Old hat for a lot of people, I know. In fact, many people just wait for computers to get faster. However, he then switched gears into a more interesting problem. With today’s advances coming in the form of more cores rather than more speed, optimization was replaced with parallelization. The same rules apply and it’s good to remember that.

Following the last session of the day, a booth crawl was held in the expo hall. This involved setting up food and drink tables at the booths of various vendors, the idea being to bribe attendees to approach them. There was beer, possibly wine, and the food leaned heavily towards cookies and grain-wrapped items. I wandered around, played a Mario Kart-like Pac-Man multi-player racing game on an Android tablet at the QuIC booth, ate a bunch of cheese, and left at 7:00 PM …

To attend the .vimrc birds of a feather (BOF) session. A .vimrc, oft pronounced vim-wreck, is the name of the configuration file Vim uses. It’s more than a configuration file, though; it’s a full scripting engine, which provides quite a bit of potential for customization of one’s editor. Damian Conway, famed teacher of Vim, Perl, and myriad other topics, was in attendance. As expected, the entirety of the session was spent learning about some of the neat, as yet unreleased, scripts Damian has been working on for Vim.

I didn’t have it in me to attend any of the evening events. I was aware of two parties, but I neither wanted to drink nor stay out late. Unlike years past, I haven’t been very social this year, either. Instead, I made the relatively long trip back to my hotel, where I wrote this post (well, just the first draft; I finished it on Thursday morning over the lousy coffee provided by the Oregon Convention Center) and turned in early.

Unlike in previous years, I didn’t show up on Sunday to explore Portland and attend the Monday tutorials. I didn’t want to spend an entire week away from home, but at the same time, nothing I saw on the tutorial schedule interested me. So I flew up Tuesday afternoon and plan to return on Friday night.

Most of the hotels near the Oregon Convention Center (OCC) were booked up, and I left my itinerary planning to someone else (who is unfamiliar with Portland), so I’m staying at the Courtyard Marriott by the airport. This wouldn’t be so bad, but, according to Google Maps, it’s a 1.2 mile walk to the Cascades MAX station.

Anyway, after getting settled in my hotel room, I headed to the OCC to meet up with my friend, Jonathan. I made it in time to register, pick up my swag, and grab some cheese and beer on the expo floor. I wandered over to the QuIC booth to chat and saw a nice demo of Android and HTML 5 applications running on Qualcomm demonstration hardware. It really showed off the power of the platform.

We decided not to stick around for the so-called OSCON Carnival, so hopped across the river on the MAX and looked around for dinner. In our wanderings, we dropped into Bailey’s Taproom to use the bathroom and have a beer. The bartender recommended the Davis Street Tavern for a good burger paired with a good tap list. I ended up having seared scallops, which were quite good. After dinner, we wandered over to the Puppet Labs party, where I got a souvenir Open Source Lab beer mug.

Bailing fairly early on the party, I caught the MAX red line back over the river and on to the Cascades station. The hotel’s shuttle driver had warned me against the walk, pointing out that there are no sidewalks. However, Google directed me away from the main road and through a business park. I don’t know why people are so averse to walking more than a couple of blocks. I found the walk to be quite pleasant, and there are blackberry brambles growing wild along the streets, providing snacking opportunities. It takes me back to childhood trips to the Pacific Northwest, when I would pick wild blackberries with my grandfather.

Back at the hotel, I grimaced at what they call a fitness center, swam a bit in the poor excuse for a pool, and soaked in the hot tub. Then it was off to bed, because, unlike the lucky folks staying near the OCC, I have to wake up in time for a 20 minute walk followed by a 25 minute MAX ride.

Tuesday was the second and final day of the tutorial sessions. In the morning I attended a tutorial on PostgreSQL’s new hot stand-by and streaming replication features; and, in the afternoon I attended part of a tutorial on Cassandra. Why only part? I’ll get to that.

I didn’t feel like going across the river to the food trucks for lunch, so I joined Debbie for lunch at Burgerville. Aside from the delicious food made from local ingredients, there are two things that struck me about Burgerville. The first I noticed when I walked in the door: for the first time, disposing of my trash would require me to read instructions. Burgerville uses three bins for trash: one for recyclable materials, one for compost, and finally one for trash that can neither be recycled nor composted. I thought this was neat, though I did get a kick out of the soft drink cup. It’s from the Coca-Cola company and advertises itself as something that can be composted; with the footnote that this was only possible in a large facility capable of composting such cups. Not something one can throw into their garden compost pile, I guess. The second thing I noticed caused me immediate regret: the receipt lists the calorie count of the foods ordered, along with carbohydrate and fiber content. Looking over the details of the burger, onion rings, and raspberry milkshake I ordered, I decided that it would not be a very paleo day for me. Oh well, the milkshake was very good.

While enjoying our carb-loaded, calorie-filled lunch, Debbie noticed someone wearing a pair of Vibram FiveFingers that we hadn’t seen before. From a distance, they looked almost like normal shoes and appeared to be made with a dark brown suede. With both of us deciding that a post-lunch, calorie-burning walk was called for, and sharing a desire to buy a new pair of FiveFingers, we set out for Portland’s REI store. A trip on the MAX, a walk, a few blocks on the trolley, and another walk brought us to the store.

The shoes turned out to be the KSO Trek. They’re very nice and I’m considering purchasing a pair for hiking. Unfortunately, I struck out on the trip. REI has been having a hard time keeping FiveFingers in stock, so I wasn’t able to find or buy a pair of the Classic version. Fortunately, I’m still satisfied with my KSOs, which I was wearing at the time.

Our impromptu quest for footwear took us well beyond the alloted time for lunch. Fortunately, this time was not wasted. While walking, we had received a call from our coworker back in the expo hall, who needed help setting up the QuIC booth. For some reason, it was fun being allowed into the expo hall while booths were still being constructed. Not sure why, other than that I enjoy seeing things taken apart and (sometimes) being put back together. After getting the booth set up, I made it to the second half of the Cassandra tutorial. I’m told by those who attended the first half that I didn’t miss much.

We had some time to kill between the end of the day’s sessions and the evening’s Ignite talks. So we walked a few blocks to a place called rontoms. Had I not been looking for the specific address, I would have walked right past, not noticing that this was either a restaurant or a bar. The cavernous interior was devoid of anyone save the bartender and a waitress, who would disappear as quickly as she appeared. The photographs on the wall, ost of which featured a man in an animal costume, ranged from strange to disturbing. After a moment’s hesitation, we ventured out back to find a patio crowded with patrons enjoying food, beer, and spirits. With what appeared to be only a single waitress working and not having particularly strong appetites, we went back inside, obtained pints directly from the bartender, and found a comfortable area to sit and chat. Twice we encountered people entering the restaurant, looking for people they didn’t know by sight. Both times my colleagues convinced them that we were those people; one girl even sat down with us for a few minutes before we let her in on the joke. After a while, I received a page from Jonathan that there was beer, salami, and cheese being served outside the ballroom at the convention center. This sounded like an excellent and delicious dinner to me, so I made my way back.

I hadn’t been to an Ignite session before, so I was looking forward to this one. Right off the bat we were warned that we would likely enjoy some talks and dislike others. Fortunately, each talk would only last five minutes, so we were free to use the time to retrieve another beer. By the time we returned, the talk would be over. I don’t believe I took advantage of this, instead waiting for the break, during which some awards were being presented.

Two talks stand out in my memory. The first, perhaps appropriately, was the first in the lineup: Paul Fenwick talking about Maximum XP: Optimising life for adventure (which he gave again, at a much better pace, at the Perl Lightning Talks). Presented in song, Paul’s message seemed to be to enjoy travel and to take advantage of opportunities to meet people and have fun. Based on what I’ve read on his Twitter stream, I’d say he’s been successful.

The other talk, Your Infinite Do-Loop Exercises Bores Me, struck a chord with me. John Scott and Jim Stogdill paired up for this talk, one would perform exercises while the other would speak, switching places at the halfway mark. Not only was it refreshing to see a talk about fitness at a convention populated by a class of people not known for their physical exertion, but it was about a method of fitness I’ve recently become interested in. While I don’t practice CrossFit myself, I frequently look at the exercises on the site and prefer it to the typical, repetitive gym workout. They also mentioned the paleo diet, which, along with the primal lifestyle, I’ve become a big fan of.

My coworkers all turned in early, so I hopped back on the MAX and headed downtown to have drinks with Kevin at Bailey’s Tap Room. I had a wonderful sour beer, which I no longer remember the name or origin of, and had the pleasure of meeting Steve, Jeff, and Michael Schwern. Jeff and Schwern were discussing the use of the Log4perl module in the latter’s gitpan project.

After last call at Bailey’s, I caught the last yellow line across the river and turned in myself.

This session is a companion to the session on competition r0ml presented on Wednesday. For those of us who, for whatever reason, were unable to attend the previous session, he provided us with five second summaries:

• Wednesday: Competition is bad, don’t do it.
• Thursday: Licensing is bad, don’t do it.

And with that, the session is over.

I’m kidding, of course. The best part of any of r0ml’s talks is the logic he uses to get from his observation to his conclusion. As he noted at the outset, the path typically takes us through the Middle Ages.

I don’t deal with lawyers very much in my day job, since I work in a support role for our engineering departments. However, I know several people in our Open Source group, and have attempted to release some of the Perl modules I’ve written while on the job. Doing so is decidedly non-trivial and, after two years I still haven’t been allowed to release my code. To say I’m disappointed is an understatement.

My experience with lawyers has been that they are extremely cautious. While frustrating, I understand that it’s their job to play it safe and to protect the company. They are scared, almost beyond reason, that an Open Source license will find its way into a piece of intellectual property that they’d rather not release. It can’t be easy trying to bridge the gap between the closed and open ways of doing business.

The topic was introduced with a question: What is the difference between copyright and plagiarism? Plagiarism is forever. I didn’t quite catch what r0ml meant by this, but I suspect it means that copyright (eventually) expires, granting the work in question to the public domain. Plagiarism, if one can get away with it, creates an attribution that lasts forever.

That, if one is an Open Source geek, leads one to think about licenses. Let’s take the attribution clause of the BSD, which contains two sub-clauses, for example. It’s redundant. It effectively means that the recipient of the source code can not claim credit for the author’s work. Under copyright law, this is already the case, so why the redundancy.

In the name of efficiency and refactoring, r0ml mused whether it would be possible to reduce the number of license clauses to one. He found this in the Do What The Fuck You Want To Public License.

Through inductive reasoning, if we can reduce the number of clauses from two to one, we should be able to similarly reduce the number of clauses from one to zero. After all, if we begin with the earlier premise that licenses are bad, this should be the goal, right?

First, briefly, why are licenses bad? There are many reasons and many arguments; too many of each for this post, but to summarize a few important ones, as of this writing, the Open Source Initiative lists 73 approved licenses. Choosing between them can be a daunting task. Neither do all of these licenses play well with each other, further complicating the selection task if one is attempting to integrate differently-licensed source code. Finally, it’s rare that anyone knows all that they are agreeing to in the license.

The Medieval sensibility was that all knowledge came either from God or from the Ancients. As such, no one could claim credit for a work, because, without exception, it would be plagiarism. For this reason, the majority of works produced during the Middle Ages were compilations, a representation of existing information.

We have a modern equivalent of this Medieval concept of copyright, called the Compilation Copyright. A compilation of files in the public domain is assembled with copyright only on the compilation. Further, no one may claim credit on the same collection of files. Instead, a new compilation, or derivative work, must be created.

How bad has copyright gotten? Well, thanks to the Apple development kit, there is a short piece of code, included in every project, that is separately copyrighted by everyone who has used the development kit. This is getting out of hand, to say the least.

So r0ml wrote unlicense.rb, which will scan a directory recursively, removing any licenses it finds. This, of course, is perfectly acceptable under the terms of the licenses being removed, so long as the files aren’t redistributed. It does have the effect of pleasing the obsessive-compulsive user.

Under the laws of many countries, a copyright notice isn’t actually required to have a copyright. This is particularly true in the United States and the European Union. In fact, in the latter one cannot even waive the protections of copyright. This creates the default case: without a license, nobody other than the author has the right to do anything with the code. The default is all rights reserved.

Richard Stallman, founder of the GNU project and the Free Software Foundation, was not trying to protect the author of code from people downloading the code; rather, he created the GNU General Public License to protect the users of the code. He felt that users have an inherent right to have access to the code running on their computer. Thus, the primary reason for the creation of Open Source licenses was to protect the user.

Many companies claim that they have an Open Source business model. Typically what this means is that they offer their software, or some subset of their software for free, under an Open Source license. Then they offer support contracts, for usually high prices. These aren’t really Open Source business models. The SQLite project has the only known true Open Source business model. The software itself is released into the public domain. This is a scary place for lawyers, especially those employed by large companies. To assuage their concerns, the company that employs the author of SQLite will be more than happy to sell them an Open Source license for the code.

Next, r0ml talked about warranties. In some jurisdictions, the default case under the law is that there is an implied warranty, unless stated otherwise. Most of us have seen the disclaimer of warranty, included to protect the author, attached to the license in code we have downloaded (or added it to code we’ve released), usually in all capital letters. While not a strict requirement to be in capital letters, it is a requirement that the disclaimer be made to stand out. Often, licenses are in plain text files, so using a bold face type isn’t possible. Hence, capital letters. The simplest case of a disclaimer is such:

/* This program comes without any warranty, to the extent permitted by law. */

As we recall, the default case under the law is an implied warranty so including the phrase “to the extent permitted by law” is redundant. Also, it should be noted that copyright law, in the United States, is codified at the Federal level, in Title 17 of the United States Code, while warranty law is codified by the states. This leads to many more jurisdictions, and far more potential confusion, for warranty law.

So finally, here is r0ml’s part serious, part humorous take away: don’t include either a copyright or a warranty with your code. If a user sues you for damages under the implied warranty in a state court, counter-sue them in US federal court for copyright infringement. After all, under the law they were not given permission to copy the code anyway.

A question came at the end of the session, from someone who appeared mildly upset and defensive. He pointed out that Stallman created the GNU General Public License for a good reason, which wasn’t mentioned by r0ml during his talk. Someone had taken the code Stallman was freely distributing and sold it. After which, they went back to Stallman to inform him that he could no longer distribute his own code, because he hadn’t licensed it. The questioner appeared to be offended by the whole point of the session, apparently feeling that all the work Stallman has done for Free Software was being ridiculed and that, without these licenses, “capitalists” will simply steal the code for their own nefarious purposes.

To this, r0ml did have a response. Copyright law has changed since Stallman faced the problem that led to his creation of Free Software. It has become more strict and the requirement for registration has been dropped. The point was made that the questioner is actually referring to the concept of provenance, not copyright. However, this concept was not further explored as, unfortunately, time had run out.

Your Work in Open Source, 3 years of Incremental Change

Chris DiBona (Google, Inc.)

Google crawled 40 million files in Google Code to generate statistics on what’s in there. Lines of code and numbers of commits are not the most useful of metrics but that’s what they have to use.

The Gnu General Public License is the most used license, at over 50%. Of those, more than half have moved to GPL version 3. Perl has declined a bit, but C has the most use, at about 40%.

Many companies are committing code, too.

Mayor Sam Adams

Sam Adams (City of Portland, Oregon)

Last September, Portland adopted one of the first Open Source policies in the nation. They’ve committed themselves to open software, open data, and Open Source in the procurement process for software.

It’s pretty cool when a politician gets it.

Situation Normal, Everything Must Change

Simon Wardley (Leading Edge Forum (CSC))

Simon started with a recap of the talk he gave last year, which showed correlations between the ubiquity and certainty. All technologies follow the same curve, from having both low ubiquity and certainty up to having both high ubiquity and certainty. The stages tend to be the innovation of a technology, the productization, and finally the comoditization.

The basic idea was that the cloud, as it is known, is still in its infancy. As it matures, we will see innovations built on it at an accelerated rate. If we don’t pay attention to it, we’ll be left behind.

Well defined processes stifle innovation.

Projects or teams can be organized by lifecycle: innovation, leverage, and commoditize. This circles back on itself. When one thing is commoditized, a new innovation can be built on top of it.

Larry claims that so rarely does he talk about Perl in the States of the Onion addresses that he has brought his conscience with him today to prod him in the right direction (the aforementioned angel and devil).

The current state of the onion is segmented into left, central, and right sections. It can be labeled, say, 5 and 6. They can also be labeled 0 and 1, for false and true. Larry then asked a series of boolean questions, asking the audience to weigh in on the veracity.

Do you think Perl 5 and Perl 6 are really the same language?

Do you think Perl 5 and Perl 6 are really different languages?

As the angel and the devil argued, Larry pointed out that an important skill for a language designer is to be able to stay on the fence long enough until he can determine which side the grass is greener on. Sometimes you discover that you’re sitting on the wrong fence and the voices in your head start to argue about which side has the greener grass.

When the voices in your head start arguing if the purple cow eats greener grass than the brown fence, it’s time to see a doctor. Or find a better drug dealer.

— Larry Wall

This is, of course, a metaphor for being a language designer. Sometimes you sit on the fence for language features, without ever knowing which direction is the better one.

Next up is a live demo of Perl 6; or, more specifically, of Rakudo Star, which is scheduled to be released next week. Some of the demos, without comment:

.say if 6 %% $_ for 1..^6

[+] gather { take $_ if 6 %% $_ for 1..^6 }

[+] grep { 6 %% $_ }, 1..^6

~[+] grep 6 %% *, 1..^6

-> $n { $n == [+] grep $n %% *,  ..^ $n }

-> $n { $n == [+] grep $n %% *,  ..^ $n }(6)

At this point, the examples scrolled off the screen due to a “whatever” example being run. That’s good news, though. It means Rakudo Star supports lazy lists and, as such, we finally have those infinite lists we’ve been promised:

0, 1, ... *

The whatever star can, in addition to being used as in an infinite series, can be used to curry a function:

(1, 1, *+* ... *)[^20]    # Fibbonacci

(0, !* ... *)[^20]        # 0 1 0 1 0 1 ...

In a recent video interview, Larry was asked, if he were hit by a bus, has he designated anyone to be his successor as the leader of the Perl 6 project? His response was that he trusts the Perl community to choose the right person.

Onions can make you cry, so can disruptive technologies or innovations. Almost everyone has labeled their technology as disruptive. As such, the phrase has lost most of its meaning.

A disruptive technology simultaneously does something worse and does something better than its competitors. In a time of the Unix philosophy of “do one thing and do it well,” Perl came along and attempted to do everything, but didn’t necessarily do any of it well. The Unix philosophy was broken by its own utilities. No one knew what a “thing” was, and no utility of the time did it well. By the time Perl 4 turned into Perl 5, it demonstrated that a tool that was itself an entire tool shed could run circles around shell scripts.

In California, we once had many, many colonies of ants. Now, most of California is populated by a single colony of Argentine ants. This is because the colonies have forgotten how to fight with each other. Perl 6 has benefited from multiple teams creating multiple implementations, in the end working together to create a better product, even if that product takes longer to complete.

If you don’t like Camelia, you can just fork off.

— Larry Wall

The takeaway, I think: It is up to all of us to determine what Perl 6 will be. What kind of disruptive technology will it be?

Ever since I saw An Illustrated History of Failure two years ago, I’ve made it a point to see @pjf‘s talks. That’s how I find myself in his mid-afternoon session, Awesome Things You’ve Missed in Perl. Judging by the size of the crowd, I’m not the only one. However, I won’t attempt to pass along his humour in this post. I’d never do it justice.

In his introduction, Piers Cawley asked that we go wild when Paul took the stage, so the folks in the Google Wave session next door would be taken aback, and realize that Perl is not, in fact, dead.

People are still out there writing Perl as if still in the dark ages of 2008. Paul doesn’t want us to write old Perl, but only new and shiny Perl. This talk only covers practices that have come about since Perl Best Practices was released.

Object-oriented Perl is not awesome. Not even close. If you look at the old ways of doing it, all of them are either wrong, stupid, or both. The rest are too hard. There’s a simple way to fix this: use Moose. This module does so much of the infrastructure work of composing classes, it makes object-oriented programming enjoyable again.

Paul spent a lot of time giving a humorous, high-level overview of the features available in Moose.

The Moose module contains a huge number of extension modules in the MooseX namespace.

When I have a problem, I go down to the pub with other Perl mongers and bitch.

One of the limitations of Perl, that is exposed to Moose, is that not everything is an object. This means methods like push() or isa() can’t be called on everything. And checking types defeats the purpose of polymorphism. Enter the autobox module, which turns everything into an object. As a bonus, it operates in lexical scope. Moose exposes autobox through the Moose::Autobox module.

A module that Paul wrote, autodie, which is now included in core. This lexically scoped module removes all of the boilerplate code that goes along with trapping errors from subroutines.

Not only is Perl 5.10 awesome, but Perl 5.10 regular expressions are awesome. In particular, the introduction of named captures (via %+) made regular expressions extremely awesome.

Perl 5.10 also provides grammars in the regular expression engine. This is the basis for Damian Conway’s Regexp::Grammars module.

Referring to an article on SweeperBot in The Perl Review. However, there’s the problem of distributing a program that uses half of CPAN to users of inferior operating systems, such as Microsoft Windows. That’s where the PAR module comes in. It will pack up all of the modules used by the program, including the Perl interpreter itself if necessary, so a single, self-reliant file can be distributed to users who need it.

Remember to never optimize code. Programmer time is far more valuable than CPU time. However, when you must optimize code, profile first. The Devel::NYTProf makes profiling awesome.

Code reviews are important, but Perl programmers are lazy. Fortunately, the Perl::Critic module has read Perl Best Practices for you and will complain about where your code violates the practices in the book. At my day job, it does about half the work of code reviews for me, loudly announcing violations of the coding standards that I enforce with an iron fist.

If you find an awesome module, buy the author a beer if you have the opportunity. There’s also CPAN Ratings to leave feedback or perlthanks in recent versions of Perl.

The full title of this session is, 21st Century Systems Perl – the New Perl Enlightment for sysadmins

Introduction

While Perl isn’t dying, “PERL” most certainly is dying. This is a good thing, because it includes all the really crappy stuff, such as Matt’s Script Archive. Thank goodness for that. To be fair, this code would have been horrible written in any language. Remember, blame the artist, not the tool.

We have a very mature community, which means we also have very mature practices. We are also converging on a standard platform, even if there are more than one ways to do something.

Part 1: Minimising Developer Fatalities

As a developer, we should do what we can to make our sysadmins’ lives easier.

Right off the bat, we should use the local::lib module, which allows an application to use custom library areas without polluting the system installation areas. It can even work with /etc/skel. Matt is a big fan of using a local library path, included with the application, so it can be maintained separately from both the operating system vendor’s modules and even other applications.

Improve module installation using Module::Install.

Package modules for your distribution of choice using cpan2dist.

Improve the CPAN experience using App::cpanminus, which is amazing easy to bootstrap:

> wget cpanmin.us
> ./cpanm

Start using all of the modules associated with best practices by installing Task::Kensho.

Vendors are getting better at distributing Perl and keeping up with module releases. The Debian Perl team is the strongest, with Fedora lagging quite a bit far behind. Fedora is finally getting better, now that members of the Perl community have a say in the packaging of Perl and the modules.

After many debug sessions, Matt has come to the conclusion that mod_$lang is evil. Jamming languages into the web server is a bad, bad idea. However, actually hooking into the different handlers can be useful. Matt’s preference now is now FastCGI.

Part 2: Maximising Automation Banality

“In the systems world, shiny and exciting is not good.”

Use the autodie (in core as of 5.10) and the IPC::System::Simple modules to reduce the repetitiveness and the common errors of systems programming.

Use IO::All to fix the syntax and semantics of I/O operations.

Systems script shouldn’t need to be deployed. It should be possible to just drop the script onto a host and it will Just Work. That’s where PAR::Packer.

The full title of this talk is, Dist::Zilla – Maximum Overkill for CPAN Distributions.

Every CPAN distribution contains a significant amount of crap. It’s infrastructure used for the distribution tools.

ExtUtils::MakeMaker has been the traditional way to work on the infrastructure code. By necessity, it contains a lot of legacy, which can be cumbersome to maintain. Enter Module::Install, which can look in the expected places for the necessary information, such as the author name. But, the author still must write all the boilerplate. Module::Starter was written to address this, composing all the boilerplate on behalf of the author. There is so much boilerplate that, by default, Module::Starter also provides a boilerplate test to detect it.

Why are we doing all of this? How much repetitive work are we doing?

What can Dist::Zilla do for us? For starters, we can remove some files:

• LICENSE
• MANIFEST.SKIP
• Makefile.PL
• README
• t/pod.t
• t/pod-coverage.t

Leaving us with only our Changes file, our code, and our tests. The non-infrastructure parts. On top of that, Dist::Zilla does all of the boring distribution bits for us. It only handles the make dist command. It does not handle the make install command, which means the users who install the module don’t need all of the dependencies.

Dist::Zilla puts all of its functionality into plugins, which will be the meat of the rest of this session. It also uses a very simple INI-style configuration file.

The main command provided by the module is dzil build. This bundles the distribution, which will contain all of the infrastructure necessary for users to install the module. When building, it follows a simple work flow:

1. Gather files
2. Munge files
3. Collect metadata
4. Write out

There is no default configuration, but there is a Basic plugin bundle that will include all of the most common plugins.

What followed were examples of what the plugins can do. Of course, all of them are designed to reduce cruft—the non-code, non-documentation bits that we’re forced to maintain. The philosophy is the same one I advocate to anyone who will listen: computers are good at doing boring, repetitive tasks with derived data; why don’t we let them do more of that stuff?

I’ve followed @rjbs on Twitter for a while, and I’ve seen him talk about Dist::Zilla. I’ve wanted to try it out for a while, to simplify my distributions—both for CPAN and for my day job—but I didn’t realize until this session just how awesome the tool is. It’s a complete framework for managing Perl module distributions. Dist::Zilla will give my Laziness score a huge bump.

To be fair, this vagueness and my pessimism are precisely why these speakers have been invited to the O’Reilly Open Source Convention. Tim O’Reilly has a grand vision for the cloud, for ubiquitous computing, and the use of technology to help solve the world’s problems. I commend him for that. I hope this morning’s speakers do justice to his vision and that, if there are valuable lessons to be learned, that we learn them.

Today’s LAMP Stack

David Recordon (Facebook)

Over the last decade, the LAMP stack hasn’t been fundamentally updated. A cache, such as memcached has been added. Different languages (Perl, Python, Ruby) have been used in place of the original PHP. Even different web servers have been used in place of Apache.

Facebook created HipHop for PHP, which compiles PHP into C++. Creating native executables in this way reduces CPU use by a large factor (a number I didn’t catch).

There are alternatives for the database component in the stack, too. MySQL is ubiquitous at this point. Facebook doesn’t really use the relational bits of MySQL very much. So they have been using databases from the NoSQL family—Hadoop, according to the presentation.

David made a point I think a lot of people miss. When evaluating databases, or any other software, first look at what problem needs solving, then find a product that solves it in the correct way. Too often I see people advocating their preferred solution without even looking at the problem.

Data is the lifeblood of Facebook (and we all have our own opinions about that). They are able to use a plethora of Open Source tools to store the data, scale the data, and analyze the data.

This talk wasn’t very focused on the cloud, aside from Facebook being a nebulous site where people store their data without really knowing where it goes or how it’s used. I expect this was more for public relations, given all the bad press they’ve had. Not that anyone stops using Facebook.

Open SETIQuest – It Will Be What You Make It!

Jill Tarter (SETI Institute)

Jill started her talk by explaining what SETI is and why it exists, which I won’t go into here, since it’s just a Google search away. I used to run SETI@home a bit over a decade ago when I was in college and felt like using my computer as a space heater.

Jill is here, representing SETI, because she wants to involve the world in their search. SETI has classroom materials covered, but they are lacking in the social networking world. Jill wants people to first identify themselves as Earthlings, recognizing our place in the Universe.

SETI, with the development of the setiQuest community, hopes to use the vast resources available in the Open Source world to improve the project. These include physical resources, such as cloud storage and compute cycles, to human resources, such as programmers and analysts.

Cloudant has created a SETI stack on the Amazon AWS infrastructure.

Open Cloud, Open Data

Jean Paoli (Microsoft)

I’m always a little concerned when I see a speaker from Microsoft at OSCON. While I can imagine that there are employees at the company who genuinely embrace Open Source—and, presumably from this talk, open data—I can’t lay aside my suspicion. Microsoft does not have a benevolent history with competition, so when a representative shows up to talk about an open cloud with open data, I instinctively look for the company’s angle. What is their nefarious plan?

Jean talked about open standards and open data. Data portability, standards, easy migration and deployment, and developer choice. For some reason, when he talks about the “open cloud,” I have thoughts about Microsoft’s OpenDocument move a few years ago. Sure, parts of it were open, but the format as a whole was useless for non-Microsoft tools.

He claimed that Microsoft Windows Azure is an open and interoperable platform. I have a hard time swallowing that. The #oscon IRC channel was not kind in its commentary. A selection from the channel logs:

<b3gl> "Microsoft totally agrees..." as long as you pay your Windows, Azure and MSSQL license fees

<alapapa> standards are great…as long as they're ours

<dbrewer> wow, thanks Microsoft.  You think I should be able to use any language I want, I appreciate your permissions.

<b3gl> dbrewer: Notice he didn't say "We believe if you want to use Linux ...."

Public Static Void

Rob Pike (Google, Inc.)

Programming languages used to be relatively simple, but still fairly powerful. They’ve gotten considerably more complex and confusing. The C++ language was used as an easy target during the talk. Rob went on to bash various (in most cases deservedly) programming languages as a way to lead into what he called the renaissance of language design.

Many of the emerging languages are dynamic and interpreted, and there’s a false dichotomy that they are considered good while the static and compiled languages are considered bad. Part of the problem is that the latter class of languages are old, designed in a different age of computing.

Obviously, the end goal of this talk was to talk about the Go language, which tries to bridge the gap between the dynamic interpreted languages and the static compiled languages.

Toward an Open Cloud

Lew Moorman (Rackspace.com)

Lew’s talk was to introduce OpenStack. Rackspace took the internal software that powers their cloud and donated it to OpenStack. I wonder if this is something we can use at my day job to build an internal cloud. The stack is licensed under the Apache 2 license and they don’t use a dual licensing model, which sounds nice.

I was wrong, the talks weren’t really about demonstrating the wonder of ubiquitous computing and how we can move in that direction so much as a showcase of organizations in the cloud or using the cloud. It was really just one long commercial.

I’ve been told by those that attended the full tutorial that the first half wasn’t really worth attending. In fact, when I arrived at the beginning of the second half, I caught the tail end of the presenter demonstrating how he recreated Twitter using Cassandra, something he dubbed Twissandra. This seems to be the exercise of choice for any distributed system. In a way, that’s smart. Take a highly distributed system everyone is familiar with, explain the challenges faced by such a system, then demonstrate the effectiveness with which the software in question can solve the problem.

In any case, the second half of the tutorial was mostly dedicated to an explanation of how Cassandra distributes its data. The details and, frankly, the delivery weren’t that interesting for me, so I didn’t follow the discussion. It was too high level to keep my interest.

I still think that Cassandra is deserving of some investigation. I have a project in mind that it may be perfect for. At my day job, we have what is essentially a distributed, key-based data store. We’ve had to implement all of the data replication functionality. If Cassandra can alleviate the need to design and implement our own data replication and integrity systems, we can put more effort into the final delivery of the data, instead of its transmission.

For my final session of the day, I’m in Environmental Monitoring with Arduino and Compatibles. Since I attended the Arduino tutorial on Monday, I thought it would be fun to attend a session on using them.

The take-away points, presented up front for our convenience:

• Environmental monitoring is important
• Arduino is cheap and easy
• Small computers are fun

The Arduino is not just the chip and board, but the IDE used to program the board. It also, as I learned on Monday, has a very shallow learning curve.

Russell works for a company doing water monitoring of the Hudson River. He’s using his domain knowledge from his job to explain how one would do something similar on a smaller scale. The values he describes detecting, and the circuits used to take the measurements, are,

• Temperature
• Turbidity
• Salinity – can’t measure this directly, but salinity conducts and we can measure resistance

Now I just need to figure out what I want to monitor at home.

After a long break, an apple, a cup of coffee, and a beer, I’m back in the Perl track.

The full title of this session is, Scratching the 40-Year Itch of Inheritance with Smalltalk-style Traits.

This is not a tutorial. How to use traits is easy, but why to use them is a more complex discussion.

Inheritance is a very complex problem and an easy one to get wrong. Then people start doing things with multiple inheritance and, even if they’re not doing something deliberately stupid, they end up with diamond inheritance. Not only is this a problem, but it’s been a problem for a very long time—40 years, in fact.

Complex systems can lead to deep class hierarchies. When hierarchies are deep, in particular with a dynamic language like Perl, it becomes difficult to determine where a method came from. Even when its known where a method comes from, undesired behavior may be inherited. This becomes worse when multiple inheritance is used.

As systems grow, the problem becomes two-fold:

1. Class responsibility – larger classes are desired
2. Class reuse – smaller classes are desired

Inheritance, by itself, cannot solve this problem. So the solution is to
decouple the sub-problems.

Several solutions have been tried:

• Interfaces
• Delegation
• Mixins – incredibly popular

As expected by the name of this session, traits (or roles in the nomenclature of Moose) solve the problem far better than any of the above solutions. Much of the session involved showing real-world application of roles to clean up code at the BBC.

http://www.oscon.com/oscon2010/public/schedule/detail/13976

I finally left the Perl track. I attended Tim Bunce’s presentation on Devel::NYTProf at OSCON two years ago and, while there have been many enhancements made to module since that time, I expect this year’s talk won’t differ much from the previous one.

This session on Simple Cloud is being presented by IBM’s Cloud Computing Evangelist. The drivers behind this product (is it a product?) are the development and promotion of a standard cloud API. There is some relevancy with my day job, not only because of the possibility of using cloud services, but as a way of getting ideas for the API I develop for our engineers to interact with the batch compute system.

There are several levels of where we can work. The levels start at the wire, where we have to generate and parse data ourselves. From there, we have vendor-specific APIs, service-specific APIs, and finally service-neutral APIs. This last level is where we want to be.

The Simple Cloud API covers three areas: file storage, document storage, and simple queues. Once thought of in these simplified concepts, there really isn’t any reason the interface used by a program can’t be standardized. A program should no more need to concern itself with the implementation details of an individual cloud provider than it does the details of the file system of the computer on which it runs.

The API uses the Factory and Adapter design patterns, with a configuration file used by the Factory object to determine which Adapter should be created. These patterns are exactly what I’ve been looking at for the API I work on at my day job.

A demo of the Simple Cloud API followed. There wasn’t much to these demos. The first showed listing data stored at two different providers. The second showed queue manipulation.

After the demo, the Apache libcloud, which is getting a good deal of vendor support.

Unlike Monday, I chose tutorials on Tuesday that held some relevance to the work I’m doing. At my day job, we have a MySQL database backing a critical production system. We have spent years fighting with it and dealing with its failures and instability. I have a bias towards PostgreSQL, having used it in the past, and finding it a superior database to MySQL. That, however, is beside the point. What is pertinent is that I have been considering a complete redesign of the system, using PostgreSQL as the data source, and a tutorial on the built-in standby and replication capabilities coming with the release of PostgreSQL 9.0 is timely.

The slides for this tutorial were distributed to us when we registered. They are intended to stand on their own, serving as documentation if we later work on implementing the concepts presented here. That said, the information density of the slides didn’t at all detract from the presentation. As a hands-on demonstration, Chander didn’t project the slides very often and, when he did, only referenced them as he spent time explaining the material.

In order to better understand how PostgreSQL implements hot standby and replication, Chander first gave us an overview of how PostgreSQL manages the data a database. I’ll be brief, so this is probably not entirely correct. For efficiency, data is manipulated in 8 kilobyte pages stored in memory, in what is called the shared buffer pool. These pages remain in memory until the pool is exhausted, at which point one or ore infrequently used pages will have any changes written to disk and purged from the pool. This means that while the updates are stored in the pool, there is a (potentially long) window of time in which a crash will cause data loss. To prevent data loss, all update operations are first written to the write-ahead log (WAL) files. During a recovery operation, these WAL files can be used to play back any transactions that were lost in the crash.

Having these WAL files means that, from a given point in time, the database can be reconstructed. It’s not a stretch to shift the playback of these WAL files into real time on a secondary system. This automatically creates the possibility of a live replicated database, which can be queried in place of the primary database.

The rest of the tutorial was devoted to demonstrating how to set up and use warm standby databases, hot standby databases, and streaming replication.

I’m just back from lunch at Burgerville with Juan and Jonathan. On the way back into the convention center, I ran into Alasdair, who has been attending the hardware hacking sessions. That made me think that I may want to try to find non-Perl sessions to attend. After all, I tend to keep up with Perl news, so the sessions are of marginal usefulness. Unfortunately, nothing on the schedule looked very interesting to me. I was curious about the session on Open Source Tool Chains for Cloud Computing until I read the description. While it looked cool, it wouldn’t be useful for me in my work. The session would go through provisioning, setup, and maintenance of hosts, all of which we already have well-entrenched solutions for in my day job. So, I ended up back in the Perl track. My friends in the San Diego Perl Mongers group will appreciate that, I think.

Anyway, on to the session.

The name Perl 6 is a language specification, rather than any particular implementation. All of the references and links off-handedly mentioned in this post are available from the Perl 6 website.

Patrick is the lead developer of Rakudo Perl, which is the most feature complete and up-to-date.

Perl 6 has a language specification and a test suite. There are still many places in Perl 6 that are not being tested yet.

Rakudo * (Star) is scheduled to be released a week from tomorrow, targeted at being a useful, usable, early adopter distribution.

At this point, Patrick began to enumerate the new language features and how they work in Perl 6, such as variables, loops, interpolation, and so on. I won’t go into these here, since there are numerous places on the Web where this has been documented.

About half way through this session, I realized that “r0ml” was presenting in another room. If I’d noticed that before, I would have attended that session.

This talk could be titled something along the lines of “Lessons Learned from Project Management.”

Jesse Vincent is the current Perl 5 pumpking, which for the moment can be thought of as the project janitor.

People who say “Perl is dead” or that Perl hackers are “desperate” are behind the times.

There are a lot of exiting things happening that are not in the Perl core. Audrey Tang has said that “CPAN is the language, Perl is the syntax.” Like Piers in the previous session, Jesse enumerated a handful of things that make Perl awesome:

• Moose
• Plack
• cpanm – makes installing CPAN modules Just Work
• Devel::Declare
• Devel::NYTProf

While some of the coolest new things happening in the CPAN world, it merely scratches the surface of what is available.

About three months ago, Jesse uploaded Perl 5.12. Amazingly, no one has reported any critical regressions.

Jesse has been assured that Rakudo * will be out next week, on 29 July. However, Perl 6 will not replace Perl 5, which has paid Jesse’s mortgage for many, many years. Also, thanks to Perl 5.12, Perl 5.10 is no longer “too new to use.”

Perl 5.12 marks the latest release in the process of cleaning up the inernals and adding much desired features. Some of the highlights:

• Deprecations warn by default
• suidperl is dead
• package Foo::Bar 1.0; – better version import syntax
• Y2038 compliant – thanks to Schwern
• Unicode improvements; upgrade to 5.2
• Pluggable keywords
• Overridable function lookup
• Dtrace support
• Deprecated modules – Class::ISA, Pod::Plainer, Shell, Switch (but still on CPAN)
• Yadda, yadda, yadda operator

Jesse believes the best new thing in Perl 5.12 is the release process, including him as the pumpking. Twenty years ago, Perl didn’t use version control. He recommends learning from this mistake.

It took five years to release Perl 5.10, after burning through two pumpkings.

Before 5.12, maintenance releases contained all sorts of bug fixes and updates, but could not break binary compatibility. Doing so was a huge task, was very difficult, and, contrary to its name, is unmaintainable. Even without all this work, the pumpking’s job is a lot of work. Jesse really doesn’t want to burn out after a release of Perl.

Traditionally, the process of turning someone with the necessary skills to be the pumpking involves preventing them from using those skills and replacing them with management skills. It’s a shame.

The system is broken and Perl 5 isn’t going anywhere, so how can it be fixed? We can reinvent it, but that’s already being done by Perl 6. Alternatively, we can refactor it. There is no reason many of the skills and duties required of the pumpking can’t be delegated out to people with those skills. In effect, the most important skill and duty for the pumpking is project management.

The 5.9 releases, leading up to 5.10, were haphazard. The 5.11 releases, leading up to 5.12, have settled into a new release every month on the twentieth, with a couple of exceptions. The 5.13 series has followed suit. One of the reasons this was possible was documenting the entire release process.

Releases in the 5.12 series are on a fixed schedule, every three months. A release schedule has been created for 5.14, too.

One of the things I’ve learned working in an enterprise and my observations of the Fedora Project is that good project management is vital. Jesse Vincent is exactly what Perl needed and he continues to demonstrate that, with regular, high quality releases of Perl. What’s more, he is a good spokesman for the project, being able to come to OSCON and give a session on all of this detail in a cojent and interesting format.

After reviewing today’s session schedule, I quickly came to the conclusion that I will spend my entire day sitting in the room “Portland 256.” This is, apparently, where the Perl track is located.

Paul Fenwick introduced Piers in song, to the tune of Gilligan’s Island.

Piers switched from Perl to Ruby a while back and swore that he wouldn’t return to Perl until 6. Facetiously, the reason he switched to Ruby was the handsome community associated with it and he reason he switched back to Perl was the amazingly supportive community associted with it. He began with a point about programming style. We think of code as describing what we are doing, but in reality the majority of our code actually describes how we are doing it. This infrastructure code is noise.

More seriously, he absolutely hated unrolling the @_ variable in every function. In such a high level language like Perl, why must we pop arguments off the stack in the same manner we would in an assembly language? This leads to long subroutines, every single one containing anti-patterns designed to implement the language infrastructure, instead of the language doing the work for us.

Moose does a lot to improve writing classes, using a more declarative syntax. However, even within Moose methods we need to write the infrastructure code. The MooseX::Declare module solves this problem, giving method syntax a more declarative style. By moving the infrastructure code out of sight, we can better focus on what we are trying to do, rather than how we are doing it.

Piers proceeded to list the modules that “rock” and brought him back to Perl:

• Plack
• Devel::NYTProf
• Moose

Perl’s object-orientation absolutely “sucks.” However, this turns out to be a good thing. It allows very clever people to create modules that extend the semantics of the language. In a language like Ruby, which has a good object-orientation built-in, it’s essentially stuck. If, in the future better ideas of object-orientation are developed, they can be implemented in Perl far more easily than in Ruby. An interesting point: sometimes when the tool sucks, things are better. People develop layers of tools that enhance and extend the original.

It also helps that the Perl release schedule has accelerated.

Piers continued with a high-level, hand-waving explanation of how MooseX::Declare works. While not informative, it was entertaining. Including a video of Matt Trout attempting to hypnotize the room.

Piers ended by thanking the Perl community and expressing how good it feels to be back into it and developing in Perl again.

It’s Wednesday morning at the O’Reilly Open Source Convention, which means it’s time for the introductory keynotes. The first thing I’ve noticed this morning is how crowded it is. Certainly more so than when I was last here in 2008. I don’t know if that’s just because we aren’t being given breakfast in the expo hall this year, so everyone is crowded into the area outside the ballroom. Another thing I’ve noticed is the gender makeup of the attendees. While still overwhelmingly male, I have noticed more women in attendance this year. Diversity is good.

Without any further ado, we’re getting started.

Welcome

Allison Randal, Edd Dumbill (O’Reilly Media Inc.)

This year’s co-chairs welcomed us and talked a bit about OSCON this year. Obviously, there wasn’t a lot of content, but they did mention the Android Hands-on event being sponsored by Google tonight. I did register for that, since it sounds like it will be fun.

Keynote

Tim O’Reilly (O’Reilly Media Inc.)

First up is the namesake of the convention. Every year he presents his vision, not just for the conference, but for the future he wants to see. He has been steering his company away from being just a book publisher or a content producer, but a company trying to make the world a better place. He urges the Open Source community to think about the cloud. Don’t just think about Linux, or whatever project, but about the bigger picture and where we’re going as a society.

He is fascinated by the ability of technology to reinvent government, a concept he’s dubbed “Gov 2.0.” We fall into the cycle of thinking of government as a vending machine, something we simply get things out of, and get frustrated when we don’t. Over the last few years, he has been talking about government as a platform.

We shouldn’t think just about selling to the enterprise, but about building a better world. We all benefit when that happens.

Coding the Next Generation of American History

Jennifer Pahlka (Code for America)

The government doesn’t have to be this obscure, opaque thing we get stuff from. It can be a platform for us to work together. Currently, the majority of the municipal workforce is over 40, and a significant percentage will retire soon. This creates a huge age gap, which leads to a technology gap.

In Oakland, California, the city workers can’t search city council meeting notes online. The method of entering the data in the computer is to scan the written notes, which are impossible for them to index.

Code for America was created to encourage younger, technologically-savvy individuals to apply their talents to government. It’s designed to create technology to open up government, to make it more accessible to the citizens. It’s a little like the iPhone or Android ecosystems. Government provides the platform, essentially the data. We, the citizens, build the apps.

Keynote

Bryan Sivak (Government of the District of Columbia

Those in the government of DC are big fans of Open Source, running Linux among other projects. They’ve long talked about being committed to Open Source, partly to save the taxpayers’ money. Unfortunately, much of this commitment is all talk.

For any project used in DC, forms are required to be filled out, justifying the choice and the expense. On this form is the question, “What Open Source projects were considered?” This is often left blank and still slips through without comment.

Proprietary solutions tend to come with copious documentation and an implementation plan. Open Source projects are more open-ended, which requires people within the government to have that vision and that creativity. This goes back to the age and technology gaps mentioned previously.

It’s good that these challenges have been identified and are being addressed.

Got MeeGo?

Dirk Hohndel (Intel Corporation)

MeeGo is the result of the unification of Moblin and Maemo. It targets netbooks, handset, tablets, and just about anything designed to be more mobile than a traditional notebook. It offers a full client Linux Open Source stack, from the kernel all the way up to the user interface, including the flexibility to support proprietary devices.

Dirk went over the primary goals and philosophy of the project (to be completely open), then went on to describe the organization of MeeGo at a high level. This included both the technical building blocks and the relationship with upstream projects.

Is Your Data Free?

Stormy Peters (GNOME Foundation)

Many of us use completely Free software on our computers, some even insist on it. However, when it comes to online services, we’ve gotten lazy.

Free software was driven by two types of people. There were those who advocated that all software should be Free, that it should be available to all people, regardless of their means. There were others who used and advocated Free software because they wanted something that didn’t crash. It’s this latter It Just Works motivation that Stormy believes has caused us to get lazy about demanding Freedom from our Web services.

She asks how many of us control our own email or have alternative ways to access it if something should happen to the primary service. What if Twitter or Facebook decides to delete your account? What happens to your data? She then went through a few examples of alternative services that have open data policies, such as Identica and Tomboy Online (it’s funny, I don’t use Tomboy because I won’t use Mono).

How many of us have read the agreements when signing up for Web services? Do we know who owns our data? Can we back it up ourselves? Who owns it, both while we’re using the service and if or when we decide to delete our data?

Keynote

Marten Mickos (Eucalyptus Systems)

The shift to the cloud is causing computing to scale, both up and out, far faster and far larger than any of the previous trends (mainframes, minicomputers, or client/server).

Many of the Open Source licenses were designed in an environment where everyone runs software on their own computers, software that requires distribution to be useful. Today we’re seeing more services being offered by companies running software within their own grids. Users never run the software themselves but rather send data in and get data out.

Eucalyptus is designed to be a highly scalable platform for on-premise use. As someone who supports many thousands of hosts in many data centers, this product has intrigued me for a while. Unfortunately, I’ve never taken the time to investigate it. It’s nice to see that those behind the company are committed to Open Source, using the split model. Users are free to download and use the software, while the company sells a supported version to enterprise.

The keynote sessions at OSCON tend to drag on for a while, making it difficult to pay attention the whole time. But they are finally over for now. We have a break before the first session of the day. I’m going to try to get some work done on yesterday’s posts before starting on my long day of Perl sessions.

I’m really impressed with the wireless network today. It had its problems during the tutorials on Monday and Tuesday. Traditionally, the network becomes almost unusable on Wednesday morning. This year, however, I have been able to connect to the Internet and write this blog post without any frustration.

For lunch, I met up with some coworkers and some friends to head across the river for lunch at Old Town Pizza. I had a small sausage and mushroom pizza, and washed that down with a pale ale.

After the Arduino tutorial, having sat down for much of the day, I grew restless. I really wanted to take a walk. More importantly, I really wanted to make my way over to Rogue Ales Public House for some beer. So I called Jonathan and we made our way over there. We each started with a four beer sampler.

I started with the Chatoe Oregasmic, finding it to be a pleasant, light pale ale with moderate hoppiness. Upon tasting it, one of my coworkers commented that it was what he expected the pale ale, which he had ordered to be.

Second in line was the Double Mocha Porter. It had a faint mocha aroma, but very little of this made its way to my pallette. I could detect a hint of smokiness, if I concentrated on it.  For something advertised as a double mocha, I was disappointed.

Having enjoyed Rogue’s Dead Guy Ale in the past, I chose for my third beer the Double Dead Guy Ale.  I don’t think I was fair to this beer. The name made me think of Stone’s Double Bastard and the Double Dead Guy Ale is nothing like that. Even so, I found it smooth with a pleasant maltiness and light hop flavors.

Saving what I expected to be the best for last, I finished with the Brutal IPA While nicely hopped, I was left disappointed after building my expectations on what I consider to be its undeserved moniker. Once I got over that, I still found it to be a perfectly enjoyabl beer. It had mild malty notes and, like the other Rogue ales I sampled, it too was smooth.  I found it to be an all around decent IPA.  Since Juan wasn’t able to join us for dinner, I bought a bottle of the Brutal IPA to share with him later.

After I had finished my samples, it was the decision of those in my party that I was criminally without beer and that, to pay penance, I was to order the Issaquah Menage A Frog.  When the bartender told me it was only available in a 12 ounce glass, I suspected that an imperial style ale.  The aroma and taste soon confirmed this.  Coming in at 9% ABV, it was not as strong as some of the ales I occasionally drink back home in San Diego, but it went very well with the beer and cheese stew I had for dinner.

And now it’s late, just a few minutes until two o’clock in the morning. I should have closed my computer and gone to bed hours ago, but I refused to do so knowing that my first day of OSCON blog entries were unfinished. Hopefully, I will have more food and beer to write about tomorrow.

In the beginning, I was shamed.  While I tried and failed to follow the Linux installation instructions, my coworker, Debbie, was able to plug my Arduino board into her Microsoft Windows notebook and get the first example running.  When the udev tip didn’t work, things were looking bleak for my attempt to control open hardware with an open operating system.  Finally, a trip to Google landed me right back on the Arduno wiki at the installation instructions for Fedora.  Finally, I could upload code to my Arduino board.  After getting the initial example to work, I modified it to change the pattern of the blinking on-board LED bulb:

int ledPin = 13;

void setup() {
    pinMode(ledPin, OUTPUT);
}

void loop() {
    digitalWrite(ledPin, HIGH); delay(300);
    digitalWrite(ledPin, LOW);  delay(300);
    digitalWrite(ledPin, HIGH); delay(300);
    digitalWrite(ledPin, LOW);  delay(300);
    digitalWrite(ledPin, HIGH); delay(1000);
    digitalWrite(ledPin, LOW);  delay(1000);
}

While we were playing with our new toys, we were treated to the history of the Arduino project, some other open hardware projects, and some of the things people have done with them.  Unfortunately, I was too busy playing with my new toy to take notes on these things, so the history lesson, by way of Wikipedia, is left as an exercise for the reader.

The editor embedded in the Arduino IDE leaves a lot to be desired.  It’s like Microsoft Notepad with syntax coloring.  My coworker found a setting that forces the IDE to use an external editor.  Basically, all it does is to make the editing window read-only.  Files edited outside of the IDE are re-read when the code is compiled.  In short order, I was able to find a Vim syntax file for Arduino code files.

After the break, we were introduced to using the Arduino board in combination with a breadboard, which allows for the creation of more complex circuits.  I’m excited, because I still have the breadboard, components, and multi-meter I bought in college for a computer engineering class.  I’ve been waiting all these years to finally have an excuse to dig them out of the closet and put them to use.  The Arduino will be a fun learning tool when my daughter is older, too.

To commence our unstructured time, which would last until the end of the tutorial (and the day), we were shown a simple circuit to wire up between the Arduino board and the breadboard.  Using a copy of the first blinking code, we could acheive the same effect of blinking the external LED simply by modifying which pin was referenced.  I took this a step further and made my LED bulb pulse like the light on a suspended MacBook.

I’m glad I decided to attend the Arduino tutorial this year. I’ve just picked up yet another hobby I don’t have time for.

The version of Blender available in the Fedora 13 package repository is 2.49b, but the tutorial focused on the beta version of 2.5, which has a redesigned user interface and new and improved features.  A Linux version was available on the internal cache website offered by OSCON, but it was 32 bit.  I ended up downloading a copy from the Blender website (the conference wifi doesn’t start to get really bad until Wednesday).  Unfortunately, Blender proved unstable and would frequently crash with a segmentation fault.  Matthew had provided files to serve as starting points for each section of the tutorial, so it was relatively easy to follow along, even if I didn’t complete the previous section.

Matthew walked us through generating a simple animation of a flying saucer approaching a planet and hitting it with a beam of light.  We started with simple shapes, two spheres, one flattened, for the saucer, a cone for the beam of light, and another sphere for the planet.  From there we learned how to apply surfaces and textures, manipulate light sources, and perform a simple animation.

All in all, I think the tutorial was worthwhile.  If I had launched Blender without it, I would be lost.  I’m still lost, but at least I have some semblance of an idea about how it works.

At the beginning of the trip, I ran into a coworker, Juan, at the airport in San Diego, who was on his way to OSCON, too.  We weren’t able to sit together on the flight, but that worked out in the end.  A man was traveling with his son of around five years.  The son had the seat next to mine, while the father was several rows back.  I offered to trade seats with the father, so he could sit with his son.  One of the flight attendants bought me a beer for my trouble.  On top of all that, the we arrived in Portland earlier than expected.

After checking into our respective hotels, we swung by the Oregon Convention Center to register for OSCON and pick up our badges and associated crap.  Actually, a mug was included in the bag o’ stuff, which I can actually use.  Plus, the bag can be kept in the trunk of my car for use at farmers markets.

Finally, it was time for dinner.  Juan and I met up with a friend of mine from the San Diego Perl Mongers and hopped on the MAX to head downtown.  After wandering around aimlessly for a bit, I searched for Kells Irish Restaurant & Pub on my phone and we found it in short order, taking a seat out back in their new beer garden.  I washed a corned beef and turkey sandwich down with three pints of Mt. Hood Ice Axe IPA and one pint of Kilkenny Irish Cream Ale.  Shortly after we finished our food, we were joined by two more coworkers, who ordered some food of their own.  We spent some time doing what one does in an Irish pub, namely drinking and talking, then we made a failed attempt to find coffee.

That brings an end to OSCON travel day.  Tomorrow morning I will head to the convention center for breakfast and will hopefully run into more people I know (or will meet new friends).  I have two tutorials scheduled for tomorrow: Introduction to 3D Animation with Blender and Get Started with the Arduino – A Hands-On Introductory Workshop. I know these tutorials don’t appear obviously relevent to my job, but I’m looking at them as useful for relaxing and enriching.  One of the reasons I like to attend OSCON is because I return to work refreshed and with a state of mind more prone to imagining creative solutions.  So, tutorials outside of my immediate area of expertise are exactly what I need when I come here.

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.