Sunday, April 21, 2013

Durandal + scrollspy

Recently, I played with the Hot Towel MVC template and tried to integrate Bootstrap's scrollspy. This was very difficult for me as my main topic is rather C# and WPF than JavaScript and Html. But after a struggle here and there, I found a solution. Not perfect (any improvements are welcome), but it's sufficient for me.

The problem is that Sammy.js, which Durandal uses for routing, does the routing via hashes (#), which apparently are also used for anchor-navigation. In order to prevent Sammy.js to incorrectly interpret the anchor-links, I added an invisible route for them to the viewmodel of the current page and route it there manually. Hard to describe, see the code!

 //shell.js:
router.mapNav('alpha', 'viewmodels/alpha', 'Alpha');
router.mapRoute('beta', 'viewmodels/alpha', 'Alpha', false);
router.mapRoute('gamma', 'viewmodels/alpha', 'Alpha', false);

In shell.js, in the activate-method, we register the normal route ('alpha'), and for each anchor-link within the alpha-page, another route that maps to the same page ('beta' and 'gamma'). Now, when you click on an anchor on page 'alpha', the activate-method of the corresponding viewmodel will be called with the anchor-value as parameter (see below).

 //alpha.html:

Nothing special for the html-part. The anchor-links are just normal relative anchor-links and the classes are mainly from bootstrap for the scrollspy- and affix-plugin.

 //alpha.js:
define(['durandal/plugins/router'], function (router) {
  var vm = {
    activate: activate,
    viewAttached: viewAttached,
    loaded: false,
    items: [
      { name: "Beta", link: "beta" },
      { name: "Gamma", link: "gamma" },
    ]
  };

  return vm;

  function activate(routeParameters) {
    if (routeParameters.routeInfo.hash != "#/alpha") {
      $(document.body).animate({
        'scrollTop': $(routeParameters.routeInfo.hash.replace("/", "")).offset().top
      }, 100);

      return false;
    }

    return true;
  }

  function viewAttached() {
    if (!vm.loaded) {
      vm.loaded = true;
      $('.bs-docs-sidebar').height($(".bs-docs-sidenav").height());
      $('.bs-docs-sidenav').affix({
        offset: $('#nav').position()
      });
      $('.bs-docs-sidebar').scrollspy();
      $('[data-spy="scroll"]').each(function() {
        var $spy = $(this).scrollspy('refresh');
      });
    }
  }

The activate-function is called whenever a route to this viewmodel is activated. When the normal alpha-route is activated, it is called with "#/alpha" as hash and nothing happens. When an anchor-route is activated, it is called with "#/beta" for example and we scroll to this anchor with jQuery.
The viewAttached-function is called when the databinding has finished. Clicking an anchor-link calls this method not for the first time and nothing happens. The important work is done on the first call: the height of the navigation-div is fitted to its content, the affix-parameter is set and the scrollspy is activated (twice, because I possibly do something wrong here *g*).

 //app.css:
.affix {
  position: fixed;
}
 // index.cshtml:
< body data-spy="scroll" data-target=".bs-docs-sidebar">

Don't forget the scrollspy data-attributes for the body-tag!

That's it :)

Sunday, November 14, 2010

Second sprint experiences of the Coding Dojo Helper

The motto of the second sprint was "Visual Studio Integration". On Microsofts website about VS-extensions, there are a lot of resources about extending the IDE. Unfortunately, after navigating around a bit, you quickly land on the boring msdn library pages. As I haven't found any nice tutorials on the web either, I had to find it out by myself: after downloading the SDK, there are new templates in the new project window under the Extensibility-folder. One of them is named "WPF Toolbox Control" and that sounded nice to me and so I took it ;)

Visual Studio Integration
Outline of a WPF Toolbox Control project
When you compile the project, you get a simple, empty dockable toolbox window inside of Visual Studio, like the properties-window but without the properties :)
The main classes of the project are the CodingDojoHelperVSExtension*.*-files, which specify the embedding of the extension into Visual Studio and MyToolWindow.cs, which is your entry-point in modifying the toolbox.
As I'm using Prism, my constructor (which is the complete code for MyToolWindow btw) looks like this:
[Guid(AGloballyUniqueIdentifier)]
public class MyToolWindow : ToolWindowPane
{
    public MyToolWindow() :
        base(null)
    {
        this.Caption = Resources.ToolWindowTitle;
        this.BitmapResourceID = 301;
        this.BitmapIndex = 1;
 
        var bootstrapper = new CodingDojoHelper.Bootstrapper();
        bootstrapper.Run();
 
        var shell = bootstrapper.Shell;
        shell.Background = new SolidColorBrush(Colors.Black);
 
        base.Content = shell;
    }
}
In my solution, I now have three projects:
  • CodingDojoHelper, which has all the logic and UI in it.
  • CodingDojoHelperDesktop, which references CodingDojoHelper and just provides the main window.
  • CodingDojoHelperVsExtension, which references CodingDojoHelper and just provides the IDE-integration.

I just need minor tweaks to adapt it to the 2 scenarios (like shell.Background = new SolidColorBrush(Colors.Black); instead of an transparent background for the desktop-version). This is really nice and I haven't thought that the integration would be so easy. However, I had two problems to solve:

Digest view with the new amCharts

  1. Every VS-extension must be compiled with a strong key. This means, every depending library also must have a strong key. It leads to the point, that I even need the strong key of Rhino Mocks, because I'm using the [assemblyInternalsVisibleTo]-attribute to be able to mock internal classes for unit-testing. Fortunately, Rhino Mocks provides a key callable via Rhino.Mocks.RhinoMocks.StrongName.
  2. I had to switch from WPF Toolkit to amCharts for this reason: the WPF Toolkit is not a published product and therefore, it hasn't got a strong name :( However, I like amCharts more by now :) I don't need to do much designing so that it looks good ^^
New features
Start-screen
What else is new in this sprint?
  • Start-screen: I've made a start-screen where you can select the target-duration of the TDD-cycles. When the time is up, you'll hear a nasty sound bite like "You weak pathetic fool" from the original Mortal Kombat game! So beware and keep your tests small and do make baby-steps to receive a saying like "Well done" from Shao Khan himself!
  • Beautified: You also have the possibility to set the total duration of the dojo and the number of combatants, that is developers. But these two items are just to show off yet, because they will gain meaning in the next sprint. I downloaded gif-animations of the fighters from an internet-resource and used a special class to make them move inside WPF - looks cool 8-) The other cool thing is a storyboard using an ElasticEase that makes the two buttons for modifying the times (which is indeed a styled scrollbar) swing into their new place. At first, I looked in Blend for the easing functions for WPF in vain. But then, I opened a Silverlight-project, build the storyboard there and copied the XAML into my WPF-project. Feels awkward, but works.
  • Config-screen
  • Config-Screen: This screen is also new to the Coding Dojo Helper and it was easily integrated with the help of Prism. Unfortunately, I haven't looked into Prism V4 and the new navigation possibilities - but this is another user story for me in the coming sprint(s).
  • Styling: I've done the same (styling with a Silverlight-project and copying the result into a WPF-project) with a Checkbox. That was needed, because the WPF-Checkbox is precompiled and therefore not decomposable into atomic WPF elements like Ellipse etc.
  • Gif-Editing: I edited my first gif-image inside of Gimp. The finish him-writing wasn't part of the image. So I opened the gif in Gimp, added 6 frames to it with the text and saved it back. It's as simple as that!
  • Adorner: It is now possible to select the keys used to switch a developer and to end the session. I grab the AdornmentLayer, make it 25% transparent and prompt the user to push the new key for it. Luckily, I had to make the same Adorner-job at work last month. So this was a no-brainer ^^
The Coding Dojo Helper is now fully functional and we use it at work in our weekly coding dojo sessions. When I finished my third sprint, it should be ready for release :D

Saturday, October 30, 2010

Training big refactorings with code katas

Recently, we had to refactor some methods out of a class into a new class. In the past, I already made some big refactorings saved by unit tests. Retrospectively, I must admit that my unit tests back then weren't unit tests but mainly integration tests: although I stubbed away the serial communication, my tests used always all layers of the program. So, instead of mocking C when testing D-->C (uses), I mocked A in D-->C-->B-->A. That means, if you want to refactor B in this chain to B'-->B'', you have to adjust all tests of C and D respectively. This is of course cumbersome.
Thank god, I almost always mock the next layer now, so that refactoring the tests is manageable. I even succeeded to refactor the tests step by step in a TDD-manner having mostly only 1 red test. To be able to do that, the Bank OCR-kata has helped me a lot. In this kata, you can do two class-refactor-steps in the first user story. I would like to present the second one in respect to clearly refactor the tests also (it helps a lot if you're familiar with this kata, so feel free to dive into it or even do a test-run for your own before reading further on).
Code so far:
public class BankAccountParser
{
  private readonly IBankAccountSplitter _bankAccountSplitter;

  public BankAccountParser(IBankAccountSplitter bankAccountSplitter)
  {
    if (bankAccountSplitter == null)
      throw new ArgumentNullException("bankAccountSplitter");

    _bankAccountSplitter = bankAccountSplitter;
  }

  public string Parse(string bankAccount)
  {
    if (string.IsNullOrEmpty(bankAccount))
      throw new ArgumentNullException("bankAccount");

    var bankAccountNumber = new StringBuilder();

    foreach (var digit in _bankAccountSplitter.Split(bankAccount))
    {
      if (digit == " _ | ||_|")
      {
        bankAccountNumber.Append("0");
      }
      else
      {
        bankAccountNumber.Append("1");
      }
    }

    return bankAccountNumber.ToString();
  }
}
Tests so far:
[TestFixture]
public class BankAccountParserTests
{
  private BankAccountParser _target;
  private IBankAccountSplitter _bankAccountSplitter;

  [SetUp]
  public void Setup()
  {
    _bankAccountSplitter = MockRepository.GenerateStub<IBankAccountSplitter>();
    _target = new BankAccountParser(_bankAccountSplitter);
  }

  [Test]
  public void Ctor_ObjectIsNotNull()
  {
    Assert.IsNotNull(new BankAccountParser(_bankAccountSplitter,
MockRepository.GenerateStub<IDigitParser>()));
  }

  [Test]
  public void Ctor_BankAccountSplitterIsNull_ThrowArgumentNullException()
  {
    Assert.Throws<ArgumentNullException>(() => new BankAccountParser(null));
  }

  [Test]
  public void Parse_Null_ThrowsArgumentNullException()
  {
    Assert.Throws<ArgumentNullException>(() => _target.Parse(null));
  }

  [Test]
  public void Parse_Zeros()
  {
    var zeros = " _  _  _  _  _  _  _  _  _ \n" +
                "| || || || || || || || || |\n" +
                "|_||_||_||_||_||_||_||_||_|\n" +
                "                           \n";

    _bankAccountSplitter.Stub(x => x.Split(zeros)).Return(new List<String>
    {
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|"
    });

    var actual = _target.Parse(zeros);

    Assert.That(actual, Is.EqualTo("000000000"));
  }

  [Test]
  public void Parse_AOneAndZeros()
  {
    var oneAndZeros = "    _  _  _  _  _  _  _  _ \n" +
                      "  || || || || || || || || |\n" +
                      "  ||_||_||_||_||_||_||_||_|\n" +
                      "                           \n";

    _bankAccountSplitter.Stub(x => x.Split(oneAndZeros)).Return(new List<String>
    {
      "     |  |",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|",
      " _ | ||_|"
    });

    var actual = _target.Parse(oneAndZeros);

    Assert.That(actual, Is.EqualTo("100000000"));
  }
}
Now I would like to introduce a DigitParser-class which should parse one digit and return a 1-string-representation of it. Therefore, I introduce the interface for it:
public interface IDigitParser
{
  string Parse(string bankAccountDigit);
}
Next, I need to inject it into the target. To do that, I take the easiest test and rewrite it using the new interface:
[Test]
public void Ctor_ObjectIsNotNull()
{
  Assert.IsNotNull(new BankAccountParser(_bankAccountSplitter,
                                         MockRepository.GenerateStub<IDigitParser>()));
}
To make it green, just complete the constructor:
public BankAccountParser(IBankAccountSplitter bankAccountSplitter, IDigitParser digitParser)
{
  if (bankAccountSplitter == null)
    throw new ArgumentNullException("bankAccountSplitter");

  _bankAccountSplitter = bankAccountSplitter;
}
This makes all other tests red because they do not compile anymore. So, alter the setup-method
[SetUp]
public void Setup()
{
  _bankAccountSplitter = MockRepository.GenerateStub<IBankAccountSplitter>();
  _digitParser = MockRepository.GenerateStub<IDigitParser>();

  _target = new BankAccountParser(_bankAccountSplitter, _digitParser);
}
and one test:
[Test]
public void Ctor_BankAccountSplitterIsNull_ThrowArgumentNullException()
{
  Assert.Throws<ArgumentNullException>(() =>
    new BankAccountParser(null, MockRepository.GenerateStub<IDigitParser>()));
}
We're green again and ready for a next test: Assert that when passing in a null-DigitParser, an ArgumentNullException will be thrown.
[Test]
public void Ctor_DigitParserIsNull_ThrowArgumentNullException()
{
  Assert.Throws<ArgumentNullException>(() =>
    new BankAccountParser(_bankAccountSplitter, null));
}
This test is red and becomes green with following code:
public BankAccountParser(IBankAccountSplitter bankAccountSplitter, IDigitParser digitParser)
{
  if (bankAccountSplitter == null)
    throw new ArgumentNullException("bankAccountSplitter");

  if (digitParser == null)
    throw new ArgumentNullException("digitParser");

  _bankAccountSplitter = bankAccountSplitter;
  _digitParser = digitParser;
}
Now comes an interesting step, because we insert an hint into one test how to refactor the sut:
[Test]
public void Parse_Zeros()
{
  var zeros = " _  _  _  _  _  _  _  _  _ \n" +
              "| || || || || || || || || |\n" +
              "|_||_||_||_||_||_||_||_||_|\n" +
              "                           \n";

  _bankAccountSplitter.Stub(x => x.Split(zeros)).Return(new List<string>
  {
    " _ | ||_|",
    " _ | ||_|",
    " _ | ||_|",
    " _ | ||_|",
    " _ | ||_|",
    " _ | ||_|",
    " _ | ||_|",
    " _ | ||_|",
    " _ | ||_|",
  });
  _digitParser.Stub(x => x.Parse(" _ | ||_|")).Return("0");

  var actual = _target.Parse(zeros);

  Assert.That(actual, Is.EqualTo("000000000"));
}
All tests are still green, so we're ready to refactor:
public string Parse(string bankAccount)
{
  if (string.IsNullOrEmpty(bankAccount))
    throw new ArgumentNullException("bankAccount");

  var bankAccountNumber = new StringBuilder();

  foreach (var digit in _bankAccountSplitter.Split(bankAccount))
  {
    if (!string.IsNullOrEmpty(_digitParser.Parse(digit)))
    {
      bankAccountNumber.Append(_digitParser.Parse(digit));
    }
    else
    {
      if (digit == " _ | ||_|")
      {
        bankAccountNumber.Append("0");
      }
      else
      {
        bankAccountNumber.Append("1");
      }
    }
  }

  return bankAccountNumber.ToString();
}
Great, but this can be rewritten easier:
public string Parse(string bankAccount)
{
  if (string.IsNullOrEmpty(bankAccount))
    throw new ArgumentNullException("bankAccount");

  var bankAccountNumber = new StringBuilder();

  foreach (var digit in _bankAccountSplitter.Split(bankAccount))
  {
    bankAccountNumber.Append(string.IsNullOrEmpty(_digitParser.Parse(digit)) ?
      "1" :
      _digitParser.Parse(digit));
  }

  return bankAccountNumber.ToString();
}
But now, the last test is red. We haven't stubbed the DigitParser there yet. To do this, I move the stubbing into the setup-method and also add the canned answer needed for the last test:
[SetUp]
public void Setup()
{
  _bankAccountSplitter = MockRepository.GenerateStub<IBankAccountSplitter>();

  _digitParser = MockRepository.GenerateStub<IDigitParser>();
  _digitParser.Stub(x => x.Parse(" _ | ||_|")).Return("0");
  _digitParser.Stub(x => x.Parse("     |  |")).Return("1");

  _target = new BankAccountParser(_bankAccountSplitter, _digitParser);
}
Prepared like this, we tweak the production code a last time ending with
public string Parse(string bankAccount)
{
  if (string.IsNullOrEmpty(bankAccount))
    throw new ArgumentNullException("bankAccount");

  var bankAccountNumber = new StringBuilder();

  foreach (var digit in _bankAccountSplitter.Split(bankAccount))
  {
    bankAccountNumber.Append( _digitParser.Parse(digit));
  }

  return bankAccountNumber.ToString();
}
But this is not the end for the tests. Actually, we're just testing if the BankAccountSplitter and the DigitParser are working together correctly. So, instead of the last two tests, we should write:
[Test]
public void Parse_SplittedInto2Digits_ConcatenateDigits()
{
  _bankAccountSplitter.Stub(x => x.Split(null)).
    IgnoreArguments().
    Return(new List<string>
    {
      "foo",
      "bar"
    });

  _digitParser.Stub(x => x.Parse("foo")).Return("a");
  _digitParser.Stub(x => x.Parse("bar")).Return("b");

  var actual = _target.Parse("nonrelevant");

  Assert.That(actual, Is.EqualTo("ab"));
}
This points us to some more tests, I had forgotten initially like what happens when the DigitParser returns null or throws an error? What if the BankAccountSplitter has this behavior?

This scales pretty well to "real life" code and as said before, the training with this kata has helped me recognize this pattern during my work and the usefulness of it.

Thursday, October 7, 2010

Coding dojo helper - Mortal Kombat Edition

A colleague of mine told us that really good developers could do a red-green-refactor-circle in about 90 seconds. This sounds quite fast, but I thought that maybe one day we could achieve that... To help getting a feeling for the time spend doing such a circle, I wrote a tool. This tool should take the time of each developer doing a round and calculate the average time of a complete timebox used for a kata, for instance.

Learned new tools :)

As a kata originally comes from martial arts, the tool got a touch of the famous video game Mortal Kombat ^^ For development, I used Blend, Gimp and Audacity to do the design and learned some new tricks. For example, one can draw an ellipse with Blend and select Object --> Path to convert it into an animation path. This path can be used in a storyboard to make a button go round another control for example:
The second thing I've learned is to capture keystrokes even if the window isn't active. This article of Stephen Toub has shown me how to do that. So, if the user presses the Scroll-Button, the stopwatch starts. If he has finished his work, he presses the Scroll-Button again and the next developer begins to code. At the end of the timebox, one presses the Pause-Button and the screen changes to show the average TDD-time and a chart listing all times:
Neat, he? This is also the first time I used a DCVS.


The first attempt was to use Git, GitHub and TortoiseGIT as mediator. But as I'm developing this on a company-laptop during my ride home, there were some difficulties accessing GitHub and I abandoned this quite fast (I do think there are ways to circumvent this, but I hadn't got the nerves to look for them any further). So I tried Mercurial, Kiln and TortoiseHg and it worked like a charm. If you want, you can fetch the sourcecode at codingdojo.kilnhg.com and have a try for yourself if you can master the red-green-refactor-mantra in under 90 seconds. On our first try, we set the alarm to a moderate 3-min-timeout, but did a 4:30 min in average *ouch*. Next time, we'll use a 4-min-timeout and are keen to beat that :)

Sunday, September 26, 2010

Coding dojos

At work, we do weekly coding dojos since 2 1/2 months now - and it's great!
Every thursday at 11am we meet in front of a computer and start a 1h-timeboxed session. This session consists of 3 parts: discuss kata, code, retrospective.

Discuss kata
First, we decide which kata to start with. If we haven't finished the kata from the week before, we throw away the results and start again from scratch including finding a common interpretation of the requirements (e.g. does an account number consist of 3 or 4 lines). Throwing away the work you have already done is not painful at all. Actually, it is necessary to improve yourself. Seeing direct improvements (e.g. completing a part of the kata which was never touched the week before) is priceless!

This part should be as long as necessary but as short as possible. At the moment, we need more than 10 minutes before writing our first test. I think we can cut that into halves in the coming weeks.

Code
At the moment, we work on the Bank OCR-kata and haven't finished the first user story yet. Before this kata, we successfully finished the katas Prime Factors and Roman Numerals *proud*. We do the katas (as well as our actual real-code-pair-programming) in a flow-Randori system:
The first person to be on the keyboard creates the test-project and writes the first test. After that, we play a round of musical chairs and the next developer solves the test. When it's green, he has the chance to refactor the code using baby-steps. Having finished the refactoring, all he has to do now is to write the next test and initiate the next round of musical chairs (which doesn't necessarily needs music to play in the background).
I think doing this kind of system is perfect when you're 4-6 people. Are there more than that, you would probably more likely do the prepari system. But being 10+ developers, I would rather split the group into two halves than having one big group where not everyone can participate.

Retrospective
About 5 minutes before the deadline, we begin the retrospective and try to find out what was good or what can be better next time. Right now, we're far away from a fast TDD-circle: approximately 5 minutes lasts a red-green-refactor-mantra, which surely can be lowered to 2 minutes.

In my opinion, every company writing software should have a regular coding dojo in the calendar. It helps enormously to spread a common coding style. Everyone learns from everyone, be it new keyboard-shortcuts (- is my newest) or amazing tools like R# or Visual Studio Power Tools.
With coding dojos, it is easy to integrate new team members and guide them in learning TDD. All in all, I highly recommend that!

Sunday, June 13, 2010

Prism is witchery

For my newest project, I wanted to use Prism to guide us writing a decoupled WPF-application. I started investigating it and was quickly amazed about the module-approach. In our former WinForms-project, we didn't used a framework to guide us building a nice architecture, but developed our own clsForms-class (at that time even with hungarian notation *awkward*) and used even IPC to communicate across process-boundaries.

I began writing the framework for the new project with heavy guidance of Prism (RegionManager, EventAggregator, DelegateCommands and CommandBehaviors). In the end, we had some modules building a master-detail view with database-access. This was the time when other coworkers started to complain that the architecture is way too complex for such a small application as it is today. We started to discuss how to simplify it and at the end we had a draw in our opinions: some people wanted to keep everything (me included *g*) and some wanted to strip it down to remove Prism, to abolish dependency injection and the IoC container Unity. Our boss had to decide it and spoke to us: "thou shalt remove Prism but keep DI for a better TDD").

The top-3 reasons why Prism is evil for us* are:
(*) i.e. not for me

3) Using the app.config for setting up the modules is error-prone and not type-safe.
I told them that we could do it in code also but somehow I got not heared :/

2) Debugging is too hard.
When you get an exception in a view which will be inserted into a region, you got this Prism-Exception telling you that there was a problem resolving this module for that region. I learned here that you cannot expect everyone to look at inner-exceptions (admittedly mostly at level >5)...

1) Top reason why Prism is evil: it is too intransparent how the regions get filled (witchery *hooo*).
What can I say? For sure, you have to look at the good documentation at their homepage to get the hang of it. Else it's witchery, yes.

So we burned it and removed it from our solution with 10+ modules and about 10,000 loc. We needed 5 hours to remove the lightweight Prism-sections completely and substitute it with our own RegionManager-approach (which is basically the same) and with our own DelegateCommand-approach (wich is basically the same) and without the help for commanding of Prism (we now use code-behind to execute the commands). Ah yes, and we copied the EventAggregator out of the Prism-sourcecode and use it now, because our approach would be basically the same...

Everyone feels better now that the evil is being distroyed.

What was the problem? We're using a whole bunch of new technologies and paradigms in this project (WPF is new to us, as Entity framework, WCF, Prism, TestDrivenDevelopment and dependency injection). This means a lot to learn and sooner or later, your retentiveness is exhausted. This meant to sacrifice a pawn, in this case it was Prism.

Tuesday, December 8, 2009

Another book, another kata

This unit testing book by Andrew Hunt and David Thomas is better than the last one, but I made the mistake? to start reading The art of unit testing in parallel (when I've finished that book, a review will be posted as well). So, nothing bad about the pragmatic book, but nothing good either. It covers NUnit (already with "That") and only strives mock-frameworks. There are a plenty of tips how to write good unit tests, among them mnemonics like "Right BICEP", "A TRIP" and "CORRECT". There is even a Pragmatic unit testing summary in checkbox-format. As if I'll go through all the rules after writing a test *lol*
All in all, a good book - but I'm looking forward to "the art".

Staying by Dave Thomas, I've done his sixth kata "anagrams" a few times and I always learned a new shortcut, trick or whatever. I rarely use the mouse anymore and I've downloaded ReSharper (because we're using NUnit instead of MSTest now) and took benefit from the smooth integration of the refactorings. DevXpress had to go unfortunately.

Here, I've found a nice introductory-video in the principles of coding katas, if you're interested.

Here is a video about the randori-variation.

Uncle Bob takes this approach a step further and declares coding kata as an art. See him performing the prime factor kata to music! here.

Thursday, November 26, 2009

Code katas

I just finished my first code kata :) I did FizzBuzz, a very easy one just to get started. I wrote the last code-bit for the last test to past in a quarter of an hour. Therefore, I continued with "stage 2" of the kata.
I wanted to make it easy to extend and got lost half the way :( There was a point where I refactored too much without unit testing. This was bad because the bigger the steps the more likely it is you have to go a step backwards.
Luckily, I got my act together and accomplished my plan. The rest was fine and all tests passed.
On a second try, my goal is to don't use the debugger anymore (I needed it twice) and take baby steps.

Wednesday, November 18, 2009

PDC 2009

It's PDC again! Yesterday, I watched the opening-keynote. They spoke about the cloud and the new Visual Studio and how they can interact. A database store, codename Dallas, was shown which tries to unite data from all over the world - surely nice to play around with.
About half the time, when talking about the cloud, they showed this list:

1970s: Mainframe
1980s: Client-Server
1990s: Web
2000s: SOA
2010+: Cloud

We're just working on to get to the 90s, great...

One new feature of VS2010 is intelliTrace, which is a history of the program running via the debugger. I hope we switch to VS2010 soon, because that sounds interesting.

Last year, a lot of sessions were recorded and put online. I hope they'll do it this year alike. Nevertheless, don't forget to watch the second keynote today (17:30 CET) at the website with Scott Guthrie.

--------------------------------------------------------------------

The second keynote was great! Silverlight 4 beta available now! With trusted mode!! File system access!!! *download*

Monday, November 16, 2009

Test-Driving

The plan is to do a 2-week-bootcamp right before christmas to learn / get experience with test driven development (TDD). I already tried to practice it and I must say that it's hard. Though writing tests before you implement feels natural (I somewhere read "developing without testing is like driving a car without fastening your seatbelt"), it is so much contradictory to what I'm used to develop (test last development; if tests at all). Because of that I looked for some help in books.

From the first one I only read two chapters online: Test Driven: Practical TDD and Acceptance TDD for Java Developers by Lasse Koskela. You can find the chapters here. As I'm a .NET-developer, a Java-book is not worth purchasing, I think. However, I mention this book because these two chapters are really good. The first one is about beginning TDD. This is the usual stuff about red, green, refactor by example. The second chapter is the one that enlightend me. It talks about how to integrate the testing in the development-process (eXtreme Programming, that is) with acceptance TDD. The following picture is from Lasse's book and opened my eyes. Never before was the test-integration so clear to me. This is the only way how a developer will write good tests: write an acceptance test and make it green via several unit test driven development-cycles.
The other chapters sound interesting - maybe I'll find this book in a library.

Test-Driven Development in Microsoft .NET by James W. Newkirk and Alexei A. Vorontsov is the other book I recently read. I got this book from my good friend Uwe (*winkeWinke*). This book has a foreword by Kent Beck - so this has to be good, I thought. But actually: it isn't :( The first three chapters are OK - the standard-introduction section. Then, the book tries to write a whole example-application with TDD. I must admit, this is courageous - but it fails. I don't think that someone will work through all this code in order to understand how to test a database, a web-service, a web-client, etc. At the end, all tests are more or less the same. I think it is more helpful to learn TDD with your own little project than with this book. By the way, the technology used (ADO.NET instead of Entitiy Framework, ASP.NET Web Service instead of WCF, ASP.NET instead of Silverlight!?) is old...