has_many :thoughts

Rather simple actually… since ActionController::Base.layout takes a proc, and calls it upon a request.

class ApplicationController < ActionController::Base
  def self.without_layout_on_xhr
    layout proc { |controller| controller.in_popup? ? nil : "application" }
  end

  def in_popup?
    request.xhr?
  end
end

class BusyWorkController < ApplicationController
  without_layout_on_xhr

  before_filter :login_required

  def new
    @work = Busy.new
  end
end

I’ve abstracted out the conditions for rendering without a template based on the controller instance method #in_popup?. Feel free to change it to whatever you want.

When the merger of Merb and Rails was announced a few months ago, I don’t think anyone really expected the goal of having Rails 3 released at RailsConf to be met. Alas, it was not. But David announced today that much of the groundwork to combining the two frameworks has already been done. Most of the work has been behind the scenes refactoring—the kind of changes that developers will likely never notice. But other features that are in the codebase and coming soon include:

• An all-new router, with an improve DSL that’s more merbish. It will include routing based on subdomains and user gents, and the ability to mount multiple apps side by side.
• Since many developers aren’t consistently using the h() helper method to escape potential script injections, the default behavior will now be to escape everything except when an all-new raw() method is utilized.
• Much of the code to make Rails JS framework agnostic is complete. New features include using data=remote=”true” and data-method=”delete” (which validate in HTML5) to allow unobtrusive binding of JS events.

David equated the new Rails philosophy to Burger King’s “Have it Your Way” concept. If I want a great burger, I can order a Whopper. But, if I have specific tastes, I can order it without pickles. Or with extra ketchup. Rails will allow you to get a great framework out of the box for users that just want it to work. But, for those that are passionate about a particular JS framework or other toolset, they can freely customize their Rails.

Toward the end of David’s keynote, he relayed a couple experiences he’s had. He reminded us to make sure that, as developers, we don’t accept the requirements bestowed upon us by stakeholders at face value. We need to constantly offer up alternatives and input. In his experience, many times when you relay to the stakeholder a different, sometimes lest costly, way to do things, their response is often: “Sure, whatever”.

This approach can save we developers hours of wasted time. That’s because, when stuck on a tough challenge, as time drags on, our motivation drops. We try to keep up our spirits but, when it looks like the challenge is impossible, we end up burning needless hours. We should quit at the point our mind checks out and reexamine the problem. David gave an example of a tough issue he worked on for two weeks and he explained that only a week and half of it he was really working and after that the rest was just goofing around because he already had given up. He should have gone back to stakeholders right then rather than burning a few more days with zero motivation.

Last Friday, a good chunk of our team spent a while debugging a problem afflicting some sites on one of our shared hosting machines.

After a bunch of red herrings, some TCP dumps determined that the sites in question were all hung up on numerous DNS requests. That led us to the call to a web service we use on the sites in question. As it turns out, the IP geocode service being called, HostIP.info, was completely down. (It’s free; you get what you pay for.)

We assumed this couldn’t be the case, since those calls are wrapped in a Ruby Timeout calls with a maximum of 2 seconds each (Timeout.timeout(2)). Well, apparently, Ruby Timeout just doesn’t work sometimes.

Big props to Andy for sleuthing that down. And bigger props to Philippe Hanrigou for writing that very detailed article where he says, specifically:

“In particular, initiating network connections and/or a broken or slow DNS server will typically block the whole Ruby process while the call completes.”

Bingo! We’re going to try Philippe’s library on these projects and others in the future when we need guaranteed timeouts.

Please Note: This is bitching. I’m a nit picky kinda programmer. I pull things apart, rip out what I hate and go nuts over it so I remember to never do it again. This is a rant, your warned.

I’m not too happy with a lot of things going into Rails lately, outside of the stuff that they are learning about through other frameworks. Some additions have been made to Rails lately that are bringing it further from Ruby, into its own language.

Many people already believe that “Ruby on Rails” is a language in and of itself. I guess they believe that the “Ruby on” part is just a cool name. Frankly, some commits as of late could possibly be developing that language.

Array#second, #third, etc.

When I first learned scripting languages I learned Python, and I still love Python (despite having no current use for it). Even back to my C/C++ days I enjoyed Array indexing as Array#[] (in ruby terms). Whats so hard about an integer (0..n) being used between them? How else do you easily modify them into Ranges…. well Rails has solved all of this for us!

Array#first, plus now Array#second, #third, #fourth. Our playboy even says he’s found a way of “massive savings in overhead” for something Ruby never had a need for in the FIRST place.

Object#try

Object#try is another one. Again, something Ruby and Matz never put into the language itself. That doesn’t stop Rails from developing it into its own language.

Object#blank?

Ever try to bring a script over from Rails, and find yourself rewriting #blank?. Sure, I love blank, it saves time right? But where’s the Ruby in a method that was never originally intended to be monkey patched into the language itself?

My Point

My point is, there are other frameworks that try to keep this sort of thing to a minimum. The benefits are countless, and I think the best are…

1. Monkey patching is kept to a minimum. If you don’t understand the danger in monkey patching, please don’t ever read a blog entry I write again.
2. Lowered need of detailed attention being required when transferring code to other frameworks and platforms
3. Less lines of code within your code base, required pieces.
4. Universal code that is understandable by anyone using the original language.
5. Learning the appropriate methods the first time around
6. Not having to re-implement if you find yourself without one of these methods

Now I’m not against these sorts of things completely, and there are frameworks that implement them correctly (Merb and DataMapper’s combined ExtLib library being one of them).

I’m just not impressed by the magic tricks anymore, and tired of seeing Rails core become the bastard child of someone’s personal “good ideas”. Just because your doing it in your projects doesn’t mean it should be forced down my throat.

Below is the schedule I came up with when going over the sessions available this year at RailsConf… Going to try to make these, if not switch with Colin so we cover the conference well… very glad to see some advanced classes! Would have loved a REAL advanced Rspec session though.

8:30am Thursday, 05/29/2008
Meta-programming Ruby for Fun & Profit Portland Ballroom 252
Neal Ford (ThoughtWorks), Patrick Farley (ThoughtWorks) Ruby is the revenge of the Smalltalkers. Not since Smalltalk has a language had such powerful meta-programming facilities. While this may seem like a minor feature, it turns out that surgical meta-programming allows solutions to problems that are clearer, more concise, more maintainable, and take orders of magnitudes fewer lines of code. Read more.

1:30pm Thursday, 05/29/2008
Powering AIR Applications with Rails Portland Ballroom 252 Tony Hillerson (EffectiveUI), Daniel Wanja (Nouvelles Solutions, Inc.) Adobe’s AIR platform offers developers familiar with web technology the tools to create desktop applications. Come and learn how to drive an HTML and a Flex AIR application with Rails using RubyAMF. Read more.

10:45am Friday, 05/30/2008
Entrepreneurs On Rails Portland Ballroom 251
Dan Benjamin (Rails Machine) Many of the people working with Rails are independent developers, doing freelance work or running small development shops. This makes sense – Rails provides a great framework for an indy developer, making it easy to work with with designers and other developers. Read more.

11:45am Friday, 05/30/2008
Hosting and the Woes Portland Ballroom 255
Ezra Zygmuntowicz (EngineYard), Jamie van Dyke (Engine Yard), Tom Mornini (Engine Yard) What are the day to day issues with Rails hosting. How can they be solved, and what are the best practise methods of avoiding them. Engine Yard have extensive experience with high volume Rails applications and would like to talk about what we’ve learned and what our customers have learnt. Read more.

1:50pm Friday, 05/30/2008
Faster, Better, ORM with DataMapper Portland Ballroom 256
Yehuda Katz (EngineYard) This session will cover using the DataMapper ORM with Ruby on Rails, and go in-depth into its code. It will focus on integration with Ruby on Rails and provide an advanced-level overview of the codebase and design philosophy. Read more.

2:50pm Friday, 05/30/2008
Rubinius – Under the Hood and Behind the Curtain D135-136
Evan Phoenix (Engine Yard), Brian Ford (Engine Yard), Wilson Bilkovich (Engine Yard) Rubinius is a virtual machine built from the ground up to provide a robust, high-performance runtime for Ruby code. The Rubinius team is guiding the development of 20,000+ specifications that define the Ruby language. Read more.

4:25pm Friday, 05/30/2008
The Launch: Dos and Don’ts of Real Life Deploys Portland Ballroom 255
Chris Wanstrath (Err Free) There’s more to launching an app than “cap deploy”—the process is as much a psychological challenge as a technical one. So, what does it take to launch an app you can depend on and be proud of? With a handful of production launches under his belt, Chris will talk about the big picture and little details of bringing your site to life. Read more.

10:45am Saturday, 05/31/2008
Assembling Pages Last: Edge Caching, ESI & Rails Portland Ballroom 256
Aaron Batalion (Hungry Machine LLC) When working on scaling Rails to millions of users/day with complex personalization, caching becomes essential. This talk will cover edge caching, edge side includes (ESI) in Rails, and partial page caching higher in the stack. It will also cover ESI as a fabric for assembling heterogeneous applications into a single, cacheable web experience. Read more.

11:45am Saturday, 05/31/2008
Advanced RESTful Rails Portland Ballroom 252
Ben Scofield (Viget Labs) Designing RESTful systems in Rails carries many benefits. It is not a problem-free approach, however; there are accessibility issues with the standard conventions, and some functions are more difficult to map to resources than others. In this session, we’ll look at solutions for these (and other) problems that arise when you take REST beyond the standard examples. Read more.

1:50pm Saturday, 05/31/2008
Build Your Own Distributed, Self-Configuring Rails Cluster Portland Ballroom 251
Dave Fayram (Powerset, Inc), Tom Preston-Werner (Powerset, Inc.) Fuzed is a Rails server stack written in Erlang that can replace standard mongrel/reverse proxy architectures. It focuses on reliability and ease of deployment in distributed environments. Read more.

2:50pm Saturday, 05/31/2008
Custom Nginx Modules: Accelerate Rails, HTTP Tricks General Portland Ballroom 251
Adam Wiggins (Heroku) Got a Rails app that needs even more speed? Adam Wiggins of Heroku will show you how to write a custom Nginx module to bring blinding speed to critical code paths (and do HTTP tricks that can’t be done with Rails and Mongrel alone), using examples from Heroku’s own authentication module ngx_heroku_gate. Dust off your C compiler and prepare to push the limits of nginx, Rails, and HTTP. Read more.

4:25pm Saturday, 05/31/2008
Metaprogramming and Ruby Internals for Rails Programmers Portland Ballroom 256
Patrick Farley (ThoughtWorks) Rails programmers are Ruby programmers. In this session we’ll cover some useful Ruby metaprogramming techniques as used in real world Rails applications and extensions. Then we’ll dig deep into MRI and JRuby source to gain a nuanced understanding of the implementation details of Singletons, Mixins and the Ruby Object model. Read more.

10:45am Sunday, 06/01/2008
Scaling Ruby from the Inside Out Portland Ballroom 252
Ezra Zygmuntowicz (EngineYard) This is a talk about what it takes to really scale Ruby applications. We will not only examine all the aspects of hardware and web server configurations, we will also look at scaling the ruby interpreter itself. Including performance quirks of MRI and how Rubinius is set to fix a lot of these problems. Read more.

11:45am Sunday, 06/01/2008
Everyday DTrace on OSX: A Guide To Using DTrace for Your Full Application Stack Portland Ballroom 251
Scott Barron (EdgeCase), Chad Humphries (EdgeCase) Have you ever wanted to know why a part of your application is slow? How about how long that query takes? Wouldn’t it be nice if you could get this type of information for ruby, rails, and the database server in one place? You can now with DTrace on OSX 10.5. We’ll show you how to best use this tool-chain to debug, profile, and gather more information about your application. Read more.

1:50pm Sunday, 06/01/2008
Building an app in 48 hours – A Rails Rumble Case Study Portland Ballroom 251
Josh Owens (Intridea, Inc/Web 2.0 Show Podcast), Chris Selmer (Intridea, Inc.) So you want to build a Rails app quickly? Competitors in the Rails Rumble had 48 hours to design, develop, and deploy a complete application. We’ll take you through the development processes of the winning four-man Tasty Planner team, and compare it with those of the one-man Your Pet Records team. We’ll discuss techniques, short-cuts, helpers, and Rails plugins that helped speed development. Read more.

Like many, I was disappointed that the Highrise API does not support tagging of people. However, I found a way to easily add the capability to the 37signals-supplied Ruby wrapper class, even if it is unsupported. I added a #tag! instance method to the Person class and used a call directly to the site, not through the API.

class Person < Subject
  ...
  def tag!(tag_name)
    `curl -s -d 'name=#{tag_name}' #{ENV['HIGHRISE_URL']}parties/#{id}/tags`
  end
end

The output is a bunch of javascript to update the page to reflect the change, but one can safely ignore this. The tag is added and everything works great. Not sure how well this would work on Windows, as the curl command-line program is likely unavailable.

We use this method in our latest project to add appropriate tags to people as they are created. It helps us segment people added to Highrise for the project from the rest of our contacts in Highrise.