Well in this entry I am going go to the next step and this time enter a 'Race' into the instantiation arguments of my Creator and it should then give me a list of 'Player Classes' that are available to the entered Ability rolls and Race selection.
Of course I will still have to the same checks for 'Grot' and 'Race' as I do not want someone to sneak something in by simply adding a 'Race' to the mix.
So like my LARP party above lets start with a new code in my 'Creator' class's 'BEGIN';
The following program contains 3 test cases that you need to make pass. To do
that, you should replace XXX in the assignments to $a, $b and $c by the
right magic values.
So far our company has been growing quickly and I'm quite pleased with that. I'm doubly pleased to announce that Dave Cross and Michael Schwern have joined us as trainers and consultants. Read the announcement here.
Well in my last post I made use of the visitor pattern so sort out 'Grot' characters at an early stage. My next challenge is to set the race of my 'Character' from one of the ones below.
Well not all of these just the original 7 A D&D races. I could try my visitor pattern again but part of what I want to build into this system is the ability to eventually expand into the odd miss-mash of races above. So I could go back and attempt to do this with parametrized roles like I tried to do with Grot character as in this post but what I really want is to load in my 'Ability' rolls and then have it tell me what 'Race' I could be rather then attempting to load all those roles.
I guess I could use a simple given when in sub on my 'Creator' class but then I would have to recode things if I added a new 'Race' into the mix.
I don’t want to install 300 more packages only because I need this only one small module which I cloned from git repository. I can’t install 300 more packages for Dzil because I do it on Android where there is no Dzill because I need to fix some modules which I can’t fix because of missing Dzil. Damn it.
Dist::Zilla: real Catch-22
Fortunately usually I can prepare tiny stub with Makefile.PL:
# Very simple stub because of damn Dist::Zilla
use ExtUtils::MakeMaker;
WriteMakefile( 'PL_FILES' => {}, 'VERSION' => '0.01', 'EXE_FILES' => [] );
Stupid? If it’s stupid and it works, it’s not stupid. ExtUtils::MakeMaker beats Dist::Zilla.
We have enabled the Act payment functionality for GPW2014. You can now pay for your tickets and receive your invoices. As a matter of fact we have now finalized our ticket prices.
If you want to take advantage of the early bird rebate you have to hurry. This phase ends at the end of January 2014.
We would also like to thank STRATO AG for sponsoring us.
Since our talk schedule is full we are now closing submissions. Lightning talks can still be submitted via email or during the workshop.
I've got a script for looking at locally installed modules, used thusly:
% pmvi Net::FTP
I use this a lot, since I often find myself wanting to check exactly what a module is doing, either to learn from it, because the doc isn't clear, or I have reason not to trust the doc, or curiosity, or ...
Here's the script:
#!/bin/sh
/usr/bin/view `mpath $*`
view is a symlink to vim, and mpath comes with my Module::Path module.
On one of my earlier posts I mentioned a Grot character, in other words a set of ability rolls that can not result in a playable character.
After a few dead ends and a little frustration I think I can now use the visitor pattern to check and see if I have a Grot before I go forward.
So All I really need to do is add into each of my 'Ability' classes the rule that applies for it. Using good old strength again the rule is a roll under 6 means you can only be a MU (Magic User) as well if you are going to me a MU you must have intelligence over 8.
So in each 'Ability' class I have an 'is_grot' which tests for its grot condition. So in each of my Abblitiy classes I add something like this
I don't think syntax has much to do with readability. Joel Berger posted his thought on a Perl versus Python matchup, but I think that falls into the same trap that most of these arguments do. If we're stuck at the level of syntax, we're really not very good programmers. I don't think any of us choose a language based on the syntax, but that's all we seem to fight about in the comparisons.
I can't go into the full background and a couple of details have been changed to protect the innocent, but I was chatting with a company that I'll call Acme. They faced a situation that I've seen before and usually ends badly. The code base they have looks like this:
Roughly a million lines of legacy spaghetti code
Very little use of existing libraries ("not invented here" syndrome)
Siloed developers
Hard to maintain and extend
Prospective developers see the code and "nope" the heck out of there
I have spoken to quite a few companies in this mess and Acme had a solution for dealing with it: they were going to rewrite the code base in another language.
Well leaving off from my last post I was a little frustrated with Moose but not as much as our Moose friend below.
So after a good night of sleep and a large pot of coffee I stumbled on a Moose solution.
Seems some-one else must of had the same problem, some time before my entry into the Moose space, and a quick search of the MooseX namespace and I found 'MooseX::Role::BuildInstanceOf'* which looked to be what I wanted. So here we go
Well in my creator class I started from scratch again with
It is known that one can label loops (or arbitrary blocks) in Perl 5, using
the syntax of MYLABEL: while (COND()) { BLOCK }
or MYLABEL: for my $x (@array) { BLOCK } and then one can
do last MYLABEL;, next MYLABEL;, or
redo MYLABEL; (for more information see
perldoc perlsyn).
However, I was unable to find how to do something
like that in Perl 6, despite some amount of searching. Luckily, the people
on the Perl 6 helped me.
The answer is that in Perl 6, it's essentially not different:
In a recent post, our own Buddy Burden expounds on the relative merits of readability vs flexibility (in the guise of Python vs Perl respectively). While he does not completely concede the point that Python is more readable than Perl, I will go so far as to negate it. In fact, I would say that the prettiness of Python can even mask some real readability issues.
I have been a Perl programmer for several years, but early this summer took a job writing Python. I’m glad I’ve learned it, there are several things that I would love to see added to Perl, most notably a set type and a proper in operator (~~ got close). That said I will absolutely not concede that Python is easier to read than Perl, as all too often is taken as the axiom that many believe it is.
In my last post I attempted to use 'Class' as roles to weed out Grot characters that can never be used in the game as a PC. In the end I took the advice found in JT Smith's recent post and abandoned that idea.
While I want my program to be flexible enough to allow new races and classes to be added easily. What I do know that there will always be just six 'Ability' rolls, so why not just use them.
I will have to change a number of things in my 'Creator' class as I will drop my 6 Abilities them as simple Int 'Attributes' and I will try to use a class for each that has a 'roll' attribute for the values and on the 'BUILD' of each of these new classes I can see if the present score qualifies in one of the 'Character Classes' as that is all I really need to know.
I know this package is on the CPAN, but I can't find it. I'm revising some training material for my Perl testing course and want a simpler exporter primarily so that it can fit on my slides easier. What I currently have is:
package Some::Package;
use Ovid::Exporter qw(sub1 sub2);
sub sub1 { ... }
sub sub2 { ... }
And you would use it as you would expect:
use Some::Package qw(sub1 sub2);
# or
use Some::Package ':all';
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.
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.
