Chris Johnston

I found this interesting article listing some of the “negatives about moving to an Agile software development process”:http://blogs.sourceallies.com/roller/page/aaron?entry=agile_s_dark_side.

bq. Being a self-proclaimed Agile Advocate I seem to find myself in discussions regard the bad points about agile. Book, articles, and talks on the subject of agile always paint the rosy happy story about using agile. I’m no fool, and I realize that things aren’t quite as happy as some people make it out to be. No one said that agile was a silver bullet. The reason that I’m an advocate for it is because I believe it is simply a better way to write software. Let’s get down to the meat of things. What is the “Dark” side of agile?

I don’t have enough experience with Agile to agree or disagree with any of the points listed, however, I have been thinking about the last one–Loss of Privacy. I have trouble with this point. I listen to Agile people and they push pair programming and team rooms. I then listen to people like Joel Spolsky and Paul Graham who both push the idea that programmers need offices and privacy in order to focus or, stated better, “to get in the zone”. Both views are based on experience so I am not sure which one to go with.

I had someone post a question in the comments section of my last post on Behavior-Driven Development “asking about EJBs”:http://www.fuzzylizard.com/archives/2006/09/15/794/#comments. I thought I would answer it with a new post instead of just a comment. Where do I start?

First, I need to define the term EJBs. For me, EJB means either Session Bean (stateless or statefull) or Message-Driven Bean. It does not mean Entity Bean. Entity Beans are just wrong and will not be considered further. As far as I can tell, no one really uses them (yes, there are exceptions, but those people are just masochists).

What is the state of Session and Message-Driven Beans? Some people use them, others do not. I personally would advise against them. The vast majority of applications are not distributed, run in a single app server, and can be completely implemented in the web container.

The main problem with EJBS is that they are completely untestable. This is a huge problem. There is no way for me to run a simple JUnit test against a session bean from within an IDE such as NetBeans or Eclipse. In order to test an EJB, I need to build and deploy the entire application inside of the application server. I then need to figure out some artificial way of entering into the app server and executing a method or two on a single bean. Not a fun way of doing development.

In order to do any kind of real development with EJBs you need to abstract all of you business logic out of the bean and place it into POJO that the bean then calls. In order to do this, you need to introduce another interface to ensure that the bean and your business POJO stay in sync. Then, you are able to test the POJO instead of the bean. However, now, in order to implement a bean, we need to not only implement the bean interfaces (local and remote), but also our own interface.

So now, not only is the bean aware of its environment, through having to implement the bean interfaces, but it is also aware of the business rules as well because of our own interface that it implements. So even to test a bean’s functionality (which eventually does not exist in the bean anyway) we need to jump through hoops. Ugh.

Basically, my personal feeling, and that of many other people, including Sun is that EJBs (at least EJB 2.x) are fundamentally flawed. Thus they were rewritten for EJB 3.0 and the Java Persistence API (JPA).

If you want an excellent article detailing what is wrong with EJBs then check out Bruce Tate’s “Don’t Make Me Eat the Elephant Again“:http://today.java.net/pub/a/today/2004/06/15/ejb3.html.

This one little statement is something I end up saying over and over again to anyone that I am trying to introduct to Test-Driven Development. It really needs a new name. I like Behaviour-Driven Development. I have seen this name before, most recently in a post by “Keith Ray on his website”:http://homepage.mac.com/keithray/blog/2006/08/12/#TDDisNotAboutTests. I also like his reason for changing the name:

bq. The problem is mental frameworks. People reject ideas that don’t fit into their mental framework. You say “test” and the listener’s mental framework comes up with … assumptions….[However] if instead you say “Behavior Spec”, the listener’s mental framework will have fewer contradictory assumptions.

I think from now on I may start using the term Behaviour-Driven Design instead. I also like this term because it goes well with the idea of designing objects based on their behaviour. The general idea, as I understand it, is to be always asking yourself the question of why a particular object is doing something or why an object contains that behaviour? Anyway, I am not quite sure where I am going with this so just go and read the blog post.

I found this blog posting via the Thoughtworks blog aggregator. The ideas is that “small methods do not necessarily mean good methods”:http://vivekvaid.blogspot.com/2006/09/small-methods-good-code.html. The author then follows this statement up with a list of examples:

* BAD: 1) boolean methods that don’t start with is or are, 2) boolean methods that throw exceptions
* GOOD: boolean isSomethingInThisState() or areTheseValuesGood() shoudl return true or false. For heaven’s sake don’t throw exceptions in these method types. They are named for a specific reason and have convey specific behavior expectations

This evening I was working on TeamDocs and had to make the decision about where to put some validation code. The code in particular is a bit of logic that I use to determine if a directory name is legal or not. In the code, I have a Directory and a DirectoryManager. The DirectoryManager is used to create new Directory objects. In terms of workflow, the new directory name first is sent to the DirectoryManager where it is used to create a new Directory. So, should the validation logic go into the setDirectoryName method in the Directory object or into the createNewDirectory method in the DirectoryManager?

Personally, I can see an argument for both. On one hand, the Directory object should posses the knowledge of what makes a valid directory name. On the other hand, by placing the logic outside of the Directory object, it allows that logic to be more dynamic. I can check if a name is legal based on the OS or some user configuration. In addition, I am not sure if Hibernate allows setter methods to throw exceptions. I will have to look into that.

I think the argument for putting the validation logic into the Directory object is more persuasive given the current trend away from “Anemic Objects”:http://www.martinfowler.com/bliki/AnemicDomainModel.html.

One thing we use at work is a Jabber server–JabberD–to facilitate communication. For the most part, it works great. However, today, I found, via a discussion on Javalobby, what looks to be a much better server and a very nice client. The server is “Wildfire”:http://www.jivesoftware.org/wildfire and the client is “Spark”:http://www.jivesoftware.org/spark, both by “Jive Software”:http://www.jivesoftware.org/.

I have played with the server a little bit and the two nicest things about are that it is open source and it has a really nice web interface for configuration (no more xml config files). The client reminds me a lot of Google’s talk client. Both are very simple and clean in their design.

The only problem is that I just set up a new jabberd server and I am not sure everyone will be willing to switch again, oh well.

For those who have not seen it yet, the “Ruby website”:http://www.ruby-lang.org/en/ has been redesigned and it looks amazing. One very cool link from the main page goes to a tutorial in which you get to “try Ruby in your browser”:http://tryruby.hobix.com/.