March 5th | Jonathan Cogley

I have been using GTD (Getting Things Done) for about 5 years now and it works. It is a great system to manage all aspects of your work and personal life. The turning point for me was when I had too many tasks and correspondence to manage in my head or my inbox. GTD allows you to create “contexts” where you will do work – for example @home, @computer, @phone, @errands, @withAccountant, @withCindy or even just filing for future reference #Done. This lets you move items from your inbox to the proper place for the work to be done. This makes your inbox more of a processing center (with the focus being getting to zero). Getting your inbox to empty and knowing that all tasks are in the right places brings on a Zen-like feeling of calm and control .

My tool for email is the corporate standard – Microsoft Outlook 2007. I love Outlook – it is an incredibly rich and powerful client which allows me to quickly move between my email and my calendar (don’t even get me started on web mail!). Creating “contexts” is easy – simply create folders representing each context and then move items from your inbox to each folder. And there begins the problem …

Moving items between folders in Outlook is painful – there are only two built-in options:

1) Drag the item using the mouse from your inbox to the folder (try that 50 times in one morning!).

2) Use the keyboard. Ctrl-Shift-V brings up the Move to Folder dialog, then navigate the folders using the cursor keys and hit Enter (also way too slow).

What about an Outlook macro? Outlook has the capability to allow tedious items to be recorded or even coded using VBA (Visual Basic for Applications). Not exactly my language of choice but if it works, use it. You can access macros within Outlook by going to Tools | Macros | Visual Basic Editor. Right click on modules in the Project Explorer and click Insert | Module.

>>See the Macros (.txt file)

The sub procedure “MoveToFolder” is really the meat of the code – it uses the recursive GetFolder to find folders by name anywhere in the inbox structure and then moves the selected items to the folder while also keeping track of items for undo. To get it all working, simply create new sub procedures for each context you want to target – for example: MoveToFolder_WaitingFor targets the “@waitingfor” folder. Save your macros and close the Visual Basic Editor (you can return to it at any time to add more target sub procedures).

Now we need to tie these macros to shortcut keys and menu items. This is very easy in Outlook – right click on the menu toolbar and select “Customize”, go to the “Toolbars” tab.

Click “New” to create a new toolbar. Call it “GTD” (or whatever) and click OK. Now drag the new toolbar onto the main toolbar at the top of Outlook. Then right click the new toolbar, click “Customize”, then go to the Commands tab to find the macros. Drag macros to the toolbar, then right click on the new toolbar item to further customize the text, icon and keyboard shortcut. Note that the keyboard shortcut you select mustn’t interfere with other standard shortcut keys in Outlook else they won’t work (I have used ALT-\, ALT-o, ALT-C, etc).

To add a new macro to move to a different folder, simply copy one of the existing ones, rename it and then add it to your toolbar.

Were these macros helpful? How do you manage your email GTD-style?

Note: I did have some trouble implementing “Undo” for the folder moves (essential for when you accidentally move the wrong thing!). Outlook doesn’t seem to support Undo in the same manner as other VBA-enabled applications. Just map the “UndoMoveToFolder” to get it working.

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

March 4th | 2009

Thinking in Regex – A C# Regex Tutorial with Examples

Regular Expressions (regex) can be a difficult language to learn.The terse syntax is one factor-regex are notoriously difficult to read-but another factor is the problem space. Pattern-matching problems require a different mindset than software development in general. However, if you can phrase the question in precise terms, translation to regex becomes easier, even trivial in many cases.

Given this, there are a few things to keep in mind when tackling a problem with regex.

1. Be specific in your requirements. “I want to prevent bad characters” is not useful. “I want to exclude asterisks” is useful.
2. Know the text your regex will run on. A regex to match a URL can be very simple, or as complex as this monster. The goal is the simplest regex that will always work with your input text.
3. Be sure you’re not matching too much. Once your regex is matching what you want it to match, test it against various not-quite-right text samples to avoid embarrassing mistakes.

Let’s say that you have some html that looks roughly like this:

<body>
    <form id="form1" runat="server">
    <div>
        He &amp; I are best buddies.
        <a href="http://www.mywebsite.com/page.aspx?param1=1&param2=2&param3=3">
http://www.mywebsite.com/page.aspx?param1=1&param2=2&param3=3</a>
        <a href="http://www.mywebsite.com/page2.aspx?param1=1&param2=2&param3=3">
http://www.mywebsite.com/page.aspx?param1=1&param2=2&param3=3</a>
        <a href="http://www.mywebsite.com/page3.aspx?param1=1&param2=2&param3=3">
http://www.mywebsite.com/page.aspx?param1=1&param2=2&param3=3</a>
        <a href="http://www.mywebsite.com/page4.aspx?param1=1&param2=2&param3=3">
http://www.mywebsite.com/page.aspx?param1=1&param2=2&param3=3</a>
    </div>
    </form>
</body>

There are many pages like this, some with many more links. You need to fix the ampersands displayed as the text of the link to be & but you do not want to replace ampersands within the href attribute or in the rest of the body of the page. This sounds a little tricky, so let’s refine our requirements.

We want to replace & with & within the text part of an anchor tag only. We don’t want to replace & when it is followed by amp;

Better. But, what exactly does ‘text part’ or ‘anchor tag’ mean in terms of characters?

Specifically, we want to replace & with &amp; between the <a> and </a> character blocks, unless immediately followed by amp;

Now that we have phrased our task this way, it is much easier to form a solution. Let’s build a .Net regex to solve this problem. .Net supports variable length lookbehind (more on this following the example), so we can build our regex in neat groups that apply conditions surrounding the text we want to replace.

Regex.Replace(inputText, "&", "&");

This will replace any & with &amp; Now we want to apply our conditions.

1) Must not be followed by amp;

2) Must come after (be preceded by) <a>

3) Must be followed by </a>

So the resulting regex looks like this:

Regex.Replace(inputText, @"(?<=\<a[^<>]*>[^<>]*)&(?!amp;)(?=[^<>]*</a>)", "&amp;");

(?!, (?=, (?<=, and (?<! are lookarounds. &(?!amp;) can be read as “Match &, then check the next four characters. If they are amp; fail the match.” The other two conditions follow a similar pattern, requiring a preceding <a ….. > tag and a following </a> tag before any < or > is encountered. Restricting the text within < …. > blocks from containing additional <> characters prevents our regex from spanning multiple anchor tags.

Two invaluable aids to learning and using regex in .NET are Expresso (a regex tool written in .NET), and the helpful forum community at RegexAdvice. If regex interests you I highly recommend playing with the tool and browsing the forum. And since you’re still reading—this probably means you!

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

February 25th | 2010

Quirks in .NET Part -2  Marshalling Booleans

In Quirks in .NET – Part 1, we talked about the quirky call vs. callvirt instructions.

This week Platform Invoke is under my microscope. It isn’t necessarily a quirk, but it can be a hair-pulling experience when you get it wrong. More specifically, getting the marshaling done properly. Even more challenging, getting it right on both 32-bit and 64-bit environments.

Marshaling Booleans

Marshaling is done primarily for two reasons: you need functionality that is not built into the .NET Framework, but is found in existing Win32 APIs; and you have existing functionality in an unmanaged library you want to reuse.

Let’s start with the basics: What managed types map to unmanaged types? Some are common sense and some are not. Let’s talk about the System.Boolean type for a second.

Most people assume it takes exactly 1 bit in managed world, but in memory it’s a byte. We can prove it with this code:

int sizeBoolean = sizeof (bool);
int sizeInt = sizeof (int);
Console.Out.WriteLine("size of boolean = {0}", sizeBoolean);
Console.Out.WriteLine("size of int = {0}", sizeInt);

The size of operator returns the value in bytes, and a bool is 1. Here’s where things get tricky. In unmanaged world, there are two types—three really—BOOL, BOOLEAN, and COM’s VARIANT_BOOL.

The .NET Framework will try guess which one you mean when marshaling, but it won’t always get it right. When a managed bool is marshaled in a Platform Invoke method, it will marshal it automatically as a 4 byte type which is the more common marshaling case. However, if you cause an interface to get marshaled to COM and that interface has a Boolean as a return or method parameter, it will marshal it automatically as a 2-byte VARIANT_BOOL. Since COM interfaces tend to mix and match Booleans of different sizes, it’s always best to be explicit about which Boolean to marshal it to using the MarshalAsAttribute attribute.

You’ll have to look at the IDL or header file of the unmanaged code to determine which you need to use. Sometimes it requires a bit of playing around too.

In Quirks in .NET – Part 3 we’ll look at numbers and binary

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

February 18th | 2010

Quirks in .NET Part -1 Call vs Callvirt

There are a lot of cool yet strange things in the .NET Framework. A lot of them make you go, “Huh. I didn’t know that.” Let’s take a look at a few of them.

call vs. callvirt

This one is especially interesting to me. In the Microsoft IL specification there are two instructions to call a method, put simply—call and callvirt. call will simply call a method, while callvirt is used to a late-bound method call, meaning that the method which is going to be called is chosen at runtime and not compile time as the simple call would. This is needed for virtual methods when a VTable lookup is required.

Interestingly, all calls to instance classes are compiled as callvirt, even if the method being called is not virtual (thus at compile time we know exactly which method will be called.) I thought it was a bug at first, but really it was a fix for another bug. Consider this code:

class Program
{
    static void Main()
    {
        HelloWorld instance = null;
        instance.SayHello();
    }
}

public class HelloWorld
{
    public void SayHello()
    {
        System.Console.WriteLine("Hello World!");
    }
}

Looks like it would immediately blow up, right? We should get a NullReferenceException. And in fact, if we compile this with the C# compiler, we do! Let’s look at the IL for the Main() method.

  L_0000: nop
  L_0001: ldnull
  L_0002: stloc.0
  L_0003: ldloc.0
  L_0004: callvirt instance void HelloWorld::SayHello()
  L_0009: nop
  L_000a: ret

Sure enough, it uses a callvirt, but here’s the interesting part: If the compiler used a call, rather than callvirt, this code would actually run. In fact, we can do that, too. Let’s change the callvirt to a call, recompile the IL using ilasm, and see what happens.

Yeah, it appears that our program, which should be causing a NullReferenceException, isn’t. This is why the .NET compilers don’t use call, even though using call is a perfectly acceptable in this case. For that matter, the only time a regular call will be used is when you call a method on a struct, or a static method on a class.

If you use the Reflection.Emit namespace frequently, or are looking into it, this is something to watch out for.

In Quirks in .Net  Part 2. we’ll look at Marshalling Booleans.

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

February 11th | 2009

FsUnit – Test F# with F#

I recently spent some time putting together an F# lab with a series of unit tests designed to help teach the language. I started out with a set of Nunit tests in C#, but kept running head-first into type problems with the method signatures and return types. Another hiccup was that my VS 2008 C# code couldn’t see my F# code until I referenced the generated F# dll directly via Browsing. Adding a simple project reference didn’t work.

For example, here’s a simple F# function that returns the square of the input for any member with (*) defined and a C# assert based on it.

F# module:

#light

namespace Samples

module SampleOne =

let inline Square (x : ^x) = x * x;

C# code:

Assert.AreEqual(9, Samples.SampleOne.Square(3));

Seems simple enough, right? Except for the build error. “The Type arguments for method ‘Samples.SampleOne.Square<x,a>(x)’ cannot be inferred from the usage. Try specifying the type arguments explicitly.” What the compiler is telling us here is that we’re calling a generic function without specifying the types.

To make the compiler happy, we have to do the following instead:

Assert.AreEqual(9, Samples.SampleOne.Square<int, int>(3));

Elegant? No, not really. The syntactic magic that F# uses to allow us to infer types is not available within C#.

Here’s a simple F# function that calls ToString on all members of a list and returns it as a new list.

let ListToString x = List.map (fun x → x.ToString()) x;

Its signature in F# looks like: val WorkOnList : (`a → string list)

In C# … Microsoft.FSharp.Core.FSharpFunc<Microsoft.FSharp.Collections.FSharpList<b>, Microsoft.FSharp.Collections.FSharpList<string>> SampleOne.WorkOnList<a,b>(a x)

Confusing, at best. Luckily there’s a testing framework that avoids these issues and is designed for F#.

FsUnit to the Rescue

FsUnit is a library that defines a simple, easy-to-use testing syntax within F#. It currently works with NUnit, but is intended to work with MbUnit, xUnit, and MsTest in the future. It’s a breeze to set up, simply reference nunit.framework, FsUnit.NUnit, and include the FsUnit F# script that sets up the syntax.

Using FsUnit, we can describe our functions and write a test for them as follows:

#light
namespace Tests
open NUnit.Framework
open FsUnit

module module1 =
    let inline public Square x = x * x;  

    [<TestFixture>]
    type ``Sample Tests`` ()=

        let WorkOnList x = List.map (fun (x) -> x.ToString()) x;
        let lame x = List.head x;

        [<Test>] member test.
         ``Test One`` ()=
            Square 5 |> should equal 25;
            Square 0 |> should equal 0;
            Square 1.5 |> should equal 2.25;
            WorkOnList [1;2;3;4;5] |> should equal ["1";"2";"3";"4";"5"]

Much more elegant and concise than the C# mess above. Spaces in test names are allowed—a feature I love. I’ve written far too many tests along the lines of ShouldCorrectlyDoOperationWhenValueAandValueBDoNotExceedValueC.

Languages typically use spaces to separate words instead of capitalization for a reason.

Keep in mind that this test syntax does not cause a compile time error if types do not match. For example, a function defined as let x = 0; does not cause a compile error when tested with x |> should equal “horse”.

In conclusion, I recommend giving FsUnit a try if you intend to test F# code. Test in the language you wrote the code in!

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

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

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

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!

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

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 <value>”, 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.

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

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<dynamic> results = new List<dynamic>();
                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.

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

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<T> 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 <ClassBeingExtended>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?

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

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<T> and SomeType<K> let’s assume that K is a superclass of T. SomeType<T> and SomeType<K> 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<T>();
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.

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

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"

or

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.

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

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.

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

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:

<asp:ScriptManager runat="server" ID="MyScriptMap" EnablePartialRendering="true" />
<asp:UpdatePanel runat="server" ID="TimeUpdatePanel">
    <ContentTemplate>
        <asp:Label runat="server" ID="TimeLabel" />
    </ContentTemplate>
    <Triggers>
        <asp:AsyncPostBackTrigger ControlID="UpdateTimeButton" EventName="Click" />
    </Triggers>
</asp:UpdatePanel>
<asp:Button runat="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:

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|<span id=”TimeLabel”>11/8/2009 7:13:35 PM</span>|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:

<div>
    <asp:ScriptManager runat="server" ID="MyScriptMap" EnablePartialRendering="true">
        <Services>
            <asp:ServiceReference Path="~/DataSource.asmx" />
        </Services>
    </asp:ScriptManager>
</div>
<script language="javascript" type="text/javascript">
    function updateTime() {
        var service = new Ajax4Samples.DataSource();
        service.GetDateAndTime(iHaveDateAndTime, null, null);
    }

    function iHaveDateAndTime(theTime) {
        var myTimeSpan = $get('MyTimeSpan');
        myTimeSpan.innerHTML = theTime;
    }
</script>
<span>The Server's Time is: </span>
<span id="MyTimeSpan"><%= DateTime.Now.ToString("G") %></span>
<input type="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.

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

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

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…

1. 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.

2. 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.

3. 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?”

4. 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.

5. 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

6. 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.

7. 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.

8. 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.

9. 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.

10. 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

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:

1. 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.

2. 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.

3. 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) {…

4. 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.

5. 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.

6. 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.

7. 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.

8. The Code window in Reporting Services still sucks.

   Sorry, I wish I had better news.

9. 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.

10. 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

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.

1. 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!

2. 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.

3. 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.

4. 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.

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

   And hello to <%: {something} %>. Isn’t that better?

6. 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.

7. Microsoft Ajax Minifier
   

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

8. Ajax Library Preview 6.
   

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

9. 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.

10. 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!

11. 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

]]> http://www.thycotic.com/top-10-takeaways-from-devconnections-day-two/feed 1