blogs.perl.org

One of the really fun aspects playing D&D was the plethora of spells that where available to the various player characters. To a programmer they introduce a whole nightmare of very vague rules that have to be implements some-how hopefully without an endless chain of it thens, given whens or, God help us, gotos or even gosub (yikes any one remember Applesoft BASIC basic?)

Because spellcasting is such a mine-field of subtle rules or at least rules that could never be applied in a game. For example the wish spell, In real game play a player could wish for, well almost anything, How would you do that in a computer game? The few times I have seen it in a game there was always a list of things you could choose from to happen.

So game designers usually opt for a more simplified spell system where the spells can be more closely codified. Usually blast this, heal that, protect this, or find that.

Thanx to Neil Bowers.

The main UAV::Pilot distro was getting too big. The WumpusRover server had already been spun off into its own distribution, and now the same is happening for many other portions of the system.

Reasons:

• UAV::Pilot hasn't been passing CPAN smoke testing because of the ffmpeg dependency. Splitting that off means the main distro can still be tested.
• There's no reason to get the WumpusRover stuff if you just want to play with the AR.Drone
• General aim towards making UAV::Pilot into the DBI of Drones

UAV::Pilot itself will contain all the basic roles used to build UAV clients and servers, as well as what video handling we can do in pure Perl.

UAV::Pilot::Video::Ffmpeg will have the non-pure Perl video decoding.

UAV::Pilot::SDL will take the current SDL handling, such as for joysticks and video display.

UAV::Pilot::ARDrone and UAV::Pilot::WumpusRover will take the client end of things for thier respective drones.

I expect the first release to have interdependency issues. I've tested things out on a clean install, but I still might have missed something. I'm going to be watching the CPAN smoke test reports closely and filling in fixes as they come.

[Via my blog]

There are various trivial command-line tools which I (have had to) create because of various reasons. Below are some of them:

norepeat

I didn't want to write this, but couldn't find any existing cli tool on CPAN or Debian. Since I put reminders on my ~/.bash_profile and I open many many terminals in a day, I needed a way to run some scripts just once a day. It's surprising that I couldn't find a tool to let me do it easily, and I hope someone can correct me on this.

exec-if-env

This began when I wanted to do something like:

if [[ "$OFFLINE" =="" ]]; then do-some-thing-that-needs-internet ...; done

in dist.ini to be run by Dist::Zilla::Plugin::Run. But of course you'll have to write something like this instead for it to work:

bash -c 'if [[ "$OFFLINE" =="" ]]; then do-some-thing-that-needs-internet ...; done'

Well I must say MooseX has helped me out again today, You might remember way back to the very first post of this AD&D series I mentioned that I would need all sorts of flavors for the values of my Character Abilities, ie tombstone, present values, magically enhanced values etc.

Well as I was programming along and setting up some playing parts of the game I was continually having to make calls back to the persistence layer (if you can call a YAML file that) for the starting value of an attribute for the current gaming session.

Then while playing with MAP of CPAN(you can tell I really like that site) I found what I think is a solution to this little problem MooseX::BuildArgs

This nifty little gem keeps your build arguments around for you in case you need them.
All I need to do is this

I’m look for some of the above, /with pre-reqs for my setup/:

• Debian
• AMD chip (see below)
• Can demo s/w running on my laptop

Suggestions most welcome.

I've been experimenting with something in the interviews I've been doing most recently. Turns out it works quite well, so I'm sharing this in the hope that it will help you as much as it has me.

One of the most important things on a software team is code reading comprehension and communication: the ability to read code, whether yours or someone else's, and walk through it, explaining to someone else what it does. Sometimes you'll be reading your code and explaining it to someone else; sometimes you'll be reading someone else's code and explaining it to yourself, sometimes you'll be looking at something brand-new to everyone and trying to puzzle it out.

By now you may have heard of gittip and wondering "why should I bother?"

Gittip is a way of donating small amounts of money to people who inspire you. That's an important point here. Peter Rabbitson, the maintainer of DBIx::Class, made a strong plea for people helping one another on gittip, but I'm going to make a slightly different argument for joining gittip, one that won't cost you a penny.

In my last AD&D post I was playing with MooseX::SetOnce 'trait' on some of my attributes in order to stop modification after the initial set.

This worked fine for the first few runs but quite quickly I had to add in all sorts of code to set default values stuff like this

my $hps=$character->current_hps()||0

Well now that I am getting quite confident with 'Moose' I decided why not discombobulate 'SetOnce' and see if I could make it do what I want.

So into the code I went.

Unit testing and continuous integration testing are ways to make sure that every change to our code won't break stuffs. We execute our tests after each commit and when we want to release our software.

On the other side of the spectrum, there are things outside our code that change and break our non-changing code. Platforms (like new versions of Perl) and dependencies, for example. Integration testing and CPAN Testers are some of the ways to make sure that dependencies and different versions of Perl still work with our software. We must do this testing regularly even when we're not changing our code, since the changing part is the other party.

There is a specific class of scenarios along this end of the spectrum when we're developing scraping libraries and API clients: source websites and API services change all the time, breaking our otherwise working code. For lack of a better term, I'm going to call this third party testing.

A few years ago I wrote a little video game in Perl called Lacuna Expanse. Tens of thousands of people have played it, and while I wouldn’t call it a raging success, it has paid for itself and continues to make a modest profit. That said, it wouldn’t have if I hadn’t been willing to make drastic changes to the design of it way late in its development. 

For the first 3 months of its development, Lacuna was storing it’s data in Amazon’s Simple Storage Service. When I had trouble getting that to scale I switched it over to MySQL. Three months into a 12 month development cycle is far, but not that far, for a major change.

About six months into the development cycle we decided to entirely change how space was configured. It was originally modeled in 3D space and the user would be able to see a slice of it at a time.

No, not Perl, but open source developers in general. It seems that FusionCharts is openly mocking open source developers on their front page, but use open source extensively.

Well I finally did learned something interesting looking at an Acme modules today.

I spotted Acme::Curse and at first glance it seemed to be just another of those silly play things in this namespace.

However the POD entry intrigued me.

Did you ever want to droo the blessing of an object? Well, now you can: Acme::Curse unblesses reference by returning a shallow, non-blessed copy of the object.

Well I do not know hot to 'droo' something (sounds painful) but the idea of a non-blessed copy is something I have need of.

So I looked inside and I saw this

[This post will be imported to cpanlists.org once the service is ready]

Do you want to develop your Perl project on your PC or laptop, without having to be constantly connected to the Internet? Then follow this simple guide.

Creating a CPAN mirror

First you'll want an offline CPAN mirror, where most of the useful Perl modules reside. There is already a document explaining how to do this, so go read it. At the time of this writing (Feb 2014), a full CPAN mirror stands at +- 16GB. Chances are you don't need a full mirror, but a mini one, which contains only the latest version of each module and currently stands at about 2.5GB. You can then update your offline mirror every so often (I do this about once a week).

Next, you'll also want App::cpanminus, if you don't already have it. This CPAN client makes it easy to install from an offline CPAN or DarkPAN mirror.

Now to install a module from your local mirror, you can simply do:

% cpanm --mirror /path/to/your/cpan --mirror-only Module::Name

This is part 11 of an ongoing series where I explore my relationship with Perl.  You may wish to begin at the beginning.

This week we look at trade-offs in expressivity.

Last week I told a story about a CS professor who was inexplicably afraid of recursion.  Other than the obvious moral of “don’t be afraid of things that use underlying complexity to make your external code simpler,”¹ what exactly does this have to do with Perl?

Timm Murray made this recording of my Stupid CPAN Tricks talk at MadMongers. He thinks he may record all MadMongers talks going forward.

[From my blog.]

Well there is always more things to post on and today I found yet another.
You might remember this post where I was setting starting money for player characters and you might remember this post where I pinched the idea from.

There was a flaw with this as it is true I was not longer able to set starting gold or hit points by doing something this

 return $self->current_gp()
          if ($self->current_gp());

or

About this posting series. Previous episodes: #1.

This time we're going to look at virtual filesystems. Perl currently seems to lack in this area compared to some other languages. There are no support for accessing or creating the various VFS's out there from Perl, except for Fuse.

First, KDE's KIO (KIO slaves). There are many slaves available, from accessing devices like Camera and Bluetooh, to the usual network protocols (HTTP, FTP, WebDAV, IMAP), to various settings and applications. One can create a KIO slave from, say Python and Ruby, but currently we lack a library to do so, even for accessing resources using KIO. The KDE4 Perl bindings project seems to lag or stop.

Second, the GNOME project's GVFS/GIO library. Perl does have a couple of libraries (VFS::Gnome, Gnome2::VFS) for the older GNOME VFS though.

As part of my rewriting of my testing classes (tired of hearing about it yet?), I found myself at the part where I needed to explain test fixtures. A fixture, in this context, is simply a particular known state that you can test against. In particular, I'm focusing on using database fixtures in tests. There's not a lot of good discussion about this and that's unfortunate because fixtures can really benefit your test suite.

I know it has been a while, but I’m finally getting around to posting my reflections on the Dallas-Ft. Worth Perl Mongers Winter Hackathon. Better late than never right? I will talk about my solution, but I also want to comment on the hackathon itself, which I thought was an excellent bit of fun.