AC/DC Black Ice Tour: Atlanta

So my ears are still ringing even as I rock out to AC/DC at work. Last night AC/DC rocked Atlanta to a sold out crowd. The set list was the typical set list they've been playing in other cities. The concert started with a mini-movie segment of Angus driving a train, and two very slutty women come into the cab to derail the train. It's chocked full of not-so subtle innuendo and general male humor. Of course I'm not so sure why the women felt it necessary to try and stop the train. They looked like groupies so why they were stopping the train is unexplained. The overt sexual references and general absurdity of the piece had me laughing. Of course it ended in a huge on stage explosion and pyrotechnics display, a huge train smashes through the stage and out pops AC/DC playing their latest "Rock 'N Roll Train". It was an awesome entrance.

Then they followed it up a Bon Scott original "Hell Ain't A Bad Place To Be". While those are some my favorite AC/DC tunes. I really wanted them to play "It's a Long Way To the Top (If you wanna Rock 'N' Roll)", and Rock 'N' Roll Singer which are probably my favorites. Well that's not true I always have trouble choosing my favorites, but I do play those a lot.

Then they broke out "Back in Black" which I thought they played too early. This is their anthem get your damn hands up, but it definitely got the crowd going. It's hard to pick what they could have shuffled around because it's a solid set, but "Back in Black" is just such a powerful song it's got to be deeper in the set list.

Then "Big Jack" off their new album. Followed by "Dirty Deeds Done Dirt Cheap" followed by "Thunderstruck" which was my wife's favorite. I do have a warm spot in my heart for "Thunderstruck". Thank god her favorite wasn't "Dirty Deeds".

Then it was back to the new album for "Black Ice", and at this point I thought I'd have to go to the bathroom. But, I stuck it out, and was treated to another movie with "Warmachine". My favorite part was the parachuting women walking on the tank treads. Hilariously.

Then it was back to the hits with "Anything Goes" and "You Shook Me All Night Long" with a flaming model dancing on the screens. Cue the 5 ladies in the audience to jump up and start dancing. While a lot of AC/DC songs are about women I can tell you there aren't many who listen to it. Then it was into T.N.T. which rocked.

Other highlights of the night were Angus' guitar solo a top an elevated stage, and the gigantic inflatable Rosie that road the train during "Whole Lotta Rosie". Finally it was real cannon fire with "For Those About to Rock We Salute You". There was one long encore ending with "Highway to Hell" finishing the nite. I don't know if my ears could take anymore. It rocked them off.

Rails on IntelliJ

As I promised I'll give my verdict on Ruby on Rails with IntelliJ. First and foremost I haven't gone back to RadRails/Aptana Studio. I've been using IntelliJ's Ruby plugin now for 2 weeks I guess, and I still really like it. It's stable and very peppy. Much more so than Java editing I hate to say, but there aren't as many features in Rails plugin as main stay Java. Just the editor alone is so much nicer than Eclipse like hitting home goes to the beginning of your code on a line not the start of the first column. And, it doesn't just crash periodically like Eclipse does. Aptana Studio was really flaky. I've only shutdown IntelliJ to reboot my machine for Apple updates so it's very stable.

By in large it covers most of rails and ruby development. You get all the comforts of home with generator scripts. Just right click on your project > New > Controller and viola it runs the Rails generator creating all of the parts you'd expect: controller, it's helper, tests, controller's view and such. You have access to all the same generators you'd expect: Controller, Model, View, Migration, plain old ruby, etc. And it works just like you expect with IntelliJ.

One draw back is undo. It looks like they tried their best to support undo'ing a generator script, but all to often it gives up saying "Undo is too complex" or something like that.

Syntax highlighting is a go. Nothing really unexpected there. Controllers, Models, Views, and even YAML editor.

Code completion. Well it doesn't work that well in Aptana, and it's not too good in IntelliJ. I've gotten to the point where I just don't use it. I think if they were to try and make this work it would have to be some sort of smart guessing going on about what you're doing. But, in the end code completion just isn't going to work for dynamic languages. Oh well.

Refactor is going to be the same verdict as Code completion. It does support move, copy, rename, and migrate. But, these aren't the fire and forgot refactorings you love with Java. Always preview...always. Sorry that's just what you have to give up when working with agile dynamic languages.

Navigating between files is just as you'd expect it with Shift-N and Ctrl-Shift-N (Splat-N and Shift Splat N for mac users). They both work well, and I go back and forth between the class version, and the file version. The class version is going to work for Controllers, Models, Tests, and Migrations. The file version will work for views, and pretty everything else. It's a little weird having these different ways you have to use, but if you're an average IntelliJ user you won't even notice. It also still carries the "Include Java Files" check box when searching in Files. That should probably be removed.

There are two views I usually go between the normal Project view, and a special Rails view. When I do Java I never switched from Project view, but the special Rails view is really quite nice. It pulls all of your code together showing your controllers, model, and tests. Under models you can access your migrations right there which is very nice. It's always a pain to navigate to the DB folder to find your migrations. It also pulls in your public folder for direct access to static resources. But, it's strangely absent of views, and this is probably why I find myself switching back to the project view. You can't see your view files (rhtml,rxml) from the Rails view. This is something I'd really wish they'd fix. It just doesn't even make sense why they left that out.

You also have access to Rake tasks as well. Just right click on your project view > Rake. From there is a bunch of fold out menus to run Rake tasks. It's really nice to see all of the options you have. I'm always finding new tasks I didn't know I got for free. The ability to view all of the Rake tasks is very important given that the Rails geeks don't document very well. But, trying to right click then navigating all of those fold out menus is a futile exercise in mouse dexterity. I'd rather see a Rake view similar to the Ant and Maven docking views. That would be really sweet. Then I can just type portions of my rake tasks and quickly run them with the find feature just like I do with Ant.

I normally use the script/server inside my own terminal to run the rails server, but IntelliJ supports running the server inside the IDE. You have all your choices of Mongrel, WEBrick, and Lighttpd. You can run your server in the various environments, but you have to specify that in the server arguments field. You can save various versions (development, production, etc) as separate programs to run, and just swap between them in the drop down box. You can run Ruby scripts, Ruby tests, Rails server, and RSpec.

The thing I miss is the ability to run the script/console from within the IDE. I think you could make IntelliJ do this as it will run normal Ruby scripts. I tried, but it failed with an exception related to readline. It probably has something to do with the fact that I rebuilt ruby to include readline library, and IntelliJ just can't load it.

I think they could make this experience a little easier by pre-populating your project with Run configurations for Developer, Test, Production, and console. That would be a nice enhancement.

Finally, the coup de grace for RadRails is that the Rails Plugin comes packed with inline template completion (remember sout?). Think TextMate like editing! The best feature of TextMate is it's fast abbreviations for common tasks in Rails. Well IntelliJ users have nothing to covet. Type vc Ctrl-J and you get a validates_confirmation_of. Type rec = redirect_to with controller. Type rf = render file. There are tons of these. Although most are targeted at Ruby, but there are some rails specifics. I'd like to see more migration templates, but the good news is you can add them.

Overall IntelliJ's rails plugin covers everything you need. I'm not switching back to Aptana/RadRails period. I think there are somethings they can improve, but overall it's the same quality you have come to love from Java development with IntelliJ. It's really one of the best Rails environments available to you.

Location of the Ruby SDK and IntelliJ on Mac

I've been getting back into Rails development again, and I've been trying to find the right IDE to work in. I'm an IntelliJ fan, and I hate Eclipse. But, last time I was using Rails I used RadRails, and it was ok. However, now IntelliJ 7 has support for Rails development, and I thought I'd try it out.

First thing I ran into when I was configuring my project is setting up the Ruby SDK. Much like a Java project needs to know where the JDK home directory lives Ruby projects need to know where Ruby SDK lives. Only problem is on a Mac or Linux box those aren't so simple to find. I also had rebuilt Ruby so I could get readline support and installed it under /usr/local.

I tried /usr/local/lib/ruby that didn't work. I tried /usr/local/lib/ruby/1.8 that didn't work. Finally after stumbling around without any success I tried /usr/local and viola it worked.

If you didn't rebuild Ruby and are using the default Mac install. It would be /usr. Make sense? No not at all, but hopefully this blog post will help some peeps in the future.

Objects as Functions Part II: A lightweight web app validation utility

Binding and validation is something almost all web frameworks must have a solution for. Some are more elegant than others, but the problem with most of them is that they are tied specifically to the use of that framework. I've yet to see a reusable utility that is framework agnostic for handling this. This is another take on Objects as Functions post I did a while back. Only now I'm applying it to binding and valiation for the web. The results are usable by any Java developer using any framework they want. Creating yet another idea "From Frameworks to Object Oriented Utilities."

I had some code that I had written a while back where I coded the binding and validation by hand. In other words it was just a bunch of if else statement ladders. It resembled something like the following:

setEmail( request.getParameter("email") );

List<String> errors = new ArrayList<String>();

if( isNotSpecified( getEmail() ) ) {
  errors.add("Email is missing.");
} else if( isNotSpecified( confirmEmail ) ) {
  errors.add("Confirm email is missing.");
} else if( validateEmailFormat( getEmail() ) ) {
  errors.add("Email address provided is not a valid.");
} else if( validateEmailFormat( confirmEmail ) ) {
  errors.add("Confirm Email address provided is not a valid.");
} else if( !confirmEmail.equals( getEmail() ) ) {
  errors.add("Email and Confirm Email did not match.");
}

return errors;

Ok so yikes! I just like jumped back 10 years by writing code like that! But, I did it because I was in a situation where the "architect" hadn't really thought about these problems, and hadn't picked a framework that gave us that ability. So most people weren't doing any validation, and very poor binding. Think Vietnam of web apps here.

So after I wrote this code once I knew I needed something better, but it wasn't until I was about to write it again that I decided to go back and try to refactor out the common code into a utility to make my job easier that I came up with a general solution. If you'll notice in that code above there are some handy instance methods I created in this class to help specifying the validation language. So I started pulling those common methods out into a separate class. I'll spare you the details of the refactoring for another blog post. I'll start with some simple examples:

public List<String> validateAndBind( RequestValidater validater ) {
   setFirstName( validater.param("firstName").require().toValue() );
   return validater.getErrors();
}

This first example simply validates that the parameter "firstName" was specified in the request, fetches that value, and binds it into the instance object using a setter method. You'll notice there is no reflection taking place here. I'm a huge fan of reflection, but I think you'll see that this is so easy you actually don't need it. Remember that even in reflective frameworks you have to specify the validation rules, and specifying the binding (i.e. making you call the setter method by hand) isn't really where all the hard work is.

Going into detail on what this does. The first step requests the "firstName" parameter from the validater object. Then it calls the require() method on it. This methods checks to see if the parameter is present if not it adds a default error message. The RequestValidater object keeps track of all the errors it encounters while executing the validation rules. Finally toValue() method returns that parameter's value as a String passing it to the object's setter method. If the value isn't present it simply returns null.

In this simple example, if firstName parameter was missing then it would create an error message like: "First Name is missing". Because the parameter used camel case (i.e. firstName) the validater can infer a display name from that by breaking apart the parameter's name on the capital letter boundaries. So "firstName" would become "First Name". You can override this by supplying a second parameter to the param() method. Like:

  setFirstName( validater.param("firstName", "First name").require().toValue() );

It will also infer using underscores as well (i.e. "first_name" = "First Name"). It's better to accept the default since it's less work, but realize that you can customize it if you so wish. The second way is to supply an actual error message in the require() method as a parameter. While this might be necessary sometimes, particularly with the matches() method, it's usually best to accept the defaults.

Here's another example that validates and binds a date object.

public List<String> validateBindings( RequestValidater validater ) {
   setBirthDate( validater.param("birthDate").require().toDate() );

   return validater.getErrors();
}

The key difference in this example is the call to toDate() rather than toValue(). The to*() methods convert strings into other values like integer, dates, etc. These methods will usually end the validation rule methods. You can also pass a default value into the to*() methods to provide a default date, integer, etc. Of course you wouldn't do that with a require() validation rule provided.

Here is a couple more examples:

public List<String> validateBindings( RequestValidater validater ) {
   setUsername( validater.param("username").require().between( 5, 30).toValue() );
   setEmail( validater.param("email").require().validateEmail().equals( validater.param("confirmEmail") );

   return validater.getErrors();
}

This example we see some more methods for performing validations. The between() method is used to validate a parameter's length is between the two values. If not it adds an error message. You can see in the email example. Two methods validateEmail() which makes sure the value conforms to an email address, and the equals method which tests to see if the value matches some other value. In this example you can see how the validater.param("confirmEmail") can be used again to refer to another parameter in the request.

Finally, there's a matches() method for making sure parameters conform to a regular expression. Here is an example of that:

public List<String> validateAndBind( RequestValidater validater ) {

   Pattern phoneNumber = Pattern.compile("\\(?\\d\\d\\d\\)?(-|\\s)\\d\\d\\d(-|\\s)\\d\\d\\d\\d");

   setPhonNumber( validater
      .param("phoneNumber")
      .require().matches( phoneNumber, "Phone Number provided does not look like a phone number.")
      .toValue() );

   return validater.getErrors();
}

Here's how you can use the RequestValidater in your controllers:

  MyObject obj = new MyObject();
  List<Errors> errors = obj.validateBindings( new RequestValidater( request ) );
  if( errors.isEmpty() ) {
     // no errors means the user's request was valid
  } else {
     // we have some errors so send them back with the form data.
  }

After I finished writing this utility I went back and refactored by code to use it. I had something like 100-150 lines of validation code that I reduced to a simple 8 lines of code. Actually I added some new lines and formatting between some of the chained method calls which inflated it to like 25 lines, but still that's an amazing amount of code reduction. And, that doesn't include the lines I would've written to do validation in the second object.

This is yet another example of how you can use Objects in Java as functions to really change how you can reuse code. Notice that I didn't create some static method utility class to do this because there was state being kept and managed inside RequestValidater for me. If I had a static method I'd have to keep track of the state for me. Even the error messages can be standardized across my entire app by using this class. Also notice that the fact I'm using binding and validating against HttpServletRequest is hidden from my model objects. This is another great example of how encapsulation hides the details of the system from my model objects. Something static utilties can't do for me. Why is this important? Well I didn't go into it, but I also made changes to the RequestValidater such that it's easy to use in unit tests by just instantiating it with a HashMap of parameters. That makes it really easy to automate your validation testing because your model object's aren't bound to the HttpServletRequest interface. Without using encapsulation it wouldn't have been that easy to reuse RequestValidater in a different context. You can see an example in the main method included in the source of how to reuse it in unit tests.

Finally, my last thought on this is that it's a single class. There is no framework you have to adopt to use this code. Java has many choices when it comes to web frameworks. It's both a blessing and a curse, but the reality of the matter is most people are using Struts! Yuck! Why continue to build code that no one else can use? This marks the time when we need to move away from frameworks and to utilities.

Now here's the source:

package com.cci.web.validation;

import javax.servlet.http.HttpServletRequest;
import java.text.ParseException;
import java.text.SimpleDateFormat;
import java.util.*;
import java.util.regex.Pattern;

public class RequestValidater {
    private HttpServletRequest request;
    private Map<String,String> params;
    private List<String> errors = new ArrayList<String>();

    public RequestValidater(HttpServletRequest request) {
        this.request = request;
    }

    public RequestValidater( Map<String,String> params ) {
        this.params = params;
    }

    public boolean hasErrors() {
        return !errors.isEmpty();
    }

    public List<String> getErrors() {
        return errors;
    }

    public Parameter param( String name ) {
        return new Parameter( name );
    }

    public Parameter param( String name, String displayName ) {
        return new Parameter( name, displayName );
    }

    protected String getParameter( String name ) {
        if( request != null ) {
            return request.getParameter(name);
        } else {
            return params.get(name);
        }
    }

    public class Parameter {
        private String displayName;
        private String name;
        private String value;

        public Parameter(String name) {
            this.name = name;
            this.displayName = convertToDisplay( name );
            this.value = getParameter(name);
        }

        public Parameter(String name, String displayName) {
            this.name = name;
            this.displayName = displayName;
            this.value = getParameter(name);
        }

        private String convertToDisplay(String camelCase) {
            StringBuilder builder = new StringBuilder();
            if( !camelCase.contains("_") ) {
                builder.append( Character.toTitleCase( camelCase.charAt(0) ) );
                for( int i = 1; i < camelCase.length(); i++ ) {
                    char next = camelCase.charAt(i);

                    if(Character.isUpperCase( next ) ) {
                        builder.append( ' ' );
                    }
                    builder.append( next );
                }
            } else {
                String[] words = camelCase.split("_");
                for( String word : words ) {
                    builder.append( Character.toUpperCase( word.charAt(0) ) );
                    builder.append( word.subSequence( 1, word.length() ) );
                }
            }
            return builder.toString();
        }

        public Parameter require() {
            return require( displayName + " is missing." );
        }

        public Parameter require(String error ) {
            if( name == null || name.length() < 1 ) {
                errors.add( error );
            }
            return this;
        }

        public Parameter between( int minSize, int maxSize ) {
            return between( minSize, maxSize, displayName + " must be at least " + minSize + " characters, but no more than " + maxSize + " characters.");
        }

        public Parameter between( int minSize, int maxSize, String error ) {
            if( value == null ) return this;

            if( value.length() < minSize || value.length() > maxSize ) {
                errors.add( error );
            }
            return this;
        }

        public Parameter matches( Pattern pattern, String error ) {
            if( value == null ) return this;

            if( !pattern.matcher( value ).matches() ) {
                errors.add( error );
            }
            return this;
        }

        public Parameter validateAsEmail() {
            if( value == null ) return this;

            if( !value.matches("(\\w|\\.)+@\\w+\\.\\w+(\\.\\w+)*") ) {
                errors.add( value + " is not a valid email address.");
            }
            return this;
        }

        public Parameter equals( Parameter param ) {
            return equals( param.value, displayName + " does not match " + param.displayName + "." );
        }

        public Parameter equals( String aValue, String error ) {
            if( value == null ) return this;

            if( !value.equals( aValue ) ) {
                errors.add( error );
            }
            return this;
        }

        public Date toDate() {
            return toDate( "MM/dd/yyyy");
        }

        public Date toDate( String datePattern ) {
            return toDate( datePattern, value + " is not a valid date. (" + datePattern + ")" );
        }

        public Date toDate( String datePattern, String error ) {
            if( value == null ) return null;

            try {
                SimpleDateFormat dateFormat = new SimpleDateFormat( datePattern );
                return dateFormat.parse( value );
            } catch( ParseException pex ) {
                errors.add( error );
                return null;
            }
        }

        public Integer toInt() {
            return toInt( (Integer)null );
        }

        public Integer toInt( Integer defaultVal ) {
            return toInt( displayName + " must be a number without a decimal point.", defaultVal );
        }

        public Integer toInt( String error ) {
            return toInt( error, null );
        }

        public Integer toInt( String error, Integer defaultValue ) {
            if( value == null ) return defaultValue;

            try {
                return Integer.parseInt( value );
            } catch( NumberFormatException nex ) {
                errors.add( error );
                return null;
            }
        }

        public String toValue() {
            return value;
        }

        public String toValue( String defaultValue ) {
            return value != null ? value : defaultValue;
        }
    }

    public static void main(String[] args) {
        Map<String,String> params = new HashMap<String,String>();
        params.put("email", "jep1957@mindspring.com" );
        params.put("email1", "this.email@bad" );
        params.put("email2", "my address@bad.com" );

        validateThese( "jep1957@mindspring.com", "charlie.hubbard@coreconcept.com", "this.email@bad", "my address@bad.com", "bad@bad@bad@bad", "hiya", "foo.bar" );
    }

    private static void validateThese( String... emails ) {
        for( String email : emails ) {
            Map<String,String> params = new HashMap<String,String>();
            params.put("email", email );

            RequestValidater validater = new RequestValidater( params );
            String val = validater.param("email").validateAsEmail().toValue();
            System.out.println( val + " was " + ( validater.hasErrors() ? "not valid!" : "valid" ) );
        }
    }
}

Life without Getters and Setters

Over at Stephan's Blog he mentioned an idea that I had the other day as well. Back when Java Beans came around the getter and setter notation was a convention to help frameworks determine what the properties of an object were. But, now that we have annotations why, other than legacy reasons, would we continue to use them? Just annotate the method with @Get, @Set, or @Property.

The cool thing is that if legacy frameworks used java.bean.Inspector class, you could encapsulate the new fangled annotation style properties inside it, and old frameworks wouldn't need to know that it changed.

This would get us closer to something I'd like in Java 7. Uniform Access Principle. No more would we need to write getter and setters. It's actually a feature that wouldn't harm the language, and you could turn it off with annotations if you had a need. The cool thing about it is that it's completely compiler driven. No language changes. Maybe if we can't get agreement on closures how about this for Java 7?

Objects as Functions

I've been wanting to write this post for sometime now. It just takes my so long to write a post, usually because of their length, that I don't do it as frequently as I should. I promised more articles in my last post so here we go.

Over the last couple of years I've been learning other languages particularly Javascript and Ruby. I really like Javascript as a language, API could use some help. I love Ruby's style of meta-programming and the fact that everything is an object. What I'm really jealous is how powerful a single function in these languages can be. For example in javascript it's easy to create widgets with Ext.js:

var button = new Ext.Button( 'okButton', { 
                                text: "OK", 
                                click: function( evt ) {
                                   alert("Hey!");
                                }, 
                                "class": "myCssClass" 
                              } );

In Swing this would be 25 lines of setter methods to customize components (OK maybe I'm exaggerating a little). Or in Ruby active record is just so simple and elegant with things like:

   books = Book.find( :all, :condition => [ "where pubdate > ?", pubDate ], :include => [ :tags, :comments ] )

The ability to hand in optional arguments regardless of position turns simple functions into really expressive mini languages. Dare I say DSLs. I really miss these features when I have to use Java. Since Java opted for the C++ route of data structures. Data structures live in the API, and not the language, it's difficult for us to mimic this type of power.

I remember reading the Javascript Bible several years ago, and in there is a chapter titled "Functions as Data". And, the author is trying to show how functions can be assigned to variables, and passed around the system such one part of the program is unaware of which exact function it's calling. He's trying break the stereotype of functions being just actions, and show you how functions can be data as well. It's a good chapter for any developer.

This got me thinking about stereotypes we have about other languages. In Java we, all too often, get stuck thinking of our objects as largely data with some marginal functions mashed in to manipulate or manage that data. We usually create huge single instance, infinite lifetime objects that then do all the heavy lifting. However, what if we created objects that lived really only for a small period of time just to perform small functions? In fact what if we took what we would normally write as a function and turned it into an object. How would that change what we could express?

Now we need a problem to practice our idea on. Let's say we want to build a simple email utility because I think everyone who has worked on a web application in the past has had to send out email. For example, say we want to send an email from the site when people register to welcome them to the system, or when they forget their password. And, as you know Javamail, while a pretty good general purpose API, is very verbose to use. So let's say we create some utility method for sending email:

public MailHelper {
   public static MimeMessage createEmail( String to, String from, String subject, String template ) {
   }
}

The idea of this method is that we give it the to, from, subject, and a template file to use for the body, and it returns a MimeMessage, which is a Javamail class. It's basically an object representing an email. The template is either a Velocity or Freemarker template. I'm going to use Velocity in this example. If you're not familiar with these libraries they're really simple. They take in text like:

Hi $name,

Welcome to my cool new website.  Thanks for taking the time to register with us.  We're so glad to call you a member.  Here is your password: $password in case you forgot, and here are some great places to get started $interestingPlace.

Thanks

The Man

And replace all of the "$" references with something you assign to them. So in your program you might say "name"="Charlie", and "password"="wouldnt you like to know", and "interestingPlace"="Tahiti". If you've used properties in Ant it's really a similar concept. It's not rocket science.

Now back to our utility. The problem with our utility is that we need a way to set all of those interesting variables that we'll substitute into our template. But, how do we do that with our single static method?

In Javascript or Ruby they might just pass a hash map like:

function createEmail( to, from, subject, template, bindings ) {
   bindings = bindings || {};  // these notation is used for optional arguments.
}

What's cool about the function above is that if you don't have any bindings, just don't include it. Javascript doesn't require you pass all of the arguments to the function so the first line just happily sets bindings to empty object if they aren't specified.

So if we copy this in Java we'd add a HashMap onto our arguments:

public MailHelper {
   public static MimeMessage createEmail( String to, String from, String subject, String template, Map bindings ) {
   }
}

Then our usage would be something like:

public static void main( String args[] ) {

   Map bindings = new HashMap();
   bindings.put("name", "Unsuspecting Luser");
   bindings.put("password", "wouldnt you like to know" );
   bindings.put("interestingPlaces", "Tahiti" );

   MimeMessage message = MailHelper.createEmail( "ycnangerp1@hotmail.com", "kevben@coldmail.ca", "Hello New Member", "email.vm", bindings );
}

Now I don't know about you, but that kinda code drives me nuts. It's so verbose, and
boring! The Javascript and Ruby versions of this are so much more fun. Now what if we wanted to add some attachments, CC some people, or add HTML and text versions of the email? Our poor little static function just can't hang. What we need is something better.

If you're still not convinced that statics aren't up for this consider that I'm leaving out some very important architecture here. Particularly, I need a VelocityEngine instance inside the static function in order to evaluate the template. Now I have to make a choice. One I make a simplifying assumption that I only need one instance of VelcoityEngine and initialize it in the static utility. That would mean I give up on the ability to have multiple template locations, or mail servers, etc. This would make it hard to unit test. It also makes reusing this utility harder because everything is hardcoded structurally. And, singleton's don't help this! The other choice is force the user to manage of the data this static utility needs, but I think that would compromise the ease and usefulness of the utility. Kinda of like well geez if you're going to make me do all of that I might as well just do it myself. Both of them get us into ugly Java.

What if we take our function and turn it into an object? I'm going to approach this from the outside interface, and then show the implementation:

public static void main( String[] args ) {

   Emailer emailer = new Emailer();

   MimeMessage mime = emailer.email("ycnangerp1@hotmail.com", "Hello New Member", "email.vm" )
           .bind( "name", "Bad Spammer" )
           .bind("password", "wouldnt you like to know")
           .bind("interestingPlaces", "Hell" )
           .toMail();
}

Look at that! Much easier to use. Notice how I don't have to create a seperate HashMap. Our new object provides this for us so binding is completely optional. If the email you're sending doesn't have any bindings then just don't call the bind() method. Also notice that emailer instance has a email() method to create an email. It almost reads like English. It also scales nicely for other types of data like attachments, or CC'ing:

public static void main( String[] args ) {

   Emailer emailer = new Emailer();

   MimeMessage mime = emailer.email("ycnangerp1@hotmail.com", "Hello New Member", "email.vm" )
           .bind( "name", "Unsuspecting Luser" )
           .bind("password", "wouldnt you like to know")
           .bind("interestingPlaces", "Tahiti" )
           .cc( "manager@spambot.com" )
           .attach( stockHypeImage )
           .toMail();
}

I'm using email addresses of known spammers to increase the chances spam bots will pick them up and blast emails at them.

If you'll notice I moved one parameter out from the first function: the from parameter. I'll add this back in at a later point in time. You'll also notice the toMail() method. Since we're making multiple calls we'll need a function to end the transaction or kick off the action. I'm going to enhance the version of the code below to also send the email instead of just creating it. I'm not going to implement the toMail() method since sending is the ultimate goal. So now let's look at the code for implementing this kinda class:

public class Emailer {

    private static final Logger logger = Logger.getLogger(Emailer.class);

    private String from;
    private String url;
    private Properties mailProperties;
    private VelocityEngine engine;

    public Emailer( VelocityEngine anEngine, Properties mailProps, String from, String url ) {
        this.engine = anEngine;
        this.mailProperties = mailProps;
        this.from = from;
        this.url = url;
    }

    public Email email( String to, String subject, String mailTemplate ) {
        return new Email( to, subject, mailTemplate );
    }

    public Email email( String to, String subject, String mailTemplate, String htmlTemplate ) {
        return new Email( to, subject, mailTemplate, htmlTemplate );
    }

    public class Email {
        private String to;
        private String subject;
        private String textTemplate;
        private String htmlTemplate;
        private Map params;

        private Email() {
            this.params = new HashMap();
            if( url != null ) {
                this.params.put("website", url);
            }
        }

        public Email(String to, String subject, String textTemplate) {
            this();
            this.to = to;
            this.subject = subject;
            this.textTemplate = textTemplate;
        }

        public Email(String to, String subject, String textTemplate, String htmlTemplate) {
            this();
            this.to = to;
            this.subject = subject;
            this.textTemplate = textTemplate;
            this.htmlTemplate = htmlTemplate;
        }

        public Email bind( String key, Object obj ) {
            params.put( key, obj );
            return this;
        }

        public void send() {
            try {
                Session session = Session.getInstance( mailProperties );
                MimeMessage message = new MimeMessage( session );

                message.setRecipient( MimeMessage.RecipientType.TO, new InternetAddress( to ) );
                message.setFrom( new InternetAddress( from ) );
                message.setSubject( subject );

                if( htmlTemplate == null ) {
                    message.setText( renderTemplate( textTemplate ) );
                } else {
                    String text = renderTemplate( textTemplate );
                    String html = renderTemplate( htmlTemplate );

                    MimeMultipart part = new MimeMultipart("alternative");
                    part.addBodyPart( createBody( text,"text/plain") );
                    part.addBodyPart( createBody( html,"text/html") );

                    message.setContent( part );
                }
                message.saveChanges();

                Transport transport = session.getTransport("smtp");
                transport.connect();
                transport.sendMessage( message, message.getAllRecipients() );
                transport.close();
            } catch( Exception mex ) {
                logger.error( "There was an problem emailing: " + subject + " to: " + to, mex ); 
            }
        }

        private BodyPart createBody(String text, String mimetype) throws MessagingException {
            MimeBodyPart body = new MimeBodyPart();
            body.setContent( text, mimetype );
            return body;
        }

        private String renderTemplate( String template ) throws Exception {
            StringWriter writer = new StringWriter();

            Template tmpl = engine.getTemplate( template );
            VelocityContext context = new VelocityContext( params );
            tmpl.merge( context, writer );
            return writer.toString();
        }
    }
}

The two interesting methods are the Emailer.email() methods. The two versions are for sending text only emails, or multipart HTML emails. At the start it's really quite simple. Invoking email() creates an Email instance which is an inner class for the Emailer. At that point you can call bind() method for every object you want to bind into the template. Notice how bind() returns the Email instance allowing you to chain method calls. Finally once you're done call send() to actually send the email. This was something that you couldn't do with the static method. For one it was too complex to configure through a single method call, and you're static method would have to have access to java properties, velocity engine, etc. By limiting our interaction to statics we force our users to take on more responsibilities. In the static case the user has to use some other utility to send the email. Either we have to force user to manage the architecture by gathering up the velocity engine instance, java mail properties, etc. Or we hard code it with statics in such that our tool will only work for a single velocity engine, from, and java mail properties. Neither is very helpful. One doesn't do enough to make it helpful, and the other limits our architecture and impacts how we can reuse it.

The Emailer class is also split into two parts. The outer class which holds all of the architectural/configuration items (velocity engine, java mail properties, etc). By splitting the code this way those portions can be configured at some place else in the code, say at application initialization, and the parts of the code that need to send email can be blissfully unaware of the architecture used to do so. This outer class acts as the glue between the java mail settings, velocity engine, and simple data like the email address of the author. It's really similar to functional language technique of currying functions.

The second part is the inner class Email. Using an inner classes allows us to create an instance that holds temporary state (i.e. bindings, the template for a specific email, to, subject, etc), but still has access to long living state (i.e. mail host, properties, velocity engine, etc). If we mixed the two inside the Emailer class we couldn't share that across multiple threads. Notice there's no setter methods on Emailer. That means once the Emailer is created other threads can't modify the internal state of it. It's immutable so it's safe to share the Emailer across multiple threads. This pattern allows Emailer to be shared, while Email instances only live on the stack of each Thread. There by separating data being written to (i.e. specifics for sending a single email) from the data that's not changing (i.e. the architecture of sending emails). Safety without synchronizing!

Notice how what started out as our verb function, createEmail(), and turned into a Noun, Email, that acted like a verb. That's usually what happens when you move from static utility methods to active function Object. For lack of a better term.

What's cool about this approach is our Emailer class acts more like a complex function like we saw in Javascript and Ruby. In a single line we easily send an email that requires potentially complex optional data. In addition it allows clients of this class to focus only on sending email, and not worry about the details of how that email is actually sent. Since we're in Java our function Object can tell the user all the options you can call on it with our IDE's code completion feature. Something Ruby and Javascript can't do reliably enough to be useful. With those scripting languages you're relying on the documentation to tell you the specific options of the function.

This pattern in Java looks more like Smalltalk to me. Your functions can end up looking very english-like. By using method chaining and inner classes we can get the same power without having to sacrifice the compact, expressiveness of functions we enjoyed with Javascript and Ruby. Not only did we improve the code's reusability, but we delivered more features by switching from static method to function object. We went from just being able to create the email to actually creating and sending it using objects as functions. In the end, we can now create very powerful single line "functions" just like those scripting languages by using the one construct Java does well. Objects.

Now as I promised da code. This example create a sub directory called templates under your current working directory, and put a test.vm template in there. Copy the template text above, and it will work:

package mail;

import org.apache.log4j.Logger;
import org.apache.velocity.app.VelocityEngine;
import org.apache.velocity.VelocityContext;
import org.apache.velocity.Template;

import javax.mail.*;
import javax.mail.internet.MimeBodyPart;
import javax.mail.internet.MimeMessage;
import javax.mail.internet.MimeMultipart;
import javax.mail.internet.InternetAddress;
import java.util.HashMap;
import java.util.Map;
import java.util.Properties;
import java.io.StringWriter;

public class Emailer {

    private static final Logger logger = Logger.getLogger(Emailer.class);

    private String from;
    private Properties mailProperties;
    private VelocityEngine engine;

    protected Emailer() {
    }

    public Emailer(VelocityEngine engine, Properties mailProperties, String from) {
        this.engine = engine;
        this.mailProperties = mailProperties;
        this.from = from;
    }

    public Email email( String to, String subject, String mailTemplate ) {
        return new Email( to, subject, mailTemplate );
    }

    public Email email( String to, String subject, String mailTemplate, String htmlTemplate ) {
        return new Email( to, subject, mailTemplate, htmlTemplate );
    }

    public class Email {
        private String to;
        private String subject;
        private String textTemplate;
        private String htmlTemplate;
        private Map params;

        private Email() {
            this.params = new HashMap();
        }

        public Email(String to, String subject, String textTemplate) {
            this();
            this.to = to;
            this.subject = subject;
            this.textTemplate = textTemplate;
        }

        public Email(String to, String subject, String textTemplate, String htmlTemplate) {
            this();
            this.to = to;
            this.subject = subject;
            this.textTemplate = textTemplate;
            this.htmlTemplate = htmlTemplate;
        }

        public Email bind( String key, Object obj ) {
            params.put( key, obj );
            return this;
        }

        public void send() {
            try {
                Session session = Session.getInstance( mailProperties );
                MimeMessage message = new MimeMessage( session );

                message.setRecipient( MimeMessage.RecipientType.TO, new InternetAddress( to ) );
                message.setFrom( new InternetAddress( from ) );
                message.setSubject( subject );

                if( htmlTemplate == null ) {
                    message.setText( renderTemplate( textTemplate ) );
                } else {
                    String text = renderTemplate( textTemplate );
                    String html = renderTemplate( htmlTemplate );

                    MimeMultipart part = new MimeMultipart("alternative");
                    part.addBodyPart( createBody( text,"text/plain") );
                    part.addBodyPart( createBody( html,"text/html") );

                    message.setContent( part );
                }
                message.saveChanges();

                Transport transport = session.getTransport("smtp");
                transport.connect();
                transport.sendMessage( message, message.getAllRecipients() );
                transport.close();
            } catch( Exception mex ) {
                logger.error( "There was an problem emailing: " + subject + " to: " + to, mex ); 
            }
        }

        private BodyPart createBody(String text, String mimetype) throws MessagingException {
            MimeBodyPart body = new MimeBodyPart();
            body.setContent( text, mimetype );
            return body;
        }

        private String renderTemplate( String template ) throws Exception {
            StringWriter writer = new StringWriter();

            Template tmpl = engine.getTemplate( template );
            VelocityContext context = new VelocityContext( params );
            tmpl.merge( context, writer );
            return writer.toString();
        }
    }

    public static void main(String[] args) throws Exception {
        Properties p = new Properties();
        p.setProperty("file.resource.loader.path", "./templates");

        VelocityEngine engine = new VelocityEngine( p );
        engine.init();

        String from = "author@yourcompany.com";

        Properties javamailProps = new Properties();
        javamailProps.setProperty("mail.host", "!YOUR_MAIL_HOST");
        javamailProps.setProperty("mail.user", "!YOUR_MAIL_USER");
        javamailProps.setProperty("mail.password", "!YOUR_MAIL_PASSWORD");
        javamailProps.setProperty("mail.port","25");

        Emailer emailer = new Emailer( engine, javamailProps, from );

        emailer.email("person@somedomain.com", "This is a test", "test.vm")
                .bind("name", "Chuck")
                .bind("password","KutzMutz")
                .bind("interestingPlaces","Tahiti")
                .send();
        System.out.println("Email sent!");
    }
}

You don't know Jack about Objects!

I have been conducting phone interviews over the last few days, and I feel less positive about the computer programmers out there. Every candidate out there has Object Oriented Design on their resume in spite of the fact they can't define polymorphism or worse encapsulation! If you can't define polymorphism or encapsulation without resorting to examples then you can't write Object Oriented Design as one your skills. You don't even know what object oriented is!

The world is full of what I term imperatives. Essentially, it's the style of code you in most imperative languages like Fortran, C/C++, and sometimes Perl (well that's if you actually understand someone else's Perl). Object oriented programming is a total shift in the way you think. It's not just a language, and to effectively use it well, you have to see others using it effectively. And, that's so hard because so much code out there is imperative at its core.

Loads of static utilities classes, singletons, and objects with only getters/setters on it litter the landscape of the mainstream. If you've ever written an entity object with only getter/setters then each entity has a companion manager class voila that's how imperatives roll. What's the big deal? The big deal is you're not getting the benefits of true OO. I recently re-read the white XP book, and in there Kent Beck talks about the cost of change, and while you don't need object orient languages to lower the cost of change. "However, in my experience the cost of change rises more steeply without objects than with objects." This has been my experience too. Object oriented languages keep the cost of change lower than other imperative equivalents. But, only if you use them correctly. Now why would Kent say that?

He's referring to encapsulation, particularly the fact that certain parts of your program should not interact with each other. That's precisely what happens in object oriented programs. What makes changing programs hard, or worse scary, is the dependencies between parts of your program. It's easier to modify your program if your changes aren't going to affect some other unrelated part. Most people think of encapsulation as effective use of access modifiers like public, protected, and private. Access modifiers are the micro-level idea of encapsulation. There exists a macro-level version of encapsulation in how your objects communicate with each other. This macro level is more important than the micro level.

Object oriented languages typically work by calling methods on instances. That means if you don't have a reference to an instance then you can't invoke methods on that object. This fact forms the basis for the macro-level concept of encapsulation. It's all about these references between objects. This macro level encapsulation more commonly referred to as architecture. A great example of this form of encapsulation is the MVC pattern.

How does the MVC model help with maintenance? Well I think it comes from understanding how to make effective reuse of your code. According to the MVC pattern Views should be empty shells waiting to be filled. Void of any business logic. Controllers responsibilities are interacting with the model, choosing which view should be rendered, and binding the model to the view. The interesting part of this pattern is that model objects are used by the view, and the controller. It's this property that makes the model so important because it's the one portion of the system that can be accessed from any other part of the program without increasing your cost of change.

Here is an example that I recently had. I had two Controllers that were serving up thumbnails of movies, and pictures. Interestingly, I needed to stream the bytes of those images over the response. The one thing that's common between these two controllers is that they both use the Thumbnail object. Imperative systems you'll find some sort of ThumbnailUtil.send() method that will share between the Controllers to do this. Ugggh. So there is the duplication and separation that begins to creep into your system when you start programming in an imperative style in an object oriented language. It would be trivial to reuse that logic if it belonged to my Thumbnail object:

public ModelAndView handleRequest( HttpServletRequest request, HttpServletResponse response ) {
Thumbnail thumbnail = thubmbnailService.loadThumbnail( thumbnailId );
thumbnail.send( resposne.getOutputStream() );
return null;
}

It's that simple! For one you're using fewer classes. The send() method is accessible to any controller that can access a thumbnail. Your model objects should have behavior, and this really goes along with any language. I started getting this idea in Java, and I started to really crystallize when I was doing Ruby/Rails. You notice two things. It's easy to reuse logic, and quick to build functionality because after a while you build up a language that models your business logic. Things are now very high level uses of these basic pieces of business logic. This is exactly like Paul Graham's discusses in Programming Bottom-Up.

Another side effect of this is that it's easy to test. In Rails they went great lengths to try and test your model, controller and model, and full integration view, controller, and model. Notice how Rails doesn't try to separate Controller from model which I think is very practical approach. But, the first level of unit testing is testing the model alone. If you're business logic is pushed down into that level it's much easier to test it than if it's inside the controller. You don't need the model and the controller so there's less dependencies you have to initialize and setup in your test environment. The more logic you can test in your model, the more coverage your getting, and the more robust your application will be.

Another example I recently ran into of more static loving imperative code was called ViewUtil. Our application is based on SpringMVC so someone added a ViewUtil class for retrieving the ModelAndView object required by SpringMVC. There was several portions of logic included in there for retrieving XML based views vs. HTML depending on properties in the HTTP request. Here are what this might look like:

public ModelAndView handlRequest( HttpServletRequest request, HttpServletResponse ) {
Model model = modelService.getModel( ... );

ModelAndView mv = ViewUtil.getView( request, "modelview" ).addObject("model", model).addObject("someParam", request.getParam("someParam");
mv.addObject( "model", model );
mv.addObject( "someParam", request.getParameter("someParam");
mv.addObject("someOtherParam", request.getParameter("someOtherParam");
return mv;
}

However, there are other problems that pertain to Views that end up inside our controllers because of the choice of using statics. For example, quite often when errors on our forms occur we have to copy parameters from the request coming in onto the ModelAndView leaving. Particularly, hidden fields on the form that don't belong inside objects. One of the problems with statics is that you can call them from anywhere. Using getView() method really only belongs in the Controller since that's the responsibility of the Controller, and not anywhere else.

Here is a more object oriented approach. One we move this method to retrieve views into our Controllers in a common super class. That way only our controllers can call it.

public class ApplicationController extends AbstractController {

protected View getView( String viewName, HttpServletRequest request, HttpServletResponse response ) {
... // all of our existing logic inside ViewUtil goes here.

ModelAndView mv = new ModelAndView(...);
return new View( request, mv );
}
}

Notice how in this example I'm not actually returning the ModelAndView class as the ViewUtil does. The reason for this is we're going to add our behavior to that object thus giving it the illusion of behavior on our ModelAndView class. So here is an example of our View class:

public class View {
private ModelAndView view;
private HttpServletRequest request;

public View addObject( String key, Object obj ) {
view.addObject( key, obj );
return this;
}

public View copyParams( String... params ) {
for( String key : params ) {
view.addObject( key, request.getParameter( key ) );
}
return this;
}
}

So here we're exposing just two simple methods. One is a delegated method to the addObject() on ModelAndView. Notice that I didn't include getters or setters for the HttpServletRequest or the ModelAndView. That's because they aren't really needed if you have a View object. Whatever sorts of code I need to do that operates on either of those objects I will put in my View object, and simply call that from my Controllers. I could even go further and add a new method to my ApplicationController.doRequest() that returns a View object instead of ModelAndView then that way my subclasses don't need a View.getView() to satisfy the Spring MVC method, and leave that to my ApplicationController.

Now I've created a easier way to handle things like copy parameters from my request to my view, and I don't need yet another static method on ViewUtil or something like that I just have smart View object. This technique is really the same has doing currying in functional languages. Instead of creating a scoped function we're created a scoped object. What's amazing about this technique is it allows one part of the program to transfer knowledge of a section of subsystems without another part of your program having to understand details about that subsystem. It's like a specialized context for another part of the program that's highly tailored to the needs at a point of time for only a short time.

Now on some level you can argue that ModelAndView object should have the copyParams method on it. But, it's not practical to think the needs of every program could be anticipated by our framework developers. It would be too cumbersome and difficult to understand because you'd need to separate out what you need from what you don't.

This illustrates that when you really stop thinking in statics and start thinking in terms of objects opportunities, that would be too cumbersome and repetitive in imperative land, open up in object oriented land. Also notice how I didn't use inheritance to accomplish this. This is the power of composition, and delegation. Inheritance is useful, but most often abused. Composition is an easy technique to learn, but seldom do imperatives ever use it effectively.