Rants

You are currently browsing the archive for the Rants category.

Ed Balls and a miniature gangster

Even at the best of times, there’s nothing more embarrassing than a politician trying to “communicate with the young”. But Ed Balls managed to take this one step further by engaging a bunch of manufactured gangsters to spearhead a ‘beat cyber-bullying’ campaign, as depicted in the artist’s impression opposite. The fake hoodlum standing alongside bully-boy Balls is Dappy, of N-Dubz, who shortly afterwards stole the mobile number of a Radio 1 listener who sent in a less than complimentary message about him, and used it to harass her, culminating in sending her a death threat. You couldn’t make this stuff up.

Behind the farce though, lurk more serious problems. How did we reach this sorry state where, in order to try and convince school children to stop bullying each other, it seems like a good idea to enlist the help of dubious role models who make a living pretending to be (or in this case actually being) illiterate thugs?

Read the rest of this entry »

You know you’re getting old when you start complaining to the BBC about things. I’d like to think I’m not getting that old yet, but even so, this dreadful article made me do this:

Read the rest of this entry »

Underage

Have a guess what this was on the back of…

NOT FOR SALE TO PERSONS UNDER 18 YEARS

What did you think? A crossbow? A box of hand grenades? An assault rifle? Close, but no cigar…

Read the rest of this entry »

If you don’t know, you probably don’t care, but in any case: stopwords are words you CAN’T search for in a full-text search of the database. They’re filtered out for performance/space reasons, because they’re ‘noisy’.  You know, words like “the” or “and” – things you wouldn’t search for anyway. Or “novel”? “welcome”!?! Anyway, it’s annoyed me so many times that I wrote the following poem composed entirely of them:

Thanx, whoever they may be
For specifying many useful ones
Amongst the others ignored

C’mon, it just isn’t sensible
Consequently I wonder why
But regardless
Somebody somewhere should be sorry

I’ve been called cynical more than once. In fact, I’d go so far as to call myself cynical, and being cynical is a healthy thing if you ask me. Another thing that’s healthy, all of a sudden, and once again, according to the media, is eggs. They used to be good for you, you should have one every day. Then they were bad, you should only have your allotted quota of standard egg units per week. Now you can, and indeed should, have as many as you like again.

Of course, all reasonable people are used to this backwards and forwards nonsense with every kind of food and drink under the sun and routinely laugh it off with a good dose of “all things in moderation” common sense. Only the media seem to suck it up like a sponge, with this latest egg story apparently being headline news everywhere.

I was blissfully unaware until it was given a prime slot on the BBC evening news, the highlight being the way they managed to wheel out the amusingly named Lucy Egerton from the British Egg Information Service without cracking so much as a childish grin.

The cynical side of me though, as always, responded with a weary “who paid for this ‘research’ then?” No surprises in the answer, or the fact that you have to dig a bit deeper than the news stories (a.k.a. press releases) to find out. It was of course the egg industry, which also seems to double up as the acronym industry, what with the BEIS (British Egg Information Service), the BEIC (British Egg Industry Council), BEPA (British Egg Products Association), the BEA (British Egg Association) and many more.

None of this though, should detract from the fact that you should eat eggs. Because they’re nice. Poached, boiled, scrambled, fried or omeletted – you can’t go wrong with an egg. Ok, you could – there is eggnog, for example. But in general, my advice, which I say is just as valuable as some ’scientific’ research paid for by a vested interest, is to eat plenty of eggs. I wouldn’t advise eating eggs produced by an industry though – instead, eat eggs produced by a free* and happy chicken, preferably your own.

*As with free software, the “free” is as in freedom, although of course if they’re your own chickens you don’t pay for the eggs)

So you followed all my tips in the first installment, but you’re still worried that your code might be maintainable? Here are some more:

  1. Forced to fix a bug? Don’t worry, you can reintroduce it a couple of releases later, as long as you remembered not to add a regression test for it.
  2. If you must document code, don’t take the opportunity to explain WHY it’s doing what it’s doing. Just describe the obvious. Learn from the masters at Microsoft:
    // Initialize the column to '0'
    ColumnToSort = 0;
    // Initialize the sort order to 'none'
    OrderOfSort = SortOrder.None;

    No, really, that’s not made up – see for yourself.

  3. If you have to generate a lengthy SQL statement, avoid any kind of formatting of the code that might make it readable. Instead, cram it all on one line such that you can only see a small part of it at once.
  4. Avoid unnecessary timezone calculations by living on the Greenwich Meridian and only testing your code when DST is not in effect. Or preferably not at all.
  5. Threading is your friend. Find obscure ways to make sure your functions are not re-entrant. When reports of random failures come in from production environments, simply say you can’t reproduce them.
  6. Carefully read any coding standards that apply to your project and commit them to memory – otherwise there is a risk you might comply with part of them by mistake.
  7. A multidimensional array is a fine construct for storing your tabular data, but only if you refer to all your columns by numbers and don’t document them. Better still though, is a comma-separated list of pipe-delimited strings. For bonus points, use a delimiter that only rarely occurs in the actual data.
  8. Use floating point numbers for your currency calculations.
  9. Although cluttering up the code is normally a worthy cause, don’t waste your time validating user input. Rely on bug reports to find out the interesting effects of the ‘unexpected’ things they entered.
  10. Refactor. Because you feel like it.

Spot The Odd One Out

What’s the difference between these?

Deathstar

A sorry and tedious tale of hardware failures in a world where technology and frozen peas collide.

I got up this morning (or rather I was dragged up by Mia, as usual, at an ungodly hour) and the first thing I noticed as I wandered past my office on the way to the bathroom was a horrible silence where the happy whirring and grinding of a dust-filled fans and creaky old hard drives should have been.

Read the rest of this entry »

I guess you’re worried that when your project has no bugs, or when maintenance becomes too easy, someone is going to start wondering what they’re paying you for. What you need is technical debt. Here my top 10 ways to sneak some into your codebase. As well as plenty of future bugs, this will ensure that any maintenance or expansion tasks take as long as possible.

  1. Create lots of overloaded versions of the same function. Only use one.
  2. Copy and paste code. For bonus points, change the pasted versions slightly.
  3. Leave chunks of commented out code (“Green Code”) lying around.
  4. Don’t use existing core logic. Reimplement it within the user interface using your own strange methodology. Make sure it behaves subtly differently. No need to check that, it will.
  5. Check several unrelated changes in at once. Only mention one in the check-in comment.
  6. Never use 5 lines of code where 50 will do.
  7. Never use 50 lines of code where several classes that almost resemble a GOF pattern you misunderstood will do.
  8. Invent your own naming conventions.
  9. Never fix a bug – hide it. For example, deal with null reference problems by simply sticking an if-not-null around the offending code. This saves you having to look for the real source of the problem, and also ensures the bug will come round again in a more subtle and interesting manner.
  10. Leaving out documentation is too obvious. Much better to document it, but make sure the code doesn’t do what the documentation claims.

Don’t Do This

It should be basic common sense, but this issue is coming up again and again. Service X asks for your login details for service Y. Two things:

  • Don’t provide them
  • Walk away from service X

Read the rest of this entry »

« Older entries