vWork Development

Builder pattern is so easy in Robotlegs

Wed, 25 Aug 2010 17:16:34 +1200

The Builder Pattern is a breeze in Robotlegs

public class ConcreteWidgetBuilder implements IWidgetBuilder {

  [Inject]
  public var injector:IInjector;

  public function buildPart(parameterised:IThing):IWidget {
    var widget:IWidget = injector.getInstance(IWidget);
    widget.param = parameterised;

    return widget;
  }

}

Parameterized builder

If you want to control what gets instanced based on a parameter:

public class ConcreteWidgetBuilder implements IWidgetBuilder {

  [Inject]
  public var injector:IInjector;

  public function buildPart(parameterised:IThing):IWidget {
    var interface:Class;

    switch(parameterised.style) {
      case ThingConst.COOL:
        interface = ICoolWidget;
        break;
      case ThingConst.HOT:
        interface = IHotWidget;
        break;
      default:
        interface = IDefaultWidget;
    }

    var widget:IWidget = injector.getInstance(interface);
    widget.param = parameterised;

    return widget;
  }

}

Bit freakin’ sexy if you ask me.

Visfleet's Radiator (v 0.0.1)

Wed, 11 Aug 2010 08:24:35 +1200

I started a project not too long ago to implement an information radiator here at Visfleet. The first milestone has been reached: Show the status of important Hudson builds

And here it is:

The source is on github

I started out with the intention of using Flex 4 skinning to make a super-modern, slick looking radiator like Panic’s. But somewhere along the way I ended up with a two tone border, it reminded me of my Commodore days, and the rest is ugly :)

Near term plans include:

Show C64 raster bars around building jobs
Use a horrible blink to highlight broken builds
Show who has claimed a build

Then:

Show which of our feature build servers has been claimed for a feature branch.
Show our twitter feed.
Get a much bigger screen.

Best practice for Ruby's require

Fri, 06 Aug 2010 15:19:00 +1200

Ruby’s require method gives you more than enough rope to hang yourself. Having now implemented too many projects with too many different approaches to using require, we thought it was worth writing down the conclusions we’ve come to.

We’ve gleaned most of our knowledge from these two articles, here, and here. So a big thank you to their authors.

How to require

Do use requires that are relative to ruby’s load path.

For example,
```
require 'my_project/b/c'
```
This assumesthat a directory containing the my_project directory is already in Ruby’s load_path (typically your project’s lib folder). It should be — more on this below.
Don’t use requires that are relative to the file.

For example, avoid:
```
require File.join(File.dirname(__FILE__), "foo", "bar")
```
Require decides if a file has already been loaded based on the unexpanded path it’s given. Two different relative paths are treated as two different files, so will be loaded twice. Moreover, it’s just yuky. If I want to figure which file a class is defined in, then I shouldn’t have to navigate a tangled web of file references.
Don’t require rubygems in your code.

It’s rude, not everyone wants to use Rubygems. If you want to use it then run
```
ruby -rubygems my_file.rb
```
OR use the following environment variable
```
RUBYOPT="rubygems"
```
Don’t manipulate ruby’s load path in your code.

Gem will always add your project’s lib directory to ruby’s load path. However, if your running an executable directly from your project (i.e. in your bin directory), or you’re running a set of units tests, then you’ll need to add your lib folder to ruby’s load path. There are a few ways to do this:
- Add this line to the top of your executable (contradicts what I just said, but at least in a consistent way).
```
$LOAD_PATH.unshift(File.dirname(__FILE__) + '/../lib') unless $LOAD_PATH.include?(File.dirname(__FILE__) + '/../lib')
```
- Or run Ruby like this:
```
Ruby -Ilib my_test_runner
```
- Or set this shell environment variable:
```
export RUBYOPT=Ilib
```

Structuring your project

Do use underscores as a separator in your project’s name.

No spaces, dashes, or camel case. Most ruby gems follow this convention, so best not to surprise people.
Do create a sub-directory under /lib with the same name as your project. And stick all your ruby files under this.

This is important if you want to package your project up as a Gem at some stage. The contents of every gem’s lib directory installed on your system automatically gets included in ruby’s $LOAD_PATH. Sticking all your code files directly in your lib is asking for same filename collisions. Even if you’re not going to package your project as a gem, it pays to follow this rule for consistency reasons.
Do create a file within your lib directory that is responsible for requiring in your other project files.

This is really an extension of the above. If you’ve nested all your code files in a project directory, then you need a single code file that is responsible for loading them all. For example, your lib fold should look like:
```
lib/my_project.rb
lib/my_project/
```
Do make your class namespaces correspond to your directory structure.

Your classes should be within modules that match the directory structure. This way you’re keeping your code namespace consistant with your directory namespace, making it easier to find things. For example, any ruby files in foo/bar should also be in a module Foo::Bar. More importantly, you’re reducing the risk of namespace collision from other libraries.

Dealing with executables

Do stick your executables in /bin. This is the default location where Gem will install executables from. You can change it, but you shouldn’t unless you have a good reason to.
Don’t use a suffix on your executables (i.e. no .rb). If you’re providing an executable to be run from the shell, then it should work like any other executable (i.e not have a .rb appended at the end).
Do use the following shebang line at the top of your ruby code to make it into an executable.
```
#!/usr/bin/env ruby
```

Guiding principle

If the above were boiled down to a single principle, it would be this:

Treat require like it’s requiring a namespace, and not a file. This is much the same as how import, and using, work in languages such as >C#, C++, and Java.

Another performance tool for AS3

Wed, 21 Jul 2010 22:33:15 +1200

Another performance tool for AS3

Elad's performance monitoring tool for flash

Wed, 21 Jul 2010 22:31:00 +1200

Elad's performance monitoring tool for flash

Mediating ItemRenderers, Again.

Sat, 17 Jul 2010 16:23:56 +1200

I’ve posted about this before.

I still have no shame about mediating ItemRenderers and to my happy suprise, Flex 4 makes it simpler with the spark.ItemRenderer and its dataChange event.

Here’s my base prescription in sample form:

Now you and I both know it can be a lot simpler to achieve the same, namely:

Why mediate, it’s so simple? Well the reason is simple too. Things never stay simple. My prescription is a easy template for me to follow, its already second nature for me to do it that way.

The moment I need to mix selection state (or multiple models) into a single renderer, my mediator is there waiting. This includes ensuring that no matter what data source is generating the itemRenderer, I have a templated method for locating the correct model (hence the comment in my mediator above).

Postgres routine (and not so routine) maintenance

Fri, 18 Jun 2010 14:03:04 +1200

Postgres is our DB of choice. We run all our vTrack and vWork systems on it. We have lately been developing data archiving and culling strategies to manage data growth and disk consumption.

I’ve found a few hints that are best shared.

Culling Old Data to Recover Disk Space

The initial thought is to perform a quick delete of the old data, a-la:

DELETE FROM table1 where date < [some date in the past]

Nothing wrong with that. However, it doesn’t recover any disk space. The natural instinct is to follow it with a vacuum:

VACUUM VERBOSE ANALYZE table1

I like to throw verbose and analyze in there too. But doh, this doesn’t recover any disk space either, it just marks the space used by the deleted as free, making it available for new data later.

Which leads to what the Postgres manual says about the subject:

The FULL option is not recommended for routine use, but might be useful in special cases. An example is when you have deleted or updated most of the rows in a table and would like the table to physically shrink to occupy less disk space and allow faster table scans. VACUUM FULL will usually shrink the table more than a plain VACUUM would.

Ok, let’s do a VACUUM FULL then:

VACUUM FULL VERBOSE ANALYZE table1

Good; Yay; finally some improvement. But that took bloody ages on the massive table that I just removed a bazillion rows from.

So, we devised a cunning plan, loosely based on what another page in the Postgres manual says about recovering disk space. In the manual it says you should perform a TRUNCATE on the table if you want to clean it up quickly, which got me thinking. Instead maybe we should just copy all of the keep-able data into a new table and blow away the old one (along with all the cull-able data).

In it’s basic form:

CREATE TABLE table1new
SELECT * INTO table1new FROM table1 WHERE date >= [some date in the past]
DROP TABLE table1
ALTER TABLE table1new RENAME TO table1

Because SELECT INTO doesn’t bring across any of the table meta-data, we then put the correct restrictions on the columns manually:

ALTER TABLE table1 ALTER COLUMN column2 SET NOT NULL
ALTER TABLE table1 ALTER COLUMN column3 SET NOT NULL
....

… recreate primary keys and indexes:

ALTER TABLE table1 ADD CONSTRAINT table1_pkey PRIMARY KEY(column1)")
CREATE UNIQUE INDEX index_table1_on_column2_and_column3 ON table1 USING btree (column2, column3)
....

… find out the max integer for sequence re-creation. A bit of psuedo code here, depends on your scripting language (we wrap all this stuff around Ruby/Rails and ActiveRecord):

max_id = SELECT max(column1) FROM table1

Then re-create the sequence:

CREATE SEQUENCE table_column1_seq INCREMENT 1 MINVALUE 1 MAXVALUE 9223372036854775807 START #{max_id+1} CACHE 1 OWNED BY table1.column1")
ALTER TABLE table1 ALTER COLUMN column1 SET DEFAULT nextval('table1_column1_seq'::regclass)

All of this work just to save some disk space? Not to mention the fact that you are dropping a table, which has some risk to it - especially if everything breaks half way through through the process.

It sounds scary and seems like quite a lot of work, but the elapsed run time difference is pretty huge.

When doing a DELETE FROM followed by a VACUUM FULL, our test system took 130 seconds. In comparison, doing a CREATE TABLE, SELECT INTO, DROP TABLE and RENAME takes around 45 seconds. This is on a very small table (2M rows) by our standards.

Another difference between the two methods is that the first method keeps the table available for reads. Writes will be locked out because a VACUUM FULL takes out an exclusive lock on the table. The second method drops the table entirely, so an outage would be required for any services or daemons which are accessing that table.

If you think about it some more though, the fact that you are having to cull data out of the table means that it is probably a write-heavy table. This indicates that an outage would have been necessary anyway, to perform a VACUUM FULL. Given this, you might as well perform the faster (albeit more complicated) form of the cull.

A final note about VACUUM FULL and indexes

I also stumbled upon another little gem while seeing just how much disk we could save. If you do a VACUUM FULL it doesn’t also hoover the indexes.

Quote, from here:

The FULL option does not shrink indexes; a periodic REINDEX is still recommended. In fact, it is often faster to drop all indexes, VACUUM FULL, and recreate the indexes.

Pretty much says it all really. And it brings me back to the previous section about copying the data into a new table, and re-creating the indexes from scratch.

If you want to save a few MB without being scary however, a REINDEX might be a good command to keep in mind.

Useful Rules and Guidelines

Fri, 04 Jun 2010 13:50:08 +1200

In our complex lives, rules and guidelines help us avoid rethinking everything that crosses our paths. Rules are the outcomes of pattern recognition.

We recognise repeating or similar stimulus in the world, and our ‘understanding’ of these stimuli is a “rule”.

I’m not quoting anyone here, and I may be oversimplifying the case, but I think this is a reasonable statement. Recognise: Drop a ball, it falls to the ground. The rule: releasing a ball causes it to fall toward the ground.

As programmers, there are a lot of rules to follow. Thankfully. Otherwise every line of code would be the realisation of hours of complex reassessment of stimuli (variables, requirements, other code..)

However when you discover, or are given, a rule to follow, it may not be “useful”. Hopefully at your disposal, you have the reasoning for the rule, but that can still leave you with more questions than answers. I’m talking about best practices here. If you want people to follow rules, you had better make it easy for them to identify wether they are applying the rules consistently.

A Rule

In Clean Code, Uncle Bob wrote:

The following advice has appeared in one form or another for 30 years or more. FUNCTIONS SHOULD DO ONE THING. THEY SHOULD DO IT WELL. THEY SHOULD DO IT ONLY.

The Reasoning

There are a lot of reasons to follow this rule. The first one that comes to mind:

Any unit of code that does only one thing is easier to comprehend when revisiting it in the future.

That’s good enough reason for me, but the rule still isn’t useful. And with a great deal of consideration to his readers, Uncle Bob continues with the “useful” part.

The useful rule

(Or, how to apply the rule.)

TO RenderPageWithSetupsAndTeardowns, we check to see whether the page is a test page and if so, we include the setups and teardowns. In either case we render the page in HTML.

If a function does only those steps that are one level below the stated name of the function, then the function is doing one thing.

This is so awesome. The ‘TO’, he advises us, is from LOGO, and is simply the syntax to introduce a method in that language. But I see this as a clue.

Clues

Clues remind us how to check if a rule is properly applied. Clues direct us into the mode of thought that originally recognised the pattern to which the rule applies. Perhaps clue’s are unit tests for rules.

Dan North, in his BDD article uses clues to remind us how to establish a good “User Story” and “Acceptance Criteria”. In fact his clues are so good that I quickly forget the rules and reasoning for user stories and acceptance criteria, and just find myself enjoying the use of the clues.

Writing a user story is a breeze now. I write down:

As a

I want

So that

I spend very little time now thinking about the complexity of my user story, instead I’m compelled to keep it simple and provide the three most important bits of information:

Who wants it,

What do they want,

To what end?

In closing

Why did I mention any of this? Because I assume people who bother to read our blog are either looking for inspiration to improve their own code, or want to help mentor others.

For the inspiration-seeking, look for people who give you more than rules and reasoning, but also give you mechanisms to ease the application of them.

For the educator, provide clues, help others find it easy to apply your rules. The rules should make their life easier, but they’re not enough on their own.

Ascending the Ivory Tower is good for everyone.

Fri, 21 May 2010 15:33:00 +1200

I attended the Flash And The City conference last week. It was an amazing experience and I met some of my personal Heroes. People who make the effort to popularise good software, good design, good tools, and good practices.

Sometimes I don’t see eye to eye with them, but I still respect anyone who puts themselves out there to be criticised so willingly :)

Funnily, a term started re-appearing that I haven’t had applied to my opinions (or the opinions of those I hold in highest regard) in a long while:

Ivory Tower

Ivory Tower connotes a place that’s unattainable. It’s being used regularly in the pejorative when discussing best practices for business, development teams and coding standards.

Now when I started using Object Oriented concepts like message passing, way back in the day, with Flash 4 and Flash 5, the same Ivory-Tower term was often bandied about by hackers and traditional linear programmers. It was often purported that things like Message Passing, Encapsulation and Polymorphism were too hard to understand and ill-suited to the day to day Flash developers’ work.

In 2000 I presented at the Sydney FlashKit Conference in an attempt to promote Flash as an RIA platform, all we needed was better coding practices. It was an uphill battle, I was asking people to climb an “Ivory Tower”. I was by no means a purist. I still don’t think I’m a purist.

So I will mix the Ivory Tower metaphor with the climb Mt Everest Metaphor somewhat from here. I think there is a surmountable slope to lofty standards of Agile and Best Practices.

Purists

A purist is someone who attains the summit and pretends they’ve never had to do a day of climbing in their life. A purist wonders, condescendingly, how you could possibly do things any other way. A purist doesn’t care for outside pressures. This kind of elitism can only be found in people who aren’t pressured into making pragmatic choices.

Pragmatism

Pragmatism does not mean “embrace the status-quo”. It means when achieving your goals, you recognise the path to attain them and the alternatives, especially the alternatives that bring everyone else to the summit. You will chose alternatives that let you reach important waypoints during your ascent.

Pragmatism can be applied to your singular ascent, your current team’s ascent, and everyone else’s ascent.

Our experiences

2 Years ago we set out to become an Agile development team that:

Had continuous integration
Automated, repeatable deploys
Encapsulated documentation (Knowledge stored in the same place it needed to be applied)
Automated Test and Behaviour driven development
Automated Integration testing
Clean consistent code
Software with a great user experience
Frequent delivery of improvements.

That was out lofty peak. We’re still not there, however I would say that we are in sight of our first peak. We got this far not by being purists, but by being pragmatists. Once we are upon the summit, we’ll look for something taller I am sure :)

Micro-architectures

Micro-architectures and small prescriptions are a fantastic tool for the worthy climber.

These are both lightweight prescriptions (easy to follow) that have massive impact:

Robotlegs gives you the Single Responsibility Concept, Code by Contract, Testable code etc.
Kanban gives you focused work-in-process, release-often, faster feedback etc.

I consider them both important tools for this ascent, others are Hudson CI, FlexUnit, Cucumber and many many more.

In closing

So my only argument with some of my heroes who proclaim “Ivory Tower” is:

“It’s not healthy to denigrate these attainable best practices”.

With the greatest respect, I ask that we speak instead in the following terms.

Find valid, workable stops along the way, and good reasons, not excuses, for stopping short of the summit

It has a more positive air to it, and it doesn’t devalue the amazing, and often freely given, efforts of the Mountain Climbing Specialists whom I think deserve slightly more respect.

Hmmm… and those of us who like to think of ourselves as Mountain Climbing Specialists could work harder to be humble. Not to make a stink so often just because someone cut a corner we wouldn’t have.

RSpec Style Unit Testing with FlexUnit4

Tue, 11 May 2010 07:08:11 +1200

We’re still early into our TDD for Flex program, and I am trying to learn “how” to write useful tests while not getting bogged down in any extremes, at least not until I understand it better.

I asked our CTO who is an accomplished ruby developer to guide and mentor me a little. He prefers to use RSpec for Ruby development. RSpec is designed for “Behaviour Driven Development” which Dan North introduces in a compelling way here. However it’s not clear at first glance why RSpec fits with Dan’s “Acceptance Criteria” template. (Cucumber)[http://cukes.info/] on the other hand, fits really well, but there is nothing even close to Cucumber for Flex that I can see.

Meanwhile, I needed something applicable and that guided me into my first tests, so I tried to adopt the DSL that RSpec uses. I think I’ve done an adequate job and I found it really helpful and inspiring. This article outlines what I do.

I am using real-world code throughout these samples. Mockolate is my mocking framework of choice here because it just works with FlexUnit4. Mockito also looks great but it’s integration with FlexUnit isn’t quite what I’d hope for.

Create a Case (Context)

The test case to me, represents the context of “how the unit (class) under test will be configured for testing”. There are sub-contexts which I’ll get to in a moment.

public class ProxyListCase {

  private var proxyList:ProxyList;

  private var configurator:IProxyConfigurator;

  [Before(order=1,async, timeout=5000)]
  public function prepareMockolates():void {  
        Async.proceedOnEvent(this, prepare(IProxyConfigurator,VOProxy), Event.COMPLETE);
  }

  [Before(order=2)]
  public function setup():void {
    proxyList = new ProxyList();

    configurator = nice(IProxyConfigurator);
    proxyList.proxyConfigurator = configurator;
  }

}

In the first “Before” section I pre-initialise Mockolate. In the second, I set up the context.

The context for ProxyList is:

That we have a ProxyList instance to test
That ProxyList is configured with required injections for testing anything, in this case, configurator is required.

Stubbing the Test

My first test, if I were to write it down, is:

given
  a simple VO
  a Proxy
then
  it builds a proxy on add

Which I deftly code as:

  [Test(given="a simple VO and a Proxy",
    it="builds a proxy on add")]
  public function ItBuildsAProxyOnAdd():void {
    fail();
  }

The metadata for the Test doesn’t “mean” anything to FlexUnit. However it can be pulled out by a custom runner on your CI server if you so wish. What it does tho, is gives you, and the next person to read the test, a very clear understanding of the test’s intent. It also lets you mark your sub-contexts in given. Let me show you how.

Sub-contexts (Givens)

First I translate the givens into with

  [Test(given="a simple VO and a Proxy",
    it="builds a proxy on add")]
  public function ItBuildsAProxyOnAdd():void {
    withSimpleVO();
    withProxy();

    fail();
  }

I then implement these new ‘givens’

  public function withProxy():void {
    proxy = nice(VOProxy);
    stub(factory).method("newInstance").returns(proxy);
  }

  private function withSimpleVO():void {
    newVO = {name: "hi"};
  }

These given’s get re-used a lot. As you refactor your tests you get a much clearer idea of what your assumptions about prerequisites are.

Do something and make assertions

Now for the simple bit, the test. This should read very clearly from the it metadata. In this case, remember: “it builds a proxy on add”

  [Test(given="a simple VO and a Proxy",
    it="builds a proxy on add")]
  public function ItBuildsAProxyOnAdd():void {
    withSimpleVO();
    withProxy();

    proxyList.add(newVO);

    verify(factory).method("newInstance").once();
  }

So we added using a prerequisite newVO and then we verified that the factory was asked to build a proxy.

I don’t think I can make a test clearer than that. Any thoughts?

Heres the whole class with a few tests, it’s a little different but you get the idea.

public class ProxyListCase {
  private static const PROXY_DISPOSE:String = "dispose";
  private static const CONFIGURATOR_BUILD:String = "configure";

  private var proxy:VOProxy;
  private var proxyList:ProxyList;
  private var configurator:IProxyConfigurator;
  private var newVO:Object;

  [Before(order=1,async, timeout=5000)]
  public function prepareMockolates():void {  
        Async.proceedOnEvent(this, prepare(IProxyConfigurator,VOProxy), Event.COMPLETE);
  }


  [Before(order=2)]
  public function setup():void {
    proxyList = new ProxyList();

    configurator = nice(IProxyConfigurator);

    proxyList.proxyConfigurator = configurator;
  }


  [Test(given="a simple VO and a Proxy",
    it="builds a proxy on add")]
  public function ItBuildsAProxyOnAdd():void {
    withSimpleVO();
    withProxy();

    proxyList.add(newVO);

    verify(configurator).method(CONFIGURATOR_BUILD).once();
  }


  [Test(given="a Proxy, and one VO added",
    it="disposes the proxy on remove")]
  public function ItDisposesTheProxyOnRemove():void {
    withSimpleVO();
    withProxy();
    withOneVOAdded();

    proxyList.remove(newVO);

    verify(proxy).method(PROXY_DISPOSE).once();
  }

  [Test(given="a Proxy, and one VO added-removed-readded",
    it="builds a proxy on re-add")]
  public function ItBuildsAProxyOnReadd():void {
    withSimpleVO();
    withProxy();
    withOneVOReAdded();

    verify(configurator).method(CONFIGURATOR_BUILD).twice();
  }


  [Test(given="a Proxy and an added VO",
    it="disposes the proxy on dispose")]
  public function ItDisposesTheProxyOnReset():void {
    withSimpleVO();
    withProxy();
    withOneVOAdded();

    proxyList.dispose();

    verify(proxy).method(PROXY_DISPOSE).once();
  }


  /* Sub Contexts */

  private function withSimpleVO():void {
    newVO = {name: "hi"};
  }

  public function withProxy():void {
    proxy = nice(VOProxy);
    stub(configurator).method(CONFIGURATOR_BUILD).returns(proxy);
  }

  private function withOneVOAdded():void {
    proxyList.add(newVO);
  }

  private function withOneVOReAdded():void {
    proxyList.add(newVO);
    proxyList.remove(newVO);
    proxyList.add(newVO);
  }

}

StickyNotes in Windows 7 make good CRC cards (if you don’t...

Thu, 06 May 2010 09:30:42 +1200

StickyNotes in Windows 7 make good CRC cards (if you don’t use them as sticky notes)

IntelliJ my Love

Fri, 23 Apr 2010 10:05:00 +1200

An un-poetic ode to IntelliJ. Will be amended continuously.

Auto-completion in comments

Iteration Live Templates

You type ‘iter’ and you get a live template:

for each (var object:Object in myColl) {

}

And a caret over ‘myColl’ letting you pick from accessable itterable types.

Nice!

Color swatches when it “sees” web color strings

Take a look at this image.

Now if only it recognised 0xfefefe as well.

Robotlegs Plugin for IntelliJ

Tue, 30 Mar 2010 18:45:00 +1300

So I started a little plugin a few days ago. I’m writing it for IntelliJ and it’s designed to make your life a little simpler, letting you navigate between classes with known ‘Up’ and ‘Down’ relationships in Robotlegs MVCS. Eg, The view is “Up” from the mediator and the service is “Down” from a command.

IntelliJ is really cool.

Apart from finding great little timesavers all the time, this is my first exposure to the underlying code of IntelliJ. It looks a little ‘patternitis’ but everything makes sense, and even the closed source ‘JavaScript’ plugin was easy enough to take advantage of with just headers.

It’s also my first time into Java, and the experience has been made sweet because:

IntelliJ is a great IDE and makes light work of what would be chore-like coding
IntelliJ is written with IntelliJ, and all the Best Practices and quality coding behaviours that IntelliJ promotes, are included in the “OpenAPI”

I mean the Javadocs are ancient and out of date, and some things are clearly legacy, and yet me, a n00b Java programmer had no trouble cobbling together the first part of the Robotlegs plugin.

The Plugin, where’s that then?

Here: http://plugins.intellij.net/plugin/?idea&id=4685 which means it’s also available in your IDE.

You may need the EAP version of IntelliJ as that is what I coded against.

It only does one thing right now. If you are in a mediator, then Ctrl-Alt-PageUp will take you to the linked in view. There is a roadmap here and all the source is here

All the design is in place and a lot of the ‘discovery’ is done. So things should fall into place. Let me know if you have any trouble with it.

Mount VBox shared dir as normal user in Linux guest

Tue, 23 Mar 2010 13:35:06 +1300

Rash wanted to mount a shared folder between his Windows desktop and a Linux guest running inside Virtual Box on said desktop.

He also wanted to be able to own and write to the mounted shared folder as himself, ( aka non-root user).

The syntax to put into /etc/fstab is:

[shared folder name] [mount path] vboxsf uid=[uid],gid=[gid],dmode=0755,fmode=0755 0 0

In Rash’s case this was:

Documents /home/rasheed/host_documents vboxsf uid=1000,gid=1000,dmode=0755,fmode=0755 0 0

Then, mount it:

sudo mount /home/rasheed/host_documents

Flash Platform Users Group

Fri, 19 Mar 2010 10:01:55 +1300

VisFleet sponsored the Flash Platform Users Group lastnight. Thanks to the guys and girls of the group for a good night and interesting talks.

And here’s some pics:

Rash taming Flash code into crafted code

Vinnie wowing the audience with 3D in the browser

Flash Platform User Group - Thursday @ 6PM at VisFleet's offices

Tue, 16 Mar 2010 14:42:00 +1300

VisFleet are sponsoring the next Flash Platform User Group meeting this Thursday @ 6PM at VisFleet’s offices. Our own Rasheed is giving a talk on the popular new Flex framework (RobotLegs).

To register, RSVP here:

http://aucknzfpug.eventbrite.com/

All welcome. Pizza and beer will be provided. Should be a good night.

Talks:

Rasheed Abdul-aziz. Rasheed will be wowing us with the wonders of the new framework RobotLegs. Robotlegs is a pure AS3 micro-architecture (framework) with a light footprint and limited scope. Simply put, Robotlegs is there to help you wire your objects together. (Sounds perfect)

Vinnie Vivace. Lately Vinnie has been twittering from the land of 3d and will be showing us a little more about Away3D Lite, a fast and small 3d engine.

List Model-Service Architecture with Robotlegs

Wed, 10 Mar 2010 10:59:00 +1300

EDIT: Stupid post. I don’t know how I got it into my head that VO’s needed an abstract factory for testing. They’re Value Objects! Without the Abs-Fac we don’t need ‘IVO’ and we can implement multiple interfaces because the concrete interface is all that our system needs. Sorry if I wasted your time with this drivel.

I’m currently looking at our services and model tier architectures. I’m focusing right now on the most common requirement of the client model-service tiers at Visfleet:

Maintain a client side representation of collection resources (Lists of like information)

Keep the list server-canonical (allow the server to provide the most up-to-date state as often as possible)

Expose standard REST operations for List, Show, Update, Create, Delete, New, Edit

Expose resource specific methods (RPC when needed)

So I was looking for a prescription, that as usual, kept my responsibility-count-per-class down near one.

What follows is my first draft. (Embiggen)

Note: IUpdateable is the only non-metaclass in this diagram.

service.load

So in this example I support service.load() which fetches the state of the whole list, or part of the list, from the server. The description of sequence that follows works as easily for any service request that results in a result record coming back from the server.

service.load() requests a list form the server.
service iterates over the service results
1. Uses voFactory.create() to create a new concrete VO
2. Parses the server result into the VO
3. Adds the VO to a payload.
service emits a signal that it has results, which carries the payload it just created.

controller (HandleResultCommand)

Typical Robotlegs behaviour here:

HandleResultCommand calls listModel.update() passing the payload of VOs

listModel.update()

The list model needs to ensure that its representation of the list is updated by the incoming payload

Iterates over the payload
1. Adds VO to list if it’s new (not in list)
2. Updates existing list VO if it’s an update (in list)

To update a VO, listModel depends on IVO being IUpdateable. This could be a responsibility of the ListModel itself, I’m still not sure which is more OO Savvy.

In my opinion, a broadly updateable VO is a requirement of the Flex framework. Collection types in Flex work best if VO object references don’t change. So do the collection-aware components.

The Gap

Usually at this point, someone wants to edit a VO. We don’t modify server-canonical VO’s in our apps, we clone them. We edit the clone, and actually share the clone as an ‘EditableModel’ so our whole app has access to the current VO under edit.

This is a perfect arrangement, however, I’m stuck. Making IVO ICloneable is not possible, I could only make VO ICloneable. If i move the IUpdateable respnsibility to ListModel there’s now a gap for ICloneable, but I’m not pleased with making an unassociated refactor a requirement.

If I introduce my EditModel at this point however, I do get a way around this that makes sense.

Welcome EditModel

(Embiggen)

I’ve dropped some components to make this clearer.

EditModel is introduced. It maintains the currently ‘under edit’ VO which is a clone. It uses ICloneable a little like a marker interface to do this. However it does require the VO to implement clone().

Do you think I should be making the effort to make ICloneable purely a marker and have a CloneStrategy?

Please feel free to comment, once you are aware of my usual disclaimers

On Robotlegs UI Architectures

Fri, 05 Mar 2010 16:10:00 +1300

There are now Caveats to all my posts.

I am considering everything in this post from the point of view of a N-Tier RIA developer’s point of view.

The Robotlegs MVCS presents a myriad of ways you can work with your tiers, without adding one line of extra framework code or departing from the Best Practices. Then there are the few presentation model mods I’ve seen around, such as Elad Elrom’s.

I quite like the “Robotlegs is the presentation model” one we use at Visfleet. Below, I give a little bit of backstory and explain why I like it so.

“MVC”

I find that the original beauty of MVC is somewhat lost in most breakdowns of MVC-like architectures. I have to wonder if I’m missing something.

Originally the “View” of MVC was a Component, The original SmallTalk MVC was component oriented. From Fowler’s UI Architecture Article:

At this point I should stress that there’s not just one view and controller, you have a view-controller pair for each element of the screen, each of the controls and the screen as a whole.

There are reasons this approach died off and isn’t considered practical. Noteably, when the components are generic (yay re-use) and encapsulate their own modelling. For example, a checkbox has it’s own selection state and transition modelling. All you get as a consumer is a public interface (on the “View” no less) consisting of properties (e.g.: checked), methods and signals (e.g.:VALUE_COMMIT).

However there is a beauty to the idea of having control/model support for these component views in your MVC-like architecture. This is something I’m a proponent of. Verbs like “select”, “move”, “reorient”, “announce”, “publish”, “change”, “commit”, “save” etc can all become adjectives of state: “Jobs[1] is selected”, “task is running”, “person is facing east”.

I consider a lot of what most would call ‘view state’ (something kept by view, mediator or presenter) is in fact domain modelling.

Domain Modelling

Again from Fowler’s UI Architecture Article:

The idea behind Separated Presentation is to make a clear division between domain objects that model our perception of the real world, and presentation objects that are the GUI elements we see on the screen. Domain objects should be completely self contained and work without reference to the presentation, they should also be able to support multiple presentations, possibly simultaneously.

I worry that the domain modelling found in the client-tier of most N-Tier applications (read database backed with a server encapsulating business logic) is often treated as a model of the business logic.

Certainly there is a good case to model some business logic in the client for speed and responsiveness, networks aren’t terribly fast compared to my computer’s bus. However that “business logic” being modelled is actually a part of the client domain model. It should be considered a utility and not actual Business Domain Modelling.

Let’s reiterrate that through example.

The business tier (server) says that:

A “Job” may transition state from “started” to “finished” or to “not started”.
A “Job” can not transition from “Started” to “Deleted” (you have to finish the job or back out of it before removing it)

When enforced on the business tier, this is “Business Logic” or “Business Domain Modelling”

When mimicked in the client tier, this is “Client Domain Modelling”. It is not:

Canonincal. So I’m calling it untrusted
Business Logic. Let’s not have it in two places.

Client Domain Models in N-Tier application clients are there to serve the purpose of presenting the business to the user

What I take away from this is:

A “Start” method is a domain model action.
selectedItem is domain model state.
runningJobs is domain model state.
etc…

To put it another way, I see my whole Robotlegs MVCS stack as one giant ‘Presentation Model’

Re-tiering feels pointless

What a lot of people do in their presenters and mediators is have a local state and message bus. This feels awkward to me. Suddenly I’m without a prescription, and frankly it’s really easy for me to write crap again. I can fill my mediator or presenter with awkward code that unsuprisingly is often best served by the MVC pattern.

I could treat my mediator as the context for another Robotlegs stack, however there is one clear drawback to this: Views, with their own concerns, cannot change containment easily. I explain this with the “Doorbell Model” later.

One context to rule them all

Or most of them… There’s lots of good reasons to use subcontexts, but within a context, I want to use a single MVCS 4-Tier.

I mediate as many components as I can, it gives me some of the elegance that the original MVC had. Each component action is mapped to a command, the command changes state in my modelling in some way, the mediator and view ensure they represent the new state. Again, I’ll outline this in the “Doorbell Model”

If I want to ‘genericise’ a component, and thus limit other users to it’s view’s public interface (as with most UIComponents), then I still create a robotlegs 4-tier stack and pass in dependencies via the view’s public interface. Then the context for the component uses these values as injection mappings (often named value mappings). I don’t do this very often mind you, a single context doesn’t cause me any real pain. Sub contexts might make for less clutter and I look forward to investigating those further.

The Doorbell Model

A simple analogy for why I don’t want any more tiers than the 4 in MVCS.

First, the views

A House is composed of a roof, a floor, and walls.
Walls are composed of Mortar, Bricks, Windows, Adornments and Doors
Doors have Adornments.
Example Adornments are: Lights, Doorknockers, Doorbells, Plaques etc..

A doorbell, where you might find it.

I’ve seen Doorbells on Doors, on the Wall beside Doors , and even at the back of a House (for a teenage boy’s mates to ring late in the evening.)

My original design might call for the Doorbell to be beside the frontDoor, thus contained by the frontWall, in turn contained by the house.

This frontDoorBell could be mediated by House’ or Door’s mediator. But why? Why not put a mediator on DoorBell. Then when I go to put a DoorBell on the backWall, and move the frontDoorBell to the frontDoor itself, nothing needs to change.

I almost imagine the DoorBell’s mediator to be a little circuit that hooks it to the wire on the House’ event bus.

An identifiable doorbell

Did you notice the arrival of the DoorBell on the backWall. This puppy makes it interesting. The event bus wants to ring two different bells, one for the teenageKidsRoom.bell and one for the hallway.bell. How would we identify the messages coming from these objects? That’s easy, the parent container of the DoorBell can inform it of it’s location (or the doorbell could ask the parent, it’s not an issue we need to care about right now).

The DoorBell.location property can be used to identify it’s position within views. This is appropriate intimacy and requires nothing but an obvious refactor to introduce it.

All those classes!

This approach to architecting my UI means that I have a proliferation of class definitions, and all within the convention of /model /view /controller /events /service. That’s OK. I compartmentalise component of the system by namespaces. Take a look at our namespace-prescription (living document) for Visfleet’s vWork product.

RFC

If you think I need to clear up anything or ammend anything or consider something, please comment. I crave peer input :)

Verbose is a dirty word

Tue, 02 Mar 2010 08:49:56 +1300

I’m not saying verbose should be a dirty word, just that it does have a pejorative meaning. If you’ve used *nix command line tools often enough, you’ll know that -v is often used as a flag for “verbose”. This usually ends up in some useful information coming out of the log or stdout. -vvv usually means “very verbose” and too much information pours out to be of any use. And this is the risk:

If verbose is your end-goal, then the more verbose you are, the better.

Right? I mean that makes sense. If “quality” is your end-goal, then more and more quality is a thing to strive for. Same goes for “agile”, “fair”, “loyal”, “just”. All these words suggest that the more you pile it on, the better. This is not true of verbose. Keep getting verbose, and in fact, you just get more noise.

I’m probably nitpicking this to death, but I’m only doing so, now, because I think I have a better quality to strive for:

Expressiveness

Really in our code, we wan’t to be more expressive. We want every line we read to convey it’s meaning.

If you check out expressive at dictionary.com there’s also a nice set of synonyms:

Synonyms: These adjectives mean effectively conveying a feeling, idea, or mood: an expressive gesture; an eloquent speech; a meaningful look; a significant smile.

I think eloquent is a good word too, it usually conveys meaning in a terse manner. That’s right, less verbose, just enough meaning and no more.

Readable Code

This code is readable, but not expressive:

public class EmployeeModel {
    ....
    public function save():void {
        if ((editingEmployee.name.length > 0) && (employees.checkUnique(editingEmployee.ssid))) {
            employees.comit(editingEmployee);
        }
    }
    ...
}

Expressive Code

So now I refactor it.

public class EmployeeModel {
    ....
    protected function employeeIsValid(employee:EmployeeVO):Boolean {
        return ((employee.name.length > 0) && employees.checkUnique(employee.ssid))
    }

    public function save():void {
        if (!employeeIsValid(editingEmployee)
            return;

        employees.comit(editingEmployee);
    }
    ...
}

I use a guard clause for starters because they convey intent more clearly.

Then I extract the method (all praise ctrl-alt-m in IntelliJ IDEA) employeeIsValid(). This gives the guard more meaning, and also gives the extracted condition more meaning. It’s a win-win.

Verbose Code

Now, is this the following code more expressive or more verbose?

public class EmployeeModel {
    ....
    protected function employeeNameIsValid(employee:EmployeeVO):Boolean {
        return employee.name.length > 0;
    }

    protected function employeeIsValid(employee:EmployeeVO):Boolean {
        return (employeeNameIsValid(employee) && employees.checkUnique(employee.ssid))
    }

    public function save():void {
        if (!employeeIsValid(editingEmployee)
            return;

        employees.comit(editingEmployee);
    }
    ...
}

I extract the name comparison (pretend for a moment that it couldn’t be done in the VO) - employeeNameIsValid().

This is not too bad, I think. It expresses that an employeeName that’s greater than 0 chars long is valid.

However this is easily inferred from the previous example, because the test is inside ‘employeeIsValid’ - It would read just as well, and so I wouldn’t bother with this extra step. At least, not until it got more complex. Remember, most refactorings are bidirectional.

Install pg gem via Bundler on OSX Snow Leopard

Mon, 22 Feb 2010 14:49:00 +1300

I encountered three problems installing the Postgres ruby gem (pg) when using Bundler to install all the gems for a project on my OSX Snow Leopard 10.6 machine.

Firstly, the gem fails to build on Snow Leopard when you use the binary version of Postgres that is distributed by Enterprise DB. To work around this, the Postgres binaires need to be installed using Mac Ports.

Secondly, the pg gem must be installed using additional bash environment variables.

Thirdly, every time you run bundle install, the current version of Bundler hard re-installs all gems listed in ./Gemfile. This means that even if you install the pg gem correctly by hand, bundler will still try to reinstall it.

All three are resolved as below, in my case I am using Postgres 8.4.

Install postgres from Mac Ports

sudo port install postgres84

Include the postgres binaries in the PATH environment variable

export PATH=/opt/local/lib/postgresql84/bin:${PATH}

Then run bundle install with the all-important arch flag

env ARCHFLAGS="-arch x86_64" bundle install

Edit: removed sudo from bundle command.