Listening to JavaCast, a new podcast, I got to hear a bit of a rant by one of the hosts on he hated 30 day licenses like IntelliJ’s and that $500 was way too much of a barrier to entry. Based on my experiences I’d say there’s a bit of truth in the statement even if I think it’s way off base.

I’ve used at least 4 Java IDEs in addition to some text editors during my java programming career. I played around with JBuilder quite a few years ago, but never did much with it because the commercial versions were pretty expensive. After that I worked for a professional services shop that was an Oracle partner, so I used JDeveloper since we were trying to sell customers on the Oracle stack. As Eclipse began to build momentum, I picked it up along with a book since I found the interface pretty horrible to understand without it. When I started my current job the developers mentioned they used IntelliJ IDEA.

I’d of course heard of IntelliJ through it’s many raving fans at JavaRanch, the ServerSide and other sites. They all claimed that it was completely worth the cost, but I had never even tried it out because I didn’t need a new IDE and I couldn’t afford to pay for it.

Given the chance to actually use it, I downloaded it and ordered a license. The first thing I noticed was I was productive right away. I didn’t need to figure out perspectives or the plugin architecture. There was no weird forced directory setup for new projects and the CVS integration worked by turning on a single project setting, no need to even type in a password. The keyboard shortcuts were easy and straightforward. The refactoring features were very nice.

Now I’m not willing to give it up even though we’re in the process of adopting IBM’s toolset. Very much like the Mac OS itself it just works, and better yet it functions intuitively. I admit freely that Eclipse has pretty much the same feature set and certainly more options with all of the plugins available. Still, I won’t go back to it as my full time IDE after being exposed to the productiveness of IntelliJ.

The grain of truth is that a $500 price point did stop me from initially even evaluating it years ago. The difference was as a manager the 30 day trial and $500 price point made no difference, given how productive it was. All of my developers use IntelliJ now, and it has helped many of them as they worked through their first java projects. Many developers on another team use Eclipse and they find it fairly hard to use, since adjusting to things like perspectives can be painful.

So in closing I think IntelliJ is still solid Java IDE choice despite the price.

While XPlanner looked like a good solution for my problem, reality intruded when I got a 2 hour window to play around with it. It requires MySQL and a servlet container (Tomcat). In about 90 minutes on Friday I got it up and running.

Today I tried to setup a sample project or two with iterations, user stories and tasks. All of that seems to work fine. The problem would be that I can’t actually add team members and assign them to a project, a fairly significant problem. I went with blaming it on myself, until I came across a very similar bug. Apparently the fix is that after adding users you sometimes need to restart Tomcat. Unfortunately that didn’t work for me and the bug isn’t listed as resolved.

Next step was to drop back a version and try it. Unfortunately, the same problem, I can’t assign a person to a team. Next try is pulling the snapshot down from the Subversion repository. Or maybe I just fall back to the old excel spreadsheet.

Now that we’re starting to run multiple Scrum projects, I’m finding an excel spreadsheet not quite enough for organizing purposes. I looked at XPlanner and ScrumWiki today. Gave up on ScrumWiki pretty early since it’s Perl CGI based and doesn’t look like its had any active development for over a year. So that left XPlanner.

XPlanner is setup to work with MySQL, though you can use other databases since it implements its persistence layer with Hibernate. Installing MySQL on my work Windows laptop didn’t turn out to be too much of a chore, mostly wizard type install these days. No major hitches with XPlanner which is deployed as a WAR file. A minor item was that the current version of XPlanner isn’t compatible with Java 1.5 since it has the enum keyword in some of its packages. A quick addition of

to the

tags and the problem was solved.

Tomorrow hopefully I’ll get some time to play around with it and figure out if its worth the effort.

One of the common practices in most Agile methodologies is the idea of collocation. Tomorrow, 5 of my developers will move back to their home cubes from another building on our campus complete with machines and chairs.

The scenario was we had a nasty large project that had been in defect resolution for well over a year. There were lots of communication issues resolving defects and both sides had a tendency to throw things over the fence and let issues sit for days. Every time I talked about setting up a war room or bringing the QA testers over to sit with the developers I was essentially told it wasn’t going to happen. So this March I decided I probably had the power to move the developers out to the QA area in another building. While I think they were a little surprised I didn’t get that much flack for it. So 6 developers and myself in the afternoons moved over to sit next to the QA staff.

After a lot of missed deadlines on the project, we finally delivered at the end of July for the first time on schedule. While collocation wasn’t the only factor it was a definite contributor. QA and development finally got on the same page. At least one other project team has been collocated now, so hopefully this will be a continuing trend.

While I like the Fitnesse example built into the wiki, I really can’t get a feel for it until I hook the test fixtures into some of my own code. Stepwise:

1. Download Fitnesse.
2. Launch the run.bat or run.sh script to launch the Fitnesse web server on port 80.
3. On the front page click on Edit.
4. Copy the format for the Fitnesse.SuiteAcceptenceTests on a new line. In this case for Example Acceptence Tests. Click Save.
5. Click on the link for the new page and add the following code:

!path /edgibbs/example_project/build/classes

!|com.edgibbs.fitexample.PersonFixtureTest|
|firstName|checkFirstName?|
|Harry |Harry    |
|Irga | Irga     |
|null | null |

The path setting should point to the area where the classes are built. The firstName will set the firstName property, and the checkFirstName will return a String for the firstName from the fixture class.

1. Run test, it should fail because class won’t exist.
2. Create following class to test an overly simple javabean, Person. Person just has a firstName String property with getters/setters:

package com.edgibbs.fitexample;

import fit.ColumnFixture;

public class PersonFixtureTest extends ColumnFixture {
  private Person person = new Person();
  public String firstName;

  public String checkFirstName() {
    person.setFirstName(this.firstName);
    return person.getFirstName();
  }
}

1. Compile the class.
2. Run the Test again. You should get green rows, yeah! And yes, this example is pretty trivial, but I like to start small.