Reports from OSCON 2012

Day 1


It is Monday morning, and I am attending a(nother) tutorial on git (Get Better at Git). I am fully convinced that git is a better tool than Subversion at this point; I am also convinced it’s harder to fully understand and use. How these things can both be true speaks to the complexity of managing source code. It’s pretty clear that in a highly collaborative project, git is the way to go. That isn’t to say there aren’t thousands of projects using Subversion successfully, but, mastery of git would certainly reduce the pain in reaching the same success.

But mastery of git takes time. Fluency takes time. It occurs to me that the quickest path to fluency is immersion, and taking one or two classes on git does not immersion make. I do long, at times, to work in a hardcore dev shop to become fluent in git… just as I long, yet more often, to live in Quebec City or Paris and become fluent in French.


My Monday afternoon session is on Moose, the most popular set of modules that extends Perl’s object support. As with git, I won’t write all my technical notes here… I’m just going to soak it in. Immerse myself as it were for the three hours I’ll have.

Okay I lied. I am already sort of liking Moose. When defining an object, you can label its attributes (think ‘values’) as ‘ro’ (read-only) or ‘rw’ (guess), make any of them required, and strongly type them. This is really fantastic. Honestly, I am often fairly lazy on the server side when it comes to validation, having already done the work on the client end in Javascript to try and assure the right values come in. But the client side is not completely in a developer’s controlling hands, so, it cannot be relied upon. Granted, Moose will crash your program if your constraints are violated, but I’d rather crash in such event than enter into an unexpected state.

I’m tempted to rejigger my Remedy and Pinnacle modules to use Moose, but I sort of hope I can get away with Moose::Lite. Performance won’t be much of an issue running atop FastCGI, but the dependency tree for Moose proper is massive, and I don’t want to acquire that much baggage quite yet.

But dang, Moose is neat. I love the concept of ‘advise’. This is a kind of flow control in object land. You can define what happens ‘before’ or ‘after’ a method is run, or even wrap a method with ‘around’ if you need access to its internals. The best analogy I can make is probably applicable to object orientation in general… it’s like stuffing your money deeper in your pocket so it has less chance of falling out. Substitue ‘logic’ for ‘money’.

When you have a class that inherits from more than one, it is called ‘diamond’ or ‘multiple inheritance’. It’s dodgy and error prone. Moose solves this with the concept of ‘roles’. I’m trying to wrap my mind around this, but it seems as though a role is a kind of validation for the relationship between classes. Ah: it enables horizontal code reuse (roles and classes) rather than strictly vertical (classes and sub-classes). Apparently, using roles in Moose is far more common than subclassing at all.

Moose finally broke my mind this afternoon. Much of this I’d need to work with to begin to understand.

Day 2

Modern Perl

Tuesday morning and I am pleased to be attending New Features of the Modern Perls by Damian Conway. Damian’s talks are worth the price of admission in themselves and everything else is gravy.

Something I did not know: when upgrading from 5.8, any XS modules you use need to be recompiled for any new version of Perl you move to. Damian is making a plea for Perl developers to upgrade, commenting that the Perl community will only be supporting the latest release and the previous two releases… meaning, security updates only for older versions of Perl. This means if you encounter an obscure, non-security related bug in an older version of Perl, it may not get fixed, and more importantly, module authors will be requiring more recent versions of Perl and the CPAN will move past you. He recommends targeting 5.14 at this time.

Interestingly, to preserve backward compatibility, you must enable new features explicitly in Perl versions starting with 5.10. This is to prevent new keywords from accidentally clashing with user subroutine names. But if you’re ready to move forward, you can enable all features in addition to requiring a minimum version of Perl simply with:

use v5.14

Now he’s making me want to upgrade just to use say (which is print with an implicit newline). Also, smartmatching (the new ~~ operator) is brilliant, a feature Damian invented for Perl. Another double-character operator added to recent Perls is //, the defined-or operator, which is better for setting default values (as below) than using ||, because || tests for true/false, not defined-ness.

my $number = $number // 42;

The above case would assign $number a value of 0 if it had started off that way, whereas using || would have seen a 0 as false and assigned $number the 42.

Damian on Moose: “It annoys me just enough so that I don’t want to use it.” Now, he also has a lot to say in favor of Moose, but mostly complains of the startup time and isn’t crazy about the declaration syntax.

Another very cool feature in recent Perls is named captures out of regexes… numbered captures are too easy to get wrong. Think using named parameters to pass to subroutines instead of an order-dependent array. It’s just better.

jQuery Mobile

My Tuesday afternoon session is on jQuery Mobile. It’s safe to assume that I’ll be building some mobile apps in the coming decade, and this is one of my likely tools. If I remain at the University during that time, jQuery Mobile is a *more* likely platform than native applications targeted to iOS, Android or some other emerging mobile OS. That is, unless successful alum donate a native apps development budget. But that wouldn’t be the best use of money, would it?

I’ve been following the jQuery projects (core, jQueryUI, and now jQuery Mobile) pretty closely for the past few years, and now load core and UI by default in my webstuff. Bring mobile into the mix is the logical next step. I already have an idea of the app I want to write… but have a ton of backend work to complete before I get proper access to the data I need. I suppose that shouldn’t stop me from prototyping the front end… in my free time (stop laughing).

Day 3

Day 3 begins the shorter sessions of the conference proper, following the keynotes. They had the mayor this year, who proclaimed Portland an ‘open source city’, and who made some funny jokes. There were some other semi-inspiring appearances amongst the keynotes, but as I decided to watch instead of type, I don’t have the time to relay these now.

Perl 5 Today, Tomorrow and Christmas is the first session I am attending this morning. Ricardo Signes is the current Perl 5 project lead (Pumpking), so you might call him a reliable source on the subject. He was also the guy who presented on Moose a couple days ago.

This is mostly a talk about the challenges in managing the Perl project, most of which (surprise!) are human in nature. Apparently the p5p (Perl 5 Porters) mailing list is a great place to get into an argument but not always a great place for a Pumpking to spend his days. There is a lot of talk at these conferences about ‘getting along’ in open source communities. Now he’s making an analogy I’ve often thought of, that of software coming about via ‘intelligent evolution’… a mix between intelligent design and evolution.

Next up, Programming In The Future, a look at how the craft might evolve in the next 25 years through the lens of how Perl has evolved over the past 25. This turned out to be a nit of a meandering talk, but included an interesting history of the most significant moments in Perl history, 1987 to present. It’s hard to imagine you couldn’t write a Perl module until 1994. Now he’s talking about parallel and functional programming, two somewhat advanced programming tasks that people seem to imagine becoming easier in the future, and some examples of how we do these things in Perl today.

Another yummy lunch, this one thanks to Google, and now I am in Test Driven UI Development. This is a very challenging endeavor. This talk centers on a toolset from the Java/Groovy world, but which could be applied to other platforms. I must say though: I cannot watch much of this test-driven development stuff without being secretly glad I don’t do it. I just seems like another codebase to maintain, which itself would always be breaking, perhaps saving me an error here or there, but which would in general dilute my productivity. It is interesting to see the speaker write the test before he writes the HTML for a simple form, though, complete with human readable comments… all very nice documentation. The notion of ‘testable code’ is about being able to select the elements in the DOM that you need to test, so, jQuery-like, you may be adding ids, but in this case, perhaps only to select them in the test suite. Dear me. The speaker discourages uses CSS classes as selectors in your test suite, because you may have front end developers mucking with class names. He mentions testing AJAX can be tricky, which I would have guessed, but that you can access return methods with jQuery and similar in order to check success in many cases.

To finish off the day, I’m attending The Conway Channel, another Damian Conway talk. Entertaining as expected, and I immediately went to play with IO::Prompter and Lingua::EN::Inflect, two of the modules he has updated this year. However IO::Prompter required Perl 5.10+, so… heck, why have I been putting off trying Perlbrew so I can run any version of Perl that I want? Now building and compiling 5.14.2. :)

Day 4

Thursday morning and I had been planning to attend this EFF session, but it was full. So I walked around the Expo Hall, checked out the booths, grabbed some stickers and pens, that kind of stuff.

Next up is the long awaited Taming Perl Regexes, another Damian Conway talk, in which he will is launching a tool called ‘rxrx’ that he had hinted at in the video he sent to YAPC::NA. It’s an incredible debugger for regular expressions, installable from CPAN as Regexp::Debugger. I will try to post a short screen cap of this tool at work once I get it installed.

I’m starting my afternoon with Advanced MySQL Replication Architectures, presented by some Oracle guys. So far this is high-level view of different replication architectures; I was hoping for a little how-to with some commands. Oh well, sometimes you hit a session that isn’t what you’re looking for.

Next up is Cooking Perl with Chef, which I have high hopes for. Having used Perlbrew for the first time today, I am feeling bold about tossing Perl itself around. Here are the problems and their solutions as presented:

  • application-specific Perl: Perlbrew
  • application-specific @INC Path: local::lib
  • versioned application code: git, SVN, etc.
  • versioned module dependencies: Carton
  • automate the previous four: Chef (scripted using Ruby)

Chef usually requires a server of its own, but if you want to save on that overhead and only have a handful of nodes to deploy to, you can use Chef Solo. Still, I think Chef would be the last piece I’d add to this puzzle, if at all, considering that I already have a scripted deployment routine that is beginning to pull all the same levers and push the same buttons. But adding Perlbrew and Carton (which leverages local::lib) are musts. Hopefully I’ll be deploying with those within a year. We’ll see!

These last session I am attending today is What Every Web Developer Should Know About Database Optimization. This was largely review for me, but I did get a reminder that occasionally JOIN order could be important, and oddly enough, yet another warning about ORMs. Object Relational Mappers can be hell on your database, especially if you don’t give the proper cues, similar to how you’d optimize SQL, just not directly. Explain to me why I want to use an ORM, again? (I know, I know…)

At 7pm (PST of course) is Larry Wall’s State of the Onion address, the official update on Perl’s present and future, but I’m whupped.

Day 5

I skipped the keynotes this morning in favor of a long breakfast. This last day is a half day of sessions.

The first for me is another database session: Optimizing MySQL Configuration. Thus far we’re getting a list of optimizations not to try. The

utility sounds worth trying out. Here’s an interesting recommendation: set skip_name_resolve to 1 and don’t use hostnames in GRANTs. It makes sense that skipping name lookups would increase performance a tad, but, it also increases your administrative overhead in maintaining IP addresses in GRANTs, since IPs change more often than names. Now we are going over the million and one configuration variables available to change in MySQL, many of which are MyISAM or InnoDB dependent (this had me detouring to a storage engine comparison since I have been using MyISAM all this time).

I don’t think I’d like to be the steward of a large database that was always needing tuning. It seems so fiddly.

Next up, some attention to the front end of things after dwelling on the back end for while: Designing HTML5 Components. Okay, this was not what I expected at all. He is using a Java framework called Vaadin (the Finnish word for ‘reindeer’) and the goal is apparently to create reusable web components. This is really yet another web framework, this one from Java land, and by reusable he means, reusable in this particular framework’s ecosystem. You write in Java, and it compiles some Javascript for each of your target browsers. Pretty slick, but you’ve got to go ‘all in’ to get the bennies.

The last session I am attending this OSCON is Instantly Better Vim. Another Damian Conway talk, a longer version of which I’ve previously attended, but let’s face it… I still haven’t adopted most of the Vim tricks he taught me the first time, and I could use a refresher.

Wow… by the end of this conference, word has gotten around about Damian’s talks. He is just too entertaining to miss. They had to get a second room and pull out the wall to accomodate his final talk. And as usual he sent me away wanting to try some Vim tricks right away.

Well, that was my OSCON 2012. As usual, a very well organized event, chock full of learning and networking opportunities, jobs for those that want them, and generalized geeky inspiration. I often find myself back in the hotel room coding, or tucked away somewhere in the conference hall, slowly exploring some of the new ideas I’ve been exposed to. Thanks to UNH for my funding.

One Response to “Reports from OSCON 2012”

  1. Bill Costa says:

    In my own code I’ve used table driven parameter definitions for doing the ‘ro’, ‘rw’ sort of constraints as well as similar automatic validations. I figured it was a wheel already invented and I too stumbled upon Moose. But when I saw the depth of dependancies I quickly backed away. I’ll have to take a look at Moose-Lite to see if that would be easier to swallow.

Leave a Reply

Panorama theme by Themocracy