With my last post I managed to apply a role to an instance of a class. What I think this will allow me to do is keep my base 'classes' from sprawling out of control while also encapsulation a good number of Game Rules' (or Biz Rules) in to small parts that I can easily reuse.
So far it has handled things quite well and even taught me a few things and I think has really exposed what Roles can do in Moose. Now as my D&D story moves along I am about to jump into what I think is going to be the to big test for Moose.
Character Races??
The differing races bring a new level of complexity to the game, well except mundane old humans who, unlike the other races, get no extra abilities, bonuses, penalties or alike.
A few months ago I released Graphics::Potrace, that provides Perl bindings to the potrace library. So, if you want to convert rasters into vectors from Perl... you know where to go.
You'll want to checkout the forks branch to see it in action. Read the docs for Test::Class::Moose::Role::Parallel to see how to use it (you'll probably need to create your own schedule).
What follows is a very naïve benchmark where I reduced a 12 minute test suite down to 30 seconds.
In my last D&D post I managed to get my generic 'OpenDoorsOnA' role working with my 'Fighter' class but I was left wondering if I would make better sense to make 'Exceptional' Strength a role then only use it the rare time that a 'Fighter' character has 18 strength????
Whenever I see the phrase 'conditionally loads the needed class' in the spec documentation it sends shivers down my spine. Then again anyone who as used DBI has used conditional loading of classes but most times I see silly shortcuts like this
JAGC is a server for code golf, where users write the shortest code using all standard features of scripting languages for solve tasks.
Users can add new tasks with unit tests, invent solutions and submit them.
JAGC will run tests for these solutions to determine the winner.
Pinto is an application for creating and managing a custom CPAN-like repository of Perl modules. Pjam is a tool which enables automatic creation of perl applications distribution archives from source code using pinto. Pjam enables continues integration in PERL. Right now pjam fits only Module:Build based projects ( Build.PL should be provided ) kept under subversion SCM, but I may change this if interest will be shown.
Pjam can be used in two ways - as command line utility and via web api to take some actions remotely.
Imagine you open up a test file and you see the following:
is foobar(3), 17, 'foobar(3) should return 17';
is foobar(2), 15, 'foobar(2) should return 15';
is foobar(3), 17, 'foobar(3) should return 17'; # duplicate?
is foobar(4), 20, 'foobar(4) should return 20';
is foobar(3), 17, 'foobar(3) should return 17'; # duplicate?
Well, that looks strange and duplicated tests are a code smell. However, it could be a code smell in one of two ways. It's probably the case that some programmer got sloppy and duplicated the tests so do you delete the extra tests?
With apologies to The Bard and The Scottish Play for the bad miss-quote above. I am continuing on with my D&D Moose Quest. The last post I left of with what to do now that I am going to try to use a number of Mixins and how they perhaps can work with other classes.
I have chosen the 'OpenDoorsOnA' character ability as it is one that is not only effected by 'Strength' it can also be effected by The 'Fighter Class' as they get an extra roll of % dice to extend there strength from 01 to 100 (00 in D&D speak) but still staying below 19. To account for this I could just fix my 'OpenDoorsOnA' role a little to look for the exceptional strength attribute like this
The section on reserved names in GCC documentation gives several recommendations that probably the vast majority of C programs in the world do not follow.
Nevertheless, these are all good practices, and an interesting exercice was to check how the latest stable perl source code behaves v.s. these recommendations. As of the day writing this blog entry, this is perl-5.18.1.
Detailed list of "violations" is at this gist, generated on linux and gcc version 4.8.2 (Debian 4.8.2-10). It is interesting to note that over 1316 hits, there are 8 categories, with 4 of them eating 98% of the hits:
In my last D&D post I left off with my six abilities as attributes in my character class and two 'traits/roles', ('Languages' and 'Henchmen') it did leave me with the question. Should I treat all or just some these character abilities as 'trait/roles' or should some be subs in my base class or $flip back and make my base abilities roles or even to go back to square one again and just make them subs in my original base class??
So I did a little reading and thinking and personally all these little code snippets do make my base class a little less cluttered which is nice but doesn't give me much. So I was wondering if I could reuse any of them and perhaps benefit from code reuse.
Hello world and Happy Holidays!! This is my first time blogging in blogs.perl.org and I figure I take this opportunity to ask the Perl community for suggestions on how I can make this Perl code run faster.
As the name of the script implies, I want to parse a cpan autobundle file so I can generate a list of distribution files from which I can create a Pinto repository. Please note that the script is incomplete and I am just wondering if there is a better approach to generate a list of distribution files.
A sample of an autobundle file can be found in the link below:
Hello, I'd like to post a link to the "table_watch_SQLite.pl" script. It's not a link in the strict sense because I couldn't manage to set a MetaCPAN perma-link to a single file.
The script is located in the "example" directory of the Term::Choose distro.
With "table_watch_SQLite.pl" one can search and read in Databases.
I use it for SQLite Databases but it should work with MySQL and PostgreSQL Databases too.
Well it seems I am making a little progress with D&D 'Character' classes I think I even got a role that will stick. I did have a little unfinished business from my previous post with my 'Character' class that I have to fix.
Namely it is important to the game that I know the current value of an ability which may change, and the initial value which will not, but I do not want to add in all sorts of attributes with funny odd names. So putting on my game design/players hat for a second, the initial ability values (rolls) are use mostly at character creation, for race and class selection. After that they are only useful as tombstone data.
An example is if a character is enchanted somehow or is just getting old and looses some 'Constitution' her 'Resurrection Survival' throw will lower but the maximum number of times a 'Character' can be resurrected is the initial 'Constitution' so I need that as well.
This is part 3 of an ongoing series where I explore my relationship with Perl. You may wish to begin at the beginning.
This week we look at the joys—and the frustrations—of Moose.
Last week I talked about why I believe that at least having the choice to program object-orientedly (without it being a huge pain in the ass) is vital to me as a programmer. In the comments I also touched briefly on why I think OOP in Perl, pre-Moose, is a huge pain in the ass, but honestly I didn’t put much effort into making that point. In my experience with other programmers (both in real life and online), the majority of them—perhaps 75%, at a rough guess—already agree with that and don’t need any convincing from me. And the rest are most likely not going to be convinced no matter what I say. Besides, this isn’t really a persuasive essay. I’m not trying to change anyone’s mind. It’s the story of my relationship with Perl. And I, like most other coders I know, have placed some value in OOP, at least in some circumstances. Also, I, like most other coders I know, felt that doing OOP in Perl was a bit of a chore.