autodeist.com

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

[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.

Having been house sitting for the past two weeks and having to catch up on a variety of things outside work - I haven't had much time to do anything on the brewing front.

But I have been able to get into the rhythm of the daily commute to work, at least - from where $partner and I were house sitting. A nice 12.8km ride in either direction, with some nice challenging climbs (by my standard) along the freeway.

In the week and a half that I've been commuting by bike, I managed to clock up about 180km. Awesomeness ensues...

Now I'm back home, and as of tomorrow will be doing the daily 9.6km, fairly flat ride from Innaloo to Subiaco. Should push past 1,000km on this bike in a few weeks easily with the odd weekend ride.

Combining this with being lazy and cheap by having meal replacements twice daily has also been a winner, and I've lost a bit of weight too - which is always nice. Swapped some stories and sachets with one of the managers at work, and confirmed that OptiFast VLCD is king. Also have a supply of emergency flavoured tuna in my desk for snacksies if I need.

Back to the not-so-healthy, but ever so fun SPIRITS! I managed to con my housemate into trying my liqueurs the other day:

* Mint Liqueur
* Coffee Liqueur
* Pear Schnapps
* Apple Schnapps

And the results are... promising! The mint liqueur used a ridiculous amount of mint and it shows, it tastes like very strong tooth paste, but not in a bad way.

The Coffee Liqueur is tasty and tastes like you'd expect it.

I haven't blended the Pear or Apple Schnapps yet, my favourite by far is Pear - as the rackings get sweeter you get a different range of mid/high range flavours from the Pear, though I think some flavour from ripening of the fruit also came through.

Apple was also ok, but was a very light and strong flavour - perhaps from the woody seeds present in the apple. I'd like to try this one again with a different variety of apple.

I also had some time to put together a from-scratch "Baileys" Irish cream recipe using thickened cream, Vanilla essence, and an Irish Whiskey I made with Still Spirits mix-in. It's nice, but the spirit base comes through quite strong. I will try again, but this time with Thick Cream instead of Thickened cream. My bad.

Over the course of this week, when I'm not working on slampt's alarm panel (see what I did there?), I'll be throwing on a Ginger Beer and another batch of spirit base.

Also, I've been taunted all week by Shay's tumblr posts about Milk Liqueur. That's right folks, motherfucking. milk. liqueur.

I think I'm going to have to give this a go as well... the concept is just too appealing to pass up. I hope Shay doesn't mind me doing the same thing... tough luck if she does :)

I'm now at the point where I think I need a huge collection of sealed glass jam/pickling jars to try various things out with... if you've got any spare, your donation is more than welcome.

The list of things I want to try is currently sitting at:

* Ginger Beer
* Ginger Wine
* Aged Bourbon
* Milk Liqueur
* Chilli Liqueur

... by the way, still not over Milk Liqueur.... but for now, bedfordshire calls.

Hell yeah. With my wash ringing in at a final 1.000 SG, I fired up the Turbo 500 still for it's inaugural run on Monday. All I can say is: wow.

The still fired up quickly, and boiled hard for little over an hour before putting out product. Not expecting it to start putting out so quickly, I ended up taking 150mL heads instead of 50mL (dissapointing) and got things underway.

In a little over three hours the still put out about 3.25L of spirit at a whopping 95%. Hooray. On the first run I managed to control the water column temperature fairly evenly - however on the second run I had to play about with it quite a lot.

The second run performed the same as the first, 3 hours, 3.25L of spirit at 94%. Joy. I wonder if the difference was because I didn't do the mandatory wash of the column packing between runs. Wash number three, which is scheduled this weekend - will be sure to give an indication.

I also need to get a small amount more of column packing - as there's a small amount of volume in the column that needs packing. That should increase the efficiency and produce better distillate, but at these percentages I can't really go much higher before the product starts using the moisture in the air to dilute itself.

All in all, very happy with the product - so now I can produce a bunch of base spirit for testing flavourings with.

So far the coffee liquer (not using my base) is delicious. It started off tasting like it was coffee added to spirit (funny that), but has aged really quite well.

I've also kicked off a Mint Liquer. 3/4 cup crushed mint, 150mL of 94% spirit and 150mL of sugar syrup. It smells crap now, but hopefully after a few weeks the mint flavour and odor really comes out and I can take it off the leaves.

Also in the works: Pear Schnapps, Apple Schnapps and Coconut Liqueur. I've got the ingredients, but now need to find a chance to put them all together.

Updates soon - I promise :)

UPDATE: Oh noes, it turns out I committed a blog faux pas - I've already got an article called Smells like teen spirit! Oh well...

To celebrate the silly season, leaving my job and regaining some sanity and the situation in general - I bought myself a present. Heh, any excuse would do - but in any case, I am now the proud owner of a Still Spirits Turbo 500 Still...

Isn't she pretty? I think she is. I've had a serious brewing hard-on for this piece of kit for at least the last six months now... now I've got to come through with the goods, so while the weather is good and I have some time off between jobs - it's brewing season!

So today I kicked off the Inaugural 100L wash. The batch is just a larger scale of my typical 25L dextrose wash (6kg dextrose, 21L water, EC1118 Yeast). However given the hotter weather and the brew store's lack of EC1118 for this quantity - I'm running with a Still Spirits Heat Wave Turbo.

I'm not a big fan of Turbo Yeast, and I've never really been afraid to say as much. However, given the improvements I've been making to my process, the heat factor here (this week the days are running up to 40+ degrees) and that I now have a quality still to work with - I'm willing to give it a go.

The original recipe was pretty straightforwards: 24kg Dextrose, 84L Water, 4 Sachets of Heat Wave Turbo Yeast. This should have yielded an OG of 1.093. After putting the wash together, it was 24kg Dextrose to 75L Water with an OG of 1.095 (ignore what's on my silly whiteboard in the photo). I put the difference down to the calculator I was using, which isn't really based around dextrose.

Anyway, at 2PM I pitched in the four sachets of Heat Wave Yeast into the wash which was at 37.2 deg. It's currently doing it's thing and should be done in about 3-4 days, I'll keep tabs on its progress and keep things documented.

From the yeast specs, I should expect to get just under 12% (or 12L of ethanol) in the final product. Not sure what to percentages I'll expect to pull off on my still, it touts ~93% average, but we will see.

In other news, I received a wine rack for Christmas which has been a huge help organising the area near my desk, which has been cluttered with wine bottles:

Yummy, now I just need to "clear" some space for future purchases. In the meantime however, I'll keep this page up to date with my brewing exploits...