Osgood is a passive, persistent, stateless event repository. The current docs say queue rather than repository but we’ve decided it’s a bit of a misnomer. A primer on the aforementioned explanation:

• Passive: Osgood doesn’t seek out your events, it only waits for notification and query
• Stateless: Querying an event does not change it
• Repository: Once you’ve inserted an event it stays there forever

So what’s that mean? Osgood (::Server) is a system wherein you record the fact that something happened. A client library is provided that allows you to do just that (::Client). You can also query the server to ask it what has happened and it will inform you. I believe an example is in order.

Magazines.com’s backend is basically a big order pipeline after the order is taken. We are phasing out an AS/400 which is currently handling fulfillment of orders. If a customer calls us and wants to cancel a magazine, our our order entry system cancels the order and then needs to notify the AS/400. We have an audit table for order line items, so we would query that table for fresh cancels and send them to the 400 to finish the process.

All was well! Then our Marketing team approached us with a good idea: Send customers who’ve canceled an email enticing them back! It was a great idea until we released that we basically had one shot in our aforementioned setup to send a cancel, and we were using it. There was no way to keep up with the status. Had we sent it to the 400? What about to our email service provider? Were there other things we might do in the future? Osgood was born.

Osgood is based around Events. You use ::Client to send an event to the Osgood server, like so:

my $event = new Osgood::Event(
	object => 'Moose',
	action => 'farted',
	date_occurred => DateTime->now(),
	params => {
		name => 'Hector'
	}
);

Events are composed of an object, an action and a time. These fields are all stored as VARCHAR(64)s, so you can put anything you like up to that size.

The optional params accepts a hashref of name value pairs. This allows storage of information that doesn’t fit Osgood’s Object/Event setup, but that you might need when using the event. A good example would be the primary key of the specific Moose that farted. Note that you can also use get_param and set_param on an Event object.

my $list = new Osgood::EventList(events => [ $event ])
my $client = new Osgood::Client(
	url => 'http://localhost',
	list => $list
);
my $retval = $client->send();
if($list->size() == $retval) {
	print "Success :)\n";
} else {
	print "Failure :(\n";
}

You can put as many events into an EventList as you like. Then you create a Client and send it! Above we check that send returned a number that matches the events we sent.

That’s all well and good, but how do you use what you’ve stored? The client also works the other way around:

my $retval = $client->query({
     object => 'Moose',
     action => 'farted',
});
 
if($retval) {
	# Gets an EventList
	my $list = $client->list();
	my $iterator = $list->iterator();
	while($iterator->has_next()) {
		my $event = $iterator->next();
		print $event->get_param('name')." farted at ".$event->date_occurred()."\n";
	}
} else {
	print "Oh noes!\n";
}

We asked Osgood for all the Moose/farted events and we got them back. One note of interest is that Events are assigned an ID when they are stored, and that ID is present when you get them in a query. This will come in useful later.

The query method supports many other options as of this writing:

• date_after: date after the specified one
• date_before: date before the specified one
• id: all events with an id greater than the one specified
• limit: only return the specified number of events

So back to our original problem. Rather than make our internal cancel process complex, we simply create a row in a queue table which is emptied frequently and sent to Osgood. Our backend processing jobs then query Osgood using the id parameter to query to find every event that was created since the last one it processed. Now we can create an unlimited number of backend jobs that work from the same event. Our email sending and publisher notification of cancels happen independently.

This work was inspired by past work with Publisher/Subscriber systems and message queues like the venerable JMS. It bears very little resemblance to those ideas, but one might be able to squint a bit and see the similarity.

Osgood::Server is a Catalyst application using the XML::REST plugin and ::Client is Moose based with some help from MooseX::Iterator and some XML::XPath and XML::DOM magic for serializing and deserializing the eventlist.

If you have any questions, feel free to drop me an email or hit me up on irc.perl.org as gphat.

A Query Builder.

I can hear your eyes rolling already. We’ve all written them. But I’m going to share an extra-cool method for doing so.

Here’s the list of ingredients you’ll need.

• Your existing DBIC application.
• Experience with custom resultsets.
• An understanding of chained resultset usage.
• Moose
• MooseX::Method

Now that you’ve collected your ingredients, let’s prepare them.

First, note that we aren’t allowing our end users to build literal queries in this recipe. We are going to allow them to chain calls to our resultset. This is a much better option, in my opinion. A lot of the complexity can be removed by simplifying some heinous or dangerous SQL into a simple resultset method. With the help of Moose we will create a custom resultset that allows us to introspect the methods available for building and show them to the user automatically.

Now, we’ll be working on a Product example. Our end user needs to build a query that finds all the products in a price range, of a certain type and in a certain category.

Since you’re already versed in custom resultsets I’ll just show you the finished product:

package Our::ResultSet;
use Moose;
use MooseX::Method;
use MooseX::Util::TypeConstraints;
 
extends 'DBIx::Class::ResultSet';
 
subtype 'Currency'
	=> as 'Object'
	=> where { $_->isa('Math::Currency') };
 
coerce 'Currency'
	=> from 'Num'
		=> via { Math::Currency->new($_) };
 
method price => named (
	operator => { isa => 'Comparator', required => 1 },
	amount	=> { isa => 'Currency', required => 1, coerce => 1 }
) => sub {
	my ($self, $args) = @_;
 
	if($args->{'operator'} eq '=') {
		return $self->search({ price => $args->{'amount'}->as_float() });
	}
 
	return $self->search({
		price => {
			$args->{'operator'} => $args->{'amount'}->as_float()
		}
	});
};

That’s a lot of code, but the concept is very simple: Create your resultset’s methods with MooseX::Method and then you can do the following magic:

my $rs = $schema->resultset('Product');
my $map = $rs->meta->get_method_map();
foreach my $method (keys(%{ $map })) {
	# See MooseX::Method docs for what to do with this.
	my $signature = $method->signature();
	# Profit!
}

Having the method’s ’signature’ allows you to get a list of the parameters that the method expects, as well as the types and ‘required’ status. That sounds like the recipe for some go-getting developer to construct a query building tool!

One warning. MooseX::Method currently lacks a permanent API for acquiring this information. The current API is to call export on the signature. You can Dumper the resulting hashref and see pretty easily how to get what you need. Keep an eye on The CPAN or in irc.perl.org’s #moose for updates.

So to use this recipe, you’ll have to construct your own mechanism for taking the above information and generating a UI for your application. I got my Catalyst based query-builder working this afternoon.

If you have any questions feel free to drop into irc.perl.org and shoot a message to gphat. You can find me in #moose.

Here’s a listing of the projects names used on our ‘current’ projects:

• Greenspan (parent project of the others)
• Lockhart
• Kayhill
• Hopkins
• Osgood
• Downham
• Holbrooke

Greenspan was the ‘first’ in the new generation of projects we’ve done at $work. It established the system used to name others. I regret choosing a name that is so obvious to anyone who knows what the Federal Reserve Board, but it established the general rules we use:

• Words that break down into two words well (Os-Good, Down-Uhm, etc)
• Words that would seem at home when naming English cities
• Words that aren’t in people’s general lexicon

Since I also wear the hat of System Administrator, I get to pick names for the servers we run. The current naming scheme is based on the Greenspan project. We use the names of currencies for our servers: peseta, drachma, lira, pound, euro. We made a list of names on our wiki of prospective names so that when a new box arrives, we have a queue of names we can choose from. We usually vote unless the box is going to primarily serve a single person’s interest. In that case, they name it on their own.

It is said that to name a thing is the power to control it. I’m not sure if that is the underlying principal, but I can say that project naming and releasing procedures have always been extremely interesting to me. I love reading ChangeLogs and reading about the process that companies use to push out shiny new toys.

I think that codenames say something about the ideology of group that uses them. I’ve always been impressed by the huge list of codenames used by Intel for their products. We could use a scheme that generates informational names like fra0132 for “Franklin location, Rack 01, Position 32″. If we had a hundred boxes I’d consider it. But in a smaller installation all of these machines have a personality and to treat them like anonymous slaves would be a disservice.

These names are often difficult to get consensus on. I might love a name only to have another developer loathe it. It takes a lot of effort to cook them up. But it’s all worth it in the end.

A conversation with Jaxn tonight got me thinking: How ‘fast’ are the sites of the top 10 ’shopping’ sites (per Alexa)?

So I measured them. At first, it was a simple matter of emptying my cache and loading each site. But many sites, understanding how important it is to get things moving quickly, used some sort of onLoad function to do some more loading without screwing up the user’s experience. To facilitate those, and not penalize them, I took a screenshot of the measurements as soon as the progress bar filled and the site was useable.

I’ve been hacking away for the last week or so on a content management system (henceforth CMS). We are going to need a CMS for some future $work projects and I’m generally unhappy with all that I’ve reviewed. So many of the existing ’solutions’ seem to be more in the business of providing you with a ‘platform’. Most of the folks I know build platforms for a living, we need only find a way to manage the content.

So with that in mind, Ayalike (pronounced like ‘a uh like’) aims to provide the following features:

• Multisite, multiuser, multirole
• Output agnostic
• Versioning
• Pluggable publishing
• Output processing

Three of those features are complete. Publishing works, but is currently not pluggable. Output processing is there as well, but I’ve yet to hook it into anything but unit tests.

That’s all kind of abstract, here’s what I’ve done in a more concrete form: This week I modified one of our internal applications to use a custom Template Toolkit provider that communicated with Ayalike and provided ‘preview’ functionality on the live site without changes to the application itself. The application functioned normally, rendering compiled templates from the filesystem, unless given a special parameter. In that case it requested the entry from Ayalike over HTTP using it’s wiki-esque page viewing feature. Obviously real apps would protect this feature with logins.

I’m not quite ready to tout it on the mailing lists or in IRC yet, but I’m very excited about the project and I hope that it might become the solution for my future work projects. Regardless, Catalyst needs a CMS.

Are you interested? Visit the Trac site. There’s even a working demo, cleared every half hour.

• BPM 37093 is a white dwarf that, as it has cooled, has turned into a diamond. Our sun will do the same in about 5 billion years, as a hard crystalline core forms in it’s center.
• Planting 300,000 new trees and allowing them a full life would offset the carbon dioxide emissions of one 500-megawatt coal-fired power plant operating for a little more than a week.
• The brass ring on the end of a pencil that holds the eraser is called a ferrule.

• Baby blue whales can gain up to up to 200lbs a day by drinking about 100 gallons of milk. Whale milk is 40-50% fat whereas cow’s milk is appromixately 4% fat.
• India is the world’s largest butter consumer. It’s people eat roughly 46% of the annual global supply — that’s over seven billion pounds.
• The darkest substance ever known was made this week.

On second thought, it’s not so different. The challenges of the projects are the same. The wrinkle is the addition of more entities into the equation.

I do so much in a day that it takes me hours to decompress. I often cook up posts on my trip home only to succumb to the soothing caress of a game, T.V. show or conversation with the girlfriend. Today I:

• Spent time discussing project and development workflow.
• Finished setting up Nagios to monitor a bunch of machines.
• Added a requested feature to our order entry / customer service app.
• Tidied up some failing tests.
• Tested tomorrow’s shipping software.
• Played Weewar.

Tomorrow I intend to continue the process discussion. Having had some time to digest the information proposed I’ve got some ideas. With my current monitoring project wrapping up a few weeks early I can set my sights on the next one: automated testing of our codebase. I’m excited to spend some time with Verby made by my friend Yuval. It’s eerily similar to some code I had begun working on when I started thinking through this project. More on that in the future I hope.

I’m going to breath some life into my old What I Learned This Week posts, but marry them to my daily adventures in the development management world. I’m hoping that some upcoming projects will yield some post-worthy nuggets. If I’m lucky maybe I can come up with a talk to give at YAPC::NA 2008 in the next few months.

As a closing I’d like to thank Jon for suggesting Sierra Nevada Porter and my beautiful girlfriend for bringing pint glasses when she moved in.

Imagine that I’m summarizing fanciful adventures and bracing, hard-fought lessons in this post. Go ahead, I’ll wait.

With that out of the way, we can quickly douse the fires of interest by describing the months of software development that culminated the creating of an order entry system for $work. That aspect of my life is harrowing and exciting. It’s a work in progress. More on that some other time, perhaps?

I’ve been… disconnected for a month or two. I rarely open NetNewsWire and I keep Twitterific closed. I’m not really sure why I’ve shunned the torrent of information I normally subject myself to. There was a spell of time — from September to mid November — where i struggled to produce a modicum of giveashit. This time was terribly busy and shutting down the founts of information was a requirement to maintain my sanity. My enthusiasm to reenter the ‘normal’ information overload has been tepid at best. I just trimmed 25 blogs out of my feed list and it still feels too big. Ok, another 20 more. Down to 80. That feels better.

I’d try and summarize the year, but I have some type of malady that muddies my memory past about 30 days. My girlfriend moved in, I shipped a big software project, nearly went insane and attended a Perl conference. All that’s happened in the last few months so it’s a poor summary.

So fuck that noise. Lets talk about what is going to happen in aught-eight:

• Be a good daddy
• Be a good boyfriend
• Enjoy my job more (working on managing up, delegating, componentizing and more)
• Go on vacation (Disney World for my brother’s wedding, March 30 - April 5)
• More

I’ve tried to write this post mutiple times. I finally succeeded. I’m not sure why my desire to talk to the world in this way has dried up. Surely I have things to say…

There are always things I want to do in my spare time, but there are a few that have been staring longingly at me from outside my cage lately. Being fettered to my desk working out the various problems that have arisen has made me long for these outside projects…

• A WeeWar clone that is more strategy and less Heavy Arty / Heavy Tank zerging
• Update my blog entries about DBIx::Class::QueryLog
• My Cat/DBIC based charting app
• Chart::Clicker
• Site Redesign

I’m attending the Pittsburgh Perl Workshop next week. My time there may give me some time to hack on these projects in my fave language. I also might take some time off to hack on them. I’ve earned it.