First AIR App: JSON Viewer

I was debugging a problem the other day, and needed to inspect some JSON that was being sent out by a web application. Now we all know that JSON is superior to XML, right? However, one nice thing about XML is that I can grab a blob, throw it into an editor, and have the editor pretty print it for me. This is especially helpful when debugging the XML in question. It makes it easier to spot a mistake in the structure, or to simply navigate to a given value in the hierarchy.

I did some looking around for something to parse and view JSON for me. I found JSON Viewer from CodePlex. It is really nice. However, it is Windows only. I do some development on Windows, but a lot on my MacBook as well. I wanted something that would work on either.

Instead of spending more time looking, I decided to code. A year ago I might have written something in Java, but I decided this was a good chance to write something in ActionScript and leveraging Adobe AIR to create a desktop application. The result is an AIR-based JSON Viewer. It looks really ugly, but I'm no designer. It uses Adobe's corelib to parse JSON and then just massages the resulting object into a structure that can be read by a Flex Tree control.

One fun use of it is to go to some of your favorite sites. Open up Firebug to watch traffic. Look for some JSON, plop it into the app and take a nice look at the data being sent over the wire to your browser (or from your browser in some cases.)  Of course some foolish sites still use XML over the wire, but most of the bigger and/or newer ones use JSON.

Meebo Platform and ActionScript

It has been a month or so since Meebo announced their "platform." Platforms are all the rage these days, six months after Facebook made everyone envious with their F8 platform. One interesting thing I noticed about Meebo's platform was that they gave you your choice of programming in JavaScript or ActionScript. How nice. So I took a look at their ActionScript support.

Several things jump out quickly, but let's state the obvious ones. They provide a Flash component for Flash 8. Now it's cool that they provide a component (even if "installing a component is arcane), but Flash 8. Seriously? Clearly this is something written in ActionScript 2.0. Now it would be one thing if they wanted to provide some support for AS2 developers, but what about AS3? It just seems crazy for a brand new platform to not support the latest version of one of the two languages it supports. It would be like Silverlight only supporting C# 1.1.

There's also the issue of providing support for the Flash IDE exclusively as well. I guess with AS3 support only, this is all you can expect. The Flash IDE is not made for developers, it is made for designers. Flex Builder is obviously the choice for developers, though it has its drawbacks.

I didn't see if Meebo provides the source code for the SWC. If they did, it probably wouldn't be too hard to compile it for AS3. Actually you might be able to use the AS2 component within an AS3, I haven't tried that. Still, if you're going to launch a me-too platform, at least do it right.

Mo' Ram

I've been working some lately with DB2. The worst thing about DB2, at least for a Mac-totin' developer, is that DB2 is not (yet) available for OSX. So what to do? I already had Vista installed on my MacBook via Boot Camp. So I installed DB2 on there and ... developed under Windows. Ugh. Running DB2 and Eclipse at the same time often resulted in not only a slow computer, but Eclipse stack overflows and out of memory errors. Funny how I never had such problems on OSX.

Once that project was done, I decided to upgrade the memory on my MacBook. The max it handles is 2GB (I had the 1 GB that was stock) so I went with that. So where to get the 2GB? Well there is always Apple @$300. Ouch. A better choice is Newegg, of course. For a change though, I found an equally good deal at Fry's, just up the road from my office. 2x1GB sticks of Patriot RAM for $65.

Now it was time to install the RAM. I am always quick to tell people that I am a software guy, not a hardware guy. However, Apple makes it really easy to install RAM on the MacBook. It took me like ten, maybe fifteen minutes total to upgrade the RAM. It could not have gone smoother.

The extra memory has inspired me to give Parallels a try. So far the results are mixed. Every time it launches, I get a message form Parallels saying it is installing Parallels Tools. Then Windows crashes (blue screen.) It reboots and seems ok, but it's still aggravating that it does this every time...

Black Friday

Yesterday my wife convinced me to go shopping with her and her sister. Normally I dismiss the idea of shopping on Black Friday, smugly stating that people should just buy everything online. Long lines, supply shortfalls (artificial or not,) and the like are all just signs of inefficient markets that will be replaced by the ruthless efficiency of e-commerce. Somehow Crystal talked me in to hitting the mall at 7 AM...

One amusing thing to me is the bait-n-switch items. These are the "limited" quantity items that are offered at a huge discount (do stores actually take a loss on these things?) in order to get lots of people in the store. The store then runs out quickly, so customers wind up buying other, more expensive items. This year's bait-n-switch special was definitely GPS units. Not only did every big-box store out there have sub $200 GPS units in limited quantities, but places that don't normally sell GPS had them as well. Get your GPS at Long's Drugs or Sportsmart, woo hoo!

Black Friday was actually a lot of fun. My niece has managed various American Eagle stores for the last ten years or so, thus I have a lot of empathy for the folks who work on Black Friday. They all seemed to be in a good mood yesterday, and I had a good time joking around with people.

Black Friday had a dark moment for me though. I managed to drop my Blackberry in a (thankfully clean) toilet. I fished it out quickly, and took the battery out of it. I waited a few hours, and it booted it up. The keyboard was crazy though. Sometimes it would not type at all, but other times keys would be entered without me touching anything. So I took the battery back out and left it out over night. This morning everything is working good as new! What a relief!

Yesterday ended on a very bright note. We are going to Florida for Christmas this year, so my wife decided to give me an early present: a Nintendo Wii. She didn't want to try and hide it from me in the luggage, and this way we got to play it with our family in Bakersfield. I am happy to say that I have a sore shoulder this morning from playing Wii Tennis late last night... She asked me if I wanted other games for it, but I really did not expect a Wii and had no idea what games are supposed to be good on it. I will probably get Madden for it, just because I used to love Madden on the PS2 and Gamecube. Guitar Hero looks like a lot of fun, too. I have basically taken the last 3.5 years off from playing video games, as I stopped having time for stuff like that when we started having babies. I'm not sure how much time I will have to play it now either, maybe once I finish my book :-)

The Network Application Pattern

    Several years ago I worked in consulting. My company was hired by larger companies to build web applications. We worked on internal web applications, external ones, and even some that were completely consumer focused, like the Washington Post Jobs site. Often we wrote applications that replaced existing desktop applications. Many of these were so called thick clients or client-server applications.
    The list of technologies was all over the place: PowerBuilder, Swing, and Visual Basic. The reasons for the conversions were pretty similar though: make things more easily accessible. It was much easier to say “you need InternetExplorer 5.5 or higher” to run an application, than it was to require somebody to download and install, and stay upgraded to the latest version of an application. The hardest part about these conversions was trying to reproduce all the functionality. You just could not do it, and there were always compromises that you had to work out with the clients on this.
    These days I am starting to think that such compromises are unacceptable. The days of the thin client are coming to an end. At the same time, the days of the thick client are not coming back. Instead a different pattern has emerged, and it is going to win. I call it the Network Application, though other folks have different names and different takes on it. Here is what it is.

Misuse of Big Iron

    To make things as accessible as possible generally meant to require as little as possible on the end user’s machine. The browser wars necessitated this as well. Inconsistencies across browsers required a least common denominator approach. The browser become a rendering device, and nothing else really.
    All the computation required to determine the interface shown to a user was performed on servers. For awhile these servers were Big Iron -- look at how well SUNW did in the late 90’s. Moore’s Law caught up and lots of cheap servers replaced Big Iron, but the usage pattern remained unchanged. Programming languages flourished around this. Look at all the UI frameworks in Java, the explosion of PHP, and the emergence of Ruby on Rails.

Another Shift

    I am not one of those melodramatics who look for a single event and say “this epoch caused everything to change.” Things started changing. Browsers stabilized and Moore’s Law kept moving along. Microsoft’s attempt at subverting web browsers by creating IE-only extensions, ultimately backfired on them. They created XMLHttpRequest, which ultimately allowed for exactly what the Netscape think tank had always hoped for and Microsoft always feared: web applications that were on-par with desktop applications. Well sort of...
    Web applications still have a lot to be desired. As I mentioned earlier, it can be really hard to reproduce a desktop experience in a browser. There are a lot of things going on to solve that, and some of them might even work. Orthogonal to the technologies at play is the pattern of how to program applications that are as feature rich as desktop applications, but can be run from a browser with no software to download or worry about updating.

The Pattern

    The key to the pattern is to stop using servers for creating user interfaces. If you like to think of UIs using the popular Model-View-Controller paradigm, the server should only be a place for Models. Your View and your Controller should be running on a client computer, not a server. Your server will probably serialize a Model to send to the client so it can use it in a view, but otherwise the boundaries should be very clear.
    Why does this help with the problem of creating desktop-like applications? Because when all the view logic is located on the client, there are no limitations to the interactivity. For an example, think about infinite scrolling like you see in Yahoo Mail (I usually rip on Yahoo, so I thought this would be a nice change of pace.) If the view of the list of your emails is formed on a Yahoo server, then to scroll past the bottom means recalculating that view on a Yahoo server, even if it is to show one more email that is just past the bottom of the list. If you had to do it that way, you would not allow scrolling. You would force pagination, like GMail does. However, if you already have the code for creating that view on the client, then all you need on the client is the data to display.

Servers Are for Services

    The beauty of this pattern is that your servers become specialized in serving up data, not HTML. There is still some overhead in de-serializing the request and serializing the response and making it all work over HTTP, but it’s a lot less than the alternatives. Of course it’s not a read-only world, so you’re not just sending out data. You are also receiving changes to the data, either directly, or (hopefully) via a service interface. Just because we’re getting clever with our presentation design, doesn’t mean our middle-tier design can be garbage.
    Notice I used the Service word. This is the same word used by those SOA guys, and it means the same thing. There’s no reason that the clients that you build for your service (in this case user interfaces) cannot leverage the same infrastructure that clients built by other folks use. Now you may want to expose more services to the user interfaces that you built, or maybe you don’t... The point is that if you decouple the so called business logic of your system, then it is easy to build Network Applications that provide rich user interfaces to the end users of your system.

Implementations of the Pattern

    Like most patterns, this was one has emerged from implementations. It is not something I dreamed up in my ivory tower in San Jose. One of my favorites is the Google Web Toolkit. GWT let’s you build things kind of like you would for the old-school thick clients using Swing, but it turns around, turns everything into code that runs on the client. One of my friends was starting to learn GWT recently and I think he was surprised when I told him that everything in GWT becomes static assets that can be served up by any web server directly. They are very cache-able assets as well... There are GWT ways to hook up your server calls as well, and of course this does require a Java application server. But that part of your code can be done in JavaScript, using GWT’s JavaScript Native Interface (JSNI.) The nice thing about using the GWT server code is that you get to use the same object model on client and server.
    GWT is tied to JavaScript, and thus it inherits the limitations of JavaScript. My other favorite implementation of the pattern is Adobe Flex. Flex Builder 3 even has code generators for creating Java or PHP data services for communicating to your Flex application. Flex applications run inside the Flash player, and don’t have nearly as many limitations as JavaScript applications. Flex applications are usually much bigger than JavaScript ones, but are also very cache-able. Bandwidth is becoming less of an issue in terms of user experience, though it is still a cost issue.

The Moral of the Story

    If you are a UI engineer, you should not be writing HTML. You should only be writing code that executes on the client. There are many other options out there. In the JavaScript world, there’s Dojo’s Dijit, the Yahoo UI Library, even script.aculo.us. Ruby on Rails’ RJS has some similarities to GWT, but is not there yet. The Rails guys are still perfecting the last generation of web applications, and have not moved on yet :-) Straddling the JS and non-JS worlds is OpenLaszlo. I would be more enthusiastic about Laszlo if it was using new Flash technologies. On the non-JS side, the two chief non-Flash entities are Microsoft’s Silverlight and JavaFX.
    Now again, these are all technologies that can be used with this pattern. They can also be used outside of the pattern, though I would say that is probably a mistake :-)

FUD by Doug Crockford

I like some of Yahoo's Doug Crockford's ideas on JavaScript. So I watched this talk by him on the State of Ajax. It has a great buildup on the history of computing and comparing pre-Ajax web apps to the IBM 3270. He's also a clearly opinionated guy, but he really lets this influence his statements. Examples...

He claims that Java applets failed primarily because of "write once, run anywhere" was a broken promise. That's ridiculous. First off Java applets only needed to succeed on Windows, so write once, run anywhere was irrelevant for a desktop technology. He does correctly state that Java UI (AWT) was no good. He commits a lie of omission, by failing to mention Microsoft's JVM infringements. He then says that Java succeeded on the server because (wait for it) write once, run anywhere is not an issue on the server. Not only is this wrong, it's the opposite of the truth. When I first started writing Java server apps in 2000, I was writing it on Windows and deploying it to Solaris.

Next he heaps praise on JScript and says that its "bugs" were just reproductions of Netscape's bugs. There is some truth in this, but it certainly shows his bias. He states that JScript inveted XMLHttpRequest and that there no innovations for five years after that until Jesse James Garret "discovered" Ajax.

He completely ignores Flash. Earlier he states that write once, run anywhere is really difficult and anybody that can pull it off deserves credit. Well Flash pulls it off. He claims that JavaScript pulls it off, but that's just plain wrong. I don't know how somebody who knows JavaScript so well can state this. He's smart enough to know all about doing browser sniffing and conditional logic based on the results of that sniff.

Flock 1.0

In case you missed the news, Flock finally went 1.0 late last month. I've been playing around with Flock for over a year. They're integration with social services has gotten better and better. I did a clean install of it and setup my Flickr, YouTube, and Blogger accounts very easily. I've given up on using it for RSS, as having a server-based solution (Google Reader) is too valuable to me. They've also added Facebook and Twitter integration, two favorite services of mine. Both are well done. And of course it's based off Firefox 2.0 now, which is great. Most Firefox plugins work great with it. I'm using its blog writer right now, as I'm planning on using it as my primary for a week or so and then figure out if I should go back to Firefox or not.

Blogged with Flock

Big Foosball Gamez

I thought about writing about Open Social, but I'll leave that to Terry for now. Besides, football is more interesting, at least this week. I'm very pleased to see Florida's defense finally stop somebody, even if it was just Vanderbilt. Vandy's defense was ranked #14 in the country, which just shows how good Florida's offense is. Last week's game against Georgia would have been a lot different if Tebow hadn't got his shoulder dinged the week before. He's Florida's "conservative" offense, i.e. their ball control offense. The running game is an option running game, i.e. it is geared towards big plays. I'm not saying Florida would have won, that would be crazy. But Georgia had plenty of time to expose Florida's weak run defense, and boy they did a good job of that!

Anyways, the NFL is where all the hype is this week. That's one nice thing in college football. You have a lot of "game of the year" type games, seemingly every week. That's a direct consequence of the no playoff system where every loss is potentially catastrophic. People want a playoff (me included,) but just remember what you'll lose if you get that. This week has a game of the year in the NFL: New England at Indianapolis.

I hate New England. I'm a Dolphin fan (please no snickers) so I have to hate them. But I respect them. I respect using technology to "cheat". I so wish Miami was doing that, though I wouldn't want them to get caught. They really need those draft picks. I also respect running up the score. This is not high school or even college (both places where you see much more running up the score) where you could maybe have sympathy on an over-matched team. Nope, it's the NFL: home of the Marxist salary cap. Everyone is making crazy money, including the coaches. There's no room for sympathy. Now, personally I would probably be more careful about exposing my starters to injuries in meaningless games, but whatever. That's their risk to take.

All that being said... I hate New England. I don't mind Peyton Manning too much. After all, he never beat Florida and he can never change that. So go Indy.

On a more a logical basis, New England's offense doesn't match up that well to Indy's defense. The whole premise of Cover-2 is to minimize big plays. It takes a big armed QB to hit the deep gaps in a good Cover-2, and Tom Brady does not have a big arm. That doesn't take anything away from him. Brady is one a few great QB's without a great arm. Cover-2 with good safety play should neutralize Moss and Stallworth. I still think teams should be able to run on Indy, but have a hard time believing that New England will be the first team to do that effectively.

Indy's offense is more diverse and has been executing against defenses every bit as good as New England's. Recent history seems to indicate that Belichick has not been able to "solve" Peyton Manning for the last couple of years. Without a strategic advantage, New England's defense does not stack up well against Indy's offense. The opposite cannot be said. So, clearly you gotta go with the home-dog Colts.

ActionScript Getters and Setters

It's always nice when a programming language surprises you in a pleasant way. ActionScript 3 has get/set property syntax, very similar to C#:

 public class Person implements IPerson
 {
  private var m_name:String;
  
  public function get name():String
  {
   return m_name;
  }
  
  public function set name(value:String):void
  {
   m_name = value;
  } 
 }

What was an even nicer surprise is that you can define properties in an ActionScript interface:

 public interface IPerson
 {
  function get name():String;
  function set name(value:String):void;
 }

And then write code that makes it look like you're accessing the field of an inteface:

       var person:IPerson = new Person();
       person.name = "Michael";

Now if only we had this syntactic sugar in Java...