Cross-posted from blogs.perl.org

Following up on my previous post that demonstrated how to get a basic Catalyst application up-and-running on dotCloud in under ten minutes, let’s explore how to take things a step further by adding a database service.

For convenience sake, I’m just going to walk you through the Catalyst::Manual::Tutorial.

However, unlike the tutorial (or most Catalyst tutorials for that matter), we’re going to use PostgreSQL instead of SQLite — and we’re going to deploy the app into the cloud vs. just developing locally (thanks to the magic of dotCloud, which makes it so easy).

Luckily, it looks like the Catalyst::Manual::Tutorial Chapter 3 has been updated with a PostgreSQL-specific appendix, which makes things a lot easier (and means that I can spare you from my terrible SQLite-to-PosgreSQL conversion skills).

Here we go:

• Following along with the tutorial, we go ahead and add Catalyst::Plugin::StackTrace to the base application module and the Makefile.PL, which ensures it will get auto-installed and built by dotCloud when we push our app. Here’s the commit on Github.

• Next, we use the Catalyst::Helper script to create a controller for ‘books’ (and a simple test), and update the controller per the tutorial. Commit

• Then, using the Catalyst::Helper script again, we create a simple view called HTML that will use Template Toolkit as its rendering engine. Finally, we set the component path to let the application know where to find the templates. Commit

• Last but not least, we create the TT2 template to accompany the /books/list action. Commit

Now we diverge a little bit and head over to the PostgreSQL appendix and create our application’s database for managing books. This assumes that you’re familiar with PostgreSQL, have installed the PostgreSQL server and client and the Perl DBD::Pg module.

• So, working locally for now, let’s create a user for this application and then a database per the instructions.

• The data file provided by the appendix had a couple of typos, so I fixed this up here. Use that data file and load up your PostgreSQL database and check that everything loaded properly.

• Next create the some DBIC schema models with the assistance of Catalyst::Helper::Model::DBIC::Schema

This creates the application’s database model files automatically from the database tables and relationships; see this commit.

• Now, with the models auto-generated and some data in the database, we need to enable our model in our ‘books’ controller. Commit

At this point, you can check out your application locally to ensure that everything is running. In fact, this is a good point to mention a Catalyst development trick: If you run the development server with script/appname_server.pl -r option, the server reloads when you update an application file. Thus, if there’s an error, you can see it right away. I usually leave this window with the server output visible next to my editing window. Good for caching typos right away.

• Okay, so finishing up, we configure the HTML view to use a ‘wrapper’ (think header, footer, etc.) for our action-specific views, and we add a CSS file, etc. Commit

• Even though we’re not going to use them yet, to stay consistent with the tutorial, we update generated DBIx::Class result class files for many-to-many relationships. Commit

• Update the books/list view template to include authors. Commit

Great. That was all pretty straightforward, so let’s deploy this on dotCloud:

• Add the additional requirement DBIx::Class to the make file. (In fact, I forgot a few requirements along the way — typical! — so let’s also add: Catalyst::Model::DBIC::Schema, DBD::Pg, Catalyst::View::TT, and MooseX::NonMoose. Curiously, I thought that MooseX::NonMoose should have been built as a dependency of Catalyst::Model::DBIC::Schema, but wasn’t … so I had to add it manually to the Makefile.)

Okay, now for the fun part, let’s add a PostgreSQL data service to our dotCloud instance by adding a couple lines to the dotcloud.yml file (Commit) as described in their documentation on PostgreSQL. Pretty simple, eh?

Now, let’s deploy these new files to dotCloud (note that our Catalyst application and the new data service are not connected yet) with dotcloud push catalyst . and watch dotCloud do it’s incredible magic of installing all of the CPAN modules that your Catalyst app needs. It really is magic.

If all goes well, you should see:

Deployment finished. Your application is available at the following URLs www: http://9f385357.dotcloud.com/

Run dotcloud info catalyst.data and you should see something like:

Now, you just need to connect up your new data service with your app (well, almost, we’ll still need to create the remote database and load it with data). To do that, you can either put the database connection info directly into your lib/MyApp/Name/Model/DB.pm file, or read it from the dotCloud environment.json file.

However, at this point, if you put your dotCloud database connection info into your app your local development version is going to complain loudly and will stop being useful as a way to see what you’re doing before you push the app to the cloud. So, this becomes a good opportunity to get our local environment set-up to be as similar as possible as our cloud environment.

On dotCloud, the database connection information is automatically put into a handy environment.json file at the root of our dotCloud environment (/home/dotcloud/). So, to make things easy, let’s also create a environment.json file at the root of our application directory. So, my application root now looks like this:

And I set my local version of environment.json to match the variable names that dotCloud provides, but with my local connection information, like so:

Okay, we’re in the home stretch now! So, to finish things off:

• To read these environment.json files, we can just add the handy JSON and IO:All modules to the Makefile. Commit

• Now we can update our Model::DB file to read the environment.json on dotCloud if it exists, or to fall back to our local version if not.

• We’re all set now to actually create the database (earlier, we simply created the data service). We’ll do that by running dotcloud run catalyst.data -- createdb default-catalyst. Note that this is using version 0.4 of the dotCloud command-line client — future versions might change this format. The .data targets the command to run for the data service that we set-up (vs. the www service running the app). If that all worked, you should see: # createdb default-catalyst

• Last but not least, we load the data from our local development environment to the cloud database. There are probably other (possibly better!) ways to do this, but I found this approach straightforward: su - postgres and then ./bin/pg_dump default-catalyst | ./bin/psql -h XXXXXX.dotcloud.com -p XXXXX -U root default-catalyst. Obviously, replace the Xs with the sub-domain and port of your data service.

With all of that done — phew! — we can run one last dotcloud push catalyst . to push the latest changes to into the cloud, install any remaining dependencies, and restart nginx. If all went well, you should see:

• The Catalyst welcome screen here: http://9f385357.dotcloud.com

• The database-connected book list here: http://9f385357.dotcloud.com/books/list

Hopefully your PostgreSQL-backed app is now running in the cloud. Hurray!

If you find an error in this post, or have improvement suggestions, please let me know in the comments.

P.S. If your app is not running, the one thing to check that tripped me us is how dotCloud integrates with git. They key take-away is: be sure to commit your changes to git, or dotCloud won’t pick them up! Personally, I found this a bit confusing, and — in the future — I’ll probably use the dotcloud ssh catalyst.www command to do my dotCloud-specific debugging on dotCloud and then manually bring those changes back into the local version and then commit the changes. Without doing that, I ended up with a lot of unecessary commits in the repository as I futzed about with a connection issue.

Cross-posted from blogs.perl.org. Feel free to comment here, or on the original.

Cross-posted from the New Internationalist Tech blog

A couple of years ago I started looking at options to deliver common “front end” functionality for sites using Bricolage, the content-management system that is used at New Internationalist

Initially, what I had in mind to provide this front-end functionality was a “swarm” of micro-applications, where each little application provided one simple, specific, function, e.g., user registration, comments on content, voting and rating, sharing content, etc. There were other people thinking along these lines too, and – eventually – I came across the MicroApps project, which stated its philosophy as: 

MicroApps are small REST applications that are designed from the ground up to be integrated with other applications. Usually, they are not directly useful on their own, but must be integrated into other applications (this is what differentiates a MicroApp from a regular REST application).

Unfortunately, the project appeared to be at a standstill, and my experience with Python was pretty limited. Most of my experience is with Perl, so my investigation headed in that direction, and eventually lead to the topic of this post: Perl Web frameworks. 

While they may not often be used for micro-applications, Web frameworks are all the rage. You’ve probably heard of Ruby on Rails, and you may have even heard of Django (a Python-based Web framework) or Symphony (PHP). Put simply: these Web frameworks aim to make Web application development faster and commonly “bake in” some best practices. 

Yes, Perl has CRUD too

Perl, though frequently dismissed by the youngsters, is not a language that likes to get left behind, and there are now several Perl Web frameworks to choose from. 

Around the time of thinking about micro-applications, I stumbled on Jifty. Jifty was developed by Best Practical – an established software company in the Perl world – and was used in the production and delivery of their Hiveminder application. 

I had heard of Gantry, Maypole, and Catalyst (and – of course – CGI::Appliation) but I had not really given them much attention until I first read about Jifty. 

Fast forward to 2009. We’re underway with a number of initiatives of strategic importance to the New Internationalist – re-launching NI’s various Web properties – and so it’s time to start thinking again about the technologies that will carry NI forward. 

My colleague Charlie had been recently experimenting with Jifty and Catalyst, and – in the interest of the experience to be gained by getting one’s hands dirty – I also decided to jump in and re-explore the state of Perl Web frameworks. 

This time I thought I’d look at the three most active, or promising, options: Catalyst, Jifty, and Mojo/Mojolicious. (I also took a pretty close look at CGI::Application, but decided to pass on that for now.)

So, far from an evaluation, I thought I’d just jot down my first impressions of where these frameworks are by exploring how easy it is to get up-and-running and working through their tutorials. 

Catalyst

My development environment for this adventure was VMware’s Fusion on a MacBook Pro and a stock Debian 5.0 “Lenny” installation. 

I started with the Catalyst installation documentation and followed their instructions for an installation using aptitude. Though the basic installation went well, it seemed to leave me with many missing modules, including Catalyst::Devel (which is odd, as that appears to be a rather critical piece). After various attempts to create an application skeleton or start up the Web server, I was able to get the various missing bits installed via CPAN and to get everything working. On to the documentation and tutorials…

My first impression was that the documentation was very well maintained. The tutorials are abundant and thorough, and make attempts to address the various versions of Catalyst that are out there in the wild. Thanks to the tutorials, I was able to get a simple test application set up relatively quickly. 

However, what Catalyst makes up for in documentation, it lacks in simplicity. As the Catalyst documentation states:

Catalyst is designed for flexibility and power; to an extent, this comes at the expense of simplicity. Programmers have many options for almost everything they need to do, which means that any given need can be done in many ways, and finding the one that’s right for you, and learning the right way to do it, can take time. TIMTOWDI works both ways.

Compared to the competing Perl Web frameworks or Web frameworks in other languages, I found that Catalyst required more effort to get started and doesn’t provide an out-of-the-box experience. Not a bad thing but a consideration nonetheless. 

Jifty

For Jifty, this time I went with the suggested apt-get install route to get things downloaded and installed. Unfortunately, the first thing I ran into was this rather intimidating warning:

WARNING: This key is not certified with a trusted signature!

Moving right along, I installed the package anyway and tried to set up my first application. Like Catalyst, I was presented with various errors about missing modules. One Google search and several CPAN installations later, as promised, I got a Pony. 

One nice thing that Jifty gives you out-of-the-box is an administration interface, making it easy to start adding test data to your model. The other really helpful thing that Jifty provides is, well, everything. Part of what makes Jifty so cool is:

Out of the proverbial box, Jifty comes with one way to do everything you should need to do: one database mapper, one templating system, one Web services layer, one AJAX toolkit, one set of handlers for standalone or FastCGI servers. We work hard to make all the bits play well together, so you don’t have to.

Which means trading off options (as in the case of Catalyst) for simplicity.

Jifty’s documentation is a little rough around the edges, but the tutorials are up-to-date and I was able to get my test application running and doing fancy, AJAX-y, stuff in no time.

Mojo/Mojolicious

Mojo is a “A next generation Web framework for the Perl programming language” and Mojolicious is a MVC framework built on top of Mojo. The primary author of Mojo – Sebastian Riedel – was one of the founders of Catalyst and, with Mojo, he sets out to create something more like Jifty – or, if you prefer, “the Web in a box.”

Mojo was by far the easiest to install: just a straightforward tarball to download and a few Perl “make” commands and Mojo was up-and-running. 

Unfortunately, the fun stops there at the moment. Mojo is very new and provides fairly limited documentation to work from. And, idling in the IRC channel, one can see lots of activity and signs that there is much work to be done before Mojo becomes a practical alternative to Catalyst or Jifty. However, once it does, it’s going to be one to watch. 

Conclusions

So, a few parting thoughts on my exploration of Perl Web frameworks:

• I worry that some of the installation issues I ran into will discourage other people to try these incredibly powerful frameworks. It’s been years since I’ve looked at any of the competing frameworks in other languages, but my guess would be that most installation issues are ironed out and the process is dead-simple. 

• However, any time I ran into a problem, I was able to hop into the IRC channel for the project and find friendly and helpful advice. All three project’s channels are active and filled with idling contributors. 

And, for me, the current prize goes to Jifty for being friendly to developers of all experience levels. For rapid application prototyping, Jifty makes the set-up process fast and easy, provides a full stack for application development, and makes a lot of relatively unimportant decisions (database mapper, Javascript toolkit, templating language, etc.) for you right upfront. 

I’m anxious to see what Charlie comes up with during his explorations of the same. 

Cross-posted from the New Internationalist Tech blog. Comments? Please post them over here.