(void* dan)

Don't mark my app's email as SPAM

Judging by the number of email outsourcing companies, there is clearly a large problem to be solved.  I’ve had sporadic issues with email being marked as SPAM with HomeField, and then regular issues on my latest project, FoundersCard.  I’ve finally got them fairly well sorted, as far as I can tell…

  1. The DNS records on your name sever must be setup correctly (and verified)
    1. The A record of the domain you’re actually sending mail from (i.e. teamhomefield.com) must point to the IP of the actual server sending the email (in this case 8.12.42.205)
    2. You should also configure the SPF record which is being used increasingly by recipient mail servers to further determine if the sending servers IP address is authorized to send email for the given domain.  My DNS has a TXT record with the value “v=spf1 a mx ptr ~all”.  
  2. rDNS (reverse DNS) must be setup
    • On the server sending the mail, the PTR record must correctly specify the hostname pointing to this sever (teamhomefield.com)
  3. Your Rails setup…
    • You can set from to be any username at the domain configured above, but I’ve found that GMail will mark SPAM unless the following format is used
      • from  ”anything@teamhomefield.com (Anything Else)”
      • Not sure why “Anything Else <anything@teahomefield.com>” doesn’t work..
    • The reply-to is great for sending on behalf of a user
      • reply_to “Dan Spinosa <spinosa@gmail.com>”
    • I am using the following ActionMailer configuration
      • config.action_mailer.sendmail_settings = {
          :location       => '/usr/sbin/sendmail',
          :arguments      => '-i -t'
        }
  4. Your emails content…
    • If you’re sending HTML email, be sure to send it as a multipart email including a text part that closely matches the HTML (which, BTW, should include <html> and <body> tags)
      • In Rails, if your mailer action is named “notify_email”, Rails will automatically create a multipart email for you if you have multiple views: notify_email.text.html.erb and notify_email.text.plain.erb
    • It’s free to check your spam score & deliverability at contactology
  5. Your mail servers IP…
    • Make sure it is not listed by Spamhaus, and remove it if it is.  It is common to see your IP in their PBL, which can easily be remedied.

HTH, and hope I don’t have to deal with this again.


Web Based S3 File Manager

I didn’t want a desktop app just to browse my files on S3 and double check that my code was actually doing what it seemed to be doing. I have no regular need to access these files and don’t want another throw-away app cluttering up my MBP.  So I did a little searching, and found this sweet freebie…

An awesome web based file manager for S3: http://www.s3fm.com/

You got something better?


Rails DB Backup to S3

If you don’t believe backing up your data is important, come back when (not if) you lose some important information.  Sensible (Rails) developers, read on…

I’ve seen (and used) decent backup solutions involving mysqldump, sftp and an additional server.  They’re okay, but with a few plugins/gems your DB backup can be elegant (and Amazon secure).  I happen to like db2s3.  Configure the gem like the README says.  Then add a couple of whenever tasks:

every 1.hour { rake “db2s3:backup:full” }
every 1.day { rake “db2s3:backup:clean” }

Holy shit done.  But you will have to pay the S3 bill.  So pick up a penny from the ground every day.  You’ll be $.25 ahead of the game at the end of the month.

Gotchas?  Of course.  db2s3 relies on aws-s3, so you must have that gem installed (this is not explained in the README).  NBD, but if you happen to be using right_aws with paperclip, like me, you may run into issues due to the gem load order.  So, keep your house in order:

config.gem “aws-s3”, :lib => “aws/s3”, :version => ‘>= 0.6.2’
config.gem “right_aws”

Thoughts?


Whatever we are, it’s we who move the world and it’s we who pull it through.

– Ayn Rand via Atlas Shrugged

Confusion Over Configuration

Many Ruby on Rails decisions are guided by the motto “convention over configuration.”  This makes Rails opinionated software and allows one to get up and running quickly and easily, so long as you follow the crowd.  I love this.  It makes you confident you can try something new, get it up and running fairly easily, then start adding functionality, breaking and tweaking iteratively.  They so to err is human.  It’s also Rails…

I’m a very organized person; it helps me get things done.  So when I recently started building some Rails billing functionality, I decided I would namespace it.  Shouldn’t be too bad…

script/generate model billing/Account ...

This created the model Billing::Account in the file models/billing/account.rb.  Nice.  Turned out to be less-than-nice when I tried to start working with it.  I’ll spare you the details of how much I hated my life that day and get straight to the caveats:

  1. The migration generated created a table called “billing_accounts” which seemed correct (and great!) to me.  But ActiveRecord doesn’t care about your namespace, so you have to manually add “table_name :billing_account” to the Billing::Account model.
  2. For testing, a new directory was created: test/fixtures/billing, but it was empty.  The file billing_account.yml was added to the base fixtures directory.  Don’t do what I did and move that file into the billing/ directory: those fixtures don’t get loaded.  So leave it, or move it and update Rails’ load path to look through fixtures/ recursively.
  3. Foxy fixtures do not work with namespaced models.  Not at all.  If there’s a way to get them to play nice, I couldn’t figure it out before deciding to hand out a couple of id’s manually.  Fuck it, that’s why.

It puzzles me that Rails’ generator seems to handle namespaced models so gracefully, but actually creates these incompatible time-sucking gremlins.  Did I do something completely wrong here?


It’s a known risk… But the odds against it are pretty good, especially when compared to the rewards of being an astronaut, so they’re willing to take the chance. In fact, they FIGHT for it… as would a lot of us. But getting the public to buy this is a lot tougher, especially a public that expects every risk in their lives to be mitigatable to zero. It will be interesting to see if NASA tries to take on this challenge, explaining to the public that doing bold things isn’t about engineering risk to zero. Shit happens, and if we just want to restrict ourselves to things where shit can’t happen… we’re not going to do anything very interesting.

Dan Canin, a Lockheed test pilot on the Columbia space shuttle accident (via reecepacheco)

I have a significant conscious desire for risk.  Maybe it has to do with the (usually) greater reward I can see, my environment growing up, or what I’ve read and learned along the way.  I’m sure that’s part of it, but I have a feeling it’s more innate.  For me: the adrenaline / dopamine rush; behavior that evolved over millions of years to keep man alive, further his accomplishments and give meaning to his life.

p.s. I’m excited to be getting a copy of Atlas Shrugged back from Reece so I can start reading it again.

Via reecepacheco

Why do they always teach us that it’s easy and evil to do what we want and that we need discipline to restrain ourselves? It’s the hardest thing in the world – to do what we want. And it takes the greatest kind of courage. I mean, what we really want.

– Ayn Rand

The question isn’t who is going to let me, it’s who is going to stop me.

– Ayn Rand

Perfection is achieved, not when there is nothing left to add, but when there is nothing left to take way

– Antoine de Saint-Exuper

On Over Engineering

During our meeting with Fred Wilson last week he mentioned something fairly obvious about our company: we have too few engineers  (i.e. just me).  He was making the point that one particular path for our company could see it thrive (netting a few million a year in profits) with a small 10-12 person staff (7 engineers or so).  But it started me thinking about it from the other angle: what if we had too many engineers?

I firmly believe one of the reasons startups create some of the most beautiful and expertly crafted products is that they have limited resources with which to produce them.  Startups therefore, by necessity, build only to create value and build the smallest solution possible.  This viewpoint is bolstered by 37signals’ Getting Real, Paul Graham in many of his excellent essays, and the principle of least effort (or path of least resistance, if you will).  It’s why Rob Pacheco says, “to find the most efficient way to accomplish a task, give it to the laziest guy in the kitchen.”

Conversely, when a startup grows (or starts) too big, it produces decreasingly beautiful products.  Engineers, by definition, like to engineer.  An average engineer - which most of them are, by definition of the word average - will not achieve perfection.  Since these engineers have to do something with their time, the company they work for ends up with an over-engineered product (by definition!).  It is the rare exception (i.e. Apple) that can produce many beautiful products by the labor of many engineers.

-A Lazy Engineer


13
To Tumblr, Love Metalab