Pivotal Blabs

Q: How do you keep passwords from appearing in plain text in your Rails log file?

A: Filter Parameter Logging

filter_parameter_logging
=> Does nothing, just slows the logging process down

filter_parameter_logging :password
=> replaces the value to all keys matching /password/i with "[FILTERED]"

filter_parameter_logging :foo, "bar"
=> replaces the value to all keys matching /foo|bar/i with "[FILTERED]"

filter_parameter_logging { |k,v| v.reverse! if k =~ /secret/i }
=> reverses the value to all keys matching /secret/i

filter_parameter_logging(:foo, "bar") { |k,v| v.reverse! if k =~ /secret/i }
=> reverses the value to all keys matching /secret/i, and
   replaces the value to all keys matching /foo|bar/i with "[FILTERED]"

(Note that :password matches password_confirm too.)

Interesting Things

• We're looking for the best search plugins for Trac. Suggestions?
• Rails: We often find ourselves adding and return in our Controllers to avoid the dreaded DoubleRenderError. It turns out that you can use unless performed? instead:

<code>
def double_rendering_action
  render :template => "wrangler/monkey" if wrangle_monkey?
  render :template => "wrangler/sleep" unless performed?
end
</code>

• Textmate Footnotes Plugin in Ruby on Rails will give you hyperlinked error messages that will open TextMate the the appropriate line of code.
• We've released our distributed page caching solution on the Pivotal RubyForge project!

REST. What is it, and how can it be used to design better web applications?

A presentation at RailsConf did me a great service by first pointing out all the things REST is not. It isn't CRUD. It isn't pretty URLs. It is neither a protocol nor an architecture, but it can play a role in your implementation of all of the above. REST itself though, is less concrete than all of that. It is a theoretical framework, a way of thinking about designing distributed software systems. For me, the first step in absorbing its principles is to forget about the database and focus on the fundamentals. This article will start there, then drill down to show how these ideas can help organize the development of your Rails applications.

(Noon: Rest From Work (After Millet) by Vincent Van Gogh)

Interesting Things

• Some projects are playing with the Mocha mocking framework. From their site:

  Mocha is a library for mocking and stubbing using a syntax like that of JMock, and SchMock. Most commonly Mocha is used in conjunction with Test::Unit, but it can be used in other contexts.

• Our own Nathan Sobo has released Treetop 0.1.0:

  Treetop is a Ruby-based DSL for text parsing and interpretation. It facilitates an extension of the object-oriented paradigm called syntax-oriented programming.

• Jeff from Inveneo presented us with a tech-talk recently about the technology they are bringing to rural and remote communities throughout the world. Fascinating stuff. A group here has volunteered to help write some software if needed.

Ask for Help

• "Are there problems getting Rspec mocks to 'reset' for each spec run?" Mocks persist across test/spec runs for class methods, so watch out.
• "My routes arn't working..." Remember that Rails routes are positional, which means that they are matched top-to-bottom; changing the position seemed to be the fix in this case.

Interesting Things

• We are hosting a Geek Session tonight at SF Beta. Tickets are going fast.

Suppose we have some behavior attached to a button's onclick event: when clicked, the button should append "foobar" to the value in the text field with ID "output_field". We might do it like this:

<input type="text" id="output_field">
<button onclick="var textField = document.getElementById('output_field'); var currentValue = textField.value; textField.value=currentValue + 'foobar';">

Inline event handler code such as this is extremely common. It's easy to write, but it's not testable, reusable, or readable, and it's mixed up in the HTML world. The way it is currently, it's hard to think of it as code that can be refactored, added to, abstracted, generalized, etc. Of course, this is a contrived, simple example, and if it were real code, probably not worth worrying too much about. However, we can use it to demonstrate some techniques that we can apply to real-world situations.

Extracting the handler to a function

Let's attack it by considering it from the point of view of testability with JsUnit; very often this can the best way to move forward because it creates a second client to the code that is relatively independent of the HTML DOM. The first step is to extract the onclick event into a function, rather than having it inline:

<script language="javascript">
  function appendFoobar() {
    var textField = document.getElementById("output_field");
    var currentValue = textField.value;
    textField.value = currentValue + "foobar";
  }
</script>

<input type="text" id="output_field">
<button onclick="appendFoobar()">

Notice that even ignoring testability, this is a dramatic improvement. First, we don't a fragment of JavaScript floating around in an HTML element. Second, we have a name for our behavior (appendFoobar) that makes the code more readable: it's now much clearer that clicking the button should write the current date. Third, we can now reuse this code from more than just our onclick handler.

Writing a test page

The second step is to move our function to an external .js file, say appender.js, so that we can write a Test Page:

<script language="javascript" src="appender.js"></script>

<script language="javascript">
function testAppendFoobar() {
  assertEquals("initialvalue", document.getElementById("output_field"));
  appendFoobar();
  assertEquals("initialvaluefoobar", document.getElementById("output_field"));
}
</script>

<input type="text" id="output_field" value="initialvalue">

Our test is for our extracted function: our test, rather than the button element, calls our extracted function.

Injecting DOM dependencies

Now that we have a green test, and code that we can actually read, we might want to consider the following refactoring. The code and test both go out and grab an element from the DOM with a certain ID. The code would be more self-contained and reusable if rather than going out and finding the DOM element, we instead passed it in to appendFoobar. That is, we could inject the dependency on the DOM element:

function appendFoobar(textField) {
  var currentValue = textField.value;
  textField.value = currentValue + "foobar";
}

function testAppendFoobar() {
  var textField = document.createElement("input");
  textField.value="initialvalue";
  appendFoobar(textField);
  assertEquals("initialvaluefoobar", textField.value);
}

<button onclick="appendFoobar(document.getElementById('output_field'))">

Extracting an object

Let's do one more refactoring: objectifying our code. Obviously, at this point our simple example doesn't warrant this refactoring, but let's keep going to illustrate the point. We'll use prototype.js to keep things simple:

Appender.prototype = {
  initialize: function(textField) {
    this.textField = textField;
  },

  appendFoobar() {
    var currentValue = this.textField.value;
    this.textField.value = currentValue + "foobar";
  }
}

function testAppender() {
  var textField = document.createElement("input");
  textField.value="initialvalue";
  var appender = new Appender(textField);
  appender.appendFoobar();
  assertEquals("initialvaluefoobar", textField.value);
}

<button onclick="new Appender(document.getElementById('output_field')).appendFoobar()">

Summary

Our code has come a long way from being an inline event handler, muddled up with HTML code. In its new form, it's the kind of code that many developers are more comfortable working with. By aggressively refactoring even simple event handlers with these techniques, we can make working with our JavaScript a far more pleasant experience.

(Blabbers who were at the conference, feel free to add your links to this post.)

• Alex's RailsConf2007 Flickr set
• railsconf2007 Flickr tag (notice all the band pix :-) )
• Parker's Flickr Set
• Martin Fowler's bliki post on RailsConf
• Tim Bray on the band

Interesting Things

• Rails gotcha: with ActiveRecord.findXXX, you can specify query parameters such as :group_by, :limit, and :include. But if you use those three together Rails will generate an incorrect query.
• Rspec 1.0 has been released.

Ask for Help

*"Can you use the Venkman Javascript Debugger to debug programatically-loaded JS, files that are actually hosted by a 3rd party, such as Yahoo!?" We don't think so, but if anyone in the community has an answer, let us know.

It was fate. A crew of Pivots in Portland on the same weekend as the Extra Action Marching Band We just had to seize the opportunity...

Will they be making an appearance at our Beer Night tonight? You never know...