Home » Posts tagged "Perl" (Page 2)

So that’s what ShipIt is!

In the last year or so I’ve been noticing that a lot of Perl modules contain a .shipit file. As I had no clue what it was about I searched the internet to see what ShipIt was and were to get it. But as you can see Google (or any other search engine) doesn’t return a link that describes. The name seems to be very common.

I figured as much that it was used to package up a module and simplify doing releases to CPAN. As well as integration with your SCM.

But never, never ever(!), did I think about looking up the name ShipIt on CPAN till today. I don’t know why I did so, but perhaps it’s because I’m still not very used to Perl modules being named anything different than Some::Long::Module::Name. Weird thing is that ShipIt first saw the light in 2007 (probably earlier, but the changelog doesn’t contain dates) so it’s out there for quite some time now. I must say I like these more decent names, as long as it doesn’t get as out of hand as it is with Ruby gems… How they name every single small gem as if it’s some sort of big ass application is beyond me. But who am I to judge about naming.

But that’s not why I’m writing this post. The main reason is for people, like me, to get to know the tool. I’m looking forward to using it to manage my modules so I don’t have to worry about updating version numbers, tagging the release in my SCM, test the final package and upload it to CPAN (or not). I know Dist::Zilla does this and a whole lot more as well, but I like Module::Install better. At least for now.

WebService::Rackspace::CloudFiles 1.01 released

I’ve just released a new version of WebService::Rackspace::CloudFiles, namely version 1.01. It should appear on your favorite CPAN mirror soon. If you really can’t wait you can get it from GitHub.

This releases fixes some issues with HEAD requests. Although the module fully implemented the specification supplied by Rackspace it turned out that their specification wasn’t up to date. In short what happened was that instead of returning a response code of 204 with HEAD requests they would in some places return a 200 response code. Instead of checking for these exact response codes (for HEAD requests at least) the module now accepts a Successful response (2xx).

I’ve reported the problem with the inconsistent response codes at Rackspace and they’ve told me that all HEAD requests will be returning a 200 response code in the future and that they’ve yet to update their developer documentation.

Anyone using either WebService::Rackspace::Cloudfiles 1.00 or any version of Net::Mosso::CloudFiles I recommend upgrading to this new release as both modules aren’t fully working anymore.

Use File::Find for recursive directory searches

One of the finest Perl (core!) module I’ve been using lately is File::Find. With File::Find it’s possible to traverse through a directory recursively to find anything you want from it. It comes with a number of options to alter the search behavior and a custom callback has to be supplied to determine what to do with the found file. Such as adding it to a list if it meets certain criteria, computing MD5 checksums or whatever else floats your boat.

Here’s a small example I also posted some time ago on Stack Overflow.

  1. span class=”st0″>’.’‘..’‘/my/dir/to/search’

Using Perl-Tidy with Notepad++

I was looking for a way to use Perl::Tidy with Notepad++ so I can format my Perl code from within Notepad++. Luckily for me someone else already figured out how to do this properly. I just had to modify a few small things to make this work for my needs.

My environment is a Windows Vista SP2 system with Strawberry Perl 5.12.1. Thanks to Strawberry modifying the system PATH I don’t need to configure this myself. After installing Perl::Tidy I can just call the perltidy command from the command-line. But for some reason calling the perltidy directly from within NppExec doesn’t work.

First, you need a .perltidyrc, or rather on Windows a perltidy.ini. I don’t really know why this has to be different, probably because it sometimes can be a pain to create a nameless file (meaning, a file with only a extension). Here’s my perltidy.ini file which I installed under C:\Users\<USERNAME>\perltidy.ini. I’ve actually shamelessly stolen this configuration from Mojo.

So following the earlier mentioned blog post this is what I changed to make it work for me.

  1. Change the command-line in NppExec to the following:
    perl -x -S perltidy "$(FULL_CURRENT_PATH)"
  2. Do the Advanced Options part
  3. Now create a Macro: for some reason this doesn’t work?

    1. Start recording
    2. Go to Macro > Execute your newly added perltidy macro
    3. Go to File > Reload from Disk
    4. Stop recording
    5. Save Macro and assign a shortcut to it

Now I wanted to be able to fire this off with a key shortcut, but I can’t add those to macro’s created with NppExec. So instead I tried to create a macro that executes the perltidy macro and then reloads the file from disk. But when executing this macro nothing happens. So if anyone has an idea to why this is I’d be glad to hear it.

For now this manual execution will work just fine. It’s just annoying that I’ll have to reload the file from disk manually.

Finished reading: The Definitive Guide to Catalyst

A couple of days ago I finished reading The Definitive Guide to Catalyst which for a technical book (or any at all) I read through quite fast. I’m not going to write a full fledged review about it but I can recommend it to anyone interested in working with Catalyst. For those who don’t know it Catalyst is a web application framework written in Perl.

Although the online documentation is very good the book is a nice addition to it. It’s more than just a collection of some code examples. The chapters follow a certain thought process to write maintainable and extensible code, complete with tests and all. Common in the book is that the example code will get a rewrite later on in the chapter to reach this goal. I consider this a nice feature of the book as it shows why that refactoring was needed and is the better solution to the problem.

There are only a few small complaints I’ve got about the book. The code indentation isn’t always consistent and there are occasionally some errors in the code. But looking more at it from a conceptual kind of view it’s clear what the author intents. I also don’t really understand the choice to include Reaction in the final chapter. Documentation is scarce and it seems abandoned. I’d much rather see some Catalyst::Runtime core modules described in there, such as Catalyst::ScriptRunner (did it even exist at the time of writing?), Catalyst::Request and Catalyst::Response. I know the latter 2 are well documented, but they weren’t even mentioned in the book.

Other than that it was a great read and am glad I bought it :-).