Giant Classes

Yes, right there on line 2548 is where I think I need to add a hook in. Does that seem right to you?

— Developer asking a remote team about one of their many giant classes over WebEx.

Improving Legacy Code

I just really feel like I should do some cleaning up while I’m in there changing the code.

— A Developer Working on a Legacy Code Base

The rewards of management can take a long time to recognize, but I heard this gem a while back. The developer was bothered by the state of the legacy code he was working with and really wanted to do some cleanup. Usual issue–almost no tests in place, plenty of nasty EJB dependencies and hard to test. For now he’s doing simple refactorings like renaming variables, extracting methods, and just deleting old commented out code.

It can take a while to convince a developer that it’s worth the effort to do some cleanup when working with legacy code. Many times it seems overwhelming to bother with changes. It’s a mess and not worth fixing. Then they reach the point where they’re not willing to just deal with patching up the problem. Every time they touch the code they make small improvements. This is how you wrangle in a nasty legacy codebase and make it workable and maintainable for the long haul.

Taking the Leave Option

I posted a little while ago about IDE choice based on a developer having to use IntelliJ in secret because his shop mandated all developers must use Eclipse at all times. To avoid this sort of situation I pointed out that you should always have an automated build that has no IDE dependencies. Chances are if you have that no one can argue that you must use one particular IDE.

Then there’s the second option:

Then there’s the shops that believe everything must be standardized. Avoid these standardization-happy shops.

Apparently the developer went with the second option and is looking to be successful elsewhere.

Struts Still Dominant

Struts is beating down the JSF challenge at least according to the metrics(comparing downloads can be a spotty exercise) Matt Raible comes up with for downloads:

  • Struts: ~340,000 per month
  • Spring: ~80,000 per month
  • Hibernate: ~80,000 per month
  • MyFaces: ~12,000 per month
  • Tapesty: ~12,000 per month
  • Wicket: ~10,000 per month

Comparing downloads can be a spotty exercise, but Matt summarizes:

Sorry JSF, you appear to be losing. Badly.

I’m still scratching my head a little. I”m not raving fan of JSF, but anecdotal evidence that I’ve seen is that about 30-40% of the shops I hear about in our region are using JSF. JSF backlash is common, but since it’s part of the J2EE spec corporate shops just migrated over to it. JSF promises a shining component castle on the hill to corporate IT.

I’m favoring Wicket in the Java web frameworks, but we’re still a JSF shop in the office with some support for legacy classic Struts projects. The Ruby world is so easy, one major web framework.

Fixing Issue with JRuby 1.0 and Rails

In seeing if my post on installing Deploying Rails to Tomcat as a WAR I came across an issue with running rails under JRuby 1.0 and ActiveRecord-JDBC 0.4.

First off you still have to run the following command because the rails script file is still not set to be executable:

chmod 775 $JRUBY_HOME/bin/rails

In addition I had to change the top shebang line of the script after I got this error:

rails --version
/Applications/jruby-1.0/bin/rails: line 9: require: command not found
/Applications/jruby-1.0/bin/rails: line 10: version: command not found
/Applications/jruby-1.0/bin/rails: line 11: syntax error near unexpected token `('
/Applications/jruby-1.0/bin/rails: line 11: `if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct?
$ rails --version
/Applications/jruby-1.0/bin/rails: line 9: require: command not found
/Applications/jruby-1.0/bin/rails: line 10: version: command not found
/Applications/jruby-1.0/bin/rails: line 11: syntax error near unexpected token `('
/Applications/jruby-1.0/bin/rails: line 11: `if ARGV.first =~ /^_(.*)_$/ and Gem::Version.correct? $1 then'

I found the fix here, but you just change the top shebang line from:



#!/usr/bin/env jruby