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:
with 'Catalyst::Controller::Role::REST'instead. (See also Catalyst::Controller::ActionRole, thanks to Florian Ragwitz.)
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.
$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.
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.