Vita da tecnici

Una delle cose che viene sempre utilizzata quando si scrive un file, ma di cui si ha poca conoscenza è l’encoding.

Cos’è l’encoding?

E’ il modo in cui un simbolo (una lettera, un numero, una valuta) viene tradotto in bit. Oggi esiste una specifica standard de facto che associa ad un simbolo un codice numerico. Questa specifica si chiama Unicode. Essa non fa altro che definire un valore numerico ad ogni simbolo che può essere scritto (quindi comprende caratteri di tutte le lingue occidentali, simboli cinesi, cherokee, etc), ma non stabilisce come tale valore numerico venga salvato fisicamente. Qui entra in gioco l’encoding che consente alla forma numerica del simbolo di poter essere salvata. Gli encoding più noti “da queste parti” sono ISO-8859-1, ISO-8859-15 (aggiunge il simbolo dell’euro al 8859-1) e UTF-8. Essi differiscono per come i smboli vengono salvati su disco.

Perchè tutta sta menata?

Perchè sempre più spesso mi capita di dover progettare e gestire prodotti che gestiscono file xml e ogni tanto mi vengono presentati degli errori “misteriosi” che sono dovuti al fatto che chi ha prodotto i file non aveva gestito correttamente l’encoding.

Ecco un semplice caso:

<?xml version=”1.0″ encoding=”UTF-8″?>

<specialchars>àèìòù€</specialchars>

Ho riportato un file xml in cui si dichiara l’encoding UTF-8. Si salva il file e tutto dovrebbe essere a posto. Niente di più sbagliato. Non basta scrivere UTF-8 nel file affinchè questo possa essere salvato in tale formato, è necessario *effettuare* l’encoding nel formato specificato. La dichiarazione nel file XML dovrebbe essere il risultato di una operazione di encoding fatta in maniera cosciente. Altrimenti cosa succede?

Il file viene salvato con un encoding diverso e quando viene dato in mano ad un parser xml tutto fila liscio fina a che nel messaggio non compare qualche carattere strano (tipicamente quelli accentati), a quel punto il programma (Java in questo caso) ce lo segnala:

Exception in thread “main” org.dom4j.DocumentException: Error on line 3 of document file:///c:/temp/test_ISO8859-1.xml : Invalid byte 2 of 3-byte UTF-8 sequence. Nested exception: Invalid byte 2 of 3-byte UTF-8 sequence.
at org.dom4j.io.SAXReader.read(SAXReader.java:482)
at org.dom4j.io.SAXReader.read(SAXReader.java:264)
at test.encoding.LoadAndParseXML.main(LoadAndParseXML.java:41)
Nested exception:
org.xml.sax.SAXParseException: Invalid byte 2 of 3-byte UTF-8 sequence.
at org.apache.xerces.util.ErrorHandlerWrapper.createSAXParseException(Unknown Source)
at org.apache.xerces.util.ErrorHandlerWrapper.fatalError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLErrorReporter.reportError(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl$FragmentContentDispatcher.dispatch(Unknown Source)
at org.apache.xerces.impl.XMLDocumentFragmentScannerImpl.scanDocument(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XML11Configuration.parse(Unknown Source)
at org.apache.xerces.parsers.XMLParser.parse(Unknown Source)
at org.apache.xerces.parsers.AbstractSAXParser.parse(Unknown Source)
at org.apache.xerces.jaxp.SAXParserImpl$JAXPSAXParser.parse(Unknown Source)
at org.dom4j.io.SAXReader.read(SAXReader.java:465)
at org.dom4j.io.SAXReader.read(SAXReader.java:264)
at test.encoding.LoadAndParseXML.main(LoadAndParseXML.java:41)

Il messaggio, una volta capito il problema, è chiaro, abbiamo dichiarato un encoding UTF-8, ma il file aveva un encoding diverso che “si è rivelato” quando è comparso un carattere “strano”. Questa è la cosa che tra più in inganno chi scrive software, infatti il programma va quasi sempre e ogni tanto “si rompe”, come mai?

La ragione sta nel fatto che sia ISO-8859-1(5) che UTF-8 usano la stessa rappresentazione binaria per i caratteri ASCII (è una scelta voluta per ragioni di efficienza e compatibilità) per cui non c’è differenza fra l’encoding in UTF-8 e ISO-8859-1 per i caratteri più comunente utilizzati. La differenza sta nei caratteri accentati ed in quelle di altre lingue (es caratteri cirillici). Oggi tutte le librerie che gestiscono file xml gestiscono anche l’encoding, quindi se capita un errore del genere significa che con molta probabilità chi sintentizza il messaggio xml lo fa tramite concatenazione di stringhe (sigh).

Che differenza c’è fra ISO-8859-15 e UTF-8? il primo è in grado di rappresentare un set decisamente inferiore di caratteri in quanto può utilizzare solo un byte per rappresentare un simbolo, mentre UTF-8 ha una codifica con numero di byte variabile che può arrivare fino a 6. L’eccezione riportata prima era: Invalid byte 2 of 3-byte UTF-8 sequence confermando il fatto che il decoder UTF-8 stava esaminando un carattere rappresentato da 3 byte ed il secondo non era quello che si aspettava.

Buon encoding a tutti

Una delle cose più trascurate è la postazione di lavoro. Spesso vedo persone che devono lavorare con PC non adeguati al compito che devono svolgere. Credo che sia un caso in cui con poco di più in termini di spesa si riesca ad ottenere un rendimento decisamente maggiore. Riporto un esempio personale, fino a due mesi fa lavoravo con un pc che richiedeva circa 35 secondi per avviare il tomcat usato per lo sviluppo (sullo stesso PC oltre all’antivirus era attivo Oracle 10g ed Eclipse, più un Firefox con i plugin firebug e webdeveloper). Quando sviluppo applicazioni web riavvio tomcat almeno 20 volte al giorno (ovvero dalle 2 alle 3 volte l’ora). Questo significa 20*35=700 secondi di attesa circa pari a 11 minuti abbondanti. Dopo qualche mese ho chiesto un pc più performante, adesso tomcat parte in 4 secondi. Questo significa 20*30=600 secondi risparmiati, 10 minuti esatti al giorno. Sono 200 minuti al mese, pari a quasi 7 ore. Non sviluppo tutti i giorni 8 ore al giorno, ma credo che di poter dire che ogni due mesi risparmio 8 ore. Considerato che il costo aziendale di uno sviluppatore con esperienza viene valutato sui 250/300 euro al giorno l’azienda in tre mesi rientra dall’investimento.

Per chi programma avere un pc adeguato è importante non solo dal punto di vista della redditività, ma anche come segnale che l’azienda invia al dipendente/collaboratore. Come vi sentireste se appena arrivati vi dessero un pc vecchio e lento? Come vi sentireste invece se vi dessero un pc nuovo potente e con un bel monitor LCD?

Questo non vuol essere un invito ad “esagerare”, comprando pc che rimangono inattivi per il 90% del tempo, ma un suggerimento a valutare le reali esigenze della persona con delle prove sul campo che misurino le attese durante il normale lavoro (da cui si potrebbe dedurre che i pc ronzini li dovrebbero dare al management, persone che solitamente leggono documenti e usano la posta elettronica).

Il Pc dal quale sto scrivendo questo articolo (il mio personale) ha una cpu Athlon64X2 3800+, 4Gb di ram 2 hd da 250GB e un monitor LCD da 22′ wide. Esagerato?

Forse, ma quando ho dovuto preparare un corso su Oracle Data Guard ed avevo due vmware Linux Centos 64bit ognuna con un Database 10g in archive log non mi sono pentito di avere tutto questo “ferro” a disposizione.

Quanto costa un pc con una configurazione simile? Ho davati un volantino pubblicitario di un negozio di una nota catena informatica che vende una configurazione molto simile (il monitor è lo stesso un HP w2207) a 999 euro iva inclusa.

Per chi lavora e porta a casa i soldi con l’informatica non sono soldi spesi male.

Spesso, parlando con le persone con cui lavoro emerge un argomento ricorrente, i tecnici, quelli che realizzano quanto altri hanno pensato, svolgono tale mansione per poco tempo (dove per poco intendo da due a quattro anni). Dopodichè solitamente vengono promossi ad un ruolo “più alto”, ovvero di coordinamento di altre persone e/o di analisi-progettazione “pura” (ovvero quella dove si programma in word ed outlook). Per verificare se è vero basta porsi le seguenti domande: quanto commerciali conosco con esperienza decennale? quanto dirigenti conosco con esperienza decennale? quanto capi progetto conosco con esperienza decennale? quanto tecnici conosco con esperienza decennale?

La risposta all’ultima domanda di solito è il minimo dei numero prodotti dalle risposte alle domande precedenti.

Questo perchè il ruolo di tecnico, almeno in Italia, è una fase di transito, non un punto di arrivo. Non mi sembra una strategia vincente per un serie di motivi che proverò ad elencare.

Quello più immediato è che tale percorso si applica di solito a persone che sono al primo lavoro o con poca esperienza e che necessitano di formazione per poter svolgere il loro ruolo. Solitamente il primo anno serve per imparare come si fanno le cose, quindi ne rimagono due o tre per accrescere la propria produttività. Giunti alla fine di tale percorso solitamente la persona è in grado di svolgere la propria mansione in maniera efficiente e produttiva per l’azienda cosa succede?

Deve cominciare ad occuparsi di altro, spesso mettendo nel dimenticatoio le cose che ha imparato, senza poterle trasmettere a qualcun altro.

Non voglio assolutamente negare che ci possa evoluzione nei ruoli tecnici, ma quella che vedo in giro non mi sembra molto conveniente per le persone che aspirano a rimanere a contatto con la “produzione vera” del software. L’evoluzione deve essere graduale e mantenere uno stretto contatto con le attività svolte in precedenza. Provo a spiegarmi meglio; quando si sviluppa un software ci sono una serie di moduli/classi/pattern che sono altamente ripetitivi e che è corretto affidare a persone con poca o media esperienza in quanto “la strada è già stata tracciata”. La persona tecnica impara a sviluppare tale soluzioni, si chiede se e come possono essere migliorate ed impara a svolgere il proprio lavoro. Una volta fatto questo è corretto cominciare a risolvere altri problemi di maggiore complessità o cominciare a pensare come riutilizzare le soluzioni adottate in contesti diversi. Seguendo un percorso di questo tipola persona cresce tecnicamente e continua a sviluppare software sempre migliore in quanto fa tesoro delle esperienze precedenti. Con la crescita del bagaglio di conoscenze si arriva ad un punto in cui di fronte ad un nuovo sviluppo la persona identifica chiaramente i problemi e le relative soluzioni ed è in grado di produrre lo scheletro dell’applicazione (infrastuttura o moduli core, etc, etc) sia in termini diprogettazione che in termini di codice e lasciare le parti ripetitive a chi deve imparare. In questo modo il tecnico rimane tale, incrementa la sua produttività e concorre a formare anche altre persone, migliorando la produttività aziendale.

A me sembra logico e coerente, ma poichè spesso non è così dei motivi ci saranno; provo a fare delle ipotesi.

La prima che mi viene in mente è che il ruolo tecnico viene visto dal mangement come un ruolo “basso”, meccanico in cui le persone sono facilmente sostituibili. Una diretta conseguenza sono stipendi bassi e una naturale tendenza delle persone a cercare ruoli pù remunerativi. Una seconda ragione consiste nel fatto che per aspirare a posizioni “alte” spesso (per chi non ha conoscenze o parenti altolocati) è necessario partire dal basso per cui il ruolo tecnico (che in questo caso viene assimilato da chi lo svolge a di basso profilo) viene visto come la gavetta per arrivare altrove. L’ultima ragione che mi viene in mente è che chi decide non sa assolutamente nulla o quasi di come avviene veramente la progettazione del software e dei diversi livelli di produttività legati all’esperienza delle persone per cui applica schemi letti sui libri (nel 99% scritte da persone che non ne sanno come lui/lei) .

Spesso mi è venuto il dubbio di essere mezo matto e di non capire assolutamente nulla di quete problematiche per cui ho provato a cercare delle prove che confutassero la mia tesi. La conferma che non sragiono mi è venuta da Google. E’ sufficiente leggere come effettuano le assunzioni di personale tecnico per trovare una assonanza con le mie idee. Google cerca persone con esperienza, in grado di *dimostrare* cosa sanno *fare*. Una delle loro assunzioni di qualche anno fa è Joshua Block uno dei maggiori progettisti/implementatori delle librerie Java (in particolare java.util). Invito i curiosi ad aprire il sorgente di java.util.ArrayList.java e di vedere chi sono gli autori: due persone con decenni di esperienza.

Il secondo motivo per cui non credo nella parabola del tecnico è quella che la strategia della temporaneità porta distorsioni nell’organigramma aziendale. Se dopo pochi anni l’azienda ci invita a fare i capo progetto/commerciali/etc, etc dopo una decina di anni ci si ritrova con tanti “coordinatori” e pochi “produttori” con una struttura aziendale che assomiglia ad una palla da football americano (in quanto il management di solito rimane composto da poche persone) . Una barca dove le persone che tengono il timone sono numericamente simili a quelle che remano. Le soluzioni ad un simile problema sono varie: si incentiva un ricambio dei ruoli intermedi sostituendoli con persone senza esperienza o si “costringono” le persone “nella parte larga della palla” a fare tecnici. Le conseguenze della prima soluzione sono perdita di conoscenze, quella della seconda insoddisfazione dei dipendenti che aspiravano (finalmente) ad un ruolo “meno tecnico”.

A mio parere la soluzione vera consiste nel selezionare in fase di colloquio persone con aspirazione tecniche per ruoli tecnici, (cosa che non tutte le aziende sanno fare) e farle crescere (anche con nello stipendio!!) secondo il loro profilo; il risultato sarebbero dipendenti/collaboratori più motivati e maggiore produttività aziendale.

Se lo fa Google una buona ragione ci sarà.