Speech therapy and technological tomfoolery
This blog’s been a few different things in its life…it started out as a place for me to post photos that didn’t fit on my main gallery site, and it ended up turning into, primarily, a travel blog. But I just finished setting up something nifty, and wanted to collate the information so that I don’t forget about it, and on the off chance that someone else finds it useful.
I just finished setting up a web site for Heather J. Shpak’s speech-language therapy private practice in Winnipeg. I’m a professional geek, but this is still something I’ve never really done before. Took a lot of time, but it was interesting.
Most (all?) of the people who have email subscriptions to my blog won’t care about the rest of this post. On the other hand, if you know someone who’s looking for private speech therapy in Winnipeg, I know where you should go 🙂
The technologically interesting point about this site is its incredibly fast, reliable, and cheap hosting via Amazon Web Services. Basically, the entire site is static HTML, which allowed me to shove all the files into Amazon S3 (Amazon’s file storage system). I then set up an Amazon CloudFront wrapper around it, and added a CNAME to the DNS records aliasing http://www.winnipegspeech.ca to d2mezwgnssuxyv.cloudfront.net (the hilariously cryptic subdomain that Amazon assigned). The final step was setting a “root object” on the Cloudfront distribution, so that when you go to the site it knows which page to serve first.
- The entire site must be static for this to work. No PHP or ASP; it’s all HTML and CSS. To make things easier for me, I cobbled together a really ugly templating system that abuses Gnu Make and the GCC preprocessor, allowing me to easily propogate changes to common elements like the navigation menu. I recommend using some sort of templating system, but probably not this one. It’s quirky, and it was tricky to make it work properly.
- You need to make sure all items in your S3 bucket are publically accessible. This is not the default.
- Setting a Cloudfront root object is harder than it should be – you need to POST an XML request. The free version of Cloudberry Explorer can do it, and that’s what I used, but even there the option is buried in a weird place and took me a while to find. (Hint: it’s not in CloudFront Manager. In the root of your S3 account in CloudBerry, right-click the S3 bucket and choose Distribution. You can set a default root object there.)
- CloudFront needs to take a few minutes to bake your changes before they’re ready. I assume it’s just propogating stuff through the cloud, but after making a change to the distribution, it often took five or ten minutes for the State to change from InProgress to Deployed. This was a little weird, because it meant that after, e.g., setting the default root object, it still looked like it wasn’t working because it hadn’t finished deploying.
- If you set your default root object to an object that doesn’t exist in the S3 bucket, the error you get is “Permission denied”. This is surprising, and can result in you wasting time fiddling with permissions, when they’re fine. Trust me.
- Because you need a CNAME record, you can’t access the site through the URL without the “www.” prefix (because you can’t make a CNAME for a root domain, only for subdomains). I’ll probably make winnipegspeech.ca to point to my non-cloud server, and have Apache serve an HTTP 301 redirect (Moved Permanently) to http://www.winnipegspeech.ca. Unfortunately this means that my not-very-reliable server is still part of the process, albeit for a very brief instant.
- Amazon’s hosting costs for a small low-traffic site are ridiculously cheap. I made up some numbers and plugged them into the cost calculator, and it estimates that this will cost $0.02 / month. I can find that much money on the sidewalk every month if I keep my eyes peeled.