1: using System.Linq;

   2:  

   3: namespace CompareBytes

   4: {

   5:     class Program

   6:     {

   7:         static void Main(string[] args)

   8:         {

   9:             var foo = new byte[] {1, 2};

  10:             var bar = new byte[] {1, 2, 3};

  11:  

  12:             var isEqual = foo.SequenceEqual(bar);

  13:  

  14:             ...

  15:         }

  16:     }

  17: }

Note that you can use this extension method for any other sequence comparisons (including custom objects – you’ll need to implement IEqualityComparer<T> in your custom class).

Go forth and compare manually no longer!

The Passionate Programmer: Creating a Remarkable Career in Software Development by Chad Fowler is a book focused on helping you become fit as a developer – leading you along the path of life decisions that make the difference between a job and a remarkable career.  As Chad says, “You don’t win a race by trying not to lose.  And you don’t win at life by trying not to suck.”  You have to be tactical, strategic, and deliberate if you want to avoid your career being “one big series of undirected coincidences.”

I won’t belabor all of the points you can find in this book, but I’d like to call out some things that stood out to me.

• Be the worst
  • If you’re the best, nothing is challenging and pushing you to grow/perform.  Seek associations with people that are better/faster/smarter than you.
  • You’re not as bad as you assume.  Give yourself the chance to discover it.
• Practice at your limits
  • Chad’s background as a musician provided opportunity to compare skill improvement to music practice.  While performances are expected to be as perfect as possible, practice is raw, gritty, and doesn’t always sound good.
  • If all you’re ever doing is sitting down churning out elegant code, you’re not pushing at the edges (where all the improvement comes from).
• Study the work of masters
  • In the arts (and many other disciplines), much time is given to learning from the work of those that have gone before.  In the past, this was more difficult in software development due to its proprietary nature, but the sheer volume and quality of open source projects makes this much more accessible now.
  • Existing code reflects on your own capabilities for growth and new avenues of thought.
• Focus on the present
  • If your head is always in the clouds of tomorrow, you’ll miss the daily victories.

  One topic Chad alluded to but didn’t build much on was approaching your career development in an Agile fashion.  I thought this was a great concept, and from some comments on his blog, it looks like he’d like to build on this in the future.  My takeaway was that I’d better start my sprint planning for my career.

There were many other points and topics covered including interaction with peers, management, and customers.  Chad includes a number of “Act on It” exercises which will challenge you to grow in the areas he covers.  Overall, it was a great read with a message I needed to hear, and I’d highly recommend it.

If you want to run the Live Mesh Client beta and the Live Framework Client side by side, you’ll want to make sure and follow the instructions prior to installing the April CTP Update.  Note that you will actually be developing against the Live Framework Client and cannot currently target the Live Mesh Client.  I assume these will merge at some point, and you’ll be able to play in both the live runtime as well as the development runtime, but for now, you’re stuck in the developer playground, so we’ll technically be connecting to the Live Framework Client (not the Live Mesh Client) for now.

I’ve been working on a Live Mesh demo rich client application, and I figured I may as well use the Live ID Client SDK rather than worry about secure credential storage.  This proved to be a bit challenging for a number of reasons, so I thought I’d post my working formula for those that might follow this dark path.

It turns out that the Live ID Client SDK only supports the x86 platform, so the first thing you’ll run across is the installer blows up while installing it on the x64 platform.  It turns out that it still manages to drop the DLLs you’ll need in %CommonProgramFiles(x86)%\Microsoft Shared\WLIDClient.

Create a WPF Application project and add references to Microsoft.LiveFX.Client, Microsoft.LiveFX.ResourceModel, and Microsoft.WindowsLive.Id.Client (found in the aforementioned path as well as %ProgramFiles(x86)%\Microsoft SDKs\Live Framework\v0.91\API Toolkits\.Net Library).  Since the Live ID Client SDK will only work for x86, you’ll need to change your Project Settings for the project that will be utilizing the SDK (highlighted below):

While you’re here, add a DefaultUserName setting to store the user’s Live ID name.  We’ll use this later for automatic sign-in:

Now that all that’s out of the way, we can get on with writing code.  Throw a button on the default layout, rename it, and add a click handler.  Inside the click handler, add the following code:

This code creates the Identity instance that will provide your authentication token.  IdentityManager.CreateInstance takes two parameters: an application ID and an application name.  The application ID is composed of three parts: Company Name;Email Address;Application Name.  In practice, I’ve found I can set this to whatever I want, but the documentation and examples call it out this way, so you’re probably best to stick with this format.  The application name passed in as the second parameter is used during display of the sign in dialog.

If a DefaultUserName has previously been saved, it will instantiate the instance using the value to take advantage of any stored credentials for automatic sign in.  Now add the logic to do the actual sign in:

This logic checks if both the username and password have been stored from a previous login (based on the DefaultUserName passed into the instance).  If they are available, it authenticates silently.  Otherwise, you’ll get the standard sign in dialog:

Notice the application name above the blue guy.  That’s the value you passed in during creation of the IdentityManager.  Once you log in, the username is saved for future automatic sign-in (if you checked Remember my Password).

To connect to the LiveOperatingEnvironment in the Live Framework Client, you’ll need an authentication token.  You can retrieve an authentication token from your authenticated identity via the following:

There are a number of other ways to obtain a token.  If you had been using credentials directly (rather than through the Live ID Client SDK), you could have done so via the following:

Now that you have a token, it’s time to connect to the LiveOperatingEnvironment:

Once this returns, you’re good to go.  It will automatically connect to either the local or cloud environment depending on what’s available, and you can start playing around with the Mesh!

There are a number of asynchronous call alternatives that you can use when it makes sense.  I opted to throw it all in a thread to avoid an unresponsive UI.  Here’s the completed class:

using System;

using System.Threading;

using System.Windows;

using MeshDemo.Properties;

using Microsoft.LiveFX.Client;

using Microsoft.LiveFX.ResourceModel;

using Microsoft.WindowsLive.Id.Client;


namespace MeshDemo

{

  /// <summary>

  /// Interaction logic for MainWindow.xaml

  /// </summary>

  public partial class MainWindow : Window

  {

    readonly LiveOperatingEnvironment loe = new LiveOperatingEnvironment();


    public MainWindow()

    {

      InitializeComponent();

    }


    private void signInButton_Click(object sender, RoutedEventArgs e)

    {

      signInButton.IsEnabled = false;


      var thread = new Thread(

        () =>

        {

          IdentityManager manager = IdentityManager.CreateInstance(

            "Sean Timm;thread@gmail.com;Live Mesh Demo",

            "Live Mesh Demo");


          string currentUser = Settings.Default.DefaultUserName;

          Identity identity;

          if(String.IsNullOrEmpty(currentUser))

          {

            identity = manager.CreateIdentity();

          }

          else

          {

            identity = manager.CreateIdentity(currentUser);

          }


          if(identity.SavedCredentials ==

            CredentialType.UserNameAndPassword)

          {

            identity.Authenticate(AuthenticationType.Silent);

          }


          if(!identity.IsAuthenticated)

          {

            identity.Authenticate();

            Settings.Default.DefaultUserName = identity.UserName;

            Settings.Default.Save();

          }


          string errorMessage = String.Empty;

          bool isConnected = false;

          if(identity.IsAuthenticated)

          {

            string token = identity.GetTicket(

              "user-ctp.windows.net", "MBI_SSL", true);

            var uri = new Uri("https://user-ctp.windows.net");


            try

            {

              loe.Connect(token, AuthenticationTokenType.UserToken, uri,

                    new LiveItemAccessOptions(true));


              Action signInComplete = OnSignInComplete;

              Dispatcher.BeginInvoke(signInComplete);

              isConnected = true;

            }

            catch (Exception ex)

            {

              errorMessage = ex.Message;

            }

          }

          else

          {

            errorMessage = "Failed to authenticate";

          }


          if(!isConnected)

          {

            Action<string> signInFailed = OnSignInFailed;

            Dispatcher.BeginInvoke(signInFailed, errorMessage);

          }

        });


      thread.SetApartmentState(ApartmentState.STA);

      thread.Start();

    }


    private void OnSignInComplete()

    {

      signInButton.Visibility = Visibility.Collapsed;

    }


    private void OnSignInFailed(string message)

    {

      signInButton.IsEnabled = true;

      if(String.IsNullOrEmpty(message))

      {

        MessageBox.Show("Sign in failed for some frustrating reason.");

      }

      else

      {

        MessageBox.Show(String.Format(

          "Sign in failed for this frustrating reason: {0}", message));

      }

    }

  }

}

Notice I explicitly set the thread to single-threaded apartment.  The Live ID Client SDK COM dependencies require this.

Now that you can connect, it’s time to go forth and make a Mesh of things!

In her book, Relevance and Linguistic Meaning: The Semantics and Pragmatics of Discourse Markers, Diane Blakemore speaks, among other things, of incoherent interpretation and contextual assumptions.  While pondering these phrases, I was reminded of Chris Brandsma’s recent article on Refactoring a switch statement.

You see, it’s not that Chris Brandsma is wrong, per se… it’s that I believe that his advice in this matter applies, at best, to a very small number of people who better already understand what they are doing.  For the large majority of developers who still misuse the word “refactoring”, the article merely builds on their disquotational knowledge.

Disquotational knowledge describes the concept of knowing something without understanding it.  There is wealth of this knowledge in our industry.  For me, it’s more important to firmly establish the 90% case and allow for discovery of the 10% case in time.  To that end…

Sean Timm’s rules of proper switch statement etiquette:

1. If your code has multiple switch statements working with a common subset of case instances, the switch must go away.
2. If you find yourself about to write a switch statement:
   • Stop, and mentally confirm that:
     • You’re not already doing another switch on a subset of these same case instances.
     • You don’t plan on doing another switch on a subset of these same case instances.
     • You can’t for the life of you figure out why anyone else would ever do another switch on a subset of these same case instances.
     • You are willing to get rid of this switch statement when you discover that you actually do need to switch on a subset of these same case instances.
   • If any of the above are not true, the switch must go away.
3. If you can’t articulate precisely why a switch must stay, the switch must go away.
4. If you’re not working in a language that supports polymorphic behavior, ignore all of this advice, and do something like Chris suggested.

A Brief Analysis of the Problem

Let’s take a quick look at the original problem:

   1: public string ReturnSomething(string name, string value)

   2: {

   3:     switch (name)

   4:     {

   5:         case "Chris":

   6:             return _valueProcessor.Chris(value);

   7:         case "David":

   8:             return _valueProcessor.David(value);

   9: 

  10:         ...

  11:     }

  12: }

Can anyone tell me what will return when you pass “Chris” and another value into this function?  Of course not… we’ve lost all semantic meaning in this code.  We could fix this with something like the following:

   1: public string ReturnSomething(string name, string value)

   2: {

   3:     switch (name)

   4:     {

   5:         case "Chris":

   6:             return _valueProcessor.PrependLastNameOfChrisToValue(value);

   7:         case "David":

   8:             return _valueProcessor.PrependLastNameOfDavidToValue(value);

   9: 

  10:         ...

  11:     }

  12: }

Ok, that’s a bit awkward, but we’ll run with it.  Since we wrote this code, we’ve discovered that we need to add some new functionality, so we stick to the code:

   1: public string ReturnSomethingElse(string name, string value)

   2: {

   3:     switch (name)

   4:     {

   5:         case "Chris":

   6:             return _valueProcessor.LookupNoteToChris(value);

   7:         case "David":

   8:             return _valueProcessor.LookupNoteToDavid(value);

   9: 

  10:         ...

  11:     }

  12: }

Pretty soon, your interface is starting to look like this:

   1: public interface IValueProcessor

   2: {

   3:     string PrependLastNameOfChrisToValue(string data);

   4:     string LookupNoteToChris(string noteKey);

   5:     byte TheHandThatFeedsChris();

   6:     bool AskChrisIfItIsReallyStillAGoodIdeaThatYouAreGoingDownThisPath();

   7:     void AllKnowledgeOfWhatYouThoughtWasReallyAGoodIdeaThatYouGotFromChris();

   8: 

   9:     string PrependLastNameOfDavidToValue(string data);

  10:     string LookupNoteToDavid(string noteKey);

  11:     byte TheHandThatFeedsDavid();

  12:     bool AskDavidIfItIsReallyStillAGoodIdeaThatYouAreGoingDownThisPath();

  13:     ...

  14: }

Dealing with Code Tumors

When you’re facing uncontrollable growth like this, it’s time to get in and do some surgery.  It should have been dealt with back when it was easier to operate on because now it has spread throughout your code.

First, we introduce a test because we want to remove this malignant growth without interfering with the rest of the code’s ability to function:

   1: [TestFixture]

   2: public class SwitchRefactorDemoTest

   3: {

   4:     [Test]

   5:     public void DoSomethingWithChrisTest()

   6:     {

   7:         var switchDemo = new SwitchDemo(new ValueProcessor());

   8:         var result = switchDemo.ReturnSomething("Chris", "Hey");

   9:         Assert.That(result, Is.EqualTo("BrandsmaHey"));

  10:     }

  11: 

  12:     ...

  13: }

ValueProcessor is being used directly in this test because we’re attempting to get rid of it (oh, I didn’t mention that?).  Among other things, ValueProcessor is clearly violating the Single Responsibility Principle.  This class is doing way too much!  For the purposes of this discussion, I won’t get into details on why this is important, but feel free to add this to your disquotational knowledgebase.

For this example, we’ll be looking at the refactoring known as Replace Conditional with Polymorphism.  You may also want to spend some time investigating Replace Conditional with Visitor as a solid combination of both these techniques can be required at times.

We’re refactoring, so we’ll go step by step and avoid breaking functionality.  We should be able to stop at any time and get back to work on that new defect we just got assigned without worrying about the state of the code.

First, we’ll work with the Chris method of ValueProcessor which currently looks like:

   1: public class ValueProcessor : IValueProcessor

   2: {

   3:     public string Chris(string data)

   4:     {

   5:         return "Brandsma" + data;

   6:     }

   7: 

   8:     ...

   9: }

We do an Extract Method on the logic, and things now look like:

   1: public string Chris(string data)

   2: {

   3:     return PrependLastNameTo(data);

   4: }

   5: 

   6: private string PrependLastNameTo(string data)

   7: {

   8:     return "Brandsma" + data;

   9: }

We run the tests, and everything still passes.  This will be our new method name, but we have a lot more work to do before the conditional is gone.  For now, we’ll just Move Method and delegate our call to the new ChrisProcessor class that we create:

   1: public string Chris(string data)

   2: {

   3:     var processor = new ChrisProcessor();

   4:     return processor.PrependLastNameTo(data);

   5: }

We run the tests, and everything still passes.  Now we go ahead and do this for each of the other conditionals.  We run the tests after each step, and everything continues to pass.  At last, all of the logic has been delegated to these new classes, and the code in the functions looks the same other than which processor we’re instantiating.

We change ChrisProcessor to derive from ValueProcessor, add the PrependLastNameTo() method to the IValueProcessor interface and add a default implementation to ValueProcessor that throws an exception:

   1: public class ValueProcessor : IValueProcessor

   2: {

   3:     public virtual string PrependLastNameTo(string data)

   4:     {

   5:         throw new System.NotImplementedException();

   6:     }

   7:     ...

   8: }

This method is currently not called, and as we modify our conditional to call it, we shouldn’t get the exception because each subclass will override the method.  ChrisProcessor is now ready to be fully responsible for its behavior, but we have an interesting situation with this code.

An IValueProcessor implementation is currently being passed in to the SwitchDemo class.  This interface was being used by the switch statement to call into the correct conditional logic, but that can now happen automatically.  Most likely, we aren’t going to need to pass the IValueProcessor in at all (since the whole SwitchDemo class will likely disappear).

For now, we’ll introduce a factory method that instantiates the correct ValueProcessor subclass (yes, I appreciate the irony of introducing a new switch method, but this is temporary and may disappear depending on the external callers… if not, use Chris’ dictionary for this ):

   1: private class ValueProcessorFactory

   2: {

   3:     public static IValueProcessor GetValueProcessor(

   4:         string processorKey,

   5:         IValueProcessor valueProcessor)

   6:     {

   7:         switch(processorKey)

   8:         {

   9:             case "Chris":

  10:                 return new ChrisProcessor();

  11:             default:

  12:                 return valueProcessor;

  13:         }

  14:     }

  15: }

Note that we’re doing these one at a time, so we start with just replacing the ChrisProcessor and add the others as we go:

   1: public string ReturnSomething(string name, string value)

   2: {

   3:     IValueProcessor processor = ValueProcessorFactory.GetValueProcessor(

   4:         name, _valueProcessor);

   5:     switch (name)

   6:     {

   7:         case "Chris":

   8:             return processor.PrependLastNameTo(value);

   9:         case "David":

  10:              return _valueProcessor.David(value);

  11:         ....

  12:     }

  13: }

Run the tests.  Everything passes.  Do the same thing with each of the other conditionals, and you finally end up with removing the conditional statement altogether:

   1: public string ReturnSomething(string name, string value)

   2: {

   3:     IValueProcessor processor = ValueProcessorFactory.GetValueProcessor(

   4:         name, _valueProcessor);

   5:     return processor.PrependLastNameTo(value);

   6: }

At this point, it’s likely that you don’t even need the ReturnSomething method, so you Inline Method and move the factory instantiation to wherever it makes sense.  Now you go and do the same to all your other switch statements that you need to push into these subclasses.  Lather, rinse, repeat.

Afterthoughts

When you’re disciplined about these things, you’ll find yourself realizing you could have taken a different path and gotten to the same place (or perhaps a better place) a lot sooner.  While working through this example, I realized that rather than delegating the PrependLastNameTo method to the new ChrisProcessor subclass when I was getting started, I should have created a ChrisProcessor class that took IValueProcessor in its constructor.  This would have allowed me to call into the old Chris() function in ValueProcessor while working to modify the conditional logic.  In real code where things are more complicated than this, I probably would have needed access to the IValueProcessor beyond its use in the ReturnSomething method, so keeping it around for delegation purposes makes a lot more sense. Perhaps next time… – Sean Timm