My Primal Meal Photo

Primal Snacking by cdgrau, on Flickr

A Simple Foraged Primal Dinner

Yesterday, Mark’s Daily Apple held a primal meal photo contest. All I had to do was submit a photo of a primal meal I ate. For most people, this would be dinner; something they cooked up after work.

Unfortunately, on the day of the contest, I didn’t have time to cook dinner. However, that didn’t mean I wasn’t going to eat dinner. When I got home, before I headed off to my karate class, I “foraged” through the wilds of my refrigerator for something to eat. We always have hard cooked eggs and salami on hand, for snacking or quick dinners. We’ve also been buying strawberries every week, since they’re a year-round crop in Southern California. And that was my entry. It’s not the fanciest primal meal anyone has come up with, but that’s okay; the winner will be picked randomly from all of the entries.

Also, if anyone is interested in having a “Grokfeast” for a chance to win a cow, let me know.

Gone Primal

A couple of years ago, when my wife was pregnant with our daughter, my parents were reading through Good Calories, Bad Calories, by Gary Taubes, and getting started with the paleolithic, or paleo, diet. It was a happy coincidence, as my wife was diagnosed with gestational diabetes. The diet information she received from my parents kept the condition under control without the need for drugs. In fact, her doctor thought she was lying about the low blood sugar numbers she was reporting and had her tested in the office during each visit.

I wasn’t immediately convinced. So many years of indoctrination by the advice of the so-called experts and the recommendations of the United States government left me believing at an emotional level that carbohydrates are not only harmless, but necessary to my existence. Plus, I really like oatmeal and granola.

It was hard to argue with results and, after following Dr. Eades on Twitter for a while, I tried the diet. It was okay, but I didn’t stick to it very well. I was still addicted to sugar and convinced that I could lose weight in the gym. I did lose a little weight and enjoyed being able to eat all the food I actually like, but have been conditioned to believe is unhealthy, without the guilt (no one likes potatoes anyway, only what they put on potatoes).

One blog that I’d run across a couple of times, but didn’t think to bookmark was Mark’s Daily Apple. I could remembered it as the interesting blog with the photo of the guy lounging in the grass, wearing his Vibram FiveFingers (I have a pair, too). My Google searches turned up nothing. Finally, one of the people I follow on Twitter posted a link. Suddenly, it wasn’t just about the diet for me. Mark Sisson’s idea of an Primal Lifestyle was the missing piece. I jumped in with both feet.

Now, my typical daily sustenance looks something like this:

Breakfast almost always consists of three fried eggs and two sausage links. I cook a third sausage link for my daughter to eat when she wakes up. I rarely skip breakfast (though strangely I did today) and haven’t deviated from this menu in over a year.

Lunch used to be a protein shake, plain whole milk yogurt with berries and stevia, and three bread-less sandwich rolls. A few weeks ago, I stopped eating the sandwich rolls. I suspect that changes to my metabolism have left me less hungry at lunch, so I practice intermittent fasting. Sometimes I’ll have the yogurt, sometimes I’ll get a burrito at the taco shop (I unwrap it and only eat the innards), and sometimes I’ll skip lunch altogether.

Dinner varies from day to day, but only a little. I typically cook a large cut of meat, like beef chuck or pork shoulder, in a slow cooker on Sunday, which gives us enough meat for the week. For a weeknight dinner, I’ll sauté onions, peppers, and garlic in coconut oil, then add some of the leftover meat, sometimes finishing by adding sour cream for a tangy cream sauce. Tonight I used a three cheese tomato sauce from Trader Joe’s.

My workout has changed significantly, too. I was a big nerd growing up, so I never went to the gym. I started going on-and-off in college, but have started going almost every day over the last eight months. Fortunately, I had a few sessions with a personal trainer once, and I’ve always followed her advice to avoid the machines and use free weights. But I was the typical guy, doing repetitive sets of weights, focusing on those beach muscles.

Since the release of Primal Blueprint Fitness, I no longer worry so much about going to the gym every day, trying to lift ever heavier weights. For one thing, it’s boring. Also, I think I overdid it and hurt my shoulder. I certainly don’t miss the horribly dull “chronic cardo.” Now I work out using my own body weight and sprint occasionally.

Suddenly I’m losing more weight. Fast. Even though I’ve taken a break from the gym for the last couple of weeks to rest my shoulder.

I’ve had a draft of this post saved for about two months, but never got around to polishing it for publication, until now. A couple of days ago, Mark Sisson kicked off the Primal Blueprint 30-Day Challenge. This is just what I needed, especially after cheating on my diet over the Labor Day weekend. I’m not half as dedicated to the lifestyle as most of the people who comment on Mark’s Daily Apple, but I’m going to try to join in the challenge and have some fun anyway.

Coasting to Work

I’ve been commuting between home in San Marcos and work Sorrento Valley every day since I bought my town home three and a half years ago. With the few exceptions when I’ve either been able to telecommute or traffic has been light, it has been an altogether miserable experience. At the beginning of the current recession, traffic improved a bit, but apparently there are still plenty of people who need to drive north on Interstate 5 past Del Mar in San Diego, because this summer has been absolutely awful.

I’ve shifted my schedule earlier for a couple of reasons. First, leaving home before seven o’clock in the morning gets me to work before traffic builds on the freeway; and second, leaving work before five o’clock in the evening gets me home in time for dinner with my daughter. Unfortunately, this summer has seen bumper-to-bumper traffic starting as early as three o’clock in the afternoon.

I’ve gazed longingly at the Coaster as it effortlessly glided by on its rails along the coast, while I crept along at a snail’s pace behind the wheel of my car. For the last three weeks—not coincidently since my return from Portland, where I’ve always enjoyed mass transit—I’ve done more than admire the train from afar, I’ve started to seriously consider using it.

So on Friday I did. I left for work a bit earlier than usual, so I could catch the 6:50 AM train at the Carlsbad Poinsettia station. After purchasing my $11 round-trip ticket, I crossed a footbridge to the boarding area. The tracks aren’t labelled, so I didn’t know which side I should wait on. After a few minutes, people had started to gather on the side I was on, so I guessed it to be the correct one.

When the train arrived, I headed to the upper level, because I wanted to enjoy the view. I wasn’t disappointed. The view of the beaches, the ocean, and the Del Mar Racetrack was gorgeous. In addition to that, I was able to use Twitter and read RSS feeds, something I’ve obviously never been able to do in the car. Twenty-six minutes later I was walking off the train at the Sorrento Valley station. A shuttle took me up the hill and dropped me off across the street from my office. I arrived at the same time, 7:25 AM, I always do.

I had a meeting scheduled from 3:00 to 4:00 PM, so I expected to catch the 4:26 PM shuttle and the 4:51 PM train. Fortunately, the meeting ended early, which allowed me to catch the 3:45 PM shuttle and the 4:05 PM train. That got me home just before five o’clock, which ended in a 75 minute commute. This is a bit longer than it would typically take me to drive home, but I arrived in probably the best mood I ever have after a commute. I attribute much of my mood to the Stone Smoked Porter I drank on the train. That’s right, the consumption of alcohol is allowed on the train. Bonus!

So on Monday I’m going to drive down to the train station and purchase a 30 day pass for $154. Unfortunately, I’ve missed the monthly cutoff to order a pass through my company’s bulk purchase and subsidy program, so I’ll have to pay full price until I can do that. I haven’t worked out how much money this will save me, if any, but right now I don’t care. It’s worth it to preserve my sanity.

This new commute comes with another benefit. We had been considering selling our 1997 Ford Explorer in order to help fund the purchase of a new car. By trading cars with my wife (I drive a 1999 Toyota Avalon) and using the Explorer to make the relatively short drive to the train station, we can get more life out of it, saving us some money. So even if the commute itself is a short-term monetary wash, there is plenty of cost saving in the long run.

OSCON 2010: Tuesday

I returned from the O’Reilly Open Source Convention three weeks ago, and I’ve had drafts for my Tuesday through Friday travel posts sitting around since then. I’ve finally found a moment on a lazy Sunday afternoon to enjoy a pint of ale while writing. Although, it is a beautiful day, which I’d be spending outdoors if my family weren’t sick (and I’m not convinced I’m altogether healthy).

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.

OSCON 2010: License to Fail

Robert “r0ml” Lefkowitz

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.

OSCON 2010: Friday Morning Plenary Sessions

I’m tired this morning after a long week at OSCON, so my ability to understand and summarize the Friday plenary sessions is diminished. As such, what follows won’t be terribly useful to anyone.

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.

OSCON 2010: State of the Onion

The Thursday sessions are over, but before I head out to the parties, I’m attending the 14th State of the Onion address. This is the always well-attended update on the universe of Perl. I immediately noticed that Larry is surrounded by his wife and his son, the former dressed as an angel, the latter as a devil.

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?

OSCON 2010: Awesome Things You’ve Missed in Perl

Paul Fenwick (Perl Training Australia)

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.

OSCON 2010: 21st Century Systems Perl

Matt Trout (Shadowcat Systems Limited)

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.

OSCON 2010: Dist::Zilla

Ricardo Signes (Pobox.com)

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.