Giving XPlanner Another Try
One of the developers on XPlanner, Jacques Morel, dropped me a comment on my post about my Pain with XPlanner post:
0.7 is very close (within a month) and has this problem solved.
You can build it right now from subversion. It is rather stable (we release it every 2 weeks internally). I am scheduled to put out a beta anytime now.
So I’m a sucker for personal contact and open source tools, and I don’t really like spending much time in Excel. So it’s on my Backpack todo list for tomorrow, so assuming some fires don’t erupt at work I should be able to pull it down and try again. And of course this will force me to pull down a Windows subversion client at work, probably Tortoise SVN.
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.