Fever on Heroku

So yesterday brought the sad news that Google Reader is being killed off. C’est la vie it seems, given it was a Google product. In my search for an alternative I rediscovered Fever and decided to see if I could run it up for free on Heroku. Onwards…

Unfortunately there were more issues than I first thought with the licensing built into Fever and getting it to play nice in a filesystem-less environment like Heroku. The below steps will work just fine, however you will be left having to re-activate Fever every time your dyno goes away (thus blowing away the in-memory downloaded activation). Sadface.

Personally I think the news about Reader is quite sad, as I would quite happily have paid for it as a service. In fact I like RSS so much that I actually shelled out the $30 for Fever when it first came out years ago (I was also pretty massive Shaun Inman fanboy if I’m being honest).

I ended up setting Fever aside because screw having to manage self-hosting for PHP and MySQL, right?

If you’re new to Fever I recommend going and checking it out, but also reading the post in response to the Google Reader announcement by Fevers author, Shaun, for a good list of what Fever is and isn’t.

Enough jibba-jabba!

Let’s turn up the heat!

OK, so I’m going to go ahead and just assume that if you’re reading this then you are already probably familiar with Heroku and already have an account and their toolchain already set up on your machine (for the sake of not having a bad time I’m also going to assume you are not using Windows, because LOL).

There are unfortunately several extra steps to getting the Fever app set up on Heroku. The design of Fever’s setup is such that it actually downloads itself during setup. Weird stuff. I guess this is some sort of code obfuscation(?), but all of this code can be acquired prior to entering your activation anyway…

Anyway, this all creates something of an issue when you are looking to deploy to an environment that doesn’t have a writable file-system…like Heroku.

The way to get around this is to go through the setup process right up until activation on your local machine—at which point the you have all the app code—then just commit this code and push that up to Heroku.

If you just commit the bootstrapping stuff and then run the setup on Heroku the app will run just fine…right up until the dyno is recycled, at which point the code disappears, your app breaks.

Local stuff

First up we need to make a local repo for Fever to live in and for us to deploy to Heroku from.

Let’s open Terminal and mash some keys!

mkdir fever
cd fever
git init .

…while we’re at it let’s create a new Heroku app!

Running PHP on Heroku is not officially supported, but it is easy, thanks to iphoting’s awesome PHP + nginx, etc… custom buildpack.

heroku create -s cedar -b git://github.com/iphoting/heroku-buildpack-php-tyler.git

…and now we’ll grab the Fever bootstrap code and commit it. We also need to add an empty index.php file to the root of our app. This is required as this is how Heroku will identify it as being a PHP deployment…

wget http://feedafever.com/gateway/public/fever.zip
unzip fever.zip -d . && rm fever.zip
touch index.php
echo "<?php header(\"Location: /fever/\"); ?>" > index.php
git add -A .
git commit -m "Added Fever bootstrap code, Heroku index.php"

Next up you’ll need to load up the app locally in your browser (you will need a way of running PHP/MySQL locally, just grab MAMP free), and jump over to /fever/boot.php.

Jump through all the setup steps until you get to the database setup stage. Throw in your local MySQL details (you’ll need to create a temporary DB, don’t worry we’ll delete it all later).

At each stage here the boot script is downloading more of the actual fever app, once you get to the section where it asks you to activate Fever you have all the core code needed to run the app.

The last thing we need to so is throw in the actual settings for our Heroku MySQL database and replace out the local settings we used when running setup.

Before we can do that though we need to add a MySQL addon to our app:

heroku addons:add cleardb:ignite

Once that’s done, we can grab our DB config details by running the following:

heroku config | grep CLEARDB_DATABASE_URL | cut -d " " -f2 | php -r '$conn=""; $in=fopen("php://stdin", "r"); while(!feof($in)){ $conn=$conn . fgets($in, 4096); } print_r(parse_url($conn));'

Note that path is the database name, just leave out the / at the start.

You then need to add these credentials to ./fever/firewall/receipt_db.php.

Once this is all done:

git add -A .
git commit -m "Fever setup complete"

…and deploy!

git push heroku master

Once the post-recieve hook has finished up (it will do a bunch of stuff to pull down binaries for our buildpack) you should be able to load up the app:

heroku open

Awesome—you should now have Fever up and running! You just scored a very capable RSS reader for the worth-while one-off cost of $30m and set up free managed hosting for it for eternity (or until Google buys Heroku and then shuts them down ;).

Get reading!


Bonus Round!

By default Fever will refresh feeds on page load, however they do provide a method for triggering a refresh via a web-hook, which you can hit from a cron task.

If this sounds like something you might be interested in then install and configure the Heroku scheduler addon:

heroku addons:add scheduler:standard
heroku addons:open scheduler

You’ll want to set the command field to:

curl -L -s http://YOUR_HEROKU_APP/fever/?refresh

Save and you’re done.

Evaluating Bourbon

I’ve been meaning to check out Bourbon for quite a while as a potential replacement/alternative to Compass. Some notes after finally kicking the tyres.

Firstly, Bourbon has a few different opinions to Compass that are worth knowing about.

In terms of CSS support they state that they attempt to support all the fairly bleeding-edge CSS3 stuff. As for browsers, all the usual suspects are supported;

  • Firefox 3.6+
  • Safari 4.0+
  • Chrome 4.0+
  • Opera 10+

…however, only flavours of IE from 9 and up are officially supported. They also don’t (and intentionally won’t) include any support for anything that requires an IE filter to work—which seems reasonable to me.

However—anecdotally—I saw a few commits while in poking around in the repo that seemed to indicate that IE 7/8 support is still being patched in where it makes sense. I suspect the “IE 9+” tag mainly stems from the refusing to include IE filters (i.e: opacity in IE < 9, for example).

Regardless, if you really need to maintain support for older versions of IE and still want to use Bourbon then you can always write & maintain your own mixins to wrap up these edge-cases. No biggie.

Another point of difference worth noting is that Bourbon doesn’t offer support for spriting images for you (a good thing, IMO), where Compass does.

Additionally Bourbon seems to be quite proactive about deprecating mixins and functions as browser support changes. This is awesome.

Finally, Bourbon is a SASS only library since v3.0.0, and has no dependancy on any external language. This is really excellent as it means that the library is platform agnostic and can cleanly be used anywhere SASS can. As an aside, check out the compact() function for some sexy SASS action!

Evaluating

I thought the best way to put Bourbon through its paces would be to try and convert over an existing Compass project and see how the process went.

Thankfully I have a moderately sized Rails app, with a bunch of stylesheets (~5K SCSS LOC) lying around. This app currently makes pretty heavy use of Compass’s CSS3 mixins, and some very limited usage of the Compass image spriting stuff.

Porting over

I was pleasantly surprised by how easy it was to port code over to Bourbon from Compass. The only real pain-points were several undefined mixins that we were depending on (opacity() and border-radius() were the main culprits), everything else had equivalent names and function signatures as you would expect. Awesome!

The only other pain point, was the image spriting stuff, which will need to be refactored away (read: deleted) later on. I didn’t want to bite it off for this test so I just picked through that code and commented it out for now.

All up I think it took me about 20 minutes to convert everything over and have the app booting and looking good without any errors.

Compile times

I also thought it might be interesting to check out the performance of the two to see if there was any substantial difference.

Given that I’m testing this against a Rails app, I altered some of the asset-pipeline config for the project;

config.assets.precompile = ["application.css"]

…so that we are only compiling out our main CSS file. Then to test the compile times we can just run;

rake assets:clean && time (RAILS_ENV=production rake assets:precompile >/dev/null)
Compass:
10.00s user 1.02s system 99% cpu 11.040 total
Bourbon:
8.81s user 0.96s system 99% cpu 9.781 total

This obviously includes Rails booting up so these numbers would be much, much higher than if you just directly ran sass.

Not a great deal of difference there really, though I think it might be interesting to see how that scaled to a really large quantity of SCSS.

tl;dr

At the end of the day it’s just CSS, right? Well, yeah.

But then again the value (for my use-case anyway) of using a tool like Compass or Bourbon is that it allows me to offload all responsibility for vendor-prefixed CSS3 stuff out of my app. This is pretty valuable.

I’m really loving Bourbon’s simplicity—it really is just SCSS. This means I can use it in non-ruby projects easily and don’t have to deal with the “magic” feeling that Compass comes with - needing config, a project, etc. When I do want to use Rails it’s just a Rails Engine. Too easy.

I also very much enjoy that they are opinionated about a few issues I care about, they are not afraid to deprecate mixins, and they don’t include any IE’s filter bullshit.

Bourbon is also potentially slightly faster.

I’ll be using Bourbon on new projects from here on.

Recently my mate Andy clued me up on a technique that he uses when designing for retina/non-retina devices. It’s a pretty simple idea really, but is a real timesaver when you are working on an interface that is going to be used on a range of devices.

The idea is to design at non-retina sizing, and then use scaling by 200% for retina, by 50% to jump back to non-retina. Keep working, rinse, repeat.

Assuming that you’ve built your document well (keep objects non-raster, sizing non-pixel, use the pixel-grid, etc.) this action is non-destructive. It also helps you to make sure that things still look good in small format, and you can still add retina detail to icons and such by jumping over to 200%, tweaking, jump back and make sure that things degrade well. Nice!

The Bjango guys have actually made some awesome actions that you can use to make this toggle a key-press away. While you’re over on Bjango’s site—I highly recommend checking out their app Skala Preview. Both are huge time-savers.

Hello World

Blogging has always been something that I’ve always aspired to do. In some ways I kinda have been for a while—a folder full of Markdown on my desktop—but that doesn’t really count, right? Consider this my first attempt at writing more, and publicly.

My hope is that writing more will improve my writing and allow me to better explore and share things I learn about, well, whatever I happen to find interesting…

The design is minimal, and largely incomplete. The objective was to get something up and running as fast as possible. The last thing I wanted was the realisation in 2 months time that I’ve half-built BS CMS thing, have 14 half-finished PSDs, and end up throwing it all away—something I have extensive experience with.

I think I’ll probably keep hacking away and improving/fixing the site as I keep posting.

For those interested, here are the technical particulars:

  • completely static, served from S3
  • built using Middleman
  • articles are markdown
  • SASS + Compass
  • typefaces are Source Sans Pro for display & Chaparral Pro for body type

Anyway, should be a fun adventure.