make better_mistakes

Monday Check-In

This week I will move my stuff out of my apartment and fly to Guangzhou. This obviously leaves me with a lack of time to work on projects. My project this week is to apply to Hungry Academy. I’ll write a post before Friday to report how that went.

The Hidden Chapter

I didn’t read five chapters this week, and that’s partially because of the hidden chapter in all tech books. I believe the hidden chapter is a bug, but in documenting it I hope to make it in to a feature.

Tech publishing firms deals with different issues than other publishers. Tech books have small audiences which leads to higher prices per book as the economy of scale is the only thing that makes a paperback a possibly profitable prospect. (Though most books make very little. The secret of publishing is making small bets on unknowns and then creating and maintaining audiences for authors who find an audience with their first book.)

Tech authors aren’t paid much relative to the compensation they can receive if they work as consultants. I don’t have any info to compare their wage to authors in other sections of the bookstore, but anyone who has enough expertise to write a good tech book also has enough expertise to find better paying work elsewhere.

They also have to strike a difficult balance, being entertaining without being overly verbose, being informative without dulling the reader into a coma. I have been routinely surprised at how well written the prose is in tech books, and it comes from a high attention to detail on the authors part, as well as the early readers of the book, who are generally uncompensated.

To prepare a book for printing the publisher must work in rigid formats which preserve layouts and encourage migraines. There may be some editing staff that review the prose, but the publishing industry has scaled down heavily on copy-editors and other related quality assurance staff as the industry has digitized.

This is all to say, mistakes are made in tech books. They are to be expected.

However, a small mistake can have large ramifications for a coder just learning a new technology. I’ve been working through Rails 3 In Action written by Ryan Bigg and published by Manning Books. This morning at six, after a night of insomnia, I began working through the third chapter. My PDF was generated earlier this week, or it was delivered to me at the least, and I assumed that any known errata would already be incorporated. It turns out this is not the case.

Instead, I had an issue with using a version of Cucumber that had come out since the book was released and breaks the functionality of the code I was working through. The error got me confused, and I decided to take a rest. After a two hour nap and some veggie huevos rancheros, I tried my hand at it again. I figured out that my issue was related to using the wrong version of Cucumber. I tried a few things to fix the version issue on my current commit, but ended up having to revert to an earlier checkin with git. And that troubleshooting process took me a couple of hours where I would have actually worked through the material.

I believe that troubleshooting problems is an important skill to have. Mistakes in tech books encourage the reader to learn how to troubleshoot. But they also encourage frustration. I wish that there were a good, simple solution to ironing out errors from tech books, even those errors that are introduced by changing technology. From my understanding, Pragmatic Programmers has much better errata reporting system then Manning Books. Reducing the errors by using print-on-demand and continuous development helps a lot, but it will never be a silver bullet.

Those hours you take to troubleshoot something that should work, but doesn’t, are the missing chapter in most tech books. Try to look at them as value-added content. And publishers, please try to keep the missing chapters in the second half of your books.

New Habits

This week I am going to set the goal of establishing two new habits, first I will post to the blog on Monday and Friday of every week. The Monday post will be about whatever my goals for the week are. The Friday post will be a review of how well I achieved my goals. The second goal is to read at least five chapters of my current development book, Rails 3 In Action.

Today I made it through the first chapter of Rails in Action, which was an overview of using rails with the scaffolding generator. Nothing too surprising, and near the end of the chapter my eyes started glazing over. Tomorrow’s chapter is about Unit::Test, RSpec, and Cucumber, Test Driven Development, all that. The writing is pretty good, Technical books have to strike a difficult balance in that their information to page count ratio must be high, but their tone shouldn’t be too dry, and if Rails in Action were a sandwich, it would have just the right amount of mustard.

Other things going on this week include packing and Christmas. My partner has sorted through all of her clothes and is giving away three quarters of them. Our rolling duffels will arrive in the mail tomorrow. We’re eleven days from flying out, and the limitations of international travel make me examine what I really need. Not a lot, it turns out.

Ira Glass On Creative Work


I’ve been busy prepping to leave town is the lie I tell myself to excuse being unproductive in the last month. Our cultural obsession with productivity makes many into tools, but there are days I wouldn’t mind getting a few things off of my metaphorical to do list.

Reality is: I get stuck in dumb loops. I check twitter. I play civ5. I marathon DS9 on Netflix way past midnight. I check twitter, reddit, reader, facebook, and twitter. I look for dopamine fixes, and avoid sitting still without my wifi on for distraction. Why? as Tony Schwartz puts it in his excellent talk The Myths of the Overworked Creative

“Let’s imagine you are looking at your computer and you are working on a very difficult problem and you know anything that you can do to get away from that problem will be extremely attractive, because human beings have two core impulses in life: number one, escape pain; number two, move towards pleasure. That’s where we live. So now, along comes the ping of that email, and that email is saying freedom, I’m free at last. And you go to that email because it takes you away from the pain of doing something more difficult and more complex, and it promises you a potential pleasure. It rarely delivers.”

Read on →

How Do I Keep Secrets While Sharing Code?

This week I’ve been working on a pretty simple Sinatra-based website which uses the twitter gem. I’m almost ready to post what I’ve got so far on github and heroku and see if anyone likes what I’ve made so far. But before I commit my code publicly, I want to ensure that my secrets are properly obfuscated. Below is a codeblock used to load secrets and keys into the application:

Correspondingly, below is the YAML which has the secrets, with my secrets stripped out:

This is a fine way to obfuscate my secrets, but only if I never include the secret in my repository, which I can do easily enough with .gitignore. But, I only want to exclude this from my viewable source, not from my deployed application, otherwise my app won’t run. Github’s help indicates that “Local per-repo rules can be added to the .git/info/exclude file in your repo,” but doesn’t indicate how this info needs to be formatted. The guides to .gitignore I have found have all directed me to a broken man page for more information, I think I need the help of a professional.

So the question is: how do I make committing this YAML file conditional? So I never accidentally upload it to github, but it always shows up on Heroku?

On Optimism

What traits make us better able to learn new skills? I think there’s a handful of qualities we can foster to make skill acquisition easier, but optimism may be the most important one.

Recently I began reading Learned Optimism, which claims that pessimists are significantly likelier to stay depressed than optimists are. I heard about the book after stumbling on a talk by @raganwald on optimism.

The book is good. I’m about halfway through it, and have taken tests which determine wether you are an optimist or a pessimist, and wether you are depressed or not, I can tell you that I am a pessimist, but I am not depressed.

I am especially glad to hear the second half of that. I have had depressions come and go since my teens, and this year has had it’s ups and downs. If I didn’t do a good job of maintaining myself, I could find myself in a depressive funk which can feel like it will go on forever.

The pessimist part of the quizzes is accurate, too. I am inclined to look at what can go wrong, and prepare well for when it eventually does. I am anxious. I tend to overthink my problems when I have them. Right now I am worrying if I am taking the right tact in this blog post.

When we’re learning something new, it is good to have an optimistic frame of mind. Because, eventually, there will be a setback. My partner is less tech-inclined then I am, and when she runs into a problem that she cannot solve on the computer, she throws her hands up and says “I’m no good at tech.” It pains me to see her pessimistic approach to technology.

When bad things happen, like if our programming environment is near impossible to setup, an optimist explains it as being impersonal, specific, and temporary. “It isn’t my fault Foo++ 0.9 isn’t easy to install, but the next version should be easier.” When good things happen, like creating an app in a new environment, the optimist takes it as personal, general, and permanent. “I’m really smart, which is what made putting together my Foo++-based webserver so quick and easy. I’m going to try building a bigger app next.”

Optimism is the attitude we need to foster to better encourage persistent improvement, especially when (inevitably) things don’t go as planned.

Rails for Zombies Is Fun

Note: Code School provides me a referral fee if folks sign up through some links in this post. Even without this fee, I would recommend their service.

I don’t like webinars on the face of it, though perhaps I am judging a book by its cover. My experience with them is that a webinar will be a series of videos where someone captures their screen and drones narration while they perform some sort of boring task in whatever technology they are trying to demonstrate. Which, for me at least, isn’t a great way to learn something.

Recently, I tried Rails for Zombies recently and I enjoyed it. At first glance, Rails for Zombies appears to be a webinar, but it is really a well produced course. The course is led by Gregg Pollack, and all of the slides used are available as a PDF. After each video there is a level—a short quiz with a series of challenges which tests your knowledge of the material. I know I am making progress with these small, well-defined challenges. The mix of questions is pretty good, with some being pretty easy to grok, while others require a few minutes of reviewing the material.

This course is thrown together for free by Code School, which has several courses on Ruby, JQuery, HTML5 and CSS3, as well as the Rails course. Once you’ve completed the Rails for Zombies course they give you a five dollar credit to “enroll” in the school, at a cost of 25$ per month. Which is a bargain if you consider the courses individually are priced at 55$ apiece.1

I had such a good time using the free version of Rails for Zombies that I have signed up for Code School and I am working on the second attack Rails for Zombies 2. These courses are a fun and engaging way to learn (or review) the basics of creating webapps in a Rails environment, and I’m going to see how much I can get done in the next month, then likely freeze my subscription. I like Code School a lot, but they’re currently only putting out a course a month, and I’m currently trying to keep my bills at a minimum.

  1. I recognize this cost comparison is actually good marketing. Anyone who considers the monthly charge or the single-time fee will sign on for the subscription, and subscription services left uncanceled are more profitable than the purchase of products from time to time.

EZ Bake French Toast

Today I made some yummy French Toast, and it was way easier then I had expected. My recipe is as follows:

Preheat oven to 400 with a cast iron skillet inside. Whip the following with a fork:

  • a splash of honey whiskey
  • an egg
  • a pinch of salt
  • a large pinch of sugar

Dunk two slices of white bread in the mixture, taking care to get as much bread as possible to suck up the egg. Let set for ten or more minutes.

Place bread in the preheated skillet, and reduce the heat in the oven to 350. Cook ten minutes, flip, and then cook an additional ten minutes.

Serve with jam or Nutella. If you need syrup, avoid anything doctored with high fructose corn syrup like yersinia pestis.

Music Management With the Swiss Army Chainsaw

Last night I was cleaning out my music collection… I know, not the most interesting Saturday night, but over the last decade my collection has gotten a little hairy.

It’s also grown to the size that pruning it by hand with Finder is nearly impossible.

Initially, I just wanted to find some files which had been accidentally duplicated. There were folders with a bunch of songs titled file.mp3 and file 1.mp3. My first stab at this had me listing files and then filtering them by piping them to grep, and yielded commands that looked like this ls -Rd | grep -i ’ 1.mp3’.

Read on →