up, up, down, down, left, right, left, right, B, A

Seriously, I can't stress how cool this is.

Google Apps FTW!

My company recently switched from Microsoft Exchange in favor of a Google Apps for our domain's email, calendar, and instant messaging. The result: I was able to completely obliterate all traces of Microsoft Outlook as well as the rest of the god-forsaken office suite. It's a no-brainer, really. Globally-accessible email / calendar / address book that ties into your IM, as well. If for whatever reason I need to use some sort of bloated word processor or *shiver* spreadsheet program, I can always download and install OpenOffice (and immediately uninstall it). Seeing as how this migration process left us in a transitory position between IM providers, I've stumbled upon a new IM client, at the behest of some fellow coworkers ...

Digsby

Trillian is dead. Long live Digsby. This versatile little IM application supports all major protocols (including Jabber). Out of the box, it also supports email and social networking notification for all the usual suspects. Its ability to consolidate multiple contacts despite provider or account into a single aliased contact (with account messaging priorities) is mega-rad. It appears to be written in python and is very extensible with YAML theming and skinning. All contact list modifications and application configuration is centralized, so if you install the app on another PC, that's it ... you'll login with a completely consistent interface. Google Calendar notifications are in the pipeline, so double-plus to Digsby.

Firefox 3 RC3

I'm inpatient when it comes to well-written software. As such, Firefox 2 has recently been replaced with the vastly superior Firefox 3 RC3. An embedded SQLite database opens the door for all sorts of interesting extension customization and makes things such as searching history or bookmarks much easier. More importantly though, memory utilization is vastly improved, JavaScript execution speed is blazingly fast, and having the option of restoring state upon application restart (without having to annihilate the firefox.exe process, or install yet another extension) is pretty frickin sweet. Coupled with the Nightly Tester Tools extension, selective enabling of extensions that haven't yet been ported made upgrading a no-brainer. Uninstall Firefox 2. Install Firefox 3 RC3. All profile settings preserved. Duh.

Ultimate Defrag

What it lacks in leet 2.0 naming, this program more than excels for those of us stuck in NTFS / FAT32 turmoil. Raxco PerfectDisk certainly earned it's place in the land of milk and honey, having long promoted file contingency based on access times. However, this little freeware / trial application raised the bar. The addition of selective directory structure / file type defragmentation prioritization on a per-disk basis, alongside a crapload of fine-tuning options, and some disk sector eye-candy, all packaged in a 1.7 meg distribution is mad wicked. There is no defragger but Ultimate Defrag. I've never gotten a hard-on for a defragger ... before today ... honestly.

ReSharper 4.0 Final

I'm one of those guys. One of those Java developers who wakes up one day to find that something has gone horribly wrong. Suddenly, all you look at is C# code. I'm really no zealot, and despite the language being tied to the most pervasive of the antiquated software monopolies with an utter lack of cross-platform consideration, it really is a decent language. Visual Studio isn't half-bad, either, as anyone who's used their debugger is forced to admit (seriously ... they're listening). However, I could not imagine having to develop without Resharper 4.0, which is ironically developed by the same guys who put together arguably the best Java IDE, IntelliJ. The refactoring options, semantic static source code analysis, and other nerdly capabilities that this product offers are a necessity. Furthermore, the developers at JetBrains must be sustained on a diet of methamphetamine and Red Bull. It's the only way I can comprehend their ability to squash bugs as they do, having been privy to the Resharper 4.0 EAP development cycle. Another obligatory plug for JetBrains ... I'm now loving TeamCity over any other continual integration tool I've used.

So there you have it. Learn from the purge. Likewise, I'm interested in any nifty software that any of my 0 readers have stumbled upon. Unless, of course, you happen to mention Twitter, in which case you'll be shot in the face.

Edit:

CoolIris

I somehow have neglected to mention CoolIris, a whiz-bang 3D image and video player extension for all major browsers. I had thought it would be one of those eye-candy plugins that remains unused, but I've been surprised by just how much I actually like this thing. It makes browsing places like DeviantArt and YouTube much more tolerable.

Cairngorm is an under-sugared, bitter-tasting Grape ...

First, there's simply way too much boiler-plate code involved. One can argue that this is great for development pattern enforcement in enterprise environments where 80-bajillion programmers are all working on the same set of functionality, each from a different angle, but I disagree. Although segmentation is important, I don't think these divisions of labor pay off in an enterprise environment as well as people claim. Honestly, I tend to think of the enterprise development as synonymous with "slow," as all of my anecdotal experiences have taught me, despite having very clean, ideologically correct code abstracted out the wazoo.

Second, Its abundant use of singletons with the Model Locator pattern and no clear mandates of when to pass data down a view hierarchy or just hit the singleton, short of "use your best judgement," seems wrong to me. I know for a fact that excessive singleton usage hurts unit test capabilities, modularization (literally, Flex modules), and the ability to debug without wanting to drop-kick your laptop.

Finally, for the first two reasons, Cairngorm enthusiasts remind me of those crazy religious zealots who like to flagellate themselves out of some twisted sense of duty. I may drink the kool-aid, but I don't want to join that camp, thanks.

PureMVC is the somewhat questionable Tropical-Punch ...

Looks like PureMVC aims to alleviate developers of several of the common-complaints Cairngorm brings about. That's admirable, as is the goal of being ECMAScript compliant, rather than being ActionScript specific. However, in my initial glance, I'm seeing a lot of the same boiler-plate, only with more patterns at play, such as Proxies, Mediators, and Facades; all of which I have no real clue as to their intent. I suspect they're there to be unnecessarily confusing. I really need to learn up more and until then, judgment is reserved.

Joe Berkovitz's MVCS Blueprint is Cherry awesomeness ...

This should be considered more of a set of guidelines, rather than a framework, as there is no real distribution or official repository of documentation. That being said, there are a few things I can really appreciate about these patterns.

For one, the use of singletons is throttled to Controllers, Services and Session information. This just flat out eliminates the majority of problems a developer can encounter when exposing their Model in singletons. However, rather than having to pass reference down from a top level controller to a particular View, the View is allowed to directly ask for data from the Controller ...

Controller calls that require asynchronous interactions accomplish this with what some people have termed the Future Value Pattern (or just Futures). In this scenario, you construct a placeholder for your data in your Controller, pass it by reference to your Service call, then immediately return it. At some point, your asynchronous call will return to populate that reference, leaving your view to listen to bindings and update your UI. Very clean, very accessible, no unnecessary Event bubbling. This in itself helps to reduce a significant amount of boiler-plate.

Finally, Joe preaches the use of dependency injection with a base class that referenes Controller and Service interfaces, then a subclass which implements those via MXML. Think compile-time Spring IOC. This opens a lot of doors when it comes to developmental mocking, testing, and easily adapting code.

Those are my initial thoughts ... I plan to spend a good bit of time on this subject.

Edit: Here's a good presentation on frameworks by the developers of ASUnit. Definitely worth a watch if you're a total dork.

I've recently come to gain a greater appreciation of Actionscript and Javascript communication. I haven't had any pressing predicament to steer me into this new-found respect, just a few odd things here and there that have caused me to take pause. For example, I doubt it will remain this way for long, but currently Google has no AS3 mapping API. There are a couple out there such as MapQuest, but come on ... we all know that Google Maps is where it's at. So, I began playing around with ExternalInterface calls in AS3 to see how it could be done. Pretty straight-forward use of Flex / HTML windowing and JS calls. You can play with it here: GoogleFlexMap Or download it here: GoogleFlexMap Source.

Today, I also stumbled across a pretty interesting way of dealing with the lack of full support for "right click" events in Flash. Check out this blog posting for more info. Another good use of ExternalInterface calls.

I think the thing to take away from these examples is that you should never limit yourself solely to what one technology will allow you to do. You may have to jump through hoops, but often you can achieve what you seek out to accomplish. In the case of Flash and Javascript, I think it's probably a good thing to stress that Javascript calls should be as standardized as possible to ensure maximum browser portability. One thing we take for granted in Flash development is that sort of cross-platform consistency.

additional links:

return undefined; blog announcement

flexmdi example explorer

Lots of interesting presentations and discussions on Adobe's new runtime environment, AIR. AIR extends Adobe's previous offerings by providing desktop application development capabilities to programmers already familiar with either ActionScript / MXML or HTML / AJAX web development. Adobe's gone to great lengths to make this web to desktop transition as painless as possible, and I've gotta say, they've done a good job. The most compelling reasons for AIR development (as I see it), is cross-platform consistency, a clean API set, and the overall media hotness of flash within a networked desktop application. As not to sound too much like an Adobe evangelist, I'll just stop now.

My only gripe about this tour is the lack of focus on anything Flex 2/3. The line is blurring between Flex and AIR development, and I'd like to see where exactly those boundaries extend. For example, to what extent can one take advantage of the new JavaScript bridging capabilities within a Flex 3 application, if any at all? I suppose I just need to start playing around with Moxie ...

• remove "Pragma" headers
• remove "Expires" headers
• set "Cache-Control" as: "no-store, no-cache, must-revalidate, post-check=0, pre-check=0"

The original blog post is dead, but you should be able to access a google cache version here

The best way I've found to go about this is by extending mx.rpc.http.mxml.HTTPService and overriding the send() method. Using a little bit of AOP-style, result-handling kung-fu, along with an extended mx.rpc.events.ResultEvent that allows writing to the result property, calls can be made to this CachedHTTPService as you would normally expect, but behind the scenes the result is built either from cache (if it has already been populated) or from the original intended URL. No caching logic to muck up your business logic.

CachedHTTPService.as

Example Call:

(CachedHTTPService is defined and called just like HTTPService, only requiring an additional parameter, the CacheManager Implementation you wish to tie into)

Here is the CachedHTTPService Source, including the CacheManager interface and example implementation, as well as the WriteableResultEvent. Have fun!

The typical transport mechanism for this design pattern is our boy, XML, which despite it's faults (bloatedness, no strong-typing support, etc) is extremely well supported, especially by Flex. E4X notation and all kinds of XML convenience classes make XML parsing a breeze, allowing the developer to take an XML response via ResultEvent.result in an HTTPService result handler and start playing around with its data with zippy developmental overhead. The problem, again, lies in the actual conversion of this response to a strong-typed object. Often, developers will manually populate typed objects with the XML values within the HTTPService result handler. Unfortunately, this makes any changes to the model annoying, as now, each of these manual translations will most likely be affected.

This brings us to one of Flex's most well-hidden gems ... the HTTPService.xmlDecode property. When you pass the HTTPService.xmlDecode property a function reference, that function will be passed an XMLDocument object as its only parameter, which is generated automatically by the service. You can then take that XMLDocument, iterate through it, building and returning objects of whatever type you desire. When you access ResultEvent.result in your handler function, that property value will be typed based on your decoder return type. So ResultEvent.result is now, say a RabidSquirrel object, rather than a RabidSquirrel XML node representation.

The beauty of this strategy is, at any point, your transport mechanism becomes disposable. If you suddenly decide to switch from XML to JSON (woot!) as your serialization strategy of choice, you only need to code some decoder / encoder functions, and you're done. No need to change anything else.

This is probably best implemented with Darron Schall's ObjectTranslator class, which is capable of taking a raw Object and returning an instantiated strong-typed object in return. Combine this with AS3's SimpleXMLDecoder class, and you've tada, you're done. Here's a simple example:

The HTTPService Definition (note the resultFormat="object")

Decoder Method

And there you have it. If you ever wanted to change the model, short of modifying the classes, you wouldn't need to do any additional work. Personally, I favor JSON and have adopted this strategy as such, using the as3corelib JSON serialization tools. One significant benefit over XML is the typing that JSON supports, therefore making recursive graph deserialization much much simpler. The only thing to keep in mind, is that your decoder function will still need to accept an XMLCollection. However, you can always grab the firstNode value off this object for the full-text response of your non-XML serialized String.

EDIT: Below is an example implementation of recursively typing an untyped object as it is decoded. This is currently handled in a JSON implementation, but it should be easily portable to an XML implementation. Note that it is dependent on Darron Schall's ObjectTranslator class. I hope this helps some people out!