¿Es oro todo lo que reluce en S2AP (Spring 2 Application Platform)?

Llevaba unos días queriendo escribir esta entrada, pero la cantidad de trabajo que tengo pendiente últimamente me ha hecho retrasarla hasta el Domingo. Todo comienza con un post en InfoQ donde redactan un resumen (me encantan sus resúmenes) de las diferentes reacciones en la blogosfera al anuncio de Spring Application Platform.

El caso es dicha noticia en InfoQ generó, como era de esperar, algunos comentarios bastante críticos sobre la plataforma, a los que los líderes detrás de Spring, incluido Rod Johnson, no tardaron en responder, y en esta ocasión de forma bastante dura. Todo ello además originó un artículo de Adrian Colyer en el blog de Spring, donde explica lo que a su entender son las razones por las que nos deberíamos preocupar por OSGi.

El problema a mi entender de este artículo en concreto es que no nos explica cuáles son los problemas de OSGi. Como decimos aquí, bueno, fair enough, pero todos sabemos que cualquier tecnología tiene sus problemillas, y no explicarlos no deja de hacer que el artículo se convierta en un mero ejercicio de auto-marketing. Pero claro, el problema es que comentar las dos grandes desventajas de OSGi en el contexto de Spring sería un poco duro desde el punto de vista del artículo:

1. OSGi, en este contexto de desplegar aplicaciones empresariales, no está regido por ningún estándar ni soportado por otras empresas (por ahora) a parte de SpringSource.


2. OSGi, no es algo sencillo. En particular es bastante más complejo que el actual modelo de despliegue de aplicaciones webs en JEE.

Yo empecé a trabajar con Equinox hace ya unos tres años, allá con Eclipse 3.0. No voy a decir que soy un experto, porque no lo soy, pero sí tengo la experiencia de la aplicación de escritorio que viene con jLibrary, que a fin de cuentas es una aplicación 100% OSGi formada por diferentes bundles. Es decir, el servidor es un bundle, el módulo de caché es un bundle, los módulos de internacionalización son bundles, el módulo de extractores de texto es otro bundle, el interfaz gráfico es un bundle, etc.

No os voy a aburrir con esta historia, pero lo que me dice mi experiencia es que trabajar con OSGi no es algo trivial. De hecho, a mi se me antoja que la forma más sencilla de desplegar aplicaciones en Spring Application Server, sigue y seguirá siendo el tener ficheros WAR. No me malinterpretéis aquí, no estoy diciendo que me guste OSGi, a mi me encanta la propuesta, y una vez que te acostumbras a él, eres enormemente productivo. Y es mucho más, OSGi está claro que es mucho más avanzado, potente, y modular que el actual modelo de despliegue de JEE.

Pero, lamentablemente OSGi no es tan sencillo. Y aquí, como se comentaba en algunos de los comentarios en InfoQ, se encuentra uno ante el dilema de ¿es mejor elegir un modelo que satisfaga al 10% de los power-users o un modelo que el resto del 90% de usuarios puedan utilizar?

Otra cosa que no deja de ser curiosa es que desde SpringSource traten de vendernos algunos conceptos como novedosos cuando realmente esos grandes avances ya se llevan viendo con los servidores de aplicaciones propietarios desde hace años. Por ejemplo, comenta Rod Johnson en el artículo mencionado arriba:

I totally agree. The fact that users are essentially deploying half their server to the server in every EAR or WAR file

Bienvenido al mundo de las extensiones propietarias Mr. Johnson. Cualquier servidor de aplicaciones, digamos WebLogic, WebSphere, JBoss o el mismo Tomcat ofrecen formas para compartir librerías. Sí, no son tan sofisticadas como los bundles de OSGi, pero en Tomcat puedes simplemente dejarlas en el shared/lib, o en WebLogic puedes crear una librería compartida y referenciarla después desde tus EARs o WARs o lo que sea. Sí, por supuesto, no es estándar, pero tampoco lo es SpringSource.

Lo mismo lo podríamos decir para la gestión de versiones en ficheros EAR, que se puede hacer por ejemplo en WebLogic 9.x y supongo que quizás en otros, y que desde luego no es tan sofisticada como la que ofrece OSGi, pero al menos se situa en el contexto de JEE que siempre es una ventaja. Nuevamente, el utilizar estas funcionalidades es responsabilidad del equipo técnico del proyecto, pero no creo que sea justo el intentar sugerir que hasta ahora eso no se podía hacer en JEE, porque siempre se ha podido hacer, y exactamente de la misma forma que propone Spring: apartándose del estándar.

En fin, que mi opinión es que por mucho que se intente maquillar, para mi está claro que S2AP es simplemente la consecuencia de la inversión de capital de riesgo, como ya he comentado en el pasado. No sería tan radical para afirmar que el emperador está desnudo, porque realmente creo que la propuesta de SpringSource tiene un valor importante, pero sí que creo que es mejor quitarse las ropas de vendedor y decir claramente que todas las tecnologías tienen sus riesgos y sus problemas, y que no siempre es oro todo lo que reluce.

insideApps: el hermano pobre de Wily Introscope

Visitando TheServerSide he visto anunciado el lanzamiento de una herramienta que a simple vista podría pasar desapercibida, pero que cuando nos ponemos a leer un poco más sobre ella parece realmente interesante.

Se trata de insideApps de la empresa determyne, que como anuncian en TheServerSide, lo han lanzado como Open Source con licencia LGPL (aunque también tienen una versión comercial).

Con el paso de los años me he dado cuenta que una de las ventajas más importantes de Java sobre otras plataformas, y que normalmente escapa a toda comparativa, es su capacidad de monitorización. Que una plataforma te proporcione ayudas para los desarrollos y que convierta el desarrollo de aplicaciones en una cosa de niños es importante, pero casi es más importante el que la plataforma ofrezca visibilidad y transparencia sobre todo lo que está pasando detrás de los bastidores, y ahí es donde Java con APIs como Attach permiten que cualquiera cree un agente que se enlaza con la máquina virtual y que te permite hacer cosas cmo las que hace insideApps, es decir recoger información, enviarla a un nodo centralizado que la agrupa y consultar más tarde dicha información a através de una consola web.



No he probado insideApp seriamente, simplemente he lanzado su demo, y la verdad es que parece realmente interesante. El año pasado os hablaba sobre Wily Introscope, que es una herramienta potentísima, pero que requiere también una buena cantidad de información, ya que nosotros tenemos que decirle específicamente a Wily lo que queremos que monitorice. Por el contrario, el planteamiento de insideApp es diferente, ya que prometen que simplemente es conectar esta herramienta e insideApp se encarga de detectar la topología de tu aplicación y de mostrar como se van comportando las diferentes transacciones, sin tener que configurar nada.



Jugando con la demo te das cuenta de que la aplicación no es tan espectacular como Introscope, y no te da tanta información, pero bueno al ser Open Source no cuesta nada descargársela y darle una oportunidad a ver que es capaz de mostrarnos sobre nuestras aplicaciones.

Si alguien la prueba, me encantaría leer vuestros comentarios (y si no también).

Guías de salarios en Irlanda

Hace unos días surgió una charla entre los amigos que estamos en jaiku sobre los salarios en Irlanda. Este además es un tema común en otros foros y por el que me llega algún correo, eso sí muy de vez en cuando.

El caso es que si hay gente por ahí que lea esto y esté pensando el pasar una temporada por esta isla, lo más sencillo para coger una idea sobre los salarios que se paga por aquí es echarle un vistazo a una de las múltiples guías que publican periódicamente las empresas de contratación y los portales de empleo. Os dejo unos enlaces:

IT Salary Guide 2008
Manpower Salary Guide 2007
Premier Salary Guide 2008
IrishJobs Salary Survey 2008
Montones de Salary Surveys no IT

Como veréis, el rango de salarios es muy amplio, y realmente depende de lo que quieras hacer y de la experiencia que tengas. Por ahora, no se está notando demasiado la crisis, aunque sí que es cierto que las empresas multinacionales han tardado más de lo normal en empezar la contratación de personal, ya sabéis, por eso de ver como iban las cosas por el otro lado del charco.

Si os queréis fiar de alguna, probablemente yo lo haría de la de Irishjobs. En las de los recruiters he detectado unos salarios un poco más bajos, quizás porque a fin de cuentas no pueden reflejar su márgen que suele ser un 15%-25%.

Pues nada, espero que os sea útil.

Un par de presentaciones sobre seguridad

Hace unos días OWASP y del evento que habían hecho en Dublín.

Pues bien, uno de mis actuales compañeros de trabajo, David Rook, que casualmente era una de las personas que exponía en dichas presentaciones ha sido lo suficientemente avispado como para localizar mi blog. Por supuesto, le llamo la atención que su nombre apareciese en una de las entradas, y presto se apresuró a traducirlo.

Después de comprobar que no decía nada malo de él, algo que es importante jejeje, ha sido tan amable de dejarme voluntariamente las transparencias de las charlas para que las subiera aquí por si a alguien le interesa. He creado un grupo en google para subir los ficheros. Aquí os los dejo:

Cross Site Request Forgery Javascript Malware de Eoin Keary.
I'm a developer get me out of here – Application Security and PCI DSS por David Rook.

Edit: Si no os funcionan los enlaces, simplemente entrad en el grupo y los podréis descargar.

Gracias a David por los ficheros.

Repasando los cambios en Servlets 3.0

Recuerdo hace años que me solía leer muchas de las especificaciones del JCP conforme iban apareciendo. Vaya, esto me hace sentirme como un verdadero bicho raro. Pero es que me resultaba bastante interesante ver como evolucionaba la especificación de EJBs, leer sobre JDO, aprender sobre JCR e intentar hacer una implementación o pegar un giro radical y leer sobre J2ME o CLDC. Con el paso de los años me he ido desenganchando :-) No sé si es la edad, o si más bien es que hay tantas especificaciones ahora mismo que te da pereza siquiera echarles un vistazo.

Aún así, hoy he vuelto a esa vieja adicción y me he leído muy por encima el early draft de la especificación de Servlets 3.0. La lectura ha sido muy fácil porque tienen resaltados los cambios que han hecho respecto a la anterior versión 2.5, así que se deja leer. Creo que puede ser interesante que los resuma por aquí, por si alguien se la quiere ahorrar:

• Anotaciones: Probablemente el cambio más grande es que ahora ya no será necesario editar los descriptores (web.xml) para crear las aplicaciones web. La nueva spec. define en su sección 8 una serie de anotaciones que se pueden utilizar para describir elementos comunes como Servlets, filtros, mapeos de URLs, parámetros de inicialización y el context listener de cada Servlet.
  
  Las nuevas anotaciones son @Servlet, @ServletFilter, @FilterMapping, @InitParam y @ServletContextListener. A mayores, la especificación hereda anotaciones definidas en la especificación JAX-RS (The Java API for RESTful Web Services), más concretamente @HttpMethod, @GET, @PUT, @POST, @DELETE, @HEAD. El siguiente sería un ejemplo:
  
  

  
  @Servlet(urlMappings={"/foo", "/bar"})
  public class SampleUsingAnnotationAttributes {
      @GET
      public void handleGet(HttpServletRequest req, 
                            HttpServletResponse res) {
      }
  }
  

  
  
  Probablemente lo que no me acabe de convencer es que la especificación deja abierta la posibilidad de mezclar las dos aproximaciones, es decir el utilizar anotaciones y el descriptor web al mismo tiempo, lo que ofrece la posibilidad de crear una especie de configuración spaghetti.
  


• Fragmentos web: El segundo cambio importante son los fragmentos web. Todos los que hemos hecho aplicaciones web relativamente grandes sabemos la tendencia a crecer y crecer del fichero web.xml, lo que hace que a veces sea complicado el mantenerlo ya que no sabes donde está cada cosa, o es sencillo cometer el error de duplicar información, etc.
  
  Los fragmentos web permiten crear ficheros web.xml individuales que se distribuyen dentro de un fichero JAR que contendría lo que podríamos llamar una mini-aplicación web. El fichero web.xml debe colocarse dentro del META-INF y el JAR dentro del /lib. El contenedor de Servlets al arrancar la aplicación se encargará de buscar todos los fragmentos web que pueda encontrar e irá añadiendo las entradas de los diferentes web.xml individuales a la configuración de la aplicación. El siguiente es un ejemplo:
  
  

  
  <web-fragment>
      <servlet>
          <servlet-name>welcome</servlet-name>
          <servlet-class>WelcomeServlet</servlet-class>
      </servlet>
      <listener>
          <listener-class>RequestListener</listener-class>
      </listener>
  </web-fragment>
  

  
  
  Un ejemplo sería cuando quieres distribuir una consola de administración para tu aplicación web. En lugar de poner todo con la aplicación web principal, pues se podría empaquetar la consola de administración como si fuera una aplicación web independiente y distribuirla con la aplicación principal a modo de fragmento web.
  
  En mi opinión esta nueva funcionalidad es una buena idea que contribuye a mejorar la modularidad de las aplicaciones web. Queda abierto sin embargo el problema del punto uno de poder mezclar anotaciones con XML.
  


• Procesado asíncrono. El tercer cambio importante en Servlets 3.0 es la introducción de métodos para realizar procesado asíncrono. Esto es de vital importancia para el soporte de comet de manera nativa en los contenedores web. Hasta ahora el procesado de una request es completamente síncrono. Si la request necesita bloquearse por algún recurso, el thread que está manejando esa request se bloqueará. Asimismo, si queremos mantener la request viva durante un largo espacio de tiempo haciendo streaming al cliente, la request permanecerá bloqueada. Esto hace que los contenedores web no puedan escalar apropiadamente ya que el uso de recursos no es óptimo.
  
  La solución propuesta en Servlets 3.0 es añadir tres nuevos métodos, suspend, resume y complete, muy al estilo de las Continuations en Jetty, y que permitirán suspender una request, reanudarla posteriormente por ejemplo desde otro thread diferente, y completarla. Es importante la nota que hacen en la especificación de que tanto el objeto request como el objeto response no son thread-safe por lo que habrá que tener mucho cuidado al controlarlos.



• Otros. El resto de cambios, ya no tan grandes, son el añadido de nuevos métodos a la interfaz ServletContext de modo que se puedan añadir servlets y filtros programáticamente en tiempo de inicialización; el soporte de cookies HttpOnly que no están expuestas a scripting en lado del cliente, y el añadido de métodos en la request para obtener el ServletContext y la el objeto response.

En mi opinión se trata de buenos añadidos a la especificación que la mejoran bastante. Habrá que ver el tema de las anotaciones es un poco problemático como he comentado desde el punto de vista que puedes tener gente en tu equipo haciendo anotaciones y otra gente haciendo descriptores, pero bueno, al final es algo que una empresa debe controlar de todos modos con mejores prácticas, procesos, y todo esto.

Edit: Me acabo de pasar por javaHispano y mira que casualidad que hablan de lo mismo.

Cinco preguntas para tu próxima entrevista de trabajo si te gusta el software

Durante las últimas semanas le he estado dando la vuelta a un tema relacionado con la búsqueda de empleo. Normalmente cuando a uno le preguntan en una entrevista de trabajo si desea saber algo sobre la compañía, se suele caer en las típicas preguntas sobre horario de trabajo, vacaciones, pensiones, comidas, bonuses, etc.

Pero, a parte de esto, cuando uno se dedica al mundo del software ya sea como programador, arquitecto, jefe de proyecto o manager, lo que le gusta es caer en un sitio donde se pueda aprender cosas nuevas, evolucionar técnicamente, trabajar con las últimas tecnologías, estar expuesto a sistemas interesantes o integrarse dentro de ciclos de desarrollo racionales con metodologías de programación modernas. Atendiendo a esto, probablemente merezca la pena dedicar estos últimos minutos de la entrevista a realizar otro tipo de preguntas que den una pista de si tu futuro entorno laboral va a ser enriquecedor o no, desde punto de vista técnico.

Pero, ay, y ahí está el problema, el entrevistador probablemente intentará maquillar cualquier punto negro de la empresa, ya sea para cazarnos o para no exponer sus vergüenza. Por ejemplo, si vamos a una entrevista y preguntamos "- ¿Utilizáis metodologías ágiles?", no sería raro recibir una contestación como "- Por supuesto, por supuesto, nuestros equipos practican XP", y dos semanas después encontrarse con cien folios de requisitos que tienen que firmar diez personas de diez departamentos diferentes para poder pasar al diseño de la aplicación.

El conjunto de preguntas deberían ser lo suficientemente claras y directas para no dar lugar a error sin llegar a ser ofensivas o sin llegar a poner en peligro nuestra candidudatura. Es decir, preguntarle al entrevistador que nos diga lo que es un assemblyen .NET puede resultar un poco incómodo para ambos :-)

A mi se me ocurren una serie de preguntas que nos pueden dar pistas de como funciona la empresa sin que el entrevistador se sienta realmente entrevistado. Estas preguntas son evidentemente técnicas. Si el entrevistador no sabe responderlas, titubea, se muestra dubitativo o esquivo, yo desconfiaría directamente de la empresa, especialmente si ese va a ser nuestro. Me voy a centrar en Java porque si pongo otro lenguaje de ejemplo al final soltaré alguna tontería. Aún así, las preguntas y sus explicaciones son lo suficientemente generales para ser aplicables directamente a cualquier otro lenguaje/plataforma. Ahí van:

• ¿Qué framework de desarrollo utilizáis?:
  
  Atención, porque esta pregunta es la más importante. Si por cualquier razón la respuesta es "tenemos un framework propio", mal pinta la cosa. De hecho, hasta me atrevería a ser radical y decir que es hora de huir de ahí como del demonio. A 2008, el mundo del software no necesita otro framework casero realizado por mentes privilegiadas "porque Spring o JSF no se ajustan a los requisitos de la empresa".
  
  El tener un framework propio es indicador, en el 99% de los casos, de estar reinventando la rueda. De aceptar esto, tocará trabajar con tecnologías probablemente obsoletas, tocará corregir bugs que no estarían ahí de utilizar algo probado, o tocará "mejorar" el framework con cosas que ya están implementadas en otras librerías. Un framework propio, puede ser resultado de una mala elección, o quizás de una elección forzada debido a que el producto se creó hace muchos años.
  
  La respuesta ideal dependerá de lo que quiere hacer el desarrollador o del lenguaje, pero a cualquiera que se mantenga un poco al día le será fácil detectar nombres clave. En Java, Spring, Hibernate, JSF, WebWork, Seam, o incluso EJBs serían respuestas válidas. Struts, mmmmm, ok, todavía hay mucho Struts por ahí y siempre será mejor que un framework web propio. En serio, cualquier cosa que no implique corregir los errores del creador de un framework casero, será más que suficiente.
• ¿Qué metodología de desarrollo utilizáis?:
  
  La pregunta, así de seca. Sin dar pistas. Así, si el entrevistador nos quiere engañar no podrá predecir nuestros gustos (salvo por nuestro CV). Si la respuesta no es clara, o es "bueno, nosotros tenemos nuestra metodología propia", etc. entonces ojo, peligro de caos, intentemos sacar algo más de información.
  
  Si la respuesta es cualquier cosa que implique desarrollo en cascada (e.g. métrica o similares), un punto por ser honesto. No tiene porque ser algo tan terrible si el resto de preguntas están a nuestro gusto, o si el ciclo de vida de los proyectos sigue un flujo racional. Es mejor que conteste eso que el que detectemos que nos intenta engañar.
  
  Si la respuesta es XP, yo estaría con la mosca detrás de la oreja, al fin y al cabo se lee más de esta metodología de lo que se usa en realidad. Si la respuesta es Scrum, o cualquier otra metodología o derivación que implique desarrollo ágil (e.g. RUP bien aplicado), seguramente estemos ante un buen lugar.
• ¿Qué sistema de build utilizáis?:
  
  Si la respuesta es ninguno, o qué es eso, pues muy mal empezamos. En Java, si la respuesta es ant, desconfianza total (lo siento por los que todavía utilizen ant, pero los sistemas de build ya han avanzado bastante en los últimos años) ya que podría significar que el trabajo será realizar mantenimientos viejos, o que la empresa no se preocupa en mejorar sus herramientas. Respuestas como maven, ivy, etc. indican que se han preocupado de mejorar estas cosas. Si la respuesta incluye integración continua, de manera espontánea, será un excelente indicador.
  
• ¿Qué entorno de desarrollo utilizáis?:
  
  Esta es la típica pregunta que, siendo bastante inocente, nos puede dar bastante información sobre como es la empresa ha evoolucionado desde el punto de vista del software. En una plataforma como Java, ha habido y hay montones de entornos de desarrollo, cada uno con una historia particular que nos puede dar pistas sobre la gente que lo utiliza.
  
  Intellij IDEA por ejemplo siempre ha sido un entorno de desarrollo que siempre ha tenido buena fama. Punto positivo si lo usan. Si la empresa utiliza NetBeans y Eclipse, se situará en el baremo de lo habitual, así que no nos indicará nada bueno o malo. Si utiliza alguna especialización de Eclipse (e.g. MyEclipse), puede ser un buen dato ya que Eclipse se deja muchas cosas en el tintero, y eso denotaría que lo saben y que han buscado una solución. Otros entornos que han ido quedando más en desuso si que nos pueden dar una pequeña alarma sobre la compañía.
  
  ¿Utiliza Visual Age, o Visual Café? Entonces es hora de huir. Estos son entornos desaparecidos hace siglos. ¿BlueJ, JCreator, ...? Hay algo raro. Son entornos que muy poca gente utiliza. ¿JBuilder, JDeveloper? Cuidado. Son entornos que han caido bastante en desuso y que la gente suele utilizar por el valor añadido de sus componentes, es decir, que quizás estén utilizando todo este "valor añadido" que es mejor evitar.
  
  ¿BEA WorkShop, WebSphere Studio, ...? Cuidado. Esto puede indicar tanto que la empresa aprovecha realmente todas las funcionalidades que ofrecen lo que sería muy bueno, como que la empresa no tiene ni idea de lo que hace y espera que las aplicaciones funcionarán mejor por el mero hecho de utlizar el IDE que viene con el servidor de aplicaciones.
• ¿Cómo se prueban las aplicaciones?:
  
  Esta es una pregunta un tanto complicada porque resulta muy amplia así que habrá que estar atento a las respuestas. Si la respuesta incluye un departamento de calidad, con bastantes personas, eso será un buen indicador. Si no lo incluye, no tiene porque ser algo terriblemente malo, aunque dependerá de lo que nos diga a mayores.
  
  Si el entrevistador nos menciona explicitamente unit tests, tests de integración, tests de stress, será un buen detalle. Si nos menciona soak testing (dejar una aplicación ejecutandose durante semanas), será un muy buen indicador. Si a mayores detectamos la presencia de algún sistema de automatización de tests, ya sea Mercury, Selenium, DBUnit, etc. será un punto realmente muy positivo. Y ya si nos comenta que los tests se ejecutan dentro del sistema de integración continua que nos mencionó antes, entonces... ¿pagan bien? :)
  
  Si la respuesta no incluye nada de lo anterior, mucho cuidado. Puede ser una buena empresa con simplemente una falta de control de calidad, pero también una empresa caótica donde no queremos trabajar. ¿Ha respondido bien al resto de preguntas? Si la respuesta es "tenemos nuestro propio sistema de testing" (ver el primer punto), entonces habrá que plantearse seriamente el trabajar en esa empresa.

Vaya, he repasado el post y me ha quedado realmente largo. Espero que al menos alguien lo encuentre interesante. A mi, personalmente, me interesan más aún vuestras preguntas, así que lanzo esto al aire a ver si alguien lo recoge: ¿Qué preguntaríais vosotros para evaluar a una empresa en una entrevista de trabajo relacionada con el mundo del software?

Imagen via melissa22@flickr.

Spring Application Server!

Tenía que pasar. Recuerdo hace unos meses comentando con mi jefe que Spring había recibido capital de riesgo y que eso tenía que significar algo. Nadie pondría 10 millones de dólares en un proyecto basado únicamente en la formación. "- Lo más probable es que aprovechen el tirón de Spring y la inyección de dinero para crear su propio servidor de aplicaciones", comentaba. Aunque la opinión de mis compañeros era contraria, ya que eso sería ir en contra del "J2EE development without EJB" que tanto tiempo ha promovido Rod Johnson.

Y es que para una vez que me sale una predicción tengo que ponerlo por aquí!! Que esto (lo de la predicción) es para celebrarlo!! Aunque mis compañeros también tenían razón ya que el servidor se aparta bastante de lo que actualmente es JEE.

Bueno, el caso es que se puede leer ya en muchas publicaciones, y es que Spring ha lanzado la Spring Application Platform, que según Rod Johnson "is the "first proper Java application server product to appear for the enterprise in ten years" y de la que se puede ya obtener una beta.

La plataforma se construye sobre OSGi (otro enorme impulso también para esta tecnología) y Tomcat, y aunque se pueden desplegar WARs, no se pueden desplegar EARs y no soporta otras especificaciones de JEE como los EJBs. Interesante también lo que comentan en InfoQ sobre la definición de un nuevo formato de despliegue en esta plataforma (PAR) que facilite el trabajo con OSGi.

Quizás nos encontremos ante un punto de inflexión en el mundo de Java y los servidores de aplicaciones. Habrá que ver como evoluciona esta plataforma que además nos dará una idea del calado real de Spring en las empresas, ya que aunque en SpringSource comentan que es enorme y así lo muestran en sus estadísticas, la realidad es que mucha gente utiliza Spring para tareas simples. Queda también en abierto como puede afectar esto a las empresas que basan su stack tecnológico en una única plataforma como BEA, IBM, JBoss, etc. + Spring. ¿Se moverán estas empresas a Spring? ¿Se quedarán con lo que tienen y empezarán a temer el coger cosas de Spring?

El tiempo nos lo dirá. Yo por si acaso voy a dejar de predecir cosas que creo que con una acertada ya es suficiente :)

Opinión sobre Spring Batch

Tenía pendiente desde hace unos días escribir algo sobre uno de los componentes de Spring más desconocidos: Spring Batch. Desde luego, Spring Batch ni suena, ni es uno de los componentes más sexies o excitantes con los que uno se vaya a encontrar en su vida laboral, a fin de cuentas los batches son una de esas cosas que cuando te la nombran ya se te ponen los pelos como escarpias; pero el caso es que es uno de esos frameworks oscuros que hacen su labor.

Hace unas semanas, tuve la oportunidad de jugar, no dejó de ser un juego, con esta librería durante unos días, y la verdad es que tengo que reconocer que quedé mucho más satisfecho de lo que me experaba. Me explico. Cuando uno se enfrenta a la página principal y de features del framework, uno se queda con el sabor de boca de que está delante de algo en los que sus creadores se han pasado de rosca. "Overengineered para lo que quiero hacer", es lo primero que pensé yo.

Aún así, conforme vas adentrándote en su documentación, y vas comprendiendo sus conceptos, y sobre todo conforme vas implementando algo de código, te das cuenta de su modularidad. En especial en un mundo, el de los batches, donde literalmente "vale todo", y los programas tienden a ser los más monolíticos, sucios, incomprensibles y difíciles de mantener por lo general que uno se pueda encontrar. Que conste que esto que pongo se basa única y exclusívamente en mi experiencia laboral (que no es realmente muy amplia), pero es que siempre que me ha tocado lidiar con algún proceso batch, siempre ha sido la parte que a todos nos daba miedo tocar. Tanto da que sea un proceso que realiza un cálculo de gestión de costes cada mes, o un proceso que cierra cuentas de traders y envía informes a medianoche en Java, o un proceso que extrae noticias de fuentes cada cinco minutos y las va procesando. Siempre es lo mismo. No sé que pasa que con este tipo de procesos periódicos, la cosa siempre se lía.

Por eso uno, después de desarrollar un pequeño batch con Spring Batch se da cuenta de que mmmm, quizás el diseño no sea excesivo, es más, por fin creo que tengo delante de mi un batch realmente mantenible.

Si estáis pensando que Spring Batch es una librería cuyo uso sólo se aplica a aplicaciones bancarias que procesen enormes cantidades de registros a medianoche, estáis equivocados. Esta es una herramienta realemente aplicable a un amplio número de procesos ya que se basa en unas abstracciones muy generales. En mi opinión, Spring Batch no es realmente un framework si no un esqueleto de aplicación de procesado de datos. Y como tal, se puede aplicar a muchos entornos y problemas.

Describiéndolo muy rápidamente, Spring Batch define lo que son Trabajos que a su vez están definidos en tareas:

  <bean id="footballJob"
        class="org.springframework.batch.core.job.SimpleJob">
    <property name="steps">
      <list>
        <!-- Step Bean details ommitted for clarity -->
        <bean id="playerload" parent="simpleStep" />
        <bean id="gameLoad" parent="simpleStep" />
        <bean id="playerSummarization" parent="simpleStep" />
      </list>
    </property>
    <property name="restartable" value="true" />
  </bean>

Spring Batch se encargará de ejecutar estos trabajos y tareas y de repetirlos si se ha producido un error y cosas así, pero también de lo que quizás sea más importante: de guardar contabilidad de todo lo que ha pasado con estos trabajos y tareas en base de datos.

JOB_EXECUTION_ID	JOB_INSTANCE_ID	START_TIME	END_TIME	STATUS
1	1	2008-01-01 21:00:23.571	2008-01-01 21:30:17.132	FAILED

Así, por ejemplo si nuestro proceso batch fuera un demonio que lee noticias RSS de diferentes sitios web (por poner algo diferente a bancos y todo esto) y las almacena en base de datos. Tendríamos un trabajo (o varios) con diferentes tareas que se encargarían de recoger las noticias y almacenarlas. Lo genial de Spring Batch es que podríamos configurar estas tareas como repetibles en caso de error, y que Spring Batch iría rellenando la tabla que veis arriba con los resultados de las diferentes ejecuciones. Sin ningún esfuerzo estamos obteniendo una enorme transparencia y monitorabilidad en nuestra aplicación.



Bueno, para mi esto que he explicado es lo más importante. A mayores Spring Batch ofrece muchas más cosas. Por ejemplo, cada trabajo podrá utilizar diferentes Writers, Readers o Transformers. Spring Batch viene por defecto con diferentes tipos de Readers para leer ficheros planos, XML o datos de base de datos. Estos Readers se configuran con una especie de mapeo entre registros y objetos de modo que algo en principio complicado como:

  ID,lastName,firstName,position,birthYear,debutYear
  "AbduKa00,Abdul-Jabbar,Karim,rb,1974,1996",

será traducido en:

  public class Player implements Serializable {
        
  private String ID; 
  private String lastName; 
  private String firstName; 
  private String position; 
  private int birthYear; 
  private int debutYear;

por obra y gracia de Spring Batch. Esos datos podrían por ejemplo ser transformados con cadenas de transformadores en base a diferentes reglas y posteriormente almacenados utilizando un Writer a base de datos con su correspondiente mapeo entre los diferentes campos y las columnas de una tabla que recoja esos datos.

En fin, que no quiero aburriros mucho, que realmente creo que la gente de Spring ha hecho un buen trabajo al recopilar patrones comunes en las aplicaciones de manejo de datos, ofreciento artefactos para leer, tratar y almacenar estos datos, para ejecutar, parar, saltarse o repetir tareas sobre estos datos, y para monitorizar el estado de las ejecuciones del proceso sobre estos datos. Todo este trabajo nos permite hacer aplicaciones de tratamiento de datos, es decir aplicaciones batch, realmente mantenibles, aunque tenga el coste inicial de comprender y acostumbrarse al framework.

¿Alguno tiene alguna experiencia con Spring Batch que quiera compartir?

OWASP su API de seguridad ESAPI y tarjetas de crédito

A principios de este mes hablaba sobre OWASP y la charla que iban a hacer en Dublin. El pasado Martes pude ir a la charla y la verdad es que fue bastante interesante.

En la primera, Eoin Keary de Ernst & Young habló sobre ESAPI, una librería Java llena de utilidades relacionadas con la seguridad en las aplicaciones web y que está avalada por OWASP. Echándole un vistazo a su javadoc, se pueden contrar clases realmente interesantes como sus HttpUtilities que define montones de métodos para realizar acciones como encriptar cookies, encriptar query strings, codificar las URLs de manera segura, etc. Otras clases como Encryptor o Randomizer se apoyan sobre JCE para facilitar el encriptar, desencriptar o generar semillas seguras. En fin, hay un montón de clases así que echarles un vistazo vosotros mismos o pasaros por la página del proyecto en Google code donde hay documentación y alguna presentación.

Respecto a si utilizar la librería o no, a pesar de que el autor recomendaba el usarla a toda costa, yo sería más partidario de reutilizar métodos, ya que al final, ya existen librerías muy establecidas como Acegi que se integran muy bien con los servidores web y servidores de aplicaciones disponibles ahora mismo, así que desde mi opinión el ignorar esto sería un poco un paso atrás. Pero ESAPI sí que me parece un lugar muy bueno para obtener patrones, código de ejemplo o simplemente métodos de utilidad para mejorar la seguridad de nuestras aplicaciones. Así que habrá que aprovechar que es Open Source.

La segunda charla fue la de David Rook, que trabaja en mi empresa actual, y que fue realmente buena. David hablaba de PCI (Payments Card Industry) y de si el tener las certificaciones que las empresas que trabajan en el mundo de las compras con tarjeta de crédito necesitan cumplir implican que esas empresas son seguras. Es decir, ¿son equivalentes el pasar una certificación de seguridad y el ser seguro?

David expuso claramente sus puntos de vista, y con los que estoy totalmente de acuerdo, y que vienen claramente a decir que no, es decir, el que te firmen un papel conforme cumples unas reglas generales bastante básicas no implica que seas una empresa segura. Para ello puso varios ejemplos de empresas que habían pasado las certificaciones exigidas por la PCI y que sin embargo habían sufrido graves ataques de seguridad.

Fue especialmente interesante el caso de TJ Maxx en el que aunque VISA sabía que esta empresa no podría cumplir los requisitos exigidos por la PCI, le dio una próloga para seguir operando hasta el 2008 ya qu eel volumen de transacciones de estos grandes almacenes significaban muchísimo dinero, y al final hicieron la vista gorda. Aún así, a pesar de perder 100 millones de tarjetas de crédito (que no está nada mal) resulta que las acciones de la compañía han seguido subiendo sin problemas, lo que genera las cuestiones de ¿Realmente nos importa al usuario de a pie este tipo de brechas de seguridad? ¿Volveríamos a comprar en una tienda a la que le roban nuestro número de tarjeta de crédito? ¿Cambiaríamos nuestra visa por una mastercard si nos pasa esto? Todas son preguntas realmente interesantes y que generaron un buen debate en las preguntas y respuestas.

Pues nada, recomendar a todo el mundo que lee esto que se pase por la web de OWASP porque realmente tienen contenido muy interesante. Por cierto, que los libros que publican se pueden descargar gratuitamente desde Lulu. Los podéis encontrar este enlace.

Domingo de escalabilidad

Cuanta información y que poco tiempo para poder empaparse de ella. Dos de los sitios que leo frecuentemente han dedicado sus últimos post a recopilar información sobre charlas de escalabilidad en tres eventos relacionados muy con el tema: Hadoop Summit 2008, Data-Intensive Computing Symposium 2008 y la MySQL Conference 2008.

Por una parte High-Scalability hace una excepcional recopilación de charlas y enlaces a información interesante presentada en la MySQL Conference. La lista es enorme: "Scaling MySQL and Java in High Write Throughput Environments", "scaling heavy concurrent writes in real time", "Exploring Amazon EC2 for Scale-out Applications", y mucho más. ¡Fenomenal recopilación!

Por otra parte, en el blog de Yahoo Developer Network anuncian la disponibilidad de las transparencias de la Hadoop Summit 2008 (y de bonus las del Data-Intensive Computing Symposium 2008 que también están por ahí). "Hadoop Overview" o "GrepTheWeb- Hadoop on AWS" entre otras que parecen interesantes. Lo mejor de estas transparencias es que los videos están disponibles.

Pues si alguien buscaba algo sobre escalabilidad para leer u ojear para la semana da la impresión de que alguna de estas presentaciones pueden ser una buena opción.

La vida del Freelance

Un poco de relajación para el sábado con este video gracioso que me acabo de encontrar:



Y es que como somos los programadores. No tenemos remedio :D

Aer Lingus automatiza el testeo de su web con Selenium

En SiliconRepublic, que es la publicación tecnológica online irlandesa por excelencia, hablan de como Aer Lingus ha automatizado el testeo de su web con Selenium. Me he animado a comentar esta noticia en el blog porque considero que muestra varios aspectos muy interesantes.

Lo primero es como una herramienta como Selenium le ha ganado la partida en un cliente grande a otros productos de pago como puedan ser Mercury, por poner un ejemplo. El responsable de e-commerce de Aer Lingus lo explica muy claro:

“Where the commercial product failed, Selenium is proving to be successful – we anticipate that our test cycles will be greatly reduced and our test resources will be able to concentrate on advancing the functionality of the site,” said Ronan Fitzpatrick, head of e-commerce at Aer Lingus.

El segundo punto interesante, y que a todos os suena, es lo complicado que resulta el introducir una política de testing de aplicaciones en una empresa. Estamos en un momento en el que, desde mi humilde opinión, nunca ha sido tan fácil testear aplicaciones. Al menos, hace cinco años no había ni la décima parte de las herramientas que tenemos ahora mismo, y las funcionalidades no se acercaban ni de lejos. Y sin embargo, a todos nos suena eso de "-¿Cómo has probado la aplicación? -Nada, unos cuantos clicks por aquí y por allá".

Según el artículo, y estamos en el 2008, en la web de Aer Lingus todo el testeo era p puramente manual hasta la implantación de Selenium. Una de las cosas que más me chocan es lo contentos que se ponen los responsables de los departamentos de QA, y diferentes jefes al ver como se van automatizando todos los tests. Sin embargo, el automatizar un proyecto es algo que tienes que pelear constantemente convenciendo a todo el mundo. Esto es como al niño que no le gustan los pimientos, y que no le gustan, y que no le gustan. Y resulta que pasados cinco años los prueba y de pronto descubre lo que se ha perdido.

El último punto importante que puedo ver es que a medida que las empresas descubren que la automatización del testeo de las aplicaciones es algo cada vez más y más importante, irán apareciendo más y más oportunidades para empresas tecnológicas que se dediquen al aseguramiento de la calidad, pruebas, automatización, y todos estos temas.

La automatización y la gestión de la calidad del software son tareas muy importantes y para las que a las empresa les cuesta mucho encontrar la sufiente expertise en el mercado. Es complicado encontrar expertos en estos temas, ya que por una parte hay poca gente que se dedique a ello, por otra parte los roles de tester están bastante menospreciados, y por último ya que mucha de la gente que se dedica a estas tareas no tiene siquiera conocimientos de software, desarrollo de aplicaciones, etc.

Estoy un poco fuera del mercado en España ahora mismo, pero me pregunto si existen empresas dedicadas exclusivamente a la consultoría de pruebas, haciendo lo mismo que Enovation ha hecho con Aer Lingus aquí en Irlanda.

Amazon reacciona. Habrá por fin almacenamiento persistente para EC2

Google lanza Google App Engine la pasada semana y todo el mundo se vuelve loco y ruegan que soporten sus lenguajes. Estaba claro que esto era un golpe importante para Amazon ya que parte de su base de usuarios irremediablemente se fugará a un servicio como el de Google, que es gratuito.

Amazon tenía que reaccionar. Y parece que lo ha hecho, aunque por ahora únicamente en forma de anuncio. Werner Vogels anunciaba ayer en su blog que Amazon ofrecerá en breve almacenamiento persistente como parte de sus servicios. La nueva funcionalidad permitirá crear volúmenes de almacenamiento persistente que variarán desde 1Gb hasta 1Tb de datos. Los volúmenes se podrán montar en cualquier instancia de EC2 y básicamente se comportarán como discos sin formato sobre los que se podrá instalar cualquier sistema de ficheros. Los volúmenes serán accesibles localmente dentro la zona de accesibilidad sobre la que hayan sido desplegados.

A mayores de esto, Amazon también ofrecerá la posibilidad de crear snapshots de modo que se pueda almacenar una imagen de cualquier sistema de ficheros en Amazon S3. La idea es que esto puede servir para replicar el sistema de ficheros en múltiples zonas de accesibilidad para construir aplicaciones geo-scalables. En el blog de Amazon Web Services ofrecen más información sobre el nuevo almacenamiento persistente para EC2.

Amazon anunció el pasado mes el lanzamiento de zonas de disponibilidad y IPs elásticas. Ahora reacciona con almacenamiento persistente para EC2. Y es que está claro que no hay nada como tener algo de competencia para dinamizar el mercado. Al final creo que los beneficiados somos nosotros, y la verdad es que ya dan ganas de que entren más compañías como Google en serio en el mercado del cloud computing.

El mapa de los centros de datos de google

DataCenterKnowledge publicó hace unas semanas una listas con las localizaciones de los diferentes centros de datos de Google. En Pingdom se han hecho eco de esa noticia y han trasladado toda esa información a un mapa de Google Maps que podéis visualizar desde Wayfaring. El mapa deja bastante claro cuales son sus mercados principales en la actualidad.

El retorno de los applets (otra vez)

Parece que los applets siempre están volviendo pero no acaban de cuajar, ¿verdad? El año pasado, en Febrero, escribía sobre como muchas empresas realmente usaban applets; en Junio me quejaba sobre lo olvidado que tenía Sun a los applets;en Mayo me sorprendía con la demo que había presentado Sun en la JavaOne; y ya en Noviembre escribía sobre Pulpcore y como esta herramienta podría ser usada para reemplazar Flash.

Pues toca otro post sobre esto. A ver si retornan, o resucitan de una vez, o si no que desaparezcan :-) Bueno, el caso es que en DZone publican un resumen muy interesante sobre las nuevas funcionalidades que hay en el JDK 6 Update 10, que se lanzó a primeros de mes, relacionadas con los Applets. Y por primera vez, realmente por primera vez, parece que los applets podrían tener algo que decir. Los cambios solucionan muchos de los problemas existentes. Casi todos eran ya conocidos, pero la verdad es que me han sorprendido unos cuantos. Los más importantes a mi gusto son:

• JNLP: La posibilidad de lanzar un applet a partir de un fichero JNLP. Esto no me lo esperaba y tengo que decir que me parece una idea fenomenal. Java Web Start y Applets eran dos tecnologías que sufrían el mismo problema: por separado eran insuficientes. Los applets tenían esa carencia de funciones y falta de un modelo claro de despliegue, mientras que las aplicaciones de Java Web Start siempre han sido un poco engorrosas ya que obligan al usuario a descargarse el programa, iniciar la ejecución, etc. Permitiendo que los Applets puedan configurarse a partir de un JNLP tiene la ventaja de añadir toda la variedad de opciones al despliegue al tiempo que unifica el deployment de ambas tecnologías.


• Argumentos de la VM: Por fin se pueden especificar argumentos en la máquina virtual desde el tag del applet. Parece que hay ciertas reglas y restricciones pero que casi todos los parámetros están soportados. Además, los parámetros se especifican a nivel del applet. Por fin se podrá asignar mucha más memoria a los Applets, algo que hasta ahora era una enorme limitación, y que obligaba a los usuarios (o administradores) a alterar las configuraciones del Java Plugin para poder ejecutar un applet con una configuración de VM diferente a la habitual.


• JVMs separadas: Ahora un applet puede indicar que necesita una VM para si mismo. Todos los applets comparten la VM del Java Plugin si no se especifica nada. Este nuevo argumento permitirá además la ejecución de un mismo applet en múltiples ocasiones, algo que antes era complicado ya que según el navegador no te quedaría más remedio que compartir la VM (ej. Firefox) lo que tiene muchos problemas si haces uso extensivo de variables estáticas ;-)


• Diferentes versiones del JRE: Cada applet puede ahora pedir la versión del JRE que necesite. Diferentes applets pueden ejecutarse con diferentes versiones del Java Plugin sin tener que tocar nada en el navegador.


• Uso de extensiones de JNLP: Podríamos agrupar esto con el primer punto, pero he preferido separarlo. El caso es que ahora se pueden utilizar desde los applets extensiones de JNLP que permiten hacer cosas como crear interfaces con JavaFX, o utilizar las extensiones de OpenGL.

La lista de novedades está aquí. Y uno se pregunta, ¿qué sería de los applets (y de Java) si a alguien de Sun se le hubiese ocurrido hacer esto hace cinco años?

¿Cuál será el próximo lenguaje soportado por Google App Engine?

Sin duda, la noticia de la semana es Google App Engine. Con todo lo que se ha hablado sobre esta iniciativa, poco más se puede añadir. En inglés probablemente la mejor revisión es la de InfoQ, y en español me quedo con la de Aitor.

Lo que me ha hecho gracia hoy es que visitando diferentes foros, parece que hay una guerra entre los fans de Ruby y los fans de Java para intentar presionar por ser el siguiente lenguaje en ser soportado por Google. Y es que está bastante claro que si Google ofrece hosting gratuito en forma de cloud para cualquiera de estas plataformas, cualquiera de ellas cogerá una enorme tracción. Mientras escribo esto, Ruby tiene 87 puntos y Java 83, así que la pelea está bastante apretada.

Así que Javeros y Raileros, hagan sus votos. Eso sí, en la lista de peticiones para lenguajes, por ahora gana Perl :-).

¿Está UML en decadencia?

Muy interesante pregunta la que se planteaban hace unos días en Coding the Architecture. ¿Está UML en decadencia?

La verdad es que hace diez años, cuando estaba en la facultad y tocaba estudiar lo poquísimo que te enseñaban sobre UML, te imaginabas el llegar a las empresas con tu título de ingeniero-sabedor-de-modelado y empezar a trabajar en modo artista: secuencia por aquí, clase por allá, transición por aquí. Incluso tengo que confesar que en mis primeros años, hasta había ocasiones en las que me tengo esforzado y creado cosas bastante interesantes en UML. ¡Qué digo cosas interesantes! ¡Sí hasta tengo probado varias herramientas que me transformasen el UML a código!

Con el paso de los años, no sé si es que he caido en sitios menos profesionales (que lo dudo), más vagos (que también lo dudo) o es que simplemente me he dado de bruces con la realidad. Y es que a la hora de la verdad, que más da si la mayoría de la gente con la que vas a tratar o bien no sabe lo que es UML, o bien sabe las dos pinceladas básicas, o bien conoce un par de diagramas. Eso sí, hay casos como en la administración pública en los que a la hora de entregar la documentación de determinados proyectos es probable que te pidan literalmente toneladas de diagramas que nadie leerá. Claro, nada que no solucione un buen generador automático :-)

Visto el panorama, ¿de qué vale hacer tu super-diagrama en UML 2.0 si nadie lo va a entender? Sí, es triste, pero es que a mi me da la impresión de que es la realidad. Y si al final nadie entiende tu diagrama, entonces el hacerlo en UML 2.0, por muy cool y estándar que sea, es algo totalmente inútil ya que va contra el primer principio del lenguaje de modelado que es la expresividad. En los últimos años, a la hora de mostrar diagramas, me he encontrado con los siguientes tipos de personas:

• Los que realmente entienden UML: desarrolladores y arquitectos a los que les interesa el tema, que han tenido también que dibujar en numerosas ocasiones, y a los que les puedes enseñar cualquier tipo de diagrama por complejo que sea porque entenderán a la primera lo que estás expresando. La minoría.


• Los que entienden UML pero se han quedado en lo básico: desarrolladores y arquitectos a los que les suena UML porque lo han estudiado o leído en su momento pero que realmente no les importa un comino. Saben lo básico, es decir que hay cajitas y flechas. Conocen estructuras básicas como la herencia y los diagramas más habituales. Pero que sin embargo no saben distinguir entre una dependencia y una implementación, o entre una llamada síncrona y asíncrona.


• Los que simplemente no entienden UML: La mayoría de managers, project managers, business analysts, etc. Verán un conjunto de figuras y flechas. Nada que no pueda hacerse en PowerPoint.

Visto el panorama, es triste ver como mis diagramas en los últimos años han ido evolucionando a un híbrido entre todos los tipos. Personalmente utilizo los siguientes diagramas: de clase, de secuencia, de casos de uso, de despliegue y de componentes. En los diagramas de clase suelo quedarme en lo básico y la verdad es que la mayoría de las veces me como clases e interfaces, o hago uso extensivo de paquetes. Dibujo lo mínimo para que sea legible y entendible, incluso por un no-informático.

En los diagramas de secuencia, cuadrados y flechas. Quizás alguna llamada asíncrona, pero es que tiene que estar realmente clara. En los diagramas de despliegue y componentes, bueno, eso casi que con el tiempo lo he transformado en un diagrama despliegue-componentes porque al final últimamente acabo por poner todo en el mismo diagrama, quedando una mezcla atroz aderezada con diferentes tipos y sabores de formas básicas del Microsoft Visio. Sniff.

Y es que hace unos meses tenía una conversación con un gran amigo mio, versado en UML, que me comentaba que mis diagramas no eran "exactamente" UML. Yo le comentaba, "Lo sé. Pero ya sabes que el UML es en sí un lenguaje de modelado libre, y lo que cuenta es la expresión". Mi amigo discrepaba, ya que considera que ese no es su problema y que la gente debería esforzarse en aprender UML, no esforzarnos nosotros en tratar de encontrar una manera de romper las normas de dibujado para expresarnos de forma que lo puedan entender. Totalmente de acuerdo con esto último, pero es que lo veo tan lejos...

¿Qué opináis vosotros sobre esto? ¿Creéis que el uso de UML ha ido decayendo con el paso de los años? ¿Alguien usa UML 2.0? O habéis tenido la desgracia de ir cayendo en los híbridos por las exigencias del mercado.

PostgreSQL@Skype

Vía High Scalability llego a un interesante artículo sobre como usan PostgreSQL en Skype.

La verdad es que sí que es cierto que PostgreSQL es uno de esos grandes olvidados en el mundo las bases de datos. Durante toda su historia ha estado completamente eclipsado por MySQL. Todo el mundo reconoce que su motor es mejor que MySQL, pero mires a donde mires la gente usa MySQL en vez de PostgreSQL; seguramente sea la mejor base de datos Open Source, pero MySQL consiguió tener su propia compañía gerando enormes beneficios; y para colmo, su creador trabaja en Sun, pero Sun compra MySQL.

Por eso probablemente este artículo sobre Skype, y conocer que una de esas empresas tecnológicas high-profile está utilizando PostgreSQL es especialmente interesante.

En el artículo, comentan como contrataron a un equipo de consultores para analizar su base de datos en busca de soportar 1 billón de usuarios concurrentes. Como esa carga sería muy superior a la que soportaría cualquier superior, escogen una aproximación de sharding en función del código de usuario y escalan horizontalmente añadiendo nuevos servidores.

Lo más curioso es la aproximación utilizada para el sharding, y es que Skype realiza todo el acceso a datos utilizando procedimientos almacenados. Incluso han creado su propio lenguaje PL/Proxy. En el artículo, comentan que esto ha sido una decisión clave y muy exitosa ya que les ha permitido realizar inmensas optimizaciones de rendimiento simplemente modificando los procedimientos almacenados.

Llegados a la hora de escoger que servidor de base de datos servirá una petición determinada, la elección se realiza también en los procedimientos almacenados utilizando su lenguaje especial:

CREATE FUNCTION pwd_check(text, text) RETURNS boolean 
$$
  CLUSTER userdb_cluster;
  PARTITION BY hashtext($1);
$$ LANGUAGE plproxy;

Sucio. Sí, probablemente. Pero efectivo al máximo.

Por cierto, que navegando un poco por su web he visto un par de enlaces interesantes con montones de recursos para integrar Skype dentro de nuestras aplicaciones:

• Skype Garage, una especie de incubador de proyectos experimentales.


• Skype Developers Zone, su nombre lo dice todo.
  
• Skype Developers Zone Blog, el blog de desarrolladores.

Una de las divisiones de Open Source más importantes en el mundo del middleware podría desaparecer

Hace un par de meses IONA, la compañía de software más importante de la historia de Irlanda, y una de las compañías más importantes en el desarrollo de middleware hace diez años, confirmó que había recibido una oferta de adquisición que a tenor de los rumores que circulan por Dublin parece claro que están dispuestos a aceptar.

Anteayer publicaban en TheServerSide el rumor de que la compañía compradora podría ser Software AG. Pero lo realmente importante, y en mi opinión preocupante de la noticia, es que parece ser que la compañía compradora (no tiene por que ser la que nombran) ha estado intentando vender la división de Open Source de IONA a través del inversor que se está encargando de la operación. Parece ser que confirman que al menos dos compañías han recibido ofertas de este inversor para la venta de esta división.

Como bien mencionan en uno de los comentarios del rumor, y aunque sea una pena, el mundo del Open Source no está fuera del bien y del mal, y no escapa de los intereses de las grandes compañías en hacer dinero. Y en este caso, consideran que la división de IONA que ha trabajado en torno al Open Source durante casi dos décadas no puede dar dinero dentro del mundo de SOA. No deja de ser un poco triste que una de esas pocas compañías centradas en el desarrollo de Open Source y que dedica parte de su plantilla a contribuir código a la fundación Apache vaya a desaparecer de esta manera.

Hace unos meses hablaba sobre lo que me había impresionado
Apache Camel y James Strachan en sus presentaciones de la IJTC. Poco después se inició un proyecto en mi pasada compañía que utilizaba Apache Camel y la verdad que es un producto muy elegante. Supongo que una vez que se confirme este tipo de noticias el futuro de este tipo de proyectos estará un poco en el aire, aunque con un poco de suerte igual es una buena justificación para una start-up en torno a estos productos.

Por cierto que desde un mes antes al anuncio de que la compañía podría ser vendida, las acciones han subido hasta casi el doble...

OWASP Top 10 2007 y reuniones en Dublin

Uno de mis nuevos compañeros de trabajo es contribuidor de OWASP, que es una comunidad abierta centrada en el estudio de la seguridad en el software. Su página web está llena de contenidos super interesantes, y entre las cosas que han venido haciendo estos años está la publicación de un informe con las 10 amenazas más importantes para las aplicaciones web.

La última versión del informe es la del año pasado: OWASP Top 10 2007 (PDF). Aunque muchos estaréis familiarizados con las diferentes amenazas, no está nunca demás el repasarse el documento de unas treinta y pico páginas y de lectura bastante amena. Resumiendo, las amenazas son:

1. Cross Site Scripting (XSS)


2. Injection flaws


3. Malicious File Execution


4. Insecure Direct Object Reference


5. Cross-Site Request Forgery


6. Information Leakage and improper Error Handling


7. Broken Authentication and Session Management


8. Insecure Cryptographic Storage


9. Insecure Communications


10. Failure to Restrict URL access

El informe explica cada una de estas amenazas, a que se deben, y ofrece consejos para corregir estos errores y defenderse de ataques potenciales en diferentes lenguajes.

Por otra parte, la gente de OWASP en Irlanda realiza eventualmente algunas reuniones en el edificio de Ernst & Young en Harcourt Street (en frente al Odeon), por si alguien se anima a pasarse por ahí. La próxima, si no me equivoco es el 21 de Abril. Y yo me intentaré pasar por ahí.