In the RC1 version of Spring Security 3.0 (SS3), the Portlet jar was dropped that was available in v2.0.5 (spring-security-portlet-2.0.x.jar).  That leaves us with a dilemma when it comes to securing portlets using SS3.  To implement security in a portlet in a JSR-168 context one would have to re-implement everything in the portlet jar to use an interceptor based way of adding an Authentication to the SecurityContext.

Rather than taking that path, Spring 3 supports JSR-286 portlet specification which allows for portlet filters.  Since a common way to implement security is through security filters, a portlet filter method seems like a viable alternative.  There is one main issue with using portlet filters in that Spring cannot be used to create or inject dependencies into the portlet filter.  (Maybe it can but I wasn’t able to get it to work).

Thus, I’ve created a PortletSecurityFilter filter that more or less follows the SS3 security process used in the Servlet side implementation (AbstractAuthenticationProcessingFilter).

What’s the point of doing this?  Well, we need to deploy our portlet to multiple portal containers.  Thus, if we use SS3 we can easily control our portlet roles and not have to rely on the portal implementation.

Process

The whole point of this exercise is to push an Authentication into the SecurityContext for SS3 to use later when verifying Role information.  We’ll create a PortletSecurityFilter to accomplish this push.

Warning, many might think of this as a hack to fool SS3.  If you’re okay with that then keep reading.

Portlet Lifecycle Location

The first question is in what portlet lifecycle should the filter live?  That depends but the best location is during the Action Phase.  Adding the filter at this point sets the SecurityContext early enough for both the Action and Render phases meaning SS3 will work for both annotation driven security as well as jsp rendering security.

PortletSecurityFilter

Below is the code for the PortletSecurityFilter.  Note that you will have to implement your own AuthenticationDetailsSource and AuthenticationManager for this to work.  You’ll notice this also throws the Authentication token onto the PortletSession for use in later requests. 

package com.your.package.name;
 
import java.io.IOException;
 
import javax.portlet.ActionRequest;
import javax.portlet.ActionResponse;
import javax.portlet.PortletException;
import javax.portlet.PortletSession;
import javax.portlet.filter.ActionFilter;
import javax.portlet.filter.FilterChain;
import javax.portlet.filter.FilterConfig;
import javax.portlet.filter.PortletFilter;
 
import org.apache.log4j.Logger;
import org.springframework.security.authentication.AuthenticationDetailsSource;
import org.springframework.security.authentication.AuthenticationManager;
import org.springframework.security.core.Authentication;
import org.springframework.security.core.context.SecurityContextHolder;
import org.springframework.security.web.authentication.AbstractAuthenticationProcessingFilter;
import org.springframework.security.web.authentication.UsernamePasswordAuthenticationFilter;
import org.springframework.security.web.authentication.preauth.PreAuthenticatedAuthenticationToken;
 
/**
 * Implements security behavior for Spring Security 3.0.  Adds an <tt>Authentication</tt> to the
 * <tt>SecurityContext</tt> and to the <tt>PortletSession</tt>.  Spring Security picks up the 
 * <tt>Authentication</tt> when it meets annotated methods with the @Secured annotation.
 */
public class PortletSecurityFilter implements PortletFilter, ActionFilter {
 
    private static Logger logger = Logger.getLogger(PortletSecurityFilter.class);
    private static final String SECURITY_TOKEN = "SECURITY_TOKEN";
 
    private AuthenticationDetailsSource authenticationDetailsSource = new PortletAuthenticationDetailsSource();
    private AuthenticationManager authenticationManager = new PortletAuthenticationManager();
 
    @Override
    /**
     * Follow the Spring Security method for an AuthenticationFilter.
     * @see AbstractAuthenticationProcessingFilter
     */
    public void doFilter(ActionRequest request, ActionResponse response, FilterChain chain) throws IOException, PortletException {
	if(request.getUserPrincipal() == null) {
	    // If no UserPrincipal from Portal stop the chain here.
	    return;
	}
	Authentication auth = (Authentication) request.getPortletSession().getAttribute(SECURITY_TOKEN);
	if(auth == null) {
	    PreAuthenticatedAuthenticationToken authToken = new PreAuthenticatedAuthenticationToken(request.getUserPrincipal(), request.getRemoteUser());
	    setDetails(request, authToken);
	    auth = authenticationManager.authenticate(authToken);
	}
 
        if(auth.isAuthenticated()) {
	    successfulAuthentication(request, response, auth);
	    chain.doFilter(request, response);
	    return;
        }
    }
 
    /**
     * Default behavior for successful authentication.
     * <ol>
     * <li>Sets the successful <tt>Authentication</tt> object on the {@link SecurityContextHolder}</li>
     * <li>Sets the <tt>Authentication</tt> onto the <tt>PortletSession</tt></li>
     * </ol>
     *
     * @see AbstractAuthenticationProcessingFilter
     * @param authResult the object returned from the <tt>attemptAuthentication</tt> method.
     */
    protected void successfulAuthentication(ActionRequest request, ActionResponse response,
            Authentication authResult) throws IOException, PortletException {
 
        if (logger.isDebugEnabled()) {
            logger.debug("Authentication success. Updating SecurityContextHolder to contain: " + authResult);
        }
        SecurityContextHolder.getContext().setAuthentication(authResult);
 
	PortletSession session = request.getPortletSession();
	session.setAttribute(SECURITY_TOKEN, authResult);
    }
 
    /**
     * Implementation of setDetails.
     *
     * @see UsernamePasswordAuthenticationFilter
     * @param request that an authentication request is being created for
     * @param authRequest the authentication request object that should have its details set
     */
    protected void setDetails(ActionRequest request, PreAuthenticatedAuthenticationToken authRequest) {
        authRequest.setDetails(authenticationDetailsSource.buildDetails(request));
    }
 
    @Override
    public void destroy() {
	System.out.println("Action filter destroy.");
    }
 
    @Override
    public void init(FilterConfig arg0) throws PortletException {
	System.out.println("Action filter init.");
    }    
}

portlet.xml

The next step is to add this portlet filter to the portlet.xml file.  After you have declared your portlets, insert the following filter declaration:

    	<filter>	
		<filter-name>PortletSecurityFilter</filter-name>
                <filter-class>
                    com.your.package.name.PortletSecurityFilter
                </filter-class>		
		<lifecycle>ACTION_PHASE</lifecycle>		
		<init-param>		
		<name>message</name>
		<value>Security Filter</value>		
		</init-param>	
	</filter>
 
 
	<filter-mapping>
		<filter-name>PortletSecurityFilter</filter-name>
		<portlet-name>your-portlet</portlet-name>
	</filter-mapping>

Spring Security 3.0 Configuration

We have to enable SS3 by creating an applicationContext-security.xml file.  Basically, all we really have to do is enable secure annotations so if you don’t want to create a new file than just throw this into your current applicationContext.xml:

<?xml version="1.0" encoding="UTF-8"?>
 
<beans xmlns="http://www.springframework.org/schema/beans"
xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance"
xmlns:security="http://www.springframework.org/schema/security" 
xsi:schemaLocation="http://www.springframework.org/schema/beans http://www.springframework.org/schema/beans/spring-beans-2.5.xsd
        http://www.springframework.org/schema/security http://www.springframework.org/schema/security/spring-security-3.0.xsd"
        >
	<security:global-method-security secured-annotations="enabled"/>
 
	<security:authentication-manager alias="authenticationManager" />	
 
</beans>

web.xml

Finally, if you added a new applicationContext than you’ll need to add that to your web.xml as a new contextConfigLocation.  That path will depend on where you put the file but one path might be:

/WEB-INF/context/applicationContext-security.xml

Add Security

Now all you need to do is add @Secured notations to your protected services or <security:authorize> tags to your jsp.  Assuming you created an AuthenticationManager that added the proper GrantedAuthorities than your security should now work.

I did this with Liferay portal v5.2.3 and successfully secured my portlet outside of Liferay.  Of course Liferay provides you with methods to expose your portlet permissions and administer them through Liferay control panel but we did not want to use that method.

svn:keywords : Date Revision Author URL Id

You can see a file’s properties from the command line with

svn pl -v filename

Some tool (like netbeans) don’t provide for defaulting properties when adding new files.  And there are probably some people (not gonna name names :^) who don’t configure their tools to default the svn:keywords property anyway.  So below is a little script that’ll do it for you.  The script is in ruby ’cause Brian (who first sketched it out a few years ago for a project) wanted to do some ruby scripting.

You can run it from time to time from the command line or better yet, set up a cron job on the build server to do it once or twice a day.  Our cron job does something like this:

cd ~/tmp/scratch-dir
svn checkout https://opi.svn.cvsdude.com/xyzzy
add_svn_keywords.rb
svn commit -m \"Added svn:keywords property\"

It’s up to you if you want to do a full checkout each time (an update would be faster.)

Here’s the script…

#!/usr/bin/ruby
#
# Adds svn:keywords property to source files.  Default to process the
# current directory.  Note: this does not commit the changes!
#
# Usage:
#   ruby add_svn_keywords.rb [src_dir]
#
# where
#   src_dir (Optional) The directory to process.
#
# for example
#   ruby add_svn_keywords.rb c:/mnscu/hr/code
#
require 'find'
require 'fileutils'
include FileUtils::Verbose
require 'ftools'
require 'optparse'

# -- functions --------------------------------------------------------------

def do_system(command)
    puts command
    system(command) or raise($?)
end

# -- vars -------------------------------------------------------------------

working_dir = "."
keywords = "Date Revision Author URL Id"
usage = "Usage: ruby add_svn_keywords.rb [src_dir]"

# -- options and svn checkout/update ----------------------------------------

opts = OptionParser.new
opts.parse(ARGV) rescue usage

unless ARGV[0].nil?
    working_dir = ARGV[0]
end

# -- svn properties ---------------------------------------------------------

num = 0
Find.find(working_dir) do |path|

    if FileTest.directory?(path)
        if File.basename(path) == '.svn'
            # allways skip the .svn dirs
            Find.prune
        else
            # don't bother setting properties on dirs
            next
        end
    else # must be a file...
        # quote spaces on paths that contain them (so svn wont fail)
        path.gsub!(/ /, '\ ')

        # add keywords property to some files...
        if File.file?(path) and path =~ /\.(ddl|bat|sh|css|dtd|el|groovy|gsp|html|java|js|jsp|properties|sql|txt|xml)$/
            keywordprop = `svn proplist --verbose #{path}`.to_a.find_all {|line| line.include? keywords  }
            if keywordprop.size == 0
                do_system("svn propset svn:keywords \"#{keywords}\" #{path}")
                num += 1
            end
        end
    end
end # find

# -- commit and cleanup -----------------------------------------------------

if num > 0
    #do_system("svn commit -m \"Added svn:keywords property\" #{working_dir}");
    puts "Added svn:keywords property to: #{num} files"
else
    puts "No changes"
end

# -- end of file ------------------------------------------------------------

http://net.tutsplus.com/tutorials/javascript-ajax/create-a-twitter-like-load-more-widget/

I’ve tried MooTools version and worked fairly well (For IE, you need to remove the last comma in line 133 of mootools-version.php). Very easy to customize and the effect is great!

Mr. Burke’s describes the “support nightmare” as follows:

A support call comes in for your product or application. It’s obviously a bug, but where is the problem? Is it your application code? Your JVM? Your Ruby VM? Your Java library? Your Ruby gem?

To paraphrase, adding a language will make it more difficult to track down bugs when support calls are made. Of course, with the decision to add any framework, runtime or library, we add complexity to our applications. In my experience, I think adding another language is no different. Even if I have an all Java stack, that doesn’t make it right to add any Java library that I want to the application environment. Too many times, I have seen frameworks injected into applications to solve problems that could have been coded by hand in less than fifty lines of Java. In situations like this, the conceptual complexity of learning a new framework doesn’t make sense. The critical aspect about the decision to add any toolset to an application is that it must be evaluated relative to its benefit.

In reality, we already deal with multiple runtimes when we resolve support calls. If a value doesn’t display correctly in a typical Java web application, the problem could be in any number of places. It might be a problem with HTML, a JSP tag library, a JavaScript function, a JavaScript library, server side controllers, business logic embedded in a service, a library utilized by these services, messaging to other systems, the ORM library or the database itself. This is why feel strongly that the decision to add anything to a system must be evaluated relative to its benefit. The expertise we utilize when evaluating a library can and should be applied when adding a language as well.

This final point about the “support nightmare” provides a nice segue to some concluding thoughts about building polyglot systems. The fact is we already use multiple runtimes and multiple languages. Even simple two-tier desktop systems will typically use SQL (the language), a SQL database runtime and whatever language the application is being built in. The reasons we already do it are so obvious, we rarely debate them. I remember the excitement I had when I was able to embed SQL in my C code instead of using Btrieve, an indexed record manager. Sure, the SQL based RDMS was more complex to install, hid more details under the covers, required a preprocessor for the C code and involved effort to setup and maintain. But the benefits easily out-weighed the effort for the applications I was building. In the same way, adding another language like Groovy or Python may require some effort, but the benefits in terms of a smaller, more expressible code base that directly reflects the problem domain can easily be worth it for the long run. Ultimately, we deliver greater business value to our customers with systems that are easier to comprehend, support, enhance and maintain. I’ve found that using the right language for the right job can help deliver such systems.

Building relationships

To be a well rounded consultant, an individual should have the people skills necessary to integrate into all facets of the team he or she is joining. This is even more important if this consultant is expected to lead the team and/or teach those he or she is working with. In this context, people skills means more than just being able to look somebody in the eye while talking to them or not curling up into a ball, sucking a thumb when somebody attractive speaks to you. We need to be, to borrow a phrase from a co-worker, socially capable geeks! You want to get to know people on a personal level, it isn’t just business. Get coffee with clients when you can. Go to lunch with people you are working with or, even better, those you are working FOR. So much of the consulting business these days is built upon relationships. When sales critters get wind of a project somewhere, the first order of business is finding somebody on staff who knows the people in charge of that project. They want to leverage a relationship to first get on the radar and to later pitch their story. Knowing somebody, not just working for them, is very important.

Like me + remember me = return business

Having the personality to be memorable goes a long way in todays market. When a decision maker decides to enlist the help of a consultant, they will often seek out folks they have worked with before. If you did great work, but nothing that was exceptional enough to be MEMORABLE work, chances are you will be forgotten. However, if you had the personality that was memorable and/or forged a relationship with this person, then chances are you will be in the forefront of their mind and get the call. Being a rock star at the keyboard isn’t always enough. Sometimes, the fact that you are a rock star can even go unnoticed if all you do is hide in the corner writing code and reading developer forums while you eat lunch. In today’s agile team environments, its very hard for a manager to keep tabs on which of the developers is keeping the project on track. Finding ways to stand out from the crowd, in a positive light of course, becomes essential to obtaining return business.

In summation, if you call yourself a consultant and can’t look at your email address book, cell phone contacts or facebook friends and find at least a couple people from each client you have worked at in the past, you probably aren’t doing your best. You haven’t forged those relationships that are of the utmost importance in today’s business climate. Unless you write the greatest code in the world (in the eyes of your client, not your own opinion) or solved a monumental problem, you probably aren’t going to be remembered. Start getting involved with your client and the people at the client personally, it’ll pay dividends down the road!

In describing the “installation nightmare”, Burke states:

But you still need to package and install all the appropriate Java libraries, Ruby gems, and Python libraries on the appropriate places of your user’s machine. You also need to hope that all the desparate environments don’t conflict with anything the user has already installed on his machine. And that’s just with languages running in the JVM.

These are valid concerns, but I don’t think they are exclusive to polyglot programming.

The problems of developing code that “works on my machine” but doesn’t work anywhere else are well documented. In my opinion, the first place to start with any project is a one-step build that provides for automated testing plus some form of continuous integration. This isn’t a particularly original idea these days. In our project, we used Ant to implement a one-step build using a clean checkout from version control. It took effort to get this working, but the effort involved would have been required whether Groovy was involved or not. In my experience, migrating from desktop Windows to Linux and then to AIX became a non-event once I had a one-step build in place.

In response to my previous blog posts on this topic, it has been pointed out that Groovy might be a special case. This is true to some degree in that Groovy was designed from the beginning for easy integration with Java. However, I think the concern about conflicts among libraries on different platforms is valid with or without Groovy. I’ve experienced first hand the unexpected differences in string truncation among IBM’s DB2 drivers running on different platforms. On Java projects, there is always a concern about a conflict with Antlr or ASM when using Hibernate and some other library that uses byte code generation. Adding Groovy is no different than adding any other library or framework to a project. There are always risks. Fortunately, one step builds and continuously integrating on all of your project platforms are tried and true strategies for mitigating this risk.

Finally, my thoughts with regards to non-JVM languages are different than those expressed by Mr. Burke:

Imagine if you used vanilla Ruby, Python and Java all as separate silos!

I would encourage you to take your imagination out of the decision making process and base it instead on facts by testing things for yourself. For example, with Python, you might find that not only is it already installed on your test and production platforms, but your required libraries might be there as well. It also might be that installing the required libraries is trivial. Of course, it is possible that it is not trivial. The important point is to try it out and then evaluate the cost/benefit to your particular project. If the benefit is replacing 10,000 lines of the most complicated part of your project with 2,000 lines of code that is more readable and easier to “reason about”, then even the extra effort of engaging your infrastructure team to install a required Python library might be worth. Remember, the costs don’t exist in isolation but in relation to the benefit of adding another of language. The importance of this cannot be overstated.

At the end of the day, the business doesn’t exist for IT’s benefit and comfort. It is our job as developers to deliver systems that represent a good value to those making the investment. Where appropriate, we shouldn’t be afraid to utilize more than one language if it adds value to the project and take advantage of techniques like one-step builds and continuous integration to mitigate the risks.

In my next post, I’ll address the “support nightmare”.

1. Is a container DIV not stretching accordingly to the size of content DIV’s?

1
2
3
4
5

<div id="container_div" style="width: 500px;">
    <div id="left_column" style="float: left; width: 200px"></div>
    <div id="right_column" style="float: left; width: 200px"></div>
    <div style="clear: both;"></div>
</div>

The last DIV will make sure that container_div will stretch accordingly to the size of left_column and right_column.

2. IE 6 3px gap
When I set the left_column and right_column’s width to 250px, it looked as though IE6 is completely ignoring the fact that these DIV’s are floating. It turned out, IE 6 has a gap of width 3px and the contents of the right_column gets pushed underneath the left_column.

http://www.positioniseverything.net/explorer/floatIndent.html

3. Peek-A-Boo bug in IE6
Now all the DIV’s are positioned where I want them. Surprise! It seems as though the contents of the DIV is hiding behind the background image in IE 6. You can sort of see it when you mouse over and try highlight it. Setting z-index won’t do the trick because there is no z-indexing in IE6. But do not worry. Once again, http://www.positioniseverything.net came to a rescue.

http://www.positioniseverything.net/explorer/peekaboo.html

His second solution of setting ‘position: relative;’ usually does the trick for me.

Happy Web Development!

In this post, I’ll address the “refactoring nightmare” as described by Bill Burke in “Polyglotism is the worst idea I ever heard”. In that post, he states:

So now your developers can use any one of these language to build out extensions to your Java app. But what happens when you want to refactor one of your re-used Java libraries? OOPS!!!

I’ve seen these type of statements in blogs dating back to 2004. Let’s take the hypothetical one step further: What happens when I use Java to build out an extension to my Java app and the library doesn’t live in the same project or project workspace as my extension? OOPS!!! There are all kinds of hypothetical scenarios that we can imagine to scare ourselves into not using this or that technology. It is more insightful to see how actual project experience can substantiate or remove the fear, uncertainty and doubt.

I do think it is reasonable to expect refactoring could be different with a dynamic language in play. The lack of tooling was one of the major concerns introducing Groovy into our project. Personally, I was used to coding in Eclipse and was very comfortable with the tools it provides. I couldn’t imagine not working in Eclipse so I expected the worst. However, reality was different from expectations in ways I never anticpated.

When the project started out, I made sure all of my Groovy code always explicitly declared types. I also created interfaces following Java best practices. As a programmer who had been using Java since 1998, I was willing to accept Groovy but I was going to make sure our team followed “good” programming practices. I didn’t want our team to get too carried away with this dynamic stuff. I was quite pleased as the project proceeded quite well for almost nine months without any major refactoring required. Then, the inevitable unforeseen change in requirements appeared that was going to rip its way through most of our existing code. At the time, I only had JEdit, Ant and JUnit at my disposal. This change resulted in my spending a long, exhausting weekend refactoring the code. Luckily, our team had almost 100% code coverage between our unit tests and integration tests. Without those tests, I’m sure it would have taken weeks to make sure the new changes were correct.

The insight gained from this long refactoring weekend was completely unexpected. If I had not coded to interfaces and had not included types on all the method signatures, the coding changes would have been minimal. Our team did a really good job of writing lots of small methods that operated on a few properties at a time. It became obvious that the successful execution of these methods didn’t depend on the objects containing the properties.

Consider the following example: A method might look up a rate adjustment in an insurance rate table based on the gender and age of the insured. The only things that mattered were the the gender, the age and the lookup table. It didn’t really matter if age and gender were part of a Person object, an InsuredPerson object or a hash map. With Groovy and duck-typing, as long the object passed into the method had the properties “age” and “gender”, the method could do its job.

I kept my eye on this going forward and realized that as objects with properties flowed through the system, it didn’t really matter what the objects were. As long as the objects passed into the business calculations had the expected properties, we got the behavior we expected from the system. Thus, my experience for our system over the next two years was that we had an easy time of refactoring when we avoided specifying types in our system. Never again did I waste a whole weekend trying to refactor our system to accommodate a change in our object model.

I have given presentations about this project many times during the last two and half years and this concept is always the hardest thing for the audience to comprehend. I don’t think its something that a person can craft an argument for and expect to have everyone nod in an agreement. There are some things that just have be experienced to be understood. I am certainly willing to grant that I may be the lucky recipient of the perfect problem domain, programming languages, and programming team for this to happen. However, I have had similar experiences doing other, smaller projects in Groovy and Java.

In summary, on a large polyglot project using Groovy and Java, I didn’t experience a “refactoring nightmare”. I found that within a given coarse-grained component, if I (a) removed all types, (b) only used interfaces sparingly, and (c) had a dependable test suite, the time spent refactoring became a non-issue for my project. How does this relate to delivering business value? Time spent refactoring is time spent focusing on technical issues, not business issues. In our regular meetings with our business experts and project manager, the team stayed focused on working through the business logic and not getting sidetracked on technical issues that don’t deliver business value.

In the next segment, I will focus on my experiences as they relate to the “installation nightmare”.

The Quality Analyst (QA) role in an Agile environment has significant importance.  In Agile, the QA is part of the development team and included from the start of the project.  QA is expected to be as up-to-date on requirements and system state as any developer.  QA is also continuously reviewing completed tasks and stories to near real-time feedback.  If there is one concept in Agile it is fast and continuous feedback on all fronts, QA is essential for this to become reality.

When running a mixed Agile/Waterfall development environment it can be difficult to engage the QA resources at the correct moment.  Generally QA is accustomed to having some large period of time, say six weeks, at the end of development where they test the entire system.  The argument for this type of testing is that at this point the code is “locked down” and thus they can test the system in peace (not pieces) without worrying about pesky developers changing things on them.  While this is a fine notion, it rarely happens and development often runs over the QA cycle.  Or, more importantly, QA finds issues that simply must be fixed.  In standard QA parlance, the QA team should start their testing from scratch after the changes are made to the code.

Agile QA

Agile has the idea of production ready functionality at the end of every iteration.  To do that, QA must be involved at the iteration level and be testing functionality as it develops.  If done correctly, at the end of the iteration the stories and components are ready to deploy to production.  Thus, unless major changes occur, these items only need regression testing from this point forward.

Embedded QA

Since QA is part of the development team, they are often co-located with the development team as well.  This gives the QA person a significant advantage, they are present when requirements changes are taking place and can express their opinions in real-time rather than after the fact.  The QA person can also help refine requirements by providing the customer’s view of the application.

Automated Testing

Once components are production ready, automated test scripts are created to compile a full suite of regression tests.  These automated tests combined with the developers Unit and Integration tests help ensure that any changes made during the current and future iterations do not adversely affect the previously tested code.

Deployment to Production

As with any project, the final push to production is often a hectic and hurried endeavor.  QA is usually under pressure to certify that the application works.  While Agile projects are sometimes (but hopefully not) just as frenzied, the existence of thoroughly tested components, automated QA test and development unit tests help ease the burden on the QA team.  While a full system test is still advisable before deploying to production, since QA has been involved from the beginning and is aware of all requirements modifications that have occurred throughout the life of the project, this task is not as onerous as in non-Agile environments.  There is not a lot of back and forth between QA, development and BAs about requirements changes that were not adequately documented.

Often times the true QA cycle, where code is “frozen”, can be cut down to one to two weeks as the QA team feels very comfortable with where the application is at when the cycle begins.

He wrote his post after reading “Polyglotism is the worst idea I ever heard“ by Bill Burke. I don’t know Bill Burke personally but the post has a troll-like feel. However, beyond the rhetoric there are concerns that I see raised over and over again. These concerns are nothing new. Almost three years ago, they were the inspiration for developing my presentation “Real World Groovy”. In that presentation, I raise concerns about introducing Groovy into a Java project and I address each concern by relating my own experience having worked with Java and Groovy on paid projects.

Burke describes four “nightmares” in his post. These nightmares are based on the assumption that introducing another programming language into a project

…..is just a big excuse so the developer can learn and play with a new language, or for a language zealot/missionary to figure out a way to weasel in his pet language into a company. Plus, you’d probably end up being average or good at many languages but a master of none.

Personally, I never had trouble sleeping when using Groovy and Java on the same project. In this series of blog posts, I’ll examine these nightmares one at time.

The “Maintenance Nightmare” concerns staffing and training. He describes the hypothetical situation that after the polyglot programmer has left the team,

…your group is a bunch of Java developers. For any bug that needs to be fixed, these developers need to be retrained in Ruby, a new Ruby developer needs to be hired, and/or a Ruby consultant/contractor needs to be brought it. Multiply this by each language you’ve introduced to your project.

Hypothetically, this group of Java developers won’t be able to read and update the code written in another language without training.

My experience is the exact opposite. The code written in Groovy was readable by the other developers on my team. No formal training was provided. The developers on my team were good, but they certainly weren’t language zealots. One had about 8 years of DB2 & Cobol with less than one year of Java experience. Another developer had 10+ years in VB and various SQL databases, as well as some Java. The subject matter experts were insurance actuaries with programming experience in PL-SQL and Foxpro. On our project, all of these people were able to write and maintain the Groovy code without formal training.

How is this possible? Groovy wasn’t added to the project because of some technical itch that needed scratching. The process of choosing an additional language involved taking a non-trivial piece of functionality and coding it in several languages, including Java. Each version was reviewed by those who would be developing and maintaining the new system. At that point in time, no one on the project had any experience with Groovy. If anything, there was prejudice against Groovy because of the uncertainty. Groovy was selected because it allowed us to easily express the algorithms and business logic in a way that reflected the business domain. The Groovy code was both concise and readable, with a very high signal-to-noise ratio.

Circling back to the maintenance concern, my experience has been that Groovy hasn’t made maintenance harder. In fact, it has made maintenance easier. Even with significant time passing between authoring and maintenance, the Groovy code has been easy to comprehend because it reflects the business domain. I try to write my Java code this way as well. However, Groovy doesn’t have a lot of ceremony around it, so it is accessible for developers with experience in other languages. My team did not struggle to decipher what was going on in a given piece of code because it was written in Groovy.

It is my experience that bugs can be resolved in minutes or hours that would have otherwise taken hours and days. The problems were solved quickly because those with domain expertise – my client’s developers and subject matter experts – could see at a glance what was wrong in the code. Note that none of this required them to be masters of Groovy. I have heard similar stories from others who had seen performance improvements rewriting C modules in Lisp or Smalltalk. The performance gains came because it was easier to implement logical efficiencies that just weren’t practical in C.

Based on what I’ve seen over the last 20+ years, technology issues are not what doom projects. I can’t tell you how many times I’ve heard developers say, “If the client could just decide what they want, I could build it. I just need to know what to build.” The hard part is getting systems to do what our client’s intend them to do. In order to bring a system into production, the team must be able to reason easily and quickly through the code to fix business logic errors.

In summary, the readability and expressiveness of languages like Groovy make maintenance of polyglot systems easier. There is less code to write and maintain and it is more readable. The benefit to less code isn’t in less effort typing at the keyboard. Rather, it is the ability to get one’s head around the various parts of the system. In addition, this enables a broader group of people with business expertise to be able to understand what the program is doing. All of this helps avoid creating a big ball of mud. Keeping the code easy to read and understand is the key to avoiding the “maintenance nightmare”.

In the next post, I’ll address the “Refactoring Nightmare”.