Brendan Forster

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.

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?

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.

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.

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

    }

}

What does a contract look like?

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; }

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.

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!

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.

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.

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.

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.