Stolen from: http://groups.google.com/group/rubyonrails-talk/browse_frm/thread/148ada4b0d33cfac?hl=en

If cost is an issue, you may wish to investigate Reverse Proxying with a
single external certificate and multiple internal certificates (either
self-signed or issued from an internal CA).

From: http://www.javascriptkit.com/javatutors/conditionalcompile.shtml
Conditional Compilation of JScript/ JavaScript in IE

In IE, there is a little known feature called conditional compilation. Supported since IE4, this feature starting getting some attention when it began showing up in some Ajax related JavaScripts. An absolute form of object detection, conditional compilation lets you dictate to IE whether to compile certain parts of your JScript or JavaScript code depending on predefined and user defined conditions. Think of it as conditional comments for your script that can also be molded to work gracefully with non IE browsers as well.

Thanks to: http://www.vivabit.com/bollocks/2006/04/06/introducing-dom-builder#c856

#48: Avatar kentaromiura / 19th April '06

You could do like I do here: Crazy corners using IE conditional comment

var cn=�class�;

/@cc_on

cn="className";

@/

so you use cn insted of class or classname _; bye

From: http://jamis.jamisbuck.org/articles/2005/12/14/two-tips-for-working-with-databases-in-rails

The second tip is handy when you’re working on a migration. I find that the process (for me) works like this:

* Create the migration and run it.
* Discover I forgot something.
* Migrate down to the previous schema version.
* Change the migration and run it again.

(Repeat as necessary.) However, being the imperfect programmer that I am, I find that I often implement the #down method incorrectly, forgetting to drop a table or remove a column. Thus, when I try to run the migration again, it fails saying that the table/column already exists.

Using script/console and ActiveRecord::Schema, it becomes a cinch to clean up the artifacts:

ActiveRecord::Schema.define do
    drop_table :foos
    remove_column :bars, :blitz
    remove_column :bars, :things
  end

From: http://jamis.jamisbuck.org/articles/2005/12/14/two-tips-for-working-with-databases-in-rails
First tip: I’ve found recently that if I have a boolean field in the database that is being used to mark whether some event occurred (referrals.pending, or feeds.subscribed) it is often more effective to make the field a datetime and record the moment that the event occurred. Then, a NULL can be used to indicate that the event has not yet occurred. Thus, you have referrals.applied_at with a method on Referral like this:

  def pending?
    applied_at.nil?
  end

This gives you the capability down the road to not only report whether the event occurred, but how frequently over various periods of time.