somebody's hungry

... 4 gigs of RAM, less than 2 of them used as per Win XP's Task Manager, still I find myself not being able to open new windows ...

me and my blog

Run my blog through Typealizer and you'll get

Do some research on the personality types and you'll stumble upon these pages http://en.wikipedia.org/wiki/ISTP_(personality_type), http://en.wikipedia.org/wiki/Myers-Briggs_Type_Indicator.

Reflect a bit and you'll see you've learned something new today.

Feel Happy!

have you changed your mind?

If you want to build a reputation, and you're using a blog to help you, then you'd better post things that you have some strong opinions on. You don't want to magnificently build a case over time just to ruin it with one single later post.

If this still happens, you can always blame it on time ... things changed, ... you got smarter.

you're a backend service, forget about the user

The title is an excerpt from my conversation this morning with a class ... no, not any class, you'll find out in a sec.

Her name is LibraryService and has been around for quite some time, and I can tell you she's on no diet. It grew to the point that no sane developer wanted to get in trouble with her, so they just feed her and everybody seems to get along. Just leave her alone, otherwise she might get nasty and do exceptional things that you won't expect.

She sits between the friendly GUI fellows that talk nicely to the user, inform him of errors, handle his mouse clicks, in a word they behave nicely as any counter officer should (some call them handlers) and the backend. So she takes the user's messages from the front-end guys through to the remote backend.

But this morning I discovered a hidden facet of her, let's call it update that does not yell back if she could not deliver the message. And this is most unusual for her, she that is always loud and ... nasty. Instead she bypasses the nice guys in front, picks up the receiver and calls the user directly (pops up a dialog in case you did not get the metaphor). This is wrong because the nice guys in the front will never know what happened with the message, so they might want to retry sending it.

What I've discovered next might be the explanation of her behavior, a new life form called Actions that masqueraded both as a counter guy and as her, fooled both parts, and put himself in-between. This would be fine as long as he helped in translating the messages that go to and fro. But instead he maliciously started to ignore her answers, both the acknowledging and the exceptional ones. He doesn't even do the job by himself, he creates another anonymous life form that has a start facet and delegates all the work to it. So both malicious and lazy, what could be worse?!

I suspect this is the reason she got upset, and started talking directly to the user. Now I'll stop this detective role playing, cause the only thing I feel right now is refactor the hell out of these guys.

boring

Are you through one of those periods when only not-challenging-enough tasks are handed over to you and you're just not learning anything new? ... and the blogs are no good cause you are missing the touch of a printed material?

Here is a piece of advice: think about an advanced programming subject you always wanted to know about, find a good book and read 2-5 pages daily. Just make sure the subject you choose is either part of every good programmer's culture or is related to your current work - you don't want to study something you can't practice.

My current pick is Java Concurrency in Practice.

passion for TODOs

Have you ever left a sticky note on your fridge saying Please remove this note? Have you ever been thirsty and had 10 sips of water thinking that you will have 2 more later? Have you ever written a letter 90%, left it on your desk with the intention of writing See you soon later?

NO, NO, NO.

Then why am I seeing these completely useless, countless TODOs in the code
TODO Add a comment describing the purpose of this file?

Man, why did you even bother to write this down? It is just a 79 line source file, couldn't you figure out what it was about? If you could not, which says something about you, why did you write this line anyway, what's its value? ... Wait, I know, you are using Subversion, you didn't wanna be left behind in the statistics so you had to change some files, any files?!

More serious than all the above, are you aware that writing shitty TODO lines removes your right to whine about the code being dirty? Have you thought about what a programmer is without his/her daily whining? I'll tell you - you'll have to talk only about the arts, ... and literature, ... and history when you meet in the hallway with your team mates - no, not even one complaint from you, you TODO addicted!

Ok now, stop crying, be a good boy, fix that and you'll get your code whining permission back again. ... on 2nd thoughts, fix all the stupid TODOs in the code, you TODO freak!

how do you measure success?

If you google for "debugging swing", my recent blog post shows up on the first Results page. Both google and answers.com ... not yahoo though. Today this is my measure for success.

Allow me for a moment to ignore questions like why this happened for this particular post and how long it's gonna stay there, just let me enjoy it. It made my day, and it's not even noon yet! :)

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.

soap with attachments, axis1 and href

Warning: Read on only if these terms together instantly give you a headache or bring you bad memories.

If you use axis in your project (and indeed it hides nicely the details of constructing SOAP messages and lower level APIs like SAAJ) you probably write code like this to invoke a remote service with attachments:

X_BindingStub service =
(X_BindingStub) new X_ServiceLocator().
getY([<url>]);
service.setUsername(<username>);
service.setPassword(<password>);
MyBusinessObject obj = new MyBusinessObject();
obj.setXXX(...);
service.addAttachment(new DataHandler(...
service.remoteMethod(obj);

But it might be that unless your business object (that Axis will serialize into the BODY part of the SOAP message) will reference the attachment, the remote system will simply ignore the attachment, or worse, your entire message.

This linking is not something the Axis guys invented, just something that they made harder to control. See http://www.w3.org/TR/SOAP-attachments for the different ways to link the SOAP message with the attachment within a MIME message.

...and here is how you could do it with Axis while leveraging the classes that wsdl2java generated:

Service service = new Service();
Call call = (org.apache.axis.client.Call)
service.createCall();
// set call endpoint, username, password

// locate the description of the remote method you want
// to call in X_BindingStub and use it here:
OperationDesc oper =
new org.apache.axis.description.OperationDesc();
oper.setName("remoteMethod");
ParameterDesc param ...
...
call.setOperation(oper);

// locate the remote method you want to call in
// X_BindingStub and use that code fragment here:
call.setUseSOAPAction(true);
...
call.setOperationName(new javax.xml.namespace.QName(...

// create the attachment
AttachmentPart ap = new AttachmentPart(new DataHandler(
"All my worries are gone now", "text/plain"));
String contentIdRef = ap.getContentId();

// construct the XML string that the remote function
// expects (it'd be very easy if you could take this from
// the remote service logs). Link to the attachment by
// setting the href attribute of an XML elem. Note that
// the remote method must expect the href attribute on
// the very XML elem where you place it
String xmlString = "<xxx>...href=\""
+ contentIdRef + "\"...</xxx>";

// call the remote service
call.addAttachmentPart(ap);
call.invoke(new Object[] {new SOAPBodyElement(new
ByteArrayInputStream(xmlString.getBytes("UTF-8")))});

It might be that the same works with axis2, your turn to test and let me know. As for MIME and DIME attachment encodings, both work, just use this extra code for DIME attachments:

call.setProperty(
Call.ATTACHMENT_ENCAPSULATION_FORMAT,
Call.ATTACHMENT_ENCAPSULATION_FORMAT_DIME);

Did it work? No?! You must have done smth wrong ...

works as designed

You definitely heard this one, developers use it as a reason for closing bugs, you even used it yourself. It sounds perfectly natural, at least to me, the developer. I bet testers hate it. 3 simple words to close a bug with.

And now I'm questioning if the construct is correct. How much sense does design make to a tester? And considering that some teams have this open policy where clients can see all the product bugs, how much sense does design make to a client?

To find out the answer, try this: in UAT, go to your client and tell her that the bug she thinks she found is actually the behavior as designed. Don't be surprised if she asks you What design? Now if you are smart you'd shut up and go check the spec that she counter-signed, if you are not-so-smart (read stupid or inexperienced) you'd say: What design?! The UML class design, the interaction and ORM diagrams!
By now the smart reader noticed that the works as designed construct is flawed. If this is the case, then my proof worked as specified.

P.S. If I were the client, I'd only sign contracts that say the software vendor must ship works as intended software.