My 19 Days of Python: Interlude 1

OK, it happened. The engine stalled and I haven't been able to get it started again. One of the things I know about programmers is that they program all the time, whether they're at work or not. Some of them keep brutal, late-night hours banging away at the keyboard, trying to solve arcane puzzles and get their code to work.

But it's been over two weeks since my "stall" and I've been avoiding Python and this blog like cancer.

To be honest, I have also been distracted by other priorities, so it's not like I've been sitting idle, staring at a blank blogger composition page, and wishing the muse would whisper something into my little, shell-like ear.

In the meantime, I've noticed two competing philosophies that relate to my current project and dilemma: should non-programmers code or not code? Actually, opinions vary, but I guess it depends on why you're invested (or not) in non-programmers learning to program.

Don't worry. In my case, the chances of me inflicting any program I may write into a professional setting is non-existent. The only place I will (and have) publish the fruits (such as they are) of my labors is here among the millions of chimpanzees vainly attempting to recreate the complete works of Shakespeare (or maybe just a sonnet or two).

Today, I realized that I ran out of excuses reasons for not returning to this project. The only question now is if I should try to pick up where I left off, or go all the way back (not that the distance is exactly vast at this point) to Day 1 of Downey's book, and start fresh (No, I wont write "Day 1A" and "Day 2A" if I choose the latter option)?

The first step is for me to go over everything, including the comments that have been languishing, and see where I stand. Hopefully this will mean that Day 4 will be forthcoming.

"The single most important skill for a computer scientist is problem solving." -Allen B. Downey

My 19 Days of Python: Day 3 and I Hit a Wall

Day 3 of My 19 Days of Python introduced me to my first real challenge (in a definitely "non-trivial" way) in attempting to think like a computer scientist. I don't know if it was all the jargon or if I was having trouble connecting the concepts with actual practice. Probably both. But I could just "feel" my brain slowing down as I was reading through Chapter 3: Functions."

What I do to prepare for a "day of Python" is to read through the chapter while sitting well away from a computer. I just read the pages and plan out what I will be doing and noticing areas where I know I will struggle. That way, when I'm back at the computer with Downey's book Think Python, I know the direction in which I'll need to travel and will be aware of the potholes and speed bumps in the road.

"Math functions. Why did it have to be math functions?" Chapter 3 introduces modules, which are files that contain the definitions of the functions and variables related to the module. But while Downey includes a bit of trigonometry (well beyond my skills as a mere writer), this chapter doesn't require the reader to actually do any trig (thankfully). For the sake of "mathphobic" people like me though, it would have been nicer if Downey had inserted another module to use as an example. On the other hand, after importing math, I can use "math.pi" in a statement without having to specifically define pi.

Chapter 3 is also the first time when the reader will have to compose or put together when they've learned in previous chapters, particularly Chapter 2. After reading the chapter, I actually go through the pages sitting at my computer and practicing what I'm reading as I blog (I haven't encountered Exercise 3.1 yet) and I think this helps map the concepts to the practice somewhat. Maybe more examples or practice exercises per concept would be useful, at least to me, when trying to "glue" an idea to an action (thinking of a function vs. writing a function). As of page 27, I've got a program, if you can all it that, containing two function definitions: "print_lyrics()" and "repeat_lyrics()" (more Monty Python fun and games). Now I need to write a script containing those definitions and use the script for the first two exercises.

For the first time, Downey mentions text editors (in the Debugging section) that are "aware" of Python and its "indentation needs," but he doesn't suggest any. Fortunately, gedit, which I regularly use in Ubuntu, lets you select which program or format you need including Python, so I'm OK there...sort of, as it still doesn't do indentation automatically. But the reader who knows absolutely nothing about this will be at a loss.

I forgot to end one of my strings with a double-quotation mark and also forgot that in the shell, to execute my script, I had to type "python repeat_lyrics.py" instead of just "repeat_lyrics.py." Once I corrected those little fubars, my wee script ran. Now on to Exercises 3.1 and 3.2. I guess you can change the order of function definitions and still have the program run OK. But these two exercises were absolutely benign next to what I knew was coming later.

I think part of what makes "Day 3" difficult is just keeping concepts like parameters, arguments, variables, statements, and functions straight. A nice picture or diagram would have helped. Actually, Downey did include a stack diagram, which is how programmers graphically keep track of which variables are used where, but I think this is part of a "think like a computer scientist" thing. A "non-scientific" picture of the overall process might have been helpful. I found a handy bullet point list at chucol.mml.cam.ac.uk to organize these terms for me somewhat.

I also had a heck of a time getting the first function in the Parameters and Arguments section of the chapter to work until I defined "bruce," which wasn't made explicit in the text. I did it wrong, since I treated the parameter "bruce" like a variable, but it worked. I wasn't satisfied however, completely exited from the shell, opened a new shell, and finally got it to work. I'll never know what I did wrong the first time, though.

I mentioned stack diagrams before and they're tricky because, at least as far as the example in Chapter 3 goes, they're read from the bottom up. The natural human tendency is to read from the top down. On the other hand, I'm a highly visual person, so it does help to have a picture to follow when trying to remember lots of little details, like parameters and variables inside a function.

There were a few concepts that were introduced but I'm not sure how much I was expected to understand. Pages 30 and 31 talked about __main__ as a built-in Python function and None as a special value (None comes back to haunt me later). After this, I was "treated" to information that seemed a little more digestible such as "Why Functions?" which I thought should have been at the beginning of the chapter, and how to import from within a module such as "from math import pi" rather than importing all of the math module with, "import math".

The Debugging section primarily addressed the various problems you can run into with text editors, although it still would have been nice if Downey would have expressed a preference. Maybe he wants his readers to "think outside the book" and do that investigation themselves. I dunno. The Glossary section is especially handy for people like me who have problems connecting concepts and "jargon" with what they actually do. But then, I'm stalling, because I'm living in dread of the Exercises section. Will I be able to successfully navigate the three remaining exercises without either cheating or giving up?

No. I cheated. I found the answer for Exercise 3.3 (I won't tell you where) and the problem made a sort of sense when I saw the answer. I copied it into a script and ran it and it worked. I think most of the required information was contained in the chapter, but I obviously don't "think like a computer scientist" because I couldn't intuitively put it together, even with the clue Downey inserted in the question for the exercise.

Actually, even after looking up the answers (or what were supposed to be the answers) for Exercise 3.4, they still don't make sense. This is typically where I get stuck trying to learn to program, think like a computer scientist, or whatever you want to call it. In a classroom setting (which is where I appear to belong), I could always tuck my tail between my legs and slink off to the instructor's office to ask what I'm doing wrong, but working alone (with everyone who reads this blog watching) at home, it doesn't quite work out so well.

I always imagine that a relatively intelligent person can pick up at least the basics of a particular discipline, including programming, but this is where I've hit my wall once again. Unless I can get past this point, I'll either be stuck at Day 3 forever or my efforts to try and "think like a computer scientist" will expire. Is there something different I could be doing or is there some way of presenting this information that would facilitate learning for a newbie better? From inside the problem, I can't tell.

Allen, are you out there?

My 19 Days of Python: Day 2

I'm tempted to call Day 2 of My 19 Days of Python, "You had me at 'unladen swallow.'"

Authors like to tell their readers a little bit about themselves in their books and Allen Downey is no exception. In reading Chapter 2: Variables, Expressions, and Statements, in his book Think Python, I discovered that he likes Monty Python and particularly their Holy Grail film, he's a runner, (based on "running" related exercises in the first two chapters of the book) and he (groan) likes math word problems.

Of course the Monty Python references in Chapter 2 could also be a subtle nod to the fact that the Python programming language is named after the comedy troupe and not the snake. But I'm sure all this isn't why you visited my blog today.

One of the other things I discovered about Downey's book on Day 2 is that exercises and conceptual content are intermixed within the chapter, at least up to a point. Most books that purport to teach you programming usually tell you about a particular topic in the first 90% of the chapter and save all of the exercises for the end. This typically forces the reader to go over an exercise and then thumb back to the relevant sections of the chapter to try and acquire the clues that will let them solve an exercise (which can be a real pain in books that have chapters that are 70 pages long).

When I encountered Exercise 2.1 on pages 14-15, I thought I had a handle on what the solution might be, but I couldn't be sure. I noticed in going over the book previously that there's no "answer" section, either at the end of the chapter or at the end of the book. I know that text books won't always have the answers to the exercises, and publishers in that case, will provide an instructor's edition of the book for the class teacher. I thought that kind of lets out those of us who are working at home, but maybe I was being unfair. Sometimes the author provides a website for the book with additional material, including help with the exercises.

The good news is that Downey does have a site for "Think Python." The bad news is that it wasn't what I expected: http://www.greenteapress.com/thinkpython/. There's more and different material that I certainly want to explore at a later date, but nothing that I could immediately apply to my "Day 2" experience. Fortunately I remembered that "Google is your friend" and discovered the solution to Exercise 2.1 at stackoverflow.com. (Sorry if I'm giving too much information away, but this series is supposed to be my unabridged thoughts and feelings as I move through each of my "Python days.")

I discovered that there are things about Python that can't be crammed into 300 pages and bitwise operators is one of them. That's OK since I'm still working on riding this bicycle with training wheels attached.

Downey introduced the concept of variables and then let me explore how variables work in an elementary way on the command line. The same for operators and operands, and expressions and statements. In just nine pages, I wasn't going to get a lot of practice. This seems just enough to give the reader a taste of what a concept is, what it means, and a tiny experience on how it works (and what happens when it doesn't work).

Exercise 2.2 requires that the reader run a small bit of code, both in interactive mode and in script mode. What may not be obvious to the rank beginner is that they will need to know how to create a script using a text editor, save the text file with a .py extension, and then on the command line, navigate to the location of the .py file and run it (you can't be in interactive mode on the command line when you run a script). Downey briefly mentioned this in Chapter 1, but most other beginning programming books will make this rather overt. For the sake of the total newbie, some step-by-step instructions, either in Chapter 1 or in the Introduction would be helpful.

The Order of Operations section sent me all the way back to ancient days and Algebra (not my most pleasant memories but after all, I am a writer, not a calculator). Somewhere in the book, Downey may have mentioned that 2**3 turns out to be 2³, but I don't remember where. It's important to understand this in order to perform one of exercises at the end of the book. If you suffer from chronic "mathphobia" or some similar malady, you may feel a bit of a twinge at this point in the chapter.

Looks like there will be a Debugging section in each chapter pointing to common problems or errors the reader may encounter. In the case of Chapter 2, common errors will be using illegal variable names or illegal characters. Add to that the common (for me) error of using a single quote at the begining of a string and a double-quote at the end such as, 'this is a bad string". Oops.

SyntaxError: EOL while scanning string literal

Exercise 2.3 gave me some practice with variable assignments and made me remember how to find the types of values (str, float, or int) I was working with. Exercise 2.4 contained three "evil" math word problems. I finally worked my way through the problems but it was more like a basic Algebra tutorial than learning how to program. Either the emphasis on math problems is because knowing how to solve these little puzzles is required for later chapters in the book, or because Downey just likes math word problems.

Suffice it to say that I augmented my ability to complete the exercises with a certain amount of searching on Google. Do I know more about programming at the end of Day 2? I suppose, but I still feel like I'm just skirting around the edges of Python, programming, and "thinking" computer science. Actually, I feel more like I'm back in high school, and I never wanted to take the Wayback Machine down that part of my history again.

We'll see what Day 3 brings.

My 19 Days of Python: Day 1

Chapter 1: The Way of the Program. The title of this chapter immediately made me think of "the Way of Bushido, but my mind takes random turns and makes strange associations from time to time. Still, it's either a very dramatic way to begin the journey of learning to think like a computer scientist, or at least something that sounds vaguely mystical or philosophical. Sort of like Zen and the Art of Motorcycle Maintenance. But I digress.

This is the very first chapter of Allen Downey's book Think Python, and the very first day of My 19 Days of Python. What will it teach me?

First off, the chapter starts differently than most of the beginning programming books I've read. It starts out conceptually. OK, a lot of books start out with the concepts of programming in general and the programming language being addressed in specific, but then they drone on for 50 or 70 or 165 pages boring the reader half to death and making them beg to either be put out of their misery, or to be allowed to write the 'Hello, World!' program and then move on.

Downey starts out with a conceptual section but it has two qualities I appreciated: 1. It was brief. 2. It was useful to the beginner (me, that is). What's a low-level language and why is it sometimes called a machine or assembly language? What's the difference between a low-level and a high-level language? You might not think these distinctions are important if you're just going to learn how to program, but the goal of the book is to get the reader to think like a computer scientist, which means the reader will have to understand some basic terms and concepts.

This also helps if you plan on talking to, or maybe just listening to more experienced programmers (and at this stage of the game, that includes just about everyone). That is, if you expect to understand little bits and pieces of what they're talking about. In addition, learning these distinctions helps the reader better explain what they're doing to others, which comes in real handy for people like me who are reviewing this book.

Actually, more than anything, I really appreciated the description of natural vs. formal languages. It makes a great deal of sense to talk about programming in these terms since everyone uses a natural language with which to communicate (in my case, English). We're all familiar with one or more formal languages, such as math or chemistry, and this helps the readers build a bridge from concepts and ideas we're familiar with to the one we're trying to learn; the formal language of programming.

This could have been a real snooze but as I said, the section is relatively brief and it's presented in a way that (for me at least) is engaging and even compelling.

Guilty admission: I skipped Exercise 1.1. It's actually placed in the middle of the chapter and not with the rest of the exercises at the end, and it could be considered a "pre-programming" exercise. However, I've done enough writing and editing in my career to be able to readily picture how a sentence looks when it is constructed using invalid tokens and/or with an invalid structure. Believe it or not, it's the reader's first foray (there I go with military metaphors, again) into parsing and debugging.

The bottom of page 7 has a section called "The First Program," and so I thought, "Here comes 'Hello, World!'".

Well, sort of. Downey briefly describes a print statement and lightly touches on Python 3, though it seems the reader will won't be asked to learn programming on Python's "bleeding edge."

I was a little surprised at the Glossary section being included near the end of the chapter, (each subsequent chapter has a Glossary) but it makes sense if part of the book's intent is to be used in the classroom. This also allows the reader to have immediate access (instead of repeatedly thumbing pages at the back of the book) to the meanings of specific terms used in the current chapter.

OK, that's the "set up," but most readers by page 11 will be ready to write their (our, my) first program in Python.

But wait a minute.

Downey briefly mentions Linux (well, really the UNIX command window) on page 3, but he didn't include some information that an absolutely beginning programmer/computer scientist will need to know. How do I run Python on my computer? It's not quite the same thing using Windows vs. Linux. What do I have to do?

Since I'm using Ubuntu 12.04 (Precise Pangolin) for all of my exercises, and I've read a few books on Python before, I know that Python is already installed on my Ubuntu PC and all I have to do is open a terminal, type "python" at the prompt, and presto, I'm in interactive mode.

If a total programming neophyte wants to get past this step, they'll need to go online and look up how to install Python and then run it on whatever operating system they're using.

Hint: If you're using Windows 7, try this handy tutorial. Assuming this book will eventually go into a second edition, or better yet, a second printing of this edition, I'd like to see Downey include a little information to help the reader find out if Python is already installed on their computer (Linux, Mac, Windows), and if not, how to install it. Then, of course, explain to the reader how to start a terminal session and start Python.

If this is a beginner's book, these are beginning steps.

The exercises.

I assume Exercise 1.2 is more a "look ahead" since a "programming virgin" will be able to review the information at http://python.org/ but not make a lot of use of it right now.

I've never seen the help feature for Python in the terminal before, so Exercise 1.3 was kind of interesting. Without any experience with Python though, the reader (me) can do about the same thing as he or she could do on the Python.org site; just noodle around and poke their nose into a few corners. There's no way to really know what you're looking at until later on (hopefully).

The last exercise is a math problem but not a horribly complicated one. It's more of a "familiarity" exercise designed to let the reader actually "do something" in interactive mode with Python.

At the end of Day 1 of my 19 Days of Python, I didn't feel really challenged, but so far what I have been asked to understand and perform has been well within my grasp. But then a lot of beginning programming books start out this way. Downey's introduction to the book even said so. Chapter 2 is called "Variables, Expressions, and Statements," so I assume that's when I'll actually have to do more than convert kilometers to miles.

At this stage in my journey, I'm concerned with two things: 1. The ability to retain information as I move from one chapter to the next, so that I can use information I learned on one day when I'm performing exercises on subsequent days. 2. (this one is critical) Eventually being able to understand enough Python and to think, even a little bit, enough like a computer scientist to write simple programs in Python on my own, and not just copy them from the book or other sources.

Will I be able to get that far and will Downey's book be able to take me there? That's what we're going to find out together as I progress through the next 18 days of Python.

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.

Fall 2012: My Two New CompTIA A+ Books Are Being Published!

Nearly a month ago, I announced the publication of a book I've heavily contributed to, Guide to TCP/IP, Fourth Edition which will be available for purchase in just a few days. Today, I have the pleasure of talking about two more books that I wrote or contributed to that will soon become available.

CompTIA A+ Complete Lab Manual is near and dear to my heart, since I have been the sole author on this book (previously Sybex's PC Technician Street Smarts series) since it began. The "Complete Lab Manual" has been retitled but essentially is the third edition of "Street Smarts" and historically, it has represented some of my best work.

The Book Description at Amazon says:

Designed to complement CompTIA A+ Complete Study Guide, this hands-on companion book takes you step by step through the tasks a PC technician is likely to face on any given day. It supports the theory explained in the test-prep guide with additional practical application, increasing a new PC technician's confidence and marketability. Various scenarios incorporate roadblocks that may occur on the job and explain ways to successfully complete the task at hand. In addition, each task is mapped to a specific A+ exam objective for exams 220-801 and 220-802.

Tasks are divided into categories: hardware and software installation, hardware and software maintenance, and installing and upgrading operating systems, networks, and security systems.

"CompTIA A+ Complete Lab Manual" comes out as a first edition on September 25, 2012, but you can pre-order it now at Amazon

I have a second CompTIA A+ book coming out on October 18: CompTIA A+ Certification Practice Exams, Second Edition, written with Michael Chapple (Mike Pastore hasn't been involved for a few editions now).

This book is essentially a really big bank of questions with which to test yourself against when preparing for the two A+ exams; over 1,000 questions in fact. The beauty of this book is that it hits every single exam domain item required by CompTIA. I got the good news via email just last night:

Good news. I just received word that your book has passed the CompTIA Approved Quality Content review. Your book will now be recognized as a CompTIA Authorized product. Many thanks to the diligence you’ve shown ensuring 100% coverage of the objectives. It was evident as you passed the review without one objective missed.

This book is designed to be used with CompTIA A+ Certification Study Guide, Eighth Edition, written by Jane and Charles Holcombe. You'll be able to buy both books as a boxed set in January

Writing two books at the same time isn't always a lot of fun (very little free time when you take my "day job" into consideration) but when the books are done, the sense of accomplishment is fantastic. I can't wait to see both books at my local Barnes and Noble and Borders.

If the CompTIA A+ exams are in your future, I'd highly recommend that you take a look at both of my new books. The Lab Manual will give you the hands-on experience you need, and the Practice Exams will provide an extremely thorough platform to use in testing your knowledge before taking on "the real thing."

Enjoy.

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.

Codecademy Revisited

I recently received an email notice in my inbox "Announcing Python at Codecademy". Well, it's about time. I reviewed codecademy's learn to program tutorial about a year ago (featuring JavaScript), but the lessons ended and there was no place to go, so I stopped visiting their site.

A year passed and I pretty much forgot about Codecademy until I received their email. Curious, I decided to browse the site.

The home page looked the same as I remembered it. "Learn to code". "Get Started (it's free)". I clicked the big, green button and the page dimmed except for the field with the active cursor and the prompt to type in your name with "quotes" around it. I was taken through the beginning of the JavaScript module, the "teaser" for the course, by putting in my name, finding out its length, and doing some elementary math computations. Once I got through the intro, I was prompted to start the next section.

What I was trying to find out is if the JavaScript tutorial had gotten past "while loops". It was difficult to tell what the whole JavaScript course consisted of since each lesson forces you to go step-by-step rather than skipping ahead. As far as I could tell, the JavaScript tutorial had been significantly re-worked and ended on variables after about five sessions.

I wasn't interested in going through the JavaScript tutorial at that point and clicked the "Learn" button at the top of the page. What I found was that after a year, Codecademy has a lot more to offer:

• JavaScript Fundamentals
• Python
• Web Fundamentals
• JQuery
• Code Year

It didn't look like the different offerings were necessarily interdependent, but you could go through the JavaScript Fundamentals course and then hit Web Fundamentals to learn HTML and CSS, progress through JQuery as your JavaScript library, and then conclude with Code Year to learn how to build websites with JavaScript. I know Python doesn't seem to fit the path, but it is (or seems to be) the newest module as it's "beta" tag discloses.

It will take a little time go to through a significant portion of the tutorials in order to learn enough to update my original review, but I did want to let anyone reading this know that Codecademy is back on my radar after a year.

I'll post subsequent blogs and let you know what I think about the details.

Guide to TCP/IP, Fourth Edition

Well, look what I found the other day.

I was the "junior" person on the team that collaborated to make this edition of the classic Guide to TCP/IP possible. Ed Tittel has been with this book since the beginning and Jeff Carrell is the unsurpassed wizard of all things networking. I was lucky to even be able to contribute to this book in some small way and to work with these fine people (I haven't forgotten that Laura Chappell's name is on the cover, but truth be told, she hasn't contributed a single word to this book since the first edition).

Because this is a text book, the publisher usually wants to give "cover credit" only to people who are well-known in the field. My name only comes after a "with" on the cover (and no mention in the author's section for the book in Amazon), but it's still a feather in my cap to have my name see the light of day at all. I'm very appreciative of the authors and editors involved for allowing this kudo to go to me.

I'm really excited to see this book being published next month and I believe it represents one of my best efforts in recent years. To find out more and to order the book, go to Amazon.com (clickable link).

Dreaming of Mars One

Mars One will establish the first human settlement on Mars in 2023. A habitable settlement will be waiting for the settlers when they land. The settlement will support them while they live and work on Mars the rest of their lives. Every two years after 2023 an additional crew will arrive, such that there is a real living, growing community on Mars. Mars One has created a technical plan for this mission that is as simple as possible. For every component of the mission we have identified at least one potential supplier. Mars One invites you to join us in this next giant leap for mankind!

-from the Mars One home page.

I came across this quite by accident but when I did, a power surge of childhood fantasies flooded my memory and my imagination. Actually living on another planet.

Wow!

I was a kid in the 1960s and from that point of view, the 21st century was where everything incredible was going to happen. It was also, far, far away, so I knew that I'd probably be a little too old to colonize the moon or be part of the first manned mission to Mars.

But I could dream.

As a side note, I also fantasized about spending a year in Antarctica. Strange, I know, but the stark landscape, scarcity of people, and the sheer romantic drama of it all really appealed to me.

Of course, I really didn't consider how boring it would have been or how dangerous. But hey, I was 14.

As far as I can tell, Mars One is real or it's trying to be. Apparently, it's the dream of a small number of investors, engineers, and scientists who don't want to visit Mars; they want to live there...soon.

OK, maybe "they" won't be living on Mars (at least not all of them) but they want to develop the technology and the implementation that would result in other human beings taking a one way trip from Earth to Mars and establishing a small (at first) permanent colony.

Stupid, crazy, or brilliant?

Mars One plans to establish the first human settlement on Mars by April 2023. The first crew of four astronauts emigrate to their new planet from Earth, a journey that takes seven months. A new team will join the settlement every two years. By 2033 there will be over twenty people living, working and flourishing on Mars, their new home.
-Mars One Mission and Vision

It all sounds real, but anyone can create a website.

The Mars One FAQ page digs into all of the pesky questions you might have about such an insane enterprise such as, is this for real, where does the money come from, and how am I going to live on Mars...forever?

Even being extremely optimistic about all this, accomplishing the specific goals and timeframes stated on the site is an incredible long shot. We really don't know the long-term (as in years and decades) effect of living on a planet with significantly less gravity than Earth on the human body. We don't have the proven technology to transport human beings to another planet, build living quarters, and establish a sustainable living environment out of the little you are able to bring with you plus the available resources in the Martian environment.

Oh yeah, and it looks like they have little to no money to even start this whole thing off.

All that said, if I were a lot younger, really healthy, really intelligent, educated in a relevant field, and completely unattached, I might just fill out an application.

Why?

The adventure. The romantic drama. The absolute thrill of really travelling through interplanetary space in real life and then actually living on another planet; having a home address that ends, "Planet: Mars".

OK, it's a dopey idea. Once the spaceship launched, I'd probably get space sick and spend the seven month one-way trip puking. I'd have to really get along with the other three people in the ship since living quarters would be tight (much more spacious in the colony, if the FAQ page is correct). Then, there's all the hard work in putting together the inflatable structures and constructing the technology that would somehow make breathable air, drinkable water, and edible food.

And then it would probably get boring and lonely. A whole planet, and at first, I'd be sharing it with only three other human beings. No way to lose myself in a crowd. On the other hand, I could walk 30 minutes in any direction away from the camp and be really alone if I wanted to be.

Really alone.

In any event, Mars One will have no appreciable impact on my life. I lack 100% of the necessary qualifications, and I'm not physically, emotionally, or in any other sense built for this sort of thing. Plus my wife would kill me if I tried to go.

No, I don't actually want to go to Mars.

But imagining the adventure is just terrific. Ah to be 14 years old again.

And to dream.

Cloning Two Hard Drives with Acronis True Image Home 2011

This should work. For the most part, it has worked, but I have just one little hiccup that's driving me insane. Let me explain.

Last August, I posted my adventures of trying to clone my undersized OS drive to a much larger hard drive using Acronis True Image Home 2011. It was enormously frustrating and job that should have taken an hour or two took days instead. Ultimately, it worked, but no thanks to the documentation provided by the fine folks who made Acronis True Image.

Time passed.

Ultimately my "new" (actually surplus drive I bought at work for $5.00) drive failed and I had to put the old OS drive back in my production PC.

More time passed.

The OS drive continued to accumulate system files and available space shrank to a dangerous minimum. I bought a couple of 1 TB drives from Dell and intended on transferring both my OS and data disks to them, insuring ample space for the foreseeable future.

I got lazy and waited a long time. But today's the day to make the move, clone both old drives to both new drives.

Cloning the OS drive was easier than I expected. I followed the old directions provided by Acronis and it worked like a charm. The PC booted to Windows 7 Professional from the new, cloned drive with no muss and no fuss. The cloning process just worked, and it worked pretty fast. I figured I might as well clone my data drive to a larger disk since I was already under the hood, so to speak.

I plugged the second 1 TB drive into the available SATA channel, booted into Windows, started Acronis, chose to clone disk 2 to disk 3 and performed the clone. The operation went exactly the same the second time as it did the first time.

Hooray.

I swapped the larger data drive for the smaller, booted and...

Yikes!

Can't find Bootmgr error.

What?

But the only thing I changed since my last successful boot is swapping a larger cloned drive for the smaller original data drive...Disk D.

I swapped the smaller drive D back in and booted. No dang problem whatsoever.

I left the "extra" larger data drive plugged in and opened Computer. It sees the C, D, and F drives. The D and F drives contain exactly the same files and directories. The only difference is that the F drive is bigger.
I did the clone operation over again just for giggles but the result was the same. When the smaller, original data drive is the D drive, the computer boots to the OS on the C drive. When I have the larger cloned data drive plugged in to the smaller drive's SATA channel (I swear, that's the only difference), nada tostada.

I am giving up my diagnostics at this point and throwing myself on the mercy of the Internet. What the heck went wrong.

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.

Review: Kindle Fire Web Experience

I've already reviewed the video and book reading capacities of my Kindle Fire. Time to turn to the web experience. How is it?

One of the things I was looking forward to when I got my Kindle Fire was being able to wirelessly surf the web while not being tied down to a desktop or laptop computer. I expected the experience to be somewhat slower but wasn't prepared for how much longer it seemed to take for a webpage to download into Kindle's Silk web browser. Not quite as bad as dial-up, but I wasn't used to waiting for (by today's standards) ages for a webpage to appear.

To get to a webpage, you can select Web in the overhead menu or select amazon, IMDb, or Facebook from the shortcuts at the bottom of the main page. Selecting Web opens the last webpage you visited, which in my case was marvel.com. I admit that one of the ideas I had was to be able to read comicbooks digitally using my Kindle Fire. I figured buying an annual subscription at Marvel would let me read all of the old comicbooks I loved as a kid but not take up any valuable storage space in the home (or costing me billions of dollars to replace everything I had when I was young).

But first, the general web experience.

To go to another site by typing in the URL, tap the URL bar to make the keyboard appear. Depending on your relative "texting" skills (mine are awful), you can type in the address of the site you want to visit. There's even a .com button so you are spared entering the suffix as individual characters. As you type, the history shows the URLs you've most recently visited, and you can select any of those if it's where you want to go.

While my fingers aren't overly fat, if there are a lot of links or buttons on the page I want to press, I tend to tap and miss the mark. Changing the orientation of the screen from portrait to landscape helps a bit, but of course, I sacrifice the length of the page. When I do "fat finger" the wrong link or button. I have to hit the back button, wait for the previous page to load, and then try again. I don't know if this is a problem in Silk, the website in question not being well designed for mobile web devices, or me being clumsy. It's just my experience. I do find that using a very gentle tap seems to work better in these delecate cases.

Now on to comicbooks at Marvel.

This one I blame on whoever designed Marvel's website.

I'd love to read 1960s vintage comicbooks. It was the silver age and my childhood and Marvel was just a lot of fun back then. You can read the first few pages of any comic for free, so I thought I'd try my Kindle Fire out by trying to read the beginning of an old Spider-Man comic. Here's what happened.

When the cover of the comic loads into the browser, there are two green arrows (no reference to the comicbook character intended) at the bottom of the screen for forward and back. To advance to page one, I have to successfully tap the right arrow. But nothing happens when I do. Or I get a white screen with an exclamation mark in the middle and have to hit the browser's back button. Unlike a book on Kindle, I can't just use a sliding finger motion to move to the next page.

I tried changing to landscape orientation to see if that helped. After multiple taps, page 1 finally appeared. Changing back to portrait orientation makes the page readable. At this point, I can use my finger to drag the page and move to page 2, but there's an annoying tendency to snap back to page 1 when I remove my finger. Frankly, the entire experience is more frustrating than it's worth. I don't want to have to sit at my desktop to read comics. It's something best done sitting in a living room chair or reading in bed late at night.

I don't know if Kindle Fire could improve this problem or if it's something the folks at Marvel.com have to fix. However, the Silk web browser, though passable, still leaves a lot to be desired. Or maybe mobile web browsing still needs to be perfected. In any case, as of now, browsing the web with my Kindle fire is not the main reason I'll be using the device.

SOPA Blackout