I might be working on a project for a friend shortly. They have lots of experience with developers who use Drupal - and I get the feeling (could be wrong) that you can semi-plug-and-play with Drupal?

So..
Want a wiki - use X plugin
Want a user system - use Y plugin
Want user profiles - use Z plugin
Want user gallery - use A plugin
Want a blog - use B plugin

So I started looking around, and there are plugins for specific frameworks, or standalone applications written in a framework, WebGUI CMS seems to have a lot of features but I want to use my framework of choice (and experience!).

Having been playing with Plack it got me thinking...

Just as Plack/PSGI sits between the webserver and your code, could someone (brighter than me!) come up with a standard for sitting between a framework and an app (blog/gallery/wiki/forum etc)?

Now that we've seen how easy Mojo::DOM makes parsing html, let's take a closer look at the css selector goodness it provides.

Here's a fairly verbose html sample for us to work with:

First, we initialize and parse the file:
use File::Slurp 'slurp';
use Mojo::DOM;
my $dom = Mojo::DOM->new->parse(scalar slurp 'some.html');

Getting all the articles' contents, of course, is easy:
$dom->find('li a');

But we can do better than that. Let's say we want only the article titles that have page anchors:
$dom->find('a[href^=#]');

Nah, let's get the article titles that link to external urls:
$dom->find('a[href^=http]');

How about only article titles that link to .net domains?
$dom->find('a[href*=.net/]');

We can also get the page anchors themselves:
$dom->find('div.article a[name]');

It could be that some articles have no text content; let's single those out:
$dom->find('div.article p:empty');

Hi Folks

I /still/ hate having to sign in twice in order to post. Grrrr.

Anyway, see this: http://vis.stanford.edu/protovis/

Examples: http://vis.stanford.edu/protovis/ex/

Slide mouse horizontally over this chart: http://vis.stanford.edu/protovis/ex/index-chart.html

However, let's not develop oodles on incomplete Perl interfaces, p-l-e-a-s-e. After all, we don't want another SVG debacle, do we?

I have my own blog, on which I post about Perl-related stuff along with other things. I also have a blog here on blogs.perl.org (obviously, as I'm posting on it now).

When I post something Perl-related, I'd like to post to both, as blogs.perl.org makes it more likely to be seen by the Perl community, many of whom probably don't follow my own blog, but I don't like the idea of manually posting it to both really. It's also a bit of a pain for any comments to be split between the two.

Solutions that come to mind:

• Automatically copying posts in the Perl category on my own blog to this blog somehow; or a script that posts a summary along with a link to the original post on my blog
• The above but in reverse; post here and have a summary & link posted to my blog
• Not use this blog, and attempt to get the feed for the Perl category on my own blog listed on planet.perl.org, and hope that helps make those posts visible to the Perl community

I can't be the only one who has their own blog but also wants their content on blogs.perl.org for better visibility within the Perl community - anyone have any suggestions?

David Golden recently 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.

Cross-posted from the CPAN Testers Blog

Chiral Operators

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.

Our Example

The rest of this post will use a single example:

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…).

The rest

perl -e 'my (my (my (my (my (my $puerto_rico)))))'

I was purchasing a dead tree copy of Modern Perl on evil Amazon I noticed several "you might also like" books:

Higher-Order Perl

Perl Language Reference Manual - for Perl version 5.12.1

PERL DATA LANGUAGE

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.

Inspired by a demonstration of Mojolicious on the command line , I replicated the relevant functionality as a stand-alone program, tentatively named App::scrape. It's currently based on HTML::TreeBuilder::XPath , the ever-useful HTML::Selector::XPath, and LWP::Simple.

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!!

Hi all,

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?)

Hi all

We get a lot of people who want to use javascript to talk to their ElasticSearch server, directly from the browser.

This poses a problem, as ElasticSearch doesn't offer any authentication, or request filtering.

I'd like to write ElasticSearch::Proxy , which would be configurable to:

• allow restriction on GET/HEAD/POST/PUT/DELETE requests
• parse the incoming JSON request, filter out anything that shouldn't be allowed, and then forward the request on to the ES server
• allow authenticated requests, with different permissions

With the module, I'd like to provide various ready made server configurations, ie you should be able to plug it into mod_perl, dancer, whatever...

I'm only familiar with mod_perl - haven't used any of the other frameworks.

LAZYWEB: What webservers should I target, and are there any existing modules which may be useful to use with the above?

thanks

clint

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.