Disegno? Una questione di allenamento!

Saper disegnare sicuramente richiede capacità e talento.. io non penso di averli, però ho scoperto l'acqua calda: le capacità si costruiscono con l'allenamento, il talento può essere innato.. ma può anche essere costruito con l'esperienza.
Non ci credete? Bé non sono mai stato bravo a disegnare, nonostante io scolpissi e dipingessi con l'areografo (e qualche volta sulle magliette)...

E ADESSO???

Non so disegnare nemmeno ora, però comincio a stendere la grafite sulla carta in maniera quasi accettabile per un principiante. Un esempio? Eccolo:

E se dovessi programmare in C ANSI.. ma OO?

Oramai é sempre più raro trovarsi in questa situazione esistendo svariate soluzioni sia open che commerciali per lo sviluppo e la compilazione di codice C++ anche per architetture embedded. Ogni tanto però capita ancora di avere questa esigenza.. in quei casi?

La risposta viene da molto lontano nel tempo, molti di voi avranno sentito parlare del documento OOC, in cui si descrivono le tecniche per programmare in uno stile OO utilizzando l'ANSI C. Questo documento esiste da molti anni.. e quando lo scoprii (nel 2002 se non ricordo male) mi entusiasmò! In questi giorni però la stessa domanda mi é stata riproposta da un curioso molto in gamba.. e perché non fornirla a tutti sul blog? Ma di più.. dato che non ho mai nulla da fare (ironico ovviamente), perché non scrivere un esempio semplice semplice di tool costruito con le macro di preprocessore? E' un giocattolino senza esplicito supporto per l'ereditarietà, il polimorfismo e quant'altro.. però é simpatico e chi vuole può usarlo/estenderlo per gioco. Eccovelo in sole 50 righe di macro con un esempio semplice semplice.

Vediamo un esempio di dichiarazione di classe:

// La classe:
CLASS_BEGIN(CheckedInt)
ATTRIBUTE(CheckedInt,int,version);
METHOD(CheckedInt,void,setValue,unsigned long val);
METHOD(CheckedInt,unsigned long,getValue);
STATIC_METHOD(CheckedInt,unsigned long,max_val);
CLASS_END(CheckedInt)

// La struttura rappresentante un'istanza:
CLASS_INSTANCE_BEGIN(CheckedInt)
ATTRIBUTE(CheckedInt,unsigned long,value);
ATTRIBUTE(CheckedInt,unsigned long,not_value);
CLASS_INSTANCE_END(CheckedInt)

// Definizione di costruttore e distruttore:
CLASS_ALLOCATORS(CheckedInt,unsigned long val);

Lineare no? E l'implementazione? Eccola:

// Metodo d'istanza:
METHOD_IMPL_BEGIN(CheckedInt,void,setValue,unsigned long val)
this->value = val;
this->not_value = ~val;
METHOD_IMPL_END(CheckedInt)

// Caso statico:
STATIC_METHOD_IMPL_BEGIN(CheckedInt,unsigned long,max_val)
return 0xFFFFFFFE;
STATIC_METHOD_IMPL_END(CheckedInt)

//...

// Inizializzazione della struttura statica:
CLASS_INIT( CheckedInt,1,
CheckedInt_setValue,
CheckedInt_getValue,
CheckedInt_max_val);

// Costruttore:
CONSTRUCTOR_BEGIN(CheckedInt,unsigned long val)
this->value = val;
this->not_value = ~val;
CONSTRUCTOR_END(CheckedInt)

// Distruttore:
DESTRUCTOR_BEGIN(CheckedInt)
// Rilascio risorse.
DESTRUCTOR_END(CheckedInt)

Usiamo la nostra classe ora!

// Istanzio:
CheckedInt *ckdInt = CheckedInt_new(10);

// Chiamo un po:
printf("A checked value: %d\n", CALL(ckdInt,getValue));
CALL(ckdInt,setValue,42);
printf("A checked value: %d\n", CALL(ckdInt,getValue));

// Accedo agli attributi direttamente:
printf("I'm a bad boy! ;)\n");
ckdInt->not_value = 0;
printf("A checked value: %d\n", CALL(ckdInt,getValue));

// Uso il distruttore:
CheckedInt_free(ckdInt);

Ok, probabilmente molti di voi diranno "Tra C++, Java, C#, cicici e tututu sicuramente questo non mi serve!", sono perfettamente d'accordo con voi... ma ogni sfizio è sfizio!!! ;)

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?

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!!! ;)

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! ;)

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.

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ù!!! ;)