I just spent almost the whole of 2009 working at a client’s site. I had a year in which I had a few large shifts in how I view “collaboration”. Some of this was fostered by fitting in to a different role. Some of this was because I’d previously spent several years working essentially solo. Some of it came from talking with coworkers about the philosophies of workspaces.

Regardless, I spent almost year away from my desk and only recently came back on January 3rd. I was looking forward to reorganizing it. Move the mini fridge. Put the laptop against the back wall. Clean out some six year old notepads from old projects.

Before I even got to lunch ony first day back, my new team lead took my attention in two directions. I hit the ground running with some wpf prototyping and I was told I’d be moving to a different desk in the building in a few weeks.

With the pending move it was hard to convince myself to unpack my box and move back into my desk. However, every interaction I’ve had with my team (although, honestly just the team-lead so far) has reinforced why I wanted to rearrange my desk in the first place.

True story. And a metaphor. Technical debt has been on my mind recently, since it was the IndyAlt.NET topic this past month. The most useful definition of technical debt for me is simple, Technical debt is the resistance of your codebase to change. What does this have to do with my desk?

After spending time with another desk (after working on a different code-base), I returned to my old desk (I came back to a brownfield application) with ideas about layout that would make it easier to work (with changes to the architecture that would make it easier to change), but I was hesitant and missed an opportunity to realize value because I was distracted by the pending move (the pending rewrite).

The sooner you make it right, the sooner you start to get value from that change. The longer you put if off, the less likely you will be able to recoupe the effort of the change, but the more you pay to work around it.

Continuation Passing Style is a functional pattern where all work that can’t be passed into a tail recursive function call is passed in as an additional argument via a closure or anonymous function, delaying execution.

What got me confused for years on this was the explanation, almost like a mantra, “A continuation is like a callback.” I don’t use callbacks much and I believe that phrase is actually expressing a different pattern, simple first-class functions. So what do I think a continuation is? It is a promise to get to it later, after a tail call. I do agree with the literature that it turns the function inside out. And Don Syme’s reasoning that you’re trading heap to avoid spending stack.

I know you hate fibonacci, but it’s simple to explain. Here it is in all it’s glory.

You note, however, that since the results of two recursive calls need to be stored, we can’t dump the stackframe and tail optimize the call, right? We could pass around two accumulators, essentially mimicking the imperative for-loop solution to the problem

This works because the Fibonacci sequence is just that, a sequence. It can also be represented by a tree, and that’s what’s causing it to be a problem for recursion in the first place. We are still left with, “How do I process a tree without risking a blown stack?” That’s what Continuation Passing hopes to solve by using a continuation (read: anonymous function) that wraps our core functionality in a heap object so we don’t call down one leve. I’m not making this clear, so I’ll show this in pictures.

Step One: We're abstracting the problem to it's simplest form

Step Two: We're making a promise to do something later

Step Three: We're expanding the first abstraction

Step Four: We're expanding the second abstraction

Step Five: Fill in the base-cases for both our promise, and the function.

And now for the punchline. Why do I care? This goes back to the spreadsheet challenge I talked about earlier. I was evaluating my abstract tree and noticed a lot of code that looked like: | Sum(a,b) -> eval a + eval b and I knew it wasn’t going to scale past my toy problem. I had a few tests, so I branched it with Git and tried replacing it with a tail recursive version. I know a spreadsheet doesn’t need that, but it really didn’t add any complexity once I figured out what it was actually doing. Just thought I’d share.

I’ve been thinking about IronRuby and WPF and this means I’ve been seeing some differences between how a staticly typed language like C# builds APIs and dynamic languages. It basically boils down to the use of primitive types at the perimeter.

Let’s look at a simple C# API

   public MyDoc GetDocFromUrl(Url address){
      // do stuff here
   }
   public static void Main(String[] args){
      GetDocFromUrl(new Url("http://some.site/some.doc"));
   }

And now the Ruby version

  def get_doc_from_url(url)
     # do stuff
  end
  get_doc_from_url("http://some.site/some.doc")

what’s the difference? In the C# version, you need to insert a url. In the ruby version, you need to pass in a string.

The first time I realized this was working with WPF trying to get a picture to update. The Xaml code had an attribute Source="blah.png" but the C# code to change this after the fact was horrific. Starting , I need to call System.Windows.Interop.Imaging.CreateBitmapSourceFromHBitmap(...). Why was that my job? For those playing at home, this is why extension methods exist. The code to do all that junk has a spiritual home on the WPF control, not in my application.

        private static void ShowFile(string FileName)
        {
            var win = new Window();
            var stack = new System.Windows.Controls.StackPanel();
            var bmp = new System.Drawing.Bitmap(fileName);
            var img = System.Windows.Controls.Image();
            img.Source = System.Windows.Interop.Imaging.CreateBitmap.SourceFromHBitmap(
               bmp.GetHbitmap(),
               IntPtr.Zero,
               Int32Rect.Empty,
               System.Windows.Media.Imaging.BitmapSizeOptions.FromEmptyOptions());
            img.Stretch = System.Windows.Media.Stretch.None;
            win.Content = img;
            win.SizeToContent = SizeToContent.WidthAndHeight;
            win.ShowDialog();
        }

When I started writing this post, I was going to make a point about static vs dynamic languages. After chatting with Jon Fuller one night and chewing it over for a few days, I think the typing is a red herring. He mentioned that the rails source code seems to have a certain layer structure. The public facing APIs take the primitive types and then convert them to internal representations. You can do this in C#. So, why not?

WPF, for example, has to serve many masters. Let’s start by thinking about where you can get the images for your WPF application.

• Files
• Filtered Files
• Generated
• Taken from the web
• Taken from gopher

I see a pattern. The API would have a large number of transformers from all the possible sources, so instead of supplying any, they supply none. From the point of view of the API developer this is less work and easy, but in they eyes of the application developer, this bleeds your API concerns into the application. It fuzzes the layer boundary. To be blunt, Earlier this week I tweeted comparing this style of APIs to a sea-cucumber spewing its guts into the surrounding water.

A better metaphor is the realization that software contains estuaries, places where the fresh water of your application mixes with the marine conditions of the APIs and frameworks you use. Seawater kills freshwater animals, and very few organisms thrive in the swirling mix. The difference is where the estuaries are contained. In Ruby APIs, we tend to keep the estuary behind the API letting the API provider manage the conversion from one type to the other. In C# APIs, we see the estuary on the application side. The thing to be aware of with the application biased estuaries is that they tend to reach farther up stream than you may realize. Abstraction layers and extensions on the API can help manage the mix of waters. Be ecologically minded, save the programming environment and code green!

Just some background on how I got the the problem I’ll be discussing. Recently, the twitters where talking about the Spolskey / Martin feud over TDD and whether or not it can be useful for every class of problem. In addition there’s been a lot of talk about Katas as a form of practice. This lead me to a 2002 article by William Wake describing a test-first spreadsheet. And, Michael Feathers is writing Vi in Haskell.

So, I started the test first spreadsheet challenge in C# because it’s super easy to work in a language you know. For the record, I completed the engine but not the application. Part of the problem is building an expression parser to evaluate formulas. While I’m not proud of what I wrote, my parser works and passes all the tests. The parser is a horrible hack that has no place in polite society and I’m not sure it should be called a parser. I blindly implemented the worst thing that could possibly work. It does have a clever little pivot to control operator precedence, but it’s ugly. That was intentional as part of this exercise was to explore the Sudoku issue from the TDD dust-up (TDD can(‘t) be used for mathematically important solutions) and see if I can build a parser without paying attention to what defines a parser in my opinion of the eyes of the rest of the world.

So, that was fun, but I wanted to play with F# since it’s been a while. The spreadsheet challenge would be an interesting experiment for me in Functional programming and TDD. I remember reading about the Haskell vim project and saying, “You can do that?” So, I wanted to find out how. It went fairly smoothly until I hit the parser, then I hit a wall. Almost literally, since it was the “)” that set me back. I was ashamed of myself. I wrote a parser for my FSharp talk that was as complex or more than this. I’m a huge fan of DSLs. Am I going to have to admit that test-first is a failure? No, I just need to look a bit deeper and discover what I think of test first.

But I did it in C#, why? In C#, I scattered information about the state of the parser all over my classes. It was easy to bang your way out of a corner if you can throw state at it. F# also has state, but I was trying to be as stateless as possible, even with a spreadsheet, and I was doing pretty damn good up until this point. I took a hard look at what Test-first means, then I took some time and relearned everything I knew about parsers up until that point.

I’m avoiding terms like BDD, TDD, and Context-Specification because they have very specific meanings to very vocal people from whom I still plan on learning. What do I mean by test-first?

• Try not to write code until you have a need.
• Those needs are expressed as executable tests.
• Your code should only express the needs of the tests.

Test-First agile design gets a bad wrap in some corners as “no-design” when it really is about controlling assumptions. My instincts said I’d need a parser to evaluate the formula, but I stubbornly threw them away. I was thinking about a parser framework like I built up in my FSharp talk. This is way too much and I couldn’t justify it. Assumptions here are: I need a parser framework vs. parsers will fall out. Both assumptions are wrong. A true parser is a small thing that you can test quickly and easily. I needed just enough parser to get the job done. The trick is not to ignore a solved problem, but control scope of the solution.

What is a parser? When reading the Graham Hutton Haskell book that Eric Meijer is using in his lecture series, I found a poem. A parser for a thing / is a function that from a strings / to lists of pairs / of things and strings. I’m not returning a list of things, but still. In a fit of assumption, I changed string to token-stream (I’m not a saint) and I was off. I started with a simple parser, operating on a token stream.

type expression =
  | Empty
  | Number of int
let expression stream =
  match stream with
  | [] -> Empty, stream
  | h::t -> Number( Int32.Parse(h)), t
let evaluate expr =
  match expr with
  | Empty -> failwith "Empty Expression"
  | Number(a) -> a

You’ll notice here that I have to return a tuple, the expression and the remainder of the parser. Since I’m programming in the functional style, I have to carry my state with me constantly. This means my functions start growing arguments, but I’m way more aware of the data I’m actually using. This became much more apparent as I started carrying a set of visited cells to prevent circular references.

The thing that tweaked my mind about it was how I didn’t need all the parser combinators I wrote over a year ago when I was parroting Mark Jason Dominus’ example from Higher-Order Perl. Even this time, trying to write test-first, I have far too much in the final solution. (Not Quite, I spent some of the weekend deleting code, but the point remains; I had code to delete, not refactor).

My final note; I think the test-first style is about controlling assumptions. It is okay to make some assumptions, but the purpose of the tests is to verify and document they are valid in the system you’re designing.

Words have power. For those who practice the Weirding Way (from Dune), this is to be taken for granted. Some agree with the Humpty Dumpty (Through the Looking Class Ch. 6) and a word means exactly what they choose it to mean. But, to counter that point, I offer the following description of my dinner last night; “Proxy Flu quickly house Cabbage’s”. Communication is based on a shared understanding, so let’s share. More correctly, I’m going to share with you what I mean. Then we’ll communicate.

People are still confusing Refactor with Redesign.

As we bound through the local community and the wider internet, it is all too common we hear something like, “We have no time to Refactor, It’s a nice to have, but we can’t”. I have also heard, “We give our team one month a year to refactor and do stuff for us.” I humbly submit, “You’re doing it wrong!” I understand that’s an inflammatory statement. I intend to back up those words, so bear with me through a metaphor.

I’m baking a cake. I was making a five course meal for the in-laws when they suggest that a cake would be nice. I really want to get that cake out and onto their plates, and I want to impress them. I look around the kitchen and realize that I’ve just used my last big bowl making the batter. I need to frost the cake, but I need the big bowl to make the icing. I reach for the nearest bowls I can find, four small bowls of different sizes. Now I have to make several small batches of icing to get the same amount. I have risks. My calculations of the ingredient proportions could be wrong. I can underestimate the size of the bowls. I can combine the ingredients in an inconsistent manner. Worse, it take four times as long to make the icing, because the time it takes to make icing isn’t directly related to the amount you make.

That was one option. Another option is to stop everything and clean all the dishes at once. But I would very literally be starving my in-laws. The last plan is to clean the big bowl and maybe a beater and spatula I could use, but only those that I need. Then, when I’ve finished, I could clean up the dishes I used for the cake. That is Refactoring.

What is implied by the statement, “we don’t have time,” is that they want to stop and clean everything. That is a redesign.

In pondering why the misunderstanding exists, I can only blame myself and other proponents (not really, but I’m making a point about misunderstandings). When talking about Refactoring, we usually start with a complete program and make changes. We don’t have a choice because we want to isolate the Refactoring act for pedagogical reasons. But it tells only half the story. A half that gives the impression this is a post-development effort. In addition, when talking about the power of small steps adding up we mention it’s possible to redesign from a series of Refactorings. But the point to drive home in that situation is lost. The code never stops being developed. We do this to express the notion that if you clean the dishes as you go, you’ll never have to wash all the dishes in the house.

When do we Refactor? At one extreme, the TDD side, you Refactor after every passing test. On the other extreme I should get my feature working, check in, Refactor and check-in again. I don’t wait until the end of the quarter. That is a Redesign, not Refactoring.

Let’s lay down one more time why we Refactor. Our first pass at solving a problem is littered and strewn with a confused jumble of ideas. Refactoring gives us a chance to solidify our abstractions, improve readability, increase reuse, manage dependencies, increase testability, and clarify APIs.

How do you start in an existing project? Clean the code you’re currently using. Not to make it perfect, but to reduce the risks of spaghetti code. If you start with a pile of dirty dishes and clean only what you need, you won’t clean all the dishes, but you will clean the ones you use most often, and they will always be clean when you need them. You didn’t mean to write bad code, you just forgot to wash the dishes.

Mark posted a question about using the MenuItemBy method on White’s MenuBar class from ruby. But there’s a problem. While the examples show C# code being used with two parameters as below, it is a lie. That method uses the params keyword, which means the rest of the CLR sees that as an array. You’re just lucky in C#. The literal translation of the code below to IronRuby will fail. 2 arguments for 1. Because it expects a typed array, not multiple parameters.

  win.MenuBar.MenuItemsBy(SearchCriteria.ByText("Task"), SearchCriteria.ByText("New"))

So, we can just wrap our criteria objects in a ruby array and pass them in? Nope. Not in 0.9, and not without some meta magic. We need a Core.UIItems.Finders.SearchCriteria[], so we’ll get one by detouring through a generic list. Oh! this is a great time to notice that CLR classes use the [] operator to return parameterized instances of themselves, like the C# <type> syntax. Here’s what my cucumber step definition looks like for creating a new task via a menu.

When "I click Task -> New" do
  l = System::Collections::Generic::List[Core::UIItems::Finders::SearchCriteria].new
  l.add(Core::UIItems::Finders::SearchCriteria.by_text("Task"))
  l.add(Core::UIItems::Finders::SearchCriteria.by_text("New"))
  @win.menu_bar.menu_item_by( l.ToArray ).click
end

This works. I admit it ain’t the prettiest, but it is expanded for demonstration purposes. Yeah, that’s it. I’m kinda rushing to get some stuff done (and posting for breakfast), so I’d like to revisit this later and clean it up with metaprogramming. Maybe next month?

I also want to note something. I thought including namespaces was so damn cool, but White and WPF use similar names and I’m not sure ruby’s modules are doing the isolation I want, so I’m avoiding it until I need it. Also something else to look into.

I took a quick look at some WaitN examples this morning to see if there was anything I needed to fear when doing an example of WaitN in IronRuby. Then I saw it. IDisposable. More correctly, a using statement. What would that look like in IronRuby?

module System::IDisposable
  def self.use_these(*disposers, &block)
    block.call(*disposers)
    disposers.each {|d| d.dispose}
  end
  def using(&block)
    block.call(self)
    self.dispose
  end
end

class DisposableHero
  include System::IDisposable
  attr :name
  def initialize(name = "Jed")
    @name = name
  end
  def do_something_to(other)
    puts "#{@name} washes a car for #{other.name}"
  end
  def do_something
    puts "#{@name} doing something"
  end
  def dispose
    puts "#{@name} is being disposed"      
  end
end

DisposableHero.new.using do |d|
  d.do_something
end

System::IDisposable.use_these(DisposableHero.new("Tony"), DisposableHero.new("Ryan")) do |t, r|
  t.do_something_to(r)
end

I added a using method to any IDisposable object that handles scoping. In addition, I added a multi-object disposing use_these block so I don’t have to nest my using blocks. It’s not perfect, but for five minutes of thinking, it’s not too bad.

Do you know how many RBIs have been hit against Cal Ripkin? How many times was a Manning sacked by a running back last year?

To put it a different way, who has the most Oscars for cinematography in a tv series?

I’m pretty sure those questions make no sense. I’m not passing judgment on sports fans, or movie buffs. I choose to spend my time doing other things. This crystallized while I was talking with Ryan. Some people have different information acquisition profiles. A few months back I saw an interview from RailsConf of Tim Ferriss, the author of the four-hour work week. He mentioned he had stopped pro-actively acquiring information because by the he needed it, he’d forgotten it. If we couple this with the acknowledgement that we can’t learn everything, what’s the best way to gain knowledge? The thesis of the interview was “just in time knowledge.”

The Internet, and your local library, make this possible. With a network of friends, it’s not a bad idea. But there is a catch. How do you know if there is something out there to know?

Recently, a coworker asked me about sending data over a modem. I couldn’t help him solve his problem, but I gave him enough to start looking. But in a sea of data, where can I find a library to tell me the frequency of a sound? Which XML library should I use? How do I know to use MVVM or IOC? Where do I start?

I’ll let you figure that out. We started to identify three patterns of acquisition; Infovore, tasker, and opportunist. These patterns depend on a combination of the person and the area of interest.

An infovore collects information for the sake of information. It’s a news hound. It’s a super fan. It’s how I approach programming. It is my hobby, but it might not be yours.

A tasker starts researching around the edges of their task. Think an informed patient. Researching cars when you need a new ride. Looking at testing frameworks when you’re a developer tester.

An opportunist only learns what they need when they need it. I’m so here with car repair. I’ve been known to watch a soccer game on TV, but I have no idea who’s playing this week, or when.

The interesting thing about this is that different people fit different profiles for different topics. A fantasy football player is likely either an infovore or a tasker regarding their team. But most of us are taskers or opportunists when it comes to health insurance.

Let’s look at three RPG players. One spends time on the Wizards boards tweaking min-max builds all weekend. Another looks at the books when it’s time for build a character or level, but still enjoys the game. The last loves hanging out with his friends, but still has to ask (though not as often) what does he roll for that again? Who’s fun is wrong-bad? I can’t tell you that.

I think the interesting part is to realize the categories of interest in our lives and determine what are acquisition profile is in those categories. Then, accordingly, determine if we’re okay with that.

I accidentally agreed to give a talk later this month. The subject is IronRuby and it’s application in the .NET ecosystem. Seems simple enough. So, to jazz things up, I want to have a host of demo applications. This is about one.

A while back, I posted an article with an example of using IronRuby and the White framework. In it, I appear to have made a promise.

I’ll get to Cucumber. I’ll publish examples. I promise.

I’m writing this in response to a recent post I wrote on my website, A Ruby Cast In Steel. While I appreciated the insight my experiments gave me into both IronRuby and WPF, the author ended up with a few conclusions I’d like me to revisit.