232641_it-IT

liliconcom

Scripting: compatibilità verso l'alto in generale

Quasi ogni versione (dalla 7y) ricevo chiamate dai clienti che dicono che i loro script non funzionano più nella nuova versione. Ricevi chiamate simili?

 

Mi chiedo se potremmo avere un migliore controllo di compatibilità verso l'alto per gli script personalizzati (non quelli generati integrati, dove mi aspetto che abbiamo questo controllo). Per essere chiari, non parlo di funzionalità all'indietro (ovvero il mio script JMP 15 non funziona in JMP 13) poiché il software si evolve in modo naturale. Ma come consumatore / utente mi aspetterei che uno script che scrivo in JMP 14 verrà eseguito ancora in JMP 15. 

 

So che l'adozione anticipata è un modo per conoscerlo presto e inviare i problemi all'elenco e-mail. MA c'è un grosso problema: gli utenti di solito non hanno il tempo di fare un controllo di compatibilità nell'adottante, soprattutto se ci sono 7-9 versioni di esso. Questo dovrebbe essere fatto dal lato del fornitore del software. Questo è anche ciò di cui i clienti si lamentano il più delle volte. "Non è il loro lavoro" e devo ammettere che sono parzialmente d'accordo (per la maggior parte dei casi).

 

Quindi, hai lamentele simili da parte dei clienti? Qual è il nostro attuale processo di verifica della compatibilità verso l'alto? Sarebbe bello riunire qui alcuni casi e suggerimenti su cosa si potrebbe fare. (E potremmo anche discuterne durante una sessione di kick-off con gli sviluppatori corrispondenti - ricordo le domande e risposte in Aula in cui si potevano affrontare quelle cose, ma l'ultima è stata credo 3 anni fa - si può solo per gli SE nel 2020? ).

 

Grazie,

balestruccio

 

PS: motivo per cui lo rendo così prominente, un cliente manifatturiero con> 100 licenze è così sconvolto da anni che pensa di passare da JMP ad altre soluzioni, persino all'open source, e sono davvero amichevoli da JMP per anni).

Ri: Scripting: compatibilità verso l'alto in generale

Ciao Martin,

 

FWIW, la mia esperienza è che la mancanza di compatibilità in avanti è quasi sempre correlata all'estrazione delle cose dal rapporto per manipolarle ulteriormente. Dici che è ragionevole aspettarsi che il software si "evolva naturalmente", ma, piaccia o no, i cambiamenti nella struttura del rapporto sono una conseguenza quasi inevitabile di questo desiderio. Dovremmo sempre preoccuparci di segnalarlo ai clienti che fanno davvero un uso pesante degli script.

 

Come sapete, per i software utilizzati nella "produzione", è molto comune, persino richiesto, disporre di aree di gestione temporanea in cui il software aggiornato viene accuratamente testato prima di renderlo "attivo". Questa disciplina potrebbe essere in contrasto con il fatto che JMP è "solo" un software desktop, ma (come illustra il tuo messaggio) i rischi sono effettivamente reali e dovremmo aiutare gli utenti a vedere JMP in questo modo quando i loro modelli di utilizzo lo richiedono.

 

In breve, questa tensione è un effetto collaterale del fatto che JMP è così molto funzionale. Penso che possiamo e dovremmo fare un lavoro migliore avvisando i clienti dei rischi e delle conseguenze della mancata fornitura di una significativa base di codice JSL al supporto di buone pratiche di ingegneria del software industriale. La ricerca e sviluppo "potrebbe" fornire metodi per ottenere tutti i valori richiesti in modo indipendente dai report, ma ciò non si trova in alcuna tabella di marcia di cui sono a conoscenza e in ogni caso eliminerebbe un po 'della flessibilità che i programmatori JSL sembrano apprezzare altamente.

 

Come te, sarei molto interessato a conoscere altri esempi in cui abbiamo avuto problemi su questo. . .

 

Saluti,

 

Ian

Ri: Scripting: compatibilità verso l'alto in generale

Ciao Martin!

TL; DR:

Punto 1: Le interruzioni di codice tra le versioni sono in genere perché le persone non seguono le migliori pratiche JSL e lo scripting in modo difensivo. Punto 2: È sempre responsabilità del cliente convalidare le prestazioni del software (nostrane o meno) tra le versioni. Dovrebbero trattarlo proprio come qualsiasi altro strumento di produzione - che è tutto controllato prima di essere rilasciato in produzione.


La versione lunga:

Solo per riff sul commento @ian_jmp made - Per la maggior parte, le interruzioni di codice tra le versioni sono dovute a persone che non seguono (o tengono il passo con) le migliori pratiche JSL. È molto più facile rompere il codice che funziona ma non è ben pensato. Mark Bailey lo chiama "script difensivo". L'esempio di Ian di persone che traggono da rapporti esistenti è classico, in particolare se stanno sottoscrivendo l'intero albero di visualizzazione. La migliore pratica per questo è usare un nome di casella di contorno come punto di riferimento locale e quindi sottoscrivere (perché non cambiano spesso).

Ho anche incontrato un paio di casi in cui le persone (me compreso) costruiscono JSL che si basa su una funzionalità che viene revisionata tra le versioni. Per me, le modifiche apportate a Recode apportate a JMP 14 hanno interrotto parte di un componente aggiuntivo che stavo mantenendo. In quel caso, ho fatto qualcosa per far funzionare il codice e mi sono bruciato per questo. Un altro esempio (cliente) è quello in cui qualcuno utilizzava nomi non ODBC conformi nel proprio database. Quando abbiamo imposto ODBC tra le versioni gli script si sono rotti. Qui qualcuno non ha seguito gli standard e si sono bruciati per questo. L'asporto è che i tuoi clienti hanno meno probabilità di incorrere in problemi se creano codice che segue le nostre migliori pratiche per la scrittura di JSL. Se lo fanno, è piuttosto raro che JSL interrompa la versione in versione. La maggior parte delle cose che ho scritto con una mentalità alla sceneggiatura difensiva è piuttosto robusta, ma continuo a controllare che tutto funzioni. Di solito aspetto fino all'ultimo paio di versioni dei primi utenti per testare (le modifiche a JMP sono generalmente piuttosto stabili a quel punto).

Ian ha anche fatto un'ottima osservazione sullo spostamento tra le versioni. Negli Stati Uniti, abbiamo alcune industrie fortemente regolamentate (farmaceutica, biotecnologica, finanziaria e alcune industrie manifatturiere con applicazioni di sicurezza militari o nazionali). Questi settori hanno requisiti di convalida per qualsiasi nuovo software o nuove versioni di software che richiedono all'utente di documentare di aver verificato il funzionamento del software e di fornire risultati coerenti tra le versioni. Gli altri miei clienti sanno che devono controllare il loro codice di integrità tra le versioni. Quindi penso che sia davvero il problema della maturità e della disciplina nella cultura aziendale di quel cliente (o almeno con le persone che generano lì la JSL). Il flusso di lavoro di test che Ian ha menzionato (messa in scena, quindi rilascio alla produzione) è una pratica standard in tutti i settori con cui abbia mai lavorato (negli Stati Uniti, nell'UE o in Asia) - dovrebbero sapere meglio che assumere.

Quindi, riassumendo, se la loro JSL è critica, devono trattarla come qualsiasi altro software di produzione e convalidare la versione JMP (con la JSL mission-critical) prima di rilasciarla alla produzione. Scommetto che le tue lamentele provengono principalmente da parti della comunità ingegneristica che non capiscono come funziona. Potresti chiedere loro se rilasciano in produzione un nuovo equipaggiamento prima di testare accuratamente le prestazioni di questo strumento e abbinarlo alle altre parti - risponderebbero "no". A quel punto potresti sottolineare che il software è uno strumento e dovrebbe essere trattato allo stesso modo.

Segui il pensiero

 

Pensandoci di più: se le persone seguono le migliori pratiche JSL (utilizzando funzioni ed espressioni, ambito, spazi dei nomi, commentando pesantemente il loro codice , ecc.) è più facile eseguire il debug quando le cose si rompono (cosa che fanno).  Quindi sembra che il cliente in questione abbia qualche fragile JSL mal formata che è cresciuta organicamente nel tempo.  Probabilmente è commentato in modo orribile e la persona che l'ha scritto è passata o non ha idea di come risolverlo (chiamo questi script franco) ... In tal caso, consiglierei di inviare qualcuno che conosce il JSL ai corsi SAS Ed JSL per un aggiornamento sulle migliori pratiche e quindi di liberarli per modernizzare il codice in questione e mettere in atto alcuni SOP per aggiungere il JSL in questione ai loro piani di test di convalida del software.

Ri: Scripting: compatibilità verso l'alto in generale

Sono d'accordo con tutti i commenti finora. Vedo il codice di "produzione" sempre orribile. Non riesco a credere che funzioni nella versione attuale, tanto meno hanno una speranza in futuro. Questi utenti non hanno imparato come eseguire lo scripting di JMP. Questo è diverso dalla programmazione generale del computer. Non è solo sintassi. Hanno appena hackerato. (Uso il termine "hacker" con venerazione. Questa attività è diversa.) Non sanno cosa stanno facendo.

 

Per quanto riguarda il commento sui cambiamenti nell'interfaccia utente di JMP che ostacola l'accesso al livello di report, molti utenti non praticano la codifica sicura. Ci sono modi per minimizzare o eliminare questi problemi, ma il loro modo produce un codice fragile.

Ri: Scripting: compatibilità verso l'alto in generale

Grazie finora per i tuoi commenti. Sono d'accordo con tutti i tuoi punti riguardo ai test prima di andare in produzione e salvare / codifica difensiva (anche se probabilmente agli utenti non piacerà;)). Questo è definitivamente sotto la responsabilità dell'utente e dell'azienda utilizzando script in qualunque lingua.

 

Tuttavia, voglio portare avanti la discussione anche con un punto di vista più critico (- alla fine, spero che nella migliore delle ipotesi abbiamo un messaggio comune per i clienti e un processo di automazione più solido da vendere ai nostri clienti):

 

Proveniente da una software house che si basa sul linguaggio di programmazione su cui si basa lo strumento, sono sorpreso di quanto spesso mi renda conto che JSL passa da una versione all'altra. Nella mia vita passata ho avuto questi problemi solo con funzioni e funzioni non documentate, non con impostazioni e opzioni come ad esempio temi di colore e altre cose negli alberi o nei metodi degli oggetti. Inoltre tutte le funzioni sono state documentate nella misura massima: quali input e output sono disponibili, qual è la descrizione e la definizione di questa opzione / input / output e così via. La guida allo scripting e l'indice non sono entrambi quel tipo. Più a questa è la chiamata base e tutte le altre possibili opzioni che devi scoprire da solo. 

 

Si potrebbe dire che tutte le parti non documentate sono soggette a modifiche: sarebbe la risposta semplice. Ma credo che non sia così facile. Il più delle volte dobbiamo cambiare almeno un po 'di "un livello al di sotto delle funzionalità integrate". Non forniamo una documentazione concreta che affermi "questo è ciò che puoi fare" e "tutto il resto non è supportato" (aka potrebbe funzionare ora ma è soggetto a modifiche). 

Un linguaggio di programmazione dovrebbe avere un tale framework - o diciamo che JSL non è un tale linguaggio di programmazione ed essere più attenti con la nostra attuale promozione di creare applicazioni per raggiungere più utenti in quanto è facile costruire codice riproducibile ma potrebbe non essere così affidabile per le versioni future. 

 

Sarei interessante sentire cosa ne pensano gli altri di questo (lo ammetto con un punto di vista più critico e mirato allo scopo, ancora una volta per favorire una discussione divers su questo argomento), potrebbe anche l'uno o l'altro sviluppatore che lo facciano nel loro giorno per base diurna.

 

 

 

Ri: Scripting: compatibilità verso l'alto in generaleIl tuo ultimo punto è quello critico: JSL è incredibilmente potente, ma alla base non è un "linguaggio di programmazione", è un linguaggio di scripting o macro. Ha strutture che assomigliano alla programmazione orientata agli oggetti e può essere usato in qualche modo in questo modo, ma è costruito su JMP ed è sempre stato progettato per automatizzare le attività nella GUI o estendere la GUI. Molte persone dimenticano che - ciò significa anche che dimenticano quando le cose cambiano nel prodotto - le cose possono rompersi in JSL (in particolare se non le codificano bene). Non dovremmo parlare di JSL nel modo in cui facciamo C ++, ecc. A rigor di termini, anche Python e R sono linguaggi di programmazione più strettamente correlati rispetto a JSL. Forse alcune persone si confondono perché la linea è sfocata con macro di Excel e VBA. Tuttavia, il punto è che JSL è un linguaggio di scripting diverso da un linguaggio di programmazione.

Migliore,

M
Ri: Scripting: compatibilità verso l'alto in generale

Ciao Mike,

 

D'accordo, è una lingua languida di scripting e quindi dovrebbe essere calpestata. Ho trovato preziosa questa discussione di discussione in quanto evidenzia anche alcuni aspetti aggiuntivi che dovremmo sempre guidare le persone a pensare quando iniziano ad automatizzare o scrivere i loro processi. Abbiamo - oltre al corso di formazione JMP JSL - altri riferimenti relativi a JMP per gli script "difensivi"?
La maggior parte dei riferimenti trovati nel web sono per altri linguaggi e non relativi a JMP (anche se potresti usarli anche tu, ovviamente). I webcast di Mastering JMP non coprono un buon stile di programmazione / scripting. Potrebbe essere un argomento interessante anche per una presentazione di scoperta?  

Ri: Scripting: compatibilità verso l'alto in generaleQuesta è un'area in cui penso che potremmo migliorare. Ci sono molte informazioni sulla comunità, nel cervello del personale, nei libri e nella documentazione, ma in realtà non c'è un documento di "best practice" di cui io sia a conoscenza. Ci dovrebbe essere. Penso che gran parte della costernazione che stai vivendo sul campo possa essere segnata fino a questo punto.

@ian_jmp - forse questo sarebbe qualcosa che la comunità tecnica potrebbe fare come barra laterale durante il calcio d'inizio.

Migliore,

M
Ri: Scripting: compatibilità verso l'alto in generale

Come suggerito dalla mia risposta, penso che questa sia un'area con cui potremmo fare di meglio, soprattutto perché generalmente incoraggiamo la costruzione di applicazioni come componente della parte "espandi" della nostra "strategia di espansione e di terra".

 

FWIW, la mia opinione personale è che non tutte le SE dovrebbero essere competenti in JSL a meno che non siano così inclini. Ma credo che ogni SE dovrebbe sapere cosa è possibile e, insieme a ciò, quale potrebbe essere la buona pratica e le insidie di non aderire a questo.

 

Sfortunatamente, anche se il calcio d'inizio 2020 è un po 'compresso e la pista tecnica è già organizzata. Quindi troveremo un altro modo di gestirlo. Più tardi.

Ri: Scripting: compatibilità verso l'alto in generale

Abbiamo iniziato ad aggiungere suggerimenti espliciti sulle "migliori pratiche" nei nostri corsi di scripting diverse edizioni fa. Continuiamo ad estendere e perfezionare questi suggerimenti con ogni revisione. Riceviamo feedback positivi dagli studenti. Beh, almeno dagli studenti che non hanno fretta di hackerare.