Writing Month Starts November 1

I just got a newsletter the other day about Prag Pro Wri Mo. I think I'll need to give this a shot in November - which is only a few days away.

My goal will be to write a blog post every day. Short or long, every day. Starting Sunday. Formatting cleanup to come later, the emphasis is purely on WRITING. The actual idea is from National Novel Writing Month. This will only serve to further the motivation and push I got from reading Career 2.0

I need to start ramping up ideas and topics now, so I'll jot down a few.

• Test ownership - how do you solve the 'nobody owns this unit test failure' problem
• Build scripts (Ant, Maven, Gant, Gradle, Etc) - where are we today, and what makes sense to move to in the future, various pains, etc
• Java 7 features - I've meant to post about these for a while. Which ones are interesting and still being included...
• New languages to try - I need to pick a new language to learn this year. I think I have an Erlang book kicking around that I need to read...
• Notable programming books in the last 1-2 years?
• Ergonomics in computing (wrist pain is becoming a real issue for me)

updated to add more topics:

• Apache+HTTPS+SVN authentication issues (TortoiseSVN cannot remember password)
  
• More on SSDs
• The search for a quality LCD Display
• Report in on my recent PC upgrade
• Talk about Windows 7 in the context of both home and work
• at least one Book Review
  

Useful Regular Expression Site

Whenever I use Regular Expressions, my memory is always a little foggy. I usually make a couple of newbie syntax mistakes which waste some time. Now in Java (or in today's case: Ant), I don't want to edit, save (and/or compile), then run every time I alter my regular expression when first building it only to find out 10 (or more) seconds later that it doesn't match what I want or doesn't even compile.

The feedback cycle is simply too long.

After 5-10 minutes of frustration I usually seek out an online regular expression tester to ease my pain. Today I found Regex Tester and it rocks.

With instant as-I-typed feedback on my regular expressions (valid, what matches were produced for the sample string, etc) I completed the regular expressions I needed very quickly.

From now on, this site will be my first step in creating regular expressions.

Development Practices That I'm Passionate About

In response to Jared's blog entry: 'What Are You Passionate About?':

The list was already fairly comprehensive, and I generally agree strongly with all of the points.

Daily meetings are a tough one for me - I agree in principle, but I've yet to get down a daily meeting practice that doesn't occupy at least 20-30 minutes of my time. I've been in a SCRUM situation (as a remote user) for several months before, and that may have only taken 10 minutes. I enjoyed the urgency of wanting to have good progress to report each day, but the meeting always seemed to collide with my lunch time due to timezone differences, so that has probably predisposed me to negative associations. I want to believe in daily status though, even if it is a limited to myself and my direct superior. I think I'll put it down as a goal to establish as routine within the next couple of weeks.

Weekly status meetings is the absolute longest time period that I think a group of several small dev teams can go between syncing.

One point I would expand on - test automation - is that I'm passionate about automation in all forms. While I think 'test automation' definitely deserves it's own bullet, general purpose automation of daily tasks for developers and non-developers alike ALSO deserves mention.

As an example, our Hudson builds push an installer and database dump to a share location with enough information that new builds of our software can be automatically installed by a simple script that QA and other non-devs can run. (Yes, QA also tests our installer manually of course) This is just one example, but it applies everywhere. Just about any repetitive task that can be automated should be automated. I do think instructions for how to do automated tasks without the automation should be well documented, though.

I love having peer reviews for all code check-ins. Having had this as standard practice for the last 2 years, I will not be satisfied with any work environment where this is not mandatory. I believe it is an essential part of delivering quality software.

I may need to update this from time to time, as I haven't really declared a list of my own - this is more of a commentary, but at least it's a start.

Results for the week starting 9/28

I will experiment with whether a second post, or updating the original post, works better.

Last week I completed 3 Java Puzzlers and read Career 2.0 each night. I have continued to read nightly, and will finish the book this week.

I didn't get around to spending much time on Stack Overflow, but the goal was mostly to throw in something programming-related last week.

Java path mystery...solved

For ages, I've wondered how in most cases, java will mysteriously be in your path in windows, even though there is no Java install directory in the path. (it will certainly be a version that was installed with a proper installer, at some prior point, but not necessarily the most recent version you've installed) To fix this, I generally put %JAVA_HOME%\bin; at the front of my PATH environment variable after defining JAVA_HOME to point to the Java install I care about (something Ant, Maven, and other dev tools often care about having defined...).

I've always wished I had the 'which' command in Windows, so I could locate which Java executable was in the path. Finally, by chance, a coworker was debugging an OpenGL crash with an Intel GMA graphics card and substituting DLLs in what he thought was the 'run' directory, and he realized that it wasn't picking it up when he put it in the directory of the JDK bin he thought it was using... When he checked process explorer, lo and behold... C:\WINDOWS\SYSTEM32\java.exe is what was running. What the heck??? I find this strange, yet there it is.

I have always thought it was registry magic, or some other trick that caused Java to end up in the system path unless you put it as the FIRST path entry. Instead, FIRST just means AHEAD of the System32 folder. (Several apps likely to be in a dev environment often put themselves at the front of the path, subversion, oracle, etc...so I never noticed that the usual first entry in the PATH is this...and I typically put entries at the END of the path except when I know there will be other entries fighting for this position)

It's funny how sometimes mysteries like this go on for many years - maybe it's a simple Eclipse feature nobody knows about, or some maven quirk, that we never take the time to fully investigate and understand...we just come up with the rule and follow it - at least it's what I've observed.

If anyone can shed some light on this, I'd love to hear it. Is this practice generally acceptable to pollute the SYSTEM32 folder with executables? For now, I am satisfied to now know why I need to put my java/bin at the front of my path...

Goals for this week (starting 9/28)

This week won't have much coding in my forecast (and is approaching half over), but I think it's important to set some goals anyway.

- Continue doing 1 Java Puzzler a day
- Read a few pages of Career 2.0 each night
- Answer one StackOverflow question this week.

My testing and metric related goals aren't gone, but are on hold this week.

First week's goals (results a month later) - Poor

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