Tag Archives: book

my first “thing in print”

Posted on by
3

mala-coverI was the technical proofer of Manning’s OCA book and got asked to write the foreword.  I got the book in the mail and was shocked to see “foreword by Jeanne Boyarsky” listed on the cover under the author’s name.  I’ve only noticed the foreword author listed on the cover when it is someone famous.  Or maybe it is that most books have an preface rather than a foreword.  Or maybe this is a shameless way to get me to advertise the book on my blog :).  (just kidding)   Anyway, it is AWESOME!

The publisher suggested putting the foreword on my blog.  Here it is.  Notice I got plugs in for Head First Java (from another publisher no less) and coderanch.com in there as well.  Speaking of plugs, feel free to read what I wrote on the blog about the OCAJP exam itself.

Note: I also contributed the equivalent of about half a chapter to the OCPJP book by Kathy Sierra and Bert Bates.  That was a lot more work and is really more of an accomplishment.  It comes out around summer.  But this foreword is the first thing I’ve ever written to wind up in a print book.  Very excited.

Taking the OCA Java Programmer I exam is a bit like taking a driving test. First you learn the basics, like where the brakes are. Then you start driving, and then you get ready to take the driving test to get your license. The written test includes things every- one should know, things that you’ll never use after the road test, and some things that are tricky edge cases. While the programmer exam cares about breaks more than brakes, it certainly likes edge cases!

Consider Mala Gupta your driving instructor to get you ready for the programmer exam. Mala points out what you’ll need to know when programming in the real world—on your first job.

And consider this book your driver’s manual. It gives you the rules of the road of Java, plus the gotchas that show up on that pesky written test. But don’t worry, it is much more fun to read this book than the driver’s manual. Just like the driver’s man- ual won’t teach you everything about driving, this book won’t teach you everything there is to know about Java. If you haven’t yet, read an intro to a Java book first. Start with a book like Head First Java or Thinking in Java and then come back to this book to study for the exam.

As the technical proofreader of this book, I got to see it evolve and get better as Mala worked on it. Through the conversations we had on little things, I learned that Mala knows her stuff and is a great teacher of Java. While I’ve only technical proofread a handful of books, I’ve posted reviews of over 150 technical books on Amazon, which makes it easy to spot a book that isn’t clear or helpful. I’m happy to say that Mala’s explanations are all very clear, and the pointers are great.

I also got to read Mala’s posts in the certification forums at coderanch.com. She’s been sharing updates about the exam as it comes out and posting fairly regularly for over a year. As a senior moderator at coderanch.com, it is great to see an author sharing her wisdom. It’s also nice to see the similarity in writing style between the forum posts and the book. This shows the book is readable and written in an easy-to-understand, casual style.

I particularly liked the diagrams, flow charts, and cartoons in this book. And, of course, the annotated code examples I’ve come to expect from any Manning book. Each chapter ends with sample mock exam questions and there is a full mock exam at the end. This gives you good practice in getting ready for the exam. Wrong answers are well explained so you don’t make the same mistakes over and over.

My favorite part of the book is the “Twist in the Tale” exercises. Mala gives a num- ber of examples of how making a seemingly minor change to the code can have major consequences. These exercises develop your attention to detail so you are more obser- vant for the mock exam questions and the exam itself.

I had already passed the OCA Java Programmer exam with a score of 98% before reading this book. If I hadn’t, the questions would have prepared me for the exam. Studying from this book will give you the skills and confidence you need to become an Oracle Certified Associate Java Programmer. Happy coding and good luck on the exam!

JEANNE BOYARSKY

SENIOR DEVELOPER & MODERATOR

CODERANCH

why i usually like books over video

Posted on by
1

A teammate was discussing the “wonders of learning from video” yesterday.  Which got me thinking.  I generally like learning from books/articles best.  This would be text with illustrations/diagrams, not raw text.  I like reading better because:

  1. It is easier to go at my own pace.  (While you can speed up video, it takes more energy to listen to fast.  And I don’t want it uniformly fast. I want to be able to stop and re-read.  Which is a pain on video.)
  2. I find it easier to find information in text.
  3. I can later search text if electronic.  Or have “physical presence” cues if hard copy.

That said, I’m enjoying some of the MOCC courses online.  Some being the operative word.  A video has to be done right to be good.  (As does a book; it’s just that books tend to go through more editing.)  I’ve noticed that the videos I like tend to be less than 5 -10 minutes in length.  With quizzes or exercises in between or in the middle.  I think the interaction helps.  It is easy to see if I understand what is going on so far.  And to revisit select parts.

Live/in person video doesn’t have the negative side effects that recorded videos do for me.  I think that is because the presenter can adjust real time.  Either by seeing reactions or looking at visual cues or answering questions.  It still feels interactive even if a high percentage is lecture.

When creating documentation

When looking for general information, there are many forms and it is relatively easy to pick the format one desires.  (Although books are more common than videos on specialized topics.)  In a company, the cost to produce internal documentation often precludes doing both.  It’s also harder on the creators to do video because:

  1. Content needs to be searchable (I suppose a video transcription could allow this.)  This is the same reason text in an image should be available in pure text as well.
  2. Producing content for video consumption is very different than merely recording an in person training session.  The focus is different.  The “real time clutter” needs to be removed.  The screen needs to be shown with a different emphasis.  It’s not something to just do on a whim.
  3. Video can’t be watched while on hold, on a conference call, etc.  Granted these aren’t the ideal times to be learning, but it does happen.  Again subtitles could help with this.

What do you think?  How do you balance text vs video for technical content?

the 555 graham cracker (or how to communicate a tech idea clearly)

Posted on by
1

We all know that sharing technical information in a clear (and ideally visually appealing way) makes it more memorable and understandable.  I saw a perfect example of it today with the electronics example of making a 555 timer.

What most descriptions do

  1. Tell you what you need so you can start out with supplies.
  2. Provide an overview
  3. Provide a circuit diagram
What good descriptions do
  1. Give you tips
  2. Show clear pictures of the completed breadboard.  Ideally from different angles.

What blows me away

The graham cracker 555 timer.  It has everything that really belongs in the 555 timer:

  • 555 chip – chocolate looking thing in middle
  • 9 volt battery – chocolate looking thing on lower left
  • three resistors – marshmallows with color stripings.
  • 1 microfarad capacitor – candy in top right
  • LED – red jelly thing
  • Wires – blue and red frosting
This is accurate (or at least really close).  It grabs your attention and makes you want to understand the concepts in mapping it back to the real one.  And it’s memorable.  Just what you want in your tech documentation.

How do I use this?

Remember tech documentation doesn’t have to be boring.  The Head First series uses cartoons.   The Developer’s Notebook uses journaling.  Manning usually uses stories and jokes.  All of this serves to keep us engaged in the material as we read.  If our brains are paying attention, we learn more.

What I didn’t tell you was that the wiki page was written by a high school student.  Don’t lose that skill after you graduate.  We need more tech writers who remember being fun fits in!