SOA, la buzzword más despreciada

Y el ganador de la buzzword más despreciada es: SOA!



Es curioso como otra histórica buzzword como Web Services sólo acapara un 4% en el índice de desprecio. Los servicios web han pasado la barrera de buzzword a realidad, y poco a poco se van implantando. Eso sí, nada que ver con lo que nos vendían hace años.

Por fin etiquetas

Por fin puedo tener tags en mi weblog. blogger.com ha actualizado la versión de su software y ahora todo está un poco más organizado.

Sobre menus, elecciones y Microsoft

Joel se queja de que el nuevo menu desplegable que ofrece Windows Vista para salir del sistema es demasiado farragoso, y Moishe, que fue uno de los miembros del equipo de desarrollo de esa funcionalidad de Windows Vista, expone las verguenzas del proceso de desarrollo de software utilizado en este sistema operativo.

Scrum en 5 minutos

Jeff Sutherland cuenta en su blog que normalmente utiliza en sus presentaciones un PDF creado por SoftHouse y que se titula Scrum in five minutes.

Este PDF está pensado para presentar rápidamente las bondades de Scrum, especialmente a analistas de negocio, directivos, jefes de departamento, que no tengan tiempo para asimilar todas los detalles de la metodología. El documento realizan un análisis muy visual y didáctico de las características de Scrumm, así que siempre será bueno tenerlo a mano :)

Multi-core CPUs y Java

Billy Newport analiza en esta entrada de su blog las posibles consecuencias que puede tener la ubicuidad de los procesadores multi-core. El problema que Billy plantea es que normalmente estas arquitecturas multi-core se presentan con varias CPUs teniendo cada una de éstas una frecuencia de reloj considerablemente menor.

La lectura resulta muy interesante, no sólo el post principal sino también las respuestas. Personalmente, no creo que esta arquitectura sea mala para Java sino todo lo contrario. Obviamente, los productos que hayan sido diseñados deficientemente deberían sufrir teóricamente una bajada en su rendimiento. Pero probablemente muchos productos mejorarán, incluidos servidores de aplicaciones, servidores web, las propias máquinas virtuales y sus algoritmos de recolección de basura, etc.

Java fue el primer lenguaje que apostó seriamente por explotar la concurrencia de las aplicaciones desde que fue creado. Y esto hará que la evolución no sea tan complicada como podría ser para otros lenguajes. Al final, lo cierto es que con ese artículo me ha entrado el gusanillo por uno de estos multi-cores :)

Java es libre, ¿y ahora qué?

Hay ciertos acontecimientos en la vida que te hacen mirar para atrás y de pronto te das cuenta de que rápido pasa el tiempo. Hace cuatro años (creo), recuerdo que yo y Alberto, comenzamos una cruzada personal para promocionar Java en España. Eran otros tiempos, cuando ambos estabamos involucrados en javahispano, y cuando realmente no había demasiado conocimiento de la plataforma Java en España.

Recuerdo haber viajado al menos por Santiago, Madrid, Barcelona, Gandía, Alicante, Cáceres y Madrid hablando sobre las maravillas de Java, y por qué era interesante esta plataforma para las empresas y los usuarios individuales. Intentando eliminar el mito de que Java en sí no era libre (lo siento, lo que han liberado son las herramientas de Sun, bueno y Duke). Que tiempos aquellos, mostrándole a la gente que no era tan sencillo el decir "Java no es libre, no lo uso"; que había otras máquinas virtuales alternativas; que el modelo de especificación era abierto y había organizaciones de software libre como Apache trabajando ya en él.

Supongo que este pasado Lunes esto ha terminado. Punto final. La discusión se ha acabado. ¿Y ahora qué? Pues por el momento habrá que esperar acontecimientos. Por ahora el JDK (que es lo realmente interesante) no se liberará hasta la versión 6 y 7, pero es que la versión 6 ya está a la vuelta de la esquina, así que no tardaremos mucho en verlo. Pronto se incluirá el JDK de Sun y Glassfish ( el servidor de aplicaciones ) dentro de las distribuciones de Linux, aunque habrá que ver si con el nombre de Java (ya que las marcas no han sido liberadas) o con otro nombre clave diferente, lo que se podría decir que marcaría el primer fork.

Será muy interesante ver también lo que pasa con otras implementaciones libres. Ahí están los kaffe, classpath o Harmony. Especialmente este último resulta interesante por algunas de las funcionalidades que ofrece y que no están presentes en las implementaciones actuales de Sun (por ejemplo Harmony es muy modular, está basado en osgi y puedes desplegar una máquina virtual sólo con ciertas partes de la misma). Por otra parte, no deja de estar bastante claro que Harmony ha sido uno de los detonantes de la reacción de Sun, ya que es una máquina virtual que aunque no terminada, si que está muy cerca de la certificación; y sin lugar a dudas la participación de IBM en este proyecto también habrá espoleado de alguna manera a los responsables de Java en Sun.

Desde el punto de vista de negocios, el movimiento de Sun ha sido magistral. Si hubiera esperado más habría llegado tarde. Java estaba en un momento de declieve en estos momentos en comparación con otros lenguajes Open Source como Python o Ruby, siendo este último claramente el lenguaje de moda. No es un secreto que ahora mismo existe actualmente una migración de talentos desde Java a Ruby, y el movimiento de Sun ayudará a aumentar todavía más la base de usuarios de la plataforma.

Sun ha sido listo también con la licencia aplicada al JDK. Ha escogido GPL v2 (+ classpath, para algunas partes), lo que le permitirá que ninguna empresa privada pueda distribuir "sabores" de Java sin que los desarrolladores puedan ver su codigo fuente. Es decir, si alguien quiere distribuir otro JDK, tendrá que mostrar el código fuente, así que los desarrolladores estarán avisados de antemano si alguna compañía se ve tentada a crear un engendro diabólico que acabe con la fama de la plataforma.

IBM ya ha mostrado su descontento por la licencia escogida. Ellos querían adoptar la licencia de Apache, o algo más libre. En cierto modo no deja de ser una pelea empresarial. Harmony ya tiene licencia Apache, y ahora podrá avanzar más rápidamente, así que si lo desean podrán tener su propio JDK con licencia Apache en relativamente poco tiempo. A este nivel empresarial, cuando eres rival de alquien, es dificil llegar a un acuerdo, porque tiene muchas consecuencias (le estoy dando la razón, reconozco que hacen bien las cosas). Y seguramente lo mismo sucederá por parte de Sun, y alguna influencia habrá tenido la opinión de IBM. Emitir juicios en este sentido siempre es algo arriesgado.

Sea como sea, los desarrolladores estamos de enhorabuena.

¿Son útiles las certificaciones?

A raiz de una noticia salida en eweek se han podido leer comentarios en varios blogs acerca de lo inútiles que pueden ser las certificaciones. Que si no significan nada, que si los programadores inteligentes no tienen tiempo para certificarse, etc. Así que como certificado que soy, no puedo resistir el poner aqui mis comentarios.

Personalmente creo que las certificaciones son algo muy útil, tanto para las plataformas, como para las empresas, como para las personas. Pero antes de exponer porque, me gustaría decir que para mi el estudio de eweek apenas tiene valor. Yo no creo que el valor de las certificaciones esté en que vas a ganar más dinero. De hecho yo nunca le pagaría más dinero a alguien por el mero hecho de estar certificado en algo. Yo tengo varias certificaciones Java y conozco mucha gente que sabe muchísimo más que yo.

Beneficios para una plataforma: Las certificaciones son una buena medida de la salud de una plataforma. En cierto modo es un círculo vicioso. Las personas buscan certificarse porque ven que una plataforma es activa y hay demanda en las empresas, y las empresas demandan una plataforma porque ven que hay movimiento en la misma y gente interesada. Normalmente las certificaciones más exitosas y con más gente certificada, te indicará las plataformas que más éxito tienen. Claros ejemplos de esto son Cisco o Microsoft.

Si una plataforma, digamos Eclipse que está muy de moda, saca un camino de certificación, lo normal es que la gente comience a certificarse. Esto llevará a las empresas a valorar estas certificaciones, lo que a su vez llevará a más personas a certificarse, y a más personas que no conocían la plataforma a interesarse por ella por verle salida laboral.

Beneficios para las personas: Una certificación puede darte un trabajo. Así de claro. Puede que no te de un gran sueldo, y seguramente no te va a dar más dinero que otras personas (al menos mucho más), pero una certificación siempre es un punto adicional en el curriculum, que directa o indirectamente se valorará en algún punto del proceso de contratación en una empresa.

Las certificaciones tienen otra serie de beneficios en cuanto a formación, que a veces no se tienen en cuenta. Las certificaciones te proporcionarán una introducción a una tecnología, ya que normalmente se centran en los aspectos básicos. Para las personas como yo, que siempre están con mil cosas, son además un modo de obligare a centrarte en algo y estudiar, lo que siempre es beneficioso. Eso sí, es importante no hacer trampas. Por ejemplo, en su época (no sé si ahora es lo mismo) las certificaciones de microsoft fueron famosas porque las respuestas las podías encontrar en cualquier parte.

Beneficios para las empresas : Para una empresa siempre es bueno que vengan personas con certificaciones a las entrevistas. Estas personas no tienen que ser muy inteligentes, o superestrellas. No existen las certificaciones-para-super-estrella-de-la-programación. Muchas personas no certificadas, atacan a las certificaciones con el argumento de que no demuestran la inteligencia de las personas, que no quiere decir que sean mejor que ellos, etc. Esto no dejan de ser llantos de colegial. Claro que no lo hacen. Las certificaciones no son para demostrar que yo tengo algo que demuestra que soy más listo que tu. Las certificaciones son para garantizarle a una empresa que una persona ha estudiado algo; que al menos tiene unos conocimientos básicos; y sobre todo, y por encima de todo, que una persona no está mintiendo cuando dice "conocimientos de Java".

Ahí está el verdadero valor para las empresas. Hoy en día, cuando te llegan montones de curriculums de gente buscando encontrar trabajo, el tener curriculums con certificaciones significa que al menos esas personas no están mintienedo. Significa que en cierto momento de su carrera estudiaron algo. Eso ya es algo importante. Ahora bien, ¿son inteligentes?, ¿valen para el trabajo? Eso ya lo veremos cuando tengan que venir a la entrevista. Pero vamos, que algún comentario que he leido del estilo "yo no miro para nada las certificaciones, a mi eso no me interesa, las paso por alto". Pues bueno, todo el mundo es libre de pasar por alto la información que quiera, pero hay pocas cosas que te certifican algo como las certificaciones, valga la redundancia.

Por otra parte, el disponer de perfiles con certificaciones es un beneficio para algunas empresas que ofrecen servicios. Esta es la razón de que muchas de ellas obligen a las personas a certificarse. Si la empresa puede ir a un cliente diciendo tengo 100 perfiles certificados en .NET, siempre será indicativo para el cliente. Como decía arriba, quizás no sean 100 cracks, pero por lo menos son 100 personas que cuando dicen que han estudiado algo, no mienten.

Bueno, espero no tener que volver a escribir sobre esto, porque es un tema tan repetido y recurrente. ¿Alguna vez se acabará esta eterna discusión?

J2SE 6.0

Este fin de semana he leido el libro Java 6 Patform Revealed del que probablemente sea el escritor Java más mítico John Zukowski. El libro, no es precisamente una maravilla. Nada que no puedas encontrar online, es decir, descripciones por encima y mucho código fuente. Pero cumple su labor de darte una idea de lo que va a venir (aún así no me gustan demasiado este tipo de libros, ya que me parecen muy "oportunistas").

Sea como sea, yo no quería escribir sobre el libro en sí. Al acabar de leerlo, he recordado hace seis o siete años cuando leias sobre el JDK 1.1 y el JDK 1.2, y vaya, ¡como ha cambiado todo! Incluso si comparamos Java 6, con el JDK 1.4, la diferencia es abismal. Soporte de lenguaje de scripting, las APIs de servicios web, JAXB, XML streaming, XML Digital Signature, el API de compilación, las novedades de Swing, las nuevas anotaciones y el soporte para crearlas, ...

Uno llega a plantearse si esto es realmente racional. Quizás es que llevé muchos años programando con el JDK 1.4 (incluso con las APIs de XML que tantos problemas dan), pero parece que desde ese momento las cosas no han hecho más que complicarse para los desarrolladores nuevos. Incluso cuando el objetivo principal de cada una de las nuevas releases siempre ha sido incrementar la productividad y hacer la plataforma más fácil. Pero lo cierto, es que yo cada vez dudo más que lo hayan conseguido.

Que no se me entienda mal, ahora por ejemplo tengo la oportunidad de programar con el JDK 1.5, y me lo paso en grande. Disfruto como un enano con las nuevas funcionalidades; y probablemente en unos años pase lo mismo con Java 6. Pero si uno se pone a pensar en las personas que entran al lenguaje. ¡Vaya!. Afrontar Java 6 no es como afrontar Java 1.2. Al final supongo que realmente será todo una cuestión de marketing y competencia. ¿Realmente necesitamos que las APIs de servicios web estén en el paquete completo? ¿Realmente hace falta que el soporte de firma digital de XML esté en el JDK?

La verdad, es que después de leer el libro, te das cuenta de que los principales cambios de Java 6 se produjeron ya al menos un año atrás, y que Java 6 lo que hará será incluir todos esos JSRs en lo que poco a poco se está convirtiendo en un enorme bundle cada vez mayor.

Lo cierto es que hace años te podías estudiar varios libros y decir soy un experto en JavaSE. Con el JDK 1.5 nos pusieron las cosas un poco más difíciles, pero tampoco demasiado, porque ni el API de profiling o la de JMX molestan demasiado. Pero lo cierto es que ahora, con todas estas APIs, va a ser difícil que alguien pueda decir, lo sé absolutamente todo sobre J2SE. Pero bueno, eso creo que era algo que prácticamente ya no se podía decir desde hace muchos años.

Lo difícil que es comenzar en una empresa de software

Este post no va sobre mi, aunque pudiese parecerlo inicialmente por el título, sino de muchos de los compañeros de mi empresa. Nuestra empresa ha recibido una inyección muy importante de fondos este año, lo que ha hecho que de repente este verano hubo muchísimas incorporaciones nuevas.

Hace unos días, tuvimos el "induction course", que básicamente consiste en irnos presentando a los nuevos, los diferentes managers que hay en la jerarquía de la empresa. Al terminar este curso, los nuevos tuvimos la oportunidad de expresar nuestras opiniones, en corro, al más puro estilo alcohólicos anónimos. Lo más destacado de los comentarios que hubo, fue el ver que prácticamente todo el mundo se quejaba de lo difícil que resultaba ser productivo en los primeros meses de nuestra empresa. Eso tiene una consecuencia muy importante, ya que al pasar tres meses te tienen que valorar tu trabajo para decidir si pasas el periodo de pruebas. Como consecuencia, había mucha gente que decía que tras dos meses en la empresa, sólo habían podido empezar a rendir después de los dos primeros meses, y que por lo tanto la medida podía resultar bastante injusta.

La verdad es que puedo dar fe de que no mienten. La cantidad de esfuerzo que hay que hacer para configurar nuestro sistema es enorme (de hecho, una de mis labores de la que hablaré en cuanto tenga un rato fue la de hacer una herramienta para la creación automática de clusters Weblogic) en cuanto a tecnologías que tienes que aprender, en cuanto a conocimientos, en cuanto a configuración del entorno (varios productos, varias versiones y subversiones, +100 proyectos Eclipse, ...). Y a todo esto le tienes que sumar todas las APIs que tenemos definidas: sistema de caché, notificaciones distribuidas, replicación, y el resto de APIs que tienen que ver con el negocio.

Una vez explicado el escenario voy a hablar de lo que yo creo que es el problema en este caso. En mi opinión, en las empresas de software, parece que hay una tendencia a pensar que los programadores son auténticas máquinas de conocimiento, personas que por el mero hecho de programar un ordenador, ya lo saben absolutamente todo. Esta tendencia hace que cuando una persona llega a una empresa se le diga "ahí tienes tu PC, ahora te decimos todo lo que tienes que configurar y empiezas a trabajar". ¿Cuántas veces habéis visto esto? ¿Cuántas veces habéis visto que al nuevo se le da su PC, se habla con el una horita, y a trabajar?

Curiosamente, esto no sucede, o no parece suceder, en otros entornos. Si vas a un banco, verás que al nuevo no le dejan dar dinero, o recoger ingresos, o ... nada; si vas a un hotel verás que al nuevo no le dejan hacer una entrada, o una salida, o ... nada; si vas a una recepción verás como el nuevo está detras de otro recepcionista atentamente escuchando y mirando lo que pasa. Así podría seguir con otros ejemplos. El caso es que en todas estas situaciones, la persona pasa por un proceso de aprendizaje, que puede durar días, o incluso varias semanas. ¿Por qué en el mundo del software, el nuevo puede empezar a tocar código sin recibir ni siquiera unas simples directrices? ¿Somos realmente tan buenos los programadores para poder darnos ese grado de confianza ciega?

La solución es simple, aunque estemos hasta el cuello de trabajo, habría que dedicar al menos una semana en explicar todo lo que "el nuevo" necesita saber para ser realmente productivo en su trabajo. Esa semana, se puede dividir entre los diferentes miembros de un equipo, pero sería muy importante que durante esa semana se hiciera una experiencia del estilo "pair programming", igual que en otros sitios hacen "pair recepcioning", "pair banking", o "pair hotelling". A la larga, estamos perdiendo un poco de productividad a corto plazo, para obtener una productividad mucho mayor, porque con un poco de suerte esta persona podrá empezar a ser productiva tras esa semana de entrenamiento.