CF OS Blue(Dragon)s

Well, it isn't quite CFUnited when many hoped to see the product go 1.0 but it is here and an impressive first product.

Here are some of the new features and a few comments.

• Admin Console: No more editing of the configuration file, every aspect of the engine available through a fully functional administration console. (Note: Originally this was not planned for this release... this will be appreciated.)
  
• CFSMTP: Build applications that respond to email coming in on Port25 immediately. No polling
• CFIMAP: Access IMAP servers from your CFML application
• Amazon SimpleDB: Need to utilise Amazon's SimpleDB? Then simply use CFQUERY! (Note: This will be interesting to get reviews on!)
  
• Amazon S3: Push files up and down to Amazon's popular S3 service with extreme ease (This is in Railo in some way also, wonder if it's equal here. Also... will we see this in ColdFusion now?)
  
• Memcache: Utilise this popular high performance caching layer deep within your CFML code
• render(): Render full blocks of CFML code on-the-fly; think Evaluate(.) but for tags
• CFCACHECONTENT / CacheXXX(): Full caching layer to let you really control what gets cached
• CFMULTICAST: Lets you send and receive multicast packets
• CFXMLRPC: Quickly consume remote XML-RPC services

There is more information on the OpenBD.org site and a WIKI.

Great Myths of Software Development

We will look at 3 Great Myths in this post.

1. Objects cannot be expressed with tag based markup.
2. Design Patterns are patterns
3. High Level Languages are not pragmatic

Myth 1: Objects cannot be expressed with tag based markup.

Objects exist after a compliler has translated class based text code into compiled classes that are created as instances in running software. ColdFusion in version 6 introduced it's development community to standard objects based on the common code of that version. Historically we see that most languages create objects with script based code but this is not always the case. There are many types of objects out there. One of the most common type of ojbects is known as DOM these are the objects created with HTML markup. Language libraries like EXTJS seem to have found sweet spot solutions for letting JS developers create DOM with script. Both seem to work well and it is mostly a matter of style.

Now with that said, the JS vs HTML dom objects are equal. As time has passed and we have learned there are ways to design objects that interface together effectively. In electronics technology there are messaging packet standards that allow these physical entities to communicate with each other via messaging standards. They still need common interfaces but the messaging packets are essential. In software we tend to focus more on interface and the developer has to know more about the unique message packets they send in and take out. Because of this we find that one thing that makes integration more reliable is Unit Testing. Over time we have learned that Unit Testing is a two point test. We must test input and output. In reality Unit Testing doesn't care what goes on inside an object as long as it accepts the input and when appropriate returns the proper output. When we look at tags vs script again there is not change here in which is better.

Myth 2 : Design Patterns are patterns

Design Patterns are better thought of as generic principles that solve generic problems. There is a great deal of confusion that comes from the belief that design patterns are like a mold used to cut out holiday cookies. Principles don't change but the implementation of the principles does from one use to the next. If we add red to a white cookie we get something on the scale of pink to red. If we add it to a blue cookie we move to purple. That is just a principled illustration and like design patterns it only illustrates the difference between the cookie and the color. Design patterns are great things to understand and there is even a pattern called Anti-Pattern. This is not a specific pattern but the principle of learning where design patterns work wrong and make things worse. Therefore we can see that the study of design patterns is not meant to be rigid but a relaxed use of principles to improve software through good understanding of ways object oriented code can be created.

Myth 3 : High Level Languages are not pragmatic

Funny is the chant of a Java developer who would chide a high level language like ColdFusion. Then he turns around and promotes Spring or Hibernate. Often low level languages are so daunting that they create high level libraries to encapsulate common processes. A high level language is just a language that has these type of features packaged not only as a library but integrated into the commands built into a platform. If the language remains extensible and allows continued encapsulation like the lower level languages then it is actually out of the box the most pragmatic solution to be acquired.

Beyond the CFConversation Podcast

If you are tunning into the Frameworks podcasts you will hear lots of interesting perspective on frameworks. If you are smart you will figure out that the one size fits all mentiality is not one of understanding. Choosing a framework that works for everyone is like choosing a vehicle that works for everyone. Imagine if everyone had to drive a truck or everyone had to drive a sub-compact car! One more thought would be should we all have hammers or should we all have nail guns? Obviously we need different tools for different jobs.

So first you may want to check out the podcasts. One was released last week end and one will be released next week end. ( http://www.cfconversations.com/ )

Next you may want to read about things happening outside of the CF realm. One good example is an article on SitePoint about a new application installer by Microsoft. This new solution lets you install open source applications on your web site. Hmmm... seems like the marketing department at even Microsoft has figured out the way to reach the public is to sell them on being able to install applications on the web site in an easy fashion. Yes, technical structure is a good benefit to any web site. Yet inside our community it seems (as you will hear on the podcasts) that a number of the vendors focus on being a 'control based framework'. Can anyone tell me if you would like to try to sell the management of your company on why a controller based framework offers more benefit than a solution that installs your choice of applications in an automated fashion? Yes, I know we coders are generally geeks but business doesn't make money because we are technically superior alone!

Now with that said let me say there are times where I will understand others may not want to use SOS as the solution of choice. We focus on the problem from more of a business centric view and then we also look at technical considerations. In about a week the beta 2 release of SOS will be uploaded for the public or developers that is to play with for a short season. We are getting very close to a full release of the product.

SOS Overview

• Business Centric
• Application Installer
• Shared Authentication
• Robust API
• Supports coding in multiple methodologies
• ADS (Approchable, DRY as in don't repeat yourself, and Sustainable) Standards
• Active Schema
• ... more to follow
  • documentation
  • screen cast tutorials
  • business overview (so the boss will understand)
  • etc.

Now if anyone needs some consulting assistance just let us know and we will see what we can do to help you out.