As I’ve been writing before, I’m currently working on an iPad and I’ve got security in mind. However, I’ve also got sanity checks in mind. What do I mean by that?
I’m not a huge, professional operation; instead, I am a one-man show (who has contracted out the actual programming but not the architecture) who is doing this in his spare time. I don’t have a lot of content to upload, but when I do, it has to be right. The user experience is critical to my app and that means that what I update has to be correct. The heart of my app is an xml config file that specifies how data is supposed to be accessed by the user, and how new data should be organized. When I add new data, I have to update the config file.
But what happens if I put a typo in the config file? This would mean either the user couldn’t access new content or it could corrupt existing content. That’s something I don’t want to happen because I don’t want to look like a clown. What do you think when you get software that doesn’t work after an update?
And frankly, me putting a typo in the config file is a possibility. I am doing the updates by hand and sometimes I do them late at night. Or I get on a roll and get careless (heck, when I write this blog, I am so excited to get a new post up that I commit typos all the time, to my chagrin). And what’s worse, even though I can proof read this stuff, I have a hard time proof reading my own writing. What I read on the screen, if it contains an error, is corrected by the time it gets to my brain because my biased brain has corrected the information and read it back to me the way I meant it, not the way I wrote it.
This is a big risk. How do I protect against myself?
The solution I am using is to write a script that examines my xml config file and does a sanity check on it. If it passes all the sanity checks, it writes the file to a pickup directory and only the contents of that directory ever get uploaded.
This sanity checker does the following:
Basically, it ensures that everything that is supposed to be there really is there, and if not, spit out an error. This protects me from myself.
This is the way I protect myself from uploading bad content – by ensuring I have a process in place to prevent it (of course, the question now is who polices the police? How do I know I wrote a valid sanity checker? The answer is that I tested it… what else can I say?).
You may be reading this blog and saying to yourself “Okay, what does this app have to do with the security space?” The answer is that I am modeling the architecture the same way that we do our spam filtering:
So, as you can see. much of what we do on the job I am reusing on a smaller scale. The software development life cycle is not just about releasing code but thinking about the entire experience end-to-end.
And that’s what I’m trying to do.
So you wrote an article on common sense and perhaps that you haven't heard of these fancy things called XSDs. Congrats!
Yes, JoeBob, I wrote an article on common sense. I do this because:
a) Many people in software development are isolated into their own specialty areas and aren't familiar with this sort of thing.
b) My readers have varying levels of technical acumen.
c) I enjoy writing about the software development process in plain English.
So yes, what is obvious to you is not so obvious to everyone else since we all can't be as sophisticated as you are.