A recent trip on Metro-North reminds me that I need to submit this script snippet to Seth MacFarlane.
Brian: Wait, what did you say?
Stewie: NEW Haven.
Brian: NEW Haven? You mean New Haven.
Stewie: NEW Haven.
Brian: You’re saying it weird. Why are you putting so much emphasis on the New?
Stewie: NEW Haven.
Brian: Say New York.
Stewie: New York.
Brian: Say New England.
Stewie: New England.
Brian: Say New Haven.
Stewie: NEW Haven.
Brian: You’re eating hair!
Sigh. If it’s still not clear, ask your local Connecticutioner / Connecticutlet before you embarrass yourself on the train.
One of my goals for the year was to learn more about the Spring Framework, a layered set of modules that intend to make enterprise Java development easier.
In September, I took a class on Spring. Last month, I put together a presentation to share what I learned with my colleagues.
I attended the Core Spring bootcamp in New York City. If you’re looking to learn about Spring in a classroom environment, there is perhaps no better source than Interface21‘s consultants as they are the company behind the project.
The course materials were solid and the class revolved around a real-world application scenario. For each segment presented, corresponding before and after projects for the lab were available in a workspace used by the free, Eclipse-based Spring IDE that was distributed to the class.
A copy of Pro Spring was included with tuition, but I’ve found the newer Spring in Action, second edition a better read. The instructors also noted that the older Pro Spring book had information on AOP and transactions that weren’t up to speed with the latest 2.x versions of Spring.
As you would expect from a technology that in practice killed EJBs, the Spring bootcamp focuses on middle-tier applications. However, there was good coverage of Spring MVC, which I hope to a adopt for a new project built on WebSphere 6.1 and J2SE 5.0.
Like Baldwin home from Paris
Some time after the course I had the opportunity to present an overview of the Spring Framework to my department. The audience consisted of developers as well as project managers and other non-technical types, so the goal was to keep the presentation accessible as well as sufficiently informative.
To sum up the philosophy of Spring in a nutshell, I hit on three characteristics with real world parallels. I hope they went over well, and I think some of the other learning materials out there would benefit from a similar approach. It seems the ideas behind Spring could be conveyed easier than they often are (another reason I like Spring in Action).
Inversion of Control / Dependency Injection
Give code what it needs, don’t make it ask
Does your car buy its own gas? Should it have its own credit card? Or use yours?
Interchangeability through Interfaces
Keep things “black box” enough that you can swap individual pieces out when you need to
Your twenty year old lamp can take either a traditional incandescent light bulb or a new compact fluorescent light bulb which provides a 75% more efficient way to do the same thing in the same standard socket.
Aspect Oriented Programming
Terrible name and difficult vocabulary for an easy-to-grasp concept
Consolidate logging and access control code, don’t repeat it all over the place
Imagine an assistant tracking your billable hours to several projects during the day for you while you focus on your real job.
Silly middle-tier guys, or, what’s with that goofy .htm extension?
I have one outstanding gripe about Spring. Spring MVC in particular. I let it slide in the class, but since the foolishness is repeated in other materials for learning Spring I felt I had to speak my mind.
In a lot of examples for configuration of the Spring MVC DispatcherServlet, folks will tell you that “.htm” is the preferred convention for the mapping requests to the front controller.
The argument goes that we should trick the search engines into thinking this is static HTML content and besides, the mapping reflects that even though the page is dynamic, it is indeed rendered in HTML. Furthermore, the “.do” convention from Struts is pure tomfoolery.
This is dogsqueeze.
I take exception with all those arguments. In fact, I’d go as far as to say the “.htm” extension for dynamic content is actually harmful:
- Most developers deploy Java Web applications to an application server which is not also the front-end Web server. Application servers, such as WebSphere, are configured to serve only dynamic content, such as servlets and JSPs. The HTTP server, such as Apache, serves the static files such as HTML documents, stylesheets and images.
What if you really did have a static file with a “.htm” extension deployed by one of your Web developers? Do you want to see her go bonkers when she can’t figure out why her file is not being found because you decided to map that extension to your servlet? WTF?
- Do you really want to make the impression that you’re hosting your Fortune 500 or high volume e-commerce site on MS-DOS?
- The “search-engine friendly” argument for the “.htm” extension goes out the window when you start using query string parameters anyway.
- You’ve introduced goofiness at the cost of elegance, another tenet core to Spring. Sigh.
But honestly, if you’re going to go through with it anyway, just add the damn extra “l”, filename limitations (virtual as they may be) are a thing of the past.
Anyone who posts or sends me one more article about Conan O’Brien and Finland is dead to me.
So I’m back on the East coast and have been driving to Manhattan a lot recently. Every nasty thing I ever said about livery cabs remains true.
I hate those “Got milk?” ads with the white slime pasted on various celebrity upper lips. Ug.
BabyCenter has the top 100 names of 2005. “Reagan” makes number 67. As a girl’s name. Not sure what’s going on with “Cadence,” “Peyton,” “Mackenzie” and “Mckenna” as female names either.
Yes, I think “Sharnobille,” “Bhopalyn” and “Harroseamus” are pretty names too, but there are certain limits that should be applied to what you call your child.
This one has been bugging me for a while, but with all the “Java is dead” chatter lately, I feel the need to point it out.
To clear up a couple more common misconceptions about the two languages…
- Java is not an acronym (bad: JAVA)
Ah. Feels good to get that one off my chest.