Paul Goscicki

This example (shortened here):

class Order
  def shipping_cost
    total_weight * 5 + 10
  end
end

require 'test/unit'
require 'rubygems'
require 'mocha'

class OrderTest < Test::Unit::TestCase
  # illustrates stubbing instance method
  def test_should_calculate_shipping_cost_based_on_total_weight
    order = Order.new
    order.stubs(:total_weight).returns(10)
    assert_equal 60, order.shipping_cost
  end
end

and this snippet (emphasis mine):

The more interesting discussion deals with whether to mock or stub your database-backed model. One upside is speed: This test case will not hit the database at all. Another is independence. I completely isolate the code under test to the controller layer.

convinced me that there just might be some treasure to be found beyond the Test::Unit. And I know that it's just the tip of the iceberg.

To anyone interested, here’s the link to my github repository with all of my open-source projects. Most of them are my own Rails plugins, but I host the latest development version of the WP Movie Ratings plugin. Without any further ado, here it is:

http://github.com/pjg

Or putting it in another words: Merb will be merged into Rails to become Rails 3.0. Is it 1st April just way too soon or what? – was my first thought the moment I’ve read it on the Ezra’s blog. But then I’ve read the official announcement and… it kind of turned out to be true. Surprised I was, definitely. I haven’t really jumped on the whole Merb bandwagon. Sure, I was planning to try out Merb in the (rather distant) future. Now it seems I won’t have to. Merb supposedly did lots of things better than Rails (modularity, less dependencies, more lightweight, faster) and those things are to be incorporated into Rails. Will see how this pans out.

Exciting times. Definitely exciting. Nice Xmas gift.

From the great article on our fluorishing craft, Lucky to be a Programmer by Gustavo Duarte:

For the past few weeks I’ve been working with a fellow developer on a project that required an all-out programming effort. It’s done now, so we’re back to a regular schedule, but when people hear about the crazy hours they often say they’re sorry. They really shouldn’t be. I would never do this often, or for long periods, or without proper compensation if done for an employer, but the truth is that these programming blitzkriegs are some of my favorite periods in life. Under the right conditions, writing software is so intensely pleasurable it should be illegal.

(via Ryan Dahl)

It was a rather hard programming quiz. On the other hand 55 points is exactly 55%, so I have passed. Barely, but still…

The above picture comes from Steve Yegge’s Egomania. There’s also his great post Dynamic Languages Strike Back. Both recommended reads.

Donald Knuth:

Premature optimization is the root of all evil.

Ezra Zygmuntowicz:

Postmature optimization is the root of all hosting bills.

(via)

Normally, you’d use partials to manage some common functionality in a single file. For example like this:

Somewhere in your view:

<%= render :partial => 'ads/ad', :locals => {:placement => 'frontpage-banner1'} %>

It’s quite concise, but how about making it even less verbose? Helpers to the rescue:

module AdsHelper
  def ad(placement)
    render :partial => 'ads/ad', :locals => {:placement => placement}
  end
end

And now you can write this in your view:

<%= ad 'frontpage-banner1' %>

Nice! I believe it’s as short as it gets. Sure, if you render this partial only a few times it might not be worth it, but what if you render it 20 or 30 times?

About those one-liners… How about turning this:

<% if logged_in? then %>
<p><%= link_to 'Edit', document_edit_path(@document) %></p>
<% end %>

into this:

<%= content_tag 'p', link_to('Edit', document_edit_path(@document)) if logged_in? %>

I don’t know about you, but to say that I’m impressed would be not enough. Available from Rails 2.0 upwards.

Steve Yegge (emphasis added):

So how do you make yourself a superstar? Never stop learning. I’ve heard people say they think this position is a crock, that it’s ludicrous, that you couldn’t possibly spend your whole career learning new things.

But I think differently. I think every program you write should be the hardest you’ve ever written. And that’s what I blog about, mostly. Improving yourself.

It got me thinking today and the more I think about it the more sense it makes. I would go even further with this and say that writing not just hard programs but simply more complicated code is good for you. Not obfuscated nor unreadable but code which is just a bit harder to understand. What I mean is using new constructs, new methodologies, shorter one-liners (but not those super-obfuscated Perl ones), etc.

There are lots of people who will tell you that you should write the simplest code possible (even despite the obvious bloat) because this results in a more maintainable application. This is of course true, but should the maintainability be the ultimate goal? I think that self-improvement should be a higher placed goal. And I think that you self-improve by writing code you need more time to comprehend because the harder code you write now and the more time you spend understanding it in the future the less complicated it becomes. Over time. And that is progress. That is self-improvement. Plus, as a side effect of this, your code is usually more concise.

Now going back to refactoring one of my projects…