Wow, four months since my last post - things have been busy, busy, busy.

I've recently moved house, sharing with $partner and her Mum while we save for a house. Whilst this is a good thing, I haven't really sorted out internet access to my computer - so everything has been moving at a snail's pace.

One of the worst things is trying to use my IMAP email on 3G. Being slow isn't so much of a problem, but the latency of 3G kills it. I was contemplating getting a laptop from work, and was discussing this with a good friend - who made a joke about moving my desktop to the cloud... so I did.

I've been looking for a solution that lets you run applications remotely with native windowing - similar to VMWare Unity, but remotely. The X display protocol does this for you, but you'd have to launch applications each time you start up a new session - you can't detach your windows from work and reattach them in the same state at home.

Having such lacklustre internet where I'm staying gave me the final nudge to give it a go. I signed up for a local VMWare vCloud provider and spun up a new server to give it a whirl.

First off, I'm quite happy with vCloud - it's a great platform for managing compute applications and for the most part, pretty easy to set up. Not cheap though, a regular VPS product from the same provider would have been a cheaper option, but I'm a snob and don't like Virtuozzo VPS products.

After getting an Ubuntu LTS box up and running and on the internet, I pulled down and installed nomachine. Nomachine is essentially poor man's Citrix, and lets you run remote X11 or Windows desktop sessions remotely, with some awesome caching.

Using nomachine to get a full Gnome desktop session was easy enough, but it's still not quite there. However, by editing the connection you can specify to run a single application modeless:

Which will do what you want successfully - you can launch applications like Thunderbird and Pidgin from your gnome-terminal instance and they will all present as modeless windows on your local machine.

But all the fun and games ends when that parent terminal process ends - meaning you have to tear down and restart all the processes every time you log in - no switching to the laptop and continuing a chat session whilst watching TV - which makes me sad, especially if I get one of those sexy Android tablets...

So what's the solution? Well, fortunately it's a solved problem.. kind of. There's a project called xpra, which acts as a detachable man-in-the-middle X-server to host your applications.

Installing this gives you a quick path to success, set up a shell script:

#!/bin/bash
DISP=":1337"
xpra start $DISP --start-child=gnome-terminal
echo "Waiting for start/upgrade of xpra..."
sleep 5 
xpra attach $DISP
echo "Exiting..."
sleep 5

Then modify the NX client to set the following startup command:

gnome-terminal -e "/path/to/startup.sh"

Firing up a session, your gnome-terminal process will either spawn or reattach to an xpra session running gnome-terminal. You can then spawn application processes under that process which will persist between nx (nomachine) sessions. Detaching is as straightforward as CTRL+C on the root gnome-terminal running your startup script ("xpra attach" runs blocking in the foreground until you kill it, when it will detach and hand the xpra session back to the daemon).

Prognosis?

Fun, interesting - but ultimately negative. A few points:

• Application Bugs - There are a few applications that cause the xpra/nx combination to bomb out, most notably the PDF Preview application
• System Tray - Applications such as Pidgin don't have a tray to dock through when running via xpra (though works fine natively through nx), so if you close the Buddy List you will lose your pidgin session
• It's slow - Despite all the wonderful caching, theres a perceptable lag working remotely and it gets in the way of productivity.
• xpra bugs - I've had a few applications dissapear from the xpra sessions altogether, running in the background but refusing to focus in my NX session, defeating the purpose of long-running applications.

So in the end, I think I will be packing this experiment in. More and more I'm convinced there's a greater need for client/server built applications such as Quassel - where you can attach/reattach your application with the application server transparently whilst handling UI on the client side. I wonder if there's room for any application frameworks to help handle this.... Maybe there's a project somewhere - but in the meantime I think it's time to bite the bullet and sort out cabling to my PC at home. Update:: Moments after posting this blog entry, my nomachine session has decided to drop all my applications and kill itself - just another sign that it's not ready for primetime.... sigh.

It's been a while since my last post, work has been keeping me fairly busy lately and my free time has been spent giving me a bit more time to have some time to myself.

On the brewing front, things have been quiet - the liqueur thing isn't really working out too well, I'm still having issues with the sharp nose on my spirits - but I'm still attributing that to the quad-stacked Turbo Yeast in my 100L wash... still trying to finish that one up so I can start stilling my normal recipe... expecting that to be a bit better.

When that has been wrapped up, I'll try my hand at some limoncello and macerations. Also on the agenda is putting some of my Ginger Beer into the fridge and giving that a taste test, as it's been almost six months since that was bottled.

The other big brewing plans I've been thinking about for a while is Cider. It's tasty, it's cheap and it's quite fashionable at the moment. Nobody I know has really done one though, so I've been a bit uncertain who I can bombard with little technical questions.

Ever lucky, my local brew store sent out an invitational for a Cider tasting and voting session for a new brew pub in West Perth, The Brown Fox. These guys have been open since March this year and have made their own wine and are moving onto brewing and selling their own Cider in the pub.

Unfortunately, due to a fat finger error when putting the event into my calendar - I missed the event and presentation by the owner on the technical side of making cider, not to mention the taste testing! Bugger.

Fortunately they had a really positive turnout and the owner, Greg, decided to invite those who were interested to come back for a monthly cider tasting/discussion at his venue. After a few quick emails, and several calendar reminders later - I attended my first monthly cider meeting.

Okay, so despite the big turnout at the first meeting - there was only four of us. Two of us were Cider newbies, so there was some really good discussion about cider making in general and some technical tips and tricks on getting the results you want.

Probably the biggest suprise was that the two cider brewers at the table both preferred brewing from store bought juice (preservative free, of course), rather than from the fruit themselves. Obviously there's a effort tradeoff there, but nobody seemed to think that there was any significant difference in the end product anyway.

So keeping that in mind, I'm keen to get my first Cider under way - hopefully as early as this weekend, assuming I can shuffle things around in my fermenters, maybe at a stretch to be ready for the next meeting, and maybe having something good to actually justify taking into work (yeah, right).

I've been working on some home automation software in C# for a friend and hit a bit of a stumbling block the other day. I needed to be able to register some message handlers for this application at runtime.

To do this, one needs to use the reflection framework - this allows you to inspect the assembly types and metadata at runtime, and is useful for this type of thing. This isn't exactly rocket science, and one can quickly throw together a quick example to discover each of the types that implement a given Interface/Subclass and make a method call to a static method on the class:

// Find all the types in this AppDomain that implement the IMessage interface
foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
{
    foreach (Type type in assembly.GetTypes())
    {
        if( type.IsSubclassOf( typeof(MessageBase) ) )
        {
            MethodInfo method = type.GetMethod("ImplementsMessage");
            MessageType msgType = (MessageType)method.Invoke(null, null);
            _messageHandlers.Add(msgType, type);

             Query the type and see what protocol message it handles
            try
            {
                // If any bit of this fails, we'll fail silently which is OK
                ConstructorInfo constructor = type.GetConstructor(new Type[0]);
                IMessage obj = (IMessage)constructor.Invoke(new object[0]);
                _messageHandlers.Add(obj.ImplementsMessage(), type);
            }
            catch
            {
                continue;
            }
        }
    }
}

The above example will call the static ImplementsMessage method on each class that is discovered that is a subclass of MessageBase.

This is well and goodly, but the problems start when you try and declare the ImplementsMessage in either an Interface or superclass. In this case, I have an Interface IMessage that I want all message handlers to implement. Interfaces and base classes are good, as we know, for defining a concrete contract to ensure that all of our classes implement the methods expected of them by the rest of the code - and are a key part of the design of this library.

Unfortunately, in any of the .NET languages - you cannot define static members in an object being inherited. Whilst the CLR can handle this, it's a design decision made by the .NET team over at Microsoft to not support it in their languages, though it seems that this is one they're looking at changing.

OK. So we can't define a static method, which isn't nice and elegant - but surely we can drop the static constraint and use the above code? Well, err... perhaps

In .NET, the CLR transparently sends an object reference to every method call made. The obvious exceptions are calls to a constructor when instantiating a new method, and calls to static methods. So it's imperative in the case above that we can always instantiate the object before we call the ImplementsMessage method.

This seems well and good, until you realise that .NET does not guarantee a default constructor as used in the example above. No, really - it doesn't. This might sound contradictory to some people, as the C# compiler will automatically create one for you if you use it on a fully qualified type at compile-time, but not at runtime.

That means the above sample will only work in the case you have explicitly defined a sane default constructor on your class at compile time. This is bad because we can't enforce this implementation with inheritance - so we're in the same problem as before: programming by convention rather than contract.

Fortunately there's a solution, and it's nowhere near as long winded as the explanation up until now. I cheekily hinted at it at the start of the article, and the answer is Custom Attributes.

Attributes are metadata you can attach to structural objects in .NET assemblies that can be reflected at runtime. If you're doing .NET, you've used them without realising. They're used heavily by components to provide information for the Visual Studio designer, are used to assign versioning and copyright information to the final assembly files as well as many other places within the framework.

By creating a custom attribute class, you can mark your classes, structs, enumerations and the like with strongly typed data that is available at runtime. This sounds like an excellent solution to the problem at hand! Here's the custom attribute class I wrote along with the updated code fragment to register these types at runtime:

[AttributeUsage(AttributeTargets.Class,AllowMultiple= true,Inherited=false)]
public sealed class HandlesMessage : Attribute
{
    readonly MessageType msgType;

    public HandlesMessage( MessageType inType )
    {
        this.msgType = inType;
    }

    public MessageType HandledType
    {
        get
        {
            return this.msgType;
        }
    }
}

foreach (Assembly assembly in AppDomain.CurrentDomain.GetAssemblies())
{
    foreach (Type type in assembly.GetTypes())
    {
        if( type.IsSubclassOf( typeof(MessageBase) ) )
        {
            // Look for the attribute saying what message they handle
            foreach (Attribute attr in type.GetCustomAttributes(false))
            {
                if (attr.GetType().Equals(typeof(HandlesMessage)))
                {
                    HandlesMessage hAttr = (HandlesMessage)attr;
                    _messageHandlers.Add(hAttr.HandledType, type);
                    break;
                }
            }
        }
    }
}

And here's a message handler being tagged:

[HandlesMessage(MessageType.InterfaceConfiguration)]
public class InterfaceConfigurationMessage : MessageBase
{
    // ...
}

And there you have it! It's a different paradigm, but still enforces the message to implement to the MessageBase contract as well as having to "register" to be picked up at runtime.

The message class itself will have to implement a few interface methods from IMessage to construct new objects, so in this case it's arguable that that might be just as valid a solution - but that has its own caveats.

For now, it's an elegant and simple way of registering message handlers in the application without relying on convention to ensure the message handler will behave as expected - and I've already had another opportunity to use custom attributes at my work to maintain backwards compatibility with some code that is being backported.

That's all for now - a more general update to come and no doubt some more C# and .NET examples too, as well as some iOS related items.