-+  Associazione
-+  Documenti
-+  Eventi
-+  Community
-+  Blog
-+  Link

Ottobre 2013

Dom Lun Mar Mer Gio Ven Sab
    1 2 3 4 5
6 7 8 9 10 11 12
13 14 15 16 17 18 19
20 21 22 23 24 25 26
27 28 29 30 31    

Cerca






 


« Marzo 2004 | Home | Maggio 2004 »

Omelia XII

Carissimi,

ho finito la lettura dell'Apocalisse 12 e, sobillato anche da larsen, ho deciso di tramutare ciò che inizialmente avevo pensato come un semplice "impressioni a caldo" in qualcosa di più corposo e articolato. Qualcosa che vuol essere una specie di riassunto di ciò che ho capito o mi ha colpito, e un modo anche per esercitarmi nella scrittura di pseudo-code in Perl6 :-)

Prevedo quindi di integrare questo post iniziale con ulteriori commenti, man mano che vado avanti nella digestione del corposissimo corpus Walliano.

Premessa

Come già Larry con "apocalisse", non intendo utilizzare la parola "omelia" nella sua accezione comune, di matrice ecclesiastica, di "sermone, spiegazione delle Sacre Scritture ai fedeli" (lungi da me l'idea di salire su un qualsivoglia pulpito!), ma nell'accezione più vicina all'etimo greco "homilìa", che sta per conversazione.

Mi piacerebbe che la conversazione non rimanesse monologo, quindi vi invito a partecipare correggendomi dove sbaglio, o aggiungendo dove tralascio, o riportando le vostre impressioni. Avete a disposizione la possibilità di commentare, quindi abusatene pure.

Gli oggetti nel quotidiano

Per quanto riguarda l'utilizzo "comune" di classi ed oggetti (i casi più semplici che rappresentano poi una buona percentuale dei casi totali, il quotidiano appunto), molto è stato fatto per rendere il più esplicito possibile ciò che dev'essere esplicito e il più implicito possibile ciò che dev'essere implicito.

La differenza principale sta nel fatto che un oggetto non è più esplicitamente, nel codice, una reference (quasi sempre, una reference ad un hash) sottoposta a bless, ma un qualcosa di "opaco" allo sguardo occasionale.

Per spiegarci meglio, vediamo come può essere implementata una semplice classe in Perl6:

    class Persona {
        has $.nome;
        has $.cognome;
        has $.soprannome = $.nome;

        method saluta {
            say $.soprannome ~ ": ciao";
        }
    }

    my $dada = Persona.new( nome => "Aldo", cognome => "Calpini");
    $dada.soprannome = "dada";
    $dada.saluta();
    my $nominativo = $dada.nome ~ " " ~ $dada.cognome;

Qui vediamo all'opera le sostanziali differenze:

  • attributi espliciti (non più chiavi di hash ma variabili introdotte da "has")
  • metodi espliciti (non più "sub" ma "method")
  • costruttore implicito ("new" non dev'essere definito)
  • metodi accessori (lettura/scrittura degli attributi) impliciti

Ovviamente, è sempre possibile implementare il tutto in maniera diversa (anche implementarlo con un hash, come ai bei vecchi tempi del Perl5). E' possibile scrivere un metodo "new", o "overloadare" le funzioni per accedere agli attributi che Perl6 crea per noi.

Ciò che mi piace particolarmente, di tutta questa implementazione, è l'innata ortogonalità delle operazioni: il fatto di fornire un "new" di default, ad esempio, non deriva da qualche magia nera, ma semplicemente dal fatto che ogni classe eredita, volente o nolente, dalla classe Object, la quale implementa appunto il metodo new in questione.

Privacy

Si possono (finalmente, sospirerà qualcuno) creare attributi, e perfino metodi, davvero "privati", nel senso che sono interni alla classe e nessuno, neanche con i salti mortali (immagino), può utilizzarli dall'esterno.

L'identificatore che segnala la nostra richiesta di riservatezza sono i due punti:

    class Personalita {
        has @.:inconscio;

        method :rimozione( $self: $indesiderato ) {
            push(@self.:inconscio, $indesiderato);
        }
    }

Nessuno potrà vedere ciò che c'è nel nostro inconscio, né tantomeno interferire con i nostri meccanismi di rimozione :-)

Ereditarietà

Non molto da dire, se non che non si usa più @ISA, ma si danno esplicitamente dei "tratti" alla classe:

    class Utente is Persona {
        has $.login = $.nome;
        has $.password;
        has $.home = "/home/$.login";
    }

    class Luser is Utente is Incompetente is Seccatura; # :-)

Classi e Ruoli

Una novità (a mio avviso meravigliosa) che porterà il Perl6 per sfruttare al meglio le potenzialità della programmazione OO è quella dei ruoli. I ruoli non sono "propriamente" classi, o meglio sono classi, ma dalle quali non è possibile costruire direttamente oggetti.

Quello che permettono di fare i ruoli, fondamentalmente, è di costruire classi complesse, o gerarchie di classi, non solo tramite il meccanismo dell'ereditarietà ma tramite quello della "composizione".

    role Programmatore is {
        has @.linguaggi_conosciuti = <<nessuno>>;
        method scrivi_codice($linguaggio, $righe) {
            die unless @.linguaggi_conosciuti ~~ $linguaggio;
            sleep($righe*10);
        }
    }

    class Dipendente is Utente {
        has $.matricola;
        does Programmatore;
    }

Non solo: è possibile associare dei ruoli ad oggetti già creati! Questo permette di creare dei "mixin", una sorta di oggetti ibridi, creati secondo una classe, ma che assumono in seguito (in qualunque momento decidiamo noi) tratti di un'altra classe:

    my $dada = Persona.new();
    $dada does Programmatore;
    push($dada.linguaggi_conosciuti, 'Perl');

Ovviamente, l'implementazione dell'operatore di match, quando applicato ad oggetti, utilizza quindi il metodo .does (invece di .isa) che ritorna un valore vero sia per la classe propria dell'oggetto, che per classi ereditate, che per ruoli in qualunque modo "assegnati" ad esso:

    if($dada ~~ Programmatore) {
        $dada.scrivi_codice(linguaggio => 'Perl', righe => 1000);
    }

Delegare, delegare, delegare

Un ulteriore meccanismo a disposizione del disegnatore di classi è quello della "delegation", ossia il demandare ad altre classi la gestione di alcuni metodi. L'implementazione prevede sempre e comunque un attributo che contenga il riferimento ad un oggetto della classe alla quale si intende delegare.

    class Dipendente is Persona {
        has Qualifica $.ruolo handles 'lavora';
    }

in questa maniera

    $dada.lavora(); # è in realtà $dada.ruolo.lavora();

La cosa particolarmente carina è che si possono usare anche espressioni regolari per decidere quali metodi delegare:

    class Persona {
        has Schiavo $.schiavo handles (/[lava | pulisci | stira]/);
    }

E abbiamo così delegato al nostro "Schiavo" tutti i lavori di casa :-)

Altro

L'Apocalisse contiene molto, molto di più, incluse modifiche al linguaggio decise da Larry e team nel tempo trascorso dalla pubblicazione dell'ultimo documento e che poco o nulla hanno a che fare con l'OOP. Degli argomenti principali, quelli che mi risultano meno chiari sono:

  • submetodi
  • "alias" privati di classi
  • in generale, tutto il meccanismo di dispatch :-)
  • AUTOLOAD e i suoi nuovi amici AUTOMETH, AUTOMETHDEF, etc.
  • definizione dei tipi

Mi riprometto di studiarmeli meglio per la prossima volta :-)

cheers,
Aldo

Inviato da dada alle 19:08 | Commenti (8)

habemus perlfunc

grazie ai soliti noti (un nome su tutti, quello di dree a cui vanno i nostri e vostri ringraziamenti) abbiamo aggiunto nel menu 'Documenti' che trovate alla vostra sinistra la voce 'perlfunc'.

Avete a disposizione la documentazione completa delle funzioni Perl in italiano, con tanto di possibilità di ricerca. Quindi, sempre meno scuse per non mettersi d'impegno ad imparare il linguaggio che noi tutti amiamo :-)

Inviato da dada alle 16:45 | Commenti (0)

OpenGroupware e Perl: perché no?

OpenGroupware.org (OGo) è, secondo me, uno dei software Open Source più interessanti che siano comparsi sulla scena negli ultimi anni. Nato dall'apertura dei sorgenti di Skyrix Groupware è un prodotto molto completo e che sta andando verso la maturità. L'unico difetto sostanziale, al momento, è nella documentazione, che è incompleta, frammentata e sparsa. La documentazione più autorevole è quella che venne rilasciata da Skyrix, ma comincia a essere obsoleta...

Fra le cose belle di OGo c'è una API XML-RPC: si può interagire col sistema usando uno qualunque fra i linguaggi che vanno attualmente per la maggiore.

In Python sono già state realizzate diverse applicazioni, in Java c'è addirittura un framework che si chiama JOGI.

Perl è, tristemente, fra i fanalini di coda e può "vantare" solo una CGI scritta nel 2001(!!!)

XML-RPC è un argomento che mi interessa molto. Tempo fa mi è stato regalato Programming Web Services with Perl che avevo cominciato a leggere e che riprenderò in mano prossimamente. Mi piacerebbe costruire un framework in Perl per operare su OpenGroupware, ma chiaramente, dato che devo ancora iniziare a farmi le ossa su XML-RPC, non posso farlo da solo.

L'idea solletica qualcun'altro? Facciamo squadra?

Ciao
--bronto

Inviato da bronto alle 12:14 | Commenti (3)

Apocalypse XII

E` uscita da qualche giorno, ma stranamente nessuno ne ha dato notizia qui, quindi provvedo io. E` uscita la dodicesima apocalisse di Larry Wall, quella forse piu` importante perche` tratta della nuova implementazione del paradigma di programmazione ad oggetti. Buona lettura :)

http://www.perl.com/pub/a/2004/04/16/a12.html

Inviato da larsen alle 18:42 | Commenti (0)

Cronache dalla MySQL Users Conference

Sono appena rientrato dalla MySQL Users Conference, che si è tenuta a Orlando (Florida) dal 14 al 16 aprile 2004.
Molto interessante, sia per i contenuti tecnici sia per il contorno culturale e comunitario. La conferenza si teneva a due livelli: quella che fisicamente si svolgeva davanti a noi, e quella che parallelamente si evolveva sui vari blog, aggiornati real-time grazie a un impianto wireless diffuso in tutta l'area dell'evento. Molto seguiti i commenti paralleli di Jeremy Zawodny, noto guru di Perl e MySQL, anima tecnica di Yahoo!, che ha diffuso sul tamburo le sue vedute sui vari talk, sottolineando gli aspetti geniali e le stupidate.
Oltre a curiosare in giro, ero anche uno degli speakers, e ho presentato un talk dal titolo "DBI Idioms", che doveva essere tenuto in un laboratorio sponsorizzato da Apple, pieno di macchine della mela. L'avventura è cominciata al mattino del 14, quando ho controllato che i computer su cui dovevo lavorare avessero il software da me richiesto (Perl DBI e DBD::mysql). Sfortunatamente, qualcuno si era dimenticato di installarli. Contattato il guru della Apple, si è dovuto constatare che le istruzioni per l'installazione di detti moduli non portavano al risultato voluto, perché mancavano i file di include necessari alla compilazione di XS.
Poiché l'unico metodo che conosco in questi casi è di reinstallare Perl e MySQL da sorgente (per essere sicuro che i binari risultanti dai moduli siano poi compatibili), ci si è dovuti arrendere all'evidenza che non si faceva in tempo a finire in tempo.
La faccenda era aggravata dal fatto che non era un'aula con proiettore, ma un'aula da corsi, in cui il server Apple poteva trasmettere a tutti i client l'immagine del proprio schermo. Quindi, sostituire il server non era un problema da poco.
Quindi, ho adottato una soluzione di emergenza, facendo la presentazione sul mio portatile, la cui immagine è stata trasportata in VNC sul server Apple, e da qui trasmessa ai client usanto il sistema "originale".
Arrivati all'orario della presentazione, altra sorpresa: il server Apple non vuole trasmettere l'immagine ai client. Mugugni e confabulazione dei guru Apple, finché uno di loro si dà una pacca sulla fronte, digita qualcosa di misterioso in una finestrella, e finalmente si può partire, ma in ritardo di 10 minuti (su un totale di 30).
Faccio del mio meglio per stringere il talk nel tempo rimastomi, e riesco ad arrivare alla fine, avendo almeno toccato tutti gli argomenti in scaletta. Molti dei 30 appassionati che mi hanno seguito, però, protestano per la defaillance tecnica che li ha privati di buona parte della presentazione.
Il giorno dopo uno degli organizzatori, nel porgere le scuse per l'inadeguatezza di Apple, mi propone di ripetere il talk, cosa che accetto. Nel frattempo ero stato abbordato da un perlista che mi sottopone un problema legato a uno degli argomenti della mia presentazione. Si tratta di un DB da 3,5 milioni di record che lui si lavora con un loop gigante, che dà dei risultati scadenti. Rapido esame del sorgente nell'intervallo fra due talk, messa a nudo del problema (a la perlmonks) e soluzione al volo in mezzo a un capannello di curiosi.
All'intervallo successivo il problema è risolto, e c'è un Monk in più. :)
Il terzo giorno c'è la ripetizione del mio talk. Solo una dozzina di spettatori, ma di quelli tosti, che fanno domande competenti e apprezzano le finezze che mi ero preparato.
Tutto sommato, una buona esperienza, nonostante la mia determinazione di comprare un portatile Apple sia stata un po' scossa ...

Alla prossima!

Inviato da gmax alle 14:34 | Commenti (1)

Nuovo feed

Il buon dada ha predisposto, per il nostro/vostro diletto, un nuovo feed del blog di Perl.it: scaricando whatsnew.rdf, oltre alle nuove entry, si avrà un elenco dei nuovi commenti. Hip hip urrà :)

Inviato da larsen alle 15:03 | Commenti (2)

NO ai brevetti software in Europa

10 giorni di sciopero web contro 20 anni di incubi da brevetto

Stiamo protestando contro i brevetti software in Europa.

La maggior parte dei software, diventerà illegale per l'uso in Europa se questa pericolosa direttiva sarà adottata senza i necessari emendamenti.

La Commissione Europea e il Consiglio dei Ministri stanno segretamente spingendo per una brevettabilità del software senza limiti, fortemente incitati dalle multinazionali e da avvocati specializzati in brevetti. Essi stanno ignorando la decisione di voto democratico del Parlamento Europeo del 24 settembre 2003, che ha il supporto di oltre 300.000 cittadini, 2.000.000 PMI, dozzine di economisti e scienziati.

Unitevi a noi in una dimostrazione nelle strade di Bruxelles, il 14 aprile 2004.

Unitevi a questa protesta cambiando la vostra homepage dal 5 fino al 15 aprile.

Inviato da larsen alle 14:05 | Commenti (1)

Bot positronici

Avete presenta la pagina Contatti, quella dove ad un certo punto si dice che "Per discutere in tempo reale su Perl e dintorni" si può andare sul canale IRC #nordest.pm? Ebbene, non fatelo mai: è un luogo terribile, un'oscura caverna che si impadronirà di voi facendo a brandelli la vostra produttività. Ora che vi ho detto cosa non fare, devo pure dire cosa e chi vi perdete. Uno su tutti, boha, e la sua arguzia. E' un bot e, malgrado la sua natura, vede tutto, capisce tutto e soprattutto non perdona niente.

14:32 <@larsen> ho trovato un metodo truffaldino :)
14:32 <@dada> larsen: dica
14:32 <@larsen> my %h = ( metodo => 'bar' );
14:32 <@larsen> $obj->${  \($h{ 'metodo' } ) };
14:33 <@dada> azz
14:33 <@larsen> ma cosi' son capaci tutti :)
14:33 <@dada> my cojons
14:33 <@larsen> boha: tu non hai visto niente, ok?
14:33 <+boha> larsen: il delitto perfetto non esiste

Scherzi a parte, boha è un divertente progetto di factoid bot fatto con POE::Component::IRC, che ha imparato tutto quello che sa in molto meno di 200 anni. Non vedevo l'ora di parlarne, e l'occasione mi pareva gustosa. Non è escluso che i sorgenti in futuro finiscano in qualche angolo del sito

Inviato da larsen alle 18:40 | Commenti (5)

MT Support Forum

Niente di particolare. Volevo solo cogliere lo spunto di questa notizia per segnalare l'ottima esperienza avuta sul forum di supporto di Movable Type, mentre stavo trafficando con il medesimo. Se state avendo l'impressione che io stia diventando fanatico di questo software, è perchè è vero :)

Inviato da larsen alle 22:11 | Commenti (2)

PerlHike 2004

PerlHike è l'unione di Perl e montagna. Non è il solito meeting o workshop in un'aula di un'università o nella sala conferenze di un hotel, dove in effetti gli interventi e le persone che si conoscono sono l'unico motivo di interesse dell'evento. Nel PerlHike ciò che assume la rilevanza maggiore è il setting, cioè il luogo in cui si trova. Questo è in controtendenza rispetto a quasi tutti gli eventi mondiali di programmazione, se si eccettuano le Geek Cruises.

PerlHike è:

hiking - La gita, della durata di due giorni, prevede un'escursione su alcune tra le più belle vette del Nordest Italia, spezzata in due parti. Il primo giorno si raggiungerà, dopo un'escursione, un rifugio, una malga, oppure un bivacco in cui trascorrere la notte. Il secondo giorno vi sarà un'altra escursione nella zona ed il rientro.

technical meeting - La sera, nel luogo dove si pernotta, ciascun partecipante a PerlHike è caldamente invitato a tenere almeno un talk (di natura più o meno tecnica). La probabile mancanza di copertura di telefonia mobile renderà quasi certamente impossibile l'accesso ad Internet, ed il peso (nonché la durata della batteria) dovrebbe scoraggiare tutti a portarsi appresso il notebook. Questo creerà una simpatica situazione di ritorno a talk vecchio stile, insomma attorno ad un tavolo con carta e penna.

social meeting - Per chi ha fiato a sufficienza, già i momenti di cammino rappresentano ottime occasioni per conoscersi. Per coloro che non sono superman, invece, le soste e soprattutto la sera saranno il momento giusto per due chiacchiere. In tutti i casi è prevista un'abbondanza di cibo e di beveraggi, tra cui alcune interessanti grappe tipiche.

Insomma... Perl, salute, bei posti, momenti sociali. Tutto ciò dovrebbe convincerti a partecipare. ;-)

La data non è ancora stata decisa, per ora stiamo raccogliendo le adesioni. Se sei in qualche modo interessato a partecipare, o ai qualche domanda, scrivi a arthas@nordest.pm.org oppure lascia un commento a questa storia.

Inviato da arthas alle 14:35 | Commenti (3)

ciscoscan

Salve a tutti. Sperando di ricevere indicazioni, commenti e critiche, vi riporto di seguito l'url con il mio primo script perl. Si tratta di un semplice scanner che va alla ricerca di porte 23 aperte dove testare le default password di alcuni apparati di rete; nel caso specifico router Cisco. E possibile specificare un po' di cosette come un file degli ip da scansionare, password list ecc.. Non e' utilissimo, non e' niente di speciale, ma e' giusto per studiare un po'...

http://goony.openbeer.it/misc/perl/ciscoscan.txt

Grazie a tutti in anticipo per i vostri commenti, e ringrazio il canale irc #nordest.pm per il supporto tecnico e morale! :))

Inviato da goony alle 18:08 | Commenti (1)

Test di applicazioni web

E' cosa risaputa che "a causa" di CPAN programmare in Perl diventa rapidamente poco interessante: uno ha un'idea, gli pare buona, non vede l'ora di trafficare un po' per avere un oggettino da mostrare e provare, poi in un modo o nell'altro scopre che quell'idea la ha già avuto qualcun altro, e che questo qualcuno l'ha messa su CPAN.
La storia che segue è quindi isomorfa a tante altre, ma per un po' di motivi, mi pare particolarmente interessante.

Uno dei miei chiodi fissi, ultimamente, è il test delle applicazioni: sono assolutamente convinto che i test siano uno strumento utile e che tendano a far guadagnare tempo durante lo sviluppo, purtroppo però non sono abbastanza bravo da scriverli e mantenerli in maniera sufficientemente veloce. Inoltre, finché si tratta di scrivere i test per i moduli di backend di un'applicazione, non c'è problema, ma non mi è molto chiaro come testarne l'interfaccia utente.

Questa sera, dunque, mi è venuto in mente di provare a vedere WWW::Mechanize, che pare promettere bene. In effetti l'interfaccia del modulo è piuttosto intuitiva, e pare semplice mettere a punto degli script che girino per l'applicazione e verifichino i risultati ottenuti. Semplice, ma lungo e tedioso.

Enters WWW::Mechanize::Shell.

Questo modulo implementa una sorta di shell che mima un browser web. Ecco un esempio di interazione:

# Search for a term on Google
get http://www.google.com
value q "Corions Homepage"
click btnG

La cosa bella è il comando script di WWW::Mechanize::Shell, che trasforma la sessione appena intercorsa in uno script Perl basato su WWW::Mechanize. Comincia a frullarvi qualche rotella? Proseguo.

Per preparare i test per la propria applicazione, basta passare un po' di tempo davanti a WWW::M::S e salvare, volta per volta, le sessioni che andranno a costituire l'insieme di test dell'applicazione (ad esempio: login con password sbagliata, login con password corretta, inserimento dati, inserimento dati incompleti...). E tutto questo lavoro si dovrà fare una volta sola.

Bello, ma scomodo. Usare una shell al posto di browser e mouse, almeno per quanto riguarda le applicazioni web, è scomodo. E qui salta fuori la mia idea (e come vi ho già anticipato, su CPAN c'è già).

Perchè non fare in modo che sia l'applicazione stessa, mentre viene usata, a produrre lo script per WWW::Mechanize? La cosa avrebbe il considerevole vantaggio di permettere ai tester (che in un mondo ideale non coincidono con gli sviluppatori) di includere nel ticket di segnalazione di un errore i passi esatti per riprodurlo (modulo lo stato particolare di altri pezzi del sistema, ovviamente). In altri termini, si scriverebbe una parte importante del codice di test direttamente usando l'applicazione.

Stavo pensando a come implementare questa cosa, quando mi sono imbattuto in HTTP::Recorder, di Linda Julien. E' implementato in una maniera diversa da quella che cominciava a farsi strada nella mia mente, però pare molto efficace, e facile da usare. Enjoy.

La gloria, per me, arriverà un'altra volta :)

Inviato da larsen alle 00:07 | Commenti (6)

D:
Progetti e documenti in rilievo
Corso di Perl Progetto pod2it
D:
La ML di Perl.it
mongers@perl.it è la lista ufficiale di Perl Mongers Italia per porre quesiti di tipo tecnico, per rimanere aggiornato su meeting, incontri, manifestazioni e novità su Perl.it.
Iscriviti!
D:
Annunci Google