Categories
Ruby Web 2.0

Updating FaceBook status from Twitter

I’ve recently jumped on the Facebook bandwagon. I can’t be bothered to update two statuses (I rarely get round to it with one), so I was looking for a way to update my FaceBook status from Twitter. I installed the Twitter application in FaceBook, but that just displays the Twitter status separately.

It seemed that the only way to do it was to write a script to regularly check Twitter, and update FaceBook when it found a new Twitter message. I found a partial solution in PHP, but decided to roll my own in Ruby anyway.

It took a few hours longer than I expected (the documentation for Net::HTTP could be better), but I got there in the end. I now have the script below installed on my DreamHost account, and set to fire every minute via cron. It’s not the prettiest code I’ve ever written, but it does the job. Feel free to borrow it if you think it’ll be useful.

Andrew ‘Boz’ Bosworth
11:29pm September 6th

I’m an engineer at facebook and I’m writing to ask if you would be willing to take down the link to your facebook/twitter status sync utility (located on your website kerrybuckley.com). Based on your comment on TechCrunch I suspect you anticipated this would be coming at some point. Even if your intended use of such a script is noble (as I’m sure it is), the simple script you have posted on your site is (and has always been) against our terms of service. Said more shortly, we just can’t let people automate aginst our site outside of the platform; it’s a slippery slope.

We’d obviously like to resolve this without disabling your account or getting the lawyers involved if possible, so please let me know as soon as you’ve taken the script down so that our legal department doesn’t get all fired up about this.

thanks,
Andrew Bosworth
Facebook Engineer

My reply:

Andrew,

As you’ll probably expect, I’m not particularly impressed with Facebook’s current stance on openness in general, or on this issue in particular. I hope that at some point you add an API to allow remote updating of status, in the same way that you recently added an RSS feed to allow tracking of friends’ statuses.

For the record, I don’t believe that posting the script on an external site constitutes a violation of the terms of service, although I accept that using it would be. Also, when you say “we can’t just let people automate”, I assume you really mean “we won’t just let people automate”. This is a shame, as it goes against the grain of the Internet, and reinforces the impression that you’re trying to lock people into your site.

All that said, I don’t particularly want to be spending my time fending off writs and takedown notices, so the script no longer appears on my site (see http://www.kerrybuckley.com/2007/07/14/updating-facebook-status-from-twitter/).

Kerry

Technorati Tags: , , ,

Categories
Rails

Correct use of the flash in Rails

[Update 9 May 2012]

This seems to work for testing flash.now in Rails 3:

it "puts an error in the flash" do
  post :create
  flash[:error].should == "Sorry, that's wrong."
end

it "does not persist the flash" do
  post :create
  flash.sweep
  flash[:error].should be_nil
end

[Update 20 April 2010]

I recently had problems testing flash.now, and Google kept leading me back to this post. Unfortunately it doesn’t seem to work with the current version of Rails (I’m using 2.3.5 at the moment).

This post from Pluit Solutions gives an alternative approach which seems to work. I haven’t tried it with Rails 3 though.


I don’t know whether this has caught anyone else out, or whether we just didn’t read the documentation properly (it’s covered briefly on p153 of AWDwR), but I thought I’d mention it anyway.

Anyone who’s written a Rails app will know that the ‘flash’ is used to store error and status messages, usually on form submissions. Model validation failure messages automatically get copied into the flash, but you often want to do it manually too.

flash[:notice] = "User Details updated."
redirect_to edit_user_path(@user)

The gotcha comes when you want to display a message and render a page, as opposed to redirecting – for example when errors are preventing a form from being submitted. This is how not to do it:

flash[:error] = "Password doesn't match confirmation." # WRONG!
render :action => 'change_password'

The problem is that the flash is stored for the next request. Because we’re no longer doing a redirect, that means the message may appear wherever the user goes next, not just on the page that we just rendered. To avoid this, use flash.now, which is only used for the current request:

flash.now[:error] = "Password doesn't match confirmation."
render :action => 'change_password'

The rule of thumb is to use flash if you’re redirecting, and flash.now if you’re rendering (either explicitly, or by dropping through to the default view for the action).

All very well, but whatever you put in flash.now is cleared out at the end of the request, so how do you test it? The answer (for RSpec, at least) lies in a comment on this RSpec feature request – basically just add the following to spec_helper.rb:

module ActionController
  module Flash
    class FlashHash 
      def initialize
        @hash = {}
        @now_hash = {}
      end
    
      def [](key)
        @hash[key]
      end
    
      def []=(key, obj)
        @hash[key] = obj
      end
    
      def discard(k = nil)
        initialize
      end
    
      def now
        @now_hash
      end
    
      def update(hash)
        @hash.update(hash)
      end
      
      def sweep
        # do nothing
      end
    end
  end
end

You can now do something like this:

describe "When a user tries to change his password with an invalid verification code" do
  ...

  it "should put an error message in the flash" do
    flash.now[:error].should == "Incorrect verification code or password."
  end
  
  it "should not persist the flash" do
    flash[:error].should be_nil
  end
end

Technorati Tags: , , ,

Categories
Agile BT Ruby Software

A step-by-step BDD example using RSpec

We’ve now got a Ruby focus group at work, and one of the first things to be set up has been a weekly programming exercise [intranet link], in the style of Ruby Quiz. It’s now week two, and the problem is slightly more complex than last week’s gentle FizzBuzz introduction. Here’s the specification:

This time, the challenge is to come up with some Ruby code that converts a positive integer to its English language
equivalent. For example:

1 => one

10 => ten

123 => one hundred and twenty three

10,456 => ten thousand four hundred and fifty six

1,234,123 => one million two hundred thirty four thousand one hundred and twenty three

The code should work from numbers 1 – 10,000,000,000 (ten billion) but if it works for bigger numbers its all good.

For an extra challenge, when the strings for the numbers for 1 – 10,000,000,000 are sorted alphabetically, which is the
first odd number in the list?

I thought it might be interesting (to me, at least!) to record the process I go through to reach the solution, rather than just sharing the finished article. I’m using a behaviour-driven approach, although the process for writing a single method obviously doesn’t touch on a lot of the wider aspects of BDD.

So here it is, warts and all (I’m writing this as I go along, so I have no idea how long this post is going to get, or whether I’ll even arrive at a solution at all!)

Categories
Rails

Opiniated software

DHH talking about pluralisation in Rails, in Scott Hanselman’s RailsConf interview with him and Martin Fowler:

…it was kind of a firewall. It was a firewall for aesthetics. So if you could not appreciate why we did this, why we chose to go through all of this work to get prettier code, maybe you weren’t in the state of mind that was a good fit for this community. So we tried to weed people out in some sense – if they don’t share the same cultural bias, if they don’t share the same values, then maybe they’re not a good fit for the Rails community.

It’s often said that Rails makes it very easy to Do The Right Thing, whether it’s separation of concerns, unit tests, DRY or whatever. I wonder how many people start using better practices because Rails pushes them in the right direction, or whether they choose Rails because they see the obvious evidence of good practices its philosophy and architecture.

Technorati Tags: , , , ,

Categories
Agile Java Ruby

An issue with mock-driven development in dynamically-typed languages

First, let me make it clear that I really like BDD, I really like mocks, and I really like dynamic languages. RSpec does a pretty good job of combining all three.

However, there’s one disadvantage that duck-typed languages suffer when it comes to using mocks to drive the design of the interfaces between objects.

Categories
Java Rails

Hi, I’m Ruby on Rails…

The guys over at Rails Envy have created an excellent J2EE vs Rails parody of Apple’s Get a Mac adverts:

Apparently there are more coming over the next few days.

Categories
Agile Rails Ruby

Are we spending more and more time writing tests?

A while ago I wrote about testing trivialities, and claimed that no matter how simple the piece of code is, it still ought to have a test. I followed it up with some thoughts on using a helper to simplify writing specs for common validations. Even using the helper, the actual test code for a single validation outweighs the production code by a factor of more than three:

Categories
Agile Java Rails Ruby Software

cruisecontrol.rb

In case you missed it, those nice people at ThoughtWorks released CruiseControl.rb yesterday.

Categories
Agile Rails Ruby

DRYing out model specs

[Updated 14/3/07: corrected specify_attributes as per Paul’s comment]
[Updated 18/12/07: modified to avoid crazy RSpec errors]

A week or so ago I wrote about writing specs for simple pieces of functionality (particularly those that are arguably just configuration, like Rails validations). I argued that it’s important to test-drive even the simple things – however, the amount of test code can get out of hand.

Categories
Agile Ruby Software

Testing trivialities … and double-entry bookkeeping

From time to time I end up in a discussion (as often as not with myself) about the point at which something is so trivial that it doesn’t justify creating a unit test (or behaviour spec, in more BDD-like language).