Test-driven development is great, but it comes with the overhead of all the prerequisites required by the testing libraries. So you may wish not to run all of your tests by default when the end-user installs your module.
Pete Sergeant (sheriff on IRC) suggests using an environment variable for doing this:
plan skip_all => 'set DEVELOPER_TESTS to enable these tests' unless $ENV{DEVELOPER_TESTS};
Claes suggested:
eval "use Test::Something::VeryDetailed"; plan skip_all => "..." if $@;
So I would probably merge the two.
if ($ENV{DEVELOPER_TESTS}) {
eval "use Test::Pod::Coverage";
plan skip_all => "..." if $@;
} else {
plan skip_all => 'set DEVELOPER_TESTS to enable these tests'
}
This way you could save having to include all the developer testing modules in the Makefile.PL.
So, I'm casting my eye around jobs.perl at the moment to see if there's anything good going in London at the moment. Is there anything out there I should particularly avoid? (Yes, I know about jobs-discuss, but since I subbed to it a week ago I haven't seen any traffic.)
That said, if anybody's looking for a hacker, I'm available... happiest when the job spec is writing fresh Perl rather than maintaining a heap of soul-sucking legacy code. Also, preferably it would involve sane version control policy, code standards, and copious amounts of unit tests. (I like tests.) And if it were some kind of Web 2.0* company, that would be even better.
* Yeccch! But you know what I mean. Interesting Web applications that involve people.
15:30 < hex> golf suggestions plz: $foo = 1 if ($bar ne 'foonly' || $baz ne 'foonly' || $honk ne 'foonly');
...
15:36 < claes> hex: working on job security?
15:37 < hex> naw, just avoiding a pile of ||s.
15:37 < claes> ah
15:37 < hex> I went for my $foo = 0; foreach ($bar, $baz, $honk) { $foo = 1 if $_ ne 'foonly'; }
15:37 < claes> hex: use Perl6::Junction
15:37 < hex> claes::D
15:38 < mauke> (grep $_ eq 'foonly', $bar, $baz, $honk) == 3 or $foo = 1;
15:38 < avar> my $foo; sub { $_ ne "foonly" && $foo = 1 for @_; 0 }->(@vars);
15:40 < kane[work]> we *so* need an 'in' statement
15:40 < mauke> "$foo $bar $baz" eq "foonly" x 3 or $foo = 1;
15:40 < kane[work]> $foo++ if 'foonly' in ($foo,$bar,$baz);
15:41 < avar> kane[work]: it's in the next release of perl
15:41 < kane[work]> of course it is
15:41 < kane[work]> everything is in perl6:)
15:41 < clintp> And a pony.
15:41 < avar> if ("foonly" ~~ @vars) { $foo = 1 }
15:41 < avar> I mean 5.10
15:41 < kane[work]> ah
15:41 < kane[work]> perl5++
15:41 < clintp> perl5++
15:41 < kane[work]> perl5++ # exists
15:43 < mauke> "@{ +{foonly => 1} }{$foo, $bar, $baz}" eq "1 1 1" or $foo = 1;
TIMTOWTDI: It's a lifestyle choice.
Apparently ~~ is the smart match operator. (Thanks to mauke for bringing it to my attention, and to clintp for the link.) I'm looking forward to 5.10....
Postscript:
17:08 < broquaint> To add to hex's golf conversation because I'm too lazy to post to use.perl: my $foo = 'foonly' !~
/^(?:$bar|$baz|$honk)$/;
"Bill Hilf, a Microsoft technical strategist, said the Zend deal, a multiyear, multiphase partnership, will ensure PHP programs run on past and future versions of Microsoft Web server software."
Is it just me, or is the likelihood of a similar thing happening for Perl extremely unlikely, even though PHP, like Perl, has its roots in the *nix world? Why do you think that is?
#!/usr/bin/perl
use warnings;
use strict;
package Foo;
sub foo {
print "1\n";
}
package Bar;
sub new {
bless {}, shift;
}
sub steal {
my ($self, $call) = @_;
my @segments = split('::', $call);
my $method = pop @segments;
my $class = join '::', @segments;
no strict 'refs';
*{__PACKAGE__ . "::$method"} = *{$class . "::$method"};
$self;
}
package main;
Bar->new->steal("Foo::foo")->foo;
Okay, this is hardly on a par with the Pugs diaries, but then again I'm not a fucking scary genius like Audrey. Bear that in mind, sunshine, alright?
Anyway. After another six or so hours of hacking away on and off I now have a super-basic photo album system working, complete with tags. Although at present if you want to put photos into it you have to do it with SQL. By hand. But it works. Obviously sorting out out a tool for that is the next step.
My to-do list after that:
Talking of SQL, I discovered on the way that SQLite changed binary database formats again in January. Of course, the way I discovered it was an SQLite error message: "unsupported file format(1) at dbdimp.c". This caused me no small confusion, since I'd created the database with a freshly-downloaded sqlite3 binary. I eventually found out via careful Googling that the format had changed and worked out that I needed a newer DBD::SQLite. But honestly, how hard would it have been for the SQLite guy(s[?]) to implement some form of version number parameter in the format? An error saying "This database was created by a newer version of SQLite" would have been much more helpful.
* This is my thrilling code name for the project. "use PhotoThing;" - so elegant, no? (Er, no. - Ed.)
Now I have moved one step further along The Road That Everybody Eventually Follows. I'm writing my own photo management software with tagging, Uncle Tom Cobley and all. Whoopie-doo, boys and girls.
I've been mulling over the way the way it's going to work for an awful long time - a year? I don't know, something like that, so with any luck it will spring from my head full-formed, like Athena. We shall see. I've racked up a couple of hours on it so far and I already have about half of an alpha prototype in fragments. Let the games begin.
Thanks a lot, whoever it was days ago in #perl who tried to come off as knowledgeable by saying "How do you know it's not Perl doing it", when I was asking about SQLite's behavior, because I was right in the first place. Now I've spent all my coding time in something like four days wasting my time trying to force Perl to do something when it was probably already doing it.
So. How on Earth do I get SQLite to behave? Anyone?