martedì 30 giugno 2009

Setter, Getter o entrambi?

I Java Beans hanno introdotto diverse convenzioni, fra le quali quelle circa l'utilizzo dei metodi getter e setter: i primi sono metodi che ritornano il valore di un attributo d'istanza, i secondi sono mutator che impostano il valore di tale attributo. La convenzione vuole che il getter abbia un nome che inizia con get, seguito dal nome della proprietà (variabile di istanza) con la prima lettera maiuscola e non abbia alcun parametro, ma ritorni un tipo pari a quello della proprietà. Il setter segue regole simili, e ha il suo nome composto da set e il nome della proprietà (prima lettera maiuscola) e riceva esattamente un argomento del tipo della proprietà senza ritornare al chiamante nulla.
Da quanto sopra si ha che per ogni proprietà servono almeno due metodi distinti, un getter e un setter, abbastanza semplici e rapidi da scrivere (addirittura gli IDE moderni consentono di creare tali metodi con un click). E' però possibile prendere in prestito da Perl il comportamento dei metodi e scrivere un metodo unico che svolga entrambe le funzioni.
Si consideri la seguente semplice classe:

public class Person {

private String name = null;
private String surname = null;
...
}



e si supponga di voler scrivere un unico metodo name che possa funzionare sia da getter che da setter a seconda del contesto in cui viene chiamato. In altre parole il seguente main deve funzionare:

public static void main(String[] args) {
Person p = new Person();
p.name( "Luca" );
System.out.println("Persona " + p.name() );

}

Come si può notare il metodo name viene chiamato in due contesti diversi: se gli viene passato un parametro si deve comportare come setter, altrimenti come getter.
Come si puo' ottenere un simile comportamento? Usando gli argomenti opzionali introdotti da Java 5 è abbastanza semplice:

 public String name(String...newName){
// controllo se e' stato passato
// un parametro o meno
if( newName != null && newName.length == 1 )
// passato un parametro => metodo setter
this.name = newName[0];

// in ogni caso ritorno il valore
// corrente come metodo getter
return this.name;
}

Come si può notare il metodo si comporta come getter sempre, ovvero restituisce sempre il valore della proprietà name. Il metodo poi indovina il contesto di chiamata analizzando gli eventuali parametri: se ne sono stati passati al massimo uno allora il metodo si deve comportare come setter. E' possibile rilassare il test sul numero di parametri considerando valida una lista di parametri qualsivoglia lunga, e usando solo il primo come setter, ma questa scelta dipende dall'interfaccia che si vuole dare al metodo.
Il fatto che il metodo restituisca sempre, anche se chiamato in un contesto di setter, il valore della proprietà non è una limitazione, anzi consente di effettuare un method-chain invocando piu' metodi in cascata.

mercoledì 24 giugno 2009

Creare un modulo per il kernel di Linux

Questo breve articolo mostra come creare e caricare un semplice modulo per il kernel di Linux, in modo da dare accesso alle funzionalità del kernel.
Un modulo deve essere scritto in linguaggio C, compilato in un modo un po' particolare (ma tutto sommato semplice) e installato e rimosso mediante i comandi insmod, depmod e similari.

Vediamo subito il codice di un modulo che viene caricato in memoria e appena attivato stampa la classica frase Hello World:

/* Declare what kind of code we want from the header files */
#define __KERNEL__ /* We're part of the kernel */
#define MODULE /* Not a permanent part, though. */

#include

/* Initialize the LKM */
int init_module()
{
printk("Modulo in fase di inizializzazione...\n");


printk("\nHELLO WORLD!\n");

/* If we return a non zero value, it means that
* init_module failed and the LKM can't be loaded
*/
return 0;
}

/* Cleanup − undo whatever init_module did */
void cleanup_module(){
printk("Modulo in fase di uscita\n");
printk("\nBYE BYE WORLD");
}

La parte relativa agli header, come pure i prototipi delle funzioni, sono standard. In particolare init_module viene richiamata al momento dell'installazione del modulo, mentre cleanup_module al momento della sua rimozione.
La compilazione del modulo avviene tramite il seguente Makefile:

obj-m := HelloWorld.o

KDIR := /lib/modules/$(shell uname -r)/build
PWD := $(shell pwd)

default:
$(MAKE) -C $(KDIR) SUBDIRS=$(PWD) modules

Una volta compilato il modulo, sarà disponibile un file .ko (Kernel Object) che può essere caricato nel sistema. Siccome stiamo parlando di un semplice modulo di prova, anziché installare il modulo direttamente nella directory modules possiamo installare e rimuoverlo manualmente.
Per installarlo basta usare il comando insmod:


 insmod ./HelloWorld.ko

Una volta installato il modulo (è possibile controllarne l'installazione con lsmod) si possono vedere i primi messaggi del kernel. Un dmesg mostra infatti la stampa della funzione di inizializzazione.
Rimuovendo poi il modulo con:

 rmmod HelloWorld
si avrà lo scaricamento dalla memoria del modulo e la scrittura fra i messaggi del kernel che la funzione di chiusura del modulo è stata richiamata.

lunedì 22 giugno 2009

Programmazione a oggetti in Perl

Perl è un linguaggio molto elegante e potente, che viene spesso insegnato per evidenziare concetti un po' più evoluti riguardo lo scripting.
Pur supportando la programmazione ad oggetti, Perl non fornisce alcun costrutto particolare per la realizzazione di classi e tipi di dato astratto. Si può paragonare Perl a un C che viene programmato ad-hoc per implementare un comportamento ad oggetti.
Imparare a programmare Perl a oggetti è molto interessante, soprattutto perché permette di vedere effettivamente come molti compilatori a oggetti si comportano. Inoltre gran parte della libreria Perl/CPAN è orientata agli oggetti, e quindi è indispensabile avere nozioni di OOP. Non è comunque facile trovare una guida sulla programmazione OOP in Perl, perciò ho deciso di scrivere questo articolo introduttivo. Da notare che farò riferimento a versioni di Perl inferiori alla 6, dove la scrittura di classi e oggetti cambierà grazie alla presenza di apposite parole chiave.

Il seguente elenco mostra i punti per me fondamentali da tenere a mente quando si vuole implementare una classe e di conseguenza usare degli oggetti.

Gli oggetti possono essere acceduti solo per riferimento.

Ogni istanza di oggetto viene mantenuta in un riferimento, in maniera simile a come avviene in Java.

Un riferimento ad un oggetto è un normale riferimento scalare
.
Come i riferimenti alle strutture dati native (hash, array) sono contenuti in variabili scalari, così pure i riferimenti agli oggetti sono mantenuti in variabili scalari.

Una classe corrisponde ad uno spazio dei nomi, e quindi si implementa tramite un package.

In Perl una classe è una entità sul quale sono richiamati dei metodi. Per la precisione, un metodo di classe è un metodo al quale viene passato un parametro che indica lo spazio dei nomi nel quale si agisce. Ecco quindi che assegnare un metodo ad una classe corrisponde ad inserire un metodo in un determinato package: il metodo potrà essere invocato solo nell'ambito di quello spazio dei nomi (classe/package).

Se la struttura dati dell'oggetto è complessa, allora essa deve essere realizzata tramite un array o un hash, e il riferimento all'oggetto diventa il riferimento all'array/hash.
Questo punto va chiarito bene: in Perl esistono solo tre tipi di variabili (scalari, array, hash) e una classe sarà presumibilmente composta da diverse variabili di tale tipo. Dovendo però usare un riferimento ordinario (si vedano i punti precedenti) per l'oggetto, si ha che tale riferimento deve essere il punto di ingresso di una struttura più complessa. Di conseguenza, il riferimento all'oggetto deve essere un riferimento ad un array/hash che contenga tutte le altre variabili di istanza. Per meglio comprendere, se in Java una definizione di classe Person potrebbe essere così strutturata:
public class Person{
private String name = null;
private String surname = null;
}

In Perl non potrebbe avere la definizione duale, ossia:

package Person;

$name = undef();
$surname = undef();
poiché, così facendo, si avrebbe che lo spazio dei nomi della persona (Person) contiene due variabili scalari, ed è impossibile ritornare un singolo riferimento che fornisca accesso ad entrambe le variabili. E' quindi necessario incapsulare le variabili di classe all'interno di un unico contenitore e fornire accesso attraverso tale contenitore:

package Person;
...
$this = { name => undef(),
surname => undef(),
};


In questo modo la variabile $this consente accesso ai valori di name e surname, ed è possibile ritornare all'esterno un singolo riferimento a $this.
Da notare che la seguente traduzione non funziona come ci si aspetta:

package Person;

$name = undef();
$surname = undef();

$this = { name => \$name,
surname => \$surname,
};

Infatti così facendo si ha l'esistenza di uniche variabili $name e $surname e di conseguenza i riferimenti di ogni oggetto creato puntano alle stesse variabili globali (all'interno del package) e quindi agli stessi valori. La soluzione di cui sopra è invece appropriata per variabili statiche (ossia condivise all'interno di ogni classe).

Un metodo di classe o di oggetto riceve sempre in automatico un primo argomento che specifica la classe o l'istanza
.
Questa cosa non dovrebbe stupire particolarmente, poiché è già quello che avviene nei normali compilatori ad oggetti: il primo parametro di un metodo di istanza è il puntatore/riferimento all'istanza stessa. E' in questo modo che i compilatori predispongono la variabile this. In altre parole, il metodo Java seguente:
public class MyClass{
public void instanceMethod(String arg1, int arg2){
this.stringVariable = arg1;
this.integerVariable = arg2;
}
}

viene mutato dal compilatore silenziosamente nel seguente:

public class MyClass{
public void instanceMethod(MyClass this, String arg1, int arg2){
this.stringVariable = arg1;
this.integerVariable = arg2;
}
}

Da notare che il primo parametro, di nome simbolico this, è un riferimento all'oggetto stesso. In altre parole i metodi di istanza ottengon come parametro la zona di memoria (o meglio il riferimento a tale zona) dove risiede l'oggetto sul quale si agisce. Perl segue lo stesso percorso: il primo argomento di un metodo di istanza contiene il riferimento all'oggetto stesso, di modo che il metodo possa essere scritto come:

sub instanceMethod{
my ($this, $arg1, $arg2) = @_;
...
}
La differenza è che qui è compito del programmatore ricordarsi che il primo argomento è il riferimento all'istanza; il compilatore Perl infatti fa solo la prima parte del lavoro (passare al metodo il riferimento come primo argomento).
Quanto sopra per quello che riguarda gli oggetti, ma per le classi?
In un linguaggio OOP come Java/C++ i metodi di classe (es. static) non necessitano di nessun argomento particolare o di modifiche da parte del compilatore. Infatti quello che avviene è che viene tenuta in memoria la tabella di dispatching dei metodi e l'invocazione di un metodo corrisponde al salto all'indirizzo fornito da questa tabella. Ma il metodo non ha bisogno di sapere se appartiene ad una classe oppure no, come non ha bisogno di sapere a che classe appartiene poiché per forza di cose, se non è di istanza, deve essere di classe.
In Perl questo non è vero: essendo una classe implementata tramite un package, i metodi all'interno del package potrebbero essere di istanza, oppure di classe, oppure nessuno dei due (normali metodi globali). Perl allora fornisce un modo per informare un metodo che è stato invocato in un contesto di classe (ossia come se fosse un metodo di classe): questo metodo riceverà infatti come primo argomento il nome (stringa) della classe/package al quale appartiene.
Riassumendo quindi, tutti i metodi di classe o di oggetto in Perl ricevono come primo argomento una variabile che indica il nome della classe (metodo di classe) o il riferimento all'oggetto stesso (metodo di oggetto) e non ricevono nulla se sono chiamati in un normale contesto di package.

In Perl non esiste il concetto di costruttore (e di distruttore)
.
Siccome Perl non fornisce nessuna parole chiave per definire una classe, i metodi costruttori (e distruttori) non esistono. Questo non significa che non si possano creare dei metodi appositi per l'inizializzazione delle variabili di un oggetto. Tali metodi dovranno ovviamente restituire al chiamante il riferimento alla struttura dati dell'oggetto.

Un metodo usato come costruttore non deve avere lo stesso nome della classe
.
Siccome questi metodi non sono dei veri e propri costruttori, non devono seguire le regole standard dei costruttori Java e C++: essi possono (o meglio devono) avere un tipo di ritorno (solitamente il riferimento alla struttura dati dell'oggetto) e possono avere un nome non vincolante (solitamente new).

In Perl non esiste l'operatore new
.
Quando si incontra qualcosa che assomiglia all'operatore new per l'allocazione di un oggetto, si sta in effetti osservando la chiamata di un metodo di nome new (si veda il punto precedente).
Il compilatore passa automaticamente ad un metodo il primo argomento (nome della classe o riferimento ai dati) quando si usa l'operatore freccia.
Quando la chiamata ad un metodo avviene attraverso l'operatore freccia, il compilatore passa come primo argomento del metodo l'oggetto lvalue su cui viene applicato l'operatore freccia. In altre parole:
LVALUE->method(arg1, arg2, arg3);

corrisponde a:
method(LVALUE, arg1, arg2, arg3);
Questo significa quindi che usando l'operatore freccia su i metodi di un package si ha automaticamente una chiamata a metodo di classe, mentre usando l'operatore freccia su dei riferimenti ad oggetti si ha una chiamata ad un metodo di istanza. Quindi ad esempio, per creare un nuovo oggetto, si può invocare il metodo new nei due modi equivalenti:
$objectReference = Person->new('Luca', 'Ferrari'); # sintassi di classe
$objectReference = new( Person, 'Luca', 'Ferrari'); # sintassi di package


e analogamente, una invocazione di metodo di oggetto può essere scritta come:

$objectReference->setName('Giovanni'); # sintassi di oggetto
Person::setName( $objectReference, 'Giovanni'); # sintassi di package

Perl deve sapere quali riferimenti puntano ad un oggetto e quali no.
Il costruttore di un oggetto non deve solo inizializzare l'oggetto e il suo stato, ma deve anche informare Perl che il riferimento non è un normale riferimento ma un collegamento ad un oggetto. Questo avviene tramite l'operatore bless, che accetta il riferimento ad una struttura dati e la classe/package a cui la struttura dati appartiene. L'operatore memorizza in una tabella il collegamento fra il riferimento e il nome del package/classe a cui è associato, in modo da poter individuare a quale classe il riferimento appartiene. In particolare, in seguito al blessing, l'operatore ref applicato ad un riferimento di oggetto restituisce il nome della classe per la quale è stato fatto il blessing.
Sulla base di questa considerazione, il template generale per un costruttore di oggetto è il seguente:

sub new
{
my ($class, @args) = @_;
# inizializza i valori dell'oggetto
$this = { arg1 => $args[0],
arg2 => $args[1],
...
};

bless( $this, $class );
return $this;
}





Sulla base di tutti i punti di cui sopra, è possibile paragonare la creazione di una classe/oggetto fra un linguaggio OOP (es. Java) e Perl. Supponiamo di avere la seguente classe Java:

public class Person{
public static int personCounter = 0;

private String nome = null;
private String cognome = null;

public Person(String nome, String cognome){
this.nome = nome;
this.cognome = cognome;
Person.personCounter++;
}


public String getNome(){
return this.nome;
}

public String getCognome(){
return this.cognome;
}
}

e di volerla tradurre in Perl. La sua definizione diviene la seguente:

#!/usr/bin/perl

package Person;

# variabile statica (la stessa
# condivisa fra tutte le istanze)
$personCounter = 0;


sub new
{
my ($class, $name, $surname) = @_;

# creazione nuovo riferimento ad hash
# con i dati (stato) dell'oggetto
$this = { name => $name,
surname => $surname,
};



# associo il riferimento alla classe
bless( $this, $class );

# incremento il contatore di istanze create
$personCounter++;

print "\nCreazione di un nuovo oggetto di tipo $class (numero $personCounter)\n";

# restituisco il riferimento appena creato
return $this;
}




sub getNome
{
my ($this) = @_;

# restituisco il dato richiesto
return $this->{name};
}


sub getCognome
{
my ($this) = @_;

# restituisco il dato richiesto
return $this->{surname};
}




che può essere testato con il seguente main:

package main;

$person1 = Person->new('Luca','Ferrari');
$person2 = Person->new('Paperon','De Paperoni');

print "\nPersona con nome ", $person1->getNome();
print "\nAltra persona con nome ", $person2->getNome(), " ", $person2->getCognome();
print "\n\n";


che produce il seguente output:

Creazione di un nuovo oggetto di tipo Person (numero 1)

Creazione di un nuovo oggetto di tipo Person (numero 2)

Persona con nome Luca
Altra persona con nome Paperon De Paperoni


Ereditarietà e Polimorfismo
L'ereditarietà in Perl viene implementata in modo molto semplice: è disponibile un array globale all'interno dello spazio dei nomi di un package, denominato ISA, che contiene le classi/package dalle quali si vuole ereditare. L'idea quindi è semplice: ogni package definisce una lista di ulteriori package in cui cercare dati e/o metodi. Quando Perl non trova un attributo nel package specificato inizia ad esplorare (sequenzialmente) l'array ISA al fine di trovare in ogni classe specificata il simbolo, e quindi lo utilizza.
Per meglio comprendere questo concetto, si consideri di estendere la classe Person con una classe Male che implementa una persona di sesso maschile:


package Male;

@ISA=(Person);

sub new
{
my ($class, $name, $surname) = @_;

# creazione nuovo riferimento ad hash
# con i dati (stato) dell'oggetto
$this = { name => $name,
surname => $surname,
};



# associo il riferimento alla classe
bless( $this, $class );

# incremento il contatore di istanze create
$personCounter++;

print "\nCreazione di un nuovo oggetto di tipo $class (numero $personCounter)\n";

# restituisco il riferimento appena creato
return $this;
}


Come si può notare la definizione del costruttore è praticamente la stessa della classe Person, addirittura si referenzia un simbolo ($personCounter) che qui non è stato ancora definito. Ora se un programma crea un nuovo oggetto di tipo Male:

$maschio = Male->new( $person1->getNome(), $person1->getCognome() );
print "\nPersona maschio con nome ", $maschio->getNome(), " ", $maschio->getCognome();


l'output di esecuzione è del tutto simile a quello del programma precedente, e addirittura la variabile $personCounter inizia il suo conteggio come fosse separata dalla classe Person (ovvero come fosse stata definita singolarmente di classe). Tutta la magia viene fatta nella ricerca dei simboli, che anziché passare per una vtable passa per l'array ISA del package corrente (ogni package può ridefinire il proprio @ISA).

La ridefinizione dei metodi è automatica, quindi se si ridefinisce il seguente metodo nella classe Male si ha che la chiamata a getNome() verrà risolta da tale metodo:

package Male;

@ISA=(Person);

sub new
{
my ($class, $name, $surname) = @_;

# creazione nuovo riferimento ad hash
# con i dati (stato) dell'oggetto
$this = { name => $name,
surname => $surname,
};



# associo il riferimento alla classe
bless( $this, $class );

# incremento il contatore di istanze create
$personCounter++;

print "\nCreazione di un nuovo oggetto di tipo $class (numero $personCounter)\n";

# restituisco il riferimento appena creato
return $this;
}



sub getNome
{
my ($this) = @_;

return $this->{name} ." (maschio) ";
}


E' inoltre possibile riferirsi alle proprietà della classe base mediante l'uso di SUPER. Si presti attenzione poiché qui super è un operatore che si preoccupa di salire di un livello nella scala dei riferimenti, ma il nome della classe deve essere sempre specificato come primo argomento: SUPER deve quindi essere usato in combinazione con l'operatore freccia.

package Male;

@ISA=(Person);

sub new
{
my ($class, $name, $surname) = @_;

$this->SUPER::new( $name, $surname );


# associo il riferimento alla classe
bless( $this, $class );

# incremento il contatore di istanze create
$personCounter++;

print "\nCreazione di un nuovo oggetto di tipo $class (numero $personCounter)\n";

# restituisco il riferimento appena creato
return $this;
}



sub getNome
{
my ($this) = @_;

return $this->SUPER::getNome() ." (maschio) ";
}


Si noti che quando si usa SUPER la parte a destra viene sempre invocata con la sintassi di package (::) mentre quella di sinistra con la sintassi ad oggetto (->).


Per concludere
Riassumendo quindi si ha che in Perl la programmazione ad oggetti viene attualmente implementata tenendo separati i metodi e i dati, in modo piuttosto esplicito. Il riferimento ai dati rappresenta il riferimento all'oggetto (e quindi al suo stato), mentre l'invocazione dei metodi avviene grazie all'operatore freccia, che impone al compilatore di passare l'entità di sinistra (il riferimento o il nome della classe) come primo argomento. Grazie poi ad una tabella dei simboli gestita tramite l'operatore bless si ha l'associazione fra riferimento ai dati e classe, e questo consente, in combinazione all'array @ISA di sfruttare anche l'ereditarietà e il polimorfismo.

mercoledì 17 giugno 2009

Linus può...

Ispirandosi alle scenette di Chuck Norris dello Zoo di 105, ecco le abilità segrete di Linus Torvalds...

domenica 7 giugno 2009

Il ruolo delle Materialized-Views

Una vista materializzata (Materialized-View) non è altro che una tabella (solitamente temporanea) che memorizza il risultato di una particolare query su dati di dimensioni evelate. L'idea è quella di anticipare le richieste di risorse di una query estraendo i dati prima che il client effettui la query.
Supponendo di avere una tabella molto vasta (qualche milione di righe), e sapendo in anticipo su quali proiezioni di dati i client vogliono lavorare, è possibile estrarre questi dati in una elaborazione batch, e far si che i client accedano a questo sotto-insieme dei dati già estratti.
Quali sono i vantaggi?
Anzitutto sulla tabella così costruita è possibile costruire indici ad-hoc, e siccome questa tabella non deve essere aggiornata (poiché rappresenta una porzione dei dati sorgenti, e andranno aggiornati solo questi ultimi), anche gli indici non devono essere aggiornati. Ne consegue che in questo caso gli indici rappresentano un caso di puro catalizzatore di accesso.
In secondo luogo la tabella così costruita può contenere il risultato di diverse computazioni che altrimenti andrebbero eseguite al volo, con conseguente richiesta di tempo e risorse.
Ma le viste materializzate hanno anche degli svantaggi: il primo fra tutti è che si opera su dei dati non aggiornati, e questo richiede infatti una buona progettazione per stabilire ogni quanto la vista deve essere annullata e ricreata (o quantomeno aggiornata). Il secondo svantaggio è la richiesta di spazio. ai dati originali si aggiunge la copia costruita ad-hoc.
Non esiste una regola fissa per l'uso delle viste materializzate: occorre analizzare attentamente il carico di lavoro sul database, le query effettuate dal client e le eventuali richieste OLAP (assieme alla loro frequenza). Solo così si sarà in grado di realizzare un sistema con viste materializzate che funzioni.

Patella con aggancio triplo

Osservando alcune foto di arcieri americani mi è saltata all'occhio la patella usata da Brady Ellison. Cos'ha di particolare? Ebbene la patella in questione differisce da quelle tradizionali perché dotata di un sistema di aggancio triplo: anziché avere l'elastico di aggancio attorno al solo dito medio, è dotata di tre elastici che avvolgono indice, medio e anulare.


Dopo qualche indagine in rete
ho scoperto che la suddetta patella viene costruita appostiamente presso il centro JOAD dall'attuale coach K. Lee e che è disponibile in commercio una versione con il piatto metallico già predisposto per un simile aggancio a tre dita.
Non sono particolarmente fiducioso sul fatto che un tab con wrapper per le tre dita sia realmente indispensabile, ma sicuramente è un'idea interessante. Il problema secondo me è che, mentre con un tab classico quest'ultimo ha una cera liberta di movimento e si può automaticamente posizionare sulla corda secondo la pressione delle dita, quello con triplo wrapper rischia di posizionarsi male sulla mano e di rimanere fissato in quella posizione per tutti i tiri, con conseguente problemi sull'uscita della corda. In sostanza, a mio parere, il triplo wrapper può risultare molto comodo in situazioni climatiche avverse, ovvero quando la mano è comunque umida (sudore o pioggia), ma il suo posizionamento deve essere ancora più accurato e controllato al momento della salita dell'arciere in pedana. Sono curioso comunque di fare una prova modificando una delle mie patelle per provare, anche se rimango dell'opinione che il singolo wrap non stretto sia il migliore. Chi si ricorda dei vecchi wrap metallici delle Cavalier e ha presente le rotazioni che Justin Huish faceva compiere al tab prima di ogni tiro capisce di cosa parlo...

mercoledì 3 giugno 2009

Scream

Niente da dire, Chris Cornell non si smentisce mai.
Ho iniziato ad apprezzarlo fin dai tempi dei Soundgarden, che rimpiango moltissimo.
Il progetto degli Audioslave è stato molto buono, e sono perfino adnato a vedere il loro concerto al Flippaut di Bologna.
E ora questo bellissimo album da solista, a mio avviso migliore di Euphoria Morning.
Continua così! (ma per via di una reunion con i Soundgarden?)

martedì 2 giugno 2009

Qualità della rivista federale

Arcieri è la rivista ufficiale della FITARCO, e viene mandata a tutti i tesserati che ne facciano richiesta al momento dell'iscrizione in federazione. Essendo iscritto alla federazione da parecchi anni (inizia nel 1991) ho visto l'evoluzione della rivista fino a questi giorni, e devo dire che sono molto deluso da come sia diventata.
Infatti, mentre una volta la rivista includeva articoli tecnici, spunti di riflessioni, e foto di grandi campioni al tiro, oggi include solo resoconti di eventi arcieristici, pochissimi (se non nessuno) articolo tecnico degno di nota, e solo foto di podi e premazioni.
Perché è così importante la qualità tecnica della rivista?
Anzitutto perché la rivista rappresenta il primo contatto che l'atleta ha con la sua federazione, e di conseguenza una rivista accattivante e che invoglia alla lettura implica fiducia e partecipazione nella federazione (non è automaticamente vero il contrario però). In secondo luogo la rivista rappresenta una forma di informazioni autorevole e ufficiale, e quindi è una sorta di guida ufficialmente approvata per chi vuole praticare la disciplina in Italia.
Per meglio comprendere cosa manchi, a mio avviso, alla rivista oggi, è sufficiente fare qualche confronto con i numeri delle precedenti edizioni. Citerò qualche esempio, quelli che mi vengono in mente, ma ovviamente si potrebbe analizzare ogni singolo numero per trovarne altri.
Una volta veniva pubblicata una serie di articoli specifici sull'Hunter&Field, nei quali venivano presentate le principali tecniche di valutazioni delle distanze, gli errori di posizionamento ecc.; oggi di questa tipologia di articoli non esiste traccia.
Una volta venivano pubblicate interviste a grandi campioni internazionali, mentre oggi non vedo nessuna intervista.
Una volta venivano pubblicati articoli tecnici sulle metodologie di messa a punto dell'arco, sulla selezione delle freccie, e su esercizi di allenamento. Ora sono rimaste solo alcune timide rubriche sull'allenamento fisico, che però lasciano realmente il tempo che trovano. Qualche volta si è trovato un estratto tecnico di un qualche libro, molto interessante a mio giudizio, ma la serie di articoli non ha avuto seguito.
Oltre a queste considerazioni qualitative, ne va fatta anche una quantitiva: la lunghezza della rivista è rimasta pressoché la stessa negli anni, ma ora la rivista include anche il Notiziario Federale, che veniva invece mandato a parte. Essendo ancora presenti le classifiche degli eventi arcieristici, ed essendo presente (giustamente) piu' pubblicità che un tempo, cosa è stato rimosso per far spazio al notiziario federale? Forse sono state tagliate anche le foto? Eppure quelle ci sono, ma sono foto di scarso valore tecnico, poiché quasi tutte ritraggono gruppi di atleti e podi. Certo è molto importante dare gratificazione ai nostri atleti, ma una volta questa veniva data pubblicando una foto dell'atleta al tiro, perché ora non viene fatto? Forse è piu' importante la sua divisa (nazionale) che la sua attrezzatura? Eh si, perché una volta dalle foto si potevano anche spiare le attrezzature dei campioni, vedere il loro setup per poi ragionarcici sopra. Lo stesso discorso valeva per le loro tecniche. Insomma, anche da una foto poteva nascere uno spunto di riflessione!
Poi c'è il resoconto degli eventi. Si, perché questo non manca, ma viene fatto in maniera asettica, senza nessun risvolto tecnico. Non si parla delle tecniche, tecnologie e stranezze di vincitori e vinti. Ci si limita a dare un secco bollettino di come è andato l'evento. Ma questo lo si puo' avere quasi in tempo reale con altri mezzi di informazione, ed ecco quindi che se la rivista mi deve riproporre, con un ritardo di circa due mesi (quando va bene) informazioni vecchie, francamente la voglia di leggerla si tramuta in voglia di sfogliarla!
Ora, ho provato a sondare il terreno e vedere se qualcun altro avesse questa mia impressione, ma apparentemente la gente oggi è talmente bombardata da informazioni che se non trova quello che cerca sulla rivista lo va a cercare in Internet o da un'altra parte. Ma questa non è una giustificazione perché la rivista abbia perso spessore tecnico. E si badi che io non penso alla rivista come la bibbia dalla quale copiare (anche se dopotutto c'è gente che copia da libri ben peggiori!), ma come un possibile spunto di riflessione. E se questi vengono a mancare, allora perché leggerla?

E giusto per fare un esempio, si consideri il numero 2 del 2009 (l'ultimo al momento in cui scrivo). Ebbene in questo numero i campionati del mondo indoor sono liquidati in appena due pagine, alle quali si sommano altre due pagine di rapide considerazioni sul settore giovanile. Non viene citato in nessun punto alcuna curiosità tecnica o tecnologica sui vincitori, addirittura non si sa chi componga la squadra USA (vincitrice dell'oro maschile), visto che il terzo componente non compare nemmeno nella classifica a fine rivista. Ancora: viene presentato un articolo sulle contratture muscolari, molto interessante. Però l'articolo (anch'esso di due pagine - come quello sui mondiali - quasi avessero lo stesso spessore) presenta due foto di un'atleta olimpionico che effettua esercizi con un elastico alla spalliera. Cosa c'è di strano? Beh, non si citano le figure e/o gli esercizi in tutto l'articolo. Allora le foto a cosa servono? A riempire spazio? Vengono inserite per alimentare l'immaginazione del lettore sul loro scopo? E infine l'articolo della rubrica agonismo sul ritorno della Freccia D'Argento in versione giovanile; nessun commento tecnico.
Possibile che non si possa pubblicare qualcosa di meglio?

lunedì 1 giugno 2009

Non usate Facebook

Un articolo veramente interessante sull'uso di Facebook, del quale questa frase mi sembra riassuma abbastanza bene il contenuto:

Futhermore, have you Facebook users ever actually read the privacy policy? It tells you that you don't have much privacy.