[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:cpanminuscurl -L cpanmin.us | perl - Mojoliciouscurl -L cpanmin.us | perl - Rediscurl -L cpanmin.us | perl - ZeroMQcurl -L cpanmin.us | perl - JSONcurl -L cpanmin.us | perl - MongoDBAnd 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`– testIt’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_appormojo generate appThe 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 webappcd webappmojo generate lite_app lisapp.plNotice 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:* LISTENI’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.