ejb 3

After ranting about Xml and j2ee development pain, I have to agree that ejb3 is really awesome. I was able to develop an entity and session bean without any deployment descriptor apart from persistence.xml file. Its really cool to see power of annotations in practice. Having a reflection of field experience really helps any framework to be more developer friendly.

xml bites again

Have you seen anybody who actually like doing j2ee/xml work?

I haven't and just because 90% of java work is j2ee stuff they are tied to it in spite of the dislike. If you have noko niko calendar of your team all you will see is :( . Apparently it took 1 day for me to integrate one external ejb with our module. I don't consider myself a j2ee expert but honestly how good are collection of xml configurations when every time you change something you have to redeploy. All I want is to compile and run my tests, is it too much to ask? . If you have a big project like us then you are screwed because every XML change requires jaring, redeploy and restart of your application. Its quite a big cycle when you have no compiler watching for your deployment descriptor errors. I am not sure whether Websphere application developer or Weblogic workshop have any sophisticated logic to validate your DD's before even deploying it.
Anyways do we really need all these descriptors to deploy some manage beans? Introspection and clever defaults could solve all the problem and it doesn't need a CS degree to figure that out, maybe some practical experience.
Honestly have anyone used any 3rd party ejb components or followed all the j2ee roles? If Java at all wants to make a component market a reality make it easy for developers.

Fluent Interface

Like most other projects out there we are using fit/fitnesse to write our acceptance tests. But to be honest I am not very big fan of fitnesse. It doesn't scale very well with project size and having fixture tables through out fitnesse pages doesn't help readability and maintainability.

Especially if you are building web application you leave the UI part out of the test unless you integrate your UI test tool like selenium with fitnesse but you still miss the readability for tabular test structures. When we get story in BDD(Behaviour driven development) format and acceptance criteria in Given-Then-When style I expect to see my test in following pattern.

"Given products exists when I search product by name then user expect to see all matching products" do

test "goto product page and search for product code '100'
now number of matching products found is '10' "

end

Doing something like this Ruby is possible and in fact Dust is doing something very similar. But achieving something like this in Java is a challenge. Fluent Interface is one of the easiest way to do achieve DSL like look in Java and its quite easy to implement too. Lets consider the following selenium unit test

public void testGivenProductsExistsWhenISearchProductByNameThenUserExpectToSeeAllMatchingProducts() {

goToProductPage().andSearchForProductCode("100);
assertThat(now().numberOfMatchingProductsFoundIs("10"));
}


Its not cool as ruby DSL's but its close and quite readable. Some of our test now looks like this and rest of the team loves it.