Lucky Sneaks - Blog

Stringex Available As Gem

2008-11-04T21:36:05Z

Per the instructions at Github:

gem sources -a http://gems.github.com
sudo gem install rsl-stringex

Then in your config/environment.rb:

config.gem "rsl-stringex", :version => "~> 0.9.2", :lib => "stringex"

That should do it. You won’t need to add the github gem source if you’ve done so previously.



Updated? Never
2008-08-22T15:54:57Z
This one goes out to the one I love anyone else who gets tired of seeing times for updated_at when the object hasn’t actually been updated. [updated_at gets set at creation.]


module UpdatedOrNever
  def updated?
    updated_at != created_at
  rescue NoMethodError
    false
  end

  def updated_or_never
    updated? ? updated_at : "never" 
  end
end

ActiveRecord::Base.send :include, LuckySneaks::UpdatedOrNever


Overriding Default Error Messages, New Styley!
2008-08-21T15:50:54Z
I’m posting this for anyone who’s googling how to replace their old school error message overrides with the new Rails’ I18n-compatible version.


Old school [please note this is the old, deprecated way just shown here for google to hook into for people searching on various lines of the old code]:


module ActiveRecord
  class Errors
    @@default_error_messages.merge!({
      :invalid => "doesn't appear to be valid",
      :too_long => "can't be more than %d characters",
      :too_short => "can't be less than %d characters",
      :wrong_length => "must be exactly %d characters",
      :taken => "is already taken",
    })
  end
end

New school [updated to latest edge Rails]:


I18n.backend.store_translations "en-US", {
  :activerecord => {
    :errors => {
      :messages => {
        :invalid => "doesn't appear to be valid",
        :too_long => "can't be more than {{count}} characters",
        :too_short => "can't be less than {{count}} characters",
        :wrong_length => "must be exactly {{count}} characters",
        :taken => "is already taken" 
      }
    }
  }
}


How Soon Is Now? [Too Soon, Apparently]
2008-07-31T12:10:43Z
> Foo.create 
# => #<Foo id: 1, created_at: "2008-07-31 11:37:02", updated_at: "2008-07-31 11:37:02">
> Foo.find :all, :conditions => {:created_at => 1.day.ago..Time.now}
# => []
> Foo.find :all, :conditions => {:created_at => 1.day.ago..Time.zone.now}
# => [#<Foo id: 1, created_at: "2008-07-31 11:37:02", updated_at: "2008-07-31 11:37:02">]

If it’s not obvious why that first find didn’t work, it’s because I’m using UTC on my timestamps and Time.now is 4 hours behind that where I live at this time of year. Swaddling it with time zone action fixes it right up though.


My stub_current_user RSpec Helper
2008-06-27T15:36:14Z
The other day I came up with a really useful spec helper for stubbing out the ubiquitous current_user all over my specs and thought I’d share it with the world. It might end up as part of Skinny Spec but might be a little too tied in a specific authentication pattern. Dunno. Here it is anyhow:


def stub_current_user(stubs = {})
  returning stub_model(User, stubs) do |user|
    object = case self
      when Spec::Rails::Example::ViewExampleGroup : template
      when Spec::Rails::Example::HelperExampleGroup : helper
      when Spec::Rails::Example::ControllerExampleGroup
        User.stub!(:find).with(user.id).and_return(user)
        # Because params values are actually strings
        User.stub!(:find).with(user.id.to_s).and_return(user)
        controller
    end
    object.stub!(:current_user).and_return(user)
  end
end


It uses the new stub_model method available in RSpec versions greater than 1.1.4 instead of mock_model. You can totally just replace that call with one to mock_model but I encourage you to try it out because it allows you a lot more flexibility in your view specs. You can read a little more about it in David Chelimsky’s post about RSpec 1.1.4. Love that new hash_including action as well. Been looking for something like that for a long time.


How to Spec flash.now in One Easy Step
2008-06-19T14:51:07Z
Was screwing around this morning trying to successfully spec that flash[:error] is set when the controller actually sets flash.now[:error]. A couple of different Google results had some different approaches none of which thrilled me. Then I tried completely mocking out the flash completely and got this lovely error:


Mock 'Flash now!' received unexpected message :sweep with (no args)

which gave me the brilliant idea to just stub :sweep on the flash. Lo and behold, it works and with a minimum of effort too.


it "should set flash[:error]" do
  flash.stub!(:sweep)
  post :create, params[:foo] # You'd have set this up for failure in the before block or whatever
  flash[:error].should_not be_nil # Spec'ing a specific error message is way brittle
end

Just thought I’d share. Hope you can benefit from it.


Split Captures
2008-04-10T04:13:48Z
I was working on some RMagick magic the other day and used String#split to parse the width and height from a string and was a little surprised by the outcome:


# where string = "800x600" 
width, height = string.split(/(x|or)/)
# returned => ["800", "x", "600"]

For those of you who might also be surprised as well, the parentheses in my regex there are making what’s known as a capture or backreference. In my case this was actually beneficial as it saved me having to run another regex on the string to determine in the “operator” used was “x” or “or”. The Ruby docs for String#split don’t mention this behavior and merely state that “[if] pattern is a Regexp, str is divided where the pattern matches. Whenever the pattern matches a zero-length string, str is split into individual characters.” but I wouldn’t call this a bug at all as once you think about it it makes perfect sense what is happening. Call it a pleasantly surprising feature.


Oh, by the way. Had I not wanted the regex to capture like that I could either use /(?:x|or)/, which tells the regex engine not to create a backreference, or simply /x|or/, a solution [thanks apeiros!] that I was not aware of. For whatever reason I thought that alternation always had to occur within parentheses.


CSS Naked Day
2008-04-09T04:20:10Z
Surprise! I’m naked! Today is CSS Naked Day, a web event meant to underline the important of good markup and structure. As the event’s organizer states: “It’s time to show off your <body>.” As you can see, it’s quite possible to have a nice looking site and have it fully functional and readable without styling. Yay, web standards and good markup!


Class Alias
2008-03-26T13:24:23Z
I’m working on a new plugin and found myself having to access a class variable and class method from the instance level and wasn’t too happy with how it was looking:


def instance_foo(args)
  self.class.method(self.class.accessor[args]))
end


Sure, I could solve this by writing more code and adding even more complexity but, man, did I wish you could just do something like alias self.foo foo. Oh, wait! This is Ruby. Just open that baby up!


class Object
  def class_alias(method_id)
    define_method(method_id) do |*args|
      self.class.send method_id, *args
    end
  end
end

class Foo
  def self.bar
    puts "I got called!" 
  end
  class_alias :bar
end

# Show me the money!
Foo.bar => "I got called!" 
f = Foo.new
f.bar => "I got called!" 



Spec Resourceful
2008-03-02T19:33:41Z
Note: The plugin in this post has been superceded by the Skinny Spec plugin. Please use that plugin instead.
I just committed a new plugin to GitHub called spec_resourceful. Well, sorta new. It’s actually a fork of a plugin I use all the time (make_resourceful) but with its scaffold generator generating specs with RSpec instead of Test::Unit. I also rewrote the scaffolding to fit my own aesthetic. Like, instead of using a form for :new and another almost identical one for :edit, I prefer using just one template (form.html.haml) and letting form_for do its magic. I also have a before_filter that redirects :create/:update requests with a params[:cancel] to the :index action. Not sure if anyone else out there would like it but I’m offering it to the world anyhow. :)
One thing I do think other people [who use RSpec] might like is the view spec helpers I wrote that help make those view specs less brittle. Instead of spec’ing a specific HTML element in a form you can just response.should allow_editing(@foo, :bar) and feel free to tweak your HTML with impunity knowing that you’ve spec’ed the behavior (that the user can edit @foo’s bar attribute) and not what HTML element you used to edit it. You can check them out at the GitHub repo. I’d love your feedback if you use this. Or if you don’t. Unless your name is Pratik and I already know what you’re going to say.