Patrones de diseño

Strategy Pattern

Define una familia de algoritmos, encapsulando cada uno de ellos, permitiendo ser intercambiados entre si. Permite que el algoritmo varie independientemiente de quien lo utiliza

Observer Pattern

Define una dependencia uno-a-muchos entre objetos. En la cual, cuando un objeto (subject) cambia de estado, todos los que dependen de el (observers) son notificados automaticamente

Decorator Pattern

Agrega funcionalidad a un objeto dinamicamente. Es una alternativa flexible a realiza sub-clases para extender funcionalidad.
Este patron de diseño es utilizado frecuentemente en conjunto con el FactoryMethod Pattern y el Builder Pattern.

Factory Method Pattern

Define la interfaz para crear un objeto, pero deja a las sub-clases determinar que clase instanciar. Permite delegar la instanciacion a las sub-clases

Firebird embebido - monousuario

Introducción

El motivo del presente post es comentar mi experiencia con Firebird, y algunas conclusiones a las que he llegado. No pretendo dar una clase de Firebird, sino comentar muy por encima algunas ventajas de trabajar con este motor de base de datos. Me enfocare principalmente en la utilización de Firebird embebido.

¿Que es Firebird?

Firebird es un potente motor de base de datos que implementa toda la funcionalidad que le podemos pedir a este tipo de sistemas (triggers, stored procedures, vistar, etc.). Es muy rápido y consume escasos recursos (muchos menos recursos que otros motores de base de datos mucho mas difundidos)

Firebird se caracteriza por poder ser utilizado de dos formas, como motor tradicional de base de datos que espera conexiones desde las computadoras clientes (similar aMySQL, Oracle, MS SQL Server, etc.), y como sistema de base de datos embebido en el cual solo una aplicación local puede acceder a la base de datos (similar a Access).

Firebird como servidor

Firebird instalado como servidor permite acceder concurrentemente a varios usuarios distribuidos de una manera muy eficaz a traves de una conexion TCP. La instalacion y puesta en marcha de un servidor Firebird es muy rápida, es decir, no nos obliga a tener que realizar una configuración exhaustiva del servidor (si noqueremos realizarlo).

Firebird embebido

Firebird embebido permite utilizar un archivo de base de datos local (de Firebird) sin necesidad de instalar el servidor de base de datos. Esto nos permite poder distribuir aplicaciones sin necesidad de instalar componente extras, solo debemos copiar el archivo con la base de datos y el driver para la conexion embebida (generalmente llamado fbclient.dll o fbembed.dll) y listo, ya tenemos una aplicacion con base de datos corriendo.
Las desventajas que tiene esta forma de operar con respecto al servidor son:

• No permite conexiones remotas
  
• Solo un usuario/aplicacion pueden estar accediendo a la base de datos (porque la misma queda bloqueada cuando es abierta).
  
• No realiza la autenticación de usuarios (es decir, cualquier aplicación puede acceder a la base de datos sin necesidad de poseer usuario y passwords válidos)

Hasta hace un tiempo pensaba que una de las mejores formas de distribuir una aplicacion monousuario, y que no haga uso intensivo de la base de datos, era Access. Actualmente creo que Firebird es una muy buena alternativa, y en varios puntos mucho mas favorable (al menos nos evitamos varios dolores de cabeza en la distribución)

Encontre las siguientes ventajas desde que trabajo con Firebird:

• Firebird no necesita tener instalado una serie de componentes, como pueden ser MDAC, JET, etc.
  
• Firebird soporta todo lo que necesitamos de un motor de base de datos permitiendonos consultas mucho mas complejas.
  
• Firebird tiene un muy buen manejo de datos aún cuando poseemos gran cantidad de datos.
  
• Firebird es totalmente gratuito tanto para uso personal, como comercial.
  
• Firebird funciona en linux.
  
• Firebird surge de InterBase lo que nos permite utilizar los componentes de Interbase para acceder a bases de datos Firebird.

Si bien son varias las ventajas que nos plantea este motor de base de datos con respecto a otras alternativas, principalmente Access, tiene dos desventajas que he identificado para proyectos muy chicos:

• No todos los programadores estan acostumbrados a trabajar con Firebird
  
• Es recomendable instalar un "Manager" para administrar y probar ciertas consultas más rapidamente.

Mi conclusión

Yo siempre pienso que no existe una solución universal (una silver bullet) para resolver los problemas, es por eso que ante cada proyecto debemos decidir cual es la mejor alternativa para nuestros stakeholders. Firebird termina siendo una posibilidad interesante en el abanico de opciones a la hora de decidir donde guardaremos nuestros datos, tanto para aplicaciónes monousuario y que funcionen en una única computadora, o para aplicaciones distribuidas con un uso mucho más intensivo de la base de datos.

Frameworks para Java

Algunas conclusiones recogidas sobre la experiencia en los frameworks

Struts

A favor

Bastante probado, mucha documentacion, muchos ejemplos, aun se siguen desarrollando aplicaciones, ampliamente probado. Se debe tener un conocimiento, aunque sea basico, de sesiones, y http.

En contra

Los DTO (Data Transfer Objects) son un dolor de cabeza. Se deben mapear algunos tipos de datos a string. Muchas veces se termina teniendo los objetos de negocio replicados, pero con Strings. Lo cual implica un trabajo extra por cada objeto. El codigo html generado es muy dependiente de struts. Todos las etiquedas son propias de struts. No se desarrolla mas sobre el mismo.

Spring MVC

Aun no he relizado pruebas exhaustivas sobre el mismo, solo algunos ejemplos muy sencillos para probarlo. Parece ser muy potente y esta en constante desarrollo. No me gusta que es bastante similar a struts como maneja las acciones. Se incorporan constantemente nuevas funcionalidades. Facil de exportar el contenido a diferentes formatos. Me parece util para integrarlo con tapestry en algunos puntos.

Tapestry

Hasta ahora es el framework que mas me ha convencido en cuanto a su arquitectura. Como se dice por alli, para usar Tapestry hay que "desaprender" todo lo que se conoce sobre otros frameworks como struts.

Ventajas

Muy buena arquitectura. Errores muy bien detallados. El codigo html es muy facil de leer, y si se utilizan componentes, casi ni se nota que hay algo mas en el. Muy buena separacion de capas. No es necesario conocer demasiado de http (aunque es recomendable cuando se avanza). Hay muchos componentes.

Desventajas

La documentacion no es demasiado buena. Hay que probar mas que leer. Pocos ejemplos al respecto (Este quizas es el mayor problema). Lleva un tiempo adaptarse al framework. El testing no es tan facil (aunque ya hay objetos que permiten realizar el testing de las clases abstractas con las cuales trabaja).

Conclusión

Por el momento me parece que la mejor opcion es utilizar Tapestry, ya que me parece una muy buena alternativa, la cual esta en crecimiento. En unos años sera junto con spring mvc, a mi entender, una de las opciones mas fuertes (quizas tanto como es hoy struts). Para la union es aconsejable utilizar spring (no el mvc), y para la persistencia hibernate. Estos tres frameworks traen muchas ventajas a los proyectos. Los dolores principales de cabeza se presentan con Hibernate y la perdida de las sesiones, y/o los objetos que se inicializan de manera "lazy".

Rokr e2

Motorola Rokr E2

El Rokr E2 es el sucesor que ha lanzado al mercado Motorola, para suplir ciertas "desventajas" del su antecesor el Rokr E1. El nuevo equipo trae ciertas mejoras y tiene caracteristicas muy interesantes, como el MotoID (que nos permite identificar un tema de musica que estemos escuchando en cualquier lado) y su sistema operativo Linux.

Características técnicas más relevantes

• Display de 240x320 pixels de 256.000 colores
• Sistema operativo Linux
• Memoria ampliable del tipo SD
• Bluetooth
• GPRS
• Camara de 1.3MP

Algunos detalles

En uno de los laterales del teléfono se dispone de botones para bajar y subir el volumen, reproducir y pausar un tema, y atrasar y adelantar los temas. Esto lo hace muy comodo al momento de escuchar musica, no hace falta que miremos la pantalla y usemos el selector para hacer estas operaciones, simplemente usamos la botonera lateral. Estos botones laterales hacen que sea similar a un mp3 player.

Quisiera detenerme en el sistema operativo que trae el teléfono, no en si por que sea Linux (a pesar que me guste), sino porque nos permite realizarle modificaciones al sistema operativo, compilar el código fuente modificado, y incorporarselo al telefono. Es decir podemos "tunear" el sistema operativo que utilizamos. Es mas existen muchas opciones de sistemas operativos basados en la versión original, con diferentes caracteristicas, overclocking, más funciones, nuevas aplicaciones, etc. Realmente es muy interesante para poder experimentar.
El teléfono tiene la opción de conectarlo a una computadora por el cable USB y que la conexión sea detectada como una conexión de red, esto nos permite poder acceder al telefono por TELNET, y SAMBA.

Para experimentar es un muy buen equipo. Tiene muchas opciones para poder adaptarlo a nuestras necesidades y "tunearlo".

Ya en estos dias uno termina hablando mas de las funcionalidades extras que trae el equipo y se termina olvidando que es un telefono, por lo tanto, si funciona como telefono. La señal es bastante buena, pero la autonomía de la bateria podría ser mejor. En un uso normal (para mi) la bateria dura 1,5 dias a 2.

Mi conclusión

El Rokr E2 es un muy buen teléfono, que esta muy equipado, el sonido es de los mejores (supera el Sony W300, W800, y al Nokia 6131. Estos datos son tomados de un estudio que se realizo en EEUU). Para todos aquellos que quieren un teléfono equipado de gama media, esta es una muy buena opción. Tiene camara, muy buen sonido, bluetooth, y posibilidad de adaptar y desarrollar software especifico.