At a previous position, I was a big fan of using the Maven Jetty Plugin to develop web apps, particularly when I was working on JSPs that needed some tweaking for different browsers. The main drawback to this approach was that using the plugin for multiple applications was cumbersome and the documentation (at the time) wasn’t that great.

For the last few months, I’ve been doing all of my development through Intellij and Tomcat using a Run/Debug configuration for the app, and I didn’t hit a snag, until yesterday.

One of the big perks of using the Run/Debug configuration is the availability of the “Reload classes and resources” function when you make a change. Selecting this option gets you near-Jetty speed when you want to make changes to classes or JSPs and see those changes reflected immediately. There are a few caviats though. You will still need to restart the container if you:

• change a method signature
• add a class
• rename a class
• change your Spring context

However, if you are changing the inner workings of a method or altering a JSP, a class/resource reload will reflect your change almost instantly.

The important gotcha that I found today, is that this option is only available if all the applications running your container are running exploded, which isn’t a big deal if you only run one app, but when you run 7 it can be an issue. If any of your apps aren’t exploded, you will see a different option, “Hot Swap”, which, from what I can tell, is about the same as a complete restart from a performance perspective.

I made the mistake of selecting one of my wars, rather than the exploded version of the war, and got bit until I double checked my app configuration. Hope this saves you some pain.

Mockito provides mechanisms for mocking most of the stuff you need, but remains mysteriously silent on constructor mocking. “Newing up” an object when you are mocking in your unit tests is a pain, and I often found myself writing tiny factories to isolate where I was using a constructor.

For example, to test the following code…

1
2
3
4
5
6
7

public class Helper {
 
  public void doSomething(String arg){
      new Something(arg).doSomething();
  }

}

I guess [Apprenticeship] basically means having the attitude that there’s always a better/smarter/faster way to do what you just did and what you’re currently doing. Apprenticeship is the state/process of evolving and looking for better ways and finding people, companies and situations that force you to learn those better/smarter/faster ways. - Marten Gustafson

I stumbled upon Apprenticeship Patterns, by Hoover and Oshineye the other day, and it hit home.

The authors propose that developers can benefit from a psuedo-medieval pattern of master/journeyman/apprentice relationships, regardless of their role in the relationships. I say “psuedo-medieval” because their pattern ignores the mandatory terms and authority structures of the medieval world, focusing instead on the more important aspect of knowledge exchange.

A few weeks ago, I cracked open Think Python, and so far it’s been a fun ride.

The interactive nature of the book has helped reinforce the various language quirks for me, and while the language so far may not be that much of a challenge (due in part to its similarities with Groovy/Ruby), the algorythms in each chapter have kept me going. I’m even considering trying to show my daughter TurtleWorld.

Oreilly’s Head First books come close in terms of readability, but even after putting away three or four so far, I’d still say that Think Python’s got the edge.

If you’re new to programming, this is a great place to start, particularly if you can snag the e-book during a half-off sale.