flow

Ruby 1.8 and 1.9 living in harmony

jk@handle.it (Jason King) — Sat, 20 Feb 2010 15:14:00 GMT

I’m running on OSX, and using MacPorts for all my un-Apple needs. So, no, getting Ruby 1.9 installed was not complex at all, the suffix is the default in MacPorts, so I just ended up with a ruby1.9 executable.

The kicker comes because Rails, and all its little generator friends, do one of two things. Either they are just hardcoded to use #!/usr/bin/env ruby or they set that line to whatever version of Ruby you happen to be using when you install/generate/make them the first time, which will be either what I’ve just written or #!/usr/bin/env ruby1.9 or (like rails) an actual hard coded path to your MacPorts ruby executable.

Ok, not really a big problem there, until you want to test your application, generator, plugin, gem, whatever against the other ruby on your system. What do you do? Go through and make sure you change all the relevant shebangs? Works fine until you miss one. You’re really testing your sed fu, not your Ruby fu.

And then what happens when, like me, you’re just so used to typing irb or ri that you’re constantly tripping over the “Oh, yeah, that’s over in the 1.9 stuff.” problem?

Well, then you know it’s time to roll out your bash fu. Ewk!

I rolled up these bash functions to switch my MacPorts installation from 1.8 to 1.9 by taking all the binaries that are part of the ruby macports install and moving them to suffixed files, and then symlinking the bare names to either 1.8 or 1.9 (which IMHO should always be how languages are installed).

So, dependencies? It depends on you having macports - it uses that to get the list of files that have been added to the relevant bin directory. You could replace that in the for loop with something else to give you those filenames.

That’s it.

Hmm, or it would be it if I said: run r18 to switch to Ruby 1.8 and run r19 to switch to Ruby 1.9. Also - warning - this runs sudo, so understand what you’re running before typing in your password.

jquery in Rails3

jk@handle.it (Jason King) — Tue, 09 Feb 2010 01:09:00 GMT

There are two things you want to sort out in Rails3 to get jquery humming along really nicely.

Firstly is the UJS. Rails3 has done great things in replacing all the inline JS with UJS and nice semantic XHTML - but, of course, they ship with the Prototype version of this UJS file.

You’ll want to just overwrite the public/javascripts/rails.js file in your project with the jquery version from github.

So the next step would be to add the javascript_include_tag to all your layouts, and if you’re a jquery fan then you’re probably used to something like this:

javascript_include_tag 'jquery', 'jquery-ui', 'rails', 'application'

At best, if you have only one layout, that’s ugly. When you begin to get more than one layout, you’re un-DRY, or you’re writing your own helper to wrap that up. It just gets uglier. Especially when compared to the Prototype equivalent:

javascript_include_tag :defaults

How do we get this logical grouping of JS files?

Well, I might just be the last one at the party here, but I couldn’t find anything online, or anything obvious in the help, for how to DRY this up. A quick dig in the source revealed the answer though. Somewhere in your init files (in Rails3 I have this in config/application.rb - but this will work in previous versions of Rails too) you can register what’s called an expansion, like so:

ActionView::Helpers::AssetTagHelper.register_javascript_expansion \
  :jquery => %w/jquery jquery-ui rails application/

So then in your layouts you can use that expansion like so:

javascript_include_tag :jquery

Much nicer, and very simple to update in a central config location, should you wish.

git really is better than svn

jk@handle.it (Jason King) — Tue, 26 Jan 2010 01:33:00 GMT

For many months when git (or really when github) first arrived on the scene I heard nothing else from all the fanboys than how great git was, how crap svn was, and that everyone who was anyone was using git now. That sort of zealous response to new software or services always gives me pause.

Inevitably, I’d ask one of the fanboys why they recommended git over svn, and usually they would come up with one of two standard “reasons”

Git handled branching much better than svn
Git was distributed and therefore cool

I had rejected the first immediately - if you’re familiar with svn, have a shell script or two to wrap up the repetitive task of retrieving the full URL from svn status, know about svn switch !!:$ and especially if you had svn 1.6 with branch tracking, then really svn is very good at branching too.

I had rejected the second for any situation where this wasn’t important - like 99% of corporate situations where you have your own svn server sitting on a 100mb/s LAN.

Unfortunately, no one ever mentioned the real advantages of git over svn.

Time to try git

I began a new role in San Diego, and we have some developers in Tijuana who have a very sketchy internet connection that can be down for many hours at a time. Sounded to me like one of the 1% of times when having a distributed SCM might prove useful. So in I dove.

The real advantages of git over svn

The fanboys would have had me totally sold had they mentioned these things.

1. You can split during commit

This sequence of events happens so often that it’s really nice to have it supported as a first class citizen in your SCM. You begin working on an issue, let’s call it “password recovery” and as you’re working you notice some hard coded URLs in some template files and you fix those, and you notice some poorly named variables and you fix those, and you notice some debug code and you remove that, and you finish your work only to realize that you now have a working directory that contains more than one logical unit of work.

git add --patch .

Tadaa - you can now use an interactive mechanism to stage your commit, picking the files or even changed lines within files that are specific to each logical unit of work. Then commit that, with an appropriate comment and move on to the next commit in the same way. So in our example we can pick and choose which files, and lines within files, that we want as part of our “password recovery” commit, commit that, then pick and choose the variable naming fixes, commit those, etc..

We end up with a useful history with change-specific commits. This alone would have sold me on git.

2. You amend/edit a previous commit

You’re adding the “password recovery” feature, editing away, and you make your commit. Then you notice a new file that you forgot to add in. No svnadmin required, no dirty history, instead you just stage the file ready for commit, and then amend the previous commit:

git commit --amend

You get the opportunity to edit the comment if you need to, and a totally new history is created in your repository.

One of the advantages of having a distributed system is that if you’ve not pushed that commit to any other developers yet, then you can fix your own repository up without adversely affecting anyone else.

3. You can undo previous commits

The --amend option is really just a convenient layer around the ability to fully reverse our a previous commit. You can do this yourself with:

git reset HEAD^

This will reset your repository to how it was one before the HEAD (that’s what the ^ means). Your files in your working directory will remain untouched, it just changes the repository so that it no longer has the commit recorded. You can then re-edit, reorganize, whatever you want before committing what you actually wanted in your repository.

Many more

There are many more very nice things that you can do with git.

Some are simple things, like that creating a new repository is very cheap and quick, so you end up doing it for things that you wouldn’t necessarily bother with for svn. It’s also done in place by default, as opposed to svn where you have to do the checkout/add trick to make a repository in place.

Some are quite complex things, like bisect is an incredible tool for easily tracking down which version a bug was introduced in. You could do it with svn too, but it ships with git - ready to go.

It’s definitely worth a try whenever you can justify it :)

Simpler test output with turn

jk@handle.it (Jason King) — Tue, 26 May 2009 05:09:00 GMT

This is a small thing, but sometimes those small things can really make a huge difference. This is one of those.

As your suite of tests grow, especially in those large applications, you often end up with an error output that looks something like this:

..........F..............F.....E....FFF...F..........

And then following that is a huge list of error details. Scrolling through that is a pain, and even with redgreen active your visual cues are at a minimum when looking through that output.

Thankfully this also annoyed Tim Pease who came up with a very pleasant alternative called turn. You can install it as a gem, and then just add:

require 'turn'

Into your test helper and you’ll see much simpler and comprehensible output from your test output.

A few more things in the Rails console

jk@handle.it (Jason King) — Sat, 02 May 2009 04:01:00 GMT

Almost immediately after posting my last post on the Rails console a few more things came to mind. It has taken me this long to blog again :)

Let’s pick up from where we left off in the previous post with…

Thing 6: reload!

I can’t believe I forgot this one in the first post, this is one of the most useful methods in the console. The reload! method reloads your Rails application, so after you make change to your app you just run reload! to pick up your new changes. No more restarting your console and losing all your history. Simple, but really effective.

Thing 7: the –debugger option

Prerequisite for this to work, as with all ruby debugging, is to have the ruby-debug gem installed, so before we begin:

$ sudo gem install ruby-debug

Then, when you start your console with the --debugger option (which you can shorten to -d) you get your Rails console run under the debugger:

$ console -d
=> Debugger enabled
Loading development environment (Rails 2.3.2)
>>

So, what does this mean? Well, now you have the debugger available, so let’s make a very simple model:

app/models/foo.rb

class Foo < ActiveRecord::Base
  def foo(foo)
    puts foo.upcase
  end
end

So now in our console we want to stick a breakpoint into that model, we can either edit the app/models/foo.rb file and put in a call to the debugger method, or more simply we can just call the debugger method in the console and put in the breakpoint there:

>> debugger
/opt/local/lib/ruby/1.8/irb/context.rb:163
@last_value = value
(rdb:1) b Foo#foo
Breakpoint 1 at Foo::foo
(rdb:1) c
=> 1
>>

Only weird thing here to note is that when we call debugger we actually cause rdebug to break in the middle of the irb code. This also happens, as you’ll see below, as we step through code - when we come out of our own code, we end up debugging the console/irb code itself. Just something to be aware of and not get freaked out at.

So, now that we have that breakpoint set, let’s run some code:

>> Foo.new.foo('bar')
Breakpoint 1 at Foo:foo
.../app/models/foo.rb:2
def foo(foo)
(rdb:1) l
[-3, 6] in .../app/models/foo.rb
   1  class Foo < ActiveRecord::Base
=> 2    def foo(foo)
   3      puts foo.upcase
   4    end
   5  end
(rdb:1) n
.../app/models/foo.rb:3
puts foo.upcase
(rdb:1) pp foo
"bar"
(rdb:1) n
BAR
/opt/local/lib/ruby/1.8/irb/context.rb:163
@last_value = value
(rdb:1) c
=> nil
>>

So, here we instantiate a Foo object and send the foo method to it with the "bar" argument. You can see that our breakpoint is hit and we’re prompted with the (rdb:1) prompt. I issue the l command (short for list) to see where I am in the code, and then the n (short for next) to step over the next statement. I’m able to pp the foo parameter to see its value, and then I n again and we see the output of that puts call.

Then, as I mentioned previously, we exit our own code, but the debugger doesn’t exit. As you can see we end up on line 163 of irb/context.rb - you’ll get used to seeing this, it means that we’re back out of our code. So I just enter the c command (short for continue) and the code continues to run and returns me back to my console prompt.

Ok, fairly simple. That breakpoint will stay in the debugger until we explicitly delete it (or restart our console session). On to the next thing…

Thing 8: helper method

There are plenty of times when you’re seeing something unexpected in your browser and want to use your console to work out what’s going on. Sometimes you want to take a look at the output of a view helper, because something’s just not fitting.

Enter the helper method. This is built-in to your console session. You won’t be able to call any helper that needs to make a URL like form_for, but you still have a lot available to you. As a simple, and trivial example:

>> helper.number_to_currency( 45.234445 )
=> "$45.23"

You can get a little fancier by setting instance variables in the helper instance, like so (I’ve added a name field to my Foo model/table):

>> helper.instance_variable_set( :@foo, Foo.new( :name => 'foo bar' ) )
=> #<Foo id: nil, name: "foo bar", created_at: nil, updated_at: nil>
>> helper.text_field :foo, :name
=> "<input id=\"foo_name\" name=\"foo[name]\" size=\"30\" type=\"text\" value=\"foo bar\" />"
>> puts _
<input id="foo_name" name="foo[name]" size="30" type="text" value="foo bar" />
=> nil
>>

Very nice, yes, I like :) Next thing…

Thing 9: readline support ^R

On systems that have readline the console session will have readline support rolled in. There are many things which this brings you, emacs editing of your lines, configuration through your ~/.inputrc file, all the juicy goodness. One thing which is generally always available in all readline distributions is the ^R mapping to the readline macro history-search-backward which means that you can hit ^R (Control+R) and start typing any part of a previous (within that console session) line and readline will search backwards through your history and present you with the options.

It’s hard to demonstrate this without being live, so really - just try this yourself. Run some commands, and then hit Ctrl+R and start typing part of one of those previous commands, you’ll see what readline magic is :)

Thing 10: adjust your $PATH

Finally, a really tiny one. Not sure how this applies to Windows because I’m not sure what Windows has in its RAILS_ROOT/script directory.

You see, time and again, people doing this:

$ ruby script/console

And in fact, the same for generators and other scripts:

$ ruby script/generator model Foo name:string

Unless you have a very broken Ruby or Rails installation, then on any shebang system you can drop the ruby - everything in your script/directory will be executable, and so it can be run directly. But then, for the truly lazy (like me) why not go one step further and add ./script to your PATH so that when you’re in your RAILS_ROOT directory you can just type the command directly.

$ echo 'export PATH=./script:$PATH' >> ~/.bashrc
$ source ~/.bashrc

So, now you are all set to run those script/* scripts directly:

$ console -d
...
$ generate model Foo name:string
...

Etc..

I hope those make your life a lot simpler. I’ll settle for just a little simpler. Have fun.

When REST doesn't fit

jk@handle.it (Jason King) — Wed, 29 Apr 2009 06:39:00 GMT

So, those of you that know me know that I’m no REST zealot. I think there are many times when it’s better to use a non-REST controller. Simplicity of URLs, succinctness of controller, etc..

One example that I’ve just come across is a questionnaire which doesn’t really map to REST. For a start I never want to expose this controller via an API, the process flow also doesn’t follow REST at all, sure I want a new questionnaire completed, but that’s it. I don’t want to be able to show, edit/update or delete.

I also want some nice and simple URLs, so I don’t want /questionnaire/new for a new questionnaire, I just want something very simple like /q. And then I want a thank-you page at the end of the questionnaire, with a message about the email confirmation that I’ve sent to the participant. Nothing here sounds RESTy, and I’d encourage you to just depart from REST when this happens - don’t feel locked in.

So, the controller will be familiar, and I’m not really interested in repeating here what I’ve done there. It will be very similar to other RESTful controllers, bar a few bits. What I *am* interested in demonstrating here is what to do in your routes.

Routes, more than controllers, are where a lot of REST magic is rolled up into some very concise helpers. So, when we move away from REST how do we make our routes nice and simple, concise, and DRY?

Well, let me just spill the beans on what I have for my questionnaire:

map.with_options :controller => 'q' do |c|
  c.with_options :conditions => { :method => :get } do |cget|
    cget.q 'q'
    cget.q_thanks 'q/thanks', :action => 'thanks'
  end
  c.with_options :conditions => { :method => :post } do |cpost|
    cpost.connect 'q', :action => 'create'
  end
end

Isn’t that with_options a nice little tool. So what are we doing here?

Well, we want all our routes to be for our new Q controller, so we open up a block with the :controller => 'q' options sending that to the map receiver. Seriously cool.

So then within that enclosing block we have our GET and POST URLs separated. So we have two GET URLs defined (both as named routes), one for the (implicit) index action with the q helper, and one for the thanks action with the q_thanks helper. Then we have a single POST URLs defined for the creation which we have named q_create. So now, what does our form look like?

<% form_for @questionnaire, :url => q_path do |f| %>

Very neat and tidy, we just use our q helper and we know that forms will have POST action, which will mean it will be routed to our create action. Then in our create action in our controller the successful response will be something like this:

flash[:success] = 'Questionnaire was successfully created.'
format.html { redirect_to( q_thanks_path ) }

Which is good enough for me.

Column sorting with good_sort

jk@handle.it (Jason King) — Fri, 03 Apr 2009 11:17:00 GMT

I spent a little time this week pulling sorting out of a project of mine as a gem. I’m really happy with where I got to with it.

What this is is something that lets you very easily add column sorting to your data views so that visitors can click on the column headings to re-present the data sorted by that heading.

There are two parts to this gem:

The Model

You get the declarative sort_on method for your model so you can stipulate in your model which attributes are allowed to be sorted on. This means that sorting is always a positive assertion, so (for example) you can choose to select only those attributes that map to columns in your DB that you have indexes for.

If sorting is attempted for any other columns, then an exception is thrown.

You also get the class method sort_by which takes a parameter (string or symbol) that has to be one of the attributes declared in that model’s sort_on and returns a hash suitable for merging into parameters for an ActiveRecord find.

The View

You also get a helper for outputting the headers in the view called sort_headers_for which makes it really easy to output all the gracefully degrading AJAX-enabled headers/links for sorting your list.

Let’s Have a Look

I’ve pretty much just chomped this out of the gem’s README, but it’s a decent example:

app/models/author.rb

sort_on :name, :updated_at

app/controllers/site_controller.rb

def index
  @authors = Author.all( Author.sort_by(params[:sort]) )

  if request.xhr?
    return render :partial => 'authors'
  end
end

app/views/site/index.html.erb

<div id="authors">
  <%= render :partial => 'authors' %>
</div>

app/views/site/_authors.html.erb

<table>
  <thead>
    <tr>
      <%
        sort_headers_for :author, %w{name ranking phone updated_at} do |header|
          "Last Changed" if header == 'updated_at'
        end
      %>
    </tr>
  </thead>
  <tbody>
    <% @authors.each do |author| -%>
    <tr>
      <td><%=h author.name %></td>
      <td><%=h author.ranking %></td>
      <td><%=h author.phone %></td>
      <td><%=h author.updated_at %></td>
    </tr>
    <% end -%>
  </tbody>
</table>

Now the sort_headers_for method is using a lot of convention in there for the code that it’s generating, but the good news is that virtually everything can be overridden if you want to do things differently.

Hope you enjoy, you can get the gem here or just install with sudo gem install JasonKing-good_sort

A couple of things in the Rails console

jk@handle.it (Jason King) — Tue, 31 Mar 2009 05:59:00 GMT

So for anyone who doesn’t know, the script/console in Rails runs up an irb process behind the scenes. It also loads Rails into the context, and a few other bits - but mainly it’s an irb session.

I’ve just been getting a couple of “Oh wow, I didn’t know that.” responses when I mention these things in #rubyonrails, so I thought I’d just post this here.

Thing 1: the underscore method

The return from every command that you enter into irb is available in the underscore method _. So, if you’re like me, you often run a command and then think that you should have assigned it to some variable, or pretty-printed it or something.

The underscore method is perfect for this:

>> City.all
=> [#<City id: 218996838, name: "Chatswood", postcode: "2067", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">, #<City id: 957448139, name: "Roseville", postcode: "2069", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">, #<City id: 1015505586, name: "Willoughby", postcode: "2068", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">]

Bugger me if I didn’t just forget to assign that to something…

>> c = _
=> [#<City id: 218996838, name: "Chatswood", postcode: "2067", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">, #<City id: 957448139, name: "Roseville", postcode: "2069", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">, #<City id: 1015505586, name: "Willoughby", postcode: "2068", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">]

Yay!

The only thing to remember is that if you don’t grab it immediately, then it will be gone next command - it is overwritten with every line.

Thing 2: the y method

This is actually just the Kernel#y method, but it’s particularly useful in irb sessions when you want to print something out in an easy to read (and easy to grab if you want YAML) format.

>> { :foo => 'bar', :woo => { :ooo => 1 } }
=> {:foo=>"bar", :woo=>{:ooo=>1}}
>> y _
--- 
:foo: bar
:woo: 
  :ooo: 1
=> nil

This is especially good for outputting large collections of Rails models.

Thing 3: the pp library

The pp or Pretty-Print lib is also great for printing out collections of data in a neat way. Just require it into your irb session and use it to great effect:

>> require 'pp'
=> true
>> pp City.all
[#<City id: 218996838, name: "Chatswood", postcode: "2067", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">,
 #<City id: 957448139, name: "Roseville", postcode: "2069", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">,
 #<City id: 1015505586, name: "Willoughby", postcode: "2068", state_id: 944944227, created_at: "2009-03-30 01:56:22", updated_at: "2009-03-30 01:56:22">]
=> nil

Voila! To make that even easier, see the next thing.

Thing 4: .irbrc

By default in *nix based operating systems the file .irbrc in your $HOME directory will be loaded by irb when it starts up. (On Windows you need to create your own irbrc anywhere you like and set the IRBRC environment variable).

You can put any Ruby commands you like in here, here’s mine:

require 'rubygems'
require 'irb/completion'
require 'pp'
require 'yaml'

def gvim(x)
  IO.popen( 'gvim -', 'w') do |io|
    io.puts x.to_yaml
  end
end

def less(x)
  IO.popen( 'less -', 'w') do |io|
    io.puts x.to_yaml
  end
end

You can see that it’s simple to require in your choice of libs in there, and you can even define your own methods, which brings us to the last thing.

Thing 5: total customization

The .irbrc is just Ruby, and as you’ve seen above you can define your own methods. I’ve defined two to make it easy to pipe an object (as yaml) out to an external program (I’ve got gvim and less setup) - but you can have anything you like. This lets you customize your own irb interface with whatever little helpers you want to make your work easier.

Take a look here and here at some powerful examples of what can be done.

Enjoy.

Case insensitive SQLIte

jk@handle.it (Jason King) — Thu, 26 Mar 2009 05:15:00 GMT

One of the things that quickly tripped me up in using SQLite in Rails was that there was no way to make a column case insensitive.

Most human textual comparisons are case insensitive, we think that “dog” and “doG” and “DOG” all denote the same thing. If we have a uniqueness constraint on a column, then we want it to protect us from having three separate entries for those three strings. Also, when we’re searching for “dOg” we want it to match any one of the three strings.

Every database has its own way of doing these sorts of things - SQLite uses one of the more sensible methods: it allows you to specify that any column you like should be case insensitive (and then any index on that column will automatically be case insensitive too).

So, you can write:

CREATE TABLE foo ( bar varchar(255) COLLATE NOCASE );

And you’ll get a case insensitive column ‘bar’. This is so often what you want, more often than not, so I wrote a quick gem that does this by default for all your migrations.

This is a kludgy kludge!

What would be nice would be to add a new option to the migration methods so that any given column could be marked with something like: :case => false Unfortunately, the Rails code for all that is not very DRY and stuffed with metaprogramming - so it’s not easy to retrofit a gem to make that happen. So my gem just makes it happen for every string or text field.

Mostly this will be what you want, but every so often case sensitivity is something that is desirable - so beware :)

Dot Versions

jk@handle.it (Jason King) — Wed, 18 Mar 2009 06:08:00 GMT

Ok, so there are chunks of code I write again and again, and this is one of them:

class Version 
  include Comparable
  def initialize(_v); @v = _v.split('.').map(&:to_i); end
  def <=>(_v); @v <=> _v.split('.').map(&:to_i); end
  def to_s; @v.join('.'); end
end

I was going to reformat it, so that the methods are all newlined properly, but actually - you should have to put up with looking at it like I look at it.

So, what does this do? Well, check this irb out:

irb(main):001:0> '3.6.8' > '3.6.4'
=> true
irb(main):002:0> '3.6.8' > '3.6.10'
=> true
irb(main):003:0> # Ack!  Should be false

We get a true because they’re strings, so they’re being compared alphabetically. Rescue us wonderful Version class:

irb(main):004:0*   class Version 
irb(main):005:1>     include Comparable
irb(main):006:1>     def initialize(_v); @v = _v.split('.').map(&:to_i); end
irb(main):007:1>     def <=>(_v); @v <=> _v.split('.').map(&:to_i); end
irb(main):008:1>     def to_s; @v.join('.'); end
irb(main):009:1>   end
=> nil
irb(main):010:0> v = Version.new('3.6.8')
=> #<Version:0x547e0 @v=[3, 6, 8]>
irb(main):011:0> v > '3.6.4'
=> true
irb(main):012:0> v > '3.6.10'
=> false

Yay. That’s it, you can get it here.