Mock Gravy

I think that it's time for another culinary discussion.

I love gravy. To me gravy is one of the great culinary delights and adds immeasurably to the right dishes.

The trouble is that I hate all instant gravies and have never felt that gravy recipes that did not involve the juices from roasting were really gravy.

In the end I resolved to come up with a way of making a good 'mock' gravy. It turns out that with the right tweaks it can make a really superior vegetarian gravy.

The fundamental idea is simple. To emulate the roasting process and produce the same flavours.

To do this I put oil (as a substitute for fat) in the bottom of a pan. Depending on whether I am trying to make a chickem, pork or beef 'mock' gravy, I use more or less oil.

To the oil I add a tablespoon of vegetable bouillon and two tablespoons of the appropriate other bouillon. I add a tablespoon of soy sauce, a drop of mushroom ketchup and a couple of tablespoons of lemon or lime juice.

You can optionally add some of the herbs that you would use for roasting, a little garlic and/or onion powder. If I'm making a beef gravy I will often also add a teaspoon of beef Bovril.

The next job is to heat the ingredients in the pan over a medium heat, stirring frequently. The intent is to recreate the process that in the bottom of a roasting tin.

The oil will stay somewhat separate from the other ingredients. You are looking to end up with the oil separated from a thick, glutinous liquor after cooking the ingredients. This should take a few minutes only. If you end up with a gritty mixture that will generally mean that the ingredients have been overcooked.

Now add enough flour to absorb the oil, mixing thoroughly.

Cook the flour and oil mixture for a minute or two. You want the flour cooked but not burnt so stir it continuously. The pan should now look to contain very dark brown bread crumbs.

Add 100-150 ml of cold water to the pan and stir hard. The flour will absorb the water and start to come together.

Now start adding the stock to the mixture a 50 ml or so at a time. Each time stir until the mixture (roux) has become smooth again and there are no more large lumps. The pan remains on the heat throughout this process.

When enough stock has been added the roux will have become runny and the rest of the stock can be addded.

Bring the pan back to the boil and taste. Season if desired. One can either add gravy granules/cubes or boil the gravy down (stirring frequently) until the desired intensity of flavour is achieved. Other flavours such as redcurrant jelly can be added at this time.

The gravy is now ready for serving. Pour it over a large helping of bangers & mash, a bowl of couscous or anything else that takes your fancy.

To make the vegetarian version simply use all vegetable bouillon and stock. This recipe scales up very well.

Ingredients

• Oil (vegetable, olive or something similar)
• Bouillon (I tend to use the Knorr 'Touch of Taste' bouillons)
• Soy Sauce
• Mushroom Ketchup
• Lemon or Lime Juice
• Roasting Herbs (Optional - Rosemary, sage, thyme etc.)
• Garlic Powder (Optional)
• Onion Powder (Optional)
• Beef Bovril (Optional)
• Flour
• 100 - 150 ml Cold Water
• 1 Litre of Good Stock
• Salt and Pepper

Good Threaded Code 2

I've been writing concurrent code in Java for some years now and like to believe that I've learnt a few things in the process.

In Java all objects have a mutex and monitor associated with them and so any object can be used to provide concurrency control and signalling. Java allows code to synchronize on any objects to which it has access, this includes the object declaring the code. In fact Java positively encourages you to synchronize on the declaring object by providing synchronized methods and allowing synchronized(this).
For example:

public class ConcurrentClass
{
    public void doSomething() 
    {
        //do something thread safe...
        ...
        //do something not thread safe...
        synchronized(this)
        {
            ...
        }
    }

    public synchronized void doSomethingElse() 
    {
        //do something not thread safe...
        ...
    }
}

When you call doSomething() or doSomethingElse() the mutex of the ConcurrentClass instance is only held for the duration of the synchronized block or the synchronized method.

I believe that this approach violates encapsulation. The mutex used to control the internal concurrency issues of the ConcurrentClass instance is available to other classes and so other classes can participate in the internal concurrency concerns of the ConcurrentClass instance. At first sight this might not seem a bad thing but just stop and think for a second. This means that concurrency control for a specific resource can be spread across several classes. Rather than debugging one class you may have to debug many.

I would far rather write something like:

public class ConcurrentClass 
{
    private Object mutex = new Object();
    ...
        
    public void doSomething() 
    {
        //do something thread safe...
        ...
        //do something not thread safe...
        synchronized(mutex)
        {
            ...
        }
    }

    public void doSomethingElse() 
    {
        //do something not thread safe...
        synchronized(mutex)
        {
            ...
        }
    }

}

This means that the mutex and thus the concurrency control is fully encapsulated within the class.

An example where the lack of encapsulation can cause a problem is in java.lang.Thread. I have seen application code that sub-classes java.lang.Thread and uses synchronized methods or synchronize on the thread object. If the application code deadlocks it becomes impossible to use any of the normal methods to control the thread as they are all synchronized on the thread themselves.

Idempotence? What's that?

When I'm architecting enterprise systems I often get that response when I talk about my preferred alternative to using 2 phase commits and XA.

Idempotence is not a particularly difficult concept. I define it as a behaviour that has the same outcome on the second, third, fourth etc. time of trying as it had on the first.

A lot of things in our day to day life are idempotent. Say you are going to the car with some bags. On reaching the car you put the bags down and go to unlock the car; you are then interrupted by a friend calling to you and you have a chat. When you turn back to the car you can't remember if you unlocked it or not so you go to unlock it again. If you had actually already unlocked the car, it will remain unlocked. Unlocking a car is normally idempotent - I'm not answerable for odd car designs or for people that actually lock their cars again when they do this.

This can be extremely useful when you are trying to integrate two disparate transactional systems. Lets call one system A and the other B. If we are doing something in A that needs a change to be applied in B we can make the change to B idempotent.

The process would often work like this.

1. Open a transaction in A.
2. Do the work in A.
3. Open a transaction in B.
4. Do the work in B. Idempotent
   
5. Close the transaction in B.
6. Close the transaction in A.

If a problem occurred in steps 1 to 5, systems A and B would be in a consistent state as both transactions would be rolled back. If a problem occurs at stage 6 then B would have the change while A doesn't.

When the process is re-run successfully A and B will end up in a consistent state as long as the work done at B is idempotent.

This is a much lighter weight mechanism that the 2 phase commit / XA one but it does mean that there is a window in which A and B can be inconsistent. For many systems this window may not be a problem in which case I'd recommend the use of idempotence.

Another month between posts.

A lot has happened to me in the past month. My cousin James came to visit, I faced eviction due to my landlord's non-payment of mortgage, I moved to a lovely new place in a converted chapel, I went speed dating and have spent an awful lot of time trying to get broadband into my new place so that I can work from home.

This morning I had a good breakthrough with JOGL - working out how to initiate an offscreen pixel buffer without needing a full blown AWT or Swing GL canvas.

With my life calming down a little (off to see the Two Gallants tomorrow in Brighton), I'll hopefully blog a little more.