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.

Dear Diane Mueller,

I’m getting pretty frustrated by the approach that Active State is taking on this Stackato beta process.

I applied for a beta when you announced the product.

You sent me an e-mail that said “If you are able to test using a VM (which is how we’re currently offering Beta), please reply to this email to let me know, and I will send you details on how to access the Stackato Beta.” on July 14th.

I replied saying “Yes, I’d like to test.”

No response.

Now I read about this contest.

But, when I go the contest page, I’m asked to sign-up for a beta code.

But I’ve already done this.

Today you send me an e-mail about the contest; it signs off with “Download Stackato VM and get started now!”

When I click that link, I’m taking to the same page that asks me to sign-up for beta access.

You see the problem here, right?

This system is broken. I sincerely hope that your new product is not as broken as your beta process.

Best regards,

Phillip.

Cross-posted from blogs.perl.org.

This past weekend I dusted off my copy of Sam Tregar's Writing Perl Modules for CPAN. The book was published in 2002 and that gave me some trepidation about re-reading it almost nine years later. However, I not yet written a CPAN module and I wanted to give it a shot -- so this seemed like a logical place to start. Thankfully, any reservations were misplaced: this book should be on the shelf of any person wanting to expand their Perl repertoire.

Here's a quick summary of what really stood out for me this time:

• Chapter 2, incorrectly titled "Perl Module Basics," should be a must-read for anyone new to Perl. It answers all the burning questions about Perl modules. Specifically, why modules are an improvement over one-off scripts almost 99% of the time, the difference between compile-time and runtime in the life of a Perl program, the concept of Packages, Symbols, Encapsulation, Object-Oriented vs. Functional style modules, Classes, Accessors and Mutators, Inheritance, Overloading, and much more. I've rarely read a programming book chapter so full of valuable information and so clearly written.

• Chapter 3 covers "Module Design and Implementation" and does it quickly and thoroughly. It starts with an explanation of Plain Old Documentation in the context of a documentation-first approach to module design, and then quickly jumps into design decisions like functions vs. objects, naming, and parameters and return values. With that information delivered to the reader, it jumps another level deep and provides a thorough exploration of inheritance vs. composition and the challenges of dealing with multiple-inheritance, and then wraps up with a quick overview of how to visually map out a module's design with UML.

• Chapter 5 delves into "Submitting Your Module to CPAN," and is a good read for the process-related concerns of getting a module submitted. It touches on how to get feedback from the Perl community and the nitty-gritty details of the PAUSE upload process. Of course, being from 2002, it could use a quick refresh and a section on newer tools like Dist::Zilla.

• Last but not least, Chapter 7 -- "Great CPAN Modules" -- is a worthy read. Sections on DBI, Storable, and LWP are particularly noteworthy, while others like CGI.pm could be updated with newer examples, and -- generally -- there are a number of great CPAN modules that could be unpacked here for the reader's benefit, e.g.: modules that take advantage of Moose, and perhaps one of the event-loop modules.

Obviously, that's just four chapters out of eleven that hit the mark. But, nonetheless, I would still recommend the book as a great resource just for those chapters alone. However, the rest of the book is not without value -- just a bit outdated for the era of "Modern" and "Effective" Perl. Specifically:

• I'm guessing that most folks would agree that h2xs is a bit outdated, and that people should probably just jump right into reading about module-starter or Dist::Zilla instead.
• The chapter on module maintenance and community could be updated to include mention of blogging, Twitter, and, most importantly, Github, as ways to build community, find contributors, and manage patches.
• The last three chapters are all devoted to various ways to write CPAN modules in C, either using XS or Inline::C, which didn't feel as contemporary or timeless as other chapters. (That said, I've never wanted to write a Perl module in C, so maybe it's just a topic that doesn't interest me.)
• Writing Web applications in Perl is relegated to the last chapter, but seems to be a pressing concern "with the kids" these days. It could easily be presented earlier and be updated to include sections on Catalyst, Dancer, Mojolicious, and Plack.

In summary, my sense is that Apress could fairly easily update this book for 2011, and that doing so would make a great resource for years to come. I must admit, I enjoyed Sam Tregar's clear, simple writing enough to almost forgive him for leaving the Bricolage project to work on Krang (inside joke).

So, what's on your Perl back catalog reading list these days?

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