Enough backstory. I had some hassle getting Catalyst::Authentication::Store::LDAP working with Active Directory. I wanted both authentication and roles, so here’s what I ended up with:

Plugin::Authentication:
    default_realm: members
    realms:
        members:
            credential:
                class: Password
                password_field: password
                password_type: self_check
            store:
                class: LDAP
                ldap_server: dc1:389
                ldap_server_options:
                    timeout: 30
                binddn: cn=SomeAccountYouSetup,ou=Accounts,dc=domain,dc=com
                bindpw: password
                user_basedn: ou=Accounts,dc=domain,dc=com
                user_filter: (userPrincipalName=%s)
                user_field: mail
                use_roles: 1
                role_basedn: ou=Groups,dc=domain,dc=com
                role_filter: (member=%s)
                role_scope: sub
                role_field: name
                role_value: dn
                role_search_as_user: 0
                role_search_options:
                    deref: always

I’m not really participating in Matt’s Iron Man but the flurry of Perl posting does leave me feeling a bit guilty for not saying a bit more about my language of choice.

UPDATE: I’ve changed the configuration a bit to show what you need to change.

We’re a Perl shop, located in Franklin, Tennessee. We sell magazine subscriptions online. This year we’ve got a lot to do and I’m looking to add some developers to our ranks. I’m not sure how many yet, but I can give the following details:

• Telecommuters are welcome.
• “New” code: Catalyst, DBIx::Class, Moose and all those things.
• 2009 Projects include two major “new” projects plus maintenance and refactoring in older applications. Lots of niches to fill. We’ll find the right one for you.
• Apache, MySQL and Linux.
• Conferences! Number depends on schedule and work to be done.

We aren’t looking for a particular job level. I’m interested in juniors to seniors. The candidates we choose will depend on the choices we have. If you are interested then drop an email to me via cwatson at magazines dot com.

I’m really excited about our work in 2009. I’m opening the year with two talks at the Orlando Perl Workshop and a commitment to work with the Enlightened Perl Organisation. I’ll eventually post this opportunity on jobs.perl.org but wanted to start here. Give me a shout!

While I’m at it, if you are a LAMP System Administrator in Nashville (or nearby) and are looking for a great opportunity, drop an email to cwatson at magazines dot com!

On a side note, my first entry of the 2008 Catalyst Advent Calendar went up today. Enjoy!

Backstory

I started working on Chart::Clicker quite a while back. I’d just come from a job as a senior Java developer and still had AWT and Swing on the brain. I’d developed a custom charting package in perl a few months before but wasn’t happy with the results. I sought out a solid charting package to emulate and was heavily inspired by JFreeChart. One of the side effects of this was my disappointment with the availability of general graphics packages on the CPAN. I was jealous of the simple classes in Java that reduced a lot of the work in making graphics: Point, Rectangle, Color and more.

I released Chart::Clicker and was happy. I had emulated a lot of the ideas inside Clicker, writing general Component, Font, Color and Border classes, to name a few. As time went by and people began using Clicker it because clear to me that these concepts could be generalized and turned into a general framework for creating graphics. Thus became Graphics::Primitive.

Enter Graphics::Primitive

Graphics::Primitive is a collection of objects that allow you build a 2d “scene”. The building block of these scenes is a Component. It has a width and height, colors (fore and back), borders, insets and padding. A Container builds on Component and yields a component that can contain other components. To allow for more than plain ol’ boxes Graphics::Primitive provides TextBox, Canvas and Image. While these entities are all pretty simple, but you can create complex results by nesting them.

Creating Output

Graphics::Primitive is really just a data structure. It doesn’t actually do any drawing. Drawing is done by Drivers. The only driver at present is Cairo. It makes a great first driver, however, as it provides PDF, PostScript, PNG and SVG output.

Layout

Graphics::Primitive also doesn’t concern itself with laying out your components. Graphics::Primitive will leave components wherever you put them if left to its own devices. To handle automatic layout management I created Layout::Manager. As you add components to a container you can provide constraints for them. Then you can ask an instance of Layout::Manager to “layout” your container (and any containers contained in it). This concept is borrowed from Java’s layout managers. It is worth noting that each container has it’s own Layout::Manager so you can choose the one that is most fitting for the look you desire.

Benefits

Graphics::Primitive allows you to separate your data from your presentation. Creating an artifact in Graphics::Primitive allows you to change the output format. Need a PDF and a PNG? There’s no reason to rely on a conversion tool or a separate rendering path. Simply clone the component to pass it to each driver.

What Can You Do With it?

The aforementioned Chart::Clicker is made using Graphics::Primitive. You can look over examples of its output. The examples are all pngs but any of those can be converted to any of the formats supported by the Cairo driver by changing a single parameter.

There is a Catalyst view, which I released onto CPAN today. This allows you to serve your components via HTTP.

Document::Writer aims to abstract the underlying Graphics::Primitive components into an API friendly to creating documents. It will likely change quite a bit as I refine the ideas and increase underlying features.

Supporting Cast

I created a handful of other modules in an effort to reduce the work others might do when building similar code.

Graphics::Color provides simple objects for various color spaces. I’ve got a list of color spaces to add, as well as conversion routines.

Geometry::Primitive provides simple geometry entities such as Point, Circle and Rectangle. These objects serve as the base for Graphics::Primitive.

Future Plans

I’m currently sitting on code that allows serialization of a Graphic::Primitive scene using MooseX::Storage, but some API conflicts are stopping me from releasing until I work them out.

Document::Writer will be getting lots of new features as I back out a lot of my crappy text code for a more robust text-layout engine based on Pango. There are supposedly bindings coming for perl that are not tied to GTK+.

Conclusion

Graphics::Primitive has been a lot of fun. If I’d known what I was getting into I probably would’ve run away screaming. There have been many nights that I couldn’t sleep because a problem was rolling around my brain and I had to get up and hack on it for a few hours.

Please check it out and feel free to hit me up with ideas and suggestions. I’ll be giving a talk, hopefully, at PPW 2008. The presentation itself is made in Graphics::Primitive, just for extra oomph.

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;

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.

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.

The 1.0.0 label is mostly just a not to it’s maturity. I’ve been using QueryLog extensively at $job — most recently to tune a multi-million order conversion script — and a 1.0 is in order.

The only new feature is a refactoring of the ‘analysis’ code into a seperate object, as well as a new mode that totals up queries, combinining same queries and keeping a count and total time for all executions.

Have fun!

When handing a request Catalyst politely outputs each action executed (in order) along with it’s timings, like so:

2007/05/17 13:52:18 INFO [Catalyst : 1506] Request took 0.429198s (2.330/s)
.----------------------------------------------------------------+-----------.
| Action                                                         | Time      |
+----------------------------------------------------------------+-----------+
| /auto                                                          | 0.102865s |
| /default                                                       | 0.040768s |
|  -> /search/default                                            | 0.028275s |
| /end                                                           | 0.171297s |
|  -> Greenspan::Lockhart::View::TT->process                     | 0.165873s |
'----------------------------------------------------------------+-----------'

This information is helpful when trying to trace the flow of execution, find an error or when trying to isolate which action is hindering speedy throughput. But what does one do when multiple people are using a load-balanced app simulataneously? Tailing error_log on 3 webservers isn’t as much fun as the kids make it out to be! My work on DBIx::Class::QueryLog has me in the mode of providing performance information in the footer of the page. So I set out to do the same for Catalyst actions.

Turns out this is easier than it sounds. Catalyst keeps a Tree::Simple object in $c->stats() that details execution. Each node is a hashref containing (at minimum) ‘action’ and ‘elapsed’ keys. The former being the name of the action and the latter being how long it took to execute. Oddly, that latter value is not a plain number, but a float followed by an ’s’ to denote it is in seconds.

A quick snippet of code placed into the ‘end’ of my root controller can digest this tree and produce something useful for my templates:


my $tree = $c->stats();

my $dvisit = new Tree::Simple::Visitor();
$tree->accept($dvisit);
$c->stash->{'action_stats'} = $dvisit->getResults();


The value of the ‘action_stats’ key is now an array of hashrefs representing each action in the chain in execution order. A simple FOREACH and we’ve got ourselves a list of actions with their timings.

The actions could be arranged in order of time elapsed using Tree::Simple::Vistitor::Sort, but I personally prefer execution order. YMMV.

At $work we are replacing a legacy system with one based on Catalyst. One of the deliverables for this year is a new order entry application. Since our customer service folks are used to working in a terminal based system speed is of great concern to us.

So I installed DBIx::Class::QueryLog as the debugobj as described in it’s documentation, dropped it in the stash and added some code to our wrapper.tmpl:


[% IF querylog %]

[% END %]


The first run yielded this:

Well. That select from users could use an index on username, eh?

Weee! That one disappeared. What are all these role selections? We use Catalyst::Plugin::Authorization::Roles but this looks fishy. We might could use an index on the role name but there are only 6 rows in that table. A bit more investigation finds a loop in our Root controller that iterates over a set of roles calling check_user_roles() to try and find out where we should redirect the user. So lets swap that out for creating an array of roles and using grep…

Kick ass! We are down to two measly queries. We reduced the number of queries by about 75% and decreased the time spent executing SQL by about 75% as well. These queries were being executed on every page load.

UPDATE:Yeah, the average statement time was broken during that. Oops.