Articles

ViewGem, a Little Script

What do you do when you need figure out what’s going on inside a gem, or just get a feel for its API?

I don’t use generated documentation to help me solve problems — often the library’s author and I disagree about what’s important to mention, and/or the documentation is fairly non-existent. Hey, I can’t whine… this stuff is free.

Paris, in a few words

We’re having a blast in Paris. 5 weeks in the latin quarter was lovely. 5 months in le marais will be too.

Now to find some french lessons.

Technical Background

I’ve decided it will be good for me if I can sit down once a week and try to write about a problem I had to solve that week, either in my daily life or working on a project.

The biggest problem for this week was actually making myself sit down and write something on here.  I don’t think that would be very interesting to readers or my future self so I’ll fore go the discussion of that.

Monkey Patching 101 – Proxy Objects

I think the most significant strength of the Ruby language is its impressive power and flexibility in metaprogramming. Affectionately dubbed “Monkey Patching” by Ruby developers, metaprogramming makes it easy to ‘hack’ existing code and frameworks like Rails for infinite customization, while making it easy to keep these hacks legible, organized and maintainable.

Google App Engine is getting popularity.

If you haven’t been following Google App Engine Blog, according to latest post the Google App Engine is getting popularity and many programmers are learning python just to play with App Engine. According to Marzia Niccolai on Google App Engine Blog:

Sass with Rails – avoiding disappearing stylesheets in production

A few days ago I noticed that some of the pages on the Hotels app on wego.com were completely unstyled. They turned out looking rather Jakob Nielsen-istic:

Wego.com Hotels - no CSS


Sizzling

Sizzling
This is the sound of steak in the griddle.

Two Surveys You Should Take

If you’re a Web developer of any stripe, please take A List Apart’s Survey for People Who Make Web Sites 2008, as it truly is beneficial to everyone in the industry.
Remove the web, and billions in trade disappear. Websites enable people who can’t walk to run to the store. They bring knowledge and freedom of [...]

Time to git collaborating with git_remote_branch

git_remote_branch 0.2.6 is out!

I’ve just released a new and improved version of git_remote_branch. Code named 0.2.6!

Ok, I admit. I haven’t really begun using code names.

I’m promoting the project from a pre-alpha to an alpha release. There’s still a lot to do, but the stability and “testedness” have improved greatly. Following are both sides of the maturity story.

Rails BootUp, Austin TX

A couple of months ago when Damon Clinkscales asked if I’d participate in a local training session for new Rails developers, I jumped at the opportunity. I really enjoyed my time as a speaker for the Rails Edge conferences, and, regardless of how stressful it is, there’s few things as satisfying as watching someone get Ruby and Rails right in front of your eyes.

View Specs: expectations or stubs on ActionView helpers | Rails Fire

View Specs: expectations or stubs on ActionView helpers

While adding Textile to a resource following the outside-in BDD process described in the RSpec Book I found myself wanting to put a should_receive expectation on ActionView::Helpers::TextHelper#textilize

This left me somewhat confused, as I wasn't sure what to stub, and the book doesn't cover this. Google also drew a blank.

sticking a <%= inspect %> in the view and looking at the page source revealed an instance of ActionView::Base, which makes sense but was somewhat elusive. It also showed a @controller reference, which itself contains a @template reference. A consequence of this is that in your view spec you can get at the template with @controller.template

It turns out that within a view spec #template provides the relevant object. Thanks to Tim Riley for pointing this out.

For example:

it "should textalize the teaser and extra_content" do
  @service = mock_model(Service, :null_object => true)
  @service.stub!(:teaser).and_return 'a teaser'

  template.stub!(:textilize).and_return "textalised teaser"
  template.should_receive(:textilize).with @service.teaser

  render
  response.should contain("textalised teaser")
end

This kind of stubbing is useful as it checks that the view is calling the textilize method, part of the api, correctly, not whether RedCloth (or some other texitle gem) is doing its thing. Stubbing like this will, if nothing else, speed up the spec execution. Testing with input/output examples for the textilized data could go in the view spec, but api testing at that level seems out of place to me. Of course it should be tested at some level, e.g. with Cucumber. YMMV.