We Are Stac

Recap of Hey!Stac #1

2013-06-06T17:48:21Z

Many thanks to everyone that attended our first Hey!Stac event on June the 4th. We hope you enjoyed it as much as we did. A special thanks to Harry Roberts and Andrew Nesbitt for their excellent talks, and to Louise Brogan-Hewitt for the awesome brownies!

Harry Roberts kicked the night off with a talk explaining the benefits of designers adopting developer best practices. Josh and I then followed with a presentation about our first (failed) attempt at creating a software startup and what we learnt from the experience. Finally, Andrew Nesbitt closed with slides and a set of demonstrations where he flew a quadcopter with various controllers via Node.js.

We plan to make the night a regular meet up and will be confirming the date for the next one soon. Feel free to join us whether or not you attended the first time round, and if you'd like to give a talk on something that interests you please get in touch.

You can see the photos from the evening on Flickr.

Harry Roberts
CSS - You've Been Doing It Wrong

Josh Nesbitt & Brent Murphy
Signal Box - Burn After Coding

Andrew Nesbitt
Node.js and Quadcopters - What could go wrong?

Introducing Hey!Stac

2013-05-15T13:33:21Z

We're proud to announce a new series of talks and socials to take place over the coming months called Hey!Stac held at The Faversham in Leeds, UK.

Over the last few years we've been lucky enough to work with the most exciting, cutting edge technology. Our clients have trusted us to select the right tools for the job. We've also been fortunate enough to meet really talented individuals who are just as passionate about those technologies. We want to create a space where developers and other creatives can meet, talk shop and build a community. We hope to achieve this with Hey!Stac.

This is where you come in! The first event is to be held on 4th June, with 3 speakers confirmed. We'd love for this to grow into a bigger community event, but we need your support.

Here's a little more information about the first event:

3 speakers, each with a talk roughly around 15 minutes based on various topics from CSS to Quadcopters!
The event is kindly hosted by The Faversham in Leeds, with plenty of comfortable chesterfield sofas and a well stocked bar
The event opens at 7pm (talks will begin at 7:30pm)
Following the event, attendees are welcome to join us for a meal in the centre of Leeds

We've posted the event to Lanyrd for people to register interest. If you're thinking of coming drop us a tweet! We're also looking for speakers for future events, if this sounds like something you're interested in please get in touch.

We look forward to seeing you on 4th June!

Stac Client Receives Funding For Expansion

2013-04-25T09:00:14Z

For the past few months we've been working alongside Fatsoma, an online ticketing company that enables users to purchase tickets and organise events with friends. Based in Manchester and founded in 2006, Fatsoma have recently secured funding in order to add features and move into new markets.

At Stac, we're assisting the existing team in their drive to enhance the product and meet the demands of it's growing user base. We look forward to more exciting months ahead and plan to publish some technical posts about our work with Fatsoma in the near future.

Raising and Rescuing Custom Errors in Rails

2013-03-27T09:02:31Z

Following on from our post on Dynamic Error Page in Rails, this week we're going to look at raising and rescuing custom errors in a Rails application.

It's often useful to map custom Ruby errors to HTTP response status codes and have Rails render the appropriate HTML error pages. For example, you might have a controller that is acting as a simple proxy to a third party service such as Twitter or Facebook, and you need any of the HTTP errors encountered when calling those sites to be handled natively by your app. Another use case would be in a Service-oriented architecture (SOA), where you want any errors in your back end services propagated to your front end web application.

In this post we'll demonstrate rescuing status errors in an imaginary proxy controller using the awesome Faraday gem. For the sake of brevity we've omitted the inclusion of tests though in the wild we'd build such a feature using TDD and our favourite test weapon, RSpec.

Not Found

To start, let's handle basic 404 Not Found errors that occur when calling a service. For this we'll need a custom error class that extends StandardError.

# lib/errors/not_found.rb
module Errors
  class NotFound < StandardError; end
end

Faraday provides a neat Rack-esque middleware feature. By creating our own custom middleware we can catch any Faraday 404s and raise our custom error. Furthermore, we can re-use the middleware anytime we need the same behaviour.

# lib/errors/raise_error.rb
module Errors
  class RaiseError < Faraday::Response::Middleware

    def on_complete(env)
      raise Errors::NotFound if env[:status] == 404
    end

  end
end

Now for the proxy controller.

# app/controllers/proxy_controller.rb
class ProxyController < ApplicationController

  def index
    connection = Faraday.new(:url => 'http://someservice') do |f|
      f.adapter Faraday.default_adapter
      f.use     Errors::RaiseError       # Include custom middleware
    end

    response = connection.get('/some/resource')

    render :text => response.body
  end

end

At this point any NotFounds raised will still result in a 500 Internal Server Error in Rails. To alleviate this let's create a module that uses rescue_from, catches any custom NotFounds and renders the default 404 page.

# lib/errors/rescue_error.rb
module Errors
  module RescueError

    def self.included(base)
      base.rescue_from Errors::NotFound do |e|
        render "public/404", :status => 404
      end
    end

  end
end

We can then mixin RescueError into our application controller and handle NotFounds app-wide.

# app/controllers/application_controller.rb
class ApplicationController < ActionController::Base
  include Errors::RescueError
end

Unprocessible Entity and Internal Server Error

Next, let's create custom errors to help us manage proxy 422s and 500s.

# lib/errors/internal_server_error.rb
module Errors
  class InternalServerError < StandardError; end
end

# lib/errors/unprocessable_entity.rb
module Errors
  class UnprocessableEntity < StandardError; end
end

We'll also need to modify the RaiseError middleware to raise those errors. Here, we also ignore any non-error response codes, and treat any unknown error responses as 500s.

# lib/errors/raise_error.rb
module Errors
  class RaiseError < Faraday::Response::Middleware
    def on_complete(env)
      # Ignore any non-error response codes
      return if (status = env[:status]) < 400
      case status
      when 404
        raise Errors::NotFound
      when 422
        raise Errors::UnprocessableEntity
      else
        raise Errors::InternalServerError # Treat any other errors as 500
      end
    end
  end
end

Now, let's change the RescueError implementation to render the appropriate HTML page.

# lib/errors/rescue_error.rb
module Errors
  module RescueError

    def self.included(base)
      base.rescue_from Errors::NotFound do |e|
        render "public/404", :status => 404
      end
      base.rescue_from Errors::UnprocessableEntity do |e|
        render "public/422", :status => 422
      end
      base.rescue_from Errors::InternalServerError do |e|
        render "public/500", :status => 500
      end
    end

  end
end

Refactoring

So far so good. The code does what we need but there's far too much duplication. Furthermore, if we want to map additional error codes we'll have to add more branches to the switch statement in RaiseError and more rescue_from handlers to the RescueError class.

Accordingly, it's time to refactor the existing code. Firstly, let's delete our existing StandardError subclasses, and create the equivalent classes using a sprinkling of metaprogramming.

# lib/errors.rb
module Errors

  # Error constants
  NOT_FOUND               = 404
  UNPROCESSABLE_ENTITY    = 422
  INTERNAL_SERVER_ERROR   = 500

  # Base subclass for all response errors
  class ResponseError < StandardError; end

  class << self

    # Returns a hash of error names to response codes.
    def error_constants
      self.constants.each_with_object({}) do |name, hash|
        # Ignore any class constants
        next if (code = Errors.const_get(name)).is_a?(Class)
        hash[name] = code
      end
    end

    # Returns a class name from a constant name.
    def class_name_for_error_name(name)
      name.to_s.titleize.gsub(' ', '')
    end

    # Returns the error class for a given constant name.
    # Default to InternalServerError.
    def class_for_error_name(name)
      class_name = class_name_for_error_name(name)
      const_defined?(class_name) ? Errors.const_get(class_name) : Errors::InternalServerError
    end

    # Returns the error class for a given error code.
    # Default to InternalServerError.
    def class_for_error_code(code)
      name = error_constants.select { |k, v| v == code }.keys.first
      name.present? ? class_for_error_name(name) : Errors::InternalServerError
    end

  end

end

# Dynamically creates a subclass of ResponseError for each error constant.
# Adds a code method to return the correct response code.
# Adds the new class to the constants in the Errors module.
Errors.error_constants.each do |name, code|
  klass = Class.new(Errors::ResponseError)
  klass.send(:define_method, :code) { code }
  Errors.const_set(Errors.class_name_for_error_name(name), klass)
end

This is a large refactoring, but permits us to vastly simplify the error raising code.

# lib/errors/raise_error.rb
module Errors
  class RaiseError < Faraday::Response::Middleware

    def on_complete(env)
      return if (status = env[:status]) < 400
      raise Errors.class_for_error_code(status)
    end

  end
end

And similarly, the error rescuing code.

# lib/errors/rescue_error.rb
module Errors
  module RescueError

    def self.included(base)
      base.rescue_from Errors::ResponseError do |e|
        render "public/#{e.code}", :status => e.code
      end
    end

  end
end

Now, raising and rescuing additional error types is as simple as adding new constants to the errors.rb file.

# lib/errors/rescue_error.rb
module Errors

  # Error constants
  BAD_REQUEST             = 400
  NOT_AUTHORIZED          = 401
  FORBIDDEN               = 403
  NOT_FOUND               = 404
  METHOD_NOT_ALLOWED      = 405
  BAD_FORMAT              = 406
  UNPROCESSABLE_ENTITY    = 422
  INTERNAL_SERVER_ERROR   = 500

  ...
end

Summary

This brings our recent posts on error handling in Rails to a close. Feel free to add any suggestions, questions or feedback in the comments section.

Dynamic Error Pages In Rails

2013-03-13T18:12:15Z

It's a little known fact that you can easily substitute the default Rails HTML error pages with something more pleasant. You may have noticed the 404.html, 422.html and 500.html files that are generated with every new Rails project and wondered if there's a clean way to style them like the rest of your application. There is, and it's surprisingly simple.

Basic Implementation

The default status code templates are served by a Rack exception application. You can override this to be any Rack compatible app, including your applications router:

# config/application.rb
config.exceptions_app = self.routes

This will route any exceptions caught to your router Rack app. Now you'll want to define routes to display those errors yourself:

# config/routes.rb
get "/404", :to => "errors#not_found"
get "/422", :to => "errors#unacceptable"
get "/500", :to => "errors#internal_error"

This will route each error code to it's respective action in ErrorsController. Now we'll want to define those actions:

class ErrorsController < ApplicationController

  def not_found
    render :status => 404
  end

  def unacceptable
    render :status => 422
  end

  def interal_error
    render :status => 500
  end

end

We tell each action to render the appropriate HTTP status code related to the error that's been caught. All that's left to do now is create the view related to each action and you're done:

# app/views/errors/not_found.html.haml
%h1 404 - Not Found

When we visit /404 our 404 - Not Found view should render as expected. Now you can style your error pages without having to duplicate any styles into the public directory of your application.

Optimising Our Errors Controller

So far we've got working error pages, but it doesn't feel like the most DRY implementation. We could make it more RESTful by refactoring our errors controller to use a show action instead.

Let's start by changing our routes:

# config/routes.rb
%w( 404 422 500 ).each do |code|
  get code, :to => "errors#show", :code => code
end

Now we need to ensure our ErrorsController uses the code parameter we're passing through:

class ErrorsController < ApplicationController

  def show
    render status_code.to_s, :status => status_code
  end

protected

  def status_code
    params[:code] || 500
  end

end

To clean things up even more I've created a status_code method which defaults to a 500, this will protect any cases where we might not have the code present in the params hash.

The final alteration as part of this refactor is to rename our view files to use status codes rather than our previous naming scheme:

# app/views/errors/404.html.haml
%h1 404 - Not Found

And that's it. We've now got a reusable errors controller which is flexible enough for us to add new error types to in the future (by adding a new code to the error codes array and a corresponding view file).

It's worth noting that you shouldn't be doing anything fancy in these views. The reason these pages are rendered is because something has most likely gone wrong in your application, so you should probably stray away from making calls to the database or performing more complex actions.

A New Stac

2013-03-05T13:46:03Z

It's been well over a year since we last blogged and our online activity has been far too sparse, but it's not because we haven't been busy!

Stac was founded over two and a half years ago and during this time we've learnt a lot. Not just about our customers, but also about what we want to achieve as a company. We've worked on a wide variety of projects - from creating basic sites for small local businesses to building web applications for large companies. This has helped us identify our strengths.

We're bringing you a new Stac. We're re-inventing ourselves by concentrating on the areas where we excel. As of today we will focus on providing consultancy, programming and project management to startups and established businesses. We've created our own product and worked on many more, so we know how an application should be built and how to integrate ourselves into teams.

We're really excited about Stac's new direction and we're looking forward to meeting more original, creative businesses whose ideas we can make a reality.

We hope you'll join us on this blog (and on Twitter) for a new set of posts about the technical and non-technical challenges we encounter in our new venture.