• Role: Web Developer
• Basis: Full time
• Salary: Based on experience
  
• Location: Storm HQ, Bath, UK

We’re working with some fantastic clients on really interesting technical projects and you’ll be getting involved from day one. Storm are also working on a range of SaaS apps that we are hoping to release over the next 12 months.  As part of our development team, any downtime from client work will be spent on these.

If that sounds interesting, read on!

Our ideal candidate will:

• Be a capable programmer with good knowledge of OOP and MVC web frameworks who understands when, and more importantly, when not to use design patterns and buzz word technologies.
• Know Ruby on Rails 3.2 well.  If not, we’d still be interested to hear from excellent programmers keen to learn Rails.
• Be competent with HTML, CSS and JavaScript to produce clean, semantic markup.  Knowledge of their new overlords, SCSS and CoffeeScript, is helpful.
• Consider source control essential.  Experience with Git helpful.
• Follow a rough, but not religious Test-Driven Development approach.
• Be adaptable and a quick learner.
• Have excellent written and spoken English.
• Be comfortable working in an agency environment, communicating directly with clients face-to-face and over the phone.  Previous experience in a client facing role is preferred, either at an agency or freelance.
• Be available to work from our offices 5 days a week.
• Thrive working in a young, dynamic company.  You’ll fit into the culture and become an integral part of the team.

We don’t require you to be a rockstar developer the finished article, just have a solid understanding of the principles and be enthusiastic to learn from, and share ideas with the team.

Benefits

• Macbook Pro and 27″ Cinema Display.
• Office in central Bath with Xbox.
• Flexible working hours.
• Friday afternoon off.
• Unrestricted holiday allowance.
• Casual dress code.
• Fantastic coffee from our awesome machine.  Tea + biccies too!

To apply, please send a CV and covering letter, along with your salary expectations and when you’d be available to start to cv@stormconsultancy.co.uk.

We’re interested in hearing from individuals, no recruitment agencies.

It’s a simple way of handling all of the oAuth requirements in Twitter’s API v1.1 that become mandatory on 5th March 2013. For more information about the plugin itself, you can read my original post on the first release.

Version 2.0 is vastly improved and allows you to:

• Use multiple Twitter accounts rather than just the one defined in the configuration
• Define a custom cache expiry (and allows you to disable it for debug purposes)
• Pass any custom parameters you want to Twitter’s API, and override the defaults easily

This update is fully backwards compatible with version 1.0. You can either upgrade the plugin using the WordPress admin panel, or just drop the updated class file in — but it will delete your cache the first time it runs, as the format has changed significantly to support the new features.

We suspect many people aren’t yet prepared for Twitter’s great API 1.0 switch off on 5th March 2013, so it’s worth checking any sites you manage or maintain to make sure they are using authenticated calls to Twitter.

You’ve probably got two controller methods

def upload
  @model = Model.new
  @model.save

  @uploader = @model.csv_file
  @uploader.success_action_callback = upload_successful_model_url(@model)
end

def upload_successful
  @model = Model.find(params[:id])

  # Now what??
end

You need to save the file name to the model so that it can be referenced later. The documentation (at the time of writing) offers no indication of how you might go about that. The secret is in the key attribute that CarrierWave adds to your model.

def upload_successful
  @model = Model.find(params[:id])
  @model.key = params[:key]
  @model.save

  redirect_to model_path(@model)
end

Simple. When you know how!

What’s your preference — Mac or PC? Tweet us at @StormUK and let us know, we’d love to hear your reasons!

Adam in MacFormat

We’re all looking forward to 2013 and like a lot of companies, we’re setting targets for the year ahead. However, now is also a good time to check that you’ve got all of the basics right in terms of your IT provision.

Our own Paul Leader has been giving advice to our local business community on just that – and you can read his piece below in Agenda, Bath’s local business magazine.

Paul in Agenda magazine

Displaying a post’s comments separately from the main content can be useful in many circumstances. Although less common nowadays, traditionally many blogs chose to feature comments in a pop-up window or lightbox. It can also be desirable for editorial or legal reasons, for caching purposes, or perhaps if you are publishing individually art-directed posts. It can also be handy when using WordPress for a non-blog website.

WordPress has some legacy support for pop-up comments, but the feature is largely abandoned and poorly supported. Also, it generates the comments pages at yoursite.com/?comments_popup=XXXX, which is both bad for SEO and will often appear in analytics as one page.

To solve this conundrum, I’ve created a basic plugin for developers to implement separate comments pages for their WordPress site. The plugin generates a comments page for each post at /comments/, using the WordPress rewrite endpoints API. It’s not quite install-and-go, so check out the notes below.

Download the Storm Comments Page plugin on GitHub

Notes:

• You will need to customise the generated page by copying the included comments-single.php template into your theme; if you’re using this as a pop-up you will want to remove the get_header() and get_footer() calls.
• WordPress doesn’t provide a filter hook for comments_link(), so you’ll need to manually replace links to your comments to point to the new page at /comments/
• A current limitation is that it doesn’t play well with comment pagination.

With a small amount of work, you can get a lot more out of your Heroku hosting whilst drastically improving the performance of your site. You might need to spend a little bit of cash on other services, but a lot less than if you simply moved the dyno slider up a few notches, and the result will be much better scalability.

So how do we max out the performance of our Heroku apps? First we stop using Heroku for things it’s bad at, then we let it do more of what it is good at, running your application code.

1. Offload Assets to S3 and CloudFront using asset_sync

By default a Heroku dyno is responsible for serving all the assets for your site, so every page load will involve multiple requests to the dyno.

The asset_sync gem modifies asset pre-compilation to sync all of your assets to an Amazon S3 bucket from where they are served directly and freeing up your dyno to handle more requests.

If you want to speed things up even more, you can slap Amazon’s Cloudfront CDN in front of your S3 bucket with multiple subdomains. Michel Sikkes has an excellent guide to serving you assets with S3 and cloudfront. Your assets will be served through Cloudfront from multiple subdomains (e.g. assets[0-3].myapp.com), all of which point to the same bucket. Not only will your assets be served through CloudFront’s speedy global CDN, but most will be downloaded in parallel. Browsers make a limited number of concurrent requests per host name (2 for IE, more for other browsers) so using multiple CNAMEs increases the number of concurrent connections, significantly reducing the page load time for users with good connections.

The cost of serving assets from S3, even with CloudFront, is very cheap and scales directly with the amount of data. Compared to adding another Heroku dyno this is great value, and has the added benefit of speeding up overall page loads.

2. Don’t Upload and Process Files with your Web Dynos

If you use something like CarrierWave or Paperclip, by default the uploading and processing of images is done by your dyno. While this is happening your dyno is completely tied up, unable to handle requests from any other user. If one person uploads a 2Mb image on a slow connection everyone else will be locked out for the duration.

To prevent this from happening you need to decouple the upload process from your dyno. The CarrierWave Direct gem does just this. With a bit of client-side magic it uploads files to S3 directly, rather than through the dyno. The images then get resized by background processes using DelayedJob or Resque. This obviously has the downside that you’ll need a worker running, but there are ways to manage these cost-effectively which I’ll talk about next.

Another option, which we’ve used recently, is the awesome Cloudinary service. They provide direct image uploading, on-demand image processing (including face detection, which even seems to work on cats) and a worldwide CDN all in one package. There is a free tier to get you started, and for $39 (slightly more than one Heroku dyno) their Basic plan will be more than enough for many sites. Obviously you could just spend money on another dyno, but that just scales your performance linearly, without really solving the fundamental performance bottleneck.

3. Background Processing the Smart Way with Delayed::Job and HireFire

Background processing with Delayed::Job is a great way of speeding up your web requests. Potentially slow tasks like image processing or sending signup emails can happen outside of the request-response cycle, making it much snappier and freeing up your dyno to handle more requests. The downside is that you need to run a worker dyno at $35/month.

Michael van Rooljen’s HireFire modifies Delayed::Job and Resque to automatically scale the number of worker dynos based on the jobs in the queue. Because Heroku charge by the dyno/second, spinning up 10 workers for one minute costs the same as one worker for ten minutes, so with HireFire you can potentially get things done quicker while paying less than you would if you ran a dedicated worker dyno.

HireFire does have one limitation, it only works for jobs scheduled for immediate execution. If that is an issue Michael has a HireFire service that will monitor your application for you, so jobs scheduled in the future will be run.

4. Offload Complex Search to a Dedicated Provider

If you have an application that needs to perform complex searches over large datasets don’t do it in your application directly. If searches regularly take a long time (a couple of seconds or more) consider using something like Solr (available as a Heroku plugin), Amazon CloudSearch, or one of the many Search as a Service providers. You’ll not only get faster search performance in many cases, but you’ll save vast amounts of development time trying to optimise your in-app search. Of course, if you have a simple application with straight-forward search then this probably won’t be worth it the cost, but it’s something worth considering.

5. Turbo-Charge your Application with Memcache backed View Caching

If you’ve not encountered caching in Rails, stop reading this article right now, go read the Rails Guide to Caching and then DHH’s short guide to key based cache expiry. Caching in Rails 4 will be even better, with improved support for “Russian Doll” caching.

View caching in Rails can have a profound effect on your application’s response time. In the past we have found that rendering pages, especially complex ones with lots of partials, can easily account for two-thirds of the total processing time, much more than you might expect.

Simply using caching will help speed up your application, but the default cache store is not shared between dynos so the benefits are limited. In contrast, a Memcache store is shared between your dynos so they all benefit from any cached item. Heroku has two add-ons that let you very easily add memcache to your project. The Memcachier addon gives you 25mb for free, and is pretty reasonably priced from there on up. Just adding a small cache store of 25mb can make a significant difference to the load time of your pages.

6. Finally: Slice and Dice your Dynos with Unicorn

So after spending a little bit of time, and a relatively small amount of cash, we’ve offloaded much of the work that was being done by our web dyno and onto services that are better suited to it; drastically speeding up our request-response cycle. Our single dyno can now handle significantly more users per minute, who are happier because they get a much faster response from the site.

However the default Heroku dyno configuration only handles one request at a time. If you wanted to increase your level of concurrency in the past you would have to increase the number of dynos. That’s all changed with the release of the Rack server Unicorn which can handle multiple concurrent connections. For most applications a single dyno should be able to handle between two and four connections at a time. The main constraint will be memory (limited to 512mb per dyno), so keep an eye on the gems you are loading in your production environment. Florian at Rails On Fire has done a great introduction on setting up Unicorn on Heroku. If you’ve followed the previous steps you should be using less memory on your web dynos, allowing you to use more threads.

Putting it all Together

At the end of all this we’ve freed up our Heroku dyno from doing things it’s not very good at like serving static files and uploads, and juiced up its performance when doing what it’s great at, serving Rails application requests with no sys-admin in sight.

Each technique can be easily applied to your existing applications, but if you develop with them in mind from the start you get all the benefits with almost no additional work. On their own each one will help the performance of your application, but combining them together will significantly extend the amount of time before you have to start forking out for lots more dynos, and when you do you’ll get much more bang for each of your thirty-five Heroku bucks.

If you’ve got any other tips for getting the most out of a Rails application, whether or not it’s on Heroku, we’d love to hear about it them!

You can currently visit an exhibition of images collated through Felix’s account, along with image collections from Bath, at the We Love Bath exhibition in the Bath Central Library. The event runs from 26 Nov to 9 Dec 2012.

Go along and check it out what Bath Life Magazine are calling “An absolute must-see for any self-respecting Bathonian”.

The answer is that you need to have a line with two ## at the start for the parser to pick it up.  For example:

  ##
  # Public: Scope to return the most recently logged entries, ordered
  # by the date the were created, newest first
  #
  # count - The number of entries to return.  Default 6.
  scope :recently_logged, ->(count=6) { order('created_at DESC').limit(count) }

That gives you a section like this in your docs:

The event, run at Komedia with an audience of 300 teens, attracted top level speakers from the city and beyond with the aim of encouraging attendees to think outside the box and to embrace the opportunities available to them.

Felix spoke about his efforts in creating one of the city’s most influential news sources through embracing citizen media in the form of his @WeLoveBath twitter account. The account now has over 12,000 followers and Felix has been widely recognised for his efforts in connecting the community.

You can watch Felix’s presentation at TEDxYouth@Bath, starting at 01:33:00ish here: http://new.livestream.com/tedx/TEDxYouthBath/videos/6603040