In my last post I used 'Moose::Util::TypeConstraints' to limit my ability scores to a range between 3~18 now onto the next little test for Moose.
The next rule I want to enforce is, if the passed in ability scores are a Grot Character, (one that can never have a class as all the scores are too low) then I want an error to be thrown.
I could of course just add in a bunch of 'if' or 'given' s in the 'BUILD' or 'around BUILDARGS' but that is not a very elegant solution and as 'Race' is chosen before 'Class' I may have to apply these rules more than once as a 'Demi-Human Character' abilities are adjusted which may preclude a 'Class' as well.
This post announces the release of Mojolicious::Command::nopaste, a clone of App::Nopaste using the Mojolicious toolkit.
I wrote it mostly as an example of using Mojolicious and its command system, but it has the side benefit of having a much lighter dependency chain than the venerable original (I already have the only required dependency on every box I use).
It also has a few bugfixes that the nopaste author either hasn’t tripped on, or had the time to fix (mostly in the Clipboard interaction on Linux) (sartak if you want to ping me I’d be happy to work with you on it). It has a slightly different list of services, including the very fun MathB.in but lacking Gist for now since the OAuth is something I don’t want to deal with yet. Any other services that people are interested in may be contributed via a PR or even a decent api spec.
Test::Class::Moose version 0.40 has been uploaded to the CPAN. Or you can get it now on github. It's a major improvement in many ways, including the fact that parallel testing is now in main branch and it works much better! Read on for the changes.
In my last post I said I was going to look at my 'Character Creation' part of my application and since then I have been doing a little digging and I believe that Moose will help me out here.
So I thought I might just want only one of these for my app and looked at 'MooseX::Singleton' but with a round of sober second thought I dropped that idea. Seems if I did that then I will have only one 'Instance' about which is good for say my DB connection but not so good if I want more than 1 user creating character's at a time. But at least I did see how Moose will help me.
As my BPM model indicates there are at maximum only 3 choices that must be made in character creation.
This is part 6 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 question of creativity in programming.
Last week I talked about how the linguistics baked into Perl allow for maximum programmer creativity. But of course all that discussion contains a hidden premise: that allowing for programmer creativity is something desireable. But is it really? Maybe programmer creativity isn’t that great an idea.
This week I received some special help on SO in understanding how the goatse operator works. I was very thankful for everyone's help. Thesetwo articles were also very helpful and I recommend reading them.
Part of my confusion over the goatse operator was not knowing the difference between list and scalar assignment operators, which both are indicated via '='. Further confusing is the fact that each can be used in either scalar or list context, so you can have list assignment in scalar context or scalar assignment in list context.
The type of assignment is determined by what is being assigned to. As ikegami says, assignment to an aggregate is a list assignment, aggregate meaning an array, a hash, a parenthetical expression, or a my/our/local variable declared with parens.
Most git wrappers on CPAN (Git::Wrapper, Git::Class and Git::Sub offer methods (or functions) based on the existing git subcommands (usually limited to a subset of the porcelain commands). Git::Repository is different.
Having thoroughly examined how Moose roles work, finding a good workable solutions to any problems I encountered, spec-ed out my basic Namespace, captured 90% of the roles I will need to create and mapped out the character creation process now I have t decide on how to put all the bits and pieces together.
So far I have these three 'Application' blocks Identified.
Character Creation
Character Instantiation
Game Play
I didn't bother to mention persistence as that is an obvious one but as seen below easy to implement.
So my dilemma now is to choose an appropriate design for the 'Application' as a whole.
From my diagram from an earlier post on character creation indicates that a simple Procedural style. The user starts with a set of dice rolls for abilities and is then presented with choices until a character comes out the end and is either persisted or dropped.
By default, Pinto is configured to use cpan.perl.org and backpan.perl.org as the upstream repositories. But since cpan.perl.org is currently offline, Pinto will throw an exception if you try to pull a module or distribution from upstream.
You can work around this by setting the sources key in the repository configuration file to cpan.stratopan.com. That site is a full mirror of both CPAN and BackPAN. The configuration file is located at .pinto/config/pinto.ini within the repository directory.
Well I was thinking today to present a net little perl script that read the PDF file I created in my last post and get some of the presto-chango automatic code generation.
Well I quickly gave that up as the PDF conversion simply but everything in alphabetical order so I lost any structure I had there. I did have to cheat and not use a PDF reader. I just slurped it in as a file and then use a reg-ex to suck out the bits I wanted. Really I had to double cheat and peek at the file first to see what to suck out.
Long story short without the structure intact I could of resorted to renaming all my objects to preserve the structure ie 1.1, 1.2 ~ 1.2.1 but that would take longer than just writing the Moose.
Intro
I would rather be quiet about this never ending topic, but after brians interesting post
about comparing percentages I have to contribute my thoughts.
I read some other posts about computer language rankings. Some supposedly based on web traffic
and others on books sales.
All this posts do mention some kind of measurements based on numbers. But I think that there are
other view points or considerations to take into account before asking for a valid computer
language ranking.
Ranking what?
In order to ranking things these must be comparable with each other.
Beside technical or linguistic considerations, let's assume as a comparison criteria
the quantitative or qualitative use of each computer language. Let the confidence of the
measurement (if possible at all) of the use as a theme for another post.
So, any sense of ranking JavaScript and C?
What can I do at system level with JavaScript? What can I do for a web page with C?
Well continuing on with my AD&D theme am taking another break from Moose Code and looking at design again. Well this time I wanted to see how many common 'roles' I might have between my differing Character Races and Classes and the large number of scribblings I have laying under my desk where getting annoying.
So I started with what I was most familiar with with ye old ULM Object Diagram using a little freeware designer from smartdraw. Well it worked ok for the base attributes of my Character class (name,race, ability scores etc.) as they will be put into a model eventually but it wasn't helping me with my roles as these are, for lack of a better words 'Business rules' and they where just cluttering up my diagram.
[I wrote this for use.perl.org in 2006, but I keep looking for it at the beginning of each year as numeric illiterates try to do the same flawed analysis to prove something about programming languages in the last year (this year it's Andrew Binstock at DDJ). I'm adding it to blogs.perl.org in case use.perl.org (now read only) suddenly disappears.]
sigzero recently asked if the Perl community was atrophying, someone else pointed me to Tim O'Reilly's State of the Computer Book Market, and there's a Wikipedia revert war over Tiobe's Programming Programming Index. All of these suffer from a misunderstanding of percentages and their value in making decisions and reaching conclusions. This is especially egregious when people divorce the percentages from the absolute numbers (either because the original data are restricted or the people know that they tell a different story).
With rperl we have now a second serious perl
compiler project, which has distinctive advantages over B::C and
B::CC, but also several disadvantages.
Basically we need to define compilation blocks for rperl (restricted
perl) - typed and compile-time optimizable syntax - and combine it
with unoptimizable dynamic perl5 syntax, to be able to run ordinary
perl5 code, partially optimized.
