$mjgardner->()

MooseX::App::Cmd

2012-03-19T17:49:18Z

I'm finally taking advantage of the co-maintainer bit that Yuval Kogman gave me last year and putting out new releases of MooseX::App::Cmd.

]]> The latest release fixes a number of long-standing bugs as well as a more recent test bug that cropped up as a result of recent changes in its dependencies. I also bit the bullet and converted to Dist::Zilla; hopefully that won't piss off any of the other maintainers.

Eventually I'd like to merge MooseX::App::Cmd with its Mouse counterpart, but that will require a bit more thought and planning.

Mentor as anything

2011-11-21T13:27:24Z

The Google Code-in 2011 is open and I'm one of the mentors for The Perl Foundation's projects. If you are or know a 13- to 17-year-old budding open source developer, check out the site and start knocking down tasks!

I XML::Rabbit

2011-09-20T18:49:35Z

Just a quick note about how much I appreciate the work Robin Smidsrød has done on XML::Rabbit. I'm now using it on a second project, and the ease in which I can quickly build a set of classes and attributes to process XML documents combined with the usual Moose-y goodness is truly wonderful.

The first project in which I used XML::Rabbit, XML::Ant::BuildFile, is still chugging away and working well.

I'm making a note here: HUGE SUCCESS

2011-09-13T14:39:49Z

Thanks to the Philadelphia Perl Mongers for hosting my DB Critic talk last night. I got over my public-speaking jitters and it went really well, with great questions and ideas from the whole group.

]]> Chris Nehren (apeiron) noted in a followup email that a new perlootut (Object-Oriented Programming in Perl Tutorial) document by Dave Rolsky is in bleadperl. It's worth reading if your eyes glaze over at OO concepts like classes, inheritance, attributes and roles; or OO systems like Moose or Mouse.

Presenting DB Critic at Philadelphia Perl Mongers tomorrow night

2011-09-12T01:10:24Z

Just a quick FYI that I'll be presenting DB Critic (née DBIx::Class::Schema::Critic) tomorrow night at the monthly Philadelphia Perl Mongers meeting. We're in Room 307 of Levine Hall on the University of Pennsylvania starting at 7:00 PM.

]]> I've posted the slides online for anyone who's interested. And yes, this was that thing I blogged about last month.

The life and death (well, deprecation) of a wrapper module

2011-08-24T02:21:52Z

Earlier this year I was frustrated with Salvador Fandiño García's otherwise excellent Net::SFTP::Foreign package. It was in almost all respects the best choice for my current project at work, but the then-current version required me to check the return values of method calls for success or failure, and then use an error method to get any reasons for failure that might be waiting. The rest of my code used exceptions courtesy of Try::Tiny, and having to write three lines of boilerplate code for every SFTP call was getting annoying.

Thus was born Net::SFTP::Foreign::Exceptional, a very thin wrapper around Net::SFTP::Foreign that proxied all public method calls and then used a Moose after method modifier to throw an exception on any errors. (It originally used subclassing instead, but Salva set me straight on that and the less said about it the better.)

All was right with the world, or at least my project. I tweaked my wrapper a little bit, including switching to Any::Moose for situations in which Moose was just too heavy. In July, though, Salva released a new version of Net::SFTP::Foreign that threw exceptions on its own with the addition of a new autodie constructor parameter. Which is cool in that I can use one less level of abstraction in my code, but bad in that it would take a while to fix my projects to not use the ::Exceptional wrapper. And even though mine was just a pipsqueak of a module that hadn't been out for very long, it would be bad form to immediately delete it from CPAN.

Enter Dave Rolsky's Package::DeprecationManager, which provides a nice interface for marking certain method calls as "deprecated" by issuing a warning when they're called. In ::Exceptional's case, I wanted to change the code to use Net::SFTP::Foreign's new autodie parameter, but also warn that users should switch to doing that themselves instead of using ::Exceptional. So I marked new as deprecated, added the appropriate tests and docs, and released.

Total lifetime of Net::SFTP::Foreign::Exceptional: two months. But it got the job done, I learned how to (and how not to) write a wrapper module and how to manage deprecations when it's time to plan for a method's retirement. All in all time well spent.

My first module: Data::Compare::Plugins::Set::Object

2011-08-09T21:30:37Z

I wrote Data::Compare::Plugins::Set::Object (blech, what a mouthful) a couple months into my job at GSI. At the time I wasn't sure what if any their policy was on open source releases, so I was careful to do it on the side and assign copyright to myself. I still haven't found an explicit policy beyond my manager's "just use your best judgment" statement. Maybe that's for the best.

It's a tiny tiny little module (less than 40 lines of code) that does a tiny tiny little thing (compare deep data structures while doing correct comparisons for unordered sets). Its main significance to me was that it exposed me to all the necessary but not difficult work of packaging up a distribution for CPAN, including documentation, tests, metadata and an installer. I went with Module::Install for the latter since it seemed like it took care of most of the repetitive work. These days I favor Dist::Zilla -- like the tagline says, it's maximum overkill and through its plugin system can automate just about anything a Perl developer needs to do. I've even written a few plugins.

Oh, and why did I write DCPSO? I was working on a tool to compare WebLogic configuration files, which are just big bags of XML with a lot of settings in no particular order. Plain old diff is no good, and even the XML-savvy variants out there (correctly) insist that element order is significant. So my program slurped in the XML and converted it to a hierarchy of hashes, lists and (you guessed it) unordered sets, reporting how and where one server was truly configured differently from another so I could fix them to be more alike.

A pretty specialized task, but I figured that the set comparison bits could be used elsewhere so I released them. And if not, hey, it got me into CPAN authoring.

DBIx::Class::Schema::Critic and parameterized roles

2011-08-09T17:15:01Z

I originally started DBIx::Class::Schema::Critic as a code sample for a job application, but I thought it was worth releasing and continued independent development. Inspired by Perl::Critic, it's a package for comparing relational database schemas against a collection of best practice policies using the DBIx::Class Object/Relational Mapper.

At mst's behest I converted it from the Moose object system to his more lightweight Moo. But now that I've accumulated a few policy modules I'd like to refactor their commonalities out into roles.

Trouble is that Moo doesn't have an equivalent to Moose's MooseX::Role::Parameterized, and I can definitely see use for that in creating a bunch of similar roles for each DBIx::Class object a policy applies to.

So what to do? Can/should I port parameterized roles to Moo, while avoiding the overhead of a meta-object protocol like Moose's Class::MOP (which Moo explicitly rejects)? Or just make a bunch of more-or-less identical roles that differ only in name and attribute content, accepting the repetition as the price of minimalism?

About me

2011-08-09T17:00:00Z

I'm a developer currently working as a build automation engineer for an e-commerce services company. I've been working with Perl since 1994, and although I started focused on web applications I've gradually moved into toolsmithing and custom applications.

My PAUSE/CPAN ID is MJGARDNER, and I usually host my public development efforts on GitHub.