ZipRecruiter Wants You

By now I'm sure that some of you have heard about ZipRecruiter, the job board startup that recently picked up $63 million dollars in funding and whose backend is written almost entirely in Perl using DBIx::Class, Catalyst, Template Toolkit. And they use sqitch for sane database management.

You'll probably recognize some of the names of people who work with them. Randal Schwartz has been consulting with them for a year. Mark Jason Dominus works there and has released some nifty open source software he wrote for them and while I don't claim to be as talented as Randal or Mark, I have been consulting there for a while now. It's huge amounts of fun. There are also tons of men and women who aren't as publicly involved in tech communities who are nonetheless very talented.

They're growing like mad and hiring for quite a few positions. And yes, they need Perl developers (and Python, and Javascript, and, and, and ...). And they do allow remote work.

Aside from the benefits they list in working there, here are some that I know readers of this blog will appreciate:

  • They're happy to hear new ideas
  • They love it when people write tests
  • They love to see refactoring to cleaner designs

I might add that when they picked up that $63 million in funding, they were already very profitable and are still growing like mad.Come join us and tell 'em I sent you (note: I don't get any perks for this. I just like the company and want to help Perl devs, too).

Veure: Building the Look-and-Feel

No Perl in this post. This is mainly for the people who've asked me to keep blogging about the creation of Veure.

In trying to explain to a designer what was going on, I had to make it clear that "space stations" in Veure aren't the tiny doughnut things that Ronnie Raygun envisioned launching (those of you who are old enough might just remember the "Raygun" reference).

Instead, as far in the future as Veure is imagined, creating a new space station involves dropping a robot on a large asteroid, letting it hollow out said asteroid, spinning it, sealing it, and then building on the inside. I threw together this (poor) concept art to show her what I meant (the white bar at the top is the central lighting bar for the station).

Source image of Plzeƈ od Karlova courtesy Wikimedia Commons

The Moose::Role Required "attributes" Bug

Every once in a while, someone stumbles across a bug in Moose whereby you can't seem to use attributes to resolve role requirements. BooK posted one solution to this, but it has a couple of drawbacks.

The first is that it requires the with() line to be listed after attribute declarations. I find that very annoying.

The second problem with his solution is that it doesn't work (sorry, BooK!). Fortunately, there's a very easy workaround to the problem.

Using Role as Partial Classes

For Veure, my text MMORPG, I found myself worrying about the Character class turning into a god object. At over 2,300 lines, 105 methods, and growing, it was getting hard to keep track of everything. I want my code to be clean and easy to follow. As a result, when new behavior arose, I started thinking of other places to put behavior, and wound up with abominations like this:

if ( $missions->has_misssion_for( $character, $npc ) ) {
    ...
}

If you're not familiar with the terminology, NPC stands for "non player character" and, as you might guess, they're implemented via the same class as player characters. So what does the above code do? Does it mean that your character has a mission for an NPC? Does it mean that an NPC has a mission for your character? Does it mean that your missions have a mission for ... wait, what does that even mean? The last one, though, is the natural reading of the above.

All because I was trying to limit the size of the Character class.

But wait, this is an MMORPG. Your character drives everything. Your character moves. Your character goes on missions. Your character has to interact with their inventory. Your character has to do all sorts of things and artificially shoving those things into different classes just to avoid the "god object" makes for unclear code like the above. However, shoving all of that behavior into the Character class means it's getting huge and unreadable.

Until now.

A small puzzle for you

This had me stumped for a bit, but I was quite pleased when I came up with a relatively simple solution.

Given several arrays, each of which has elements which are a subset of allowed elements, and given that every allowed element appears at least once in each array, how do I rewrite all arrays such that each element of each array which has an identical value to an element in another array has the same index number in each array, with missing elements being undef?

OK, that was a mouthful. Here's an example which should make it clear:

@a = ( 'b', 'c', 'f' );
@b = ( 'a', 'd' );
@c = ( 'c', 'd', 'e' );

I should have the following when I'm done:

@a = (  undef,    'b',    'c',  undef,  undef,    'f' );
@b = (    'a',  undef,  undef,    'd',  undef,  undef );
@c = (  undef,  undef,    'c',    'd',    'e',  undef );

In other words, I'm trying to line up all of those values (because they're going to an HTML table and my $client needed to see the missing values). Once you see the answer to the puzzle, it's actually not too hard.

Post your solutions below!

About Ovid

user-pic Freelance Perl/Testing/Agile consultant and trainer. See http://www.allaroundtheworld.fr/ for our services. If you have a problem with Perl, we will solve it for you. And don't forget to buy my book! http://www.amazon.com/Beginning-Perl-Curtis-Poe/dp/1118013840/