Mundo Byte

Objective-C para desarrolladores Java: Parte 1

2012-01-29T13:00:00.001-08:00

Como desarrollador Java y claro que no con mucha experiencia en lenguaje C, es importante comenzar conociendo algunas diferencias entre ambos lenguajes. Aprendí cuestiones básicas de lenguaje C desde la preparatoria, pero claro que sin tener ninguna práctica en la Universidad, olvide lo que aprendí, sin embargo no es muy complicado recordar aquellas cuestiones básicas.

En este sencillo tutorial, vamos ver algunos conceptos básicos de Objective-C que hereda del lenguaje C con el fin de perfilarnos más adelante a comenzar con el desarrollo de aplicaciones en MAC OS X y iPhone utilizando Xcode.

Aunque Objective C es más utilizado en el mundo Mac y este ejercicio se desarrolló en una MacBook, es posible hacerlo en Windows, bajar el compilador y cualquier editor, aunque claro esta, no es tarea de este tutorial explicar su instalación. A continuación paso a listar las herramientas utilizadas para este ejercicio.

NOTA: No es intensión de este tutorial, explicar las diferencias entre lenguaje C puro y Objective C.

HERRAMIENTAS.

MacBook Pro - OS X Lion
CodeRunner - Puedes utilizar cualquier otro editor de texto.

CONCEPTOS BÁSICOS

Al igual que en Java, en Objective C se acostumbra al uso de Interfaces y Clases. Vamos a crear una interfaz llamada Arithmetic

En Java, la super clase cósmica de la cual deriva toda la jerarquía de clases de la biblioteca de Java, es llamada Object. Pues bien, en Objective C, NSObject es el similar a la clase Object. Aunque en Objective C no es requisito que una clase derive de NSObject. En Java si una clase no especifica extender a otra clase, internamente deriva de Object.
Mientras en Java la herencia de especifica mediante la palabra "extends", en Objective C se indica mediante el símbolo dos puntos (:).
En Java, el cuerpo de una interfaz o de una clase esta definida por la apertura y cierre de llaves {….}, en Objective C se delimita por @interface y @end.
En Objective C las variables de instancia de declaran seguido de la definición de la interfaz y encerradas entre llaves, tal y como se muestra en la imagen. operador1 y operador2 son estas variables.
En Java podemos definir métodos de instancia y métodos de clase. Recordando que los métodos de instancia son aquellos que podemos invocar creando una instancia del objeto, mientras que los métodos de clase son aquellos que podemos invocar sin tener una instancia de un objeto, como por ejemplo, los métodos de la clase Math son un ejemplo claro de los métodos de clase… Math.pow(…..). En java, los métodos que en su definición agregan la palabra static, se consideran métodos de clase.

En Objective C, un método de instancia se declara con el símbolo menos (-) y los métodos de clase (como el método pow en Java) se declaran con el símbolo más (+).
El tipo de dato de retorno de un método siempre se especifica entre paréntesis, en este caso, es (void).
Como se observa en la imagen, después del nombre del método, se escribe el caracter dos puntos (:) para posteriormente indicar el tipo de dato del parámetro que es encerrado dentro de paréntesis. En este caso, tenemos dos parámetros llamados op1 y op2. Ámbos son de tipo (NSInteger).

En la segunda parte vamos a realizar la implementación de la interfaz y veremos como compilar, enlazar y ejecutar este ejercicio desde la línea de comandos para que en la tercer parte podamos desarrollar una sencilla interfaz gráfica mediante Xcode + Interface Builder que utilice esta clase Arithmetic.

III. Paso de parámetros en Java: Por Valor

2012-01-29T11:48:00.003-08:00

Explicábamos en la segunda parte de este artículo que lo que realmente se pasa es una copia de la referencia. La explicación gráfica del ejemplo anterior de lo que sucede en memoria es la siguiente.

Recordemos que en nuestra primera entrega explicamos lo que es una “referencia de objeto” y decíamos que una referencia de objeto apunta al Objeto.

Entonces cuando creamos al objeto “ascari”, este es solo una referencia a un objeto Empleado. Cuando invocamos al método triplicarSueldo y le pasamos como parámetro al objeto ascari, no le estamos pasando la dirección de memoria de “ascari”. Lo que sucede es que se hace una copia de la referencia “ascari” y esta copia se pone en “x”.

Lo anterior es la piedra de tropiezo para muchos, y es lo que les causa confusión. El hecho de que Java maneje el concepto de “referencia de objeto” es lo que hace pensar que Java hace un paso de parámetros por referencia, es decir, que se le pasa la dirección de memoria. Sin embargo, una referencia de objeto es un apuntador a un Objeto ubicado en algún otro lugar de memoria.

Como lo comentábamos, cuando “ascari” es pasado al método triplicarSueldo, no quiere decir que a “x” le sea asignada la dirección de memoria de “ascari”. Como lo ilustra la figura de arriba, se hace una copia de la referencia! Por lo tanto existen dos referencias que apuntan a un objeto Empleado.

Técnicamente esta mal dicho si decimos “modificar x” ó “modificar ascari” ya que en ningún momento estamos modificando a “x” o “ascari” ya que estas son solo referencias a un objeto Empleado, lo que realmente se modifica es el objeto Empleado.

Ahora como seguramente muchos pensaran que todo lo anterior es absurdo, hay que realizar un último ejemplo para demostrar de forma contundente que los objetos no son pasados por valor.

Tercer Ejemplo.

Hagamos un método llamado intercambiar que reciba dos objetos Empleado y que intente intercambiar a los empleados.

Si Java hiciera un paso de parámetros por “referencia” el resultado de este ejemplo es que “a” terminaría refiriéndose a Beto y “b” terminaría refiriéndose a Ascari, sin embargo no es así. ¿Qué esta pasando internamente en memoria? ¿Por qué en el ejemplo anterior si existe un cambio en la variable que hace la llamada y en este no?

Si el paso de parámetros Si el paso de parámetros fuera por referencia, ocurriría algo como esto.

Si Java hiciera un paso de parámetros por referencia, entonces “x” obtendría la dirección de memoria de “a” y “y” obtendría la dirección de memoria de “b”. Entonces cuando en el método “intercambiar” intentemos hacer que “x” apunte al Empleado Benito y que “b” apunte al Empleado “Ascari”, por ende “a” también apuntaría a “Benito” y “b” apuntaría a “Ascari”. (Figura de abajo).

Sin embargo, podemos comprobar que lo anterior no funciona. a sigue refiriéndose a Ascari y b a Benito. Por lo tanto, Java no acepta un paso de parámetros por referencia sino por copia o valor, pero lo que se copia es la referencia del objeto.

Ahora veamos lo que en realidad esta pasando.

Observamos que existe una copia de las referencias a y b. Estas referencias son copiadas en x e y. Ahora “x” apunta a Ascari y “y” a Benito.

Pero inmediatamente en el método “intercambiar” se realiza el intercambio.

Ahora vemos como “x” apunta a “Benito” y “y” apunta a “Ascari”.. Sin embargo no perdamos el foco de que tanto “a” como “b” siguen apuntando al mismo objeto!!!!!!!!!

Lo anterior demuestra de forma contundente que Java NO realiza el paso de parámetros por referencia, sino por copia, pero lo que sucede es
que se hace una copia de las referencias de objeto.

Desafortunadamente autores de libros sostiene que Java realiza paso de parámetros por referencia para los objetos.

Algunos autores son:
● Francisco Javier Ceballos
● Agustín Froufre

Afortunadamente hay autores que con toda la autoridad desmienten lo anterior. Algunos de ellos son:

● Gary Cornell
Autor y coautor de más de una veintena de libros. Posee el
titulo de Doctor otorgado por la Brown University y ha sido
científico visitante en IBM.

● Deitel & Deitel
Toda una autoridad y sus libros son un clásico
en lo tocante a Java y C++.

Pero si todavía queremos más referencias para creer, existen libros de preparación para el EXÁMEN DE CERTIFICACIÓN “SUN CERTIFIED JAVA PROGRAMMER” tal es el caso del libro “SCJP Exam for J2SE 5” del Dr. PAUL SANGHERA, donde en la página 124 afirma lo siguiente.

“The key point to remember is that regardless of whether the passed variable is a primitive or a reference variable, it is always the copy of the variable, and not the original variable itself. Technically speaking, it is pass-by-value and not pass-by-reference within the same virtual machine.”

Más adelante, en la página 125 comenta lo siguiente.

“Recall that an object reference variable points to an object, and it is not the object itself. When you pass a reference variable in a method, you pass a copy of it and not the original reference variable.”

Ahora bien, para los necios, por si esto fuera poco, el mismo creador de Java, sostiene que Java solo utiliza el paso de parámetros por valor.

““There is exactly one parameter passing mode in Java – pass by value – and that helps keep things simple.”

Podemos dar por hecho que hemos desmentido una creencia errónea y a partir de ahora, no seremos engañados por muchas páginas de internet y de personas que dicen que Java acepta el paso de parámetros por valor y por referencia.

Saludos!!

II. Paso de parámetros en Java: Por Valor

2012-01-29T11:48:00.001-08:00

Existe una creencia errónea muy difundida de que en Java el paso de parámetros se realiza de dos formas.

● Los tipos primitivos se pasan por valor.
● Los objetos se pasan por referencia.

Es necesario aclarar que en Java solo existe un único modo de paso de parámetros. Paso por valor. Y lo anterior, es independiente si se trata de un tipo primitivo o un objeto.

Primer Ejemplo.

Si tenemos el siguiente método.

Ahora creamos un objeto Empleado para triplicar el sueldo.

Hasta aquí todos concordamos que no se altera el valor de porcentaje.

Definitivamente comprobamos que incluso aquellos que me acusan de ignorante por no tener idea de lo que hablo, tienen razón! Los tipos primitivos son pasados por valor. Ahora, veamos con un segundo ejemplo si tienen razón al decir que los objetos son pasados por referencia.

Segundo Ejemplo.

Tenemos una clase Empleado. El primer parámetro del constructor es el nombre, el segundo, tercero y cuarto es el día, mes y año respectivamente de su fecha de contrato en la empresa.

Observemos como al empleado en cuestión le asignamos como fecha de contrato el 11 de Junio del 2009.

Al imprimir la fecha de contrato podremos observar que dicha fecha fue alterada ya que obtenemos una fecha del 11 de Junio de 1999! Le hemos quitado 10 años de trabajo al empleado!

Básicamente lo anterior no es un paso de parámetros, pero es un buen ejercicio de calentamiento para prepararnos con lo que sigue.

Tercer Ejemplo.

Entremos en materia pues y hagamos un método que reciba como parámetro un Objeto de tipo Empleado.

Ahora vamos a crear un objeto Empleado y pasarlo como parámetro al método triplicarSueldo.

Upss!!!!!!!!!! El sueldo del empleado ya no es el mismo!!!!!!!!!!!!!! oh nooooo, tenían razón!! Los parámetros en Java se pasan por referencia :( me equivoque! Bueno ni modo, cerrare el blog. Nos vemos……

……………………….

Bueno soy malo para fingir pero hice mi mejor esfuerzo. La verdad es que pese a lo anterior, los objetos son pasados por valor, le guste a quien le guste así es y será por los siglos de los siglos. Lo que realmente sucede es que se pasa una copia de la referencia!

¿Copia de la referencia?… Pero que es eso? De que hablo?.. Bueno, esto se explicará en la tercera parte de este artículo.

Nos vemos a la próxima!!

I. Paso de parámetros en Java: Por Valor

2012-01-29T11:47:00.001-08:00

Después de varios meses de no escribir en el Blog, he decidido responder a una serie de cuestionamientos sobre el tema de “Paso de parámetros en Java” donde desafortunadamente existe mucha confusión al respecto y por ende he recibido comentarios en donde dicen que yo no tengo idea de lo que hablo. Pero bueno, aclaremos ahora todo esto y veamos en donde esta el meollo del asunto o el asunto del meollo.

Ocupare material elaborado por mi en un curso que impartí sobre Java. Barreré como a la hojarasca!

Introducción

Variables primitivas.

Básicamente consisten en variables de alguno de los tipos primitivos.

Variables de Referencia.

También se les llama variables de objeto. Estas variables no son el objeto mismo, son solo una referencia al objeto. Imaginemos tener una variable de tipo Date.

private Date fechaLimite;

Al crear el objeto con el operador new, sucede algo como lo mostrado en la imagen de abajo.

fechaLimite no es el objeto en si, más bien es una referencia al objeto Date.

En Java, el valor de toda variable de objeto es una referencia de un objeto que reside en algún otro lugar. El valor proporcionado por el operador new también es una referencia.

La expresión new Date() crea un objeto del tipo Date, y su valor es una referencia del objeto recién creado. Esa referencia se almacena entonces en la variable fechaLimite. Las referencias de objeto son equivalentes a los punteros de C++, sin embargo, en Java no es posible manejar punteros y la administración de memoria es una tarea del Garbage Collector.

Existe Existe en la terminología de las Ciencias Computacionales para el paso de parámetros a los métodos.

● Paso por valor o copia. Significa que el método obtiene solamente el valor (una
copia) que proporciona quien hace la llamada.

● Paso por Referencia. Significa que el método recibe la ubicación de la variable
que proporciona quien hace la llamada.

Ahora si, una vez aclarado lo anterior, podemos comenzar a desmentir a esa falsa creencia que tienen algunos de mis lectores del blog y muchísima más gente conocedora de C++ pero no de Java y piensan que todo es igual en Java.

Desarrollando un agente de chat que informe el clima

2011-07-28T21:12:00.000-07:00

En este tutorial desarrollaremos con App Engine un pequeño agente de chat que nos informe sobre el estado del tiempo actual de la ciudad que le indiquemos y lo hará utilizando la red XMPP tal como lo hace GTalk. Si no sabes que es App Engine o no has desarrollado anteriormente, es recomendable que leas este pequeño tutorial

Para obtener la información del estado del tiempo podemos utilizar cualquier servicio público como el de Yahoo, Msn, etc., en mi caso utilizaré Google Weather API.

Antes de iniciar...

Antes de iniciar, dejemos en claro el sencillo ejemplo que deseamos hacer. Si tienes algún servicio compatible con el protocolo XMPP como por ejemplo Gtalk (chat de Google), Pidgin, iChat, etc., agrega la siguiente cuenta a tus contactos,

clima-byte@appspot.com

Una vez agregada la cuenta, abre una ventana de chat con este contacto y escribe el nombre de la ciudad de la cual deseas obtener la información actual del estado del tiempo,

Como lo puedes ver en la imagen anterior, del otro lado hay un pequeño agente que te responde inmediatamente con el estado del tiempo actual de la ciudad que le especificas... Lo anterior es una sencilla aplicación que hace uso de un Servlet y del protocolo XMPP desde App Engine.

XMPP

El Extensible Messaging and Presence Protocol es un protocolo open source basado en XML para la transmisión/recepción de mensajes y es mejor conocido como XMPP (anteriormente llamado Jabber). La ventaja de utilizar el protocolo XMPP es que no se requiere de un servidor central, cada uno de nosotros puede ser un servidor y/o el cliente. Cada usuario de la red XMPP, tiene un identificar único conocido como JID (Jabber ID), dicho identificador es del tipo:

usuario@dominio.com

donde el @dominio es el nombre del dominio del servidor que proporciona este servicio. Google App Engine ofrece soporte para XMPP por lo que al momento de registrarnos para obtener una cuenta y crear una aplicación en App Engine, nuestro JID será:

id-aplicacion@appspot.com

El id-aplicación será aquel que indiquemos al momento de crear una aplicación en App Engine.

Para más información sobre el protocolo XMPP puedes consultar la wikipedia en español o ingles.

Google Weather API.

Se trata de un sencillo servicio que basta con invocar la siguiente URL y nos regresará la información del estado del tiempo en formato XML.

http://www.google.com/ig/api?weather=DF

Peguen la url anterior en un navegador y obtendrán un xml con la información actual y un pronostico del tiempo de los próximos días.

Dado que la información es regresada en formato XML, vamos a necesitar un pequeño y sencillo parser xml que haremos nosotros utilizando SAX.

Desarrollando el agente...

Creamos un Google Web Application Project (recuerda leer este tutorial en caso de no haber desarrollado antes con App Engine). Le podemos llamar AgenteTiempo.

Al crear el proyecto, se creará un Servlet y aquí será donde obtendremos un servicio XMPP para comunicarnos con algún JID, pero antes de ellos, vamos a desarrollar el pequeño parser.

Creamos una clase llamada EstadoTiempo con los siguientes atributos y sus respectivos setters y getters,

private String condition;
private String humidity;
private String temp_c;
private String temp_f;
private String wind_condition;

Creamos una clase llamada SaxEstadoTiempoHandler que extienda de la clase DefaultHandler. Puedes ver el código aquí. Podemos ver que sobre-escribimos el método startElement(...) y mediante el parámetro localName verificamos si se trata del elemento deseado. Como podemos ver en la siguiente imagen, nos interesan los elementos señalados en la región amarilla, condition, temp_f, temp_c, humidity y wind_condition, por lo cual en el código Java preguntamos por dichos elementos y obtenemos el valor de su atributo "data" desde el método resolveAttrib.

Ahora en el Servlet que se generó al crear el proyecto vamos a parsear el XML utilizando el handler creado anteriormente. Como podemos ver en la siguiente imagen, hemos creado un método privado y utilizado un objeto de la clase XMLReader pasandole como handler la clase SaxEstadoTiempoHandler. En el método parse de XMLReader le pasamos un objeto InputStreamReader que contiene un stream de bytes que representa el XML devuelto por la url del API de Google Weather.

Es importante indicar una codificación ISO ya que al pasarle a la url el atributo "hl=es" nos devolvera los resultados con acentos y nuestro programa podría arrojar una excepción. Una vez invocado el método parse del objeto XMLReader, construimos en un StringBuilder la respuesta que le devolveremos al usuario.

El cuerpo del mensaje que el contacto de chat envie a nuestro agente se realiza mediante un POST, por lo cual debemos utilizar el método doPost. Ver código fuente completo del Servlet.

Ya para finalizar, debemos agregar en el appengine-web.xml las siguientes etiquetas, tal y como lo describe la documentación de Google sobre el protocolo XMPP

Además de esto, en el archivo web.xml debemos modificar el url-pattern de nuestro servlet y cambiarlo por:

/_ah/xmpp/message/chat/

Y listo!!!! Finalmente estamos listos para publicar nuestro proyecto en la nube de App Engine! Como lo mencione al inicio de este tutorial, puedes ver el resultado, agregando al contacto clima-byte@appspot a tus contactos de GTalk o de algún otro servicio que utilice la red XMPP como jabber.org o desde Pidgin.

Se te puede quedar como ejercicio que el agente también proporcione el pronóstico de los próximos días! O incluso hacer algo diferente! Por ejemplo un ejercicio que se conecte al DataStore de Google usando JDO donde se encuentren almacenadas las calificaciones de alumnos y el agente le muestre las calificaciones de todas las materias actuales al alumno, claro esta, mediante alguna clave para evitar que algún curioso vea información que no le corresponde.

Saludos!!

Leyendo archivos de texto desde Groovy

2011-07-26T21:41:00.000-07:00

Hoy en el trabajo necesitaba obtener aquellos tiempos altos en funciones de Oracle que se llaman desde una aplicación web en Java. Dicha aplicación utiliza log4j y graba en el log el tiempo que tarda en ejecutar una función.

Por ejemplo, en dicho log podemos encontrar lineas como esta, siendo la marcada en amarillo la de especial interés,

De esta forma, requería estar leyendo muchos logs de más de 10000 lineas en busca de funciones cuyo tiempo sobrepasara los 2000 milisegundos.

La verdad es que no había utilizado antes Groovy y de momento se me ocurrió investigar en como podría hacer lo anterior, llegando a lo siguiente.

Como seguramente saben, Groovy es un lenguaje dinámico que corre sobre la JVM, por lo que es posible hacer uso de las mismas clases de Java.

Para leer un archivo basta con crear un objeto de la clase file e invocar al método eachLine que recibe un closure,

new File(name).eachLine( aqui closure )

Un closure es algo como un "método anonimo" y en Groovy se identifica por que esta encerrado entre signos de llaves {.......}

new File(name).eachLine(){line ->
def i = line.indexOf("Time(spring)")

En el código anterior, abrimos el archivo de texto y ejecutamos el método eachLine para iterar por cada línea que contenga el archivo. El método eachLine al obtener una línea del archivo la "depositara" en la variable "line" que será de tipo String y entonces será como podremos posteriormente utilizar el método indexOf.

Para mejores ejemplos sobre un closure, consultar aqui

El código completo es el siguiente:

Una vez medio entendiendo los closures el código de arriba es fácil de digerir, aunque realmente como tal es casi mi primer pinino en Groovy pues la verdad no me he metido con él!

Saludos!!

Introducción al Google App Engine

2011-07-23T21:39:00.000-07:00

Google App Engine es un servicio de alojamiento gratuito (1 GB de almacenamiento) de aplicaciones web escritas en Java, Phyton o el propio lenguaje de google llamado "Go". Mediante Google App Engine, google proporciona a los desarrolladores una infraestructura para instalar aplicaciones web en los lenguajes antes descritos.

En el caso de una aplicación web desarrollada en Java, es posible mediante el App Engine desplegarla en la infraestructura que google proporciona y acceder a ella mediante un dominio gratuito del tipo http://name.appspot.com

Google App Engine proporciona un soporte para el desarrollo de aplicaciones Java en sus versiones 5 o 6 y de API's y Frameworks tales como:

JavaServlet API 2.4
Java Server Pages
Java Server Faces 1.1-2.0
JPA y JDO
JavaMail
Groovy
BlazeDS
Spring MVC
Spring ORM
Struts 1.0 - 2.0
Tapestry
WebORB
etc...... más información

Para comenzar a utilizar App Engine, debemos crear una cuenta gratuita entrando al siguiente link , se nos pedira un número de celular a donde se nos enviara un código de confirmación, mismo que deberemos introducir. En el caso de México, el número de celular debe ser de la compañía Movistar (telcel, iusacell, etc., no funcionan), antes del número debemos introducir el código del país, por ejemplo, si fueras de México debes introducir algo como:

+52 xxxxxxxxxx

donde +52 es el código del país México.

Una vez creada la cuenta, mediante el Plugin de Google para Eclipse, podemos crear aplicaciones Java utilizando el SDK de App Engine, además de poder desarrollar aplicaciones utilizando el conocido GWT. Al instalar el plugin para eclipse, podemos también instalar el SDK de App Engine, por lo que no será necesario descargar el SDK y el Plugin por separado.

Ya instalado el plugin, podemos inmediatamente crear una aplicación utilizando App Engine y publicarla muy fácilmente. Para crear un proyecto, basta con seleccionar la opción indicada en la imagen.

En la Guia de Introducción a App Engine que ofrece Google en español, se desarrolla en primera instancia parte del siguiente código en un Servlet.

Al crear el servlet con eclipse y escribir el código anterior, es muy fácil probar la aplicación localmente. El SDK de App Engine, incluye un servidor local que simula todos los servicios que ofrece la infraestructura de App Engine, por lo cual podremos simular nuestra aplicación web localmente antes de instalarla en el servidor de Google.

Para ejecutar la aplicación anterior, basta con ir al menú Run > Debug As > Web Application , y entonces en el navegador teclear:

http://localhost:8080 ó http://localhost:8888

dependiendo del puerto que se inicialice.

Como página principal se muestran los Servlets disponibles, al dar click sobre "Guestbook" se ejecutará el código anterior, el cual presentará una pantalla que pedirá un correo como cuenta de Google para poder autenticar, dado que estamos en el ambiente local, se mostrará una pantalla como la siguiente, pero en caso de que la aplicación ya este publicada en nuestro dominio de App Engine, entonces se mostrará la pantalla de Google donde se pide nuestra cuenta:

Pantalla en servidor Local

Pantalla al instalar la aplicación en dominio de App Engine

Una vez que nos hemos autenticado, entonces se mostrará el mensaje que pusimos en el Servlet, que en este caso será algo como:

Hello, molder.itp

Para publicar la aplicación, primero debemos dirigirnos al archivo appengine-web.xml y en las etiquetas  escribir el id de la aplicación que es el mismo que escribimos al crear nuestra cuenta de App Engine, en mi caso fue "mundo-byte" tal como lo podemos ver en nuestra cuenta,

También debemos indicar el número de versión. Finalmente el archivo de configuración quedará similar al siguiente:

Hecho lo anterior, ya podemos publicar nuestra pequeña aplicación desde Eclipse dando click al ícono mostrado en la siguiente imagen:

Y listo!! el resultado lo podremos visualizar con la url de nuestro dominio, que en mi caso es la siguiente:

http://mundo-byte.appspot.com/guestbook

Hemos visto lo fácil que resulta publicar una aplicación web Java utilizando el AppEngine, sin duda una buena opción para varios desarrollos! Espero más adelante compartir más cosas acerca del App Engine de Google.


Saludos!!

Pruebas automatizadas en Interfaz de Usuario

2011-04-18T18:42:00.000-07:00

En una entrada anterior, escribía sobre la existencia de SeleniumIDE, un plugin para Firefox con el cual podemos ejecutar pruebas en la interfaz de usuario de una manera un poco más automatizada.

En realidad puede ser muy útil, tiene muchos comandos que sirven para simular casi todo lo que un usuario humano podría hacer.

Por ejemplo, el siguiente video que hice, muestra una prueba muy sencilla pero en un Sistema real implementado en ambiente productivo (claro, la prueba fue hecha en un ambiente de test).

La prueba es tan sencilla que solo consta de comandos click, doubleClick, select, y un assertConfirmation el cual sirve cuando la aplicación lanza un cuadro de confirmación con JavaScript y con este comando Selenium da por hecho que debe aceptar la confirmación.

En YouTube existen algunos pocos tutoriales que pueden servir de inicio.

Desarrollo Rápido de Aplicaciones con Oracle

2011-04-16T22:55:00.000-07:00

INTRODUCCIÓN

Cuando escuchamos Oracle, a la gran mayoría nos viene a la mente esa Base de Datos Relacional que tiene fama de ser la mejor de entre las actuales, sin embargo, hace algunos días conocí "Oracle Application Express" conocida como APEX, la cual es una Herramienta para el Desarrollo Rápido de Aplicaciones (RAD) que utilizan una Base de Datos Oracle y se basa en una interfaz web, lo mejor de esto es que se puede descargar gratuitamente y utilizarse incluso sobre Oracle DataBase Express Edition. Con APEX podemos crear rápidamente aplicaciones web que hagan uso de una base de datos Oracle, incluso con APEX podemos conectar con servicios web.

Voy a mostrar de una forma muy rápida de como crear un sencillo formulario de registro, por lo que tenemos dos formas de seguir este tutorial,

Descargar e Instalar localmente APEX, lo que incluye también tener instalado Oracle DataBase. Queda fuera de este tutorial los pasos de instalación y configuración.
Crear una cuenta gratuita en http://apex.oracle.com , la cual esta sujeta a una previa aprobación. Al final de los pasos de la creación de la cuenta, se te pedirá una justificación por la que deseas obtener una cuenta demo, basta con poner alguna palabra como "education", que en mi caso, la cuenta fue aprobada casi automáticamente.

LA INTERFAZ WEB DE APEX

Como lo comentamos, APEX esta basado en una interfaz web y con muy pocas líneas de código, podremos tener una aplicación web profesional.

Una vez creada nuestra cuenta, veremos una interfaz similar a la imagen. Podemos crear y administrar aplicaciones web, navegar por las tablas contenidas en nuestro esquema, ejecutar sentencias SQL, administrar usuarios, servicios y monitorear actividad, etc.

En este momento, nos centraremos en la opción "Application Builder"

CREANDO LA APLICACIÓN

Seleccionando la opción Application Builder,

Click en botón Create
Seleccionar DataBase en el Application Type
Crearemos una aplicación desde cero, seleccionando From Scratch
Tecleamos un nombre para nuestra aplicación y un ID que ya nos da por defecto, así como seleccionamos el nombre del Schema a utilizar.
Con esto ya tenemos creada una aplicación, sin embargo, una aplicación esta compuesta por Pages, por lo que ahora debemos seleccionar el tipo de página que deseamos. Cabe resaltar dos opciones,

Form: Creará un clásico formulario donde existirán cajas de texto, introducimos los valores y damos click en guardar.

Tabular Form: Creara como su nombre lo indica, un formulario tabular, es decir, nos mostrará los datos existentes en una determinada tabla de base de datos en forma tabular y con la posibilidad de actualizar directamente los datos que deseamos.

Seleccionamos Form y en la parte de abajo el nombre de la tabla sobre la cual basaremos el formulario. Por el hecho de crear nuestra cuenta demo en APEX, tenemos una serie de tablas ejemplo, dos de ellas son EMP y DEPT, seleccionamos DEPT por ser la más sencilla y click al botón Add Page.
Click en Siguiente.
Seleccionamos No Tabs y click en Next.
Seleccionamos que NO deseamos copiar componentes compartidos.
Una parte importante de las aplicaciones web es un sistema de autenticación de usuarios, APEX nos proporciona ya unos mecanismos muy sencillos de utilizar, seleccionaremos las opciones como lo muestra la imagen,

Ahora debemos seleccionar un Theme para nuestra aplicación. Afortunadamente también tenemos posibilidad de crear temas propios. En este caso, yo seleccionaré el Theme 20. Click en Next
Finalmente verificamos que la información sea correcta y damos click al botón Create.

Ya tenemos la aplicación creada y podemos ver que esta compuesta de dos página, una de ellas es la página que creamos en los pasos anteriores y la otra es la página de autenticación que en la imagen aparece como "101 - Conectar" debido a la mala traducción :)

Damos click sobre el ícono 1-Dept
En la columna Page Rendering damos doble click sobre P1_DEPTNO

Editamos su propiedad Display As.. y seleccionamos Text Field. Guardamos los cambios.

Regresaremos a la pantalla anterior y solo resta presionar el botón de Run. Se nos mostrará como primer página la autenticación de usuario. Por defecto, el usuario existente es el mismo que el de nuestra cuenta demo de APEX.

Una vez que nos hemos identificado, podremos ver el pequeño formulario de registro de Departamentos, que basamos en la tabla DEPT de la base de datos Oracle que ya existía al momento de crear nuestra cuenta demo.

Podemos especificar que el Deptono sea una secuencia o un trigger para no tener que insertarlo manualmente.

En otro tutorial escribiré como hacer otras cosas más interesantes, pero este fue un primer acercamiento a esta buena herramienta de Oracle que nos puede ayudar a realizar ciertas cosas de manera muy fácil.

Mi primer texto en Illustrator CS5

2010-12-12T12:56:00.001-08:00

Bueno, algo que siempre quise aprender desde que comencé en esto del desarrollo de software, fue algún programa de dibujo vectorial como Illustrator. Soy todo menos diseñador, pero creo que con un poco de práctica puedo mejorar significativamente!

Les comparto este video de Youtube donde muestra como poner nuestro nombre con Illustrator agregando algunos degradados y transparencias. No me quedo como en el video, pero espero ir mejorando!

Y aquí el resultado :(

CMS: Java México

2010-09-16T21:09:00.000-07:00

javamexico

La comunidad de Java México, inicio hace unos meses el desarrollo de un Administrador de Contenidos (Foros, Blogs, Bolsa de Trabajo, etc). El proyecto será OpenSource (GPL v3) y estará desarrollado sobre las tecnologías:

Tapestry 5
Spring 3
Hibernate

He descargado e instalado el proyecto, y desde luego que la idea es participar como desarrollador. Como acertadamente lo comentan, es una buena opción para hacer crecer el CV. Tapestry es un Framework para el desarrollo MVC, tipo Struts, pero hasta donde puedo ver, es mucho más simple y elegante, así que es una gran oportunidad para aprender. Aquí, Enrique Zamudio publica un introducción de Tapestry dividida en 5 partes para despertar la curiosidad a muchos desarrolladores que no conocíamos este framework.

Los invito pues a darse una vuelta por la comunidad Java México y a participar en este proyecto, tanto si eres un desarrollador novato, es una buena oportunidad para crecer en conocimientos y participar de algún modo.

Aprendiendo Lean Software: Eliminar el Derroche

2010-08-30T21:28:00.000-07:00

ANTECEDENTES
Cuando estudiaba el 6to Semestre de la carrera, entré a laborar a una pequeña fabrica de software en Pachuca, Hidalgo (México). De 2 años para acá comencé a interesarme en temas más específicos de Ingeniería de Software pasando por la Administración de Proyectos, Casos de Uso, hasta metodologías y procesos como MoProSoft y Personal Software Process. Confieso que desde un inicio nunca pude comprender al 100% estas prácticas de métodos formales, sin embargo las acepte en un inicio. Más adelante la relación entre estas prácticas y yo fue insostenible y las abandone para dar paso a la filosofía ágil de la cual sencillamente estoy encantado.

A partir de aquí, inicia una serie de comentarios que expresan mi opinión personal (muy posiblemente equivocada) sobre bibliografía y material que voy estudiando con el objetivo de crear notas y compartirlas principalmente con estudiantes de carreras afines.

¿QUÉ ES LEAN SOFTWARE DEVELOPMENT?
Comparto con ustedes un video-presentación que realizó Emilio Osorio donde explica lo que es Lean Software y sus principios básicos. Debajo de la presentación, comparto mi poca experiencia, opiniones personales y posiblemente no tan acertadas pero que eso es lo que hace tan valioso a la filosofía ágil, que no existe una receta a seguir y que el proceso se debe amoldar según el entorno.

¿Qué es y por qué funciona el Lean Software Development? from SG Campus on Vimeo.

PARA INICIAR...

Debo comenzar diciendo lo que digo siempre que hablo de metodologías formales.

Martín Fowler, un Gurú en el mundo de Java comenta en su artículo The New Methodology, que las metodologías formales basan sus principios en otras Ingenierías como la Civil y la Mecánica, en donde la mayoría de sus problemas, son susceptibles de un análisis matemático y modelado previo a la construcción. Los métodos formales y nuestros maestros nos enseñaron que en el Software la mejor forma de hacer las cosas bien, son hacerlas a la primera! El error de la Ingeniería de Software tradicional es tratar al desarrollo de Software como un fenómeno predictivo de otras ingenierías, entendiendo como predictivo aquello que es susceptible de un modelado y de un análisis matemático para predecir el comportamiento de un Sistema al aplicar una fuerza.

Pueden leer este otro artículo que escribí titulado ¿Por qué fracasan los proyectos de SW?... Este artículo lo considero bien documentado, y es sencillamente una recopilación de ideas que varios autores a nivel mundial han escrito.

PRINCIPIO 1: ELIMINAR EL DERROCHE

Como desarrolladores estamos tentados a comenzar por desarrollar aquellos módulos más fáciles o más bonitos ó con más reto personal, aunque éstos no agreguen un valor de negocio al usuario, , peor aún, desarrollamos cosas que el cliente no pide. Por ejemplo si debemos desarrollar un Sistema de Reporte de Ventas, muchas veces como desarrolladores comenzamos desarrollando la funcionalidad que grafique los datos, aunque quizá el cliente solo pidió tabularlos, peor aún, desde la filosofía ágil, nosotros debemos entregar funcionalidad cada 2 o 3 semanas, desde esta perspectiva quizá hemos omitido el desarrollo de la autenticación y autorización al sistema y hemos dado paso a desarrollar funcionalidades que no son prioridad en ese momento.

Alguien podría preguntarse ¿Y el desarrollar la funcionalidad para que grafique datos no es algo bueno?... Seguro que sí, pero si el cliente inicialmente no lo pidió, debemos mejor entregar una pieza de software funcional y usable con el que el cliente/usuario comience a trabajar. El usuario, al ver el sistema en funcionamiento seguramente pedirá los datos graficados y más funcionalidad extra, pero en ese momento, él ya estará sacando provecho al Sistema.

Finalmente en este momento puede venir una pregunta más para el lector, con lo anterior ¿no estamos propiciando a que el cliente pida y pida de forma insaciable nuevos requerimientos?... Desde luego,... Pero entonces el proyecto no será costeable para la empresa!... Bueno, desde la perspectiva tradicional efectivamente el proyecto no será costeable, saldrá de sus límites y no será un buen negocio para la empresa que desarrolla el Software, pero desde la perspectiva ágil sencillamente se pagara justo lo que se desarrolla con el plus de que tendremos a un cliente bastante contento. A diferencia de los métodos formales, los métodos ágiles te impulsan a entregar funcionalidad cada 2 o 3 semanas, de tal forma que el costo del desarrollo no se va sobre el proyecto, sino sobre funcionalidad. El cliente no pagará un Sistema, más bien pagará funcionalidad hasta completar un Sistema, de esta forma, si el cliente posteriormente agrega más requerimientos sobre algo ya desarrollado, podremos justificar más fácilmente un costo extra con el plus que el cliente al estar contento no tendrá tantos inconvenientes en pagar por mejorar o agregar funcionalidad extra de algo que ya esta usando. En el caso de una mejora, incluso la misma empresa que desarrolla, puede pensar en no realizar un cobro extra.

Como lo dice Emilio en su presentación, el derroche será todo aquello que no agrega valor al negocio del cliente. No debemos confundir "Eliminar el derroche" con no desarrollar o proponer requerimientos que tengan un valor agregado al negocio del cliente, por el contrario, siempre es buena idea dar un valor agregado al negocio del cliente, una ventaja competitiva que lo ponga un paso adelante sobre sus competidores. Debemos eliminar documentación innecesaria como Diagramas UML, planeaciones en gantt, decenas o cientos de hojas de Casos de Uso.

Lo anterior resulta muy delicado dado que el RUP y las herramientas como UML son tan aceptadas en nuestra industria, sería muy difícil de entender y aceptar que el 90% de los diagramas de UML son en su mayoría inútiles. ¿Qué tan similares son los diagramas de clases realizados al inicio con las clases que se tienen al término del proyecto? La verdad es que son muy diferentes. Si alguien en este punto esta pensando que el Diagrama de Clases es útil por que nos da una vista rápida de como esta construido el sistema, obviamente que desconoce de las herramientas de Ingeniería inversa que nos ayudan a generar diagramas en base a las clases de un Sistema. Existen numerosos autores que ponen en duda la utilidad de UML, muchos otros autores reconocidos como Craig Larman conscientes de los puntos débiles del RUP pero convencidos de su utilidad defienden su utilización desde un punto de vista ágil. Para efectos de este punto, podemos leer un artículo de Bertrand Meyer (el creador del Lenguaje Eiffel) titulado "UML: The Positive Spin" donde verdaderamente se burla de lo absurdo que puede resultar el UML. De igual forma, podemos leer "Death by UML Fever" donde se explica que verdaderamente tenemos una Fiebre de UML. En conclusión podemos decir que UML puede resultar una buena herramienta de modelado post-development, como base para generar documentación para el mantenimiento del Sistema, pero no resulta tan bueno para generar documentación de requerimientos y análisis.

Son muchísimas cosas que agregan un derroche a nuestros proyectos, y considero yo que para este punto, solo falta un poco de sentido común para detectarlo.

Más adelante continuaré con los principios restantes de Lean Software, mientras tanto debí seguir leyendo el libro de Mary Poppendieck que me regalaron.

Saludos!

Material: Lean Software Development

2010-08-29T16:28:00.000-07:00

Les comparto algunas presentaciones con audio que realizo el buen Emilio Osorio. Emilio es una de las personas que más fuerte evangeliza los principios ágiles en México, especialmente encantado por los principios de Lean Software Development.

¿Qué es y por qué funciona el Lean Software Development? from SG Campus on Vimeo.

Las cinco practicas esenciales del Desarrollo Lean-Agile from SG Campus on Vimeo.

Cómo hacer de tu grupo de desarrolladores un Equipo de Alto Desempeño from SG Campus on Vimeo.

Requerimientos de SW, ¿Cuántos kilos le damos?

2010-08-23T22:05:00.000-07:00

El domingo anterior a escribir este post, fui a comer a un mercado de la ciudad de Pachuca, Hidalgo. Todavía iba caminando, aún ni me sentaba cuando ya me estaban preguntando si deseaba sopa o arroz, además de decirme la lista completa de guisados. Luego pues, decidí parar y sentarme a comer. Lo primero que hicieron fue darme como 1/2 kilo de tortillas. Al inicio todo iba bien ya que entre más tortillas me daban, más rápido comia y más pedia. Conforme fui avanzando en la comida, me fui dando cuenta que las muchas tortillas que me dieron en un inicio se acumularon, se estaban enfriando, que sencillamente eran innecesarias tantas en un inicio, pues termine pidiendo que me las cambiaran por otras menos frias.

Termine por darme cuenta que lo que me estaba pasando, era un ejemplo muy burdo de lo que pasa en el Desarrollo de Software (burdo pero muy cierto).

Yo era como el cliente/usuario que desea un Sistema de computo, usuario que desde un inicio sabe que necesita de algo que satisfaga sus necesidades, pero al poco tiempo se dejan escuchar miles de voces que te ofrecen una amplia gama de funcionalidades, opciones, mejoras, etc., muchas veces innecesarias. Ya habiendo entrado en el juego, el usuario se sienta a la mesa listo para definir sus requerimientos, sin embargo, los expertos Consultores, Project Managers, PMI, etc., comienzan a invadir al usuario con kilos de requerimientos, decenas y decenas de Casos de Uso, diagramas, diccionarios de datos, Interfaces, etc., requerimientos que con el paso del tiempo se van "enfriando", perdiendo así su valor original y el usuario termina por cambiar dichos requerimientos por algunos más refinados.

La dinámica del software es cambiante, su ámbito no es del todo predecible, sin embargo esto es algo de lo que aún no entendemos, nos aferramos a utilizar técnicas y metodologías predecibles que basan sus principios en otras ramas de la Ingeniería como la Mecánica y/o Civil en donde la mayoría de sus problemas son susceptibles de un análisis matemático, modelado y simulación, sin embargo, en el desarrollo de Sw no podemos forzar y modelar una Arquitectura detallada del Sistema mediante diagramas UML que en papel se ven bien, pero al momento de implementarlo es donde comienzan los problemas.

Nosotros como desarrolladores, líderes de proyecto, analistas, etc., debemos entender bien lo anterior y ayudar al usuario en el camino a descubrir que cosas son las que Él realmente desea, en lugar de abrirle un abanico de opciones desde un inicio. Si desde un inicio le ofrecemos kilos y kilos de tortillas, corremos el riesgo de que al paso del tiempo el usuario nos las devuelva y pida algo más reciente!

Los métodos ágiles nos proporcionan sencillos pero sólidos principios que nos ayudan a tener un cliente/usuario satisfecho pues generalmente tienen lo que realmente quieren, ya que lejos de hacer una toma de requerimientos detallada, la vamos refinando conforme avanzamos en el camino, evitando así trabajar "en valde" o innecesariamente ya que con las constantes reuniones y entregas rápidas de funcionalidad al usuario, éste puede ir descubriendo más fácilmente lo que realmente quiere y necesita.

¿Y tú cuántos Kilos de Requerimientos le ofreces a tu cliente/usuario?

Saludos!!

Introducción a los WebService I: Práctico y Fácil

2010-08-19T21:54:00.000-07:00

Nivel: Intermedio
Se requieren conocimientos de programación. Este tutorial es meramente didáctico y se ha desarrollado a modo de ser entendible para usuarios sin experiencia en el tema, de tal modo que se pudieron omitir configuraciones.

INTRODUCCIÓN

¿Alguna vez se han preguntado de que manera los Sistemas de Banca en Línea por Internet pueden ofrecer a sus usuarios servicios tales como, recarga de tiempo aire, pago de tarjeta de crédito, pago de recibos de luz y agua, etc?

En primera instancia quizá esto sea poco importante, irrelevante, pero si nos detenemos y pensamos un poco en que las diferentes compañías como Telmex, CFE, Bancomer, Sky, Movistar, etc., tienen sus Sistemas desarrollados en diferentes plataformas (.NET y Java generalmente) ¿Como es que podrían comunicarse plataformas diferentes?

Pago de Servicios de la Banca en Línea de Banco Azteca.

¿Como podrían comunicarse dos personas que hablan un idioma diferente?...

La respuesta a esto son los WebService! Los WS publican unos descriptores XML llamados WSDL que definen una interfaz de comunicación para que otros WS Cliente puedan hacer uso de ellos e invocarlos. Para entender de mejor forma lo anterior, podemos imaginar a dos personas que hablan idiomas diferentes y sin embargo desean comunicarse entre si de forma efectiva, así que uno de ellos publica una interfaz que la otra persona pueda entender como por ejemplo una serie de dibujos (escritura pictográfica) o de movimientos (mimica) y a esta interfaz es a lo que llamamos el WSDL. De esta forma ambas personas aunque hablen un idioma diferente podrán comunicarse.

Mediante los WS, por ejemplo, la Banca en Línea de Banco Azteca puede ofrecer a sus clientes el pago de diversos servicios, pues sencillamente hace uso de los WS que otras compañías publican, crea un cliente para consumir esos WS y listo! tendremos a Sistemas desarrollados en diferentes plataformas comunicandose.

Existen diversos "tipos de WebService", dos de los más comunes son los:

Basados en el protocolo SOAP
Basados en Rest

En este tutorial dividido en 2 partes veremos los más clásicos, los que utilizan el protocolo SOAP.

HERRAMIENTAS UTILIZADAS

JDK 5
Apache Tomcat 6
Apache Axis 2 WAR
Eclipse Helios
Mac OS X 10.6.1

Nota --> La instalación de Tomcat es muy sencilla y funcional siguiendo este tutorial.

DESARROLLO

Para iniciar debemos desplegar el WAR de Axis en Tomcat e invocar la siguiente URL

Debemos validar que tenemos las librerías esenciales para el correcto funcionamiento de axis, para ello basta con dar click al botón de Validate.

Ahora mediante Eclipse vamos a crear un proyecto Java común y corriente y una clase llamada Saludo:

Posteriormente crearemos un archivo xml al que llamaremos services.xml en una carpeta a la que llamaremos META-INF y estará en la raíz del proyecto, de tal forma que debe lucir algo así:

Así pues, vamos ahora a exportar dicho archivo a un JAR que los WS conocen como AAR. En eclipse damos click derecho sobre el proyecto y damos click a export. Seleccionamos JAR File y escribimos un nombre poniendo la extensión ".aar".

Finalmente vamos a la consola de Administración de Axis. Nos pedira un Usuario y Password, así que tecleamos "admin" y "axis2" respectivamente. En la parte de Upload Service podremos subir el archivo que generamos.

Si todo sale bien, en Available Service tendremos el WS que hemos subido.

Si damos click sobre el nombre del WS, nos abrirá una página en blanco, pero si vemos su código fuente, veremos el famoso archivo WSDL que será el que utilizaremos en la segunda parte de este artículo para generar un cliente que consuma este WS.

En esencia, los WS son sencillos de implementar, aunque como toda tecnología, tienen sus puntos complicados.

Saludos!!

Pruebas Automatizadas: Selenium IDE

2010-07-24T20:24:00.000-07:00

Selenium IDE es una útil herramienta para desarrollar pruebas automatizadas a nivel de Interfaz de Usuario para Aplicaciones Web. Se presenta como plugin para Firefox y puede utilizarse para cualquier otro navegador mediante Selenium RC. Su uso es muy sencillo, sin embargo, la cantidad de comandos y la poca documentación existente puede dificultar su implementación en grandes proyectos.

Selenium memoriza los comandos ejecutados por nosotros como por ejemplo, escribir palabras en cajas de texto, click a submit y esperar a cargar la página, verificar texto, click a links, entre muchos más. Al memorizar estos comandos, Selenium es capaz de ejecutarlos posteriormente y reproducir fielmente las acciones que previamente realizamos. El resultado es ver como nuestra aplicación es probada como por arte de magia sin intervención nuestra.

La importancia de las pruebas automatizadas es esencial, pudiendo programarlas para ejecutarse al termino de la codificación de un módulo, ejecutarlas diariamente por las noches, etc.

Pueden descargarlo y ver un video tutorial sobre su uso en la página oficial.

Saludos!!

Presentando JUnit y Selenium

2010-06-25T21:00:00.000-07:00

Vengo en el ADO, voy para Pachuca y la película esta aburrida, así que aqui vamos.

El día de hoy en el trabajo realice una presentación al equipo de desarrollo de la Gerencia para la que trabajo, el tema en cuestión fue "Pruebas Unitarias". Podría decir que al menos desperte una cierta curiosidad entre los desarrolladores, aunque me temo que esa curiosidad les dure muy poco.

Durante la platica mencione a JUnit y a Selenium IDE como dos grandiosas herramientas. Lo más difícil de explicar y hacer notar su utilidad fue JUnit, lo más fácil fue Selenium. Al final de la presentación se toco el tema de "diseño del sistema" o Arquitectura... Ese era el momento ideal para hablarles de TDD y sus ventajas no como una buena práctica de testing sino como un excelente marco para guiar al equipo por un buen diseño, después de todo su nombre lo dice (Test Driven Development), pero bueno, me detuve en primera x que soy un niño en ese tema y aun continuo un camino de aprendizaje y en segunda por que considero que si el equipo no realiza pruebas unitarias y yo comienzo a decirles que primero hay que programar una prueba para algo que aun no existe, seguramente me hubieran tirado más de a loco.

No cabe duda que es por demás interesante la implementación de buenas prácticas en un proceso de software y más aún cuando se le da un enfoque agile. No perdi la oportunidad para mencionar de pasada a eXtreme Programming y Scrum, claro que ni siquiera mencione bien para que son ya que no queria parecer ñoño, pero deje plasmadas dichas palabras en las diapositivas.... espero que algún curioso pueda investigar sobre Scrum y XP!!!

Ya les platicare posteriormente como nos va en este camino que recién inicio... si, la idea es comenzar a implementar prácticas ágiles muy sencillas.

Saludos!!

2 Herramientas: Monitor de Logs y Screenshot Tool

2010-06-21T18:08:00.000-07:00

Les voy a presentar 2 sencillas pero muy útiles herramientas que podemos utilizar en nuestro trabajo diario como Desarrollador de Software:

Tail for Win32: Tail es un programa para monitorear los cambios que ocurren en tiempo real en archivos de texto. Con Tail podremos monitorear los archivos de Log del Servidor de Aplicaciones o de nuestra aplicación Java/.NET/etc., que tengan un archivo de Log usando por ejemplo Log4J. Algunas cosas interesantes y bastante sencillas son el hecho de poder definir keywords y Tail en tiempo real nos mostrará la salida del Log marcando de colores aquellas keywords que hayamos definidio previamente.

2. GreenShot: Cuantas veces como desarrolladores nos vemos en la necesidad de aclarar rápidamente a un usuario algunas opciones del Sistema, incluso imprimiendo capturas de pantalla y poniendo flechas y texto para un mayor entendimiento por parte del usuario. GreenShot es casi un clon de Snagit, a diferencia que GreenShot es Open Source. Su uso es tan sencillo que basta con presionar la tecla "Impr Pant" e inmediatamente podremos seleccionar una sección de pantalla y listo!! Podremos ver la sección que hemos recortado en el editor de GreenShot en caso de que necesitemos agregar flechas, marcar algún texto, etc., o en su defecto omitir dicho editor y pegar la sección de imagen que hemos recortado en nuestro correo electrónico, listo para ser enviado! En menos de 5 segundos tenemos una útil captura de pantalla y ya no será necesario abrir el no tan útil MS Paint.

¡¡¡El cliente no sabe lo que quiere!!!

2010-06-06T20:45:00.000-07:00

Cuando usted era un jovenzuelo (como yo al momento de escribir este artículo), cuando comenzaba a realizar su vida propia y comenzó a ganar un poco de dinero, seguramente por su mente paso el comprar un automóvil, cuentas bancarias, etc., y si usted al igual que yo, llego a la ciudad originario de provincia, al inicio muchas cosas le son desconocidas, usted sabía que quería tener un automóvil, pero no tenia muy claro que tipo de auto le convenía ni con que características.

¿Qué tipo de motor?
¿Que tipos de frenos? ¿de disco, de tambor, antiblockiersystem?
¿Que tipo de suspensión?
Velocidad máxima, tiempo de aceleración.
Costo de mantenimiento y refacciones.
Costo de tenencia (en México).

Usted disponía de un presupuesto, y para aclarar todas sus dudas, lo mejor era consultarlo con los expertos de las agencias o incluso con sus mismos amigos... Si usted estaba convencido que quería un Automóvil pero no tenia claro los tipos de características que hacen atractivo a un automóvil según su presupuesto, ¿podríamos concluir que usted no sabia lo que quería?... Pues SÍ, aunque también podría ser NO.

En el desarrollo de Software estamos muy acostumbrados a gritar la frase "El cliente no sabe lo que quiere" siempre que algo sale mal y desafortunadamente la indecisión en el desarrollo de software es más compleja que el ejemplo del auto. En un inicio el cliente sabe que necesita automatizar sus procesos de negocio y hacerlos más efectivos y dinámicos, que le permita una toma de decisiones más certera, pero pese a lo anterior, tiene muchas dudas de el alcance y hasta donde la tecnología le puede ayudar, y esto es parte de la naturaleza de trabajar con cosas abstractas e intangibles.

Bajo la mirada de la filosofía ágil, el cambio de requerimientos es algo natural al cual debemos adaptarnos, de ahí que en Scrum se recomiende hacer entregas con valor de negocio mínimo cada 2 semanas hasta 1 mes como máximo, de esta forma el cliente podrá ir validando, refinando y agregando nueva funcionalidad con una idea mucho más clara a lo largo de la duración del proyecto y de ningún modo tendrá que vaciar sus requerimientos en largos e inútiles documentos que inevitablemente cambiaran con el tiempo, además de crear una mala relación entre cliente-consultora.

Requerimos un cambio de filosofía, dejar de pensar que el cliente es quien comete los errores, el cliente al igual que nosotros no tiene muy claro lo que quiere, dado que no es experto en tecnología y en un principio no esta consciente de todas las cosas que la tecnología le puede ayudar, esto último lo va descubriendo conforme puede ir probando funcionalidad. La comunicación Equipo de Trabajo - Cliente es importante para el éxito de un proyecto, olvidémonos de la vieja comunicación Cliente - Líder/Gerente - Equipo de trabajo... En este ámbito, los puentes en la comunicación no sirven, bajo NINGUNA circunstancia, NO HAY EXCUSA para hacerlo.

Más vale el desarrollo iterativo y adaptarse al cambio, la frase "¡¡¡El cliente no sabe lo que quiere!!!" debe ser cosa del pasado, debemos saber convivir con el cambio, negociar tiempos de entrega, de esta forma tendremos a un cliente más contento que al estar culpándolo por los cambios.

DB4O: Una Base de Datos Orientada a Objetos

2010-06-02T20:56:00.000-07:00

DB4O es una Base de Datos Orientada a Objetos que cumple muy bien su función, persistir datos de aplicaciones de pequeña y mediana escala.

Los modelos Relacional y Orientado a Objetos son ciertamente incompatibles, en términos simples, al desarrollar una aplicación con Base de Datos no almacenamos objetos, si bien nos va, utilizando un patrón de diseño DAO podemos "abstraer" un poco la complejidad de la persistencia en la capa web y pasarla a una capa de persistencia para que sea otra persona quien la implemente, o mejor aún, de una forma más sofisticada emplear un Framework ORM como Hibernate. Pero en el peor de los casos, al trabajar con una BD Relacional utilizamos variables escalares y enviamos sus valores a la BD.

Sin entrar en polémica sobre la utilización o no utilización de SQL embebido código de un Lenguaje de alto nivel o la utilización de un ORM, es bueno considerar a DB4O como una alternativa real y potente para muchos de los proyectos que podamos desarrollar.

Su utilización es tan fácil que para abrir una conexión basta hacer algo como:

ObjectContainer db = Db4o.openFile(DB4OFILENAME);

Y para persistir información basta con escribir:

db.store(usuario);
db.close();

Sin mapeos, ni XML, ni SQL, ni concatenación de variables a String que contiene SQL!! Basta con crear el objeto y emplear el método save.

Existe una versión de DB4O para Java y una más para C#, mismas que pueden descargarse de la página oficial.Para nuestro ejemplo en Java basta con agregar a nuestro entorno de programación (Eclipse, NetBeans, etc) el archivo db4o-7.4.88.12908-java5.jar.

Al descargar la librería de la página oficial, nos vendrá con una completa documentación, incluido un muy buen tutorial en ingles y español sobre su utilización.

Un sencillo y austero ejemplo en NetBeans se puede descargar de aquí

Inyección de la Dependencia II: Práctico y Fácil

2010-04-17T22:52:00.000-07:00

En la primera parte vimos un ejemplo por demás sencillo, el clásico Hola Mundo! utilizando la Inyección de Dependencia mediante Spring!

En esta segunda parte, continuaremos con otro ejemplo igual de sencillo, más útil, pero que al final de cuentas nos encontraremos con un problema!

Buscando Archivos!
Vamos a realizar un sencillo buscador de archivos! El API de Java incorpora una interfaz llamada FileFilter que contiene al método accept, este método deberá contener toda la lógica requerida para filtrar de una lista de archivos, aquellos que cumplan con nuestras características! De tal modo que pasaremos una referencia de FileFilter al método listFiles de la clase File.

Para empezar, creamos una clase que implemente a la interfaz FileFilter.

package archivos;

import java.io.File;
import java.io.FileFilter;

/**
 *
 * @author windoctor
 */
public class FileExtensionFileFilter implements FileFilter{

    private String extension;

    public FileExtensionFileFilter(String extension){
        this.extension = extension;
    }

    public boolean accept(File pathname) {
        String nameLower = pathname.getName().toLowerCase();

        return (pathname.isFile() &&
                (nameLower.indexOf(extension) > 0)? true:false);
    }    
}

Posteriormente, vamos a crear una clase que se encargue de listar todos los archivos que cumplan con nuestro criterio de búsqueda!

package archivos;

package archivos;

import java.io.File;
import java.io.FileFilter;
import java.io.FileNotFoundException;

/**
 *
 * @author windoctor
 */
public class BuscadorArchivo {
    private String directorio;
    private String extension;
    private FileFilter filter;

    public BuscadorArchivo(String directorio, String extension){
        this.directorio = directorio;
        this.extension = extension;
    }

    public File[] listar() throws FileNotFoundException{
        File dir = new File(directorio);
        //Si no existe, lanzamos una excepción
        if(!dir.exists())
            throw new FileNotFoundException
                    ("No existe el directorio "+directorio);

        //Este es nuestro filtro, el cual pasaremos al método listFiles
        filter = new FileExtensionFileFilter(extension);
        File[] files = dir.listFiles(filter);

        if(files == null || files.length <= 0){
            System.out.println("No existen archivos "+extension);
            return null;
        }
        else
            return files;
    }
}

Ahora en el applicationContext.xml vamos a agregar la definición de la clase anterior:

<bean id="beanArchivo" class="archivos.BuscadorArchivo">
   <constructor-arg index="0" value="/home/windoctor/Documentos" />
   <constructor-arg index="1" value=".mp3" />
</bean>

Como vemos, la clase BuscadorArchivo tiene un constructor que recibe 2 parámetros de tipo String y que serán inyectados vía Spring. De tal suerte que al ejecutar el siguiente código, obtendremos una lista de archivos:

package archivos;

import java.io.File;
import java.io.FileNotFoundException;
import org.springframework.beans.factory.BeanFactory;
import org.springframework.beans.factory.xml.XmlBeanFactory;
import org.springframework.core.io.FileSystemResource;

/**
 *
 * @author windoctor
 */
public class ArchivoMain {
    public static void main(String args[]){
        BeanFactory factory = new XmlBeanFactory(
                new FileSystemResource("web/WEB-INF/applicationContext.xml"));
        BuscadorArchivo buscador = (BuscadorArchivo)
                factory.getBean("beanArchivo");
        try {
            File[] files = buscador.listar();
            int size = files.length;
             //Ahora que tenemos todos los archivos filtrados, solo los listamos
            for(int i = 0; i < size; i++){
                File file = files[i];
                String nameFile = file.getName();
                long fileSize = file.length();
                String msg = nameFile + " - Size: "+fileSize;
                System.out.println(msg);
            }
        }
        catch (FileNotFoundException ex) {}
    }
}

Si tenemos archivos mp3 en la carpeta, la consola mostrará una salida similar a esta:

Pista5.mp3 - Size: 4877446
Pista20.mp3 - Size: 3669863
Pista10.mp3 - Size: 10081612

Hasta este punto parece que todo ha salido bien y ya tenemos una idea más clara sobre lo que es la inyección de la dependencia, aunque este ejemplo no es mucho mejor que el anterior y aun nos puede parecer algo tonto la DI. En este punto vamos a realizar una prueba unitaria mediante JUnit! Las pruebas unitarias son algo que muchos no hacemos pese a las enormes ventajas que esto aporta! En NetBeans vamos a agregar a la librería de nuestro proyecto a JUnit 4.5. En la carpeta de "Test Packages" colocaremos la clase de unidad que crearemos a continuación.

package archivo.test;

import archivos.BuscadorArchivo;
import java.io.File;
import java.io.FileNotFoundException;
import org.junit.Assert;
import org.junit.Test;

/**
 *
 * @author windoctor
 */
public class ArchivoTest {

    @Test
    public void listarTest(){
        BuscadorArchivo buscador = new 
                  BuscadorArchivo("/home/windoctor/Documentos", ".mp3");
        try {
            File[] files = buscador.listar();
            Assert.assertNotNull(files);
        } 
        catch (FileNotFoundException ex) {

        }
    }
}

Al ejecutar el código anterior obtendremos una salida de JUnit como la que muestra la imagen de abajo.

Nuestra prueba unitaria ha resultado exitosa! Sin embargo, aún nos falta probar a la clase FileExtensionFileFilter, así que debemos hacer lo mismo.... Un momento... Sin darnos cuenta, ya hemos probado a "FileExtensionFileFilter" dado que BuscadorArchivo obtiene por si mismo una referencia de ese objeto!

En la primera parte de este tutorial, mencionamos que una de las características deseables del Software es que tenga un débil acoplamiento! Desafortunadamente en este ejemplo esta característica no se esta cumpliendo del todo!

Si pensamos un poco más, caeremos en la cuenta que con el ejemplo anterior estamos limitados a filtrar archivos únicamente por su extensión! Pues BuscadorArchivo recupera por si mismo a un FileExtensionFileFilter... ¿Y si deseamos filtrar en base a que un archivo de texto contenga cierta palabra?

El anterior ejemplo es sencillo, pero si lo trasladamos a clases de un Sistema empresarial que es grande y tiene decenas, cientos o miles de clases, las pruebas unitarias se vuelven difíciles de realizar por el fuerte acoplamiento que existe, además que el mantenimiento se complica!

La solución consiste en inyectar objetos FileFilter en BuscadorArchivo, dado que FileFilter es una interfaz, podemos crear tantos filtros de archivos según nuestras necesidades. Realizaremos una modificación a la clase BuscadorArchivo

public class BuscadorArchivo {
    private String directorio;
    private FileFilter filter;

    public BuscadorArchivo(String directorio){
        this.directorio = directorio;
    }

    //Ahora al Buscador de archivos se le asigna un Filtro en lugar
    //de que Él mismo obtenga un filtro.
    public void setFilter(FileFilter filter){
        this.filter = filter;
    }

    public File[] listar() throws FileNotFoundException{
        File dir = new File(directorio);
        //Si no existe, lanzamos una excepción
        if(!dir.exists())
            throw new FileNotFoundException
                    ("No existe el directorio "+directorio);


        File[] files = dir.listFiles(filter);

        if(files == null || files.length <= 0){
            System.out.println("No existen archivos con el criterio de búsqueda");
            return null;
        }
        else
            return files;
    }
}

La diferencia ahora es que BuscadorArchivo ya no recupera por si mismo un filtro, por el contrario, el filtro le es inyectado mediante un método setFilter. Para que Spring pueda hacer esta inyección, debemos modificar también el archivo applicationContext.xml:

<bean id="beanFilter" class="archivos.FileExtensionFileFilter">
<constructor-arg index="0" value=".mp3" />
</bean>

<bean id="beanAnalizadorXml" class="archivos.BuscadorArchivo">
<constructor-arg index="0" value="/home/windoctor/Documentos" />
<property name="filter" ref="beanFilter" />
</bean>

Podemos observar que ahora hemos definido un nuevo bean FileExtensionFileFilter que es inyectado al beanArchivo. El beanArchivo ahora tiene una etiqueta property que consta de 2 atributos, name y ref.

name: nombre del atributo de la clase. En este caso, hemos agregado a BuscadorArchivo un atributo llamado filter, este nombre es el que deberá colocarse esta propiedad.
ref: Es la referencia de otro bean que se ha declarado en el applicationContext.xml

Con la modificación anterior tenemos un código con un menor acoplamiento, ahora es posible asignarle realizar búsquedas de archivos con diferentes filtros y no necesariamente por extensión como originalmente sucedía!

Puedes descargar el proyecto en NetBeans de la primera y segunda parte de este tutorial desde aquí.

Cerraremos este tutorial sobre la Inyección de la Dependencia mediante Spring con una tercera y última parte en donde veremos otro ejemplo más que nos permita comprender de mejor manera la DI.

Saludos!!!

Cualquier error encontrado en este tutorial, reportarlo como comentario dentro del mismo!
La información contenida aquí se utiliza con fines educativos y su utilización en ambientes de producción es únicamente responsabilidad de quien lo hace.

Inyección de la Dependencia I: Práctico y Fácil

2010-04-12T19:28:00.001-07:00

Spring es un Framework de código abierto, creado originalmente para mitigar la odiosa complejidad de los EJB (La especificación de EJB 3 ha sido considerablemente más ligera y fácil de utilizar). Una de las características más conocidas de Spring es trabajar con la Inyección de la Dependencia y la Programación Orientada a Aspectos. Omitiremos un poco la discusión sobre el término Inversión del Control (IoC) que es más general, para otra ocasión!

Alta Cohesión y Débil Acoplamiento

Se dice que el Software debe tener dos características fundamentales, una alta cohesión y un débil acoplamiento. La cohesión se refiere a la manera en la que agrupamos todos los "artefactos de software" (un término quizá más apropiado es "unidad de software"). Con "agrupar" debe entenderse a la facilidad con la que pueden ensamblarse todos nuestros componentes de software, métodos, clases, paquetes, etc.

El débil acoplamiento se refiere al grado de dependencia que existe entre las unidades de software, es decir, si tenemos dos clases, A y B, y alguna de ellas depende en gran medida de la otra y no esta presente, la clase o método dependiente no podrá realizar efectivamente su tarea. El acoplamiento a nivel de métodos es más fácil de comprender con el siguiente ejemplo:

public int multiplicar(int a, int b){
        int c = resta(a,b);
        return 2 * c;
    }
    
    public int resta(int a, int b){
        return a-b;
    }

Vemos pues que existe una fuerte dependencia del método multiplicar con el método restar! El método multiplicar llama al método restar. En gran medida, esto es lo que debemos evitar! Sin embargo, es importante aclarar el término "débil acoplamiento" y "desacoplamiento", este segundo término da a entender algo total y absoluto, mientras que el primero dice que puede haber acoplamiento por que definitivamente no es posible desarrollar Software con cero acoplamiento! Sin embargo, mediante algunas técnicas es posible reducirlo!

Spring Framework fomenta el débil acoplamiento mediante la Inyección de dependencias que es lo siguiente que veremos.

Inyección de la Dependencia

La Inyección de la dependencia sigue un sencillo principio, "No me llames, YO te llamo". Lo anterior describe perfectamente la tarea de la DI (Dependency Injection), es decir, cuando desarrollamos Software, sabemos de antemano que existen clases relacionadas, cada objeto se hace responsable de llamar y crear a otros objetos que necesita para poder llevar a cabo su tarea. Para aclarar lo anterior vamos a realizar el ya clásico programa del "Hola Mundo!". Utilizaremos NetBeans 6.8 por su sencillez y simplicidad de primera mano (omitiremos su lentitud), desde luego que Eclipse es un mejor IDE, pero en Eclipse debemos instalar un plugin para trabajar más cómodamente con Spring y NetBeans ya lo trae por defecto (por ello utilice el término "de primera mano").

En NetBeans creamos un proyecto web y llegado a la opción de Frameworks, seleccionamos Spring Web MVC.

Vamos a crear una interfaz llamada ISaludo:

public interface ISaludo {

    void saludar();

}

Así como la clase que implemente la interfaz:

public class Saludo implements ISaludo{
    public String mensaje;

    public Saludo(String mensaje){
        this.mensaje = mensaje;
    }
    public void saludar() {
        System.out.println(mensaje);
    }
}

Vemos que la clase Saludo recibe una cadena en su constructor, esto podría ser otro tipo de Objeto creado por nosotros mismos. Lo que vamos a hacer aquí es tan sencillo que no se le vera utilidad a nivel de aplicación y en realidad, mucho del poder de Spring puede ser visto con mayor facilidad a nivel de Arquitectura! Vamos a concentrarnos en aplicar la DI.

Dentro de la carpeta WEB-INF, NetBeans ha creado un archivo XML llamado applicationContext.xml, en el tendremos a las etiquetas y dentro de ellas colocaremos lo siguiente:

El pequeño fragmento anterior, tendrá la tarea de instanciar un objeto de tipo Saludo (véase que esta dentro del paquete saludo), a este objeto lo vamos a referenciar por "beanSaludo". Además podemos ver que la clase Saludo recibe en su constructor una cadena de texto, misma que inyectaremos desde Spring mediante el atributo constructor-arg. Finalmente creamos una clase para ejecutar este ejemplo, el más sencillo de todos los que pueda haber!

public class SaludoTest {

    public static void main(String args[]){
        BeanFactory context=
                new XmlBeanFactory(new 
                FileSystemResource("AQUI LA RUTA/applicationContext.xml"));

        ISaludo saludo = (ISaludo) context.getBean("beanSaludo");
        saludo.saludar();
    }

}

Al ejecutar la clase anterior, podremos observar en la consola de NetBeans la siguiente salida:

"Hola, este es nuestro primer ejemplo DI!!"

Lo primero a resaltar es que dicho mensaje no ha sido establecido! Podría pensarse en primera instancia que hubiera sido lo mismo colocar el mensaje en algún archivo de texto pero en realidad si lo hubiéramos hecho así, en algún lugar del código tendríamos que leer el archivo obtener el valor y "settearlo" al atributo mensaje de la clase Saludo! Sin embargo, nótese que en este sencillo ejemplo, Spring ha INYECTADO dicho recurso automáticamente por nosotros, es decir, nosotros no hemos hecho nada como esto:

Saludo saludo = new Saludo("hola mundo!");

ni tampoco

saludo.setMensaje("Hola mundo");

Lo que se debe notar es que Spring como por arte de magia a inyectado el recurso (la cadena de texto) por nosotros! Sin aplicar la DI, el código del método main quedaria mucho más simple:

public class SaludoTest {
    public static void main(String args[]){
        Saludo saludo = new 
               Saludo("Hola, este es nuestro primer ejemplo DI!!");
        saludo.saludar();
    }

}

Con el código anterior, obtendriamos el mismo resultado pero sin la utilización de Spring! Este ejemplo es tan sencillo que el poder de la DI no es notoria, al contrario, lo hace ver como algo inútil, sin embargo, este ejemplo es meramete educativo y debe bastar para entender a que se refiere la "Inyección de la Dependencia" (NO me llames, YO te llamo). Más adelante veremos ejemplos más útiles en donde se vera de mejor forma la utilidad de la DI.

Saludos!!

Cualquier error encontrado en este tutorial, reportarlo como comentario dentro del mismo!

La información contenida aquí se utiliza con fines educativos y su utilización en ambientes de producción es únicamente responsabilidad de quien lo hace.

¿Qué es un EJB?... La triste realidad del Sector Académico

2010-04-04T17:00:00.000-07:00

Este es un vídeo que me ha dejado sin palabras! Incluso es tan vergonzoso que me niego a creer que es verdad, pero si lo es, realmente es solo una muestra de la realidad que vive el sector académico en muchas partes del mundo, principalmente en países latinoamericanos, México desde luego no es la excepción! El video, lo he visto de este blog. Fueron unos alumnos de la UTN los que grabaron esta clase y la animaron en este video...

No soy el desarrollador senior pero tampoco soy un desarrollador Junior y aun así no he podido entender en palabras de este profesor lo que es un EJB!!!

Pese a ello, la arrogancia de muchos catedráticos es notable! Los "Títulos" de posgrado ("Maestrías", "Doctorados") han originado en el Sector académico una cortina de humo y un lamentable conformismo!

Podría enumerar a cada uno de mis maestros que tuve, pero por respeto a su persona (no como a catedráticos) no lo haré, más sin embargo, muchos de ellos siempre me dieron risa cuando hacían alarde a sus maestrías y a sus doctorados y ellos mismos aceptaban que nunca les había gustado el desarrollo de sw.

Afortunadamente, existen también verdaderos catedráticos (aunque muy pocos) que saben de lo que hablan y se preocupan verdaderamente por la educación! Entre ellos por ejemplo, Raul Oramas, profesor de la Universidad de Occidente el cual tiene un esquema de capacitación gratuito en tecnología Java de muy alto nivel

http://www.profesorjava.com/ ... Profesores como Raúl, son los que realmente se necesitan en lugar de tener a catedráticos encerrados como ratas de laboratorio en sus cubículos con el pretexto de ser "investigadores"... ¿Qué investigan? ¿Cuáles han sido sus aportes a la comunidad científica? ¿En realidad han servido o dado frutos sus investigaciones? Y con "frutos" no me refiero a nada palpable, pues la investigación científica puede tardar años en materializar sus investigaciones, más bien me refiero a si las supuestas investigaciones que realizan muchos académicos realmente son ineditas y han servido de base para otras investigaciones teóricas?

Nunca ocultare mi antipatía por el sector académico! Me bastaron 4 años de carrera y haber conocido a la planta docente de mi "honorable" institución de donde soy egresado para darme cuenta que quizá solo 1 (o siendo menos estricto 2) profesores son verdaderos académicos, los demás... los demás son simplemente... mejor le dejo hasta aquí!

Saludos!!

El giro positivo del UML

2010-04-03T22:12:00.000-07:00

Sencillamente esta es una sátira genial que escribió ya hace algunos años Bertrand Meyer y que tradujo Javier Smaldone en su blog.

En el blog de Javier Smaldone, hubo una discusión entre el y Fernando Pinciroli.

Es muy importante ser fríos y objetivos, si bien Javier Smaldone comenta puntos muy ciertos sobre el UML, también cae en el exceso de desprestigiar totalmente no solo a UML sino a RUP.

Como en uno de los artículos que escribí titulado El Fracaso de los proyectos de Software, apoyado en uno de los artículos más interesantes de Martín Fowler, comento que el modelado en UML debe manejarse con cuidado, pues la idea de "primero modela y luego construyes" encaja perfectamente en la Ingeniería Civil y Mecánica donde la naturaleza de sus problemas son suceptibles de un análisis matemático para determinar el comportamiento de una entidad bajos ciertas circunstancias y esto en definitiva obliga casi a un modelado previo.
Desafortunadamente en el Software la idea de realizar primero un "Diagrama de clases" e invertir mucho tiempo en ello para diseñar una Arquitectura es realmente absurda!

Es importante aclarar que no estoy del todo de acuerdo con Javier y Bertrand Meyer, por el contrario, pienso que algunos diagramas UML son útiles siempre y cuando se tomen como una ayuda para aclarar cuestiones de diseño y no como documentación base del proyecto ya que esto último desvía la atención de las organizaciones en lo que es realmente importante... dejar un valor de negocio al cliente! En breve publicaré la traducción de "La Fiebre del UML" que hace un tiempo leí.

Sin más que comentar, lean este artículo, disfrútenlo, diviértanse y sobre todo, tómenlo con mesura, más aún si son estudiantes!

Libros: Scrum y TDD

2010-03-26T23:07:00.000-07:00

Pese a que las metodologías ágiles ya tienen más de una década, su uso en latinoamerica no ha sido tan profundo. Una de las principales razones, es la existencia de poco material en español!

Afortunadamente con el afán de promover principios ágiles, se han realizado traducciones de artículos y libros, por ejemplo, uno de ellos es "Scrum y XP desde las Trincheras", un libro obligatorio para todos aquellos que deseen aprender las bases de Scrum y XP de manera práctica! El libro es completamente gratuito!

http://www.infoq.com/minibooks/scrum-xp-from-the-trenches

TDD (Test Driven Development) es una práctica ágil cuya filosofía es desarrollar las pruebas unitarias antes de codificar cualquier funcionalidad del negocio! Este es un excelente libro gratuito escrito originalmente en español!

http://www.dirigidoportests.com/el-libro

Ambos libros pueden ser comprados en su versión impresa por un módico precio!

¿Problemas?... Ese no es mi problema!!

2010-03-26T22:25:00.001-07:00

La burocracia es uno de los problemas existentes en muchas organizaciones, principalmente en Gobierno! Desafortunadamente las empresas privadas no están exentas de esto!

El siguiente vídeo nos ilustra de una forma cómica lo que ocurre en muchas de las organizaciones! En el desarrollo de software por ejemplo, es muy común encontrarse con programadores egoístas que no comparten su conocimiento y cuando un integrante del equipo de trabajo tiene problemas, no faltara quien se niegue a ayudarle!... "Ese no es mi problema!!" pensamos rápidamente.

No solo programadores, sino todos los involucrados en el proyecto de desarrollo, nos corroe la envidia y buscamos únicamente que lo que nosotros hagamos este bien hecho, lo que hace el de al lado o el de frente no nos interesa. Se nos olvida que los objetivos requieren de una responsabilidad compartida y solo esta suma de esfuerzos harán que podamos obtener resultados cuantificables, es decir, metas!

El Fracaso en los Proyectos de Software

2010-03-15T09:28:00.000-07:00

Última revisión: 17 de Marzo 2010
Antes de comenzar, debo aclarar que yo no tengo nada en contra de las metodologías tradicionales, al contrario, creo que su aplicación es muy eficiente en algunos tipos de proyectos, pero sin duda en la mayoría de proyectos empresariales, han demostrado ser ineficientes. Por esta razón, debemos dar una mirada a una nueva alternativa que lleva utilizándose con éxito en Europa desde hace más de 10 años!

Esta serie de articulos bajo el nombre “El fracaso en los proyectos de Software” es simplemente una recopilación de ideas que muchos expertos realmente involucrados en el desarrollo de software han vertido durante los últimos años:

Y a tantas otras personas que directa o indirectamente han influido en la filosofía ágile. (ver).

Esta primera parte, da solamente un acercamiento del entorno actual en el que se vive en muchas partes del mundo, principalmente, en México. En la segunda parte que comenzaré a escribir en breve, hablaré más especificamente sobre la filosofía de las metodologías ágiles y sus bondades.
Durante mi corta experiencia, he podido ver muchos Sistemas de Software de mediana escala con una calidad increíblemente pobre, con un mantenimiento que resulta un tormento y un tiempo de desarrollo cada vez más corto. Cuando lo anterior no sucede, el proyecto se termina, pero no cumple con las expectativas del cliente y termina siendo muy poco utilizado. Por ejemplo, una de las casas de préstamo de efectivo en México recientemente ha iniciado un nuevo proyecto para migrar su sistema de cobranza en .NET a una plataforma Java! Indudablemente la razón de esta migración no es por que .NET se haya quedado “corto”, más bien habla de una pésima aplicación que a estas alturas ya es inmantenible por su terrible calidad, derivado de una mala administración!

El fracaso de estos proyectos se atribuye a diferentes perspectivas, desde un nivel meramente técnico (personal mal capacitado), hasta una mala visión de negocio entre los niveles gerenciales. Mi intensión en este artículo no es hablar sobre los errores o aciertos que cometen los niveles gerenciales ya que en estos momentos no tengo injerencia en este campo por mi nula experiencia, así que me enfocaré más al problema derivado de una mala Ingeniería de Software y abrir la pregunta que Tom DeMarco lo plantea en uno de sus artículos…. La Ingeniería del Software es ¿Una idea obsoleta?

Esta serie de artículos, involucran a estudiantes y académicos y a profesionistas del mundo laboral.
A los estudiantes, para que conozcan lo que se viene trabajando en reino unido y países europeos con éxito desde hace más de 10 años. Además con esto espero que sepan que no todo en la vida de los sistemas es un conjunto de tablas, relaciones, frameworks y lenguajes de programación! Quienes me conocen, saben muy bien que mi formación ha sido eminentemente técnica, así que en definitiva no podrán decir que me intereso en este tipo de proyectos por que “no se programar”.

Al sector académico es una llamada de atención para que dejen a un lado sus ideas obsoletas sobre la Administración de Proyectos de Software, se haga una revisión a las retículas académicas y se actualice a la planta docente. Es hora de que los catedráticos sepan que hay otras cosas que el modelo en cascada (muchos ni siquiera enseñan algo de RUP) y peor aún ¿Por qué seguimos perdiendo el tiempo en hacer que el alumno domine un Microsoft Project para hacer bonitos pero inútiles diagramas de Gantt? Es hora que el sector académico se pregunte ¿Realmente todas estas prácticas están agregando un valor real al producto?… En México la educación es obsoleta, mientras en otras partes del mundo se enseña PSP/TSP, RUP, Ágile, Testing, etc., en México seguimos encerrados con nuestros diagramas de flujo, diagramas de contexto, y tantas otras prácticas obsoletas. Mi antipatía por el sector académico siempre ha sido notoria para todos aquellos que me conocen en persona y he sido un crítico muy duro con ellos. Yo mismo he vivido la ineptitud de muchos catedráticos, mi asesor de titulación quería diagramas de flujo y de contexto argumentando que los Casos de Uso eran para personas técnicas y no para los usuarios!!! Lo más triste era ver que se encontraba en el departamento de Posgrado pues era un Maestro en Ciencias!

Finalmente, a los profesionistas de hoy, a los desarrolladores que aún no conocen a los métodos ágiles, es seguro que ustedes estarán con muchas cosas de acuerdo.

Sin más que esperar una mentalidad abierta por parte de ustedes lectores, es hora de ver algunas de las razones por la que los proyectos de Software fracasan y ver bajo una filosofía agile una alternativa, aunque no necesariamente una solución completa a los problemas existentes en el desarrollo de SW, pero Ágile puede influenciar aún más los conceptos de la Ing de Software tradicional!

SITUACIÓN ACTUAL
En el año 2006, John Avellanet utilizó un estudio realizado por Accenture para establecer los puntos necesarios que se requieren para alcanzar el éxito de un proyecto. Los datos sobre el entorno en el desarrollo de proyectos de TI era desalentador, desafortunadamente del 2006 a la fecha, las cosas no han cambiado en mucho.

Solo el 27% de los proyectos de TI puede ser considerado un éxito.
Los proyectos de TI sobrepasan su costo en un 56%.
Se estima que los proyectos sobrepasan su calendario en un 84%.
El 31.1% de los proyectos son cancelados antes de que sean terminados.

Lo anterior son números rojos alarmantes, que sin embargo, no son nada nuevos , estos números han existido desde un inicio.

Este proyecto es extremadamente importante.

No hay calendario, ni guias, ni el personal necesario…

Y su fecha de entrega es mañana!! Así que esta es su oportunidad

de impresionar realmente a todos!

CAUSAS DE TAN DESALENTADOR PANORAMA
Las causas son diversas. El Dr. Daniel Tapia, Profesor Investigador del Centro de Investigación en Tecnologías de la Información (CITIS) de la Universidad Autónoma del Estado de Hidalgo, atribuye el fracaso de un proyecto de TI a las siguientes razones;

Se daba mayor atención a las cuestiones operativas que a la planificación.
Planeación deficiente.
Los objetivos del proyecto no estaban alineados con los objetivos de la organización.
El entorno global hace que la planeación tradicional ya no sea suficiente.
Una mera planificación de actividades y recursos no sirve de nada.
Se requiere una gestión estratégica.

Existen puntos interesantes en las presentaciones del Dr. Tapia que recomiendo leer (ver al final de este artículo), aunque en algunas cuestiones, no concuerdo del todo, como por ejemplo donde hace mención que se requieren procesos bien definidos y una documentación extensa. Fuera de esto, el Dr. Tapia concluye que un simple enfoque de Ing. de Software ya no es suficiente, lo cuál es extremadamente cierto, sin embargo, en este artículo nos enfocaremos en dicho aspecto.
A los puntos anteriores, voy a agregar uno que seguramente puede ser causa de polémica por ser tan directo y acusador.

Durante muchos años, el sector académico ha tenido erróneamente mucha injerencia en el desarrollo de software cuando su papel no es precisamente ser el protagonista en este ámbito. Las universidades estan más interesadas en crear pequeñas fábricas de software, que en preparar de forma adecuada a los alumnos. Las empresas por su parte, se están enfocando en capacitar en cuestiones básicas a los alumnos que egresan en lugar de desarrollar software, es decir, los papeles se estan invirtiendo!! Las universidades están desarrollando software y las empresas están capacitando!!.

Hace poco más de un año, escuche al Director General de QuarkSoft, Cesar Montes de Oca, decir todo lo anterior! Ellos como empresa tenían que capacitar a los recién egresados sobre temas tan sencillos como realizar una simple conexión a base de datos con Java! Sin duda que algo muy pero muy grave esta fallando con las Universidades, pero bueno, afortunada o desafortunadamente no es tema de análisis en este estudio.

Grandes universidades que sin duda han hecho grandes aportes a la Ing. del Software, como por ejemplo la University Carnegie Mellon (en conjunto con el SEI), han desarrollado varios de los modelos y procesos para el desarrollo de Software como por ejemplo (CMM/CMMI, PSP/TSP., etc., “Avances” mismos que al día de hoy han demostrado ser ineficientes para la mayoría de los casos reales. Aquí en México por ejemplo, se ha creado MoProSoft como un modelo de desarrollo de software para las empresas mexicanas, modelo que ha sido lidereado por la Dra. Hanna Oktaba, académico del IMAS en la UNAM.

Es importante hacer un pequeño paréntesis y aclarar todo lo anterior para no crear malos entendidos. El sector académico ha hecho no solamente grandes aportes, más bien ha hecho todos los aportes de la actualidad en cuanto a las Ciencias Computacionales [Ver Ing de Software de Ian Somerville para una diferencia entre las Ciencias Computacionales y la Ing de Software]. Debemos agradecer a nuestros maestros de la universidad por enseñarnos aquellas estructuras de datos, por hacernos entender el algoritmo de Dijkstra, por explicarnos la notación O, por aquellos difíciles proyectos en lenguaje ensamblador y por aquellas Series de Fourier, etc., sin embargo, han olvidado que mucho de su trabajo es eminentemente teórico que puede demostrarse y realizarse en laboratorios, pero un proyeto de desarrollo de software no puede ser simulado y demostrado fácilmente.

¿Cuál es el problema de las Metodologías actuales?

La filosofía que siguen los métodos formales están basados en procesos aplicados en otras ingenierías como la ingeniería civil y mecánica en donde se requiere una planeación detallada antes de construir! Este es el punto medular de este artículo… “La planeación detallada“… Martín Fowler un verdadero gurú a nivel mundial, escribió un muy interesante y famoso artículo donde habla sobre “La nueva metodología” y da unas pautas generales que describen el error de las metodologías tradicionales y los aciertos que han tenido las metodologías ágiles.

Ha sido un error tomar casi al pie de la letra la filosofía de otras ingenierías y aplicarlas al desarrollo de software. En la ingeniería civil por ejemplo, los problemas importantes son suceptibles de un análisis matemático que determina por ejemplo, la fuerza a aplicar a ciertos elementos, la resistencia de los materiales, etc. En pocas palabras, los métodos que se utilizan en otras ingenierías son “predictivos” [entiéndase por predictivo que es posible "predecir" el comportamiento de un Sistema bajo ciertas condiciones]y funcionan muy bien en ese ámbito. Sin embargo, en el mundo del desarrollo de software comercial, ¿Como es posible predecir un cambio de requerimientos? ¿Es posible predecir la duración de un proyecto?… Muchas personas podrían argumentar que si es posible predecir lo anterior, quizá sí, pero no bajo modelos matemáticos como en otras ingenierías y por ende esta filosofía debería desecharse.

Lamentablemente, esta predicibilidad es muy usada en procesos tales como el PSP [Ver Personal Software Process del Dr. Watts Humprhey] , en donde debes ir haciendo todo un registro de tus tiempos, de tus distracciones, e ir sacando promedios de cada actividad a la que te dedicas para que de esta forma, en actividades similares posteriores, puedas predecir el tiempo que llevaras en construir cierto componente de software, aunado a esto, toda una serie de procesos formales intentan mejorar tu productividad y calidad en tus desarrollos. Los principios del PSP pueden ser aun muy discutidos, yo mismo me encuentro aún valorando sus bondades en ciertos tipos de proyectos.

Las metodologías tradicionales, al ser meramente predictivas, dicen que debemos hacer una toma completa y detallada de requerimientos al iniciar un proyecto, posteriormente asentar en documentos y diagramas UML la arquitectura del sistema a utilizar, después comenzar la construcción del sistema y finalmente una etapa de pruebas. Nótese la gran similitud con la ingeniería civil, en donde primero se diseña y después se construye!

Cuando se trabaja con metodologías tradicionales, existe una resistencia nativa al cambio. Las personas que trabajan en el proyecto se resisten a cualquier cambio de requerimientos, cosa contraria a lo que pasa con los métodos ágiles, en donde se piensa que los cambios son bienvenidos, se trata sencillamente de convivir con ellos y transformar una debilidad en una fortaleza.
La toma de requerimientos tradicional, indica hacer una detallada documentación y casos de uso donde se plasmen los requerimientos. Hoy en día ya sabemos que un desarrollo iterativo es mejor, en donde al inicio del proyecto se de solo un panorama general de todo lo que el usuario quiere y en cada iteración se desglosen un poco más los requerimientos.

El diseño de una arquitectura antes de la codificación es otro problema fundamental! Teóricamente lo anterior suena bien e incluso lógico, pues a final de cuentas, esto mismo se hace en otras ingenierías! Pero la práctica nos ha demostrado que el definir una arquitectura anterior a la codificación resulta muy problemática a la hora de codificar. La filosofía agile, nos indica que la mejor arquitectura que podemos definir en un inicio son cuestiones generales como la plataforma de programación, la BD y los frameworks que utilizaremos, pero la arquitectura detallada, ira fluyendo durante la codificación!

La etapa de pruebas es un asunto discutido. Por un lado, los tradicionalistas opinan que debe haber un equipo aparte del equipo de desarrollo que se encargue de probar el sistema, además de esto, nos indica que la etapa de pruebas se realiza al final de la etapa de codificación! En el lado ágil, tenemos que no existe un equipo aparte del equipo de desarrollo, los desarrolladores son y deben ser los mejores testers, además de esto, la práctica de TDD, nos dice que primero debemos crear la prueba unitaria antes de crear el módulo! Es decir, debemos crear primero una prueba unitaria para algo que aun no existe!! Esto es raro al inicio, pero aporta muchas ventajas!

El error de las personas que practican metodologías tradicionales
Son muchos los errores que siguen los project manager tradicionales. Desde el hecho de que las empresas gastan o se desviven en piratear licencias de sofisticados programas para elaborar diagramas de Gantt y hacer un detallado calendario de todo el proyecto con fechas de entrega, personas que realizarán cada una de las tareas y/o módulos existentes, plan de trabajo que desarrollo una noche antes el departamento de ventas para poder vender un proyecto de miles de pesos etc., hasta el hecho de designar un equipo especializado en “pruebas de software” que sea diferente al del equipo de desarrollo que realizará las pruebas al software en base a un detallado análisis en casos de uso de 100 páginas.

Otro error que cometen frecuentemente los administradores de proyectos es,

Yo Administrador de Proyectos, soy el único que puede dialogar con el cliente! Tu programador, tienes prohibido hablar con el cliente de cosas relacionadas con el proyecto, cualquier duda que tengas en los requerimientos debes dirigirte a mi, cualquier duda que tenga el cliente en la estimación de tiempo debes indicarle que se dirija conmigo.

Acaso al construir una casa, el maestro de obra habla con nuestros papás en lugar de hablar directamente con nosotros que somos los clientes??

Algo más irónico es por ejemplo, cuando una vez que el departamento de ventas diseñó nuestro plan de trabajo y decidió que nos llevaríamos 2 días en construir la interfaz que comunicaría nuestro módulo de consultas de proveedores externos con la tabla que existe en DBASE y que la transmición de datos se haría mediante un certificado digital de seguridad web SSL, además claro esta, de tener la opción de enviar un correo electrónico a los directivos cuando el monto de las facturas exceda el monto planeado que se tiene en SAP. Una vez que en la primer reunión que tuvo el depto de ventas con el cliente y entrego dicho plan de trabajo, el cliente quedo asombrado ante la rapidez de desarrollo y le dijo al departamento de ventas que entonces comenzaran ese mismo día con el proyecto! Entonces el departamento de ventas, corre inmediatamente a darle la excelente noticia al equipo de desarrollo que tiene 2 días para mostrar un primer entregable, que de el plan de trabajo y las estimaciones de tiempo, que ya ni se preocupen, que ellos muy amablemente ya lo hicieron por nosotros!

Entonces el equipo de desarrollo, manda rápidamente a su analista estrella a la toma de requerimientos. Este llega al siguiente día con unas 30 hojas de las cuales unas 25 contiene información redundante! Entonces el equipo de desarrollo tiene ya solamente 1 día para terminar el primer entregable!!!!

Lo anterior, obviamente es una descripción subjetiva que no esta muy alejado de la realidad. Por un lado, tenemos a muchosStakeholder como el cliente, el depto de ventas, gerencia, etc., que piensa que hacer software es como manufacturar algo o hacer enchiladas, que en cuestión de horas estará listo para funcionar!!

Por otro lado, tenemos a métodos formales que nos exigen hacer una detallada toma de requerimientos en extensos casos de uso y más importante aún, estar persiguiendo al cliente para que firme dichos requerimientos y así “asegurar” que estos no cambien en un futuro y si cambian entonces tenemos a un “cliente que no sabe lo que quiere” y nos negaremos a realizar el cambio y si lo realizamos, será con un costo adicional sobre lo planeado. Por si esto fuera poco, se nos ha enseñado que antes de iniciar la etapa de codificación, debemos elaborar una detallada arquitectura del sistema y plasmarla en muchos diagramas UML y documentos que puedan servir como referencia “más adelante”.

Esta idea de una Arquitectura detallada y modelado UML, funciona bien en la Ingeniería Civil, pero no en el desarrollo de software… Incluso, el hecho de que muchos catedráticos piensen que el UML es la octava maravilla del mundo, es debido a que los diseños en papel o en una herramienta UML son consistentes y se ven bien! De la misma forma en el mundo real y productivo, los diseños UML en un principio parecen ser correctos y el modelo parece ser lo suficientemente bueno para generar una buena arquitectura, pero los problemas surgen a la hora de la codificación, y es cuando vemos que los diagramas UML solo nos han servido para perder el tiempo!! Cuando lo anterior pasa, es entonces que vociferamos a todo mundo que el cliente tiene la culpa por no saber lo que quiere, que nuestro analista no “predijo” como si lo hubiera hecho Walter Mercado lo que el cliente iba a querer más adelante y que nuestro arquitecto de software no supo diseñar una arquitectura escalable y preparada para el cambio!! Y es que aún si suponemos un modelo exitoso con UML, el constante cambio de requerimientos hará que sucedan dos cosas posibles:

Se actualiza toda la documentación existente y además se procede con dicho cambio a nivel de codificación. Al actualizar los cientos de documentos existentes y dejarlos actualizados y acorde a los nuevos requerimientos, hemos perdido tiempo valioso en aquello que realmente aporta un valor o ventaja competitiva a nuestro cliente! Por lo tanto, ya tenemos un retraso de más de un 50% y no entregaremos a tiempo la funcionalidad o si la entregamos, estará llena de errores por la premura del tiempo.
Dejamos de lado la documentación y nos enfocamos a lo que realmente aporta un valor al cliente! Desafortunadamente, a mitad del proyecto, este enfoque resulta triste, ya que hemos perdido la mitad de tiempo en elaborar documentación que, conforme el proyecto fue avanzando y evolucionando ha quedado obsoleta y ya no sirve de “base” para el mantenimiento del sistema, pues lo que comenzó como un simple sistema de facturación, terminó acercándose más a lo que es un ERP. Finalmente, la documentación pasa a ser un bonito recuerdo!

No faltara quien a estas alturas pueda argumentar algo a favor del modelado detallado en UML y pueda decir:

“Uhmm, pero un diagrama de clases o de componentes, nos da una visión general de la estructura del sistema y esto es muy útil para saber como interactuan los componentes del sistema, así que es necesario realizar estos diagramas. Además los diagramas de despliegue por ejemplo son muy útiles cuando tratas con un cliente técnico.”

Lo anterior, es una idea desesperada por encontrarle un sentido a la existencia del modelado excesivo en UML. Bastaría hacer un refactoring a nuestro código fuente para obtener un diagrama siempre actualizado de clases o de componentes del sistema! Y todo en cuestión de minutos!!… ¿Para que perder el tiempo diseñando y planeando algo de naturaleza intangible que con el tiempo irá cambiando y evolucionando? Ahora bien, no todo en el UML es malo, los diagramas de despliegue por ejemplo son útiles, los diagramas de actividades son una versión más bonita de los diagramas de flujo, en un momento dado podrían ser útiles 2 o 3 diagramas de secuencia, etc. El punto aquí es el “exceso” que se comete con UML.
Aunado a lo anterior, todavía podemos decir mucho más….

Los líderes y clientes, piensan que el hacer software es tan sencillo y rápido como introducir una fórmula en excel, por esto mismo, obligan a los desarrolladores a trabajar jornadas mayores a las 8 horas!
Los líderes de proyecto no están dispuestos a perder su autoridad! Es común que en los equipos, siempre exista una autoridad que tome todas las decisiones [programadores extrella, líderes absolutos]. Cuando un desarrollador sugiere o habla algo con el cliente, el líder siente perder autoridad, reacciona y entonces prohíbe una comunicación con el cliente!
Los equipos de trabajo siempre están a la espera de recibir órdenes, a que se les asigne una tarea, muchas veces a que se les diga como hacerla, etc. Mientras en la forma tradicional perdemos el tiempo esperando recibir ordenes, en las metodologías ágiles se fomenta a equipos auto-dirigidos!

¿Es importante estar certificado en una norma ISO, CMM/CMMI/, MoProSoft, etc?
Muchas empresas no ven lo anterior como una posibilidad para realizar un cambio y mejora en sus procesos, en vez de eso, lo ven como algo superficial del cual pueden alzar el cuello y presumir ante sus clientes que tienen una certificación ISO xxxx-xxxx y que entonces son la mejor opción ya que sus competidores hacen software basura y ellos al tener una ISO, hacen desarrollos de calidad!

Yo mismo he vivido lo anterior. En mi primer trabajo profesional que tuve en el desarrollo de software, yo aún era estudiante y me toco vivir como la empresa para la que trabajaba, se preocupaba más por dar a conocer a los clientes que se contaba con la certificación MoProSoft nivel 1, cuando internamente no se conocía muy bien la forma de aplicar efectivamente dicho modelo.

El presidente de la empresa, siempre aseguraba que no podíamos presumir nuestras miserias al cliente! Ciertamente algo muy cierto, el problema era que nunca se preocupo por hacer un verdadero cambio de fondo. Pero bueno, el asunto original es si realmente es importante estar certificado en alguna de las anteriores normas y procesos formales para tener éxito en el desarrollo de software! Me permito citar nuevamente al Dr. Tapia:

No existe interés por métodos formales de aseguramiento de la calidad del software. Las empresas mexicanas están más preocupadas por conseguir la certificación de sus procesos con un distintivo de calidad, aunque dicha certificación no garantice la satisfacción de sus clientes.

Finalmente…
Para terminar esta primera parte del artículo “El fracaso en los proyectos de Software”, debemos sacar las concluciones más relevantes.

Los métodos tradicionales, siguen un enfoque utilizado en otras ingenierías como la Ingeniería Civil y Mecánica, en donde, sus problemas son susceptibles a un análisis matemático que determinará el comportamiento de un sistema bajo ciertas condiciones. En el desarrollo de software, no es posible determinar con exactitud el comportamiento de los sistemas de software.
Los métodos tradicionales y las personas que trabajan con ellos, siguen un riguroso esquema, en donde se aleja mucho al equipo de desarrollo y al cliente. El desarrollo ágil fomenta la comunicación desarrollador/cliente e invita al cliente a ser parte del equipo, mientras que los tradicionalistas sostienen que el líder de proyecto debe ser el responsable de hablar con el cliente.
Cuando los proyectos fracasan, se cree que todavía debe agregarse una capa más detallada de procesos aún más formales y definidos, de planes aún más detallados, de más documentación, de más juntas de 3 horas, de una mayor vigilancia al equipo de desarrollo y de más horas de trabajo, cuando en realidad los principios deben ser muy sencillos. [ver el artículo de Emilio Osorio]
Las empresas se preocupan más por tapar hoyos superficiales, por presentar un mundo de caramelo en sus desarrollos con el cliente y de obtener certificaciones aunque no entiendan como aplicarlas.
En muchas empresas, la gerencia toma decisiones que no le corresponden y debe dejarlas a los verdaderos expertos. Muchas veces son estos niveles los que fijan el costo de un proyecto de software y la duración del mismo. Cuando menos lo esperamos, ya nos entregan un plan de desarrollo con fechas ya establecidas!.
Durante más de 10 años, los métodos formales no han dado tantos resultados positivos. Lo preocupante de esto, es que al no dar los resultados esperados, día a día se piensa en agregar más formalidad y rigidez a su proceso. Los métodos ágiles tampoco son la solución a todos los problemas, pero si dan unas buenas pautas para reformular las actuales ideas de la Ingeniería de Software.

En la segunda parte de este artículo, comenzaremos a ver a la filosofía de los métodos ágiles y veremos en ellos una mejor herramienta para tratar de resolver los problemas actuales en la administración y desarrollo de software.

Visita el blog próximamente para leer la segunda parte que será mucho más interesante! No olvides vertir tus comentarios que serán muy útiles para enriquecer este artículo! Tanto si eres un estudiante con o sin experiencia, un académico dando o no dando clases de Ing de Software, o un profesionista desarrollador o líder de proyecto! Todos los comentarios, buenos o malos, pero constructivos, son bienvenidos!

REFERENCIAS BIBLIOGRÁFICAS

Métodos de Ordenación de forma concurrente

2010-03-10T21:14:00.000-08:00

En mi blog anterior, publique en el 2008 un artículo sobre la ordenación de un arreglo de números aleatorios mediante 3 métodos: QuickSort, Burbuja e Inserción. Pero estos métodos se ejecutaban de forma concurrente mediante Threads. En ese tiempo, no se la razón por la cual no subi el código fuente y mucha gente lo solicito en los comentarios de dicho artículo!

Pongo aquí el código fuente para su descarga!

Números palindrómicos

2010-03-09T21:19:00.000-08:00

En projecteuler.net se ofrece el siguiente problema:

Un número palindrómico se lee de la misma forma en ambos sentidos. El palíndromo más grande a partir del producto de dos números de 2 dígitos es 9009 = 91 x 99.
Encontrar el palíndromo más grande a partir del producto de dos números de 3 dígitos.

A continuación les planteo la solución original que yo hice antes de acertar a la respuesta y poder ver la solución que se plantea en la misma página una vez resuelto el problema!

public Set calcularPalindromosNumerico(Integer min, Integer max){
        Set <Integer>listaPalindromos = new HashSet<Integer>();
        for(int i = min; i <= max; i++ ){
            for(int j = min; j <= max; j++){
                Integer res = j*i;
                if(isPalindromo(res))
                    listaPalindromos.add(res);
            }
        }
        return listaPalindromos;
    }

Lo primero que cabe resaltar en el método anterior es que utilizamos una clase “Set” con el único propósito de no almacenar resultados repetidos (100*110 y 110*100 por ejemplo) [Recordamos que la clase Set no almacena datos duplicados]. Lo segundo que hay que notar es que el método recibe objetos envoltorio Integer. Esto es así ya que la lista que contendrá los números palindrómicos no estará ordenada y usaremos al método estático “sort” de la clase Arrays para ordenar dicho arreglo, pero para que lo anterior funcione, los elementos a ordenar deben implementar a la InterfazComparable según nos lo indica la documentación de la clase Arrays, así pues, los envoltorios de los tipos primitivos implementan a esta interfaz y es por ello que el método recibe objetos Integer en lugar de int.

Por último, creamos otro método que permita validar si un número es palindrómico.

public boolean isPalindromo(int numero){
        String palindromo = ReverseString.reverseIt(
                String.valueOf(numero));
 
        if(numero == Integer.parseInt(palindromo))
            return true;
        else
            return false;
    }

ReverseString es una clase que podemos encontrar aquí
Lo único que nos resta hacer es crear el método main que nos permita comprobar el resultado:

public static void main(String []args){
        Palindromo palindromo = new Palindromo();
        Object[] listaPalindromos = palindromo.calcularPalindromosNumerico
                                (100,999).toArray();
 
        Arrays.sort(listaPalindromos);
        for(Object i : listaPalindromos){
            System.out.println(i);
        }
    }

El 100 y 999 que se pasan como argumentos al método, esta claro que es el primero y último número de 3 cifras que existen!
De esta forma, obtenemos que el palíndromo más grande resultado de la multiplicación de dos números de tres cifras es: 906609
En la misma página de project euler , se proporciona un PDF con el algoritmo que da solución al problema! Pero este PDF solo lo podremos ver una vez que hayamos acertado a la respuesta!
Como complemento, para hallar números palindrómicos, existe el 196-Algorithm que pueden revisar como lectura adicional!
Saludos!!

Project Euler: Matemáticas y Programación

2010-03-07T21:24:00.000-08:00

Project Euler es una página que consta de más de 200 problemas matemáticos, que por su dificultad en el número de operaciones y cálculos, no son posibles de resolver sin la ayuda de la programación!

Hace 2 días recién me inscribí, así que al día de escribir esta entrada, solo llevo 5 ejercicios resueltos! Desde luego que he iniciado con los más fáciles!

Lo interesante de esto es que para entrar a un nivel “novice” debes tener entre 100 a 149 problemas resueltos! De lo contrario, estarías en el nivel 1 o 2 los cuales no son tan válidos, ya que si en un lapso de 60 días no resuelves ningún problema, desapareces del record! El nivel 3 es el nivel “novice” y en este nivel es cuando ya puedes quedar inmortalizado en el score sin importar el tiempo que ha pasado desde la última vez que resolviste un problema!

Para muestra del tipo de ejercicios, he aquí el primero que resolví el cual es un verdadero regalo!

If we list all the natural numbers below 10 that are multiples of 3 or 5, we get 3, 5, 6 and 9. The sum of these multiples is 23. Find the sum of all the multiples of 3 or 5 below 1000.

public class Multiplo {
    public int sumarMultiplos(int rango, int numeroUno, int numeroDos){
        int suma = 0;
        for(int i = 1; i

Como ven, se trata de un problema bastante sencillo! Estaré poniendo en este blog todos los problemas que vaya resolviendo! Aunque solo lo hago cuando tengo por ahí un tiempo libre!

Saludos!!

DB4O: El poder de las Bases de Datos Orientadas a Objetos

2010-03-07T21:23:00.000-08:00

Hace alrededor de 1 año, conocí a DB40, una Base de Datos Orientada a Objetos Open Source!… ¿Pero qué es DB4O? y sobre todo ¿para que me sirve si ya se utilizar MySQL, SQL Server, Oracle y otro manejador de Base de Datos Relacional?… Estas preguntas son las que trataré de responder a continuación.

¿Qué es DB4O?

Bien, como ya lo dije arriba, DB40 es una Base de Datos Orientada a Objetos de alto rendimiento. En algunos Benchmark realizados, DB4O muestra un rendimiento superior o similar a las Bases de Datos Relacionales, en el caso de Java, utilizando JDBC o algún Framework como Hibernate! Podemos ver estas pruebas en la página de polepos.org

¿Hibernate?… ¿Qué es eso?

Bien, si no sabes que es Hibernate te lo explicare a continuación!

Hibernate es una “herramienta” para Java (NHibernate es la versión para .NET) que nos permite poder conjuntar sin ningún problema al modelo Orientado a Objetos con el Relacional! Debes de saber que ambos modelos no son compatibles!

Pero yo he utilizado Java y MySQL… ¿Como no van a ser compatibles?

Es verdad, el paradigma Orientado a Objetos con el Modelo Relacional son incompatibles. No importa que tu hayas trabajado y desarrollado una aplicación que guarde datos en MySQL mediante Java, C# o algún otro lenguaje OO, en realidad lo único que has hecho, es escribir una simple sentencia SQL y enviarla al manejador de BD pero desde Java.

El hecho de enviar sentencias SQL a algún manejador de BD Relacional, no significa que sean compatibles!… Pero bueno, finalmente ¿A que me refiero cuando digo que son incompatibles?,.. pues bien, veámoslo con un ejemplo.

Persona ximena = new Persona("Ximena", "Rodriguez", 'F');
JDBC.save(ximena);

Si Java fuera compatible con MySQL/PostgreSQL/etc., el código anterior, indudablemente funcionaria! Es decir, sería posible guardar objetos! En lugar de eso, necesitamos utilizar variables escalares que contienen los valores que deseamos guardar, concatenarlas a otra cadena que tiene la sentencia SQL y finalmente enviarlas al manejador de Base de Datos mediante una alguna interfaz que comunique Java con MySQL/PostgreSQL/etc., como lo es JDBC.

public void guardar(String nombre, String aPaterno, char sexo){
    stmt.executeUpdate(
                "INSERT INTO persona("nombre, paterno, sexo )" +
                    "VALUES(' "+nombre+', ' "+aPaterno+" ', ' "+sexo+" ')");
}

Y para recuperar datos, es lo mismo, debemos enviar una consulta SELECT * FROM y con el resultado que nos devuelve la BD, ir iterando sobre cada registro para guardar el valor en variables o en Listas.

Finalmente podemos ver el esfuerzo requerido para conectar los dos mundos;

import java.sql.*;

public class Jdbc10 {
  public static void main(String args[]){
    System.out.println(
                  "Copyright 2004, R.G.Baldwin");
    try {
      Statement stmt;
      ResultSet rs;

      //Register the JDBC driver for MySQL.
      Class.forName("com.mysql.jdbc.Driver");

      //Define URL of database server for
      // database named JunkDB on the localhost
      // with the default port number 3306.
      String url =
            "jdbc:mysql://localhost:3306/JunkDB";

      //Get a connection to the database for a
      // user named auser with the password
      // drowssap, which is password spelled
      // backwards.
      Connection con =
                     DriverManager.getConnection(
                        url,"auser", "drowssap");

      //Display URL and connection information
      System.out.println("URL: " + url);
      System.out.println("Connection: " + con);

      //Get a Statement object
      stmt = con.createStatement();

      //As a precaution, delete myTable if it
      // already exists as residue from a
      // previous run.  Otherwise, if the table
      // already exists and an attempt is made
      // to create it, an exception will be
      // thrown.
      try{
        stmt.executeUpdate("DROP TABLE myTable");
      }catch(Exception e){
        System.out.print(e);
        System.out.println(
                  "No existing table to delete");
      }//end catch

      //Create a table in the database named
      // myTable.
      stmt.executeUpdate(
            "CREATE TABLE myTable(test_id int," +
                  "test_val char(15) not null)");

      //Insert some values into the table
      stmt.executeUpdate(
                "INSERT INTO myTable(test_id, " +
                    "test_val) VALUES(1,'One')");
      stmt.executeUpdate(
                "INSERT INTO myTable(test_id, " +
                    "test_val) VALUES(2,'Two')");
      stmt.executeUpdate(
                "INSERT INTO myTable(test_id, " +
                  "test_val) VALUES(3,'Three')");
      stmt.executeUpdate(
                "INSERT INTO myTable(test_id, " +
                   "test_val) VALUES(4,'Four')");
      stmt.executeUpdate(
                "INSERT INTO myTable(test_id, " +
                   "test_val) VALUES(5,'Five')");

      //Get another statement object initialized
      // as shown.
      stmt = con.createStatement(
               ResultSet.TYPE_SCROLL_INSENSITIVE,
                     ResultSet.CONCUR_READ_ONLY);

      //Query the database, storing the result
      // in an object of type ResultSet
      rs = stmt.executeQuery("SELECT * " +
                "from myTable ORDER BY test_id");

      //Use the methods of class ResultSet in a
      // loop to display all of the data in the
      // database.
      System.out.println("Display all results:");
      while(rs.next()){
        int theInt= rs.getInt("test_id");
        String str = rs.getString("test_val");
        System.out.println("\ttest_id= " + theInt
                             + "\tstr = " + str);
      }//end while loop

      //Display the data in a specific row using
      // the rs.absolute method.
      System.out.println(
                        "Display row number 2:");
      if( rs.absolute(2) ){
        int theInt= rs.getInt("test_id");
        String str = rs.getString("test_val");
        System.out.println("\ttest_id= " + theInt
                             + "\tstr = " + str);
      }//end if

      //Delete the table and close the connection
      // to the database
      stmt.executeUpdate("DROP TABLE myTable");
      con.close();
    }catch( Exception e ) {
      e.printStackTrace();
    }//end catch
  }//end main
}//end class Jdbc10

Código fuente: Using JDBC with MySQL, Getting Started

Con DB4O es tan sencillo conectar a la BD como hacer lo siguiente:

// Crear una base si no existe, abrirla si ya existe.
     File file = new File("testDb4o.yap");
     String fullPath = file.getAbsolutePath();
     ObjectContainer db = Db4oFactory.openFile(file);
     try{
           // realizar alguna acción con db4o
           // Ejemplos :
           db.set(obj);  // Almacena un objeto en la base
           db.commit();       // Realizar la transacción (y arrancar otra)
           db.delete(obj);   // Eliminar un objeto en la base
     }
     finally{
           db.close();         // Cerrar la base y liberar los recursos
}

Existe abundante documentación en ingles y en español sobre el uso de DB4O con Java y C#, al bajar DB4O de la página oficial, encontraremos en dicha carpeta, un completo tutorial en español sobre su uso, además de una guía de referencia! De igual forma, existe un libro “The definitive guide to db4o” que aunque no es la versión actual, sin duda es un excelente comienzo para iniciarse en esta fantástica BD.

Finalmente… Dijiste que Hibernate conjunta los dos mundos, ¿Como lo hace? y si ya lo hace, ¿Para que usar DB4O?

Bueno, Hibernate utiliza archivos XML para “mapear” clases Java con columnas de una Tabla Relacional y mediante este mapeo, es posible hacer algo similar al código que vimos para guardar objetos en DB4O, pero la diferencia es que Hibernate internamente se encargará de hacer dicho “mapeo” por nosotros e insertar en las columnas de la Tabla Relacional! A cambio de esta comodidad de utilizar Java y MYSQL/SQL Server/etc., Hibernate disminuye el rendimiento de la aplicación!

Es causa de mucha polémica decir si DB4O es o no es la opción idónea para aplicaciones empresariales de gran escala, por lo mismo que las Bases de Datos Orientadas a Objetos no tienen un fuerte sustento matemático como si lo tienen las Relacionales, su penetración no ha sido tan fuerte! Por lo anterior, la industria del Software no ha querido experimentar en ambientes reales de gran escala la potencia de DB4O.

Independientemente de lo anterior, DB4O es la mejor opción para aquellos desarrolladores Freelance que desarrollan aplicaciones de escritorio o incluso web que no requieren de almacenar millones de datos!

Algunos recursos sobre el uso de DB4O son:

Serializar objetos Java a XML

2010-02-27T21:26:00.000-08:00

Mediante XStream podemos crear de manera extremadamente fácil un XML. En este ejemplo, aprenderemos la manera de hacerlo, para ello descarguemos la distribución binaria de la página oficial.-

HERRAMIENTAS

Equipo portatil Acer Aspire, Intel Celeron 1.86 Ghz, 1 GB RAM
Mandriva 2009, KDE 4
XStream 1.3.1
Eclipse 3.4.2-

DESARROLLO

Antes que nada, debemos agregar las librerias XStream a nuesro entorno de desarrollo, ya sea Eclipse, NetBeans o cualquier otro. En este enlace puedes ver como agregar librerias a eclipse. Las librerias que agregaremos para este ejemplo serán “xstream-1.3.1.jar” y “xpp3_min-1.1.4c.jar”.

Posteriormente creamos un proyecto Dynamic Web. Creamos una clase Java llamada “Direccion” y posteriormente otra llamada “Persona” dentro del paquete “beans”.

package beans;

public class Direccion {

 private String calle;
 private String colonia;
 private String municipio;
 private String estado;
 private int cp;

}

package beans;

import java.util.ArrayList;

public class Persona {

private String nombre;
private String apaterno;
private String amaterno;
private ArrayList direccion;

}

Finalmente encapsulamos todos atributos en sus métodos setter y getter, seleccionando los atributos y dando click derecho sobre la selección para escoger la opción de “Source–Generate Getters and Setters”.

Ahora crearemos una clase llamada TestXML dentro del paquete test, y copiaremos el siguiente código:

public class TestXML {

public static void main(String args[])
{
Direccion direccion = new Direccion(
"Aqui la calle","Aqui la colonia","Aqui municipio",
"Aqui el estado", 12345);

Persona persona = new Persona(
"Ascari", "Romo", "Pedraza", direccion);

XStream stream = new XStream();
stream.alias("persona", Persona.class);

String xml = stream.toXML(persona);
System.out.print(xml);

}

Como ven es muy fácil, ahora más interesante será obtener los datos de un manejador de BD, crear el XML como ya se explico y enviarlo a la capa de presentación en Flex para su visualización.