Coldfusion 8 Beta Bigger

May 30, 2007

Coldfusion 8 has been released to public beta.

As the Allaire Macromedia Adobe product goes into public beta, the thing everybody can agree on is that there is more there than there was before.  More Ajax stuff.  More support for Flex.  More monitoring stuff.  It’s bigger than the last big release, and bigger than the release before that, which is the same for any language/framework.

All of this hints toward a basic underlying question.  What is Coldfusion, anyway?

  Is it a language?  Is it framework?  Is it a vehicle for pushing Flex onto unsuspecting customers?  Is it a training ground for Java programmers?  Is it on Rails? Or is it at the station waiting for the 5:15?  We can define it in terms of what it is, or what it does.  Where it came from, and where is it going.

  From my perspective, there are two Coldfusions.  The old Allaire product, written in C++, for a web space which had little more than CGI, perl and custom connectors in Java and C++ to drive with, Coldfusion 4 was extremely compelling.  At the time, I needed to put together a solution (quickly), and I wanted to look beyond Perl.  Coldfusion fit the bill, and I was able to put together a site quickly and nicely, and from that I drew attention from people who wanted to do the same (have a site up, and fast).  The database layer is simple and easy to administer.  The security is reasonably solid, and the scalability capability is there.  There were big boys playing with Coldfusion, so it seemed like it would not disappear overnight.  Microsoft’s ASP was another contender, arising the result of an acquisition of a competitor of Allaire’s.

  The second Coldfusion was (in my opinion) beta’ed with Coldfusion MX (aka 6).  I would not have run anything on production on Coldfusion MX.  Coldfusion 5 had everything I needed from CF, so CF MX was for the lab, for playing.  It was not until CF MX 7 was released that I considered this new Coldfusion to be a solid product.

  As far as the language/framework question goes, it’s all a question of how you define language and how you define framework, and that is based on assumptions and other factors.  I think basing the distinctions based upon those features of a language or framework or other construct may be more accurate (but not quite so efficient).  A language exists for the purpose of transferring information and data from one domain to another for processing.  The rules governing the mechanisms for doing so, the syntax and essential protocols, that could be the limit of the language domain.  Some expressions or manifestations of the language in the form of characteristic structures or linguistic phenomes could be considered to be so intrinsic that they are parts of the language itself, and so I will often include that into the “core” language.  Beyond that, there are domain specific constructs, dialects or colloquialisms, which could be called extensions of the language, or libraries.  If they change, with a specific structure or a set of complementary structures, the approach to solving a problem, or transferring information and data from one domain to another, then perhaps they are more a framework.

  Given that quick and dirty explanation (or in spite of it), I consider Coldfusion running on the Java platform (the second Coldfusion) to be a framework for Java.  I don’t have any strong opinions, as this is a didactic discussion, with no deep  implications.  I’ve loosened up a bit and am quicker to forgive the slight malopropism and get on with things.  The discussion of the distinction between language and framework *is* an important one to have, not for the sake of the conclusions that are reached, but rather for highlighting the elements or properties of each set, where those roles exist and how they play their part in making systems go.

  While not central to the discussion it is notable that the recent arrivals in the web programming arena have been from beyond the shores of the U.S.  Ruby and Python both have origins in Japan.  PHP had an interesting journey from Denmark, then through Israel for PHP 3, and for Zend.  And then the IDE’s Eclipse and Netbeans both come from Prague.  That international influence is a sharp contrast to the “old days.”  The old players are mostly American: Microsoft, Sun Microsystems, Adobe (And Allaire was American, as was Silicon Beach Software, the original creators of Flash).  The important thing to note about this is that it is just one more feature of the break from “tradition” that was Microsoft, IBM, Apple, Adobe, HP…  one more characteristic of Web 2.0.  And Adobe has to face the challenge by moving forward with its initiatives, the CF8 public beta being a key component of that.  Businesses will continue to look for what best supports their business initiatives.

  From a functional perspective, the language/platform has to be measured in terms of what it is trying to achieve, or what problems it is trying to solve, and its effectiveness in doing so.  The functional perspective could include the ability to access  databases quickly and reliably (possibly including ORM), and the ability to support the current web client side demands (Ajax, Flex).  The list goes on.   This release of Coldfusion and libraries achieves a big list check off for many items which have been lacking in the Coldfusion realm, and seemingly ubiquitous in other platforms (visa vi image processing).  But the functional perspective alone does not make up the complete picture.  Customer acceptance (external marketing), a skilled and motivated developer base (internal marketing), and a clear product roadmap would go a long way for the Coldfusion community.


Random but not Unlikely

May 29, 2007

  If you wonder at all which influenced which, broadcast media affecting personal or business computing, or vice versa, notice the order that the screens went wide.  It wasn’t for the computer’s sake, nor was it the relentless pursuit of the Golden Mean.

  I find it funny when I think about 5 years ago as “the old days”, but in the lifetime of Flash, and in Internet Time, the early 2000’s was a simpler time.

  Here are a couple of psuedo random links for some “old school/new style” Flash:

Some finalists for the 2007 Canadian New Media awards:

 And the FWA (Favourite Website Awards):

G-Index for May

May 29, 2007

G Index May 2007

As millions (or less) closely watch, the Erlang programming languages maintains a thin lead over contenders Eiffel, and Haskell, as it has been predicted  by some to be the “next” Ruby on Rails, or  killer language/platform paradigm.

The G-Index is a measure taken by putting the string “Programming Language” and the name of the language in question, into Google, and recording the number of hits.  It is not intended as a scientific study, nor as sarcastic social commentary, and is quite possibly just an excuse to post a graph.

What’s Yahoo Instant Messenger Doing?

May 27, 2007

I was doing some debug tracing on a Flex program, when I had to dig in deeper, and take a look at what was happening underneath the hood. Flex, Flash, for the debugger, they use the equivalent of the localConnection class. And that, in turn, uses shared memory. That shared memory is locked and handled by two processes (in Windows anyway), MacromediaMutexOmega, and MacromediaFMOmega. See this from OSFlash for a better explanation.  So, to view these processes’ activities, I launch ProcessExplorer, from SysInternals. And I run a search on “Omega”, and what do I find besides my Flex code running in IE? I see a couple of pairs of similar constructs owned by the Yahoo Instant Messenger program.

Yahoo - Processes

I was alright with Yahoo until… I wish I had marked the calendar. It was a few months ago. I had left my computer on, when I went to sleep. During the night, Yahoo launched an automatic update process. One of the steps in the process was to query me about my preferences *but* to give me only 5 minutes to make my selection known. Well, I was asleep at the time. So, I awoke to a rebooted computer, with the Internet Explorer preferences “customized” to Yahoo’s liking, among a few other things. If I had wanted it, I would have asked for it. This disturbed the state of my machine, which, I kind of consider an invasion of privacy. I felt a little violated. But, I walked out of the fantasy world I had been in, that any of these big companies could possibly be the “good guys.” That illusion has been dispelled.
Yahoo Process Omega
So, here’s Yahoo peeking its head in at me while I am debugging, and I wonder what it is up to. I know that Yahoo and Adobe have been working together on Flex stuff, and that Yahoo released an IM version built on Flex, but I didn’t think this was related.

Oh well, I am inclined to switch from Yahoo soon anyway, but I remain curious.

On the Taxenomy of Ducks

May 27, 2007

On the Taxenomy of Ducks:

Using Object Inrospection and Reflection to Manage Systems Integrity

          When I was 12, my brother and sister and I spent a week in Seatle, visiting my grandparents during winter breaker.  On the Tuesday of our visit, my grandmother had her bridge club over, and my grandfather was out taking care of some holiday shopping, so my siblings and I were left to entertain ourselves for a few hours.  It was was raining outside, so my sister decided she would read a book.  My brother wanted to play a game (I was hoping we would play chess).  So, he went to grandmothers game closet, and pulled out a box, handed it to me and asked me to set it up, so we could play a game.  The box was labelled Chess, and had pictures of a chess board and chess pieces on the outside, so I was excited to play a game of chess.  I opened up the box, and began to set up the board pieces, and I found that a few pawns were missing.  I could have just told my brother we could not play, as there were pieces missing.  I could have gone and interrupted grandmother’s bridge game, to ask her if she knew where the missing pieces were.  But I found some dice laying on the table, so I substituted the dice for the missing pawns, so we could play a game, and asked my brother “Okay, white or black?”
Rabbit Or Duck
           The roles and responsibilities and expectations of objects in software systems are subject to the requirements, methods and organization of the system architect, and the engineering team lead.  How objects handle their input objects is an age old problem, and with the introduction of distributed systems, the shapes and sizes of input objects can suffer from their own contraints.  An object needs to have a way of behaving when it is handed an object for processing, and the first thing it needs to do is inspect the input.  If the input is not what it requires, then it needs to either handle that somehow, or throw an error.  Or maybe he doesn’t want to deal with it at all and “fixes” it by making the error message go away….
try {
} catch(e:Error)
  //do nothing - let someone else deal with it.

          This principle of software development has become topical because of the fairly recent adoption of a practice dubbed “Duck Typing” by some, popular in ColdFusion and Ruby development circles.  So, what is “Duck Typing” and why does it raise discussion around object behavior?         

          In software languages like C++ and Java, objects are classified by types, which define specifically what properties they have, and what methods are available.  When the C++ or Java code is compiled, the compiler checks to ensure that the inputs to object methods are of the expected types, and if not, a compiler error is thrown.  In interpreted systems, like Ruby, or JIT compiled systems like ColdFusion, the types are checked at runtime JIT compile time.  If the objects are strongly typed, an error is thrown.  This is much like my brother handing me the box from the game closet.  If the box was not labelled Chess, I could have objected and handed it back to my brother.

          The practice of “Duck Typing” is to abandon this practice, and let the called object deal with whatever object it is handed.  I have heard it told to me that "If it looks like a Duck, and it Quacks like a Duck, then it is probably a Duck"  So, in other words, if it is the object has a radius parameter, then it is probably a circle.  In practical terms, this is a shift of responsibilities from the caller, software environment or compiler, to the called object.  The objection to “Duck Typing” is that often this means a shift of responsibility to quality control, the bug tracking team, customer service and the project manager who is left explaining why their enterprise web system is crashing, and the development team is having difficulty tracking the bugs.  What has not been clarified in some team development environments, is that there has been a shift in responsibility.  Someone has to pick up the slack.  It is left to the called object to be more diligent in checking it’s input, and more flexible in how it handles the input.  Like, when I discovered there were pieces missing from the chess set, and I made a couple of pawns out of dice, the team needs to be clear on what the object has the authority to do, to perform its function.       Communication needs to be of the highest order in cases like this, where repsonsibility is shifted to the worker classes.  Once it is clear what the developers are being handed, there are a few strategies which need to be embraced when the protective tools of compile and runtime type checking are no longer there, because in the end, the software needs to work. There is ad hoc internal type checking, which can be set up with a simple tag, or an extra parameter on an object, which signifies the class.  There is an inventory process which an object can run on acceptance or rejection of a call.  The inventory is a matter of running through an object’s properties, like a checklist, to see if this is here, if that is there, etc., to make sure its properties match to what is expected.  The reflection API can accomodate this, as well.    If you are using Duck typing in a project, make sure to build type variance into your unit tests.  Better that the unit tests blow up than your codeline… or the customer.    What is the reason for this interest in a methodology?  Where’d the Ducks come from?  Well, when the girls start screaming, look for the rock star.  Quiz Time:  Is it David Hasselhoff or David Heinemeier Hannson?  Well, the DRY principal employeed in Ruby on Rails, says that the interface (required behavior) leads to repetition.  (DRY = Don’t repeat yourself… so repeating, bad).   Dave Thomas and Andy Hunt (Pragmatic Programmers)  These guys are incredible.  They advocate pushing Ruby on your business, with the tactics of Scientologists on a three day weekend.  Well, that was then.  Now, they are pushing Erlang (saying it’s today’s Ruby).  Give me a break.

     There is some merit, however, in the argument that the behavior of an object should in some cases define what it was, and so, having a type would be redundant.  And, given suffiently compelling context, I’d give it a whirl.  However, the situations a contractor is placed in are often a little less predictable than the cozy intellectual Oasis of Object Orient land.  There is a large installed base of non OO scripting methodologies, and relational databases, which aren’t going to step aside and make way for new practices.  Same goes for the installed base of employees.

     So, while not denouncing the practice of Duck Typing completely, I would question the argument for its adoption simply on the basis that it has one aspect of DRY, so it will lead to some future benefit.  In every single case, where a change is made, I have to ask myself How much is this going to cost? and What business benefit are we going to derive?  You *cannot* simply remove a solution from its context, and then advise for it.  If you remove it so far as to remove it from the problem, then the solution looks for a problem, any problem, to take its place.

     Sean Corfield expressed concern that people seemed to miss the point of his talk, when they talked only of the performance boost of using Duck Typing.  Removed from even a contrived context, how would anyone think any differently?  You can lead a duck to water but you can’t make him…. (okay, a metaphor mix in was called for)

   As a quick disclaimer, I should say that I am passionate about patterns, enthusiastic about object oriented methodologies and applications which can really drive efficiency and creativity.  While this is so, I witness many people who simply do not understand the underlying pricipals, but think they do.  It’s okay to not understand.   The concepts are not at all down to earth… they are abstract.  But for the people who think they understand the principals and try to drive an implementation with complete disregard to tried and true principals and practices of Unit testing, communication, and so on, … and without any support from a return on investment standpoint, let me say, these people are dangerous to software projects.

     I will continue this (rant?) and tell how the chess game turned out in a later post  (continued….)

ObjectProxy in Flex 2

May 18, 2007

ObjectProxy in Flex 2 (continued) I went over the problem of the null responder, and a solution, in the last discussion of Delayed Instantiation. This deserves a deeper look because it is a frequently misunderstood and misapplied area of the Flex framework. Fortunately, Adobe provides the source code for ObjectProxy, and it can be found in the Flex SDK under [Flex SDK Folder]’frameworks’source’mx’utils’ I’ll dig into one particular area, the getter function, as that was what was in doubt in the example.

/** * Returns the specified property value of the proxied object. 
** @param name Typically a string containing the name of the property, 
* or possibly a QName where the property name is found by 
* inspecting the localName property. 
* * @return The value of the property. 
* In some instances this value may be an instance of 
* ObjectProxy. 
override flash_proxy function getProperty(name:*):* { // if we have a data proxy for this then 
   var result:Object = null; 
   if (notifiers[name.toString()]) return notifiers[name]; 
    result = _item[name]; 
    if (result) { 
       if (_proxyLevel == 0 || ObjectUtil.isSimple(result)) 
           { return result; } 
           { result = object_proxy::getComplexProperty(name, result); } 
// if we are proxying } 
  return result; 

In the traditional use of the Virtual Proxy, the caller is requesting the value of some property. The only way to access this property is through the accessor interface, or the getter, which is what is listed above. Now, the getter does not simply return the private value and be done with it. It can do several things. In this case, it does the following: 1) Check to see if we are waiting for a response on this item (from the notifiers). If so, pass back a reference to the notifier. 2) Get the indexed item, and if it is a simple object (a Number, say) or if the _proxyLevel is 0, just return the object 3) Otherwise, send back a proxy to the complex object The caller is never sure what he is going to get, and has to work with the interfaces presented to him. In the first use case, where the Notifier is returned, is this what we see when we are givge, en the null error, as in the last article? Or is this a different case altogether? Now, you think, it would be really handy if I could introspect the proxy to see if it is the real object, or if it is a notifier or proxy. But it would also be the exact opposite of what the design pattern was supposed to encourage, thus reducing the solution’s overall effectiveness, and lowering the measure of loose coupling between those layers. As soon as you start digging inside of the object to find out stuff (not during debug, I am talking about realtime deep uinstrospecting to gain knowledge about the state of an object when it was intended to be encapsulated. This is a good time to go ahead and trace through a test case with the debugger, to see what is going on. Why is there a delay in that object’s instantiation, and why do we get a null error? What are the mechanics of what is going on? What is the proper way to handle these objects with care, to avoid producing that error. And finally, if there is an inherent problem with the architecture, how could it be fixed, so that a deeper look would not be necessary? (continued) Here’s another solution I have seen applied, which eliminates the errors, but we still haven’t fully clarified the root cause yet.:

public function result( event : Object ) : void
   var resultEvent:ResultEvent = ResultEvent(event); 

   var result:ArrayCollection = resultEvent.result as ArrayCollection;
    for (var i:String in result) 
    { result[i] = new ObjectProxy(result[i]);}
    ModelLocator.getInstance().myArray = result;

This looks suspiciously like the code in the previous post, in the framework itself. So, this move compensates for something the framework is not handling for some reason. That is, the result is not being wrapped in a Proxy because of the type of variable the result is being assigned to. So, the return code is doing what the framework would have done, wrapping it in a Proxy, so the Proxy will handle peeking at the contents to see if it’s ready. More can be gleaned from the documentation on RemoteObject, and the ways to handle the results and bindings. The best results seem to come from letting the bindings do the hard work, and to not beat the framework into submission with multiple type casts, and extraneous events. But, sometimes, this seems to be all you can do to make it go… (to be continued)

ArrayUtil and RemoteObject Proxies in Flex

May 17, 2007

The problem:

In Flex, you’ve performed all of the steps to issue a remote query, and your responder has received the resultevent, and you go to evaluate the payload, and it gives you a null error:  “Error #1009: Cannot access a property or method of a null object reference”.

A solution (as described in Peter Ent’s blog):

Assign the result through ArrayUtil.toArray = mx.utils.ArrayUtil.toArray(;

(link (solution near bottom) :

What’s really going on?

The underlying object carried by the result event is a Proxy Object, and not an ArrayCollection, nor an array.  It could look like an ArrayCollection, but only if handled in a particular way.

Why can’t the problem be fixed?

Because the paradigms have been mixed, and they can’t be unmixed. 

The paradigms I refer to are what contrast delayed instantiation, which is characteristic of functional programming languages like Scheme, Lisp, and Haskell, and eager evaluation, which is typical of declarative programming languages like C, Java, and PHP.  In order to force declarative languages to use delayed instantiation (or lazy acquisition, or lazy loading), a bit of code has to be put in place to manage the laziness properly, and as unobtrusively as possible.  The pattern typically used is the Virtual Proxy Pattern.

In this pattern, the interface to the object that is presented, is in fact, a proxy.  It may return the real fully populated object, and it may return a shell.  That all depends on how it is implemented.  In Flex, if an object is not quite ready, you can bind it with no problem, but you don’t want to directly access the underlying object, or its members.  There are interfaces (like ArrayUtil) which you can operate through to either force it to load up all of the data, or to tickle the object, and set a listener for when it is populated (basically binding).

The Rich Client interface in Flex, provides many cases where this behavior is desireable, and to force it to load up all of the data is not always appropriate.  It is similar to the problem developers run into when they first start trying to actively drive a command into a view that has not been instantiated.  They will get a null error.  Then, after trying many things, and poring through the books, they find creationPolicy=”ALL”.  And the immediate error goes away.  That is how you defeat delayed instantiation in your views.

But, the delayed instantiation is there for a reason.  It was put in place to solve a problem, and by incrementally removing the solution, without understanding what it solved, is tantamount to inviting or encouraging the problem to surface.

It’s all about timing.  And making good use of time, which can be devoured very quickly by rich user interfaces.  For anyone who has done Windows programming, or other UI programming, you might be familiar with onDraw() event handlers for views, and how that all happens on a larger reDraw cycle.  The same principle applies here.  The data and the view are on different schedules.

When I continue, I will look at some code examples, with Haskell first, and then Java, for comparison.  Speaking of Haskell, looks like they have an actionscript byte code assembler for Haskell, with support for the Flash 9 virtual machine (AVM2).  Great work guys!

(to be continued)