Proprio in questi giorni sul forum Tips&Tricks di Pro Gamma è apparso il 10.000° messaggio. In questa occasione voglio proprio dirlo un’altra volta: grazie.
Grazie della partecipazione, del supporto e dei suggerimenti con i quali ci avete dimostrato un grande affetto verso Instant Developer e Pro Gamma.
Grazie perché con la collaborazione di tutti il forum è diventato uno strumento utile ed efficace per risolvere i problemi che si possono presentare durante lo sviluppo delle proprie applicazioni.
10.000 di questi giorni a tutti 
.
Nessuna applicazione moderna deve avere bisogno di un manuale per poterla utilizzare, in diverse occasioni ci siamo trovati d’accordo su questo.
Tuttavia molte applicazioni gestionali hanno a che fare con processi complessi, che man mano le rendono sempre più complicate: fino a quando si tratta di scorrere delle fotografie e indicare quelle che ci piacciono non ci vuole molto, ma gestire un sistema di programmazione della produzione è tutta un’altra cosa.
A questo punto alcuni potrebbero proporre di inserire nell’applicazione stessa dei “sistemi integrati di documentazione”, che diano all’utente le informazioni che servono quando non sa come andare avanti. Questo era proprio l’obiettivo di Kera: insegnare al mondo come usare il software, tramite un tool che permette agli sviluppatori di aggiungere un sistema di tutorial integrato alle proprie webapp.
Ma qualche settimana fa Kera ha gettato la spugna, riconoscendo che gli utenti non vogliono essere guidati mentre usano le applicazioni. Può sembrare strano, ma è così. Ma quale può essere la ragione di questo comportamento?
Qui la discussione è aperta; dopo tanti anni di osservazione di come gli utenti approcciano l’uso delle applicazioni, secondo me il motivo principale è che formazione e utilizzo sono due processi staccati fra di loro. Mentre uso l’applicazione non la voglio dover imparare, devo invece avere uno spazio di tempo separato per dedicarmi all’apprendimento.
Quindi, se proprio non riuscite a rendere naturale l’utilizzo delle vostre applicazioni, il mio consiglio è quello di non buttare soldi nella trappola dei tutorial, ma di convincere i vostri clienti a pianificare corsi di formazione.
Cosa ne pensate?
Se anche il tuo portatile ha qualche anno, probabilmente avrà cominciato a far girare le ventole come una portaerei e a far sentire i suoi anni in termini di performance. Per il rumore si potrebbe usare un compressore per pulire il dissipatore, ma per quanto riguarda le performance non c’è molto da fare.
Tuttavia prima di uscire a comprare il tuo nuovo laptop ti consiglio di aspettare un attimo. Perché Haswell, il nuovo chip di Intel, sta per cambiare tutto: batterie che durano un giorno intero, CPU tre volte più veloci e grafica decisamente più performante rispetto a quelle odierne.
E non è tutto, perché Intel ha voluto tirare fuori un altro coniglio dal cappello: Silvermont, la nuova architettura a 22nm per processori Atom. Immaginate che tutto quello che ho appena scritto sui notebook valga anche per i dispositivi mobile.
Pensavamo che ormai la battaglia dei processori fosse finita?
Beh, ci sbagliavamo e ne vedremo delle belle.
La scorsa settimana abbiamo ricevuto una richiesta di assistenza che segnalava un possibile problema relativo ai campi contatore. Il testo della domanda era il seguente:
Inserisco un record in una tabella che ha un campo contatore; nella istruzione di Insert ho usato la funzionalità di Instant Developer che mi fornisce il valore del campo contatore dopo l’inserimento. Però non sembra funzionare correttamente.
Avevamo già ricevuto richieste simili in passato e anche questa volta la causa del problema è la stessa: la presenza di un trigger che dopo il salvataggio della nuova riga esegue una insert su un’altra tabella, anch’essa dotata di un campo contatore. Infatti per recuperare il valore in questione dopo uno statement di insert, le applicazioni sviluppate con Instant Developer utilizzano la proprietà @@IDENTITY, ma in questo caso particolare il risultato ottenuto non è corretto. Questo “problema” è noto a chi utilizza SQL Server, tanto da avere un nome specifico: Identity Crisis.
Alcuni di voi conoscono già il problema e in passato ci hanno chiesto perché non utilizziamo la funzione SCOPE_IDENTITY() per risolverlo. Purtroppo, come segnala Microsoft, in alcuni casi le funzioni @@IDENTITY e SCOPE_IDENTITY() possono restituire valori non corretti. Il bug è chiuso ma la correzione è presente solo in SQL Server 2012:
[...] that this bug is fixed in SQL Server 2012, but not in older versions, and that they will probably not provide a patch for older versions of SQL Server because of the risk of regression bugs.
Se avete a che fare con contatori e trigger di questo tipo, avete una sola strada da percorrere: rileggere il valore dell’ultima riga inserita identificandola mediante altri campi. È una soluzione scomoda, certo, ma è l’unica che può darvi una certezza.
Se invece dovete sviluppare una nuova applicazione voglio darvi un consiglio diverso. Infatti l’identity crisis non è l’unico problema legato all’uso dei contatori. Ad esempio, la sincronizzazione bidirezionale di dati generati da applicazioni mobile offline diventa problematica, perché i valori dei campi contatore creati nei dispositivi potrebbero essere in conflitto fra loro.
Come fare per risolvere definitivamente la questione? Se sviluppate con Instant Developer vi propongo di usare il DocID: un GUID compresso in 20 caratteri utilizzato per identificare univocamente ogni entità, che risolve in maniera definitiva il problema della crisi d’identità. Se ne volete sapere di più potete leggere il manuale di Instant Developer alle pagine 39 e 229-230. Tra l’altro, usando i DocID non c’è nemmeno bisogno di rileggere il valore della chiave primaria che è già disponibile nella parte client della vostra applicazione.
Mai più crisi d’identità!
Riferimenti:
Iscrizione in corso...
