Dave Sherohman

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.

So it's back to Perl Iron Man after *mumble* months. And back to square one in Perl Iron Man, thanks to those months, but that's no real surprise - I've always been a lousy blogger because I never seem to be able to find topics to write about on anything resembling a regular basis.

I do have another excuse aside from lack of topics, though: I was too busy writing Perl to bother with taking the time to write about Perl.

I've started a long-past-due update of the "Work" section of this site, expanding substantially on the description of my freelance work and adding links to the long and short versions of my CV/resume. A project portfolio, code samples, and information on my involvement in the broader software development community should also be coming within the next few days.

Marc Mims has recently taken over maintainership of Net::Twitter and rebuilt it on top of Moose. This has been a cause of much concern for me, as it does not appear that the non-Moose Net::Twitter::Lite will meet my needs. Yesterday's Net::Twitter Roadmap post proved quite reassuring in that regard, but did not fully address my concerns. As Marc's blog does not appear to support comments, I am posting my thoughts on it here.

In the last couple weeks, I've seen Perl questions on at least two separate forums which revolved around the connection between .pm files and Perl packages. Really, though, this connection is quite easy to understand if you just remember one thing:

It doesn't exist.