This the the third part in an on-going series about using Mojolicious to write non-blockging applications (with an eye towards the web, obviously). In part 1 I demonstrated the how it can improve the number of requests/clients served when the application uses high-latency backends (in that case a database). In part 2 I showed how each request can be sped up when that request needs multiple resources from a high-latency service (e.g. external web services).

In each, I showed a blocking example, then a non-blocking example. I then gave the usual warning that you had to use a Mojolicious server for the nonblocking version. While its true that you need a Mojolicious server to get the benefits of the nonblocking architecture, in this post I will show how with a little care in construction, you can build your application so that it will run correctly on any supported server and the nonblocking benefits will be evident where possible.

In a recent post, our own Buddy Burden expounds on the relative merits of readability vs flexibility (in the guise of Python vs Perl respectively). While he does not completely concede the point that Python is more readable than Perl, I will go so far as to negate it. In fact, I would say that the prettiness of Python can even mask some real readability issues.

I have been a Perl programmer for several years, but early this summer took a job writing Python. I’m glad I’ve learned it, there are several things that I would love to see added to Perl, most notably a set type and a proper in operator (~~ got close). That said I will absolutely not concede that Python is easier to read than Perl, as all too often is taken as the axiom that many believe it is.

And I have examples.

This post announces the release of Mojolicious::Command::nopaste, a clone of App::Nopaste using the Mojolicious toolkit. I wrote it mostly as an example of using Mojolicious and its command system, but it has the side benefit of having a much lighter dependency chain than the venerable original (I already have the only required dependency on every box I use).

It also has a few bugfixes that the nopaste author either hasn’t tripped on, or had the time to fix (mostly in the Clipboard interaction on Linux) (sartak if you want to ping me I’d be happy to work with you on it). It has a slightly different list of services, including the very fun MathB.in but lacking Gist for now since the OAuth is something I don’t want to deal with yet. Any other services that people are interested in may be contributed via a PR or even a decent api spec.

Enjoy!

In my last post, I use a Perl dispatch pattern where you store a subroutine reference in a variable and then use that as the method to call on an object. Like so:

my $method = sub { ... };
$invocant->$method(@args);

Is there a name for this pattern? If not I propose to call the “method” an “ephemeral method”. Does this work for everyone?

Note that you really can’t call it a lexical method for several reasons.

Update:

Part of the broader problem of adding test methods in a composable way has been addressed now in the Test::Mojo::WithRoles system. That said, the original post still contains a solution that is easier in one-off scenarios. Keep reading :-)

Original Post:

Perhaps by now you are aware that Mojolicious has a very powerful test framework called Test::Mojo. It wraps most of the Test::More in with Mojo::UserAgent, Mojo::DOM and Mojo::JSON (and probably some things I have forgotten) to let you really test your app in a deep but pleasant way. That said, what if there is some method you wish it had? Should you monkey patch it into Test::Mojo?

No! There’s a better way! The next version of Mojolicious includes one tiny improvement that opens the world of testing as far as your imagination can take you. It just requires a little cleverness.