Refinements arrived to Ruby trunk [here](https://bugs.ruby-lang.org/issues/4085.) The purpose of Refinements is to make monkey patching safer, extending core classes but limiting its effects to a particular area of code. Shugo Maeda wrote ...

"Refinements are similar to Classboxes.  However, Refinements doesn't
support local rebinding as mentioned later.  In this sense,
Refinements might be more similar to selector namespaces, but I'm not
sure because I have never seen any implementation of selector
namespaces.

In Refinements, a Ruby module is used as a namespace (or classbox) for
class extensions.  Such class extensions are called refinements.  For
example, the following module refines Fixnum."

You can read the long story here [https://bugs.ruby-lang.org/issues/4085](https://bugs.ruby-lang.org/issues/4085) So let's see how Refinements work in practice Basically instead of doing …

class Object
  def blank?
    respond_to?(:empty?) ? empty? : !self
  end
end

puts "".blank?
puts "hi".blank?
puts nil.blank?
puts [].blank?
puts [1].blank?

and polluting all the objects, you can do ...

module Blank
  refine Object do
    def blank?
      respond_to?(:empty?) ? empty? : !self
    end
  end
end

class A
  using Blank

  puts "".blank?   # => true
  puts "hi".blank? # => false
  puts nil.blank?  # => true
  puts [].blank?   # => true
  puts [1].blank?  # => false
end

and monkey patch in a controlled way. You can also check that you won't be polluting all the objects in your system by checking …

class B
  puts "".blank?
  puts "hi".blank?
  puts nil.blank?
  puts [].blank?
  puts [1].blank?
end

This will raise an undefined method `blank?' for [](String) (NoMethodError). Refinements has been committed to ruby by Shugo Maeda, but it may be reverted for Ruby 2.0. The Ruby Core is asking for feedback, so, what are the use cases you see Refinements is good for you? You can learn more about Refinements reading [Refinements in practice, a blog post from Yehuda Katz](http://yehudakatz.com/2010/11/30/ruby-2-0-refinements-in-practice/)

**[rails-api](https://github.com/spastorino/rails-api)** is a plugin developed by Yehuda Katz, José Valim, Carlos Antonio da Silva and me (Santiago Pastorino) which modifies Rails applications trimming down usually unneeded Rails functionalities for API applications. Do you remember we added support for this on core and [it was reverted](https://github.com/rails/rails/commit/6db930cb5bbff9ad824590b5844e04768de240b1)?. This plugin enables that again. ### What is an API app? Traditionally, when people said that they used Rails as an "API", they meant providing a programmatically accessible API alongside their web application. For example, GitHub provides [an API](http://developer.github.com/) that you can use from your own API clients. ### Why using this instead of Rails? Because you don't need the entire Rails middleware stack. Specifically you won't need middleware that are meant for browser applications. For example you probably won't need cookies support, but you can add that back if you want. You don't need most of the functionality provided by ActionController::Base like template generation for instance. And you won't need generated views, helpers and assets. The plugin also skips the asset pipelining. ### Configuration #### For existing Rails applications you need … 1. To add gem 'rails-api' to your Gemfile 2. Make *ApplicationController* inherit from *ActionController::API* instead of *ActionController::Base*. As with middleware, this will leave out any *ActionController* module that provides functionality primarily used by browser applications. 3. Remove respond_to from your controllers and just use render :json instead. #### For new apps Install the gem if you haven't already: gem install rails-api Then generate a new **Rails API** application: rails-api new my_api And that's it, when you use the generators by default controllers will respond to json only. ### Middlewares An api application comes with the following middlewares by default. * *Rack::Cache*: Caches responses with public *Cache-Control* headers using HTTP caching semantics. * *Rack::Sendfile*: Uses a front-end server's file serving support from your Rails application. * *Rack::Lock*: If your application is not marked as threadsafe (`config.threadsafe!`), this middleware will add a mutex around your requests. * *ActionDispatch::RequestId* * *Rails::Rack::Logger* * *Rack::Runtime*: Adds a header to the response listing the total runtime of the request. * *ActionDispatch::ShowExceptions*: Rescue exceptions and re-dispatch them to an exception handling application. * *ActionDispatch::DebugExceptions*: Log exceptions. * *ActionDispatch::RemoteIp*: Protect against IP spoofing attacks. * *ActionDispatch::Reloader*: In development mode, support code reloading. * *ActionDispatch::ParamsParser*: Parse XML, YAML and JSON parameters when the request's *Content-Type* is one of those. * *ActionDispatch::Head*: Dispatch *HEAD* requests as *GET* requests, and return only the status code and headers. * *Rack::ConditionalGet*: Supports the `stale?` feature in Rails controllers. * *Rack::ETag*: Automatically set an *ETag* on all string responses. This means that if the same response is returned from a controller for the same URL, the server will return a *304 Not Modified*, even if no additional caching steps are taken. This is primarily a client-side optimization; it reduces bandwidth costs but not server processing time. Other plugins, including *ActiveRecord*, may add additional middlewares. In general, these middlewares are agnostic to the type of app you are building, and make sense in an API-only Rails application. You can get a list of all middlewares in your application via: rake middleware #### Other Middlewares Rails ships with a number of other middlewares that you might want to use in an API app, especially if one of your API clients is the browser: * *Rack::MethodOverride*: Allows the use of the *_method* hack to route POST requests to other verbs. * *ActionDispatch::Cookies*: Supports the *cookie* method in *ActionController*, including support for signed and encrypted cookies. * *ActionDispatch::Flash*: Supports the *flash* mechanism in *ActionController*. * *ActionDispatch::BestStandards*: Tells Internet Explorer to use the most standards-compliant available renderer. In production mode, if ChromeFrame is available, use ChromeFrame. * Session Management: If a *config.session_store* is supplied, this middleware makes the session available as the *session* method in *ActionController*. Any of these middlewares can be added via: config.middleware.use Rack::MethodOverride #### Removing Middlewares If you don't want to use a middleware that is included by default in the api middleware set, you can remove it using *config.middleware.delete*: config.middleware.delete ::Rack::Sendfile Keep in mind that removing these features may remove support for certain features in *ActionController*. ### Choosing Controller Modules An api application (using *ActionController::API*) comes with the following controller modules by default: * *ActionController::UrlFor*: Makes *url_for* and friends available * *ActionController::Redirecting*: Support for *redirect_to* * *ActionController::Rendering*: Basic support for rendering * *ActionController::Renderers::All*: Support for *render :json* and friends * *ActionController::ConditionalGet*: Support for *stale?* * *ActionController::ForceSSL*: Support for *force_ssl* * *ActionController::RackDelegation*: Support for the *request* and *response* methods returning *ActionDispatch::Request* and *ActionDispatch::Response* objects. * *ActionController::DataStreaming*: Support for *send_file* and *send_data* * *AbstractController::Callbacks*: Support for *before_filter* and friends * *ActionController::Instrumentation*: Support for the instrumentation hooks defined by *ActionController* (see [the source](https://github.com/rails/rails/blob/master/actionpack/lib/action_controller/metal/instrumentation.rb) for more). * *ActionController::Rescue*: Support for *rescue_from*. Other plugins may add additional modules. You can get a list of all modules included into *ActionController::API* in the rails console: ActionController::API.ancestors - ActionController::Metal.ancestors #### Adding Other Modules All Action Controller modules know about their dependent modules, so you can feel free to include any modules into your controllers, and all dependencies will be included and set up as well. Some common modules you might want to add: * *AbstractController::Translation*: Support for the *l* and *t* localization and translation methods. These delegate to *I18n.translate* and *I18n.localize*. * *ActionController::HTTPAuthentication::Basic* (or *Digest* or *Token*): Support for basic, digest or token HTTP authentication. * *AbstractController::Layouts*: Support for layouts when rendering. * *ActionController::MimeResponds*: Support for content negotiation (*respond_to*, *respond_with*). * *ActionController::Cookies*: Support for *cookies*, which includes support for signed and encrypted cookies. This requires the cookie middleware. The best place to add a module is in your *ApplicationController*. You can also add modules to individual controllers. ### How can I help? Go to the project url [https://github.com/spastorino/rails-api](https://github.com/spastorino/rails-api) and report issues, test it in real apps and provide bug fixes. We have been measuring the plugin against some applications and we will post more about the results later. Meanwhile, if you can test it and share the improvements you found in your apps, would be awesome. To be able to add this functionality to core we need the plugin to show significant performance improvements for real API applications, so it's important to let us know about your results. <3 <3 <3 Find me at RailsConf. Tenderlove and I are giving out hugs for free! **Update #1**: Wycats who after working with us (South American rubyists) is known as wygatos (figure our why :P), is adhering to the campaign of giving hugs for free.

In this opportunity I'll explain (as the title suggests) how to go from a brand new mac os x to running Rails tests. Step 0, is to make sure that locale returns

LANG="en_US.UTF-8"
LC_COLLATE="en_US.UTF-8"
LC_CTYPE="en_US.UTF-8"
LC_MESSAGES="en_US.UTF-8"
LC_MONETARY="en_US.UTF-8"
LC_NUMERIC="en_US.UTF-8"
LC_TIME="en_US.UTF-8"
LC_ALL=

(you'll get some unexpected errors later on if not). To do so, you can either set the Language to one that Mac OS X sets UTF-8 by default, like United States from the System Preferences panel. Or, you can run

$ export LC_ALL=en_US.UTF-8
$ export LANG=en_US.UTF-8

to achieve that. Step 1, install Xcode. Step 2, install osx-gcc-installer from https://github.com/kennethreitz/osx-gcc-installer Step 3, So now you're ready to install Homebrew, by doing:

$ /usr/bin/ruby -e "$(/usr/bin/curl -fksSL https://raw.github.com/mxcl/homebrew/go)"

Now this is how to install some common libraries Step 4, We need to first have git in order run the brew doctor, so

$ brew install git

You can make sure that everything is ok by running

$ brew doctor

at any time. It should return 'Your system is raring to brew' when in optimal conditions. Step 5, now to install the rest of the libraries

$ brew install memcached mysql postgresql

Step 6, initializing the mysql and postgres databases must be done by doing

$ initdb /usr/local/var/postgres
$ mysql_install_db --verbose --user=`whoami` --basedir="$(brew
--prefix mysql)" --datadir=/usr/local/var/mysql --tmpdir=/tmp

Step 7, I like having some aliases to load/unload mysql, postgres and memcached. To do so, you should add the following lines to your ~/.zshrc

alias memcached_load="launchctl load -w /usr/local/Cellar/memcached/1.4.13/homebrew.mxcl.memcached.plist"
alias memcached_unload="launchctl unload -w /usr/local/Cellar/memcached/1.4.13/homebrew.mxcl.memcached.plist"
alias mysql_load="launchctl load -w /usr/local/Cellar/mysql/5.5.20/homebrew.mxcl.mysql.plist"
alias mysql_unload="launchctl unload -w /usr/local/Cellar/mysql/5.5.20/homebrew.mxcl.mysql.plist"
alias postgres_load="launchctl load -w /usr/local/Cellar/postgresql/9.1.3/homebrew.mxcl.postgresql.plist"
alias postgres_unload="launchctl unload -w /usr/local/Cellar/postgresql/9.1.3/homebrew.mxcl.postgresql.plist"

Step 8, Now you're good to go. Next we'll install rbenv to easily switch between multiple versions of Ruby. You can also choose to use RVM or roll your own.

$ brew install rbenv ruby-build

Step 9, Add

export PATH=$HOME/.rbenv/bin:$PATH
eval "$(rbenv init -)"

to your ~/.zshrc. Step 10, now do the following to install ruby

$ rbenv install 1.9.3-p125

Step 11, you need to

$ rbenv global 1.9.3-p125
$ rbenv rehash

Step 12, Cool, so now we are good to go and setup Rails.

$ git clone https://github.com/rails/rails.git
$ gem install bundler
$ rbenv rehash
$ cd rails
$ bundle

Step 13, now, from the Contributing to Rails Guide, you should

$ mysql_load
$ postgres_load
$ mysql -u root
mysql> GRANT ALL PRIVILEGES ON activerecord_unittest.* to 'rails'@'localhost';
mysql> GRANT ALL PRIVILEGES ON activerecord_unittest2.* to 'rails'@'localhost';
exit
$ cd activerecord
$ rake mysql:build_databases
$ rake postgresql:build_databases

And that's it!, we have Ruby, MySQL, PostgreSQL, Memcached, and everything needed to do some Rails development. Step 14, we need to load Memcached for its needed for some tests by doing

$ memcached_load 

Step 15, and lastly, you can run Rails tests by doing

$ rake

at the top of the rails directory. Everything should work just fine, or at least you should get the same results as the [Rails CI.](http://travis-ci.org/#!/rails/rails) Congratulations!

*TL;DR*: don't run *bundle exec* before *rails* command, rails already checks the presence of *Bundler* through the *Gemfile* and sets up everything according to it without the overhead of *bundle exec_. _rails* command is the only exception to the rule. Additionally I've added a [patch](https://github.com/carlhuda/bundler/commit/2c838255ccadadeab5298b7c2bbc39035e59f248) to *Bundler* that avoids calling Bundler.setup which adds unnecessary overhead. I was researching on a huge *Bundler 1.1* performance regression, [@masterkain](http://twitter.com/masterkain) was hitting when running *bundle exec rails runner ''* (you shouldn't run bundle exec before the *rails* command, but keep reading for now). I started to profile it using *ruby-prof* and one of the things I realized was that *Bundler.setup* (which is a considerable slow method because it calls [Bundler::Runtime#setup](https://github.com/carlhuda/bundler/blob/2a38a24a295b6e978f0c982d454a3a9f11399abc/lib/bundler/runtime.rb#L7-42)) was ran 3 times. My first reaction was WTF?? 3 times??. I will write about my other findings in another blog post. After analyzing the code, I found out that the first call to *Bundle.setup* is in [Bundler::CLI#exec](https://github.com/carlhuda/bundler/blob/2a38a24a295b6e978f0c982d454a3a9f11399abc/lib/bundler/cli.rb#L398) right before shelling out to run _rails runner ''_. The second call is on [boot.rb](https://github.com/rails/rails/blob/d2abe28ed342443f8c374a6e02977ccb0c3b3f95/railties/lib/rails/generators/rails/app/templates/config/boot.rb#L6) as part of the boot process (well actually it's required from *bundle exec* through [this rubyopt](https://github.com/carlhuda/bundler/blob/2a38a24a295b6e978f0c982d454a3a9f11399abc/lib/bundler/runtime.rb#L227) and on boot.rb the require returns false because it's already required). And the last call starts on [config/application.rb](https://github.com/rails/rails/blob/d2abe28ed342443f8c374a6e02977ccb0c3b3f95/railties/lib/rails/generators/rails/app/templates/config/application.rb#L17) which ends up calling [Bundler.require](https://github.com/carlhuda/bundler/blob/2a38a24a295b6e978f0c982d454a3a9f11399abc/lib/bundler.rb#L120-122) to finally call *Bundler.setup* for the third time. The second and third calls are run on the same process so *Bundler.setup* caches the result in [@setup](https://github.com/carlhuda/bundler/blob/2a38a24a295b6e978f0c982d454a3a9f11399abc/lib/bundler.rb#L105) so there's no slow down between those 2 calls. But the command passed to *bundle exec* runs in a different process (remember I said before that we were shelling out to run *rails runner ''_) so the resulting execution of the first _Bundler.setup* won't be available to the [rails runner process" and doesn't make any sense. All that *bundle exec* needs to do is to "setup the rubyopts](https://github.com/carlhuda/bundler/blob/2a38a24a295b6e978f0c982d454a3a9f11399abc/lib/bundler/runtime.rb#L209-231) needed to run the command you are passing to *bundle exec_. I've [patched](https://github.com/carlhuda/bundler/commit/2c838255ccadadeab5298b7c2bbc39035e59f248) _Bundler* to do the right thing. So don't run *bundle exec* before *rails* command, this command is already aware of *Bundler* and sets up everything according to what you have on your _Gemfile_. If you prepend *bundle exec* before *rails* command all you will be adding is overhead of opening another process from *Bundler* and executing useless code since *rails* already does the right thing. You probably already know about that, but I've seen a lot of proficient Rails developers doing it. Read more about the topic in [Yehuda's blog](http://yehudakatz.com/2011/05/30/gem-versioning-and-bundler-doing-it-right/)

We're opening the box of RailsConf 2010 memories! Yep ... we suck at journalism, so it turns out we have this almost one year old interview with Caike Souza we never shared before. So sorry Caike! Caike ([@caike](http://twitter.com/caike)) is a passionate agile software craftsman and founder of the [Orlando Code Dojo](http://orlandodojo.org/) group, where programmers get together to practice coding to improve their skills once a month. He is currently working at [Envy Labs](http://envylabs.com/.) Thanks for your time and great vibe!

Time has come for me to write a Rails generator, and as you're guessing right now, my first step was taking a look at the [Guides](http://guides.rubyonrails.org/generators.html.) They give you a pretty good idea on what you can do (despite of being for Rails 3.0), but as my friend Santiago always say, there's no better documentation than the source code itself. So, my second step was to dive into the [code](http://github.com/rails/rails/tree/2-3-stable/railties/lib/rails_generator/.) You should definitely read the code, great stuff there. After some time reading, I decided it was time for me to start playing around with that, so here it comes: First thing you should know, is that all Rails generators are derived from a class called “Rails::Generator::Base.” But, if we derive our generator class from NamedBase instead of Base, then we’ll get the ability to take a name parameter from the script/generate command line. With that in mind, you can start writing the generator *skeleton*:

class WidgetGenerator < Rails::Generator::NamedBase
  def manifest
    record do |m|
      # Do something
    end
  end
end

In order to make the generator work on your Rails 2.3 application, you should place this file under **'lib/generators/widget/widget_generator.rb'** Is on the manifest method where the magic occurs. Depending on what exactly we want our generator to do, is what we're going to code inside it. In my case, I wanted to behave very similar to the scaffold, so I wanted a controller class, a model, views, migration, etc... You can look at the templates of the scaffold generator, they will give you a very clear idea on how to use them. Then, you should place your templates under **'lib/generators/widget/templates/'** In most cases, you will want your generator to receive several arguments. Best way is to have an initialize method to take care of that, just like this:

class WidgetGenerator < Rails::Generator::NamedBase
  attr_reader   :controller_class_name,
                :class_name
  attr_accessor :attributes
  
def initialize(runtime_args, runtime_options = {})
    super
    @name = runtime_args.first
    @controller_class_name = @name.pluralize.capitalize
    @attributes = []

    runtime_args[1..-1].each do |arg|
      if arg.include? ':'
        @attributes << Rails::Generator::GeneratedAttribute.new(*arg.split(":"))
      end
    end
  end

  def manifest
    record do |m|
      # Do something
    end
  end
end

Until now, we're just initializing the generator, but it's not doing anything yet. Let's add some action on our manifest method:

def manifest
    record do |m|
      m.template('controller.rb', "app/controllers/#{name.pluralize}_controller.rb")
      m.template('model.rb', "app/models/#{name}.rb")
      m.migration_template("migration.rb", "db/migrate", :migration_file_name => "create_#{name.underscore.pluralize.camelize}")

      m.directory(File.join('app/views', name.pluralize))
      for action in %w[ new edit show ]
        m.template(
          "view_#{action}.html.erb",
          File.join('app/views', controller_file_name, "#{action}.html.erb")
        )
      end
    end
  end

Cool, now we are generating a controller from our template, a model, a migration, among others...Nice! You can also add a protected banner method, to display the usage of the generator right on the console:

protected
    def banner
      "Usage: #{$0} widget WidgetName [field:type, field:type]"
    end

And that's all !! You can now generate all the widgets you want. The command to run this would be:

$ ./script/generate widget MyWidget title:string viewing:integer

Have fun generating!!

Among the great people we met at the RailsConf was George Guimarães ([@georgeguimaraes](http://twitter.com/georgeguimaraes)), by no surprise he was a very cool and funny dude, and he was open to talk and hang around with us. George is co-founder of [Plataforma Tec](http://plataformatec.com.br/), that many of us got to know well through their amazing set of gems/plugins and the stunning work José Vailm has been doing as a Rails Core team member. Kind of what I hope it's happening with the great work Santiago Pastorino is doing with his contributions and how it's reinforcing WyeWorks reputation. But still there are a lot of guys behind the scenes that support this great Open Source effort that's being carried in these companies, probably not so much by direct intervention but with more hard and 'real' work as we like to say to joke around and bother the OSS guys. The kind of work that pay the bills :P Not that George doesn't do OSS, actually he's currently involved in the development of [Restfulie](http://github.com/caelum/restfulie) that got many people pretty excited at the RailsConf this year, and much more stuff. Hope you enjoy this not so serious take. Thanks George!

In the last day of the RailsConf 2010 Santiago and I got the pleasure to hang out a few hours with Fabio Akita, a very successful guy in the Ruby and Rails community, but yet so humble and open as many of the great people we met in these past days. Fabio is well known as a great evangelist of this movement, as a great speaker, for his bundle of plugins for the vim editor but also for carrying interviews with important people of the community on every conference he attends. The thing is that personally I never got to see him as the subject of the interview, and he is a wise guy that has a lot to say. So even though he was very tired, he accepted to do this improvised short interview with me, almost the first time I was holding a camera. This is the first of a small series of interviews that will be posted soon. I hope you all enjoy it and share his thoughts on what are the good things that makes this community so special, so that we never loose that spirit. Thanks Fabio!

I was working lately on a Sinatra project, and got fascinated on how fast you can get things up and running. Everything was beautiful, until I tried to upload a file using paperclip. Although Paperclip was originally built for rails [Ken Robertson](http://invalidlogic.com/dm-paperclip/) ported it to Datamapper. Let me explain in few steps how you can upload with Paperclip, using Datamapper. Start declaring your model like this:

class Resource
  include DataMapper::Resource
  include Paperclip::Resource

  property :id,     Serial

  has_attached_file :file,
                    :url => "/system/:attachment/:id/:style/:basename.:extension",
                    :path => "#{APP_ROOT}/public/system/:attachment/:id/:style/:basename.:extension"
end

You'll need to specify your :url and :path options as the ones built into dm-paperclip are merb centric which won't quite work. Also set APP_ROOT to where ever your application root directory with your static Sinatra folder is. Now your routes should look something like this:

post '/upload' do
  resource = Resource.new(:file => make_paperclip_mash(params[:file]))
  halt "There were some errors processing your request..." unless resource.save
end

And there's the tricky part, on the **make_paperclip_mash** method. Paperclip expects the file object loaded from the form to be in a different form than what is created by default. To fix this you should create a Mash (which is just a Hash, unless you're actually using merb):

def make_paperclip_mash(file_hash)
  mash = Mash.new
  mash['tempfile'] = file_hash[:tempfile]
  mash['filename'] = file_hash[:filename]
  mash['content_type'] = file_hash[:type]
  mash['size'] = file_hash[:tempfile].size
  mash
end

And that's it, now you can upload files using Paperclip right on your Sinatra app with Datamapper. You can check out the code of this example at: [sinatra_paperclip.rb](http://gist.github.com/291877)

For past few days we had been working on the new version of the WyeWorks site, so stay tunned. This new version will have a twitter section, where the last 5 tweets of our team will be displayed. So first thing I had to do was installing the twitter gem:

gem install twitter

In order to achieve this, I've found 3 different ways using the twitter gem, plus one not yet implemented on the gem, that I've already proposed the patch. The dumbest one would be:

#!/usr/bin/env ruby

require 'rubygems'
require 'twitter'

users = %w(wyeworks spastorino joseicosta smartinez87 nartub)

tweets = users.map { |user_name| Twitter::Search.new.from(user_name) }.
               inject([]) { |tweets, search| tweets + search.fetch(5).results }.
               sort { |t1, t2| Date.parse(t2.created_at) <=> Date.parse(t1.created_at) }[0,5]

tweets.each do |tweet|
  puts tweet.created_at
  puts tweet.from_user
  puts tweet.profile_image_url
  puts tweet.text
end

What this does is retrieve the last 5 tweets of each user and merge them sorted by date. Obviously, best thing to do would be directly retrieving the last 5 tweets from the @wyeworks/team list. Only way to do this using the gem requires authentication, despite the list being public. In order to authenticate, we may take two paths, the first one would be using HTTP Authentication:

#!/usr/bin/env ruby

require 'rubygems'
require 'twitter'

httpauth = Twitter::HTTPAuth.new('wyeworks', 'password')
base = Twitter::Base.new(httpauth)
base.list_timeline('wyeworks', 'team', :page => 1, :per_page => 5).each do |tweet|
  puts tweet.created_at
  puts tweet.user.screen_name
  puts tweet.user.profile_image_url
  puts tweet.text
end

The other and preferred way for authentication is OAuth, since we don't have to send the user and password through the network. In order to make OAuth work with twitter, we have to create an application at [http://twitter.com/apps](http://twitter.com/apps) Once we've created the app, twitter provides us with a Consumer Key and a Consumer Secret, needed to authenticate using OAuth

#!/usr/bin/env ruby

require 'rubygems'
require 'twitter'

oauth = Twitter::OAuth.new('consumer token', 'consumer secret')

begin
  oauth.authorize_from_access(oauth.request_token.token, oauth.request_token.secret)

  base = Twitter::Base.new(oauth)
  base.list_timeline('wyeworks', 'team', :page => 1, :per_page => 5).each do |tweet|
    puts tweet.created_at
    puts tweet.user.screen_name
    puts tweet.user.profile_image_url
    puts tweet.text
 end
rescue OAuth::Unauthorized
  puts "> FAIL!"
end

Either of these ways works just fine, but no one completely satisfied me, since we are working with a **public** list, so as far as I can see authentication is out the question, even more when anyone can see it directly from the web without authenticating. For this reason, I started looking at the [Twitter API](http://apiwiki.twitter.com) searching for a non-authentication way to do it: [Here's](http://apiwiki.twitter.com/Twitter-REST-API-Method:-GET-list-statuses) what I found. You can test that making a request to [http://api.twitter.com/1/wyeworks/lists/team/statuses.json?page=1&per_page=5](http://api.twitter.com/1/wyeworks/lists/team/statuses.json?page=1&per_page=5), obtaining the list as a json, or xml in case you change the .json to .xml So I've came up with this monkey-patch:

module Twitter
  # :per_page = max number of statues to get at once
  # :page = which page of tweets you wish to get
  def self.list_timeline(list_owner_username, slug, query = {})
    response = HTTParty.get("http://api.twitter.com/1/#{list_owner_username}/lists/#{slug}/statuses.json", :query => query, :format => :json)
    response.map{|tweet| Hashie::Mash.new tweet}
  end
end

Being able to get the list without authenticating by:

Twitter.list_timeline('wyeworks', 'team', :page => 1, :per_page => 5).each do |tweet|
   puts tweet.created_at
   puts tweet.user.screen_name
   puts tweet.user.profile_image_url
   puts tweet.text
end

I've already contacted the gem's authors, proposing this patch: [http://github.com/spastorino/twitter/commit/aed3a298b613a508bb9caf93afc7f12c50626ad7](http://github.com/spastorino/twitter/commit/aed3a298b613a508bb9caf93afc7f12c50626ad7.) Wynn Netherland already told me it's pretty probable that it will be approved. Until then, you can make use of this functionality from my fork [http://twitter.com/spastorino/twitter](http://twitter.com/spastorino/twitter) **UPDATE #1:** My fork was merged into [http://github.com/jnunemaker/twitter](http://github.com/jnunemaker/twitter) master branch and twitter 0.8.3 was published through [Gemcutter](http://gemcutter.org/gems/twitter)

As many of you must know, last weekend a [Railsbridge Bugmash](http://bugmash.com) was celebrated, and I had the honor to be part of it for the first time. For those who are not aware about what this is, it's a virtual event that takes place on irc.freenode.net at #railsbridge channel. The general idea of these events is to work on the Rails Core, taking a look at the [Rails Issue Tracker](https://rails.lighthouseapp.com/projects/8994-ruby-on-rails/overview.) However, given that Rails 3 is about to see the light, this opportunity was intended to deeply test it looking for: * Fix a known issue * Report a bug * Make sure your favorite gem or plugin still works. If not, fork it and make it so. * Write a blog post about a certain component * Write some documentation * Get an app up and running and document what you had to do to upgrade. * Create a screencast Each accepted contribution or patch done by a participant, gives him chances to win one of several [prizes](http://bugmash.com/sponsors), the more contributions the more chances you have to win. For further details check out the [Railsbridge Bugmash Guide](http://railsbridge.org/BugMashGuide.pdf) and the [RailsBridge Wiki](http://wiki.railsbridge.org.) Many bugs were fixed during the event, some [plugins and gems were tested](http://wiki.rubyonrails.org/rails/version3/plugins_and_gems), really interesting discussions took place (specially regarding [generators](http://guides.rails.info/generators.html)) and some other articles were made. To mention some: * [Making Generators for Rails 3 with Thor](http://caffeinedd.com/guides/331-making-generators-for-rails-3-with-thor) * [Getting Started with the Rails 3 Bugmash](http://blog.envylabs.com/2010/01/getting-started-with-the-rails-3-bugmash) * [Getting Rails 3 (pre) up on OSX](http://jamesarosen.com/post/339319063) * [Rails 3 and Passenger](http://cakebaker.42dh.com/2010/01/17/rails-3-and-passenger) * [Upgrading an Application to Rails 3 - Part 1](http://caffeinedd.com/guides/348-upgrading-to-rails-3) * [Customizing your scaffold template become easier in Rails3](http://zigzag.github.com/2010/01/18/customizing-your-scaffold-template-become-easier-in-rails3.html) * [Let your SQL Growl in Rails 3](http://hasmanyquestions.wordpress.com/2010/01/17/let-your-sql-growl-in-rails-3) * [Rails Bugmash 2010](http://blog.trydionel.com/2010/01/16/rails-bugmash-2010) * [migrating a rails app from 2.x to 3.0](http://www.madcowley.com/madcode/?p=12) * [Notes from Rails 3 bugmash](http://blazingcloud.net/2010/01/17/notes-from-rails-3-bugmash) * [Notes from the field upgrading to Rails 3](http://rails3.community-tracker.com/permalinks/5/notes-from-the-field-upgrading-to-rails-3) And then Jose Valim, motivated by the posts done regarding rails 3 generators, published one himself called [Discovering Rails 3 Generators](http://blog.plataformatec.com.br/2010/01/discovering-rails-3-generators) This was my first participation and it was a bloody great experience. During the event I was specially devoted to search bugs on Rails 3 and try to patch them. I managed myself to find 4 code bugs and 1 documentation bug, proposing a solution for all of them. One of them was not approved though, for there was a bigger problem that required José Valim's intervention, the 3 other patches were approved. I would also want to highlight the gigantic work done by the organizers, the core team members, and also to all the participants. I strongly valued the support [José Valim](http://twitter.com/josevalim), [Pratik Naik](http://twitter.com/lifo) and [Michael Koziarski](http://twitter.com/nzkoz) gave me. They were a hell of a help when trying to find solutions for the bugs. Would also want to thank [Ryan Bigg](http://twitter.com/ryanbigg) for his cooperation, and specially to [Sam Elliott](http://twitter.com/lenary), an incredible 18 year old guy with a great future ahead. Besides working together with Ryan and Sam, we kept a really nice chat during almost the entire bugmash. The awesome will to help at #railsbridge really overwhelmed me, where everybody was willing to help each other, something that makes it so much easier for the ones starting to contribute to Rails. I would also want to congrat and thank all the participants for trying to make Rails better. So don't hesitate to join the next time, it's not as hard as I expected it to be and you would definitely not regret it. Now I'm really motivated to help others so I'm going to join to [Rails Mentors](http://www.railsmentors.org) on [RailsBridge](http://www.railsbridge.com) to give back the good things I received during this experience.

Well i guess many of you might have checked the last edition of the [Rails Magazine](http://railsmagazine.com/issues/4.) If not, you may should. In particular one of the articles by Rodrigo Rosenfeld Rosas talks about PDF generation with odf templates, something I've been playing around in the last few weeks. He explains the mechanism that can be used for this purpose and finally mentions the **odf-report** gem by Sandro Duarte which i've been using and forked to add support for image substitutions. *More info here*: [http://github.com/josecosta/odf-report](http://github.com/josecosta/odf-report) Give it a try! **UPDATE** Fork was merged to [master branch](http://github.com/sandrods/odf-report.)

I'd like to share with the community my emacs init file and a set of plugins to give a nicer experience on Ruby on Rails development, which you can checkout from http://github.com/spastorino/my_emacs_for_rails/tree/master. I have been using this environment under emacs 23, and it has not been tested on other emacs versions, so all feedback is welcome, if something goes wrong please feel free to contact me. ## What's in the package? The package provides my customized Emacs init file and some plugins I found very useful to enhance Ruby on Rails development experience. ### Plugins * anything * auto-complete * autotest * [cedet](http://cedet.sourceforge.net/) * color-theme * [ecb](http://ecb.sourceforge.net/) * find-recursive * flymake * javascript * [nxhtml](http://ourcomments.org/Emacs/nXhtml/doc/nxhtml.html) * [rcodetools](http://eigenclass.org/hiki.rb?rcodetools) * rdebug * redo * ri-emacs * [rinari](http://rinari.rubyforge.org/) * ruby-block * ruby-mode * toggle * yaml-mode * [yasnippet](http://code.google.com/p/yasnippet/) * [yasnippets-rails](http://github.com/eschulte/yasnippets-rails/tree/master) ## Installation Before you can use some plugins you have to install a few packages: To use rcodetools you need to install the rcodetools, gem with

sudo gem install rcodetools

To use autotest you need the ZenTest gem, install it with

sudo gem install ZenTest

On further post I'm going to explain how to set it up under the gnome environment using all the beauty that gnome-notifier has. Checkout the package

git clone github.com/spastorino/my_emacs_for_rails

and copy all the files under my_emacs_for_rails directory to ~/.emacs.d directory if it doesn't exist you have to create it. ## Screenshot You can see here some screenshots to get a taste of the look and feel that this one has. !http://blog.wyeworks.com/assets/2009/9/11/emacs-screenshot.png!:http://blog.wyeworks.com/assets/2009/9/11/emacs-screenshot-full.png

Scheduling tasks is something we all need to know to do, for it's quite common in applications. Fetching feeds, indexing some data, processing files at a periodical time, that happens a lot. You are probably quite familiar then with the linux cron, if you had to deal with scheduling stuff in the past, but there is something you may not. Let me introduce you the [*Whenever*(Whenever)](http://github.com/javan/whenever/tree/master) gem. What is it? A simple gem to schedule tasks writing them in nice ruby syntax...just let the gem work it's magic and deal with the cron. In order to install it, you have to add first the github source, only if you never done it :

$ gem sources -a http://gems.github.com
$ sudo gem install javan-whenever

To get started, just place yourself in the app path and type

$ wheneverize . 

This will create an initial config/schedule.rb for you. There you can nicely write tasks to run. Some examples are:

every 3.hours do
    runner "MyModel.some_process"
    rake "my:rake:task"
    command "/usr/bin/my_great_command"
  end

  every 1.day, :at => '4:30 am' do
    runner "MyModel.task_to_run_at_four_thirty_in_the_morning"
  end

  every :hour do # Many shortcuts available: :hour, :day, :month, :year, :reboot
    runner "SomeModel.ladeeda"
  end

  every :sunday, :at => '12pm' do # Use any day of the week or :weekend, :weekday
    runner "Task.do_something_great"
  end

Another nice thing to do is integrate it with Capistrano.

 after "deploy:symlink", "deploy:update_crontab"

  namespace :deploy do
    desc "Update the crontab file"
    task :update_crontab, :roles => :db do
      run "cd #{release_path} && whenever --update-crontab #{application}"
    end
  end

The official documentation provides this way to integrate it, but we found some little details, and the solution is here for you. If you integrate it by the regular way, when making multiple deploys, it will configure several tasks to run in your cron file. Why? Because the path of the current application changed, and the gem uses the path (by adding a comment line) when updating the cron. What should we do then? Simple, change the **run** line with this:

run "cd #{current_path}; whenever -i #{current_path}/config/schedule.rb"

What have we done? We used the -i option, which makes an update, but passing the comment we want, and make it not to change in every deploy. Feel free to try it and leave your comments !!

I know there are several discussions on the usage of method_missing in Ruby. In this post i'll present a pretty simple, yet useful solution that uses method_missing to interact with the [Brightcove Media Read API(Getting Started with the Media API)](http://support.brightcove.com/en/docs/getting-started-media-api) (you don't need to be familiar with this service, i'll explain a little bit in the next few lines). [Brightcove Media Read API(Getting Started with the Media API)](http://support.brightcove.com/en/docs/getting-started-media-api) accepts calls of the form:

http://api.brightcove.com/services/library?command=find_all_videos
&token=0Z2dtxTdJAxtbZ-d0U7Bhio2V1Rhr5Iafl5FFtDPY8E.

http://api.brightcove.com/services/library?command=find_related_videos
&video_id=123123&token=0Z2dtxTdJAxtbZ-d0U7Bhio2V1Rhr5Iafl5FFtDPY8E.

http://api.brightcove.com/services/library?command=find_videos_by_text
&text=sometextsample&pageSize=100&token=0Z2dtxTdJAxtbZ-d0U7Bhio2V1Rhr5Iafl5FFtDPY8E.

A token must be passed on each call, and you could also add more parameters like you would do in a regular GET request. What comes back is a JSON string that can be easily picked up. The key thing here is to notice that there are several commands you could execute from the [API](http://docs.brightcove.com/en/media/#Video_Read), naturally each with its own name that must be specified in the request right after [command=". Since the "API](http://docs.brightcove.com/en/media/#Video_Read) also provides a set of error codes to address all wrong requests or non-existent commands requests, we simply wanted to forward all the calls to the [API](http://docs.brightcove.com/en/media/#Video_Read) and reply back with its answer. So, in order to avoid defining all [API](http://docs.brightcove.com/en/media/#Video_Read) methods in our Ruby module, we just used the method_missing and forwarded all calls to it, using the name of the method as the [API](http://docs.brightcove.com/en/media/#Video_Read) command. The idea was that a call like:

http://api.brightcove.com/services/library?command=find_videos_by_user_id
&user_id=34876423&token=0Z2dtxTdJAxtbZ-d0U7Bhio2V1Rhr5Iafl5FFtDPY8E.

became just:

Brightcove::ReadProxy.find_videos_by_user_id :user_id => 34876423

We then implemented what we called the Brightcove::ReadProxy in a few lines like shown below:

module Brightcove
  module ReadProxy

    TOKEN = '0Z2dtxTdJAxtbZ-d0U7Bhio2V1Rhr5Iafl5FFtDPY8E.'
    SITE = 'http://api.brightcove.com/services/library'

    def self.method_missing(method_id, *args)
      args[0] ||= { }
      args[0].merge!({ :command => method_id, :token => TOKEN })
      get SITE, args[0]
    end

    def self.get(url, params)
      http_client = HTTPClient.new
      result = http_client.get(url, params)
      content = nil
      begin
        content = JSON.parse(result.content)
      rescue Exception => e
        Rails.logger.error e.message
      end
      return content
    end
 
 end

Basically all the magic relies in the method_missing that would convert any call to the Brightcove::ReadProxy module in the format accepted by the [API](http://docs.brightcove.com/en/media/#Video_Read), without having to define every [API](http://docs.brightcove.com/en/media/#Video_Read) method and maintaining the Rails like finders syntax. We also used the httpclient gem to simplify the GET request calls and the json gem to parse the result of the call. I'm not saying that this is the best usage, but i think in this particular situation it suits pretty well. What do you think?

Time has come for us to make a sortable list, and let's face it, drag&drop are the prettiest ones. So, let me explain how to proceed. Suppose you have a playlist with many videos, and want to establish an order on which they will be played. First thing you will need is to add a 'position' attribute to your Video model. To do that, we'll generate a migration first:

script/generate migration add_position_to_videos position:integer

Now just run *rake db:migrate*.

View Code

First thing you need to make sure, is that you have the prototype and scriptaculous libraries in your application. Now let's see how your **index.html.erb** file should look like

   
Videos
  
   
  
     <% @videos.each do |video| %>  
       <% content_tag_for :li, video do %>  
         <%= link_to video.name, video_path(video) %>  
       <% end %>  
     <% end %>  
   
  
   <%= link_to "New Video, new_video_path %>  

Now all we have to do to make the list sortable is add the sortable_element helper method to the index view. You need to pass it the id of the element you want to be sortable, and a URL that is called via an AJAX request so that the updated positions can be stored in the database.

   <%= sortable_element('videos', :url => 'sort_videos_path') %>  

The videos in the list can now be dragged and dropped, but the new order isn’t persisted back to the database. So let's code the sort method in the videos_controller.rb

   def sort  
     params[:videos].each_with_index do |id, index|  
       Video.update_all([’position=?’, index+1], [’id=?’, id])  
     end  
     render :nothing => true  
   end  

And that's it. We are now updating the position of the videos. Most probably, we would want now our videos to be shown in the index in the correct order, so we just need to touch the index method on the controller a bit.

   def index  
     @videos = Video.all(:order => ’position’)  
   end  

At this point we are almost set to go...did you guess what's missing? Yes, we need to add the route to the sort method :)

   map.resources :videos, :collection => { :sort => :post}  

The line above adds the new action and makes it a POST request, which is the type that our AJAX call uses when making XMLHTTP requests. And that's pretty much it. Now you have a fully functional sortable list of videos. There are some more tricks we can use to improve this, for example, the **sortable_element** helper receives one option called 'handle'. What's this? The way to specify the draggable area of the element. This I think is the most used one. Let's give it a try: We should first add a span tag on the index view:

 <% content_tag_for :li, video do %>  
   [drag]  
   <%= link_to video.name, video_path(video) %>  
 <% end %> 

Note the span has a 'handle' class, and that's what you are going to set as draggable, using the :handle option:

   <%= sortable_element(’videos’), :url => sort_videos_path, :handle => ’handle’ %>  

You can style this a bit with a CSS, adding a line similar to this one:

 li .handle { color: #777; cursor: move; font-size: 12px; } 

Beautiful....just beautiful... Ok, we have this magical sortable list now, but we added a 'position' field to videos...we can handle this manually when creating or updating the videos, or we can use the **acts_as_list** plugin, which I recommend. Just install it by typing

script/plugin install git://github.com/rails/acts_as_list.git

in your console. All configuration this needs to work is to add **acts_as_list** in our model, that should look like this:

   class Video < ActiveRecord::Base  
     acts_as_list  
   end  

Congrats!!! Enjoy your sortable list !!!

At WyeWorks headquarters, every once in a while, we come across some project that needs a media edition/transcoding solution to build into. This was the case of our latest project in which we built a pretty simple interface with [Brightcove(Brightcove - The Leading Online Video Platform.)](http://www.brightcove.com/), a powerful video platform on which we may write something about it in our forthcoming posts, but it's not the point right now. Turns out to be that Brightcove recommends that files should be encoded using either H.264 or VP6. As usual, we ask ffmpeg for salvation when we need to transcode media files and this was not the exception. But we didn't want to transcode just every file nor make the choice based on the file's extension. We wanted a way to check the current file encoding. Searches made at that time lead us to think that the usual way to get a media file encoding is by running: ffmpeg -i which i must say that it's pretty ugly for me since that command it's supposed to be used for conversion and as far as i know it doesn't offer some flag to get only the file information. In fact, that command returns an error (but still prints the information we need): jose:~$ ffmpeg -i barsandtone.flv FFmpeg version 0.5-svn17737+3:0.svn20090303-1ubuntu6, Copyright (c) 2000-2009 Fabrice Bellard, et al. configuration: --enable-gpl --enable-postproc --enable-swscale --enable-x11grab --extra-version=svn17737+3:0.svn20090303-1ubuntu6 --prefix=/usr --enable-avfilter --enable-avfilter-lavf --enable-libgsm --enable-libschroedinger --enable-libspeex --enable-libtheora --enable-libvorbis --enable-pthreads --disable-stripping --disable-vhook --enable-libdc1394 --disable-armv5te --disable-armv6 --disable-armv6t2 --disable-armvfp --disable-neon --disable-altivec --disable-vis --enable-shared --disable-static libavutil 49.15. 0 / 49.15. 0 libavcodec 52.20. 0 / 52.20. 0 libavformat 52.31. 0 / 52.31. 0 libavdevice 52. 1. 0 / 52. 1. 0 libavfilter 0. 4. 0 / 0. 4. 0 libswscale 0. 7. 1 / 0. 7. 1 libpostproc 51. 2. 0 / 51. 2. 0 built on Apr 10 2009 23:18:41, gcc: 4.3.3 Input #0, flv, from 'barsandtone.flv': Duration: 00:00:06.00, start: 0.000000, bitrate: 505 kb/s Stream #0.0: Video: *vp6f*, yuv420p, 360x288, 409 kb/s, 1k tbr, 1k tbn, 1k tbc Stream #0.1: Audio: mp3, 44100 Hz, stereo, s16, 96 kb/s **Must supply at least one output file** The information we need is the video codec (in this case vp6f) to determine if we need to transcode it. Another thing to mention is that nothing that you see as the output there outputs to the stdout. No rocket science needed but i was kind of lazy to parse this from scratch. Lucky for me, there was this not so new [rvideo(rvideo)](http://code.google.com/p/rvideo/) gem (still unknown for me) that made me save some precious time. [RVideo(rvideo)](http://code.google.com/p/rvideo/) still relies in ffmpeg command and also it's internal work to get the information we need involves that same output parsing, you just don't have to do it yourself. After installation (not covered here, just check rvideo readme file), you can do things as shown below: inspector = RVideo::Inspector.new(:file => file.path) inspector.video_codec => "vp6f" inspector.duration => 6000 inspector.audio_codec => "mp3" We've just made a tiny introduction to inspection. I'm not covering video processing. Check [rvideo(rvideo)](http://code.google.com/p/rvideo/) for more details! Enjoy!

While developing an application with Sebastián that allow users to upload videos with some file name restrictions, meaning that it must contain only A-Z and 0-9 digits, underscores (_) as a valid component as well, and also the name must be preceded by it's own #id, we came up with the need of applying this custom filter to each uploaded video. After doing some research on paperclip source code and internet tutorials, we suggest the following solution:

class Video < ActiveRecord::Base
  has_attached_file :video,
    :path => ":rails_root/public/system/:attachment/:id/:style/:normalized_video_file_name",
    :url => "/system/:attachment/:id/:style/:normalized_video_file_name"

  Paperclip.interpolates :normalized_video_file_name do |attachment, style|
    attachment.instance.normalized_video_file_name
  end

  def normalized_video_file_name
    "#{self.id}-#{self.video_file_name.gsub( /[^a-zA-Z0-9_\.]/, '_')}"
  end
end

What are we doing here? Easy, in **has_attached_file** we edit the way paperclip returns the **path** and **url** by default, the most relevant components when saving and loading the file in order to display it. Paperclip default values are:

path default => ":rails_root/public/system/:attachment/:id/:style/:filename"
url default => "/system/:attachment/:id/:style/:filename"

Values preceded by ':' are the standard interpolations paperclip has. For further information on this visit [http://wiki.github.com/thoughtbot/paperclip/interpolations(Interpolations)](http://wiki.github.com/thoughtbot/paperclip/interpolations.) What we did was change **:filename** with **:normalized_video_file_name** in both path and url, being the second a custom interpolation and then added the 'normalized_video_file_name' method to video.rb. By doing this we not only achieve a way for paperclip to handle the file by this normalized way, but also have a method to access the normalized file name, plus being able to access the original file name through paperclip video_file_name method. So remember on video_file_name you have the uploaded filename and on normalized_video_file_name you have the server filename.

Delegation is a feature Rails introduced in it's 2.2 version, and in my opinion are quite useful and somehow something we don't see too much around. The concept of delegation is to take some methods and send them off to another object to be processed. Let me explain this with a brief example: Suppose you have a User class for anyone registered on your site, and a Customer class for those who have actually placed orders:

class User < ActiveRecord::Base  
   belongs_to :customer  
end  
  
class Customer < ActiveRecord::Base  
   has_one :user  
end

As for now, if you are in a Customer instance, you can get their User information doing *@customer.user.name*, or *@customer.user.email*. Delegation allows you to simplify this:

class User < ActiveRecord::Base  
   belongs_to :customer  
end  
   
class Customer < ActiveRecord::Base  
   has_one :user  
   delegate :name, :name=, :email, :email=, :to => :user  
end

Now you can refer to **@customer.name** and **@customer.email** to retrieve and set values for those attributes directly. Pretty nice, huh? We are now working on some code to make possible to inherit behaviour, along with polymorphic associations, so when you create a Cutomer, the User gets created as well with the data you provided when creating the customer, and so on. So keep posted, for there will be more to come...

Right after starting with [Thinking Sphinx(Thinking Sphinx plugin)](http://ts.freelancing-gods.com/), it was quite hard to find a concise guide on how to enable wildcard search. For those out there who might not know, [Sphinx(Sphinx free open-source SQL full-text search engine)](http://www.sphinxsearch.com/) searches default to matching whole words, not partial ones, so you won’t get any results of you search, for example, for one letter or part of a name. So, how to get around this?? .. well .. [Sphinx(Sphinx free open-source SQL full-text search engine)](http://www.sphinxsearch.com/) provides wildcard search and below is how you can enable this with [Thinking Sphinx(Thinking Sphinx plugin)](http://ts.freelancing-gods.com/) ## How wildcard search works in Sphinx? There are basically three settings that rule the wildcard search world: * enable_star * min_prefix_len * min_infix_len **enabled_star is required plus one of the other two for settings for enabling either prefix or infix search (can't have both, at least on the same index).** ### enable_star This settings enables "star-syntax", or wildcard syntax (means that '*' can be used at the start and/or end of the keyword), when searching through indexes which were created with prefix or infix indexing enabled. The star will match zero or more characters. It only affects searching; so it can be changed without reindexing by simply restarting searchd. For example, assume that the index was built with infixes and that enable_star is 1. Searching should work as follows: 1. "abcdef" query will match only those documents that contain the exact "abcdef" word in them. 1. "abc*" query will match those documents that contain any words starting with "abc" (including the documents which contain the exact "abc" word only); 1. "*cde*" query will match those documents that contain any words which have "cde" characters in any part of the word (including the documents which contain the exact "cde" word only). 1. "*def" query will match those documents that contain any words ending with "def" (including the documents that contain the exact "def" word only). ### min_prefix_len Minimum word prefix length to index. Optional, default is 0 (do not index prefixes). For instance, indexing a keyword "example" with min_prefix_len=3 will result in indexing "exa", "exam", "examp", "exampl" prefixes along with the word itself. Searches against such index for "exam" will match documents that contain "example" word, even if they do not contain "exam" on itself. Too short prefixes (below the minimum allowed length) will not be indexed. ### min_infix_len Infix indexing allows to implement wildcard searching by 'start*', '*end', and '*middle*' wildcards. When mininum infix length is set to a positive number, indexer will index all the possible keyword infixes (ie. substrings) in addition to the keywords themselves. Too short infixes (below the minimum allowed length) will not be indexed. For instance, indexing a keyword "test" with min_infix_len=2 will result in indexing: * "te" * "es" * "st" * "tes" * "est" infixes along with the word itself. Searches against such index for "es" will match documents that contain "test" word, even if they do not contain "es" on itself. ## Drawbacks :( Indexing prefixes will make the index grow significantly (because of many more indexed keywords), and will degrade both indexing and searching times. Also, there's no automatic way to rank perfect word matches higher in a prefix index, but there's a number of tricks to achieve that (setup to indexes or extended-mode queries. Read more [here](http://www.sphinxsearch.com/docs/current.html#searching).) ## Show me some code! So, here it's how you can set a wildcard search on a particular index for any of your models. In this case i'm setting an infix search.

class Article < ActiveRecord::Base
  ....
  ....

  define_index do
    indexes title, body, author
    set_property :enable_star => 1
    set_property :min_infix_len => 3
  end

  ....
  ....
end

You can also set these properties in your sphinx.yml settings file under config/ folder for any environment you want. It might look like this:

production:
  enable_star: 1
  min_infix_len: 3

and it will apply to all of your indexes. Re-index your data and restart the sphinx deamon (remember i'm using Thinking Sphinx, so i have a set of nice and short rake tasks to achieve this).

rake ts:stop
rake ts:in
rake ts:start

Now you should be able to fire searches like this:

Article.search "Sphinx"
Article.search "Think*"
Article.search "*inx*"

And many more cool stuff that's beyond the scope of this post :) Enjoy!

And Ruby just doesn't stop surprising us!! In the past we have to deal with XML files and parse them, incredibly easy task using Hpricot library. Now the turn was for [OPML(OPML)](http://en.wikipedia.org/wiki/OPML) (Outline Processor Markup Language) files. In case you are not familiar with this type of files, its most common use is to exchange lists of web feeds between web feed aggregators. We found this function to parse the OPML document recursively preserving its structure in the [desktop weblog(desktop weblog)](http://dekstop.de/weblog/), that does the job of extracting the feeds, and modified it a bit. Now it returns a hash containing the title of the articles as keys, and its links as values. Here's the function:

def self.parse_opml(opml_node, parent_names=[])
    feeds = {}
    opml_node.elements.each('outline') do |el|
      if (el.elements.size != 0)
        feeds.merge!(parse_opml(el, parent_names + [el.attributes['text']]))
      end
      if (el.attributes['xmlUrl'])
        feeds[el.attributes['title']] = el.attributes['xmlUrl']
      end
    end
    return feeds
  end

All you have to do is call it this way:

require 'rexml/Document'

opml = REXML::Document.new(File.read('my_feeds.opml'))
feeds = parse_opml(opml.elements['opml/body'])

Pretty easy, huh? Try it out and leave your comments...

Inspired by Hal Fulton's article [Thirty-seven Reasons I Love Ruby(Thirty-seven Reasons I Love Ruby)](http://rubyhacker.com/ruby37.html), i'd like to share my top twenty reasons I love Ruby. 1. **{color:#993300}It's object-oriented.** What does that mean? Well, for every ten programmers, there are twelve opinions as to what OOP is. I will leave it your judgment. But for the record, Ruby does offer encapsulation of data and methods within objects and allows inheritance from one class to another; and it allows polymorphism of objects. Unlike some languages (like C++ for instance) Ruby was designed from the beginning to be object-oriented. 1. **{color:#993300}It's a pure OOP language.** Am I being redundant? I don't think so. By this I mean that everything, including primitive data types such as strings and integers, is represented as an object. There is no need for wrapper classes such as Java has. And in addition, even constants are treated as objects, so that a method may be invoked with, for example, a numeric constant as a receiver. 1. **{color:#993300}It's a dynamic language.** For people only familiar with more static languages such as C++ and Java, this is a significant conceptual leap. It means that methods and variables may be added and redefined at runtime. It obviates the need for such features as C's conditional compilation (*#ifdef*), and makes possible a sophisticated reflection API. This in turn allows programs to become more "self-aware" -- enabling runtime type information, detection of missing methods, hooks for detecting added methods, and so on. 1. **{color:#993300}It's an interpreted language.** This is a complex issue, and deserves several comments. It can be argued that performance issues make this a negative rather than a positive. To this concern, I reply saying that a rapid development cycle is a great benefit, and it is encouraged by the interpreted nature of Ruby. 1. **{color:#993300}It understands regular expressions.** For years, this was considered the domain of UNIX weenies wielding clumsy tools such as **grep** and *sed*, or doing fancy search-and-replace operations in *vi*. Perl helped change that, and now Ruby is helping, too. More people than ever recognize the incredible power in the super-advanced string and text manipulation techniques. 1. **{color:#993300}It's multi-platform.** It runs on Linux and other UNIX variants, the various Windows platforms, BeOS, and even MS-DOS. 1. **{color:#993300}It's derivative.** Is this a good thing? Outside of the literary world, yes, it is. Isaac Newton said, "If I have seen farther than others, it is because I stood on the shoulders of giants." Ruby certainly has stood on the shoulders of giants. It borrows features from Smalltalk, CLU, Lisp, C, C++, Perl, Kornshell, and others. The principles I see at work are: 1. Don't reinvent the wheel. 2. Don't fix what isn't broken. 3. Finally, and especially: Leverage people's existing knowledge. You understand files and pipes in UNIX? Fine, you can use that knowledge. You spent two years learning all the **printf** specifiers? Don't worry, you can still use *printf*. You know Perl's regex handling? Good, then you've walked a way in Ruby path too. 1. **{color:#993300}It has a smart garbage collector.** Routines like **malloc** and **free** are only last night's bad dream. You don't even have to call destructors. Enough said. 1. **{color:#993300}It's a scripting language.** Don't make the mistake of thinking it isn't powerful because of this. It's not a toy. It's a full-fledged language that happens to make it easy to do traditional scripting operations like running external programs, examining system resources, using pipes, capturing output, and so on. 1. **{color:#993300}It's open-source.** You want to look at the source code? Go ahead. Want to suggest a patch? Go ahead. You want to connect with a knowledgeable and helpful user community, including the language creator himself? You can. Welcome on board. 1. **{color:#993300}It has an advanced Array class.** Arrays are dynamic; you don't have to declare their size at compile-time as in, say, Pascal. You don't have to allocate memory for them as in C, C++, or Java. They're objects, so you don't have to keep up with their length; it's virtually impossible to "walk off the end" of an array as you might in C. Want to process them by index? By element? Process them backwards? Print them? There are methods for all these. Want to use an array as a set, a stack, or a queue? There are methods for these operations, too. Want to use an array as a lookup table? That's a trick question; you don't have to, since we have hashes for that. 1. **{color:#993300}It's extensible.** You can write external libraries in Ruby or in C. In addition, you can modify the existing classes and objects at will, on the fly. 1. **{color:#993300}It uses punctuation and capitalization creatively.** A method returning a Boolean result (though Ruby doesn't call it that) is typically ended with a question mark, and the more destructive, data-modifying methods are named with an exclamation point. Simple, informative, and intuitive. All constants, including class names, start with capital letters. All object attributes start with an @ sign. Again, simple. 1. **{color:#993300}It pays attention to detail.** Synonyms and aliases abound. You can't remember whether to say **size** or **length** for a string or an array? Either one works. For ranges, is it **begin** and **end*, or *first** and *last*? Take your pick. You spell it *indices*, and your evil twin spells it *indexes*? They both work. 1. **{color:#993300}It has a debugger.** In a perfect world, we wouldn't need debuggers. This is not a perfect world. 1. **{color:#993300}It is concise.** There are no superfluous keywords such as Pascal's **begin*, *then** after **if*, *do** after *while*. Variables need not be declared, as they do not have types. Return types need not be specified for methods. The return keyword is not needed; a method will return the last evaluated expression. On the other hand... it is not so cryptic as C. 1. **{color:#993300}It is expression-oriented.** You can easily say things like *x = if a < 0*. 1. **{color:#993300}It has powerful string handling.** If you want to search, substitute, justify, format, trim, delimit, interpose, or tokenize, you can probably use one of the built-in methods. If not, you can build on them to produce what you need. 1. **{color:#993300}It has few exceptions to its rules.** The syntax and semantics of Ruby are more self-consistent than most languages. Every language has oddities, and every rule has exceptions; but Ruby has fewer than you might expect. 1. **{color:#993300}It is laced with syntax sugar.** (To paraphrase Mary Poppins: A spoonful of syntax sugar helps the semantic medicine go down.) If you want to iterate over an array x by saying *for a in x*, for example, you can.