People should write (more) books on CPAN instead. Here are some ideas.
1) The best of CPAN. A curated list of modules, picked by the editor. I would prefer a task-oriented organization. Every mention of modules should also at least mentions its maintenance status (is it actively maintained? is the author responsive? bug queue? are bugs getting fixed?), performance characteristics, strong points, drawbacks, interface. Tasks doable by Perl's builtins and core modules can be mentioned too, although the editor should not dwell too much on those.
2) Creating and maintaining your own CPAN. minicpan, Pinto, carton?, ... Potential reader base include Perl shops and corporate users.
3) Definitive guide to Acme::. Fun things, stories behind the modules, (mostly) useless tricks employed by the modules. I want to a fun, entertaining, light read. Should be 100 pages or less. In the age of ebooks, could perhaps sell for $5-$10? I'd buy it.
4) The worst of CPAN :) A bit like #3 in spirit, but more "coding horror" style.
Deven Corzine is revitalizing the Advanced Perl Users group on LinkedIn, and I've volunteered to help. We're going through all of the join requests to approve everything we can, delete the obvious spam and HR requests, and figure out what to do with the rest.
But, besides clearing out the backlog, I want to quadruple the number of members in the group by the end of summer (which is sooner than Christmas). We have 250 members right now. I want that to be 1,000.
LinkedIn is essentially a trust network that relies on connections and recommendations for other people to get a quick read on strangers. That's amplified with controlled groups, such as Advanced Perl Users group on LinkedIn, which is set up so "new members will only be approved if an existing member is willing to personally vouch for the new member". Deven's intent is to have a group of serious Perl programmers who we'd want to hire ourselves.
I’ve been writing tests for a web service in which one of the methods would occasionally take an inordinate amount of time. The amount of time was inconsistent and it would be useful to capture some timing data to provide the vendor. But, I didn’t want to litter my test files with code to calculate the elapsed time. Eventually, the bugs would be worked out and the timing information would just be noise.
So I wanted to somehow hook into the test framework itself to give me the timing data.
I am happy to announce that Galileo CMS is now available from CPAN! This project has been my on-train side-project, but its come a long way in a short time. The most exciting thing for me is that its entirely installable from CPAN. To try it out, simply do
$ cpanm Galileo
$ galileo setup
$ galileo daemon
of course, you can also run it using the servers provided by Mojolicious, or using your favorite psgi-compliant server (as long as they support websockets).
Authorized users edit pages using markdown with a live-preview. All updates to pages, menus and users are sent via websockets. Styling is courtesy of Twitter’s Bootstrap library.
Is including Changes information in main module's POD a good idea?
You bet. Typing "man Foo" or "perldoc Foo" beats having to go to search.cpan.org or metacpan.org and search for Foo and click some more. Or having to download the distribution, extract the tarball, and viewing the Changes file.
Well, actually, it's a good idea as long as module authors don't have to do it manually.
UPDATE 2012-09-07: I changed my mind :) After creating an alias chg to a command that views Changes in my local repositories, and chgr to cpan-listchanges, I no longer find Changes in the POD appealing. So all I needed was an easy access to Changes.
The first issue of the Perl Weekly was sent out on 1st August 2011. Almost a year ago.
In case you don't know what it is: It is a weekly e-mail with a curated collection of links to the most intersting, Perl-related articles of the previous week. As seen by myself.
I wrote about it several times on this forum, but I think this might be a good opportunity to mention it again. There was also a suggestion that people should brag about the stuff they build. I totally agree.
If you are already a subscriber, let me thank you for your support!
If you are not yet a subscriber, let me invite you to check out the web site, the archive and to subscribe to the Perl weekly newsletter.
Not always. In user-facing applications, where the list of installed and enabled plugins is clear, then plugins are often a good thing. This article is concerned not with end-user facing applications, but with libraries. Libraries that allow their functionality to be extended through plugins. In particular, libraries that automatically detect and load all installed plugins.
Plugins aren't always obviously plugins. In this article, I'm defining a plugin as a software module that adds additional functionality or modifies the externally observable behaviour of the existing functionality of the core piece of software. Call it a "plugin" or an "optional dependency" - it's the same thing.
Just an FYI, if you're using Business::Shipping in your app and also Log4perl, then Business::Shipping will clobber your Log4Perl config with it's own. A quick work around for this is:
use Business::Shipping;
Log::Log4perl->init($your_own_config_file_path_goes_here);
Basically clobber Business::Shipping right back.
If I get some round-tuits I'll submit a patch to fix this problem. If the author of Business::Shipping were using something like Log::Any then he could spew out his logs, and the consumers of Business::Shipping could simply load the appropriate adapter rather than having Business::Shipping clobber the Log4perl global config. I guess technically this could be a bug in Log4perl using globals too. Anyway, this little work around should get you by in the mean time until a patch can be authored to remedy the problem.
I just uploaded to Crypt-SSLeay 0.60 to PAUSE to address RT #77167 and CPAN testers failures with the previously released version. The former was due to the fact that SSL v2 is no longer supported on various platforms, and the latter due to the fact that LWP::Protocol::https was not specified as a dependency.
Most of the changes leading up to 0.59_03 were similarly minor and straightforward. However, one addressing RT #64054 attempted to deal with incomplete reads and writes in a better way, and is a significant change from the original codebase.
A grand tradition of the YAPC::Europe are the Lightning Talks, 5 minute presentations
about any topic. We plan three sessions of Lightning Talks, one every day.
Léon Brocard has graciously agreed to host the Lightning Talks.
I dislike the interface because it forces me to remember/decide/do too many things. I don't want to have to remember whether to use timethis()/timethese(). I don't want to have to pick the appropriate $count. I don't want to have to label the subs. With Bench I can just type:
% perl -MBench -e'bench sub { code }'
% perl -MBench -e'bench [sub { code1 }, sub { code2 }]'
Guess what, I got tired of having to type the above too :-) So now with the latest release of Bench, a command-line script bench is provided. You can now just type:
While testing some code for an forum answer i made a stupid mistake. It was late, I didn't thought of it, why in the world should I name the Module "Test" and wonder then why it behaves unexpected (I do know why! - some newb might not). But the more glorious idea is that we all have such moments and hide them carefully. Why not pile the xp up and make a Perl course out of it by showing what can go wrong and maybe even write it like a comedy? I saw even a motion picture in my mind about someone ranting how bad Perl is while making such moves.
Tuts are hard work, I know because i wrote some. To set up all the traps that a screwball comedy comes out of it that actually works dramaturgically should be even harder. But maybe someone runs with the idea.
I just tried to install GD from CPAN. It complained that gdlib-config is missing and that I should install libgd.
After some search I found out that in Ubuntu gdlib-config is provided by libgd2-xpm-dev and not by libgd.
So I am sending a patch to Lincol Stein to have a better error message, but it would be nice if I could included the names of the correct packages from other Linux distributions.
Hence the question.
What package provides gdlib-config in your distribution?
Just because you're coming to a conference doesn't mean your loved ones must stay back home. And if they do come with you, the fact that you're at the conference doesn't mean they have to stay at the hotel.
We've put together some activities in and around Frankfurt
on the wiki
Perlybook.org is now available in version 0.13.
Continue enjoying all the Docs from CPAN in your Ebook-Reader of choice.
This fixes a bug, concerning some input like e.g. Log::Log4perl.
Because MetaCPAN's autocompletion was used to match user-input to something valid, you always got an ebook about Tie::Log4perl (which is autocomplete-suggestion number one in this case) - so this is fixed now and you will get the book you want.
The downside of this is that the input allows no more typos and is case sensitive too! But that's not a big issue if you use a browser with JS enabled... JQuery will fill up the form correctly with a bit of your help.
Secondly a minor bug is fixed so that you should be able to download your ebook of choice directly from you Kindle Reader if you have some WLAN around. I would like to hear some feedback about this on github or as comments here in the blog. Because on my Kindle Reader (there is no model name written on this thing, I don't even know which model it is) I can now download (which I couldn't before) but - very strange - I can't open the book... would like to hear if others have the same issue.
Unlike trash-cli (and like rmv), trash-u supports undo (called rollback in rmv). And unlike rmv, trash-u supports redo. Multiple undo/redo is supported. It's also worth noting that rmv currently does not support per-filesystem trash (everything goes to $HOME, which might cause heavy copying between devices).
To undo your last action:
% trash-u --undo
And to redo:
% trash-u --redo
To see your actions history:
% trash-u --history
To discard history (forget undo/redo information):
% trash-u --clear-history
trash-u also supports dry-run mode to show what's going to be deleted:
