I’m sorry there hasn’t been much action on here recently – it’s been a manic few weeks.

I’m writing a book on Writing Performant Ruby (catchier title pending), which will be coming out in the new year, and – if anyone happens to be around the Worcester, UK region then I’m presenting at @WooWebUK on Google’s Go language next month (September 20th) – look it up and come along!

There’ll be a couple of new blog posts out in the next couple of weeks, as well as a tutorial series on designing scalable apps – check back!

Update – or, where I’ve been and what I’m doing!

If you wouldn’t mind taking a couple of minutes to fill in this quick questionnaire about the direction that RefineryCMS PgSearch should take, it would help the community massively! This relates to the

refinerycms-pgsearch

Help improve RefineryCMS PgSearch!

I’ve just released an improved version of the Search gem for RefineryCMS by Resolve Digital. This version uses PostgreSQL’s inbuilt full-text search capabilities to offer performant search in a scalable manner on Postgres based sites.

Check out http://jgwmaxwell.github.com/refinerycms-pgsearch for more information, or just add

gem 'refinerycms-pgsearch'

rails g refinery:search

rake db:migrate

rake db:seed

rake refinery:search:rebuild

And you are underway! Enjoy

New Gem – RefineryCMS PgSearch

EDIT – THIS POST WAS RETARDED, AND COMBINED TWO MUTUALLY EXCLUSIVE WAYS OF DEALING WITH THINGS.

You only ever need one OR the other of these approaches – Strong Parameters does not work WITH attr_accessible – if you want to use it, you need to remove the mod below for attr_accessible by default, just like you set whitelist_attributes to false with ActiveRecord.

This is a follow up to this post, which dealt with Mass Assignment Security in ActiveRecord.

Mongoid doesn’t support setting

config.active_record.whitelist_attributes = true

attr_accessible nil

module Mongoid
module WhitelistAttributes
extend ActiveSupport::Concern

included do
attr_accessible nil
end
end

module Document
include WhitelistAttributes
end
end

That’s all you need to do – remove the line

config.active_record.whitelist_attributes = true

Mass Assignment Security with Mongoid

Firstly, many apologies for not having had the time to update this much recently, I’ve been flat out working on the final stages of Cloudhaven, the hosted e-Commerce platform that I’ve been working on for a long time. I have to say I’m delighted with what we’ve managed to produce – there are many innovative features that will make a difference to real-world stores selling online. I will be offering a full write up soon on what it does, along with releasing 2-3 gems that we’ve built for community release in the process of building it, but don’t worry – this site isn’t going to become propaganda!

However, we are starting to send out some invites to people registered on our beta-testing mailing list, if anyone would like to sign up to become a tester, you’ll get a fully featured store free for the duration of testing and some great savings for life after the beta period comes to an end.

If anyone wants to register for more details and to try it out, go to http://cloudhaven.net and sign-up. We’ll never spam you, nor let your details out of our clutches, so come and find out more!

Launching Cloudhaven Hosted e-Commerce

There has been a reasonable amount of focus on security recently, with a number of high profile websites succumbing to a variety of password hacks. I’m not going to discuss password security here, although please, please don’t be a mug and  store them in plain text or just as a simple hash, even with a salt. If you were planning on doing that, read up on the issues first, especially on BCrypt or a similar solution before you go live – you owe it to your users.

Mass assignment is something which has often been the cause of security holes, but shouldn’t be. Best practice in Rails has been to use attr_accessible to declare mass assignable attributes, which works well, other than it puts the burden for authorization of which attributes are ok into the Model. This is a violation of MVC, where the Controller should be handling Authorization/Authentication. It also is limited, as different situations might require a different set of acceptable attributes for the same model. So, what can we do?

Enter strong_parameters – a gem which gives granular, situational control over acceptable attributes in the Controller. It is simple to use, and offers some great control at the cost of additional time and complexity when programming. Using it is a 3 step process:

gem 'strong_parameters'

class Page < ActiveRecord::Base
include ActiveModel::ForbiddenAttributesProtection
end

class PagesController < ApplicationController
....
private
def page_params
params.required(:page).permit(:title, :body)
end
end

Then you simply use page_params instead of params[:page] whenever you are using mass assignment. If you do this, you must remember to set whitelist_attributes = true in your config/application.rb otherwise you won’t have the inbuilt protection working, and you have to include ActiveModel::ForbiddenAttributesProtection in each model which automatically protects its attributes for you.

It takes a couple of seconds extra per controller, but is definitely worth it in my opinion, and allows you to define multiple methods for multiple situations – making the use of mass assignment secure, and versatile. Check the official Rails blog for more info.

Stronger, Safer, More Secure Rails Mass Assignment

There are few topics in programming more likely to cause dissent than the ideal way for beginners to learn a programming language¹ or even to program at all, and whilst I’ve read some great posts on the subject – I think many of them are missing the point. A lot of the posts I’ve read are 6 months old now, but little has changed to frame their arguments differently – I apologise for rehashing the subject, but I wanted to offer my own take.

Not for Beginners?

There seems to be a reasonably broad consensus that Rails is ‘not for beginners’, with comments from the very top of the ecosystem down (see @dhh tweet below).

@sryche Rails was never primarily about being friendly to beginners. We encourage improvement and for people to live up to the state-of-art.

— DHH (@dhh) November 30, 2011

An oversimplification of many of the arguments (presented more eloquently by Rob Yurkowski, some horse called Oscar, Richard Bucker, Michael Bleigh, and more) is that Rails’ complexity means that it is too difficult for beginners to learn, and even that the interest in Rails of beginners in some way might harm the project itself.

Having read most of the prominent posts on the subject, it strikes me that the people writing fall into a broadly similar camp – having some prior programming experience, encountered Rails in some previous incarnation of  the framework, feel that the ongoing changes to the codebase make it increasingly difficult for beginners to programming to learn how to get started, and/or feel that the community has become hostile and unhelpful to requests for assistance from beginners.

A beginner, what’s that again?

I think the most important thing to stress, and the point that gets lost by lumping all ‘beginners’ in together in some kind of Rails Programming Draft, is that there are many many different types of beginner, with many different goals. Rob Yurkowski touches on a couple of types – young and enthusiastic or refugee from PHP seeking redemption – but this only scratches the surface.

Dealing with difference creates complexity – this is a fundamental law of dealing with any system or network. Looking after Apache is simple, Apache + Passenger is quite simple, Apache + Passenger + MySQL is less simple, Apache + Passenger + MySQL + Memcached is less simple again. By the time you build up to a full application stack with reverse proxy caches, load balancers and the like – that ends up being a complex environment. In many cases, this is one of the main arguments against Rails for beginners – it is too complex, it has too many moving parts.

Certainly this can be an issue – if someone wants to learn Rails in order to put a one page static site on the Internet, then it is certain they have not understood why they might like to learn Rails, or indeed any web application framework. Within this kind of use subset, I certainly support the idea that Rails is not for beginners, but then again it is not for this kind of use either and thus is no co-incidence in the former being true as well. We, as programmers, only have ourselves to blame though for people believing that they need to learn more complex skills and frameworks for domain problems that are well and truly solved without them.

We need to stop being snobby

Much of the problem of these ill-advised beginners believing they need to explore Rails is in the general superior attitude and snobbery that we possess as a coding community. Possibly, it started with FrontPage and the identikit style that it produced. I’d feel smug if once again another problem could be placed at Redmond’s door², their condoning and encouraging a lack of flair and original thought in FrontPage directly leading into those that knew better looking down on the work it produced. Certainly though, I have lost count of the times that I have heard (and sometimes made) disparaging comments about using Dreamweaver without understanding a thing of how the underlying technologies work. The general feeling amongst ‘serious’ coders that if you aren’t developing with Emacs or Vim you aren’t really ‘getting it’³ is another, smaller scale example.

In the case of those people who really just need a small, static site and some encouragement, this snobbery is not helpful. Telling a man who needs a manual on how to saw wood he needs to be using the latest industrial scale automatic logging device would be ridiculous, and in most industries and walks of life there is a grudging respect for those who do things the hard way. I am sure that anyone cutting down a tree with nothing but sweat, wheatabix and an axe will get respect – not someone laughing at them for hand-coding CSS rather than writing SASS or LESS.

It is our responsibility as a community to encourage those who have no need of the complexity of going deeper, and are likely to suffer for doing so, that they can achieve what they want with simple tools. Learning Rails won’t suddenly make a website look any good, nor find visitors and pageviews. If people shouldn’t be beginners, we should ensure that they feel valued and proud of the level they need to be at.

The other fish in the Sea

Having ruled out those who shouldn’t be here, we get left with the rest. At this point, realism starts to bite as there are broadly three classes who remain – those that can’t, those that won’t and those that might. I’ll discuss each of these in turn.

Those that can’t

Unfortunately, not all of us are equal – it’d be lovely if we were, but it’s not true⁴. Some people are not born to be web application developers – either through ability or available time – and that’s ok – it doesn’t even mean they can’t come to the party. There are some fantastic tools such as SquareSpace which lower the boundary to having a reasonably custom web presence, and for some people this is the kind of developing that they should be doing – it’s enjoyable, productive, and can end up with phenomenal results. It takes a level of intellect to get to grips with the enormity of the task of building a web application – from choosing the underlying technologies (RDBMS vs NoSQL), live web technologies (Goliath, Faye, learn Node, or pay a company like Pusher?) to considering caching patterns to ensure responsiveness for users – there is a lot you need to know, regardless of which language you choose, and unfortunately you need to understand it too. Using a tool, like SquareSpace or iWeb shouldn’t be derided – they are viable options for many many people who want to be part of the Internet, but don’t have either the intellect, or even the time to get to grips with the technologies needed to code your own. Here, yeah – Rails is not for these beginners, but no Framework is – the responsible approach is to guide them into a more suitable channel.

Those that won’t

Some people have enough intellect, have enough time, and even have enough inclination to learn how to use Rails – normally with some dream of writing a new social networking site that will make them rich. And that’s where it stops with these beginners for Rails as they will never learn – they aren’t trying to learn to use Rails, they are trying to reach some end result without caring how they get there. These beginners are the problem ones, and the ones that really most of the people who say that Rails isn’t for beginners are seeing and railing⁵ against. Nobody who builds houses only knows which bits go where – no brickie can only tell you which shape brick he will use. To become accomplished in a trade or skill, you have to have a desire to understand “why” rather than “what”, and fixating on the “what” with Rails will bite you in the arse very quickly.

There are thousands of Stack Overflow posts, or Rails forum posts, or IRC messages that just want solutions to relatively basic Rails problems, without the posters wanting to take the time to understand why they are in trouble. Ultimately, I could categorise those that won’t very simply – do they google for their problem before asking for help? If they don’t then yeah, sure,  Rails isn’t for them.

Those that might

Here, this is the crux of it though – those that might. People with enough intellect, time, energy and a desire to learn. For those beginners, who genuinely want to master a new technology, then it is imperative that they are encouraged to adopt the best techniques and most cutting-edge practices; this industry moves too fast not to. This is where Rails, more than any other framework, is the right choice for beginners – by being, to quote @DHH again:

@sryche Rails was never primarily about being friendly to beginners. We encourage improvement and for people to live up to the state-of-art.

— DHH (@dhh) November 30, 2011

Rails sets itself as the gold medal target for learning – learn Rails, and you’ll be ahead of 95%⁶ of developers in your outlook, and preparedness for the approaching trends of the Internet. I came to Ruby web development from PHP, and when flicking back every now and then I am amazed by how backward it seems. I don’t want to TROLL the PHP community – it’s a very capable language, and achieves lots of good things, but it hasn’t moved with the times, probably through its fragmentation into the 35million different frameworks on offer. Things such as the asset pipeline have no match in PHP-land, or even in the rest of Ruby web development, but they are the future – for example consolidated, efficient asset handling promotes quality, robust front-end code.

If you are going to learn, learn the best – as anything else is a false economy, and a waste of your time.

It will be hard

Don’t get me wrong – I agree with many people who say that Rails is very hard for a beginner to learn and understand. In fact I gave up learning it, the very first time I tried (back in early 1.x), due to it not making much sense coming from spaghetticode PHP. I can totally agree with people saying that the newest functions and features further increase the learning curve too. Well, what do beginners expect? It to be a walk in the park? With a decent grounding in Ruby, such as following Why’s guide, and blitzing through the Ruby Koans, you could expect to be in a position to grapple with Rails as a complete beginner to Ruby web development. Yes, Sinatra possibly might seem more approachable and easier to “learn”, but what do you really learn by doing this?

require 'rubygems'
require 'sinatra'

get '/' do
"#{Time.now}"
end

And then running ruby yourfile.rb? Yes, it is essentially a dynamic web application, yes it is awesomely simple – but learning how to make Sinatra run a blog application with several resources (Posts, Categories, Tags, Authors, etc) and an Admin area – that’s really rather harder – in fact it’s a lot harder to write a Sinatra CRUD application and tie it all together than it is to learn how to do the same in Rails.

Maybe it’s not all that hard

A lot of this comes down to snobbery again – ‘scaffolding is evil’ is a normal refrain amongst experienced developers, and in many ways it can be, and certainly can lead to bad habits, but really – for a beginner – is it?

rails g scaffold post title byline body:text gets you an awfully long way, and more importantly writes some decent code to learn from as a beginner – what better way to learn how to respond to request types than to actually see a respond_to block? Yes, ultimately hand crafting controllers and models is preferable, but when talking about beginners, it’s really important to remember that there can be steps to wisdom.

Finally

Ultimately, the question of whether Rails is for beginners or not comes down to this: do we want new developers pushing old techniques and slowing the adoption of new practices, or do we want the next developers to believe in best practices and are agents for change? Rails may have reached widespread adoption and acceptance, but it still disrupts. Surely we need to encourage beginners to buy in to this, not the old ways?

Actually, it turns out I was wrong – @dhh is actually explaining why Rails is the only choice for beginners when he said Rails sets out to “encourage improvement and for people to live up to the state-of-art”. After all, these should be the only criteria when choosing an ideal framework for beginners.

Rails is definitely FOR beginners, whatever @DHH says

I was just browsing the Ruby Koans project, considering whether to recommend it to a friend who ia interested in learning to how to programme, and two things struck me. Firstly – it’s a fantastic way for beginners to learn some of the inner workings of the language – check it out if you haven’t already. Secondly, it’s a brilliant reminder of how pure and deep the Object Oriented nature of Ruby is. I’ve been writing some PHP code recently, and the PHP adoption of OO principles has improved a lot of late, but it still feels like a sticking plaster over a broken leg – some visual cues of attention and improvement, but can’t really walk on it. Coming back to Ruby, even simple Ruby like this, is always a delight and a joy.

I wish that more programmers would give it a go – both Object Oriented code in general, and Ruby in particular – it is such an enlightening experience. I started out nearly a decade ago by weaving bits of SpaghettiCode PHP and attempting to make it continue to comply to my will as the programmes got larger and larger. I think that my development and learning curve was significantly slowed due to the frustration of attempting to manage these monsters. It took quite some time (and cursing at CodeIgniter), before I was prepared to start buying into the advantages of OO code. I think every smart developer has a certain tendency to rail against the machine – feeling that they don’t need the help and can do it just fine, until they discover writing Object Oriented code actually makes you better, rather than holding you back. I’ve read some interesting posts recent on why Rails isn’t for beginners, and I couldn’t disagree more, but I’ll save that for another post and leave you with this sample from the Ruby Koans project, which got me started thinking about this:

class AboutObjects < EdgeCase::Koan
def test_everything_is_an_object
assert_equal true, 1.is_a?(Object)
assert_equal true, 1.5.is_a?(Object)
assert_equal true, "string".is_a?(Object)
assert_equal true, nil.is_a?(Object)
assert_equal true, Object.is_a?(Object)
end
end

You know a language is Object Oriented when…

1. Introduction
2. Getting Started
3. Building Features
4. Making it work

Introduction

At some point in every Ruby developer’s career there comes a stage where there is a need to reuse code on a large scale. Certainly using a good snippet system in your code editor can go a long way – inserting bits here and there. After 3, 5, 10 projects this becomes a nightmare to maintain – remembering which ones you haven’t updated¹. The best way to recycle code is to make a ruby gem, and then include it in your applications in your

Gemfile

It is amazingly easy to get started building a gem, and there are many reasons apart from code management why you might like to do so. Arguably the biggest reason for this is that doing so, and opening your gem up through github (or one of the other options such as bitbucket or beanstalk) brings the possibility of collaboration with others. This can lead to contributions to your code, helping people ‘scratch an itch’, and possibly your small piece of code could develop into a major tool for the whole Ruby community. Every great project starts somewhere, so, interested? Let’s begin.

Getting Started

There are a few tools you can use to ease the creation and maintenance of a gem, but inarguably² the best choice is to use Bundler. Bundler does so many things more than just running

bundle install

• Ruby installed (obviously), and right now there shouldn’t be any reason not to be running on 1.9.3 if you are on MRI ruby – it’s battle ready, and massively speeds up development.
• Bundler installed. This happens by default if you use RVM to manage your Rubies, or just run gem install bundler if it isn’t there already.
• Somewhere to put the gem – I use

  ~/ruby/gems/GEMNAME

  to store my gems, so if want to create a new directory, do so now.

Ok, now we’ve got everything ready, we can start building a gem. you’re going to need a cool, catchy, original name for you gem, one that has a certain air of distinction, that sounds superior. It is worth reading this article for more information on this. So we are going to use the fantastic name “dostuff” for this article – obviously you’ll need to choose your own and use that instead! Creating a gem with Bundler will create the new gem in a directory of the same name as you’ll choose for the gem, so if you get into the folder you want to create the gem inside, we’ll begin.

~/ruby/gems$ bundle gem dostuff && cd dostuff
~/ruby/gems/dostuff$ tree
.
├── dostuff.gemspec
├── Gemfile
├── lib
│   ├── dostuff
│   │   └── version.rb
│   └── dostuff.rb
├── LICENSE
├── Rakefile
└── README.md

If you don’t have

tree

bundle gem xxx

• Generates the basic file structure for the gem
• Creates an empty git repository in the gem directory
• Writes an initial gemspec file
• Sets up some brilliantly useful rake tasks (“rake release” is bliss, but more on that later)

The most important file that has been created for us is the dostuff.gemspec file, which holds all of the configuration information for the gem. We can see what initial setup we’ve been given by Bundler:

~/ruby/gems/dostuff$ cat dostuff.gemspec
# -*- encoding: utf-8 -*-
require File.expand_path('../lib/dostuff/version', __FILE__)

Gem::Specification.new do |gem|
	gem.authors = ["JGW Maxwell"]
	gem.email = ["jgwmaxwell@gmail.com"]
	gem.description = %q{TODO: Write a gem description}
	gem.summary = %q{TODO: Write a gem summary}
	gem.homepage = ""

	gem.files = `git ls-files`.split($)
	gem.executables = gem.files.grep(%r{^bin/}).map{ |f| File.basename(f) }
	gem.test_files = gem.files.grep(%r{^(test|spec|features)/})
	gem.name = "dostuff"
	gem.require_paths = ["lib"]
	gem.version = Dostuff::VERSION
end

This configuration file contains the information required by Rubygems and Bundler to make your gem work, and to attribute ownership and authorship. One of the benefits of using Bundler to manage and create the gem is that it comes with a great set of defaults that do make building the gem much simpler, but there are some caveats. The biggest of which is actually a git issue, but remember that if you delete a file which has been previously committed to the repo, you have to git rm FILENAME to get rid of the file from the repo as well. This is because the gem knows which files it includes by running a git ls-files in this line:

gem.files = `git ls-files`.split($)

Ok so, we have the skeleton of the gem, now we need to configure it and make it do things. You are welcome to follow the basic code below, to end up with a gem that does nothing of any use whatsoever, or add some of your own code instead.

Building features

So, for the purpose of this guide, we are going to give the gem a function that translates any string to Pirate speak (“Arrrrrr”). There is a basic web API for Pirate speak online at http://isithackday.com/arrpi.php. The API takes a string and returns a Pirate speak string, so it seems ideal that we should mixin this functionality to Ruby’s String class so we can just call

#to_pirate

To add features, the basic hierarchy is that the gemspec adds the lib/ directory to the require path, and when you require the gem, it will pick up the file in that directory named after the gem – in my case dostuff.rb. In most gems, these base level files serve as little more than vessels for requiring other functionality, stored deeper within the gem. So, we will add a new file to hold the function that we need, making the structure look like this:

lib
├── dostuff
│   ├── pirate.rb
│   └── version.rb
└── dostuff.rb

In pirate.rb we will add the functionality for translating strings to Pirate  speak. This only needs to be a single method:

require 'net/http'
require 'uri'

module Dostuff
	module Pirate
		def to_pirate
			uri = URI.parse("http://isithackday.com/arrpi.php?text="+URI.escape(self))
			return Net::HTTP.get_print(uri)
		end
	end
end

This is dead simple, just a

#to_pirate

URI#parse

So, we can test this now by firing up an IRB session and checking on our process. Instead of just running irb, we are going to use Bundler to fire up the console – this makes it easier to check the functionality within our gem. So, from a command line in the root of your gem folder, run the following commands:

~/ruby/gems/dostuff$ bundle console
1.9.3p194 :001 > String.class_eval("include Dostuff::Pirate")
=> String
1.9.3p194 :002 > "yes, this is indeed pirate talk".to_pirate
yarr, this be indeed pirate talk => nil

Making it work

Ok, so we have a working way of talking to Pirates, but what happened in that first line of code? String.class_eval("include Dostuff::Pirate") This is a simple way of including functionality within another class that we don’t have direct access to – obviously we don’t want to open up the entire of the Ruby codebase just to add an include statement. The way around this is metaprogramming, code programmatically changing the functionality of other code to achieve a desired effect. Ruby is arguably the ultimate metaprogramming language, classes never are closed, multiple ways of including, extending and requiring things, but that is beyond the scope of this article.

Obviously we don’t want to have to issue that

#class_eval

lib/dostuff.rb

require "dostuff/version"
require "dostuff/pirate"
module Dostuff
  # Public: Includes Dostuff::Pirate into String to enable String#to_pirate
  String.class_eval("include Dostuff::Pirate")
end

Because the this file is parsed whenever the gem is required anywhere, the same metaprogramming technique we used just before works beautifully here again. If you want to check it, you can fire up an IRB session again:

~/ruby/gems/dostuff$ bundle console
1.9.3p194 :001 > "hello my friend".to_pirate
ahoy my mate => nil

Success! The final thing to do is to bundle it up as a gem and release it so it is easy to use in future. At this point it is important to remind people that if you follow the next steps, your code will be out in public, and anybody could install it. If you need to keep code private, only follow the first part of this.

Firstly, we need to top our git repo up with the latest code. Doing so (if you aren’t familiar with git) is as simple as doing

~/ruby/gems/dostuff$ git add .
~/ruby/gems/dostuff$ git commit -m "initial commit - make String talk #to_pirate"
[master (root-commit) 2f48a37] initial commit - make String talk #to_pirate
 9 files changed, 111 insertions(+), 0 deletions(-)
 create mode 100644 .gitignore
 create mode 100644 Gemfile
 create mode 100644 LICENSE
 create mode 100644 README.md
 create mode 100644 Rakefile
 create mode 100644 dostuff.gemspec
 create mode 100644 lib/dostuff.rb
 create mode 100644 lib/dostuff/pirate.rb
 create mode 100644 lib/dostuff/version.rb

Then, you can just run

rake install

~/ruby/gems/dostuff$ rake install
rake aborted!
ERROR:  While executing gem ... (Gem::InvalidSpecificationException)
    "FIXME" or "TODO" is not a description

Tasks: TOP => install
(See full trace by running task with --trace)

Then fortunately there is a really helpful explanation – telling us that we haven’t updated the

dostuff.gemspec

git add . && git commit -m "I made a silly"

rake install

~/ruby/gems/dostuff$ rake install
dostuff 0.0.1 built to pkg/dostuff-0.0.1.gem
dostuff (0.0.1) installed

Perfect, we can now use this gem in all kinds of different applications – wherever you want something to talk like a Pirate really! You can check this by trying a normal IRB session:

~/ruby/gems/dostuff$ irb
1.9.3p194 :001 > "hello my friend".to_pirate
NoMethodError: undefined method `to_pirate' for "hello my friend":String
...
1.9.3p194 :002 > require 'dostuff'
 => true 
1.9.3p194 :003 > "hello my friend".to_pirate
ahoy my mate => nil

Entering the Gemsphere (or publishing it on Rubygems if you want to be prosaic)

Ok, so if you don’t want your code to be “out there”, then you need to stop following now – congratulations, you’ve got a working gem! For those who want to be part of the community, take your next steps now…

You’re going to need two (free) accounts to finish the rest of this. One is for a public, web accessable git repository (such as github, others exist) to host the source code, the second is an account at Rubygems.org which will actually host the gem itself and make it available through

gem install dostuff

Signing up for Github is easy, free if you don’t want any private repos to keep your code from prying eyes, and almost certainly a good thing to do for any developer. Head to github.com/signup/free to get an account, and then follow their instructions here to get your computer setup with SSH keys properly – it will make your life a lot easier in the long run than trying to use HTTPS connections with git. At this point in time you need to create a new git repo on github, I’d strongly advise calling it the name of your gem. Once that is set up, you can follow the instructions on the new repository page that github provides, which for us essentially boils down to running

git remote add origin git@github.com:YOURUSERNAME/GEMNAME.git

git push origin master

Next step is to make sure you are registered at Rubygems.org, and then login on your local machine by running

gem push

This is, I always feel, a great anticlimax as part of the process of developing gems. There should be more pomp and circumstance involved in publishing a gem than simply issuing a two word command, but I suppose we can leave that for Java programmers and get on with being Rubyists. To send your gem out to the world, just run

rake release

gem uninstall dostuff

gem install dostuff

Congratulations, you’ve just launched your first gem. One slight gotcha to avoid though – if you want to tweak the features, you’ll need to run

git add . && git commit -m "a message" && rake release

lib/dostuff/version.rb

There’ll be another post in this series soon looking at building a much more advanced gem, but I hope this gets you started nicely. Before I finish that though, you could have a think about tasks that need doing. Writing documentation – both inside the code for rdoc or ri and in the README file is essential for any Gem or coding project, this would be a good next step.

Make a Ruby Gem and enter the Gemsphere

Sextant

I noticed Sextant first on the Changelog a couple of weeks back, and thought it might be useful – a gem to give you your routes in the browser. After all, waiting for Rake to fire up Rails just to spew out its routes is painful. Then it gets doubly painful when you realise that your tiny shell window has mangled the text into an unreadable state (yes, even with 2×24″ screens you still never have enough screen area), so you resize, fire rake routes off again, wait… etc – it is one of the things I hate most about developing in Rails.

Instead, you can use Sextant – it gives you a simple display of all your Rails routes (just like running rake routes) in the web browser, instantly (or as fast as your Puma can carry you). In large applications this can offer a ridiculous performance increase for developers, as it can take a huge amount of time for Rails to initialise all of the required classes (4+ minutes on MRI 1.9.3p194 for one of my Applications).

If someone would adapt a similar approach for Rails generators that would be truly fantastic, as again running rails g takes a lot of time in a big application. Maybe this could all be bundled together behind a nice Sinatra front end for development mode? If anyone beats me to writing that then please let me know, I’d love to use it!

Anyway, I’m sure you are wondering how to use this gem. Turns out it is deeply complicated, using one whole line of code to achieve. In your Gemfile (preferably in a :development group, as below – you don’t want this out there live in production!) just add

gem 'sextant'

and run bundle install to get it all sorted. Reboot your server and go to /rails/routes to see all your roots laid out.

Hats off to Richard Schneeman for a great gem, and if anyone knows of any other similarly useful tools then let me know.

Puma

I tested Puma as part of a large benchmark of different Ruby application servers a few months ago, and was underwhelmed with the results back then. It seemed like it had a lot of potential, but was wildly inconsistent about when it showed. That was 0.9.8, but things have changed, the version is now 1.3.1 and the story has been rewritten.

There are some massive claims made on the Puma website and I’m not going to attempt to verify their benchmarks now (although there’s going to be news on that front soon), but given the calibre of people behind the project it is only going to be a matter of time until they have it smoking fast. Even from last time, the difference is noticeable and immediate, even in development mode on Rails 3.2.x – everything just feels a little snappier than it did under Unicorn. Probably most importantly though is the memory overhead they are advertising – it’s astonishingly low. On the app I’m developing at the moment it’s consistently 30meg less than Thin, which if you are running on a service like Heroku is really useful (as each dyno¹ is capped to 512mb).

I’d encourage anyone and everyone to give Puma a good shot at the moment – it works well on MRI 1.9.3, but it’s really designed for Rubinius or JRuby – as then it can utilise its strong support for concurrency to much better effect². Using it is as simple as whacking gem ‘puma’ in the Gemfile, and then running

$ puma

on the command line to fire up Rails/Sinatra/whatever-rack-based-framework-you-fancy.

Sextant shows Rails Routes in browser, and Puma gets a snarly performance upgrade

Grape::API¹ is an awesome tool for building APIs in Ruby – it’s quick ² and has a nice DSL with some lovely features. One major issue with it comes whilst developing the application – there is no built in reloading of classes, and whilst there are a couple of threads about implementing reloading³, there’s no progress as yet.

Fortunately, Grape is Rack-based, which allows us to use Shotgun⁴ as a development server, which handles reloading for us. Simply add a

group :development do
gem 'shotgun'
end

to your Gemfile to give yourself a copy of Shotgun in development mode, run

$ bundle install

and then you’ll be able to start your app by running

$ shotgun

Visit http://localhost:9393/[your path here], make some changes and refresh to see your changes working, and a major headache gone!

Reloading Grape::API applications in development

Well, after a couple of months away from writing, I’ve managed to find time to start again. Since the last post, a huge amount has gone on – both in terms of consulting and with my own Startup, and I’ll be sharing many of the lessons I’ve learned over that period of time. Additionally, it was long past time to abandon Tumblr as a hosting platform and move to something a little more serious, with a proper webhost. So, This is now running on WordPress – a platform I have been critical of in the past, but increasingly impressed by as a blogging engine of late.

The Tumblr to WordPress migration is particularly simple, making me wonder why I didn’t do it a long time ago, although the import tool could be better at allocating posts to categories, and it could import pages as well, but I can’t complain too much.

Cloudflare are still providing the distribution for the site, but now it’s running on MediaLayer’s servers (not an affiliate link!). I have to say I’ve been blown away by their customer support so far, as well as the responsiveness of their platform. I’d thoroughly recommend them from my dealings with them so far.

I wish that WordPress would break the bond to MySQL and look at using MongoDB instead – blogging a natural candidate for document databases, and the idea of only having to hit a couple of queries instead of the 50+ that WordPress can need must be worth it. Admittedly, WordPress isn’t as dreadful as Magento, but that is another story for another time…

Anyway, I’m looking forward to sharing some useful code with you all, but for now, so long.

Leaving Tumblr, Writing Again