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!

Las empresas acostumbran a destinar uno o varios servidores para albergar en ellos los repositorios de cada uno de sus proyectos. Otras recurren a servicios como los que incluyo a continuación.

A nivel personal, es muy probable que no contemos con esa infraestructura y nos interese contratar un servicio bueno, bonito y barato, que nos permita alojar nuestros proyectos privados (y otros públicos). Si bien es cierto que GitHub es uno de los sitios más populares y alberga el código fuente de muchas aplicaciones conocidas, existen otras alternativas.

Bitbucket

Visitar ell sitio web de BitBucket

Codebase

Visitar el sitio web de Codebase

Codeplane

Visitar el sitio web de Codeplane

GitHub

Visitar el sitio web de GitHub

Projectlocker

Visitar el sitio web de Projectlocker

Repositoryhosting

Visitar el sitio web de RepositoryHosting

unfuddle

Visitar el sitio web de unfuddle

XP-Dev

Visitar el sitio web de XP-Dev

Si conoces alguna alternativa más estaré encantado de incluirla en este listado. Gracias!
]]> http://alonsogarciapablo.com/blog/sitios-web-alojar-el-codigo-fuente-privado/feed/ 6 http://alonsogarciapablo.com/blog/modulos-en-ruby/ http://alonsogarciapablo.com/blog/modulos-en-ruby/#comments Thu, 12 May 2011 07:54:17 +0000 Pablo http://alonsogarciapablo.com/blog/?p=603 Llega un momento en la vida del programador Ruby en que, de forma natural, empieza a indagar en el código escrito por otras personas, por ejemplo en proyectos alojados en GitHub. En estos proyectos se empieza a ver cómo se hace uso de los módulos, mixins, etc. Pero no siempre es fácil de entender todos estos conceptos.

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.

Por fín he terminado de leer Clean Code, el famoso libro de Robert C.Martin a.k.a. Uncle Bob, que algunos conoceréis por ser uno de los autores del manifiesto ágil. Después de haberme encontrado con innumerables referencias al libro – tanto en twitter, como en algunos blogs que sigo habitualmente (que ahora recuerde este de @kinisoftware y este de @jacegu) – me propuse leerlo como uno de los objetivos para este año.

Escribir código que funciona es una tarea relativamente sencilla. Lo difícil es escribir código que, con el tiempo, no se convierta en un “chorizo” imposible de ampliar y/o mantener, y que sea entendible por otros programadores. En Clean Code, Uncle Bob nos explica su visión del buen código: el código limpio.

Resumiendo mucho, un código limpio (y bueno según el autor):

• Incluye nombres significativos en variables, funciones, clases, etc.
• Incluye funciones con responsabilidades bien diferenciadas, los parámetros justos, un nivel de abstracción uniforme.
• No repite código.
• Está autodocumentado, por lo que no es necesario usar comentarios.
• Está bien diseñado. Por ejemplo, hace uso de interfaces en vez de implementaciones concretas.
• Tiene bien separado el manejo de errores para que esto no interfiera en la comprensión del código.
• Se integra bien con otras aplicaciones, manteniendo limpias las fronteras y transformando la información externa en objetos de nuestra aplicación.
• Está cubierto al 100% por una batería de tests que comprueban todos los posibles caminos de ejecución.
• Está dividido y organizado en clases de un tamaño justo con responsabilidades bien definidas.
• Separa claramente la construcción e inicialización del sistema de lo que es la ejecución en sí.
• Crece de una forma sostenible, es decir que la arquitectura evoluciona incrementalmente y el código no va degenerando sino todo lo contrario, con cada cambio es más “fino” y siempre cumple las 4 reglas de Kent Beck para escribir código limpio.

El libro está repleto de código escrito en Java. Hay 2 capítulos donde Uncle Bob explica las refactorizaciones de una clase de JUnit y la clase org.free.date.SerialDate. Estos ejemplos son muy educativos, aunque exigen bastante atención.

En general no es un libro “de piscina” ni “de váter”, sino que requiere bastante esfuerzo: reeler los ejemplos para entenderlos, subrayar y tomar notas, consultar referencias, etc.

Me ha gustado por que no sólo te explica cómo escribir si no que tiene bastantes referencias y conceptos como la Ley de Demetrio, Desarrollo guiado por pruebas (TDD) y las reglas F.I.R.S.T., Separation of Concerns, Single Responsability Principle (Principio de Responsabilidad Única), Open-Closed Principle, Inversion of Control y el patrón Depency Injection, Domain Specific Languajes, etc.

También ayuda a ver y compreder algunos patrones de diseño como Abstract Factory y Adapter (Wrapper).

El último capítulo incluye una referencia de “Smells and heuristics”, que son una ampliación de los Code Smells del libro de Refactoring de Martin Fowler y que sirve como muy buen resumen del resto del libro.

Sin duda, Clean Code puede marcar un antes y un después en tus capacidades de programación si lo estudias con dedicación.

Y cómo la práctica hace al maestro, ¡ahora toca practicar!

• Pass all tests.
• Clear, expressive & consistent.
• Duplicates no behavior or configuration.
• Minimal methods, classes, & modules

Cuya traducción al castellano vendría a ser:

• Estar bien cubierto y satisfacer las aserciones de una buena batería de tests unitarios.
• Expresar las ideas que nosotros como programadores queremos expresar (código auto-documentado).
• Decir cada cosa una única vez (DRY -> Don’t Repeat Yourself).
• Evitar tener partes supérfluas: debe ser simple y satisfacer las necesidades actuales, sin pensar en lo que puede pasar en el futuro (You ain’t gonna Need it -> YagNi); y tener el mínimo número de clases y métodos (teniendo en cuenta el Principio de Responsabilidad Única).

Me he enterado de la existencia de estas reglas gracias al libro Clean Code, que llevo tiempo leyendo y que mucha gente considera de obligada lectura para cualquier desarrollador de software.

Ryan no cuenta nada nuevo. Sin embargo, a través de un ejemplo práctico y en tiempo real, explica de forma muy sencilla cómo abordan la creación de una aplicación web 37signals. Allí siguen los siguientes pasos:

1. Estudiar el modelo y obtener los conceptos sobre los que tratará la aplicación,
2. Crear prototipos visuales de la estructura de las pantallas/wireframes,
3. Aplicar el diseño gráfico a los prototipos,
4. Maquetar las pantallas mediante HTML/CSS,
5. Programar la aplicación y ver los resultados.

De la charla me quedo con dos cosas importantes:

• Es muy probable que cuando el cliente vea los primeros prototipos de la aplicación empiece a darse cuenta de posibles cambios y mejoras en la aplicación. Es importante pararle los pies al cliente para no caer en una toma de requisitos infinita. Se le pueden plantear soluciones genéricas que le satisfagan y permitan continuar con el desarrollo.
• Lo anterior es importante para poder avanzar con todo el proceso y sacar rápido una primera versión al mercado. Esto les permite obtener rápidamente feedback de los clientes/usuarios y realizar los cambios oportunos en base a experiencias reales y no a elucubraciones hechas en una fase temprana en la que no se conoce bien el dominio de la aplicación.

Espero que os guste.

En este video de 4:44, Ward explica la historia y motivaciones de esta metáfora.

Ward comenzó a utilizar esta métafora mientras desarrollaba una aplicación relacionada con las finanzas (por eso usó una anología financiera). La idea es que cuando implementas unas solución de una forma rápida, adquieres una deuda, igual que la deuda que obtienes con un banco cuando este te concede un préstamo. En el momento ganas en velocidad (tiempo), y si pagas la deuda rápido no habrá problemas. El problema ocurre cuando mantienes esa deuda técnica: mientras sigas endeudado, seguirás pagando intereses.

Hay muchas tareas en el desarrollo de software que pueden ser objeto de la deuda técnica, como: refactorizaciones del código de la aplicación para que sea más limpio y tenga un mejor diseño, documentación (como el Javadoc por ejemplo), implementación de los tests, etc.

Un proyecto donde sólo se desarrollan nuevas funcionalidades y se aumenta continuamente la deuda técnica es muy probable que fracase, debido a los intereses que hay que pagar: código que sólo los desarrolladores que comenzaron el proyecto son capaces de entender, código espagueti; mayores probabilidades de que los desarrolladores estés desmotivados y escriban peor código, etc.

Por eso, hay que tomar medidas para saldar periódicamente nuestra deuda técnica (en aquellos casos en que se haya producido). Por ejemplo: llevar un registro de esas tareas pendientes y reservar tiempo en el futuro próximo para llevarlas a cabo. Según Ward, la aplicación debería reflejar en todo momento la comprensión que los desarrolladores tienen sobre el problema.

En definitiva, y según mi experiencia, coincido con el contenido del vídeo: no es bueno dejar este tipo de cosas para mucho más tarde, porque en la mayoría de ocasiones “Later equals never”. ¿Cuántas veces, ante un código que funciona has pensado: “mañana lo reviso y lo refactorizo para que esté más limpio”; y, tiempo más tarde, ni siquera tú entendías lo que hace? Seguro que sabes de lo hablo. En estos casos, corremos el riesgo de caer en un “efecto bola de nieve” en el que cada día aumenta la entropía de la aplicación. Y es entonces cuando el proyecto tiene todas las papeletas para fracasar.

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?

Con el objetivo de garantizar la accesibilidad de los contenidos Web, los desarrolladores deberíamos hacer uso de herramientas que faciliten esa labor, y sirvan para comprobar que los sitios son real y funcionalmente accesibles. En este post, quiero recopilar todas las herramientas que estamos viendo en clase.

Validadores automáticos

• TAW: Desarrollado por la Fundación CTIC.
• Hera: Responsabilidad de la Fundación Sidar.
• WAVE: Por WebAIM: Web Accessibility in Mind.

Complementos para Firefox

• TAW en un clic.
• Hera Extension.
• Web Developer Toolbar.

Amplificadores y lectores de pantalla

• Zoomtext
• Jaws. Impresiona escuchar esa voz sintentizada.

¿Qué es la accesibilidad Web?

Una de las definiciones más populares, por razones obvias, es aquella propuesta por Tim Berners-Lee:

“El arte de garantizar que cualquier
recurso, a través de cualquier medio, esté disponible para todas las
personas, tengan o no algún tipo de discapacidad”

Como sabemos, no hablamos únicamente de personas ciegas, sino que debemos incluir en este grupo: personas que no distinguen bien los colores, con visión reducida, gente mayor, etc

¿Qué es WAI?

Web Accesibility Initiative, es una iniciativa del W3C que aboga por el cumplimiento global de las normas de accesibilidad. Se dividen en:

• WCAG. Contenido web accesible.
• ATAG. Herramientas de Autor (como Dreamweaver y FrontPage) accesibles y que generen código accesible.
• UAAG. Navegadores y herramientas multimedia accesibles.

La siguiente imagen, resume lo expuesto anteriormente:

“A”, “Doble-A” (AA), y “Triple-A” (AAA)

Las normas, están divididas en checkpoints o puntos de verificación, cada uno de los cuales tiene asociado una prioridad, en función de su impacto en la accesibilidad de los contenidos:

• Prioridad 1: El desarrollador tiene que satisfacer este punto de control.
• Prioridad 2: El desarrallador debe satisfacer el punto de control.
• Prioridad 3: El desarrollador puede satisfacer el punto de control.

Esto significa que, lo mínimo que debería hacer un desarrollador, es cumplir los checkpoints de prioridad 1. Así, aparecen 3 niveles de conformidad de los contenidos Web:

• Nivel de conformidad “A”: Se cumplen todos los puntos de verificación de Prioridad 1;
• Nivel de conformidad “Doble-A”: Se cumplen todos los puntos de verificación de Prioridad 1 y 2;
• Nivel de conformidad “Triple-A”: Se cumplen los puntos de Prioridad 1, 2, y 3.

Actualmente, los sitios Web de la administración pública, deberían tener el nivel de conformidad “Doble-A”.

La ley española

Lo que interesa ahora, sobre todo a las administracions públicas, que pueden ser sancionadas, es la LEY 49/2007, de 26 de diciembre, por la que se establece el régimen de infracciones y sanciones en materia de igualdad de oportunidades, no discriminación y accesibilidad universal de las personas con discapacidad.

Otras normas y leyes importantes

• La norma Española UNE 139803:2004, de AENOR, compatible con las directrices WAI.