Pennyworth Only

On Interface Gems

Wed, 07 Jul 2010 21:04:00 -0400

Some members of Boston.rb had a great discussion at last night’s hackfest about library dependencies. In particular, we were discussing the problem of libraries (gems) that depend on other libraries and how Rubygems and Bundler both promote implementation dependency instead of interface dependency. “Interfaces? We don’t need no stinkin’ interfaces!” I hear you cry. It’s true: Ruby doesn’t have interfaces in the same sense Java does, but it certainly has them in the object-oriented sense. We generally call them APIs.

Take the following scenario: you’re building a web application that you will deploy in a Java container, so you’re running on JRuby. You want to integrate with Twitter, so you add the twitter gem, which in turn depends on the yajl-ruby gem for JSON parsing. Sadly, yajl-ruby is C bindings for JSON. What you want to use is json-jruby, but you would have to fork the twitter gem to make it use that. It’s not just that yajl-ruby and json-jruby have different APIs — indeed, they don’t differ by much — it’s that the dependencies are declared in the .gemspec files, so even monkey-patching can’t save the day.

This is precisely why Eric Gamma (one of the Gang of Four) says you should, “program to an interface, not an implementation.” (See this interview.)

Interface Libraries

If twitter depended on an interface instead of an implementation, you would be free to use any implementation you wanted so long as it abided by the interface. But how, exactly, do you write an interface in Ruby?

Rubygems and `provides`

In a recent post, Marcin Kulic discusses this and other dependency problems in the Ruby/Gems landscape. His recommendation is that we add #provides to Gem::Specification and use it like so:

Gem::Specification.new do |gem|
  gem.name = "my-json-implementation"
  gem.version "2.7.4"
  gem.provides "json", :version => "<= 1.2.0"
end

This is a fine idea in theory, but Nick Quaranto pointed out that modifying Rubygems is exceedingly difficult and it raises backwards-compatibility problems. Additionally, there are naming issues, since the first implementation of a set of functionality (JSON, YAML, LDAP, Twitter API) usually takes the most obvious name for the interface.

Bridge Gems

Michael Bleigh, in writing OmniAuth, a Rack-based authentication provider, found he needed JSON parsing, but he didn’t want to depend on a specific implementation precisely because he didn’t want to dictate what the clients of his gem should use. To scratch this itch, he created multi_json, which uses the Bridge Pattern. multi_json declares only two methods: MultiJson#encode(object) and MultiJson#decode(json_string). It has a number of “engines” that it can use. If you want to write a JRuby-based web application that uses OmniAuth, simply declare your dependency on json-jruby and then set the engine appropriately.

Pre-definition and Post-definition

For functionality that already exists in several implementations — JSON encoding and decoding, LDAP access, &c. — the mission of an interface (either the “provides” version or the bridge gem version) is clear: extract out the most salient pieces of all the popular implementations and give them a common API. For functionality that does not yet exist — for example, the client API for a new web service — the interface builder is faced with a difficult decision: define the interface first or extract it later?

Pre-defining the interface has one key advantage: clients of the interface can easily depend on the interface rather than an implementation, so there won’t be a mad rush to change all the gems in the wild later. It also has a disadvantage: it reeks of premature decision making. Waiting to define the interface until several competing implementations have sprung up allows the interface writer to select only the most important aspects of the libraries.

Of course, in the real world, it is likely to be a mix. Perhaps you start with an implementation, try it out on a few projects, build a first version of an interface, and iterate on both. Interfaces, after all, can be versioned just like implementations. Of course, we hope they don’t change too often.

Core Principles of an Interface

Above all, semantic versioning is key to building a great interface. Included in semantic versioning is proper use of deprecation. Any method, class, or module that is to be removed must first be deprecated in a minor or patch version and can only be removed in a major version.

Secondly, interface writers should take input from the community on the API. Perhaps the easiest way to do this is to inspect the popular implementations in a category on Ruby Toolbox for commonalities.

And, of course, only build interfaces where they’re truly necessary. Out of the thousands and thousands of gems in the wild, very few provide such core functionality that they are used by libraries that are in turn used by applications. Let’s keep in mind the problem we’re trying to solve and not go interface-crazy.

How to Build an Interface Gem

What does it mean to make an interface gem? multi_json is certainly a good start at a JSON interface. It provides core functionality (just two methods, #encode and #decode) and makes it easy for the client to plug in new engines. The Boston.rb group decided that a truly great interface gem would have at least one additional feature, though: an easy way for implementers to test the compliance of their implementations. This will vary in practice, but it might be an Rspec macro:

require 'multi_json/spec_macros'

describe MyJSONImplementation do
  subject do
    MyJSONImplementation
  end
  it_should_implement_json(:version => 1.0)
end

Or it could be a Module that gets mixed in to a test class:

require 'multi_json/test_support'

class MyJSONTest < Test::Unit::TestCase
  include MultiJson::TestCase::VersionOnePointOh
  def subject
    MyJSONImplementation
  end
end

In either case, the important point is that implementers have a dead-simple way to add a whole suite of compliance tests. One thing we discussed at the hackfest was creating an rspec_rfc gem that supports SHOULD, SHOULD NOT, MUST, and MUST NOT language so implementers could distinguish non-compliance (fails at least one MUST or MUST NOT), conditional compliance (passes all MUSTs and MUST NOTs, but fails at least one SHOULD or SHOULD NOT), and compliance (passes all). The problem here is that Rspec already uses should to mean what RFCs call MUST.

The other improvement that should be made to multi_json, and is important for all interfaces, is very thorough API documentation. multi_json only defines two methods, but the API contains more than method names. Parameter types, return types, possible exceptions, yielded block, yield params, and yield return values are all important. The current documentation for #encode and #decode looks like this:

# Decode a JSON string into Ruby.
#
# Options
#
# :symbolize_keys :: If true,
#    will use symbols instead of strings
#    for the keys.
def decode(string, options = {})
...

# Encodes a Ruby object as JSON.
def encode(object)
...

It should probably look like the following (and, yes, I will be submitting a patch):

# Decode a JSON String into a Ruby Object.
#
# @param [String] string the object in JSON representation
# @param [Hash, nil] options additional options
# @option options [true, false] :symbolize_keys if true,
#         will use Symbols instead of Strings for Hash keys
# @return [Object] a Ruby Object
# @since 0.0.1
def decode(string, options = {})
...

# Encodes a Ruby Object as a JSON String
# 
# @param [Hash, Array, Numeric, String, Symbol, #to_json] object a
#        Ruby Object to be converted to JSON. Each object in
#        the graph must be a Hash, Array, Numeric, String, or Symbol
#        or declare a #to_json instance method.
# @raise [NoMethodError] if any object in the graph cannot be
#        translated into JSON.
# @return [String] the Ruby Object as JSON
# @since 0.0.1
def encode(object)
...

Ideal Candidates

Good candidates for interfaces tend to meet the following:

provide functionality that is used by libraries more than applications
some external definition of correctness of functionality
the potential for or existence of a variety of implementations

The three categories that come most easily to mind are formats (JSON, YAML, Markdown), protocols (LDAP, OpenID, HMAC, AES), and API clients (Twitter, Flickr, Delicious).

(Later: not ten minutes after posting this, I came across Yehuda Katz’s Moneta, an interface for key/value stores. Like multi_json, moneta is a great example of a bridge gem, though it could use some of the same improvements that multi_json could, namely providing implementers a test suite and having thorough documentation on the API.)

On Stifling Innovation

One criticism of interfaces is that they stifle innovation. It’s harder for me to write a truly new way of using LDAP if I have to comply with an interface. This is certainly a valid concern. The mitigation strategy should be extreme care in writing and curating interfaces. Don’t write one unless there’s an obvious need, and when you do write one, require only as much as you truly need for basic functionality. People can always depend on a specific implementation if they need more than the basics.

Power-Law Distributions and Code Metrics

Tue, 08 Jun 2010 13:53:00 -0400

Existing Metrics Tools

The Ruby community has a wealth of tools to measure code:

Saikuro for cyclomatic complexity
rcov for code coverage
churn for finding code that changes a great deal over time
Flog for finding complex code
Flay for finding duplication in code
MetricFu, which packages many of the other metric tools together

The Power-Law Problem

The underlying behavior that these tools measure tend to lie in power-law distributions. Perhaps 80% of your classes have 100% (or near-100%) code coverage, but 20% have less than 50%. Or maybe the cyclomatic complexity of 80% of your methods is less than 5, but 20% of them have a complexity greater than 16. The problem is that describing the mean or median of a power-law distribution is nearly meaningless. The reason is that the small number of instances at the head of the distribution share very little in common with the many that compose the tail.

The problem, thus, is not that we’re measuring the wrong things, but that we’re reporting the wrong measurements. If you look at a graph of mean-code-complexity over time and see that it is slowly but steadily getting worse (increasing), you can’t tell whether the bulk of your code is getting worse or whether there’s one particular module that is accruing all the technical debt. In the former case, you almost certainly have a communication or process problem; in the latter case, you might be doing everything perfectly and simply have to plan for a future refactoring.

The Reporting Solution

Instead, power-law distributions are better described by the mean and/or median of the “head” (generally 20%) and “tail” (generally 80%) groups. Thus, each metric should have three configuration options:

bulk_delimiter: the dividing line between the “head” and “tail” groups. Defaults to 20%.
a head_min, head_max, or head_range for the ideal values for the “head” group. Default depends on the metric in question, but might be <= 50 for Flog.
a tail_min, tail_max, or tail_range for the ideal values for the “tail” group. Default depends on the metric in question, but might be <= 10 for Flog.

Implications

What we have to change: the reporting of metrics we’re collecting. MetricFu’s graphs should have two lines for each metric. RCov’s coverage reports should have a divider between the “head” and “tail” groups and summary information for each.

What we don’t have to change: the collection methods. The hard part of these metrics libraries is the instrumentation of code and collection of data. Fortunately, we don’t have to change any of that. (NB: I haven’t actually read through all of the code for the above projects, so this isn’t actually a guarantee. I can, however, be fairly certain that we can keep at least 80% of the code :) )

The Stuff of Stuff

Thu, 20 May 2010 00:54:57 -0400

A beautifully-laid out piece of analysis from Steven Pinker’s The Stuff of Thought on how the brain models stuff:

At first glance, the conceptual distinction between an object and a substance seems to be captured in the linguistic distinction between a count noun and a mass noun. Count nouns, like “apple” and “pebble,” tend to be used for bounded hunks of matter. Mass nouns, like “applesauce” and “gravel,” tend to be used for substances without their own boundaries. The two types of nouns are sharply distinguished by the grammar of English. We can enumerate and pluralize count nouns, but not mass nouns. When we refer to quantities, we have to use different quantifying words: “a pebble” is fine, but “a gravel” is not. We talk about “many pebbles” but not “many gravel,” and we talk about “much gravel” but not “much pebble” or “much pebbles.” And mass nouns can appear in public naked: “gravel is expensive,” “I like gravel.” Whereas count nouns generally cannot: “pebble is expensive,” “I like pebble.” An important clue to the mental model behind mass nouns is that, in some ways, they act like plurals of count nouns. They share some of their quantifiers: “more applesauce,” “more pebbles.” Or their ability to appear naked in a sentence: “I like applesauce,” “I like pebbles.” And their ability to appear with spatial words like “all over,” as in “applesauce was all over the floor,” and “pebbles were all over the floor.”

The overlap in grammar reflects a similarity in the way we conceive of substances. The things typically labelled with mass nouns and multitudes, the things typically labelled with plurals, which, together, may be called “aggregates.” Substances and multitudes both lack intrinsic boundaries and can spill out into any shape. They can coalesce: put some pebbles together with some pebbles and you still get pebbles, put some applesauce together with some applesauce and you still get applesauce. And they can be divided. None of this is true of the typical referent of a count noun, like a horse. No one is in doubt as to the boundary where a horse leaves off, and when you cut a horse in half, the result is not a horse.

Where a plural differs from a mass noun is that it is conceived as a set of individuals which can be identified and counted. A singular count noun like “pebble” stands for something that is bounded — delineated by a fixed shape, and not made up of individuals. A plural, like “pebbles,” stands for something that is unbounded and made up of individuals. A mass noun, like “applesauce,” stands for something that is neither bounded nor made up of individuals. All this suggests that our basic concepts about matter are not the concepts “count” and “mass,” but the mini-concepts, “bounded,” and “made up of individuals.” If so, we should see a fourth possibility: things that are both bounded and composed of individuals. We do, indeed. These are collective nouns, such as “committee,” “bouquet,” and “rock band.”

It’s not just nouns that care about boundedness and individuals. Verbs do, too. As we saw earlier, verbs like “pour” require aggregates, like “water” or “pebbles.” Verbs like “smear” and “streak” apply to substances. And verbs like “scatter” and “collect” apply to multitudes. This is because the concept of an action depends on the number and kind of things it affects — as in the difference between “eat” and “drink,” “throw” and “scatter,” “murder” and “massacre.”

The intuitive materials science behind the count/mass distinction assumes a Play-Dough world in which objects are molded out of the substance. Rocks are made of rock, glasses are made of glass, beers are made of beer, cats are made of cat. The model breaks down when an object can’t be construed as having been formed from a scoop of material. A television isn’t made out of something called “television,” so we can’t say that, “a steamroller left television all over the road.” The distinction also breaks down when we put a substance under a powerful enough microscope. We use the word “rice” to refer to a cup of it, a grain of it, or even a fragment of a grain of it, but as we zoom closer and closer, we reach a point at which we aren’t seeing rice any more. Perhaps if humans could see the crystals, fibers, cells, and atoms making up matter, we would never have developed a count/mass distinction in the first place.

The count/mass distinction in our minds is not just unfettered by the object/substance distinction in the world. It is unfettered by the physical world altogether. It is best thought of as cognitive lens or attitude by which the mind can construe almost anything as a bounded, countable item, or as a boundryless, continuous medium. We see this in a distinctive kind of mass noun that does what count nouns usually do. These are mass hypernyms — superordinates, such as “furniture,” “fruit,” “clothing,” “mail,” “toast,” and “cutlery.” Though they don’t refer to a substance — chairs and tables aren’t made out of “furniture” — the words can’t refer directly to the individual objects they stand for, either. They require a special classifier noun, as in “a stick of furniture,” “an article of clothing,” or the general-purpose classifier “piece.”

Holy Jeebus!: Saddened by the heat @lessconf is taking over its speaker lineup

Wed, 19 May 2010 22:13:13 -0400

Holy Jeebus!: Saddened by the heat @lessconf is taking over its speaker lineup:

I was just perusing some of the tweets on the @lessconf twitter stream and started backing up through some of the conversations. Jeebus, it’s crazy-town out there. Several people called the guys at Less out for the fact that the speaker lineup for LessConf is all-male and all-white. Additional…

"The discovery, in the early Web browsers, that reasonably-typeset text [that] embedded simple forms..."

Fri, 07 May 2010 18:22:00 -0400

“The discovery, in the early Web browsers, that reasonably-typeset text [that] embedded simple forms and hyperlinks, and came equipped with a “Back” button, hit the biggest 80/20 point ever in the history of User Interfaces, couldn’t have been predicted by anybody; but it’s as true today as ever.”

- Tim Bray, “HTML5 and the Web”

I'm a Poet?

Sat, 20 Mar 2010 14:22:00 -0400

When a poet’s mind is perfectly equipped for its work, it is constantly amalgamating disparate experience; the ordinary man’s experience is chaotic, irregular, fragmentary. The latter falls in love, or reads Spinoza, and these two experiences have nothing to do with each other, or with the noise of the typewriter, or the smell of cooking; in the mind of the poet these experiences are always forming new wholes.

— T. S. Eliot, The Metaphysical Poets

This sounds a lot like me. Am I a poet? Why can’t I write any poetry? Or does “poet” and “poetry” mean something broader and the work I do is poetry? Or is Eliot wrong?

I like to steal things from writers.

How Bose Lost a Customer for Life

Wed, 17 Feb 2010 14:27:00 -0500

A few years ago, my father gave me a pair of Bose’s QC-2 headphones. They were awesome. I wore them while working at coffee shops, on airplanes, and to get the most out of my Brahms and Decemberists.

Last week, alas, I broke a piece of plastic on one side of the headphones. It’s the bit that slides along the headband and swivels. It’s a pretty key element, especially given that piece of plastic cost Bose less than 8¢ and they charged $300 for the headphones. I knew the headphones were no longer under warranty, but I figured I could buy a replacement. I would’ve been happy to pay, say $10 for this 8¢ piece of plastic.

Bose, however, wouldn’t settle for a profit margin of 12,400%. Nope. The only option they’re willing to give me is to trade in my QC2s along with $100 for a new pair of QC15s. (When I told them I wasn’t interested, they replied, “Apologies, but unfortunately the part you are looking for is not something we have available to sell individually.” Does that mean that actually do have them but are unwilling to sell them?) I’m sure the QC15s are quite spiffy, but my QC2s have a lot of life left in them — if only I could get this part.

Not only do they lose me as a customer, though, they also make an enemy. I’m going to work very hard to build a computer model of the part so that I and others can print their own. Hopefully that will put a dent, however small, in their profits. Every time I wear my headphones out, people ask me what I think of them. I used to give glowing reviews. Now I’ll have nothing but vitriol to offer.

And a final suggestion to every consumer products company out there: if the functionality of your $300 product can be lost for want of an 8¢ piece of plastic, order lots of extras. Send one or two along with the original product and make it easy to order more. Make it dead simple for your customers to like you instead of hate you.

(Later: I do have to give Bose credit for one thing: they responded quickly, both via email and Twitter. Their responses were ridiculous, but at least they didn’t leave me wondering.)

Trash Day and the Fall of Civilization

Wed, 10 Feb 2010 10:51:06 -0500

Today is trash day. That’s the day wherein we gather up all of our banana peels, used dental floss, socks with holes in them, and broken plant pots and put them on the curb for the nice garbage men¹ to collect it. That’s the good part.

Today is also recycling day. That’s the day wherein we gather up all of our wine bottles, empty dental floss containers, and news-magazines-we-never-got-around-to-reading-but-now-we’ve-gotten-the-next-issue-so-why-keep-the-old-one-around-s and put them on the curb for the nice recycling men¹ to collect. The intent is good here — the less plastic that makes its way into the Pacific Gyre, the better off our planet is.

The problem is that in Massachusetts we have a bottle deposit. When I buy a can of Coke or a bottle of Duvel, I pay an extra 5¢ to the state. Then, if I return the empty bottle, I get my 5¢ back. Sometimes I forget about a bottle and it goes into the normal recycling pile. No problem, I’m not worried about the occasional 5¢ and I’m happy for the state to keep it to work down its massive budget deficits.

Except the state doesn’t get it. Every trash day there are roving bands of people with shopping carts who go around and poke through the trash and recycling looking for stray soda and beer bottles. I don’t begrudge them poking through my detritus. I sure don’t want it any more. What I do hate is that they tear open bags of trash and leave them mixed in with the recycling. Now everything has to go into the garbage truck and there’s nothing left for the recycling people to pick up. All my effort of separating my garbage so the human race can live on Earth for an extra 0.0002 seconds is for naught.

All for 5¢.

[1] the three who do my street are all men. I’m sure this isn’t a global phenomenon.

Staff Bio

Thu, 04 Feb 2010 17:34:25 -0500

Some day I hope to have a bio as creative as the ones on the Bandcamp FAQ. For example:

Shawn Grunberger helped negotiate the Peace of Westphalia in 1648. It was nontrivial.

Chuck Lorre Productions, #275: Ask Chuck!

Tue, 02 Feb 2010 11:21:02 -0500

Dear Chuck,
At a recent dinner party, I found myself in an awkward situation when the host, a devout atheist, sneezed between spoonfuls of his gazpacho. Without thinking, I said, “God bless you.” He gave me a withering look and said, as if to a child, “Golly gee, I sure hope he does.” The other guests exploded with laughter, while I imploded with humiliation. To avoid future embarrassment, what is the correct response when an atheist sneezes? Troubled with ahchoo

Dear Troubled,
First, a little background information. Saying “God bless you” following a sneeze is thought by some to have originated in the sixth century in order to protect the sneezer from falling ill to the bubonic plague. Another possible origin is that people once believed that the devil entered the body during a sneeze and saying “God bless you” could help ward him off. Since the plague has killed something like two hundred million people and the words “God bless you” have, in all likelihood, been said countless times to Glenn Beck, we can safely assume the phrase has no real power against germs or demonic possession. What it does contain is simple human courtesy — a means by which we express concern for one another. As to how to respond to a sneezing atheist, well, that’s easy. Simply say, “Sounds like you’re coming down with something; I hope you don’t die and rot in a box.”

An Open Letter to Frank D. Wagner

Thu, 28 Jan 2010 14:47:00 -0500

An open letter to Frank D. Wagner, Reporter of Decisions of the Supreme Court of the United States:

Dear Mr. Wagner:

In reading through the slip opinion of Citizens United v. Federal Election Commission, I noticed a grammatical error. Associate Justice Kennedy, writing for the majority, quotes McConnell, supra, as follows:

Section 311 disclaimers provide information to the electorate, McConnell, supra, at 196, and “insure that the voters are fully informed” about who is speaking… (Citizens United, Syllabus, page 7)

The meaning of insure is generally taken to be “protect against financial loss” rather than “guarantee.” The original author, Associate Justice Stevens, likely meant that the disclaimers “ensure that the voters are fully informed.” The error is repeated verbatim in the opinion on page 52. Both quotes in Citizens United should include “[sic]” indicating the original misuse.

Sincerely,

James Alexander Rosen

"Under the majority’s view, I suppose it may be a First Amendment problem that corporations are not..."

Thu, 28 Jan 2010 12:47:09 -0500

“Under the majority’s view, I suppose it may be a First Amendment problem that corporations are not permitted to vote, given that voting is, among other things, a form of speech.”

- John Paul Stevens, in Citizens United v. Federal Election Commission

"But your children aren’t really yours. They have lives of their own. So when your designs do..."

Thu, 28 Jan 2010 09:56:08 -0500

“But your children aren’t really yours. They have lives of their own. So when your designs do change the world, you have to accept it. You have to say, ‘OK, this was such a good idea, other people took it and ran with it. I win.’”

- Wil Shipley, as quoted in The Washington Post

"If the problem has a solution, worrying is pointless, in the end the problem will be solved. If the..."

Wed, 27 Jan 2010 10:01:47 -0500

“If the problem has a solution, worrying is pointless, in the end the problem will be solved. If the problem has no solution, there is no reason to worry, because it can’t be solved.”

- Zen proverb

dancroak: Electoral College reform. New states have roughly...

Mon, 25 Jan 2010 13:06:06 -0500

dancroak:

Electoral College reform. New states have roughly even populations around 5,617,000 according to the 2000 US Census.

OSX + Multiple Network Locations + Proxies

Thu, 21 Jan 2010 18:20:07 -0500

At work I’m behind a proxy. At home I’m not. OSX provides a nice way to handle that problem: multiple network locations. You can create a location (“work”) with some proxy settings and one (“home”) without, then simply switch between them as you commute back and forth.

Those proxy settings work great for Safari, iChat, and iTunes. They work reasonably well for Firefox (using SystemProxy). What they absolutely don’t work for is scripts run in Terminal. Rubygems? Nope. Git? Nope. Curl? Nope.

The normal solution is to put the following in your ~/.bash_profile (assuming you’re a bash person like me):

export HTTP_PROXY='http://proxy.mycompany.com:80'
export http_proxy=$HTTP_PROXY

That works great at work, but not so well at home. Instead, I recommend this:

export HTTP_PROXY=system_profiler SPNetworkDataType|grep "HTTP Proxy Server"|awk {'sub(/^.*:[ \t]*/, "", $0); print $0;'}
export http_proxy=$HTTP_PROXY

You’ll have to either open a new Terminal tab or run source ~/.bash_profile after you switch locations, but that seems easier than resetting each variable. Does anyone know a way to delay the binding so that when scripts ask for $http_proxy that function gets re-evaluated? If so, please tweet me @jamesarosen.

A Fast Random Lookup in SQL with Conditions.

Mon, 18 Jan 2010 10:37:47 -0500

If you want a random element from a table from ActiveRecord, you might be tempted to do this:

def MyModel.random
  find :first, :order => 'RAND()'
end

That has two unfortunate problems: it’s unbearably slow for large tables, and it doesn’t work on all databases. To fix those problems, you might try the technique from hgimenez’s fast_random:

def MyModel.random
  if (c = self.count) == 0
    nil
  else
    find :first, :offset => rand(c)
  end
end

That works great… until you want to add some conditions. Let’s say you want a random element created in the last two weeks. You might try this:

def MyModel.random_in_last(since = nil)
  if (c = self.count) == 0
    nil
  else
    since ||= 2.weeks.ago
    find :first, :conditions => ["created_at > ?", since],
                 :offset => rand(c)
  end
end

Unfortunately, this goes bang! The problem is that the offset gets applied first, and can point to a row that the conditions exclude. You need to execute the conditions in a sub-query so that by the time the offset is applied, all rows are valid:

def MyModel.random_in_last(since = nil)
  if (c = self.count) == 0
    nil
  else
    since ||= 2.weeks.ago
    find :first, :select => 'recent_models.*',
                 :from => "(select * from `#{self.table_name}` where " +
                            sanitize_sql_array(['created_at > ?', since]) +
                          ") as recent_models",
                 :offset => rand(c))
  end
end

Getting Rails 3 (pre) up on OSX

Sun, 17 Jan 2010 11:49:00 -0500

I sat down to work on the most recent Bugmash. First I followed Yehuda Katz’s instructions on getting started with Rails 3. Those instructions worked great for running an app on Rails 3, but they’re not quite sufficient for working on Rails itself. Here are some pointers for that, as well as a few unresolved issues:

Install the latest MySQL using the DMG version. By default, it installs into /usr/local/mysql, which is fine.
Install the latest PostgreSQL also using the DMG version. By default, it installs into /Library/PostgreSQL, which is fine.
Add /Library/PostgreSQL/bin to your $PATH. You probably want to do this in your ~/.bash_profile or equivalent.
Go to the directory in which you cloned Rails and add a build_options.yml file. In it, place the following:
Run gem bundle -b build_options.yml
Run rake

Most of the tests run so far, but I’m still having trouble getting Rails 3 to actually connect to the MySQL and PostgreSQL databases. I’ll have to work on that.

Lessons in Toilet Paper Engineering

Fri, 15 Jan 2010 21:47:52 -0500

First, a wonderful brochure created by Chris Rugen, author of an equally informative blog post.

Second, two different Squidoo pages.

Third, a new poll (read: marketing campaign) by Cottonelle.

The evidence is clear, folks. Friends don’t let friends hang toilet paper under.

Wine Review: 2006 Calatrava Sauvignon Blanc

Sun, 10 Jan 2010 19:37:50 -0500

Rating	★✩✩✩✩
Winery	Calatrava
Vintage	2006
Country	Colchagua Valley, Chile
Color	White
Name	Sauvignon Blanc
Grape	Sauvignon blanc
Price Paid	$4.00
Good for	foisting off on others at college house parties
Bad for	a bread and cheese plate

Smells a bit of acetone and citrus rind. The most redeeming thing I can say about this wine is that I can drink a full glass of it without feeling ill. Oh, and it does actually have a rather nice heavy texture. Unfortunately, enjoying the texture means you have to taste the wine longer…