Mathias Brandewinder on .NET, F#, VSTO and Excel development, and quantitative analysis / machine learning.
31. January 2010 08:04

I have grown a bit frustrated by the difficulty to gather information about local .Net development community events. Of all people, I am one of the best-positioned to hear about these events, because of my involvement with the San Francisco .Net user group, and yet, I routinely discover that I missed an event, because there is no clear place to go to get that information and I never heard about it.

So here we go – ladies and gentlemen, introducing NorCalWeekly.Net, your weekly serving of .Net events in north California! My goal will be to provide in one place, on a weekly basis, announcements for all upcoming .Net events in the area – so if you know of anything relevant taking place, please let me know! The design and features are somewhat minimalist for the moment, I’ll improve it over time.

27. January 2010 18:26

Mark Needham recently published a series of posts around TDD, and one caught my attention. He is mocking a series of calls to a method SomeMethod() of a service IService, and doesn’t really care about the arguments, but:

For the sake of the test I only wanted 'service' to return a value of 'aValue' the first time it was called and then 'anotherValue' for any other calls after that.

His solution is to ditch his mocking framework (Rhino.Mocks, as far as I can tell) for that one test, and hand-roll his stub – and his example is a good case for why you might want to do that, sometimes.

However, this got me curious, and I wondered if this was indeed possible using Rhino. As recently as last week, I struggled with mocking repeat calls; but I had never actually considered a situation where one might want to mock a method, focusing only on the fact that the method is called, without paying attention to the specific arguments passed. Fun stuff.

After some digging into the documentation, I came across IgnoreArguments(), which seems to do the job:

public void SpecifyFirstReturnThenReturnSameThingForeverAfter()
{
var fakeService = MockRepository.GenerateStub<IService>();
fakeService.Expect(f => f.SomeMethod(null)).IgnoreArguments().Return("First").Repeat.Once();
fakeService.Expect(f => f.SomeMethod(null)).IgnoreArguments().Return("SecondAndAfter");

var first = fakeService.SomeMethod("ABC");
var second = fakeService.SomeMethod("DEF");
var third = fakeService.SomeMethod( "GHI" );

Assert.AreEqual("First", first);
Assert.AreEqual("SecondAndAfter", second);
Assert.AreEqual("SecondAndAfter", third);
}

IgnoreArguments() seems to be a potentially convenient way to make some tests lighter. That being said, arguably, the setup here is cumbersome, and the hand-rolled version is clearer: when you reach the point where you wonder if your mock is doing what you think it should, you enter perilous territory…

23. January 2010 00:21

One of the immediate benefits I saw in digging into F# is that it gave me a much better understanding of LINQ and lambdas in C#. Until recently, my usage of LINQ was largely limited to returning IEnumerable instead of List<T> and writing simpler queries, but I have avoided the more “esoteric” features. I realize that now that F# is becoming familiar to my brain, whenever I see a statement in C# which contains a foreach:

foreach (var item in items)
{
// do something with item.
}

… I ask myself if this could be re-written in a more functional way. Sometimes it works, sometimes not. Just like classic OO Design Patterns, functional programming has its own patterns, and I find that having a larger toolkit of patterns in the back of my mind helps criticizing my own code and think about alternatives and possible improvements.

I encountered one such case a few days ago, with the following snippet:

public bool IsValid()
{
foreach (var rule in this.rules)
{
if (!rule.IsSatisfied())
{
return false;
}
}

return true;
}

There is nothing really wrong with this code. However, seeing the foreach statement, and an if statement with a return and no else branch made me wonder how I would have done this in F# – and my immediate thought was “I’d use a Fold”.

More...

18. January 2010 09:01

.Net events in the North California area, Feb 18, 2010 – Feb 24, 2010.

Tuesday, Jan 19, 2010

7:00 PM, O'Reilly Media, Sebastopol: Mathias Brandewinder (that’s me) will talk “For Those about to Mock”. Free, organized by the North Bay .Net user group.

Wednesday, Jan 20, 2010

6:30 PM, Microsoft San Francisco Office, San Francisco: Peter Kellner will talk about “Using WCF RIA Services in Silverlight 4 to Build n-tier LOB application”. Free, organized by the San Francisco .Net user group.

If you know of upcoming .Net-related events in North California that I would have missed, please let me know, and I’ll add them to the thread!

16. January 2010 11:15

One of my recent posts looked into reading the VBA code attached to a workbook, and lead to a discussion on analyzing the differences between the macros of two workbooks – what is commonly called a “diff”.

This got me curious as to how diffs are generated. A quick search lead to the Longest Common Subsequence problem: once (one of) the longest common sub-sequence (abbreviated LCS from now on) of characters between two texts has been identified, it is straightforward to determine what has been added and removed from the original text to get the second text.

Example

Original: this is my great code
Modified: that is my awesome code

LCS: th is my  code

Changes to original: this is my great code

The idea behind the algorithm used to identify such a longest common subsequence (LCS) is a nice example of dynamic programming, and goes along these lines. If I have two sequences,

• if they start with the same character (the head), then their LCS is the head + the LCS of the right-hand remainder of each string (the tail),
• if they don’t start with the same character, then their LCS could start either with the head of the first sequence, or of the second one. Their LCS is the longest of the LCS of the first sequence and the tail of the second, and of the LCS of the second sequence and the tail of the first one.

More...