[Update] I should have mentioned that the elapsed time was only about 15 min; maybe less.

I’m a perl programmer from way back and while it has been 2 years since I’ve written any perl of consequence I’ve decided that my client’s application was going to be implemented in perl… just for the fun of it. (I’ve been writing a lot of python+tornadoweb+redis+mongodb and I’m very comfortable in this space. Mojolicious is a half step outside my comfort zone because I really do not want to rewrite this app in python if I don’t have to. I’m a big believer in DRY)

I’m certain that everything is installed. I used the same installation for documentation’s sake recently:

wget http://fastdl.mongodb.org/linux/mongodb-linux-x86_64-2.0.0.tgz
# need to untar and then relocate the files to the path

# MOJOLICIOUS - (as root)
curl -L cpanmin.us | perl - App:cpanminus
curl -L cpanmin.us | perl - Mojolicious
curl -L cpanmin.us | perl - Redis
curl -L cpanmin.us | perl - ZeroMQ
curl -L cpanmin.us | perl - JSON
curl -L cpanmin.us | perl - MongoDB

And we should be ready for the first app.

The application folder structure is going to look like this:

.
|-- COPYRIGHT
|-- INSTALL
|-- LICENSE
|-- README
|-- bin
|-- data
|-- doc
|-- src
`-- test

It’s far from perfect and it’s missing the Mojolicious application (webapp). So let’s create a mojo app (adapted from the docs):

Nope, not yet. First you have to know whether you are going to create a lite_app or a full-blown app.

mojo generate lite_app

or

mojo generate app

The difference is quite extensive. The second selection is probably best suited for anything more that a a few dynamic pages. And the lite app seems suited for all-in-one file deployment. Right now I’m not sure which is best for this design problem, however, I know that I can convert later; I can cut-paste everything and with any luck I won’t be repeating myself.

So before I make that decision. What does my application look like.

• I need a login screen and session state so that the data is private for my client. One user is sufficient.
• I need to upload a CSV file to a file system and queue that file for processing.
• I need a background process that looks for queued files and then processes them.
• The process is as simple as a GET against a URL, storing the result in another CSV and then getting the next record from the input file.
• Once all of the records have been processed the second file is converted to a PDF of mailing labels.
• The PDF can be downloaded from inventory.
• and finally the user should be able to delete the PDF, the original CSV and the intermediate CSV.

So that’s pretty simple. I need a few pages:

• login
• error
• queue status
• upload
• are you sure (popup??)
• completed (optional, could always be inline)

So for the time being lite_app it is. This is what I did:

mkdir webapp
cd webapp
mojo generate lite_app lisapp.pl

Notice that I specified my application name (lisapp.pl). Starting the app was a breeze eve though it bugs me that the mojo team misused daemon and does not even want to be open minded about it. Oh well, it’s a good platform in spite of ‘daemon’. And then I noticed the output:

$ ./lisapp.pl daemon
[Wed Sep 21 00:13:47 2011] [info] Server listening (http://*:3000)
Server available at http://127.0.0.1:3000.

Notice that the output is stating that it’s listening on ‘*’ and 127.0.0.1.  What’s up with that? When I did a ‘netstat -ln’ I only had one instance of port 3000.

tcp        0      0 0.0.0.0:3000            0.0.0.0:*               LISTEN

I’m not certain I understand the motives here. But I have to say that it drop be nuts because I knew that I had to test on 0.0.0.0 since my server is at Rackspace. And at first glance I only saw the 127.0.0.1. So it’s on me to pay attention and on them to be more clear.

When I pointed my browser to the URL it popped. As I expected since this is a very lightweight app. So for now I will take a break. Next time I will add the login screen. It’s part of the 3rd screencast and pretty simple. I also need to read-up on the under command. It seems to be where all the power comes from. Keep in mind that the home page is going to be a login screen. No data should leak out. Everyone logs in.