Wednesday 29 September 2010

Stored Procedures Are Bullshit

Obviously not totally bullshit. They have their uses. But I am working on an application that has so overused them, that I feel like stabbing out my eyes with a rusty spoon every time I look at another of the 1000 line obfuscated monstrosities.

Who the fuck thinks writing a multi-thousand line stored proc is a good idea? At no point does common sense intrude and say ‘Hold on. I might have taken a wrong turn here’? I suppose not, since this app has literally hundreds of enormous procs, containing the vast bulk of the applications critical logic.

Even though the insanity of this approach should be self-evident if you’re anything other than a total charlatan, for the sake of my own sanity, I’ll iterate here why this is so much bullshit:

  •   Multi-thousand line functions of any form are folly. Multi-thousand line functions in an IDE as feature-free as your typical DB client are on a higher plane of batshit insanity. For fuck sake.     
  •  Why, oh why, would you choose to write business critical logic in the exact place where your unit tests can’t get at it? Oh wait, it’s because you don’t have any.
  • By writing all your critical code as SPs, it’s not only now next-to-impossible to test properly, it’s also tethered to the scaling capabilities of your DB. Nice work.
  •   Most of the stated benefits of SPs no longer apply. It’s 2010. 
  •  If the amount of SP code is large or especially complex, you’d better like your DB vendor because you’re not fucking changing.
  •  Your application developers have to context switch every time they want to implement a full slice of functionality. From modern IDE / language / tools to the SQL stone age of whatever shithole DB client you’re using (they’re all shit, no exceptions), this is the path to productivity destruction.
  •   Debugging stored procedures is a fucking black art, known only to DBAs and weirdoes. Fact.
Very few coding topics actually arouse strong feelings in me – something I have learned over years of working with many different people at different companies is that, as software engineers go, I’m reasonably easygoing. I can accommodate a vast array of programming styles and technologies without much of the usual subjective, vitriolic, bullshit that often reigns in an industry full of Aspergers sufferers.

But on this I’m clear. Fuck stored procedures.

Tuesday 14 September 2010

Roguelike - Mining!


Players can now enter mining mode and designate blocks to be mined. Miners will path to the nearest block to be mined, and start digging.


Roguelike - Pathfinding


Pathfinding entities up and running. Not that they've got to try hard in this particular test dungeon.

Thursday 9 September 2010

Roguelike Development

I've decided to blog a little about the ongoing development of a Roguelike. I'll be developing in C#, using libtcod.net for console support and some helpful library functionality like FOV calculation pathfinding, and BSP generation, amongst other things.

I'm primarily inspired by Dwarf Fortress, a game I'd love to be able to get into but just can't seem to crack. It's a testatment to its complexity that it actually seems simpler to develop my own Roguelike than to brave its (frankly horrendous) UI.

We'll see how far I get with this. Here's the first screenshot below! From small beginnings...

Set up the main console window, dividing it into sections. Tab toggles various enlarged views of the main window. Got a viewport system up and working so the main map can be scrolled.