John Beynon

a UK Ruby on Rails developer in Guildford, Surrey

Surrey Ruby User Group #1

Last night I attended the inaugural Surrey Ruby User Group held at a pub in Woking. Whilst numbers were low (which isn't a bad thing for an inaugural meeting) it simply led to a more intimate meeting. Two excellent presentations were given on MongoDB and RubyGems separated by some pub grub and an informal chat, covering subjects like RVM, Testing frameworks, what to test etc.

I can honestly say that I actually got more out of last night than I have from any of the LRUG meetings I've attended. The next meeting is planned for 26th April (last Tuesday of the month pattern) at the same location this time topics are expected to be Real World Testing and a Fishbowl session????

So if you're in Surrey or the surrounding area come along - Woking has good train links or if you're located in Guildford give me a shout and we'll share a ride.

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 'Backlog too deep' messages will 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.

HTML5, Headings and SEO impact.

Unless you've been living under a rock HTML5 is the new cool kid on the block - typically people are all over it's inbuilt media tags or the canvas element but there are more important everyday features that we all will use.

If you've ever worked with an 'SEO' expert/agency one of the primary things they will harp on about is headings. It's funny though, that in all the years I've been in this industry it's very rare to find 2 SEO experts that say the same thing and headings are certainly the area that cause most discussion.

You get the staunch approach (and usually the majority) where all headings have to be correctly nested from h1 down to h6, some want various levels duplicated - I've even had one that wanted the h1 to be placed before the closing body tag and then (wait for it!) absolutely positioned back to the top of the page via css - because "that's how Google would read the page".

HTML5 (whenever it's finally adopted) is certainly go to throw something else in the mix, duplicate headings are perfectly valid - depending on who you listen to they are currently but apparently it's not the 'Google' way. Without going into the gory details HTML5 adds more semantic ways to markup your content, notably introducing tags like header, nav, section, article and footer. Within certain of these new tags you are allowed duplication as they essentially mark the header/footer/nav of the section that they are in. Header is the obvious one to place your heading tags but now article (think an item - not necessarily an article such as a blog post per say) can have a header of it's own, so this markup is perfectly valid

You can use tools like http://gsnedders.html5.org/outliner/ to 'outline' your markup to ensure that it flows right but I certainly think that this is going to add interest when it comes to SEO, both from the 'experts' and also from Google itself. Since HTML5 essentially means Google has to do less work to locate elements on a page (think the new element and Google sitelinks - you know, those few links that sometimes appear under a search result which appear randomly on results) of course as long as they are used correctly. 
Google are relatively quiet on the whole subject, saying they don't want to get in the way of developers using cutting edge markup and their crawler will simply not parse markup it doesn't understand (see http://www.google.com/support/forum/p/Webmasters/thread?tid=1d3850aec4e3dd96&...)..

This is definitely an area that will need a close eye keeping on thats for sure!

My 4 tier backup strategy

Yep, it's overkill but I sleep safe in the knowledge that my data is backed up. I've seen people loose data all too often and there's no harm in being over cautious.

Last year my iMac went through a strange little spell and didn't want to boot. I did have backups in place but it definitely caused me to reassess what I was doing and where I was keeping my data. At the time I was using mozy.com which is great, but there's a few things to remember - your initial upload will always take an age (most internet connections are none symmetrical - VirginMedia is a massive half a meg up compared to their minimum 10Mb down) and as the saying goes 'what
goes up must come down'. Connections are sometimes throttled or capped so the next question is how long would it take me to get my data back and is that time going to be acceptable?

....time to reassess.

My first line of defence now is Dropbox.com - I use dropbox as my working folder, git repos (these are pushed to github too), documents (if not in Google), xcode etc all reside in a dropbox folder so they are automatically backed up, version controlled and duplicated to my iMac, MacBook pro and my mobile devices. When I move onto a new computer I install Dropbox and down comes all my 'required' stuff - I also store my OSX dotfiles in there too which are symlinked to their homes in my User directory so I can keep all my bash customisations, git configs, aliases all in sync. I particularly like DropBox because
it's a real folder on my disk - not a cloud volume so the data is local to me and not being accessed over the wire so there's no latency in accessing my data.

After Dropbox comes TimeMachine, I have a 1Tb drive partitioned (TimeMachine will use *ALL* available storage on the drive it uses before it starts purging backups but it's incredibly efficient in backing up duplicate data). TimeMachine does a system wide backup to local media so it's backing up both mine, my wife's profiles, photos etc that are taken off our various cameras etc - plus if/when you need to move to a new Mac you can simply start the OSX install process and choose 'Restore from TimeMachine backup'. If I had an excess of data I'd be seriously considering getting a Drobo to keep my data local to me.

All my photos are uploaded to Flickr presently - primarily so other members of my family can see them but it also serves as another backup tier. Photos are priceless memories so the more places these are in the better as far as I'm concerned.

Then comes Mozy.com - unlimited single computer backup for $5 a month - there's a multitude of these services out there now at the same price, crashplan, backblaze etc and the majority offer DVD/USB restores shipped via courier so you don't have to download all your data but you still need to get your data up there. I don't backup the entire system but 'watch' key user directores to make sure the important stuff is all out of my house.

Whilst this seems overkill it covers me for all eventualities;

Dumb fingers is covered by Dropbox (with TimeMachine as a backup)
Local failure is covered by TimeMachine
Total loss is covered by Flickr and Mozy.

Syncing multiple calendars on an iPhone

In our household we make heavy use of Google apps and most notably
calendaring to keep our busy schedules in check. On Android it's easy
to add multiple calendars but I've always struggled on my wife's
iPhone in the end resorting to adding a new 'account' logged in as
myself just syncing my calendar.

It turns out there's an easy solution, from an iPhone visit
http://m.google.com/sync - from there you are able to select any
calendars your are already subscribed to via Google Calendar to make
them available on your iPhone.

Simple when you know how.

Deleting item from Has Many Through assocation

I needed to remove a specific category from a specified list of blog posts defined through a :has_many, :through association. Here's the migration I wrote;

 

In hindsight, I'll probably just run this data manipulation from the Rails console rather than committing this code as a migration but it's useful nevertheless.

And in a bid to write even less code as us Ruby developers love to do, here's a shortened version;

dusting off....

Yep, it's time to dust off the old blog again as the dust has been gathering again...

I figured a new direction I'd like to take my blog is providing some code snippets (via Gists) from my day to day work. I'm certainly no Ruby master but hopefully they will serve useful for me to remember them as well as others.

A few Android updates from me

So Android 2.2, aka Froyo has now shipped and I think my operator (Orange) was one of the first to get it out into the wild being as I've rooted and reloaded a vanilla HTC Desire ROM I couldn't apply the update anyhow.

Over the past few weeks I've been wondering what value HTC Sense was actually giving me - the vanilla Android UI is nice and polished enough, I totally get why Windows Mobiles use HTCs own UI on top of the ghastly Windows Mobile UI - anyhow, to cut a long story short I'm using a totally custom ROM baked from here removing all of the HTC Sense stuff (in fact, almost all of the HTC apps altogether) - it's not possible to entirely get rid of all HTCs customisations but it's a good deal better. In the process I've also started to use the Fake Flash method for entering recovery as well as providing access to run Nandroid backups etc.

A problem I found was that removing HTC Sense the Android launcher would insist on linking the 'Phone' shortcut in the launcher bar to the HTC Phone application so now I'm using ADW Launcher  in it's place which provides lots more customizations and allows you to change the default shortcut icons.

All in all, still loving Android and being able to tinker with the phone at this level!

Finally My Google Apps account is a first class citizen

If you use Google Apps this will be all to familiar to you. As Google Apps users we all lived in this kind of limbo where we had to have our Google Apps account as well as a Gmail account since outside of Google Apps your Google Apps login was useless. In fact, it was so useless that you may have even accidentally created a 'ghost' Google profile using your Google Apps credentials for services like Google Reader etc where the account your using wasn't your Google Apps account but a ghost version using the same email address etc.

But no more! Google has started rolling out 'transitioned' accounts (apply by filling out this spreadsheet). It's a painless process but the end goal is that your Google Apps login becomes a first class citizen so you can use it on Google Reader and other Google properties. From what I can understand they transition accounts from Google Apps accounts to normal Google accounts (renaming any ghosted accounts in the process) so you can now login to gmail.com using your Google Apps credentials - this allow lets you use Google Multiple Account so you can switch been Apps/Gmail/Multiple Apps logins.

Woohoo, this is great news for any Google Apps user!
Web Statistics

Clicky