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

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

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

Oggi scricchiolo

Hanno iniziato le mie scarpe. Apparentemente.
Almeno, mia moglie mi ha fatto notare che le mie scarpe cigolavano, alla frizione con il terreno (non si è espressa così, io sto scrivendo, lei stava parlando). E l'ha sentito nel casino del supermercato.
Da quel momento ho iniziato progressivamente a notare che non era uno stridio o un cigolio (neppure un pigolio), ma, appunto, uno scricchiolio.
E che non erano le scarpe, ma io.
Mi sento come una diga con un inizio di crepa. E l'acqua, dietro, che spinge.
Siccome sono una diga pensante e in fondo ci sono un po' di paesi, cerco di tenere.
Devo trovare un modo di tenere.
Forse somatizzo, ma mi fa pure un po' male la schiena...

---

Questo post avrebbe dovuto trattare di generazione automatica del codice. Sarà per una delle prossime volte.
Ora ho problemi più seri.

Quindi, per la prima volta dall'inizio di questo blog (non so quante altre volte l'ho scritto in post precedenti, non serve che controlliate) sto usando questo strumento come diario, come sfogo reale.
E scrivo di getto, senza pensare.
(anche questo rischia di non essere del tutto vero: sto scrivendo una bozza, poi la rileggerò, cancellerò qua e là, cercherò di essere più diretto, cancellerò tutto, riscriverò da capo, etc. etc., ma è l'approccio più di getto che possiamo sperare di ottenere da me in questo momento: diciamo che, semplicemente, cercherò di non correggermi troppo)

La speranza è che un giorno rileggerò il tutto e mi farò una grossa e grassa risata. Ovviamente è più probabile che la rilettura porti a trovare tutto molto infantile e banale, come spesso mi capita quando mi azzardo a farlo, ma proviamo a puntare, comunque, sulla grassa risata. (Mi viene da sorridere al solo pensarci, guarda come sono rilassato, lì, nel futuro...)

Ma ora la pressione è forte: lavorativa, informatica (in sè, slegata dal lavoro), nella mia interpretazione del mondo.
Tiene la vita privata. Il che, tutto sommato, comunque, non è male.

Il lavoro pressa, non è inusuale.
Lo ha sempre fatto, è il suo mestiere, in fondo. E' solo che lo fa in modo insolito, curioso e poco elegante. Ulteriori approfondimenti, in questo momento non sono molto affari vostri (o dovrei dire tuoi, caro diario, che sei il solo che non può scappare e sei costretto a sorbirti il tutto, correzioni comprese). Anzi, non avrei neppure dovuto iniziare a parlarne, non insistete. Quasi quasi cancello questo paragrafo. Ma no, vah, leggetevelo lo stesso...

L'informatica mi opprime con il suo immobilismo (curioso, la scienza che non si ferma mai, quella che faccio fatica a starle dietro, che ogni 6 mesi passano 3 anni...).
Oggi mi sembra che non ci siano state novità sensibili da oltre 5-6 anni. Spero di sbagliarmi, spero che voi le vediate, io vedo solo nomi marketing che cercano di vendere vecchie tecnologie ed approcci - in particolare, non mi parlate di SOA, AJAX, Flex e varianti varie, per favore, non c'è nulla che non ci fosse già nel 2000 e forse prima! - e soffro per non essere io stesso a riuscire a trovare qualche punto di appoggio per la leva che crei il movimento. Mi hanno chiesto, recentemente, se non vado allo SMAU. E che ci vado a fare?
Sto aspettando un computer da indossare e sempre connesso di cui ho già parlato, o anche solo un programma che capisca cosa gli dico, che traduca correttamente, faccia per me ricerche su internet e scriva almeno parte dei miei allegati tecnici: se non c'è nulla di ciò, per favore, non svegliatemi. Va anche bene un robot che sappia stirare (seriamente, intendo!), se non avete altro da propormi e proprio non sopportate che resti apatico in questo angolo.

La mia interpretazione del mondo sta cambiando.
Non in meglio o in peggio, semplicemente sta cambiando: apparentemente tutto è più chiaro e completo, ma è sempre così, arriva un momento in cui, per folgorazione o erosione lenta, arrivi a percepire i dintorni in modo differente e ti sembra pure di cogliere i contorni e i dettagli e non solo delle macchie in movimento. L'esperienza insegna che dura un momento, ma pazienza. Per ora va bene così, non possiamo escludere a priori che questa volta possa essere effettivamente quella buona, manca solo il coraggio di cambiare per adeguarsi a queste nuove lenti.
Perchè, non so se è evidente anche per voi o è solo una questione di punti di osservazione differenti, ma se non mi sposto da qui, difficilmente riuscirò a raggiungere la mia meta.

Ed è con questo bagaglio di nuove certezze granitiche che nutro i miei dubbi, ancora una volta.
Depa a due velocità: quella mentale, a km da qui e quella di azione, anche lei a km da qui, ma alle spalle.
In mezzo la diga.
Lo scricchiolio.

Un rapido checksum, se non altro, sembra permettere di escludere azioni da un giorno di ordinaria follia: hardware e firmware sembrano al loro posto.
Troppi, come sempre, invece, i dati e come sempre in ordine e da organizzare. Mancano dei link, è ovvio.
Altri sono broken.

Scricchiolio.

Puntatori aperti, nella mia testa.
Alcuni sono cose da fare, quasi dimenticate, ma con un segnale luminoso che lampeggia.
Altri sono cose dimenticate del tutto. Forse importanti.

Cigolio. Questa volta erano le scarpe, però.
Mi metto in ascolto, per uno scricchiolio.
Niente.
Basta che non sia come il singhiozzo, quando sembra che stia per passare, ma forse è ancora lì.

Mi spiacerebbe scoprire che i link e i puntatori appesi riguardassero aspetti importanti della vita, diventati momentaneamente meno importanti e ora tornati come dovevano essere.
Già mi è capitato una volta. Mi ero quasi completamente perso, vagavo per zone deserte, ma mi rallegravo per la spiaggia ed il sole.
Per fortuna è arrivato un apparente momento difficile, seguito poi dai figli, che un po' prendendomi in braccio e un po' con la manina mi hanno riportato a casa. Priorità dei valori rovesciata, tornata a posto.
Ma ti spiace per il tempo perduto, resti deluso perchè ti ricordi cosa pensavi di te quando eri tu il bambino, per esserti accorto che la lista dei valori la dichiaravi in un modo e la vivevi nell'altro.

Scricchiolio. Visto? Che vi avevo detto?

Perchè i bambini la vedono molto più chiara? Perchè fanno domande, se sanno già le risposte? Maieutica?
Perchè dobbiamo rassegnarci a scambiare il nostro destino da imperatori del mondo conosciuto con quello da impiegatino asburgico?

Non vi viene da pensare, a volte, che quello scricchiolio, a pensarci bene, è un po' che si sente, ma guarda che l'acqua non c'entra nulla, deve essere il vento tra i rami degli alberi?

E questo pensiero vi rassicura davvero o vi preoccupa di più?

Bye

Depa

[... continua ...] Leggi tutto

Bentornati

Siete tornati, dunque, voi e i vostri hits.
Vi ho visti in forma di istogrammi.

Mentre eravate in ferie io ho lavorato (solo il blog si è fermato completamente).
Non è neppure una consolazione sapere che sono in vantaggio su di voi, che vi state alterando solo ora per la rarità dei tram non soppressi, che hanno cambiato percorso e non si capisce più come fare ad arrivare alla meta (in tempo sarebbe troppo anche in situazioni normali).

Non ditelo a me che ho colto la situazione nella sua completa chiarezza sotto ad una grandinata il 16 agosto sera, in area totalmente scoperta (neppure un cornicione nel raggio di 500 metri) di fronte al Cimitero Maggiore. Con autobus sostitutivo in ritardo. E vento che girava l'ombrello. Un assaggio del terzo e quarto girone dell'inferno messi assieme per dieci minuti. Senza neppure essere stato troppo lussurioso o goloso.

Eppure, nonostante i diversi cataclismi, il mio problema principale in questo periodo è stato quello di cercare di riposarmi in qualche modo, di trovare una qualche distrazione (ed il tempo per goderne), senza intaccare la necessità di lavorare.
Alla fine l'unica evasione, in queste settimane, me l'hanno fornita i libri (va beh, un po' di montagna nel week-end, moglie e figli, qualche cena fuori, ... ma che c'entra? non distraetemi e lasciate che mi pianga addosso inutilmente e per i motivi più futili almeno per una riga).

Libri anche attraverso aNobii (quanto tempo mi porta via? servirà a qualcosa? per ora ho inserito solo ISBN di due scaffali - ne ho diversi, non finirò mai... - e qualche tag: appena inizierò a commentarli, vedrete comparire una colonnina a questo blog).

Il problema (?) è che non trovo più libri che mi distraggano o mi interessino (soprattutto delle dimensioni da poter portare dietro in treno e tram) che non siano seri e pesanti.

Per questo ora sto leggendo Eco (neppure i romanzi, i saggi!) e argomenti di religione.

Se, date queste premesse (ed avendo letto le parole di colore oscuro al sommo della porta) trovate ancora il coraggio di andare oltre l'abstract...

---

Se son d'umore nero allora scrivo
frugando dentro alle nostre miserie:
di solito ho da far cose più serie, costruire su macerie
o mantenermi vivo
(Guccini - Avvelenata)

Per farvi entrare subito nel clima mentale da me vissuto in questo periodo, parto con alcuni estratti da 'Il superuomo di massa' di Eco:

Sappiamo benissimo che c'è un modo di vedere le strutture narrative come elementi neutri di una combinatoria assolutamente formalizzata, che non riesce a dare ragione dell'insieme di significazioni che la storia e la società attribuiranno poi all'opera.
[...]
Sappiamo d'altra parte che ogni sforzo di definire una forma significante senza investirla già di un senso è vano e illusorio, così come ogni formalismo assoluto non è altro che un contenutismo mascherato.
[...]
Tanto più che infine si prospetta un'altra serie, la serie delle interpretazioni, talora discordanti che, sulla base di motivazioni diverse e a diversi livelli di classe e di cultura, una udienza dà del messaggio che le perviene.

Incertezze interpretative, quindi, dovute alla difficoltà di dividere le strutture narrative dalla società e dai punti di partenza e dai pregiudizi di chi dovrà, in un dato momento, eseguire l'interpretazione.

Per quanto riguarda gli argomenti di religione, mi interessa molto approfondire questioni legate alla storicità di Cristo. Ovviamente Messori e Ratzinger (sono cattolico, ricordate?), ma anche le posizioni opposte (non si può essere obiettivi su questi argomenti, ma mi interessano comunque i diversi punti di vista), come Odifreddi (l'ultimo suo testo è un best seller del momento, facile che lo abbiate letto anche voi) o UAAR (Unione degli Atei e degli Agnostici Razionalisti, in cui troverete ancora Odifreddi e altri personaggi famosi e schierati contro la religione come la Hack), mediando un po' con Wikipedia ed altre fonti più o meno di parte prese da Internet (alcune pure buone).

Come già in altri miei post mi trovo a sottolineare la presenza di problemi dovuti a troppe e non certificate informazioni, che non possono fare altro che creare incertezze (o, come minimo, quel relativismo che preoccupa tanto Ratzinger).

Se il dubbio può essere anche sano, positivo e molla per successivi approfondimenti o fonte di profonde riflessioni e dolorosi combattimenti interiori, la difficoltà di distinguere le frasi buttate a caso da quelle ragionate, l'indeterminatezza fine a sè stessa o dovuta a tentativi di alzare polveroni o alla ripetizione acritica e non validata di altre fonti, alla stupidità, all'incomprensione, alla scarsa profondità o al fatto di dover comunque dire qualcosa è solo negativa e irritante.

A volte si sparpagliano le carte per nascondere la strada corretta, talvota, semplicemente, perchè non sappiamo fare altro che crearci casino da soli:

... non c`è nulla fuori dell`uomo che, entrando in lui, possa contaminarlo; sono invece le cose che escono dall`uomo a contaminarlo... " (Vangelo di Marco, 7,1-23)

Per rimanere più terra terra, non sembra un caso che Terry Pratchet e Gaiman Neil, in Buona apocalisse a tutti (va beh, ho letto anche qualcosa di non seriosissimo, in seguito ad un ottimo consiglio che faccio che girarvi, sottolineando, però, che non si tratta di un libro normale, pur essendo tutt'altro che serio e pesante) fanno pensare al demone Crowley, riguardo agli umani:

non c'è nulla che possiamo fargli che non si facciano da soli e loro fanno cose che non noi non avremmo nemmeno mai pensato, spesso utilizzando elettrodi

In questo campo possiamo trovare molti altri esempi di incertezza (da che parte sta il tentativo di misdirection?), come per esempio, quando si parla di Inquisizione e Galileo: si tratta di esagerazioni e leggenda nera o realtà storica? Abbiamo dei mezzi per capirlo, magari nel tempo? Possiamo risalire alla verità storica o siamo incatenati in quello che mi ostino a ritenere un gran brutto luogo comune, secondo il quale la storia la scrivono i vincitori?

L'incertezza delle fonti, l'immersione in una società che ci bombarda di fattoidi sono stati anche oggetto di una serie di interventi in un post nel blog di Isadora cui non ho potuto fare a meno di intervenire, che partiva dall'attualità di Fahrenheit 451 (ai tempi non lo avevo letto, nel frattempo ho corretto questa mancanza, bel suggerimento, grazie - ok, ok, so che state pensando che ho cercato di farmi passare per un lettore incontentabile e seriamente colto, per poi mostrare che mi basta un testo di fantascienza di diversi anni fa e un titolo di fantasy-umoristico-demenzial-filosofico, ma rendetevi conto che siete voi che pensate in modo molto malizioso e che non è colpa mia se oggi vi è andato tutto male).

E' evidente che il problema della qualità dell'informazione, sotto diversi aspetti, è molto sentito.

E' un po' come se fossimo arrivati al superamento del giornalismo:
- prima: mancava l'informazione, il giornalista la trovava e, almeno idealmente, la doveva validare prima di fornirla.
- ora: chiunque vi darà informazione (e relativa opinione, ci mancherebbe, lo sto facendo pure io), ma il problema è individuare le informazioni buone

Le cause e gli ambiti in cui si possono trovare cattive informazioni sono troppe, quindi non è facile correggere a monte il problema.

E' questa, a mio modo di vedere, la vera sfida dell'informatica del post-inizio-internet:
- estrarre le informazioni dal mucchio, con primo filtro sulla spazzatura e sulle 'distrazioni', evitando le ridondanze
- validarle con fonti controllabili

Il tutto il più dinamicamente possibile, perchè ogni operazione che facciamo su queste informazioni le cambia ancora e dobbiamo riuscire a sfruttarne la continua evoluzione, smettendo di raccogliere solo montagne di dati, ma iniziando ad usarli per davvero.

Chiuderei ancora con il già citato testo di Eco, che cita Dino Segre, che a sua volta cita molti altri autori, per aforismi, in Dizionario antiballistico (anche a voi l'iterazione di ipse dixit, al posto che rassicurare fa pizzicare il vostro senso di ragno?), mostrando come Pitigrilli avesse acutamente notato che l'aforisma (di cui lui faceva grande uso) possa essere rovesciato senza perdere forza (mostrando chiaramente quanta vuota conoscenza sia contenuta in tali espressioni e nella cultura che su di esse si basa - ce li avete anche voi, a casa, gli aforismi di Oscar Wilde?):

Talora Pitigrilli si è divertito ad allineare aforismi di autori diversi, l'uno che negava l'altro, entrambi autorevolissimi, sotto la voce "facciamoci un'opinione":

Non ci si inganna che per ottimismo (Hervieu)	Si è più spesso fregati dalla diffidenza che dalla fiducia (Rivarol)
I popoli sarebbero felici se i re filosofassero e se i filosofi regnassero (Plutarco)	Il giorno che vorrò castigare una provincia la farò governare da un filosofo (Federico II)

Ed è così che, un po' marzullescamente rischiamo di accorgerci che gli aforismi stanno diventando la fonte della nostra conoscenza quando, addirittura, non ci viene richiesto di condensare la nostra conoscenza in aforismi.

Bye

Depa

P.S.: non chiedetemi nulla riguardo all'ultima frase, risolvetevela per conto vostro.

[... continua ...] Leggi tutto

Narciso Yepes e la chiave del quindici

Narciso Yepes, diventato noto al grande pubblico per aver suonato con la sua chitarra classica il pezzo centrale della colonna sonora di Giochi Proibiti, soleva ricordare di aver imparato le basi da un grande maestro che, però, non era un chitarrista, ma un pianista, Vincente Asencio.
Asencio gli faceva sentire al pianoforte cosa doveva suonare. Quando lui gli diceva che non era possibile ripeterlo con la chitarra, Asencio gli rispondeva che, se non poteva fare nulla con quello strumento, avrebbe fatto meglio a cambiarlo. Così Yepes studiò nuove tecniche, riuscì a ripetere gli esercizi proposti, diventò uno dei massimi virtuosi del mondo, arrivando a tenere concerti con la chitarra estesa da 6 a 10 corde dal liutaio Ramirez secondo i suoi suggerimenti.

Questo aneddoto deve essere molto noto perchè è facile incontrare persone che si immedesimano in Yepes.
Qualche virtuoso esiste anche, ma non è raro vedere usare strumenti sbagliati nei modi e momenti sbagliati, con tentativi di estensione ed estremizzazione, ma senza prima averne approfondito i limiti.

Come chi cerca di usare la chiave del quindici su un bullone da 12 o un martello per svitare un dado, talvolta i risultati possono non essere quelli sperati (ben vengano le eccezioni, ovviamente!).

In questo senso, uno degli esempi più comuni nell'informatica è quello di considerare l'XML come ingrediente fondamentale e irrinunciabile. Non importa per cosa, l'importante è usarlo.

---

Qualcuno di voi sarà anche saltato sulla sedia, ma l'XML, che mi conosce, sa che non deve prendersela, dal momento che gli è ben noto che lo uso con quotidiana assiduità.

Ci frequentiamo almeno dal 1996 1998 e non se la prende se continuo a sottolineare l'ovvio, ovvero che continuare ad evidenziare che è uno standard è utile quanto confondere Java con la sua sintassi di base.

Perchè di standard, nell'XML c'è solo quello: la sintassi.
La semantica bisogna sempre implementarla, come credo sia ben noto.

Dtd o Xml Schema servono per rafforzare la sintassi, anche se a diversi livelli, ma per usare quei dati incastrati tra un tag e l'altro, serve sempre un programmatore.

Spero, infatti, sia a tutti palese che, anche usando l'xsl(t), anche se dichiarativamente, anche se tra mille limiti e salti tripli per fare cose banali in altri ambienti, stiamo sempre scrivendo regole, filtri, semplici trasformazioni, qualche controllo, ovvero: programmando.
A questo proposito, giusto per fare un esempio che mi piace sempre sottolineare, progettare una architettura multilivello, separando bene la presentation dalle business rules e poi decidere coscientemente di buttare la possibilità di usare competenze e strumenti specifici del front-end (esperti di html e javascript, grafici che costano tipicamente meno di programmatori e strumenti WYSIWYG che permettono un disegno rapido) usando xml ed xslt per generare il layout e manutenerlo è veramente un peccato.

Senza considerare che il carico (sia in termini di heap che di cpu) per il parsing ed applicazione delle regole rischia spesso di essere significativo rispetto all'utilizzo di altre tecniche (magari compilate, come una buona vecchia JSP).

Comunque, se il fatto che si debba fornire la semantica programmandola e che sia ragionevolmente sconsigliato sfruttare l'XML come base di un template engine/layout manager fossero gli unici problemi non avrei scritto questo articolo. Si tratterebbe di peccati veniali.

Ciò che mi preme sottolineare è la tendenza all'esagerazione nell'utilizzo di questo seppur utile e versatile strumento.

Per esempio, come strumento per memorizzare dati, in ambiti complessi.
Per fare un esempio pratico: non mi direte che non avete mai visto un CMS xml-based, vero?
Io ho anche visto citare questa feature come elemento distintivo di certi sistemi, laddove il pubblico (e talvolta l'oratore) non era in grado di cogliere che:

• la stessa flessibilità descrittiva si può ottenere anche con un bel database, con la stessa facilità (i casi cui mi riferisco riguardano progetti di una certa dimensione, dove non è neppure messo in dubbio che esistano altre funzionalità per cui è necessario ed irrinunciabile un bel RDBMS)
• ricercare valori di tag in XML salvati sul filesystem non è operazione propriamente performante: per risolvere questo tipo di problema è solitamente necessario ricorrere ad altre strutture architetturali (es: estrazione preventiva dei metadati e loro indicizzazione - non di rado appoggiandosi ad un RDBMS, o, talvolta, addirittura riscrivendo da capo funzionalità che sono oramai consolidate e super-performanti da anni in quei sistemi -, cache multilivello, etc. etc.)
• come sopra citato, per la famosa estensibilità garantita dall'XML bisogna programmare: lo so bene che non è sempre necessario farlo all'aggiunta di un nuovo campo in un CMS, - a patto di rimanere entro certi limiti, beninteso -, ma per quello che mi è capitato di verificare nella pratica o si rientra in situazioni quasi banali e gestibili anche più facilmente su DB, o si devono comunque battere quelle costose 10 benedette dita sui tasti.

Un altro caso tipico è la generalizzazione "hand made", tipicamente in fase di configurazione di un sistema: il costo dell'interprete vale il vantaggio della generalizzazione? ci lamentiamo della reflection e aggiungiamo un intero interprete? anzi, a volte aggiungiamo pure la reflection come modalità di costruzione di oggetti generalizzati nell'xml, da far richiamare in una Factory e/o in un Singleton allo startup?

Non so se vi siete resi conto delle risorse richieste per l'elaborazione, soprattutto usando DOM - a proposito, su .NET c'è il parser SAX, o si va solo di DOM? io non sono riuscito a trovarlo...:

• tempi per il parsing (SAX e DOM)
• tempi per costruirsi gli oggetti (automaticamente nel DOM, spesso 'a mano', più leggeri, con parser SAX based)
• heap che si riempie facilmente (che so: mai provato un out of memory in Java per import dati massivo via XML, passando da un parser DOM?)

Vediamo di esaminare anche i vantaggi, per capire dove ha senso usarlo, almeno IMHO (in italiano verrebbe IMMP, fa schifo, spero lo capiate, senza considerare che la 'M' di 'Modesto' poco mi si addice):

• la standardizzazione di questa sintassi aiuta nell'avere dei parser e ci sono molti casi in cui un parser bell'e pronto è proprio ciò che ha ordinato il dottore (per esempio, per estendere un linguaggio con tag libraries/web controls)
• esistono casi - rari e semplici, purtroppo - in cui una bella trasformazione xslt è comunque decisamente più semplice da scrivere di un programma (es.: per creare dei pdf - xsl-fo - magari a partire da un html: bisogna lavorare un po' sull'xsl, ma fare uno spider che si naviga il sito in un certo ordine e ne produce un libercolo in pdf è alla portata - mi dicono che il Mac lo faccia di default, è vero? per PC, tra gli open source, di decente ho trovato solo HTMLDOC, anche se non si naviga da solo gli url delle pagine - ; ancora: nel passaggio di dati da un sistema ad un altro, spesso è utile trasformare un XML proveniente dall'esterno in un XML in formato già gestito dal nostro sistema, per rielaborarlo senza ulteriori sviluppi e un filtro di questo tipo scritto in xsl è la morte sua).
• laddove le descrizioni dei dati (dai tracciati record alle immagini SVG) sono complesse e questi dati devono essere scambiati tra sistemi o essere alla base di programmi per cui ha poco senso aggiungere un database, l'XML è decisamente più adatto di altri formalismi (es, il vecchio EDI), essendo potenzialmente molto più ricco, espressivo e permettendo di condividere e validare la sintassi in modo più mirato.

Proviamo un piccolo riassunto di casi pratici, relativo ai punti su cui solitamente mi sento o non mi sento di usarlo:

NO

• in generale, per evitare di gestire documenti su DB (es. del CMS) o come modalità di estensione dei campi nel database: non posso fare ricerche e join in modo performante, devo parsare ed intepretare il mio file ogni volta (a meno di pre-parsing ed indicizzazioni di cui si è già parlato - ma come gestite l'indicizzazione? la delegate al DB o la gestite a mano? vi siete ricordati di indicizzare tutti gli elementi e lasciare il testo ad un motore di ricerca full-text? i valori dei tag sono codificati o si tratta di stringhe, pure inserite manualmente?). Indizi del fatto che non va così bene: a parte i tempi di sviluppo di eventuali indicizzazioni e recupero dei dati, dovete usare uno o più livelli di cache e, in caso di miss, la relativa interpretazione porta via 2 ordini di grandezza o più del tempo necessario per recuperare il dato pre-interpretato dalla cache (2 ordini di grandezza è troppo: sarebbe bene che le cache correggano 1 ordine di grandezza, altrimenti è indice di seri problemi nell'operazione fuori cache: se non ci sono alternative, fate bene ad usarle, ma se le alternative ve le siete precluse da soli...).
• XML per memorizzare oggetti:
• non vi piaceva la serializzazione nativa di Java e davvero pensate che questa sia più veloce? provate a fare un profiling e non dimenticate la gestione del versioning delle classi).
• la versione in xml potete passarla come risultato di un Web Service? in linea di principio va bene, ma usare qualcosa di già pronto - es: SOAP - e passare direttamente l'oggetto era troppo standard?
• vi serve per estendere il DB? v. sopra.
• Volete farvi da soli il vostro OODBMS? Forse è il caso di considerare qualcosa di già pronto (ma non prima di aver considerato che, comunque, si tratta di tecnologie ancora molto discusse e, come minimo, un po' immature)
  
• XML alla base dello strato di presentation: in questo caso si ha la perdita di performance per interpretazione vs. compilazione di cui ho già parlato; vi sentite più flessibili nel definire le zone del sito e le pagine? avete contato bene il costo di manutenzione, la flessibilità e quanto vi è costato realizzare un Template Manager di quel tipo, fuori da ogni standard?.

NI [situazioni da pesare, caso per caso: personalmente non ho ancora trovato una regola]

• XML come file di configurazione [rischio: overdesign (in molti casi basta un file di properties) - possibile vantaggio: flessibilità ed espressività (soprattutto quando servono diversi livelli di approfondimento)]
• XML come metadato (es.: base per Xlink o, più in generale, per il Web semantico ed RDF) [rischio: performance povere per mancanza indicizzazione o indicizzazione manuale, difficoltà nell'eseguire query, difficoltà di documentazione - possibile vantaggio: distribuibilità, laddove le performance non sono importanti, maggiore disponibilità di ambienti per eseguire parsing xml rispetto ad installare un RDBMS

SI

• XML per trasferire dati ed aumentare l'interoperabilità tra applicazioni (in tanti sostengono che sia nato per questo ;) ):


• Web Services
• base per Web 2.0, a partire da RSS/ATOM
• come sorgente dati remota (in particolare come RE in REST)
• in generale, per disaccoppiare i sistemi


• XML come base per il formato di memorizzazione di una applicazione standalone laddove usare un DB sarebbe un po' eccessivo (es: state scrivendo Open Office e decidete di salvare in dati in locale, in formato portabile, aperto e facilmente trasformabile; i vostri dati, in questo caso, tipicamente non richiedono ricerche cross tra i diversi xml, al più solo all'interno di uno stesso documento
• come base per definire nuovi linguaggi che richiedano interpretazione ed esecuzione: Apache Ant docet e certamente ha senso, dal momento che, in questi casi, comunque bisogna scrivere un parser ed un interprete e trovarsi con metà del lavoro fatto (e anche bene) non può che far piacere; altri esempi sono linguaggi che descrivono regole inferenziali (es: XML Rule Language in JBoss Rules - ex. Drools - ma, attenzione, nel manuale anche loro stessi dicono: 'There are several scenarios that XML is desirable. However, we recommend that it is not a default choice ...') o linguaggi che descrivono comportamenti che necessitano di un controllo di esecuzione (es: per definire dei workflow o - con un salto di fantasia di un centimetro e mezzo - come base per il governo di un ESB, come nel caso di BPEL).

Avete altri esempi? Avete elenchi di altri metodi architetturali usati malamente?
Non siete d'accordo su quanto ho detto dell'XML e ne volete parlare?
Beh, provate a darmi un feedback, prometto che se ne ho voglia ci penso su...

Bye

Depa

P.S.: poi magari salta fuori che avete ragione voi
P.P.S.: per quanto improbabile, intendo... ;)

[... continua ...] Leggi tutto

Uno, nessuno e centomila

Inizia tutto dal dover approvare un commento del Depa. Siccome sapevo (via, diciamo che ne ero ragionevolmente convinto) di non essere io (sto invecchiando, ma non ancora così tanto da non ricordarmi di aver messo un commento al mio blog 5 minuti prima), evidentemente doveva essere un altro (un passaggio logico un po' complesso, spero siate riusciti a seguirlo - magari potete leggerlo ancora una o due volte, finchè non vi convince).

Leggendo il testo del commento si chiariva, infatti, che si trattava di omo-nick-nimia.

Sapete bene che già mi ero accorto di non essere il solo Depa. Oggi posso dire di aver passato serenamente e definitivamente quel brutto contraccolpo psicologico e, anzi, trovo che possano nascere dei possibili sviluppi interessanti.

---

Certamente questo post nasce all'insegna del titolo di Pirandello.
E certo l'estratto che riporto sotto della Wikipedia su questo argomento non aiuta ad alleggerire il senso di inevitabilità che incombe sul post (e sulla necessità di non arrivare alla follia del personaggio principale, ovvero io):

Dal punto di vista formale, stilistico, si può vedere la forte inclinazione al monologo del protagonista, che molto spesso si rivolge al lettore, ponendogli interrogativi e problemi in modo da coinvolgerlo direttamente nella vicenda, che è senza dubbio di portata universale. La lunga gestazione dell'opera potrebbe far pensare che essa sia frammentaria e disorganizzata. Al contrario essa può essere considerata come l'apice della carriera dell'autore e della sua tensione narrativa.

Dovrebbe essere ovvio a chiunque che chi l'ha scritto non si stava riferendo a Pirandello, ma al sottoscritto e a questi post, in cui vi tiro in ballo continuamente, in mezzo a testi lunghissimi, elaborati e (non avrei saputo esprimermi meglio) di portata universale.

Ma torniamo a noi, per vedere se si possa riuscire a cogliere dei risultati utili, nonostante le premesse.

Il Depa che mi ha scritto è un disegnatore di professione (lui tende a minimizzare, ma non dategli retta) e ha un suo blog in cui pubblica alcune sue creazioni. Oltre a piacermi i disegni, (i fumetti non li ho ancora letti), apprezzo moltissimo il fatto che usi il blog in un modo completamente diverso dal mio - così non mi fa concorrenza ;) - e che si possa, comunque, riconoscere un gran bel lavoro ed impegno sottostante. Gli rinnovo i complimenti.

A questo punto sono stato stimolato a cercare altri blog di altri Depa. Brevemente i primissimi risultati:

- Il Depa: Blog variabile, non intensissimo, ma con alcune perle (cercando bene). Ovviamente questo commento è soggettivo ed alterato dal risentimento (acc... lo psicologo non mi aveva detto che era passata?), perchè è quello che mi ha preceduto sul titolo del blog.
- Depa Campeon: Il suo sottotitolo riporta 'il depa come non lo avreste mai voluto vedere'. Blog con argomenti molto (troppo?) vari, forse come le sue professioni ('un sacco', dice) con leggero orientamento verso il calcio.
- Depa (89): il più giovane, di quelli che ho trovato, che, finora, si è espresso solo in giugno e che cerca di parlare con i suoi amici (ma ci tiene a far vedere che gli piace di più incontrare le sue amiche) e usa troppe 'K' per i miei gusti. Frequenta l'agraria a Voghera, da quanto si capisce dai 3 post e ha circa 18 anni. Alla sua età (20 anni fa! acc...) abitavo anch'io a Voghera e mia sorella faceva l'agraria. Il che non vuole dire nulla, concordo.
- Un Depa laziale: Curiosamente il 17 giugno pubblica lo stesso test che il Depa vogherese (sono quasi coscritti, al più si mancano di pochi mesi) aveva postato il 12 giugno. Si conoscono?
- Siccome non possiamo lasciarci sfuggire le altre arti, di fila un Depa musicista ed uno attore (sui blog mi astengo dal commento).

Immagino che con questo elenco voi possiate capire almeno chi io non sia. Forse credavate o avete creduto che io fossi uno di quelli. Quando ho iniziato il mio blog, un mio amico è finito in uno degli altri e mi ha fatto un commento che non capivo.
Fa pensare. Gente che mi conosce da tanto tempo ha seriamente creduto che io fossi un altro.

Sappiamo tutti che su Internet è facile non essere riconoscibile, nascondersi dietro ad un nickname, cambiare identità come Mattia Pascal e diventare un altro. E non impazziremo come Vitangelo Moscarda, perchè possiamo scegliere chi vogliamo essere. O annientare la nostra personalità quando vogliamo, per farla rinascere diversa su un altro blog.

Sembra il superamento di Pirandello, eppure l'impressione è che, se dovessi pensarci ancora un po', non so se riuscirei ad evitare il finale già scritto. E, comunque, sembra difficile tirarci fuori qualcosa di utile.

La soluzione potrebbe essere quella di spingersi ancora oltre: creare una comunità di Depa (non di recupero, una comunità virtuale, una community). Tutti i Depa ci si ritrovano e, rappresentando persone che sono o non sono, con diverse - tutte, potenzialmente - caratteristiche e le competenze, possono vivere tutte le vite virtuali che vogliono.
Il nome o il nick diventerebbe l'unico punto fermo comune tra tutti questi Depa.
Con enormi vantaggi:
- aumento delle visite sui rispettivi blog
- scambio di competenze
- possibilità di conoscere altre persone (senza sbagliare mai il nome, per giunta)
- marketing del proprio nome (che tende a diventare un brand)

Chiaramente potrebbe anche diventare una moda e dilagare: altri potrebbero voler variare il proprio nome in Depa (o semplicemente fingere di essere Depa - tanto su Internet...). Tempo qualche mese e si potrebbero avere milioni di Depa registrati.

Lo vedete anche voi, il business? Certo, ci vorrebbe un testimonial famoso. Esiste una risposta già pronta: Depa Billaba, maestra Jedi.

Tutto torna.

Esiste solo il rischio di essere sopraffatti dal fatto che la stessa idea possa essere utilizzata da chi si chiama Rossi...

Bye

Depa

[... continua ...] Leggi tutto