¿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.