blogs.perl.org

Any other puppet using perl developers out there frustrated by the lack of a native cpanm provider for package resources in puppet?

I just ordered "Puppet Types and Providers". Should be here in two weeks. I'm thinking it would be nice to contribute back a new provider to the puppet code base to serve our needs as perl developers and as sysadmins who have to manage perl code bases.

I just created a project work space for such work at:
https://github.com/hesco/cpanm-puppet-provider

I'll try later today to outline my thoughts on the user interface and the features I imagine this puppet provider making available in the README in that repo.

I would love to collaborate with others on such a project. If interested, please clone the repo and send me your pull requests, drop me a line at: hesco@campaignfoundations.com or call me at x21 at the phone number published in the footer of that domain.

Thanks.
-- Hugh

Neil Bowers released a survey of markdown to HTML formatters recently. I thought it was an interesting coincidence, because I have recently written a CPAN library to go the opposite way, from HTML to Markdown.

For various and sundry reasons I wanted to move my blog from a Wordpress installation to a static blog where the post content is represented as markdown, but there were (to my complete astonishment) no CPAN modules to convert HTML to markdown, so I decided to write one based on HTML::Format.

In general, I was surprised by the lack of tools (in any language) to convert Wordpress exports into markdown, but now we have something for Perl. I was pleasantly surprised how quick and straightforward it was to implement the converter. If you have a need to convert HTML into format X, give HTML::Format some serious consideration as the base platform to do that work.

Recently Dominus posted a lovely horror story from his programming past and I couldn't help but think about my time as a mainframe programmer and the team lead who hated me. She once got upset at another developer for increasing the space allocation for jobs. Why was the other developer increasing that allocation? Because our nightly batch jobs were running out of space and we'd get woken up with calls telling us the jobs were failing and we'd tell them to increase the disk space and restart the job. The team lead was upset because if the operators didn't have to call us, "why would they need us?".

However, I was the person who really upset her and I never quite figured out why. I was told it was because, unlike her, I could actually program (allegedly she was an operator who simply rose through the trenches), but I don't know this for certain. All I know is that she did not like me and one day she managed to exact her revenge against me for whatever I had done to offend her.

I think there are two advantages in encapsulation.

Separation of implementation and API interfece

Advantage of encapsulation is that if you change the implementation,
you don't need to change api interface.

For example, see the following code. This is Mojo::Path source code.

Now that MarpaX::Languages::ECMA::AST is on the road, I can start effectively my exciting project: Jperl, i.e. JavaScript engine writen in perl thanks to the only but so great BNF parser: Marpa.

I've now uploaded the survey results for YAPC::Europe 2013 and The Pittsburgh Perl Workshop 2013. Both had only a third of attendees respond, which for PPW is still 20 out of 54, and 122 out of 333 for YAPC::Europe.

To read the full story, please see my blog entry.

I also sent out the talk evaluations for PPW2013 this morning, so if you presented a talk at Pittsburgh and haven't received an email, please let me know.

I've just published the first full version of my review of CPAN modules for converting markdown to HTML. There's still work in progress, particularly comparing the output generated by the different modules, but it's fairly complete now.

One question I often hear is “Why should I chose Mojolicious versus one of the other major Perl web frameworks?” While I have many answers to that question, I personally believe the most important difference is that Mojolicious is designed to be non-blocking. Many of you will have heard of Node.js. The reason that Node is popular is that it is designed to be non-blocking. By writing your webapp in a non-blocking style using a non-blocking framework, you can often build a faster and smarter application, requiring fewer servers to handle the same amount of traffic. Although Perl has several web frameworks, only one was written with non-blocking design in mind: Mojolicious.

To demonstrate a non-blocking application, I am going to write a simple pastebin using Mojolcious and Mango, a non-blocking MongoDB library (from the same developers as Mojo).

A while back I forked Term::ReadLine::Perl making Term::ReadLine::Perl5 because of the former maintainer's lack of responsiveness regrading my patch to add GNU Readline history and general lack of responsiveness overall.

Term::ReadLine::Perl purports to be a "pure Perl" version of GNU ReadLine. It can use, but does not require, Term::ReadKey. With this issue it seems that more hacking is needed when Term::ReadKey is not available.

Right now Term::ReadKey is recommended. But putting a dependency on Term::ReadKey would simplify the code, and that is much needed. That makes this less code less "pure" Perl.

Looking at the CPAN Testers reports, seems to be pretty much available on different OS's and is somewhat actively maintained.

Any thoughts on turning a "recommends" into a "requires" for Term::ReadLine::Perl5?

This post describes my current practice. Input/suggestions are most welcome to improve the process.

I am presently maintaining about 300 Perl distributions, 90% of which are CPAN distributions. As mentioned on a previous blog post, I am now developing some non-CPAN Perl software projects à la CPAN, by grouping software components as Perl distribution and releasing them like CPAN distributions, although not necessarily to CPAN. That number is expected to shoot up to at least 350-400 in 6-12 months, as more code is converted into Perl distributions. So without some helper scripts and automation, one can quickly go insane.

Does anyone fancy writing a Dist::Zilla plugin that would read a Changes file in YAML and munge it to one in the CPAN::Changes::Spec format?

Etherpad is a really great collaborative editor. Written in Javascript for NodeJS, it offers a HTTP API which allows to do a lot of things.

Despite a lot of other languages API libraries, Perl had no API module for a long time.

This is not an issue anymore since I wrote the Etherpad::API. Now we can use the etherpad API for our greater pleasure.

An use of this module is Etherpad::Admin, a Mojolicious-based web site which displays informations about pads and permits basic operations on them.

For the console lovers (myself included), padconsole is what you need to manage multiple etherpad instances from your terminal ! It's on its early stage, so all functions from the API are not usable right now, but as they say: "Release early, release often".

I will not reinvent the wheel and take the exact definition from the C grammar in its Lex format:

{HP}{H}+{IS}?	 { return I_CONSTANT; }
{NZ}{D}*{IS}?	 { return I_CONSTANT; }
"0"{O}*{IS}?	 { return I_CONSTANT; }
{CP}?"'"([^'\\\n]|{ES})+"'"	 { return I_CONSTANT; }

Over the past couple of years, my practice of developing and releasing software as Perl/CPAN distributions has spread to my other non-CPAN projects. Software are now being composed as collections of Perl distributions, although they are not released to CPAN (but some components are). I am embracing this practice because:

1) It encourages modularity, a desired property in software. Perl modules are logical groupings of code, and Perl distributions are units of deployment/release.

My usual behavior for setting version requirements in dist.ini:

Go through each dep, search for it on CPAN, copy and paste the version number.

I decided that
a) that takes too long
b) That's not the versions I've been testing with.

So I hacked this together: dzil_myversions.pl

Synopsis

$ dzil listdeps | ~/dotfiles/home_bin/dzil_myversions.pl 
aliased = 0.31
Compress::Raw::Zlib = 2.062
Data::Dumper::Concise = 2.020
Encode = 2.54
ExtUtils::MakeMaker = 6.8
File::Spec = 3.40
HTTP::Request::Common = 6.04
IO::Async = 0.61
IO::Async::Loop = 0.61
IO::Async::Process = 0.61
IO::Async::SSL = 0.13

Pitfalls to avoid

I now have over a 100 Distributions on CPAN!

Some days ago I discovered that my CPAN distributions count had already gone above 100, only that my MetaCPAN page has misled me due to a bug ( which I reported since). I now have 103 distributions on CPAN and you can find a list of them on the Israeli Perl Mongers site, with whatever is missing from the MetaCPAN page.

So now I'm in the CPAN 100 club, and now will also better focus on improving the quality of my existing distributions. According to GumbyPAN, the top ten authors are SHARYANTO [265] RJBS [258] TOBYINK [239] ADAMK [236] ZOFFIX [222] MIYAGAWA [216] BINGOS [197] INGY [177] TOKUHIROM [170] SMUELLER [156], so no one has gone up to 300 distributions yet (also see the top 20 current in the leadercpan page.).

Maniac Downloader

While I know I'm in the minority, I use the Perl debugger quite a bit. In fact, I've hacked on perl5db.pl more than I can to admit and it's a mess. However, on a day-to-day basis, I use it constantly and have it bound to ,d in my vim setup. Unfortunately, I also write a lot of Moose code and that's when I invariably hit things like this:

About this posting series: things that should perhaps personal notes, but shamelessly posted. Things that should've been tweets, but are not because they are a tad longer. Things that are useless most of the time.

* Saw a post about mod_mruby for Nginx. Apparently there is also a module to embed Lua, and another one for Perl. After we painfully learned to decouple web application server from webserver (using WSGI, Rack, PSGI), now it's mod_perl time all over again?

* We use code generation a lot these days in Perl. Dist::Zilla and Pod::Weaver (and their alternatives). Mo[ou]* modules. Type::Tiny, and my data validation framework Data::Sah, which is also code-generation-based. DBIx::Class::Schema::Loader. I'm even thinking of generating command-line scripts on the fly since most of my scripts nowadays are just interface to function in a module. And I look forward to the days when we generate the generators. Certainly an improvement over the boilerplate-generation days (think Module::Starter and Rails/Catalyst).

* I notice that my command-line scripts are getting longer and longer names (compared to a few years ago), is this a sign of old age? Or simply because I have more scripts/projects nowadays? I can manage a few or a dozen rainbarf's, but a couple of hundred?

I currently write a commercial app and found out that Wx::RadioButtons work differently under MacOS. These simply ignore the constant &Wx::wxRB_GROUP and slap together all the groups of a dialog. By toying around I found a way how to get several radio buttons (these labeled, round things from only one can be selected) in one dialog (following some style guidelines I guess), just put them on separate Wx::Panel. Than I remembered that Wx::Perl::RadioGroup does this anyway, and using them you also don't have to know about &Wx::wxRB_GROUP. It just works like the mackenzies claim. It will see the light of CPAN as soon I learn to handle dzil.

Since launching the Perl TV more than a week ago there have been quite some changes.

Videos can be now listed by tags, module names, or speaker. (Though it is still not clear how interviews and talks with multiple speakers will be listed.)

Besides YouTube videos, now videos posted on Vimeo can also be added. (For example Parsing JSON with a single Regex)

Videos in any language can be now posted and they will be listed separately in every listing: For example Sawyer X has an English and a Hebrew version of the Asynchronous programming FTW! posted.

There was some improvement in the layout as well. The default Dancer2 template and CSS is slowly replaced by a more responsive web design. (Try resizing the browser.)