Best way to install postgis for Postgres versions lower than 9.6.x? from source.

I recently had an absolute bear of a time trying to install the postgis extension for Postgresql 9.6.3 which I’m running because there is an error on upgrade from 9.6 to 10 around the hstore extension which seems impossible to get over unless I blow away all the data related to hstore or try this very tricky migration that basically massages hstore data.

First I tried to simply install postgis with homebrew. Silly me.
That upgraded my 9.6.3 installation to Postgress 11 and installed the extension. It took me 2 hours to pick through the debris, (dyld errors, had to ln -s the new readline library to the old one that postgres expecting after I ran
brew switch postgres 9.6.3

After that, I was able to install postgis with brew via two commands

brew pin postgres
brew install postgis --ignore-dependencies

That looked like it worked, but everytime I then tried to install the extension I’d get and error around this phrase (I lost the stacktrace in my glee of finding a fix)

Symbol not found: _AllocSetContextCreateExtended

I turns out what I had to do was uninstall postgis from brew

brew remove postgis

then go to the official postgis source page, pick a stable version (I had issues with 2.4.7. compile error on Mac OS) but 2.5.3 worked just fine.

I downloaded the tar file, uncompressed it then ran
make install

And VOILA! I was able to create the postgis extension for the db I was working on. phew!

recovering from git reset –hard

You’ve been there … you’ve done some work, then staged or committed it in git and forgotten about it for a bit. Only to hop into the terminal another day thinking you’re on master and wondering why your git pull is doing a merge.

Having neither the time, or patience since you’re running low on coffee and you want to look at that Pull request locally, you’ve run

git reset --hard origin/master

only to instantly remember you’ve blown away all that good work.

The good news is, you can recover from git reset error in very specific instances as described here

I accidentally ran git reset --hard on my repo today too while having uncommitted changes too today. To get it back, I ran git fsck --lost-found, which wrote all unreferenced blobs to <path to repo>/.git/lost-found/. Since the files were uncommitted, I found them in the other directory within the <path to repo>/.git/lost-found/. From there, I can see the uncommitted files, copy out the blobs, and rename them.

Note: This only works if you added the files you want to save to the index (using git add .). If the files weren’t in the index, they are lost.

In the case (like mine) where you committed the changes previously, you will find hashes in .git/lost-found/commit that refer to the commits that you lost. You can view what is in them by running

`git show 98b9e853c9c8ffc07b450c61b05313cc4aa9eceb` (for example)

Usually it will just show the diff of the commit which you can re-apply manually line by line, other times you’ll see something like this

commit 98b9e853c9c8ffc07b450c61b05313cc4aa9eceb
Merge: c5060f1 89e959d
Author: xxxxxx <>
Date: Thu Jul 13 17:42:09 2017 -0500

Merge branch ‘master’ of xx/update-readme

on the line that says “Merge”. You can run a git show on one or both those hashes as they point to the parent commits of the one you’re looking at.
You can keep doing that till you get the commit you were looking for. whew!

puma-dev on OSX follow up (tips and tricks)

I’ve been doing a lot more Rails dev recently, and as I wrote about previously, I’ve really been enjoying using puma-dev to do that. I just wanted to add a couple of things to that initial post that may not be initially apparent.

Getting puma to stay idle longer

Out the box, puma-dev will spin down an app after 15 minutes of inactivity. This was a bit short for my tastes so I went asking around for how to extend this. Turns out you can run a simple command …

puma-dev -install -timeout 180m

On OSX this actually updates the plist file that launches puma-dev directly. which brings me to the next point …

Restarting puma-dev manually

On OSX. The puma-dev plist file used by launchd to run puma-dev on startup, seems to be located at /Users/<your username>/Library/LaunchAgents/

The reason why this is important is that in the puma-dev readme, it says to restart puma-dev by running.

pkill -USR1 puma-dev

However. Lets say, you’ve misconfigured your plist file (like I managed to do), launchd will keep trying to run puma-dev and failing all the while spitting out an error that looks like this in your puma log files every ten seconds

Error listening: accept tcp accept: invalid argument

The dead giveaway is entries like this in your system log files located at /private/var/log/system.log[1616]): Service exited with abnormal code: 1
Service only ran for 0 seconds. Pushing respawn out by 10 seconds

To stop this just run this command

launchctl unload /Users/<your username>/Library/LaunchAgents/

This will let you fix up your plist file. Then you can restart it with this command

launchctl load /Users/<your username>/Library/LaunchAgents/

You can also use this as a way of starting and restarting puma-dev.

Running on a different port

If you have Apache running on port 80 and don’t pass in the right command when installing then puma-dev will fail to launch, and keep failing as described above.

This means you have to run `puma-dev install` with the http-port flag, for example

puma-dev -install -http-port 81

I like this, not for the reason you’d think, but because it allows me access my apps on https://<appname>.dev, while still accessing my php apps with apache on port 80!

Something to note though is that you have to run this command everytime you run `puma-dev install`, or else it will overwrite your settings in your plist file and cause you hours of grief as you try to figure out how you broke all the things amidsts rending of hair and gnashing of teeth

To illustrate … say you have your port set to 81 and you run the command we discussed first

puma-dev -install -timeout 180m

This will reset your port to 80 quietly, and puma-dev will start failing as I described previously. so to avoid that you want to run

puma-dev -install -timeout 180m -http-port 81


This behavior is subtle enough to cause problems for someone who may have installed puma-dev a while ago and forgotten where everything is and how it all works, so I filed a bug report about it.

Hope this helps someone avoid a stressful afternoon or two!

Rails dev with puma-dev

A few months ago the creator of my favorite rails server (puma) announced a version of puma called puma-dev. This new server bears more than a passing resemblance to pow, because of its goal of making local rails development stupendously easy.

I was a big fan of pow when it first came out but I eventually stopped using it when it as development on it slowly crawled to a halt then eventually stopped. Having come to Rails development from a PHP background, where the server was always available,

  • I didn’t like having to type `puma` or `rails s` to start working on a local application, or …
  • having to remember and assign different port numbers if I was working on more than one app at a time. So I was definitely excited about having puma-dev pick up where pow left off.
  • it also made playing around with subdomains easier

So I was definitely looking forward to having it pick up from where I left off with pow

Setup is super easy. First make sure to include puma in your Gemfile

gem 'puma'

Then run `puma` at the command line and make sure your app starts up with no problems.
Next install puma-dev

brew install puma/puma/puma-dev
sudo puma-dev -setup
puma-dev -install

To setup (for example), you’d just run

puma-dev link yourdomain /path/to/your/app

And voila!

I’ve been using this setup for a few months now, and I must say, I find this immensely useful because I have an apache server running on port 80 for my PHP work, so I can actually access a domain on It also supports websockets!

Things to note

  • puma-dev will spin down the server after a few minutes of inactivity, so don’t be surprised if your app takes a few seconds to startup after you’ve been gone for a while
  • To restart the server (in case you’re working on something that doesn’t auto load or isn’t loading correctly)  just run `touch tmp/restart.txt` from rails root

json (1.8.3) and rubyracer gems aren’t compatible with ruby 2.4.0

PS: This is moot anyway because it looks like Rails 4.2 doesn’t fully support Ruby 2.4.0 yet

Ran into this problem trying to upgrade a Rails app to use the new version of Ruby.

make "DESTDIR="
compiling generator.c
generator.c:861:25: error: use of undeclared identifier 'rb_cFixnum'
} else if (klass == rb_cFixnum) {
generator.c:863:25: error: use of undeclared identifier 'rb_cBignum'
} else if (klass == rb_cBignum) {
generator.c:975:5: warning: division by zero is undefined [-Wdivision-by-zero]
rb_scan_args(argc, argv, "01", &amp;opts);


Turns out this is because of Bignum/Fixnum integration that rolled out in ruby 2.4.0

after that I hit another fugly stack trace caused because I hadn’t upgraded therubyracer gem to 0.12.3

I had to include the gems and specific versions in my gemfile

gem 'json', '~> 1.8.6'
gem 'therubyracer', '~> 0.12.3'

then run

bundle update json

Unfortunately, as I mentioned above, I was unable to run Rails 4.2.7 anyway, because it looks like it hasn’t been fully prepped to incorporate Ruby 2.4.0’s integer changes.

Suddenly failing `rvm install`command on os x 10.11 (El Capitan)

This actually started with a strange error, when I went to fire up a rails server in an app I’d been working on the night before.

Unable to load application: LoadError: dlopen(/Users/xxx/.rvm/rubies/ruby-2.3.0/lib/ruby/2.3.0/x86_64-darwin14/readline.bundle, 9): Library not loaded: /usr/local/opt/readline/lib/libreadline.6.dylib

Like I mentioned, I’d fired up this app less than 24 hours prior, so this was very strange to me. Some quick googling around suggested that I try to reinstall my ruby version so I ran the command

rvm reinstall 2.3.0

Well that errored out with another strange error

ruby-2.3.0 - #configuring...........................................................
ruby-2.3.0 - #post-configuration.
ruby-2.3.0 - #compiling...........
Error running '__rvm_make -j 1',
showing last 15 lines of /Users/xxx/.rvm/log/1476345601_ruby-2.3.0/make.log
compiling enc/trans/newline.c
compiling ./missing/explicit_bzero.c
compiling ./missing/setproctitle.c
compiling dmyenc.c
linking miniruby
dyld: lazy symbol binding failed: Symbol not found: _clock_gettime
  Referenced from: /Users/xxx/.rvm/src/ruby-2.3.0/./miniruby (which was built for Mac OS X 10.12)
  Expected in: /usr/lib/libSystem.B.dylib
dyld: Symbol not found: _clock_gettime
  Referenced from: /Users/xxx/.rvm/src/ruby-2.3.0/./miniruby (which was built for Mac OS X 10.12)
  Expected in: /usr/lib/libSystem.B.dylib
make: *** [.rbconfig.time] Trace/BPT trap: 5
++ return 2
There has been an error while running make. Halting the installation.

You might notice the “(which was built for Mac OS X 10.12)
which is a bit of a hint at what the problem is.

Because the last line hints the problem is with make, I decided to reinstall make with brew and it dumped the solution to the problem in my lap

brew install make
Warning: You have Xcode 8 installed without the CLT;
this causes certain builds to fail on OS X El Capitan (10.11).
Please install the CLT via:
sudo xcode-select --install

Basically I’d upgraded my Xcode version without installing command line tools. Once I ran this command, my rvm reinstall went fine and my readline problems went away.

Managing Talent that doesn’t fit between the lines

One of the most interesting management insights I’ve read in a while.

I have a staff member who produces brilliant work but is consistently late every single day. I can’t fire him because it will take months…

Dushka Zapata’s answer: I once hired a woman who did brilliant work but was not a good team player. It’s not that she was destructive or hostile. It was more that, in an industry that typically thrives on collaboration, she was an independent contributor. Another employee was always late. I fel…

the key insight being

People who deliver brilliant work are hard to come by.
It’s our job as managers to make our business environment flexible enough to give  every brilliant employee a place to thrive.

I absolutely loved this!

All too often, I find that managers (especially middle managers) are concerned with bringing employees “in line” and getting them to conform to the system, instead of figuring out how to help them do their best work. I imagine following the approach outlined in the article is much easier said than done though.

PS: I bet it would make a very interesting interview question for a management position.

what subdomains taught me about questioning my assumptions

A couple of years ago I worked at a “startup”.  I put startup in quotes because it was really a big company pretending to be a small one. Ideas generally flowed from the top down; engineers wound up on the crap end of everything, usually getting overruled and dictated to by PMs and the UX team. Naturally, a lot of the engineers were disillusioned and frustrated with the way things were working.

It was in the middle of this rather cynical time that we got a new PM on the team. He was tasked with improving our onboarding flow and upping conversion numbers, and I was the engineer assigned to work with him on this project.

He had a lot of ideas about how to go about accomplishing this task, and surprisingly, he had actually dug around in the database and pulled some numbers that backed up the direction he was going in (before he came along, very little of what we did was based on data … another source of frustration).

However, on the list of things he wanted to try was something that raised my eyebrow.

“Hey … Pete” (not his real name by the way)
“Am I reading this right? You want us to leave off the subdomain field on signup?”
“So how will we assign subdomains to the client to access and login to their app?”
“We can just randomly generate a unique string and use that, I think”

To provide some context, this was 2013, and the subdomain-login-access pattern where a customer was actually a group of people who needed separate logins to access a particular space within an app, had become a mainstay of web apps all over the techie world. The pattern, popularized by 37 Signals and Basecamp almost 8 years earlier, was simply one of those things that everyone just did.

Being the brilliant undiscovered product genius I thought I was at the time, I knew taking away subdomains from the signup form, would be an unqualified disaster. Users would freak out when they signed up and were redirected to to login. They would panic when they couldn’t remember what url to go to login, they would bombard us with emails, and the complaints would force us to roll back this silly change.

I smirked to myself and got to work on getting this and other changes pushed out on the appointed date. After getting everything built out and QA’ed in staging, we rolled out the change and waited …

I’ll spare you the suspense … nobody complained about the subdomains

I was completely blown away. I simply could not understand it … I mean, subdomains were so crucial to the users, how could they not miss that on the sign up?!?!?

Turns out that subdomains are actually confusing for a lot of users, and us taking that off their plate simplified the sign up process. Users mostly didn’t care what the url looked like, and the ones that did, could request a specific one in the settings. (A few years later, 37 Signals would remove subdomains in the newest versions of their apps, citing the exact rationale that we discovered back then)

I learned 2 things that day
– Humble pie is actually pretty delicious, people should eat it more
– You know nothing Jon Snow. (Seriously. You don’t)

Lots of us walk around spouting truisms without any data to support what we’re talking about, and nobody challenges us, so we keep doing the things we’re doing. In reality, if we poke a couple of these “assumptions” we might find that a lot of them come tumbling down like a Jenga tower.

So, whenever you find yourself not wanting to try something because “everyone knows thats how its done”, take a breath then go ahead and test that assumption.

If you’re correct what do you have to fear?

Loved this post on hiring from Coding Horror

We Hire the Best, Just Like Everyone Else

One of the most common pieces of advice you’ll get as a startup is this: Only hire the best. The quality of the people that work at your company will be one of the biggest factors in your success – or failure.

Perhaps worst of all, if the interview process is predicated on zero doubt, total confidence … maybe this candidate doesn’t feel right because they don’t look like you, dress like you, think like you, speak like you, or come from a similar background as you? Are you accidentally maximizing for hidden bias?

“Product management is the art of knowing what to build”

Loved this little gem of a quote hidden inside the following article

“Product management is the art of knowing what to build”

Feels like one of those “Everybody knows that” things from the Geico commercials, but from experience, fewer people than you’d imagine know this.

Why Big Companies Keep Failing: The Stack Fallacy

Stack fallacy has caused many companies to attempt to capture new markets and fail spectacularly. When you see a database company thinking apps are easy, or a VM company thinking big data is easy? – they are suffering from stack fallacy. Stack fallacy is the mistaken belief that it is trivial to build the layer above yours.

How to fail

Convincing Failure

There are two ways to fail and the consequences are orders of magnitude apart. Convincing failures allow us to make better decisions in the future. We tend to agonize over the risk of executing something poorly but the much bigger risk is building the wrong thing to begin with.

This is one of my favorite articles about Failure. Written by Andrew Bosworth, almost a year ago now (who I wish would blog more), I still reference it from time to time to remind myself of the lesson in it, which is …

“… if you execute to a level of quality that makes it unlikely that another team, even with more time and effort, could succeed, then yours is a convincing failure. This kind of failure is strategically valuable because we can now eliminate an entire development path from consideration. That means subsequent work is dramatically more likely to succeed. A convincing success is unquestionably the goal of every effort, but a convincing failure should be a close second.”

For me the lesson that lies inside of that nugget doesn’t just apply to Engineering teams, it applies to life.

Lots of times, people will try something, but they’ll do it half heartedly. They might open a business, or try to do standup comedy, or try to make a pro team (that was me), but they don’t give it their all … maybe they want to string some wins together so that they can convince their friends and family that this isn’t some flight of fancy, or maybe they’re afraid that they’ll fail, so if they don’t give it everything they’ve got, it won’t hurt as much when things don’t work out. The problem with this approach is that, just like the article says, you’re still left wondering “what if?” when the opportunity finally fades from view. Which in a lot of ways is worse than not trying at all.

I like reading this article because it reminds me that if I try something in my personal life, that I want to either succeed or I fail … hard. No in between.

The secret weapon of great teams … the quintessential team player

Wayne RooneyI’ve worked on high functioning teams, dysfunctional teams, teams of people who absolutely hated each other, teams where everyone loved each other, and I think I’ve zeroed in on one trait that anyone can look for in a team that will tell you how productive and successful they’re going to be.

Before I do this, I’m going to tell a small sports story.

I played at a pretty high level (amateur) when I was younger, and I played with this one guy (lets call him Dick) who was a brilliant player, with a nasty habit of berating players every time they made a mistake. The thing I noticed was that, sometimes players wouldn’t even make a mistake, they’d just do something that he didn’t think they should do, and he’d immediately get on them. Even worse, sometimes he’d make a mistake and blame someone else.

Miscontrolled a ball? “That was a Shit pass!” he’d yell.
Gave the ball away in a bad area of the field? “Why weren’t you covering that guy?!”

If they ignored him, he’d just keep sniping at them or refuse to pass to them in the game/practice. People didn’t really enjoy playing with this guy at all. He was very good though, so you’d just have to suck it up and try to play with the negativity, which is very tough for younger/developing players who were short on confidence sometimes.

There was another player, (lets call him Wayne), who was actually even better than this guy, but it wasn’t apparent because he did a lot of “dirty work”, unglamorous stuff. He rarely did fancy moves, or tried things that made you go “wow” or look around for an ESPN filming crew. But the guy was steady, technically brilliant, rarely made mistakes (which you start to realize is very hard to do at a high level). If you were in trouble, say surrounded by 2 guys and were about to lose the ball, you could knock the ball to his general direction and it didn’t matter how much pressure he was under or how crap the ball you played to him (look up “hospital pass”), he’d pick it up and find a way out. It was amazing.

Want to know the awesome thing about this guy? he never blamed people for anything!
It was actually kind of weird.

If you made a mistake he’d yell
“Don’t worry about it, just recover, go get it back!”,
If you played a bad pass, he’d say
“Go on … go make sure they make the mistake now … win it back!”.
If you missed the shot, even if it was from 2 yards out with an empty goal, he’d say
“Unlucky. You’ll get the next one!”

He’d constantly yell encouragements …
“Awesome pass John”
“Holy crap look at Ronaldo over here!”
“What a shot … more of that!”

He was everywhere … always looking for a way to help out. If he was better positioned, he’d tell you where to play the pass. If you were hesitant about what to do, he’d yell out
“hit it” … or “touch that off to Mike” … and if you did something different, he’d wouldn’t skip a beat
“ohhh … even better. love that pass!”
then he’d be off to get open for the next guy.

And it was infectious … because he gave you encouragement, you weren’t afraid to make mistakes, and because nobody else was really as good as this guy, you realized that you really couldn’t get on somebody about how crap they were playing, because at some point in the game you’d probably do something pretty stupid. A side effect of this is that everyone started to play for everyone else, because there was no real thing as a “mistake”, everyone just knew to cover for everyone else, even Dick.

So if your man blew by you, somebody else would step up and mark the loose guy, someone else would take his guy, etc etc, and you could just go find an open guy and mark him. Everybody covered for everyone else … it became part of the game, part of the team DNA … and it was a very good team indeed.

I bet by now you know what that trait is in teams I’ve seen that predicts how well they work together. There is no fear of failure.

If you get some bad code into production, you don’t get thrown under the bus, or get walked into a small room with fluorescent lights to get reamed by your boss, instead people swarm around and try to help you, and you do the same when someone else makes a mistake, or misses a deadline. The culture of blame is non-existent, so people fix problems, not the blame. If a deadline was missed, then the team didn’t make a good estimate NOT that Kathy is a shitty engineer.

This is very important to note, because most corporate environments, for whatever reason, seem to embrace a culture of blame. If something goes wrong, everyone wants to know who’s at fault.

“yeah Mike wrote that code 2 weeks ago, we told him not to push it live, but he did it anyway, this is what happens.” … usually followed by a self righteous sigh.

People point fingers quickly, because a culture of blame stems from a culture of fear. Fear of failure, fear of not living up to “high standards” … fear of not being an “A player”. If someone else is to blame for something, then you can still stay secure in your illusion of awesomeness, or maybe you are really fantastic and all your shitty co-workers are just bringing you down, or maybe nobody will listen to your brilliant ideas, so this is what they get.

Now does this mean that you should constantly cover for and try to baby along players who can’t hack it at the level of everyone else? Absolutely not.

On the soccer team I was on, you had to meet a certain (high) standard to make the squad … if you weren’t good enough you simply wouldn’t make the team … simple.You had to have a particular skill level to play, but once you were in, you were one of us, and we’d work our socks off for you, just like we’d work our socks off for Lionel Messi if he chose to join (look him up, he’s only the best player in the world). Its the same way on the great teams I worked with.

Teams that work well together don’t fear failure, High functioning teams that work well together, have amazingly talented and driven people working together for each other who don’t fear failure. They embrace it.

They can do this because they have great team players, men and women who constantly work for each other, push each other, encourage each other, and pick up the slack when somebody falls down or trips up, without even thinking about it. Great teams are stacked with people who say

“What can I do to help”
instead of
“I’ve done my job”

You know … quintessential team players. The real tell-tale sign of a great team.

Being that person that makes everybody else great, isn’t that hard. It’s all about being like Wayne, performing at your best, being a pro no matter what and adopting an attitude that there is no real mistake, because you’re going to cover for your teammate, and trusting that they’re going to cover for you.

It really is that simple.