I’ve tried mind mapping in the past and it never really stuck for me.  It was a little too free form.  I needed some structure for my ideas, that’s why I was looking for something in the first place.  Robert’s post briefly describes the structure that he has used for forming user stories.  The method made the idea click a little bit better.  Basically he starts with the project in the center and then the ring out is the different actors.  Hanging off the actors are the actions that they should be doing.

I downloaded the 30 day trial of MindJet MindManager and tried Robert’s technique out on my current project.  It was a lot easier to get started that it had been on previous attempts with mind mapping, but I kept feeling like something was missing.  Here’s what finally clicked for me: what the user does is less important than why they want to do it.

In the classic user story we have an actor, an action, and a business value that the story provides (As an <actor> I want to <action> so I can <business value>).  I slightly modified Robert’s approach and added a level for business value — the “so I can” clause of a user story.  Now I have the project in the center, next the actors, and then I start listing out the business value that each actor wants to get from the app that we are building.  Under each of these leaves I can then start describing actions that would provide the actor with the business value.

This really make things click.  My ideas started to come together and I feel like the result is clear user stories that are customer business value focused.  I need to thank Robert again for convincing me to dig in to mind maps again.  I think this will be a big help in focusing my ideas in to something communicable and implementable.

First lets get the code:

$ git clone git://github.com/MagLev/maglev.git

Initialized empty Git repository in /Users/rgarver/Sources/maglev/.git/
remote: Counting objects: 28955, done.
remote: Compressing objects: 100% (12671/12671), done.
remote: Total 28955 (delta 15669), reused 28427 (delta 15200)
Receiving objects: 100% (28955/28955), 14.97 MiB | 539 KiB/s, done.
Resolving deltas: 100% (15669/15669), done.
Checking out files: 100% (2180/2180), done.
Initialized empty Git repository in /Users/rgarver/Sources/maglev/.git/remote: Counting objects: 28955, done.remote: Compressing objects: 100% (12671/12671), done.remote: Total 28955 (delta 15669), reused 28427 (delta 15200)Receiving objects: 100% (28955/28955), 14.97 MiB | 539 KiB/s, done.Resolving deltas: 100% (15669/15669), done.Checking out files: 100% (2180/2180), done.

$ cd maglev

Great, we have the code.  Next step is to do a base install.  This installs the base libraries and GemStone which is the fabled persistence layer that MagLev has integrated.  GemStone is a object persistence layer originally built for Smalltalk.  If you haven’t ever played with Smalltalk or some of the variants (eg: Squeak) I recommend it.  It will turn your head upside down.

$ ./install.sh
[Info] Starting installation of MagLev-22578.MacOSX on sirius.local
Password:
Sat Nov 21 09:22:44 PST 2009
[Info] Setting up shared memory
  Total memory available is 4096 MB
  Max shared memory segment size is 4 MB
  Max shared memory allowed is 4 MB
[Info] Increasing max shared memory segment size to 2048 MB
kern.sysv.shmmax: 4194304 -> 2147483648
[Info] Increasing max shared memory allowed to 2048 MB
kern.sysv.shmall: 1024 -> 524288
[Info] Adding the following section to /etc/sysctl.conf
# kern.sysv.shm* settings added by MagLev installation
kern.sysv.shmmax=2147483648
kern.sysv.shmall=524288
kern.sysv.shmmin=1
kern.sysv.shmmni=32
kern.sysv.shmseg=8
[Info] Setting up GemStone netldi service port
[Info] Adding "gs64ldi  51456/tcp" to /etc/services
[Info] Downloading GemStone archive using /opt/local/bin/wget
--2009-11-21 09:22:44--  http://glass-downloads.gemstone.com/maglev/GemStone-22578.MacOSX.zip
Resolving glass-downloads.gemstone.com... 207.171.185.197
Connecting to glass-downloads.gemstone.com|207.171.185.197|:80... connected.
HTTP request sent, awaiting response... 200 OK
Length: 74858717 (71M) [application/zip]
Saving to: `GemStone-22578.MacOSX.zip'

100%[==========================================================================>] 74,858,717   847K/s   in 1m 45s

2009-11-21 09:24:32 (694 KB/s) - `GemStone-22578.MacOSX.zip' saved [74858717/74858717]

[Info] Uncompressing GemStone archive into /Users/rgarver/Sources
[Info] Linking gemstone to /Users/rgarver/Sources/GemStone-22578.MacOSX
[Info] updating MSpec, RubySpec, and RBS submodules
Submodule 'benchmark' (git://github.com/acangiano/ruby-benchmark-suite.git) registered for path 'benchmark'
Submodule 'spec/mspec' (git://github.com/rubyspec/mspec.git) registered for path 'spec/mspec'
Submodule 'spec/rubyspec' (git://github.com/rubyspec/rubyspec.git) registered for path 'spec/rubyspec'
Initialized empty Git repository in /Users/rgarver/Sources/maglev/benchmark/.git/
remote: Counting objects: 7332, done.
remote: Compressing objects: 100% (5521/5521), done.
remote: Total 7332 (delta 1595), reused 6917 (delta 1274)
Receiving objects: 100% (7332/7332), 9.90 MiB | 578 KiB/s, done.
Resolving deltas: 100% (1595/1595), done.
Submodule path 'benchmark': checked out 'd807eea7f7b2f38240bc177a0c22e599081882ea'
Initialized empty Git repository in /Users/rgarver/Sources/maglev/spec/mspec/.git/
remote: Counting objects: 2745, done.
remote: Compressing objects: 100% (1080/1080), done.
remote: Total 2745 (delta 1848), reused 2484 (delta 1644)
Receiving objects: 100% (2745/2745), 378.57 KiB | 383 KiB/s, done.
Resolving deltas: 100% (1848/1848), done.
Submodule path 'spec/mspec': checked out 'bcec47c70e0678a29fd0c1345358c4daf7b971a3'
Initialized empty Git repository in /Users/rgarver/Sources/maglev/spec/rubyspec/.git/
remote: Counting objects: 26787, done.
remote: Compressing objects: 100% (8705/8705), done.
remote: Total 26787 (delta 18332), reused 25672 (delta 17482)
Receiving objects: 100% (26787/26787), 3.71 MiB | 520 KiB/s, done.
Resolving deltas: 100% (18332/18332), done.
Submodule path 'spec/rubyspec': checked out 'b0a18cf80dc706d39ee550831b8b941224b60fb6'
[Info] Creating new default 'maglev' repository
[Info] Generating the MagLev HTML documentation
[Info] Finished upgrade to MagLev-22578.MacOSX on sirius.local

[Info] MagLev version information:
maglev 0.6 (ruby 1.8.6) (2009-11-20 rev 22578-1067) [x86_64-linux]
GEMSTONE: 3.0.0 Build: 64bit-22578
MONTICELLO: MagLev-ao.1067.mcz
MAGLEV: commit e2a4fe2e0f7ca85cdcb141e6b56913eba802eefd
        Author: Allen Otis <otisa@abaco.gemstone.com>
        Date:   Thu Nov 19 19:57:09 2009 -0800
[Info] GemStone version information:
GemStone/S 64 Bit
3.0.0 Build: 64bit-22578
Fri Nov 20  8:22:00 2009

[Info] Adding these to your .bashrc will make it easier to run MagLev
export MAGLEV_HOME=/Users/rgarver/Sources/maglev
export PATH=$MAGLEV_HOME/bin:$PATH

[Info] After you complete this upgrade and verify MagLev is working, run
  rake stwrappers
to generate the .rb files for the GemStone/Smalltalk FFI
in MAGLEV_HOME/lib/ruby/site_ruby/1.8/smalltalk/

As you can see on OS X it will build everything for 64bit which is pretty cool.  It also downloaded a bunch of support libraries and updated all of the submodules.  If you ever update the code locally you are supposed to run ‘$ ./update.sh’ to rebuild everything and get it all up and running.

Once you have it installed you should add the following lines to your .profile or .bashrc

export MAGLEV_HOME=/Users/rgarver/Sources/maglev
export PATH=$MAGLEV_HOME/bin:$PATH

You’ll need to make sure you run those lines on the command line also.  Once the environment is setup you can run ‘$ rake maglev:start’.  This command apparently boots up the core MagLev engine.

$ rake maglev:start
(in /Users/rgarver/Sources/maglev)
startstone[Info]: Starting Stone repository monitor "maglev".
startstone[Info]: GemStone server 'maglev' has been started.

Once that is started you are good to go:

$ maglev-irb
/Users/rgarver/.irbrc
error , no such file to load -- readline,
          during /Users/rgarver/Sources/maglev/lib/ruby/1.8/irb/completion.rb
error , no such file to load -- readline,
          during /Users/rgarver/.irbrc
irb(main):001:0> puts 'hi'
hi
=> nil
irb(main):002:0>

One thing that I am happy about with SPDY is that is appears to be built with deployment clearly in mind.  This isn’t the first attempt to improve web speeds, it’s not even the best, but it does appear to be the simplest to deploy in to the wild and see rapid adoption.  If Apache and Firefox gained support for SDPY out of the box, and it was show that using the protocol would improve server throughput, it would be enough to shift most websites over.  That’s only two players.  That’s pretty promising.

I should note here that the team is using a fibonacci scale of estimates and generally has features between 1 and 5 points.  This project is also made up of significant legacy code and is being “stabilized”.  Bugs come in regularly and don’t get estimated.  Big changes to the application need to take in to account existing users and their similarly legacy data. (Legacy here means old and originally developed with minimal QA and tight time constraints)

The first 5 sprints for this team were quite encouraging.  After a 3 week bootstrapping period there was a strong sense that the team was building up to a strong pace.  The team had a rough sprint 6, but they seemed to bounce back the following week.  Sprint 8 had another collapse.  By this point we were looking at 4 weeks and only completing 20 points.  What is going on?  Sprint 4 had us expecting twice that pace.

I’m very fortunate to have a reliable team, a very skilled and experienced team lead, and a patient set of stakeholders.  As we began seeing the fluctuating velocities for what they were (a problem with our process) all of us began looking for causes and solutions.  I’ve seen this before.  The team got about 6 weeks in to the project, everyone was beginning to feel confident that we were doing things right, and then we started to lose control.  We’d nail one sprint only to completely miss on the next one.  It was frustrating and demoralizing.

We got through it.

The root cause came down to unanticipated externalities.  That means that a task would get held up because we needed an icon from the designers, or we needed content for the new email, or our acceptance criteria were vague enough that developers couldn’t quite tell if they were done until QA approved or rejected the work.  The team wasn’t quite sure if their work was done and tasks would get rejected at the end of every sprint for often minor issues.

What did we do to fix it?

The biggest change was to add detail to the acceptance criteria and make sure our QA process would verify exactly to the acceptance criteria.  This ultimately was my fault and by getting QA to strictly focus on the ACs it put pressure on me to get as much in to the ACs as I could, otherwise I’d need to create a new user story to tune it and that may mess up my timelines.  I like to call this approach “strategic pressure points”.  The goal is to strategically put positive and negative pressure and side effects to encourage those best practices that we all say we should follow but often lose motivation after a few times.

The other shift in think came more as a side effect of the first.  That was to hold on to user stories until I had all of the content and graphics ready to go with it.  In an ideal world we’d be able to drop a designer directly on the team and turn the graphics problem from an external issue to an internal one.  This gives the team (plus one designer) control over their ability to complete the stories that they accept in to a sprint.

The key to this turnaround is a return to the basics.  What do the numbers say?  What is going wrong or right; what is causing frustration in the team members?  And, what can you do to make things incrementally better?  Keeping our eyes on the metrics that we are collecting helped us track the instability of our process and allowed us to focus on specifics when looking for problems.  Constantly looking for things that aren’t working perfectly and finding ways to make them slightly more perfect helped us respond to the problems rationally and see rapid recovery from the issues that were affecting us.

In any case that is not what I’m here to talk to you about.  In looking through these mp3’s the list of webinars was not collected in to any sort of podcast format.  This is frustrating because this would be ideal commute time listening on my iPhone.  Out of this frustration came podcast.local.  Podcast.local is a simple Rails application (really simple) that allows you quickly create a podcast through a series of forms.  The name comes from the naming convention provided by the Passenger preference pane on OS X.  If you set it up through the pref pane you will just need to go to http://podcast.local.  From there you can create your podcast one episode at a time and then subscribe to them through your iTunes.  The coole thing is that because it’s on the web iTunes just picks it and starts downloading episodes.

Like I said above, this application is too simple to go in to much detail.  I used it to do some experimentation with a few technologies that I haven’t had much time to mess around with.  Namely Blueprint CSS, jQuery, jQuery UI, and Paperclip.  Enjoy!

I’ve been having discussions recently with some coworkers about finding better tools for various aspects of our business. A lot of our discussions are looking at how to organize our development process, but every once in a while it diverges to a different set of issues, especially how we track our developer/designer/account managers’ hours.

If you’ve known me for a while, you’ll know that I get a kick out of trying out new apps and services. I like to find ways to make myself more efficient and better at my job and life in general. Usually I end up throwing these tools away after a few weeks. But every once in a while I find something that lasts. A great example of this is OmniFocus. I had been trying to implement a good approximation of GTD for several years, and in that time I’ve tried probably 15 different tools and online services that implement various approximations of GTD. But it wasn’t until I started using OmniFocus that I really found a sustainable process and a tool that empowered me.

Coming from the agile community the common reaction to “What tools should I use to organize my development process?” is whiteboards, poster paper, and ample note cards. While I do appreciate this tactic from first hand experience, this has some obvious flaws as soon as your team members are not co-located.

Our current suite of tools have a number of failings for a number of different reasons. The reaction that I’ve been hearing lately from my colleagues is that we need to find a single tool that handles all of our major needs. The theory—I presume—is that having fewer tools will mean less manual work maintaining the tools and their content.

I’m not a big fan of this philosophy for a few reasons:

1. It is not likely we will find a single tool that fits all of our business requirements without it being too complex or expensive (or both), therefore our processes and practices will need to be adjusted for the tool. The realist in me is OK with the idea of adapting to the tool to an extent, sometimes the tool can give you a better process that you didn’t know before (eg: OmniFocus), but that’s pretty rare.
2. There are a few tools that are actually working very well for us, however the “one tool to rule them all” model creates artificial value in eliminating that independent tool for a consolidated one that may be less effective.
3. It impairs a teams ability to experiment with new work patterns and tools by adding cultural pressure and often bureaucratic overhead around tool choice. If agile software development is about expecting change and continuously adapting to it, then I want to have the flexibility to adapt everything down to the tools the I use.
4. I’m not convinced that maintenance overhead is entirely due to the number of tools. I think it has more to do with not using the right tools.

Modern application development approaches have really focused on the idea of specialized tools that solve a small set of problems. The old model of monster apps that can be customized to do what you want, but not quite perfectly, is being phased out for interoperability and APIs. Our Github account can send post-commit notifications to our Campfire account, our Acunote account integrates with our bug tracking system, and just about everything will send an email to keep you up to date.

The moral of the story: Why use one tool that does everything just OK when you can have many tools that to their own things really well and will talk to each other?

So I tried Red for a while (short while) and was all excited and thought it was really cool and I’d be using it forever. Then I tried to make a Ajax call to a rails app and got back JSON, crap. Red doesn’t support parsing JSON. I eventually figured it out and made a pretty cool billing summary widget using Red. But that took me a few days. And it was really hard. Much harder than it needed to be.

I like what Red was trying to do, but looking back I think I knew it was too good to be true. It’s not quite there and requires a lot of hacking to do most practical things. I’m now using jQuery. I reimplemented the billing summary using jQuery in a couple of hours, and most of that time was spent re-learning jQuery. I’m actually pretty happy with it after using it for a few weeks. I thought I would always return to Prototype.

In my excitement for learning a new tool I discovered the extension jQuery UI and their Themeroller. This has got to be one of the cooler javascript library extensions that I’ve seen. ExtJS tries to provide a will UI toolkit and has a theme API, but the Themeroller for jQuery UI is really sweet and super simple. As a basis for a back office admin it is ideal, and I can see a number of opportunities in a broader set of situations. The icon library alone has made producing simple, intuitive interfaces really easy.
Posted in programming Tagged: javascript, jquery, jqueryui, programming, themeroller ]]> http://blog.selfmodifying.com/2009/02/10/back_to_jquery/feed/ 0 Ryan http://blog.selfmodifying.com/2009/01/03/json_for_red/ http://blog.selfmodifying.com/2009/01/03/json_for_red/#comments Sat, 03 Jan 2009 20:11:26 +0000 Ryan Garver http://selfmodifying.wordpress.com/?p=35 ]]> I’ve been playing around more with Red.  I alternate between really liking it and totally pulling my hair out.  On a order form app that I’m building I made some very quick work of a dynamically updating billing summary div.  It came together very quickly until I added the AJAX piece.  AJAX support in Red is actually very good, but JSON support is non-existent.  This made Ryan a sad boy.  I dug around to see what other people have done and found that they haven’t done much.  There is some stub code for a Request::JSON that my be what I’m looking for at some point, but I need it now.  So here is what I did:

class Module
  def define_method(sym, &block)
    `this.prototype['m$'+sym.__value__]=block.__block__.__unbound__`
    `Red.updateChildren(this)`
    `Red.updateIncluders(this)`
    return `block`
  end
end

class Object
  def self.from_json(text)
    ret = Object.new
    meths = []
    `var v = eval("("+#{text}.__value__+")")`
    `for(var member in v){#{meths}.push(new Array($q(member), $q(v[member])))}`
    meths.each do |meth|
      ret.class.send(:define_method, meth[0]) do
        meth[1]
      end
    end
    return ret
  end
end

Now doing a simple AJAX call that returns JSON becomes really easy:

@req = Request.new(:url => '/orders')
@req.upon(:response) do |response|
  new_data = Object.from_json(response.text)
  @summary = new_data.summary
  @subtotal = new_data.subtotal
  @total = new_data.total
end
@req.execute(:data => {'plan_id' => @plan, 'promo' => @promo})

A few things to note here.  The section that defines `define_method` on `Module` is actually back ported from the current master branch of Red.  This works pretty well, though I haven’t tried it with a JSON string that describes a living object.  But I don’t think it’s too far from being able to handle that.

If you are in a position to ask this question I humbly recommend you default to: “No, I do not need this as an instance variable right now.” There is a tendency to plan for every potentiality when doing software development and this is a prime example of such a situation. Resist the temptation.

Instance variables represent state associated with an object in memory. When you declare an instance variable you are saying to all future developers: “This piece of state needs to last for the life time of this object because it will be used elsewhere.” Think very hard about that. We are saying loudly here that this variable is coupled to other fragments of code. Which code? Dunno, do a global search .

This is called tight coupling. I will go so far to say that coupling is the source of all evil and complexity that we deal with as programmers. With every step that we, as programmers, take in building a system should be with an eye to reduce or at least not increase the coupling in the system that we are working on. The fewer instance variables that we have in a Rails controller the smaller the potential coupling between the view and other method calls that have access to those instance variables. Each method, each action in a controller, should be as self contained as possible. The less leakage of state out of a function the better. Generally your view doesn’t need to see that temp variable of the calculations that you made to set a model attribute keep it local, drop the “@”. Worst case scenario you go back and refactor your code to include that “@”.