New feature:

“My microblog”

This is basically a short summary of whatever I say so that you don’t have to read all of my blog, aka an abstract in academia, or “The Argument,” if you’re Milton while writing Paradise Lost, so, voila, my first “microblog” post.

I was able to install and have found no trouble manipulating Adobe Illustrator to prepare the graphics for the Software Carpentry wiki. I found that a problem that I thought would be painless took about two weeks of time to prepare (purchasing and jumping through fortunately small obstacles).

And now the full post:

—

This is what makes me happy:

1 click install.

I had to install Adobe Illustrator on my machine in the lab today, and I noticed that I had come a fair way to get the problem solved (and yet in order to solve a larger problem).

And then, it reminded me: problems are recursive. (Or in other words, in order to solve a big problem you have to solve a smaller problem first.) Here’s the steps required:

Insane, but now I’m finally converting the graphics to put into the wiki (and getting that to work with DrProject is another huge problem tree in itself XD).

I’m just lucky I didn’t have to find some bizzare dependency for Illustrator.

This weekend, I was installing a GIMP denoising plugin into my computer. I had tried to read the GIMP documentation on installing plugins, but when it came to Windows, they basically avoided the problem altogether. They made it seem like a hard task; many people do not know what the diferences is between a precompiled binary and source code is. You can’t write help files for developers; they already know what to do. You have to write help files for the masses.

The “heroics” as they called it could be done in a much simpler fashion. Plugins, at least for desktop applications, could have this simple work flow for users to follow to obtain the plugin they need.

1. Sync GIMP with the GIMP plugin registry website so GIMP can poll for new plugins

2. User manipulates graphic interface to download plugin from site into correct directory

3. Plugin works the next time GIMP is run.

(This is very similar to Ubuntu’s Add/Remove Programs.)

Currently, you have to put a binary into a non-specific folder by hand… now I have 2.4, so I naturally thought that the plugin should go into the 2.4/lib/gimp/plugin directory… but no, it doesn’t. It goes into the depreciated 2.0 folder. This caused me 20 minutes of utter frustration.

This is something that most developers do not know: frustration accumulates faster then you think. I suspect it actually grows exponentially, but I have yet to prove that (though I assure you that I’m actively researching it).

We should not expect, as computer scientists, for users to know where to put anything of our program. This is another sandboxing technique, and to run with the metaphor, a new toy shouldn’t be hard to reach.

One of the things that I am starting to recognize as both a programmer and QA is the lack of enforcement of defensive programming strategies. I recall in one class learning about how to crash programs, and the first thing I thought of was putting in a null. If you’re making your code available to others, such as an API or a class, you have to put a shield on your box. It saves headaches and blame, then the bad code can be made obvious, and that it was certainly not yours.

Programs should always expect to be given a null. Just throw the blasted exception. It’s good practice, and it can be done before the “real” code, so there’s no need to say it makes the code ugly, or that something has to be imported (it’s part of java.lang). It’s the literal equivalent of a precondition in a math proof (and everyone knows how much I hate math proofs), or jokingly, the null set is a subset of every set.

Another defensive practice that goes unnoticed is not enough arguments in some random system call with arguments (for the Windows folks that are lost, think of trying to run a DOS program with some extra information in it that the program expects). I recently crashed a program at multiple points just for this simple fact. If a program expects x arguments, then just return an exception automatically if those conditions aren’t met.

To extend the saga of this shoddy program, we expect that the user is a sys admin who can handle a stacktrace…

That’s something I disagree with because I feel:

1. It is ugly.
2. It is preventable.

Also, there was a bug that I found in the program that allowed the sys admin to delete the “All” project in DrProject. What if a malicious hacker got through all the firewalls and defense mechanisms? Or a sys admin mistypes? Or a less-informed user does not want the all project because he (or she) considers it a hindrance?

Quite the -little- failure.

But what is the source of failure? In this summer, in this blog, arguments will be proposed that deal with all the little gaffs in computer science. To be honest, I chose the name “Source of Failure” for my blog on a whim, and admittedly I based it on the “Worse than Failure” blog, but this one has meaning that is unknown, even to me. Its scope is beyond the scope of the “Worse Than Failure” blog; there’s a broader perspective means. This summer, I will try to answer both what “Source of Failure” means, and what we can do to prevent it.

I was editing the wiki of an instance of DrProject, and I said to myself after doing it innumerable amount of times:

This is drudgery.

This is what computers are for; to do all the repetition for us. But at the same time, we must make it easily available for users to use and deploy…

And that’s the hard part. How do you make a multi-delete and auto-update script easy and gracefully available, preferably on the GUI?

Not every user knows how to use shell scripts. Admitedly, I didn’t know what they were four months ago either. And no user would be happy to find out those hours of work could have been automated if they looked in xyz directory or got the sys admin to do it for them.

Allowing a GUI to preform scripted operations may be ugly, but it will help the user manage the wiki, and yet, more operations introduce further complexity into the program.

What to do?

In the last few days I’ve been converting the notes of Software Carpentry from XML to Markdown. That in itself is a realatively straightforward task. Touch up the converter program here and there, come up with a few workarounds…

Workarounds?!

One of the things that I learned as a kid was that programs should be intuitive to use. That’s why my generation as children would use programs like KidPix for their artistic creations. Those days are certainly long gone, but the desire for intuitive programs remains.

Programs also include programs that help programmers program or programs that interpret programs. Although I’m not trying to confuse you (as I am referring to IDEs and compilers), my point is that everything is a program, just as Alan Turring said that everything was data. Even English is a sort of program.

Therefore, since all programs must be intuitive, and everything is a program, then all things should be intuitive.

But they’re not.

One of the worst failures of CS is the lack of intuitiveness in some programs. It is understandable that not every single usecase can be explored, but many cases must be explored and unintuitive problems removed. I hate workarounds, and confusing installation. People these days expect (and in my opinion rightly so) everything done in a couple of clicks.

In essence, I support complete sandboxing.

Users are NOT programmers. Most of them [incorrectly] think that programmers preform a black art, and some even consider that programmers celebrate when a user causes a catastrophic error.

Making sure that users can do virtually anything possible — within the reasonable constraints of the program to avoid feature creep — is the only demand that users will put upon programmers in the decade to come.

One of the most important qualities of programs written today is that they must support numerous languages across the world. All programs written today, regardless of their intended audience, should be written with a Unicode file format [preferably UTF-8] with localization in mind. No internationalization leads to plenty of Unicode bugs!

I cant describe the confusion I was having when I was testing my own little Java program which expected to display some Kanji in a Java program. To my horror, it wasn’t working, and I thought that I had left a bug unsquashed. In reality, I was saving it in an ISO format that guaranteed only ANSI characters (to my knowledge). Saving it in UTF-8 solved the confusion.

The second thing I see and loathe in code is the expectation that there will be no localization. One of the greatest little lessons I learned from my high school teacher was to declare each and every string as a constant and leave it at the top of the file. Then, when somebody wants to localize the file, they do not have to hunt through each and every file editing the text!

I’ve even seen this failure littered throughout DrProject, and I certainly would be tempted to fix all of them. The only time I could see where this should be avoided is in C, which has no overloading of the + operator to concatenate strings easily, or include other data as well. Therefore, Java or Python have no excuse!

Welcome to a summer blog where I will take a light-hearted look at tech writing and testing DrProject. I’ll be commenting on some of the bizarre, amazing, and downright silly bugs that I see to poke fun at how much we can overlook as programmers.

On tech writing, I’ll be continuing my development of DrProject’s ever-growing documentation, and penning new wiki pages to support DrProject’s growing feature set and usability.

You can find more about DrProject at drproject.org.

The image of the flowers is a mod from http://www.flickr.com/photos/aussiegall/1540543921 and used under the CC-AT license. If you would like to use it yourself, by all means, but under the CC-AT-NC-SA.