Notes from Howard Lindzon’s DemoCamp Toronto 29 Talk

Howard Lindzon spoke last night at DemoCamp 29 (on twitter; democamp site). It was a fun ramblin’ jamblin’ talk. Here are a few takeaways that stood out for me:

Treat the world as flat, and find a defensible niche to start in. E.g. think of the world as the Risk game board, and pick an initial territory where your chances of getting established are high. If you start in Europe, you have lots of borders and the battle is much harder than, say, starting in Australia. (Or Kamchatka. Remember Kamchatka? I think I learned more geography in Risk than in school.)

Follow your own rules. In response to an audience question about mistakes he has made in his career, Howard explained that many of them stemmed from breaking his own rules when investing, e.g. (1) investing in the market when all signs still clearly pointed to down, (2) investing in companies whose CEOs did not have deep domain experience. (Howard likes such companies best, as a rule, for his investments.)

Have a sense of humor, especially about yourself. Howard’s self-deprecating humor made him a real pleasure to listen to, and he explained that his habit of poking fun at himself is part of why people like to follow him in social media. “I make fun of my own mistakes first, before anyone else has a chance to.”  He talked openly about passing on a few investments that would have been incredibly profitable, e.g. a chance to invest $25K in Twitter when it was valued at only $20M.

Spot and leverage the big waves. He spoke to only one slide during the 30-or-so minutes, and it showed two graphs depicting the meteoric rise in Twitter and Facebook usage. His main point was that when you can get in front of a huge market-changing trend (like social media) you are maximizing your business opportunities to do well. “You don’t need to catch every wave. Just one amazingly great wave in your lifetime is all you really need”. Also, fighting a paradigm-changing trend is futile. So, in this specific example, which Howard calls “the social leverage trend”, figure out which of Facebook and Twitter it makes best sense to align your business with first, then integrate and try to ride the wave.

Use your dashboards. He talked about dashboards and his view that they’re essential to business success. From memory, “What’s your dashboard? It’s never too early to start building your dashboard. … Figure out the one or two pages you need to look at every day to understand both the macro market picture and the micro [i.e. the key signals/metrics from your own business]. For me it’s http://techmeme.com, http://angellist.com, and market all time highs.” These dashboards give him “the very early market signals [from AngelList] and the loudest public market signals [from all-time highs]“.

Thanks Howard for a fun and frank talk.

ActionController::RoutingError (undefined method ‘sub’ for nil:NilClass)

Or, “Man I’m glad Ruby on Rails is an open source framework”.

Ruby on Rails normally provides pretty good debugging information for dealing with errors, but I ran into an odd error today that had no debug info other than the exception itself. Here’s what I did to find and fix the problem.

Symptoms: “So, tell me, how long have you been feeling this way?” I had just added a new controller, model, views, and helpers to my app. Requesting a route to any of the new controller’s actions caused Rails to die with the exception “ActionController::RoutingError (undefined method `sub’ for nil:NilClass)”. No stack trace. No filename / line numbers. I knew one of the 20-odd new files I had just created must be causing the problem, but I didn’t know which one.

Diagnosis: “Breathe in. Breathe again. Again. OK, now cough. Ah, yes, now I see the problem.”: The only way I know of to diagnose these kind of problems is brute force. I added a debugger statement to the top of application_controller.rb and restarted the app. Then I requested a URL that was causing crashes, and from the breakpoint, stepped forward in the debugger (next, next, next…) until the app died. Studying the code that executed just before the app died didn’t yield an obvious result, but about 10 frames up the stack I could see a call to ActiveSupport::Inflector#constantize. I edited that method to print (puts) the parameters it was being called with, then restarted the server and tried again. Voila: the last parameter spit out by #constantize before the server died was the culprit.

#constantize PlaceLinksHelper for name PlaceLinksHelper

The Cure: “Take three of these and call me in the morning.” : It turns out I had created a helper module with the file name “places_helper.rb”, but within that file I mistakenly defined “module PlaceLinksHelper”. For some reason that shall remain a mystery to me, this caused things to fall-down-go-boom. The fix was simply to give the module the name Rails expected to find: “PlacesHelper”.

Upon Reflection… “I sure hope that doesn’t happen to me again. But it probably will.” I don’t know how you do this sort of diagnosis efficiently in a closed-source or compiled environment.  This is about the 5th time I’ve edited Rails source code to find and fix an oddball problem. I guess you could try attaching a debugger to binaries and then study the gobbledy-gook, but… no thanks. The only other thing I  could have done in a compiled/closed source setup is study each of my own files line by line. That would have worked, but it would have taken far more time.

Source code good.