brendan forster

MEF Monday #1 – Interesting Resources

Brendan Forster — Mon, 01 Feb 2010 14:20:10 +0600

Following up from my talk on MEF at SLCC on the weekend – where I ran through the fundamentals of MEF, developing applications in Silverlight, and answering questions about using MEF in applications - I thought I’d share some of the resources that I’ve found valuable when I started with MEF.

MEF on Codeplex

A great starting place for anyone looking into MEF. Installers, documentation, blogs and more.

MEF Forums

Have an issue? Trying something and its not working as you expect? Have a look here, someone else may have come across the same issue and found a fix.

MEF and Dependency Injection – How they Differ

I got the “Is this Dependency Injection?” question a few times over the weekend, and Glenn Block has a good list here of what MEF v1 does not support when you compare it to popular DI Containers such as Ninject, StructureMap or Unity.

MEF and Prism – How They Relate

Another interesting question that was raised is how MEF and Prism relate. While they may have inadvertently encroached on eachother’s turf, the feature parity and directions differ greatly. I expect some synergy between the two down the track (perhaps MEF support within Prism), but currently Prism has the specialised UI composition features (EventAggregator, Composite Commands) out-of-the-box that MEF doesn’t support in v1.

The Relationship Zoo

How do we identify and represent the relationships between components, especially as applications become more intricate?

Nicholas Blumhardt, maintainer of the Autofac project, did a great job of dissecting the patterns for defining relationships between components, and throws around some ideas about scenarios and future plans for this space.

Building Extensible Rich Internet Applications with MEF

Here is a session from PDC last year where Glenn talked about using MEF in Silverlight, including some of the Silverlight-specific features, such as PackageCatalogs and asynchronous downloading of XAP files.

PS: I’ve got some of my own thoughts and samples on the way, as well as some ideas about applying MEF to application scenarios.

Why even bother?

Brendan Forster — Mon, 30 Nov 2009 16:18:07 +0600

Ever since PDC, I’ve been struggling to figure out how a community project can compete in the Twitter space in this day and age. Up until recently, Tweetdeck was the defacto Twitter client, with a few people going on about Tweetie on something called an iPhone. A lot of others were around the place, fighting for airtime. But then Seesmic gets a few moments on stage during a keynote, scoring a bunch of free publicity for their app – which was a preview demonstrating the fact that they rewrote it as a native Windows application.

Where was the innovation?

This may come across as me venting at Seesmic, but its more a vent in general at how someone can differentiate themselves in such a noisy industry – an industry where an update for a product client generates an absurd amount of news articles on top of the Twitter noise. After all, this isn’t something I do for a day-job. Its a side-project that a few friends work on whenever they have spare time. How can we even compete against full-time employees, venture capitalists, and tech influencers for mindshare?

What project am I talking about? MahTweets. A extensible client in WPF for microblogging and uploading content that started out as something we wrote for ourselves, and is something we are sharing with the community. Sounds like just about every other client out there, I bet.

Let me discuss how we differentiate ourselves from the rest.

A Truly Open-Source Client

Anyone can download the source, explore its internals, and customise it to suit their needs. We’ve had upstream patches submitted from people who want to tweak the user interface, (theming is something that we support for plugins, the full UI is a lower priority).

A client that is free as in beer is one thing, but ultimately you’re at the mercy of the company resolving any issues you encounter. If you’ve got some developer skills (or are just curious about code) why not download the code and browse it yourself?

Plugin Support Available Today

MahTweets supports Twitter and Facebook out of the box, along with support for a number of other syndication services (Flickr, 12seconds, Twitpic, RSS). We’d love to talk about what is in the pipeline, but we’re hard at work polishing the user experience and the plugin architecture for the next release, so that other people can come in and write their own plugins.

One of the most interesting features we have (and have barely scratched the surface of using) was the Status Handler pipeline. No other platform client I’ve come across has good support for writing handlers. We did a proof-of-concept version for TechEd AU that had support for Ruby plugins using the upcoming Dynamic Language Runtime, which translated status updates into LOLwords - I thoroughly enjoyed hearing people see their tweets turned into something out of ICanHazCheezburger.

A Better (and more personal) List Implementation

One of the use cases that Loic uses as a motivator for plugin-based architecture is support for custom behaviour. He uses an example of an “temporary unfollow” to ignore the noise that someone is already. Of course, the user wants it specifically for Twitter.

We identified this frustration early on and built what we call “streams” – giving the user full control over what appears in each list, so they can make changes on-the-fly. The streams are persisted when you close the app, so there’s no requirement for you to use Twitter or use Facebook. This is our own implementation – you can filter based on account, message, contact or any combination.

Clients don’t seems to care about good filtering, yet its something everyone wants

We’re making it for you (any incidental fame is just a bonus)

The current incarnation of MahTweets started out over a few tweets between myself and Paul – discussing how we might build a client which supports plugins. We wanted to have plugins at the core so that others could take our initial work and go further. It really sucks that all the others are finally “getting” this desire for people to customise their client, when this was something that we wanted from the start.

A lot of what we’ve done in terms of features has been driven from our users. Little things can often make or break the experience for a user (we’ve seen both sides of that) and its what drives me to do more. Here’s some recent ones I’ve found on Twitter:

“Did I just see mahtweets do geotagging? NICE!” - source

“Now that I'm getting used to it, I'm beginning to dig #MahTweets. Slick interface and nifty animations.” - source

“I like #mahtweets and its use of #MEF - I have written an extension myself.” – source

“@airliebee you running it on a personal machine or a work one? If it's yours, give @aeoth's MahTweets a spin. Best Windows client evar! :)” – source

Wrapup

This was never about being #1 in popularity in the Twitter space. I wanted to see the guys behind MahTweets get some recognition for their hard work over the past few months. I know Paul has looked at a shitload of Twitter clients over the past months, to see what everyone else is doing and where they fall down, and he’s done an incredible amount of work on turning out something incredible (why lie - he’s the overlord and the main driver of this).

So how can we push the competition further and get a bigger voice in the field when we’re struggling to be heard above the noise of the interwebs? I’d love to see Tweetdeck or Seesmic move in a direction which is more driven by plugins – they have been talking about this, but I don’t believe they’re close to the flexibility and control that we have currently.

What are your thoughts?

.NET Code Contracts – What’s the best way to use it?

Brendan Forster — Thu, 19 Nov 2009 05:57:14 +0600

This is part of a series of articles covering not only the technical capabilities of .NET Code Contracts being added in v4.0 of the .NET Framework, but also the benefits of this technology and how developers can leverage the technology in their projects.

The Million Dollar Question

In the previous entry, I introduced the Code Contracts concept and demonstrated how the tooling works. With so many different ways to write software, is Code Contracts something that we can integrate into a developer’s workflow?

Ultimately, the process of writing software is made up of a number of tasks. And before writing any code, you should have an idea of what it is you’re designing. Let’s use the scenario of owning a vehicle (there’s more to it than this, but I’ll focus on a few key scenarios) and define a number of behaviours which must be adhered to:

A vehicle can have a number of occupants.

An unregistered vehicle cannot be driven.

The vehicle needs at least one occupant before it can be driven.

An occupant should only leave a vehicle when it is stationary (unless the vehicle is in an action movie, of course!).

The key about this is that it can be applied to different types of vehicles – cars, motorbikes, trucks.

Defining the Interface

To cover the key features of the class, this code snippet should suffice:

public interface IVehicle

    int Wheels { get; }

    int Occupants { get; }

    bool IsRegistered { get; }

    bool IsMoving { get; }

    void PersonEntersVehicle();

    void PersonLeavesVehicle();

    void StartDriving();

    void StopDriving();

    void RegisterVehicle(Country country);

public enum Country

    Australia,

    UnitedStates,

    UnitedKingdom

Declearing the Contract

Typically, the next step is to implement this IVehicle interface and test against that. But what we can do here is write the contract statements in a separate class, so that all implementations of IVehicle will use the same contract.

Note: To ensure the contract is detected for interface implementations of IVehicle, VehicleContract must explicitly implement IVehicle.

[ContractClassFor(typeof(IVehicle))]

public class VehicleContract : IVehicle

    public int Wheels { get { throw new NotImplementedException(); } }

    public int Occupants { get { throw new NotImplementedException(); } }

    public bool IsRegistered { get { throw new NotImplementedException(); } }

    public bool IsMoving { get { throw new NotImplementedException(); } }

    [ContractInvariantMethod]

    void ObjectInvariant()

        Contract.Invariant(Occupants >= 0);

    void IVehicle.PersonEntersVehicle()

        Contract.Requires(IsRegistered);

        Contract.Requires(!IsMoving);

        Contract.Requires(Occupants >= 0);

        Contract.Ensures(Contract.OldValue<int>(Occupants) + 1 == Occupants);

        Contract.Ensures(IsRegistered);

        Contract.Ensures(!IsMoving);

        Contract.Ensures(Occupants > 0);

        throw new NotImplementedException();

    void IVehicle.PersonLeavesVehicle()

        Contract.Requires(IsRegistered);

        Contract.Requires(!IsMoving);

        Contract.Requires(Occupants > 0);

        Contract.Ensures(Contract.OldValue<int>(Occupants) - 1 == Occupants);

        Contract.Ensures(Occupants >= 0);

        throw new NotImplementedException();

    void IVehicle.StartDriving()

        Contract.Requires(IsRegistered);

        Contract.Requires(!IsMoving);

        Contract.Requires(Occupants > 0);

        Contract.Ensures(IsMoving);

        Contract.Ensures(IsRegistered);

        Contract.Ensures(Contract.OldValue(Occupants) == Occupants);

        throw new NotImplementedException();

    void IVehicle.StopDriving()

        Contract.Requires(IsRegistered);

        Contract.Requires(IsMoving);

        Contract.Ensures(!IsMoving);

        Contract.Ensures(IsRegistered);

        Contract.Ensures(Contract.OldValue(Occupants) == Occupants);

        throw new NotImplementedException();

    void IVehicle.RegisterVehicle(Country country)

        Contract.Requires(!IsMoving);

        Contract.Ensures(IsRegistered);

        Contract.Ensures(!IsMoving);

        Contract.Ensures(Contract.OldValue(Occupants) == Occupants);

        throw new NotImplementedException();

[ContractClass(typeof(VehicleContract))]

public interface IVehicle

    // interface here

The two attributes on the interface and the contract class link the contracts to the interface, enabling the Code Contracts rewriter to verify the implementations of the interface against the contract.

This may seem like a lot of work, but the major benefit of having contracts defined in a separate class is that the contracts will be slipstreamed into any class which implements IVehicle.

Implementing the Interface

With all the core components in place, we can now go ahead and write the code for the class. While one might feel that you should be checking that the state of the class is valid (and throwing exceptions otherwise), this is handled by the static and runtime checkers.

public class Car : IVehicle

    public int Wheels { get; private set; }

    public int Occupants { get; private set; }

    public bool IsRegistered { get; private set; }

    public bool IsMoving { get; private set; }

    public Car(int wheels)

        Contract.Requires(wheels > 0);

        Contract.Ensures(!IsMoving);

        Contract.Ensures(Occupants >= 0);

        Contract.Ensures(Wheels == wheels);

        Contract.Ensures(!IsRegistered);

        this.Wheels = wheels;

        this.Occupants = 0;

        this.IsMoving = false;

        this.IsRegistered = false;

    public void PersonEntersVehicle()

        Occupants++;

    public void PersonLeavesVehicle()

        Occupants--;

    public void StartDriving()

        this.IsMoving = true;

    public void StopDriving()

        this.IsMoving = false;

    public void RegisterVehicle(Country country)

        this.IsRegistered = true;

        // TODO: track the country information

I’ve added in some additional contracts in the constructor, so that the Car is initially configured correctly. Aside from that, all the contract information is driven from the VehicleContract class.

Catching the Exceptional Behaviour with Static Verification

Here’s a quick console app that tries to use the Car in strange ways. I’ve highlighted the lines where static verification throws up warnings (see Part 1 for how this appears in Visual Studio).

static void Main(string[] args)

    Car car1 = new Car(4);

    // test #1 - no people in the car

    car1.RegisterVehicle(Country.Australia);

    car1.StartDriving(); // requires unproven: Occupants > 0

    Car car2 = new Car(3);

    // test #2 - person leaves moving car

    car2.RegisterVehicle(Country.Australia);

    car2.PersonEntersVehicle();

    car2.StartDriving();

    car2.PersonLeavesVehicle(); // requires unproven: !IsMoving

    // lets use it properly

    Car car3 = new Car(5);

    car3.RegisterVehicle(Country.Australia);

    car3.PersonEntersVehicle();

    car3.StartDriving();

    car3.StopDriving();

    car3.PersonLeavesVehicle();

Automated Testing of Contract Behaviours

For the adventurous, they might be wondering if there is a value proposition in automated testing instead of detecting warnings during compilation. As the Contracts will generate an exception, the test runner should be capable to detect the exception and deal with it.

There are a couple of hurdles to jump to get this working:

Hurdle 1: the ContractException class: this class is marked sealed and internal, to ensure developers don’t try to catch the exception. Which I totally appreciate, because the contracts should be raised so that it isn’t handled by the function. This is probably a discussion for another topic – while I like how they’ve implemented handling exceptions, it could be taken further.

[TestFixture]

public class CarTests

    [TestFixture]

    public class CarTests

        [Test]

        [ExpectedException(ExpectedMessage = "Precondition failed: IsRegistered")]

        public void StartDriving_WithNoRegistration_ThrowsException()

            Car car1 = new Car(4);

            car1.StartDriving();

            Assert.Inconclusive("This should raise a contract exception");

        [Test]

        [ExpectedException(ExpectedMessage = "Precondition failed: Occupants > 0")]

        public void StartDriving_WithNoOccupants_ThrowsException()

            Car car1 = new Car(4);

            car1.RegisterVehicle(Country.Australia);

            car1.StartDriving();

            Assert.Inconclusive("This should raise a contract exception");

        [Test]

        [ExpectedException(ExpectedMessage = "Precondition failed: !IsMoving")]

        public void PersonLeavesVehicle_WhileDriving_ThrowsException()

            Car car2 = new Car(3);

            // bad test #2 - person leaves moving car

            car2.RegisterVehicle(Country.Australia);

            car2.PersonEntersVehicle();

            car2.StartDriving();

            car2.PersonLeavesVehicle();

            Assert.Inconclusive("This should raise a contract exception");

        [Test]

        public void Occupant_EntersDrivesAndLeavesVehicle_HasNoOccupants()

            // good test - correct setup and usage

            Car car3 = new Car(5);

            car3.RegisterVehicle(Country.Australia);

            car3.PersonEntersVehicle();

            car3.StartDriving();

            car3.StopDriving();

            car3.PersonLeavesVehicle();

            Assert.AreEqual(0, car3.Occupants);

We’ve brought over the scenarios from the console application. As ContractException is not accessible directly, we need to inspect the Message property of the exception to ensure the correct precondition is throwing the exception – its not perfect, but it works.

Hurdle 2 - Exception Handling: Code Contracts uses event handlers to allow applications to handle contract exceptions, so that applications can handle issues globally by listening to the ContractFailed event. In addition to getting the exception information, the handler can either unwind the stack, or mark the event as handled.

To demonstrate the available options, I’ve added this code to the test class to set up the test:

[TestFixture]

public class CarTests

    EventHandler<ContractFailedEventArgs> errorHandle = (s, e) =>

        // signal that the issue is sorted and no exception should be raised

        //e.SetHandled();

        // revert the code to before the method was entered and throw the exception

        //e.SetUnwind();

};

    [SetUp]

    public void Setup()

        Contract.ContractFailed += errorHandle;

    [TearDown]

    public void TearDown()

        Contract.ContractFailed -= errorHandle;

    // tests

If I set the ContractFailed event as handled – by calling e.SetHandled() - the exception will be consumed and the application will continue along its merry way. Except that’s not a good thing – I want to ensure that the test throws an exception. I’ve structured the failing tests so that they will assert the test is inconclusive (it shouldn’t reach the end if the contract is correct) because it should never complete.

This is what I see from the NUnit system runner:

Ruh-roh. I consumed the exception when I shouldn’t have.

If I set the ContractFailed event to wind back the stack – by calling e.SetUniwnd() – the application will roll its state back to before it entered the problem method, and the exception will be raised.

The test runner now gives me this information:

Ah, that’s better. Green pastures.

The benefit of pushing this stuff out to a testing framework is that you can reduce compilation overhead:

1. Writing the code (opt-in to check the contracts).

2. Commit the code and run an automated build containing a test suite against the contracts (mandatory check).

3. Finally, deploy the application without the contracts to boost performance.

The tests can be structured around identifying the expected behaviour for valid or invalid scenarios. Ultimately, this becomes another type of testing you can do during development, and this can be integrated easily into your automated build processes using existing .NET testing frameworks.

Summary

Code Contracts can be added to existing code, but one of the main benefits I’ve encountered is that code contracts can become a step between defining the interface and writing the implementation. The compilation tools allow a clean separation between interfaces, contracts and implementations for clarity and consistency, while still allowing verification of contracts within the IDE, by merging contracts with the interface implementation during compilation.

Code contracts can also be verified at runtime by leveraging unit testing frameworks, to ensure that a contract change (much like changing the implementation of a class) will raise errors if the test scenario breaks. I also demonstrated some of the configuration options about handling contract exceptions, but this will be the focus of an upcoming entry.

What’s All This? An Overview of .NET Code Contracts

Brendan Forster — Thu, 19 Nov 2009 05:21:15 +0600

What is Code Contracts?

Code Contracts is a direct descendant of the Spec# project – which was a research project designed to add design-by-contract functionality to the C# language. While its syntax was quite similar to Eiffel (which was the first to implement DbC), it was always intended to be a research project. Most of the team moved over to work on Code Contracts, which applied this knowledge with the goal of providing better integration with the .NET Framework and tooling support within Visual Studio.

The Base Class Library team is using Code Contracts to verify the core libraries of .NET 4.0 as it heads towards being released next year – with the longer-term goal being that contracts can be used as first-class citizens by third party developers building applications and components on top of .NET. These contracts are included when you download the Code Contracts tools, so you can see how the BCL team is using Code Contracts.

What is Design By Contract?

For those who are unfamiliar with design-by-contract, its a pattern for specifying how components in an application behave. I’ll defer to Wikipedia here, because I think this is the best summary out there about the focus of design-by-contract:

What does it expect?

What does it guarantee?

What does it maintain?

You’re probably rolling your eyes at this point, so lets stop handwaving and use a practical example. I’ll drill down a bit deeper on the concept itself in another entry, but this should be a good starting point.

A Tale of Consumers and Suppliers

In a typical contract, there are two participants – for simplicity’s sake, we’ll call these entities the consumer and the supplier. In the real world, the supplier would be the developer writing the component, and the consumer could be a different developer using the component in their application.

Say I have implemented a collection, and this is the method for adding an item:

public void Add(T item)

    if (item == null)

        throw new ArgumentException("item");

    // ... add the item to a collection

public int Count

    get {

        // implementation

    set {

        // implementation

For this method above, we have an implied expectation that the consumer will provide a non-null item as the parameter. The method will throw an exception otherwise, to scold the consumer about doing something silly.

How can the consumer understand this requirement when writing code against this class?

Personally, I’d suggest Reflector here (a godsend and should be in every .NET developer’s toolset), but that’s hardly ideal to do for every class and library you deal with. In a utopian developer society, we should be able to find this information easily and quickly.

There is also a guarantee here – can you spot it? Think about what is being managed internally by the collection and is being exposed to the consumer.

There is a guarantee around the behaviour of the Count variable – the supplier must ensure that the Count value is updated when Add is finished. Should we take it for granted that this will be incremented?

How can we verify that Count is correct at the end of the Add method?

This depends on the implementation of the collection. You could write a unit test to achieve this, but we can specify this as part of the contract, and use the static checking tools to verify the behaviour.

What does a contract look like?

This depends on the implementation of the language - Eiffel has DbC available natively, other languages have contract available via third party libraries – and .NET 4 will have Code Contracts built into the core. How these contracts are integrated into assemblies will be discussed in a later entry.

So, to rewrite the above section to use Code Contracts, this is how it would behave:

using System.Diagnostics.Contracts;

// ...

public void Add(T item)

    Contract.Requires(item != null);

    Contract.Ensures(Contract.OldValue(Count) + 1 == Count);

    // ... add the item to a collection

public int Count { get; set; }

So we’ve taken out the exception and included two statements which form the contract:

The expectation of the consumer: I require that ‘item’ is not null.

The guarantee of the supplier: I ensure that ‘Count’ will be incremented by this method.

There are other contract statements available (Assert and Assume) but these are only verified at runtime – rather than the all-round awesomeness of static verification.

How does this work in Visual Studio?

Code Contracts are not available by default in Visual Studio. You need to install the tools from the project site to get the integration – this is available for 2008 or 2010. Not sure on whether this is going to be something that will be available

This is how I’ve set up my project. There’s a fair bit of control over what can be tested here.

Sidenote: There are two versions of Code Contracts – Standard and VSTS Edition. The only difference between the two is that the Static Checking is available with VSTS – which I think is the most important feature in terms of supporting design-by-contract. Insert sadface here. Guess its going to become like FxCop – a nice tool available and used by the percentage of the community who already do this sort of thing. Oh well. Back to regular transmission.

Having all that set up, I create an instance of my custom collection and try to add null to it (because I’m silly and trying to make a point). No compilation errors are raised, but I get a harsh warning message.

So I have two choices here: ignore the warning or fix it. Of course, I’m trying to make a point here, so I’m going to ignore it. Pressing F5 runs the app, but then I ...

Oh crap, that’s a lot of stack trace. I’ve highlighted the stack which is managed by Code Contracts, but this also gives us the option to debug the code.

The error that I ignored. Well, I guess I should fix it because the user’s not going to like that message either.

And the verification passes. Sweet.

If the shoe was on the other foot, and the supplier was at fault, you’d see a similar scenario.


Oh! That's what that line was supposed to do!

The Summary (people who have a short attention span, read this)

Code Contracts is a feature that will be available in .NET 4.0 that will allow developers to specify contracts in their code, which are exposed when the library is used by a third party. The tooling in Visual Studio is progressing along nicely (with enough guidance to help resolve issues without getting in the way) but the restriction on the static checking tools is something that will prevent many from utilizing Code Contracts to its fullest.

With the ongoing evangelism of practices to improve software development, I hope that this becomes another tool in the belt for good developers to build quality code – it is a different pattern to TDD, but I believe they can work side-by-side. It will be interested to see how this gets picked up by the community as .NET 4.0 heads towards going gold in March.

Thoughts on hashDB – 140 characters just isn’t enough

Brendan Forster — Tue, 07 Jul 2009 18:30:08 +0600

Long Zheng (who makes me tired just following his twitter feed) has, in the space of a few hours, taken an idea from a fun side project and turned it into a full-on site. It revolves around a centralised repository of hashes, which are managed by the community and accessible through a web service. He’s got a brief summary of his idea on the site and is looking for feedback.

The idea is solid (I’d use it, which is a good indicator) but I’d probably add a few things:

Trusted Users

While users can register and submit their own hashes, I’d like to streamline the hash input process by allowing people who already provide the correct hashes (that is, providing verification files with the download) to be permitted to directly upload the correct hash. Cut out the moderation, call them Trusted Users for the applications they provide, and focus on the files/downloads which do not already provide the mechanism to verify files.

Choice of Format

SHA-1 is the best choice for the moment – it doesn’t suffer from collisions like MD5 and is not computationally intensive. But what if things change? This probably falls into the “future-proofing” category but I’d like the site to be able to switch to format XYZ in the future, because the advancement (and security analysis) of the cryptography and digital signature field is rapidly changing. It wasn’t so long ago that MD5 was considered “safe”.

Descriptors + Metadata

Not sure what Long has in mind, but I’d like to see a number of optional information associated with each hash.

Malware Hazard: Invalid hashes are fine, but if a known hash is associated with some malware – think of those Win7 Beta ISOs which were freely available but included nasty surprises when you installed it – I’d like to warn others about it. Once it becomes apparent that the ISO I have is malicious, I’d like a mechanism to submit a comment about this hash to the site. It may not be an immediate change, but after a number of responses (other users may see the comment and verify it themselves) the moderators should flip the warning switch and consider it a serious risk.

Versioning: While you can have a file which is called ApplicationName.X.Y.Z.exe, what if I have an installer called setup.exe (I still get this a lot, particularly with small apps). What I’d love is to see information about the source of the file (who provided it), the actual version (date, number, whatever) and perhaps some release notes (I’m pushing my luck, I know).

Application History: With all this rich metadata (related products, versioning, comments), why not throw in some functionality to search for information about a specific application (assuming we’re linking hashes from related applications) that the site is tracking. The scenario for this feature may be like this: “I have application ABC and am getting some crashes when I follow the same series of steps. Google’s no help with a solution, the support process for the application is lacking (forums/phone/nonexistent/whatever) and I’m at my wits end. If I can point my installer at the DB and obtain a history of the application, I can quickly decide whether to try (and get my hands on) a different version or hit the bottle and tackle the problem tomorrow.

It could be as simple as a link to the product’s Downloads page, but it could also be a direct link if that is at all possible. This may not work as well (Codeplex for example comes to mind) for some sites, but many applications provide public FTP access to official releases, plus beta and nightly drops.

I’ll definitely keep an eye on how this turns out – he’s already looking for help with getting something out there. Good luck!

Why Current Operating Systems Suck: the Mouse

Brendan Forster — Sun, 05 Jul 2009 12:28:40 +0600

Background: Long Zheng mentioned an offer inviting people to get paid and provide feedback about their current experiences with operating systems. I can’t fault him for working to bridge the gap between OS makers and users (that’s gotta be the end result out of any research, otherwise its about as useful as shouting at a canyon), but I thought I’d go in another direction and vent directly about what is currently broken with the current crop of operating system. Partly because 20 minutes is not enough time to outline years of frustration and tired concepts, but mostly because the issues I have also have some historical context.

[All of the following should not be considered as fact. This is just the musings of a jaded geek. – Ed]

The Computer Mouse as a Concept

The current form of the mouse is a concept that come out of XEROX PARC in the early 70s. It had a metal ball underneath and three buttons on the top. There were some earlier versions which were much more radical (one even used a bowling ball as a component) but the essence of the mouse remains unchanged.

I am glad that the mouse style improved, however. Source: DigiBarn Museum

So, why change something that has been around for 30+ years and is attached to just about every computer out there? After playing around with other types of inputs which are designed to better represent natural gestures, such as stylus, touchscreens, big damn tables, and even tyre-changing addons, I can’t help but feel that it is time to stop building operating systems and software designed specifically for the mouse, and focus on progressing towards user interfaces.

You want specific reasons? Read on.

Fitts’ Law

Ever get frustrated when using a mouse that you have to carefully move so that you don’t overshoot a target on the screen (for example, the button to close a popup that’s appeared and distracted you)? That’s Fitts’ Law in action.

Having come from a Computer Science background, I was introduced to this theory in a subject called Event Driven Computing (which had a fair bit of work around user interfaces). Basically, this law states that the time to position the mouse cursor to a specific target is proportional to two things. The first is the distance (D) to travel, and the second is the width (W) of the target.

The law was first published in 1954, and has proven to be remarkable accurate in subsequent studies.

Apologies for the math. It won’t happen again (until the next time).

It became apparent when the graphical user interfaces started to become popular that the issue needed to be addressed. The most common fix for this is to put menus and commonly-used items at the edge of the screen, so that the user cannot overshoot the target area.

I’ve included a screenshot of how the position affects the “target region” when comparing Safari on OS X and Windows. OS X works around Fitts’ Law by moving the menu to the top of the screen (just don’t try and close the window itself). Windows just ignores the issue and forces the user to aim for a small region.

Safari for OS X (top) and Windows 7 (bottom)

Some operating systems work around Fitts’ Law better than others, but real estate at the edge of the screen is always at a premium (and if you have multiple monitors you sacrifice some of real estate to get a bigger desktop space), so I view this as a hack rather than a solution. Plus, most applications cannot push all their interactive elements to the outer (unless you’re doing something trivial like a document viewer, perhaps) so they need to design their applications so that the mouse gestures are optimised. That has lead to conventions like menus.

Sure, menus organise a lot of functionality. But can it be done better?

See all those keyboard shortcuts? That’s a good indicator that, after a while, users get sick of navigating menus with the mouse. Some applications that have a lot of functionality (this is from Visual Studio - you need to know shortcuts to maintain your sanity with using it) need to resort to using menus.

[Ed: I want to do some testing of whether Fitts’ Law applies to touch input – while it has some similarity to mouse input, I feel that it will perform better than using mouse input. Stay tuned.]

Why no Multi-User Interactions?

Ever get frustrated when you plug in a second mouse and expect (or desire) to see a second cursor appear?

Your average operating system is a single user experience. These days you can log in as different users (like in Unix and its derivatives) and you can have access multiple desktops running concurrently (eg. Remote Desktop). But at the desktop level, the standard is to have a single cursor and a single active window. That may have been something more suitable in yesterday’s world - where 640K was enough for anybody - but not for today’s world.

These days, I find myself wanting more. I find myself doing a fair bit of pair programming these days – whether it is throwing around ideas for implementing features or solving particular issues - but sharing a computer between two users is a tedious experience. Either we have one person coaching the other or we throw the keyboard and mouse between each other until the task is done.

To be honest, I’m not sure what I want specifically. But I do know that I want more freedom. I’m sure there’s some human-computer interaction rules that are violated by having multiple users being active at once, but that is beside the point.

Touch Gesture != Mouse Click

The Engineering Windows 7 blog has a nice overview of how touch gestures in Windows 7 behave - but they underlying vibe I get from the gestures is that they’re focusing too much on making touch behave like mouse clicks, instead of deliberately separating these features out. Things like this:

“Drag – Touch and slide your finger on screen. Like a dragging with a mouse, this moves icons around the desktop, moves windows, selects text (by dragging left or right), etc. This works everywhere.“

“Flicks – Flick left or right to navigate back and forward in a browser and other apps. This works in most applications that support back and forward.”

You’d think that these gestures are mutually exclusive, but what I’ve found while building applications is that the Flick is really specific (move X distance within a specific period of time), and the workaround of listening for a Drag on the window (and calling the navigation event you were expecting originally) introduces other issues – like FlowDocumentPageViewer text being highlighted.

“Zoom – Pinch two fingers together or apart to zoom in or out on a document. This comes in handy when looking at photos or reading documents on a small laptop. This works in applications that support mouse wheel zooming.“

This may seem silly, but when I manipulate objects on a touch surface, I perform the opposite gesture. This is also opposite to how the Surface ScatterView items behave - two fingers moving away from eachother will increase the size of the item, two fingers moving towards eachother will reduce the size of the item. [Ed: Here’s a quick video introducing the Surface concept that came up at REMIX Australia]

So which is it? I hope I’m wrong here (we ended up using our own code, rather than leaning on the default behaviours, so I can’t confirm that this is the default behaviour) but it shows that even a simple gesture such as zoom can be misinterpreted.

My personal favourite:

“Press-and-hold – Hold your finger on screen for a moment and release after the animation to get a right-click. This works everywhere. Or, press-and-tap with a second finger – to get right-click, just like you would click the right button on a mouse or trackpad. This works everywhere.”

1) You took my Hold Gesture (which is supposed to be a left-click) and turned it into a different mouse button after an arbitrary period of time. The only way I saw to get around this is to move your finger before the animation shows up, and that’s introducing a Drag gesture instead.

2) This is not intuitive. I found the first way of doing this by accident, and I didn’t even know about the 2nd way until I read the article. And don’t give me this whole “Macs were doing it for ages” excuse either – if its supposed to be a touch gesture, don’t map it to a right-click. Call it a context menu event or something similar.

I’m going to follow up on this particular topic as I’ve been throwing around some ideas with my boss (well, this was a while ago, I need to look back at what we actually discussed) about making gestures more discoverable. Surface is a great example of this – how do you guide the user through the functionality available without interfering with the user experience or requiring an instruction book to get started?

Got any solutions, angry guy?

As I said before, stay tuned. I want to delve a bit deeper into the current touch situation for Windows developers (I haven’t had a chance to try WPF 4.0 yet, I want to delve deeper into the Windows 7 Touch stuff once it RTMs, I want one of these to play around with) and I want to go into some greater detail about building applications that don’t rely on a mouse – and there are some tricky things like text selection and menu navigation that you’d think “No mouse? You must be mad!”.

Side Note: Silverlight 2 Windowless Browser Support

Brendan Forster — Sun, 07 Jun 2009 19:53:26 +0600

I was doing some site updates during the week (stuff unrelated to Silverlight actually) and came across this simple and intriguing issue. I thought I’d blog about this really specific issue because its been frustrating to say the least (and I have no idea when this will be resolved) and it was a stark reminder for me that Silverlight development is not at the point where it is a ubiquitous experience for some browsers.

Updated 9/6 – Re-tested with Safari 4 RTW.

Windowless Silverlight Content

One of the perks of using Silverlight plugins on a website is having the ability to blend XAML content and HTML content. I’ll use a simple example of a control that is semi-transparent to show how this blending works and where it falls down. The screenshots below show the XAML code of the plugin and and HTML code used to embed the plugin on the page. A photo is used for the HTML background.

XAML Code	HTML Code

First off, a test of the officially supported browsers:

IE8	Firefox 3.0.10

All good so far. The supported browsers work - IE6 and IE7 are dead to me for the purposes of this test. And in general. Hell, even my dad uses Firefox these days. Stop using IE6. Please.

Checking MSDN shows a laundry list of limitations about using windowless plugins. This doesn’t mean “never use windowless mode” but what I read as TEST YOUR PLUGIN IN OTHER BROWSERS.

So, I did. And what I found was not good. To ensure this is just a snapshot in time, I’ve included browser versions that I’ve tested this on – the Silverlight plugin I’m using is v2.0.40115.0.

Safari 4 for Windows

I tested this with the public Beta (released 12 May). What do you get? To use a non-technical term, bupkis. I kid you not, nothing gets rendered. Fantastic, here’s a screenshot of what I get. Note that if you right-click the region where the plugin should be, nothing happens. No Silverlight context menu, no Safari HTML menu, bupkis.

The annoying part of Safari 4 for Windows is that the Mac version supports windowless content (side note: it renders all content as windowless irrespective of what the plugin specifies – funky!) and renders the plugin content fine (I don’t have a Mac handy – yet). This may be just an issue with the beta (only been available for a couple of weeks). Safari 3 works fine with Silverlight 2 plugins – so I’m sure that it’ll be resolved between now and then.

EDIT 9/6 – Safari 4 for Windows came out of beta to celebrate WWDC. Problem still occurring.

Google Chrome and Chromium

The new browser on the block (and its open-source brother) started out with no support for Silverlight at all. So how does it handle this plugin now? This is using Chrome v2.0.172.30. As the screenshot below shows, the experience is better, but the transparency is being ignored. The same thing occurs on the latest Chromium build I could find (build 17842).

The Moral of the Story

Things I’ve learned from this:

1. Avoid using Windowless plugins unless required. This hinges on whether or not a large percentage of your visitors use Safari or Chrome, as well as on the numerous gotchas to keep in mind, such as CPU overhead, mouse events, full-screen mode and others. The situation may also dictate it.

2. Wait for Silverlight 3.0 for additional supported browser. I found a few threads on the Chrome boards about Silverlight 2.0 issues - most of them are resolved but this one (see last comment) makes me think that we may have to wait until Silverlight 3 to get full Silverlight 2.0 support in Chrome (which doesn’t sound right unless there are upstream issues).

3. Safari for Windows isn’t officially supported.

4. There isn’t much documentation around what Silverlight features work/don’t work in unsupported browsers (I haven’t even looked at Opera for this). The MSDN docs are vague, bug reports are sporadic, and most discussions I’ve seen on the Silverlight forums end with a “It doesn’t work” summary. Or have I missed some magic fountain of information about this?

Microsoft Extensibility Framework – Introduction and Sample

Brendan Forster — Sat, 09 May 2009 15:35:56 +0600

Introduction

MEF is new a library that enables extensibility to be added to an application. Extensibility isn’t a new concept, but MEF is an attempt by Microsoft to provide a single architecture across the .NET platform to enable flexible development of extensibility without having to roll your own code, or having to learn a completely new architecture when writing a plug-in for another application.

The other thing to note is that MEF is more than a CodePlex project – it is slated to be a part of .NET Framework v4. The latest previews have focused on making the libraries more developer friendly. The preview versions are available from the Codeplex site.

Using MEF in your Application

To get started using MEF, grab the latest drop from this page (Preview 5 at the time of writing this) and add a reference to System.ComponentModel.Composition.dll in your project.

Declaring Extensions

As a minimum, the class needs the Export attribute and a reference to the MEF assembly. The code snippet below shows the current contract attributes available (more than one Export attributes can be used on a class).

   1: using System.ComponentModel.Composition;

2:

   3: [Export]

   4: [Export(typeof(IExtension))]

   5: [Export("ExportTypeFoo")]

   6: [Export("ExportTypeFoo", typeof(IExtension))]

   7: public class MyExtension : IExtension

   8: {

   9:     // stuff here

  10: }

Use the first attribute if you are looking to use this type specifically. I’m not as sold on the value of this, as it seems excessive to use MEF to find something I already have referenced – perhaps I haven’t found the right use for it yet.

The second attribute is good if you have a defined interface which all extensions should implement. If you arrange your application so that the core (interfaces, business logic) is separate from the UI, then you can write extensions in a separate assembly which references the core (or a subset containing the interfaces), and then add the extensions assembly into a predefined folder to make it available at runtime.

The third attribute uses a string to define the contract type. This still suffers from the problems that come from using the first attribute, but I suppose its there for those times when you just don’t want to define interfaces.

The fourth attribute is for interfaces with a specific contract. For example, if you have an editor which allows extensions to be written to manipulate a text file. The editor supports right-click on selected text to run all available extensions, but also has a menu item with sections to group the extensions (eg Format, Transform, Validate). Rather than having multiple interfaces for each menu type, the grouping name and the interface becomes the contract type.

Consuming Extensions

One of my habits with consuming extensions is to wrap the functionality in a separate class. The code below shows the minimum that you need to configure a list of extensions:

   1: using System.ComponentModel.Composition;

   2: using System.ComponentModel.Composition.Hosting;

3:

   4: internal class BasicExtensionManager

   5: {

   6:     [ImportMany(typeof(IExtension))]

   7:     private List<IExtension> allExtensions = new List<IExtension>();

8:

   9:     public void Compose()

  10:     {

  11:         allExtensions.Clear();

  12:         var catalog = new AssemblyCatalog(Assembly.GetAssembly(typeof(IExtension)));

  13:         var container = new CompositionContainer(catalog);

  14:         var batch = new CompositionBatch();

  15:         batch.AddPart(this);

  16:         batch.AddExportedObject<AssemblyCatalog>(catalog);

  17:         container.Compose(batch);

  18:     }

19:

  20:     public List<IExtension> Extensions

  21:     {

  22:         get

  23:         {

  24:             return allExtensions;

  25:         }

  26:     }

  27: }

I’ve used the ImportMany attribute here to obtain multiple extensions (previous versions had this as an implicit behaviour of Import but this has been separated out with Preview 5). You also have access to the Import attribute if a single entity is required (for example, the catalog contains multiple items and you allow the user to select one, which is loaded into the application).

A few terms to note in the above snippet:

Catalog: the catalog can be an AssemblyCatalog, DirectoryCatalog or TypeCatalog. The catalog searches any found assemblies for the Export declarations mentioned above.

CompositionBatch: the Composition Batch is used to represent the “session” when using extensions. In this case I supplied the extension manager (which has a property with the Import declaration) and the catalog containing the extensions (which have the Export attributes as shown above). If the catalog is updated, the batch handles this (previously this had to be handled manually).

CompositionContainer: handles the mapping of import and export objects. You can query the exported items here, or simply pass a CompositionBatch and do it automatically.

The code to use this extension manager is shown below:

   1: BasicExtensionManager mgr = new BasicExtensionManager();

   2: mgr.Compose();

   3: foreach (var e in mgr.Extensions)

   4: {

   5:     Console.WriteLine(e.ToString());

   6: }

Demo: Single Instance Plugins

To drill down deeper on the importing of extensions, I thought I’d implement an extension manager that a) provides information about the types imported and b) creates instances of each available type for an application to use. For this sample, I have two extensions which are added to an application. ExtensionA can be created in multiple instances, but ExtensionB can only be used in a single instance. But how do we set this behaviour with MEF?

The extension author has control over how their extension is used, so they can specify whether or not their code can exist in multiple instances. The trick is to use the new PartCreationPolicy attribute.

The options to provide with this attribute are:

NonShared: A new instance is created for each type.

Shared: Only one instance of this type should exist at any time.

   1: [Export(typeof(IExtension))]

   2: [PartCreationPolicy(CreationPolicy.NonShared)]

   3: public class ExtensionA : IExtension

   4: {

   5:     // implementation

   6: }

7:

   8: [Export(typeof(IExtension))]

   9: [PartCreationPolicy(CreationPolicy.Shared)]

  10: public class ExtensionB : IExtension

  11: {

  12:     // implementation

  13: }

The consumer can also specify the creation policy for any imported extensions. This code snippet shows how the import can request extensions that are only single-instance:

   1: [ImportMany(typeof(IExtension), RequiredCreationPolicy=CreationPolicy.Shared)]

To test this behaviour I used a Guid property on each extension. This is generated the first time it is read (there are other ways create a unique identifier, the Guid was was quick and relatively straightforward). I wrote a different implementation of the Extension Manager that uses this code snippet to create a new instance of a specific type. The container contains the catalog with the available extensions.

   1: public IExtension CreateNewInstance(Type t)

   2: {

   3:     var result = container.GetExportedObjects<IExtension>()

   4:                     .Where(c => c.GetType() == t).SingleOrDefault();

   5:     // may get null if you pass an invalid type

   6:     return result;

   7: }

Now, when I run through the test suite and request multiple instances of each extension type, I get this resulting output. Extension A has a different identifier for each instance, and each instance of Extension B is simply a reference to the first instance.

Hooray!

Try it out

The sample I have included below has both extension managers and the tests used above. I’m aiming to have something more complex up next (need to polish the concept some more and do some refactoring of the application itself) but hopefully this is something that can be used as a starting point. The MEF assembly is included with this zip file.

Introduction

Brendan Forster — Sun, 03 May 2009 10:09:00 +0600

Welcome to my little place on the internet. Up until now I’ve been on the “consumer” side of blogging, so this is new territory for me (side note: I actually loathe the word “blog”, and I’ll always endeavour to use a better word in its place). If something requires clarification, or you have feedback to provide, just leave a note on the site or email me directly.

About Me

After growing up in Adelaide, I graduated from university with a Bachelor of Engineering (Computer Systems) and Bachelor of Maths and Computer Sciences in mid-2008. I’m now living in Sydney and currently working for nsquared solutions. The other details aren’t important right now, but if you want to beat the details out of me you’ll need to buy me a beer at a social event or something.

Background

Right now I’m wearing a .NET developer hat – this may change in the future, but for now that’s where the bulk of my experience lies, so I’m going to start off this blog (ugh, last time, I swear) by sharing my experiences in the .NET world. I mostly did Java through uni, with a bit of C and C++, perhaps I might touch on that a bit too, depending on the rust levels. My professional .NET adventures started when I did some part-time ASP.NET work while at uni, and while ASP.NET remains my core competency I’ve branched out recently to do work with Live Services, WPF and Silverlight.

Goals

A lot of the software developers I know and read recommend having your own blog space – writing skills are a completely different domain to writing code, and demonstrating a concept or API function to someone else is completely different to understanding it yourself – and I want to give back to the community and contribute to the body of knowledge available regarding .NET and software development.

There’s a whole bunch of new and updated tools and technologies coming out of Redmond recently, and with Win7 and .NET 4.0 on the horizon this is a very exciting time for anyone who is interested in playing around with new stuff. Specifically, I’ve been playing around with the Microsoft Extensibility Framework a bit over the last few days (got some basic samples, but needs some polish to finally be an awesome F5-style demo) and ASP.NET MVC continues to catch my eye (after wrapping up a WebForms project I’m going to put some time into that). Silverlight (in particular some of the v3 features) look to be blurring the lines between web, RIA and client applications. And Virtual Earth and Live Framework continue to evolve and grow, with updates and new features that seem to have been lost in the noise of other product announcements.

In addition to talking about .NET I hope to branch out more into the practices and concepts that are associated with software development, software engineering or whatever-you-wish-to-call-it-when-people-build-software. This is a young field, which is rapidly evolving, and there are many, many ways to get from A to B. I do not have all the answers right now. But over time, hopefully I can pick the brains of others in the industry, dissect opinions and articles from others, and add my insight and opinions to the process wherever appropriate.

I’ll also include some non-work stuff as it happens – because all work and no play makes Jack a dull boy.

Code Samples

While I agree with the sentiments of others - that we need to do more to improve the quality of code in use everywhere - many of the samples that will appear here will not demonstrate best practices initially – most of the ideas I have in place currently are around proof-of-concept work and demonstrations of specific features.

As concepts grow and evolve, my personal goal is to turn these samples into standalone applications - wherever there is a genuine interest in the community. Of course, some of these may be purely for fun or for mad-scientist-esque purposes, so not all of these will achieve greatness (or even mediocrity). So if something you see here fills a niche, let me know and perhaps we can organise some collaborate so that we can critique and refine and continue to drive interest and make the world a better place, one line of code at a time.

As others have said far more eloquently in a recent discussion on this, we need to do more around outlining what the sample includes and, more importantly, emphasize what the sample does not cover. Is there value in giving a sample the kid gloves treatment to protect that someone who does the F5-oh-look-it-works trick before using it elsewhere? Where is the point where the sample needs to satisfy the necessary requirements that production code is held to? Is there a happy medium? Can we even define succinctly what a “good sample” should constitute?

The only thing I’m sure of is that a samples should clearly define what it is not demonstrating.