One of my long-term ideas is to make my laptop more location aware and to have something like cron except for locations instead of time. It will be useful to automatically reconfigure my network and proxy settings in Firefox and Thunderbird and to prevent information leakage. Also, my laptop can automatically synchronize its minicpan and git repositories with the mothership when it detects that a "fast" or "local" network connection is available.
As I'm not really interested (yet) in the physical location, it is enough for the laptop to know what wireless networks are visible to determine how it should behave. Later (or once GPS sensors become commonplace in laptops, or Perl becomes commonplace on GPS-enabled devices), adding GPS detection etc. will also become interesting.
Caching is a tricky business. Having just one kind of cache won't work, because the production environment will greatly determine the most efficient caching system. A distributed production environment would be best-served with a distributed cache. A smaller, single-server environment could use a simple shared memory cache.
Enter Jonathan Swartz's CHI module, the greatest Perl module to provide a
unified caching interface. CHI is the DBI of caching: It presents an API, and
delegates to CHI::Driver modules to perform the heavy lifting. It
provides a layered caching system, allowing you to have a faster, more
volatile cache in front of a slower, more persistent cache. It also provides a
variable expiration time, preventing a "miss stampede" where all processes try
to recompute an expired cache item at the same time.
By integrating CHI cache into WebGUI, we have the ability to provide any
caching strategy that CHI can provide. We get Memcached, FastMmap, and DBI
drivers (and more drivers can be written).
I'll work through the other issues as I get the opportunity - but the incompatibility with current perl versions was the reason I took on maintenance, so I wanted to get a release with that fixed out quickly.
It is interesting to see which are the popular downloads and as an author the number of downloads of your own modules. They also have a nice chart of which OS's the module has been built for.
Not so sure that the example in the article - DBD::Mysql Failing on OSX - is such a good showcase! (looking at the report just seemed that mysql_config wasn't in the build servers path or something, so a setup issue, not a module issue).
But that aside it's interesting to see how far PPM seems to have come.
In a small script someone wrote at work I saw the indirect pattern of new Object, instead of the more correct form of Object->new. When I inquired (okay, I said "WTF?!"), he said that he just copied the synopsis of a module. Oh, right.. some of the synopses (plural of "synopsis", bet you didn't know that!) still have some outdated syntax examples.
I'm not gonna write about how we should all update our PODs to remove syntax that hasn't been (or shouldn't have been, at least) written for the last 10 years, even though I should! I wrote to talk about the reply my co-worker got when he opened a ticket asking for the synopsis to be updated, per my suggestion.
He got the reply "what is this, the syntax police?" Perhaps half-jokingly, but still problematic, IMHO.
Police? No. Neighbors, family members and friends? Yes!
I struggled with a problem where a given method would return an array of array refs of data, but the order (and sometimes presence) of array ref elements were sometimes slightly different. This is because this code needed to test real data and I could not mock the results. After giving this some thought, I realized I wanted something like the Levenshtein edit distance for data structures. Marcel Grünauer suggested that each element get assgined a unicode character. This solves my problem nicely with the following code ...
I saw a very ugly Perl code, and I think that is possible because no code review exist in project. But always we have a very little time for human code review. I search CPAN modules for basic level code review by machine. I hope that these modules help Perl people to avoid writing ugly code and help team leaders minimize time to code review.
I try to collect founded modules in github repository and now want to describe what we know if all these test passed:
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)?
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 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!!
