debugging swing

... they say debugging code can take more than the writing itself ...

One of the problem I faced when I joined my actual project, with its GUI module having ~2230 java files was finding out which handlers were being invoked in response to a GUI event. Now that I know the project conventions and where the different types of classes go, it's easier, still from time to time I have this difficulty. My team mates have it too, so here is a tip to find out what piece of code is called to handle a particular event:

• set your debugger to step into the JDK classes, for IntelliJ the setting is here File / Settings / Debugger / Stepping.
• to catch mouse events (most common) set your breakpoints in java.awt.Component#processMouseEvent (you'd want to avoid catching MouseEvent.MOUSE_ENTERED and MouseEvent.MOUSE_EXITED)
• when the execution flow reaches your breakpoint, look at the this variable, it will show you the type of the clicked component. Indeed, it won't help finding out that you clicked a JButton, but you can always go up the containment hierarchy until you find a custom component (very often a derived panel XxxMyFeaturePanel) so you'll know what corner of the code base you are in. Do this by evaluating expressions like this.parent.parent.parent
  
• if you want to debug the actual handler being invoked, locate the handler of interest mainly in this.listenerList, this.mouseListener and set a breakpoint in there, most often you'll be interested in an application-specific handler as opposed to a JDK handler
• for components that feature selection (like JTable), the selection listener will be on the table's selection model, so check ((JTable) this).getSelectionModel().listenerList

Here is a screenshot with the above technique: breakpoint in java.awt.Component, the this reference is a StripedJTable that is contained in a ConfigBackupPanel.

If you are interested in debugging deeper through the JDK sources, make sure you get a JDK compiled with debug info, otherwise you won't see valuable info like variable values. You can find instructions here on how to build a rt.jar with debugging info. (The author uses the GNU utilities for Windows to find all java files in the JDK but you can do the same thing with the built-in Windows command dir <path_to_jdk_src_dir>\*.java /b /s). Also you might need to copy rt.jar to a temp location and include it from there in the classpath when compiling.

trashing code

Did you see much software having features removed in newer releases, cause I can't actually name a single one. Imagine the product management board saying Hey, customers are not using this feature, let's trash it.

I am not commenting on their behavior, and for good reasons probably, they prefer other methods of "removing" features. One is hiding them from the user by offering a basic vs an advanced interface, or grouping some features under an Advanced menu item, or offering a More things to do step. This way, what they and the GUI designers are doing is protecting the user from the ever increasing GUI complexity, enable them to do things as fast as possible.

In this context, I suggest that you, yes you, the developer in the cube right behind the R3 pole, start thinking about protecting yourself from the ever growing complexity, which we feel both when reading and writing code. A good way to do this is fight back: start controlling the size of the code base.

That being said, this morning I am particularly happy because I see my project fellows throwing away code: today it was a draw, 3 classes added, 3 removed.


Before starting to read IT literature, I thought I was weird feeling this way about throwing away code. But I see there are a lot others feeling the same thing, and they can express the idea much better than me.

So start feeling happy when code gets deleted, it is a sign of healthy code while more features are added to the product.

SLOC can be good for your morale (II)

Here is the theory, below is the result: my last refactoring as seen through the eyes of SourceMonitor:

windows to the rescue

For the record, I took the screenshot yesterday, 2008! No comment ...

SLOC can be good for your morale

While Wikipedia tells you there are 2 advantages and so many as 9 disadvantages for using the SLOC metric in software programming, I'll tell you yet another advantage.

Start by thinking about TDD and the psychological reason why TDD is good: it shows you red turning to green, effectively rewarding you for the done job.

Now I've stepped into a project with such a scrambled source code that I find myself constantly refactoring while doing other tasks. Sometimes the refactoring gets bigger and turns into a standalone job and this is the case when I'd love to see a line like this one on my display after I'm done: Great job, you maintained all the functionality, all tests pass, the code base is smaller and easier to understand!

Ok, I'm giving the tools too much credit ... I'll run the tests myself and ensure the functionality is preserved. But hey, what about the code base is smaller and is easier to understand! To a big extent I think the shorter the better, and to skip the debate let's take the proof to the extreme, just go through the C - Cobol code comparison here and see which one is easier to grasp. You're right, the shorter one.

This means you can measure (part of) the success of a (big) refactoring with a metric derived from SLOC, along the lines of effective SLOC, this as long as the tool that computes this metric for you is smart enough to yield the same results for:

i++;

and

i = i + 1;

and

void m() {
 date = new Date();
}

and

void m() {
 n();
}
void n() {
 date = new Date();
}

P.S. Guess what, I've edited the post and made it shorter ;)

hiring

If you say to me How are you? these days and don't expect a useless, no-substance Western answer like Not so bad, I'll reply back with Good, hiring.

And it is the HOW I am doing it that matters this time. I am putting extra effort to eliminate phonies in interviews, those that sound brilliant and don't do the job, so you'll get a hands-on test at the end of the 2h interview which is structured like this:

- discussion on recent projects and professional experience
- questions from various subjects like algorithms, data structures, technologies, software development
- hands-on test

I am only looking for 2 engineers, so hiring one not good for the job will mean 50% failure. Fingers-crossed.

XML and aliens

[...] If SETI@home works, for example, we'll need libraries for communicating with aliens. Unless of course they are sufficiently advanced that they already communicate in XML. [...] - Paul Graham

Man, this line is so good, I had to reproduce it here and post yet again a link to Paul Graham's essays so that other know-it-all programmers can read them and realize they know next-to-nothing.

Humble me.