Feedback for improvement in agility
February 18th, 2009
Last week, during a casual chat with our Agile evangelist, I asked about what could be improved in our team based on what he observed.
He quickly said that it depends on a lot of things and that it is difficult to give feedback without being part of the team. He asked me to pose that question to the team. We already do that in retrospective meetings.
But, after pushing further to get some high-level things that we could improve upon, he gave me a few suggestions:
- Adopt pair-programming for every line of code that we write.
- Increase the level of communication between team members
- Everyone needs to really pay attention during stand-ups
- Work towards overall team productivity rather than individual productivity
- …..
My immediate reaction as soon as I heard “pair-programming for every line of code” was to point out that it may not be the right thing to do all the time. Now, I realize how stupid I was..! I was asking for feedback. I should have shut my mouth and should have treated every piece of advice as a compliment. I did thank him for his time, however.
This was very valuable feedback. I need to apologize to him tomorrow for arguing with him even if I did not completely agree with his opinion.. 
Application Configuration properties simplified by Spring
February 8th, 2009
The combination of PropertyPlaceholderConfigurer and PropertyOverrideConfigurer classes in Spring Beans API have been invaluable for me to simplify configuration properties for a few of applications I have worked-on recently. The placeholder configurer helps us to share the properties across various pieces of the application using “placeholders”.
As recommended in the Spring reference manual, I usually setup a “default” configuration file (app.properties.default) file that is packaged within one of the main Jar files. This keeps the actual (overriding production) properties file very short as you only override the properties that are different than the default properties file.
Sometimes, a simple loading of the configuration properties may not be enough. There might be a need for post-processing the properties using some custom code.
Certain properties may have to be:
- Selectively disabled/enabled
- Translated based on the values of others
- Set & be available within the application (in the code that is not wired-up in Spring XML)
Spring does have hooks for some of these to decrypt/encrypt properties, intercept the processing of each of the String values, etc. This means writing a new class that overrides the natural behavior of these Configurer classes.
Both of these Configurer classes are implemented as bean factory post-processors. So, if ApplicationContext is used instead of BeanFactory, these should automagically work. If you are using BeanFactory interface (eg., XMLBeanFactory class), then you will need to construct these Configurer classes and call the “postProcessBeanFactory” method by passing the BeanFactory instance as a parameter.
This method is also very helpful if there is a need to centralize the post-processing logic in one place and if this logic involves a lot of custom coding:
public void postProcessBeanFactory(ConfigurableListableBeanFactory beanFactory) throws BeansException
As per the Javadocs, this method is invoked after all bean definitions have been loaded, but no beans have been instantiated yet.
Best way to demo/learn a Java-based API
February 1st, 2009
I designed and implemented a dual-API SDK at my current job. This dual-API SDK did not initially run on any application server.
During this implementation, I learnt that it is best to use a dynamic language like JRuby or JPython or Groovy for demonstrating & learning the capabilities of the API as well as interactively test some edge-case scenarios that are not so easy to automate (randomly causing network outages, database outages, etc.). This was very useful especially at the Sprint reviews to demonstrate the new functionality.
It is incredibly easy it is to set up some complex scenarios interactively using the Java API calls in one of the above 3 dynamic languages. We are still using JDK 5 and so could not take advantage of the built-in scripting support in JDK 6.
We chose to use JRuby (due to the familiarity of Ruby to some developers) even though my favorite was JPython, especially because I have had experience building a large-scale enterprise system using Python in one of my previous jobs at a startup.
However, we ran in to one big problem: The APIs (API interfaces) that use Java Generics were impossible to test using JRuby. We kept the usage of generics to very minimal in our client API interfaces but for obvious reasons our SPI-side interfaces used generics heavily.
After a while, I also realized that it is impossible to type all of the JIRB commands correctly. Any typos in JIRB can lead to really ugly stack traces on the console. Hence, the need for tab-completion and file-based history to remember all of the commands that can be accessed by using the up-arrow/down-arrow keys.
Also, as a nice touch to our Sprint review demos, we customized the command prompt to display our product name (I have changed that to “MYSDK”, below). So, the following .irbrc file was created and copied to the user.home dir.
# ~/.irbrc
# enables Tab completion
require 'irb/completion'
#IRB.conf[:PROMPT_MODE] = :SIMPLE
IRB.conf[:USE_READLINE] = true
IRB.conf[:ECHO] = false
IRB.conf[:IRB_NAME] = “MYSDK”
IRB.conf[:DEBUG_LEVEL] = 0
IRB.conf[:AUTO_INDENT_MODE] = true
# Setup a file-based history across sessions of irb
require ‘irb/ext/save-history’
IRB.conf[:SAVE_HISTORY] = 100
IRB.conf[:HISTORY_FILE] = “#{ENV['IRBRC']}-history”
require ‘java’
import java.lang.System
# SDK stuff
# My SDK imports go here..