Vita da tecnici

Dopo aver finito la mia prima applicazione in PHP ed averla messa on-line voglio tornare sull’argomento del confronto fra le due piattaforme.

Lo scopo del post è rispondere alla famosa domanda: per scrivere la mia applicazione web devo usare java o php?

Caso n.1: se l’applicazione andrà installata sotto forma di hosting la scelta è praticamente obbligata php

Caso n.2: se chi scrive l’applicazione non ha fatto studi informatici o non ha anni di esperienza nella programmazione la scelta  consigliata è php

Caso n.3 se si sta cercando di fare del content managament (ovvero pubblicazione di contenuti tipo pagine web) la scelta consigliata è quella di guardare se esiste un programma php (e ce ne sono veramente TANTI) che fa al caso vostro.

Caso n.4 se dovete scrivere una applicazione che è al 50% HTML e 50% web service la scelta consigliata è Java

Caso n.5 se dovete fare progetti di cooperazione applicativa (secondo lo standard CNIPA) la scelta obbligata è java

Caso n.6 se dovete produrre applicazioni “corpose” Oracle based la scelta caldamente consigliata è Java

Solo i casi n.1 e 5 sono “obbligatori”, gli altri sono suggerimenti. Al termine della mia esperienza posso confermare che se si vuole scrivere una applicazione senza usare prodotti già fatti, ma solo librerie(es Spring framework piuttosto che Zend framework) Java è la scelta a mio avviso più produttiva (a patto di ipotizzare che le persone che ci lavorano abbiano la stessa produttività in entrambi gli ambienti) e matura, in quanto a livello di librerie web (e NON di prodotti tipo portali,CMS, etc) Java offre delle soluzioni più complete e più sofisticate (per esempio la gestione delle transazioni via AOP in Spring o i custom tag Spring MVC o Struts).

Dopo aver spiegato perchè, secondo me, architettura e sviluppo software non si possono paragonare per quanto riguarda il processo di creazione del prodotto continuo le riflessioni estendole alla fase successiva: il post vendita.

Se nel caso della produzione la metafora poteva sotto qualche aspetto reggere, una volta che si parla di manutenzione la metafora è inapplicabile.

Provo ad elencare le differenze con una serie di domande.

Vi immaginate di dover chiamare per forza l’artigiano che vi ha fatto il lavoro (elettricista, muratore, idraulico, etc) per qualsiasi modifica?

Vi immaginate di dover pagare un contratto di assistenza annuale per i problemi con l’uso della casa?

Vi immaginate di sentirvi dire dopo tre/cinque anni che la vostra casa è obsoleta e che ne vuole una nuova?

Mi pare che sia sufficiente.

E’ già da diverso tempo che ho in testa questo argomento. Spesso la progettazione e lo sviluppo vengono paragonate all’architettura, da cui vengono presi a prestito vari modelli. Un esempio su tutti è la qualifica software architect.

A mio parere assimilare il processo di realizzazione di un software al processo di realizzazione di un edificio è decisamente fuorviante e ci sono più divergenze che similitudini.

Consideriamo come viene fatto un edificio: si parte dal progetto che viene approvato (a volte accompagnato della presentazione di un plastico) e da lì si comincia a costruire. Una volta che si comincia alcune cose diventano immutabili, per esempio non è più possibile (se non con costi ed oneri esagerati) spostare la costruzione o cambiare forma alle fondamenta. E’ possibile cambiare i particolari, le collocazioni di alcuni muri, ma la natura dello stabile rimane quella del progetto. La costruzione viene fatta da una serie di figure completamente diverse e spesso molto specializzate, chi tira su i muri difficilmente monta gli infissi o fa l’impianto elettrico o quello idraulico o posa i pavimenti. L’architetto o l’ingegnere o il geometra vanno in cantiere per assicurarsi che il direttore lavori segua fedelmente il progetto, ma sicuramente “non vanno alla betoniera”. Un altro fattore importante è l’interscambiabilità, un muratore un giorno fa un pezzo di muro che il giorno dopo può essere finito da un collega, senza particolari passaggi di consegna.

In sostanza tutto procede secondo logiche preordinate e basate su standard accettati. (Se qualcuno pensa che nei cantieri edili ci sia il caos legga quello che segue).

Nell’informatica invece non accade nulla o quasi di tutto questo. Il committente spesso aprrova un progetto non conoscendo i dettagli di cosa verrà fuori e capisce cosa vuole solo quando vede funzionare un pezzo di software. Ne risulta che spesso è necessario un ciclo di prototipi e rilasci per tarare il tiro. Chi di noi andrebbe ogni giorno in un cantiere cantiere che ha commissionato dicendo “mi sposti la finestra più in qua” o “le piastrelle che ho scelto e che avete montato non mi piacciono più” o ancora “mi sposta la casa altri di 30cm dalla strada”? aggiungendo “tanto quanto vuoi che costi”?

Chi costruisce una casa sa benissimo che dopo che un pezzo è stato fatto c’è un costo ben preciso per buttare giù e rifare. Chi commissiona un software evidentemente no.

Un altro aspetto è la specializzazione che nell’informatica è molto meno sviluppata, proviamo a lasciare una classe o anche una funzione a metà ed assegnare ad un altro programmatore il compito di finirla; quanto tempo ci vuole per la presa in carico di quanto già fatto? Inoltre spesso unprogrammatore svolge diversi compiti (design dell’interfaccia grafica, modellazione/definizione di parti della base dati, etc)

Un altro indicatore che indica quanto la produzione del software sia diversa e più arretrata rispetto alle costruzioni edili è la presenza dei building block ovvero dei componenti riusabili. Nell’edilizia si usano, mattoni porte e finestre già fatte, nell’informatica molto meno. Cosa succederebbe se un giorno entraste nel cantiene dove stanno costruendo casa vostra e vedeste un muratore che con un camino acceso fabbrica dei mattoni? Immaginiamo il dialogo:

Noi: Buongiorno, cosa sta facendo?

Muratore: Buongiorno, sto facendo i mattoni per costruire la casa

Noi: Perchè?

Muratore: Sa, quelli che sono in commercio non mipiacciono tanto, poi hanno quegli spigoli così ruvidi, me li faccio io così faccio prima e sono come mi servono.

Il risultato sarebbe: fuori dal cantiere a calci nel sedere.

Nell’informatica molto pochi si scandalizzano se qualcuno nel 2008 si fa un package di logging in java o in .net eppure la fine dovrebbe essere quella del mutatore sopra citato.

Un’altra differenza sostanziale è che chi comincia a programmare fa una carriera in cui pian piano diventa coordinatore e poi project manager o commerciale; quanti muratori-architetetti o elettricisti-ingegneri conosciamo?

Si conclude qui questa riflessione sul processo di costruzione software e sulle sue differenze rispetto al processo di costruzione edile. Tutti i fattori elencati fanno parte della fase costruzione, manca ancora la fase “manutenzione e post vendita”, ma credo che già si intuisca come parlare di software architect sia una cosa che non ha fondamento reale. Nei prossimi articoli proverò ad illustrare altre differenze e delle metafore più appropriate.

L’idea di fare un paragone fra VB6 e Java mi è venuta da una serie di esperienze recenti dove ho dovuto modificare o analizzare codice VB6 e java scritto da altre persone. Erano almeno 6 anni che non usavo VB6 e un ritorno al passato mi ha fatto capire le ragioni del suo successo. La prima cosa che ho notato del codice VB6 è stata la sua densità, ovvero quasi tutte le righe di codice erano dedicate a svolgere il compito specifico per cui era pensato il software; il codice Java che ho dovuto analizzare invece era l’opposto, per trovare le classi che svolgevano la funzionalità applicativa ho devuto aprire almeno 10 classi scritte per mettere le funzionalità applicative dentro il framework.

Questo mi ha fatto riflettere perchè in parte corrispondeva alle mie esperienze lavorative precedenti, da cui sembra emergere che i programmatori Java tendano a farsi tutto in casa; ovvero il logging, il mapping fra oggetti e RDBMS e così via. In VB no, codice e codice che fa le query e gestisce gli eventi utente, librerie custom zero o quasi (se non wrapper per usare meglio le funzionalità esistenti).

Credo che la ragione del VB6 sia stata proprio la produttività ovvero la tendenza con cui il linguaggio e l’ambiente di sviluppo portavano il programmatore a concentrarsi sulle funzionalità applicative. Credo che la situazione di Java nel 2008 sia QUASI come quella di VB6 nel 2000 nel senso che ormai ci sono tutte le librerie per concentrarsi solo sull’implemetazione degli aspetti funzionali.

Nonostante tutto non rimpiango i giorni in cui lavoravo in VB6 (anzi lo considero una sorta di peccato orginale). La ragione è molto semplice: in VB non si ha il controllo di niente, ovvero basta cominciare a complicare un po’ la logica applicativa per trovarsi intricati in una serie di eventi che rendono difficile stabilire un comportamento completamente deterministico. In Java il programmatore ha il controllo di quello che accade e può influire in maniera molto più efficace sul flusso di esecuzione. Questo credo che sia stata una delle ragioni del successo di Java (nei confronti di VB), il senso di sicurezza che viene dato al programmatore. Un’altra ragione è sicuramente stata il mix di eleganza/potenza della soluzione servlet+jsp che ha permesso a Java di diventare il riferimento in ambito server side. La risposta Microsoft, ovvero .net ha superato tutti i problemi tecnici precedenti e sotto alcuni punti di vista è superiore a Java (da quel poco che ho visto di C#, mi sembra una versione di Java rivista e migliorata), ma con il vincolo non indifferente di rimanere ancorata alla piattaforma Windows. Senza considerare che il codice VB6 va riscritto per essere convertito a .net per cui se si decide di cambiare il salto verso Java non è così doloroso rispetto a quello .net.

Negli ultimi mesi ho speso parecchie ore ad imparare ed usare il php, per cui ora che sono arrivato ad una sua discreta conoscenza vorrei provare a buttare giù qualche riflessione. Dal punto di vista del linguaggio la differenza più grande è che Java è tipizzato mentre PHP no. La seconda differenza è che in Java le variabili vanno dichiarate, in PHP no. A mio modo di vedere sono due grossi svantaggi a favore del PHP, perchè rendono più facile la scrittura di codice bacato. Una (almeno per me) stranezza del PHP è che i nomi delle variabili sono case sensitive, mentre quelli delle funzioni no. Anche questo fattore crea problemi almeno per chi è alle prime armi. La cosa invece che apprezzo del PHP è che è interpretato e quindi non devo riavviare Apache quando cambio il codice. Un’altra cosa positiva sempre legata alla dinamicità del php è che si sente molto meno l’esigenza di file di configurazione, in quanto il codice può essere la configurazione del sistema (si cambiano i valori delle variabili e via); in java ormai se non ci sono quintali di file XML si riesce a fare ben poco. E’ vero che questo potrebbe essere un problema legato più alle librerie che al linguaggio, ma se Java potesse essere dinamico come PHP credo che la configurazione di molte applicazioni sarebbe diversa. Per quanto riguarda il discorso legato alla produttività (che è stato il primo aspetto che mi ha spinto ad usare PHP) devo dire che il maggior peso lo hanno le librerie e che dipende da cosa si deve fare. Se si devono scrivere applicazioni web da zero e si dispone già di un server con Java (e di una struttura sistemistica dietro) secondo me Java aiuta di più. Se invece il target è un sito dinamico in hosting/housing presso un provider internet allora PHP è una scelta obbligata in quanto il supporto Java è pressochè nullo (a meno che non vogliate gestire un server dedicato o virtuale). PHP ha il grosso vantaggio di offrire una serie di prodotti gratuiti per quasi tutti i tipi di applicazioni. Basta cercare PHP CMS su google per rendersi conto del grosso vantaggio rispetto a Java. La (presunta) maggiore produttività vantata dagli ambienti PHP è dovuta essenzialmente alla presenza di applicazioni già fatte che consentono di non partire da zero. Le controparti in Java esistono, ma sono molto rare e molto più complesse (e solitamente si portano dietro mega e mega di Jar). Se dovessi scrivere una applicazione da zero e fare uso solo di librerie e non di prodotti esistenti allora Java, almeno per chi lo conosce e usa le librerie esistenti senza riscrivere ogni volta le cose da zero è la scelta migliore. In questo caso sono le librerie a fare la differenza: io posso dire a ragion veduta che SpringMVC offre un insieme di funzionalità nettamente maggiori rispetto allo Zend framework (sempre MVC). E’ vero che Zend è un framework più giovane, ma se devo sviluppare adesso (e consegnare per ieri)…….

Alla prossima dove parlerò di VB6.

Si conclude con questo articolo la panoramica sull’encoding in Java e sulle ragioni delle eccezioni che spesso si incontrano nel fare il parsing dei file xml.

Questo ultimo articolo è dedicato alla fonte più ricorrente di tali errori. la chiamata del metodo getBytes della classe String senza parametri (parametri nella getBytes?? eh sì, esite anche la getBytes che accetta un argomento). L’esperienza mi insegna che dove c’è una getBytes() e del parsing xml prima o poi compaiono errodi di encoding. Perchè?

Perchè effettua l’encoding usando il charset della piattaforma su cui gira java e quindi varia da sistema operativo a sistema operativo. Chi riceve la sequenza di caratteri tradotta in byte non sa che encoding è stato usato, per cui si può solo indovinare. Se proprio serve serializzare dei caratteri in uno stream di byte la prima cosa da fare è concordare l’encoding in modo che chi riceve e chi trasmette possa scambiarsi i dati. Consiglio di utilizzare UTF-8 che consente di inviare caratteri di vario tipo (anche quelli non europei). Neanche a farlo apposta in questi giorni mi sono scontrato con del mio codice (sigh) che per fare il parsing di un file xml richiede come parametro un InputStream; peccato che la funzione chiamante passasse una stringa. Per passare da una stringa ad un inputstream si fa getBytes e poi si passa il risultato ad un ByteArrayInputStream. E zac!! ci si espone ad errori di encoding perchè i parser leggono da InputStream l’encoding da utilizzare che non c’entra nulla con quello dello stream che è ottenuto da una getBytes. La soluzione è di aggiungere un metodo che accetta come parametro un reader e usare un StringReader.

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.