Curiosavo il web quando mi sono imbattuto in alcuni Chuck Norris Facts per geeks e visto che da poco è uscito il secondo volume della raccolta in italiano ritengo l'argomento di attualità e li cito qui di seguito, opportunamente tradotti in italico idioma...

• Il sistema funziona perchè Chuck Norris gli ha detto di farlo.
• Chuck Norris non ha bisogno di una suite di test. Sono i test ad avere bisogno di lui.
• Le CPU vanno più veloci per scappare da Chuck Norris. (senza peraltro riuscirci, ndt)
• Chuck Norris può normalizzare uno schema inserendo dati random.
• Chuck Norris può compilare gli errori di sintassi.
• Chuck Norris riesce a parsare XML non valido.
• Chuck Norris può infrangere la legge di Moore.
• Il cervello di Chuck Norris gli fa da controllo di versione, e funziona meglio di Git.
• Chuck Norris può fixare qualsiasi cosa senza cambiare niente.

Per gli amanti del genere, non perdetevi i Knuth Facts.

L'articolo originale è qui, e va oltre i geek facts sopra citati!

Di scuola francese, un sublime esempio di gusto barocco applicato all'operatore ternario...

bool isEmpty = object.isEmpty() ? true : false ;

...non vedo come altro spiegare questo:

unsigned ret = -1;

P.S.
A partire da questo, "Coding Comedy" diventa una categoria di posts :-)

Scenario

Due sviluppatori decidono di collaborare ad un progetto Java, si tratta di:

• Gino - sviluppatore Java, lavora su Windows
• Lino - sviluppatore tuttofare, lavora su Mac Os X

Lino possiede una macchina CentOS su cui gira un server SVN a casa propria, il tutto funziona bene ma Lino si annoia e spiana la macchina per effettuare alcuni esperimenti. Nel frattempo accade nell'ordine che:

1. L'esigenza di avere un repository comune per i sorgenti del progetto si fa incalzante
2. Git diventa famoso
3. GitHub apre i battenti

Il resto è storia...

Step 1 - account su GitHub

E' la parte più facile, Lino va su http://github.com e registra un account, per ora si accontenta di quello gratuito, che se da un lato non offre la possibilità di avere repository privati, dall'altro è completo in termini di funzionalità a meno del servizio SSL (ma visto che il repository è comunque pubblico...).

Step 2 - setup di msysgit su Winbloze

La fama di Git è letteralmente esplosa e il supporto per Windows non ha tenuto il passo. Fortunatamente dei ragazzi volenterosi hanno messo insieme un pacchetto di installazione a partire da materiale esistente: msysgit. Una volta installato, Lino ha a disposizione una shell Unixlike con git 1.5.5 già configurato, ssh e chicche varie. Ci sarebbe anche una GUI Tcl ma Lino non è riuscito a farla funzionare. Per evitare che i logs relativi ai suoi commit su GitHub siano attribuiti all'utente unknown, Lino indica a git il suo username; dalla shell di msysgit, al prompt digita

$ git config --global user.name "lino"
$ git config --global user.email lino@example.com

Step 3 - setup delle chiavi ssh

Chi come Lino non ha una coppia di chiavi ssh (!!!) può generarle usando proprio msysgit. Dal menu Start -> Programmi -> Git selezionare la voce Git, si apre una finestra contente la shell; al prompt digitare

ssh-keygen -C “username@email.com” -t rsa

Lino fornisce una password ed accetta le opzioni che il programma suggerisce per il nome e la destinazione dei due files contenenti le chiavi, che finiranno in ~/.ssh/ che tradotto nel path NTFS diventa C:\Documents and Settings\Lino\.ssh. Successivamente bisogna fornire la chiave pubblica a GitHub: basta fare login, editare il proprio account (in alto a destra) e copiare ed incollare il contenuto della chiave pubblica (che è stato salvato in ~/.ssh/id_rsa.pub) nell'apposito box.

Step 4 - Creazione del repository

Ovviamente se il repository già esiste questo step è superfluo. Basta avviare la procedura a questo link: http://github.com/repositories/new e digitare i comandi suggeriti nella shell di msysgit.

Step 5 - Clone del repository (era: cvs checkout)

Per iniziare a lavorare sul repository remoto bisogna effettuare quello che con CVS avremmo chiamato checkout: il clone del repository. Nel pannello di controllo di GitHub, fra i dettagli del proprio progetto, Lino trova il seguente:

Public Clone URL: git://github.com/lino/progettox.git

Dalla shell di msysgit Lino punta sulla cartella di lavoro che conterrà il progetto e poi esegue il cosiddetto clone:

$ git clone git://github.com/lino/progettox.git ProgettoX

Se tutto va bene ora nella cartella di lavoro dovrebbe esserci una nuova cartella chiamata ProgettoX contenente i sorgenti. Siamo operativi, Lino può festeggiare e cominciare ad usare Git proprio come faceva con CVS...

Push delle modifiche (era: cvs commit)

Lino modifica alcuni files nel repository locale clonato da quello su github; per spedire le modifiche sul repository remoto esegue il cosiddetto push. Per prima cosa, Lino esegue un commit locale, come farebbe con CVS:

$ git commit -m"messaggio di commit"

In seguito, come per il link del clone, Lino recupera da GitHub il push url. Poi, dalla cartella ProgettoX:

$ git push git://github.com/lino/progettox.git

Pull delle modifiche (era: cvs update)

Gino ha già fatto il clone del repository su GitHub, per recuperare le ultime modifiche di Lino al progetto esegue il pull:

$ git pull

Considerazioni

L'utilizzo di Git alla maniera di CVS consente agli sviluppatori di cambiare sistema di SCM con il minor sforzo mentale possibile ma, come ci si può aspettare, utilizzare git in questo modo è un po' uno spreco... Git ha l'enorme vantaggio di essere un sistema distribuito, perciò ogni repository locale è un'entità autonoma rispetto al progetto complessivo, vale a dire che Lino può branchare localmente il repository, effettuare delle modifiche per conto suo, tornare sulla master branch (la CVS HEAD) quando collabora col team e ancora ritornare sulla propria branch nel tempo libero. Quando pronto potrà fare un merge della branch locale sulla master locale, e solo successivamente fare il push sul repository remoto... e questo è solo per fare un esempio, le possibilità sono veramente tante!

Riferimenti

Questo post è il risultato di un meshup di articoli e guide che ho letto per far utilizzare GitHub ad un collega Windows-user, di seguito gli originali:

Git Introduction Tutorial
(http://www.kernel.org/pub/software/scm/git/docs/tutorial.html)

Git for CVS users
(http://www.kernel.org/pub/software/scm/git/docs/cvs-migration.html)

Providing your SSH key
(http://github.com/guides/providing-your-ssh-key)

Presi in prestito

Dati in prestito

if (cond)
  a(); b();
b();

Ovvero perchè l'uso delle parentesi nei blocchi condizionali dovrebbe essere preso un po' più sul serio...

Quando qualcuno mi propone una soluzione ad un problema di qualche tipo asserendo che "così sarebbe più facile", spesso cado in uno stato ansiogeno prodotto dalla certezza che in realtà "così smetterà di funzionare". Ma è difficile argomentare quando a supporto della propria teoria si ha solo una "sensazione" - abbiamo bisogno di un metodo quantitativo.

Facendo riferimento alle interfacce di programmazione, Russell propone la teoria del "rendine difficoltoso l'uso scorretto". Il concetto è semplice e facile a dirsi, un pò meno a farsi, ma lui da bravo kernel hacker lo sa bene, quindi ecco la sua ricetta per valutare l'efficacia di un metodo al fine di ottenere interfacce difficili da usare male (l'italiano qui non mi supporta un granchè accidenti). Ovviamente vince chi fa più punti!

Sbagliare è impossibile: 10 punti.
Rientrano in questa categoria le funzioni del tipo fai_questo() o fai_quello(). Ovviamente si può riuscire ad usare male anche queste, ad esempio non chiamandole affatto, ma in linea di massima dovremmo essere al sicuro (i fans del "code by intention" potrebbero contestare l'uso del condizionale ;-) )

Fare in modo che il compilatore (ma pure il linker) ci impediscano di sbagliare: 9 punti.

#define BUILD_BUG_ON(cond) sizeof(char[1-2*!!(cond)])

Così si ottiene una specie di assert a tempo di compilazione, se cond è diverso da zero il codice non compila. Spargete BUILD_BUG_ON in giro per i sorgenti ed il gioco è fatto.

Fare in modo che il compilatore ci avvisi che stiamo sbagliando: 8 punti.
Dai sorgenti del kernel:

/*
* min()/max() macros that also do
* strict type-checking.. See the
* "unnecessary" pointer comparison.
*/
#define min(x,y) ({ \
  typeof(x) _x = (x);    \
  typeof(y) _y = (y);    \
  (void) (&_x == &_y);    \
  _x < _y ? _x : _y; })

Se provate ad invocare min() su due variabili di tipo diverso il compilatore emetterà un warning.

Quello ovvio è (probabilmente) l'uso corretto: 7 punti.
Applicazione del rasoio di Occam alla programmazione. Voi chiamereste la funzione exit() o _exit()? Non deludetemi...

Dare nomi alle cose che dovrebbero suggerirne l'uso: 6 punti.
Ancora dal kernel: la funzione che restituisce il reference count per un modulo a volte può fallire (così va il mondo); Russel fa notare come sia vagamente meglio chiamare tale funzione try_module_get() piuttosto che module_get(). Programmatore avvisato...

Fa' le cosine a modo o schianto: 5 punti.
Se il prim0 venuto tenta di usare la nostra API in malo modo, possiamo inviargli un messaggio subliminale uccidendo l'applicazione a runtime... assert() è nostro amico!

Seguire le convenzioni: 4 punti.
A volte il conformismo paga... Scrivere delle funzioni i cui prototipi presentino gli argomenti in un ordine logico e noto in letteratura è cosa buona, ad esempio in un wrapper di memcpy mi aspetterei di trovare "la destinazione prima della sorgente".

La lettura della documentazione ci impedirà di sbagliare: 3 punti.
Vabè, diciamo solo che se il funzionamento dell'API si basa sulla premessa che bisogna leggere la documentazione siamo messi male...

La lettura dell'implementazione ci impedirà di sbagliare: 2 punti.
Questa credo si commenti da sola!

La lettura del thread appropriato sulla mailing list ci impedirà di sbagliare: 1 punto.
A volte le API hanno interfacce inspiegabilmente strane, e magari il motivo è da ricercarsi in qualche ragione storico-filosofica (tipo, "sui sistemi VAX c'erano solo 6 caratteri per fare questo o quello"), in questi casi chiedere sulla lista o sfogliare le FAQ può aiutare, ma certo l'API di turno non brilla per usabilità!

Per un'introduzione al concetto di "Easy to Use" vs "Hard to Misuse" leggete qui.

warning: unused variable 'pippo'

Ops... misa che è colpa mia! Ed è andata pure bene, visto che non di rado, soprattutto quando le cose non funzionano come dico io, sono solito scrivere cose tipo:

int fava;

Noblesse oblige...

Sempre su quei vecchi sorgenti, e sempre a tempo di compilazione, gcc mi produce pure il seguente:

warning: Worakaround for <descrizione problema>: please remove it some day!

Ancora opera mia...

Mi sovviene allora un aneddoto che ho letto recentemente in Dreaming in Code, dove l'autore Scott Rosenberg a pag. 308 racconta di commenti al codice sorgente di Windows 2000 di questo tenore:

// We have to do this only because Exchange is a moron

Il codice sorgente, quello commerciale in particolare, è spesso lontano da quello che il senso estetico di Donald Knuth percepirebbe come gradevole... E' pur vero che in alcuni casi il naming delle variabili, i contenuti dei commenti, la stesura delle macro del preprocessore rappresentano la valvola di sfogo dello sviluppatore, che in qualche modo dovrà pur esternare il proprio malumore. O il proprio pensiero circa un collega. O la propria bastardaggine:

#define private public

Per approfondire, date una letta qui.

assert(0);

discretamente utile ma poco verbosa, ecco un tip dal cubicolo a fianco:

assert(condizione && "messaggio");

o semplicemente:

assert(!"messaggio verboso");

il che produce l'output seguente:

main.cpp:6: failed assertion `!"messaggio verboso"'

Quick and dirty!

Ultimamente passo le mie giornate al cubicolo occupandomi di un coso che tokenizza, parsa e sperabilemente esegue delle istruzioni contenute in uno script. Niente di strano, se non che recuperando del codice legacy è saltato fuori un pimpl; vedo di spiegare di cosa si tratta così da fornire una certa autoconsistenza al post…

Il pimpl viene spesso definito “idioma”, un costrutto dalle caratteristiche precise che possiamo usare per risolvere problemi noti; è stato formalizzato da Herb Sutter durante uno dei sui quiz per il Guru Of The Week. Nel foglietto illustrativo del pimpl troviamo le seguenti indicazioni:

• L’header file che contiene il pimpl non include altri headers di classi che vengono usate “per valore”, il che comporta tempi di compilazione più rapidi.
• Cambiamenti alla parte privata della classe non comportano la ricomplilazione dei moduli sorgente che dipendendono da questa, anche qui tempi di compilazione più rapidi.
• Favorisce l’incapsulamento.

Sempre nel foglietto illustrativo troviamo le controindicazioni:

• Sviluppo di codice aggiuntivo.
• Il pimpl non può incapsulare dati “protected” eventualmente necessari alle sottoclassi.
• L’ulteriore livello di indirezione introdotto fra la classe ed il suo pimpl impatta le performances (non di molto a dire il vero) e richiede un pò più di attenzione in fase di manutenzione.
• Non possiamo spostare funzioni virtual all’interno del pimpl.

Vediamo un pimpl in azione:

class XImpl; // forward declaration
class X
{
public:
  X();
  ~X();
  // costruttore di copia ed altre amenità...
  void metodoPubblico();
private:
  XImpl* pImpl_;
};

Notate lo stile Hungarian usato per la variabile che incidentalmente da il nome all’idioma stesso!

Ora, osservando la dichiarazione della classe X, possiamo notare il puntatore opaco al pimpl che ci mette al riparo da ricompilazioni selvagge (vedi punto uno dei benefici effetti del pimpl). Approfondiamo il discorso e passiamo all’implementazione:

#include "x.hpp"

class XImpl
{
public:
  XImpl(X* x) : self_(x) {}
  void metodoPrivatoDiX() {}
  void altroMetodo()
  {
    // accedo ad un metodo pubblico di X
    self_->metodoPubblico();
  }

  int membroPrivatoDiX_;
};

X::X() : pImpl_(new XImpl(this)) {}
X::~X() {delete pImpl_;}
void X::metodoPubblico() {pImpl_->membroPrivato_ = 1;}

Notiamo l’utilizzo del pimpl all’interno dei metodi di X, questo sostituisce quella che sarebbe stata una chiamata ad un metodo privato della classe stessa. Ora è evidente come la classe XImpl sia sconosciuta agli utenti di X; questo significa che cambiando XImpl non ricompileremo il mondo intero (punto due della lista benefici). Altra cosa da notare è che il pimpl che ho scritto si tiene un puntatore alla classe X, questo nell’eventualità che XImpl dovesse accedere a metodi pubblici o virtuali di X per svolgere i propri compiti; si tratta di un altro livello di indirezione, ma possiamo conviverci…

Ne vale la pena? Se ci serve, si, se deve rimanere un esercizio di stile meglio investire il tempo in attività più proficue, come ad esempio farsi un caffè. Nel caso del mio coso parserizzatore il pimpl ha isolato Flex e Bison dal resto del codice, producendo una serie piuttosto lunga di vantaggi (fra cui vedi punto tre lista benefici).

Per approfondire:
http://c2.com/cgi/wiki?PimplIdiom
http://www.devx.com/cplus/Article/28105
e naturalmente...
http://www.gotw.ca/gotw/024.htm ]]>