push.cx
Peter Bhat Harkins
Create localhost Aliases for Different Projects
As a consultant I’m getting set up to develop on a new Rails project every few weeks or months. And I’ll jump back to an earlier project to answer questions, fix bugs, fix typos, etc. Eventually, something overlaps between them. I got bit by this again, so I wanted to write it up.
As is always the case, a bug came up on a project I’d finished a few weeks before. I did a git pull to make sure I was up-to-date, started it up again and... it blew up. I couldn’t load any pages at all, and it failed deep in ApplicationController of all places.
It didn’t take too long to run down the problem: the old project and my current project happened to set a cookie with the first name. The current project had discarded the cookie it didn’t recognize, but the old project wasn’t as robust and failed when it saw the cookie it considered invalid.
The problem is that everything is on the domain name localhost and the browser considers that to be one site. I had one really frustrating debugging session when the browser used its cache for a different version of jQuery from a different site I’d been working on earlier that day. I’ve also seen security software that refuses to run on localhost, sites with “service-oriented architecture” that need multiple web servers running, and I’m sure there’s more reasons I’m not thinking of.
So let’s use a different domain name for each project. It’s as easy as editing the /etc/hosts file. I like to make entries like this:
` 127.0.0.1 foo-dev.com # 2015-03-27 foo project for foo llc 127.0.0.1 blah-dev.org # 2015-02-01 blah project for blah `{lang=”hosts”}
I don’t use fake domain top-level domains like “local.dev” because some security software (including FIDO U2F don’t permit unknown top-level domains. (And, worse, .dev is now Google’s private turf.)
I also don’t use subdomains like “local.foo.com” for two reasons. First, nothing stops the site itself from using that subdomain, so visiting the production site will now try to pull in assets or iframes from your local development copy. Second, cookies can behave in surprising ways when set or accessed on a subdomain vs. hostname.
In writing this up I’m reminded how many of the tiny development habits I have are about preventing some weird corner case that have cost me hours and hours of time, so I have to close with a famous quote:
...and of course you must be careful not to overwrite the bounds of memory blocks, free a memory block twice, forget to free a memory block, use a memory block after it’s been freed, use memory that you haven’t explicitly allocated, etc. We C++ programmers have developed tricks to help us deal with this sort of thing, in much the same way that people who suffer severe childhood trauma develop psychological mechanisms to insulate themselves from those experiences.
Joseph A. Knapka