miércoles, abril 30, 2008

Spring Application Server!

miércoles, abril 30, 2008 por Martín


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 :)

lunes, abril 28, 2008

Opinión sobre Spring Batch

lunes, abril 28, 2008 por Martín


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_IDJOB_INSTANCE_IDSTART_TIMEEND_TIMESTATUS
112008-01-01 21:00:23.5712008-01-01 21:30:17.132FAILED


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?

jueves, abril 24, 2008

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

jueves, abril 24, 2008 por Martín


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, abril 20, 2008

Domingo de escalabilidad

domingo, abril 20, 2008 por Martín

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.

sábado, abril 19, 2008

La vida del Freelance

sábado, abril 19, 2008 por Martín

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

jueves, abril 17, 2008

Aer Lingus automatiza el testeo de su web con Selenium

jueves, abril 17, 2008 por Martín

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.

lunes, abril 14, 2008

Amazon reacciona. Habrá por fin almacenamiento persistente para EC2

lunes, abril 14, 2008 por Martín


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.

domingo, abril 13, 2008

El mapa de los centros de datos de google

domingo, abril 13, 2008 por Martín


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.



viernes, abril 11, 2008

El retorno de los applets (otra vez)

viernes, abril 11, 2008 por Martín


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?

jueves, abril 10, 2008

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

jueves, abril 10, 2008 por Martín


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 :-).

miércoles, abril 09, 2008

¿Está UML en decadencia?

miércoles, abril 09, 2008 por Martín


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.

domingo, abril 06, 2008

PostgreSQL@Skype

domingo, abril 06, 2008 por Martín


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:

viernes, abril 04, 2008

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

viernes, abril 04, 2008 por Martín


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

martes, abril 01, 2008

OWASP Top 10 2007 y reuniones en Dublin

martes, abril 01, 2008 por Martín

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