It is true! Although I know some people who will give me a disgusted look if I say it in their presence...
October 2009 Archives
CAVEATS: This is 110% opinion with heaps of experience thrown in.
As an aside, in the real world there is far less conscious design than you realise. Sometimes this is a very good thing because it reduces confidence - mantras are like car sat-navs, rely on them totally and one day you might find yourself driving off a cliff because you trust it perfectly. YMMV (especially if you leave the road and plummet towards the ocean).
"The new keyword isn't inherently evil, but it may complicate your design later." Emphasis on may. (Context: using new Connection(db) over Connection.get(db) )
For example, say you have a database connection object and you want to set up a pool of X objects that you want to reuse. Rather than use the factory method, you could edit the Connection object such that is composed of e.g. a DatabaseSocket which interfaces with the database directly. Connection's constructor grabs a DatabaseSocket from the pool, and existing methods on the Connection object forward themselves to the DatabaseSocket. (delegation!)
From outside it's essentially the same, the methods do what you want them to, no knowledge of the DatabaseSocket required... the only difference is each Connection object can hold additional state as well as a reference to the (possibly shared) DatabaseSocket.
This could be very desirable, especially in multi-threaded scenarios. Consider the case where there is contention for a limited resource. With a factory method that directly hands you an object, the onus is usually on you to properly handle sharing and locking for that object. (It's not as simple as adding 'synchronised' to all the methods!) In addition, if other objects in the pool become unused but the object you were given is highly contended, you can't switch to another object unless your code specifically accounts for this. And, if your code accounts for this, the entire factory pattern is less of an abstraction and more of a distraction.
However, if you construct an object unique to you, one that delegates your commands to a shared resource, that object can alter its behaviour with respect to the resource, even storing command history and seamlessly replacing it with another resource if need be (consider distributed systems and a failing link, or simply a process that has crashed), you maintain the abstraction that you have *a* instance of the resource, which is often all you want.
Sharing objects is nice, but instantiating a brand-new object is always more powerful because in the worst case it can be a perfect proxy for another object, and thus replace the factory pattern entirely. Personally I see the factory pattern as an obtuse version of early optimisation, and as we all know it is a fool's game. We have refactoring for this kind of thing anyway, and at the very least, you can always s/new Connection/Connection.get/
My rule of thumb generally (and completely ignoring most uses of the factory pattern) is: 'do you want a brand new object of your very own, or are you happy being given an object to achieve what you want?' If you're doing anything with mutable state outside your program logic, you probably don't need to track any extra data outside of whatever exists externally, and you should ask whatever subsystem you are dealing with for appropriate objects to this effect. However, if you want additional data with your ice-cream sundae, the former is actually a sensible thing to do, and doesn't preclude you from changing the implementation of the created class so that it grabs the 'real' object elsewhere behind the scenes.
Besides which, factory methods won't magically make everything work if you change the underlying implementation. Integration testing still needs to be done, you almost certainly need to fix bugs in the edge cases. Anyone who has done multi-threaded programming will attest to the nightmare caused when you start changing things like this.
-----
Symmetric operations like Equals are not solved satisfactory by pure-OO approaches. Verbs are verbs, they exist without nouns if need be - Java makes this hard, but if you can, treat verbs like first-class beings. c.f. CLOS multiple dispatch. (Not that this is a perfect solution either, but I scribed this for future reference.)
Composition is often a good thing to use, but that really depends on what you're trying to achieve.
Liskov substitution principle - if you can adhere to that you can safely derive your class. Otherwise you will almost certainly run into errors later down the line, some quite gnarly and subtle - imagine if you program all Animals to jump(), then derive an Elephant from Animal...
Inheritance has its uses, but you need to be careful about what it really means. It's not about extending functionality as much as it is about telling people "Hey, I have a cool object here with special features I can use, but since it behaves exactly like this more basic object, you guys get to play with the same instance as me!".
Aside: as far as defensive programming is concerned, you can learn a lot by programming to a closed-source API like Windows. By the third time they screw you over by making some subtle change, you learn not to trust implementation details too much. (And besides which, classes change, code does, libraries... that's what integration testing is for, surely?)
Imagine you buy some skittles from the shop one day. Next week, you go in, and you try and do the same thing, but the shop keeper punches you in the nose before telling you "oh, if you want to purchase your item, you have to say 'Blooblebloo' and twirl the golden baton three times". No, you'd call the police for him being a menace to society and your now-bloody nose. Do you honestly expect your software to be any different?
If you change your interface such that invariants, preconditions and postconditions change, strengthen or weaken respectively, you will negatively effect other code up if they rely on it. This is not a fault with inheritance, interfaces, OOP or whatever - you told the programmer you'd always do something one way, deal with the consequences of changing it to something completely different. This is a seriously bad design flaw.
Aside: The Old New Thing is a blog about backwards-compatibility in Windows among other subjects, and reading that will prove many times over that taking interfaces at more than face value causes enormous problems. To be fair to the zillions of win32 developers, they had no power to change the APIs to expose hidden features they needed, so this kind of trickery was sadly inevitable for many years. You, on the other hand, have no excuse in open source-land.
Incidentally, Eiffel needs a big mention because it hasn't done in the lectures yet. Look up 'design by contract'. It's like first-class unit testing. It also eases a lot of the above issues by tightly coupling guarantees about your code with the code itself - you can't break them without it knowing about it, and likewise, calling code knows exactly what to expect from you.
Anyway, the trick is to design your interfaces so you give code as little guarantee as is possible while allowing useful things to be done. This gives you more freedom to change the implementation, add new methods, etc. assuming the calling code is bug-free and makes no wrong assumptions about your interface.
Think about real-life contracts which lock down so much and try to close loopholes. There's a good reason why they do that, annoying as it is, so perhaps you should consider closing the ambiguity in your own software so that everybody is playing to the same rules.
What annoys me about interfaces though is that you're forced to do a fair amount of donkey work to use them. Think of the high-water-mark stack example and my suggestion to override all the push() methods so that it works. Doable, not pleasant, though, is it?
A superior solution to interfaces - and to the occasional twisted desire to have multiple inheritance - is traits, as implemented by Squeak Smalltalk and Scala on the JVM. Traits promote behaviour reuse rather than the combined state+behaviour reuse of inheritance. Mixins are similar, slightly less powerful and harder to manipulate in complicated cases, but at least are available in languages like Python and Lisp. Scala lies between these two with its own traits implementation (and, as a JVM language, has the benefit of being compilable, which I am sure will please Ian immensely and hopefully encourage him to look at it if he hasn't already done so!)
More on traits: http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf
Hopefully someone will find that enlightening.
And most importantly, there is more to program design than OO!
As an aside, in the real world there is far less conscious design than you realise. Sometimes this is a very good thing because it reduces confidence - mantras are like car sat-navs, rely on them totally and one day you might find yourself driving off a cliff because you trust it perfectly. YMMV (especially if you leave the road and plummet towards the ocean).
"The new keyword isn't inherently evil, but it may complicate your design later." Emphasis on may. (Context: using new Connection(db) over Connection.get(db) )
For example, say you have a database connection object and you want to set up a pool of X objects that you want to reuse. Rather than use the factory method, you could edit the Connection object such that is composed of e.g. a DatabaseSocket which interfaces with the database directly. Connection's constructor grabs a DatabaseSocket from the pool, and existing methods on the Connection object forward themselves to the DatabaseSocket. (delegation!)
From outside it's essentially the same, the methods do what you want them to, no knowledge of the DatabaseSocket required... the only difference is each Connection object can hold additional state as well as a reference to the (possibly shared) DatabaseSocket.
This could be very desirable, especially in multi-threaded scenarios. Consider the case where there is contention for a limited resource. With a factory method that directly hands you an object, the onus is usually on you to properly handle sharing and locking for that object. (It's not as simple as adding 'synchronised' to all the methods!) In addition, if other objects in the pool become unused but the object you were given is highly contended, you can't switch to another object unless your code specifically accounts for this. And, if your code accounts for this, the entire factory pattern is less of an abstraction and more of a distraction.
However, if you construct an object unique to you, one that delegates your commands to a shared resource, that object can alter its behaviour with respect to the resource, even storing command history and seamlessly replacing it with another resource if need be (consider distributed systems and a failing link, or simply a process that has crashed), you maintain the abstraction that you have *a* instance of the resource, which is often all you want.
Sharing objects is nice, but instantiating a brand-new object is always more powerful because in the worst case it can be a perfect proxy for another object, and thus replace the factory pattern entirely. Personally I see the factory pattern as an obtuse version of early optimisation, and as we all know it is a fool's game. We have refactoring for this kind of thing anyway, and at the very least, you can always s/new Connection/Connection.get/
My rule of thumb generally (and completely ignoring most uses of the factory pattern) is: 'do you want a brand new object of your very own, or are you happy being given an object to achieve what you want?' If you're doing anything with mutable state outside your program logic, you probably don't need to track any extra data outside of whatever exists externally, and you should ask whatever subsystem you are dealing with for appropriate objects to this effect. However, if you want additional data with your ice-cream sundae, the former is actually a sensible thing to do, and doesn't preclude you from changing the implementation of the created class so that it grabs the 'real' object elsewhere behind the scenes.
Besides which, factory methods won't magically make everything work if you change the underlying implementation. Integration testing still needs to be done, you almost certainly need to fix bugs in the edge cases. Anyone who has done multi-threaded programming will attest to the nightmare caused when you start changing things like this.
-----
Symmetric operations like Equals are not solved satisfactory by pure-OO approaches. Verbs are verbs, they exist without nouns if need be - Java makes this hard, but if you can, treat verbs like first-class beings. c.f. CLOS multiple dispatch. (Not that this is a perfect solution either, but I scribed this for future reference.)
Composition is often a good thing to use, but that really depends on what you're trying to achieve.
Liskov substitution principle - if you can adhere to that you can safely derive your class. Otherwise you will almost certainly run into errors later down the line, some quite gnarly and subtle - imagine if you program all Animals to jump(), then derive an Elephant from Animal...
Inheritance has its uses, but you need to be careful about what it really means. It's not about extending functionality as much as it is about telling people "Hey, I have a cool object here with special features I can use, but since it behaves exactly like this more basic object, you guys get to play with the same instance as me!".
Aside: as far as defensive programming is concerned, you can learn a lot by programming to a closed-source API like Windows. By the third time they screw you over by making some subtle change, you learn not to trust implementation details too much. (And besides which, classes change, code does, libraries... that's what integration testing is for, surely?)
Imagine you buy some skittles from the shop one day. Next week, you go in, and you try and do the same thing, but the shop keeper punches you in the nose before telling you "oh, if you want to purchase your item, you have to say 'Blooblebloo' and twirl the golden baton three times". No, you'd call the police for him being a menace to society and your now-bloody nose. Do you honestly expect your software to be any different?
If you change your interface such that invariants, preconditions and postconditions change, strengthen or weaken respectively, you will negatively effect other code up if they rely on it. This is not a fault with inheritance, interfaces, OOP or whatever - you told the programmer you'd always do something one way, deal with the consequences of changing it to something completely different. This is a seriously bad design flaw.
Aside: The Old New Thing is a blog about backwards-compatibility in Windows among other subjects, and reading that will prove many times over that taking interfaces at more than face value causes enormous problems. To be fair to the zillions of win32 developers, they had no power to change the APIs to expose hidden features they needed, so this kind of trickery was sadly inevitable for many years. You, on the other hand, have no excuse in open source-land.
Incidentally, Eiffel needs a big mention because it hasn't done in the lectures yet. Look up 'design by contract'. It's like first-class unit testing. It also eases a lot of the above issues by tightly coupling guarantees about your code with the code itself - you can't break them without it knowing about it, and likewise, calling code knows exactly what to expect from you.
Anyway, the trick is to design your interfaces so you give code as little guarantee as is possible while allowing useful things to be done. This gives you more freedom to change the implementation, add new methods, etc. assuming the calling code is bug-free and makes no wrong assumptions about your interface.
Think about real-life contracts which lock down so much and try to close loopholes. There's a good reason why they do that, annoying as it is, so perhaps you should consider closing the ambiguity in your own software so that everybody is playing to the same rules.
What annoys me about interfaces though is that you're forced to do a fair amount of donkey work to use them. Think of the high-water-mark stack example and my suggestion to override all the push() methods so that it works. Doable, not pleasant, though, is it?
A superior solution to interfaces - and to the occasional twisted desire to have multiple inheritance - is traits, as implemented by Squeak Smalltalk and Scala on the JVM. Traits promote behaviour reuse rather than the combined state+behaviour reuse of inheritance. Mixins are similar, slightly less powerful and harder to manipulate in complicated cases, but at least are available in languages like Python and Lisp. Scala lies between these two with its own traits implementation (and, as a JVM language, has the benefit of being compilable, which I am sure will please Ian immensely and hopefully encourage him to look at it if he hasn't already done so!)
More on traits: http://scg.unibe.ch/archive/papers/Scha03aTraits.pdf
Hopefully someone will find that enlightening.
And most importantly, there is more to program design than OO!
Cheap lazy bugger like me? I know you are. Here's a recipe that'll get you some delicious fajitas without paying a premium for certain branded powdered mixes
Ingredients
Add the peppers, onions, chillis and crushed garlic, and fry it all for a few minutes more. Add all the spices and mix well. Pour all the cold water in - this will release the fond, or stuck bits of meat, from the pan and into the liquid. Add the lime juice and cornflour, stir well, and reduce for a few minutes.
Serve with wraps and enjoy.
What, you want pictures too? Sighhhhhhh
Ingredients
- 500g chicken, sliced into small strips
- two-three peppers, sliced into short strips (the more colourful the better)
- three small onions, quartered and chopped (I like to add a red onion, both for colour and because they're my favourite!)
- two red/green chillis (or use 2tsp crushed chilli instead)
- four cloves garlic, crushed
- 5tsp paprika
- 4tsp black pepper
- 3tsp cumin
- 3tsp salt
- 3tsp dark muscovado sugar
- 1tsp oregano
- 1/2tsp thyme
- 200ml cold water
- lime juice, freshly squeezed
- heaped tsp cornflour, placed in a ramekin with a little water added to form a thick paste
Add the peppers, onions, chillis and crushed garlic, and fry it all for a few minutes more. Add all the spices and mix well. Pour all the cold water in - this will release the fond, or stuck bits of meat, from the pan and into the liquid. Add the lime juice and cornflour, stir well, and reduce for a few minutes.
Serve with wraps and enjoy.
What, you want pictures too? Sighhhhhhh
I'm still seething over a lecture I had last week, which proclaimed that Java is "the example of an object-oriented language". Perhaps, if your only experience of programming is BASIC and C, and are completely ignorant of the history of the term 'object-oriented' or even its true meaning. Then again, what do I expect? We were taught UML the week before - nothing says "mediocre creativity-devoid engineer" more than a codified system for drawing stick figures and circles in the right places.
There's a pretty good example of an object-oriented language that existed 20 years before the development of 'Oak' (which, incidentally, was a far more descriptive name than Java - it grows incredibly slowly into a huge behemoth of source code, it's barely pliable, and has many branches making up the 'standard library', several of them very rotten a.k.a. 'deprecated'). Some might even call it the canonical example.
That object-oriented language is called Smalltalk. You may have heard of it. It came from the great computer idea factory called Xerox PARC, and is notable for being one of the few concepts Apple didn't steal outright. Its designer, Alan Kay, coined the term 'object-oriented programming'. In this language, everything is an object, and there is no concept of integral types (not strictly an issue in Java due to boxing, but this only serves to increase the confusion in that language). An object's state is completely private to the object, and all communication is done via message-passing - you might know this as a 'method call'. OK, not a big difference, right?
There was one odious example given in our lecture, that of a 'Money' class, and summing several amounts of Money. One wrong approach was to implement a 'getAmount' method and use that to sum, which breaks if you change the type used to represent amounts, say, from double to int. This is a problem with explicit typing, in fact - any language that features generic programming concepts like Lisp, Haskell, even C++ if you are careful, wouldn't give a damn about that. The 'correct' solution to this problem, at least in the backwards world of Java, is to create an 'add' method of the Money class and use that instead. Congratulations, you've just created a competing and incompatible solution to the already-well-known semantics of adding two things, namely the + operator, because operator overloading was made impossible. Then again, the semantics of + were already broken by string concatenation, so even a generic 'sum' function would be flawed.
It's not as if the alternatives are a bed of roses, though. Alan Kay himself has said that Smalltalk was not the language he had intended it to be, instead longing for a more organic approach to software.
The problem with object-oriented design in its current incarnation is a problem with how we reason with the world. We think of verbs and nouns, not of the processes involved, and when placed in a system like Java - a system that insists, nay, demands that everything you do belongs to a class (or an XML file, if you're unlucky) - that's all you think of. Nouns. Nouns that contain other nouns and verbs which let you interact with the nouns so that other nouns aren't tightly coupled with your nouns and verbs that kinda don't belong to the noun but you haven't got a better noun to put it and oh god now we need a VisitorMediatorFactory because the type system and single dispatch won't let us do things in an obvious way.
The question is, what is the right way to do this? Going back to Alan Kay, and after watching his keynote speech at OOPSLA '97 we can see his idea for a more biological approach. What is crazy from my perspective is that earlier Smalltalk versions are far truer to his idea of independently-operating, self-contained biological agents, or actors, than Smalltalk-80's thinly-veiled subroutine calls. Why the change?
One thing I can be grateful to Java for is that its takeup by industry has provided us with a rather robust, widely-available and well-tested VM, and one that other people can design their own languages for. Having examined a lot of the emerging languages, Scala seems to be an interesting mix of object-orientedness, functional programming and the actor model, and looking at the examples provided, I am sorely tempted to give it a go for my next games project. Alternatively, I could just say 'screw it' and use Lisp/Clojure instead, saving me the trouble of Greenspunning further down the road.
However, the only way to see if an approach really works in practice is to try it for yourself. Computer science would benefit so much more from analyses of large-scale projects, their design weaknesses, potential solutions for these problems and the impact it would have on the other parts of the design. Maybe this has been done already. But unfortunately, in the real world we have to deal with mediocre programmers on large projects somehow, and I fear that all the will in the world won't improve that particular problem. Just ladlefuls of Java and UML, and weird cultish methodologies designed to prod drones into working well rather than improving the field outright. Sighhhhhhhh.
Anyway, the point is, this is not the kind of thing a top-ten university should teach. It is quite telling that process is described in far more detail than how to create a good design, although what it tells me I don't yet know. One day...
There's a pretty good example of an object-oriented language that existed 20 years before the development of 'Oak' (which, incidentally, was a far more descriptive name than Java - it grows incredibly slowly into a huge behemoth of source code, it's barely pliable, and has many branches making up the 'standard library', several of them very rotten a.k.a. 'deprecated'). Some might even call it the canonical example.
That object-oriented language is called Smalltalk. You may have heard of it. It came from the great computer idea factory called Xerox PARC, and is notable for being one of the few concepts Apple didn't steal outright. Its designer, Alan Kay, coined the term 'object-oriented programming'. In this language, everything is an object, and there is no concept of integral types (not strictly an issue in Java due to boxing, but this only serves to increase the confusion in that language). An object's state is completely private to the object, and all communication is done via message-passing - you might know this as a 'method call'. OK, not a big difference, right?
There was one odious example given in our lecture, that of a 'Money' class, and summing several amounts of Money. One wrong approach was to implement a 'getAmount' method and use that to sum, which breaks if you change the type used to represent amounts, say, from double to int. This is a problem with explicit typing, in fact - any language that features generic programming concepts like Lisp, Haskell, even C++ if you are careful, wouldn't give a damn about that. The 'correct' solution to this problem, at least in the backwards world of Java, is to create an 'add' method of the Money class and use that instead. Congratulations, you've just created a competing and incompatible solution to the already-well-known semantics of adding two things, namely the + operator, because operator overloading was made impossible. Then again, the semantics of + were already broken by string concatenation, so even a generic 'sum' function would be flawed.
It's not as if the alternatives are a bed of roses, though. Alan Kay himself has said that Smalltalk was not the language he had intended it to be, instead longing for a more organic approach to software.
The problem with object-oriented design in its current incarnation is a problem with how we reason with the world. We think of verbs and nouns, not of the processes involved, and when placed in a system like Java - a system that insists, nay, demands that everything you do belongs to a class (or an XML file, if you're unlucky) - that's all you think of. Nouns. Nouns that contain other nouns and verbs which let you interact with the nouns so that other nouns aren't tightly coupled with your nouns and verbs that kinda don't belong to the noun but you haven't got a better noun to put it and oh god now we need a VisitorMediatorFactory because the type system and single dispatch won't let us do things in an obvious way.
The question is, what is the right way to do this? Going back to Alan Kay, and after watching his keynote speech at OOPSLA '97 we can see his idea for a more biological approach. What is crazy from my perspective is that earlier Smalltalk versions are far truer to his idea of independently-operating, self-contained biological agents, or actors, than Smalltalk-80's thinly-veiled subroutine calls. Why the change?
One thing I can be grateful to Java for is that its takeup by industry has provided us with a rather robust, widely-available and well-tested VM, and one that other people can design their own languages for. Having examined a lot of the emerging languages, Scala seems to be an interesting mix of object-orientedness, functional programming and the actor model, and looking at the examples provided, I am sorely tempted to give it a go for my next games project. Alternatively, I could just say 'screw it' and use Lisp/Clojure instead, saving me the trouble of Greenspunning further down the road.
However, the only way to see if an approach really works in practice is to try it for yourself. Computer science would benefit so much more from analyses of large-scale projects, their design weaknesses, potential solutions for these problems and the impact it would have on the other parts of the design. Maybe this has been done already. But unfortunately, in the real world we have to deal with mediocre programmers on large projects somehow, and I fear that all the will in the world won't improve that particular problem. Just ladlefuls of Java and UML, and weird cultish methodologies designed to prod drones into working well rather than improving the field outright. Sighhhhhhhh.
Anyway, the point is, this is not the kind of thing a top-ten university should teach. It is quite telling that process is described in far more detail than how to create a good design, although what it tells me I don't yet know. One day...
I have a simple recipe for making chocolate syrup, great for milkshakes and in coffee. It's really delicious, not overly sweet, and is great to add an extra flavour to strong drinks without turning it into a sugary abomination.
Ingredients
Transfer to a heatproof container, leave to cool with the lid off, then strain it into your jar. (I can't help but find a couple of lumps every time I do it. If you don't care about that too much, you could just not bother with that step, perhaps?)
OK, so now you've done that, a choccaccino is a cappuccino with two teaspoons of chocolate syrup. And here is an exampl- oh, no, sorry... it was just too good to let it just stand there.
Man waits for no coffee. And that's just the way it should be. (Better pics next time, I'll promise not to be an impatient sod.)
Ingredients
- 1.5 cups demerara sugar (feel free to use caster sugar, but it's sweeter than I like)
- 1 cup water
- 30g liquid glucose
- 1.5 cups cocoa, sifted
- 1 tsp vanilla extract
- Heatproof container for cooling
- a sterile jar or bottle to keep it in
Transfer to a heatproof container, leave to cool with the lid off, then strain it into your jar. (I can't help but find a couple of lumps every time I do it. If you don't care about that too much, you could just not bother with that step, perhaps?)
OK, so now you've done that, a choccaccino is a cappuccino with two teaspoons of chocolate syrup. And here is an exampl- oh, no, sorry... it was just too good to let it just stand there.
Man waits for no coffee. And that's just the way it should be. (Better pics next time, I'll promise not to be an impatient sod.)
A lusciously rich treat that goes nicely with a cappuccino
These are probably my favourite muffins to make, containing two-and-a-half of my favourite ingredients: raspberry, dark chocolate, and a little coffee to help it all blend together.
Ingredients (makes 4)
spot the raspberries
Preheat the oven to 200°C (180°C fan). Line your muffin tin with paper cases - sometimes I like to cut out squares of greaseproof paper and use those instead, but fitting them into the tin can be a little tricky.
Beat the sugar and butter together until light and fluffy. I used a wooden spoon for this, but switched to a whisk for the remainder so that the mixture gets reasonably airy. (Also, it's a lot easier to mix like that if you have a decent whisk!) Add the egg and beat until you have a consistent runny mixture.
unlisted ingredient: elbow grease
Pour in the espresso, and the same amount of single cream - or whatever dairy substitute you feel like today. I'm quite a creamy person, which can get rather messy at times. Ahem. Add a smidge of vanilla at this stage, too, and give it a quick whisk.
Espresso gives colour and flavoursome strength to your mixture, taking the edge off the sweetness of the batter and placing your focus on the raspberries and chocolate
Sift the flour, baking powder and salt into the bowl. As you can see, I like to save on washing up by weighing the flour directly into the bowl and sieve, but there is a lot to be said for mise en place, especially when you're using egg whites or anything equally volatile.
Fun fact: my height in inches
Oh, and mix it in well. Shouldn't take you long with that whisk.
Next step... chopped chocolate...
You know those boxes of broken biscuits? They should sell boxes of broken chocolate, too. I know you can get misshapes at Cadbury's World, but it's just not the same.
...and raspberries, all in. Just fold the mixture to spread it all the way through, you've got to keep it lumpy. You should find it rather sticky now, too. Don't be afraid to use your fingers (a good lesson in life, except in sausage factories).
A thinly-veiled excuse to lick it off your finger afterwards
A little mess is fine, and gives you yet another excuse to eat crispy muffin mix from the tin once it's done
OK, now we're ready! Fill the muffin cases aaaand...
Rise, sir Muffin
...we're go! Now all you have to do is wait for 20-25 minutes. Plan ahead, make yourself two espressos at the start. It'd what I'd do.
At about 20 minutes, test with a skewer - it might need doing a little longer, I've never trusted ovens to be too reliable. If all goes to plan you'll get something like this:
Looks nice, huh? But they're lacking a little something... hmm, what about drizzling coffee and chocolate icing over them? Or a ganache with white chocolate shavings (which I save for my Triple Chocolate Muffins, more on them another time)? Or better still...
Alternative method: place in popcorn maker. Do not try that at home unless you need the insurance money.
Toasted pine nuts complement the taste beautifully. Add them before you put the muffins in the oven, so that by the time you take them out they'll be encrusted with them. Trust me, it's excellent - you won't regret it.
(The more observant will notice I intended to do this. Yes, I forgot, I was far too busy taking pictures to remember or I definitely would've presented them to you. On the bright side, they made a simply looovely pesto, and you'll get to see what I did with that tomorrow. One for the vegetarians!)
These are probably my favourite muffins to make, containing two-and-a-half of my favourite ingredients: raspberry, dark chocolate, and a little coffee to help it all blend together.Ingredients (makes 4)
- 35g golden caster sugar
- 35g butter, softened
- 1 egg, beaten
- 1 shot of espresso or 50ml strong coffee
- few drops of vanilla essence
- 50ml single cream
- 100g plain flour
- 1 level tsp baking powder
- pinch of salt
- 50g raspberries
- 50g dark chocolate, chopped or chips
spot the raspberriesPreheat the oven to 200°C (180°C fan). Line your muffin tin with paper cases - sometimes I like to cut out squares of greaseproof paper and use those instead, but fitting them into the tin can be a little tricky.
Beat the sugar and butter together until light and fluffy. I used a wooden spoon for this, but switched to a whisk for the remainder so that the mixture gets reasonably airy. (Also, it's a lot easier to mix like that if you have a decent whisk!) Add the egg and beat until you have a consistent runny mixture.
unlisted ingredient: elbow greasePour in the espresso, and the same amount of single cream - or whatever dairy substitute you feel like today. I'm quite a creamy person, which can get rather messy at times. Ahem. Add a smidge of vanilla at this stage, too, and give it a quick whisk.
Espresso gives colour and flavoursome strength to your mixture, taking the edge off the sweetness of the batter and placing your focus on the raspberries and chocolateSift the flour, baking powder and salt into the bowl. As you can see, I like to save on washing up by weighing the flour directly into the bowl and sieve, but there is a lot to be said for mise en place, especially when you're using egg whites or anything equally volatile.
Fun fact: my height in inchesOh, and mix it in well. Shouldn't take you long with that whisk.
Next step... chopped chocolate...
You know those boxes of broken biscuits? They should sell boxes of broken chocolate, too. I know you can get misshapes at Cadbury's World, but it's just not the same....and raspberries, all in. Just fold the mixture to spread it all the way through, you've got to keep it lumpy. You should find it rather sticky now, too. Don't be afraid to use your fingers (a good lesson in life, except in sausage factories).
A thinly-veiled excuse to lick it off your finger afterwardsA little mess is fine, and gives you yet another excuse to eat crispy muffin mix from the tin once it's doneOK, now we're ready! Fill the muffin cases aaaand...
Rise, sir Muffin...we're go! Now all you have to do is wait for 20-25 minutes. Plan ahead, make yourself two espressos at the start. It'd what I'd do.
At about 20 minutes, test with a skewer - it might need doing a little longer, I've never trusted ovens to be too reliable. If all goes to plan you'll get something like this:Looks nice, huh? But they're lacking a little something... hmm, what about drizzling coffee and chocolate icing over them? Or a ganache with white chocolate shavings (which I save for my Triple Chocolate Muffins, more on them another time)? Or better still...Alternative method: place in popcorn maker. Do not try that at home unless you need the insurance money.Toasted pine nuts complement the taste beautifully. Add them before you put the muffins in the oven, so that by the time you take them out they'll be encrusted with them. Trust me, it's excellent - you won't regret it.
(The more observant will notice I intended to do this. Yes, I forgot, I was far too busy taking pictures to remember or I definitely would've presented them to you. On the bright side, they made a simply looovely pesto, and you'll get to see what I did with that tomorrow. One for the vegetarians!)
Attaching a mask depicting the eye of Sauron to a camera lens simply turns it into a giant poppy, thus losing any impact it possibly could've had. It wouldn't even scare a fainting goat.
It could be worse though. At least I made a half-arsed attempt at a costume, with a vaguely intelligent reason for choosing it. Besides, I only did it because I'm far too nice to show up everybody else by wearing a superior costume. That's my excuse and I'm sticking to it. Now excuse me for a moment while I peer down rapidly at everyone snapping pictures. (Thankfully for them, the girls had enough sense to wear high-necked dresses!)
Later this weekend: step-by-step guide to raspberry mocha muffins, full of luscious pictures.
It could be worse though. At least I made a half-arsed attempt at a costume, with a vaguely intelligent reason for choosing it. Besides, I only did it because I'm far too nice to show up everybody else by wearing a superior costume. That's my excuse and I'm sticking to it. Now excuse me for a moment while I peer down rapidly at everyone snapping pictures. (Thankfully for them, the girls had enough sense to wear high-necked dresses!)
Later this weekend: step-by-step guide to raspberry mocha muffins, full of luscious pictures.
UML illustrates useless junk.
They don't replace your text, they just compound more confusion onto your utterly horrid system design.
It can sully any development methodology by its presence, even XP.
UML is heavyweight in the same way a sledgehammer cracks a nut.
It is boxes joined up by lines codified and suitable for consumption by clueless enterprisey managers
You are allowed to colour in UML diagrams for contrast as long as you keep within the lines.
Should you use UML?
Short answer: no
Long answer: if what you're explaining needs a diagram, use a diagram to help communicate your ideas clearly. If you are competent enough you shouldn't need to rely on something like UML to get the idea across. However, if your project and/or your own skills are comparable to a steaming turd, use UML.
"If you are not saying much don't use a great big diagram"
What should you put in a UML diagram?
Some people link it with heavyweight processes and think the diagram should contain everything in the known universe plus a full proof of Fermat's last theorem. But they're wrong!
It's just about illustration.
If you need to express some relationships between classes, you draw a diagram showing the relationships. You probably do this anyway and don't need some crazy ruleset to help you do this.
Not many projects have a relationship diagram as interesting as (say) MediaWiki, and that's pretty dry stuff, so for the love of god don't do it. Every time you do so, you help some South American clear space to build a soy farm for 3 years, ravaging the environment in the long term. For your next trick, let's shoot an RPG at an oil tanker. 10 points for each oil-smothered penguin!
"A good report is one you can't put down."
An enterprisey report is one you can't lift up, unaided.
If you want to draw simple diagrams, you can use something small and simple like a pen and paper.
Alternatively, use UMLet.
There's more sophisticated tools like Poseidon.
Thinking of jumping off the suspension bridge? Try googling "UML diagram tools" first!
Use case diagrams.
People who can't program are IDIOTS. You need a SIMPLE diagram to get through their THICK skulls. URRRRR!
You draw users as stickmen. This is CUTE. Then you have some lines and a circle with what they're going to do.
Congratulations! Using a diagram you just drew a 7-word sentence in ten times the time.
This is good - the MORONS you are building software for can UNDERSTAND you now!
An actor is a user outside the system.
Imagine a mime artist trapped in a box, and you have an actor.
Like mime artists, actors are supremely irritating and have almost as many stripes/dashes.
An actor can also be a computer program/search engine, but draw it as a stickman anyway because your supremely THICK users wouldn't understand a graphic of a computer.
A use case is something the system is supposed to do. It's a global operation of the system. Diagrams help you think about the different uses of a system.
The basic format of a use case diagram is a stickman (of course), and a bulleted list. But instead of bullet points, imagine they've gone hollow and decided to swallow the list elements whole, like demented typographical macrophages. Nom nom.
The standard relationship is a line. For the kind of person who relies on a UML diagram, this is probably the only substantial relationship they'll have.
Occasionally the lines will have hollow arrowheads at the end. You can think of it as 'extends' in Java. Extending a thin line does little to impress the ladies, but I digress.
Apparently these serve to simplify diagrams. For some reason it isn't allowed to connect a line from one relationship to another. I don't make the rules.
One use case can be a generalization of another. Another relationship is inclusion: 'one thing is part of another thing'. This has a special arrowhead and a label, but be careful you don't confuse it with the hollow arrowhead. You might change the meaning of the system entirely and get confused because your addled brain can't cope with reasonable assumptions or critical thought.
Something about stereotypes were glossed over completely. Probably for the best.
There are other features but nobody gives a shit anymore. Honestly. What is the point of this crap.
It's simplistic, childish, devoid of real use... but it adds a buzzword. What more do you want?
NEXT! Class diagrams. These show the object-oriented structure of a program. Now, ignore for a moment the problems with object-orientation and assume all our problems can be solved completely by it. This is basically a code definition - something not very helpful to most people - of the class name, its members and functions.
In addition, these classes may or may not exist in the final code.
You can show the class at any level of detail that you like. You need to be reminded of this just in case you felt you had to mindlessly follow such verbosity all the time; to be fair, you honestly, probably do.
An empty-headed arrow is as stupid as the representation suggests, showing a superclass relationship. Italics denote classes without objects.
Relationships have diamondheads. Filled diamond indicates ownerships (harking back to an earlier time of dark shapes being owned... oh, I won't labour this point)
Hollow diamonds indicate non-owned parts.
Read the label in the direction you are going.
This is probably one of the only useful parts of UML, and you don't need a whole infrastructure to get you to the kind of database relationship diagrams they made you do for GCSE IT. Honestly.
Aaaand just as something useful came up the lecture on it ends. How ominous.
They don't replace your text, they just compound more confusion onto your utterly horrid system design.
It can sully any development methodology by its presence, even XP.
UML is heavyweight in the same way a sledgehammer cracks a nut.
It is boxes joined up by lines codified and suitable for consumption by clueless enterprisey managers
You are allowed to colour in UML diagrams for contrast as long as you keep within the lines.
Should you use UML?
Short answer: no
Long answer: if what you're explaining needs a diagram, use a diagram to help communicate your ideas clearly. If you are competent enough you shouldn't need to rely on something like UML to get the idea across. However, if your project and/or your own skills are comparable to a steaming turd, use UML.
"If you are not saying much don't use a great big diagram"
What should you put in a UML diagram?
Some people link it with heavyweight processes and think the diagram should contain everything in the known universe plus a full proof of Fermat's last theorem. But they're wrong!
It's just about illustration.
If you need to express some relationships between classes, you draw a diagram showing the relationships. You probably do this anyway and don't need some crazy ruleset to help you do this.
Not many projects have a relationship diagram as interesting as (say) MediaWiki, and that's pretty dry stuff, so for the love of god don't do it. Every time you do so, you help some South American clear space to build a soy farm for 3 years, ravaging the environment in the long term. For your next trick, let's shoot an RPG at an oil tanker. 10 points for each oil-smothered penguin!
"A good report is one you can't put down."
An enterprisey report is one you can't lift up, unaided.
If you want to draw simple diagrams, you can use something small and simple like a pen and paper.
Alternatively, use UMLet.
There's more sophisticated tools like Poseidon.
Thinking of jumping off the suspension bridge? Try googling "UML diagram tools" first!
Use case diagrams.
People who can't program are IDIOTS. You need a SIMPLE diagram to get through their THICK skulls. URRRRR!
You draw users as stickmen. This is CUTE. Then you have some lines and a circle with what they're going to do.
Congratulations! Using a diagram you just drew a 7-word sentence in ten times the time.
This is good - the MORONS you are building software for can UNDERSTAND you now!
An actor is a user outside the system.
Imagine a mime artist trapped in a box, and you have an actor.
Like mime artists, actors are supremely irritating and have almost as many stripes/dashes.
An actor can also be a computer program/search engine, but draw it as a stickman anyway because your supremely THICK users wouldn't understand a graphic of a computer.
A use case is something the system is supposed to do. It's a global operation of the system. Diagrams help you think about the different uses of a system.
The basic format of a use case diagram is a stickman (of course), and a bulleted list. But instead of bullet points, imagine they've gone hollow and decided to swallow the list elements whole, like demented typographical macrophages. Nom nom.
The standard relationship is a line. For the kind of person who relies on a UML diagram, this is probably the only substantial relationship they'll have.
Occasionally the lines will have hollow arrowheads at the end. You can think of it as 'extends' in Java. Extending a thin line does little to impress the ladies, but I digress.
Apparently these serve to simplify diagrams. For some reason it isn't allowed to connect a line from one relationship to another. I don't make the rules.
One use case can be a generalization of another. Another relationship is inclusion: 'one thing is part of another thing'. This has a special arrowhead and a label, but be careful you don't confuse it with the hollow arrowhead. You might change the meaning of the system entirely and get confused because your addled brain can't cope with reasonable assumptions or critical thought.
Something about stereotypes were glossed over completely. Probably for the best.
There are other features but nobody gives a shit anymore. Honestly. What is the point of this crap.
It's simplistic, childish, devoid of real use... but it adds a buzzword. What more do you want?
NEXT! Class diagrams. These show the object-oriented structure of a program. Now, ignore for a moment the problems with object-orientation and assume all our problems can be solved completely by it. This is basically a code definition - something not very helpful to most people - of the class name, its members and functions.
In addition, these classes may or may not exist in the final code.
You can show the class at any level of detail that you like. You need to be reminded of this just in case you felt you had to mindlessly follow such verbosity all the time; to be fair, you honestly, probably do.
An empty-headed arrow is as stupid as the representation suggests, showing a superclass relationship. Italics denote classes without objects.
Relationships have diamondheads. Filled diamond indicates ownerships (harking back to an earlier time of dark shapes being owned... oh, I won't labour this point)
Hollow diamonds indicate non-owned parts.
Read the label in the direction you are going.
This is probably one of the only useful parts of UML, and you don't need a whole infrastructure to get you to the kind of database relationship diagrams they made you do for GCSE IT. Honestly.
Aaaand just as something useful came up the lecture on it ends. How ominous.
Speaking of career fairs, a housemate asked me if I was going to any. I said no, for reasons that are probably now obvious.
"But what are you going to do next year?"
Well, aside from me already having a job... (the situation may be different in July, but let's assume the worst case that I'm without one as soon as I get my degree.) I'm a programmer. It's basically the same as a traditional craftsman, but with more blips and bloops. If you're good enough, there's going to be opportunities one way or another.
I already have some experience, I already know what field I want to work in, and taking a unskilled job isn't an issue. You see, the real wealth is not found in a salaried position - it's by making an individually-attributed contribution to society and getting compensated for it accordingly. One isn't necessarily more stable than the other; just ask anybody who lost a job in the recession. You just need to seek opportunities for wealth creation, whether they're on your own, as a partnership, or joining a company.
Paul Graham wrote an excellent essay on this topic. A few edge cases aside, it seems a very apt description of the whole thing - and hopefully it knocks a couple of fallacies out of your head on the way.
The only caveat with this whole thing is I'll probably have to deal with finance. Oh God. By the end of this I'll be making bespoke software for baby-munching robots, I just know it.
"But what are you going to do next year?"
Well, aside from me already having a job... (the situation may be different in July, but let's assume the worst case that I'm without one as soon as I get my degree.) I'm a programmer. It's basically the same as a traditional craftsman, but with more blips and bloops. If you're good enough, there's going to be opportunities one way or another.
I already have some experience, I already know what field I want to work in, and taking a unskilled job isn't an issue. You see, the real wealth is not found in a salaried position - it's by making an individually-attributed contribution to society and getting compensated for it accordingly. One isn't necessarily more stable than the other; just ask anybody who lost a job in the recession. You just need to seek opportunities for wealth creation, whether they're on your own, as a partnership, or joining a company.
Paul Graham wrote an excellent essay on this topic. A few edge cases aside, it seems a very apt description of the whole thing - and hopefully it knocks a couple of fallacies out of your head on the way.
The only caveat with this whole thing is I'll probably have to deal with finance. Oh God. By the end of this I'll be making bespoke software for baby-munching robots, I just know it.
Putting things off. It's wonderful, isn't it? If you don't feel like doing something quite yet, you just postpone it and get on with doing something more fun. Then, when a deadline looms, you get to flog yourself to death, usually to keep the wheels of capitalism greased. Doing this too often invariably leads to throwing yourself between the gears in a vain effort to halt the machine, but despite your best efforts, your wimpy frail body is no match for the Corporation, the immortal person who keeps on going. Ha ha, look, your eyeball just bounced off the wall! Let's send that in to You've Been Framed and make even more profit.
Labour laws have made this kind of thing rather impossible to do physically, but the practice is still alive and well mentally. There were career fairs at university today - all your favourite consultancy companies plus PricewaterhouseCoopers, bartering for your soul in exchange for lots of money. Look forward to what you'll get when you graduate! Long hours playing with imaginary numbers in various firms' bank accounts, just so you can get some imaginary numbers in your bank account; some of which you'll spend on feeding your snivelling spoilt kids with fast food, replete with imaginary nutritional value, but more often going to invest in imaginary tracker funds so you can get even bigger imaginary numbers. Then you can go home to your wife, your feelings for each other imaginary, and later making (what can only rightly be called) imaginary love. At least your car is real, but its worth is pretty damn imaginary. Repeat for years until you start to wish your life itself is imaginary.
If they remade It's a Wonderful Life today, it would probably star a hedge fund manager who gets shown round the world, looking at all the ever-so-slightly-happier faces everywhere. Nobody minds. You were shouting at the screen for him to top himself long before he stuck his head in the oven. Bet you'd eat it afterwards.
Anyway, let me pretend my digression actually had a point rather than just being a cathartic rant, and suggest that procrastination is like taking a loan of time. You'll have to pay it back one day. With that in mind, will there ever be a time crunch, triggered by too many lazy buggers sitting on their arse watching Corrie and playing Xbox? Surely it's only a matter of time.
Labour laws have made this kind of thing rather impossible to do physically, but the practice is still alive and well mentally. There were career fairs at university today - all your favourite consultancy companies plus PricewaterhouseCoopers, bartering for your soul in exchange for lots of money. Look forward to what you'll get when you graduate! Long hours playing with imaginary numbers in various firms' bank accounts, just so you can get some imaginary numbers in your bank account; some of which you'll spend on feeding your snivelling spoilt kids with fast food, replete with imaginary nutritional value, but more often going to invest in imaginary tracker funds so you can get even bigger imaginary numbers. Then you can go home to your wife, your feelings for each other imaginary, and later making (what can only rightly be called) imaginary love. At least your car is real, but its worth is pretty damn imaginary. Repeat for years until you start to wish your life itself is imaginary.
If they remade It's a Wonderful Life today, it would probably star a hedge fund manager who gets shown round the world, looking at all the ever-so-slightly-happier faces everywhere. Nobody minds. You were shouting at the screen for him to top himself long before he stuck his head in the oven. Bet you'd eat it afterwards.
Anyway, let me pretend my digression actually had a point rather than just being a cathartic rant, and suggest that procrastination is like taking a loan of time. You'll have to pay it back one day. With that in mind, will there ever be a time crunch, triggered by too many lazy buggers sitting on their arse watching Corrie and playing Xbox? Surely it's only a matter of time.
From the BBC News website:
It is currently unknown whether the international terrorist group - who sell a range of clothing and costumes (including the infamous My First Suicide Bomber) and their popular pick-and-mix interpretations of the Qur'an - are in immediate danger of liquidation into splinter groups, as led to the creation of Wellworths this year.
Plans for the group to form a high-street presence were first mooted 20 years ago, but while imitation terrorist cells have made inroads into our towns, al-Qaeda has remained an exclusive brand reserved for considerably higher-profile locations. Today's recent news casts doubt on any hope of the group's expansion.
Plans for the group to form a high-street presence were first mooted 20 years ago, but while imitation terrorist cells have made inroads into our towns, al-Qaeda has remained an exclusive brand reserved for considerably higher-profile locations. Today's recent news casts doubt on any hope of the group's expansion.
(On request of my housemate, she wanted credit for being sous-chef. We both whipped, and not in that way, either. Whatever way that might be.)
Pretty thoroughly, too - being a coffee meringue cake.
It was made for my housemate's birthday after a rather quick search that morning for appetising cake ideas. You can find out how to make it yourself. I swapped the walnuts for chopped roasted hazelnuts, because I think they're a far better complement for coffee-flavoured things - that, and I prefer pretty much any nut over walnuts, save for those lurid pistachios. Eeeeesh.
I'll get some original recipes up here next time I do a spot of baking - it might even be my infamous muffin recipe!
Pretty thoroughly, too - being a coffee meringue cake.
It was made for my housemate's birthday after a rather quick search that morning for appetising cake ideas. You can find out how to make it yourself. I swapped the walnuts for chopped roasted hazelnuts, because I think they're a far better complement for coffee-flavoured things - that, and I prefer pretty much any nut over walnuts, save for those lurid pistachios. Eeeeesh.I'll get some original recipes up here next time I do a spot of baking - it might even be my infamous muffin recipe!
It's almost there, no, really this time, oh, I'm very close, if only you wait a little longer... this, and many other similar utterings, is a recurring theme in my life. (Although thankfully, I'm not getting the full anorgasmia experience from my antidepressants. Mostly a good thing, but it's not doing my chronic fatigue any favours.)
Certain projects are still like this (sorry Clickteam, and yes, dad, I'll get round to your ideas too), but I have several years' of stalled development to catch up on and only so many hours in a day to do it in. This very blog was one of those projects - an idea, floating around in the pool of my consciousness, and a survivor of the tsunami of depression that wiped away much of my desire to actually implement things. Countless thoughts, projects and concepts weren't so lucky; rotting away on a backup CD or buried in my mind, assuming they haven't turned to earwax and been wiped away by now.
Sometimes I wonder whether looking like a twat is the price I must pay for individuality. Other times, I wonder what would be louder, the noise a monster truck makes, or the sound of a football-pitch-sized sheet of bubblewrap as said truck drives over it. However much that costs, it's worth it, carbon footprint be damned!
I almost feel like a coherent person. You'll see, just wait a little longer...
Certain projects are still like this (sorry Clickteam, and yes, dad, I'll get round to your ideas too), but I have several years' of stalled development to catch up on and only so many hours in a day to do it in. This very blog was one of those projects - an idea, floating around in the pool of my consciousness, and a survivor of the tsunami of depression that wiped away much of my desire to actually implement things. Countless thoughts, projects and concepts weren't so lucky; rotting away on a backup CD or buried in my mind, assuming they haven't turned to earwax and been wiped away by now.
Actually, that would make a better excuse for licking my own earwax than my current reason, "I'm a masochist". Besides, my face doesn't really suit the 'scary weirdo' perception; I like to think of myself as more of a 'quirky, lovable fool', mostly because it's really hard to transcribe the gestures people often use to describe me.The driving force for actually getting this website set up is the feeling that I have stories to tell, and experiences worth sharing (mostly scrumptious cakes, of which I get asked for recipes heartwarmingly often). I think it's a good sign, but we'll see where it actually goes. Worst case scenario, it turns into a LOLotter blog that does its utmost to tattoo your eyeballs with lewd advertisements for uninventive MMORPGs. Unfocus your eyes and the breasts appear to move!
Pornographic magic-eye pictures could be marketed as accurate 'marriage simulators'. Some people seem to get it all the time, but the rest of us frustrate ourselves spending far too long trying to see the concealed nudity, failing miserably before suddenly copping an eyeful and spending the rest of our lives trying to remember what we did to get there. Oh yes, you might be smiling now, young'uns, but that's going to be your fate. Start researching volumetric displays, holographic hyper-porn won't invent itself, you know.
Sometimes I wonder whether looking like a twat is the price I must pay for individuality. Other times, I wonder what would be louder, the noise a monster truck makes, or the sound of a football-pitch-sized sheet of bubblewrap as said truck drives over it. However much that costs, it's worth it, carbon footprint be damned!
I almost feel like a coherent person. You'll see, just wait a little longer...