Si alguna vez ha tenido la mala suerte de experimentar un fallo en JMP, probablemente haya visto un mensaje que le solicita que envíe los archivos de fallo a JMP. (Nota: envíenos sus fallos e indique su correo electrónico si desea contactar con el soporte técnico de JMP). Si envía sus archivos, estos se combinan con los de los evaluadores internos y clientes de todo el mundo y se incorporan al sistema de gestión de fallos de JMP. El equipo de DevOps de JMP utiliza nuestro propio software para analizar los archivos de fallo que usted ha reportado y, posteriormente, colabora con el equipo de desarrollo de JMP para identificar las relaciones entre las firmas de fallos y los errores conocidos.
Describo el proceso que seguimos para usar JMP y otras herramientas para analizar los fallos de JMP. Ahora nos resulta relativamente sencillo relacionar un nuevo informe de fallo con un problema conocido o identificarlo como un caso nuevo que requiere mayor investigación. Sin embargo, resolver fallos misteriosos novedosos no es tan sencillo. Este póster muestra cómo puedes ayudarnos a resolver más fallos proporcionando información detallada con tus informes y explica cómo esto contribuye al desarrollo de JMP. Además de los detalles de los fallos, JMP 18 también te permite enviar telemetría anónima sobre el uso de las funciones de JMP. Utilizamos esta información para comprender mejor los patrones de uso de los clientes, así como las distribuciones de hardware y sistemas operativos.
Hola a todos. Gracias por acompañarme en mi sesión de pósteres para aprender más sobre uno de mis temas favoritos. Soy Shannon Conners, Directora de Operaciones de Desarrollo de JMP. Hoy me gustaría hablarles sobre cómo pueden generar y compartir datos para ayudarnos a mejorar JMP.
Pero antes, unas breves palabras sobre mi grupo de DevOps. Nos encargamos de la planificación, las pruebas de infraestructura y todas las tareas de producción que dan soporte al desarrollo de funciones de JMP, la corrección de errores y las actualizaciones de seguridad. Damos soporte a todo ello en los distintos ciclos de lanzamiento.
Pero basta de hablar de mí. Hablemos un poco de ti. Si estás viendo este vídeo grabado en línea, probablemente seas un usuario frecuente de JMP como yo. Si es así, habrás notado que a veces JMP te pide que nos envíes información. Esto puede ocurrir principalmente en dos situaciones. La primera es si, por desgracia, sufres una violación de acceso a JMP o un fallo del software. La segunda es si instalas JMP; te pedirá que nos envíes estadísticas de uso anónimas. A esto lo llamamos telemetría. Te pedimos que des tu consentimiento para enviar esta información porque respetamos tu privacidad. Puedes configurar tus ajustes de privacidad en las preferencias de JMP, a menos que, por supuesto, tu organización ya los haya configurado por ti.
Primero, hablaremos de los fallos. Los clientes de JMP son muy creativos. Sabemos que tienen acceso a muchas fuentes de datos diferentes y pertenecen a diversos sectores, por lo que es posible que se encuentren con un fallo de JMP que no hayamos detectado en nuestras pruebas. Hemos integrado funciones de detección de fallos en JMP, que les avisarán cuando el software deje de funcionar. La próxima vez que lo reinicien, JMP les pedirá que nos envíen los detalles.
Con el paso de los años, hemos desarrollado un sistema interno que recibe, almacena y relaciona los informes de fallos con problemas conocidos. Este sistema nos permite identificar rápidamente si un fallo es nuevo y requiere una investigación más exhaustiva, o si ya lo conocemos y podemos orientar al cliente sobre cuándo estará disponible una solución o si ya existe una. Además de almacenar los informes de fallos de los clientes, el sistema también gestiona los informes de fallos detectados internamente por los centros de servicio, el soporte técnico, los evaluadores o cualquier otro miembro del equipo.
Hablemos un poco sobre cómo funciona esto. Es posible que veas este cuadro de diálogo con una X roja que indica que JMP se va a cerrar. Sé que a todos nos disgusta ver este cuadro de diálogo, pero lo verás. Cuando hagas clic en Aceptar, JMP se reiniciará. Luego verás que JMP se cerró inesperadamente y que hay una sección en blanco para agregar texto. Notarás que la opción "Enviar informes de forma anónima" está marcada, al igual que la opción "Buscar problemas recientes" cuando aparezca esta ventana.
En primer lugar, no haga clic en Cancelar aquí. Si lo hace, ni siquiera sabremos que se produjo el fallo. Entiendo que pueda sentir cierta inquietud al ver esta ventana sobre la información que JMP nos envía, pero no se preocupe, JMP no envía los scripts de la tabla abierta ni otros detalles similares. JMP solo envía los comentarios que introduzca en la sección en blanco de la ventana, información básica de instalación y verificación de su sistema Windows, como el sistema operativo o una lista de controladores o software instalados: información que nos ayuda a solucionar problemas.
Finalmente, JMP envía estos archivos de error que detallan la ruta del código que estaba activa cuando el software dejó de funcionar. Al igual que otros archivos de error generados por sistemas operativos o productos de software, estos archivos no son legibles para humanos y solo resultan útiles para el desarrollo al depurar un problema específico.
Si simplemente acepta la configuración predeterminada que ve en esta ventana y hace clic en "Enviar informe a JMP" para enviar su error de forma anónima, JMP subirá sus archivos a nuestro servidor. El envío anónimo agregará su error a nuestra base de datos, pero tenga en cuenta que a menudo no es posible diagnosticar y replicar completamente el problema solo con los archivos de error. Replicar el problema con acciones interactivas o un script JSL es el método ideal, tanto para depurar un error como desarrollador como para verificar cualquier solución que implementemos como probador.
Te recomiendo encarecidamente que desmarques la casilla "Anónimo" y proporciones tu dirección de correo electrónico. Esto te permitirá abrir un nuevo caso de soporte técnico y resolver tu problema con ellos. Trabajar directamente con nuestro equipo de soporte técnico hasta que puedan reproducir tu problema aumentará considerablemente las posibilidades de comprenderlo y solucionarlo en una futura versión.
Ahora bien, si no recuerdas qué hiciste o no tuviste tiempo de consultar con alguien, puedes enviar el informe de forma anónima. Si lo haces, por favor, incluye en el cuadro de texto cualquier detalle que recuerdes sobre lo que estabas haciendo cuando JMP falló. Si podemos reproducir el fallo, ya sea que lo hayas reportado al soporte técnico por correo electrónico o de forma anónima, crearemos un nuevo informe de error para dar seguimiento al problema. Si no podemos reproducirlo, el fallo permanecerá en nuestro sistema hasta que recibamos nueva información que nos ayude a realizar una prueba.
Quería hablarles un poco sobre la ventana de error donde les pedí que compartieran detalles sobre lo que estaban haciendo cuando JMP dejó de funcionar. La primera captura de pantalla muestra la vista predeterminada de este cuadro de diálogo de error. Como mencioné, no hay dirección de correo electrónico ni información del cliente. La marqué como la menos útil porque, si bien esto agrega el error a nuestra base de datos, este error anónimo, enviado sin información, tiene prácticamente ninguna posibilidad de ser replicado y resuelto en una versión futura.
En la segunda ventana, un cliente envió un informe de forma anónima, pero como pueden ver, incluyó un comentario muy útil sobre una acción que realizó antes del fallo, lo cual nos proporcionó suficiente información para reproducirlo. Sin embargo, como no proporcionó una dirección de correo electrónico, no pudimos informarle sobre la solución y confirmar que logramos reproducir el fallo. Ahora tenemos un informe de error y esperamos solucionarlo en el futuro.
La tercera ventana es un ejemplo en el que alguien envió un informe de forma anónima, pero proporcionó suficiente información como para que pudiéramos elaborar un informe de investigación para un desarrollador, quien pudo crear un script JMP para replicar el problema y encontrar una solución de inmediato.
La última ventana es un ejemplo. Alguien proporcionó una dirección de correo electrónico y un script. Esto es muy útil porque podemos ejecutar el script en varias versiones y determinar cuándo comenzó y cuándo dejó de ocurrir el problema. Entiendo que no todos tienen tiempo para crear un script que reproduzca el problema, pero si tienes uno que puedas compartir, nos ayudará a resolverlo mucho más rápido, lo cual es de gran ayuda.
Quería explicar brevemente cómo recibimos y procesamos sus archivos. Básicamente, los archivos de error se descargan del servidor. Añadimos símbolos a los archivos, lo que técnicamente significa procesar la pila de errores. Cargamos esa información en una base de datos y, a continuación, la comparamos para determinar si un nuevo error no coincide con ninguno que hayamos visto antes. Mostramos la información en los casos de soporte técnico cuando un cliente la envía por correo electrónico o en la página web de errores de JMP, una página interna que utilizamos para investigar errores anónimos y con nombre.
La telemetría sigue un proceso muy similar. En este caso, al no haber clientes con los que trabajar (ya que toda la telemetría se envía de forma anónima), podemos resumir los datos. Los almacenamos en una base de datos, los resumimos y los publicamos en JMP Live. Los desarrolladores que deseen profundizar en los datos y comprender mejor el uso de la plataforma o de las funciones pueden descargarlos directamente y consultarlos con este complemento de telemetría creado por el desarrollador Evan McCorkle.
Curiosamente, observamos que aproximadamente el 10 % de los clientes que autorizan 18 están optando por compartir su telemetría. Si bien la telemetría no abarca todos los usos de JMP, estamos obteniendo una muestra muy útil de lo que los clientes intentan hacer con el software, lo cual resulta sumamente valioso para el desarrollo de futuras versiones de JMP.
En resumen, queríamos señalar que su ayuda para esclarecer los problemas con JMP, ya sea mediante informes de fallos o errores que envíe directamente a support@jmp.com, es fundamental. Agradecemos los detalles que nos proporciona sobre lo que estaba haciendo cuando se encontró con el problema. Analizamos esta información y nuestro equipo de soporte técnico trabaja para reproducir dichos problemas. Si se trata de una versión beta del software, nuestros evaluadores se encargan de reproducirlos y buscamos solucionarlos.
Ahora, en JMP 18, también puedes contribuir compartiendo información de telemetría que nos ayuda a comprender los patrones de uso y cómo los usuarios interactúan con el software y sus flujos de trabajo. Esto es sumamente útil y esperamos que participes. Por último, quería recalcar que el personal interno de JMP utiliza el software para mejorarlo.
Somos como ustedes. Usamos JMP, usamos JSL, interactuamos con bases de datos, limpiamos nuestros datos, los procesamos, escribimos scripts y tenemos maneras de crear gráficos interactivos y publicar resultados en JMP Live. Eso es algo que me encanta tanto del pipeline de análisis de fallos como del pipeline de telemetría: que usamos JMP para mejorar JMP. Me parece genial.
Muchas gracias por escuchar mi charla. Si están en Discovery, no duden en pasar por mi sesión de pósteres; me encantaría hablar con ustedes personalmente. Muchas gracias.
