por Guillermo Álvarez

Creo que todos conocemos una sintaxis parecida:

Manejar tags localmente es fácil:

> git tag -l # lista los tags locales
> git tag tag_name # Crea un tag local
> git tag -d tag_name # Borra el tag local
>
> git tag -d `git tag -l ` # Borra todos los tags locales

Pero manejar los remotos... no es tan intuitivo, así que me dejo esta
pequeña nota:

> git fetch --tags #Aunque ya lo hace por defecto
> git ls-remote --tags origin # Lista los tags remotos

Y para borrarlo, tendremos que borrar primero el local y luego hacer:

> git push origin :refs/tags/tag_name

---Adjuntos---

smime-3.p7s

Continuando con el artículo Testeando ajax sin selenium han mejorado algunas cosillas.

La versión anterio, tenía un problema y es que solo servía para visitar. ¿Pero que pasa con el resto de steps (como I press), que implican peticiones y que esperan ajax como respuesta? Pues aquí está la solución.

When /^(.*) as an ajax request/ do |task|
   When task
   response.body = get_ajax_html(response.body)
 end
 

Esto dota a las features de poder realizar cualquier acción que antes hacías y evaluar su respuesta. Por lo tanto, lo que antes era:

    And I press "Guardar"
 

Ahora es

    And I press "Guardar" as an ajax request
 

Como extensión, he visto que otras formas de page.update, usan la función javascript html en vez de replace with, por lo que la función que obtiene el cuerpo ha sido actualizada.

def get_replace_with_body(body)
   body=~/replaceWith\(\"(.*?)[^\\]\"\)/m
   body=~/\)\.html\(\"(.*?)[^\\]\"\)/m unless $1
   raise Exception.new('The ajax response doesn\'t containg a js replaceWith method') unless $1
   "#{$1}"
 end
 

Y ahora ya puedo testear casi todo el js sin usar selinium, configurar una máquina virtual, un xen, linux, firefox, selenium_server, etc...

Como quería terminar una cosa, y lo que necesita más que test de vista o test de controlador era un test de integración, no me quedó otra que dotar a cucumber+webrat-selenium (nuestro entorno de feature testín) de capacidad de ajax.

Bueno, seamos serios, son un par de lineas que me permitieron hacer ejecutar la feature, y paso a comentar, ya que de tratarse de aplicaciones rails, este método es usable para la mayoría de page.update que realizamos.

page.update actualiza un elemento del dom con nuevo contenido, para eso lanza un javascript que es interpretado por el navegador. Suponiendo que usamos jquery (tal vez cambie la implementación para el antiguo y obsoleto prototype), este hará un replaceWith. Este código parsea el código devuelto por la aplicación y extrae la actualización de la página.

Pasemos ahora a ver el código:

# Desescapamos javascript, ya que escapado no nos sirve de mucho.
 # Así tendremos un html válido. Esto se resume en:
 #  < div id="\'hola\'">\tadios\t< /div>  ===>    adios  
 def unescape_javascript(javascript)
  javascript.gsub!('\n' , "\n")
  javascript.gsub!('\t' , "\t")
  javascript.gsub!("\\'", "'")
  javascript.gsub!('\"' , '"')
 end
 
 # Expresión regular encargada de sacar lo que realmente nos intersa.
 #  ...replaceWith(' ESTO NOS INTERESA ')...
 def get_replace_with_body(body)
  body=~/replaceWith\(\"(.*?)[^\\]\"\)/m
  raise Exception.new('The ajax response doesn\'t containg a js replaceWith method') unless $1
  "#{$1}"
 end
 
 # Combinado de las dos anteriores
 def get_ajax_html(text)
  unescape_javascript(get_replace_with_body(text))
 end
 

Y el step correspondiente.

When /^I visits by ajax (.*) $/ do |path|
  visits(path)
  response.body = get_ajax_html(response.body)
 end
 

Y la feature

 Scenario: Changing my name
    Given I am a logged in as a Candidate
    When I visits /profile/edit.js ajax
    And I fill in "candidate_profile_first_name" with "Guillermooo"
    And I fill in "candidate_profile_surnames" with "Alvarez"
    And I press "Guardar"
    Then I should see "Guillermooo Alvarez"
 

La solución es fea, torpe, poco optima. Pero creo que puede resolver la mayoría de peticiones ajax del servidor sin depender de un motor javascript externo.
Si alguien conoce alguna otra forma sin incorporar más dependencias al testing... que me lo haga saber.

Basándonos en la teoría de que las máquinas están bien configuradas en lo que respecta el correo, yo voy a tener cientifico.net para correos personales y yolanda.cientifico.net para los correos locales de la máquina.

Esto permite que yo desde cualquier cuenta de correo envie un mensaje a guillermo @ yolanda cientifico PUNTO net.

Para que sirve esto.... pues para ser más comodón aún. Soy fiel usuario de scp (consola -> servidor) y webdav (escritorio<->servidor), pero poder enviar archivos a mi cuenta del servidor y al llegar allí, arrancar alpine o cualquier otro cliente de correo de consola, y poder guardarlo, es una gozada.

Ahí queda dicho.

DRB o Distributed Ruby es una abstracción de sockets tcp y serialización de objetos que trae integrada ruby por defecto.

Tenía ganas de jugar con drb y su abstracción superior sobre el patron tuple spaces que es una forma de implementar el paradigma de memoria asociativa (associative memory) desda linda, que es una forma de coordinar y comunicar diferentes procesos entre máquinas. Ya jugaremos con Rinda, pero como bien dice mi amigo Jack... Vayamos por partes.

En este caso vamos a poner un caso real en rails para procesar emails. No es que sea necesario utilizar DRb, es que es la única forma rentable que he encontrado. Recibimos e-mails con una frecuencia indeterminada, y los procesamos desde una tarea rake. Esto está bien salvo por que levantar una tarea rake que como dependencia tiene :environment, puede suponer bastante tiempo. Si supone 10 segundos y cada instancia supone 40 o 50 megas. 10 correos por segundo... tumbarían la máquina.

Pues lejos de ir más lejos se implementa una arquitectura cliente-servidor en el que el servidor es la tarea rake y el cliente es lo que se conecta con el MTA(Mail Transfer Agent) del sistema. Al grano:

El cliente, solo necesita esto

#!/usr/bin/env ruby 
 require 'drb' 
 URI="druby://localhost:9999"  
 server = DRbObject.new_with_uri URI 
 return server.process($stdin.read.to_s) 
 

Mientras que el servidor se arreglaría con esto

 
   desc 'Start Mail Daemon' 
   task :daemon => :environment do 
     require 'drb' 
     URI="druby://localhost:9999" 
     class Processor 
       def process(mail) 
         ModeloActiveRecordParaMails.create(TMail.new(mail)) 
       end 
     end  
     DRb.start_service URI, Processor.new 
     DRb.thread.join 
   end
 

Con esto estaría ya todo el trabajo hecho.

Creo que el código es bastante auto-explicativo. Si hay alguna duda... A los comentarios.