Software evolution…

Su Tuttoscienze di oggi c'è un interessante articolo che vi invito a leggere sull'evoluzione del software paragonata a quella dell'hardware negli ultimi decenni.

Per l'hardware viene preso in considerazione come metro di giudizio il numero di cicli (forse era meglio l'ormai classico flops ma tendezialmente l'ordine di grandezza è lo stesso).

E per il software? Come principale dato dell'evoluzione del software viene preso in considerazione la produttività del programmatore, che è rimasta, come viene detto, tendenzialmente inchiodata a 10 istruzioni al giorno.

Sono un pò scettico su questo dati e sul loro significato; cosa vuol dire 10 istruzioni? il termine è un pò troppo generico: 10 istruzioni ad alto livello?

E soprattutto non sono completamente d'accordo con l'assunzione che il metro di giudizio per l'evoluzione del software sia la produttività media di un programmatore: sarei più propenso a vedere l'evoluzione del software come la capacità dello stesso a eseguire "operazioni" non possibili fino a un certo periodo. O piuttosto a permettere all'utente di eseguire delle azioni in campo virtuale che hanno un effetto sul mondo reale.

Ma più ci penso e più mi metto in dubbio, e porgo la domanda: secondo voi come dovrebbe essere valutata l'evoluzione del software?

Segue che come conseguenza del teorema di Godel e Turing la produzione del software è un processo non automatizzabile, come già chi ci lavora si era accorto…. e vari excursus sulla diseconomia del prodotto dovuta alla sua natura non industriale.

Bell'articolo che mi lascia comunque qualche dubbio.

Mazi

Embedded Java database engines.

Negli ultimi due mesi sto conducendo un lavoro di scouting su tecnologie adattabili al nostro modello dati per un problema in esercizio.

Quando sono entrato nel team di sviluppo il modello dati era ormai ampiamente implementato e collaudato, ma cominciava a mostrare il fianco soprattutto per una non corretta valutazione delle risorse necessarie al suo uso in esercizio e al target operativo.

Lo strumento utilizzato in questo momento è EMF.

Come cita la pagina di presentazione:

EMF is a modeling framework and code generation facility for building tools and other applications based on a structured data model. From a model specification described in XMI, EMF provides tools and runtime support to produce a set of Java classes for the model, a set of adapter classes that enable viewing and command-based editing of the model, and a basic editor. Models can be specified using annotated Java, XML documents, or modeling tools like Rational Rose….


Oltre a queste utilissime funzioni di generazione automatica del codice senza cui nessun programmatore riuscirebbe a vivere….:) EMF offre anche un vero e proprio framework per il modello dati in termini di inserimento, ricerca cancellazione… e una modalità di persistenza del modello dati su file system.

Il problema nasce dal fatto che per offrire tutte queste funzionalità EMF pesa molto in termini di RAM.

Per fare un esempio il nostro modello dati diciamo che rappresenta dei dispositivi di telecomunicazione (dei DSLAM come ben sa ormai chi mi conosce…) e con con l'attuale configurazione riusciamo a gestire circa 100 dispositivi per blade (server dual processor con 4 GB di ram); visto che a pieno regime ci sono circa 10000 dispositivi sul territorio questo vorrebbe dire 100 blade da circa 3000 dispositivi l'una che inesorabilmente porta a 300000 euro di sola ferraglia….. un pò troppo visto il nostro budget…

Era indispensabile cambiare tecnologia per il modello dati, e per questo sono stati esaminati prodotti appartenenti a diverse famiglie:

  1. RDBMS di tipo tradizionale (i.e. Oracle Database).
  2. In-memory database (i.e. TimesTen).
  3. Embedded database engines in Java (i.e. Berkeley DB Java Edition).

Io mi sono occupato dello studio della terza tipologia di prodotti, prendendo in considerazione Hypersonic SQL, H2 Database, Mckoy SQL Database, Apache Derby e Berkeley DB JE.

I nostri requirement sono:

  1. Gestione trasparenete della ram (memoria per il framework configurabile).
  2. Scalabilità e performance nelle operazioni CRUD.
  3. Politica transazionale di tipo ACID.
  4. Salvataggio dei dati in locale.

Hypersonic si è dimostrato poco performante per i nostri impieghi, H2 molto performante ma con soluzioni solo in-memory o solo on-disk, Derby ancora non offre nessuna feature in-memory e Mckoy ha rilasciato nel 2004 la versione 1.0.3 come una ultima release, un pò datato e indice di nessun ulteriore sviluppo.

Berkeley DB JE invece mi è piaciuto da subito: non offre nessuna interfaccia SQL e non implementa un modello relazionale, ma offre una serie di API per la persistenza molto intuitive e molto flessibili adatte agli sviluppatori; permette di definire la persistenza di oggetti del modello dati tramite le annotation, così come le relazioni di contenimento piuttosto che i constraint. Il suo runtime coincide con quello dell'applicazione e si appoggia a un file system locale per la persistenza dei dati.

Gestisce le transazioni, ha elevate performance e permette di configurare la ram utilizzata per il suo environment, usando il disco quando necessario per swappare.

Insomma proprio quello che cercavamo 🙂

Non per niente Sleepycat (l'azienda che lo ha svilppato) è stata recentemente comprata da Oracle.

Unico neo è che è rilasciato con un doppia licenza, GPL e commerciale senza bisogno di rilasciare il codice: stiamo aspettando un preventivo per capire la portata della spesa, ma visto che ormai è un prodotto Oracle non ci aspettiamo niente di economico.

Nel caso qualcuno ne avesse bisogno, durante le mie ricerche mi sono imbattuto in questo bell' elenco di database engines open source scritti Java.

Mazi

Roger’s playing… silence please.

Week-end infuocato quello appena passato.

Sono partito con Barbi venerdì mattina alla volta di Verona, per visitare la città e per prepararmi all'evento musicale dell'anno.. il concerto di Roger Waters!!!

Verona è una bellissima città, e il tempo ci ha graziato viste le pessime previsioni (pioggia a tutto andare). Diciamo che ci siamo presi solo qualche goccia.

Visita a Sirmione e Malcesine (sul lago di Garda) il sabato; cena in piazza Bra sotto l'Arena con musica live di un certo Mark Knopfler 😀

La domenica è cominciata bene, col tempo che ci ha assicurato un sole pieno tutto il giorno.

Concerto previsto per le 9:30, vista la nostra disponibilità di biglietti in poltronissima siamo entrati alle 9:15, giusto giusto per l'inizio celebrato con la ormai collaudata In The Flesh.

La prima parte del concerto ha visto Roger ripercorrere la sua storia con canzoni del suo repertorio; Mother, poi tributo a Syd Barrett con Shine On You Crazy Diamond, per poi passare a Have A Cigar, Wish You Were Here, Set The Controls, The Gunners Dream, Perfect Sense e Sheep.

Pausa di un quarto d'ora e poi Dark Side Of The Moon tutto d'un fiato.

Spettacolo!!!!!!!!!!

Oltretutto l'Arena di Verona è un posto con una acustica fenomenale, meraviglioso e molto suggestivo in cui vivere un evento del genere.

Sono contento di essere riuscito ad andare a vedere una persona del calibro di Roger Waters finalmente dal vivo (visto che il concerto del 2002 del tour In the Flesh me l'ero perso).

Dopo il concerto sarei rimasto a Verona per la data del giorno dopo 😀

Difficile dimenticare qualcosa del genere penso per tutta la vita.

Consiglio a tutti un giro sul buon flick per le foto del week-end.