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.
(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:
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.
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.
>>> characters = [chr(number + 64) for number in numbers]
>>> characters
['W', 'O', 'W', 'Y', 'O', 'U', 'A', 'R', 'E', 'R', 'I', 'G', 'H', 'T']
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.
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!
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:
def dr_chams_timeline( year )
case year
when 1894
"Born."
when 1895..1913
"Childhood in Lousville, Winston Co., Mississippi."
when 1914..1919
"Worked at a pecan nursery; punched a Quaker."
when 1920..1928
"Sailed in the Brotherhood of River Wisdomming, which journeyed \
the Mississippi River and engaged in thoughtful self-improvement, \
where he finished 140 credit hours from their Oarniversity."
when 1929
"Returned to Louisville to pen a novel about time-travelling pheasant hunters."
when 1930..1933
"Took up a respectable career insuring pecan nurseries. Financially stable, he \
spent time in Brazil and New Mexico, buying up rare paper-shell pecan trees. Just \
as his notoriety came to a crescendo: gosh, he tried to buried himself alive."
when 1934
"Went back to writing his novel. Changed the hunters to insurance tycoons and the \
pheasants to Quakers."
when 1935..1940
"Took Arthur Cone, the Headmaster of the Brotherhood of River Wisdomming, as a \
houseguest. Together for five years, engineering and inventing."
when 1941
"And this is where things got interesting."
end
end
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.
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.
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 à laGreasemonkey
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.
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.
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:
Last night was the final night of the Intro to Python Coding course that I’ve been teaching on behalf of Computer Coach for the past five weeks — Mondays and Wednesdays, 6:00 p.m. to 10:00 p.m..
I’d like to congratulate the students! It’s not easy to spend four hours an evening twice a week learning something completely new and unknown to you, but the students did just that. 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 — we entered code and saw what happened, hopefully learning along the way.
As a farewell present to the students, I sent them a copy of So You Want to be a Wizard, a little “zine” written by Julia “b0rk” Evans for programmers who are starting out that’s full of good advice. I hope it helps them through those moments that every programmer has, when nothing seems to work and all you want to do is throw your computer out the window. I’ve posted it here as well, partly because it’s full of good advice that even experts need to remember, and partly because I want to make sure that everyone knows about Julia’s works.
Even the table of contents lets you that that you’re in for a fun read:
Julia has a whole set of zines, some of which are free…
…and some fancier ones, which come at a reasonable price, even for groups:
Once again, congratulations to the Intro to Python Coding students!
For the benefit of my classmates in the UC Baseline program (see this earlier post to find out what it’s about), I’m posting a regular series of notes here on Global Nerdy to supplement the class material. As our instructor Tremere said, what’s covered in the class merely scratches the surface, and that we should use it as a launching point for our own independent study.
The “binary numbers” portion of day 1 at UC Baseline. Tap to see at full size.
There was a lot of introductory material to cover on day one of the Hardware 101 portion of the program, and there’s one bit of basic but important material that I think deserves a closer look, especially for my fellow classmates who’ve never had to deal with it before: How binary and hexadecimal numbers are related.
The problem with binary
(for humans, anyway)
Consider the population of Florida. According to the U.S. Census Bureau, on July 1, 2019, that number was estimated to be 21,477,737 in base 10, a.k.a. the decimal system.
Here’s the same number, expressed in base 2, a.k.a. the binary system: 1010001111011100101101001.
That’s the problem with binary numbers: Because they use only two digits, 0 and 1, they grow in length extremely quickly, which makes them hard for humans to read. Can you tell the difference between 100000000000000000000000 and 1000000000000000000000000? Be careful, because those two numbers are significantly different — one is twice the size of the other!
(Think about it: In the decimal system, you make a number ten times as large by tacking a 0 onto the end. For the exact same reason, tacking a 0 onto the end of binary number doubles that number.)
Hexadecimal is an easier way to write binary numbers
Once again, the problem is that:
Binary numbers, because they use only two digits — 0 and 1 — get really long really quickly, and
Decimal numbers don’t convert easily to binary.
What we need is a numerical system that:
Can represent really big numbers with relatively few characters, and
Converts easily to binary.
Luckily for us, there’s a numerical system that fits this description: Hexadecimal. The root words for hexadecimal are hexa (Greek for “six”) and decimal (from Latin for “ten”), and it means base 16.
Using 4 binary digits, you can represent the numbers 0 through 15:
Decimal
Binary
0
0000
1
0001
2
0010
3
0011
4
0100
5
0101
6
0110
7
0111
8
1000
9
1001
10
1010
11
1011
12
1100
13
1101
14
1110
15
1111
Hexadecimal is the answer to the question “What if we had a set of digits that represented the 16 numbers of 0 through 15?”
Let’s repeat the above table, this time with hexadecimal digits:
Decimal
Binary
Hexadecimal
0
0000
0
1
0001
1
2
0010
2
3
0011
3
4
0100
4
5
0101
5
6
0110
6
7
0111
7
8
1000
8
9
1001
9
10
1010
A
11
1011
B
12
1100
C
13
1101
D
14
1110
E
15
1111
F
Hexadecimal gives us easier-to-read numbers where each digit represents a group of 4 binary digits. Because of this, it’s easy to convert back and forth between binary and hexadecimal.
Since we’re creatures of base 10, we have the single characters to represent the digits 0 through 9, but no single character to represent 10, 11, 12, 13, 14, and 15, which are digits in hexadecimal. To work around this problem, hexadecimal uses the first 6 letters from the Roman alphabet: A, B, C, D, E, and F.
That’s a hard number to read, and if you had to manually enter it, the odds are pretty good that you’d make a mistake. Let’s convert it to its hexadecimal equivalent.
We do this by first breaking that binary number into groups of 4 bits (remember, a single hexadecimal number represents 4 bits, and “bit” is a portmanteau for “binary digit”):
1100 0010 1010 1001
Now let’s use the table above to look up the hexadecimal digit for each of those groups of 4:
1100 0010 1010 1001
C 2 A 9
There you have it:
The decimal representation of the number is 49,833,
How to indicate if you’re writing a number in decimal, binary, or hexadecimal form
Because we’re base 10 creatures, we simply write decimal numbers as-is:
49,833
To indicate that a number is in binary, we prefix it with the number zero followed by a lowercase b:
0b1100001010101001
This is a convention used in many programming languages. Try it for yourself in JavaScript:
# This will print "49833" in the console
console.log(0b1100001010101001)
Or if you prefer, Python:
# This will print "49833" in the console
print(0b1100001010101001)
To indicate that a number is in hexadecimal, we prefix it with the number zero followed by a lowercase x:
oxC2A9
Once again, try it for yourself in JavaScript:
# This will print "49833" in the console
print(0xc2a9)
print(0xC2A9)
Or Python:
# Both of these will print "49833" in the console
print(0xc2a9)
print(0xC2A9)
Common grouping of binary numbers and hexadecimal
4 bits: A half-byte, tetrade, or nybble
A single hexadecimal digit represents 4 bits, and my favorite term for a group of 4 bits is nybble. The 4 bits that make up a nybble can represent the numbers 0 through 15.
“Nybble” is one of those computer science-y jokes that’s based on the fact that a group of 8 bits is called a byte. I’ve seen the terms half-byte and tetrade also used.
8 bits: A byte
Two hexadecimal digits represent 8 bits, and a group of 8 bits is called a byte. The 8 bits that make up a byte can represent the numbers 0 through 255, or the numbers -128 through 127.
In the era of the first general-purpose microprocessors, the data bus was 8 bits wide, and so byte was the standard unit of data. Every character in the ASCII character set can be expressed in a single byte. Each of the 4 numbers in an IPv4 address is a byte.
16 bits: A word
Four hexadecimal digits represent 16 bits, and a group of 16 bits is most often called a word. The 16 bits that make up a word can represent the numbers 0 through 65,535 (a number sometimes referred to as “64K”), or the numbers -32,768 through 32,767.
If you were computing in the late ’80s or early ’90s — the era covered by Windows 1 through 3 or Macs in the classic chassis — you were using a 16-bit machine. That meant that it stored data a word at a time.
32 bits: A double word or DWORD
Eight hexadecimal digits represent 32 bits, and a group of 32 bits is often called a double word or DWORD; I’ve also heard the unimaginative term “32-bit word”. The 32 bits that make up a word can represent the numbers 0 through 4,294,967,295 (a number sometimes referred to as “4 gigs”), or the numbers −2,147,483,648 through 2,147,483,647.
32-bit operating systems and computers came about in the mid-1990s. Some are still in use today, although they’d now be considered older or “legacy” systems.
The IPv4 address system uses 32 bits, which means that it can represent a maximum of 4,294,967,29 internet addresses. That’s fewer addresses than there are people on earth, and as you might expect, we’re running out of these addresses. There are all manner of workarounds, but the real solution is for everyone to switch to IPv6, which uses 128 bits, which allows for over 3 × 1038 addresses — enough to assign 100 addresses to every atom on the surface of the earth.
64 bits: A quadruple word or QWORD
16 hexadecimal digits represent 64 bits, and a group of 64 bits is often called a quadruple word, quad word, or QWORD; I’ve also heard the unimaginative term “64-bit word”. The 64 bits that make up a word can represent the numbers 0 through 18,446,744,073,709,551,615 (about 18.4 quintillion), or the numbers -9,223,372,036,854,775,808 to 9,223,372,036,854,775,807 (minus 9.2 quintillion through 9.2 quintillion).
If you have a Mac and it dates from 2007 or later, it’s probably a 64-bit machine. macOS has supported 32- and 64-bit applications, but from macOS Catalina (which came out in 2019) onward, it’s 64-bit only. As for Windows-based machines, if your processor is an Intel Core 2/i3/i5/i7/i9 or AMD Athlon 64/Opteron/Sempron/Turion 64/Phenom/Athlon II/Phenom II/FX/Ryzen/Epyc, you have a 64-bit processor.
Need more explanation?
The Khan Academy has a pretty good explainer of the decimal, binary, and hexadecimal number systems:
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.
