Thycotic Software Ltd. | Team Blog

The Benefits of Pair Programming

jfrankel — Thu, 04 Feb 2010 20:09:16 +0000

February 4th | 2009

The Benefits of Pair Programming

The Agile practice of Pair Programming is one of the more controversial development techniques within the software development community. The controversy lies in the question of how two programmers working together on the same code can be more productive than the same two programmers writing code individually. The determining factor in answering this question is simple – more lines of code do not equal more productive software development.

Case studies have been conducted, the experts have weighed in, and the results are unequivocal: the benefits of Pair Programming can result in significant advantages for an organization developing software.

The success or failure of software is dependent on its quality, and Pair Programming directly improves quality in numerous ways. When two developers work together design pattern quality improves as the pair develops short, simple, and easy to maintain code with fewer bugs. Bugs are a major quality concern in software development; with two sets of eyes writing the code, more mistakes are caught, thereby decreasing the cost of development. Bugs found late in the development process are often costly to fix. Finding software defects early prevents and helps deter difficult problems down the road. Complexity often arises in programming, and two minds working to solve a problem together can see more options and draw conclusions more quickly than one.

Teams implementing Pair Programming also experience the benefits of increased team morale, worker discipline, and improved time management. Individuals on the team put more effort into writing good code, creating an atmosphere of collective code ownership.

Our team has been practicing Pair Programming for years, so I set out to get some input from them. Thycotic team programmer, Bryant Smith, has been Pair Programming daily for over five years. Bryant commented “The code’s intention is clearer, it self-documents. What might be clear to me is not necessarily clear to others; assumptions are uncovered and more clearly stated. This is true with the unit test code as well as test coverage. When my pair is coding I often think outside the box about ‘what if’ scenarios. This extra test coverage further documents the code’s intention.”

Another team lead member, Tucker, thought “A major benefit of Paired Programming is knowledge sharing. It breaks down code complexity across the dev team and quickly brings new people up to speed.” Tucker is currently working with 3 other developers—forming two programming pairs every day.

Risk for management is also decreased as knowledge is spread around the team, pairs are rotated, and team members come and go. The benefits of Pair Programming to the development team, management, and the organization are significant as the software development process proves to be on time, within budget, and seemingly effortless for a Pair Programming team.

Katie McCroskey is a Marketing Manager at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product. On Twitter? Follow Katie

Managed code isnt always the best solution

jfrankel — Fri, 15 Jan 2010 18:38:56 +0000

January 15th | 2009

Managed code isn’t always the best solution

Managed code is cool. In fact most of the code I write at work is managed code in C#. In one case our product team needed to write some unmanaged code as a Log On credential provider. Throughout Microsoft’s documentation on this, it was strictly mentioned that Managed Code is a bad idea. Well, why? It’s not just for performance.

.NET inherently was designed to be version-independent, meaning an application that targets the .NET 1.1 Framework CLR cannot run on 2.0, and 2.0 CLR projects will not be able to run on the 4.0 CLR, when it’s released. This is why extensions for Windows can rarely be written in managed code. It is possible to write a Log On credential provider in managed code since .NET can be exposed to COM and vice-versa. It will even work. But assuming you write a credential provider that is built in .NET 2.0, and another vendor tries to provide one in .NET 1.1, or any version other than 2.0, the logon.exe process will attempt to load both versions of the .NET Framework. This will ultimately fail and the user will not be able to boot without going into safe mode.

The same applies to context menus for Explorer and Add-Ons Internet Explorer. They can both be extended using Managed Code, but all it takes is a version conflict to kill them off.

So, as much as we love our managed code, there are scenarios where it isn’t a good idea to use it. Ultimately, if you are trying to extend any application that uses COM (or any other unmanaged code solution) as its extension method, rather than Managed Code, then stick with Unmanaged Code.

Kevin Jones is a Team Lead at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product. On Twitter? Follow Kevin

Debugger Friend or Foe

jfrankel — Thu, 07 Jan 2010 16:49:26 +0000

January 7th | 2009

Debugger: Friend or Foe

The debugger is something that most developers get familiarized with pretty quick. I am not really even going to bother explaining it as it’s such a ubiquitous tool. We all use it for one main reason though: something doesn’t work the way we expect.

I would suggest that it only be used as a last resort. The debugger, while effective and powerful, can lead you down rabbit holes—even if you are familiar with how debuggers work. Rather, start by writing a failing unit test that demonstrates the issue, and proceed from there. After all, if you are in the debugger it’s probably because something isn’t working right. And if something isn’t working right, shouldn’t you have a failing test?

Sometimes though, a failing test is just not enough. In these cases the debugger is a quick way to figure out how something works. It’s easier than sprinkling your code base with calls to Debug.WriteLine. The debugger also allows you to do cool things like modify where it is in the stack execution.

Let’s look at a piece of code. It’s pretty trivial:

class Program
{
    private static int _aNumber = 0;

    static void Main(string[] args)
    {
        int incrementedNumber = GetANumberIncremented();
        System.Console.WriteLine(incrementedNumber);
        System.Diagnostics.Debugger.Break();
    }

    static int GetANumberIncremented()
    {
        return ++_aNumber;
    }
}

Paste this into Visual Studio and hit F5 to make it go. The 3^rd line of the Main method should cause you to break into the debugger. This is the same as setting a breakpoint. I only used it so I wouldn’t have to explain where to put a breakpoint. Using the mouse, hover over incrementedNumber. Hopefully you’ll get 1, like I did.

Now let’s try something interesting: Select GetANumberIncremented() including the parenthesis, but not the semicolon. Right-click on the selection and use a familiar tool, Quick Watch. Now we get 2. What gives?

It may be obvious to some, but not to others. The debugger is, in most cases, invasive. Quick Watch is handy, but as we did it on a method we forced the debugger to re-run the method GetANumberIncremented. It’s re-evaluating the stack. With the Quick Watch window open, click “re-evaluate.” Now we get 3. Again, and we get 4, and so on. It’s screamingly obvious in this example, but imagine if it was in a 3^rd party assembly and GetANumberIncremented was a public method. We would have no idea what the method was doing. This is a pretty tame case as we’re only incrementing a number. But you can probably imagine instances where this could easily put an application into a state it wasn’t intended for.

Another thing you can get bitten by on the debugger? First chance exceptions. If you aren’t careful the debugger might tell you an exception is being thrown when it is actually being handled gracefully somewhere else. So when the time comes to run the application normally, it will work just fine.

Overall the debugger is an invasive tool that can lead you to some dead ends if you’re not careful.

I wouldn’t go so far as to say the debugger is evil. But I avoid it when I can and opt for unit tests instead. A unit test runs the code just as if it was being used by the application—or at least it should!

Dealing with Nullable Types and IIf in VBNET

jfrankel — Fri, 01 Jan 2010 19:09:49 +0000

December 29th | 2009

Dealing with Nullable Types and IIf in VB.NET

Here’s a tip that might bite some C# developers getting their feet wet with VB.NET. In fact, I got bit by this one recently, and it didn’t help that it was knee deep in COM. Let’s examine this harmless looking C# statement:

int? someSpoon;
string helloValue = someSpoon.HasValue
    ? "The spoon is " + someSpoon.Value
    : "There is no spoon";

This is a pretty typical use of the ternary operator. If someSpoon has a value, then the helloValue is “The spoon is ”, if it doesn’t have a value, it is “There is no spoon”. This is a safe use because someSpoon.Value will not be evaluated unless the condition is true.

VB.NET does not have a built-in operator similar to this, however it does have a function called IIf. Its syntax is this:

Function IIf(ByVal expression As Boolean, _
    ByVal truePart As Object, _
    ByVal falsePart As Object)

We’d be tempted to write something like this with our VB.NET IIf:

Dim someSpoon As Integer?
IIf(someSpoon.HasValue, _
    "The spoon is " & someSpoon.Value, _
    "There is no spoon")

But wait! We just introduced a bug. Take a minute to figure it out.

Got it? OK let’s see if we agree. The problem is that as IIf is just a plain function, someSpoon.Value will always be evaluated. If you call .Value on a nullable type without a value, you’ll get an exception. This is because the Value must be resolved before it is passed into IIf. C# doesn’t exhibit this behavior because the true part is completely ignored.

So, what’s the fix?

You might be tempted to switch to an If/Else statement but I chose to write my own IIf using lambdas. It’s called SIIf—S is for safe—and it doesn’t exhibit this behavior. Instead of passing in the Value, we pass in a function that will be invoked to get the Value if it’s needed.

Here’s the source for it:

Public Function SIIf(Of T)(ByVal expression As Boolean, _
         ByVal trueExpression As Func(Of T), _
         ByVal falseExpression As Func(Of T))
    If expression Then
        Return trueExpression()
    End If
    Return falseExpression()
End Function

I also added generics—another annoyance to VB.NET developers who use Option Explicit. Here’s how it would be used:

Dim someSpoon As Integer? = Nothing
Dim result As String = SIIf(Of String)(someSpoon.HasValue, _
            Function() "The spoon is " & someSpoon.Value, _
            Function() "There is no spoon")

All we really have to do is remember to put Function() before the 2nd and 3rd parameters. This prevents our exception from happening because Value is only ever invoked if the expression is true by the lambda.

Update: As some of you have already pointed out, this functionality is built into the .NET Framework 3.5 using a three argument If statement, which I overlooked. I would recommend using this over my own solution if possible.

Cool Things to Do with Dynamics in dotNET 4

jfrankel — Mon, 21 Dec 2009 15:44:25 +0000

December 21st | 2009

Cool Things to Do with Dynamics in .NET 4.0

In An Overview of C# 4.0 I discussed some of new features in C# 4.0. One thing that I didn’t cover was the dynamic keyword.

Put simply, something marked as dynamic does not have any compile-time enforced semantics. Instead, all members of the instance are resolved at runtime by the Dynamic Language Runtime (DLR). Here is a simple example:

static void Main(string[] args)
{
    dynamic int1 = 1;
    dynamic int2 = 2;
    dynamic result = int1 + int2;
    Console.WriteLine(result);
}

This, as expected, will print 3. However, the operator + and what int1 and int2 really are is resolved at run time. I’ll demonstrate this using the following code (which looks like it shouldn’t compile, but actually does):

static void Main(string[] args)
{
    dynamic int1 = 1;
    dynamic ex1 = new Exception("Oops!");
    dynamic result = int1 + ex1;
    Console.WriteLine(result);
}

This normally wouldn’t compile since an int type and the Exception type do not have a + operator. Regardless, this code compiles just fine. It’s only at runtime that we get an error:

Unhandled Exception: Microsoft.CSharp.RuntimeBinder.RuntimeBinderException: Operator ‘+’ cannot be applied to operands of type ‘int’ and ‘System.Exception’

So, what use is this? Why don’t we just use the real types rather than dynamic? Possible scenarios for using dynamic are: when we don’t know what the type is; or when it came from an odd place, such as reflection. If a type is resolved via reflection, we can treat it as a dynamic and not worry about calling “Invoke” or “GetProperty” on it. The same goes with COM Interop. If a complete wrapper is missing then we can declare it as dynamic and continue to use it without significant complex code.

But the most interesting use of a dynamic is declaring your own. Enter the DynamicObject base type. This allows us to tell the object how to behave at run time and instruct it how to handle the resolution of properties and methods. We can build some very powerful tools with this.

I’ve done some neat things with PowerShell, and the thing that particularly amazed me was how easy it is to consume and manipulate XML. Here’s a PowerShell snippet that loads an XML file:

$xmlConfig = New-Object XML

$xmlConfig.Load(”Some XML Path”);

$backup = ($xmlConfig.configuration.appSettings.add | where {$_.key –eq ‘BackupEveryInMinutes’}).value;

This XML file looks something like this:

<configuration>
    <appSettings>
        <add key="BackupEveryInMinutes" value="1440" />
    appSettings>
configuration>

$backup will be assigned to 1440. I like the way you can just access the properties off of the $xmlConfig as if they were always there. In C# and .NET previously, this would have been impossible. However, using the DynamicObject, we can build one that does. Let’s start!

Let’s make a class that derives from DynamicObject.

public class DynamicXml : DynamicObject
{
}

An important concept in this is being able to override TryGetMember. This is how we tell the DLR how to dynamically resolve something.

public class DynamicXml : DynamicObject
{
    public override bool TryGetMember(GetMemberBinder binder, out object result)
    {
    }
}

· binder – this is what is attempting to be bound, or resolved. It can tell us what the DLR is trying to figure out, such as a property name

· result – to tell the DLR the value of what is being resolved.

· return – if the dynamic was successfully resolved. In our case, we will return false if the XML document doesn’t contain a node. This will cause the DLR to throw an exception if the return value is false.

First we must load our XML document. Let’s use an XmlDocument (as opposed to the newer XDocument) as an example. The constructor will take an XmlNode since XmlDocument inherits from XmlNode.

So the usage scenario for our code will be something like this:

XmlDocument document = new XmlDocument();

document.Load(”pathtoxml.xml”);

dynamic dynamicXml = new DynamicXml(document);

string value = dynamicXml.configuration.appSettings.add.value;

The properties being used on the dynamicXml are the nodes of what we are trying to access. We can check the binder to see what property is being resolved. We can recursively return our dynamic object to continue resolution, too. The final result looks like this:

using System.Xml;
using System.Collections.Generic;
using System.Dynamic;

namespace CSharp4
{
    public class DynamicXml : DynamicObject
    {
        private readonly XmlNode _node;

        public DynamicXml(XmlNode node)
        {
            _node = node;
        }

        public override bool TryGetMember(GetMemberBinder binder, out object result)
        {
            result = null;
            XmlNodeList nodes = _node.SelectNodes(binder.Name);
            if (nodes.Count == 0)
                nodes = _node.SelectNodes("@" + binder.Name); //Check and see if it's an attribute.
            if (nodes.Count == 0)
                return false;
            if (nodes.Count == 1)
            {
                XmlNode node = nodes[0];
                result = GetContent(node);
            }
            else
            {
                List results = new List();
                foreach (XmlNode node in nodes)
                {
                    results.Add(GetContent(node));
                }
            }
            return true;
        }

        private dynamic GetContent(XmlNode node)
        {
            if (node.NodeType == XmlNodeType.Attribute)
                return node.Value;
            if (node.HasChildNodes || node.Attributes.Count > 0)
                return new DynamicXml(node);
            return node.InnerText;
        }

        public override string ToString()
        {
            return this;
        }

        public static implicit operator string(DynamicXml xml)
        {
            return xml._node.InnerText;
        }
    }
}

Sure, it’s not perfect. It could handle collections better instead of returning a list and support for types other than a string. And this isn’t the best solution either. It’s a nice syntax but using the XDocument and LINQ is a better alternative. However I think it’s a great use for dynamics.

Do you agree? Let us know. Based on your feedback, we may include another installment on this subject—with improvements.

Are Extension Methods a Code Smell

jfrankel — Thu, 10 Dec 2009 15:12:23 +0000

December 10th | 2009

Are Extension Methods a Code Smell?

The extension method is a handy feature that came in C# 3.0/VB.NET 9.0 and .NET Framework 3.5. Quite simply, it allows the appearance of extending a class and giving it additional functionality without actually having to modify that class. Here’s an example:

class OtherClass
{
    public void Foo()
    {
        User user = new User();
        user.DisplayUserName();
    }
}

public class User
{
    public string UserName { get; set; }
}

public static class Extensions
{
    public static void DisplayUserName(this User user)
    {
        string userName = user.UserName;
        //Display userName
    }
}

In the “Foo” method we are calling a method “DisplayUserName” which appears to belong to the User class, but is actually a static method in a completely different location.

Extension methods are currently present in the .NET Framework. Their most notable use is in LINQ. All of LINQ’s operators are implemented as an extension method on the IEnumerable interface.

But can they be a code smell? In most cases I would say yes, for several reasons.

Firstly, if it is something simple, why not just implement it in the object? In the case of the User, it may not be his responsibility to display to the interface. Therefore, to avoid violating the Single Responsibility Principle, it would be better to keep the functionality out of the User class. However, this turns something that might have been better as a service into a concrete static implementation, and this could be difficult to test by mocking. By creating a service and adding it to a container, we have a more appropriate solution.

Secondly, new developers—or even experienced ones—might be confused. It’s impossible to tell just by looking at the code if it’s an extension method or an actual method on the object. If you have multiple extension methods the code can be extremely difficult to read. It may even introduce bugs or make code reviews labor intensive.

A third scenario where I see extension methods as problematic is in the fact that they seem to be instance-based. That is, they have the appearance of accessing a method on an instance of an object. In actual fact, the compiler is just translating it to a normal static method. A developer might be tempted to do something like this:

public static class Extensions
{
    private static string _userName;
    public static void DisplayUserName(this User user)
    {
        _userName = user.UserName;
        DoDisplay();
    }

    public static void DoDisplay()
    {
        //Do something with _userName
    }
}

This is perfectly legal and working code, but by introducing something outside of the scope that is static, and not tied to an instance of User, we’ve introduced thread safety issues. I believe this is one of the reasons Extension Properties were not introduced—it’s an invitation for this sort of code.

Extension methods can be a slippery slope. While they may have been introduced for a perfectly valid and specific reason, there’s a broken window effect: if there’s one broken window in the neighborhood, it’s an invitation for other windows to be broken too. There’s an obvious invitation for extension methods to be written in such a way that if one extension method is written, then you’re inviting other people to use them in possibly careless ways.

Are they useful in any context at all? Yes, I believe they are. Usually for extending sealed classes for which you don’t have the source. A common pattern is to make string helpers as extension methods. Here’s an example:

class Program
{
    static void Main(string[] args)
    {
        string sample = "the quick brown fox jumped over the lazy dog";
        string titled = sample.ToTitleCase();
        //titled will be "The Quick Brown Fox Jumped Over The Lazy Dog"
    }
}

public static class StringExtensions
{
    public static string ToTitleCase(this string s)
    {
        return System.Globalization.CultureInfo.CurrentUICulture.TextInfo.ToTitleCase(s);
    }
}

This might be an acceptable use of an extension method. We are extending a sealed and well-known class “string” and giving it additional functionality.

I could also see it working, on owned-code, with helper methods in unit test projects.

As far as organization goes, try keep extension methods down to a minimum, or none if possible. If you must use them, organize them in way that all the extensions are organized in Extensions static class. Or to take it step further, append the extension method with “Extension” so it is easily identified as one.

I think they are cool – but ultimately the possible negatives outweigh the positives.

What say you readers? Are extension methods a quick way to shoot yourself in the foot?

An Overview of C# 4.0

jfrankel — Tue, 01 Dec 2009 21:04:13 +0000

December 1rst | 2009

An Overview of C# 4.0

In Some Love for VB.NET 10 Too I focused on the new features in VB.NET 10. Now let’s take a look at C# 4.0. C# already has a strong, rich feature set which will, no doubt, be developed even further. I will discuss the actual C# 4.0 specification itself, not the .NET Framework, so the ever-popular “dynamic” keyword will be left for later. It deserves a post of its own.

COM Cleanup

This feature is pretty cool and it’s definitely going to get a big cheer from those who do a lot of COM automation. C# 4.0 has a few extra features that make working with COM a little easier. Word automation is a popular reason to use COM automation in the .NET Framework. Take this example which runs Word for you and adds a paragraph with bold text:

object oMissing = System.Reflection.Missing.Value;
var word = new Application();
word.Visible = true;
var doc = word.Documents.Add(ref oMissing, ref oMissing, ref oMissing, ref oMissing);
var paragraph = doc.Content.Paragraphs.Add(ref oMissing);
paragraph.Range.Text = "Hello World!";
paragraph.Range.Bold = 1;
paragraph.Range.InsertParagraphAfter();
Console.ReadKey(true);

Something that immediately stands out is all those ref’s to oMissing. What is that? Simply put, C# doesn’t support optional parameters, but COM (and VB.NET) do. To indicate to the COM Callable Wrapper that you want it to be treated like “nothing” was passed in (as opposed to NULL) Missing.Value is required. In C# 4.0, that is no longer the case. Here it is in C# 4.0:

var word = new Application();
word.Visible = true;
var doc = word.Documents.Add();
var paragraph = doc.Content.Paragraphs.Add();
paragraph.Range.Text = "Hello World!";
paragraph.Range.Bold = 1;
paragraph.Range.InsertParagraphAfter();

Much better! What’s actually happening here is just syntactic sugar. The C# compiler automatically adds a ref to Missing.Value for you, which is easy to see with a tool like Reflector. If you want to pass in Missing.Value automatically from some parameters, and actual objects for others, read the section on named parameters farther down in this blog. In addition to adding Missing.Value for you, you can now—optionally—not pass a parameter by reference even if the signature declares it as ref.

A new addition to the C# 4.0 language is support for indexed properties. For example, let’s look at some code that adds a bookmark to the document:

object oMissing = System.Reflection.Missing.Value;
object endOfDoc = "\\endofdoc";
var word = new Application();
word.Visible = true;
var doc = word.Documents.Add(ref oMissing, ref oMissing, ref oMissing, ref oMissing);
var paragraph = doc.Content.Paragraphs.Add(ref oMissing);
paragraph.Range.Text = "Hello World!";
paragraph.Range.Bold = 1;
paragraph.Range.InsertParagraphAfter();
var bookmark = doc.Bookmarks.get_Item(ref endOfDoc);
bookmark.Range.Text = "Goodbye World!";

bookmark is declared as doc.Bookmarks.get_Item(). Bookmarks is actually a property that supports indexing. C# 3.0 doesn’t support it. In C# 4.0 we can now index into it:

object oMissing = System.Reflection.Missing.Value;
object endOfDoc = "\\endofdoc";
var word = new Application();
word.Visible = true;
var doc = word.Documents.Add(ref oMissing, ref oMissing, ref oMissing, ref oMissing);
var paragraph = doc.Content.Paragraphs.Add(ref oMissing);
paragraph.Range.Text = "Hello World!";
paragraph.Range.Bold = 1;
paragraph.Range.InsertParagraphAfter();
var bookmark = doc.Bookmarks[endOfDoc];
bookmark.Range.Text = "Goodbye World!";

Neat. Does this mean C# 4.0 now supports indexable properties? Unfortunately not. As of now it can only consume them, not declare them—but it’s a step in the right direction. Also notice that we didn’t pass the endOfDoc by reference. With COM, you no longer have to pass an item by reference if you prefer not to. This only works on COM wrappers and not regular .NET managed code.

This brings us to the next feature of COM: embedded interop assemblies. A problem that COM presents for some developers, which .NET developers have to deal with when working with COM, is versioning—or making sure that the required interop wrapper is even installed. In .NET 4.0, the compiler will automatically embed your COM interop assemblies into your application if you simply right-click the reference and hit properties. This will prevent your compiled application from referencing the assembly. Instead, it will contain its own types. This ensures that your application is always using the same interop wrapper.

So our C# 3.0 code went from this:

object oMissing = System.Reflection.Missing.Value;
object endOfDoc = "\\endofdoc";
var word = new Application();
word.Visible = true;
var doc = word.Documents.Add(ref oMissing, ref oMissing, ref oMissing, ref oMissing);
var paragraph = doc.Content.Paragraphs.Add(ref oMissing);
paragraph.Range.Text = "Hello World!";
paragraph.Range.Bold = 1;
paragraph.Range.InsertParagraphAfter();
var bookmark = doc.Bookmarks.get_Item(ref endOfDoc);
bookmark.Range.Text = "Goodbye World!";

To This:

var word = new Application();
word.Visible = true;
var doc = word.Documents.Add();
var paragraph = doc.Content.Paragraphs.Add();
paragraph.Range.Text = "Hello World!";
paragraph.Range.Bold = 1;
paragraph.Range.InsertParagraphAfter();
var bookmark = doc.Bookmarks["\\endofdoc"];
bookmark.Range.Text = "Goodbye World!";

That’s cleaner now, huh?

Covariance and Contra-variance

This new feature was added to C# 4.0 to help with generics. In today’s C# code, all generics are invariant. For example, given the type SomeType and SomeType let’s assume that K is a superclass of T. SomeType and SomeType will not have any inheritance relationship at all even though T and K have a relationship. Why can’t we do this?

Ensuring type safety. In this example, allowing this to occur falls short:

List<string> stringList = new List<string>();
List<object> objectList = stringList;
objectList.Add(new object());

Even though string inherits from object, we can’t assign it to a list of objects. Line three is a good example of why not: our objectList would really be a list of strings at run time, then blam! we add an object to it. Delegates have the same problem.

private delegate T Callback();
public void DoCallback()
{
    Callback<object> callback = new Callback<string>(CallbackHandler);
}

private string CallbackHandler()
{
    //Implementation Omitted
}

You would assume that this is OK. After all, why shouldn’t a callback of object be assigned to a callback of string if string always implements object? Well…for the same reason as the List.

Variance to the rescue! Where have we seen variance before? Arrays. This has always compiled:

object[] actuallyStrings = new string[] { "Hello", "World" };
actuallyStrings[0] = new object();

This will throw an ArrayTypeMismatchException, but the compiler allows it. With generics, we can do this in a way that is always compile time safe. If a generic interface or generic delegate has a reference type T as its type parameter and does not have any method or member that takes in a parameter of type T, we can declare it to be covariant on T. On the other hand, if that interface or delegate does not have any method or member that returns T, we can declare it to be contravariant on T.

NOTE: That description was taken from Buu Nguyen’s post on Code Project. It’s an elegant description and kudos to him for thinking of it.

Thus, in C# 4.0 we can declare on our delegate that T is out as we never accept a type of T.

private delegate T Callback<out T>();
public void DoCallback()
{
    Callback<object> callback = new Callback<string>(CallbackHandler);
    object result = callback();
}
private string CallbackHandler()
{
    return "Hello";
}

result in this case, is an object and rightfully so. Since T can only be an output type, and we know string always inherits from object, the compiler can safely assume the implicit cast.

So why is this a feature in C# 4.0? As Buu points out, this feature has actually been available to the CLR since generics were introduced in .NET 2.0, though none of the languages supported it.

Named and Optional Parameters

Named and default parameters partially complete the COM interop enhancements—something that many consider long overdue. With named parameters, you can specify the order in which your parameters are declared. This also comes into play with option parameters. Here is an example:

static void Main(string[] args)
{
    PrintTwoStrings(stringB: "World", stringA: "Hello");
}

static void PrintTwoStrings(string stringA, string stringB)
{
    Console.WriteLine(stringA);
    Console.WriteLine(stringB);
}

Notice that I explicitly declared the parameters, even out of order. Likewise, I can make stringB optional with a default. This code will produce “Hello Japan”

static void Main()
{
    PrintTwoStrings("Hello", stringB: "Japan");
}

static void PrintTwoStrings(string stringA, string stringB = "World")
{
    Console.WriteLine(stringA);
    Console.WriteLine(stringB);
}

Even though stringB has a default, we explicitly set it to Japan. If we were to omit the stringB in the call to PrintTwoStrings:

static void Main()
{
    PrintTwoStrings("Hello");
}

This will print “Hello World”. You can have multiple optional parameters, but they must all be placed after the required ones. This is to avoid confusion with overloads.

This also works with COM. If you have a COM method that takes an exceptional number of arguments, and you want to pass in Missing.Value for all but a few, you can use named parameters and it will default all of the others to Missing.Value.

It’s worth noting that C# and VB.NET are compatible with each other on named and optional parameters. VB.NET has actually supported both these features for years.

Some Love for VB.NET 10 Too

jfrankel — Tue, 24 Nov 2009 20:17:24 +0000

November 24th | 2009

Some Love for VB.NET 10 Too

At Thycotic we typically work with C#. In fact, 90% of the code that we write is written in C#. However, it’s no secret that I am a VB.NET Fanatic. Generally, C# developers don’t look kindly on VB.NET developers because they consider VB.Net an inferior language. But I particularly like how it’s implemented in Visual Studio.

One of the criticisms of VB.NET is that is that some of its features are not up to par with C#. That’s an indisputable fact, I’ll admit. But a lot has been done to the upcoming VB.NET 10 for the .NET Framework 4.0, to bring VB.NET closer to C# for syntactic sugar.

Auto Properties

C# 3.0 introduced a really cool feature called automatic properties. Essentially, the C# compiler emits a backing field for you so you don’t have to do it yourself. This feature will be available in VB.NET 10. Its syntax looks like this:

Public Property MyAutoProperty As Object

That’s it! It’s just that one line; even simpler than C#. Of course you can decorate it with ReadOnly or WriteOnly so that it only has a getter or setter. The one thing it can do that C# 3.0 or 4.0 doesn’t let you do, however, is auto-initialize it.

Public Property MyAutoInteger As Integer = 10

MyAutoInteger will default to 10. The VB.NET compiler will secretly put this in the constructor or static constructor if the property is static, similar to the way fields can be auto-initialized.

Subs as Lambdas

C# 3.0 introduced a rich syntax for Lambda expressions, and VB.NET followed suit to support LINQ. One limitation is that the passed in delegate must be a function that returns a value, and not a sub. Consider the following:

Sub Main()
    DoWork(Sub(x) Console.WriteLine(x))
End Sub

Public Sub DoWork(ByVal work As Action(Of String))
    work("Some String Maybe")
End Sub

This simply wouldn’t compile in VB.NET 9 with Visual Studio 2008 because DoWork expects an Action delegate, which does not return anything thus making it a Sub, not a Function. I’m happy to say this will compile in Visual Studio 2010.

Collection Initializers

If you’ve ever had a List or Dictionary you wanted to quickly initialize with data for something simple like a unit test, C# made this easy with collection initializers. VB.NET 10 introduces a similar syntax to allow initializing a collection.

Dim helloWorld As New List(Of String) From {"Hello", "World"}

This will create a list with “Hello” and “World” in the list. Likewise for a dictionary:

Dim helloWorld As New Dictionary(Of Integer, String) From {{1, "Hello"}, {2, "World"}}

Good stuff!

Line Continuations

VB.NET was criticized for its reliance on line feeds to decide where the next statement block would start. Previously, to continue the statement to the next line you had to use an underscore to indicate that the next line was part of the current one. In VB.NET 10, that remains true. But VB.NET 10 allows flexibility while implicitly understanding where the underscore is. For Example:

Dim someNumber As String = "Hello" &
     "World"

Dim someNumber As Integer = 10 +
     40

Better COM Support & Indexed Properties

C# 4.0 introduced better handling for “missing” arguments in COM. VB.NET has had that for a while.

C# 4.0 has partial support for indexed properties to complete their COM enhancements. Sadly, C# only lets you consume them from COM, not declare them, which VB.NET has been able to do since its inception.

And let’s not forget that VB.NET has plenty of other language tools that C# lacks such as the “With” construct:

Dim builder = New StringBuilder()
With builder
    .Append("The ")
    .Append("Quick ")
    .Append("Brown ")
    .Append("Fox ")
    .Append("Jumped ")
    .Append("Over ")
    .Append("The ")
    .Append("Lazy ")
    .Append("Dog.")
End With

A contrived example, sure, but you get the idea of its usefulness. The “Handles” as a way of handling events is one of my favorite features. Of course C# developers will quickly to tell you that it’s a horrible syntax.

Conclusion

Both languages definitely have their advantages and disadvantages. Clearly though, VB.NET 10 has a lot of polish on it that cannot be ignored.

The Danger of Single Responsibility in Programming Continued

jfrankel — Thu, 19 Nov 2009 14:50:06 +0000

October 16th 2009 | David Cooksey

The Dangers of Single Responsibility in Programming Continued

The Dangers of Single Responsibility, Cont.

Doug Rohrer responded to my initial post on this topic with a good refactoring of the classes involved in a manner similar to the Strategy pattern. I agree with many of his points—the hypothetical developer certainly chose the wrong responsibilities; misunderstood the Single Responsibility Principle; and generally made the code a mess. That said, I believe that SRP is most definitely dangerous, not because of what happens when it is used correctly, but because of how easy it is to get it wrong. Misapplying the SRP can result in code that makes God objects look easy to maintain.

For clarity’s sake, I’ll go one step further—it is easy to misunderstand the sentence “A class should have only one reason to change” as a literal commandment to be applied at the line or method level. This results in disaster. One common example of how the SRP is misunderstood can be seen in this thread, where the poster asks if the SRP means that each class can have only one method. Luckily the poster received a good informative answer, but that is not the case for all developers learning about the SRP.

Here is an example of code modifications I have seen motivated by a desire to apply the SRP.

BEFORE

public class Check
    {
        private readonly IDataProvider _dataProvider;

        public Check(IDataProvider dataProvider)
        {
            _dataProvider = dataProvider;
        }

        public bool Run()
        {
            IBusinessObject data = _dataProvider.Get();

            if (data.Condition1 && data.Condition2)
            {
                string message = string.Format("Check failed, {0} {1}", data.Property1, data.Property2);
                throw new Exception(message);
            }
            return data.Property3 != data.Property4;
        }
    }

AFTER

public class Class
    {
        private readonly IDataProvider _dataProvider;
        private readonly ICheckErrorMessageProvider _checkErrorMessageProvider;

        public Check(IDataProvider dataProvider, ICheckErrorMessageProvider checkErrorMessageProvider)
        {
            _dataProvider = dataProvider;
            _checkErrorMessageProvider = checkErrorMessageProvider;
        }

        public bool Run()
        {
            IBusinessObject data = _dataProvider.Get();

            if (data.Condition1 && data.Condition2)
            {
                string message = _checkErrorMessageProvider.GetErrorMessage(data);
                throw new Exception(message);
            }
            return data.Property3 != data.Property4;
        }
    }
public class CheckErrorMessageProvider : ICheckErrorMessageProvider
    {
        public string GetErrorMessage(IBusinessObject data)
        {
            return string.Format("Check failed, {0} {1}", data.Property1, data.Property2);
        }
    }

Here, the developer asked the SRP question “Does this class have only one reason to change?” and got the answer “No, it could change because the formatted text could change, or because the logic could change”, and refactored the String.format out into its own provider. While harmless on the surface, this artificial separation of concerns does not add any value. The new class is so specific that it cannot be used anywhere else. In addition, the developer is likely to forget the CheckErrorMessageProvider name almost immediately, so if a text change is required he will most likely go to the Check class first, and then go the extra level down into the string provider in order to make the text change. In other words, the complexity of the code was increased for no benefit.

I believe that after correctness, simplicity is the most important programming principle. Simpler code is easier to understand when first read; easier to remember; easier to test; easier to refactor; and easier to add features to. Anything that adds complexity makes all of these tasks harder, especially on larger projects with many non-trivial sub-systems. Applying single responsibility at the line or method level diffuses business logic into a cloud of tiny classes that do next-to-nothing individually, and thoroughly obscure the logic they represent.

In conclusion, yes, the SRP is not dangerous when applied correctly. But then, most things are dangerous because of what happens when they are misused, and the Single Responsibility Principle is no exception. Handle with care!

David Cooksey is a Senior .NET Consultant at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product.

Want to join a team of top notch developers in the DC Metro area?

jfrankel — Thu, 19 Nov 2009 14:35:52 +0000

If you can solve the problem below, you may just have what it takes.

www.thycotic.com/codetest.txt

Please submit your solution with your resume and cover letter in an email to TDDjobs@thycotic.com

At Thycotic you’ll join a highly capable team of .NET developers who work on consulting projects for clients, and interesting products. Improve your agile development skills while working with a team of skilled, passionate developers. We’re hiring, and we’d love to hear from you!

Required:

You have the permanent legal right to work in the United States
You have excellent written and spoken English
You live, breathe, sleep, eat and drink C#
You have a strong understanding of Object Oriented principles, the .NET Framework, ASP.NET, relational databases and web application development
You are able to communicate effectively with co-workers and clients/customers
You are willing to work in the Washington DC Metro Area
You want to develop using Test Driven Development
You want to develop using Pair Programming

Why work at Thycotic:

Your ideas and opinions will be valued
You will continuously learn about new development techniques and technologies
We are a seasoned Agile .NET shop – not many of those around!
We are a Microsoft Gold Certified Partner
Follow a technical career path
Excellent benefits package
You will be working in the heart of Washington, DC

The AJAX UpdatePanel Is it your worst enemy?

jfrankel — Tue, 17 Nov 2009 15:49:01 +0000

November 17th 2009 | Kevin Jones

The AJAX UpdatePanel: Is it your worst enemy?

A recent code camp presentation I did sparked a debate about the “UpdatePanel” in AJAX. It’s no secret I believe it barely qualifies as real AJAX at all.

Most AJAX Frameworks have the UpdatePanel, and they are all similar in function, but I’m referring specifically to the one built into the Microsoft AJAX Framework. If you haven’t used AJAX before, it’s a useful tool to know and understand, but I wouldn’t recommend going much further than that.

The UpdatePanel is a control that simply designates its contents as an asynchronous callback, or “AJAX” call. Take a look at this ubiquitous example of updating a label with the servers time – sans a postback:

"server" ID="MyScriptMap" EnablePartialRendering="true" />
"server" ID="TimeUpdatePanel">
    
        "server" ID="TimeLabel" />
    
    
        "UpdateTimeButton" EventName="Click" />
    

"server" ID="UpdateTimeButton" OnClick="UpdateTimeButton_Click" Text="Update Time" />

The code behind it looks like this:

protected void Page_Load(object sender, EventArgs e) {
    SetTime();
}

private void SetTime() {
    TimeLabel.Text = DateTime.Now.ToString("G");
}

protected void UpdateTimeButton_Click(object sender, EventArgs e) {
    SetTime();
}

Pretty simple. When we click the UpdateTimeButton the label updates the time with the current time, and without causing a postback. Great, right? It’s easy and requires little knowledge of advanced AJAX functionality.

Then what’s the problem?

Firstly, it’s slow and cumbersome. Secondly, it’s not very flexible. Let’s use our trusty tool – Firebug – to see what the AJAX Framework is really doing under the covers.

Here’s the post:

MyScriptMap	MyScriptMap\|UpdateTimeButton
UpdateTimeButton	Update Time
__ASYNCPOST	True
__EVENTARGUMENT
__EVENTTARGET
__EVENTVALIDATION	/wEWAgLsi+LQBwLJqc+YBE5RYQbIcM8reKtnUnkQkSFh4HRl
__VIEWSTATE	/wEPDwULLTE4MzQ0ODUyNDIPZBYCAgMPZBYCAgMPZBYCZg9kF gICAQ8PFgIeBFRleHQFFDExLzgvMjAwOSA3OjEzOjEwIFBNZG RktDZ2TbaSW4PmU5zi/+6LeFQPeOA=

According to IIS, this is about 344 bytes. That’s a lot of data to post just to get a new date. So why did we need to post so much information?

The ViewState is the biggest part of this. ASP.NET fundamentally uses the ViewState for a whole slew of reasons, but in order for ASP.NET to process the request it needs the ViewState. There is also a field called the EventValidation. It contains information that ensures the ViewState hasn’t been tampered with. Since the EventValidation goes together with the ViewState, the AJAX call needs to send this information too. The rest of the data tells the ASP.NET runtime exactly what happened: which button was clicked; the name of the ScriptManager; etc.

That’s quite a bit of information. This is what the server sent back:

55|updatePanel|TimeUpdatePanel|11/8/2009 7:13:35 PM|128|hiddenField|__VIEWSTATE|/wEPDwULLTE4M

zQ0ODUyNDIPZBYCAgMPZBYCAgMPZBYCZg9kFgICAQ8PFgI

eBFRleHQFFDExLzgvMjAwOSA3OjEzOjM1IFBNZGRkbHZ0Gxr67

EAa/bNdqZfXC6A7YPA=|48|hiddenField|__EVENTVALIDATION|

/wEWAgLUiOrpBgLJqc+YBK3kgBaC8Pr4C9SpWuCECT5qBkBH|16|

asyncPostBackControlIDs||UpdateTimeButton|0|postBackC

ontrolIDs|||16|updatePanelIDs||tTimeUpdatePanel

|0|childUpdatePanelIDs|||15|panelsToRefreshIDs||TimeUpda

tePanel|2|asyncPostBackTimeout||90|20|formAction|

|UpdatePanelTime.aspx|

Much more than just a simple date and time. ASP.NET is sending back a lot of information in the form of a single string that is delimited by pipes, and parsing it. The total size of it as IIS is 556 bytes. After the third pipe you’ll find the content of the label we were updating – HTML and all. This is the essence of the UpdatePanel. It works by sending its content to the server and the server sends back new content. The client framework then replaces the old content with the new content.

Clever enough, but it can lead to poor performance and bad design.

Is there a different way?

Yes, and though it can be a little inconvenient you gain more in the long term.

AJAX is Asynchronous JavaScript and XML. Ironically, XML is becoming the less popular means of AJAX communication. JSON (pronounced Jason) has become the primary means of AJAX based requests. JSON is easy to work with, and more compact than XML. Here is a simple example of a key and value pair.

[
    {"Key":"The Key 1","Value":"The Value 1"},
    {"Key":"The Key 2","Value":"The Value 2"}
]

In .NET, it’s fairly easy to return JSON data from a web service so long as all of the types returned can be serialized. If we were to create a simple web service that returns the date and time, we could use JavaScript to request it from the web service. The Microsoft AJAX Framework includes a framework to make this much easier than hand coding requests from JavaScript. Here is what our web service method looks like:

[WebMethod]
[ScriptMethod(UseHttpGet = false)]
public string GetDateAndTime()
{
    return DateTime.Now.ToString("G");
}

It looks like a typical web service method, but notice the addition of the ScriptMethod attribute on the method. In order to wire AJAX into a web service, additions to the web.config file are required. Visual Studio 2008 will create a new web.config file with all of the correct settings in place to get you started with AJAX.

Calling it from our client side script is very simple:


    "server" ID="MyScriptMap" EnablePartialRendering="true">
        
            "~/DataSource.asmx" />
        
    


The Server's Time is: 
"MyTimeSpan"><%= DateTime.Now.ToString("G") %>
"button" onclick="updateTime();" value="Update Time" />

This is a page that updates a span—MyTimeSpan—with the response from what the web service returns. We do this by adding our web service as a ServiceReference. It generates a large piece of JavaScript that allows communication with the web service. From there, a few lines of JavaScript request the data from the service. When we click Update Time, we don’t actually send any data to the server. And why should we?

The response is as simple as this:

{”d”:”11/8/2009 8:22:26 PM”}

Just a date and a time that totals 28 bytes. The “d” is a little bit of magic that the AJAX Framework itself is using. However when you consume it you needn’t worry about the “d”. The AJAX Framework includes some metadata in responses to make things easier, such as type names, to allow for a typing system.

Sure there’s a little more coding to it but it allows a greater degree of freedom and functionality with AJAX. There are other frameworks that complement the Microsoft AJAX one, including jQuery which allows for easy manipulation of the DOM and finding controls.

My conclusion: avoid the update panel at all costs. It’s cheap and easy to implement, but it’s slow and doesn’t allow adequate flexibility.

Thycotic brings Password Management to SuperComputing 2009

jfrankel — Mon, 16 Nov 2009 21:22:10 +0000

November 163th 2009 | Jonathan Cogley and Dan Parker

Thycotic brings Password Management to SuperComputing 2009

Thycotic will be in Portland Oregon this week, exhibiting at SuperComputing from November 14th to the 20th . Stop by our booth (#354) to catch a peek of the iPhone version of Secret Server enterprise password management.

Are you responsible for end-user passwords? As to see a demo of our new self-service password reset application, Password Reset Server.

Come visit us to talk about password management or information security.

See you there!

Jonathan Cogley is the CEO of Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product. On Twitter? Follow Jonathan

Top 10 Takeaways from DevConnections Day Four

jfrankel — Fri, 13 Nov 2009 14:27:27 +0000

November 13th 2009 | Jimmy Bosse

Top 10 Takeaways from DevConnections Day Four

Whew! Day Four (officially day Three, but I am counting the pre-conference workshop)came to a close with the famous “64-bit Question” session where .NET Rocks! hosts Carl Franklin and Richard Campbell gave away some fantastic swag, like $10,000 Team System licenses. Too bad I didn’t win one. It was a great final day and I chose a well rounded set of sessions:

It’s the Least You Can Do: Improve Security in Your ASP.NET Applications by Rachel Appel
Understanding Efficient User Interface Design by Markus Egger
Performance Isn’t Optional – Making Web Services Work by Richard Campbell
Building a Rich Web UI at the Speed of jQuery UI by Dino Esposito

And from our home office in Walla Walla, Washington…

Read the SANS Institute Report, “…25 Most Dangerous Programming Errors…”

We can’t be 100% secure, but reading the report will help you think about the most obvious concerns and direct you to resources for addressing these concerns.
Use White Lists instead of Black Lists.

You can’t think of everything even if you try. If you are protecting a file upload, compare how many types of files a user might attempt to upload vs. the specific few you want them to actually upload. White List those few and reject the rest.
The UI is how your users will judge your application.

Most of our work as developers goes into the back end but we are judged on the front end. When was the last time a user said, “Your data model is fantastic and I love how you have separated your concerns?”
Don’t confuse Learnability with Usability.

Usability is a measure of how productive and intuitive the UI is for the average user. Learnability is a measure of how quickly a user can learn a new application.
Most of your users are “Good – Average” level users.

A user will quickly transition from a beginner user to an average user while very few will ever become expert users. Yet, as developers, we often program to those two extremes. Refocus your efforts on the majority of users who are somewhere in between. Note that for a public site this paradigm is a little different as the majority of users may very well be beginners who only visit occasionally
Performance Tuning comes after development.

You will never really know what areas of your application will be bottleneck until people are actually using it. If you attempt to tweak your application for performance in advance, you will just be guessing, and often incorrectly.
Decompose your performance problems.

By creating tests for each tier independently you can determine which tier is your bottleneck or if your problems are elsewhere, like a 10Base-T hub between your server and firewall.
Sometimes you need to cache less for better performance.

Cached items are low priority so they can be thrown out by the garbage collector when resources need to be freed. If you are caching
too much you could actually be forcing the system to run out of resources thereby forcing the system to purge your caches. Only cache things that have high usage.
Go download jQuery UI.

This framework can help you do some amazing things with the UI, from tabs to modal dialog, this framework is slick.
jQuery is better with ASP.NET MVC.

Because MVC developers are often in a bare metal HTML frame of mind, not because of any technical limitations.

My first DevConnections has been a fantastic experience. I heard some phenomenal speakers, met new developers from all over the world, and sharpened my saw. I am excited to bring the things I’ve learned back to our team. But first I am going to have a restful weekend – I never thought a conference could be so exhausting.

If you have any questions about this series of posts or about DevConnections, feel free to send me an email (jimmy.bosseATthycotic.com) or message me on Twitter @jimmybosse.

Jimmy Bosse is a Team Lead at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product. On Twitter? Follow Jimmy

Top 10 Takeaways from DevConnections Day Three

jfrankel — Thu, 12 Nov 2009 14:48:19 +0000

November 10th 2009 | Jimmy Bosse

Top 10 Takeaways from DevConnections Day Three

Wednesday seemed to go at a breakneck pace. The sessions I attended on Tuesday were all given by Microsoft employees and only one
presenter used VS 2008. These presentations were all about how I was going to get things done when VS 2010 launches (allegedly in March 2010.)
The sessions I attended on Wednesday had more to do with how to get things done, today (or when we get home from the conference), and everyone was using VS 2008.

My biggest complaint about DevConnections is there are too many good sessions. There were several sessions that I wanted to attend that were in conflict with one another.
The sessions I managed to settle on were:

What ASP.NET Developers Should Know About JavaScript by Scott Allen
Introduction to jQuery with ASP.NET by Rick Strahl
WCF the Manual way… the Right way by Miguel Castro
.NET Rocks!- SQL Server Reporting Services by Carl Franklin & Richard Campbell with guest Paul Litwin
Refactoring Today’s .NET Code to Good Design Practices by Dino Esposito

And so, without further ado, the top 10 takeaways from day three:

Get the FireBug plug-in.

It seems like every presenter uses FireBug in Firefox, even the Microsoft team. It is very useful when working with your web UI. Go get it if you haven’t already.
Use $.fn to create your own jQuery plug-ins.

jQuery is such an amazingly fluent framework and so easy to extend to your own needs.
You can create pseudo namespaces in JavaScript.

For example, if you want to create a Point object in a Geometry namespace:
var Geometry = {};
Geometry.Point = function(x, y) {…
Use “JavaScript-Behind” for your pages.

It is easy to inline your JavaScript, but for anything other than the most trivial tasks you should move your JavaScript to .js files.
Don’t make any new .asmx pages.

Use WCF. Microsoft no longer supports WSE (.asmx) web services. Your existing services will work, but don’t make any new ones.
Write your own WCF services without the project templates.

Although the WCF project types are helpful to get you up and running quickly, they are full of stuff you don’t need and can make your job harder in the long run. Miguel Castro has a good article on this topic here.
Microsoft has merged the Matrix , Table, and List regions into a Tablix.

A silly name but a very useful change. How many times have you wanted to add a static column to a Matrix or otherwise mix a table with a Matrix? Many times, I know. Now it is possible with the Tablix.
The Code window in Reporting Services still sucks.

Sorry, I wish I had better news.
Single Responsibility Principle is a Principle, not a Law.

You are striving to give a class one reason to change, not extract every line of code into its own class. A Principle means that you aim to code towards a goal but have to also balance that with the needs and design of your system and the problems you are trying to solve.
Shameless Plug: Dino Esposito, IDesign software architect and author, asked me about our Single Responsibility blog post by my colleague David Cooskey.
Service Locator is good. Dependency Injection is better.

With service locators, the “injection” of the dependency is being done from within the class itself. This makes it hard to identify
these dependencies from outside the class. With dependency injection, these dependencies are easy to identify.

Today promises to be another flurry of fantastic sessions. Check back tomorrow for more highlights from DevConnections.

Jimmy Bosse is a Team Lead at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product. On Twitter? Follow Jimmy

Top 10 Takeaways from DevConnections Day Two

jfrankel — Wed, 11 Nov 2009 15:10:54 +0000

November 10th 2009 | Jimmy Bosse

Top 10 Takeaways from DevConnections Day Two

Tuesday at DevConnections (#devconnections) was a whirlwind of excellent sessions by the Microsoft ASP.NET team. It started with the Keynote by Scott Guthrie (@scottgu) and went on to feature what’s new in ASP.NET 4.0 and VS 2010 Web Development. Shortly after were four great sessions:

The Future of C# by Charlie Calvert.
What’s New in ASP.NET MVC.
What’s New in the AJAX Control Toolkit and Microsoft Ajax Library (#devconnajax) by Jim Wang (@turanuk) and James Senior (@jsenior)
Testing in ASP.NET by Federico Silva Armas

After so many enlightening sessions, my Evernote notebook is filled with many amazing things that I learned, even with my laptop battery dying twice. It is hard to whittle them down to ten but here goes, again in no particular order.

VS 2010 supports multiple monitors.

You can finally move a document off the tab and onto a second monitor. Now you don’t have to waste that beautiful 24” monitor just filling it with palettes!
The Web.Config file of a new web project is empty.

Ok it has a few lines of XML, but it is no longer War & Peace.
C# will now have named parameters.

At first this gave me flashbacks of Objective-C, but I have come to embrace this new feature. While today’s IDEs make it easy to see the
signature of methods to understand what the parameters of a method call are, it is great at quick glance to see explicitly what each one
is without having to dig into the code, like in a printout or blog post.
C# and VB will have access to the DLR.

Sitting on top of the Dynamic Language Runtime will allow your C# code to create a variable of type dynamic to hold references to objects
(like COM Interop) and call methods you know exist on those objects, without the compiler complaining.
Say goodbye to <%= Html.Encode({something}) %>

And hello to <%: {something} %>. Isn’t that better?
Areas will help you with your giant Controller directory

A new feature called “Areas”, will allow you to divide your giant MVC projects into more logical directory structures.
Microsoft Ajax Minifier

If performance is paramount in your website, this tool will squeeze every last byte out of your JavaScript libraries.
Ajax Library Preview 6.

The demos from this library were really slick. Go get it and make your website sparkle.
Lightweight Test Automation Framework

While there are too many automated UI testing frameworks out there, experience has shown that each one is good for different
testing scenarios. You can quickly tack LTAF on to your website and get started with UI testing.
Custom Logging for LTAF

Extending logging in LTAF to meet your needs is nice. Federico even mentioned a custom logger that would screenshot
the browser when the test failed. Now that is a great idea!
BONUS!!! WebSiteSpark

If you are and independent developer or a small shop, check out WebSiteSpark (http://www.microsoft.com/web/websitespark/).
For $100 you get access to an amazing set of Microsoft tools and technologies to help get you started.

Today promises to be another flurry of fantastic sessions. Check back tomorrow for more highlights from DevConnections.

Jimmy Bosse is a Team Lead at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product. On Twitter? Follow Jimmy

Top 10 Takeaways from DevConnections Day One

jfrankel — Tue, 10 Nov 2009 21:03:03 +0000

November 10th 2009 | Jimmy Bosse

Top 10 Takeaways from DevConnections Day One

Yesterday I attended the pre-conference workshop, “SharePoint Jump Start: Reimagining Collaboration” hosted by Dan Holme. This workshop was a great tour on getting your first SharePoint site up and running, with an expert guide warning you of the pitfalls and gotchas you might encounter; the best way to introduce your users to collaboration; and some basic business intelligence to wow your boss, without any code.

There were many tidbits of information that I thought were important to remember and at the lunch break I decided that I would post for you the Top 10 things (in no particular order) I took away from Dan’s presentation.

Use the “Advanced” installation option.

The basic option is a quick choice for when you are evaluating SharePoint, but installing from the Basic option will prevent you from scaling your installation in the future.
Create a SharePoint Administrator account to use for installation.

SharePoint will embed the account in several locations, and a dedicated administrative account for SharePoint will avoid headaches in the future.
Ensure the Host Headers you use for your Sites are A Records, not C Records.

The C Record aliasing will cause problems down the road. If you are using C Records, convert them to A Records.
Enforce Check-In/Check-Out on all your libraries.

Ensuring your users are locking files they are editing will prevent conflicts.
Give managers “Override Check-Out” permission.

Someone will check out a file and then not be available to check it in when you need it. You won’t have to field calls from
managers needing to unlock a file if you create a role for the permission and assign it to your managers.
The names of objects you create are often their URLs.

Most of the time when you are creating Libraries, Sites, etc. in SharePoint, the name you give it in the creation
forms will also be the URL for that object. Make sure your keep the name short and avoid spaces. You can usually edit the “friendly name” that is displayed in the UI later.
Limit the number of versions in your Document Libraries.

SharePoint does not diff the changes when storing your versions. Every version is a complete copy taking
up space in your database. If you do not cap the number of versions, you will quickly run out of space in your database.
Most of the “Workflow” requests of your users can be handled with alerts.

If a workflow request starts with, “I want to be emailed when…” then an alert will probably be the simplest option.
You can use SharePoint lists as data for your Excel pivot tables.

This can enable you to provide some basic but impressive “Business Intelligence” functionality quickly and easily.
Folders are obsolete in a Metadata world.

You don’t need folders to organize your documents. If you collect the proper metadata about your documents
it is easier for your users to find information than even the best intentioned folder structure. I loved Dan’s
example of this, “Say you have a photo library with a directory for beach photos, sunset photos, and dog photos.
What do you do with the photo of a dog at the beach during sunset?”

The session was extremely useful and Dan is a great speaker. I recommend you attend a session with him if you get the chance. If Day One was an indication of the rest of the conference, it will turn out to be great week.

Tortoise more than just version control

jfrankel — Mon, 09 Nov 2009 16:02:27 +0000

August 24th 2009 | Jimmy Bosse

For most developers version control, or source control, is a minimum requirement. The primary purpose of version control is to enable multiple team members to work in the code without stepping on one another’s toes. It is also great for branching (creating a new direction in the code that may or may not be integrated back in to trunk) and tagging (marking a particular snapshot of the code, such as a release).

Our Subversion Repository is the ultimate code documentation.

Using source control as documentation is a whole lot better than placing comments inside your code. If you need to write a comment to explain what your code does, then its logic probably needs simplifying. Well-commented commit notes, on the other hand, remind you exactly what you were thinking when you first committed that code.

An explanation: WHY? Explain why you are writing the code.
The Identity of the Writer. We use the initials of the pair committing the code.
Story Number. An identifier linking the commit to the user story it is implementing.
A Summary. Brief notes about what you are trying to achieve in the code you are submitting.

The most important one is WHY.

We frequently find ourselves looking at a block of code and trying to figure out why it’s there. The longer a piece of code remains in a codebase, the greater the chance you’ll forget why it was written in the first place. If good commit notes were written, the “blame” feature becomes your best friend. Its name is misleading as it implies that its purpose is to reveal the culprit who broke something, but in fact it is intended to remind you who wrote the code, and the purpose for which they wrote it. If you are fortunate enough to have a repository for your user stories, you’ll always have a sense of the bigger picture at the time the code was written.

As you work on a software project, your understanding of the problem evolves, as does your approach to the solution. Something that is obvious and finely-crafted today might look like a silly hack to you six months from now.

Leave your future self a note as to how awesome you thought you were at the time. You’ll thank yourself for it—and so will your team members.

Build Your Solutions from the Context Menu

jfrankel — Mon, 09 Nov 2009 15:52:26 +0000

Sept 2nd 2009 | Jimmy Bosse

Build Your Solutions from the Context Menu

Many times you want to quickly refresh your solution from the repository and quickly build it without having to open Visual Studio. Follow these simple steps to add a Registry Key that will add a context menu for you solution files.

Launch RegEdit: Start > Run > type regedit > click OK.

Navigate to HKEY_CLASSES_ROOT > SystemFileAssociations.

If there is no “.sln” key, add a key for “.sln”.

If there is no key for “shell” in “.sln” then add a key for “shell”.

Add a “Build Solution” key in “shell”.

Add a “command” key to “Build Solution”.

Set the default value for command to:

cmd.exe /k “call “%%VS90COMNTOOLS%%\vsvars32.bat” x86&&msbuild “”%1″” /p:Configuration=Debug /t:Rebuild /l:FileLogger,Microsoft.Build.Engine;logfile=MSBuildDebug.log&&pause&&exit”

Reboot, and now you can build your solution file from the context menu.

Tada!

Note that this specific entry will only build debug builds for 2008 solutions. You can modify the VS90COMNTOOLS and Configuration=Debug to add entries for other versions of Visual Studio and other build configurations.

Jimmy Bosse is a Team Lead at Thycotic Software, an agile software consulting and product development company based in Washington DC. Secret Server is our flagship enterprise password management product.

The Bridge Pattern – When a single class hierarchy is not enough

jfrankel — Mon, 09 Nov 2009 15:41:54 +0000

September 10th 2009 | David Cooksey

The Bridge Pattern – When a single class hierarchy is not enough

The bridge pattern allows both the implementation and the abstraction of a programming scenario to vary. Let’s take a look at a specific use case in order to understand the benefit the bridge pattern provides.

Imagine we are writing a top-down scrolling action game. The player will be able to choose from a variety of vehicles and will be up against a maze full of passive and active obstacles. In order to increase replayability, the vehicles available will include tanks, helicopters, and motorcycles, with expansions planned to include additional vehicles. Tanks will have a cannon and a machine gun, helicopters will have missiles and a machine gun, while the motorcycle will allow the player to throw grenades and wield a samurai sword. Throughout the course of the game, upgrades will alter the abilities of each weapon (better missiles, more ammo for the machine gun, swords of awesome lethality, etc).

So, how do we plan our class structure in such a way that we can treat each vehicle the same at the high level, while allowing for flexibility in both the selected vehicle and the weapons it is currently using?

Ideally our top-level implementation should allow us to do something like PlayerVehicle.FireWeapon1() without concerning ourselves with the specific vehicle or weapon the player is using.

The bridge pattern gives us the flexibility we need.

First we create a vehicle base class.

  public abstract class Vehicle
{
public IWeapon weapon1;
public IWeapon weapon2;

public abstract void Move();
public void ShootWeapon1()
{
weapon1.Fire();
}

public void ShootWeapon2()
{
weapon2.Fire();
}
}

By leveraging the “has-a” relationship between a vehicle and its weapons we allow the weapons to vary. The exposed ShootWeapon1 and ShootWeapon2 functions perform the same function in this case as calling .weapon1.Fire() on the vehicle itself. By making Vehicle an abstract class we leave all details of movement up to its concrete implementations.

public class Tank : Vehicle
{
public Tank()
{
weapon1 = new SimpleCannon();
weapon2 = new BasicMachineGun();
}

public override void Move()
{
// Check for physical obstacle, if no obstacle move the tank.
}
}

public class Helicopter : Vehicle
{
public Helicopter()
{
weapon1 = new AirToAirMissile();
weapon2 = new BasicMachineGun();
}

public override void Move()
{
// Move helicopter
}
}

As a result, both the Tank and Helicopter listed above will work as the vehicle in the following code sample.

      Vehicle vehicle = new Tank();

vehicle.Move();
vehicle.ShootWeapon1();
vehicle.ShootWeapon2();

The bridge pattern allows us to change vehicles and weapons independently. This concept is extensible to as many degrees as are necessary to allow independent variation. For example, a futuristic update to the game might add varying kinds of passive or reactive shields to the vehicles. No problem, just create an IShield interface and add it to the Vehicle abstract class.

Essentially, the bridge pattern is just an implementation of a recognition that two concepts exist in a “has-a” relationship and need to vary independently. As such, it provides the required flexibility with no drawback other than a small increase in the complexity of the class hierarchy.

These aren’t your father’s regular expressions

jfrankel — Mon, 09 Nov 2009 15:34:25 +0000

September 17th 2009 | Morgan Kleene

These aren’t your father’s regular expressions

Regular expressions, as they’re traditionally defined, make it impossible to match balanced patterns like “ab”,” aabb”,”aaabbb”, “aaaabbbb”, etc. The Microsoft.NET implementation has augmented traditional regular expressions with new features that allow us to match arbitrary balanced constructs.

I’ll demonstrate a few patterns and build up to a Regular expression that matches a small xml-like language.

There are a few Regexp language ingredients that allow us to match balanced patterns. The first is the named ‘capture group’, and its interesting implementation in .NET. Given the Regex “^a(?abc)(?123)b$” consider what happens when we execute it on the string “aabc123b”: Both “abc” and “123” are captured by the group “g”. The following code demonstrates this by printing out “abc” and then “123”:

Regex r = new Regex(@"^a(?abc)(?123)b$");
      foreach (var s in r.Match("aabc123b").Groups["g"].Captures)
      {
          Console.WriteLine(s);
      }

NOTE: the ‘^’ at the beginning of the Regex means to only match at the beginning of line and the ‘$’ means to match only at the end of the line.

Imagine a stack associated with each group, in our case g, onto which the captured elements are pushed. Most stacks can be popped as well as pushed, right? These stacks can as well. By labeling the second group –g instead of g, matching the text in the parentheses pops off the top element of the g stack. So the following code prints absolutely nothing. Matching the “123” pops “abc” off of the g stack.

Regex r = new Regex(@"^a(?abc)(?<-g>123)b$");
      foreach (var s in r.Match("aabc123b").Groups["g"].Captures)
      {
          Console.WriteLine(s);
      }

An important aspect of the -g construct is that if the g stack is empty then the elements enclosed cannot be matched. The expression “^(a)(<-g>a)(<-g>a)$” will never be matched.

Now I’ll demonstrate how to match two different kinds of balanced expressions. The first will be strings of the form “()” “(())” “((()))” “(((())))”. When we match this kind of of regular expression there are essentially two phases: pushing elements onto the stack as we match the opening parentheses, and popping them off the stack as we match the closing parentheses. The Regexp that matches this expression is:

@"^(?\()*(?<-p>\))*(?(p)(?!))$"

The only new part is the (?(p)(?!)) construct at the end of the line. This construct means that if the p group is nonempty then we should match the pattern “?!”. The pattern “?!” is a negative lookahead, in this case with no argument. This means that the entire pattern matches only in the case that it is not followed by the space between words, which is impossible. What this pattern does is force failure when the p group is not empty to prevent matching things like “((()”, where all the opening parentheses are not consumed by the closing parentheses.

The previous regex does not deal with things like “()((()))(())” because we have restricted all opening parentheses to precede all closing parentheses. It is a simple matter to change this, and allow the parentheses to occur in any order. The following regex will match all strings of balanced parentheses:

@“^(?:
(?\()
|
(?<-p>\))
    )*
(?(p)(?!))$”

NOTE: this is compiled using the RegexOptions.IgnorePatternWhitespace option, to allow spacing for clarity.

We can think of this expression as “Match an opening parenthesis and push it on the p stack. Match a closing parenthesis and pop the p stack only if the p stack contains an opening parenthesis. If we reach the end of the expression assert that the p stack is empty.”

Think about what happens in these examples: Consider the string “(((”. This fails because the group “p” contains “(((“ when we reach the end of the string. Consider the string “)(“. This fails because the only time we match a closing parenthesis is when there is an opening parenthesis on the “p” stack; the first character is never matched.

We must make sure that we only match things that we’ve seen before. In .NET that’s a breeze. The “\k” construct gives us access to the top of the stack associated with the g group.

Regex r = new Regex(@"^(?abc)(?<-g>\k)$");
      foreach (var s in r.Match("abcabc").Groups["g"].Captures)
      {
          Console.WriteLine(s);
      }

In the above code, nothing is printed. We match “abc”, push “abc” on the top of the g stack and then pop everything off the g stack when we reach the -g group and the “\k” construct matches what’s on top of the g stack.

Finally we’re ready to see the expression that matches an arbitrary html-like language. The regular expression matches a language with balanced opening and closing tags. There are no attributes or any inner content, but extending such an expression to deal with things like that shouldn’t be too much of a problem.

@"^(?:
                            (?:<(?[^>]+)>)
                                    |
                              (?<-tagName>>)
                            )*
                           (?(tagName)(?!))$"

We first match the opening tag and capture the name of the tag to the

“tagName” group. When we encounter something that looks like a closing tag we only match (and pop the opening tag off of the “tagName” stack) if the same opening tag is already on the “tagName” stack. When we get to the end of the string we make sure that all opening tags have been matched by asserting that the “tagName” stack is empty.

.NET Regular expressions are a bit more powerful than the Regexes most of us are used to due to the addition of a stack that can push and pop arbitrary elements. If you have a simple, balanced pattern to match they can be extremely helpful.

References

[1] Friedl, J. 2006 Mastering Regular Expressions. O’Reilly Media, Inc.

Morgan Kleene is a Senior .NET consultant at Thycotic Software, an agile software services and product development company based in Washington DC. Secret Server is our flagship password management software product.

Thycotic Software Ltd. | Team Blog

The Benefits of Pair Programming

February 4th | 2009

Managed code isnt always the best solution

January 15th | 2009

Debugger Friend or Foe

January 7th | 2009

Dealing with Nullable Types and IIf in VBNET

December 29th | 2009

Cool Things to Do with Dynamics in dotNET 4

December 21st | 2009

Are Extension Methods a Code Smell

December 10th | 2009

An Overview of C# 4.0

December 1rst | 2009

COM Cleanup

Covariance and Contra-variance

Named and Optional Parameters

Some Love for VB.NET 10 Too

November 24th | 2009

The Danger of Single Responsibility in Programming Continued

October 16th 2009 | David Cooksey

Want to join a team of top notch developers in the DC Metro area?

If you can solve the problem below, you may just have what it takes.

The AJAX UpdatePanel Is it your worst enemy?

November 17th 2009 | Kevin Jones

Thycotic brings Password Management to SuperComputing 2009

November 163th 2009 | Jonathan Cogley and Dan Parker

Top 10 Takeaways from DevConnections Day Four

November 13th 2009 | Jimmy Bosse

Read the SANS Institute Report, “…25 Most Dangerous Programming Errors…”

Use White Lists instead of Black Lists.

The UI is how your users will judge your application.

Don’t confuse Learnability with Usability.

Most of your users are “Good – Average” level users.

Performance Tuning comes after development.

Decompose your performance problems.

Sometimes you need to cache less for better performance.

Go download jQuery UI.

jQuery is better with ASP.NET MVC.

Top 10 Takeaways from DevConnections Day Three

November 10th 2009 | Jimmy Bosse

Get the FireBug plug-in.

Use $.fn to create your own jQuery plug-ins.

You can create pseudo namespaces in JavaScript.

Use “JavaScript-Behind” for your pages.

Don’t make any new .asmx pages.

Write your own WCF services without the project templates.

Microsoft has merged the Matrix , Table, and List regions into a Tablix.

The Code window in Reporting Services still sucks.

Single Responsibility Principle is a Principle, not a Law.

Service Locator is good. Dependency Injection is better.

Top 10 Takeaways from DevConnections Day Two

November 10th 2009 | Jimmy Bosse

VS 2010 supports multiple monitors.

The Web.Config file of a new web project is empty.

C# will now have named parameters.

C# and VB will have access to the DLR.

Say goodbye to <%= Html.Encode({something}) %>

Areas will help you with your giant Controller directory

Microsoft Ajax Minifier

Ajax Library Preview 6.

Lightweight Test Automation Framework

Custom Logging for LTAF

BONUS!!! WebSiteSpark

Top 10 Takeaways from DevConnections Day One

November 10th 2009 | Jimmy Bosse

Use the “Advanced” installation option.

Create a SharePoint Administrator account to use for installation.

Ensure the Host Headers you use for your Sites are A Records, not C Records.

Enforce Check-In/Check-Out on all your libraries.

Give managers “Override Check-Out” permission.

The names of objects you create are often their URLs.

Limit the number of versions in your Document Libraries.

Most of the “Workflow” requests of your users can be handled with alerts.

You can use SharePoint lists as data for your Excel pivot tables.

Folders are obsolete in a Metadata world.

Tortoise more than just version control

August 24th 2009 | Jimmy Bosse

Build Your Solutions from the Context Menu