Wednesday, December 04, 2002


Together/J.

It's old news at this point that Borland has acquired TogetherSoft.  I wonder what this will mean for the future of TJ.  I've been a TJ user since V2; I bought it as of V3, and I've kept maintenance up on it ever since.  I got a pretty good deal back then -- it only cost me $1800 to buy when I did.  It's been worth every penny.

Refactoring has become very popular lately -- true support for it in IDEs, that is.  With TJ's transformation capabilities (simultaneous round-trip engineering) I've had the equivalent for a very long time.  TJ has improved its refactoring capabilities in the most recent releases, adding features like "Extract Operation" and so forth.

There's a lot done right, and some things done wrong.  The GUI builder part of TJ is very slow and primitive; it's so slow that I consider it to be unusable.  Take that with a grain of salt, though -- I work on a creaking old 600Mhz laptop, and I need to upgrade sometime soon (but I don't, because I love the 1400x1050 display.  It's the perfect size). 

TJ also displays a big tree with everything in your project, which is just dumb.  What am I supposed to do, go hunt around in the tree for the methods that are in my current file?  I hate trees!

I like JBuilder, but I can't stand Borland's upgrade policies.  As an Enterprise user, they hit me up for 70% maintenance per year.  Yes, it's worth it in terms of value provided.  But!  You need to look at it in terms of value differential from the other products that are available.  NetBeans is free, and provides great functionality.  Eclipse just gets better and better too.  And IntelliJ gives JBuilder a good run for its money.

I don't use JBuilder much any more.  I use NetBeans for debugging and TJ for modeling.  NetBeans is a little clunky in places, but I just don't see spending piles more cash on JBuilder.

Of course, upgrading my TJ is probably going to cost me 70% a year from now on.  That sucks.


8:17:36 PM    

More on Testing.

I've tried creating a series of fine-grained tests this evening, as I worked through a new association library.  I didn't do it quite the way that Kent Beck wants me to; I was creating a fair amount of the structure of the system first.  For me that's a thinking process -- I really don't know the shape of the whole thing until I've meandered around the problem for a while.  I just don't see the point of writing too many tests early.  Yes, I know it's nice not to have to write them all at once (because that means there are tests that aren't going to get written), but the complexity just seems to preclude it. 

When I did start writing the tests, I found that I definitely like the style of writing a test for what I expected and wanted, rather than what the code being supported actually did.  I found some problems with my API that way, and refactored that before continuing with the test coding.

I also discovered that my testing routines could be very fine-grained.  Each line of code could check for desired results and fail if necessary.  It's unfortunate and annoying that I need to come up with so many failure messages.  It would be really nice if there was some way that a message could be auto-generated.  The message doesn't need to be particularly clear; I just need to be able to identify where it came from so I can do my fix.

Tests need to be debugged, too.  If running tests is the primary way of developing code then the act of running the test needs to be under the debugger...this tightens the loop considerably.  It took a little tweaking to get TJ to do this right.  It's something that should be a default option.


12:29:21 AM