Le slide che seguono sono da ritenersi più un how-to e best practice sull’utilizzo dei due strumenti.

Mi auguro che il materiale sia di vostro gradimento.

Per riuscire però ad effettuare i commit attraverso il Proxy che non consente l’acceso ssh al server github.com ho fatto diverse ricerche su internet, provando le più diverse strade.

C’era chi suggeriva di creare un file wrapper per il proxy seguendo un procedimento alquanto semplice:

• Installare netcat
• creare uno script da shell collocandolo nella directory bin/ dell’utente che riportava in sintesi questo comando “nc -x${PROXY_IP}:${PROXY_PORT} -X5 $*“
• configurare il parametro core.gitproxy indicando il nome del file precedentemenet creato.

Per me non ha funzionato e comunque questa procedura a mio avviso poteva essere  semplificata ulteriormente utilizzando questi due semplici comandi eseguiti da shell.

EXPORT http_proxy=http://myproxy:8080
EXPORT https_proxy=http://myproxy:8080

Non li metterei come valori persistenti perchè, usando il notebook su diverse reti rischierei di non raggiungere il proxy specificato con conseguenza dell’interruzione della navigazione.

Comunque non ha funzionato. Quindi ho cercato una nuova soluzione al problema.

Un altro sito suggeriva di usare l’url proposto da github nella versione https al posto di quello ssh.

Ho fatto un tentativo e non riuscivo nemmeno a clonare il repository remoto ricevendo come risposta “warning: remote HEAD refers to nonexistent ref, unable to checkout.“. Quindi ho temuto che fosse un problema del mio repository remoto. Per fortuna anche con il repository di JQuery mi segnalava lo stesso errore. E lo faceva con qualsiasi repository provassi a clonare. Quindi il repository non aveva problemi.

Ho provato a fare un mix tra le soluzioni “installazione netcat” e “https al posto di ssh” ma comunque non ho avuto il risultato sperato quindi ho continuato nella ricerca della soluzione fino ad incappare in questa discussione!

Grazie a quanto è scritto nella discussione precedente ho cominciato a fare un po’ di prove giocando sull’url per la richiesta del repository.

La soluzione in fondo era più semplice di quanto si pensasse.

Partendo dall’url di aggiornamento del repository fornito da github in formato https (https://user@github.com/user/repository.git), ho inserito anche la password dell’account github e ho fatto viaggiare la richiesta su protocollo http (non sicuro). Quindi l’url utilizzato in fine è stato:

http://user:password@github.com/user/repository.git

In questo modo ha funzionato tutto correttamente e sono libero di aggiornare il mio framework da, come direbbero gli americani, “ognidove”! :)

Mi domando quindi perchè non potrei partecipare anche io al dibattito nazionale? Non sarò un esperto di economia ma, visto che parlano tutti di economia, penso di non aver minor diritto di altri a chiacchierare. Non lo farò con la voce ma ci proverò con questo articolo sul mio blog. Almeno non sarete costretti ad ascoltarmi!

Non mi soffermerò a lamentarmi dei parlamentari che guadagnano 2 volte quello che guadagnano gli altri parlamentari in altri paesi d’Europa. Una persona che lavora al servizio del paese merita ogni centesimo che prende, se lavora bene.

Non voglio raccontare del sistema Europa che non vuole salvare l’Italia o del conto alla rovescia che ci separa dal defaul in stile profezia Maya.

Non voglio lamentarmi delle pensioni, perchè, già quando iniziai a lavorare, ero consapevole che quanto versavo nelle casse dell’ente previdenziale sarebbe andato a favore dei pensionati attuali e che il Paese non avrebbe potuto garantirmi alcuna pensione,  trovandosi l’Italia in una fase di invecchiamento.

Io ho voglia di chiacchierare in materia di evasione fiscale. Questa trascurata materia per la quale tutti dicono che è complicato. Lo sarà certamente non lo metto in dubbio ma sono un po’ perplesso su come si apporccia al problema.

Dunque, l’ammontare dell’evasione fiscale in italia è mediamente del 38%, ovvero 275.000 miliardi di euro (!!!). Magari saranno miliardi di lire? Può darsi, non sono un esperto di finanza, allora vuol dire che l’evasione fiscale in italia ammonta a circa 150 Miliardi di Euro? Ovvero 6 volte la manovra “Salva Italia” varata dal Governo Monti!!!

Beh, io sarò un semplicione, un superficiale e uno che fantastica troppo ma… se il Governo consentisse anche ai privati di scaricare l’IVA che scenario si presenterebbe?

Sì la prima cosa che salterebbe all’occhio è che l’IVA è uno degli incassi più redditizi che lo stato ha e quindi se si toglie quella è tutto il sistema che va a gambe all’aria.

Però se la persona potesse scaricare il costo di un bene, un servizio o quanto altro così come fanno le aziende e poi scaricare (o meglio recuperare) una parte dell’IVA versata alle casse dello stato (anche un misero 20% di quanto viene anticipato in fase d’acquisto, ovvero il 2.5% di quel 21% attuale), chiunque vorrebbe ricevere fattura, scontrino e ricevuta per qualsiasi servizio ricevuto!

Gli evasori sarebbero costretti ad uscire allo scoperto perchè a quel punto sarebbero denunciati direttamente da chi riceve il servizio! Non credete?

Avrò detto tante cavolate sicuramente e me ne scuso con gli economisti, politici e affaristi di ogni sorta, ma un cittadino onesto che paga le tasse e rispetta la legge ha tutto il diritto di dire la sua! Siamo pur sempre in Democrazia!

Poichè ho due bimbi in casa che già da qualche settimana hanno iniziato a definire questa lista, ignari della vera identità dell’uomo barbuto vestito di rosso che arriva sulle renne con tanti campanelli, mi sono domandato se ci fosse un Babbo Natale tecnologico cosa potrei chiedergli io?

Segue la lista dei miei desideri tecnologici:

1. Banda larga: sono una di quelle persone colpite dal Digital Divide (non è una malattia ma un disagio social-digitale) e quindi sono costretto a utilizzare una connessione a banda larga mobile a 3.6MBit con le relative limitazioni.
2. Aggiornamento del layout del mio sito web: è da agosto del 2010 che il layout è rimasto invariato, sì certo ho apportato di tanto in tanto qualche modifica, ma è quello che avevo iniziato ad usare provvisoriamente 15 mesi fa e credo sia ora di cambiare. Qualcuno ha suggerimenti da darmi?
3. Più risorse per il framework php ALPHA: ultimamente ho ripreso in mano il progetto valutando una riscrittura completa di alcune delle classi del Core. Ho inziato a fare degli esperimenti, ma di questo vi racconterò nei prossimi giorni con maggiori dettagli. Sarebbe comodo però se Babbo Natale mi prestasse un po’ di suoi folletti per migliorare il Framework sarebbero i benvenuti!

La mia letterina la concluderei così:

…Quindi, non avendo grosse pretese, che ne dici di contattare un gestore telefonico e digli di attivare la connettività nella mia zona (sì poi il contratto lo pago io non devi accollartene tu)? Sì poi se conosci un buon webdesigner che vuole farsi pubblicità e propormi un layout innovativo, essenziale e adatto al mio sito certo non disdegnerei il suo operato anzi, caro Babbo Natale, te ne sarei Grato! E perchè non coinvolgere una trentina dei tuoi folletti nelle attività di sviluppo sul framework? Se questi folletti fossero italiani sicuramente si potrebbe sbandierare il come progetto tutto italiano!

Insomma Babbo Natale, sappi che il bicchiere con il latte e i biscottini te li lascerò comunque sul tavolino accanto all’albero, ma tu puoi vedere di fare qualcosa anche per me?

Il seminario ha suscitato un particolare interesse prima in fase di iscrizione (è stata un’emozione sapere che c’era il tutto esaurito dopo appena 24 ore dall’apertura delle iscrizioni!) e del pubblico in sala poi che rientrato dall’evento fieristico mi ha tempestato di email chiedendomi le slide e delucidazioni sugli argomenti trattati.

Di seguito quindi rendo disponibili le slides già pubblicate qualche giorno fa sul mio profilo Slideshare provando ad apporfondire anche quanto già raccontato nei 50 minuti del seminario.

Dalla consultazione delle statistiche sui CMS e dalle statistiche d’uso delle librerie Javascript disponibili sul sito w3techs, si nota come particolari strumenti abbiano una significativa diffusione su scala mondiale. Cosa può significare e quanto può pesare per le aziende che hanno intenzione di dotarsi di una soluzione web tutto ciò?
Un’azienda che non vuole sentirsi vincolata a un preciso fornitore deve affidarsi a uno degli strumenti più diffusi  e/o conosciuti sul mercato mondiale.
Tale scelta è ripagata sia in termini di sicurezza in quanto una soluzione largamente diffusa, per mantenere il suo status, deve garantire gli opportuni aggiornamenti di sicurezza, inoltre i fornitori dovranno necessariamente offrire una tariffa adeguata ai costi di mercato in quanto non esclusivisti della competenza specifica.

Ma i fattori di valutazione dello strumento di cui dotarsi per un’azienda sono vincolati anche dalla diffusione della piattaforma su scala locale/nazionale, altrimenti il fornitore della soluzione potrebbe trovarsi nel vantaggio di essere l’unico player esclusivista della competenza offrendo i propri servizi a costi al di sopra degli standard di mercato.

Per quanto riguarda invece lo sviluppo di soluzioni ad-hoc è importante svolgere un accurato compito di analisi del processo da informatizzare valutando e annotando qualsiasi variabile non dando nulla per scontato.
Una volta che la situazione sarà risultata più chiara da un punto di vista dell’analisi dei bisogni, è importante effettuare una ricerca (on-line) valutando la presenza di soluzioni già sviluppate per risolvere lo specifico problema, quindi verificare cosa si dice sul Web del prodotto in termini di qualità e rivolgersi a uno o (meglio) più consulenti per assicurarsi contemporaneamente che esistano competenze locali specifiche e che l’eventuale soluzione scelta possa essere adeguata alle proprie necessità.

O più semplicemente potrebbe essere più efficiente rivolgersi direttamente a un consulente che potrebbe valutare le vostre necessità e proporvi la soluzione più adeguata.

Ma alla base di tutto, come ha ribadito anche il collega Fabrizio Caccavello nel suo seminario a SMAU Milano 2011, c’è bisogno che prima della collaborazione si instauri un rapporto di fiducia tra Cliente e Fornitore!

Dunque, partiamo dall’inizio, diverso tempo fa ho lavorato prima come impiegato e poi come collaboratore presso il Circondario Empolese Valdelsa, per il quale ho sviluppato e manutenuto il sistema per la gestione delle domande e delle offerte di lavoro da parte dei Centri per l’Impiego semplicemente denominato Me.La. 

Avendo un po’ di tempo a disposizione qualche mese fa, avevo segnato che avevo lavorato al Circondario Empolese Valdelsa, specificando un periodo ben preciso ma Facebook insisteva nel dire (sulla mia scheda di profilo pubblico) “Lavora presso Circondario Empolese Valdelsa“. Lavora, e non lavorava? Dopo un po’ di tentativi ho rinunciato a fargli capire che non lavoravo più lì… In fondo non c’è peggior sordo di chi non vuol sentire :)

Oggi ho avuto di nuovo voglia di capire cosa potesse esserci di errato e… ho trovato l’inghippo! :)

Appena ho specificato la posizione che ricoprivo nell’organico magicamente il mio profilo citava testualmente “Ha lavorato presso Circondario Empolese Valdelsa come Sviluppatore software“.

Che faccia parte sempre della delega dell’attività di testing all’utente finale?

Stamattina ho ricevuto diverse notifiche da Facebook e la cosa che ho notato è che le notifiche inviate vengono elaborate come se chi la ricevesse fosse dello stesso sesso della persona che l’ha spedita… :)

Eccovi gli esempi:

Ciao Diego,
nome dell’amico ha commentato un post in cui sei taggato.

Eccovi l’altro esempio:

Ciao Diego,
nome dell’amica ha commentato un post in cui sei taggata.

So di non aver cambiato sesso, almeno non ricordo di averlo fatto… quindi c’è qualcosa che non va! :)

Ecco, questa curiosa esperienza mi ha fatto riflettere in genere sulla qualità percepita di un servizio e la qualità effettiva.

La qualità (strutturale)  di Facebook da me percepita è molto alta, un Social Network in costante evoluzione che offre tantissime funzionalità, estetica ben curata, uptime pari quasi al 100%.

Poi però leggo una notifica con questi errori che sono riconducibili a meri errori di logica di programmazione e mi sorge il dubbio conto che il beta testing viene demandato all’utente finale, l’ultimo utilizzatore del software (in questo caso Facebook) e non dal produttore… o forse quest’ultimo svolgerà solo una minima parte dei controlli?

Spulciando un po’ il codice e la documentazione di WordPress, ci sono tanti modi descritti per risolvere il problema, ma tra quelli che prediligo c’è la modalità SQL, che richiede tu abbia le credenziali di accesso al tuo DB, che se non ricordassi sono nel file wp-config.php nella root del sito, e principlamente non richiede la scrittura di codice PHP (almeno evitiamo di scriverlo quando non è realmente necessario :D )!

Questa modalità SQL è molto semplice in quanto WordPress autentica un utente anche accettando una password codificata in MD5 (guardatevi il codice del metodo wp_check_password(), nel file /wp-includes/pluggable.php).

Quindi accediamo alla nostra console di MySQL (di solito utilizzo MySQL Workbench del quale non riesco più a farne a meno), e stabiliamo la connessione alla nostra banca dati, infine, presupponendo di avere un’installazione base di WordPress ci dovremmo ritrovare con delle tabelle con prefisso wp_, quindi eseguiamo subito una bella query di selezione:

select * from wp_users

prendiamo nota dell’ID dell’utente con ruoli di amministrazione, nel mio caso l’ID equivaleva a “1″. Poi eseguiamo la seguente query:

update wp_users set user_pass = md5('mia nuova password') where ID= 1;

Come direbbero i francesi “Les jeux sont fait!”

Di solito una pagina del genere è costituita dai seguenti spezzoni di codice (esemplificativi):

   <form method="post" action="mypage.php">
      <fieldset>
         <legend>
            Modulo contatti
         <legend>
         <p>
            <label for="nome">Nome</label>
            <input type="text" name="nome" id="nome" value="" />
         </p>
         <p>
            <label for="cognome">Cogome</label>
            <input type="text" name="cognome" id="cognome" value="" />
         </p>
         <p>
            <input type="submit" value="Procedi" />
         </p>
      </fieldset>
   </form>

mentre la parte di codice PHP che tratta il contenuto del modulo ha un funzionamento simile a quello che segue:

<?php
   if(isset($_POST) && count($_POST) > 0 ){
      $result = salvaDatiDelModulo($_POST);
      if($result === true){
         echo("Dati salvati correttamente");
      }else{
         echo("Si è presentato un errore durante il salvataggio del modulo: $result");
      }
   }
?>

Provando a premere il tasto F5 della tastiera dopo aver cliccato il pulsante Procedi sul modulo, vedrete un messaggio molto familiare (visibile su molte pagine web) e che, in dipendenza del browser utilizzato, mostra un messaggio del tipo: “La pagina sta provando a inoltrare di nuovo le informazioni di un modulo, si vuole procedere?“.

La conseguenza di un Submit eccessivo  può variare in dipendenza della complessità dell’applicazione e della gestione degli invii di richieste duplicate che talvolta,  a causa di un click spasmodico del tasto di Submit, può generare un inserimento duplicato di record in una banca dati, o la rimozione di più file dalla stessa directory o altri problemi che dovrebbero rientrare in un contesto di “Gestione degli errori”.

Lo stesso problema si presenta se per esempio dopo il Submit, abbiamo fatto click su un link della pagina, rendendoci conto di non essere sulla pagina giusta premiamo il pulsante “indietro” del Browser. Succede che il browser ci avverte che “la pagina è scaduta, è necessario nuovamente inoltrare i dati del modulo al server, bla bla bla…“. Le conseguenze di un inoltro sono le medesime descritte nel paragrafo precedente: record duplicati, eliminazioni di troppo, doppio invio email di email ecc.

Come si può evitare questo prolbema? Non è troppo difficile, eppure spesso si evita di gestire questo problema per inesperienza o perchè si tralascia valutando che le probabilità che un utente faccia click sul pulsante “indietro” del browser siano bassissime… Non è sempre così, le probabilità potrebbero essere altissime e la gestione del problema potrebbe risparmiare tanti grattacapi successivi.

La soluzione consiste nell’elaborare la richiesta quindi in qualsiasi caso dirottare la pagina verso un’altra destinazione (o verso se stessa) senza trasferire i dati in post, fornendo alla pagina di destinazione un ulteriore parametro che dovrebbe servire a comunicare il messaggio di errore o di successo all’utilizzatore del nostro modulo web.

Un’implementazione grezza ma già abbastanza efficace è la seguente:

<?php

   if(isset($_POST) && count($_POST) > 0 ){
      $result = salvaDatiDelModulo($_POST);
      $uri = $_SERVER['REQUEST_URI'];
      $uri .= (strpos('?',$uri)!==false)?'&','?';
      $uri .= 'msg=' . $result;
      header("Location: $uri", true); // Dirotto verso il nuovo URI ricostruito e rimpiazzo la location attuale nella barra degli indirizzi.
   }
   if(isset($_GET['msg']){
      $result = $_GET['msg'];
      if($result == 0){
         echo("Dati salvati correttamente");
      }else{
         // Prevedere un'array con i vari codici di errore e la relativa decodifica in messaggio testuale
         $msg = $codiciErrore[$result];
         echo("Si è presentato un errore durante il salvataggio del modulo: $msg");
      }
   }
?>

Quanto sopra consentirà di navigare anche avanti e indietro nella storia del browser o premere infinite volte il tasto F5 della tastiera!

Non era poi così complicato?  ;-)

La soluzione è servita!

Presupponendo che l’installazione di wordpress si presenta con la modalità predefinita di permalink (?page_id=0000) si vuole dirottare la pagina con ID 1234 verso il sito http://example.com.

Ecco le considerazioni da cui partire:

1. Si presuppone che sul webserver sia installato e ben configurato il modulo mod_rewrite di Apache.
2. La struttura dell’url costruito da WordPress per arrivare alla pagina 1234 è http://miosito.it/?page_id=1234
3. La regola dovrà prevedere che tutte le richieste che arrivano alla suddetta pagina dovranno essere dirottate verso il sito http://example.com
4. Per una corretta indicizzazione sui motori di ricerca la pagina 1234 dovrà rispondere con un codice di Redirect 301 (la pagina è stata trasferita altrove)

La regola di rewrite da utilizzare per il suddetto scopo è la seguente:

RewriteEngine on
RewriteCond %{QUERY_STRING} page_id=1234
RewriteRule .* http://example.com [R=301,L]

Maggiori informazioni sulle Rewrite Rules e sul mod_rewrite potete trovarle nella documentazione ufficiale.