Yesterday (2 hours ago) was the last day at my job, and closes one chapter on my life. I’m thankful for the experience. I will begin the next - undoubtedly amazing -chapter of my life Monday, and am no less than gitty at the prospect.
Wednesday was the mensal Java User Group, and a particularly good one at that! I post a recap here because they say that you don’t remember anything you don’t use within 2 weeks, and the least I can do is regurgitate 2 day old knowledge towards that end.
Ted Neward was the speaker, giving two talks.
One was on the groovy language; the notes on this one are briefer, as the talk was lighter.
- Groovy was started 3 years ago by James Strachan.
- Goal: create something easier to work with than Java
- Java (surprise!) isn’t the last word on languages
- Sun’s attitude reminiscent of Grover Cleveland’s suggestion that they should close the patent office – that’s to say, "what else could there possibly be?"
- ACM tried to assess how productive somebody is. They determined that a young programmer writes about the same amount of useful bug free lines of code per day as an experienced programmer, except that the experienced programmer gets the code right the first time around.
- ACM said that a language like C gets something like 4-6 assembly instructions per line. Java / C++ get 6-10. Lisp, amazingly, can get hundreds, maybe even thousands! A language can be inherently more powerful. It makes sense to get the most bang for those X lines of code you get a day.
- For more, check out the groovy home page.
The other talk was about debugging ("Busy Java Developers Guide to Debugging"), which I found fascinating because Ted seems to really enjoy this.
- What is a bug? Anything the customer doesn’t expect?
- There are utilities, and JDK 5 and 6 introduced a raft of APIs/ tools, like JConsole, which is a service console shipped with JDK 6.
- Management needs to display a commitment to quality
- Schedule debugging into the project
- "Bug chats" are the highest priority meeting that can be called in some environments that Ted has worked
- Scott Davis (paraphrase): "Only 40% of projects use some form of unit tests" !
- "Ship It!" good book on debugging (I can vouch for that—the book broaches all the stuff you do anyway (setting up a bug tracker, setting up a source code respository, and a heckuva lot of other basics, and makes them a coherent discipline.)
- John Robbins, Microsoft SQL Server team, relays that developers used "teddy bear" debugging, talking through an issue with a stuffed animal. Talking through a problem forces the brain to enumerate it in a different manner and potentially will provoke a solution.
- Simialarly, sometimes walking away from a problem and taking a walk is beneficial. Often, the solution will come just as you’ve left the office and on the drive home, or as you’re sleeping: "Aha! Eureka!"
- JPDA is a general architecture for tooling support in Java. It’s comprised of:
- JVMI – agent inside the debugee’s VM
- JDWP – java debug wire protocol
- JDI – Java debug interface
- Other cool utilities:
- jdb standard console debugger
- extcheck: detects duplicate classes loaded via the $JDK/ext directory.
- Experimental tools:
- Jps, jstat, jstud, jinfo, jhat, jmap, jsadegd, jstart: cool experimental tools that aren’t guaranteed, and that are often written by Linux/Solaris people and may not run on Windows
- How to approach a bug
- "Duplicability" regenerates the bug once in 24 hours.
- Throw unit tests at it (which you should be doing anyway!)
- Track it in anyway shape or form. Enter it into the bug system for both the aforementioned enumeration which may itself be profitable and for the documentation to better aid the next guy.
- Use the binary chop
- Dive and conquer
- Start at component boundaries and then work out.
- Raise debug thresholds.
Naturally, I whole heartedly you go out and see Ted Neward speak (in particular he's pushing No Fluff, Just Stuff") when you get a chance. He was obviously knowledgeable, a good speaker, very worth it.
