I’m running on OSX, and using MacPorts for all my un-Apple needs. So, no, getting Ruby 1.9 installed was not complex at all, the suffix is the default in MacPorts, so I just ended up with a ruby1.9 executable.
The kicker comes because Rails, and all its little generator friends, do one of two things. Either they are just hardcoded to use #!/usr/bin/env ruby or they set that line to whatever version of Ruby you happen to be using when you install/generate/make them the first time, which will be either what I’ve just written or #!/usr/bin/env ruby1.9 or (like rails) an actual hard coded path to your MacPorts ruby executable.
Ok, not really a big problem there, until you want to test your application, generator, plugin, gem, whatever against the other ruby on your system. What do you do? Go through and make sure you change all the relevant shebangs? Works fine until you miss one. You’re really testing your sed fu, not your Ruby fu.
And then what happens when, like me, you’re just so used to typing irb or ri that you’re constantly tripping over the “Oh, yeah, that’s over in the 1.9 stuff.” problem?
Well, then you know it’s time to roll out your bash fu. Ewk!
I rolled up these bash functions to switch my MacPorts installation from 1.8 to 1.9 by taking all the binaries that are part of the ruby macports install and moving them to suffixed files, and then symlinking the bare names to either 1.8 or 1.9 (which IMHO should always be how languages are installed).
So, dependencies? It depends on you having macports - it uses that to get the list of files that have been added to the relevant bin directory. You could replace that in the for loop with something else to give you those filenames.
That’s it.
Hmm, or it would be it if I said: run r18 to switch to Ruby 1.8 and run r19 to switch to Ruby 1.9. Also - warning - this runs sudo, so understand what you’re running before typing in your password.
There are two things you want to sort out in Rails3 to get jquery humming along really nicely.
Firstly is the UJS. Rails3 has done great things in replacing all the inline JS with UJS and nice semantic XHTML - but, of course, they ship with the Prototype version of this UJS file.
You’ll want to just overwrite the public/javascripts/rails.js file in your project with the jquery version from github.
So the next step would be to add the javascript_include_tag to all your layouts, and if you’re a jquery fan then you’re probably used to something like this:
javascript_include_tag 'jquery', 'jquery-ui', 'rails', 'application'
At best, if you have only one layout, that’s ugly. When you begin to get more than one layout, you’re un-DRY, or you’re writing your own helper to wrap that up. It just gets uglier. Especially when compared to the Prototype equivalent:
javascript_include_tag :defaults
How do we get this logical grouping of JS files?
Well, I might just be the last one at the party here, but I couldn’t find anything online, or anything obvious in the help, for how to DRY this up. A quick dig in the source revealed the answer though. Somewhere in your init files (in Rails3 I have this in config/application.rb - but this will work in previous versions of Rails too) you can register what’s called an expansion, like so:
ActionView::Helpers::AssetTagHelper.register_javascript_expansion \
:jquery => %w/jquery jquery-ui rails application/
So then in your layouts you can use that expansion like so:
javascript_include_tag :jquery
Much nicer, and very simple to update in a central config location, should you wish.
Almost immediately after posting my last post on the Rails console a few more things came to mind. It has taken me this long to blog again :)
Let’s pick up from where we left off in the previous post with…
A/B testing, split testing, side-by-side testing, call it what you like but for those interested in improving the performance of their marketing it’s crucial to test your copy, headlines, imagery and visual arrangement.
I’ve just packaed up guerrilla_rotate, an internal tool that I’ve been using for a while, and stuck it up on my new best friend: github
It’s best to use this in combination with Rubaidh::GoogleAnalytics in which case it’ll just do what you expect for your stats. If you don’t use that, then you’re on your own with how to track the stats, manual analytics of some sort, or who knows - old school, unique image tags in each view.
Have fun.
When we incorporated Google Adsense into Freedraw we just couldn’t find a simple to use plugin that would insert the ads we needed into our layouts.
How the plugin works is simple, you define how the ad should look within your config/googlead_sense.yml file (a sample one is provided with the plugin). You’ll want to change at least the adclient setting otherwise I’ll get all your ad revenue.
Actually, don’t change that setting! :)
Then just add it into your views or layouts, like so:
<%= google_ad %>
This is a bit different to how the old one worked, you used to have to define all those settings in each controller that you wanted to use the helper in.
This is simpler, and you still have some control over the format in your view, like so:
<%= google_ad(:skyscraper) %>
To install the plugin:
script/plugin install git://github.com/JasonKing/google_ad_sense.git
You can see more here
