If you're a module author, and looking for something to release on CPAN Day, have a look at your CPAN Testers results. If you've got any failures, check the test report(s) and see if you could release an update to prevent those in the future.
For the last several months I had some more free time during the long (for me) nights in Central Europe. I didn't have to work any more additionally to cover some expenses. Having done several projects on Mojolicious, looking at the code, I clearly saw same patterns — repeating over and over again — in the code of my projects.
I had also, I would say, successful previous open source project on GitHub (which code had the same "issue" and some more), but I just left it after some time. I think I disappointed some people. Apologies. I left it because it was looking to me too monolithic, too "hard-codded", promising to be hard to maintain, and test...
I wanted something more flexible, implementing the same ideas and functionality, something more, hmm.. professional, easy to start with, well covered with tests, installable via CPAN or manually, imposing good coding practices, extensible, scalable, light on dependencies, enterprisey...
Contradictory requirements, you may say, this would be such an ado.
What happened last month:
The camel was at a Meetup, again, together with some Perl mongers.
(Nobody had asked it to eat the decoration..)
Inspired by PoC||GTFO, herewith is a (pseudo) quine written in Perl that generates a copy of itself as a PDF which is also a mountable ISO with that PDF as the sole file.
Copy the script as quine.pl, run it, and you'll get a quine.pdf which can also be mounted as a filesystem:
bash$ file quine.pdf quine.pdf: # ISO 9660 CD-ROM filesystem data 'CDROM' bash$ sudo mount -o ro quine.pdf /mnt bash$ ls /mnt quine.pdf bash$
quine.pl:
If you're still looking for something to do on CPAN Day (Sat 16th August), you could fix a bug in a CPAN distribution. It might be a bug in one of your own distributions, but it doesn't have to be — you could fix a bug in someone else's distribution. If their dist is on github you could send them a pull request, otherwise attach a patch to the issue in RT.
We are still accepting proposals for Lightning Talks and will continue to do so until a week before the conference. We will be having a Lightning Talk session, which will have about 10 Lightning Talks of 5 minutes, towards the end of each conference day.
It will be possible to submit a Lightning Talk proposal during the conference as at least two speaking spots on days 2 and 3 will be held open until the day before the talks to give you a chance to see something at the conference and put together a Lightning Talk response. As there will be fewer spots available during the conference we recommend that you submit your proposal as soon as you can.
If you would like more information about Lightning Talks please read R Geoffrey Avery's detailed description on the conference website.
In December last year released the first version of Time::Moment. I don't foresee any major changes in Time::Moment 0.16 API, so in next release I'll remove the "early preview release" notice in the description. I have been using 0.16 in production two different deployments with great success, by removing DateTime from the ORM we have seen significantly reduced the memory usage and CPU usage and increased the throughput when inflating timestamps from a RDBM, previously DateTime was a one of our bottleneck in our profiling.
Curtis Poe, one of the top presenters in the world of Perl (and testing and ...) recently posted How Do Conference Speakers Get Compensated? in LinkedIn. There had been a bit of a kerfuffle on the YAPC Europe Conference Organizers mailing list after some mail that would have been better handled in private email.
There's an undercurrent idea in the open source world that money is dirty and paying for services is bad. YAPC started as a reaction to the much higher priced (and much higher produced) The Perl Conference that only met on the west coast of the United States save for a couple of tries in Europe. At the first YAPC, Kevin Lenzo literally passed the hat at the end to make up for the shortfall. Mostly, YAPC still acts like that and waits for a big sponsor to fix it.
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.
blogs.perl.org is a common blogging platform for the Perl community. Written in Perl with a graphic design donated by Six Apart, Ltd.
