pilgrimscribeshutterbugdevelopergadgeteer

object oriented approaches to web development

01.11.06

I began working on the web in 1997, starting with simple web sites and gradually growing into more dynamic database-driven web sites, to fairly sophisticated systems for e-commerce (multiple payment gateways, rebilling, fraud prevention), as well as online presence management.

But 2006 marks a significant departure for me. Until now the codebases I’ve worked on have had some division between APIs and presentation, but not the full-on MVC, and with minimal (if any) object oriented practices. This is despite my hobbyist experience with C++, Java and Objective-C. For some reason it has never hit me to go OO on the web.

Ruby on Rails got me started. Like every web developer out there, I wanted to see what the hype was about. I heard of Ruby some time ago, but never gave it a try. So I am one of those folks who learned Ruby via the Rails door. Besides working through the depot application in Agile Web Development with Rails, I moved my PHP driven personal site to Rails and added a few new features. I also attended Canada on Rails for some good wholesome indoctrination (well, perhaps not that wholesome)!

I spent five months developing a framework in ColdFusion 7, learning much about object oriented techniques on the now Adobe-owned platform. I ran into some limitations, and also discovered some jewels of the language.

I investigated Zend Framework for PHP, and as a test began porting my personal site over to see if it could handle all the routing and database needs that Rails so gracefully took care of.

In two months I learned the basics of Python and Django, and wrote two smallish apps for data browsing, PDF generation, both secured with LDAP-based authentication.

I’d like to share some of my likes and dislikes taken from the broad experience of this year.

Ruby

I began learning Ruby with “why’s (poignant) guide to Ruby”, which takes much too slow a pace for an experienced programmer. But it did help me realize just how smartly Ruby is designed. Looking at the way punctuation is used, each one seems specifically chosen in a make-sense way (eg. @ for attribute). Even the convention of consonants being capitalized like Proper Names, and variables being all lowercase. Some things take getting use to — everything is an object, and blocks can take some time to grasp. But after the initial hurdles, I found Ruby to be both a very powerful and elegant language.

Matz began developing Ruby in 1993, more than three years after Guido began creating Python. As a more recent language, he had the advantage of incorporating the best of Perl, Python, Lisp and other languages into a single language.

As a newer language, one that wasn’t widely publicized until 1998 (7 years after Python was made public), it still is maturing as far as library support and performance.

Until YARV is bundled with Ruby, performance is a valid concern. For web applications, the solution is to make good use of page caching, which everyone ought to do anyway, but especially in the case of Ruby on Rails.

I haven’t personally done enough with Ruby to run into library limitations, though some have. The existence of a Ruby to Python bridge (untested by me) is a good indication that people like Ruby but sometimes wish for the Python libraries.

My experiments with Unicode were a bit dismaying. Once I determined that I must require 'jcode', I then found that string offsets would grab specific bytes from a string, not code points as desired. Since Rubyists can easily revamp the base String class, there may be a solution out there, but certainly the bundled support is less than I expected for a programming language developed in Japan.

Ruby on Rails

Rails is all the hype these days. Not only does it provide a good skeleton to get started, it allows you to avoid writing SQL (for the most part), and ties into prototype and script.acul.us for all the AJAX and Web 2.0 goodness you could want.

I am quite happy with the direction that Rails is taking. Matter-of-factly, I had been looking into RESTful web applications and found it reason enough to not use Rails, which was driven by actions on the URL line. So I was very pleased to hear that RESTful design was a big focus of the next release. I am also quite agreeable with the core focus of Rails, and how the team slices between what is essential and what should be an add-on plugin.

My main concerns with Rails are thread safety and deployment. I can’t speak to resource usage of spawning multiple processes vs. multiple threads, so I’m not sure if the lack of thread safety is a big deal! But I must say that getting Ruby and subsequently Rails installed on my Mac and again on TextDrive with Lighttpd was no small task.

One problem was the utter number of installers and guides that just weren’t current. For localhosting, building from source following the Hivelogic guide turned out to be the best solution. A far cry from Marc Liyanage’s simple PHP installers, but not altogether difficult once you jump in.

There are many different web servers and methods to deploy Rails, and wading through all those options to find one that really works for you is a small nightmare. It also sounds a tad more complex to manage a mongrel cluster than to have a mod_python like process on Apache. Yes, we can become server administrators for our Rails apps, but it takes time, and it’s not the nicest thing to drop on someone else’s lap.

Ruby has more going for it than Rails, not that I’ve tried out the other frameworks (Nitro+Og, etc.). There are tools like Capistrano to help with deployment, and rSpec is very intriguing for applying “test- first” practices to application design. Both employ “domain specific languages”, that is, they hijack Ruby into providing an English like syntax to achieve their ends. Ruby already is very readable, and it is also very flexible, so it is quite suitable for this process.

Python

I began learning Python in September 2006 with the intention of using it for web development. My primary reason for this choice was that other developers in the organization use Python for other tasks. I was a short-term volunteer, and trying to ensure that whatever I developed had a chance of being maintained. Besides Wycliffe Canada, you’ll find Python used in many interesting places:

The Python language has many powerful features, like list comprehensions to manipulate data. It has some smart design, such as using tuples to allow methods to return multiple arguments. Tuples are the read-only equivalent of lists, and carry a performance advantage. In this way, Python feels closer to the machine than Ruby. But with dynamic typing, advanced data types, and built in memory management, it is certainly a high level language. With dynamic typing, variables need not be declared, but Python is strongly typed so it does not automatically cast, for example, integers to strings. It’s a smart approach that keeps the programmer in control.

Python’s indentation takes no getting use to at all, especially if you are using a competent editor with Python support (I use TextMate). On the other hand, a few things, like sometimes requiring a trailing comma in tuples seem to be artifacts of a not entirely well thought out language. With Ruby, Matz wanted to create a language more object oriented than Python, and it is, in fact Python didn’t even have classes in the first release. Python is already 17 years old, and that history brings some baggage as well as many benefits.

A major benefit is the Python libraries, which are really quite wonderful. Whether working with the built in support for CSV files or hashing, or using third-party libraries for LDAP or generating PDFs (reportlab), I was always impressed with what Python is capable of. Not only that, Python itself and many of the add-ons are provided as Mac OS X installers, and are easy enough to install with Debian’s package manager too.

When it comes to web development, there are many frameworks for Python. There is something called WSGI in Python, that makes it super simple to write your own web framework, and so people have. It is nice to have choices, and I like the friendly community feel. Frameworks like Pylons tie into other tools like SQLAlchemy, a very competent ORM. If you are a framework developer, Python is a nice place to be.

But making a choice does take work, and whereas Ruby has a Rails focus and many books on it, many of the frameworks for Python do not have the same level of good educational material.

Django

Django is a well known, well supported, and current web framework for Python. A simple database model will not only create the entire schema for you (yes, I never actually learned PostgreSQL while using it), it powers the wonderful “free” Administration site. Every web developer should at least take a look at Django’s admin site, which looks great and requires very little code to get going and to customize.

Why then didn’t I use the Django Admin for either of my projects? The truth is, it didn’t quite fit my needs for the simple applications I was developing. However, I was somewhat dismayed that the more advanced UI controls (e.g. the side by side select lists) used by the administration site were not available as stand-alone controls for the front-end.

While Django is on board with the DRY principle, certain areas like URL routing adhere to what I would call the WET (Write Everything Twice) principle. That was a particular pain when restructuring my Django app to be deployed under a folder. The Django folks are aware of the issue.

Despite it’s problems, Django is one of the better web frameworks I’ve seen, and holds a lot of potential. It is definitely worth watching in the coming months as they finally hit the 1.0 release and publish the Django book.

For proponents of Python, see why py? and also check out the Snakes and Rubies video.

Python itself may experience some troublesome times, as there are plans for incompatible changes in the upcoming Python 3k version. The 2.x stream will continue to be supported, but 3k could see slow adoption (as with PHP 5) while framework and library providers try to support both versions.

One change will be to make the already excellent Unicode support the standard string type, relegating all non-Unicode work to a special binary format. Many of the other changes are to remove the baggage of now deprecated features, and to fix design mistakes made in the beginning. It’s good to see that the Python community is not-at-all resting on their laurels.

PHP

Back in 2000 I was playing in PHP 3.x, and soon after version 4.x. Of course my code was always in typical PHP fashion, procedural and mixing everything together. In 2005 I read through the PHP 5 manual, learning about the new objected oriented features, but I never put it to good use. One of my experiments was with multibyte (specifically Hebrew) text, which I did manage to get the basics working, though PHP’s support for Unicode remains quite abysmal.

The PHP language may not be as expressive as Ruby or Python, but it is an easy to learn language, very C or Java like. What is ugly about PHP is the API, which feel like a hodgepodge of libraries from many sources, and too great extent, I suppose it is. Along comes Zend Framework, with the promise of a nice clean object-oriented interface.

Zend Framework

This August I began working with Zend Framework, a really great community project that Zend started up. As an experiment, I derailed my personal site by porting it to ZF. At least I tried — I got the routing working but ran into trouble with the “topic tree” which helps categorize my list of articles. In Rails this is achieved with acts_as_tree in the model, and :include => [:topic] while retrieving the article list. No such facility in Zend Framework, at least not yet.

Later, when beginning a small project which would generate PDFs, I took a look at Zend Framework again. What I found was a pretty nice looking API that unfortunately didn’t support wrapping of text. On the other hand, reportlab for Python is at version 2.0, and not only handles wrapping paragraphs, but can shrink the font if the text doesn’t fit, along with many other features. I also found Python had good built in support for reading in CSV files with line breaks within fields and double-quote mark escaping. While PHP could’ve worked, Python quickly became my choice for the project.

The big problem with Zend Framework is that it’s still fairly young (version 0.15). It would be a great project to get involved in, but at the time I wanted to focus on my project and not building frameworks.

What I’ve found is that my interest in PHP really has little to do with PHP itself. I like the fact that I could become certified, which should help with employment. I also have an interest in Hebrew and perhaps going to Israel one day for work or study. Zend happens to be based out of Israel, and usually has openings there. Finally, PHP is a huge community, where it would be possible to get involved and help out a lot of people!

I am indeed looking forward to PHP 6, which is going to rock! Andrei Zmievski is an employee of Yahoo! and is studying linguistics. He is one of the main people working on Unicode support for PHP 6, and it is amazing what he’s doing. PHP is at the bottom of the heap for Unicode right now, but with all the work Andrei and team are doing, I suspect it will be the best thing going for some time. They are even doing transliteration!

ColdFusion

I’ve spent six years of my life employed as a ColdFusion programmer, and have even changed jobs to stick with ColdFusion rather than jump to Java (okay, there were other reasons as well).

ColdFusion’s tag based syntax is easy for HTML coders, and is great for a company with a split between HTML-based designers and web application developers. The developers can do all sorts of backend work, and create a simple set of tags (or taglibs) for the designers to use. But during development, the tag based syntax can feel overly verbose, and the CFSCRIPT-based scripting language is restrictive in that it doesn’t allow tags to be called.

ColdFusion is designed for web application development, so I have worked with it directly most of the time. I have looked at Fusebox and Mach II a little, but there are many other frameworks I have not tried. Since ColdFusion has a single purpose, it can be finely tuned for that purpose. On the other hand, the team behind ColdFusion is charged with providing a language and the related libraries. ColdFusion feels higher level than other languages, and in many ways that makes it nice to work with, but in other ways it is limiting. It just depends what you’re trying to achieve.

Adobe ColdFusion and even NewAtlanta’s BlueDragon are of course commercial, setting CFML apart from the other languages discussed (PHP’s Zend tools make it slightly commercial, but still it is mostly free). It fills some needs quite well, but in other cases a free open source platform provides a more powerful solution.

So where do I go from here?

ColdFusion

As far as employment, I mainly have seen opportunities with ColdFusion. To that end, I’ve been assisting with cftextmate, to provide ColdFusion language support for TextMate, and also to learn TextMate better.

If I do find employment using ColdFusion, it is quite likely that I will focus on CF somewhat exclusively. I may give my ORM a second go, and perhaps look into porting routes and rSpec to the CF side. I’d likely spend some time looking at XmlHttpRequest object, JSON and the many Web 2.0 pushing frameworks. Basically, I would spend my extra hours working to bring cool stuff to ColdFusion.

Rails 1.2

If left to myself, I will likely focus on Ruby on Rails with plans of starting a new project. The 2nd edition of Agile Web Development with Rails is nearly out of beta. Reading through that should provide a good refresher, and fill me in with all the new developments and the things I never got to in the 1st edition.

ActionScript 3

As a total aside, I spent an evening learning about ActionScript 3 which is included in Flash Player 9, and has a command line compiler bundled with the free Flex 2.0 SDK. It seems Adobe has cleared up many of the problems plaguing Flash developers of the past, and I am very interested in learning more about it.

I’m sure such experience could play into web application development, but my interest lies entirely in gaming. Ever since the days of Galaga, I’ve had the childhood dream of becoming a game developer. I’ve been involved on many small side projects, but nothing was much of a success. Flash can make a small game easily accessible to many, many casual gamers through the web. It has a lot of potential, and I’m sure I’m not the only one who has seen that.

Flash has tended to be expensive for development, and I never did like their GUI. Adobe LiveMotion seemed better in many ways, but never took off. Perhaps Adobe/Macromedia will make major headway for the 9.x release. But for now, I’m especially interested in what can be accomplished with the free tools.

In Summary

All said, I have learned a great deal from this years’ foray into web frameworks. I now have the knowledge to choose the best tool for the job from a wider range of possibilities. If the platform is fixed, then there is the possibility of “porting” some of the good ideas to another language. Regardless of which tools and projects I end up working on, I’m very much looking forward to improving my development practices. That means object- oriented, test-driven code that is easier to maintain. Amen.

Copyright © 2008 Nathan Youngman. All rights reserved.
feed me