Es más que habitual ver gente de dentro de una comunidad de un framework inspirado en Rails hacer críticas más o menos feroces hacia el propio Rails, y comparar el framework de turno con Rails para “demostrar” que tiene mejor rendimiento, que escala mejor(en cualquier caso, pienso que sería más correcto decir que es más fácil escalar), etc., afirmaciones que pueden ser más o menos reales, aunque hay por ahí algunos benchmarks/comparativas que hay que cogerlos con pinzas.

A mi, en la mayoría de los casos, me parece una actitud negativa que “enfrenta” comunidades, a ver quien la tiene más larga, y no lleva a ninguna parte. Es mucho más inteligente observar, aplaudir y por qué no copiar o adaptar, los avances de frameworks diferentes al “mío”.

Para mi, el gran mérito de Rails, además de que se haya creado una comunidad más que interesante alrededor suyo, es que replanteó a muchos como se llevaba a cabo el desarrollo web, y por ello que hayan salido tantos frameworks web que lo han tenido como ejemplo para tener algo similar en otros lenguajes de programación (Grails, Django, CakePHP, Symfony, Roo, Zend, Play!, y otros muchos que me dejo).

Y volviendo al post de Jacob Kaplan-Moss, agradece principalmente dos cosas de Rails:

• La programación debe ser divertida(pienso que Ruby dentro de Rails tiene mucha culpa en este punto): Creo que la mayoría que nos metimos en este mundillo, lo hicimos porque nos parecía que iba a ser divertido (bueno… otra razón era que la informática era el futuro y se iba a cobrar mucho dinero XD).

  Jacob habla de que la comunidad Python a veces se toma a ella misma demasiado en serio: necesitaba ser un lenguaje serio, usado por gente seria, para empresas serias y grandes desarrollos(a.k.a. “enterprisey”).

  Y llegó Rails para recordar que el desarrollo web debería ser algo divertido, la comunidad Rails en general desprende que se pueden desarrollar productos pequeños, divertidos, ligeros y además hacer dinero con ellos.

• La simplicidad es una feature, o lo que sería menos es más: Pone como anti-ejemplo el caso de los CMS y la típica obsesión de cubrir el máximo de casos de uso posibles, terminando siendo productos mastodónticos. Aunque no exclusivo de los CMS, seguro que muchos de los que hemos trabajado con gestión de contenidos, lo hemos vivido.

  Rails, por un lado no pretende cubrir el máximo de casos de uso reales, para eso hay plugins que pueden facilitar la vida; y por otro, es un framework opinado (aquí entra lo de Convention over Configuration ). Lo que quiere decir que el framework tiene un funcionamiento por defecto que no es necesario configurar, para ahorrar decisiones al desarrollador, lo que lo hace más simple.

  Resumiendo, gracias a Rails, estos nuevos frameworks tratan de minimizar el trabajo “genérico” de los desarrolladores, sin querer llegar a cubrir cada caso de uso.

¿He dicho que el lenguaje con el que más he trabajado(y sigo trabajando) es Java? Considerado uno de los lenguajes más “serios” y más complejos en cuanto a configuraciones, especificaciones… pero sobre todo en la forma que se ha venido utilizando. Y gracias a Rails han aparecido algunos frameworks web interesantes como Grails o Play!, y creo que algunos otros de los que no hablo porque no tengo suficientes referencias, que son más divertidos y minimizan el trabajo.

Por esto, además de porque he trabajado con Rails y que tengo pendiente retomarlo XD, gracias!

He pasado de 2.7.1 a 2.8.5 y por ahora sin problemas, si alguien encuentra algo, se agradece el aviso

Pues resulta que hace unos días, en alzado han convocado la Beca Alzado 2009. Para el que no la conozca, es un concurso de ideas, donde al ganador se le dan 3000€ para ayudarle a que se pueda hacer realidad, sin ningún compromiso con alzado ni nada de letra pequeña.

Sólo puedo recomendar presentarse a todo el mundo que ande con un proyecto interesante entre manos. En nuestro caso, nos ha servido de ayuda a muchos niveles(los 3000€, ganar visibilidad, consejos…), además de ser una gran inyección de motivación

Y para los que queráis saber más acerca de Jobsket, tras convocar la Beca para este año, Eduardo Manchón ha publicado una entrevista a Martín, donde habla de un poco de todo: de donde venimos, hacia donde queremos ir, como trabajamos…

By dream sister

A mi ha llegado un punto en que me resulta gracioso, dependiendo de la experiencia de cada programador, se oyen opiniones que no tienen nada que ver unas con otras. Cuando al final, que un producto sea mejor o peor(al menos a nivel de programación), depende más de la capacidad del programador y su experiencia con el lenguaje que utilice, y no del lenguaje en sí.

Algunas opiniones/tópicos que he visto repetirse muuuchas veces:

Java es “enterprisey”.
Rails no escala.
Para aplicaciones empresariales serias, hay que utilizar Java.
Javascript es sucio.
Si no tiene tipado estático, es para aplicaciones de juguete.
-Pon aquí un lenguaje- es lento.
-Pon aquí un lenguaje- es una mierda XD.

O el clásico:

Cobol está muerto

Y para que no se diga, tampoco estoy libre de pecado, yo pienso que PHP lo pone demasiado fácil para empezar a escribir código spaghetti XD

Precisamente, el lunes noche volví de unos días de vacaciones en Bélgica, donde visité a un “cerebro fugado” que se dedica a la investigación. Además, pude conocer a más españoles en su misma situación y hablamos sobre el tema, son investigadores a los que les gustaría volver, pero mientras quieran dedicarse a la investigación lo tienen realmente difícil y con hasta un 37% de recorte presupuestario, la puerta que seguirá abierta será la de salida.

Pienso que es interesante que unan el esfuerzo que ya estaban haciendo por separado impartiendo charlas, talleres y seminarios para “evangelizar” acerca de las bondades que pueden aportar Groovy o Grails; y que se quieran enfocar conjuntamente en hacer llegar estas tecnologías a las empresas para tratar de ayudarles a ser más productivas(principalmente a empresas Java, obviamente).

Os dejo los videos que grabaron durante la presentación, si os interesa conocer algunas cosas del lenguaje Groovy o del framework Grails, no dejéis de verlos:

Álvaro Sánchez-Mariscal, haciendo una introducción a Groovy

Nacho Brito, acerca de los beneficios de usar Groovy

Pues resulta que hoy me ha llegado un correo de SitePoint, anunciando que durante 7 días la versión en PDF está disponible para descarga gratuita, yo ya me lo he descargado, a ver cuando voy terminando mis lecturas pendientes y le dedico un tiempo, a ver si resulta un libro interesante y útil.

Después de refactorizar nuestro código javascript dependiente de prototype, donde hemos encontrado que hay efectos muy sencillos de implementar gracias a script.aculo.us que no lo son tanto con YahooUI(la librería Effects Widget nos ha ayudado en esta transición), nos encontramos que teniendo en el layout la declaración de qué librería deben usar para renderizar esos taglibs de Ajax, en las vistas seguía haciéndolo con el código para prototype, por lo que daba errores javascript. Para que en cada vista renderizara usando el código de YUI, debemos poner la declaración <g:javascript library=”yui” /> en cada vista, yendo con cuidado en el orden de las dependencias, ya que si hay un <g:javascript library=”yui”/> en el layout y en la vista sólo se renderizará el segundo, por lo que habría que hacer algo así:

En el layout:
<g:javascript library="yui" />
<g:layoutHead />
<yui:javascript dir="..." file="..." />
<yui:javascript dir="..." file="..." />
<g:javascript library="application" />

En la vista:
<g:javascript library="yui" />
<yui:javascript dir="..." file="..." />

En este orden se renderizarán primero las dependencias básicas de la librería YUI, luego las que necesitemos para usar componentes, y por último nuestro propio código que puede depender de algún componente.

En fin, no es una solución DRY, pero funciona para los pocos casos en los que lo necesitamos.

Otra de las soluciones de las que nos hemos ayudado, como muchos seguro que imaginaréis , es implementar una función $(), que aunque no nos dé las bondades de las extensiones DOM de prototype, nos ha ayudado a tener que cambiar mucho menos código:

function $(id){ return YAHOO.util.Dom.get(id)}

A modo de ejemplo, y basándome en el post Descargando la música de GoEar.com en debugmodeon, se me ocurrió escribir un pequeño script que hiciera prácticamente lo mismo(Extractor.groovy):

Update: Parece que el código se verá mejor en gist

import groovy.util.XmlParser
args.each{ id ->
def songs = new XmlParser().parse("http://www.goear.com/files/xmlfiles/${id[0]}/secm${id}.xml")
def song = songs.song[0]
def mp3 = song.'@path'
def name = (song.'@artist'+"_"+song.'@title').replaceAll(" ","_")
def file = new File("/path-a-un-directorio/${id}-${name}.mp3").newOutputStream()
file << new URL(mp3).openStream()
file.close()
println "${name} has been downloaded"
}

Para utilizarlo, simplemente le pasamos los identificadores de las canciones que queramos descargar, por ejemplo:

groovy Extractor.groovy cd332f6 e96ff20 acee672