Joel Berger

I have found myself in a bit of a CPAN exuberance these last few months. While I have released several new modules, I haven’t found time to announce them individually. Here then is a joint announcement of what I’ve been doing on CPAN lately.

Test::Mojo::WithRoles

Roles are very cool, but due to the Mojolicious’ architecture not needing them, they seem to be sadly underused in the broader Mojolicious community. That said I saw a disturbing trend emerging surrounding Test::Mojo extentions; in order to add functionality extensions were all subclassing Test::Mojo to add their new methods. This is fine until you want to use two extensions in the same test script at the same time.

In order to dissuade this problem from continuing further, I have released Test::Mojo::WithRoles. This class is essentially a factory that builds a (mostly) anonymous subclass of Test::Mojo with the applied roles.

For the test writer, it makes it very easy to declare the role without having to compose them into a class yourself. Meanwhile for the test library author, all they have to do is use Moo::Role and it will work as you expect. Since most extentions simply add methods, this is usaully just changing the inheritance line to declaring the role.

If extension authors make use of this mechanism (I have a big one coming myself), we should all be able to extend the already awesome Test::Mojo without stepping on eachother’s toes.

Mojo::IOLoop::ForkCall

Ok this one isn’t “new” but rather it has gotten very stable. The reason that I’m including it in this post is that I’m hoping to call an upcoming release 1.0 (a rarity for me).

For those who haven’t seen it, Mojo::IOLoop::ForkCall is a mechanism to “unblock” blocking code by forking. It then presents a very Mojo-like interface for receiving the response. The code was originally stolen mostly from AnyEvent::Util with smatterings of POE::Wheel, though since then there have been lots of tweaks to make the code as solid and Mojo-friendly as possible.

Remember that this is forking, and forking and IOLoops together can be scary. If possible, you should use natively non-blocking database drivers or non-blocking api service calls etc. Sometimes that isn’t possible however and so that is where this module comes in.

Mojo::JWT

JSON Web Tokens are a really nifty way to pass messages over untrusted transport and still trust that the message hasn’t been modified. In fact the underlying mechansism is much like Mojolicious’ own session cookies in the way they work. The Mojo::JWT module makes it easy to create and validate JWTs in your Mojolicious (or even non-Mojolicious!) applications.

Rich Elberger was kind enough to write about it in his recent blog post “Perl and Google Do Mix”.

Webservice::Shipment

At $work, we needed to diplay shipping information to the user, as many sites that have physical products do. Though there were a ton of these modules on CPAN, some focused on wrapping all of the functionality of one service, others wrapped a small amount of lots of services. While I needed the latter, even these didn’t provide the ability to detect the service and then provide a consistent api to extend and thus fetch and read information from the external service. With Webservice::Shipment module provides this interface, though currently only for UPS and USPS. Additional classes are more than welcome!

Mojolicious::Plugin::ReplyTable

This one is especially fun! Mojolicious::Plugin::ReplyTable provides the (cleverly named) reply->table helper which accepts an arrayref of arrayrefs (rows of values) and renders it in one of many formats, determined by the user’s request. Mojolicious provides wonderful content negotiation which detect the type of response that the user wants, but you still have to build the handlers yourself. Not so for “rectangular data” anymore, just use this. Currently supported response types are text, JSON, HTML (table), CSV, XLS, and XLSX. Other types would happily be added if proposed (and especially if the code is given too :D ).

Mojolicious::Plugin::RevealJS

When I write a talk, I have a very important requirement: I want all of my code samples to be runnable. I want people to be able to copy and paste or clone the example and have it work. The only way that I can ensure this is if I can have all of the code external to the talk and include it into the slides dynamically. To this end I have already written two presentation systems on CPAN (neither of which I would recommend anymore) and this is a third. The first two tried to reinvent the wheel too much; Mojolicious::Plugin::RevealJS is simply a collections of helpful functionality wrapped around the excellent Reveal.js presentation library, which give me the functionality that I need.

It is very new still and I don’t make any compatibility promises yet, but it already is hosting my “Mojolicious Introduction” talk (in both dynamic and static forms). If you browse through that talk’s repository you can see that it already is doing the code inclusion and removes lots of the standard boilerplate. The fact that it is running on GitHub (static) pages shows that there is at least a basic facility to export the dynamically generated content as static pages. There still are several features that I would like to add, but I think it is useful already, as long as you will tolerate minor api changes in upcoming versions.

Come see me at YAPC::NA

I will be giving a talk on an as yet unreleased module which will make testing your web application’s javascript behaviors much easier. I hope to see you there!