PgLife

Qualche giorno fa mi sono imbattuto per caso in PgLife, una pagina web costruita da Bruce Momjan che raccoglie e aggrega diverse informazioni dalle community PostgreSQL e le presenta raggruppate. Lo scopo è quello di presentare agli utenti inesperti un riassunto di quello che sta succedendo nella community PostgreSQL, nonché indirizzarli verso le risorse di supporto che meglio li possono servire. La pagina si aggiorna automaticamente andando a prelevare informazioni dalle mailing lists, dal canale IRC e dal planet.

Verso Qt 5

Aron Seigo in questo post spiega che la versione 4.11 di KDE sarà importante per due motivi fondamentali: il long term support e il passaggio a QT 5. La 4.11 infatti sarà l'ultima release basata su Qt 4.

La nuova versione di KDE sarà basata sul Plasma Workspace 2, a sua volta appunto basato su Qt 5.

L'importanza dello stile

C'è sempre stato un grosso dibattito circa lo stile di programmazione, indipendentemente dal linguaggio adottato. Lo stile raccoglie nozioni sintattiche e semantiche, ovvero come scrivere e allineare un pezzo di codice e come chiamare variabili, funzioni, e altri identificatori.

Tempo fa seguivo un thread ove mi sono permesso di esprimere un positivo commento sul linguaggio Python. Premetto che non sono un programmatore Python, ancora non riesco ad appassionarmi al linguaggio, forse perché il mio fidato compagno Perl riesce comunque a farmi svolgere gli stessi compiti. Ho comunque imparato le basi del linguaggio, proprio per sapere di cosa sto parlando quando si entra in discussione.

Ebbene un indubbio vantaggio di Python è l'indentazione basata sugli spazi. Eppure c'è ancora gente che trova questa cosa troppo rigida:

However, I've learned programming with languages where whitespace is throwaway and not having to bother about whitespace or indentation is more natural for me.

A prima vista il commento di cui sopra è piu' che ragionevole: dopotutto perché preoccuparsi di uno spazio di rroppo o di un'andata capo sbagliata? Ognuno di noi ha, inconsciamente, un proprio stile di programmazione, così come ha una propria calligrafia. E proprio come la calligrafia, anche lo stile di programmazione risulta molto influenzato dai primi insegnamenti e dagli esercizi fatti, ma non per questo risulta non-migliorabile.

Ora chiunque ritenga che un linguaggio libero nella formattazione possa essere migliore di uno rigido in tale aspetto è uno stupido (opinione ovviamente personale); analogamente lo è chi è pensa il vice-versa.

Il punto non è tanto la formattazione del codice, bensì lo stile: Python impone uno stile basato su spazi bianchi, mentre altri linguaggi non impongono tale stile. Ma di fatto per programmare in qualunque linguaggio occorre aderire ad uno stile. Non è solo una questione di sintassi, è una forma mentale.

Se si programma del codice con il proprio stile, altri programmatori potrebbero avere difficoltà nel leggere a manutenere tale codice. E se questo non rappresenta un problema per progetti "home-made", lo diventa per grossi progetti ove esistono precise regole di formattazione e di stile. La mancata applicazione di tali regole faranno si che il proprio codice sia escluso a priori, indipentemente da quanto possa essere efficace ed efficiente. L'esempio che sono solito fare è quello di un autore di libri: ogni libro deve avere una struttura che i lettori si aspettano, e quindi un indice, un titolo di capitolo, una numerazione di pagina, del testo formattato correttamente, un indice analitico, ecc. Se il libro non aderisce a tale struttura non significa che è illeggibile, ma semplicemente che la sua lettura potrebbe risultare deviata rispetto allo standard che i lettori si aspettano. Lo stesso vale per un pezzo di codice.

Il solo fatto di avere libertà di formattare il proprio codice come si vuole non significa che qualunque formattazione accettata da compilatore/preprocessore possa essere lecita. E quindi cosa succede? Si definiscono i suddetti stili. Cosa fa invece Python? Elimina in un certo senso il problema alla radice rimuovendo parte delle discussioni senza fine su dove piazzare parentesi ed andate a capo. E il solo fatto di aver rimosso tali discussioni gioca a favore del linguaggio.

Poi c'è l'aspetto creatività: molti sostengono che un linguaggio rigido nella formattazione impedisca o limiti la creatività del programmatore. Anche questo è falso: la creatività è insita nel processo, non solo nella sua implementazione. E' quindi l'algoritmo in primis che deve essere elaborato in modo creativo, non la sua implementazione. 

Se la penso così come mai non sono ancora passato a Python? Dopotutto Perl è proprio l'anti-Python dal punto di vista della sintassi e dello stile. Ebbene, come già detto, non ho ancora trovato una sfida sufficientemente avvincente da farmi passare a Python. Tuttavia questo non significa che i miei programmi Perl siano offuscati, anzi, cero sempre in ogni programma di usare una sintassi coerente e chiara, aderendo il piu' possibile allo stile del contesto in cui mi trovo.

Ero un utente Microsoft e non lo sapevo nemmeno!

All'alba della mia carriera da programmatore ero affiscinato dai sistemi Microsoft: lavoravo con SQL Server, studiavo il kernel di Microsoft Windows (2000) e mi cimentavo ad usare le MFC (la libreria Microsoft per C++). Da cosa derivava la mia dipendenza Microsoft? L'ho capito solo da poco.

Qualche giorno fa il mio piu' caro amico mi ha riportato alla mente un vecchio cartone giapponese, uno dei miei preferiti: Trider G7. 

Ebbene durante la fase di avvio del robot protagonista, la schermata che appariva sul computer centrale era la seguente:

Si nota chiaramente sia il linguaggio utilizzato che il produttore. Chissà, forse questo era un timido tentativo di lavaggio del cervello di giovani possibili programmatori...e forse è stato proprio quel messaggio che ha sviluppato nel tempo la mia passione per i sistemi non-Microsoft. Oppure qualche altro cartone, di cui non ricordo nulla, proiettava schermate con gnu, delfini, diavoli e pesci velenosi...

Fatto sta che, anche se involontariamente e inconsapevolmente, ero fin da bimbo un utente Microsoft, visto che seguivo assiduamente il cartone e avevo anche il roboto giocattolo (che però non includeva nessuna capacità computazionale!).

Due videogiochi che hanno segnato la mia vita

Qualche sera fa parlavo con alcuni amici di vecchi videogiochi, e così mi è tornato alla mente un gioco da sala giochi (arcade) al quale giocavo spesso quando, ancora piccolo, ero al mare: si trattava di un gioco di Formula Uno con la particolare caratteristica che non vie ra un monitor elettronico, bensì un nastro che ruotava sul quale era disegnata la pista, e la macchina era visualizzata tramite un proiettore luminoso. Insomma, un videogioco non elettronico, bensì elettromeccanico. Ricordo che mi affascinava nella sua semplicità: il cambio era a due marce, low e high e le altre macchine sul circuito regolavano la velocità a seconda di quella della mia macchina, perciò gli avversari erano comunque sempre "pari" al pilota.

Con non poca fatica sono riuscito a trovare qualche informazione sul gioco: si tratta di Daytona 500, anno 1976 (ossia piu' vecchio di me!).

A dire il vero la versione di cui sopra è quella "lusso": io ricordo di averne vista e provata anche una in bianco e nero, ma di quella non riesco a trovare informazioni.

Vi è anche un altro gioco, apparentemente stupido, che ha segnato la mia vita: Trivella per Commodore 64 (anno 1985). Il gioco ricorda vagamente il piu' famoso Pac-Man: il protagonista guida una trivella dalla forma tondeggiante che deve mangiare/scavare i pallini che si trovano in alcune gallerie senza essere a sua volta mangiato da alcuni mostri del sottosuolo. A differenza di Pac-Man, la trivella non è libera ma legata da una funa avvolgibile che gli consente di tornare alla base (per nascondersi). Il gioco prevede 70 livelli, ricordo mio padre che si accaniva con questo gioco e le serate passate a giocarci assieme. Credo lui fosse riuscito ad arrivare fino al livello 35, molto piu' di quanto fossi riuscito a fare io!

Kde & Emacs a tutto schermo

Un trucchetto semplice ma molto comodo per permettere a KDE di avviare Gnu Emacs a tutto schermo consiste nell'opzione di quest'ultimo mm che richiede appunto la massimizzazione del frame principale.

Quando il codice è veramente "pulito"

OpenBSD e' uno dei progetti per me piu' interessanti nel panorama Open Source: in particolare e' noto per la sicurezza intrinseca del codice (e di conseguenza del sistema operativo stesso). Lo sforzo degli sviluppatori di OpenBSD e' quello di fornire una base di codice particolarmente robusta e priva di errori banali di programmazione. Qualche giorno fa guardavo la lista delle patch per la versione 5.3 rilasciata lo scorso primo Maggio 2013. Ebbene la lista prevede solo 4 vulnerabilita' conosciute, e le patch per risolvere le problematiche sono veramente cortissime, fino anche ad una singola linea di codice.

La brevita' delle patch e' secondo me un fatto impressionante che testimonia l'alta qualita' del codice stesso, che pur non essendo immune da errori (quale codice lo e') e' cosi' robusto da permettere con piccole e semplici modifiche la correzione di errori molto specifici.

BSDA Certification Exam

One of the reasons that forced me to go to the Central Europe BSD Day 2013 was to take part in the BSDA Certification Exam. And I'm proud to say that now I'm BSDA certified! I've passed the exam with a quite high score, near the maximum, but I have to admit that I misread a few questions...I guess it is normal considering the stress of the exam itself.

I'm not supposed to talk about the exam contents, since one thing that any candidate has to sign and agree on is a non-disclosure agreement. However, I can say that the exam is very good in quality: questions are well written and, in my opinion, quite focused on the subject. Moreover, the correction of the question was in time, and therefore I received the results before the deadline for the correction has passed. 

How did I prepared to the exam? Well, I fired up four virtual machines, each one with one of the four mainstreams BSD releases (actually I was firing up five machines, but I used FreeBSD instead of PCBSD because I did not need a graphical environment to test my capabilities). On each machine I exercised all the confgurations and commands the BSDCG Study Guide recommends, and I noticed the differences among any command and stack. Being mainly a FreeBSD user, I found myself at home on FreeBSD systems, but recognized the need for more practice on different BSDs, and having virtual machine was a good way of comparing all the four main systems.

When you cannot find technical information...(or Why Perl & CPAN rock!)

Have you ever heard of the HL7 protocol? No? Well, me neither until a few days ago when I was studying for an exam.

Unluckily I was unable to find some good documentation related to such protocol, or at least, some good and quick documentation (you don't want to spend nights reading specifications about something you probably will not be using in the near future, right?).

Therefore I fired up my web browser, pointing it to CPAN and searching for some Perl libraries implementing such protocol. And I got it: the Net::HL7 library implements the bare messaging behind HL7. The next step was to fire up Emacs and start reading the code.

Well, as usual in Perl, the code was simple, clean, elegant and short.

In less than 30 minutes I had an understanding of the HL7 messaging that was superior to that of my other competitors, even those who were already using such protocol!

I have to say, Net::HL7 did not turn me into an HL7 guru, and it does not matter how many times I read the source code, nothing will make me a guru on such a subject. Nevertheless I believe that this is another evidence of how Open Source is a much superior way of doing things and sharing knowledge, and how Perl/CPAN represent one of the wider world knowledge base ever built.

Now, thinking about this episode, I don't know what exactly made the difference: it was Perl? It was CPAN? It was the courage to fire up an editor and look into the black box? Surely it was the combination of all the above, and this is also a reason why I strongly advocate that knowing a few languages is a huge mistake and that developers should be able to find and understand as many technologies and languages as possible, to be able to get inspiration and knowledge from everywhere.

Eclipse Day Florence 2013

Ho partecipato alla seconda edizione dell'Eclipse Day Firenze (EDF 2013), organizzata da RCP-Vision presso il centro congressi di Firenze una settimana fa. Devo dire che questa edizione mi è piaciuta anche piu' della precedente: in particolare molte presentazioni hanno incluso delle demo live from scratch, che hanno permesso al pubblico di meglio comprendere come la tecnologia Eclipse e l'intero ecosistema si sia evoluto.

La conferenza ha avuto un tenore molto serio, forse fin troppo per i miei guisti, ma nulla da eccepire sull'organizzazione e sul catering, sempre di alto livello, nonché sul centro congressi che è sempre bello (sarà perché comunque adoro la Toscana in generale e quindi mi appare sempre tutto molto bello).

Devo comunque notare che mi appare sempre piu' evidente come l'ecosistema Eclipse si sia evoluto per sopperire alle carenze proprie del linguaggio Java, e ora sia possibile fare instrumenting con pseudo linguaggi che prendono caratteristiche di altri linguaggi, come l'operator overloading che gli ingegneri Java hanno tanto disgustato...

Central Europe BSD Day 2013

With a few days of delay I'm reporting my trip to Naples to participate to the Central Europe BSD Day 2013. The conference was well organized and the location was nice: the conference took place at the CNR in Naples, and we had a whole room with multimedia display where several very good speakers presented the current status in many BSD-related projects.

One interesting fact that emerged from the conference is that the BSD community is somewhat really small when compared to the Linux one, and this does not mean that it has lack of quality or is steps behind because of the lack of resources: on the other hand the BSD community (or better, all BSD communities) has been able to focus and exploit their resources at the best. In other words, even with less developers than other communities, BSD is able to ship an enterprise quality set of products. It sounds to me that the whole point in BSD is to keep things simple, so that they are easier to be managed.

With regard to the conference organization I have to say organizers were really nice and made a good job to make the day successful, even if the number of participant was not so big as I would have been expected from an European event. However, the conference place was good, the meat was great and the technical discussions were very interesting too, so I've nothing but good words to say about the event.

As a side note, I had the opportunity to leave a few PostgreSQL flyers and to talk to some people about both ITPUG and PostgreSQL.

Sysadmin panics: nomi di risorse

Qualche giorno fa seguivo un interessante thread su quali nomi vengono dati alle proprie macchine/servizi, e questo mi ha riportato alla mente alcuni esempi di cattiva nomenclatura.

Mi è capitato di assistere ad un cattivo uso dei nomi da parte di un sysadmin immerso nel suo panico: ogni workstation, ogni utente, ogni stampante, ogni cartella di rete prendeva un nome dipendente dal numero di telefono dell'utente stesso. Anzi, per dirla tutta, non dipendente dal numero di telefono, ma uguale (ove possibile) al numero di telefono stesso. Ovviamente mi riferisco al numero di interno, quindi 3-4 cifre al massimo.

Perché la cosa non ha senso?

La prima motivazione, abbastanza ovvia, è che avere uno username numerico su un sistema è una idiozia. Si provi a pensare all'output dei comandi di amministrazione anche piu' banali che riportano, a fianco del PID (numerico) di un processo uno username anch'esso numerico; la confusione è presto garantita! Inoltre alcuni sistemi non accettano username completamente numerici, e questo era il caso di cui sopra, ove si era quindi creata una certa eterogeinità fra username alfanumerici, cartelle numeriche, stampanti numeriche, ecc.

La seconda motivazione, forse meno ovvia, percui questa scelta sia ridicola, è che non scala efficientemente. Le persone cambiano numero di telefono, anche se non spesso, e questo significa dover riconfigurare hostname, username, cartelle, nomi delle stampanti, code di stampa, permessi...quando la persona di fatto è rimasta la stessa, e la cosa cambiata non ha nemmeno influenza sul sistema informativo. Molto meglio allora nominare le cose sulla base delle persona, con il classico , in modo da poter identificare ad-personam le risorse.
Terza motivazione, ancora meno evidente: le persone vengono sostituite anche solo temporaneamente. Supponiamo che alla postazione 666 la persona si assenti per un periodo (es. maternità) e venga sostituita dalla persona della postazione 999: che identificativo deve avere la persona che cambia la postazione? La logica vorrebbe che abbia 666 come identificativo, per rispettare la postazione sulla quale lavora, ma di fatto questo riflette una situazione non reale e poco gestibile: che permessi deve acquisire la persona? Quelli della postazione 666 uniti a quelli della postazione 999? I permessi in XOR?
Insomma, di tutti gli schemi dei nomi che ho visto fino ad ora, questo è sicuramente il piu' imbarazzante con il quale mi sono trovato a lavorare. Chissà, forse ha qualche lato positivo, ma io francamente lo ignoro.

Sysadmin panics: EOL

EOL in informatica puo' significare diverse cose: "End Of Line", se visto da un programmatore, oppure "End Of Life" se visto dal lato di un sysadmin. Ed e' proprio questo aspetto argomento di questo post.

I sistemi informatici solitamente hanno un ciclo di vita ben definito, e la scelta di un sistema piuttosto che un altro, nonché di una versione piuttosto che di un'altra è proprio un argomento che va affrontato controllando anche la EOL del prodotto stesso, cosa che spesso viene trascurata.

La EOL è importante perché il produttore, sia esso commerciale, una community o un singolo sviluppatore, non fornira' nessun tipo di supporto per un prodotto che ha raggiunto la EOL. Questo ovviamente non significa che il prodotto smetterà di funzionare, ma usare un prodotto EOL significa essere soli e navigare a vista. In altre parole, se viene identificato un bug su un prodotto EOL, nessuno si occuperà ufficialmente di preparare un bug-fix. Il che, è giusto chiarirlo, non significa che non ci saranno bug-fix, ma che se questi si trovano solo dovuti alla buona volontà di qualcuno o all'uso di risorse indipendenti (anche commerciali) non mainstream.

Eppure, nonostante queste banali considerazioni, vedo molti miei colleghi in panico perché scoprono, improvvisamente, di avere prodotti EOL e di non saper prendere la decisione se aggiornare o meno. La resistenza all'upgrade è sempre la stessa: se funziona, perché cambiarlo? E spesso la scelta che viene fatta è quella di fare l'upgrade solo quando si presenta un reale problema da giustificare un downtime.

Inutile dirlo: è la scelta sbagliata!

La EOL dei prodotti solitamente è di anni, 5 o forse piu', mai meno di 2 (almeno dalla mia esperienza pratica). Se un prodotto va in EOL significa che non sono stati fatti aggiornamenti importanti negli ultimi 2 anni almeno, ovvero non ci si sta curando dei propri sistemi.

Inoltre noto che molto spesso si raggiunge la EOL perché si presta attenzione solo alla numerazione, che magari varia di poco. Se il prodotto "x" passa dalla versione 8 alla 9 nel giro di qualche anno, il salto tecnologico è sicuramente notevole, ma visto l'incremento di un solo valore decimale, spesso non gli viene data importanza. Si consideri ad esempio FreeBSD: al momento in cui scrivo la versione (-stable) piu' recente è la 9.1, e le versioni disponibili sono la 9.0, 8.3. Il salto da 8.2 a 9.1 non sembra così grande, ma in realtà la 8.2 è del 2011 e si trova al momento in EOL.

Se posso essere (parzialmente) concorde con chi sostiene che non ha senso correre dietro ad ogni minor release, spero che almeno queste considerazioni sulla EOL dei prodotti spinga qualche collega nel panico a prevedere regolari update.

No more FEAR (?)

Solitamente non mi accanisco in giochi per il computer. Da quando il mio fedele Commodore 64 è andato in pensione (parecchi anni fa), le mie ore davanti al computer sono sempre state spese nella maggior parte dei casi per imparare, piuttosto che per giocare.

Poi qualche anno fa, precisamente nel 2006, l'incontro con FEAR (First Encounter Assault Recon), un gioco sparattutto basato su una trama horror-complottistica. Mi è subito piaciuto: i personaggi, le dinamiche, le mappe, tutto era al posto giusto. Così ho iniziato a giocare al multiplayer, l'unico disponibile gratuitamente, e la passione è aumentata. Ho coinvolto qualche mio amico nel gioco, e a volte ho fatto anche qualche partita on-line da solo. 

Qualche anno dopo, in notevole ritardo rispetto alle tempistiche dell'arcade (ma come ho detto, ormai sono un giocatore anomalo) ho montato la versione single player. La mia attenzione è stata catturata, ed ho passato diverse serate davanti allo schermo per finire tutta la storia, rimandendo con quel senso di amarezza una volta completati tutti i livelli (se ben ricordo 18).

Così ho continuato: FEAR 2 (Project Origin), che mi ha semplicemente fatto perdere la ragione, e l'anno scorso FEAR 3, molto bello ma un po' troppo esagerato.

Intanto, occasionalmente, mi trovavo ancora con un mio caro amico per un bel FEAR 1 multiplayer (noto anche come FEAR Combat). Poi l'amara scoperta: dal 5 Dicembre 2012 FEAR Combat è dismissed, e non si può piu' aprire un server pubblico. Esistono delle patch e una community di affezionati al gioco, e forse un giorno mi unirò anche io, o forse è semplicemente ora di passare oltre...comunque è ancora possibile giocare a FEAR Combat a patto di usare la patch della versione 1.1 (denominata SEC2).

Ho provato il multiplayer di FEAR 3, ma non mi ha convinto. Sia chiaro, la grafica e gli effetti si sono evoluti tantissimo negli anni, ma il Combat originale mantiene quel qualcosa di affascinante nonostante gli innumerevoli bug.

E giusto per la cronaca: FEAR 1 l'ho giocato completo solo una volta, FEAR 2 ben 3 volte, e FEAR 3 solo una volta.

E' chiaro qual'è il mio preferito?