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 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.
I’m assuming that by now you’ve probably heard of Let’s Encrypt.
If you haven’t, they are a brand new Certificate Authority that issues SSL certificates for free via an automated system!
There has to be a catch right?
Well kinda, but it’s a small one.
The certificate is only valid for 90 days.
They mention two reasons for this in a blog post: to encourage automation and to contain the damage of a compromised cert.
If you need to renew every 90 days, you don’t want to be doing that by hand right?
By encouraging automation, they can effectively force you to investigate how to make security easier for yourself over the long term.
You may have read the famous Ten Immutable Laws Of Security but the related Ten Immutable Laws of Security Administration tells us in Law #2 that
Security only works if the secure way also happens to be the easy way
Once you have automated your SSL cert generation then the easy way will be the standard way.
As last year I was unable to post every month about the Pull Request Challenge assignments, I decided that this year I would try to post updates every three months.
So, for the first month, I got WebInject. The PR was not huge. Just a contribution to add a README file to the distribution. As the author did not want to update the README and the POD, the PR was changed in order to generate the README from the POD. This PR was then merged. Yay, first month complete.
So lucky for me a client decided to pay me to refactor some of their very old code. Refactoring can be fun, but if you have a 20 year old business critical codebase where the team has forgotten or don't know how stuff works and it absolutely has to not break, then you have some challenges and quite a lot of potential for loss of face.
This particular job was to refactor a single large, excessively complex subroutine into something that was testable and that a relatively naive programmer could reason about. And there were no tests.
tl;dr: this blog post is relatively involved, but scroll down to the bottom to see some neat abuse of git as a data analysis assistant.
Perl's copious documentation is one of the things that keeps me using it. But
this is not an unalloyed benefit; actually finding something, unless you have
a pretty good idea where to start looking, can be like finding the proverbial
needle in a haystack.
Fortunately, we have Joshua ben Jore's perldoc-search,
which will find anything you can specify as a regular expression, and that
Perl itself can find.
Unfortunately, this can sometimes be a bit too much. I generally have several Perl
kits unpacked in my home directory (well, subdirectories of it). Since by
default file-find does a File::Find::find on
@INC, and since by default @INC contains my current
directory, then if I issue a file-find in my home directory, the
entire tree gets searched, and every unpacked kit can produce a hit.
It turns out there is a surely-unsupported but nonintrusive way to exclude
the current directory from the search. Instead of running
perldoc-search directly, run it as
It’s 2016, but the CPAN Pull Request Challenge continues. Motivated by my 100% in 2015, I subscribed to the second year, as well. Unfortunately, I didn’t have time to blog about my January PR, but it would have been more about Git than Perl, anyway.
My March assignment was Plack::Middleware::ReverseProxyPath. I noticed the module had several testers’ failures, and looking at the matrix I noticed Perl 5.8.8 was all red in both Linux and Darwin, so I decided to have a look at that.
