Dave Sherohman

A user on SitePoint asked about "[Perl Modules] Installing in non-standard (isolated) locations.", which was really about how to have two versions of a webapp on the same server, with each referencing a different version of a module. I provided simple explanations of how to accomplish this using either PERL5LIB or "use lib".

After an extended absence (due to a combination of few ideas of things to write for them, shortages of time, and platform-specific challenges), I'm back into the DIC52 with an entry for the HTML5 challenge, Traspel Lite. This is a simple one-page spellcasting game, pitting the player against a series of foes of increasing difficulty.

Steinbach's guideline is a well-known maxim in the tech world, but I have a variation on it which is at least as important (and much more serious):

There was a time when we had to make due with cryptic error codes, but it's not 1960 any more. Memory, disk, and bandwidth are cheap these days. We can afford to write programs with the ability to report clearly and accurately what has gone wrong rather than requiring the user to look it up in a manual somewhere or, worse, try to guess what happened.

Cross-posted from dream.in.code:

That's a big question which goes straight to the heart of Perl and plays a big role in why Perl is such a love-it-or-hate-it language.

For this week, I've written up an Ars Magica die roller. Ars Magica's dice conventions are unique, using three different types of rolls, all of which are based on ten-sided dice:

• Simple Roll: This is just your basic d10 roll with 0 read as 10.
• Quality Roll: In a quality roll, 2-10 are read normally, but a roll of 1 means to re-roll, doubling the result. Further rolls of 1 will repeatedly double the final result, allowing for arbitrarily high rolls. For example, rolling 1-1-1-7 is read as 56 (7, doubled three times).
• Stress Roll: Stress rolls are basically like quality rolls, but with the potential for very bad results as well as very good. A stress die is rolled just like a quality die, except that, if the initial roll is a 0, the total of the roll is 0, regardless of any modifiers, and the die is rerolled to determine whether you have botched your attempted action. Under poor circumstances, additional botch dice may be called for. If any botch die comes up 0, something bad has happened in addition to having failed. If multiple botch dice are rolled and more than one 0 is rolled, each 0 makes the result even worse.

This week is something of a gimme for me, given that I've already done app development against the Twitter API. For the sake of something simple and accessible, I opted to revise my earlier Iron Man post on Monitoring Hashtags with Perl and Net::Twitter to make use of Twitter::TagGrep and call that my DIC 52 Weeks of Code entry for this week:

I've been following the site </dream.in.code> for a good while now, mostly helping people out with their Perl problems. Today, I found an announcement that they're doing a "52 Weeks Of Code" Challenge, which started yesterday. It looks interesting (especially since they've suggested one week's challenge will be in Brainfuck), so I'll be participating and posting my solutions here.

The first challenge is in jQuery and looks pretty simple, but I have other code that I'm pushing to get done today, so it can wait until (hopefully) tomorrow.

Call it loose coupling, application of encapsulation, avoiding god objects, plugin-based architecture, or whatever else, but I don't like having objects which carry out the functions of another class's objects. I believe that each class should contain the full measure of its functionality, so that adding it to a project is as simple as use MyClass; without requiring modification of any existing code for the new class to do its thing. (Existing code will often need to be modified to tell it to use the new class, of course, but that's not what I'm talking about here.)

Unfortunately, KiokuDB::Tutorial's example of using Search::GIN hardcodes knowledge of how the Person class should be indexed into the database ->connect call. I'm sure this was just done for the sake of showing the simplest possible example, but here's how I set things up so that my ->connects don't have to change when a new class or index is added.

My second trip to #kiokudb came about when I got to the point of wanting to edit my objects through a web interface, which called for identifying the object I was editing. While Kioku was assigning unique IDs to each object which would be perfect for the purpose, the objects themselves didn't have access to their IDs and so couldn't provide them to my templates for insertion in the pages. Starting from my root node and walking the object graph every time seemed unreasonable and

$dir->store($obj);
$obj->id($dir->object_to_id($conf));
$dir->store($obj);

was thoroughly unsatisfactory, even ignoring its issues with handling objects stored indirectly by reference.

As mentioned in my last post here, I've recently started in on a free-time project to teach myself some of the more-currently-popular modules that I haven't been using. So far, that means Moose and KiokuDB. Moose has been coming along pretty readily so far (I'm not entirely sure whether that's because of MooseX::Declare or in spite of it), but KiokuDB has had me scratching my head quite a bit and sent me off to IRC twice for help.