Custom fonts on Heroku

We had a requirement to use a specific font when rendering a PDF using wkhtmltopdf / wicked_pdf.

We've been scratching our heads on this one for a while and had resorted to thinking that we'd need to use a custom build pack.

It turns out there's a much simpler solution. Ubuntu custom fonts can be added to the .fonts folder in your home directory. If you drop into a bash session and try and access the ~ path you get taken to your application. So we thought, hang on - maybe we can just commit a font to our app by putting it in a .fonts directoy. It turns out you can!

My ElasticSearch 101 to Surrey Ruby User Group Slide Deck

Here's the slidedeck from the presentation I gave last night to the Surrey Ruby User group.

My Heroku UK User Group Slide Deck

Better late than never, here's the slide deck from my presentation earlier this week to the new Heroku UK user group.

Notes from the field #3

The decorations have gone up!

Migrating mySQL to Postgresql - If you find yourself needing to move from mySQL to Postgresql.

Time for Decorating? - A nice clean approach for Decorators in your Rails applications. Keeps those views super super clean of logic!

12 Factor Apps - Great architecture advice for building web applications

Tomorrow is my presentation to the Heroku UK user group - The Why, What and How of Heroku.

ENV variables for development environment

Something caught my eye in a recent Heroku newsletter in regards to setting ENV variables in development. The newsletter talks about using Foreman for running your application locally which will look for a .env file in the root of your project which should contain key=,value pairs for your variables for development.

Great if you use Foreman, but what about Pow? Well, no fear - it supports the use of .powrc and .powenv (with .powrc loading first).

In practice it seems like the best solution will be to have a sample_env file under source control for reference and then developers can create either a .env or .powenv file with their own variables off the sample keys - or both (via a symlink from one to the other) which will cover all bases.

Notes from the field #2

Not long till Christmas, 35 days in fact.

Inaugral Heroku UK user group - Starring myself of course, for Heroku nuby's - not seasoned pro's. I won't be showing ANY code fingers crossed.

A great deep dive into writting Hubot Scripts - We recently implemented our own Hubot at Kyan - he's a lot of fun...and not much use (at the moment)

A neat approach to local development Heroku ENV variables from Engine Yards VP of Engineering! - Been looking for a good solution to this for a while, this seems like a REALLY nice approach if you couple it with a heroku_env_sample.rb file which you DO checkin to source control.

Implementing authorship on Google - Get your pretty face showing up on Google search results.

Notes from the field #1

I find a lot of useful stuff that I want to remember so figured I'd start sharing more of what I'm finding and reading in what I'm going to call 'Notes from the field' - it'll probably be weekly but don't hold me to that.

Using Unicorn On Heroku - Tried this this week and got excellent increase in throughput - worth a look if you're running on the Cedar stack

Textmate to VIM - Useful article if you're considering making the switch

Automated tagging of Heroku deployments - Script your deployments to Heroku and tag your code post deployment

Control ads Google Shows you - Find out why you're seeing certain Google Ads and opt out if you want.

New Kyan.com launches

It's been a labour of love here at kyan but we've finally taken the covers off our shiney new website. It's been getting some excellent praise on the internet - we hope you like it as much as we do. Oh, and it's hosted on heroku of course.

Inaugral Heroku UK User Group

I'm pleased to announced that the inaugral Heroku UK meeting will take place at Skillsmatter on December 5th.

Registration is now open for the event here - the talk descriptions on the website will change a little bit between now and then. I'm going to be doing a fly through of Heroku answering the why, what and hows.

Hopefully we'll have time for a Q&A session afterwards and also discuss plans for the group as we appreciate that 'Heroku' is quite a broad topic.

All Change!

Right then, time for a change.

I've been in a dilema for quite some while now. I haven't blogged in ages - my blogging output has been declining since the whole 'social media' revolution started. I've been stuck between just adopting Google+ as a way consolidating thoughts, notes etc but there's no RSS feed and after the initial high take up of Google+ it's taking a while to build up again.

So here I am, a new clean blog. I'm going to start entirely fresh so I'm leaving all my oldcontent where it was on Posterous and move forward here. I hope you'll join me - things have changed quite a bit since my prolific blogging days, I now only use Ruby on Rails and as much as I can deploy to heroku so there won't be any talk (except to mention) ColdFusion or Fusebox etc. It's going to be all Ruby on Rails, Heroku, probably a bit of Apple and Android thrown in for good measure and perhaps the occasional rant.

Increasing Heroku Dynos != More Performance

Something I keep coming across time and time again is a complete misunderstanding of Heroku Dynos and what increasing the count of them in your application will give you.

Firstly, repeat after me

Increasing Dyno count DOES NOT increase performance

When you give someone a slider the first thing they'll do is put it right to the top as everyone wants everything and then balk at the $828 bill they're going to receive monthly - I've done it and my clients have done it but this is NOT increasing performance of your application.

Heroku's definition of a dyno is A dyno is a single web process running on Heroku. It is capable of serving a single web request (pageview) at a time.

Heroku documents the key concepts of their platform here - but hey, we're developers who don't read no stinking documentation.

In brief, if you have a web page in your application that has a request time of 250ms then a single dyno will be able to process 4 requests a second. If you then increase to 2 dynos you'll be have to process 8 requests a second, 3 dynos - 12 requests a second etc etc. Increasing dyno count increases concurrency NOT performance so it's down to you to get your code as performance as possible, halfing a request time of 250ms to 125ms would double your possible requests per second to 8 so making your code as performant as possible will keep your Heroku bill down since you'll need less dynos.

If your dynos are unable to process the requests then the requests are put into the 'backlog' for later processing as dynos become free. If this backlog becomes too deep and the Heroku platform cannot keep up you will receive an H11 error (read more here) in your logs and an error page be served to your visitors. At this point you have two options, increase your dyno count or make your code more performant. As Heroku themselves detail - simply adding more dynos to increase concurrency may not be a good thing either if your database cannot keep up with the throughput - this is why when I last spoke with Heroku do not intend to add autoscaling to their platform since if your database is the cause of your backlog then throwing more dynos at your application will only compound the problem. People need to be care of auto scaling options that are coming out whether it be via a gem or a Saas offering. Mind you, this is all behaviour that your can read about on the Heroku site but I thought I'd add a summary here.