Take this scenario. A company I once worked for had what can be described as a business directory built upon a licensed, yet bastardised, version of a popular ColdFusion-based CMS. It didn’t work that well! The decision was made to redevelop the application in Java. It took two years to reach the same level of functionality! What happened next? Ruby-on-Rails is what! The rest is history and beyond the topic of this post.

So, in effect, the application almost went full-circle in its development paradigm — both ColdFusion and Ruby-on-Rails can be considered Rapid Application Development environments, Java, certainly not. Why did the decision makers not stick with ColdFusion and put time aside to actually build it properly in the first place? To put it simply, they lost faith in ColdFusion; it was largely mis-understood.

The weakness of every programming language does not lie with the language itself per se — albeit it can have an important influencing factor — but rather with the ability, or indeed inability, of the developer to leverage the language in the most efficient and optimal way.

ColdFusion, like every other programming language has had and I’m sure still does have its fair share of poor developers; those people simply working with it as a means-to-an-end, rather than those passionate about the language, those people programming without understanding the fundamentals of programming or the implications of their poorly written code. This is apparent from .NET to Java, ColdFusion to Ruby, JavaScript to ActionScript.

Let’s not dilly-dally, bicker or insult one another about which is best, which one is dying and which one is not worth the computer it is compiled on. What is important is to understand the merits of each language and decide which one best suits the application, not only in technical terms, but also in terms of time-to-market, cost of development, availability of a skilled workforce etc.

ColdFusion, whether rightly or wrongly in some people’s opinion, can sit proudly amongst its peers and provide a truly compelling alternative.

Here’s how (in no particular order):

1. Low Total Cost of Ownership – frequently, ColdFusion is described as expensive, it simply isn’t especially if you consider the natively supported functions. But to put it bluntly, if your company cannot afford the cost of ColdFusion standard, or indeed ColdFusion hosting, you have bigger things to worry about regarding the profitability of the company; you won’t be able to afford much of anything! The problem becomes not the product. ColdFusion applications are quicker to develop and developers are vastly cheaper to employ than their peers in Java or Ruby, just look at ITJobsWatch for examples.
2. Rapid Application Development – ColdFusion vastly simplifies tasks. What would take other languages numerous lines of code to produce is efficiently encapsulated either in a tag or function or as a setting in the administrator. This is a simplistic yet indicative example: where else can you connected to a database simply with one line of code or indeed simply by name? ColdFusion changed the idea of specifying development time in terms of months and years to weeks and months or small features a matter of hours and days. Simplicity is not the mother or all evil. To be pragmatic, simplification reduces costs.
3. Rich Internet Applications – ColdFusion may or may not have pioneered the RIA paradigm, but it has played a significant supporting role to Flash and now Flex. ColdFusion natively supports Flash remoting, providing the all important data access tier.
4. Platform Maturity – ColdFusion 8 is built upon the latest version of Java (1.6). Along with internal improvements to the ColdFusion application, this has afforded ColdFusion unprecedented speed improvements and stability.
5. Language Maturity – with each major release of ColdFusion comes many language enhancements added to the core. This means that previous addons, for example image manipulation, which came at a premium are now standard. Adobe and other companies that produce CFML engines are now participating in a CFML advisory committee, which aims to set standards for the core language. This is not only a sign of maturity but a letter of intent by the industry that will mean your application will work on any engine, assuming no proprietary functionality is used.
6. The Ultimate Middleware – ColdFusion sits comfortably between any backend and front end system. Be it interfacing with a host of databases, Java, .NET, COM, Corba or connecting to classic HTML or rich Flash, Flex and AJAX frontends with little or no configuration.
7. Feature Rich – what other web technology natively supports PDF generation, charting, enterprise-level search, AJAX, image manipulation, Atom and RSS creation, Zip and JAR file manipulation, a server monitor, Flex integration, encryption libraries, all important database connectors, webservice creation, XML manipulation, inbuilt reporting application (similar to Crystal Reports), email, FTP to name but a few? I hazard a guess at none, unless you’re happy to pay a premium.
8. Platform Independent – since ColdFusion 6, when Macromedia redeveloped the entire application in Java, ColdFusion has been platform independent. You can install it on practically any machine.
9. OpenSource Alternatives – BlueDragon and Railo are both significant alternatives to Adobe ColdFusion and both have opensource alternatives, the latter of the two having recently joined the JBoss community. Adobe are also considering providing a free edition to academic institutions.
10. The Future – many commentators have mentioned Hibernate as a significant addition to the next release of ColdFusion, version 9. But having seen the prerelease notes, that is not all that will be added. Alas I’m under NDA, but rest assured, there is going to be a significant intake of breath when developers get hold of the next release. ColdFusion 8 was firmly geared towards middle management with fuzzy additions, ColdFusion 9 is set to re-address the balance with compelling language and functionality enhancements.

ColdFusion evangelism needs to step up a gear! Adobe certainly doesn’t afford much marketing budget to the product, prefering The Community do the hard work. It is not always easy convincing the decision makers that ColdFusion is a good product of choice, without Adobe’s unnerving support, but we have to work hard, break down those barriers, encroach on events outside the comfortable sphere of the ColdFusion world and demonstrate ColdFusion’s match-winning ability.

ColdFusion isn’t dying, it’s simply niche. Every niche has its place.

UPDATE: If you would like to view the ensuing debate regarding ColdFusion prompted by Aral Balkan, feel free to do so. This post should serve as a positive reminder of ColdFusion’s virtues, alongside the need for a balanced and polite debate.

Below is a list of Flex and AIR frameworks that will allow you to get up and running and develop highly-collaborative applications. The introductions are by the frameworks themselves, but I’d like to here from you about your experiences using them.

Cairngorm

Cairngorm is the lightweight micro-architecture for Rich Internet Applications built in Flex or AIR. A collaboration of recognized design patterns, Cairngorm exemplifies and encourages best-practices for RIA development advocated by Adobe Consulting, encourages best-practice leverage of the underlying Flex framework, while making it easier for medium to large teams of software engineers deliver medium to large scale, mission-critical Rich Internet Applications.

More information can be found on the Cairngorm project’s website.

PureMVC

PureMVC is a lightweight framework for creating applications based upon the classic Model-View-Controller concept.

Based upon proven design patterns, this free, open source framework which was originally implemented in the ActionScript 3 language for use with Adobe Flex, Flash and AIR, has now been ported to nearly all major development platforms.

Two versions of the framework are supported with reference implementations; Standard and MultiCore, though only the Standard version has been ported to other languages so far.

More information can be found on the PureMVC project’s website.

Mate

Mate is a tag-based, event-driven Flex framework.

Flex applications are event-driven. Mate framework has been created to make it easy to handle the events your Flex application creates. Mate allows you to define who is handling those events, whether data needs to be retrieved from the server, or other events need to be triggered.

In addition, Mate provides a mechanism for dependency injection to make it easy for the different parts of your application to get the data and objects they need.

More information can be found on the Mate project’s website.

Swiz

Swiz is a framework for Adobe Flex that aims to bring complete simplicity to RIA development. Swiz provides Inversion of Control, event handing, and simple life cycle for asynchronous remote methods. In contrast to other major frameworks for Flex, Swiz imposes no J2EE patterns on your code, no repetitive folder layouts, and no boilerplate code on your development. Swiz represents best practices learned from the top RIA developers at some of the best consulting firms in the industry, enabling Swiz to be simple, lightweight, and extremely productive.

More information can be found on the Swiz project’s website.

Guasax

Guasax is an ease of use programming framework which provides the creation of an ordered and scalable application with Adobe Flex. The lifecycle of the Guasax framework is based in the MVC pattern to take on our program actions. The Guasax framework helps you to maintain your business logic tier highly decoupled from your presentation logic tier.

Guasax takes reflection and introspection techniques as well as the Inversion of Control (IoC) pattern to execute the operations which we have pointed at and to make a decision about itself. Guasax is not intrusive on your class model. You don’t have to extend your classes in a framework class to use it.

More information can be found on the Guasax project’s website or on their Google code project.

Model-Glue: Flex

Model-Glue: Flex brings implicit invocation, Model-View-Controller design, and cleaner, less repetitive integration with backend services to Flex and AIR applications.

It shuns repetitive, boilerplate code in favor of helper classes and expressive APIs.

More information can be found on the Model-Glue: Flex project’s website.

Gaia

Gaia is an open-source front-end Flash Framework for AS3 and AS2 designed to dramatically reduce development time.

Gaia is targeted at anyone who develops Flash sites. It provides solutions to the challenges and repeated tasks faced with front-end Flash site development, such as navigation, transitions, preloading, asset management, site structure, deep linking and SEO. It provides speed and flexibility in your workflow and a simple API that gives you access to its powerful features.

More information can be found on the Gaia Framework’s website.

UPDATE: Some more frameworks that I overlooked.

Parsley

Parsley is an application framework for Flex/Flash/AIR applications written in AS3. It contains the following modules:

IoC Container (Configuration and Dependency Injection) – Inspired by the Spring Framework it brings the concept of anIoC(Inversion of Control) container to ActionScript. It is useful for configuration and wiring of applications. It helps building a well structured architecture and decoupling the individual building blocks of your application. Configuration is based on XML files.

MVC Framework – The MVC (Model View Controller) framework helps decouple the view layer from other parts of the application. It borrows the concept of a FrontController from Cairngorm, but instead of advocating the use of BusinessDelegate and ServiceLocator patterns, the framework integrates the FrontController with the IoC container.
More information can be found on the Parsley Framework’s website.

Prana

Prana is an Inversion of Control (IoC) Container for ActionScript 3.0, and more specifically the Flex framework. It enables you to configure objects and components in a non-intrusive way by describing them in an external XML document and having them loaded at runtime.

At its core is a Spring-ish application context and IoC container. The XML dialect for the application context is aimed to be Spring compliant.

The framework also contains utility classes for configuring and extending Cairngorm and PureMVC applications, a Reflection API and general utilities.

More information can be found on the Prana Framework’s website.

Arp

Arp is a pattern-based framework for Flash and Flex. It supports both ActionScript 2 and ActionScript 3.

More information can be found on the Arp project’s page on the Open Source Flash website.

Human behaviour flows from three main sources: desire, emotion and knowledge

Desire lines are those well-worn ribbons of dirt that you see cutting across a patch of grass, field or park, often with nearby pavements, particularly those that offer a less direct route, ignored. In winter, desire lines appear spontaneously as trampled down paths in the snow. These paths are never perfectly straight but instead, they meander like a river this way and that, as if to prove that desire itself isn’t uniform or linear and (literally, in this case) straightforward. Desire Lines show that it is human to choose, but it is also human to choose what other people have chosen before. Be it for establishing a pattern, be it for convenience, or be it for not reinventing the wheel. In this way the Desire Lines become well-trodden and pseudo-permanent routes to a particular destination.

Desire Lines are the ultimate unbiased expression of natural human purpose

The term ‘Desire Lines’ originates from the field of urban planning in the early 20th Century.

An optimal way to design pathways in accordance to natural behaviour is not to design them at all

Extending the concept to websites

Broadening the concept of Desire Lines, it is also possible to see other impressions of human desire in websites, many of which can provide a commercial advantage to the particular website in question.

The web phenomenon is simply another way people find entertainment, communicate and interact. Whether the purpose of using the web is for enjoyment or employment, Desire Lines are are a such perfect expression of natural human intention that they become the utlimate design pattern for building successful and intuitive websites. It is easy to envisage users like an army of ants moving in single file towards their goal, not following set paths, but bypassing the planned route directly towards the news article, the video, indeed any product being offered by the website concerned.

Instead of websites providing classic access points via menus and taxonomies, they can employ different access points based upon user preferences and previous browsing history. This is heavily dependent upon capturing user’s details via a cookie or a login system, like at Amazon, but the benefits to the user can be far more rewarding.

So who is doing this?

Understanding the demographics of your users and your site usage is key to Desire Lines. The BBC website is a great example whereby search statics are monitored frequently. They adapt their web user interface and site structure based upon what people are typing into their search box thus making it easier for subsequent users to view the more relevant or interesting stories of the day.

Amazon makes Desire Lines more explicit and beneficial to their users through Listmania, recommendations, Customers Who Bought This Item Also Bought, What Do Customers Ultimately Buy After Viewing Items Like This?, Better Together, Recently Viewed Items, Wish Lists etc. In essence, Amazon does not provide a single standard way of finding an item, but relates each item together through a myriad of historic information from its user community. The user therefore has the option to search for an item, use the catagories, or click on links and begin their own desired user journey, which can be uniquely distinct from other users journeys or a mirror of those journeys.

Current TV takes the concept even further by showing content that is purely based upon what users want, or what they term as viewer-created content. Current slice the schedule into short segments into “pods” — each just a few minutes long. These pods profile interesting people on the rise, intelligence on trends as they spring up around us, and international news from new perspectives. Anyone who wants to contribute can upload a video. Then, everyone in the Current online community helps decide what should be on TV. You can join in at either stage — watch & vote or make video.

Limitations to Desire Lines

A key limitation, or possibly a challenge, to the successful adoption of Desire Lines concerns advertising revenues. For a user it is beneficial to be able to reached the desired destination as quickly and efficiently as possible, but for a website’s advertising revenue it certainly is not. To be simplistic and possibly cynical, many sites don’t want users to have an overly efficient experience as this limits page views and page impressions. The challenge, therefore, is to retain users on the website and provide them more relevant information and targeted advertising.

There are also implications on what is considered more relevant and what is not. The BBC to some extent decides based upon user searches, but this serves also to hide potentially captivating an important stories. One user’s preference isn’t necessarily the next’s, therefore creating an information bias. This may be even more problematic with our over-reliance on Google for finding information. The Google algorithms essentially decide what we find even though we are told that the sites listed are based upon relevance and popularity.

Finally, you can’t pave every desire line. To do so would end in a playing field not covered in lush green grass with a few tracks intersecting the green, but a concrete mess.

The Law of Demeter says that if I need to request a service of an objects sub-part, I should instead make the request of the object itself and let it propagate this request to all relevant sub-parts, therefore the object is responsible for knowing its internal make-up instead of the method that uses it.

Stated in plain English:

• You can play with yourself
• You can play with your own toys (but you can’t take them apart)
• You can play with toys that were given to you; and
• You can play with toys you’ve made yourself.

Stated more succinctly, the Law of Demeter for Functions says that:

• Your method can call other methods in its class directly
• Your method can call methods on its own fields directly (but not on the fields’ fields)
• When your method takes parameters, your method can call methods on those parameters directly; and
• When your method creates local objects, that method can call method on the local objects.

The basic idea is to avoid invoking methods of a member object that is returned by another method. When you do this, you make structural assumptions about the container object that may be likely to change. The container object may later need to be modified to contain a different number of the contained objects, or it may end up being changed to contain another object which contains the original component object. If the ‘returned’ object isn’t a sub-part of the object whose method was invoked, nor of some other object, then it typically is not a violation of LoD to invoke a method of the returned object (particularly if the object was created by the invoking method).Using the Law of Demeter (LoD) you instead ask the container to invoke a method on its elements and return the result. The details of how the container propagates the message to its elements are encapsulated by the containing object. This results in weak coupling and strong cohesion, the general goal of high readability and maintainability of an application. This is highly desirable when building a ‘modern’ ColdFusion application as it is all too easy getting trapped into the bad-old-days of “spaghetti code”.

A side-effect of this is that if you conform to LoD, while it may quite increase the maintainability and ‘adaptiveness’ of your application, you also end up having to write lots of little wrapper methods to propagate methods calls to its components, which can add development time overhead.

In software engineering, a design pattern is a general repeatable solution to a commonly occurring problem in software design. A design pattern is not a finished design that can be transformed directly into code. It is a description or template for how to solve a problem that can be used in many different situations. Object-oriented design patterns typically show relationships and interactions between classes or objects, without specifying the final application classes or objects that are involved.

Not all software patterns are design patterns. Design patterns deal specifically with problems at the level of software design. Other kinds of patterns, such as architectural patterns, for example Model-View-Controller (MVC), Implicit Invocation and Dependency Injection, describe problems and solutions that have alternative scopes. However, for ease, I generally consider software and architecture patterns under the design pattern scope.

Design patterns can speed up the development process by providing tested, proven development paradigms. Effective software design requires considering issues that may not become visible until later in the implementation. Reusing design patterns helps to prevent subtle issues that can cause major problems, and it also improves code readability for coders and architects who are familiar with the patterns.

Design patterns can be classified in terms of the underlying problem they solve. Examples of problem-based pattern classifications include Creational, Structural and Behavioural Patterns. Creational patterns, such as Singleton, deal with the creation of objects, Structural patterns, such as Facade, deal with the relationships between objects and Behavioural patterns, such as Observer, deal with the communication between objects.

The practical application of design patterns to ColdFusion applications is a new phenomenon and one which requires careful consideration. There is no sense in using a design pattern for the sake of using it, it must first solve the problem you have encountered. Common design patterns that I have used in my day-to-day development have included Singleton, Composite, Model-View-Controller (MVC), Data Access Object (DAO), Gateway, Bean and the Facade Pattern. These I will discuss in later articles.

Further Reading:

Alexander, Christopher; et al (1977). A Pattern Language: Towns, Buildings, Construction. New York: Oxford University Press. ISBN 0-195-01919-9.

Freeman, Elisabeth; Freeman, Eric; Bates, Bert (2004). Head First Design Patterns, paperback, O’Reilly. ISBN 0-596-00712-4.

Gamma, Erich; Richard Helm, Ralph Johnson, and John Vlissides (1995). Design Patterns: Elements of Reusable Object-Oriented Software, hardcover, 395 pages, Addison-Wesley. ISBN 0-201-63361-2.

Shalloway, Alan; Trott, James (2001) Design Patterns Explained: A New Perspective on Object-Oriented Design, paperback, 368 pages, Addison-Wesley. ISBN 0-201-71594-5.