Category Archives: Uncategorized

2 anni di blogging: cosa ho scoperto che può tornarti utile

Oggi questo blog compie 2 anni. Solo a scriverlo mi sembra impossibile. Ma cosa mi sta insegnando questo viaggio?

gray steel chain on orange surface

Photo by Miguel Á. Padriñán on Pexels.com

 

Continue reading

Quella sottile linea invisibile

Camminando giusto giusto sul confine tra Italia e Austria nel percorso Water Trail.

Un passo sei di qua e un passo sei di là. Così semplice, quasi banale. Eppure la differenza è enorme. Sarà una fissa mia ma queste cose mi affascinano. E mi chiedo: perché proprio lì la linea di confine e non un metro prima o dopo? Come viene deciso?

Questi confini geografici mi scatenano poi dei pensieri piu generici o astratti. Quanti confini attraversiamo nella nostra vita? E quanti ammettono un tornare indietro?

I nostri confini sono anche ciò che ci caratterizza: i nostri limiti, i nostri princìpi, la nostra confort zone. Cosa facciamo quotidianamente e in modo tangibile per espandere noi stessi, le nostre abilità e le nostre conoscenze?

Detto questo mi fermo qua, potrei cominciare a farneticare e sconfinare in un territorio filosofeggiante che non mi appartiene.

A voi affascinano i limiti, i confini, le situazioni limite?

Keep it going

It has been nine months since the opening of this blog and it’s time to make a look back. I started this adveture to record some interesting readings, some thoughts and to exercise in writing. I also started because I read all over my Twitter timeline and other developers’ blog that opening a blog and start writing technical things down makes you a better developer. Being a better developer is what makes me tick and so this place was born.

9-cards-home-launcher-icon.png

In the very first period I updated my social profiles (LinkedIn and Twitter) and setup the basics of the blog: the name, the graphical theme and the pages where I talk about who I am.

The blog started in Italian because it was meant for my personal exercise. I found that it was true: writing things in a good form (not just tech notes or tech e-mail at work for you or your team) that is in a very minimal way pleasant to read improves your knowledge about a subject. I have to research, to read twice to provide scripts and images, and so on. Now I write in English because I want to practice and because English is the main language in the IT world. Anyway, I won’t stop to write some posts in Italian.

I’ve a schedule that I can live with of 2-3 posts a week. This is the most difficult part. It was easier at the beginning: everything was new but being constant is the hardest thing.

Conclusions

No matter what I have to keep up and go on because I’m receiving positive feedback from this experience that I want to maintain and possibly amplify. My plan for the near future is to became Always better in English technical writing about the subject I like the most: Windows, C# and possibly a bit of Unity 3D engine.

 

 

 

Tu sei il tuo peggior nemico

As a software developer, you are your own worst enemy. The sooner you realize that, the better off you’ll be-

– Jeff Atwood

Per quanto Jeff “Coding Horror” Atwood possa essere a volte schietto e brutale penso che sia difficile contraddirlo in questo contesto.

Il miglior codice di tutti è nessun codice.

Abbiamo tutti le migliori intenzioni quando scriviamo codice ma poi ogni riga di ciò che scriviamo deve essere debuggata, deve essere capita, documentata ecc…

Facciamo al mondo un favore, se possiamo scriviamo meno righe di codice possibile.

I test sono per le persone

State scrivendo test automatizzati per alcune parti del vostro codice in produzione. Congratulazioni! State scrivendo i test prima di scrivere il codice? Ancora meglio! Già fare ciò vi fa rientrare tra gli avanguardisti delle pratiche di ingegneria del software. Ma state scrivendo buoni test? Come si può dirlo? Un modo è chiedersi, “Per chi sto scrivendo i test?” Se la risposta è “Per me, per evitarmi di correggere bug poi” o “Per il compilatore, così possono essere eseguiti,” allora è possibile che non stiate scrivendo i test migliori possibili. Quindi, per chi dovremmo scrivere test? Per le persone che cercano di capire il vostro codice.
I buoni test servono anche da documentazione per il codice che stanno testando. Descrivono come il codice funziona. Per ogni utilizzo i test:

  1. Descrivono il contesto, il punto di partenza e le precondizioni che devono essere soddisfatte;
  2. Illustrano come il software viene chiamato;
  3. Descrivono i risultati attesi con le post-condizioni che devono essere verificate.

Le persone che cercheranno di capire il vostro codice dovrebbe guardare un paio di test, e confrontarli con le tre sezioni appena descritte e trovare in ciò una guida.

Vittoria

Un genio ti credevi
e mete altissime
di raggiunger speravi.

“Mi basta un’occasione
(ti vantavi) per fare
un balzo avanti, colossale…”

Ora il dubbio ti assale:
passati son molti anni,
con vani sogni, ahimè,
te stesso inganni.

Se avanzare tu vuoi
è il presente che conta.
Afferralo, e spremine
tutto quello che puoi.

– Herbert Kauffman

 

Messaggi di errore

Ho sempre avuto un particolare interesse per i messaggi di errore. Ritengo che un software a qualunque livello (app per smartphone, l’app della tua azienda, il gestionale per la fatturazione del negozio sotto casa) debba avere i messaggi di errore che siano utili per l’utente finale (anche per il servizio assistenza se necessario o coerente con l’ambito d’utilizzo) e non fargli venire voglia di spaccare lo schermo.

IC725769

Un messaggio di errore frustrante

Niente è più demotivante di un messaggio di errore che dice tutto/niente, lasciandoti a bocca asciutta e che non ti guida verso la risoluzione del problema. I messaggi di errore frustranti fanno venire voglia di disinstallare il programma e sconsigliarne l’uso a colleghi-amici-parenti. Siccome la differenza la fanno i dettagli, quando vedo dei messaggi di errore ben scritti faccio sempre mentalmente i complimenti a chi ha creato il software.

Per messaggio di errore si intende:

Un avviso all’utente riguardo un problema che è già accaduto.

I messaggi di errore sono quindi da distinguersi rispetto alle dialog box, ai messaggi di avviso e alle conferme.

Il primo problema con i messaggi di errore è che ci sono troppi modi per farli sbagliati: troppo tecnici, troppo generici, che accusano l’utente, troppo rossi, con le scritte maiuscole, con troppo informazioni buttate alla meno peggio e via dicendo.

Perciò quando è il mio turno di scrivere dei messaggi di errore faccio il meglio che posso per renderli dei gentili avvisi per l’utente provando a renderli:

  • Informativi in un linguaggio comprensibile ai non tecnici e inerenti al dominio del problema;
    • Esportazione del bilancio non riuscita per sovraccarico del sistema, riprovare tra qualche minuto è meglio di Esportazione dei dati non riuscita per un timeout della richiesta al server;
  • Essere concisi;
  • Fornire informazioni su come venirne fuori;
  • Il pulsanti/le scelte devono avere un testo che sia un verbo d’azione che fa riferimento esplicito a come l’utente sceglie di arginare il problema, tipo: Annulla, Riprova, Conferma, Ho capito, Continua (da evitare i classici OK / Sì / No);
  • Contenere informazioni di aiuto per il reparto tecnico di assistenza, visibili all’utente tramite progressive disclosure.

Degli ottimi messaggi di errore si trovano in Git:

 

Cattura

Esempio di errore per comando non esistente in Git.

 

Cattura

Messaggio di errore di Git del comando add

 

I miei buoni propositi per i messaggi di errore non riesco sempre a mantenerli, ma è un argomento che mi sta a cuore e per questo cerco di fare meglio al messaggio successivo (o revisionando quelli vecchi).

Riferimenti

MSDN – https://msdn.microsoft.com/en-us/library/windows/desktop/dn742471(v=vs.85).aspx

Apple – https://developer.apple.com/library/mac/documentation/UserExperience/Conceptual/OSXHIGuidelines/WindowAlerts.html

 

Invece di…

Un collega ha comprato qualche settimana fa SQL Server 2014 Unleashed. È uno dei soliti libro-mattone che potresti usare come fermaporte nelle giornate più ventose. Lo sfogliamo casualmente durante le pause caffè o altre occasioni in cui si stacca dal monitor per prendere fiato. Così mi sono imbattuto nel capitolo dei trigger, in particolare nella sezione degli instead of trigger.

Scopro un mondo parecchio interessante, dei trigger che scattano prima delle effettive operazioni sui dati: a differenza dei trigger tradizionali che scattano ad operazioni eseguite (chiamati trigger AFTER). Nel dettaglio:

  1. Viene recepito un comando DML;
  2. Scatta trigger INSTEAD OF;
  3. Scattano controlli CHECK;
  4. Scatta trigger AFTER.

Esempio:

CREATE TRIGGER dbo.TI_PERSONE_CONTROLLI ON dbo.PERSONE INSTEAD OF INSERT

In un primo momento non ne trovo un’applicazione che potrebbe fare al caso nostro e archivio la questione.

Verso sera capita che abbiamo problemi di spazio su disco presso un cliente. Delle verifiche ci portano a scoprire che una tabella di log è esageratamente grande e popolata erroneamente da un bug di un programma di scambio dati. Il bug era di semplice risoluzione ma per vari motivi era impossibile sostituire il programma nel server. Amari estremi, estremi rimedi:

TRUNCATE TABLE LOG;
CREATE TRIGGER dbo.TI_LOG_ANNULLA_INSERT ON dbo.LOG INSTEAD OF INSERT
AS
BEGIN
	PRINT ''
END;

Il giorno successivo abbiamo sostituito il programma di scambio dati e distrutto il trigger instead of.yes

Riferimenti

MSDN https://msdn.microsoft.com/en-us/library/ms189799.aspx

 

Inizio

Il primo post.

Lo sto scrivendo con mia figlia in braccio mentre va un video di canzoni per bambini. Potrebbe essere di buon auspicio! È il secondo progetto di un blog che inizio. Il primo anni fa non mi aveva convinto ed è morto dopo poche settimane. Adesso sono molto più entusiasta e mi sento carico.