Just say no…

What’s in a Game?.

I haven’t even seen – let alone played – GTA3 for example, but my GBA still has me hooked, so I would disagree with that. Maybe I’m just a kid at heart…


[Russell Beattie Notebook]

Do yourself a favour, don’t buy GTA3. Its horrifyingly addictive. Maybe its because its the first game I’ve bought for a while now, and the technology has moved on somewhat. My last couple of game purchases were of the ‘big complex strategy’ variety that don’t require rapid reflexes and thus don’t stimulate the adrenaline rush of action games.

Its also the first ’18’ rated game I’ve ever bought, and they really, really mean it. Don’t play it with your kids. Unless they’ve grown up and left home.

Of course, if you like losing 4 hours of your life every time you sit down to play a ‘quick game’ then go right ahead…

Hacker Humour

YKYBHTLW…. You know you’ve been hacking too long when you come up with an idea for a silly Science Fiction/Horror short story, in which the universe implements reference-counting, and as soon as the number of `references’ (i.e. connections to other people) you maintain reaches zero, you are visited by The Garbage Collector. (52 Words) [The Fishbowl]

You know you’ve been hacking too long when this makes you laugh out loud.

Temporal Decoupling

The subject of messaging systems came up in a conversation last week, and some

wheels started turning. I like the idea of messaging systems. It feels

architecturally clean to have all your components abstracted away from each

other, so that each one only sees the message bus, and doesn’t give a hoot where

its messages are going to, or coming from. Even more specifically, each

component can choose which messages it wants to get, and not be bothered with

the rest. This again feels tidy.

Not only do messaging systems give you an architectural layer of abstraction,

but you also get the thing that prompted this post: temporal decoupling. If

you have a part of the system that isn’t running 24/7, you can either build

‘time-locks’ into the UI so that it can only be accessed when the system is up,

or you could use a combination of an off-line cache and a store-and-forward

message queue to allow the system to be used in limited fashion even when parts

of it are temporarily down. The cache can be implemented as ‘just another

subscriber’ to the message queue. Another bonus: adding message consumers is

transparent to message producers, and vice versa. This allows a many-to-many

relationship between components, such that multiple machines can look like one

big virtual one to anything on the other side of the message queue.

Disadvantages? Two network hops (Producer-Queue-Consumer) where before there

was only one. Added development complexity. System administration – now

there’s a message queue component to look after as well. Point of failure –

losing your message queue would not be funny. The store-and-forward approach

would not work well for time-critical messages (eg. stock market transactions).

Better to report failure immediately than complete the transaction at some

indeterminate point in the future, when market conditions may be wildly different.

Introduce Interface Refactor

Dr. Cedric In the House. Cedric has a new style on his blog (very nice) and an interesting new post on using Interfaces. In it he makes two interesting assertions: never supply an interface without a factory and “new” should only appear in factories. He’s going to expand on the second one later, but the idea is that the first rule avoids this type of code:

IEmployee emp = new EmployeeImpl();

Woof, that’s ugly, ain’t it? Check out Cedric’s site for the details.

Now someone help me out, I’m starting to see posts about Test Driven Development (TDD) where they’re talking about creating lots of interfaces. Is this true? Tell me it isn’t so! I need some education on this topic…

-Russ [Russell Beattie Notebook]

Pure greenfield Test-Driven development means only doing things as the tests need them, so interfaces should only appear where they’re supposed to. However, pure greenfield development is something of a rare beast. A fair proportion of my time is spent doing Test-Driven Refactoring, where I’m trying to retrofit the attitude and practice of Test-First to lumps of intransigent legacy code. Interfaces are the programmer’s equivalent of a crowbar in these situations. You have to lever apart the coupling in order to fit a TestCase into the gap.

Open Source Security

Safe and unsafe.

A report

says that Open Source Software is more vulnerable than Closed Source:

Advocates of the open-source process often claim that their products are more

secure thanks to the larger number of people poring over the code

This is one of the most widespread fallacies about Open Source code. 

The truth is that Open Source developers spend much more time writing code than

reading it.  And it makes sense, right?  You are most likely

contributing to an Open Source project to have some fun on your spare time, and

what fun is there in trying to make sense of code written by an unknown

developer living probably on a different continent than yours?

Since there is no fun in doing that, there needs to be an incentive, like

money.  The bottom line is that fixing security flaws in Open Source software can

only happen if the project is backed by a company that is actually paying a

salary to the members of the project, and if the said company has a clear

interest in having this security hole plugged.

Short of having that, Open Source is just as unsafe as Closed Source is. [Otaku, Cedric’s weblog]

Yes. All source code has the potential for security flaws. The real differentiator for open source is the sheer speed with which flaws are tackled once discovered. Its usually on the order of days. Compare the amount of time it takes the FreeBSD team to release an operating system patch once a hole is found with, say, your favourite proprietary desktop operating system.

Open source projects also tend to generate more loyalty and pride of workmanship from their developers, so a higher level of care tends to be taken over the work. Paraphrasing (poorly) from somewhere, you’re only as good as your last commit. When all the world can see your code, bad as well as good, would you not be a little more hesitant about releasing cruft?