Skip to content
Sep 8 14

New Republic article on Amicus

by Topper

This New Republic article ( ) is the truth of what happened at Amicus and makes for a response, in a way, to Seth Bannon’s previous post: ( ).

As Amicus was unraveling, I had a chance to spend more time talking to the investors than ever before. One point that kept coming up in our discussions was: “stuff like this happens more than you think, just no one talks about it.” It’s my, perhaps wishful, hope that if real stories are heard then there will be moments of pause in the current frenzy that is our exciting tech world.

Invariably, I find all of the Amicus investors to be wonderful people and strong business leaders. YC was a life changing experience that I would recommend for nearly all young companies. Advice from YC has been very personally helpful and changed Amicus’ direction more than once for the better.

The bigger problems at Amicus came from one bad actor and a currently accepted system of large party-round seed investment that gives no one any oversight.

It would probably be good to keep discussion of this post on Hacker News ( )

Feb 27 12

Henry Miller on Writing (h/t Kottke)

by Topper

Except for #11 these are perfect for programmers too. Especially:

6. Cement a little every day, rather than add new fertilizers.

Jan 24 12

New gig

by Topper

Hey all,

As an “oh yeah… meant to tell you.” – I’ve been CTO of Amicus since the beginning of the year. It’s awesome. We’re helping caused-based organizations kick ass.


Jan 24 12

My Coding Styles

by Topper

I’ve already written about my path-to-pretty coding style. However, I have not written more specifically about how I approach each language in my rails stack. I do realize some of what I’ll say below is not best-practice. This is my pragmatic approach to how I code, YMMV. I have tended to work at medium scale (1-3mm user) sites handling medium traffic (2-300 req/sec) with a small number of employees (6-50). At an order of magnitude larger of any of those statistics I realize you have to tighten up.


  • 2 space tabs (no tabs)
  • wrap 3rd party APIs whenever you’re using them a lot
  • use modules to namespace gems with many classes
  • try my best to rely on 3rd party code, contribute back when broke
  • edge cases aren’t edge cases at scale – they happen. Think about them.
  • anything intended for the greater world must be specced to perfection, anything used internally must at the very least have enough specs that I cannot typo anything.
  • Interaction with 3rd party APIs are hard to spec which is why it’s better to wrap in your own classes. Initial testing can hit the live API, and then you can move off of doing that.


  • always REST, write controllers as if they were an API
  • controllers shouldn’t do much
  • models can get kind of thick. Break out into modules when *too* thick, but play that loose.
  • classes wrapping models (especially for your REST api) are encouraged and dropped right in the models folder. Model != Db table.
  • Rails 3.1+ asset management is a gift. Use it. Pass config from backend to front end using erb.
  • Your models should be very well specced. Your controllers really only need a surface layer. Acceptance tests are awesome to have when you get there.


  • CoffeeScript is better
  • jQuery is a gift. Use it.
  • namespace everything – global functions do not belong
  • any custom code you use belongs in your own namespace at Motionbox we used MBX.blah
  • I tend to believe that changing prototypes is OK, but I recognize the why of “don’t” and so don’t do it myself. I don’t avoid libraries just because they change prototypes.
  • Use an MVC framework (even for little things).
  • Spec out the MVC models. I rely on the acceptance tests for the V and C code (mostly). Any tests that rely on HTML can be brittle.


  • namespace all your CSS under one global class (you’ll thank me later)
  • never use style words in your classes or IDs. HTML is supposed to be what a document IS not what a document looks like. If something is a submit button it’s a “submit-button” not a “blue-submit-button.”
  • Use the minimum amount of HTML to have your app look right. Play with it, don’t just git ‘er done.
  • HTML should at least look like it’s functional (forms should point at the right place and be submittable). However, I’m not a zealot when it comes to progressive javascript enhancement. My target audience probably has Javascript enabled. Yours may not… think about your audience.
Nov 18 11

IE, iframe, P3P, Cookies, oh my

by Topper

I was just banging my head against the wall trying to figure out why internet explorer wasn’t remembering my user’s sessions. Turns out it’s something that has bitten me in the past.

IE doesn’t allow you to set cookies when your site is in an iframe unless your site has set P3P headers. Also, ordering matters – the P3P header must be set *before* the cookie is set.

If you’re using ruby, this gem works pretty well:

Further reading:

All the articles I read about setting headers, etags, etc were all really old. Hopefully, if you’re using rails you found this article. Just install the gem and add the line from the README to your application.rb – no monkey patching. Good luck.

Oct 26 11

Periods in your rails requests and the “format”

by Topper

I sometimes hit a bug where a username has a period in it… so if you have a path such as:


Rails will parse that first period as the beginning of the format param… so you lose the files route, etc.

It does let you use %2E though which will be unescaped to the period in your params… so


will give you the correct user_id param of “my.username” and continue on its routed merry way.

Just a simple reminder. Probably more for me than you 🙂

Oct 6 11

A moment of silence

by Topper

I would be remiss if I didn’t mark this day (well, yesterday). RIP Steve Jobs. I’ve been trying to think of any person or company that has changed my world more than Apple. Their products encouraged me on my path to my current career. Their personal computer interfaces have permeated the entire market. The idea that a computer should be simple and available has shaped the planet. Their phone put the internet in my pocket, changing my world again.

His 2005 Stanford commencement speech [VIDEO] was powerful at the time, but now carries even more weight. “Stay Young. Stay Foolish.” At 56, I guess he will always remain young, but he was certainly not foolish.

Steve Jobs set an example that almost none of us will attain, but in striving we hope to make the world just a little bit better.

Aug 25 11

Here, Here… how to save WebOS

by Topper

I find it tricky to write about a company I work for (HP). So I’ll just link to this:

Exactly. I’ll go one step further and say “be the cloud OS that no one else is.” Embrace the web. It could save you. I’d like to do a longer discussion on this, but I have to watch my words (probably, no one has told me this).

Aug 22 11

The process of software creation

by Topper

Wow. This woman describes succinctly what I’ve been trying to describe for a few years now. At the ol’ Motionbox (pre Snapfish acquisition) this is exactly what we were doing. We went from the horrible waterfall, to a version of Agile (not formal) and settled on something remarkably like what Mary writes.

It worked fantastically. It keeps everybody invested and focused on the end result rather than the details. It also keeps your team working together and doesn’t allow for excuses like “that wasn’t on the list.”

It, however, does require everyone on your team to be a good-to-great communicator and to be very good at their jobs (weak links stick out like sore thumbs). However, if that’s not what you’re striving for anyway… you’re probably doing it wrong.

Hardcore agile guys… what’s your take?

Nov 5 10

Resque. Two things to think about.

by Topper

We started using the redis-backed Resque for background jobs. So far it’s been pretty great to work with. The syntax is clear and the whole thing just works. There are very good articles describing how to actually code Resque. Here’s one. I won’t bother with yet-another-walk-through.

However, I do want to talk about one gotcha and one thing you should think about.

The Gotcha: Possible Message Failure

Messages in Resque are not necessarily going to run. There is an, admittedly edge, case where a worker can pop a message off of a queue and then die. The message never gets put in a fail queue and it never actually runs. The message is gone. I have a fork that fixes this (makes it so messages can’t be lost unless Redis loses ’em) However, that’s awaiting a merge.

Until my branch (or some other fix) gets merged, make sure you think about what’s going to happen if your job doesn’t run. For many apps this can be “ok” (since it won’t happen very often). Just make sure it’s OK for yours.

One Thing You Should Think About: Tracking Message State

Since you can’t reach into a Resque queue and say “talk to me about this job,” tracking message state is up to your application. We happen to do this in our database.

We put a “job” record into the database with body, result, state columns. The body is there so we can always re-create a message from the database if something goes wrong. The result keeps track of what happened and the state lets us track it along its merry way.

If you have to make absolutely sure that your messages get processed, you’ll have to think about how you’re using Resque.