Libbertà

Quanno m’accorsi d’esse prigioniero
Cor laccio ar piede in mano a un regazzino
Non c’ebbi che n’pensiero, de rivolà in giardino
[Er grillo zoppo - Trilussa]

Una volta, purtroppo, era più facile definire cosa fosse la libertà.
Forse perchè, quando si ha un piede straniero sopra il cuore, il peso si sente anche senza stare a pensarci.
Poi la situazione è migliorata e si è potuto distinguere tra la libertà da (beneficiario un popolo) e la libertà di (beneficiario il singolo).

Ci sta una libertà anche un po' più egoistica, un po' meno quando si usa lo stesso termine per scopi marketing, o per gridare il diritto di poter fotografare la privacy altrui, o per difendere la libertà di opprimere.

Tra gli estremi si posiziona, a mio modo di vedere, il software libero.

Il che ci riconduce (con un salto triplo degno del peggior telegiornalista che cerca di passare da un crudo fatto di cronaca nera alla rubrica settimanale di gastronomia) alla fine del post precedente, in cui accennavo al modello di business di un software libero come Daz Studio.

Ricordate che vi avevo minacciati di parlare di licenze Open Source e modelli di business?
Ricordate il finale di Hotel California, You can check out any time you like, but you can never leave? Fino a che punto siete veramente liberi di non cliccare sul link Leggi Tutto?

Credete che io possa riuscire mai ad annichilire ulteriormente la mia già scarsa immagine di scrittore, continuando con queste penosissime introduzioni?

---

Ricorderete certamente (non metto il link al post precedente perchè dovreste vergognarvi anche al solo pensiero di scherzare sulla possibilità di non averlo ancora letto) che il modello di business di Daz Studio e compagnia bella si basa sulla rivendita di modelli grafici 3D pre-realizzati (più o meno come qualche altro migliaio di siti di grafica, con la differenza che, essendosi creati loro il programma sono in vantaggio, perchè posseggono un forte catalizzatore e una forte leva marketing).

Diventa interessante, confrontarlo, molto brevissimamente, con altri modelli di business basati sull'Open Source (free as freedom, not price, ci rammentano fin da piccoli dalla Free Software Foundation (FSF)):

• pubblicità/marketing (personale e per terzi - sempre basato sui grandi numeri)
• consulenza/servizi/corsi sui propri ed altri prodotti (cross-selling, tenendo presente che, con l'Open Source si abilitano alcuni mercati - es.: le linee strategiche per l'e-government prevedono, al punto 6, un incremento la diffusione e la utilizzazione di soluzioni Open Source e da tempo esiste un osservatorio Open Source; per certi versi è come se l'Open Source venga a costituire una sorta di certificazione, simile a quelle della qualità - su quest'onda nasce il marchietto dell'OSI, che si propone internazionalmente per censire le varie licenze open source). Tra i vari modi di far pagare i servizi trovo interessante la proposta di proporre un supporto a contributo volontario, che potrebbe anche portare ad uno sviluppo Open Source ben più orientato e goal-driven (variante come minimo da indagare, direi - l'ho vista usare, almeno, da ATutor, un sistema per l'e-learning basato su GPL) [Consulting e Subscription Strategy]
• dual licencing: per scopi commerciali, una licenza commerciale affianca quella open (così si 'vende' anche il prodotto e non solo i servizi collegati, da un lato risparmiando in marketing e sulla rete commerciale, rispetto ad un prodotto 'classico') [Dual Licence Strategy]
• vendita di estensioni, moduli o, comunque, feature a valore aggiunto non presenti nella parte Open Source del prodotto (up-selling); facilitato dalla natura elettronico/informatica (non fisica) del prodotto
• vendita di accessori o prodotti correlati: non solo libri, manuali e CD sull'argomento, ma anche magliette, tazze ed altri accessori di questo tipo
• supporto volontario al servizio (particolarmente efficace per servizi di altissimo livello e con grandissimo seguito come quelli forniti da Sourceforge o dalla Wikipedia)

Casomai dovesse interessarvi approfondire questo primo riassunto, sopra, tra parentesi quadre ho indicato nomi di strategie utilizzati in un bellissimo (anche se un po' datato) articolo di IT Manager's Journal, che aggiunge anche le strategie di Optimization, Patronage, Hosted ed Embedded, decisamente più adatte (soprattutto la seconda) ad aziende di una certa dimensione e brand. Se vi avanza tempo, potrebbe interessarvi anche la presentazione di Tim O'Reilly relativa ai design pattern nei business model Open Source (non così fondamentale come altri testi dello stesso autore, peraltro).

Di fatto, il modello di business utilizzato da Daz si configura quasi come una vendita di estensioni: solo, mentre i moduli aggiuntivi di un prodotto si venderanno a pochi clienti selezionati, con costi relativamente elevati, le estensioni di questo tipo avranno come target la massa e potranno mantenere un prezzo basso.

Da notare che una variante interessante (non facilissima da applicare a prodotti impalpabili come quelli informatici e, in particolare ai modelli grafici, almeno in prima istanza) può essere quella di far leva sulla mania di collezionismo: si comprano pacchetti chiusi e si trovano, con diversa probabilità, oggetti 'confezionati' randomicamente (per chi avesse giocato a Magic the Gatheringo simili dovrebbe essere molto chiaro). Non ho esempi a questo proposito, non ne ho trovati, se ne conoscente segnalatemeli.

Con un modello di business basato sulla vendita di gadget o librerie, si evita pure il problema che mi sta capitando nel cercare di trovare un modo di affibbiare ad un mio sistema una licenza Open Source GPL v3 (la GPL è la licenza che più di tutte permette di supportare il dual licencing affiancando una licenza commerciale ad una Open Source e la versione 3 è particolarmente interessante per la compatibilità con altre licenze libere, Apache 2.0 in particolare e per la protezione nei confronti di chi volesse tentare di imporre eventuali brevetti su quanto è stato realizzato).

Forse vi sto per dire una banalità e vi annoierete (ma spero, invece, che vi cada la mascella per lo stupore come è capitato a me), ma mi è recentemente capitato di notare con disappunto che, sotto certe condizioni e pur utilizzando parti di software libero, è più facile rilasciare un prodotto software con una licenza commerciale che con la GPL.

Infatti le licenze, anche quelle libere, in quanto oggetti legali possono essere incompatibili tra loro, come ci ricordano i tipi della GNU (abbastanza ovviamente il link precedente è un approfondimento GPL-centrico: sarebbe interessante avere una sorta di matrice, tra le licenze più diffuse, ma non l'ho trovata).

Lo stupore cresce quando vi accorgete che le licenze di SUN non sono compatibili con la GPL.

Lo ridico in un altro modo: Java (di SUN - spiego dopo questa apparentemente curiosa precisazione) e GPL (fino al 13/11/2007) non potevano convivere.

Lo ridico ancora: Stallman si è espresso almeno due volte a proposito di quella che lui chiama Java Trap, tra il 2004 ed il 2006, evidenziando come programmi basati su Java (di SUN) non possano essere legalmente anche licenziati con la GPL.

Perchè la precisazione di prima (Java di SUN)? ne esistono altre? Certo, Java come specifica non pone vincoli, li pone la licenza con cui viene rilasciata l'implementazione. E la licenza di SUN, per quanto riconosciuta dalla fsf come libera, non è compatibile con GPL.

Le implementazioni alternative sono almeno 2: GNU Classpath, suggerito da Stallman ed il più recente Apache Harmony. Essendo implementazioni basate su licenze Open Source compatibili con la GPL, se riuscite a compilare il vostro sistema usando le loro librerie e compilatori, ok, siete salvi, potete rilasciare il vostro programma Java sotto GPL.

Purtroppo, allo stato attuale, sono implementazioni ancora parziali (per fare un esempio, il mio sistema non è ancora compilabile con questi due pacchetti - sto verificando come sostituire i metodi non implementati con altri, ma devo ancora capire bene se il gioco valga la candela).

Una breve parentesi: GNU Classpath si ferma alle specifiche della JDK 1.4, mentre Apache Harmony parte dalla compatibilità con la 1.5. Vedete voi cosa più vi serve (spero per voi che sia la 1.5 o la 1.6, ovviamente).
Inoltre con Apache Harmony potete farci sostanzialmente ciò che vi pare (licenza Apache 2.0), compreso commercializzare il vostro prodotto; con GNU Classpath, invece, non ne sono sicurissimo (il testo è ambiguo, la spiegazione sembra più possibilista - se riuscite a capirlo voi, con un ragionevole livello di certezza, fatemi un fischio): si basa su GPL (quindi, tutto ciò che tocca dovrebbe diventare GPL), ma con una eccezione che permette di linkare altri moduli, senza farli diventare GPL.

Certamente, lo so, l'ho detto prima, è inutile che continuiate a bisbigliare: esiste un'altra possibilità, dal 13/11/2007 Java è stato annunciato con licenza GPL (qualche commento di Goslin a questo proposito). Ne hanno parlato tutti, ci mancherebbe altro che fosse sfuggito un particolare così importante.

Purtroppo, almeno per i miei scopi, non va mica tanto bene. La scelta di SUN riguarda la licenza GPL v2, non la GPL v3. Ci sono, almeno, le seguenti controindicazioni:
- GPL v2 e GPL v3 sono incompatibili tra loro: quindi, tutta la parte relativa ai brevetti non sarebbe applicabile
- molto peggio, GPL V2 e licenza Apache non sono compatibili tra loro (mentre GPL v3 e Apache, sì): quindi non potrei utilizzare, nel mio sistema, tutte quelle belle librerie che uso
- ancora peggio: usando Java licenziato GPL v2 il vostro sistema diventerebbe GPL v2 anche lui e non sarebbe applicabile il dual licencing con licenza commerciale, non essendo il primo della cordata

Acc.... ma scusate, non ci sono programmi Java licenziati sotto GPL?
E come fanno? Ricevono lettere di cause dalla FSF in continuazione?
O so basano su zone grigie di interpretazione (tipo quella per cui, secondo l'Apache Foundation già la GPLv2 era compatibile con la licenza Apache 2.0, mentre secondo la FSF no)?

Vi devo chiedere di smetterla di deviare continuamente in parentesi inutili, e di cercare di concentrarvi sul punto fondamentale: come faccio a risolvere il mio problema?

Con lincenze BSD o MPL? No, troppo libere, io sono uno di quelli che 'non sopportano l'idea che altri possano vendere il mio sistema': anche un commerciale normodotato (cosa che io non sono, io sono la versione seria del signor Spock di Star Trek) potrebbe piazzare nel tempo libero il mio sistema e questo non mi potrebbe mai andare giù, dopo i miei inutili tentativi.
Prendendo spunto dalla GPL e aggiungendo varianti che permettano l'uso di librerie free? No, potrebbe essere complesso, non sono un legale, diventa un casino, ci vuole un attimo a sbagliarsi e a renderla troppo o troppo poco flessibile (pensate solo a quanto tempo e risorse ci hanno messo a variare la GPLv2 per farla diventare GPLv3).

Queste cose le dico per voi, per evitare che vi troviate con un bellissimo sistema (il più bello di tutti, ovviamente), basato su librerie Open Source, senza poter sfruttare la distribuzione free, perchè potreste rischiare di infrangere una o più delle licenze.
Non voglio che rischiate di dover rivedere le librerie di base del vostro sistema e di dover adattare parti del codice con ulteriore effort, a fronte di nessuna aggiunta in funzionalità (ulteriori costi, per voi), solo perchè non siete stati abbastanza lungimiranti all'inizio del progetto.
Non voglio rischiare io di rompermi le balle a leggere un lamento lungo un post sul vostro blog, scritto per sfogare il vostro disappunto e per chiedere inutilmente a Stallman e compagni se non sia il caso di ripensare un po' i vincoli della libertà, come già suggerito diverso tempo fa dallo stesso poeta con cui abbiamo iniziato questo post:

La libbertà [...]
se c'è chi la guida e la riduce
e l'incanala verso l'officina,
appena arriva smove la turbina,
diventa forza e se trasforma in luce.
[...]
Ma quanno l'acqua ha smosso ner cammino
una centrale elettrica o un mulino,
se canta o se barbotta, nun è male
lassaje un pò de sfogo naturale!
[La libbertà - Trilussa]

Bye

Depa

P.S.: le mie scuse a Trilussa, per la leggera forzatura ed anacronismo dell'ultima citazione. Non credo di averne invertito o travisato completamente il senso, ma sono conscio di averlo allontantato un po' dall'originale intenzione.
P.P.S.: a Stallman e compagni: tranquilli, non sentitevi in obbligo di affrettarvi con un commento a questo post, la risposta la capisco da solo e comprendo la posizione, anche se la condivido solo parzialmente.
P.P.P.S.: prometto che smetto, ma non potevo non ricordare anche questa strofa, perchè su questo argomento non può che farmi bene anche un po' di autocritica:
La libertà non è star sopra un albero,
non è neanche il volo di un moscone,
la libertà non è uno spazio libero,
libertà è partecipazione
[La libertà - Gaber]

[... continua ...] Leggi tutto

CRUDeli variazioni

In Centomila miliardi di poesie, Queneau prende 10 sonetti, con le stesse rime, fa una striscia per verso e li impagina come in un gioco di identikit per bambini, in modo che si possano combinare fino a produrre quanto promesso dal titolo.

Facile notare che è la struttura formale dei sonetti e le regole che Queneau si è imposto che gli permettono di raggiungere il risultato. Ed è lo stesso scrittore ad evidenziare che:
"Il classico che scrive la sua tragedia osservando un certo numero di regole che conosce è più libero del poeta che scrive quel che gli passa per la testa ed è schiavo di altre regole che ignora." [Che cosa è l'arte? - 1938 - Raymond Queneau]

Chi mi conosce sa che, se vi sto parlando di letteratura che si compone dinamicamente, in realtà, niente di più facile che stia per propinarvi quelle due righe indispensabili per l'introduzione a, che so, la generazione automatica di codice.

Chi mi conosce potrebbe pure immaginare che, se mai qualcuno potesse azzardare un assurdo paragone tra una metodologia informatica ed una medicina (cosa che mai faremo), io cercherei di portare l'attenzione sul fatto che le buone medicine vanno prese, ma meglio se dopo consultazione con uno specialista, sempre solo dopo aver ben letto le istruzioni per l'uso, capito che davvero curano il nostro male e stabilito che non contengano controindicazioni anche gravi.

Infatti, se certe regole le applica Queneau, il divertimento potrebbe anche diventare arte, ma con autori meno accorti si potrebbe rimanere fermi al generatore automatico di poesie della mutua, perdendosi anche il gusto dello scherzo.

---

Come spesso in altri casi, la mia vita virtuale e quella reale si confondono, si intrecciano lavoro e interventi sui blog (ancora su quello di Isadora, in un post già citato, anche se oramai un po' perso nel passato) e anche spiaggie e montagne le vedo da tempo solo renderizzate.

Non posso, invece, girarmi senza sbattere contro qualche progetto che si basa sulla generazione automatica di codice.

Dopo 8-10 volte, dopo aver escluso di essere coinvolto in una candid camera, mi ha sfiorato il dubbio che il senso di dejavu fosse accompato anche da un senso di disagio, dalla domanda se e quando questo processo nel mio passato si sia dimostrato effettivamente parte di una metodologia produttiva o fosse solo un modo di automatizzare il cut&paste (da non intendersi necessariamente in senso negativo: chi è senza peccato...).

Sourceforge, ad oggi, anagrafa tra i 2700 e i 2800 progetti nella categoria Code Generators: tra i primi 10 ci sono almeno 4-5 compilatori o estensioni, 1 progetto ERP (che, contrariamente a quanto potreste immaginare, ha davvero a che fare con questo post), 1 progetto per generazione di codice partendo dall'UML e 3-4 generatori generici template-based.

Per mancanza di tempo cercheremo di escludere almeno i compilatori, che richiedono ben altra teoria, per concentrarci su casistiche più semplici, tipicamente quelle rappresentate da un modello dati che viene trasformato in un generico output (visivo, su file, come vi pare) sulla falsariga di un template elaborato da un qualsivoglia motore, possibilmente in modo più dichiarativo possibile e senza ricompilare, al fine di produrre nuove righe di codice leggibile ed, eventualmente, modificabile e riusabile.
Uno dei tanti pratici e quasi classici utilizzi del classico pattern MVC, insomma. Estenderemo appena questo ambito, giusto perchè non ha senso limitare la fantasia (anzi, se volete poi segnalare altri curiosi impieghi e approcci, siete, al solito, benvenuti).

Diamo per scontato che abbiate già visto e/o usato generazioni automatiche, almeno una volta, per esempio per creare automaticamente codice e form di CRUD (per i 2 che non lo sanno, è l'acronimo con cui si indicano le operazioni alla base della gestione di dati: Create Read Update Delete). Magari con successo. Le stesse due-tre formettine, sempre uguali per l'intera applicazione, di semplice gestione di dati piatti, con pochi bottoni, sono spesso rese con strumenti simili, partendo dal reverse del database (e qualche altra informazione minore riguardante resa grafica, lookup, etc. etc. Approccio convincente, in fondo. Sembra funzionare.
Vien da chiedersi se non sia possibile estendere la tecnica ad altre casistiche.

L'utilità nel generare codice da compilare per le interfacce, soprattutto quando sia richiesta grande velocità non raggiungibile con sole generalizzazioni ottenibili componendo dinamicamente le pagine è indiscutibile. Tecniche simili sono utilizzate da molti CMS per per produrre siti Web con numero elevatissimo di accessi e ridotta richiesta di personalizzazione della navigazione da parte dell'utente): si creano tutte le pagine in html, al posto che passare da jsp, che, fossero pure basate su grandi cache, su numeri enormi possono far sentire il loro peso (beh, nei siti più importanti, dove viene richiesta una fortissima interazione user-centrica, comunque, l'approccio a pagine statiche non è praticabile e bisogna scalare aumentando l'hardware).

Sulle interfacce grafiche viene bene, anche perchè la generazione automatica supplisce, in parte, alla ridotta o non disponibile ereditarietà di implementazione tipica di tecnologie di front-end (jsp, aspx, etc. etc.).
[Che poi sia un bene non esagerare, in generale, con l'ereditarietà di implementazione e che sia poco sensato e/o mal definito pensare non solo di riusare componenti, ma anche di far ereditare posizioni e presentazione a pagine diverse, è altra questione che non vorrei tirare in ballo in questo post].

Non per nulla gli ambienti di sviluppo e progettazione visuali sono uno dei modi più comuni per produrre codice senza scriverlo direttamente, in una continua interazione tra utente ed IDE (particolarmente continua e interessante laddove venga gestito anche il roundtrip e relative difficoltà di riallineamento tra il codice scritto manualmente e quello generato - risolto, il più delle volte, con aggiunta di commenti, placeholder e dichiarazioni varie nel codice da parte del generatore + richiesta di scrivere, gentilmente, appena fuori dalla zona riservata).

Altro caso classico di generazione del codice è quello fornito da strumenti ORM, che, partendo da un reverse del DB generano le classi nel linguaggio di vostra elezione, per supportare il pattern DAO. Non insisto ad approfondire un argomento che mi piace molto poco, come già sapete, ma dovevamo citarlo, non fosse altro che per evitare accuse di averlo appositamente escluso.

Uscendo dagli esempi e cercando di generalizzare, inizio a segnalarvi che su SoftwareReality si trova una bellisima serie di articoli, completi e approfonditi, sull'argomento.

Può qui giovare riprendere e commentare almeno la pagina che tratta di vantaggi e svantaggi dei generatori di codice.

Vantaggi:

• Ultra-consistenti: perchè generati proceduralmente
• Maggior pulizia e semplicità del codice: portano il programmatore a ridurre le attività di generalizzazione, concentrandosi su cosa serve ora; ogni modifica potrà essere aggiunta sul template del generatore, riproducendo il codice (a meno di modifiche intervenute sulla prima generazione e/o a meno di necessità di gestione - solitamente complessa - del roundtrip, ovviamente)
• Stabile e bug-free (il debugging si concentra PRIMA dell'inizio del progetto): verissimo, ma non è trascurabile il fatto che, se il debug del motore di generazione (tipicamente costoso/molto costoso) avviene PRIMA dell'inizio del progetto, non lo paga il cliente, ma qualcun altro (noi, se siamo noi ad aver progettato il generatore di codice, è un nostro investimento). E' certamente vero, comunque, che in presenza di poche modifiche in corso d'opera a motore e template, ogni generazione successiva può essere eseguita automaticamente o eventualmente con solo piccola supervisione.
• Produce molto velocemente una nuova API aggiornata e garantita, partendo da una descrizione del dominio del problema: anche questo verissimo, ma la sua potenza e flessibilità dipende dalla flessibilità con cui abbiamo generalizzato il nostro generatore ed il relativo dizionario dati (più è flessibile più sarà probabile un significativo investimento iniziale). Qualcuno ritiene che sia questa la forza di alcuni degli ERP/CRM Open Source di maggior successo.
• Customizzabile: inoltre non necessariamente serve il codice del generatore come dice l'articolo da cui siamo partiti, se possiamo agire su template, dizionario dati, regole (a meno, ovviamente, di non considerare come codice anche questi tre elementi)
• I cambiamenti di generatori/template, codice generato e progetto vanno di pari passo: se è necessario un cambiamento strutturale lo si fa sul generatore/template e si propaga ovunque . Non bisogna, però, perdere di vista il problema del roundtrip di cui parlavamo sopra. Non di rado, dopo la prima generazione, si rischia di non riuscire a stare dietro ai cambiamenti. Ovviamente la nostra generazione dovrà prevedere una architettura che separi le personalizzazioni dal codice generato. Lo si può fare con righe di codice "riservate", come i tool visuali di cui parlavamo, o (meglio, ma non sempre così facile) separando il codice generato dal codice modificabile in classi diverse e legandoli con qualche pattern.
• I programmatori sono liberi di concentrarsi su aree di sviluppo di maggior rilievo (il morale migliora, la produttività cresce): è forse uno dei punti di maggior interesse... se la generazione del codice non vincola troppo e non richiede troppo (altrimenti si ottiene il risultato opposto). Questo vantaggio è particolarmente vero se gli sviluppatori in questione non sono quelli che devono gestire anche il generatore, dizionario dati e relativi template, ovviamente.
• Insegnano a scrivere codice: solitamente ci si attende che il codice generato sia ben scritto e consistente al 100% (ma tra teoria e pratica ce ne passa) e i programmatori (junior) possono imparare dallo stile del codice generato. Vero solo se confrontato con metodologie che prevedono documentazione da leggere per le style guide e solo se il codice viene veramente letto. Nella pratica mi capita di vedere che non venga letto (e/o applicato) nè il documento degli standard, nè il codice scritto da altri (anche senza generarlo automaticamente, tra codice prodotto in-house da senior e codice esterno, disponibile in centinaia di migliaia di progetti open source ce ne sarebbe a sufficienza, anche senza generatori; senza considerare che il codice generato, solitamente, riguarda parti concettualmente più semplici, da cui si può imparare meno)

Svantaggi:

• Prima bisogna scrivere il generatore: lo abbiamo detto sopra, i costi si spostano sull'investimento. Inizia ad aver senso quando lo stesso generatore si può riusare su più progetti, perchè, a quel punto, i costi si abbattono e si è più competitivi della concorrenza. E' un po' come scrivere librerie o framework aziendali (ma questo punto lo approfondiremo - non so se oggi o quando, ma lo faremo)
• Applicabile solo all'interno di ambiti e condizioni specifici (almeno fino alla realizzazione del primo generatore basato sulla comprensione del linguaggio naturale: poi sostituiremo il dizionario dati con le specifiche e sarà libero di interpretare a modo suo e fare lo stesso casino di un programmatore umano). Anche l'articolo citato suggerisce che il codice generato sia da considerare un supporto per le parti aggiuntive, scritte manualmente, una sorta di API
• Se il codice generato deve trattare con database, questi devono essere progettati e normalizzati bene, perchè i generatori solitamente non si comportano bene con database con caratteristiche particolari: vero, a questo riguardo possiamo solo aggiungere che non è raro che il database stesso (o, almeno, parte di esso) siano parte del codice generato. Generatori che si adattano a database esistenti sono solo generatori più flessibili, che estrapolano parte del loro dizionario dati dai metadati, dal reverse del db.

Mi sembrano necessarie alcune considerazioni aggiuntive:

• di fatto, per generare il codice, è necessario operare una sorta di generalizzazione. Spesso conviene, a mio parere, chiedersi se non ci sia l'alternativa di progettare una soluzione generale, al posto che generare il codice, per gestire direttamente la problematica. Pro: potrebbe essere più manutenibile (una sola/poche classi al posto delle decine/centinaia/migliaia generate + quelle del generatore che sarebbero, comunque, da manutenere). Contro: un comportamento generale può girare più lentamente di uno generato in modo specifico, in fase di esecuzione (ricordate l'esempio dei CMS all'inizio di questo post?)
• vale la pena di considerare, a seconda dei casi, modalità di generazione progressiva, prodotta dall'interazione uomo/macchina. Vantaggi: flessibilità e velocità. Svantaggi: maggior rischio di complessità per gestione roundtrip. Laddove questa generazione sia nascosta all'utente (non programmatore, ma utente finale), potrebbe essere pericolosa e pesante. Per fare un esempio di una simile casistica, conviene pensare a strumenti di data mining o di interrogazioni dei database semplificate per gli utenti finali: da una semplice interfaccia si generano query SQL, senza che l'utente debba conoscere SQL (il caso più semplice è il QBE, Query By Example). A parte il fatto che, solitamente, in questi casi, si perde molta della potenza del linguaggio sottostante, mi viene sempre in mente il drag&relate visto nel 2001 su Top Tier (oggi inglobato in Sap Portal - che, tra l'altro, non vedendolo dal 2004, non so se mantenga ancora questa caratteristica, che già tendeva a nascondere): metteva facilmente in relazione entità anche complesse di database (anche alla base di ERP come SAP e BaaN, ai tempi), generando output in base al fatto che l'utente poteva trascinare righe di una entità su un'altra entità e le join ed i filtri li applicava lui secondo regole dedotte dai metadati e corrette/integrate manualmente sul suo dizionario dati. Bellissimo strumento demo (almeno per i tempi), aveva il piccolissimo difetto che, al terzo-quarto drag&relate poteva anche riuscire a mettere in ginocchio il server, dal momento che generava continue subquery di complessità arbitraria, come i vedeva bene dai log degli ODBC. Attenzione a problematiche simili generabili dai constraint di Hibernate, nel caso il programmatore non conosca bene la struttura del DB sottostante (e se lo conosce, forse ci siamo persi parte dei vantaggi di Hibernate stesso e dell'ORM... siccome ho già detto che non insisto, non insisterò...)
• Esistono, oggi, sistemi anche molto complessi che utilizzano la generazione di codice a partire da dizionari dati di dimensioni e obiettivi importanti: Compiere ERP e i suoi figli ADempiere e OpenBravo (era lui, ad essere indicato tra i primi 10 Code Generators in sourceforge) costituiscono uno degli esempi più eclatanti: una buona parte dell'ERP si rigenera sulla base di regole e descrizioni di relazioni tra entità. Magari ne parliamo meglio in qualche prossimo post, riguardo a strumenti OpenSource per le aziende. Fossero solo gli unici esempi (anche in caso di funzionamento parziale rispetto al dichiarato), sarebbero sufficienti per rendere questa metodologia come degna di considerazione, ben al di sopra dell'automatizzazione del cut&paste di codice.

Oltre ad annoiarsi con le considerazioni di cui sopra, con la generazione di codice ci si può anche giocare (anche perchè generazione è una parola piena di significati, anche importanti, non vogliamo mica lasciarla passare senza far nulla, vero?).

Non so se abbiate presente CRobots. Si tratta di un gioco per programmatori: si programma il comportamento di un robot e lo si manda a combattere in un'arena con altri robot e, ovviamente, ne rimarrà soltanto uno.

Per un esame universitario misi assieme CRobots e algoritmi genetici (voglio dire: se parliamo di generazione, parliamone fino in fondo) per far evolvere programmi in grado di giocare a CRobot (per superare i limiti di potenza di un 8086, non potendo permettermi un algoritmo di selezione effettivamente basato sul combattimento in arena, troppo lento - ogni partita richiedeva minuti, tempo non compatibile con la durata attesa della mia vita -, dovetti pensare ad un modo di 'far leggere' il codice all'algoritmo di selezione, con delle euristiche per valutarne la bontà - via il dito dal tasto sinistro del mouse, ve ne parlo un'altra sera...).

In termini evolutivi non ho passato di molto il brodo primordiale, ma è bastato per vedere robot immobili trasformarsi in quelli dotati di un ridotto movimento (troppo movimento era dannoso: finivano a suicidarsi contro il muro), fino ad arrivare a quelli che vendevano cara la pelle sparando qua e là a caso.

Generazione automatica ed evolutiva di bug, in fondo, pur all'interno di un codice stilisticamente accettabile e sintatticamente corretto, perchè preimpostato (provate a rileggervi vantaggi e svantaggi, in questa ottica, potrebbero assumere un altro aspetto).

In ambiti più complessi la generazione di codice può fermarsi un attimo prima, ad una proposta di generazione (la differenza sta solo nell'applicare o meno il risultato), richiedendo una più esplicita e forzata interazione tra uomo e macchina.

Essendo parecchio malati potrebbe pure capitare di laurearsi con una tesi (di Artificial Intelligence, ovviamente, che so, intitolata Sistemi basati su conoscenza che analizzano il proprio ragionamento) impostata su un sistema esperto che si limiti (con la modestia che mi contraddistingue) a proporre le modifiche alla propria base dati, senza modificarla, partendo dall'analisi della base dati stessa, dai risultati forniti e da quelli attesi e interagendo con l'esperto di dominio.

Siccome dopo aver giocato con la parola generazione ora stiamo sforando nel giocare anche con la parola codice, possiamo estenderne appena appena il concetto e chiudere il giro (sempre per passi e per vie traverse e contorte, si intende e ci mancherebbe altro) tornando dall'informatica alla letteratura da cui eravamo partiti, citando una serie di generatori di codice molto particolare, di linguaggio, in modo da arrivare a generatori di storie, il cui capostipite, se la memoria non mi inganna, dovrebbe essere Storyteller, del già più volte citato Shank.

In questo caso la generazione deve passare da un motore che conosca, tra l'altro:
- i principi minimi di base di semiotica che chiunque impara da bambino leggendo Eco o, almeno, le già citate classificazione di Aarne e Thompson e schema di Propp, per estrarre alcune conoscenze relative alla struttura dei racconti
- due o tre concetti di come si susseguono le azioni nel mondo reale (script basati su Conceptual Dependency nel caso di Shank)
- qualche (minima) capacità semantica (di fatto, compresa nel punto precendente)

Per evitare che pensiate che mi stia inventando, appunto, delle storie, vi cito qualche link d'esempio, che parta da un significativo elenco di link a generatori di storie (di diverso livello e diversi argomenti), per passare ad una introduzione, schemino (con altri link) e qualche modello per raccontare storie più evoluto ed accademico, che, magari, sia in grado di sottolineare le emozioni dei personaggi, per finire giocando su qualche narratore online (dal generatore di trame per il cinema, ad esperimenti che si spingono anche a cercare foto coerenti con il testo fino a cercare di far soldi, sfruttando i generatori automatici per diventare ricchi scrivendo un romanzo).

Approfondire anche questo argomento ci riporterebbe su un discorso già più volte sfiorato e mai intrapreso.
Che non abbiamo tempo e spazio di iniziare neppure stavolta.
Peccato...

Bye

Depa

P.S.: potrebbe venirvi in mente anche di costruire post automaticamente, che contengano le parole più cercate, per far salire il ranking e gli hits sul proprio blog. Curiosamente l'esito può anche non risultare così insopportabile da leggere rispetto a molti articoli di blog scritti appositamente per l'ottimizzazione nei motori di ricerca. Anzi, talvolta mi sorge pure il dubbio che, con la generazione automatica, certi programmatori e romanzieri si siano già spinti più avanti di quanto io sappia e vi abbia raccontato...

[... continua ...] Leggi tutto