Una delle sfide più grandi che incontriamo quando iniziamo a far crescere JMP all'interno di un'organizzazione è che le persone iniziano a imparare a usare JSL, e iniziamo a vedere questa proliferazione di codice JSL all'interno dell'organizzazione. Una delle sfide più grandi che inizia a presentarsi con l'adozione di JMP su larga scala all'interno di un'azienda è la questione di come gestire tutto il codice generato dagli utenti su larga scala. Come controlliamo tutto questo materiale?
Nel corso degli anni, sono stati proposti molti metodi diversi per farlo. Alcuni provengono dal campo dell'informatica e dello sviluppo software, come i sistemi di controllo delle versioni. Altri propongono di usare semplicemente un'unità condivisa da qualche parte. A quanto pare, entrambe le soluzioni hanno i loro pro e contro.
Per darvi un po' di luce in fondo al tunnel, in realtà c'è una via di mezzo che funziona abbastanza bene per questo, non proprio... Non voglio dedicare tutte le risorse allo sviluppo di una vera e propria società di sviluppo software interna per gestire la parte di gestione del software. Non voglio gestire il Far West, che è solo un'unità condivisa sul server di qualcuno.
Ma a quanto pare questi due estremi hanno i loro pro e contro. Quando si parla di Git o di un sistema di controllo di versione, GitHub è solitamente quello che la gente conosce meglio. Gestire basi di codice? È esattamente ciò che fa davvero bene. È un ottimo strumento.
Distribuire facilmente gli aggiornamenti? Non è questo il suo obiettivo. Non è quello per cui è stato progettato. È progettato per flussi di lavoro di sviluppo software professionali, e non è di questo che stiamo parlando. Non lo fa particolarmente bene.
Controllare l'accesso e i permessi di versione, ovviamente, lo fa piuttosto bene. Mantenere il controllo delle versioni, sapere come vengono tracciate le modifiche nel tempo, tutte queste cose sono esattamente ciò per cui sono progettati i sistemi di controllo delle versioni. Per questo motivo, non è adatto ai principianti. È progettato per i professionisti.
Ho visto esempi di utilizzo di questa tecnologia in giro, ma di solito si tratta di organizzazioni che hanno dedicato personale, risorse e tempo alla creazione di un gruppo dedicato allo sviluppo software all'interno dell'azienda. Questo può funzionare in determinate situazioni, oppure potrebbe già essere disponibile per altri motivi.
All'estremo opposto, l'idea di utilizzare solo file JSL e una cartella condivisa, una directory condivisa su un server. È quasi lo specchio dei problemi del sistema di controllo delle versioni. Gestire la base di codice, non è il massimo. Sta migliorando con alcuni di questi sistemi cloud, ma non è ancora un granché.
Distribuire facilmente gli aggiornamenti? Certo. Basta cliccare sull'ultimo aggiornamento. Magari inviare un'e-mail o qualcosa del genere, oppure utilizzare alcuni dei componenti aggiuntivi, parte del codice proposto nel tempo per facilitare questo particolare flusso di lavoro, che è possibile aggiungere ai componenti aggiuntivi. Sicuramente una possibilità, ma non banale. Meglio del sistema di controllo delle versioni da questo punto di vista.
Controllo degli accessi? Non è un granché, a dire il vero. Adatto ai principianti? Sì. Non è male, ma nemmeno superlativo. A quanto pare, esiste una via di mezzo. Io e il mio collega, il mio coautore e io, in realtà siamo arrivati a questo risultato da due attività di sviluppo diverse. Siamo entrambi approdati più o meno alla stessa soluzione. È stato interessante vedere come ci siamo trovati a metà strada su questa idea.
A quanto pare l'idea è OneDrive, che ci crediate o no. Ce l'hanno tutti. È un sistema aziendale. Beh, non tutti, ma una buona parte delle organizzazioni ha accesso a OneDrive o a un equivalente, diciamo. Userò OneDrive per questa sessione perché è quello che ho, ma esistono degli equivalenti.
I vantaggi di questo approccio, però, sono davvero sorprendenti. Gestire la base di codice è simile a JSL, ma si ha un maggiore controllo di versione, ovvero abbiamo un maggiore controllo sulle modifiche, e abbiamo la possibilità di tracciare la cronologia e ripristinare le versioni precedenti del codice. Se qualcosa va storto, se il codice è corrotto o qualcosa del genere, possiamo ripristinare le versioni precedenti. Queste funzionalità le otteniamo utilizzando i sistemi aziendali di cui stiamo parlando.
Distribuisci facilmente gli aggiornamenti. È qui che entra in gioco questa soluzione. Possiamo impostare una strategia di aggiornamento più o meno automatizzata per un'intera azienda. Senza dover alzare un dito, realisticamente. È praticamente senza codice. Ci sono un paio di bit di codice che dobbiamo inserire nei nostri componenti aggiuntivi, ma a parte questo, è tutto punta e clicca. È incredibilmente facile da fare con questi sistemi.
Autorizzazioni di controllo e modifica. Anche in questo caso, queste sono incluse nei muri. Puoi dare alle persone autorizzazioni di visualizzazione e modifica, puoi dare alle persone autorizzazioni di download e modifica. Puoi dare alle persone l'accesso completo quando ne hai bisogno e puoi attivarlo e disattivarlo a seconda delle necessità. Puoi farlo per i gruppi. Ci sono opzioni di policy, cose del genere.
Ha un ottimo sistema di permessi di accesso ed è adatto anche ai principianti. Come ho detto, richiede pochissima programmazione aggiuntiva. Se stai già scrivendo componenti aggiuntivi, sai già tutto ciò che ti serve per farlo. È semplicissimo da implementare.
Qual è il trucco? Beh, il trucco arriva quando ci si rende conto che quando JMP installa un componente aggiuntivo, questo è fondamentalmente solo una cartella che contiene un po' di JSL con un paio di file speciali che indicano a JMP dove posizionarlo nell'interfaccia utente grafica e alcuni metadati sul componente aggiuntivo. Ma per la maggior parte, si tratta solo di una cartella di file JSL che JMP prende e poi inserisce in una posizione specifica che sa dove trovare.
La cosa interessante, però, è che i file importanti per il componente aggiuntivo possono essere ovunque a cui JMP acceda. Non devono necessariamente trovarsi in quella cartella. Puoi metterli dove vuoi. La cosa che Hyde e io abbiamo capito è: cosa ci impedisce di mettere i file importanti in una cartella OneDrive e poi di usare semplicemente un puntatore dal componente aggiuntivo per andare a quei file importanti e aprirli nella cartella OneDrive?
A quanto pare non c'è niente. Non c'è niente che ti impedisca di farlo. Questo è ciò che ottieni quando lo fai. Un paio di queste diapositive e la diapositiva successiva sono più utili per riferimento più avanti, ma le esamineremo molto velocemente solo per avere un po' di narrazione su cosa sta succedendo qui.
In OneDrive sul cloud, nella cartella OneDrive, ci sarà il cuore del componente aggiuntivo. Avremo l'interfaccia utente, il codice del componente aggiuntivo. Hyde l'ha affrontata così. Io l'ho affrontata partendo dall'idea di inserire risorse, grandi librerie di materiali che avrebbero occupato molto spazio sul disco rigido di qualcuno, e che avrebbero dovuto essere scaricate solo al momento di aprirle. Altrimenti, non avrebbero voluto occupare spazio sul disco rigido. Tutto questo materiale può essere presente nella cartella OneDrive, ed è lì che risiede.
Sul desktop JMP c'è un piccolo script, forse 20 righe. Il suo scopo principale è renderlo leggibile all'utente. Fa tre cose. Tre cose specifiche. Primo, verifica se sa dove si trovano i file dei componenti aggiuntivi. Ha una posizione? In caso contrario, deve visualizzare una finestra di dialogo che chiede: "Ehi, dove dovrei cercare il componente aggiuntivo?". Quindi, apre il pacchetto del componente aggiuntivo. Questo è tutto. Queste tre cose.
L'altra cosa presente sul disco rigido dell'utente è quello che chiamo un mirror della posizione di OneDrive. Ora, questo mirror, a seconda di come lo si imposta, può avere solo collegamenti logici, solo link a file, alias, se si sa cosa sono, oppure copie dei file effettivi sincronizzati. Entrambe le soluzioni presentano pro e contro, ed entrambe funzionano ugualmente bene.
Opzione uno, in cui si hanno solo collegamenti logici. Pro: dimensioni del file molto ridotte. Occupa poco spazio sul disco rigido. Si tratta solo di collegamenti, e estrae i file in fase di esecuzione. Si ottengono informazioni sui file accurate e aggiornate al minuto. Contro: non funziona quando non si è connessi a Internet. Se ci si trova su un aereo o in un luogo simile e non si dispone di una connessione Wi-Fi, i componenti aggiuntivi potrebbero non caricarsi affatto.
L'altro svantaggio è che, a seconda delle dimensioni del componente aggiuntivo, potrebbe verificarsi un leggero ritardo tra il clic sul collegamento in JMP e l'apertura del componente aggiuntivo. Entrambi sono svantaggi. Non lo definirei un vero svantaggio, ma è importante sapere che per i componenti aggiuntivi più grandi potrebbe verificarsi un leggero ritardo.
La seconda opzione, che è quella che vi mostrerò oggi, è l'opzione della cartella sincronizzata. Questa opzione occupa più spazio sul disco rigido, ma consente l'accesso offline e il caricamento è... Non è istantaneo, ma è decisamente più veloce. Se deve recuperare una versione più recente di un file e non è ancora sincronizzato, potrebbe verificarsi un leggero ritardo. Ma il vantaggio è che, man mano che i file vengono modificati, vengono automaticamente copiati nella cartella locale.
In entrambi i casi, i permessi di controllo di versione in lettura/scrittura sono ancora attivi. Se qualcuno apporta una modifica al proprio disco rigido locale, verrà creata una copia del file. Non gli sarà consentito di modificare l'originale e farà riferimento solo a quest'ultimo. Se qualcuno modifica qualcosa e commette un errore, la prossima volta che il componente aggiuntivo verrà caricato, caricherà l'originale. Non caricherà la sua modifica. Abbiamo quel controllo di versione, quel flusso di lavoro protetto, sempre attivo.
Ora, per configurare la posizione OneDrive, possiamo farlo in diversi modi. Il modo più semplice che ho trovato è tramite Teams. È proprio lì che inizieremo la parte dimostrativa di questa sessione odierna. In Teams, se si configura un team, viene creato automaticamente il sito di SharePoint necessario. Quindi è possibile aggiungere una cartella da Teams e configurare la sincronizzazione da lì.
Poi hai la possibilità di andare al sito di SharePoint, se vuoi. Questo è ciò che fanno i tuoi utenti. Accedono direttamente al sito di SharePoint e configurano la sincronizzazione. È lì che puoi concedere loro le autorizzazioni per visualizzare, modificare, scaricare, ecc. È lì che puoi concedere loro le autorizzazioni per i contenuti; in realtà hai anche il controllo degli accessi al componente aggiuntivo. È comodo. Vediamo velocemente come farlo.
Questo è Teams. Ho Teams. In realtà sono nel mio gruppo Teams proprio qui. Ci entri e di solito c'è un pulsante che si vede, e al momento ho questo piccolo. C'è un pulsante che dice "Crea un nuovo team". Crei un nuovo team e crei il canale. Poi, quando entri nel canale, sotto il canale, c'è un'opzione che dice "File".
Puoi creare un nuovo file o una nuova cartella. Di solito, creo una nuova cartella e la chiamo "Contenuto del componente aggiuntivo". Da qui, posso usare i miei puntini e ho le opzioni per scaricare o sincronizzare con SharePoint. Voglio aprire il mio SharePoint Drive. Questo è il mio SharePoint Drive. È la stessa posizione. Mi trovo effettivamente all'interno di quella cartella. Questo è il contenuto del componente aggiuntivo. Questo è il nocciolo del mio componente aggiuntivo che ora vi mostrerò.
Sotto questi tre puntini, c'è un'opzione che dice "Sincronizza". Quello che fa nel mio file system... Su Windows ha un aspetto leggermente diverso, ma sul Mac, quello che fa nel mio file system è creare una posizione di librerie condivise e crea una copia della cartella qui.
Ora, quando apporto modifiche a questa cartella, poiché ho i permessi di modifica, chiunque altro abbia accesso a questo file riceverà automaticamente una copia delle modifiche. Verranno inviate al sito di SharePoint e poi a tutti gli altri. È qui che inizio a modificare.
Ora, diamo un'occhiata veloce al file. Questo non è poi così importante. È solo il contenuto. Ma diamo un'occhiata a uno di questi file. Questo è il componente aggiuntivo che ho creato e vi spiegherò... Non vi spiegherò come creare il componente aggiuntivo perché si tratta semplicemente di usare la procedura guidata.
Diamo un'occhiata a cosa abbiamo qui. Queste sono le parti che non ci interessano molto. Sono le cose che JMP deve sapere. Il Launcher del componente aggiuntivo e le Preferenze del componente aggiuntivo sono le due che ci interessano. Le preferenze del componente aggiuntivo contengono una cartella o un file. Lo inserirò qui deselezionato perché è stato eliminato durante il test l'altro giorno.
Questo è il modo in cui dovrebbe apparire di default. Quello che succederà in questo script shell è che mi chiederà: "Ehi, dov'è il contenuto del componente aggiuntivo per questo componente aggiuntivo?". Quando lo saprà, lo scriverà in questo script delle preferenze, così non dovrò chiedermelo ogni volta che eseguo il componente aggiuntivo. Me lo chiederà solo una volta e se lo ricorderà.
Diamo un'occhiata a questo script shell che condividerò molto velocemente. Svuotiamo il blog. Ci sono tre, ancora una volta, brevissimi frammenti di codice. Non c'è molto da guardare. C'è una finestra di dialogo che chiede dove si trova effettivamente il JSL per questo componente aggiuntivo. Prova ad aprire le preferenze. Poi c'è un ciclo che cerca di aprire il codice o mi chiede dove si trova. Questo è tutto ciò che stiamo esaminando qui.
Ho creato questo componente aggiuntivo e l'ho inserito nella mia cartella dei componenti aggiuntivi. Se apro JMP e dico demo, mi risponderà, ehi... Non lo vedi qui sotto, ma dice: "Seleziona la tua directory per il training starter". Beh, per questo componente aggiuntivo. Ho dimenticato di modificare quel testo. Tutto quello che farò è entrare e dire: "Ecco la mia unità condivisa, ed ecco dove si trova la mia cartella". Dirò: "Ok, apri". Il componente aggiuntivo è stato avviato dalla posizione OneDrive.
Quello che posso fare è tornare qui, riaprire questo tizio e vedere che ho un testo diverso per questo file del componente aggiuntivo. Sono entrato e ho aggiunto il componente aggiuntivo stesso. Ora eseguo di nuovo il componente aggiuntivo. Ora mostra il nuovo testo qui in basso. Per darvi un'idea di quanto possa essere complesso, ci sono due diversi componenti aggiuntivi che voglio mostrarvi molto velocemente, entrambi sfruttano questa funzionalità. Non entrerò nei dettagli. Lasciatemi concludere. Questo è ciò che voglio.
Il primo è quello che ho creato, chiamato JMP on the Spot. In realtà, utilizza il concetto di cui stiamo parlando oggi per estrarre il contenuto da un browser web, un visualizzatore. Un repository o una libreria sono probabilmente i termini più adatti per descriverlo. Se apriamo JMP on the Spot, tutto il contenuto presente qui esiste solo sul cloud. Se voglio aprirlo, verrà scaricato in tempo reale.
Un'altra opzione è quella che noi, come SE, utilizziamo per gestire i nostri materiali quando impariamo una nuova release, il che è davvero appropriato per JMP 19. Ma è qui che vengono archiviati i nostri materiali. Si utilizza proprio questo componente aggiuntivo. Questa GUI e tutto ciò che vi è associato si trovano su OneDrive.
Se dovessimo andare a dare un'occhiata, in effetti, ce l'ho proprio qui. Questo è tutto ciò che esiste nel componente aggiuntivo vero e proprio sul mio disco rigido: il file delle preferenze che abbiamo già visto, e in realtà lo stesso file che vi ho mostrato per l'esempio demo. Tutto il resto è in tempo reale. L'ho scaricato sul mio disco rigido mentre veniva modificato dal team.
Man mano che i nostri materiali per JMP 19 e JMP 18 vengono caricati, vengono caricati su OneDrive e automaticamente scaricati sul mio computer. Non devo preoccuparmi di aggiornare i miei componenti aggiuntivi, i video e altro, i contenuti più corposi che a volte abbiamo durante la formazione. Risiedono nel cloud, non li scarico. Non devo farlo. Non occupo spazio sul mio disco rigido per farlo.
Cosa abbiamo visto oggi? Beh, abbiamo visto che OneDrive ci offre la possibilità di gestire la base di codice, di distribuire facilmente gli aggiornamenti, di controllare gli accessi e le autorizzazioni, ed è intuitivo per i principianti: richiede pochissima programmazione aggiuntiva, a parte il fatto che se state scrivendo il vostro codice JSL, sapete già tutto ciò che vi serve per farlo. Tutto ciò che dovete fare è ricordare un piccolo trucco: non esiste una regola che imponga che il componente aggiuntivo debba risiedere nel repository dei componenti aggiuntivi.
