@SD West 08: Highlights of Day Five

Ten Ways to Improve Your Code (Neal Ford)

Even if I do not fly airplanes anymore (for now?), I try to stay informed about what happens in the pilots' world. One aspect of it that has always impressed me is the importance given to constantly improving one's practice. Software development should not be different. This is why I like this kind of session, as there is always something to improve somewhere!

Neal presented ten ways to walk this path of improvement. Here is a very short version of these ways, consult the slides on-line for the full version:

1. TDD for its design benefits (including DI).
2. Static analysis (byte-code & source analysis).
3. Good citizenship (encapsulation, invariants preservation from construction to mutation, cautious usage of singleton).
4. YAGNI (no speculative development, no more ivory-towerish frameworks pleaeaease).
5. Occam's razor (make the difference between essential & accidental complexity).
6. Question authority (including established so-called standards, rebuke anti-patterns).
7. SLAP (single level of abstraction principle: for this, refer to yesterday's "Clean Code").
8. Polyglot programming (leverage languages targeted at specific problems)
9. Learn the nuances of Java (discover the hidden JDK gems!).
10. Anti-objects (too inspired by the real world and solving problems in a reverse manner).
    

Neal also presented 10 corporate development smells that would be hilarious if they were not tragic! Discover them now. For point 4 (the inane debate about stored procedures), you can also read my take on it in this discussion.

To finish I think it is worth quoting Neal's answer to client who try to find excuses for not making things better:

"Your problem is not more complex or so different than everybody else's!"

Responsible Web Design (Scott Fegette)

As if anything in software development could be responsible (software liabilities anyone?), Scott re-stated the need of staying abreast of current standards and best practices during his very open and non-dogmatic session. He also reminded us where we come from and all the progress that has been made along the way.

Here are a few key points:

• Thinking semantically (avoiding layout-specific markup as much as possible), with microformats for example.
• Properly managing CSS styles.
• Opting for un-obstrusive JavaScript (enough of these links that break when JS is disabled!).
• Staying current with the standards and practices.
  

I will not claim I followed everything in this session, even though Scott did a great job to demonstrate his points with actual web sites and code samples.


Memory Leaks in Java Applications (Gregg Sporar)

My worst memory leak, despite forgetting anniversaries, happened in 2002 when using Xalan. Each XSL transformation was leaving a bunch of not collectible objects in memory, until the JVM had enough and died. Since then, I am worried about all sorts of leakage (and since I am getting older, this should not surprise you), but I still like XSL ;-)

Gregg is obsessed with memory leaks too, but he works for Sun and knows the problem like the palm of his hand. The goal he had for us in his class was:

"To understand the different types of tools and techniques available for finding memory leaks."

He then went through a thorough review and demonstration of different techniques:

• Post-mortem inspection: analyzing a thread dump after the JVM crashed with proper tooling.
• Instrumentation: to perform live analysis of what is going on in the JVM, mainly by analyzing the trend in object generation count.
• A combination of both: to capture dumps on running code.
  

He also explained the lack of user-friendly tooling for analyzing class-loader related memory leaks (that can lead to the infamous permanent generation error). To learn further about this interesting and uneasy subject, I encourage you to read the two articles he co-authored for ST&P in April and May 2007, from which he extracted the material for his talk.


Mock Objects / Mock Turtles: The Role of Patterns in TDD (Scott Bain)

After reminding us the youth of our industry, Scott made this very interesting statement:

"Software Development is both an intellectual and a practical profession."

I find this interesting because I tend to over-emphasis the intellectual part of the job when I digress about the nature of our profession. So, yes, there is also a practical dimension to it and Scott argued that testing is a driving force for this concretization.

So how do design patterns play a role in unit testing? On top of allowing us to use a simple name to communicate a lot of information and context, which is extremely valuable, did the GoF give us best practices for testing these patterns? Unfortunately not. But all hope is not lost, as Scott explained as he went on detailing applicable test strategies for the most prominent patterns (strategy, decorator, façade). This is a work in progress that can be contributed to on Net Objectives web site.

So what is the relationship with turtles? Because some patterns force you to know a lot about the chain of objects behind the scene (turtles all the way down) to be able to test them ; and that placing a mock at the right place can alleviate this issue. It is for this astutely located mock that Scott coined the term mock turtle (well in fact, he recycled the term).