• Transaction strategies: The High Concurrency strategy, dos formas de mejorar nuestro código para mejorar el performance de una transacción. El método consiste en esencia en sacar del método transaccional toda la lógica que no tenga nada que ver con la transacción.
• Pronoide: Los proxies en Java, Dynamic Proxies vs CGlib, y su uso desde Spring, los proxy explicados de forma muy sencilla y como utilizarlos desde Spring.
• High Performance And Smarter Logging | Javalobby, cosas a tener en cuenta a la hora de implementar el logging en nuestra aplicación.
• Dissecting the Disruptor: Wiring up the dependencies | Javalobby,explicación en detalle de este nuevo patrón tan de moda ultimamente.
• Serialización de alto desempeño: Protocol Buffers | Java México
• Symphonious » Background Logging with the Disruptor
• StringSearch – high-performance pattern matching algorithms in Java
• Implementing a simple cache with Java | Christian Schenk, un sistema de cache sencillo y muy bien montado y pensado.

• La calidad es el aliado de la planificación, no su adversario. Si sacrificamos la calidad por la planificación lo estamos haciendo mal

• “El software y las catedrales son muy similares. Primeros los construimos, después rezamos”, Sam Redwine.

• No existe calidad del software sin satisfacción del usuario.

• “Los buenos programadores utilizan sus cerebros, sin embargo las buenas prácticas nos permite no tener que pensar en todos los casos”.

• La documentación se convierte en un problema cuando se convierte en un factor externo al desarrollo, como si fuera un elemento independiente.

• Testing, ¿hasta donde?. Es difícil definir cual. obj. en este proceso sin llegar a la elim. de todos los err, algo que resulta imposible

• Testing, ¿hasta donde?. No existe relación entre el tamaño del error y los problemas que causa.

• Testing, ¿hasta donde?. Cohete de 18 mill. de dolares había sido destruido en vuelo debido a un simple guión que faltaba en un programa.

• Los departamentos de calidad del software requieren una comunicación continua y fluida con los departamentos de desarrollo.

• La documentación debe acompañar el desarrollo de software, ser parte de él. Debe servir al proyecto y no ser un obstáculo en el mismo.

• No hay nada que justifique que el software se tenga que ir deteriorando conforme se van realizando tareas de mantenimiento con el mismo.

• “Un programador trabaja para un resultado libre de errores; un tester, para encontrarlos”, Moses Oliver,

• “La estructura de un sistema software refleja la estructura de comunicación del equipo que lo ha desarrollado”, Richard E. Fairley.

• Cometer errores en el desarrollo de software es algo natural. Lo importante no es no equivocarse sino detectar los errores a tiempo.

• “Copiar y pegar código de Internet en el código del programa es como masticar chicle que has encontrado en la calle”, Mike Johnson,

• La detección de errores, lo más próxima posible a su origen, ahorra dinero.

• Un programa que no funciona es incorrecto; pero un programa que funciona no es necesariamente correcto: difícil de mantener, entender ..

• El origen de la sabiduría de un desarrollador se basa en conocer la diferencia entre un programa que funciona y un programa correcto,

• Uno de los principales problemas con que se encuentran los equipos de testing es que se consideran obstáculos,

• Los testers son desarrolladores de software, son una pieza más dentro del equipo, hacen otro tipo de trabajo, pero de gran importancia.

• “El código no existe hasta que se sube a un repositorio de fuente”, Jeff Atwood

• Escribid el código para que os entiendan otras personas, no sólo para que os entienda la máquina.

Escribid el código para que os entiendan otras personas, no sólo para que os entienda la máquina

NOTA: Frase de Javier Acedo en la conferencia que dio en Conferencia Agile-Spain 2011

• Elegance vs. simplicity, y como quitar facilmente unas sentencias if/else que inundan el código.
• Speeding up Spring integration tests, pues eso, como simplicar la carga del contexto de spring cuando ejecutamos un test.
• Inicializacion Lazy De Spring Para Tests, más información sobre como inicializar de forma perezosa el contexto de spring.
• Reasons to call .isEmpty on collections in Java | Transylvania JUG y porque es recomendable utilizanr el isEmpty para verificar que una colección es vacía.
• Como hacer nuestros test más legibles con Hamcrest, Hamcrest es una librería que nos provee de una serie de matchers que podemos utilizar para escribir nuestros test con un lenguaje más cercano al natural de manera que se hace más sencillo comprender que están comprobando nuestros test.
• Pojo Properties Auto Testing « Dan Haywood, y como hacer trampas en las pruebas de cobertura. Aunque realmente para que sirve este test.

CSS y JavaScript

Cuando se trata de CSS y JavaScript la opción consiste en unir los ficheros de un mismo tipo en un único fichero y comprimirlos, de esta manera tendríamos un único fichero CSS y un único fichero JavaScript.

En estos casos el problema suele ser combinar el entorno de desarrollo con el de producción. Es decir, durante el desarrollo de la Web es evidente que resulta más sencillo trabajar con varios ficheros que con uno sólo comprimido. El momento de unificarlos y comprimirlos debería realizarse en el momento de instalar la aplicación en producción.

Imagenes

Por tanto, para reducir el número de peticiones sólo nos queda buscar fórmulas para reducir el número de imágenes que utilizamos en nuestra Web. Para ello tenemos 2 opciones.

CSS Sprites

CSS Sprites consiste en combinar varias imágenes en un único fichero. A continuación mediante el uso desde la CSS de la propiedad backgroun-position mostraremos sólo parte de esa imagen.

Pero esta forma de trabajar aunque útil, tiene 2 problemas:

• En algunas ocasiones resulta difícil combinar varias imágenes en una sola.
• Hay que tener en cuenta el tamaño de la imagen. En algunas ocasiones y sobre todo para sprites grandes podemos tener problemas de memoría en el navegador (To Sprite or not Sprite).

Convertir las imágenes a base 64 e incluirlas en la CSS o HTML

Es la técnica que comentaba en mi anterior artículo, Conversión automática de imagenes a Data URis.

En este caso, el problema que tenemos es que no es soportado por todos los navegadores.

Data Uris es soportado en los siguientes navegadores:

• Firefox 2+
• Safari – all versions
• Google Chrome – all versions
• Opera 7.2+
• Internet Explorer 8+

Es decir, no es soportado en nuestros amigos los IE6 e IE7. Aunque para este caso existe la posible opción de utilizar MHTML aunque (yo no lo he probado) parece que no termina de funcionar del todo bien.

Y luego tenemos la limitación de tamaño en el IE8, que no acepta Data Uris de más de 32 Kilobytes.

Bueno, en cualquier caso, las opciones están ahi y la mejor solución dependerá de cada situación particular y supongo que en muchas ocasiones la combinación de ambas técnicas.

Enlaces

Este post es un resumen de un estupendo artículo How To Reduce The Number Of  HTTP Requests de Robert Nyman.

En un próximo artículo pasaremos de la teoría a la práctica.

Es decir, en lugar de ponerlo de la siguiente manera:

<img src="image.jpg">

Lo podemos poner:

<img alt="" src="data:image/jpeg;base64,/9j/4AAQSkZJRgABAQAAAQABAAD/..." />

En estos artículos explica con más detalle la técnica:

• Como poner imagenes en correos o paginas sin usar etiquetas de img o attachments.
• CSSEmbed, conversión automática de imágenes a Data URIs.

Y aquí 2 herramientas online para realizar este conversión.

• Image to base64 converter.
• Image to Data URI convertor.

Y aquí otra para utilizarlo en local o desde aplicaciones Java.

• CSSEmbed

Esta técnica suele aumentar el tamaño en un 30%, pero se compensa si lo metemos en un fichero cacheable (css, html) y ademas lo comprimimos con gzip.

Debemos tener en cuenta:

• Que esta técnica se utiliza para imágenes pequeñas ya que hay una limitación de tamaño (en el IE8 están limitadas a 32K).
• Y que en versiones inferiores al IE8 no es soportado. En estos casos se pueden utilizar en MHTML. La aplicación CSSEmbed que hemos recomendado antes soporta esta opción.

En definitiva, la principal ventaja es que reducimos el número de peticiones al servidor.

<script type=”text/javascript”>
var navegador = navigator.userAgent.toLowerCase();
if( navegador.search(/iphone|ipod|android/) > -1 ){
document.location = ‘http://m.dominio.com’;
}
</script>

Vía: http://miquelcamps.com/javascript/detectar-movil-con-javascript-y-redirigir/

La Integración Continua es como una tarjeta de crédito al revés. Una tarjeta de crédito nos permite comprar algo grande hoy, y pagarlo de a poquito más adelante. Sin embargo, las tarjetas de crédito tienen un pequeño secretito oscuro… el interés compuesto. Terminamos pagando mucho, mucho más de lo que tomamos prestado. Siempre resulta más barato pagar en efectivo si podemos.

Cuando usamos un sistema de Integración Continua, ocurre lo opuesto. Podemos hacer pequeños pagos todos los días, o podemos esperar hasta el final y hacer un único gran pago. ¡Desafortunadamente este último gran pago tiene todo el interés compuesto agregado! Si esperamos al final, terminamos pagando más… mucho más!

Esto ocurre por el “tiempo a oscuras” entre que un desarrollador escribe el código y lo combina con el código que escribió el resto del equipo. Si combinamos el código todos los días, o incluso un par de veces a la semana, los cambios son menores y relativamente indoloros. Pero si esperamos…

Este es el indice del tutorial:

Como podéis ver muy completo y pensado para montarlo desde el principio. Lo podéis encontrar en esta dirección: http://carloszuluaga.wikidot.com/hudson