viernes, 28 de agosto de 2009

Saas y RIAs ayudan a reducir el carbon footprint

Hoy encontré otro caso donde la tecnología ayuda a reducir el carbon footprint, es decir, la huella de carbono que dejamos en el planeta. Software as a service + RIA combinadas para minimizar el impacto ambiental:


Odio los buscadores de coincidencias, pero toclasaas es una aplicación software as a service y también está construida como una rich client application.

Porqué Saas? Pues la optimización de recursos (una aplicación para todos), de conocimiento (sinergia entre los tenants), reusabilidad, etc. minimizan el consumo de energía en comparación al modelo opuesto (cada tenant con su aplicación, server, personal dedicado, etc.).

Porqué RIA? Una aplicación RIA bien diseñada ayuda a minimizar la cantidad de rountrips y el tamaño de los mensajes entre cliente y server. Esto se traduce en menor consumo de recursos, por lo tanto un server puede atender más pedidos. Aunque el aporte más grande está en la mejora de la experiencia usuario, su productividad y optimizar el uso que hace de la herramienta.


miércoles, 26 de agosto de 2009

Green IT no es solo optimizar data centers

Hoy leí en la National Geographic sobre un nuevo tipo de letra pensada para consumir menos tinta en las impresiones. Se llama ecofont y es de uso gratuito:

Una idea genial, muy simple, lo que la hace doblemente buena!

sábado, 22 de agosto de 2009

Como hacer el unit testing mas fácil

Cuando se habla de tdd, exiten muchas herramientas y técnicas asociadas al testing unitario. Mi compañero Sergio hizo un muy resumen de ellas en su blog:

Además de estas técnicas, creo que hay algo fundamental para hacer una aplicación fáclmente testeable y tiene que ver con el diseño. A continuación voy a enumerar algunos aspectos que me parecen importantes.

Modelo de dominio

Resolver la lógica de la aplicación usando un modelo de dominio (o domain model pattern). Testear lógica desde un modelo de dominio es relativamente simple, solo hay que crear objetos, asignar propiedades, llamar a métodos y hacer asserts. Esto se debe a que un modelo de dominio no tiene depentencia a ninguna cuestión de infraestructura como persistencia, seguridad, etc. Esta separación natural hace que las pruebas sean más unitarias.

Me ha pasado de trabajar en aplicaciones donde había que modelar las entidades del dominio sin métodos. Esto es conocido como un antipatrón llamado anemic domain model. Construir pruebas unitarias en este caso es una tarea dura, pues generalmente otro objeto encapsula la lógica. En mi caso, las pruebas dependian de los datos cagados en la base de datos, cuando estos cambiaban, las pruebas dejaban de andar. También pasaba que había casos donde el test modificaba los datos y al hacer esto, invalidaba otras pruebas. Estos esfuerzos adicionales dificultan las construcción y el uso de pruebas unitarias. También pasa que con el tiempo las pruebas dejan de ser válidas ya que nadie mantiene los datos en la base. Según mi experiencia, hubiese sido muy bueno en estos casos trabajar con un modelo de dominio.

Para crear buenos modelos de dominio, recomiendo el libro domain driven design.

Programar hacia interfaces, no implementaciones

Este es uno de los principios de diseño que más me gusta. Si cada objeto de una aplicación (excluyendo al model de dominio) fuera una estrategia intercambiable, sería muy fácil aislarlo para poder testearlo unitariamente. Esto nos lleva al siguiente punto.

Inyección de depencias

Un framework de inyección de dependencias facilita la creación de pruebas unitarias (y de la aplicación). Algo que hago es crear un contexto especial para los casos de test que me permite modificar las dependencias según más convenga. Por ejemplo un servicio (service layer) que usa un objeto para la autorización puedo asociarlo a uno que siempre autoriza para probar determinada funcionalidad. Esto se conoce como mock objects.

Algunos trucos para construir pruebas unitarias usando spring framework
  • Crear una clase TestBase que herede de AbstractJUnit4SpringContextTests. Esta clase define el application context de test a usar.
  • Usar notaciones para definir las dependencias de un test

    Para insertar depencias por tipo:
    @Autowired
    private CatalogService catalogService

    Para insertar dependencias por id del bean
    @Resource
    private Client clientMario

  • Si la persistencia se realizar en base de datos, usar AbstractTransactionalJUnit4SpringContextTests. Esta clase realiza automáticamente un rollback de las operaciones realizadas. Yo la uso desde una clase test base:
    http://www.codepaste.net/4poaxh

  • Marcar los casos de test que ensucian los beans cargados por spring. Esto ayuda a eliminar las dependencias entre test. Por ejemplo si en un test se agregan items al cache y en otro test es necesario que el cache esté vacío para no afectar la prueba, se puede marcar el 1er caso de test como @Dirty y spring volverá a cargar todos los beans nuevamente luego de ejecutar la prueba.

    @Test
    @Dirty
    public void addItemsToCache() {...

  • Definir beans de las entidades del modelo con los resultados esperados en el contexto de test. Esto es algo que evita el hardcodeo de los resultados esperados. Luego se le agrega al caso de test una dependecia a este objeto.

    @Resource
    private Client expectedClient
Espero sea de ayuda. Para mi hay un antes y un después de usar spring.

viernes, 21 de agosto de 2009

Ideas para un mundo mejor

Ojalá alguien más tome la idea de plantar árboles para compenzar el CO2 emitido:

Sería muy bueno para alcanzar el objetivo de cero CO2. Y porque no apostar a hacer crecer este número negativamente en el tiempo...

jueves, 6 de agosto de 2009

Energía solar hogareña

Hace poco un amigo me pasó una tienda que vende equipos de energía solar. Este está muy bueno para trabajar con una notebook desde casa:

También está muy bueno el do it your self

Algo que vale la pena analizar, es encontrar donde esta el 80/20 el consumo energético. Hace un tiempo use como herramienta una calculadora para esto. Otra consideración importante es la de usar la energía solar con aparatos de corriente continua, ya que la conversión a 220 alterna es ineficiente.

Con este tipo de alternativas, estamos mas cerca de minimizar el impacto ambiental.

sábado, 1 de agosto de 2009

Convertir java objects a json usando json-taglib y jstlj

Dado que extjs trabaja con stores del tipo json, sería bueno poder convertir facilmente los objetos java que devuelven los servicios (service layer). Para eso json taglib permite convertir java objects a json en una pagina jsp. Se combina muy bien con jstl para trabajar con objetos más complejos.

1ro Instalar json taglib. Bajar del sitio oficial json-taglib.jar y copiar a WEB-INF/lib del proyecto.

2do Bajar los archivos jsl-api.jar y jstl-impl.jar del sitio jstl y copiar en tomcat/lib

3ro Armar un hello world json y jstl

y listo! Aca dejo un buen tutorial que me está siendo de mucha ayuda:

Conectando extjs con el server side usando spring framewok

Una de las ventajas de extjs es que permite fácilmente poder prototipar sin tener que construir ninguna pieza server side. Con este tipo de frameworks es posbile definir como origen de datos de un combo un archivo json:

// Armo filtros
var comboFilter = new Ext.form.ComboBox({
store: new Ext.data.JsonStore({
autoLoad: true,
url: 'services/sales/filter/brands.json',
root: 'data',
fields: ['id', 'name']
}),
valueField: 'id',
displayField: 'name',
triggerAction: 'all',
forceSelection: true,
mode: 'remote',
loadingText: 'Loading...'
})

Para mayor claridad estoy usando url amigables. La url services/sales/filter/brand.json me dice que quiero obtener del dashboard de ventas, el filtro de marcas, en formato json.

Spring, ademas de ser un IoC/DI container, provee una buena forma de manejar friendly urls. Vamos a explicar paso a paso como usar spring como un pegamento entre client side y server side.

1ro Configurar spring web para escuchar los request en /services:

2do Configurar spring mvc para que la url services/sales/filter sea resuelta con el controller OlapServiceController:

3ero Implementar OlapServiceController. Este es quien realiza la ejecucion del servicio (service layer) que devuelve el filtro y selecciona la vista filter2json.jsp para renderizar el filtro en formato json:

Algo interesante de esta implementación es el bajo acople que hay entre el front end (extjs) y backend (jsp, spring, java, mondrian, etc.). Trabajar con simples urls permite definir un punto de entrada y abstraer totalmente su implementación. Sería posible tener fácilmente más de un server resolviendo peticiones (si los servicios son stateless) o acceder al servicio en la nube y escalar ondemand.

Otra posibilidad interesante es al tener un front end estático, es posible aplicar técnicas de caché en el browser para disminuir la cantidad de request, o distribuirlo a través de una cdn.

Y por último sería "no tan difícil" darle features offiline a la aplicación usando google gears (http://gears.google.com/). Aunque sobre esto me gustaría profundizar un poco más en otro post.