Rabbit Creative

From the GNU Smalltalk documentation:

I am an abstract class. My objects represent things that are discrete and map to a number line. My instances can be compared with < and >.

The documentation is written from the perspective of the object. Brilliant.

I’ve loosely followed the happenings over at the Consumerist for about a year now. Reading articles here and there and reading about half the comments for each article.

The articles themselves are decent. They’re revealing and interesting to read.

Some of the comments, however, are a different story. The following were taken from this article:

Our bank has me properly trained.

All I had to do was upgrade my account to playa level, in accordance with the higher balance, and I could use a lot more of my money daily.

Wanting to make a purchase @ Best Buy, and he Banks with Bank of America?? That’s like admitting you are a stupid consumer.

If you can afford to put it on the debit card, you can just as well put it on the credit card and immeidately pay down the balance without incurring interest. This is credit cards 101 stuff here LOL.

They reek of playing by the rules and using workarounds to “correct” an issue that, in my mind, shouldn’t have been an issue in the first place.

On a positive note, there are some level-headed, reasonable commentators as well.

I think the OP has a right to be mad. It’s HIS money.

“OP” means “original poster,” and usually refers to the author of the article about which people are commenting.

I think it is a big deal that he was denied access to his own money. It’s not Bank of America’s money, it’s his money.

I’d like to focus on this comment for a moment:

I am so sick of consumers like you who think there’s no problem anywhere until something happens to you personally, and that if problems happen to others its their fault because they are not as slick or whatever as you are.

See anything odd?

This part, I am so sick of consumers like you…

I’ve been noticing this house of mirrors kind of dichotomy for quite some time.

It’s one in which I must be very careful about the language I use. Each word is both ally and enemy. Use a word in one context and it becomes a scholar of truth. The same word in a different context can turn on you like beaten dog. And some words, ought not be used at all.

In its common usage, “consumer” is one of them.

Using the term “consumer” as a description of a human being is like throwing your chips into the pile. You’ve agreed to play the game. Their game. A game you cannot win because of the very definition of the word.

Sure, everyone consumes. Consume food. Consume “goods.” Consume air. “Consumer” doesn’t seem like such a bad word. Does it?

Have you ever met someone that was able to argue their way into or out of anything? Regardless of how ridiculous their stance may have sounded in the beginning, you were eventually able to see their point of view.

Like most things, language isn’t permanent. Quite literally, a word means no more and no less than what I say it does. In my mind and in my communications. You can agree or disagree to use it in the same way. The practice of “rewiring” words is deceptive. It’s also common. The best defense is to be aware of it.

Words are like opinions. Opinions are subjective. You understand what I am saying because of the agreed upon definitions of the words I am using. Or you don’t. Or you understand some, but not all. Or you understand, but disagree. The last one is rare.

Now, imagine for a moment that you and I are good friends with staggering wealth. We agree to redefine a word, say, “consumer,” to mean “unit of consumption that leads to profit.”

With our financial influence we begin to use the word “consumer” in all communications. The word, to a degree, fits, or makes sense, in the contexts it is being used, and so catches on.

Finally, you take the bait. “I’m a consumer, damn it! I have rights!”

No, no you don’t. Humans have rights. Consumers, per the game (context) you’re playing, do not.

Same word, different contexts. I use the word context here to describe a social climate. By social climate I mean a rather large group of humans who subscribe to a certain set of rules. This is that. This is considered good form, that isn’t. So on and so forth. I don’t call it culture because I believe culture to mean something produced serendipitously over time, not arbitrarily as in my above example.

Now we come full circle. The very name of the website, “consumerist.com,” leads me to believe the people engaged therein have all agreed to step into yours and mine’s house of mirrors. No matter how much progress they make in “improving” it, we will always be the game masters. Should they come close to completion, with a stroke of the pen we will return them to the beginning. New restrictions, new technicalities, new rules. Unending rules. Arbitrary rules. Rules designed to keep them minimally satisfied, and always busy enough to prevent them from really thinking about the situation they’re in.

If you’ve come this far, and I trust you have because I believe you to be intelligent, it is of the utmost importance that you realize there are games within games. Breaking out of one is often not good enough. There are many games we have been fooled into playing.

I’ll end this by saying that simple is good. If a system is so big you can’t hold the entire thing in your head at once, it’s too complex. Break it down and distribute. The Constitution is a small, relatively simple document. The IRS tax code is a large, complex document.

I’m constantly at war with myself and other forces to “get the simplest thing that can work” up and running quickly and at the same time not writing absolutely shitty code that has to be massaged a week later.

Actually, it’s not the massaging that I mind — I like refactoring code. What bothers me is it never feels like there’s enough time or emphasis given to creating time to go back and refactor. It’s always about moving forward and making it work, regardless of the quality of work being done. So long as it looks good on the outside.

It feels like the only real option I have is to “slow down.” I think this coming week I’ll do that. Slow down, but remain steady. Slow and steady.

I wasn’t aware I needed to make my Internet Explorer professional. Really, I wasn’t.

What I find interesting is that they didn’t include, oh, I dunno, a JavaScript debugger in there.

This trick was shown to me just a few days ago and it’s been so helpful I thought I’d share it:

Hold down CONTROL and scroll with your mouse (or trackpad) and the entire operating system will zoom in!

Here’s a screen cast showing this in action!

This is probably the easiest way to turn Rails’ acts_as_tree structure into a select field:

HTML:

<select name="category_id">
  <%= expand_tree_into_select_field(Category.top) %>
</select>

Ruby helper:

def expand_tree_into_select_field(categories)
  returning(String.new) do |html|
    categories.each do |category|
      html << %{<option value="#{ category.id }">#{ '&nbsp;&nbsp;&nbsp;' * category.ancestors.size }#{ category.name }</option>}
      html << expand_tree_into_select_field(category.children) if category.has_children?
    end
  end
end

The Category.top method is simply:

def self.top
  find(:all, :conditions => [ 'parent_id IS NULL' ])
end

Finally, your Category class should implement has_children?:

def has_children?
  children.size > 0
end

That last bit is, of course, optional. You could easily write category.children.size > 0, but that’s not very object-oriented now, is it?

Enjoy!

product.inventory_transactions.sum(&:amount) # ArgumentError: wrong number of arguments...

Why? Because model.relationship returns a modified version of the Array class. The object returned acts very much like (if not identical to) calling Model.find, and accepts most (if not all) of find’s options.

So note that if you are calling model.relationship.sum, you either specify the attribute you’re interested in:

product.inventory_transactions.sum(:amount)

Or, if, for whatever reason, you want to use Enumerable’s sum method, you can convert to a standard array:

product.inventory_transactions.to_a.sum(&:amount)

What’s the difference? Model.relationship.sum is a database operation. model.relationship.to_a.sum is a pure Ruby operation.

You author a Client model. You have an array of clients and you want to call Ruby’s uniq method on them. You define “unique” clients as having the same name. This doesn’t work:

>> c1 = Client.find(1)
=> #<Client id: 1, artist_id: 1, name: "Daniel Waite", alias: "Rabbit", birthdate: nil, created_at: "2008-01-13 13:20:14", updated_at: "2008-01-23 01:03:26">
>> c2 = Client.find(4)
=> #<Client id: 4, artist_id: 1, name: "Daniel Waite", alias: nil, birthdate: nil, created_at: "2008-01-14 23:44:58", updated_at: "2008-01-14 23:44:58">
 
[ c1, c2 ].uniq.size # 2

Being the clever Ruby programmer you are, you quickly modify client…

class Client < ActiveRecord::Base
 
  def ==(other)
    name == other.name
  end
 
end

Satisfied, you run the above code again.

[ c1, c2 ].uniq.size # 2

What the fuck? Frustrated, you go medieval…

class Client < ActiveRecord::Base
 
  def ==(other)
    name == other.name
  end
 
  def ===(other)
    name == other.name
  end
 
  def eql?(other)
    name == other.name
  end
 
  def equal?(other)
    name == other.name
  end
 
end

Huffing and puffing, you carefully run your code again…

[ c1, c2 ].uniq.size # 2

ANGER SHARKS ARE SWIMMING!

But fear not my friend, for you have sought, and so the answer shall be revealed to you…

class Client < ActiveRecord::Base
 
  def hash
    name.hash
  end
 
  def eql?(other)
    name == other.name
  end
 
end

Wearily, you try again…

[ c1, c2 ].uniq.size # 1

Success!

Yes, both methods must be overridden.

You may have never seen it, but the hash method is available to all objects. I’m not quite sure how or why this works, but it does. Rejoice.

**UPDATE**

Russ pointed out that for new or unsaved objects, yes, all you have to override is the eql? method. However, to compare for equality for existing objects (i.e. objects retrieved from the database) you must override both methods.

This makes things more interesting, too. If you wanted to define equality between clients as having both the same name and the same birthdate, you can write…

class Client < ActiveRecord::Base
 
  def hash
    %{#{ name }#{ birthdate }}.hash
  end
 
  def eql?(other)
    hash == other.hash
  end
 
end

And now you have a more complex definition of what equality means. Gotta love Ruby.

I was browsing various “time management” applications and found this doozy of a site by the name of Data Basics. They proudly flaunt this bit of fascist literature…

Control. Compliance. Acceptance. ROI.

I guess the people in charge believe ROI is achieved only by control, compliance and acceptance. What a world…

An avid Rubyist proposes a very interesting #as method. It definitely looks rubyesque, but others disagree, namely James Gray and a bright fellow named Ara.

The original posting that generated a lot of good debate on the merits of such an approach.

The OP’s second attempt at gaining the hearts of others, only to be fucking smashed by Ara. Beautiful.

I don’t mean to be sensational about it, but the code presented by Ara was simply gorgeous. It reeked of solid programming and, more importantly, a fundamental understanding that if you’re resorting to “neat tricks,” you your code needs to be smothered into submission.

That said, I still like the idea of #as. It’s different, and there are some drawbacks (mentioned on the forum), but I think it’s worth feeling out. It’s easy as hell to implement:

class Object
 
  def as
    yield(self)
  end
 
end

So it’s worth trying.

Here are the two examples in question.

Ara’s suggestion (”traditional” method, in my mind):

guesses = stems.map{|stem| "#{ stem }.#{ guess_extension stem }"}
basenames = transform2 source_files + transform1(guesses)
expanded = basenames.map{|basename| File.join dir basename}

FC’s suggestion with #as:

expanded = stems.map { |stem|
  "#{ stem }.#{ guess_extension stem }"
}.as { |guesses|
  transform2(source_files + transform1(guesses))
}.as { |basenames|
  basenames.map { |basename|
    File.join dir, basename
  }
}

Now, I will not use curly braces for multi-line blocks. Forget about it. Here’s what it looks like with do…end.

expanded = stems.map do |stem|
  "#{ stem }.#{ guess_extension stem }"
end.as do |guesses|
  transform2(source_files + transform1(guesses))
end.as do |basenames|
  basenames.map do |basename|
    File.join dir, basename
  end
end

Not so pretty, is it? It’s definitely less sentence-like than with curly braces.

In the end I suppose it comes down to style and being flexible. If I were so dead-set against { and } for multi-line blocks I could definitely see using it. On the other hand I question my conviction in that area… is it worth missing out on a potentially useful feature just to follow dogma?

Programming. It’s definitely an art.