I tried using this today and noticed another detail: The subtest name is printed *after* the sub-test output. I expected that it would be printed *before* the output, as it appears in the test.
I don't know if this change is possible with the TAP structure or not.
This was a useful example, Ovid.
I agree being able to skip declaring a plan inside of a subtest would be a nice feature.
My idea for a solution for CPAN to automate distributing the full stack of dependencies of modules. So in addition to a "download" link for a module, there would be a "download with all dependencies" option.
Some related pieces:
- Authors should be stricter about which versions of modules they require, and favor the practice of depending on versions they have tested against rather than defaulting to "whatever the newest version of the depending is"... which may not even be released yet!
- For modules that provide Pure Perl and XS alternatives, there should be a standard way for automated tools to build the Pure Perl version.
- Like Ubuntu or Debian, we could make use of a "build farm" that would compile the XS bits on various platforms.
In your case, it would mean that when selected an old version of Moose, you would have the option to download the old version with all dependencies that the old version depended on, instead of getting the old version...and then getting all the newest dependencies.
It's my dream.
If someone makes a case that CGI::Explorer would be a good replacement for some they do internally now, I think it would be considered.
I've been happy using (perl-based) Movable Type on a shared hosting account. Using a perl-based blogging platform is one more way to support the community. (And there is talk in the MT community of refactoring it to use CGI::Application and other CPAN modules).
It runs multiple blogs out of the box, so you can easily run your technical blog and personal blog in one place, as I do:
My "Perl" category is subscribed to by PerlSphere.
I also prefer the philosophy of a decentralized grassroots network of blogs, rather than giving centralized control to some third-party organization.
Great tips! Thanks. I'm getting sold on roles-centric programming.
It would be great to have a index page somewhere of all your posts about roles.
There's a bug here that I didn't spot until I tried to run it:
my $DIR => 'lib/';
I think you mean "=" there, not =>
darcs managed the complications of this workflow very elegantly. We actually only created one feature branch off of the trunk. They we created one ticket tracking number for each launch.
To launch phase one, a developer took a local co py of the feature branch, removed all the patches that were for the second phase, by referencing the phase2 ticket number (darcs oblit -p phase2), and then pushed the result to the trunk. Of course, there were some details and edge cases, but overall darcs handled everything rather well.
Joining several others, I'm moving my Perl blogging off of use.perl.org. My personal Perl blog posts will be here.
I sometimes write about Perl on my company blog here.
On my own site, I'll be able to see my own traffic stats, control the SEO, and provide a unique design. I think having a plurality of blogs promoting and discussing Perl is a good thing.
The trash can concept is such a useful idea, adopted by all the major desktop operating systems.
It perhaps says something about geek culture that it is not yet built into major command line interfaces. I wish it was.