Pat Gannon's blog

XP vs Kanban: New Product Development

Pat Gannon — Fri, 09 Jul 2010 02:40:19 GMT

Our Situation

My team and I are currently working on a new line-of-business web application, and we had a discussion today about what the best Agile process would be for our current endeavor. Up until last Friday, we have been practicing Extreme Programming (XP). We generally have week-long iterations, starting on Friday mornings and ending on Thursday evenings (so that end-of-iteration crunch time to meet our iteration commitment doesn’t fall on a Friday evening). Friday mornings we have our stand-up, then our retrospective, and then we plan our next iteration. Last Friday, we decided to try out a Lean/pull process for a week. This morning at our stand-up, I was trying to pick between working on a rather large story that was at the top of our “Ready” queue, which I probably could not have finished by the end of the day, and a smaller story just below that is more manageable for today. If we were to continue using Lean/Pull, having the story half-finished at the end of the day is not such a problem, but if we’re going back to XP and fixed-length iterations, I need to make sure there’s no work-in-progress by EOD. This post is about which process we decided to use and why.

Extreme Programming

An advantage of XP over Kanban is our perception that its easier to convey rough estimates of a batch of work to upper management.

My boss (the CTO) routinely meets with the CEO and COO of our small company and they will discuss a strategic new product, or a fairly large module to be added to an existing product. They will collaboratively write a set of stories, and then on the following Friday, the development team will meet to give a rough estimate to each of those stories (or each of the “must haves” if there are a lot of stories). Once we’ve done that, my boss will divide the sum of estimates by our weekly velocity (the average amount of work we complete per week), then multiply by a risk-factor, to produce an estimate of when that chunk of work will be done, and conveys that back to upper management. The estimate and the scope it represents are not set in stone, and everyone understands that. This still has value to upper management, because they can choose to cancel or defer that chunk of work if its expected value isn’t roughly commensurate with the required effort. Also, it serves as a signal to whether or not they should be brainstorming new strategic products/modules, or whether we’re busy enough that it’s not worth-while for the moment. Additionally, the iteration commitment in XP provides a bit of security in knowing that the work currently under construction will be done by the end of the week, which can be communicated to other stakeholders if asked.

In an ideal world (eg. textbook Agile/XP), we would be able to deliver the most valuable features to production in one iteration, generate some value, and build from there. In the real-world (or in our world in any case), there is often a minimum marketable feature set that must be completed in order for a new application to deliver any value in its business context. In our business, our customers are busy and selective, so if you demonstrate something for them that doesn’t do the core functions that sparked their interest, at best: they’re not going to use it in its current state. At worst: they will lose interest in the new product and decline to dedicate any more attention to it in the future. Another factor that can result in a minimum marketable feature set like this is a marketing push. Given a fixed marketing budget, are you going to spend those valuable dollars running that full-page ad in a trade journal after the product has had just a week of development? I think that would probably be unwise in most situations. All of this is certainly not to say we should return to waterfall and decide the scope up front, then do it ‘til it’s ‘done’, etc., but merely that like most things in life, selecting when to ‘launch’ a new application is a balance. You want to launch with the minimum set of functionality that will actually garner the attention of your intended audience, without doing so much up front that you need to do a ton of re-work after it’s used in production and the users tell you everything that’s wrong with it. The trick is to implement A, B and C (if those are the features that are absolutely critical) without trying to deliver D, E and F (the nice-to-haves) at the same time. The problem is that the effort required to build A, B and C often takes more than one reasonably-sized iteration, in the case of a new application.

To sum up, the fixed length iterations used in XP enable us to deliver valuable timeframe estimates to upper management, and I don’t see a way around that in our business context.

Kanban

Kanban is Japanese for “signboard” or “billboard”. “Kanban is a signaling system to trigger action. As its name suggests, kanban historically uses cards to signal the need for an item.” (Wikipedia) We have actually been using a virtual Kanban board for a little while now, as in it’s simplest usage, it’s effectively similar to the XP-style story board (index cards stuck on a ferrous whiteboard with colored magnets) we were using previously. The process change I referred to previously is that we briefly tried out a pull system, where our stakeholders added and prioritized stories in the “Ready” queue at will, theoretically signaled by our completion of work. We tried this rather than having a fixed-length iteration this week, prompted in part by it being a short week due to the 4th of July holiday recognized on Monday.

What attracted us to a pull-system is the flexibility it gives stakeholders to introduce new cards or prioritize cards in the middle of an iteration. (Both are prohibited in XP: scope is fixed for the current iteration and the order of story implementation is selected by dev team members based on the logical flow of work occurring during the iteration.) The other nice thing about it is that it avails us to interesting approaches (like Value Stream Mapping) for maximizing the throughput of new features. (In other words, minimizing the amount of time it typically takes a story to go from conception to production.) It definitely sounds nice in principal, and seems to have worked out well for Toyota.

The down-side of using Kanban when developing a new application is that there’s no apparent way to do the broad estimates that we currently communicate to upper management. Although you can use your calculated cycle time (the average amount of time it takes a feature to go from conception to production) to estimate when a particular feature will be delivered to production, what about the time required to deliver the minimum marketable set of features? It doesn’t seem possible to use cycle time to calculate that, and you can’t use velocity if you don’t have fixed length iterations. Furthermore, the chunks of work represented by the minimum set of marketable features doesn’t seem very compatible with a pull system. The stakeholders aren’t adding a feature to the queue as we get work done, they’re telling us the minimum set of features that are needed before they’re willing to call a meeting with a key client to demonstrate a new application, and that seems logical given the circumstances. Lastly, calculating cycle time and identifying bottle necks becomes much more difficult if the stories moving through the value stream are not similarly sized, and they commonly are not toward the beginning of an applications lifetime, since there is little or no infrastructure in place at the beginning.

Decision

Since the value of being able to produce rough estimates for new applications to upper management exceeds the value of them being able to add and prioritize stories in the middle of an iteration, we decided to go back to using XP for our next iteration. We will continue to use XP on this application (and all new functionality which can’t be fully launched after one iteration) until it is actually being used in production. We will deliver it to a production environment at regular intervals prior to that, and demonstrate it there for upper management. Once the intended users are actually using it in production and getting value from it, we have tentatively decided to try out a pull system again, since it will make more sense to have new features be pulled through the system in response to work being completed once we are getting feedback from the intended audience, and rough estimates will not need to be communicated back to upper management for that application. Does ‘XP for brand new apps, Kanban for enhancements’ seem like a good modus operendi? One thing that occurs to me as I’m reading back over my post is that if had decided to go with a pull system from the start, we could use some estimation methodology that is unrelated to our process (for example some flavor of COCOMO, or SWAG, or you name it), although I gather that the velocity-based estimates we have been using since we adopted XP have been a lot more accurate than estimates given before the company used an Agile process (although I guess that could have to do with adoption of other Agile practices keeping us focused). If anybody reading this has implemented a new application using a pull system under similar constraints, how did you deal with estimation (was it anywhere near accurate?), and was your work queue much larger at the beginning of the project, or was it small throughout?

Technorati Tags: Agile,Extreme Programming,XP,Lean,Lean Software Development,Kanban

Writing WPF apps using Kiddo/IronRuby and the MVVM pattern

Pat Gannon — Wed, 02 Jun 2010 20:12:04 GMT

Kiddo is a Ruby DSL for building simple WPF and Silverlight applications, inspired by the Shoes library. It’s still an early alpha, but a very cool concept none-the-less. I rather like the idea of being able to produce a slick looking WPF (or Silverlight) UI using a simple Ruby API. The basic syntax looks like this (taken from the post linked to above):

require "kiddo"

Kiddo.start do

draw :stack do
    draw :text, "Text to reverse:", :font_size => 18
    draw :edit_box, :named => "input"
    draw :text, "Your string will show up here.", :named => "result"
    draw :button, "Reverse It!", :named => "fun_button"
end

after :fun_button.is_clicked do
    :result.text = :input.text.reverse
end

end

If you run this, you’ll get something like this on your screen:

You type in some text in the textbox, click the button, and the app will reverse the string and show it above the button. I think the sample code is fairly self explanatory, but if you’re not sure what it’s doing, check out the link above.

The only issue I had with Kiddo is that it wasn’t clear how one could test the logic that was occurring in one of the event handlers (like the string reversing logic in the “after” clause above). I wasn’t able to figure out how I could plug in an MVVM (Model View View-Model: the approximate thick-client equivalent of the Model View Controller pattern for web applications) framework without modifying Kiddo, so I went ahead and monkey patched it to support a very basic type of MVVM that would enable me to easily test the logic that handled UI events. The MVVM extension would need enhancing to be used for probably anything significant, but I think that’s probably true of Kiddo also. Here is the modified Kiddo example, hooking into the extensions I added…

require "kiddo"
require "kiddo_mvvm"
require "main_view_model"

Kiddo.start(:view_model => MainViewModel) do
draw :stack do
    draw :text, "Text to reverse:", :font_size => 18
    draw :edit_box, :named => "input"
    draw :text, "Your string will show up here.", :named => "result"
    draw :button, "Reverse It!", :named => "fun_button"
end

command :fun_button.is_clicked, :reverse_text
end

There are three differences between this and the original example. First, the updated example requires the file with the Kiddo extension I added (kiddo_mvvm.rb) and file with the ViewModel that has the logic that will respond to the button press (main_view_model.rb) Next, the ViewModel class is associated with the sample UI by passing it in as an option on the Kiddo.start method call. Finally, instead of having an “after” clause with the actual logic that responds to the button click, we have a call to the new “command” method which ties the button click event (:fun_button.is_clicked) to the method on the ViewModel that should be executed when the event fires (reverse_text).

Here is the code for the ViewModel class containing the logic (main_view_model.rb):

class MainViewModel
attr_accessor :input
attr_accessor :result

def reverse_text
@result = @input.reverse
@input = "thank you"
end
end

It defines public getter/setter properties that correspond to the text of the “input” textbox and the “result” text (label). It also defines the “reverse_text” method that is invoked by the MVVM extensions to Kiddo in response to the button being clicked. That method reverses the string in “input” and sets it into “result”. To illustrate the advantage that this approach has to simply calling a method on a business object in an “after” clause (that the command can easily read from and write to several bound widgets), it also sets “input” to “thank you”. Now, you can run the revised sample which behaves like the original sample except that it also puts “thank you” in the input box after you click the button.

Now you can write a test directly against MainViewModel to test the logic without bringing the actual UI into play. Here is a simple example of that (test_MVVM_custom.rb), using the very simple Test::Unit ruby testing framework:

require "test/unit"
require "main_view_model"

class MainViewModelTest < Test::Unit::TestCase
def test_reversing
    vm = MainViewModel.new
    vm.input = "mytest"
    vm.reverse_text
    assert_equal "tsetym", vm.result
end
end

The fixture defines a single test that instantiates the ViewModel, sets the input to “mytest”, calls reverse_text and verifies that the result is “tsetym”. Running a test/unit test is very simple, simply execute the ruby file! (ir test_MVVM_custom.rb)
Finally, here is the code for the MVVM extensions I added to Kiddo (kiddo_mvvm.rb):

module Kiddo
class App
    attr_accessor :view_model
end

class << self
    alias_method :original_start, :start
end

def self.start(options={}, &block)
    view_model = options.delete(:view_model)
    if view_model
      App.instance.view_model = view_model.new
    end
    original_start options, &block
end

def command(hash, view_model_method)
    view_model = App.instance.view_model
    if !view_model
      raise "Must pass a ViewModel instance to Kiddo.start in order to bind a command"
    end
    hash[:instance].send hash[:method] do |sender, args|
      #Copy data from widgets into ViewModel
      view_model.methods.each do |method|
        if method.index("=") == method.length - 1
          property = method.chop
                 widget = App.instance.locate property

                 if widget and defined?(widget.text)
                   view_model.send method, widget.text
                 end
        end
      end
      view_model.send view_model_method
      #Copy data from ViewModel back into widgets
      view_model.methods.each do |method|
        if method.index("=") != method.length - 1
          property = method
          widget = App.instance.locate property
          if widget and widget.respond_to?("text=")
            new_text = view_model.send method
            widget.text = new_text
          end
        end
      end
    end
end
end

This code theoretically shouldn’t need to get modified on an app by app basis (except to enable new types of controls, etc.) It essentially just adds in support for the “view_model” option on Kiddo.start and then defines the new “command” method. That method loops through all the methods on the ViewModel that end in “=” (Ruby property setters) and tries to match them to UI widgets based on their name. When a match is found, it sets the ViewModel property to the text of the corresponding widget. (Obviously this approach won’t work for all types of widgets, but it’s a start!) Next, it calls the method on the ViewModel that has the name passed in from the caller. Finally, it loops through all the methods on the ViewModel that don’t end in “=” and tries to match those to widget names. When a match is found, it sets the text on the widget to the corresponding property value from the ViewModel. This enables the ViewModel class to effectively “bind” to widgets simply by creating a getter/setter property with the same name as the widget.

I’m contemplating porting MongoDB Management Studio to use Kiddo, so if that comes to pass, then there will likely be a number of enhancements to this extension.

Introduction to IronRuby - presentation materials

Pat Gannon — Fri, 23 Apr 2010 04:49:48 GMT

Attached is the Powerpoint slide deck and two sample applications (application plug-in and simple DSL) that I used for my presentation for NBNUG on Tuesday, 4/20/10.

Slide deck

DSL Plugin

App Plugin

Troubleshooting Non-Reproducible Bugs in Visual Studio 2010

Pat Gannon — Sat, 07 Nov 2009 08:16:08 GMT

There are two new features in Visual Studio 2010 that help developers troubleshoot bugs that can't be easily reproduced. One is IntelliTrace, which seems like it will be of limited usefulness to me because it can’t be done remotely, but it might be more useful for teams that have a dedicated QA staff and/or don't practice TDD. On the other hand, I watched an episode of Hanselminutes where Scott interviews Tess Fernandez about Debugging Crash Dumps in VS2010, and that technique seems like it could be really useful.

IntelliTrace is only available in Visual Studio 2010 Ultimate. It seems to collect the values of all in-scope variables whenever an IntelliTrace event occurs. Those watched events are configurable (from a long, but pre-determined list), and include things like button clicks, writing to the Debug log, registry access, etc. If you encounter some non-desirable functionality in an application while debugging (or running their test tool), you can break in the debugger, and then see what the state was whenever one of the watched events occurred. There is also an option to basically capture the state whenever a method is called, but that entails a significant performance penalty, as one might expect. I found an article on MSDN that says: “With IntelliTrace, you can debug applications launched from Visual Studio and log files that were created by IntelliTrace or the test tool Test and Lab Manager. You cannot use IntelliTrace with applications launched outside Visual Studio and attached using the Attach to command. IntelliTrace does not support remote debugging of applications that are running on other computers.” That implies to me that there’s no real way to use this functionality to figure out what happened when a bug occurred on a user’s computer, unfortunately. That article is here: http://msdn.microsoft.com/en-us/library/dd264915(VS.100).aspx . Also note that although you can step backwards in the debugger (and step out of methods to see what the variables were in the calling method) in IntelliTrace, you can only step in increments of IntelliTrace events (which can include method calls if you configured VS that way), so it will step over big chunks of code if they don’t include watched events.

Here are some posts about how to get started using IntelliTrace: http://blogs.msdn.com/habibh/archive/2009/10/20/getting-started-with-visual-studio-2010-intellitrace-hello-intellitrace.aspx and http://blogs.msdn.com/habibh/archive/2009/10/21/the-future-of-debugging-is-here-visual-studio-2010-now-supports-stepping-back-in-the-debugger.aspx

Debugging crash dumps, however, does seem like something that can be done to troubleshoot undesirable functionality that happened on a user’s computer (or on a production server). Apparently in Vista and Windows 7, there is functionality in Task Manager such that you can right-click on a process and choose “Create Dump File” which creates a file in “the temp directory”. (Apparently there are separate apps you can download to generate such dump files with Windows XP, such as “DebugDiag”, but I'm not sure if that works with managed code.) You can then open the resulting file in Visual Studio 2010 and, provided you have the source code for the application, debug it in “Mixed Mode” (meaning you can see what was happening in managed code as well as in Native code). Although you can’t step in the debugger when you’ve loaded a dump file, you can see all the values of the variables in memory (by highlighting over them in code just like typical debugging), and using the “Parallel Stacks” window in VS2010, you can get a visualization of the code that all active threads were executing when the dump was generated, and click through to see what all the variables were set to in a given thread when the dump was generated. It was implied in passing that this will work with applications compiled for .NET 3.5. It seems to me this would be incredibly useful for troubleshooting a problem that can’t be reproduced. When the problem happens, just tell the user to create a dump file, send it to development, and then see what was happening with their app at the time. That screencast is here: http://channel9.msdn.com/posts/Glucose/Hanselminutes-on-9-Debugging-Crash-Dumps-with-Tess-Ferrandez-and-VS2010/ I'm excited about this functionality, and I'm hoping to be able to spend more time trying to debug Crash Dumps created from some of my company's WinForms applications, and seeing if it is feasible to do from Windows XP (which is installed on many of the workstations running our applications). When and if that comes to fruition, I'll be writing another post on this topic.

Getting ActiveRecord and NHibernate Working in Medium Trust

Pat Gannon — Wed, 24 Jun 2009 05:31:18 GMT

I have spent the last couple of hours trying to figure out how to get Castle ActiveRecord working in medium trust (using GoDaddy), and I have finally succeeded (for my purposes).

Here are the steps I had to take to get this working:

* Re-built ActiveRecord to allow partially trusted callers, which entails the following steps: (thanks to this thread on the Castle Project forums)

1. Do an SVN Checkout on the Castle project trunk using TortoiseSVN or Subversion. The repository is here: http://svn.castleproject.org:8080/svn/castle/trunk

2. Navigate to the root directory of the Castle project on your machine and enter the following command:

SharedLibs\build\NAnt\bin\nant -t:net-3.5 -D:assembly.allow-partially-trusted-callers=true

Naturally, the build fails (running unit tests), but I was none-the-less able to get the updated DLLs I needed from the build\net-3.5\debug directory under the Castle directory. I updated all the ActiveRecord-related DLLs (and NHibernate, etc.) that my app was using from the release version of ActiveRecord to this newly-compiled version. It also now needs Iese.Collections.dll and NHibernate.ByteCode.Castle.dll

3. I added the following line to my ActiveRecord configuration file (appconfig.xml), which is required by newer versions of NHibernate (thanks to these instructions on NHForge):

<add key="proxyfactory.factory_class" value="NHibernate.ByteCode.Castle.ProxyFactoryFactory, NHibernate.ByteCode.Castle" />

* Enable AllowPartiallyTrustedCallers by adding the following code to AssemblyInfo.cs:

[assembly: System.Security.AllowPartiallyTrustedCallers]

* Place this line after your call to ActiveRecordStarter.Initialize(...): (thanks to these instructions on NHForge)
NHibernate.Cfg.Environment.UseReflectionOptimizer = false;

Apparently getting Lazy Loading to work in Medium Trust is even harder, but there is apparently a tool available called NHibernate Proxy Generator that will enable that to work, although it entails generating proxies at compile-time because Reflection is not allowed under Medium Trust. Here is the tale of an individual who was apparently able to get this to work: http://blechie.com/WPierce/archive/2008/02/17/Lazy-Loading-with-nHibernate-Under-Medium-Trust.aspx At present, I don't need lazy-loading in the application that I'm running in Medium Trust, so I haven't tried it.

Good luck! Leave a comment if this worked for you, or if you have any problems.

Updated Presentation Materials: Developing REST Web Services using WCF

Pat Gannon — Wed, 17 Jun 2009 02:28:13 GMT

Here are the presentation materials that were slightly revised for the second time I grave the WCF/REST presentation (on June 3rd in the South Bay). Sorry for the delay!

RESTDemo.zip

Presenting on REST/WCF in the South Bay

Pat Gannon — Tue, 02 Jun 2009 05:10:33 GMT

I am doing my Developing REST Web Services using WCF presentation again for the South Bay chapter of the Bay.NET user group. It will be Wednesday, June 3rd at the Microsoft’s Silicon Valley conference center at 1065 La Avenida St, Mountain View, CA (Building 1 - room number is still TBD).

Developing REST Web Services using WCF - Presentation materials

Pat Gannon — Thu, 23 Apr 2009 05:48:21 GMT

As promised in the presentation I did last night for NBNUG, here is my slide deck and sample code for my REST/WCF presentation. As I mentioned in the presentation, the sample code is purposefully not well-factored, so as not to obscure the core concepts that the code is demonstrating. The sample code is not at all meant to convey architectural best practices for WCF-based applications, it's essentially an illustration to get folks started working with this technology.

Slide Deck
Sample Code

del.icio.us Tags: WCF,REST,.NET,Web Services

Presenting at NBNUG on 4/21: Developing REST Web Services using WCF

Pat Gannon — Sun, 19 Apr 2009 00:51:15 GMT

I am demonstrating how to create a REST-based web service using WCF at the upcoming NBNUG meeting. Here is the abstract:

Tuesday, 4/21/2009, meeting at 7:00 PM

O'Reilly Media in Sebastopol

1003-1005 Gravenstein Highway North, Sebastopol
Tarsier Conference Room (between Building B and Building C)
(8 miles west of Santa Rosa)

The presenter will walk through a working REST-based web service (and client), implemented with WCF (Windows Communication Foundation). We will discuss the underlying principles of REST (Representational State Transfer), the motivations for it, and how to create that style of web service using WCF. We will discuss how you can secure these type of web services and finally, we will briefly touch on ADO.NET Data Services (formerly known as Astoria): a technology that automatically exposes a REST web service layer on top of a Linq data source.

Rendering a diff in a web page

Pat Gannon — Wed, 08 Apr 2009 07:05:06 GMT

Recently in my spare time, I have been working on a web site where developers can post code snippets which they would like to be reviewed by other developers on the web. Once a code snippet has been posted, other developers can add comments and make a revised version of the code snippet, which will be rendered under the original code snippet as a diff (the difference between the original snippet and the revised snippet). I have registered myself a domain, but the site is not ready to be launched yet. This post is about how I rendered a line-oriented diff in an ASP.NET MVC web page. I'll write another post to announce the site itself when I launch it.

The Algorithm

After a brief period of trying to figure out my own algorithm for rendering a diff, I decided to do some research on how others have solved the problem. It seems that it's not quite as easy of a problem to solve as it would seem on the surface, and there has actually been a fair amount of in-depth research done on how to solve it. I wound up deciding to use Bill Menee's Menees diff library, which uses the popular Myers algorithm, described in the paper An O(ND) Difference Algorithm and its Variations by Eugene W. Myers. The paper looks fascinating, and I might be interested in implementing it myself at some point, but for the moment I'm going to use the Menees library. Here is the abstract to the paper, to give you an overview of how Myers solves the problem.

The problems of finding a longest common subsequence of two sequences A and B and a shortest edit script
for transforming A into B have long been known to be dual problems. In this paper, they are shown to be
equivalent to finding a shortest/longest path in an edit graph. Using this perspective, a simple O(ND) time
and space algorithm is developed where N is the sum of the lengths of A and B and D is the size of the
minimum edit script for A and B. The algorithm performs well when differences are small (sequences are
similar) and is consequently fast in typical applications. The algorithm is shown to have O(N+D2 )
expected-time performance under a basic stochastic model. A refinement of the algorithm requires only
O(N) space, and the use of suffix trees leads to an O(NlgN +D2 ) time variation.

The Code

Here's the code that I came up with to render a diff created by the Menees library.

The model and view-data:

   1:  using System;

   2:  using System.Collections;

   3:  using System.Collections.Generic;

   4:  using System.Linq;

   5:  using System.Text;

   6:  using System.Web;

7:

   8:  using Menees.DiffUtils;

9:

  10:  namespace CodeReview.Models

  11:  {

  12:      /// <summary>

  13:      /// Represents a chunk of source code

  14:      /// </summary>

  15:      public class SourceCode

  16:      {

  17:          public int Id { get; set; }

18:

  19:          private string _title = string.Empty;

20:

  21:          public string Title

  22:          {

  23:              get

  24:              {

  25:                  return _title;

  26:              }

  27:              set

  28:              {

  29:                  _title = value;

  30:              }

  31:          }

32:

  33:          public string Description { get; set; }

  34:          public string Code { get; set; }

  35:          public string CreatedBy { get; set; }

  36:          public List<Comment> Comments { get; set; }

37:

  38:          private List<string> _lines = null;

39:

  40:          public List<string> Lines

  41:          {

  42:              get

  43:              {

  44:                  if (_lines == null)

  45:                      _lines = GetLines(Code);

46:

  47:                  return _lines;

  48:              }

  49:          }

50:

  51:          public bool IsValid

  52:          {

  53:              get { return (GetRuleViolations().Count() == 0); }

  54:          }

55:

  56:          public SourceCode(string code)

  57:              : this()

  58:          {

  59:              Code = code;

  60:          }

61:

  62:          public SourceCode()

  63:          {

  64:              Comments = new List<Comment>();

  65:          }

66:

  67:          public List<Difference> Diff(SourceCode compareWith)

  68:          {

  69:              List<Difference> differences = new List<Difference>();

  70:              IList a = Lines;

  71:              IList b = compareWith.Lines;

  72:              TextDiff diff = new TextDiff((int)HashType.HashCode, false, false, 0);

  73:              EditScript script = diff.Execute(a, b);

74:

  75:              foreach (Edit edit in script)

  76:              {

  77:                  differences.Add(ConvertEditToDifference(edit, compareWith));

  78:              }

79:

  80:              return differences;

  81:          }

82:

  83:          private List<string> GetLines(string code)

  84:          {

  85:              return code.Split('\n').ToList();

  86:          }

87:

  88:          private Difference ConvertEditToDifference(Edit edit, SourceCode compareWith)

  89:          {

  90:              return new Difference()

  91:              {

  92:                  LineNumber = edit.StartA + 1,

  93:                  Text = GetChangeText(edit, compareWith),

  94:                  Type = ConvertEditTypeToDifferenceType(edit.Type),

  95:                  NumberOfLines = edit.Length

  96:              };

  97:          }

98:

  99:          private string GetChangeText(Edit edit, SourceCode compareWith)

 100:          {

 101:              StringBuilder changeText = new StringBuilder();

 102:              SourceCode textSource;

 103:              int lineNumberInTextSource;

 104:

 105:              if (edit.Type == EditType.Insert)

 106:              {

 107:                  textSource = compareWith;

 108:                  lineNumberInTextSource = edit.StartB;

 109:              }

 110:              else

 111:              {

 112:                  textSource = this;

 113:                  lineNumberInTextSource = edit.StartA;

 114:              }

 115:

 116:              for (int i = 0; i < edit.Length; i++)

 117:              {

 118:                  changeText.Append(textSource.Lines[lineNumberInTextSource + i]);

 119:              }

 120:

 121:              return changeText.ToString();

 122:          }

 123:

 124:          private DifferenceType ConvertEditTypeToDifferenceType(EditType editType)

 125:          {

 126:              switch (editType)

 127:              {

 128:                  case EditType.Change:

 129:                      return DifferenceType.Change;

 130:                  case EditType.Delete:

 131:                      return DifferenceType.Removal;

 132:                  case EditType.Insert:

 133:                      return DifferenceType.Addition;

 134:                  default:

 135:                      throw new ArgumentException("Unexpected edit type: " + editType, "editType");

 136:              }

 137:          }

 138:

 139:          public IEnumerable<RuleViolation> GetRuleViolations()

 140:          {

 141:              if (String.IsNullOrEmpty(Title))

 142:                  yield return new RuleViolation("Title is required", "Title");

 143:

 144:              if (String.IsNullOrEmpty(Code))

 145:                  yield return new RuleViolation("Code is required", "Code");

 146:

 147:              yield break;

 148:          }

 149:

 150:          private void Validate()

 151:          {

 152:              if (!IsValid)

 153:                  throw new ApplicationException("Rule violations prevent saving");

 154:          }

 155:      }

 156:

 157:      public class Difference

 158:      {

 159:          public DifferenceType Type { get; set; }

 160:          public string Text { get; set; }

 161:          public int LineNumber { get; set; }

 162:          public int NumberOfLines { get; set; }

 163:      }

 164:  }

 165:

 166:  namespace CodeReview.ViewData

 167:  {

 168:      public class ShowSourceCodeViewData

 169:      {

 170:          public string RenderedOriginal { get; set; }

 171:          public List<CommentViewData> Comments { get; set; }

 172:

 173:          public ShowSourceCodeViewData()

 174:          {

 175:              Comments = new List<CommentViewData>();

 176:          }

 177:      }

 178:

 179:      public class CommentViewData

 180:      {

 181:          public string RenderedOriginal { get; set; }

 182:          public string RenderedRevised { get; set; }

 183:          public string Text { get; set; }

 184:      }

 185:  }

 186:

The controller action and supporting methods:

   1:          public ActionResult Show(int? id)

   2:          {

   3:              SourceCode original = _repository.GetById(id.Value);

   4:              string[] originalLines = original.Lines.ToArray();

   5:              ShowSourceCodeViewData viewData = new ShowSourceCodeViewData();

6:

   7:              viewData.RenderedOriginal = ConvertFromPlainTextToHtml(original.Code);

8:

   9:              foreach (Comment comment in original.Comments)

  10:              {

  11:                  StringBuilder originalBuilder = new StringBuilder(); //the buffer for displaying the original version (on the left side of the diff)

  12:                  StringBuilder editedBuilder = new StringBuilder(); //the buffer for displaying the revised version (on the right side of the diff)

  13:                  string[] editedLines = comment.Revision.Lines.ToArray();

  14:                  List<Difference> differences = original.Diff(comment.Revision);

  15:                  int originalLineNumber = 0;

  16:                  int editedLineNumber = 0;

  17:                  CommentViewData commentViewData = new CommentViewData();

18:

  19:                  foreach (Difference difference in differences)

  20:                  {

  21:                      //put all unchanged lines leading up to this difference into both buffers

  22:                      for (; originalLineNumber < (difference.LineNumber - 1); originalLineNumber++, editedLineNumber++)

  23:                      {

  24:                          originalBuilder.Append(RenderLineHtml(DifferenceType.NoChange, originalLineNumber, originalLines[originalLineNumber]));

  25:                          editedBuilder.Append(RenderLineHtml(DifferenceType.NoChange, editedLineNumber, editedLines[editedLineNumber]));

  26:                      }

27:

  28:                      if (difference.Type == DifferenceType.Addition)

  29:                      {

  30:                          string differenceText = difference.Text;

31:

  32:                          if (differenceText.EndsWith("\r"))

  33:                              differenceText = differenceText.Substring(0, differenceText.Length - 1);

34:

  35:                          string[] lines = differenceText.Split('\r');

36:

  37:                          //put added lines only into the buffer for the revised version, and add blank space to the buffer for the original version

  38:                          foreach (string line in lines)

  39:                          {

  40:                              editedBuilder.Append(RenderLineHtml(difference.Type, editedLineNumber, line));

  41:                              originalBuilder.AppendLine();

  42:                              editedLineNumber++;

  43:                          }

  44:                      }

45:

  46:                      if (difference.Type == DifferenceType.Removal)

  47:                      {

  48:                          string differenceText = difference.Text;

49:

  50:                          if (differenceText.EndsWith("\r"))

  51:                              differenceText = differenceText.Substring(0, differenceText.Length - 1);

52:

  53:                          string[] lines = differenceText.Split('\r');

54:

  55:                          //put removed lines only into the buffer for the original version, and add blank space to the buffer for the revised version

  56:                          foreach (string line in lines)

  57:                          {

  58:                              originalBuilder.Append(RenderLineHtml(difference.Type, originalLineNumber, line));

  59:                              editedBuilder.AppendLine();

  60:                              originalLineNumber++;

  61:                          }

  62:                      }

63:

  64:                      if (difference.Type == DifferenceType.Change)

  65:                      {

  66:                          //put revised version of changed line into buffer for revised version

  67:                          editedBuilder.Append(RenderLineHtml(difference.Type, editedLineNumber, editedLines[editedLineNumber]));

  68:                          //put original version of changed line into buffer for original version

  69:                          originalBuilder.Append(RenderLineHtml(difference.Type, originalLineNumber, difference.Text));

  70:                          editedLineNumber++;

  71:                          originalLineNumber++;

  72:                      }

  73:                  }

74:

  75:                  //put all remaining unchanged lines into buffer for original version

  76:                  for (int i = originalLineNumber; i < originalLines.Length; i++)

  77:                      originalBuilder.Append(RenderLineHtml(DifferenceType.NoChange, i, originalLines[i]));

78:

  79:                  //put all remaining unchanged lines into buffer for revised version

  80:                  for (int i = editedLineNumber; i < editedLines.Length; i++)

  81:                      editedBuilder.Append(RenderLineHtml(DifferenceType.NoChange, i, editedLines[i]));

82:

  83:                  commentViewData.RenderedOriginal = ConvertFromPlainTextToHtml(originalBuilder.ToString());

  84:                  commentViewData.RenderedRevised = ConvertFromPlainTextToHtml(editedBuilder.ToString());

  85:                  commentViewData.Text = comment.Text;

86:

  87:                  viewData.Comments.Add(commentViewData);

  88:              }

89:

  90:              return View(viewData);

  91:          }

92:

  93:          private string ConvertFromPlainTextToHtml(string plainText)

  94:          {

  95:              return plainText.Replace("\r", "<br/>").Replace("\n", "").Replace("  ", "&nbsp;&nbsp;");

  96:          }

97:

  98:          private string RenderLineHtml(DifferenceType differenceType, int lineNumber, string lineText)

  99:          {

 100:              //the line will be styled according to the type of change that was made

 101:              return string.Format("<div class=\"{0}\">{1}: {2}</div>", differenceType.ToString().ToLower(), lineNumber, lineText);

 102:          }

The view:

   1:  <%
   2:      foreach (CommentViewData comment in Model.Comments)
   3:      {
   4:  %>
   5:      <p class="comment_body">
   6:          <%= comment.Text %>
   7:      </p>
   8:      <div class="editingArea">
   9:          <div class="originalCode">
  10:              Original:<br />
  11:              <%= comment.RenderedOriginal %>
  12:          </div>
  13:          <div class="editedCode">
  14:              Edited:<br />
  15:              <%= comment.RenderedRevised %>
  16:          </div>
  17:          <div style="height: 500px"></div>
  18:      </div>
  19:  <%
  20:      }
  21:  %>
 
The CSS:

.originalCode { float: left; border: thin solid black; padding: 10px 10px 10px 10px; width: 450px; }

.editedCode { float: right; border: thin solid black; padding: 10px 10px 10px 10px; position: absolute; left: 600px; width: 450px; }

.editingArea { }

.addition { background-color: Black; color: green }

.removal { background-color: Black; color: red }

.change { background-color: Black; color: white }

.comment_body { font-style: italic; font-weight: bold; }

.comment_header { font-weight: bold; }

#Title { width: 700px; }

#Description { width: 700px; height: 150px; }

#Code { width: 700px; height: 300px; }

This is going to need some work before it's ready for prime time (the HTML conversion and CSS need work, and the controller method should be broken out into smaller methods, perhaps using a command pattern or something, etc.), but I figured it was enough to get you going if you're thinking about implementing something like this yourself. (This approach could make for some very nice build notification emails, IMO.) Did I leave anything important out? Is there a better or easier way to do this? Is there a glaring bug? Leave a comment!

del.icio.us Tags: .NET,asp.net,mvc,algorithms,diff