Monday, February 13, 2006
On another note
A couple of weekends ago I was pleasantly surprised to bump into Steve Freeman at a very English institution. Steve came up with a parallel between the way that orchestral players mark their parts in pencil, and the way people comment their code. With orchestral scores, each player and conductor has their own interpretation of the piece. They often mark their parts in pencil to remind them of changes of tempo, changes of key, or when the pages need turning quickly. As sets of parts get passed from one player or orchestra to another, the amount of pencil tends to increase, often obscuring the original information. It is normally a relief to see a nice clean part with little or no pencil, just the notes and directions as written by the composer. Removing the clutter gives time and space to read and process all of the information on the page, without confusion, contradiction or duplication of information.
People often encourage thorough commenting of code, to explain to other developers what it does, and how it works. Steve and I reckoned that we would much rather see clear, well written code with no comments, than the verbose and largely unhelpful comments that one often sees. Then when you do see a comment, you know to pay particular attention to it. We really want to see the notes underneath the pencil, not be distracted by scribbles.
People often encourage thorough commenting of code, to explain to other developers what it does, and how it works. Steve and I reckoned that we would much rather see clear, well written code with no comments, than the verbose and largely unhelpful comments that one often sees. Then when you do see a comment, you know to pay particular attention to it. We really want to see the notes underneath the pencil, not be distracted by scribbles.
Drawing Parallels
Recently I've been reading a bit about Neuro Linguistic Programming (NLP). I haven't got too deeply into it, but it's generally a set of theories about the way that people think, communicate, learn and perceive the world around them. For example, some people think about things mostly in a visual way, whereas others prefer to use sounds or feelings to represent their thoughts internally. The idea is that by learning about the different representation systems, and how to tell which ones people favour, you can tailor your words and actions to communicate with them more effectively.
The particular book I am reading wraps this up in a self-help, being a more effective person, achieve your life goals type of way, but one thing struck me. The book describes the essence of NLP, and being an "effective person", as 1) know what you want; have a clear idea of your outcome in any situation, 2) be alert and keep your senses open so that you know what you are getting, 3) have the flexibility to keep changing what you do until you get what you want.
This seems a lot like what the agile development philosophy says. We have a set of stories that define where we want to get to; during development we monitor progress with daily standups, regular integration, or more empirically with techniques like Scrum; and we change the stories, the solutions, the code, the team etc, etc, until we get where we want to be.
The particular book I am reading wraps this up in a self-help, being a more effective person, achieve your life goals type of way, but one thing struck me. The book describes the essence of NLP, and being an "effective person", as 1) know what you want; have a clear idea of your outcome in any situation, 2) be alert and keep your senses open so that you know what you are getting, 3) have the flexibility to keep changing what you do until you get what you want.
This seems a lot like what the agile development philosophy says. We have a set of stories that define where we want to get to; during development we monitor progress with daily standups, regular integration, or more empirically with techniques like Scrum; and we change the stories, the solutions, the code, the team etc, etc, until we get where we want to be.
Wednesday, February 01, 2006
Spring AOP
I've generally been a bit sceptical about the applicability of aspect-oriented programming (AOP). There seemed to be a lot of hype coming out of places like IBM about AspectJ, but I could never see this really taking off, as it is really a different language, rather than an extension to Java. Kevin Sullivan (et al) have an interesting paper which balances some of the benefits and some of the problems, using AOP to design software. After reading this I was still thinking that aspects might not be that useful.
However, I've recently been looking at the AOP support in Spring, which gives the programmer an API to use, rather than extra programming language constructs. Although this restricts what is possible to a certain degree, it does allow AOP to be used in "normal Java programs", especially as one of the tenets of Spring's design philosphy is to be non-invasive. I have managed to add two useful aspects to my current project, without changing the existing source code, but just by adding some new classes, and some configuration. Spring then weaves its magic to connect things up at runtime (using a lot of reflection and dynamic proxies behind the scenes). Regardless of this, I was pretty impressed.
In the application I am working on at the moment, we are calling a number of external web services, and we have been somewhat concerned with the performance of these. We wanted to measure how long calls to the web services take to complete. By using an aspect, we can write the profiling code in one place, and apply it across all of our web service calls. By configuring it in the Spring application context, we can also insert or remove the profiling code without having to alter the Java source.
I wrote the following simple class, which implements an interface from the Spring API, to implement some around advice. There's a lot of terminology used in AOP, for a quick guided tour, see this glossary.
Then in the configuration, I just add:
Spring automatically creates a proxy for my webServiceFacade bean, which intercepts calls, and runs my advice instead (which in turn, proceeds to call the original method).
In the same vein, I took the ideas presented by Tom White in his article on using memoization for caching, and created a caching aspect. I could then chain this together with my profiling aspect to compare performance of the calls with and without caching.
However, I've recently been looking at the AOP support in Spring, which gives the programmer an API to use, rather than extra programming language constructs. Although this restricts what is possible to a certain degree, it does allow AOP to be used in "normal Java programs", especially as one of the tenets of Spring's design philosphy is to be non-invasive. I have managed to add two useful aspects to my current project, without changing the existing source code, but just by adding some new classes, and some configuration. Spring then weaves its magic to connect things up at runtime (using a lot of reflection and dynamic proxies behind the scenes). Regardless of this, I was pretty impressed.
In the application I am working on at the moment, we are calling a number of external web services, and we have been somewhat concerned with the performance of these. We wanted to measure how long calls to the web services take to complete. By using an aspect, we can write the profiling code in one place, and apply it across all of our web service calls. By configuring it in the Spring application context, we can also insert or remove the profiling code without having to alter the Java source.
I wrote the following simple class, which implements an interface from the Spring API, to implement some around advice. There's a lot of terminology used in AOP, for a quick guided tour, see this glossary.
public class SimpleProfilingAdvice implements MethodInterceptor {
public Object invoke(MethodInvocation invocation) throws Throwable {
StopWatch sw = new StopWatch();
sw.start(invocation.getMethod().getName());
Object returnValue = invocation.proceed();
sw.stop();
report(invocation, sw.getTotalTimeMillis());
return returnValue;
}
private void report(MethodInvocation invocation, long ms) {
// print out the timing info etc
}
}
Then in the configuration, I just add:
<bean id="webServiceFacade" class="WebServiceFacadeImpl" />
<bean id="profiler" class="SimpleProfilingAdvice">
<bean id="proxyCreator" class="org.springframework.aop.framework.autoproxy.BeanNameAutoProxyCreator">
<property name="beanNames">
<list><value>webServiceFacade</value></list>
</property>
<property name="interceptorNames">
<list>
<value>profiler</value>
</list>
</property>
</bean>
Spring automatically creates a proxy for my webServiceFacade bean, which intercepts calls, and runs my advice instead (which in turn, proceeds to call the original method).
In the same vein, I took the ideas presented by Tom White in his article on using memoization for caching, and created a caching aspect. I could then chain this together with my profiling aspect to compare performance of the calls with and without caching.
