Recently in Perl Category

A few days with the JAPHs has reminded me of a few things:

1. I’m behind. I need to do a better job of keeping up with Perl things.
2. Perl has a unique culture and community that is both interesting and valuable to what it produces.
3. I’m so glad that the people I usually hang out with do not use a certain expletive as their favorite adjective.

Okay, so let’s review.

Sunday

I traveled to Columbus, Ohio on Sunday. My travel was mostly uneventful, other than an hour delay in Dallas to replace the brakes on the plane. Because of that, I didn’t get to have dinner with Terri’s cousins, just her uncle. However, I enjoyed a delicious meatloaf and lemonade with Keith at the Cap City Diner (warning the web site plays music). I arrived at The Blackwell that evening, which is apparently named after a professor at OSU who has been convicted of insider trading.

My first impression of Ohio State campus is that they must have had a beautiful football stadium at one time, but now appears to be just a modern monstrosity with a beautiful arch on the end facing The Blackwell. I suppose this stadium will soon be featuring regular visits from our northern neighbors in Nebraska… I’m not an OSU fan, but I hope OSU beats NU every time they play here.

While traveling and late into Sunday evening, I finished up my notes for my first talk.

Monday

I met my colleagues in the lobby and we walked together over to the Ohio Union, where the conference was being held. The Union is knew and was a very nice place to conference, particular one priced at the value that YAPC is—though, my conference registration was paid for by the low-low price of giving two talks, which is great since I was just talking about two subjects I like to talk to others about anyway.

The keynote on Monday was given by Jesse Vincent, who was the Perl5 v12 pumpking, which has been released and is well into it’s maintenance cycle now. For those that may not know, this marks the second major release of Perl in the last 3 years and is part of a new effort to consistently make a major release of the language every year. This is good news for at least a couple reasons.

1. Perl language developing will stay fresher with new features coming regularly.
2. It will help dispel the message of the naysayers and show that Perl is Alive.

After that, I went to a couple talks on Catalyst that I didn’t pay much attention to. This had far less to do with the quality of the talks and more to do with me thinking about my talk.

I gave my first talk at 10:00 am on Telecommuting. I will post the audio/video when Krishna gets it online. I may post the slides too, but there’s really not much to show in them. Most of it was me telling a few stories from note cards. I feel like I was a bit dull, but I got some good questions at the end, which is usually a good sign. As I said on Twitter, I hope it was useful.

After breathing a sigh of relief I spent most of the rest of the day in talks and working on a project for work. I attended Util’s talk on Amazon EC2. I learned that EC2 hasn’t changed significantly since I used it. It’s still the same, though there are more instance configuration options, Windows instances, and different storage engines. This is mostly just an extension of what was there when I was last using it a couple years ago.

We then grabbed some lunch from The Flying Pizza, which was cheap and greasy and pretty good.

After lunch, I ended up in Moose for Managers, which wasn’t a stand-out talk in my mind since I can’t remember anything about it. However, I was working on something related to work at the time, so that’s probably just me not paying close enough attention. I stayed in the Grant Street Room to listen to Paul Fenwick’s talk on Awesome things you’ve missed in Perl. Paul is a great speaker and showed a number of things I’ve put on my todo list to investigate.

I ended the regular talks for the day by attending Dave Rolsky’s talk on Fey and Fey::ORM, which I’m mildly curious about since I once tried to write an ORM and because Fey seems like something which could be useful for something at work. By the way, my attempt at an ORM was awful and Dave actually wrote a scathing review of it on CPAN Ratings, which is part of the reason it has been disappeared from CPAN…I think that may have been my first CPAN module. Oh well. No hard feelings.

Finally, there were the lightning talks. They were enjoyable, as usual, but I’m not sure there are any that stand out in my mind from Monday.

After that, my fellow Grant Streeters headed out to dinner. We went to a local, cheap Chinese place, which was pretty decent. I stayed up late working after that, though after all the talks and travel I was pretty spent, so I got done far less than I wanted.

Tuesday

I ended up sleeping in a bit and missed the first round of talks and caught only the last part of Michael Schwern’s talk on the coding cycle. I stayed in the Grant Street room to see Gabor Szabo’s talk on Padre, which I’ve long been interested in, but still haven’t looked at much. If you want to learn Perl, using this editor sounds like the best way to get started.

Then it was lunch again, at Chipotle this time. Mmmm… Chipotle.

I attended scrottie’s talk on running Perl in a cheap distributed computing system (i.e., a pile of cheap computers working together to form a supercomputer of sorts). This was followed by Nick Perez giving a talk on how he’s building apps using POE and Plack.

I moved downstairs to another Schwern talk, this time on perl5i, which is a pretty interesting project. He’s basically taken to pulling in his favorite language extensions and piled them into a single module, perl5i. I’m still thinking about how it works and wondering if I like it or not. I certainly like most of the modules he’s brought in and how it works. I’m just not certain I like the mo and mc meta-accessors… still considering it.

After that talk, I stepped out for a while and worked a bit and chatted with some folks in the lobby of the Union. I met a lot of great folks while here, too many to mention all of them.

Then, I attended the keynote, which was given by Stevan Little. This talk explored the history of Perl and how we got to Modern Perl today. Using some concepts by Larry Wall, he wanted to show how Perl had filled a void that once existed in Unix. That is, it used to be if you wanted manipulexity (lots of deep functionality) you wrote something in C. If you needed something with whipuptitude (built quickly and easily) you used shell script. Perl was an attempt to fill in the difference so you could have both manipulexity and whipuptitude. Modern Perl is the outcome and successful implementation of this.

This is also a good opportunity to explain that while Perl has long had the slogan TMTOWTDI (There’s More Than One Way To Do It) from Larry Wall, Modern Perl makes it longer with TMTOWTDI BSCINABTE. This is pronounced Tim Toady Bicarbonate, which acronymizes, “There’s More Than One Way To Do It But Sometimes Consistency Is Not A Bad Thing Either.” This is an extension to Perl thinking that basically adds a little more consistency to programming (via Moose and related thinking) without actually losing any flexibility. (In fact, Modern Perl is really much more flexible in many ways, it just adds a common foundation that makes that flexibility a little more solid and less re-inventive.)

After this came the second round of lightning talks. There were again several good ones, but I think the talk that outshined them all was the one by Makoto Nozaki titled “How I mastered English with Perl.” It was great. I hope the video of it is posted so I can watch it again.

After this, we had the banquet, where I sat with one of my coworkers, Dieter, some of the folks from Best Practical (Shawn Moore, Kevin Falcone, and Jesse Vincent) and got to meet a couple others, Elliot and Ingy. I had a pretty decent time learning a bit about others, talking with Elliot and Jonathan Rockway in the food line, and made a smallish bid on some coasters during the auction. Pathetic, I know, but I did by a new Perl T-shirt since my Perl polo I bought at OSCON is starting to wear.

After that, I went with some folks and ended up talking about work with my coworkers at a local bar before heading back to my room where I stayed up late inventing a new talk to replace the one I wasn’t able to get together in time.

Wednesday

I started the morning by attending another Schwern talk on gitPAN, which is a really cool way of mining information about CPAN using github. This was followed by a talk by Tatsuhiko Miyagawa on cpanminus, which I had only heard rumors of up until this point. Now that I’ve tried it out, I’m not sure why I haven’t been using it for months now. It’s a very nice (simple!) CPAN client that handles most of what you need when you just want to install a module to try it out.

I then gave my second and final talk on Form::Factory, which showed a bit on how to extend Moose and how I like to build forms, but I don’t think it’s earth shattering. I would like it to be, but my time to hack is constrained by so many things.

I followed that with mst’s talk on The Troll, the God, and the Mountain, which was a very unusual introduction to DBIx::Data::Store. The punchline is that the Troll, Thog and his friend Al, are renamed and made great by the god v10 (“Voton,” i.e., Perl 8 v10) to become “Orthog-an-Al Persisten-T roles.” That’s about all I remember, to be honest. I’ve been hearing a few rumors about this project via Rob Kinyon (I think), though, so I’m keeping an eye open for when it hits CPAN.

I had one more lunch at YAPC, with a bunch of folks I didn’t know and Rob. I confess to have forgotten all names at this lunch, but they were good company for lunch.

Next, I attended Cool Perl 6 today by Patrick Michaud, who is the lead on Rakudo, which is the engine for Perl 6. I’m really thinking Perl 6 should be renamed to something else because it’s like Perl, but it’s not Perl. I like to watch these talks mostly for fun, though, things are getting to the point now that you can write Perl 6 applications, which is tempting to try.

I then attended a really excellent talk on autodie, titled “The Art of Klingon Programming” by Paul Fenwick. The talk featured Paul in a TNG uniform talking about his time as an exchange officer in the Klingon empire where he was testing the new universal translator. The joke is this. If you’ve programmed very much Perl, you know a common idiom is to write “open or die.” The reason is that if the file doesn’t open it returns a false value, so the short circuit “or” operator allows you to skip the die on success or run the die on failure. This is a good way to ask for blood wine in Klingon, since trying to ask nicely won’t get you any. The autodie module comes along to make this kind of talk automatic (making open die without the “or die” on the end).

Prior to the final keynote by mst, I attended two more Moose talks, one by doy and the other by perigrin. Both had way more information than I was really able to consume and the major thing that I took away was that I need to look into the new declarative syntax and immerse myself more deeply into the Moose type system, which I’ve really barely touched.

The final keynote was given by mst, which was another summary of the history of Perl as well as a general summary of some of the good things that have happened in the world of Perl in the past year.

After that, I went over to the Blue Nile Ethiopian Restaurant with the other speakers (and hangers on) and experienced my first taste of Ethiopian food and had one more social event. I got to speak a bit with chromatic, whom had edited the articles O’Reilly published to OnLamp. I got to chat with Ricardo Signes, Dave Rolsky, Rob’s wife, Randall Schwartz, and several others. It was a good time.

Finally, it was time to pack and head home.

In Summary

Perl has a really interesting culture. Between the libraries on CPAN, the dedication of many developers to the language and the community, and the way the leaders in the community interact with it, Perl has a lot going for it. It almost seems like there is a bit of religious fervor to it, though, that’s partially just the concentration of people getting together to talk about Perl. Most of these folks work in other languages too and have important concerns outside of Perl.

On my list of things I need to look into from the conference:

• Perlbrew: A nice way of installing Perl VMs for development and testing.
• local::lib: A nice way of locating and using CPAN modules installed to your home directory.
• cpanminus: A tool that simplifies installing modules from CPAN.
• Bread::Board: A framework for inversion of control, which is something I want to do better with in Form::Factory
• CPAN Explorer: A visualization of CPAN.
• Reflex: A new syntax for doing POE-like things with Moose.

There are others, but I don’t want the list to get too long.

Anyway, that’s my summary of everything I have to say about YAPC::NA 2010. Lord willing, I hope to attend again.

Cheers.

Help! Help! I need help!

I’m giving a talk at YAPC 2010 on telecommuting as a software developer. For the talk to be successful, I’m going to need more than just my own experience to pull from. If you are a telecommuter and have a moment, I would appreciate your help in filling out this survey.

The goal of the talk is two-fold:

1. I want to explain the benefits and risks of telecommuting as a Perl developer.
2. I want to provide some practical tips to help fellow telecommuters.

I want the format to be oriented towards telling a number of stories about telecommuters with practical advice interspersed.

Perl Telecommute Survey

Recently, I’ve started backing away from Jifty as my web framework of favor. There are a few reasons for this, but mostly it’s related to performance. Jifty is includes everything, Ajax, dispatch, ORM, Comet/PubSub, REST, forms, HTML, templating, and a pony (probably a kitchen sink too). Basically, with Jifty you don’t need to spend very much time working on building up your own utilities or framework upon framework to fit your style or needs. Jifty hands you a style as well, one that I mostly like.

However, the cost to performance on my Qublog project was too much. It was easier for me to port it to Catalyst sans-Ajax than it was to try and correct the performance issues. In addition, I no longer use Jifty for work, wanted to use features of DBIx::Class, Moose, etc. I’m not trying to bag on Jifty here, just explain why I’m moving away from it general. I very well may find a use for it for something in the future.

There is, however, a major feature of Jifty I miss after having moved to Catalyst. Jifty has a collection of classes for encapsulating form rendering and processing. At the center of this is the action class, which is really a glorified functor, but with all the accoutrement required to render an HTML form and to clean up, verify, and process submission. I like this. I like this a lot. I decided to use the flexibility afforded by Moose with an implementation of something like these action classes to create a new form handling system. Over my Thanksgiving vacation, I was able to build up what has become Form::Factory.

An Example

Okay, I thought about showing you the process I worked through to get here, but you probably want to see it in action first. I’ll work backwards from there.

In order to use Form::Factory, you must first define an action class. Here’s a simple login action you might use to present a login form to your users in a web application:

package MyApp::Action::Login;
use Form::Factory::Processor;

has_control login_name => (
    control => 'text',
    features => {
        required => 1,
        trim => 1,
        length => {
            minimum => 3,
            maximum => 20,
        },
        match_regex => {
            regex => qr{.@.}, # really naive check for email address-ish thing
            message => qw{your %s should be an email address},
        },
    },
);

has_control password => (
    control => 'password',
    features => {
        required => 1,
        trim => 1,
    },
);

has c => (
    is => 'ro',
    isa => 'MyApp',
    required => 1,
);

sub run {
    my $self = shift;

    if ($self->c->authenticate({ name => $self->login_name, password => $self->password })) {
        $self->result->success("welcome back,  @{[$self->login_name]}!");
    }
    else {
        $self->result->failure('the login name and password you entered is wrong');
    }
}

The has_control calls establish the inputs expected for our login action and tell the action what features those controls have. For example, the required features will result in a form that reports an error for that control when no value is given during a submission.

The run method here actually performs the action. (For this example, I’m using something Catalyst-ish, but this could just as easily be used with CGI, CGI::Application, Plack, Jifty, or whatever you prefer.)

To use the login action in our web application, we’ll now need to send the form to the user. Here’s a Template::Declare template that should work:

template 'user/login' => sub {
    my ($self, $c) = @_;

    page_wrapper {
        form { { action is 'user/check_login', method is 'POST' }
            my $interface = Form::Factory->new_interface(HTML => {
                renderer => sub { outs_raw(@_) },
            });
            my $action = $interface->new_action('MyApp::Action::Login', { c => $c });
            $action->unstash('login');
            $action->render;
            $action->clear_messages;
            $action->stash('login');
            $action->render_control(button => { name => 'login' });
        };
    };
};

That would render an HTML form that the user can then fill in and submit. The new_interface call creates an instance of an interface class. These are responsible for connecting an object to the user interface. In this case, it’s an HTML form.

The new_action call then creates an instance of the action class associated with our interface class. Note that we can pass a hashref of arguments that will be passed to the constructor.

The unstash and stash calls are handy for remembering certain things about the form. This includes any error or success messages associated with processing the form. For example, if the user entered their login name, but the incorrect password. The processing bit (which we’ll see in a moment) would stash the error from trying to authenticate and would also stash the login name itself (but not the password since passwords controls don’t ask to stash their value). Then, when the form draws again, teh error message will be shown and the login name box will come prefilled with the previous entry.

The clear_messages call clears the messages from the action so that we can stash a clean slate for the action (we don’t want to see a message we already displayed again).

The render method renders all the controls associated with the action. (By passing the controls option you can output only a subset if you wish.) The render_control is used to output a button that is not directly associated with the action (in this case we just use it to get the user to send the form back to us).

Once the user clicks on our “Login” button, we’ll then want to process the input. That looks something like this:

sub check_user_login :Path('user/check_login') :Args(0) {
    my ($self, $c) = @_;

    my $interface = Form::Factory->new_interface('HTML');
    my $action = $interface->new_action('MyApp::Action::Login', { c => $c });
    $action->unstash('login');

    $action->consume_and_clean_and_check_and_process(
        request => $c->request->params,
    );

    if ($action->is_valid and $action->is_success) {
        $c->response->redirect('/index');
    }
    else {
        $action->stash('login');
        $c->response->redirect('/user/login');
    }
}

We get the interface and action objects same as before. We unstash the saved information again. Then, we do that long method, which is a shortcut for saying:

$action->consume( request => $c->request->params );
$action->clean;
$action->check;
$action->process;

The consume method takes the input and applies that to each control object.

The clean method then cleans up the values given to each control. In this case, for example, the login_name will have whitespace trimmed from the beginning and end since it uses the trim feature.

The check method then validates the inputs to determine whether or not we can reasonably expect the user’s input to have a chance at working. Here’s where most of the features added above will do their work. If the user does not enter anything for the username, the required feature will cause the control to be set as invalid.

Then, the process method will cause the action to process. Actually, the process method itself first checks to see if the input is valid and does nothing if it is not. If it is valid, it will copy the values from the control objects into the action attributes and run the run method defined on the action.

Finally, we can check the success or failure of the action and react accordingly. That’s how Form::Factory works in a nutshell.

Goals

Now that you’ve seen an example, here’s what I want to achieve in a nutshell:

1. Actions should be well-structured, but very simple to build.
2. Actions are tied to the user interface by controls, which are easy to extend.
3. Common features of actions should be simple to define and associate with actions.
4. User interfaces should be easy to build for hosting actions.

Actions are Well-Structured, Simple

Actions are just functors, function objects. At the center of each is a run method responsible for taking some action. To get there, however, you need input and after you get there you need output. Form::Factory uses Moose attributes to specify what input the action takes. Each has_control builds an attribute onto the action, but also associates more information about how it interacts with the user.

The output is a little less formally specified at this point, but comes out through a result object. The result object is a list of messages associated with the action along with some status information. It can also return a hash of other information for more general output. However, I’m assuming that most of the output of the action is the side-effects the action performs.

When an action is run, it goes through four basic phases to process:

1. Consume. The user input is delivered to each control associated with each attribute on the action.
2. Clean. The input in each control is filtered and corrected, allowing whitespace to be removed, numbers to be reformatted, etc.
3. Check. The input of each control is validated and any errors discovered are reported. Processing stops here if there are errors.
4. Process. The input in each control is copied into the action attributes directly and the action is run.

In addition to the features attached to the controls, you can specify general subroutines which will run during these phases. For example, if you have a form for changing a password, you might want a check that looks like this:

has_checker check_that_passwords_match => sub {
    my $self = shift;
    my $new_password = $self->controls->{new_password}->current_value;
    my $confirm_password = $self->controls->{confirm_password}->current_value;

    if ($new_password ne $confirm_password) {
        $self->result->is_valid(0);
        $self->result->error('the New Password and Confirm Passwords do not match');
    }
};

This allows you action’s run method to focus on the task it performs and nicely segments off all the checks. You can also logically group your checks and filters so that they are separate from each other. This makes it easier to subclass your actions or compose them from roles.

Controls are the Bridge

An attribute added to your action with has_control has a control object associated with it. This control does most of the work until right before processing. The control receives the initial input, the cleaned input, and is where the value sits when checked. It is not until it is checked that the value enters the attribute instance slot.

Without the control in place, i.e., if we assigned to the attribute directly, Moose would object to the input before we have a chance to do anything. I want to avoid exceptions in this case as well because input validation failures are not exceptional, they’re expected. We need a way to easily send back notes the user about corrections needed and would like to avoid spewing call stacks unnecessarily.

Controls also suggest how the user interface object should present them to the user. An interface is not bound to use these suggestion in exactly the same way as its peers. For example, a text control in HTML might just be a text input box while in a CLI interface might be presented as a command-line option that takes an argument. A check box, on the other hand, will be a check box input in HTML, but would be an option that takes no arguments in a CLI (it’s presence suggesting “on” and it’s absence suggesting “off”).

Features Modify Actions

A common feature of form handling is filtering and input verification. In Jifty these were called canonicalization and validation. Horrible. I’ve called them cleaning and checking. In general, though, the cleaning and checking you want to do is extremely repetitive. On almost everything I want to trim the whitespace and verify that something that is required is present. I often want to check input length for something too long or too short. Sometimes I want to check that email addresses or phone numbers are sane, etc. In Form::Factory, all of these are called “features.”

A feature is a generic object that modifies an action. These can be anything from a feature that is just used to flag the role for some reason to features that actually modify the structure and processing of the form. Features can also be attached to particular controls to clean or check an individual control’s input.

Interfaces Talk to the User

And interfaces are probably what make Form::Factory most unique. An interface looks at the controls for an object and presents them somehow to the user. Currently, I’ve written an HTML interface and a CLI interface. The HTML interface presents them using the matching HTML form controls. The CLI interface presents them as a usage snippet describing the command-line options the action accepts. You can define a single action class and use that action to define a web form or a command-line interface.

I plan to add a REST interface as well, which will be a variation of the HTML interface. Other interfaces I’ve considered (but have no plans for at this time) could include things like a Wx GUI, a PDF interface that builds a PDF with form fields and then consumes FDF documents created from that, an XForms interface, a XUL interface, or a curses interface.

Okay, so that’s my current contribution to the forms parsing arena. I’m still working the kinks out, so be careful if you give Form::Factory a try. Things will change. Otherwise, I’d love some feedback and help ironing out some of the wrinkles.

Cheers.