Feeds

FeedRSSLast fetchedNext fetched after
2ndQuadrant XML 00:01, martedì, 25 luglio 01:01, martedì, 25 luglio
:: Luca Ferrari :: XML 00:01, martedì, 25 luglio 01:01, martedì, 25 luglio
Il blog di Enrico Pirozzi - Postgresql XML 00:01, martedì, 25 luglio 01:01, martedì, 25 luglio
Planet PostgreSQL – Denis Gasparin XML 00:01, martedì, 25 luglio 01:01, martedì, 25 luglio
PostgreSQL – Blog di Diego Cinelli XML 00:01, martedì, 25 luglio 01:01, martedì, 25 luglio

venerdì, 07 luglio

16:51

pgloader e gli URL (compresi quelli di MySQL!) [:: Luca Ferrari ::]

Un interessante articolo sull'ultima versione disponibile di pgloader.
Noto con piacere che lo script permette di collegarsi autonomamente ad un database differente, es. MySQL, e migrarne il contenuto verso un database PostgreSQL. Ancora meglio, pgloader è in grado di riconoscere e interpretare gli URL che gli vengono forniti scaricando file tramite altri protocolli, come HTTP, per poi leggerli e dump-arli verso una istanza PostgreSQL.

martedì, 27 giugno

16:43

PgAdmin III è ancora vivo! [:: Luca Ferrari ::]

PgAdmin è sempre stato il tool di riferimento per l'amministrazione di un cluster PostgreSQL mediante interfaccia grafica.
Onestamente non ho mai usato molto tale applicativo, se non quando ero alle prime armi e faticavo a districarmi sulla linea comando di psql,
ma questo non significa che il tool non sia valido, anzi è uno dei piu' completi che abbia mai visto.


La versione forse piu' nota di PgAdmin è la 3, e infatti spesso si trova il nome PgAdminIII. L'interfaccia grafica era spartana ma funzionale, le wxWidgets facevano il loro scopo e rendevano l'applicazione portabile, ma l'eleganza ne soffriva abbastanza.
L'anno scorso è stata rilasciata la versione stabile di PgAdmin 4, completamente riscritto in Python e basato su interfaccia web.
Ciò ha rappresentato una discontinuità nel mantenimento della versione 3, basata su altra tecnologia.


Mi ha fatto piacere scoprire che esiste un fork di PgAdminIII mirato a mantenere il codice attivo e funzionante per ancora qualche versione di PostgreSQL. In effetti, mea culpa, ammetto che l'installazione di PgAdmin 4 non mi risulta mai molto semplice, sicuramente per la mia mancanza di conoscenza Python (nemmeno la wheel sembra funzionare sul mio povero computer!).


Lunga vita a PgAdmin (III o IV)!

domenica, 25 giugno

14:40

Riflessioni su pl/java [:: Luca Ferrari ::]

Bruce Momjian ha pubblicato un breve articolo circa l'adozione di pl/Java.
I linguaggi pl/ sono una serie di bindings per utilizzare un linguaggio di programmazione differente dal "plain" SQL all'interno di una istanza PostgreSQL, ovvero lato server.
Pertanto pl/java altro non è che un binding per poter utilizzare il linguaggio Java direttamente all'interno del server PostgreSQL, ad esempio per la costruzione di trigger o stored procedures. Io stesso ho utilizzato in passato pl/java in produzione, e ho anche tenuto dei mini corsi e dei seminari sul suo utilizzo (si veda ad esempio qui), nonché ho provato a contribuire a minime porzioni di codice.


Pl/Java risulta abbastanza ostico rispetto ad altri linguaggi pl/, e ciò è dovuto alla natura di Java (non certo ai suoi limiti), in particolare alla fase di compilazione che richiede sempre:

  • un deploy di una forza compilata del codice;
  • un pezzo di codice collante SQL che possa "iniettare" le funzionalità Java dentro al server PostgreSQL.

Pl/Java si basa per scelta progettuale su Java Native Interface (JNI), scelta abbastanza efficiente se si considera che il codice deployato risulta locale al server cluster e quindi non è necessario utilizzare chiamate remote (es. RMI). In modo coerente con le scelte architetturali di PostgreSQL, pl/java utilizza una virtual machine backend per ogni processo attivo, richiedendo quindi dei tempi di startup piuttosto lunghi (o diciamo piu' lunghi rispetto ad altri pl/).


L'implementazione di pl/java è elegante e interessante, permette la sincronizzazione dei thread su un mutex singolo e consente di interagire con gli oggetti di backend arrivando perfino a implementare una sorta di SQL MED del poveraccio.


Eppure pl/java non sfonda, come nota appunto Bruce nel suo articolo.


Avendolo usato in produzione posso affermare che pl/java è fortemente condizionato dalla competizione con altri linguaggi pl, in particolare quelli di scripting. Effettivamente io stesso, ad un certo punto, ho modificato porzioni di codice abbastanza sostanziose per passare da pl/java a pl/perl. Ovviamente ciò è stato possibile perché potevo scrivere codice in entrambi i linguaggi, competenza non sempre presente, e l'esigenza principale è stata quella di dover garantire una modifica on-the-fly al codice sorgente anche quando non fosse disponibile un ambiente di sviluppo completo. Detto in due parole: per usare pl/java occorre impostare un progetto (Eclipse o similare), compilare, deployare e "iniettare" il codice nel backend, in pl/perl basta un editor di testo per modificare il codice e la fase di deploy si riduce ad iniettare il codice nel backend.


Personalmente ritengo che pl/java sia uno strumento interessante e importante, e che la sua adozione in contesti fortemente Java-based (per competenze, librerie, stack) sia opportuna, ma solo da un punto di vista degli sviluppatori. Difficilmente un DBA utilizzerà pl/java per implementare le proprie logiche di controlle server-side.

sabato, 24 giugno

22:42

Ulteriori considerazioni sul planet PostgreSQL italiano [:: Luca Ferrari ::]

Qualche mese fa avevo espresso brevemente alcune considerazioni sul futuro dell'aggregatore di blog dell'associazione ITPUG, ovvero il Planet PostgreSQL Italiano.
La mia preoccupazione era dovuta al fatto che nei primi mesi dell'anno corrente non vi erano stati post relativi all'associazione e al mondo PostgreSQL in generale, e infatti facevo notare come solo io avessi pubblicato 13 post fra Gennaio e Aprile.


Ad oggi, giro di boa della metà anno, la situazione non è migliorata, e ancora una volta pare che il planet sia utilizzato solo per aggregare i miei post:



Ancora una volta sento la necessità di sollecitare l'associazione e il consiglio a valutare l'utilizzo di questo strumento di aggregazione e informazione, che risulta ormai evidentemente abbandonato a se stesso e in rapido declino di contenuti (a differenza del sempre aggiornato Planet PostgreSQL.

domenica, 11 giugno

08:54

Perl blogs will be powered by PostgreSQL [:: Luca Ferrari ::]

There is a grant request aiming at revamping blogs.perl.org.
I have to admit that blogs.perl.org is in a bad shape, and in fact I do not use it anymore for my personal contents since the well known
login issues.
Well, the important part about the grant request, at least with regard to the PostgreSQL community, is that…surpise! The new platform will store content on a PostgreSQL backend:

[…]
will be written on top of Dancer2,
DBIx::Class, and DBI,
with a PostgreSQL database
imported from the existing
[…]


A great news for two of my favourite Open Source projects (Perl and PostgreSQL) and a great wat to spread the word thru our own content!

sabato, 20 maggio

19:48

PostgreSQL abbandonerà il supporto al download FTP [:: Luca Ferrari ::]

Dal giorno 15 Agosto 2017 non sarà piu' possibile scaricare PostgreSQL tramite FTP!
Come spiegato nella mailing list pgsql-announce, visto il basso traffico
del protocollo FTP, nonché la vetustà del protocollo e dei relativi programmi,
il team che mantiene l'infrastruttura ha deciso di spegnere l'accesso FTP.
Questo non dovrebbe risultare in un particolare disservizio per gli utenti finali, quanto
forse solo per alcune applicazioni e script automatici.

venerdì, 19 maggio

19:47

PostgreSQL 10 beta 1! [:: Luca Ferrari ::]

Ci siamo!
PostgreSQL 10 fa finalmente capolino nel mondo con il rilascio, ieri, della prima beta release.
Il download comprende pacchetti binari per le maggiori distribuzioni, oltre ovviamente alla possibilità
di compilare i sorgenti, anch'essi scaricabili come archivi.

lunedì, 08 maggio

21:16

API Java per la replicazione PostgreSQL [:: Luca Ferrari ::]

Con l'avvento della versione 42 del driver JDBC per utilizzo di applicativi Java su database PostgreSQL è stato fornito
il supporto alla replicazione.
E' stata creata una API apposita per la gestione della replicazione, il cui punto di ingresso è getReplicationAPI() sull'oggetto PGConnection, come
descritto nella documentazione:


The entire replication API is grouped
in org.postgresql.replication.PGReplicationConnection
and is available via org.postgresql.PGConnection#getReplicationAPI.

Questa feature permette di controllare e gestire la replicazione anche da applicativi esterni (Java).
Ahimé il corrispondente driver Perl (DBD::Pg) non supporta la gestione della replication, nonostante
l'infrastruttura DBI consenta una gestione generalizzata della replica. Anche il framework
DBIx non mi pare offra una soluzione, seppur esista un "minimale" supporto
alla replica logica a livello di tabella. La cosa strana è che Bucardo è un sistema di replica implementato in Perl!

sabato, 06 maggio

18:14

Toolchain e qualità PostgreSQL [:: Luca Ferrari ::]

Ho trovato una presentazione interessante sul mantenimento del code base di PostgreSQL, che come è ben noto,
ha una dimensione piuttosto estesa e una qualità del codice elevata.
La presentazione, non particolarmente dettagliata nelle sue slide (e quindi di facile lettura),
percorre ed elenca i principali strumenti e termini usati all'interno del progetto, dalle notizie e le mailing list,
al metodo di invio di una patch e alla relativa revisione e test automatico del codice.
Ritengo sia sempre utile valutare quali strumenti i grossi progetti utilizzano e il workflow, anche di alto livello,
che adottano.

venerdì, 05 maggio

18:13

Ancoa sul "caso" PostgreSQL e Uber... [:: Luca Ferrari ::]

Chi si ricorda il caso di Uber che, dopo attenta valutazione decise di passare a MySQL e abbandonare PostgreSQL?
I commenti sulla vicenda si sono sprecati, e la community PostgreSQL ha da subito mostrato
un approccio costruttivo alla vicenda sezionando e spiegando in dettaglio
come le limitazioni presentate da Uber erano in realtà scelte progettuali e/o
ostacoli superabili con estensioni (si veda per esempio il post di Simon Riggs).


Ora Christophe Pettus ha prodotto una presentazione molto interessante e dettagliata
che riassume quanto affermato da Uber e come questo, seppur vero in teoria, non sia mai stato documentato opportunamente e,
soprattutto, non sia mai stato valutato adeguatamente.
Non voglio difendere PostgreSQL a spada tratta, penso che una compagnia come Uber abbia sicuramente
personale qualificato per prendere la decisione migliore, anche se come spiegato nella presentazione
di cui sopra spesso si è fatta confusione confrontando cose differenti negli stessi ambiti (ad esempio
la replica, comparando la logical replication con la streaming replication).

venerdì, 14 aprile

15:55

Dimensioni delle tabelle e dei dati dump di testo, qualche insignificante esperimento [:: Luca Ferrari ::]

Mi sono ritrovato per le mani una vecchia e obsoleta istanza PostgreSQL 8.4 piuttosto grossa, lo spazio disco del tablespace
risultava essere di circa 13 GB! Ho quindi preso spunto per fare una piccola indagine su cosa occupasse tanto spazio,
concentrandomi solo sulle relazioni (tabelle):


SELECT c.oid,nspname AS table_schema
, relname AS TABLE_NAME
, c.reltuples AS row_estimate
, to_char( pg_total_relation_size(c.oid)::real/(1024*1024), '99G999D99' ) AS MB
FROM pg_class c LEFT JOIN pg_namespace n ON n.oid = c.relnamespace
WHERE
relkind = 'r'
AND
nspname = 'public'
ORDER BY 4 DESC, 3 ASC;

Ebbene sono saltate subito all'occhio tre tabelle in particolari (nomi di fantasia):


  oid   | table_schema | table_name | row_estimate |     mb
---------+--------------+------------+--------------+------------
63740 | public | tab1 | 8.74153e+06 | 2.248,58
66161 | public | tab2 | 2.9728e+06 | 1.192,00
65032 | public | tab3 | 2.44735e+06 | 1.280,77

Come si nota queste tre tabelle superano di slancio ciascuna una occupazione di 1 GB, arrivando fino a 9 milioni di tuple circa!
Insomma, non una cosa eccezionale per PostgreSQL, ma sicuramente nemmeno una cosa di routine, e che comunque indica forse la necessità
di una riprogettazione o di un partitioning.
Comunque, le stesse tabelle su disco quando occuperebbero in formato testo?



% pg_dump -h localhost -U luca -t tab1 testdb > tab1.sql

Effettuando il dump, con molta pazienza, di quelle tre tabelle sopra indicate si ottiene che:


% ls -lh tab?.sql
-rw-r--r-- 1 luca luca 579M 2017-04-12 11:32 tab1.sql
-rw-r--r-- 1 luca luca 494M 2017-04-12 11:37 tab2.sql
-rw-r--r-- 1 luca luca 571M 2017-04-12 11:36 tab3.sql

e quindi lo spazio occupato all'interno di PostgreSQL risulta da 2 a 4 volte superiore allo spazio disco dei dati testuali.
Chiaramente questa non rappresenta una inefficienza di PostgreSQL, quanto una naturale esigenza del database di tenere i dati allineati,
avere le pagine dati (8kB) con spazio sufficiente per consentire aggiornamenti, ecc.


Se si effettua un vacuum full sulle tabelle di cui sopra si ottiene il seguente risultato:


> vacuum full verbose tab1;
...
0 index pages have been deleted, 0 are currently reusable.

ad indicare che il database era già "buono", e abbastanza compattato. Ovviamente i dati che PostgreSQL riporta sul numero di tuple e dimensione
dei dati sono rimaste invariate.

lunedì, 10 aprile

19:49

Considerazioni sul planet italiano di PostgreSQL [:: Luca Ferrari ::]

Ho fatto caso che ormai sul planet ufficiale dell'associazione ITPUG, ovvero www.planetpostgresql.it, sto scrivendo
sporadicamente solo io. Questo secondo me è un campanello di allarme: io non sono certo migliore o piu' bravo di altri
soci e componenti dell'associazione, ma questa assenza dell'associazione dal planet indica che forse non si crede piu'
in questo strumento. Il fatto però è che nemmeno sul planet ufficiale si leggono post di ITPUG, e quindi non è tanto
la piattaforma italiana ad essere trascurata, ma il sistema di pubblicazione di notizie e articoli in generale.


Tornando al planet italiano, è facile verificare che su un periodo abbastanza ampio gli unici post
aggregati sono miei, e spesso risultano a loro volta dei link ad altre notizie ed articoli:


  1. 6 Gennaio 2017
  2. 13 Gennaio 2017
  3. 18 Gennaio 2017
  4. 27 Gennaio 2017
  5. 3 Febbraio 2017
  6. 21 Febbraio 2017
  7. 23 Febbraio 2017
  8. 24 Marzo 2017 (a) e (b)
  9. 2 Aprile 2017
  10. 5 Aprile 2017 (a) e (b)
  11. 8 Aprile 2017

Possibile che in un periodo di circa 3 mesi ITPUG non abbia avuto nessuna notizia da pubblicare?
Perfino in questi giorni, dove si richiede la regolarizzazione della quota per l'anno 2017 in vista
dell'imminente assemblea ordinaria, non vi sono notizie a riguardo.


Il consiglio che mi sento di dare al futuro consiglio è quello di prendere una decisione in merito al planet: se non lo si
vuole aggiornare allora tanto vale "spegnerlo", ma se lo si mantiene (come è tradizione anche nell'ambiente PostgreSQL e non solo)
allora lo si deve popolare periodicamente.

sabato, 08 aprile

17:24

PostgreSQL ltree [:: Luca Ferrari ::]

Da un thread su una delle mailing list ufficiali ho appreso di un tipo di dato a me sconosciuto: ltree.
Un ltree rappresenta un label tree, quello che nei linguaggi di programmazione è un meccanismo di properties. In sostanza
si definiscono delle etichette, ordinate gerarchicamente in base ad un separatore (il carattere .) e a queste si associa un valore.
Esistono poi funzioni apposite di utilità per la navigazione e la ricerca nell'albero delle etichette.


Vediamo un esempio pratico: supponiamo di voler catalogare in un albero alcune informazioni basilari riguardo la nostra associazioni
(dati assolutamente casuali e a puro scopo didattico!).


CREATE TABLE 
itpug( tipologia ltree, counter integer );

Ora si supponga di voler trovare il dettaglio dei soci, magari la loro somma partendo dalla foglia dell'albero:


SELECT sum( counter )  
FROM itpug  
WHERE tipologia @> 'itpug.soci';
sum
----
50
(1 row)


Supponiamo di voler trovare tutte le informazioni relativi al web (si noti l'uso della tilde):



SELECT *  
FROM itpug  
WHERE tipologia ~ '*.web.*';
tipologia | counter
---------------------------+---------
itpug.web.siti | 3
itpug.web.ssl.certificati | 1
(2 rows)


Insomma, ltree si presenta come estensione sicuramente interessante, anche se forse un po' sorpassata dall'uso di altri formati quali json e jsonb.

mercoledì, 05 aprile

22:28

Planet PostGIS [:: Luca Ferrari ::]

Scopeto da poco e quasi per caso: il planet.postgis.net è il planet ufficiale dell'estensione spaziale di PostgreSQL. La sua funzione è simile a quella del planet ufficiale di PostgreSQL: aggregare notizie ed esperienze da blogger di tutto il mondo relativamente al solo ambito GIS.
Non è sicuramente uno dei planet che leggerò quotidianamente, ma vale la pena tenerlo presente per avere un'idea dell'evoluzione del mondo GIS legato all'ecosistema PostgreSQL.

21:17

if-else in psql [:: Luca Ferrari ::]

Un articolo interessante che punta ad un commit di Tom Lane (e altri) per l'introduzione in psql di un costrutto if-else, ovvero \if, \elif, \else.
Mi torna subito alla mente Larry Wall in Programming Perl: soltanto un Algol-er potrebbe usare una parola chiave che è file scritto al contrario.
Ad ogni modo la modifica, che verrà introdotta con PostgreSQL 10, permette l'uso di costrutti condizionali basilari in psql. Si presti attenzione
che questi non sostituiscono i costrutti condizionali di plpgsql, ma si inseriscono direttamente nell'interprete SQL base fornito a corredo di
praticamente ogni installazione.
Sarà quindi possibile realizzare script automatici piu' complessi da dare in pasto al nostro fidato amico psql.

domenica, 02 aprile

18:15

Pipeline di una query in PostgreSQL [:: Luca Ferrari ::]

Una interessante spiegazione da parte di Tom Lane sulla pipeline di una query.
Anche se si fa riferimento all'utilizzo, non ammesso dallo standard SQL, degli alias SELECT in una clausola WHERE, la mail spiega in modo molto dettagliato come devono essere valutati
i vari passi della sintassi di una query.

venerdì, 24 marzo

19:08

Caratteri, codifiche, ordinamento [:: Luca Ferrari ::]

Un articolo molto chiaro e sintetico che aiuta a tenere a mente i concetti dietro collation, charater encoding e charset.
Consiglio vivamente la lettura.

18:30

SpeakerFight & PGDay.IT: è possibile? [:: Luca Ferrari ::]

Sono venuto a conoscenza per caso di un progetto interessante: SpeakerFight.
L'idea è abbastanza semplice, e l'implementazione mantiene la semplicità: si inviano dei contributi di talk (per conferenze ed eventi) e si lascia che le persone li votino, in un meccanismo stile "star" ben noto da altre piattaforme. I talk/contributi che hanno ricevuto il maggior numero di voti vengono selezionati per l'evento.

Un paio di giorni fa ho proposto di valutare questo meccasnimo nell'ambito del PGDay.IT. Da tempo sono sostenitore di una call-for-papers piu' aperta e con selezione maggiormente trasparente rispetto a quanto è avvenuto nelle ultime edizioni. Anzi, a dire il vero ho anche proposto piu' volte di fare un "speaker fight" del poveraccio addirittura per il keynote, proponendo di chiedere alla community chi fosse interessato a fare un keynote speech invece che andare su singolo invito diretto.

Ora sistemi come quello qui descritto hanno, ovviamente, i loro svantaggi: per esempio si potrebbe votare molto un talk tenuto da un perfetto incompetente che risulterebbe in uno speech di pessima qualità, trascurando magari talk meno "accattivanti" ma di sicuro successo ed impatto.
E forse alcune persone non vogliono selezionare di propria volontà i talk, quanto lasciare che siano gli organizzatori a "stupirli" con contenuti all'altezza di stimolare la curiosità e l'intelletto.
Tuttavia è difficile rimanere in un ambito o nell'altro se non si hanno dati alla mano circa il gradimento delle precedenti edizioni (questione che spesso ho sollevato).

Personalmente ritengo che aprire almeno una porzione del PGDay.IT ad un sistema di votazione diretta possa dare quella spinta ad autori e partecipanti per sentirsi maggiormente coinvolti e, soprattutto, per poter decidere il livello dei contenuti da visionare, garantendo quindi una maggiore partecipazione (almeno in teoria).
Se poi il tutto viene accompagnato anche da un feedback sui talk, si può avere una base dati abbastanza oggettiva che possa permettere un evento migliore ad ogni edizione.

Per sessioni interattive penso che un sistema di gradimento anticipato sia fondamentale: organizzare una sessione interattiva (es. ITPUG-Lab) non è semplice e rischia di portare via risorse (sia organizzatori che partecipanti) dalle track della conferenza. Occorre quindi essere certi del gradimento e della partecipazione alla sessione.

Insomma, una sfida interessante e uno spunto per i prossimi organizzatori dell'evento perché si possa sempre migliorare e non "sedimentare" su formule sempre uguali e ripetute.

giovedì, 23 febbraio

22:22

Quali parte sono "colpite" dalle statistiche PostgreSQL? [:: Luca Ferrari ::]

Ecco una interessante immagine che rende l'idea di quali parti del complesso e completo sistema di statistiche PostgreSQL. L'immagine mostra quali viste usare a seconda della parte di backend/stack che si vuole monitorare.
Per l'articolo originale si veda qui:


martedì, 21 febbraio

17:12

PostgreSQL @ Python [:: Luca Ferrari ::]

Il legame tra Python e PostgreSQL appare sempre piu' forte.
Se da un lato ITPUG sarà anche per questa edizione media partner della conferenza italiana PyCon 8 , la community PostgreSQL viene citato nella sezione Community per l'internazionale PyCon 2017.

venerdì, 03 febbraio

17:55

GitLab, PostgreSQL, e la perdita accidentale dei dati [:: Luca Ferrari ::]

Un socio di ITPUG ha indicato un articolo interessante riguardante un incidente informatico capitato a GitLab. A parte il tecnicismo e l'errore, forse grossolano e sicuramente dettato dallo stress e la fretta (chi è senza peccato scagli la prima pietra...), la parte interessante dell'articolo è l'apertura e la documentazione che GitLab ha voluto fornire a seguito dell'accaduto.
Sicuramente questo atteggiamento ha permesso a GitLab di uscire "meglio" dal disastro, poiché quasi tutti gli sviluppatori hanno apprezzato la documentazione fornita, che ha consentito uno studio postumo utile a chi si troverà in simili situazioni.

venerdì, 27 gennaio

21:08

TAP: alcuni concetti [:: Luca Ferrari ::]

Il Test Anything Protocol (TAP per gli amici) è un formato semplice ed efficace per la reportistica di test automatici.
Nato nell'ecosistema Perl nel 1988, il protocollo si è evoluto ed è uscito dai confini Perl per giungere ad altri linguaggi e sistemi, perfino database con PostgreSQL e pgTap.

Il formato TAP è abbastanza semplice e si basa su alcuni concetti semplice:
  • producer è un'applicazione che si occupa di produrre un output TAP compatibile (su stdout)
  • consumer è un'applicazione che si occupa di interpretare l'output di un producer e fornire un report finale.

Ad esempio "prove" è un consumer dell'output prodotto da "Test::More" e similari, che a sua volta fungono da producer.
Nell'esempio relativo a PostgreSQL si ha che "pg_prove" è un consumer, e le funzioni importate da pgTap e i relativi script SQL sono i producer.

Il formato TAP è abbastanza semplice e prevede un solo paio di elementi obbligatori.
Anzitutto occorre inserire il numero di test, ovvero il piano di esecuzione, indicato come 1..N (con N > 0), e solitamente questo compare come primo elemento nell'output. Grazie a questa informazione il consumer sa se ha raggiunto la fine dei test (N) correttamente o se qualcosa ha causato un abort del sistema. Con l'evoluzione TAP supporta anche che N sia zero, indicando così che si vuole saltare la porzione di test. Inoltre è possibile specificare il piano di esecuzione alla fine, che in altre parole è come dire che non c'è un vero piano di esecuzione.

Successivamente, per ogni test effettuato, ci deve essere almeno una riga che inizia con "ok" oppure "not ok". Questo è l'unico elemento obbligatorio, anche se altri sono suggeriti per una migliore comprensione e analisi dei tool consumer.
Subito dopo lo stato del test si dovrebbe indicare il numero progressivo del test stesso, come pure una descrizione del test (affinché si possa capire meglio quale test è stato eseguito). Da ultimo vi è la possibilità di una direttiva (commentata in stile Perl, ossia con "#") che può indicare di saltare il test (SKIP) o che il test non è ancora completo (TODO).

Riassumento l'output di TAP può essere considerato come:


<# direttiva>

Ed ecco quindi un esempio pratico:

1..2
ok 1 - First comparison test
ok 2 - Second comparison


Qualora il piano di esecuzione non sia corretto TAP dovrebbe fornire una indicazione (non una direttiva) di tale fatto:

1..10
ok 1 - First comparison test
ok 2 - Second comparison
# Looks like you planned 10 tests but ran 2.

Solitamente durante la fase di sviluppo non si utilizza un piano di esecuzione, ma all'atto del rilascio del software il piano di esecuzione deve essere "congelato" in modo da aumentare la verifica automatica di errori.


Nell'output di TAP tutte le linee che iniziano con un commento in stile Perl ("#") vengono ignorate e usate, ad esempio, per fornire all'utente dei messaggi diagnostici per aiutarlo a capire perché un test è fallito.

Una direttiva di emergenza, denominata "Bail out!", indica che il sistema di test ha deciso di non proseguire per errori (controllati) troppo gravi. Ad esempio si può annullare una sessione di testing perché la rete non è disponibile, o il compilatore non è alla versione corretta, ecc.

Nel caso in cui non sia fornito un vero piano di esecuzione, e quindi l'output di TAP non inizi con "1..N", il sistema non sa quanti test deve eseguire. In questa eventualità si deve procedere con i test, aumentando in modo incrementale l'eventuale numero riportato in uscita, e alla fine stampando il "presunto" piano di esecuzione:

ok 1 - First comparison test
ok 2 - Second comparison
1..2

Tuttavia in questo caso il sistema non può sapere autonomamente se i test sono finiti o se c'è stato un abort di esecuzione, e per questo si richiede al programmatore di inserire una chiamata di fine esecuzione (ad esempio in Perl done_tsting() ).


Fino a qui ci si è occupati di TAP dal lato del producer. L'output di TAP viene poi analizzato a sua volta da un consumer, ad esempio "prove" o "pg_prove" che forniscono un riassunto su quanti test sono stati eseguiti, quanti sono andati bene e quanti sono falliti. L'idea dei consumer è che, all'aumentare del numero di test, l'utente dovrebbe potersi concentrare solo sul risultato finale e non sui singoli output dei vari test.

Per maggiori informazioni sulle specifiche TAP si veda qui.

16:04

Reboot ITPUG (Le mie dimissioni da ITPUG...parte 3) [:: Luca Ferrari ::]

Il consiglio di ITPUG è nuovamente in forze: dopo le mie dimissioni di circa un mese fa è stato eletto un nuovo socio per sostituirmi.
Questo permetterà ad ITPUG di proseguire le normali attività fino alle prossime elezioni di fine biennio, direi Aprile.
Presto sparirà il mio nome dalla lista dei consiglieri , immagino ci vorrà tempo perché si dia la giusta visione al mio sostituto.

A seguito delle mie dimissioni ho assistito ad un approccio abbastanza roccambolesco nella gestione del da farsi. Premesso che non ho intenzione di polemizzare e che quanto qui descritto rappresenta solo (e ovviamente) il mio punto di vista, ecco cosa è successo.

Anzitutto un po' di delusione perché le mie dimissioni non sono nemmeno state verbalizzate. Non è mania di protagonismo, ma un consiglio che vuoel una gestione trasparente deve quanto meno prendere atto di quanto sta accadendo al suo interno e "scolpirlo" nella pietra. Amarezza anche per la presidenza, che nonostante io avessi chiesto si pronunciasse, si è limitata a convocare l'assemblea straordinaria.

Stupore anche per la decisione, quasi unilaterale e a colpi di rima baciata (ossia in modo molto prolisso), di delegittimazione del consiglio stesso. Essendone io uscito si è deciso, applicando in maniera molto rigida e forse non regolare lo statuto, di delegittimare il consiglio stesso. A nulla è servito portare alla memoria dei consiglieri (alcuni storici quasi quanto me) e dei soci che già in passato, in analoga situazione e con dimissioni presentate, il consiglio aveva comunque proseguito la sua attività. E a nulla è servito ricordare che anche i soci pendenti potevano essere ammessi all'associazione (anche perché lo statuto stesso prevede 30 giorni per una decisione).

I soci stessi sono stati posti in discussione, utilizzando una logica boolean abbastanza contorta per la quale chi non aveva pagato/rinnovato la quota 2017 risultava "non in regola" e quindi non ammesso alle votazioni del mio sostituto. Ora, in assenza di un regolamento specifico e considerato che le quote vengono rinnovate in occasione dell'assemblea ordinaria (solitamente Aprile), questa mi è sembrata una contromisura molto forte. Inoltre, non essendoci un termine stabilito per il rinnovo, definire la morosità dei soci risulta abbastanza discutibile.
E anche qui i consiglieri storici avrebbero potuto ricordarsi di cosa accaduto nel 2014, situazione differente ma valutazione di "morosità" analoga.
Ancora peggio: c'è la garanzia che i consiglieri fossero tutti in regola con la quota?
E se non lo erano, anche se per un breve periodo nel loro mandato, il consiglio non deve essere analogamente delegittimato?

Ma andiamo avanti. E' stata convocata una assemblea straordinaria dei soci, sbagliandone la convocazione e facendo quindi slittare di un giorno l'assemblea stessa. Che poi è stata verbalizzata come ordinaria, e non come straordinaria.
Piccolezze, sviste, e concordo! Ma una associazione che vuole applicare rigidamente lo statuto non può fare simili sviste, almeno secondo me.
E se anche succedono queste sviste, perché in un caso la convocazione è stata annullata (ritardando quindi la "rilegittimazione" del consiglio) e nell'altro caso no?

Insomma, come si evince, ritengo che sia stato applicato uno statuto mirato piu' a legare le mani all'associazioni che non a sostenere la stessa.
Fermo restando che l'approccio difensivo difficilmente risulta inadeguato, forse questo accanimento ha causato piu' danni che utile.

Detto questo penso, in tutta onestà, che a parte i miei impedimenti personali forse è un bene che io sia uscito da questo consiglio: le incongruenze fra il mio modo di vivere l'associazione e quello degli altri membri è ormai abbastanza distante, e questo avrebbe comunque impedito un sano lavoro di entrambi.

In bocca al lupo al nuovo consiglio, e buon lavoro!
Sperando che si riprenda a pubblicare ai soci i verbali delle riunioni, anche questi trattenuti a colpi di statuto...

Un'ultima nota: fino alle mie dimissioni io sono stato l'unico consigliere ad essere stato in carica dall'inizio dell'attività ITPUG con assoluta continuità. Ahimé ritengo che la mia memoria storica non sia stata utilizzata in modo costruttivo come avrebbe potuto.

P.S.
dai messaggi che passano in lista soci penso di sapere chi sarà il prossimo presidente: 47605db981f8

mercoledì, 18 gennaio

20:14

Quanto ITPUG? (Le mie dimissioni da ITPUG parte 2) [:: Luca Ferrari ::]

Avendo marcato la fine della mia attività da consigliere con le dimissioni di circa un mese fà, ho deciso, quasi per curiosità, di cercare di quantificare il lavoro svolto da ITPUG e dal suo consiglio negli ultimi due mandati.
Si tratta di dati ovviamente indicativi, visto che strumenti diversi offrono opzioni di statistica differenti, ma possono essere utilizzati per un grezzo lavoro di analisi quantitativa.
E' bene sottolinearlo: si parla di attività quantitativa, non qualitativa!
Tuttavia l'attività quantitativa spesso indica e sottointende la presenza in associazione e la vitalità della stessa, da qui il mio interesse per questi semplici dati.

Ovviamente non sto svelando alcun segreto, questi dati sono comunque visibili e calcolabili da ogni consigliere e socio, con un po' di impegno e pazienza. Potrei anche aver commesso qualche errore di computazione, nel qual caso ogni correzione è ben accetta.

Considerando quindi la data del 30 aprile come termine di un biennio (e il relativo inizio del successivo), e sottolineando come il biennio 2015-2017 non sia ancora giunto al termine (e quindi i dati di tali biennio si riferiscono alla data attuale), si ha che:
  • biennio 2013-2015
  1.  301 commits
  2. 281 tickets
  3. 19 verbali riunioni di consiglio
  4. 108 thread in lista itpug-consiglio@
  5. 170 thread in lista itpug-soci@
  • biennio 2015-2017
  1. 103 commits
  2. 190 tickets
  3. 7 verbali riunioni di consiglio
  4. 160 thread in lista itpug-consiglio@ 
  5. 130 thread in lista itpug-soci@

L'attività del consiglio può essere quantificata con il numero di commits nel repository documentale, ovvero quanti documenti il consiglio ha ritenuto di inserire fra quelli ufficiali (fra questi, i verbali delle riunioni di consiglio), nonché dal numero ti tickets (ovvero di problematiche e task da affrontare). Come si può notare il valore di entrambi è drasticamente calato nell'ultimo biennio, segno che non si utilizza piu' né il repository né il sistema di ticketing come strumento base per la gestione delle attività del consiglio.
Questo è in parte confermato anche dall'aumento del numero di thread nella mailing list consiglio, che rispecchia il maggior uso e preferenza di questo canale di discussione rispetto agli altri strumenti.
A mio avviso questa è una regressione, poiché l'email non rappresenta lo strumento ideale per gestire scadenze, priorità, condivione di documenti.
Il dato però piu' allarmante, a mio avviso, è quello delle riunioni di consiglio, o meglio, dei verbali delle riunioni di consiglio. Come si può vedere le riunioni di consiglio sono scese del 60% circa, segno che il consiglio non ritiene sufficientemente utile riunirsi con regolarità (ulteriore conferma della preferenza del canale e-mail), o ha delle difficoltà a riunirsi.
Appare anche diminuita l'attività e la presenza del consglio nella mailing list dei soci, visto che il numero di thread si è abbassato. Ora, questo dato in particolare non coinvolge direttamente il consiglio, visto che i thread possono anche essere creati dai singoli soci (e anzi, questo è quello che dovrebbe accadere); tuttavia l'abbassamento del numero di discussioni evidenzia, secondo me, un raffreddamento del "networking" fra i soci al quale il consiglio dovrebbe cercare di porre rimedio.

Lascio ad altri il computo dei post e della frequenza di aggiornamento del planet italiano perché sarei sicuramente male interpretato.

ITPUG ha una struttura di supporto informatico sicuramente complessa e funzionale (si veda qui), di gran lunga superiore a quella di molte altre associazioni PostgreSQL analoghe. Ritengo sia di vitale importanza per l'associazione che ogni consiglio riesca ad usare al meglio questa infrastruttura, nonché la storia che essa contiene (archivi, logs, ecc.) poiché rappresenta un bagaglio culturale di enorme valore.

venerdì, 13 gennaio

17:59

Josh Berkus lascia il core team di PostgreSQL [:: Luca Ferrari ::]

E' di ieri la notizia che Josh Berkus, uno dei membri del core-team di PostgreSQL, si dimette dal core team stesso, e in effetti come diretta e rapida conseguenza non appare piu' il suo nome nell'elenco dei contributor (si veda il suo annuncio ufficiale qui.

Ho avuto poche occasioni di vedere Josh dal vivo, e quello che mi ha sempre colpito è la sua capacità come speaker, oltre alle sue competenze tecniche dettate da una grande esperienza. Ma un'altra cosa mi ha sempre colpito: Josh si è sempre dimostrato (nelle sue apparizioni nonché nelle sue comunicazioni nelle varie mailing list) una persona corretta e aperta, in una sola parola mi ha sempre dato l'impressione di essere una persona "pura" per quanto riguarda il progetto stesso.
Questo perché, a differenza di altri membri del progetto, si sono viste anche reazioni molto piu' business-oriented e meno community-centric.

Ritengo che Josh abbia svolto un ruolo molto importante per l'advocacy e la qualità del progetto PostgreSQL e, anche se il team è composto da persone piu' che valide, penso sarà difficile rimpiazzare pienamente un simile personaggio.