Morning Hacker

Thoughts on the current startup ecosystem

It seems like the biggest obstacle to startups right now is convincing potential co-founders to overcome “Idea Ego.”  I define Idea Ego as “the affinity a founder has toward their own idea, and the perceived (often exaggerated) opportunity cost of not pursuing that idea.”  

There’s no question that we’re in a frothy startup market.  Literally, everyone and their mother has a startup these days.  (No joke, my mom just launched a company.)  But good luck convincing anyone to join your startup — all the “qualified” people are chasing their own dreams!   

The pervasive notion of Idea Ego is leading to what I call the “Era of Startup Diminishing Returns,” where each new startup causes a net negative effect on the overall ecosystem.  This appears to be especially true with respect to recruiting and funding.  

The winners in the current startup ecosystem are the people who can band together and build something.  In sum, the whole is greater than the sum of its parts.  Instead of building a prototype, go build a team.    

TL;DR — Get over your “Idea Ego.”  You’re harming the ecosystem.  Incubators and VCs pick teams, not ideas.  

Social Inept

corneliusdurden:

Pandora Return since IPO: -39.21% 

Groupon Return since IPO: -34.01% 

Linkedin Return since IPO: -29.44% 

Zillow Return since IPO -13.03 

the mole is growing!

Too clever by half!

I migrated a new field into an existing table that contains a default value.  But when I deploy to Heroku, that default value isn’t propagated to the existing 5000+ records.  So I wrote a Delayed::Job that would set the attribute to the default value.  

Easier said than done.  Things were going swimmingly at first, but then Heroku coughed this out:

Process running mem=834M(162.9%)

Error R14 (Memory quota exceeded)

I figured the problem was looping through thousands of records, which were loaded into RAM.  Naturally, I began re-writing my loop so that it would process the records in batches, to wit:  

  users.each do |user|
    contacts = user.contacts
    puts "USER = #{user.email} " + " | " + "There are #{contacts.count} that need fixing."
    acct_email = user.email        
    batch_flag = true
    batch_size = contacts.count/10
    upper_batch_range = contacts.count/batch_size
    x = 0
    y = upper_batch_range
    range = x..y

    while batch_flag
      contacts[range].each do |batch_contact|
batch_contact.update_attribute(:weight, 5) if contact.weight.nil?
      end
     
      if # ... this is where I stopped and just Googled it.
        batch_flag = false
      end
    end

    end # contacts.each
  end # users.each 

But just when things were getting a bit hairy (e.g., 20-30 minutes of head scratching), I thought “this is Rails, there’s gotta be a better way.”  And sure enough, Active Record has a “find_in_batches” method built in.  Try this answer on Stack Overflow and this API Dock page on the find_in_batches method.

Moral of the story:  if you’re getting too clever with your code, you’re probably not using the Rails API properly.  Just Google your task and see what you can find. 

Rspec tests — yeah, i’m finally doing them

I finally got passing Green Rspec tests. I admit: I was a Test-Hater, but i’m starting to love TDD!  

Frankly, it was a pain in the ass to write a test suite for the API that I’m using.  But immediately after I got it working, it was clear that my code was wrong!  Amen for TDD. I fixed the hidden problem (validates_uniqueness_of :emailMessageId, :scope => [:to_email] was missing contact_id as a scope).  

Back to coding…