This month's technical presentation at Chicago Perl Mongers was about Sean Blanton's project called App::Services. It's an interesting project that uses Bread::Board to access resources like databases, logging, ssh, and others.

Along the way, we discussed logging practices (most of us are using Log::Log4perl), and the best way to get a Perl module ready for CPAN (I suggested using Module::Build directly, but Dist::Zilla outvoted me).

Sean mentioned in passing the Salt stack for executing commands across multiple machines, which looks like a very interesting alternative to more detailed tools like Puppet or Chef. Salt seems to be just a simple way to execute commands on multiple machines. Those commands could be administrative (restart httpd), or they could be the application.

One other very interesting thing from App::Services was providing a role for the larger system to use. So one creates App::Service::Log::Log4perl and App::Service::Log::Role, and in other services you consume the App::Service::Log::Role and then can use the Log4perl service. What's interesting about this is that the role is provided alongside the logging service, it isn't something that you have to create yourself. Doing it this way improves interoperability and simplifies adoption by giving you the tedious bits already. It's the difference between "Here's a service, figure out how to use it best" and "Here's a service, and here's a good way to use it" (I've been doing something similar by providing Test::MockObject implementations of my modules for testing purposes in the same distribution as the module itself. An "official" mock object).

In two weeks we have another project night, which I'm hoping is as productive as the last. If you're in the Chicago area, check us out on the Chicago Perl Mongers meetup page.

How often have I told myself, "I'll kludge this now and rewrite it later"? And how many times did I actually go back and rewrite that kludgy bit? "Too often" and "not enough". Many job postings include the phrase "update legacy applications," as a euphemism for "rewrite poorly-designed spaghetti." The Y2K problem was a huge exercise in code out-living the developer's plan, with a healthy dose of cargo-culting thrown in. Lately, I've been learning to plan for a likely possibility: My code will survive to haunt my bug lists and my resume for a long time.

We developers are a lazy lot, it's one of our greatest strengths. But like all virtues, it is a double-edged sword that must be wielded responsibly. Laziness is defined as maximum gain for minimal effort. For laziness's sake, I write automated tests to avoid manual testing, I build a development server that mimics production closely so I don't get woken up at 2:00 am when my code blows up, I write documentation that explains the design of the software so I don't have to trace through layers of code to figure it out, and anything else I can do to make sure I don't have to work as hard solving the same problem in the future.

Automated tests are the programmer's best friend. How do I know my code works? By running it. How do I know it works every time I change something? By running it again. Automated tests are simply running the code, controlling the input and checking the output. Since I write tests once according to expected input and output, I can refactor the entire program and be absolutely sure it works for that set of input. I don't need to test manually, clicking everywhere or preparing input on-the-fly, which saves me a lot of time in the long run (because this code will live forever).

A development server is another necessity for laziness. At a former employer I instituted a policy: All custom client projects included renting a development/staging server, no exceptions. This staging server could be completely destroyed and rebuilt with zero consequences. Our deployment processes were automated (more laziness) to make it easy to recover from mistakes. Once our automated tests passed, the clients had a place they could verify the expected behavior and see their ideas in action before releasing the code on to an important, production system. We instituted this policy from learning our lesson: Our laptops were never the same as the production server, so we needed some place that was. Deploying code directly to production is only rarely without unforeseen consequences.

I've been called a hero a couple times now. I don't believe or understand why, but I've noticed it's always after I mention how much I enjoy writing documentation. Writing documentation is like explaining my code to someone else, usually future me: It forces me to think critically about the code, how it works, and what side-effects and edge-cases it has. Every time I go back to write documentation I've found bugs in my code: incorrect assumptions, inelegant algorithms, or undesired side-effects. Usually, the first other person who reads them finds even more: things I didn't think of, or things I thought would never be a problem (famous last words). Writing the documentation gets me out of the code mindset and into the design mindset, and well-designed code is code that will live forever.

There is nothing more boring than a solved problem. By making sure I have automated tests, a sandbox environment, good documentation, I can make maintenance easier, which is the true definition of laziness: Maximum gain for minimum effort.

We had our first project night at Chicago.PM this week, where we discussed ideas and wrote code for a Perl REPL GUI program (App-Prima-REPL on Github) by David Mertens built on Prima.

There were some small ideas to make the program more user-friendly, and some larger ideas like an IRC client and guided tutorials based on the same format that http://perltuts.com uses.

I'm hoping that if I keep saying this, I'll be embarrassed into doing it: I would really love to see the Ruby Koans translated into Perl (in spirit, if not in actual content). I've started writing down ideas for chapters, but there is a lot of content to cover.

I added a -I flag and a -M flag to the prima-repl command-line launcher that work as close to perl's flags as I could get. This is one of the things I love about prove and plackup: Where it makes sense, they work like perl does. So now the prima-repl can have subs and modules imported on the command-line.

Altogether it was a wonderfully productive evening and I'm looking forward to the next one.