Modern Perl

Planet Iron Man

Planet Iron Man

http://ironman.enlightenedperl.org/

Following matt’s post about people not blogging enough about Perl, I’ve decided to try to post once a week about Perl. So I will start by a series of articles about what we call modern Perl. For this, I will write a simple feed agregator (using Moose, DBIx::Class, KiokuDB), some tests, and a basic frontend (with Catalyst). This article will be split in four parts:

Catalyst - Web Framework

Catalyst - Web Framework

http://catalystframework.org/

The elegant MVC framework Catalyst will make web development something you had never expected it to be: Fun, rewarding and quick. New Book! Jonathan Rockway's new Catalyst book, published by Packt Publishing, is now available for purchase. Get it now!

Why I use Moose, Perl's Post Modern Object System

The following is an edited and updated version of a Moose advocacy bit I wrote on the Google AppEngine for Perl project mailing list quite a while ago.  I decided to republish it here since with the recent release of Catalyst 5.8, which uses Moose as a core technological foundation, I felt it would be a good idea to reflect on why I think this is a great thing.  There are quite a few tutorials and code overviews for why Moose is a superior object system (links at the end of the article) but I don't see many postings that are simple reflections on Moose and why I, as a developer, am happy it belongs to Perl.

I also think the Google AppEngine for Perl project is not getting nearly enough love and I'm hoping to draw a bit of attention to it as well.

You can read the original here, but that version has an embarrassing number of spelling and grammar errors :)

Without Moose, I'd probably have lost the faith and left Perl for another language.  This is not a lightly written statement, since I've been using Perl as a primary server side development language since 1996.  When I first started programming I gravitated toward Perl for two reasons:  First, it let me do what I needed to do without getting in the way or forcing me to jump through a lot of hoops.  Second, it introduced me to what is now broadly thought of as the Open Source community, an idea of how software development and knowledge sharing could be that excited my idealistic nature.  I have to imagine there are quite a few programmers in Perl with a similar story.  A lot of us started using Perl because the module CGI made it trivial to create server side web forms, while DBI created a straightforward means to shuffle information between the web and back end databases.  Perl did what I needed it to do.

However, over the time, my love affair with Perl diminished.  Perl's default Object Oriented system is very minimalistic and I found myself envious of languages that allowed --and even encouraged-- a best practices approach in modeling your application.  For the first time I started to feel like Perl was getting in the way of me just doing what I needed to do, mostly because I was spending a lot of time jumping through hoops and not expressing my problem domain.  Even worse, this lack in Perl caused many large projects to create there own ways to close the gaps left open by existing methodologies.  How many different and incompatible component systems have been written for Perl?  How many systems for making it easier to do object oriented programming?  And each time you go to load a new module from CPAN, you end up also loading a bunch of dependencies for yet another half baked OO framework that is only being used on a handful of projects.  This reality makes it much harder for newcomers to usefully contribute code, since each time you have to learn a new underlying framework and all its idiosyncrasies.  That's why most important Perl CPAN modules have at most a small handful of contributors.  Worse, if fed the common belief that Perl is spaghetti code not suitable for larger applications.  Now, I do think having competing ideas is good, and that value is one of the things that makes Perl strong, however for basic, core programming tasks the lack of consistency really hurts us.  Where would Perl be if CGI had not been so complete, or if DBI did not become the dominate method of accessing databases?

Moose has reinvigorated my love for the Perl language, it's community and programming in general.  It cleanly solves the problem of Perl's minimal OO features.  I write less boilerplate and spend more time expressing my problem domain.  It provides a wealth of expression around which a rich economy of best practices and shared solutions can grow.  Additionally, since it's written for programmers by programmers, I find that it fits my brain better than any other ivy tower OO solution.  It has a large and growing community of active developers, more than any other competing system OO framework for Perl AFAIK.  Lastly, some of the most important Perl projects of our day, such as Catalyst, DBIx::Class, etc are either using Moose or moving toward Moose.  For me, Moose makes OO Perl just as expressive and fun as I found Perl to be when I first started writing website applications all those years ago.

Is it perfect?  No, certainly there is a lot of room for Moose to improve.  However, all the right decisions to let those improvements happen have been made.  The developer community is very serious about feature enhancements and about growing adoption of the framework as well as growing the number of contributors.  I am a case in point, since although I've been using Perl for more than 10 years, Moose is one of a small number of projects that I've managed to become involved at the contributor level.  Moose not working the way you need it to?  That's fine, come to IRC and make your case.  However, I would encourage to do your homework first, since the Moose channels have some of the brightest minds I have ever had the chance to see in action.

For me, properly written Perl starts with Moose.  It should serve as the basis for any serious project you may be about to undertake.

• For more about Perl.
• For more about Moose.
• The Official Moose Learning Manual
  
• For more about the Google AppEngine for Perl project.

Great Interview about the Latest Catalyst Release

Here's an article you might have missed.  Nice summary of the main features of the 5.8 version of Catalyst.

Matt's Iron Man Contest

If you wanted a reason to blog about what you are doing with Perl, here's another: 

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. 

 

Catalyst 5.8001 has shipped!

More about this coming soon, for now you can read the official delta list.  This marks the end of the Catamoose project, since now Catalyst is officially stable on the Moose object oriented framework and its all just Catalyst now.

What's more amazing, I installed it in development for my $work website and it just ran fine after a few tweaks (mostly things we did out of laziness that had been long marked as deprecated.

Again, will blog more once I play with the final release a bit.  Tremendous thanks to the spirited group of volunteers that worked to make this day happen.

Hopefully DBIC will follow soon with a major stable release as well.

-- UPDATE --

DBIC has gone stable as well!  Find the latest and greatest here.