The Software Devotional

Suggestions for Keeping Your .NET Skills Current

I got caught in a flypaper conversation a while back during which one of my fellow developers asked for suggestions on how to keep his .NET skills current. Professional development, as it is generally called, isn't something I think about often. I read a lot, read lots of blogs, speak and write about .NET development, and experiment with lots of new technologies as they become available. Professional development is only a side-effect of my curiosities and interests.

If my observations are anything close to reality, I find that most developers do not spend nearly enough time sharpening their saws. Steven Covey, who coined the phrase in his book 7 Habits of Highly Effective People, describes sharpening the saw as "having a balanced program for self-renewal in the four areas of your life: physical, social/emotional, mental, and spiritual", with the mental area concisely described as "learning, reading, writing, and teaching." The part of the saw that I am talking about is in the mental department.

Other than the 'soft' skills required for advancing in any team environment, a developer must constantly be sharpening his skills in software development in order to continue to be a successful software developer. Developers need to be knowledgeable enough about a broad range of topics to bring the right tool to the table when a need arises. Even if you aren't an expert with the tool, or even very proficient, you need to know where to start. For developers who make a habit of keeping their saws sharp, not everything will look like a nail just because they know a lot about hammers.

Back to the question of skills. So I thought about the things I do. Here is a brief list of the things I do that I think help keep my .NET skills current.

Magazines

Unfortunately, there don't seem to be many mainstream magazines that specifically cover .NET development. However, we have some pretty good ones. If you are on a budget, you will find that you can find the content of most magazines available online.

MSDN Magazine is probably the most well known .NET/Microsoft development magazine, although it isn't my favorite. In my opinion, the articles are too long and detailed (does that sound backward?). In most cases, I am looking for bite-sized, ADHD-friendly, articles that cover the "why, what, and so what" questions along with enough technical detail to get me started on a project. I would prefer more articles that dive deep on more narrowly focused subjects so that I can pick the topics I am interested in. Nonetheless, it is still a very good magazine for staying current with Microsoft technologies - especially the new and yet-to-be released technologies.

Visual Studio Magazine, while it almost faded out of existence several years ago, is experiencing somewhat of a revival. Good authors have been contributing some great content and the magazine has become something I read more regularly.

Along the same lines, CoDe Magazine provides some pretty good .NET technical content as well, but hasn't made it into the group of sources I consult regularly for .NET content (no can explain). One very nice feature that I love about CoDe's website is their topical index. Click any one of numerous topics such as WCF, AJAX, XML, etc. to see a list of articles covering the topic (similar to a tag cloud on a blog).

Find It Online

In addition to reading magazines, preferable online versions, you will find that there are lots of web sites devoted to .NET development topics. I will suggest some, but there really are too many to try to list here. My suggestion is to find several that focus on the area of programming that you want to learn about, and check back with the site regularly for content of interest. Most of them allow you to subscribe to a syndication (RSS/Atom) or email feed to have regular updates pushed to you when new content hits the site. Subscribe to a few and spend a little time each week reviewing the new content and reading/skimming the articles that interest you.

Before getting to the online-only sites, keep in mind that most print magazines (including MSDN Magazine, Visual Studio Magazine, and CoDe Magazine, all mentioned above) can be read online.

One of my favorite programming web sites has always been DevX. <FullDisclosureStatement>I must point out that I also write periodically for DevX, but that is only because after searching around several years ago, DevX was the online publication I liked the most.</FullDisclosureStatement> DevX is a very broadly scoped programming site - it does not specialize in any single type of development and they generally don't dive overly deep on any single topic. Instead, DevX offers a very broad set of content for software developers of all types and ranges of experience. Subscribe to their email digest in the programming areas you are interested in.

The Code Project is also a favorite of mine. The Code Project is a site where developers go to post how-tos, sample code and articles about software development. Like DevX, The Code Project serves a very diverse audience. However, there are so many new contributions every week that you can typically find several different articles on any subject (most with sample code) you are searching for.

Two others that I follow very closely are InfoQ and TheServerSide.NET. InfoQ is a very broadly based architecture and development community news site. It covers everything from Java and open source development to .NET development. If you consider your role to encompass that of architecture, make sure you keep up with the news flowing out of InfoQ.  TheServerSide.NET is slanted more towards boots-on-the-ground developers practicing the art of .NET development. Both are good places to keep up with the world of development.

Even better than reconnoitering the web site on a regular basis, which you are likely to forget to do on a regular basis, sign up for the periodic emails from the sites. It pushes the content right under your nose. If you spend the time to read through these messages, you will have no trouble staying on top of the goings on in the industry.

Blogs

Blogs might initially seem similar to online magazine articles, but after reading through them for a while you will find that they are generally much different. Blogs are typically more narrowly focused streams of content. You will find authors blogging about things they come across in their jobs: programming VB.NET, software architecture, WinForms control development, etc. What's better, most blogs support subscriptions so you can not only be notified of new content, but also so you can read the content at your leisure from any of a number of great blog readers (if you don't have one you already LOVE, try Google Reader). The idea here is to pick lots of blogs from authors that post about topics that interest you. Plan to add more blog subscriptions as you find more content and to unsubscribe from blogs that go stale.

If you are a .NET developer, check out Scott Guthrie's blog. He posts on lots of topics of general interest to .NET developers.

Do a Google search for ".net programming blogs". Subscribe to the ones that interest you. I find it helpful to browse the actual blog web site occasionally to find links to other interesting blogs. Do this periodically to keep your list of blogs fresh and interesting to you.

Although not of specific interest to .NET developers, one of my favorite techy blogs is Coding Horror, hosted by Jeff Atwood. The topic isn't always about programming, but Jeff normally writes about topics that are of interest to developers with a sense of humor that is sure to please all but my wife, who doesn't seem to find humor funny.

Books

There really aren't a lot of general purpose .NET programming books that I can recommend, since a good book has a narrow focus on a particular subject area. However, I have listed a few good places to start below.

Code Complete, by Steve McConnell, is one of the most widely read books about solid coding practices that exists. It is now in its second edition (I own both) and has been revised to include more .NET coverage.

A topic that ALL developers should know more about is design patterns. The best book on the market for learning design patterns is Head First Design Patterns. It is one of a number of books from the Head First series, which takes a narrative and almost Socratic approach to teaching design patterns. After reading Head First Design Patterns and when you have come to understand when a design pattern is useful and how it works, you can pick up Professional Design Patterns in VB.NET or purchase download-able code for each of the patterns from the Data & Object Factory. While I don't recommend it because it is more academic that most developers need, I will get beat up (no, seriously) if I don't also mention the so-called gang of four design patterns book: Design Patterns: Elements of Reusable Object-Oriented Software.

Another great way to stay fresh is to get certified as a Microsoft Certified Professional Developer. While I don't value certification for most developers, it is a big help for either new developers or developers getting out in the job market. A MCPD line on your resume can stand out when large numbers of resumes are being reviewed. If you are happily employed, the training can yield lots of nuggets of new information you didn't previously know and, in some cases, get you a small bonus or bump in pay.

There are lots of other books you can consider. There are only a few that I can recommend to a broad audience:

Practices of an Agile Developer should be required reading for developers. Even if your development group doesn't practice agile development, read this book. It should have been named Practices of a Professional Developer.

Peopleware and The Mythical Man-Month are age-old favorites that seasoned software developers know and bring up, often in a passing way, in hallway conversations. They are good bedside reading because they will put you to sleep and because there are sound management principles covered throughout both books.

Also, as a general rule of thumb, don't shy away from management books. Having noodled over some of the issues faced by managers might be a benefit one day when you have the opportunity to lead a group of developers. Management books are also good because they can help a developer to be more self-aware of himself when it comes to how managers view developers.

Conferences/Training

The most popular conferences are the large national conferences hosted around the country. The biggest conference with the broadest diversity of content available is DevConnections, held twice a year: Orlando in the Spring and Las Vegas in the Fall. This conference draws the best speakers every time.

Another big conference to check out is VSLive. VSLive is very similar to DevConnections, except on a smaller scale. VSLive travels to more venues so you might find one closer to home.

I am very happy to see that there are smaller locally hosted conferences popping up all over the country. These are often non-profit and often hosted by a local user group. They don't have nearly as many nationally recognized speakers, but are LOTS cheaper, don't require travel, and last only 1-3 days. These factors make local conferences easy to get approved by your manager. Ask around at a local user group or check out Community Megaphone to find a conference near you. If you live in or near Nashville or Knoxville (Tennessee), check out DevLink (Nashville) or CodeStock (Knoxville) - both are great examples of local conferences offering great content at unbeatable prices.

Microsoft hosts events in lots of cities all over the country to promote their servers and development tools. Don't miss the free training and an opportunity to network with other developers in your area. Check the MSDN Events site regularly.

Another avenue you can pursue is focused developer training from one of many training providers. In most big cities, you will probably find several training providers that offer a wide range of training. Be careful though - many training providers simply choose to use the Microsoft-authored training curriculum, which is good enough to get you started if you are starting near zero. The best training providers that I know of are Pluralsight and DevelopMentor. Both have written top-notch custom training programs covering many .NET subject areas. Pluralsight edges out DevelopMentor (seems to me that most of the best talent from DevelopMentor moved to Pluralsight several years back) in terms of high-power talent teaching and authoring the courses, but DevelopMentor has considerably broader course offerings, more training locations, it offers each course much more often, and offers several courses in Guerrilla format (10-12 hours per day for 5 days).

Conclusion

I have undoubtedly missed some important points because I pulled this together very quickly. If I have missed something you think important to mention, leave me a comment.

devLink 2009

Tennessee developers: registration opened on April 1 for devLink 2009. devLink is a software development conference held in Nashville every year - this year it is scheduled for Thursday, August 13 through Saturday, August 15 and will be held  at the David Lipscomb University campus. Like the big national conferences, devLink provides great session content by great speakers. But unlike the big national conferences, devLink limits attendance (this year to 800 attendees) and its non-procrastinator price is only $75 (goes up to $100 after April 15). Register now because it sells out every year.

devlink is organized by John Kellar: speaker, developer, blogger, and nice guy.

devLink is one of a growing number of "local" conferences being organized all over the country. In general, they are on similar footing as VSLive, DevConnections, and the SD conferences in terms of content, but lack the big-budget venue and marketing blitz. This appeals greatly to me because I dislike the travel expenses of getting to the conferences and because many of the national conferences slant session content toward the material being pushed by the big marketing departments of Microsoft, Oracle and the like. The "local" conferences that come to mind (without Googling) are devLink (Nashville, TN), CodeStock (Knoxville, TN), and CodeMash (Sandusky, OH). Check them out and attend the one that's most convenient to you.

If you know of any that I've missed, please let me know by posting here or emailing me.

Warning About Using Extension Methods

In an article I published at DevX about some of the new features in VB9, I described how you could use extension methods, which are a new feature available in VB9, even in projects targeted at the .NET 2.0 framework. When I first read about extension methods, my mind began racing through all the features I wish various classes and products had implemented. A short list of the extension methods I implemented and used frequently are described below.

• IsSomething(Object) and IsNothing(Object): These methods make it easy to check object references.
• SafeString(String): This method always returns a string. In the event that a string was set to Nothing, it returned String.Empty. An overloaded version of the method also accepted a default value that would be returned when the string was set to Nothing.
• SafeDBString(SQLDataReader), SafeDBInteger(SQLDataReader), etc: These methods allow safe access to fields returned in a result set. In most cases, when I want to read a string from a database, especially for display, I want an empty string instead of DBNull. This method does this neatly and concisely.

I know there are various ways to implement these methods without using extension methods, but the dot syntax used when you call extension methods appeals to me. The syntax of strMyString.IsNullOrEmpty() seems more natural than String.IsNullOrEmpty(strMyString).

That said, I will offer you a warning that my article referenced above did not mention. If 1) you work in an environment where classes containing plumbing code, business classes, and the like are created, and 2) you have used extension methods created in .NET 2.0 projects, you will find yourself in a sticky situation when (if) you decide to use those classes from a .NET 3.5 project. The problem is caused by duplicate definitions for the ExtensionAttribute: one in your .NET 2.0 project and one in the .NET 3.5 framework.

When you attempt to compile a .NET 3.5 project with references to duplicate ExtensionAttribute definitions, the build output console in Visual Studio doesn't show a specific error. It merely indicates that the build failed. If you attempt to build the project manually using command line tools, the error message looks like the output below.

Microsoft (R) Visual Basic Compiler version 9.0.30729.1
Copyright (c) Microsoft Corporation.  All rights reserved

InternalXmlHelper.vb(9) : error BC30560: 'ExtensionAttribute' is
ambiguous in the namespace 'System.Runtime.CompilerServices'.

<Global.System.Runtime.CompilerServices.ExtensionAttribute()> _
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

If you have the luxury of upgrading your entire code base to .NET 3.5 at one time, then you will be safe. Simply remove the 'hacked' ExtensionAttribute definition from your code. When the projects are recompiled, references to the ExtensionAttribute will naturally pick up the definition provided in the .NET 3.5 framework.

If you run in a mixed environment, like I do most of the time, then you will run into the problem that the ExtensionAttribute will be defined both in your .NET 2.0 project (as described in the DevX article) and in the .NET 3.5 framework. This will prevent you from compiling any .NET 3.5 projects that reference any of your .NET 2.0 classes that use extension methods. Keep in mind that this means that any project that contains the .NET 2.0 assembly where you 'hacked' a definition for ExtensionAttribute, even if it is an indirect reference (you reference an assembly that references it), cannot be referenced by a .NET 3.5 project until the 'hacked' definition is removed.

Extension methods are still useful in some smaller projects where the entire project will be upgraded to .NET 3.5 at one time. Extension method users beware: if you work in an environment where you have multiple versions of .NET assemblies in use, you are heading into a world of pain.

GUID Visualizer Broken in VB.NET and How to Fix It

A colleague brought over a strange problem he was seeing while debugging a VB.NET project. During a debugging session he hovered his mouse over a variable of type System.Guid. You normally expect the standard visualizer for the type to appear, but it was displaying "Empty". Unfortunately, this led to some thrashing and gnashing of teeth because this 'bug' caused him to incorrectly suspect a problem with his code.

After a bit of searching and reflecting over the System.Guid class, I found that it is the visualizer for GUIDs in VB.NET that is 'broken'. The 'bug' exists in both Visual Studio 2005 and Visual Studio 2008. Dang.

Here is what the problem looks like out in the wild. In VB.NET, the visualizer tricks you into thinking that the value of the GUID is Empty.

When you call .ToString on the GUID, there is clearly a GUID populated.

I ran the *same* code in C#, and it works perfectly. +1 for C#!

 

Microsoft left a bug in the two most recent versions of Visual Studio? Not really.

When I found that the GUID shows up correctly when you call the .ToString method, I realized that the GUID is populated, it just doesn't appear correctly in the debugger. This led me to believe that there must be something else going on. I got out Reflector to take a look at the System.Guid class and found the problem.

As it turns out, the System.Guid class contains a single read-only property named Empty. Because the Empty property shows up in the debugger visualizer as the only member, it has the effect of making you think that the value is empty. To make matters worse, the Empty property returns an empty (all zeros) instance of a System.Guid class. The result, when you drill into the System.Guid variable: you get a never-ending tree of what appears to be Empty GUIDs.

We can't blame the visualizer specifically. The word Empty is misleading and leads developers to believe that a GUID variable is empty - the "not used" type of empty.

You can work around this problem by downloading a visualizer for GUIDs (from here and here).  Both of these visualizers give you the option to open a window in the debugger displaying the GUID's value. A little cumbersome.

Here's how you can create an even better GUID debugger visualizer on your own.

Create a VB.NET class library. If you are using Visual Studio 2008, make sure to target the .NET 2.0 framework. Create a new class and put the code below into the class file. The class and project names do not matter.

<assembly: system.diagnostics.debuggerdisplay(="" {tostring}="" ,="" target:="GetType(System.Guid))">
Public Class Visualizer_GUID
    '---- no implementation necessary
End Class

Compile the code and put the output in your "My Documents\Visual Studio 2008\Visualizers" and/or "My Documents\Visual Studio 2005\Visualizers" directories. Crank up another Visual Studio project, create a GUID, and hover over it in debug mode. Here's what you will see.

Now that's much better.

You can download my project and compiled class library here (11.3K).

Speaking at VSLive Dallas

One of my favorite things to do is talk at professional conferences. If you've ever seen me speak at one, you'll know immediately that professional speaking is not an essential skill in my profession, but I am getting a little better each time. I will be speaking at VSLive in Dallas about one of my favorite topics: cloud computing.

Come see me from 9:45 - 11:00 AM on Tuesday, December 9. My hope is to dispel some of the hype, and related mistrust, surrounding cloud computing. I will give you the practical knowledge of how to build big-company reliability and scalability into your product for a small-company price. Amazon's web services offerings are changing the landscape of software development - come see how it can impact you.

Here's the official session information:

Cloud Computing for .NET Developers

Cloud computing services are beginning to impact the developer community in a big way. Companies ranging from microISV start-ups to Fortune 500 companies are finding tremendous value in cloud-sourcing functions traditionally serviced by in-house facilities. Amazon's Simple Storage Service broke the ice with inexpensive large-scale reliable storage that catered to the development community. More recently, the Simple Queue Service, the Elastic Compute Cloud, and SimpleDB services have made possible what was too expensive to consider previously. The time has come to change the way we look at infrastructure - not only do we not need to build these services any longer, but we don't even need to manage them.

This session will start by exploring the possibilities to leverage cloud services available from Amazon. We will discuss how they are commonly being used, and how the services can best be adopted in your applications. Then we will spend the majority of our time exploring code to use each of these services inside your applications. We will discuss freely available tools and libraries that are available and how they can serve you best. PowerPoint will be kept to a minimum in favor of code and samples. You will leave this session with a solid understanding of how cloud computing services can help you build more robust applications more quickly and less expensively.

If you use the promotional code SPJON when you register, you'll receive $300 off your conference registration package of your choice!

How I Do It: Unit Testing with NUnit

Unit testing should be a way of life by now for all developers. It should be something that every developer does with every project. We should be running code coverage analysis on all our projects to help ensure that we are building the right tests. Should be.

Mainstream adoption of unit testing seems to be making progress - more and more development groups are testing at least some error prone portions of their code or are adding unit tests when new code is added to a project. These are healthy choices for any development group.

For those development groups that pick up unit testing late in the game, they face a tough challenge. Realistically, we have to face the fact that unit test coverage will start very small and grow over time. Because it takes so long to write good unit tests, and because code that was written without unit testing forethought is tough to test, we have to accept a slow transition. Below, I share my ideas about how to write good unit tests. This article will cover NUnit specifically, but many of the ideas are equally applicable to any unit testing framework.

I have a few theories about unit testing that have shaped my unit testing practices.

Testing Is Almost Always More Important Than Encapsulation

Good unit testing is almost more important than OO encapsulation. That is, when design decisions regarding the interface of my classes, I choose will choose to make the classes more testable than more encapsulated. On public interfaces, I am lean a little more in the direction of encapsulation so the end user isn't either 1) pained by lots of testing baggage on the class's interface or 2) exposed to methods that have the potential to cause serious run-time problems. If you are working in an assembly that will never be exposed to the end user, take advantage of your envious position and lean heavily toward making your classes easier to test more effectively by compromising your 'public' interface.

Consider Testing Needs Early and Often

Unit testing should be integrated into every facet of your development. When you design classes, when you decide on parameters to methods, when you design the tasks the methods will perform, when you design methods that will require complex objects to be provided as parameters, consider the testing requirements of the system. It will often change your perspective in ways that you will be pleased about later.

Find Good Tools

Unit testing is very easy to skip or postpone - if it is hard to run the tests, you will be much less likely to run them early and often. A good tool will make it easier to execute the tests, view the test results, debug the tests (step through the code), and calculate/display code coverage results. You will likely purchase these tools, but a good tool is worth the investment. Unit testing tools that make testing easier will help you to get in and stay in the practice of testing early and often.

Writing Unit Tests - Best Practices

Locate your tests in a separate assembly

Put unit tests in a new project separate from the project you are testing.  Name the unit testing project using the same naming convention used to name the assembly being tested, adding ".NUnit" at the end of the project name.  If the assembly is named CorporateLibrary, your unit test project should be named phc_CorporateLibrary.NUnit.  The uniformity in naming convention will make it easier to find the unit test library. In addition, if your group uses more than one type of unit testing, you will be able to distinguish your NUnit test classes from other types.

Inside your testing project, name the classes that contain the unit tests using the same name as the class being tested, adding "_Test" to the end of the class name. Since you will probably be testing multiple classes, separate the tests for each class in its equivalent class in the test project. If you have used folders to organize your project, use the same folder names and hierarchy to organize your test classes.

One Test Per Method

Each method should test a single piece of functionality of the method class or method it is testing.  You should generally opt for lots of test methods over fewer test methods that test lots of functionality.  The results of your testing will give a finer granularity of error results that will help determine the nature of the problem that caused the test to fail.

Instead of creating a single test method to test the return value of a function given different parameters, create multiple tests, one for each set of input parameters. This will help you to quickly identify which test failed when you see a red error result in the NUnit GUI.
Put Your Test Class(es) in a Separate Assembly

Name Your Tests for Easy Identification

Name your tests using the following convention: Test_<methodbeingtested>_<brieftestdescription>. If you are writing a unit test to ensure that the GetString method handles Nothing parameters correctly, you might name your test "Test_GetString_Nothing".

Do Not Write Unnecessary Output

Do not write unnecessary output inside your unit test unless it is required to verify that the unit test was successful.  In most cases, your test should be written such that a failure is reported using one of the standard error reporting methods, normally a series of Assert* methods.

Never (Almost) Catch Exceptions in Unit Tests

Unless there is a compelling reason to handle an exception in your unit test, it is better to avoid any error handling in your unit test methods.  Instead, allow NUnit to capture the exception and report it in the unit test results.  If the test method expects an exception, meaning that an exception being raised means the test passes, then use NUnit's ExpectedException attribute.  If you decorate a test method with the ExpectedException attribute, and the method does not throw an exception, the unit test fails.

NUnit's ExpectedException attribute informs NUnit that it should expect an exception when it executes the test method.  You can specify the exception type (using the .NET Framework's GetType() function), the exception name (same as the type, but you specify the name instead, making the code easier to write and easier to look at), the exception message (the ex.Message string returned on the exception), and more.  You can use any or all of the parameters you need to be sure the correct exception was thrown.  You may also specify a UserMessage that NUnit should report to help the person running the test understand why the test failed.

<Test()> _
<ExpectedException(ExceptionName:="System.ArgumentException", _
    ExpectedMessage:="The LogText parameter was either empty or Null.")> _
Public Sub Test_ApplicationLog_WriteLog_VerifyParm_Nothing()

    Dim strValue As String

    strValue = ApplicationLog_WriteLog(Nothing)

End Sub

In the example above, the name and message of the expected exception are specified, along with an informational message to the tester about the exception.  Also notice that since an exception is expected when the ConfigurationCache_Read_String method is called, there is no need to use one of the normal assert methods.

Write Code That Is Easy to Test

This is a personal impression, but I think when you find it difficult to write good unit tests for classes and methods, this is a reflection of the quality of the code itself.  It may not be broken down into methods to perform a single discrete task, or there may be a tremendous amount of 'state' that is required to be present to test a method (such as constructing a complex set of objects).

In other cases, your classes are very tightly coupled to other classes, making it difficult to for one to operate properly without the other. Find ways to make the connection between these classes more loosely coupled. This will allow you to replace objects that are difficult to fabricate with mock versions that do nothing more than satisfy the needs of the unit test.

In some cases, there's not much you can do about these problems.  However, take a moment to look at your code and decide how large the methods are, and if breaking them down into smaller bits of functionality might help to make writing unit tests easier.

Don't Ignore Private and Friend Methods

The bulk of the code in a well-written class is probably hidden inside Private and Friend scoped methods. Don't ignore these methods, test them.

The recommendation to test Private and Friend methods begs the question: how do you test those methods when the test code is in a separate assembly? Recall, one of my theories is that good testing is more important than perfectly ripe bowls of encapsulation. I am willing to sacrifice encapsulation in the name of better and more efficient testing. The answer is to change some of your Private methods to Friend methods, and apply a .NET Framework technique that allows you to expand the Friend scope to include another assembly. See my post from Feb 13, 2008 on how to do this. I understand how naughty this sounds, how unorthodox this sounds, but it is a reasonable trade-off to get solid unit tests for your projects.

Continuous Production

I was intrigued by a recent article I read on InfoQ about a process known as Continuous Production. As the name implies, the idea is that rather than using a controlled series of incremental deployments to your production platform every month, or every week, you build a process that enables you to deploy software to production daily, or even continuously. What intrigued me wasn't so much that the idea was novel. It struck a raw nerve that made me consider what processes and controls must be in place for a company to streamline its processes sufficiently to enable high-quality deployments of high-quality quality software continuously. Releasing software to production every 30 minutes (as in the case of Flickr) is a compelling challenge to any software development process. Paul Duvall's article on testearly.com referenced by the InfoQ article above shed some light on the details of this process.

Over the past year, I’ve been advocating a much more intensive criteria for Continuous Integration with my peers and customers, which is more like “Continuous Production” meaning you can produce production-ready software on a daily or even a continuous basis. Effectively, we’re talking about extending the Continuous Integration model into all environments (Test, Stage and Production), not just the development environment.

Before discussing the process itself, consider the barriers to such a process. First, I believe any barrier that would keep you from adopting such a process probably stems from an unhealthy set of, or lack of, existing processes. The ability to adopt a process of continuous production while maintaining a high quality product is the ultimate measure of a software development process. It requires a high degree of maturity in all the processes from compilation, testing, deployment, to final deployment verification. Even in development shops where continuous production isn't desirable, the goal of being able to support continuous production is a worthy one; it provides a framework to develop a healthy set of processes for software development.

Obviously, applications deployed on the web are the best candidates for continuous production. The software is deployed to a controlled environment and a rolling upgrade can normally prevent any noticeable downtime. However, in cases where software is downloaded and installed by end-users, or worse, in cases where it is centrally deployed and undergoes traditionally long deployment and test cycles, it isn't practical to deploy updates frequently. Even in these cases, however, it can still enable healthier internal processes if the compilation, testing, and building of final installation packages was completely automated.

Consider the some of the process requirements for continuous production.

Automated Source Code Compilation and Unit Test Execution

After checking a change into source control (you use a good source control tool, right?), the source should be compiled automatically and the appropriate unit tests should be executed providing immediate feedback to everyone involved on the status of the build.

Quality Assurance

To make this system, your QA group needs to work seamlessly with your development group. They should understand how to test the software without complex descriptions of how to test the specific change that was made. Better yet the QA group should use an automated regression test to verify the correctness of the software. All manner of tests, including unit tests, regression tests, load tests, etc. should be run either automatically or very easily by the QA group.

Automated Deployments

I work in a web application environment, so my perspective is skewed toward server-side deployments. However, many of the same principles are equally applied to other project types. Once the testing has verified the quality of the software, you should be able to have the software automatically deployed to the appropriate servers. This step is considered very risky in many environments - great care should be taken to ensure a quality deployment.  Many unit tests, some regression tests, and other forms of deployment verification are available to verify that the software was deployed successfully. Same story - these verifications should be automated to reduce the chance of the task being forgotten or performed improperly.

I suggest that it is advantageous for development groups to adopt continuous production processes, especially when it seems more difficult to do so.  The barriers to adopting these processes are probably symptoms of broken or inefficient processes. Even if continuous production isn't desirable, consider the changes required to make it easier to update the software seamlessly, automatically, and often. In cases where there is concern for negative user reaction to frequent changes to the software, consider establishing an expectation of frequent updates and providing the ability to keep users abreast of the changes.  In cases where there is concern that such a process cannot produce quality software, consider the changes to your process to increase the quality in such an environment. In all cases, even if you don't plan to release the software to customers continuously, I suggest that your process (overall) will mature and enable you to produce higher quality software.

What is the biggest barrier that might keep your development group from adopting a policy of Continuous Production?  Make a list of those barriers, and then label it "Areas for Process Improvement".

How to Test Friend Methods from a Separate Assembly

In my most recent article covering VB9 and Visual Studio 2008, I mentioned a new feature of the .NET Framework version 3.5 that allows a class to be decorated with an attribute named "InternalsVisibleTo" that expands the Friend scope outside the current assembly to include another specified assembly. A reader of my article replied to let me know that I hadn't mentioned another feature provided in the .NET Framework version 2.0 and available inside Visual Studio 2005. I didn't know about this feature, so I am passing it along.

The feature I overlooked is an InternalsVisibleTo that can be applied to an assembly, expanding the Friend scope of all classes expand to include another specified assembly. I was excited about the ability to expand a single class's Friend scope, but I am even more excited that I can do it for an entire assembly. This feature is invaluable in good unit testing, and the ability to open an entire assembly with one attribute makes it easier to manage.

Keep in mind a simple rule: if the assembly you want to expose Friend methods from is strongly named (call it CodeAssembly), then the assembly you are exposing these methods to (call it TestAssembly) must also be strongly named. Remembering this will save you a hour of troubleshooting why the Friend methods are not appearing as expected in IntelliSense from TestAssembly.

Inside the CodeAssembly project, add the following line of code - nowhere in particular works great. Once this code is added, all the Friend types from CodeAssembly are visible inside TestAssembly.

<Assembly:InternalsVisibleTo("TestAssembly, PublicKey=PublicKeyHere")>

Getting the public key of an assembly is not as simple as Right-Click, Properties, Version tab - Details tab in Vista. Use the strong name tool, sn.exe as shown below.

C:\Development\TestAssembly\bin>sn -Tp TestAssembly.dll

Microsoft (R) .NET Framework Strong Name Utility  Version 2.0.50727.42
Copyright (c) Microsoft Corporation.  All rights reserved.

Public key is
00240000048000009400000006020000002400005253413100040000010001006fd1b6f542259a
b2bb4eabb9907f7f997e502b2d64757f4e33bc303c921a57b71d124ea3af1ce2321c8c9f8f372a
5b9c87138b3c09b796037696846ae09e4accac8317f7be1200a5751060794708a0f9184241a502
1c0aa24b279e5bcacc4ec15df4e01fde7761e445005adeb79e8754d9c29b5528dd02c2598cd9f8
99b26cb1

Public key token is 3aa62adff42294b1

Copy the text of the public key into a class inside CodeAssembly as shown below:

'Filename: ProjectLibrary.vb

<Assembly:InternalsVisibleTo("TestAssembly, PublicKey="002400000480000" & _
"09400000006020000002400005253413100040000010001006fd1b6f542259ab2bb4eabb" & _
"9907f7f997e502b2d64757f4e33bc303c921a57b71d124ea3af1ce2321c8c9f8f372a5b9" & _
"c87138b3c09b796037696846ae09e4accac8317f7be1200a5751060794708a0f9184241a" & _
"5021c0aa24b279e5bcacc4ec15df4e01fde7761e445005adeb79e8754d9c29b5528dd02c" & _
"2598cd9f899b26cb1")>

If CodeAssembly is not strongly named, then the syntax of the InternalsVisibleTo attribute is simplified because the public key is not required.

'Filename: ProjectLibrary.vb

<Assembly:InternalsVisibleTo("TestAssembly")>

New Article: Fall In Love with Visual Basic All Over Again in Visual Studio 2008

Article: Fall In Love with Visual Basic All Over Again in Visual Studio 2008

I have been using Visual Basic for longer than I care to remember. Each version is better than the last, and the latest release is no exception.  The combination of VB9 running inside Visual Studio 2008 makes a powerful development environment. My latest article was published on DevX last week and covers my favorite features of Visual Basic 9 and Visual Studio 2008.

I was a little more lazy than usual about posting to my blog about this article, but I received quite a bit of email regarding this article. The bulk of the mail responded to my judgments about some of the new features. Some people didn't like that I even made judgments (sorry, but get used to it) while others didn't agree with my judgments (if my email responses didn't help, let me know). Many said they agreed with me and just wondered why I didn't include more LINQ samples.

Here we go. I try to let people know when I think something they are doing is stupid or when I think they are at risk of unwittingly doing something stupid. In the case of VB9, I am warning people about the latter problem: VB9 allows some seemingly freakishly lazy modes of coding, which I don't like.  The article does a pretty good job of pointing them out, so I will not elaborate here. Many who didn't seem to mind me judging VB9 just didn't agree that I don't like the relaxed nature of how VB9 treats type declarations. I shutter to imagine going back to a BASIC language where we don't explicitly declare types. I consider the the choice to NOT explicitly provide a type for a variable a shortcut that will cause undue confusion later during the development process - I don't like that.  It just doesn't seem to be the sort of coding practice I would expect from a true Craftsman. For those that think I should have included more LINQ examples, type "VB.NET LINQ" into Google and see where it takes you.

Some of the readers even pointed out that many of these features were added explicitly to support features in LINQ. I made that point in the article. Out of the context of LINQ, however, some of these features just add code smell. I don't like that.

If you have a different idea, let me know.