Archive for February, 2006

Do you know any open-source Java project that deserves unit tests?

I am planning to see if I can do some more work on test automation. I have discovered that I am pretty good at going into existing code bases and adding tests now. In order to practice, and to have something to demonstrate, I would like to find a deserving open source project that I could add some unit tests to.

The design of the project doesn’t have to be good. As a matter of fact, the worse the design, the more point there is in the exercise. Of course, the project should not have any existing unit tests. And it should be in Java. If I feel very masochistic, I will accept an EJB project, but I am not sure I want that much pain.

Does anyone reading my blog have any suggestions to a project that would be worth the look? Post a comment or drop me a line.

Comments

Dell XPS Vanity Lights Blink!

My newest computer is a Dell XPS thing. It’s a huge monster of a laptop (really a gaming laptop, good for the performance). It comes with external LED lights on the top, sides and bottom. These lights are normally only configurable though a custom program. Since I got the PC, I have been dying to find a way to control these LEDs from a script. Finally, today, I found out how.

A post on Notebookforums made med aware of the tool API Monitor, which allows me to see how a program is using the Win32-API. From there, it was easy to recreate a program to do the same. The hardest part was that I decided to try to use the Ruby Win32API interface to call the methods. It was hard to find out how to pass the arguments, and in the end, I ended up with a pure C solution.

The final solution is a command line program, which allows me to script it. I have encapsulated the modification of the LEDs in a simple function for easier reuse.

For any reader with an XPS who would like to replicate it, I have posted the C source code and Executable. These files are licensed under a Creative Commons Attribution2.5 License.

Attachments

Creative Commons License

Update: The previous version of the xps_led_control.exe required cygwin installed on the client PC. I have compiled a new version that presumably should run without cygwin.dll. If you have the chance to test this out, I appreciate positive or negative feedback as to whether it works. Thanks.

Comments

If You Can’t Say Anthing Useful…

Writing my previous post got be thinking about code comments. I have seen a lot of bad comments in my years, and I’d like it to stop! Here are a few examples from the horror cabinet of the world of code comments.

Stating the bloody obvious

Never, ever, say in comments what the code already says. Ever:

class Bar {
  /** gets the foo of the bar */
  public String getFoo() {...}

  /** Calculates the bazzle */
  public int calculateBazzle() {
    // initialize return value to zero
    int returnValue = 0;
    // increment return value by one
    returnValue++;
   ...
  }

This just makes me want to scream. If you can’t say anything useful, say nothing at all!

Oh yeah: The same goes for XML file comments.

IDE generated comments

I wonder how much code is in production with stuff like the following:

/**
 * Class Bar was generated by IDEA on Feb 17th 2006 by
 * jbr.
 * @author jbr
 */
public class Foo {

  /**
   *  Method bazzle comment.
   * @param arg1
   * @param arg2
   * @return
   */
  public Object bar(String arg1, String arg2) { ... }

}

If the author of the comment couldn’t even read it for long enough to see that it was not appropriate – who else will benefit from it? And what good does empty @param and @return Javadoc comments do?!?

The totally dense comment

Writing good comments is really hard. Writing is hard, period. Many comments are too verbose and too hard to understand to actually be of any use, An easy track to fall into when you notice that a comment is hard to understand, is to add more text! This is like trying to extinguish a fire with gasoline.

I wish I could find an example like this, but I’d rather not insult anyone. If you have a comment, that you have written, that is verbose and/or dense: Sense it to me, and I will publish it for public humiliation.

You may laugh at this, but unless you never write comments, you have committed this cardinal sin yourself. Several times. Writing good comments is hard

Conclusion (?)

Good comments makes code much more pleasant to work with. But bad comments are just a waste. I feel like I see almost as much bad comments as good comments these days.

Leave a file as if though you would never have a second chance to fix it. Chances are that you never will come back to it. If you can’t be bothered to fix the IDE-generated comment: Turn it off and delete it. If you can’t be bothered to write something meaningful: Don’t write anything at all.

It seems like a substantial fraction of otherwise sane Java-programmers think that a poor or nonsensical comment is better than no comment at all. This madness has to stop!

Comments

What is the Most Useful Thing You Could be Doing Now?

Recently, there has been a discussion about code comments on the pragmatic programmer mailing list: “Should you comment or not? What should be commented?”

The one point I haven’t seen expressed succinctly is the following: Given a finite amount of time and a codebase with some … issues (which codebase doesn’t have issues?) what is the most useful thing you could do with your time? How often is the answer “comment more”?

Many factors determine the answer: If the code has good test coverage, you can refactor it with impunity. That might be a better way to spend you time. If you’re good at “blind refactoring”, maybe you could restructure the code to bring more under test? Maybe you could improve the test coverage? Given finite amount of time, it is a question of priority.

Comments

Consensus-based Decisions

In the book Software for Your Head, Jim McCarthy introduces The Core Protocols (pdf). Even though the book occasionally give off a new-agey feeling with ritualistic interaction, I think the Protocols have a lot of merit. I especially like “the decider protocol”

As I see it, the Decider protocol is a basic tool for consensus-based decisions. I think consensus as a tools in misunderstood and underutilized. It is easy to assume that basing decisions on consensus is a perfect way of spiraling off into meaningless discussions, but I think this is easily avoided. The thing is: The only thing that consensus means is that no-one feels strongly enough about a decision of the group to oppose it. If the intentions of each member of the group can be revealed quickly enough that one can avoid needless debate when there already is agreement, decisions can be made fairly quickly.

With the Decider protocol, it is all pretty easy: Anyone can veto a decision. This means that everyone will have to stand behind the decision once it has been made. If you cannot stand behind the decision, you will be asked “what will it take to get you in?” (the Resolution protocol).

In my experience, most of the time a comitee is extremely grateful for any well-formed proposal that is presented before it. The Decider protocol rewards making such proposals, while making it safe to protest unsound proposals. The Resolution protocol allows for the proposal to be improved to everyone’s satisfaction.

But if you are member of a consensus-based group – you better pay attention. You have your chance to veto, you have your chance to raise a counter-proposal. Unless you protest a proposal, you will be required to support it after it has been decided.

I have yet to see a full fledged “Decider protocol by email” description. For many groups, I think this could be very effective. A decider protocol for email would have to talk about how to deal with silence, how to set dead-lines for responses, and how to deal with Resolution. Do you have an idea about how to handle this? Leave a comment or send me an email.

Comments

DHH: Secrets behind Rails

David Heinemeier Hansen’¨s talk at OSCon is available at IT Conversations. For those who don’t know, DHH is the man behind the big rising star of 2005: Ruby on Rails.

Favorite quote: “Too many technologies are chasing flexibility as thus it was free. It is not. Your exchanging flexibility for velocity in development, for a delay in changing you mind, and it is really a bad notion! … In other terms, constaints are liberating”

In my own words: Oh yes, and I think there is a special place in hell for those who insist om having their own special organization of source code. ;-) There is a standard (maven 2), stick to it!

No. You are not special.

Comments

Creative Commons Attribution 3.0 Unported
This work is licensed under a Creative Commons Attribution 3.0 Unported.