Skip navigation
1 2 3 Previous Next


36 posts
How much code documentation is a symptom of bad coding (i.e. poor method or variables names, poor class or package structure, missing logging, etc)?  

What are the cost vs. benefits of creating interfaces and how should they be balanced? I am only considering cases where interfaces are optional and aren

Is it more secure to allow the browser to save a website password or prohibit the browser from saving the password?
    Benefits of allow the browser to save the password:
  1. Spoof websites are more easily detected because the username and password don't show up (this may be a mute point if the username is saved but not the password).
  2. Keyloggers won't pick up the password if you don't type it. (Thanks to Thrawn)
  3. People will be less likely to keep the password in an obvious place (i.e. sticky note)
    Benefits of prohibiting the browser from saving the password:
  1. Stops someone with access to your computer from accessing the passwords (the level of access needed can vary based on how the passwords are stored).
What should be in a source control commit message for a single file add?
  1. Reason: The reason for the file should be in a comment in a file so it would be a duplicate to also include in the commit message.
  2. File add: Already part of the commit
  3. Issue identifier
Could java.util.concurrent.lock.Lock use a static list of all threads that have locks and ThreadLocal locks lists to know about all in use locks and then check for incorrect order when lock() is called. Consider: In lock: Check the ThreadLocal list and if there are no other locks then proceed. Else if there are other locks then look through other threads to determine if any have any of the same locks in a different order. Add current lock to ThreadLocal list. In unlock: Remove current lock from ThreadLocal list.  

Do a "requirements document" and "design document" use an outdated format? Is one monolithic document the right way to handle that information? Are there better ways to handle that information?

Consider this idea:

  • Keep requirements/design info in a tree structure.
  • Support viewing the whole tree to a specific depth so that people can ignore undesired detail.
  • Allow ownership to be set by branch.

Are there products/techniques currently available that handle this better?

When interviewing candidates (only 3-4 interviews) I would ask them the following question: What kind of programming work do you like best? They always gave then same basic answer: Creating new software. Since that isn't the answer that I would give I asked my co-workers and between 4 of us we had 3 different answers: 
  1. Creating something new
  2. Debugging problems
  3. Improving (adding features, improving performance, etc).
Would you give one of those answers? Do you have a different answer?  
I had a URL that I wanted to POST with JavaScript so a made a 
        <form name="doForm" action="" method="post">
and used JavaScript to set action and callsubmit. But Tomcat showed the request as a GET (I.E. 7 is my browser). I found that adding a dummy form input fixed the problem: 
        <form name="doForm" action="" method="post">
            <input type="hidden" name="blah" value="blah"/><!-- need at least 1 input or the form uses method="get" even when "post" is specified. -->
On a real-life desktop I will often move toward an object to work with it. i.e. When I want to look at the calendar I will move closer to it. That allows better use of my desktop because some objects are "zoomed out" and therefore take less space (in my field of view). I received an iPod Touch for Christmas and the zooming of web pages and pictures works well. Of course adding a touch screen to a normal computer would help zooming work better. Has anyone ever tried to incorporate a similar idea into a GUI? Icons, minimize/maximize, and resizing are somewhat like that but not quite enough. It would be nice to resize something to a "zoomed out size". i.e. I could set a size for my email program when it isn't in use and it would be shrunk to fit in that space when desired. That would allow me to "watch" the output of windows without it being large enough to read it.  
How much paper would be saved each year it Microsoft changed the default margins in Word to 1" on each side (or even 1/2")? Remember that when you choose your program defaults.  
Normally I see abstract classes named asAbstractClass. But when there are many abstract classes that requires typing at least AbstractCwhen using code completion. Therefore I suggest that abstract classes be named ClassAbstract so that code completion is more usable. "Abstract" is a modifier on the class name anyway and it doesn't need to be in the primary position. What do you think? I know this isn't a huge deal -- I am just suggesting it as a minor improvement.
Does widening or autoboxing happen first? Which parammethod will be called from the autoboxing method? If one param method is commented out then it will have no problem calling the other. 
private static void autoboxing() {
    Integer integer = new Integer(2);

private static void param(int param) {
    System.out.println("param(int " + param + ")");

private static void param(Object param) {
    System.out.println("param(Object " + param + ")");
I wish I had a terminal program that distinguished (i.e. with different colors) standard output, standard error, standard input, command input, and the command prompt. It would be obvious when I wrote a command that is waiting for user input so that I don't wait for my program to finish when it is waiting for me to enter input (this usually happens with shell scripting when I forget to provide the standard input to a long list of piped commands). Does such a program exist? Do you think it would be beneficial?  

Telecommuting tips Blog

Posted by staufferjames Dec 17, 2007
I have been telecommuting 1-2 days/week for a few years so I present the following tips to those who want to telecommute: 
  1. Practice communicating by email (especially when it is easier to talk in person about something) so you get better at writing emails that are complete and easy to understand.
  2. Practice doing as many normal activities on your telecommuting days as possible. Minimize "waiting until you get back to the office".
  3. Practice minimizing differences between your telecommuting and in-office days so that your telecommuting doesn't negatively affect the company.
For me #1 was the hardest to learn. 

BTW why do there seem to be more full-time telecommuting positions in .NET than Java? (Or maybe you disagree...)


Connection Haiku Blog

Posted by staufferjames Dec 17, 2007
One connection good. Then two connections better. Or maybe not so.Technorati Profile