Sistema de log

Cuando se esta desarrollando una aplicación a menudo se comente el fallo de tomarse en serio el log cuando la aplicación esta muy avanzada. El log hay que usarlo desde el principio y siempre hay que estar seguro que se esta generando como se desea.

Hay que establecer una política de mensajes de tal manera que muestre información util para los desarrolladores. Esto es importante ya que no hay que confundir un log con un sistema de auditoria. Los sistemas de auditoria muestran las operaciones que se han realizado, con que datos y como han acabado y un log recoge información util para el equipo tecnico que indican datos sobre la implementacion, el estado de la aplicación, fallos, etc... Es decir, la auditoria esta orientado a negocio y el log al técnico.

Un error a eliminar del log es el sintoma del fallo ciclico. Estos log se corresponden a procesos automáticos (no requieren interaccion del usuario como pulsar un boton, etc..)  y que informan de un hecho (ya sea fallo o que ha podido realizar la tarea).

Por ejemplo, un proceso automatico que intenta conectar con una IP para enviarle un fichero xml y lo hace cada 5 segundos.

Si acierta el log dice :

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - Fichero 00222AC.xml enviado a 127.0.0.1


Si falla dice log dice :

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a ....

Y uno de estas dos pares lineas se escribe el log cada 5 segundos. Al final se tiene

[TareaEnviaXML] - Tarea funcionando....

[TareaEnviaXML] - Tratando de enviar el fichero 70222AC.xml
[TareaEnviaXML] - Fichero 70222AC.xml enviado a 127.0.0.1


[TareaEnviaXML] - Tratando de enviar el fichero 10222AC.xml
[TareaEnviaXML] - Fichero 10222AC.xml enviado a 127.0.0.1

[TareaEnviaXML] - Tratando de enviar el fichero 20222AC.xml

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X

[TareaEnviaXML] - Fichero 20222AC.xml enviado a 127.0.0.1
[TareaEnviaXML] - Tratando de enviar el fichero 30222AC.xml
[TareaEnviaXML] - Fichero 30222AC.xml enviado a 127.0.0.1

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X
...........
Asi el log se hará enorme y realmente no aporta tanta información,  es decir si el proceso ha cumplido con el fichero 70222AC.xml en realidad no necesito saberlo en el log. Si fallo para el fichero 00222AC.xml entonces si, pero si luego falla por lo mismo en realidad tampoco necesito ver el log para saberlo, lo que realmente se necesita es ver cuando a funcionando o si ha fallado por otra cosa. Por lo que el log quedaria:

[TareaEnviaXML] - Tarea funcionando....

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X

[TareaEnviaXML] - Tratando de enviar el fichero  00222AC .xml
[TareaEnviaXML] - Fichero  00222AC .xml enviado a 127.0.0.1

y ya esta. O:




[TareaEnviaXML] - Tarea funcionando....

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a Y

[TareaEnviaXML] - Tratando de enviar el fichero 00222AC.xml
[TareaEnviaXML] - El fichero 00222AC.xml no se ha podido enviar a 127.0.0.1 debido a X



[TareaEnviaXML] - Tratando de enviar el fichero  00222AC .xml
[TareaEnviaXML] - Fichero  00222AC .xml enviado a 127.0.0.1

Esto representa un log mas pequeño que muestra la misma informacion.

Software parts dependency research(I)

When the develop team is in design phase have to think a lot of thing but there are two concepts that are the most important concepts. In addition, it is a good beginning for the design approach starting think in these concepts.

These concepts are:

•          Which are the parts of software?
•           How coupled are these parts?

Think about that… step by step

Which is the correct way to split the software up into parts? The software splitting can not be a mechanical process because the main factor is the information system that have to be solved by the software and this information system is fully subjective, that is to say:

•     The costumer have to explain it.
•          The  develop team have to understand.
•           The initial approaching, based on costumer/develop team interviews, will change when the software developing have skill that can be review, analyze, etc. In that moment, the fight will begin. Sure.  It will be because the costumer will say:”I don’t want this, this have to be in this way”. The develop team will say:” You said you want this”.  The costumer say:”you didn’t get it, I wanted this”… Do you know the song???   

I show you the “Box split” method for splitting information system up into parts that can be used like parts of the software. The purpose is the split information system process can set the base for development.

1º Step. Information capture process: Like all good development, the information system have to be understood by the team members. Advice: when the developers talk about their work (the software) usually use a technical words that  must not be understood by the  customer. It happened to costumer too. They usually use the their language for telling us that they want. This is good because if they use the their language then the develop team can suppose how the software interface have to be but warning because the customer explanation can be only good for interface. The business logic have to be a deal between the develop team and the customer said in a technical words. Never let the costumer explain the business logic in their language.

El no empezar de cero

Cuando se empieza el desarrollo de una aplicación se puede diseñar la aplicación, se pueden hacer pruebas de concepto (utilizo este framework?, esta tecnología?, etc..), etc… Todo parece maravilloso. YA SE LIARA DESPUES.

Pero en el mundo empresarial lo mas normal es que o que te incorpores a un proyecto ya empezado o que se te obligue a partir de un proyecto ya existente. Esto unido al hecho de que al no conocer el negocio tan bien como la gente que ya estaba en el proyecto hace que si quieres hacer algo mejor, aplicar alguna nueva tecnología, crear un marco de trabajo, etc… Digas cosas como: “Es que no me dejan” , “Ya esta tan mal que no lo puedo cambiar”, “En el próximo proyecto…”    TE SUENA ¿verdad?

Es cierto que si el proyecto se empezara de cero se podrían hacer las cosas de otra manera pero eso no va a pasar por dos motivos principalmente:

-          No se puede asumir el coste (da igual el proyecto, imposible que exista un proyecto que asuma el coste de que lo desarrollado hasta el momento no valga)

-          ¿Quién te dice que lo nuevo que vas a introducir es mejor que lo que ya había? (ojo con esto y no te confies por muy bueno que te parezca lo que quieres poner  que demostrar la mejora de algo a nivel de diseño o explicándolo es muy complicado).

Tienes dos opciones:

-          No propones nada para el proyecto actual pero aprovechas el proyecto actual para conocer el negocio y proponer algo para el siguiente.

-          Cuando tengas claro lo que quieres proponer entonces lo haces para las nuevas tareas que vayan surgiendo. De esto se deduce que TIENE QUE SER COMPATIBLE CON LO QUE YA EXISTE (1).

(1)    El hacer compatible lo que quieres proponer para tu proyecto seguro que limitara la potencia que lo que pretendes pero es la forma de que tus superiores acepten tu propuesta.

Limitación de competencias

La limitación de competencias consiste en determinar de forma lógica quien es el responsable de una determinada funcionalidad de un sistema complejo. Y cuando digo responsable, me refiero a todos los estratos del ciclo de vida de la funcionalidad:

- Desarrollo

          - Mantenimiento

          - Solución de errores

- Etc..

La limitación de competencias es un gran problema ya que, aparte de que es un asunto muy subjetivo, los responsables se ven sujetos a demasiados detalles de muy bajo nivel (lo que costo hacer esto, los problemas que dio lo otro, etc..) y tienden a “barrer para casa”; es decir, a no buscar la mejor solución si no lo que menos trabajo les de.

Por ejemplo, un equipo que se encarga del desarrollo de una página web(PW) y otro de una capa de Web Services(WS) que controla los datos del cliente. Entonces:

1º PW quiere saber los datos de un cliente y WS le dice “llama a la función A con el DNI”.

2º Lo hace y funciona.

3º Se entra en producción y los usuario se dan cuenta que algunos DNI no funcionan. Se le indica a PW. PW se lo dice a WS y este le responde:”Es que si el DNI no esta cuando se llama a la funcion A hay que llamar a la funcion B con el DNI”

4º …. PROBLEMA

Que seria lo correcto: ¿PW cambia la llamada y llamaría a la funcion B? ¿WS cambia la funcion A para llamar a la funcion B y obtener el resultado?

Ambas soluciones tienen pros y contras. Ambas soluciones podrían ser correctas y/o erróneas bajo determinados contextos. Entonces como determinar quien tiene que hacer la modificación? 

La solución mas común es solucionar el problema llegando a un acuerdo entre los responsables de PW y SW y si no se puede llegar a una solución entonces acudir a una figura superior (un jefe de los dos equipos).

Tanto si se llega a un acuerdo como si se acude a una figura superior, es clave la capacidad de hacerse entender por parte de los responsables de cada equipo. Por lo que se puede decir que el resultado de un producto software se ve determinado por las actitudes comunicativas de sus responsables mas que por las habilidades técnicas de estos responsables.

Manipulacion de bytecode con Javassist. Incluir funcionalidad a las anotaciones.

La reflexión es el método tradicional que ofrece Java para hacer  programación dinámica donde el modo de instanciar objetos y donde y cuando usar los métodos de estas instancias no se conoce en tiempo de compilación. Pero la reflexión presenta dos problemas:

-       No deja manipular el código. Es decir se puede, por ejemplo, definir un método nuevo en tiempo de ejecución.

-       Es muy lento (Mirar articulo http://www.ibm.com/developerworks/java/library/j-dyn0610/)

La manipulación de bytecode permite lo mismo que la reflexión, además se puede incluir código nuevo en tiempo de ejecución y es más rápida que la reflexión.

Existen varios frameworks para manipular bytecode. Yo recomiendo Javassist porque es prácticamente como la reflexión nativa de Java pero de manera ampliada.

El siguiente ejemplo ilustra de manera simple como usar javassist para potenciar el uso de una anotación.

public @interface PonleValor

{

   

}

class Hello {

    

     @PonleValor

     private String valor;

    

    

    public void say() {

        System.out.println("Hello es " + valor);

    }

}

public class Test {

   

     public static void main(String[] args) throws Exception {

        ClassPool cp = ClassPool.getDefault();

        CtClass cc = cp.get("es.trap.Hello");

       

        for (Object field:cc.getClassFile().getFields()){

           

           

           FieldInfo info = (FieldInfo)field;

          

           for (Object atrib :info.getAttributes()){

              

              

              

               if (atrib instanceof AnnotationsAttribute){

              

                   AnnotationsAttribute anota = (AnnotationsAttribute)atrib;

                  

                   String name = anota.getAnnotations()[0].getTypeName();

                   

                   if (name.equals(  "es.indra.trap.PonleValor"))                  

                       cc.getConstructors()[0].insertAfter( "{" + info.getName()+  "= \"Ahora vale algo\"; }" );

               }

                  

               

           }

           

        }

      

        Class c = cc.toClass();

        Hello h = (Hello)c.newInstance();

        h.say();

    }

}

Como se puede ver en ejemplo, si instanciamos la clase Hello con Javassist (como si se hiciera con reflexión) y una de sus variables tiene la anotación PonValor entonces se le pondrá un valor de forma automática.

El resultado si se ejecuta este programa es:

Hello es Ahora vale algo

Obtener peticion HTTP en Java

Una peticion HTTP no es mas que un String que envia un emisor para probocar una respuesta en un receptor.

Si se quiere ver una peticion HTTP lo mas facil es enviarla a un puerto donde este un socket escuchando.

Por ejemplo:

public class Main {

    /**
     * @param args the command line arguments
     */
    public static void main(String[] args) throws Exception {
       ServerSocket server = new ServerSocket(8080);

       Socket so = server.accept();

       DataInputStream ent = new  DataInputStream(so.getInputStream());

       byte [] sal = new byte[256];
       while (ent.read(sal) != 0)
        System.out.println(new String(sal));

      }

}


Si se hace la peticion (por ejemplo con el SOAPUI) a localhost:8080/WS la respuesta seria:

POST /WS HTTP/1.0
Content-Type: text/xml; charset=utf-8
Accept: application/soap+xml, application/dime, multipart/related, text/*
User-Agent: Axis/1.4
Host: localhost:8080
Cache-Control: no-cache
Pragma: no-cache
SOAPAction: "
"
Content-Length: 473

<?xml version="1.0" encoding="UTF-8"?>
<soapenv:Envelope xmlns:soapenv="http://schemas.xmlsoap.org/soap/envelope/" xmlns:xsd="http://www.w3.org/2001/XMLSchema" xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance">
<soapenv:Body>
<wsHola xmlns="http://es.indra.transporte.webservices.cscreplacement.core">

<respuesta>Hola Mundo</respuesta>

</wsHola>
</soapenv:Body>
</soapenv:Envelope>

Y ya esta.

Editor grafico para JavaFX 2.0

Hola

Acabo de ver que Oracle a publicado un editor grafico para JavaFX.
Se puede descargar de aqui.

Cuando pueda le hecho un ojo y os cuento.

Un saludo