UJS drivers (rails.js / jquery-ujs.js) -- load them LAST.

Don't load your UJS driver (rails.js or jquery-ujs.js) before your application logic JavaScript.

	<%= javascript_include_tag 'jquery' %>
	<%= javascript_include_tag 'rails' %>
	<%= javascript_include_tag 'application' %>
	/* NO. NO. The above is /wrong/. */
	<%= javascript_include_tag 'jquery' %>
	<%= javascript_include_tag 'application' %>
	/* every other javascript file you need */
	<%= javascript_include_tag 'rails' %>

view raw gistfile1.erb hosted with ❤ by GitHub

Why? Because your UJS driver is going to hook into the submission events for ajax elements. If you need to run a validation (or anything like it) that has to be executed BEFORE form submission occurs, because it may cancel the submission event, you need to have that code hook into the submission events before your UJS driver does.

Therefore, load your UJS driver last.

Mint.com is pretty awful now.

Mint sucks. What happened? After Intuit bought them, they added support for one of my previously unlisted banks, but then almost immediately all four Bank of America accounts I had inputted stopped updating.

And just awhile ago, my Prosper account stopped updating.

So now I have:

* a PayPal account I get non-stop "low balance" warnings for, even though the balance hasn't changed in over a year,
* a car note account that doesn't show my remaining balance,
* An Ally CD,
* and one bank account.


The most hilarious moment of this has to be that today I got an email from Mint, claiming that they've improved their back-end so now they don't talk to a 3rd party any more to get your bank updates: they connect directly to the financial institutions instead. Too bad connecting directly with the banks is apparently less robust than connecting through that 3rd party, am-i-rite?

Runner up for most hilarious moment: Mint claims that you have to turn off all (ALL) of Bank of America's three-factor security mechanisms in order for Mint to work, because they're "unsupported." I have an account with another bank that updates perfectly fine via Mint, and it uses the same three-factor security that Bank of America does.

It's unfortunate that Wesabe and the rest of them died off so quickly; they probably could have used this moment to start picking up customers as they drop off of Mint.

There is no way I'm turning off any bank's additional security. I've already had my identity thiefed twice (caught by the bank both times before they did any real damage), I am not making it easier for someone to ninja my bank account, because, you know, there is MONEY IN THEM THERE ACCOUNTS.

Making Jammit jam with Heroku

So, you want to use Heroku and Jammit together, and you've come here of all places! I know, there's no good solution for this floating around The Interwebs, so I figured one out myself, and now I'm publishing so that you, YOU THE VIEWER, can be both shocked and amazed.

There's a nicely formatted gist right here, or you can read it inline below:

	unless Rails.env.development?
	require 'fileutils'
	output_folder = Rails.root.join("tmp", "jammit", "assets")
	FileUtils.mkdir_p(output_folder)
	# Heroku specific hack.
	Jammit::Packager.class_eval do
	def glob_files_with_heroku_hack(glob)
	paths = glob_files_without_heroku_hack(glob)
	# Heroku has a magical "public/javascripts/all.js" file. It is a Mystery.
	paths.reject { |path| path =~ /javascripts\/all.js$/ }
	end
	alias_method_chain :glob_files, :heroku_hack
	end
	Jammit.package! :output_folder => output_folder
	Rails.configuration.middleware.insert_before('Rack::Sendfile', 'Rack::Static',
	:urls => ['/assets'],
	:root => "#{Rails.root}/tmp/jammit")
	end

view raw jammit.rb hosted with ❤ by GitHub

Yes, that large hack floating around in the middle is specifically for Heroku. If you're on another cloud service that is a little less wizardly, you can drop the class_eval block entirely and you should be good to go.

If you're wondering if the resultant files will be cached by Heroku's Varnish HTTP accelerator: yes. Rack::Static will return the fetched files as Rack::File objects, which Heroku caches.

UPDATE: if it's not obvious, this needs to go into config/initializers -- so it runs once on app start up.