Weekly Developer Status Meetings
I don’t know how typical my status meetings are. I knew from attending numerous status meetings at past jobs what I didn’t like, long pointless reporting of status that everyone generally already knows. So here’s how mine go:
- Scheduled for 30 minutes, but typically run 15 minutes.
- Monday every week unless there’s a holiday in which case it’s not rescheduled.
- A printed agenda handed out at the meeting, but not before.
- Cover any management items that may affect the team from financials to consulting contracts. (My guess is I tend to cover more here than most care for)
- Two or three items like training or upcoming projects.
- Open up the end of the meeting for questions/comments. Usually this is short, but some weeks this takes up about 15 minutes, and it seems valuable even if it’s developers letting off steam about how insane it is to pay big money for the newest shiny tools and expect instant productivity improvements.
- That’s it.
Is JSF Really Going Anywhere?
Recently ran across a blog entry where Rob Lambert asked if anyone was actually using JSF? My initial experience is I don’t know anyone using it for any real project. Struts is pretty common, I occasionally here about something like Velocity, but never JSF.
I remember looking into local training classes when I thought JSF might be viable in our area around Sacramento. Turned out there was only one class available in the last 9 months and it got canceled. I walked through 300+ pages of JSF in Action, but I got frustrated that it was too front end focused, and it had some nasty javascript it implemented for simple things like links that caused turmoil for using JWebUnit on it. In the end we went with Struts. I’m thinking JSF may very likely die on the vine.
Nice Error Messages in Spring
Working through Chapter 2 of Spring: A Developer’s Notebook tonight, and I’m pleasantly surprised by Spring’s error messages. This is the first one I got after deploying one of the examples:
|
1
2 3 4 5 6 7 |
org.springframework.beans
.factory.BeanDefinitionStoreException: Error registering bean with name 'viewResolver' defined in ServletContext resource [/WEB-INF/rentABikeApp-servlet.xml]: Bean class [org.springframework.web.servlet .view.InternalResourceViewResolvers] not found; nested exception is java.lang.ClassNotFoundException: org.springframework.web .servlet.view.InternalResourceViewResolvers |
This points me to the file and the exact reference that is causing the problem just by reading the error message. I suppose a line number would be the only thing missing. Turns out I had an extra ‘s’ at the end of InternalResourceViewResolver. A quick fix and the next error message:
|
1
2 3 4 5 6 7 8 9 10 11 12 13 14 15 16 17 18 |
org.springframework.beans.
factory.BeanCreationException: Error creating bean with name 'editBikeForm' defined in ServletContext resource [/WEB-INF/rentABikeApp-servlet.xml]: Error setting property values; nested exception is org.springframework.beans .PropertyAccessExceptionsException: PropertyAccessExceptionsException (1 errors); nested propertyAccessExceptions are: [org.springframework.beans .TypeMismatchException: Failed to convert property value of type [java.lang.String] to required type [java.lang.Class] for property 'commandClass'; nested exception is java.lang.IllegalArgumentException: Invalid class name: com.springBook.Bike] |
This one is pretty obvious as well, whoops com.springbook not com.springBook. It’s nice that it points you to the errors right away. I’ve seen so many java open source packages that don’t point you at the real error relying too often on a simple stack trace.
J2EE Architects and Pet Peeves
‘J2EE Architect’ is a loaded word, and I should know I’m a Sun Certified Enterprise Architect (SCEA). I meet up with a lot of architects through the hiring process and reviewing consultant RFPs and quite a few of them scare me. When asked about implementation details I get responses like:
I’ve only worked at companies with really high end J2EE developers who could implement my design, so they didn’t really need mentoring.
SOA is really a paradigm shift for developers and takes some getting used to.
I develop really complete object models with UML class and sequence diagrams that map out exactly what is to be done and I use common J2EE patterns.
Look at my enterprise diagram here it really explains how to lay out your SOA architecture with our reference ESB implementation.
For the view layer I find XML and XSLT are very effective because you can separate the content from the presentation.
I like Michael Feathers rule that any code without tests is legacy code. My rule for architects is any architect who can’t/won’t code their solution is a legacy developer.
Searching for Java Development Podcasts
If anything I’ve gotten fairly addicted to RSS and more importantly podcasts in the last 6 months since a group of friends got me a 4th generation iPod while I was spending December in the Stem Cell Transplant unit of a local hospital. I now probably listen to 2 hours or so a day of audio, 1 hour on my morning walk and 1 hour of during the roundtrip commute.
One thing I’ve been searching for are decent development podcasts. I’ve found a fair amount at a site called IT Conversations, but only really run across one site by Tim Shadel that actually has java development podcasts. It would appear he’s run out of time or energy to continue them, but the 10 or so that are there are pretty good. My guess would be by this time next year there will be too many to listen to but for now the selection is really limited.