Often we hear people talk about making your programming more "data-driven". When you can convert procedural code to a data structure (generally with a small procedural driver), instead of replicating procedural code, you just add another entry to your data structure. This is great with dispatch tables, repetitive chunks of code and state machines. However, there is a hidden benefit of it which will not only make you a better programmer, but it will make later maintenance programmers fail to notice a common flaw that your code lacks. They'll curse you if you have the flaw, but if you don't have it, they'll find that data-driven sections of your code are so easy to work with that they won't even think about it.

My current contract is lovely. I'm having a lot of fun and the environment is awesome. However, it's a short contract. I took it, in part, because it was a problem space I wanted to do more work in. Because it's a short contract I'm already working on negotiating my next contract (a perpetual hobby for freelancers), but I thought I'd experiment with a different approach: asking you to reach out to me. If you think I can help your company and you're not in a position to hire me directly, go to those who are and talk to them. If you want to hire me or one of the talented developers who works with me, drop me a line (I can't guarantee that I'm available, but you never know). If this approach works, I can do more work on open source or Veure instead of spending all of my "between" time negotiating contracts.

That being said, I don't always get contracts I negotiate for and sometimes I turn them down. However, if you're an individual considering freelancing, I thought it worth discussing some of the obstacles I've faced.

On my personal blog I wrote about Veure, an MMORPG that I'm writing in Perl. I followed that up with a post about the roadmap to an invite-only alpha. It's a lot of work, but my company has now decided to commit to it and figure out how to finance the work. This browser game is huge in intended scope, but fortunately, Perl has given me the power to get much of it done quickly. In fact, according to my private Veure github repo, I now have 17% of the ALPHA tasks done. That's up from 0% when I posted the roadmap a little over a week ago. In short, progress is fast.

Currently I'm working on character combat and that's where custom DBIx::Class resultsets have made my life easier.

Some of you may remember me talking quite a bit about Veure a few years ago when I was living in Amsterdam. I never discussed on the Web what it was about.

Now it's time to fess up, but I've posted the story of Veure to my personal blog instead of blogs.perl.org because it's not really about Perl (and blogs.perl.org kinda struggles with images). Veure was/is a Perl-based MMORPG. It's not done, but I included a few screenshots.

After reading about opening Perl module via name with vim, I realized it had a couple of (for me) limitations. First, I always operate from my top-level directory in a project, but that post doesn't prepend a lib/. Second, when I'm running a test suite, I see failure which might be from a module in the lib/ directory, but more often than not are in the t/lib/ directory. Since I keep all of my project directories identical, I can use one little bash function to handle this:

function vim {
  set -- "${@//:://}"
  module="lib/${@/%/.pm}"
  testclass="t/${@/%/.pm}"
  if [ -f $module ]; then
    command vim $module
  elif [ -f $testclass ]; then
    command vim $testclass
  else
    command vim "${@}"
  fi
}

So using it like this:

vim Veure::Foo::Bar::Baz

It will first look for lib/Veure/Foo/Bar/Baz.pm, and then look for t/lib/Veure/Foo/Bar/Baz.pm before finally giving up and just executing vim with whatever arguments I pass into it.

Improvements welcome.

I recently asked Adam Kennedy why he went back to blogging on use.perl.org. He replied:

I stopped posting to blogs.perl.org until I can migrate everything from use.perl over to it.

Anyone want to work on a migration script? I'd do it myself were it not for the Veure project I'm on. You just have to look at the gists in this post or the image on this post to see why the communication is so much richer here. Of course, there are plenty of other reasons, but clearly blogs.perl.org is a great, modern platform for the Perl community and I'd love to see more people promoting it.

Here's a crontab entry to run "echo 'Hello World'" every five minutes:

0-59/5    *    *    *     *   echo Hello World

Here's the .plist (property list) file you should create in OS X to do the same thing:

<?xml version="1.0" encoding="UTF-8"?>
<!DOCTYPE plist PUBLIC "-//Apple//DTD PLIST 1.0//EN" "http://www.apple.com/DTDs/PropertyList-1.0.dtd">
<plist version="1.0">
<dict>
    <key>Label</key>
    <string>org.veure.test</string>
    <key>ProgramArguments</key>
    <array>
        <string>echo</string>
        <string>Hello, World</string>
    </array>
    <key>RunAtLoad</key>
    <true/>
    <key>StartInterval</key>
    <integer>300</integer>
</dict>
</plist>

Apple lists there reasons why this is a good thing, but I confess that it seems more trouble than it's worth.

While my Enterprise Perl cartoon may seem like a joke, it's not. It's a sad fact that for larger codebases, tests can take a long, long time to run. The one I used on the BBC PIPs project took an hour and twenty minutes to run when I left that team. The one I use on the BBC Dynamite project takes just over an hour to run. Adam Kennedy, on the Enterprise Perl post, reported his tests can take a couple of hours to run.

It's very interesting watching people use Test::Class. Usually, it's wrong. This isn't really a fault of Test::Class, though (well, not much), but rather, it's a fault of its documentation. It needs more.

OK, you know how it works. Everybody who's really comfortable with testing often offers the following advice:

• Use Devel::Cover
• Don't strive for 100% coverage

This advice is absolutely correct, but misleading. It leaves you with an obvious question: what coverage do I want? This is where the danger lies.