# Monday, 15 February 2010

Episode 71

In this interview, Tim Wingfield describes the Kanban system and how he uses it.

Monday, 15 February 2010 05:11:42 (GMT Standard Time, UTC+00:00)
# Saturday, 13 February 2010

You could start at the beginning and read all the way through Windows Server 2008 R2 Administration Instant Reference by Matt Hester and Chris Henley. Part 1 of the book of the book ("Getting Started") walks the reader through planning, installing and upgrading the operating system, while subsequent sections dive into details about specific areas of the software.

But a more reasonable approach is to open to the section on which you are working today. Each chapter is structured so that you can dig into the detail you need. Each topic begins with an explanation of concepts and definitions of key terms. This part is critical for someone like me, who doesn't spend his days managing servers. Experienced administrators may skip this section and jump to the detailed explanations of how to use and configure each feature of Windows Server 2008 R2. Basic functionality is described first, followed by more advanced features.

A section on Active Directory, for example, begins with a description of built-in groups, followed by a description of custom users and groups and how rights are granted. After establishing these basics, the author describes how to use Active Directory to manage groups, users and rights and how to configure this in Windows Server.

Hester and Henley write in a clear, concise style that simplifies everything they describe. Step-by-step instructions are amplified by screen shots.

The smaller dimensions of the book make it fit easily into a laptop bag, despite the 500+ pages of text.

This is a solid book for a full- or part-time network administrator to keep on hand for a quick reference or for a more detailed look into important concepts of Windows Server.


Official Book site

Saturday, 13 February 2010 20:36:46 (GMT Standard Time, UTC+00:00)
# Wednesday, 10 February 2010

Episode 70

Dave Bost, the host of the popular Thirsty Developer podcast discusses what goes into each episode and some of the technology he uses to record and produce the show.

Wednesday, 10 February 2010 07:22:33 (GMT Standard Time, UTC+00:00)
# Tuesday, 09 February 2010

Unit testing the critical methods of your application is important.

Generally, I focus on testing public methods because this is the interface that others use to interact with my library. Testing only public methods also safeguards me from modifying unit tests every time I refactor or optimize the encapsulated code of my libraries.

Unfortunately, sometimes critical methods are marked Private. Because I always create my unit tests in a separate project, this presents a problem: Private methods are only accessible to other methods in the same class; You cannot call a Private method from an external assembly.

You have several options when testing Private methods from a separate project.

  • Change the method's accessor to Public
  • Create a public 'accessor' to the method
  • Use reflection to access the method
  • Test a public method that calls this method.
  • Change the method's accessor to Internal and make Internal methods visible to your test project.

Each of these approaches has its shortcomings

Change the method's accessor to Public

This is probably too extreme as it breaks any abstraction you were trying to create. Too many public methods can clutter an API, making it overly complex.

Create a public 'accessor' to the method

This involves creating a public class and method decorated with the [Shadowing] attribute. It definitely adds a level of complexity to your class. When you ask MSTest to create a new Unit Test of a private method, you will be prompted to create an accessor.

Test a public method that calls this method

This is a popular choice. The idea is that public methods call private methods, so testing your public methods will call and test your private methods. To get good code coverage, you will need to know which methods are called (an approach known as "White Box testing".) Some people don't like to call this a unit test because multiple methods are called.

Use reflection to access the method

This is the most complicated of the methods listed here; But, if you don't have the source code and you feel you must test a private method, this is your only option.

Change the method's accessor to Internal and make Internal methods visible to your test project.

This method is a good compromise. By default, Internal methods are available only to other methods in the same assembly. However, you can an external project explicit permission to access Internal methods by adding the following line to AssemblyInfo.cs class of the file containing the method you want to test.

[assembly: System.Runtime.CompilerServices.InternalsVisibleTo("TestProject")]

where TestProject is the name of the project containing your unit tests.

When I have access to the source code, marking Internal methods visible is my preferred method of testing private methods. When I don't have access to source code, I tend only to test public methods.

Tuesday, 09 February 2010 15:54:29 (GMT Standard Time, UTC+00:00)
# Monday, 08 February 2010

Episode 69

Shortly after CodeMash, chief cat herder Jim Holmes discusses what went into the planning and what makes this conference different.

Monday, 08 February 2010 03:50:07 (GMT Standard Time, UTC+00:00)

I gave a talk on MEF a numbe of times during January. You can get the slides and demo from the link below

or you can view the slides below:

Monday, 08 February 2010 03:36:13 (GMT Standard Time, UTC+00:00)
# Wednesday, 03 February 2010

Episode 68

James Bender, Mike Wood and Chris Woodruff created NPlus1.org to assist software architects, lead developers and those aspiring to these roles. In this interview, James and Mike discuss the goals and accomplishments of NPlus1.

Wednesday, 03 February 2010 12:47:35 (GMT Standard Time, UTC+00:00)
# Monday, 01 February 2010

Many software developers are using Pair Programming to increase the quality and maintainability of their code. In a pair programming environment, two programmers work together to write code.

Tonight in Southfield, MI, the Great Lakes Area .Net User Group is sponsoring a pair programming event, which we have labeled The Motor City Codeslingers. We invite programmers who work in any language to bring their laptops and pair with another developer. You may bring a side project with you, work on an open source project, work on a programming exercise (we'll provide a few) or just exchange ideas.

Joe O'Brien is a noted Ruby developer and owner of EdgeCase in Columbus, OH. He has agreed to stop by and provide some mentoring on pair programming techniques. Joe's company is well-known for its commitment to pairing as a way to maintain high quality.

The Motor City Codeslingers will meet at the Biggby Coffee House at 26185 Evergreen Rd in Southfield, MI tonight from 6-9PM. If we fill up Biggby, the overflow crowd can head to the Potbelly or Chipotle next door. The official announcement for this event is at http://is.gd/7pFGL

I hope to see you there.


Monday, 01 February 2010 12:38:53 (GMT Standard Time, UTC+00:00)

Episode 67

In this interview, Steven "Doc" List discusses the concepts behind Open Spaces and Community Courtyards and his role in facilitating these events.

Monday, 01 February 2010 12:28:21 (GMT Standard Time, UTC+00:00)
# Sunday, 31 January 2010

I smiled as I drove across the state line into Michigan Friday morning. I was returning home from spending most of the week in Ohio, speaking at user groups throughout the state.

I spoke about Managed Extensibility Framework at four user groups over three days in four different cities.

Tuesday, I spoke at an internal user group of the Cincinnati Financial Corporation, before heading over to the Cincinnati .Net User Group in Mason, OH. Wednesday I drove up to Dayton to speak at the Dayton .Net Developers Group. Thursday I presented to a packed house in Columbus at the Central Ohio .Net Developers Group.

The trip was a great success. At each stop, the crowd was larger than their average meeting.  Everywhere I went I heard probing questions that indicated that I was communicating the concepts of MEF and loosely-coupled architecture. This was gratifying as most people had no idea what MEF was when they arrived at my talk.

The best of the trip was that I had a chance to see old friends. I spent ten years living and working in the Cincinnati area and many of my former colleagues came out to hear me. Some I hadn't seen in years. I once worked for a Columbus-based company, and through them I got to know much of the developer community in that area and I saw many familiar faces in Central Ohio this week. Tuesday and Thursday night, we went out for drinks after the meeting, which gave me a chance to talk one-on-one with a lot of smart people.

I also got a chance to see the inside of the Sogeti offices in Cincinnati, Dayton and Columbus and talk with some of the team in these offices.

I had a great time on this tour and I'd love to do another one.

Thank you to all who came out to hear my talk. Thank you especially to Mike Wood, Jim Holmes and James Bender, who allowed me to stay at their homes on my trip.

Sunday, 31 January 2010 05:07:49 (GMT Standard Time, UTC+00:00)