Scripting: compatibilidad ascendente en generalCasi todas las versiones (desde 7y) recibo llamadas de clientes que dicen que sus scripts ya no funcionan en la nueva versión. ¿Recibes llamadas similares?
Me pregunto si podríamos tener una mejor verificación de compatibilidad ascendente para los scripts personalizados (no los generados integrados, donde espero que tengamos esta verificación). Para ser claros, no hablo de la capacidad hacia atrás (es decir, mi script JMP 15 no se ejecuta en JMP 13) ya que el software evoluciona de forma natural. Pero como consumidor / usuario, esperaría que un script que escribo en JMP 14 se ejecute en JMP 15 todavía.
Sé que Early adopter es una forma de conocer esto temprano y enviar los problemas a la lista de correo electrónico. PERO hay un gran problema: los usuarios generalmente no tienen el tiempo para hacer una verificación de compatibilidad en los primeros usuarios, especialmente si hay entre 7 y 9 versiones. Esto debe hacerse en el lado del proveedor de software. Eso es también de lo que los clientes se quejan la mayor parte del tiempo. "No es su trabajo" y debo admitir que en parte estoy de acuerdo (en la mayoría de los casos).
Entonces, ¿tiene quejas similares de los clientes? ¿Cuál es nuestro proceso actual de verificación de compatibilidad ascendente? Sería bueno reunir aquí algunos casos y sugerencias sobre lo que se podría hacer. (Y también podría discutir esto durante una sesión de lanzamiento con los desarrolladores correspondientes; recuerdo las preguntas y respuestas en la sesión plenaria en las que uno podía abordar esas cosas, pero creo que la última fue hace 3 años), ¿podría uno solo para las SE en 2020? )
Gracias,
Martín
PD: La razón por la que hago esto tan destacado, un cliente de fabricación con más de 100 licencias es tan molesto desde hace años que piensan en pasar de JMP a otras soluciones, incluso de código abierto, y son realmente amigables con JMP durante años).
Re: Scripting: Compatibilidad ascendente en generalHola martin,
FWIW, mi experiencia es que la falta de compatibilidad con los reenvíos casi siempre está relacionada con sacar cosas del informe para manipularlas aún más. Usted dice que es razonable esperar que el software "evolucione naturalmente", pero, nos guste o no, los cambios en la estructura del informe son una consecuencia casi inevitable de este deseo. Siempre debemos esforzarnos por señalar esto a los clientes que realmente hacen un uso intensivo de los scripts.
Como ya sabe, para el software utilizado en 'producción', es muy común, incluso requerido, tener áreas de preparación en las que el software actualizado se pruebe a fondo antes de ponerlo en 'funcionamiento'. Se podría ver que esta disciplina está en desacuerdo con el hecho de que JMP es "simplemente" un software de escritorio, pero (como lo ilustra su mensaje) los riesgos son realmente reales y deberíamos ayudar a los usuarios a ver JMP de esta manera cuando sus patrones de uso lo exijan.
En resumen, esta tensión es un efecto secundario del hecho de que JMP es tan funcional. Creo que podemos y debemos hacer un mejor trabajo al alertar a los clientes sobre los riesgos y las consecuencias de no brindar a un código JSL significativo el respaldo de buenas prácticas de ingeniería de software industrial. I + D 'podría' proporcionar métodos para obtener todos los valores requeridos de una manera independiente del informe, pero esto no está en ninguna hoja de ruta que yo sepa, y en cualquier caso eliminaría parte de la flexibilidad que los programadores de JSL parecen valorar muy.
Al igual que usted, estaría muy interesado en escuchar otros ejemplos en los que nos hemos metido en problemas por esto. . .
Salud,
Ian
Re: Scripting: Compatibilidad ascendente en general¡Hola martin!
TL; DR:
Punto 1: Los saltos de código entre versiones generalmente se deben a que las personas no siguen las mejores prácticas de JSL y las secuencias de comandos defensivamente. Punto 2: Siempre es responsabilidad del cliente validar cualquier rendimiento de software (local o de otro tipo) entre versiones. Deben tratarlo como cualquier otra herramienta de fabricación, que se examina antes de lanzarse a producción.
La versión larga:
Solo para hablar sobre el comentario @ian_jmp realizado: en su mayor parte, los saltos de código entre versiones se deben a que las personas no siguen (o siguen el ritmo) de las mejores prácticas de JSL. Es mucho más fácil romper el código que funciona pero no está bien pensado. Mark Bailey lo llama "scripting defensivo". El ejemplo de Ian de personas que se extraen de informes existentes es clásico, particularmente si están suscribiendo todo el árbol de visualización. La mejor práctica para esto es usar un nombre de cuadro de esquema como punto de referencia local y luego subíndice (porque no cambian con tanta frecuencia).
También me he encontrado con un par de instancias en las que las personas (incluido yo mismo) construimos JSL que se basa en una característica que obtiene una revisión entre versiones. Para mí, los cambios en Recode que salieron en JMP 14 rompieron parte de un complemento que estaba manteniendo. En ese caso, hice algo para que el código funcionara y me quemé por ello. Otro ejemplo (cliente) es cuando alguien estaba usando nombres no compatibles con ODBC en su base de datos. Cuando aplicamos ODBC entre versiones, los scripts se rompieron. Aquí alguien no siguió los estándares y se quemaron por ello. La conclusión es que es menos probable que sus clientes tengan problemas si crean un código que siga nuestras mejores prácticas para escribir JSL. Si lo hacen, es bastante raro que JSL rompa versión por versión. La mayoría de las cosas que he escrito con una mentalidad de scripting defensivo es bastante robusta, pero aún así me aseguro de que todo funcione. Por lo general, espero hasta el último par de lanzamientos de adoptadores tempranos para probar (los cambios a JMP generalmente son bastante estables en ese punto).
Ian también hizo un muy buen punto sobre moverse entre versiones. En los EE. UU., Tenemos ciertas industrias que están fuertemente reguladas (Farmacia, Biotecnología, Finanzas y algunas de fabricación con aplicaciones militares o de seguridad nacional). Estas industrias tienen requisitos de validación para cualquier nuevo software o nuevas versiones de software que requieran que la base de usuarios documente que han verificado que el software funciona y proporciona resultados consistentes entre las versiones. Mis otros clientes saben que necesitan verificar su código entre versiones. Así que creo que es realmente el problema de la madurez y la disciplina en la cultura de la empresa de ese cliente (o al menos con las personas que generan el JSL allí). El flujo de trabajo de prueba que mencionó Ian (puesta en escena, luego lanzamiento a producción) es una práctica estándar en todas las industrias con las que he trabajado (en los EE. UU., La UE o Asia): deberían saberlo mejor que asumir.
Entonces, en resumen, si su JSL es de misión crítica, deben tratarlo como cualquier otro software de producción y validar la versión de JMP (con el JSL de misión crítica) antes de lanzarlo a producción. Apuesto a que sus quejas provienen principalmente de partes de la comunidad de ingenieros que no entienden cómo funciona. Puede preguntarles si lanzarían una nueva pieza de equipo a producción antes de probar a fondo el rendimiento de esa herramienta y hacer coincidir las otras partes; responderían "no". En ese momento, podría señalar que el software es una herramienta y debería ser tratado igual.
Pensamiento de seguimiento
Pensando más en esto: si las personas siguen las mejores prácticas de JSL (usando funciones y expresiones, alcance, espacios de nombres, comentando mucho su código , etc.) es más fácil de depurar cuando las cosas se rompen (lo que hacen). Por lo tanto, parece que el cliente en cuestión tiene un JSL frágil mal formado que se cultiva orgánicamente con el tiempo. Probablemente esté horriblemente comentado y la persona que lo escribió se ha movido o no tiene idea de cómo solucionarlo (llamo a estos guiones franken) ... En ese caso, recomendaría que envíen a alguien que conozca JSL a los cursos de SAS Ed JSL para una actualización de las mejores prácticas y luego los suelten para modernizar el código en cuestión y coloquen algunos SOP para agregar el JSL en cuestión a sus planes de prueba de validación de software.
Re: Scripting: Compatibilidad ascendente en generalEstoy de acuerdo con todos los comentarios hasta ahora. Veo el código de 'producción' todo el tiempo que es horrible. No puedo creer que funcione en la versión actual, mucho menos tener una esperanza en el futuro. Estos usuarios no han aprendido a escribir JMP. Eso es diferente de la programación informática general. No es solo sintaxis. Ellos simplemente piratean. (Uso el término 'hacker' con veneración. Esta actividad es diferente.) No saben lo que están haciendo.
En cuanto al comentario sobre los cambios en la interfaz de usuario de JMP que impiden el acceso a la capa de informe, muchos usuarios no practican la codificación segura. Hay formas de minimizar o eliminar estos problemas, pero su forma produce código frágil.
Re: Scripting: Compatibilidad ascendente en generalGracias hasta ahora por sus comentarios. Estoy de acuerdo con todos sus puntos con respecto a las pruebas antes de entrar en producción y guardar / codificación defensiva (aunque a los usuarios probablemente no les gustará;)). Esto es definitivamente responsabilidad del usuario y la empresa que utiliza scripts en cualquier idioma.
Sin embargo, quiero avanzar en la discusión también con un punto de vista más crítico (- al final, espero que tengamos en el mejor de los casos un mensaje común para los clientes y un proceso de automatización más robusto para vender a nuestros clientes):
Viniendo de una casa de software que se basa en el lenguaje de programación en el que se basa la herramienta, me sorprende la frecuencia con la que sé que JSL está cambiando de una versión a otra. En mi vida pasada, solo tuve estos problemas con funciones y funciones indocumentadas, no con configuraciones y opciones como, por ejemplo, temas de color y otras cosas en los árboles o métodos de objetos. Además, todas las funciones se documentaron en toda su extensión: qué entradas y salidas están disponibles, cuál es la descripción y definición de esta opción / entrada / salida, etc. La guía de secuencias de comandos y el índice no son del mismo tipo. Además, esta es la llamada básica y todas las demás opciones posibles que tiene que averiguar usted mismo.
Se podría decir que toda parte no documentada está sujeta a cambios, esa sería la respuesta fácil. Pero creo que no es tan fácil. La mayoría de las veces necesitamos cambiar al menos un poco del "nivel inferior a las funciones integradas". No proporcionamos una documentación concreta que diga "eso es lo que puede hacer" y "todo lo demás no es compatible" (también puede funcionar ahora, pero está sujeto a cambios).
Un lenguaje de programación debe tener dicho marco, o decimos que JSL no es un lenguaje de programación así, y tengamos más cuidado con nuestra promoción actual de crear aplicaciones para llegar a más usuarios, ya que es fácil construir código reproducible pero podría no ser tan confiable para futuras versiones
Sería interesante escuchar cómo se sienten los demás al respecto (lo admito más y con un punto de vista crítico, una vez más para fomentar una discusión diversa sobre este tema), también uno u otro desarrollador puede hacer esto en su día para base del día
Re: Scripting: Compatibilidad ascendente en generalSu último punto es el crítico: JSL es increíblemente poderoso, pero en esencia no es un "lenguaje de programación", es un lenguaje de script o macro. Tiene estructuras que se asemejan a la Programación Orientada a Objetos, y se puede usar de esa manera hasta cierto punto, pero está construido sobre JMP y siempre ha sido diseñado para automatizar tareas en la GUI o extender la GUI. Mucha gente olvida eso, lo que también significa que se olvidan cuando se cambian las cosas en el producto, las cosas pueden romperse en JSL (particularmente si no las codifican bien). No deberíamos hablar de JSL de la forma en que hacemos C ++, etc. Estrictamente hablando, incluso Python y R son lenguajes de programación más relacionados que JSL. Quizás algunas personas se confunden porque la línea está borrosa con Excel Macros y VBA. Sin embargo, el punto es que JSL es un lenguaje de script que es diferente a un lenguaje de programación.
Mejor,
METRO
Re: Scripting: Compatibilidad ascendente en generalHola Mike,
De acuerdo, es un lenguaje de secuencias de comandos y, por lo tanto, debe tratarse. Esta discusión me pareció valiosa, ya que también destaca algunos aspectos adicionales que siempre debemos guiar a las personas para que piensen al comenzar a automatizar o escribir sus procesos. ¿Tenemos, además del curso de capacitación JMP JSL, otras referencias relacionadas con JMP para la escritura "defensiva"?
La mayoría de las referencias que se encuentran en la web son para otros idiomas y no están relacionadas con JMP (aunque también podría usarlas, por supuesto). Las transmisiones web de Mastering JMP no cubren un buen estilo de programación / scripting. ¿Podría ser un tema interesante también para una presentación de descubrimiento?
Re: Scripting: Compatibilidad ascendente en generalEsa es un área en la que creo que podríamos mejorar. Hay mucha información sobre la comunidad, en el cerebro del personal, en los libros y en la documentación, pero realmente no hay un documento de "mejores prácticas" que yo sepa. Debería haber. Creo que gran parte de la consternación que estás experimentando en el campo puede atribuirse a este punto.
@ian_jmp - tal vez esto sería algo que la comunidad técnica podría hacer como barra lateral durante el inicio.
Mejor,
METRO
Re: Scripting: Compatibilidad ascendente en generalComo sugirió mi respuesta, creo que esta es un área con la que podríamos mejorar, especialmente porque generalmente fomentamos la creación de aplicaciones como un componente de la parte de 'expandir' de nuestra 'estrategia de expandir y expandir'.
FWIW, mi opinión personal es que no todos los SE deben ser competentes en JSL a menos que estén tan inclinados. Pero sí creo que cada SE debe saber lo que es posible y, junto con esto, cómo se vería una buena práctica y las dificultades de no adherirse a esto.
Desafortunadamente, aunque el inicio de 2020 está un poco comprimido, y la pista técnica ya está organizada. Entonces encontraremos otra forma de manejar esto. Más tarde.
Re: Scripting: Compatibilidad ascendente en generalComenzamos a agregar sugerencias explícitas de "mejores prácticas" en nuestros cursos de secuencias de comandos hace varias ediciones. Continuamos ampliando y refinando estas sugerencias con cada revisión. Recibimos comentarios positivos de los estudiantes. Bueno, al menos de los estudiantes que no tienen prisa por hackear.
