• Read more about Announcing Profanity Filter for Rails

I'm pleased to announce Profanity Filter for Rails. This gem filters undesirable words from text and displays a friendly version. Filtering is non-destructive by default but has the option of replacing the original text. It's based on a dictionary that is customizable so you can add additional words as needed.

Profanity Filter is the evolution of a plugin I created a few years ago called Fu-Fu (the Profanity Filter for Rails). This new version has been renamed, tested with Rails 3 and has been moved over to the Intridea github account to ensure proper support (bug fixing, development time, etc) going forward.

Installation

gem install profanity_filter

Rails 3 with Bundler

Open your Gemfile and add:

gem "profanity_filter"

Rails 2.x without Bundler

Open config/environment.rb and add:

config.gem "profanity_filter"

Usage: Basic

You can call the profanity_filter method within your ActiveRecord models.

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

Usage: Non-Destructive

Filters content when called, original text remains in the database.

profanity_filter :foo, :bar    #=> banned words will be replaced with @#=>$%    profanity_filter :foo, :bar, :method => 'dictionary'    #=> banned words will be replaced by value in config/dictionary.yml    profanity_filter :foo, :bar, :method => 'vowels'    #=> banned words will have their vowels replaced    profanity_filter :foo, :bar, :method => 'hollow'    #=> all letters except the first and last will be replaced    Non-destructive versions of the filtered attribute:    some_model.foo => 'filtered version'    some_model.foo_original => 'non-filtered version'  

Usage: Destructive

Filters content in the database, original text is lost. Note the "!" when calling the profanity_filter method.

profanity_filter! :foo, :bar    #=> banned words will be replaced with @#=>$%    profanity_filter! :foo, :bar, :method => 'dictionary'    #=> banned words will be replaced by value in config/dictionary.yml    profanity_filter! :foo, :bar, :method => 'vowels'    #=> banned words will have their vowels replaced    profanity_filter! :foo, :bar, :method => 'hollow'    #=> all letters except the first and last will be replaced  

You can find additional information in the README.

Contributing

I've used this on a number of projects and it's served me well but it's by no means perfect. If you find something that doesn't work for you or have a suggestion please let me know and I'll see what I can do (directly or through Github Issues). If you have an improvement/refactoring I welcome pull requests on Github. The project has a full test suite with benchmarking and the code base is tiny so feel free to jump in!

You can find Profanity Filter on Intridea's Github account.

• Read more about New Twitter Button Gem from Intridea

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.

• Read more about MultiJSON: The swappable JSON handler

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.

• Read more about Redfinger: A Ruby WebFinger Gem

Just yesterday, Google turned on webfinger for all GMail accounts. Today, we’re releasing a RubyGem to help you use the new protocol!

What’s a WebFinger?

WebFinger is a new protocol for extracting public information about a person via their e-mail address. It is meant to complement systems such as OpenID as well as give a simple way to get basic information about a user without having to ask them for it.

E-Mail providers can implement WebFinger by creating a special URL (specifically at /.well-known/host-meta) that is an XRD XML document telling the requester a URL at which they can find out more about e-mail addresses on their domain. Google’s, for example, is http://www.google.com/s2/webfinger/?q={uri}. When the WebFinger endpoint is requested with an e-mail address in place of {uri}, Google looks up information about that e-mail’s public profile and provides it in a standardized XRD XML format.

So why WebFinger when OpenID already exists? Users are used to associating their e-mail address with their identity. It’s natural since an e-mail address is (usually) for a specific person. By putting a protocol in place to find out more about an e-mail address without requiring additional input from the user, a host of options become available.

For instance, if I’m an application looking to authenticate using OpenID, I can ask a user for their e-mail address instead of their OpenID URL (something that will confuse mainstream users to no end). Or, if I want to automatcially fill in basic profile information, I can check to see if a parseable profile page is available in a format such as hCard.

Enter Redfinger

Redfinger is a library built to easily consume the WebFinger protocol. Installing it is simple:

gem install redfinger

Using it is just as simple:

require 'rubygems' require 'redfinger'  finger = Redfinger.finger('youraccount@gmail.com') finger.open_id.first.to_s # => "http://www.google.com/profiles/youraccount"

Redfinger will query the host of the e-mail domain specified, and, if the Webfinger protocol is supported, retrieve information about that e-mail address including such links as OpenID Provider, hCard URL, and more.

How can you use this today? Well, if you’re an OpenID consumer you can use the above code to try to “intelligently find” an OpenID endpoint from an e-mail address. Of course, it will just about only work with Google at the moment (this is an alpha protocol, after all). Or, you could install the mofo gem (a gem for parsing microformats for web pages) and do some neat things with microformats:

require 'rubygems' require 'mofo' require 'redfinger'  finger = Redfinger.finger('account@gmai.com') card = hCard.find(finger.hcard.first.to_s) card.fn # => "That GMail user's full name" card.title # => "The title he/she entered on Google Profile"

Here Redfinger determines a URL that will have hCard information about the e-mail address specified, and the Mofo gem goes out and fetches that address, parsing out the information.

WebFinger is still brand new (Google calls it “alpha”) but it shows some promise for being a great way to make the open web more seamless for users. As always, the Redfinger source code is available on GitHub and RDoc Documentation is available. Check it out!

• Read more about ruby_bosh- an XMPP BOSH session initializer

Hot on the heels of my post on why XMPP will be huge, here’s a ruby library to pre-initialize BOSH sessions in your Ruby web applications. This feature allows you to by-pass exposing your user’s XMPP credentials in your HTML views.

The process follows as such:

There are many XMPP servers and BOSH connection managers out there, but as of now this library has only been tested with eJabberd 1.2+. Please feel free to fork and submit a pull request if you’d like to contribute.

The plugins and documentation can be found at: http://www.github.com/skyfallsin/ruby_bosh

Jack Moffit’s written a Django/Python example here.

• Read more about Colorist: Color Manipulation For WebHeads

While writing color customization code for a recent project, I once again ran into the fact that the existing color gems for Ruby seem to be built for vastly different purposes. To that end, I decided to write a new library for dead-simple manipulation of colors with an emphasis on ease-of-use and being useful for web developers.

Installation

gem install colorist

The Basics

To instantiate a color in Colorist, you use a number of methods:

require 'colorist' include Colorist  red = Color.new(0xff0000) red = 0xff0000.to_color red = "red".to_color red = "#f00".to_color red = Color.from_rgb(255,0,0)

Note: I include Colorist in these examples, but there’s no reason you can’t leave it namespaced i.e. Colorist::Color instead.

The idea is to give maximum flexibility without making it complicated. Once you’ve instantiated a color, you can figure out a few tidbits about it and perform some basic operations:

red.brightness # => 0.299 red.r # => 255 red.invert # => #<Color #00ffff> red.text_color # => #<Color #ffffff> red.to_s # => "#ff0000" red.to_s(:rgb) # => "1.000, 0.000, 0.000"

Operations

The real value of Colorist comes in comparison and addition. You can use normal operators with the colors to add them together, subtract them, and compare them based on brightness. You can also do this with the string or numeric representations of colors:

red = 0xff0000.to_color green = 0x00ff00.to_color yellow = red + green yellow = "red".to_color + "green" yellow.to_s # => "#ffff00" red - 0.2 # => #<Color #cc0000>

Comparisons work off of the brightness of a given color. You can also calculate the contrast between two colors using the W3C’s formula:

red = "red".to_color red > "black".to_color # => true red > "white".to_color # => false red.contrast_with("green".to_color) # => 0.500653594771242

Get Coloring!

That’s most of the basic functionality, for all of the details you can view the RDoc on RubyForge. The source is available on GitHub and there is a Lighthouse project for any bugs or feature requests. Enjoy!

• Read more about We "Cheat" And So Should You

I’m the kind of guy who has a tendency to memorize where to find information instead of the information itself. It usually goes something like this:

google -> foo -> 3rd link -> middle of the page -> oh yeah -> profit$ google -> bar -> 2nd page -> 5th link -> sidebar 2nd link -> ahh yeah -> profit$

I love compulsive behavior as much as the next guy – but this does get old after a while, even looking up obscure Ruby methods and Bash commands to satisfy my questionable motivations. You can break the cycle; you can cheat the system.

Err the Cheat

‘cheat’ is a small utility app created by Chris Wanstrath (of Err and GitHub fame) that is basically a command line interface to a simple wiki. It was announced over a year ago and is built on _why’s excellent Camping ‘microframework’ with a YAML backend.

Anyone can create, edit, and modify cheat pages and anyone can call them up via the command line tool like so:

cheat foo

Installation

‘cheat’ is a gem and can be installed thusly:

sudo gem install cheat

You can check to make sure that everything is copacetic by issuing:

cheat cheat

If this works, you’re cheating.

Cheating

The first thing you should do is check out the all of the available cheat sheets. If there’s something you need that’s not in the list – by all means create your own, it benefits everyone (…or just you depending on how obscure the information is).

You can list the available sheets:

cheat sheets

Some sheets of interest include: sed,
awk, git, git-svn, vim, and of course acts_as_taggable_on.

You can call up any of the sheets by name using the cheat command:

cheat 'foo_sheet_title'

Note: each time you access a sheet for the first time it gets cached locally in a .cheat folder in your home folder (This is on OSX, this will still work on windows, but you need to have a HOMEDRIVE or HOMEPATH environment variable set).

Cheated

You can be compulsive and efficient at the same time – thanks Cheat! Instead of hitting google everytime you need that same obscure ruby/awk/sed/vi reference — just cheat and the system goes from:

google -> ??? -> profit$

to:

cheat foo -> profit$

Ditch the ambiguous question marks and accelerate your profit$, cheat.