Calendario dell'Avvento ITPUG: 24 Dicembre

Non è molto originale, ma ad ogni modo Auguri a tutti!

% psql -c "select initcap( chr( 65 ) || chr( 117 ) || chr( 103 ) || chr( 117 ) || chr( 114 ) || chr( 105 ) || chr( 33 ) );"

ITPUG's Advent Calendar

This December, borrowing a concept commonly used in other communities, I decide to challenge the ITPUG members in writing an Advent Calendar.

The idea is quite simple: write a post (related to PostgreSQL of course) per day.

We started a little late, on December 3rd, and were able to push an article almost every day so far. Posts were pushed to the ITPUG members mailing list, generating several interesting discussions among the italian community.

It is possible to find the posts at our (italian-language) planet at www.planetpostgresql.it; please note that all articles on the planet are from my blog because I did the effort to "forward" them to the planet.

I hope this would be the first of several ITPUG Advent Calendars, and I hope other PostgreSQL Users' Groups will do the same in the future.

I'd like to thank all PostgreSQL developers, translators, testers for the great product they continue to deliver us.

And I wish a Merry Christmas to you all.

Calendario dell'Avvento ITPUG: 23 Dicembre

Un'utility interessante che mi sono sempre riproposto di sperimentare è pgCluu.

Pgcluu viene distribuito con due eseguibili: pgcluu e pgcluu_collectd. Il secondo è la parte che si preoccupa di collezionare le statistiche e di archiviarle su file system, in maniera simile a quanto fatto da altri tool di monitoring (ad esempio flow-tools). Il programma pgcluu è invece il responsabile di fare il reporting delle statistiche.

In default la collezione delle statistiche avviene su due fronti: il cluster e il sistema, mediante sar. E' comunque possibile disabilitare l'uso di sar, e in particolare lo switch -h (che svolge la stessa funzione dell'omonimo di psql) disabilita l'uso di sar.

Da notare che nonostante gli eseguibili siano due, la pagina di manuale è una sola ed è riferita a pgcluu(1).

% export STAT_DIR="/tmp/pgcluu_stats_collection";
% mkdir $STAT_DIR && pgcluu_collectd -d demodb -h localhost -M 200MB -D -i 10 -U luca --stat-type all $STAT_DIR
LOG: Detach from terminal with pid: 4442

Si è creata una directory dove verranno collezionate le statistiche e si è lanciato il programma di raccolta dati. Le opzioni usate fanno si che il processo vada in background (-D), si colleghi al database "demodb" (-d) con utente "luca" (-U) sulla macchina locale (-h). Per evitare l'esecuzione incontrollata si fissa una soglia di raccolta dati con tetto massimo di 200 MB (-M), si abilita la raccolta di tutte le statistiche (--stat-type) presenti in PostgreSQL (ossia si legge pg_stats_all) e si vuole che le statistiche siano collezionate ogni 10 secondi (-i).

Attenzione all'opzione -D che può risultare subdola: se il database richiede una password per l'utente il prompt per la password non viene richiesta e pgcluu_collectd termina subito. Occorre quindi utilizzar eil file ~/.pgpass per permettere la connessione automatica (come per psql - in effetti si usa psql per collezionare i dati).

Nella directory STAT_DIR si troverà un file testuale "sysinfo.txt" che contiene un dump di svariate informazioni di sistema (spazio dischi, dmesg, sysctl, ecc.). Altri file comprendono le statistiche di sistema in formato CSV:

Ora generando un po' di carico sul database sotto analisi:

demodb=# CREATE TABLE baz(value int);
demodb=# insert into baz select generate_series(1, 1000);
demodb=# insert into baz select generate_series(1, 1000000);
demodb=# insert into baz select generate_series(1, 1000000);


A questo punto si può generare il report:

% export STAT_OUTPUT_DIR=/tmp/pgcluu_stat_output
% mkdir $STAT_OUTPUT_DIR && pgcluu -o $STAT_OUTPUT_DIR -v -S $STAT_DIR
...
DEBUG: Inserting menu into all html files.

E il gioco è fatto: puntando il proprio browser alla directory di output si avrà accesso alle statistiche collezionate in un modo un po' piu' user-friendly.

Da notare che il manuale di pgcluu indica di terminare esplicitamente il demone di raccolta statistiche prima di generare il report, ma io ho provato a farlo anche senza fermarlo e tutto pare funzionare ugualmente. Unica pecca: non si possono generare i report sovrascrivendoli di volta in volta, perché pgcluu si rifiuta. Ne consegue che per eseguire il tutto in formato schedulato occorre prevedere lo svuotamento della directory di output o almeno un qualche modo di rotazione.

Ah, ultima cosa:

% file `which pgcluu`
/usr/local/bin/pgcluu: Perl script, UTF-8 Unicode text executable

Calendario dell'Avvento ITPUG: 22 Dicembre

Esiste un Foreign Data Wrapper di SQLite.

Io personalmente non lo uso per scopi specifici, quanto piu' per "collegare" un'istanza PostgreSQL a diversi database del mio desktop KDE. Molte applicazioni KDE infatti si appoggiano a SQLite, e a dire il vero anche altri strumenti come fossil (fossil-scm.org) lo fanno. Lo scopo pe rme è quello solo e puramente di studio dei meccanismi interni di aclune applicazioni, un giorno forse avrò anche bisogno di manipolare in diretta i dati. Ad ogni modo l'uso è abbastanza semplice, quasi banale per chi è abituato ai fdw.

Faccio un esempio specifico: digikam

== Passo 1: fare il dump dello schema del database ==

% sqlite3 -interactive digikam4.db
sqlite> .output digikam.sql
sqlite> .schema
sqlite> .q

== Passo 2: preparare uno script di migrazione ==

Mi faccio aiutare qui da Perl (lo script lo riporto in seguito):

% perl export.pl digikam.sql digikam_server /tmp/digikam4.db >
export_digikam.sql

così facendo creo un file export_digikam.sql che creerà il server "digikam_server" partendo dal file di dump "digikam.sql". Il nome del file "digikam.db" serve solo per collegare il data wrapper al database SQLite giusto.

== Passo 3: caricare le tabelle e il foreign data wrapper ==

Da un promp psql è abbstanza banale accedere via fdw:

image=# CREATE EXTENSION sqlite_fdw;
image=# \i ~/Pictures/digikam_export.sql

e tutto è fatto!
Ok, vediamo quanta "roba" c'è nel database:

image=# SELECT count(id) as Foto, sum( filesize ) / (1024 * 1024 *
1024) as Gigabytes FROM images;

foto  | gigabytes
------+-----------
39491 | 285




===== script perl di conversione ======
#! /usr/bin/perl

use v5.10;
my $IN;
my $server = $ARGV[ 1 ];
my $file = $ARGV[ 2 ];
open $IN, "<", $ARGV[ 0 ] || die "\nImpossibile leggere file dump\n$!"; 
say "CREATE SERVER $server FOREIGN DATA WRAPPER sqlite_fdw OPTIONS (database \'$file\');"; while (<$IN>) {

if ( /CREATE TABLE (\w+)/ ) {
  $table = $1;
  $sql = "CREATE FOREIGN TABLE $1 (\n";
}
elsif ( $table ){
  chomp;
  s/DATETIME/TIMESTAMP/;
  s/PRIMARY KEY/NOT NULL/;
  s/\(//;
  $sql .= $_ . "\n" unless /(UNIQUE | \)\; ) /xms;
  if ( /[\)\;]/ ){
    $sql =~ s/,$//;
    $sql .= ") \n\t SERVER $server \n\t OPTIONS (table \'$table\' );\n" ;
    say $sql;
    undef $table;
    undef $sql;
  }
 }

}

Calendario dell'Avvento ITPUG: 21 Dicembre

Questa mattina Denis batte tutti sul tempo e pubblica sulla mailing list un articolo veramente piacevole da leggere e ben dettagliato su come usare l'estensione pg_partman che consente di automatizzare molti dei compiti del partizionamento in PostgreSQL.

L'articolo di Denis fornisce un esempio pratico e illustra anche alcuni dei problemi che potrebbero insorgere nell'utilizzo del partizionamento.

Calendario dell'Avvento ITPUG: 20 Dicembre

Vorrei introdurre una utility con la quale sto spendendo un po' di tempo e che, anche se non direttamente collegata a PostgreSQL, può semplificare la gestione di un database: sqitch.
Sqitch funziona con molti database, fra i quali ovviamente PostgreSQL, producendo degli script sql che vengono usati per fare il deploy/aggiornamento/test di un database.
Sqitch concettualmente funziona un po' come un repository Git/hg:

• si installa uno schema "sqitch" nel database sotto controllo;
• si usa questo schema per memorizzare le modifiche effettuate e "firmate" con un hash crittografico

Il tutto è trasparente all'utente, che usa il solo comando "sqitch" un po' come si usa git (e molti comandi e il loro output sono simili, come ad esempio log, status, add).
Attenzione però che sqitch non sostituisce un sistema di controllo delle versioni, quindi è buona norma usare sqitch tenendo comunque gli script SQL sotto controllo delle versioni.

Ecco un rapidissimo esempio per la generazione di due tabelle in un database (demodb) esistente.

• crare un nuovo progetto e definire il database

% sqitch --engine pg init itpug
% sqitch target add itpug db:pg://luca:pwd@localhost/demodb
così facendo si crea un progetto "itpug" e si definisce che quando ci si riferisce al database "itpug" si punta in realtà a demodb.

• si aggiunge lo script per la prima tabella

% sqitch add authors -m "Tabella autori"                                                        
Created deploy/authors.sql
Created revert/authors.sql
Created verify/authors.sql
Added "authors" to sqitch.plan
% echo "CREATE TABLE authors( pk serial NOT NULL, name text NOT NULL, primary key(pk));" > deploy/authors.sql
% echo "DROP TABLE authors CASCADE;" > revert/authors.sql

così facendo sqitch crea tre script sql (vuoti) per il deploy, l'undeploy e la verifica (qui lasciato vuoto).

• si crea una tabella con dipendenza dalla precedente, così da informare sqitch in che ordine le modifiche al database vanno applicate

% sqitch add posts --requires authors -m "Tabella dei post"                                      
Created deploy/posts.sql
Created revert/posts.sql
Created verify/posts.sql
Added "posts [authors]" to sqitch.plan
% echo "CREATE TABLE posts( pk serial NOT NULL, content text , authors_pk integer, primary key(pk), foreign key(authors_pk) references authors(pk) );" > deploy/posts.sql
% echo "DROP TABLE posts;" > revert/posts.sql

• deploy del database, e si nota come sqitch si colleghi a demodb per creare le tabelle nel giusto ordine.

% sqitch deploy itpug                                                                            
Adding registry tables to itpug
Deploying changes to itpug
  + authors .. psql:deploy/authors.sql:1: NOTICE:  CREATE TABLE will create implicit sequence "authors_pk_seq" for serial column "authors.pk"
psql:deploy/authors.sql:1: NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "authors_pkey" for table "authors"
ok
  + posts .... psql:deploy/posts.sql:9: NOTICE:  CREATE TABLE will create implicit sequence "posts_pk_seq" for serial column "posts.pk"
psql:deploy/posts.sql:9: NOTICE:  CREATE TABLE / PRIMARY KEY will create implicit index "posts_pkey" for table "posts"
ok

Da qui in avanti si può usare "log" o "status" per sapere in che stato ci si trova, se ci sono script non ancora inviati al server, ecc.
Occorre però specificare sempre a quale database si fa riferimento (che qui è stato denominato itpug per comodità). Se ad esempio eseguiamo status fra due deploy si avrebbe:

% sqitch status itpug                                                                            
# On database itpug
# Project:  itpug
# Change:   173fb5f9cf9f5048e5b2baf6e6699984b4fdb9fe
# Name:     authors
# By:       Luca Ferrari,,,
#
Undeployed change:
  * posts


notare come l'output sia simile a quello di un rcs distribuito, anche se qui git/hg/bzr non sono nemmeno stati toccati.


Ultimissima cosa: gli script crewti da sqitch non sono "vuoti" ma contengono  informazioni su come gestire le dipendenze. Di conseguenza, sovrascrivere tali script come ho fatto nel passo 3 è sbagliato. Meglio quindi editarli nel proprio editor preferito. Per meglio comprendere, consideriamo di aggiungere un'altra tabella con la dipendenza dalle altre due:

% sqitch add statistics --requires authors --requires posts                                      
Created deploy/statistics.sql
Created revert/statistics.sql
Created verify/statistics.sql
Added "statistics [authors posts]" to sqitch.plan

% cat deploy/statistics.sql                                                                      
-- Deploy statistics
-- requires: authors
-- requires: posts

BEGIN;

-- XXX Add DDLs here.

COMMIT;

Ecco quindi che quei commenti sql all'inizio del file indicano a sqitch come procedere.

Se si vuole esplorare come sqitch gestisce il database e la sua storia si può partire dalla tabella sqitch.changes.

Me @ Planet PostgreSQL

This is my first attempt to appear on Planet PostgreSQL.

I'm Luca, the current president of the Italian PostgreSQL Users' Group (ITPUG) and I'm a PostgreSQL addicted.

Unluckily I'm currently not using PostgreSQL in a day-by-day job, but I'm following the evolution of the project and using it wherever is possible.

I hope to able to contribute to the community somehow.

Calendario dell'Avvento ITPUG: 19 Dicembre

Per l'articolo di oggi mi faccio aiutare da un post passato in -advocacy per fare qualche considerazione.
PostgreSQL potrebbe essere il quarto piu' popolare database del pianeta. Dico potrebbe perché ovviamente non ha senso la misura fatta da dbengines.com. Almeno non per me.
Non si tratta infatti di una misura tecnica o tecnologica, quanto piu' sociale.
 

Ora leggendo la metodologia applicata si vede che la metrica tiene presente  quanto si parla nel web di un database. La differenza di punteggio fra PostgreSQL e gli altri tre prodotti che lo precedono è sconvolgente. Ma come si può notare i posti fuori dal podio hanno uno score non troppo dissimile e, a mio avviso, tutti una buona qualità tecnica.
Cosa significa questo in soldoni? Che chi usa PostgreSQL preferisce parlare di cose tecniche e non filosofeggiare. E ciò è bene fino a quando non ci si scontra con queste classifiche, che inevitabilmente potrebbero portare qualcuno a fare la scelta sbagliata su indici forse poco attendibili. 

Tutto questo per ricordare a noi tutti che quanto piu' materiale siamo in grado di produrre e diffondere su PostgreSQL, tanto piu' il database continuerà a guadagnare in popolarità, e tanto piu' sarà facile (per noi) avere a che fare con installazioni PostgreSQL.

Calendario dell'Avvento ITPUG: 18 Dicembre

Personalmente uso Emacs per quasi tutto, eccetto che per collegarmi ad

un database PostgreSQL.

Non che Emacs non possa farlo, ma semplicemente mi trovo meglio con psql per svariate ragioni, compreso il fatto che a volte devo accedere a macchine che non hanno Emacs installato (e non sono raggiungibili da macchine con Emacs installato). Ad ogni modo Emacs dispone di una serie di modi sql-* per svariati database, fra i quali ovviamente PostgreSQL.

Ora perché diavolo qualcuno dovrebbe collegarsi a un database tramite Emacs? Semplicemente perché inglobare il client dentro all'editor facilita lo scambio dati fra script, server, email, e qualunque altro buffer abbiate aperto (inclusi i commit per le versioni)!

Riporto una minimale configurazione per un ambiente con due database (ovviamente username e password sono inventati):

(add-hook 'sql-interactive-mode-hook
 (lambda ()
  (toggle-truncate-lines t)))

(setq sql-connection-alist
'((TEST (sql-product 'postgres)
    (sql-port 5432)
    (sql-server "localhost")
    (sql-user "demo")
    (sql-password "demo")
    (sql-database "demodb"))
 (PROD (sql-product 'postgres)
    (setq sql-port 5432)
    (sql-user "demo")
    (sql-password "demo")
    (sql-database "demodb") ) ) )


(defun pg-connect (which)).
  (interactive "SQuale connessione database?" )
    (setq sql-product 'postgres)
    (let ()
     (message "Connessione al database %s" which)
      (sql-connect which ) ) )

Anzitutto si abilita la modalità "linee lunghe", perché visualizzare l'output delle query con le andate a capo è abbastanza fastidioso. Poi si definiscono due database, nominati TEST e PROD, con i relativi parametri di connessione. Si possono definire quante connessioni si vuole.

Infine la funzione pg-connect chiede all'utente a quale database collegarsi: M-x pg-connect e poi si inserisce il nome del database (TEST o PROD).

Dopodiché emacs apre il prompt (psql) del database in un buffer separato.

Notare che questa configurazione funziona su Emacs 24.4.1 ma mi ha

dato qualche grattacapo su 24.3

Esce PostgreSQL 9.4

Sotto Natale il PostgreSQL Global Development Group ci regala la nuova versione stabile del fantastico ORDBMS: PostgreSQL 9.4.

A few ridicolous (to me) Perl requests

Usually I don't get personal on blogging and commenting: everyone is free to express herself on the net about pretty much any subject. And I'm not getting personal on this set of entries too, but I have to spend a few words on a Perl blogger that is requesting loudly for a set of shortcuts in the language that make no sense at all.

One is about the versioning of the Perl language: stating that Perl 6 is a different beast from Perl 5 is quite easy. But pretending to have different numbering of both versions is awkward. For external developers Perl 6 is the new version of the Perl language, and this is the thruth. The fact that Perl 6 has evolved as a more complex beast than a "simple language improvement" is another fact, but having to number them independently will cause a lot of confusion.

Another issue is about enabling use warnings; silently when specifying use 5.x;. While I understand that it would be much more easy to use a single line pragma, the author does not realize that there is a lot of legacy code that do not explicitly negates warnings since they were not enabled by default. And keeping backward compatibility is really important.

I don't want my programs to behave strangely just because a future version of Perl let me write simpler code: I just want to write simpler code in the future, without having to constantly refactor old code.

On the same mindset if the request to have package to return automatically a true value. Again, the point is valid and I believe in the future could be a reasonable way of programming, but it is not the right choice for legacy code. And moreover, it does not make sense at all when developers will use /package/ multiple times within the same file (because Perl is not Java, right?).

Calendario dell'Avvento ITPUG: 17 Dicembre

Vorrei spendere alcune parole su un progetto, apparentemente abbandonato, ma che potrebbe portare nuova linfa a PostgreSQL e il suo ecosistema: PostgreSQL Magazine.
Circa due anni fa venne lanciata l'idea di questa rivista online, disponibile all'indirizzo http://www.pgmag.org
Io ho seguito i lavori ma non ho partecipato attivamente perché in quel periodo ero alle prese con un'altra rivista, e comunque ho visto nascere il primo numero promozionale che se ben ricordo venne diffuso a PGCon 2012. Sull'onda del successo iniziale si giunse ad un primo numero ufficiale, e poi da lì al secondo che ahimé è rimasto work in progress.
Lungi da me affermare che il progetto è morto, ma sulla mailing list non si ha piu' attività.
Allora perché ne parlo? Perché forse qualcuno è interessato a contribuire all'iniziativa e ha le capacità/volontà/tempo/risorse per rimettere in carreggiata questo sforzo di diffondere ancora di piu' l'amato database.

Calendario dell'Avvento ITPUG: 15 Dicembre

Io sono sempre stato dell'opinione che i commenti siano anche piu' importanti del codice. Però si sa, i programmatori sono pigri, gli admin pure e i commenti spesso si perdono.
Però si può commentare anche un database, e questo potrebbe tornare molto utile. Non parlo dei commenti negli script SQL ( -- e /* */ ), ma del comando COMMENT di PostgreSQL  che consente di attaccare una stringa di testo ad un oggetto di database (tabella, colonna, constraint, funzione, ...).
 

 Per cosa si può usare questa funzionalità? Ad esempio per creare una sorta di versioning del poveraccio: se ogni commento include un numero di versione (generato manualmente o automaticamente) si può capire a che versione un database/tabella è, e quindi si potrebbe intervenire piu' rapidamente per scoprire eventuali anomalie. Ma vediamo COMMENT in pratica:

# COMMENT ON CONSTRAINT imu IS 'no comment!';

(visto il giorno fatidico!)
Piu' seriamente:

# COMMENT ON TABLE foo IS 'Tabella foo versione [1.1]';


Ed è tutto! Solo una stringa può essere agganciata ad un oggetto, e quindi ricommentare lo stesso oggetto equivale a sovrascrivere il commento precedente, mentre impostarlo a NULL equivale a rimuoverlo. I commenti vengono salvati nella tabella pg_description.
Da qui a vedere un dump completo di una tabella il passo è breve:

# WITH rel_comments AS (
SELECT c.relname  AS tabella, CASE WHEN d.objsubid = 0 THEN
'--tabella--' ELSE '(#' || d.objsubid || ') ' || (SELECT attname FROM
pg_attribute a WHERE a.attrelid = c.oid AND a.attnum = d.objsubid )
END AS colonna, d.description AS commento
FROM pg_class c JOIN pg_description d ON d.objoid = c.oid )

SELECT * FROM rel_comments WHERE tabella = 'test';


 tabella |   colonna   |           commento
---------+-------------+------------------------------

  test    | --tabella-- | Tabella foo versione [1.1]
  test    | (#1) pk     | Prima versione della colonna

Un po' piu' complesso risulta invece aggiornare in append i commenti, a meno di non passare per gli oid. E' comunque possibile creare una funzione che accetti il nome della tabella e della colonna, estragga i dati necessari e faccia UPDATE di pg_description concatenando (o sostituendo) il commento.

Calendario dell'Avvento ITPUG: 14 Dicembre

Al primo PGDay.IT del 2007 partecipò anche Mr. Ishikawa, allora presidente del Japan PostgreSQL Users' Group (JPUG). Nel suo talk egli spiegò, fra le altre cose, che il simbolo del JPUG non prevedeva un elefante, come avviene per PostgreSQL e di conseguenza per molti progetti correlati, bensì una tartaruga. La ragione di questa scelta era etica e morale: in Giappone un gruppo appartanente ad un movimento religioso materializzò una serie di attacchi terroristici, forse il piu' famoso dei quali quello alla metropolitana di Tokyo. Durante questi attacchi i terroristi portavano delle maschere raffiguranti un elefante blu.
Ecco quindi che, mentalmente, per i giapponesi è un brutto segno avere un simbolo con elefante, specialmente se blu. 

Insomma, la stessa etica e rigore mentale che si trova anche nel nostro paese!

Ora però perché proprio la tartaruga? Spulciando in giro si può scoprire che POSTGRES, il fratello maggiore di PostgreSQL e figlio di Ingres, aveva come logo proprio una tartaruga. Ancora meglio: il motto del progetto sembrava essere "it's slow but it gets there". 

Indubbiamente si nota lo spirito scherzoso che ha sempre
contraddistinto i prodotti Berkely.

Calendario dell'Avvento ITPUG: 13 Dicembre

E' il turno di Matteo, vicepresidente di ITPUG, che sulla mailing list soci presenta i risultati di un esperimento di join fra datatype numerici di differnti formati e dimensioni.

Materiale molto completo, con anche un grafico che spiega chiaramente quali siano i datatype piu' rapidi per i join (gli int4).

Calendario dell'Avvento ITPUG: 12 Dicembre

Perché va bene avere la replica, HA e fratelli, ma un buon dump ha il
suo valore!
Penso che sia capitato piu' o meno a tutti di scrivere uno script shell per automatizzare il backup (dump) di uno o piu' database PostgreSQL. Personalmente io mi sono trovato nella situazione di scrivere (e riciclare) script di backup che creassero file il cui nome era parlante, includendo nome del database, data del backup, ora del backup, ecc. Il passo successivo è scrivere un ciclo che iteri su tutti i database nel cluster.
Una simile automazione si trova anche negli script che vengono installati automaticamente in una macchina FreeBSD (502.postgres); lo script fa esattamente quello che ho appena descritto, ovvero:

1) itera su tutti i database presenti nel cluster (andando a leggere il catalogo di sistema)
    SELECT datname FROM pg_database WHERE datname!='template0'

2) costruisce un file con il nome del database e la data attuale 

   now=`date "+%Y-%m-%dT%H:%M:%S"`
   ...
   file=${backupdir}/pgdump_${db}_${now}

3) effettua il backup effettivo del database

   daily_pgsql_pgdump_args="-U ${daily_pgsql_user} -bF c"
   pg_dump ${daily_pgsql_pgdump_args} -f ${file} ${db}

Da notare l'uso del formato custom (opzione -F c) che consente il
restore parallelo qualora si voglia dare tutto in pasto a pg_restore.

Va anche detto che lo script in question effettua anche un dump usando
pg_dumpall (che poi viene compresso).

Lo script ha alcune spunti di riflessione interessanti, come ad esempio la protezione dei file di backup e la retention policy: tutti i file di backup giornalieri piu' vecchi di 7 (o della variabile ${daily_pgsql_savedays}) giorni vengono cancellati con l'uso di un find

find ... -a -mtime +${daily_pgsql_savedays} -delete


Insomma, questo script rappresenta un buon punto di partenza per la gestione schedulata dei backup, e ovviamente non si sostituisce ad altre tecniche e tecnologie piu' evolute. 

Sulla mailing list soci si è aperta una discussione con tanti spunti su come migliorare questo tipo di script, ad esempio aggiungendo logging via syslog, mount al volo dei file system di backup, controllo dello spazio disco, ecc.

Calendario dell'Avvento ITPUG: 10 Dicembre

Sul fantastico CPAN è possibile trovare una versione del famoso software di importazione di dati pgloader scritta (ovviamente) in Perl!

Ricordo che il software originale è stato scritto in Python.

Calendario dell'Avento ITPUG: 9 Dicembre

Oggi è il turno di Denis (seguito a ruota da Vincenzo), che sulla mailing list soci ci ricorda l'utilità della clausola WITH ORDINALITY: la possibilità di aggiungere una colonna con ordinamento (a dire il vero ordinalità) ad una query che abbia un funzione che ritorna un SET OF. 

In sostanza, grazie a questa possibilità si possono enumerare l'ordinamento dei risultati estratti dalla funzione e che compaiono nella clausola FROM della query.

Calendario dell'Avvento ITPUG: 8 Dicembre

Dave Page è, fra le altre cose, l'ideatore e lo sviluppatore principale di pgAdmin, il software desktop Open Source piu' utilizzato per l'amministrazione di un cluster PostgreSQL. Sul planet ufficiale è uscito un articolo di Dave che illustra la storia che ha portato pgAdmin fino alla terza versione (l'unica con la quale io abbia mai avuto a che fare).

Oltre ad essere un'interessante lettura per gli eventi storici che si sono susseguiti e che hanno portato Dave a diventare un hacker PostgreSQL, l'articolo in questione è molto importante perché svela che è in cantiere la prossima versione del software, denominata ovviamente pgAdmin 4. Questa versione sarà basata su Python e sarà web-based.

Già, pare che il team di pgAdmin non veda di buon occhio altri linguaggi, come Perl e Java, e questo mi fa pensare che non vedremo un merge delle forze con gli autori di un altro programma web based: PostgreSQL Studio.

Sono comunque convinto che il team di pgAdmin saprà dare alla community un ottimo prodotto, in piena coerenza con quanto fatto fino ad ora.

Calendario dell'Avvento ITPUG: 7 Dicembre

Il client psql permette di inviare l'output delle query su file, cosa abbastanza utile per generare al volo dei report csv, html, LaTeX, ecc. Ma oltre a questo psql include il flag -L (log appunto) che consente di replicare ogni output su un file di log.
In sostanza se si aggiunge il flag -L alla linea di comando normale di psql, specificando un file di log, si avrà che ogni query e il relativo output saranno mandati in copia anche su quel file, indipendentemente da dove l'utente abbia rediretto l'output.
Da notare che il log non rispetta i comandi di allineamento, quindi l'output nel log è sempre "allineato".
Inoltre il log riporta anche le query fatte, comprese le interrogazioni verso il catalogo di sistema (\d e similari), che a loro volta però vanno abilitate con -E.
Infine il log è (ovviamente) in append anche fra piu' sessioni, quindi il file rischia di crescere molto rapidamente.

Calendario dell'Avvento ITPUG: 6 Dicembre

Ecco una "piccola" query che dovrebbe dare uno sguardo piu' facilmente leggibile sui lock attualmente presenti nel sistema. Parto da un possibile output della query per meglio far capire:

-[ RECORD 1 ]---+-------------------------

--------------------------------------
pid             | 1492
locking_summary | RowExclusiveLock GRANTED on table public.listini
user_query      | insert into listini(prezzo) select generate_series(1,1000000);
by              | bsdmag started on 2014-12-05 13:15:02.759257+00 (running)

ovvero si riporta quale processo (pid) ha quali lock (locking_summary) per l'utente (by) che sta eseguendo la query (user_query) a partire dal tempo indicato (by). Altro non è che una reinterpretazione del join fra pg_locks e
pg_stat_activity.

Inserire la query in una vista, denominata verbose_locck, consente di eseguirla piu' facilmente; di seguito la definizione della query/vista:

CREATE VIEW verbose_locks
AS

WITH full_table_name AS
(
   SELECT 'table ' || nsp.nspname || '.' || clz.relname AS name, clz.oid
   FROM pg_class clz JOIN pg_namespace nsp ON clz.relnamespace = nsp.oid
   WHERE clz.relkind = 'r'
)

SELECT
l.pid   -- process identifier
-- locking information
, l.mode
  || CASE WHEN l.granted THEN ' GRANTED'
          ELSE ' WAITING'
     END
  || ' on ' ||
  CASE WHEN l.locktype = 'relation'
            THEN (SELECT name
                  FROM full_table_name
                  WHERE oid = l.relation )
       WHEN l.locktype = 'tuple'                THEN    ' row '
       WHEN l.locktype = 'transactionid'
            THEN        ' transaction ' || l.transactionid
       WHEN l.locktype = 'virtualxid'
            THEN    ' virtual transaction ' || l.virtualtransaction
       ELSE l.locktype
  END
  AS locking_summary

-- current query launched from the user
, a.current_query AS user_query
-- username and some other details about the query
, a.usename || ' started on ' || a.query_start || CASE WHEN a.waiting
THEN ' (waiting) '
                                                       ELSE ' (running) '
                                                  END
  AS by

FROM pg_locks l LEFT JOIN pg_stat_activity a ON l.pid = a.procpid
WHERE l.pid <> pg_backend_pid() -- do not show myself

Calendario dell'Avvento ITPUG: 5 Dicembre

psql si presenta come una shell verso PostgreSQL. E come tutte le shell che si rispettino, anche psqlpermette all'utente di modificare il proprio prompt, adattandolo alle proprie esigenze.
L'analogia con le shell (csh, zsh, bash) è quanto mai obbligatoria, visto che i meccanismi sono i medesimi:

• definizione di una serie di variabili speciali che vengono espanse con dei valori prefissati (es. nome utente, nome del database, ecc.)
• interpolazione di alcune sequenze di escape (stile bash, ossia con le parentesi quadre!)
• definizione di una serie di variabili del programma psql che siusano per renderizzare il prompt

In psql il prompt viene renderizzato con due variabili:

• PROMPT1: il promp classico
• PROMPT2: il prompt delle righe di completamento comando (quando uno statement non viene completato su una sola riga)

Esiste anche un PROMPT3 che qui non mi interessa trattare.

Fatta questa premessa sul prompt di psql io sono solito modificare il comportamento standard per far assomigliare maggiormente il prompt di psql a quello delle mie shell utente. In particolare mi piace inserire l'informazione sull'utente correntemente connesso al database, il database (ovviamente), la macchina e la porta a cui sono collegato.
Questo consente rapidamente di capire a "chi" sono connesso quando tengo aperte piu' sessioni fra istanze differenti.

Il tutto si traduce come:

\set PROMPT1 '[%n@%/ %m:%>  %x %# '
 

 ossia
 

'nome_utente@database nome_host:porta_tcp #'

Abbastanza utile il marcatore %x che viene espanso in stringa vuota se non vi sono transazioni attive e in un carattere '*' se si è all'interno di un blocco di transazione.
Per il PROMPT2 (quello multiriga) solitamente opto per qualcosa di piu' corto: nome utente e database, giusto per essere sicuro di fare il COMMIT sul database giusto!

E per un po' di mal di testa, ecco una versione colorata da inserire nel proprio ~/.psqlrc:

\set PROMPT1 '%[\033[0;1;33m%][%[\033[0;1;

37m%]%n%[\033[0;1;31m%]@%[\033[0;1;37m%]%/%[\033[0;1;33m%]
%[\033[0;1;34m%]%m:%>% %[\
\033[0;1;33m%]%[\033[0;1;33m%]]%[\033[0;1;32m%] %x %# %[\033[0;1;37m%]'
\set PROMPT2 ' %n%[\033[0;1;31m%]@%[\033[0;1;37m%]%/%[\033[0;1;33m%]
%[\033[0;1;32m%] %x %# %[\033[0;1;37m%]'

Calendario dell'Avvento ITPUG: 4 Dicembre

Un altro giorno, un altro post a tema PostgreSQL.

Denis oggi ha postato un simpatico esempio sulla mailing list soci di ITPUG relativo al meteo. Già, perché grazie ai foreign data wrapper è possibile inglobare in un cluster dati veramente disparati, come quelli scaricati da un web service meteo (o da una connessione http).

L'esempio fa anche uso delle funzioni integrate di PostgreSQL per i tipi JSON.

Calendario dell'Avvento ITPUG: 3 Dicembre

psql è il mio client preferito per PostgreSQL, specialmente perché
sono un amante della command line.
Una funzione secondo me piuttosto utile di psql è il single-step mode:
se abilitato psql forza la richiesta di una conferma prima
dell'esecuzione di ogni istruzione SQL. Non è propriamente come
racchiudere il comando in una transazione, quanto piu' come eseguire
ogni istruzione in modo condizionale.
Ciò aiuta ad esempio l'esecuzione di script complessi per verificare
cosa si sta per eseguire.
Abilitare il single-step può essere fatto in due modi:
1) con il flag -s sulla linea di comando
2) con la variabile SINGLESTEP come segue
\set SINGLESTEP 'on'
(e analogamente 'off' per disabilitare la funzione)

La cosa utile del single-step è che procede alla sostituzione delle
variabili prima della richiesta della conferma. Supponiamo di avere uno script come il seguente:

CREATE TABLE foo(
       pk serial not null,
       value integer default 0,
       PRIMARY KEY(pk)
);

INSERT INTO foo(value) VALUES(1);
INSERT INTO foo(value) VALUES(2);
INSERT INTO foo(value) VALUES(3);
INSERT INTO foo(value) VALUES(:var1);

e di avviare psql, impostando il single-step e il valore della variabile var1:

# \set var1 '4'
# \set SINGLESTEP 'on'
# \i script.sql

durante l'esecuzione dello script si avrà che:

***(Single step mode: verify command)**********************

*********************
INSERT INTO foo(value) VALUES(4);
***(press return to proceed or enter x and return to cancel)********************

Quindi non solo viene richiesta conferma dell'esecuzione del comando,
ma si mostra anche il valore espanso della variabile.

Il calendario dell'Avvento ITPUG (?)

Seppur in ritardo oggi ho provato a lanciare la sfida del calendario dell'Avvento ITPUG. L'idea non è nuova, ci sono già alcune community che fanno il calendario dell'Avvento: si scrive qualcosa ogni giorno riguardo ad un progetto particolarmente interessante. Un esempio? Si veda il calendario di Catalyst.

Non so bene se la cosa riuscirà a prendere piede, ITPUG non è (ancora) pronta come infrastruttura (ad esempio il planet Italia non è denso di writers), ma penso che anche la mailing list soci possa andare bene come mezzo per la divulgazione di PostgreSQL. Perfino un social network è appropriato, l'importante è condividere link e contenuti.

Cosa scrivere? Beh, qualunque cosa sia correlata a PostgreSQL: tips and tricks, howtos, curiosità, notizie relative ad eventi, esempi di SQL virtuoso, ecc.

Quanto scrivere? Non c'è una lunghezza, da qualche riga a qualche pagina! L'importante è che l'argomento sia PostgreSQL-related.

Perché scrivere? Perché penso che sia importante condividere (anche delle banalità) su PostgreSQL, l'importante è abituarsi a condividere, e questo è un modo un po' forzato per scrivere e curiosare nei thread degli altri autori.

Quando scrivere? Ogni giorno!

Spero vivamente che la cosa abbia successo.

Ah, mi rendo anche disponibile a fare da forwarder per il planet Italia per chi non avesse un blog o non fosse ancora collegato a tale planet, ovviamente citando autore e lasciando inalterato il materiale fornito.

Un esempio di cattivo design di interfaccia utente

Mia madre possedeva una Volkswagen Scirocco 1.6 GT amaranto. Parliamo degli anni '80. Io adoravo quella macchina, con i sedili sagomati e il cruscotto sportivo.

Ma aveva un difetto di design dell'interfaccia utente che mi è venuto in mente per caso solo oggi.

Il pulsante del triangolo quattro frecce era in realtà un pulsante che si attivava solo con la leva della freccia di svolta innestata. Ovvero: per accendere le quattro frecce si doveva girare la leva di svolta e attivare il pulsante del triangolo.

Se ci si pensa è un concetto abbastanza furbo, tipico di un programma informatico: siccome esiste già un modo per attivare un lato delle luci lampeggianti, basta fare uno switch booleano che dica se si vuole attivare anche l'altro lato.

In realtà è un pessimo design: se il pulsante del triangolo resta per errore inserito gli indicatori di svolta non funzionano piu' come dovrebbero e si rischia di produrre sempre un incidente!
In informatica si traduce con una variabile inizializzata male (lo switch booleano appunto).

Stranezze di altri tempi che sono sicuro si possono trovare in programmi attuali...

Sysadmin Panics: usare rottami per server

Uno degli indiscussi vantaggi di molti software Open Source, in particolare dei sistemi operativi, è che spesso non sono ingordi di risorse hardware. Ci sono varie spiegazioni per questo: alcuni progetti vengono di fatto sviluppati su computer datati (per mancanza di fondi), altri progetti come OpenBSD si obbligano ad essere compatibili con la loro base di installato, e in generale non c'è la necessità di dover spingere sul mercato una nuova release che forzi l'utente a comprare nuovo hardware.

In breve quindi con il software Open Source anche un vecchio computer può funzionare egregiamente. Quante volte si è sentito dire che anche un datato Pentium I può fare da firewall! Io stesso ho recuperato pc vetusti con i quali poi ho fatto videoconferenze o il rendering di una stanza di casa...

Ma un conto è riciclare un vecchio computer, un conto è basare la propria filosofia di deployment su questo concetto. Sia chiaro, tutti vorrebbero risparmiare sull'hardware, ma a me sono capitati casi raccapriccianti.

Piu' volte sono stato forzato ad usare dei vecchi server HP, del peso di una lavatrice, come firewall. E concettualmente tutto funzionava: qualche scheda di rete buona, un paio di dischi SCSI, un po' di memoria, e a regime nessuno si accorgeva dell'età del server. Fino a quando non c'era un problema e il server andava reboottato: improvvisamente tutti gli utenti si accorgevano di quesi 3 minuti spesi nel controllo POST del BIOS e dal minuto necessario al controller SCSI per essere sicuro di aver enumerato tutti i dischi!

Ancora peggio: una volta mi venne chiesto di usare un firewall già riciclato come server per una installazione satellite. Ricordo un solo computer che alla pressione del comando ls faceva passare un secondo prima di mostrare il risultato, ed era l'8088 di mio nonno. Ebbene il server di cui sopra faceva passare due secondi. Ma non era costato nulla!

Nei casi di cui sopra, piccoli esempi in fondo, si parla comunque di hardware buono, e quindi adatto a lavorare in un deployment classico (computer sempre acceso, dischi continuamente in utilizzo, alimentatori ridondati, ecc.). Ma quando si passa a voler usare un EEE PC come server solo perché sopra ci si può installare Linux e un qualche database relazionale....beh forse è il caso che si riprogetti il tutto.

Il solo fatto che hardware vetusto, o hardware compatto, possa svolgere allo scopo non significa che debba. Le velocità dei dischi contanto, e la risposta del database può far infuriare i vostri utenti, arrivando a vanificare il risparmio ottenuto. L'hardware conta: il buon hardware costa, ma spesso ripaga.

L'hardware vetusto trova ancora spazio, se in buone condizioni e con la giusta ridondanza. L'hardware compatto va bene per gli esperimenti e le postazioni di emergenza.

 

FreeBSD and Whatsapp

La FreeBSD Foundation ha ricevuto una grande donazione dal CEO di Whatsapp. Fa molto piacere vedere che le aziende stiano riconoscendo, sempre piu', il valore ai grandi progetti Open Source che hanno permesso il loro business.
E il mio personale invito è anche quello di valutare altri progetti, forse piu' detro le quinte, ma che movimentano molti piu' dati come OpenBSD (mai fatto un login ssh?).

cron > /dev/spam

Penso sia capitato piu' o meno a tutti i sysadmin di qualunque razza, età e professionalità di crearsi uno o piu' programmi o script per il monitoring di una qualche risorsa specifica. Non importa quale sistema di monitoring si usi, prima o poi occorre qualche riga di codice Perl o Shell per tenere sotto controllo una risorsa, il classico quick and dirty.

E siccome i sysadmin sono anche pigri, meglio dotare il proprio script di un alert via e-mail quando qualcosa va male.

E per essere proprio sicuri che il disastro non passi inosservato si manderà tale alert a piu' persone, in modo che anche in caso di assenza qualcuno possa dominare la situazione.

Fin qui tutto regolare, nulla di sconvolgente.

Se non fosse che ci sono sysadmin che semplicemente ignorano gli alert inviati da cron (e per esperienza sono gli stessi che fanno un update senza leggere le release notes!). Diversi anni fa ne ho conosciuta una tipologia che non solo ignorava gli alert, ma li classificava anche come spam!

Come ci si accorge di un simile atteggiamento? Ebbene io diversi anni me ne accorsi perché, durante una giornata di ferie, ricevetti una telefonata che mi informava che il servizio di posta si rifiutava di inviare nuove e-mail. Apparentemente un problema al demone stesso, o questo è quello che si pensa subito, fino a quando non ci si collega e si trova nella propria inbox qualche pagina come segue:

In breve il server di posta aveva, in un certo senso, fatto il suo dovere collassando sotto l'enorme mole di e-mail inviate da uno script che ogni minuto controllava una risorsa non disponibile inviando poi una mail di lamentela.

E ovviamente, nessuno prima si era accorto del fattaccio perché le e-mail veniva scartate a priori....

Quindi meglio essere sicuri che le e-mail siano trattate per quello che sono: delle risorse che vanno anch'esse controllato (manualmente). E meglio anche evitare che ogni minuto uno script fatto a mano si incazzi!

Richard Stallman a Modena

Richard Stallman non ha certo bisogno di presentazioni.

Ne è convinta anche l'Università di Modena, presso la quale il prossimo 24 Novembre, Stallman terrà un discrso sulla libertà digitale.

Resto un po' deluso dal vedere come l'incontro di Stallman sia riportato da una misera nota sul portale universitario, con anche evidenti errori di battitura. Fra le altre cose, nemmeno un link all'evento ufficiale della FSF, che richiede anche una registrazione anonima (cosa non richiesta dal sito dell'università)...

PGDay.IT 2014

Il PGDay.IT 2014 si è concluso, ormai da circa due settimane.

E' stato un PGDay.IT per me anomalo, soprattutto per il fatto che non vi ho partecipato. Problemi personali purtroppo gravi mi hanno infatti tenuto lontano dall'associazione ITPUG, e quindi dalla organizzazione dell'evento nonché dall'evento stesso. Dalla comparsa del PGDay.IT (nel 2007) non avevo mai saltato una singola edizione, nonché ero stato coinvolto in ogni organizzazione.

Sono comunque molto contento di come ITPUG, il consiglio direttivo e i volontari coinvolti nell'organizzazione, abbiano affrontato l'evento, aggiungendo all'edizione del 2013 una nuova edizione di successo.

I dati dell'evento sono piu' che incoraggianti: ulteriore record di partecipanti, con la quota che supera di slancio le 120 persone! Due sessioni, come nella migliore tradizione del PGDay.IT, e ancora un ITPUG Lab di successo. L'ITPUG Lab, come per la prima edizione del 2013, resta la vera innovazione del PGDay.IT: una sessione in stile open-space dove i partecipanti sono liberi di provare, consultarsi e fare aggregazione per risolvere problemi e situazioni da loro stessi proposti.

Ma il PGDay.IT non finisce con i talk e le sessioni interattive, e gli eventi sociali permettono ai partecipanti di continuare a fare aggregazione.

Con un pizzico di presunzione devo ammettere di essere molto orgoglioso dei risultati ottenuti da ITPUG in questo mandato; certo ci sono stati dei problemi e delle difficoltà, e altre ce ne sono anche ora, ma l'associazione si è ben ripresa da una situazione di stagnazione e si prepara ad affrontare piu' sana che mai un nuovo anno solare. A riprova di ciò l'aumento costante di soci che si è ottenuto nel tempo, indice che la direzione intrapresa è quella buona.

Un ringraziamento di cuore a tutti i volontari e chi si adopera per la buona riuscita dell'associazione. Nella speranza che anche la comunità internazionale, un po' silenziosa riguardo questo evento così importante (basti pensare che dal PGDay.IT nacque il primo PGDay europeo) possa rendere giustizia agli sforzi fatti in questi anni.

Moglie

Ricordo quella sera come fosse ieri.

Ero sul lettone con mio padre, guardavamo la televisione. Un film che alcuni describerebbero come cult, ma che già allora era trash.

Non ricordo l'anno, penso fosse il 1987, comunque avevo 10 anni o poco meno.

Dopo uno spezzone di quel film mio padre mi disse che senza mia madre non sarebbe mai riuscito a superare i suoi problemi agli occhi. 

Una frase che all'epoca sicuramente faticai a capire, nonostante avessi vissuto bene la sofferenza dei molteplici interventi ai quali si era sottoposto.

E' da diversi giorni ormai che anche io sto passando dei guai con gli occhi, e ammetto in tutta onestà di capire solo ora quella frase. 

Dopo aver visto mia moglie in azione.

Dopo aver compreso che senza di lei sarebbe stata molto dura, forse anche impossibile. O forse sarebbe stata possibile, ma avrei gettato la spugna.

Francamente io sarei una pessima moglie, non avrei saputo fare meglio di quanto non stia facendo la mia.

Mosche Volanti

Cara Carmensita,
solitamente non scrivo mai di cose personali, cerco di essere riservato e temo strumentalizzazioni. E poi lamentarmi non mi piace: temo sempre di essere inopportuno.
Ma sono ormai alcuni centimetri di barba che ho dei pensieri. 

Non hanno un filo logico, non saprei almeno spiegare qual'è il legame che li accomuna e li presenta con insistenza. 

Cerco allora di scriverteli, consapevole che non li sto affatto esorcizzando.

Sovrasemplificando posso dire che i pensieri si dividono in positivi e negativi.

I pensieri negativi si comportano un po' come le "mosche volanti" che galleggiano nel mio vitreo sporco: non ti fanno vedere la vita in bianco e nero, ma sono abbastanza fastidiosi da costringerti a girare lo sguardo anche quando stai guardando una cosa bella. E come le mie mosche volanti, non sai mai da che direzione o quando si presenteranno, né per quanto tempo. 

Forse questo è uno degli aspetti piu' affascinanti della mente umana.

Chissà magari con il passare del tempo questi pensieri si adageranno sul fondo, un po' come le mie mosche volanti, e avrò nuovamente la visione "sgombra".

Di certo oggi questi pensieri negativi ci sono, e mi rendono quasi insensibile (ma non irriconosciente) perfino davanti a dei bei regali, non importa di che portata siano, fossero anche grandi come una casa.

Il lato negativo dei pensieri negativi è che si rafforzano, negativamente.

Credo sia una caratteristica umana: è piu' facile pensare negativo quando le circostanze sono negative.
Circostanza: quello che sta attorno. Troppo spesso ci si dimentica che dove si sta è piu' importante di cosa ci sta attorno.

Il lato positivo dei pensieri negativi è che ti spingono a riflettere.
Ad esempio su giustizia e Dio.
Perche' proprio su questi due? Forse perché quando le circostanze sono negative ci sembra che entrambi questi concetti siano accomunati da una egual assenza.

Riguardo la giustizia ti dirò, forse non è vero che è assente, forse sono solo io che non sempre riesco a capirla. Sicuramente io non sono in grado di giudicarla, perché credimi che se fossi io a decidere sulla giustizia il mondo sarebbe molto piu' ingiusto di come è adesso. E non lo dico perché sono rancoroso o arrabbiato, è che un po' tutti ci sentiamo sempre parte lesa e riteniamo di essere in grado di poter essere equi, ma in fondo forse non lo saremo mai.
E' un altro degli aspetti della natura umana: l'erba del vicino è sempre piu' verde.

Riguardo Dio, beh non abbiamo mai parlato di Dio.

Solitamente quando le circostanza sono avverse la fede tende a vacillare; la mia no e probabilmente perché non sono un gran esempio di fedele. Credo che Dio esista, credo ne esista solo uno visto che così mi è stato insegnato, e non sento l'esigenza di cercarne altri.
Anzi, proprio nelle circostanze avverse so che esiste: lo sento mentre preme il suo pugno sul mio stomaco.

Ti scrivevo che la mia fede non vacilla, anche se forse sarebbe piu' corretto dire che le mie abitudini non vacillano. Eh si, perché non ho certo intenzione di pregare di piu' o di cambiare le mie rare manifestazioni religiose. E non per lanciare una sfida, ma perché se mi si vuole piagnucolante allora non si merita venerazione.

E allo stesso tempo non varierò il numero di candeline accese con mio figlio.

Mi diletto di programmazione. Non sono un programmatore famoso, non certo uno che cambierà il mondo con i suoi programmi.
Io curo le anomalie dei software, chiamate in gergo bug.

• Alcune forme di bug possono essere risolte semplicemente con un cambio di contesto.
  
  
• Alcune forme di bug richiedono un piccolo intervento chirurgico.
  
  
• Alcune forme di bug richiedono un intervento complesso e lungo, con arresto e fermo del sistema per diverso tempo.
  
  
• Alcune forme di bug non si manifesteranno mai.
  
  
• Alcune forme di bug produranno la morte accidentale del sistema in tempi brevi.
  
  
• Alcune forme di bug non faranno in tempo a manifestarsi perché il sistema sarà sostituito prima.
  
  
• Alcune forme di bug non veranno curate perché il sistema è troppo obsoleto.
  
  
• Alcune forme di bug (de)genereranno in altre forme.
  
  
• Ogni volta che si manifesta un bug occorre fare opportuni accertamenti e programmare gli interventi necessari, nonché ripetere una fase di esami funzionali per assicurarsi che il problema sia risolto.
  
  
• La cura di un bug puo' scatenare altri effetti collaterali, anche altre forme di bug.
  

Sostiuisci alla parola "bug" la parola "cancro" e rileggi.

Cancro è una parola che ha diversi significati, e che produce sensazioni differenti in chi la legge o pronuncia. E anche questa è una delle cose affascinanti della mente umana.

Se usata per indicare il segno zodiacale, ad esempio di un figlio, penso generi pensieri positivi. 

Se usata per indicare una malattia, genera sicuramente pensieri negativi.

Il cancro (la malattia) è una delle cose piu' vigliacche che la natura potesse inventare. E' una cosa che rende anche me vigliacco, perché cerco di non parlarne nella speranza che non mi noti.

Il cancro è una cosa che non auguro nemmeno al mio peggior nemico, ma ad essere sincero non mi sconvolgerebbe se capitasse a qui pochi che han cercato di minare la mia famiglia. 

Come ti scrivevo, forse è meglio che non sia io a decidere cosa sia giusto e cosa no!

Una persona molto influente mi disse che il tempo è l'unica cosa veramente democratica, perché passa per tutti in ugual misura. Ho sempre pensato fosse vero, ma scontrandomi con una malattia del genere capisco che è un ragionamento sbagliato. 

Sbagliato è quello che si sta misurando: non importa che la velocità sia la stessa, la distanza è ciò che conta, e quindi se il tempo passa uguale per tutti, la quantità accumulata fa la differenza, anche se mitigata dalla qualità. 

E forse in questo ragionamento ci sta che le malattie siano abbastanza giuste nel non giudicare chi colpiscono, anche se la vera giustizia pare essere una frase da velina: "non avere malattie nel mondo".

Nella parola "cancro" è contenuta anche la parola "arco", e pensavo a quando mi dilettavo in questo sport. 

Sono stato un buon arciere, non uno famoso, ma me la cavavo. 

Ho avuto un grande fan che mi spingeva a fare le gare anche quando non mi sentivo pronto, quando la mia "forma" non era al top. Eh si perché se gareggi solo quando sai di vincere allora sei un vigliacco. Ed ecco perché ritengo che il cancro sia una manifestazione di vigliaccheria: se ne sta nell'ombra, a prepararsi, ad allenarsi, per mostrarsi solo quando si sente pronto ad affrontarti.

L'arco è stato uno sport molto importante per me. La sua individualità mi ha insegnato a contare sulle mie forze, e adesso che non lo pratico piu' forse mi sento meno forte. 

Se non fosse stato per l'arco non avrei nemmeno preso in considerazioen di sposare mia moglie.

Ti scrivevo a proposito del mio grande fan.
Il fan è una persona che ti sostiene in molte delle scelte che fai, se non in tutte. Non importa quale sport tu voglia praticare, perché incidentalmente è anche il preferito del tuo fan. Nel mio caso, fu' l'arco.
Il fan è quella persona che rimette a posto il frigo portatile dopo che lo hai preso a calci per una voléé sbagliata, come pure è quello che si alza presto per portarti ad un raduno le aste nuove da provare. E' anche la persona che, alla tua prima gara, va a recuperare le frecce buttate fuori mentre tu sei troppo impegnato a piangere.

Alla tua gara successiva troverà il modo di aggiustarti gli occhiali, ben contento di come questo significherà guidare fino in Sicilia per una nuova competizione.

Il fan è spesso incompreso: agli occhi delle altre persone risulta quasi ridicolo per la passione che ha. Alcune persone addirittura vedono nei fan la causa dei tuoi insuccessi, ma io non ho mai dato credito a queste teorie.

Inutile dirlo, al fan non importa quante delle oltre 144 frecce tu sbagli, perché ha siglato un accordo segreto in due articoli:

1. guarderai con il cannocchiale ogni freccia, eventualmente segnandola come un vero giocatore di briscola;
   
2. il tuo atleta è il migliore che esista sempre e comunque.
   

Con questo non voglio dire che ogni fan sia con il paraocchi e non oggettivo, anzi devo ammettere che il mio piu' grande fan è sempre stato oggettivo nei miei confronti. Anche se la componente soggettiva è quella che mi piaceva di piu'.

Ora il mio piu' grande fan è malato.

La sua malattia è il mio segno zodiacale, che strana coincidenza. 

Per uno come me, che cerca sempre di trovare il legame negli avvenimenti, è un po' quello che mi merito.
Sai, ho dato il primo bacio a mia moglie il giorno 3, ci siamo sposati il giorno 4, fidanzati il giorno 5, e un altro lieto evento il giorno 6. Insomma, ho reso l'idea.
Chissà, forse questa attitudine mentale mi deriva proprio da quando, agli albori della mia carriera arcieristica, il mio piu' grande fan aveva elaborato uno strano collegamento fra le mie performance e quelle di Tomba, il suo secondo atleta preferito.

Ricordo di aver pensato in piu' di una occasione quanto fosse facile la vita del fan: sempre dietro la linea di tiro a guardare, mentre in pedana con le gambe tremolanti e il cuore in gola c'ero io.

Ora che dietro alla linea di tiro devo starci io ti dirò che è molto dura.

E così questi sono piu' o meno le mie mosche volanti, che continuano ad infastidirmi nel breve periodo, anche se paradossalmente quello che mi interessa ora è il lungo periodo.

OpenWebMail ?

OpenWebMail e' una piattaforma di email web.

Non e' particolare, ce ne sono tante come OpenWebMail. Non dispone di un calendario e di nessuno strumento evoluto per essere classificata come una vera applicazione PIM (Personal Information Management), e' una semplice e funzionale applicazione di posta elettronica.

Perche' allora parlare di OpenWebMail?

In passato sono stato costretto ad utilizzare questa interfaccia come client di posta per un'azienda. Ebbene, seppur di semplice e intuitivo utilizzo, OpenWebMail non viene piu' sviluppato attivamente da diverso tempo.

Eppure ci sono ancora aziende che utilizzano OpenWebMail come unico client di posta per i loro dipendenti, e quel che e' peggio, ci sono anche fornitori di servizi che forniscono installazioni di OpenWebMail beta in produzione!

Towards a sigil style

It happens more day by day that I find myself writing or maintaning programs and scripts written in different languages, mixed and interpolated together.

This lead me to appreciate every day more those languages that apply a "sigil" style, where each variable is identified thru a special character (a sigil), such as for instance $var or @array.

The technical reason for having a sigil is often that the parser is simpler, since it is helped by the developer in understanding what looks like a variable and what looks like a bareword or a function. But the final result, at least for me, is that it is much simpler to read a sigil-based language than another one. I cannot explain exactly why and how, but it turns out that looking at a piece code that contains sigils prompt me in the right mood at the right line. Let's say for now that it is just a metter of seeing a sigil that pops up my attention and make me think what the symbol at the cursor is depending on its sigil.

And, it is worth saying, I appreciate the most those languages like Perl where different sigils are used to indicate different things (even if you will end using the scalar $ the most).

Atom vs Emacs

Atom.io e' un nuovo editor di testo, in fase di sviluppo.

E' promettente: un editor totalmente personalizzabile da parte degli utenti che possono scrivere facilmente moduli ed estensioni per cambiarne il comportamento e l'aspetto.

Ok, ricorda qualcosa....se non fosse per il "semplicemente" direi che e' esattamente identico ad Emacs. Eccetto che Emacs puo' essere ancora piu' semplice!

A parte le battute dovute piu' che altro alla religione degli editor, Atom appare veramente un clone moderno di Emacs.

Non solo Emacs e' di fatto l'unico vero editor totalmente personalizzabile che io abbia mai visto e usato, ma alcune delle feature di Atom sono identiche a quelle di Emacs.

Ad esempio, il modulo  Zen fa esattamente quello che il mio Emacs fa con poche righe di codice lisp, e soprattutto senza dover installare una estensione.

La possibilita' di avere i suggerimenti sui nomi dei file da editare e' esattamente quello che fa il mio Emacs con IDO.

Sort Lines  fa esattamente quello che il comando sort fa, solo che Emacs permette di eseguire gia' tutti i comandi disponibili su un buffer o una regione, e quindi risulta ancora una volta vincente.

E come per Emacs, le estensioni si sprecano e portano fino ad esempi inutili come Editor Stats  (francamente mi interessa sapere di piu' cosa sto editando che sapere 'quanto').

Insomma, a parte per la tecnologia utilizzata e per il fatto che la struttura di Atom mi appare maggiormente a "micro-kernel", direi che di differenze significative con Emacs non ce ne sono.

E questa mi sembra una bella vittoria per Emacs, precursore di molte idee riprese poi negli IDE e negli ambienti moderni.

Non mi e' ancora chiaro se Atom potra' funzionare anche in console e quindi via terminale remoto, cosa che Emacs svolge egregiamente (anzi, Emacs puo' lavorare in modalita' client-server e anche come wrapper di terminale).

Ma sicuramente una cosa e' chiara: Emacs ha una licenza piu' conveniente che quella di Atom.

PostgreSQL 9.4: decodifica dei WAL e replication slot

Ricordo che al PGDay.IT del 2012 il keynote (Simon Riggs) parlava di una feature che sarebbe stata introdotta in PostgreSQL riguardo la decodifica dei WAL in formato logico, ossia umanamente leggibile (istruzioni SQL o qualcosa di simile). Era stato detto che ci sarebbe voluto diverso tempo per implementare tutti i pezzi di questa conversione da binario a testuale, ma che era un passo fondamentale per la crescita di PostgreSQL.

Ebbene nella nuova versione, la 9.4, alla quale gli sviluppatori stanno lavorando, e' stata introdotta una patch che permette di convertire i WAL in formato testuale.

Qui si trova un primo esempio, piuttosto impressionante , della funzionalita' di decodifica dei WAL.

Da notare che l'esempio sopra riportato cita anche i "replication slots", un'altra feature aggiunta per l'imminente 9.4. L'idea e' semplice ed elegante: mentre prima il master non aveva alcuna conoscenza dello stato di replica degli slave, che quindi potevano andare off-line per molto tempo e rimanere "troppo indietro" rispetto al master, dalla 9.4 il master terra' lo stato di replicazione di ogni slave agganciato (uno slot appunto). Questo permettera' al master di conservare tutti e soli i WAL richiesti dagli slave, anche se non disponibili per molto tempo, senza costringere il DBA a indovinare quanti WAL mantenere (keep segmentes) o l'implementazione di un continuos archiving.

La 9.4 promette molte altre feature, ma quelle di cui sopra in fatto di replica sono sicuramente molto significative.

On bug and bug reporting

A quite well established mindset with Open Source projects is that as much users a code base has, as much it will be tested and, therefore, will produce a continuosly growing quality product.

And it is true, indeed!

But what does it mean to test an Open Source project? Disregarding the low level testing with test suites, it means that true users will install, run and report back application misbehaviors, crashes, problems, and so on. And this is the point of this post: reporting back information to developers so that they could do their work and improve the software. I'm not focusing on how to write a good bug report, you can find a lot of information about in the net and in the project documentation itself. But have you ever thought about the importance to report as less information as possible to allow a developer to do her job? I mean: what do you think a developer will feel like opening the bug tracking system on the Monday morning and finding out tons of bug reports? Therefore, before posting a bug report, please ensure that none before you has openend the same report, and in case append to such report. You will achieve the goal of making the developer feel better and, most notably, to avoid wasting her time in reading just another report that reports the already known problem.

And if you have time, please provide a clear and short way to reproduce the bug, even if you are not the first reporter. Even better, write an automated test for the bug you are interested in: you will grant the developer some extra time to concentrate on the real bug instead of the aside artifacts.

And about testing allow me to spend some extra words: while it is very important to test the produced code, please consider that techniques such as Test Driven Development TDD not only promote the creation of tests ahead the code that implements a feature, but also that a feature should be requested due to a failed test.

In other word, if you want to add feature X to the project Y provide a short and clear test along with the feature request.

Why?

Because again, you are going to give the developer(s) some extra time and will help her better understanding what is your will. And most notably, while writing the test you will become a concrete part of the development and will better think about what you are asking (and why you are needing it). In other words: you will only ask something you can clearly explain and with as less as possible misunderstandings, while the developer(s) will have a concrete case to start developing on.

Fianlly, again on testing, please spend some time reviewing and providing new test cases for existing code, even if you don't have a feature request or a bug to work on.

Why?

Because Open Source developers often, or better almost always, do the hard work on their spare time, and will regret to implement some new code until they do not risk public embarassment. Therefore, if the code base has a strong and reliable test case, developers will be more likely to implement more code without having to worry about awkaward bugs.