Monday 28 September 2009

'Fallen Earth' Review (5/10)



Well, I was sick of pixies, faries, orcs and elves. I gave Fallen Earth a shot. Seemed like a riot
  • There was first-person/third-person gameplay (Hellgate +1)
  • There was melee and ranged combat -- with proper guns (Hellgate +1)
  • Open world concept (Oblivion +1)
  • The Earth was devastated by a deadly virus and there's so few of us left (Fallout +1)
  • The graphics are great (Hellgate +1)
  • There's support for PhysX technology (Coolness +1)
And then I played it.

Tuesday 22 September 2009

I hate programming

Ok so that's a bit of a lie. I don't hate programming. I just hate web-programming. Or maybe it's me hating reality, that might be it. Ok, well when we learned how to design software, we were all (or should have been) taught a series of core principles. It's these principles that separate 'our' clean, efficient, meticulous code from that of a hack (who may or may not be brilliant in and of her/her own right -- just not capable of working on a team etc). Whatever. One particular principle that stands out to me relates to hardcoding.


Don't hardcode. Sure there are cases where hardcoding is acceptable/ideal but for the most part (i.e. the majority of web and client applications), there's not a whole lot of need for hardcoding and in fact, hardcoding can get you into a world of pain down the road. Sure, you might think you just finished coding whatever it was you were doing and it's perfect -- until someone comes along and says "hey, can you change to ? thanks!" -- that's when you realize you were dumb and you now have to do do a search/replace-all. Naturally it gets more complicated/tedious if it's not longer a case of search/replace-all. So yeah, hardcoding is generally, non-ideal (besides, it's far more elegant to have a universal algorithm that handles a wide range of scenarios than to be stuck in the box of only one scenario).

Thursday 10 September 2009

Trillian Automation + Too much time on my hands...

Preface
While the majority of my friends and colleagues have reasonably reliable internet, there are a few that, for whatever reason, have a hard time maintaining their connections. While most of them know that their connections are unreliable at best (either due to their ISP, bandwidth usage, equipment failure or that they are wardriving) a few have no idea that their connections are stuttering.


A connection is said to be stuttering when the connection drops but for such a short period that, based on how they use their connection, there is no glaring indication of what just happened (I imagine most users don't run perpetual ping-tests). Microsoft's 'Live Messenger' (and the various other chatting services) is a major culprit here - particularly so with the advent of offline messaging.

MSN (and other chatting services) operate by having a user sign on. This sets the client's state as being 'connected' (this is independant from the user's actual status i.e., available, away, invisible etc). The client checks back with this central messaging server every so often to make sure that the user is still connected. With the official MSN client, (empirically), it looks like this check is made every eight seconds or so. This is just when the client is sitting there, doing nothing. During active conversations, I would estimate the check to be four seconds or so.

When the client software [successfully] checks in with the central server, the software is "reassured" that it is still connected. The software (and thus, the user) is only made aware of  a problem in the event that this check fails. What this means, is that if the user's connection drops and is subsequently restored during the 7.9 seconds window between checks (3.9 seconds for active chats), the user has no idea that they were, in fact, offline for a very small window. From the end user's (the one with the dodgy connection), there is no reason to care -- they aren't aware of the disconnect and thanks to the luxury of offline messages, most of the time, they don't miss anything from the conversation.

It is important to note that offline messaging is not bullet proof. I don't quite know how the various offline messaging system work but I from time to time, we've all recieved the "such and such message failed to be delivered" error message even when both users in the conversation might be using client software that supports offline messaging.