me

def Dates Don't Always Add Up

posted_by :Amos, :on => 'October 27th, 2008'

I don't even know what to say about this? Anyone know why this happens?

>> Date.today -1
=> Sat, 25 Oct 2008
>> Date.today - 1
=> Fri, 24 Oct 2008
>> Date.today
=> Sat, 25 Oct 2008

end

def Square Pegs in Roun...Square Holes

posted_by :Amos, :on => 'October 14th, 2008'

One of the greatest things about Ruby is being able to think outside the box. With every class open to change the possibilities become limited only by the imagination. Just today I ran into just such an issue...

Working with a lot of others that think strictly in a Java mindset leads to a lot of code that tries to jam functionality into the existing state of a library without changing the libraries classes. Today we were working with customizing views for ActiveScaffold. We needed to have colspans that were configurable for each column, and would be different for each model. We didn't want to have to do an override for each form so it really needed to go on the columns themselves. I stepped away for a short period of time, and when I cam back my pair had used the description field of an ActiveScaffold column to pass the colspan where we needed it. The code looked something like this:

class FooController < ApplicationController
 #code
   config.columns[:field].description = '2' #notice the use of a string in description because he forgot about duck typing
   config.columns[:field_two].description = '2'
 #more cool code
end

In the view he was then using the description as the colspan attribute. NOTE: My pair really is smarter than this quick workaround, I think he was hungry. We also needed to mark certain fields as required. I'm not sure how he was planning on doing this within those bounds. So I sat down and thought outside the confines of making my world jam into the ActiveScaffold idea of how things work, and I instead made ActiveScaffold understand my world.

class FooController < ApplicationController
 #code
   config.columns[:field].class.class_eval do
     attr_writer :colspan
     attr_writer :required
     def colspan
       @colspan || 1
     end
     def required?
       @required || false
     end
   end
   config.columns[:field].colspan = 2
   config.columns[:field_two].required = true
 #more cool code
end

I know that it isn't the cleanest right now, but tomorrow when I get in I'm going to put it in a module and actually call class_eval on the real class and not finding it with other methods. The point here is to not forget that Ruby is your tool. Don't beat a square peg into a round hole, bend the hole until it is square.

end

def RESTful Wizard

posted_by :Amos, :on => 'August 12th, 2008'

Just before RailsConf 2008 I published ActsAsWizard. A rails plugin for creating RESTful multi-step wizards. I've been really happy with it, but hadn't pushed it much because of a dependency on acts_as_state_machine that I wanted to remove.

Well, I've done it. Just yesterday I removed all dependencies on acts_as_state_machine, and ActsAsWizard is finally a standalone plugin for rails. In removing acts_as_state_machine I have also removed a lot of dependencies on active record. The plugin modules are still automatically added to ActiveRecord::Base, but the functionality can be now be used with models that are not ActiveRecord. In fact I was contacted by one user that is using the wizard to populate session information.

If anyone tries out ActsAsWizard, please send me any comments or suggestions. Your help would be greatly appreciated. Oh, and patches are always welcome.

end

def In Place Editor and Collection Partials

posted_by :Amos, :on => 'September 2nd, 2007'

I've noticed a lot of individuals have been having problems with the in_place_editor function and using a collection partial. The problem comes down to an in_place_editor looking for an variable beginning with an @. So here is the quick fix.


The partial function:

<%= render :partial => "item", :collection => @items %>


Inside the Partial:

<%@item = item%>
<%= in_place_editor_field :item, 'on_hand' %>

I know it is a bit of a hack, but it is a very quick fix. Happy Coding!

end

def Why Should I 'Test Rails Itself?'

posted_by :Amos, :on => 'March 21st, 2007'

I was reading Google Groups' Rails Group the other day when I ran into someone talking about why should I test the validates functions. Here is a quote from his email:

For example, what is the point of writing a unit test that simply tests a validate statement in the model? Yes, it's interesting (the first time, at least) that the test works and that, golly-gee, Rails works as advertised, as well, but is there any real use in doing this?
I can imagine a scenario where a I update Rails and suddenly a unit test that tests a Rails validator fails, but I expect the Rails development team would find this before me. Or is that too naive?

I just thought I would post my response for anyone who has the same question. Also, sorry if the format is bad or to quick, but I was trying to hurry when I wrote him the response.

Don't look it as testing Rails. You are testing your model on testing validates. Let's say you write this class:

class Person < ActiveRecord::Base
  validates_length_of :phone_number, :within => 7..10
  ...
end

So you write a test:

def test_phone_number_length_incorrect
  person = Person.new(:phone_number => '123456')
  person.valid?
  assert person.errors.invalid?(:phone_number), 'Invalid Phone Number Coming Back as Valid'
end

I think we would all agree that this test makes sure that a valid phone number passes.

Now not thinking you do a find and replace and replace all 7s with 8s or maybe number with numbers is more likely. So you have:

class Person < ActiveRecord::Base
  validates_length_of :phone_numbers, :within => 7..10
  ...
end

Now you can place :phone_number => '12' into your database because you are now validating :phone_numbers.

If you have a test you run tests after you completed the find and replace, and this error would be caught right away. That is why you 'test Rails.'

end

end