Durante el pasado de mes de Julio, tuve la gran oportunidad de pasar una semana trabajando con los increíbles chicos de BeBanjo. En cuanto me enteré de que están buscando gente para ampliar su equipo, decidí escribir a Luismi Cavallé para obtener más información al respecto. Y cual fue mi sorpresa cuando me propusieron trabajar una semana con ellos. Claro: ¿qué mejor forma de conocer a tus candidatos que trabajar una semana con ellos?. Mucha gente no entendía que fuese a una empresa a trabajar sin cobrar un duro, pero ¡yo no lo dudé ni un minuto!

La experiencia fue genial para mí. Fueron sólo 5 días pero personalmente me aportó mucho. Por eso, y en primer lugar, quiero dar las gracias a Jorge Gomez Sancha y Bastian Manintveld por la invitación. Thanks!.

Paso a resumir algunas de las buenas prácticas y aspectos que más me llamaron la atención y por las que opino que realmente merece mucho la pena trabajar en BeBanjo:

A nivel técnico

Llevaba mucho tiempo deseando trabajar en algún proyecto Rails “de la vida real” y con un equipo maduro que realmente llevara mucho tiempo trabajando con el framework. Ya había asistido a una sesión sobre Testing de aceptación en Ruby impartida por Luismi y Sergio Gil y eso me motivó mucho a escribirles. A nivel técnico, me llamó la atención:

La programación por parejas: un ordenador, dos pantallas, dos teclados, y dos ratones

Reconozco que nunca había programado en pareja de una forma tan intensiva. Sí lo había hecho para resolver algún problema complejo concreto, pero no durante jornadas completas. La experiencia fue muy positiva. En BeBanjo tuve la oportunidad de comprobar la productividad y calidad que se consigue cuando dos cabezas están resolviendo un mismo problema.

El hecho de tener una persona al lado, con quien poder discutir una determinada solución, no sólo ayuda a obtener un mejor código, sino que también consigue que ambas partes estén completamente concentradas en su trabajo. Trabajando con Luismi comprendí que el hecho de exponer el problema a otra persona de una forma oral, ayuda a darse cuenta de muchas cosas que de forma introspectiva sería difícil descubrir.

Y si a eso le sumas la técnica del Pomodoro sincronizada entre todos los miembros del equipo con tomatoi.st, un sencillo tablero kanban y una planificación al comienzo de cada día: ¡la productivad es brutal!

El ciclo BDD/TDD: ¡las pruebas primero!

¡En BeBanjo siempre escriben los tests primero!. Y gracias a esta experiencia puede ver a un equipo real con su propia forma de hacer BDD/TDD, es decir, programando primero cuál es el comportamiento esperado desde el punto de vista del usuario en forma de test para después codificar una solución lo más elegante posible. Esto hace posible desarrollar nuevas funcionalidades sin apenas abrir el navegador.

En el caso de Ruby On Rails, tuve la oportunidad de trabajar con el famoso Steak, y también pude ver a Jasmine en acción

Lo mejor que he aprendido referente a este tema es, a parte del enfoque BDD, que no existe una forma definitiva de probar tu código sino que cada equipo/persona debe elegir qué aproach le aporta más valor y seguridad… Por otro lado, he aprendido que hay cosas bastante triviales que no merece la pena probar.

El workflow con git: varias ramas y un buen entorno

He de reconocer que a nivel profesional sólo he trabajado con Subversion. Conozco GIT gracias a GitHub y algún proyecto que he desplegado en Heroku.

En BeBanjo tienen muy bien planteando su flujo de trabajo con git. Descubrí bastante comandos de git y los problemas que puede ocasionar el trabajar con una única rama master.

Ni que decir tiene, que los despliegues en producción son bastante frecuentes y que cualquier miembro del equipo puede desplegar nuevas funcionalidades sin miedo a romper algún código anterior.

Excelencia técnica y happy programmers

Poco puedo contar de Luismi, Sergio Gil (Porras) y Christos Zisopoulos que no se sepa ya. A nivel técnico cuentan con una gran experiencia y son desarrolladores muy “visibles” y activos en el panorama Ruby nacional e internacional, lo cual dice mucho sobre sus perfiles y los convierte en grandes compañeros de trabajo. Pero lo más importante de todo es que disfrutan con su trabajo.

En este punto he de agradecerles a los tres su gran paciencia a la hora de responder mis infinitas preguntas, y en especial a Luismi que fue con quién más trabajé y de quién más pude aprender . Thanks!

A nivel de empresa

Al mismo tiempo, tenía muchas ganas de vivir el ambiente de una empresa de producto tipo startup. El hecho de que mi estancia coincidiera con un cambio de oficina me hizo estar implicado en situaciones bastante divertidas y a su vez curiosas por las que supongo toda startup debe pasar algún día. BeBanjo me parece una buena empresa por los siguientes aspectos:

El buen ambiente de trabajo: felt like home!

Los miembros de BeBanjo me hicieron sentir como en casa desde el minuto nº1. Pocas veces me he sentido tan cómodo en un ambiente de trabajo en tan sólo una semana. He de reconocer que durante esa semana no tuve la sensación de ir a “trabajar”. Horarios flexibles, mucha comunicación entre el equipo, reuniones informales, comidas muy distendidas, y mi gran inquietud por aprender con ellos lograron que el día a día fuese super ameno.

Productos nicho que resuelven necesidades reales

El éxito de BeBanjo radica en que sus productos están enfocados a un nicho de mercado muy específico. Los fundadores detectaron que las empresas que ofrecen contenidos de video bajo demanda tienen determinados problemas a la hora de gestionar la información sobre sus referencias (series, películas, etc) y la publicación en diversas plataforma. Entonces diseñaron y desarrollaron varias aplicaciones (Sequence, Movida y Metadata) enfocadas a ayudar a estas empresas. Un punto clave en este aspecto es la gran colaboración de los clientes en todo este proceso.

Concienciación de la importancia del diseño

Sin duda, en BeBanjo saben lo importante que es el buen diseño de producto y por eso trabajan con los mejores. No pude conocer personalmente a Ale Muñoz pero sin duda ha hecho un gran trabajo en el diseño de los actuales productos de BeBanjo. Actualmente están buscando diseñadores todo-terreno y estoy convencido que no tardarán en encontrar a algún crack en este campo.

La importancia de un buen equipo comercial y una clara orientación a cliente

Hace tiempo que soy consciente de la importancia de un buen equipo comercial a la hora de desarrollar productos tecnológicos de éxito. De poco o nada sirve tener un producto excelente a nivel técnico si los posibles compradores no conocen acerca de su existencia… En este sentido creo que ambos socios realizan una gran labor a la hora de establecer nuevos contactos comerciales y en el trato diario con el cliente.

Su enfoque internacional: pensando en grande

Me llamó mucho la atención el enfoque claramente internacional de esta pequeña gran empresa… No era raro escuchar a lo largo del día muchas conversaciones de fondo en inglés o francés. Parece de perogrullo pero… ¿por qué limitarse al mercado nacional? Y este enfoque no se limita a la parte de captar clientes, sino también a la hora de contratar nuevos empleados… ¿por qué no contratar a gente con talento de otros países?.

Podría seguir escribiendo… pero no me quiero extender mucho más. Aprovecho para agradecer de nuevo a todos los miembros de BeBanjo y me despido recomendado a todo el mundo vivir una experiencia de este tipo. Merece la pena.

¡Gracias BeBanjo!

Con este post pretendo ayudarte a entender bien los módulos de ruby para, por ejemplo, aprender cómo dividir bien el código en módulos, entender el código de las gemas, extender el comportamiento de Rails, etc…

¿Qué es un módulo?

Un módulo es una agrupación de métodos, clases y constantes. Mediante el uso de módulos, podemos dividir un programa o sistema en varias partes independientes y reutilizables que interactúen entre sí. Si estás familiarizado con Java, el concepto de módulo podría asimilarse al concepto de paquetes.

Uno podría pensar que esta definición es similar a la de una Clase, que también tiene métodos, clases y constantes… Sin embargo, la diferencia fundamental respecto a las clases, es que no se pueden crear instancias de un módulos.

Como ejemplo de módulo tenemos el módulo Math, que recopila mayormente funciones para operaciones trigonométricas. Y que

¿Cómo se define un módulo?

module MyModule
 
  MY_CONSTANT = '...'
 
  def MyModule.my_method_1
    ...
  end
 
  def my_method_2
     ...
  end
 
  ...
 
end
 
puts MyModule::MY_CONSTANT
...
MyModule.my_method_1

El ejemplo define un módulo de nombre ‘MyModule’ con una constante MY_CONSTANT. Vemos que el módulo tienes 2 métodos: un primer método de módulo, llamado “my_method_1″, que sería equivalente a un método estático de una clase; y un segundo método, “my_method_2″, que sería un método de instancia. ¿Método de instancia? ¿No me acabas de decir que los módulos no tienen instancias? Lo veremos un poco más abajo

Como hemos visto, podemos acceder al valor de una constante a través de “::” y el nombre de la constante. La invocación de los métodos de módulo sería similar a la invocación de un método estático.

Principales usos de los módulos

Definición de espacios de nombres

Cuando los programas crecen, surge la necesidad de organizar de alguna forma todas las partes de la aplicación que están de alguna forma relacionadas entre sí. En el caso del módulo Math, queda claro que todas esas funciones están tan relacionadas que deben habitar en un mismo espacio de nombres. Los espacios de nombres también evitan el problema de que surja una ambiegüedad en el caso de que haya dos componentes con un mismo nombre. Por ejemplo, podemos tener dentro de un programa varias clases con el nombre “Settings”, pero cada una estará referida a algo concreto. Incluyendo esas clases en distintos módulos, conseguimos que puedan ser identificadas de forma unívoca.

Para cargar y utilizar un módulo desde otras partes de la aplicación, podemos usar principalmente 3 métodos:

• require, que carga un fichero de código sólo una vez. En este caso el método recibe una cadena con el nombre del fichero.
• load, que carga un fichero de código aunque ya ha sido ejecutado previamente.
• autoload, que recibe el nombre de un fichero y de un módulo, y carga el fichero la primera vez que se accede al módulo indicado.

Todos estos métodos aceptan rutas absolutas y relativas.

Mixins

Los mixins permiten añadir funcionalidad a una clase mediante el comando include.

Vamos a ver un ejemplo en el que añadimos un método de instancia a la clase String que elimina los espacios en blanco de principio y fin de una cadena y los sustituye por guiones.

module StringUtils
  def hyphenize
    self.to_s.strip.gsub(' ', '-')
  end
end
 
class String
  include StringUtils
end
 
puts " en un lugar de la mancha... ".hyphenize

Con este mecanismo, podemos reutilizar el módulo en varias clases. Es posible incluir varios módulos en una misma clase o módulo, con lo que conseguiríamos un efecto similar al de la herencia múltiple disponible en otros lenguajes como C++.

Además de añadir métodos de instancia, es posible extender una clase con métodos de clase, haciendo uso de extend. Lo vamos a ver con un último ejemplo, que extiende una clase con métodos de instancia y de clase.

module MiModulo
 
  def self.included(base)
    base.send :include, InstanceMethods
    base.send :extend, ClassMethods
  end
 
  module InstanceMethods
    def mi_metodo_de_instancia
      "mi método de instancia"
    end
  end
 
  module ClassMethods</p>
    def mi_metodo_de_clase
      "mi método de clase"
    end
  end
end
 
class MiClase
  include MiModulo
end
 
puts MiClase.mi_metodo_de_clase
puts MiClase.new.mi_metodo_de_instancia

Como vemos, definiendo el método included dentro de un módulo, podemos especificar un comportamiento que se ejecutará cuando ese módulo sea incluido en otro módulo o clase. En este caso, cuando se incluye el módulo en tiempo de ejecución, en envían dos mensaje con send a MiClase para añadir los métodos de instancia(include) y de clase(extend).

Y con esta introducción y los ejemplillos, espero que entiendas un poco mejor cómo funcionan los módulos en Ruby .

Referencias

Lógicamente, esto no lo he inventado yo, sino que he consultado estos enlaces:

• Documentación de la clase Module de Ruby.
• Capítulo sobre módulos en Programming Ruby, The Pragmatic Programmer’s Guide.
• Sección sobre módulos, Ruby User’s Guide.
• Definición de programación modular, Wikipedia.

En esta entrada explico mis primeros pasos con Ruby Version Manager (RVM), una aplicación que nos permite gestionar fácilmente varias versiones de Ruby y agrupaciones de gemas. Mi intención es ir “migrando” poco a poco a la versión 1.9.2 de Ruby y a la versión 3 de Ruby On Rails y durante un tiempo voy a tener que convivir con ambos entornos… De momento todo esto me ha funcionado bajo Mac OS X.

Instalación

Ejecutamos el siguiente comando:

bash < <(curl -s https://rvm.beginrescueend.com/install/rvm)

Añadimos la siguiente línea al fichero de configuración ~/.bashrc, teniendo en cuenta que no haya ningún “return” antes:

[[ -s "$HOME/.rvm/scripts/rvm" ]] && source "$HOME/.rvm/scripts/rvm"  # This loads RVM into a shell session.

Si abrimos un nuevo shell y ejecutamos el comando rvm, deberíamos ver la descripción del comando y modo de uso. Ahora deberíamos instalar una versión de Ruby, por ejemplo la versión 1.9.2:

Instalación de Ruby

rvm install 1.9.2

Ahora ya podemos indicarle al sistema que use la versión de ruby de RVM:

rvm use 1.9.2

Si ejecutamos la orden:

which ruby

Veremos que ya no apunta a /usr/bin/ruby, y si listamos las gemas instaladas veremos que ¡no hay ninguna!. Podríamos volver a la versión del sistema fácilmente, con:

rvm system

Si queremos seleccionar una versión por defecto para nuestro shell, podemos hacerlo con el flag –default:

rvm --default use 1.9.2

Gemsets

Ahora llega la parte interesante, la opción de crear gemsets, que son agrupaciones de gemas. Por ejemplo, podríamos tener en un mismo sistema 2 gemsets, uno con las gemas de rails 2.3.8, y otro con las gemas que tienen que ver con la versión 3 de Rails. Al instalar una versión de Ruby, RVM crea por defecto el gemset de nombre ‘Global’ y es el que se usa por defecto si no se lo indicamos explícitamente otro (como en el siguiente ejemplo). Para crear un gemset y empezar a usarlo:

rvm gemset create rails3
rvm use 1.9.2@rails3

Podemos ver los gemsets que hemos creados con:

rvm gemset list

Ahora ya podemos instalar la gema de Rails3 y todas las gemas que nos hagan falta. ¡Anímate a probarlo! Es my sencillito. Y ahora… ¡a enredar un poco con Rails 3!

El propósito de este post es ayudarte a configurar una aplicación Ruby On Rails muy sencilla, con soporte para la definición de tests de aceptación de usuario con Cucumber. Son los pasos que yo he seguido para iniciarme en el mundo del BDD (desarrollo dirigido por comportamientos). El ejemplo consiste en la clásica aplicación Rails (versión 2.3.5) de gestión de Posts, generada usando Scaffolding.

He colgado la aplicación resultante en mi cuenta de GitHub: https://github.com/alonsogarciapablo/cucumber_rails_test.

Configuración previa

Antes de empezar, es necesario instalar las siguientes gemas:

Gherkin

Gherkin son dos cosas:

• El lenguaje que ha surgido a partir de Cucumber. Más concretamente es un DSL (lenguaje específico de dominio) que permite hacer BDD (desarrollo dirigido por comportamiento).
• La librería para parsear dicho lenguaje.

$ gem install gherkin

Cucumber y Cucumber para Rails

Como introducción a Cucumber, te recomiendo leer Cucumber Backgrounder, donde Aslak Hellesøy explica cómo se puede integrar Cucumber en una aplicación Rails, y la sintaxis para definir Features, Scenarios y Steps.

$ gem install cucumber-rails

Webrat

Webrat permite escribir tests de aceptación que simulan el comportamiento de un navegador web y de los usuarios en definitiva. Permite simular cosas como: ve a la página principal, rellena el campo nombre de usuario con “Pablo”, rellena el campo contraseña con “Alonso”, pincha en el botón “Login”.

$ gem install webrat

Database Cleaner

Database Cleaner define una serie de estrategias para limpiar una base de datos. Originalmente se pensó para garantizar un estado “limpio” entre la ejecución de los tests automáticos.

$ gem install database_cleaner

Aplicación de prueba

Creamos una aplicación Rails y la configuramos para que funcione con Cucumber

Creamos la aplicación Rails:

$ rails cucumber_rails_test
$ cd cucumber_rails_test

Generamos los ficheros necesarios para usar Cucumber con Webrat:

$ script/generate cucumber --webrat
      create  config/cucumber.yml
      create  config/environments/cucumber.rb
      create  script/cucumber
      exists  features/step_definitions
      create  features/step_definitions/web_steps.rb
      create  features/support
      create  features/support/paths.rb
      create  features/support/env.rb
      create  lib/tasks
      create  lib/tasks/cucumber.rake

Generamos una Feature

Generamos una feature con dos escenarios, uno para la creación y otro para el borrado de Posts:

$ script/generate feature post title:string body:text published:boolean
      exists  features/step_definitions
      create  features/manage_posts.feature
      create  features/step_definitions/post_steps.rb

Se deben haber creado automáticamente dos nuevos ficheros, un fichero con la definición de la funcionalidad de Gestión de posts (features/manage_posts.feature):

Feature: Manage posts
  In order to [goal]
  [stakeholder]
  wants [behaviour]
 
  Scenario: Register new post
    Given I am on the new post page
    When I fill in "Title" with "title 1"
    And I fill in "Body" with "body 1"
    And I uncheck "Published"
    And I press "Create"
    Then I should see "title 1"
    And I should see "body 1"
    And I should see "false"
 
  Scenario: Delete post
    Given the following posts:
      |title|body|published|
      |title 1|body 1|false|
      |title 2|body 2|true|
      |title 3|body 3|false|
      |title 4|body 4|true|
    When I delete the 3rd post
    Then I should see the following posts:
      |Title|Body|Published|
      |title 1|body 1|false|
      |title 2|body 2|true|
      |title 4|body 4|true|

, y otro fichero con la definición de los pasos (features/step_definitions/post_steps.rb):

Given /^the following posts:$/ do |posts|
  Post.create!(posts.hashes)
end
 
When /^I delete the (\d+)(?:st|nd|rd|th) post$/ do |pos|
  visit posts_path
  within("table tr:nth-child(#{pos.to_i+1})") do
    click_link "Destroy"
  end
end
 
Then /^I should see the following posts:$/ do |expected_posts_table|
  expected_posts_table.diff!(tableish('table tr', 'td,th'))
end

Ejecutamos los tests de aceptación

Como todavía no está implementada la funcionalidad, la ejecución de los dos escenarios falla. No existe todavía el modelo Post, ni la ruta asociada a la creación de un nuevo Post:

$ rake cucumber
(in /Users/paul/Proyectos/cucumber_rails_test)
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -I "/Users/paul/.gem/ruby/1.8/gems/cucumber-0.10.0/lib:lib" "/Users/paul/.gem/ruby/1.8/gems/cucumber-0.10.0/bin/cucumber"  --profile default
Using the default profile...
F-------F--
 
(::) failed steps (::)
 
undefined local variable or method `new_post_path' for #<Cucumber::Rails::World:0x8194fd00> (NameError)
./features/support/paths.rb:14:in `path_to'
./features/step_definitions/web_steps.rb:16:in `/^(?:|I )am on (.+)$/'
features/manage_posts.feature:7:in `Given I am on the new post page'
 
uninitialized constant Post (NameError)
./features/step_definitions/post_steps.rb:2:in `/^the following posts:$/'
features/manage_posts.feature:17:in `Given the following posts:'
 
Failing Scenarios:
cucumber features/manage_posts.feature:6 # Scenario: Register new post
cucumber features/manage_posts.feature:16 # Scenario: Delete post
 
2 scenarios (2 failed)
11 steps (2 failed, 9 skipped)
0m0.124s
rake aborted!

Generamos el scaffold del modelo Post y ejecutamos las migraciones pendientes

$ script/generate scaffold post title:string body:text published:boolean
$ rake db:migrate

Volvemos a lanzar las pruebas

$ rake cucumber
(in /Users/paul/Proyectos/cucumber_rails_test)
/System/Library/Frameworks/Ruby.framework/Versions/1.8/usr/bin/ruby -I "/Users/paul/.gem/ruby/1.8/gems/cucumber-0.10.0/lib:lib" "/Users/paul/.gem/ruby/1.8/gems/cucumber-0.10.0/bin/cucumber"  --profile default
Using the default profile...
...........
 
2 scenarios (2 passed)
11 steps (11 passed)
0m0.261s

Ahora sí que funcionan los tests y nuestra aplicación ya tiene una cobertura muy básica de tests de aceptación para la funcionalidad de gestión de posts, y los escenarios de creación y borrado. Ya tenemos listo nuestro entorno para empezar a desarrollar the-bdd-way ¿A que no era tan difícil?