Namecheap + Amazon S3

Written by Pete Corey on Sep 23, 2014.

I recently wanted to point a domain I had registered on Namecheap (www.thisurlshortenertotallyandcompletely.rocks) to a static site I was hosting on Amazon S3. The whole process was fairly painless. Check it out:

  1. Create a new S3 bucket.
  2. Upload your content to the bucket.
  3. Add a bucket policy to allow anonymous read access to all objects in the bucket:
{
    "Version": "2012-10-17",
    "Statement": [
        {
            "Sid": "AddPerm",
            "Effect": "Allow",
            "Principal": "*",
            "Action": "s3:GetObject",
            "Resource": "arn:aws:s3:::www.thisurlshortenertotallyandcompletely.rocks/*"
        }
    ]
}
  1. Enable website hosting on the bucket. Save the endpoint generated for you. You’ll need this to set up your Namecheap CNAME alias.
  2. Browse to the alias and make sure that your site is working as expected.
  3. Now on Namecheap, select the domain you want to link to your S3 bucket.
  4. Go into “All Host Records”.
  5. Add a CNAME alias to the endpoint of your bucket.
  6. Have a beer.

I hope that helps.

Git Bisect and Commit History

Written by Pete Corey on Sep 16, 2014.

Every time I use git bisect I find myself giddy with excitement. The tool is absolutely amazing at tracking down where a bug crept its way into your code. Being able to find the offending commit in minutes leaves me with an unhealthy sense of power over my code base. Sometimes git bisect can lead to an obvious fix if the bad commit is small, but sometimes a large commit can lead to hours of investigation.

When bisecting, I sometimes land on a commit like this:

f934e... is the first bad commit
commit f934e...
Author: ...
Date: ...
   Case #12345. Implemented feature X.

Feature X was huge. This commit touches hundreds of lines and dozens of files. I might have been doing frequency local commits while I was developing the feature, but I decided to be kind to my co-workers and my future self by rebasing everything into a tidy single commit in order to keep the repo history clean. Now, I’m faced with sleuthing through this behemoth to find my bug.

This always makes me question whether I should be rebasing my local commits before pushing them, or leaving them separate and pushing a large chain of commits to the trunk. By squashing and rebasing, you can cleanly revert large chunks of code (whole features) and quickly understand the project history at a glance. By not rebasing, you can quickly find where bugs were introduced and see the history through a more focused lens.

Personally, when working in teams, I try to keep my contributions to the trunk be fully self-contained. If I’m implementing a feature or fixing a bug, I want all of the changes related to that be in a single commit. This means that I squash and rebase my local commits before pushing. However, when I’m working independently, I find that I don’t rebase. I just push my chain of local commits.

Responsive SVG Height Issue

Written by Pete Corey on Sep 9, 2014.

You may have noticed, but I’ve been having some issues with the svg logo I’m using for this blog. I’m not specifiying explicit height or width attributes on the svg element, but I am setting a viewBox attribute. This lets me specify the height and/or width of the element through my css. If only the width or height is specified, the other attribute will scale accordingly, preserving the aspect ratio of the svg. After some feedback and testing with browserstack, I found out that this wasn’t behaving as I thought it would on some browsers.

1pxsolidtomato

When the logo is displayed in the navbar, I indirectly set the width to 150px (by setting the wrapping container’s width to 150px). Because the viewBox is set to "0 0 100 25", I would expect the height of the rendered svg to be 38px (0.25 * 150px). This worked as expected in Chrome 37 and Firefox 31 on my windows machine. But strangely, in IE 11 the height of the svg element was set to 150px. Even more strangely, in Chrome 37 and Safari 7 on OSX the height of the svg seemed to be stretching to over 1000px.

The fix was very simple. Setting a max-height of 100% on the svg element will correctly set the height of the svg on all browsers.

svg {
    width: 150px;
    max-height: 100%;
}

Honestly, I’m not entirely sure why this was happening. If I had to guess, I would assume it had something to do with this WebKit bug.