Tuesday, January 31, 2006
Shovel-think
Well, I was outside, shoveling, and I got to thinking. I do that a lot while performing mundane tasks. The problem is that homework is a mundane task. Anyhow, I was thinking, and I realized that of the programming that I do on my own (As in, not for work or homework), it falls into three categories. Those are programs intended to be used by other people, programs I intend to use myself, and boredom programs. You can actually classify these three categories based on the amount of error handling, interestingly enough.
Boredom programs
These are essentially techdemos. I'll be sitting around one day, bored, and think of something cool to write. I'll work on it for a few hours, enough to get it in a working demonstrable state, and then abandon it forever. Virtually no forthought goes into these things, I just sit down and start typing code.
A good example is the C#-based multithreaded IRC server I wrote yesterday. I was sitting around, bored, and just started writing an IRC server. I think I spent about 5 or 6 hours on it last night, most of the time spent learning how to do things I wanted to do. By the end of the coding block, I had an IRC server that mIRC could connect to, join channels, and PM people. A very small subset of the IRC featureset, sure, but enough for casual use. Enough to connect a few copies of mIRC and actually use them.
Multithreading a network app in .NET is easy. In fact, any asynchronous socket work is more or less multithreaded by default. The way it works is through callbacks. When you listen for connections, you have a callback. When there is data waiting to be read, you have a callback. These callbacks are in seperate threads, managed by the framework. So if you are writing something like an HTTP server with no shared info between threads, it is insanely easy. Even if you do have shared data structures like my IRC server does, it doesn't much matter. All shared data in my app is done via hash tables, and a few simple checks handle data being removed before we try to do something with it.
Programs I intend to use myself
These are the types of programs where I'll think, hey, I need an app to do such and such. iPodDrop started out as such a program, and is in the process of moving to the third category. When started, the program had very little error checking. It had enough to handle cases that I was likely to encounter, but nothing to handle somebody doing something wrong. So, I might handle an unreadable file, but wouldn't bother handling funky framerates; I wouldn't pass iPodDrop a file with a framerate of 36. Of course, now that iPodDrop is moving to the third category, such checks are starting to show up to ensure better stability.
These types of apps are likely to get finished into a working state. Working, but not polished. They do what they're meant to do, and it doesn't have to be pretty.
Programs I intend others to use
A lot of my web work could be considered to be in this category. iPodDrop is moving into it. In this category, error checking is included to cover common scenarios, trying to make sure users can't do dumb stuff. I don't go overboard, I mean an "or die" for most MySQL calls in a web app is fine. Since web apps are stateless, the occasional error isn't going to bring down the system, if the MySQL server hiccups or something. But I would add error handling for any user input, certainly, or expected failures.
To be honest, I intended this post to be a lot longer and in-depth, but I started writing it 5 hours ago and got interrupted, and am only finishing it now.
Boredom programs
These are essentially techdemos. I'll be sitting around one day, bored, and think of something cool to write. I'll work on it for a few hours, enough to get it in a working demonstrable state, and then abandon it forever. Virtually no forthought goes into these things, I just sit down and start typing code.
A good example is the C#-based multithreaded IRC server I wrote yesterday. I was sitting around, bored, and just started writing an IRC server. I think I spent about 5 or 6 hours on it last night, most of the time spent learning how to do things I wanted to do. By the end of the coding block, I had an IRC server that mIRC could connect to, join channels, and PM people. A very small subset of the IRC featureset, sure, but enough for casual use. Enough to connect a few copies of mIRC and actually use them.
Multithreading a network app in .NET is easy. In fact, any asynchronous socket work is more or less multithreaded by default. The way it works is through callbacks. When you listen for connections, you have a callback. When there is data waiting to be read, you have a callback. These callbacks are in seperate threads, managed by the framework. So if you are writing something like an HTTP server with no shared info between threads, it is insanely easy. Even if you do have shared data structures like my IRC server does, it doesn't much matter. All shared data in my app is done via hash tables, and a few simple checks handle data being removed before we try to do something with it.
Programs I intend to use myself
These are the types of programs where I'll think, hey, I need an app to do such and such. iPodDrop started out as such a program, and is in the process of moving to the third category. When started, the program had very little error checking. It had enough to handle cases that I was likely to encounter, but nothing to handle somebody doing something wrong. So, I might handle an unreadable file, but wouldn't bother handling funky framerates; I wouldn't pass iPodDrop a file with a framerate of 36. Of course, now that iPodDrop is moving to the third category, such checks are starting to show up to ensure better stability.
These types of apps are likely to get finished into a working state. Working, but not polished. They do what they're meant to do, and it doesn't have to be pretty.
Programs I intend others to use
A lot of my web work could be considered to be in this category. iPodDrop is moving into it. In this category, error checking is included to cover common scenarios, trying to make sure users can't do dumb stuff. I don't go overboard, I mean an "or die" for most MySQL calls in a web app is fine. Since web apps are stateless, the occasional error isn't going to bring down the system, if the MySQL server hiccups or something. But I would add error handling for any user input, certainly, or expected failures.
To be honest, I intended this post to be a lot longer and in-depth, but I started writing it 5 hours ago and got interrupted, and am only finishing it now.
