AJAX or Flex

Flex
© dion gillard

Dare Obasanjo and Shelley Powers have been blogging about whether or not AJAX has a future, and what are the candidates for something to displace it. Timely, as I've been looking at some of this stuff recently, trying to get myself to play a bit in the client space.

Dare notes the development process is "a mess". I'm actually ok with it; it's not so terrible to not have a completely integrated development environment to do ALL your work. Even with Eclipse as my primary development IDE, I still have to shell out to PhotoShop or The Gimp to edit images. And I like that most of the tools are replaceable. I can freely move between Eclipse, TextMate, BBEdit, whatever, to do my raw text editing.

My problem is the mess that is DHTML development. Face it, JavaScript is a bit of a mess. As an OO fan boy, I like to frame solutions to problems in classes. And to do that in JavaScript is not terribly clean, certainly not intuitive. Most of the IBMers playing in the AJAX space that I know, are using dojo, and rave about it. Dojo adds a bit more to the learning curve for JavaScript, and I've not found a lot of decent documentation for it either. My take on dojo is that I need to know about all the wonky stuff in JavaScript, and HTML, and CSS, and then dojo itself, to get something done.

Which led me to start looking at Flex.

There seems to be lots of good doc for Flex, and while there's certainly another learning curve involved, over the top of whatever JavaScript you already know (because they use a next-gen JavaScript called ActionScript), the one nice this is that it's fairly self-contained. I can build out a lot of functionality in single .mxml files. There's not really an attempt to build a higher level framework over the top of the legacy of HTML, JavaScript, and CSS.

This kind of suits me, and since I tend to be a bit of a contrarian anyway, suits me even better amongst my IBM colleagues :-)

Dare also bring up WPF/E, but I'm not going to give it a serious look until I hear they have some semblance of a story for Linux.

Now, back to the matter I started with: Flex or AJAX; will one win over the other? I doubt it; each has their place. Think about this: could you build a GMail with Flex? The answer is a relatively simple "no", I think, because there's a critical bit of functionality that Flex does not provide: being able to imbed rando HTML in your app. Flex seems a bit constrained here. However, since a lot of email comes over as HTML now adays, how on earth are you going to render it in your app? At best you'd need to do this as a hybrid app; part Flex, part HTML. Great (not). Exact same argument for Google Reader.

Another pain point is printing. The printing story for Flex is pretty low-level. Sometimes I just want to 'print the page', but it's not completely clear to me how well that would ever work out.

So I'll claim there are certain apps for which Flex is simply not appropriate. And there are other apps, for which Flex will be just fine.

For my own selfish purposes, I actually do want to play a bit more with the weird and wacky MDI-ish mini-windows in my browser page thing a bit more. That's me, I'm a geek. And Flex seems to have a better story there, for now.

And I need to start doing some homework on Apollo.

In a stroke of complete 'small world', I found the flickr picture above via a search of "flex". It's from dIon Gillard, a name I remember back from the happy REXX years. Script on!

JSON array vulnerability

Unsafe appliance
© David

Robert Yates points to an odd vulernability of JSON, in at least Firefox, having to do with an overwritten, user-supplied Array constructor. Sigh.

Some thoughts:

• I don't like JSON because it happens to be directly eval()-able by JavaScript (and maybe Python). I like it because it's fairly consise, textual, and contains the bare minimum set of primitive and composite data structures from which all manner of useful data structures can be built. Having it be eval()-able was just a nice-to-have. I have recommended to people they should never use eval() though. There are JSON decoders available for JSON. Do you really want to be subject to someone injecting a function invocation into your datastream?
• Although I like JSON because it's consise, it can actually be made more consise, although rendering not legal JavaScript anymore. Perhaps that would be a good thing. :-) For instance, the commas separating array elements and key/value pairs seem to be completely extraneous. Likewise, quoting keys, for keys that contain non-special characters, is overkill. Fixing both of these would make JSON a lot more readable:

  Legal JSON:

  { "Image": { "Width":800, "Height":600, "Title":"View from 15th Floor", "Thumbnail": { "Url":"http://scd.mm-b1.yimg.com/image/481989943", "Height": 125, "Width": "100" }, "IDs":[ 116, 943, 234, 38793 ] } }

  Consise-r JSON:

  { Image: { Width:800 Height:600 Title:"View from 15th Floor" Thumbnail: { Url:"http://scd.mm-b1.yimg.com/image/481989943" Height: 125 Width: "100" } IDs:[ 116 943 234 38793 ] } }
• Joe Walker notes the Array constructor vulnerability only occurs for JSON which has a top level array, and not for arrays included in a top level object, presumably because the interpreter balks at the object notation, considering it a code block instead. A code block with a quoted string followed by a colon in it, which is not legal JavaScript for a code block. However, I was able to get a JSON object, without quoted keys, to kick off the Array constructor vulnerability. Now I see why quoted keys are important. Presumably the non-quoted key looked like a code label. Did you know JavaScript has labels?
• Uncle Ben says: "With great power ....". Sure, it's really nice to be able to add methods to built-in classes, override existing methods / constructors (classes), but ... there's a cost. I'm not sure the cost is worth it. Perhaps it's time we started thinking about moving some of the wild west capabilities out of JavaScript, or at least out of user-land JavaScript. Steve Northover had a great presentation years ago on the dangers of class extension in Smalltalk; for you youngsters, that would be the ability to add methods, etc to existing classes. One of the few things I dislike about Ruby. I should see if he still has that presentation around somewhere.
• Perhaps it's time to take another look at YAML.
• Flex is looking better every day.

As a complete aside, Robert added the info about the vulnerability in an update to a previous blog entry. That update never showed up as an update in Google Reader. Maybe because it's RSS, and not Atom? Bummer. Somehow Robert Sayre noticed the update, and I noticed Robert's entry.

not an observer sport

Observer
© Bobby Magee

From Programming Erlang, by Joe Armstrong, chapter 1, "Getting Started":

Did you actually run the shell on your system? If not, please stop and try it now. If you just read the text without typing in the commands, you may think that you understand what is happening but you will not have transferred this knowledge from your brain to your fingertips - programming is not a 'observer sport.' Just like any form of athletics, you have to practise a lot.

He's so right. I always try to write and run samples from books I'm learning from, even if I'm just copying the programs right out of the book. For most languages, there is a certain amount of muscle memory that your fingers will need to get; finding the '$' for PHP, for instance. But even beyond that, learning the keywords, control structures, indentation, etc is always easier when you are writing it, than if you're just reading it.

On a completely unrelated topic, but pointing to the same web site, I really like the direction the Programmatic Programmers are taking in the programming publishing field. I bought the Programming Ruby book and the PDF from them, and have used both, most recently using the PDF more than the book. If I like this Erlang book, which I can download preview chapters for, I'll probably just buy the PDF version and not the dead tree version. The price is right. And no dumb DRM in the PDF either; for instance, I copy/pasted the section above right from the PDF. I did have to fix the quotes and dash characters though.

No, it doesn't work

Everyone seems to be all atwitter over Twitter. James Governer blogs about it, the Joyeur guys podcast about it, etc, etc.

This one, a bit like Second Life, sounds interesting, and at the same time, a waste of time. But I'm always trying to keep an open mind. So a few days ago I got an account, figured out how to 'follow' someone (though not sure I could do it again), and then waited for something to happen. Which it didn't. So this afternoon, I go to the site, click the Help link, only to be told "It works!".

"It works!" in some default goop that Apache dumps on your system when you install it. Basically, if you haven't finished configuring your server, or malconfigured your server, expect to see a web page saying "It works!".

Searching for some more background on "It works", I found this following hilarious exchange:

http://www.mail-archive.com/debian-apache@lists.debian.org/msg08515.html

Make sure you read the response 'marked as done'. I may be reading that wrong, but it appears that a program decided to change the status of a bug based on the text in the subject line of the message.

This is reminiscent of the lovely authentication messages in CVS, "I LOVE YOU" and "I HATE YOU", especially when those messages leak out to the user.

Anyhoo, still no idea how to 'use' Twitter, but I think I'll survive.

BTW, I enjoy the Joyeur podcasts, "ps pipe grep", referenced above, but that might just be because I'm a customer; my teeny web site is hosted there.

java closure horror

Mechanical Horror
© Goran Zec

If the intent is to push people even farther away from Java, they're on the right track.

The very first comment there is spot on; Java needs type inferencing. With type inferencing, we could have gotten some of the benefits that generics were supposed to bring, without the horrifying syntax. # of Google hits for 'java' 'generics' 'horror': 541,000.

I'm not sure what to say about closures, none of the suggestions look very good to me. I'm still trying to recover from having to work on projects where people are starting to use generics. Luckily, because annotations comes along for the ride when with generics (in JSE 5), and Eclipse has handy dandy 'quick fixes' for adding a @SuppressWarnings when I want to write tidy code (ie, remove the generic crud), life is somewhat liveable.

browser smalltalk

small bridge big sky
© Radoslaw Stypczynski

From Peter Fisk's Almost Smalltalk:

Smalltalk running in Flash is not that far away.

I got goose pimples.

Check out Peter's site, he's got some pretty cool demos up there. On my DE-mentor's advice, I KVM'd over to my sad, bored, win32 desktop, installed the latest .net and ie, so I could run his .net version. Gorgeous. Check out some of Peter's other recent posts for other demos.

But, I'm not sure I'm ready to go back to Smalltalk. Sorry, John. Or Lisp. I've grown attached to using [ ]'s for array access. etc. Although I will admit that I just wrote in a note to someone the othe day that I liked Ruby because "it's Smalltalk in text files". The thing I really miss though, is the Smalltalk browser. An unadorned IDE, that I can fiddle with in the IDE itself.

Ruby and JavaScript are tough customers in that regard, with the amount of wild-west coding going on. JS doesn't even have language-level features to create classes, though you can programmatically create something similiar enough. And Ruby has class extension madness. But maybe we can add a bit of rigour to JS. Define some nicer class definition structures that would be amenable to a browser grokking them, and providing some useful meta information. And from the vista smalltalk work from Peter, doing IDEs in a browser seems quite do-able.

And somehow, this also ties into RESTy resourcey goodness. Somehow.

hmmmm ....

BTW, the image to the right is in my new style of 'flickr pictur with an attribution'. Got the idea to 'inline' the title, owner, license from Mark Pilgrim, and converted my old Ruby commandline program to build the HTML, getf4b, to a Greasemonkey script, getfwa.

Lighter than HTTP

One of the things we discovered in Jazz was that when you start thinking of defining your product's remoteable APIs as services, that you find yourself in a position where you want your server to also be a client to these services. But you obviously don't want to be making a remote HTTP call out, from your server, back to yourself. That's not very light.

I will tell you that infinite recursive calls in a remote-to-yourself scenario are quite exciting!

Fixing the remote-to-yourself problem is simple when you know that other service you are calling is available somewhere in your current address space. Because you can just 'call' it. There are issues; like the fact that remote calls are always copying the 'parameters', but in many programming languages, passing arguments will occur by reference. Something to watch out for, when designing your services around existing programming paradigms like function/method invocations, and objects.

Now let's make the story a little more interesting. Say you want to call some service, which isn't in your address space, but is on your local machine somewhere. Do you just go ahead and pay the cost of issuing HTTP requests, like a real client, and let your existing server infrastructure handle it like a remote call? For such local calls, tcp/ip overhead (to localhost) is likely to be neglible, since often this won't hit your ethernet interface at all. tcp/ip stacks aren't that stupid. But there's still the HTTP overhead, and that can be significant.

I'm reminded of the old Network Vehicle project I worked on eons ago. We had this same problem. A Smalltalk program controlling all the devices. And a Java program running the user interface. Same box. Needed to chat. This was 1997, and while using HTTP wouldn't have been out of the question, it was clearly overkill. So, we developed our own 'protocol' over tcp/ip. Java could send us messages like:

DIAL 919-555-1212

and Smalltalk would receive the message and dial the phone. Smalltalk might send a message to Java, in reference to a voice recognition event:

DISPLAY MAP

Really, it was that easy. Of course, we had a finite set of messages to send, so coming up with a simple protocol was quite feasible.

But it makes me wonder if what sort of economies might be available by specifically avoiding HTTP, in the cases where it's not buying you very much to begin with.

---

Photo 'Think' with a nice CC license, by Francisca Ulloa. Found using the Flickr's Create Commons Search.

Software licensing and SaaS

I hate software licenses. Well, I kind of like the WTFPL. But most of them I don't like; they're simply too complicated. And there are too many of them. I was painfully reminded of this, like I need the reminding, by looking at the Ruby license which leads to the even scarier LEGAL file.

Sigh.

In contrast, the Python license is a thing of beauty.

I suppose a lot of folks don't care too much about software licenses. But as a software developer that would like to consume, reuse, and redistribute as much open/free software as I can get away with, and working at a big software development house that has a tendency to attract legal attacks, I can tell you, I care. Because my company cares. More complicated licensing scenarios mean more time spent with lawyers, and less time in my text editor.

However, while day-dreaming of our eventual future, SaaS, I happened to think that all the licensing nonsense just goes away. Because in the future, we won't be delivering software to customers, we'll be delivering the results of service requests. The output of some program. And at least for the GPL, it seems clear to me that I don't have any downstream licensing issues. As long as I never redistribute my programs.

But of course, that really goes against the spirit of certain licenses, and I'm thinking of the GPL in particular. The GPL was designed to allow tinkerers to tinker, but SaaS doesn't really lend itself to that model. Maybe that's a big downside of SaaS; the loss of freedom to tinker. But more importantly, will software licenses be extended so the concept of 'combining source/programs' applies to using a client program using a service over the network? Or is this already a concern?

Blue sky dreaming? Yeah, probably. But ya gotta dream!

BTW, we will clearly have to deal with software patents in the SaaS world.

---

Photo 'DayDream Believer' with a nice CC license, by Becka Spence. Found using the Flickr's Create Commons Search.

Rest. and be Thankful

Duncan Cragg's Business Functions | The REST Dialogues just blew my mind.

Here I was, all this time, thinking myself a RESTafarian. I had however, always believed there was a place for RPC-styled invocations. This is largely, no doubt, from the work I did on my previous project, Jazz, where we started with RPC-styled web services, and then added some REST ones. In my mind, I've been thinking all along that REST and RPC-styled services, together, are what it takes to feasibly build a complex web services based system.

But something about Duncan's arguments rings true with me.

One thing does cause me concern though. And that is dealing with concurrency of 'objects' on the server. Once your individual POST requests end up having to hit multiple objects, locking them, you need to start to be concerned about deadlocking. Not that this wasn't a concern before, but it's still a concern here, though Duncan seems to brush it aside too casually.

I'm not sure I believe everything can be boiled down to state-transition tables, but certainly it would be nice if they could. Makes me wonder if things like BPEL (well, a non-XML version thereof :-) make more sense than they otherwise seem to, to me, today.

My most interesting thought though, was what this means to programmers, in terms of the APIs they use to invoke these services and get the results back. RPC maps wonderfully to function/method call patterns. Do we really end up living in a world where every web service has the same set of method names available (but different typing for POST parameters, and POST and GET results)? hmmm. How else might we able to make the protocol interaction more palatable to ordinary programmers used to defining, implementing, and calling methods and functions that are more RPC-ish? Or is a functional programming style, that this interaction pattern seems best suited for, just the obvious way to do it?

Anyhoo, got some back-reading to do this week ...

As an aside, I also love the dialog style of argument that Duncan used. Not sure why, maybe it's easier to read than straight through narrative. Steve O'Grady also often does this, and I've tried my hand at it as well.

---

Photo 'Rest, and be Thankful' with a nice CC license, by Brian Aslak. Found using the Flickr's Create Commons Search.

Xdebug support for Eclipse PDT

A colleague of mine from the UK, Dave Kelsey, has just uploaded a bit of nifty new functionality for the Eclipse PDT Project. PDT stands for PHP Development Tool, the new name of the PHP IDE project at Eclipse.

The new functionality enables you to use the PHP XDebug extension. As shipped, the PDT project ships support for the Zend Debugger. For any of a number of reasons, you might want to be able to use XDebug instead of the Zend Debugger extension. Now you can!

Brief information available here, code and doco available here.

Dave hangs out on the eclipse.tools.php newsgroup on the news.eclipse.org NNTP server, if you have any questions, bugs to report, etc. Note that you need to be registered to the news server; if you don't already have a userid, you can get one from here.

Also note that Ben Ramsey just posted a blog entry about how to set up the Zend Debugger in Eclipse.

---

Photo 'Time to debug' with a nice CC license, by Henri Bergius. Found using the Flickr's Create Commons Search.