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 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
- Fashion Galleries
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: https://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.