I benefattori

Osservando le nuove offerte in campo dello sviluppo, vedo strumenti cross platform sopratutto per i cellulari.
Ho parlato con un amico, titolare di una importante software house, il quale mi diceva che stava cercando uno strumento per scrivere il codice una volta sola per Android e iOS.
Scrivere il codice una volta sola vuol dire risparmiare, avere una base unica sulla quale fare le modifiche, vuol dire tagliare i costi di produzione del proprio prodotto e raggiungere un target di clienti il più ampio possibile.

Uso Java dalla versione 1.0.1beta su OS/2 Warp, che i più giovani forse nemmeno ricordano. Dovrei sentirmi inorgoglito del fatto che oggi sempre più persone riconoscano che avevo ragione, che è importante non escludere dei clienti possibili, rispettando le loro scelte, perché il sistema operativo è parte importante del modo di lavorare di una persona e una persona lavora diverse ore al giorno...
Ricordo il dileggio di chi mi faceva notare che Microsoft era la più forte, che il mercato era saldamente nelle sue mani e gli altri erano ininfluenti. A onor del vero oggi lo scenario delle piattaforme mobili è ben diverso, molto più variegato e probabilmente gli stessi che tempo fa imparavano a usare VisualBasic e si sentivano Grandi Programmatori non si preoccuperebbero minimamente di studiare HTML, JavaScript, Java ecc... se il loro campione da seguire oggi fosse ancora il dominatore assoluto delle percentuali di installato, come negli anni '90. A loro vorrei ricordare che senza Java non ci sarebbe nemmeno C#, tentativo fallito di Microsoft di copiare una tecnologia allora migliore della loro. Oggi C# è un ottimo strumento per sviluppare su piattaforma Microsoft e gli altri mercati desktop sono ininfluenti, diverso invece è il discorso per quanto riguarda il mercato mobile.

Invece io non sono più così convinto che il cross platform sia la scelta vincente sempre.

E' più facile oggi fare cross platform rispetto a 20 anni fa: ci sono più librerie che nascondono la piattaforma e la crescente potenza dell'hardware permette di tenere degli strati di compatibilità tra l'applicativo nativo e il sistema sottostante. Penso per esempio all'ottimo Parallels su Mac OS X che permette di fare girare ad esempio  Microsoft Office per Windows senza vedere il desktop di Windows, ma di vedere le finestre Windows assieme a quelle del Mac. Penso proprio ai tempi di OS/2 quando di vedevano le finestre dei programmi per windows 3.1 assieme a quelle di OS/2, ma allora l'hardware non era così generoso come oggi e andava tremendamente piano.

20 anni di sviluppo cross platform mi hanno però insegnato che ci sono delle spine in questo mondo di rose. Le applicazioni cross platform non sfruttano mai le caratteristiche della macchina, ma soprattutto NON SI COMPORTANO SECONDO LE ABITUDINI DEGLI UTENTI.

Parlavo con un utente Windows che per le prime volte usava il fantastico The Gimp per il fotoritocco. Egli si arrabbiò perché la finestra di dialogo per aprire i file non era quella alla quale lui era abituato (The Gimp usava finestra di dialogo per Gnome) e questo particolare sminuiva tutto il progetto.

Chi ci "regala" applicazioni cross platform lo fa per LEGARCI ALLA SUA PIATTAFORMA, rendendo inutile il sistema operativo sottostante, per creare un ecosistema di applicazioni e quindi di persone, che hanno bisogno di lui. Questo spiega anche perché spesso le piattaforme cross platform impongono il loro look and feel anche quando potrebbero (e dovrebbero) appoggiarsi ai componenti del sistema sottostante. Garantire lo stesso aspetto su più piattaforme non serve tanto agli utenti, i quali tipicamente ne usano soltanto una. HTML5 mi sembra un'ottima specifica, applicata solo in parte dai produttori di piattaforme, i quali vedono positivamente la sostituzione di Flash, che è proprietario e i plugin sono pesanti, con uno standard aperto, ma l'idea che gli applicativi possano farsi senza dipendere da loro non va loro certamente a genio: quindi l'uso di uno strumento cross platform è sempre più scomodo per l'utente rispetto alle applicazioni native.

Prima di scegliere lo strumento bisogna pensare bene a cosa serve e a CHI LO USA.

NON DICO CHE BISOGNA TORNARE ALLE SOLUZIONI NATIVE in massa, dico che vedo un futuro migliore per chi sviluppa una soluzione nativa per il core dell'applicazione, che deve espandersi e crescere tramite dei generatori di codice o con dei motori che creano l'applicazione a partire da regole o parametri. Questa soluzione è oggi usata da pochi, per quando posso vedere dalla piccola finestra che ho sulla realtà, il motivo è che progettare un'applicazione è un conto, ma progettare un'architettura magari personale è tutt'altra cosa. Su questo fronte c'è ancora spazio per la piccola azienda creativa, che riscopra il valore della progettazione e dell'analisi sui dettagli che si ripropongono nei vari progetti dei quali si occupa.

La logica si può sviluppare con uno dei tanti linguaggi cross platform (Java, C#, JavaScript, anche il C++ 14 va bene) o con sistemi più sofisticati di scripting.
Anche le tanto vituperate stored procedure oggi sono piuttosto portabili e possono essere prese in considerazione e chi le sceglie merita rispetto.

Ci vuole coraggio per sviluppare la propria libreria di base. Scrivere generatori di codice o addirittura scrivere in xml dei layout che poi si applicano automaticamente ai dati da rappresentare, magari seguendo il Naked Object pattern e mettendo da parte il sopravvalutassimo MVC.

Sono queste secondo me le linee da seguire per chi nel 2015 non lavora solo su progetti altrui e vuole continuare a fare il proprio mestiere di produttore di progetti software, senza reinventare la ruota ma mantenendo la propria indipendenza e libertà.

Moduli Mancanti

Vorrei dire ai più pessimisti e ai tecnici più radicali nell'adesione alle regole, che in informatica c'è ancora molto spazio per un po' di fantasia, ma ancora di più ci dovrebbe essere spazio per un ritorno alla semplicità.

E' passato troppo tempo dall'ultimo post, tempo che ho impiegato nella mia attività di programmatore indipendente, ma adesso sento il bisogno di esprimere qui un concetto, che non mi sembra banale, purtroppo però pare che chi crea strumenti non ne abbia ancora preso coscienza:
quando si sviluppa un programma modulare, bisogna tenere presente sempre che un modulo potrebbe NON ESISTERE al momento della chiamata.

Non è un dettaglio da poco.

Ritenere che un modulo sia sempre installato, quindi che la presenza sia sempre certa è a mio avviso un grave errore progettuale, che inficia lo stesso vantaggio della modularità. Non basta sapere che posso sostituire un modulo con un altro, che ha un'implementazione diversa, mantenendo la stessa interfaccia, perché nel momento in cui si toglie un modulo necessario, per sostituirlo, l'applicazione deve essere FERMA. Questo non è sempre tollerato e tollerabile in tutte le situazioni.
Se l'alternativa è usare un cluster di server, francamente non mi sembra una soluzione, bensì una pezza costosa necessaria per la mancanza di un software moderno.

Non mi sembra sensato che, perché si cambia un logger, un sito con migliaia di visite si debba bloccare.
Ma anche nel momento in cui la modifica sia più importante, penso ad esempio ad un componente di back end per comunicare con web service, la sostituzione dovrebbe portare ad un messaggio di errore, oppure all'accodamento dell'invio dei dati in un sistema di bus.

Il tema della mancanza del modulo chiamato è affrontato malissimo in Java enterprise. Non esiste a livello di linguaggio qualcosa che si avvicini ad un'architettura modulare.

Se si usano le chiamate JNDI,  si può gestire la mancanza della parte chiamata, ma JNDI usa delle stringhe non standard tra un application server e un altro, perciò è un modo orribile per mantenere il progetto. Un diverso application server può usare parole diverse e una stringa non ha aiuti dal compilatore, quindi sbagliando a scrivere una parola, si ottiene un errore a runtime.

Le injection delle ultime specifiche hanno risolto il problema delle stringhe, ma ne hanno introdotto uno più grave: una risorsa iniettata può mancare e si ottiene una bella NullPointerException, chiamandola.

Il sistema modulare migliore ad oggi tra quelli disponibili, è OSGi. Purtroppo il supporto degli strumenti di sviluppo sotto questo punto di vista è scandaloso. Un oggetto esposto come servizio ha un'interfaccia, come best practice. Ora, la specifica suggerisce che il modulo chiamante crei un wrapper dell'oggetto esportato, implementando la sua stessa interfaccia, in modo che quando il client chiama un metodo, non sappia se sta chiamando il wrapper o il servizio vero e proprio, in modo che la mancanza del modulo chiamato sia gestita dentro al wrapper, magari con un messaggio per l'utente o per per accodare i dati. Tutto questo a mano ? Ma è ridicolo !  Non tutti lavorano per grosse multinazionali con budget enormi ! Non ho trovato aiuti in giro per questo punto, così importante.

La spiegazione che mi do su questa mancanza è che, soprattutto nei progetti piccoli,  la realtà è che ciò che si sviluppa non è un vero progetto software, ma un prototipo da vendere ! Chi fa moduli in un prototipo ? Nessuno.

Possibile che i pattern, la programmazione a oggetti, il buon senso siano tutti lussi ? No.

Non conosco Objective C, però ho letto che si possono passare messaggi (chiamare metodi) che non esistono e che possono trovarsi a runtime. Questo non è sempre ideale, anzi, ma forse negli anni 80 qualcuno si poneva il problema di chiamare un modulo che non c'è? Le shared object di mac os x si possono scaricare dinamicamente come i bundle di OSGi. Forse la soluzione esiste se la si cerca ?

Possibile che Java, il linguaggio dell' ubiquitous computing, non tenga conto minimamente di questa problematica ? Lasciare il problema a OSGi e rimandare continuamente il progetto Jigsaw non è una buona notizia, soprattutto se si vede a cosa si è dato priorità, come i generics, orribili.

A me viene da dire che il mondo Java, che uso da sempre, si concentri troppo sul linguaggio e troppo poco sugli strumenti ! Invece che cercare novità nelle annotation, sarebbe meglio spingere sullo sviluppo di generatori di codice che lascino al programmatore la scrittura di interfacce e implementazioni, queste ultime comunicanti con un sistema a bus, con una gestione della mancanza dell'oggetto chiamato, direttamente nel codice generato.

Il boiler plate necessario per un sistema moderno a volte è lo stesso che si usava 20 anni fa sui vecchi programmi legacy in c++.

Non abbiamo imparato niente da allora? Con tutti i problemi di memoria condivisa dei programmi multithread, non sarebbe il caso di rivalutare i vecchi task singoli, con un sistema (cross platform, please) che faccia comunicare i vari task, gestendo la mancanza del chiamato con un bus o un'altra forma che si possa decidere al momento della generazione del codice "collante" ?

Con finalmente un sistema standardizzato e semplice per aggiornare i moduli obsoleti ? Incredibilmente, OSGi ne è privo !

OSGi è sinceramente una buona idea, ma è stato concepito per girare su macchine con risorse scarsissime, in team con budget abbondantissimi ! Il core ha pochissime funzionalità. Oggi ci vuole un core che incorpori già un web server, un sistema di log moderno e standard e che non faccia impazzire con i classloader, che sono un delirio sotto OSGi, soprattutto quando si vuole usare librerie che non sono nate per OSGi e che usano internamente i classloader, perché chi le ha sviluppate, pensava a un sistema modulare, ma non ne aveva uno buono...