intertwingly

It’s just data

Rails and Snowmen

People have started to notice that Rails is adding a snowman to their URLs.  There even is now a website devoted to this.

These types of social implications of technical decisions fascinate me.  Here’s some further background that I have pieced together.  I may have some details wrong, corrections welcome.

For starters, Rails by default standardizes on utf-8 for web pages.  As with pretty much everything in Rails, you can change the default, but virtually nobody does.  Utf-8 is a good choice here, and certainly is better than iso-8859-1 or win-1252.

Rails provides the encoding information on the Content-Type header, and on the accept-charset attribute.  Under normal circumstances, this will cause all responses to be encoded as utf-8, across all commonly used browsers.  Yes, including IE.

Most pages in Rails are produced using templates, and generally these templates are not the problem.  Data in those templates typically come from databases, and sometimes data can get into databases that isn’t 100% pure and clean.  In particular, sometimes this data may have encoding errors.  Such errors can easily become visible when that data is displayed in a form.

Browser recovery strategies vary on encoding errors, but often involve displaying a diamond with a question mark in it.

User behavior varies in the presence of such errors, but a common reaction is to switch the encoding.

The trouble starts when the user then proceeds to submit the form.  The net result, with some browsers, is that the data is sent respecting the user’s choice.  In other cases, browsers send the data using the application’s choice.

How Rails will react to encoding other than utf-8 being used depends on the version of Rails, the version of Ruby and a number of other factors.  In some cases, the result is an HTTP 400 response code (Bad Request).  In others, a 500 (Server Error).  In others, a 404 (Not found).  In others, even more misencoded data will make it all the way to the database.

As I said, sometimes the browser will chose to respect the user’s choice.  This is generally only done if it is possible to do so.  As not every character can be encoded using Western ISO Latin1, including such a character in a hidden field has been found to be an effective strategy of forcing the browser’s hand.

Enter the snowman.

In most cases, this is simply invisible metadata that solves a real problem that is otherwise hard to describe and debug.

Unfortunately, it isn’t always so invisible.  Try a query on this page and observe the resulting URI.  This page opted to use HTTP GET in order to make the URI meaningful.  Unfortunately the URIs with the latest version of Rails now have a bit of exposed cruft.

The fact that people care about such things to complain indicates that socialization of the concept of that URIs are to be meaningful is working.  The unfair perception that this is (yet another) workaround for IE has also entered into the debate.

This is a very real problem.  One without clean and comprehensive solutions.  The Rails team is aware of the _charset_ hidden value, but that opens up a different set of problems.

Solutions being discussed to date include renaming the form field, choosing a different character, moving the field to the end of the query, and providing a mechanism to opt out.


Rails 3.0 Release Candidate

Many things have changed since Rails 2.3.x.  Few changes (except for those affecting views and mail) affect existing projects beyond the normal cycle of deprecation.  Lots affect books, and the way you learn Rails.

If you are the type that prefers to learn from a book, there are lots of good Rails books out there.  In all, I would say that the most important criteria is picking a book that matches the version of Rails you plan to be working with on.  Agile Web Development with Rails is available for Rails version 2.x and for Rails version 3.x.

...


Community over Code

Noah Slater: Joining the ASF was an interesting experience for me. I had come from a free software background, and proudly wielded my gnu.org email address around. At some point along this journey, I gave up on my publishing software. There was no other reason for my continued involvement with the project, beyond the fact that I loved being a part of the community. It was, and remains, so vibrant and positive. All of the aggression, and trolling, and arguments I had become used to on the free software lists just didn’t exist. It was comparatively idyllic! It slowly occurred to me that free software misses the point, and so does open source. It isn’t about enforcing freedoms and political agendas. It isn’t about more eyes for shallow bugs. It’s about community. Without a throng of decent, friendly people who are open to new ideas, discussion, and who enjoy collaborating and helping each other, a project like this is nothing. A good community can make up for poor documentation, and lack of features. A good community can make up for anything!

I love CouchDB, but I love the CouchDB community even more.


Feedback Loops

Allen Wirfs-Brock: Web standards are complex software artifacts and like all software, they contain bugs. Sometimes the best way to find and fix compatibility bugs is to implement and deploy the standard on widely used browsers. This generally takes place in the context of early releases such as the IE9 platform preview builds. So, when you as a web developer are providing feedback on such releases you aren’t just providing feedback on a specific browser you are also providing feedback on the new and emerging standards that it implements. Of course, for this feedback to be worthwhile, browser implementers and standards authors need to be able and willing to quickly respond to feedback that identifies significant problems. The rapid response to the ES5 jQuery toString problem and other issues on es5-discuss show how browser implementers and other TC39 members can and do work closely together to create a more compatible and interoperable Web. But it all starts with your feedback, so please keep it coming.


Back in Line

Total weight gain on in the 9+1 days of cruise and travel: 4.6 pounds.  Total weight loss on the 6 days since we’ve returned 4.5 pounds.

I expect some dampening oscillation to occur, but seem to be back on track.


Inventory Checklist

Just got back from a 9 day cruise, with no email, internet, or cell phone.  Recommendations for future preparations:

Expensive lanyards and watches are available; oddly water shoes and card cases were hard to find.