Inverting 5V to GND for a relay

I’m working on a project right now where I want a 5v output from a Raspberry Pi to switch a rely controlling 120V AC. The relay I’m using is this one:

http://amzn.to/2ztmEKH

The problem is that it switches the relay when the line goes LOW (ie. ground). I’m using a HAT on my Pi that always sets a certain pin HIGH when activated. So I needed a way to turn 5V into GND.

I found a blog post with a schematic:

I breadboarded everything and it looked great. I didn’t want a breadboard in my final project though, so I wired everything up into a simple cable:

Here’s what’s going on there:

Add some heatshrink and it looks like:

So, the single wire coming out going to the relay activation pin (technically it sends GND so the wire could be black) and the other two go to the Pi’s GPIO pin and GND. Nice and clean!

Rails 5.1 new default BIGINT primary key sort of ruins existing apps (with fix!)

TL;DR

Run bin/rails db:schema:dump in development to get a new schema.rb file built that explictly defines :integer as the data type for all id columns.

What’s going on

I just upgraded our app to Rails 5.1 but ran into a problem when trying to build and run the test suite on our CI:

ActiveRecord::MismatchedForeignKey: Column `role_id` on table
`authorizations` has a type of `int(11)`. This does not match
column `id` on `roles`, which has type `bigint(20)`. To resolve
this issue, change the type of the `role_id` column on
`authorizations` to be :integer. (For example `t.integer role_id`).

After some research I found that this message was added specifically for 5.1 when you try to have a new BIGINT column be a member of a foreign key that’s still of type INT.

The problem is that the schema file didn’t define what data type your id columns should be because there was no need to: everything was always INT and that’s all it would ever be. Going forward, however, the default is BIGINT so when Rails 5.1 sees the datatype-less schema file it happily makes all the id columns BIGINT, but all your foreign keys are defined in the schema with t.integer so they’re plain INTs still. Ugh.

I figured maybe there was new syntax for the schema file that would explictly tell Rails that the id column should be an INT and not use the default of BIGINT. I ran a bin/rails db:schema:dump and sure enough for every table there’s a new parameter:

create_table "authorizations", id: :integer, force: :cascade, options: "ENGINE=InnoDB DEFAULT CHARSET=utf8" do |t|

Notice that id: :integer is new.

If you want to take advantage of BIGINT then you would need to migrate all existing id and foreign *_id columns to be BIGINTs. But, this means dropping foreign keys altogether, upgrade column types, then re-adding your foreign keys (or maybe tell your database to ignore foreign key relationships while you migrate all these datatypes, but I haven’t tried that technique). You’ll need to take your site offline to do this. That wasn’t worth the hassle for us, and we’re nowhere near id 4,294,967,295 so we should be good for a while.

If future me is reading this after getting our 4 billionth user: it seemed like a reasonable tradeoff at the time!

Temporarily disable password validation in AuthLogic at runtime

I needed to create a bunch of users, some by setting a password and some by skipping password validation because they already have a crypted_password and password_salt (AuthLogic’s default password storage fields). I Googled all over the place for a solution to hack AuthLogic, then hack Rails validators, but finally found one from looking at the source.

You can monkey patch AuthLogic’s require_password? method to return false and the password authentication check will be skipped. So in the part of my script right before importing users that already had a crypted password I added the following:

class User
  def require_password?
    false
  end
end

The validator itself is still present on User, but luckily AuthLogic adds an :if => require_password? check to it. Manipulating that check lets you skip validation altogether.

Code—migrate a bunch of objects from Rackspace to S3

Ever have to migrate from Rackspace Files to S3? I did. And I couldn’t find a simple way to do it. So I made one. There’s a service (mover.io) but it gave up after 25,000 objects. I had to copy 175,000.

Great Migration is a Ruby script I wrote to handle this situation. It logs into Rackspace, gets a list of all objects from a container (paged in groups of 10,000 by default), and copy those objects to an S3 bucket as quickly as possible (for Ruby anyway). I copied my 175,000 files in just about an hour and a half (for a total cost of $1.32 using a beefy c4.4xlarge EC2 instance).

Check out the repo for a technical description of how it works or just clone/fork and get copying!

The easy way to bulk edit tons of S3 objects to be public readable

If you do a Google search for “s3 bulk permissions change” you’ll see most of the results involve writing a script to loop through all of your objects, buying the Bucket Explorer app, or vague references to “bucket policies”. This last one is the key.

A common use case for S3 is to contain images uploaded by users on a website. Usually you’ll want theses images viewable by the world so they can see what’s been uploaded. If the code doing the upload gives public read access, great! But if it doesn’t, or you’re migrating a ton of images from one service to another and the read permission is lost, this technique is for you.

In the AWS S3 console click on your bucket on the left. Next click the “Properties” button at the upper right. Open the “Permissions” section here:

Click “Add bucket policy” at the bottom:

Paste in this snippet of JSON:

{
  "Version": "2012-10-17",
  "Statement": [
    {
      "Sid": "AddPerm",
      "Effect": "Allow",
      "Principal": "*",
      "Action": "s3:GetObject",
      "Resource": "arn:aws:s3:::my.bucket.com/*"
    }
  ]
}

Make sure to change the name of your bucket on that last line, but keep the “/*” part. This will give read-only access to everyone for all objects in your bucket. If there are only certain directories of your bucket that should be public you can change that path from “/*” to your desired path. If you need more than one path then you’ll need multiple “Statement” values, one for each.

Just click “Save” and you should be good to go!

My Preferred Ruby on Rails EC2 Server Setup

I still haven’t fallen for the Chef/Puppet/Ansible hype—I setup EC2 servers manually and then image the server. Creating a new instance of that image is how I reproduce the setup. I haven’t yet worked in an environment that’s had complex enough requirements/changes that I’ve needed to complete automate the server setup using one of the above tools. I’ve just kept things simple.

After years of tracking and building on this setup in Evernote I finally consolidated everything into a bash script and put it into a gist:

https://gist.github.com/cannikin/7d0834bc3814865a47df

The script assumes you’re running an Ubuntu image (ami-5189a661 is great). It installs nginx and configures it to send requests to a Unicorn socket. It also includes ImageMagick since it seems like every app ends up needing it at some point. It installs Ruby via ruby-install and uses chruby to pick which version to use (setup in /etc/profile.d so it’s available in both login and non-login shells). Everything should magically work if you deploy using Capistrano.

Follow the instructions at the top of the gist and you, too, shall have the Ultimate Ruby on Rails EC2 Server Config™!

On the virtues of contracting

I’ve been a professional software/web developer for fifteen years now, and up until nine months ago I only ever worked as a traditional full-time employee. I’ve worked for big companies (1,500 employees) and small ones (two, including me). Nine months ago I got a call from a recruiter about a contract position. Outside of a little freelance work here and there I’d never considered doing contracting full-time, but thought I’d give it a shot.

I’m glad I did because it turns out that I love it. Several reasons:

• The pay has been great (75% more than I was making at my highest paid full-time position, and I was being paid very well there).
  
• No commute. I can’t stress this one enough. My last on-site position had a 45-minute commute each way. I have two kids and now that’s an extra hour and a half I get to see them each day.
• Less stress. It seems like no matter where you work you end up getting involved in, even if just watching from the sidelines, office politics. As a programmer I just want to put my headphones on and get some work done, and working from home makes this 10x easier.

My current contract is almost up so I’m starting to look for my next gig. I’ve got a couple options for full-time again, but the sweet nectar of contracting is just too good. I could go back to my recruiter, but when listening to a podcast this weekend I heard about Toptal.

The first thing that stood out is their screening process—you have to pass their own phone and coding interviews before you make it to the site. Any other job service I’ve seen simply lets everyone in the door who wants in so I imagine it’s pretty overwhelming for employers and very difficult to find the good ones. At Toptal they claim that only 3% of applicants make it through the process. I never love interviewing (does anyone?) but I’m excited for the opportunities that Toptal could open up for me so I’m going to brush up and get ready for that phone call.

They also provide some tips for those looking for Ruby on Rails engineers. I’ve had several previous employers ask me for help with interviewing and now I’ve got a great resource to send them to.

Wish me luck!

THIS A THOUSAND TIMES: No more JS frameworks →

Sunset tonight #nofilter

At the aquarium (at SEA LIFE Aquarium)

After a tough soccer practice (at ESCONDIDO SPORTS CENTER)

Something about this warms my heart every time I see it… (at Apple Store)

Gotta show the love! #arduino

No man ever finished his work, for each task is but a preparation, which, being completed, should be put under our feet, that we may thenceforward labor on a higher level. Thus, no true worker was ever satisfied with what he accomplished, for, by doing that, he had qualified himself to do something better.

— George Houghton

at Connors Park San Marcos Ca