Many on the list weren’t even Rails developers and the list of victims was spread across the globe. It is appropriate at least that DHH was at least on the list, though we never saw a response from him.

There are two adages that I believe apply:

You cannot manage what you do not measure.

What gets measured, gets done.

All too often, processes go stale or drift so far from their intent that it becomes a disadvantage to be process-driven.  If you work for such a company or even if you have your own personal processes, consider putting into place a layer where you measure parts of the process.  I don’t know what those measurements would concern, just start measuring something.

Once you have a reasonable set of data points, attempt to perform some analysis to see if you can draw any conclusions.  At a company I worked for in the past, we measured the effectiveness of peer reviews by tabulating documentation defects and code defects detected by the group and by person.  In a separate activity, we measured defects detected by our QA group and ultimately by the customer community.  My point being, we could take all this data and eventually determine our effectiveness and even predict our future performance.  Being able to predict our performance enabled us to estimate and plan much better and thus be more competitive.
If you are a company that suffers from this, you need to swallow the Red Pill and see the truth.  Measured and analyzed processes can become your Morpheus.  If you swallow the Blue Pill, you will almost certainly continue to languish within old, non-value-added processes that lead you into an uncertain future.

You should now be conjuring up an image of Laurence Fishburne gesturing you to come and get some.

This past week I attended the Advanced Rails Studio in Dallas and had a fabulous time. The picture you see is from our lunch outside on Friday — I am in mid-gesture at the near table on the left.

If you have the opportunity to go to one of these studios, I think you’ll both benefit and enjoy it at the same time. The Rails Community is filled with a smart and optimistic bunch of people who are very fun to be around.

The Studio itself was run with amazing attention to detail. I can tell you that I was very well-fed and not just with bottom-feeding food, either. Kudos to Mike and Nicole for making the logistics so automatic.

Unlike my experience at the basic Studio back in January 2006, this one involved much more discussion and debate. Just imagine 40+ knowledgeable developers getting together to share experiences. Of course, there were class notes, but these served mostly as enablements for discussion. Often, the value of the section was not in the notes, but in the discussion.

I do find that I generally am well-versed in most of the content that I see in the course notes. With the number of Rails and Ruby books becoming available and the amount of blog activity its hard not to be informed these days. So for me, the value of the course was in the sharing and reinforcement that I know the latest practices and that I know any applicable heuristics.

Bottom line: highly recommended.

So since we’re looking into this, I thought it might be a good idea to solicit other suggestions for geocoding services and address variants which GeoKit doesn’t already support, but which would be useful to the Rails community.  It appears there will be some refactoring involved, so it makes sense to do a little due diligence by broadening the input process.

So drop me or Andre a note or comment and let us know.

First, the finders will now all accept optional :units and :formula keys to enable you to override the units and formula used by the model by default. This makes it possible to serve distance queries in miles or kms and even to modify the formula used in the query. Overriding the formula might be important if you know the proximity is close and you don’t care about precise accuracy. It might also be helpful in the event that your dataset grows beyond that which would perform using the more taxing Haversine (:sphere) formula.

The second feature is a bit more subtle and edge case-like. If you steer away from our defaults and customize the lat / lng attributes, then the rigin was previously unable to handle taking an instance of those rows that you seek. I made a change to enable it to detect that situation. So now, you can do this. I did find one issue and that’s with the distance_from method which counts on lat / lng. Hopefully, I can add the same introspection and tidy that up as well. This will enable full customization for lat / lng attributes. Of course, you can write your own accessors to get around this, but still…

If you have any additional feedback, feel free to send Andre or I an email.

UPDATE: The update is complete, you can now compare the distance of Mappable instances which customize their lat / lng attributes when running as acts_as_mappable. If you don’t understand what this means, you probably don’t need the feature, so don’t sweat it.

What amused me was that I recognized myself as being an asshole (not a flattering quality).  But then I also recognized myself as being a maverick (much more admirable).  So I’m justifying the former with the theory that to be a maverick, you must also be an asshole.

The trouble with my theory is that if you are going to claim to be a maverick, you need to have the occasional win on your scorecard; mine resembles a golf scorecard (this is to say that low scores don’t win in this case).  Unfortunately, my asshole qualities to some might be considered undebatable.

And so now I subscribe to still another theory: people are a product of their environment.  So see, its not my fault after all…