new ThoughtStream("Derick Bailey");

Design And Testability

derick.bailey — Fri, 10 Sep 2010 16:28:52 GMT

In the line of business applications that I build, it’s considered good practice to use a test-first approach; Test-Driven Development, Behavior-Driven Development, or whatever you want to call it. Write a test, verify that it fails for the right reasons, make it pass, refactor the code to ensure it’s up to all required standards. How a person goes about doing the implementation of the tests and the code to fulfill the tests depends largely on the platform, language and testing tools used. Each platform has different needs and different ways of approaching the idea of “testability” in code. Some languages require specific design decisions to enable testable code, while other languages pretty much guarantee that your code will be testable – even if some designs are easier to test than others.

Design And Testability In Ruby

If I were writing some code in Ruby, I could easily test this:

        1: class Foo

       2:   def bar

       3:     baz = Baz.new

       4:     baz.do_something

       5:   end

       6: end

There are a number of options for being able to test the behavior of the Foo class’s .bar method. I could use the nature of Ruby’s open-type system and just replace the initializer and do_something method on the Baz class; I could use RSpec and it’s built in mocking syntax; I could use the not-a-mock gem (which is my preference) to stub the methods; etc.

We essentially get testability in ruby for “free” – it’s built into the dynamic nature of the language. Other dynamic languages such as Python, etc, also give us testable code by nature of the language. We are not required to do anything special to create code that is “testable”. Now that doesn’t mean all code is easily tested, though. There are still design principles and paradigms that will make your code easier to test, which also tends to lead to code that is easier to understand. The point, though, is that you don’t have to do anything special to isolate the behavior of the Foo class from the implementation of the Baz class in the above example.

Design And Testability In C#

Looking at the equivalent code in C#, we would say that this code is not “testable” from the perspective of unit tests:

       1: public class Foo

       2: {

       3:     public void Bar()

       4:     {

       5:         var Baz = new Baz();

       6:         Baz.DoSomething();

       7:     }

       8: }

By all the principles, practices, and design standards that we preach in C# / .NET, this code is not testable because of the hard dependency on the Baz object and it’s implementation.

There are a significant number of principles that are being violated in these few lines of executable behavior, and we would need to change the code in a very significant way to create something that is “testable”. We would need to introduce an abstraction over Baz – but ensure that the Foo class owns the abstraction so we don’t violate the Dependency Inversion principle. And we would need to introduce Inversion Of Control and some form of Dependency Injection to ensure that Foo is not directly dependent on Baz’s implementation (neither the constructor nor the DoSomething method’s implementation). The resulting code, to be “testable” by all accounts, would look something like this:

       1: public class Foo

       2: {

       3:   private doSomething;

       4:   

       5:   public Foo(IDoSomething doSomething)

       6:   {

       7:     this.doSomething = doSomething;

       8:   }

       9:   

      10:   public void Bar()

      11:   {

      12:     doSomething.DoSomething();

      13:   }

      14: }

      15:  

      16: public interface IDoSomething

      17: {

      18:     void DoSomething();

      19: }

      20:  

      21: public class Baz: IDoSomething

      22: {

      23:     public void DoSomething()

      24:     {

      25:       // ... whatever this does...

      26:     }

      27: }

(Note: I included the shell of the implementation for Baz in this example – but those extra few lines of code don’t diminish the expansion of the rest of the code. I included it to show the requirement of implementing the interface on the Baz class.)

Angels And Demons

As a person who dabbles in ruby and that community, I get the sense that we applaud Matz for the open nature of ruby, allowing the great minds of people like David Chelimsky to develop tools like RSpec with it’s built in mocking capabilities. We have the freedom to express the intent of our code without the significant ceremony of the abstraction, dependency inversion, and “testable” code the we say is required in C#. These people are the heroes – the angels - of the ruby community, held in high esteem because they have made the art of “testable” code approachable by anyone that can write code. And they deserve our applause for these efforts, without question. The tools and capabilities in Ruby and RSpec are quite wonderful and I enjoy working with them.

Why, then, do we demonize companies with tools like Telerik’s JustMock, Typemock’s various offerings, and Microsoft “Pex and Moles” for providing the same capabilities in C# / .NET? Why do we attack people like Roy Osherove and dismiss his contributions to the community? Have we become so dogmatic about our “principles” and “standards” that we no longer have a sense of pragmatism or exploration and questioning? Has the “alt.net” community become “dogma.net”, “elitist.net”, or “hate.net” as so many others have suggested, for so many years? What value do we truly gain – other than the admiration and awe of the people that wish they were “smart enough” to point out the “flaws” – through this continuous disregard for what is a valid perspective and approach to software development in .NET?

What’s The Point?

I honestly ask – why? … or, why not? If I can write this test in rspec:

       1: Baz.should_receive(:do_something)

or write this test in typemock:

       1: var fake = Isolate.Fake.Instance<Baz>();

       2: Isolate.Swap.NextInstance<Baz>().With(Fake);

       3: //... run the foo.Bar method, here

       4: Isolate.Verify.WasCalledWithAnyArguments(() => fake.DoSomething());

why shouldn’t I write that one in typemock? Why should we applaud the ruby community for it’s contributions and demonize the .NET community that has given us the same core capabilities. Is it because the capabilities to do this are not “free” in a static language? Is it because we’re afraid of the profiling API that is required to do this in .NET? Is it because we’ve become dogmatic instead of pragmatic? Is it because TypeMock is expensive? or is there a legitimate reason that we have emotional reactions and cry-foul the possibilities that these tools introduce?

Searching …

I don’t know the answers. I’m asking because I want to find the answers. And yes, I recognized that I still have an attachment to the abstractions and interfaces. I’m not gong to go spend the $ on TypeMock or JustMock today, but at least I’m asking the question in an open and honest manner. I hope the rest of the <divisive-name>.NET community will join in and begin to question everything we hold sacred. We might actually learn something if we do.

Knowing when to ask

derick.bailey — Wed, 01 Sep 2010 15:29:18 GMT

It doesn't matter how much experience you have, what your title is, or whether you are considered a leader in the team / project / company. If you don't know yourself and when you need to ask questions, you're going to be in trouble. You must be able to evaluate your own perspective and whether or not you are stuck down in the weeds or not.

I’m mapping individual trees, not surveying the forest

I just got off the phone with a coworker who is the 'point person' on a new feature set. I called him and asked for advice on two separate issues related to the piece that I am currently working on. 1) a design problem with the workflow, and 2) whether or not i should "do it right" or "get it done".

My own perspective and involvement in the process had led me down into the weeds of implementation detail where I needed to be. I recognized an issue in the implementation that was causing problems with the workflow. I also recognized that my current depth and focus were preventing me from seeing the big picture (schedule, budget, etc). My reaction to the design problem was one of “do it right” because I was focused entirely on the implementation issues at hand. I knew that I needed a higher level perspective to understand whether or not “do it right” was the correct response, though. So, I called up my coworker and asked for help. We discovered two possible solutions through the conversation. One of them was “the right way” to make the code conform to all of the principles and patterns that we try to use. The other was “well, you could just do this and get it done without a major rewrite”, ignoring many of those principles.

Lose the ego and the pride

In the end, I was not capable of making the decision to “do it right” or “get it done” because I was too far down in the weeds of implementation detail. I needed a different perspective and advice on how to proceed and I found that perspective by asking questions and seeking advice.

I don’t care about my title, role, or over-arching responsibilities on the team, the project or within the company. It would have been irresponsible of me to assume that I could make the decision on my own at that point in time. This does not mean that I always have to seek advice and others’ perspectives. It only means I know when I need to seek advice and others’ perspectives. It also creates opportunities for me to take the opposite role on a regular basis. I am often the person with the high level perspective who is capable of providing advice on whether or not someone else can take the time to “do it right” vs “get it done”. And because I know when to ask and I do ask when I need to, others are also willing to ask because they see that it’s ok to ask.

If you refuse to ask; if you don’t know when to ask; if you are afraid to ask; you are potentially damaging your career, team and project. Lose the ego, drop your guard and give up your pride for a moment. Learn when and how to ask for the help that you need.

“Bring out yer dead!” clang

derick.bailey — Sat, 07 Aug 2010 00:38:57 GMT

Today, the twitterverse that I follow reminded me of the Monty Python “Bring out yer dead!” skit at the beginning of the quest for the holy grail. If you don’t know what I’m referring to, watch this:

Bring Out Yer Dead! *clang*

The “I’m not dead yet" victim, today, is IronRuby as the majority of the .NET developers I am following on twitter are quick to declare “ironruby is dead”.

A Troubled Future For The DLR And IronRuby

It all started with a blog post from Jimmy Schementi. If you haven’t read this post, go read it now.

Yes, the contents of his post are infuriating. Once again, Microsoft has dropped the ball on what had the potential to be a tremendous advancement in the .NET world: the DLR and the Iron* dynamic languages. Yes, I’m disappointed in what Microsoft is doing, but I’m not surprised. Yes, I’m sad that IronRuby is not getting the kind of love and attention (and funding!) that I think it should be getting. Yes, I want to bitch and moan about it.

Yes, it looks like the future of IronRuby is going to be slow going for a while. But I would hardly say ironruby is dead at this point. More than anything, though, I’m disappointed with the immediate response of the .NET community, as shown in the above screen shot of a twitter search I did.

“I’m Not Dead Yet”

While the .NET community is so quick to jump on the bandwagon of dismissing IronRuby and claiming it’s dead, trying to dump the body on the passing cart, Jimmy and his former coworker that he mentioned are probably wondering why no one is hearing IronRuby say “I’m not dead yet!”

Here’s the the thing, people… I know this may be shocking or unappetizing or whatever… but it’s the obvious point that I’m trying to make in this post:

IronRuby Will Only Die If We Let It Die. It’s Open Source for crying out loud! If you don’t want it to die, CONTRIBUTE!

Now, I do understand that Jimmy’s post was talking about the DLR at large, and not just IronRuby. And yes, it is worrying that the DLR is not getting funding, either.

Honest question here: does IronRuby actually need the DLR? There is an IronRuby v1.0 runtime for .NET 2.0 and .NET 3.5, and there is still an IronRuby runtime for .NET 3.5 with v1.1 of IronRuby. Does the DLR run on .NET 3.5? I thought it was 4.0 only. If the IronRuby runtime does not require the DLR, then forget the DLR and it’s non-funded status. Work with and contribute to the IronRuby runtime that does not need the DLR.

Do Something About It

I’m going to say this again, because it needs to be repeated: IronRuby Will Only Die If We Let It Die. It’s Open Source for crying out loud! If you don’t want it to die, CONTRIBUTE!

I don’t claim to know how to contribute. I don’t claim to have contributed. I do know that an open source project without any contributors is likely to die long before an open source project with contributors. So stop waiting for the dead body collector to whack IronRuby over the head while it says “I feel happyyyyyy!!!”, and help keep an open source project alive.

Albacore v0.2.0 Preview 2 Is Available

derick.bailey — Fri, 06 Aug 2010 19:42:26 GMT

I’ve pushed another preview release of albacore up to rubygems.org. This release builds on the changes that I talked about in the Preview 1 Notes and adds (what I think is) some great new capabilities for contributors and end-users, both.

Installing The Preview

This is all you need to install the preview version:

        1: gem install albacore --pre

The inclusion of ‘--pre’ on the command line will tell the gem system that you want to install the latest preview version of albacore. You will then need to modify your rake file to use the preview version (v0.2.0.preview2):

       1: require 'rubygems'

       2: gem 'albacore', '=v0.2.0.preview2'

       3: require 'albacore'

       4:

The second line tells the gem system to use the specific version of Albacore that you want, when the Albacore gem is required.

A Refocus (Again)

In the preview 1 notes, I talked about a few tasks being removed and gave a reason why – to focus albacore down to it’s core of build related tasks. In the time since then, there has been numerous discussions of this on the albacore mailing list. The end result of the discussion was a realization that the focus of albacore should not be “build” vs deploy tasks, but “high quality, value adding” tasks related to building .NET based systems. This shift in focus came after some great counterpoints and discussion on how build vs. deploy is often a gray area, and how splitting out into multiple gems for these concerns would likely be a bad thing in the long run. Rather than focus on an arbitrary distinction such as build vs. deploy, we are now moving forward with the idea that the tasks we do include should be of the highest quality and should add significant value. We shouldn’t repeat a task or a capability that is found elsewhere in ruby or a ruby gem unless we are creating something that is truly valuable and unique in comparison.

Note that the tasks listed as going away in the preview 1 notes are still going away. We are simply re-stating why they are going away: they didn’t add value, or they duplicated functionality that can be found elsewhere.

Albacore Task Updates

There are not a lot of task updates in this preview release, but the ones that are there are fairly significant.

CSC Task

A handful of new options have been put into this task, which should hopefully make it close to if not ready for prime-time. I imagine that we’ll still need some additional options, but this version of the csc task is on the right track.

The new options include:

debug: tell csc whether or not (and how much) debug information to put into the assembly.
define: set compiler symbols for your builds
doc: generate xml documentation for your assembly
optimize: optimize the code in your assembly
resources: embed resources into your assembly. this is a simple version that only embeds files directly. no options for identifier or accessibility exist, yet.

       1: csc :build do |csc|

       2:   csc.resources "file1", "file2", ... "fileN"

       3:   csc.debug = true # true, false, :full, :pdbonly

       4:   csc.define :whatever, :something, :etc

       5:   csc.doc = "path/to/docfile.xml"

       6:   csc.optimize = true # true or false

       7: end

For more information on these options, see the csc command line documentation.

SQLCmd Task

A few new attributes have been added to this task that will make it easier to use and add more options for authentication. These options include:

trusted_connection: use a trusted connection instead of supplying a username and password
batch_abort: “on error batch abort” – causes sqlcmd to return a failure code if any of the scripts run encounters an error

There are some behavioral changes related to these options, as well. If you do not specify a username and password, then the sqlcmd task will default to a trusted connection. This means you don’t need to specify any authentication information or options when setting up your sqlcmd tasks and sqlcmd will assume you want to use a trusted connection. If you specify a username OR password, though, the sqlcmd task will assume you do not want a trusted connection. You can manually override the trusted connection behavior by specify .trusted_connection in your tasks.

Batch abort will be assumed, by default, if you provide more than one script for sqlcmd to run. You can override this behavior by explicitly setting .batch_abort to false in your tasks.

And finally, the task will search your “program files” folder for SQL Server 2005 or 2008 if you don’t specify a .command attribute, directly. Note that it currently does not look in the “x86” program files folder on x64 machines. That will be done hopefully in the next release (preview or final release of v0.2.0).

       1: sqlcmd :runscripts do |sql|

       2:   sql.trusted_connection = true # or false

       3:   sql.batch_abort = true # or false

       4: end

For more information on the new options, see the sqlcmd documentation.

AssemblyInfo Task

To support attributes that need more complex parameters or have other complex needs, a .custom_attributes attribute has been added to the assemblyinfo task.

       1: assemblyinfo do |asm|

       2:   asm.custom_data(

       3:     '[assembly: XmlnsDefinition("http://www.acme.com", "Acme.Common.I18N")]',

       4:     '[assembly: XmlnsDefinition("http://www.acme.com", "Acme.Views.Helpers")]'

       5:   )

       6: end

Internal Cleanup And A Plug-In System

This release has a lot of internal cleanup of the codebase, the way tasks are created, the handling of the Albacore.configure block along with the code that plugs into it, and much more. In addition to removing many of the files that used to make up albacore (as they were no longer needed), we also reduced the size of the gem from ~400K downto ~40K by filtering out additional files that are not necessary at runtime. This means albacore will download and install faster than ever! This should also reduce the amount of time it takes to load the albacore codebase in your rake tasks.

The net result of the cleanup effort has produced a lot of good results: a reduction in the number of files that represent that albacore framework; an easier to work with framework that allows tasks to be created with only a simple include statement; and a plug-in system that allows contributors and end-users with specific needs not currently baked into albacore to develop their own tasks and plug directly into the albacore configuration with ease.

Custom Tasks

It’s now easier than ever to task advantage of the albacore features and create your own rake tasks. I’ve talked about how simple it is to create your own rake tasks, already, but the albacore framework gives you more than just a way to create tasks. It also gives you access to a unified logger, the configuration api, easy-to-create and use hash and array attributes for your object model, and more.

To create your own task with the albacore framework, you only need to do a few things:

“include AlbacoreTask”. this module will bring most of the albacore functionality into your class and it will create a custom rake task for you, using the name of your class.
a no-args initializer. all albacore task classes need to have an initializer that can be run with no parameters. you can allow optional parameters if you want.
an execute method. all albacore task classes need to have an execute method – again, with no parameters – so that the task can call .execute on your class

I’ve built a small example task to replace the old ‘expandtemplates’ task (which is deprecated in v0.2.0). This new version of the task uses the build in ERB functionality of ruby and accepts a hash as the key / value data to populate the ERB template.

       1: require 'erb'

       2:  

       3: class ExpandTemplate

       4:   include AlbacoreTask

       5:  

       6:   attr_accessor :template, :output

       7:   attr_hash :settings

       8:  

       9:   def execute

      10:     expand_template(@template, @output, @settings)

      11:   end

      12:  

      13:   def expand_template(template_file, output_file, settings)

      14:     template = File.read template_file

      15:  

      16:     vars = OpenStruct.new(settings)

      17:     vars_binding = vars.send(:binding)

      18:  

      19:     erb = ERB.new template

      20:     output = erb.result(vars_binding)

      21:  

      22:     File.open(output_file, "w") do |file|

      23:       puts "Generating #{file.path}"

      24:       file.write(output)

      25:     end

      26:   end

      27: end

Once you have this class defined in a file, you only need to “require” it in your rakefile (or you can put this class directly in your rakefile if you want). The inclusion of “AlbacoreTask” on line 4 will automatically create an “expandtemplate” task for you. You can then call the task like any other albacore or other rake task:

       1: expandtemplate :appconfig do |tmp|

       2:   tmp.template = "templates/app.config.template"

       3:   tmp.output = Files[:output] + ".config"

       4:   tmp.settings( 

       5:     :mysetting => "this is some settings",

       6:     :connectionstring => "some connection string"

       7:   )

       8: end

To see this example do it’s thing, take a look at my vimbacore project on github. It’s my playground where I test out a lot of the new features and functionality of albacore, and I’ve included this (and a config example) in that project.

Custom Task Names

There are times when you want to name a task’s class one thing, but you want to have the task method (the method that you call in your rakefile) named something else. An example of this in albacore is the “nunit” task. The class that runs and defines this task is actually called NunitTestRunner. To avoid having tasks with long, ugly names like that, you can specify one (or more) task method names in your class by specifying a “TaskName” constant prior to the “include AlbacoreTask” line in your class. Here’s how the NunitTestRunner class is defined:

       1: class NUnitTestRunner

       2:   TaskName = :nunit

       3:   include AlbacoreTask

       4:   # ...

       5: end

The use of “TaskName = :nunit” instructs albacore to create the task method “nunit” instead of “nunittestrunner”. You can also specify multiple names if you want aliases for your task:

       1: class MyCustomTask

       2:   TaskName = [:task1, :task2, :taskN]

       3:   include AlbacoreTask

       4: end

This will create 3 task methods that you can use from your rakefile: task1, task2 and taskN.

       1: task1 :foo do |t|

       2:  # ...

       3: end

       4:  

       5: task2 :bar do |t|

       6:  # ...

       7: end

       8:  

       9: taskN :baz do |t|

      10:  # ...

      11: end

Custom Configuration

The Albacore.configure block also support plug-in capabilities. All you need to do is create a ruby module that includes “Albacore::Configuration” and your module will automatically become part of the Albacore.configure block. Here’s an example that doesn’t really do much (again, this example is in my vimbacore project) but illustrates how simple it is:

       1: module ExpandTemplateConfig

       2:   include Albacore::Configuration

       3:  

       4:   def expandtemplate

       5:     puts "..........Albacore.configure.expandtemplate was called. This is a demonstration of the configuration plugin system.\r\n\r\n"

       6:   end

       7: end

You can then call .expandtemplate in the Albacore.configure block:

       1: Albacore.configure do |config|

       2:   config.expandtemplate

       3: end

Like I said – this example doesn’t do much. But it does illustrate how simple it is to create a plugin for the configuration system.

Automatic Configuration Mixins

If you are creating your own tasks using albacore, you can have your configuration options automatically mixed in by placing your config module in a “config” folder next to the file that your task is defined in. Look at the way I’ve set up the vimbacore project:

and the config folder:

The file names are important for the config module to be automatically included. Name the config file after the task’s class with “config” at the end of it. In this case the class is named “ExpandTemplate” so the config file is located in ./config/expandtemplateconfig.rb

By adhering to that simple layout, your config module will be loaded up and runtime. Combine this with the “include Albacore::Configuration” that I mentioned agove, and you have automatic Albacore.configure mixins!

Moving Forward…

As the final release of v0.2.0 approaches, we’ll be working to do additional clean up on the albacore functionality, add more options to existing tasks, and create a few new tasks. We’ll also be documenting the albacore functionality so that others can take advantage of it without having to read through the source of existing tasks. We want to make albacore easy to use and highly customizable, and that requires a comprehensive set of documents describing how to access the functionality in albacore.

Vendor Lock-In Vs. Best Of Breed Tools

derick.bailey — Tue, 27 Jul 2010 12:00:00 GMT

I posted the bulk of this on the Albacore group as a reason for my wanting to take Albacore down to it’s “core” as a suite of build related tasks (which I talked about in the Preview1 post). However, I thought the information was enough to warrant it’s own post on my blog… so here it is: why I think best-of-breed tools that you tie together yourself tend to be better than the all-in-one vendor lock-in approach.

As a .net developer, I’m used to seeing the "all in one" solutions being handed to us by various vendors. Microsoft gives us Visual Studio, they give of Office, they give us Team Foundation Server. Telerik gives us UI controls for WinForms, Web, WPF, and even an ORM and test framework. Oracle provides a database engine, business rules / erp system and much much more. It's the nature of software-as-a-business model, to a certain extent – at least in the .NET world. Vendors want you to use their tools because they need to make money. So it makes sense for every vendor to offer complete solutions that work well with their own items. You see a lot of integration and interop between the products that one particular company produces.

Unfortunately, this has a ripple-effect into the open source efforts in .NET as well. There tend to be a lot of the same things being done by many different people because everyone expects to see a one-stop-shop for the things that go hand-in-hand.
In the ruby world (and in the *nix world in general), you don't see this very often, if at all. You see many individual pieces being put together to create something that is larger than the sum of the individual parts. Many of the small pieces that one large system uses will be pulled from many different vendors, and each of them will do their one specific thing really really well. Look at Rails3 for example. There’s the core of Rails, but there’s also the direct use of Thor, the SQLite integration, the Test::Unit and RSpec integration, the Rake integration, etc. There are so many parts of what Rails is that most people outside of the ruby world tend to think that Rails is the only thing that ruby does (yes, I have heard people say things close to this).

Looking back at my development experience, I’ve been exposed to both worlds – the vendor lock-in world and the best-of-breed world. At this point in my career, I prefer the many-tools, best-of-breed approach. I've done the whole vendor-lockin thing with one stop shops and it has burned me more times than i can count. There are inevitably issues that I have with the toolset and/or things I want to do that the toolset just can’t do, and I’m stuck. I am using the tools that don’t do what I need and often can’t do anything about that. Having taken the other approach in the tools and vendors that i choose over the last 4 years or so, I find it to be overall better. Instead of locking me into VS+TFS and the "one microsoft way", for example, I found subversion + trac + apache. Later, trac no longer served my needs so i switched to redmine. When that no longer served, I dropped trac and apache and went to VersionOne (letting them host it). Now that subversion is no longer fitting my needs, I am in progress of dropping it for git.
The best-of-breed mentality and capabilities of many small pieces gives me flexibility and control in situations like this.

Now this doesn’t mean that I won’t choose a vendor simply because they are an all-in-one package. There are times when that package is going to be the right tool for the job at hand, and those tools should be consider and used when appropriate. The point I’m making is that when you do select a tool – any tool – be sure that you are selecting the tool that fits your needs for what they are, and be sure to find tools that allow you to change according to how you need to change. Chances are, the big all-in-one tool (like TFS) is not going to be sufficient for every one of your needs unless you are willing to bend your needs to what the tool can do. And that, quite frankly, is the wrong thing to do. A good selection of the best-of-breed tools may take a little more time to set up and learn, but it will likely pay for itself in the long run when you are able to replace one or more pieces to keep up with your team’s needs.

How To Build Custom Rake Tasks; The Right Way

derick.bailey — Mon, 26 Jul 2010 21:04:46 GMT

A long time ago (last year) I wrote a few blog posts that talked about how I was going about creating some custom rake tasks. This turned out to be the beginning of my albacore project and I’ve been working on that project for nearly a year now. It’s been a lot of fun and I’ve learned a lot in the process of creating and maintaining it. One of the things I learned recently is that the way I am currently handling task creation – the way that I talked about in those posts – is not the best way to do it. There is, in fact, a much easier way to create a custom rake task: the Rake::Task.define_task method.

A Simple Rake Task

The following code creates a rake task called “foo”, then defines a task named :bar and sets it up to run as the default task.

        1: def foo(*args, &block)

       2:   Rake::Task.define_task(*args, &block)

       3: end

       4:  

       5: foo :bar do

       6:   puts "this is coming from the task called :bar, which is a foo task"

       7: end

       8:  

       9: task :default => [:bar]

Lines 1 through 3 show how simple it actually is to define a rake task. Obviously I haven’t done anything useful with this task, but it illustrates the point. The call to Rake::Task.define_task on line 2 is where the real magic happens. Well, ok… there’s nothing magical about this… at all. I’ve defined a method on line 1 and I’ve called that method on line 5. the name :bar is passed into the *args parameter and the do … end block is passed into the &block parameter. Both of those are then passed into the define_task method. Running rake on this rakefile produces the simple message that you see in the puts statements on line 6.

A Useful Rake Task

At this point, any valid ruby code you want can be used to define a rake task. You only need to provide a minimum of a name to the define_task method and you’re good to go. The code block to define the method body is optional and can be provided by any code that you want. You can also take different parameters than the define_task needs, as long as you provide what define_task needs when it needs it.

For example, you could easily create a very simple task to copy files, like this:

       1: def copy(name, src, dest, *args)

       2:   args || args = []

       3:   args.insert 0, name

       4:   

       5:   body = proc {

       6:     FileList[src].each do |f|

       7:       puts "Copying #{f} To #{dest}"

       8:       FileUtils.cp f, dest

       9:     end

      10:   }

      11:   Rake::Task.define_task(*args, &body)

      12: end

      13:  

      14: copy :copysomefiles, "*.rb", "/temp/"

      15:  

      16: task :default => [:copysomefiles]

Line 11 will copy all of the .rb files from the current folder into the temp folder on the root of your drive… more importantly, though, it is a first class citizen in the rake task list, giving you all the capabilities of task depdenencies, parameterized tasks, etc.

       1: copy :copyoutput => [:initialize, :build, :test], "**/*.rb", "/myproject/"

       2:  

       3: task :default => :copyoutput

This simple snippet sets up a :copyoutput task with 3 dependencies and then sets up the default task to run it.

Cleaning Up

I’m glad I found this… it is going to greatly simplify the things I have been doing to create rake tasks – especially when it comes to Albacore. The code that I have in Albacore’s create_task method is pretty ugly, involves inheritance and a few other hacks that I’m not so fond of. The worst of it, though, is that it’s very difficult to change because it’s hard to see what’s really happening. Simplifying things down into small methods that call Rake::Task.define_task should greatly improve the infrastructure of Albacore, though.

I hope this information is useful for others, as well. If even one person has that “aha!” moment and realizes how easy it is to create your own rake tasks, than this blog post has done it’s job. :)

Why Is Git Trying To Delete My Project Folder?!

derick.bailey — Thu, 22 Jul 2010 15:38:05 GMT

NO! I do NOT want you do delete my project… what’s going on here? why is git trying to delete my project folder?

Albacore v0.2.0 Preview 1 Is Available

derick.bailey — Wed, 14 Jul 2010 21:17:15 GMT

A few days ago I pushed a preview version of Albacore up to RubyGems. The intention of doing a preview release was to show everyone the new direction that Albacore is heading and to get feedback from the community on that direction. Things are far from complete in this preview… there is a lot of work that I still want to pack in before the final release of v0.2.0… but there’s already enough change that has occurred, that I think it is time to start getting feedback and making improvements based on that.

Installing The Preview

This is all you need to install the preview version:

        1: gem install albacore --pre

       1: require 'rubygems'

       2: gem 'albacore', '=v0.2.0.preview1'

       3: require 'albacore'

The second line tells the gem system to use the specific version of Albacore that you want, when the Albacore gem is required.

With all that being said, here’s what you can expect from the preview…

Reduced Syntax For Several Attributes

Many of the tasks that Albacore includes are what we call ‘command line tasks’ – these are tasks that call out to a command line tool. In previous releases, all of these tasks had their command line executable (or script or whatever) set through an attribute called ‘.path_to_command’. This lengthy name is hard to type and hard to remember if you don’t use it on a regular basis. With that in mind, we reduced the attribute to ‘.command’. For example:

       1: nunit :test do |nunit|

       2:   nunit.command = "tools/nunit/nunit-console.exe"

       3:   # other settings here

       4: end

A few other tasks have had similar overhauls to specific attributes. the Unzip task, for example, has attributes renamed to ‘.file’ and ‘.destination’ to represent the zip file you want to unzip and where you want the contents sent. These changes should simplify your tasks a little and make them easier to read.

A Few New Tasks

In addition to the CSC task that I’ve already mentioned on this blog, there is also a new SpecflowReport task that let’s you run reports from specflow.

       1: specflowreport :specflow do |sfr|

       2:   sfr.command = "path/to/specflow.exe"

       3:   sfr.projects "path/to/something.csproj"

       4:   sfr.reports "nunitexecutionreport"

       5:   sfr.options "/out:specs.html"

       6: end

Default To .NET 4 For MSBuild And CSC

FINALLY!!!!

I do have to apologize to the community of Albacore users for taking so long to get this done. I should have done it in a previous release, but I kept tell myself “no no… I’ll get v0.2.0 out the door soon…” … sorry about that. At long last, though, you no longer have to do any hard coded paths to make it work with .NET 4.

Not using .NET 4? Don’t worry! v0.2.0 will make your life easier, still! You can easily change framework versions with one simple statement in your task definition:

       1: msbuild :build do |msb|

       2:   msb.use :net35

       3:   # other configuration here

       4: end

The .use(version) method is now available on the MSBuild and CSC tasks and let’s you specify which version of .NET you want to use when calling out to the command line. Here’s the current list of supported versions:

:net2 or :net20 for v2.0.50727
:net35 for v3.5
:net4 or :net40 for v4.0.30319

Need another version? Drop us a line or submit a patch and we’ll get it added. (I know that this isn’t anywhere near the complete list. This is what I have on my machine, right now.)

A New Configuration System

This is one of the things I’m most excited about and hopefully something that will make your life even easier, with Albacore. There is a new configuration system that let’s you configure defaults for any attribute of any task in one simple place. Always using .Net 3.5 with MSBuild and don’t want to specify it in every msbuild task? no problem… Always want to use the same .command or .options with nunit? No problem… want to set the .log_level for every task? no problem…

       1: Albacore.configure do |config|

       2:   config.log_level = :verbose

       3:   config.msbuild.use :net35

       4:   config.nunit do |nunit|

       5:     nunit.command = "path/to/nunit-console.exe"

       6:     nunit.options "/noshadow"

       7:   end

       8:   # additional task configuration here

       9: end

This Albacore.configure method can be called at the top of your rakefile and it will set the specified attributes for the specified tasks, on every instance of that task, to this default. Of course, you can still override any individual setting within any individual task definition.

In addition to the .configure method, this release of Albacore also makes it easy to configure any specific task through code, using a hash.

       1: msbuild_settings = {

       2:   :properties => {:configuration => :release},

       3:   :targets => [:clean, :build]

       4: }

       5:  

       6: msbuild do |msb|

       7:   msb.update_attributes msbuild_settings

       8: end

Now you can set virtually any attribute of any task through code, outside of the task definition. You only need to provide a hash to the .update_attributes method on the task object.

A Better Internal Structure

I don’t want to bore everyone with a lot of detail here, but it is worth mentioning. Many of the individual modules that have previously been used in Albcore task objects have been consolidated into a single ‘AlbacoreModel’ module. In addition, many other changes have gone into the other modules to help clean them up, significantly. This is important not just for the current developers of Albacore, but also for the future developers and contributors. It will make life easier and allow others to extend Albacore with less trouble.

A Few Tasks Have Been Killed

This is probably going to be the most controversial thing that I’ve done in Albacore…

After a lot of thought and consideration about the focus of Albacore should be, I came to the conclusion that I want to help build the best set of build related tools for the .NET workd, running in Ruby / Rake. What this means is that I don’t think Albacore should be in the business of deployment. There are some tremendous deploy related gems already available and I want to encourage the use of those instead of having half-baked, 2nd class deployment capabilities built into Albacore.

In addition to this, I also realized that there are a few tasks that just don’t add any value. They are either duplicating functionality from somewhere else, or muddying the functionality that was intended.

With all that being said, here are the tasks that have been killed, and why:

rename: provides no value. just use ‘FileUtils.mv’ in a regular task. you get more options and better support from the ruby community with the FileUtils module
ssh: deploy related, which is not albacore's "core". albacore is a build related framework, not deployment. suggest users switch to capistrano and webistrano if the want ssh stuff.
sftp: same as ssh
expandtemplates: while this is (mostly) functional and does provide some value, it's a hack that i put together because i wasn't aware of the existing templating solutions out there. ERB is built into to ruby and there are so many more available if people want them. I would suggest a switch to ERB or one of the other template systems if you need a templating solution.
plink: I was on the fence about deleting this one, since it is a command line tool for a specific tool (PuTTY). However, I decided to kill it because it is ultimate a deploy related tool – an SSH client.

Now, just because these have been officially removed from Albacore, doesn’t mean you are out of luck if you are using them… at least, not long-term. Check out the “what to expect in the future” to see how you’ll be able to revive these tasks (if you so desire) in the near future.

And Much Much More

There’s a lot more that has happened than this list can show – many miniscule details to give Albacore a much more solid feel to it. For a complete list of what has changed, check out the “v0.2.0” label on the Github Issues page – specifically look at the “Closed” tags to see what has been done (though the list of closed issues will continue to grow, while the preview 1 release will not change. I may release another preview as progress is made).

What To Expect In The Future

One of the things I want to do for the final release (probably really soon, cause I need this…) is create a very simple plug-in architecture to allow end-users of Albacore to add functionality. I want to create a system that is easy to extend and easy to change. I want to allow the system to grow and change with your needs, not just the needs of those who are speaking up on the mailing list or StackOverflow or whatever. If you want to re-add the ExpandTemplates task, if you want to re-add the SSH or SFTP task, or if you want to re-create them or create something new in a meaningful manner that suits your environment’s needs better, I want to make it easy for you.

The work that has gone into, and is still going on in, the refactoring of the internal structure in Albacore is going to facilitate a lot of this. In addition to that, there will be a simple drag-n-drop folder that you can add to any project anywhere on your system, and Albacore will pick up and automatically call ‘require’ on all ruby files in that folder. This code isn’t available, yet… you’ll have to wait for another preview (or maybe the final release if that happens sooner than expected) but it will be there. I need this functionality for myself and I’m sure others will take advantage of it, too.

In addition to the plug-in system, there will be other changes and details on a smaller scale: some additional work will be done on the CSC task; a few more bugs will be fixed; a few other tasks will have more options; and we’ll continue restructuring and fixing up the internal structure of Albacore, too.

As always, if you’re interested in contributing to Albacore in any way, head on over to http://albacorebuild.net and you can find links to the discussion group, source code, wiki, and much more.

I Bought An iPad… And I’m Returning It.

derick.bailey — Wed, 14 Jul 2010 03:24:47 GMT

A while back I posted that I would buy an iPad when I found a very specific type of app for it. Well I found that app thanks to the comments on the blog post and I’ve had my iPad for about 24 hours now. I’ve downloaded apps, and played games. I’ve watched movies from my Netflix account. I’ve checked email, I’ve used IRC and Twitter to communicate with my team while my laptop was going through 20 hours of CheckDisk (no joke on the 20 hours)… and I’m going to return the iPad. It’s not worth $600.

The Good:

The apps are the undeniable killer part of an iPod Touch / iPhone / iPad. Without the apps, it’s hard to say the device is worth anything. Apple has certainly created a culture around the apps and it shows. There are some amazing apps out there and they can do some great things. You can’t deny the quality and quantity of apps that are available.

If your wondering what app I bought to solve my problem previously stated: Air Sketch by Qrayon. It really is a great app and it does provide a solution for the needs I stated. If you are looking for a way to solve your distributed team collaboration needs by replacing a whiteboard with a virtual whiteboard, then an iPad and Air Sketch should be on your short of things to try. It really does work.

The hardware is also really nice. It’s solid. It’s easy to handle. It’s intuitive to use the controls on the device. It’s really well made and anyone who owned any Apple device (prior to iPhone 4) can tell you that this is what you expect. I have a Macbook Pro and an older iPod video. Both of these are well made, and I expected nothing less with the iPad. I was not dissapointed. The screen is also nice. Good resolution, great brightness and contrast. It makes the apps look great. The overall performance of the device is really good as well. Overall, it’s just a good piece of hardware.

Netflix streaming is awesome!

The Kindle App is great! … I’ve got a Kindle DX already. The benefit of the iPad is that you get a backlit screen and it’s color.

The Bad:

Everything else… well, ok… what’s left? Not a whole lot, honestly…

No multi-tasking. This one really drives me nuts with the iPad. I know a lot of you don’t care about this and don’t notice it. I believe that’s because you’re used to it with the iPhone (prior to iOS4). There is no iOS4 for iPad… at least not until later this year, which will likely see the announcement of new iPad hardware anyways. Coming from the world of Android, though, I do notice this. I can’t stand the single-task nature of the iPad. I had my IRC set up for work while my laptop was on the fritz, but I had to constantly re-open the app every time i wanted to know what was going on with my team. Forget that… I paid $5 for Android IRC on my Droid and turned on background notifications so I could receive messages even while running Skype Mobile. Yes, I do use multi-tasking on my Droid… just about every day. Why can’t I get IRC notices, twitter updates, play Pandora radio in the background and track my movement via GPS all at once? Oh wait, I can. My Droid does this for me every time I go out jogging or bike riding. :)

Yes, Netflix streaming is awesome… but i’m not going to spend $ every month on a 3G connection for this… i didn’t even buy the 3G iPad. I bought the wifi version. Sure, I could tether the iPad to my phone when I’m on the go, but what’s the point of that? I’ll bring my laptop, tether that, and have so much more. If i’m at home, I’m going to watch netflix on my PS3 (in much higher resolution than the iPad) or on my Laptop (again, much higher resolution)… so yeah… netflix is awesome if you’re on the go and have 3G or a tether… no thanks. not worth the $.

Yes, the kindle app is great! it really is… but I don’t care about backlight or color that much. I don’t read in dark places, and I have yet to need color on the device when I can open my PC and read / see the color version of what I’m reading. I’ll keep my Kindle. I love that device.

The Verdict: Not For me.

I have a Motorola Droid for my phone, and quite honestly it fits my life and my needs better than the iPad does. The things that I love about the iPad i also love about the Droid. Sure, the apps are not as numerous and it’s hard to find the same quality at times… but I don’t use that many apps… I’m not a casual gaming addict… I have a handful of games and I play them on occasion, but it’s not that big of a deal to have slightly lesser games. The ones I have are great.

I am a social media addict – twitter, facebook, etc. That being the case, I want a device that will keep me up to date when I’m on the go without me having to manually check in on things. My Droid gives me that. The background checking and multi-tasking capabilities of Android are what I need… and if I already have that fix being filled, why would I need another device that can’t fit in my pocket or give me that fix?

The iPad is a multi-media and entertainment powerhouse, and this device does not fit into my life. It is not worth the $ I spent and I want my $ back. I’d much rather have a new road bicycle to help me continue getting back into shape – something I’ll use for years to come – than a first generation multi-media buzz-worthy hunk of technology that will be outdated in 6 months or less.

The iPad solved the problem that I originally stated. No really… it did… but at a price that isn’t worth it, in my opinion. I expected to be wow’d on many fronts and I was wow’s on some of them. I expected a lot from the iPad, and I was given a little. I expected it to replace my netbook that the wife carries around the house … it probably could, except she uses it to play facebook games… *ahem* Flash, anyone? I expected the iPad to fill a void in my digital life and ultimately, it only reminded me why I bought a Droid and a Kindle – both of which fit my digital life perfectly.

Bye bye iPad. I wish I hadn’t spent the $ on you and I hope I can get a full refund from Apple.

Easy To Read != Easy To Understand

derick.bailey — Mon, 28 Jun 2010 20:11:30 GMT

I ran into this code a while back:

        1: public abstract class ScanPrefixSpecification : IScanSpecification

       2: {

       3:     public abstract IEnumerable<string> BarcodePrefixesFilter { get; }

       4:     

       5:     public bool IsSatisfiedBy(string item)

       6:     {

       7:         return BarcodePrefixesFilter.Where(item.StartsWith).Any();

       8:     }

       9:  

      10:     public string GetScanFrom(string scanString)

      11:     {

      12:         foreach (var prefixFilter in BarcodePrefixesFilter.Where(scanString.StartsWith))

      13:         {

      14:             return scanString.Substring(prefixFilter.Length);

      15:         }

      16:         return "";

      17:     }

      18: }

There isn’t anything wrong with this code from a technical standpoint. It does exactly what it needs to do and it provides a specific point of functionality in our system. By reading the code and by reading the tests around this code, I can see what this class does:

it’s a basic specification pattern where the scanned item satisfies the specification when the “item” starts with any of the strings found in the BarcodePrefixesFilter list
and it removes the first match found in the BarcodePrefixesFilter list from the beginning of the “scanString”; or returns an empty string if no matches were found

Ok, that’s great… now, why does it do that? Where does this code express the needs of the business; the understanding of why those characters need to be removed from the front of the scanned string? How much additional code am I going to have to read to understand the context of this code? How long will it take me to understand what functionality this code facilitates, from a functional view of the system?

… easy to read is not the same as easy to understand. Be sure your code is understandable, not just readable; and the only way to do that is for someone else to look at your code and work with it.

I’ll Buy An iPad When …

derick.bailey — Tue, 22 Jun 2010 03:06:31 GMT

no, really… I’m actually interested in buying an iPad… but under very specific circumstances. Here’s the app that I want, that would make me shell out $500 for an iPad: a remote whiteboard app that transmits my drawing on the iPad over to my computer so that I can have a virtual whiteboard shared with my coworkers across the internet. It’s entirely a collaboration problem that I’m trying to solve. I want to grab my coworkers and walk over to a whiteboard… except we’re all thousands of miles from each other so that doesn’t really work.

Give me an iPad app that turns the iPad into a whiteboard and sends the drawing over to a whiteboard app on my PC (Windows 7, by the way… though I also run OSX on occasion).

I don’t want to use a shared whiteboard via a website… I’ve already got a Wacom art tablet… these are not good enough solutions because there is a disconnect between what I see on the screen and where my hand is drawing. I need to look at what I am drawing as I am drawing it and the iPad seems like it should be the perfect solution to this. It’s either that or a really expensive touch screen monitor, which I don’t have room for on my desk.

I don’t think a remote desktop client solves the problem, either. When I remote desktop into my box, it locks me out of the physical box so that the remote client is in control. I need a whiteboard app that keeps me up and running and just does whiteboard stuff from the ipad to the pc.

Does this app exist? If not, who wants to write it for me? :)

Work In Process (WIP) Limits, Policies, Etc.

derick.bailey — Mon, 14 Jun 2010 18:49:24 GMT

I had a great discussion a few of my team members this morning. We were discussion work in process (WIP) limits, policies, and other items that are related to both of those. By the end of the discussion we had some great policies outlined for how we wanted to handle WIP limits, moving forward. The following represents the notes on the various policies that I wrote up based on the conversions. Before I get into the detail of what we are starting with for our policies, though, I wanted to talk about policies briefly

A Few Notes On Policies

Policies give us a basic framework for deciding what we are going to do, when. They give us guidance on how we should approach our work, from various perspectives. They are not, however, prescriptive "you must do this or you will face the wrath of Larry" rules and they do not give us all answers for all scenarios and circumstances. Software development is a human process, first and foremost. It requires interaction, communication, and judgment calls between humans for the benefit of humans, with the goal of getting things done quickly and effectively. you will run into scenarios that are not covered under the current policies. use your best judgment in those scenarios and seek the advice of others if you are not sure what to do.

Not every repeated scenario needs a policy. There are times when the repeated presence of a scenario should be an indication that our policies need to change to account for this, and there are times when that repeated occurrence should be a signal that we have a problem in our processes and we need to fix our processes.

Policy: WIP Limits

The purpose of WIP limits is not to be a hard and fast rule or mechanical thing that prevents us from getting work done. The purpose is to facilitate getting things completed and out the door. A WIP limit is a policy, and like all policies there are exceptions and there is always the possibility of the WIP limit changing based on empirical evidence that suggests a need for change. A WIP limit is also not a comfort zone that we live within, but should be viewed as a goal that will expose problems in our process and help us to improve. Setting a WIP limit for any given column does not mean that you absolutely cannot put another ticket into that column. Rather, it means that when the WIP limit is exceeded, we as a whole team have to take on the responsibility of understanding why the WIP limit has been exceeded so that we can work to correct that situation now and prevent it from happening again.

When a given step is running up against it's WIP limit, it is our responsibility as a team to help move things forward. This means looking at the downstream steps to see if we need to get other work downstream completed so that we can make room for work that needs to be moved forward. However, don't look at WIP limits as a "you must not exceed this". Look at them as "what percentage of time are we staying under these limits? how can we improve that %?". When we start seeing WIP limits that are being met 80% or more, it may be time for us to consider reducing the WIP limit to expose the next set of problems in our process, facilitating further improvement.

I don’t expect our WIP limits to stay what we have currently defined them as for very long. After all, if our WIP limits are static, then we’re doing something wrong.

Policy: Protecting WIP

We should strive to complete work that has been started, before starting new work. this means a developer that is finished with their current work should seek to help others finish work in process before starting new work. if no other team member needs assistance, or if the time for the person needing work to come up to speed is more than the team can spend right now, then the person needing work should look for the next highest priority work to start. this also means that you should be looking downstream at steps in the process where WIP limits are being run into, to see if you can help alleviate any potential bottlenecks. If QA is getting backed up, take the time to see if you can help get some tickets tested and pushed through before starting a new ticket.

Policy: Emergency Fixes

We use VersionOne as our project management took, currently. Since we can’t model a horizontal swim-lane in V1, we will create an "Emergency Fixes" priority. This priority would be reserved for exactly what it sounds like: things that are truly emergencies. Emergency fixes mean that the developer who is working on them will drop whatever they are doing and get it fixed, now. All other work, for as many resources as are needed to complete the emergency fix, is put on hold until this thing is fixed. this includes developers, QA, product owners, etc. Emergency fixes are a primary exception to WIP limits and these fixes should be pushed through the system as quickly as possible, regardless of any WIP limits being exceeded.

Emergency fixes should also be a sign that we as a team need to step back and understand why the problem was allowed to be pushed into production in the first place. We should use this time and effort to find the root cause of the problem and see what we can do to not only prevent the problem from recurring, but also prevent similar problems from slipping through our fingers in the future.

We had a good example of an emergency fix from an IRC chat today:

Boss: hey [dev], [product owner] logged a backlog, problems with [feature] not working in IE7
Dev: oooh fun
Dev: so should issues like this trump the WIP limits we're trying to do ?
Boss: In this case, yeah. We released it, told them about it, and they just told us they can't use it.

I get the feeling that we will eventually be using many different of Classes of Service… but this is a great place for us to start.

Policy: Failed Acceptance Tests (ATs)

When an acceptance test is failed, the person doing the testing should move the ticket back to In Progress and notify the developer(s) that worked on it. both the person that worked on the ticket originally and the person that tested the ticket are responsible for ensuring the ticket is fixed and moved forward again. if a failed AT is going to prevent a release from happening on time, this needs to be brought up with the product owners immediately.

a failed AT may cause WIP limits to be exceeded. this is intentional, but not something to be ignored. a WIP limit being exceeded by a ticket with a failed AT should kick the team into problem solving mode. we should use this opportunity to find the problems in our processes and improve.

Policy: Create ATs Column

Our QA lead brought up the subject of tickets being in-progress vs. waiting for acceptance tests to be created. Based on her input and discussion with the others in the call, we think it would be good to have a column called "Creating ATs". The purpose of this column is not to say that we should wait until the work is done to create the ATs. Rather, it is there to facilitate the needs of our QA person considering our limited QA personnel. We often run into situations where a developer picks up work and completes it before she is aware of the work being started. this column will give us a place to recognize that situation and gives use better insight into the real status of a ticket.

Ideally, we should be working with QA to define the ATs before work is started. Given the number of developers compared to only 1 QA person, though, this is not always going to happen. The presence of tickets in the Creating ATs column should be another sign that our team uses to help us improve. It may be evidence for the need to hire more QA people, or the need for the developers to communicate with QA more frequently, etc.

Policy: Long Running Tasks

there are times when we are working on tasks that must be extended over long periods while waiting for input or data from external resources. for example, one of our developers is working on a data migration process for one of our customers. this process takes an extensive amount of time and cannot be run during normal business hours. He works through this process on the weekends and completes a little more of it every weekend. this type of activity will be put into VersionOne as an Epic and have individual stories split out to represent the work that is going to be done for the given increment, whether that increment is time based (on the weekends in this example) or feedback based (waiting for feedback from a customer on a given change). this will let us get the individual increments of work done and moved through the system, while letting us plan for the additional work by creating another ticket in the Epic / backlog.

One Final Note On Policies

All of this is open for discussion, clarification and modification by the team. These are policies designed to help us recognize the next set of problems in our current development process. As we continue to move forward, our needs as a team will change. When this happens, our policies will also change. We are not trying to define “the way” we develop and release software. We are trying to define what our current needs and goals are, with the intention of improving our processes as we move forward.

Git: Oops. I Forgot To Add Those New Files Before Committing

derick.bailey — Wed, 09 Jun 2010 21:05:43 GMT

I do this pretty regularly… working away, adding files, finish something up and commit. Only after I commit do I realize that I forgot to add the new files to git.

This always frustrated me with subversion because it meant I would have to make yet another commit and put in some silly commit message like “forgot to add these files to the previous commit” and I would often repeat the same commit message as the previous commit along with the note about forgotten files. Anyone that needed to merge my changes anywhere would have to some how know that they need to read the commit messages and figure out that this second commit was supposed to be part of the first commit, so they have to bring it along for the merge.

Git Commit --amend To The Rescue!

With git, you can solve this problem easily without having to create another commit in the repository and without having to re-type any of your commit messages. Stage the file that you forgot then when you do your commit, provide the “--amend” and “-C” options.

        1: git commit --amend –C HEAD

The --amend option tells git that you want to add these changes to the previous commit… that you want to amend the previous commit with these changes.

The –C option (or –c option… slightly different semantics, but generally the same) requires you to specify what previous commit’s message you want to reuse. If you don’t provide the –C or –c option, your commit message editor will come up and will contain the commit message from the HEAD commit allowing you to modify the message if you want. Alternatively, you can still provide a –m “message” and this new message will be used.

and you can see in gitk that there is only one commit with that message, but the menu.html file that I previously forgot is there

Note that --amend will change the SHA1 ID of the commit… you can see in the original screen shot at the top that the commit was ID 8bbad12 and in the second screenshot and the gitk screen shot, the ID is now 35af25e. If you need to preserve the SHA ID of the previous commit, this is probably not the best option for you. But if you don’t need to preserve it, this can save your coworkers the headache of having to look through a bunch of “forgot to add the files” commits.

Git: D’oh! I Meant To Create A New Branch First!

derick.bailey — Tue, 08 Jun 2010 14:59:43 GMT

Yesterday I ran into a situation with git where I was working away on some code, finished what I was doing and committed the changes. Immediately after making the commit, I realized that I was still sitting in my master branch instead and had made the commits there instead of on a topic branch like I meant to.

If I were using subversion, at this point I would create a branch from the head of where I committed and then revert the original commits. The subversion history would show that I made the mistake and anyone that pulled changes from the original location would get the commits applied and then rolled back.

Git makes this situation trivial, and no one will ever have to know that you accidentally made a commit to the wrong branch, first. :)

Git Reset To The Rescue!

The first thing you want to do is snap off a new branch, just like you would in subversion. I normally like to use the ‘checkout’ shortcut to create the branch and switch to the branch at the same time:

        1: git checkout -b mytopicbranch

but in this case, I don’t actually want to checkout the branch yet, so I’m just going to create a branch without switching to it:

       1: git branch mytopicbranch

At this point, both mytopicbranch and master are pointing to the same location.

What we really want, though, is for master to still be back at “initial commit” and mytopicbranch to contain the two commits that were made after that. To do this, we need to know the sha fingerprint of the commit we want (which we can see in the above image) and we need to use the ‘git reset’ command. The great thing about reset is that is doesn’t do anything to the contents of the repository like a revert would do. Rather, the reset command just moves the branch pointer (the HEAD of the branch) to the commit that you specify.

Run this command:

       1: git reset 2f7efb32 --hard

and you will see git move the HEAD of the master branch to that commit:

Now when we look at the repository again, we see master where we want it and we see mytopicbranch where it should be, as well!

No changes were made to the content of the repository. We only moved the HEAD pointer for the master branch around and made it look like we actually created our branch before making those other two commits. :)

Albacore Feature Preview: Building C# Code With CSC.exe

derick.bailey — Tue, 01 Jun 2010 12:00:00 GMT

I’ve been meaning to do this for a very long time… it’s been asked for multiple times and it’s been on my list of things to do for a very long time… but it’s finally happening! I’m finally putting a ‘csc’ task into albacore so that you can build your c# code directly from the c-sharp compiler (csc.exe).

A Simple Example

Here’s a small sample of what a rakefile might look like, using the csc task:

        1: csc :build do |csc|

       2:   csc.command = "csc.exe"

       3:   csc.compile FileList["src/**/*.cs"].exclude("src/**/*Specs.cs")

       4:   csc.output = "myproject.dll"

       5:   csc.target = :library

       6: end

       7:  

       8: csc :build_tests => [:build] do |csc|

       9:   csc.command = "csc.exe"

      10:   csc.compile FileList["src/**/*Specs.cs"]

      11:   csc.output = "myproject.specs.dll"

      12:   csc.target = :library

      13:   csc.references "myproject.dll", "nunit.framework.dll"

      14: end

      15:  

      16: nunit :test => [:build_tests] do |nunit|

      17:   nunit.command = "nunit-console.exe"

      18:   nunit.assemblies "myproject.specs.dll"

      19: end

there are three tasks here: build, build_tests, and test.

the build task will build all .cs files that do not end with “Specs.cs” and will produce a dll called “myproject.dll”
the build_tests task will build all of the unit tests by compiling al files that end with “Specs.cs”, referencing the “myproject.dll” as well as “nunit.framework.dll” and producing a file called “myproject.specs.dll”
and the test task will run the tests that are found in “myproject.specs.dll”

It’s a fairly simple script but that’s the point. By using a FileList to specify what files should be included / excluded from compilation, you can use naming conventions to determine what will or won’t be built into any given assembly. This means there is no need to have separate “tests” folder or project. You can have your tests living in files right next to the things that are being tested. With proper naming conventions being followed (whatever conventions your team wants to use), you don’t have to worry about your tests being built into your production code.

A Work In Progress

This is still a work in progress and not an official announcement of the csc task’s availability. The example above shows almost everything that the csc task is currently capable of… and as you can see, it doesn’t have a lot of the csc command line features built into it, yet. If you’d like to help add features and functionality, the task is currently being built in the dev branch of the albacore repository.

If you’d like to follow the progress of the csc task without wading through all the other work going on in the dev branch, I’ve started a small project over on github, called vimbacore. This is my personal playground for trying out two things: c# coding in vim (not just using vim from visual studio… but, only using vim), and the csc task in albacore. If you would like to see the evolution of the csc task in albacore, you can watch this project. I’m going to try and keep it up to date with new features and functionality related to the csc task and use this example project as a means of determining what features and functionality the csc task needs.

new ThoughtStream("Derick Bailey");

Design And Testability

Design And Testability In Ruby

Design And Testability In C#

Angels And Demons

What’s The Point?

Searching …

Knowing when to ask

I’m mapping individual trees, not surveying the forest

Lose the ego and the pride

“Bring out yer dead!” *clang*

A Troubled Future For The DLR And IronRuby

“I’m Not Dead Yet”

Do Something About It

Albacore v0.2.0 Preview 2 Is Available

Installing The Preview

A Refocus (Again)

Albacore Task Updates

CSC Task

SQLCmd Task

AssemblyInfo Task

Internal Cleanup And A Plug-In System

Custom Tasks

Custom Task Names

Custom Configuration

Automatic Configuration Mixins

Moving Forward…

Vendor Lock-In Vs. Best Of Breed Tools

How To Build Custom Rake Tasks; The Right Way

A Simple Rake Task

A Useful Rake Task

Cleaning Up

Why Is Git Trying To Delete My Project Folder?!

Albacore v0.2.0 Preview 1 Is Available

Installing The Preview

Reduced Syntax For Several Attributes

A Few New Tasks

Default To .NET 4 For MSBuild And CSC

A New Configuration System

A Better Internal Structure

A Few Tasks Have Been Killed

And Much Much More

What To Expect In The Future

I Bought An iPad… And I’m Returning It.

The Good:

The Bad:

The Verdict: Not For me.

Easy To Read != Easy To Understand

I’ll Buy An iPad When …

Work In Process (WIP) Limits, Policies, Etc.

A Few Notes On Policies

Policy: WIP Limits

Policy: Protecting WIP

Policy: Emergency Fixes

Policy: Failed Acceptance Tests (ATs)

Policy: Create ATs Column

Policy: Long Running Tasks

One Final Note On Policies

Git: Oops. I Forgot To Add Those New Files Before Committing

Git Commit --amend To The Rescue!

Git: D’oh! I Meant To Create A New Branch First!

Git Reset To The Rescue!

Albacore Feature Preview: Building C# Code With CSC.exe

A Simple Example

A Work In Progress

“Bring out yer dead!” clang