Drag and Drop en JavaFX 2.0

Hola

Os pongo un enlace donde hay un ejemplo de como implementar el drag and drop.

http://blog.ngopal.com.np/2011/06/09/draggable-node-in-javafx-2-0/

Un saludo

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.