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.
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.
Welcome to Planet Moose, a brief write up on what's been happening in the world of 