The next version of Perl::Critic has been shipped to CPAN and it includes built-in themes tied to the CERT guidelines for secure coding. CERT divides their guidelines into "rules" and "recommendations". You can activate the Perl::Critic policies that CERT suggests like this:
# Apply all "rules"
perlcritic --theme certrule YourCode.pm
# Apply all "recomendations"
perlcritic --theme certrec YourCode.pm
# Apply both
perlcritic --theme 'certrule || certrec' YourCode.pm
These are not new policies -- we've just classified the existing policies that overlap with CERT's guidelines. Perl::Critic does not cover all the CERT guidelines, so I suggest visiting their site to see more ways to improve the security of your code.
Last time, I showed you how to write non-blocking (web) applications using Mojolicious.
In those examples, each action only had to perform one non-blocking action.
In this article I’m going to take things a little further, introducing you to Mojo::IOLoop::Delay.
I will use a delay object to perform multiple simultaneous non-blocking actions and wait until they complete before moving on, all without blocking the server for other requests.
Just wanted to share a new little debugging tool, Devel::Quick.
It allows you to write DB::DB subroutines on the fly, and provides a few variables by default to make things simpler.
Background
DB::DB (the DB subroutine under the DB package) -- if defined when Perl is run under '-d' -- will be executed before every line in the Perl source being run. If the DB::DB call is within a subroutine, you can also peak at the arguments passed into the sub.
Example
A simple example of a module using this is Devel::Trace, which will print out the source code about to be executed for every line.
With Devel::Quick, we can recreate this functionality like so:
Does your Git wrapper support commit messages encoded in latin-1? (encoding header) In Shift-JIS? Actually, any encoding you can think of, given that Git doesn't care.
Do you know about multiline headers? Like in signed commits? (gpgsig header)
These days Perl/CPAN is not king anymore. It no longer has the largest number of modules or the most complete collection in every aspect. But it still compares very favorably overall and is still regarded as one of the repositories that have the best supporting infrastructure/ecosystem (e.g. CPANTesters).
Each post will mention a few modules/applications that exist and live on other language's software repositories like Python's PyPI, RubyGems, or npm, but currently do not have their equivalents on CPAN (at the time of posting, according to my observation).
How to view this negatively
So what? Well, read on.
You have $LANG envy!. So what? :-) Envy is good, I heard it's one of the virtues of programmer (well yeah, hubris is a mispelling). It's nice to be able to have things that others have.
Well, I couldn't resist...had to start with the typical "Hello, world!" This is a blog site about a programming language, is it not?
I am currently a high school student, and computer programming is one of my interest/hobbies. I have a website where I offer Perl tutorials for beginners, and I really like making tutorials. That said, I myself am not a very advanced programmer, by any means...I really don't know much at all. One of the ways that I learn is by taking on programming challenges/tasks, but the issue is, I don't know how effectively I am completing the task. I am sure there are better ways to approach some problems from both logical and technical standpoints. Therefore, I am mostly starting this blog as a place to get feedback from others about the scripts that I write as to what the potential weaknesses/drawbacks might be, and how I can make my scripts (and my programming skills in general) better.
Welcome to Planet Moose, a brief write up on what's been happening in the world of Moose in the past month, for the benefit of those of you who don't have their eyes permanently glued to the #moose IRC channel, or the MetaCPAN recent uploads page.
Thanks for contributions from Damien Krotkine; and thanks to Upasana Shukla for allowing me to interview her. If you'd like to contribute some news for next month's issue, you can do so on the wiki.
Ricardo Signes' App::Cmd has been praised a lot so I gave it a try for my recent command line app. In summary, the module is great although I missed some minor features and documentation (reminder to all: if you miss some feature in a CPAN module, don't create yet another module but try to improve the existing one!). One feature I like a lot is how App::Cmd facilitates writing tests for command line apps. After having written a short wrapper around App::Cmd::Tester my formerly ugly unit tests look very simple and clean. Have a look at this example:
After a lack of hactivity in the previous quarter, I've slowly resumed development work. Sadly I failed to achieve last quarter's target to setup CPANLists and GudangAPI, and instead have been mostly busy getting my workflow more {d,r}efined, for development of CPAN modules as well as other non-CPAN Perl projects. I blogged about that here and here. I made some progress on a tool called riap, which is a command-line shell Riap client and will make debugging/browsing Riap-supporting API services (like CPANLists and GudangAPI will be) easier. This will be released in a few days. I also released App::ListRevDeps to help me see who uses my modules.
I write a metric crap ton of code. It’s pretty much what I do from the time I wake up until the time I go to bed on most days. I do it because I love it, but there’s something that’s always bothered me about code, or rather coders. All too often we try to make code perfect, when what we should really be trying to do is make it work.
We try to keep things loosely coupled, modular, and using the right design patterns. We apply all kinds of best practices, optimizations, and the latest paradigms. In reality though, if we make something that works, there will be time to go back and fix it, because making it work often means making money, which gives you options.
Thinking out loud about creating a real puppet package provider to handle perl modules, led this afternoon to a conversation on #perl-help with ilmari_ who pointed out that the lack of a real package manager for perl will frustrate efforts to wrap that missing functionality in a native puppet provider for its package resources. He called what we have now 'module installation tools' which fail to rise to the level of a real package manager. At a minimum, he suggested a real perl package manager would also require the ability to uninstall a module, as well as the ability to query the system about the modules installed there, perhaps the ability to query upstream about available packages.
This immediately created a threat for scope creep as I now explore what would be required to provide that missing functionality, as prelude to writing a puppet provider which might wrap it.
Acme-oop-ism is about writing code that works in Moose, Mouse and Moo. We've already looked at how Type::Tiny has achieved this. Now I'm going to introduce you to some Acme-oop-ist techniques.
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.
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.
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.
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.
Welcome to Planet Moose, a brief write up on what's been happening in the world of 