computer

The other day, I had a short conversation with the consultant:

She: "Steven, do you think we should provide this feature?"

I: "Yes, absolutely. So can you update your use case specs so that I can start working on it?"

She: "OMG, is there such a need? I'm kind of busy right now, can you start first and I will update once I got free up a bit"

I: "No, I won't do anything more than what is specified, and I'm just trying to make your specs more important"

She: "OK then"

Maintain your specs whenever required, otherwise you're just writing specs for nobody.

I got a bug reported saying the system kept on giving "delete failed" message even though the record had actually been deleted. Therefore I look into the code and found this:

deleted = SomeManager.delete(id);
if (!deleted) msg = "Failed to delete record";

It looks OK to me at the first sight, but after went into the delete() method, I felt like killing the one who wrote the code of SomeManager.

public boolean delete(String id) {
  // ... code to establish db connection
  PreparedStatement ps = ...
  boolean deleted = ps.execute();
  return deleted;
}

According to the documentation of PreparedStatement.execute:

Executes the SQL statement in this PreparedStatement object, which may be any kind of SQL statement. Some prepared statements return multiple results; the execute method handles these complex statements as well as the simpler form of statements handled by the methods executeQuery and executeUpdate.

The execute method returns a boolean to indicate the form of the first result. You must call either the method getResultSet or getUpdateCount to retrieve the result; you must call getMoreResults to move to any subsequent result(s).

Returns:
true if the first result is a ResultSet object; false if the first result is an update count or there is no result

It tells me obviously that the programmer didn't read the doc at all and was assuming the operation fails if he gets a false.

During a dinner session about two weeks ago, I and another two friends had a little debate on the Java IDE, let's call them E and K accordingly:

K: "IntelliJ is the most efficient one, you can literally complete most tasks without using a mouse"

Me: "In Netbeans, you can configure as many shortcuts as you want too"

E: "JBuilder is also darn good, I'm still using JBuilder X now"

Me: "Netbeans is free and almost every features are plug-ins, you can customize the IDE based on your needs. And bla-bla-bla..."

E: "Hey how much they paid you to promote Netbeans?"

This morning, E messaged me via MSN saying "Hey you know what, I find the latest version of Netbeans is better than JBuilder, check it out!". At that moment, I totally had no idea what to reply. Don't get me wrong, of course Netbeans is (still) far from the best, my whole point has already been stated at the post's title.

Evaluating a few UML modeling tools for the past few days has forced myself to learn XMI (XML Metadata Interchange) and it allows me to share my UML diagrams among design tools. Fortunately, the sharing process is almost seamless, presumably you draw your diagrams with standard UML notations.

Imagine you're damn tired but you really would like to give valuable comment to your friend. After typing few lines of text, you still have to deal with those hard-to-recognize characters. How would you feel?
Despite the fact that I understand why the word for verification must be displayed as an image, I'm yet trying to figure out why the characters must be hard to recognize. Perhaps you could give me an answer.

As the author of the blog, I think I'm the one who should be responsible for getting rid of spam comments, not the readers. What do you think?

Java programmer should already know that Java natively support Unicode, it means that we can put comment in generally any languages. It might not be very useful, but it's at least good for those (like me) who is not very good in english (yet).

Although you're a genius, you aren't going to master any development frameworks without learning the basics. Unlike biology or chemistry, development frameworks are literally created by, developers. Therefore, without reading the material produced by those creators or those who is already the expert in the subjects, you probably wouldn't know how those developers want you to use their tools. For example, I was asked for several times why weren't the initial form values (using Struts) being populated onto the output HTML and eventually found out that their Form classes don't extend ActionForm. It concluded that they blindly copied everything and missed out the declaration of the FormBean.

It's just too many similar examples.

Perhaps most of them think that it's just a framework and it isn't going to last long anyway. They might be right, but the way they learn to use the frameworks is wrong, or more politely, improper. When I have to use a framework which I never use before, the first thing I do is go to the homepage (I'm sure every framework now has a homepage), read the introduction, concept and the guide for beginner (I even like to read about the history). If I find it enough for me to start, I would follow some samples and write code from scratch for the sake of trying it out. If the document available on the website isn't enough for me, I would buy a book, that's why I own a copy of "Spring in Action". Ridiculously if I still couldn't start conding on the framework by then, I will definitely encourage everyone in the team for picking up a better one.
Not yet end of the story. Before we learn the basics of any frameworks, we should first learn the basics of J2EE or even the basics of Java. Too many Struts developers don't realize that they are actually running one single servlet, ActionServlet. If you don't at least know what is servlet, how are you going to debug the weird behaviors caused by the ActionServlet? If you don't know JNDI lookup, how are you going to solve the problem when Spring fails to inject the resource as expected? If you don't know reflection, what should you do if Spring doesn't include your method into the transaction aspect? If you don't know JSP include, how would you know if your tag library is correctly included?

Ever since the new technical director has joined the company, UML design become the compulsary milestone for those projects which are bigger than certain size. He was working at Rational Software before the company acquired by IBM and now, he's working remotely from US and occasionally in our KL office. I'm glad that we have such practice advocated by a top player like him, otherwise no one will actually spend efforts on UML design. He did teach us on every single type of UML diagram and I believe every employee (the attendance of the UML workshop was compulsary) has already get familiar with most of the notations. It short, we all now can interpret most UML diagrams.
But, one of the project manager asked me the other day "Does class diagram really helps our development? If it doesn't, I'm OK if you want to skip it"
Of course I wouldn't want to skip it, if I do this time, I know I'm going to skip it forever.
Fortunately I finally managed to convince her that having UML diagrams could literally shorten the development time and we're not drawing out the diagrams for the sake of showing it to people.
Usually, before I write the first line of code, I design the class in my mind, I just don't draw it out. It's not that I like to do design so much, it is because I couldn't start any coding without having a rough picture of all the objects I can think of. Therefore, by drawing it out, I'm actually forcing myself to think of the objects (and the relationships of them) a lot further. Besides that, diagrams help bringing our design to a more consistent level, though conflicting is still avoidable.
Perhaps our technical director would still have to work harder on pushing UML design because while it's hard to tell people how to do certain things, justify to people for doing certain things is a lot more harder.