[GIT] Configurazione di una repository Git

Continuiamo la trattazione sul versioning in Git, richiamando un altro post scritto sull’argomento su questo sito:

Qui viene spiegata la procedura di configurazione locale e remota di una repository Git. Servizi online di hosting molto famosi per il versionamento del vostro codice, gratuiti e a pagamento, sono GitHub, Assembla e BitBucket. Io personalmente utilizzo i primi due: su GitHub versiono i progetti “free” (visto che per renderli privati si paga), su Assembla quelli che voglio rendere privati.

git

Vi linko a tutorial per il versioning su Git, per maggiori approfondimenti:

Vediamo ora gli step per il versionamento su Git. Io uso il Terminale su MacOx, ma la procedura funziona allo stesso modo su Windows, anche se per la generazione delle chiavi SSH dovrete aiutarvi con altri programmi, come Putty.

1. Generazione delle chiavi SSH. Le chiavi SSH servono per stabilire una connessione sicura tra il vostro pc e l’account remoto della repository Git, permettendovi anche l’autenticazione. Dopo aver generato le chiavi sul vostro account remoto (GitHub, per esempio), dovrete copiare nelle Impostazioni la chiave pubblica generata.

cd ~/.ssh
# Ci si sposta nella directory ".ssh" presente sul pc. Se non c'è occorre crearla.

Si generano le chiavi, lanciando il comando ssh-keygen da terminale:

ssh-keygen -t rsa -C "your_email@example.com"
# Crea una nuova chiave SSH con il tuo indirizzo email

# Genera la coppia di chiavi rsa ssh pubblica e privata. A video uscirà un messaggio del genere:
# Enter file in which to save the key (/Users/you/.ssh/id_rsa): [Press enter]
# se non digiti nulla e premi invio, verrà salvata la chiave privata nel file id_rsa della cartella .ssh

Il terminale chiederà anche la passphrase, ossia la password:

Enter passphrase (empty for no passphrase): [Type a passphrase]
# Enter same passphrase again: [Type passphrase again]

Il comando genererà la coppia di chiavi pubblica e privata.

Your identification has been saved in /Users/you/.ssh/id_rsa.
# Your public key has been saved in /Users/you/.ssh/id_rsa.pub.
# The key fingerprint is:
# 01:0f:f4:3b:ca:85:d6:17:a1:7d:f0:68:9d:f0:a2:db your_email@example.com

A questo punto, digitate il seguente comando per copiare la chiave pubblica, da incollare poi nelle Impostazioni dell’account della vostra repo Git (per esempio, su GitHub, vi è la sezione “Add SSH keys” delle Impostazioni Account):

pbcopy < ~/.ssh/id_rsa.pub
# Copia il contenuto del file id_rsa.pub negli Appunti

Eccovi un riferimento utile per questo step: Generating SSH Keys

2. Installazione di Git. Se non già presente, dovete installare Git sul vostro pc (per capire se è già preinstallato, basta lanciare il comando git sul terminale e vedere se vi elenca i vari comandi previsti dal protocollo). L’installazione è molto semplice: basta scaricare l’ultima release da questo link (Git). Altro riferimento utile per questo step: Set Up Git

3. Creazione di una repository. La prima cosa da fare è creare una repository sull’account remoto (di GitHub o Assembla, per esempio). Lì salverete il contenuto del vostro progetto, sincronizzandolo di volta in volta dai vostri pc. Riferimento: Create a repo.

Adesso passiamo alla configurazione della repo GIT locale alle vostre macchine. Spostatevi con il terminale in corrispondenza della directory root del vostro progetto oppure create una directory di progetto da zero. Per esempio:

mkdir ~/Hello-World
# creo una directory di progetto "Hello-World" nella cartella Users

cd ~/Hello-World
# mi sposto in corrispondenza della cartella di progetto appena creata

git init
# inizializzo la cartella di progetto come repository GIT. 
# Ecco il messaggio che vi verrà visualizzato:

# Initialized empty Git repository in /Users/you/Hello-World/.git/

# creo un file README, in cui inserire le informazioni sul progetto
touch README

# committo il file README creato
git add README
# il comando ADD mette il file README nell'area "stage", ossia non è ancora commitato

git commit -m 'first commit'
# committo le modifiche della repository, lasciando il messaggio "first commit"

Se avete inserito (o erano già presenti) altri file/directory nella directory di root (oltre README), allora dovete aggiungerli tutti nell’area “stage”, prima di committarli, con il comando ADD:

# aggiungo tutti i file all'area "stage"
# dopo l'add metto il punto (.)
git add .

git commit -m 'new commit'

Infine, per salvare il tutto sulla repo remota, ecco i comandi:

git remote add origin https://github.com/username/Hello-World.git
# creo una "origin" remota sulla repository GitHub

git push origin master
# mando i commit al branch "master" su GitHub

[iOs] Paginare i dati di una UITableView

Vi condivido il codice che ho messo su una repo di GitHub, utile per la paginazione dei dati caricati in una UITableView. Questa feature è molto comoda, quando dovete caricare troppi dati da un vostro servizio online e, dunque, la fase costituita dalla chiamata remota stessa, il fetching dei dati e il popolamento delle celle della vostra UITableView potrebbe risultare alquanto onerosa, se non addirittura far crashare la vostra app.

Ecco il link al progettino: https://github.com/fficetola/PaginationScroller

Prima di entrare nel vivo del codice, vi scrivo qui cosa viene fatto nell’app di esempio:

  • viene inizializzata una UITableView e nel metodo loadData, viene fatta una chiamata remota ad un servizio PHP di test (che vi ho anche condiviso nella cartella php-example-paging);
  • l’output in JSON del servizio di test lo potere vedere qui: http://francescoficetola.it/ios-test/test-paging.php?idx_last_element=0&block_size_paging=2. Nel servizio PHP di test, vengono passati due parametri: idx_last_element, ossia l’indice del primo elemento della lista di dati da cui si vuole partire, e block_size_paging, ossia il numero massimo di elementi che si vuol far restituire a partire dall’indice richiesto (nell’esempio precedente, si richiedono i primi 20 risultati dal primo elemento della lista, con indice 0). Il servizio PHP genera 100 elementi e, dunque, se si richiedono 20 elementi per volta, il numero massimo di pagine restituite sarà 5 (total_pages, è il numero massimo di pagine calcolate e restituite per la paginazione, current_page è la pagina corrente del blocco di dati richiesti)
  • Lato app, si intercetta il JSON di risposta e si “fetchano” i dizionari in singoli oggetti di tipo Object. 
  • Quando si scrolla la UITableView fino all’ultima cella, viene visualizzata una UIActivityIndicatorView, che scompare soltanto quando sono stati caricati altri blocchi di dati (si richiama, infatti, il metodo loadData).

Ecco il metodo della UITableView in cui vi è la vera e propria logica di paginazione:

- (void)tableView:(UITableView *)tableView willDisplayCell:(UITableViewCell *)cell forRowAtIndexPath:(NSIndexPath *)indexPath {

    //check last cell in uitable
    if(indexPath.row==self.objects.count-1){

        //Create and add the Activity Indicator to splashView
        UIActivityIndicatorView *activityIndicator = [[UIActivityIndicatorView alloc] initWithActivityIndicatorStyle:UIActivityIndicatorViewStyleGray];
        activityIndicator.alpha = 1.0;
        //activityIndicator.center = CGPointMake(160, 360);
        activityIndicator.hidesWhenStopped = NO;
        [activityIndicator startAnimating];

        self.tableView.tableFooterView = activityIndicator;

        //arrest condition
         if(_currentPage<_totalPages){

             _lastIndex = indexPath.row+1;
             //timer...
             [NSTimer scheduledTimerWithTimeInterval:0.1 target:self selector:@selector(loadData) userInfo:nil repeats:NO];

         }
         else{
             [activityIndicator stopAnimating];
             self.tableView.tableFooterView = nil;
         }

         [activityIndicator release];

    }
}

Il metodo willDisplayCell scatta per tutte le celle della UITableView, ogniqualvolta ognuna di queste viene visualizzata. Poiché a noi interessa rilevare soltanto quando è stata visualizzata l’ultima cella della tabella, vi è il seguente controllo:

if(indexPath.row==self.objects.count-1)

In tal caso, viene aggiunto nel footer della UITableView un UIActivityIndicatorView e, se non è verificata la condizione di arresto della paginazione, viene fatta una chiamata al metodo loadData in cui si richiama di nuovo il servizio remoto per la restituizione di un nuovo blocco di dati a partire dal lastIndex aggiornato.

Per determinare la condizione di arresto della paginazione, si va a controllare se la pagina corrente caricata (currentPage) sia l’ultima (totalPage):

if(_currentPage<_totalPages)

Se non si verifica tale condizione, viene eliminato lo spinner dal footer e viene terminata la paginazione (non viene più richiamato il metodo loadata).

UITableView pagination

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2013/03/31/ios-paginare-i-dati-di-una-uitableview/.

[iOs] Far votare o recensire un’app su Apple Store con Appirater

Volete invitare l’utente a lasciare un voto o una recensione sulla vostra app su Apple Store? Sono diverse le librerie che permettono di fare il rating, ma tutte di terze parti.

La libreria che vi consiglio, che è anche quella più utilizzata per tale scopo, è Appirater, di cui trovate una presentazione sul sito ufficiale del creatore:

http://arashpayan.com/blog/2009/09/07/presenting-appirater/

Il codice è scaricabile direttamente da GitHubhttp://github.com/arashpayan/appirater/

AppiraterScreenshot

Cosa vi permette di fare Appirater:

  • chiedere all’utente se vuole recensire e votare la vostra app su Apple Store, visualizzando una popup con opzioni
  • permettere di impostare quando visualizzare la popup, se dopo N giorni dall’installazione dell’app (o sua nuova release) sul device oppure dopo N utilizzi (uses) dell’app stessa
  • permettere di posticipare la recensione da parte dell’utente, ricordandogli di farlo dopo N giorni
  • oppure, se l’utente non vuole recensire l’app, “ricordare” tale opzione e non visualizzare più il messaggio di popup
  • i messaggi della popup sono localizzabili in varie lingue (compreso italiano)

Le opzioni sono configurabili nel file Appirater.h e le vedremo in dettaglio dopo aver definito come installare la libreria.

Installazione

  1. Scaricare da GitHub la libreria ed importare tutti i suoi file (comprese le cartelle delle lingue .lproj che vi interessano) nel vostro progetto
  2. Se utilizzate l’ARC (Automatic Reference Counting), poiché la libreria è un pò vecchiotta e non utilizza l’ARC, dovete marcare il file Appirater.m con il flag -fobjc-arc (basta andare sulla root del progetto, selezionare il target e nella scheda Build Phases » Compile Sources, in corrispondenza della classe Appirater.m, inserire il flag su citato cliccando due volte su tale classe)
  3. Aggiungete al vostro progetto i seguenti framework (sempre nella scheda Build Phases, sezione Link Binary with Libraries): CFNetworkSystemConfiguration e StoreKit. Assicuratevi di cambiare da Required ad Optional il flag del framework StoreKit, sempre nella sezione Build Phases » Link Binary with Libraries del target.
  4. Infine, potete utilizzare Appirater direttamente nel vostro AppDelegate.m, in corrispondenza del metodo application:didFinishLaunchingWithOptions:

Utilizzo. Un esempio di utilizzo di Appirater è il seguente: 

    //call the Appirater class
    [Appirater setAppId:YOUR_APPID];
    [Appirater setDaysUntilPrompt:1];
    [Appirater setUsesUntilPrompt:10];
    [Appirater setSignificantEventsUntilPrompt:-1];
    [Appirater setTimeBeforeReminding:2];
    //[Appirater setDebug:YES];
    [Appirater appLaunched:YES];

Tale codice è stato inserito nel metodo dell’AppDelegate application:didFinishLaunchingWithOptions:

Potete settare una serie di opzioni o come fatto nell’esempio precedente o modificando i valori di default dell’interfaccia Appirater.h.

Importante è inserire l’AppID della vostra app, così come visualizzata nelle informazioni relative all’app stessa sull’account di iTunesConnect. Per farvi rilasciare un AppID dovete aver pubblicata una vostra app sullo store o almeno registrato tutte le sue informazioni lì prima dell’invio ad Apple per l’approvazione.

Tra le opzioni che possiamo settare abbiamo:

  • + (void) setAppId:(NSString*)appId; permette di settare l’AppID dell’app (da prelevare su iTunesConnect)
  • + (void) setDaysUntilPrompt:(double)value;  setta il numero di giorni da quando è installata l’app (o una sua nuova release) dopo i quali visualizzare la popup di rating
  • + (void) setUsesUntilPrompt:(NSInteger)value; setta il numero degli “usi” (uses) dopo i quali si chiede all’utente se vuole votare. Un uso potrebbe essere il fatto che l’app si apra in primo piano nel device.
  • + (void) setSignificantEventsUntilPrompt:(NSInteger)value; setta il numero di eventi significativi prima di chiedere all’utente se vuol fare il rating
  • + (void) setTimeBeforeReminding:(double)value; setta il numero di giorni prima di rivisualizzare la popup di rating (una sorta di promemoria)
  • + (void) setDebug:(BOOL)debug; questa opzione è comoda per gli sviluppatori, perché consente di visualizzare immediatamente la popup per poter fare test o sviluppo. Tale opzione è da disabilitare quando si rilascia l’app sullo store.

Eccovi un altro riferimento utile (stavolta in italiano): http://www.htmedia.it/2012/03/tip-ios-31-chiediamo-una-recensione-con-appirater/

Buon rating!

CodeMotion 2013 a Roma: i giorni 22 e 23 Marzo

Codemotion2013

Programmare è un’arte. Sbaglia chi pensa che sviluppare software sia un’attività meccanica, sempre uguale, senza stimoli o fantasia. Noi ci mettiamo testa ma soprattutto cuore.

Anche quest’anno, non posso che consigliarvi l’appuntamento al CodeMotion all’Università Roma Tre, incontro ormai abituale per chi è appassionato di tecnologie di IT, che si terrà il 22 e il 23 Marzo prossimo.

In realtà l’evento dura più di due giorni (dal 20 Marzo al 23), perché si terranno anche dei workshop interessanti (peccato che capitino durante la settimana!).

Iscrivetevi all’evento qui: http://rome.codemotionworld.com/evento/conferenza/

PROGRAMMA: 

Google Developer Group (GDG) Lazio-Abruzzo

Propongo agli sviluppatori particolarmente spinti verso l’innovazione tecnologica, questa interessante iniziativa:

Google Developer Group (GDG) Lazio-Abruzzo – Idee e tecniche per sviluppatori interessati a tecnologie innovative

Google-Developers

Cosa significa GDG L-Ab?
gdg-labGoogle Developers Group Lazio Abruzzo. In pratica persone a Roma e dintorni che fabbricano software e si inventano applicazioni Web e Mobile (non solo Google) … e che si divertono a farlo.Gente che cerca innovazione per creare ulteriore innovazione, non solo tecnologica, ma anche sociale.I GDG sono in tutta Italia e nel Mondo, sono indipendenti e liberi ma aiutati e coordinati da
Google.

Ecco i siti di riferimento:

Creative Commons License
This work by Francesco Ficetola is licensed under a Creative Commons Attribution 4.0 International License.
Based on a work at www.francescoficetola.it.
Permissions beyond the scope of this license may be available at http://www.francescoficetola.it/2013/01/24/google-developer-group-gdg-lazio-abruzzo/.

[iOs] Il Logging nelle nostre app con le Preprocessor Macros

Prima di un rilasciare una app iOS su Apple Store, è buona prassi fare un pò di pulizia dei log sparsi nel codice. Molti sviluppatori, infatti, sono restii all’utilizzo del debug e preferiscono utilizzare, man mano che sviluppano, la classe NSLog e farsi stampare gli output sulla console. Dunque, i nostri progetti rimangono pieni di NSLog che, tuttavia, è meglio non rilasciare sulle app in esercizio. Il motivo è dovuto al fatto che la scrittura dei log è onerosa e potrebbe ridurre le performance della nostra app. Inoltre, anche se la console del device è nascosta all’utente, potremmo dimenticare di loggare informazioni sensibili … e ciò è “no buono”.

Ho letto un pò di articoli a riguardo, tra cui i seguenti:

Ecco la procedura che ho seguito, utilizzando le Preprocessor Macros. L’idea è quella di inserire un flag (-DDEBUG) nella configurazione di DEBUG del nostro progetto e importare nelle nostre classi un log “custom” (DLog oppure ALog).

  • Per prima cosa, inserite un file Log.h nel vostro progetto con il seguente contenuto:
#ifdef DDEBUG

#   define DLog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);

#else

#   define DLog(...)

#endif

// ALog always displays output regardless of the DEBUG setting

#define ALog(fmt, ...) NSLog((@"%s [Line %d] " fmt), __PRETTY_FUNCTION__, __LINE__, ##__VA_ARGS__);
  •  Poi spostatevi nella configurazione del vostro progetto (click sulla root di progetto, selezionate Targets e poi spostatevi nella scheda Builds Settings). Qui, cercate la voce “Other C Flags” e inserite il flag -DDEBUG in corrispondenza della configurazione di DEBUG.

  • NOTA. Il punto precedente non è necessario se in Log.h si va a controllare il valore del flag nativo DEBUG (che è true se siamo in ambiente di debug, false quando si è in modalità Release/Ad Hoc), anzichè DDEBUG (che è una nostra variabile “custom”)
    #ifdef DEBUG
  • Importate l’interfaccia Log.h nel file di progetto <YourApp>_Prefix.pch, in modo da rendere visibile la macro in tutte le classi (senza importare esplicitamente la macro ogni volta). Nel mio caso, ecco il contenuto del .pch:
#import <Availability.h>
#import "Log.h"

#ifndef __IPHONE_5_0
#endif

#ifdef __OBJC__
	#import <UIKit/UIKit.h>
	#import <Foundation/Foundation.h>
#endif
  • Infine, potete utilizzare i log “custom” normalmente come fareste con NSLog, come segue:
 DLog(@"Logging %d con %@",1, @"DLog");
 ALog(@"Logging %d con %@",2, @"ALog");

Eccovi l’output di esempio delle precedenti righe di log:

2012-12-25 15:03:16.276 MyApp [4451:907] -[AppDelegate application:didFinishLaunchingWithOptions:] [Line 33] Logging 1 con DLog
2012-12-25 15:03:16.281 MyApp [4451:907] -[AppDelegate application:didFinishLaunchingWithOptions:] [Line 34] Logging 2 con ALog

DLog e ALog, per come sono stati configurati nel Log.h, stampano anche il nome della classe, il metodo e la riga di codice in cui si trovano. ALog stampa anche se non siamo in DEBUG (quindi, come NSLog, loggherebbe anche quando abbiamo rilasciato l’app su Apple Store o con una distribuzione “ad hoc”).

Quindi, lanciando la vostra app in DEBUG (sia sul Simulatore che sul device) vi troverete i log stampati sulla console. In Release (sia su App Store che su una distribuzione “ad hoc” dell’IPA) non verrà loggato nulla sul device dell’utente, se avete utilizzato DLog (e non ALog oppure NSLog).

Un pò di sapere è pericoloso: “Ars longa, vita brevis”

Da quando ho messo su questo blog articoli tecnici, mi arrivano spesso mail per informazioni sulla risoluzione di problemi di programmazione, soprattutto quelli legati all’iOS di Apple, visti alcuni processi “rognosi” in cui spesso ci si sbatte.
La mia idea è che si sta procedendo verso quella che definirei “standardizzazione” del linguaggio, che facilita la programmazione, portando anche i non esperti del settore a “cimentarsi” nello sviluppo dei software.

Quella che scrivo è una riflessione che si può applicare ai settori lavorativi più disparati, ma che qui vorrei particolareggiare per quello in cui opero, quello dello sviluppo di software appunto.

Innanzitutto, parto da una citazione famosa di Socrate: “Scio ne sapio” (“Io so di non sapere”). La citazione è rivolta (e venne rivolta) con un atteggiamento polemico contro coloro che pretendono di sapere troppo. Ma il “non” sapere è uno stato normale dell’uomo.
La presente riflessione è nata dopo aver letto una mail, e di cui qui vi riporto un estratto:

[…] So utilizzare abbastanza bene Windows 7; non sono un programmatore, ma mi interesserebbe prendere delle lezioni sull’utilizzo dello smartphone e tablet Apple (rispettivamente iPhone e iPad). Sono appassionato di questi apparecchi, ma non so utilizzarli. […]

Cosa ho pensato? La curiosità è lecita, ma non si può pretendere di imparare a programmare così da un giorno all’altro e, sicuramente, non è il caso di partire da Objective-C per farlo.

Il punto di partenza potrebbe essere quello di trovare un “linguaggio padre”, come può essere C/C++/Java per i linguaggi “tipati” o Python/PHP per quelli “non tipati”.
L’importante è iniziare a pensare alla programmazione. Non programmare.

Mi ha molto affascinato l’articolo di Peter Norvig (padre dell’intelligenza artificiale) dal titolo: “Teach Yourself Programming in Ten Years“, e di cui riporto il link all’ottima traduzione di Fabio Tessitore): Imparara a programmare in 10 anni…perchè vanno tutti di fretta?

Vi invito a leggerlo tutto di un fiato. Io da qui ho estrapolato le seguenti frasi/citazioni:

  • La conclusione è che le persone vanno molto di fretta quando devono imparare qualcosa sui computer, oppure che i computer sono qualcosa di favolosamente facile da imparare rispetto a qualsiasi altra cosa.
  • Non ci sono libri su come studiare Beethoven, la Fisica dei Quanti o perfino l’Addestramento dei Cani in pochi giorni.
  • Come disse Alexander Pope, “un po’ di sapere è pericoloso“.
  • Qual è il punto? Alan Perlis una volta disse: “Un linguaggio che non influenza il modo di pensare la programmazione, non vale la pena di essere conosciuto. È possibile che debba imparare una piccola parte del C++ (o più probabilmente, qualcosa del tipo JavaScript o Flash) perché hai bisogno di interfacciarti con qualcosa di esistente per portare a termine un compito specifico. Ma allora non stai imparando a programmare; stai imparando a completare quel compito”.
  • Alcuni ricercatori (Bloom (1985), Bryan & Harter (1899), Hayes (1989), Simmon & Chase (1973)) hanno dimostrato che sono necessari circa dieci anni per sviluppare esperienza in una gran varietà di campi, inclusi il gioco degli scacchi, la composizione musicale, la telegrafia, la pittura, il suonare il pianoforte, il nuoto, il tennis, le ricerche in neuropsicologia e in topologia.
  • La chiave è la pratica intenzionale: non semplicemente farlo ancora e ancora, ma impegnarsi in un compito appena oltre le proprie abilità, provare, analizzare il proprio rendimento mentre e dopo l’esecuzione e correggere gli errori. Quindi ripetere. E ripetere ancora. (Vedi l’articolo “Lo sgobbone batte l’intelligente“)
  • Samuel Johnson (1709-1784) pensava ci volesse anche di più: “L’eccellenza in un campo qualsiasi può essere raggiunta solo attraverso il lavoro di una vita; non si può acquistare ad un prezzo inferiore“. E Chaucer (1340-1400) aggiunse La vita è così breve, l’arte così lunga da imparare. Ippocrate (c. 400 AC) è noto per la massima “Ars longa, vita brevis“, che è parte della citazione più lunga “Ars longa, vita brevis, occasio praeceps, experimentum periculosum, iudicium difficile, che in Italiano suona come” –  [La vita è breve, l’arte è lunga, l’occasione è fugace, l’esperienza ingannevole, il giudizio difficile]. Sebbene in Latino, “ars” può significare sia arte che mestiere, nell’originale Greco la parola “techne” significa solo abilità, non arte.
  • Lavora su progetti insieme ad altri programmatori. Sii il miglior programmatore in alcuni progetti; sii il peggiore in altri. Quando sarai il migliore potrai testare le tue abilità di guidare un progetto e ispirare gli altri con la tua visione. Quando sarai il peggiore imparerai cosa fanno i maestri, e cosa non piace fare loro (perché lo faranno fare a te).
  • Perlis dice che i migliori hanno un talento che prescinde dall’allenamento. Ma da dove viene questo talento? È innato? O viene sviluppato con la diligenza? Auguste Gusteau (lo chef di Ratatouille) dice: “Tutti possono cucinare, ma solo gli impavidi possono essere grandi.” Penso sia volontà di dedicare una larga parte della propria vita alla pratica. Ma forse “impavidi” è un termine per sintetizzare questo concetto. Oppure, come dice Anton Ego, il critico di Gusteau: “Non tutti possono diventare grandi artisti, ma un grande artista può venir fuori da ovunque“.

Non c’è altro da aggiungere penso. Occorre aver la coscienza di non sapere le cose, per studiarle, provarle e confrontarsi con gli altri, migliorandosi continuamente. Comunque, il segreto per sopportare lo sforzo è quello di fare le cose con passione.

 

[CleanCode] Il test di Joel: 12 domande per migliorare il tuo codice

Hai mai sentito parlare del SEMA? Si tratta di un sistema, piuttosto esoterico a dire il vero, per misurare l’abilità di un team di sviluppo di software. No, aspetta! Non cercare di informarti sul SEMA! Ti ci vorrebbero almeno sei anni solo per cominciare a capire di che si tratta. Così ho preferito inventarmi il mio personalissimo, poco scientifico e inadeguato test per la valutazione della qualità di un team di sviluppo software. La cosa interessante di questo test è che richiede al massimo tre minuti, così con tutto il tempo che puoi risparmiare puoi iscriverti a un corso di medicina.

Il test di Joel

  1. Utilizzi un prodotto per il controllo del versioning dei file?
  2. Riesci a compilare un intero programma con un solo comando?
  3. Crei almeno una build al giorno?
  4. Hai un sistema di gestione dei bug?
  5. Sei solito risolvere i bug prima di scrivere del nuovo codice?
  6. Hai un programma di sviluppo aggiornato?
  7. Hai un documento di specifiche?
  8. I tuoi programmatori lavorano in un ambiente tranquillo?
  9. Ti servi dei migliori prodotti presenti sul mercato?
  10. Hai dei tester nel tuo team?
  11. Durante il colloquio, fai scrivere del codice a chi si presenta per far parte del tuo team?
  12. Fai eseguire dei test di usabilità a sorpresa?

La cosa interessante del Test di Joel, è che ti permette facilmente di dare una risposta a ogni domanda, sia essa sì o no. Non hai bisogno di immaginarti il numero di righe di codice che sei in grado di produrre al giorno, o il numero medio di bug che riesci a chiudere. Basta che assegni al tuo team un punto per ogni “sì”. Purtroppo, la cosa brutta di questo test è che non dovresti assolutamente utilizzarlo, in modo da evitare possibili svenimenti.

Un punteggio complessivo di 12 rappresenta la perfezione, 11 è invece tollerabile, ma realizza 10 o meno e stai certo che andrai incontro a problemi piuttosto seri.
La verità, purtroppo, è che la maggior parte dei team di progetto realizza punteggi compresi tra 2 e 3 e ha bisogno veramente di un grande supporto, dato che compagnie come Microsoft viaggiano a ritmi da 12 a botta.

È ovvio che quelli elencati non sono gli unici fattori che concorrono al successo o al fallimento di un team: per esempio, qualora avessi a disposizione un team eccezionale per la realizzazione di un software che comunque non interessa a nessuno, bé la gente non lo acquisterebbe lo stesso.
Ed è anche possibile che un team di imbranati, incapace a rispondere affermativamente a una sola delle mie domande, riesca comunque a produrre un software fantastico, capace di cambiare il mondo. In ogni modo, non considerando questi fattori esterni, è un dato di fatto che se ottieni un 12 secco, potrai contare su un team disciplinato e capace di consegnare il prodotto in qualunque momento.

Continua la lettura