Well, change isn't always easy, even if you believe in it. I'd say I did fairly poorly on my first week (now a month ago) and those since, though I was on the vacation a decent portion of the time after. Still - that's no excuse not to blog results. I currently have a more pressing side project at work, so I won't get to focus on code much in the next week or two, but I will come up with a new list of goals for next week regardless.
I was pretty faithful to the puzzler a day (as it's a fun break from the normal day), and probably did 1 puzzler a day. I can't emphasize enough how useful (and satisfying!) it is to learn the quirks of a language that you use day-to-day (in this case, Java). It's good knowledge, and 'Java Puzzlers' presents it in an entertaining fashion.
On the unit test front, I probably updated or added a unit test one day of the week, in a section of code I already had pretty good coverage with. I did not get around to writing my first Abbot test. My issue has always been writing the first test - it's easy (and enjoyable) to follow in the footsteps, once they are there, but it seems like a pretty solid trend that untested code stays as untested code - there is an initial barrier of resistance still (maybe the code is hard to test, maybe the coder is lazy, or maybe test-driven just isn't strongly enough part of the mindset to jump-start things)
On the findbugs section I'd say I failed - there's no lack of warnings to fix, but they are often in a foreign area of the codebase. I did examine our warnings reports in Hudson, but didn't fix any.
I find that sometimes I'm hesitant to perform an obvious fix in a section of the codebase most requently updated/maintained by another developer. Prior history (just google Debian SSH) dictates that sometimes applying fixes that a code metric suggests in code you aren't familiar with is a bad idea. The code I'm looking at isn't as delicate, but it still deters me somewhat. We'll see how I cope with this as I really want to better embrace Findbugs.
On the Hudson front, I frequently spend an hour or two getting everything building (especially tricky in Eclipse at times, as the heavy generics often confuse Eclipse's compiler, since it does not use javac). Afterwards, I don't know what I should work on and it is late at night. Time dicates I should probably find a bug to fix, but it's often hard to find a good starter. I think I will keep this goal of contribution, with a renewed focus or speaking with the devs that hangout in #hudson on IRC. I'll just ask if there's an area I could help with in a small way. Hudson remains the single most useful bit of Java software I've ever used - the benefit the project has given our team is tremendous.
I'll have to come up with a list of follow-up goals and any strategies for better accomplishing them
I think Eclipse slightly surpasses Hudson in terms of use for me. For a team that line edges into Hudson's camp. I however do not have the role of build manager as you do so that is a bit of the reason for me personally.
ReplyDeleteOn the testing front it has proven very difficult to get our team to test. We are in an environment that ends up saying "Ehh... Who cares about testing". Well the people who have to deal with releases do, but that is another debacle unto itself. Sometimes tests are hard to write but that just makes you more confident of your result. Who likes to be wrong? I sure don't, but when I test and I am I feel a lot better when I am wrong because usually its some edge case that I didn't understand was an edge case or a weird precondition that does not easily present itself, but I at least know I tried. When its wrong and I didn't test I just feel like I didn't care or I was overconfident and it shot me in the foot.
Good Luck on the goals for next week.
Eclipse is a really impressive tool - that is for sure. I think it's value is way underrated by speakers. I think the IDE topic deserves a post of it's own some time.
ReplyDelete