John Wood

CDClip: Command Line's Current Directory to the Clipboard

Have you ever been at the command line and realized you need to copy the current directory into another application? Pasting it into an open dialog for example? Normally you would go to Edit/Mark and select the current directory from the prompt… quite fiddly.

To make it easier I've created a very simple, free, small utility called cdclip.exe that you can run from any folder in the dos prompt and it puts the current directory into the clipboard ready to be pasted into any other application. Just copy the executable into the Windows folder (or any folder on your path) and that's it.

Download it from here http://www.servicestuff.com/jwss/cdclip.zip

The C# code is, of course, really simple:

Clipboard.SetDataObject(Environment.CurrentDirectory, true);

SOA and Business Experts

About a year ago I was working with a project that was massively entrenched in OOP design, specifically using the Domain Model pattern to represent business entities as business objects. They had huge class hierarchy (6 foot) diagrams to go with it with more interconnecting lines than a NY subway map.

Yet throughout my work on that project, one thing that occurred to me is that when we were talking to the business experts we never once discussed these objects. Perhaps in our minds we were thinking of specific objects, but we couldn't talk on those terms to the business experts because it was just so foreign to them.

Right now I'm working on a project based on a service-oriented architecture, or more precisely a service-oriented design. In this project all the data is separate to the objects, and we use schema to define the data entities and then have mostly autonomous services working on or returning that data independently.

And the big difference is that now I can talk to the business experts about the very same data entities that are in my schema. At one point I actually showed them the schema and they understood it instantly. They would even understand the services (by their name and what they act on), and could even make some suggestions.

Perhaps the new model is a simpler system, or perhaps the business expert is more tech savvy. I'm not sure. But I do feel that service oriented architecture lends a lot to opening up communications between developers and business experts - simply because the design isn't centered on polymorphism, inheritance and searching for your business logic deep inside your class hierarchy - it's centered on data and services.

Business experts tend to think in terms of data and service separation. They have a pile of invoices, and they have a good idea of the workflow that those invoices need to pass through. This is how the business is modelled in their heads.

Most SOA designs are very upfront, deliberately simplified in order to keep everything agile and easily understandable to all levels of the corporate structure.  They focus on separating the data from the business logic, which is not only great for re-use and scalability, it also seems to be great for getting the business experts interacting more with the development process.  And I think that's a very valuable thing.

Unit Tests != TDD

A lot of people seem to get confused between unit tests and Test Driven Development.

Unit tests are typically small pieces of code that test the functionality of units of your application. No matter what design methodology you use, unit tests have a legitimate purpose in ensuring that stuff is still functioning. This is particularly important with highly interdependent code that might be more open to inadvertently breaking.

Test driven development makes use of unit tests, but they're far from being the same thing. TDD is about writing tests upfront to dictate the requirements of the application, and then writing code that makes the tests succeed.

Just because you're creating unit tests, before or after coding, does not mean you're adopting test driven development.

My previous posts are discussing how Test Driven Development, that is developing tests up front as a means to driving the development process, is not a very efficient approach to software development. That doesn't mean that unit tests are bad. Unit tests are always necessary to ensure your code stays functional. Just wanted to clarify that.

Test Driven Development or Business Driven Development?

When my 1 year-old wants something she enthusiastically points and babbles and then waits for me to reciprocate. Is it water she wants? The ball on the table? The stuffed cow? It's difficult to tell. I end up just giving her everything that somewhat intersects with the path of her pointing (and usually moving) finger until she squeals with joy and hugs the object like a long-lost friend.

While her pointing is a vague form of requirement specification, the lit up face, squeal and excited reaction constitutes the test that tells me whether I hit the mark.

So what does this have to do with Test Driven Development? Effectively, with only a little hint, I'm determining the requirements based on the reaction to the tests. The tests are driving my efforts to meet her requirements. And this is actually a lot like how TDD works.

The main thing that comes to mind as I'm fumbling about the desk is that this process isn't particularly efficient. TDD is not really an efficient way to enforce requirements.

So how could we improve this.

Well for one, if my daughter could just come straight out and tell me what she wanted, then I would be able to carry out her wishes with more accuracy. While that probably won't be as thorough as a flow chart and would more likely come in the form of "Ba" for ball or "Wawa" for water, it would certainly help direct me towards the right object.

Natural language is probably the primary mechanism for communicating requirements. More so when you have programmers who do not understand the business, and business experts who do not understand how to write specifications. But while useful, natural language isn't always perfect: regardless of how sophisticated their grasp of language it can often be ambiguous or incomplete.

To truly grasp the requirements, being told what is expected isn't enough - you must have a thorough understanding of the problem itself. My daughter knows exactly what she wants because she wants it! The business expert knows exactly what he wants, because he understands the problem and the business system inside out.

So how do we get from the mind of the person who understands the problem, to the implementation of the process?

The gap will forever exist so long as we have programmers who don't understand the business, encoding misunderstood requirements into low level machine code that is validated only by some tests, which are also encoded by programmers in a desperate last attempt to get the requirements right.

Closing the gap means having less tech-savvy programmers and more business-experts who can automate the things they constantly think about and understand themselves. Workflow platforms, domain specific languages (DSLs) and intentional programming are the tools that enable those people to translate that valuable knowledge into automated processes.

And when your system consists of high level, domain centric, workflow oriented commands such as "When the order price hits the market price process the order" - do you even need tests to validate that this meets the requirements? These commands are the requirements.

This, I think, is where the future of programming lies - business driven development, not test driven development.

What's Wrong With Test Driven Development

While pondering on the merits of TDD the other day something struck me. Test Driven Development really has little to do with testing. It's a bit like saying that C# is a testing language because it supports boolean expressions. The real essence of TDD is defining a contract of intended behavior. I call it Intention Safety. Intention Safety is a bit like Type Safety, but rather than enforcing the type it enforces the intended behavior of the program.

But if you follow this line of thought, TDD really seems to be lacking. Type safety is controlled by well defined types. Either something is compatible with a type or it isn't and we get a compile time error - it's pretty much black or white.

The contract for intended behavior in TDD is far weaker. In some ways it's like playing a game of Taboo. You can specify anything you want so long as you don't specify the exact behavior. If Type Safety were to work the same way that TDD does, we wouldn't have types but instead a type definition would be a series of patterns that are used to recognize a type. Think how much harder programming would be.

So why can't TDD be as good as type safety? Admittedly defining much less articulating behavior is a very difficult thing indeed. There are projects such as the endeavors of Intentional Software that still haven't come to any real material fruition.

But perhaps one day it will be this simple. Perhaps one day when we define a function, we don't just have type safety for the bits coming in and out. Perhaps we'll also have a little declaration at the start of the function that defines the intended behavior of the procedure. Or perhaps that declaration will be the procedure itself and there won't be any real code. And TDD won't really be needed any more.

Some food for thought.

Variable Scoping in Try/Catch Blocks

Am I the only one that finds it annoying that try blocks mess up your scoping?

If I have some code like:

Person[] people = GetPersonList();
...

Then I realize that I need to wrap this in a try/catch block...

try
{
    Person[] people = GetPersonList();
}
catch ()
...

But ah! no... now 'people' cannot be used outside of that try block. So I have to move the declaration above the try statement, set it to null, and just assign it inside the try block rather than declare it. Hassle.

So here's my second language suggestion of the week: Make try blocks the exception (no pun intended) for variable scoping. If I declare something in a try block, then it should not scope the variable, just the code.

This may mean you could have an uninitialized variable if an exception was caught - but that's ok, we just raise a warning that it hasn't been assigned to unless it's also set in the catch block. Most of the time we'll be aborting or something in the catch block anyway.

C# 'as' Keyword Suggestion

The "as" keyword in C# attempts to cast an instance to a specific type and if it fails returns null.

The problem is, I'm not really sure when this would really be that useful. If you expect the variable to be of a specific type then you should just perform an explicit cast and an exception is raised to break the program flow if it fails. If you think it's possible it won't be of that type, then shouldn't that be in an "if" statement using the "is" operator? Returning null means you lose information - now you no longer know whether the instance was null to begin with. It just means that you'll end up with a NullReferenceException which is misleading because it was actually an InvalidCastException. Sometimes the instance is then checked to see if it's null and the it's used to raise an error, which is silly because they should be using "is" instead.

However, sometimes the problem with "is" is that of scoping. It means that if you're assigning the variable inside the if block, and you want to use it outside the if block,  then you have to declare the variable you're assigning it to outside of the if or it'll be lost in that scope. It seems awkward.

I have a suggestion to change the syntax of the "as" cast operator to make it more useful: Add an "else" part that specifies an expression that is assigned to the instance, or an exception that is thrown, if the instance cannot be cast. eg.

IDisposable disp = obj as IDisposable else throw new InvalidCastException("The object does not support IDisposable");

or...

IFolder folder = item as IFolder else originalFolder;

Wouldn't that be more useful?

Shallow Cloning Made Easy: Calling MemberwiseClone on non-cloneable objects

In my last post I wrote about a way to clone an object without having to implement ICloneable. It would use serialization to clone the object, by serializing the object to a memory stream and then deserializing immediately to create a new, copied instance of the object.

A reader pointed out that this performs a deep clone, while that depends on the serialization implementation for that class for most cases it's true.

The .Net framework gives us a base method called MemberwiseClone that copies the values of all the non-static fields of an object. Because it isn't recursive and just copies references as-is, MemberwiseClone doesn't perform a deep clone, rather it just performs a primitive shallow clone.

However this method is protected and is only available on the base class, object. This means we cannot invoke it on objects ourselves. Instead we're expected to implement ICloneable on the object and use MemberwiseClone to perform the shallow clone in the implementation.

So here's a simple bit of code that bypasses that restriction. The code lets you run MemberwiseClone on any object you pass in, therefore performing a shallow clone of any object.

public static object ShallowClone(object obj)
{
 return typeof(object).GetMethod("MemberwiseClone", System.Reflection.BindingFlags.NonPublic
  | System.Reflection.BindingFlags.Instance).Invoke(obj, new object[0]);
} 

Put this method in your utilities class - it's static so you can run it from anywhere.

Note, though, that by running this method you're not guaranteed that the object will be in a consistent state, or that all the fields were actually cloned correctly. But in simple cases it should work.

Hope you find it useful.

Cloning through Serialization

You don't have to implement ICloneable in order to clone objects. Any objects that are marked as serializable (by the [Serializable] attribute or implementing ISerializable) can also be effectively 'cloned' by serializing the object to a memory stream, and then deserializing back to a new copy of the original object.

I use this code to achieve this. You simply pass in the object that supports serialization and it returns a clone.

/// <summary>
/// Performs cloning through serialization
/// </summary>
public static object Clone(object obj)
{
    MemoryStream ms = new MemoryStream();
    BinaryFormatter bf = new BinaryFormatter();
    bf.Serialize(ms, obj);
    ms.Flush();
    ms.Seek(0, SeekOrigin.Begin);
    return bf.Deserialize(ms);
}

Perhaps you might find it useful too.