On Saturday I wrote about naming your distribution, and how that should be based on your (lead) module name. ETHER pointed out that if your module is sub-optimally named, then you should also consider renaming your module (and thus probably the distribution) on CPAN Day.
I thought it would be helpful to expand on that, and give some pointers to resources that might help you with naming.
Regularly, CPAN authors are reminded that CPAN is a large collection of files, mirrored all over the world, and that it would be nice to keep its size reasonable.
Over the last twelve years, we've seen regular calls to remove old versions of distributions from CPAN. Because I'm too lazy to look for more, I'll point to the earliest and the most recent I could find.
My topic for today is not just removing old releases, but actually removing all the versions of a published distribution from CPAN (thus making it disappear entirely, except from BackPAN).
Here are some good reasons to do this:
Having lost interest or not being able to maintain the code any more are not valid reasons to remove a distribution from CPAN, but they are good reasons to make ADOPTME a maintainer.
So, if you've got an old distribution that doesn't belong on CPAN any more, maybe you could consider removing it on CPAN Day?
You can get the latest dev release from your closest CPAN mirror, or manually from MetaCPAN:
https://metacpan.org/release/MITHALDU/PPI-1.217_01
After Adam Kennedy made his last release of PPI in February 2011 with 1.215, the contributions of Revision: Tom Wyant, Olivier Mengué, David Steinbrunner, Matthew Horsfall (alh), massive amounts of work by Mike O'Regan, more help and most importantly the blessing of Adam Kennedy, moral and substantial support by Matt Trout, and some work by myself, the first release candidate of PPI in 3.5 years is now on CPAN, soon to be a real release.
The change log has a detailed listing and the git repository is even more detailed (it even has tags if you clone it). That said, the summary of the changes is:
[ I have been sending these grant reports to the perl-qa mailing list, whence they have found their way to news.perlfoundation.org. It was quite rightly suggested that it was appropriate to post them here too and so, somewhat belatedly, I am doing just that. ]
In accordance with the terms of my grant from TPF this is the monthly
report for my work on improving Devel::Cover covering May and June 2014.
Actually, it's really only for May. I did some work on Devel::Cover in June,
but I am not charging that to the grant, so the month referred to here is May.
This month I released versions 1.14 and 1.15.
Perls 5.20.0 and 5.21.0 were released this month and, thanks in no small part to
work by Matthew Horsfall, they are both fully supported by Devel::Cover.
A while ago I've registered perlpolls.com and perlsurveys.com but in the end I have not done anything with them. They are about to expire and I don't intend to renew them. If any of you is interested in these domains, please let me know and I can pass the ownership.
When you release your module to CPAN, you should make sure that the distribution has the right name. Doing so makes it more likely that all the different tools and systems in the CPAN ecosystem can process your distribution. I'll outline what I mean by that, and how you can get it right. If one or more of your distributions doesn't follow the conventions, maybe you could release a fix on CPAN day?
Quite a while I got interested in the idea of short, clear examples showing Perl as glue for CPAN. I recently refound these, and they caught my imagination:
Sorry, my understanding of role is not enough.
I add some topic to the following entry.
mop problem 5 - Role and C3 searching is not always necessary
Welcome to Planet Moose, a brief write up on what's been happening in the world of Moose in the past month, for the benefit of those of you who don't have their eyes permanently glued to the #moose IRC channel, or the MetaCPAN recent uploads page.
If you'd like to contribute some news for next month's issue, you can do so on the wiki.
Moose 2.1210 has been released containing some updates to the test suite, and documentation improvements.
Here are some details on our keynote speakers, who will close off each day of the conference in the main auditorium. Rather than technical talks on a specific part of Perl technology, these keynotes deal with major themes in Perl and the art of programming. We're delighted to present three of the major figures of Perl in Europe at YAPC::EU::2014.
This isn't a talk about Perl; it's a talk about how we're changing the world and how the world is sitting up and noticing.
Ovid will cover the gamut of human civilisation from hunter/gatherer tribes to Valve software in a fascinating call to arms about hierarchies and innovation.
"What shall we do tonight, mst?"
"Same thing we do every night: Try to conquer the world"
Your yearly breakneck survey of the Perl community, language and culture. Heartwarming, earthy, loud.
This is the joy in what we do
Sawyer presents a journey through consciousness and reality itself via puzzles, the craft of programming, and flathunting. Unmissable.
CPANTS bills itself as a "testing service for CPAN distributions". It calculates a kwalitee score for all distributions. It doesn't test the quality of your code, but instead evaluates whether your distribution follows various conventions.
Being 'CPANTS clean' means that your distribution is more likely to behave well with the CPAN toolchain, the ecosystem of CPAN-related services, and ad-hoc tools that various people write.
If you haven't thought of something to release on CPAN Day (Sat August 16th), have a look at your CPANTS author's page.
I don't like that mop user tend to look down the user of current perl Object system.
Moose is great! Current Perl object system is not good!
No, No, No.
Current Perl object system is good. There are no lack to do Object Oriented program. Any program can be created by single inheritance and delegation.
At first, I hope improvement of current Perl OO system. Why from now we should write the following code? At first, I hope simple syntax of the following code before mop release.
This is a slightly expanded version of a comment I posted a couple of days ago on NEILB's blog.
Neil was mostly talking about private functions, while I'll be talking mostly about private methods (i.e. object-oriented programming), but I think there's probably a good deal of overlap between the two concepts.
The traditional way of indicating a method is private is to name it with a leading underscore:
sub _secret_sauce { my $self = shift; ...; } $self->_secret_sauce(@args);
The assumption is even baked into the Perl development and testing toolchain in a few places. For example Pod::Coverage won't complain about missing documentation for a sub if that sub happens to be named with a leading underscore.
I used to think the underscore convention was good enough. But partly because of this upcoming project and partly because of problems I've encountered working on various codebases, I've been forced to re-evaluate my thinking, and have come to the conclusion that the underscore convention is insufficient.
I’ve tried and failed so many times to use perlbrew on OSX.
I’ll admit that I haven’t started a full-on investigation, but this is really quite frustrating and confusing:
Well this is a bit embarrassing. My script to tell me the date of the first CPAN/PAUSE upload told me the 16th August, but somehow when writing the first post about it, I changed the date to the 14th. Doh.
The good news is that 16th August is a Saturday this year, which gives us all a better chance at uploading a release or two. And two more days to prepare.
I've updated the previous posts, and regenerated the charts.
Today, thanks to the countless CPAN smokers of BinGOs (aka Chris Williams) I got the first test reports that indicate the same problem exists on OpenBSD and NetBSD as well. (Surprisingly, there are no reports at all on FreeBSD and OSX!)
As I don't have any knowledge of BSDs and this IO::Pty stuff, I wonder if there is anyone out there with such expertise? Could you look into this issue?
Birds of a feather... flock together.
YAPC::EU is a great place to meet face to face with others in the community that share your interests, even non-Perl ones. To make it easier for you organise these informal gatherings - known as BoFs - we have created a page on the wiki.
Fancy getting together to watch the premier of the new season of Dr Who, going for a run, or discussing the future of Act (A Conference Toolkit? Then sign-up now!
If none of the current BoFs interest you then please feel free to make your own suggestions for a meet-up on the wiki and help us make the conference even better.
Knock Knock. Race::Condition. Who’s there?
Race conditions are a fact of life. What can we do when one knocks upon our door?
Often we mark race conditions that are not immediately solvable with a comment:
if (!-l $config && -f _ && -r _) {
# RACE! config file could go away, change type, or become unreadable between file test and file read
open my $fh, '<', $config …
…
That is good so that future us can be easily reminded of the issue. It is really hard/impossible to debug or test the various possible race conditions though.
Race::Condition gives us a way to still mark the race condition but also adds in the ability to hook into it for debugging or testing purposes.
The SEE ALSO section in your module's pod is where you direct the reader to other things of interest. In this post I'll briefly outline what constitutes a good SEE ALSO, and why it benefits you to create one.
My thoughts on this topic have evolved over time, and in writing this I've realised that a lot of my modules could do with a brush up. I'll be releasing those on CPAN Day, of course :-)
Once in a while, I search the web for Perl/Tk. I'm always happy to find some old jewels. This time, it was keen little rabbit ears, which is a simple ear training program for Linux and Windows. It has a Perl/Tk GUI and comes with good installation instructions.
You can find it here: Keen little rabbit ears.
I downloaded the script, got the dependencies (it relies on timidity to play MIDI files) and tried it out. Then I did some changes, like use FindBin to locate files relatively to the script in the file system, use File::Spec to build paths, and use File::Temp to create the temporary MIDI file for timidity in a proper place.
But, then I wanted to share the code with Matthias Nutt, the original author. He has a web site: matthias-nutt.no-limit.de. But the feedback form is dead (have a look at the anti-spam picture).
So, does anybody know Matthias Nutt? Or: does anybody know how to handle this kind of code? Can I set up a git repo with the new code without risking expensive lawsuits?
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
