The title is mostly for search engines for anyone who encounters this in the future.

I have, for no particular reason, decided to implement the fractal diamond-square terrain generation algorithm in Perl. Sometimes it's nice to just play.

    $$$$$$$$$$$$$$$$$$$$$$$####################*********************!**!!!!!!!!!!!!!
    $$$$$$$$$$$$$$$$$$$$$$#####################****************************!!!!!!!!!
    $$$$$$$$$$$$$$$$$$$$$$###########################*#*##*#*####************!!!!!!!
    ####$####$#$#$$$$$$$$$##########################################**********!!!!!!
    ################$$$$$$$$##########################################**********!!!!
    #################$$$$$$$$$##########################################**********!!
    *###############$$$$$$$$$$$#########################$##$#$$$$########**********!
    ****#*############$$#$##$##########################$$$$$$$$$$$########**********
    ********#############################################$$$$$$$$#########**********
    *************#########################################$#$##$########************
    !*!*************###################################################*************
    !!!!!!*!**********####*##*#*#######################################*************
    !!!!!!!!!!!*****************############$##########################*************
    =!!!!!!!!!!!!***************###########$$$##########################**#*#*******
    ====!!!!!!!!!!!!***********############$$$$$#############################*******
    ;=======!!=!!!!!!!**********##**#######$##############################**********
    ;;;;;;========!!!!!!!***************###############################*************
    ;;;;;;;;========!!!!!!!!*!*!**********############*##############************###
    ;;;;;;;;;;;=====!!!!!!!!!!!!!!!********#*#**************######*************#####
    :;;;;;;;;;;======!!!!!!!!!!!!!!!***************************#*#*********#########
    :::;;;;;;;;;======!!!!!!!!!!!!!!!*************************************##########
    ::::::;;;;;;=======!!!!!!!!!!!!!!!*!*******************************#############
    ~:::::;;;;;;;;=========!!=!!!!!!!!!!!!!*!***************************############
    ~~::::::;;;;;;;;=;===========!=!=!!!!!!!!!!!!!!!*********************#*#########
    ~~~~:::::::;;;;;;;;=;===============!!!!!!!!!!!!!!!*********************########
    ~~~~~~:::::::;;;;;;;;;;;;;=;==========!!!!!!!!!!!!!*!*******************########
    -~~~~~~~::::::::::;;;;;;;;;;;;;==========!=!!!!!!!!!!!!*****************########
    ----~~~~~~~::::::::::;;;;;;;;;;;;=============!!!!!!!!!***************##########
    ------~~~~~~~~:~:::::::;;;;;;;;;;;;;============!!!!!!!!**************#######$$$
    ,--------~-~~~~~~~:::::::::::;;;;;;;;;==========!!!!!!!!!***********#########$$$

I didn't actually intend for this to be a series of posts, but hey, that's the consequence of going with the flow rather than rigidly planning everything out beforehand and it nicely mirrors the theme of:

• How to be agile without testing
• When must you test your code?

If you have not read those, I strongly recommend that you do so before continuing on this post. Mostly the comments have been positive, but Adrian Howard has offered some interesting counter-points and some good resources for further reading. I will not say that he's wrong, but there is a different way of looking at this situation.

Recently I wrote about how to be agile without testing (if you haven't read that, you should do so before reading this). I was planning on a follow-up after some comments came in and so far the reaction was decidedly mixed. I think that's a shame because not many people seemed to focus on the punchline:

And that's really the most interesting idea of this entire post: your customer's behavior is more important than your application's behavior.

What's a bug?

Fair warning: if you're someone who has the shining light of the converted in your eyes and you've discovered the One True Way of writing software, you might feel a bit challenged by this post.

Your newest developer just pushed some code, but it has a bug. They screwed up the CSS and one of the links is a bright, glaring red instead of the muted blue that your company requires. While you're sitting with her, counseling her on the importance of testing, you get a call from marketing congratulating you on the last release. Sales have jumped 50%.

You know that the only change is the link color.

Was that code really a bug? Are you honestly going to roll it back?

More importantly, and this is the question that many people get wrong: what are you going to learn from this?

The YAPC::NA schedule has now been posted. This will be my first YAPC in the US and it looks like it's going to be great. Curiously, my last YAPC was in Frankfurt, Germany about half an hour away from where my father lives, and this YAPC is in Austin, a couple of hours from where my mother (and many other relatives) live. Thus, Perl is bringing me closer to my family :)

I have two talks accepted. The first is Testing with Test::Class::Moose. That one's a bit of a risk because I'm presenting what is effectively alpha code. However, I've been doing testing long enough that I'm fairly comfortable with what's being put forward. Target audience: if you've ever wanted to use Test::Class + Moose, Test::Class::Moose is the module for you. Plus, due to the reporting and extensibility, this module is probably a great choice for companies with larger test suites who want to better control and information over what's happening in their tests.

The second talk is Roles versus Inheritance. That one gets a bit mind-bendingly complicated for some folks because inheritance, unlike roles, is sometimes hard to wrap your brain around. It's not a tutorial on roles because frankly, roles are generally ridiculously easy to use once you understand them. Instead, it's an explanation of roles and the problem they're trying to solve.

I'm going freelance next month in a company that my wife and I are starting. Part of what I've been doing is consulting on various issues companies have and part of that is this whole notion of "agility". I fear that the term "agile" is becoming a meaningless buzzword because, while the core principles are sound, companies are just using the word to say "we have no process." It's a fine line between a process so lightweight that you don't even notice it and a process that doesn't exist and it's understandable that some companies will incorporate "agile" into their buzzword bingo without understanding what it really means. This is sad because it not only dilutes the utility of agile, but it creates a perfect straw man for agile detractors.

I've been thinking about the idea of adding optional "tags" to Test::Class::Moose, similar in concept to Mark Morgan's Test::Class::Filter::Tags. Here's an example of what that would look like:

sub test_get_profile : Tags(redis network) {
    ... tests go here
}

What could you do with that? Well, the other day our network went down at work. My test suite blocked because all of the tests which required a network would hang. With the above, I could do this:

Test::Class::Moose->new( exclude => 'network' )->runtests;

And have carried on with my work.

Or maybe you have tests that you know could run in parallel:

sub test_some_unit_test : Tags(parallel) {
    ... tests go here
}

With that, if someone writes a forking version of Test::Class::Moose, you could automatically pick out all of the tests which can safely run in parallel and the tests which cannot would be run sequentially in another child.

Of course, if you parallelize the tests, it would be nice if you knew how long different test classes and methods ran: it would make it easier to write a scheduler. Oh, that's right, Test::Class::Moose has reporting (and a branch where I'm beefing up the reporting docs).

There's a lot of potential here. I'm currently working on improving the documentation, but I think the abstract should say "test suites for power users". With all of the features it has, it's shaping up into a pretty nifty tool.

If you like this idea, I've added it to play.perl.org.

When you're using Redis, you can issue the select index command to use a different database (think "namespace"). By default Redis provides you with 16 different databases numbered 0 to 15 (you can configure it for more). All keys and values will be separate from any other keys and values in other databases. So how do you know which database you're in? As it turns out, Redis doesn't offer a command for directly querying that information.