Avoiding Thick Technical Books
I picked up and poignant tidbit from <a href=”http://joelonsoftware.com>Joel Spolsky</a> after listening to a recent podcast on IT Conversations. Joel was talking about the big technical book boom of the dotcom era and that publishers noticed a trend that often the bestsellers in a topic area were determined by book with the thickest spine. Thus publishers began delivering more and more books that were breaking the 1000+ page barrier. Readers apparently having no better criteria to judge by were apparently buying the thickest book assuming it covered the material in more depth.
From a personal standard, this is almost the opposite of my approach. From my standpoint I have a limited time as a manager to delve into new areas. Thus I want to be able to dive into a topic quickly and get a good understanding without being buried in example code which often doesn’t even compile. I detest most of the 2″+ stuff with 8 authors most of which is a waste of bandwidth. And I do appreciate these days that every web technology book doesn’t begin with two chapters on the history of CGI to today anymore or explain the great issues with the stateless web or even better the huge difference between HTTP Post and Get.
So lately I find myself really enjoying the Pragmatic Programmer Series or some of the O’Reilly’s Developer Notebooks, and I actually read all the way through them. I still buy plenty of thick books, but they’re almost always more reference types like JUnit Recipes or J2EE Web Services. I never read all the way through them.
The only recent contradiction of this recently is that I picked up Holub on Patterns after attending a talk of his at SD West 2005. I read straight through the first hundred pages or so of his critiques of Java versus true OO, and then blew off the rest of the book which was basically some elaborate code examples of many of the GoF Patterns.
A Little More Anecdotal Evidence of Low JSF Adoption
Matt Raible commented in a post on Wicket that:
In the past couple of months, I’ve spoke in front of 25+ Java developers on 4 different occasions to talk about web frameworks. I’ve asked those developers which frameworks they’ve used, or plan on using. Struts is still the most widely used, with WebWork and Tapestry the least used. Surprisingly, JSF seemed to be getting no traction among the the audiences I spoke to.
So without going looking for it I continue to see evidence that JSF isn’t exactly taking off. Not sure this just says that most IT shops are conservative on new tools, or JSF just isn’t quite ready for prime time. I’d guess the later, but I’ve only taken spent about 20 hours or so playing around with JSF, so I can’t really back that up.
Fresh Sprint #1 Whiteboard
Starting a Sprint on a small project. I just love seeing the whiteboard before the Sprint really gets underway.
CruiseControl Warnings
I get about 48 email messages from Cruisecontrol each day for one of our projects. This is not something I’m proud of since this situation has existed for at least 4 weeks now, we’ve had a broken build. The problem stems from some nasty functional tests that no one wants to investigate and we’ve sort of let our process slip.
Anyway the interesting thing is about 11:00am yesterday I started getting a broken build message every 20 seconds. Checking the messages it was apparent the compile was failing now not just some unit tests. Sadly since email is easy to filter I think all of my developers have rules now to filter the messages straight to the trash. I’ve been the holdout willing to deal with the lagging guilt every time I see a message. It didn’t take long to track down the problem which involved the common misstep of forgetting to check in all the files into CVS by one of our senior developers. Since he was at lunch I sent him an email about the offending class and they stopped after he got back from lunch.
So even when you’ve let your build get to a badly broken state, there can still be value in continuing to run Cruisecontrol. This is probably also why visuals like lava lamps work better as reminders. Too bad about the fire hazard.
Checking out JUnit 4 from the Source
During a meeting of senior developers where we kick around general development issues like whether to use Spring MVC or JSF going forward, a question came up from one of the developers about JUnit 4 and when it was supposed to be released. The motivation for this was he wanted to try using TestNG now.
A little light bulb went off in my head on the way to my oncologist’s appointment about an hour later. Maybe I can checkout the source to JUnit 4. After hunting through the Yahoo group for JUnit, I discovered a post that mentioned just getting the source for the JUnit 4 version on Sourceforge. Sadly enough I admit, I’ve never pulled down the CVS source before on Sourceforge. I actually never noticed the little CVS link in the projects. So with a little trial and error on the old command line below I got things checked out after a bit of fiddling:
1
|
cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/junit login
|
1
|
Logging in to :pserver:anonymous@cvs.sf.net:2401/cvsroot/junit
|
1
|
CVS password:
|
Just hit return here. I mistakenly tried a really old FTP habit of mine and stuck in an email address
1
|
junk@junk.net
|
. Of course it really needs a blank password so just hit return.
1
2 3 |
cvs login: CVSROOT may only specify a positive, non-zero, integer port (not `2401:').
cvs login: Perhaps you entered a relative pathname? cvs login: warning: skipping invalid entry in password file at line 6 |
Not real sure why I got this message, something to do with some junk in my .cvspass file I’m sure. Anyway for a minute I throught it was failing but then I ran the next command and realized I was logged in to sourceforge.
1
|
cvs -d:pserver:anonymous@cvs.sf.net:/cvsroot/junit checkout -r Version4 junit
|
Success at last! I’ll check out JUnit 4 a bit tomorrow. This of course tweaks my interest to go ahead and pull down 0.6.3 of XPlanner from the Sourceforge as well, though after 0.6.1 and 0.6.2 failed me this is probably futile.