Programming *is* Rocket Science!

John Carmack is something of an idol to me. He’s an incredible programmer that has created some of the most advanced graphical games ever seen on the PC. He also dabbles in amateur rocketry with his rocketry company, Armadillo Aerospace, whom I’ve written about before.

I joined the Amateur Rocketry mailing list a couple years ago. The aRocket list is a great place to read about what’s going on in the amateur rocketry scene. The various rocket scientists on the list openly discuss designs, fuel mixtures, and a host of other topics. There’s also a lot of advice for both those getting into the game, as well as those who have been in a while.

Recently, John posted a note about the Rocket Racing League and some advice about the programming controlling vital components of the jets. Unfortunately, the mailing list archives require you to be a member of the list to view, but I’ll include some snippets of his post here.

The test pilot for the rocket racing league project made the suggestion that we should not allow the computer to shutdown the engine during the critical five to fifteen second period where the plane is at takeoff speed, but too close to the ground to make the turn needed to get backdown on a runway. We currently shut the engine down whenever a sensor goes out of expected range, and there are indeed plausible conditions where this can happen even when the engine is operating acceptably, such as a pressure transducer line cracking from vibration. On the other hand, there are plausible conditions where you really do want the computer to shut the valves immediately, such as a manifold explosion blowing the chamber off.

Disregarding the question of whether it was a good idea or not, this seems a really straightforward thing to implement. However, I cautioned everyone that this type of modification has all the earmarks of something that will almost certainly cause some problems when implemented.

Shutting off the engines on a regular plane is bad enough, but we’re talking about a full-blown rocket with wings here. I can imagine that a sudden loss of engines is enough to cause a good deal of stress for any pilot, but losing the engines just as the plane is taking off could be devastating. Of course, the engine exploding could be pretty devastating too.

We did implement it, and guess what? It caused a problem. We caught it in a static test and fixed it, and haven’t seen another problem with it since, but it still fell into the category of “risky to implement”. If we weren’t operating at a high testing tempo, I wouldn’t have done it. I certainly wouldn’t have done it if we only got one testing opportunity a year (of course, I wouldn’t undertake a project that only got one testing opportunity a year…).

Our flight control code really isn’t all that complicated, the change was only a few lines of code, and I’m a pretty good programmer. The exact nature of why I considered it a bit risky deal with internal details, but the point is that even fairly trivial sounding changes aren’t risk free to make. There are certainly some classes of changes that I make to our codebase regularly that I don’t bat an eyelash at, but you can’t usually tell the difference without intimate knowledge of the code.

I’ve found similar situations in my own programs. There are areas of the code that I’ll change, knowing it will have no real effect on anything else, and then there are those areas where changes are trivial, but they cause odd problems that come back to bite you later. Testing is, of course, the best way to find these problems, but testing isn’t always possible. But then, I’m not writing code that could mean the difference between life and death for a pilot. Not *that* has to be some serious stress.

Many software guys do not have a reasonable gut check feel for the assessment of software changes in an aerospace project. My normal coding practice has over an order of magnitude more test cycles than Armadillo does physical tests, and Armadillo does over an order of magnitude more tests than most other aerospace companies. Things are fundamentally different at different orders of magnitude.

John’s team probably runs tests more than any other team out there. He has successfully married the typical programming cycle with aerospace engineering. They constantly make incremental improvements and then run out to test them. And as surprising as it sounds, it seems to cost them less to do this. By making incremental improvements, they can control, to some degree, the impact on the system. What this means in the end is that they don’t spend an inordinate amount of time building this huge, complex system, only to have it explode on the first test. Not that they haven’t had their share of failures, but they’ve been a bit less spectacular than some.

John also presented some additional info from his other job.

As another cautionary tale, I recently had the entire codebase for our current Id Software project analyzed by a high end static analysis company. I was very pleased when they reported that our discovered defect rate was well under half the average that they find on codebases of comparable size. However, there were still over a hundred things that we could look at and say, “yes, that is broken”. Sure, most of them wouldn’t really be a problem, but it illustrates the inherent danger of large software solutions. The best defense, by far, is to be as small and simple as possible.

Small and simple is definitely the best. The more complexity you add, the more bugs and odd behavior pop up. Use the KISS principle!

Switching Gears…

Ok, so I did it. I made the switch. I bought a Mac. Or, more specifically, I bought a Macbook Pro.

Why? Well, I had a few reasons. Windows is the standard for most office applications, and it’s great for gaming, but I find it to be a real pain to code in. I’m not talking code for Windows applications, I’m talking code for web applications. Most of my code is perl and PHP and I really have no interest in fighting with Windows to get a stable development platform for these. Sure, I can remotely access the files I need, but then I’m tethered to an Internet connection. I had gotten around this (somewhat) by installing Linux on my Windows machine via VirtualBox. It worked wonderfully, but it’s slower that way, and there are still minor problems with accessibility, things not working, etc.

OSX seemed to fit the bill, though. By default, it comes with apache and PHP, you can install MySQL easily, and it’s built on top of BSD. I can drop to a terminal prompt and interact with it the same way I interact with a Linux machine. In fact, almost every standard command I use on my Linux servers is already on my Macbook.

Installing Apple’s XCode developer tools gives me just about everything else I could need, including a free IDE! Though, this particular IDE is more suited for C++, Java, Ruby, Python, and Cocoa. Still, it’s free and that’s nothing to scoff at. I have been using a trial of Komodo, though, and I’m leaning towards buying myself a copy. $295 is steep, though.

What really sold me on a Mac is the move to Intel processors and their Bootcamp software. I play games, and Mac doesn’t have the widest library of games, so having a Windows machine available is a must. Thanks to Bootcamp, I can continue to play games while keeping my development platform as well. Now I have OSX as my primary OS and a smaller Bootcamp partition for playing games. With the nVidia GeForce card in this beast, as well as a fast processor and 2GB of RAM, I’m set for a while..

There are times, though, when I’d like to have Windows apps at my fingertips, while I’m in OSX. For that, I’ve tried both Parallels and VMWare Fusion. Parallels is nice, and it’s been around for a while. It seems to work really well, and I had no real problems trying it out. VMWare Fusion 2 is currently in beta, and I installed that as well. I’m definitely leaning towards VMWare, though, because I’ve used them in the past, and they really know virtual machines. Both programs have a nifty feature that lets you run Windows apps in such as way as to make it seem like they’re running in OSX. In parallels it’s called Coherence, and in VMWare it’s called Unity. Neat features!

So far I’ve been quite pleased with my purchase. The machine is sleak, runs fast, and allows me more flexibility than I’ve ever had in a laptop. It does run a bit hot at times, but that’s what lapdesks are for.. :)

So now I’m an Apple fan… I’m sure you’ll be seeing posts about OSX applications as I learn more about my Mac. I definitely recommend checking them out if you’ve never used one. And, if you have used one in the past, pre-OSX days, check them out now. I hates the old Mac OS, but OSX is something completely different, definitely work a second look.

Instant Kernel-ification


Server downtime is the scourge of all administrators, sometimes to the extent of bypassing necessary security upgrades, all in the name of keeping machines online.  Thanks to an MIT graduate student, Jeffery Brian Arnold, keeping a machine online, and up to date with security patches, may be easier than ever.

Ksplice, as the project is called, is a small executable that allows an administrator the ability to patch security holes in the Linux kernel, without rebooting the system.  According to the Ksplice website :

“Ksplice allows system administrators to apply security patches to the Linux kernel without having to reboot. Ksplice takes as input a source code change in unified diff format and the kernel source code to be patched, and it applies the patch to the corresponding running kernel. The running kernel does not need to have been prepared in advance in any way.”

Of course, Ksplice is not a perfect silver bullet, some patches cannot be applied using Ksplice.  Specifically, any patch that require “semantic changes to data structures” cannot be applied to the running kernel.  A semantic change is a change “that would require existing instances of kernel data structures to be transformed.”

But that doesn’t mean that Ksplice isn’t useful.  Jeffery looked at 32 months of kernel security patches and found that 84% of them could be applied using Ksplice.  That’s sure to increase the uptime.

I have to wonder, though, what is so important that you need that much uptime.  Sure, it’s nice to have the system run all the time, but if you have something that is absolutely mission critical, that must run 24×7, regardless, won’t you have a backup or two?  Besides which, you generally want to test patches before applying them to such sensitive systems.

There are, of course, other uses for this technology.  As noted on the Ksplice website, you can also use Ksplice to “add debugging code to the kernel or to make any other code changes that do not modify data structure semantics.”  Jeffery has posted a paper detailing how the technology works.

Pretty neat technology.  I wonder if this will lead to zero downtime kernel updates direct from Linux vendors.  As it is now, you’ll need to locate and manually apply kernel patches using this tool.


To optimize…

… or not to optimize, that is the programmer’s dilemma.  Optimization is a powerful tool in the programmer’s arsenal, but one that should be used sparingly and with care.  The key to optimization is identifying what exactly to optimize.


Shawn Hargreaves, creator of the Allegro game programming library recently posted a link to the blog of Thomas Aylesworth, a.k.a. SwampThingTom.  According to his blog, Thomas is a software engineer for the aerospace and defense industry.  He’s also a hobbyist game developer.

Tom’s first foray into the world of blogging is a series of posts about optimization, specifically targeting XNA based games.  In his first post, he explains the importance of design and what Big O notation is.  His second post delves into prototyping and benchmarking, complete with examples.  In part three, he introduces us to the NProf execution profiler as well as pointing out a few other potential bottlenecks.

Optimization in general is something you shouldn’t really need to worry about until the very end of the development cycle, if ever.  Optimization is a great tool for squeezing just a few more cycles out of your code when you really need it.  What you normally don’t see, however is a significant increase in speed.  If you’re looking for a significant increase in speed, take a look at your underlying algorithm.

Generally speaking, unless you’re writing extremely specialized code, optimization should be used very sparingly.  You’re better off looking for the elegant way to solve your programming dilemma.  Look into alternative algorithms or possibly re-design the data flow.  If you’re not sure where the bottleneck is, look into using a code profiler, or simply add debugging statement that surround suspected “slow” code.  You’ll usually find that a poor design decision is causing the bottleneck and that a simple re-design can result in huge speed increases while keeping your code readable and maintainable.


If you’re interested in optimization, or even just curious, take a look at Tom’s articles, they’re a great read.

Common PHP Regular Expression Security Issue

Stefan Esser (PHP Security Blog, Suhosin) recently posted an entry on his blog titled “Holes in most preg_match() filters” about a possible security issue that apparently escapes a lot of notice.

Let me explain the situation.  PHP uses Perl Compatible Regular Expressions, PCRE, for pattern matching.  In PCRE the carat metacharacter (^) is used to match the very beginning of the string, and the dollar-sign metacharacter ($) is used to match the end of the string.  This is extremely useful to ensure that the expression you’ve written has matched the entire string.

However, PCRE_DOLLAR_ENDONLY is not used by default.  This means that the dollar-sign metacharacter still matches to the end of the string, but it also matches is a newline character is at the end of the string.  In other words, a newline character may, or may not be present at the end of the string and you won’t know either way by default.

So, how do we fix this then?  Well, there are two ways.  First, you can add a D modifier to the end of the regular expression like this :

preg_match(‘/^[a-z]+$/D’, $string);

Or, you can use the \z modifier like this :

preg_match(‘/^[a-z]+\z/’, $string);

Either method works, although from the comments at Stefan’s site, it looks like \z is more portable since Perl doesn’t support the D modifier.

Here is short script to “prove” this, as it were :


$badstring = urldecode(“test%0a”);

if (preg_match(‘/^[0-9a-zA-Z]+$/’, $badstring)) {

print “Test 1 MATCHES\n”


if (preg_match(‘/^[0-9a-zA-Z]+$/D’, $badstring)) {

print “Test 2 MATCHES\n”


if (preg_match(‘/^[0-9a-zA-Z]+\z/’, $badstring)) {

print “Test 3 MATCHES\n”



I’m posting this info for two reasons.  First, it’s something programmers need to know.  It’s important since security holes are a bad thing.  Second, I’m guilty of this myself.  phpTodo used the dollar-sign metacharacter without the D modifier, making my code somewhat insecure.

The good news is that I have corrected the problem and posted a new version.  This is a precautionary measure, I don’t believe this adversely affected the security of the application, but better safe than sorry.  Head over and grab the new version just to be on the safe side.

phpTodo 0.8 Beta Released

A new version of phpTodo, version 0.8 Beta, was released today.  It’s been almost six months since the last release, mostly due to lack of time.  My primary goal for this release was to add ATOM support and get all the bugs fixed.  I feel I was able to accomplish both of these goals.

I think an official 1.0 release is imminent, assuming I have time to work on the program.  I have a few features I’d like to add before 1.0 if I can.  If they do get added, a 0.9 gamma version will be released before 1.0 becomes official.

After the 1.0 release, I’d like to get group support added.  In addition, I’m thinking about switching from single category based tasks to tags.  This would allow a single todo item to be placed into several categories at the same time.  Feed support will be updated as well, keeping in-line with the current feature set.


Overall, I’m quite happy with this project.  It’s helped me out in numerous ways, organizing my personal todo lists as well as giving me the opportunity to work on an open-source project.  I’d love to hear some feedback concerning this project, especially if you’re using it on a daily basis.  I’m definitely open to suggestions for improvements and I’d like to get some additional CSS layouts to include with the distribution.  You can leave any comments you may have right here on this blog entry.

Thanks to everyone who has already sent me suggestions and bug reports.  I hope to hear from more of you soon!  If you’re interested in trying out phpTodo, check out the demo site.

Book Review : 19 Deadly Sins of Software Security

Security is a pretty hot topic these days. Problems range from zombie computers acquired through viral attacks, to targeted intrusion of high-visibility targets. In many cases, insecure software is to blame for the security breach. With the increasing complexity of today’s software and the increased presence of criminals online, security is of the utmost importance.

19 Deadly Sins of Software Security was written by a trio of security researchers and software developers. The original list of 19 sins was developed by John Viega at the behest of Amit Yoran who was the Director of the Department of Homeland Security’s National Cyber Security Division. The list details 19 of the most common security flaws that exist in computer software.

The book details each flaw and the potential security risks posed when the flaw exists in your code. Examples of flawed software are presented to provide an insight into the seriousness of these flaws. The authors also detail ways to find these flaws in your code, and steps to prevent the problem in the future.

Overall the book covers most of the commonly known security flaws. These include SQL Injection, Cross Site Scripting, and Buffer Overruns. There are also a few lesser known flaws such as Integer Overflows and Format String problems.

The authors recognize that software flaws can also consist of conceptual and usability errors. For instance, one of the sins covered is the failure to protect network traffic. While the book goes into greater detail, this flaw generally means that the designer did not take into account the open network and failed to encrypt important data.

The last chapter covers usability. The authors detail how many applications leave too many options open for the user while making dialogs cryptic in nature. Default settings are either set too loose for proper security, or the fallback mechanisms used in the event of a failure cause more harm than good. As the Microsoft Security Response Center put it, “Security only works if the secure way also happens to be the easy way.”

This book is great for both novice and seasoned developers. As with most security books, it covers much of the same material, but is presented in new ways. Continual reminders about security can only help developers produce more secure code.

[Other References]

10 Immutable Laws of Security Administration

10 Immutable Laws of Security

Michael Howard’s Weblog

John Viega’s HomePage

Microsoft XNA Game Studio Express Released

Ok, so I’m a little late, but XNA Express was released on Monday. For those that don’t know, XNA is Microsoft’s newest foray into the world of hobbyist programmers. In a nutshell, XNA gives you everything you need to write and publish games for both the PC and XBox 360.

You can read all about XNA at the Microsoft Game Technologies Center. To download XNA you’ll need XNA Game Studio Express, the XNA Framework Redistributable, and Visual C# 2005 Express Edition.

In addition to the XNA release, GarageGames has released their TorqueX game engine, based on XNA. TorqueX is free to download and try out for 30 days and is a mere $100 for indie developers. The engine looks pretty nice and it will be neat to see what developers come up with in the coming months.

Also on the XNA front, Dave Weller from Microsoft mentioned in his blog that you can code XNA games in F# now. F# is apparently a programming language designed by the Microsoft Research team. It marries together a large host of features from a variety of programming languages such as Python, C#, Scheme, and more. It looks interesting, but does the world really need a new language at this point?

At any rate, get out there, get XNA, and get coding!

AJAX and Security, Revisited

In the last two days I’ve started to notice a number of articles detailing security in an AJAX application. Apparently there are a lot of people out there touting AJAX as this super-secure way of serving content on the web. And then there are those that are touting it as less secure than traditional DHTML sites. Mike Kemp of Heise Security warns that AJAX can open you up to attack while Jeremiah Grossman of Whitehat Security explains that AJAX is no less secure than traditional DHTML.

But let’s look at the reality of the situation. Regardless of the language and methodology used, security still breaks down into some fairly straightforward concepts :

    1. Never trust the client
      • In simple terms, consider the user of the application to be the enemy. Double check everything the user sends you and make sure that what they send is acceptable. Be as restrictive as possible because even the simplest mistake can be costly.
    2. Design using the Defense In Depth approach
      • Defense in depth is a security strategy in which you use multiple layers of defense to prevent attacks. This type of strategy goes beyond the web page you are trying to serve and encompasses the network as well. Simply put, you design your security to run at each layer. What this means is that instead of just checking input at the server level you instead check it at every layer the data interacts with. While this means more code, it can also mean more security. If someone was able to get through one layer, it doesn’t mean they’ll get through the next.
    3. Test Test Test
      • Before you release your application, you test it. Add security penetration testing to your test suite. Attack the application from every angle you can think of and, if possible, have others attack it as well. It’s very hard for a programmer to check his own work for security flaws because he knows what the program is designed to do and what security code has been put in place. Having someone else test your application can reveal security and application bugs that you as a developer would never find.
    4. Keep up with current technology
      • Keeping up with technology is one of the best ways to learn how to secure your applications. I highly recommend reading security related programming books, blogs, and news to find out about new techniques, reinforce old techniques, and, most importantly, to keep security at the forefront of your mind. If you’re not thinking security, then you’re likely to make simple mistakes that can cost a lot in the long run.
    5. Make sure your tools are up to date
      1. The tools you use can be the source of security bugs if you don’t keep them up to date. A great example of this are the APIs you use within your programs. If you link to old versions of the APIs then you may be susceptible to security and application bugs that were fixed in later releases. APIs are usually a black box item, so make sure you check into the API before deciding upon it’s use.

These are just a few ways to make sure you’re maximizing security in your code. There are many other lists out there, but you’ll find that they all come down to the same few basic principles. Never think that your program is 100% secure, there’s always a way to attack it. You just need to be more diligent than the attackers.

XNA Game Studio Express Beta 2 is out!

Saw over at both LetsKillDave and Gamasutra that XNA Beta 2 has been released. As with the previous release, VC# Express needs to be installed.

Unfortunately, I didn’t get to do much of anything with Beta 1, but I’m hoping to play around a bit with Beta 2. Definitely going to need to learn C# though. Just another language to add to the growing list of languages I’m familiar with.. :)

There are also a few sites dedicated to XNA development. Check them out :


XNA Spot

XNA Resources

GarageGames has also been working a bit with XNA and their Torque engine and they’ve ported it over to XNA. It’s going to Beta on November 6th, but should be released around the same time XNA is officially released. Of course, release dates slip so don’t take my word for it.. Exciting stuff!