I'm at a conference in Portland this week to learn about a web framework called Symfony2 for my $DAYJOB. The Symfony2 stuff is all co-located with DrupalCon 2013 and one of the rooms across the hall from our workshop was for Drupal sprints. The sign in the picture was posted outside - and it makes it super clear that newbies are welcome, and who they should try to find to get going on a task quickly.
This is an idea we need to steal for Perl hackathons.
]]>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.
]]>In the latest release we've:
Added better support for UTF8 in the pod -> *roff -> *roff-formatter -> pager pipeline - unfortunately a lot of UTF8 support for pod remains at the mercy of *roff-formatters. People running perl on Mac OS X, for example, will get old crufty versions of groff that do not process UTF8 input, even though Pod::Man supports UTF8 output.
Improved support for $PAGER and $PERLDOCPAGER definitions that expect pipelines or input redirection
Improved behavior of -l -q
Added two new formatter classes (ToANSI and ToTerm) which bypass many of the UTF8 problems with *roff-formatters.
Made it easier for downstream utilities to define their own command line arguments
Closed over 20 bug tickets on the RT queue. Some of these bug reports were years old unfortunately.
One area where Pod::Perldoc needs definite improvement is in a test suite. It has almost no tests, and the tests it does have are very basic. This is an area I intend to address on an on-going basis, but in order to make the Pod::Perldoc which ships with Perl 5.16 the best it can be, I would appreciate more testing from a wider audience of installations and operating systems.
An easy way to do this without risk to your other perl installations is to set up a "perldoc-testing" instance of perl inside of perlbrew where you can install Pod::Perldoc 3.17 from CPAN after the fact. (Note: Pod::Perldoc now requires at least perl 5.6 due to heavy use of "3-argument" open in several refactorings.)
Bug reports, comments or questions are best directed to the RT queue, but I will cheerfully review pull requests or Issues on the Pod::Perldoc github repository.
Thanks!
]]>The guinea pig CPAN release for this talk is a Perl binding for the Cron.IO service. It uses Franck Cuny's cool Net::HTTP::API library. A complete binding in like 60 lines of code. Very cool.
]]> ]]>
Basic tags in git are a human friendly label that point to a certain commit. Basic tags don't have a git object associated with them so they're mostly for use on your local repository.
It is also possible to create "annotated tags" which are first class git objects and point to a specific commit (as the top of a tree of commits.) Because annotated git tags are first class objects, it is possible to share them across repositories. It is these tags that I would encourage you to make if you use Git Hub.
What do you get for your trouble? When you push your tags to Git Hub, it automatically creates a ZIP and tarball download link of that tagged release. That can be handy for a bunch of different reasons - uploading to CPAN or sharing code with people and systems without a git client to name two. (They can also be handy if you don't want to go through BackPAN to find historical releases of modules.)
How do you make (annotated) tags?
git tag -a 'VersionString' <Commit>
Example (where 88df47a represents my HEAD):
git tag -a 'v1.03' 88df47a
Your $EDITOR will fire up and git will prompt you to add a tag commit message. I usually make it the same as the version string on the command line, but it could be whatever makes the most sense to you. And because in some ways git is like perl - there's more than one right way to do this. (This is what works best for me.)
You can tag historical commits too. Just replace the tag string and commit reference at the end of the command line with the appropriate values. You can find historical code commits using git log of course.
To check tags, or explore someone else's tags, you can see all of the tags in a repo by typing:
git tag
Another advantage is that you can substitute a tag pretty much anywhere you need to use a commit reference. Instead of typing 88df47a, I can substitute v1.03 which I think we can agree is a lot easier to remember. (But maybe not - perl hackers' minds work in strange ways sometimes.)
Once you have made the tags you want, you need to push them (just like your regular code commits) using the --tag flag on git push.
Example:
git push origin master --tag
Assuming your origin points to Git Hub, they will take it from there.
P.S. If you're looking for an easy introduction to git covering 80%+ of basic source control workflow, I saw this last night on Hacker News and really liked it. So, have a look.
]]>Jeff, if you see this please email me: mallen at cpan dot org.
Thanks.
]]>It's a culture shock coming from a background of CPAN. The old joke is that Perl is just a life support system for CPAN and that is arguably true, but I am here to tell you: you may not appreciate how good Perl hackers have it with respect to CPAN and the culture around documenting, packaging and testing distros once they're on CPAN.
It's hard for me to be neutral vis a vis Perl and Python because I am much more comfortable writing Perl, but I felt like the release process for python was really not very straightforward. Learning how python projects write, package and release documentation took as long as writing major portions of code. And I'd take the simplicity of writing TAP vs. the inflexibility and opaqueness of the Python unittest library any day. Finally, there's the mess of installing a python distribution with all of its dependencies. I've heard plenty of complaining about how CPAN client X does this badly or client Y does this other thing poorly, but I felt like I was in cargo cult territory with respect to the various ways that python tools are distributed and installed.
But aside from being generally unfamiliar with the cultural mores of the Python world, working with Python was good for my Perl code in the sense that it really focused me on how objects within the client should interact with each other. This isn't a knock on Perl's OO (or perceived lack of OO) capabilities, but rather a realization that I used my Perl library as a "first draft" client with the API service itself - prioritizing "it just works" over "it's elegantly constructed."
Now that I'm feeling pretty good about how the python library works and is written, I can go back and refactor my Perl code that much more quickly.