Wonderland

The Simplest Thing That Could Possibly Work (With Gems)

2009-10-11T10:26:37-04:00

There has been some turmoil in the Ruby community over the github decision to stop building gems.

Since I have a forked gem that was previously hosted on github, I and my fellow users of the fork are directly affected.

In my case, I am going to do the simplest thing that could possibly work. Move my existing published gem under the same name¹ (leshill-will_paginate) over to Gemcutter. Why not follow along?

Before getting started, I signed up with Gemcutter (go ahead, do so now). Once you have confirmed your account, follow the very clear instructions and add your API key to ~/.gemrc.

gemcutter_key: NOT_MY_REAL_API_KEY

Gemcutter runs as a plugin to RubyGems, so lets install and configure it.

sudo gem install gemcutter
gem tumble

Great! We are ready to start publishing. Gemcutter only accepts prebuilt gems, so we will have to build our gem locally first. Before doing that I will modify the gemspec to make it clear that this is a fork by changing the name² and a few other fields.

Gem::Specification.new do |s|
  s.name    = 'leshill-will_paginate'
  s.version = '2.3.11'
  s.date    = '2009-10-11'
  s.summary = "Fork of the Most awesome pagination solution for Rails"
  s.description = "The will_paginate library provides a simple, yet powerful and extensible API for ActiveRecord pagination and rendering of pagination links in ActionView templates."
  s.authors  = ['Les Hill', 'Mislav Marohnić', 'PJ Hyett']
  s.email    = 'someone@example.com'
  s.homepage = 'http://github.com/leshill/will_paginate'

Ok, now we can build it.

gem build will_paginate.gemspec

Ready? Let’s push it up to Gemcutter

gem push leshill-will_paginate-2.3.11.gem

We can now install my fork of will_paginate:

sudo gem install leshill-will_paginate

Done!

¹ This is one source of heat (of many?) in the current ‘What to do?’ gem discussion. Who knew we were all unhappy with the github decision to publish gems as user-gemname?

² github prepended the github user automatically, now we have to do so explicitly in the gemspec.

and vs && - Fight!

2009-10-09T14:22:34-04:00

At Hashrocket we are always expressing our views on code, both the good and the bad, about both our own code and code written by others. Recently, the issue of when to use the two flavors of Ruby logic operators: the punctation operators &&, ||, ! or the english operators and, or, not.

Developers new to Ruby¹ should be following the rule to only use the punctuation operators for logic:

editable = user.admin? || item.editable?

if user.admin? && item.editable?

and the english operators for flow control:

render :action => 'edit' and return if editable

Once developers are proficient (see below for a quiz!) in Ruby, this rule should become a rule of thumb or just ignored. For example, this reads better with and:

if user.admin? and item.editable?

So how do you know if you should be following the rule or just be aware of it? Answer this:

What happens if we replace the || with or in the first example and why?²

¹ Excluding those who are proficient in other languages and already recognize the issue.

² Did not know the answer? Take a minute and learn Ruby’s operator precedence

Best Practice: No Chains in Controllers

2009-09-29T23:39:00-04:00

Dan Croak just posted testing named scopes which you should read right now.

We also have been using the rule of thumb in the last paragraph: No Chains in Controllers. Our experience is that not only do you immediately benefit from simpler tests, but we have also found that you get simpler and more expressive implementations. If we do end up using a chain we usually encapsulate it in a method, keeping the tests and code clean.

Update for stub_chain for Mocha

2009-08-05T14:02:42-04:00

Thanks to Josh Nichols for pointing out that the original code (and the RSpec mock code!) did not handle stubbing the same part of the chain multiple times, for example:

stub_chain(:votes, :supporting, :count).returns(supporting_count)
stub_chain(:votes, :opposing, :count).returns(opposing_count)

Here is the updated snippet that works when you stub the same part of the chain multiple times:

 1 module StubChainMocha
 2   module Object
 3     def stub_chain(*methods)
 4       if methods.length > 1
 5         next_in_chain = ::Object.new
 6         stubs(methods.shift).returns(next_in_chain)
 7         next_in_chain.stub_chain(*methods)
 8       else
 9         stubs(methods.shift)
10       end
11     end
12   end
13 end
14 
15 Object.send(:include, StubChainMocha::Object)

Copy that into spec/stub_chain_mocha.rb and then require it from spec_helper.rb.

Bouncy Bots!

2009-07-01T10:08:30-04:00

A simple negative captcha for Rails.

A negative captcha flips the normal captcha on its head, rather than asking humans identify themselves, we trick the bots into identifying themselves. We do this by placing honey pots in a form that are invisible to a human, but visible to a bot. When the bot submits the form, we look for the honey pot entries and discard the form submission if we find any.

The source is MIT licensed and available on github.

Installing Bouncy Bots!

Bouncy Bots! is available as a gem from github. Install the gem with the following command:

% sudo gem install --source http://gems.github.com/ leshill-bouncy_bots

After you have the gem installed, add a config.gem line to your environment.rb file:

1 config.gem 'leshill-bouncy_bots', :lib => 'bouncy_bots', :version => 0.1.0

Using Bouncy Bots!

Controllers

Use the bounce_bots macro in your controllers to detect and bounce bots. The macro takes two parameters, the honey pot field name and the redirect path or url. For example, to check for the field :blog_url and redirect bots to the pages_path :

1 bounce_bots :blog_url, :pages_path

You can also pass the standard controller filter options such as :only or :except :

1 bounce_bots :blog_url, :pages_path, :only => [:create, :update]

Views

In your form views, add the honey pot field. If you are using form_tag, you can use any form element, for example (using haml):

1 = text_field_tag :blog_url, nil, :class => 'long_required'

In your stylesheet, add a rule to ‘hide’ the field:

1 input.long_required { display:none; }

If you use form_for, there are two helpers to simplify making the honey pot.

1 = f.bounce_label 'Blog Url', :class => 'long_required'
2 %br
3 = f.bounce_field :class => 'long_required'

And that’s it.

Semantic List Markup with will_paginate

2009-06-27T08:35:29-04:00

will_paginate using ul and li tags

will_paginate is the defacto standard plugin for the Rails community. Almost every app will need pagination and will_paginate does almost everything you need.

The one thing will_paginate does not do is generate semantic pagination markup. Semantic markup uses standard HTML tags to convey structure and meaning. For example using an h1 tag for a heading rather than styling a div tag to do the same.

The default will_paginate pagination is a series of anchors and spans strung together. As many a designer has pointed out, that series is really a list of pagination controls. If you are working with such a designer or you are writing semantic markup, try out my fork and enjoy will_paginate with semantic pagination.

How to install

As of this moment, you can install it as a plugin. I am considering releasing this as a gem; ideally the patch to will_paginate would be accepted (see below).

%script/plugin install git://github.com/leshill/will_paginate.git

How to use

Use the will_paginate view helper, passing the :semantic => true option. If you do not want the enclosing ul tag, pass :container => false.

<%= will_paginate @pages, :semantic => true %>

Which looks like:

 1 <ul class="pagination">
 2   <li class="disabled prev_page">&laquo; Previous</li>
 3   <li class="current">1</li>
 4   <li><a href="/pages?page=2" rel="next">2</a></li>
 5   <li><a href="/pages?page=3">3</a></li>
 6   <li><a href="/pages?page=4">4</a></li>
 7   <li><a href="/pages?page=5">5</a></li>
 8   <li><a href="/pages?page=6">6</a></li>
 9   <li><a href="/pages?page=7">7</a></li>
10   <li><a href="/pages?page=8">8</a></li>
11   <li><a href="/pages?page=9">9</a></li>
12   <li class="gap">&hellip;</li>
13   <li><a href="/pages?page=33">33</a></li>
14   <li><a href="/pages?page=34">34</a></li>
15   <li class="next_page"><a href="/pages?page=2" class="next_page" rel="next">Next &raquo;</a></li>
16 </ul>

Will this patch be accepted?

Signs point to ‘uncertain’. Mislav has in the past indicated that he was not convinced that list support was necessary in the plugin since you can replace the renderer¹. Since semantic markup is commonly used, I have sent a pull request. In any event, the authors of will_paginate have my thanks for creating a very useful plugin.

¹ So why the fork? In order to support the containing ul directly, the core of the helper had to be modified. See the change on github .

Default Options With Ruby

2009-06-10T19:34:47-04:00

Ruby and the argument collecting hash syntax

Unlike other languages, ruby does not support keyword parameters. As an alternative, we use ruby’s syntactic shorthand to pass a hash as the final argument to a method using the key => value syntax:

1 some_method(first_arg, :key1 => value1, :key2 => value2)

some_method will receive a hash as its second argument with the specified key/value pairs. Unlike regular arguments, there is no way to provide default values for the individual key/value pairs (you can provide a default for the hash argument though):

1 def some_method(thing, options = {})
2   #...
3 end

There are a few ruby idioms for providing default options to an option hash, one of the most common is available in rails, using the core extension Hash#reverse_merge from ActiveSupport¹:

1 def some_method(thing, options = {})
2   options.reverse_merge!({:key1 => 'default'})
3   #...
4 end

If you do not have access to ActiveSupport, you can use ruby’s Hash#merge² as an alternative:

1 def some_method(thing, options = {})
2   options = {:key1 => 'default'}.merge(options)
3   #...
4 end

If that seems like too much code to be typing all the time, you can open up Hash and add a method. Careful! This is simple enough to get wrong. Here is some code³ from a very useful rails plugin:

1 def default!(defaults = {})
2   defaults.each do |key, value|
3     self[key] = value if self[key].nil?
4   end
5   self
6 end

This code works until you want to set a default value to nil. This can be fixed by replacing the conditional on line three with unless self.has_key?(key). Or you can simply rewrite this in terms of Hash#merge⁴:

1 def default!(defaults = {})
2   replace(defaults.merge(self))
3 end

¹ Which builds on ruby’s Hash#merge.

² Or merge-bang (merge!).

³ Slightly modified for readability.

⁴ ActiveSupport does something similar.

Truncating HTML

2009-06-03T12:23:40-04:00

We recently needed to show a truncated version of existing HTML content. Although there are several issues¹ when dealing with HTML content, our specific concern was maintaining the integrity of the HTML. Some quick googling led to a nice helper written by Henrik Nyh last year. We tweaked the original a bit to append the ellipsis within the tag at the truncation point and truncate at a word (or tag) boundary. Here it is, enjoy.

 1 # By Henrik Nyh <http://henrik.nyh.se> 2008-01-30.
 2 # Free to modify and redistribute with credit.
 3 # Word truncation and fixes by Les Hill <http://blog.leshill.org> 2009-06-02
 4 #
 5 
 6 require "rubygems"
 7 require "hpricot"
 8 
 9 module TextHelper
10 
11   # Like the Rails _truncate_ helper but doesn't break HTML tags or entities.
12   def truncate_html(text, max_length = 30, ellipsis = "...")
13     return if text.nil?
14     doc = Hpricot(text.to_s)
15     doc.inner_text.chars.length > max_length ? doc.truncate(max_length, ellipsis).inner_html : text.to_s
16   end
17 
18   def self.truncate_at_space(text, max_length, ellipsis = '...')
19     l = [max_length - ellipsis.length, 0].max
20     stop = text.rindex(' ', l) || 0
21     (text.length > max_length ? text[0...stop] + ellipsis : text).to_s
22   end
23 end
24 
25 module HpricotTruncator
26   module NodeWithChildren
27     def truncate(max_length, ellipsis)
28       return self if inner_text.chars.length <= max_length
29       truncated_node = dup
30       truncated_node.name = name
31       truncated_node.raw_attributes = raw_attributes
32       truncated_node.children = []
33       each_child do |node|
34         break if max_length <= 0
35         node_length = node.inner_text.chars.length
36         truncated_node.children << node.truncate(max_length, ellipsis)
37         max_length = max_length - node_length
38       end
39       truncated_node
40     end
41   end
42 
43   module TextNode
44     def truncate(max_length, ellipsis)
45       self.content = TextHelper.truncate_at_space(content, max_length, ellipsis)
46       self
47     end
48   end
49 
50   module IgnoredTag
51     def truncate(max_length, ellipsis)
52       self
53     end
54   end
55 end
56 
57 Hpricot::Doc.send(:include,       HpricotTruncator::NodeWithChildren)
58 Hpricot::Elem.send(:include,      HpricotTruncator::NodeWithChildren)
59 Hpricot::Text.send(:include,      HpricotTruncator::TextNode)
60 Hpricot::BogusETag.send(:include, HpricotTruncator::IgnoredTag)
61 Hpricot::Comment.send(:include,   HpricotTruncator::IgnoredTag)

¹ For example: preventing XSS attacks, maintaining coherent styling.

AWS S3 Bucket Copy

2009-05-28T15:43:44-04:00

We use S3 for a lot of our projects using the aws-s3 gem. One thing that has continually plagued me is copying objects from one bucket to another. Having rewritten this snippet of code twice already, I am placing it here for future reference. Enjoy.

 1 class S3Object
 2   def self.copy_across_buckets(src_bucket, src_key, dest_bucket, dest_key, options = {})
 3     original = open(url_for(src_key, src_bucket))
 4     default_options = {:content_type => original.content_type}
 5     store(dest_key, original, dest_bucket, default_options.merge(options))
 6     acl(dest_key, dest_bucket, acl(src_key, src_bucket))
 7   end
 8 
 9   def copy_to_bucket(dest_bucket, dest_key = nil, options = {})
10     self.class.copy_across_buckets(bucket.name, key, dest_bucket, dest_key ? dest_key : key, options)
11   end
12 end

RSpec stub_chain for Mocha

2009-05-05T22:13:45-04:00

I am not at RailsConf but I have been following the tweets of my coworkers, so I heard about RSpec‘s new stub_chain method. Since I prefer Mocha’s syntax to that of the built-in RSpec stubbing framework, I created a monkey patch to add stub_chain to Mocha:

 1 module StubChainMocha
 2   module Object
 3     def stub_chain(*methods)
 4       while methods.length > 1 do
 5         stubs(methods.shift).returns(self)
 6       end
 7       stubs(methods.shift)
 8     end
 9   end
10 end
11 
12 Object.send(:include, StubChainMocha::Object)

Copy that into spec/stub_chain_mocha.rb and then require it from spec_helper.rb.