Tim Morton

The Periodic Table Puzzle

Sat, 10 Mar 2012 16:07:38 -0500

In a recent job interview, I got the following puzzle/algorithm question:

You have the standard periodic table of the elements, and a list of words (ie the OSX spell-check dictionary). How can we find the longest word that appears in the table? For example, “NO” starting at #7.

After a bit of thought, I started sketching out an algorithm based on iterating through the table. At each cell, we start trying to build words that start at that cell. For example, at #1 we consider “H”, then “HLi”, etc. For each candidate word, we consult the dictionary: is this a word? (if so, we can consider it for the “longest word” prize). Then we ask a related question: is this a prefix for a word? That is, does any word start with this character sequence? If not, then we can abandon this direction, and return to the current starting cell. After considering each direction from that cell, we can move on to the next one.

It turns out, the interviewer was thinking of a different algorithm. First, sort the dictionary by word length. Starting at the longest word, search through the table for an occurrence of that word. Stop when we’ve found a word.

What followed in the interview was a lot of hand-waving about algorithmic complexity and sketched pseudocode. Running through the table for every single word in the dictionary (until a match is found) seemed very slow to me. With my algorithm, I can consider each candidate word in O(log n) on the size of the dictionary, by binary searching on a sorted dictionary. With his, we’re considering each candidate word against one dictionary word at a time, but doing this for each word in the dictionary. That algorithm will end up something like O(n) on the size of the dictionary. I’m sure there are optimizations possible to both approaches, but sitting in a conference room with a whiteboard and some notebook paper, I was pretty sure that my approach was correct.

Math is hard, let’s go coding

A few weeks later, I was still curious about the question: was my approach really faster? To answer the question, I whipped up a prototype implementation in ruby.

Short answer: I was right. Solving the puzzle with his algorithm took ~26 seconds on my machine. My algorithm runs 1000 times in just 5.6 seconds. Neither version is well-optimized, but I think I’ve fairly represented the guts of the slower algorithm.

Be Ruthless (but not yet)

Sat, 25 Feb 2012 16:51:00 -0500

Earlier this week, this excellent piece by Chris Parker made the rounds on Hacker News.

Here’s the thing: you are not ruthless enough. You are certainly not ruthless enough to your objects, and you probably need to be more ruthless to yourself.

This is true. Be ruthless. But not yet. Let’s see how Chris continues:

Being ruthless to yourself means every time you say “oh, I’ll just open up this internal bit over here…” use that moment to give yourself whatever negative feedback you need to go back and write the correct interface.

When you have an internal bit “over here”, and you have a good idea about what you’re trying to accomplish, then you should be absolutely ruthless. But when you’re first building something new, even if it’s just a new set of classes for a small feature, you should be a mild-mannered, dope-smoking, peace-loving hippy. Toss things out there. Share private internals with wild abandon. Build the messy, cobbled-together version, just to prove that it can work. Then clean it up.

Remember the old aphorism:

Make it work
Make it right
Make it fast

Many people skip the second step, and they will encounter the evils that Chris explains. But other people get stuck on the first step, seeking the correct or elegant solution before they have any sense of the real problem space.

This rhythm reoccurs at all scales of the software development process. In minute-to-minute development, we can write a test, get it to pass, then refactor a little. With a small feature or bugfix, often “just do it” is the way to start - but before committing the code, review with a critical eye. At the week-to-week level, you need to mind your application architecture, but you also need to deliver real functionality and make sure that real users are happy with the software.

So be ruthless with code, not with ideas or concepts or half-formed architecture diagrams floating in your head. Produce code with joy, with courage, and (occasionally) with wild abandon - before you ruthlessly shape it into something great.

Weird things you cannot do

Fri, 10 Feb 2012 11:52:00 -0500

Don’t name a capistrano namespace “rake”. This breaks the db:migrate task, or any other built-in task that tries to run a rake command. You’ll get a message like this:

executing "cd (your deployment directory) && #<Capistrano::Configuration::Namespaces::Namespace:0x107e01908> RAILS_ENV=production  db:migrate"

This error occurs with Capistrano 2.9, but does not occur with 2.5 - I’m not going to bother tracking down the exact version that introduced this issue.

The origin of 20% time

Sun, 16 Oct 2011 09:28:35 -0400

Six days shall thou hack, and deliver all thy features;

but the seventh day is a sabbath unto Quality of thy Code; in it thou shall not deliver any business value, nor thy tester, nor thy project manager, thy senior developer nor thy junior developer, nor any consultant or contractor that is within thy company.

New gem: Mixable Engines

Sun, 04 Sep 2011 12:47:17 -0400

Just published a new gem for my day job: Mixable Engines.

In the beginning, there was the engines plugin. This was back before Rails 2.3, when men were men and there was no “engines” functionality built into rails. The plugin would mix together the controller classes from your engines and your application.

In those days, my colleagues and I at the ASEE wrote lots of engines, and lots of apps that used those engines, and all of it depending on this mixed-together architecture. Now as we upgrade our apps to Rails 3, this gem allows us to keep the existing code and engines working without rewriting everything.

RIP, faithful phone

Mon, 04 Jul 2011 16:22:18 -0400

I am the least gadget-whoring programmer that I know. As proof, I submit this fact: my recently-deceased phone was an original, 2g iPhone. It had become annoyingly slow recently, but I was not planning on forking over the cash to replace it. But now, sadly, it has decided that the “touch screen” does not care about touch, and will just be a screen.

It has served me well, since the 2007 price drop a few months after launch.

Now, bring on the shiny!

Code and Money - a gap in the medium term

Thu, 23 Dec 2010 14:44:00 -0500

In software development, we’ve got tools for planning the short run. Unit tests tell me what code to implement right now. Daily task lists tell me what to work on today. GTD helps to manage my week.

In planning my personal finances, I’ve got a good handle on my day to day expenses. The Mint iPhone app keeps my balances up to date. I’ve got money going into my checking account, out to various savings accounts, and paying my bills. I know, to a good approximation, whether I can really afford an expensive latte in the morning.

Similarly, in both areas, my long term planning is about as good as it can be. Mockups and broad product descriptions give the software project a mission. Retirement calculators and rules-of-thumb tell me whether I’ll be ok in the future. All of these visions are fuzzy, because there’s unpredictable events in the future, but the tools are there to give us the best possible answers that can we can get.

The trouble comes in the medium term. Your customer wants a new feature for their conference in three months: can you deliver? What other features need to be rearranged? You need to replace your car in a year. How much should you save? Does that interfere with your vacation plans? The medium term is where the art of planning gets dicey. It’s close enough that real decisions and commitments are needed, but far enough that intuitive notions of “easy”, “hard”, “expensive” and “minor” are not sufficient. In the medium term, there are multiple projects, each with different deadlines, requirements, and priorities.

Right now I have six medium-term financial goals, all with different deadlines. Some are flexible, both in date and amount - I could put off my vacations, or do something less expensive. Some are not - the property taxes must be paid by the deadline, come hell or high water. I don’t have a good way to visualize how they all fit together - in fact, I’m thinking of writing a tool. Given a fixed number of dollars per paycheck, will that allow me to pay everything? Or, given fixed amounts and deadlines, how much do I need to pay per paycheck?

Right now I have several projects in the works, some with deadlines, some without. If the deadlines can’t be met, then customers need to know as soon as possible, but none of them are overwhelming on their own. The question is, can they all fit together into my schedule, in a way that satisfies everyone?

$30/hr Java Coders are not Photography

Wed, 09 Jun 2010 11:37:00 -0400

In the beginning, there were painters. They were artists and chroniclers of reality.

At the RailsConf keynote, Neil Ford claimed that photography changed painting, by freeing painters from the burden of representing reality. He then went on to claim that “enterprise java” development will do the same for programming - freeing us from the drudgery of faithfully copying business processes.

This is sort of correct - we are (slowly) being freed from the boring and repetitive parts of our craft, but not because we’re outsourcing those pieces to India and Romania. Just like painters, we’re outsourcing those pieces to machines. Libraries, compilers, and frameworks free us from “accurately” representing the computers with which we’re working. More importantly, we’re making progress from the other direction, taking the simplest business problems and automating them too. Spreadsheets freed up programmers from developing simple math applications. Google Docs Forms and similar things mean that basic form-crud will soon be a thing of the past. These problems will be solved by the combination of machines and non-experts, just like the “capture this scene” problem is solved by a non-painter and his camera.

TDD Survey Results

Sun, 14 Jun 2009 00:00:00 -0400

I gave a lightning talk at RubyNation called “TDD in the real world”, mostly as an excuse to poll the audience about testing practices.

The most interesting question for me was - how many people follow the standard “red, green, refactor” cycle in their day to day development? I asked - who follows this pattern more than half the time? 70% of the time? 100% of the time? Results:

50% - about half the audience.
70% - ~40% of the audience (I’m in this category)
100% - 5 and a half people, including Yehuda Katz

A lot of people are not doing strict TDD. This is the RubyNation conference, which had TATFT last year. This is the Ruby community, which has a ton of experimentation and a million test frameworks. Frankly, I’m kind of baffled. Are these people doing a lot of research-style code spikes? Are they writing tests after the code, but still getting decent test coverage? Or is testing just “exercise and vegetables” - things that people should be doing, but don’t?

More research is needed.

Engines and routes - a simple solution

Mon, 25 May 2009 00:00:00 -0400

So the new Engines feature in Rails 2.3 is great, but there’s one big problem with the way it handles routes. The routes in all of your engines are loaded before your application routes. This is a big problem if your engines have a catch-all default route for a CMS-type thing.

The Thoughtbot guys have one solution which involves alias_method_chain and the ActionController internals. Fortunately, there’s a much simpler way.

In your engine, rename routes.rb to my_routes.rb.
At the end of your application routes.rb file, add this line:
```
ActionController::Routing::Routes.add_configuration_file(
```
```
  "#{RAILS_ROOT}/vendor/plugins/cms/config/my_routes.rb")
```
(“cms” is the engine name, replace it with your own)
That line goes outside the block that covers the rest of the routes.rb file.