Generando javascript con código ruby embebido en rails 2.x

Hay veces que es bastante útil y cómodo devolver en una petición código javascript para que sea ejecutado en el cliente (y actualice el interfaz del usuario o lo que tenga que hacer). En vez de realizar (1) Petición, (2) Generar datos, (3) recepción y procesamiento, (4) actualizar página; pasamos a (1) Petición, (2) generar código, (3) actualizar página. Es decir nos ahorramos el parseo, además nos ahorramos tener que cargar javascript (que procesa las respuestas) en el cliente y usando jquery/mootools/* se realiza todo el proceso de forma transparente (indicando en la petición ajax que esperamos recibir un script). Esta técnica será válida solo para pequeñas actualizaciones (que son mayoría) y principalmente para temas de interfaz (que suelen ser triviales), pues en definitiva el código que no se ve, es código difícil de mantener.

En Rails tenemos templates RJS que básicamente consiste en lo que acabo de comentar pero generando javascript con wrappers en vez de usar js sin más, algo que me parece absurdo, pero eso es otro tema. Para rails 1.2.x teníamos este maravilloso plugin de Dan Webb que te permite escribir javascript con ruby embebido en él, algo como:

<% @ids_to_modified.each do |id| %>
   $('#' + <%= id %>).removeClass('<%= @class_to_remove %>').highlightFade();
<% end %>

Desde Rails 2.x ya no es necesario el uso del plugin (en parte porque ya no va), pues podemos hacer esto mismo gracias al nuevo formato de las vistas.

Ahora todas las vistas tienen el formato nombre.formato.template_engine, por ejemplo lo típico sería algo como: nombre.html.erb. Pero, ¿por qué no tener plantillas como nombre.js.erb?. De esta forma tendremos, sin incorporar plugins ni nada, la funcionalidad antes comentada, generar javascript permitiendo ruby embebido (es decir, usando erb).

Para hacernos la vida algo más simple, vendría bien incorporar ciertas funciones y helpers. En tu application.rb, no estaría de más tener algo como:

def respond_with_js
    respond_to{|format| format.js }
end

Por lo que nuestras acciones que vayan a ser llamadas mediante xhr tendrán una pinta tal que:

def vote
   # hacer lo que sea...
   respond_with_js
end

Tenemos que tener en cuenta también, que el javascript generado debe de ser válido (por ejemplo escapar comillas en las cadenas, o similares). Para asegurarnos que algo es javascript válido, nada mejor que usar json por lo que podemos pillar prestado del plugin de MinusMOR su helper (y añadirlo a application_helper.rb)

def js(data)
  if data.respond_to? :to_json
    data.to_json
  else
    data.inspect.to_json
  end
end

Por lo que ahora podemos escribir cosas tal que:

$('div.cancel').append(
    <%=js link_to('Cancelar', :action => 'cancel') %>
);
# o
alert(<%=js error_message_for(@error) %>);

Finalmente, si queremos usar partial's tendremos que añadir este helper para soportar el nuevo formato de las plantillas (gracias a mad.ly):

def partial(name, options={})
  old_format = self.template_format
  self.template_format = :html
  js render({ :partial => name }.merge(options))
ensure
  self.template_format = old_format
end

Fíjate que no estamos sobreescribiendo el render :partial típico, es un helper simplemente. Para usarlo tendríamos que hacer algo como:

$('#some_div').html(<%=partial 'movie_information', :object => @movie %>);

En definitiva una forma mucho más cómoda, potente y simple de generar javascript desde el lado del servidor. Aunque insisto en que solo se debería de usar esta táctica para cosas triviales y pequeñas.

Lenguajes, estadísticas y tonterías

Hay muchas maneras de conocer la popularidad de un lenguaje de programación, o una tecnología en particular. Me encantan este tipo de historias a pesar de su dudosa fiabilidad, al menos cuando se toman sus valores absolutos, sin una interpretación detrás. Me entretengo más que un tonto con un lápiz con servicios de este tipo. Hay unos cuantos, comentaré los que conozco y más útiles pueden resultar:

  • El abusurdo índice Tiobe (que cada vez me lo creo menos).
  • Google Trends, el cual puede ser usado para cualquier cosa en general, aunque es difícil de usar pues muchas veces términos de lenguajes o tecnologías significan algo más en el mundo real (Java es una isla y un tipo de café, ruby es una piedra preciosa, python es una serpiente o una referencia a los Monty Python, etc...).
  • Indeed.com sitio web estadounidense de búsqueda de empleo que ofrece un servicio de tendencias en los trabajos, tanto por valores absolutos como relativos. El más simple y potente de usar.

Jugando un poco, me he encontrado con gráficos bastante curiosos. Nadie duda que en estos momentos Java es lo más usado, pero creo que tampoco nadie dudará en que estamos ante un auge de los lenguajes dinámicos. Veamos datos absolutos:
Java, perl, php, python, ruby chart absolutes values
La primera posición de Java no sorprende, la segunda de perl, a mi al menos, tampoco; luego tenemos php por encima de python y ruby. Los datos son bastante usuales. Recordemos que estamos antes tendencias de ofertas de trabajo, es decir el uso de lenguajes en el mundo empresarial. Pero ahora veamos sus valores relativos (es decir, su crecimiento y tendencia).

Por la gráfica anterior, podemos deducir que los valores de Java y Perl son prácticamente iguales en el tiempo, sinónimo de su madurez, pero ¿qué pasa con php, python y ruby?:
Java, perl, php, python, ruby chart relatives values
¿De quién es esa línea que va por el 550%? Ruby. Curiosa situación, quizá el apoyo de Sun tenga algo que ver en todo esto. Quizá...

Visitas en el 2007: para el pozo

A pesar de ser un maniático compulsivo de las estadísticas, las que menos me importan son las de mi blog personal (esto que estás leyendo), quizá porque no ansío ganar nada de dinero, y no me importa que me visiten cuatro gatos (los mejores sin duda), escribo bicosyes.

Aunque después de ver el post de DraXus e ir a google analytics me ha mosqueado bastante que no esté disponible (o soy muy tonto para encontrarlo) una opción para agrupar los datos de las estadísticas (por mes, por ejemplo...). Como tiene una opción para exportar los datos (a csv por ejemplo), y como me aburro mucho, me he hecho un script tonto para sacarme un cool gráfico por meses. Ves que bien.

estadísticas de bicosyes.com en el 2007 por meses

Como podemos ver en él, se puede deducir que aquí no entra ni san Pedro. Don't worry, be happy.

Ya que me pongo con estadísticas y a pesar de que a nadie le importe estos datos salvo a enfermos compulsivos estadísticos, voy a mencionar los datos más interesantes a mi parecer:

Como conclusión, par de tetas atraen más que cualquier otra cosa y si quieres visitas más te vale sacar algo conocido o buscado, una lastima porque no creo que en un futuro próximo saque algo sobre una rubia espía programando en Java un fork de frets on fire.

Me sorprende el tráfico de gente con el puto bindous de las narices, y aún más el porcentaje de IE. Querido visitante, si usas IE vete de aquí, cuando seas mayor, vuelve. También bastante sorprendente que Opera esté por encima de Safari (¿quien narices usa Opera? Un navegador no soportado por Google yo lo considero muerto, r.i.p.)

Posiblemente todas estas sorpresas que veo sean debidas al tráfico proveniente de los buscadores (tráfico ocasional que solo busca una respuesta rápida de cómo poner una imagen en java, o que busca canciones de frets on fire, o similares), quizá este año ponga un filtro para eliminar todo ese tráfico "basura".

Si alguien le interesa el script tonto, está en ruby. Simplemente hay que descargar el fichero CSV de las visitas una vez aplicado correctamente el rango (desde el 1 enero hasta 31 diciembre) e indicarle al script el nombre de dicho fichero y, opcionalmente, el título del gráfico. Las librerías requeridas están comentadas en la cabecera del fichero. El gráfico de arriba lo he generado tal que así:

$ ./GoogleAnalyticsCsvParser.rb data.csv "Visitas bicosyes.com 2007"

Tarea para Rake: Ruby on Rails en Aptana

Aptana es un IDE basado en Eclipse, el proyecto RadRails que pretende facilitar el desarrollo de aplicaciones con Ruby on Rails desde Eclipse se encuentra ahora dentro Aptana. Un problema típico puede ser que ya tenías tu proyecto empezado e intentas usarlo desde Aptana. Según cómo hayas creado tu aplicación puede llegar a traducirse a un cuelgue de Aptana debido a que no detecta bien el bucle infinito de enlaces simbólicos que se crea dentro del subdirectorio vendor cuando se crea la aplicación con un típico rails [nombre de la aplicación] (al menos si has usado los paquetes de ubuntu, incorrecta forma de instalar rails, por cierto).

Historias y rayadas aparte, si quieres importar tu proyecto de ruby on rails a Aptana/Eclipse, algo así como el típico mvn eclipse:eclipse de maven en el mundo Java, he hecho una tarea para rake, para realizar este proceso. Creará los ficheros necesarios para poder importar luego el proyecto desde Aptana, y eliminará los enlaces simbólicos malignos que he comentado en el anterior parrafo en caso de que existiesen.

Simplemente descargamos el fichero y lo colocamos en lib/tasks, y ejecutamos rake aptana:aptana. Esto nos creará en el raíz de nuestro proyecto dos ficheros, .loadpath y .project, que harán que nuestro proyecto pueda ser importado en Aptana (File, import, Existing projects..., y tal).

Sigue leyendo

Anuncios de “Ruby on Rails VS …”

En RailsEnvy hay una lista de vídeos al estilo "I'm a Mac, I'm a PC" donde comparan Ruby on Rails frente a otras plataformas para el desarrollo Web. Por ahora hay versus PHP, Java, coldfusion, Django y .net. De algunos de ellos incluso varios. Este es el segundo respecto a .net, en mi opinión el mejor sin duda, aunque el de coldfusion le sigue de cerca, y en el de Java curiosa forma que tienen de representar una tecnología de la plataforma mediante un bote rojo, a que no adivinas qué es!

Ruby on Rails, ¿se acabó lo que se daba?

Hace 3 años se publicó lo que fue la primera versión de un increíble framework para el desarrollo Web en un lenguaje de script no muy conocido, Ruby. Este framework era Ruby On Rails, y comenzó la revolución.

Desde entonces, en los dos años siguientes el tema de moda en la programación Web era lo cool que era RoR, que molaba mogollón, que era la hostia, que viva la madre que lo parió, y esas cosas. Incluso el año pasado me dio por probarlo a ver si realmente merecía la pena. Después de probar algunas de sus características lo dejé por dos razones, (1) ruby me parece parecía un lenguaje de script apestoso (yo lo veo como una mezcla de ada y perl, los cuales tienen unos puntos de vista totalmente opuestos!, ¡eso no se hace!), (2) ninguna de sus características es algo revolucionario, sí, son curiosas y chocan la primera vez, pero nada que no se puede hacer en otro lenguaje (en una tarde te programas la característica X que necesitas).

Últimamente se ha ido tranquilizando la cosa y apenas se hablaba ya de Rails, o al menos no tanto. Y hace un mes, a raíz de este post, empezaron las críticas sin parar hacia éste. Famosa es ya la historia de Twitter, aplicación escrita en RoR, que cuando alcanzó su éxito y comenzó su uso intensivo, estaba más tiempo caída que online (exagerando las cosas claro, pero era muy lenta y con bastantes caídas) y a partir de ésto se atacaba a rails criticando su falta de eficiencia y escalabilidad.

En mi opinión todo se está exagerando, simplemente la moda de Ruby On Rails ha pasado (2 años creo que es ya más que suficiente), lo cual no quiere decir que vaya a desaparecer, pero posiblemente significa que no crecerá mucho más, y dado que en el ámbito empresarial no es que haya entrado muy fuerte (principalmente debido a una falta de soporte o entidad detrás del framework, a diferencia de, por ejemplo, GWT o apestosas tecnologías Java en general), esto significa que la caída ha comenzado y no hay quien la pare.

Si hace un año hubiese dicho que Rails es una mierda, la gente me hubiese escupido, pegado una paliza, Google no me indexaría, Microsoft me mandaría bindous con cada telepizza y los teletubbies me dedicarían una canción. Ahora, una vez que ha pasado la moda, ya se permite tocar al intocable, y quien quiera, puede decir lo que le plazca. Ves que bien. Por mi parte, cuando tenga que realizar una aplicación Web en el futuro, rails será una de mis últimas primeras opciones, puesto aunque que por alternativas, no será.