I ran into a couple snags when upgrading, but doing the following solved my problems:
The following allows you to get rid of the numerous “Model.find(params[:id])” calls in your controllers. I’m pretty sure I’ve seen similar solutions out there, so if anyone wants to link to those in the comments that’d be helpful.
Read the rest of this entry »
function remove_defaults(){
$("input[@type=text]")
.each(function(){
this.default_value = this.value
})
$("input[@type=text]")
.focus(function(){
if(this.value == this.default_value) {
this.value = ""
}
})
.end()
}
$(remove_defaults)This is meant to save me from having to write the same boilerplate profiling code over and over.
By default, it creates an HTML graph and saves it to RAILS_ROOT/ruby-prof/profile.html .
The method url_path is a convenience method for saving your HTML graph to a location based on the URL used.
To use, add the below to lib , then add “around_filter RubyProfHelper” to whatever controllers you want to profile. Then go to the URL you want to profile and add profile=true to the query string. You should probably ensure that this can’t be run by any schmoe in production. Also, you’ll probably want to have your SCM ignore the ruby-prof directory.
If you want to get more fine grained with your filter, use the following:
RubyProfHelper.run("output_file_name.html") do
code_to_profile(here)
end
When you visit the corresponding URL, *leave out* profile=true
from the query string.
This arguably needs to be a plugin, but I find it more
straightforward as a /lib addition.
class RubyProfHelper
class <<self
def filter(controller, &block)
return (yield block) unless controller.params[:profile]
# Instead of "profile.html" you can try url_path(controller),
# which will return a file path based on the url visited
run("profile.html", &block)
end
def run(output_file_name = "profile.html", &block)
require 'ruby-prof'
RubyProf.start
yield block
result = RubyProf.stop
printer = RubyProf::GraphHtmlPrinter.new(result)
# create directory
dir = File.join(RAILS_ROOT, "ruby-prof")
FileUtils.mkdir_p dir
file_path = File.join(dir, output_file_name)
f = File.open(file_path, "w+")
printer.print(f)
end
# will evaluate to home.html or something like
# products.html
# products/2.html
def url_path(controller)
if controller.request.path =~ /\/$|^$/
"home.html"
else
controller.request.path + ".html"
end
end
end
end
Recently, while working on designerpages.com, I wrote some smelly code. My task was to add the “change category” feature to the home page’s product wars, shown below. To do this, I needed a controller to receive the “change category” AJAX request, then set a session variable and return the code for refreshing the product war.
The stink arose from the name I chose for the controller, ProductWarsController. This might seem like an OK name, but it’s not, and after a short detour I’ll explain why.
Steven Pinker’s latest book, The Stuff of Thought: Language as a Window into Human Nature, introduced me to the term polysemy:
Polysemy refers a word’s having a number of distinct but related senses… the senses of a word are so tightly linked that it takes a linguist or an artificial intelligence researcher to spot the difference. here are some examples:
- Chicken can refer to a kind of animal (Why did the chicken cross the road?) or a kind of meat (Try it, it tastes like chicken!).
- Construction can refer to an event (The construction took nine months), a process (The construction was long and noisy), a result (The construction is on the next block), or a manner (The construction is shoddy).
While polysemy is fascinating and even entertaining1 when it occurs in the English language, it can easily lead to confusion in code. Code polysemy occurs when you use a name that appears consistent with your existing body of code, but whose meaning (behavior) actually differs in a subtle way. Users (you and other programmers) will expect your code to behave in one way, and when it doesn’t they’ll have to waste time figuring out what it actually does. Because the difference between expected and actual behavior is slight, and because the unexpected behavior is still related to the name you gave it, it’s easy to leave the mistake uncorrected.
Which brings me back to my stinky code. On Designer Pages, Product War has multiple, related meanings. It can refer to a model and it can refer to the actual Product War being displayed on the home page. The new controller ProductWarsController was meant to be related to the product war being displayed. However, under Rails conventions ProductWarsController should be related to actual Product War records. The resulting clash was confusing - the “update” action didn’t actually update a record, which is the expected behavior; rather, it changed which Product War would be used on the home page. What a disgusting hunk of effluvium.
The solution was to change the name ProductWarsController to ProductWarDisplayController. And now my code smells like roses.
1Pinker points out that polysemy also “arises when a word is used to refer to something that is merely associated with its usual reference… i.e. when one waitress tells another The ham sandwich wants his check.”