Siempre que se crea un objeto nuevo (en Java con la palabra reservada new) se invoca al constructor del objeto para que cree una instancia. Por lo general los constructores son públicos. El singleton lo que hace es convertir al constructor en privado, de manera que nadie lo pueda instanciar. Entonces, si el constructor es privado, ¿cómo se instancia el objeto? Pues a través de un método público y estático de la clase. En este método se revisa si el el objeto ha sido instanciado antes. Si no ha sido instanciado, llama al constructor y guarda el objeto creado en una variable estática del objeto. Si el objeto ya fue instanciado anteriormente, lo que hace este método es devolver la referencia al estado creado anteriormente. 

En los patrones anteriores utilizamos un Traductor. Imaginemos que el traductor carga a memoria no sólo números, pero también diez mil palabras obtenidas a través de un archivo de texto o un web service. Cada vez que este objeto se cree utilizará mucho espacio en memoria. Además, si se usa un web services para cargarlo, cada carga consume muchos recursos de red y tarda mucho en terminarse de construir. 

Traductor estará disponible para toda la aplicación, y en cualquier lado que se despliegue un texto será invocado. No tendría mucho sentido construir un Traductor cada vez que lo querramos utilizar. Lo más sano sería utilizar un sólo Traductor para toda la aplicación. ¿Cómo lograrlo? A través de un Singleton. Omitiendo la lógica del objeto, el código que se debería usar quedaría algo así:

public class Traductor{
      private static boolean instanciated=false;
      private static Traductor traductorInstance;
 
     /**
       *Notar que el constructor es privado!
      */
      private Traductor(){
          //cargar un diccionario a memoria  a través de un WebService. 
     }
 
    public static Traductor getTraductor(){
           if (! Traductor.instanciated){
                 Traductor.traductorInstance= new Traductor();
                 Traductor.instanciated=true;
           } 
          return Traductor.traductorInstance;
   }
 
    public String translate(String toTranslate){
       //mucho código bonito va aquí
    } 
 
}

En cualquier lugar de la aplicacion que se quiera utilizar hacer una traducción se hace esto:

Traductor.getTraductor().translate("unaPalabra");

¿Qué logramos con esto? Que alguien que utilice nuestro código no pueda hacer esto

Traductor t = new Traductor();

Es un gran beneficio porque podemos controlar mejor, cambiarla en el futuro, optimizarla, a Traductor. Evita malos usos de la clase y se nos asegura que a lo más hay una instancia del objeto en toda la aplicación.

Las cosas no son tan fáciles como parecen. Hay muchas maneras de crear los Singletons. En este ejemplo utilizamos un booleano estático, pero no siempre es necesario, pudimos haber inicializado traductorInstance como null, y en vez de verificar la variable booleana, verificar si la instancia es null o no.

public class Traductor{
      private static  Traductor traductorInstance=null;
      /**
       *Notar que el constructor es privado!
      */
      private Traductor(){
          //cargar un diccionario a memoria  a través de un WebService. 
     }
 
    public static Traductor getTraductor(){
           if (! Traductor.INSTANCE==null){
                 Traductor.traductorInstance= new Traductor();
           } 
          return Traductor.traductorInstance;
   	}
 
    public String translate(String toTranslate){
       //mucho código bonito va aquí
    } 
 
}

O, para hacer las cosas más fáciles (que no siempre conviene, jeje) podríamos evitar la evaluación en getTraductor y crear el objeto cuando lo declaramos:

public class Traductor{
      private static  Traductor traductorInstance=new Traductor();
      /**
       *Notar que el constructor es privado!
      */
      private Traductor(){
          //cargar un diccionario a memoria  a través de un WebService. 
     }
 
    public static Traductor getTraductor(){
           return Traductor.traductorInstance;
   	}
 
    public String translate(String toTranslate){
       //mucho código bonito va aquí
    } 
 
}

Fácil ¿no? Mmm, pues se puede complicar. En Java por ejemplo, todavía se podría obtener una copia de traductor así:

Traductor t = (Traductor)Traductor.getTraductor().clone();

Para evitar esto tendríamos que añadir las siguietnes líneas a nuestra clase Traductor

     public Object clone() throws CloneNotSupportedException {
         throw new CloneNotSupportedException();
       }

También alguien podría extender la clase y volver público el constructor. Para evitar esto sería buena idea declarar nuestra clase como final.

Hay que tener especial cuidado cuando el Singleton se utiliza en un ambiete multi hilos, porque puede crear problemas si no se implementa de la manera adecuada. En Java es posible que tengamos que meter algún synchronized por ahí para evitar problemas.

Concluyendo, la idea central del Singleton es esa: asegurar de que exista tan solo una instancia del objeto en toda la aplicación. Hay muchas maneras de implementar un Singleton (aquí solo vimos algunas). Es un patrón muy aplicado en Java, aunque, como todos los patrones, se puede implementar en cualquier lenguaje orientado a objetos. También se pueden hacer cosas interesantes uniendo el Singleton con otros patrones creacionales (recordemos que el singleton no busca crear, sino que limitar la creación).

Básicamente lo que hace el este patrón es unir varios Factory Methods, delegando la responsabilidad total sobre qué instancias crear a partir de datos comunes. La semana pasada hicimos un pequeño traductor, que al recibir un número desplegaba su valor en español, inglés o alemán. Para mostrar el concepto del Abstract Factory vamos a extender el ejemplo.

Primero vamos hacer un sencillo reloj que nos muestra la hora actual. Como sabemos, la hora puede ser desplegada en formato de 24Hrs o puede ser desplegada en formato AM/PM. Recordando que es a manera de ejemplo, vamos a utilizar la clase Date de una manera que no se debe, y probablemente el reloj lo haríamos de una manera más sencilla, pero para nuestro ejemplo queda perfecta su uso. Como en el caso del diccionario, haremos una clase abstracta de Reloj y dos implementaciones para cada una de los formatos, y una clase que contenga el método del Factory Method. La cosa quedaría algo así:

La clase Reloj:

public abstract class Reloj {
 
    abstract String dameLaHora();
}

La clase que se da la hora en formato AM/PM:

public class RelojAmPm extends Reloj{
 
    public RelojAmPm(){
 
    }
 
    public String dameLaHora() {
        Date d = new Date();
        int hora = d.getHours();
        int minutos = d.getMinutes();
        int segundos = d.getSeconds();
        String tr;
        if (hora<=12){
            tr="Son las "+hora+":"+minutos+":"+segundos+" AM";
        } else {
            tr="Son las "+(hora-12)+":"+minutos+":"+segundos+" PM";
        }
 
        return tr;
    }
 
}

La que nos da la hora en formato de 24 horas:

public class Reloj24Hrs extends Reloj {
 
    public String dameLaHora() {
        Date d = new Date();
        int hora = d.getHours();
        int minutos = d.getMinutes();
        int segundos = d.getSeconds();
        String tr;
        tr = "Son las " + hora + ":" + minutos + ":" + segundos + " ";
 
        return tr;
    }
}

Nuestra clase que contiene la el método que elije las instancias. A diferencia del post anterior, ahora el parámetro que recibe el método es un entero, que acepta los enteros especificados como constantes estáticas en la clase. Esto se usa mucho para no estar adivinando los paráemetros que acepta el método:

public class RelojFactory {
    public static final int RELOJ_AM_PM=0;
    public static final int RELOJ_24_HRS=1;
 
    public RelojFactory(){
 
    }
 
    public static Reloj createReloj(int tipoDeReloj){
        if (tipoDeReloj==RelojFactory.RELOJ_24_HRS){
            return new Reloj24Hrs();
        }
        if (tipoDeReloj==RelojFactory.RELOJ_AM_PM){
            return new RelojAmPm();
        }
 
        return null;
    }
 
}

Y finalmente la clase cliente, que será la usuario final:

public class MainClient {
 
    public static void main(String[] args) {
        Reloj r = RelojFactory.createReloj(RelojFactory.RELOJ_24_HRS);
        System.out.println(r.dameLaHora());
    }
}

Hasta aquí tenemos dos fábricas: una de palabras, y la que acabamos de hacer que nos da la hora. En un proyecto cualquiera se nos pide hacer un sistema que despliegue la hora y los números de la manera en la que se expresan en cada país (una implementación súper elemental de Locale de Java). Vamos con dos ejemplos prácticos. En Estados Unidos se despliegan los números en inglés, y la hora en formato AM/PM; mientras que en Guatemala se dicen los números en español y la hora en formato de 24 Horas.

Ahora vamos a crear una Abstract Factory, que le pondremos Locale.

public abstract class AbstractLocaleFactory {
    public static final String US="ESTADOS_UNIDOS";
    public static final String GT="GUATEMALA";
 
    String pais;
 
    public abstract Traductor createTraductor();
    public abstract Reloj createReloj();
 
    public String getPais(){
        return this.pais;
    }
 
    public void setPais(String pais){
        this.pais = pais;
    }
 
}

Como ven esta fabrica tiene un par de métodos que devuelven un Reloj y un Traductor. Noten que Reloj y Traductor son a su vez clases abstractas.

Ahora implementamos nuestra clase LocaleGuatemalaFactory, que va así:

public class LocaleGuatemalaFactory extends AbstractLocaleFactory{
 
    public LocaleGuatemalaFactory(){
        this.pais=this.GT;
    }
    public Traductor createTraductor() {
        return TraductorFactory.createTraductor("espanol");
    }
 
    public Reloj createReloj() {
        return RelojFactory.createReloj(RelojFactory.RELOJ_24_HRS);
    }
 
}

Y la respectiva para Estados Unidos:

public class LocaleEstadosUnidosFactory extends AbstractLocaleFactory{
 
    public LocaleEstadosUnidosFactory(){
        this.pais=AbstractLocaleFactory.US;
    }
 
    public Traductor createTraductor() {
        return TraductorFactory.createTraductor("ingles");
    }
 
    public Reloj createReloj() {
        return RelojFactory.createReloj(RelojFactory.RELOJ_AM_PM);
    }
 
}

Ahora en el cliente, si queremos las cosas como se verían en Guatemala, simplemente hacemos esto.

public class MainClient {
 
    public static void main(String[] args) {
 
        Reloj reloj = null;
        Traductor traductor = null;
 
        AbstractLocaleFactory localeFactory = new LocaleGuatemalaFactory();
        reloj = localeFactory.createReloj();
        traductor = localeFactory.createTraductor();
 
        System.out.println("--------");
        System.out.println("1="+traductor.traducirNumero(1));
        System.out.println(reloj.dameLaHora());
 
    }
}

El resultado de correr el codigo anterior es:

1=uno
Son las 21:50:17

Ahora si cambiamos la linea

        AbstractLocaleFactory localeFactory = new LocaleGuatemalaFactory();

Por esta

        AbstractLocaleFactory localeFactory = new LocaleEstadosUnidosFactory();

Tendremos como resultado:

1=one
9:52:56 PM

Aquí es un ejemplo sencillo. Pero imaginen quedemos hacer un Locale para cada país, y en el locale tener más cosas como: la nomenclatura de moneda, el sistema de numeración, el manejo de fechas, kilómetros o millas, etc. Con el Abstract Factory Pattern es muy sencillo agregar cada nuevo pais, o cada nueva característica del Locale. Pero sobre todo el código es MUY legible y FACILMENTE extensible. Alguien que nunca ha visto estas piezas de código puede entender como hacer un nuevo país.

Entonces, el Abstract Factory Pattern puede ayudarnos mucho en casos donde hemos de manejar familias de objetos. Al inicio no siempre es obvia su implementación, pero siempre está el recurso de del refactoring, en el cual salen nuevas maneras sencillas de hacer las cosas. Este, como muchos patrones, requieren escribir un poco más de código al principio, pero nos reducen el esfuerzo a largo plazo porque hay menos código repetido.

Aquí el código de este patrón.

Hoy hablaremos del más famoso de los patrones de creación: en Factory Pattern (Patrón de fábrica). Utilizaremos los nombres ingleses porque creo que son más claros que las traducciones que se podrían hacer. Además, en software de todos lados, es más estandar utilizar el inglés en ciertas nomenclaturas para facilitar que otros lean nuestro código. Buhh, alguien alega por ahí, pero reconzcámoslo: programamos en inglés. 

Como todo se entiende mejor con un ejemplo -al menos eso creo yo-, comenzaremos con uno. Supongamos se nos encarga crear un traductor que devuelva los números del cero al diez en tres idiomas: inglés, español, y alemán. Existen muchísimas maneras de hacer esto. Al final, se desea un método que reciba un entero entre 0 y 10 y que devuelva una cadena con el nombre de dicho número en el idioma que se esté trabajando. 

Una manera de entrarle al problema podría ser algo así:

public class MainClient {
public MainClient(){
     }
 
	public traducirNumero(String idioma, int numero){
		if (idioma.equals("español")){
		  switch (numero){
		     case 0: return "uno";
		     case 1: return "dos";
		    ....
		   }
		}
 
		if (idioma.equals("english")){
		    switch (numero){
		     case 0: return "one";
		     case 1: return "two";
		    ....
		    }
		} 
 
		if (idioma.equals("deutsch")){
		    switch (numero){
		     case 0: return "eins";
		     case 1: return "zwei";
		    ....
		    }
		}
	}//traducirNumero
       
public static void main(String args[]){
MainClient mc = new MainClient();
System.out.println(mc.traducirNumero("espanol",1));
}
}//de la clase

 El resultado del código anterior, como ya sabrán, es uno.

Esta solución parece funcionar, y de hecho lo hace. Pero imaginemos que ahora nos dicen que desean la traducción de todos los números? Sin duda el código comenzará a crecer. Y claro, ahora tendremos que agregar código de lógica para cada idioma para escribir números como 752, 1233, etc. 

Como nos gusta hacer gala de nuestro enfoque a objetos, los primero que se nos ocurre es una herencia. Definiremos una clase abstracta Traductor, y para cada idioma haremos una subclase de Traductor.

public abstract class Traductor{
 
   public abstract String traducirNumero(int numero);
 
}

Y ahora comienza la magia a aparecer. Vamos a crear una clase especializada para diccionario, que se encargará de traducir los números. Tendremos una clase especializada para traducir los números al español, que iría algo así:

public class TraductorEspanol extends Traductor {
 
    public TraductorEspanol(){
       super();
       ...
    }
 
    public String traducirNumero(int numero){
       switch(numero){
       	   case 1: return "uno";
       	   case 2: return "dos";
       	   ...
       }
    }	
 
}

La clase para el inglés iría

public class TraductorIngles extends Traductor {
 
    public TraductorIngles(){
       super();
       ...
    }
 
    public String traducirNumero(int numero){
       switch(numero){
       	   case 1: return "one";
       	   case 2: return "two";
       	   ...
       }
    }	
 
}

Y la del alemán no la ponemos, porque ya captaron la idea. Ahora, en el momento de querer utilizar un diccionario, se llamaría algo así

Traductor t = new TraductorEspanol();
t.traducirNumero(1);

Entonces, la clase MainClient cambiaría un poco y quedaría así:

public class MainClient {
 
	public String  traducirNumero(int numero){
		Traductor traductor = null;
		if (idioma.equals("español")){
			traductor = new TraductorEspanol();
		}
 
		if (idioma.equals("ingles")){
			traductor = new TraductorIngles();
		} 
 
		if (idioma.equals("aleman")){
			traductor = new TraductorAleman();
		}
		String toReturn traductor.traducirNumero(numero);
                return toReturn;
	}//traducirNumero
     public static void main(String args[]){
          MainClient mc = new MainClient();
          System.out.println(mc.traducirNumero("espanol",1));
     }
}//de la clase

Qué hemos ganado? Primero, nuestro código es mucho más legible. Segundo es bastante más escalable. Podemos agregar el traductor para el francés muy fácilmente. Tercero hemos escondido la manera en la que traducimos a Tradúceme. Por ejemplo, puede ser que las traducciones a chino las vayamos a traer a un web Service. En ese caso TraductorChino se encargaría de hacer todo el ajetreo de conectarse a internet y buscar el web services, pero los demás ni se enteran.

Pero el Factory Pattern no ha aperecido, Es tiempo de irlo a llamar. Bueno, Traduceme está haciendo algo que no le compete: está eligiendo la instancia de Traductor que quiere usar. Imaginen que se usa el traductor en 100 lugares, entonces en cien lugares se tiene que buscar qué clase de Traductor vamos a instanciar. El patrón de fábrica -factory pattern- nos esconde esa lógica. Vamos a agregar ahora nuestra fábrica de traductores.

public class TraductorFactory {
     public TraductorFactory(){
 
     }
 
	public static Traductor createTraductor(int numero){
		Traductor traductor = null;
		if (idioma=="español"){
			traductor = new TraductorEspanol();
		}
 
		if (idioma=="english"){
			traductor = new TraductorIngles();
		} 
 
		if (idioma=="deutsch"){
			traductor = new TraductorAleman();
		}
		return traductor;
	}
}//de la clase

¿Qué hace TraductorFactory? Simplemente elige, en base a los argumentos dados - en este caso el idioma- qué clase de traductor se instanciará. Traduceme de nuevo cambia y quedaría así:

public class MainClient {
     String idioma;
     public static void main(Strin []args){
		Traductor traductor = TraductorFactory.createTraductor("espanol");
		System.out.println( traductor.traducirNumero(1) );
	}//main
 
}//de la clase

MainClient se ha visto dramáticamente reducido, y su código es muy fácil de leer. Quien quiera usar un traductor simplemente hará llamar a Traduceme. Traduceme sabe el idioma que eligieron, pero no sabe que subclase de Traductor instanciar, pero sabiendo el idioma TraductorFactory sabe exáctamente qué instancia de Traductor crear. Si la aplicación desea cambiar de idioma simplemente le envía otro parámetro a Traduceme y listo. También agregar idiomas es más manejable que antes. 

El Factory Pattern esconde al usuario final dle código la desición de qué sublclase instanciar, y promueve el encapsulamiento de las partes más variables del sistema. En términos generales, una fábrica abstracta consiste de las siguientes partes:

• Un cliente, que es el que llama a la fábrica (en nuestro caso MainClient).
• Una fábrica, que decidé la clase a instanciar (TraductorFactory).
• Un prodicto, lo que la fábrica devuelve (para nosotros las instancias de Traductor).

Pueden bajar los fuentes de este ejemplo aqui.

Estamos en abril, pero la noticia del año en  en el mundo tecnológico  acaba de suceder: Oracle comró Sun. El precio por acción fue de $9.50, totalizando la pequeña cifra de 7.2 millones de dólares. Muchas cosas han aparecido y mucho se ha comentado en blogs, foros y cículos tecnológicos en general. Para muchos, como yo, que desarrollamos mucho en Java la pregunta obligada es ¿qué va a pasar con Java? Pero lejos de ser esta la única pregunta a responder, hay una lista que surge por ahí.

• ¿Qué va a pasar con MySQL? El negocio principal de Oracle han sido las bases de datos, y lo seguirá siendo. MySQL probablemente ha sido su mayor competidor. ¿Lo dejarán vivir? Yo creo que sí, que volverán a MySQL parte de su negocio. 
• ¿Qué va a pasar con Netbeans? De cuando en vez visité el sitio de JDeveloper, lo bajaba y lo probaba. Sin duda un IDE bonito y completo. Lo que nunca encontré es alguien que lo usara y siempre me causó duda el que Oracle lo siguiera desarrollando. ¿Van a unir NetBeans y JDeveloper? ¿Adiós Netbeans? ¿Seguirán caminos separados?
• ¿Qué va a pasar con Solaris? Creo que vamos a comenzar a escuchar más de Solaris. Aparecerán versiones de Oracle (y MySQL) áltamente optimizadas para Solaris y cosas parecidas.
• ¿Qué va a pasar con OpenOffice? Mmmm, no sé. ¿Le interesará a Oracle?
• ¿Que pasará con VirtualBox?
• ¿Que pasará con Glassfish y parecidos? Es probable que Oracle intente unificar todo el middleware en el suyo propio. JBoss debe estar ya craneando qué camino tomará para que no se lo tomen. 

Un tema que ha sucitado mucha incógnita es ¿qué pasará con el hardware de Sun? ¿Se dedicará Oracle a vender servers? Oracle ha tenido mucho acercamiento con Dell y especialmente HP para vender su base de datos en servidores de dichas compañías. ¿Querrán hacer compromisos éstas con su nuevo competidor?

En fin, la lista de preguntas es larguísima. Desde las certificaciones hasta el JCP (Java Community Process). Sólo el tiempo nos dirá. IBM hizo una propuesta de comprar son a inicios de mes … ¿se estarán mordiendo los dientes? Lo que sí sé, es que tendremos Java por mucho tiempo más.

Patrones de Diseño (Design Patterns)

A partir de ahora comenzaremos todos los martes con un nuevo patrón de diseño. ¿Qué son los patrones de diseño? Bueno, durante el tiempo que el paradigma de programación orientado a objetos ha estado por ahí, se han aprendido muchas cosas. Muchas de las lecciones aprendidas se han tratado de conceptualizar. El primer esfuerzo se le debe a la conocida como Gang Of Four (GoF), quienes fueron los primeros en acuñar el término. 

Los patrones de diseño son un conjunto de estrategias, o buenas prácticas, que pueden facilitar el trabajo en muchas situaciones a la hora de realizar una aplicación orientada a objetos (según la RAE utilizo de mala manera el término “aplicación”). Los patrones de diseño son relativamente fáciles de comprender, no son nada del otro mundo. Lo que a veces se hace complejo es utilizarlos. Por ello hay que conocerlos bien, especialmente los más importantes, porque realmente facilitan el trabajo, y sobre todo, hacen el código más legible. 

Los patrones de diseño son independientes del lenguaje en el que utilicen (siempre y cuando el lenguaje sea orientado a objetos!). Generalmente se presentan como diagramas de UML. Una lista completa la pueden encontrar en wikipedia. 

Según su enfoque los patrones de diseño se agrupan en:

• Patrones de creación (o creacionales). 
• Patrones estructurales. 
• Patrones de  comportamiento.
• Patrones de sistema. 

Por azares del destino, un compañero de despido estaba muy metido en la política. Era parte de un nuevo partido de izquierda, el partido de dignidad nacional (PDN) cuyos postulados tenía mucho sentido. Pero sobre todo era el partido con más corazón: estaba dispuesto a elevar los impuestos para distribuir mejor la riqueza, era fiel precursor de la lucha por la educación pública en todos los sentidos, la salud pública y la ayuda al menos favorecidos. Muchas de sus ideas hicieron eco en todo el país. Proponían eliminar la educación y salud privadas de manera que todos comenzaran con las mismas oportunidades y de que las elevadas sumas que la gente pagaba en las instituciones privadas las absorbiera el gobierno para hacer un mejor uso de ellas.

El auge del partido era grande. La población cada vez empobrecía más y las condiciones de vida en el país se deterioraban. Cuando entré no vi mucho lugar para mí. Sin embargo por alguna razón, tal vez ser de los pocos profesionales, me nombraron candidato a diputado. Fue algo que sucedió muy rápido. No estaba acostumbrado a las reuniones públicas, pero me gustaban. Me gustaba el respeto que la gente me daba. Además en el partido comencé a trabajar como asesor legal….y me pagaban! Me pagaban incluso más que en mi anterior puesto. Afortunadamente pude rodearme de gente con corazón que deseaban un bien para el país, y yo era uno de sus representantes.

Vinieron las elecciones. La tensión comenzó a crecer en mí. Lo gocé. Gracias al interior del país logré quedar como diputado. Mi asombro era mucho: era un representante del pueblo. Tenía un encargo que no sabía que podía tener. Sin tan ni son de repente yo, Inocencio Izquierdo, era diputado. De pronto comencé a tener muchos amigos, y muchas fiestas se hicieron a mi nombre. Yo no cabía de felicidad, pero nunca olvidé la responsabilidad que había caído sobre mí: el de representar a mi pueblo. Y digo que fue una responsabilidad que cayó sobre mí, porque yo no la elegí. Desde ese tiempo me volví creyente del destino.

Y así, comencé mi vida política.

Algunas características importantes que pido de la tecnología de presentación:

• Java. Por ahora me quedo con Java, con sus pros y sus contras.
• Web.
• Open, libre, gratis.
• Que las cosas se vean bonitas, out-of-the-box. No soy bueno con el diseño gráfico, y por ahora no tengo interés en enfocarme en él. Por ello es importante que la tecnología que escoja haga cosas fancy que se vean bonitas.
• Que sea sencillo generar código con él.
• La curva de aprendizaje no ha de ser muy elevada.
• Decente integración con Netbeans y/o eclipse.

Ahora, vamos con cosas puntuales.

• Binding inteligente. Mejor si la unión entre el GUI y el resto pueda hacerse con Beans.
• Tablas inteligentes. TableModel, o equivalente que permita hacer pagineos y búsquedas sobre las columnas. Las tablas son muy importantes para mí.
• Ajax….
• Templates o skins ya definidos, y una manera de personalizar un poco la presentación final.
• La menor cantidad de código goma o de plomero. No soy amigo de XML, pero tampoco enemigo: si se usa de manera inteligente puede ayudar mucho, pero hay frameworks que simplemente se pasan con sus implementaciones en xml.
• Documentación, ejemplos, etc.
• Una comunidad grande. Este es uno de los puntos de mayor peso a mi criterio. Una comunidad de mayor tamaño permite corrección rápida de errores, foros, comentarios, etc.
• Algún soporte comercial, o el patrocinio de una(s) de las grandes empresas de software.
• Una expectativa larga de vida. Importante también. La tecnología que escoja será mi caballo de batalla por los siguientes años. Al menos espero que así sea.
• Cantidad de componentes o widgets. Yo no me voy a poner a diseñar calendarios en js o comboboxes que tengan autocomplete.
• Quiero escribir las cosas una vez. Si el framework me deja “deployar” mis aplicaciones en html, flash, mobile, desktop y demás mejor.

Aparte de las mencionadas hay un “me gusta” que una nueva tecnología debe tener. Ese presentimiento interno de que mi relación con la tecnología a escoger será buena.

Por mucho tiempo mi plataforma de trabajo se basaba en hibernate, para la persistencia de datos, jsf para la presentación, más específicamente richfaces, junit para los tests. Simple pero funcional. En su momento tuve la disyuntiva richfaces-icefaces, pero decidí irme por richfaces porque me gustó más y por el hecho de que JBoss lo soportaba. Estaba comenzando con SEAM cuando tuve que hacer un deploy de un proyecto con richfaces en un weblogic 8 que costó muchísimo, lo que me hizo quererme hacer más independiente del servidor en el que instalo: que corra en tomcat.

Bueno, hoy me entero que jboss comenzó´a pasar su middleware a GWT. En pocas palabras me dijeron que abandonarán eventualmente el proyecto richfaces. Por ahora richfaces me funcionó bien, salvo algunos problemas de compatibilidad de exploradores. Pero adquirí mucho conocimiento al respecto y las cosas funcionaban como quería.

Ahora, lo más sabio es buscar y casarme con una nueva tecnología lo más pronto posible. Lo que me abruma es la cantidad de propuestas que existen. Los llamados RIAs ahora aparecen por todos lados. Cada framework con enfoques muy diferentes y propuestas más diferentes. Pero hay que elegir uno.

Hace unas semanas hice un poco de investigación. Al final creo que los competidores finales son:

• GWT.
• ZK.
• Echo
• OpenLaszlo.
• Flex.
• Appcelerator.
• AdobeAir
• JavaFx
• Wicket
• SmartClient
• SpringMVC
• OpenXava
• ItMill
• Rialto

Estas han sido mis opciones finales, sin embargo la oferta es considerablemente más amplia. Una búsqueda en google o en wikipedia les puede dar más luces. De todos estos frameworks algunos tienen un enfoque más geek, otro más “javero”, otros mas xml, otros más swing, etc. Lo bueno es que hay mucho de donde elegir. Lo malo es, irónico, que hay mucho que elgir.

Un buen comienzo es ser sincero: ¿Para qué existe una empresa de software? Como cualquier empresa, la primera razón es: hacer dinero. Creo que cualquier empresa que olvide ese principio llegará a tener problemas de subsistencia. No es ser materialista, ni mucho menos, pero al final de los cantares, o como la llamaría Aristóteles, la causa final de una empresa de software es hacer dinero.  Y, siguiendo con Aristóteles, la causa material sería el software.

Un libro que recomiendo es On The Business of Software de Erick Sink. Muchas de las ideas que presentaré vienen del libro, que también tendrá su post especial….cuando tenga tiempo.

Pero siguiendo con el punto. Así como un martillo existe para martillar, una bicicleta para moverse, una guitarra para tocarla, del mismo modo una empresa existe para hacer dinero. Entonces una empresa de software existe para hacer dinero a través del software que hace.

Tipos o divisiones en las empresas de software hay muchos. Hay empresas que se dedican a hacer sistemas operativos, otras a hacer bases de datos, otras a hacer ERPs, otras para hacer páginas web, otras para integrar distintos sistemas, otras para software bancario, otras de telecomunicaciones, otras para restaurantes, otras hacen software a la medida y un gran etc.

Resumiendo, una empresa de software es una organización dedicada a hacer dinero a través de software. El siguiente punto que se debe definir es ¿qué tipo de software hará la compañía?

En el blog hablaré de mi proyecto, con las restricciones y oportunidades que tengo (el famoso FODA). ¿Haciendo qué tipo de software podré hacer negocio? Para ser realistas por el momento han de desecharse las “grandes ligas”. Es irreal suponer, diseñar y demás, una empresa que se dedique a hacer sistemas operativos, o una competencia a MS Office, a SAP, a Oracle o alguno parecido. No digo que no se pueda, lo que digo es que una empresa pequeña NO debe empezar por ahí.

¿Entonces en donde empezar? Bueno, hay nichos, muchos nichos. Hay que elegir un nicho que sea lo suficientemente pequeño que no interese a los grandes, pero que sea lo suficientemente grande para crear ganancias. Creo que una empresa pequeña será generalmente una evolución de consultorías pequeñas o medianas de software hecho a la medida. Este creo que es un buen punto de partida. Por ello hay que elegir cuidadosamente los proyectos en los que un consultor que desea crear una empresa de software se mete.

A la fecha no sé en que nicho de mercado deseo meterme, pero ya les estaré comunicando cuál. También creo que es importante definir un proyecto e intentar separarse un poco del software a la medida ¿por qué? Porque el retorno de un producto que se vende muchas veces es muchas veces mayor que estar haciendo software a la medida.

En conclusión: una empresa de software pequeña es una organización que se dedica a ganar dinero a través de pequeños proyectos de software, consolidando uno o varios productos de los que puede obtener ganancias en un mercado en el que puede competir.

Claro, esto es una simplificación. Una empresa de software, como cualquier otra empresa, tiene mucho conocimiento, muchos trucos, mucha experiencia que debe adquirir y cultivar. No es sencillo funda una empresa próspera de software: hay muchos riesgos que hay que saber identificar y manejar. Hay metodologías técnicas y administrativas que se tienen que adquirir y refinar. El software es una ciencia-arte y para que una empresa que hace algo así es necesario que se componga de artistas-científicos que la hagan funcionar.

Luis H. Fernandez
luishernan@gmail.com

El término calidad siempre me ha parecido ambiguo. ¿Que hace que un bien o servicio “posea” calidad? No sé. Hay procesos de calidad, chequeos de calidad, y mil cosas con calidad, pero nadie entiende a ciencia cierta qué es calidad, aunque todos comprenden el término. Aunque para algunos es aquel software que no tiene bugs, para otros el que satisface al cliente, para otros es el que optimiza recursos, para otros el que se mira bonito, etc.

Cuando el término entra al contexto del software, la cosa se pone peor. ¿Qué hace que un software sea uno de calidad o no? Claro, debido a lo ambiguo del término, la discusión en este tema no tendrá fin.

Con todo, lo que hacemos es software, y nos gustaría hacer siempre software de calidad. Para poder etiquetar a un software como uno de calidad, debemos definir algunos atributos para poder poner el software en evaluación. Estos atributos, y sus prioridades, cambian cuando cambia el contexto de software: un sistema para hospitales se juzga de una manera distinta a una página web.

En FFSE R. Glass propone siete atributos del software que le confieren lo que llamamos calidad:
+Portabilidad: la portabilidad implica que un programa puede correr en distintas plataformas, no sólo de sistemas operativos sino diferentes versiones, diferentes ambientes y esquemas.
+Fiabilidad o confiabilidad: el software hace lo que debería hacer, y no “truena”.
+Eficiencia: que tanto recursos economiza en tiempo y espacio el software.
+Facilidad de uso: es fácil de usar?
+Evaluable: Es sencillo de examinar? Se le pueden correr fácilmente unit tests?
+Leíble: Es el código expresivo y fácil de comprender?
+Mofificable: Qué tan sencillo es modificar el software.
+Escalibilidad: pueden agregarse funciones de manera rápida y consistente?

Buscando en internet, encontré otros atributos que vale la pena mencionar:

+Compatibilidad: es el software amigable con otros sistemas?
+Seguridad: es el software seguro contra ataques externos?

Todos concordarán que los atributos anteriores son buenos parámetros para medir la calidad de un producto de software. Sin embargo el orden de estos productos varían de proyecto a proyecto. Un proyecto que maneja información confidencial puede que tenga la seguridad muy alta, una página de internet tendrá muy alta la facilidad de uso, un software bancario tomará más en cuenta la fiabilidad que la portabilidad.

El usuario y el código

Al usuario final le viene del norte en qué tecnología corre un programa, o que metodología de desarrollo se utilizó para su creación. Poco le importa si se utilizó un lenguaje de cuarta generación o assembler. El usuario toma por sentado ciertos estándares y cierta funcionalidad. Por ejemplo un usuario espera siempre que en el lugar que aparezca un disquete se grabe su trabajo. Si esto no funciona bien, el usuario tendrá una muy mala percepción del software, y por tanto el software no tendrá mucha calidad.

El otro lado de la moneda es la calidad del código. ¿Es sencillo de encontrar errores? ¿Hay un buen uso del modelo de programación? ¿Se optimiza el uso del hardware? Aquí cada quien tiene un criterio diferente, hay filosofías, metodologías, paradigmas y demás.

Glass expone algo que me llamó mucho la atención: la satisfacción del cliente no es lo mismo que calidad de software. Entre los elementos que evalúa el cliente están cosas como el precio del producto, el diseño, el tiempo de entrega, el soporte y otros. Un mal software puede tener una alta satisfacción (aunque poco probable), y un buen software puede ser mal valuado por el usuario (créanme, sucede). Entonces la política de calidad de la empresa en general es distinta a la política de calidad del software en sí. Pese a muchas opiniones, el software es el código y nada más. Otras cosas le van unidas, pero no son software.

En Pragmatic Programme Hunt y Thomas exponen un punto importante: software lo suficientemente bueno. En ocasiones, especialmente cuando no hay restricciones de calendario, el desarrollador quiere siempre mejorar su software. Irónicamemte un software puede ser siempre mejorado. Hay que aprender cuando un software es lo suficientemnete bueno, porque agregarle funcionalidad o mejoras puede ser hasta contraproducente si no se sabe donde parar. Al final esto es ingeniería de software, y como todas las ingenierías nuestro objetivo es calcular. Si voy a comprar alambre para cercas las plantas de mi casa puedo calcular la circunferencia usando 3 en vez de pi, si voy calcular los materiales necesarios para un edificio redondo seguramente usaré 3.14159 o tal vez más dígitos, y si estoy calculando la órbita de una nave espacial definitivamente usaré más decimales. Hay que saber cual me conviene más. Lo mismo en el software.

Existe un ISO, el 9126 que se dedica a la calidad de software tiene puntos muy interesantes. Especialmente me gustó la división que hacen para medir la calidad: la calidad del modelo, la calidad de la métrica externa, la de la métrica interna y la calidad en el uso de las métricas. Está también CMMI que se dedica a la calidad estandarizar la calidad del software y la calidad del proceso productivo de éste.

En fin la calidad de software es algo que radica entre lo objetivo y lo subjetivo. Hay mucha leña por ahí para partir, porque el universo del software es también dinámico y los parámetros también cambian. Cada equipo de trabajo tiene sus propios parámetros. Lo que quiero recalcar es que cada equipo debe definir cuales son sus parámetros para medir la calidad de su software. Luego modelar, diseñar, implementar y mantener el software apegado a esos claves. En cada proyecto el orden de prioridades cambian también y hay que tenerlo presente, porque al final de los cantares lo que queremos es que nuestro software funcione, le guste al usuario y se acerque lo más ppsible a hacer lo que tiene que hacer.

Luis H. Fernandez
luishernan@gmail.com

Algunos links.

http://synergix.wordpress.com/2008/07/02/modelo-de-calidad-tradicional-del-software/
http://blog.xebia.com/2008/11/05/what-exactly-is-software-quality/
http://en.wikipedia.org/wiki/Software_quality
http://satc.gsfc.nasa.gov/support/STC_APR96/qualtiy/stc_qual.PDF
http://en.wikipedia.org/wiki/ISO_9126
http://www.bth.se/tek/besq.nsf/(WebFiles)/CF1C3230DB425EDCC125706900317C44/$FILE/chapter_1.pdf