A noi c'ha rovinato l'autsursing

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.

Bootstrap e la tassonomia

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.

 

 

 

Il valore del codice

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.

 

 

 

 

 

Xamarin vs. PhoneGap

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.
«ottobre»
domlunmarmergiovensab
2829301234
567891011
12131415161718
19202122232425
2627282930311
2345678