OpenSourcery

A few weeks ago I gave my talk to the Portland Perl Mongers on Moose. Slides are up, if anyone who couldn't make it wants to read them.

The talk went fairly well, especially considering that I haven't presented anything since I talked about POE for the Philadelphia Perl Mongers; there were some projector issues, which were completely my fault for assuming that the projector would be the same resolution as my laptop screen, but I managed to keep some decent momentum going anyway.

The audience mostly seemed to understand the subject matter, which surprised me a little. I expected more questions than I got, so either I was very clear or people were so baffled that they couldn't even formulate coherent queries. (Or everyone was really eager to get to the Lucky Lab for beer.)

Next I'll rip these slides apart and submit one or two talks for YAPC (submission deadline this Friday!); I know someone else is planning to talk about the MOP, so I'll do a more in-depth talk about type constraints or roles, either of which should provide me with plenty of material.

Part of my job involves development on elementalClinic (emC). emC is a few years old, and has undergone a lot of architectural change; it started as a collection of CGI scripts, grew into a collection of scripts, templates, and modules, and made the transition to a mod_perl application in late 2006.

Now, mod_perl is fine for writing Apache modules; but I have a web application, and I don't need most of the power that mod_perl exposes. Being tied so tightly to Apache has caused some problems and inconveniences along the way. For example, any tool to deal with Perl module dependencies becomes much more complicated when one of them is mod_perl, and running tests through Apache has made certain kinds of test failures much more difficult to debug.

We'd talked internally about moving emC to Catalyst at some unspecified point in the future. Catalyst is mature, well-tested, and very powerful, and while I don't love everything about it, there are a lot of people working on it (besides, I have a commit bit, so if I don't like how things work it's partly my own fault anyway). I've been using Catalyst for another project recently after being away from it for a while, and decided that maybe it wouldn't take as much effort to start moving emC over as I thought.

So, on Thursday, I told Randall that I was going to take a few hours from the next couple of weeks, and see how far I got in just replacing the dispatch mechanism from emC -- converting the controllers and the session and so on is something we can do incrementally, but getting Catalyst in "underneath" everything is a big first step.

It turns out that the answer to "how far can I get" is "all tests passing"; with just over 5 hours' work, Catalyst is now sitting between the outside world and emC's controllers. The immediate benefit is that emC can run on any of Catalyst's engines: mod_perl, standalone, prefork, FastCGI, etc. The long-term benefits are no more maintenance of hand-rolled dispatching code and the ability to incrementally replace even more hand-rolled code with modules from CPAN.

A huge factor in this is that Matt Trout had already written Catalyst::Controller::WrapCGI, a controller for running existing CGI scripts seamlessly inside a Catalyst application. A shout out to Rafael Kitover, too, for helping me find and fix a problem with it under mod_perl, and then releasing a new version with my patch included.

My first target for Catalyzing emC's code is probably going to be the functional tests, which use WWW::Mechanize and currently each have to spin up their own Apache process -- Catalyst's test module can fake up HTTP requests in-process, which is really nice for speed during the test-edit-test cycle, and it already has a WWW::Mechanize-based wrapper, so I shouldn't need to change too much code to make use of it.

This morning I merged the Catalyst branch into emC trunk. I'm excited about how easy it was to slip Catalyst in underneath the existing emC code, and I'm looking forward to the changes it'll make possible in the future.

A while ago, I told Jay Shirley (in a moment of weakness) that I'd co-maintain the Catalyst-Action-REST distribution. Over the past week, I've closed several bugs, and I feel comfortable enough with the codebase to start making more sweeping changes.

C-A-REST is certainly useful in its current state, but it has its warts. At the same time, I've been thinking about the fact that Catalyst 5.80 (svn) is built on Moose, and about how Moose could possibly help with some of C-A-REST's rough spots.

Here's a list of things I'd like to improve in the near future, in rough order of how much I've thought them through:

• Using roles instead of classes for every type of object (Action, Request, and Controller) will make it much easier for C-A-REST's modules to play nicely with other Catalyst extensions. The old classes will stay around for backcompat, but new code will be able to use with 'Catalyst::Controller::Role::REST' instead. (See also Catalyst::Controller::ActionRole, thanks to Florian Ragwitz.)
• Serialize/Deserialize plugins are currently only loaded from under Catalyst::Action:: -- there's no way to look under MyApp::Action:: or any other namespace. There's also no good way to pass configuration to plugins (a common request). Finally, they all share a lot of code, like looking up data in the stash or reading the body, that needs to be refactored.
• Serialize/Deserialize are symmetrical -- that is, they're forced to use the same Content-Type. This is OK for basic use, but it puts a pretty hard barrier on extending the basic de/serialization mechanism for application-specific content types, and I'd like to make it easier to specify that certain content types are only used in one direction or another.
• REST status helpers have clunky syntax and don't cover enough HTTP status codes. Calling $self->method($c, ...) makes me sad; we've talked about using a REST view and/or a REST response role instead. Whatever the solution, the REST component of Catalyst::Controller::REST needs to feel less bolted-on than it currently does.
• REST and Serialize/Deserialize are unnecessarily conflated. I'm not entirely sure they should even be in the same distribution, but they definitely need to be easier to use separately. Switching to roles may be enough to make me happy, here.

Check out Catalyst-Action-REST on github, and let me know what you think.

I'll be speaking about Moose at the next Portland Perl Mongers meeting (April 8, 6:53pm, at Free Geek).

Moose is a postmodern object system for Perl 5.

Moose's recent rise in popularity has led to a surge of declarative class-building and accessor-generating modules, but the real power of Moose comes from its metaclass fundamentals, not from the syntactic sugar of has(). Using Moose as a foundation makes it easier for your code to grow and scale.

I'll cover some of the concepts in Moose that the MOP (Meta-Object Protocol) makes possible, especially roles and type constraints. If we have time, I'll go through a simple Moose extension, focusing on the mechanisms Moose provides to help your code play nicely with others'.

If the first sentence of this description was news to you, you should at least read the SYNOPSIS of Moose, and if you can get through Moose::Manual and Moose::Manual::Concepts, so much the better. I'll expect a lot of questions, but I hope to move past "what is an object" pretty quickly.

By the end of the night I hope you'll have a better understanding of the depth of what Moose provides, and why has() is only the tip of the iceberg. I don't expect that everyone will immediately understand every concept provided – my goal is to impress you so much with Moose's awesomeness that you're willing to follow up later on the documentation pointers that I throw out.

3:o Moose!