La idea es sencilla: partiendo de una o varias fuentes de entrada, realizar transformaciones para generar una fuente de salida. Las entradas pueden ser:

• Un CSV.
• Un feed (RSS, Atom, etc).
• Datos en XML, JSON, etc.
• Una página HTML, de la cual nos podemos quedar con una parte solamente.
• Fotos de Flickr, búsquedas en Yahoo!, etc.
• Datos introducidos por el usuario (fechas, lugares, cadenas, números, etc).

Las transformaciones que podemos hacer con las entradas son también muy variadas: contar, sumar, iterar, filtrar, ordenar, … Podemos realizar operaciones  de manipulación de cadenas, fechas, lugares, etc.

También podemos usar otro pipe (nuestro, o cualquiera público) como fuente de datos, o al revés (pasar la salida de nuestro pipe a otro).

La salida podemos obtenerla como RSS, JSON, por email, etc. Y todo esto con una herramienta vía web, muy sencilla, haciendo drag & drop.

En mi caso, dispongo de varios blogs:

• Mi blog personal.
• El blog de Salenda.
• El blog de Escuela de Groovy.

Y buscaba una manera de agruparlos en un sólo feed. Éste es el pipe que he creado:

Los resultados de la ejecución, como decía, pueden obtenerse en formato RSS, JSON, etc. También pueden compartirse vía Delicious, Facebook, Twitter, etc.

En resumen, un gran invento este .

IMPORTANTE: Facebook ha llegado a un acuerdo con anunciantes terceros para que utlicen tus fotos en sus anuncios sin tu permiso. Para bloquearlo: haz clic en “Configuración” y selecciona “Privacidad”. Luego ve a “Noticias y Muro” y selecciona la pestaña “Anuncios de Facebook”. Selecciona “Nadie” en la caja desplegable y guarda los cambios. Ayuda a tus amigos y corta y pega este mensaje en tu estado.

Y lógicamente todo el mundo lo anda repitiendo como loros. Tiene la pinta de un hoax clásico, pero bueno, intentemos arrojar algo de luz. Vayamos por partes:

• Cuando te registraste, ya le diste tu permiso a Facebook para utilizar tu contenido, así que no llores ahora. Extraído de sus términos y condiciones:
  

  Para el contenido protegido por derechos de propiedad intelectual, como fotografías y vídeos (“contenido de PI”), nos concedes específicamente el siguiente permiso, de acuerdo con la configuración de privacidad y aplicaciones: nos concedes una licencia no exclusiva, transferible, con posibilidad de ser sub-otorgada, sin royalties, aplicable globalmente, para utilizar cualquier contenido de PI que publiques en Facebook o en conexión con Facebook (en adelante, “licencia de PI”). Esta licencia de PI finaliza cuando eliminas tu contenido de PI o tu cuenta (excepto en el caso en que tu contenido se ha compartido con terceros y éstos no lo han eliminado).

  [...]

  Por “usar” se entiende utilizar, copiar, reproducir o mostrar públicamente, distribuir, modificar, traducir y crear obras derivadas

• Además, anteriormente las condiciones decían que este permiso era perpetuo, aunque las volvieron a modificar hace poco, volviéndolas a redactar de una forma más amistosa para los usuarios. En cualquier caso, esta licencia les sirve a Facebook y a muchas otras páginas en las que te habrás registrado sin leer las condiciones, para protegerse ante posibles demandas de los usuarios.
• Resulta que han sido aplicaciones de terceros, y no Facebook, quienes han violado esos términos y condiciones, y Facebook ya desmintió este rumor el viernes.

Conclusiones:

1. Léete lo que firmas cuando te registras en una página. Y si no, ajo y agua.
2. ¿De verdad te crees tan importante para que alguien haga un anuncio con tu careto? xDDD

Si tu aplicación necesita ser altamente escalable o simplemente muy rápida, desnormaliza la base de datos y utiliza Siena

Obviando la cuña publicitaria sobre Siena, la verdad es que cualquier lector poco avezado en estos asuntos, especialmente aquellos procedentes de entornos universitarios, podría llevarse las manos a la cabeza. El problema es que muchas algunas veces, el mundo académico más tradicional establece dogmas de tal forma que hace que los estudiantes no se atrevan a cuestionarlos.

Estaría bien que, intentando ir más allá de ejemplo “Libro-Ejemplar”, fuesen capaces de advertir de las enormes penalizaciones desde el punto de vista del rendimiento que supone, entre otros, normalizar una base de datos en aplicaciones con un alto volumen de tráfico.

La conclusión es que… todo depende . Everything is fast for small n, y en determinadas aplicaciones con un n no tan pequeño, habría que planteárselo muy mucho. Jeff Atwood lo explica mucho mejor en su post Maybe Normalizing Isn’t Normal, de muy recomendable lectura.

En una línea parecida, Gimenete volvió a escribir otro artículo, “Técnicas para la optimización de bases de datos” donde, entre otros, habla de la desnormalización. En este caso, yo creo que puede que haya técnicas de optimización que no tengan mucho sentido en ciertas aplicaciones (que no sean aplicaciones masivas de Internet). Una vez más, nos volvemos a dar cuenta de que no todo es blanco o negro, sino que hay grises.

Acabando con el tema de la normalización, dos artículos también recomendables:

• When Not to Normalize your SQL Database.
• Normalization Is for Sissies.

import javax.sql.DataSource
import groovy.sql.Sql

class MyService {

    boolean transactional = false

    DataSource dataSource

    def serviceMethod() {
        sql.eachRow("select * from table") {
            println it
        }
    }
}

Sin embargo, el problema viene al necesitar transacciones. Como no podemos utilizar DomainClass.withTransaction{ ... }, necesitamos manipular los límites de la transacción manualmente.

Por desgracia, Groovy no tiene un withTransaction o algo parecido, aunque mediante metaprogramación lo podemos añadir nosotros mismos. La solución que propongo tiene las siguientes cosas en cuenta:

• Hay que evitar que se cree una nueva conexión con cada llamada al execute(), cacheando la conexión.
• Precisamente en esta última funcionalidad hay un bug que hay que evitar.
• Asumimos que es necesario enviar parámetros distintos a queries distintas.

Vayamos a ello. En primer lugar, necesitamos añadir una closure a la clase groovy.sql.Sql. Podemos hacerlo en cualquier parte de nuestro código (siempre y cuando lo hagamos antes de la transacción), aunque el lugar más apropiado es BootStrap.groovy:

import groovy.sql.Sql

class BootStrap {

    def init = { servletContext ->
        Sql.metaClass.withTransaction = { Closure stmt ->
            cacheConnection(){
                connection.autoCommit = false
                try {
                    stmt().each {
                        execute(it.query, it.params)
                    }
                    connection.commit()
                } catch ( e) {
                    connection.rollback()
                    throw e
                } finally {
                    connection.autoCommit = true
                }
            }
        }
    }

    def destroy = {
    }
}

Después, para invocarlo, desde un servicio por ejemplo:

        def sql = new Sql(dataSource)

        Connection connection = sql.createConnection();
        try{
            def sql2 = new Sql(connection);
            sql2.withTransaction {
		[
		    [query:"nsert into table values (?,?,?)", params:[p1, p2, p3]],
		    [query:"insert into table2 values (?,?,?)", params:[p4, p5, p6]]
                ]
            }
        }finally{
            if(sql.dataSource){
                connection.close();
            }
        }

Esta solución es la descrita en este hilo, con la diferencia de que se le pueden pasar parámetros a la query.

Hay un JIRA abierto pidiendo esta funcionalidad que, de hecho, supuestamente ya está presente en el código de Groovy, pero está pendiente de ser testeada. Lo que yo sí que os puedo confirmar es que esta solución sí funciona perfectamente

Al principio todo perfecto. Hasta que me ha dado por poner una tilde en una GSP: “Iniciar sesión”. ¡Insensato! Quién me mandaría a mí osar a hacer algo así.

Alguien podría argumentar que podría haber puesto la entidad HTML correspondiente (“Iniciar sesión”). Realmente es lo suyo en las vistas. Pero aún así, eso es pan para hoy y hambre para mañana. Salvas esa situación particular. Pero cuando te vengan datos de la BBDD con tildes, tampoco se te van a mostrar. Si no consigues ver una tilde en una vista, no la verás tampoco si viene de otro lado.

La solución a esto es muy sencilla (la aprendí con sangre hace tiempo): todo en UTF-8.

Primero he sospechado de Netbeans 6.7 M2, que es lo que uso ahora para desarrollar en Grails. Por desgracia, en Netbeans no hay manera de definir/cambiar la codificación de caracteres en un proyecto Grails. Indecente que esto no se pueda hacer. Pero bueno, afortunadamente hay alternativas.

Entonces he probado con mi otro editor habitual para Grails: E Text Editor (versión para Windows de TextMate; muy recomendable. Me compré una licencia personal hace poco), en el cual sí se puede especificar claramente la codificación de caracteres al guardar el fichero. Guardándolos todos en UTF-8, nada. La tilde se seguía viendo mal.

Probé después con Vim y con JEdit. Y nada. De ahí no salía.

Después de hacer varias pruebas con proyectos de plugin nuevos (grails create-plugin) (para asegurarme que no había nada modificado) y con proyectos de aplicación nuevos (grails create-app), ha resultado ser un puñetero bug en Grails.

Esta tontería me ha costado varias horas, una brecha en la cabeza y un agujero en la pared . Es lo que tiene que los desarrolladores principales de Grails lo hagan todo en inglés, y que además la mayoría de usuarios también.

Buff, qué poco favorecido salgo malas fotos hacía esa cámara. Pero bueno, suficiente para demostrar que “yo estuve allí” :

View on Vimeo.

Me ha costado un poco, pero he sido capaz de migrar algunas de las entradas anteriores con sus comentarios. Más que nada por su valor sentimental, no por lo que puedan aportar. Y también porque empezar un blog sin nada resulta un poco triste .

En Salenda estamos experimentando varios cambios. El primero de ellos es este sistema de blogs, donde no sólo tenemos un blog corporativo, sino que además permite que existan blogs individuales de las personas que trabajamos en Salenda.

En estos días habrá más novedades, que iremos contando a su debido tiempo

Como permiten ponerlas en tu web, ahí va una que he creado de ejemplo:

No es por nada, pero son más bonitas que las de Canyamo, ¿verdad Enrique?

En una de las empresas para las que trabajo están buscando una persona
para hacer labores de preventa. Esto consitiría básicamente en ir a
visitar posibles clientes y hablarles de lo que hacemos, los productos
que tenemos, etc. desde el punto de vista de la tecnología, con
presentaciones y/o demostraciones en vivo. No se trata de comercial,
sino de preventa, que no es lo mismo. O si lo queréis ver así, de
evangelizador.

La persona elegida estaría un tiempo viniendo conmigo a reuniones para
que viese en qué consiste la dinámica y fuese adquiriendo el
conocimiento, para después hacerse cargo él directamente.

La empresa en cuestión permanecerá como incógnita en público . Yo trabajo para ellos
como autónomo y la idea que tienen es que la nueva persona empiece
como autónomo también, aunque no están cerrados a contratar a nadie.

Sobre dinero, no os puedo decir porque no depende de mí, eso lo tendría que negociar cada
candidato, pero la idea es una pequeña remuneración por hora de
presentación + ( % de margen + % de beneficio ) cuando haya ventas.

Lo bueno es que el trabajo difícil (creación del material) ya lo he
hecho yo, y que las comisiones pueden ser interesantes (podemos estar
hablando de ventas desde 10.000? hasta 1 millón). Además, tendréis la
oportunidad de visitar grandes cuentas: CASA/EADS, Bankinter, Inversis
Bank, Endesa, BBVA, ISBAN, Telefónica, Vocento, Carrefour, Banco de
España, RSI, Correos, Euskaltel, …

Lo malo, que en el mercado de la industria del software, los ciclos de
venta van desde 6 meses a 1 año (incluso 2 años a veces), así que no
es “llegar y vender”. A la mayoría de los prospectos hay que
visitarles varias veces. Pero bueno, nadie se hace rico en 2 días,
¿no? .

No se necesita nada en especial para el puesto, más que soltura a la
hora de hablar en público, y algo de conocimiento en alguna de las
líneas de servicio que tiene la empresa:

1. Quality Assurance: productos y servicios de pruebas.
2. Performance Management: gestión del rendimiento y la disponibilidad
   de aplicaciones Java.
3. Hay otras, pero las prioritarias son 1) y 2). Y en general, está
   todo orientado a Java/J2EE.

La entrevista técnica os la haría yo, pero ya os digo que no se
necesita nada en especial (ni títulos ni experiencia profesional ni
nada), ya que al principio estaríais de “observadores”.

Vaya ladrillo que me ha salido . Si os interesa, o conocéis a
alguien que le pueda interesar, o tenéis alguna duda sobre lo que sea,
mandadme un mail a alvaro PUNTO sanchezmariscal ARROBA gmail PUNTO com.