This week Twitter launched the official “Tweet Button,” a button for website owners to count RT’s and let readers easily share content. Mashable was first to report on this shiny new button, but we’re the first to release a tweet-button gem for your next project.

Introducing tweet-button

A new Ruby on Rails gem/plugin to generate shiny new Twitter buttons.

Usage

First, include the TweetButton module into your application helper. After that, using it is as simple as adding a single method call to your views:

<%= tweet_button %>

Bam. Done. You’ll have a sweet lookin’ Tweet button all up in your view.

Of course, you can customize it. The method takes a few options. Any default can be overridden universally.

:url - The URL to share; the default is the current URL.
:text - The text that will appear in the tweet; the default is "Check this out!"
:via - The attribution. Defaults to "tweetbutton", but you should change that.
:lang - Set the language for the tweet (no default).
:related - Related Twitter accounts (no default).
:count - The tweet count box position (values can be "none", "horizontal", or "vertical"; default is "vertical").

So, if you wanted to tweet about Hacker News, attribute it to Peter Cooper, and add some custom text, all from a tweet button with a horizontal counter, you’d do this:

<%= tweet_button(:via => "peterc", :url => "http://news.ycombinator.com", :text => "AWESOME.")

Simple enough, eh? Also, this method call will include the Twitter JavaScript into the page (it only does it once, even if you have multiple buttons on the page). To put this wherever you’d like (i.e., your header), then use the twitter_widgets_js_tag method. If you call this method, it will place the tag wherever you call it from (and only place it there; subsequent calls do nothing).

The gem also supports the custom Twitter share links. To generate one, use the custom_tweet_button (aliased to custom_tweet_link also) method:

<%= custom_tweet_button %>

This will generate a link that will link to the share page with the same default options as the standard Tweet Button generator. You can customize your custom link with text as the first argument, the same options as tweet_button (with the exception of the count parameter, which will be ignored) as the second, and HTML options as a third argument. For example:

<%= custom_tweet_button('Tweet it!', {:via => "myself"}, {:class => "tweet-sharey-thing"})

Setting universal defaults

You can set a new default for any option by setting default_tweet_button_options in your application helper. For example:

module ApplicationHelper
  include TweetButton

  TweetButton.default_tweet_button_options = {:via => "myself"}
end

Only the options you specify will be overridden; so if you only specify a new default +:via+ (which you should definitely do), then the other defaults will stay intact.

Coming Soon

Tweet Buttons can also live in an iframe, so we’ll probably be adding that very soon!

Plan on using this gem?

If you plan on using this gem, please let us know in the comments section! We’d love to check it out :-)

Roll the credits!

This awesome sauce gem was written by our very own hackstar Jeremy McAnally. You can follow his tweets here and his Github here.

JSON has become ubiquitous. From Facebook and Twitter both declaring it to be the preferred (and in some cases only) option for API access to the new OAuth 2.0 draft spec declaring that JSON is the only acceptable response format for OAuth token responses, JSON is here to stay. What isn’t ubiquitous, however, are people’s preferred implementations.

As library authors it is our duty to try to support as large a part of the community as possible and do so in a friendly manner. To that end, today we’re releasing MultiJSON, a simple library that allows you to seamlessly provide multiple JSON backends for your library with intelligent defaulting. Install with a simple gem install multi_json and then get started like so:

require 'multi_json'

# Decode using default engine.
MultiJson.decode('{"abc":"def"}) # => {"abc" => "def"}

# Set an engine using a symbol.
MultiJson.engine = :active_support

# Encode using ActiveSupport
MultiJson.encode({:abc => "def"}) # => '{"abc":"def"}'

This gem is primarily for library authors, allowing you to use the best JSON available on the users’ systems without explicitly requiring one library over another. This way you can be sure that your JSON handling will work across implementations (e.g. JRuby) as well as requiring as little extra code as possible (the gem detects existing libraries before requiring more by default).

Engines supported by default are:

• yajl-ruby
• json (gem)
• active_support
• json_pure

We hope that this will make development of JSON-relying libraries a little bit less of a headache for library authors and users alike. The code is, as always, available on GitHub.

More and more web applications are providing external logins through sites such as Twitter, Facebook, and more. It can be a bit of a pain to assemble suitable buttons for all of these services to display as the “NASCAR box” of logos for users to click when signing up or on to a site.

To make this a little bit easier, Intridea is releasing a collection of free and open-source logo buttons for use, well, however you’d like, but probably for these types of authentication scenarios. This collection is starting with twelve buttons:

The initial set created are for Twitter, Facebook, Myspace, OpenID, Google, Yahoo, Basecamp, Campfire, Present.ly, Aol, LinkedIn, and GitHub.

This collection will grow over time as we get suggestions (or forks) of new iconography. The idea is simply to provide a clean, consistent set of icons that can be used to represent some of the web’s most popular services. Each icon is available in 32×32, 64×64, 128×128, and 256×256 PNGs as well as an Illustrator CS4 source file that contains all of the buttons and individual CS3 .EPS files that contain each button individually.

To see a full download grid for each icon, visit the GitHub Project Page. If you have a logo you’d like to see included, please add a request for it to the GitHub Issues Page

While I’d been tracking with great interest the progress of OAuth 2.0, Facebook lit off the powderkeg yesterday by announcing that their entire API was moving to the protocol (as well as to RESTful JSON). As a developer who had been constantly confounded by the relentlessly hostile environment that Facebook seemed to present to developers, yesterday was a sudden and welcome about-face. The acquisition of FriendFeed, it seems, gave Facebook the talent they needed to do it right this time.

But anyway, on to the news! We have just released a gem for OAuth 2.0 to work with the new Facebook API. You can get it right now:

gem install oauth2

We wanted to get this into the hands of developers ASAP so for now the functionality is pretty much limited to the “web server” type of authentication (the protocol includes many different strategies, all of which will be implemented on the gem over time) and has been tested to work with Facebook’s new API.

So how do you use it? Here is an example Sinatra application containing all of the code necessary to authenticate and then perform requests against the Facebook API.

require 'rubygems'
require 'sinatra'
require 'oauth2'
require 'json'

def client
  OAuth2::Client.new('api_key', 'api_secret', :site => 'https://graph.facebook.com')
end

get '/auth/facebook' do
  redirect client.web_server.authorize_url(
    :redirect_uri => redirect_uri, 
    :scope => 'email,offline_access'
  )
end

get '/auth/facebook/callback' do
  access_token = client.web_server.get_access_token(params[:code], :redirect_uri => redirect_uri)
  user = JSON.parse(access_token.get('/me'))

  user.inspect
end

def redirect_uri
  uri = URI.parse(request.url)
  uri.path = '/auth/facebook/callback'
  uri.query = nil
  uri.to_s
end

So now you’re ready to get started with the new Facebook API! This is still an early release, but I’ll be working on it a lot in the coming months, partially as preparation for my talk at RailsConf in which I’ll be delving into the OAuth 2.0 specification and what it means for Rails developers in-depth. The code is, of course, available on GitHub where you can report any problems you run into. Enjoy!

Update: Those who aren’t terribly familiar with the protocol may wonder why OAuth 2.0 isn’t just rolled into support of the OAuth gem (or why I didn’t fork it and do it that way). Honestly, I would have liked to, but OAuth 2.0 is an almost entirely different beast than 1.0a and they share so little functionality that it would basically be two projects living under the same gem name. So that’s why!

We’re always looking for ways to make it easier to keep up to date with your co-workers using Present.ly. Recently I’ve been using the Mac Beta of Chrome and thought a Chrome Extension could be a great way to use Present.ly throughout the day. As of today it is available on Google’s Chrome Extension Directory.

The functionality of the extension is still growing, but you can read and post updates to your network as well as view text attachments. It will keep refreshing automatically and let you know when new updates come in, letting you check in without even opening a new tab!

As with all of our client applications, the Present.ly Chrome extension is available as open source on GitHub. We think it’s a great new way to access Present.ly, and we hope you enjoy it!

If you’ve taken a look at Mustache, the “stupid in a good way” templating engine, you might know that there are also Javascript Mustache renderers such as Mustache.js. Today we’ve released a small library called mustache_json that allows you to compile your Mustache view objects into JSON, allowing them to be interpreted by Javascript Mustache rendering engines.

What this means for your project is that you will finally have a identical client-side and server-side rendering interface, opening wide the opportunities for pushing more of the rendering work onto the client-side, a boon for many real-time and heavy-interaction applications.

To install mustache_json, just get the gem from Gemcutter:

gem install mustache_json

To use it, simply require 'mustache_json' and all of your Mustache objects will automatically be given a #to_json method. For instance:

require 'mustache_json'

class Person < Mustache
  def initialize(first_name, last_name)
    context[:first_name], context[:last_name] = first_name, last_name
  end
  
  def initials
    "#{context[:first_name][0..0]}.#{context[:last_name][0..0]}."
  end
  
  def listing
    "#{context[:last_name]}, #{context[:first_name]}"
  end
end

bob = Person.new('Bob', 'Bobson')
bob.to_json

This will render into a JSON object that looks like this:

{"last_name":"Bobson","initials":"B.B.","listing":"Bobson, Bob","first_name":"Bob"}

Mustache JSON gives you access to all of the public instance methods you declare in your Mustache as well as any context you have set. It is essentially a fully compiled version of the Mustache view, providing everything another renderer needs to create the actual markup. The JSON back-end for this library is swappable, meaning you can use the JSON gem, JSON pure, ActiveSupport, or Yajl by default (and any other class with an encode method if you’ve got a different library).

Documentation is available on RDoc.info and the source is available on GitHub. Stay tuned for posts in the future about utilizing this library to actually perform identical rendering in Ruby and Javascript.

That’s the most foul, cruel, and bad-tempered word you ever set eyes on!

Look, that word’s got a vicious streak a mile wide! It’s a killer!

There will be no killer words in this application: Behold the mighty Fu-fu! And there was much rejoicing… But first, a little history on Fu-fu: The Profanity Filter for Rails.

A Little History

Recently, I needed a simple (profanity/cuss/swear/bad word) filter for a Rails app, so I hit up Google for the answer as this seemed like a problem that should have been solved by an expert. Sadly, this was not the case.

Over the next day or so I was able to get a simple prototype up and running in our application and that’s the way it stayed for the next couple weeks. Then I realized that this was reason I wasn’t able to find a profanity filter plugin on Google.

Upon closer inspection it seems that people are building their own filters and leaving it at that. Almost being guilty of this, I decided that it was time to give back to the community and get a profanity filter plugin out in the wild.

I was able to publish the first version of the Profanity Filter during the Community Code Drive at RailsConf 2008. Hacking in the same room as DHH, David Chelimsky, Chad Fowler, Rich Kilmer, Marcel Molina Jr., and the entire Intridea team is a great motivator.

During RailsConf we decided that the plugin needed a real name; “Profanity Filter” wasn’t cutting it. Someone suggested fu-fu pronounced ‘eff-you-foo’. That was promptly shortened to ‘foo-foo’. How can you not love something named Fu-fu that deals with profanity and abuses plugin idioms at the same time?

Continue Rejoicing (Examples!)

The interface for Fu-fu is clean and straight forward. For example. lets say that ‘frak’ is a common curse word.

class Post < ActiveRecord::Base
  profanity_filter :title, :body
end

post = Post.create(:title => 'Fraking title', :body => 'What a bunch of frak')

post.title          #=> '@#$% title'
post.title_original #=> 'Fraking title'

post.body           #=> 'What a bunch of @#$%'
post.body_original  #=> 'What a bunch of frak'

By default the filter will replace common curses with the standard curse notation of ‘@#$%’. Fu-fu is also has the ability to do dictionary replacements:

class Post < ActiveRecord::Base
  profanity_filter :title, :body, :method => 'dictionary'
end

post = Post.create(:title => 'Fraking title', :body => 'What a bunch of frak')

post.title          #=> 'fr*k*ng title'
post.body           #=> 'What a bunch of fr*k'

Fu-fu comes with a default dictionary file that replaces all vowels with asterisks (*).

You can also add an exclamation point to the end of the filter call (profanity_filter!) and have the method save the filtered text to the database (although this is not recommended for most applications).

You can also call Fu-fu directly:

ProfanityFilter::Base.clean('frak')               #=> '@#$%'
ProfanityFilter::Base.clean('frak', 'dictionary') #=> 'fr*k

Todos and Fixes

But alas, there is still danger in Caerbannog. As with all things, there is room for improvement.

* better filter regex, doesn't currently catch things like 'f-r-a-k'
* needs support for multiple dictionaries and configuration
* needs support for different levels of filtering (prude, normal, weak, etc)

Installation

To install the Fu-fu: The Profanity Filter on Edge Rails or Rails 2.1 and greater:

script/plugin install git://github.com/adambair/fu-fu.git

On earlier versions of Rails:

git clone git://github.com/adambair/fu-fu.git vendor/plugins/fu-fu

Resources

Bug tracking is available through the Fu-fu Lighthouse project. Also, feel free to contribute. I’ll be happy to accept patches and push requests for reasonable fixes and additions as long as they come with test coverage.

The source code is available on GitHub.

For general discussion about the plugin, please use the forums and wall of Fu-Fu’s Acts As Community Profile

Thanks to the Intridea team for their time, contributions, and suggestions. I’ve had a great time building Fu-fu and I hope someone may find it useful.

Intridea is officially open-sourcing Scalr - a redundant, self-curing, and self-scaling hosting environment build on top of Amazon's EC2.

Scalr utilizes EC2 to provide a multi-tiered hosting environment with pre-built images for load balancers, database servers, and application servers. Designed with flexibility in mind, users can further customize each type of machine to use as nodes in their server farm or customize a generic base image for any number of purposes. The application monitors and maintains the server farm by reconfiguring the entire cluster when machines fail or when new machines are inserted. Additionally Scalr can be setup to replace failed machines and scale up and down based on user configured thresholds. The application provides a simple web-based interface for configuring and monitoring your server farms.

The system was initially designed for MediaPlug, a white label audio, video, and image transcoding service that needed to scale based on customer demand.

The project can be found at http://scalr.intridea.com

The project is still very young, but we're hoping that by open sourcing it the AWS development community can turn this into a robust hosting platform and give users an alternative to the current fee based services available.

Josh Owens and Dave Naffis were the 7th and 8th leading contributors, respectively, in the October '07 Rails Hackfest. The Rails Hackfest recognizes developers who, by submitting patches, documentation, tests, and/or tickets, are actively involved in improving Ruby on Rails. Kudos to Josh and Dave for their accomplishment! Intridea is proud to give back to the Rails community, as well as other open source projects.