There are a growing number of Heroku iOS applications coming out for managing your Heroku applications. Nezumi, Iroku and more recently LovelyHeroku. Having absolutely nothing to do one evening (when does that ever happen?) I sat down and produced a comparison of the features that the 3 applications offer.
UPDATED: Take a look at my comparison - it's dated as 29 October 2013 (prices and feature set) and I may have missed some features or incorrectly compared a feature - if I did, it can't have been obvious enough how to perform the task in hand.
Boost were gracious enough to provide me with a free version of their application. Thanks!
I'm not making judgements here, you can do that yourself.
Something else I do is manage the Surrey Ruby User Group. We're a little way out of London but working at Kyan I have good access to people willing to give presentations - we don't attract numbers like the London Ruby User Group but we're slowly growing and meeting regularly at the moment every 2 months or there abouts.
However, lastnight was slightly different. We played RTanque. RTanque is a game for Rubyists built using the Gosu 2D library to get a top down view on the action.
The idea is simple. Destory the other tanks! You build a tank in Ruby, you have access to sensors (radar) and can control the direction of your tank and turret, speed of movement etc - it's great fun and everyone had a great time, we held an elimation tournament to start with before loading all the bots into a single arena for a death match.
Take a watch of the DeathMatch on YouTube.
There's presently a bug in Rails 4.0.0 that can cause you issues deploying your application to services like Heroku.
In short, a validation such as
validates_acceptance_of :terms, allow_nil: false
can result in your application becoming undeployable for the first time on Heroku.
If there's one thing I do a lot of is building Rails applications for deployment to Heroku. It's also something that my colleagues at Kyan do. Keeping up to date with the best practices and Heroku's own recommended best practices is tough - not to mention configuring your application for a seamless asset pipeline deploy.
Nine times out of ten my applications are hosted on Heroku and consequently following their recommended best practices I use Unicorn webserver for my Rails applications.
Ten times out ten I use the Better Errors gem to replace the standard Rails error pages.
When Heroku Postgres dataclips first appeared I remembered thinking that they were pretty cool but was struggling to find a use case for them.
More recently, my opinion has changed to just how awesome they are. Take for example a recent case where for whatever reason a Heroku worker hadn't been running for several weeks so the delayed job queue size was quite large.
We had a requirement to use a specific font when rendering a PDF using wkhtmltopdf / wicked_pdf.
Here's the slidedeck from the presentation I gave last night to the Surrey Ruby User group.
Better late than never, here's the slide deck from my presentation earlier this week to the new Heroku UK user group.
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.
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.
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 herokuenvsample.rb file which you DO checkin to source control.
Implementing authorship on Google - Get your pretty face showing up on Google search results.
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.
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.
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.
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.
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.