blog.philcrissman.com

When I decided that I wanted to change my career and “go into computers”, I had a very limited exposure to computing.

Well… I should qualify that. It’s true, I had used DOS so much in high school (before there was Windows) that I preferred DOS to the Macintosh of that day, wrote my own autoexec.bat files, and in fact had a copy of DOS, Pascal, and Moria on 5.25” floppy disks that pretty much went everywhere with me. At the time, many DOS PCs did not have hard drives; you loaded the OS from a floppy, then it ran from memory and you put in some other disk with your files or other programs on it.

Read the rest of this entry

Let’s assume that testing your software is good. We’ll assume that you are working on a larger project, or as part of a team, so we want to test the code. Great. There we are.

Something to keep in mind is that exhaustive testing is not possible. This is not provable, and it would not be true if it were provable.

If it were provable, that would mean that you could locate everything testable within the software, and demonstrate that tests could not be written for all of them. But if it’s possible to locate everything testable within the software, then it must be possible to write tests for all of them.

Of course, showing that something is not provable isn’t the same thing as showing that it’s true… but let’s assume, just for fun, that exhaustive testing is not possible. I mean, exhaustive. Nothing left out. Nothing left untested. No input, output, or circumstance un-foreseen and un-tried. Impossible.

So there will be some things that are not tested. Whatever you don’t test probably has a bug in it, somewhere. That’s also unprovable, and a little bit cynical. It’s also a bit of a tautology. If we assume that all software has bugs (cynical? realistic), we know that the bugs are not in what you tested, because if they were in what you tested you would have found and corrected the bugs. So, said bugs (of whose existence we are confident) must be in the areas which you didn’t test.

Of course, if you’re going to do tests at all, you want to test everything you can; you want to at least attempt to be exhaustive, within reason. Good deal; your manager will be very happy.

For the record, I do think test-driven development is a Good Thing, and that it will probably ensure that, at the very least, your core concerns (whatever you had the foresight to test) will work properly.

But you’ll know that you haven’t tested everything. Because you can’t have tested everything.

I’ve started thinking along these lines before, but seeing hellotxt.com this evening started me thinking about it again.

The Problem

Social Networking is a great tool; it’s a cool thing. It’s not going away, and there are quite a few of them out there that are doing quite well. That’s the problem. There are a lot of them, and a lot of the people who like this sort of thing wind up with memberships on many of them. Some of them are more directly competitive with each other, but in general, the successful social networking sites have unique features which compel people to keep multiple accounts — most people don’t seem to give up one service in favor of another. Instead, they just add the new tool to their pantheon of social networks. Myspace, Facebook, Virb, Bebo, Digg, Vox, del.icio.us, LinkedIn, Twitter, Pownce, Jaiku… phew. The list could continue.

It’s this sort of mess that makes concepts like hellotxt work: Here! You can send out some information to multiple places at once. Your life will be better.

It’s a good tool, but doesn’t solve the problem.

Read the rest of this entry

Was just thinking: I’m 34 years old. Aren’t I supposed to, you know… aren’t I supposed to have arrived by now? Going by our assumptions when we were young, I mean; when I was 10, 11, 12, even a little older, I’m sure if you had asked me what I would do/be when I was 34, I would have said: an artist, or a writer, or a musician. Depending when you asked. But one thing’s for sure: I was pretty confident that whatever I was going to be, by the time I reached the ripe old age of 34, I was certainly going to be it by that time.

So why the heck do I still feel I’m not there?

Read the rest of this entry

Physics has the convenience of being able to speculate that any given particle could potentially be composed of yet smaller particles. I realize that the credulous limit of building-block particles has probably been reached, theoretically; whether quarks or super-strings, or what have you. But even those thought experiments were a giant leap from the already miniscule building block particles of atoms, protons, neutrons, electrons.

In computer science, we don’t really have that luxury. A bit is not ever going to get any smaller. There wouldn’t even be a lot of meaning to speak of a “half of a bit.” This is easier to see if you view a bit as “on or off”, or as a true::false, yes::no, 1::0 pair. In a true or false question, does “half of a true” even mean anything?

The whole model breaks down if you allow a bit to be anything other than on or off. It doesn’t have a “size” per se, it is by definition the smallest digital component there is.

Looking at bits from an electrical engineering standpoint, where a receptor might view a pulse of a certain strength as an “ON” bit, and a weak pulse as an “OFF” bit, it makes marginally more sense to speak of bits getting “smaller”. Theoretically, the amount of electrical current needed to indicate an ON or OFF bit would be determined by the sensitivity of the components; if a component can distinguish accurately between very slight signals, that’s really all that’s needed. But the “bit” hasn’t gotten any smaller, functionally. It’s still a bit. You still need eight or sixteen of them to represent character data; and so on, and so on.

Physicists can always hope to find and learn more about yet smaller and smaller components of the universe. Not us. Computer scientists are stuck with the bit.

This silly line of thinking arose when I was thinking about bandwidth (in the sense of data transfer, not the electrical engineering sense). As we go forward, the need for greater and greater bandwidth seems to loom as one of the more daunting technical problems we’ll be solving in the next decade or so. If you were to make a straight analogy with physical pipes, one logical step would be to make the material that you are pushing through the pipe smaller. More bandwidth automatically, right? Except that the information being shoved through the pipe isn’t going to get any smaller.

(I suppose we could somehow mandate that all network traffic must be gzipped or otherwise compressed; that might help a little, but I think it would be close to impossible to enforce without altering the open nature of the Internet.)

So, we’re left with making the pipes bigger.

Looking around a little, NegaBytes has some interesting tips for optimizing HTML and CSS. A lot of them involve simply using fewer characters—single character class or ID names, single character javascript variables. It’s certainly a tautology that doing this will save bandwidth, but it seems to be that it does so at the expense of code maintainability, at least to a certain extent.

I’m neither a physicist or an electrical engineer; so if I’ve oversimplified my analogies, or otherwise embarrassed myself here, feel free to let me know. :-)