hecticjeff

Large-scale JavaScript Application Architecture

2012-02-11T00:00:00-08:00

Interesting talk about organising javascript in more complex applications.

Resque Rails Auth

2012-01-13T00:00:00-08:00

Recently I found myself wanting to access the resque-web ui on a live application. I had considered just running resque-web as a separate process, but after reading this article I realised that I could mount resque directly in the router, awesome!

However, the application doesn't use devise for authentication, so I wanted an easy way to restrict resque-web to admins.

Using rails 3 router's advanced constraints you can pass a :constraints options with an object that responds to matches? and receives the current request as an argument.

Since the current user's id is stored in the session, we can simply retrieve the user and check if they're an admin.

class AdminRestriction
  def self.matches?(request)
    user_id = request.env['rack.session'][:user_id]
    user = User.find_by_id(user_id)
    return user && user.admin?
  end
end

MyApplication::Application.routes.draw do
  mount Resque::Server => '/resque', :constraints => AdminRestriction
  # Other application routes.
end

The AdminRestriction class performs the actual checks, in the router it is simply passed as a constraint.

First we pull the user_id out of the session, then we attempt to get the user from the database. Finally we check that we've found a user and that they are an admin.

If the user tries to access /resque and they are not an admin, they simply get a 404 error.

This technique can be used with any rack application, or indeed with any regular route, just pass a :constraints option (see the match method docs), and the constraints that you apply can use any part of the request to decide if it matches. You can restrict access by ip address, or do routing based on the request's geolocation.

The possibilities are endless.

Test Driven Development Lifecycle

2011-03-22T00:00:00-07:00

Start at the top level with a user requirement. This will ensure that you are trying to solve the right problem in the first place.

Cucumber / Steak

Write a simple high level requirement in cucumber or steak. For example if you were writing an api and you wanted to allow people to post activity.

First you would write out the requirement in plain english.

Feature: Creating activity
  As an activity producer
  I want to post activity to the api
  In order to share it with the world

  Scenario: POST to /activity
    Given I am an authorized activity producer
    When I post some activity
    Then I should receive a 200 success status

This defines the high level picture of what the application aims to achieve. From this point the next step is to write some steps to properly test that the features are working.

Obviously the features won't be working yet, because that's not how test/behaviour/real-world driven development works. If you start writing code before you really know what you are building, then it is likely that you will at some point, perhaps without realising, implement the wrong feature. More likely though, being that smart martin that you are, you will implement the correct feature, but unwittingly leave a bug in it. No harm, you say, bugs happen in software and it's probably only one line of code that needs changing. But if the bug doesn't manifest itself for a few days, weeks, months, then it will take an ever increasing amount of time for you to track it down. Then once you have isolated it, you have to ensure it won't happen again.

This all comes down to testing. If you can easily run a bank of tests that confirm that your application is behaving at night you will, infact, sleep better at night. For some this is reason enough to write tests, but wait, there's more. If you have a comprehensive collection of tests you can use to verify that your application is working correctly, then you are in a very good position to do some refactoring. No more worrying if you've broken some seemingly unrelated piece of functionality when you make a change to the application.

Controller tests

The next layer down the stack is the controller, this makes sense, since this is the layer that manages incoming requests. So after writing the initial acceptance test in a high level language, then implementing the steps necessary to test this logic in a slightly lower level language, you now drop down to a relativly granular level. This is where you start to stub out the main functionality of the application. So in the case of our activity example above, you would at this stage be stubbing out the functionality of the models, and just dealong with the way that controllers handle requests.

This layer may be preceeded by another, slightly higher level one in which the routing for the application is set up, however this is quite a web application specific area.

Model tests

The model tests are the core of the testing universe, they are very small, low level details about the various methods that a model provides.

The model tests are the most important tests, as they contain the business logic for your application. But they are often also the easiest tests to write. This is because a lot of the time you will be dealing with primitive data types. No external services to worry about. This is a good reason to push as much logic into the model as possible, it is far easier to test this that it is to put it in your controller then try to stub it out.

Other tests

All of this testing malarkey is great and everything, but sometimes you have got to just use the product to uncover random bugs, but don't worry, that's not to say we can't still use testing to help us. Instead of jumping right in and fixing that bug like a good boy scout hacker, write a failing test that reproduces the bug. This test may exists as (m)any layer(s) of the test stack. Often you will need to write a test in the acceptance layer to perform the same interaction that caused the bug, then once that has caught the bug, go down the layers and write tests for the code paths that the bug touches, these failing tests will then (all going to plan) be green once you have fixed the bug, and as a billy bonus you've got yourself another test or two that will ensure many good nights sleep in the future.

Final thoughts

The testing pattern of development is still not used as a default development technique. Many (most) tutorials you find out there will focus on the functionality that they are trying to tutor you on, but a vital part of implementing any functionality is to ensure a long lifespan by testing it thoroughly.

Testing will seem like a chore at first, but once you get the hang of it, the whole process becomes a pattern, that if followed with a small bit of dicipline, will lead you to enlightenment, it will allow you to model your ideas with more structure with the tools available.

In many ways it's like learning a new language, with more languages, you see more ways of doing things. With testing, you'll see new ways to express your applications logic using high level language.

hecticjeff.net

2010-06-04T00:00:00-07:00

This blog now lives at a new address, hecticjeff.net. If you're reading this then you are already here! I'm still using heroku to host the blog, it's quite simply the best (only?) way to host ruby apps in the cloud. If you want to get in touch you can now email me on self at hecticjeff dot net.

The blog is going to get some love soon, comments will be the first thing to activate, as I'm using the excellent toto from cloudhead I will most likely opt for the wonderful Disqus comment system. That's priority 1. Priority 0 is to write some more posts, but I've been settling into a new job (with the awesome Simpleweb crew) in a new city (Bristol) recently, so this blog has been neglected to say the least. But it's time has come.

An introduction to node.js

2010-02-14T00:00:00-08:00

Update: The node.js api is in constant flux until it reaches a 1.0 release. The code in this post doesn't work with the latest releases of node (it was written for the 0.1.3x series), however the concept is still the same. The best place to start is the node.js api docs.

I've only just got round to doing some coding with Ryan Dahl's great node.js project, although the project has been around for about a year now, so I've put together this short introduction to give you a taste of what node is about.

The project is under heavy development, and the api is still changing quite regularly, but don't let that scare you off, node is stable and usable now.

For those that don't know, node.js is a project that brings javascript to the server and into the realm of PHP and Ruby. However with node there is one big difference. It is based around the concept of events, just like in the browser, javascript waits for events to be fired, then invokes the function that has been attached to the event.

Node uses this to it's full advantage, most operations that you perform in node will have a callback associated with it, this means that node doesn't have to wait while it's completing some time-consuming task, it can go about serving other requests, then when the event is fired it can go back and execute the function attached to the event. This leads to very fast response times when using node as a web server, as it can handle thousands of requests per second.

The program can be installed easily on OS X (using Homebrew or compile from source) and Linux (compile from source), Windows support is planned in the future, but is currently non-existent. Once installed you have access to a command line utility, node, this runs .js files through the node interpreter.

A basic node hello world program could look like this:

var sys = require('sys')

function sayHello (name) {
  return 'Hello ' + name + '!'
}

sys.puts(sayHello('World'))

save this into a file and then run it from the command line like so:

As you can see it's just javascript syntax, just like you would use in a browser, but the first difference the astute reader will have noticed is the require() statement. This is built into node and conforms to the CommonJS Module specification. This version of require is slightly different from one you might see in Ruby or PHP, it actually returns an object which you can assign to a variable, or use directly:

require('sys').puts('Hello World!')

Each module is a self contained unit of code, it has its own private scope, so can define functions to use internally, then expose public functions to be used externally using the exports object. Here's an example of a simple module:

var calculator = {
  add: function (a, b) {
    return a + b
  },
  subtract: function (a, b) {
    return a - b
  },
  multiply: function (a, b) {
    return a * b
  },
  divide: function (a, b) {
    return a / b
  }
}

process.mixin(exports, calculator)

The last line may seem a little strange, but all it does is extend the exports object with the properties defined in the calculator object, if that line wasn't there then the module wouldn't return anything as it wouldn't export anything. To use our new (rather basic) module we'd do something like this:

// Assuming that calc.js is in the same dir as this file
var calc = require('./calc')

// Now we can use the calc object to do calculations, joy!
var ten = calc.add(3, 7)
var two = calc.subtract(5, 3)

This overview barely scratches the surface of what is possible with node.js, the api documentation contains all you need to know about node, and it is all on one (albeit rather long) page, so once you've read through it you should have a pretty good idea how you'd go about coding for it.

There are already some very interesting projects using node available to try. A quick glance at the node wiki will give you a glimpse of what is possible with this fantastic new technology, as well as some more background information on the project.