Showing posts with label programming. Show all posts
Showing posts with label programming. Show all posts

Friday, January 17, 2014

Taking A Different Approach To JavaScript

I enjoyed my Codecademy experience in learning JavaScript, but especially toward the end, I felt like I was having to look up things constantly. I posted a query on their forums and got a very nice response back from one of the mods explaining that this was perfectly normal. He suggested retaking the course to help cement the new concepts and haunting the Q & A forums for more info. In the meantime, I found something else.

Interestingly enough, I found out in one of the Codecademy Q & A's about a site called JavaScript.is (Sexy). It sounds like a silly name, but I think it's actually going to be the solution to my situation. They have an eight week tutorial that I just began titled How to Learn JavaScript Properly.

There's a textbook involved, and they recommend a related reddit study group, signing up for Stack Overflow and, interestingly enough, using Codecademy for practice.

You can click the link I provided to see all of the requirements for the class, but I like the organization and structure involved. It also provides me with the format for repeating the Codecademy JavaScript course as well as adding more content via the other class elements.

Since this is a work requirement, I need to stick with it and I guess that's the secret, especially for people like me who aren't "natural" programmers. I write in English everyday for a variety of purposes, professional, semi-professional, and personal, so I have plenty of practice in that arena. If I did the same with JavaScript, even though I find it less intuitive than my native written and spoken language, I can only imagine that coding in JavaScript will get a little bit easier.

I haven't forgotten HTML5 and CSS3, but I'm not sure combining that with JavaScript in the same learning effort is going to be effective. I may need a different plan for that learning path. Right now, in addition to my professional and personal life, I'm focusing on this plan.

Wish me luck.

I'll be back at some point to let you know how things are panning out.

Sunday, December 15, 2013

Ten Days Down the Road

This always happens when I start studying. I get sidetracked. My actual work started to heat up, preventing me from proceeding with the CSS book. I did receive Training Guide: Programming in HTML5 with JavaScript and CSS nearly a week ago and started noodling around in that, but didn't get too far.

I was advised this would be a good book to learn from even without working in Windows 8 and with Visual Studio (I'm not interested in the certification, just learning the information), but that means I get to skip a few chapters. The book is organized in "waves," so to speak, so you first get introduced to HTML, then JavaScript, then CSS. Later, you get more advanced information on HTML, then JavaScript, then CSS again, and so on. I'm only on page 32, so you can imagine things are still pretty elementary.

On the other hand, I did start the Codecademy JavaScript tutorial, but as usual, I got bogged down toward the end of "Introduction to Functions in JS." I've appealed for help to the forums so I guess I'll see what the error of my ways is by the by. 

I thought I was doing reasonably well there for awhile, but then the problems seemed to assume more knowledge than I had. I thought I had missed some key portion of a previous lesson and went back, working my way forward again, but it didn't help. One exercise gives me both an error and also passes me on to the next exercise, so that's confusing. On top of that, I thought my code was written exactly to specs.

The other exercise is beyond me. I don't find enough information in the instructions or the previous exercises to allow me to write code that doesn't complain at me. I know for actual programmers, these lessons would be painfully elementary, but to me, they're locked black boxes with no way in.

My real problem is that I don't naturally think like a programmer. I've read arguments back and forth on the web about whether anyone can learn to code. Sort of like the message in the Pixar film Ratatouille (2007), "Anyone can cook." 

I believe anyone can cook but not that anyone can cook well. The question remains, can anyone learn to code, even at an elementary level, or is programming a skill set for a specific population that no one outside that group can acquire? I feel like Codecademy's "teaching style" is good in that they don't just lead you around by the nose, giving you all the code upfront and then simply having you copy and paste, and then run short, small programs. On the other hand, when you get stuck, you're stuck. The hints on the last two exercises weren't helpful in the slightest.

Forums can be incredibly slow to respond, depending on how attentive the mods are, so I don't know how long I'll need to wait for a clue let alone an answer. A large part of programming is debugging, but that requires a sufficient understanding of how the code works to find the problem. I'm not there yet. The point of setting these work goals is to see if I can ever get there. Now that my job performance is riding on it, I'll have to figure out a way or be prepared (at least) to eat large helpings of humble pie.

That's my report, such as it is.

Addendum: Not that much time passed and I got two helpful responses on the forum. Turns out I made some minor, newbie errors. Oh duh. Now, back on track.

Thursday, December 5, 2013

Day Three of My Forey into CSS

After the limitations I discovered in learning CSS as part of the Codecademy Web Fundamentals track, I decided I needed something a little more in-depth. I considered another online program such as Lynda.com, but they cost bucks. OK, not a lot of bucks, but I didn't feel like bugging my boss for his credit card again, especially since I already made him buy me this book.

So I decided to look through some of the other books I've collected over the years and have been ignoring, and I selected this book from 2009. Yes, I know there's a more recent edition available, but this one is in hand right now, so why wait? It seems enough to get me started and I'll have a leg up on CSS by the time the other book arrives.

The question now is whether or not to just concentrate on CSS or to do as Codecademy previously (through automation) suggested and move on to JavaScript via their tutorial? Interestingly enough, that track is telling me that I finished the first section in Introduction to Programming. I hadn't realized I'd let so many of these tasks incomplete until revisiting the site of my old haunts, or perhaps I should call them "my old sins."

I suppose it wouldn't hurt to at least see what I was supposed to have learned in the distant past. Especially since the book I ordered from Amazon yesterday addresses HTML5, CSS3, and (drumroll) JavaScript.

The CSS book I'm using at the moment is rather slow going, but it's taking me over some really basic stuff I went through at Codecademy, and I could probably use the review to continue cementing this into my leaky memory. Oh, I installed the TextWrangler code editor on my Mac at work. Not the greatest tool I've used, but it's free and does a descent job. I really miss how the online editor at Codecademy worked. You could toggle back and forth between the HTML and CSS tabs to do the editing, but the Results window instantly showed your changes. Beats having to continually refresh a web browser.

I find it interesting that after ignoring this blog for over a year, I should be writing daily blog posts here. Go figure.

Wednesday, September 26, 2012

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

Tuesday, September 11, 2012

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?

Monday, September 10, 2012

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 23, 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.

Sunday, September 9, 2012

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.

Friday, September 7, 2012

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.

Friday, August 24, 2012

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.

Friday, August 17, 2012

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.

Saturday, December 3, 2011

Review of CoffeeScript: Accelerated JavaScript Development

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

First off, before even getting into the book, what is "CoffeeScript"? For a quick and dirty definition, I hit up Wikipedia:
CoffeeScript is a programming language that transcompiles to JavaScript. The language adds syntactic sugar inspired by Ruby, Python and Haskell to enhance JavaScript's brevity and readability, as well as adding more sophisticated features like array comprehension and pattern matching. CoffeeScript compiles predictably to JavaScript and programs can be written with less code (typically 1/3 fewer lines) with no effect on runtime performance. Since March 16, 2011, CoffeeScript has been on GitHub's list of most-watched projects.
I suppose I could say that if you don't know what CoffeeScript is, you shouldn't be reading Burnham's book, but that's probably not true. According to the "Who This Book Is For" section in the Preface:
If you're interested in learning CoffeeScript, you've come to the right place! However, because CoffeeScript is so closely linked to JavaScript, there are really two languages running through this book - and not enough pages to teach you both. Therefore, I'm going to assume that you know some JavaScript."
The author goes on to say that even if you know just a bit of JavaScript, you should be OK, but rank novices at the language might want to get to know a bit of JavaScript before tackling CoffeeScript. Also, since Ruby inspired a lot of the features in CoffeeScript, having a bit of Ruby background is a plus.

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

How to get CoffeeScript.

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

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

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

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

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

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

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

Wednesday, August 31, 2011

Learn to Program Online at Codecademy.com

My friend Judah Himango suggested that I look at the Codecademy.com site. It's just about the easiest way to learn JavaScript anyone could imagine, and it's relatively fun, too. There is a bit of a hook involved. Although you can start the lessons without creating an account, after a few lessons, you are offered the opportunity to either create an account (it's free) or lose your work to date. I created an account.

Once I did, I could continue with the lessons, quit with I got tired/bored (my work was saved automatically), and then sign in later to continue with my saved work. On signing in, you are shown a summary of the lessons you've completed and which ones you have yet to start. After you successfully finish so many lessons, you "earn" achievement badges. For making it through the first four of eight lessons, I earned two achievements.

The lessons are fun, easy, but inflexible. If you deviate from the lesson in the slightest way, you will get an error message. While a hint is provided with different steps in each lesson, if you get stuck, you don't get any other help except to offer feedback about the lesson. There's no way to just get the full solution presented to you. That's good on the one hand, because you aren't tempted to give up too easily and it "forces" you to try and figure out what went wrong. On the other hand, it you truly get stuck...you're stuck. Lessons build on one another (which is a good idea) so if you can't figure one part of a lesson out, you won't be able to just skip it and move on.

The scope of the course, "Getting Started with Programming", only spans eight lessons, ending after the lesson on "while loops". There's no obvious way for me to tell after lesson eight if I'll be able to continue with what I've started to learn. I clicked the "Courses" link in the header menu expecting to see extended (possibly for pay) courses, but all that appeared was the eight lessons for the basic course.

Once you log out, you're returned to the start page. The other options on that page include subscribing to an email newsletter, and sharing your experience with your lessons on twitter and Facebook. Presumably, this is part of how Codecademy plans to market itself. Oh, there is a section called "Create a Lesson", so the Codecademy folks are interested in external participation in expanding their project.

Codecademy seems like it's a project in the making. Since they harvest your email address, both as a condition of creating an account, and during the pre-account lesson when you're asked to enter your email address, I expect that once Codecademy has a sufficient database of names, they'll advance to the next phase of whatever their plan happens to be. That could either mean further lessons will be for a fee or they may continue to offer more advanced lessons without charging.

I'm hardly the first blogger to post a review. About two weeks ago, TechCrunch published their write up on Codecademy, including a talking to Codecademy co-founders Zach Sims and Ryan Bubinski. Sims commented several times on the TechCrunch blog including, "Hi everyone - we might be a little slow right now but we're working on getting things faster. Thanks so much!"

Other thoughts: The "subtitle" of the course "Getting Started with Programming" is "Time to become a coding ninja". That sounds as if Codecademy's intent is to encourage its students to become proficient and even expert at coding. Three things will have to happen. The first one is obvious. They'll need more lessons. A lot more lessons.

The next two points I take from my own experience. You can't really learn something unless you do it all the time. People don't learn to read and write when they do it only occasionally. They need to practice reading and writing all of the time until it becomes second nature. Even if you teach someone the basics of programming, if they don't have any way to apply it on a frequent basis, they'll lose those skills again. Building in some form of continual practice with periodic refreshers of material covered previously will help.

Finally, students will eventually have to learn to "build" something practical. Learning how to determine the length of a string is fine and dandy, but so what? How does that figure into writing a program that actually does something? Lessons will eventually have to lead to practical projects so that at some point, the students will be able to program independently.

Of course, the real power in any programming language is its libraries, so learning JavaScript will have to turn into something like learning jQuery. Another things to consider is whether or not JavaScript will be the only programming language Codecademy chooses to teach. A lot can be done with JavaScript but hardly everything. A server-side language such as PHP might make a good addition. Beyond that, it just depends on what sort of long-term goals Codecademy has for its project.

Presently, although Codecademy has gotten a lot more attention than they expected in the short amount of time they've been online, I'm sure they'd love more. If you know little or nothing about programming but would like to learn in an interactive environment, go to Codecademy.com and try it out.

Monday, August 8, 2011

The Python Standard Library by Example: A Review

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

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

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

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

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

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

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

Wednesday, February 2, 2011

Pragmatic Guide to JavaScript

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

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

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

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

Often, my favorite part of a book such as this is the Who is this book for section. Here is where you'll find the "official" mission of the book and sometimes where you'll find the inconsistency between the book's stated purpose and how it's actually written. Here's the first sentence:
This book is not really intended to teach you "JavaScript the language".
What? That's not the impression I got from the back cover. As the "Who is this book not for section continues, it says that the language is pretty easy on its own so, if you know any programming at all, learning the basics (loops, variables, and so on) isn't much of a chore. The book even recommends the "JavaScript Core skills" section of Opera's Web Standards Curriculum.

So who really should buy this book?

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

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

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

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

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

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

Friday, July 9, 2010

Review: Getting Started with Processing

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

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

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

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

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

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

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

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

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

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

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

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

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

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


Share/Bookmark

Tuesday, December 29, 2009

Practical Guide to Linux Commands, Editors, and Shell Programming

Author: Mark G. Sobell
Format: Paperback, 1080 pages
Publisher: Prentice Hall PTR; 2nd edition (November 29, 2009)
ISBN-10: 0131367366
ISBN-13: 978-013136

The reviews on the first edition of this book were overwhelmingly favorable, so you'd expect Sobell's second edition to be at least on par. What I want to know before handing over my hard earned green, is why I should buy the second edition? What has changed so much in the world of Linux in 4 or 5 years that makes a difference? With those questions in mind and tome in hand, off I went in pursuit of the answers.

The back cover blurb touts the advantages of this book, including the fact that it includes both system administration info and programming data; material that is usually archived in two different books (with the idea that system admins and programmers don't live in the same universe). Another advantage is that the book is "distro agnostic", meaning that it doesn't favor Ubuntu and other Debian-esque flavors vs. Fedora and other Red Hat variants. Surprisingly, though I suppose it shouldn't be, info on Mac administration is also included (and why not...go back far enough and the common ancient ancestor is UNIX). But what's new?

Gold dust was discovered in the Preface in the New in this edition section. Turns out, Mac OS X CLI info is brand new in this edition, so if you love Linux and Mac, or at least you have to administer them, you're in luck. Also, there's a new chapter on Perl, new rsynch secure copy utility material, and content covering 15 new utilities that weren't included in the first edition. There have also been some organizational changes. Three indexes have been added to make it easier for the reader to find specific information, including an index just for Mac OS X.

The first five chapters or so bring the reader up to speed on Linux and Mac (mostly Linux) in general, including a basic overview of the operating systems and where to find things. Common utilities, file system basics, and an introduction to the shell are all available. Up to this point, you don't have to be much of a guru in anything or even much of a power user, so students who want to be admins and shell programmers are welcome here.

They say there are two types of people in the world; vi people and emac people. I happen to be the former but understand (reluctantly) that there are plenty of folks out there that prefer the latter editor. Sobell serves both populations with a chapter devoted to each editor. Keep in mind there are entire books written on these editors, but you may not have the desire or time to buy and read them.

The book then moves the reader on to more detailed information on the shells. The bash (bourne again shell) shell is included as well as the TC shell, which is the expanded version of the C Shell (csh and yes, it's pronounced "sea shell"). I've never worked with a Linux system that didn't have the bash shell as the default, but if you really want something "completely different", here's your opportunity to learn about the TC shell.

The next part of the book: "Programming Tools" includes some of the main changes in this edition. The brand-new Perl chapter is inserted here, as is the chapter on rsync. Don't expect to learn Perl from scratch by reading a single chapter in this book, but if you have a background in Perl or just in general scripting, it will help in Linux shell programming. My personal preference is Python, but you can't have everything.

The last main section is the command reference and it is basically a long list of man pages. The twist is that some of them (they're marked) are commands specific to Mac. I'm not sure if it would be faster for the experienced Linux user to just read a man page in the shell or to look it up on Sobell's book, but they're here, anyway. That said, there are additional details present, as least for some of the commands, including examples, discussion areas, and the occasional diagram you won't find on a man page.

I probably could have lived without the Glossary in the Appendix section, but if the book is supposed to speak to newbies as well as power users and admins, then it makes sense. As I previously mentioned, one index includes nothing but Mac OS X notes, which is a nice plus, but I suppose it assumes you're working in a mixed Linux/Mac environment. If you administer just Macs, I can only imagine you have the required Mac-oriented texts on your bookshelf.

The main advantage of this book and others like it, is not that it contains any radically new information or that it's put together in a unique way. The reason you want to buy this book is that all this information collected entirely between two covers. The entire body of Linux administration data is more or less easily located on the web and is no more than a search string in Google away, but the Internet is a lousy library. By comparison, Sobell's Practical Guide to Linux Commands, Editors, and Shell Programming is a model of organization.

The second edition of this successful book does what it's supposed to; update information for a changing technology landscape, add a few new bits for spice, and otherwise maintains the original level of quality. You could read it cover-to-cover, but something this size works better as a reference for the learner or the experienced person who needs a quick reminder (you can't remember everything). If you administer Linux, program Linux, or both, this book most likely has what you need. If those roles are your goals, then this book will carry you to the target. Enjoy.

You can find and purchase Mark Sobell's book at Amazon.com.

Share/Bookmark

Wednesday, December 9, 2009

What do Interpreted Programming Languages have in Common? Part II

I begin this tutorial a few weeks ago with Part I and received some very nice comments correcting my (fortunately) minor errors. This isn't a tutorial about how to program in a specific language or even really about how to program. I wanted to show the common structure of interpreted programming languages in the hopes of revealing some common threads, rather than focusing on the ins and outs of one language. I've heard it said that if you learn one langauge, it makes learning the next one easier. My problem is I get lost in the nuances of the language in question and lose track of the basic structure of programming. I've created this tutorial series to try and correct that. This tutorial is for my education as much as anyone else's so I welcome comments but, as I said before, be polite. This is about learning.

Speaking of Languages, code examples are presented in JavaScript, Python, and Ruby. I figured this represented a healthy cross-section of commonly used interpreted languages. Now, on with the show.

Controlling Program Flow, Part I

In our last episode (sorry, couldn't resist), we left off with Arrays and Booleans. The tutorial picks up with methods of flow control. According to Wikipedia, flow control is "a statement whose execution results in a choice being made as to which of two or more paths should be followed. For non-strict functional languages, functions and language constructs exist to achieve the same result, but they are not necessarily called control flow statements." In other words, it's a way of making decisions within the program given different conditions. Speaking of which:

Conditions: These statements in a program act as a decision tree or like a set of intersections in a city. The decisions or route are dependent on what conditions are or are not true (speaking of Booleans) or where you're trying to go. The basic structure of a conditional statement looks something like this:

if (condition)
{
     conditional code;
}

That's a very general example, of course, but it gives you a place to start.

if statements:
If statements are more or less the same in all three of the languages we've been working with:

JavaScript Sample Code:

var value = 0;
if (value > 0)
{
     alert("Greater than zero");
}
Python Sample Code:

n = 0
if n > 0:
     print ("Greater than zero")
Ruby Sample Code:
n = 0
if n > 0
     return "Greater than zero"
end
Of course, that's not much of a decision tree. Each program has different conditional statements that are similar but not exactly the same, to deal with a decision that is either this or that:

if-else statements:
The following examples are equivalent and look almost the same, but not quite:

JavaScript Example Code:
var name = "Jim";
if (name == "Jim")
{
     alert("Your name is Jim.");
}
else {
     alert("You are not Jim.");
}
Python Example Code:
name = "Jim"
if (name == "Jim"):
     print ("Your name is Jim")
else:
     print ("Your name is not Jim")
Ruby Example Code:
name = "Jim"
if name == "Jim"
     print "Your name is Jim"
else
     print "Your name is not Jim"
end
That takes care of "the fork in the road", so to speak, but what if there's more than one decision to make? It can't be just "Jim" or "no Jim" all the time. What about Jim, Bill, and Heather, for example?

else-if statements:
Depending on the program, this statement is called else-if, or elif, or elsif, but you get the idea.

JavaScript Code Example:
if (name == "Jim")
{
     alert ("Good Morning, Jim.");
}
else if (name == "Bill");
{
     alert ("Good Morning, Bill.");
}
else if (name == "Heather");
{
     alert ("Good Morning, Heather.");
}
else
{
     alert ("You're not on the list.");
}
Python Example Code:

if (name == "Jim"):
     print ("Good Morning, Jim.")
elif (name == "Bill"):
     print ("Good Morning, Bill.")
elif (name == "Heather"):
     print ("Good Morning, Heather.")
else:
     print ("You're not on the list.")
Ruby Example Code:
if name == "Jim"
     return ("Your name is Jim.")
elsif name == "Bill
     return ("Your name is Bill.")
elsif name == "Heather"
     return ("Your name is Heather.")
else
     return ("You're not on the list.")
end
print name
As you can see, there really isn't much difference between now each language expresses conditional statements. The details are quite minor and I hope this all illustrates the common factors in such statements, which is the important piece to learn in this lesson.


Time limitations are forcing me to make Part II shorter than I originally intended, but at least I've got it up and on the blog. Pick through everything and see if I left any holes. If so, let me know. If not, then all is good, at least for Part II. See you next time for Part III: Loops.


Share/Bookmark

Sunday, October 11, 2009

Python: Converting from one temperature scale to another is easy, but what about eight?

In just about any class or set of tutorials involving beginning programming, there's usually a problem or set of problems having to do with converting temperatures. Just about everyone has had to write a wee bit of code to convert Fahrenheit to Celsius or vice versa. That's not much of a chore. However, there are eight major temperature scales available (though some are around now only for their historical value), according to wikipedia. What if you had to write a program that let a user convert a temperature from any of these scales to any of these scales?

Do you have any idea how many if statements you'd have to write? On the previously referenced wikipedia page, there are eight tables (one for each temperature scale) so converting from any of scales to any of scales would, in theory, require 8 times 7 or 56 if statements (it wouldn't be 8 times 8 because you wouldn't convert from a scale to itself). That's an awful lot of coding and there's got to be an easier way.

Actually, there's more than one way to make it easier, but this is a tutorial that is, or should be, within the grasp of a relative newbie to Python. I took a stab at it and came up with what I think is a pretty straightforward bit of programming that doesn't require a lot of typing.

Oh. I forgot. There is a specific requirement for the solution to the problem. The code must convert from the source scale temp to central or canonical scale, such as Celsius, and then must convert that value from Celsius (for example) to the target scale temp. Here's what I came up with. I don't claim this is the best possible solution, but I don't think there's anything fundamentally wrong with it, either (I checked with a higher power to be sure). See what you think. Here it is:

t = float(raw_input("Please enter the temp: "))
source = raw_input("Please enter the source temp scale: ")
target = raw_input("Please enter the target temp scale: ")

if t < 1000000.0:
    if source == "k":
        cel = t -273.15
    elif source == "c":
        cel = t
    elif source == "f":
        cel = (t - 32) * 5.0 / 9.0
    elif source == "r":
        cel = (t - 491.67) * 5.0 / 9.0
    elif source == "d":
        cel = 100.0 - t * 2.0 / 3.0
    elif source == "n":
        cel = t * 100.0 / 33.0
    elif source == "re":
        cel = t * 5.0 / 4.0
    elif source == "ro":
        cel = (t - 7.5) * 40.0 / 21.0
    if target == "k":
        answer = cel + 273.15
    elif target == "c":
        answer = cel
    elif target == "f":
        answer = cel * 9.0 / 5.0 + 32.0
    elif target == "r":
        answer = (cel + 273.15) * 9.0 / 5.0
    elif target == "d":
        answer = (100.0 - cel) * 3.0 / 2.0
    elif target == "n":
        answer = cel *  33.0 / 100.0
    elif target == "re":
        answer = cel * 4.0 / 5.0
    elif target == "ro":
        answer = cel * 21.0 / 40.0 + 7.5

print answer
I found all of the formulas for conversions at wikipedia, too. You can copy this code into a text editor and save it as something like covert.py, then run it to see how it works for you. Share/Bookmark