Burk on Books: Growing Object-Oriented Software, Guided by Tests

If you want the short version, here it is: Developers should get this book and spend some time absorbing the ideas in it. It’s well written and easy to read, but grokking it all will take time and practice. I recommend doing it as a team, book club style; read a bit then discuss it so you can bounce ideas off each other and get the benefit of other viewpoint. I also recommend starting now so you can write better code sooner!

Note to those who care: ‘Grok’ is a real word now, it’s in the Oxford English Dictionary, though I prefer the definition in Merriam Webster’s.

Still here? Well then, I think it’s safe to assume one or more of the following; you weren’t convinced by my four sentence review, you want more details about the book, or maybe you’ve just got some time to kill and like my writing style. Hey, stop laughing, it’s possible...

According to the authors, “Growing Object-Oriented Software, Guided by Tests” is the results of a couple of decades of experience, including almost ten years of Test-Driven Development (TDD) on a wide range of projects. While the authors state that the goal of the book is to teach you TDD, don’t believe them. From what I read, the goal is to teach you TDD the way it should be done. Just as having 100% code coverage doesn’t mean there are no bugs, writing unit tests first doesn’t guarantee a working system.

The authors expand upon the traditional approach to TDD by adding acceptance tests to the mix. Acceptance tests, sometimes called end-to-end tests, begin at the user level (UI or public API) and exercise all parts of the system to ensure the system performs correctly.

Their approach adds an outer loop to the standard Red-Green-Refactor cycle. The loop starts with writing a failing acceptance test then writing all the unit tests needed to make it pass. While it may seem to be a small thing, I think adding the outer loop gives needed direction to the developers’ efforts by highlighting what should be built next.

The book starts with a quick introduction to the authors’ view of TDD, the tools that will be used in the examples throughout the book (JUnit 4, the Hamcrest matching framework, and the jMock2 Framework).

In Part II, the authors go deeper into how they start a project using their acceptance test/unit tests approach. In it, they introduce the concept of a “walking skeleton” which forms the basic structure the rest of the system is built upon.

Part III, a “Worked Example” is the longest section of the book, and it’s where we get to look over the authors’ shoulders as they build a nontrivial application that includes a Swing-based user interface and third-party services in the back-end. Even so, it’s not a realistic application, which is good because at the level of detail they’re giving us, the book would be too big to lift.

One of the most important things this book does is prove that you can test-drive a functional user interface. Yes, it’s a Swing-base UI, but I suspect you could follow the same approach using Seleium or Geb and test-drive a web-based UI too.

Part IV is titled “Sustainable Test-Driven Development” and it the authors present some useful guidelines intended to help you keep your sanity while maintaining a test-driven approach.

Part V covers “Advanced Topics” like how to test persistence, dealing with mult-threading, and how to test asynchronous code.

There’s more after that, including “A Brief History of Mock Objects” and two useful Appendices.

I said it before, and I’ll say it again. Developers should get this book and spend time absorbing the ideas in it; preferably with other team members for the most benefit, Go solo if you must, the time invested will be well spent.

Disclosure: I received a free copy of the book from the publisher, with the understanding that I would read it and write a review of it. For more information read my Full Disclosure post.

Here's the publishing details:

Title: Growing Software , Guided by Tests

Authors: Steve Freeman and Nat Pryce

Published: 2009 by Addison-Wesley

ISBN-10: 0321503627

ISBN-13: 978-0321503626

Burk on Books - Essential Skills for the Agile Developer: A Guide to Better Programming and Design

“Essential Skills" is a part of Net Objectives' Lean-Agile series. The authors’ intent is to teach the "minimal set of skills developers need on the journey toward becoming adept at incremental development.” In my opinion they’ve more than met that goal.

Note that while the title says "Agile Developer", almost all the examples are in Java, and the skills are just as useful to Java developers as to any other kind.

Due to its focus on the fundamentals of good software development, “Essential Skills” is one of those rare books that is valuable to both beginners and experienced developers.

Beginners will learn to develop high quality software, while experienced developers will be reminded of valuable practices they may have dropped while attempting to meet aggressive deadlines. But there's more.

The authors also describe the benefits gained, which is quite useful if you're often asked to "cut corners" and deliver something sooner. (Imagine flashes of lightning and ominous music here.) Once business people see how rushing things out the door leads to lower code quality, and eventually results in longer deliver times, they tend to back off a bit.

You've no doubt heard that moving a team that produces so-so software to an agile process won't improve the quality. They'll just produce it faster. However, using the skills you learn from this book will increase the quality of your software. And, over time, you may notice that it's sped things up too - whether you go agile or not.

In short, I strongly recommend this book for both beginning and experienced developers, no matter what methodology you follow. I found myself nodding in agreement more than a few times as I read, and I think you will too.

Oh, yes. One more thing. If you do nothing else, find someplace to read the Preface. Yes, that's right, the Preface. It's only two pages, but there's something worth learning right there. If you're not sitting in a bookstore, you can get it straight from the publisher at InformIT. If the link doesn't work, just go to http://safari.informit.com/9780321700469 then click the link for the Preface and enjoy.

“Essential Skills for the Agile Developer: A Guide to Better Programming and Design”
Authors: Alan Shalloway, Scott Bain, Ken Pugh, Amir Kolsky
Publisher: Addison-Wesley Professional; 1st edition (August 29, 2011)
ISBN-10: 0321543734 ISBN-13: 978-0321543738

Burk on Books - Switching to the Mac, Designing Web Interfaces, and Essential JavaFX

Its been a while, but I've recently posted three new book reviews on DZone; Switching to the Mac and Designing Web Interfaces, and Essential JavaFX. While they cover very different topics, all of them are worth reading.

Essential JavaFX is a great introduction to JavaFX. You get a good feel for working with JavaFX without having to devote too many hours to it. The only thing I didn't like is that the images are gray-scale instead of color. I know it ups the printing cost, but when you're dealing with graphical user interfaces I think having color is important.

Switching to the Mac is a great book for those of us who have spent many years on Windows and finally move to a Macintosh. I bought mine almost a year ago and found that my previous training didn't help me on my Mac so I did what I often do. I went looking for a book to help me. After reading reviews of several books and leafing through a few at Borders, I decided on Switching to the Mac, and I'm glad I did. It's not the kind of book I read cover to cover, but it's stuffed with useful information. If you moving like I did, I think you'll find if useful to keep the book near your Mac for a while.

Designing Web Interfaces is an excellent book for anyone designing web applications. It's well written with plenty of color diagrams and screen shots (Yes!) so you can see how various interactions play out. I am a little disappointed though because there's no sample code even though the authors say they targeted the book for designers and developers. Even so, I think this is a great book for designers and a good one for developers who enjoy a challenge.

That's it for today. I've got three more reviews to write up, one book to read and review, and I think I'll be caught up.

BTW, I'll be at the the No Fluff Just Stuff software symposium here in Atlanta this weekend so if you're there and want to talk about the books, or any aspect of software development, feel free to introduce yourself.

One more thing before I sign off, this blog isn't intended to be a one way signal. If you want to ask a question or share a thought (preferably one that is relevant to the posting), please leave a comment.

Burk on Books - Pragmatic Thinking and Learning

Last year, Andy Hunt (co-author of the Pragmatic Programmer) authored a new book titled “Pragmatic Thinking and Learning: Refactor Your Wetware”, and I’d like to tell you a bit about it.

It’s a great book. You should stop reading this blog posting and go buy a copy of the book, then sit down and read it. Now.

OK. That was the short version, which is probably all that some of you needed to hear. The rest of this is for people who are looking for some details.

The book is published by the Pragmatic Bookshelf, it was released on October 28th, the ISBN is 1934356050, it retails for $34.95 and is worth every penny. Still not enough?  OK, I’ve got a detailed review posted on DZone in the IT Book Zone (at http://books.dzone.com/reviews/pragmatic-thinking-learning) and you can win yourself a free copy if you read the review, post a comment, and get chosen by the Fickle Finger of Fate.

If you’re still reading this, I’m guessing that you’re looking for some insight that’s not in my other review. OK, here goes: The secret to getting the most out of the book is that you can’t just read it. Andy’s put exercises in the book and you need to do them, and do them the way it’s described, to get the most out of it. This isn’t much of a secret because Andy tells you the same thing early on in the book, and in a podcast (“Andy Hunt on Pragmatic Wetware") which is available on the PragProg.com website or from ITunes. The reason I bring this point up is that it is very easy to know this and somehow still not do it.

The other secret is that reading the book (and doing the exercises) is still not enough. Just like Neal Ford’s book “The Productive Programmer”, you need to actually practice the things you read about. It’s not enough to think, “Cool! I love that idea!” Until you take action, and begin practicing what you’ve read about, you won’t really benefit from knowing it.

As someone more profound than I once said, “Those who do not read are no better off than those who cannot” or, more succinctly, “To know and not do is not to know.”

Thus endeth the day's lesson.

Burk on Books - Practical API Design

Practical API Design: Confessions of a Java Framework Architect

Author: Jaroslav Tulach

Published by: Apress on July, 2008

ISBN: 1430209739

If you write code then you are designing APIs and this book is for you.

Jaroslav Tulach, is the founder and initial architect of NetBeans and in this book he shares with us the lessons he learned during ten years of designing APIs that are used by developers around the world.

If others use your APIs, then the lessons found here are worth far more than the price of the book and the time it takes to read and digest it. Do yourself, and your users, a favor and start studying it today. And if others don’t use your APIs, then it might be that you need this book even more.

“Practical API Design” is divided into three parts: In part one, Jaroslav describes the theories underlying his approach to API design and his reasons for writing “another design book.” This section is reasonably brief and introduces the main concepts underpinning the rest of the book. In part two Jaroslav draws on his decade of experience and expounds on what works and what to avoid when designing frameworks and APIs for public consumption. Part three is where the rubber meets the road and Jaroslav shows how the theories and ideas from part one can be applied in daily life to achieve the practical application of the rules as described in part two.

The information in this book is relevant to every developer, though I will admit that some probably need it more than others. If you write code, you’re creating APIs - even if you’re the only one using them. If you’re creating APIs then knowing how to create and evolve those APIs benefits you and anyone who depends on those APIs to get things done.

For me, the bottom line on this book is that anyone who writes code winds up creating APIs, so it makes sense to learn how to create, evolve, and maintain them without breaking any code that already uses them.

There are some nice resources out there for anyone interested in learning more about this book. Here are just a few:

Jaroslav has created a website at “http://wiki.apidesign.org/wiki/Main_Page” with the intent of building a community around the book and the ideas he’s expressed in it.

Download chapter 1 from Apress at “http://www.apress.com/book/view/9781430209737”.

Check out InfoQ's interview with Jaroslav Tulach at “http://www.infoq.com/articles/tulach-practical-api-design”. In it there's a link to download chapter 3.

If you’re interested in learning more about the book, I have a more detailed review on DZone (and I’m told they may be giving away a copy) at http://books.dzone.com/reviews/practical-api-design.

Happy reading!

Burk Hufnagel

Mini Java puzzler - Zapped by static

I was modifying some legacy code (defined as code with no automated tests) and found something unexpected when I tried to use it. The original code was rather complicated (possibly because there were no tests), but this simplified version has the same odd behavior:

public class Test {
    static {
        initName();
    }

    static String name = "Sue";
    static Test instance = new Test();

    public static String getName() {
        return name;
    }

    private static void initName() {
        name = "Bond, James Bond";
    }

    public static void main(String[] args) {
        System.out.println("My name is " +
                Test.getName() + ".");
    }
}

So we have a class with one static variable, three static methods and one static initializer. Other than the static initializer, it looks like a pretty simple class that's easy to understand doesn’t it?

In case you’re not familiar with static initializers, let me paraphrase a bit of Sun’s Java Tutorial: "A static initialization block is a normal block of code enclosed in braces, { }, and preceded by the static keyword. They can appear anywhere in the class body, and the Java runtime guarantees they are called in the order in which they appear in the source code." 

That sounds kind of cool, but what’s the point? Why would you use one? Well, a static initializer executes when the class is loaded into memory and it is normally used to do some kind of one-time processing for the class. In this case, the initializer calls the initName() method when the Test class gets loaded into memory and before it’s main method executes.

So, getting back to the puzzle, the question is this: What does the above code do when you run the class?

Here are the possible answers:
   A) It prints “My name is Sue.”
   B) It prints “My name is Bond, James Bond.”
   C) Nothing, because it doesn’t compile.
   D) None of the above.

I recommend taking some time to figure out your own answer before reading any further. You’ll get more out of this is you do. Don’t worry, I’ll don’t mind the wait.

Ready to look at the answers? Good. First things first. Answer C, "Nothing, because it doesn't compile" is not correct. I included it just so I can tell you that I don’t like that kind of answer on a puzzle, or Java certification exam for that matter. Any IDE worth using will tell you if the code will compile or not. While it may have been a useful skill years a go, when our only tools were stone knives and bearskins, we’ve had better tools for so long now that it seems unreasonable to ask a question where “it won’t compile” is the right answer. OK, back to the puzzle.

What about answer B? Well, if you’ve attended one of Josh Bloch’s Java Puzzlers talks (or read my earlier Mini Puzzler), you know the whole point of this is to show you code that looks simple but behaves strangely. So you probably didn’t pick answer B - even though it looks like that’s exactly what should happen. And you would be right in doing so. The code doesn’t print  “My name is Bond, James Bond.”

What about the ever popular “None of the above.” Sorry, not this time. Answer D is not correct either.

By the process of elimination, the correct answer must be A. It prints “My name is Sue.”  and, as it turns out, that is just what does happen. Don't trust me on this, run it yourself - then come back for the explanation.

When I ran the original test code, I didn’t believe the results. It didn’t make any sense so I ran it in the debugger. If you do the same, you can see that the initName() method does get called before the main() method, and that when initName() finishes, the value of “name” is “Bond, James Bond” - just as we expected.

So what’s going on? How does “name” get set to “Sue”? Well, to mis-quote the spirit of Obi-Wan, “Use the source, Luke.”

In looking at the source, you can see that right after the static initializer, we’re declaring and initializing the “name” variable. Which seems odd because the initName() method already set “name” to a value - so it must already exist, right?

Sort of. The compiler sets aside space for the variable and includes code to initialize it but, because “name” is a static variable, its initialization happens when the class is loaded into memory instead of when the class constructor is called. It also appears that, like a static initializer, static variable initialization also happens “in the order in which it appears in the source code.” So after the static initializer is called, the code that initializes “name” to “Sue” executes and overwrites the value we expected to see. Believe it, or not.

So, how do we fix it? Simple. Swap the two lines so the variable is declared and initialized before the static initializer block gets called. Actually, there’s an even better solution for this kind of situation. Since the static initializer is only determining the value for one variable, have the line that declares the variable call a private static method that returns the variable’s initial value. Doing so would’ve prevented this problem in the first place, and ensures that nobody can accidently re-order the lines and start wondering why they’re seeing a line from a Johnny Cash song instead of something Sean Connery ought to be saying.

If you’ve got any feedback on this please post a comment.

Thanks for reading,
Burk

DevNexus 2009 review

DevNexus is the new name for the Atlanta Java DevCon conference, which is organized and hosted by volunteers from the Atlanta Java User Group (AJUG). The conference was recently re-branded as DevNexus because it's not limited to Java anymore. Don't get me wrong, Java is still a major focus, but there are other languages (some of which run on the JVM) and technologies that AJUG members use and we wanted to include those too.  

DevNexus has expanded to two days this year and may be even bigger next year. Not only that, but it went from two tracks to three, so there were even more tempting talks to choose from.

Speakers ranged from Neal Ford (Meme-Wrangler at ThoughtWorks, well known NFJS speaker, and author of The Productive Programmer) to Emmanuel Bernard (lead developer at JBoss, and spec lead for JSR  303: Bean Validation), to Peter Higgins (project lead for the Dojo toolkit) and Doris Chen and Justin Bolter (Technology Evangelists from Sun); and the topics were just as varied.

After some introductory remarks from Burr Sutter (Java Champion and AJUG top-dog), Neal Ford got the ball rolling Tuesday with his keynote "On the lam from the Furniture Police," which was an excellent look at how to be productive in a corporate environment that seems designed to prevent it. Neal's excellent keynote was followed by four hours of technical break out session on topics like Test Driven Design (not Development), browser optimization (aka getting around browser restrictions), grid computing, and how to create and use RESTful web-services with Java. The official day ended with Emmanuel Bernard's keynote on "Scaling Hibernate" which also gave us a look at some of the new features Hibernate supports, like sharding and full text search capability. After that, there was a "cocktail reception" for people who preferred a friendly chat (sometimes called networking) with other developers and architects over sitting in rush-hour traffic.

Wednesday got off to an interesting start. Doris Chen and Justin Bolter gave their keynote speech titled "JavaFX: The Platform for Rich Internet Applications" which, not surprisingly, promoted JavaFX as the best solution for Java developers who want to build RIAs. This was followed by Yakov Fain's keynote, "Picking the right technology for Rich Internet Applications" which compared Adobe's Flex, Microsoft's Silverlight, and JavaFX. During the speech he stated his belief that JavaFX might be a contender in 2010, but not today. I found this a little disconcerting, having just heard about what JavaFX can do. While I'm not sure I agree with him, I do think Yakov made some good points, though things may change with the release of JavaFX 2.0 slated for later this year. In case you're interested, his recommendation for developers that need to start an RIA project today was to use Flex.

After the clash of the RIA titans, there were three hours of breakouts mostly geared toward RIA or web development; topics included JavaFX, Java and Flex, developing modular Web applications using Spring 3.0, and GWT.  There were also some server-side topics like a JEE 6 preview, a look at Spring 3.0, JSecurity also known as Apache's project 'Ki', anda look at JVM-based dynamic languages in the enterprise.

The conference ended with a rap-session hosted by Burr Sutter, AJUG's main leader and Java Champion, asking for ways to improve the conference next year and how we can get the word out about it so more people will attend. There were several good suggestions, and you've just read part of my solution to the question.

DevNexus was a great conference and well worth the cost (just $185 for the whole thing) so start planning to attend next year; you'll be happy you did. BTW, the price is set so that the costs of the conference are just about covered; this is not a 'for profit' venture, it's part of the way that AJUG works to build the Atlanta Java community. If you want to get involved, start attending the monthly meetings (they're free) and see what you've been missing out on.

If you were there, or wished you were, and have something you'd like to share then please leave a comment.  

Thanks for your attention,

Burk

Learning Java by Leading

Another great way to keep up your technical skills is to lead a certification study group. They say that the best way to learn something is to teach it. While that may be true, I can tell you that you don’t have to teach. I’ve recently found that leading a study group grants many of the same benefits while giving you an out. Since you’re just leading the group, and not actually teaching the topic, you don’t have to be an expert.

Even better, if someone in the group really is an expert on part of the topic, or just knows more about it than you do, you can defer to their expertise without losing credibility. And, that’s a win for everybody. (On the other hand, when I lead a group, I think it is important for me to know as much as possible about the topic so I can answer most of the questions they bring up.)

Certification itself seems to be a controversial topic, but I think that most people would agree that it is a way for interested people to learn more about a given topic. Personally, I think studying for certification is great because it forces me to learn about things I wouldn’t otherwise be too familiar with. For example, way back in 2001 I was studying for the Sun Certified Java Programmer (SCJP) exam (version 1.2 I think) so I had to become familiar with the Java IO classes. While they're useful for working with directories and files, I had no experience with them because at the time I was writing code that ran in an app server.

As I stated above I’m currently leading a study group and we're preparing for the SCJP exam for Java 6. While reading this week's chapter, I ran into something possibly useful and definitely interesting. Like the Java I/O classed in 2001, it's something new to me because I’m mostly writing JEE code and most JEE app servers don't support Java 6 yet. Sigh.

Anyway, we’re using Kathy Sierra and Bert Bates’ “Sun Certified Programmer for Java 6 Study Guide” as our text. It's an excellent book and since Kathy and Bert were instrumental in writing the exam, I figure that after working our way through it we should be covered. This week we’re on chapter 6 which is all about Strings, I/O, Formatting, and Parsing.

The I/O section introduces the java.io.Console class, which is new in Java 6 and lets you read from and write to the command line – if the environment you’re running in supports it. You write information to the console by calling format() and printf(), and you read from it using readLine() and readPassword(). The readLine() method is for retrieving a single line of text from the console. The readPassword() method also retrieves a line of text, but doesn’t echo it to the screen so your password isn’t displayed - which seems reasonable. So far so good, right?

Now comes the interesting bit. The readLine() method returns a String, but the readPassword() method returns a character array. After I read that, I looked up and wondered why the API wasn't consistent. It seemed to me that it would be better if both of them returned a String. Then my eye caught the next sentence and suddenly it all made sense.

Since readPassword() returns a character array, you can do whatever validation is necessary and then overwrite the data with something else to scrub the password from memory. So, why can’t you do the same thing with a String? Think about it for a bit before you read the next paragraph…

That’s right! In Java, Strings are immutable and they’re stored in a special memory pool so the JVM can reuse them; which means that if readPassword() returned a String then the confidential information you took pains to hide from prying eyes could be found by someone sifting through the system’s memory.

Of course, this also means that once you get the password you should take pains not to do anything that would create a String out of it; but you probably figured that out already.

If you're in a study group, or leading one, please leave a comment and let me know what you think about it. Is it valuable? Is it a waste of your time? And what do you think about Java certifications? Are they intrinsically valuable, or does it depend on circumstances?

Thanks for reading this. Y'all come back now, y'hear?