martedì 27 novembre 2007

Come un bambino



Come un bambino ho iniziato e come un bambino mi sono velocemente annoiato.

Avete mai provato a cercare su Internet un presepe in grafica 3D (meglio se navigabile - e esageriamo? - con i personaggi che si muovono, l'acqua che scorre etc. etc.), da installare sul PC?
Beh, io non sono riuscito a trovarne neppure uno.

Ma se non ti arrendi al primo ostacolo, il minimo che puoi fare è provare a vedere se riesci a farlo tu (per giocare, non come attività commerciale).
Voglio dire: ci sarà pure un programma (free, ovviamente!), per quanto elementare, che sia in grado di stilizzare delle figure che, almeno da lontano, sembrino umane e poi sia in grado di scambiarle con altri programmi in grado di fare il resto del paesaggio, - lasciamo stare le animazioni etc. etc. per il momento. No?

Beh, sì e no.
No: non c'è un (solo) programma che in grado di stilizzare figure che sembrino umane almeno da lontano.
Sì: ce ne sono diversi in grado di modellarne che sembrino umane anche da vicino.
E anche con le animazioni.

Vi anticipo il finale, rovinandovi la sorpresa e la voglia di continuare: come nella più dozzinale commedia di Hollywood, non ci si può esimere dalla considerazione che un presepe vero è molto meglio, che serve arte, spirito e fuoco, non bit.

Ai pochi che saranno ancora interessati suggerirei di non escludere a priori che nel corpo del post si possano approfondire alcuni aspetti dei programmi sopra citati.



La ricerca di programmi per animazioni di modelli umani può riservare delle sorprese e fornire una vaga idea di come potrebbero essere quelli usati per realizzare film di successo.

L'occhio di Google cade subito su MakeHuman (plugin di Blender) e DAZ Studio.
Li ho trovati in questo ordine e mi sono fiondato sul primo, ben sapendo che Blender è un prodotto Open Source di altissimo livello. Una volta ho pure provato ad impararlo, ma ha una plancia comandi che neppure l'Enterprise e certamente io non sono un artista tale da giustificare uno sforzo di qualche giorno per iniziare a fare qualche scena in 3D: l'ho tenuto installato e poi mi sono limitato ad un decisamente più semplice e comunque per me più che adeguato anim8or.

MakeHuman è impressionante. Nella documentazione si legge che per realizzarlo hanno dovuto studiare anatomia in dettaglio e c'è da credergli. Partite da una figura umana base e vi trovate a cercare di modificarla, come fosse di gomma, in ogni suo più piccolo aspetto.

Volete la bocca un po' storta, un taglietto sul labbro, le narici più larghe? Vi serve un'espressione con gli occhi un po' infossati e stanchi? Per il vostro prossimo vampiro vi serve poter decidere la lunghezza dei denti? No, oggi modello un alieno con la testa come ET...
Alcuni volti base caratteristici sono già impostati, così come alcune strutture corporee, non vi resta che applicare il modello predefinito e usarlo come base per rilavorarlo di fino.
Chiaramente volete anche che l'uomo che avete disegnato cammini, raccolga oggetti da terra, salti, cerchi di prendere a pugni qualcuno, ci mancherebbe altro. E non potete sopportare che, girando la testa, i muscoli del collo non si tendano come nella vita reale.
Potete controllare tutto e poi renderizzarlo sfruttando Blender.

Ora che ci penso... tutto no... ci sono due icone che, accidenti, sono disabilitate: si tratta di quella che permette di disegnare anche i capelli e, molto peggio, di quella che permetterà di vestire i nostri personaggi (personalmente trovo inaccettabile inserire dei personaggi nudi nel presepe, escluso, al più, Gesù bambino...).

Beh, la versione che ho provato è una 0.9, queste caratteristiche sono promesse per la 1.0.
Personalmente l'attendo con ansia e sto già iniziando a lavorare alla sceneggiatura del mio film di animazione.

Facciamo un salto anche su Daz Studio 3D.

Vi serve un attimo per capire che il sito non mostra foto, ma personaggi renderizzati.
Qui hanno lavorato più a fondo sui materiali e sulle texture della pelle, delle iridi e per rendere particolari come la screpolatura delle labbra.

Qui i personaggi (i modelli base hanno dei nomi e sono proposti come attori e star - alcuni free, altri, molto più definiti, a pagamento) possono avere capelli (che si possono allungare ed accorciare) e vestiti (anche questi si possono adattare, rendere più o meno stretti).
Sono previste espressioni e posture predefinite, basta applicarle al personaggio e non sarà necessario fargli muovere il singolo muscolo: si posizionerà come da esempio.
Una curiosità: i modelli base non sono limitati solo ad umani nel vero senso della parola, ma anche anime e manga giapponesi: se avevate sempre sospettato che quei cartoni fossero un po' troppo uguali e precisi, giocando con questo programma ne potrete avere tutte le conferme.

Essendo un prodotto con fini commerciali (almeno, più espliciti di MakeHuman, nonostante dichiari di essere Tell-ware - sono contenti se ne indicate l'esistenza ad almeno due persone: con questo articolo dovrei andare pari, almeno spero), presta anche più attenzione alla compatibilità con i formati di file di altri sistemi più noti e di più alto livello (soprattutto Poser, riferimento essenziale, a quanto pare, per questo tipo di programmi).

Molto più user-friendly di MakeHuman, risulta anche meno flessibile, un po' troppo predefinito, forse un poco più asettico: i modelli presentano meno gradi di libertà, superati dai tanti elementi aggiuntivi precotti che si possono comprare: di diverse pettinature e abiti ne abbiamo già parlato, ma si possono comprare (e da altri siti anche scaricare gratuitamente) oggetti 3D di tutti i tipi per costruire mondi per i nostri personaggi: sedie, armadi, case, scudi e armature, animali e piante, etc. etc.

Il prezzo del singolo oggetto è abbastanza basso, perchè target è la massa.

Il presepe sarebbe una nicchia di mercato scoperta? Pensateci: si potrebbero vendere personaggi digitali, pastori e pecore, alberi etc. etc. per completarlo: strano che non ci abbiano ancora pensato.

Adesso ringraziatemi, perchè vi risparmio: originariamente avevo intenzione di continuare sulla strada indicata dalle ultime due frasi ed imbastire tutto un discorso su licenze Open Source e modelli di business, (mi sarei lasciato prendere la mano, sarei leggermente uscito fuori tema, ma quando mai non lo faccio? e poi, almeno su questo blog, lo svolgimento lo decido io...), che, in questo momento, mi stanno un po' assillando; ho, invece, deciso di fermarmi qui e, udite udite, di rimandare ad altro post quest'altro argomento.

Deve essere l'effetto dell'avvicinarsi del Natale: è bastato citare il presepe e sono diventato più buono

Bye
    Depa

P.S.: oltre ai programmi che gestiscono figure simil-umane, a partire da questi siti (o in questi stessi siti) si possono trovare anche programmi per realizzare paesaggi realistici ed animati (cito solo, come esempio Bryce e Terragen). Volevo ricordarvelo, ma, casomai, ne parleremo un'altra volta.
P.P.S.: per i più curiosi e giocosi, esiste anche un programma che genera volti in grafica 3D a partire da foto: si chiama FaceGen, se ne può scaricare una versione (ridotta e con scritte sopra alla testa) free.

[... continua ...] Leggi tutto

martedì 13 novembre 2007

Osservando distaccatamente babeli mediatiche



Miro, osservo, imparo. Se sto in ascolto posso migliorare. Se sono aperto ai suggerimenti posso cambiare.
A volte, per ricominciare è necessario cambiare nome.

Su queste basi si presenta, pirandellianamente, il Fu Democracy Player. Nome cambiato, appunto, in Miro e proprio oggi esce dalla preview pubblica e rilascia la versione 1.0

Cambiamento non impressionante, ma significativo, al punto da indurmi a questo nuovo post dopo la stroncatura di qualche mese fa.

Due al prezzo di uno: già che siamo in argomento proviamo anche a chiederci dove sia finito il tanto annunciato Babelgum, presunto concorrente di origini italiche di Joost.

Chiedendoci sempre, se non sia meglio uscire a farsi un giro, al posto che stare davanti alla TV ed al PC contemporaneamente.
Ai tempi del mio precedente approfondimento, il tempo era clemente, invitante, i dubbi erano ridotti.

In questi giorni, invece, fa freddo e tira vento. Bisogna pure cercare di sopravvivere allo sciopero dei mezzi e cercare di tornare a casina nonostante la natura si opponga, con gli alberi che si immolano tranciando le linee del tram, finendo di mettere in ginocchio il traffico di una Milano che Milano non è, che sgomita per cercare di tornarsene sul lago, in campagna, ma anche appena fuori dalla tangenziale, ovunque purchè non in strada, ferma.

Anche davanti alla TV o al PC.

Anche i pochi che viaggiano con (uno stupendo) Le mie italiane di Pennac in una mano e la sbarra del tram nell'altra, non appena arrivati in scompartimento lo ripongono nella borsa del portatile e si mettono a parlare con notepad, per allacciare dialoghi lontani nel tempo e nello spazio, lontani dall'adesso, dall'odore di bruciato dei freni del treno.

Sperando che siano i freni del treno e non la ventola del PC rotta che sta abbrustolendo la CPU, intendo.
Scartando a priori la possibilità che a fumare sia il cervello, oramai ai minimi termini per il poco sforzo critico che ci viene lasciato.
Perchè, forse, scrivere un blog è un modo per sforzarsi di parlare e pensare e non subire solo le informazioni che ci vengono iniettate dritte nella memoria a medio-breve termine, giusto il tempo di ricordarci cosa comprare domani al supermercato, prima di svanire per lasciare il posto a ciò che certamente vorremo desiderare dopodomani.



Avete DAVVERO selezionato Leggi tutto?
Grazie mille, anche se, al vostro posto, me ne sarei andato altrove perchè l'abstract era, oggettivamente, un po' consunto, un po' già visto, piuttosto banale.

Forse pensavate che, come al solito, nel body avrei parlato d'altro.

No. Sfortuna. Stavolta si parla davvero di recensioni di player. Noioso e banale (mica posso scrivere sette pagine di roba dense come una tazza di cioccolata tutte le volte), per questo sono riuscito a pubblicarlo a pochi giorni dal post precedente, rovinandomi la recente media di 1 post al mese.

E cercheremo pure di lasciare i lamentosi pianti su noi stessi e le paranoie sull'essere controllati fuori da questo approfondimento. Se vogliamo pensare, pensiamo, non è vero che non siamo liberi di farlo, e dovremmo anche iniziare a riconoscere il trucco.
Dovremmo sapere che i consigli della regia ci porteranno inevitabilmente a volere qualcosa che non ci passava neppure per la mente fino a qualche secondo fa.
Tra i diversi modi di uscirne, se è almeno in parte ancora vero che chiodo scaccia chiodo, possiamo provare a girarci, giocare coi figli, prendere un libro, girare per Internet, fare del sesso, vivere con le persone che amiamo, chiamare un amico, cercare Dio, fare una camminata in montagna, etc. etc.

E' veramente difficile la scelta tra essere cintura nera sulle puntate dell'ultima serie del Dr. House e cercare di migliorare la propria vita?

Se trovate che sia complicato riuscirci, meglio che lasciate subito questo post, perchè siete già conciati abbastanza male per conto vostro, ma se pensate di poter stare senza TV per una settimana senza gravi effetti collaterali, ok, andate avanti, parleremo di questa cosa di cui potete fare a meno e su cui, quindi, potete ancora fare delle scelte.

Visto che si tratta di un argomento interessante, ma neanche troppo, vediamo di chiuderlo in due parole.

Finalmente:
- hanno aggiunto permalink: si può scaricare un video, ma lo si può anche vedere, intanto che si scarica (dal sito originale, via browser, non ancora in Miro stesso)
- i filmati ripartono da dove avevate smesso di guardare (io lo trovo comodo)
- le ricerche non sono più così lente e la possibilità di estendere la lista dei siti su cui cercare è interessante (come il tentativo,

che non riesce spesso, peraltro, di catturare i video anche da siti non noti)
- non rischiate più il blocco del download se, intanto che scarica, potete girare tra gli altri canali ed impostare delle ricerche
- cancellazione dei download in sospeso e memo di download in corso quando si esce (ma ci voleva tanto?)
- presenza di canali in HD (bella risoluz... ah, già, ma l'ho downloadato, non è in stream...)

Problemi:
- ancora non legge/scarica da expertvillage (se non, ovviamente, per quei video che ExpertVillage trasmette anche via YouTube)
- paginazione risultati ricerche mancante: potete vedere un max di circa 20 risultati, anche se ce ne sono centinaia.
- appena installato parte con un tocco (unità di misura tecnica, corrispondente a 15,4 badilate irlandesi) di download predefiniti (a meno che non li abbia ripresi da una non completa deinstallazione di Democracy Player)

Inizia a diventare un tool da downloadare o, almeno, da tenere sotto controllo.

Da segnalare, en-passant, il tentativo di spingere gli utenti a realizzare la propria TV.

Un invito alla non passività, come il mio, o semplicemente una spinta a creare contenuti gratuiti? Comunque sia, interessante, quindi giocateci.

Su Babelgum, invece, c'è ancora meno da dire:
- sembra la copia di Joost, con piccole differenze grafiche (il telecomando è l'unica invenzione nella GUI, ma ha veramente poche funzionalità)
- ancora pochi (quasi nulli) i gadget
- ancora troppo pochi canali
- video di qualità, a prima vista, leggermente inferiore a quella di Joost (soprattutto a full screen)
- molto veloce lo spostamento (rewind, fast forward) all'interno del filmato che si sta visualizzando.

C'è ancora un bel po' di strada da fare, a quanto sembra e, nonostante sia italiano, c'è ben poco di italiano.

Ci sarebbe Vcast, se oltre a Mediaset non lo spengono anche gli altri, ma già come superamento della TV, con il videoregistratore. Che, se non altro, mostra fantasia nell'interpretazione limite delle licenze.

Bye
    Depa

[... continua ...] Leggi tutto

giovedì 8 novembre 2007

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