Agile software development using Kanban & Scrum. We code Flex & Ruby on Rails in Auckland, New Zealand.

  • Builder pattern is so easy in Robotlegs

    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)

    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

    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.

  • Mediating ItemRenderers, Again.

    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

    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

    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.

    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

    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<HelperMethods>

      [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);
      }
    
    }