sabato, novembre 29, 2008

C#: Perdita di eleganza?

La prima volta che incontrai sulla mia strada il linguaggio C# fu nel 2003, era ancora un linguaggino molto molto MOLTO Java-style, quasi clone, con alcune features in più come boxing e unboxing, property, delegate, eventi e qualcosina d'altro.

Oggi, alla release 3.5 del .NET framework, assistiamo ad una evoluzione del linguaggio a dir poco sconvolgente! Lo dico in senso positivo da un certo punto di vista, in senso negativo da un altro:

Lati positivi dell'evoluzione del linguaggio C#
  1. Aggiunte features che permettono di modellare il software in maniera più flessibile, vedasi generics con constraints;
  2. Aggiunte features che semplificano la realizzazione di pattern comuni in maniera meno verbosa, vedasi iteratori e delegate.. anche se già dalla prima versione;
  3. Aggiunti strumenti per la cooperazione tra sviluppatori, vedasi classi e metodi parziali.
Lati negativi dell'evoluzione del linguaggio C#
  1. Metodi estesi, non hanno ancora un corrispettivo nell'esperienza comune (pattern che li vedano come strumento da utilizzare realmente);
  2. Metodi partial: si tratta in fondo di metodi virtual non puri ma senza codice (solo più efficienti.. ma i compilatori d'oggi risolvono anche quel problema!);
  3. generics: ancora problemi con i vincoli, da aggiungere features in questo caso:
    class Classe where T: operator > {...}
Insomma.. butto il sassolino: trovo che l'entropia di C# stia aumentando, portando ai problemi di utilizzo di ADA e Haskel! Voi che ne dite?

mercoledì, novembre 12, 2008

Nasce OpenTVF

Ragazzi.. nasce OGGI OpenTVF su sourceforge.. andate a dare un occhio! ;) Se qualcuno è interessato a collaborare con lo sviluppo di OpenTVF... é sempre ben accetto! :D

A BREVE... metterò su sourceforge anche altri progetti che per troppo tempo ho tenuto nel cassetto.. se poi qualche interessato mi darà una mano a renderli qualcosa di più appetibile per l'utente finale.. MEGLIO!

A prestisismo.. HAPPY CODING!!! ;)

mercoledì, novembre 05, 2008

Drago Magnus

Come avrete notato la DeA ha buttato fuori una quintalata di raccolte/enciclopedie/corsi/ecc ecc in fascicoli a partie da quest'estate; tra le tante ce n'é una intitolatea semplicemente "Draghi" che propone delle miniature, a detta loro da collezionare e basta.. ma io trovo che siano più divertenti da dipingere! Voi che ne dite? ;)

Vi prometto che la metterò anche su Picasa così che sia scaricabile in dimensioni originali.. solo che prima vorrei scattare qualche foto un po' più "ambientalizzata" e contestualizzata, con altre miniature (che ho già dipinto) in maniera da simulare una piccola bataglia "nani VS drago magnus".

P.S.: Chi di voi si ricorda chi è il drago magnus? Indizio: anche se nella foto non si vede, lo scudo l'ho dipinto di bianco con una croce rossa! ;)

mercoledì, ottobre 22, 2008

Diamante condannato

Diamante condannato


Una preziosa pietra,
rara tra coproliti,
risplende affannosa
nell’olimpo tra miti.

Non solo per natura
le doti son innate,
elogio di bravura
per sfide affrontate.

Diamante condannato,
solitario viaggio,
sogno decapitato
d’unione col raggio.

Onnipotente,
un dio “fato” eleva valorosi
che esternano spontaneamente.

martedì, settembre 16, 2008

J2EE SecurityService: potente ma...

...decisamente "entropico"!

Niente da dire su JAAS lato autenticazione, realizzato un po' sul modello di PAM (con cui tra l'altro può interagire), JAAS è decisamente costruito bene dal punto di vista dell'autenticazione.. per J2SE.. in J2EE le cose non vanno altrettanto bene dato che:
  1. ci si può autenticare in Ackerman(N,N) modi con N>3... il che tradotto da "modoDiDire" a "italiano standard" significa "troppi";
  2. l'autenticazione avvenuta in ognuno di questi modi porta a risultati diversi.. se almeno uno potesse scegliere una delle modalità di autenticazione qualunque (la più standard, la più comoda, ...) ottenendo lo stesso risultato... invece ci si può autenticare:
    • lato web-tier, utilizzando uno dei metodi vari (BASE,FORM,DIGEST,CUSTOM ecc) con identità salvata lato web-tier e propagata lato EJB;
    • direttamente tramite API dell'AS (come "com.sun.appserv.security.ProgrammaticLogin" in glassfish) saltando tutti i meccanismi di autenticazione standard.. e anche questo lato web e lato business con enormi differenze sul risultato;
    • utilizzando librerie che interagiscano con JAAS e con il SO, ad esempio per effettuare il login usando l'identità locale dell'utente (ad esempio un client di una applicazione EE potrebbe usare le credenziali di Windows o di PAM in Linux, Unix, MacOSX, "/.*[xX]/");
    • creando un proprio LoginModule e Realm (tanto per aggiungere entropia.. finiremo per confonderci con il "rumore di fondo"!!!)...
    • ...mi fermo ma potrei proseguire, sicuramente uno standard (anche de-facto) farebbe piacere.
  3. autenticazione=??? Ok, abbiamo controllato tutti i LoginModule di questa terra, username+password, impronte digitali, scansione retinica, statistiche di digitazione, impronta vocale, eco nel padiglione auricolare destro, ecc ecc... e mò? Salvataggio di Subject, Principal, Credentials... Tutto qui? E poi? Perché devo scrivere nel subject che sono "Gabriele Lombardi", creare un principal con dentro scritto "Gabirele Lombardi" e magari salvare le credenziali "Gabriele Lombardi"+"PasswdFuffa"???
Ma mica abbiamo finito.. eh no! Diamo un occhio lato autorizzazioni, da questo lato l'architettura è stra-fine: gestione di risorse, gestione di policy sulle risorse, di regole nelle policy, di permissions sulle risorse, di...
...insomma un casino!

Allora, dico io, va bene che bisogna poter fare mille cose.. che la sicurazza è una cosa, che bisogna essere generali e che usare i DesignPatterns aiuta a sviluppare software riutilizzabile e corretto... però a tutto c'é un limite! OPPURE...
Bene.. cari Sunnisti, esiste un simpatico BANALE pattern GOF di nome "Facade", lo usate sempre... ci sono package che fanno anche il caffé e nelle API pubbliche se ne vedono 4 classi/interfacce/annotazioni in croce! (Vedasi javax.persistence... fa l'impossibile.. ma "di nascosto")... usarlo anche per il SecurityService no eh? Magari usarlo UNA SOLA VOLTA ma bene.. creando un solo standard di accesso al servizio... non 27 modi diversi, non standard, vendor-dependent... e in generale diversi o peggio... quasi uguali ma con sfumature "cangianti"!!!

DETTO QUESTO...

Butto li una domanda-esempio: se volessi gestire dinamicamente utenti (e gruppi di utenti/gruppi organizzati in un DAG) nonché risorse (organizzate ad albero o DAG anche loro)... e poi volessi creare dei permessi che associno risorse e utilizzatori (utenti o gruppi) in maniera da poter risolvere i permessi sfruttando ereditarietà sia sulle risorse che sugli utenti/gruppi... come potrei fare? Ovviamente il tutto lo voglio fare dinamicamente.. non voglio uno staticissimo policy-file!

ESEMPIO:

RISORSE:
  • PhotoGallery
    • Gallery1
    • Gallery2
con permessi ordinati "edit">"comment"> "browse" (cioè che si implicano l'un l'altro).

UTENTI:
  • Users
    • Admin
    • Owner
    • KnownUser
PERMESSI:

  • Admin->Risorse: "*"
  • Owner->PhotoGallery: "*" (o "edit" dato che implica le altre)
  • KnownUser->Gallery1: "comment"
  • User->PhotoGallery: "browse"
Al che "Ciccio", associato al gruppo KnownUser, può vedere tutte le gallerie, ma può commentare solo Gallery1 e non può editare. "MasterOfPuppets" associato al gruppo Admin può fare tutto, mentre "QuiQuoQua", owner della galleria, può fare tutto.. ma solo sulla (sua) galleria.

Soluzione? Ovviamente costruibile a run-time.. cioè creando la struttura di risorse e utilizzatori a run-time aggiungendo tuple in una o più tabelle, creando le tuple di utenti e gruppi e creando le tuple per i permessi.

Vi prego... FLAMMATEMI questo post, così magari ci capisco un po' di più!!! ;)

lunedì, agosto 18, 2008

Diamo forma ai libri..!

Alla fine le poesie sono fatte per essere scritte.. e lette! Quindi eccovi la mia prima pubblicazione poetica ufficiale:

Deliranti sentieri...
...in versi sparsi.


Giusto per dare forma ai pensieri.. tipo forma di "parallelepipedo sfogliabile"! ;)

giovedì, agosto 07, 2008

Mutevole erotismo

Mutevole erotismo


Fantasia fervida,
ricerca di novità,
il docle piacere
d'un sogno proibito;
di tabù superati
è plasmata l'unione.

Fine delle idee,
nullo desiderio
d'arti spericolate;
sensibile profondo,
gustato a pieno,
l'amore passionale.

La sottomissione
all'amante deciso,
la prevaricazione
d'uno schiavo dolce,
scontro d'intensi sguardi:
si miscelan' i sensi.

Riscoprendoci dentro,
sbizzarrendoci fuori,
usando corpi nudi,
assaporando ogni
sfumatura d'anime,
siamo sempre più "NOI"!


Gabriele Lombardi

mercoledì, luglio 02, 2008

Sgretolandoti

Sgretolandoti


Mente d'instabile,
veloce deriva
d'una dolce pensatrice:
s'aggrovellano idee,
paure, proiezioni
d'un mondo che mai
fu meno reale.


Gabriele Lombardi

Fresche e lucenti... nell'oscurità

Fresche e lucenti... nell'oscurità


Perle trasparenti brillano:
da tiepidi raggi trafitte,
rotolano inermi lungo stami,
abbandonano i giovani germogli
per lanciarsi nell'abisso
ove non faranno ritorno.


Gabriele Lombardi

giovedì, maggio 15, 2008

Stagioni diverse

Stagioni diverse


Rotean ingranaggi
d'esseri mutevoli,
splendore rugginoso;
alternarsi frivoli
osservo personaggi.

Essendo incapaci
d'introspetta puntura,
dolore fastidioso
alimenta paura,
vegetano felici.

Rarament'intendendo,
ponendomi quesiti
vi osservo dubbioso:
contorto è l'animo,
lo sto somatizzando.

Gli umani son siti
d'intricati terrori:
chi diviene furioso,
chi rovina d'amori,
chi lavor'appassiti.

Io m'osservo: perdente
comprendo di non poter,
nell'animo fumoso,
duro nocciolo scorger:
sconfitta è sovente.


Gabriele Lombardi

mercoledì, maggio 14, 2008

Sambuco in fiore

Ragazzi, in questo periodo la natura si è svegliata e sembra impazzita. La camomilla romana ed i papaveri invadono i campi e le piante di sambuco riempiono l'aria di un profumo dolciastro. Maaa.. lo sapevate che:
  1. Il sambuco è una pianta commestibile, non tossica, i cui fiori hanno mille usi.
  2. In questo periodo i fiori aperti (e belli profumati) possono essere fritti in pastella (come i fiori di zucca) e comodamente mangiati utilizzando il picciolo del fiore come "manico".
  3. Per produrre un buon liquore al sambuco (non identico alla classica sambuca) è sufficiente raccogliere i fiori, separare i singoli fiorellini dal picciolo "sgrullando" il fiore su un giornale e tenerli in "infusione" per 40 giorni in alcool puro (in maniera tale che i fiori riempiano completamente il barattolo in cui sono posti); dopo questo periodo è sufficiente per ogni litro di alcool aromatizzato versare in una pentola un litro di acqua e 700g di zuccero e portare ad ebollizione (facendo sciogliere completamente lo zucchero con un cucchiaio), infine miscelare bene i due liquidi e lasciar raffreddare. La raccolta e separazione dei fiori dai piccioli è un'operazione velocissima (le piante di sambuco si trovano ovunque ed i fiori maturi si staccano subito), purtroppo bisogna aspettare 40 giorni (agitando di tanti in tanto il barattolo), però la preparazione finale del liquore con acqua e zucchero è un lavoro da 10 minuti!!!
  4. Sambuco è anche un comune di 84 abitanti in provincia di Cuneo ;)
  5. Il suo nome deriva dal greco, "sambuchè", una specie di flauto costruito rimuovendo il modollo morbido dai rami più grossi.
  6. E' una pianta emolliente e sudorifera, i fiori sono diaforetici, i frutti sono lassativi e la corteccia è diuretica. (ne ha una per ogni esigenza ;) Inoltre i fiori possono essere usati contro l'influenza tramite infusi e come astringenti per la pelle se se ne utilizza il decotto.
Tutto qui? No no: gli usi del sambuco sono 1000 e 1000.. ma non vi voglio togliere il piacere della scoperta, Google is your friend ;)

martedì, aprile 15, 2008

Notte perpetua

Belli guaglioni, eccovi un bel racconto da leggere d'un fiato e da commentare. Se fa schifo.. ditemelo pure, sono qui apposta per ricevere commenti di qualunque genere. Sicuramente non è un racconto "nella media". Ditemi che ne pensate, a presto.
Notte perpetua

mercoledì, marzo 26, 2008

OOP in VimScript

Vim è uno dei (due) editor di testo più potenti che esistano, e come il suo concorrente (Emacs) può essere programmato in (almeno) un linguaggio di scripting apposito: il VimScript (in Emacs si usa l'elisp). Il VimScript è un linguaggio molto potente, articolato, con strutture dati flessibili (simili alle strututre dati di Python), tra le quali i dizioniari. I dizioniari, utilizzati in maniera particolare, consentono la costruzione di funzioni in cui sia possibile accedere al loro contentuo, una sorta di self pointer. Buttiamo lì un'identità di cui discuterò con voi volentieri:
strutture+function_handler+self=object orientation
Vediamo come questa cosa possa essere vera in VimScript: per prima cosa vi esorto a scaricare questo archivio con all'interno del codice VimScript, fra cui quello che ho scritto per l'OOP. In secundis aprite ed osservate il file "OO.vim" presente nella cartella "VimPresentation\Automation\Scripting". In esso:
  • BaseClass: salva in una variabile globale la classe corrente, costruita come dizionario con l'entry speciale "__name" contenente i nomi delle classi da cui l'oggetto eredita (per ora solo la corrente) e l'array (ora vuoto) delle interfacce implementate. Successivamente lo restituisce.
  • Interface: nefinisce una struttura simile a quella di una classe ma senza array delle interfacce.
  • Hinerit: l'ereditatrietà è gestita all'interno del costruttore chiamando questa funzione, qui viene creata l'istanza della superclasse, viene poi aggiunto ai nomi delle classi da cui si eredita il nome della sottoclasse, sarà poi compito del costruttore terminare la propria opera aggingendo nuovi attributi e svolgendo altri compiti di inizializzazione.
  • Virtual: i metodi virtuali non sono altro che metodi che vengono (nella sottoclasse, non nella superclasse come in C++) salvati all'interno della strututra d'istanza sotto nuovo nome tipo "superclasse_metodo" e che quindi vengono sostituiti nella sottoclasse.
  • PureVirtual: un metodo virtuale puro invece è un metodo che non è ancora stato implementato, se ne genera quindi una versione dummy ( che genera solo un'eccezione) e si utilizza la stessa tecnica dei metodi virtuali.
  • Implements: l'implementazione delle interfacce significa due cose:
    1. l'interfaccia (il suo nome) deve figurare tra le interfacce implementate,
    2. tutti i metodi virtuali puri presenti nell'interfaccia devono essere in quelche modo "importati" all'interno della classe corrente (starà poi al programmatore implementarli).
  • Isa: usando i nomi da dizionario si può sapere se una istanza è (da qualche parte nell'albero d'ereditarietà) istanza di una determinata classe.
  • IsImplemented: in modo analogo si può controllare se un istanza implementa una determinata interfaccia.
  • Import: un po' di comodità non guasta! ;)
Detto questo, sperando che abbiate contemporaneamente visionato il (semplicissimo) codice in VimScript che definisce queste funzioni, vediamo come utilizzarle per definire una classe, il classico contatore. Riporto e commento il file "Counter.vim":
let s:_default = 42
All'interno di uno script le variabili nello scope s: sono locali allo script stesso, per una classe questo significa avere a disposizione uno strumento per gli attributi statici.
function! Counter(...)
...
endfunction
Al solito definiamo una classe come funzione con funzioni innestate, la funzione di suo farà da costruttore. In fondo si può trovare il codice:
function! Counter_compare(a,b)
" Contronto actual:
return a:a._actual>a:b._actual
endfunction
che definisce una funzione friend. Il costruttore svolge le seguenti azioni:
if a:0<1
let initial = s:_default
else
let initial = a:1
end
let counter = BaseClass('Counter') | Implements ICounter
call extend(counter,{'_actual': initial})
che rappresentano:
  1. inizializzazione dell'attributo "initial" come variabile (per ora) locale,
  2. creazione dell'istanza con implementazione dell'interfaccia ICounter,
  3. agginta dell'attributo privato "initial".
Vedremo dopo come è stata definita l'interfaccia, ovviamente la sintassi deriva dal fatto che è stato creato un comando apposito per la definizione delle interfacce implementate, che richiama la funzione omonima.
A questo punto vengono aggiunti i metodi (eventualmente dichiarati virtuali se devono sovrascrivere i metodi di una superclasse o di un'interfaccia):
Virtual actual
function! counter.actual() dict
return self._actual
endfunction
E la classe è pronta! ;) Si osservi che i metodi vengono dichiarati con la speciale sintassi:
funciton! struttura.nome(...) dict
...
endfunction
dove la parola chiave "dict" assicura che all'interno del metodo si possa fare riferimento al dizionario "counter" con la parola chiave self. Si noti anche che il nome della funzione inizia con il nome dell'istanza che si sta costruento e che verrà restituita al termine del costruttore, infatti si sta semplicemente dichiarando un funciotn_handler di nome (in questo esempio) "actual" all'interno del dizionario "counter" richiedendo di generare il riferimento locale "self" con la parola chiave "dict".
Nel file "StepCounter.vim" si può osservare che l'ereditarietà è ottenuta semplicemente sostituendo la chiamata a "BaseClass" con la chiamata a "Hinerit" passando anche il nome della superclasse e la lista degli argomenti.
Con la definizione dei comandi si è resa semplicissima la dichiarazione delle interfacce:
fun! ICounter()
let counter = Interface('ICounter')
Abstract actual next prev set
return counter
endfun

Infatti:
  1. Si crea l'interfaccia in una fuzione "costruttore",
  2. si crea "l'istanza" con "Interface",
  3. si creano i metodi virtuali puri col comando "Abstract",
  4. si restituisce l'interfaccia.

OO in Matlab: Single inheritance

Belli guaglioni, ricordate questo post rtelativo alla programmazione OO in Matlab? Bè ogni tanto per sfizio mi diletto a giocherellare con la metaprogrammazione e ho da proporvi un paio di chicche, una (banale) in matlab e una più interessante in VimScript (prossimo post).
Iniziamo pensare alla tecnica proposta per programmare OO in Matlab, abbiamo compreso come ottenere molte features, non abbiamo ottenuto però l'ereditarietà. Per aggiungere l'ereditarietà vogliamo tenere d'occhio i seguenti aspetti:
  • Overriding: vogliamo poter "sovrascrivere" i metodi della superclasse con le nostre nuove versioni senza perdere però la possibilità di accedere esplicitamente alle versioni della superclasse.
  • Accessors: non abbiamo descritto in maniera molto dettagliata come poter realizzare dei metodi accessori al meglio della comodità d'utilizzo, l'idea è quella di ottenere una sorta di property come in C#, per intenderci.
  • Protected access: nell'antico post sulla OOP in Matlab abbiamo descritto in maniera precisa come ottenere accesso pubblico e privato ai metodi, come costruire funzioni private accessorie non legate agli oggetti, come memorizzare gli attributi come privati ma non come pubblici (cosa che non faremo, usando invece i metodi accessori). Resta però da efinire come ottenere un livello protetto di accesso ai metodi o attributi. Si cominci a considerare il fatto che se si ottiene l'accesso protetto ai metodi si può sfruttare quello per avere accesso protetto verso gli attributi semplicemente con degli accessori protetti. Per ora però purtroppo non siamo in grado di creare metodi ad accesso protetto, quindi ci limitiamo ad utilizzare la tecnica delle property.
Dopo tutta sta pizza passiamo al codice: vogliamo creare la classe stepCouter sottoclasse di counter, in essa dovremo sfruttare il valore attuale del contatore per poterlo leggere, modificare e reimpostare; per questo motivo creiamo il seguente metodo accessorio nel contatore:
% The actual value accessor:
function ao = Actual(ai)
% Getting the actual value:
if nargin>0; start=ai; end

% Setting the output:
if nargout>0; ao=start; end
end
Collegheremo questo metodo all'oggetto salvando il function_handler con il nome "actual" all'interno dell'istanza restituita:
% Returning the counter: this is the public methods' set exported.
c = struct('next',@Next,'prev',@Prev, ...
'reset',@Reset,'actual',@Actual);
Fatto questo abbiamo la possibilità, nella sottoclasse, di istanziare il contatore e aggiungervi dei metodi che, sfruttando la property 'actual', possano modificare anche l'istanza della superclasse.
Si noti che la superclasse e la sottoclasse avranno collegati a sé due workspace differenti con all'interno i loro rispettivi attributi privati; questo significa che con questa tecnica comunque ogni classe genera istanza che hanno il proprio workspace separato da tutti gli altri, senza possibilità di interferenze. Ecco il codice:

function c = stepCounter(start,step)
% STEPCOUNTER Generates a new counter that uses a step.
%
% Here the single hineritance is obtained by generating an object of the
% superclass and then joining the method calls, notice that the mantained
% workspaces are distinguished so there are difficulties in the private
% attributes access (there is no protected access, only public or private);
% so an accessor in the class "counter" must be added (in this case
% "actual"), this allows to have the actual attribute to be public.

% =========================================================================
% Creating the object:
% =========================================================================

% Using the superclass' constructor:
c = counter(start);
clear start;

% Adding local methods:
c.step = @Step;
% Saving the old method so that can be explicitly called if required:
c.counter.next = c.next;
c.next = @Next;
% Same for the prev:
c.counter.prev = c.prev;
c.prev = @Prev;

% =========================================================================
% The public methods body.
% =========================================================================
% The next integer function:
function n = Next
% Increment:
n = c.actual(c.actual() + step);
end
% The prev integer function:
function n = Prev
% Decrement:
n = c.actual(c.actual() - step);
end
% Setting and getting the step value:
function so = Step(si)
% Getting the actual value:
if nargin>0; step=si; end

% Setting the output:
if nargout>0; so=step; end
end
% =========================================================================
% Private methods are simple functions and can be defined here.
% =========================================================================
end

% =========================================================================
% Support functions that are not methods (no access to attributes) are
% defined here.
% =========================================================================
Quindi in questa sottoclasse "step" è un attributo locale privato, ed è l'unico presente nel workspace della sottoclase "stepCounter", il parametro "start" del costruttore viene rimosso una volta utilizzato perché dopo la chiamata al costruttore della superclasse non serve più (è stato memorizzato nel workspace della superclasse) e se non eliminato rimarrebbe nel workspace privato della sottoclasse "stepCounter" occupando spazio inutile e potenzialmente dando la possibilità di scrivere codice errato e confuso. Per "step" si è creata una property, i metodi "next" e "prev" sono stati sostituiti e le vecchie versioni sono state salvate nella struttura stessa in una sottostruttura con il nome della superclasse. Ora è possibile scrivere codice come il seguente:
c1 = counter(10);
c2 = stepCounter(10,10);
c1.next()
c2.next() % Uso la versione "overridata":
s=c2.step %ottengo lo step:
c2.step(20); % Imposto lo step:
c2.counter.next(); % Uso la versione originale:

mercoledì, febbraio 13, 2008

Commenti in C++

I linguaggi C/C++/Java/ecc (anche se non nello standard C99) prevedono l'utilizzo di due diversi tipi commenti:

// Commento su una riga (one-line comment)
/*
Commento di un intervallo di testo (range comment)
*/

Inoltre non prevedono comment nesting (annidamento dei commenti), quindi suddividono l'input in token "//", "/*" e "*/" dipendentemente dal contesto (di commento). Questo unito all'utilizzo del carattere "/" condiviso tra i due tipi di commento permette di "giocare" per ottenere risultati interessanti e utili.. quando si dice giocare con poco per ottenere molto! ;)

Date un occhio a questi esempi e se vi va lasciatemi un commento (al blog, non in C++ ;)

martedì, gennaio 29, 2008

Buio illuminante

Buio illuminante


Luce diffusa, radente, coglie
ogne anfratto dell’anima pia,
occultando le ombre minacciose.
In agguato pazientano tenebre,
liberatrici di spettri antichi,
nulla può impedirne il ritorno.

Miope dell’antica identità,
non comprendo il profondo dolore;
erroneamente intendo segni
mostratimi con gesti inattesi.
Nel buio profondo ora brancolo
fiutando intesa per dar appoggio.

Giornate luminose rendon ciechi,
sovente di più svela oscurità,
chiarore perpetuo, s’apprezza poco.
Nell’ombra, un sol raggio di speranza
pare illuminar l’intera vita,
vien ben percepito con ogne senso.

Dovrebbe serenità
pervadere le menti
d’accecati dispersi:
vedranno più di prima.

Non capendo,
percepisco.


Gabriele Lombardi