I have come to wish many things were part of Perl syntax that are not, and no using external modules is not enough for me. I think it’s time Perl got the features as part of the language itself (and yes I suppose I could settle for feature.pm, and no I’m probably not going to write them myself, I’m not smart enough yet). The first of these is a proper exception stack.

The most prevalent of SOAP libraries for Perl is SOAP::Lite it is the oldest and most documented. Though for all of its documentation it can be quite painful to figure out how to use it. First make sure you’ve read Part 0 to set up the server. Once that’s done let’s look at the most simple way to interface with this server. In our first example we need to send a request to getCountries, which is a method provided by the API.

This is a prelude to a series on working with SOAP Requests using Perl. For the past 3 months I have been working on a Perl API for CyberSource’s Simple Order API which uses SOAP (I should note, that although I believe most of the API is now stable some area’s still need work, and thus I don’t expect it to reach 1.0.0 anytime soon). First I used SOAP::Lite to do my requests, but I found it confusing to construct the requests that I needed to make.

I’ve heard many times that Dist::Zillamakes it harder for people to contribute to the project. This is not true, it is either unfortunately either ignorance or FUD (much like saying Linux is harder to use than Windows). Truly, there are things that some dzil users do that canmake it harder, but it doesn’t have to be that way. Michael Schwern recently contributed to one of my dzil projects without ever realizing I was using dzil, until I told him.

About 4 months ago russoz (Alexei Znamensky)sent me a message about quoting the versions generated by Dist::Zilla::Plugin::OurPkgVersion. I was a bit skeptical at first about needing it, and the suggestion seemed to have more to do with style anyways. But after digging a little I found to my horror that OurPkgVersion was generating completely invalid multipart version strings, e.g:our VERSION = 0.1.0;Which doesn’t work. I was shocked because I was using Test::HasVersion.

Hopefully, someone will use the blog post to write an actual doc patch, seeing as how this is undocumented. I finally wrote A test for DZP::OurPkgVersion with the help of CJM. So I figure it’s best to share the knowledge imparted upon me to all those who are writing plugins without tests. Before we get started I’m going to advise that this test will only check the output that dzil built, if you need it to test anything more sophisticated, you’ll have to learn more.

Here I talked about creating a new catalyst project using a minting profile for Dist::Zilla. If you don’t know how to create a minting profile read that first. I’m sure once you’ve tried that you’ll agree that having a little bit more than the basics in a newly minted dist would be a good thing. first we need to create our profile.ini correctly 1 2 3 [GatherDir::Template] root = repo include_dotfiles = 1 (note: if you’ve got [DistINI] plugin loaded you’ll probably want to remove it) Now you can put any file in the subdirectory repo of your profile (if you leave out include_dotfiles = 1 then anything beginning with a .

For starters I’m not a super fan of interactive shell’s for non-system shells. I don’t see the point as much. When I first tried Devel::REPL I didn’t like it at all, compared to every other interactive shell I’ve used (with the notable exception of Oracle’s SQLPLUS, which is the worst shell ever) it was an unfriendly toy not worthy of mention. I couldn’t go up in history, there was no tab completion, and all in all the default output was ugly no colors or formatting.