Speakers and Talks

Sébastien Stormacq

.

I’ll be there!

More information at http://www.brussels-jug.be/wiki/doku.php?id=events:2010_09_session1

One of the “problems” of doing all the business logic in the Service (or UseCase, Business) Layer is getting the right exception message back onto the screen. Lot’s of times people invent all kinds of home-brewed exceptions: e.g. ResultNotFoundException, InsufficientFundsException, DateTooFarIntoFutureException, …
Another approach, which is far worse, is to let specialized exceptions like a ConstraintViolation (hibernate), UserException (axis) and many others. It couples the front-end to back end.

When defining custom exceptions for every problem, you force the controller to catch all the exceptions that could be thrown separately. Adding a new exception can be cumbersome, and it does not really matter if you define them as checked or unchecked, unless you plan to catch the remaining exceptions with a generic info message like: something went wrong…

What’s the correct solution?

Here comes the BusinessException

public class BusinessException
    extends RuntimeException {
	/** A code indicating the cause of
            the exception. */
	private String code;
	/** The exception that is wrapped by
            the business component. */
	private Exception wrappedException;
	/**
	 * Constructor.
	 *
	 * @param code The code indicating the
         * cause of the exception.
	 * @param wrappedException The exception
         * that is wrapped by the business
         * component.
	 */
	public BusinessException(String code,
          Exception wrappedException) {
		this.code = code;
		this.wrappedException =
                  wrappedException;
	}
	public String getCode() {
		return code;
	}
	public void setCode(String code) {
		this.code = code;
	}
	public Exception getWrappedException() {
		return wrappedException;
	}
	public void setWrappedException(
           Exception wrappedException) {
		this.wrappedException = wrappedException;
	}
}

When a business rule validation has been detected, a new BusinessException should be throw.

When an exception is thrown from any layer beneath the Controller layer, it should be wrapped by the BusinessException.

The code is the key for translation by the view renderer.

Placing this in the architecture

When we place the BusinessException into a widely use architectural stack we come up with something like this:

Advantages

The advantages are clear:

• The controller and other layers are loosely coupled (e.g. no DAO dependency in Controller)
• The transaction can be rolled back, since the exception is thrown.
• The controllers aren’t forced to catch many exceptions.
• No need for those custom made exceptions. One exception to rule them all!

BusinessException versus other exceptions

The businessException should wrap a recoverable violation or exception, that can be displayed in the screen. Transaction is rolled back, and the user can change the input and/or try again.

Normal exceptions are unrecoverable. The transaction is rolled back, and the user is directed to an error page.

It’s not the point to wrap every exception, but only the expected ones. Don’t wrap a It’s a really simple pattern, but a very powerful one.

In essence 4 scenario’s can happen:

1. The first level fails. Typically this is something like a missing required field. The user is redirected to the same page to fix the problem.
2. The second validation fails: a business exception is thrown.  Typically this is a business rule that failed, for instance a balance is too low to complete a purchase. It also could be an exception wrapped by the BusinessException. For instance when the database row has changed after you loaded it.
3. Everything succeeded, the business layer returned normally.
4. The business layer threw an exception (not a BusinessException), the page is redirected to the error page. Unrecoverable, should only be on programming bug.

Conclusion

A lot has to be said for straight and simple win-win patterns. This one is definately one of those.

• Enables loose coupling between interacting classes
• Makes it easier to test
• Allows us to easily switch between implementations.

Lately, I’ve been openly questioning if we should always use interfaces. Are they always required by default and is the extra cost of keeping the interface and the implementation in sync worth the trouble? Lets discuss.

When we are using dependency injection, the coupling between one class and another is very low. It’s of course true that by injecting implementation instead of interfaces we are making the coupling a little tighter. The classes are still in isolation, since neither creates a new instance. This is still done by the DI container, which deals with instantiation and configuration.

Is a class that only has interfaces as dependencies easier to test then classes that have implementations as dependencies? Most of us are eager to say yes, but in fact, frameworks like EasyMock enable us to mock (non final) classes. We can add behavior just like any other interface.

When writing an application, it’s very rare to change the implementation of an interface. Almost all my interfaces have exactly one implementation. Sometimes this is not the case naturally, but I find it pretty easy to spot those implementation that might or will change in the near foreseeable future.

If we should reduce the amount of interfaces in our code, the advantages could be:

• Less classes which (should) equal to less configuration and maintenance
• Less synchronization during development so results in a little faster velocity

Anyway, this is purely speculative.

Let me state that I’m not thinking about actually dumping the interfaces. It’s a proven practice, but I’m think out loud and for myself. What I’m looking for is an insight or story that will convince me either way. So if you have any, I’m more then eager the hear!

Andries

Shorten the build cycle for developers

The length of the build-cycle is critical for developers.

Exploded development

With the release of JBoss Tools for eclipse, I finally managed to get a very good exploded development going on. I tested the beta 3 as well as the beta 4. In both cases, exploded wars didn’t function as I wanted. Didn’t remember quite what didn’t work, but with the the GA release, everything worked out fine.

The main benefit of exploded development is the powerful option to edit JSP files live! This is a serious advantage. Our team started out without this, but as the project exploded in size, the start-up time was increasing drastically. Would not ever want to do another project without this ability!

Another great benefit is the possibility for incremental publishing (standard behavior with the plug-in). Packing a war is something that can take half a minute or longer using eclipse, with incremental publishing only the changed files are submitted, resulting in mere seconds.

The last benefit is a faster start-up, since the server doesn’t have to unpack the war. Our war is about 45Mb large, which took 10-15 seconds to unpack.

There is one setback! When using this, there is a bug when you have breakpoints in eclipse. The breakpoints sometimes (and this is rather frequent, say 1 in 5) cause the server to start up really slow. And slow is like 1h to start… The workaround here is to restart the server and disable the breakpoints on start-up, enabling them once the server is started. It’s a common bug when you Google for it, so I’m confident this will get resolved soon.

Hot-code replacement

Learning how to use hot-code replacement can save some restarts of the server. With hot code replacement, you can alter any Java code, as long as you stay within the method where your breakpoint currently hangs. This is perfect for adjusting 1 line of code, since most bugs are exactly one small thing that was wrong.

There is a little more to it. Sometimes eclipse complains about the failure of the hot code replace. What we do is following: we let the thread run until it’s finished. Then we start the code again (refresh the page, submit a form…) and let it stop on the same breakpoint. Then we add 1 space and save it. This never fails!

No Hibernate Cache

Another great way to speedup the start time during development, is to disable the Hibernate cache (second level cache, query cache) during development. With a maven profile, this is done very easy.

We have about 25 classes that are non-strict read/write cached. This takes about 12 seconds to start-up, every class that is cached has it’s own thread started by Hibernate (I think this is for timeout of the cache).

No premature loading of cached items

Many applications start by eager fetching some data this is cached then. I believe this is completely useless in a development environment. Again with Maven this ain’t hard to set up.

A word about Spring configuration

One could argue that the Spring configuration could also be completely lazy. Indeed, this would be a tremendous start-up gain, in our 100 beans large project, it takes 20 seconds to set up the beans. It’s the single most time consuming event in our application start-up.

We don’t do this, since it posses a real danger. With lazily initiated beans you lose the dependency checks at start-up

Shorten the setup time

Setting up eclipse is something we needed to do quite a lot of times. When switching branches, when added dependencies etc.

We used to use the maven eclipse plug-in. Lately I found out that this plug-in is absolutely unnecessary. With the proper maven setup, the simple command mvn eclipse:eclipse does the trick. Actually you need two things:

            <plugin>
                <groupId>org.apache.maven.plugins</groupId>
                <artifactId>maven-eclipse-plugin</artifactId>
                <configuration>
                    <wtpversion>1.5</wtpversion>
                </configuration>
            </plugin>

Above is a plugin in the web module (pom.xml).

<jboss-web>
    <context-root>mistral</context-root>
</jboss-web>

Above is the content of the file webapp/WEB-INF/jboss-web.xml , which sets the context-root with jboss. If you don’t do this, it’ll default to the war filename.

Other optimizations

In order to have the best possible environment, other optimizations are in order. But I’ll keep those for my follow-up. Things that can be improved:

• Use of the continuous integration.
• A (good) project wiki
• How to manage multiple databases efficiently(database independence per developer)
• Office instant messaging

Conclusion

Pretty long post. There is a lot to say about development optimizations. My experience in it is that there is a lot to gain. There are some key concerns however:

• KISS, Keep It Simple Stupid.  An optimization should never be something that has to be explained. Optimizations are only good optimizations when they feel natural, they should also make things simpler almost never more complex.
• A very important one: a team should work all in the same manner. It’s too hard when multiple ways of developing have to be supported.
• Don’t be afraid to change your development manners. Sometimes a change can be a little investment, but large gains on longer terms.

As always, I’m open for debate and questions.

Regards,
Andries

Separation of responsibility

Methods should have 1 concern (responsibility, purpose, … ). Let’s look into the matter with an example. Consider following code:

public void createCustomer(Map requestParameters) {
	Customer customer = new Customer();
	customer.setName = requestParameters.get("name");

	//Check if a customer was already registered with that name
	if (customerService.getCustomerByName(customer.getName()) != null) {
		System.out.println("Customer already exists");
		return;
	}
	customer.setShoppingCart(new ShoppingCart());

	customerService.save(customer);

}

The above code is something I scraped together, it’s not real code. But it illustrates something I see regular. The method name is save. So I expect that the code only does some saving. Instead it creates a new customer, checks if it’s valid (no double names) and then saves it. So the method is actually performing 3 things.

This method should be refactored into 4 methods. The first method, which I would call bindValidateAndSave is the algorithm method. It tells what to do, not how it’s done. Its responsibility is to provide the algorithm. The 3 other methods would be called bindCustomer (bind and add new shoppingCart), validateCustomer and saveCustomer.

With the last method (saveCustomer) I get the WHY? question a lot, since the extracted method is actually only 1 line of code long. Although it might not improve readability for programmers, it’s a paradigm shift in how the method is addressed. In our example, if the saveNewCustomer calls customerService.save() it’s responsible that the save method is actually called right. Instead if we let it delegate to a newly extracted method (saveCustomer) it isn’t responsible for the explicit saving. Instead now it defines the algorithm. In this case bind, validate, save. The implementation is just the save method.

Working in this fashion takes some getting used to, but in the end I truly believe this produces stabler and more maintainable code.

Self-describing methods

The second insight I have about the Extract Method refactoring, is removing comments from my code. A lot of fresh developers believe writing comments is the key to great software. As Martin Fowler stated in his excellent book Refactoring, comments are really a bad smell that something is wrong. Either your code is too complex or too long winded. Extracting code just to give it a nice method name helps readability. Take for instance the following example:

public void eat(Food food)  {
	//Other eat actions...

	//Need to blow on the food cause it might be hot
	while (food.getTemp() > 50) {
		mouth.blow();
	}
}

Although the example is completely stupid, it would be slightly less stupid if written like this:

public void eat(Food food)  {
	//Other eat actions...
	blowWhileHot(food);
	mouth.eat(food);

}
private void blowWhileHot(Food food) {
	while (food.getTemp() > 50) {
		mouth.blow();
	}
}

Et voila, our code just became A LOT more readable.

I agree, both examples are intertwined in most cases, but there is a difference between the two.

Both insights are developed by reading Refactoring, a book that definitely made it into my top 10 list!

Got any comments, let’s hear them!

Andries

First off, a small apology. I’ve read the book in Dutch, and he uses terms that I can only translate so and so.

MTQ

MTQ stands for Material, Time and Quality. Every thing you do can be mapped into these 3 parts. The material you are making, the time it took for making it and the quality of the finished product. It’s important that there is a great dynamic between the three. If you change 1 of them, at least another one needs to compensate. The sum is constant. Think about it. If you are nearing a deadline and have a unit of work to do, you can do three things. First is to produce less, second is to take longer and last is finishing with less quality then you would deliver normally.

His most important point on this subject was that the relation between the three exists. Always. There is no such thing as work faster during a period of time. Working faster generally means less quality. Period.

I see MTQ as a measure of efficiency. A good senior developer will produce the same material as a junior developer, but in less time and better quality.

Translating this into best practices, is to realise deadlines are not flexible without taking into consideration of the MTQ theory. Quality is probably the most abstract term, which reflects into less bugs, more maintainable code and better documentation.

Strategy and Tactics

A strategy is a road-map with certain goals. Goals could be learning a technology, get promoted into a certain function, learn a new skill… The goals are generally a long time further into the future.

A tactic is a certain action you will take, that gets you closer to a certain goal. The tactic fits in your strategy.

Translating this into java development is setting milestones into your release plan. Milestones are important strategies, and taking the hardest part first (if possible) is generally a good starting point for choosing the milestones. See the milestones as your strategy, as where specific implementation details are your tactics. Examples of such tactics could be choosing the right technology, using frameworks, and so on.

Side-notes he made are following:

• Strategies that change a lot, aren’t strategies at all: Change can be important but requires are decisive reason and good reasoning.
• Asking why a lot, make good strategics from tacticians. Asking why to yourself forces you to think things through, see bigger pictures and learn more understanding.

Decision Making

Even as developer, we need to make choices every day. We have to determine which the best approach is to resolve a certain problem, which implementation would be best, how we can refactor something and so on. Not to mention higher level decision making, like overseeing development, finding wrong implementation before they become problematic.

To make our decision making efficient, we need to direct the process. Kasparov states that you need to learn to make decisions and give pointers on how you should. Let’s solve a simple problem: decide the best bugfix.
Start off by giving yourself some time to spin up some possible solutions, brainstorm in your mind to provide even the most idiot solution. Search for at least 3 alternatives, let the imagination thrive! Now, depending on the amount of alternatives you’ve found, pick the 2-3 most promising and examining them. Think steps ahead. Ask yourself following questions for each alternative:

• If I change my code like this, where will my behavior change in other code? And if I change other code that was affected, will these changes affect even more code? (See the steps ahead coming?).
• Is my proposed fix easy to maintain, will I need to document a lot?
• Can I do better? How?

After questioning yourself, pick the best choice. Now, this may seem to take long, but you will be awarded following:

• Receive confidence in your code. Writing code in confidence makes you a better programmer (and makes it more fun).
• Be able to see bugs BEFORE they are written. No explanation needed here, does it.
• Write cleaner, better and more maintainable code. Your code will be smart, just like you.

See habits and deal with them

This one is something I do a lot as well. Coders tend to have certain habits, good and bad. A habit I tend to have is to dive into code straight away (Bad Bad Bad…). Other habits could be forgetting to write tests, commenting code and forget to remove it, writing idiot comments or none at all, choosing dubious names and so on. The point is, we should self-evaluate and see these bad habits. Knowing yourself is being a better person.

Everyone has a bad habit, when identified you should deal with it. Force yourself to write tests, hang a big post-it on the screen to never forget it. Personally I’ve make myself write halve the code in my mind before actually starting to write.

One of my favourites was that I knew about 5 shortcuts in Eclipse until 6 months. Identified this as a bad habit, printed the cheat sheet and forced myself to use them. When I didn’t , I deleted my piece of code I had generated and did it again by the shortcut. 6 months later I know like 50 shortcuts in eclipse, which owns. The downside is now with Eclipse Europe, they changed some of them (alt+enter for one), which is frustrating…

Game Stages

• Opening Game: In opening games you use a repertoire to setup the board. Openings are predetermined setups of the board. You can reflect this to use what you know, when starting a new project. Or better yet: use what works. Don’t reinvent the wheel. There are a lot of common best practices to be used when starting up a new project.
• The middle game: Here is where developing matters. Building up the application up to the next release. Nice play where one should overcome possible dangers and problems. No predetermined path can be found, as every chess game is unique (and so is every application), one will have to deal with the problems as they arrive.
• The endgame: Here the amount creativity drops to a bare minimum. See this as the final days before a release. Only a very limited path to success is available. Here we need to focus on what needs to be done.

The advantage of the attacker.

Attacking problems before they are too big is better then to wait until a problem is blocking. Attackers are in advantage because less code is dependent on the problem, making the solution simpler.

Final thoughts

I do admit, this is a limited snapshot of the book. I’ve filtered the stuff out that actually could be mapped into java development. Some topics he wrote about were a big stretch to get into the Java world . Anyway, I’ve tried on the best parts and I hope you enjoyed it.

More about the book

Do I recommend this book? Yes! Although it’s not the best book I’ve read in it’s branch, it’s definitely worth reading. I enjoyed mapping my mind to his, seeing how stuff he encountered could and did reflect on me. In the end, I became a wiser person, something I strive for at the moment.

It changed my perspective on certain topic, I especially liked the part about the MTQ and the decision making progress. Also the end of the book, which deals less about chess and more about dealing with yourself, was an eye opener on a lot of topics.