Stephen King's Novel 11/22/63: A Book Review

I think the last Stephen King novel I read was The Stand, first published in 1978. That's probably not true, now that I think about it. It was probably Firestarter which came out in 1980.

I stopped reading King after that. His books were too long, they tended to plod along, the characters were all depressing, his towns were always depressing, and all his stories seemed to end badly.

As I recall, King's novel The Dead Zone was about a man who, after getting in an auto accident and going into a coma, awakens with the ability to see a person's future just by touching them. This story too was about a man who tried to change the future, in this instance, by assassinating another man who was destined to be elected President and start a nuclear war.

So it's possible that King was mining some of his old material when he wrote 11/22/63: A Novel. Maybe so, but it's a lot more complex a novel than his previous works, at least as far as I know since I stopped reading him over 35 years ago. This, I think, is because this time King tackled one of the most famous events in American history: the assassination of John F. Kennedy.

King himself says that the idea of writing this story first came to him in 1972, the year I graduated high school, but he didn't think he had the "chops" back then to do credit to a novel of such scope, plus the research demands were formidable.

By the end of the first decade of the 21st century that was no longer true, and Jake Epping's story was told.

I would never have known about this novel except for a chance discovery on social media of an upcoming six-part television series on hulu based on King's book. Reading the premise fascinated me and, finding a copy of the novel at my local public library, I couldn't resist giving it a whirl.

I was dismayed that this tome was over 800 pages long. I don't have a lot of time for discretionary reading, and even though I read somewhat faster than the average person, it would still take a while to work my way through the whole thing.

Fortunately, it's a page turner.

Yes, especially the town of Derry, Maine was horribly depressing and even unrealistically grim. The communities King develops tend to have personalities of their own, as if they were living (and often evil) beings. Derry: bad. Jodie, Texas: good. Dallas: really bad, but not as downright creepy as Derry.

I liked Jake Epping. He was a borderline normal human being, a recently divorced high school teacher who seems emotionally closed, but only because he's not very emotionally expressive.

Jake got into this mess because he was teaching an adult ed class, one of the students was the high school janitor who was endearing, walked with a limp, and had an acquired brain injury. Harry writes an essay for Jake's class that tells about the night that changed his life, the night when his drunken father attacked his mother, siblings, and Harry with a hammer and killed everyone except Harry. Harry lived, but not without severe consequences.

Jake showed uncommon compassion for Harry and his tragedy but there was nothing he could do about it. After all, you can't change the past...

...normally.

But another resident of Jake's little community, Al Templeton, the owner of a local diner that served the world's best and most inexpensive hamburgers, had a secret. At the back of the restaurant's storeroom was a sort of "rabbit hole," a tesseract, an invisible doorway that lead to a single destination: September 9, 1958 at 11:58 a.m. You can go back to that moment in time, stay as long as you want, even years, then step back through to 2011 and you'd only have been gone exactly 2 minutes. Step back again, and it's September 9th all over again and whatever you changed on your previous trip was reset. It's as if you'd never gone through before (well, not exactly, but Jake doesn't figure that out until the end of the novel).

It's doubtful Al would have shared this secret with anyone, but another one of his secrets got in the way. You see, the "distance" between 9/9/58 and 11/22/63 is just over five years. Al had this crazy idea that he could save the life of John F. Kennedy, prevent Lee Harvey Oswald from ever carrying out the assassination.

The problem is, toward the end of the five-year journey, Al got cancer.

So he came back to 2011 and told the only man he thought he could trust, the only man young enough (mid-30), healthy enough, and unattached (Jake was recently divorced from his alcoholic wife and they had no children...well, he had a cat), and shared not only his secrets, but all his research (King's research, actually) on Oswald and associates with him, charging Jake with Al's original mission: save JFK at all costs.

Why?

Because Al believed that had JFK lived, he would have changed our nation for the better, maybe stopped our involvement in the Vietnam war, saving the lives of countless young men. Of course no one would know how history would play out until (or unless) Kennedy was saved.

A few things.

There's a yellow card man or a red card man or some other color card man who is always waiting near the "time portal" (for lack of a better term) in 1958. He's a wino, probably homeless, dirty, panhandling for money to buy more booze. But he's also connected to the portal somehow, as if he knows something, as if he can tell where Al was from during his trips, or where Jake came from.

The color of the card he wears in the brim of his hat keeps changing, indicating "something". On the day when Jake Epping finally accepts the task of stopping Oswald kill Kennedy, when he encounters the wino in 1958, the card is black and the man had cut his own throat and bled to death.

Another thing. Time doesn't like to be messed with. As long as you didn't actually try to make changes in history, time left you alone (more or less). But when you planned to make a change, time pushed back. You could still exert enough energy to overcome the resistance, but the bigger the change, the bigger the push back.

When Jake decided to save Harry's family from being murdered and prevent Harry's brain injury, the first time, he suffered through severe stomach flu, an attempt on his life by someone else who had a grudge against Harry's father, and he was nearly killed by Harry's Dad himself. Oh sure, he saved Harry, but his Mom still got a broken arm out of the deal, and Harry's brother still died (his sister lived, though).

The second attempt went much better, but Jake had taken precautions against the push back and amazingly, they worked.

But there was no going back. Rather than let the cancer kill him, Al had taken an overdose. Once his death had been reported, his diner would be sold, torn down, and some sort of mega-store would be built on its grave...

...and the tesseract would burst like a soap bubble and Kennedy's assassination would once again be reduced to a subject for history classes. Jake had only days, probably just hours, to step through the rabbit hole one more time and begin his journey through the long five years until November 22, 1963.

The majority of the novel chronicles Epping's living through the late 1950s and early 1960s as George Amberson (and King's portrayal of even the tiniest details of living in America during that time period were exquisite), would-be novelist, substitute teacher, and occasional gambler (like Marty in the second "Back to the Future" movie, Jake had been armed with the results of all the major sporting events, especially the upsets, as a means of making some ready cash), his adventures, first in Maine, then in Florida, and finally in Texas as he, acting on all of Al's research, slowly builds toward the day when he'd attempt to stop one of history's most famous assassinations.

Reading 11/22/63 was like watching one very long multi-car collision...horrible and yet fascinating. People suffered so terribly, and yet, I absolutely needed to know how or if Jake/George was going to save the President's life.

I think the original plan was for Jake/George just to lie low for five years, live modestly, make the money last, and stop Oswald, save Kennedy, and then go back to a better and brighter 2011.

But a man has to do something for five years.

Jake/George isn't a trained time traveler like you'd see in other stories. He has a few facts to go by, but unprepared, how does a man from the 21st century fit in at a time when computers filled a room, manned space exploration was in its infancy, and married couples in TV sitcoms still slept in separate beds?

But in many ways, this isn't really a story about time travel. It's like most of King's novels, about an ordinary person in a highly unusual circumstance, fighting against time itself, as if time had a life of its own, as if time was trying to kill Jake, in order to do what he thought was good, perhaps the greatest good in history.

But history fought back.

Jake/George falls in love, which makes things worse, not for him and not for his lovely Sadie, at least not at first, but for his mission. Time no longer has one target, Jake himself, to shoot at, now it has the woman he loves as well (and time makes them both suffer).

True to form, King introduces a small parade of insane, cruel, brutal individuals into the novel. The results are depressing and desperate, but like the aforementioned car wreck, I couldn't turn away. I found myself, having stopped reading to drive somewhere or perform some other task in mundane reality, terribly worried and wondering how I would ever find a way to stop Oswald. Yeah, I know. I started to identify with Jake/George. It got kind of personal.

Time batters and shreds Jake/George so that he ends up with only hours and then minutes to spare, rather than years, to find and stop Oswald. He does, but the consequences are disastrous. No, Jake/George, though maimed, lives, but so many other people die...

...and as it turns out, so does the future.

I waited a long time to get to this point in the novel and it's almost a let down. This isn't because of a fault in the novel, but because everything up until this moment, has been focused on killing Oswald and saving Kennedy, and in spite of time, it works.

But where do you go from here?

As it turns out, back to 2011, but again, referencing Marty McFly and his visit to the alternate 1985, it's the same town, but it's changed so much, and not for the better. Saving Kennedy doesn't save the world, it fractures reality. The green card man, a different one from the guy who committed suicide during Jake's last trip down the rabbit hole, explains it all to him.

Each trip doesn't exactly reset time. There are residual echoes from the previous trips. Each trip, and especially each change, tangles the different strings in time and if the tangles aren't stopped, existence itself is undone.

The only thing Jake can do is leave the alternate 2011, where no one has ever heard of Jake Epping and most of the world is a war zone, go back to 1958, do nothing, save no one, and then go back to his original 2011, go back to being a high school teacher, and let his scars and limp remind him that no one attempts to change history unchallenged.

Jake resisted. He could still save his beloved Sadie, Sadie who died trying to stop Oswald. Sadie who was almost killed and permanently scarred by an insane ex-husband (a classic King character), Sadie who was the only woman Jake really loved.

All he has to do is risk the very fabric of existence.

The novel was published in 2011, so there's plenty of information on the web that explains the ending, how King resolved the dilemma. Or you could avoid the novel altogether and watch the mini-series on hulu next month.

I'll leave that to you.

I thoroughly enjoyed the novel and almost considered reading it again. But that would feel too much like Jake's failed first trip through the tesseract, and then him going through again to replay history with a different outcome (besides, I've got a headache). Maybe a trip down the rabbit hole will let you, with great effort, change history, but King's novel will always begin and end exactly the same way.

The ending is semi-happy. At least King gave us that much.

My 19 Days of Python: The Introduction

I recently requested (asked for; begged for) a review copy of O'Reilly's new Think Python book. Over the years, I've toyed with the idea of learning (no, actually learning) how to program in at least one language, but I never could get past a certain point. Usually, it either came down to getting stuck at a particular stage and never being able to progress forward or I just plain ran out of discretionary time and had to pursue more productive activities (write a book).

I've always felt that there should be a book "out there" that would be able to take a non-programmer and successfully lead that person (namely me) to be able to program in a particular language, as opposed to just copying exercises out of a book or from some online source. I've looked at various texts over the past several years but never found one that fit the bill. I had high hopes for V. Anton Spraul's Think Like a Programmer, but ultimately the book failed due to lack of accessibility and ease of use (in spite of the author's comments otherwise, C++ is not an ideal first language for the "learn-at-home-in-your-spare-time" student).

At about the same time I heard about Think Like a Programmer, I discovered Think Python, but Spraul's book arrived at my home first so I reviewed it first. Then Downey's book was delivered by UPS and I started peering into the first page's of his text. I found it refreshing and very honest:

In January 1999 I was preparing to teach an introductory programming class in Java. I had taught it three times and I was getting frustrated. The failure rate in the class was too high and, even for students who succeeded, the overall level of achievement was too low.

One of the problems I saw was the books. They were too big, with too much unnecessary detail about Java, and not enough high-level guidance about how to program. And they all suffered from the trap door effect: they would start out easy, proceed gradually, and then somewhere around Chapter 5 the bottom would fall out. The students would get too much new material, too fast, and I would spend the rest of the semester picking up the pieces.

Yes! In a nutshell, that's my experience with just about every book I have ever used to try to learn to program. I work with software developers every day and in listening to their conversations, they seem to be a group of people who are just "wired" to know how to learn to program. I believe that people have certain natural aptitudes that allow them to acquire specific skill sets with some relative ease, while those who are wired differently struggle and ultimately fail to acquire the same skill sets, even when generating great effort to learn them.

I don't think I'm wired to be a programmer. I don't "think like a programmer." I think like a writer, which is what I'm good at. However, I'd like to expand my areas of interest and competency and stretch myself a bit so that I could learn how to program. Not only do I need to successfully learn a programming language and to write programs in that language, I need to learn to "think" in a way that allows me to program. If Spraul's book isn't written to teach me to "think like a programmer," then maybe Downey's book is.

Certainly Python is a more "accessible" language, since it doesn't need to be compiled. Linux (specifically Ubuntu 12.04) has a Python interpreter available, so all I need to do is open a shell, type "python" at the prompt, and away I go.

Downey's goal in writing his book (the book actually has a number of contributors who have become involved thanks to the fact that it was originally released under the GNU Free Documentation License, so Downey isn't the sole creator of this product) is to provide a resource to assist students, both in class and learn-on-your-own, to "learn to program and think, at least a little bit, like a computer scientist."

It seems as if Downey should have the background to enable him to accomplish his task:

Allen Downey is an Associate Professor of Computer Science at the Olin College of Engineering. He has taught computer science at Wellesley College, Colby College and U.C. Berkeley. He has a Ph.D. in Computer Science from U.C. Berkeley and Master’s and Bachelor’s degrees from MIT.

But how can I tell if his book really does what Downey says it does? The answer is to use it to learn how to program in Python.

Here's what occurred to me.

The book has nineteen chapters. Each chapter is relatively short, maybe ten to fifteen pages per chapter, including glossary section and exercises. That doesn't seem like a lot of material, but looking at the table of contents, the book seems fairly comprehensive.

I could kill two birds with one stone: thoroughly read and practice with the book so I could write a good review, and learn to "think like a programmer" (at least marginally) and as a result, learn to program in Python. I could take a chapter a day (I'll explain this part in a minute) and see if, by the end of the book, I was where I wanted to be, not as a programming expert, but as a fairly competent "hobbyist."

So that's what I'll do. I'll write a blog post after I successfully read each chapter and perform the exercises it requires. That's nineteen blog posts or "my 19 days of Python" using Downey's book. Nineteen "chapters" on my blog to write a book review. What more could a publisher want?

As I go through each chapter, I'll post my responses, successes, frustrations, not only with the book but with the process of learning to change my thinking to adapt to "thinking Python." This is just the introduction. My next post in this series will be on my experiences with "Chapter 1: The Way of the Program."

Is Think Python really a different book? Is it the "magic text" that will teach a non-programmer like me to program? That's what I'm going to find out. That's what we'll find out together.

Wish me luck and come along for the ride.

Book Review: Think Like a Programmer

Author: V Anton Spraul
Format: Paperback, 256 pages
Publisher: No Starch Press (August 8, 2012)
ISBN-10: 1593274246
ISBN-13: 978-1593274245

I'll give No Starch and Amazon the benefit of the doubt and say that any understanding about the intent, purpose, and function of the book are mine. Spraul's Think Like a Programmer really wasn't quite what I thought it would be.

Let me explain.

One of the issues with learning how to program, as the author rightly states, "isn't learning a language's syntax—it's learning to creatively solve problems so you can build something great." More to the point for me, it's learning the thought process that's used by the programmer. What makes it easy for one person to pick up a book on a language such as JavaScript or, for the sake of this book, C++ and start useful programming in a relatively short period of time, while another person who seems equally intelligent always gets stuck at a particular point in the learning process?

Besides the willingness to practice and sometimes be virtually obsessed with programming, it's the ability to conceptualize the idea of programming, and probably the world in general, in a very specific way. I think this is what makes some people great artists while others can barely doodle. Your brain is just "wired" to program (or draw or doodle). However, that doesn't mean people who don't consider the process of programming (as opposed to the process of learning and using a specific language) intuitive can't learn to program, at least to a degree. It just means that the non-intuitive "programmer" needs to learn to think in a particular way by training and practice rather than just "getting it" naturally.

I mentioned before that some people are just intuitively artistic, but I also learned many years ago from Dan O'Neill and The Big Yellow Drawing Book, that anyone can be taught to draw. It doesn't mean anyone can be turned into a Picasso, but they can learn to be reasonably competent, as long as they follow a certain order of steps and practice regularly. That's how I imagined Spraul's book would present learning to think like a programmer.

O'Neill's book doesn't assume anything except that the person using it can see six inches in front of them and hold a pencil. Alas, Spraul's book is based on the assumption that the reader has some programming experience and specifically with C++. Since Spraul is advertised as having "taught introductory programming and computer science for more than 15 years," it seemed reasonable to assume that the book was a very beginning programming book or better yet, a "pre-programming" book where the reader is taught to think like a programmer and to learn introductory programming simultaneously.

That's my fault, I suppose. In order to even use the book to its fullest extent, you have to have some basic knowledge in compiled programming languages in general and C++ in specific (I know just enough JavaScript and Python to get my face slapped, as the saying goes..I don't know from C++ from jack). Before that, you have to know set up a compiler so you can even run your code (assuming you know how to code anything in C++). So if (like me) you thought Spraul's book would be a beginner's book on coding and thinking like a coder...oops.

Now for the good news. The book will probably hone your programming problem solving skills or even help you hone your puzzle solving skills...but again, if you are a C++ newbie, you will probably be out of luck. OK, I know that writing a book that is language agnostic or without referencing a programming language at all is probably impossible. You can't teach the thought process behind programming in isolation from doing actual programming. But (and I'm sure Spraul would disagree with me on this, but I'm the newbie here) there were two errors (in my humble opinion as the reviewer) made before the writing of this book ever started. The first was the choice of programming language and the second was requiring that the reader have prior knowledge of that language. Something like JavaScript or Python would have been a better choice (for all I know, Spraul is more comfortable teaching C++ but who knows?). They require virtually no set up on a computer and are considered more "beginning" programming languages. Also (again, in my opinion), it wouldn't be quite so challenging for a total newbie who also isn't an "intuitive programmer" to pick up either language for the sake of learning problem solving.

Beyond that, teaching problem solving isn't exactly the same as teaching a thought process. How do programmers think differently than non-programmers? Can the difference be taught to non-programmers who want to learn to program (if not for money, then for fun)? With all due respect to Spraul, who I'm sure is a cracker jack teacher, programmer, and a wonderful human being, I don't think this book teaches that to the non-programmer audience. The "disconnect" may be between the process of teaching programming in the classroom, where the student has plenty of support, including any introductory technical set up required for the language being used, and picking up a book and teaching yourself not only programming, but "how to think like a programmer."

The "dream book" for non-programmer newbies to learn to successfully program has yet to be written.

Review: Microsoft Manual of Style, Fourth Edition

Author: Editors and Content Managers at Microsoft Corporation
Format: Paperback, 464 pages
Publisher: Microsoft Press; 4 edition (January 27, 2012)
ISBN-10: 0735648719
ISBN-13: 978-0735648715

I don't write technical content for Microsoft products very much these days (read: "practically never") but the Microsoft Manual of Style is not only considered required reading for those folks who do, but even for those of us who don't. Let me explain.

In many companies that produce technical documentation, there is a distinct set of rules that govern the voice, style, and other aspects in how the documentation is to be presented. Most people who aren't technical writers assume I just "wing it" whenever I create documentation for a technical product, but this is untrue. The documentation has to speak to a particular audience and for a variety of reasons, not the least of which is consistency, documentation for technical products must be presented in an exquisitely specific manner. Any technical style guide is designed to provide the writer with a template around which that presentation is organized.

Microsoft's fourth edition of their style guide is constructed into two broad areas: General Topics and Usage Dictionary. The first part is the narrative that addresses general subjects such as web content, the user interface, and even grammar and punctuation. The second part is the dictionary, but one that offers correct spelling and syntax around technical terms, from beep and bitmask to undo and update. Like any dictionary, you use it when you need to be sure you are using a technical term correctly or if you haven't the faintest idea on it's proper usage (and not all writers know how to spell all words, which is why we have dictionaries).

The first part of the book exists to familiarize the writer with the various aspects of writing style expected when documenting Microsoft products. It stands to reason that Microsoft's internal writing staff all use this book as the Bible; a Bible they themselves have produced. However, plenty of other companies must refer to Microsoft products in their documentation and it makes a great deal of sense to comply with Microsoft's preferred standards when doing so (just as we'd all wish Microsoft would write a version of Internet Explorer that complied with accepted web standards, but I digress).

As the front matter states though, no style guide can contain references to each and every aspect of each and every product, so there will be gaps. Several other references are suggested, both web resources and other guides and dictionaries. Together, this should provide the technical writer with a sufficient set of tools in order to create documentation that is readable by a general audience, internally consistent, and consistent with documents produced by other writers and agencies that comply with Microsoft writing standards.

This isn't a bad way to produce documentation for technical products that have nothing to do with Microsoft, either. Many technical writers work under temporary contract and provide writing services to a variety of companies needing documentation for general customers (such as end users) as well as technical consumers (such as IT staff). Smaller companies especially, won't have their own preferred style guide for their documentation, so it will be up to the writer to consult with the ops or dev team supervisor to agree upon a preferred style. While the Chicago Manual of Style is the accepted standard for professional writing, it is not designed specifically for technical documentation. In lieu of any other technical style, Microsoft's style guide is considered the de facto style by most businesses that need technical documentation.

I took a look at the Punctuation chapter in order to sample this book's wares, and was pleased that Microsoft indicated correct vs. incorrect styling as "Microsoft style" vs. "Not Microsoft style." There's more than one way to be right or wrong, but we're talking about Microsoft technical writing style, not general language usage, so what might be "right" in an email, could still be "Not Microsoft style".

You'll never memorize this book, so don't even try. If you are an aspiring technical writer, you don't want this stuck in your memory, anyway. That's why it's a reference and not undying prose. Plus, styles change over time, so you will need to continually adapt in order to stay current. That's also why you will need the current edition, rather than relying on previously published versions.

If you're worried about this guide stifling creativity, then you're in the wrong business. While there is certainly aspects of technical writing that require creativity, there is also a large amount of standards compliance required (and you thought programmers had all the fun). If you document Microsoft products or any other technical asset, assuming you want to write by some objective standard, a very good place to start is with the Microsoft Manual of Style.

A Book Review of The Linux Command Line: A Complete Introduction

Author: William E. Shotts Jr.
Format: Paperback, 480 pages
Publisher: No Starch Press; 1st edition (January 14, 2012)
ISBN-10: 1593273894
ISBN-13: 978-1593273897

Linux has been struggling to become a "desktop darling" of the home and small office user for years and has yet to succeed. I don't know if it will ever succeed. One of the biggest hurdles Linux has to cross is its reputation as being command-line driven. Most people fear the command line and if you're old enough, you remember (with dread) the arcane DOS interface or struggling to remember what command syntax to use with the now ancient Apple IIe. Users love Windows because the GUI is easy.

Ubuntu, of all the Linux distros, is about the best in terms of a user-friendly GUI, and yet even when Windows users abandon the Microsoft "mothership", they almost always turn to a Mac and not to Ubuntu (or any other flavor of Linux). Face it. Linux may never succeed as a desktop operating system and may have to "settle" for being the king of the server and embedded device markets.

But is that such a bad thing?

Ironically, the power of a Windows machine is on the command-line, but unless you're a system admin or network guru, that doesn't even occur to you. And absolutely, the power of Linux is in the command-line shell. Why fight the nature of what Linux is? Instead of trying to avoid shell commands, embrace them. That's where The Linux Command Line: A Complete Introduction comes in.

The hardcopy of this book should be on its way to me for my review right now, but I couldn't wait. The publisher kindly allowed me to also download a PDF version of the Shotts book, so here I am, tearing into it (metaphorically speaking) and getting ready to devour its contents. What secrets does it hold and for whom shall they be revealed?

Scrolling through the beginning of the PDF, I discovered the "Who Should Read This Book" section. According to the author, this book is for the rank beginner in the Linux world who is likely a Windows "power user" and who, for whatever reason, must learn Linux management skills. That's a rather amazing statement since, having scanned the table of contents on my way down to page 29, I discovered a rather impressive list of skills to be learned. Among them were "A Gentile Introduction to Vi" (my favorite editor), "Package Management", "Regular Expressions", "Compiling Programs", and "Writing Shell Scripts". Any one of these topics is worthy if its own book (and they're out there) and certainly they will be intimidating to the Linux novice.

But first things first.

The end of the introduction to the book gives rather brief instructions for how to install Linux on a computer or how to use a live CD, so the reader is presumed not to even use Linux on a regular basis (or at all). On the other hand, there are no links or instructions as to where to find a Linux ISO file for download or how to burn a bootable CD or DVD, so I guess the reader is expected to know something. Oh, in case you're wondering, I'm using Ubuntu 11.04 (Natty Narwhal) to write this review and practicing commands in the default bash shell.

The first section of the book is called "Learning the Shell", which is pretty basic. The first chapter, "What is the Shell" offers the reader a little bit of a history lesson on the shell and how to use very basic commands, such as "date", "cal", and "df". It's a very short chapter and fortunately gets the reader into opening and using the shell right away. It's a gentle beginning. When does the book get "rough?"

Technically, the hardcopy of the book is only 480 pages long, so it's not an encyclopaedia (remember them?). Yet, for not being a massive tome, the Shotts book probably best works not only as a linear tutorial but as a reference. After all, even veteran shell users don't remember everything and I've seen Linux developers with decades of experience still have to look up commands they don't use very often (although they almost always do so using Google rather than grabbing a handy book).

I called this book "a linear tutorial" because the first section is written in just that manner. One skill set builds on the previous ones presented and the more the reader goes through and practices what they're reading, the better they should get at navigating the directory tree, copying and moving files, locating files, and using man pages.

Although there are no exercises or labs at the end of each chapter, there are notes encouraging the reader to pause and to practice what they've learned as well as experimenting and adapting on commands they've been using. The reader is also encouraged to refer back to the help and man documentation on commands, which is a further exercise in using the shell, since these tools are the first ones a system admin or programmer turn to when they're trying to recall that rarely used command switch.

Actually, the book doesn't really need a separate section for exercises since each page in the chapters directs the reader to try out various commands. This is a book that needs to be opened alongside a Linux machine where the reader is simultaneously working in the shell.

It would take too long to review the content in each chapter and section, but there are a few notable mentions. In Chapter 12 "A Gentile Introduction to Vi", the reader is treated to a Vi primer (sorry, Emacs users). It's probably just about as much as a new user will need to edit files on a Linux machine and if need be, books such as Learning the vi and Vim Editors by Robbins, Hannah, and Lamb are always available.

I did wonder about introducing the reader to Regular Expressions in Chapter 19. For the average computer user, even the average Linux computer user, Regular Expressions can be a real "migraine maker". This may be your first clue that not everyone who will use this book will use all of it, at least not right away. Although this is a great skill to acquire, not everyone may be up to the challenge. When reading this book, assess whether or not you want or need to learn everything it has to offer.

Chapter 23: "Compiling Programs" is another chapter that may not always be useful to all readers. The content goes quickly from "What is Compiling" to downloading source code from the web (specifically ftp.gnu.org), examining the source tree, and building a program. Note that the reader isn't expected to know how to actually write a program, so the general purpose of this chapter is to introduce the power of compiling in the shell and, like vi and Regular Expressions skills, is something that can be built upon using other resources if the reader so desires.

All of the fourth and last section of the book is devoted to "Writing Shell Scripts". If the hypothetical reader of this book is someone who wants or needs to learn Linux server management skills, everything presented in the book up to this point is not only useful, but required. Certainly writing shell scripts (and again, there are entire books available on this subject), is a necessary skill set for the Linux systems admin or even for people who just like to "get under the hood" a little.

After a brief introduction, the reader is lead through the "rudimentaries" of their first shell script which is about as basic as echo 'Hello World!' The reader must dig back into what they've learned before about using vi or vim, creating a file in the desired directory, making it executable, and saving it (none of these instructions are presented again in the shell script chapter). The last bit in the chapter gives the reader a tip on how to configure vim for shell scripting by turning on syntax highlighting, highlighting search results, and using auto indent. The rest of the section takes the reader through building a scripting project and pulls together previously learned skills to develop more complex scripts, including teaching the use of loops and arrays.

The final note in the final chapter addresses the reader, "Well, we have completed our journey. The only thing left to do now is practice, practice, practice. Even though we've covered a lot of ground in our trek, we barely scratched the surface as far as the command line goes."

I can agree with that. There's a reason why the book's subtitle is "A Complete Introduction." That's not a contradiction in terms, it's the literal truth. Part of the power of the shell is in its almost infinite potential, which most shell users never master, but if you buy and then use The Linux Command Line: A Complete Introduction to its fullest extent, your "introduction" to the shell will be very impressive.

Book Review: Sams Teach Yourself TCP/IP in 24 Hours (5th Edition)

Author: Joe Casad
Format: Paperback, 544 pages
Publisher: Sams; 5th edition (November 4, 2011)
ISBN-10: 0672335719
ISBN-13: 978-067233571

I've been spending a lot of time with TCP/IP and particularly IPv6 in the past few months (I can't tell you why right now, but soon). When I saw Joe Casad's book Sams Teach Yourself TCP/IP in 24 Hours was in its fifth edition, I wondered how it compared to my experiences in researching various aspects of internetworking. One way to find out for sure is to request a review copy from the publisher, so here I am and here it is.

I'm a big fan of the "Sams Teach Yourself" books. I've had good experiences with them in the past and they usually offer just the right amount of learning, broken up into correctly sized bites. They also usually build one "hour" upon another so that by the end of the book, you really have learned something. There is no "who is this book for" section in the front matter, but this series is typically tailored for the beginner. How much of a beginner do you have to be? The first hour is called "What Is TCP/IP?". The first questions asked are, "What is a protocol?" and "What is a network?". Pretty basic stuff.

This series is designed, as I'm sure you guessed, to be a learning series. After the chapter's main content, there's a Q & A section and a Workshop section which is made up of a brief quiz (4 or 5 questions) and a short series of exercises. Appendix A in the back has all the answers, so you can check your work or have a peek if you really get stuck. Just for giggles, I went through the Workshop section of Chapter 14: TCP/Utilities and it seems like it's pretty standard material, if you know much about networking. Questions have to do with what commands you would use to view a computer's ARP cache or to see which hosts have made TCP connections to your computer (this all assumes a Windows PC) and exercises focused on ipconfig and ping. Not super challenging, but if the goal is to teach a networking newbie, this is at the right level.

I guess I shouldn't have been surprised that only one "hour" was dedicated to IPv6 (Hour 13) or that there were Exercises assigned to this chapter, but no answers for them in the Appendix. There are two good reasons for this. One is that a newbie will have their hands full with IPv4 and the other is that most folks still consider IPv6 really new (the "newness" is an illusion as IPv6 standards have been developing for years and many ISPs have accelerating their adoption of the next version of IP recently). The downside to this "neglect" in the book is that newbies are the perfect audience to learn IPv6 from scratch, at least at the level of concept. If you've got a couple of Windows 7 computers, you can ping their IPv6 addresses or ping your own localhost address (ping ::1).

On the up side, this TCP/IP book covers a lot more than TCP/IP at the level of the protocol including DNS, Routing, SOAP, Email, and "the Cloud". That sounds impressive and from the neophyte's perspective it is. However, because the book is addressed to the beginner, that's about as deep as you go into any of these topics. To be fair, that's a deep as this book should go, but that also means if you have any networking experience at all and you don't need a ground-level review, this book will be too light for you.

If you are a person who wants to learn basic networking (not particularly for how to set up two or three computers for wired/wifi in your home) with an eye on something a little more advanced like CompTIA's Network+ and a little later on Cisco's CCNA, then Casad's book will certainly give you a leg up. If that's where you are or where you want to go, I'd recommend Sams Teach Yourself TCP/IP in 24 Hours. If you have some experience and are looking for a book with more "meat" to it, you'll need to look elsewhere.

Addendum, 12-26-2011: Regarding IPv6 deployment, I just found this article at InfoWorld: IPv6 due for wide deployment in 2012, experts say

Review of CoffeeScript: Accelerated JavaScript Development

It's been awhile since I've sunk my teeth into a good book review so I'm finally glad to get my appetite back and start consuming Trevor Burnham's CoffeeScript: Accelerated JavaScript Development book. I'm actually just as interested in trying out CoffeeScript itself as in having a look at what the book has to offer. Well then, let's get started.

First off, before even getting into the book, what is "CoffeeScript"? For a quick and dirty definition, I hit up Wikipedia:

CoffeeScript is a programming language that transcompiles to JavaScript. The language adds syntactic sugar inspired by Ruby, Python and Haskell to enhance JavaScript's brevity and readability, as well as adding more sophisticated features like array comprehension and pattern matching. CoffeeScript compiles predictably to JavaScript and programs can be written with less code (typically 1/3 fewer lines) with no effect on runtime performance. Since March 16, 2011, CoffeeScript has been on GitHub's list of most-watched projects.

I suppose I could say that if you don't know what CoffeeScript is, you shouldn't be reading Burnham's book, but that's probably not true. According to the "Who This Book Is For" section in the Preface:

If you're interested in learning CoffeeScript, you've come to the right place! However, because CoffeeScript is so closely linked to JavaScript, there are really two languages running through this book - and not enough pages to teach you both. Therefore, I'm going to assume that you know some JavaScript."

The author goes on to say that even if you know just a bit of JavaScript, you should be OK, but rank novices at the language might want to get to know a bit of JavaScript before tackling CoffeeScript. Also, since Ruby inspired a lot of the features in CoffeeScript, having a bit of Ruby background is a plus.

A couple of other "support" features before diving into the book and CoffeeScript. The sample code used in the book can be found on the book's official page at Pragmatic along with links to the errata, the discussion forums and of course, how to buy the book in hardcopy, ebook, or both formats.

How to get CoffeeScript.

I chose to use Ubuntu for my "testing platform" but was running Ubuntu's last LTS version, which doesn't support installing CoffeeScript, even in an exceptionally painful manner. Therefore, I upgraded my Ubuntu box to 11.10 (Oneiric Ocelot), opened the Ubuntu Software Center, and searched for CoffeeScript. It was discovered in no time and I installed it with no difficulty. Notice that this means I completely blew off the instructions for installing CoffeeScript as found in the first chapter, but since the book was published last August and the production version of 11.10 didn't become available until October, I figured, "what the heck". We'll see if my impatience will come back to bite me in the rear.

So now I have CoffeeScript. How am I going to use it? Oh, yeah. I have this book.

Anxious to "meet coffee", I opened a terminal window and just for giggles, typed "coffee -v" to see what version I had. So far, so good, I have version 1.1.1, the same version used in the book (the latest version as I write this blog post is 1.1.3).

There are all kinds of text editors you can use with CoffeeScript, but the author, apparently being a Mac guy, prefers textmate. Fine and dandy, but I use Ubuntu and prefer Vim. Apparently, there are textmate plugins for a wide variety of text editors including Emacs, gedit, jEdit, and of course, Vim. You can choose to go through the time and effort of adding the plug-in but you don't have to. As it says in the book, any text editor will do.

I have to say two very good things about this book. First off, the author obviously knows CoffeeScript. This is evidenced by the apparent ease at which he explains the concepts and the whirlwind tour he takes the reader through. The whirlwind tour is the second good thing since the reader gets started programming right away and dives into a practical project. If you are a beginning web developer, this book is well suited to your experience level. Unfortunately, for the beginner (and probably more advanced readers), the book has some drawbacks. I'm not sure Burnham knew exactly who to write the book for. At some points, you need to understand some JavaScript to know what's going on and at others, the author goes to some length to explain aspects of HTML and CSS (which I would presume the reader should know if they're taking on a web development programming language).

I don't mind books for beginners and in fact, I encourage them, and as an author, I can certainly understand when a publisher asks that you limit your page count to under 150 and thus limit the scope of your book, but it's as if Burnham couldn't decide how to best make use of his 138 pages. While it's good not to overwhelm novice programmers with a lot of details, beginners also tend to get confused easily if tasks and concepts are not sufficiently explored. Based on his writing style and presentation, it seems like Burnham is probably a very likable and knowledgable person, so I hate to give his book a less than stellar rating, but with CoffeeScript, JavaScript as well as jQuery, HTML, and CSS all tossed into the middle of the salad, it was hard to see the overall focus of this small text.

I do like that the book devoted itself to creating a single product (a simple game) throughout the chapters and allowed the reader to make and refine this game as a way to learn basic CoffeeScript, but in my opinion, the book is as frustrating as it is illuminating. If you're interested in learning CoffeeScript and you have at least a little programming experience, I won't say not to buy Pragmatic's CoffeeScript book, but I would recommend also spending a lot of time at coffeescript.org which, in and of itself, isn't a bad way to learn this language.

Book Review: HTML5 Media

By Shelley Powers
Paperback: 138 pages
Publisher: O'Reilly Media; 1 edition (August 17, 2011)
ISBN-10: 1449304451
ISBN-13: 978-1449304454

I understand that O'Reilly is publishing a series of hardcopy and ebooks that sport a rather modest page count in order to get the material to market very quickly. Shelley Powers' HTML5 Media is one of them. Please keep in mind this book isn't intended to teach you everything you want to know about HTML5 but rather, to show web developers how to insert HTML5 media elements into web pages using the new video and audio elements.

The book's front matter states that the target audience is web developers, authors, and designers who need to ramp up to using HTML5 video and audio elements fast. Hence the size of the book. No one wants to read through 800 pages when they need to do anything fast. Powers' book, with its scant 138 page count, is guaranteed to be a fast read...maybe. Actually, that depends on how much you already know. While the book doesn't require you have a lot of experience with actual video and audio files, you will need a background in CSS and JavaScript for this to make the most sense to you. Of course, if you are a designer or developer, that should go without saying.

While sample code is available, sample video and audio files are not. It's sort of a BYO...F (for files) affair. This is to keep the size of the downloadables manageable, so be prepared to have video and audio material of your own available (if you don't have much on hand, don't worry. Powers provides a number of resources where you'll be able to access what you need).

It's not just about the HTML...it's about the browsers. You can be fabulous HTML5 designer but if your browser (or your customer's browser) doesn't support the audio and video elements, you might as well not bother. IE9 or later is required, but you can also work with Firefox 3.5 or Chrome 6 and do just fine. If you keep your browsers current, you have nothing to worry about.

I got to work right away with what I learned on page 2, creating a basic audio page and, by adding the controls attribute to the audio element, I could play a sample mp3 I had on my computer (Sleep Away by Bob Acri using Chrome 9.0 on Windows 7, in case you wanted to know).

With my first minor success completed, I decided to download the sample files for the book and went back to the preface to look for the link...and didn't find it. I found the usual boilerplate text under "Using Code Examples" and while Powers says in the "Examples" section that there is a downloadable, I couldn't see where she provided the URL. Fortunately, I had already looked up the book's site at oreilly.com and easily found the correct zip file (and remember, when you try to work with these files, you'll need to provide your own video and audio material and change the default names to the names of the files you're working with in the sample code).

The book presents its content in four chapters which covers the default use of the video and audio elements, customizing the media elements (this is where CSS and JavaScript experience starts to come in handy), and other, more advanced material, including media elements in SVG documents.

Frankly, I found working with this book to be a blast. It's short enough to not be overwhelming to the reader and to impart a real sense of accomplishment very quickly, but dense enough to provide practical information that can be leveraged into actual, real-world web projects (not all books do this). Doing a bit of research, I took a look at some of the other books Powers has written including Learning JavaScript, 2nd Edition and JavaScript Cookbook. HTML5 Media is another fine example of her writing and another fine book from O'Reilly.

If working with media files in HTML5 sounds like something you want or need to do, I'd recommend picking up a copy of this book.

Book Review: Learning Perl, Sixth Edition

Paperback: 390 pages
Publisher: O'Reilly Media; Sixth Edition edition (July 1, 2011)
ISBN-10: 1449303587
ISBN-13: 978-1449303587

It's been around awhile...the Learning Perl book I mean. Now in its sixth edition, this O'Reilly classic is still going strong. But first things first.

Who is this book for? You don't find out until the first page of Chapter 1, but it's called "Introduction", so I guess that's OK. Is this book for you? Depends. According to page 1, "This is not a reference book. It's a tutorial on the very basics of Perl, which is just enough for you to create simple programs mostly for your own use." In other words, you'll learn Perl but not much more. The reader is presumed to know some programming and is someone who specifically needs to learn Perl. Beyond the basics, don't expect much out of Learning Perl, but that's not a fault of the book. That's its nature. Anything else you need to know, you'll have to get somewhere else. That said, you start learning Perl here.

Why a Sixth edition? That's easy to find in the front matter of the book. The changes are all laid out in the "Changes from the Previous Edition" section. The book's been updated for Perl 5.14, but that's on the cover. Keep in mind that some of the book's sample code will only work with 5.14, so if something seems "broken", check the version of Perl you're using (this section in the book tells you how to do that). Not all of the sample code requires the latest version of Perl, though. A lot of it will work with older versions.

I loved the line in the Preface that said, "We can't give you all of Perl in just a few hours. The books that promise that are probably fibbing a bit." That's the reality of learning how to program in Perl or any other language. I love the honesty. Like Edna says, "I covered the basics." (If you don't know who I'm quoting, turn in your geek badge now).

Now that you know who this book was written for and what it won't teach you, what will it do for you? If you're at all familiar with the prior version, you can expect this book to maintain the same level of excellence as edition five. About the only complaint about that book was that it was too basic, but I've explained that already. The sixth edition is an update on a time-honored Perl book that is designed to just open the door to programming in Perl.

Each chapter provides the conceptual information for the topic at hand and ends with a set of exercises allowing the reader to practice what they've learned. The book doesn't leverage each chapter to allow the reader to build a larger project as they progress through the book. That's often the frustration when I go through beginners books, because I want the programming to actually do something. If you get that feeling, remind yourself about the book's caveat and then keep going.

If you are an experienced coder, this book might seem a little elementary for you, even if you don't know Perl, so there may some parts you'll skim through, but if you need a ground level foundation, Learning Perl is the place to come.

Not much more to say. What you see is what you get. If you want to learn Perl and already know a little about programming, buy this book. It's a good investment in your precious time and your hard earned dollars.

Migrating Applications to IPv6: A Review

Paperback: 50 pages
Publisher: O'Reilly Media (July 7, 2011)
ISBN-10: 1449307876
ISBN-13: 978-1449307875

This wasn't what I expected.

I have an interest in migration from IPv4 to IPv6 for reasons I can't really explain right now, but I thought that reviewing Dan York's book Migrating Applications to IPv6 would hone my thinking and expose me to a different way of looking at IPv6. After all, most of us think of implementing IPv6 on an internetwork. We think of the expanded IP address space and the changes in DNS records, how routing mechanisms will change in IPv6 implementations and so on. We don't really think about how the change will affect applications. You might not have thought that IPv6 would change anything about how you write applications. Dan York's book gets you to think again.

But in only 40 pages?

Actually, the content of the book is only 34 pages. That's like a short chapter in just about any other IT book I've ever read or reviewed. Something made me decide to check around at other books on IPv6 recently published by O'Reilly. There's a trend.

Cricket Liu is something of a mainstay at O'Reilly in terms of her DNS and BIND book (in its 5th edition as of June 2006). Her DNS and BIND on IPv6 book was published at the end of May this year. It's only 52 pages long with about 37 pages being actual content. Planning for IPv6 by Silvia Hagen will be published at the end of August and it's a total of 82 pages long. If you put these three books together, you might have the start of an actual IPv6 book based on the most recent IETF RFCs for IPv6 implementation, but I'd certainly expect more to round out the subject.

Each of these three books runs a little over $25.00 each, but you could also buy Hagen's IPv6 Essentials book (published in 2006), with a full 448 pages of information, for only about ten dollars more. I looked through the front matter of York's book trying to find some reason for it's "mini-format". I couldn't find anything. I've never seen a complete book from O'Reilly before that was so thin on content. I had expected an in-depth treatment of the topic but what I found was a "pamphlet" of introductory ideas, tips, and tricks.

York's book does address, in a very compressed space, a number of issues that you will need to consider as an applications developer, and they all have to do with how your application accepts, manages, and stores IP addresses and DNS records. If your app requires that an IP address be input, does it do so allowing enough space for IPv6 addresses? If your app manages DNS records, will it be able to accomodate both A and AAAA records (IPv4 and IPv6 respectively)? Does your app expose any APIs that have an IP address format dependency? As a developer, if you haven't asked yourself those questions before, this book will help you find the answers.

Is the information in this book useful? Yes. I found the content, what there was of it, well written, insightful, and knowledgable. Is it worth 25 bucks? That's hard to say. If I wanted information on application migration, DNS and BIND, and general IPv4 to IPv6 migration planning, would I pay over $75.00 (for the three books I just mentioned) for a total page count of only 174 pages, no matter how well written or useful, when a full-sized book of almost 450 pages is less than half that cost?

Sorry, but I'm having a tough time trying to figure out what O'Reilly's strategy is here. When I requested a review copy of York's book from O'Reilly, I didn't give the page count a single thought. Now, it's all I can think about.

What happened, O'Reilly?

The Python Standard Library by Example: A Review

Paperback: 1344 pages
Publisher: Addison-Wesley Professional; 1st edition (June 11, 2011)
ISBN-10: 0321767349
ISBN-13: 978-0321767349

Stop! If you are just beginning to learn the Python programming language, do not buy this book! This book was written for intermediate to advanced Python programmers who want to be able to put their hands on the Python standard library of modules (which is why I'd recommend buying the hard copy if you meet the qualifications). This is not a book that will teach you the first steps in programming in Python.

Another thing. Although the transition to Python 3 is coming along nicely, like the transition from IPv4 to IPv6, the future isn't here yet. This book was written showcasing the Python 2.7 library and this version of Python will likely be with us for some time. If you're looking for a Python 3 library resource, this book isn't for you.

I'm sure other books have been spawned from blogs before, but I can't recall any right off the top of my head. The book you're reading about has its origins in Doug Hellmann's Python Module of the Week series, so you can always visit his blog to get an idea of how his book reads.

Like many other programming and technical books, it's not as if this information doesn't live elsewhere, but the information isn't particularly accessible in a single location. While every copy of Python ships with hundreds of modules that span a wide field of developers, tasks, and years, the documentation for these modules isn't particularly consistent. That's where Hellmann comes in. He provides one resource for Python module documentation in a consistent "voice", and demonstrates the how and the why of these modules in a straightforward, understandable way. If you've read Hellmann's blog (and if you're an experienced Python programmer, you probably have), you'll more than appreciate his book.

The vast arena of examples are clear but the sheer volume may be a little intimidating. Hellmann's book weighs in at a robust 1344 pages, but then it is "one-stop shopping" at its finest. Programming Python "from scratch" is fine and well when you're first learning the language, but the real power of Python is in the ease of use of its library. Having all that collected in one container is a terrific advantage and, not having to search the web for specific modules, you might just come across a few that you've never heard of before, inspiring you to take a different direction to solve a problem. If you're an experienced programmer, but not in Python, you could get by with going through this book to learn the language, but as I've already said, it's really written for people who already know Python.

This is another fine addition to the Addison-Wesley Developer's Library. If you're a Python programmer, you know you want this book. Go ahead and pick up a copy of Doug Hellmann's The Python Standard Library by Example. You can't go wrong.

Trying to get a look and feel

I know, I know...it's been forever. I've been working on other blogs and have woefully neglected my first effort. I've also been trying to figure out exactly what content I want to feature here. For awhile, I was doing technical book reviews more or less exclusively here, but I ran out of bandwidth to do that kind of writing. I've been pining to get back to something like that lately, but maybe not with such an emphasis.

I love reading. I really enjoy it. I also like to write about what I read, but I read all kinds of books. The theological tomes I'm reserving for another blog entirely so if that's not your cup of tea, you don't have to be concerned that such content will appear here. On the other hand, I'm having a lot of fun reading Ayn Rand's Atlas Shrugged. I have been trying to get together with a few other folks for a "book club" of sorts, but the priorities of the various members seem a bit scattered, so it's not as successful as I'd hoped. Even if the "club" doesn't continue, I now have the desire to expand my reading selections into other more "literary areas.

I've changed the theme and imagery of the blog significantly but I still don't know if I really like it. I'll probably keep tinkering with it, but expect new content to appear here pretty soon. I'll still review books on technical subjects I like, but I also want to talk about (even if it's just to myself) my other "biblio" interests.

Please stand-by. There is nothing wrong with your television set.

Book Review: Computer Structure and Logic

Author: Pearson Certification Team
Format: Paperback, 496 pages
Publisher: Pearson IT Certification (January 28, 2011)
ISBN-10: 0789747936
ISBN-13: 978-0789747938

This is and isn't a book about computer hardware and software certification...sort of. OK, it's published by Pearson IT Certification and the authors are the Pearson Certification Team, but the content doesn't map to a specific certification or even a specific technology. That's a little unusual.

Most books on computer or IT certs focus like a laser on a particular exam. Often, but not always, technical certifications are tied to a particular company (Microsoft, Cisco...) and a particular technology (Windows, SharePoint...). However, the blurb on the back of this book says:

Your first step toward certifications from CompTIA, Microsoft, or Cisco...absolutely no experience necessary!

Really?

The book has a certain logic to it and an assumption. The assumption is that there are people out there who are interested in information technology certifications and a career in IT who pretty much have no idea how computers and computing technologies work. Usually (but not always) people who self-select for a career in a technological field have some prior knowledge about it or at least some sort of aptitude. This book assumes a target audience that doesn't.

The logic of the book is to take the reader to an absolute in-the-basement starting point regarding IT, and to build them up one subsystem and one chapter at a time. This isn't a reference book. For the reader to get anything at all from what's written here (assuming the readers are the target audience), they will have to start at the beginning and move through each chapter in sequence. No short cuts.

To that end, Chapter 1 is "Introduction to Computers". I'm not kidding. You start out with a high level view of the history of computing, beginning with the first computers created in the 1940s. That sounds as dry and moldy as week-old toast, but it's a necessary first step for a person who may not even know what makes a computer work on a fundamental level. What is a CPU? How does it interact with working storage (RAM) and input devices (keyboard and mouse)? Page 9, for example, includes a drawing of a cutaway view of an NMOS transistor. Now that's basic. So is the Chapter 1 section called, "What is a PC?".

Each chapter ends with a series of review questions immediately followed by an answer key that contains a brief explanation for each item. Chapters can contain one or more case studies and the solutions for each one can be found after the review questions and answers. This book reads less like a self-study guide for a computer certification and more like a beginning computing text book. I can see this book being marketed mainly to high schools, vocational schools, and possibly to universities with an eye on the very first freshman class teaching computer technology.

Chapters 1 through 6 are strictly focused on hardware (I/O ports, motherboards, CPUs) but Chapter 7 transitions the reader into the software part of the book by introducing BIOS and the boot process. After that, the remainder of the chapters cover operating systems, including Windows, Linux, and Mac, security basics, networking basics, and beginning troubleshooting skills. By the end of the book, the reader should have an elementary understanding of how modern computers work, including some networking fundamentals. This information can then be used to bridge the reader to further studies mapping to CompTIA A+ and Network+ exams (Linux isn't covered sufficiently to carry the reader into the Linux+ certification without a great deal of additional study).

From the CompTIA A+ and Network+ exams, I can see the reader, building on what they've learned, moving into the entry-level Microsoft Windows and Cisco certifications, but you are talking about starting the journey at the very beginning of the trail. I'm not sure I'd recommend this book for a person interested in certification self-study unless they were very disciplined and enjoyed learning "textbook-style". The book seems a better fit for a group learning experience such as a traditional classroom, or as a supplement for on-line education.

If you've tried the CompTIA A+ exam and felt you were in over your head because you didn't understand basic computer concepts, Computer Structure and Logic might be a good resource for you, but you should really want to learn computing in order to benefit from this book. Otherwise, the rather dry presentation, especially in the beginning chapters, will stop you cold.

Pragmatic Guide to JavaScript

Author: Christophe Porteneuve
Format: Paperback, 150 pages
Publisher: Pragmatic Bookshelf; 1st edition (November 22, 2010)
ISBN-10: 1934356670
ISBN-13: 978-1934356678

So there are just billions of JavaScript books on the market and if you are interested in this language, or learning more about this language, you probably own several. Why would you want to buy the Pragmatic version? What sets it apart from the rest of the herd? What does it bring to the table?

Good questions. But can Porteneuve's book provide the answers?

According to the blurb on the back cover, the book will get you up to speed quickly and painlessly with the 35 key JavaScript tasks you need to know. Task-oriented is good. You can't learn to use a programming language without writing the programming language. I am concerned about the phrase the 35 key JavaScript tasks you need to know. How does anyone know which tasks I need?

Often, my favorite part of a book such as this is the Who is this book for section. Here is where you'll find the "official" mission of the book and sometimes where you'll find the inconsistency between the book's stated purpose and how it's actually written. Here's the first sentence:

This book is not really intended to teach you "JavaScript the language".

What? That's not the impression I got from the back cover. As the "Who is this book not for section continues, it says that the language is pretty easy on its own so, if you know any programming at all, learning the basics (loops, variables, and so on) isn't much of a chore. The book even recommends the "JavaScript Core skills" section of Opera's Web Standards Curriculum.

So who really should buy this book?

Apparently, people who already have a smattering of JavaScript knowledge (or more), but who need a set of specific solutions to common JavaScript tasks. The tasks are collected into six different parts in the book, including Pure JavaScript, The DOM, Events, and Timers, UI Tricks, and more.

Each task is generally presented in a two-page spread, with the description of the task on the left and the code samples on the right. I say code "samples", because the "finished product" isn't presented on a silver platter for the reader, hence the need to not just know, but to be familiar with programming in general and JavaScript in specific right at the onset. Thus, you can think of this book as not for the JavaScript beginner, but as the next step in a JavaScript coder's progress in learning to apply practical solutions to JavaScript problems.

This is a good thing, since most beginner's JavaScript books focus on teaching the language but don't really teach you what to do with it. It would be really cool if a publisher like Pragmatic would publish a series of books on a language, starting with a complete beginner's primer, and then producing subsequent books aimed at different skill levels and applications for the language.

JavaScript really isn't just about the language. Except for very minor tasks, in production, you almost always are using a framework such as jQuery, Dojo, or MooTools. Although this book advertises itself as "framework agnostic", it (and the author, I suppose) tends to favor ProtoType as a framework. That said, it's not an exclusive ProtoType tutorial and does offer creative solutions to what are considered common problems.

Every book has a website, and this one is no exception. The book's official site is http://pragprog.com/titles/pg_js, where you can access the sample code, review the errata, and participate in forum conversations about the book's contents (though, there are only three threads, the most recent being November 2010 as of this writing).

Like all books that present specific tasks and solutions, Pragmatic Guide to JavaScript is limited by its own parameters. That is, it won't tell you how to solve problems beyond the 35 tasks presented in the book. However, the book also helps you learn different ways (hopefully) to solve problems you may have already confronted or with which you are currently struggling. Before buying, it's probably best to scan the table of contents and see if there are enough of the kinds of tasks that you need to explore. If so, pick up a copy and have at it...and have fun.

Review: Pragmatic Guide to Subversion

Author: Mike Mason
Format: Paperback, 150 pages
Publisher: Pragmatic Bookshelf; 1st edition (November 15, 2010)
ISBN-10: 1934356611
ISBN-13: 978-1934356616

I really like this book. It fits my needs perfectly. Let me explain.

I use Subversion in my day job as a technical writer for a software company. I use Ubuntu (9.10 Karmic Koala) and connect to the subversion repository via the shell. This is pretty much how the book was written, so all of the commands and tasks really fit my personal situation. Not only that, but the level of complexity (or lack thereof, if you're a total subversion guru) is right at my level.

OK, the book wasn't just written for me. Each task that is demonstrated in a bash shell is also presented in TortoiseSVN for Windows users and in Cornerstone for Mac OS X users. The book doesn't bias to only one interface, so a very wide subversion user base is served.

In general, a task is presented on two pages, both facing the reader, with the left page using narrative to describe the task, background information, and references to other relevant parts of the book, and the right page presenting the task. Each book section starts with a brief list of what it contains and provides the page numbers to how tasks are done in each of the interfaces, so you can easily skip over the bits that don't apply to you.

Pragmatic Guide to Subversion won't teach you how to be an expert subversion administrator, but it will teach you plenty about the hands-on of using subversion. You even get lessons on installing subversion, creating a respository, projects, and managing trunks, branches, tags, and more.

You can create a lab environment on your local computer or use the book's material to smooth over any rough spots in working with a production repository in a software development environment (like me). The book is simple, easy to read, and practical. If you work with subversion and keep having to bug the developers about how to manage your work in svn, go by the book and, as they say, RTFM.

Cheers.

HTML5: Up and Running

Author: Mark Pilgrim
Format: Paperback, 240 pages
Publisher: O'Reilly Media; 1 edition (August 25, 2010)
ISBN-10: 0596806027
ISBN-13: 978-0596806026

I became impatient with the history lesson in Chapter 1 and wanted to test drive HTML 5. What's different? What's new? Guess I'll have to work to find out. As the blurb I found at Amazon said of HTML5, It’s not one big thing. It's not a matter of learning a new markup language from scratch, which is both a good and bad thing. In fact, again to quote the author's blurb, “Upgrading” to HTML5 can be as simple as changing your doctype...In HTML5, there is only one doctype: !DOCTYPE html. That's encouraging, but just how easy is it to learn HTML5 and how easily can you learn it from Pilgrim's book? I went in search of the answers.

The first place I went was the book's Preface to see where I could find a link to the source code. I was pointed to the author's site Dive Into HTML5, which is the original book on which the book I'm reviewing is based, but it didn't have a clear cut link to anything called "source code". Maybe this is where It’s not one big thing comes back to bite me.

Chapter 2: Detecting HTML5 Features introduced me to Modernizr (yes, I spelled it right), which is a nifty JavaScript library that detects the HTML5 and CSS3 features your browser will support. It also creates a self-titled global JavaScript object containing the properties for each such feature. However, if your browser doesn't support certain HTML5 features, Modernizr won't fix it. But what about learning HTML5? We kind of got away from that.

Oh wait! Chapter 3: What Does It All Mean? helps. I found the link to a set of code examples which got me started. Then, as I progressed through the book and through the author's site, which runs in parallel and often in duplicate, I realized how the book was organized. This is no small feat, but maybe it was my expectations that made the task difficult. I was expecting a front-to-back guide to getting started with HTML5 and what I discovered was a collection of loose pieces in a box.

Learning HTML5 from Pilgrim's book is like putting together a jigsaw puzzle. When you first open the box, all you can see are a collection of jumbled pieces that, taken at a glance, don't make a lot of sense. If you had never encountered a jigsaw puzzle before, you might look, become confused as to what these pieces mean lying in such disarray, close the lid, and walk away looking for something more comprehensible.

One missing pieces of the puzzle, so to speak, is a knowledge for HTML4. Imagine the raw code of an HTML4 web page. Now imagine that you are presented with a list of tags and other markup elements you're not familiar with. What are you supposed to do with them? How do they work? What do they replace (if anything)? Using Chapter 3 on his web site for an example, I tried to navigate around until I could find something I could sink my teeth into.

Got a lesson on DOCTYPE, history lessons on the root and head elements, lots of other stuff to scan past, a section called A Long Digression Into How Browser Handle Unknown Elements, more stuff...more stuff...then it began to register. I started to hit spots on the pages that said stuff like, this is how we used to do things (add example of old code) and this is how you do it in HTML5 (add example of new code). The information is there, it's just not organized and called out the way I wanted it.

I went back to the book, compared it to the same pages on the author's site and "got" the organization. It may be a matter of how I think vs. how the author thinks, but from that point on, it was easier to tease what I wanted to know out of the book's pages.

I think HTML5 is fabulous but I'm not sure that HTML5: Up and Running is the best book to use as an introduction. It most definitely is not the best book to use for an introduction if you aren't familiar with HTML in general. I'd recommend navigating the author's website before buying the book. If you "get" the website, you'll "get" the book. They're pretty much the same thing.

Review: Getting Started with Processing

Authors: Casey Reas & Ben Fry
Format: Paperback, 208 pages
Publisher: Make; 1st edition (June 17, 2010)
ISBN-10: 144937980X
ISBN-13: 978-1449379803

I return to the topic of "learning how to program" every now and again because I haven't found a truly painless way of teaching programming to people who aren't naturally wired for it. I don't know if Processing is the answer, but it sure seems to be in the running. It has the benefit of being an open source program written to appeal to graphic designers who need or want to learn programming. Let me explain.

I've reanimated my interest in drawing and graphics recently (a long story) and am doing most of my work in GIMP, with which I'm fairly familiar. GIMP has a lot of wonderful features and a few drawbacks. I've tried to augment with Inkscape, but I've got so many other projects going, it's hard to dedicate the time to really get familiar with Inkscape. Then I received an invitation to review Getting Started with Processing, written by the creators of the Processing program. I thought that was probably (hopefully) a good sign, so I jumped at it.

At only 208 pages, it seemed like this would be a quick read (and my stack of books to review is growing rapidly, so I need to work through a few). Quick reading, yes. Quick to get through, no. Not with the practice this requires. Processing is an interface that uses common programming syntax to create static, 3D, and animated graphics. It doesn't look like much when you install it, but the potential of Processing is amazing.

Installation though was the first of my concerns. If you have 32-bit Windows, it's probably your best bet, but the book said that trying to install Processing onto my 64-bit Windows 7 machine was chancy at best. Installing on Linux is fine if you are savvy enough to do the job manually and not with a package manager. While Processing is open source, you won't find it in the Ubuntu repositories so apt-get or aptitude aren't options. I only say this because more regular desktop users are gravitating to Ubuntu so the "average" Linux user may no longer be as comfortable in the shell. Oh, for the Mac users out there, there is an installation file for Processing that'll work for you.

In some ways, the basic process is fairly simple. Input the proper code into the main input pane, click Run and your graphic appears. Yowza! Just like that. There are plenty of exercises to try out in the book, but I really would have liked it if the authors would have made the location of the code samples for the book more explicit. I visited

You can find tutorials and code samples for Processing at Processing.org but I assumed the code samples would be included on the tutorials page. My fault. Click the image of the book's cover on the site's main page and go to the books page to find the zip file containing the sample code. Of course, the site tutorials have a lot more examples of really spectacular work, so beyond the book, you can really have fun.

Yes, along with creating some really cool images, you will learn programming basics, or at least how to copy the examples of for loops and such that are presented. Also, having some basic idea of how web graphics work helps, particularly understanding RGB color, as you have to manually enter these values as part of the code.

I know Processing has been around for awhile but I would have appreciated a little more automation in the interface. It would be nice to click File -> Save As -> and save an image as a png or a tif, but it's a little more complicated than that. It's easier (for me, anyway) to export an image so that it can be uploaded to a web server than to create and save a simple static graphic.

There are plenty of graphics engines out there, including open source solutions, but nothing is truly intuitive and everything requires quite a bit of practice to gain proficiency. Progressing is the pretty much identical, but the advantage is that you also learn programming basics at the same time. If you have even a little bit of a background in programming and algebra, you're that much further ahead.

Comparing the book to the possibilities I discovered on the Processing site told me that the book only covers the basics. You won't be a Processing guru by page 206, but you will have the essentials of the language (which is very simple) and the interface, enough to make your own static and animated designs. The interface itself has examples (File -> Examples, and then choose the desired submenu), so you can see the code and the result of specific effects.

I'm probably not doing the book or the program sufficient justice in my review, and while most graphic designers will probably want to stick with PhotoShop and Illustrator (though they're hideously expensive), there's a lot to be learned and to be accomplished using Processor. If you don't believe me, go to the Processor exhibition page and see some impressive examples of work done exclusively in Processor.

Other value added pieces on the Processor site include a wiki and an active forum, so if you decide to take up Processor, you're certainly not alone.

Visit their site, explore the resources, get the book. With computer generated graphics and animations entering their mature stage in film and other venues, learning Processing could be a first step to a life long adventure. Enjoy.