# Monday, March 8, 2010

Episode 76

In this interview, DevExpress evangelist Gary Short discusses technical debt and its effects on a software project.

Monday, March 8, 2010 11:43:37 AM (GMT Standard Time, UTC+00:00)
# Monday, March 1, 2010

Episode 75

Sam Corder is the founder of the MongoDB-CSharp open source project In this interview, he describes the use of MongoDB and other document database

Monday, March 1, 2010 4:52:13 PM (GMT Standard Time, UTC+00:00)

Tuesday March 23, I will be presenting "Extending your Application with the Managed Extensibility Framework" at the Cleveland .Net User Group in Cleveland, OH. More information is available at http://clevelanddotnet.blogspot.com.

Saturday April 17, I will be presenting "Building Your First ASP.Net MVC Application" at the Pittsburgh Code Camp at The University of Pittsburgh. More information is available at http://codecamppgh.com/codecamp.aspx

Monday, March 1, 2010 11:51:35 AM (GMT Standard Time, UTC+00:00)
# Wednesday, February 24, 2010

Episode 74

Debbie Must describes the unique challenges of deploying her software and how she attacked these challenges.

Wednesday, February 24, 2010 4:51:27 PM (GMT Standard Time, UTC+00:00)
# Monday, February 22, 2010

Episode 73

In this interview, Corey Haines talks about software craftsmanship, what it means to him and his plan to improve the quality of coding in our industry.

Monday, February 22, 2010 4:48:43 PM (GMT Standard Time, UTC+00:00)
# Wednesday, February 17, 2010

Episode 72

C# MVP Darrell Hawley spends a lot of his time programming in Python these days. In this interview, Darrell describes the Django framework for developing web applications in Python.

Wednesday, February 17, 2010 4:26:19 AM (GMT Standard Time, UTC+00:00)
# Monday, February 15, 2010

Episode 71

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

Monday, February 15, 2010 5:11:42 AM (GMT Standard Time, UTC+00:00)
# Saturday, February 13, 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, February 13, 2010 8:36:46 PM (GMT Standard Time, UTC+00:00)
# Wednesday, February 10, 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, February 10, 2010 7:22:33 AM (GMT Standard Time, UTC+00:00)
# Tuesday, February 9, 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, February 9, 2010 3:54:29 PM (GMT Standard Time, UTC+00:00)