Aunque el email es una gran herramienta, en la actualidad hay un “sobre uso” del correo. Para absolutamente todo se hace un nuevo mail. Y en muchas ocasiones, el email no es la mejor herramienta para solucionar los problemas. Quiero aclarar que estoy hablando de proyectos de chicos a medios, proyectos en los que una empresa naciente se involucra. Para proyectos más grandes hay otras herramientas que generalmente se utilizan, que de no utilizarse no sería posible el desarrollo en gran escala.

Este es un tema de manejo de proyectos, asunto sobre el cual quiero dedicarle algunos posts. El manejo de proyectos es uno de los grandes puntos grises del desarrollo de software, y un área que poco interés se suele poner en las empresas. Cada vez más me convenzo de que un buen software está íntimamente ligado a un buen manejo de proyecto.

Pero volviendo al tema, NO ES SENSATO utilizar el mail para todo. Seguro les ha tocado más de una ocasión buscar un documento que enviado por un cliente, que sabe Dios dónde se encuentra en su inbox (o su respectiva carpeta o tag). Y luego de 20 minutos de búsqueda el archivo buscado estaba en un mail con “No Subject” que su cliente envío hace un par de meses. O quieren ver la versión de la especificación en la que se contemplaba x o y característica del producto que ahora ya no está contemplada, o la fecha de entrega, etc.

Y dependiendo del rol que cumplan en el proyecto, la avalancha de mails puede parecerles SPAM. Si ustedes son parte del equipo de ventas, pero están incluídos en el CC (y son uno de los 25 destinatarios de CADA mail del proyecto) le perderán la pista a las cosas importantes. Además cada quien tiene una configuración distinta para responder, y de pronto la “conversación” se vuelve un hilo de mails que pocos entienden.

El email funciona muy bien para muchas cosas, pero cada vez veo más claro que como método de almacenamiento de conocimiento no es una buena herramienta. Como menciono hay herramientas alternativas, software para manejar proyectos, para almacenar documentos, etc. Pronto haré una lista de software disponible para esto. Hay herramientas que almacenan mejor el conocimiento, que lo pueden indexar de distintas maneras, que pueden buscar relaciones, que pueden intentar estructurar el conocimiento, y que no excluyen el email. Hay algunas herramientas que consideran los replys de los mails…y es una gran cosa.

Una lista de razones por las que considero que hay que buscar alternativas al mail para manejar el flujo de información en un proyecto:

• El conocimiento se vuelve, hasta cierto punto restringido. Sólo los destinatarios poseen el conocimiento sobre el proyecto, lo que de principio le reduce la vida. Claro, hay cosas confidenciales, pero hay muchas otras que son del interés común tanto de la empresa proveedora como el cliente.
• Es sumamente complicado de organizar. Aunque ahora existen maneras eficientes de manejar cada correo de entrada, los correos en los que se tratan distintos temas, se vuelven un desafío.
• Mucha información puede volverse ruido. Si todas las mail de un proyecto se van a la carpeta “Proyecto X” de nuestro manejador de correo, de pronto tendremos una carpeta con miles de correos que no nos sirven, a lo más para hacer búsquedas.
• No se escriben buenos mails. Abundan los mail con subjects malos, los mails de más, los mails mal escritos, los mails que no dicen nada, o que dicen algo en mucho, etc. Que es otro tema que algún día tocaremos, cómo y porque escribir buenos mails.

Pero hay un punto importante: mucha de la información sobre el proyecto sale del cliente, y el cliente USA EL EMAIL, y hacerlo utilizar otra herramienta, es prácticamente imposible. Así que la solución que se utilice DEBE usar el mail como interfase. Irónico pero cierto. Intentar que el cliente use “nuestra herramienta” es algo difícil de lograr, así que el mail debe ser utilizado, pero con un nuevo enfoque.

No related posts.

Antes de comenzar con código o parecido, pensemos en este problema. En muchos países se utilizan las espigas redondas en los tomacorrientes, y en otros las espigas planitas. Otras veces nuestro aparato tiene 3 espigas y el tomacorrientes 2. Sin embargo sabemos que el aparato que deseamos conectar “entiende” la corriente eléctrica, “la acepta”, aunque la interfaz para conectarse a ella sea una distinta a la nuestra. ¿Qué hacemos en estos casos? Usamos un adaptador! O un convertidor, o un transformador, cómo le querramos llamar.  Pues lo mismo sucede con el software. A veces hay librerías que nos son útiles pero que para utilizarlas nos teneoms que adaptar a ellas. Tenemos dos opciones: modificar todo nuestro código para que se adapte a la librería, o podemos crear un adaptadro que traduzca lo nuestro a lo de ellos y lo de ellos a lo nuestro. Un ejemplo sencillo en el mundo Java es el de los Enumeration y los Iterators. Ambos tienen un hasNext()  o  un hasMoreElements() que hacen lo mismo; al igual que un next() y un nextElement() que hacen lo mismo. Imaginemos todo lo queremos manejar con Iterators, podemos crear un adaptador que nos “convierta” entre Iterator y Enumeration.

Vamos con el usual ejemplo. Imaginemos tenemos un sistema que maneja coches, barcos, aviones y parecidos. Generalmente los motores que se usan son de gasolina, pero las nuevas tendencias han popularizado los motores eléctricos. Para simplificar mi caso y mostra bien el punto, tenemos que el proveedor de vehículos eléctricos nos provee sus librerías para el motor eléctrico que es prácticamente igual a nuestras implementaciones pero con otros nombres (prender en vez de encender, “mover más rápido” en vez de acelerar, etc.), y tiene una restricción extra: para poder acelerar o detener el motor, este tiene que estar conectado. Y surge el problema ¿cómo hacemos para nuestras librerías puedan hacer uso del motor eléctrico? Podríamos reescribirlas todas, pero el tiempo que eso nos tomaría sería mucho. Además sabemos que existirían problemas que nuestras librerías ya han solucionado.

Como nos gusta ser elegantes en nuestro uso de objetos, hace muchos años creamos una clase abstracta (pensamos también hacer una interfaz, pero la clase abstracta nos provee otros métodos útiles):

package com.guisho.software.patrones.adapter;
public abstract class Motor {
   abstract public void encender();
   abstract public void acelerar();
   abstract public void apagar();
   //...mas metodos que hacen muchas cosas
}

Y tenemos nuestras implementaciones de algunos motores, por ejemplo el motor económico:

package com.guisho.software.patrones.adapter;
 
public class MotorEconomico extends Motor {
 
    public MotorEconomico(){
        super();
        System.out.println("Craendo motor economico");
    }
 
    public void encender() {
        System.out.println("Encendiendo motor economico.");
    }
 
    public void acelerar() {
        System.out.println("Acelerando motor economico.");
    }
 
    public void apagar() {
        System.out.println("Apagando motor economico.");
    }
 
}

Y el motor gastón (que ya no se vende tanto!):

package com.guisho.software.patrones.adapter;
public class MotorGaston extends Motor {
    public MotorGaston(){
        super();
        System.out.println("Creando el motor gaston");
    }
 
    public void encender() {
        System.out.println("Bum, bum....encendiendo motor gaston");
    }
 
    public void acelerar() {
        System.out.println("Buuuuuuuuuuuum, acelerando y gastando muuuucha gas");
    }
 
    public void apagar() {
        System.out.println("Apagando motor gaston");
    }
 
}

Estas clases siempre nos han funcionado bien, y de hecho tienen muchas cosas como servicios, mantenimientos y otros, que usamos gracias a la interfaz motor. Por ejemplo es común que usemos cosas como estás:

        Motor motor = new MotorEconomico();
        motor.encender();
        motor.acelerar();
        motor.apagar();
       //hacer mas cosas....
        motor = new MotorGaston();
        motor.encender();
        motor.acelerar();
        motor.apagar();

Ahora la empresa que construye motores eléctricos nos manda su propia implementación que va así:

public class MotorElectrico {
 
    private boolean conectado = false;
 
    public MotorElectrico() {
        System.out.println("Creando motor electrico");
        this.conectado = false;
    }
 
    public void conectar() {
        System.out.println("Conectando motor eléctrico");
        this.conectado = true;
    }
 
    public void activar() {
        if (!this.conectado) {
            System.out.println("No se puede activar porque no esta conectado el motor electrico");
        } else {
            System.out.println("Esta conectado, activando motor electrico....");
        }
    }
 
    public void moverMasRapido() {
        if (!this.conectado) {
            System.out.println("No se puede mover rapido el motor electrico porque no esta conectado...");
        } else {
            System.out.println("Moviendo mas rapido...aumentando voltaje");
        }
    }
 
    public void detener() {
        if (!this.conectado) {
            System.out.println("No se puede detener motor electrico porque no esta conectado");
        } else {
            System.out.println("Deteniendo motor electrico");
        }
    }
 
    public void desconectar() {
        System.out.println("Desconectando motor electrico...");
        this.conectado = false;
    }
}

Como vemos, este motor hace lo mismo que el nuestro, pero de manera y con llamadas un poco diferentes. ¿Cómo hacemos para integrar este MotorEléctrico al resto de nuestro sistema? Así es, con un adaptador o adapter!
El adapter “envuelve” al objeto extraño (por eso le llaman wrapper también, ya que wrapper viene siendo envoltorio).

Nuestro adaptador se escribiría así:

package com.guisho.software.patrones.adapter;
 
public class MotorElectricoAdapter extends Motor{
    private MotorElectrico motorElectrico;
 
    public MotorElectricoAdapter(){
        super();
        this.motorElectrico = new MotorElectrico();
        System.out.println("Creando motor Electrico adapter");
    }
 
    public void encender() {
        System.out.println("Encendiendo motorElectricoAdapter");
        this.motorElectrico.conectar();
        this.motorElectrico.activar();
    }
 
    public void acelerar() {
        System.out.println("Acelerando motor electrico...");
        this.motorElectrico.moverMasRapido();
    }
 
    public void apagar() {
        System.out.println("Apagando motor electrico");
        this.motorElectrico.detener();
        this.motorElectrico.desconectar();
 
    }
 
}

Como ven el adapter se encarga no solo de corregir los nombres de los métodos, sino también cosas como conectar y desconectar el motor, cosas que a nuestra implementación no le importan. Pero lo más importante es que ahora podemos utilizar esta implemetnación de Motor en nuestro sistema utilizando la implementación de ellos. Por ejemplo podemos hacer cosas como esta:

        Motor motor = new MotorEconomico();
        motor.encender();
        motor.acelerar();
        motor.apagar();
 
        motor = new MotorGaston();
        motor.encender();
        motor.acelerar();
        motor.apagar();
 
        motor = new MotorElectricoAdapter() ;
        motor.encender();
        motor.acelerar();
        motor.apagar();

El patrón adapter aparece en todos lados, aunque muchas veces no se le llama adapter específicamente. Ahora que lo conocemos lo podemos usar en nuevos proyectos, o tal vez puede solucionarlos problemas que resolvimos a medias en algún software por ahí. Como siempre les dejo el código fuente.

Related posts:

1. Prototype Pattern – Patron Prototipo — Patrones de diseño
2. Builder Pattern, Interfaces Fluidas– Patrones de diseño
3. Abstract Factory Pattern – Patrones

5 de enero
Hoy me han llevado al lugar de construcción por primera vez. La situación es perfecta: tiene parada de bus cercana y enfrente hay una cafetería con comida casera. El viejo edificio de apartamentos, al que va a sustituir nuestra nueva construcción, lleva un año al borde de la ruina. Mi propia empresa ha colocado varios puntales que, por el momento, han ido evitando que el caduco edificio reviente por sus múltiples grietas. La construcción de este megalito ladrillo comenzó hace cinco años, y aunque los pisos superiores nunca llegaron a recibir el agua, la electricidad y el enfoscado de las paredes, en diez meses los cimientos ya se habían desplazado peligrosamente y las vigas presentaban peligrosas fisuras. La cansada torre de viviendas ya ha cumplido su propósito y ahora nosotros la conduciremos a una muerte dulce… Por supuesto, el viejo edificio no será demolido hasta después de construir y probar el nuevo, lo que nos deja poco espacio de maniobra; pero no vamos a dejar a todas esas familias en la calle durante la construcción. De cualquier modo, los vecinos de la vieja y decadente estructura nos miran con recelo. Saben que el nuevo edificio tendrá viviendas cómodas, pero algunos de los residentes no podrán costearlas. Ni sé qué va a ser de la gente, ni es asunto mío. Llegan los primeros camiones de ladrillos.

6 de enero
Me han presentado a Matías, la persona a quien “voy a reportar”. No me han dicho si es el capataz, el jefe de obra, el aparejador, o el arquitecto; sólo me han dicho que todo lo que tenga que “reportar” se lo “reporte” a él. Así que, por donde él diga, yo zaca-zaca, como una locomotora. Esa es la definición que me han dado de nuestra metodología. He buscado “reportar” en el diccionario, y no aparece.

10 de febrero
En algo más de un mes, hemos cavado medio metro de cimientos. Ayer Matías nos dijo que empezáramos a poner ladrillos, porque el tiempo designado para la cimentación se había agotado hace dos semanas. No aceptó nuestras excusas de que las prometidas excavadoras aún no habían llegado y que nos habíamos visto obligados a cavar con las paletas de enyesar. Un compañero se trajo un pala de cavar que guardaba de una obra anterior y casi le echan por razones deontológicas. Según Matías, lo que pasa es que frecuentamos demasiado la cafetería. El asunto se ha zanjado con un “hale”, a levantar paredes y luego que cada palo aguante su “vela”. El trabajo sin planos es dificultoso. Los cimientos tienen una forma algo pintoresca. He pedido una plomada para que las paredes queden verticales y he recibido improperios poniendo en duda mi masculinidad. Ya sé que Matías no es el arquitecto, porque el arquitecto es un tal Ignacio. Pasó a supervisar la obra el otro día. Aunque aún no había nada que ver. Me han llegado rumores, aunque no son muy dignos de crédito, de que existen fotocopias de planos.

1 de junio
Anoche estuvimos hasta la siete de la mañana cubriendo con tablas y enmoquetando el espacio que algún día ocupará el despacho de la planta, aunque el edificio no es aún más que una maraña de vigas de todos los tamaños y algunas paredes que habrá que tirar más tarde están en el sitio equivocado. Hemos traído baterías para los fluorescentes y unos muebles de caoba preciosos. Por suerte, todo estuvo a punto para la demo. Izamos al cliente con la grúa hasta su futuro despacho y pudo contemplar la vista que disfrutaría desde el emplazamiento. El viento hizo que la pared oeste, que dos de mis compañeros sujetaban con la espalda, se derrumbara con gran estruendo sobre la mesa de caoba en el peor momento. Gracias a Dios, el cliente fue comprensivo: esto pasa siempre en las demos, y él está curado de espanto, dijo mientras el sacudíamos el polvo del traje. Dice que el lunes que viene vendrá a probar las instalaciones sanitarias. Supliremos con cubos la inexistencia de tuberías.

5 de marzo
Han transcurrido casi catorce meses. Llevamos ya siete de retraso y el edificio no acaba de superar el estado de “casi terminado”. Soy de los pocos albañiles que no ha cambiado de obra en este tiempo. Matías está consumido por la zozobra y se pasa el día en la cafetería trasegando Soberanos. El arquitecto no ha vuelto a pasar por aquí. Los rumores dicen que existieron unos planos, pero no eran de un bloque de pisos, sino de un polideportivo. Por lo visto, en las reuniones del comité de construcción se dijo que la filosofía era la misma y que sólo harían falta modificaciones mínimas. Ahora comprendo por qué nos hicieron instalar aros de baloncesto en el hueco del ascensor. Siempre dije que acabaríamos teniendo que quitarlos o aquello no era un hueco de ascensor, que era cuestión de lógica. Matías siempre me contestaba que no le viniera con tecnicismos. Estoy perdiendo la vocación de constructor. He decidido apuntarme por las tardes a un curso de informática, a ver si puedo cambiar de vida. Este oficio mío no es serio.

No related posts.

El principio establece que, en un entorno informático, la información no debe repetirse. Es decir, el conocimiento almacenado en un programa informático debe mantenerse en un, y sólo en un, lugar. De primas a primeras, el principio parece evidente, pero cuando investigamos algunas piezas de código, incluso las nuestras, nos damos cuenta que constantemente violamos el principio.

Para aclarar el concepto vamos con un ejemplo, harto común, con el que nos topamos constantemente. Supongamos que estamos haciendo una parte de un sistema en el cual se almacenará un catálogo de productos, digamos de frutas. Normalmente lo que haríamos es primero crear la base de datos. En la base de datos se tendrían estos campos: id, código, nombre, precio. En la misma base de datos agregamos ciertas restricciones al producto: el código es único y es una cadena de 10 caracteres, el nombre no puede ir vacío, el precio no pueden ser cero (observemos que incluso los tipos de esos datos radican en la creación de la tabla en la base de datos).

Una vez creada la base de datos, nos dirigimos a nuestro IDE para crear el código que trabajará con esos datos. Los enfoques varían mucho, y las maneras de trabajar con esos datos también. Pero en este caso vamos a trabajar con una capa de persistencia basada en un ORM (Object-Ralational Mapping). En algún lado de la configuración del ORM estableceremos que la tabla fruta se mapeará al objeto Fruta. Que el objeto Fruta tendrá un id, un nombre, un código y un precio.

Con nuestro mapeo funcionando, nos dirigimos a crear nuestro objeto Fruta. Nuestro objeto tendrá un BigInt para el id, tendrá un String para el código, otro para el nombre y un BigDecimal para el precio. Ahora crearemos los métodos de accesos (accessor methods) con su set y su get. Si la capa de persistencia nos echa una mano no tendremos que verificar que el código sea único, pero si no, tendremos que codificarlo nosotros.

Ahora, si somos queremos que nuestro código sea escalable y pueda mantenerse a largo plazo, utilizaremos alguna implementación del patrón MVC (Model-View-Controller, o Modelo-Vista-Controlador). En cada uno pondremos los respectivos campos de la fruta: el id, el código, el nombre y el precio. Haremos un listado de las frutas que hay almacenadas, y una forma para agregar y/o editar entradas.  En la vista le diremos al controlador qué desplegar, y haremos una tabla en el View. El model ya lo implementamos, que es nuestro objeto Fruta. Para la forma haremos lo mismo, pondremos los campos de fruta y lo guardaremos. Para proteger nuestro modelo haremos algunas validaciones del lado del servidor, pero para darle una experiencia interactiva al usuario, también haremos validaciones en el lado del cliente. Usaremos, claro está, uno de esos bonitos frameworks que ahora nos hacen la vida más fácil con javascript. La validación del código único requerirá una llamada de Ajax, y las demás serán simples validaciones con Javascript.

Ahora estamos a punto con el manejo de frutas en el sistema. Tenemos un diseño robusto, altamente escalable, muy legible. Pasamos nuestro trabajo orgullosos a control de calidad. Control de calidad nos informa que el máximo de caracteres de código es 10 y en el javascript del cliente nosotros pusimos 10. Bueno, un teclazo de más a cualquiera le pasa, ¿no?. Pasado un tiempo nos dicen que en el mapeo del ORM no pusimos correctamente el precio, y permitimos que sea vacío. Cosas, la prisa hizo que se nos pasara por alto. Pero pasado todo eso, todo bien.
Pasados unos días, nos mandan un requerimiento del cliente que pide que el código en vez de ser de 10 caracteres va a ser de 15 (cambiaron un par de cosas del negocio), y que hará falta otro código: el código de bodega que será de 20 caracteres y también hará falta el peso unitario, que será un decimal opcional.
En nuestra mente comienza a correr el tedioso proceso que tenemos que realizar: hacer los cambios en la base de datos, hacer los cambios en el mapeo, hacer los cambios en el objeto fruta, hacer los cambios en el controller y en el view para la lista, hacer los cambios en el controller y en el view (que incluye dos validaciones de javascript). Que tedio no????? Además….qué fácil será confundirnos.

A todo esto la documentación estaba ya lista, y habrá que cambiarla, pero por falta de tiempo creemos que se quedará tal y como está.

He aquí lo que nos pasa cuando violamos el principio DRY. El principio DRY establece que la información, o el conocimiento debe estar almacenado en UN SOLO LUGAR, para evitar el tedio de cambiar las cosas en mil lados cuando hacen falta cambios, además de ahorrarnos la tendencia a cometer errores cuando hay que cambiar muchas cosas que significan lo mismo. Analicemos los cambios: agregar un campo y modificar otro. Este conocimiento, en gran parte está almacenado en la base de datos (aunque no todo, por ejemplo en la base de datos no podemos hacer ciertas validaciones para los códigos, o cosas parecidas).

Por eso ideas como las aplicadas por ruby (convención sobre configuración) han sido muy populares últimamente. Grails ofrece también un enfoque bonito. Por ejemplo, si cambio las restricciones en mi setter de fruta, ¿no sería menester que esas restriccinoes se extendieran a todos lados? Agrego un campo en mi clase, agrego pesoUnitario, ¿no se deberían propagar estos cambios a la base de datos, a los controllers, a los views, al javascript, a la documentación? Por ello también soy un fan de la generación de código: permite reducir la redundancia de la información.

Nadie negará la utilidad de patrones como el MVC, o de ideas como el ORM. Pero a veces esas soluciones crean una sobre ingeniería tan grande que no sé si compensan sus soluciones. En nuestros tiempos donde los IDEs son tan poderosos nos deberían ayudar un poco más en este tema. No hablo de herramientas CASE, hablo de un nuevo enfoque de programación. Esperemos en el futuro surjan ideas y solucinoes nuevas (en las que espero ustedes y yo aportemos nuestra parte) para este problema de la constante violación del DRY. Programar debe simplificarse mucho. Hemos desarrollado soluciones a soluciones y cada año hay nuevas propuestas, pero siento lo mismo que hablaba una vez con alguien: estamos haciendo el mango del hacha más bonito, más durable, más ergonómico, más resistente a golpes…cuando lo que deberíamos estar haciendo es diseñando una sierra eléctrica!

No related posts.

Vimos ya los patrones creacionales más importantes. No son todos, en el futuro veremos más, pero son los más usados y los más importantes. Ahora comenzamos con una nueva fase: Los patrones estructurales. Los patrones estructurales (structural patterns) podrían llamarse patrones de relaciones, o algo parecido, porque su principal función es facilitar y mejorar las relaciones entre objetos.

En el mundo de objetos, la creación de instancias es muy importante, pero tan importante como la creación, es la manera en la que instancias de objetos se comunican entre sí. Un diseño estandarizado y bien pensado puede facilitar mucho las cosas durante el desarrollo de un sistema grande. En ocasiones nos ponemos a realizar nuestras soluciones a la medida, pero generalmente estas solucionen decaen en construcciones extrañas que serán difíciles de entender para futuros desarrolladores, e incluso para nosotros mismos una vez que dejemos de ver el código.

Una solución elegante es utilizar inteligentemente patrones estructurales. Pero cuidado, puede ser arma de dos filos. Podemos caer en la tentación de meter patrones en todos lados, incluso cuando no es necesario. Nuestro código puede comenzar a crecer y crecer sin hacer aún nada, bajo la premisa de que todo lo queremos hacer con patrones.

Los patrones son una herramienta de diseño muy poderosa, pero hay que saberla utilizar. El tiempo y la experiencia suelen ser los mejores acompañantes para un diseñador de software, porque sólo el tiempo le dará el colmillo para utilizar sus herramientas adecuadamente. 

Con mucha frecuencia el diseño de un dominio inicia con nociones sumamente intuitivas. Conforme el diseño se va destilando y mejorando, se agregan soluciones específicas de software (como patrones), que lo pueden ir complicando (con el propósito de hacerlo más manejable). Generalmente los patrones estructurales entran en la jugada en etapas medias del diseño, y muchísimas veces son el resultado de refactorización (refactoring). 

  Así que comenzamos con los patrones estructurales. Encendamos motores y preparemos la mente, porque estos patrones son buenos martillos y desatornilladores que podemos meter en nuestra caja de herramientas. Sin dudas algún día nos serán de mucha utilidad en medio de un proyecto, y la gente quedará sorprendida de como resuelves elegantemente los problemas .

Foto por.

Related posts:

1. Patrones de Diseño
2. Builder Pattern, Interfaces Fluidas– Patrones de diseño
3. Patron Adaptador – Pattern Adapter – Patrones de diseño

Una empresa que quiere enfocarse en desarrollos a la medida tiene un modus operandi distinto a una empresa que se dedica a desarrollar un producto. Cada elección tiene sus ventajas, sus desventajas, sus riesgos y sus oportunidades. 

Empresa de desarrollo a la medida. 

Por un lado la empresa que hace desarrollo a la medida tiene un método distinto de mercadeo, y en un 99% de veces harán el desarrollo a la medida para empresas. Un tipo muy común en este tipo de empresas son las que se dedican a hacer páginas web. Cada página es distinta y los requerimientos varían entre proyecto y proyecto. 

Este tipo de empresa depende totalmente de su personal, y con mucha frecuencia los cobros se hacen por hora o por proyecto. Son empresas con niveles de especialización relativamente bajos, pero con capacidades de desarrollo en una gran cantidad de tecnologías. 

Muchas empresas nacen luego de proyectos de outsorsing individuales que redundan finalmente en una empresa dedicada al outsorsing. Las empresas grandes y medianas siempre tienen requerimientos y necesidades nuevas de software, para las cuales simplemente no existen productos porque son tareas demasiado específicas de la empresa. 

La gran ventaja de las empresas que desarrollan a la medida es que CASI siempre habrá trabajo. Con sorprendente frecuencia serán solicitados sus servicios. También invierten relativamente menos en su personal, ya que no hay una curva de aprendizaje aguda para realizar los proyectos, ya que como dijimos, son muy generales. Además siempre habrá efectivo, porque comúnmente los trabajos se pagan en corto tiempo. Claro, si no hay proyectos, habrá problemas. 

La mayor desventaja en este tipo de empresas es que tienen un tope claro: la cantidad de horas disponibles. Por ejemplo si se tienen 10 programadores (y claro, a veces habrá diseñadores, en ciertos casos gerentes de proyecto, etc.) y cada programador trabaja 40 horas semanales, es decir 160 horas mensuales, la empresa no puede ofrecer sus servicios por más de 1600 horas mensuales. Y el precio que cobra por hora por 1600 es su tope de ingresos. 

Empresas que desarrollan un producto. 

Estas son las  empresas que toman la determinación desarrollar uno o varios productos y luego se dedicarán a venderlos. La tarea de ventas y mercadeo es parecida a la de un producto normal. Puden tener un equipo de mercadeo y de ventas que sepa poco de software, pero que conozca bien el producto. 

La principal ventaja de crear un nuevo producto de software es que el límite está bastante menos definido que en el caso de desarrollos a la medida. Una vez desarrollado el producto las ganancias se multiplicarán en cada venta con costos sorprendentemente bajos. El software, a diferencia de todos los demás productos, no tiene ningún costo por reproducirse. Una vez creado el producto, cada copia vendida tiene un costo de cero. 

En ocasiones se requrirán desarrollos a la medida sobre el prodcto base, pero estos desarrollos extras pueden agregarse a nuevas versiones del producto. Además, estos desarrollos podrán ser generados sólo por la empresa, de modo que no hay competencia en cuanto al desarrollo sobre el producto (claro, en casos de productos pequeños y medianos). 

El desarrollar un producto lleva tiempo y especialización. El equipo de trabajo ha de ser muy integrado, y agregar nuevos integrantes al equipo es más costoso, porque cada nuevo elmento debe aprender la manera en la que está hecho el producto, su funcionalidad, los estándares de codificación, etc. Nuevas consideraciones aparecen, como la necesidad de afinar estrategias de manejo de versiones, tiempos de trabajo, arquitectura del sistema, manejo del proyecto, y demás tareas que conyevan la creación de un nuevo producto. 

Y esto desenboca en el mayor riesgo de este tipo de empresas, especialmente en sus inicios, y este es que el producto no tenga aceptación. Cuando esto sucede los meses de trabajo -que son una inversión absorvida por la empresa- poco valieron. Este tiempo que no generó ingresos es tiempo perdido, aparte del costo perdido en pagar salarios, establecimiento, etc. Por eso para las empresas que desean desarrollar un nuevo producto es clave la decisión sobre qué producto desarrollar. En otro artículo se tratará este caso, porque es realmente importante escoger un buen producto. Por esta razón también es aconsejable sacar la primera versión con pocas características en un lapso de tiempo pequeño, para darse una idea sobre la efectividad en ventas del producto desarrollado. 

En algunos casos la idea de productos surge luego de desarrollos a la medida. Tal vez la necesidad de un cliente existe en otros y esto abre la puerta a la posibilidad de desarrollar un producto en base a esa necesidad identificada. Además de que se puede obtener la experiencia en los clientes en los que se desarrolla primero.

En fín, cada enfoque tiene sus colores y tropezones. La opción de desarrollar un producto puede arrojar ganancias más grandes y crecimientos a escala, pero su puesta en práctica es más complicada tanto operativamente como financieramente, pero si se tiene éxito, las recompensas valen la pena. El camino que se elija tomar determinará las posiblidades, el giro, y el futuro de la empresa.

No related posts.

Este patrón es facilito, ya lo veremos. En el caso específico de Java ya se tiene mucho camino ganado, porque Java provee la interaz clonable con el propósito de crear clones en mente. Pero vamos a hacer también una implementación sin usar esta interfaz para comprender completamente la idea detrás del prototipo. La primera manera de implementar este patrón en Java es implementando la interfaz Cloneable. Mas abajo veremos otra forma de implementarlo, que es haciéndolo a mano, con una ventaja extra: en vez de crear referencias a los objetos contenidos, podemos crear objetos nuevos, que en muchos cosas nos puede ser de utilidad. Por ahora veamos un un ejemplo sencillo usando cloneable:

  public class Copiame implements Cloneable {
			Object clone = null;
			try {
				clone = super.clone();
			} catch (CloneNotSupportedException e) {
				e.printStackTrace();
			}
			return clone;
  }

Expliquemos un poco. Clonable es una interfaz vacía, pero para utilizar super.clone() tenemos que implementar cloneable si no quere mos una CloneNoSupportedException. La segunda cosa a considerar es que clone hace una copia de los valores de los campos de un objeto, no de los objetos a los que apunta. En otras palabras, el objeto clonado apuntará a los mismos objetos que el objeto antiguo apuntaba. Otra cosa a tomar en cuenta es que clone() devuelve siempre un Object. También notemos que clone es un método protected que puede ser llamado solo por la misma clase o el paquete que la contiene.

Entonces, ¿para qué nos sirve clonar objetos? Bueno, nos sirve para copiar objetos que tardan mucho en crear, o que son complejos de crear. Por ejemplo una lista grande que es costoso en tiempo obtener y que se desea ordenar de dos maneras distintas.

De nuevo nos adentraremos con un ejemplo, que sigo pensando es la mejor manera de aprender. Para nuestro ejemplo vamos a hacer una clase Persona y luego llenar la persona con los datos de dos hermanos: Juan y María que serán ingresados a un sistema x.

package com.guisho.software.patrones.prototype;
 
/**
 *
 * @author guisho.com, luishernan@gmail.com
 */
public class Persona implements Cloneable{
 
    public String nombres;
    public String appellidos;
    public String nombrePadre;
    public String nombreMadre;
    public String direccion;
    public String telCasa;
    public String nacionalidad;
    public String ciudadEnQueVive;
    public String nombreMascota;
 
    public Persona(){
 
    }
 
/*Setters y geters....*/
 
}

Y un cliente que crea la Persona:

    public static void main(String[] args) {
        Persona juan = new Persona();
        juan.setNombres("Juan José");
        juan.setAppellidos("Pérez Ramirez");
        juan.setNombrePadre("Juan Pérez Martinez");
        juan.setNombreMadre("María Ramirez");
        juan.setDireccion("9a. Ave. 43-12 Z.1");
        juan.setTelCasa("34567890");
        juan.setNacionalidad("Guatemalteca");
        juan.setCiudadEnQueVive("Guatemala");
        juan.setNombreMascota("Pepito");
 
        //Hacer algo con Juan, ingresarlo al sistema, etc...
        System.out.println("Ingresando al sistema :"+juan.toString());
 
        Persona maria = (Persona)juan.clone();
 
        maria.setNombres("María Inés");
        System.out.println("Ingresando al sistema :"+maria.toString());
 
        //ingresar a Maria al sistema....
 
    }

Como vemos, ahora no se tuvieron que ingresar todos los campos de María sino, solo aquellos que la diferenciaban de su hermano Juan. Hay que recordar que si hubiesen objetos en el ejemplo estos se clonan por referencia, es decir las referencias de ambos objetos son las mismas. Ahora vamos a vamos a implementar la clonación a mano. Le vamos a añadir a Persona este método:

    public Persona creaPrototipo(){
        Persona p = new Persona();
        p.setNombres(this.nombres);
        p.setAppellidos(this.appellidos);
        p.setNombrePadre(this.nombrePadre);
        p.setNombreMadre(this.nombreMadre);
        p.setDireccion(this.direccion);
        p.setTelCasa(this.telCasa);
        p.setNacionalidad(this.nacionalidad);
        p.setCiudadEnQueVive(this.ciudadEnQueVive);
        p.setNombreMascota(this.nombreMascota);
        System.out.println("Creado prototipo de Persona");
        return p;
    }

Entonces en el cliente podemos hacer esta llamada

        Persona maria = juan.creaPrototipo();

Como vemos, el patrón prototipo es sencillo: crear una copia de un objeto para ahorrarnos los pasos de su creación, o para optimizar accesos o procesos que ya se hicieron en un objeto similar y crear una copia del objeto ya con esos datos ingresados. Como siempre les dejo aquí el código para que jueguen..

Related posts:

1. Patron Adaptador – Pattern Adapter – Patrones de diseño
2. Singleton Pattern — Patrones de diseño
3. Builder Pattern, Interfaces Fluidas– Patrones de diseño

Si estás pensando en poner, o ya tienes, una empresa de software, tendrás que aprender un poco de marketing, mercadeo y todas esas otras ciencias ocultas que siempre viste de menos y consideras superfluas y no dignas de tu valioso y hermoso tiempo. Pero si quieres que tu empresa salga adelante, has de enamorarte (o al menos hacer que te gusta) del marketing.

En estos posts estaré tocando con cierta frecuencia el tema del marketing, porque a nosotros los tecnólogos geeks no nos gusta, no se nos hace necesario y hasta vemos de menos aquellos que lo practican. Pero tienes que tener en mente esto: si quieres hacer una empresa existosa, te conviene saber de marketing. Tu empresa puede no hacer buenos productos y mercadearse bien, y seguirá viva. Pero si hace excelentes productos que nadie conoce (o que a nadie le sirven!) estarás en problemas. Claro si haces malos productos y nadie los conoce ya sabes el destino .

El marketing te servirá tanto como si quieres hacer una empresa de 1000 personas con ventas millonarias al año, como si quieres poner tu pequeño estudio de freelancing en tu hogar y ganar lo suficiente para mantenerte y para tus chicles. Es vital para tu empresa, sea de uno o de mil, que venda. Y si lo que quieres vender es software tienes que aprender a hacerlo. Pronto te darás cuenta que lo más difícil es vender – y que – al final de los cantares el mundo del software s un mundo de ventas. 

Así que nada de hacerle caras feas al marketing y vete a comprar un par de buenos libros para devorarlos. Aquí iremos también compratiendo experiencias y dándote consejos para que vayas teniendo una guía. 

P.D. Acabo de buscar y “marketing” es considerado como correcto (aunque anglicismo) por la RAE.

No related posts.

El builder pattern, o patrón de construcción, es uno más de los patrones creacionales de diseño. En términos generales un builder esconde los detalles de la creación de un objeto final que se llama producto. Hay varios métodos para lograr esto, y por ello hay varias “implementaciones” de este patrón que en nada coinciden , salvo en el nombre. El clásico, usado en el GoF es un poco más complejo del que vamos a ver ahora, pero no se asusten, ya tendremos la oportunidad de aprenderlo. En esta ocasión nos vamos a enfocar en un builder que se llaman interfaces fluídas (fluid interfaces).

Y seguimos con la política de que la mejor manera de entender, y de aprender, es con un ejemplo. Estuve dándole vueltas a un buen caso para ejemplificar y se me ocurrió este: supongamos que vamos a hacer un programa para una empresa que ofrece servicios de web hosting (alojamiento en web). Esta empresa tiene varios planes que ofrecer: tiene un plan personal, un plan bronce, uno plata, uno oro y finalmente el diamante. El personal ofrece un alojamiento de 10MB, una transferencia mensual de 100MB, una cuenta de correo electrónico y nada más. El bronce ofrece 100MB de alojamiento, 1000MB de transferencia mensual, 10 cuentas de correo electrónico. Así sucesivamente cada plan aumenta las cantidades de alojamiento, transferencia y cuentas de correo. A la cada plan agrega nuevas características. El plata ofrece acceso ssh, y una base de datos; el oro agrega estadísticas de sitio y panel de control. Así se van multiplicando las opciones, y para crear la aplicación definimos nuestro objeto que queda así:

package com.guisho.software.patrones.builder;
 
import java.math.BigDecimal;
 
/**
 *
 * @author guisho.com, luishernan@gmail.com
 */
public class PaqueteDeHosting {
 
    /*Los siguientes campos son obligatorios siempre*/
    private String nombre;
    private BigDecimal precioAnual;
    private int capacidadDeAlmacenamiento; //en MB
    private int transferenciaMensual; //en MB
    private int cantidadDireccionesCorreo;//
 
    /*Las siguientes son opcionales, hay planes que no los tienen*/
    private int cantidadSitiosPermitidos;
    private int cantidadBaseDeDatos;
    private String codigoOferta;
    private boolean accesoSsh;
    private boolean panelDeControl;
    private boolean estadisticasDeSitio;
    private boolean ipPublica;
 
    public PaqueteDeHosting(){
 
    }
 
    /* mas constructores */
    /* Setters, getters y demás código....*/
}

Bien, ahora cada plan tiene una configuración previamente establecida, que el vendedor no arma en el momento, y que preferiblemente no puede cambiar. ¿Cómo hacemos para crear cada objeto? La primera manera que se nos ocurrirá es crear un constructor pada cada caso, manteniendo siempre los valores obligatorios. Tendríamos una colección de constructores como la siguiente:

    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos) {
        this.nombre = nombre;
        this.precioAnual = precioAnual;
        this.capacidadDeAlmacenamiento = almacenamiento;
        this.transferenciaMensual = transferencia;
        this.cantidadDireccionesCorreo = cantidadCorreos;
    }
 
    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos, int basesDatos) {
        this.nombre = nombre;
        this.precioAnual = precioAnual;
        this.capacidadDeAlmacenamiento = almacenamiento;
        this.transferenciaMensual = transferencia;
        this.cantidadDireccionesCorreo = cantidadCorreos;
        this.cantidadBaseDeDatos = basesDatos;
    }
 
    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos, String ipPublica) {
        this.nombre = nombre;
        this.precioAnual = precioAnual;
        this.capacidadDeAlmacenamiento = almacenamiento;
        this.transferenciaMensual = transferencia;
        this.cantidadDireccionesCorreo = cantidadCorreos;
        this.ipPublica = ipPublica;
    }
 
    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos, String ipPublica,int basesDatos){
        this.nombre=nombre;
        this.precioAnual=precioAnual;
        this.capacidadDeAlmacenamiento=almacenamiento;
        this.transferenciaMensual=transferencia;
        this.cantidadDireccionesCorreo=cantidadCorreos;
        this.ipPublica=ipPublica;
        this.cantidadBaseDeDatos=basesDatos;
    }
....

Como vemos solo hicimos un par de combinaciones con la cantidad de bases de datos y la ip pública. Mientras la cantidad de campos opcionales crece, la cantidad de constructores aumenta desmedidamente creando el ambiente ideal para que aparezcan errores.

Otro camino que se puede tomar es el clásico bean: un constructor vacío y setters para cada parámetro que deseamos agregar. Este método tiene un pequeño inconveniente: podemos dejar al objeto en un estado incosistente: podemos ponerle cuántas cuentas de correo pero no ponerle nombre, ni ponerle precio. ¿Qué hacemos entonces? Hacemos un Builder!! El builder se explicará por el solo. Veamos:

En PaqueteDeHosting hacemos un constructor con los campos que siempre van para evitar estados inconsistentes:

    public PaqueteDeHosting(String nombre, BigDecimal precioAnual, int almacenamiento, int transferencia, int cantidadCorreos) {
        this.nombre = nombre;
        this.precioAnual = precioAnual;
        this.capacidadDeAlmacenamiento = almacenamiento;
        this.transferenciaMensual = transferencia;
        this.cantidadDireccionesCorreo = cantidadCorreos;
    }

Y creamos el builder

package com.guisho.software.patrones.builder;
 
import java.math.BigDecimal;
 
/**
 *
 * @author guisho.com, luishernan@gmail.com
 */
public class PaqueteDeHostingBuilder {
    private  PaqueteDeHosting paquete;
 
    public PaqueteDeHostingBuilder(String nombre, BigDecimal precio, int cantidadAlmacenamiento, int transferenciaMesual, int cantidadCorreo){
        this.paquete.setNombre(nombre);
        this.paquete.setPrecioAnual(precio);
        this.paquete.setCapacidadDeAlmacenamiento(cantidadAlmacenamiento);
        this.paquete.setTransferenciaMensual(transferenciaMesual);
        this.paquete.setCantidadDireccionesCorreo(cantidadCorreo);
    }
 
    public PaqueteDeHostingBuilder catidadSitiosPermitidos (int cantidad){
        this.paquete.setCantidadSitiosPermitidos(cantidad);
        return this;
    }
 
    public PaqueteDeHostingBuilder cantidadBaseDeDatos (int cantidad){
        this.paquete.setCantidadBaseDeDatos(cantidad);
        return this;
    }
 
    public PaqueteDeHostingBuilder accessoSsh(boolean acceso){
        this.paquete.setAccesoSsh(acceso);
        return this;
    }
 
    public PaqueteDeHostingBuilder panelControl (boolean panel){
        this.paquete.setPanelDeControl(panel);
        return this;
    }
 
    public PaqueteDeHostingBuilder codigoOferta(String codigo){
        this.paquete.setCodigoOferta(codigo);
        return this;
    }
 
    public PaqueteDeHostingBuilder ipPublica (String ip){
        this.paquete.setIpPublica(ip);
        return this;
    }
 
}

Si lo analizamos el builder simplemente envuelve al objeto que creará, con una especie de métodos de acceso (parecido a un JavaBean) pero con la peculiaridad que se devuelve a sí mismo siempre. ¿En qué nos ayuda esto? Miremos el cliente como crea un Paquete ahora:

    public static void main(String[] args) {
 
        PaqueteDeHosting personal = new PaqueteDeHostingBuilder("personal",new BigDecimal(100),10,100,1).build();
        PaqueteDeHosting bronce =
        new PaqueteDeHostingBuilder("bronce",new BigDecimal(200),100,1000,10).accessoSsh(true).build();
        PaqueteDeHosting plata =
        new PaqueteDeHostingBuilder("plata",new BigDecimal(300),100,1000,50).accessoSsh(true).catidadSitiosPermitidos(10).cantidadBaseDeDatos(1).build();
        PaqueteDeHosting oro =
        new PaqueteDeHostingBuilder("oro",new BigDecimal(500),100,4000,100).accessoSsh(true).catidadSitiosPermitidos(100).cantidadBaseDeDatos(5).ipPublica("10.10.10.10").build();
 
    }

Como vemos esto es mucho más sencillo de leer (aparte que la línea se alarga un poco, podríamos hacer varias líneas), y deja al objeto siempre en un estado consistente. Este método de construcción por medio de llamadas encadenadas se llama interfaces fluídas, y es el punto de inicio para muchos lenguajes como Groovy, que crean construcciones bastantes complejas a partir de Builders sencillos que permiten muchas configuraciones.

De nuevo, este no es el Builder de GoF, que veremos en otra ocasión, pero es otro concepto de Builder. Tiene la ventaja que es fácil de entender y de implementar. Imagino que ya se les ocurrió varias maneras de implementarlo en su código actual, así que manos a la obra y a dejar bonito el código! Finalmente les dejo el código fuente de los ejemplos aquí.

Related posts:

1. Singleton Pattern — Patrones de diseño
2. Patron Adaptador – Pattern Adapter – Patrones de diseño
3. Abstract Factory Pattern – Patrones

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).

Related posts:

1. Builder Pattern, Interfaces Fluidas– Patrones de diseño
2. Patron Adaptador – Pattern Adapter – Patrones de diseño
3. Factory Pattern – Patrones

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.

Related posts:

1. Factory Pattern – Patrones
2. Builder Pattern, Interfaces Fluidas– Patrones de diseño
3. Singleton Pattern — Patrones de diseño

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.

Related posts:

1. Abstract Factory Pattern – Patrones
2. Singleton Pattern — Patrones de diseño
3. Builder Pattern, Interfaces Fluidas– Patrones de diseño

• ¿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.

No related posts.

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. 

Related posts:

1. Patrones estructurales (structural patterns)
2. Patron Adaptador – Pattern Adapter – Patrones de diseño
3. Builder Pattern, Interfaces Fluidas– Patrones de diseño

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.

No related posts.

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.

No related posts.

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

No related posts.

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

No related posts.

Hay un nuevo proyecto que deseo comenzar. Es sumamente agradable poder elegir la tecnología a usar, pero a la vez puede causar un gran dolor de cabeza debido a la gran, inmensa, gigantesca, cantidad de opciones que se abren. ¿Qué tecnología uso? ¿Web o no web? ¿Java, C++ o .net? ¿Qué DBMS?

Cuando un cliente pone las reglas, el rango de acción disminuye: nosotros trabajamos IIS en Windows, o nosotros MySQL en Linux, con PHP, o nosotros una opción barata de hosting, y un gran etc. Pero cuando pensamos en desarrollar un nuevo producto ¿qué tecnología usar?

En principio, debido a mi experiencia anterior y mi área de conocimiento, siempre tiendo a ver todas las soluciones bajo la lupa  web. Creo que en un futuro no muy lejano las aplicaciones de desktop irán desapareciendo. Hace más de diez años teníamos ya los applets, y es irónico como las nuevas tecnologías comienzan a tener ese punto de vista.

Hay aplicaciones que son de naturaleza web, y tendrían poco sentido hacerlas desktop, por ejemplo las redes sociales, buscadores, sitios de noticias, etc. Hay aplicaciones que son de naturaleza desktop y que no tendría sentido volverlas web: compiladores, aplicaciones de oficinas, IDEs, etc. Sin embargo las cosas han cambiado y muchas de estas aplicaciones están migrando al mundo web. Hay una intersección cada vez mayor entre las aplicaciones web y las desktop.

Web o desktop. La mayor parte de aplicaciones empresariales (tema para otro post) pueden perfectamente ser desarrolladas en ambas tecnologías, con las ventajas y desventajas de cada una. A mi opinión la decisión en cuánto al enfoque que se debe tomar depende de dos cosas: costo y tiempo.

Creo que una aplicación desarrollada bajo el paradigma web o bajo el paradigma de escritorio debería poder ser compilada o “deployada” en cualquiera de los dos contextos. Todavía no he encontrado muy asentado este concepto pero creo que debería comenzar a predominar. Pero el mundo no es color de rosa, y las cosas no funcionan así.

Hay ya muchos frameworks que permiten programar aplicaciones web como si fueran de escritorio (Wicket por ejemplo), pero todavía están un poco verdes en su desarrollo. Cada aplicación tiene un contexto definido y unas restricciones que deben respetar, pero considero que es mejor idea hacer las aplicaciones web, aunque al decirlo todavía hay algo que siento no me deja aconsejarlo tranquilamente.

Ventajas de web.
+Multiplataforma para el cliente.
+No hay necesidad de actualizaciones.
+Centralizado.

Ventajas de escritorio.
+El usuario está más acostumbrado.
+No se necesita un server.
+Aplicaciones muy pesadas deben correr en el cliente.

Luis H. Fernandez
luishernan@gmail.com

No related posts.

De las buenas prácticas de desarrollo de software que quiero sacar a discusión, comenzaré con el manejo de fuentes. Sorprendentemente el manejo de fuentes y de versiones no se toma tan en serio como debería. Muchas veces he estado en proyectos, o los he visto, en los que muchos, muchísimos problemas surgen debido a espaguetis de código mal unidos, versiones que se creían diferentes, trabajo que se pierde.

Sobre la teoría del manejo de versiones se ha hablado mucho ya. No es algo sencillo en lo más mínimo, a mí me sigue asombrando lo eficientes que SVN o CVS son a pesar de lo complejo de su funcionamiento. Muchos buenos manuales existen para aprender a usar SVN o CVS. Yo en general me iría con alguno de ellos dos, aunque a la gente del entorno MS le podría servir más aprender sourcesafe.

Independientemente, mi punto es el siguiente: SIEMPRE hay que usar algún manejador de versiones. Es la primera cosa que un proyecto serio requiere. Es algo que ni siquiera debe ser apuntado, sino que siempre entendido que habrá un manejo de versiones.

¿Por qué? En lo personal las siguientes razones son los motivos por los qué uso un manejador de veriones.
+Backup. Son una manera muy sencilla para hacer copias de respaldo. Aunque sea una diaria.
+Cambios. Cuando quiero hacer un cambio peligroso, me quita el miedo de pasarme llevando algo por delante. Si eso pasara, simplemente vuelvo a una versión anterior.
+Manejo de versiones en sí. Un cliente quiere unas cosas, el otro otras, pero la base es la misma. Puedo mantener las fuentes exactas de cada instalación, añadir nuevas cosas y luego unirlas. Es una maravilla.
+Trabajo en equipo. El manejo de una manejador de versiones facilita enormemente el trabajo en equipo. Al final del día siempre hay una versión, igual para todos, y los cambios de cada uno los ve el otro. OJO un error común es es tratar al manejador como el que solucionará todos los problemas y no es cierto. La comunicación entre el equipo es siempre vital.
+Es sencillo. Cualquier IDE te permite importar tus fuentes a un repositorio y trabajar a partir de él sin mucho trabajo, incluso si estás comenzando a usar una manejador.

En resumen, en cualquier proyecto lo primero que deben hacer SIEMPRE es utilizar una manejador de versiones. Mis consejos son utlizar SVN o CVS, son sencillos, son libres, la mayoría de IDEs tiene extensiones para ellos y sobre todo les van a hacer la vida más sencilla.

Luis H. Fernández
luishernan@gmail.com

No related posts.

De hecho creo que la comunidad Java debía proponer un JSR pronto para la organización de proyectos en los IDEs, de tal manera que al crear un proyecto en netbeans, lo pueda abrir en eclipse, intelliJ, JDeveloper, o cualquier otro que se ponga enfrente, creo que sería de mucha utlidad.

luishernan@gmail.com

No related posts.

Y no sólo las palabras claves se escriben en inglés. Los foros, las comunidades se construyen en inglés. Las documentaciones y los bugs, todo se hace en inglés. Cuando nos topamos con algún problema extraño, llegaremos con foros en los que muchas veces ninguno de los participantes habla inglés como lengua materna, pero todos hablan inglés para intercomunicarse. Me causa gracia cuando en un foro me comunico con personas de Irlanda, India, Brasil, Rumania, México, Alemania, Rusia y etc. Me asobmra que todos nos podamos comunicar. De no existir el inglés simplemente no habría un medio de comunicación. Cuando busco un software nuevo, o alguna herramienta por ahí, espero que la página esté en inglés. Incluso cuando la página tiene una versión española, prefiero batirme con la que está escrita en la lengua de shakespeare. Sin duda el inglés permite la existencia y el crecimiento de una comunidad muy grande de desarrolladores.

Pero hablar español nos cuesta plata. Hacer programas en español nos cuesta más plata y tiempo que hacerlos en inglés. Usar ñ,á,é,í,ó,ú,ü,¿,¡ y alguno que otro por ahí es sumamente caro. Nuestro idioma tiene poco o ninguna influencia en el mundo del software. Tanto así que la misma palabra “software” la tuvimos que traer del inglés tal y como estaba. Sí, el inglés nos ayuda a aprender, pero nuestras aplicaciones las escribimos en español. Y eso no siempre es tan sencillo como parece.  Muchos de los que leen estas letras sin duda han tenido más de alguna rabieta cuando ven que en su software aparecen í,á�,é,à y otro buen montón de simbolitos raros. O cuando uno tiene que hacer maravillas para hacer que funcione una base de datos con encoding latin-1, un server con ISO-8859-1 y una aplicación con UTF-8. Alguien, con un toque de sátira, dijo una vez “lo bueno de los estándares es que hay muchos”. Más de alguno se ha puesto a llorar cuando hace un pequeño cambio y ve que cambia al charset que. Todos estamos acostumbrados a términos de charset, asdfasd, asdfasd.

En lo personal intento tratar de usar siempre UTF8, pero no siempre es posible debido a que en ocasiones no tengo el control sobre la plataforma en la que instalaré. Este es el primer post sobre el español y el inglés que haré. Hay muchos libros y muchos lugares en los que se puede obtener información sobre como hacer mejor software, pero esos siempre son en inglés (ironías), así que pienso comenzar la discusión para aquellos que hablamos español….¿cómo podemos mejorar el software en español? Lo gracioso es que siempre estaremos escribiendo aplicaciones en español definiéndolas en inglés.

No related posts.

Creo que el desarrollo de software sufre un estancamiento severo. Hemos desarrollado nuevas e interesantes técnicas, modelos de manejo de datos, metodologías de desarrollo, y un sin fin de formas para hacer las cosas. La nuestra es una tarea altamente intelectual y hemos estado viendo como hacernos la vida más sencilla.

Sin embargo los tiempos y costos de desarrollo permanecen iguales, sino es que han crecido más. El estallido de GUIs con mucho entorno gráfico han añadido dificultad a nuestra tarea. El desarrollo en web se ha tornado altamente dominante, y los usuarios esperan webs bonitas, pero a nosotros, por lo general, no nos gusta hacer cosas bonitas, nos gusta hacer cosas que funcionen. Han aparecido los diseñadores gráficos, cosa que no es mala en sí, pero no han aparecido formas de lograr una simbiosis entre programadores y diseñadores gráficos.

Todos aprendemos nuevas tecnologías y frameworks constantemente. Aparecen, y queremos usarlos. Algunas de estas ideas fructifican y se convierten en estándares de facto. Muchas otras crean un gran alboroto pero terminan quedando en lo que algunos llaman shelfware, es decir en la librera guardados y considerados como ideas interesantes pero que no aplican.

Finalmente, creo que el software es una gran oportunidad de desarrollo para Latinoamérica. La inversión en software es relativamente pequeña: una computadora y alguien que sepa usarla. No se precisan de multimilonarias fábricas ni materias primas. Necesitamos personas educadas que sepan manejar y crear y software. Siempre me he preguntado: ¿por qué de los miles de frameworks que aparecen, hay tan pocos latinoamericanos? Y cuando de casualidad me encuentro con uno de origen latinoamericano, generalmente es brasileño. Este blog tambien quiero que sea una invitación, que lance una espinita, para que desarrolladores hispanos nos pongamos las pilas y creemos. Tenemos la capacidad, aunque nos hemos dormido.

Así que bienvenidos, ojalá aparezca pronto la crítica y las ideas. El nuestro es un mundo precioso, así que démosle un toque con ñ.

No related posts.