So if you've been itching to get stuff done with EC2 in the eu-central-1 region (which AFAIK only accepts v4 requests), please give this test release a spin. I plan to release it as 0.31 after a couple of weeks if no show stopper(s) pop up.
]]>perldoc
. Working with Koichi KUBO, I think I have a perldoc which works effectively with encodings in files like perlop
, perlfunc
and perlvar
.
Preliminary results with the Japanese docs have been pretty successful, but it would be nice to get some positive results with other encodings/languages. So if you use a Perl with core documentation that isn't "plain old ASCII", would you please give Pod-Perldoc 3.24_01 a spin in your environment?
If you accept this task, please email results to bug-pod-perldoc at rt.cpan.org
, open a github issue, or comment here.
Thanks!
]]>I really like the notion of Channels that Perl6 seems to have implemented in the spirit of the golang channels. They are brilliant.
]]>With a recent thread from CPAN-workers fresh in my memory, I promised to release Test::RequiresInternet to CPAN during YAPC if I was fortunate enough to get through all of it.
I uploaded Test::RequiresInternet shortly before game night and its available on CPAN (also Github.) I just haven't gotten around to publicizing it a bit until I was back from Florida.
That means you can now write your test like this:
use Test::More;
use Test::RequiresInternet ( 'fluxcapacitor.io' => 1953 );
# I got Internet!
ok(travel_in_time());
done_testing();
Why not just use Net::Detect? I wanted a simple module that uses TAP output and didn't have any dependencies outside of the Perl core. I also wanted to account for the environment variable NO_NETWORK_TESTING
and the syntax I adopted.
In a recent update of the upstream service they included the ability to fetch additional data fields including timezone, congressional district, school district and so forth. Is there a good CPAN module (or a recommendation) to take a Perl data structure like a hash and turn it into a Moo(::Lax) object "automagically?" I had a look but I didn't find anything especially suitable.
These data structures are purely informational in nature and just have getters for their attribute names. This would be less difficult to accomplish using Moose (obviously) but I'm wondering if there are any suggestions for something that installs getters for hash keys dynamically and is Moo-friendly.
Thanks!
]]>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.
Over the weekend my new module was merged and released to CPAN by the HTML::Format maintainer. The driver script for the WordPress to Markdown conversion is here. I may revise my driver script to put post metadata into TOML but I haven't done that yet mostly because the static blog engine is still under construction so the exact post format requirements are still unstable.
I used a fairly good sized corpus of posts as tests and had good results but more tests are always welcome.
]]>I meant that
git clone https://github.com/mrallen1/perl-Tombala && cd perl-Tombala && cpanm --installdeps .
works
But that it is awesome if
cpanm https://github.com/mrallen1/perl-Tombala
will work in the future.
]]>Why would you want to install a project from git instead of the normal CPAN download/build/test/install process? There are a lot of use cases, but the one I care about most is experimentation, followed fairly closely by patching. Finally, there are pieces of projects which are too trivial to go through the whole "PAUSE packaging/upload" process.
The git representation of a Perl module may be weeks or months ahead of its most recent CPAN release. Also some developers maintain branches of the project which add (or remove) features not available in the CPAN release.
Using CPANfile makes using such code much easier to download and install correctly. If you haven't started using it already, please consider adding CPANfile to your normal development activities, especially if you host your code on a service like Git Hub.
Read more here. I'd also be happy to answer any questions in the comments here, sent from twitter or by email.
]]>This is an idea we need to steal for Perl hackathons.
]]>It's an admirable goal to strive for, but there are several ::Tiny modules which have non-core dependencies.
That being said, I could easily revert the Moo and the URI::Escape portions of the code, but once you opt for SSL connections you're pretty much stuck with non-core modules anyway.
Why not keep the sweet sweet sugar?
]]>So I started by thinking what was the "minimum viable product" for an EC2 client? Something that slaps a valid v2 AWS signature on any arbitrary API request and translates the XML returned into a Perl data structure. And that's exactly what Net::EC2::Tiny is.
In the spirit of *::Tiny modules, I tried to restrict the number of dependencies, but when I decided firmly to require HTTPS support, that locked me into IO::Socket::SSL and Net::SSLeay, so I opted to give myself a little bit of sugar and used Moo. So there's 5 non-core dependencies.
Anyway, when you're in the mood for a quick (and possibly dirty) EC2 client, whip up a simple(ish) script using Net::EC2::Tiny. It's the low learning curve glue between the raw EC2 API and Perl - perfect for those jobs which interact with EC2 in a relatively minor way.
]]>perldoc (a tiny little wrapper around the Pod::Perldoc module) finds the appropriate pod markup (either embedded in a .pm or a .pod), passes it to Pod::Man, takes the output from Pod::Man and then invokes the "nroff" implementation (which is usually groff) and sends it to your pager (less, more, etc) where it's displayed on your screen.
That's a lot of places where UTF-8 can go sideways. And it usually does.
So it seems like one solution is to simply avoid this pipeline, using Pod::Text::Term, so I've uploaded a developer distribution of perldoc (3.19_01) to CPAN where the default formatter for POD is "Term" instead of "Man". In my admittedly limited testing this seems to provide much better cross-platform UTF8 support when displaying documentation.
This is where you can help: please install the 3.19_01 distribution in a perlbrew environment and display some of your UTF8 documentation. If there are problems, you can report them on the RT queue for the distribution.
Thanks!
]]>Until today, this module had been using v1 signatures. If you use this module and start getting "version mismatch errors" from EC2 calls, you will need to update to this version.
Please be aware that URI::Escape and Digest::SHA were added to the module dependencies to implement AWS v2 signatures.
]]>