Dr. Nic Sells His Baby

Well, one of them anyone and maybe not the one he loves the most.

All-around pretty smart Rails-guru guy Dr. Nic is selling his Rails-based MyConfPlan site for charity so he can attend a conference session:

Why? Because all the money paid by the winner is going to the Chad Fowler and Marcel Molina Jr fund for all-things Humanitarian, and so I can go to their Testing Training Day on the 17th of September in Berlin. Minimum donation is $75.

That’s right, the winner’s money could be entirely tax-deductible as its all going to charity. (You get the site’s code base and the myconfplan.com domain (cost of transfer is yours) are yours. I get entry to the workshop.

If it raises $500 then you are donating $500. If it raises $2,000,000 then you are donating $2×10^6.

I like it. Rather than let an interesting niche site languish on the vine it gets sold off to someone who can either learn from it or extend it, Dr. Nic gets some testing edumacation, and the charity gets some cash.

As of this posting bidding is up to AU $355. Not too shabby.

MyConfPlan in action.

Rails ActiveRecord Instances and ‘super’

For a class of objects in my database I extract data from one or two ways: the first directly from the database via ActiveRecord, the second from Amazon using Amazon::Ecs.

When the asset calls to Amazon to populate its properties I want to use the Amazon-provided data. When I refrence the asset without calling to Amazon (ie: the data has been cached) then I want to reference AR's properties directly. I don't want to have to make two calls dependent upon the data's source location.

In otherwords, I always want to be able to call

book.title

no matter what.

Turns out ActiveRecord makes this pretty easy:

If there are attributes and an attribute called "title" exists, return that. If attributes don't exist then call the super class's title() which contains the data extracted from the database.

Pretty cool ActiveRecord, pretty cool.

Where Does “– tables()” Come From?

When starting up one of my Rails apps the initial console output looks like this:

=> Booting Mongrel (use 'script/server webrick' to force WEBrick)
=> Rails application starting on http://0.0.0.0:3000
=> Call with -d to detach
=> Ctrl-C to shutdown server
** Starting Mongrel listening at 0.0.0.0:3000
** Starting Rails with development environment...
-- tables()
-> 0.0576s
** Rails loaded.
** Loading any Rails specific GemPlugins
** Signals ready. TERM => stop. USR2 => restart. INT => stop (no restart).
** Rails signals registered. HUP => reload (without restart). It might not work well.
** Mongrel available at 0.0.0.0:3000
** Use CTRL-C to stop.

Note that little chunk in the middle that shows how long it took to read the table structure from the database:

-- tables()
-> 0.0576s

Where the heck does that come from??

Of the three Rails apps I currently have in development that only gets output in one of them. The config and environment files are the same across all three platforms (save for database access credentials) and yet only one of them spits out that data.

It's really messing up the production server since Apache attempts to jam it into the HTTP header which causes a 500 error, as one might expect.

Anyone know? A plugin? Lesser-known config option? Elves? I am stymied.

Solving the Depricated @Flash Warning

Long long ago I ran into an issue in which my use of flash always generated a warning, though I thought I was implementing it properly.

In the comments Dmitry finally solved the mystery:

Don’t name your flash partial “_flash.rhtml”, name it something else, like “_flash_box.rhtml”. This is a known bug.

And with that, no more warnings.

options_for_select and <<

It's fairly common to want to grab a bunch of unique database entries and display them as a set of form option tags. Rails has which does quite a nice job of it.

But what to do when I also want to include items not in the database, such as "all" or "none"?

In this case I'm appending "all" onto the hash that constitutes the options.

(Note that it's probably better to have the uniq be in the SQL as DISTINCT but that's for another day.)

‘rake db:migrate’ on Production Server

When the time comes to deploy on a production server, the following sets up the database:

rake db:migrate RAILS_ENV=production

in_place_editor_field as a textarea

You want to use in-place editing but you've got a large amount of text and the default textfield created by in_place_editor_field just isn't large enough? Set the rows property:

When the rows property is set to any value greater than 1, in_place_editor_field renders a textarea instead of a textfield.

in_place_edit_for, in_place_editor_field and Complex Cases

In-place editing of content is a very cool feature and for the most part dead-simple to do in Rails. Unfortunately all the examples around, including the ones in Rails Recipes, assume you'll be implementing this functionality in only the simplest of cases, usually when displaying just that editable data on the page.

In my case I have much more complex requirements - an instance of an event can have many notes attached to the event. If the author of the note is viewing the event they should be able to edit any notes they've written, and edit them in the page using in_place_editor_field.

In this instance the controller for the notes is different than the controller for the page.

Here's how I finally managed to get it to work, using the editing of a note title as an example.

First, add the following line to the note controller:

This automagically sets up a function in the controller called set_activity_item_note_title for us.

Second, in the view, which is app/views/activity/show.rhtml and thus controlled by the ActivityController I display all notes via:

At this point every other example of in_place_editor_field would tell you to add the following to your page to create an in-place editor:

or some variant of that (or something even worse if the author is building their example off of Rail's scaffolding). But that won't work in this case for many, many reasons which you have probably already discovered for yourself if you're reading this.

So, third, I customized the in_place_editor_for like so:

@activity_item_note = note; - set our iteration as an instance variable instead, since in_place_editor_for requires one of these to work (sigh).

:title - define the property to be edited.

:url => { :controller => 'activity_item_note', :action => 'set_activity_item_note_title', :id => note.id } - take back control of the controller and point it to the one that should handle the edit. Add the name of the method and make sure the id of the note being edited is in there as well.

And that does it.

Warning: Because we're passing the id in the URL there's pretty much nothing in this to stop someone from hijacking the URL, injecting their own id's and running rampant through the database, mucking with titles as they see fit. The default set_activity_item_note_title created when I defined in_place_edit_for :activity_item_note, :title has no provision to manage this sort of authentication. As such it is probably a good idea to wrap the auto-generated functions with your own code to manage authentication, something like:

In my case a simple version of this is: