Andrew Powell

Amazon has entered the tablet market.  The Kindle Fire, however is not an "iPad killer". 

[Read more →]

Every couple of years I have to stop and shake my head at how damn cyclical (and cynical) this business is.  Sometimes, I can't help but feel like Marty McFly and get the feeling like I've seen all this before.  Everyone is, quite rapidly, getting caught up in the notion of this high experience, mobile, touch-screen, multi-device world and how revolutionary it is.  

We've sung this song before though.  It's nothing new.  

It's kinda like "O Canada" and "My Country, 'Tis of Thee" being the same melody as "God Save The Queen".  We know it's the same tune, just different lyrics.  With that thought in mind, let's take a look back and figure out how we got to this point and where we are going in the future.

When I first started building software (Omnis 7 paid the bills), it was all about client-server computing.  You had to have moderately powered desktops and a beast of a database server to house all the data.  Most of the heavy lifting of the data and logic happened at the client.  The server was, basically, just a database, if not in reality, just a database.  This made updating the applications we built a total pain in the ass because we didn't have a really well built out infrastructure to push updates to our clients.  Hell, even Microsoft sent updates on CD.  I fondly remember waiting to see what was in that month's TechNet update, but I digress.

As server performance increased at a faster rate than desktop performance did, the shift was back towards a centralized-type system that was a lot like the mainframes of yesteryear.  Hell, the system we used was even called MetaFrame to harken back to the mentality that all the processing was centralized.  Metaframe was an absolute disaster, but that's a story for a few beers and another time.  At that point in time, you had all the power you needed on the server to run the app, but you were still talking to the database, which was the centralized server component.  That part didn't go away.  

Not too long after that, along came the rise of web-based UI's.  This moved pretty much solidified the move of all the processing to the massive servers that we had sitting in data centers (or server rooms).  This paradigm gave rise to the concept of a middle-tier that took requests from the client (web server), processed the incoming data, made requests to the database, then sent the results back to the client.  

This was a defining demarcation because at this point, we would never really have all the logic in one place anymore.  The client could render and process some of the data and the server would still do most of the business logic.  This worked well, especially with the introduction of client-side scripting methodologies, like JavaScript.

In the middle of the last decade, we saw the emergence of the Rich Internet Application (RIA), be it AJAX, Flash (and Flex), or whatever your tools of choice were (and maybe still are).  This, again, signaled a new era where we moved a lot of the processing back to the client and relegated a good majority of the middle-tier to things like security and data access.  A lot of business logic moved towards the client applications, again.  

Fast forward a year or two to the present day. Now, we are in the midst of a new multi-device paradigm where we have a legitimate business need to have both consistent experiences and business logic across multiple devices (Android, iPhone OS, Windows, Desktops, etc.).  So what do you do?  Do you spend the extra money to duplicate libraries of business logic across platforms and create a version for Cocoa, Android, .NET, and whatever other platforms on which you wish to deploy your applications?  

In a word, no. 

You do the smart thing and move that common business logic back to the server.  The native user interface serves the relatively simple purpose of providing the face of the application, taking input from the user, prepping it for the middle-tier, passing it to the middle-tier, then processing and rendering the results.  The real work: security, data access, and all important business rules and logic are deferred to the server, again.  

So here we are, again in the circle, moving the most intensive processing back to the middle-tier and leaving our device native code to render the user interfaces.  History would tell us that the next phase of this will probably be much more powerful devices that can handle the processing of complex business rules and crunching larger amounts of data.  Achieving this will require us to find a way to create logic libraries that are cross-device.  That will require a change in the current environment where either everyone, or a good number of vendors start playing nice.  If that does or doesn't happen, history tell us that something will trigger us towards this paradigm in the next two to three years.  Let's hang on and see what happens next.

The other day I heard someone define iTunes as a RIA. I started to correct them because, until then, I had only thought of RIAs as being built with AJAX, Flex, Silverlight, etc; with these new RIA technologies. That comment though, got me to thinking. What does really define a RIA? Is it the technology that is used to build the application or how it leverages the power of the Internet (via SOA, etc.)?

After a bit of consideration, I have to say that an RIA is any application that leverages the power of the Internet to enhance the application. An RIA is not simply an AIR application, a Flex application, an AJAX application, or a Silverlight application. Any application that uses the internet to leverage new user experiences is a RIA.

So, that being said, iTunes is probably one of the best examples of an RIA out there. It changed the game when it came to music applications, adding the ability to subscribe to podcasts, share your library, listen to Internet Radio broadcasts, and the iTunes store itself transformed iTunes into the most ubiquitous and indispensable RIA we've seen yet. All that and it wasn't even built in Flex, AJAX, OpenLazlo, Curl, or Silverlight. It was built in Objective-C.

In the coming months and years as we see RIAs and the influence of SOA proliferate through ordinary desktop applications, we're going to have to take a long hard look at how we, as a community, define a RIA. I think we're heading towards a point where we really do define a RIA as any application, regardless of the development language, that leverages the Internet to deliver new user experiences to the end user. In the end, it would seem, we are all RIA developers.

I am pretty sure (others have confirmed) that the latest update for Mac OS X (10.5.3) nukes the debug Flash Player.  After installing, I went to debug a Flex app and it couldn't find the debug player.  A simple re-install of the player from your Flex Builder folder will fix the issue.  The Apple update page doesn't have any notice about the Flash player, but it is broken with the update.   This obviously means that Apple has snuck in a Flash Player update without any mention of it on their site.

http://support.apple.com/kb/HT1141

OK, so a lot of Mac users use TextMate for everything from text editor to IDE. I didn't realize this until recently, but you can blog directly from TextMate. If your blog supports the Wordpress, Moveable Type, and Type APIs. You get live spell checking thanks to the built-in integration with the OS X dictionary. You can edit existing posts in TextMate as well as new entries. You can upload images to your blog, simply by dragging an image into the editor window; TextMate will automatically upload it for you.

Don't believe me? Check out this YouTube video for more info:

BTW, this post was written in TextMate.

I've been seeing people splash this quote from The Wall Street Journal: "Apple's iPhone, with all its cutting-edge mobile Internet trickery, needs something much better than the current Flash player that Adobe makes for cellphones." Let's analyze this statement a bit and think about it. First of all, you have to realize that executives choose their words very carefully when talking to investors. Just ask Jeff Skilling what happens when you don't... asshole (read the article, you'll get it.) The quoted article specifically states that the iPhone "needs something much better than the current Flash player that Adobe makes for cellphones." This is not the true Flash player we all know and love. This is talking about FLASH LITE. I agree with that Flash Lite cannot deliver what Apple wants to deliver on the iPhone. Until we get Flex 4 and can build to mobile devices, Flash Lite is a joke. But, I digress.... I think this could be a bit of misdirection by Mr. Jobs & co. I am of the opinion that we will see either a Flash Player or AIR Runtime for the iPhone very soon. Just my two cents.

As everyone who is running Leopard and ColdFusion know by now, Leopard shipped with Java 5, and not Java 6. The performance improvements in Java 6 are too great to be left behind on the Mac. Fortunately, there is a solution: SoyLatte: Java 6 for OS X A simple change to the "java.home" variable in your jvm.config file and you'll be all set. Binaries are available, so you do not have to compile your own. I am currently running, in a development environment, under the 64-bit version with CF8 and it is smooth. Of course, YMMV.

Those developing AIR applications in HTML/JavaScript know that the engine that enables these applications is WebKit. Apple has just released a CSS reference for Safari and WebKit. Since AIR is powered by WebKit, this, in turn, also applies to AIR Applications. Explanation of Terms Supported CSS Properties

Leopard (OS X 10.5) and Flash Player 9 are not fully compatible. There is an issue with FileReference.upload() that is breaking not only Flash Player 9, but also AIR Beta 2. This issue is supposedly going to be fixed in the "Moviestar" release of Flash Player.