Recent Articles

« Jul 14

August 2014

When developers first got access to those new-fangled gadgets called computers, memory was a very precious resource. Applications were frequently written as a main controller that would load module overlays into memory, call a function, and then repeat as additional functions were called. It was a horrible way to code, but it was all we had. Unfortunately, as computers came equipped with more and more RAM, this habit of repeating the controller code in every file seems to be quite resilient...


In life, you will inherit all sorts of things: traits from your direct ancestors, knick-knacks from relatives you tolerated, and sometimes, even money! Of course, there are other things in life that you inherit that you might not even want. The gene for some debilitating disease. The urn filled with the ashes of a relative you particularly despised. Code.

Securing Input

We all know that many developers have difficulty in dealing with built-in concepts like dates and times, and that for and switch statements don't necessarily have to be used with each other. However, validating a piece of input is usually more straightforward. You compare what you got to what was expected.
We've all heard of threads. No, not the stuff hanging loosely from your clothes. I mean threads, as in multitasking. Most modern languages have all sorts of nifty facilities that allow you to create, manipulate and destroy them at will and with minimal effort. There are even abstractions that will manage a set of threads for you, so that you can spawn a bunch of tasks, and let them tell you when they're done. You can synchronize them yourself. You can put up cyclic barriers to make them all wait at a specific point in the code. You can make them return a value when they're done. Or you can just spawn them and let them run all by their lonesome. Of course, not everyone trusts the built-in facilities... Now you might expect this sort of thing from Joe Offshore, but not from certain huge, blue companies.