new ThoughtStream("Derick Bailey");

Electronic Kanban Tools and WIP Limits: LeanKitKanban Gets It!

derick.bailey — Mon, 09 Nov 2009 17:55:24 GMT

Most of the electronic Kanban boards that exist simply don’t understand what WIP limits are really about. They all seem to go down the path of forcing any step (column) in the process to have a maximum limit that is very hard and fast. They set it up so that you cannot add any more items to the step than the limit allows. But the truth about WIP limits is that they are not supposed to be hard and fast, mechanical limits. Putting in a hard limit like this is a great way to destroy the productivity of a team and usefulness of a tool when the team finds themselves in a crunch, in a situation with additional resources and needs, or any of a number of other circumstances.

I know I haven’t been vocal about this online, but it’s something I’ve been complaining about to my coworkers and friends for a while. It bugs me and is one of the major reasons that I’ve stayed away from the major (free) players in the electronic Kanban realm, other than trials and basic testing of the systems.

But then I got an email from Chris Hefley this morning, about some new features in LeanKitKanban. When I logged in to check them out, I was surprised to see this happen when I tried to exceed a column limit:

I can’t tell you how happy I was to see this! Finally, one of the tools vendors in this space is really starting to get it! For this, and a few other reasons that I don’t want to talk about yet, LeanKitKanban is now officially my favorite electronic Kanban / task board around. If you haven’t done so, I highly recommend that you check them out.

Do any other electronic Kanban boards are heading down this same path and allowing for limit overrides? If your current tool doesn’t support this, it should.

A Time For Change

derick.bailey — Wed, 04 Nov 2009 15:36:03 GMT

Change comes in groups of three, right? Well, I have a 4 week old baby girl (I can hardly believe she’s 4 weeks old already). That would be change #1. For change #2, I turned in my two week notice to my current employer on Monday.

Starting on November 16th, I’ll be joining up with fellow LosTechie, Joey Beninghove, over at TrackAbout.com. I’m excited about the opportunity. There’s a great bunch of developers on that team and it should be a lot of fun and a significant challenge for me, at the same time.

Now I just have to wait and see what change #3 is going to be…

The Ultimate ‘Hello World’

derick.bailey — Thu, 08 Oct 2009 20:42:51 GMT

So… my blog may be going dark for a while… I don’t think I’m going to have a lot of free time for at least a few weeks, due to the ultimate ‘Hello World’ baby girl that my wife delivered on Wednesday morning @ 1:45am.

I’ll get back to blogging some time I get back to sleeping, or start getting back to office – whichever comes first.

A Basic YAML Config Module For Ruby

derick.bailey — Mon, 05 Oct 2009 16:39:01 GMT

In the process of working with Albacore and creating a task to wrap around SQL Server’s SQLCmd.exe, I wanted to ensure that I could allow individual developers the ability to easily provide their own database server connection information, so that they can easily run database scripts against their local database server instance. To do this, I decided to have a little fun with YAML and some ruby metaprogramming.

The YAMLConfigBase Mixin

The end result is a little YAMLConfig module that allows you to mixin the ability to dynamically add / set some attributes on a ruby class.

        1: require 'yaml'

       2:  

       3: module YAMLConfigBase

       4:     def configure(yml_file)

       5:         config = YAML::load(File.open(yml_file))

       6:         parse_config config

       7:     end    

       8:     

       9:     def parse_config(config)

      10:         config.each do |key, value|

      11:             setter = "#{key}="

      12:             self.class.send(:attr_accessor, key) if !respond_to?(setter)

      13:             send setter, value

      14:         end

      15:     end

      16: end

This code will read a simple name/value pair from a yaml file, loop through each of the pairs and set an attr_accessor to that name, with that value. It’s also smart enough to check and see if the attr_accessor exists, before trying to create it. So you can configure a ruby object that already has attributes set up, with this utility.

Using YAMLConfigBase

Any class that includes the YAMLConfigBase module will be able to easily load a yaml file and have the key / value pairs from that yaml file automatically set as attributes w/ values.

If we have this yml in a file called “someconfigfile.yml”

       1: my_setting: my value goes here!

and we have this ruby code:

       1: require 'yamlconfigbase'

       2:  

       3: class Foo

       4:   include YAMLConfigBase

       5: end

       6:  

       7: f = Foo.new

       8: f.configure("someconfigfile.yml")

       9:  

      10: puts f.my_setting

we end up with this output (running IRB in windows command prompt):

The “Foo” class in this example only has 3 lines of code in it, yet I was able to create, set, and get a value in an attribute that I defined in a yaml file. You want to talk about DRY code? This is death-valley in the middle of a summer drought, dry. :)

I know it’s not super-duper-amazingly-original stuff, but it’s fun to do this kind of thing and make the rest of a framework easily configurable through yaml. It also shows the power of meta-programming and dynamic languages like ruby.

Albacore: Breaking Changes In Location Of Executables

derick.bailey — Sun, 04 Oct 2009 19:20:20 GMT

I was working on cleaning up Albacore this weekend, and I noted that both the NCoverConsole and MSBuild tasks in Albacore both require the location of the .exe, to execute. The MSBuild task defaults itself to the .NET 3.5 SP1 folder, if none is specified, but the NCoverConsole task requires the path to be specified. With both of these requiring a path to the .exe file, it made sense to consolidate the functionality of storing the location and executing the command in a module. This would help to ensure consistency across all the tasks that need to execute something on the command line.

Breaking Change: ‘path_to_exe’ is now ‘path_to_command’

In the process of putting together the basic module for this, I decided that ‘path_to_exe’ is not the right setting name. Rather, ‘path_to_command’ is more appropriate, in case someone wants to use a .bat, .cmd or other executable file extension.

MSBuildTask:

        1: desc "Run a sample build using the MSBuildTask"

       2: Rake::MSBuildTask.new(:msbuild) do |msb|

       3:   msb.path_to_command = "C:/Windows/Microsoft.Net/Framework/v3.5/MSBuild.exe"  

       4:  

       5:   msb.properties :configuration => :Debug

       6:   msb.targets [:Clean, :Build]

       7:   msb.solution = "lib/spec/support/TestSolution/TestSolution.sln"

       8: end

NCoverConsoleTask:

       1: desc "Run a sample NCover Console code coverage"

       2: Rake::NCoverConsoleTask.new(:ncoverconsole) do |ncc|

       3:   ncc.path_to_command = "lib/spec/support/Tools/NCover-v3.2/NCover.Console.exe"

       4:     

       5:   ncc.log_level = :verbose

       6:   ncc.output = {:xml => "lib/spec/support/CodeCoverage/test-coverage.xml"}

       7:   ncc.working_directory = "lib/spec/support/CodeCoverage"

       8:     

       9:   nunit = NUnitTestRunner.new("lib/spec/support/Tools/NUnit-v2.5/nunit-console.exe")

      10:   nunit.log_level = :verbose

      11:   nunit.assemblies << "assemblies/TestSolution.Tests.dll"

      12:   nunit.options << '/noshadow'

      13:     

      14:   ncc.testrunner = nunit

      15: end

Breaking Change: no second parameter for MSBuildTask.New

Also – to keep things a little more consistent, I decided to remove the second parameter from the MSBuildTask initializer. You can no longer specify the path to the msbuild.exe in the initializer. Rather, you should specify it in the settings of the task, as shown in the above example.

Feedback Welcome

I always welcome feedback, especially with this project being in such an early stage and with so few tasks available, so far. If you liked the optional MSBuildTask initializer parameter, if you think path_to_exe is a better name, or if you have any other questions, comments, or suggestions, please drop me a line. The easiest way to do that is over on the Albacore Issues list, or through ‘Contact’ link in the sidebar of this page.

Albacore AssemblyInfo Task vs. Nant Assembly Info Generator

derick.bailey — Tue, 29 Sep 2009 15:06:48 GMT

Here’s one of the reasons I like Rake and my custom Rake tasks that I’m building into Albacore, so much.

To generate some assembly information such as version, company name, copyright, etc., you need to do this with nant:

        1: <?xml version="1.0"?>

       2: <project name="Assembly Version Info Generator" default="buildVersionInfo" basedir=".">

       3:     <target name="buildVersionInfo">

       4:         <asminfo output=".\SomeFolder\AssemblyInfo.cs" language="CSharp">

       5:             <imports>

       6:                 <import namespace="System.Reflection" />

       7:             </imports>

       8:             <attributes>

       9:                 <attribute type="AssemblyCompanyAttribute" value="MyCompany, Inc." />

      10:                 <attribute type="AssemblyProductAttribute" value="MyProduct" />

      11:                 <attribute type="AssemblyVersionAttribute" value="0.0.0.0" />

      12:                 <attribute type="AssemblyCopyrightAttribute" value="Copyright (c)2009 MyCompany, Inc. All Rights Reserved." />

      13:             </attributes>

      14:         </asminfo>

      15:     </target>

      16: </project>

To do the same thing with Albacore, you only need this:

       1: desc "Assembly Version Info Generator"

       2: Rake::AssemblyInfoTask.new(:assemblyinfo) do |asm|

       3:     asm.output_file = "./SomeFolder/AssemblyInfo.cs"

       4:     asm.company_name = "MyCompany, Inc."

       5:     asm.product_name = "MyProduct"

       6:     asm.version = "0.0.0.0"

       7:     asm.copyright = "Copyright (c)2009 MyCompany, Inc. All Rights Reserved."

       8: end

I’ll take the half-the-size, easier-to-read lines of no angle-bracket-tax where I can write real code, any day.

Albacore: A Suite Of Rake Build Tasks For .NET Solutions

derick.bailey — Wed, 23 Sep 2009 15:14:23 GMT

After my previous post on building a “real” rake task, I decided to dive in head first and learn how to get this stuff done. I chose to drive the tasks out via rspec, through a TDD process, and I created a couple of rake tasks that are proving to be quite useful to me: an msbuild task and an assembly info generate task. Yeah, I know that this has been done to death, at this point. During the trials and tribulations of me getting down and dirty with ruby, rake, gemspec, rspec, etc, I came across some libraries that already do exactly what I set out to do.

Rubicant: http://github.com/mendicantx/rubicant
Rake-dotnet: http://github.com/petemounce/rake-dotnet
Rake-Me: http://github.com/agross/rake-me
Raken: http://github.com/stevenharman/raken
etc. etc. etc.

The point is, I know I am re-inventing the wheel. So, why did I decide to continue with my efforts, and actually produce Albacore? First and foremost, I did it so that I would have an excuse and good reason to really dive down deep into what it takes to produce a high quality, valuable toolset using ruby, rake, rspec, etc. I wanted to learn, and wanted to find out what I could and could not do easily with these tools.

With the idea of using Albacore as a way for me to learn all of these tools, I don’t plan on giving up on this toolset and using another one. I have enjoyed the process of learning and creating something useful in a new framework, and I can see a lot of value in what I’ve already created. The end result has multiple benefits and was well worth the effort.

So, with all that in mind, I present to you: Albacore – A Suite of Rake Build Tasks for .NET Solutions.

What Is Albacore?

The sub-title and everything I’ve stated so far, really do give this away. I wanted to have a suite of rake tasks that I can use for my .net solutions. In the process of creating this suite, though, I wanted to avoid the mistake of duplicating a lot of code between the rake tasks and the underlying object model that gets executed by the tasks. I’ve taken the time to learn how the rake tasks work and how to properly create an ultra-simple, light-weight task wrapper around an object model that does the real work.

At the time of this writing, there are two primary tasks Albacore includes: MSBuiltTask and AssemblyInfoTask.

MSBuildTask: This task is used to build your .NET solutions. Internally, this task calls out to the MSBuild command line. This will allow you to run the task against a .NET solution directly, or against an MSBuild file or anything else that the MSBuild exe allows you to build.

AssemblyInfoTask: This task is used to generate your assembly information – version, copyright, title, description, etc. The assembly info task writes the attributes that you supply out to the file that you specify. At this time, the only language that this task supports is C#. I don’t have any use for a VB or other .NET language version of this task, so I have not provided any mechanisms to write into other languages. If there is sufficient interest in other languages, though, I’ll work with those who are interested to create a language option.

How Do I Get Albacore?

If you would like to use Albacore for your rake tasks, all you need to do is install the gem via github’s gem server. To do this, follow these instructions:

1. Setup github as a gem source. Open a command prompt for ruby, and run this command:

gem source –a http://gems.github.com

This will add github as a source repository for you to install ruby gems from. The good news is, you only have to do this one. After you add this source, you will be able to pull any gem you want from github, whenever you want.

2. Install the Albacore Gem. Open a command prompt if you don’t have one open already, and run this command:

gem install derickbailey-Albacore

Be careful to get the spelling of my name correct (one “r”) and the capitalization of Albacore correct. This will install the library on your local box and you will be ready to use it.

How Do I Use Albacore?

To use Albacore on your project, be sure you have it installed first. Then you only need to

require ‘albacore’

in your rakefile, and you can get started. Here is the example that I have included in the default rakefile in the albacore gem:

        1: require 'albacore'

       2:  

       3: namespace :albacore do

       4:     

       5:     desc "Run a complete Albacore build sample"

       6:     task :sample => ['albacore:assemblyinfo', 'albacore:msbuild']

       7:     

       8:     desc "Run a sample build using the MSBuildTask"

       9:     Rake::MSBuildTask.new(:msbuild) do |msb|

      10:         msb.properties :configuration => :Debug

      11:         msb.targets [:Clean, :Build]

      12:         msb.solution = "lib/spec/support/TestSolution/TestSolution.sln"

      13:     end

      14:     

      15:     desc "Run a sample assembly info generator"

      16:     Rake::AssemblyInfoTask.new(:assemblyinfo) do |asm|

      17:         asm.version = "0.1.2.3"

      18:         asm.company_name = "a test company"

      19:         asm.product_name = "a product name goes here"

      20:         asm.title = "my assembly title"

      21:         asm.description = "this is the assembly description"

      22:         asm.copyright = "copyright some year, by some legal entity"

      23:         asm.custom_attributes :SomeAttribute => "some value goes here", :AnotherAttribute => "with some data"

      24:         

      25:         asm.output_file = "lib/spec/support/AssemblyInfo/AssemblyInfo.cs"

      26:     end

      27: end

I’ve included this example build of the Albacore tasks in the rakefile at the root of the gem installation, as well as all of the rspec tests for the library. With this, you can run the tests or the sample builds directly from the rakefile, in the installation folder of the gem.

You can run this sample with the following command(s):

“rake albacore:sample” – runs all of the tasks from Albacore

“rake albacore:msbuild” – only runs the msbuild task

“rake albacore:assemblyinfo” - only runs the assembly info generator task

I’m also planning to maintain the Albacore wiki on the github page, with instructions on how to install it, how to use the individual tasks, etc. You can get the link to the github project in the next section of this post.

Can I Get The Albacore Source Code?

Yes! I’m doing this as an open source (MIT license) project on my github account. You can grab the source code, fork it to your github account, or do whatever else the magic of git + github lets you do. If you add something useful, fix a bug, or make something more ‘ruby-like’ or more clear and understandable, just let me know and I’ll see about merging your changes into the main project!

http://github.com/derickbailey/Albacore

What’s Next?

I am planning to continue extending Albacore, as the needs of my projects continue to evolve. Right now, these two basic tasks are enough to get me off the ground and running. The future will likely bring NCover, NUnit, and other tasks into the mix, as my teams have a need for them.

(albacore tuna photo by daviddesign. used here under a creative commons license)

Help! E-Text Editor Can’t Run My Rake Tasks…

derick.bailey — Fri, 18 Sep 2009 13:37:29 GMT

I downloaded the E-Text Editor to work with my ruby / rake stuff, because it’s a great editor and because it supports all of the TextMate bundles. The idea is that I should be able to run all of my Rake tasks and RSpec tests directly from E. However, I can’t seem to run my rake tasks.

I’ve got Cygwin installed (am new to this… don’t really know much about it). I’ve got the Ruby one-click installer installed (I’ve been using this for several months now). And I’ve got the Ruby textmate bundle installed into E(updated it from the E bundles menu).

Whenever I try to run a rake task, though, I get this error:

I have checked for the file that it says it can’t find. The file does exist. Does anyone have any clue what this error means and how to fix it? My google searches on this have been returning nothing.

An Alternate Way To Handle Task Dependencies In Custom Rake Tasks

derick.bailey — Fri, 18 Sep 2009 00:30:25 GMT

Earlier today, I showed how to create a custom Rake task from the base TaskLib, so that we can use more than just simple “task :name” syntax for our rake tasks. In that example, I showed how to add explicit support for task dependencies by adding a second parameter to the initializer of our custom task:

        1: attr_accessor :name, :task_dependencies

       2:  

       3: def initialize(name = :some_name, task_dependencies = {})

       4:   @name = name

       5:   @task_dependencies = task_dependencies

       6:   yield self if block_given?

       7:   define

       8: end

       9:  

      10: def define

      11:   task name => task_dependencies do

      12:     #... some code here

      13:   end

      14: end

This code works, as shown earlier and provides the ability to execute dependency tasks prior to this one:

       1: FooTask.new :somename, [:someothertask, :andanother] do

       2:   # ... task detail here

       3: end

It turns out there is a much less explicit, much more ruby-ish way to do the same thing. It seems that rake understands that the name of the task (the :name accessor) is to be treated as if it were a method. Since all methods in ruby have an implicit lambda block, as we’ve seen, we don’t have to include the explicit version of the :task_dependencies in our code. We can simplify the custom task and remove all of the :task_dependencies usage. Then we only need to call the => lamba when setting the name of the task in our rake file.

This example task, with no explicit :task_dependencies works the same as the example from the earlier post, today:

       1: class FooTask < Rake::TaskLib

       2:     

       3:     attr_accessor :name

       4:     

       5:     def initialize(name = :test)

       6:         @name = name

       7:         yield self if block_given?

       8:         define

       9:     end

      10:     

      11:     def define

      12:         task name do

      13:             puts 'I Run Second'

      14:         end

      15:     end

      16:     

      17: end

      18:  

      19: FooTask.new :foo => [:bar] do

      20: end

      21:  

      22: task :bar do

      23:     puts 'I Run First'

      24: end

The result of running ‘rake foo’ on this code, is this:

As you can see, the dependency task of ‘:bar’ is executed first, as expected.

Considering everything that I’ve been learning about ruby in the last few days, I have to say that this feels more like the ruby way of coding. It is far less explicit, reduced code, still as functional, and has the syntax of a standard ‘task :foo => :bar do’ call that most rake users are familiar with.

A Failed Opportunity To Coach, Teach, And Help Others Improve

derick.bailey — Thu, 17 Sep 2009 21:09:14 GMT

A colleague in the nation of Pablo-The-Donkey asked a question on the LosTechies private mailing list:

“Has anyone had experience with bringing agile into a workplace that has legacy code that hurts to touch, let alone wrap tests around and refactor?”

I responded to the list with a little bit of my experience, and I thought the information was worth sharing. Hopefully my experience will help someone else avoid the same mistakes. So, here it is, exposing my failures and idiotic tendencies for the world to see. Be gentle. :)

My Failure As A Teacher, Bringing In Agile And Other Ideas

I have to be honest here and say that I failed miserably at introducing better practices into my current company's largest team / project, from a legacy code perspective. I had such a hard time getting people to recognize that they way they were working was painful, for a few years. They all recognize it now, but I had already given up on that team and left them to their own devices, by the time they were looking for better ways... not the best choice in my career... (I've been very successful in the other half of the organization, where "legacy" code is what we wrote 6 months ago, and the team is actively refactoring and changing as time moves on... but that's a different story.)

Part of the problem, in retrospect, was how I approached the situation. I was hardcore 'selling' agile, unit testing, sprint/iteration, etc to the developers. I was showing them how to do it on the smaller projects that I was involved in, and continuously trying to convince people that they needed to change what they were doing, all from a very 'agile is the way' salesman perspective. The real issue in how I approached it was that I basically said "you guys are doing A. A is wrong and doesn't work. You need to be doing Z instead." - I was trying to get them past all of the learning mistakes that I had made, and pushed directly to the end-goal, where they couldn't see the benefit.

Here I was, talking about how important test names are, and how the tests need to be written a certain way, and how a CI server should be run with branching and merging, and ... and the people I was talking to thought I was an idiot that was being nit-picky about things that don't matter. They weren't concerned with any of that - they just wanted to stop working 80 hours a week and have some kind of safety net to give them confidence in their work. They were looking at "A" as the big problem they had to solve... the first layer of the onion... and I was trying to tell them how the 26th layer down in the onion was problematic, when they couldn't even see that layer, yet.

I've been picking up on the way Joe Ocampo approaches change management in a development organization in the last year or so and have begun to move my change management style into something similar to what he talks about, from what I have heard / read from him. I'll let Joe enlighten us with all the gory detail, but the essence of it is to facilitate conversations on change in a manner that enables the people doing the work to be the ones suggesting the changes, with you guiding and correcting the suggestions.

I've also found Kanban systems (visualizing work, limiting WIP, pull, system thinking / continuous improvement, etc - which is where Joe pulls a lot of knowledge from, I think) to be a very effective change management system in my organization. I find that lean thinking and Kanban do not presume to say "your wrong. do it this way." Rather, it only says "you're doing the best you can in your situation. Let's start by limiting work in process so we can get individual items done faster, and we'll go from there, when you're ready."

The point of the story is to be careful about 'selling' agile and trying to 'skip to the good part' where everyone is happy and doing 'the right thing'. Even though we know what the eventual answers will be, we have to let the people doing the work, discover those answers for themselves, at times.

How A .NET Developer Hacked Out A Rake Task

derick.bailey — Thu, 17 Sep 2009 15:19:49 GMT

I spent the last two days having my brain melted by Scott Bellware, in a crash course on Ruby, Rake, RSpec, Selenium, web UI test automation best practices, and all-around uber-normal-person-language-oriented development. It was great! After the first 7 hour day, I felt like I had been awake for 24 hours. After the second 8 hour day, I felt like I actually knew something about Ruby and good web UI test automation practices.

Will The Real Rake Task Please Stand Up

In the conversations and snappy banter that ensued during and after the sessions, Scott and I talked a little about Rake and building what he referred to as ‘real’ Rake tasks instead of the ‘not-Rakeish’ tasks that most people build. By ‘not-Rakeish’, Scott was talking about our propensity as .NET developers to make everything a class and make heavy use of the “system.Object of Rake: the ‘task’”. This point is illustrated by a google search of ‘build custom rake task’. Practically every result that comes up will show you how to use “task :somename do … end” and call “rake :somename”.

Whether or not you think using standard ruby objects in a standard rake ‘task’ is ‘Rakeish’ or not, isn’t really the point. Of course that works. Yes, many people do it that way, because it works. The point Scott was making is that professional tools like RSpec and Selenium don’t provide tasks in that way. We don’t see these simple constructs being used. Rather, we see professional tasks being built so that we can call something more like this:

        1: Spec::Rake::SpecTask.new do |t|

       2:   t.ruby_opts = ['-rtest/unit']

       3:   t.spec_files = FileList['test/**/*_test.rb']

       4: end

That conversation with Scott and some other conversations around the idea of building .NET solutions with Rake got me thinking about how we could build a much more ‘professional’, ‘real’ Rake task to call out to MSBuild. While I have not yet put this solution together, I have spent some time learning how to build tasks such as the RSpec ‘SpecTask’ shown above. Not surprisingly, it’s a very simple endeavor. I honestly don’t claim to understand exactly why everything in my hacked-together custom task is set up the way it is, but I have a pretty good idea of what’s going on, at this point. So, I wanted to share my newfound knowledge and hopefully inspire some of the .NET Rake building people out there to create something a little more ‘Rakeish’, rather than just using the default ‘task :whatever’ syntax and calling into an ‘MSBuild’ object.

Defining A Custom Rake Task Using TaskLib

Since I was unable to find any good info via my google search, I started examining the RSpec rake task and the Selenium rake tasks that were installed via the gems. The first thing I found is that I needed to have the ‘rake’ and ‘rake/tasklib’ files, so that I could create a class that inherits from ‘TaskLib’. For example, I can create a task called “FooTask” like this:

       1: require 'rake'

       2: require 'rake/tasklib'

       3:  

       4: class FooTask < Rake::TaskLib

       5: end

This basic definition gives me a task that I can use via Rake. However, it doesn’t really do anything yet and doesn’t even have a name that we can call from rake.

Giving The Task A Name

To set up a good task name to use, we need to include a ‘:name’ accessor (think auto property in c#) and parameter in the initializer. This name will be used later, to tell the TaskLib base class what the name of the task is, at runtime.

       1: class FooTask < Rake::TaskLib

       2:   attr_accessor :name

       3:   def initialize(name = :some_default_name)

       4:     @name = name

       5:   end

       6: end

Notice the ‘:some_default_name"’ – this does exactly what it sounds like… sets the default name of the task. In this case, we are literally giving the name a default of ‘some_default_name’. We are then setting the @name (which has been automatically generated by the ‘attr_accessor :name’ usage… again, this is like an auto property in C#).

Letting The Task Do Custom Work

If we want to provide the ability for the user of the task to actually do some work, we need to include the lambda block evaluation that ruby has built in. This is done by yielding self if a lambda block is present, in the constructor.

       1: def initialize(name = :test)

       2:   @name = name

       3:   yield self if block_given?

       4: end

this block of code let’s us call our custom task with a ‘do … end lambda’ block

       1: FooTask.new do |t|

       2:  #do stuff with t, here

       3: end

The ‘|t|’ in this code refers to the actual FooTask instance that we yielded (‘self’), and will let us have access to all of the methods in the FooTask object, once we add some.

Defining The Default Work To Do

In all of the custom rake tasks that I have examined so far, I have found a method called ‘define’ that appears to be a standard convention for rake tasks as the location of code that gets executed by the custom task that we are creating. This method calls the TaskLib method ‘task’ with a name parameter (the name we supplied in the initializer) and then does the work. For example, RSpec does all of it’s spec parsing and running from here, and Selenium does all of it’s server initializing or shutdown here. For this example, we’re just going to print some junk out to the screen.

       1: def define

       2:   task name do

       3:     puts 'some test being printed'

       4:   end

       5: end

The ‘task name’ code is important here, as it provide rake with the knowledge of the task’s name, so that we can call it from the rake command line.

Running What We Have

At this point, we have enough code in place to run the sample rake task. Create a ‘rakefile’ with all of the above code, then add code similar to how we called the ‘SpecTask’ earlier. The contents of the rakefile should be:

       1: require 'rake'

       2: require 'rake/tasklib'

       3:  

       4: class FooTask < Rake::TaskLib

       5:  

       6:   attr_accessor :name

       7:  

       8:   def initialize(name = :test)

       9:     @name = name

      10:     yield self if block_given?

      11:     define

      12:   end

      13:  

      14:   def define

      15:     task name do

      16:       puts 'some test being printed'

      17:     end

      18:   end

      19: end

      20:  

      21: FooTask.new :my_task do

      22: end

Notice that we are giving the task a new name when we call ‘FooTask.new :my_task’. The name is being set to ‘my_task’. We can now run the task from rake via a shell prompt (command prompt in windows):

So we now have a custom rake task that is much more ‘Rakeish’. However, it’s still not terribly useful. There is no way to get data into the task and there is no way to call any dependencies before this task.

Adding Data To The Task

To add data, methods, or do something useful with the task, we can use all the usual ruby ways – methods with parameters, with ‘=’ assignment, attr_accessors, etc etc. For simplicity, let’s use an attr_accessor to create a ‘property’ (I know, it’s not really a property in Ruby, but it sure behaves like one). We’ll add an accessor call ‘:data’ and we’ll have the define method write that data out instead of our hard coded string.

       1: class FooTask < Rake::TaskLib

       2:  

       3:   attr_accessor :name, :data

       4:  

       5:   def initialize(name = :test)

       6:     @name = name

       7:     yield self if block_given?

       8:     define

       9:   end

      10:  

      11:   def define

      12:     task name do

      13:       puts @data

      14:     end

      15:   end

      16: end

Adding the data accessor will let us use the ‘|t|’ yielded to our task at runtime, like this:

       1: FooTask.new :my_task do |t|

       2:   t.data = "I'm using the data accessor!"

       3: end

Now when we run the task again, we get this output:

Using this basic pattern, along with other methods, accessors, etc. we can begin to create a task that can do much more for us by allowing the user of the task to provide configuration of the task at runtime.

Calling Dependency Tasks

The last thing I want to show for now, is how to add the ability to call task dependencies when calling our custom task.

In the ‘task :somename’ style of usage, we may want to call other tasks as dependencies of ‘somename’. This is done by using a lambda with the task names. For example:

       1: task :somename => [:somedepdency, :anotherdependency, :whatever, :etc] do

       2:  # do stuff here

       3: end

This code would call the ‘somedependency’, ‘anotherdependency’, ‘whatever’, and ‘etc’ tasks before running the ‘somename’ task.

To provide this same dependency execution in our custom task, we first need to provide a way to specify the dependencies. We can do this by adding a second parameter to the initializer, with a default value that shows we have no dependencies, and then calling the that parameter as a method or hash of methods after storing it in another accessor.

       1: class FooTask < Rake::TaskLib

       2:  

       3:   attr_accessor :name, :task_dependencies, :data

       4:  

       5:   def initialize(name = :test, task_dependencies = {})

       6:     @name = name

       7:     yield self if block_given?

       8:     @task_dependencies = task_dependencies

       9:     define

      10:   end

      11:  

      12:   def define

      13:     task name => task_dependencies do

      14:       puts @data

      15:     end

      16:   end

      17: end

Notice the additional ‘task_dependencies’ accessor, the assignment of an empty hash as the default value in the initializer, storage of the parameter in the ‘task_dependencies’ accessor variable, and then the ‘ => task_dependencies’ lambda execution in the define method. This basic code set allows us to specify a number of dependent tasks and have them executed prior to our custom task executing.

To set a dependency for this task, we only need to add the task names as the second parameter to the constructor in our rakefile. Here’s example rakefile with all of our code, a simple task to use as a dependency, and our custom task being called with that dependency.

       1: require 'rake'

       2: require 'rake/tasklib'

       3:  

       4: class FooTask < Rake::TaskLib

       5:  

       6:   attr_accessor :name, :task_dependencies, :data

       7:  

       8:   def initialize(name = :test, task_dependencies = {})

       9:     @name = name

      10:     yield self if block_given?

      11:     @task_dependencies = task_dependencies

      12:     define

      13:   end

      14:  

      15:   def define

      16:     task name => task_dependencies do

      17:       puts @data

      18:     end

      19:   end

      20: end

      21:  

      22: FooTask.new :my_task, :call_me_first do |t|

      23:   t.data = "I'm using the data accessor!"

      24: end

      25:  

      26: task :call_me_first do

      27:   puts "I'm called first, because I'm the dependency!"

      28: end

The output of this task with its dependency is this:

Moving On

Now that we have all of the core parts of a real, ‘Rakeish’ custom task in place, we can easily move our FooTask out into it’s own ‘FooTask.rb’ file and have it be a required file in our Rakefile. We could even package this up as a gem and have it be available for installation via the gem system. However, this is not a professional quality task, at this point. There are no tests written for this task, and it doesn’t really do anything valuable other than show how to hack together a custom rake task.

I hope that this little tutorial will at least provide some inspiration to the rest of my Rake using .NET developing colleagues out there in the world, though. I’d really like to see (and will probably build and distribute) a much more professional ‘MSBuild’ rake task, based on this new found knowledge. There are plenty of MSBuild ruby objects out there… it shouldn’t be that difficult to convert it into a rake task and put some unit tests around it.

A Coworker’s Response To The Future Of The Boutique Software Shop

derick.bailey — Fri, 11 Sep 2009 21:05:48 GMT

Sean Biefeld forwarded a link to Michael Feather’s Thoughts on the Future of the Boutique Software Shop earlier today and it sparked some interesting conversations at the office, via email. One response from a coworker (Robert O’Neil, who doesn’t have a blog, as far as I know) really resonated well with me. I’m posting his entire response, with his permission, and only adding one small [Edit] near the end. Although my experience set is different from Robert’s, I share the sentiments and opinions that he offers in this response.

Robert’s Response

To me, it’s a sign of maturation of the industry.

In ‘the old days’ there were no separate disciplines - we didn’t have Business Analysts, UX Designers, Systems Analysts, etc. Those came about because specializations became needed. Those who did everything well gained reputations and business; those who couldn’t fell out of the industry or worked for the others.

As the scope of work grew larger, so did the teams required and no one could doing everything anymore. As the complexity of the Domains grew, we needed analysts to dive in and really understand the issues, design the solutions, and explain them to the people doing the implementation. As the tools became more powerful, those who implemented the designs needed to specialize more with the tools and techniques to do the best they could with them. As software became more and more a commodity, the price of development had to fall, which required teams of experts in disparate disciplines working together more efficiently (hence Agile, RUP, etc. overtaking Waterfall).

In the early days the only interface a user had with software was the Priest of the Almighty Blue, who take a form asking for a report and return with a report at a later time. Then came the Mini-computer, then the UNIX Workstations, then the PC and its progeny and everyone had to learn to interact with each architecture’s Operating Systems – almost all command line based. Each piece of software, if it had a graphical interface, was different based upon design philosophies and graphical library. The better designs and philosophies outgrew the others.

Then came Graphical interfaces (Motif, X-Windows, Mac, GEOS, and finally MS Windows) and standard interfaces became the rage. No one wanted to learn a different way to do the same thing in different applications, so the creators of the interfaces defined ‘the way’ and no one had to think about user Interactions anymore. Anyone who did was labeled a heretic and made to conform.

Now we’re in the age of Software as a Commodity, Software as a Service, and Web 2.0 -- and user interfaces, user interactions, and work and data flow are once again important to delineate your software from your competitors. Thus the need for people who understand how to make software interfaces, interactions, and work and data flow interesting, efficient, elegant, enjoyable, transparent, and desirable.

Thus the problem isn’t that software never needed these people before, but that their need was lessened by ‘standardized’ interfaces and behaviors. It was exacerbated when developers stopped being taught and learning the aspects of this art; this craft. These types of people have always been with us, but their roles were reduced by the software ‘Industrial Revolution’ that relegated their input to how to best follow standards, not revise them or break them when it made sense for the product and the end-user.

I’m personally glad to see them reappear.

Rant Warning!

The biggest issue I’ve seen every step of the way in my life as a developer of software is that there are people who care about quality and those who don’t. There are people in our industry who don’t think of what we do as a craft, of our craft as a blending of science, engineering, art, and aethstetics -- and of ourselves as craftsmen. There are people who don’t want to learn to improve what they do as much as they want to collect methods so they can hold them up as an achievement, as if the number of ways you know to do things is more important than doing them well.

Every craft has people who do it for the money and not for the love of creating something people will appreciate and enjoy. Yet our craft, like others, continues to thrive and improve because there are people who do care. There are people who care as they create the best software they can (or are allowed). There are people who care as they teach how to create better software. And there are people who care as they investigate ways to be better at creating software, ways to be more efficient and cost-effective at creating software, and ways to make software itself better.

Before I became a software developer, I worked in home construction. I saw the same divisions there. I saw workers who threw things together the quickest and easiest way they could; they didn’t care. I saw workers who would do the minimum required to get their money, who would take shortcuts, and hide deficiencies. I saw workers whose work fell into ruin within a decade.

I saw craftsmen who would tear out their work and redo it because it didn’t meet their values of quality, even though it could mean working extra hours to catch or keep up or miss a deadline. I saw craftsmen who’d take the time to teach their juniors how to do it better. I saw competitors discuss methodologies and techniques with each other because it improved their craft—even though they were giving away what some would consider ‘trade secrets’. I saw craftsmen whose work stands the test of time and is still well-founded and solid to this day.

Will you be a craftsman who cares about your craft, your product, and your reputation? Or will you be a code monkey and do the minimum asked of you to merely ‘get the job done’?

I saw builders who counted the number of homes they could produce each year as more important than the quality of those homes; they were counting the money instead of the smiles of owners happy with their new homes. They built huge tracts of houses almost overnight. Almost none of those builders are still in business to this day and their tract homes began to fall apart – in less than 5 years, in some cases.

I saw builders who took the time and the effort – and the money – to ensure the homes they built had a quality that ensured respect. They hired and retained craftsmen, they acquired the best materials, they nurtured neighborhoods, and they only worked for clients who understood that craftsmanship sometimes cost more but would pay for itself. Most of those builders are still in business today. Their products are still viable and enjoyed by their owners – some almost 40 years later!

What kind of place will we let [insert your company name] be? The answer to that depends upon what kind of craftsmen we are and what kind of reputation our work gains the company and ourselves.

</end rant>

I made this rant because this comment hit a chord with me:

Great piece. This is exactly what I feel. I've been through the big corporate IT treadmill. In my younger days I was slapped down by senior management for throwing things round the office when people were screwing up because they just didn't care (I'm Scottish, like Ramsay). I grew out of that to the point that I was considered an asset for my ability to keep my cool in front of provocatively stupid customers. But a bit of you dies if have to keep hiding the fact that you care, that you don't like producing 3rd rate crap at the lowest cost.

Since I left the corporate life my enthusiasm for IT has been reborn. I've really been enthused by UX. That perspective is exactly what was missing from the techno-driven, "be grateful for whatever we give you" paradigm I'd grown up with. I've also been excited by the opportunities Agile has given for UX to be drawn into the heart of the development community, provided the UX people really want to shed their independence and get real influence at last.

It was an interesting point about most developers lacking the right "neural wiring" for UX. That's probably historically true, but perhaps more important is that UX never really featured in the education, training or experience of developers. If they thought about it at all (unlikely) they saw it as peripheral, out there somewhere, a subjective and imprecise discipline that had no real affinity with the clear, logical, realities of software development.

Developers aren't born knowing about all the essential disciplines surrounding the actual coding. They have to be taught the value of configuration management, release management, security & carefully designed databases.

If they are exposed to UX right from the start of their careers and if they are constantly shown how important it is to the development of high quality applications then they will get it. Maybe not many of them will be talented interaction designers, but at least they'll avoid the crasser mistakes we all used to make. They will recognize the need to work with the UX professionals, and they will see the value in what UX can contribute to the work of the team.

Some Initial Thoughts On Agile Developer Skills And Certification

derick.bailey — Fri, 11 Sep 2009 19:10:44 GMT

There’s a new mailing list over on Google Groups surrounding the ideas behind Agile Developer Skills Certification. After reading this post by Ron Jeffries, I joined up with the group and started reading the traffic. I generally share the same opinions as many of the people on this list about multiple choice, memorization based 'tests' - the Microsoft Certifies XYZ type test where the only thing you need is a good memory and no real skill. This type of test is lousy and we should avoid it at all costs.

Then, a response to a another post by Keith Braithwaite got me thinking and re-surfaced some previous thoughts that I've had but never articulated. Keith's statements were:

That seems to me like a somewhat mystical view of "skill". I think that the IEE Certificate I mentioned in a previous post did something useful and conrete. Here's what I had to do to get it:

Solve a small simulation problem in C++. I got extra credit because I kept my source under version control.

Devise and build a small relational database schema to handle a business problem, put a VB UI on it.

Implement a very (very!) simple network protocol on top of sockets in C. I got extra credit because I made the documentation of my protocol look like a man page.

Model a problem domain using OMT Work in a small team to plan and execute a small development project to build a small app in C++

Write an essay showing an understanding of some well-known IT project disasters and their causes.

The approach that Keith describes here reminds me of the education system for receiving a Masters degree or Ph.D. My wife is a Ph.D. in Social Psychology and a professor at Baylor University. I regularly have conversations with her about the Masters and Ph.D. students that she is advising/mentoring,I was dating her during her last few years of graduate school and I remember her describing how her Ph.D. defense was conducted.

The Masters / Ph.D. Defense

When a Masters candidate goes up for the final 'certification' that they are worthy of having a Masters degree, in psychology, they don't take a multiple choice test, a written test, or anything that involves memorization like that. The candidate has a Thesis in the form of a study, the collected and analyzed results, and the final write-up of the results and information and how it contributes to the global community of psychologists. The candidate takes this information and presents it to a panel of 'judges' that grille the candidate with questions that are designed to make them think, all with the purpose of seeing how they respond and how they handle the questioning, as well as to test the foundational knowledge of the candidate, to ensure that they understand the foundations and details of what they have built.

When the psychologist with a Masters degree is then going up for the final 'certification' of having a Ph.D. worth skillset, they again go through the same type of process - only significantly more in depth and detailed, requiring much more analysis and writing of the results, and with a much greater level of scrutiny and nit-picking from a much more judgmental panel of other Ph.Ds.

(Yes, I know got many of the details of the Masters Thesis and Ph.D. Dissertation defense wrong. The details aren’t the point and are not that important at the moment.)

Software Development Is Not Unique

It seems the software development community has thought itself to be unique in terms of demonstration of skill, and I believe that it's an incorrect view of the software development world. We as an industry have a bad habit of this, as we've seen with the recent explosion of Lean Software Development and Product Development based theories and practices that are being assimilated into our craft. Psychology - especially social psychology - is as much a 'touchy-feely' art as it is science, in my opinion. Sounds a lot like software development, doesn’t it?

Taking A Page From Masters / Ph.D. Candidacy

The point of my lengthy blabbering is to say that I believe we should take a page out of the world of Masters / Ph.D. candidacy and defense to create a similar and as reputable form of Agile Developer Skills certification. There's a tremendous history and wealth of knowledge to be pulled from, in the education and psychology community, and it would be a shame to ignore such a wonderfully paralleled industry.

What Do You Want To Know, About Kanban In Software Development?

derick.bailey — Thu, 03 Sep 2009 15:17:38 GMT

I asked this question via Twitter a few minutes ago, and wanted to ask the non-twittering inter-web-o-blog-reading public:

if I were to do an Intro To Kanban presentation for your team/company/local-user-group, what questions would you want answered?

Let me know what you would like to have answered, and I’ll see what the common threads are. The resulting presentation material will be made available via my GitHub account, and I’ll likely end up answering some of the questions via blog posts, too.

A Kanban Board Is A Production Leveling Task Board

derick.bailey — Thu, 03 Sep 2009 00:50:38 GMT

In the lean manufacturing world heijunka - production leveling - “is a technique for reducing the mura waste and vital to the development of production efficiency […]. The general idea is to produce intermediate goods at a constant rate, to allow further processing to be carried out at a constant and predictable rate.” – from Wikipedia. While heijunka is the process of eliminating variance or unevenness in the system, a Heijunka Box is a tool that is used to achieve the goal of heijunka. It is a visual representation of the production system that is used to show how the work is being scheduled and mixed

What we tend to call a Kanban Board in software development is a close relative to a Heijunka Box. However, we have taken the roots of the heijunka box and added some parts of the production line to the box, directly. Most notable are the queues or storage bins that sit in front of or behind a given step in the process. We have also taken a great amount of influence from agile methodologies such as Scrum’s sprint boards and XP’s task boards, for our Kanban boards.

Figure 1 represents a very generic three step process that receives input from an upstream supplier and delivers to a downstream customer. This generic form of a Kanban board is very typical for a simple system.

Figure 1. A Kanban Board. Also-Known-As HeijunkaBox++

Some of the key differences between a sprint board in Scrum or a task board in XP, and a Kanban board are the following:

Focus On The Entire Value Stream: Scrum and XP tend to be very focused on the developer activities, assuming that activities that occur prior to and after the development effort are taken care somewhere else. Kanban focuses on the entire value stream – from “that’s a great idea!” all the way down to “here’s some $ for the software you just gave me” – from concept to cash.
Limited WIP: This is the mechanical process of limiting the amount of work in process (WIP) in the system at any given time. It’s what let’s us get stuff done and is what leads us to the “pull” of a Kanban system
Queues: We have taken the concept of a storage bin with a safety stock off the production line of a manufacturing floor and made it an explicit concept in our visualization of WIP and intellectual inventory
Production Leveling: A team may not care about variance in a user story from Scrum or XP. They typically only care about whether or not they can complete the story within the sprint or iteration

Both limited WIP and queues have been discussed by a significant number of persons around the inter-blog-o-webs. A quick Google search on kanban in software development will turn up a good number of resources, including my own posts on the subject. In contrast, though, the idea of production leveling in software development seems to have taken a back seat. It is often ignore entirely as not transferable from the manufacturing world, or is done implicitly within a team already and never made into a first class citizen of our process. This is a shame since production leveling, or not, can have a direct financial impact on a system – even if we are already working to capacity via a pull based system like Kanban.