I recently started using flymake-mode in emacs, which does a “make on the fly” for the buffer you’re currently editing. For Perl, that basically means checking the code by running perl -c on it. If it sees any errors or warnings, it highlights this in the buffer. This is pretty handy for catching typos, although I’ve seen some weird false positive. Anyway, it’s a great tool, except that it does its checking by creating a file in the same directory as the one you’re editing.

I’ll be offering a one day Intro to Moose class at YAPC::NA 2011 in lovely Asheville, NC. To register, log in to the YAPC::NA site and then go to purchasing page. If you haven’t registered for YAPC yet, you can buy your conference ticket at the same time too. Intro to Moose Join us for an interactive hands-on course all about Moose, an OO system for Perl 5 that provides a simple declarative layer of “sugar” on top of a powerful, extensible meta-model.

Yesterday I converted all of my (many) Mercurial repos over to Git. The reason for this has very little to do with my preference. I’ve used both hg and git quite a bit over the past few years, and both are quite good. However, the (FOSS) Perl community as a whole seems to have settled on git, and people complained about having to use hg with my code. Setting up git reminded me of why I chose hg a few years back.

Many of the ideas in this post actually come from my friend Unny Nambudiripad, but Unny doesn’t blog, so I’ll have to write this up for him. The other day I was talking with Unny and Lisa Kimball about a nonprofit Lisa had looked at. She was disturbed because they’d spent their entire budget on salary. Unny and I didn’t think that was a problem, and Unny had a very good take on how to evaluate a nonprofit organization’s donation worthiness.

Since I’m looking for work these days, I’ve been doing a lot of interviewing. An interview is a potential employer’s chance to learn more about me, but it’s just as important that I learn about them. I think in an ideal interview, I spend at least as much time asking questions as answering. Over the years, I’ve created a standard list of questions that I want answered. What do you like best about working there?

(I’m still looking for a new position. Please check out my resume and contact me if you’re looking for a great Perl developer.) I was talking this weekend with Matt Mackall about Python 3 and Perl 6. Matt is the creator of Mercurial, so he is deeply invested in Python. He was asking about the relationship between Perl 5 and Perl 6, and we were comparing it with the relationship of Python 2 and 3.

(I’m still looking for a new position. Please check out my resume and contact me if you’re looking for a great Perl developer.) There was a lot of interest in Chloro, my new form library, when I blogged about it last week. I just released 0.01. I’ve started integrating Chloro into a web app that I’m developing, and I really like using it so far. That said, this release should be considered an alpha, and I reserve the right to completely rewrite it for the next release.

(I’m still looking for a new position. Please check out my resume and contact me if you’re looking for a great Perl developer.) Perhaps I should title this entry “Building a Slightly Less Horrible Form Library.” When I mentioned form processing in the Moose IRC channel recently, mst said “form modules are … satan”. That sounds about right. I’ve looked at a number of form libraries over the years. Recently I started using HTML::FormHandler (HFH) in an application I’m working on, but eventually I realized it just didn’t work for me.

My current position at Thomson Reuters is a contract position scheduled to end on April 29. It looks like budget constraints dictate that this contract won’t be renewed, so it’s time for me to get my interviewing shoes on. I’m looking for consulting work (part time up to about 30 hours a week). My skill set includes Perl (no kidding), Javascript, web applications, non-web applications (batch data processing, daemons, etc), database design, testing, development processes, and lots of other good stuff.

Perl Best Practices (PBP) was released in 2004, about 7 years ago. Perl is a great language, but its culture of TIMTOWTDI can be a problem. These days, we often hear that “there’s more than one way to do it, but sometimes consistency is not a bad thing either” (TIMTOWTDIBSCINABTE). PBP deserves a lot of credit for encouraging discussion about the downsides of TIMTOWTDI. PBP has a lot of recommendations. A lot of them are fairly trivial, like recommendations on code formatting.