Arragonán

Ando metido en un proyecto muy chulo llamado UniversalPlaces, TorresBurriel ya publicó un post hablando sobre el lanzamiento inicial y el equipo(equipazo!).

UniversalPlaces es una web donde se pueden reservar estancias en hoteles. A día de hoy todavía en fases iniciales de lo que se pretende que llegue a ser, pero seguro que en los próximos meses dará mucho que hablar

Si indagáis un poco, veréis que el equipo es de todo menos convencional. Y no me refiero a que el equipo esté por encima de la media(que lo está!), si no a que es un equipo “a medida” para el proyecto. Cada miembro del equipo trabajamos independientemente a los demás, y aunque alguna vez hayamos podido/podemos/podamos coincidir, tenemos otros jaleos . Una apuesta diferente a la habitual por parte de Javier Mcallan, para entrar a competir en un sector tan duro como es el del turismo en internet.

Mi rol dentro del equipo ha resultado ser programador y algo así como el responsable(o irresponsable ) de la parte técnica. Nuestro objetivo desde la parte técnica, es que la tecnología existente resulte la menor limitación posible para ofrecer una mejor experiencia de usuario, y os aseguro que está siendo todo un reto!

Bueno, y cómo imagino que no esperaríais otra cosa de mi, os voy a contar un poco acerca de que tecnologías estamos utilizando(por ahora nada excesivamente especial):

• Es una aplicación web hecha con Grails. Es el framework que más domino a día de hoy, y para este proyecto encaja perfectamente. Como se puede suponer, también hay un trabajo muy importante de integración, y la plataforma Java tiene multitud de herramientas para ello.
• Corre sobre un Apache Tomcat 6 en producción.
• Usamos MySQL y MongoDB para las bases de datos. La primera para guardar lo relacionado con reservas, clientes… Y la segunda a día de hoy es poco más que una caché de búsquedas de estancias, para lo que podríamos estar utilizando otras muchas herramientas tipo clave/valor, pero mientras ganamos experiencia para experimentar con algunas características de Mongo que pueden encajar muy bien con funcionalidades que están en el roadmap.
• El servidor es un dedicado bastante resultón, que ahora mismo va bastante sobrado.
• También estamos utilizando Amazon S3 para servir las imágenes y Postmark para mandar por email la confirmación de las reservas. Son servicios que hemos externalizado desde ya.

Y como curiosidad una métrica, a día de hoy, con la funcionalidad que se puede ver, tenemos poco más de 2200 líneas de código groovy y java.

Supongo que algunos ya lo sabréis, este Viernes 11 de marzo a partir de las 16:00 voy a impartir un taller de Grails que ha organizado primerViernes.

El taller durará 4 horas, tiene un coste de 100€ y lo llevaremos a cabo en las instalaciones de Madrid On Rails.

El taller está enfocado a gente que ya conoce el framework y quiere acelerar su aprendizaje. En el taller veremos ejemplos en código y trabajaremos sobre distintos tipos de caché, plugins propios y de terceros, sistemas de colas… vamos, que NO va a ser introductorio.

¿Que aún no conoces primerViernes?

primerViernes es un grupo organizado para el lanzamiento de proyectos en Internet que se basa en la idea de “más hacer y menos hablar”.

Con esa declaración de intenciones, ya supondréis que soy simpatizante de este grupo que se concentra en Madrid, y con el que vemos un espíritu muy similar al que nos ha empujado a mover la iniciativa CachiruloValley en Aragón.

Además, habiendo estado en uno de los primerViernes, tengo la sensación que del grupo saldrán algunas empresas interneteras que van a dar guerra

Me ha vuelto a pasar… otra vez! La configuración por defecto de Apache Tomcat 6 me ha dado problemas con la codificación de carácteres.

Mientras que en el servidor embebido de Grails funciona todo perfectamente con UTF8, siempre que no la líes gracias a a causa tu IDE/editor favorito, claro. Al poner en una instalación de tomcat el war que quería desplegar, los carácteres no-ascii(eñes, tildes, etc) no se pasaban con la codificación correcta cuando los parámetros iban por GET.

La solución es bastante simple.

A la línea del server.xml de la configuración de nuestro/s tomcat/s:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443"/>

Añadirle URIEncoding=”UTF-8″, para que quede algo como esto:
<Connector port="8080" protocol="HTTP/1.1" connectionTimeout="20000" redirectPort="8443" URIEncoding="UTF-8"/>

Y ya

Ya hace casi un par de semanas que se celebró el Spring I/O 2011, y algunos ya han escrito sobre ello.

Iba a hacer un resumen completo del evento, pero visto que otros ya han hecho muy buenos resúmenes y que me he enfriado sólo destacaré lo que me resultó más interesante de las charlas y talleres que pude asistir. Estaba muy difícil elegir entre los 3 tracks, se veía que iba a haber nivel… a ver si este año suben los videos para ver charlas que me perdí de las que me hablaron muy bien.

- Lo que más me gustó:

De cero a multinacional con Grails y EC2, de Jorge Uriarte y Eloy García-Borreguero. Siempre es interesante ver como otra gente soluciona sus problemas y más cuando usan un framework que tú mismo usas, en cierto modo me recordó un poco a nuestra charla de jobsket del año pasado. No por el contenido ni por el producto, si no por ver un caso real y que el caso fuera un negocio en internet.

Conociendo Griffon a fondo, de Andrés Almiray. La verdad que no le había prestado demasiada atención a griffon por que estoy bastante alejado de las aplicaciones de escritorio desde que me pagan por programar . Pero vi que era una buena oportunidad de aprender un poco de la mano de Andrés(entre otras muchas cosas, uno de los fundadores de griffon), ya que posiblemente desarrolle en el futuro un pequeño proyecto de escritorio y quería conocer que me ofrecía el framework. Como mínimo debería hacer un hola mundo

Aplicaciones web ultraescalables con Redis de Alberto Gimeno. No es colegeo(que podría serlo ), ya sabía por donde iban a ir los tiros de su presentación porque fuimos hablando sobre el evento desde días antes, y precisamente fui porque sabía de antemano que iba a resultar interesante. No decepcionó, asistió mucha gente y fue la charla en la que más gente vi preguntar; les descubrió a mucha gente una alternativa a las típicas bases de datos relacionales.

Tuning your Grails applications, de Peter Ledbrook. Que sin descubrir grandes cosas, hizo un interesante repaso a las buenas prácticas que deberíamos utilizar en el desarrollo web para que nuestras webs sean más rápidas(empezando por evitar optimizaciones prematuras ), y algunas formas de hacerlo con Grails.

Esto fue lo que más me gustó, otras cosas que me resultaron muy interesantes fueron las keynotes de Juergen Holler y Graeme Rocher, la charla de pruebas de Aitor Alzola, el taller de Geb con Fátima Casaú…

Por otro lado, el primer día hice de facilitador(que dicen los agilistas ) de un taller de groovy koans. Vamos, que hice una pequeña introducción-presentación de que son los koans, la gente se puso a programar y yo echaba una mano a quien me pidiera ayuda o tuviera alguna duda.

Esta fue la mini presentación que preparé:

Los koans recortados que hicimos en el taller están en github.

Personalmente me gustó mucho el evento, se notó que se aprovechó el rodaje y experiencia de los eventos de México DF y de Madrid y que habían más medios que el año pasado. También un WIN montar fiesta la primera noche para que la gente se relacionara distendidamente tras el duro día

Al final lo mejor, como siempre, es reencontrarte con amiguetes y conocidos; desvirtualizar o conocer gente nueva. Si al final lo bueno siempre está en el cara a cara

Nos vemos en otra

Todo el mundo en algún momento ha necesitado implementar autentificación HTTP en una aplicación o página web(o no ).

Con grails me ha vuelto a tocar hacerlo, por medio de un filtro para que fuera muy fácil de poner o quitar. El código queda como algo así:


class AuthFilters {
 def USERNAME = "user"
 def PASSWORD = "pass"

 static filters = {
  httpAuth(uri:"/**") {
   before = {
   def authHeader = request.getHeader('Authorization')
   if (authHeader) {
    def usernamePassword = new String(authHeader.split(' ')[1].decodeBase64())
    if (usernamePassword == "$USERNAME:$PASSWORD") {
     return true
    }
   }
   response.setHeader('WWW-Authenticate', 'basic realm="myRealm"')
   response.sendError(response.SC_UNAUTHORIZED)
   return false
   }
  }
 }
}


¿Hace falta explicar algo?

Este año se repite el Spring I/O, bajo el nuevo nombre, que es el evento de SpringSource y javaHispano promovido por Sergi Almar. Y este año, a diferencia del anterior, me toca estar sólo ante el peligro con un taller de Groovy Koans.

Groovy Koans es un proyecto para ayudar a introducirse al lenguaje Groovy utilizando tests unitarios, conocí el proyecto un poco de rebote gracias a Amalia, y me pareció interesante proponerlo como taller para ayudar a conocer los fundamentos del lenguaje. Todavía tengo que ver que subconjunto de los koans selecciono para el taller, ya que no veo posible hacerlos todos en un par de horas.

En el taller realmente espero hablar muy poco, prefiero dedicarme a dar apoyo y a resolver las dudas que puedan surgir cuando la gente se ponga manos a la obra.

Sin estar del todo cerrada la agenda, la verdad es que el cartel es impresionante, con ponentes internacionales y nacionales de muchísimo nivel. Si os interesa groovy, grails, spring o el ecosistema java en general yo no dudaría en registrarme

Por cierto, las fechas son 17 y 18 de Febrero, y el lugar la Universidad CEU San Pablo en Boadilla del Monte (Madrid).

Como algunos ya sabréis, una de las cosas que podemos hacer con Groovy es escribir scripts al estilo de Ruby, Perl, Python… para realizar alguna tarea repetitiva. Desde mi humilde punto de vista(y de gente que sabe mucho más que yo), un programador debe tener en su caja de herramientas un lenguaje para escribir scripts que sirva para automatizar tareas.

Hace poco he estado haciendo unos retoques a uno que tenía casi olvidado, cuya responsabilidad era hacer una migración de una base de datos a otra, con esquemas muy distintos(por lo que tocó sudar sangre ). Para esto me ayudé de un par de scripts escritos en groovy que cumplieron perfectamente con su función.

Hablando ya del código, una de las cosas interesantes que tiene groovy en sus últimas versiones es la incorporación de Grape en el lenguaje. Con Grape podemos manejar las dependencias a librerías externas utilizando los mismos repositorios que hay para maven, por ejemplo yo necesitaba el driver jdbc de mysql:

import groovy.grape.Grape
Grape.grab(group:'mysql', module:'mysql-connector-java', version:'5.1.6',classLoader: this.class.classLoader.rootLoader)


Otra cosa que está muy bien es lo que facilita el trabajo con bases de datos, groovy nos da el paquete groovy.sql.* para ello. Un ejemplo con código limpiado para que sea más fácilmente legible:

def sql = Sql.newInstance("jdbc:mysql://localhost:3306/vieja", "root","pass", "com.mysql.jdbc.Driver")

sql.eachRow("select * from contenidos_secciones where seccionId = 2"){
println it.id
println it.titulo
//acciones reales a ejecutar
}

El it dentro de eachRow, efectivamente representa una fila del resultado obtenido de la consulta.

En mis scripts en los eachRow trataba los datos recibidos para finalmente generar los inserts sql para el esquema de la base de datos nueva y los escribía en un fichero. Para tratar ficheros groovy también nos simplifica la vida, en mi caso tenía por ahí una función tal que así:

def writeToAFile(query, fileName){
def file = new File("${fileName}.sql")
file.append(query+"\n","UTF-8")
}


A este código habría que añadirles muchas líneas pero no quiero aburrir con cosas genéricas que no aportan gran cosa, como el porrón de consultas y subconsultas diferentes, cambios de estructuras, tratamientos de cadenas para generar inserts…

En fin, que si no tienes ningún lenguaje para escribir scripts, ya puedes dejar las excusas/pereza y empezar a aprender uno!

Y si eres programador Java, groovy es el que resulta tener una menor barrera de entrada que los lenguajes sospechosos habituales para esas tareas, la mayoría de la sintaxis ya la conoces

Hace un poco que he empezado a trastear Mockito para utilizarlo en un proyectillo que llevo entre manos. Por si hay algún javero despistado, es una librería para ayudarnos a hacer mocks y stubs de las dependencias de código que queramos testear.

Pues hace unos días que encontré unos screencasts sobre Mockito que me resultaron muy aclaratorios de como puedo aprovechar la librería. Como me resultaron útiles, simplemente los comparto :

Ayer, unas horas después de leer el post de @kinisoftware, Modelos de dominio anémicos, POJOs y demás seres del lugar, me encontré una discusión en twitter a varias bandas(sitio que no es ni mucho menos el mejor para debates así… sigo echando de menos las conversaciones/discusiones que teníamos entre una micro-comunidad en jaiku, pero ese es otro tema) sobre el anti-patrón del modelo anémico.

Hablando del tema vi tuits de @kinisoftware, @albertovilches, @jmbeas, @genezeta, @jneira, @jlhuertas… y fijo que me pierdo a algunos más de gente que no sigo. Como es habitual, yo no me mojé demasiado . Por un lado soy un chaquetero, y por otro esta gente sabe mucho y me pueden dejar a la altura del betún en cualquier momento

Por resumir un poco esto del modelo anémico, viene a ser que el modelo está implementado con DTOs, cuya única responsabilidad es encapsular datos para transferirlos a otra parte(ej: de una base de datos a la vista de una app). Cosa que creo aún es bastante habitual en muchas aplicaciones que utilizan ORMs o similares(llámense Hibernate, ActiveRecord, GORM, Doctrine, MyBatis… o soluciones home-made)… Pues resulta que eso es un anti-patrón, más que nada porque por hacer eso probablemente estemos rompiendo el paradigma de programación orientada a objetos.

Recuerdo cuando me enseñaban POO(con Java) que una clase Rectangulo tenía un atributo base y otro altura con sus getters y setters y un método calculaArea() que devolvía su área(vale, y probablemente extendería de Poligono ). Vamos, que se supone que un objeto combina estado y comportamiento, por eso veo por ejemplo hablando una clase de dominio Noticia que tiene un atributo propietario puede tener un método del estilo:

public boolean esPropiedadDe(Usuario usuario){
   return propietario.equals(usuario)
}

La cosa es que en los frameworks MVC ese tipo de lógica la he visto(y sí, también la he puesto! XD) en la capa del controlador, cuando se supone que es una capa que debe ser lo más tonta posible en cuanto a lógica de negocio (o ya puestos, tonta del todo , skinny controller-fat model), y con la moda de las capas de servicio con los Spring & co(Grails como una de esas víctimas colaterales) ha resultado que esa lógica se pone en la capa de servicio para evitar ponerla en el controlador y seguir dejando a las clases de dominio como DTOs(o modelos anémicos).

¿Eso quiere decir que siempre pongo la lógica en las clases de dominio?
No, pero procuro hacerlo siempre que puedo identificar responsabilidades en una clase del dominio. Aún así, en ocasiones me encuentro con lógica que pasa a alguna clase en la capa de servicio, principalmente porque no consigo identificar qué clase debería ser la responsable, afecte a varias clases de dominio o simplemente sean comportamientos que no tienen que ver con la lógica de negocio pura y dura. Por supuesto teniendo en cuenta que esas decisiones sean cosa mía

De todas formas, ya se sabe que en esto del desarrollo de software todo depende de muchos factores(principalmente de los gustos y costumbres de los desarrolladores) y nadie tiene LA respuesta. Eso es lo que hace más interesante el mundillo, ¿o no?

Viñeta de Geek And Poke, como no

PD: Disculpad que os tengáis que imaginar parte del código y el spanglish rarillo en los ejemplos, el código de verdad hace tiempo que procuro escribirlo siempre en inglés

En estos momentos me encuentro enfrentándome a un problema en el que tengo que persistir una cantidad de datos realmente grande, con diferentes fuentes de esos datos, en cada fuente los datos pueden ser “de su padre y de su madre”, el sistema debe escalar lo más fácilmente posible y se deben poder hacer búsquedas por diferentes criterios.

Una vez puestos en contexto a grandes rasgos, os diré que vi que posiblemente la mejor opción para resolver el problema era utilizar una base de datos orientada a documento, un tipo de base de datos de las llamadas NoSQL.

Tras andar estudiando CouchDB y MongoDB, me decanté por la segunda. ¿Por qué?: La principal razón porque MongoDB, además de MapReduce, permite lanzar consultas dinámicas al estilo relacional. En la misma web de MongoDB hay una comparativa muy interesante de diferencias y similitudes con CouchDB.

En fin, que he ido recopilando algunas lecturas que me han resultado interesantes para romper el hielo(eso sí, principalmente para trabajar con Java):

• Tutorial: MongoDB in Java
• Learning Mongodb y Still learning MongoDB
• Java Tutorial – MongoDB (del driver oficial)
• MongoDB: A NoSQL datastore with (all the right) RDBMS moves
• MongoDB made more Groovy

Tengo que decir también que hay un par de plugins para Grails, pero por ahora he pasado de ellos. No he visto que aporten mucho más que un mapeo objeto-documento para las clases de dominio, y eso haría que perdiese esa flexibilidad que necesito.

En fin, trataré ir contando algo de como van mis progresos