Pequeños cambios en el blog

A los que os paráis a escribir en este modesto espacio, lo primero muchísimas gracias porque me encanta conversar sobre todo estos temas, segundo simplemente comentar que he puesto a la derecha un panelillo donde aparecen los últimos comentarios. Era algo que quería poner ya hace mucho tiempo, pero que mi naturaleza vaga para adecentar el blog me lo impedía (sólo hay que ver el caos del panel lateral para darse cuenta). Por suerte Jordi me ha enviado un pequeño script para solucionarlo.

Por otra parte, desde hace unas semanas os habréis dado cuenta de que hay un mapa que muestra los visitantes en tiempo real que hay en el blog (al fondo a la derecha). Este servicio es cortesía de amung.us y la verdad es que parece que funciona bastante bien. Me encanta entrar en el blog y ver que alguien te está leyendo en ese mismo momento en otra parte del planeta. ¡Muchísimas gracias a los que lo hacéis!

Comunicando ideas con comics

De vez en cuando siempre te topas con algún artículo que supone un soplo de aire fresco a un tema tan tratado como son las metodologías de desarrollo.

En User Interface Engineering han publicado una entrevista con Kevin Cheng en la que explica como en algunos equipos de Yahoo utilizan comics para comunicar historias y casos de uso.

Parece que todo surgió a partir de un encuentro con Bill Buxton, Principal Researcher en Microsoft Research, después de reunirse con Kevin y su compañero Tom Chi, trazaron las ideas sobre lo que posteriormente pasarían a llevar a la práctica con el equipo de Yahoo! Local, que parece que estaba experimentando dificultades.



Según comenta Kevin en la entrevista, la experiencia fue todo un éxito y el feedback enormemente positivo; tanto que otros equipos y otros proyectos pasaron a utilizar esta técnica.

Antes del uso de comics los equipos tenían bastantes dificultades para seguir complejos documentos de requisitos. Según Bill, con los comics consiguen expresar de una manera muy sencilla y clara los diferentes casos de uso de la aplicacón. Es importante destacar que estos comics se centran en las interacciones del usuario con la aplicación, y no pretenden ser diagramas de bajo nivel.

Personalmente, me ha parecido una idea original, muy en línea con las metodologías ágiles. Parece tener realmente mucho sentidos cuando una historia se tiene que compartir, diseñar, especificar entre diferentes personas, departamentos, etc. Todos sabemos lo que pasa a veces con los documentos de requisitos cuando implican a mucha gente: alguien modifica algo aquí, otro añade algo allá, alguien no ve los cambios de la última versión y al final hemos perdido parte del significado.

Poner todo esto en unas cuantas viñetas es una de esas cosas que las piensas y dices: "vaya, esto realmente debe funcionar". Ahora bien, ¿están las compañías preparadas para adoptar una práctica así o es algo simplemente reservado para reductos de innovación como Yahoo? Eso ya es otra historia.

Por cierto, además de la presentación que he incrustado en esta entrada, también hay disponible un podcast con la entrevista.

Las empresas europeas buscan soluciones en Polonia

Hace seis meses escribía sobre por qué Google y otras empresas abrían centros de desarrollo y tecnológicos en Polonia. Ayer, en BusinessWeek se preguntaban por qué IBM sigue en Cracovia.

Según se puede leer en el artículo IBM tiene sobre 1100 empleados en esta ciudad, pero no es sólo IBM sino que ahí también están compañías como Motorola, KPMG o Cap Gemini y entre otras, y es que parece que ciudades como esta con más de 150.000 universitarios son una fuente continua de graduados, no sólo para los departamentos tecnológicos sino también para los de management o financieros.

El artículo también se centra en como muchas empresas europeas han encontrado en países del Este como Polonia la solución a la terrible presión de las empresas de subcontratación Indias ponen en el mercado con su mano de obra barata.

No deja de ser curioso sin embargo el que a pesar de que todas estas empresas estén en Polonia, y que los sueldos siguen subiendo (7% el año pasado), la reaildad es que la mayor parte de la gente joven se va del país. En lo que llevo aquí en Irlanda he conocido a mucha gente de Polonia, no en vano hay más de 180.000 polacos (wikipedia) aquí en Irlanda, todos dicen lo mismo, y básicamente es que todos sus amigos se han ido de Polonia, y o bien están en Alemania, Austria, UK, Irlanda, etc.

También es cierto que hay gente que está volviendo, que parece que la cosa está mejorando estos últimos años, y que los salarios empiezan a ser decentes. La verdad, es que se hace muchas preguntas cuando mira a estos países y ve como las empresas invierten ahí, como está mejorando la calidad de vida, como estos países se hacen más y más competitivos, como hay tanta gente cualificada y con ganas enormes de trabajar, y lo compara con como ha ido evolucionando España estos últimos años donde los sueldos apenan han subido.

Bug Driven Development

Ayer leyendo el blog de Phil Haack me ha gustado mucho la respuesta imaginaria que le hace en su blog a un hipotético escéptico de toda metodología de testing y en la que se inventa el concepto de BDD:

I’m sorry, but I’m not a fan of Bug Driven Development. I think Test Driven Development is not without its challenges, but it’s a better alternative. Either you’re with us, or against us. Are you a bug lover? Bug Driven Development gives comfort to the bugs.

Yo no sería tan radical para decir que si no prácticas el Test Driven Development caerás en un proceso continuo de corrección de errores, pero lo que no cabe duda es que si no existe ningún proceso de calidad, si no existen unit tests, integration tests o una automatización mínima de los tests, se llega a un punto en el que el equipo de desarrollo entra en modo corrección de errores.

Quizás una de las peores consecuencias de esta BDD es que muchos de esos bugs, que no fueron testeados en su momento, ocasionarán cambios en el diseño y en la arquitectura del sistema, cambios que pueden requerir desde horas de código hasta muchos días. Y todo por no seguir un proceso de mínima prevención en un primer momento.

Al final esto de TDD y BDD no deja de recordarme en cierto modo a la medicina preventiva (TDD) y la medicina curativa (BDD).

Google rebaja la latencia bajo el agua

Según se puede leer en alguna web parece que Google ha confirmado este mes en una conferencia celebrada en Singapur que planea el lanzamiento en el 2009 de un cable multi-terabit que cruzará el pacífico y unirá Asia con América.

Todo ello para sacar ventaja sobre rivales como Yahoo o MSN. Da vertigo el imaginar lo importante que puede ser el mercado de los búscadores cuando estas empresas se permiten gastar millonadas en conseguir el canal más rápido posible, aunque sea cruzando océanos.

Que bien nos vendría a nosotros un cablecillo como esos para llegar hasta Nueva Zelanda, pero eso ya es otra historia...

Lotus Symphony, Eclipse RCP y Open Source

Como quizás ya conoceréis porque se ha anunciado en todas partes, esta semana IBM ha lanzado Lotus Symphony una suite ofimática destinada a competir con Microsoft Office y que por ahora se basa en Open Office 1.x pero que pronto lo hará en 2.x.



Ya adentrándose un poco más en la parte técnica del producto, lo que muchos no saben es que está basado en Eclipse RCP y por lo tanto se beneficia de muchas de las características que vienen ya con Eclipse como el soporte de OSGi, su update manager, su sistema de ayuda y sobre todo el poder integrar y aprovechar toda la plataforma en la que han trabajado durante años. No deja de ser interesante como se pueden sacar productos como una suite ofimática a partir de algo que inicialmente sólo era un entorno de desarrollo.



Ahora bien, realmente lo de que pueda competir con Microsoft Office, o google docs, ya es un poco más utópico, al menos por ahora. El anuncio del producto es bastante confuso y aunque en algunos sitios comentan que la suite es Open Source, a mi me da más bien la impresión de que simplemente han querido decir que se basa en Open Source (OpenOffice), ya que no he podido acceder al código fuente o encontrar nada relacionado con el desarrollo.

En caso de que fuese realmente Open Source, entonces sí que puede que la suite tuviese algo que decir, ya que al estar basado en Eclipse RCP sería realmente sencillo el crear aplicaciones que incrustasen esta suite, o aplicaciones que aprovechasen todos los componentes gráficos que incluye.



Una de las preguntas más típicas que me llegaban cuando estaba haciendo el cliente de jLibrary, y que todavía me llega de vez en cuando, era si se podía integrar OpenOffice en Eclipse RCP, y como hacerlo. Básicamente las opciones no eran demasiado agradables:

1. Usar las librerías Java de OpenOffice.


2. Integrar directamente el componente ActiveX (windows) y olvidarse de todo.

Sin embargo, si esta suite ofimática fuese realmente Open Source entonces ya se podría simplemente añadir los plug-ins necesarios y ya tendríamos OpenOffice listo para utilizar e integrar en nuestras aplicaciones corporativas. Y es que creo que eso de "¿puedo integrar Microsoft Office?" o "tenemos que crear un editor que sea igual que Office" es algo que más de uno estará acostumbrado a escuchar.



En fin, os dejo aquí unos cuantos enlaces en los que hablan de Symphony y su relación con Eclipse. Será interesante seguir como evoluciona el proyecto y ver si realmente tiene algún éxito.

Chris Aniszczyk sobre Lotus Symphony.
Lotus Symphony: First Impression.
Escape Velocity: Lotus Symphony.
My firsts impressions of Lotus Symphony.

El rol de build engineer

Una de las posiciones que más hemos intentado presionar donde trabajo para que se contratase es la de release/build engineer.

No cabe duda que hoy en día construir software es más complejo (no necesariamente más difícil) que hace años. La cantidad de diferentes sistemas que intervienen en el funcionamiento de una aplicación hace que crear una release sea mucho más complicado que hace años donde casi sólo había que preocuparse por crear un fichero ejecutable para su correspondiente plataforma.

Hoy por hoy nos encontramos que cualquier mínimo software involucrará aplicaciones de escritorio, applets o RIAs, contenedores web, servidores de aplicaciones, sistemas de mensajería, interfaces o servidores de terceros, etc. Asimismo, la integración continua (incluso aunque nos ponga en evidencia) se ha convertido en una práctica fundamental a la hora de lanzar software a tiempo. Sin embargo, está claro que a medida que el software se hace cada vez más y más complejo el mantener este proceso de integración continua se hace más complicado. Y es que hay que tener en cuenta que el proceso de integración continua no se limita únicamente a compilar el código fuente y asegurarse de que no se ha roto la build , si no que es necesario construir un sistema "vivo" que nuestro departamento de QA pueda utilizar para asegurarse de que realmente no se ha roto nada.

Para intentar solucionar este problema se introduce el rol de build/release engineer. Hoy por hoy si se busca en los portales de empleo se encuentran ofertas de empresas que buscan cubrir este tipo de vacante, aunque es cierto que tampoco son demasiadas. Por ejemplo hoy he estado buscando en las ofertas de Irlanda y sólo he encontrado tres o cuatro en el portal que suelo seguir.

La verdad es que por experiencia propia puedo decir que aunque el rol está justificado lo cierto es que es complicado encontrar a alguien que se quiera dedicar exclusivamente a mantener la salud del sistema de automatización de una empresa, por mucho que este rol te permita aprender como funcionan internamente muchos sistemas. Al fin y al cabo, quién quiere pasarse meses pelando con scripts y ficheros XML, ¿no?

Por lo tanto, en el caso de reconocer el valor de build engineer y no poder contratar a uno, ¿qué se puede hacer? Básicamente se me ocurren dos soluciones:

• Promocionar a alguien de QA: Normalmente (al menos aquí) los testers suelen ser graduates o personas con conocimientos informáticos pero que nunca se han dedicado a programar o que ni siquiera han estudiado realmente informática. Muchas de estas personas son realmente buenos en lo que hacen y llegan a tener un conocimiento global del funcionamiento del sistema mucho mejor que muchos desarrolladores.
  
  Algunos de estos testers con el tiempo van ganando experiencia y conocimientos que les permitirían pasar a ejercer un rol de build engineer, que a fin de cuentas está directamente relacionado con todo el proceso de QA, así que podría verse como un tipo de promoción natural.


• Asignar el rol de build engineer a todo el equipo: Para mi es importante resaltar aquí lo de "todo el equipo". Ya que todos sabemos lo que va a pasar si un desarrollador se dedica a configurar la build el sólo, es decir, que se convertirá de manera no-oficial en el build engineer, y que siempre que pase algo acudiremos a él a ver si lo puede solucionar.
  
  Rotando el rol de build-engineer entre los diferentes miembros del equipo, por ejemplo haciendo que cada semana uno ejerza ese papel, se consigue que todo el mundo acabe por tener un conocimiento de la build y que se mejore también el conocimiento global de como funciona el sistema. Al principio puede hacerse tedioso y engorroso, por eso de que todos tenemos muchas cosas que hacer para andar aprendiendo todos lo mismo, pero con el tiempo y cuando los errores aparezcan todo el grupo habrá adquirido el conocimiento para solucionar los problemas de automatización y no se dependerá del release engineer que vuelve dentro de un mes y se ha ido de vacaciones.

Por cierto, que si os lo estáis preguntando, pues nosotros por ahora nos hemos quedado en un termino medio. Cuando llegué no había nada de nada, pasados unos meses conseguimos un build engineer, pero con el tiempo lo perdimos, y ahora, pues bueno, como al final nuestra automatización ha llegado a niveles bastante avanzados y es bastante compleja pues requiere mucha dedicación, así que hay un equipo digamos de "gestión de procesos" que se dedica a controlarla, siendo algunos de los miembros de este equipo también desarrolladores. Es decir, que en lugar de involucrar a todos los desarrolladores lo que puede ser un poco utópico pues se escogen a tres o cuatro y se les asigna la responsabilidad de estar pendientes de eso como parte de su tiempo.

Eclipse y su infraestructura de testing

Hace tiempo hablaba del Eclipse Way y de como me fascina el proceso de desarrollo que siguen.

Repasando un ppoco las charlas de este año de la EclipseCon 2007 (ya ha llovido) me he encontrado con una bastante interesante de Sonia Dimitrov y Kim Moir donde hablaron sobre todo el proceso de QA que se sigue en Eclipse.



Se extraen varias cosas interesantes:

• Tienen el rol de build engineer para proteger a los desarrolladores del proceso de build (este rol merece un post en si mismo).
• 176.000 tests en 33.000 JUnit tests ejecutándose en cinco build machines con máquinas virtuales 1.4, 1.5 y 1.6.
• 469 tests de rendimiento con 2345 tests que se ejecutan en cinco máquinas diferentes. Se ejecutan sólo unos cuantos días debido a que lleva unas 10 horas ejecutar los tests y procesar los resultados.
• Para asegurarse la validez de los tests de rendimiento utilizan imágenes ghost que instalan justo antes de lanzar los tests.
• Tienen un conjunto de tests de limpieza. Chequean que todo esté correcto: javadocs, licencias, políticas de código, etc.
• Los desarrolladores escriben test unitarios, pero el código de los tests se mantiene separado en un CVS propio.
• Los resultados de los tests de rendimiento se almacenan en una base de datos dedicada.
• Para detectar fallos tienen un parser que analiza la salida de los tests y en caso de errores genera reportes y los envia a una lista de correo.
• La mayor parte de los errores que obtienen no se deben en realidad a errores en el código sino a problemas con las máquinas, poco espacio en disco, actualizaciones de software, antivirus, etc.

No sé que os parece, pero a mi me ha sorprendido especialmente toda la infraestructura dedicada al testing, incluido el dedicar un CVS específicamente para el almacenar el código de los tests. Está claro que toda esta infraestructura y este proceso tan elaborado debe tener algo que ver con la capacidad para estar lanzando versiones sin retraso durante cinco años.

WebLogic se prepara para JEE 6

Si hay algo que no se le puede negar a BEA es que suelen estar por delante de los demás. Fueron de los primeros (¿el primero?)* en soportar JEE 5, en dar soporte oficial de Spring, en permitir la ejecución de su plataforma sobre un hypervisor, etc. A fin de cuentas, es la ventaja de dedicarse casi exclusivamente a su servidor de aplicaciones.

El caso es que según se puede leer hoy en The Register BEA ha anunciado en su conferencia BEA World que WebLogic 10.3 estrenará un nuevo sistema de módulos que permiten escoger que partes quieres instalar en tu servidor de aplicaciones. De este modo puedes prescindir del contenedor web, o de los módulos de Struts, o del registro UDDI, o cualquier otra cosa que no necesites.

Parece que el instalador para esta versión sólo ocupará 150Mb respecto a los 600Mb actuales. La visión de BEA es que se puedan descargar actualizaciones de los módulos de manera independiente y a través de Internet.

Toda la magia de esto radica en la arquitectura mSA (microService architecture) de BEA que se basa en OSGi y que les ha permitido aislar de manera individual 230 componentes diferentes del servidor de aplicaciones. En la EclipseCon 2007 hubo una presentación (estas son las transparencias) en la que se explicaba más a fondo esta arquitectura de micro-servicios y que ya resumió en su momento Alex Blewitt.

Esto es un primer paso como preparación para JEE 6 aunque por ahora parece que habrá que esperar hasta Marzo del 2008, fecha de lanzamiento de WebLogic Server 10.3.

* Nota: Carlos aclara muy acertadamente en uno de los comentarios que hubo varios servidores de aplicaciones que tenían certificación JEE 5 antes de WebLogic 10.

Un par de eventos sobre programación en Dublin

La verdad es que una de las cosas que esperaba al llegar a Dublin, y que me ha decepcionado bastante, es que hubiese eventos tecnológicos a los que asistir. Pues no. La verdad es que en el año que llevo aquí no ha habido nada de nada, aunque justo es decir que en otros años sí que ha habido algo como la ApacheCon del 2006.

Bueno, el caso es que parece que ahora en Otoño va a haber un par de eventos interesantes, y que quizás le interese a alguno de los irlandeses (que me consta que los hay por los comentarios) que leen esto en el caso que se dediquen a IT.

El 15 de Octubre Emmanuel Bernard, Jboss lead developer estará hablando sobre Hibernate en el Westin Hotel, mientras que el 30 de Octubre Mike Culver, Web Services Evangelist de Amazon hablará sobre el futuro de los servicios web. Ambos eventos los organiza developers.ie y el registro es gratuito.

También habrá un evento más grande en Noviembre, pero por ahora no hay muchos detalles sobre ello. Hay que aprovechar que por aquí hay poco de esto.

Validación en Java: Oval, una joya escondida

Hay veces que los frameworks menos conocidos te dan una sorpresa en cuanto elegancia y funcionalidad. Es el caso de Oval, un framework de validación de objetos para Java realmente recomendable.

La idea de este framework es definir los requisitos del modelo de objetos de nuestra aplicación para posteriormente utilizar Oval para que realice la validación. Las restricciones sobre el modelo se definen mediante anotaciones, mientras que la validación se puede realizar de manera programática o automática.

El siguiente código muestra una clase anotada:

public class BOFieldObject
  @NotNull
  @NotEmpty
  @Length(max=32)
  private String name;

...

Para validar el objeto anterior sería muy sencillo:

   Validator validator = new Validator();
   BOFieldObject bo = new BOFieldObject();
  
   List violations = validator.validate(bo);  

Realmente simple, ¿verdad? La siguiente lista muestra lo que personalmente me gusta más de este framework:

• Permite el diseño por contrato. Para ello utiliza AspectJ y escapaz de forzar las restricciones tanto en los constructores como en los parámetros y valores de retorno de los métodos de las clases de modo que se pueden especificar fácilmente precondiciones y postcondiciones.
  
• Soporta herencia en las anotaciones (aunque curiosamente todavía no se pueden declarar anotaciones en interfaces).


• Soporta la creación de anotaciones complejas tanto utilizando Java como lenguajes de scripting como groovy, beanshell o javascript por ejemplo.


• Se pueden crear anotaciones propias.


• Se pueden anotar las clases con las anotaciones definidas en JPA. Oval es capaz de interpretar estas anotaciones y las traducirá internamente a sus propias anotaciones.


• Soporta perfiles de modo que puedes asociar una restricción con uno o varios perfiles. De este modo se pueden ejecutar diferentes validaciones en diferentes escenarios (ej. UI, web, app server, etc.)

La verdad es que he estado comparando este producto con otro framework que en teoría debería ser mucho mejor como hibernate-validator, y lo cierto es que Oval es realmente muchísimo mejor y la mayoría de las funcionalidades que he describido en la lista anterior no las soporta el framework de Hibernate, aunque justo es decir que el primero tiene alguna funcionalidad como la validación en base de datos que a Oval le falta.

En cuanto a rendimiento también funciona muy bien. De hecho, creo que no hay excusa para utilizar un framework como este. En algún pequeño benchmark que he hecho me salía un overhead de 0.03 milisegundos al evaluar un objeto con 53 anotaciones diferentes respecto a lo que sería la instanciación normal del objeto sin validación. Al añadir aspectos a la validación, el overhead pasó a ser tan sólo de 0.05 milisegundos.

En fin, que es realmente una pena que frameworks como este, muy superiores a los que están en Hibernate o Spring no se conozcan más, porque realmente creo que se merece ser más conocido.

Por cierto, ¿Alguién lo conocía o lo ha usado?

¿Debería un arquitecto programar?

Sin duda, éste es el tema que más tinta levanta y ha levantado dentro del mundo de la arquitectura del software. ¿Debería un arquitecto programar? ¿Debería mancharse las manos o quizás debería permanecer distante trabajando en los aspectos funcionales y no funcionales de la aplicación?

Desde luego, opiniones hay para todos los gustos. Hay quien aconseja huir de los denominados ivory-tower architects o que no se corta en afimar que los arquitectos ágiles escriben código. Hay incluso famosos arquitectos que no se cortan en afirmar que un arquitecto debe escribir código.

En el otro lado del ring están las personas que piensan que los arquitectos deben saber cómo programar, deben tener bastantes años de experiencia, pero a la hora de la verdad deben actuar más como estrategas de la compañía mezclando diferentes roles como visión empresarial, liderazgo, análisis financiero, sin necesidad de tener que escribir código.

El caso es que la asociación internacional de software architects (IASA) ha publicado tiene una encuesta online en la que pregunta cuanto debería programar un arquitecto de software. Y el resultado hasta ahora es este:



¿Qué os parece? ¿Coincidís?

Rich Ajax Platform

Hace tiempo (desde que vine a Irlanda) que vengo estando desconectado del desarrollo con Eclipse. No me entendáis mal. Sigo trabajando con Eclipse diariamente (sigue siendo mi IDE preferido), pero ya no estoy al día de los diferentes plug-ins que van saliendo, de las diferentes versiones de los frameworks, etc.

Sin embargo, hoy en sus blogs me ha llamado la atención una entrada que referenciaba al proyecto Rich Ajax Platform. La verdad es que desde que coincidimos en los JAX Innovation Awards del 2006 no había sabido más del proyecto (si a alguien le interesa en esos Awards consiguió el tercer puesto sin tener nada que funcionase minímamente, y es que vale más una buena buzzword hace más que mil desarrolladores ;-)).



La captura de pantalla que se ve arriba es de una demo online que tienen en la página web del proyecto ejecutándose sobre Firefox. Es una especie de mashup de Google Maps incluyendo funcionalidades de chat (Eclipse ECF supongo). El caso es que hay que reconocer que el interfaz es exactamente igual al de una aplicación desarrollada con Eclipse RCP.

Según se puede leer en la página web del proyecto, todavía no se soportan todos los widgets, pero sí una buena cantidad de ellos a juzgar por esta demo.

Parece que según algunos creen, parece que el desarrollo web podría estar cambiando y ahora mismo es ya posible crear un núcleo compacto basado en RCP común a varias aplicaciones y desplegar éstas en el escritorio, dispositivos móviles (eRCP) y la web (RAP) "simplemente" creando algunos adaptadores para cada plataforma.

La verdad es que aunque discrepo con esta opinión, lo cierto es que la demo me ha sorprendido por su similaridad a Eclipse. Eso sí, como comprobaréis es terriblemente lentoooooo.

delicious 2.0

En TechCrunch anuncian la preview de delicious 2.0 (sólo invitación). Se trata de una reescritura completa de la aplicación que añade una serie de novedades que a unos gustan más y a otros menos. En TechCrunch hay varias capturas de pantalla. La interfaz es también completamente nueva.



Personalmente del.icio.us es una aplicación que me deja un sabor agridulce. Por un lado, la utilizo diariamente, y hace su labor, por lo que podría decir que me es útil. Por otra parte, la veo como que si le faltase algo a la hora de organizar mi contenido. Y por lo que he visto, tampoco parece que la versión 2.0 vaya a solucionar esto.

Yo básicamente utilizo del.icio.us para dos cosas: guardar mis bookmarks y ver que es lo que guardan los demás; pero realmente, con lo que yo más disfruto es con lo segundo. Podría ser un arrebato de voyeurismo tecnológico, pero lo que creo es que lo primero no está realmente aprovechado. De hecho, creo que a medio/largo plazo podría vivir perfectamente sin guardar mis bookmarks en del.icio.us, porque prácticamente para lo que más lo uso es para guardar un bookmark que le quiero enseñar a alguien que no está ahora mismo conmigo, así que lo guardo en del.icio.us y al día siguiente lo recupero y se lo enseño.

Quizás me equivoque, pero me da la impresión de que podría haber por ahí alguna oportunidad de negocio para alguna aplicación que fuese un poco más allá de los bookmarks y te permitiese trabajar con el contenido de estos elementos enlazados. Sería un poco como una mezcla de del.icio.us, lector RSS y CMS. Algo que incluso te permitiese crear tu propio blog de bookmarks, aunque seguro que habría que andar mucho con ojo con esto último por posibles problemas con licencias.

Quizáis lo que leyáis esto conocéis algo mejor que del.icio.us...

Probando la eficiencia de los tests unitarios

Via Navegapolis descubro una nueva utilidad para mejorar la eficiencia del proceso de testing. Se trata de Jumble, una herramienta que permite medir la efectividad de los tests unitarios que hayamos escrito.

La idea es clara. Seguro que como yo, algunos habréis tenido la sensación después de terminar los unit tests de que quizás no sean tan completos como os gustaría, e incluso cuando la herramienta de cobertura de código (code coverage) te dice que la cobertura es buena, tu tienes esa sensación de que hay maneras de entrar en el programa que no has cubierto con unit tests.

Lo que hace Jumble es mutar el código de tus clases y después ejecutar los unit tests. Como ha mutado las clases, lo que Jumble espera es que los unit tests sean capaces de detectar esa mutación y alerten de que la entrada es inválida, y por lo tanto fallen. En caso de que los unit tests no fallen pues es probable que ese caso en concreto no haya sido cubierto.

Las mutaciones son de lo más diversas, por ejemplo cambiar sentencias condicionales (e.g. x > y pasa a ser !(x>y)) o por ejemplo cambiar el valor de las constantes definidas en el código, o modificar operaciones aritméticas. Para mutar el código Jumble utiliza la librería BCEL y modifica el bytecode en tiempo de ejecución.

El concepto me ha parecido realmente interesante. Me parece una aplicación bastante inteligente a la modificación de código fuente. En fin, que en el video sobre Model Based Testing que nos recomienda Juan Palacio hablan un poco sobre ello y muestran algún ejemplo.

High performance web sites: 13 reglas para conseguir páginas web más rápidas (video)

El máximo responsable de rendimiento de Yahoo, Steve Souders realizó hace un mes una presentación sobre sitios web de alto rendimiento en la OSCON 2007. El caso es que, Steve, también autor del libro High Performance Web Sites, repitió la presentación en Yahoo hace unos días, y éstos la han puesto en la web para nuestro disfrute.



En la presentación habla sobre 13 reglas que han definido en el grupo de rendimiento de Yahoo para la creación de sitios web eficientes dentro de la compañía, explica cada una de las normas, y las diferencias entre seguirlas y no seguirlas, y por último habla un poco sobre YSlow.

Por cierto, las trece normas en orden de prioridad son:

1. Minimizar las peticiones HTTP
2. Utilizar una CDN
3. Añadir el tag expires a la cabecera HTML
4. Comprimir los diferentes recursos
5. Poner las CSS al principio de la página
6. Mover los scripts al final
7. Evitar las expresiones CSS
8. Externalizar los ficheros JavaScript y las CSS (y cachearlos)
9. Reducir las búsquedas DNS
10. Compactar el código JavaScript
11. Evitar la redirección
12. Eliminar scripts duplicados
13. Configurar los ETags

¿Alguna que se os ocurra?

¿feature o bug?

Visto en Techhawking. Foto de Dratz@flickr.