OSCON 2010: Smalltalk-style Traits

Curtis “Ovid” Poe (BBC)

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.

OSCON 2010: Building Applications with the Simple Cloud API

Doug Tidwell (IBM)

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.

OSCON 2010: PostgreSQL Reloaded

The full title of this session is PostgreSQL Reloaded – Hot Standby, Streaming Replication & More! It was presented by Chander Ganesan, who, even before the tutorial started, demonstrated his skill as a presenter. Reading his biography, I noted that he appears to be a professional trainer, which is a nice sign. He started out by waiting for a whiteboard to be delivered. Good! That means pictures will be drawn and audience interaction may take place. I really appreciate his dynamic personality and presenting style. Having gotten little sleep the night before, he was able to keep me awake and focused.

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.

OSCON 2010: Cool Perl 6 Today

Patrick Michaud (pmichaud.com)

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.

OSCON 2010: Perl 5.12

Jesse Vincent (Best Practical)

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:

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.

OSCON 2010: New Beginnings in Perl 5

Piers Cawley (BBC)

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:

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.

OSCON 2010: Wednesday Morning Keynotes

I haven’t had a chance to compose my Tuesday blog posts.  Hopefully, I’ll find time throughout the day to work on them.  All that really means is that my posts will be chronologically out of order.

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.

OSCON 2010: Monday

Beer Samples at Rogue I awoke early on this first day of theO’Reilly Open Source Convention so I could have breakfast with Juan at his hotel. At first I thought fresh-made omelettes, bacon, and sausage were simply a better choice than the fruit and pastries offered at the Oregon Convention Center. As it turns out, no breakfast was offered at all. After breakfast, a short ride on the MAX delivered us to OSCON. I’ve already written about the tutorials, so I won’t mention them here.

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.

OSCON 2010: Get Started with the Arduino

Arduino and BreadboardThe second tutorial I attended at OSCON on Monday was one I had regrettably skipped when I was last here in 2008: Get Started with the Arduino.  After purchasing my Getting Started with Arduino Kit for $69.95, I tore it open like a kid in a toy store.  Inside the kit were the Arduino board itself, some jumper wires, a handful of components, including LED bulbs and resistors, and a USB cable to allow for programming the notebook computers everyone in attendance brought with them.

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.

OSCON 2010: Introduction to 3D Animation with Blender

The first tutorial I chose to attend this year at OSCON was Introduction to 3D Animation with Blender.  It was something I wanted to attend for fun instead of for work.  The instructor was Matthew Momjian, a 17 year old high school student who has been using Blender for four years.  His experience with the software showed, too.

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.