Disqus - Latest Comments for Dan Kubb

Re: [ANN] alter-ego 1.0.0 Released

Dan Kubb — Sat, 29 Nov 2008 12:30:44 -0000

This looks pretty nice. I was curious tho, have you looked at Mixology? I was thinking that the state blocks could setup anonymous modules, and instead of the handle blocks you could use normal methods. Each module would correspond to a specific state and get mixed into the object as part of each state transition.

Re: The last of the Merb 0.5.x line

Dan Kubb — Sat, 02 Feb 2008 12:35:00 -0000

Mike, a good resource to check merb against for its HTTP compliance is the following flow chart:

http://thoughtpad.net/alan-dean/http-headers-st...

It gives alot of information about how requests should be handled, and what status codes to return in certain situations. Its missing a few things, like returning 422 Unprocessable Entity when a PUT or POST request body is well formed, but contains invalid information (Fielding commented in rest-discuss this was the best status to return in this case); otherwise its probably one of the best resources aside from RFC 2616.

Re: Easy PDF Generation with Ruby, Rails, and HTMLDOC

Dan Kubb — Tue, 20 Nov 2007 15:33:02 -0000

Would you mind posting an example of what the example view renders to when rendered as PDF?

I've got some code using PDF::Writer, and managing the templates is a pain. If I could design the templates using normal HTML views, and then render them as PDF with some reasonable control over the style, I'd be a happy man.

Re: Quick trick for using “classify”

Dan Kubb — Sun, 24 Feb 2008 16:23:51 -0000

Have you thought about submitting a failing test case to the Rails Trac site? I can imaging that tables with the word "status" would be reasonably common, so it probably should be fixed.

Re: Battle Royale - Testing

Dan Kubb — Sun, 18 Mar 2007 13:50:00 -0000

This is a great post. I tend to mock too far in depth, and I think I should just be testing the surface of my API and try to treat it more like a black box so that my tests aren’t brittle.

I know your testing helpers aren’t finished, but I have a question about the syntax. In your tests I see the following:


should_have_many :rated_books, :through => :ratings

For the purposes of testing does it really matter if rated_books is found through ratings? It might only be better to make sure that User#rated_books can be responded to, returns zero, one or more RatedBook models, and whatever other behaviour the dependent code relies upon.

The fact that the models are found through a join with another model isn’t really important (IMHO) to test. If you were ever to change this, but leave the interface the same, all dependent code shouldn’t break, but the tests will.

I think when tests break but dependent code doesn’t that means the test cases are too brittle.

Re: Battle Royale - Testing

Dan Kubb — Mon, 19 Mar 2007 23:56:00 -0000

Tammer: Actually I don’t think that using reflection is such a bad way of testing the associations, as long as the logic is wrapped up nicely and can be updated in one spot should the reflection API in ActiveRecord change at some point. ActiveRecord is pretty well tested, so as long as its API says the association exists I think its reasonable to believe it.

I’ve been thinking about the problem of over-mocking, and I just came across a presentation by Chad Fowler called ‘Quick and Clean: Well-factored Rails’ that presents a few approaches that I think would simplify controller testing. Here’s a summary of his talk as well.

For example, he asserts that you don’t want to have finder methods with conditions/orders in your controller actions such as:

def search @users = User.find :all, :conditions => ['name like ?', "%#{params[:q]}%"] end

Instead he thinks the controller should have no knowledge of how the User.find method works, and that you should wrap it into a finder method like
User.search_by_name, as in your example above:

def search @users = User.search_by_name(params[:q]) end

This is also known as the Skinny Controller, Fat Model approach.

If this was used then to test the search controller action, all you’d have to do is mock User.search_by_name in your functional test. You’d still want to test User.search_by_name directly in the unit test, which is sort of just like moving the complexity to a different spot, although I think its moving it to the more correct location.

Re: Jester: JavaScriptian REST

Dan Kubb — Sun, 08 Apr 2007 13:02:00 -0000

Eric, this is absolutely fantastic. This (and a few other cool things this week) is enough to get me to switch back to Prototype.

+1 for an async option too.

Also, you may want to look at the bottom of ActiveResource’s README file for a list of error codes a RESTful Rails app can return. I believe the status codes Jester is checking aren’t quite in-line with ARs’ behaviour.
For example a status between 200-399 is considered to not have returned an error, while 422 is used when the app receives bad data.

Re: Jester 1.1: Asynchronous REST

Dan Kubb — Thu, 19 Apr 2007 13:27:00 -0000

Is anyone working on Rails helpers that use Jester for things like AutoComplete? It seems as if the built-in Rails helpers don’t make use of the features available in RESTful Rails enabled apps.

Re: Jester 1.1: Asynchronous REST

Dan Kubb — Thu, 19 Apr 2007 20:00:00 -0000

Eric, there was some talk over here about how Rail’s AutoComplete helper used an approach that doesn’t really fit with the RESTful Rails way of doing things.

In that article’s comments I mentioned I think a better approach would be to just use the standard #index action, and return XML using respond_to. On the client side it could be parsed and used to create an AutoComplete field, just like how AutoComplete works now.

Taking it a step further, I could see a benefit of writing a plugin that can act as a stand-in replacement for normal Rails javascript helpers (like AutoComplete) but using Jester and RESTful Controllers.

My comment above was mainly to see if anyone’s gone down this road or if there’s any interest in this area.

Re: Jester 1.1: Asynchronous REST

Dan Kubb — Thu, 03 May 2007 01:53:00 -0000

Eric, the main helpers that could be better done RESTfully are the ones for AutoCompleter and InPlaceEditor. In the docs it says they’ll be pulled out of the core into plugins before Rails 2.0 is released.

In AutoCompleter’s case it would be better to do a GET to the #index action, retrieving the xml formatted data to merge into the autocompletion field. For InPlaceEditor, it would be better to do a PUT to the #update action.

Actually, the worst part about these is that they’re paired with other helpers that dynamically add actions to the controllers to handle their respective requests. Nasty.

Re: The URL Police

Dan Kubb — Wed, 14 Nov 2007 16:42:00 -0000

I like to use a DRY version of the precise approach. I create my own submit_tag helper method in ApplicationHelper like so:

def submit_tag(value, options = {})
  super value, options.merge :name => nil
end

I do this with any Rails helper that I want to supply defaults to. I sometimes even use this to raise exceptions when I forget to specify certain parameters, like :title for any form fields.

Re: To em, or to err.

Dan Kubb — Tue, 29 Jan 2008 21:38:00 -0000

SASS has something built-in where you can specify the default sizes, and use math within the CSS-like syntax to calculate relative sizes of fonts and line heights.

Re: what, is it good for? absolutely nothing

Dan Kubb — Fri, 22 Feb 2008 14:05:00 -0000

This is a pretty nice idiom. Its probably worth submitting as a patch to Rails, since I think it much cleaner than using == to test the format type.

Re: RESTful contact forms

Dan Kubb — Fri, 04 Apr 2008 11:50:00 -0000

I don’t have any huge improvements over what you’ve done here, but you could always pass the form values into Notifier.deliver_contact_form using Hash#values_at:
<filter:code lang="ruby">
Notifier.deliver_contact_form *params.values_at(:name, :email, :message, :referer)
</filter>

I’m also not sure the “and return” in the action is necessary. I suppose its an ok idiom to use when you need to return from the middle of the action, but when its the last statement in the action its unecessary.