I got my first GoPro, the HERO2, in 2011 and have been using it to record all my ski trips since. Not because I do anything that's really impressive, but because it's fun and a great way to review my skiing to look for ways to improve. If you haven't had the experience of recording something you thought was impressive on video yet, what usually happens is that the footage looks incredibly boring compared to how it felt at the time you recorded it. A 10 foot cliff looks like a 3 footer on the wide angle lens. Keep that in mind next time you see a POV video that really impresses you: it was far crazier for the person who recorded it.
Usually I make a season recap video in the fall as a way to get excited about the upcoming year, but this year's took me longer to finish. Mostly due to laziness, but I also wasn't too excited about the conditions on any of my trips last year. Hopefully this west coast drought will end soon, though 2014-2015 doesn't look like the season to make that happen so far.
Anyway, here's the video:
Baldface lodge and Whitewater in Nelson, BC were the season highlights even though a high-elevation rain event happened the week before I arrived. Hoping for more wintry conditions there this year.
This was done by a PHP script that scraped Squaw's snowfall tracker every hour to check for changes. But last month I was looking to build something “real” in Node and decided that rewriting this script would be a good place to start.
Analysis paralysis is the state of over-analyzing (or over-thinking) a situation so that a decision or action is never taken, in effect paralyzing the outcome. (Wikipedia)
It's natural to want to do things "the right way", and I just kept thinking; Is this package already outdated? Is this random person on GitHub actually maintaining this package? Will X play nicely with Y? What would someone experienced use here? Didn't I just read something about a fork of Node that was going to progress even faster?
Perhaps this is just typical of all newer languages/frameworks and I had false expectations about Node feeling more mature given its popularity. Turns out that the Node ecosystem poses a challenge for some experts as well:
So maybe that's just the way it's gonna be. Time to make some choices and start coding.
After a reading a few tutorials and opinions I decided a few things:
I'd use Node 0.11x invoked with the --harmony flag for ES6 for generator support (details). After using Twisted's deferred.inlineCallbacks for years I can't imagine returning to callback hell. And flow control libraries like async still feel dirty to me. Language-level support is where it's at.
Koa looked like a nice basic web framework to start with.
It really doesn't do all that much, so didn't take too long to put together. The hardest part was probably figuring out which external packages were going to play nicely with ES6 generators/Promises for Koa. There are surely things I've done wrong but it's in the wild and I learned a lot along the way. If this project were of more importance, this might even be one to throw away.
Now I wonder how things will change before my next Node project...
Since 2011 this site has been powered by WordPress running on m1.medium Amazon EC2 instance. It became neglected once HipChat took off and the version of Ubuntu it was running, Natty Narwhal (11.04), stopped being supported on October 2012... Oops! Instead of trying to upgrade the host I figured I’d take the opportunity to simplify things and try out some new tools.
From WordPress to Jekyll
First off, I really don’t need a beefy database-backed CRM powering the site, so WordPress is out. In its place I’ve chosen Jekyll, the static website tool that powers GitHub Pages. Hugo also looked appealing but lacks the ecosystem of themes and support that Jekyll has. Since I’d like to spend more time writing for the blog instead of tinkering with it, Jekyll wins. (I'm sure Hugo will catch up in time - it seems like a very well run project.)
Jekyll is also nicely supported by GitHub Pages but I saw scatteredcomplaints about their CDN settings and limitations placed on Jekyll plugins so have decided to host the content on Amazon S3 instead.
Ideally I wouldn’t have to worry about deploying site updates to S3 at all, and Travis CI is the tool to make that happen. It watches the site's GitHub repo for changes and pushes them over to S3 with the help of the s3_website gem. This post from one of the Travis CI employees shows how easy it is to set up.