Ovid

• Website: www.overseas-exile.com/
• About: Have Perl; Will Travel. Freelance Perl/Testing/Agile consultant. Photo by http://www.circle23.com/. Warning: that site is not safe for work. The photographer is a good friend of mine, though, and it's appropriate to credit his work.

Recent Actions

• Posted Cleaning up the Test::Class::Moose base class to Ovid

  I'm quite enjoying Test::Class::Moose. It's very easy to use and it gives you such fine-grained control over your test suite and powerful reporting capabilities that it's turning out to be far more powerful than I had expected. It's actually easy enough to use for…

• Posted Tags now available with Test::Class::Moose to Ovid

  Side note: Why did I miss that last Perl QA-Hackathon? I've attended every one since they started ... except for the last one. I missed it because the damned French government can't get around to reissuing my damned visa, despite the fact that they're legally required to. I've also had to…

• Posted Fractal Diamond-Square Terrain Generation in Perl to Ovid

  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…

• Posted Code Evolution Versus Intelligent Design to Ovid

  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:

  • ="http://blogs.perl.org/users/ovid/2013/04/how-to-be-agile-without-testi…
• Commented on How to be agile without testing
  Adrian, I like to make a distinction between customer and non-customer code. For non-customer code (such as for an open source project or a back end reporting system), there's a far different strategy which is applied. However, by "customer" code,...
• Commented on When Must You Test Your Code?
  Adrian, of course you can comment. What a strange question :)...
• Commented on When Must You Test Your Code?
  Gabor, regarding "harm" to maintenance developers, this may be an area I alluded to in the post where "do no harm" is universally accepted as a moral standard but the definition of "harm" varies. In this case, I would argue...
• Posted When Must You Test Your Code? to Ovid

  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…

• Commented on How to be agile without testing
  Sushisource: I'm very deliberately conflating monitoring and testing because they're different in the way that motorcycles and planes are different: they are different means of accomplishing the same general goal and each has strengths and weaknesses. But first ... You...
• Commented on How to be agile without testing
  Gabor, that's a great question and the answer is a resounding "no!" I was planning on writing a follow-up to this post entitled "when you must test" and the central criteria is simple: harm. It's a matter of simple ethics....
• Posted How to be agile without testing to Ovid

  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…

• Posted YAPC::NA Schedule is up to Ovid

  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…

• Commented on Random thoughts about agile software development
  Ether, I discovered that the deadline was extended and submitted the talk. However, it turns out that they're already have to turn away some speakers, some of then new. Rather than ask them to kick another speaker, I withdrew the...
• Commented on Another strike against AUTOLOAD
  Nathan, see perldoc mro....
• Commented on Discoverable tests and creating testing standards
  Michael, Thanks for the thoughtful comments. I'll have to take that into consideration....
• Posted Random thoughts about agile software development to Ovid

  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…

• Posted Adding "tags" to Test::Class::Moose to Ovid

  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…

• Commented on Play Perl is a Startup
  Good luck! I hope this works out for you :)...
• Posted Another strike against AUTOLOAD to Ovid

  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…

• Posted What does this PHP print? to Ovid

  Via this blog entry which I'm sure some of you have seen before, the following PHP prints "horse".

  <?php
    $arg = 'T';                                                             …

• Commented on Beginning Perl (Wrox) is now released
  Duncan, thanks for the report. It looks like I'm going to have to try and write something up to fix that for the errata. Damn!...
• Posted Better reporting for your test suite to Ovid

  It's very poorly documented, but Test::Class::Moose also has reporting built in.

  Here's how diag() all test classes from slowest to fastest, with time information:

  ="prettypri…

• Posted Using Roles with Test::Class::Moose to Ovid

  Note: this post assumes you have Test::Class::Moose version 0.06 or higher (on its way to the CPAN now).

  By now you may have heard of Test::Class::Moose. I wrote this to solve a need that…

• Commented on Discoverable tests and creating testing standards
  Johan: Yes, I love Devel::CoverX::Covered. It's complementary to this technique. I've written about it before, but I should do that again....
• Commented on Discoverable tests and creating testing standards
  Brian: completely coincidental. The directory layout I got after noticing how easy it is to find tests when using Test::Class. The stub tests are something I wanted to do for a while and I hacked them together in a few...
• Posted Discoverable tests and creating testing standards to Ovid

  I like writing code. I like writing tests. I don't like:

  • Trying to figure out where the tests are
  • Writing boilerplate
  • Finding yet another package without tests

  That last one is particularly vexing when you discover that your code is failing because

• Commented on no indirect considered harmful
  Hi Joel, The issue with tie is simple: it takes an ordinary variable and suddenly makes it magic. When abused (as it often is), it can make it very, very hard to figure out what is going on. It's also...
• Commented on no indirect considered harmful
  On a historical note, Ben Evans listed indirect method call syntax as one of the main reasons why he couldn't port Perl to the JVM. It's a huge blocker in terms of alternate implementations, so rather than allowing us to...
• Commented on A follow up on three-value logic in Perl
  Try the "fatal" option. Stringification is ditched, but it gives you a nice stack trace so you can (hopefully) figure out how you got there....
• Commented on A follow up on three-value logic in Perl
  J David Eisenberg: that looks tempting and it might be right for some code. However testing for $employee->salary being greater than zero skips a use case: what if an employee's salary is legitimately at zero and they should have the...

Comment Threads

• Adrian Howard commented on When Must You Test Your Code?

  can i comment?

• Adrian Howard commented on How to be agile without testing

  I do so love the continual delivery stuff. It makes building a

  That said - you seem to be assuming that the only reason to write tests is to find bugs / behaviour that the customer doesn't want. There are other reasons to write tests.

  For example:

  • I write the vast majority of my code using TDD. Here I'm writing tests to help my design.

  • Sometimes I write story level tests / acceptance tests / customer tests. Here I'm writing tests to help me figure out when I've done something.

  …

• Adrian Howard commented on When Must You Test Your Code?

  A few random musings.

  First, alluding back to my comment-that-never-made-it-through-MT-sucky-sign-in - a large chunk of your approach to when to write tests is based on the assumption that most tests are written to detect error (or harm - in your elegant repositioning of priorities).

  There are other reasons to write tests. To drive the design (you know I'm a huge TDD fan). To mark a goal for completion (a bunch of the BDD / acceptance test driven school). I'm sure they are more.

  Personally I tend to write lots of design-driving tests, and very few harm detection tests…

• Ross Attrill commented on When Must You Test Your Code?

  There are several things that I like about this article. I like that the article acknowledges technical debt is sometimes appropriate and provides some suggestions on managing that.

  Your concluding paragraph says it all.

• Adrian Howard commented on How to be agile without testing

  So I don't dispute what you say about tests, but I will cheerfully dispute whether or not currently recommended best practices in testing are the elusive Holy Grail of performant software.

  Hmmm.. whose best practices are you reading ;-)

  I've been running workshops on the advantages of a more experimental metric-driven approach for a couple of years now. Jez Humble's CD book was published nearly three years ago. The classic "The Deployment Production Line" paper from Agile 2006 is more than six years old now.

  We've got the Lean Startup folk ranting ab…