Category Archives: Uncategorized

Dina Bitmap Font for OSX

I used FontForge to create a version of the Dina programming font optimized for OSX.

[ Download ]

Usage note: you must set the font size to 16 for this font to display correctly.  See below.

Other versions of the Dina font I was able to find on the internet all got screwed up on OSX so I made this one.  It seems to work great in, MacVim, and XCode.

To use this file, unzip it and put DinaMedium.dfont into ~/Library/Fonts/ and follow the instructions for your editor: configuration: I am using emacs24 compiled with these instructions.   I added these lines to ~/.emacs:

(setq mac-allow-anti-aliasing nil)
(set-frame-font "-apple-Dina-medium-normal-normal--16--*-*-m-0-iso10646-1")

MacVim configuration:  Using the latest macvim, I added this line to ~/.vimrc:

set noantialias
set guifont=Dina-medium:h16

Any other app configuration:  Select Dina-medium from the standard OSX font picker and set size to 16.

Dina is my favorite font for programming.  All letters and symbols are clearly disambiguated, like zero and a capital ‘O’, or braces, brackets, and parenthesis (essential for clojure programming).  The size is just right for my eyes and a 30″ display.  And I love the overall aesthetic.  Hope you enjoy!

Users of my iOS Game Teach Me a Lesson MIT Didn’t

In the game of Monorail, it is a more valuable to be skilled at fixing broken solutions than skilled at deducing correct solutions.

I made the iOS puzzle game Monorail.  Before publishing the game, I thought I had figured out the best way to solve the puzzles. Users surprised me with a better strategy, and this experience has changed the way I write computer programs and think about the business of startups.

The object of Monorail puzzles is to complete a closed-circuit loop through all the stations (dots) by drawing rails.  The loop must pass through each station exactly once and close back on itself, like an actual monorail system might in a city.

My Strategy:  Careful-Logical-Deduction

My strategy for solving these puzzles was to reason carefully about every rail before putting it down.  The game was specifically designed to be amenable to this strategy: each puzzle has only one possible solution-path given the starting conditions, which makes it possible to deduce each rail placement until you have solved a puzzle.

For example, you can observe that in a solution path, each station connects to exactly two neighboring stations.  (One rail in, one rail out).  Thus, since a corner station has only two neighbors, you know that it must connect to those two.

I developed layers upon layers of elaborate methods to deduce what rails must be placed on the board.  I solved puzzles by using logical reasoning, placing rails one-by-one until I have completed the path.

Better Strategy: Iterate-and-Repair

When I shipped the game, I used Flurry to track a bunch of statistics about puzzle-completion time because I was worried the puzzles would be too difficult.  After looking at the stats, however, I found that many users were whipping through puzzles I thought I had designed to be super difficult. How? They found a superior strategy.

I found some of the best monorail solvers and observed them.  They would:

  • Start by guessing random paths and just drawing whatever comes to mind.
  • Fix mistakes.
  • Repeat.
  • If things ever look hopelessly messed up, then press the CLEAR button and start over.

I call this the Iterate-and-Repair strategy.

It turns out to be easier and faster to iterate from an existing but wrong solution, than to deduce a correct solution from scratch.  Even if you have to occassionally press the “clear” button to start over.

This realization inspired me to be more headstrong when writing computer programs.  I now put more emphasis on iteration and refactoring from a reasonable starting point, rather than trying to figure out the best possible design ahead of time.  If the code gets totally screwed up, I press the metaphorical clear button and use what I’ve learned to devise a new and better starting point.

I even used Iterate-and-Repair to write this blog post!  “Good writing is rewriting.”

If this whole post is obvious to you, then congratulations, you are already an Iterate-and-Repair kind of problem-solver.  To me, this was kind of a revelation.  I started out as more of a Careful-Logical-Deduction kind of guy.  I think this was influenced by my undergraduate education in mathematics at MIT, where so much emphasis is placed on logical reasoning and certitude.  Indeed, I’ve observed that many of my MIT friends who play monorail tend toward Careful-Logical-Deduction.

Now I’m more of an Iterate-and-Repair kind of guy, and I think I’m a better puzzle-solver, better programmer, and a better startup founder for being so.

Lifting weights will give you a heart attack and ruin your sex drive

This article about Jack LaLanne describes him as The Founder of Modern Fitness.  The most interesting part of the article is that in 1936 he opened a gym with weights and the medical profession was against him:

“People thought I was a charlatan and a nut,” he remembered. “The doctors were against me — they said that working out with weights would give people heart attacks and they would lose their sex drive.”

I wonder what things doctors are against today, but which we will later take for granted.  Maybe some of the ideas in this awesome book.

Psychological Evaluation of Aaron Iba