I bought Expression Studio 3 a while back – it’s really not bad at all. Expression design is not up to Adobe Illustrator standards by any means but for my purposes it’s very serviceable. Personally the only feature I really found myself wishing for after using Illustrator is the gradient mesh. Fingers crossed for gradient mesh support in Expression Design version 4…

I designed the new Rowan Beach logo and web site graphics with Expression Design – it only took a few hours to get something looking half decent even though I was pretty new to the software (and some would say challenged from a design perspective) – the software is a lot simpler than Illustrator which makes it faster to pick up and use. Partly that’s because it doesn’t have the same feature set as Illustrator but I think it’s also because it’s new software with the benefit of a clean, fresh UI design.

Expression Blend is great for laying out Silverlight / WPF application screens (I’ve been using it mostly for Silverlight really) although it sometimes does nasty things to the XAML (e.g. it often adds negative margins all over the place when you surround something with a different layout container). If you stay in split view and keep an eye on the XAML that is being churned out it really works quite well. Overall I still tend to do a lot of layout in the visual studio XAML editor though  - the better auto-complete support with Resharper is great and being able to hit Ctrl+K, Ctrl+D to quickly reformat the XAML is very handy. I find that I normally swap back and forth between Visual Studio and Expression Blend when doing Silverlight layouts. Blend is pretty much indispensable for doing key-frame animations, especially for parts and states model transitions – those would be much more of a pain to code by hand in the XAML I wonder how things will change when Visual Studio 2010 is released, as that will have GUI designer support for XAML – time will tell. Oh, I should mention, Expression Blend can open Visual Studio .sln files which is really handy – both apps will auto load changes made in the other app too which works well normally, although occasionally I find that I need to restart Blend as it seems to get confused by changes that have occurred in Visual Studio.

As for the other tools in Expression studio, well I’m sure I’ll find a use for them eventually :)

The pace at which Microsoft are releasing new technologies at the moment is little short of astonishing. I had heard about the reactive framework a while ago but I didn't know it had actually shipped in any form yet. I ended up finding a use for this for the first time yesterday on a Silverlight project when I noticed that System.Reactive.dll had been installed as part of the Silverlight toolkit. On this app I'm creating a domain layer that will be shared by the Silverlight application on the client side and an asp.net application on the server side. I'm using a shared code approach for this at least until Silverlight 4 is released (via Visual Studio's 'Add existing item -> Add as link'). I had originally thought this would preclude me from using the reactive extensions in the shared domain model but then I stumbled across this: http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx. Basically Microsoft have already released the Reactive Extensions for 3 platforms - Silverlight, .NET 3.5 sp1 and .NET 4.0. So I was able to download the .NET 3.5 sp1 version and use the Reactive framework in both versions of my domain layer as I wanted to.

For a basic overview of the reactive framework, check out the Microsoft devlabs site (http://msdn.microsoft.com/en-us/devlabs/ee794896.aspx). Here's the most pertinent quote from the front page of the site:

Rx is a superset of the standard LINQ sequence operators that exposes asynchronous and event-based computations as push-based, observable  collections via the new .NET 4.0 interfaces IObservable and IObserver.  These are the mathematical dual of the familiar IEnumerable and IEnumerator interfaces for pull-based, enumerable collections in the .NET framework.  

Here’s a simple example (with most of the non-pertinent code removed from the classes) of how I’m using the IObservable interface where I would otherwise use a standard CLR event pattern.

public class Plan
{
    private readonly IList _selectedSurveyElements;
    private readonly Subject _surveyElementAdded;

    public Plan()
    {
        SurveyElementAdded = _surveyElementAdded = new Subject();
        _selectedSurveyElements = new List();
        _assetPlans = new List();
    }

    public IObservable SurveyElementAdded { get; private set; }

    public virtual IEnumerable SelectedSurveyElements
    {
        get { return _selectedSurveyElements; }
    }

    public void AddSurveyElement(SurveyElement surveyElement)
    {
        _selectedSurveyElements.Add(surveyElement);
        _surveyElementAdded.OnNext(surveyElement);
    }
}

public class AssetPlan
{
    private readonly IList _surveyElementPlans;

    public AssetPlan(Asset asset, Plan plan)
    {
        Asset = asset;
        Plan = plan;

        _surveyElementPlans = new List();

        plan.SurveyElementAdded
                .StartWith(plan.SelectedSurveyElements.ToArray())
                .Subscribe(x => _surveyElementPlans.Add(new SurveyElementPlan(x, plan)));
    }

    public Asset Asset { get; private set; }
    public Plan Plan { get; private set; }

    public IEnumerable SurveyElementPlans
    {
        get { return _surveyElementPlans; }
    }
}

The ‘interesting’ part here, is in the constructor for AssetPlan – the elements currently attached to the plan are converted to an IObservable and then concatenated with any elements that are added to the plan in the future (plan.SurveyElementAdded) and all of them are operated on inside the lambda. This would take more lines of code and be less ‘declarative’ using an event pattern.