Reminiscing the difficulties of predicting the future or how the iPhone 5 made it all come true

A few year back, at the height of the iPod boom, I predicted its swift demise.
I might have titled this said blog post something like Why the iPod must die!

So back then I was predicting the death of single purpose devices such as MP3 players in general and the iPod in particular. Well... I was wrong, but not all the way. The iPod is still around, but sales are declining. As a matter of fact they have been declining every year since my prediction was made in 2008:

Why do I want to warm up old toast you ask? Good question. Another thing I mentioned towards the end of the aforementioned blog post was about, how I believed, Apple could make boatloads of money, not with the iPod itself, but with the control over the connection mechanism, the 30-pin dock.

Most "i" devices Apple introduced up to iPhone 4S have this connection mechanism. A whole supporting universe of accessory makers has emerged that use that 30-pin standard to connect anything from stereo systems to zebra pattern 3d printers (I made this one up, don't Google needlessly!).
However, Apple, like Sun, when it missed the JVM for the trees, missed to monetize the 30-pin connector handsomely. While normally very astute in locking in consumers and partners alike, this was a big miss, indeed, for Apple. Also contributing to this was the ease with which people could reverse engineer the connector.

But fret no more, under the guise of improving user experience, Apple introduced the new "lightning connector" and closed this loophole with the iPhone 5. Though I have not heard any of my friends or co-workers ever state that they had trouble or needed a new way to connect, it is now a fact of live that we will have to buy many adapters or replace existing gadgets.

Now, the life of the 3rd party accessory maker has changed drastically as well. No longer can they use simple analog techniques to reverse engineer this. There is an encryption chip specific to the connector that needs to be dealt with. Why would you need an encryption chip in the docking connector? To control its use of course. IMHO this thing is so complicated that it delayed the launch of the promised lightning to Apple dock adapter.
Thus, for manufacturers the only viable alternative is to check with Apple to see what the terms of licensing lightning technology would be. This, in turn, translates into revenue in the future for Apple, and my prediction made many years ago, finally comes true !

Cheers,
B.

CF: ColdFusion with Amazon Load Balancer (ELB) and mysterious line breaks causing "unterminated string literal" exceptions

This seems like a complicated scenario at first until I started thinking about it again.
You use ColdFusion in the Cloud, specifically in the Amazon cloud, you then add a load balancer in front of your servers, then you notice your JavaScript starting to error out in some browsers. You cannot explain it.
Then, you spent countless hours going nuts.

Here is a sample JavaScript and ColdFusion block that would break. The simple block retrieved a name from a ColdFusion function and passed it to JavaScript:


<cfoutput>
  <script type="text/javascript">
    var myName = '#fCallForName()#';
  </script>
</cfoutput>


The above returned this in browser lets say the name was "John" :



  <script type="text/javascript">
    var myName = '
John';
  </script>


This, in turn, throws a "unterminated string literal" exception in JavaScript because of the line break right before the name. Of course, you say, silly you, you probably doing something in CF to return a Newline character combination. Good thought! So I changed the CF side to be as simple as possible. Here is the CF code that returns an empty string; guaranteed!



<cffunction name="fCallForName" returntype="string">
<cfreturn "">
</cffunction>




So nope, empty string still produced new line in the JavaScript output. So a few brain cycles go by and
I get to thinking to check to hit servers directly (bypassing amazon ELB altogether) and see what is returned. The return this time is enlightening, there is a blank string rather than the expected empty string, but no newline.



  <script type="text/javascript">
    var myName = ' ';
  </script>



Yeah, progress, maybe? This is different, which again it should not be. Thus, the only thing this establishes is that the Amazon load balancer (ELB) is changing the output stream somehow. Then, I also remembered an earlier blog post of mine where I outlined that CF inserts an empty space character when the function output is used directly in place in HTML context:  http://boncode.blogspot.com/2009/03/cf-coldfusion-functions-and-case-of.html
... and the fog began to lift.

I immediately reassigned the function output to a variable like so:

<cfset userName = fCallForName()>

Then, used the variable to output the content of the function:



<cfset userName = fCallForName()>
<cfoutput>
  <script type="text/javascript">
    var myName = '#userName#';
  </script>
</cfoutput>



...and bingo, everything started to work again. No more JavaScript errors. However the conclusions here are more scary then the error:

a) ColdFusion does introduce more than just a space character when function output is used in place
b) Amazon elastic load balancer makes modifications (corrections?) to the network stream and changes the output. For each in place output of function call it adds a line break.

Both a) and b) should not happen, but they do ;o(
At least now my pain could be your gain. Cloud pittfals, I guess...simple assumptions like surely the load balancer will not modify my data could throw you off .

Cheers,
B.