Today’s show covered a few basic attributes important to using version control successfully with Java. The principles covered in Software Configuration Management Patterns are excellent. The two books from the Pragmatic Programmer Bookshelf, on Subversion and CVS, are excellent references to the tools that tightly weave excellent principles into the book. There’s also great free book for Subversion – it’s mainly a tool reference, but excellent.
This show discusses how we use the Team Review technique talked about in the last show, how I’ve seen it done, and touches on how the Jupiter plugin supports those efforts.
There a few resources mentioned in this podcast. First is the article When Two Eyes Aren’t Enough, by Karl Wiegers that we touched on last time. The next is the CSDL code review standards document that we used as a model to create our own internal code review standards. The last resource is the list of code review tools:
Jupiter Eclipse Plugin [Open Source]. In my view this is by far the best tool available. The downsides: it’s only available for Eclipse. See the user manual.
Today’s podcast brushes over several techniques described by Karl Wiegers and Steve McConnell, including:
inspections
team reviews
walkthroughs
pair programming
code reading
dog and pony shows or client demos
peer deskchecks or pass-arounds
ad hoc reviews
There were two major sources for this podcast. First is the article When Two Eyes Aren’t Enough, by Karl Wiegers and available from his website, processimpact.com. The second was Chapter 21 of Steve McConnell’s second edition of Code Complete.
Spring’s support for declarative transactions and it’s interception work are the subject of this podcast. I’ve got a quick high-level overview of AOP as well.
Today’s podcasts gives takes brief look at a couple template classes provided by Spring, and why the idea is really important. I’m still working on a good format for show notes. Here’s a bare bones version.
This podcast focuses on a quick intro to Spring and how it affects your code dependencies.
If don’t want to listen to it with the player above, you can download Spring and Dependencies podcast.
Show Notes
Here’s the outline I worked from while recording the podcast. It’s sketchy, so don’t take it for hard information. I’ve woven in a couple links, though.
Who I am
Java developer since 90′s
J2EE since Struts 0.5
Worked as programmer for university, .com, government
What the show format is
Cover interesting topics, many of them as they’re emerging
Mainly my own experience and my reading: get what I think is a decent overview
I wanted something substantive to listen to on the way to work or somewhere else
10-20 minutes
Split topics across shows often
Perhaps have a basic theme for week
EJ classes
90 minutes, 3 times per week
Spring IoC: Basic bean factory
Allows for creation and wiring up
Gives you home theater components instead of an all-in-one
Encourages interface programming
Can/should replace config file
Eliminates creation and relationship code, allows object to focus on its reall purpose
Moves dependency definitions to configuration
Dependencies
Variable type (Comcast comcast)
Constructor choice (new Comcast())
Variable methods used (comcast.connect(), comcast.sendSpam())
Getting rid of dependencies
Change variable type from concrete class to interface (Isp isp)
That eliminates dependency on variable type
That also standardizes the methods used — (isp.connect(), isp doesn’t have sendSpam() call). This may require changes to your code. You see this recommendation when using Map vs. Hasmap.
Remove constructor call and replace with set method.
Lets object creation be someone else’s problem
Your object is now dealing simply with how to get its work done and collaborate with other objects.
This has a really cool side effect: you’ve now made it really easy to use mocks of your Isp during testing instead of a real implementation.
About a year ago, we were using jWebUnit, which is an API built on HttpUnit — which in turn is very similar to HtmlUnit. We used it in conjunction with DbUnit to load the database tables before the test and verify them after. It worked really well. We had tests that could verify the operation properly manipulated the database, and could check the structure of the HTML returned.
We went away from it mainly because functional tests could only be written by programmers with that method, and with JMeter we could have someone a systems analyst or a tester write the functional tests. Using the proxy recorder available in JMeter let a user click through the test and replay it. JMeter could load the DB and check it based on CSV files, instead of XML. In the end I think the flexibility is a little less, but the number of people who can help get the work done has increased.
We’ve been doing a bit of research lately on the “Buy vs. Build” argument in application development. As a survey of what’s out there, one of my colleagues collected a number of articles on the issue. Many of these are on the web, so you can check out his Furl archive in the “Buy vs. Build” area. If you’ve got any other sources, drop in a comment!
