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?
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.
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!
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…
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"
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:
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 ;).
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:
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;
…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!
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 (~5KSCSSLOC) 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.
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.
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;
…so that we are only compiling out our main CSS file. Then to test the compile times we can just run;
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.
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.
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 BSCMS 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: