Programming Reading Material What I’m Up To

JavaScript books that you can read online for FREE

My actual setup at my old office (February 3, 2020), where I coded in JavaScript all day.


  1. You’ve decided to learn JavaScript (or just need a refresher), and
  2. you’re short on cash due to the current economic situation

…you’re in luck! There are a couple of good books on JavaScript whose contents are available to read online, free of charge!

The first of these books is Eloquent JavaScript, Third Edition, written by Marijn Haverbeke and published by No Starch Press. It’s not just an introduction to JavaScript, but an introduction to programming in general. It’s beginner-friendly, which is one of the reasons why it’s the main book for the first part of the JavaScript/React course that I’m teaching.

You can Eloquent JavaScript, Third Edition online here.

The second book is JavaScript for Impatient Programmers, ECMAScript 2020 edition, written by Dr. Alex Rauschmeyer. Its coverage of JavaScript is more complete, but it’s a little less beginner-friendly, which is why it’s the backup book for my course. I’m going to incorporate some of its content into the course, and point students to the online edition if they’d like some additional reading material.

You can read JavaScript for Impatient Programmers, ECMAScript 2020 edition online here.

Current Events Programming Tampa Bay What I’m Up To

I’m teaching an online JavaScript/React programming course!

The folks at Computer Coach Training Center must like my work, because they have me teaching another course — a 12-week, 3-times-a-week, 4-hours-per-session Intro to JavaScript and React programming!

I taught the Intro to Python Coding course on Computer Coach’s behalf in July and August. That one took place twice a week over 6 weeks, with each session lasting 4 hours.

The Intro to JavaScript and React Programming course starts next Tuesday evening, and happens Tuesday and Thursday evenings and Saturday mornings for 12 weeks.

The first six weeks of the course will be dedicated to gaining a solid understanding of JavaScript programming. During that part of the course, the text will be Eloquent JavaScript, Third Edition, which remains one of the most-recommended books for beginners. I’ll use it as a basis, but also add some additional material and cover changes in the 2019 and 2020 versions of JavaScript.

The second six weeks of the course will be all about React.js — and nothing but React. Yes, people use React in combination with all sorts of other technologies, but in order to get a solid grounding in React, it’s helpful to start by working purely in React. Hence Pure React, May 2020 Edition (which includes the newly-introduced feature of hooks) is the text for this section of the course.

If you’ve ever been in any of my Tampa iOS Meetup sessions, you’ve seen my teaching technique — you’re not passively watching slides, but coding along with me, and even experimenting, just to see what happens. That’s I what I did with the Python class, and it’s what I’m going to do with the JavaScript/React class — enter code, see what happens, and gain experience along the way. It’s learning by doing.

If this course interests you, it starts next Tuesday, and you can sign up by contacting Computer Coach.


Current Events Deals Programming Reading Material

Happy Programmer’s Day! / Fanatical’s deal on FREE programming books

The origin of Programmer’s Day

The 256th day of the year (the 100th day in hexadecimal) is known as the Day of the Programmer. On most years, it’s September 13th, but on leap years — which includes this one — it’s September 12th.

The day was proposed by two Russian programmers, Valentin Balt and Michael Cherviakov, who petitioned their government to recognize this day. The recognition came on September 11, 2009 when Russian president Dmitry Medvedev signed the decree, making it official.

The deal

Whenever an “official unofficial” day like this happens, there’s always at least one vendor offering a deal. Day of the Programmer is no exception, and Fanatical are offering a bundle of three books from Packt for free in its honor!

Yes, I know that Packt is almost industry shorthand for “Not necessarily good, but not necessarily bad,” but at this price, you can’t say that these books aren’t worth every penny.

Here’s a video that goes a little deeper into deal, and a little deeper into poking a little fun at Packt:


“My code isn’t working” is a great problems-and-solutions flowchart for Python programmers

Tap to view at full size.

Dr. Martin Jones, the author behind the book and site Python for Biologists, has come up with a chart to help Python programmers when their code doesn’t work and they can’t figure out why.

He writes:

A few times a year, I have the job of teaching a bunch of people who have never written code before how to program from scratch. The nature of programming being what it is, the same error crop up every time in a very predictable pattern. I usually encourage my students to go through a step-by-step troubleshooting process when trying to fix misbehaving code, in which we go through these common errors one by one and see if they could be causing the problem. Today, I decided to finally write this troubleshooting process down and turn it into a flowchart in non-threatening colours.

Behold, the “my code isn’t working” step-by-step troubleshooting guide! Follow the arrows to find the likely cause of your problem – if the first thing you reach doesn’t work, then back up and try again.

It’s intended for programmers who are new to Python, but even experienced Pythonistas sometimes get distracted and stuck on simple things. I’m keeping a copy handy.

You can tap on the image above to view it at full size, and there’s also a printable PDF version as well.

[ Thanks to my UC Baseline classmate Daniel Jimenez for the find! ]

Programming What I’m Up To

A more Pythonic approach to one of my “Capture the Flag” solutions

In my article about the Capture the Flag at The Undercroft in which I recently participated, I wrote about my solution to this particular challenge:

Your answer lies in the 1’s and 0’s…

0010111 00001111 00010111, 00011001 00001111 10101 00000001 00010010 00000101 00010010 00001001 00000111 00001000 00010100

(Make sure to use the comma, and spaces correctly)

The first part of my solution was turning those numbers into a list. Copy the numbers into a text editor, stick 0b in front of each one, and then turn the sequence into a Python list:

Paste the list into a Python REPL and then display its contents to see the numbers in decimal:

The next step is to convert those numbers into letters. Once again, the Unicode/ASCII value for “A” is 65, so the trick is to add 64 to each number and convert the resulting number into a character.

Here’s how I did that:

I could’ve gone super-functional and done it in one line:

Tap to find out more about lambda functions in Python.

Between lambda and map(), there’s a whole lot of functional programming concepts to solve a relatively simple problem.

I could write a whole article — and I probably should — based on just that single line of code, but in the meantime, I thought I’d post an easier, more Pythonic solution.

This simpler solution uses good ol’ list comprehensions:

Most programming languages don’t have list comprehensions. In those languages, if you want to perform some operation on every item in an array, you use a mapping function, typically named map(), but sometimes collect() or select().

Hence my original solution with lambda and map() — it’s force of habit from working in JavaScript, Kotlin, Ruby, and Swift, which don’t have Python’s nifty list comprehensions.

Current Events Programming

Happy 10th Whyday!

Today, August 19th, is Whyday! I wrote a longer post about it earlier this week, but if you want the short version, it’s this: It’s a day to celebrate creativity and whimsy using technology.

Whyday is named after the engimatic programmer/artist who operated under the name “Why the Lucky Stiff” (or _why for short), and his story is told in this video:

My favorite quote from _why, which he Tweeted before he took down his Twitter account:

when you don’t create things, you become defined by your tastes rather than ability. your tastes only narrow & exclude people. so create.

In the spirit of _why, let’s all use this day to start a creative project or try something new!

Find out more about Whyday ay

Current Events Programming

“Whyday’s” tenth anniversary is Wednesday!

While sorting out the image archives of this blog over the weekend, I noticed this photo:

In case you don’t recognize it, it’s a picture an underappreciated classic of programming literature known as why’s (poignant) guide to Ruby, a book written by the enigmatic programmer and artist who went by the nom de plume of why the lucky stiff.

That’s when it hit me:

Is Whyday still a thing?

And if not, can we make it a thing (or at least capture its spirit) again?

why’s (poignant) guide to Ruby

During the the ’aughts, Ruby exploded from obscure programming language whose best documentation was in Japanese and became the darling tool of startups everywhere. A good chunk of that popularity came from Ruby’s killer app, Rails.

However, at least some of wave of Ruby programmers that appeared at the time has to be credited to _why. Yes, that’s the commonly-accepted short from of his name, and no, the underscore is not a typo. If Rails’ preternaturally handsome creator  David Heinemeier Hansson made Ruby cool, _why, with his “skinnier, edgier Jack Black” appearance and style, made Ruby fun.

While there were a number of books on Ruby at that time, why’s Ruby tutorial, why’s (poignant) guide to Ruby stood out. First, there’s that title. But that was only the beginning.

The book’s first page looked like this:

It featured whimsical recurring characters, such as the cartoon foxes whose catchphrase was “Chunky bacon!”…

…not-quite-sane science adventurers, who, when not dynamiting retirement homes, will teach you the basics of classes and branching…

The “Dr. Cham” chapter features code like this:

And let’s not forget the elf with a pet ham and the cat:

For new programmers, it was an approachable book that didn’t try to bury you with jargon. For experienced developers, it provided a refreshing take on programming concepts. If you were looking for a Ruby reference, you were reading the wrong book. But whether you’d been a programmer for 20 minutes or 20 years, it was a fascinating, engrossing read that made you think about programming differently.

If that wasn’t enough, the book came with its own soundtrack. In addition to being a programmer and illustrator, _why was also a musician with a tendency towards the “indie rock”-style, and he wrote a song for each chapter.

Thankfully, the book and soundtrack preserved online. Go ahead and give it a look. I’ll wait for you here.

_why’s code

In addition to the poignant guide, _why also wrote a fair bit of code, some of which became de facto or even de jure Ruby standards:

  • Hpricot, an HTML parser that became the Ruby de facto standard for a while. The current de facto standard parser, Aaron Patterson’s Nokogiri, was designed to use Hpricot’s syntax.
  • RedCloth, a module for using the Textile markup language in Ruby.
  • Markaby — short for “markup as Ruby — which was a DSL to generate valid HTML using Ruby blocks and methods instead of tags.
  • Camping, a Markaby-based microframework inspired by Rails. Its code amount to less than 4 kilobytes.
  • Hobix, a YAML-based weblog application written in Ruby.
  • MouseHole, a personal web proxy that can rewrite the web à la Greasemonkey
  • Syck, a YAML library for C, Ruby, and several other languages. For a time, Syck was a part of Ruby’s standard libraries. It’s still available as a gem.
  • unHoly, which converted Ruby bytecode to Python bytecode, which made it possible to run your Ruby applications on the Google Application Engine.
  • bloopsaphone, a crossplatform chiptune-like synth, based on PortAudio with a Ruby frontend.

Of his creations, my favorites were the ones that were part of his mission to solve what he called “The Little Coder’s Predicament,” which is that in spite of the fact that we had better computers, software, and networks in the 2000s, the barrier to entry for programming — especially for kids — had become much higher:

In the 1980s, you could look up from your Commodore 64, hours after purchasing it, with a glossy feeling of empowerment, achieved by the pattern of notes spewing from the speaker grille in an endless loop. You were part of the movement to help machines sing! You were a programmer! The Atari 800 people had BASIC. They know what I’m talking about. And the TI-994A guys don’t need to say a word, because the TI could say it for them!


The old machines don’t compare to the desktops of today, or to the consoles of today. But, sadly, current versions of Windows have no immediately accessible programming languages. And what’s a kid going to do with Visual Basic? Build a modal dialog? Forget coding for XBox. Requires registration in the XBox Developer Program. Otherwise, you gotta crack the sucker open. GameCube? GameBoy? Playstation 2?

His solution to the Predicament was to first write Shoes, a simple toolkit for Ruby that use web page concepts to build desktop GUI apps for macOS, Windows, and Linux:

Shoes formed the basis of Hackety Hack, an IDE combined with a tutorials system that was a lot of fun to use. Here’s a screenshot of Hackery Hack in action, being used to write a “Hello, World!” program:

Since _why was developing this tool for children, he went straight to the subject matter experts: 25 children and their parents, whom he consulted and used as testers as he worked on the project.

(And because this was a _why project, it had a manifesto. Read it; it’s good.)

Here’s the Hackery Hack site:

_why’s performances

I was at RailsConf 2006, where _why gave a multimedia extravaganza of an evening keynote presentation. It was something I’d never seen before or since at a keynote: Part programming lecture, part video show, part concert complete with his band, the Thirsty Cups. You either left this performance either scratching your head or wanting to take programming to strange new heights.

After the show, I had a chance to hang out in an unexpected gathering of people that included both _why and Martin Fowler, which was an amusing, enlightening, and amazing experience.

_why’s disappearance

As you were reading this article, you may have noticed that I have only referred to its subject as “why the lucky stiff” or “_why”.

You may have wondered — quite fittingly — why?

There’s no definitive answer, but there are some hints.

Like a lot of creatives, the person behind the “why the lucky stiff” persona is an intensely private person. _why could be the out-there guy performing songs about how Ruby’s error handling just sounded so much more capable and effective with its rescue statement versus other languages’ try and catch (“try to catch me, I’m falling!” he’d joke), but the person lurking behind the mask wanted privacy during his downtime.

_why made it a point to reveal as little about himself as possible, and most of us were happy to indulge him. Most people were happy to simply know and address him as “why”, and in the community, it was a point of etiquette to not try and dig too deeply.

Of course, even in those pre-GamerGate, pre-“shitposting”, pre-chan-ruining-lots-of-the-net times, _why’s secrecy didn’t sit well with some people, who for some reason, just had to know the name of the person behind the _why identity was. So in 2009, they dug deep, and eventually found his name (as well as his wife’s) and publicized it.

_why may have also been a victim of Open Source Success, when a little project that you worked on in order to scratch a creative itch becomes so popular that many other projects depend on it. Suddenly, your project is no longer just a little thing you worked on, but a big thing that people expect you to maintain and upgrade. I’m reminded of a line from Byrne Hobart’s article, Working in Public and the Economics of Free, and it’s simultaneously hilarious and sad:

Running a successful open source project is just Good Will Hunting in reverse, where you start out as a respected genius and end up being a janitor who gets into fights.

As a result of the factors listed above, plus some others probably known to no one else but _why, the internet presence of Why the Lucky Stiff vanished on August 19, 2009. His sites, blogs, social media, and code repositories all vanished. I wrote about it the day after it happened.

Luckily for us, all of his work — well, the work that he’d released to the public, anyway — was open source, and with the effort of some dedicated Ruby and Rails developers, his projects were saved. Some people even took them over and expanded on them. Other projects became the basis of newer, improved projects.


In 2010, a year after _why vanished into the night, Glenn Vandenburg declared that August 19 should be celebrated as Whyday.

Here’s what he wrote on the Whyday site:

On August 19, 2009, Why the Lucky Stiff withdrew from the online community. We in the Ruby community wish him well, but we really miss him.


Why gave us a lot of cool software and other things, but what he really gave to the Ruby community was a spirit of freedom, whimsy, and creativity. When Why took the stage at the first RailsConf, in 2006, he strapped on his guitar, walked to the microphone, and yelled “Put your best practices away!”


Discipline, care, and responsibility are important; we owe our customers, employers, team members, and families to take our work seriously. At the same time, though, we need to play. If we don’t occasionally break out of the mold of our “best practices,” we can easily miss many wonderful ideas, some of which can bear rich fruit (just as Camping and Hpricot led to Sinatra and Nokogiri).

On Whyday, we’re encouraged to borrow a page from _why’s book and creative, instructive, collaborative, and crazy. The site suggested doing things such as:

  • See how far you can push some weird corner of Ruby (or some other language).
  • Choose a tight constraint (for example, 4 kilobytes of source code) and see what you can do with it.
  • Try that wild idea you’ve been sitting on because it’s too crazy.
  • You can work to maintain some of the software Why left us (although Why is more about creating beautiful new things than polishing old things).
  • On the other hand, Why is passionate about teaching programming to children. So improvements to Hackety Hack would be welcome.
  • Or take direct action along those lines, and teach Ruby to a child.

The Whyday site lives on, but it’s been a while since I’ve seen anyone make a fuss about Whyday.

I thought that given that we’re in the middle of a pandemic and that we’re all spending more time at home (at least I hope we are), there’s no better time that now to bring back the spirit of Whyday.

This Whyday, I plan to celebrate by starting some kind of creative project. (Actually, I plan to start a couple.) If you can, you should start one, too! 

Recommended reading and viewing

Got eighteen and a half minutes? Then you’ll want to watch this documentary on Why the Lucky Stiff and how he inspired the Ruby developer community:

Articles on _why: