La gente está como loca añadiendo FacebookConnect a sus aplicaciones gracias a herramientas como Facebooker. Pero FacebookConnect no sólo sirve para que los usuarios se registren de forma instantánea. Como Pierre Oliver nos enseña en su blog son varias las herramientas que nos proporciona Facebook para promocionar nuestro sitio. Tales como:

• Postear al muro de los usuarios
• Añadir el widget de invita a tu amigos
• El widget de Hazte fan
• Hacer uso del sistema de comentarios de Facebook
• Y optimizar los enlaces de FB a tu sitio

Lo mejor es que estas soluciones parecen sencillas de aplicar y Pierre Oliver ya se ha preocupado de buscar los tutoriales por nosotros. No se puede pedir más.

Como ya os mencioné en un post anterior, Rails 2.3.4 incluye de serie soporte para poblar/popular/llenar (como queráis llamarlo) la base de datos.

Para aquellos que quieran aprender a usar esta nueva feature nada mejor que uno de los screencast de Ryan Bates. Se acabó cargar datos en las migraciones!

Los propios 37signals han publicado en su blog Signal vs Noise un mapa de Google maps en el que puede verse dónde están cada uno de sus empleados.

No sólo cabe destacar que trabajan totalmente desperdigados sino que no todos están en USA. Hay uno en Granada: Joshua Sierles.

No me extraña que sean buenos haciendo herramientas de colaboración : ).

Ya está disponible Rails 2.3.4 y se recomienda encarecidamente a todos los usuarios de Rails 2.3 que actualicen por los bugs de seguridad que soluciona. En especial:

• Vulnerabilidad de temporización con Cookie Store
• Vulnerabilidad Cross Site Scripting (XSS) al escapar código en los formularios

Tanto uno como otro son díficiles de explotar por razones diferentes.

Además, la nueva versión incluye cerca de 100 bugs resueltos y un par de características nuevas: I18n para plugins y el fichero db/seeds.rb para cargar fácilmente información en la base de datos.

A actualizar se ha dicho!

Ya se conocen los ganadores del Rails Rumble 2009. Para aquellos que no lo sepan, se trata de un concurso en el que ninjas de Ruby on Rails compiten para ver quiénes pueden hacer la mejor aplicación web en tan sólo 48 horas.

Los grupos son de hasta 4 personas como mucho. Y se les permite preparar de cara al concurso cualquier información no digital. Bocetos, dibujos, esquemas, pero nada de Photoshop ni mucho menos código.

Los ganadores generales de este año son los siguientes:

• hi.im: En el que podemos crear un perfil y crear una tarjeta de presentación virtual con enlaces a todas nuestras redes sociales.
• How’s My Code?: Con el que podemos revisar código de forma sencilla y que además está integrado con GitHub.
• Tablesurfing: Con que podemos contactar con gente para irnos de bares o restaurantes : ).

Además hay menciones especiales a los mejores en cada categoría:

• Premio al mejor aspecto visual: Lowdown, con el que podemos escribir features de Cucumber de forma colaborativa.
• Premio al más útil: ZenVDN, con el que podemos subir y publicar videos en alta resolucion. Dispositivos móviles incluidos.
• Premio al más completo: hurl, que al igual que con curl el que podemos hacer peticiones HTTP. Perfecto para probar APIs.
• Al mejor hecho por una sola persona: AlertMe.tv, que te avisa cuando hay nuevos episodios disponibles.
• Y al más innovador: LAZEROIDS! para recordar los viejos tiempos : ).

Impresiona ver lo el aspecto y el buen funcionamiento de algunas de las aplicaciones. Parece que Rails Rumble cumple muy bien con el objetivo de demostrar como Rails acelera el desarrollo web.

Dicen por ahí que uno no aprovecha RSpec al 100% hasta que no escribe sus propios matchers. Y la verdad, ahorran tiempo y hacen que nuestros tests sean mucho más legibles. No debemos olvidar que los tests son documentación. Lo mejor de todo es lo sencillos que son de crear.

Supongamos que a menudo comprobamos si un número es múltiplo de otro:

describe 9 do  it "should be a multiple of 3" do    (9 % 3).should == 0  endend

Feo, verdad? No es fácil interpretar a simple vista lo que queremos testear. Lo ideal sería poderlo expresar de la siguiente manera:

describe 9 do  it "should be a multiple of 3" do    9.should be_a_multiple_of(3)  endend

Manos a la obra. Creamos el fichero spec/support/matchers/be_a_multiple_of_matcher.rb  con el siguiente contenido.

# spec/support/matchers/be_a_multiple_of_matcher.rb

Spec::Matchers.define :be_a_multiple_of do |expected|  match do |actual|    actual % expected == 0  endend

Debemos asegurarnos de que el fichero es incluido en nuestros tests. Editamos spec/spec_helper.rb:

# spec/spec_helper.rb

Dir[File.dirname(__FILE__) + "/support/**/*.rb"].each {|f| require f}...

Y con eso ya podemos usar el matcher be_a_multiple_of cuando queramos. Pero aún podemos hacerlo mejor. Si el test falla, el mensaje que veremos no hablará de múltiplos sino que simplemente dirá que esperábamos 0 y obtuvimos otra cosa.

Podemos hacer que los mensajes sean más descriptivos con lo siguiente:

# spec/support/matchers/be_a_multiple_of_matcher.rb

Spec::Matchers.define :be_a_multiple_of do |expected|  match do |actual|    actual % expected == 0  end

  failure_message_for_should do |actual|    "expected that #{actual} would be a precise multiple of #{expected}"  end

  failure_message_for_should_not do |actual|    "expected that #{actual} would not be a precise multiple of #{expected}"  end

  description do    "be a precise multiple of #{expected}"  endend

Y con eso tenemos una herramienta más en nuestro repertorio para hacer las cosas más rápido y mejor. Para los interesados, el ejemplo original ha sido extraido de la Wiki de RSpec en GitHub.

Este es el vídeo de Javier Ramírez presentando JRuby a una audiencia de desarrolladores Java en el Sun Open Communities Forum.

La exposición es amena y muy convincente. Javier hace un buen trabajo presentando Ruby on Rails a una audiencia que aún no está decidida.

Aquí podéis ver la presentación (en Español) a la vez que las transparencias.

Si alguna vez os habéis planteado usar Basecamp no dejéis de echarle un vistazo a Teambox.

Teambox proporciona las herramientas básicas de colaboración que podemos necesitar trabajando en equipo. Como son: Listas de tareas, una wiki, mensajes privados (con soporte de SMS) entre los miembros del equipo e incluso una sala de chat.

La interfaz de Teambox tiene un aspecto impecable y hace uso de AJAX. La interfaz es en general bastante agradable y fácil de usar.

Teambox es un producto español, aunque está en Inglés porque tiene objetivos internacionales. Lo mejor es que no sólo es Open Source (podéis descargar el código fuente en su repositorio de Github) sino que podéis crearos una cuenta de forma totalmente gratuita.

Ahora están trabajando duramente para lanzar la versión 2.0  que además de un fuerte rediseño va incluir mejora tan interesantes como soporte para iPhone y Android e integración con Twitter. ¿Se puede pedir más? : )

Siguiendo la tónica del anterior artículo ¿Cómo aprendieron Ruby on Rails? aquí va mi particular Como aprendí Ruby on Rails.

Desde mi punto de vista. La mejor forma de aprender algo es leyendo un buen libro sobre el tema. Sin despreciar las magníficas fuentes de consulta que ofrece Internet. Estas son las mías:

Aprendiendo Ruby

No se puede programar con Ruby on Rails sin conocimientos básicos de Ruby. Programming Ruby, también conocido como The Pickaxe Book por suportada, ha sido desde hace mucho el libro de referencia. No me decepcionó.

Programming Ruby: The Pragmatic Programmers’ Guide por Dave Thomas, con Chad Fowler y Andy Hunt. Editorial Pragmatic Programmers.

Aprendiendo Rails

Agile Web Development with Rails es, en mi opinión, el libro ideal para iniciarse en Rails. En especial por la forma en la que explica cual es el proceso habitual del desarrollo de una aplicación web con Ruby on Rails.

Cuenta con el propio David Heinemeier Hansson como coautor.

Agile Web Development with Rails. Por Sam Ruby, Dave Thomas y David Heinemeier Hansson. Editorial Pragmatic Programmers.

Fuentes para tener siempre a mano

Conforme aprendemos, incluso cuando ya tienes experiencia, hay sitios web de consulta que son de una ayuda inestimable.

http://guides.rubyonrails.org explica de forma directa y sencilla las herramientas más habituales de Rails. 

http://www.gotapi.com/rubyrails proporciona una agradable y usable interfaz para consultar cualquier la API de Ruby on Rails. Ideal para cualquier método que se nos olvide.

http://railscasts.com tiene una enorme variedad de screencasts. Grabados por Ryan Bates. Cada uno con una solución práctica a decenas de problemas o dudas que puedan surgir. Recomiendo a todo el mundo suscribirse a su RSS.

Perfeccionando Rails

Este libro es una biblia. Es el libro con el que realmente aprendí a usar la variedad de herramientas que Ruby on Rails proporciona. Que juntas unas con otras hacen que crear sitios web con Rails sea bonito y agradable. No es un libro sencillo, pues a veces toca temas complejos. Pero no cabe duda de que el autor (Obie Fernandez) ha hecho un trabajo excelente.

The Rails Way por Obie Fernandez. Editorial Addison Wesley.

Estos han sido mis principales compañeros de viaje durante el año y medio que llevo aprendiendo Ruby on Rails. Y aun sigo haciéndolo. Espero que sirvan a muchos más a darse cuenta de lo creativo que puede llegar a ser crear aplicaciones web con las herramientas adecuadas.

37 Signals acaba de hacer pública la portada de su próximo libro: Rework.

Dicho por Jason Fried (fundador de 37 Signals). “Getting Real trataba de software. Rework trata de negocios“. El libro puede ser reservado ya en Amazon y ha recibido esta crítica del gurú del marketing Seth Godin: “Ignora este libro bajo tu propia responsabilidad”.

Personalmente me encantó Getting Real y estoy deseando echarle la zarpa a este.