Uno de los mayores desafíos que enfrentamos al desarrollar JMP dentro de una organización es que las personas empiezan a aprender a usar JSL, y empezamos a ver esta proliferación de código JSL dentro de la organización. Uno de los mayores desafíos que surge a medida que JMP se adopta a mayor escala en una empresa es la cuestión de cómo gestionar todo el código generado por el usuario a gran escala. ¿Cómo controlar todo esto?
A lo largo de los años, se han propuesto muchos métodos diferentes para lograrlo. Algunos provienen del campo de la informática y el desarrollo de software, como los sistemas de control de versiones. Otros proponen simplemente usar una unidad compartida. Resulta que ambos métodos tienen sus ventajas y desventajas.
Para darles una pequeña luz al final del túnel, de hecho, existe un punto medio que funciona bastante bien para esto, aunque no del todo... No quiero dedicar todos los recursos a desarrollar una empresa de desarrollo de software completa internamente para gestionar el software. No quiero dirigir el Salvaje Oeste, que es simplemente una unidad compartida en el servidor de alguien.
Pero resulta que esos dos extremos tienen sus pros y sus contras. Cuando hablamos de Git o de sistemas de control de versiones, GitHub suele ser el que la gente conoce mejor. ¿Gestionar bases de código? Eso es precisamente lo que hace muy bien. Es muy bueno.
¿Implementar actualizaciones fácilmente? No es su especialidad. No está diseñado para eso. Está diseñado para el flujo de trabajo de desarrollo de software profesional, y no es de eso de lo que hablamos aquí. No lo hace especialmente bien.
Controlar el acceso y los permisos de versión, por supuesto, lo hace bastante bien. Mantener el control de versiones y saber cómo se rastrean los cambios a lo largo del tiempo son precisamente las funciones para las que están diseñados estos sistemas de control de versiones. Por ello, no es apto para principiantes. Está diseñado para profesionales.
He visto ejemplos de su uso práctico, pero suelen ser organizaciones que dedican personal, recursos y tiempo a crear un grupo de desarrollo de software dentro de la empresa. Esto puede funcionar en ciertas situaciones, o puede que ya lo tengan por otras razones.
En el otro extremo, la idea de usar solo archivos JSL y una carpeta o directorio compartido en algún servidor. Es prácticamente el mismo que el sistema de control de versiones. La gestión del código base no es excelente. Está mejorando con algunos de estos sistemas en la nube, pero aún no es excelente.
¿Implementar actualizaciones fácilmente? Claro. Simplemente haz clic en la última actualización. Quizás envíes un correo electrónico o algo similar, o uses algunos complementos. Parte del código que se ha propuesto con el tiempo para facilitar este flujo de trabajo en particular se puede añadir a tus complementos. Sin duda, es una posibilidad, pero no trivial. Mejor que el sistema de control de versiones en este aspecto.
¿Control de acceso? Siendo sinceros, no es gran cosa. ¿Ideal para principiantes? Sí. No está mal, pero tampoco es superlativo. Resulta que hay un punto medio. Mi colega y yo, mi coautor y yo, llegamos a esto desde dos actividades de desarrollo diferentes. Ambos llegamos más o menos a la misma solución. Fue interesante ver cómo coincidimos en esta idea.
Resulta que la idea es OneDrive, aunque parezca increíble. Todo el mundo lo tiene. Es un sistema empresarial. Bueno, no todo el mundo, pero una buena parte de las organizaciones tienen acceso a OneDrive o a un equivalente, digamos. Voy a usar OneDrive en esta sesión porque es lo que tengo, pero existen equivalentes.
Las ventajas de esto, sin embargo, son realmente sorprendentes. Gestionar la base de código es similar a JSL, pero ofrece mayor control de versiones, o mayor control de edición, y la capacidad de rastrear el historial y revertir a versiones anteriores del código. Si algo falla, si hay una corrupción en el código o algo similar, podemos revertirlo. Estas capacidades se obtienen al usar los sistemas empresariales de los que hablamos.
Implemente actualizaciones fácilmente. Aquí es donde la teoría se pone en práctica con esta solución. Podemos configurar una estrategia de actualizaciones prácticamente automatizada para toda una empresa. Sin tener que mover un dedo, siendo realistas. Es prácticamente sin código. Hay un par de fragmentos de código que debemos introducir en nuestros complementos, pero más allá de eso, todo es cuestión de apuntar y hacer clic. Es increíblemente fácil de hacer con estos sistemas.
Permisos de control y edición. Estos vienen con los muros. Puedes dar permisos de visualización, edición, descarga o descarga. Puedes dar acceso completo cuando lo necesites y activarlo o desactivarlo según sea necesario. Puedes hacerlo para grupos. Tiene opciones de políticas y cosas así.
De hecho, tiene un sistema de permisos de acceso muy bueno y es fácil de usar para principiantes. Como ya he dicho, requiere muy poco código adicional. Si ya estás desarrollando complementos, sabes todo lo necesario para hacerlo. Es facilísimo de implementar.
¿Cuál es el truco? Bueno, el truco está en darse cuenta de que, cuando JMP instala un complemento, este es básicamente una carpeta que contiene un montón de JSL con un par de archivos especiales que indican a JMP dónde colocarlo en la interfaz gráfica y algunos metadatos sobre el complemento. Pero, en general, es solo una carpeta de archivos JSL que JMP toma y coloca en una ubicación específica que sabe dónde encontrar.
Lo interesante, sin embargo, es que los archivos importantes del complemento pueden estar en cualquier lugar al que JMP acceda. No tienen por qué estar en esa carpeta. Puedes colocarlos donde quieras. Hyde y yo nos dimos cuenta de que ¿qué nos impide colocar los archivos importantes en una carpeta de OneDrive y que luego, con un simple puntero del complemento, se acceda a ellos y se abran en la carpeta de OneDrive?
Resulta que no hay nada que te impida hacerlo. Esto es lo que obtienes al hacerlo. Un par de estas diapositivas, la siguiente y la siguiente, son más bien para referencia más adelante, pero las repasaremos rápidamente para tener una breve explicación de lo que está sucediendo.
En OneDrive en la nube, la carpeta de OneDrive albergará la esencia del complemento. Tendremos la interfaz de usuario y el código del complemento. Así lo planteó Hyde. Mi enfoque se basaba en la idea de colocar recursos, grandes bibliotecas de materiales que ocuparían mucho espacio en el disco duro, y que solo se necesitarían al abrirlos. De lo contrario, no se quiere ocupar espacio en el disco duro. Todo esto puede estar en la carpeta de OneDrive, y ahí es donde se encuentra.
En el escritorio de JMP hay un pequeño script, de unas 20 líneas. La mayor parte lo hace legible para el usuario. Hace tres cosas. Tres cosas específicas. Primero, comprueba si sabe dónde se encuentran los archivos del complemento. ¿Tiene una ubicación? Si no, necesita mostrar un cuadro de diálogo que diga: "¿Dónde debo buscar el complemento?". Luego abre el paquete del complemento. Eso es todo. Esas tres cosas.
El otro elemento que existe en el disco duro del usuario es lo que llamo un espejo de la ubicación de OneDrive. Dependiendo de cómo lo configure, este espejo puede tener solo enlaces lógicos, enlaces a archivos y alias (si sabe cuáles son), o copias de los archivos sincronizados. Ambos métodos tienen sus ventajas y desventajas, y ambos funcionan igual de bien.
Opción uno, donde solo tienes enlaces lógicos. Ventajas: tamaño de archivo muy pequeño. Ocupa poco espacio en el disco duro. Solo son enlaces y extrae los archivos en tiempo de ejecución. Obtienes información precisa y actualizada de los archivos. Desventajas: no funciona sin conexión a internet. Si estás en un avión o algo similar y no tienes acceso a Wi-Fi, es posible que tus complementos no se carguen.
La otra desventaja es que, dependiendo del tamaño del complemento, puede haber un pequeño retraso entre hacer clic en el enlace en JMP y su apertura. Ambas son desventajas. No lo consideraría una desventaja, solo quiero tener en cuenta que, con complementos más grandes, puede haber un ligero retraso.
La segunda opción, que les mostraré hoy, es la carpeta sincronizada. Esta opción ocupa más espacio en el disco duro, pero permite el acceso sin conexión y la carga es... No es instantánea, pero sí mucho más rápida. Si necesita obtener una versión más reciente de un archivo y aún no se ha sincronizado, puede haber un pequeño retraso. La ventaja es que, a medida que se modifican los archivos, se copian automáticamente a su carpeta local.
En ambos casos, aún se mantienen los permisos de control de versiones de lectura y escritura. Si alguien realiza un cambio en su disco duro local, se creará una copia del archivo. No se le permitirá modificar el original, y solo se hará referencia a él. Si alguien modifica algo y comete un error, la próxima vez que se cargue el complemento, se cargará el original. No se cargará el cambio. Contamos con ese control de versiones, ese flujo de trabajo protegido, en cualquier caso.
Ahora, para configurar la ubicación de OneDrive, podemos hacerlo de varias maneras. La forma más sencilla que encontré es a través de Teams. Ahí es donde comenzaremos la demostración de esta sesión de hoy. En Teams, si configuras un equipo, se crea automáticamente el sitio de SharePoint que necesitas. Luego, puedes agregar una carpeta desde Teams y configurar la sincronización desde allí.
Luego, tienes la opción de ir al sitio de SharePoint si lo deseas. Esto es lo que hacen tus usuarios: acceden directamente al sitio de SharePoint y configuran la sincronización. Ahí es donde puedes darles permisos para ver, editar, descargar, etc. Ahí es donde puedes darles permisos sobre el contenido; también puedes controlar el acceso al complemento. Es muy práctico. Veamos cómo hacerlo rápidamente.
Esto es Teams. Tengo Teams. De hecho, estoy en mi grupo de Teams aquí mismo. Entras y hay un botón que suele aparecer, y ahora mismo tengo este pequeño. Hay un botón que dice "Crear un nuevo equipo". Creas un nuevo equipo y el canal. Luego, al entrar en el canal, debajo del canal, hay una opción que dice "Archivos".
Puedes crear un nuevo archivo o una nueva carpeta. Normalmente, creo una carpeta nueva y la llamo "contenido del complemento". Desde aquí, puedo usar los puntos, y tengo opciones para descargar o sincronizar con SharePoint. Quiero abrir SharePoint Drive. Esta es mi SharePoint Drive. Es la misma ubicación. De hecho, estoy dentro de esa carpeta. Este es el contenido del complemento. Este es el núcleo del complemento que les voy a mostrar.
Debajo de estos tres puntos, hay una opción que dice sincronizar. En mi sistema de archivos, se ve un poco diferente en Windows, pero en Mac, crea una ubicación de bibliotecas compartidas y una copia de la carpeta.
Ahora, al realizar cambios en esta carpeta, dado que tengo permisos de edición, al crear cambios en este archivo, cualquier otra persona con acceso recibirá automáticamente copias de esos cambios. Se enviarán al sitio de SharePoint y luego a todos los demás. Aquí es donde empiezo a editar.
Ahora, veamos el archivo rápidamente. Este no es tan importante. Es solo el contenido. Pero veamos cómo se ve uno de estos. Este es el complemento que he creado, y les voy a explicar... No les voy a explicar cómo crear el complemento, ya que solo se usa el Asistente para complementos.
Veamos lo que tenemos aquí. Estas son las partes que no nos interesan demasiado. Son las que JMP necesita conocer. El Lanzador de complementos y las Preferencias de complementos son las dos que nos interesan. Las preferencias de complementos contienen una carpeta o archivo. Voy a dejarlo sin seleccionar porque lo borré cuando lo probé el otro día.
Así es como debería verse por defecto. Lo que ocurrirá en este script de shell es que me preguntará: "¿Dónde está el contenido del complemento?". Cuando lo sepa, lo escribirá en este script de preferencias, para que no tenga que preguntarme cada vez que ejecute el complemento. Solo me preguntará una vez y lo recordará.
Veamos... Voy a compartir este script de shell rápidamente. Dejemos el blog. Hay tres fragmentos de código muy cortos. No hay mucho que ver. Hay un diálogo para preguntar dónde se encuentra el JSL de este complemento. Intenta abrir las preferencias. Luego hay un bucle que intenta abrir el código o preguntarme dónde está. Eso es todo lo que veremos.
He creado este complemento y lo he guardado en mi carpeta de complementos. Si llego a JMP y digo "demo", me dirá: "Oye...". No lo veo aquí abajo, pero dice: "Selecciona tu directorio para el inicio de la formación". Bueno, para este complemento. Olvidé cambiar ese texto. Solo voy a entrar y decir: "Aquí está mi unidad compartida y aquí está mi carpeta". Voy a decir: "Abrir". El complemento se inició desde OneDrive.
Lo que puedo hacer es volver aquí, abrir este complemento y ver un texto diferente para este archivo. He añadido el complemento. Voy a ejecutarlo de nuevo. Ahora se muestra el nuevo texto aquí abajo. Para que se hagan una idea de lo complejo que puede ser, quiero mostrarles rápidamente dos complementos que aprovechan esta función. No voy a entrar en detalles. Para terminar, quiero terminar con esto.
El primero es el que creé, llamado JMP on the Spot. Este usa el concepto que hoy abordamos para extraer contenido para un navegador web, un visor. Probablemente, un repositorio o una biblioteca sea una mejor descripción. Si accedemos a JMP on the Spot, todo este contenido existe únicamente en la nube. Si quiero abrirlo, se descargará en tiempo real.
Otra opción es la que usamos, como ingenieros de sistemas, para administrar nuestros materiales cuando estamos aprendiendo una nueva versión, lo cual es muy apropiado para JMP 19. Pero aquí es donde se almacenan nuestros materiales. Se utiliza este mismo complemento. Esta interfaz gráfica de usuario y todo lo relacionado con ella reside en una ubicación de OneDrive.
Si lo revisáramos, de hecho, lo tengo aquí mismo. Lo único que existe en el complemento en mi disco duro es el archivo de preferencias que ya vimos, y de hecho, es el mismo archivo que les mostré para el ejemplo de demostración. Todo lo demás es en tiempo real. Lo bajé a mi disco duro mientras el equipo lo editaba.
A medida que subimos nuestros materiales para JMP 19 y JMP 18, se suben a OneDrive y se descargan automáticamente a mi equipo. No tengo que preocuparme por actualizar mis complementos, los videos ni nada; el contenido tan extenso que tenemos a veces, cuando recibimos capacitación, está en la nube; no lo descargo. No tengo que hacerlo. No ocupo espacio en mi disco duro para hacerlo.
¿Qué vimos hoy? Vimos que OneDrive nos permite administrar la base de código, implementar actualizaciones fácilmente, controlar el acceso y los permisos, y es fácil de usar para principiantes. Se requiere muy poca codificación adicional, salvo que, si escribes tu propio JSL, ya sabes todo lo necesario para hacerlo. Solo necesitas recordar un pequeño truco: no hay ninguna regla que indique que el complemento deba residir en el repositorio de complementos.
