Facebook User IDs are BigInts in PostgreSQL

We’ve recently been working on integrating 5 Blocks Out with Facebook, starting with making it easy to sign up via Facebook Connect. I stumbled across a bug related to this today that might impact other developers doing the same thing, so I figured it would be worth sharing.

When someone signs up on 5 Blocks Out using their Facebook account, we take their Facebook user ID (fb_uid) and save it in a database table so we can remember them later. We use PostgreSQL as our database.

Now, Facebook user IDs are integer values, and it turns out they can be pretty big. Bigger, in fact, than the default “integer” type which Rails migrations use when creating an integral-valued column in a PostgreSQL table. So if you follow the defaults, you will eventually crash when a user with a large fb_uid tries to sign up.

My code was doing something like this…

user = User.find_by_fb_uid(current_facebook_user.id)

… and with current_facebook_user.id too large, you get this unhappy result:

ERROR: value \"1000001234556789\" is out of range for type 
integer\n: SELECT * FROM \"users\" WHERE
(\"users\".\"fb_uid\" = E'1000001234556789') LIMIT 1

The solution is to use type :bigint when creating your database column. Or, as in our case, change your existing integer column from integer to bigint:

class RecoverFromDumbAssedProductionError < ActiveRecord::Migration  
  def self.up    
    change_column(:users, :fb_uid, :bigint)  
  end
end

Happy Facebooking.

New from Apple: iMagicExpandingBattery

Katrin had some odd problems with her Macbook last week. The mouse button on the trackpad stopped working and the machine began locking up intermittently. I dug around for an hour or so trying to figure it out and finally gave up, figuring it was a hardware problem with the mouse.

1 trip to the Apple Store and $130 later, we had a solution: it was indeed a hardware problem, but with the battery, not the mouse. The “Genius” at the Apple Store (they really should rename that tech support role) explained that batteries in Macbooks can sometimes expand, phsyically swelling up to the point where they push against the edge of the battery container, damaging laptop internals and even cracking the case.

Don’t believe me? Check out these images of bloated and cracked Macbooks. Swollen-battery-itis.

The fix, provided your laptop isn’t irreparably damaged by this problem, is to simply buy a new battery. Although some people report online that they convinced Apple to replace the battery for free, most say Apple won’t cover the problem. Sorry for you.

The kicker: the Genius also explained:

  1. You shouldn’t leave your laptop plugged in for more than one hour after it reaches full charge. Instead, unplug and let it run down to near zero. (One assumes you should also plan your day carefully so that you are near electricity at the right times.)
  2. The expanding battery is “by design”, i.e. the battery is designed to expand so that you know it has reached the end of its life. Uhhh… no, I don’t think so. Can you imagine the battery in a car expanding to the point where it cracks the battery casing and damages the engine? In the auto industry that’s cause for a product recall.

It’s a design flaw, plain and simple. Just admit it.

I like my Macbook a lot, but problems like this and the recent iPhone antenna debacle make me wish Apple would admit failures openly and handle them with grace. I’m reminded of one of Microsoft’s more odious traits back when it was riding high: a notable arrogance and disdain towards customers. It wasn’t Microsoft products that had problems, it was “stupid customers using it wrong”.

Apple, you need us more than we need you.

The identity ‘iPhone Developer: Foo’ doesn’t match any valid certificate/private key pair in the default keychain

Great title, eh? Surprise: this is another entry in stupid stupid stupid, and like the previous one, this too is brought to you by Apple.

The problem and symptoms: you’re trying to rebuild an iPhone app that another developer worked on in the past. <– important.

Let’s say the other developer’s name is “Bert Fiddlesticks”. When you build your app in Xcode you get a build failure with a message like this:

The identity ‘iPhone Developer: Bert Fiddlesticks’ doesn’t match any valid certificate/private key pair in the default keychain.

Workarounds:

First check this great page of workarounds on fixing iPhone code signing errors. It’s way better than Apple’s developer support pages on this same topic.
You’re back? Sorry that didn’t work out for you. Great page though, eh? Hopefully you tried changing the code signing entries in your project settings to get rid of Bert’s name. Me too. No joy.

Here’s what I ended up doing:

  1. Find the project folder on disk.
  2. Open the .pbxproj file with a text editor.
  3. Search for Bert’s name. If you find it, e.g. in the code signing info section, delete everything between the quotes.
  4. Save and close the .pbxproj file.
  5. Restart xcode.
  6. Go to project settings and change the code signing entries to your own name. Do this even if you already did it earlier.
  7. Build clean and rejoice, for all should now be well.
In my case the pbxproj file had a line like this:
  "CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "iPhone Developer: Bert Fiddlesticks (ABC1232)";

I changed it to look like this:

  "CODE_SIGN_IDENTITY[sdk=iphoneos*]" = "";
Child’s play.
Elapsed time for you: 10 minutes. Elapsed time for me: 3 hours.
Follow

Get every new post delivered to your Inbox.

Join 348 other followers