BlueChild: End to End development of a Perl Catalyst Website

Now that the Moose version of Catalyst is out (see previous posting), and we are nearing a stable DBIC (the last few release candidates/Betas have powered Takkle without any real problems) I'd like to start a new project to showcase these technologies as well as document some of the best practices for application development that I've seen evolve in the Perl community over the past few years.  Additionally, I plan to make this a complete, 'end to end' project, including how I setup my development instance and structure my application, which seems to be an item where a lot of Perl newcomers feel confused.  I plan to eventually deploy this to the cloud (probably Amazon EC2) but will develop on a local virtual machine to start off the project.

I'm not going to build a bunch of contrived demos designed to show off the framework in the best possible light while simultaneously serving to obscure it's gaps and weaknesses.  Those might make nice screencasts but anyone doing real development can see through the smoke.  I'm going to build a real application which hopefully will go live sometime before the end of the summer 2009. While I build the application, I will blog about it and the source will be stored on github which will allow you to follow along.  Also, I am hoping to get feedback from some of the Catalyst/Moose/DBIC cabal as I go along, and perhaps pick up a few patches from readers like you along the way.  I am hoping to make this a dialog; when I say or do something you think is a bad idea, or is a practice that has fallen out of favor, I hope you speak up and correct me.

The Application

The application I will build is a website dedicated to (from the business documents) "showcasing indie fashion, bargain shopping and import or export of fashion merchandise between the USA and China."  I'm building this application for my wife who for whom fashion is a hobby.  She also has a long term interest in possibly leveraging her manufacturing connects in Southern China (she's a Chinese National living in the United States.)  Building this application is something I've spoken with her about for quite a while, but have not had time to work on it.  Now that I am hoping to combine the work for her along with my desire to help promote Perl Catalyst applications I can combine the free time I have available to meeting multiple needs.

I'll detail the business requirements in a later posting, but I want to point out that its definitely a best practice to make sure all the requirements, features, scope limitations, etc. are in place before you make any technology choices.  This is something you need to insist upon from yourself, as well as from your business partners.  A quick feature summary, just to help you orientate yourselves:

• Owner Blogging and limited content management features
• Forums
• Fashion Galleries
• Ecommerce
  

Why Build?

So, you might ask, why build an application when there might be several preexisting 'kitchen sink frameworks' that could be modified to meeting a reasonable percentage of the business requirements?  For example, some of the content and social networking features could be solved with something like Movable Type.  Are we building this just for vanity purposes? 

I think (as I imagine many of us developing in Perl) that unless one of the big, "everything and the kitchen sink" CMS+social networking systems contains everything you want out of the box it's better practice to loosely glue together existing components (CPAN), refactoring where necessary, to achieve the architecture goal.  You'll always end up with a more flexible and maintainable system, in my opinion.  This predisposition comes from a lot of experience I have consulting for companies where someone had decided a lot of money could be saved if they tossed out all the custom development in favor of a large package bought from some provider, typically with a multi-year maintained package.  The promise is that the system will do everything you need either via configuration or development of plugins.  Typically this works until you need the system to do something new, like integrate with Facebook Connect, Twitter or whatever happens to be the need of the day.  You inevitable end up hacking ugly shims into the code (if you even have the code available) to meet a requirement. The more you add in and hack the harder it becomes to make further changes.  Then one day you wake up and find your code base has not only forked so much as to be unrecogizable, but that designed choices and compromised made to fulfill the original requirements have so hobbled you that it's nearly impossible to add in new functionality without breaking stuff you already have.

In this case, since I know I am planning to use this system to play with some ideas I have for building related applications for the iPhone and a few other things, I want a minimal codebase that cleanly expresses the basic business logic.

This is not to say I think it's best to write everything from scratch.  That's not the Perl way either.  So I will be leveraging CPAN to the max, and as I develop when I identify code that could be better expressed as a new CPAN module, I'll cut a subproject and build it that way.

Basic technology choices

I'm going to use git for source control, and the application will be under an opensource license on githut.  I choose git because many of the projects I contribute to (Moose) are on git and there's talk of moving Catalyst and DBIC as well, so I need a clean project and an excuse to learn this system.  For initial development I will use SQLite for the database since that's trivial to run and gives me an excuse to shake down some of the new development taking place on DBD::SQLite  I'll use the latest and greatest Catalyst, and my ORM will be the latest release candidate of DBIC, with the hope that project will move to stable sometime shortly.  Otherwise, I'll pick technology as needed to solve particular problems.

Follow along on github at: http://github.com/jjn1056/bluechild/tree to see the current source.  Should be checking in the basic project skeleton shortly.

The next posting for this will be entitled "BlueChild: Getting Started with a new development instance of Catalyst" and will include information on how I cut a virtual machine, set it up and created a basic project. 

 

Comments

[Mark]

[this is good] Well John the reality is that many developers need to try out ideas first in a virtual hosting environment, where they do not have root.This has often been a big stumbling block because of developers who do not think to test the framework in this kind of setup. Thus you get modules that, when passed the proper build switches, install themselves in places like /usr/local/lib/perl/usr/local/lib/perl/lib. I hope you will consider doing a run-through on a virtual hosting environment to work out the non-root install bugs before declaring victory with your showcase series.

[John Napiorkowski]

In my next blog post I will show how I typically set up a new virtual machine with a deployment geared toward situations where you don't have root. So definitely fitting this bill is very important.I do have to say though, with the cost of cloud instances falling so low, it's becoming less of an issue to have to deal with these kind of shared setups. For my side consulting work, these are almost always legacy situations. But I will definitely discuss. Thanks for bringing up the issue and please watch my blog to make sure I am good to my word.

[Mark]

I suppose I'd like to draw a distinction between a virtual machine (where you can have root) and a virtual host server (pair.com, he.net, nearlyfreespeech.net, to name a few), where you normally don't. Virtual host accounts generally go for $10 / month or less, whereas something like an EC2 instance would cost $35 and up (haven't checked prices a while, but they used to be $70 / month).It is indeed becoming less of an issue, but $35 a month versus $0.35 a month (for nearlyfreespeech.net, when traffic is light) is a BIG difference to me.The difference between doing it on a VM on your own machine versus doing it somewhere with a real IP address, is you can roll out very small services that are not going to support higher hosting fees.

[John Napiorkowski]

I think we can clarify the goal is to make sure we develop in such a way and to make it easier to deploy to shared hosts if necessary, but also not hamstring yourself if you can move up to a full virtual host or cloud instance. Ideally you'd be able to instance all third party cpan modules into your own locally controlled perl lib area. That way you can avoid some of the trouble with not having root on many of the shared servers.There is also the possibility of compiling your own local perl, but many shared server hosts will object. Sometimes it helps to ask very nicely for permission. If you can demonstrate technical competence and if you are polite, you can often talk your way through to a solution that meets the need.

[Marty Brandon]

Great idea John. Looking forward to your posts. I'm a researcher who has used Perl for nearly a decade, but I often get a little discouraged trying to choose a good combination of packages from the CPAN and implementing them using "best practices". Though there are many good books and a supportive community, nothing beats seeing a working example that includes explanation of why things were implemented the way they were.

[John Napiorkowski]

My next part should be out later today or tomorrow. My plan is to have a lot more text and discussion / explanation than you get in a how to. Thanks for checking in and place feel free to ask questions when something is not clear.

[Khandielas]

[this is good] I have been using Perl in my work for about 8 years, but have not got chance to do web developing. So when I want to do a website for myself, I found there are tons of things to learn. There are many blogs, site generators, blah blah, but I just want something of my own. I am learning Catalyst now. Your work will be a great help if you can show us from A to Z.BTW, I like your 'suit', style of 'Qing' Dynasty, isn't it? And the color 'yellow' was only for royal family.

[John Napiorkowski]

I'm not sure if it's Qing Dynasty style (my wife's away and she'd know) but yes, I'm wearing the Emperor yellow :) This was part of a series my wife and I took after we got married.I'm catching on on the next part of BlueChild, I got side tracked a bit with some Catalyst related advocacy work. Also, as I pointed out, I'm trying hard to cover all the gaps. Hopefully people like you will say, "Hey, I don't get it" and of course hoping some of the the other experts around correct me when I got off on something silly.