Matias Tactile Pro

The Matias TactilePro page says boldy:

Built like a tank.
The Tactile Pro Keyboard is built to last, and comes with a 5 year warranty.

I'm not sure any keyboard I've ever owned has died within five years. Generally, keyboard are trouble-free, as long as you ignore all the crud that gets trapped in them, especially if you have animals that shed. If you really want to be seen as standing behind your product, you'd have to do a lot better than that to impress me.

Maven Makes Developers Feel Stupid

Although Maven has its benefits, its documentation is often spartan and scattered, and sometimes it can be quite painful to figure out how to accomplish a task, although once you've figured out how to do it, it's usually not terrifically hard to repeat it in the future.

A recent post to the Maven list just classically typifies this, for me: "How to use EAR plugin? Am I stupid?" Yes, sometimes Maven makes you feel stupid. I'm inclined to believe that's often Maven's fault, not the developer's.

Matching JAXB Dates in Tests

If you find yourself wanting to correctly generate the date format used by JAXB, most likely in test code, you might find yourself messing with an XMLGregorianCalendar doing something like this:

        GregorianCalendar gregorian = new GregorianCalendar();
        gregorian.setTime( date );
        XMLGregorianCalendar xml = DatatypeFactory.newInstance().newXMLGregorianCalendar( gregorian );
        return xml.toXMLFormat();

If you do, you're likely to get bitten by the fact that on dates with 0 milliseconds, your method will include the milliseconds and the JAXB output will not:

expected:<2008-07-16T15:15:51[]-04:00> but was:<2008-07-16T15:15:51[.000]-04:00>

As a result, you'll want to employ code more like this:

        GregorianCalendar gregorian = new GregorianCalendar();
        gregorian.setTime( date );
        return DatatypeConverter.printDateTime( gregorian );

Et voila.

JBoss Effect and Hibernate Session.connection()

Sometimes it seems as if there's a JBoss effect wherein developers, once they've become a part of JBoss, become somewhat arrogant and rude in dealing with some members of their community. At first, I thought this might be the Marc Fleury effect, but he's gone, and JBoss seems to still have the same effect at times.

Case in point is the recent deprecation of Session.connection() in Hibernate and the tone of the responses here (Google cache version if Atlassian's still doing maintenance) and here.

Now, granted, the method is deprecated, and the deprecation comment implies that it will be replaced in the future with new methods. That said, the comment neither talks about the dangers of using connection() nor talks about alternative approaches that could be taken, both of which are common in deprecation Javadoc, and both of which would likely have reduced the volume of questions they were going to field.

And, frankly, if the best you can do to "help" the community is to respond with brusque, unfriendly comments about said member's ability to read and/or interpret the rather spartan documentation on this point, perhaps you should just stick to coding, instead of "helping"?

I will point out that another thread, About 3.2.4 and Deprecated function, generally stayed in the informative and polite zone, mostly due to max. Thanks, max, it's nice to see. So if you want to know why Hibernate 3.2.4 is deprecating Session.connection(), read that thread instead.

TweetDeck vs. Spaz

I've spent part of the day witih TweetDeck after weeks with Spaz, and have come away with some comparative notes.

Spaz

• Simple tabbed single-column layout.
  
• Works well with the keyboard, allows you to scroll up and down, lightly greys items you've previously looked at.
• Scrolls pretty smoothly.

TweetDeck

• Single or multi-column layout.
• Multi-column layout looks a little lame when most of the columns are empty.
• It's nice to be able to separate replies from the rest of your incoming messages.
• The ability to group people or have a few searches up at once seems handy, although I didn't use either, and I'm not sure how often I would.
• Feels jumpy when scrolling, easy to lose your place.
• Not well-suited to keyboard scrolling and difficult to know which items you've already read.

Basically, these are both reasonable clients with different strengths; if you need to organize your tweets, I imagine TweetDeck is your choice.  If Spaz' simple layout will work for you, I find it a little more usable right now.

I've also played briefly with twhirl, but so briefly that I don't really feel qualified to comment.  I found the skin to be more noisy and cluttered, so I quickly went back to Spaz.

Command-Line Parsing Libraries for Java

I've recently had the need to do some command-line argument parsing in Java, and so I took the opportunity to quickly evaluate some of the command-line parsing libraries that are available for Java.  After looking briefly, the following options seemed to be relatively well-known:

• args4j
• JewelCLI
• jArgs
• Commons CLI

args4j
Of the options, I spent the most time with args4j; it seemed to be relatively modern, it was available in a Maven repository, it was written at least in part by Kohsuke Kawaguchi, whose Hudson project seems to have turned a lot of heads.

Most java.net projects have pretty weak websites and documentation, I've noticed.  The args4j project is no exception.  It has a sample page, a blog post and some javadoc, and if you piece all three of those together, you'll basically have enough information to get started, after which you'll occasionally have to dive into the code.

I was able to make this work for me, but it lacks most of the bells and whistles that I had hoped adopting a third-party library designed for this purpose would provide.  Args4j will not easily:

• Limit the number of arguments
• Restrict arguments to matching arbitrary rules like regexp pattern-matching
• Display great help for the available options (it has usage, but it seems to leave out information like whether or not an option is required)

Although I haven't dug through the source code in detail, it doesn't look to me like there's a very complete suite of tests.  That doesn't matter if the code is solid and the documentation's good, but with the gaps in the documentation, some tests would have helped to make things a little easier to understand.

JewelCLI
JewelCLI has a pretty spartan (Maven-built) site, but seems to have good functionality and clear, if simple, documentation by example.  As far as I can tell, it isn't available in any Maven repositories, which is too bad because it seems to be built with Maven and, at first glance, I'd say it looks slightly more capable than args4j, and it seems to have a full test suite, although it doesn't look like anything's changed much recently.

It's another anotation-based implementation.  It uses an interface instead of a class, which has pros and cons.  It's vaguely fun because it allows them to implement some simple things under the hood like interrogatory methods for optional parameters.  That said, args4j's class approach gives you the flexibility of putting the behavior inside the same class as the data, if you choose to accept that option.

jArgs
jArgs seemed like it might be reasonable, but the last release was in 2005, the site is sometimes unresponsive, preventing you from looking into it in more detail, the implementation seems like more work to set up - programmatic configuration instead of class-based or interface-based reflection/generation.  Ultimately, if I can't get to the project consistently, I tend to take that as an omen.

Commons CLI
Apparently the oldest of the options here, and doesn't get a lot of respect from commenters, so I didn't really look at this very closely..

In Summary
I ended up using Args4j for now, but I think I'd use Jewel CLI next time, and if it works out as well as it seems at a distance, probably stick with that. 

This is also a good time to point out that Java's console programming model is pretty limited.  Key bindings?  Clear screen?  Move around?  Nope, sorry.  There seem to be third-party tools to get you there, but the core console functionality is basically suited to log output and the occasional thin piece of input.

Taylor Gautier looked into some of the before, if you're looking for further comparisons.

Disabling Menu Items: Gruber/Spolsky

Joel Spolsky takes a stand against disabling menu items, arguing:

Users see the disabled menu item that they want to click on, and are left entirely without a clue of what they are supposed to do to get the menu item to work. Instead, leave the menu item enabled. If there's some reason you can't complete the action, the menu item can display a message telling the user why.

John Gruber returns fire with the pro-disabling-menu-items argument:

This is why Spolsky is a Windows developer, not a Mac developer. Disabling menu items when they can’t be used is a fine practice — it means that the visual state of a menu item reflects the actual state of the command it represents. ... Spolsky’s suggestion — that you leave all menu items enabled all the time and show an alert when they’re chosen but can’t be used — would be irritating as hell every time you ran into it.

Spolsky’s suggestion is also predicated on the assumption that the user is stupid. Better is to assume that the user is clever and curious and will be able to figure out for themself why a certain command is currently disabled.

As with most polar arguments, this is a false dichotomy: there aren't simply two choices here. Yes, it can be confusing to see menu items disabled and not know why. Yes, it can be irritating to see menu-items enabled even when they can't work, such that triggering one will result in a warning dialog. But there may be ways to solve both problems. For instance, what about disabling menu items but allowing those disabled menu items a way of communicating the reason for which they're disabled where a confused user an learn more. We can assume the user is clever and curious without forcing them to dig through help and experiment to answer the question. For instance, some kind of a tool-tip on a disabled menu item could probably be done. It sounds vaguely ugly, but there's probably some way to make that work. On a windows window, where you're pretty much guaranteed to have a status bar, the message could easily be displayed there. On a Mac, where you might have a menu and no window at all, something like a tooltip seems like your only available choice.