Linking to your GitHub code

It’s pretty easy to link directly to a line of code in your GitHub repo:


Don’t do that you naughty sausage! Your codebase will evolve (if all goes well), and line 16 will be replaced by a newer, shinier string of characters. Or, in this case, it’ll point to something that no longer exists.

This, on the other hand, is more likely to stick around to haunt its author (me):


Select a tag before you link to your fancy code (“Switch Tags” under GitHub‘s “Source” menu).

AS3 DI Metadata Tags

Spring Actionscript, Dawn, SmartyPants-IOC, Swiz, Parsley and SwiftSuspenders (used by Robotlegs) perform Dependency Injection.

Moreover they can all perform automatic DI by parsing class metadata. It would be grand if the common DI related metadata tags could be standardised. That way we really could write code that is decoupled from any particular framework.

I’ve started a little document over at GitHub:

I don’t know the libraries well enough to fill in all the details, so if you could fork the repo and edit the doc that would be great! Also, the format/layout could be better, so if you have any ideas on that front.. edit away.

Flexible RIA Architecture: PureMVC and Mate

I’ve been using PureMVC for my Flash/Flex applications for quite a while now, and have generally found it to work quite well. Besides the obviously annoying abundance of boiler-plate code, it does a decent job of separating concerns, and has helped me to build better applications.

Lately, however, I’ve been building an application for which PureMVC has turned out to be a pretty poor fit. The term that some people have used to describe this kind of application is “Document-Based”.

A benefit of MVC is the ability to easily create multiple Views of the same Model. Document-based is roughly the opposite of that: the ability to create identical Views of different data. Think OS X Finder (or Windows Explorer if you must!): multiple windows that look and function the same but show different parts of your filesystem.

I spend a lot of my time trying to learn as much as possible about programming. This means subscribing to a huge number of feeds and bookmarking obsessively! Looking for solutions to my current problem I re-discovered Mate. I hadn’t looked too deeply into it before as I needed an ActionScript Framework that wasn’t bound to the Flex Framework (ruling out pretty much every framework except for PureMVC). This time however, I didn’t mind binding(!) myself to Flex.

Central to Mate is the concept of an Event Map. UI components dispatch events that bubble up the display list and get caught by one or more Event Maps: loosely coupled goodness. Mate also employs Dependency Injection instead of the Service/Model Locator pattern used by Cairngorm and PureMVC. And no Singletons! Suitably impressed.

I highly recommend you check out Mate, and if I were you I’d do it in this order:

  • Mate Presentation by Laura Arguello: fairly long, and a bit slow, but quite fun and covers some really important concepts – not just for Mate, but application architecture in general
  • Hello Mate by Neil Webb
  • Mate Overview
  • Mate Document-Based Example by Theo Hultberg/Iconara: lots of great info

Ok, time for me to calculate how painful it’s going to be to switch my application over to Mate.

UPDATE: I posted my thoughts (as best as I could gather them) on the PureMVC forum here:

UPDATE: I decided not to switch to Mate for my current project. I wrote a little MVC framework (much like PureMVC), that uses Dependency Injection, and switched to that instead. More here:

AS3 Dependency Injection and [Autowire]

Warning: This is long and probably VERY boring.. unless you are an AS3 junkie, and you’re interested in so called “lightweight micro-architectural frameworks” for Flash and Flex.

A couple of weeks ago I played around with Mate and Swiz. I already knew a little about Dependency Injection (in theory anyway), but playing with those two frameworks really drove the point home: applications are potentially MUCH easier to write, and much more flexible, when you take advantage of Dependency Injection.

If you’ve used PureMVC you might be familiar with writing code like this:

var myProxy:MyProxy = facade.retrieveProxy(MyProxy.NAME) as MyProxy;

This is sometimes referred to as the Model or Service Locator pattern. Firstly, it’s a little tedious to write. But more importantly, it puts the responsibility on your class to “fetch” the things it needs – not a good thing (especially from a testing point of view). From the “outside” you can’t see what your class is dependant on: you have to review the actual code in your class to see what it wants to pull in from the outside world.

It’s also a bit sneaky: to get something out, you have to know how it was put in – splitting and spreading knowledge across your codebase. Not pleasant.

Alternatively, you could use a Singleton to hang all your objects on. That would not be cool: link, link, link.

Enter Dependency Injection

Another solution is to declare certain properties on your class as dependencies to be “given” to you on (or just after) construction. A Dependency Injection framework will take care of managing these dependencies and providing you with what you need. Your class can then focus on doing it’s job instead of worrying about how to get the objects it needs.

I Like The Mediator Pattern

And I like the concepts in PureMVC: Specifically the Mediator, Command and Proxy patterns. I like clean view components with absolutely no framework or application code in them – as made possible by the Mediator pattern. I like Commands and I like binding them to system events. I like Proxies, who only communicate outwards, by dispatching events, and who’s APIs must be accessed directly by Commands and/or Mediator instances.

But I don’t like the use of Singletons or Multitons, the Service/Model locator pattern, the spreading of knowledge throughout the system by the Mediator and Proxy registration and retrieval mechanism (you have to know how something was put in to get it out again), and the custom Notification scheme and it’s associated methods: listNotificationInterests and handleNotification (with that nasty switch!).

So, I like PureMVC, I just think it could be improved for certain use cases. Now, obviously, improvement is subjective. Designing a framework is largely a balancing act: every decision has a pro and a con, and the framework architect must weigh up the pros and cons to steer the project in a chosen direction. That direction is determined by the architects vision of the most important use cases for the framework. I think that PureMVC has been brilliantly designed when stacked against it’s objectives. It’s been very carefully thought through, has an amazing author and community, sports great documentation, examples and utilities, and does it’s job well.

YALMAFRIA (Yet Another Lightweight Micro-Architecture For Rich Internet Applications)

Mate and Swiz can both do Dependency Injection. What I found interesting about the Dependency Injection in Mate is that it’s event based – this allows you to look at the event target to determine the instance that is currently being injected into. Using that (and a thing called an Object Builder in Mate) I was able to configure my application to automatically create Mediators for view components as they arrived on stage, and set references to the view components on the newly created Mediators.

It worked, but it seemed a little klunky, and still required a fair amount of code to map a Mediator Class to a view component Class (and any other dependencies). Regardless, it got me amped – using Dependency Injection and automatic Mediator registration I could remove most of the boring (and brittle) code from my projects.

I decided not to use Swiz or Mate in the end. Both offer nice solutions to some of the challenges of building RIA applications, but neither would make building my current application any quicker or easier.

Besides: I didn’t like the idea of using the display list as a system event channel, as in the case of Mate, or the concept of a central (Singleton) event dispatcher, as in the case of Swiz. And I didn’t want to put ANY application or framework code into my view components, as both seem to encourage.

Also, I wanted a framework that I could use for both Flex AND plain AS3 projects. I believe that this is possible with Swiz, but certainly not with Mate.

So, I looked for an AS3 Dependency Injection library to build a(nother) micro-architectural framework on top of..

Back to Dependency Injection

I tried Spring ActionScript (previously known as Prana) first. Immediately, two things bugged me about it: the use of external xml files to configure dependencies, and the side-effect of that requirement:

When compiling a SWF the compiler ignores Class definitions that are not directly referenced by the application. A small problem, easily solved, but an extra step none the less to ensure all necessary Classes are compiled. Loading your dependencies externally is groovy, fo sho, but I really don’t need that right now.

I believe you’d enjoy Spring ActionScript if you’re from Java land (hello there, have you played with Clojure yet? it got me all jazzed for a spell.. even though I didn’t build anything useful with it).

Anyhoo.. check this out if you are interested in Spring ActionScript and Autowiring: link

Or this, if you want to see how to do a similar thing with Swiz: link

Inspired by Guice

Next I checked out SmartyPants-IOC. I liked the vibe and proceeded to build my little framework with it.

RobotLegs AS3

I decided to call my framework RobotLegs. It’s very simple really. It contains two factories (and some Interfaces):

A Mediator Factory – for automatically creating and wiring up Mediators as view components arrive on Stage.

And a Command Factory – for binding commands to events.

Everything else is handled by Dependency Injection thanks to SmartyPants. Conceptually, the framework is much the same as PureMVC, but uses DI in place of a registry, and built-in Flash Events instead of Notifications.

I was able to migrate my current project over to Robot Legs (from PureMVC) in about a day. Not bad considering there were dozens of Commands, over 20 Mediators and around 10 Proxies to convert. It was a bit of a mission creating all the custom Event Classes to replace my Notifications though.

But it was certainly worth it. My application code has tidied up nicely. Many of my Mediators, Proxies and Commands have halved in size, due to the removal of lookup code and notification body casting.


The cool thing about Mediators that automatically wrap themselves around view components as they appear is that it greatly simplifies dealing with composite, lazily instantiated view components. I don’t need to worry about how a view component comes into being, I just set up a rule that ensures when that view components arrives I have a Mediator to link it back into the application. This is great for items inside Tab Navigators, Accordians, View Stacks etc.

It does present a little problem however: context. When you manually create and register a Mediator, you have the opportunity to give it some context, such as setting a property on it. Mediators that get automatically created make this a bit tricky. We could, of course, set that property on the view component, to be picked up by the Mediator on registration, but that’s not cool – view components should be self-contained, stand-alone widgets.

My current solution is to allow Mediators to request properties from parent Mediators. This is made possible by the Mediator Factory, with it’s dictionary of currently registered Mediators and view components, and a method declared by the Mediator Interface called “provideProperty”.

I plan on releasing Robot Legs once it has settled down a bit – using it in my current project has pointed out a great many things that I had overlooked initially. It won’t be everyone’s cup of tea – nothing is 🙂

UPDATE: RobotLegs 0.1, with demo Flex app, has been released. More info here:


RobotLegs AS3: A DI Driven MVCS Framework for Flash & Flex – Inspired by PureMVC

Want a framework like PureMVC but without Singletons, Service Locators, or casting? Perhaps one with Dependency Injection and Automatic Mediator Registration?

Well, you might enjoy RobotLegs AS3: yet another lightweight micro-architecture for Rich Internet Applications.

It’s got the bits that I like about PureMVC (Mediators, Commands and Proxies) without any of the bits that I’m not so fond of (Service Locator, Singletons, casting casting casting!).

I’ve put the source up on GitHub, so feel free to Fork it and make it better:

Discussion Group:

Here’s a little demo:
(Please note: the API and usage has cleaned up a lot since this demo was built)

You can also view the demo here (with view source).

The demo app is perhaps not so great, but it demonstrates many of the framework’s features. AND, there isn’t a single cast in there! No actor casting, no payload casting, not any casting, not even for fun!

I have much to say about this little framework, but it’s the wrong side of 5am and I’ve had a crazy long day. In the meantime, you can find some background info here and here if you’re interested.

Update: RobotLegs Lives!

Getting Started with Git on Mac OS X

Some Background

I’ve recently switched from using SVN to using Git as my source control management tool of choice. It took a little while to get to grips with, but it rocks!

Git is not an evolution of SVN. It is entirely different. Git is a distributed revision control system – everybody working on a project has their own full copy of the repository and its entire history.

Git does not require the presence of a network connection: most commands in Git operate locally, allowing you to review your project history, make branches and tags, merge changes, but most importantly, allowing you to commit while offline.

If you’ve used SVN you’ve probably noticed the littering of .svn folders across your entire project tree, requiring the need for an export tool to retrieve clean copies of your code, and introducing problems when you delete, rename or move files or folders in your project. Git takes a slightly more sensible approach: it creates one folder (named .git) in the root folder of your project.

Git Concepts

With Git there are 3 important things to be aware of: the Git object database, the “index”, and your working area.

The Git object database contains a bunch of stuff that you typically don’t need to worry about. Essentially it’s the repository.

Your working area is the collection of files currently sitting in your project folder. You should treat these files as if they are temporary – because they are! Things you want to keep should be committed to the repository.

The Index is sometimes referred to as the Staging Area. It’s a list of what will get stored on your next commit. Conceptually it sits between your working files and the Git object database. Files that haven’t been staged to the index will be ignored when doing a commit. This gives you great control over what gets committed when.

A branch is a cheap copy of a particular state of the Git object database. Branches are easy to create and switch between, giving you a safe way to try out ideas quickly and easily. Switching to another branch updates your working area to reflect the state of that branch – this is why you should consider your working area temporary.

Installing Git on Mac OS X

Grab and install the latest OS-X Installer from:

Configuring Git

You need to tell Git who you are – it uses this information for your commits etc.

Fire up your terminal, and type:

git config --global "Your Name"
git config --global

Using Git

Once Git is installed on your system, creating a Git repository is easy: open your terminal, cd into the root folder of your project, and type: git init

That’s pretty much it!

After initialising your Git repository, it will most likely be empty. In order to commit files to the repository you first need to “stage” them by adding them to the index. To add all the files in your current project to the index type:

git add .

To commit these files type:

git commit -m "your commit message"

To view the status of your repository type:

git status

To Summarise

[Download and install Git]
[cd into the root of your project]

git init
ls -la
git status
git add .
git status
git commit -m "a useful commit message"
git status

[change some files in your working area]

git status
git diff
git commit -a -m "commit message. -a adds all files to the index"
git status

[delete some files from your local working area]

git status
git add -u
git commit -m "commit message. -u adds deleted files to the index"
git status

Ignoring Files

You will probably want to ensure than certain files don’t ever get committed to the repo:

Extra Configuration

You can enabled colorful output:

git config --global color.diff auto
git config --global color.status auto
git config --global color.branch auto

Some Bundled Visual Tools

git gui

Git Screencasts

Installing Git on Windows

Some Other Git Links


Eclipse Integration

Point your eclipse update manager to:

More info:

Some Commands

Add all working files to the index:

git add .

Add deleted files to the index:

git add -u

Create and switch to a new branch:

git checkout -b newbranchname

Review last commit:

git show
git show --stat
git show --name -status
git show HEAD

Review commit history:

git log
git log tag..branch
git log -10
git log --since="May 1" --until="June 1"
git log --author=fred
git log -- some/file

Creating branches:

git branch name
git branch name commit

Switching branches:

git checkout name
git checkout -f name

Parsley: Your Favourite Herb?

I’ve just started looking into Parsley:

First thought: version 2 is exactly what I’ve been trying to build with RobotLegs.

I’ve only briefly skimmed through the manual, but it really looks promising. I have some initial concerns (the use of Static methods for example; see:, but need more time to play around properly.

The forum pointed me to these two handy example projects:

Find them on the forum here:

All the Spice:

RobotLegs AS3: Introductory Screencast

RobotLegs AS3 is a Dependency Injection Driven MVCS Framework for Flash and Flex inspired by PureMVC.

I’ve been meaning to do this for a while, but only got the chance to sit down and give it a bash this morning. It was pretty rushed, so I’ll probably redo these when I get a chance.

NOTE: If you don’t know PureMVC you should watch these first: PureMVC.TV

Update: The vids were pretty crap, so I removed them. Besides, they’re a bit dated now anyway (the framework’s API has tightened up quite a bit since this post). Have a look:

A Nice Eclipse Icon – Suited for Mac OS X

I’ve always found the default Eclipse App Icon to be a bit.. lacking. I’m pretty sure I’m not the only person who feels this way. Occasional quests to find a better icon have usually resulted in disappointment. My latest search lead me to this icon. Not great, but it inspired me to finally sit down and try to create my own.

The First Stab

Here’s my initial attempt:

Mac OS X Eclipse Logo 256×256 on Black

I’m not entirely satisfied with it, but it’s a start. Here’s how it looks in my dock:

You can download the Icon (and it’s “source”) here:

Mac Eclipse Icon Pack

If you know of any cool Eclipse icons please leave a comment below. Thanks!

From here…

Pimp My Eclipse by Lee Brimelow

Update: My Terminal Icon