I guess this is making news across the US and Canada, but my hometown of Calgary is suffering from the worst flooding in a half-century at least. A year’s worth of precipitation has fallen in the last 48 hours: a small city and three nearby towns are completely obliterated and over 10% of this city of 1.1 million people have been evacuated.  Entire portions of our nationwide highway has been completely washed away. Hospitals are shut down and the whole downtown core is under water.

Worse still, the rains are still coming. These were photos from this morning, but another 100mm has fallen upstream of the river bed since. Thousands of troops have been deployed to evacuate and rescue stranded people.The emergency response here has been overwhelmingly fast.

BNTXrCOCEAAR2r9.jpg large

(For reference this guy is standing on a 4 ft high traffic divider, not a curb)

CAL062113-gya-8.jpg

I gotta say though, I love my city. For the 100,000+ people displaced, there’s less than 5,000 actually in evacuations and shelters: so many people have opened up their homes. If you take a look at Kijiji or twitter right now you’ll see it flooded with people offering shelter to complete strangers. Roads are choked full of people dropping off supplies to charities and shelters across the city.

Thankfully, my wife and I are safe and dry. Our tiny little home is located in a corner of the city that is higher up than most but we have many friends and family whose homes are under water right now.

 

I was hoping to have an updated version of the console library for those who use Visual Studio but difficulties in porting the project from the original language, VC 6 (don’t laugh), to VS2010 have frustrated the hell out of me recently.

I’ll spare all of you the insanely technical and ranty diatribe running through my head right now and just say this: a little disconcerting to see the compiler gag and throw errors over it’s own header files. :S

So I’m going to try the ol’ VC6 to VS2008 path and see if I can breach the problem from this angle instead.

My apologies about the downtime… the server issue has been restored and we’re back on track. Two things upcoming in the next 3-4 weeks:

– I’ve finally got what appears to be a decent thread on the next article. As mentioned earlier, I specifically wanted to build up a complex and ugly piece of code in order to show the reader how to untangle such inevitabilities but the downside is that I have written myself into a bit of a corner and it took not some several attempts to figure out the best way out. In these circumstances, the temptation is to just rewrite – and while a valid option, it can be dangerous too. It is my hope to show how to recover messy projects rather than merely give up and move on to the next big idea.

– It seems like there is some problems with the console library when using Visual Studio. I managed to get my hands on a copy of the latest and greatest edition, so we should have some decent static libraries for you good folks soon.

Since December, I’ve been performing a rewrite of the firmware for a product my company has been developing for the past two years. This was one of those nightmare projects where it was started by a previous developer who ditched the company halfway through the project. To make matters worse, this project had a very obscure design and horrible architecture that had no end of latency and timing issues. The previous developer had hoped these would go away it he sped up the clock, it made it survive demos but was barely stable enough for long term deployment.

What normally happens in this circumstance is tragic but predictable: the project is three months away from completion but is such a mess that the developers ask to rewrite it in order to ensure quality. But the guys who can authorize it, the project management types, look at the situation and say “yes, we agree there’s a problem but we’ve already spent all this time and money on it. We’re only three months away. Make it work.” A month later the exact same conversation occurs; and the next month, and the month after. Before you know it, an entire year has passed and the project is still three months away.

These types of projects were what the last company I worked with used to get new customers. For most companies though, one of three possible outcomes occured: 1) management kills the project, 2) they push the project through as is, become buried in field support issues  and gain a reputation of crappy products, or 3) married to the previous time and effort invested, the project is strung along for years, perpetually three months from completion.

I believed that scenario #2 was going to be my fate, but mercifully, I was spared this outcome by what was one of the strangest firmware bugs I’ve ever seen: adding 100+ additional instructions (even NOPs) anywhere to a normally stable codebase would suddenly transform the processor into a raging beast that would completely and utterly ignore any and all branches or calls in the code. Everything else would work perfectly.

After about 40 emails back and forth, they threw in the towel and said: “we don’t have a clue, good luck”.  It was at that point that a rewrite was authorized and development began anew….

Continue Reading

As casually mentioned earlier, I’m a firmware developer by profession and the vast majority of my time from 9 am to 5 pm (actually, it’s 8-5) is spent doing something that very few people even know about, and even fewer know how to do properly.

Firmware occupies the fuzzy middle ground between hardware and software (hence the prefix “firm”). I taught myself programming back when I was ten, spending countless hours hogging the family computer developing roguelikes: although I’m formally trained as a “Computer Engineer” – which I basically describe as being an electrical guy who specializes in 1’s and 0’s. I’m one of the more rare developers that started in software and became formally trained in electronics. (Notice that I didn’t say “better”…  just rarer – at least in my neck of the woods).

The electronics side is an absolute blast. The net result of my formal training is the ability to make a computer from scratch using nothing but transistors. I all but locked myself in an absolutely freezing electronics lab for three years straight trying to wrap my head around the confusing movements of electrons.

Firmware is this silly thing that you really have to be a certain (and twisted) personality to enjoy.  Being a firmware developer means that you’re essentially a 1970’s era programmer stuck in the 21st century: the company I work for is still doing half their development in assembly language! But the bits you move around can actually leave the chip that you’re programming and go out into the real world to measure and change things. When you start a project you’re given this expensive brick of copper, fibreglass and silicon and by the end of it you’ve made the thing come alive and touch the world.

My work experience has historically been with ultra-low power sensors and wireless communications – the type of stuff where the thing you’re working on needs to last years on a single battery and often operating in environments full of fun things like explosive, poisonous and acidic gasses and at temperatures higher than 200 degrees Celsius.

The systems that I’ve deployed tend to be small-to-medium scale embedded systems, typically running at speeds less than 20MHz. It’s actually amazing how much work you can get done at 4MHz. Most, if not all, of all this high tech computing power that the Silicon Valley has developed over the years has been spent in this neverending quest to put pretty pictures on a screen. Yesterday’s supercomputers are today’s handhelds… sometimes we forget what that means.

Over time, I’d like to do a series of tutorials about firmware development: it’s something I absolutely love doing and am passionate about. The problem is, I’m not the greatest at splitting focus between two projects (I’ve got five at work right now!) – so the roguelike tutorials will need to be finished before that happens.

It was a long time coming but the Beginner’s Guide to Roguelike Development has been updated. The new articles cover NPC’s primarily but I also included in an article about splitting up code into multiple files. I included that last article because the example code is getting really messy and the professional perfectionist in me is dying a little inside.

I have intentionally been letting the code become unwieldy in order to drive home the point of good coding practices. For the past ten years, I have dealt with crappy developers who parrot Joel Spolsky or Fred Brooks but never really take the principles behind it to heart (the last company I worked for made it’s bread and butter from cleaning up the mistakes of other developers). My goal throughout this guide is to take the rookie programmer through some of the real-life issues that arise during development. I believe that it’s far better to experience the pain before showing how to prevent it, otherwise it’s hard to see the point. Well, at least it was for me when I was a young upstart… 🙂

This wave of articles finally puts to rest Section One which was intended to give people a taste of RL development. My goal with this new section is to start introducing the concept of architecture and structure in code; by the end of it, the code should look like something a developer would be proud to have their name attached to. We’ll see if I can achieve that.

My 9-5 grind is as a lead firmware developer for an instrumentation company. Part of the reason why the release of the next couple articles has been so delayed is because the sales department here sold a product we’ve been developing *before* we finished designing it; leading to instant crunch time and frantic testing. This has happened before, and never ends well: but they still did it, not once, but 3 times now

*sigh*

Article Seven is just about complete. After four re-writes and well over 40 hours put into it, this is definitely the most difficult article I’ve ever written. By far I’ve found the greatest challenge is making sure that there is a trajectory to the guide; each article leads into the next with just one improvement or one new feature.

Continue Reading

For a while now I’ve been developing what I call the “Beginner’s Guide to Roguelike Development in C++”. I really like  messing around with them.

I’ve been making console-based games (“console” as in ASCII, not  console as in PS3) since I first learned how to program. I have the artistic skills of a walrus so it was more out of necessity than intention. I quickly was hooked and spent many an hour in the basement hogging the family computer, working out clever ways to move characters around on a black screen.

It’s a great way to keep sharp. The thing about roguelikes: they’re a programmer’s playground. The ASCII-tileset is just abstract enough to make a playable game while not being detailed enough to waste all your time worrying about pixel shades and graphical effects. Within half a page of code, you’re up and running, diving straight into real gameplay decisions.

As a professional developer, I need to continually learn and grow. Sure, I could audit courses at a university or read books on applcation programming, but nothing is more fun, challenging and instructive as making a game. It encourages all that is best about programming: algorithm design, exotic data structures, simulation, gameplay decisions, design… these things are often a risky, expensive and impractical exercise in a commercial setting.

I believe this man puts it best:

We are more ready to try the untried when what we do is inconsequential. Hence the fact that many inventions had their birth as toys. ” Eric Hoffer (1902-1983)

These little toy worlds have taught me so much, and given me the skills to feed my family with a career that I love.  Not bad for no graphics, hey?