Hoy he sufrido un episodio de estos que llegan a exasperarte un poco. Se trataba de crear una serie de virtualhosts para emular en un servidor local el comportamiento de un apache "de producción". El servidor local tiene instalada una Fedora 7 y un apache "limpio".

Entre otros cambios poco relevantes para este problema, introducimos un virtualhost que simplemente hace de proxy delegando las peticiones en otro servidor, algo parecido a:

<VirtualHost *:80>
  ServerName midominio.com
  ServerAlias www.midominio.com
  ProxyRequests Off
  ProxyPreserveHost Off
  ProxyPass /app/ http://abc.blabla.com:8080/path/
  ProxyPassReverse /app/ http://abc.blabla.com:8080/path/
  ProxyPass / http://abc.blabla.com:8080/path/
  ProxyPassReverse / http://abc.blabla.com:8080/path/
</VirtualHost>

Una vez realizados los cambios en el httpd.conf y reiniciado el servicio, comprobamos con gran dolor que el proxy no está funcionando correctamente, dándonos el siguiente error:

[error] (13)Permission denied: proxy: HTTP: attempt to connect to 127.0.0.1:8080 (*) failed

Tras comprobar que todos los permisos estaban bien, que ninguna directiva evitaba que todo funcionase, etc. Me decidí a buscar ayuda en google. Y la encontré. En este enlace podéis ver la solución con más detalle, pero el resumen es que SELinux está bloqueando la conexión, y debemos de configurarlo para evitar que esto ocurra. Debemos de marcar la opción "Allow HTTPD scripts and modules to connect to the network" en la pantalla de configuración de Firewall, como podéis ver en el enlace anterior.

Como ya os comenté hace tiempo hemos estado preparado una nueva versión de Galicia Global (algo así como una 2.0) para conmemorar la edición 2008 del día de Internet y las letras gallegas.

Lo más destacable de este “upgrade” (que ya está en producción) es que ahora es posible definir amistades entre usuarios y crear redes entre ellos. Si ya os habíais registrado como gallegos globales podéis pasaros por la web a jugar un rato con las novedades, y si no lo habéis hecho ya, registraos ¿A qué estáis esperando?

Missing in action (M.I.A) is a status assigned to a member of the armed services who is reported missing following combat and may be injured, captured, or dead.

Sí amigos: desaparecer en combate. Eso es lo que le puede pasar al útil objeto console de la herramienta Firebug (que me imagino usarán/conocerán casi la totalidad de “hackers” javascript del mundo).

Si, como nosotros, la usáis, meted la siguiente línea de código como preambulo a vuestros javascripts. Os evitaréis alguna que otra excepción si olvidáis de vez en cuando un inocente console.debug en vuestro código.

if (!window.console) { var console = { debug : function(value) { }}}

Y, por cierto, el Firebug últimamente tiene tendencía a dejar al Firefox atontado… o es el Firefox el que está empezando a arrastrarse… no sé…

Hace unas horas nos preguntaron a Asís, Marcos y a mi cuánto nos gustaba programar… difícil respuesta.

Quizás el título de este post pueda dar lugar a equívocos. Obviamente, una de las consecuencias de refactorizar suele ser la reducción del código. A lo que me refiero con “eliminar código es refactorizar” es a erradicar toda señal de código innecesario en una aplicación.

Las preguntas a hacerse

1. ¿Se utiliza este código en alguna parte de la aplicación?
2. ¿Es el código parte de un plugin y se utiliza en otras aplicaciones?
3. ¿Se utiliza o no se utiliza?

Si la respuesta es no, no,no

Si te pareces a Amy Winehouse borra ese código.

Borrar código es bueno. Eliminas puntos de fallo. Reduces el número de tests necesarios. Abrevias la documentación. Es decir: reduces el ruido en tú aplicación.

Y si te arrepientes más adelante de borrarlo

Usa el control de versiones… ¿o no estás usando ninguno?

Ahora que estamos utilizando a tope Rails 2.0 y toda la parafernalia REST en nuestras aplicaciones, nos hemos dado de bruces con un pequeño problema de rutas.

La solución pre-REST

Digamos que nuestras aplicaciones están internacionalizadas y que tenemos la costumbre de poner el código de idioma en la URL, utilizando un filtro para forzar que este código aparezca en la misma mediante una redirección. Una técnica bastante habitual y extensamente documentada.

# application.rb
before_filter :set_language

def set_language     
  unless (locale = params[:locale]).blank? && Languages.supported?(locale)
    set_locale(@locale = locale)        
  else
    redirect_to params.merge(:locale => Languages.default)
    return false
  end
end

# routes.rb
map.connect ':locale/:controller/:action/:id' 
map.connect ':controller/:action/:id'

De este modo, la primera petición a la aplicación que no lleve el idioma en la URL recibirá como respuesta una redirección a la misma URL con el añadido del idioma.

El problema con REST

Si añadimos un recurso, las rutas generadas y los helpers para crear paths y urls no incluirán el código de idioma, por lo tanto, si no hacemos nada, al pasar por el filtro cada petición recibirá como respuesta un redirect. Mal asunto.

# routes.rb
ActionController::Routing::Routes.draw do |map|   
  map.resources :customers
end

La solución

En primer lugar necesitamos modificar ligeramente las rutas para que estas incluyan el código de idioma.

ActionController::Routing::Routes.draw do |map|   
  map.with_options(:path_prefix => ':locale') do |localized_map|
    localized_map.resources :order
  end
end

Por último debemos lidiar con la generación de rutas. Como quedaría feo (y no muy DRY) tener que andar pasando el código de idioma a cada helper (léase order_path(@current_locale, @order)) lo que necesitamos es modificar el comportamiento de Rails para que lo haga él solito. Y qué suerte la nuestra, ya existe un plugin para eso: localize_url_helpers, que de forma transparente incluye el idioma y nos permite usar los helpers como de costumbre.

C’est voila.

Las últimas semanas de desarrollo con Ruby on Rails en Trabe Soluciones se han dividido a partes iguales entre el desarrollo de una nueva aplicación y la modificación y mejora de otras dos. Trabajar con código antiguo (entiéndase por antiguo: con al menos un mes de vida) es siempre una invitación para la mejora y el refactoring. Es indiscutible que a lo largo de un mes un programador evoluciona de manera tal que todo lo que ha hecho hasta el momento le parece malo (o al menos peor que lo que hace actualmente). Demos paso al refactoring.

Podemos enfocar esta tarea de un modo sistemático y enfermizo, en busca de un código excelso cuya sola contemplación nos haga entrar en una suerte de experiencia mística (perdiendo tiempo y salud mental) o bien podemos dejar que fluya sin más.

Un ejemplo: vamos a simplificar la definición de las típicas acciones index que sólo delegan. Cuando te encuentras por segunda o tercera vez con algo como esto:

def index
  list
  render :action => list
end

... decides cambiarlo por algo como …

index_as :list

# Refactoring ohh yeah!!!
def self.index_as(method)
  define_method :index do
    send(method)
    render :action => method
  end      
end

10 minutos después la aplicación ha perdido peso y todos lo agradecemos (y más ahora que llega el verano y la playa).

Parece poca cosa, pero cualquier refactoring, por pequeño que sea, es bueno. El principio de no repetirse no es una idea feliz de un loco cualquiera; es un concepto fundamental en el desarrollo de aplicaciones de calidad, y si aún no lo practicas ya es momento de empezar.

Ya ha terminado el seminario (bueno, hace un par de horas) y estamos muy satisfechos con el resultado final. La gente ha participado, parece que no se ha aburrido (demasiado) y han aguantado como campeones las casi cuatro horas de Ruby y Rails. Tanto Asís como yo y el resto de gente en Trabe Soluciones queremos agradecer a todo el mundo su asistencia. También queremos darles las gracias a Fernando Bellas y Víctor Carneiro por su ayuda y colaboración para montar el seminario.

Por cierto, ya hemos dejado para descargar las trasparencias en PDF de la charla.

Nos vemos en la próxima.

Digo yo que si en el mundo REST un POst te permite crear (Create) un recurso; un Get te permite obtener una representación de un recurso (leer, Read); un PUt te permite modificar (Update) un recurso; y un Delete te permite borrar (Delete), un recurso… POGPUD será la versión RESTful de CRUD.

Vamos, digo yo xD

Asís y yo hemos decidido hablar un poco sobre JRuby en el seminario introductorio de Rails del jueves, ya que esperamos que la mayoría de los asistententes vengan del mundo Java.

Para preparar el material he vuelto a revisitar la página del proyecto que tenía un poco abandonada. Me ha sorprendido lo mucho que han avanzado y como han mejorado la integración con Java. Es bastante sencillo:

include Java
import 'java.util.ArrayList'

list = ArrayList.new
list.add "uno" 
list.add "dos" 
list.add "tres" 
list.each do |n|
  puts "num: #{n}" 
end

list.class.name # => "Java::JavaUtil::ArrayList
list.java_class.name # => "java.util.ArrayList" 

Esto y mucho más, en el wiki. La verdad, crear ventanas swing desde jirb hace que un escalofrio te recorra toda la espalda. Curioso cuanto menos.

NOTA: Un día de estos pruebo a desplegar alguna de nuestras aplicaciones con JRuby en un Tomcat utilizando Goldspike y os cuento.