def twitter_url(resource, tweet_text="Check out this article from my-site.com:")
          tweet_url = root_url.chop + url_for(resource)
          "http://twitter.com/home?status=#{tweet_text} #{tweet_url}"
        end
    

This method just builds a url to twitter and supplies some default text which you may optionally override by passing a second argument. Call it in your view like this:

        <%= link_to "Retweet this post!", twitter_url(@post) %>
    

Now, this method works but it would be much better if we could use shortened urls. So let’s change things a bit in order to use bit.ly — twitter’s preferred url shortening service. Before we write any code…

1. You’ll need to sign up for bit.ly.
2. And grap your api key.

With that info on hand, we’re ready to interface with the bit.ly api. Let’s make another helper method also located in app/helpers/application_helper.rb:

        def shorten_with_bitly(url)
          # build url to bitly api
          user = "insert-your-username"
          apikey = "insert-your-api-key"
          version = "2.0.1"
          bitly_url = "http://api.bit.ly/shorten?version=#{version}&longUrl=#{url}&login=#{user}&apiKey=#{apikey}"

          # parse result and return shortened url
          buffer = open(bitly_url, "UserAgent" => "Ruby-ExpandLink").read
          result = JSON.parse(buffer)
          short_url = result['results'][url]['shortUrl']
        end
    

This method uses your credentials to build a url to interface with the bit.ly api. Bitly receives our request and returns a JSON object containing a shortened url. We’ll parse this object, grab the shortened url, and return it.

Finally, we need to change our initial twitter_url method to include url shortening:

        def twitter_url(resource, tweet_text="Check out this article from my-site.com:")
          tweet_url = root_url.chop + url_for(resource)
          tweet_url = shorten_with_bitly(tweet_url) if Rails.env.production?

          "http://twitter.com/home?status=#{tweet_text} #{tweet_url}"
        end
    

This is identical to our original method except we’ve added a new line which calls shorten_with_bitly. This line overwrites the tweet_url variable — replacing the long url with a shortened version. Finally, we’ll include a condition to ensure this only happens in production. This saves us from creating a bunch of useless bit.ly links that point to localhost urls.

Some final points.

• The shorten_with_bitly method borrows heavily form a ruby snippet posted by Puneet Pandey. Pandey definitely deserves some credit here.
• If you’re looking for a more robust way to interface with the bit.ly api, checkout this url shortening gem by Nasir Jamal. I’ve never used it but appears to be fully featured and well documented.

Here’s an example.

Let’s say you have an array:

		colors = %w{red yellow green blue orange purple pink teal}
	

And you want to grab each object, uppercase it, and store the result in new array. You might try:

		big_colors = colors.each { |color| color.upcase }
	

But this doesn’t work. It returns an array of lowercase colors because the code doesn’t know that we’d like to store each iteration in a new array. So lets refactor a bit and try this:

		big_colors = []
		colors.each do |color|
		  big_colors << color.upcase
		end
	

That works. We create an empty array, grab each color, uppercase it, and add it our newly created array.

But because this is a fairly common process, ruby provides the collect method to help clean things up a bit. So we can refactor this code using collect like this:

		big_colors = colors.collect { |color| color.upcase }
	

A few final points.

• Although the collect method works on arrays, it's not strictly an array method. It's part of the enumerable module which is mixed into to the array class. The enumerable module has loads of timesaving methods for working with collections. Check out the ruby documentation.
• The collect method and the map method are interchangeable. Most people prefer collect but use whatever syntax makes more sense to you.

Now, jQuery makes this functionality super easy – just a few lines of code. But here’s the tricky part: the configuration of each profile page needs to be stored in your database and be associated with a given user. Otherwise users would lose all their changes on page refresh. No good.

This means every time a user changes something (e.g. removes a stock ticker) you need to let rails know the profile has been changed so that the appropriate columns can be updated in your database (e.g. set the ticker’s ‘hidden’ boolean to true). And ideally, this should all happen silently in the background so that the user’s not even aware their changes are being saved on the fly.

Now, we’re talking about making the client talk to the server without a page refresh. That means AJAX. So here’s the plan…

1. Create your javascript event.

For simplicity, say you’d like to let the user can change the background color of their profile page. Let’s give them three buttons to toggle between red, yellow, and purple. Your html would look like this:

<body>
Make Green
Make Yellow
Make Purple

</body>

And your jQuery would look like this:

$('.change_bg_color').click(function() {
	if (this.id == 'green') { $('body').css('background-color', 'green') };
	if (this.id == 'yellow') { $('body').css('background-color', 'yellow') };
	if (this.id == 'purple') { $('body').css('background-color', 'purple') };
});

That will get our background changing color, but as soon as the page refreshes we’ll lose our changes. So let’s get rails involved.

2. Set up the appropriate models and associations

I’ll move pretty quickly here cause it’s so easy. I assume you have a current_user stored in your session. I’ll also assume you’ve set up a one-to-one association between ‘users’ and ‘profile_settings.’ This means you should be able to do something like this in your controller:

def make_background_green
	current_user.profile_setting.update_attributes(:background_color => 'green')
end

And then you can apply this color using inline style:

<body style="background-color=<%= current_user.profile_setting.background_color %>;" >
<%= link_to "Make Green", :action => "make_background_green" %>
<%= link_to "Make Yellow", :action => "make_background_yellow" %>
<%= link_to "Make Purple", :action => "make_background_purple" %>

</body>

Of course this is just nasty for a couple of reasons: (a) you’d have to write a new method for each possible color, (b) the markup is sort of ugly, and (c) we’re relying on a page refresh to do the work. So let’s clean this up a bit using AJAX.

3. Update your profile settings via AJAX.

First, let’s get our html looking better:

<body style="background-color=<%= current_user.profile_setting.background_color %>;" >
Make Green
Make Yellow
Make Purple

</body>

Then lets add some AJAX to our click event:

$('h3').click(function() {
	if (this.id == 'green') { $('body').css('background-color', 'green') };
	if (this.id == 'yellow') { $('body').css('background-color', 'yellow') };
	if (this.id == 'purple') { $('body').css('background-color', 'purple') };		

	$.post('http://your_site.com/profile_controller/change_background_color', {
		'background_color' : this.id
	});
});

Here’s where you need to pay attention. We’re sending an AJAX post request with two arguments: (1) the url we’d like to load and (2) the data we’d like to pass along as a key/value pair. This means your controller is going to fire the ‘change_background_color’ action and will have access to the params[:background_color] with a value equal to the clicked element’s id.

And so your controller will look like this:

def change_background_color
  current_user.profile_setting.update_attributes(:background_color => params[:background_color])
  render :nothing => true  # make sure the action knows not to load a template
end

4. Mission accomplished.

Your profile settings should now be updating quietly in the background. If you have any problems, start up firebug and watch your AJAX hit register in the console log. This can be very helpful when debugging. But don’t get discouraged. Once you get this process down, all sorts of cool things become possible.

class String
  def reverse_each_word
    self.split.collect { |word| word.reverse }
  end
end

That works but suppose you wanted to abstract this logic to use elsewhere. So instead let’s write a method to iterate through each word in the sentence, yielding the result to a block. Then you can do whatever you want to each word (upcase, reverse, length, capitalize, etc). Now that’s a bit trickier:

class String
  def each_word
    self.split.each { |word| yield word }
  end
end

And now you have a more flexible method which can do things like this:

"This is a very short sample string".each_word do |word|
  word.reverse.upcase
end

Neat. But what’s going on here? The reverse_each_word method is pretty vanilla – take a string, split the words into an array, reverse them, and return the collection. The each_word method, however, is less straight forward. It starts out much the same – take a string, split the words into an array but then…

Well, it’s actually pretty simple. We use the keyword yield to let ruby know that our method is going to accept a block. And, more specifically, we’re telling ruby we’d like each word in our array to be yielded as parameters within that block. Now we can iterate through through each of our words – manipulating them however we please.