One of my long standing mental code blocks has been trying to get me little brain to understand what a 'Route' is. This really came to a head when I first started to use Mojolicous in a big way.
You see in the old days it was easy, you just had an URL that pointed to something and you could either get or a post to it. It was of course used and abused in all sorts of ways, I still have a browser bookmark that looks like this
Regexp::Parsertron is a Marpa-based parser for Perl's regexp. Yes, I've written a BNF for the regexps. The low (dev) version # tells you something important.
See the docs on MetaCPAN for details.
Devel::Cover is fast approaching its fifteenth birthday. When it was released the minimum Perl version supported was 5.6.1, and that was because the mechanism Devel::Cover needed was not introduced until 5.6.1.
Since that time, Devel::Cover has supported every new, stable version of Perl, whilst continuing to support every version from 5.6.1. Not every feature is available on every version, but most are.
I have recently pushed a commit which raises the minimum version to 5.8.1. The main reason for this is that it is becoming increasingly difficult to install 5.6.x and 5.8.0 to test against. Other reasons are that Devel::Cover has reduced functionality prior to 5.8.1, and that the official Perl toolchain now has a minimum version of 5.8.1. I'd rather spend my limited time on other aspects of Devel::Cover than supporting perl versions that are well over a decade old.
I doubt very much that anyone is seriously using current versions of Devel::Cover on versions of Perl before 5.8.1, but I'd be interested to hear from anyone who might find this new minimum requirement to be troublesome.
Otherwise, I'll plan on releasing Devel::Cover 1.22 with this new requirement in the near future.
Last night I gave a "Wow, Perl 6!" talk at the Toronto Perl Mongers, whom I thank for letting me speak, even after I got lost for 15 minutes in the building the event was hosted at and was subsequently late.
The talk is an overview of some of the cool features Perl 6 offers. If you didn't get a chance to be at the talk or to watch it via a Google Hangout, you can still get a recording of it.
Not a tech blog today more just a store on design and development. So here goes.
Once upon a time not too long ago and not very far away I was happily working working away when the dreaded battle started between 'The Design' and the 'The Process' types.
Well the end of this was that neither side won their little war and as the big hats came in an 'solved' the team problems by a compromise which left both sides unhappy and shall we say not on speaking terms.
So on the process side the great and glorious 'Scrum' process was adopted (btw not the choice of the Process types) and on the design side they stuck with good old Requirements and Design from the 'Waterfall' model we all know and love.
The real rub was the chief process guy was put in charge of the requirements and the chief design person was place in charge of the process. Needless to say I smelt disaster from a long way off.
There is a new page on the Perl Weekly website listing all the authors.
It would be awesome to have a list of articles by author mapped from that page.
The problem is that the list of authors is probably not complete and many of the articles that were included in the 4+ years of the newsletter were not tagged with the author. Especially in the first 2 years. So if you have some spare time and would like to help adding the authors to the articles....
All the source code is in this repository. The source files are in the src/ directory. Including the authors.json file that holds the information about the authors. The html/ files are generated. Don't bother with those.
If you are already there, it would be nice to include the Twitter account of all the authors who have a Twitter account so the little Twitter links next to their articles (See the latest) will also include their handle. That can help people further distribute the articles and also mention the author in one click.
Well, it was a great party but .. It seems everybody needs to get home, as home is better place than being a guest somewhere ... as Russian would say ;)
But to be serious I am going to close cpanparty project as:
I don't have much time to write new test cases for existed CPAN module and it seem nobody wanted to join this process
My initial idea behind sparrowhub was to create a repository of reusable test / monitoring suites to match various life practical cases. CpanParty is a bit different - this is specification by example / test descriptions of existed CPAN modules. Still thinking that idea is quite interesting I am going to remove cpanparty plugins from sparrowhub to keep it clean and dedicated to initial purposes so not to confuse user asking how can I use test cases for Dancer2 or Mojlicious or other great web frameworks in my daily test/monitoring tasks?
There has been some discussion this week about forks of pieces of Mojolicious.
Frustrating discussions over what is proper and how to discourage forking.
It has been a long week to be honest (and thankfully the recent incident has been peacefully resolved, see postscript).
But then finally, just today, I’ve chosen to see things a different way.
I’m really happy to see what lengths people are willing to go to in order to use Mojolicious.
This includes addressing a perceived need for streamlining by taking a maintenance burden onto themselves and forking that code that which they need.
They see the value in Mojolicious’ code, if not the value in the toolkit as a whole.
At the 2016 German Perl Workshop in Nuremberg
I first released and demonstrated a simple local search
engine created from Elasticsearch with Perl for the surrounding infrastructure.
The search application is distributed via CPAN as Dancer::SearchApp.
In my ongoing crusade to direct people away from XML::Simple and towards XML::LibXML, I've recently published a documentation project called "Perl XML::LibXML by Example". The primary target of this documentation is the desperate Perl hacker who might otherwise reach for XML::Simple without realising the awful horrors that module will inflict upon them. My hope is that by pointing people at this documentation we'll be able to help them solve their problems sooner and with less pain.
In helping people with their Perl and XML problems I've come to realise that in order to become proficient with XML::LibXML what people really need (and what I've aimed to provide) is:
Perl is a thriving language backed by an active community that continues to grow daily as newcomers discover what the language has to offer. The Perl Conference (also affectionately referred to as “YAPC::NA”) is the premiere North American event featuring training, workshops, hackathons for all things Perl and for all skill levels.
If you are new to Perl and have never attended YAPC before, The Perl Foundation is pleased to announce a very special welcome gift for a few lucky individuals. If this is your first time, you could join the Perl community at YAPC::NA::2016 in Orlando, Florida June 19th through 22nd for only $50.
Here’s what your $50 will get you:
Free admission to the main conference event, including all track talks, all keynotes, and some fun social events. (Regular ticket price is $250).
Free hotel accommodations June 19, 20, and 21 (The lowest room rate is $119/night)
Free Zero to Perl 5 Beginner Class. (Regular ticket price is $75).
SparrowHub - is a test/monitoring suites repository. SparrowHub repository contains collections of reusable testing/monitoring suites which are also called plugins. These are test suites for various use cases. From testing web services to checking disk available amount on your server. Sparrow suites are runnable via console script called sparrow which produce TAP output. It could be used in whatever monitoring , testing task and could be easily integrated into existed monitoring / deployment / configuration / automation systems. Sparrow plugins to be written on outthentic DSL and to be extended by Perl.
I have just added two 5 minutes tutorials for those who:
wants just to use sparrow suites in monitoring / testing purpose
Social media will absolutely help you grow your local PM. Through consistent social media usage, when combined with consistently holding meetings, Sydney PM meeting attendance has grown from a motley crew of ~6 people 18 months ago to a venue busting 25 last month.
Attendance was so unexpectedly large we had to move out of our hosts board room (thanks Broadbean) to their general staff area. Thankfully their wall mounted status TV was quickly re-purposed for presenters and the show went on smoothly.
Social media for us has been Facebook and our pm.org email list, with Meetup being recently reinvigorated along with #australia on irc.per.org (does that count as social media?)
Heres a strategy: Facebook is very good at gently reaching out to people who can be convinced to play around with perl and come along to your meetings. They might not have used perl in a while, or at all, and everything in between. These people can be gradually enticed to come along via your PM's Facebook page.
On behalf of the Rakudo development team, I'm very happy to announce the March 2016 release of Rakudo Perl 6 #97. Rakudo is an implementation of Perl 6 on the Moar Virtual Machine[^1].
This release implements the 6.c version of the Perl 6 specifications. It includes bugfixes and optimizations on top of the 2015.12 release of Rakudo, but no new features.
Upcoming releases in 2016 will include new functionality that is not part of the 6.c specification, available with a lexically scoped pragma. Our goal is to insure that anything that is tested as part of the 6.c specification will continue to work unchanged. There may be incremental spec releases this year as well.
Please note: This announcement is not for the Rakudo Star distribution[^2] --- it's announcing a new release of the compiler only. For the latest Rakudo Star release, see http://rakudo.org/downloads/star/.
If you've been a programmer for more than a couple of years, then you remember when Node.js first appeared. Some folks were raging about how insanely fast their ecosystem was growing, while others confusedly shrugged, wondering why anyone would want to use a language made for scripting browsers for server side work.
I can easily dismiss Node's large ecosystem of reinvented wheels, but the underlying point of why it got popular is valid: the fewer languages you need for an app, the fewer (or less experienced) programmers you have to hire, the cheaper it is to make your app. The self-proclaimed "HTML programmer" who was copy-pasting JS snippets from blogs and forums, now of all a sudden became a full-stack Web developer. But is using a made-for-browsers language for all-purpose work the right approach?
My
latest blog post
is the introduction to my Marpa Book, currently in progress. The book will be a theory monograph, so it's kind of stuffy, but it's a good summary of Marpa's features. It also discusses the implications of these features for applications.
