JRuby Team Picked Up By Sun

Posted by kev Thu, 07 Sep 2006 18:31:00 GMT

Wow. Just wow. Congrats guys.

Update: Tim Bray gives us Sun’s motiviations.

Posted in ,

SD.rb Meeting Tonight

Posted by kev Thu, 07 Sep 2006 17:13:00 GMT

If you’re in San Diego (or even Southern California) we’d love you to drop by the sd.rb meeting tonight. Chris Abad and I will be talking about RESTful stuff in Rails and Tom Preston-Werner will be debuting his new natural time parsing library, Chronic.

We have our meetings at the UCSD CSE buildng (room 1202). If you want to drop me an email at kevin dot clark at gmail dot com I’ll give you my cell in case you get lost.

I hear OC Ruby may be making a field trip. See their list if you want to get in on that.

Addtionally, several OC Rubyists and SD Rubyists are planning to meet up at Rock Bottom just off campus around 6:15 for dinner. Come hang out.

If you can’t make it the sd.rb podcast is always an option and I’m told you should be getting several updates from the last meeting in the next couple days. Keep a look out.

Posted in ,

Documentation Project: Proposals

Posted by kev Wed, 06 Sep 2006 18:47:59 GMT

In case you missed it, I’ve got information about proposals for the Caboose Documentation Project on the Caboose Blog.

If you’re interested in helping out, please go take a look.

Posted in ,

A Ruby IDE: Why TextMate Is Close Enough

Posted by kev Wed, 06 Sep 2006 10:04:00 GMT

Recently Tim Bray posted a list of things he has found that Ruby needs. One of these things is an IDE and he provides a list of useful things one would do for us. I’m not sure if Tim has tried TextMate, but if you’re aware of the right features it turns out to almost be exactly what he’s looking for. The remaining features might be implemented by the right group out in the Lazy Web (do these things and we’ll all be grateful). Anyway, here’s interesting things you may have missed about TextMate in the context of Tim’s wish for an IDE.

Read more...

Posted in , ,  | 14 comments

Running Tests on Deploy with Capistrano

Posted by kev Mon, 04 Sep 2006 22:16:00 GMT

Rabble just released an article on his Testing Rails Blog on how to run tests on deploy with Capistrano. It covers basic Capistrano tasks that will work with a single deployment server and then goes into some more advanced tasks for multiple server deployment and concurrent deploys. Go check it out.

Posted in , ,

assert_select included in core, assert_tag deprecated

Posted by kev Sun, 03 Sep 2006 21:23:00 GMT

In case you missed the changeset, Assaf Arkin’s assert_select has been included in EdgeRails. This officially marks the deprecation of assert_tag.

I think this is a good thing. I always found the syntax of assert_tag ugly. assert_select looks to be a fine replacement.

If you aren’t running edge, it is available as a plugin.

Posted in ,

Mocking Models

Posted by kev Sat, 02 Sep 2006 23:30:00 GMT

Today I decided to see how much of the test code in my current side project I could rip fixtures out of. At the same time I could see what kind of speed increase I got from staying away from the database. Model tests seem to be the most straight forward so I started there.

Read more...

Posted in , ,  | 2 comments

The Flexibility of Mocha

Posted by kev Fri, 01 Sep 2006 18:18:00 GMT

This post just blew me away. Turns out instead of using the delegate_method_to_mock! method I posted the other day, I could use Mocha and just save myself the time. Check this out:

Using Flexmock (and my custom method):

  def test_process_exit
    delegate_methods_to_mock!(RailsFCGIHandler, :close_connection) do
      fcgi = flexmock()
      fcgi.should_receive(:close_connection)
      @handler.mock = fcgi
      @handler.stubs(:when_ready).returns(:exit)
      @handler.process!
    end
  end

It works but it’s none too pretty. Flexmock people, if there’s a better way speak up.

Here’s the equivalent using Mocha:

  def test_process_exit
    @handler.expects(:close_connection)
    @handler.stubs(:when_ready).returns(:exit)
    @handler.process!
  end

I can place expectations directly on my object (even though I didn’t create it as a mock) and it takes care of it for me. That is *so* much clearer and I’ve saved 3 lines that didn’t tell me anything new about my test. I think I’m in love.

Posted in , ,  | 3 comments

On The Day's Events

Posted by kev Thu, 31 Aug 2006 01:25:00 GMT

So, I seem to have inadvertently caused a significant amount of controversy with this morning’s article on what I don’t think you should be doing in Rails. Some rather harsh words have been exchanged. It’s time for us all to take a breath, count to ten, and remember we’re all just coders working together to make Rails (and Ruby) better.

Matz is nice, so we should be nice.

With that as a preface I’d like to explain some of the things I said which caused a stir. Hopefully this will clarify and you can stop thinking of me as some pre-pubescent FUDdy jerk if indeed that’s where you stand.

I thought I was giving you a list of things that you should avoid in modern versions of Rails. I didn’t get anything back differently from my reviewers. You should know that for bigger articles like this I always have a group of people take a look see first and give me feedback. These are people that I respect and may be better at writing and programming than I am (and often are). I wait to get OKs from that group before I post.

I think this group of lines may have been my downfall.

See? A halt! Sufficiently frightened? You should be. Now, stop using these things. It’s for your own good.

I rather regret this. In my head it was tongue-in-cheek. My reviewers didn’t even mention it though I imagine they knew I was joking since they know me personally. Others apparently didn’t. What I meant to say was that I hope the list would coerce you into improving your code. That message got lost somewhere along the line and I feel like we’ve played a rather large game of telephone. I’m sorry for that.

Pagination seems to be the issue we pulled apart today so let’s talk about that for a few minutes. I said some things about pagination that, after returning to them, seem a bit cryptic. Sorry about that. Let me clarify: the built in pagination helpers are a hackish pain. They’re hard to work with and have some efficiency issues. As a result, working with very large data sets can cause it problems. Don’t be afraid, just be aware. With large data sets you’ll want to roll your own. The Paginator object itself isn’t so bad (though we really should clean it up) and I prefer to use custom pagination with it over the helpers.

That being said, we’ve talked about pulling out the Rails pagination helpers into a plugin for a while. I imagine they were brought up when I passed the article around was for that reason. It isn’t deprecated yet, but it probably will be.

Now, if you have other concerns please bring them up here.

Update: A friend has noted that one of the problems may be that some look at me as a voice of the core. Let me be clear: I’m not in core. I don’t speak for core. I speak for myself based on my knowledge and opinions. When I say, “we’ve talked about it” I mean “I’ve talked with developers working with the core in and outside the core team and the consensus seems to be that pagination will come out”. BUT, I’m still not David and not the core.

Posted in , ,  | 29 comments

Injecting Mocks (one way or another)

Posted by kev Wed, 30 Aug 2006 21:15:00 GMT

I’ve been playing a lot with mocks lately (and I’m a bit post happy today) so I thought I’d show off a bit of code that was useful in a patch in RailTies.

Sometimes methods are hard to mock. They aren’t calling actions on some object you can replace with a mock or the API was designed so it’s hard to inject the mock in the first place.

This bit of code lets you intercept a method call and redirect it to a mock object of your choosing:

  
  # The multiple method form
  def delegate_methods_to_mock!(klass, *methods)
    methods.each {|m| redefine_method_using_mock! klass, m }
    yield
    methods.each {|m| reset_method_using_mock! klass, m }
  end

  def delegate_method_to_mock!(klass, method)
    redefine_method_using_mock! klass, method
    yield
    reset_method_using_mock! klass, method
  end

  def redefine_method_using_mock!(klass, method)
    klass.send(:attr_writer, :mock) unless klass.respond_to? :mock=

    klass.send(:alias_method, "nonmocked_#{method.to_s}", method.to_s) unless klass.respond_to? "nonmocked_#{method.to_s}"

    klass.send(:define_method, method, 
      Proc.new {|*args|
        @mock.send(method, *args)
      }
    )
  end

  def reset_method_using_mock!(klass, method)
    klass.send(:remove_method, method)
    klass.send(:alias_method, method, "nonmocked_#{method.to_s}")
  end

So then we use it like:

  def test_process_exit
    delegate_methods_to_mock!(RailsFCGIHandler, :close_connection) do
      fcgi = flexmock()
      fcgi.should_receive(:close_connection)
      @handler.mock = fcgi
      @handler.stubs(:when_ready).returns(:exit)
      @handler.process!
    end
  end

What happens is that an accessor is placed on the object in question and the method you want the mock to intercept is redirected to call on the mock instead… so it goes like this:

I call someobject.blah(1,2,3) which would normally call someobject.a(1,2,3) (may be a protected method) but instead we redefine a to call @mock.a(1,2,3) so we can register the call.

I’m not entirely sure if this is the best way to handle it but it seems to be working for my needs at the moment.

Posted in , ,  | 3 comments

Older posts: 1 ... 3 4 5 6 7 ... 17