Thursday, July 19, 2007

Good attributes for a software engineer

I was browsing the internet recently on my electronic browse-board when I came across this list of good attributes for a software engineer. I though I would share it with you.

http://www.thundernet.com/alpartis/articles/engineer.shtml

IMHO there's quite a difference from being a developer or "hacker" as Paul Graham likes to say and being a software engineer. I don't like being called a hacker. I like to think of myself as a very clever, inventive, dedicated, no compromises, problem solving rottweiler. However, I also like to think that what I'm doing is designing products for some goal. Products that will be around for a long time and are built with maintainability and extensibility in mind. While coming up with a cute solution is nice, software development is more than that. You have specs, deadlines, budgets, design constraints, maintainability, complexity budgets, safety of people and their data, coupling, cohesion, deployment, supportability etc.. to worry about. The hacker finds solutions. The engineer builds. And their's a fundamental difference in mindset.

Tuesday, July 10, 2007

ramblings without insight, pause or coherence

On the 23rd of September 1865, Steve Stormsmith set sail from Portsmith for the new world. At 12:70pm, seven days later he was found slightly confused inside a Walmart in Sam Town, Kentucky in the present day trapped in a piece of long winded sci-fi novel dialog with a shelf stock boy who name has been lost to the ages but who is know to those who purvey in such things as name or titles as Bob, the self stock boy. Bringer of New Inventory, Dropper of Cans and Announcer of Today's Specials.

Steve looked around him in a startled fashion having been startled by the mysterious teleportation slash "startleling" machine which had transported him to his current location by mechanism unknown. He took a moment to marvel over the last sentence then bravely pushed aside a can of string peas on a nearby shelf. The can of peas who, up until that moment, had quite happily been blocking Bob from Steve's view now moved themselves sideways. The inertia of the tin and the friction between itself and the shelf surface bent under the iron will of Steve and the marginal amount of mechanical force required to move the aforementioned can of small, green, eatable objects slightly to the left. Steve paused to look at the lettering on the aforementioned can of small, green, eatable objects and noted that it was written "peas". He did not recognized the letters or the word as he was not able to read. He had lost his ability to read in a freak speed reading accident when he was a teenager. People had always told him to slow down, but he wouldn't listen. He was young and therefore immortal. What no one had told him was you don't necessarily die. Sometimes you're just horribly cripple or mutilated. Many have lost an arm or a leg speed reading beyond their capabilities. As it turned out Steve lost his ability to read at all. What no one told Steve was that the immortality of his youth only applied to his physical form and not his soul, which died a little each time he was confronted by a labeled can of tinned vegetables. How could life do this to him? For all he knew the can could contain tiny, green, novelty golf balls as the only thing he had to go on the picture on the tin. He didn't even know where he was, which would have been helpful to know, for if he had known where he was he would have realized that it could only have been a can of peas as Walmart always stocks the tiny, green, novelty golf balls next to the tinned pineapple slices. The can he was looking at was next to the tinned tomatoes. It was a dead give away, really.

It was Bob who eventually broke the melancholy silence. "Umm.." he said as if he was thinking what to say, though in reality he was trying to determine if the question he was about to ask was a stupid question. It turned out that the question he was about to ask was not a stupid question although there was no way that Bob, given what he knew, could be sure. In the end he asked the question not because he was certain it was an insightful question to ask but because it was what the employee training pamphlet told he he should ask. "Can I help you?".

Steve looked at Bob. No, in truth he stared at Bob. Steve concentrated hard on the auditory signal he had picked up. He brain analyzed the signal in extreme detail. It checked the signal for peaks and valleys. It split the signal up into its constituent parts. It separated noise from voice from background clutter. Eventually it could make out some kind of speech. A call went our through the mass of connected nerves and neurons for an interpreter, some quivering mass of white or gray matter which could make sense of the auditory blizzard of signals. Eventually a match was found and the neurons did fire and rejoice for it had been determined that the voice was one which was speaking English. From there it was easy. Words were decoded, context was added, a pinch of grammar a dab of linguistic a touch of magic and poof! Steve understood the sentence. By this time, however, Steve realized he'd been staring at Bob for well over a twelfth of a second. He scanned over the mass of text that had brought him to this moment and realized a horrible truth. The writer was padding his novel. Steve felt a chill pass over his soul. It would be a long time before he slept again.

-------------------

That's the end of chapter 1 of The Incredibly Long Winded sci-fi novel. Join us next week for chapter 2 where a passer by asks Bob where the cereal is kept and half the world's population mysteriously dies of old age.

Thursday, July 5, 2007

Oops, the RegExp was too greedy.. and no one thought about cancel. The race is on!

I have a saying. Don't write bugs, your program has enough with the ones you don't know about. What I mean by this is don't write code that you know can fail under certain rare circumstances/inputs/races because murphy's law says those circumstances will occur. Also, since you're not perfect, those special case might be more common than you think and may interact with bugs you don't know about to create little disasters.

Recently I changed my CVS password on our local CVS server. This was done by using a very convenient script. My login name is "at". When I changed my password "mat"'s account was deleted. Later, a colleague "vsingh" went on the server to check to see if his account was deleted and all the user accounts except his disappeared. What happened?

Well, the convenient script changed the passwords by reading in the whole file, deleting all the lines that contained "username:" and witting out the file again appending the new password. It's unfortunate that the script's RegEx didn't bother to match newlines as it meant that when "at" changed his password "mat"'s account was deleted. Good thing "pat" and "arafat" don't work in R&D..

So, why did user "vsingh" delete everyone's account? Well, user "vsingh" was only interested in whether his account was deleted, so he got far enough to type in a password then typed ctrl-c to cancel. Unfortunately the script behaved badly when it was canceled. Instead of reading in the file, modifying it then writing it out it canceled reading the file, added vsingh and over-wrote the original. Net result: some panic until we restored the file from backup.

Oh, and there's still a race condition in the script too. Can you spot it? Thankfully that hasn't manifested yet.

Thursday, June 28, 2007

Dictionaries filled with typos

Why, oh why do most spell check dictionaries allow the user to easily add words to the dictionary but not remove them? Every once a week or so I accidentally add yet another common typo to the list of custom words and then have to go looking through that programs config files searching for the place where it keeps my list-of-typos, find it, and remove it. How do are normal users supposed to deal with this situation? I seem to remember the first few programs I used with this feature used to provide a nice way of going into the custom list of words and editing them. Now they just disappear into the ether and good look trying to convince the computer that "teh" is not a valid word!

Grr..both SeaMonkey and Evolution do this to me. At first I thought it might be accessible by way of the preferences. Since it was a relatively pedestrian setting, I looked in the advanced tab.. Nope, not there... Not in any other either.. Oh well.

Putting a potentially dangerous setting right next to items that are in common use is just bad UI design. Making it incredibly difficult to fix the mistake is downright user hostile. A pox on whoever came up with the bright idea of omitting this setting!

Thursday, June 21, 2007

Programming in a group

http://www.codinghorror.com/blog/archives/000890.html

1 isn't the loneliest number! 0 is! It doesn't even have itself to keep it company!

Actually, I spent almost 10 years programming on my own, in my own projects. When I did join the rest of the programmer race, the biggest challenge was communications. Thomas Kuhn, in his book The Structure of Scientific Revolutions, mentions that one of the problems when trying to resolve conflicts between two competing paradigms is that the vocabulairy, structure etc.. of the frameworks used within each paradigm are different. In order to have successful communication, you need to know enough of the other person's frame of reference and share enough vocabulary in common to say the right words in the right order to transmit a thought. Unfortunately for me, I had little to no idea of how other people thought about programming and only a vague idea of the vocabulary. My first few 6 months were spent in a continuous, desperate bid to explain my thoughts on a given design or problem in a way that was comprehensible to someone else. In the end I got the general idea.

Programming in a group can be very humbling. It's human nature to ignore one's own mistakes if it's believed they were mistakes but inevitable.. or that something or other was impossible anyway... When programming in a group, it's likely that someone in the group will be able to show you your folly; to see that your inevitable mistake is someone else's obvious mistake.

..arrogance is the natural result of insufficient "learning opportunities"..

Wednesday, June 20, 2007

Biking

Last week-end was the Ottawa-Kingston bike tour.. aka the Rideau Lakes cycle tour.

http://www.ottawabicycleclub.ca/rlct

It's a 360km bike ride spread out over two days. 180km from Kingston to Ottawa and next day back again.

Why is it the last 20km are always completely brutal? When we past the 45km to go mark I felt fine. Even when we past the last 20km mark I felt fine.. but then we got this massive headwind and I just died. Anyways, we did alright in the end. It also only happens on the second day. The first day the last few kilometers are always fine.. Must be some sort of bike-tour-law-of-physics or something :-).

On the last day of the tour I got two flats (the second one happened literally a few hundred meters from the finish. It was a relatively slow leak so I just leaned progressively forward until I had to get off with about 100 meters to go.) and my chain broke. Oh how I hate it when the chain breaks.. My chain has now broken twice. Time to get a new chain. It was lucky my dad had brought with him some extra chain links because I'd already taken 2 out last time and needed to take another 4 out for the repair (well, three links really, but it was easier just t take 4 out). He brought exactly 6 links so it worked out well.

The problem with getting a new chain is that you also need to get a rear cassette. If you don't, the old cassette will damage the new chain and wear it out very quickly. Since I broke my wheel two weeks before the ride and did the ride on a lender, I also need a new wheel. The pessimist here would suggest I actually could use a new bike but I don't think so. I don't like throwing out old equipment, especially if it's not working. I guess that means I'd rather get it working and then throw it out, which doesn't make any sense, but I've checked and there's no law that says I have to make sense so I'm going to stick with my preference. :-).. Not that I am going to throw it out. I'm sure it could do another hundred million miles so the plan is: get all the new parts I need to bring the bike to working order and then keep riding it.

One important thing I learned on this tour: taking two spare inner tubes is good. However, before you do, make sure they are the right size for your wheel. An inner tube with a schrader valve won't work on a presta valve rim... Also 35mm wide is a little too big for a 28mm tire.. doh! Canadian tire sold me the wrong tube! Right box with wrong tube!

Monday, June 18, 2007

Bugs

Well, I'm happy. One of the bugs I filed on sun's java VM's drag and
drop support on windows has been dealt with and fixed.

http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6362095

I'm quite proud to have helped improve the robustness of their product.
It makes me wonder, though... Why did this take so long to find?

While trying to figure out what the heck was wrong with my code I posted
a message in the java forums. The only person to reply was someone
wanting to know how the heck I managed to get drag and drop working at
all:

http://forum.java.sun.com/thread.jspa?threadID=567809&messageID=3979708

I'm starting to wonder if drag and drop is one of those technologies the
tends to be badly understood despite the fact it's widely used and very
basic. A few other technologies that have a similar problem are:

1) How various different text encoding work and interact. Everyone
understands ascii and everyone understands that UTF is magic fairy dust
that makes everything work but the concept of a text encoding format and
how it's important to know what text encoding is being used when reading
a string of text seems to be lost on the majority of programmers.

http://www.codinghorror.com/blog/archives/000178.html

2) String escaping. The number of times I've seen code that hasn't been
properly escaped before being processed is uncountable. The basic idea
behind escaping is to allow for arbitrary strings inside another
formated string. The classic example for me is how to display things
like html syntax inside a html document.

http://en.wikipedia.org/wiki/Escape_character
http://en.wikipedia.org/wiki/HTML_encoding
http://amit.chakradeo.net/2005/11/28/escaping-urls-vs-escaping-html/

The reason I mention these two in addition to drag and drop is, is the
one thing they all have in common is the central point of confusion with
these technique/technologies revolves around data formats. In fact,
sometimes I swear that, if I didn't know better, many programmers simply
do not understand what it means for data to be in a format at all.