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.

A Weekend full of Learning

Where do you find people who willingly spend their entire weekend learning about things like Java class loaders, Groovy, Java Server Faces, Google Web Toolkit, Test Driven Development, Alternative languages for the JVM, and other similar topics? Well, last weekend you’d have found about two hundred of them at the 2008 Greater Atlanta Software Symposium put on by No Fluff Just Stuff.

The conference started Friday at 1PM and ended Sunday at 6PM, with breaks for food and sleep. The primary draw was twelve 90-minute opportunities to learn about one of 72 topics being presented by some of the best speakers out there including people like David Geary, Scott Davis, Neal Ford, and Ted Neward.

And if that weren’t enough (Is it ever?), each day had an extra goody; on Friday Jared Richardson presented a potentially life-changing keynote titled "Career 2.0" (keep an eye out for the book), Saturday ended with a choice of BOFs, and Sunday's lunch was followed by an hour-long “expert panel” featuring seven of the speakers holding forth on topics like architecture, testing and SOA.

If you’ve never heard of No Fluff Just Stuff then you’re in for a treat. It’s kind of like a traveling, three-day long, JavaOne. I recommend checking out their web site for a time and place when they’re either someplace near you or someplace you want to visit, then sign up and get ready to learn. It's good for your career.

What's in a name?

Listening to Jared Richardson speak, I knew I had to make a change and I needed to do it tonight. Jared was tonight's key note speaker at the "Greater Atlanta Software Symposium" aka No Fluff Just Stuff. His talk was titled "Career 2.0," and it got me thinking (again) about my career and what I want to do and be.

Jared made a lot of suggestions, and I intend to give some of them a try. One of the many things he suggested was to become a blogger because it's an easy way to share the things we learn with others. He said it's easy to create a blog. In fact, he claimed that it is so easy to get started that on previous occasions some people had actually fired up their laptops and created a blogging account during the second part of his speech.

After I got home I decided to take part of Jared's advice and enter the blogosphere. I went to blogger.com's home page and, since it only required three steps to get started; create an account, name the blog, and pick a template. I have to admit that it did look pretty easy.

I created an account, but then I had to wonder about the folks Jared spoke about. Creating the account was easy, but picking a name was definitely not. I'll admit that it took me a while, partly because all the names I initially wanted were taken; but it's also because I believe names are more important than you may think.

I suggest to you that names conjure images in our minds and can affect both our expectations and behaviors. Let me give you an example.

Many years ago my neighbors had a dog named "Rambo." Care to guess what kind of dog it was? If you've seen the "Rambo" movies, starring Sylvester Stallone, you'd probably thinking that Rambo was a powerful dog with a serious attitude; something like a Rottweiler; and you'd be partly right.

Rambo did have an attitude, but he wasn't big at all. You see, Rambo was a toy poodle. (Yes, I asked about the name. It turns out that when they decided to get a dog, my neighbors had a tough time deciding, so they compromised. She got to pick the dog, but he got to name it.) The point is that we often have preconceived ideas about people and things based on their name, and I wanted to pick a name that would help people get in the right frame of mind for what I was expecting to post here.

The first name I picked that hadn't already been used was "Musashi Flex" and I wrote much of this post for that blog's initial posting. But the next day I found that explaining what the Musashi Flex was, and how it applied to my blog,was more work than it was worth; though fans of Steve Perry's Matador series, it might have grokked it.

So I went back to thinking up a meaningful name and, after sleeping on it, the phrase "mind like a sword" is what I've come up with. It's not the perfect title, but I like it and I like the idea of equating mental sharpness with a sword's effectiveness in battle. (Yes. I am familiar with the phrase "Just like a(n) X to bring a knife to a gunfight", where X is some group you don't want to ba associated with; but "Mind like a bullet" just isn't me.)

I expect to do a few things with this blog:

• Share my ideas on software development.
• Share issues and solutions I run into while working as a software architect and developer.
  
• Provide a place to discuss and review some of the many of the books I read - most, but not all, related to software design and development.

Well, this seems like a reasonable length for my first post. Thank you for your time and attention.

May you live long and prosper!