Skip to main content

mojolicious - first app (part 1)

[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:
# need to untar and then relocate the files to the path

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

And we should be ready for the first app.

The application folder structure is going to look like this:
|-- 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

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

Notice that I specified my application name ( 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:
$ ./ daemon
[Wed Sep 21 00:13:47 2011] [info] Server listening (http://*:3000)
Server available at

Notice that the output is stating that it's listening on '*' and  What's up with that? When I did a 'netstat -ln' I only had one instance of port 3000.
tcp        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 since my server is at Rackspace. And at first glance I only saw the 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.


  1. [...] at the CPAN help for MongoDB (previously installed in mojolicious part 1) So now we have to test the connection with this sample code (I got it from the CPAN and then made [...]


Post a Comment

Popular posts from this blog

Entry level cost for CoreOS+Tectonic

CoreOS and Tectonic start their pricing at 10 servers. Managed CoreOS starts at $1000 per month for those first 10 servers and Tectonic is $5000 for the same 10 servers. Annualized that is $85K or at least one employee depending on your market. As a single employee company I'd rather hire the employee. Specially since I only have 3 servers.

The pricing is biased toward the largest servers with the largest capacities; my dual core 32GB i5 IntelNuc can never be mistaken for a 96-CPU dual or quad core DELL

If CoreOS does not figure out a different barrier of entry they are going to follow the Borland path to obscurity.

UPDATE 2017-10-30: With gratitude the CoreOS team has provided updated information on their pricing, however, I stand by my conclusion that the effective cost is lower when you deploy monster machines. The cost per node of my 1 CPU Intel NUC is the same as a 96 CPU server when you get beyond 10 nodes. I'll also reiterate that while my pricing notes are not currently…

eGalax touch on default Ubuntu 14.04.2 LTS

I have not had success with the touch drivers as yet.  The touch works and evtest also seems to report events, however, I have noticed that the button click is not working and no matter what I do xinput refuses to configure the buttons correctly.  When I downgraded to ubuntu 10.04 LTS everything sort of worked... there must have been something in the kermel as 10.04 was in the 2.6 kernel and 4.04 is in the 3.x branch.

One thing ... all of the documentation pointed to the wrong website or one in Taiwanese. I was finally able to locate the drivers again: (it would have been nice if they provided the install instructions in text rather than PDF)
Please open the document "EETI_eGTouch_Programming_Guide" under the Guide directory, and follow the Guidline to install driver.
download the appropriate versionunzip the fileread the programming manual And from that I'm distilling to the following: execute the answer all of the questio…

Prometheus vs Bosun

In conclusion... while Bosun(B) is still not the ideal monitoring system neither is Prometheus(P).


I am running Bosun in a Docker container hosted on CoreOS. Fleet service/unit files keep it running. However in once case I have experienced at least one severe crash as a result of a disk full condition. That it is implemented as part golang, java and python is an annoyance. The MIT license is about the only good thing.

I am trying to integrate Prometheus into my pipeline but losing steam fast. The Prometheus design seems to desire that you integrate your own cache inside your application and then allow the server to scrape the data, however, if the interval between scrapes is shorter than the longest transient session of your application then you need a gateway. A place to shuttle your data that will be a little more persistent.

(1) storing the data in my application might get me started more quickly
(2) getting the server to pull the data might be more secure
(3) using a push g…