Hacía tiempo mucho que me rondaba por la cabeza escribir algo de la "guerra" de los lenguajes de programación(y frameworks por extensión), un flame típico en blogs, foros, listas de correo, eventos, cafés, cervezas... y Abel Muiño (@amuino) me lo puso ayer en bandeja con esta cita extraída del post The Best Programming Language for a Lean Startup.

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

Vía Ricardo Galli encuentro la inciativa La ciencia en España no necesita tijeras, a la que no puedo más que unirme.

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.

Me parece muy interesante la iniciativa que se presentó el Viernes en Madrid On Rails: Escuela de Groovy, una joint venture entre ImaginaWorks y Salenda, dos de las empresas de referencia en el mundillo Groovy/Grails/Griffon/... hispano.

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

Ya hablé aquí hace un tiempo acerca del libro The Principles Of Successful Freelancing.

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.

Días antes del último despliegue de Jobsket, estuve dándole vueltas a un problemilla con Grails 1.0.5 y los taglibs estándar para usar Ajax, por defecto Grails utiliza la librería javascript prototype para abstraerse de los distintos navegadores. Para que funcionen los taglibs remoteFunction, remoteLink y formRemote debemos utilizar <g:javascript library="prototype" /> para que cargue el .js de la librería, la cuestión es que estamos utilizando algunos componentes de YahooUI(y de GrailsUI) y para aligerar el peso de las peticiones, queríamos quitar todas nuestras dependencias con prototype.

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)}