We're all familiar with references and Use Rule 1:
You can always use an array reference, in curly braces, in place of the name of an array.
This leads to code like ${$foo} (dereference a scalar reference) or @{$bar{baz}} (dereference an array reference stored in a hash).
The curious part: The curly braces actually form a block, i.e. you can put multiple statements in there (just like do BLOCK), as long as the last one returns a reference:
% perl -E 'use strict; use warnings; ${say "hi"; \$_} = 42; say $_'
hi
42
This block also gets its own scope:
% perl -E 'use strict; use warnings; ${my $x = "hi"; say $x; \$x} = 42; say $x'
Global symbol "$x" requires explicit package name at -e line 1.
Execution of -e aborted due to compilation errors.
$x isn't visible outside the ${ ... } block it was declared in.
% perl -E 'use strict; use warnings; ${my $x = "hi"; say $x; \$x} = 42;'
hi
Personally I'd prefer YAML over JSON for local config data anytime.
Even if JSON is secure by default, and YAML is insecure.
YAML is readable and writable. It's better than .ini, .json and .xml.
But Houston we have a problem. For a long time. I'll fix it.
We have the unique advantage that the spec author and maintainer is
from the perl world, Ingy, and maintains the two standard libraries
YAML, the PP (pure perl) variant, and YAML::XS, the fast XS
variant, based on LibYAML.
This would be an advantage if those two libraries would agree on their
interpretation and implementation of the specs. They do not.
Historically the YAML library is used as the default reader for
CPAN .yml preferences and a fork of YAML::Tiny, CPAN::Meta::YAML which
is in core is used to read and write the package META.yml files.
Too long/didn't read: Don't use Test::WWW::Mechanize::PSGI or similar, use LWP::Protocol::PSGI. I wish I'd found out about this module when it was first released in 2011 rather than in 2015. Which is why this article is here. LWP::Protocol::PSGI is great work and needs to be more widely known.
Since we moved away from monolithic web applications deeply embedded into the web server via the web framework movement and PSGI, now around a decade ago, a common way of testing things has been with modules like Catalyst::Test, Test::WWW::Mechanize::PSGI, Dancer2::Test and similar. These work by mocking the http
request and response layers, with the mocked layers talking to an object or a subroutine reference rather than a web server. Which is fine, except, say you want to test both against your application code and your web server using the same test suite. You end up having to do fairly nasty things to decide if you are dealing with a mocked http request/response layer talking to a coderef, or a real one talking to a web server.
TL;DR - if you have an Alien::Base based Alien module, please update configure_requires so that it depends on Alien::Base::ModuleBuild instead of Alien::Base, and (this part is key) make a release.
This is technically more correct, and it will also future proof your module in the event that Alien::Base::ModuleBuild gets spun off from the rest of Alien::Base. There are a number of motivations making such a move. Please join us on GitHub or the #native IRC channel if are interested in working on the next generation of of Alien::Base.
Sparrow is a tool to automate testing infrastructure. Automated testing
is essential part of continuous integration processes as it provides fast feedback
on cases when something goes wrong.
Consider simple example of how sparrow could be used to build up some basic parts
of your infrastructure.
web application development
We have a simple Dancer2 application we are going to deploy on development environment:
app.psgi
#!/usr/bin/env perl
use Dancer2;
get '/' => sub {
"Hello World!"
};
dance;
"The future is now thanks to science" - Clemont - Pokemon Trainer and Science Aficionado.
If you are in or around NYC next week then be part of the future. NY.pm has organized a Perl 6 Beginners Study Group and next week Saturday March 05 2016 is our second group session. Meeting details from official announcement in NY.pm mailing list:
``````
The second meeting of our New York City Perl 6 study group will be held:
Saturday, March 5, 1:00 - 3:00 pm
d.b.a.
41 First Ave
Manhattan
between East 2 and East 3 Streets
http://tinyurl.com/gphhdja
Subway: F-train to Second Ave; exit at First Ave (east) end of station
I fixed some tests in Module::Release because I supported v-strings and dev versions at the same time. Even though I don't use v-strings, the module would recognize v1.2.3_1. Andreas caught this because he does this amazing work to test CPAN breakage. John Peacock noted that version changed due to the "Lyon Compromise" from the 2014 Perl QA Hackathon. I know about the various concensuses (Olso Consensus, Berlin Consensus, Lancaster Consensus), but got no google juice on the Compromise.
In short, the Lyon Compromise is a bit more strict on version formats to trim off some tricky edge cases. John pointed me at a gist from David Golden which mentions Lyon but not Compromise.
So, I'm saying Lyon Compromise for Perl QA quite a bit. And Perl. Because keywords about version formats from the Lyon Compromise. If that's what you're looking for, I hope you find it.
My pull request challenge assignment for the month of February was Proc::ProcessTable a Perl module to interface with the Unix process table. As you can see from looking at the README.md file via Github this project recently has been moved to Github with the intention of light maintenance with focus on critical fixes made by the community. I was running out of time and I didn't have a linux system to use or test this module so I decided to do something simple like integrating Travis CI.
All it takes to enable Travis CI in a Github repo is a .travis.yml file in the root directory of the project and a Github account to allow Travis access to the Github repositories for Travis builds.
As you can see from the examples Proc::ProcessTable is now tested on 8 different versions of Threaded Perl running on Ubuntu Linux. Now I can mark my February assignment as done. YAY!!!! \o/
Not long time ago I asked a community about possible service to run integration tests for existed cpan modules , not having too much feedback I decided to run such a service to make my suggestion visible and available to try for other users.
So, meet CPANParty - an alternative integration tests for cpan modules. Right now service is hosted on swatpm site, but in the future I will probably move it to dedicated domain.
Only a few randomly chosen cpan modules was picked up and tested. Eventually I will add more.
On behalf of the Rakudo development team, I'm very happy to announce the
February 2016 release of Rakudo Perl 6 #96. Rakudo is an implementation of
Perl 6 on the Moar Virtual Machine
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[^1] --- it's announcing a new release of the compiler
only. For the latest Rakudo Star release, see
http://rakudo.org/downloads/star/.
For the past year I’ve been working on putting a new business together that is built on top of Perl and AngularJS. The new business is called Tabletop.Events. It is a convention management platform for the hobby board game industry.
It’s features include:
Badge sales and printing
User event submissions
Event ticket sales
Registration desk management
Blog and email newsletter to attendees
Desktop and mobile friendly interfaces
A full web service API
It’s built on Wing, which is the same core toolkit we used to build The Game Crafter. On the back-end, Wing is pure Perl making use of Dancer, DBIx::Class, Moose, and a whole host of other Perl technologies. On the front-end Wing is all AngularJS, which allows us to rapidly build out a robust UI that automatically ties itself to the Perl backend.
If you want to learn more about the technologies used to make Tabletop.Events, come hang out with us at the next MadMongers meeting.
Last time I have been deeply involved into test automation development. So some projects was born like swat, outthentic and finally sparrowhub.
After some mediation on the future of my projects I am still committed to the idea of sharing such a tests with the rest of perl/cpan community.
An issues arise on my way though:
people used to stick to convenient unit tests kept under their cpan distributions and are half-heartedly for third party tests alternative which of course is respected by me.
(IMHO) integration tests are hard to write and maintain, this is probably why people prefer to write unit tests, and as swat is kind of integration test tool, it could be "neglected" for the reason above. I believe still that integration tests are essential part of development.
Taking into account all of this I am introducing an idea of third party tests service - 3Party ( working name, just can't invent something better right now ) with the following features:
Part 3 of the Regular Expressions to Grammars tutorial is now up at http://theperlfisher.blogspot.nl/2016/02/from-regular-expressions-to-grammars-pt_20.html - This covers parsing of a short JavaScript blurb into a form that the compiler we're going to write next time can understand.
