Usability Rule: A feature doesn't have real existence unless it's easy to use

I know someone has probably said something like this before, but it hit me today while using Git (well, git-svn) on a project.

A feature isn't really available until it's easy to use.

I have to ship off some skinning work to a remote team, but at the same time, I'm reacting to a fundamental change in the data model that I didn't expect. I don't want to be dancing around the skinning changes, so I made a branch for myself with git.

There's nothing exciting about any of that because that's exactly what I should be doing. The difference with svn is that I'd never think to do that. I may think of it in a "lab environment" or suggest it as a solution to someone else, but I'd probably never think "Oh, I should branch this guy and avoid pain later" in the situation I related above.

It's not because svn doesn't have an answer to branching, it's that branching isn't the first answer when it should be. I probably would have just tried to dance around the remote team's changes if I wasn't using git-svn.

You could argue that branching is a complex concept, but implicit in the story is that in svn branching is harder than in git. Since branching is hard enough for me to avoid it, svn is penalizing me for doing the right thing.

Of course, you could call me dumb or lazy, and I'll accept that. But not so dumb that I won't use git-svn or just git from now on.

Adding some generators to RubyAMF

I'm having fun adding some generators to RubyAMF. They should help get your RubyAMF project kicked off a little fast and in the Rails style. More over at RubyAMF.org

Yer all Jeenyusis.

I just wanted everyone to know that reading this blog makes u smrt.

Get a Cash Advance

CFUnited Express Presentation: Offline/Online with AIR

This last Friday (11/9) I was able to stand in for Simon Horwith and speak at CFUnited Express Bay Area, a mini conference by TeraTech. I spoke on the features of AIR that enable developers to build Occasionally Connected Clients.

I had a good time and I was surprised by the diversity of the topics and the way ColdFusion development is going these days.

I worked with ColdFusion for 5 years or so 4 years ago, but spent a lot of energy trying to get some different languages under my belt, and so landed where I am today doing Flex and Rails and Java and so on. I'm happy working with what I'm working with, but it's good to see that the CF community is keeping up with the times and even enjoying some new features that make other dynamic language frameworks like Rails so fun to work with, as mentioned by speakers like Sean Corfield

Here's a link to my presentation from Friday, which has links to the code samples I showed.

Google's Looking Out for Me.

It's not often I get excited about a User Interface feature as small as this, but I found this one pretty special.

I hopped into my Gmail and staring back at me was this:



That's Google, there, telling me without me having to track it down, that I may have a problem with my experience in Gmail due to third party software.

That's awesome. That is a good user experience.

They had to first decide that there was a problem affecting a good chunk of users (which means they are tracking that sort of thing meaningfully, not just to have the data around). Then they made a help topic on how to get around the issue. They didn't stop there. Not Google. They figured out how to tell that I was running Firebug and then told *me* that there may be a problem instead of waiting for me to figure it out the hard way.

It's nice to see that kind of user experience in action in something I use every day, not just being talked about.

Delegate Factories with Prana

I've been having fun with Prana lately. Prana is an IoC container framework for Flex under development by Christophe Herreman. Prana is sort of built with Cairngorm in mind, but it could work for any configuration and injection you wanted to do at runtime.

One of the benefits I can see is for rapidly prototyping an application with little to no knowledge of the service you may need to connect to for your data needs. If you can define the data model well enough, you could build your application with Cairngorm in such a way that all you'd need to do is change one file (or type of file): the Delegate.

That's the reason for the business delegate: to keep the application isolated from the implementation of the service layer.

I've written up an example of how I'm currently using this on a project and posted it at http://labs.effectiveui.com/examples/prana/delegates/. It's a pretty lame sample, but if you right click and select "View Source", it shows how I have created a DelegateFactory that gives my commands a Delegate that conforms to a certain interface. Then, using Prana, I can configure the DelegateFactory to build whichever implementation of the Delegate I wanted, without recompiling the application.

The benefit is that I can drive the application's data from dummy xml data, but the application doesn't care where that data comes from. As long as I'm write about the way the data looks, my Commands don't need to change once I switch over to a production ready Delegate.

First, look at the DelegateFactory. Notice that it contains a string, _delegateClassName which will contain the qualified name of the class I want the DelegateFactory to make. There's some type-checking in there once that string is set to make sure that points to a class that conforms to the interface. One last thing to notice is that I need to have the class of the delegate referenced at least once in the code so that it's compiled in. That happens on the line that says

private static var compileTheseClasses:Array = [DevDelegate]


So DevDelegate is the delegate I want to use at development time. That Delegate acts like a regular delegate that calls an HTTPService to get some xml. Instead of doing that, though, it just loads xml local to the swf and sends a ResultEvent to the LoadPeopleCommand as if a result had just returned from the HTTPService.

Once last thing to notice is the applicationConfig.xml which drives Prana. It's loaded by the InitializeCommand. In that first block there:

<object id="delegateFactory" class="com.effectiveui.examples.business.DelegateFactory" factory-method="getInstance">
<property name="delegateClassName" value="com.effectiveui.examples.business.DevDelegate" />
</object>


I tell Prana to configure my DelegateFactory with the delegate class I want to use. I can change this xml file at runtime, so as long as I make sure the Delegate is compiled in, I can change delegates whenever I need.

Of course that's just one of the uses of Prana, but I really like the ability to get up and running easily by making a development time delegate.

Flex needs a Custom Metadata Class

At MAX, I was really surprised to find out a sekret Flex compiler feature: You can keep custom metadata around in your Flex app. There's a tutorial with a really sweet proposed application for that feature at Christophe Coenraets' Blog.

The only thing about that example is that the entityManager needs to know to read the objects passed into its save() method for metadata. That's not a problem for that use case. BTW, you can read metadata with describeType()

What if I wanted to copy more of the JPA with Flex? Then I'd need the FPA (a mythical Flex Persistence API) to manage the instantiation of the EntityManager and pass in a reference at runtime. I'd need to inject the right EntityManager into any code that wanted it. Right now to do something like that we'd need to read every class, or intelligently read certain classes, to figure out if there were annotations to deal with.

It'd be nicer if we had a first-class Metadata class that got instantiated by the framework at runtime and knew about the class it decorated. That way it could do things like negotiating with the "FPA" to get the right EntityManager at runtime based on configuration data. It could then modify the object that had the metadata with no developer intervention. It'd look something like this, following Christophe's example:


[PersistenceContext(id='applicationPersistenceContext')]
public var entityManager:EntityManager;


That would mean that at runtime, the 'applicationPersistenceContext' persistence context, which could contain data about which database in SQLLite to use, maybe usernames and passwords or something like that... in short: configuration you don't want compiled into your code. That PersistenceContext object would know to inject the correct EntityManager into the variable 'entityManager'.

I think it'd be a great addition to the framework which would allow a lot more use of the "Dependency Injection Pattern" to help make easy to use frameworks for specific needs on top of Flex.

I've created an enhancement issue here: https://bugs.adobe.com/jira/browse/SDK-13002 If you agree, make sure you vote on the issue.