venerdì 30 dicembre 2011

Il negozio di scarpe di mio nonno



"Io appartengo a una grande azienda che produce scarpe..." disse l'ingegner Carozzi. "In questi tempi di crisi, l'azienda sta andando molto male, e sta cominciando a licenziare. Io mi guardo intorno, e credo di aver capito perchè l'azienda in cui lavoro sta fallendo: è perché noi siamo dei bravi venditori, siamo degli ottimi manager, ma non ci capiamo un gran che di scarpe! Anzi, nelle riunioni aziendali si sente spesso dire con una punta di orgoglio dai nostri capi che loro non ci capiscono molto di scarpe, del resto loro sono bravi dirigenti, bravi venditori, non importa che vendano scarpe oppure lustrini natalizi. Non importerà, d'accordo, intanto però l'azienda sta fallendo." L'ingegner Carozzi si scostò un attimo per accendersi la pipa. Fuori stava cominciando a nevicare. "Io dico queste cose con cognizione di causa, sapete." Fece una pausa di riflessione, poi continuò: "Mio nonno aveva un negozio di calzature in centro. Il suo negozio era sempre pieno di gente! E tutti erano molto sorpresi che il negozio di mio nonno fosse sempre pieno. Perché dovete sapere che mio nonno aveva un carattere difficile, era un burbero, un uomo molto pragmatico, era l'esatto contrario di un buon venditore. Lui era capace di dire a un cliente che aveva messo gli occhi su una scarpa molto costosa, che quella scarpa non era per lui, di lasciar perdere, di uscire dal negozio e risparmiare i suoi soldi. Il negozio di scarpe di mio nonno era sempre pieno perché la gente sapeva che quell'uomo burbero era davvero un intenditore di scarpe! Questo perché prima di essere un negoziante era stato un calzolaio. La gente sapeva che quando andava da lui poteva chiedere un consiglio sulla scarpa adatta a lui, e ricevere una risposta del tutto sincera e competente. La gente in quegli anni doveva risparmiare su tutto: non poteva permettersi un acquisto sbagliato! E sapeva che mio nonno gli avrebbe venduto la scarpa giusta. E il suo negozio era sempre pieno! Nonostante lui fosse un burbero, avesse un carattere difficile e non fosse tagliato per il mestiere di commerciante." L'ingegner Carozzi si voltò verso i suoi interlocutori, sorrise loro con un sorriso amaro, poi si voltò e se ne andò per la sua strada.

mercoledì 31 agosto 2011

Navigazione e geolocalizzazione

Sono a P., una città a me sconosciuta, per un meeting. Ho bisogno di una farmacia - mi sono dimenticato le aspirine a casa! Fortunatamente ho con me il mio cellulare Android. Ecco cosa faccio:

1) Apro Google. Siccome ho attivato il geolocalizzatore, la pagina visualizzata riporta chiaramente che mi trovo a P.
2) Seleziono Places
3) Da lì digito "Farmacia". Appare un elenco delle farmacie, in ordine di vicinanza.
4) Scelgo la prima e visualizzo la mappa, con le informazioni in tempo reale del traffico.
5) Ok, il traffico è leggero. Maps mi dice che ci arriverò in cinque minuti in macchina e in nove minuti a piedi! Sono in macchina, ci vado in macchina.
6) Clicko sul Navigatore, che immediatamente attiva il GPS. La voce di una signorina, in bell'italiano, mi racconta la strada da fare, nominando anche le vie.

Il tutto con un Android senza nessuno speciale software a pagamento, con una configurazione "out-of-the-box". Niente male!

Il prossimo passo è andare in un supermercato, fare la spesa, e uscire senza pagare alla cassa - ma ritrovandosi il conto esatto addebitato sulla carta di credito. (Il che non è propriamente fantascienza...)

venerdì 24 giugno 2011

Fammi ripetere con parole mie

Come Software Architect, la lezione più preziosa è stata imparare che io e lo sponsor del progetto - o meglio, si dovrebbe dire gli stakeholder - parliamo lingue differenti.

Abbiamo del resto una formazione differente, esperienze differenti, e significative difformità nei punti di vista.

Per questo la chiave del successo di un progetto software, oggi, è la chiarezza di comunicazione tra chi fornisce la tecnologia - l'Architect, appunto - e chi intende utilizzarla per raggiungere i suoi scopi di business.

Ecco perché è fondamentale che l'Architect si chieda sempre: ho capito quali sono gli obiettivi di questo progetto? Esiste uno strumento formidabile: dopo aver letto un documento, aver partecipato a una riunione, avere ascoltato le parole degli stakeholder, fermarsi un attimo e dire: "Ok, ora fammi ripetere con parole mie". Vediamo cosa ho capito davvero.

Altrettando fondamentale è chiarire fin dall'inizio che cosa la tecnologia può offrire, e che cosa non può offrire. E' bene fin da subito spianare il campo da miti e leggende. (E lo so che è difficile: è bello all'inizio avere uno sponsor che ci guarda come Bilbo Baggins guardava Gandalf nello Hobbit!)

Direi quindi che sono due le chiavi importanti per il successo di un progetto software enterprise:

1) Voglio capire bene quali sono gli obiettivi da ottenere con il sistema
2) Voglio comunicare bene cosa un sistema è in grado di offrire (e cosa no)

Le questioni tecniche, i disegni architetturali, i dettagli implementativi vengono molto dopo.

venerdì 17 giugno 2011

Basta Database!

Una domanda che non fareste mai ad un Cliente, che ha un sistema informativo con un suo potentissimo sistema di RDBMS (database relazionale, normalmente Oracle o MS Sql Server), è: "Ok, ma a cosa ti serve?"

Come a cosa serve un database? (Ti guardano come un poveretto, con tanto di occhi sgranati)... Ma non lo sai che in un database ci sono tutti i dati aziendali? Ma non lo sai che è il cuore del sistema informatico? Ma non lo sai che nessuno nemmeno osa pensare di non averne uno...

Mentre sento queste cose mi aggiro curioso tra gli utenti (solitamente disperati) di un tale eccellente sistema: sono lì che combattono con infinite tabelle, piene di dati ridondanti e infinitamente inutili, che per essere tirati fuori hanno bisogno di uno stranissimo linguaggio, perlopiù incomprensibile alle logiche umane, chiamato SQL.

La maggior parte delle aziende, per cercare di tirar fuori qualcosa da quei mostri lì, compra sistemi di Datawarehouse e Business Intelligence che costano loro un ordine di grandezza in più...

Mi aggiro tra sistemisti che sognano vacanze ai Caraibi e mondi senza computer - soprattutto senza database - e tra manager che guardano fuori dalla finestra cercando di capire con quali soldi pagare l'espertone Oracle (o quello che volete) che gli risolverà il loro maggior problema, e cioè: perché ho milioni di dati inutili e non trovo mai quelli che mi servono?

A cosa serve un database? "Ad archiviare i dati". Sono scettico. "A gestire le transazioni..." ok, ci avviciniamo. "Ad estrarre dai miei dati le informazioni che servono per il mio business..." Ah no! Ecco il punto!

Il punto è che la tecnologia delle basi di dati è nata quando i computer erano relativamente lenti, soprattutto i dischi, poco capienti e le applicazioni molto costose da scrivere, perché difficili da creare e debuggare. Perciò si è inventato un sistema altamente efficace nell'archiviare i dati (scrittura) e nel recuperarli (lettura), e questo a scapito della loro intelligibilità e facilità d'uso.

Il sistema relazionale inventato da Cobb è un sistema efficace con computer poco potenti e capienti, esattamente il contrario dei computer di cui disponiamo oggi.

Oggi possiamo tranquillamente immaginare (e realizzare!) un sistema informativo complesso senza database sotto. "E come fai ad archiviare i tuoi dati?" Li scrivo sul disco, ovvio. Sì ma in che formato?

Ecco una buona domanda. Le cui risposte possono essere almeno tre, e ricoprire con ciò gran parte delle necessità di archiviazione di un'applicazione anche di media/grande complessità.

Prima possibilità: flat file. Salviamo tutti i nostri dati in file di testo in formato flat. Esempi: il win.ini, YAML, SQLite, TextDB ecc. ecc. (http://en.wikipedia.org/wiki/Flat_file_database)

Seconda possibilità: chi ha necessità di immagazzinare relazioni gerarchiche di tipo padre-figlio, o strutture fortemente innestate, può usare il formato di testo più potente in assoluto: XML. Il che è però fin troppo per la stragrande maggioranza delle applicazioni.

Terza possibilità: ok, proprio non potete fare a meno di Oracle! Almeno lasciatelo scrivere a chi lo sa fare, e voi non sporcatevi le mani. Utilizzate dunque uno strumento di ORM - object relational mapping - che ha il compito di serializzare, deserializzare e ricercare i vostri oggetti di business in un normale database relazionale.

Quest'ultima possibilità è quella secondo me più interessante, e che spero prenda piede nelle applicazioni enterprise del prossimo lustro. L'articolo che più concisamente descrive la tecnica è questo.
Seguito dall'ottima voce su Wikipedia.

In soldoni, nelle applicazioni moderne, le attività di DDL (Data Definition Language) e DML (Data Manipulation Language) debbono essere demandate ad un apposito strato software (l'ORM appunto) che le svolge al meglio e in modo "trasparente" per l'utente. In questo caso ciò che conta maggiormente nell'applicativo non è più il modello concettuale dei dati, ma il modello concettuale degli oggetti (sottinteso, di business, cioè a dire: web services, remote procedure calls e quant'altro). Il vantaggio consiste, di fatto, nella drastica diminuzione delle risorse necessarie al disegno e allo sviluppo della base dati - fino quasi ad annullarle.

Per Java, il miglior strumento ORM è senz'altro Hibernate, mentre per il mondo Microsoft è l'Entity Framework

Entrambi sono ottimi punti di partenza per dire definitivamente addio agli odiati database.

giovedì 24 marzo 2011

Testo e font sfocati in IE9 e Firefox 4

Ok, vi siete scaricati Internet Explorer 9 o Firefox 4 o superiori e, dopo un iniziale periodo di eccitazione mistica, avete pensato di avere bisogno di un nuovo paio di occhiali! "Ma sono io, o si vede tutto un po' sfocato?"

Il fatto è che i nuovi engine grafici dei browser di ultima generazione utilizzano di default - quando la trovano - l'accelerazione hardware via scheda grafica. La rappresentazione di un documento HTML non è più la commistione di font raster (cioè disegnati pixel per pixel) e immagini, ma un'unica immagine che si va componendo mentre la pagina viene renderizzata. L'effetto "sfocatura" è dovuto al fatto che i font non sono più raster, ma vettoriali, e utilizzano le primitive grafiche per essere renderizzati - proprio come accade, ad esempio, nelle applicazioni Silverlight (WPF e compagnia).

Ok, ma io adesso come faccio? E' inaccettabile che lo schermo si veda "peggio" che con IE8 o Firefox 3.

Avete due possibilità: la prima è quella di disabilitare l'accelerazione hardware, ad es. in Firefox 4 sotto Opzioni / Navigazione / Utilizza l'accelerazione hardware quando disponibile. Chiaramente con questo vi giocate una delle più importanti innovazioni dei browser di ultima generazione, cioè l'utilizzo della GPU nel rendering delle pagine, con un sostanziale aumento delle performance.

Oppure potreste fare il "fine tuning" dell'engine di renderizzazione grafica dei font vettoriali. In Windows XP andando su questo sito:

http://www.microsoft.com/typography/cleartype/tuner/step1.aspx

Invece su Vista e 7, semplicemente da Menù Start, scrivendo "Ottimizzazione caratteri Clear Type"

(Io ho seguito quest'ultima strada e sono soddisfatto, però è questione di gusti)