Clojurescript Chat Example

I love programming in clojure.  I used clojure to write the server-side of Spacetime, and it worked like a charm.

I’ve been playing around with clojurescript.  There isn’t much example code out there yet, so here’s a very basic realtime chat app that I cobbled together.  It uses clojure for the server, clojurescript for the client, and websockets.

Spacetime Released!

I released Spacetime, an iOS app that I have been working on in my spare time.

It lets you request someone’s location by sending them a regular text message.  This message has a link in it for them to click on. They don’t even need an iPhone.  After they click the link, Spacetime shows you their location on a map.  Kind of a neat hack, I think.

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.

My Favorite iPad Apps

A lot of friends are getting iPads and asking me what my favorite apps are. I use my iPad for 3 main things:

  • Web Browsing
  • Reading
  • Games

Here are my favorite apps for each of these uses.

Atomic Web Browser – This browser has a tone of features that utilize the additional iPad screen size better than the built-in browser.

Kindle – By far my most-used app.  I was worried that the iPad screen would be less comfortable than the eInk on my Kindle DX, but to my pleasant surprise, I can read for many hours on the iPad without a problem.  Given that Kindle on the iPad is so much faster than the DX, I don’t have any reason to use my DX anymore.  I love reading Kindle books on my iPad.

GoodReader – Great for reading PDFs.  And it syncs with DropBox.  Just drop a PDF file into your DropBox and then open it with GoodReader on your iPad.  Best way to transfer/read PDFs.

WordBook XL – I think this is the best English dictionary app for the iPad.  It’s based on WordNet and the UI is good.  I tried a bunch of other dictionary apps before this one, and liked this one the best.

Construction – The best game I’ve played on the iPad.  The objective is to build structures out of a limited set of materials.  Challenging and fun.

SuperJuicyHD – A fun puzzle/action game that involves popping bubbles.

Mirror’s Edge – A fun side-scrolling action game from EA that uses touch-screen gestures in a creative way.

Rush Hour – A great sliding-block puzzle game.

Psychological Evaluation of Aaron Iba


Get every new post delivered to your Inbox.