Leo Barrientos :: Software Business

Buscando Grupo Scout en Providencia.

2008-10-25T13:46:00.000-07:00

Sigo buscando un Grupo Scout en Providencia donde pueda volver al movimiento como dirigente, actividad que abandoné por razones de estudio hace 4 años y quiero retomar.

Hoy he ido al grupo Carmen MacPhee a preguntar y me dijeron que no hay cupos como dirigente y que sólo aceptan gente del colegio [... plop], lo cual me pareció raro, a todo esto no oí ni el ruido típico de una enérgica tropa o una manada familia feliz.

Sigo buscando, ahora creo pasaré a la de Nuestra Señora de la Divina Providencia, a ver que tal.

Si alguien sabe de un grupo Scout por acá en Providencia avísenme en los comentarios, se agradece.

Open Sistemas Chile y Appfuse

2008-10-09T12:38:00.000-07:00

Hola, Appfuse es un maravilloso framework Java para aplicaciones WEB y con el cual se hacen aplicaciones profesionales enterprise usando algunas de las mejores tecnologías y herramientas conocidas en el mundo de la ingeniería de software.

Acá el Link donde pueden encontrarnos como proveedores de servicios Appfuse en Chile, en especial Spring con Hibernate. Si necesitas soporte con appfuse escribe a chile[at]opensistemas.com

También somos especialistas en Symfony en PHP5.

Saludos.

Open Sistemas en Chile

2008-09-30T17:38:00.000-07:00

Hola a todos, anuncio que Open Sistemas ya está en Santiago de Chile - Luego de algunos años trabajando en España y con mi máster de ingeniería de software bajo el brazo estoy de regreso junto a Pamela Castro.

Ya estamos ofreciendo servicios de desarrollo y asesoría en Ing de software (Más info en www.opensistemas.com) así que pida su información a chile@opensistemas.com

La info oficial de la franquicia aquí: http://www.opensistemas.com/prensa/noticias/muestra_noticia/period/1222735282/article/26/306/

Va a ir todo excelente y esta primera semana ha sido muy interesante por Santiago. Un poco de marketing viral y de referencias si que nos ayudaría por parte de ustedes.

Probando Flock

2008-08-17T14:58:00.001-07:00

Hola, estoy probando el editor del navegador Flock, basado en firefox.

Blogged with the Flock Browser

Presentación UPM

2008-03-31T12:06:00.000-07:00

Aceptando un invitación de Nelson Medinilla quien es mi tutor de tésis de Master[1], el día Viernes 28 de Abril he realizado una presentación sobre mi experiencia en desarrollo de software. El objetivo de dicha presentación fue intentar responder algunas dudas que tenemos cuando estudiamos la carrera de informática.

Para mi fue una experiencia muy enriquecedora y agradezco a todos los que participaron en ella, en especial a Nelson y Xavi por hacer de esta una tarde muy interesante de ingeniería de software.

A continuación los archivos de esa presentación: PPT - Diagrama de Casos de Uso EventNet.

[1] Nelson ha escrito este Paper muy interesante.

No más sistemas de información administrativa

2008-03-26T18:09:00.000-07:00

La maldición de dirigir proyectos sistemas de información administrativos (Un crear/editar/borrar/mostrar por aquí, otro por aquí) ya me han reventado el cerebro, es que el software se ensucia si no se usa con elegancia y no es elegante hacer una aplicación donde sea básicamente un front-end de un medio persistente (Mountains Gandalf! Mountains Gandalf!).

Si bien estos últimos 2 años han sido una curva exponencial de power empezando por typo3, symfony, spring y próximamente grails, creo que debo dejar de programar que me estoy desencantando y dedicar mi tiempo libre a programar juegos. He estado buscando un juego tipo Commandos 2 para participar en el proyecto aplicando patrones y cosas interesantes y desafiantes y que por favor no sea un SIA (nada de crear/editar/borrar/mostrar nada, ni una pistola!), pero no encuentro así que mejor pido ayuda a quien lea.

Apropósito esto debe ser una especie de crisis recurrente en la gente que nos dedicamos a este tema, me gustaría saber de otros casos.

Pues este ha sido mi post a las 2:23 de la mañana imprimiendo tésis de master que espero entregar este mes y poder dedicarme a otra cosa por las tardes luego de OpenSistemas.

Saludos!

Respuestas que me gustaría dar, pero no puedo - Escenario 1

2008-02-16T16:13:00.001-08:00

mysql_connect("localhost", "root");
//Consultas aqui
//Un poco de html por aqui....

Respuesta deseada: ¿Are you from the past? (Ver The IT Crowd).
Respuesta correcta: Hay varios ORM para php, debes utilizar capa de persistencia como Doctrine o Propel. Además puedes usar un framework de desarrollo llamado Symfony que integra todo y mucho más.

Appfuse y el talón de Aquiles del desarrollo de Software.

2008-02-16T14:44:00.000-08:00

En esta entrada hablaré de un libro de historia interesante y de mi experiencia con Appfuse (www.appfuse.org) y como aquel libro de historia me ha hecho reflexionar.

He terminado recientemente de leer "El Economista camuflado", libro que ha vuelto a despertar en mí la sensación de tener muchas ganas de aprender leyendo de cosas que no tengan que ver con software - sensación que no experimentaba desde "El último Catón" [Matilde Asensi]. En el intertanto han pasado varios libros de software que recomiendo ferviéntemente: "The pragmatic programmer" y la serie de los libros "Head First", en especial el de patrones de diseño.

Comentaba que he terminado de leer "El economista camuflado" por que a continuación de dicho libro he comprado otro que me ha parecido muy interesante, su nombre es "El talón de Aquíles" [Cesar Vidal] y cuenta sobre cuales han sido las debilidades de personajes de la historia que los han hecho sumirse en grandes derrotas - todo gracias a su talón de Aquíles. Interesantes antecedentes históricos que me hicieron pensar en cuál es el talón de Aquíles de nosotros los ingenieros de software.

Hablar de cuales son las debilidades que padecemos los ingenieros de software puede tomar bastantes horas, incluso hay asignaturas completas que rezan sobre las causas de la crisis del software, o de porqué el software carece de una visión industrial desde su concepción. Desde mi punto de vista creo que el talón de Aquiles de esta profesión es que carece desde un principio de la conexión entre la teoría y la práctica, ¿Cuántos profesores han hecho un mapping de persistencia con Hibernate?, ¿Un paginador?, ¿Han validado la vista W3C?, ¿Una estrategia de búsqueda?, ¿Objetos en caché? salvo casos destacados. Así pues nos vemos enfrentados a un mundo de clientes que esperan resultados concretos - no podemos responder a las tareas de un proyecto con ejercicios mentales.

Desde algunos años existen Frameworks de desarrollo de software que vienen precisamente a aportar lo industrial pues orquestan las piezas de una aplicación aportando los mecanismos necesarios para que todo funcione apropiadamente y obviamente reutilizando bibliotecas usadas millones de veces a lo largo y ancho del mundo. A pesar de todos estos beneficios me impresiona la cantidad de personas ligadas al mundo del software que conoce muy poco de estos temas; personalmente fuí muy ignorante de esto hasta que aprendí Ruby On Rails hace un par de años.

Existen frameworks para todos los gustos y tecnologías, de los que he utilizado y/o visto puedo hablar con propiedad de dos de ellos: Symfony para php5 y Spring para Java. En el encabezado de este post señalaba que hablaría de Appfuse, pues bien Appfuse (www.appfuse.org) es un organizador de distintas herramientas utilizadas para construir software con java; en términos concretos puedes elegir un arquetipo de appfuse y en un par de minutos tendrás configuradas tus herramientas favoritas listas para comenzar a desarrollar tu aplicación.

La configuración de appfuse que utilizo es Spring + Hibernate, a continuación les doy 6 razones para desarrollar software con Appfuse:

Gestión de usuarios: Desde el momento de la primera ejecución appfuse provée un sistema de gestión de usuarios que incluye login, creación, roles, recuperar contraseñas. En fin todo lo que nos demandaba tiempo y era aburrido. ¿Alguien se ha divertido haciendo las clases para escribir cookies y validar sesiones?.
Plugin de generación de código: Una vez diseñada tu base de datos con su integridad referencial por supuesto, basta ejecutar una orden para que se genere el código - si eres bueno diseñando bases de datos estarás encantado. Esta generación de código escribe las clases con anotaciones JPA que permitirá conectar tu modelo orientado a objetos con la persistencia (Tengo un post relacionado llamado orientación de objetos v/s Bases de datos).
Generación de CRUD: Si la aplicación va de muchos "Crear/Editar/Borrar/Mostrar" de seguro esto te solucionará muchos de tus problemas. No sólo se genera el código para el CRUD si no que los test y datos de prueba. Evidentemente no te puedes quedar sólo con lo que te generara - si necesitas customizar lo generado es muy fácil de refactorizar - pues Appfuse crea managers y Daos genéricos que luego puedes fácilmente reemplazar por tus clases.
Jetty: Appfuse incluye un mini-tomcat por decirlo simple, desde el proyecto ejecutas mvn jetty:run-war y luego a http://localhost:8080 - No deploy need! - además no levanta el servidor si tu appz no pasa los test (Testing driven developmente es absolutamente necesario a estas alturas).
Utilizas el poder y la magia de las herramientas, la inyección de dependencia de Spring es un concepto que voló mi cabeza al descubrirlo - no cabe más que decir que si los productos por sí solos son exitósos, imagínatelos coordinados trabajando al servicio de tu cliente.
Dejo lo más importante para el final: La respuesta a tus dudas es Matt Ribbles - Appfuse cuenta con una de las mejores listas de correos que he participado - todas las veces que he preguntado algo es Matt Ribbles, creador de appfuse, quien personalmente contesta dándote exáctamente la información que necesitas. O séa que mejor.

Y puesto que la ingeniería de software es una Lemmingería (Alan Davis ironizaba al respecto) les cuento lo que no me ha gustado de appfuse:

La curva de aprendizaje: Se tarda mucho en entender de que vá el tema, desde el DaoImpl al DaoInterface, del ManagerImpl al ManagerInterface, de los manager y Daos genéricos, del dispatcher servlet, de los alias de vistas y vista resolver, del initBinder del controlador, del controlador multiaction ..... hay mucho, mucho que aprender a entender como se relacionan. En 4 fin de semanas puedo decir que ví claridad.
El riesgo de lo automático existe aquí - pero muy poco: Me ocurrio que en unos test, Spring inyectaba por nombre el objeto necesario automáticamente, esto funcionaba perfecto hasta que puse dos aplicaciones en el mismo workspace y cambié de portatil - no funcionó más. Luego de eso tuve que buscar en todo el Spring in Action para resolver el problema.
Aprender todos los mecanismos para ver claridad, personalemente no soy muy bueno con las capas de presentación - me gusta más el tema puro de patrones en la parte del modelo y controlador, pero me he visto obligado a pasar horas revisando los jsp y sus tags.

Para concluir, les hago una invitación a usar frameworks y que si ya los usan a buscar otros para mejor continuamente para vencer nuestro talón de Aquiles - Mi próximo desafío se llama Grails.

Hasta pronto!.

Estructura de SVN para Proyectos de Software

2007-11-05T13:23:00.000-08:00

Tener una estructura ordenada de nuestro repositorio es muy importante, pues el proceso de desarrollo en concreto produce artefactos software que deben ser mantenidos, ordenados, revizados y catalogados adecuadamente.

Para quienes no utilicen un control de versiones en sus proyectos, les recomiendo que comiencen a usarlo inmediatamente pues en el software hay que ser simplista, gestionar los cambios, reutilizar lo más posible, y en la medida de lo posible que herramientas hagan nuestro trabajo [Para los estudiosos: Do not repeat yourself, Keep it simple stupid, etc].

Lo primero es entender como trabaja un control de versiones en lineas muy generales: Existe un directorio donde se alamcena una base de datos de archivos, cada desarrollador obtiene una copia de ese directorio y hace los cambios necesarios que luego sube a este directorio; Si hay más de una persona trabajando no importa pues tiene herramientas automáticas que son capaces de juntar los cambios incluso en un archivo y avisar de los conflictos. Para más información sobre control de versiones y en concreto de subversion click aqui.

Ahora que ya se sabe el beneficio de usar un sistema de control de versiones, se debe definir que estructura deberá tener este. Si bien la estructura depende del proceso de desarrollo de software que practiques, la estructura que se presenta la puedes usar como base pues formaliza los archivos y carpetas que se deben incluir.

Nomenclatura:

Linea base: Linea base de gestión de configuración - en nuestro caso una carpeta que contien determinados artefactos.
ITER: Número de la iteración en la cual fue producido el documento o modelo. No aplica a código fuente. Ejemplo: PLAN_REQ-ERS-00.doc significa el documento de especificación de requisitos de la linea base PLAN_REQ que se produjo en la iteración 0.

Tipos de archivo (de las herramientas que yo uso):

.zargo: Modelo UML en ArgoUML
.doc: OpenOffice Word Processor
.xml: Modelo de base de datos en DBDesigner.
.txt: Un editor de texto.
.sql: Script sql.

Cabe señalar que se trata de una estructura de directorios para un proceso de desarrollo iterativo, más info aqui

trunk (Directorio de desarrollo)

PLAN_REQ (Linea base de planificación y requisitos)

PLAN_REQ-CALIDAD-ITER.doc (Plan de calidad)
PLAN_REQ-CASOS_DE_USO_FORMATO_BREVE-ITER.doc (Casos de uso, formato breve)
PLAN_REQ-CONFIGURACION-ITER.doc (Plan de gestión de configuración IEEE 828)
PLAN_REQ-DESCRIPCION_DEL_SISTEMA-ITER.doc (Descripción del sistema)
PLAN_REQ-DIAGRAMA_CASOS_DE_USO-ITER.zargo (Diagramas de casos de uso)
PLAN_REQ-ERS-ITER.doc (Especificación de requisitos de software - IEEE 830)
PLAN_REQ-ESTIMACION_PLANIFICACION-ITER.doc (Estimación y Planificación del proyecto - Cocomo II, Puntos de función, cartas gantt)

DISEÑO (Linea base de análisis y diseño)

DISEÑO-CASOS_DE_USO_FORMATO_EXTENDIDO-ITER.doc (Casos de uso formato extendido - màs conocido como Fichas de casos de uso)
DISEÑO-CONTRATOS_DE_OPERACIONES-ITER.doc
DISEÑO-DIAGRAMAS_DE_SECUENCIAS_DEL_SISTEMA-ITER.zargo (Pueden obviarlo - no me gustan muchos estos diagramas)
DISEÑO-MODELO_CONCEPTUAL-ITER.zargo (Classes de análisis)
DISEÑO-DIAGRAMA_DE_CLASES-ITER.zargo (Classes de Diseño)
DISEÑO-DIAGRAMAS_DE_INTERACCION-ITER.zargo (Diagramas de secuencia y comunicacion[colaboración])
DISEÑO-MODELO_RELACIONAL_BASE_DE_DATOS-ITER.xml
DISEÑO-PLAN_DE_PRUEBAS-ITER.doc

IMPL (Linea base de implementación)

IMPL-BASE_DE_DATOS-ITER.sql (Dump de la base de datos)
SRC (Código fuente)

PRUEBAS (Linea base de pruebas)

PRUEBAS-PRUEBAS_DEL_SISTEMA-ITER.doc

ENTREGA (Linea base de entrega)

ENTREGA-LICENCIA-ITER.txt
ENTREGA-MANUAL_DE_INSTALACION-ITER.doc
ENTREGA-MANUAL_DE_ADMINISTRACION-ITER.doc
ENTREGA-MANUAL_DE_USUARIO-ITER.doc
ENTREGA-NOTAS_DE_LA_ENTREGA-ITER.txt

tags(Directorio de marcas de desarollo)

iteraciones (Cada vez que se termina una iteración se hace una copia del trunk aquí, marcada yyyymmdd_iterITER)
releases (Cada vez que se lanza una versión del producto se hace una copia del tag de iteración correspondiente aquí yyyymmdd_releaseRELEASE)

branches (Directorio de variantes del proyecto)

Puedes descargar la estructura aqui,

Haz checkout de tu repositorio descomprime la carpeta en tu copia de trabajo y haz commit. Yo uso subEclipse, RapidSvn y subversion por terminal.

Espero les sirva.

Si tienes feedback deja comentarios o me escribes a lbarrientos@opensistemas.com.

Suerte!

Orientación a objetos y Bases de Datos

2007-09-04T19:17:00.000-07:00

Si hay algo que funciona en el software son las bases de datos relacionales, si bien tienen un caracter absolutamente estructurado son ampliamente usadas en aplicaciones orientadas a objetos y allí viene un gran problema: La magia de la orientación a objetos se rompe en la creación de objetos - en este caso en obtener un objeto desde una base de DATOS; esta labor la realiza la Persistencia. Persistencia es el concepto que se debe usar en orientación a objetos pues las BD quedan fuera de su alcance.

La persistencia es la encargada de devolver y perpetuar objetos de un determinado tipo desde/hacia los negocios; el problema es hacer depender fuertemente nuestra elegante - no acoplada - indiferente aplicación OO a mecanismos puramente estructurados y enfoncado en los datos; si necesita datos desde su BD que la persistencia crée los objetos y usted los usa como objetos propiamente tal; objetos, objetos, objetos.

Es completamente sugerible aislar estos mecanismos en una capa de persistencia (Nota: Use JPA - HIBERNATE - Invente una capa de persistencia), sería ingenuo conectarse y consultar a una BD desde cualquier parte, tal como una vista html por ejemplo - de hecho es una excelente forma de saber a quien no contratar. Muchas veces me he encontrado en sistemas web donde se conectan donde se les ocurre sin usar ninguna separación haciendo un desastre el mantenimiento, pero dándome mucho trabajo.

Definitivamente el software libre nos sirve para mirar cómo lo hicieron otros para mejorar nuestros sistemas o mejor aún reutilizar y aportar; capas de persistencia como Hibernate o JPA son un excelente forma de aprender esta abstracción de traer objetos cargados desde la persistencia.

Patrón estado

2007-09-03T09:45:00.000-07:00

Desde un tiempo a esta parte he llegado a la conclusión que el software nunca se termina de hacer y creer que con un proceso X,Y o Z se tendrá "The definitive software" es absolutamente falso. En base a esto la vuelta de tuerca es estar preparado y siempre listo (Sí, soy Scout) para los cambios que de seguro ocurrirán en nuestro diseño, para ello - y tal como mi gran profesor Nelson Medinilla me enseñó - hay que agregar "Ambiguedad" al diseño pues es muy comprometedor nombrar un método de forma cerrada, por ejemplo: "calcularTasas" - es mejor usar "calcular" o mejor "operar" por que si hay cambios los metemos dentro de un método que está preparado para ser extendido en su funcionalidad.

Siempre es buena práctica encapsular lo que varía y una fuente de variación en el comportamiento de una classe es su estado - la otra fuente que se me viene a la cabeza es el tipo que se soluciona con el Patrón Estrategia - ¿Adivinen qué? Existe un patrón llamado estado.

La idea del patrón estado es encapsular - aislar las operaciones que dependan del estado o que se pueden graficar en una máquina de estados.

Supongamos una clase Impresora , los estados serían : ImpresoraApagada - ImpresoraImprimiendo - ImpresoraEsperando - ImpresoraLimpiandose, la operación de ejemplo que depende del estado sería - en un principio - imprimir o mejor aún la más ambigua "operar()"; luego a alguien se le ocurrirá algún chequéo de tinta antes de imprimir.

Seguramente algien podría hacer funcionar esta clase simplemente con un switch dentro de imprimir, pero el problema viene cuando deseas ampliar los estados y sus transiciones; necesariamente debes intervenir el switch y agregar esta nueva opción.

La solución elegante es "encapsular lo que varía" y "favorecer la composicion por sobre la herencia", así pues tenemos la Clase impresora con un atributo llamado EstadoActual, es este atributo el que vamos cambiando y es de tipo EstadoImpresora - que es una clase abstracta o interface si así lo quieren.

Al diseñar la clase Impresora podríamos crearla con un estado por defecto e implementar los cambios de estado dentro de la misma clase o en cada clase estado definiendo el siguiente estado cuando el caso lo amerite; para este ejemplo el cambio automático de estado con una máquina de estados no lo considero por que me cae muy mal Craig Larman.

Classe:
Nombre: Impresora
Atributos: EstadoImpresora estadoActual
Metodos: imprimir()

Descargar el código aca

Patrón Strategy (Estrategia)

2007-05-22T14:09:00.000-07:00

Este patrón se llama estrategia y sirve básicamente para cambiar un algoritmo que una classe implementa.

En el ejemplo en código, se crea una objeto banda que tiene un atributo objeto integrantes, pues bien, supongamos que ese objeto integrantes es un objeto que se pueda intercambiar fácilmente al crear este objeto banda y pasándole el objeto integrantes correspodiente al tipo de banda que queremos crear.

la clase IntegrantesXXXXXXXXX hace la implementación adecuada.

Acá va el código, have fun!

Patrón Factory

2007-05-03T12:40:00.000-07:00

Este es uno de mis patrones favoritos, se llama Factory y la idea es que exista una clase Factory que devuelve un objeto con las características propias de ese factory.

En el ejemplo puedes ver que se necesitan crear objetos banda (de música Rock, Jazz, etc.) entonces se usa una clase JazzBandFactory que devuelve un objeto Banda con el atributo estilo con valor "Jazz" a través del método make() que es llamado desde una clase Factory abstracta.

El truco es que la clase abstracta tiene un método abstracto, entonces al llamar a ese método abstracto se usa el implementado por la subclase JazzBandFactory.

Así se genera una aplicación lista para implementarse, simplemente ante la necesidad de crear un nuevo tipo de banda, creamos una classe xxxxxxxxxFactory que crea y setéa un objeto banda de la manera que sea necesaria.

A nivel de código sería :

JazzBandFactory productorJazz = new JazzBandFactory();
Band banda = productorJazz.create(); //Este es la llamada al método de la Clase Abstracta Padre, este método llama al abstracto make que es implementado por JazzBandFactory.

// Aquí ya el objeto banda tiene los valores que le da JazzbandFactory en el metodo make

Descarga el código Java acá Factory.zip

Se puede usar en miles de casos, por ejemplo en perfiles de usuario, botones de un determinado estilo, etc, etc.

Patrón decorator

2007-05-03T12:29:00.000-07:00

Ahora pongo el código en Java del patrón Decorator, por que los comentarios me dicen que no se entiende. Decorator.zip

Patrones de diseño: Decorator

2007-04-23T12:33:00.000-07:00

Hola bienvenido a mi serie de post que he llamado "Patrón de diseño en 10 minutos", hoy comienzo por el patrón Decorator.

La idea de estos post no es dar tanto ejemplo en código si no explicarlo en el lenguaje humano lo más claro posible, pues así quedan más claros los conceptos. Si no resulta me comprometo a poner ejemplos - así les obligo a dejar comentarios.

Vamos, antes les debo recordar que en general se usan interfaces, clases abstractas y métodos abstractos para determinar los comportamientos de los objetos.

Es un poco dificil de entender esto de comportamiento en los objetos, pues mucha gente simplemente agrupa una serie de métodos desde sus "librerías"; espero ayudar a que quede claro que el camino de la orientación a objetos va por otro lado.

Patrón decorador:

Supone que vas a un hotel, cada noche de hotel en habitación compartida tiene un precio base de 100$.

A mitad de la noche se te ocurre bajar a la piscina y la entrada vale $5.

Luego de la piscina pides comida (en tu habitación), esta comida tiene un precio de $10.

¿Cuanto sería el total? , sería un poco dificil de obtener datos al tener una array o alguna estructura de todos los objetos pues estos objetos son de distintas clases y prbablemente de distintos métodos.

Cual es la solución, pues el patrón decorador, simplemente cada cosa nueva que pides tiene un atributo que es un objeto del precio base que se va actualizando y cuando creas el objeto "adicional" simplemente le vas pasando ese objeto, de esta forma para obtener la cuenta la obtienes desde el último objeto "adicional" creado.

Algo así como (en pseudo código):

cuenta = new Habitacion(); // existe el método costo que devuelve 100.
cuenta = new TicketPiscina(cuenta); //existe el método costo que devuelve this.cuenta.getCosto() + this.costo() o sea 100 + 5
cuenta = new ComidaHabitacion(cuenta); //existe el método costo que devuelve this.cuenta.getCosto() + this.costo() o sea 105 + 10

Y para obtener el precio sería simplemente : precio = cuenta.costo();

Vamos, ¿se entiende?

Saludos!

¿Para qué trabajo?

2007-04-21T04:43:00.000-07:00

Ayer conversando me dí cuenta lo fácil que es para mi a veces cometer el error de pensar en el trabajo como mi actividad principal. Pues el trabajo no es mi actividad principal, a pesar de que ahora trabajo desde las 7:30 hasta las 16:00 y luego voy a clases del Master hasta las 21:00; todo mi día es acerca de Software.

Parece ser la desgracia de trabajar en lo que te gusta...

Mi actividad principal es aprender y compartir mi vida con mi mujer,así aprendo de muchas cosas, aprendo a ser mejor, a escuchar, observo y repaso en mi cabeza mis errores.

Simplemente, tenemos el derecho de haber cometido errores y hay que aprender de ellos para que no se vuelvan a repetir. Sin duda alguna he cometido errores por pensar que mi actividad principal es el trabajo - mi desarrollo profesional.

Ahora que estoy terminando mi meta de tener un master estoy buscando nuevos desafíos, esta vez con las cosas claras de saber cual es mi actividad principal.

En el siguiente post si que hablo de software!.

Dude!, the american way.

2007-04-20T01:32:00.000-07:00

Requisitos, Requisitos, Requisitos.

2007-03-27T14:31:00.000-07:00

Y lo que antes en negocios era ubicación, ubicación, ubicación es nuestro talón de Aquiles en Software: Requisitos, requisitos, requisitos.

En realidad abstrayéndonos de la implementación y pensando en términos de reglas de negocio es el mayor riesgo y el responsable del fracaso de la mayoría de los proyectos.

¿Que pasa con los requisitos?, pues que son un contrato y si el sistema hace lo que los requistos dicen pues estamos bien (no iremos presos), siempre y cuando que los requisitos y sus especificaciones documentadas sean aprobadas por el cliente.

De esto surgen dos escenarios negativos:

Que el cliente esperaba más de lo que el sistema hace.
Que el sistema no implementa los requisitos.

¿Que errores de dirección permiten que ocurra esto? pues en lo que siempre fallan quienes se centran en la tecnología y no en las reglas de negocio de lo que estamos desarrollando - cosa que alguna vez me ocurre:

No existe gestión de espectativas: El cliente normalmente no entiende hasta donde llega el proyecto, se debe definir un alcance: ¿Qué es el proyecto? ¿Que no es el proyecto?

No existe un listado de características y de funcionalidades formal del sistema: Si no hay documentos no hay nada que hacer.

Que los documentos de requisitos están en lenguaje técnico que el cliente no entiende.

Que no se da la importancia a la gestión de la configuración: Un gestor de configuración es casi un médico heroe, se encarga de controlar los artefactos producidos,sus cambios, versiones, su archivo, su coherencia, etc; no tener un gestor de configuración - o no hacer las actividades de gestión de configuración - es conducir un automovil con los ojos cerrados.

Y yo que creía que el gestor de configuración era quien configuraba las máquinas. ....

Mis errores históricos

2007-03-13T06:06:00.000-07:00

Hello world!! (es un clásico).

Me agrada bastante esto de registrar mis errores en Proyectos de Software, pues así no vuelven a ocurrrir, aquí va mi lista a Marzo 2007.

Error: No dar visibilidad al Proyecto ni a mi trabajo.
Error: No hacer pruebas unitarias de las classes.
Error: No actualizar las Cartas Gantt.
Error: Trabajar sólo.
Error: No controlar el código (svn).
Error: No programar pensando en los servicios, si no en un implementación.
Error: No pensar antes de diseñar, ni pensar en escribir código.
Error: Perderme entre tantos diagramas de secuencia.
Error: No haber usado Tarjetas CRC antes.
Error: No saber PMBOK antes.
Error: No preparar mis classes para ser re utilizables.
Error 2005 : No aplicar antes arquitectura de 3 capas.
Error 2005 : Trabajar directamente en el sitio de explotación.

¿Cuáles son los tuyos?

Listado de características v/s Casos de Uso.

2007-02-16T12:46:00.000-08:00

Se supone que cuando empezamos en un desarrollo tenemos un listado de características con lo que debe hacer el sistema y luego hacemos nuestros Casos de Uso. El tema es ¿Cuál debo hacer?, ¿Es mejor cumplir una característica completa? o ¿enfocarnos en los casos de uso?, la respuesta es "depende".

Plantéo el siguiente escenario:

La aplicación debe :

Enviar un SMS que indique tiempo al cual se encuentra un Autobus desde un paradero al recibir un SMS con el siguiente formato: "Paradero LineadeAutoBus" Ej.: 105 591

Esto de "la aplicación debe" son nuestro Listado de Características.

Y como consecuencia de este Listado de Características obtenemos los famosos Casos de Uso, que serán nuestra compañía el resto del desarrollo.

Los Casos de Uso son:

¿Con que partimos para desarrollar?, pues tenemos las 2 alternativas:

Realizar la Característica 1.
Realizar un caso de uso.

Para decidir se considera el nivel de visibilidad comprometido, si el cliente tiene un poco de paciencia podemos partir por los casos de uso; si no partimos con la característica.

Estoy seguro que el desarrollo con casos de uso nos permitirá un diseño elegante desde un primer momento, pero que a lo mejor tardaremos un poco más en mostrar algo completo - recordemos que los clientes quieren resultados, no diagramas de Ingeniería que sólo nosotros entendemos - debemos hablarle en su lenguaje.

Si tenemos un poco más de tiempo conviene comenzar con los Casos de Uso, si no tratemos más "visual" el entregable y realizemos primero alguna de las características. Finalmente el producto tendrá la calidad de hacer lo que tiene que hacer, de haber aplicado principios de OO y la elegancia de los patrones de diseño.

Cultura de Prototipos/Maquetas

2007-02-15T14:31:00.000-08:00

Como todos sabemos - pero nos cuesta aceptarlo - la única constante en Desarrollo de Software es el cambio.

El maldito cambio, simplemente debemos ser más inteligentes: Tener en la cabeza que las cosas cambian y que nuestra obsesión por implementar funcionalidad lo antes posible con classes perfectas nos lleve a codificar de más.

¡Pero un momento!, ¿codificar de más?, si - aunque me costó creerlo mientras antes se empieza a escribir código más tarde finalizaremos el proyecto.

¿Por qué?, por que nuestra obsesión no considera que los cambios ocurrirán y que el cliente simplemente quería otra cosa, o se ajustó esta regla de negocio y tal, y tal, y tal, y tal .......

Solución: Cultura de Prototipo.

Conversamos con el cliente.
Formalizamos lo conversado en una Lista de Características.
Revisamos con el cliente esta lista.
Especificamos los requisitos de las características que tienen mayor prioridad.
Hacemos un protipo - sin funcionalidad.
Revisamos con el cliente el Prototipo/Maqueta (que tardamos a lo más 2 horas en hacerlo con HTML o drag&drop), revisamos la Lista de Características y así nos aseguramos que vamos bien con el cliente.
Repetimos en cada iteración que sea necesario.
Continuamos con los paso habituales de Desarrollo Iterativo e Incremental.

Se ve muy simplista, estoy de acuerdo, lo importante es que ya estamos listos para:

Asegurar que el sistema hará lo que el cliente quiere.
Aplicar principios de OO.
Aplicar patrones de Diseño y le damos caracter de Ingeniería a la obra de arte.

En ese orden, funciona créanme!.

Con un gran amigo aprendimos que no hay que mostrar los diagramas de classes, ni nada parecido al cliente. Le mostramos los artefactos en su propio lenguaje: Un listado de características en el cual identifique cláramente lo que quería.

A pesar de todo esto siempre surgirán nuevos cambios, pero ya tendremos una arquitectura extensible y no hemos perdido horas de trabajo de implementación - No existen malos equipos, sólo malos líderes.

¿Si, te parece que eso lo implementemos en la próxima versión?

Hacer pruebas es lo más ineficiente, pero peor es nada!.

2007-02-15T13:49:00.000-08:00

Si es verdad, hacer pruebas es lo más ineficiente para controlar la Calidad de nuestro software. ¿Por qué?, muy simple: Los números no mienten.

Del 100% de los errores, se pueden encontrar tan sólo el 7% a través del compilador-Intérprete.

Algunas opiniones dicen que si como desarrolladores dependemos del Debug y el Compilador para encontrar errores - manifestados como Fallos o Defectos - en realidad es porque no sabemos desarrollar.

La cosa es : "Mientras antes observemos la calidad, más posibilidades se tiene de encontrar errores".

Algunos datos empíricos gringos:

La distribución de defectos es:

56% en Especificación de requisitos.
27% en Diseño.
7% en Implementación.
10% Otros.

Los errores más importantes los cometemos al especificar requisitos, debemos recordar que una aplicación no está libre de errores si compila; sino que al no hacer lo que la aplicación debe hacer siguiendo las reglas de negocio.

No es buena práctica esperar a realizar las pruebas para comprobar la calidad, puesto que simplemente descubriremos menos errores.

Por otra parte los costos al finalizar un Proyecto y encontrar errores en cada Flujo de Trabajo es:

Especificación de requisitos : 82%
Diseño: 13%
Implementación: 1% (Si, 1 %).
Otros: 4%.

Imagínense que están entregando el Proyecto y no hace lo que se supone que debería hacer: ¿Quién está a cargo de especificar requisitos en tu equipo de trabajo? ....

Ahora si queremos corregir los errores, los costos son exponenciales mientras más tarde nos preocupemos de la calidad:

En un proyecto mediano

Corregir errores anteriores mientras Analizamos cuesta en promedio 200 Dólares.
Corregir errores anteriores mientras Diseñamos cuesta en promedio 500 Dólares.
Corregir errores anteriores mientras Codificamos cuesta en promedio 1200 Dólares.
Corregir errores anteriores mientras se hacen las Pruebas cuesta en promedio 5000 Dólares.
Corregir errores anteriores estando en Operación cuesta en promedio 15000 Dólares.

De verdad las pruebas no son suficientes y no son sinónimo de Control de Calidad.

Como tener Log en PHP5 y no morir en el intento

2007-02-15T13:21:00.000-08:00

Log?,

/**
* Classe: Log
* Responsabilidades: Escribe los Logs de usuario en la carpeta log/
* Colaboradores: No tiene.
* Patron: Singleton.
* Uso Principal: Log::getInstance()->addEntry('Mensaje','Classe que invoca','Metodo que invoca',$editMode);
*
* @author Leo Barrientos C. leobarrientos@opendesarrollo.cl
* @copyright GNU
*/

Esta classe genera un log por día en la carpeta log y en modo testMode=true guarda el archivo añadiéndole un .test al final.

Además usa un patrón singletón por lo que la llamada es con el famoso "::" y muy simple:

include_once("Log.class.php");
Log::getInstance()->addEntry('Test','No class','No Method', false);

El diagrama de Classes es el siguiente:

Puedes descargar el archivo haciendo click(Con el mouse) aqui.

Principio de Single Responsibility

2007-02-15T12:07:00.000-08:00

¿Qué sucede cuando tenemos alguna classe y unos de sus métodos no "suena bien"?, pues es tiempo de aplicar los principios de la orientación a objetos.

En esta oportunidad mostraré un ejemplo del Principio de Single Responsability(SRP).

Supongamos que tenemos una classe Almacen de un sistema de Inventario de Productos, el diagrama de Classes inicial se muestra en la figura 1.

Figura 1: Diagrama de Clases Rev 1.

Pues bien, vamos a aplicar "elegancia" al Diagrama de Classes aplicando el SRP llenando la siguiente tabla:

Classe: Almacén

El almacén __________________

En el espacio vamos agregando los métodos y acomodando el lenguage a ver si tiene sentido en las reglas del negocio de nuestra aplicación.

Classe: Almacén

En el almacén se puede agregar un Item.
Del almacén se puede remover un Item.
El almacén imprime el Inventario.
El almacén puede despachar envíos.

¿Hay alguna frase que no tenga sentido con lo que entendemos que hace un almacén? Claro que si:

El almacén no imprime un inventario, lo que hace es devolver la información de todos los items que están en él o sea el Inventario; o mejor aún una lista de Items(List, Collection o array, lo que sea.).
El almacén no despacha envíos, lo que si despacha envíos es un Despachador que solicita ciertos items al almacén.

Con esto, reconocemos los sustantivos y acciones y actualizamos nuestro Diagrama.

Figura 2: Diagrama de Clases Rev 2.

Bueno, ahora revisemos si esto tiene sentido:

Classe: Almacén

En el almacén se puede agregar un Item.
Del almacén se puede remover un Item.

Classe: Despachador

El despachador puede despachar envíos.

Classe: Inventario

El Inventario se imprime.

Si, tiene sentido!.

Ahora pseudo codifiquemos un test para ver si funciona:

Caso de Prueba: Imprimir el Inventario actual.

inventario = new Inventario();
inventario.imprimirInventario();
inventario = null;

Si funcionará , pues con UML definimos que el método imprimirInventario depende del método getItems del Almacén y recibirá correctamente el contenido actual del almacén.

¿Comentarios?.

Calidad: Defectos v/s Fallos

2007-02-15T04:21:00.000-08:00

Muchas veces hablamos o escuchamos "Hey, encontré estos errores en el sistema....", ante esto podemos hacer 2 cosas inmediatas :

Cuestionar nuestra existencia.
Agradecer, pues nuestro Software una vez corregido será mejor.

Creo que la mejor opción es la 2, sin embargo para llegar a esto hemos cometido un error muy grave : "Hemos permitido que un defecto se convierta en un Fallo".

A modo de aclarar conceptos debo decir que un :

Error: Lo comete un humano durante el Proceso de Desarrollo.
Defecto: Es la consecuencia de un error.
Falla: Es un defecto no detectado y que no está eliminado.
Fallo: Defecto que se manifiesta durante la ejecución.
Incidente: Comportamiento no esperado.

Evidentemente la mejor forma de que no ocurran fallos es evitar escribir con errores que produzcan defectos. Para aumentar la calidad de nuestro producto artístico de Ingeniería de Software debemos realizar un control estático; que en palabras simples no es que otra cosa que otro developer amigo revise el código (Si leerlo) y retroalimente tu trabajo.

Está comprobado que la calidad del Producto software aumenta inmediatamente si los desarrolladores sabemos que nuestros artefactos serán revisados (Leidos, comentados) por otras personas, en lo llamado Control estático.

Muchas personas relacionan la calidad del Producto con que pase las pruebas - Control dinámico - antes de entregarlo, error gigante!!!; el control estático es preventivo y es más eficiente pues obliga inmediatamente a implementar buenas prácticas.

La frase final de este Post es : " Preocuparse de evitar y corregir los defectos antes que ocurran los fallos."

¿Comentarios?