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?

Beating the odds by reading books

In my copious spare time (gained by not watching much TV) I read and review books, technical and otherwise, as a way of keeping up with the rest of the world. (You can read my most recent review here.) Usually I’m working on one or two books at a time (did I mention I love to read?) but I discovered some really interesting books in a short period and now I’ve gotten a little swamped. At this point, I’m reading three books and writing reviews for three others.

I posted one review to DZone.com’s Book Zone last Friday, but you won’t see it in their listing until the zone leader approves it. The other two are not technically technical (they aren’t specifically about programming or software development per se) but they are books I would recommend to developers and architects who need to communicate their ideas with others.

The review I posted is for “Groovy Recipes” by Scott Davis and it is a book I highly recommend for anyone interested in the Groovy programming language. As its title suggests, the book is full of recipes showing you how to get something useful done in Groovy. There’s even a section with recipes for Groovy’s web framework, Grails.

If you’re looking for a new language to learn, or you’d like to improve your skills with Groovy, this is an excellent choice to help you on your way.

“Presentation Zen” is the name of a web site as well as a book, both by Garr Reynolds. I found the web site when I was working on a technical session for JavaOne 2008. While I loved the approach Garr suggested, I was pretty sure I couldn’t pull it off in the time I had left to prepare. I stuck a more traditional approach and swore to myself that I would come back and learn to improve my presentation skills.

This book is full of good information and can point you in the right direction, but you (and I) have to do the work needed to improve - reading alone probably won't cut it. But, if you want to get better at presenting information then this is a great place to start.

The third review I’m writing is for a wonderful little book titled, “The Back of the Napkin” and it’s subtitle “Solving problems and selling ideas with pictures” pretty much lets you know what to expect when you read it. If you’re anything like me and most of the programmers and architects I’ve worked with then you’re probably comfortable sketching a diagram to describe a problem or solution to the people you work with. So why would you want to buy a book about it?

Well, take a look at the website Dan Roam (the author) set up for the book and watch the video on the five focusing questions and the six ways to see and show. That should be enough to get you to place an order for the book today. In case the site’s down or you can’t view the videos, the point is that Dan presents a well reasoned method to figuring out how to visually solve problems and present the solution to other people so they can understand it. From my point of view, getting better at those two things is well worth the price of the book and the time it takes to read it, and you can’t ask for much more than that.

I’ll update this post – or just post a short notice – when the reviews are done and out there. I also post to the Atlanta Java User Groups’ Book Corner so you may see them there first.

Oh yes, the title of this post is my way of thumbing my nose at the "statistic" I've heard concerning the average number of books a programmer reads in a year - which is supposedly zero. I don't know about you, but I'm doing my best to boost that number; and learning a good bit at the same time...

Dang. I just realized I'm going to need a good sign-off phrase to let you know I’m done and didn’t just hit the “post article” button by accident.