| Oratore |
Trascrizione |
| Serkay Olmez |
Ciao, sono Serkay e Fred di Seagate e oggi parleremo di come abbiamo creato un ecosistema JSL per gestire i nostri script JSL. |
| |
Stiamo usando Git per gestire i controlli del codice sorgente, il codice sorgente dei nostri script JSL, e anche per distribuirli. Questo sarà il punto principale della conferenza di oggi. |
| |
Ma oltre a questo, parlerò anche dell'integrazione di VBA con PowerPoint e della raccolta dei crash log, oltre che dei test unitari. Passerò rapidamente al sommario. |
| |
Quindi, quello di cui vorrei parlare prima è la nostra storia con JSL. Scrivo in JSL da circa 10 anni. |
| |
Siamo molto contenti di dove siamo ora, ma ci è voluto un po' di tempo per arrivare fin qui e vorrei parlare delle tappe fondamentali della nostra esperienza, di cosa abbiamo fatto finora e perché lo abbiamo fatto. |
| |
E poi parleremo di Git e di come lo abbiamo abilitato per il controllo del codice sorgente dei nostri script JSL e di come ci ha permesso di sviluppare ulteriori funzionalità. Ad esempio, una volta abilitato Git, |
| |
Puoi aggiungere altre funzionalità, come il monitoraggio degli script. In questo modo, gli sviluppatori possono sapere quando i loro script sono in uso e monitorarne l'utilizzo. |
| |
E, cosa probabilmente ancora più importante, possono anche raccogliere i log. Se lo script si blocca, lo sviluppatore lo sa e può tornare indietro e correggere i bug. E tu puoi... |
| |
Puoi aggiungere un'ulteriore funzionalità, andando ancora oltre. Puoi persino creare ticket di bug automatizzati se sai già che il tuo script si è bloccato. In questo modo, puoi creare automaticamente un ticket di bug per questo problema. E puoi monitorare questi ticket utilizzando un software di monitoraggio come JIRA o Atlassian. |
| |
E concluderò con le nostre migliori pratiche e le lezioni apprese finora. |
| |
COSÌ, |
| |
E in appendice ho anche il manuale di uno script di cui parlerò. È uno script che può caricare immagini su PowerPoint. |
| |
Ho un manuale molto dettagliato a riguardo e vorrei solo farti sapere che tutto ciò di cui parlo qui, i dati e gli script, saranno disponibili. |
| |
E sono pubblicati in un repository pubblico nella sezione riferimenti qui e puoi semplicemente andare lì e prendere quei file se scegli di farlo. Quindi lasciami iniziare con |
| |
con la breve storia qui. Quindi 10... Ho lavorato con JSL per circa 10 anni o giù di lì, e ho iniziato, ho iniziato con |
| |
nozioni molto basilari e non sapevo molto di scripting JSL. |
| |
E poi, una volta che inizi a farlo, ti rendi conto che devi avere un controllo del codice sorgente adeguato e che hai bisogno di metodi adeguati per distribuire i tuoi script. |
| |
Il bello dello scripting JMP è che non presenta alcuna barriera d'accesso. Puoi letteralmente creare un grafico manualmente e poi scaricare lo script. È scritto per te. |
| |
Puoi anche utilizzare Community to JMP su JMP.com per porre domande e ottenere risposte. |
| |
E tu... la sceneggiatura è così efficiente che stai facendo il tuo lavoro in modo così efficiente che la gente se ne accorgerà. Ti chiederanno come fai le cose e tu dirai: "Ho una sceneggiatura per quello". E loro... |
| |
chiedi: "Puoi condividerlo con me?" E all'improvviso diventi uno sviluppatore, anche se non avevi intenzione di diventarlo. |
| |
E poi devi occuparti della distribuzione dei tuoi script. La prima idea che mi viene in mente è semplicemente di allegarli, il che è un'idea orribile, e io l'ho fatto per un bel po'. |
| |
Ed è abbastanza ovvio perché non è una buona idea, perché alleghi uno script e poi lo invii e poi il giorno dopo ne fai uno |
| |
revisione e poi devi inviarla di nuovo, e non sai nemmeno se l'utente accetterà la prossima. Quindi sto solo illustrando il concetto. |
| |
Di recente ho ricevuto un'e-mail da un collega che faceva riferimento a uno script che ho creato nel 2017 e stavo semplicemente numerando i miei script con questi |
| |
Numeri di versione, il che non è una buona idea. Quindi, dopo tre o quattro anni, ci si rende conto che la gente usa ancora script vecchi di tre anni, perché non sono stati aggiornati. |
| |
Un modo per risolvere questo problema è quello di utilizzare un'unità condivisa e, in base all'interazione che ho avuto con le persone in esse presenti, |
| |
Discovery Summits è un'iniziativa che molte persone e aziende stanno utilizzando. Quindi, ciò che fanno gli sviluppatori è |
| |
Scarica i tuoi script su un'unità condivisa e gli utenti li estrarranno direttamente da lì, il che risolve metà del problema di distribuzione, ma non fa nulla per il controllo del codice sorgente. Non... non puoi tracciare le modifiche apportate al codice. |
| |
Ed è per questo che siamo passati a Git. È stata una svolta per noi e ha permesso di implementare molte funzionalità. Quindi, cosa si fa con Git? Gli sviluppatori caricano i loro script in un repository e... |
| |
gli utenti estrarranno i loro script direttamente da Git. Questo è stato un grande miglioramento per noi e ci ha permesso di raccogliere i registri degli arresti anomali e |
| |
Utilizzo degli script, ecc. E vorrei anche parlare di un paio di altre cose che ho imparato dai Summit. Sono stati molto utili per migliorare le mie capacità di scripting. Ho partecipato a un summit nel 2018 e ho imparato parecchio sulle espressioni, ecc. Quindi |
| |
le persone potrebbero voler tornare ad ascoltare quelle presentazioni, perché aiutano con le capacità di sceneggiatura. |
| |
Un altro traguardo importante per noi è stato il testing. Sono stato ispirato da questo intervento al Summit dell'anno scorso, che parlava di unit testing, che consente di testare automaticamente gli script prima di pubblicarli. |
| |
Oggi parlerò principalmente di test di integrazione perché i test unitari sono... necessari, ma non sufficienti. |
| |
Poiché è possibile eseguire un test unitario, è possibile testare tutti i moduli e tutti funzionano correttamente. Ma quando li si assembla, non funzioneranno. Si bloccheranno, come illustrato qui. Ogni cassetto viene testato, probabilmente, ma quando li si assembla, non funzioneranno. |
| |
Una caratteristica interessante che aiuta parecchio lo sviluppatore riguarda la raccolta dei log. |
| |
È davvero utile sapere che il tuo script si è bloccato e, soprattutto, come si è bloccato. Puoi farlo raccogliendo i log degli utenti, così puoi tornare indietro e correggere lo script, inviando le modifiche e gli utenti avranno subito il loro script corretto. |
| |
E l'ultima funzionalità che stiamo lanciando di recente riguarda la segnalazione automatica dei bug. Dato che avete già il rapporto sugli arresti anomali, perché non intervenire su queste informazioni? E così creiamo un sistema automatico |
| |
monitoraggio |
| |
sistema, che terrà traccia dei log degli arresti anomali e creerà automaticamente segnalazioni di bug in modo che lo sviluppatore possa lavorarci sopra. Inoltre, è possibile aggiungere l'utente come osservatore in modo che sappia che qualcuno sta lavorando al problema. Ecco, questo risolve il problema. |
| |
che risolve il divario informativo tra utente e sviluppatore. |
| |
Quindi questo mostra la cronologia e dedicherò un po' di tempo a questo |
| |
sui singoli elementi, ma inizieremo con Git e lo compilerò rapidamente e lascerò che Fred ne parli. |
| 163084 |
Va bene. |
| |
COSÌ, |
| |
Git è solo un sistema di controllo di versione, e non uso la parola "controllo di versione". In realtà, voglio dire che Git ti aiuta offrendoti, di fatto, possibilità di redo illimitate, anche se usi Git solo sul tuo computer locale. |
| |
ti dà la possibilità di tenere traccia delle revisioni dei tuoi file e di tornare a quelli vecchi, nel caso in cui decidessi che un lavoro svolto nelle ultime settimane era errato e volessi tornare a qualcosa di diverse settimane fa. |
| |
Quindi Git è semplicemente un software che si installa sul computer locale. Crea un repository, che può poi essere condiviso con altri repository. |
| |
Come GitLab o GitHub. TortoiseGit è un'interfaccia grafica utente (GUI) da usare sul computer locale che semplifica le cose. Quindi, Serkay, potresti aprire la prossima diapositiva? |
| |
Quindi il modello che ho cercato di far usare agli sviluppatori è sul loro computer locale. Gli sviluppatori in locale devono installare il client Git e iniziare |
| |
controllando la versione dei file sul loro PC locale. Una volta che avranno preso l'abitudine, potremo collegarli a un repository remoto. |
| |
e Git si connette a repository remoti o SSH in generale o altri metodi e possono inviare |
| |
copie del loro database Git sul repository remoto. Una volta caricato sul repository remoto, è disponibile per la condivisione tramite un server web HTTP e JMP. |
| |
Possiamo quindi puntare agli URL e al server web HTTP...HTTP e caricare gli script da esso. Quindi, invece di utilizzare un'unità condivisa, utilizziamo un server web HTTP popolato tramite push su un repository Git. |
| |
E poi i punti elenco qui sotto evidenziano semplicemente i vantaggi di tutto questo e come funziona esattamente. |
| |
Possiamo passare alla diapositiva successiva. |
| Serkay Olmez |
Quindi prenderò il controllo qui, Fred, e ti mostrerò... ti mostrerò un'implementazione di illustrazione molto elementare, e gli script sono disponibili nei Riferimenti. |
| |
COSÌ, |
| |
Questo sarà un codice molto semplice. E quello che mostro qui è il codice che lo sviluppatore sta sviluppando. È il minimo indispensabile, giusto? È solo una finestra di dialogo che dice: "Ciao mondo". |
| |
E supponiamo che lo sviluppatore voglia passare questo codice agli utenti. Quindi, invece di fornire questo codice, ciò che lo sviluppatore passa è questo codice, |
| |
che è un collegamento al repository. Quindi questo è il repository dello script JSL hello che si trova lì... |
| |
nel repository remoto. Ciò che fa l'utente è semplicemente afferrare... l'utente afferra il |
| |
script dall'URL. Quindi questo è codice statico. Non necessita di alcuna modifica, quindi lo sviluppatore può modificare lo script quando vuole, ma l'utente non deve fare nulla. E qui vi mostrerò solo un'illustrazione e vorrei solo andare a schermo intero. |
| |
Illustra semplicemente come funziona questa cosa con una particolare interfaccia grafica, ovvero GitHub Desktop. Quindi quello che devi fare è installare questo |
| |
software sul tuo computer e crea un repository locale, che terrà traccia delle modifiche che hai apportato. Ad esempio, in questo caso, ho appena creato questo script JSL hello. |
| |
e questo software saprà che c'è una modifica e la evidenzierà automaticamente. Quello che devi fare è prima di tutto inviarla al tuo repository locale, |
| |
che invia questi dati al tuo repository locale e poi li invierai al repository di origine, che è un repository remoto. Ora li invierò al repository remoto, che li renderà disponibili agli utenti. |
| |
Quindi, una volta fatto questo, gli utenti potranno estrarre questo nuovo codice. E ora torno al ruolo utente e questo è lo script, l'utente lo esegue, e quando... una volta fatto questo, apparirà la finestra di dialogo. Quindi stai eseguendo lo script che hai estratto dal repository. |
| |
Quindi spiegherò...spiegherò tutto questo un po' meglio con un codice più avanzato, che sarà anch'esso correlato a PowerPoint. |
| |
Quindi le persone eseguono molte analisi in JMP e molte persone, alla fine, vogliono comunque trasferire i loro risultati in PowerPoint. So che JMP ha alcune funzionalità per trasferire |
| |
immagini direttamente in PowerPoint, ma volevamo qualcosa di più...qualcosa di un po' più sofisticato. Vogliamo |
| |
Gestire il modello di PowerPoint. Vogliamo fare altre cose all'interno di PowerPoint, decidere quante immagini vogliamo inserire per diapositiva, ecc. E |
| |
Per fare ciò, devi prima connettere JMP con PowerPoint e puoi farlo davvero molto... |
| |
In un modo molto efficace, senza nemmeno dover uscire da JMP. Quello che puoi fare è individuare dove si trova il file eseguibile di PowerPoint, che in genere si trova in Programmi. |
| |
Quindi si crea un file batch che attiverà questo eseguibile di PowerPoint, che andrà a prendere il file PowerPoint che si desidera eseguire e lo eseguirà. Quindi è possibile fare tutto questo in JMP. In pratica, JMP cerca il file eseguibile di PowerPoint. |
| |
E una volta individuato, lo raggruppa in questo file batch. E include anche il percorso del PowerPoint che si desidera eseguire. |
| |
e la macro e quindi PowerPoint avrà una macro al suo interno per eseguire la gestione all'interno di PowerPoint. Quindi ecco come |
| |
Collegare JMP a PowerPoint e dovrai anche lasciare che JMP lo faccia. Ma la domanda è: come fai a far arrivare questo file PowerPoint ai tuoi utenti, per cominciare? Potresti |
| |
Chiedetegli di scaricarlo, il che non è l'ideale perché volete gestirlo automaticamente e allo stesso tempo volete anche controllare il codice sorgente del vostro PowerPoint. Quindi deve essere un buon candidato; deve essere una parte integrante dell'intero ecosistema. Non volete metterlo all'esterno. |
| |
Un altro requisito è che non si voglia scaricare PowerPoint ogni volta che si esegue lo script. Quindi, è consigliabile scaricare PowerPoint solo se sono state apportate modifiche al repository di immagini o se è stato aggiunto qualcosa di nuovo a PowerPoint. |
| |
Quindi, un modo per farlo è usare questo piccolo script JMP, un comando JMP che è la data di creazione. Quello che sto facendo qui è controllare |
| |
la data del file locale. Quindi, se il PowerPoint locale è più vecchio di quello che ho nel repository, allora andrò a scaricarlo. Quindi |
| |
andrà a scaricare PowerPoint tramite richiesta HTTP e |
| |
Sembra più o meno così. Quindi quello che devi fare è controllare il tuo PowerPoint sul tuo computer locale. Se non esiste, puoi semplicemente recuperarlo dal repository tramite una richiesta HTTP. Se esiste, puoi controllare la sua data, e se è vecchio, puoi comunque andare e |
| |
estrai quello nuovo. Quindi, il punto è che puoi integrare PowerPoint senza problemi nell'ambiente JMP, in modo da poter caricare i tuoi risultati in JMP, comprese tabelle e immagini. E puoi fare tutto questo senza interrompere il controllo del codice sorgente, come ti mostrerò qui. |
| |
Quindi questo sarà il codice che, ad esempio, forniresti ai tuoi utenti. Di nuovo, si tratta di codice statico. Non contiene nulla, a parte un URL che collega lo script al repository remoto. Quindi andrà a prendere il |
| |
Script JMP dal repository; tali script sono di nuovo disponibili e puoi semplicemente estrarli dai Riferimenti. |
| |
Dal, dal, dal lato dello sviluppatore, questo è lo script vero e proprio, giusto. Questo è lo script, lo sviluppatore ha sviluppato e |
| |
Lui o lei lo invia al repository remoto. E la cosa bella di questo script è che vorrei solo sottolineare rapidamente un paio di funzionalità. |
| |
Quindi, se, ad esempio, guarda questo. Questo è uno script di testo autonomo e non devi distribuire file PowerPoint o script aggiuntivi |
| |
separatamente. Quello che fai è collegarli nel tuo script e sono collegati nel repository qui, |
| |
incluso il PowerPoint. Quindi questo script gestirà tutta la distribuzione. Quindi, andrà a prendere il PowerPoint. |
| |
Se necessario, recupererà altri file aggiuntivi. Quindi tutto è raggruppato nello script, quindi si occupa di tutta la gestione per te. Lasciate che ve lo mostri velocemente. Lo riporterò indietro. |
| |
e metterlo a schermo intero |
| |
così puoi vedere chiaramente. Questa sarà una dimostrazione di come attivare PowerPoint automaticamente |
| |
per un caso particolare. E quello che fa questo script è ottenere i percorsi dalla tabella, questa è una tabella JMP che include molti percorsi di immagini, e questi si riferiscono a questo particolare |
| |
server, e prenderà quei percorsi e prenderà solo quelli evidenziati qui e li inserirà in PowerPoint. |
| |
Lo eseguirò e questo script è a tua disposizione se vuoi provarlo. Ed è uno script utile e completamente funzionante. Quindi, sto eseguendo questo. |
| |
script qui. Di nuovo, si riferisce al repository. Quindi non ha lo script di riga, lo sta semplicemente estraendo dal repository. Lo esegui, recupera il codice, apre una finestra di dialogo. |
| |
E lo farò semplicemente. Non entrerò nei dettagli e, una volta eseguito, PowerPoint verrà avviato automaticamente. |
| |
PowerPoint si avvierà e poi... inizierà... creerà le diapositive qui. Estrarrà 20 immagini e ci vorranno 10 o 20 secondi e poi avrai PowerPoint. |
| |
fatto. Quindi questo è il PowerPoint che ottieni e tutto viene fatto automaticamente e tutto è stato estratto dal repository. |
| |
Quindi, cosa succederà ora? Come modificheresti questa presentazione PowerPoint? Immagino che tu voglia apportare alcune modifiche al tuo modello. E |
| |
puoi vedere maggiori dettagli a riguardo nell'appendice, ma quello che voglio mostrare è come si modifica il |
| |
script in PowerPoint. E andrò a schermo intero, |
| |
E lo farò. Partiamo da ciò che ci è rimasto nella diapositiva precedente, giusto? Quindi avevi queste immagini. |
| |
Quello che voglio fare è modificare il modello in modo banale, solo per illustrare il concetto. Quindi vai a... |
| |
Vai alla macro, scorri verso il basso e trovi la cosa che vuoi modificare, e io farò una semplice modifica qui. Cambierò il colore dell'intestazione solo per sottolineare un punto, giusto. Quindi cambia questo |
| |
E |
| |
salvalo. E questo è in tempo reale. |
| |
Puoi salvare questo e cancellare le diapositive in modo che il tutto venga trasferito più velocemente nel repository, perché sarai tu a inviarlo al repository. |
| |
E poi lo pubblichi usando l'interfaccia grafica di Git. Andrà nel repository |
| |
e lo renderà disponibile ai tuoi utenti. Quindi tutti i tuoi utenti riceveranno la modifica all'istante. Quindi, non dovrai chiedere loro di aggiornare PowerPoint o altro. |
| |
Questo andrà semplicemente nel repository. |
| |
Quindi tornerò a JMP e alla modalità utente, quindi eseguirò nuovamente lo script, che recupererà il nuovo PowerPoint. |
| |
E se lo esegui di nuovo, passerà attraverso il |
| |
diapositive, verrà creata la diapositiva. E quello che noterete è che sono state apportate delle modifiche, che riguardano il cambio del colore della riga dell'intestazione. |
| |
COSÌ, |
| |
cos'altro abbiamo? |
| |
Monitoraggio degli script. Penso che questa sia stata una delle migliori funzionalità che abbiamo sviluppato, perché dà la possibilità allo sviluppatore di vedere se |
| |
Il loro copione... il suo, il suo copione è apprezzato o no. Giusto. Quindi viene eseguito? Qualcuno lo esegue regolarmente? |
| |
Quindi questo è un vantaggio. L'altro vantaggio riguarda |
| |
log...raccolta dei log degli arresti anomali. Quindi, se lo script fallisce, è possibile catturare l'errore utilizzando la funzionalità di acquisizione dei log di JMP. In questo modo, si inseriscono le subroutine nella funzione di acquisizione dei log. |
| |
Se fallisce... il fallimento... il registro dell'errore verrà restituito in questo testo restituito dal registro. E poi quello che fai anche è |
| |
racchiuderlo in un try, in modo che lo script sopravviva per effettuare la segnalazione. |
| |
Poi controlli se è vuoto. Se è vuoto, significa che non si è verificato alcun crash, quindi i tuoi script sono sopravvissuti. |
| |
Ma se non è vuoto, significa che si è verificato un crash e lo hai contenuto. Puoi recuperare il log e segnalarlo. Il modo per farlo è usare HTTP. |
| |
ID utente, nome dello script e nota di registro, se si tratta di un arresto anomalo... |
| |
Che si tratti di un crash o di un'esecuzione regolare, magari puoi anche fornire alcune metriche sulle prestazioni. In sostanza, puoi trasmettere alcuni metadati relativi al tuo script allo sviluppatore. |
| |
E quello che farà il server è registrarli e avrai un set di file memorizzati sul server e potrai monitorarli. E sto solo mostrando un esempio. |
| |
tabella di questi. È un registro di crash, che ha... che ha il timbro della data, ha un nome di script, quindi questo script è fallito alla data |
| |
con questo particolare crash. Quindi questo è estremamente utile per lo sviluppatore perché può tornare indietro e risolvere il problema. Quindi comprimerò questo e questo e farò una rapida dimostrazione qui che mostra come |
| |
come tu |
| |
contenere l'arresto anomalo e come segnalarlo all'utente. Quindi quello che farò qui è creare un arresto anomalo della subroutine. Creerò un parametro indefinito |
| |
e JMP si lamenterà. Dirà che questa cosa non è definita, quindi lo script si blocca. Ma quello che farò è chiamare quella subroutine |
| |
in una funzionalità di acquisizione del registro e tutto sarà inserito in un tentativo. Quindi, anche se lo script si è bloccato con la subroutine, sopravviverà nel complesso e sarà in grado di segnalare un |
| |
Segnalazione di crash. Quindi, si invia una notifica ben formattata all'utente e si dice che... gli script si bloccano con questo particolare errore e abbiamo creato un log per questo e ci stiamo lavorando. Quindi, questa è la notifica che si invia all'utente. |
| |
Una delle cose fondamentali che ho imparato ai Summit è stata l'automazione dei test. Prima facevo i test manualmente, il che era molto frustrante. |
| |
Perché richiede tempo e non puoi catturare ogni singolo dettaglio del tuo script. È impossibile fare ore di test quando apporti una piccola modifica. |
| |
Così ho iniziato ad occuparmi di test automatizzati e ho scoperto che è molto importante eseguire test unitari. Quindi, sapete, il test si riferisce al test di singole subroutine. Quindi, avete una funzione e volete testarla. |
| |
più volte prima di inserirlo nel tuo sistema generale, in modo da poter eseguire questi test unitari |
| |
per i singoli moduli, ma non sarà sufficiente. E posso mostrarvi un paio di esempi. |
| |
Ad esempio, la NASA ha perso il suo Mars Climate Orbiter per un motivo molto strano...a causa di un errore molto strano perché c'erano due team di software, uno in Europa, |
| |
uno negli Stati Uniti. E uno di loro lavorava con le unità di misura delle libbre e quello negli Stati Uniti, sì, quello era negli Stati Uniti, e quello in Europa. |
| |
usava Newton. Quindi hanno sicuramente fatto i loro test unitari. Ma quando hanno messo insieme il codice, non ha funzionato, perché uno si aspettava Newton e l'altro riceveva libbre. Quindi hanno letteralmente perso |
| |
Orbiter, solo perché si sono dimenticati di convertire da libbre a Newton. E più recentemente, come Starliner, la Boeing ha perso il suo Starliner e poi ha ammesso che avrebbe potuto individuare l'errore se l'avesse fatto. |
| |
un rigoroso test di integrazione. E alla fine, ciò che conta è il |
| |
test di integrazione perché i moduli non vivono da soli nello script, ma comunicano tra loro. |
| |
E questa è una divertente illustrazione del problema. Quindi puoi avere due oggetti che vengono testati a fondo. È una finestra, giusto? Cosa può andare storto con una finestra? |
| |
Ma se ne hai due insieme, non si apriranno nemmeno, quindi devi fare dei test di integrazione per vedere se sono combinati, se funzionano bene insieme. |
| |
E vorrei illustrare brevemente un punto che mostra come ho iniziato a fare test automatizzati. E questo si riferirà a un caso particolare, che è |
| |
un caso difficile, per essere onesti, perché questo testerà una finestra modale e le finestre modali non scompariranno a meno che non si clicchi su un pulsante. Quindi devi |
| |
creare uno script JMP che fa clic su un pulsante, che in un certo senso imita un comportamento umano, e quello che sto facendo qui è iniettare un tester nel |
| |
finestra modale qui. E la cosa bella di questo approccio, penso, è che puoi ancora distribuire |
| |
questa cosa, questo script ai tuoi utenti e gli utenti non si accorgeranno nemmeno che in realtà contiene una routine di test. |
| |
Quindi ha gli hook per un tester, ma poi lo esegui da solo, quello che fa è cercare questo parametro della modalità di test e non è impostato. |
| |
Quindi, se non è impostato, lo script lo imposterà a zero, disattivando tutti gli hook nella tabella. Puoi quindi fornirlo ai tuoi utenti e loro potranno eseguirlo in questo modo. |
| |
Tuttavia, se vuoi testare il tuo script, quello che devi fare è creare un codice tester sopra di esso. Il codice tester imposterà la modalità di test su uno e creerà anche il tester... |
| |
Oggetto tester che vuoi iniettare nel tuo script. Ad esempio, in questo caso particolare, seleziona una colonna specifica. |
| |
e poi gli assegna un ruolo cliccando un pulsante e poi esegue lo script, giusto? Quindi, questo imita letteralmente un comportamento umano. |
| |
Quindi caricherà lo script vero e proprio. In pratica, inietta i parametri nello script che si desidera testare. Ora che lo script viene eseguito automaticamente, verrà caricato ed eseguito, e l'interfaccia utente verrà chiusa dopo aver cliccato su questo e quel pulsante. |
| |
E poi quello che fai è eseguirlo di nuovo in una funzionalità di acquisizione dei log, in modo da sapere se qualcosa va storto, catturerai l'errore. |
| |
E lo inserisci anche nel tentativo di invio in modo che, nel complesso, lo script sopravviva per segnalare il log. E poi, se non c'è stato alcun errore, il log restituito sarà vuoto, il che significa che lo script non ha fallito. |
| |
Se qualcosa è andato storto, lo saprai nell'acquisizione del log. Ecco l'idea. |
| |
COSÌ, |
| |
Abbiamo |
| |
la capacità di monitorare gli script. Abbiamo la capacità di |
| |
Acquisire i log degli arresti anomali. Quindi ci siamo chiesti: perché non intervenire sul log degli arresti anomali? Se vedi un log degli arresti anomali, significa che qualcosa è andato storto, e lo script... l'utente lo sa già perché lo script si è ovviamente bloccato, e lo sviluppatore sa che lo script si è bloccato perché i log sono |
| |
memorizzati su un server. Quindi sono lì per essere utilizzati. Ma il fatto è che non si tratta ancora di un ciclo chiuso, perché l'utente non sa che lo sviluppatore lo sa. E si può chiudere questo ciclo creando ticket automatici. Quindi, poiché si hanno già le informazioni, si può |
| |
utilizzare un software di tracciamento dei bug come JIRA Atlassian e quindi è possibile utilizzare la funzionalità REST |
| |
per raccogliere le informazioni dal server, creare un ticket, assegnarlo allo sviluppatore e assegnare all'utente il ruolo di osservatore. L'osservatore significa che ogni volta che lo sviluppatore fa qualcosa |
| |
sul bug e inserisce tali informazioni in JIRA, che verranno inoltrate all'utente in modo che venga avvisato e sappia che qualcuno sta lavorando sul bug. |
| |
E ci sono diversi modi per farlo, a seconda del tipo di JIRA che hai, e ti sto solo dando il |
| |
codice di base qui. È un codice curl che puoi creare e raccogliere i metadati che hai dai registri degli arresti anomali e incorporarli in un file JSL e quindi verranno trasmessi tramite REST e andranno nel |
| |
JIRA, che è... che lo monitorerà per te. E poi JIRA, se configurato correttamente, JIRA lo notificherà... JIRA notificherà lo sviluppatore e possibilmente |
| |
l'utente per il quale... per il quale lo script si è bloccato. E quindi tutto questo è collegato e lo sviluppatore saprà che c'è un bug su cui deve lavorare e l'utente saprà che qualcuno ci lavorerà. |
| |
Bene. Credo che questo mi porti alle mie note conclusive. Solo gli spunti che potete trarre da questa presentazione. |
| |
Git è stato il fondamento del nostro sistema e ci ha permesso di realizzare molte belle funzionalità e non ho nemmeno menzionato quelle di base, che |
| |
che sono piuttosto ovvi, perché ti danno anche la possibilità di collaborare. Quindi, se più persone lavorano allo stesso script, puoi utilizzare tutte le funzionalità del |
