Archive for January, 2010

Expanding My Bookshelf

January 31, 2010 Leave a comment

I have just updated my Bookshelf. It’s been Christmas season recently, which means I was able to add some substantial extensions to my library. First of all I got a copy of the Gang of Four (GoF) standard work “Design Patterns: Elements of reusable Object-Oriented Software”. As with Eric Evan’s book on Domain Driven Design, I am impressed by the precise style of writing they used to describe common patterns in Software. It’s been pretty handy in situations where I felt like “wait, I have seen this before, let’s do it right this time”.

My next book, “Best Kept Secrets of Peer Code Review” by Jason Cohen was provided for free by Smart Bear Software, the creators of CodeCollaborator a Software to help with code review. By coincidence, the book deals exactly with this matter and describes the necessary steps to introduce, execute and improve a peer code review process. A very interesting read. Thanks guys.

For Christmas I got Peter Seibel’s “Coders at Work”. Unfortunately, I don’t have much time for reading since I need to prepare for my (soon!!!) exams, so this is one of the books that will have to sit on my bookshelf unread for a while. However, I expect it to be a fun and more relaxed read than most other “tech books”.

My employer was kind enough to donate me an Amazon voucher, which I used to buy the Albahari Brother’s (the are also the creators of LINQ Pad) LINQ Pocket Reference and a book on Functional Programming with F#. Thank you very much Mrs. Leber. Even though I could just read small parts of them, they provided for an excellent bonus on understanding of the underlying principles on LINQ, which was especially handy during my work with the MoreLinq project.

I feel a little unsatisfied for having around 5 books sitting on my desk which I am half through. I’m on a very tight schedule at the moment and need to prioritize tasks relentlessly. Pretty much the same I had to do my whole last year, so I’m used to it :-). Each of those books has been a valuable support to the work I’ve done lately, so I will continue to expand my library in this and that direction, if I see the above criteria met. This leaves me realizing, how important continuous learning and expanding one’s horizon is, which is fun because the horizon is so huge and there’s always something new to discover. Kind of opposite  to what I need to do for school at the moment (fixed horizons, fixed expectations and known solutions)…

Categories: Book Reviews

Configuring Git and Mercurial to use DiffMerge

January 28, 2010 2 comments

My preferred merge/diff tool at the moment is DiffMerge by SourceGear. Besides normal diff and also folder diffs, it supports three-way merging and has a pretty sweet, intuitive UI with a-well chosen colour scheme and excellent shortcuts. The reason it is my tool du jour is its perfect cross-platform implementation supporting Windows, MacOS X and Unix. The feature set (and the UI!) is same on all platforms. Remembering only the workings of one diff tool significantly reduces friction for me.

Integrating DiffMerge with the various VCS I use (mercurial, git and svn) is quite cumbersome, but is fortunately very well possible. I’ll post my sample configurations here. The configuration files are alway located in the user’s home directory. Configuration is the same for Windows/Mac OS X and Unix, however you’ll have to adapt the path to the DiffMerge executable accordingly.

Mercurial (~/Mercurial.ini):

git = True

hgext.extdiff =

merge = diffmerge

cmd.diffmerge = c:\Programme\SourceGear\DiffMerge\DiffMerge.exe

vdiff = diffmerge

diffmerge.executable = c:\Programme\SourceGear\DiffMerge\DiffMerge.exe
diffmerge.args = --result=$output -t1="Local Version" -t2=$output -t3="Other Version" --caption=$output  $local $base $other
diffmerge.binary = False
diffmerge.symlinks = False
diffmerge.gui = True
diffmerge.premerge = True

Mercurial will fire up DiffMerge during merges automatically from now on. Since the built-in diff command will always print directly to console (you can pipe this into a patch file too, very useful!) you need the extdiff extension to enable diffing with DiffMerge. That’s why TortoiseHg also needs to be configured explicitly to use DiffMerge as visual diff tool.

Git (~/.git):

[mergetool "diffmerge"]
        cmd = diffmerge --merge --result=$MERGED $LOCAL $BASE $REMOTE
        trustExitCode = true
        tool = diffmerge
[difftool "diffmerge"]
        cmd = diffmerge \"$LOCAL\" \"$REMOTE\"

Git does not merge automatically but will rather leave merge markes in the file. You have to use

git mergetool -t diffmerge

to bring up DiffMerge. On the web one can find recommendations to set

trustExitCode = false

when using DiffMerge. Since v 3.1. this is no longer needed because DiffMerge now returns correct status codes indicating whether a merge was successful or failed.

Categories: Source Control, Tools

TDD as a Means to Explore New Platforms

January 15, 2010 Leave a comment

On of my motivations behind the iRow project was to try a 100% TDD approach on a real world project. Being familiar with  features of .net testing frameworks (my favorite is MbUnit), my baseline expectations on the way such a framework should work and integrate into my development environment where set. Unfortunately, I was soon disappointed by the frameworks available. I have written about my research on iPhone unit testing frameworks before, so I won’t list their shortcomings here. In retrospective, working with a testing framework gave me unique opportunities to gain insight into the new platform.

The concrete advantages I experienced were:

  • learn about platform specific build systems and deployment details
  • forced to develop components in a loosely coupled fashion from the ground up
  • explore unique mechanisms of the language, that might require new or make known patterns redundant
  • fast compile-test cycle, less time spent in front of the debugger
  • combined with source control: painless experiments
  • combined with isolation framework: implementation shows how runtime manipulations can be made
  • testing framework implementation shows how code meta-data can be leveraged (or not leveraged)

I can imagine taking this approach to learning new platforms in the future. Plus, I think knowing how to verify the own code is an essential skill on every platform.

Categories: Design, Projects, Tools

I’m At StackOverflow Careers Now

January 13, 2010 Leave a comment

Since I am currently looking for an internship at a software company between my exams and studies, I thought it would be a good idea to file my CV at StackOverflow Careers. You can find it here.  The timeframe I am available is 06/2010 – 10/2010.

Categories: General

Modelshredder: Tracking down InvalidProgramException

January 1, 2010 Leave a comment

I received my first bug report for modelshredder the other day. When trying to convert a sequence of objects into a DataTable, the following exception occurred:

I did some immediate research on possible causes for such an exception to be thrown. Microsofts KnowledgeBase indicated there might be a problem with the amount of local variables being allocated inside the injected method, however this was not the case since modelshredder uses only three local variables, regardless of the type of object. After some back and forth with the bug reporter, we were able to conduct a sample to reproduce the bug. Some trial and error with ShredderOptions including different subsets of members revealed, that the exception only occurred when the injected code tried to access an Indexer Property. The cause for this is pretty clear when taking a look at the MSIL generated for a property access.

ilgen.Emit(OpCodes.Ldloc_0);     // Load array on evaluation stack
ilgen.Emit(OpCodes.Ldc_I4_S, i); // Load array position on eval stack
ilgen.Emit(OpCodes.Ldarg_0);     // Load ourselves on the eval stack
ilgen.Emit(OpCodes.Call, pi.GetGetMethod());
// Check if we need to box a value type
if (pi.PropertyType.IsValueType)
    ilgen.Emit(OpCodes.Box, pi.PropertyType);

// Store value in array, this pops all fields from eval stack that were added this for loop

As you can see, the code expects the getter to be callable without any parameter, which is not the case if (PropertyInfo) pi.GetGetMethod() returns an indexer method. Since I can’t imagine there’s any use in representing the contents of an indexer property in tabular form, I decided to simply ban indexer properties from the ShredderOptions. To do so, I have added a validation inside the ShredderOptions constructor to check all PropertyInfos for Index parameters.

PropertyInfo pi = member as PropertyInfo; 

if (pi != null)


if (pi.GetIndexParameters().Length > 0 ) 

throw new ArgumentException("May not contain indexer properties.", "members");


Even though the fix was pretty easy once the cause was identified, bugs in MSIL injection are very hard to track down. The exception could point to any other part of the injected code being incorrect. I haven’t seen any effective way (or tool for that matter) to debug or review runtime injected code yet. It appears, one is pretty much left with nothing but trial and error in such cases.

Categories: Open Source, Projects
%d bloggers like this: