Authoritah v0.1.2

I’ve pushed a new version of my authorisation/permission gem that fixes a small issue found by a developer in my team. It now supports propagating permission rules down the controller inheritance chain.

So given:

    class ParentController < ActionController::Base
      include Authoritah::Controller
      permits :current_user
    end

    class ChildController < ParentController
    end

The ChildController here would inherit the permits :current_user rule from the parent.

Just sudo gem install authoritah to pick up the latest version (v0.1.2). As ever, bug reports/feature requests would be appreciated.

That’s it. Thanks for watching.

RSpec 2 on Rails 3

Just a quickie – RSpec 2 is on its way, but if you’re itching to get specs running under Rails 3 you can. The RSpec 2 alpha/beta gems are in the wild, so to get it running under Rails 3, just do the following.

Firstly, install the gems:

$ sudo gem install rspec --prerelease
$ sudo gem install webrat
$ sudo gem install rspec-rails --prerelease


Once this is done, you need to add the gem declarations to your Rails Gemfile:

group :test do
gem "rspec", "2.0.0.a5"
gem "rspec-rails", "2.0.0.a6"
end


Note, these versions are correct as of 12th Feb, but will change.

Finally, you need to run the newly available generator to create the RSpec structure and helpers:

$ rails g rspec:install


And you should be set. Happy speccing.

Authoritah update

I’ve pushed a couple of changes to my Authoritah gem recently that hope to make it a bit more useful. Firstly I’ve fixed using Procs that access the controller for testing whether an action is permitted or not:

class WidgetController < ApplicationController
  forbids :current_user => Proc.new {|user| user.id == params[:id }
end

This now works as expected.

I have also added the ability to change the outcome of an authorisation failure rather than always returning a 404. You can now use the on_reject option to customise the behaviour, as follows:

  
class WidgetController < ApplicationController
    permits :current_user => :logged_in?, :on_reject => :redirect_to_login
    forbids :current_user => :blacklisted?,
            :from => [:create, :destroy],
            :on_reject => Proc.new { redirect_to '/blacklisted' }

    def redirect_to_login
      flash[:notice] = "Please login to view widgets"
      redirect_to root_url
    end
  end

I hope these changes prove useful.

Simple authorisation gem for Rails

I’ve been looking around for a simple gem to handle basic Rails controller authorisation but I didn’t really get on with any of the maintained gems out there. They mostly rely on additional tables in your DB, cover hundreds of cases I don’t care about and generally seem a lot of effort.

The fruits of this frustration are here. My main aims with authoritah were providing a simple declarative DSL for specifying your permission rules that you customise to hook in to whatever authentication system you use.

Here’s an example:

class WidgetController < ApplicationController
  permits :current_user => :admin?, :to => [:create, :destroy]
  permits :current_user => :logged_in?, :to => :show
end

Authoritah relies on you providing a method or methods on your controller that result in an object you can query for authorisation information. In these examples we’re following the restful_authentication/authlogic approach of a current_user method that returns the currently logged in user.

At present you can’t just do the following:

class WidgetController < ApplicationController
  permits :logged_in?
end

which would imply you want the action to be permitted as long as there is a user logged in (i.e. you have a logged_in? method on your controllers). I’ll fix this soon though.

For more information see the gems home at http://github.com/indmill/authoritah.

Hurl – curl, but sicker.

One of the more useful things to come out of Rails Rumble this year is a fantastic little service called Hurl. Put simply, it allows you to set a URL and HTTP headers, and then displays the resultant content, be it HTML, XML, JSON, whatever. It’s a great little tool for developers exploring APIs such as Twitter, Facebook, Delicious. It’s curl on steroids. And it’s great.

Kudos to Chris Wanstrath and Leah Culver for a great little tool.

Mercurial sub-repositories for project dependencies

With a number of our projects now sharing certain assets (primarily CSS files, images and javascript files) I’ve recently been looking in to a new feature of Mercurial; subrepos. These have been introduced in Mercurial 1.3 and are roughly analogous to externals in Subversion. Having just completed a first stab at using subrepos where we have assets shared between a Java Struts app and a Rails app I thought I’d share the steps in getting things up and running on OS X.

Dependencies

You’ll need the most recent version of Mercurial (v1.3.1 is the latest stable build). I use MacPorts to manage most of my apps on OS X. To install Mercurial with macports simply do:

$ sudo port install mercurial

Running the Mercurial command should return the following output:

$ hg --version
Mercurial Distributed SCM (version 1.3.1)

If not, update your ports install and try again.

Setting up

First we need a couple of repos – lets set them up with Mercurial:

$ hg init css-assets
$ hg init app
$ cd css-assets
$ echo "body { margin: 0 }" > main.css
$ hg add
$ hg commit -m "Initial stylesheet commit"

We now have an assets repository with a stylesheet and an empty app repository.

Subrepos

Now we need to link our css assets project to our app. It’s worth bearing in mind that subrepo support is experimental at this point and may change, but at this time the process is:

1. Clone the subrepo in to your parent repository.
2. Write an .hgsub file to identify the subrepo
3. Commit the parent project to link the subrepo.

So, we must do the following steps:

$ cd app
$ hg clone ../css-assets css
updating working directory
1 files updated, 0 files merged, 0 files removed, 0 files unresolved
$ echo "css = css" > .hgsub
$ hg add
$ hg ci -m "Committing CSS subrepo"

The subrepo is now linked to the app repo. Committing the app repo has one major side-effect; it creates an .hgsubstate file. This identifies the version of the subrepo you link to. No matter which updates are pushed to the CSS repo by other users, our app repo will be fixed to the version in the .hgsubstate file. You can confirm this easily:

$ cd css-assets
$ hg log

The tip changeset ID of the CSS repo will match the version in the app repo .hgsubstate file. To update the app subrepo we must do the following:

$ cd css-assets
$ echo "p { margin: 5px }" >> main.css
$ hg ci -m "Updated main stylesheet"

This has updated the CSS repo. The app repo will not yet be aware of these changes; if you check the .hgsubstate file in your app repo you’ll see the changeset ID will still be the ID of the initial commit to the CSS repo. To update the version of the CSS you must:

$ cd app/css
$ hg pull -u
$ cd ..
$ hg ci -m "Updating CSS subrepo"

Now check the .hgsubstate file. The changeset ID has been updated to point to the CSS repo tip. Anyone cloning your repo will now get the latest versions.

That pretty much covers everything I’ve uncovered so far. An improvement I’d like to see is the ability to set your .hgsub file to point at a remote repo and for it to handle the initial clone for you rather than manually cloning and configuring (and if it can do this, someone please inform me how – the documentation is still a little thin).

Jetty, JRuby 1.3.0RC1 and Warbler

We’ve been preparing a new product for launch over the last few weeks, and part of the process has been testing out using Jetty and JRuby for the live deployment instead of our trusty Mongrel and MRI deployments.

We’ve been using the very handy Warbler gem (http://github.com/nicksieger/warbler) to package up our Rails app ready for Jetty, and it’s been going swimmingly. However, after a recent upgrade we’ve seen some very painful memory problems, with the Jetty process adding 100b to the heap with every request. We finally tracked the errors down do a part of our code doing a lot of XML processing in the Hpricot jruby gem. It turns out that Warbler bundles JRuby 1.3.0 RC1, and this was having difficulty with Hpricot.

And this is where Github saves the day again! Downloading a more recent fork of the warbler gem with JRuby 1.3.1 has solved our pain (the gem is at http://github.com/finnlabs/warbler) and our test deployment server is now zipping along nicely again.

Rails 3 is going to rock

Yehuda Katz presented the keynote at Rails Underground this morning, and very interesting it was too. The core of his speech revolved around the new version of Rails. Added to the usual tenets of convention over configuration, DRY, etc was a new concept. Opt-in.

Rails 3 has been broken down from a monolithic framework to a set of loosely coupled modules tied together with stupidly simple public interfaces. The router is a module, the renderer is a module, validation is a module, etc, etc. Any can be used or not in your Rails app, or indeed your vanilla Ruby/JRuby/MacRuby app. This direction is beneficial for many reasons:

• New Rails projects can just pull in the parts of the framework they need.
• Existing projects can easily remove dependencies on parts of the framework they don’t need.
• Rails components can be swapped out for alternative implementations

He showed examples of how Sinatra can now effectively be implemented in Rails, how ActiveSupport has been broken up to be more useful outside Rails, and how ActiveModel has replaced ActiveRecord. Very interesting, and very promising. Apparently the APIs will be settled within the next few weeks so edge Rails is going to be stabilising in terms of the interfaces.

One thing is for sure. Rails is going to be a a very different beast.

Clojure Robot on Google Wave

I’ve wanted a little project to start learning Clojure in a bit more detail, and having got access to Google Wave a couple of weeks back, I figured a suitable challenge would be to build and deploy a simple Wave robot to Google App Engine. So I did. And may I present… CENSOR BOT!

Censor Bot (censorbot@appspot.com if you have a Wave account) listens to messages posted in a wave and removes naughty swear words. It’s a pretty simple beast (about 40 lines of Clojure in all), but is non-trivial enough to serve as a good first project. In this post I’ll go through the process of getting a Clojure Wave robot built, hosted on GAE and accessible in your wave account.

Firstly we have some dependencies:

• Java 6
• Ant
• A Google App Engine account (sign up here)
• A Google Wave account
• The Google App Engine SDK
• Clojure 1.0

Firstly, download and install the Google App Engine SDK from here. Just unzip the SDK (latest is v1.2.2) somewhere useful. Whilst you’re there, it’d be a good idea to set up your GAE account too. Once you’re signed in (at http://appengine.google.com) you can click the “Create an application” button and reserve your app identifier. Note this down as you’ll need it later.

Next, ensure you’re running Java 6; you should see the following:

$ java -version
java version "1.6.0_13"
Java(TM) SE Runtime Environment (build 1.6.0_13-b03-211)
Java HotSpot(TM) 64-Bit Server VM (build 11.3-b02-83, mixed mode)


If you’re running a pre Java 6/JDK 1.6 version, you’ll need to upgrade as the Wave API only runs on Java 6. I suffered a couple of gotchas here on OS X. Firstly, open Applications/Utilities/Java Preferences.app and update the list so Java 6 is selected. This ensures code runs under that version of the JVM. However, Ant will still try and compile under JDK 1.5. You have to adjust your JDK symlinks too.

$ cd /System/Library/Frameworks/JavaVM.framework/Versions
$ sudo rm CurrentJDK
$ sudo ln -s 1.6 CurrentJDK

You’ll also need to download and install Clojure. Instructions here.

Now the fun can begin. cd to your favourite project location and run:

$ git clone git://github.com/indmill/censorbot.git

This has everything you need to write a basic Clojure Wave robot. The only things you’ll need to change are:

• In build.xml, update the sdk.dir property to point to your GAE SDK location.
• In war/WEB-INF/appengine-web.xml, change the application to be your GAE application identifier.
• That’s pretty much it, unless you’re feeling brave and want to rewrite my newbie Clojure code.

You should just be able to run:

$ ant deploy


now to deploy the app to GAE. It may complain that your GAE credentials are not stored. I had to run:

$ path/to/gae-sdk/bin/appcfg.sh update war

And voila, you should be able to add your newly deployed censorbot to a Wave and off you go. The censorbot doesn’t censor many actual rude words yet, but feel free to edit its dictionary.

The code itself is very straightforward if you have done any Clojure. The main entry point from Wave-land is the function:

(defn -processEvents
  [this bundle]
  (let [wavelet (.getWavelet bundle)]
    (welcome-if-new bundle wavelet)
    (doseq [event (blip-submitted-events (.getEvents bundle))]
      (censor (.getBlip event)))))

It retrieves the wavelet from the event bundle, welcomes itself to the wave then filters out BLIP_SUBMITTED events and censors the contents. I’ve tried to make it as functional as I can but proper Clojure hackers out there could probably tidy it up a lot. Anyway, I welcome any comments, and if my instructions have missed any steps let me know and I’ll improve. Thanks.

Early stage developers

Early Stage Developers

As an ex-freelancer, and somebody who still receives the odd request I have grown weary of approaches of the following ilk: “We’ve got this great idea, we just need a developer to build it for us. We haven’t got any cash but we’re willing to offer a small equity share”. These approaches are designed make $ signs spin around in the developers eyes. However, my gut feeling when I receive an approach like this is:

1. If the business guy won’t risk any cash (whether it’s his or somebody elses) on the big idea then it’s probably a crappy idea.

2. All the business guy is trying to do is offload the risk of failure to me.

As a business guy, when raising cash for a new enterprise you would typically search for investors to put in money in return for a percentage of your company. Early stage investors usually put up relatively small amounts of cash for larger percentages of the company. This is because the perceived *risk* – at an early stage the company/idea is incredibly unlikely to succeed – makes it effectively worthless. When they approach a developer to build the product at this early stage and all that is offered is equity they are asking them to take the same risk, with something just as, if not more valuable than money. Time.

I can see why this is an attractive route for business guys. Why take investment to fund development of your product and lose a great chunk of your company when you can go straight to the developers and get the product built for a much smaller percentage? But the approach is flawed in many ways:

– Good developers always get work. Proper paid work. You’re not going to get the best developers.

– Given a fixed percentage equity, developers will cut corners to deliver features in the shortest time.

– If the relationship sours there’s a lack of flexibility on how to proceed without resorting to legal channels

Business guys trying to develop their products in this way need to realise one thing. The early stage developer is an investor and thus should be treated in a similar way; someone to pitch to, someone to get advice from, someone to be completely transparent with. Someone to trust. And thus someone to treat with respect.

Now I’ve been lucky with the jobs I’ve selected in the past. I hooked up with very passionate people who had (admittedly limited) funding, who had a great idea that I shared the passion for, and who have been very transparent in their dealings with me. Even given that however, there are certainly things I would do differently now.

Firstly, the business guy *pays* for the first iteration (which they did for the gig I accepted). No question. This way you have closure if the relationship doesn’t work out for whatever reason. You get paid up front, you do the work to contract, then you stop. How much is up to you, but I suggest a daily rate that works for you. At the end of this iteration the business guy should have a prototype or v1, and the developer has been paid.

If the first phase works out and they like what you’ve delivered, we have a basis for a relationship. Now it’s time to barter equity for features; DON’T accept a flat equity percentage for continual involvement. Less “Give me 20% and I’ll work for you”, more “I will build you the commenting system for 5% equity in your company”. I think this approach is great for many reasons:

– the business guy is focussed on getting a useful feature, and the developer is focussed on delivering it.

– the business guy gets more flexibility – if he gets funding in the future, then future iterations can be paid for in real money.

– the relationship has flexibility in the event it sours as the only agreement is to deliver *the next iteration*.

This iterative model can continue until the product is complete, the product fails, the developer gets hired as the CTO, whatever.

I think there’s a seed of a good business venture in there somewhere. Any developers out there interested? There’s a small equity share in it for you…

As an ex-freelancer, and somebody who still receives the odd request I have grown weary of approaches of the following ilk: “We’ve got this great idea, we just need a developer to build it for us. We haven’t got any cash but we’re willing to offer a small equity share”. These approaches are designed make $ signs spin around in the developers eyes. However, my gut feeling when I receive an approach like this is:

1. If the business guy won’t risk any cash (whether it’s his or somebody elses) on the big idea then it’s probably a crappy idea.
2. All the business guy is trying to do is offload the risk of failure to me.

As a business guy, when raising cash for a new enterprise you would typically search for investors to put in money in return for a percentage of your company. Early stage investors usually put up relatively small amounts of cash for larger percentages of the company. This is because the perceived risk – at an early stage the company/idea is incredibly unlikely to succeed – makes it effectively worthless. When they approach a developer to build the product at this early stage and all that is offered is equity they are asking them to take the same risk, with something just as, if not more valuable than money. Time.

I can see why this is an attractive route for business guys. Why take investment to fund development of your product and lose a great chunk of your company when you can go straight to the developers and get the product built for a much smaller percentage? But the approach is flawed in many ways:

• Good developers always get work. Proper paid work. You’re not going to get the best developers.
• Given a fixed percentage equity, developers will cut corners to deliver features in the shortest time.
• If the relationship sours there’s a lack of flexibility on how to proceed without resorting to legal channels

Business guys trying to develop their products in this way need to realise one thing. The early stage developer is an investor and thus should be treated in a similar way; someone to pitch to, someone to get advice from, someone to be completely transparent with. Someone to trust. And thus someone to treat with respect.

Now I’ve been lucky with the jobs I’ve selected in the past. I hooked up with very passionate people who had (admittedly limited) funding, who had a great idea that I shared the passion for, and who have been very transparent in their dealings with me. Even given that however, there are certainly things I would do differently now.

Firstly, the business guy pays for the first iteration (which they did for the gig I accepted). No question. This way you have closure if the relationship doesn’t work out for whatever reason. You get paid up front, you do the work to contract, then you stop. How much is up to you, but I suggest a daily rate that works for you. At the end of this iteration the business guy should have a prototype or v1, and the developer has been paid.

If the first phase works out and they like what you’ve delivered, we have a basis for a relationship. Now it’s time to barter equity for features; DON’T accept a flat equity percentage for continual involvement. Less “Give me 20% and I’ll work for you”, more “I will build you the commenting system for 5% equity in your company”. I think this approach is great for many reasons:

• the business guy is focussed on getting a useful feature, and the developer is focussed on delivering it.
• the business guy gets more flexibility – if he gets funding in the future, then future iterations can be paid for in real money.
• the relationship has flexibility in the event it sours as the only agreement is to deliver *the next iteration*.

This iterative model can continue until the product is complete, the product fails, the developer gets hired as the CTO, whatever.

I think there’s a seed of a good business venture in there somewhere. Any developers out there interested? There’s a small equity share in it for you…