.NET Architectonics

In Italia non esiste una classe dirigente che capisca l'importanza del software. Questa classe dirigente--a cominciare dal piu tennologico e italiota dei primi ministri--si riempie la bocca di cose-da-cominciare-a-fare e di cose-da-smettere-di-fare ma non va mai oltre il paroleggio. E le parole, anche quelle dorate di uno "ubiquitous language" perfetto, restano parole e non diventano quasi mai implementazione. La mia riflessione è che questo accada certamente perché la politica è un mestiere con forti tradizioni di famiglia. Ma andando oltre, provando ad avvicinarsi al cuore del problema, io mi azzarderei a dire che accade perché nessuno sa bene cosa sia il software e a cosa serva. E nessuno ha idea di quanto sia vitale. E nessuno si azzarda a dotarsi di advisor giusti. Gli advisor ci sono ma sono pescati tra coloro che non sono riusciti a fare politica. Se già un politico è scarso, l'advisor di un politico è ancora più scarso. Entri in un ospedale--almeno un grande ospedale--e ti rendi conto che le procedure ci sono; che gli operatori seguono delle regole di business chiare e definite. Ti rendi pure conto che quelle regole determinano processi che funzionano. E quando ci sono storture e brutture è soprattutto per l'ossessione burocratica e numerica dei costi. E ti rendi conto, però, che queste regole di business e questi processi sono implementati come se fossimo fermi al 1980. E' tutto di carta--ed è un costo. E' tutto un tracciare di carta--ed un doppio costo. E' tutto di una lentezza esasperante e burocratica--ed un costo. Così finisce che la burocrazia ritarda l'intervento se per caso il nome del medico curante non è scritto a penna sulla cartella di carta. E però non ti fanno entrare se non hai la tessera sanitaria. E la tessera sanitaria viene usata, udite udite, solo per fare una fotocopia. Follia. C'è sulla gazzetta ufficiale firmata da monti (!!!) l'istituzione della cartella clinica elettronica. Ma nessuno al ministero ha mai fatto un passo per capire come implementarla. Cioè monti (o chi per lui) si limita a dire dal 1. gennaio entra in vigore la cartella elettronica. Cazzi vostri. E comimcia un "cazzi vostri" burocratico che prima o poi raggiunge la foglia del grafo. Ma la foglia non può fare nulla. E nulla si fa. Sono stati fatti timidi tentativi di implementazione, ma ciascuna ASL ha chiamato la sua software house di fiducia e si sono arenati per manifesta incapacità di gestire un progetto "così complesso". Ma come "ciascuna ASL"? Già, proprio così: niente centralizzazione. Eppure il software complesso nel mondo reale esiste e viene scritto; e avviene anche in Italia. Basta prendere le persone giuste, con skills reali e misurabili, prenderli dal mondo reale e non dal sottobosco della politica e pagarli come si deve per fargli elaborare un progetto. I costi? Follia. Giusto per dare un'idea: le mie tariffe (altissime per gli standard italiani, ma nella media europea) produrrebbero un costo di gran lunga inferiore (!!!) a quanto si paga normalmente nel sottobosco della politica; per il nulla. Si vede che siamo un paese di letterati: tutti devono aver letto i pilastri della terra di Ken Follett. Dove un muratore, Tom, pagato da un priore costruisce una cattedrale. A dire il vero, Tom costruisce mezza cattedrale. E la cattedrale poi crolla. Ecco, appunto. Ma quello era il medioevo; noi saremmo nel 2015.

Autsursing all'italiana è l'atto di "ricorrere ad altre imprese per lo svolgimento di alcune fasi del processo produttivo" delegando COMPLETAMENTE ad esse tempistica (salvo vaghe alzate di voce), documentazione e soprattutto controllo di qualità. In sostanza, un'azienda trova più comodo pagare e lavarsi le mani dell'implementazione di parte dell'infrastruttura del proprio business.

Stando a Wikipedia e ai vaghi ricordi liceali, la tassonomia è la disciplina della classificazione. Twitter Bootstrap fa proprio quello,né più meno di Linneo che se ben ricordo si applicò alla classificazione delle specie animali e vegetali.

Poteva anche farlo un'altro framework CSS/JS/HTML ma alla fine ciò che serviva al popolo web era una lista verosimile di elementi HTML, di quelli che si usano oggi e non di quelli che si sarebbero dovuti usare in una certa maniera nei primi anni 80.

HTML ha vinto alla grande la battaglia--a dire il vero poco più di una scaramuccia--con le orde del cosiddetto RIA. Credo fosse l'ultima mia volta ad un Community Days molti anni fa quando mi lanciai nella profetica visione di un mondo che usa XAML invece di HTML e C# invece di JavaScript. La visione storica era assolutamente veritiera; ma gli strumenti che si sono affermati sono stati altri. Ma se ci pensate, Twitter Bootstrap eleva HTML al rango di un linguaggio più alto livello anche se non complesso come il super-ingegnerizzato XAML. E il JavaScript viene arricchito da framework che più o meno simulano un linguaggio di più alto livello di astrazione.

Twitter Bootstrap ci dice due cose essenziali.

1. Le pagine web oggi hanno bisogno di elementi che in HTML non ci sono, ma si possono creare. Bootstrap non solo dice quali ma dice pure come debbano essere creati. E lo fa solo con CSS, HTML e un pizzico di jQuery tra l'altro operando una selezione tra le quintalate di plugin che fanno la stessa cosa. Per ogni nuovo elemento--drop-down, breadcrumb, pager, tab, carousel, modal che sia--ci dice il layout HTML e come programmarlo e quali siano gli eventi intercettabili.
2. Le pagine web devono essere responsive. E integrando meccanismi HTML responsive al suo interno forse Bootstrap riesce a trovare le parole giuste per spiegare che mobile web è altro da mobile-first. E che mobile-first è solo approssimazione.

Non è sorprendente che in molti casi sia sufficiente avere un sito che più o meno si vede su mobile. In questi casi, Bootstrap fa un eccellente lavoro. Però al tempo stesso divenendo responsive un fatto automatico e naturale diventa più facile per tutti capire quando ci vuole qualcosa di più--ovvero server-side detection di capabilities e classificazione delle view più o meno secondo i breakpoint di Bootstrap.

PS: Quando si parla di server-side detection di dispositivi NON si parla di avere una view HTML per ogni accidenti di telefono né di farsi a mano il parsing delle UA string. Si parla di usare  strumenti che dicano se un certo browser appartiene ad una certa classe: smartphone, tablet, etc. Solo che rispetto a CSS media queries ci sono centinaia di capability su cui differenziare HTML e anche CSS e JavaScript.

 

 

 

Casualmente mi imbatto in un post di Mauro Servienti dall'intrigante titolo "I dev dovrebbero". Il punto che emerge è che il  codice--almeno nella maggior parte dei casi--influisce per una piccola parte sul successo del progetto.

Chiaramente Mauro generalizza, e di sicuro non si può dire che l'affermazione sia un falso storico. Il commento più appropriato al solito sarebbe il classico "Dipende". Tuttavia la ragione che mi spinge a commentare in un altro post è che nel primo capitolo della nuova edizione di MS .NET Architecting Applications for the Enterprise (casualmente nel momento in cui scrivo #7 su Amazon tra i libri .NET a cinque anni--cinque--dalla pubblicazione) c'è un riferimento al ruolo del codice nel successo di un progetto.

 

If you ask the question "What does make projects fail?" then probably the most common answer you receive will trace failures back to business-related issues such as missing requirements, inadequate project management, wrong cost estimates, lack of communication and even incompatibility between people in the various teams. You hardly see the perception that bad code may hurt.  #naa4e

E' interessante notare come Mauro faccia in un commento l'esempio della centralina di un'automobile--per chi è importante la realizzazione tecnica. Ecco, la ciccia sta tutta qua.

Un'autovettura non si sfascia quasi mai; solo rarissimamente ha bugs e come nel software il bug si aggiusta. A differenza del software, un'autovettura rimane quella, funziona e non richiede cambiamenti al motore e i cambiamenti fatti alla carrozzeria sono disaccoppiati dal motore.

Ma se un'auto dovesse essere rimontata spesso, aggiustata di continuo, fatta evolvere ... beh anche la centralina avrebbe il suo perché.

L'auto è in un certo senso code-that-just-works. Purché funzioni, ci si può accontentare anche del primo livello di maturità CMMI--basta funziona. E--facile battuta gratuita--le macchine tedesche hanno di solito un livello CMMI più alto di altre macchine. Ma se devi metterci le mani dentro anche la qualità del codice ha un costo; anzi soprattutto la qualita del codice è il costo.

 

 

 

 

 

Tutti abbiamo o avremo molto presto il problema di scrivere nel minor tempo possibile applicazioni mobile per almeno due piattaforme, forse tre. Inutile dire che due delle piattaforme sono in un qualche ordine dettato dal business e sono iOS e Android; la terza piattaforma è altrettanto ovviamente Windows Phone. Quali opzioni abbiamo oggi per ridurre il costo di sviluppo portandolo al di sotto della soglia data dalla semplice somma dei costi di sviluppo per ciascuna piattaforma? Di opzioni ce n’è almeno tre: Xamarin Studio, una qualsivoglia implementazione di Cordova e Appcelerator Titanium. In questo post mi limito ad un confronto diretto tra Xamarin Studio e PhoneGap, l’implementazione più conosciuta (ma non certo l’unica) della piattaforma open-source Cordova.

Xamarin Studio è un IDE separato, addirittura disponibile come estensione di Visual Studio, che permette di scrivere applicazioni per iOS e Android. È disponibile per Windows e Mac. Le applicazioni si basano sugli SDK nativi delle piattaforme ma la API esposta al programmatore è essenzialmente una variante del .NET Framework. Si trovano a disposizione classi ad hoc per la piattaforma target e classi con la stessa interfaccia di quelle del .NET Framework. Il linguaggio di programmazione è C#. La parte “magica” della soluzione Xamarin è che il compilatore rimappa le chiamate alle classi C# su funzionalità base della piattaforma sottostante e produce un eseguibile ARM imfiocchettato come un bundle iOS o Android.

L’applicazione che viene generata è una classica applicazione nativa in cui la struttura—presentation e business logic—viene sviluppata nello stesso modo di una analoga applicazione nativa scritta usando direttamente gli SDK della piattaforma. PhoneGap è una implementazione di Cordova—la piattaforma open-source attualmente gestita da Apache Software Foundation e originariamente basata sul prodotto PhoneGap acquistato da Adobe nel 2011. Oggi PhoneGap è semplicemente una distribuzione Cordova gestita da Adobe e paragonabile a Icenium di Telerik e PhoneJS di Devxpress. L’applicazione che viene generata è una applicazione nativa a tutti gli effetti. Lo sviluppo, tuttavia, è basato su HTML, CSS e JavaScript.

Un’applicazione PhoneGap è semplicemente una collezione di pagine HTML che, lette dalle risorse dell’applicazione nativa, girano dentro una WebView a tutto schermo. Dal punto di vista della struttura fisica l’applicazione è basata su una sola view (o activity secondo il gergo Android). Tutto ciò che accade viene gestito via JavaScript, codificato via HTML e sottoposto ai vincoli e alle performance del browser del dispositivo. Tanto un’applicazione Xamarin che un’applicazione PhoneGap sono perfettamente in linea con le direttive Apple e sono approvate o respinte unicamente sulla base di quello che fanno o non fanno.

Un’applicazione creata con Xamarin Studio ha il solo difetto di essere un tantino grossa come dimensione visto il peso specifico del runtime Mono che si porta appresso. Per il resto non presenta problematiche particolari e nella stragrande maggioranza dei casi (per non dire sempre) non si riscontrano penalità di alcun tipo. Un’applicazione creata con PhoneGap (o simili) è strutturalmente soggetta al dazio della performance. Già la semplice navigazione da pagina a pagina dà una misura concreta di ciò. Si può navigare seguendo un click e lasciando il browser a caricare la pagina successiva magari dalla cache: niente animazione, ed è il modo più veloce, oppure con animazione JavaScript e il rischio di movimenti a singhiozzo su quasi tutti i device. Per dirla tutta, un’applicazione PhoneGap realistica è lenta e poco fluida se paragonata ad una nativa. Punto. Tuttavia, la minore velocità e fluidità non la rendono necessariamente inutilizzabile o inutile.

Cosa scegliere?

Il punto fondamentale dello sviluppo mobile non è tanto nell’abbattimento dei costi di N-1 piattaforme quanto nel taglio lineare dei costi di sviluppo per piattaforma. Il totale del costo di sviluppo per N piattaforme non sarà mai uguale al costo unitario più un quid: il resto è noia. La sostenibilità dello sviluppo mobile passa per strumenti intelligenti capaci di far scrivere la stessa app in una frazione del tempo per ciascuna piattaforma e nell’individuazione di forme di riuso di codice di business. In questo contesto trovo che il backend sia un canale importante—per molte app mobile la logica che serve può tranquillamente stare sul server e viaggiare solo online. Il grosso del mobile è presentation e presentation e UX devono essere massimizzati perché il risultato sia accattivante. In questo contesto l’applicabilità di PhoneGap si riduce. Io scelgo Xamarin.