Flex Tooling

Tools of the Trade.
© Joe Dykes

Adobe Flex Builder 2 - $500. Youch. That's way over the sweet spot at which I'll willing to plunk down some cash for a software tool.

What is Adobe Flex Builder 2 anyway, assuming you don't want to follow the link above? A set of Eclipse plugins that provide a development environment for folks developing with Adobe Flex. I can only imagine this includes things like syntax-coloring editors for ActionScript / MXML, code completion for the same, debugging, etc. For $500, that's what I'd expect. But I don't really know what it includes, because for $500, I have no intention of ever buying it, myself. Why even find out what's in it?

I can't really complain about this; just over 10 years ago we were selling VisualAge Smalltalk for $3000 a seat. The price has gone up since then. And since Adobe is giving away the Flex runtime, they have to sell something to keep the stockholders happy. I'm not stockholder, so it's ok if I'm not happy about it.

It would interesting to see Adobe break this out a bit more, to make the tools a bit more approachable to various cheap-skates like myself. They of course have student pricing, but that doesn't help me. What about some kind of subscription model, like MyEclipse?

I'm not going to wait for that to happen. A lot of the literature I've seen around Flex puts the Builder 2 eclipse plugins right in your face, as if that's the only option you have to develop with Flex. It's not. I'd love to bookmark a link to the 'free' (as in beer) SDK, but the obvious download path goes through un-bookmarkable links (in Flash? heh), as well as a required sign-in to your 'Adobe account'. So here is the 'english bookmark'.

• Start here: http://www.adobe.com/devnet/flex/
• Click the tab "Downloads" under the title "Flex Developer Center"
• Click the link "Download and try" link under "Free Flex 2.0.1 SDK (included with Flex Builder 2)"
• Sign into your Adobe download account.
• Half-way down the page is the "Free Flex 2 SDK and Japanese Language Pack"

And I should note that the tools are implemented in Java. The list of platforms supported, assuming you have Java installed, include: Windows 2000, XP, Server 2003, Mac OS X 10.4.x, Redhat Enterprise Linux 3 or 4, Suse 10, Solaris 9, 10.

Whew.

After 'installing', you are left with a set of command line tools. Time to get busy!

So what I need to find out is how painful life will be without the amenties the Eclipse plugins presumably provide. I can deal without code completion and syntax highlighting. I might be able to fudge a bit on the syntax highlighting by using a plain old XML editor for the MXML bits, and maybe a JavaScript highlighter for the ActionScript bits. But I assume there is no story for debugging. That may be painful.

On the other hand, this is an opportunity to build some new tools. My favorite 'subject area' in programming. Programming itself.

new gRESTbook()

The Biggest Guestbook in the World
© edwin11_79

As atonement for my sins, I've started a new mini-project called gRESTbook. The idea is to actually stop spouting off about REST, and just waving the "it's easy and it's cacheable!" flag, and writes some code. An example. Of a really simple service, but complex enough to show all the interesting generic challenges. Remember web Guestbooks? That's even easier than the old todo list that we usually used to use as an example app.

I've been meaning to do this for a while. Actually, what I really want to play with is stuff like this (lifted from the project page):

• machine- and human-readable descriptions of services
• machine- and human-readable descriptions of data flowing through these services
• library-ized engines to handle common RESTy patterns
• programming language 'interfaces' that I can use to plug existing data into the library-ized engines
• finding out what nice looking client interfaces to RESTy services look like

But you have to crawl before you can walk.

And I also want to play with the client end as well, since there are plenty of unknowns in that space as well. Currently planning on using Flex for the client.

I'll sporadically post back here as significant function becomes available ...

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.