Cómo depurar el código en V7 ?


([N1] Emanuel) #1

Es la pregunta que me surge? Qué métodos podría usar?

Saludos.


([N1] aztecmexico) #2

Buen día,

  1. Primero que nada leer a fondo la documentación para conocer un poco más a fondo la plataforma, haciendo especial énfasis en las notas, comentarios y observaciones que vienen en el manual.
  2. Llenar de mensajes tus desarrollos cuando algo falla, no es lo óptimo y pierdes algo de tiempo pero no hay de otra.
  3. Algún participante en el foro comentó recientemente “oler los errores”, pero eso solo te lo dan muchas horas de experiencia en la plataforma, que no dudo que las tengas.
  4. Prueba y error, aunque a veces esod e jugar a la gallinita ciega enerva.
  5. Estar al tanto de las publicaciones en la Base de conocimiento y de los correos que Velneo envía a los suscriptores y miembros del foro.
  6. Utilizar el vBugman.
  7. Preguntar en el foro, que tiene una EXCELENTE comunidad y más de alguno te puede sugerir por donde van los tiros.

En fín, lo que se te ocurra.

Algo muy importante, tratar desde un principio de llevar una metodología para el desarrollo, entre más ordenados seamos al desarrollar menos dolores de cabeza tendremos.

Hay muchas sugerencias y consejos de buenas prácticas, pero todos están regados por el foro y otros lugares y blogs.

Es muy difícil, pero no imposible, es hasta cierto punto “natural” que entre más potencia de la plataforma mayor dificultad al depurar, son ya muchas las características que tiene V7 y cada una merece muchas horas de estudio y de análisis pero a fín de cuentas sigue valiendo la pena y como dicen por ahí, si todo fuera fácil pues cualquiera lo haría.

Saludos.

Martin Ibarra.


([N3] blavan) #3

Hombre por fin un poco de cordura en los comentarios sobre este tema.
De joven participaba en campeonatos de tiro de precisión con arma larga, cuando las cosas se torcian era muy normal ver compañeros echando pestes contra la munición y el visor, ellos nunca eran el problema, yo nunca fui de esa teoría y primero analizaba el fallo humano.
Que un depurador pueda detectar que la instrucción Get variable local del objeto después de disparar objeto este como hija de disparar objeto y no a su altura pues puede pero hablando de codigo v7 puro de cuantas lineas de codigo estamos hablando en cada evento o proceso.

Personalmente cuando un evento o proceso me pide mas de 20 lineas de codigo MALO, seguro que eso se resuelve de otra forma mas simple y sencilla.


([N3] pacosatu) #4

Hola Benito.

Evidentemente en Velneo V7 “puro” es teóricamente innecesario un Depurador, porque es Velneo el que nos asiste en todo momento para no cometer errores. El problema es que esto es la teoría y en la práctica aparecen errores que Velneo no detecta (como el Get variable local del objeto) y es entonces cuando se agradece una buena herramienta de depuración. Esto se agrava si empezamos a meter en nuestras aplicaciones miles de líneas HTML, JavaScript, …

En un campeonato de tiro de precisión, 2 armas largas del mismo fabricante se pueden comportar de forma distinta. Uno de los competidores ajustará su mirilla mediante procesos manuales de prueba y error y sabe que su tiro se desvía un poco a la derecha. El otro competidor dispone de una herramienta (comprada al propio fabricante del arma) que mediante un rayo láser le dice con total precisión que el tiro se desvía 3,02mm a la izquierda con un viento lateral de 5 m/s. Quizás el de prueba y error es mejor tirador, pero el del rayo láser sabe con certeza cómo corregir la mirilla porque ha depurado el arma y tiene una tabla con las relaciones velocidad-viento/desviación.

Una herramienta de depuración, no es solo algo que detecte errores, es también:

  • Poder poner marcas en nuestro código, TODO, REVISAR, ANCLAJES, …
  • Poder documentar ampliamente nuestro código sin el handicap de que el proyecto crecerá de tamaño y ralentizá la ejecución (¡¡ esto es absurdo !!)
  • Poder auditar la ejecución de cada línea de código para saber el tiempo que tarda en ejecución. Puedes descubrir que una llamada a una función tarda 10 segundos y de allí deducir que el algoritmo está mal diseñado, que haces una consulta a un servidor lento, etc…
  • Poder poner puntos de ruptura y ver una “foto” de las 100 variables, entre globales y locales, que están al alcance en ese momento.
  • Poder ejecutar los objetos desde vDevelop para probarlos.
  • Poder copiar y pegar código V7 desde el portapapeles a un editor de texto para documentar la aplicación.
  • Poder analizar cómodamente código de terceros para hacer refactoring y evitarse horas de penosa lectura de código ineficiente.
  • Y muchas cosas más

JavaScript nos aportó dinamismo en la ejecución de nuestras aplicaciones, ahora nos falta también ese dinamismo en la resolución de errores.

Saludos
Paco Satué


([N1] aztecmexico) #5

Buen día,

=).

Todos los comentarios son hechos con cordura, en este caso y días después de la incidencia pues aderezados con paciencia, y los de otros días con mucha cordura, pero tambien aderezados con mucho cabreo, que no por eso pierden la cordura.

El depurador no es un tema de si Velneo quiere o no quiere o si puede o no puede, es necesario.

con cada nueva funcionalidad, característica, etc. y al abrir tanto el abanico se hace cada vez más indispensable una herramienta de este tipo, para mantener la filosofía “life is soft”, porque ahorita estamos “Debugging is hard”.

No le echo culpas que no le corresponden, pero hay muchos temas que se le escapan y recapitulando un poco, en mi incidente pasada pues a fín de cuentas SI era un problema de la plataforma, “algo” sucedio que no funcionaba mi sistema, y para dar con la solución pues fue después de mucho análisis y demasiada prueba y error.

La muchacha es guapa, me gusta y me casé con ella, pero eso no quita que tenga sus defectitos -yo tambien- lo interesante aqui es que esté dispuesta a mejorar.

Saludos.

Martin Ibarra.


([N1] Emanuel) #6

Les agradezco sus comentarios, pero hablando más en términos técnicos, es decir de la técnica que se puede usar para hacer el debug.

Las dos alternativas sería usando mensajes (alert) o realizando un registro (LOG) en alguna tabla para tener un seguimiento de ejecución?

Saludos.


([N4] velavisual) #7

@Emanuel

Puedes mirar las funcionalidades de la Open Apps vLogger, está enfocada a hacer Logs de nuestra aplicaciones.

Componente que permite fácilmente hacer log de nuestra aplicación. Se ha portado, en la medida de lo posible, la potencia de log4j. Podemos usarlo sin configurar absolutamente nada, o personalizarlo con nuestras necesidades.
Podemos loguear a pantalla, a fichero de texto en el servidor, fichero diario, etc. Además se puede personalizar fácilmente con más salidas o formateadores del texto.


([N1] aztecmexico) #8

Hola Emanuel,

Tambien he utilizado la última que mencionas, pero no en una tabla, sino generando el log en archivo .txt


([N1] Emanuel) #9

Muchas gracias, seguiré sus consejos.

Saludos.


([N4] ofsantana) #10

Bueno yo uso una técnica que le aprendí a @alfonsogu (creo que la explicó una vez en los foros de 6.x), y que consta de crear una variable global llamada $BUG, y la activo o desactivo en una parte del menú de la aplicación. De esta manera los mensajes sólo se ven cuando activo la variable $BUG, y me aseguro que no se me vayan en la versión de producción.

Pero lo dicho por todos, a veces esto no resuelve y toca “oler” los errores, pero esto requiere, como dijo Martín, bastantes añitos con la herramienta y saber cuando algo huele mal. Pero si te sirve la técnica del $BUG adelante, a mi me ha resuelto muchos problemas de “debug”