The other day when I wrote about the upcoming dedication of the Waverley Trail, I originally spelled “Waverley” as “Waverly.”  Not long after, in the comments, Brian Del Vecchio pointed out that he thought the spelling was actually “Waverley.”

At first, I was a little embarrassed because I was pretty sure that I had always spelled it “Waverly,” what I’ll call “the short spelling.”

So, I checked online and found that Google Maps thinks the official spelling is “Waverley,” what I’ll call “the long spelling.”  I checked with the MBTA, and the 73 bus is called the “Waverley Square - Harvard Square.”

Oh well.  I decided I had lost a brain cell somewhere and just went back and changed the post to use the long spelling.

But still!

Having grown up in Waverley Square, I found it hard to believe that I had been spelling it incorrectly all my life.  Before I went back and updated the post, I was going to make an argument that people in Waverley Square actually do spell it “Waverly!”

I did find a few people listing their address as “Waverly.”  It actually has its own ZIP code: 02479.  I went through a brief phase in my teens where I would list my return address as “Waverly, MA 02179.”  (It was changed to 02479 sometime in the last ten years or so.)

I also discovered a few local businesses that styled themselves with the short spelling.

Ultimately,  I felt these points didn’t add up to much of an argument, and I relented.

Since I was in the Waverley area today, I asked my mom–my folks still live in the area–how she spells it.  She responded with the short spelling.  So, at least I know why I spell it the way I do.

On the way home, I was pretty sure the Waverley post office used to be adorned with a simple sign that said “Waverly Post Office 02179.”  So I stopped by, only to find that the simple metal sign had been covered by a lit plastic sign featuring the US Postal Service logo and nothing more.

Then I spotted the window! That photo at the top of this post, ladies and gentlemen, the one with the short spelling, is a photo of the window of the United States Post Office in Waverly Square.  And if it’s good enough for the Post Office, then it’s good enough for me!

Now, I should probably try to draw some observation here, like: “this is how place names change over time,” or “now that these names are in databases instead of on paper and in people’s memories, place names might stop evolving,” or “maybe marketing interests will drive the naming of neighborhoods instead of the people in the area.”

No, that would take a long time, and this post has already gotten out of hand.

Instead, I’m just going to give reign to my wicked provincial nature, and heap scorn on all you people who aren’t from here trying to tell me how to spell things! :)

Aron pointed me to Josh Kenzer’s interview last month with Twitter Developer Alex Payne.  The newsworthy bit is that Alex states that Rails applications don’t scale well:

Running on Rails has forced us to deal with scaling issues - issues that any growing site eventually contends with - far sooner than I think we would on another framework.

We’ve actually been told this a lot by Rails folks.  Hopefully, someday the demand for Spotstory will be so great that we’ll have some first hand knowledge on the matter!

Having said that, there are already a couple of areas where we’ve already bumped into issues while using Rails.

Issue 1: Fixtures break down

A single set of fixture data just breaks down after you’ve created a certain number of tests.  I’ve talked about this before and it’s what caused us to create Isolated Fixtures.  So, we innovated our way around that.

Issue 2: The trap of CRUD-is-King

This is an issue we’ve encountered in the past couple of months, and a lot of what we’re doing now is geared towards ameliorating this condition.  But first I should probably explain what I’m talking about!

Rails lets you get a lot done quickly in the sense that you create a model, lots of code gets created generated, and you start seeing features work almost immediately.  Awesome!

Now, everyone warns you that you’ll throw away a lot of this generated code, and you do.  You refactor something here, change the presentation of something there, and you think you’re pretty much done.

But you’re not.  Because what you’ve done (at least in our case)  is expose features in a way that makes sense in terms of pure CRUD, but it has little to do with how regular people think about doing what they want to do.

I think what I’m trying to say is this: since so much of the application is automatically derived from the data model, the interface you end up exposing is tied to closely to the data model.

Maybe if we were more skilled designers we wouldn’t have gotten ourselves into this situation.  Perhaps we needed a better design methodology.

Also, I concede that Rails doesn’t force you to do this, or keep you from fixing the problem.  This is not the end of the world.  Very likely, this is also a problem in other frameworks.

But Rails’ CRUD-is-king mindset does do a lot to steer you down this path.  Again, I’m not saying this is a reason to not use Rails, just pointing out our own experience.

In closing

In closing, we’re happy with Rails and Ruby.  But we also understand that they’re tools, and all tools have their limitations.

I hope we’re not excommunicated from the Ruby on Rails community for this! :)

Google Maps Mania mentioned us today.

I’ll be attending the Waverley Trail dedication ceremony this Friday, April 27, 2007.  The event takes place at 3:30 PM, rain or shine, at Beaver Brook Reservation, 650 Trapelo Road, Belmont.

The Waverly Trail “celebrate[s] the remarkable history of the Oaks and the Waverley neighborhood.”  Beaver Brook Reservation, known colloquially as “Waverley Oaks” once housed enormous oak trees, some reportedly over 1000 years old.

This is where I grew up.  I used to catch crayfish in the brook here.  I’m really excited to learn more about the trail.

On a related note, WalkBoston will be sponsoring a one-hour guided tour of the trail on Saturday, April 28, 2007 at 10:30 PM.  It’s free, but reservations are required.  See here or call 617-367-9255 for details.

Howdy, Spotstorians!  We did a major system update on April 24, 2007 around 11:45 ET.  We hope you enjoy.  This release contains:

• KML support See your Spots in Google Maps and Google Earth!
• Rails 1.2.3 We’ve updated to the latest and greatest Rails!
• Bug fixes Always some bug fixes for you!

KML

You can now view your Spots using either Google Earth or Google Maps.  There are a couple of ways to do this.

Google Maps

Currently, the only way to see a Spot is to provide a URL in the search box.  When Google has crawled the site (the next day or so), you’ll be able to find your Spot in the Google search results.

To see your Spot right now, go to a Spot, take its URL, copy it into the Google Maps search box, and append the suffix “kml” onto it like so:

  http://www.spotstory.com/spots/show/120.kml

To see what this looks like, just click here.

As I mentioned, Google hasn’t sucked our KML into their index yet, but when they do, you should start seeing your Spots appear in Google Maps under the “See user-created content” link at the bottom of the left-hand side of the page.

We’ll let you know when this happens.

Google Earth

To see your spots on Google Earth, you can go to the Spot, and click on the “KML” link under the map.  If you have Google Earth installed, it should load automatically.  (If you don’t have Google Earth installed you can can download it from here.)

You can also right-click to save the content to disk, and load it into Google Earth from there.

Rails 1.2.3

This isn’t a change you’ll notice, but we get a lot of traffic from the Ruby on Rails community, so we thought it made sense to mention that our production environment is now using Rails 1.2.3.  For details, you can see Aron’s great post about his Rails 1.2.3 upgrade travails.

Thank You!

That’s all for this update.  Please let us know if you find any problems.

Thanks to everyone who has contributed to the site either with content, comments, or attention!

When we started working on Spotstory, Aron and I had many conversations like this:

Matthew: “Oh, we should have a feature like [some feature]!”

Aron: “Yeah, and you should be able to get it via an RSS feed!”

Matthew: “Uh, okay … oh, and we could do this thing where we [do some other thing]”

Aron: “Definitely!  Oh, and you should be able to get at it with an RSS feed!”

And so on.

Now, I’ve simplified this conversation a lot to make a point (that is, I’m not implying that Aron’s only contribution to the site’s design was to follow up each statement I made with “and we should make it available with a feed!”)

What I am trying to point out, is that from day zero we made a decision to have Spotstory be as open as possible, and a major aspect of that was to have data bubbling out of all these RSS feeds.

I didn’t quite appreciate this at the time (but I should have, since I’ve long been a “open an API to your software and people will do unexpected things that amaze you” kind of guy.)

Anyway, a couple days ago I was thinking, “It would be cool if we could have a list of recently created Spots in the sidebar of the blog.”

And then it occurred to me: there has to be a WordPress plugin out there somewhere that will do this.  And if there is, I know we have the feed.

If you haven’t already, cast your eyes over to the sidebar and see a happy little list of the most recently created Spots on Spotstory.  It took five minutes–literally–to put it together. (It took longer to write this blog entry!)

Special thanks to Chris Hatcher and his nifty SideRSS WordPress plugin and thanks to Aron, too,  for having the foresight to make sure we did the right thing from the start.

Update

I just realized that if you’re reading this in a feed reader, you won’t see the sidebar!  Oh, the irony.

OpenCoffee is touted as “a place for people who love startups to hang out and meet.”  That pretty well describes OpenCoffee Boston which takes place every Thursday morning from 10:00 AM to noon at Andala Coffee House.  Andala is located in Central Square at 286 Franklin Street, Cambridge, MA.

This event has been going on for a little over a month, and I’ve spent at least a little time at most of them.  The environment is quite friendly, the coffee is quite good, and I always come away having learned a thing or two.

Attendance is generally strong, and has grown slightly since it’s started.  The crowd is mostly made up of web-oriented entrepreneurs, but there are folks with all sorts of backgrounds.  I’ve spotted at least one venture person in attendance.

The coffee is good, the environment is very informal (no name tags!), and it’s easy to pop in and out just to catch up and say hello.  Some people even work away on their laptops through the entire event.

So, if you’re remotely near Central Square and thinking about grabbing a coffee, come on by, meet a couple people, see a demo, hear about a new idea, or just enjoy a cup of coffee!

I was in Harvard Square today, and being a few minutes early for my lunch meeting, I decided to pop into Bob Slate.

I haven’t been in there for quite some time, but I can always count on them to have a wide array of cool notebooks to drool over.

I was not disappointed: witness, in the accompanying photo, what can only be described as a Moleskine bonanza!  Ruled, plain, squared.  So many sizes, aspects, and page counts.

Just thought I’d share.

If you have been following this weblog for a while, you have probably figured out that Spotstory is a Ruby on Rails application.

Over the past few days, I have been working to upgrade Spotstory from Rails 1.1.6 to Rails 1.2.3.

There is very little comprehensive information about some of the problems encountered when upgrading a Rails application from the 1.1.6 release to 1.2 (specifically, Rails 1.2.3).

Once You Freeze, Step Cautiously

Upgrading your Rails application is easy! Update, deploy, then go enjoy your apple pie! Right? Wrong.

% rake rake rails:freeze:edge TAG=rel_1-2-3

So far, so good. Let’s see if anything runs.

rake rails:update --trace
rake aborted!
uninitialized constant ActionController
/usr/local/gems/rake-0.7.1/lib/rake.rb:1948:in `const_missing'
config/../config/environment.rb:32

Why did this happen? Did the Rails installation get corrupted during the upgrade? No. Far, far simpler. On line 31 of config/environment.rb, I had a raw reference to ActionController. Due to major dependency changes in Rails 1.2, this no longer works.

# Rails 1.1.6 technique for setting session expiry:
ActionController::Base.session_options[:session_expires] = Time.mktime(2037)

In Rails 1.2, it appears that this sort of configuration can not appear within the Initializer block. After moving session configuration out of the Initializer block, things started running.

Deprecations & Warnings

I decided that every deprecation message would be squashed and every warning removed. I worked on most of the warnings before even trying to get all our tests to pass; they were just too noisy for my aesthetics.

DEPRECATION WARNING: The :dependent => true option is deprecated and
will be removed from Rails 2.0.  Please use :dependent => :destroy
instead.  See http://www.rubyonrails.org/deprecation for details.
See http://www.rubyonrails.org/deprecation for details. (called from
has_many at vendor/rails/activerecord/lib/active_record/associations.rb:558)

(Yes, that link is actually printed twice!)

These deprecation messages are great — they tell me what has changed and how to improve my code, but they reference source files and line numbers within the Rails core. This is not helpful. I was able to find some instances of deprecated usage by recursively grepping our source (from within Emacs, which makes results electric). Very quickly, I turned to a heavier hammer.

ActiveSupport::Deprecation.debug = true

Toggling this debug variable exposes the full callstack which caused the deprecation message.

Here are the changes I needed to make in order to eliminate all our deprecation messages:

1. Some model helpers have gone away or have changed in call syntax. Rewrite model methods in the following way:
   

   Rails 1.1.6	Rails 1.2.3
   Model.find_first	Model.find(:first)
   Model.find_all	Model.find(:all)
   Model.type	Model.class.to_s
   Model.count(conditions)	Model.count(:all, :conditions => conditions)

2. Has many associations no longer provide the has_ASSOCIATIONs? and ASSOCIATION_count methods. Rewrite:
   

   Rails 1.1.6	Rails 1.2.3
   Model.has_ASSOCIATIONs?	! Model.ASSOCIATIONs.empty?
   Model.ASSOCIATION_count	Model.ASSOCIATIONs.size

3. Rewrite controller/view instance variable references:
   @params, @session, @request, @response all become params, session, request, response.
4. Move to the new form generators.

   form_tag ... end_form_tag

   becomes:

   form_tag do ... end

   The same is true for form_remote_tag references. In addition, the form methods no longer need output-generating RHTML rules (remove the “=”).

5. The link_to helper prefers a different way for specifying that a link will generate a POST operation.

   link_to ... :post => true

   becomes

   link_to ... :method => :post

6. Association dependencies now support more granularity, which means that the old-style:

   has_many ... :dependent => true

   becomes:

   has_many ... :dependent => :destroy

7. Add parentheses and remove whitespace between parens and method names to prevent ambiguity. Not clear why these issues didn’t cause issues in Rails 1.1.6.

Fixing Broken Tests

With our application beaten into quiet submission, it was time to turn to our tests. A good majority of our tests still worked, but a few changes were needed to get everything passing.

1. Content-Type headers now include charset information; make test helpers resilient to the presence of charset.
2. assert_tag with a string value for the :content option now performs a strict match against the content for any sub-tag. As a result, some :content options were converted to regular expressions.

   Determining when a regular expression is necessary is not obvious, especially when the match text is embedded within another markup tag.

At this point, all of our tests passed.

Dependencies

Unfortunately, we weren’t done. The development server would unexpectedly give errors like:

User expected, got User

In addition, our User model would get missing_method errors for methods which clearly exist. The problem is an interaction between the Rails 1.2 dependency rewrite and plugins which have dependencies upon application models. Ramble On discusses a similar dependency issue.

We use a number of plugins in our application. One of these is a customized version of acts_as_commentable. This plugin defines the Comment model and expects a User model to be defined by your application.

In development mode, plugin models are not reloaded. The dependency infrastructure unloads the User model, but doesn’t realize that there are still live references from the plugin-defined Comment model. Subsequent references to a comment’s user information will generate an AssociationTypeMismatch exception giving the cryptic “expected User, got User” message. Because this is a reload problem, errors don’t happen on initial load. The errors start the second time a comment-displaying page is loaded.

Web searching didn’t reveal much at first. Some people recommended explicitly requiring the User model in application code. Others recommended replacing references to a User object with references to its id. Another solution called for explicit :class_name in the association declarations. Some of it worked some of the time; none of it worked consistently.

I started looking through the Rails dependency code and found that Nicholas Seckar (ulysses on IRC and in SVN) was responsible for much of the rewrite. After explaining my missing_method errors in an email, he replied:

See http://api.rubyonrails.org/files/vendor/rails/railties/CHANGELOG.html
Look under the changes for 1.2.0, 4th one down.

This references a late change to Rails 1.2 by Rick Olson:

Ensure plugins are in the Dependencies.load_once_paths collection by default. [Rick] If you really want your plugins to reload, add this to the very top of init.rb:

Dependencies.load_once_paths.delete(lib_path)

Ok. I need to reload my plugins. Bleh. Further, this has to happen in environment.rb, not in environments/development.rb. Bleh.

# Array of plugins with Application model dependencies.
reloadable_plugins = ["acts_as_commentable"]
# Force these plugins to reload, avoiding stale object references.
reloadable_plugins.each do |plugin_name|
  reloadable_path = RAILS_ROOT + "/vendor/plugins/#{plugin_name}/lib"
  Dependencies.load_once_paths.delete(reloadable_path)
end

None of this forced plugin reloading feels right. Rails should just figure it out, yes? More mail to Nicholas, leading to his response:

The problem is related to associations — the class object is cached and thus the class is never garbage collected, even though it is ‘removed.’ This causes all sorts of problems…

Since it only happens in development mode, it really doesn’t matter.

He’s partially right. It doesn’t affect production applications, but it really does affect peace-of-mind. I’m sure lots of people are freaked out when they bring up their upgraded app in development mode and find all sorts of things unexpectedly broken.

Update: I was wrong about the session configuration changes in Rails 1.2. I have updated this post accordingly.

During the early days  of Spotstory (you know, a couple months ago) we started throwing a lot of features at folks.  Usually, we gave these new capabilities a brief mention in the release notes, and then hoped people would find them and use them.

A few nights ago, we were talking to a longtime user (in relative terms!) of the site. I mentioned Locations, and this person didn’t seem to know what I was talking about.  So much for hope!

So, I figured that it was probably a good time to step back and cover some of Spotstory’s features in a little more detail.  Since Locations were the inspiration, I’ll start this series of posts with them.

What is a Location?

So what’s a Location?  It’s what it sounds like: a place somewhere on the planet!  It’s a latitude and a longitude.  They also have a name (e.g. “Parent’s House”, “Home”, “Ski Lodge”, etc.)  That’s it!

Why do I care?

You can think of a Location as a bookmark for the face of the planet.  It’s a way for you to watch a specific place for the appearance of new Spots.  You can even get an RSS feed for the Location which is updated when new Spots appear.

How do I Create one?

Locations are easy to create.  Just go to your home page and click on the edit icon next to ”My Locations,” you’ll find it on the upper right hand side of the page.   From there, just follow the instructions.

You can create as many Locations as you’d like.  Currently, the Locations you create are private. 

If you’ve got any other questions, comments, or suggestions about Locations, or anything else, we always love to hear from you!

I hope you’ve enjoyed this intro to Locations!  I’ve covered most of the details here but there are a few more neat things about them you’ll discover, I’m sure. So get started: go create a Location today for your home, your childhood home, your favorite vacation spot or any other place you fancy!