With a little JavaScript it’s possible to detect if a browser supports Server Name Indication and conditionally redirect to a HTTPS page. Code at the end of this post.

Trouble, thy name is Shared Hosting with SSL

Recently, I had to put a client into Amazon CloudFront for a high traffic event. I’ve done this a number of times, but this was the first time I need HTTPS support. Amazon offers HTTPS in two forms:

  • All Clients (Dedicated IPs)
  • Only Clients that Support Server Name Indication (SNI) “Older browsers and other clients that don’t support SNI can’t access your content over HTTPS.”

All clients sounds safe right? Well, it is, but it’s also very expensive and enabling it requires that you go through an approval process.

SNI is cheap and easy, but… I was aware of it’s existence, and knew it was a pain because of limited browser support. Time to check that assumption.

First, however, we need to understand the different types of hosting and, to do that, you need to know a little about how HTTP and SSL/TLS work.

How you clear the DNS cache on OS X has changed yet again…

DNS caching is a good thing in general, it speeds up your browsing by not having to request the same information over and over. However, if you are making changes to DNS, they will not appear until the cache expires.

On 10.10 Yosemite clearing the DNS cache is now done by running:

sudo discoveryutil udnsflushcaches

For the record:

(OS X > 10.6 && OS X < 10.10):

sudo killall -HUP mDNSResponder

OS X <= 10.6:

sudo dscacheutil -flushcache

Emacs 24.4 is officially released and Mac OS 10.10 Yosemite has arrived. As always, time to build.

Before begin you will need Xcode installed (free in the Mac App Store) to build Emacs. Of course if your the sort of person who uses Emacs, you’re probably the sort of person who has Xcode installed.

To build Emacs you also need Autoconf and Automake and Apple has stopped shipping these with Xcode. If you don’t already have them (hint: which autoconfig and which automake) you will need to install them.

In the Internet age we live in, it’s not uncommon for web servers to be hit with Unintentional, not so Distributed, Denial of Service (DoS) Attacks. The attacks itself is intentional, but it’s not trying to bring down the server. It’s just some stupid ‘bot running a probe as fast as it can and, as a side effect, bogging down your server.

Bots are evil, but at least smart bots rate limit themselves to keep off the radar.

The typical stupid bot is running a password probe against an admin login. If you run any WordPress sites, you see this. All. The. Time. There are many good options to prevent these attacks, including renaming well known URLs, IP filtering, and automatic IP banning software, like Fail2ban.

However, sometime you just need to make the attack go away now. For that, I have a couple of Bash functions/tcsh alias.

I often find myself needing to download files to my local box via SCP. Which means entering the hostname, the path, and the filename in to my terminal window. However, I’m really lazy, if I can’t auto complete it or cut and paste it, I’m not happy. Enter this simple Bash function:

I’m lazy and I’m always looking for ways to avoid any unneeded typing. Here’s a little OpenSSH configuration tip that can save you up to 16 characters (if you have crazy long usernames).


In most cases, if you enter 0 for an IP address it will expand to Likewise, 127.1 will expand to Why? Magic.

Not Magic

But really, why do these shortcuts exist and how do they work? It can’t be as simple as adding zeros, if it was 127.1 would more logically expand to

Turns out it’s a historic quirk in the inet_aton() function which is used, directly or indirectly, by most software to parse IP addresses in dotted-quad format into integers.

Sometimes an AJAX request on a page you’re developing needs to hit a server on a different domain. Web browsers’ Same-Origin Policy means (among other things) that other domains called from AJAX need to be whitelisted using the Access-Control-Allow-Origin header.

While this limits the damage malicious Javascript injected into a page can do, it’s annoying in development. You could whitelist your dev box,, or (depending on how you work), but that’s ugly.

Fortunately, there’s an easier way, temporarily disable same-origin policy.

As part of the work Indra did for Stand Up To Cancer’s telethon, I need to make use of Convio/blackbaud’s Luminate Online Server APIs. Luminate Online is a widely used fundraising platform and relationship manager for non-profits.

I’ve turned that development work into open source in the form of gem providing Ruby bindings to the APIs.

I have only implemented a handful of endpoints, Luminate Online doesn’t have any kind of test mode or sandbox, any testing has to be done with live data. However, I’ve used a meta programming approach making it easy to quickly add additional endpoints.

All of the endpoints I have implemented have been used in anger.

The details are in the repo:

Yesterday, I was involved in a fire drill around the launch of a new Rails site on a very tight time frame. The site worked fine in development/staging, but the index was taking upwards of 10 seconds to render in production.

Because it worked outside of production we leapt to the conclusion it was related to the hosting infrastructure. We checked Apache, Passenger, server load, network configuration, and so on. Nothing.

Finally, I thought to check log/production.log, and there is was:

Processing by BlahController#index as */*
  Rendered blah/_carousel.html.erb (5795.2ms)
  Rendered blah/index.html.erb within layouts/site (5801.5ms)

We quickly tracked it down some image processing that wasn’t being cached. It didn’t show outside of production because the image assets were different. I won’t bore you with the details.

However, I will bore enlighten you as to my point. When debugging a problem, start with the simple things. The Rails logs aren’t very detailed, but they provide more than enough information to quickly drill down to problems in your code.