Programming

The Importance Of Error Messages

I had a good laugh on Friday as I ready the Pop-up Potpourri: Mayday Edition article over on The Daily WTF. As one person commented: ”These make TheDailyWTF worth existing.” So funny. More so since these pop-ups come from actual applications. I have always believed that if you are going to display some sort of error message, the message should really only display a brief explaination of what happened (ie. ran out of disk space), what didn’t happen (ie. file wasn’t saved) and what the solution is, all from the user’s perspective. The user doesn’t care about internal error numbers or stack traces or anything else that relates to debugging of any kind. All the user wants to know is how can I fix the problem and move on with what I’m trying to do. Everything else is stuff that should be in the application’s log file.

That brings me to log files. I ran into a small error this weekend that caused me to sit down and say “what was I thinking?”. And before you start into me about not using a logger, such as log4j, forget it; this application predates log4j. And not only that, there are some instances I can think of where you may want your logging to go to stdout. I have slowly been migrating the logging over to log4j but there are still a fair number of calls to System.out.prinlnt(). Anyway, once again, I digress. I had been tinkering in the code of an application, adding some new features. But recently I had also been cleaning up old code, mostly instances where methods had been deprecated. I was testing something out, when I saw a string of these in my console logger:

UTF-8
UTF-8
UTF-8
UTF-8

The offending code it turned out was a result of a change I made due to a deprecated method within URLEncoder. The new method requires an encoding scheme, which The World Wide Web Consortium Recommendation states should be “UTF-8”. But what I had instead was “UTF-8 ” (notice the extra space) within code similar to this:

try {
  userList.append(URLEncoder.encode(lastUserStr, "UTF-8 "));
}
catch (UnsupportedEncodingException uee) {
  System.out.println(uee.getMessage());
}

The end result was that an UnsupportedEncodingException was being thrown and the error message associated with that exception was my invalid encoding scheme. Unfortunately, in a console logging window, that extra space doesn’t show up, so from a developer’s perspective it looks like UTF-8 isn’t supported. And that simply wasn’t the case. Since I haven’t got this particular class set up with log4j and not wishing to introduce any major changes at this point, I replaced the offending code with something like this:

try {
  userList.append(URLEncoder.encode(lastUserStr, "UTF-8"));
}
catch (UnsupportedEncodingException uee) {
  System.out.println("Unsupported encoding: " + "[" uee.getMessage() + "]");
}

So next time you are writing a error message, think aobut who the reader of the message will be and ensure the message is written from that person’s perspective. And don’t try and write a message that will satisfy multiple types of people.

Dynamic Languages

I read an article over at ONJava today titled ”Technologies to Watch: A Look at Four That May Challenge Java’s Development Dominance”. I was going to call it an ‘interesting’ article, but it really wasn’t that interesting. In fact, the author pretty much lost my attention when describing the first of these emerging technologies to watch, dynamic languages. The author started by saying that “dynamic languages can be much more productive than static ones like C++ or Java”. Statements like that make me cringe.

I think that it’s important in software development to use the right tool for the job. So if you’re writing a quick web app to generate [or in some cases, cheat at] hockey pool scores then I don’t think it makes a lot of sense necessarily to use Java Servlets. You could use it, but it’s not a production application, it’s going to be used internally, and you’ll likely going to make changes as you go along. So I would say that Perl (or some other similar dynamic language) is probably a good choice. That’s not to say that Perl can’t be used for production apps, so don’t start flaming me for that.

Where I have a real problem is that people generalize and equate writing actual lines of code with productivity, without thinking of the software writing process as a whole. The language mentioned in the article is Ruby. The author mentions that types in Java are static so you have to “you must create and compile a full program” and goes on to say that that because with Ruby types are dynamic, “you can just start typing and go.” The author is implying that with Ruby I will be way more productive. But the problem with the “type and go” mentality is that unless you are a disciplined programmer, you will do just that. You’ll type and go. And when something doesn’t work, you’ll try typing something else and go again. And again.

When you are forced to compile and link and whatever else, the type and go method becomes less productive. Agreed. So don’t do that. Instead, stop and think about what you are trying to accomplish, what happening instead and why the difference between the two. And how changes in one spot of the code will affect other things. I’m talking about a true understanding of the programming trade. You can’t do that if you keep thinking that this next change will work “this time.” Sure, we’ve all done it, but that doesn’t make it right. And I don’t know for sure but I’d be willing to bet that while the coders so-called “productivity” might be worse when using Java (or other such static language), the productivity of the development team over the whole software process is likely well above that of the dynamic languages. It’s not so great if the coders are cranking out the code but have to do things over and over because the code fails to work as expected during the testing phases.

Of course, all that said, you also have to factor in the programmers themselves, for if you have the very best (and disciplined) coders working in Ruby and poor coders doing the same thing in Java, it’s very possible that the Ruby project will be more successful faster. But I think as a whole, you won’t find too many production, enterprise applications written with dynamic languages. Flame if you want, but you’ll make your case a lot better if you write some code and show me.

Magical Development Environments / Languages

I was catching up on some more of my RSS feed reading and read Aaron Seigo’s entry on programming languages. While Aaron raises some good points, his request for an IDE that magically does everything is a pipe dream. IBM’s Websphere tried to do something similar and it sucked. At least it did when I used Websphere in early 2000. Everything was stored in a database (DB2 of course) and as such, broken syntax was identified immediately. But you had to use the Websphere IDE, which had an editor, a versioning client, etc but while the pieces worked, their functionality was all mediocre at best. Seriously. Only IBM fanatics loved Websphere; everyone else was saying “WTF?”. So while everything was magically integrated, not one of the pieces would have stood out if on it’s own. It was somewhat like using a tightly woven IDE that used MS Notepad as it’s editor, telnet as it’s CVS client, and voodoo for the administrative functionality (my examples suck, but you get where I’m going with this). And you couldn’t really use external tools and it didn’t really support plugins. So it did a lot of stuff on the fly for you but gone was the joy of writing code because it was so tedious to use all the mediocre tools.

For the past ten years, I’ve used multiple tools when developing. At first, it was Emacs and a bunch of command-line tools. Then I changed to various IDEs and various support tools (xxdiff, Cervisia, etc). Now I’ve settled on Eclipse, which does a reasonable job of allowing me to use a single tool when doing Java development. But that’s not out of the box; out of the box Eclipse is just okay. To make it better, you have to add a bunch of plugins to do various extras, like support JSPs and Tomcat.

So maybe Aaron’s request isn’t a pipe dream. Or maybe I’ve just lowered my standards and given in a bit. I still prefer Cervisia as a CVS client but use Eclipse’s built in one as it’s more convenient. I don’t think you’ll ever find Aaron’s request in anything but an open IDE that allows plugins to be built on top of it. Eclipse (and in talking to developers there several other IDEs) is certainly moving closer towards the dream becoming reality. That all said, I will speculate that the more you try to automate everything as Aaron requests, the more you need to tie the pieces together and the harder it is for that project to be open. And when that starts happening then the cycle towards a ‘mediocre at best’ IDE begins.

Learning To Code

I read an interview this morning with Blake Ross of Firefox fame and was a bit shocked to read Blake’s comments that ’The only way to learn how to code is to code. You can’t learn it in school, and you can’t learn it curled up in bed with a book.’ He then goes on to say that ’you have to be right in front of the computer, facing off with it, trying to figure out how it works and ultimately trying to outsmart it.’.

The problem with that statement is that the reader will infer that by coding, the reader will become a coder, when in fact all they will become is a hack. Not a hacker, but a hack. You know, someone who changes one line, recompiles and sees if that fixes the problem. Change another line, repeat. The end result? A big hack. That’s typically what comes out of those six month coding wonder courses they offer at colleges and universities these days; big hacks. No not all, but most are guys who can hack but can’t program.

I think I’ve covered this topic in a similar fashion before, but I’ll cover it again. Programmers understand how things work at all levels, they plan things out and they see the big picture. Think I’m biased (I took computer science at U of C) or jealous or just plain wrong? Perhaps. But look at it this way. If you took a person and introduced them to use a hammer, a screw driver, a drill, a level and all sorts of other carpenters tools, could you then call him a carpenter? Perhaps. But would you hire him to build your house? Not likely. Why not? Ah ha! Because although that person might be able to hammer in some nails, drill some holes or cut a few boards, they don’t know the first thing about building a house.

In exactly the same way, a person who been taught a few things about programming, either in a quickie college/tech program or by themselves, will never really learn the right way to do the bigger picture stuff. At least not unless they experiment for a long time or have they have proper mentors, in much the same way as the trades system works, where tradespeople start as apprentices and work up from there. The same applies for pretty much all careers I should think (in flying we start as first officers, for example) but for some reason the perceived magic around computers lets people get away with being hacks for longer than they should.

I should end by noting that I really should give Blake the benefit of the doubt and assume he was misquoted but nevertheless the fact exists that the hacks are everywhere and they outnumber the rest of us. That’s why I’m hoping to drop technology altogether and work for Kenn Borek Air within a few years.

Reinvent The Wheel (But Make It Square)

I’m way behind in reading the news in my new favourite tool, Akregator, a RSS feed reader. As I plowed through the list of 400+ unread articles I ran into a brilliant (read: me being sarcastic) article on making your web application more efficient by loading common lists at start-up.

Okay, maybe I shouldn’t be so hard on the author. But then again, the article is 95% code listing and only 5% actual text discussing why you should do this and things to consider when implementing it. Is it just me or does the gist of the article seem pretty much common sense for even the most junior developers? Perhaps I just expect more out of “Lead Developer” and an article labeled as “Intermediate”. And why is it that none of the potential complications are discussed? The author really could have shined had he mentioned that you will run into issues if the list values ever need to change or looked at caching data that is far more expensive to retrieve.

Of course, as I think more about this, I’m not sure which is worse: that the article was written in the first place or that Slashdot included it as a story.

Two Programmers

Every software development company, no matter how small, should have at least two programmers. Or one programmer and a boss of sorts who used to be a coder and has time to review code. Or one programmer and an external mentor of sorts. Or something. And that something better include code reviews. Otherwise, you are liable to end up with developers who write terrible code forever more.

Although I agree that there are some brilliant programmers out there, even those guys get tired now and then. And when you’re tired or distracted, the simple solutions seem to get missed. Hense the need for code reviews. And the problem with the less-brilliant developers is that some of them will continue to make gross errors even after they’ve been coding for many years. So help stop bad coding by implementing good practices like code reviews; for the good of users everywhere.

Sticking with Eclipse

I’ve decided to stick with Eclipse for all Java development, including web applications requiring Tomcat. There’s no turning back now. Well, I guess I could switch back or switch to something different but I think that Eclipse is the best of all things.

Where did the day go?

Given enough time, everyone can be a programmer. Procedural programming is just that, very procedural. Do this, then do that. Then do some more. Programming is simply putting instructions in a logical order to accomplish a task. Not unlike writing down directions to your house.

I can say all this because in third-year of university I was a TA for several Computer Science classes, one of which was a basic computer class, CPSC 201, used by many, many students to help satisfy a science option requirement. And part of that class was writing very simply programs. And, for the most part, everyone was able to overcome the initial “fears” and write basic programs. But that’s why today we have a lots of people developing software in the world that have little or no training whatsoever. Not that there’s anything wrong with that. But that’s a different subject altogether.

Where was I going with this? Oh ya, so I think that of the trained software developers (or engineers if you prefer and aren’t living in Texas) that there are three types of people. There a people who absolutely love developing software, people who love computers and developing is a way to use computers, and people who develop software but honestly have no idea why they are in this field.

For me, I’m in the first group. I love developing software. Once I sit down in front of my laptop, I’m done. The rest of the world no longer exists. And as a result, I often find myself wondering where the day went, becuase it seems like only minutes ago that I had breakfast and now it’s close to seven o’clock and I should start thinking about making some dinner… Right after I finish these last few lines of code.

One page, one Servlet

For the most part, I’ve always been anti-framework. And by framework, I don’t mean EJBs or Servlet engines, I mean fancy “tools” that claim to make things easier. I’m against using such tools for a variety of reasons but for the most part I’m against them due to complexity.

My favourite example is a tool where by you simply describe your DB tables and Java objects and it “magically” takes care of the rest. The problem I’ve always found is that it works perfect for the example application or any other similar application which uses a few “main” tables and some look up tables. But if you start getting more “complicated”, suddenly the framework can’t handle things very well and you end up writing handlers for special cases.

Form validation is another great example of frameworks that handle simple things but no so when it gets messy. No programmer likes to write form validation code. If the user misses a field or puts something incorrectly into a field, the entire form needs to be redisplayed with the user’s input back into all the fields. A few years back there was a framework that could be used to do most of this for you, and I admit, for the simple stuff it was pretty cool. It reduced the amount of simple form validation by 80-95%. But it only worked with forms where some fields were required and others weren’t. So far so good. Except that I needed to have dependencies, where if you filled in field X, you needed to fill in field Y or if you selected radio button A, you couldn’t enter anything in field B.

So now I had an app where the framework was used to validate all form input but in some cases there was also extra validation somewhere else.

So in the end, I tend to advocate the “one [web] page, one servlet” philosophy. It makes it easier to pick up the code and follow what’s going on, it makes it easier to debug and it means less mucking around with things beyond your control. And besides, saving time in the coding stage is really not all that great since the majority of your time is going to be spent debugging and testing and making changes (because the customer changed their mind.