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.