PgAdmin III è ancora vivo!

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

Riflessioni su pl/java

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.

Ulteriori considerazioni sul planet PostgreSQL italiano

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:

• 14 Aprile
  
• 5 Maggio
  
• 6 Maggio
  
• 8 Maggio
  
• 19 Maggio
  
• 20 Maggio
  
• 11 Giugno
  

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.

Perl _ filehandle

Leggendo la documentazione di :Find mi sono accorto di una frase nella sezione di esempio:

the "_" is a magical filehandle
that caches the information from the preceding "stat()", "lstat()", or
filetest.

e così incuriosito sono andato subito ad approfondire nella documentazione di stat:

If "stat" is passed the special filehandle consisting of an
underline, no stat is done, but the current contents of the stat
structure from the last "stat", "lstat", or filetest are returned.

Diciamo che _, a differenza della variabile topic non è una vera variabile ma un segnaposto particolare che viene interpretato come accesso alla cache dell'ultima operazione stat effettuata. E' facile costruire un esempio che mostri questi:

#!env perl

use v5.20;

my $file_name = $0; # myself

my @stat_values   = stat $file_name;
my @cached_values = stat _;

say "Same values for $file_name!" if ( $stat_values[1] == $cached_values[1] # inode
           && $stat_values[7] == $cached_values[7] # size
           && $stat_values[8] == $cached_values[8]  ); # atime

Lo stesso utilizzo non può essere effettuato con File::stat, che infatti riporta nella documentazione:

As of Perl 5.8.0 after using this module you cannot use the implicit $_ or
the special filehandle "_" with stat() or lstat(), trying to do so leads
into strange errors.

Secondary Selection & Emacs

Una discussione sulla mailing list Perl6 mi ha portato a fare una rapida ricerca e scoprire che, ovviamente, Emacs supporta anche
la Secondary Selection. Questa è una modalità nativa di X11 (che in realtà supporta fino a 4 clipboard coesistenti) che funziona un po'
come il kill-ring di Emacs stesso, ma che nella sua implementazione non si appoggio al kill-ring.
In sostanza è possibile copiare e incollare testo indipendentemente dalla regione selezionata e senza modificare il contenuto del kill-ring,
consentendo quindi ad Emacs di gestire fino a due clipboard contemporanee, una delle quali gestita tramite un ring e collegata
alla clipboard principale di sistema.

Non usate :wq! per uscire da vi!

Una cosa che non capisco di Vi(m) e dei suoi utenti è la costante ed errata abitudine di usare il comando q! per uscire dall'editor.
Ho già scritto in precedenza riguardo questo soggetto, ma sono incappato in una innocente immagine di un minicorso del linguaggio C che, ancora una volta, insegna a chi è alle prime armi ad uscire da Vi con la combinazione mortale :wq! (qui l'immagine del post).


Vediamo di approfondire ancora una volta.
Anzitutto cosa suggerisce l'aiuto in linea di Vi? Eseguendo :help si ottiene qualcosa del genere:

*help.txt*      For Vim version 7.4.  Last change: 2016 Mar 31

                        VIM - main help file
                                                                         k
      Move around:  Use the cursor keys, or "h" to go left,            h   l
                    "j" to go down, "k" to go up, "l" to go right.       j
Close this window:  Use ":q<Enter>".
   Get out of Vim:  Use ":qa!<Enter>" (careful, all changes are lost!).

Andiamo bene! L'help in linea suggerisce di uscire dall'editor con :qa!, in sostanza l'equivalente di una kill -9!


Eppure ci sono alcuni modi molto piu' furbi di uscire da Vi senza rischiare di perdere i dati, e il mio preferito è quello di usare ZZ che esce salvando se necessario le modifiche. Perché questa cosa è importante? Perché forzare un aggiornamento del file ad ogni  uscita ne cambia il timestamp e potrebbe creare conflitti con strumenti di controllo delle versioni e di build automatico.
Ma non solo, se si digita :help :x si scopre che:

*:x* *:xit*
                        Like ":wq", but write only when changes have been
                        made.

ZZ                      Write current file, if modified, and quit (same as
                        ":x").  (Note: If there are several windows for the
                        current file, the file is written if it was modified
                        and the window is closed).

Mettiamo ora a confronto le varie modalità:

comando	caratteri	rischio di perdita modifiche
:qa!	4	si
:wq!	4	no
ZZ	3 (contando SHIFT)	no
:x	2	no

Quindi perché non istruire gli utenti da subito ad usare modalità di uscita smart, visto che risultano perfino piu' compatte (in termini di caratteri) rispetto a quelle brutali?

Perl and regexps are too much verbose (!)

A colleague asked me a quick Perl way to check if a string contains only a predefined set of chars excluding a few ones.
Easy pal!
Regexp to the rescue!

Then I was asked for a way that did no use a regular expression, because "you know, regular expression can be somehow verbose".
Gosh!
My answer was simply "you don't use regexps a lot!".

I don't believe I have to explain to any (Perl) programmer that regexps have been designed to express in short a whole set of choices,
more in general an alphabet (in the most wider concept).

But let's move on, and after showing a quick and dirty one liner such as:

perl -E 'say "Wrong $_" unless ( /^[0-9]+$/ ); ' -F

I got another strange sentence as "yeah, but I don't like Perl too much, it is somehow verbose as a language".
And again, my answer was: "you don't use it regularly!".

It is clear Perl was seen in the wrong way, since both the language as well as regular expressions can be really short, as well as
a one liner…
No other comments required!

Distanza fra date "note" in Perl

Come si può fare a conoscere se una serie di date note si trovano ad una distanza interessante l'una dall'altra?
Facile con un po' di Perl!


Anzitutto la definizione: per distanza interessante intendo un numero di giorni multiplo di 10, anzi meglio, potenza di 10, ovvero 100, 1000, ecc.
Detto questo, costruiamo la struttura base:

#!env perl

use v5.20;
use DateTime;

my $begin = DateTime->new( year => ..., month => .., day => .. );
my $now = $begin->clone();
my $dates = [
    { day => 4, month => 7 }
    , { day => 19, month => 7 }
   ...
    ];

push @$dates, { day => $begin->day, month => $begin->month };
my $base = 10;

Con $begin si indica la data di partenza, mentre in $dates si inseriscono giorno e mese di alcune date a voi significative.
Per capirsi, $begin potrebbe essere la data di nascita di vostro figlio e $dates contenere il vostro matrimonio, laurea, ecc.
Da notare che inserisco automaticamente la data di partenza nell'array delle date da cercare, così da valutare la data contro se stessa
spostata chiaramente di alcuni anni.
Fino a qui, nulla di sorprendente. Beh, anche il resto è abbstanza noioso:

for ( 1 .. 100 ){
    $now->add( years => 1 );
    for my $when ( @$dates ){
 $now->set( day => $when->{ day }, month =>  $when->{month} );
 my $delta = ( $now->epoch - $begin->epoch ) / ( 60 * 60 * 24 );
 next if ( $delta % $base != 0 );
 say "La data " . $now->dmy . " si trova a $delta giorni da " . $begin->dmy 

           if ( ( log( $delta )/log( $base ) ) =~ /^\d+$/ );
    }
}

In un ciclo di 100 anni (perché oltre diventa poco interessante, almeno per voi visto che non ci sarete piu') si processa un anno alla volta
sommandolo alla data di partenza $now (clone della vera data). Contro tale "annata" si testano tutte le date ricercate per vedere se
la distanza in giorni $delta è multiplo di 10 ($base) e piu' precisamente se è un logaritmo in base 10.
Solo di quelle date si effettua una stampa a video.

Cosa sono gli Emacs mode? Major mode, minor mode, oh my...

Uno dei concetti chiave di Emacs che mi pare sia molto spesso sottovalutato da chi non lo utilizza è quello dei mode.
Emacs è un editor multi-mode, ovvero è possibile attivare piu' modi contemporaneamente.
A loro volta i mode si suddividono in due categorie principali:

• major mode rappresentano il contesto di un buffer;
  
• minor mode forniscono funzioni trasversali fra uno o piu' buffer.
  

Molto spesso la differenza non viene colta, ma è importante perché l'uso combinato dei mode può personalizzare tantissimo il comportamento
di Emacs.
Anzitutto Emacs ammette un solo major mode per buffer, mentre virtualmente infiniti minor mode possono essere attivati su ogni buffer.


Un major mode definisce il "contesto" di utilizzo del buffer, nonché le funzioni principali fornite in quel buffer. Ad esempio
se si sta editando un buffer che contiene uno script Perl, il relativo major mode fornirà funzioni legate a Perl. Analogamente, se
si sta visualizzando il contenuto di una directory, il relativo major mode (es. dired) fornirà le funzioni principali
per interagire con il buffer. Un major mode può anche "rimappare" alcuni tasti funzione per rendere piu' facile l'utilizzo all'interno
di tale buffer.


Un minor mode fornisce sottofunzioni specifiche all'interno del buffer, e magari a livello globale su tutti i buffer. L'esempio classico
è quello del correttore ortografico (es. flyspell) che agisce sul testo indipendentemente questo sia codice o testo o una chat.


Per meglio comprendere questi concetti, mi si passi un blasfemo paragone con Eclipse.
In Eclipse è possibile editare progetti Java, C/C++, Perl, PHP, Python (e altri). A seconda del tipo di progetto Eclipse carica funzioni
differenti e fornisce refactoring e renaming in modo differente, e questo è esattamente quello che fa un major mode Emacs. Ecco perché poco
sopra ho parlato di "contesti" del buffer.
Tornando ad Eclipse, i commenti e le parole chiave vengono evidenziate in modo analogo fra i vari linguaggi, come pure i marker degli errori
e dei problemi, e questo è quello che fa il minor mode Emacs (ok, per i font c'è la fontify, ma non scendiamo a questo livello).
E i template del codice? Eclipse fornisce template per, ad esempio, i get e set (getter e setter), cosa che in realtà richiede due passaggi: uno di
front-end e uno di backend. Il front-end mostra la UI all'utente, il back-end scrive il codice contestualizzato. Questa operazione può essere
fatta in Emacs tramite un altro minor mode (es. yas).


Per riassumere si tenga sempre presente che il major mode stabilisce cosa è possibile fare con un buffer, sia in termini di contenuti, che di tasti funzioni,
che di funzioni stesse, mentre un minor mode stabilisce quali arricchimenti si possono fornire al contenuto del buffer.
La linea di separazione non è così marcata, perché come è noto Emacs è un ecosistema che si piega su stesso e si espande, ma per avvicinarsi a questo
strumento quanto sopra dovrebbe bastare.

Magit spin-offs: another way to name a tracking branch.

A few days ago my attention was caught by an entry in the Magit Branch Pop-up buffer: Create a new spin-off.
Uh?

What the hell is a spin off?
According to the Magit Branching documentation, a spin-off is nothing more than a tracking branch.
A tracking branch, created on the git side with the -t switch, is a branch that knows (i.e., it has
knowlegde) about the branch it was originated from. Well, every branch in git has, of course, knowlegde
about its ancestor branch (how would you merge otherwise?), but in this case
the knoweldge is made explicit by the tracking feature.


In particular, when a tracking branch is checked out git advices about commits that made the
current (tracking) branch diverging from its ancestor, something like the following:

% git checkout b
Switched to branch 'b'
Your branch and 'master' have diverged,
and have 1 and 2 different commits each, respectively.
  (use "git pull" to merge the remote branch into yours)

In the above example you can see that the b branch is behind master two commits, as well as after master by one commit.
In other words, your b branch has done a single commit while master advanced by two other commits. As git
suggests, you can pull and git will automagically fetch updates from the master branch into b.
And in fact:

% git pull
From .
 * branch            master     -> FETCH_HEAD
Merge made by the 'recursive' strategy.

The tracking is useful to know transparently when and how (much) your branch is diverging from the source, and this of course
is true both for local commits and remote ones:

% git status
On branch b
Your branch is ahead of 'master' by 2 commits.
  (use "git push" to publish your local commits)
nothing to commit, working tree clean

What happens into Magit? Well, once you checkout a tracking branch the popup buffer shows that is unmerged from the source branch, and
it does suffice to F pull to prompt the merging popup.





So, to recap, a Magit spin-off lies a tracking branch, which in turn is a branch explicitly aware of what makes it different
from the source branch. This is useful, for instance, for features and short living development branches that are going to be merged
surely by design and must be kept up to date from the normale release history. I don't see the point in using tracking into
versions branches.

Perl blogs will be powered by PostgreSQL

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!

FreeDOS blog challenge: my short story about FreeDOS

I found the FreeDos blog challenge while reading one of my planets, and I decided to share a few lines about my personal experience.

Back in the days when I was a little tiny poor developer just kicked off by the university, I found a job where I was supposed to use a fourth-level language, something I would hate for the following years. The development chain was awkward: while the production machine was a Linux system, and thus the deployment was done on a Linux server, the development machine was a DOS one. Allow me to explain: you could develop and compile applications both on Linux, some Unix, and DOS (or Microsoft Windows including a DOS)
but installing the compiler on a Linux machine was a real pain, and so I was instrumented to work on Windows and DOS.
Another reason to stay on the DOS side of development was that the source code did use the cp850, that is those set of characters used to create frames and decorations.

Therefore, at that point, I was forced to boot my laptop on Windows, open the DOS prompt and interact with all the DOS basic programs and commands, like the text editor and find. The deploy was as easy as copying a file from the DOS box to the Linux server via either a Secure Shell (e.g., winscp) or a remote share (e.g., Samba).
It was not a cat's pijama for me, since I was a kind of "Unix-inside" developer, and I was coming out of university where I saw a lot of shiny brand new development tools like Eclipse.

I start reasoning about a way of running the DOS compiler on my Linux box directly, and of course I found out FreeDOS. The problem was I needed to run both FreeDOS and Linux at the same time to get out of the latter all the command line power I was used to and out of the former the ability to run the required compiler and tools.
I hear you: virtualization to the rescue!
Not so easy pal, since back in those days (I think it was 2003) there was not the widespread of virtualization as we mean today, and the only tools available to me were jails, chroot, and VMWare. Unluckily booting a FreeDOS machine via VMWare on my poor Intel Celeron 733 MHz with 192 MB of ram was not an efficient idea.

Therefore I was forced to throw away the idea of using FreeDOS (for that purpose).

This experience pushed me to study better the compiler and face the problem of installing the cp850 on my Emacs editor, as well as how to configure the terminal (terminfo) to use the compiler entirely on Linux, and I never came back to Windows+DOS for my development.

After a few months I had to manage another ancient machine used to send out faxes. The machine was bare metal directly attached to a moden on its own phone line, running a DOS program to send faxes. Due to an hydraulic problem, the machine blown away and so I had to replace it. Of course, it was not possible to either find a decent running copy of MS-DOS, as well as to substitute such machine with an Hylafax server (but that's another story).
Luckily, I had made a little experience on FreeDOS, I decided to ran that version on the fax machine. Several years after I was on another job, and I got an email from a previous colleague of mine telling me that they have turned off the fax machine, that have ran FreeDOS for 6+ years without any problem. OK, let's be honest here: the job of the machine and, thus, of the operating system, was not so complex in this deployment, but I think it is great to have a project as FreeDOS that allows anyone to run ancinet programs and access data even years after the programs developers are no more on the market!

And what about today?
Well, today I believe it is a lot easier to run a FreeDOS instance, and in fact I've always a virtual machine around with a recent version of FreeDOS that I use to run my 20+ years old C programs I made at school!

Thank you very much to all the developers, maintaners and people behind the FreeDOS project.
Unlike other free operating systems that often share a common architecture and execution runtime, this one is especially important in my
opinion because it allows us to run programs no other operating system could.