posh-git Release v0.2

I just tagged the v0.2 release of posh-git, which you can download here. This is the last release supporing msysgit 1.6.5 and 1.7.0. In this release…

PowerShell Module

Thanks to a contribution from David Muhundro, posh-git now exposes its functions through a module (.psm1). The module exposes a number of functions whose usage can be seen in the example profile.

Tab Expansion Updates

  • TortoiseGit commands: tgit <tab>
  • git-svn operations: git svn <tab>
  • Stash completion for git stash operations: show, apply, drop, pop, branch
  • Branch completion for git reset and git rebase
  • Completion of deleted files for git rm
  • For most commands, tab completion should now work if other command flags are in use. For example, git rebase -i <tab> works as expected.

Thanks to Jeremy Skinner and Mark Embling for their contributions to this release.

Next Steps

The most common complaint about posh-git is performance, which has already been addressed for the next release (available in my master branch). However, the fix requires taking a dependency on msysgit 1.7.1, which has not been officially released yet.  Still, it has been working fine for me.

Beyond that, we still need to address the first two items on my list from the last release…

  • Testing! I’d like to figure out a way to run some integration tests that verify a given repository state renders the expected prompt. If you have suggestions how to approach this, or know how other Git integration projects are tested, please let us know over at the Google Group.
  • Documentation! How to get started, what the project provides, etc.

If you have any other feature requests or find issues, please let us know.

Posted in PowerShell. Tags: , . Comments Off on posh-git Release v0.2

St. Louis Day of .NET – August 20-21, 2010

One of my favorite developer events of 2009 was St. Louis Day of .NET. Not only were the facilities (Ameristar Casino) top-notch, but there were a ton of great sessions and I got to pick the brains of some really sharp people. This year’s event looks to be even better, with a huge variety of sessions on principles, practices and plenty of programming. I will be presenting two sessions:

Dynamic .NET Demystified

Dynamic .NET has gone mainstream with the recent promotion of the Dynamic Language Runtime into .NET 4. This session will discuss what the DLR is, how it works with C# 4 and Visual Basic 10, and why this doesn’t mean C# has jumped the shark. We will also look at some ways in which these features can be used to solve real-world problems.

LINQ Internals II: System.Interactive

System.Interactive is a library distributed with Microsoft’s Reactive Extensions, currently available on DevLabs, which provides a number of useful extensions to the LINQ Standard Query Operators. These extensions include operators to add and contain side effects, handle exceptions, generate and combine sequences, and much more. This session will review the new operators and discuss interesting problems they can be used to solve. Note that Rx is available for .NET 3.5 SP1, Silverlight 3 and .NET 4.0, so this session is not just for those developing on the bleeding edge.

Free Stuff

The organizers were kind enough to provide speakers with some discount codes, so I figured this is as good a place as any to give those out. Two lucky commenters will get a code worth $75 off the cover price, with the grand prize being free admission. All you have to do is leave a comment (with a valid e-mail address) convincing me that you deserve these rich rewards over my other suitors. And if your reasons are all terrible, I’ll ask random.org. Deadline is 23:59 CDT on Monday, July 26th.

Hope to see you there!

Posted in .NET. Tags: . 4 Comments »

“Refactoring” Notes

I’m not going to bother with a review of Martin Fowler‘s Refactoring: Improving the Design of Existing Code. It’s good enough that its catalog, available in expanded form online, now provides the definitive vocabulary shared by dozens of refactoring tools across nearly every major development platform. Though I was already familiar with the majority of the catalog, I thought it would be worth reading the other chapters, the notes from which you will find below with my additions indicated with emphasis. I’ve also included thoughts on various entries in the catalog.

Principles in Refactoring

  • 58: You don’t decide to refactor, you refactor because you want to do something else, and refactoring helps you do that other thing.
  • 62: Beck – Maintaining the current behavior of the system, how can you make your system more valuable, either by increasing its quality, or by reducing its cost. … Now you have a more valuable program because it has qualities that we will appreciate tomorrow. … There is a second, rarer refactoring game. Identify indirection that isn’t paying for itself and take it out.
  • 62: Problems with Refactoring
    • Don’t know limitations
    • Is refactoring because a tool tells you to a bad reason?
  • 65: Modify your code ownership policies to smooth refactoring.
  • 66: Code has to work before you refactor.
  • Ward Cunningham: Unfinished refactoring = technical debt.
  • 68: You still think about potential changes, you still consider flexible solutions. But instead of implementing these flexible solutions, you ask yours, “How difficult is it going to be to refactor a simple solution into the flexible solution?” If, as happens most of the time, the answer is “pretty easy,” then you just implement the simple solution.
  • 70: Changes that improve performance usually make the program harder to work with.
  • If you optimize all code equally, you end up with 90 percent of the optimizations wasted, because you are optimizing code that isn’t run much.

Bad Smells in Code

An expanded catalog of code smells is available online.

  1. Duplicate Code
  2. Long Method
  3. Large Class
  4. Long Parameter List
  5. Divergent Change
    • One class that suffers many kinds of changes
  6. Shotgun Surgery
    • One change that alters many classes
  7. Feature Envy
  8. Data Clumps
  9. Primitive Obsession
  10. Switch Statements
  11. Parallel Inheritance Hierarchies
  12. Lazy Class
  13. Speculative Generality
  14. Temporary Field
  15. Message Chains
    • a.k.a. Law of Demeter
  16. Middle Man
  17. Inappropriate Intimacy
    • Circular Reference => Change Bidirectional Association to Unidirectional
  18. Alternative Classes with Different Interfaces
  19. Incomplete Library Class
    • Introduce Foreign Method => Extension Methods
  20. Data Class
    • Favor setters and encapsulated collections
    • Very OO-centric – FP would argue that immutable data classes are preferred
    • Hide Method => Immutability
    • 87: “Data classes are like children. They are okay as a starting point, but to participate as a grownup object, they need to take some responsibility.”
  21. Refused Bequest
    • Smell is stronger if the subclass is reusing behavior but does not want to support the interface of the superclass. (NotSupportedException)
    • Apply Replace Inheritance with Delegation
    • 88: When you feel the need to write a comment, first try to refactor the code so that any comment becomes superfluous.

Building Tests

  • Tests should be fully automatic and self-checking.
  • Interesting that a distinction is drawn between unit and functional tests, but there’s no mention of integration tests as middle ground
  • 97: “When you gget a bug report, start by writing a unit test that exposes the bug.”
    • This is my #1 use case for test-first
  • 98: “The key is to test the areas that you are most worried about going wrong.”
  • 101: “Don’t let the fear that testing can’t catch all bugs stop you from writing the tests that will catch most bugs.”

If this is the first you’ve read of unit testing, check out a book dedicated to the subject like Pragmatic Unit Testing.

Catalog Notes

  • Composing Methods
    • Replace Method with Method Object
      local variables => method object fields to facilitate extracting methods
  • Moving Features Between Objects
    • Introduce Foreign Method = Extension Methods
    • Introduce Local Extension = Subclass or Proxy
  • Organizing Data
    • Replace Data Value with Object
      replace primitive with a type that means something (decimal => Money)
    • Replace Type Code with State/Strategy
      inheritance is often abused, but this is one of its best use cases
  • Simplifying Conditional Expressions
    • Introduce Null Object
      OO approach to avoiding null checks, also not to be abused
  • Making Method Calls Simpler
    • Separate Query from Modifier
      mutation and query operations don’t mix
    • Replace Parameter with Method
      this rarely applies to new code, but rather is found in methods that have evolved over time
    • Hide Method
      • Related: Remove from Interface — useful to let a method “hide in public” for easier testing without cluttering up its expected usage as implementer of an interface
    • Replace Error Code with Exception
      if a circumstance is truly exceptional, exceptions are often better than error codes…
    • Replace Exception with Test
      …but if it’s not exceptional, don’t incur the overhead; for example, return a Null Object
  • Dealing with Generalization
    • Extract Subclass, Superclass and Interface
    • Collapse Hierarchy
    • Form Template Method
    • Replace Inheritance with Delegation
    • Replace Delegation with Inheritance

Big Refactorings

  • 359: “Do as much as you need to achieve your real task. You can always come back tomorrow.”
  • 360: “You refactor not because it is fun but because there are things you expect to be able to do with your programs if you refactor that you can’t do if you don’t refactor.”
    • I need to remember this!!

These are hard to identify, but provide the biggest return on investment. Think of them as high-level goals accomplished through low-level changes from the above catalog.

  • Tease Apart Inheritance
  • Convert Procedural Design to Objects
    • Also, Convert to Functions
  • Separate Domain from Presentation
    • MVP, MVC, MVVM…use something!
  • Extract Hierarchy
Posted in Books, General. Tags: . Comments Off on “Refactoring” Notes

Unit Testing [Serializable]

A common struggle with unit testing is figuring when to just assume somebody else’s code works. One such example is serializability: for simple classes, it should “just work” so we shouldn’t need to write a unit test for each of them. However, I still wanted to be able to verify that all classes in certain namespaces were marked as [Serializable], so I wrote the following test:

[TestCase(typeof(Money), "Solutionizing.Domain")]
[TestCase(typeof(App), "Solutionizing.Web.Models")]
public void Types_should_be_Serializable(Type sampleType, string @namespace)
    var assembly = sampleType.Assembly;

    var unserializableTypes = (
        from t in assembly.GetTypes()
        where t.Namespace != null && t.Namespace.StartsWith(@namespace, StringComparison.Ordinal)
        where !t.IsSerializable && ShouldBeSerializable(t)
        select t


After we have a reference to the Assembly under test, we use a LINQ to Objects query against its types. If a type matches our namespace filter, we make sure it’s serializable if it should be. Finally, by using ToArray() and ShouldBeEmpty() we’re given a nice error message if the test fails:

TestCase 'Solutionizing.Tests.SerializabilityTests.Types_should_be_Serializable(Solutionizing.Domain.Money, Solutionizing.Domain)'
 Expected: <empty>
 But was:  < <Solutionizing.Domain.Oops>, <Solutionizing.Domain.OopsAgain> >
 SerializabilityTests.cs(29,0): at Solutionizing.Tests.SerializabilityTests.Types_should_be_Serializable(Type sampleType, String namespace)

I use a few criteria to determine if I expect the type to be serializable:

private bool ShouldBeSerializable(Type t)
    if (IsExempt(t))
        return false;
    if (t.IsAbstract && t.IsSealed) // Static class
        return false;
    if (t.IsInterface)
        return false;
    if (!t.IsPublic)
        return false;

    return true;

Other than IsExempt(), the code should be more or less self-explanatory. If you had never bothered to check how static classes are represented in IL, now you know: abstract (can’t be instantiated) + sealed (can’t be inherited). Also, note that !IsPublic will cover compiler-generated classes for iterators and closures that we don’t need to serialize.

The final piece is providing a way we can exempt certain classes from being tested:

private bool IsExempt(Type t)
    return exemptTypes.Any(e => e.IsAssignableFrom(t));

private Type[] exemptTypes = new []
    typeof(SomeClassWithDictionary), // Wrapped dictionary is not serializable
    typeof(Attribute) // Metadata are never serialized

Of course, this isn’t a replacement for actually testing that custom serialization works correctly for more complicated objects, particularly if your classes may depend on others that aren’t covered by these tests. But I have still found this test to be a useful first level of protection.

Review: Pragmatic Unit Testing In C# with NUnit (2nd Edition)

I’ve written hundreds of tests, read dozens of articles and listened to several presentations on unit testing, but until recently had never actually read a book dedicated to the subject. In reviewing my options, I was told repeatedly that I should start with Pragmatic Unit Testing (In C# with NUnit) from The Pragmatic Programmers, part of the three-volume Pragmatic Starter Kit. In the context of that starter kit, I found the book to be an excellent introduction to unit testing; however, a developer with sufficient experience could probably get by with a quick glance over the summary provided as Appendix C (which is available online).

But before I get into the book, let me start by applauding the idea of the Pragmatic Starter Kit. As I entered industry after receiving my degrees in Computer Engineering and Computer Science, it became clear that I was terribly unprepared for building quality software. Academia provided a solid foundation of theory and some (basic) techniques to structure code (OO, FP, etc), but provided precious little guidance for scaling projects beyond a few thousands lines of code. Version control was given one lecture and a trivial assignment (in CVS), the unit testing lecture did little to convince me that it actually had value, and automated testing was never even mentioned (in fact, build processes in general were scarcely discussed). These are the gaps that the Pragmatic Starter Kit aims to fill with practical advice from the field, and if Pragmatic Unit Testing is any indication the entire series should be required reading for new graduates (or even sophomores, really).

As one would expect from an introductory volume, the book begins with an excellent overview (PDF) of what unit testing is and why it matters. There are also several pages dedicated to rebuttals to common objections like “It takes too much time to write the tests”, “It’s not my job to test my code”, and my personal favorite “I’m being paid to write code, not to write tests”, which is answered brilliantly:

By that same logic, we’re not being paid to spend all day in the debugger either. Presumably we are being paid to write working code, and unit tests are merely a tool toward that end, in the same fashion as an editor, an IDE, or the compiler.

Developers are a proud lot, so the emphasis on testing as a powerful tool rather than a crutch is crucial.

Chapters 2 and 3 follow up with an introduction to testing with NUnit, first with a simple example and then with a closer look at structured testing with the framework. All the usual suspects are covered, including classic and constraint-based asserts, setup and teardown guidance, [Category], [ExpectedException], [Ignore] and more.

The most valuable chapters to a new tester will be chapters 4 and 5. The former provides the “Right BICEP” mnemonic to suggest what to test; the latter takes a closer look at the “CORRECT” boundary conditions (the B in BICEP) to test. The expanded acronyms are included in the aforementioned summary card (PDF). Even after you have a good handle on what to test, the mnemonics can still serve as a handy reminder, and starting out the overviews of each bullet are spot on. I also liked chapters 7–9, which give good guidance on qualities of good tests and how testing can be applied effectively to projects and to improve code, though the refactoring example was a bit longer than it probably needed to be.

In my opinion, the weakest parts of the book were chapters 6 and 10, on mocking and UI testing, respectively. The former starts out strong, but gets bogged down once it starts talking about tools. The reader would be better off skipping section 6.3 altogether in favor of a good Rhino Mocks or Moq introduction. The discussion of UI testing, on the other hand, covers too little on a number of topics to be of much value other than to raise awareness that you should test all parts of the application.

Overall I was quite pleased with the quantity and quality of material covered for an introductory volume, awarding four out of five donkeys. The authors make a good argument for testing and offer sound guidance for how to do it. However, if you’re already familiar with unit testing you may be better off reading The Art of Unit Testing or finding more specific material online.

Posted in .NET, Books. Tags: . 1 Comment »

SPWeb.AssociatedGroups.Contains Lies

While working on SPExLib (several months ago), I revisited this post, which presented a functional approach to a solution Adam describes here. Both posts include logic to add an SPWeb group association, which most simply could look something like this:

SPGroup group = web.SiteGroups[groupName];
if (!web.AssociatedGroups.Contains(group))

While testing on a few groups, I noticed that the Contains() call lies, always returning false. This behavior can also be verified with PowerShell:

PS > $w.AssociatedGroups | ?{ $_.Name -eq 'Designers' } | select Name


PS > $g = $w.SiteGroups['Designers']
PS > $w.AssociatedGroups.Contains($g)

Of course, it’s not actually lying—it just doesn’t do what we expect. Behind the scenes, AssociatedGroups  is implemented as a simple List<SPGroup> that is populated with group objects retrieved by IDs stored in the SPWeb‘s vti_associategroups property. The problem is that List<T>.Contains() uses EqualityComparer<T>.Default to find a suitable match, which defaults to reference equality for reference types like SPGroup that don’t implement IEquatable<T> or override Equals().

To get around this, SPExLib provides a few extension methods to make group collections and SPWeb.AssociatedGroups easier to work with and more closely obey the Principle of Least Surprise:

public static bool NameEquals(this SPGroup group, string name)
    return string.Equals(group.Name, name, StringComparison.OrdinalIgnoreCase);

public static bool Contains(this SPGroupCollection groups, string name)
    return groups.Any<SPGroup>(group => group.NameEquals(name));

public static bool HasGroupAssociation(this SPWeb web, string name)
    return web.AssociatedGroups.Contains(name);

public static bool HasGroupAssociation(this SPWeb web, SPGroup group)
    if (group == null)
        throw new ArgumentNullException("group");
    return web.HasGroupAssociation(group.Name);

public static void EnsureGroupAssociation(this SPWeb web, SPGroup group)
    if (web.HasGroupAssociation(group))

The code should be pretty self-explanatory. The name comparison logic in NameEquals() is written to align with how SharePoint compares group names internally, though they use their own implementation of case insensitivity because the framework’s isn’t good enough. Or something like that.

There should be two lessons here:

  1. Don’t assume methods that have a notion of equality, like Contains(), will behave like you expect.
  2. Use SPExLib and contribute other extensions and helpers you find useful. :)
Posted in Object Model, SharePoint. Tags: , . Comments Off on SPWeb.AssociatedGroups.Contains Lies

Extension Methods on Types You Own?

It’s no secret that I’m a fan of using extension methods to make code more concise and expressive. This is particularly handy for enhancing APIs outside of your control, from the base class library to ASP.NET MVC and SharePoint. However, there are certain situations where it might be useful to use extension methods even though you have the option to add those methods to the class or interface itself. Consider this simplified caching interface:

public interface ICacheProvider
    T Get<T>(string key);
    void Insert<T>(string key, T value);

And a simple application of the decorator pattern to implement a cached repository:

public class CachedAwesomeRepository : IAwesomeRepository
    private readonly IAwesomeRepository awesomeRepository;
    private readonly ICacheProvider cacheProvider;

    public CachedAwesomeRepository(IAwesomeRepository awesomeRepository, ICacheProvider cacheProvider)
        this.awesomeRepository = awesomeRepository;
        this.cacheProvider = cacheProvider;

    public Awesome GetAwesome(string id)
        var awesome = cacheProvider.Get<Awesome>(id);
        if(awesome == null)
            cacheProvider.Insert(id, (awesome = awesomeRepository.GetAwesome(id)));
        return awesome;

So far, so good. However, as caching is used more often it becomes clear that there’s a common pattern that we might want to extract:

    T ICacheProvider.GetOrInsert<T>(string key, Func<T> valueFactory)
        T value = Get<T>(key);
        if(value == default(T))
            Insert(key, (value = valueFactory()));
        return value;

Which would reduce GetAwesome() to a single, simple expression:

    public Awesome GetAwesome(string id)
        return cacheProvider.GetOrInsert(id, () => awesomeRepository.GetAwesome(id));

Now I just need to decide where GetOrInsert() lives. Since I control ICacheProvider, I could just add another method to the interface and update all its implementers. However, after starting down this path, I concluded this was not desirable for a number of reasons:

  1. The implementation of GetOrInsert within each cache provider was essentially identical.
  2. Tests using a mocked ICacheProvider now needed to know if the code under test used GetOrInsert() or Get() + Insert(), coupling the test too tightly to the implementation. Furthermore, natural tests along the lines of “Should return cached value” and “Should insert value from repository if not cached” were replaced with a single implementation-specific test: “Should return value from GetOrInsert”.
  3. Most importantly, I came to realize that GetOrInsert() really just isn’t something that a cache does, so why should it be part of the interface?

So instead I have a handy GetOrInsert() extension method (conversion is left as an exercise for the reader) that I can use to clean up my caching code without needing to change any of my cache providers or tests for existing consumers.

The question is really analogous to whether or not Select() and Where() should be part of IEnumerable<T>. They are certainly useful ways to consume the interface, just as GetOrInsert() is, but they exist outside of what an IEnumerable<T> really is.

Posted in .NET. Tags: . Comments Off on Extension Methods on Types You Own?