Vita da tecnici

Mentre scrivevo il post precedente ho cercato su google “utf byte exception” per ottenere la dicitura dell’eccezione java.

Il primo risultato è stato il mio blog!!

ho deciso di immortalare l’evento con un bello screenshot (attenzione la risoluzione è 1680X1050).

Questo è il penultimo dei post che riguarda l’xml encoding e tratta un argomento che si può presentare quando si ha a che fare con delle applicazioni che si basano su scambio di messaggi xml. Capita a volte che le applicazioni message oriented abbiano una struttura a due livelli:

1. il primo livello di xml trasmette i campi generali (es il mittente, il nome del servizio, il contenuto informativo)
2. il secondo livello di xml trasmette il contenuto vero proprio ed è rappresentato da un campo del primo livello

Esempio

<message>

<sender>Giovanni</sender>

<service>invio_fattura</service>

<content><![CDATA[

<?xml version="1.0" encoding="ISO-8859-1"?>
<fattura> 	<numero>2</numero>  	<data>20080131</data> ... ...  </fattura>

]]></content>

</message>

Tale strutturazione si usa quando si vuole creare uno scheletro di comunicazione da usare per diversi servizi che vengono chiesti a dei fornitori in tempi diversi. Gli sviluppi successivi possono riutilizzare “l’infrastruttura” di comunicazione e concentrarsi solo sul contenuto senza dover configurare endpoint diversi e “menate varie”.

Una soluzione di questo tipo pone un problema di encoding particolare; infatti per evitare il famoso “Invalid byte 2 of 3-byte UTF-8 sequence” ed annessi e connessi è necessario capire cosa succede se il messaggio viene trasportato via rete tramite protocollo http.

Il contenuto del tag content è a tutti gli effetti una stringa che, nel caso di cdata non viene toccata (si può inserire il contenuto facendo l’escaping dei caratteri, ma il messaggio diventa molto meno leggibile ad occhio nudo). La domanda da porsi è: se all’interno di CDATA ci sono dei caratteri accentati con che encoding vengono trasmessi?

La risposta è: a priori non è dato saperlo. Eh? Perchè?

Analizziamo il “viaggio” del messaggio; se si usa un web service client (tipo quelli generati da AXIS) abbiamo a disposizione un metodo di un oggetto che, presi i parametri di input, crea un xml e tramite un http client, lo invia “come stringa” (è una semplificazione, ma serve per non perdersi nei dettagli) all’http server. l’http client specifica un encoding nell’header http; il server legge l’encoding e ricostruisce una stringa che rappresenta il messaggio xml. A questo punto sul server il web service può essere implementato tramite un metodo che accetta gli stessi parametri del client (stile AXIS) o viene fornito un albero JDOM, DOM4J o XOM da cui prelevare i dati (stile Spring Web Services). In entrambi i casi il contenuto del campo content è accedibile come stringa. Stringa = sequenza di caratteri per cui non esiste problema di encoding, la conversione byte-caratteri è stata presa in carico dall’http server o dalla libreria che implementa i meccanismi di web service.

Che problemi ci sono allora?

Che il contenuto di content deve essere dato in pasto alla nostra libreria XML preferita che crea un albero o una serie di eventi; ma nell’header del messaggio contenuto in content è specificato un encoding che non ha più alcun legame con l’encoding reale. Tale informazione sull’encoding va ignorata.

Come si fa?

La soluzione l’ho citata nel post precedente: si usa un reader al posto di un input stream.

Ricetta facile e veloce: se dobbiamo dare in pasto ad una libreria xml del contenuto che proviene da una stringa utilizziamo un reader e non un inputstream

In questo articolo porrò le fondamenta di quello che sarà l’argomento di un altro post, l’xml all’interno dell’xml.

Capire la differenza fra Reader ed InputStream è fondamentale se si vuole riuscire ad evitare errori di vario tipo legati all’encoding.

Quel e’ la differenza fra InputStream e Reader?

Il primo ragiona in byte, il secondo in caratteri che tradotto significa: il primo non fa il decoding il secondo sì. (per OutputStream e Writer si applica il concetto complementare di encoding)

La differenza è “tutta” qui. Vediamo cosa significa: se in un programma che tratta XML (dove quindi l’encoding/decoding è richiesto) passo un InputStream cosa fa la libreria(DOM4J per esempio)? Legge la prima riga, il prologo con <?xml cerca l’encoding e costruisce un Reader che trasforma i byte in caratteri secondo le regole del charset. Se invece alla libreria passo un reader, essa comincia  caricare i caratteri senza controllare l’encoding del prologo.

Quindi in un caso il prologo viene letto (e quindi viene fatta una operazione di decoding) nell’altro viene ignorato (il decoding lo ha già fatto il reader).

Sapere che esistono queste due possibilità è molto utile infatti ci sono casi dove il prologo e la relativa informazione sull’encoding deve essere letta (per esempio quando si legge da file system), mentre ce ne sono altri in cui deve essere ignorata (per esempio quando l’xml viene passato come stringa).

Nel prossimo post affronterò l’ulteriore complicazione dell’xml dentro xml, caso che può essere abbastanza frequente nel caso di webservice che si scambiano nessaggi.

Qualche giorno fa ho avuto una discussione, a volte anche abbastanza accesa, su come ottimizzare uno specifico modulo di un prodotto in fase di sviluppo.

Problema: da un nodo centrale si devono contattare n server comporaneamente (tramite webservice) per poi assemblare le risposte ottenute. Le richieste dal nodo centrale sono originate da una operazione compiuta dall’utente per cui ci possono essere m richieste che originano n*m richieste remote.

La persona (mooolto tecnica) che si era fatta carico del problema sosteneva una poszione di questo tipo: le operazioni di invocazione non sono altro che attesa su una socket, se al posto di generare n*m thread uso i meccanismi di comunicazione non bloccante sulle socket (non blocking I/O) risparmio risorse e l’applicazione è più scalabile.

Il ragionamento sembra filare, ma c’è un problema di fondo (più di uno in realtà, ma quello veramente importante è uno solo):

Di quanto l’applicazione è più scalabile? quanto costa in termini di complessità di codice usare il non blocking I/O rispetto ad un “semplice” thread?

Senza una misurazione effettiva si rimane nell’ambito delle opinioni, con un test case (anche molto semplice) ci si muove nel mondo dei fatti.

Per cui la prima cosa che ho chiesto è: quanto migliora con il non blocking I/O in termini di prestazioni e di utilizzo di memoria?

Dopo vari test case, la conclusione è stata che l’applicazione di test (simulando un carico circa 1000 thread) multithtread e quella con non blocking I/O avevano circa le stesse prestazioni (qualche punto precentuale a favore del multithread) in termini di prestazioni e quella con i thread occupava diversi mega di memoria in più (qualche decina quando c’era un numero consistente di thread). La macchina di produzione sarà dedicata all’application server ed avrà 4GB di RAM. Cosa sono 2o mega in più, specialmente considerando che stano alle previsioni attuali sarà difficilissimo superare i 300 thread? Soprattutto il codice multithread risulta più pulito e più facile da manutere in futuro (considerato anche il fatto che non tutto sanno manegiare a dovere le api bel non blocking I/O).

Conclusione: prima di dire è più veloce/scalabile/etc  questo rispetto a quello è necessario avere dei fatti a supporto, perchè finchè ci si limita alle opinioni (per quanto sensate e intuitivamente corrette) non si può essere veramente sicuri di quello che si dice. La semplice condivisione di un test case vale più di mille parole ed è infinitamente più istruttiva sia per chi lo scrive sia per chi lo legge. Anche perchè  le applicazioni sono spesso complesse e devono tenere conto del fatto che ormai l’hardware è sempre multiprocessore (e lo sarà sempre di più); per cui il miglioramento presunto va inquadarato in ottica costi/benefici (e i costi, a meno di errori grossolani, ci sono quasi sempre). Il mio ultimo pensiero va a quel team di sviluppo (di un sistema operativo) che era felicissimo di aver ottimizzato il tempo di esecuzione di una API del 20%; quando il loro responsabile vide il loro lavoro li guardò stupito: avevano ottimizzato il ciclo idle del sistema

Alla prossima.

Dalle statitiche del blog vedo che uno dei termini più richiesti è xml caratteri accentati. Questo posto vuole provare a dare una soluzione di come si trattano i caratteri accentati.

Supponiamo di avere una tag il cui contenuto è:

àèìòù€

e di voler creare un file xml che contenga tali caratteri.

L’esempio con DOM4J è il seguente :

import java.io.FileOutputStream;

import org.dom4j.Document;
import org.dom4j.DocumentFactory;
import org.dom4j.Element;
import org.dom4j.io.OutputFormat;
import org.dom4j.io.XMLWriter;

public class TestXMLEncodingAccento {

public static void main(String[] args) throws Exception {
Document document=DocumentFactory.getInstance().createDocument();
Element e=document.addElement(”CaratteriAccentati”);
e.setText(”àèìòù€”);
OutputFormat outformat = OutputFormat.createPrettyPrint();
outformat.setEncoding(”ISO-8859-1″);
//outformat.setEncoding(”UTF-8″);
//outformat.setEncoding(”ISO-8859-15″);
FileOutputStream fos=new FileOutputStream(”c:/temp/testaccenti.xml”);
XMLWriter writer = new XMLWriter(fos, outformat);
writer.write(document);
writer.flush();
fos.close();
}

}

Il programma non fa altro che creare una stringa con i caratteri in questione, metterli in un tag e salvare un file con un certo encoding. L’encoding è la chiave di tutto in quanto determina il valore dei byte che rappresentato il carattere che vengono poi salvati su disco. “L’equazione” è carattere->sequenza di byte dipendente dall’encoding->file.

Se proviamo ognuno dei tre tipi di encoding e ogni volta apriamo il file con un editor “evoluto” dovremmo vedere i caratteri accentati sempre visualizzati correttamente. Se proviamo ad utilizzare come output System.out il risultato dipende dall’encoding della console in uso, se coincide vediamo tutto corretto altrimenti compaiono dei caratteri strani. Se compaiono dei caratteri strani (tranne per il simbolo dell’euro che è un discorso a parte) significa che il lettore non sa gestire l’encoding, ma il file è scritto bene.

Un discorso a parte merita il simbolo dell’euro, questo compare solo nel caso di encoding UTF-8 e ISO-8859-15. Perchè? Perchè ISO-8859-1 non ha nella sua mappa di traduzione simbolo->sequenza di byte tale carattere per cui non è possibile salvare il simbolo € correttamente. ISO-8859-15 è stato fatto apposta per supportare il simbolo dell’euro (e visto che la codifica utilizza un solo byte per fare spazio all’euro è stato rimosso un altro simbolo).

Alla prossima

**If there are some non italian readers that wish to learn more about java encoding please leave a comment in english and I’ll try to post more articles (english readable) on the topic.**

Ho visto che molte delle ricerche che portano al blog hanno le parole chiava java ed encoding. Ho pensato di dedicare qualche post all’argomento.

Il primo e’: Come cambiare encoding ad un file?

Faccio copia ed incolla di un sorgente Java che preso un file con un certo encoding (da specificare esplicitamente)  ne crea una sua versione con un encoding differente.

public class FileReEncoder {

private static final int BUFFER_SIZE=2048;

public static void main(String[] args) throws Exception {
String fileNameIn=”test1″;
String fileNameOut=”test2″;
String encodingIn=”UTF-8″;
String encodingOut=”ISO-8859-1″;
File fileIn=new File(fileNameIn);
if (!fileIn.exists() || !fileIn.canRead()) {
System.err.println(”Il file ” + fileNameIn + ” non esiste o è illeggibile”);
System.exit(-1);
}
FileInputStream fis= new FileInputStream(fileIn);
InputStreamReader reader= new InputStreamReader(fis,Charset.forName(encodingIn));
try {
FileOutputStream fos=new FileOutputStream(fileNameOut);
OutputStreamWriter writer= new OutputStreamWriter(fos, Charset.forName(encodingOut));
try {
char[] bufferChar=new char[BUFFER_SIZE];
int charsRead=0;
while ((charsRead=reader.read(bufferChar))>0) {
writer.write(bufferChar, 0, charsRead);
}
} finally {
writer.close();
}
} finally {
reader.close();
}

}

}

Enjoy!

Se ci sono altre domande o cose che vorreste vedere trattate sull’argomento suggerite pure.

**If there are some non italian readers that wish to learn more about java encoding please leave a comment in english and I’ll try to post more articles (english readable) on the topic.**

Probabilmente l’ultimo trimestre è il più duro per i tecnici (ma anche per i commerciali) in quanto il tempo per centrare gli obiettivi è sempre meno e di solito la meta è distante.

Di solito si verifica la seguente situazione: i commerciali o i capi progetto per fare il budget dicono di sì a tutto o quasi ed arrivano sulla scrivania progetti impossibili. L’impossibilità principale è data dal fatto che i tempi a disposizione per tali progetti sono ridicoli. La domanda classica è perchè il progetto arriva a settembre o ottobre o più tardi invece di marzo, aprile o maggio?

Domanda inutile, tanto tutta l’azienda che conta, dal top management fino ai commerciali (che solitamente sul budget hanno premi di produzione non trascurabili) hanno in testa un unico target, centrare gli obiettivi economici.

Cosa fare? Accettare la cosa come un dato di fatto, che si ripeterà ogni anno. E’ una componente strutturale di tante aziende per cui si tratta di stringere i denti ed aiutare l’azienda a raggiungere gli obiettivi (anche se spesso il raggiungimento degli obiettivi economici non si riflette sullo stipendio del tecnico la cui mansione è assimilata alla manodopera facilmente sostituibile). Quello che a cui si deve stare molto attenti sono le possibili “fregature” (solo per il tecnico s’intende). Non mi sono mai trovato in situazioni simili, ma ho ben presente i racconti e le lamentele di tante persone che ho conosciuto e che ci sono passate; solo grazie alle loro sono uscito indenne da tali disavventure. Uno scenario classico è il seguente.

Un PM/commerciale ha un progetto in ritardo e da tale progetto deriva una parte non trascurabile (per sempio sopra il 5%) del budget aziendale, per cui ci sarà la massima volontà a centrare l’obiettivo. E’ nell’interesse di tutti, l’azienda che aumenta il fatturato, la persona prende il premio. Se ci sono cause insormontabili per cui l’obiettivo non può essere veramente centrato scatta la corsa “all’accordo”. Essa consiste nel dire, caro cliente,partner, etc, etc il tale progetto e’ in ritardo per questi motivi, va bene se mi certifichi che questa parte del progetto attualmente in sviluppo è finita ed io te la consegno fra X mesi? Dove esiste un rapporto di fiducia ci si viene sempre incontro, per cui in tanti casi la risposta è sì. Così i conti tornano, nel senso che l’azienda raggiunge gli obiettivi di bilancio, il lavoro e’ spostato di qualche mese ed il cliente ha un “credito” da giocarsi la momento buono.

Peccato che a volte quando si afferma che un lavoro è finito (anche se non è vero), anche il relativo capitolo di spesa viene chiuso. Che conseguenze ci sono?

Per il commerciale nessuna, ha centrato l’obiettivo. Per il tecnico qualche “problemino” c’è, infatti dove carica le giornate l’anno dopo se il capitolo si spesa è chiuso?

Spesso su un nuovo progetto o nella fase successiva del progetto. Pessima soluzione. Per tanti motivi.

Quello più importante è che si falsano i rapporti costi/ricavi delle attività e di conseguenza i manager prendono delle decisioni su dei dati sbagliati.

Esiste una via d’uscita? Secondo me sì. La prima cosa da fare è accordarsi in maniera chiara e precisa sull’allocazione futura dei costi dei progetti “chiusi virtualmente”. La seconda cosa è far in modo che in azienda vengano quantificate in maniera esplicita gli spostamenti di fine anno. Per un tecnico è doveroso darsi da fare per raggiungere gli obiettivi aziendali, ma faticare tanto per poi trovarsi brutte sorprese in futuro, no.

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à.