David Goldenrecently posted regarding a comment from Leon Timmermans on IRC. Leon highlighted a problem when CPAN authors try to find information about CPAN Testers, and how they can request testers to do (or not do) something with a distribution they've just uploaded.
The page they are looking for is the CPAN Author FAQ on the CPAN Testers Wiki. Although there is plenty of information for authors, the page doesn't appear prominently on search engines when some searches for that kind of information.
As such, David has suggested that people tweet or post about the page, which includes this post ;) In addition, I'm going to look at adding this and potentially other useful pages as quick links on other CPAN Testers family sites. If there are specific pages you think should be mentioned, please let me know and we'll look at how best we can raise their profile too.
In actual usage,
the syntax of Perl's list operators is quite natural.
Descriptions of that syntax, however, tend to be awkward.
The current practice is to describe this syntax in terms of "left precedence"
and "right precedence".
In other words, list operators are said to be chiral.
I have
problems with the Chiral Interpretation of list operators.
The most serious of these: the Chiral Interpretation
does not actually account for the behavior
of expressions that contain list operators.
In this post, I assume you have a working knowledge of one or more
list operators (examples are join and sort).
The most authoritative account of the Chiral Interpretation
is in
the perlop man
page.
Module::Build is a popular module to complain about. Much of it is either whining or completely outdated (sometimes both). I use it in most of my modules and so far it is my preferred module builder, this is not merely a rant on something I don't want to use.
The vast majority of modules, probably something like 95%, don't need anything special. They are just some Perl files, maybe with some XS: their build process is entirely standard. That means that for 95% of all modules out there it doesn't really matter what you use, as long as it doesn't break. Module::Build, Module::Install and ExtUtils::MakeMaker all work fine. Boring, but boring is a good thing in a toolchain. Module::Build is a frequently used option, but lets be honest, it hasn't exactly eclipsed ExtUtils::MakeMaker and Module::Install. In fact, the latter seems to be the usual choice among the "cool modules" (Moose, Catalyst, etc ).
I'm sure mjd might take exception to the title of the first book. Larry might be surprised he is the author of the second. The PDL folks might not care about the third.
I haven't looked up the licensing for the various documentation bits that looks to be put in a self-published context through Betascript Publishing and Network Theory LTD. To be fair, Network Theory LTD is donating $1 of the $30 book to The Perl Foundation. Gosh, how nice.
Very weird and not sure but I think rather disturbing.
My long-term plan is to turn the program back into a module that can switch out HTML::TreeBuilder for a different engine with the same query capabilities. Especially WWW::Scripter and WWW::Mechanize::Firefox but also XML::LibXML in HTML-mode are backends that I would like to support.
Ideally, the code lives on as a module that gets used by other modules again. WWW::Mechanize has no convenient scraping support. Web::Scraper has no convenient navigation support and doesn't lend itself to data-driven approaches due to the DSL-config-style it uses. Having a common way to do queries against a DOM tree would be a nice thing if you want to extract data from the interwebz.
I've volunteered to pick up maintenance of the HTML-Format module, which has been lacking love recently (last update 2004).
Initial intention is to do maintenance on it - its currently causing warnings about UNIVERSAL::Can on recent versions of perl and there are a number of RT tickets for it.
I am converting it to use Dist::Zilla for release management (although my CPAN volume does not really justify this, the fact that it manages the bits I would otherwise forget does!). Source - including imported versions of all the previous tar files I could find on backpan, is now in git on github.
A trial release has gone out, although I intend to further work before pushing out the next proper release - specifically improving the documentation and tests.
Over the weekend I released Dancer::Plugin::Database 1.10, incorporating a couple of bug fixes thanks to Christian Sanchez, Michael Stiller and crayon.
I've also added a quick_select feature; it seemed odd to not have it since quick_insert, quick_update and quick_delete were all provided.
It lets you do simple queries very quickly:
# In scalar context, returns first matching row as a hashref:
my $user = database->quick_select('users', { id => $user_id });
return "Hello there, " . $user->{first_name};
# In list context, returns all matching rows as hashrefs:
my @users = database->quick_select('users', { category => 'admin' });
It's intended for simple queries, so if you need to retrieve only certain columns, sort results, do joins etc; since the database keyword gives you a normal DBI handle, you can just do it however you like. For simple queries, you might enjoy the simplicity, though.
The Perl booth, maintained by Ann Barcomb, El-Che, Gabor, Liz and Wendy, did exceptionally well! More than 20 copies of the Modern Perl book were sold, all copies of Perl Moderne (an original french Modern Perl book, written by Sébastien Aperghis-Tramoni, Philippe "BooK" Bruhat, Jérôme Quelin and Dancer core developer Damien "dams" Krotkine) were sold, over 300 tuits were distributed, and plenty of information flyers. This took a lot of work and dedication by those that maintained the booth.
It is a good example of why it is important to come to these meetings. An average room has between 70-200 people. That's a lot for a single room! The booth saw, met and spoke to roughly 800 people!! When have you ever seen such high numbers? An amazing effort that was able to market (or "spread", or "discuss", or "outreach", or "promote", or "inform", or whichever expression you prefer to use) and showcase Perl to people.
I hope to attend many more conferences, and I do intend to attend the next FOSDEM.
And well done to all those who helped out in the booth! You did one hell of a job!!
I'm at work right now, waiting for some code to run in the Perl Debugger and I got to thinking. Right now I've set a break point and I've hit "c" for continue executing, and in the background the debugger is doing all these checks on every single line and slowing down the execution of my program like crazy. I know it's doing something because if I hit ^C is halts properly at its current point of execution. What if there were some way to speed this up?
I'm thinking...
DB > b $condition
DB > $DB::breakpoints_only_mode = 1;
DB > c
Setting $DB::breakpoints_only_mode essentially promises the debugger that you won't hit ^C or anything silly like that. The implementation would be something like...
Set up a hook of some kind for all existing breakpoints, which turns debugger flags on, then checks the breakpoint, then turns debugger flags back off again.
Turn off the debugger flag(s?)
Continue running the code as normal
What do Smarter People Than Me think of this idea?
(of course it's entirely possible that the debugger isn't actually slowing down my code all that much... but it feels like it is?)
Over the weekend I threw together Dancer::Plugin::SMS, which uses Adam Kennedy's SMS::Send to easily send SMS messages.
Using it from an app can be as easy as:
sms $destination, $message
# or with named params:
sms(to => $destination, message => $message);
Configuration for which SMS::Send driver to use, login details etc are all read from your Dancer app's config, so if you decide to change provider, you need only update your content, and you're done. There are SMS::Send drivers for a whole host of online SMS text messaging providers so you'll likely find one for whatever service you plan to use; if not, writing one is pretty trivial. There's even ones for using a phone connected to your machine, if that's what you plan to do.
Some time ago I wrote Test-YAML-Meta. At the time the name was given as a compliment to Test-YAML-Valid, which validates YAML files in terms of the formatting, rather than the data. Test-YAML-Meta took that a step further and validated the content data for META.yml files included with CPAN distributions against the evolving CPAN META Specification.
I've been working with ElasticSearch over the past months as part of the MetaCPAN project. Using ElasticSearch as our back end has worked out really well so far. The reason is that, out of the box, it provides a REST API. So, in our case, we've been able to concentrate on writing code and not on designing an API, defining its behaviour, arguing over URL schemes etc.
To be clear, ES is not written in Perl, but there is a handy Perl module you can use to get yourself up and running in *minutes*.
On February 5th, my wife and I celebrated the birth of our lovely daughter, Lilly-Rose.
Needless to say, this has impacted my posting here :)
At one point before the birth when we were both rather bored, I was trying to get some work done, but I had some code which I could not load because I lacked an Internet connection. Not all modules were present on my system, config files were missing, etc. However, I desperately needed to unit test my code and I quickly got fed up with my standard bag of tricks for forcing modules to load. Thus, I wrote a module to handle that bag of tricks for me. Later, after releasing it to github, I thought about dedicating it to my wife and newborn daughter, but I didn't think they'd like the Package Butcher dedicated to them.
Today, I moved the development place of one of my incredibly simple yet incredibly useful data munging tools from http://perlmonks.org/?node_id=598718 to Github . I hope that by moving it there, it becomes easier for people to submit patches.
I haven't given much thought about putting the program onto CPAN as well. The packaging is already done, but I'm not sure if I want to split out the meat of the program into a module, or maintain two versions, a module-using version and the stand-alone version that I currently have. App::Ack did maintain a monolithic version for a while, but I'm not sure whether it's worth the effort. There also is a version of this file that reads and produces Excel files, thanks to Spreadsheet::WriteExcel and Spreadsheet::ParseExcel. I haven't decided on whether to import that version into this tree, a different branch or what else to do with it.
I have an issue somewhat related to Steven Haryanto's concern about bloated apps. I can live with a command taking a second longer to run when performing work, but I absolutely detest waiting that long for the usage message to be generated. I am constantly running commands without arguments (eg Git) to get an overview of sub-commands and/or their options. A slow Perl command line app (eg dzil) is a pain in comparison. It is sometimes quicker to load the manpage.
But it doesn't necessarily have to be that way. App::Dispatcher is a tool for constructing command line applications
written in Perl. It is specifically designed to handle applications
with multiple sub-commands and will generate code to display usage
text, validate options and arguments, and dispatch commands. Its main
strength is that the usage and validation does not load any
command classes with their possibly heavy startup dependencies.
On the 1st January 2011, I released the first Open Source version of Labyrinth, both to CPAN and GitHub. In additon I also released several plugins and a demo site to highlight some of the basic functionality of the system.
Labyrinth has been in the making since December 2002, although the true beginnings are from about mid-2001. The codebase has evolved over the years as I've developed more and more websites, and got a better understanding exactly what I would want from a Website Management System. Labyrinth had the intention of being a website in a box, and although it's not quite there yet, hopefully once I've released all the plugin code I can put a proper installation tool in place.
It seems to me that the folks who say that aren't programmers. If they are, they've never been the sole responsible party for any application. When there's no one to pass the blame to, TDD is no longer just an idea, it's time & money.
Once you get the hang of it, the peace of knowing that your code works has a value beyond measurement.
It's for this reason Mojolicious makes it easy to test your web apps in a clean, simple manner.
Now that's easy. But there's more.
Test::Mojo tests are chainable, so you can keep your tests in a clean group:
Now that's pretty. But wait, there's more.
Using Mojolicious' built in JSON parser, you can test JSON output using an equivalent decoded Perl structure:
On a side note, Mojo::JSON is the fastest pure-perl JSON parser available. Thanks to chansen, it recently became even faster, outperforming JSON::PP by 3x.
There is one very advanced feature in Tempate::Toolkit called META variables. META variables are variables that you define in a processed template, that are later available to the WRAPPER template. That means that you can set, for example, the title of the page in the main layout from the inner content template. That's also what it's usually useful for.
However, since Dancer provides its own "layout" option, it basically separates these two processes (rendering a WRAPPER and rendering an inner template), making Template::Toolkit unable to simply define a WRAPPER. So... how does one get it to work?
Well, it's possible to kindly ask Dancer to step aside for a bit, and give you more control over the templating, which means you can do some more advanced stuff, like using SET to set variables in the WRAPPER, or using META variables. Here's how easy it is:
