Monthly Archives: August 2011

[update 2011.08.30] as pointed out these are not micro frameworks.

I’m not sure where to begin and I’m not certain where this is going to end. I have an outline and some ideas but nothing is concrete. I’m not even sure what my conclusion is or how I’m going to get there.

What I do know is that I’m a fan of python and perl, among other languages both compiled, interpreted, functional, byte-coded and JIT. I know that I like small and micro frameworks that don’t get in the way of getting things done. And I know while I like extensive and mature libraries I do not like deep dependencies. And while like terse language semantics and idioms I tend to prefer just enough to be descriptive and functional (the other kind of functional). As I reflect on that description I visualize my ideal senario as the sweet spot on the bell curve.

History

This past weekend I read an article where the author talked about micro web frameworks. Sadly the comparison was limited to a few python web frameworks and he seemed to miss a few at that. (cyclone and tornadoweb). However, it was a good article

.

This got me to thinking. “are there any micro web frameworks for perl?” My first google search was not very good. Catalyst was in the top 10 over and over so my “find” was not there. I kept trying. That’s when these two popped. Mojolicious and PerlDancer. I went to the mojo site and followed a link to a screencast. It reminded me of a rails demo I watched many years ago. This time, however, the presenter used a mac+vim instead of a mac+textmate. I was highly impressed, not because I like vim but because the demo showed just how well thought out this one feature was. So I’m hoping that the rest shows the same attention to detail.

PerlDancer, on the other hand, seems to follow in many of the same footsteps. And while they are micro frameworks with many similarities to their python cousins they have plenty of differences.

Just some quick notes. The author of mojo appears to be the main author of catalyst. And PerlDancer admits to being a kissing cousin to Sinatra.

Installation

To start any evaluation you need to start at the beginning. In this case the installation. One of the things that I first noticed was that they both used cpanmin.us. cpanmin.us is a url/web application used to automate the installation of CPAN libs. Of which these both qualify.

Today was not a good day for cpanmin.us. First of all their DNS servers seemed to be off the air. When the cpanmin.us server returned the installation went easily enough. I had been given some advice for installing the project manually, however, as much as I need to understand the complete dependency tree for this article and whatever projects I might install… this was one skirmish I was going to lose.

$ sudo sh -c "curl -L cpanmin.us | perl - Mojolicious"

After I entered my password for the sudo command everything started to churn and everything seemed to install nicely.

$ curl -L http://cpanmin.us | perl - --sudo Dancer

PerlDancer was not that lucky and it’s probably not PD’s fault. After the first run I received an error message. PD could not write to the .cpanm folder which mojo had created but with root ownership. This required that I update the ownership of the folder and rerun the command.

The one thing that is missing here is the commands for deploying this project in userspace and yet the critical libs in sys-space. While I have dev servers and most users do too. It’s a good practice to sandbox this sort of tool until there is widespread adoption.

I’m not sure if PD simply generated more io during the install or if it just had more dependencies but there was a lot more output from PD.

Hello World

My first hello world was implemented using mojo. It’s a good thing for me that mojo had a 3-line h.w. on their website and it worked out of the box.

use Mojolicious::Lite;
get '/' => {text => 'Hello World!'};
app->start;

The PerlDancer, on the other hand, simply did not work. From what I could tell neither the command line tools dancer nor the perl module existed and since I had already closed my desktop and terminal sessions I had lost any hope of determining if there had been a problem during the installation. So I did what any other sysadmin would do. I re-installed it and tried h.w. again. This time it worked:

#!/usr/bin/perl
use Dancer;
get '/hello/:name' => sub {
    return "Why, hello there " . param('name');
};
dance;

It’s interesting that they are so very similar when it comes to the h.w. code. I’m fairly certain that if I add the bang-splat to the top of the mojo example it would work fine too… but then I decided to experiment with it myself and it did not work. So one strike for and against both frameworks. Net-net the score is tied at zero.

Hello World App

There is more than one way to create a h.w. app.

$ mojo generate app hello_world

Sadly this generated an error. Mojo wanted the app name to be standard perl camel case. So I tried again:

$ mojo generate app HelloWorld

which worked. So then it was a matter to launch the webapp which the documentation suggested that the following would work:

$ ./script/hello_world

But when I tried to launch the application I was returned immediately to the command line with a dump of the usage string. Frustrated by not sleepy enough to give up, I decided to try the same set of steps with PerlDancer. So I created my app:

$ dancer -a MyWeb::App

And the first thing I read in response to my request was… YAML was missing. So although pd was nice nough to give me the install string I had more manual config to do. I would have thought the config would have been complete already. So… I installed YAML and then tried again. This time the command completed ok.

$ cd MyWeb-App
$ ./bin/app.pl

Now the webserver is running. The pages loaded. Maybe not with as much zip as I was hoping for, but it displayed. And as I wrap up this session I decided to try one more thing with mojo. When I tried to launch mojo on my generated h.w. app I received this output:

rbucker@mvgw:~/tmp/hello_world$ ./script/hello_world
usage: ./script/hello_world COMMAND [OPTIONS]

Tip: CGI, FastCGI and PSGI environments can be automatically detected very
     often and work without commands.

These commands are currently available:
  eval       Run code against application.
  cgi        Start application with CGI.
  inflate    Inflate embedded files to real files.
  version    Show versions of installed modules.
  daemon     Start application with HTTP 1.1 and WebSocket server.
  cpanify    Upload distribution to CPAN.
  get        Perform HTTP 1.1 request.
  fastcgi    Start application with FastCGI.
  generate   Generate files and directories from templates.
  test       Run unit tests.
  routes     Show available routes.
  psgi       Start application with PSGI.

These options are available for all commands:
    --help          Get more information on a specific command.
    --home    Path to your applications home directory, defaults to
                    the value of MOJO_HOME or auto detection.
    --mode    Run mode of your application, defaults to the value of
                    MOJO_MODE or development.

See './script/hello_world help COMMAND' for more information on a specific command.

Clearly I was missing something. The daemon option was the one that I caught first. I supposed that if I used that option that the application could launch and run in the background. Thus making it impossible to see any console output and limiting the amount of debug information I was going to receive. I had tried a few other options like routes which worked nicely and I tried psgi, cgi and eval. It was not clear to me which was going to work. So on a whim I tried:

$ ./script/hello_world daemon

And lucky for me. It worked. So now I have more to test. I went back to my original hello.pl script and tried:

$ ./hello.pl daemon

This worked. I finally had everything working. Of course I’m not happy about the daemon flag. It seems counter intuitive for the moment but worthing contacting the author.

Well; given the amount of confusion and general inaccuracy I have decided to break this article into 2 and possibly 3 parts depending on the response I get from the mojo author.

In conclusion for the moment… if I had to decide the fate of these frameworks right now. It would not be good for them. There are too many alternatives that have good and sometimes great docs. Hello World is not the place where I expected the doc to fail.

In coming articles I hope to cover the following as it applies to this toolset. But only if the system continues to function. It is quite possible that I’m going to test the python micro web frameworks instead or in addition to…

Perl Concurrency
Performance
CPAN
Worker Model
ZeroMQ
MondoDB
Redis
Projects that deserve forking

 

[update 2011-09-01] The guys at mojo have made it very clear that their usage for DAEMON is the way things are going to be. I can respect that although I disagree. There are no less than 3 examples in the same “framework” space that use the term consistently. Only they have inverted the meaning. This does not mean that mojolicious is bad or worse. But it means that buyer beware. You gotta spend more time making sure that they have not change the context in other areas. From my perspective this is too bad. I would have like used it.

for testing:
/usr/bin/twistd --nodaemon --python=foobar.tac

for production:
/usr/bin/twistd --pidfile=/var/run/foobar.pid \
                --logfile=/var/log/foobar.log \
                --uid=nobody --gid=nobody \
                --reactor=epoll \
                --python=foobar.tac

QED