Roy Osherove is giving an hands-on TDD Masterclass in the UK, September 21-25. Roy is author of "The Art of Unit Testing" (http://www.artofunittesting.com/), a leading tdd & unit testing book; he maintains a blog at http://iserializable.com (which amoung other things has critiqued tests written by Microsoft for asp.net MVC – check out the testreviews category) and has recently been on the Scott Hanselman podcast (http://bit.ly/psgYO) where he educated Scott on best practices in Unit Testing techniques. For a further insight into Roy’s style, be sure to also check out Roy’s talk at the recent Norwegian Developer’s Conference (http://bit.ly/NuJVa).

Full Details here: http://bbits.co.uk/tddmasterclass

bbits are holding a raffle for a free ticket for the event. To be eligible to win the ticket (worth £2395!) you MUST paste this text, including all links, into your blog and email Ian@bbits.co.ukwith the url to the blog entry.  The draw will be made on September 1st and the winner informed by email and on bbits.co.uk/blog

Advertisement

The Agile Workshop is moving. We have been in serviced offices for the past 3 months and had to decide as to whether we wanted to commit to another 3 months or find something else.

The past 3 months have been a learning experience with all the usual highs and lows. On the low side we haven’t been able to grow according to our original plan but on the high side we have been involved with some really interesting projects and some joint ventures.

Our new offices are located within the Social Enterprise Centre in Cambridge which is part of a social charity for incubating start-ups. This is something close to our hearts and is something we want to enable ourselves at some point. The joint ventures we have already entered into are a sign of this and even agile itself eludes to this with the close collaboration with clients.

Once we have settled into our new offices we would like to start focusing on our grander vision of providing world class training, mentoring and coaching agile approaches and of course the ‘doing’ side of it of working directly on delivering projects for our clients.

So as always, if you are ever in the vicinity then please stop by and see us.

Just attending the NxtGenUG Cambridge session on Silverlight 3. A quick count shows between 30 to 40 people attending.

The talk starts with a very staged performance involving Richard talking to a pre recorded self over a webcam support call. It is a tad cheesy but heck, I like it.

The talk then moves on to the 2D perspective manipulation. This makes it very easy to take a 2D image and manipulate it in 3D space. This would make doing a carousel effect very easy and it also works with all content. This is proved by taking a business application form and quickly transforming it by spinning the form round and adjusting the perspective. The form still works but typing text in backwards and at an angle isn’t exactly usable 🙂

GPU acceleration is then discussed and demonstatred along with pixel shading. The GPU acceleration only applies to video (and on the mac only applies to full screen video). I thought the GPU acceleration also applied to pixel shader effects in Silverlight 3 as well. Wouldn’t mind digging into that a bit more.

However, the pixel shader effects are still cool. Way beyond me but the thought that I could find a water ripple effect and bring it in is a very tempting prospect.

Next up is caching and compression. The caching and compression story in Silverlight 3 sounds very compelling. Currently the Silverlight 3 install is actually 40k LESS than the Silvberlight 2 install even though it has much more crammed in. This is quite an achievement by the silverlight team.

The xap files are now much more compressed as well so delivering your silverlight files to your end users is going to take less bandwidth. The figure quoted is a 20% reduction in size.

Also, your own assemblies can now be cached. In Silverlight 2 it would only cache Microsoft assemblies so this is good news. Microsoft has done a good job of compressing as much as possible.

It seems you also get control of the actual caret in a text box. And to demonstrate this, a 1 pixel wide image of a ‘carrot’ for the caret :). I know – more cheese but it got the chuckles.

Moving on to styling and the Silverlight 3 story is much better. It feels like there’s real separation in regards to the design elements which has also caused the most questions from everyone so this seems to be a big win for everyone. Styles can also be applied programmatically (and probably with databinding directly) so it is possible to change the style on the fly which will be good for providing more dynamic theme support. Styles can also be applied located in external assemblies so providing customer specific styles will be much more streamlined.

After a break for pizza we move on to the out of browser experience. This is one of the areas where I think Silverlight 3 will be strongest and can’t wait to get the chance to implement this in some of our projects. If this can be linked with a good synchronised storage solution (like Microsoft synchronisation services) then this will be fantastic as Silverlight 3 will detect when the network is connected. Occasionally connect computing here we come.

It also detects new versions so not only is deployment simplified, but upgrading is also simplified. I’m not sure on the extent of this (for instance, whether you get the chance to hook into the upgrade before and after to be able to migrate stored data). All in all it sounds very promising.

Deep linking also looks very nice so it is possible to link directly to a point within silverlight. This also enables back button support within the browser so no more hassle with the user clicking back expecting to just go back one small step and instead goes all the way to the start of the application (or beyond).

There was also a demonstration on how different silverlight islands on a page can talk to each other. This not only works at the page level but also between tabs and even between different browsers which is quite impressive.

In general the talk focused a lot on the presentation whizzy side of silverlight rather than on the line of business application side of it. Although silverlight is gaining more market share, flash is still the dominating technology for more marketing driven rich content so the spinning video type elements don’t feel as persuasive in that light.

Where silverlight will win more is the rich line of business side of things and also the out of browser based applications so in this regard silverlight is competing in the adobe air space more. It will be interesting to see how silverlight progresses in that space but I didn’t see enough from this talk that really emphasised that point.

All in all it was an enjoyable evening.

I’ve just received my new netbook and I must admit I’m impressed so far. I got this with the intention of blogging more and so far the keyboard on it feels quite comfortable. The battery life has a reported 10 hours which is amazing and I’m looking forward to seeing how long it lasts at user groups and conferences.

I’m going to upgrade it to 2Gb when the memory arrives and will then put Windows 7 on it as using XP feels a little strange these days (I’m spoilt). I’m refraining from putting visual studio on it but I may eventually so I can see what it’s like.

Well, this is the first post from it. Now I can start work on the series of posts that have been bouncing around in my mind since the altnetuk conference. Time to spend time with family now though 🙂

We attended the AltNetBeers last night as part of the AltNetUk conference weekend. It was a thoroughly enjoyable evening involving far too much drink but the discussion was good. I even managed to sit on the ‘park bench’ at one point and give my views on Given When Then tests and how they can structured etc.

So today is the open space code day which I am seriously looking forward too (but hopefully with less drinking involved).

If anyone is reading this and is also going today (or to the actual altnetuk conference tomorrow) then please say hi. For anyone at the altnetbeers last night – we were the one’s playing 9 ball 🙂

Following on from the previous post regarding removing the strings when registering Dependency Properties I wanted to fine tune it so we could remove the need for specifying the type we are defining the dependency properties on.

The way to do this is to cache a static instance of the DependencyPropertyHelper class in our class like so:

private static readonly DependencyPropertyHelper DependencyProperty = new DepenencyPropertyHelper<WorldViewModel>();

Now we can change our dependency property registrations from this:

public static readonly DependencyProperty CameraLookDirectionProperty =  
    DependencyPropertyHelper<WorldViewModel>.Register(x => x.CameraLookDirection); 

To this:

public static readonly DependencyProperty CameraLookDirectionProperty =  
    DependencyProperty.Register(x => x.CameraLookDirection); 

We’ve just been doing some multi-touch WPF work. Well, when I say ‘we’ I really mean everyone else apart from me as it got into what I consider to be serious math of which I have very little (zero) knowledge. Anyway, I digress.

One of the things that has bugged me with WPF are the Dependency Properties, or at least the ugliness of them. An example is

public static readonly DependencyProperty CameraPostionProperty =
    DependencyProperty.Register("CameraPosition", typeof(Point3D), typeof(WorldViewModel));

What bug’s me most is the Register method. I don’t like the magic string which can get lost during a refactor and it would be far too easy to get the order of the type parameters the wrong way round. Just a misspelling of the string is enough for it to not work (which happens far more often than it should).

A much preferable syntax would be the following:

public static readonly DependencyProperty CameraLookDirectionProperty =
    DependencyPropertyHelper<WorldViewModel>.Register(x => x.CameraLookDirection);

With this syntax theirs no magic strings and no types to get mixed up.

This syntax is achieved with the code below:

public static class DependencyPropertyHelper<T>
{
    public static DependencyProperty Register<TR>(Expression<Func<T, TR>> action)
    {
        var member = (MemberExpression)action.Body;
        return DependencyProperty.Register(member.Member.Name, typeof(TR), typeof(T));
    }
}

Now we are taking the string from the member name itself and the order of the types is picked up correctly.

The Castle Windsor 2.0 release contains the auto registration that was previously only available on the trunk (as opposed to the previous 1.0 RC 3 release). The two main auto registration methods we use are the following:

container.Register(
    AllTypes
    .Of<IController>()
    .FromAssembly(Assembly.GetExecutingAssembly())
    );

container.Register(
    AllTypes
    .Pick()
    .FromAssembly(Assembly.GetExecutingAssembly())
    .WithService
    .FirstInterface()
    );

The first one registers all ASP.NET MVC controllers into the container, whilst the second one register’s all other classes using the first interface as the service to register against. So if you have a class ServiceImplementation that implements IService then container.Resolve<IService>() will return an instance of ServiceImplementation.

Their is currently an issue with this second mechanism though in regards to derived classes. To help explain, consider the following:

public interface IFirstServiceOnBase 
{
    // …
} 

public interface IFirstServiceOnDerived : IFirstServiceOnBase 
{
    // …
} 

public class BaseService : IFirstServiceOnBase 
{
    // …
} 

public class DerivedService : BaseService, IFirstServiceOnDerived
{
    // …
}

In this example we have BaseService which implements IFirstServiceOnBase. We then have DerivedService which inherits from BaseService and also implements IFirstServiceOnDerived.

What we want to happen is that when the previous auto registration reflects on our types we expect a call to container.Resolve<IFirstServiceOnBase>() to resolve to BaseService and for container.Resolve<IFirstServiceOnDerived>() to resolve to DerivedService.

However, we find that the second resolve on the container for IFirstServiceOnDerived actually throws an exception as it wasn’t registered.

So, why is this?

The answer is that interfaces are listed in the order of lowest base class first up to derived classes next. So the WithService.FirstInterface() call tries to register DerivedService against IFirstServiceOnBase as opposed to IFirstServiceOnDerived, and finds that this service interface has already been registered against BaseService.

Our fix for this is a new extension method:

public static class WindsorExtensions
{
    public static BasedOnDescriptor FirstInterfaceOnType(this ServiceDescriptor serviceDescriptor)
    {
        return serviceDescriptor.Select((type, baseType) =>
        {
            var interfaces  = type.GetInterfaces().Except(type.BaseType.GetInterfaces());
            if (interfaces.Count() == 0)
                return null;
            return new [] {interfaces.First()};
        });
    }
}

The FirstInterfaceOnType extension method filters out the base interfaces and will now correctly register DerivedService against IFirstServiceOnDerived as we expect.

This changes our second auto registration call to the following:

container.Register( 
    AllTypes 
    .Pick() 
    .FromAssembly(Assembly.GetExecutingAssembly()) 
    .WithService 
    .FirstInterfaceOnType() 
    );

We have been using NHibernate and using SQLite for in-memory tests which has worked very well for us but hit an issue when using schemas.

We wanted to separate out the tables used by our services through the use of schemas as schemas provides a very nice clean logical separation. However, although NHibernate supports schemas through the schema attribute on your class mappings, our SQLite tests fail as SQLite doesn’t support schemas.

We looked into ways around this. Our first port of call was to look at whether their is a way of managing this through our own NHibernate dialect class but our investigations led us to a dead end – although we plan on revisiting this later.

So we switched to looking at the SQLite ADO.NET provider. We figured that if we wrapped this then we could intercept the calls to it and override the “schema.table” requests into “schema_table”.

To achieve this we provide our own implementations of the following:

• IDbCommand
• IDbConnection
• DbParameter
• DbParameterCollection
• IDbTransaction

Within each of these implementations we wrap the underlying System.Data.SQLite versions of these to delegate down to. Within the command itself we parse the provided CommandText and detect if a schema is used, overriding this when necessary.

The final piece of the puzzle is to provide our own NHibernate driver which will tell NHibenate to use our implementation of IDbCommand. We couldn’t just inherit from the SQLite20Driver class so we had to copy its implementation as provided below:

using NHibernate.Driver;

namespace TheAgileWorkshop.SQLiteWithSchemaSupport
{
    public class SQLiteDriver : ReflectionBasedDriver
    {
        public SQLiteDriver()
            : base(
              "TheAgileWorkshop.SQLiteWithSchemaSupport",
              "TheAgileWorkshop.SQLiteWithSchemaSupport.SQLiteWithSchemaConnection",
              "TheAgileWorkshop.SQLiteWithSchemaSupport.SQLiteWithSchemaCommand")
        {
        }

        public override bool UseNamedPrefixInSql
        {
            get { return true; }
        }

        public override bool UseNamedPrefixInParameter
        {
            get { return true; }
        }

        public override string NamedPrefix
        {
            get { return "@"; }
        }

        public override bool SupportsMultipleOpenReaders
        {
            get { return false; }
        }

        public override bool SupportsMultipleQueries
        {
            get { return true; }
        }
    }
}

 

Now to use schemas with NHibernate and keep your in-memory SQLite tests passing, reference the TheAgileWorkshop.SQLiteWithSchemaSupport.dll and specify this driver class (TheAgileWorkshop.SQLiteWithSchemaSupport.SQLiteDriver) in place of the SQLite20Driver class that exists at the moment.

To use this, you can get the source or grab a copy of a release build of the dll directly.

I hope this helps others. If there are any issues then please don’t hesitate to let me know.

UPDATE: We have updated the release build dll link with a version that supports ‘.’ in the parameter values (such as a decimal property) based on MacX’s comments.

I had a discussion today regarding Moq and how to make a quick stub of a property so that a mock object could be thrown into somewhere and have the properties work as simple properties. The simple answer weas to use an expectation:

But that felt ugly – and not as useful as it could be.

After playing around for a while I found the Moq.Stub namespace. After placing a using to this namespace at the top you can do something along the lines of personMock.Stub( p => p.Name ):

or to mock out all of the properties use personMock.StubAll():

As you can see – if no expectation is needed stubbing properties is quite simple in Moq.