Posted by: sourceoffailure | January 11, 2009

BlogCPR: What happened?

At least I’m back– wait. That’s what you would say to a physician.

Fortunately this semester I have been blessed with two CS courses that I can rant about, and that should give me ample material for this blog to continue. One is a UI Design course and the other is Data Structures and Analysis. Both of the professors are excellent, and I am enjoying the classes very much.

Posted by: sourceoffailure | August 24, 2008

Purpose Change

As summer ends, this blog also is nearing its end… or at least, in its original form.

The original purpose of this blog was to write about my experiences in software testing this summer. But being a computer scientist doesn’t simply involve testing. Where does that code come from? And how come it is so buggy?

I enjoy more than just software testing. You might be surprised, but seeing a stack trace gives me an incredible high, because I know that somebody else won’t have to experience it. It feels, in some ways, a little special (although I feel awful when I’ve introduced a bug into my own code, so I know what it feels like on the other side of the coin).

I also actually do like programming. That’s what I came here for. That’s what my reason for being in this business is for. I know for a fact that there are an innumerable number of programmers that are better, more advanced, and smarter then myself.

Instead, I simply want to do my part, play my role in this grand stage.

Being a computer scientist to me means I get to play many different parts. To become successful, one must become versatile and have many different skillsets to draw on during this technological revolution. One of my other disciplines, Political Science, calls this time the dawn of the knowledge economy.

Whether I code, test, design, draw, or write, the goal is the same: the development of the program at hand.

That’s why I love computer science; because programmers are not only scientists, but artisans.

It is often said that you change technology, while technology changes you. It changes the way you work. It changes the way you play. It changes the way you go about your life.

Few other professions offer such a possibility.

So as they say in radio,

So long for now.

PS. I will continue to post during school later this fall about all the things now listed.

Posted by: sourceoffailure | August 10, 2008

Agile ’08 and the Home Strech

I thought I would be blogging more, but hey, life gets busy. And as one Adam @ Home comic strip put it, some days, “I don’t have anything to blog about.”

Microblog: After learning about and developing new skills at the Agile Conference in Toronto, Canada, I look forward to applying the techniques and information I’ve learned, especially in User Experience (UX), to new projects (or old projects, or DrProject -.-) in the fall. The first round of testing of DrProject’s NEWT milestone is complete (as testing/designing and coding are in a two-step), and now I am processing LaTeX into Markdown for Greg Wilson’s CSC301 informal textbook.

Microblog 2, directed at Python 3.0: I want to explore in the paragraphs below how I think that Python has shot itself in the foot and how I might have simple solutions, some of which has been practiced in other languages.

Python, in the last few years, has become a highly respected and stable language. Reports expect that 15% of Google’s codebase is written in Python (1). However, with the expected release of Python 3.0 comes reports that previously written Python scripts will be incompatible with new ones, and that brings a lot of problems with it. Python, in essense, has just shot itself in the foot.

Part of the conventions of programming languages is that you do not break someone else’s code when the compiler changes. Java is an excellent example. Sun may, from time to time, depreciate various methods and practices. In this case, the code does not completely break, but in a compile error, says that the user is calling a depreciated method. Also, Sun elects to still display the javadoc for these old methods, even if they are not ment to be used any longer.

Although Guido deserves some reprieve for attempting to increase the simplicity of Python coding (likely in the face of it’s similar competitor, Ruby), this experiment jeopardizes the credibility of the programs produced wth Python (some which certainly have influence in business) and will lead to utter chaos and hassle of maintaining more then one distribution of Python on a single system, particularly to users who are not familliar with Python, or with programming languages in general. Those users expect backward compatible behaviour.

So, what to do?  I propose three solutions:

0. If the language is going to experience a substantial shift, create a new language and change its name. Cobra anyone?

1. Adaptive refactoring. This is the same practice as Sun used for the getGraphics() method in the AWT. Originally, the getGraphics method of a component to draw objects on the screen. Now, get2DGraphics() is used. getGraphics is now simply a wrapper for the new method. Python could also do a simmilar process, which allows the use of both processes to access the same thing. Another part of this is based on the blackbox techinque. Describing the interface for something is much more efficient then describing its interals. Perhaps midway – in an agile development team – an efficency is noticed that will allow a refactoring of code. Concealing that refactoring until the next release with wrapper methods ensures that other people’s code does not break because you have redesigned your interface.

2. Depreciation, Support, and Final Removal. Old methods are depreciated but still supported within the language, and after a certain amount of time, are finally removed as they expect code that is still in use will not use such methods.

3. Versioning. This option is more of a preventative feature, but versioning the file to a specific compiler would prevent compiling 2.x code with a 3.y compiler and is much more helpful to the user instead of saying that a method that was expected to be there is now missing.

Python has just shot itself in the foot with its plans in the 3.0 release. But it doesn’t have to. There are three main ways that the language can keep out of trouble: Adaptive Refactoring, Depreciation, and Versioning. And if that is not enough, if the language itself is going to experience an earthquake of a shift, then simply change it’s name just like other projects. The last thing we need is broken code. We have enough of that already.

That is a source of failure.

Source (1):,breaking-the-python-code.aspx


This is the home stretch. The final week.

Posted by: sourceoffailure | July 8, 2008

Transforming Selenium into Bromine


By transforming Selenium scripts into Python, and running the Selenium Server on localhost,  I am able to automate and modify tests as one monster test suite as grouped in a folder. A future objective of mine is to unify unit tests and browser-end unit tests into one command.

The title for this week’s blog was inspired by a little bit of alchemy; Selenium is a JavaScript testing tool that is used on the browser level to check that all the Javascript is working properly. When you add a proton, in this metaphor representative of an idea, you get Bromine (Br). But watch out, it’s unstable.

In this case, that proton is Python. This isn’t to say that throwing Python will make Selenium unstable, or better. I’m more or less trying to say that it’s an interesting, potent mix of poison and radioactivity.

Metaphors aside, I’ve been able to get the Selenium server up and running, which acts as a proxy server so Selenium can preform JavaScript testing. To my surprise, and my delight, the Selenium Server is written in Java, which I daresay is the closest thing that CS has to a lingua franca.

Getting Selenium to cooperate with Firefox shouldn’t be that hard with some help, and then I will be able to write some tests, using the Selenium IDE, that is then exported into Python and run as a batch.

This may involve writing a Python script that edits a Python script so that it can be run by anyone, because currently Selenium would enter my login information as a string, so other people would not be able to run my test successfully unless they were impersonating me. A little bit of basic metaprogramming didn’t hurt anyone, did it?


Apologies to Qi and Liz, whose comments were dumped by spam filters into the spambox. I’ll be sure that doesn’t happen again. Your comments were greatly appreciated.

Posted by: sourceoffailure | June 11, 2008

Programming Gold

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.

Posted by: sourceoffailure | June 9, 2008

Plug-in Problems

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.

Posted by: sourceoffailure | June 6, 2008

Defensive Programming

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.

Posted by: sourceoffailure | May 31, 2008

Secret Scripts

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?

Posted by: sourceoffailure | May 27, 2008

Carpentry Without Power Tools

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…


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.

Posted by: sourceoffailure | May 16, 2008


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!

Older Posts »