All our thoughts. Broadcasted.

Il Test Driven Development è una tecnica di design del software che permette di scrivere del buon codice con un ampio tasso di coverage di test automatizzati. Esistono diverse librerie per fare questo, generalmente almeno una per linguaggio, basate tutte sul design di SUnit (originariamente xUnit), il framework di test scritto da Kent Beck (ideatore di Extreme Programming).

Non fa eccezione il linguaggio C che possiede diverse librerie di testing, tra cui Check e CUnit. Queste due sono caratterizzate dall’essere implementate in puro C e non in C++ come ad esempio googletest.

Installare CUnit sotto Mac è molto semplice anche se mi ha dato qualche problema dovuto alle numerose piattaforme su MacOs X ha girato nel corso degli anni (nato su PPC, PPC64, portato su i386 e ora x86_64, senza contare universal che racchiude le due famiglie).

Per prima cosa possiamo installare la libreria da MacPort:

1. sudo port install cunit
   MacPort  scaricherà, compilerà e installerà CUnit e libncurses
2. Modificare il path di MacOS X
   Purtroppo l’installazione di port non mi ha aggiunto i path alle librerie e agli include installati tramite MacPort, quindi è necessario modificare il file /etc/paths e aggiungere le seguenti righe:

   /opt/local/
   /opt/local/lib
   /opt/local/include/

3. Riavviare il Mac per rendere attive le modifiche al path
4. A questo punto possiamo provare a compilare il codice di esempio presente sul sito di CUnit con l’accortezza di specificare l’architettura e l’inclusione delle librerie CUnit e Ncurses:

   gcc -lcunit -lncurses -Wall example.c -o example -arch x86_64

5. Il codice di test ora risulta essere compilato e funzionante possiamo lanciarlo con

   ./example

Happy coding!

Ieri un’amica mi ha chiesto di spostare il suo sito da un provider ad un altro.

Ecco alcuni spunti di riflessione che ho trovato spulciando il codice sorgente:

1. DRY up your code (Don’t Repeat Yourself)
   Nel codice erano presenti 4 punti dove modificare i parametri di accesso al database, non era molto più semplice mettere tutto in un file di configurazione separato?
2. Ancora:  DRY up your code (Don’t Repeat Yourself) e Anti-If (e qui siamo ai livelli di CodingHorror)
   Il codice che impostava la home page nel caso non ci fossero richieste specifiche era una interminabile catena di if.

Ecco qui un bel esempio da non seguire:

$pid=$HTTP_GET_VARS['pid'];
if($pid ==  '0' ||
   $pid ==  '1' ||
   $pid == '11' ||
   $pid ==  '2' ||
   $pid ==  '3' ||
   $pid ==  '4' ||
   $pid ==  '5' ||
  .....
) {
  ;
}else{
  $pid = '0';
}

Bene, proviamo a rifattorizzare un pò questo codice e renderlo in po più flessibile:

1. Creiamo un array di ‘pagine’

   $authirizedPages = array('0', '1', '11', '2', '3', '4', '5',.......);
   $pid = '0';
   if(in_array($HTTP_GET_VARS['pid'], $authirizedPage)){
     $pid =$HTTP_GET_VARS['pid'];
   }

   A questo punto il codice è già molto più flessibile rispetto a prima, basta modificare l’array di pagine autorizzate.

2. Il passo successivo è rendere indipendente il codice dalla base dati

   $authirizedPages = mysql_fetch_array( mysql_query( 'SELECT id FROM pages' ));
   $pid = '0';
   if(in_array($HTTP_GET_VARS['pid'], $authirizedPage)){
     $pid =$HTTP_GET_VARS['pid'];
   }

3. Ora possiamo anche eliminare una variabile:

   $pid = '0';
   if(in_array($HTTP_GET_VARS['pid'], mysql_fetch_array( mysql_query( 'SELECT id FROM pages' )))){
     $pid =$HTTP_GET_VARS['pid'];
   }

   A questo punto potremmo anche fermarci, il codice è molto più compatto e flessibile rispetto a prima e l’aggiunta di una pagina comporta semplicemente l’aggiunta di un record sul database e nessuna modifica al codice. Questa è e deve essere una buona norma! Codice indipendente e non ripetuto!

Qualunque suggerimento ovviamente è ben accetto, solo in questo modo è possibile migliorarsi.

Ciao
P

Recently I’ve developed a very funny website with wordpress and a lots of plugins.
With my surprise, after a coupe of week of correct working, some users told me that, after the login with facebook connect, all the site contents, such as menus and posts, aren’t accessible.

That’s is caused by an incompatibility issue between Role Scoper and wp-facebookconnect plugins.
I think that after login Role Scoper don’t recognize the user level of the registred Facebook Users, and so revoke all the permission to them.

My solution consists to decrease the Wp Facebook Connect hooks execution priority to zero:

• Open wp-contents/plugins/wp-facebookconnect/fbconnect.php
• Find the line 93

  add_action('init', 'fbc_init_auth');

  this line add an action to wordpress init hook

• Decrese the priority of the action adding the priority option after the action name

  add_action('init', 'fbc_init_auth', 0);

• Save and now everything is working fine

Ultimamente ho trovato molto utili o interessanti queste librerie:

Ruby Graph Library
Implementa una struttura dati a grafo, sulla quale e’ possibile applicare tutti gli algoritmi piu’ comuni sui grafi. Ogni istanza nodo possiede i metodi per aggiungere archi e collegare altri nodi, per gestire vertici, e ciclare sul grafo (anche l’iteratore non e’ ottimizzato)

Skynet
Skynet implementa MapReduce di Google. MapReduce e’ un modello di programmazione e di elaborazione di dataset enormi. Ecco come Google vi da istantaneamente i risultati della vostra ricerca su un database che rappresenta gran parte di internet. Grazie a questa libreria e’ possibile eseguire processi paralleli su piu macchine. Non solo, estendendo ActiveRecord permette facilmente di utilizzare MapReduce nella vostra applicazione Rails.

RubyProf
RubyProf e’ un profilatore delle applicazioni scritte in Ruby, evidenzia i colli di bottiglia e permette di analizzare, attraverso i grafici prodotti, le prestazioni di un determinato segmento di codice.

Bye
Piero