Recensione generale

In una parola: ottimo. Anche se migliorabile.

A memoria credo sia il primo a trattare l’integrazione tra PHP e MongoDB.
Lo stile è molto scorrevole. I concetti sono spiegati in modo chiaro nella maggior parte dei casi. Fanno eccezione i concetti di programmazione funzionale nel capitolo dedicato a map-reduce, che avrebbero beneficiato di un maggiore approfondimento.
Ogni capitolo presenta diversi esempi di codice per gli argomenti trattati.
I quiz di cui è costellato aiutano a richiamare i concetti appena appresi e a capire se sia il caso di rileggere quanto appena studiato. Peccato che non siano molto numerosi. Le soluzioni ai quiz si trovano alla fine del libro.

Vengono presentati anche alcuni “compiti per casa” (di cui non viene data soluzione, naturalmente) che invitano ad implementare soluzioni diverse da quelle presentate o software che utilizzando i concetti esposti li espandano per creare software più complessi.

La caratteristica che ho apprezzato di più è la presentazione degli esempi: prima viene esposto il codice completo di tutti gli script, e in seguito, durante la spiegazione, vengono riportati i frammenti di codice. Questo consente di avere una visione globale e di poterla studiare da soli. Molti altri testi spezzano i sorgenti rendendoli illeggibili, o integrano la spiegazione in commenti lunghissimi che, senza colorazione della sintassi, li rendono altrettanto illeggibili.

Lo stile adottato sembra distaccarsi un po’ dal classico dei manuali tecnici, per tendere a quello dei testi universitari.

In alcuni casi si ha la sensazione che ci sia molto di più dietro (e spesso a ragione), e che il libro copra solo l’uso base di alcune caratteristiche.
In altri casi è scritto chiaramente (con relativo link) che per approfondire si possono consultare fonti online.

Alcuni piccoli errori tipografici come campi di array separati da :  (come in javascript) invece che da => in PHP, o virgolette dimenticate  nelle chiavi di accesso agli array sono facilmente individuabili e non pregiudicano la qualità del libro.

Capitolo 1 – Installazione

Inizia con una breve panoramica del “movimento NoSQL”, ne spiega brevemente i fondamenti, e poi passa alla procedura di installazione vera e propria, sia per Windows che per Linux, mentre per OSX dice semplicemente “è come su Linux”.
In tutti i casi la procedura è tanto semplice da richiedere non più di un paio di pagine.
Passa velocemente all’avvio del server, coprendo le principali opzioni di configurazione, alla creazione di database e collection, per finire con l’installazione, tramite PEAR, dei driver per PHP e a un primo script dimostrativo.

Capitolo 2 – La prima applicazione

Ormai diventato l’”hello world” dei libri che trattano web, si parte costruendo un piccolo blog senza troppe pretese: inserimento, cancellazione, modifica degli articoli. Quindi si passa ad
approfondire tramite paginazione dell’archivio per finire con l’inserimento di commenti ai post.
Durante il percorso vengono spiegate le classiche operazioni CRUD (Create, Read, Update, Delete), spiegando anche il particolare linguaggio di query di MongoDB, le operazioni di limit e skip, il concetto di cursore e di scrittura safe.
Si conclude con alcune operazioni particolari (upsert, incremento di un campo, rimozione di un campo) e con la distinzione tra documenti embedded e esterni, spiegando anche come fare le “select” cercando dati su documenti embedded.

Capitolo 3 – Session Manager

Dopo una breve introduzione a cosa sia una sessione, passa subito a definire un session handler personalizzato. Con l’occasione viene anche creata una classe (singleton) per la connessione al DB, che verrà utilizzata nel resto del libro.
Viene quindi creata una classe per la gestione della sessione tramite MongoDB, facilmente riutilizzabile in altri progetti in quanto quasi totalmente
trasparente.
Il capitolo si conclude con un esempio di gestione di login/logout degli utenti.
Molto utile non solo per capire come come astrarre l’accesso a MongoDB tramite una classe e come usare upsert, ma anche per capire come usare un DB generico (anche SQL) per le sessioni in PHP.

Capitoli 4 e 5 – Aggregazioni e statistiche

Accorpo la descrizione dei due capitoli perché trattano più o meno lo stesso argomento: map-reduce e group().
Il primo è forse l’argomento più difficile per chi è abituato a linguaggi procedurali o ad oggetti, in quanto riprende concetti della programmazione funzionale, mentre il secondo si avvicina di più a concetti conosciuti come quelli dell’SQL.
Due capitoli non facili da assimilare, nei quali avrei forse visto bene un numero maggiore di esempi. Fortunatamente quelli che ci sono riguardano applicazioni pratiche (tag cloud, statistiche di accesso alle pagine, ecc.) e non argomenti astratti.
Vengono introdotte anche le capped collections.

Capitolo 6 – Integrazione con i RDBMS

Forse il capitolo meno interessante per me, anche se tratta un argomento importante. Vengono portati diversi esempi di come usare in parallelo MongoDB e un database SQL (MySQL): come usare MongoDB per fare cache delle query complesse fatte su MySQL, o per archiviare vecchi dati in modo da scaricare MySQL.

Capitolo 7 – GridFS

Capitolo un po’ scarno, ma che fornisce tutte le informazioni necessarie per iniziare a lavorare con GridFS per lo storage di file dentro il DB.
Anche qui MongoDB eccelle per semplicità, quindi gli esempi sono brevi e chiari.
Uno degli esercizi invita ad implementare una gallery con thumbnail, dicendo di salvare le thumbnail assieme all’immagine originale, ma non spiega se si possano avere due file nello stesso ducumento (hint: non si può).

Capitolo 8: Geolocalizzazione

Introduce le funzionalità di geolocalizzazione di MongoDB, fornite sia da indici bidimensionali che da procedure predefinite nel server per la ricerca in base alla distanza da un punto.
Una buona introduzione, anche se lascia un po’ il dubbio sulle unità di misura (gradi, radianti, metri?) che vanno utilizzate.
Ottima la spiegazione di come integrare queste funzionalità con le mappe di Google per la visualizzazione dei risultati.

Capitolo 9: Sicurezza

Questo è il capitolo con meno codice PHP. Si concentra sull’amministrazione dalla console di MongoDB per la creazione di utenti con relative password, e di vari tipi di indice, comprese le procedure per analizzarne l’efficacia.
L’argomento indici forse sarebbe stato meglio trattato in un capitolo precedente.

Capitolo 10: RockMongo e phpMoAdmin

Una rapida panoramica di due interfacce web (scritte in PHP) per l’amministrazione, l’interrogazione e, soprattutto, il backup e il restore di database o di collections.
Copre pro e contro delle due soluzioni, l’installazione e l’uso di base.

Dopo esattamente due mesi di silenzio, finalmente mi ricordo che ho anche un blog, e torno a scriverci per parlare un po’ di questo mio primo PHPday.

Complice la vicinanza e un’interesse crescente, dopo l’annuncio, su come potesse essere una giornata immerso tra i programmatori PHP, ho fatto la pazzia e mi sono iscritto, approfittando dell’offerta early bird. Arrivato lì in auto, la prima (e unica, direi) brutta sorpresa: l’hotel non aveva un parcheggio proprio, e i Carabinieri, coadiuvati da un carro attrezzi, stavano portando via auto in divieto lungo le strade. Per fortuna dopo 15-20 minuti ho trovato un buco anche abbastanza vicino.

Veloce passaggio alla registrazione, dove mi hanno riempito di gadget (maglietta, cappellino, portacellulare a forma di sedia/antistress, oltre al tesserino identificativo) che non sapevo dove infilare visto che avevo le mani impegnate dall’Eee e dall’ombrello, e poi l’attesa per l’inizio che, come nella migliore tradizione di tutte le conferenze, è partito con mezz’ora di ritardo. Un plauso agli organizzatori che in 30 secondi hanno condensato i saluti per cui era prevista una mezz’ora, per cui tutti i talk sono stati abbastanza in orario.

L’affluenza, nonostante i timori visto il prezzo di iscrizione, è stata molto buona.

Tranne uno, per cui mi aspettavo tutt’altro, tutti i talk sono stati interessantissimi, e mi è dispiaciuto veramente tanto doverne perdere 2 o 3 a causa delle sovrapposizioni (c’erano tre “percorsi” contemporanei).

Interessante l’intervento di Rasmus Lerdorf (di cui parlerò probabilmente in un altro post) riguardo lo sviluppo di PHP, anche se purtroppo era subito dopo pranzo e mi sono perso l’inizio.

Zend Italia ha inoltre organizzato una sessione straordinaria di esame per la certificazione in PHP5, ed ha offerto l’iscrizione gratuita ai primi 10 iscritti. Ne ho approfittato subito e mi è andata bene. Anche l’esame è andato bene, visto che ora sono Zend Certified Engineer.

L’unica nota dolente è che l’esame mi ha fatto perdere altri due talk che mi interessavano. Ma pazienza!

I pranzi e i buffet sono stati un’ottima occasione per intavolare, nonostante la mia timidezza cronica, quattro chiacchiere con altri appassionati. Venerdì sono finito a pranzo con due relatori, tra cui il rappresentante di PayPal Italia…

“Incluso nel prezzo” c’era anche l’iscrizione al GrUSP, il Gruppo Utenti e Sviluppatori PHP italiani. Solo da ieri sono stato iscritto anche alla mailing list dei soci e mi ci sto ambientando, ma vista la chiacchierata fatta sabato sera in finale dei lavori tra i membri del gruppo e la cinquantina di persone rimaste, sembrerebbe una cosa molto interessante (tra sconti, contatti, collaborazioni, ecc.)

Approfitto per ringraziare gli organizzatori per l’ottimo lavoro svolto, e per salutare Cesare e Michele (se mai passeranno di qua).

Sul sito dell’evento ci sono i video registrati durante i vari talk, quindi se non ci eravate potete farvi un’idea di come è stata.

L’anno prossimo l’appuntamento è a Rimini (a meno di inconvenienti). Farò il possibile per esserci.

Il PHPday quest’anno si sposta a Verona, e cerca di dare un taglio ancora più ampio all’evento, allungando la durata a due giorni e introducendo il canale “community” per la presentazione di prodotti opensource. Ci saranno inoltre dei lightning talk, dei “dibattiti” improvvisati dai partecipanti.

Consultate il sito per il programma completo, tuttora non definitivo, ma già con diversi argomenti interessanti sul piatto, almeno per me. Inoltre sarà una buona occasione per incontrare sviluppatori preparati e competenti, merce abbastanza rara, purtroppo.

La novità mal recepita (al punto da generare un post molto risentito del presidente del GrUSP, il gruppo organizzatore) dai partecipanti, invece, è il prezzo di iscrizione, fissato in € 100 per la partecipazione a entrambe le giornate (60 per una sola), che aumenta a 160 (e 90) se ci si iscrive dopo il 16 aprile.

Secondo me, visto quello che viene offerto (soprattutto il pranzo e due buffet per ogni giornata) non è per niente alto, ma posso capire che, per chi è abituato a parteciparvi gratis dagli eventi precedenti, rappresenti un po’ un trauma.

Probabilmente l’affluenza sarà inferiore agli anni scorsi, ma di contro il pubblico sarà più mirato e interessato.

Credo che farò il possibile per partecipare.

Oggi, dopo un mese di sviluppo di un sito, lo metto in produzione e mi accorgo che con Galeon le textarea non vengono “trasformate” in editor wysiwyg da FCKeditor.

Subito penso che sia un bug nel plugin per jquery che integra FCK e vado sul suo sito ( http://www.fyneworks.com/jquery/FCKEditor/ ), e infatti nemmeno lì la demo funziona. Ma prima di scavare nel javascript, vado anche sul sito di FCK ( http://www.fckeditor.net/ ) . E nemmeno lì funziona.

E, naturalmente, la persona che deve usare quel sito usa sempre Galeon…

La cosa strana è che Epiphany (che usa la stessa versione di libnspr e di xulrunner) e Firefox/Iceweasel funzionano perfettamente. E che (Tiny)MCE funziona senza problemi anche in Galeon, visto che lo sto usando per scrivere questo post.

Toccherà scrivere un plugin per Zend Framework anche per MCE…

Nel frattempo, se qualcuno ha suggerimenti su come integrare FCK in Galeon, sono i benvenuti.

A List Apart, sito di riferimento per chiunque lavori o si diletti nello sviluppo di siti web, anche quest’anno ha indetto un sondaggio per designer, sviluppatori, architetti dell’informazione, project manager, scrittori ed editori web, uomini di marketing e chiunque altro operi nel settore.

I risultati dell’anno scorso, raccolti da quasi 33.000 partecipanti, sono stati molto interessanti, e visto che buona parte delle domande di quest’anno sono simili, sarà interessante vedere le variazioni e gli sviluppi nel settore.

Se siete nel settore, e potete dedicarci 15 minuti, fate come me e rispondete al sondaggio.

Assieme a un restyling del sito, che trovo molto meglio del precedente (almeno ora è fluido in verticale), anche se ha ancora qualche link rotto, è stata annunciata oggi la nuova versione di Zend Framework, la 1.5.

Le principali novità di questa versione sono Zend_Layout, che permette di avere un layout comune a tutte le pagine invece di doverlo ripetere per ogni View o di dover usare accrocchi per includere i pezzi in ogni View, e Zend_Form, che permette di creare dei form da passare alla View e di inglobare negli stessi le informazioni per la validazione dei campi oltre a permetterne la validazione al volo anche tramite AJAX (informando il browser tramite JSON sugli eventuali errori).

Ci sono moltissime altre novità, naturalmente, oltre a diversi bugfix.

Più veloce della luce Akrabat, che in contemporanea ha rilasciato la sua nuova versione (anche questa 1.5) del tutorial per Zend Framework, includendo già le informazioni su Zend_Layout e Zend_Form.

Trovo molto intelligente la sua scelta di categorizzare i vari form come Model, ma devo ancora vedere la documentazione ufficiale, se già lo prevedeva.

In realtà ad una prima occhiata avevo classificato Zend_Form come una feature utile al massimo per chi scrive CMS, perché rimuove dalla View le informazioni sul form, rendendo la vita difficile ai grafici/HTMListi quando si lavora in un ambiente misto, ma ora sto meditando se ricredermi. Forse lo proverò direttamente sul campo per vedere le reazioni.

Ho già installato il nuovo framework in parallelo al precedente 1.0 (che mantengo per non rischiare la compatibilità di alcune applicazioni già scritte) e nei prossimi giorni lo proverò sicuramente.

Sono state annunciate ieri le due nuove versioni dello Zend Framework.

La 1.0.4 è una maintenance release, che corregge un centinaio di bug. Sarò stato fortunato, o magari non uso ancora molte delle funzioni del framework, ma non mi è ancora mai capitato di incappare in un errore da quando ZF è alla versione 1.0.x. Ne ho trovati un paio mentre era in beta, corretti rapidamente.

La 1.5RC è la prima release candidate della nuova versione, che dovrebbe uscire in versione definitiva entro 1 mesetto. Qui le novità rispetto alla 1.0.x sono moltissime. La più importante, forse, è il nuovo modulo Zend_Layout che dovrebbe risolvere molti problemi dell’attuale modello di View in caso di siti con layout molto simile in molte pagine: la maggior parte, insomma. Altre innovazioni sono lo Zend_Form (che personalmente non mi piace molto perché sembra mischi la logica di Controller e View, ma dovrò approfondire) che supporta form potenziati da AJAX, nuovi helpers per Action e View per un migliore supporto AJAX, nuovi componenti per Advanced View, nuovi componenti per l’autenticazione tramite Information Card e OpenID, e miglioramenti importanti a Lucene (un “motore di ricerca” integrato nel framework, per indicizzare documenti di vari tipi), per la generazione di PDF (ora con supporto UTF-8) e ai web services (Technorati e Slide Share).

Entrambe richiedono almeno PHP 5.1.4 per funzionare, ma io consiglio di passare direttamente a PHP 5.2.

Spero solo di trovare un po’ di tempo per smanettare con la 1.5. Alcuni dei nuovi moduli sembrano molto interessanti.

Devo però muovere una critica agli sviluppatori: nella documentazione non si capisce da quale versione un certo modulo o una certa funzione sono state implementate, col risultato che ci si trova magari a cercare di usare con la 1.0.4 una funzione o una classe che esistono solo nella 1.5 e non si capisce dove sia l’errore finché non si va a vedere il sorgente del framework. Appena mi verrà attivato l’account nel bug tracker credo che aprirò una segnalazione a proposito.

La prima cosa che salta all’occhio (non ho ancora letto tutto il draft, e non penso lo leggerò mai, è lunghissimo!) è che finalmente hanno unificato la numerazione delle varie componenti. Quindi avremo HTML5, XHTML5 e DOM5 (invece di HTML 4.01, XHTML1.0, DOM3, ecc.).

Vi lascio il piacere della scoperta per vedere tutte le novità introdotte, ma se volete una scorciatoia, c’è un anche draft per le differenze con HTML4. Speriamo solo che questa draft rimanga tale il meno possibile. O almeno non tanto quanto sono rimaste draft quelle di CSS3.

Ma la cosa più interessante è che, pur non essendo ancora uno standard, HTML5 inizia già ad essere supportato da alcuni browser, e purtroppo la Microsoft ci mette lo zampino.

Per farla breve: si sono accorti che IE7 non rispetta gli standard benissimo, mentre vogliono rispettarli di più con IE8. Il problema è che molti utenti stanno scrivendo pagine per IE7 pensando che rispetti gli standard quando si specifica un DocType corretto. Una cosa del genere è già presente in IE6, che abilita lo “standards mode” specificando un DocType corretto, mentre va in “quirks mode” se il DocType è errato o mancante. Ma non rispettando totalmente gli standard, questo modo viene chiamato “almost standards mode”. IE7 li rispetta un po’ di più… possiamo definirlo “a little bit more almost standards mode”?. IE8 quindi avrà tre metodi di rendering delle pagine: quirks mode, almost standards mode, standards mode. Il problema è quindi come distinguere tra IE7 e IE8, che usano lo standards mode in modo diverso. Con un meta-tag, naturalmente!

Devo ancora raccapezzarmici, ma la mia opinione è che sia l’ennesima porcheria. In pratica verrebbe introdotto un meta-tag che specifica quale versione del browser viene richiesta per visualizzare una certa pagina:

<meta http-equiv="X-UA-Compatible" content="IE=8;FF=3;OtherUA=4">

Quindi se io scrivo un nuovo motore di rendering delle pagine devo andare a controllare cosa la gente ha messo (sempre che lo metta) in OtherUA, almeno finché il mio motore non sarà abbastanza famoso da meritare un tag apposito (notare che lì sopra manca Webkit, motore di Konqueror e Safari), oppure affidarmi alla compatibilità del mio motore con Firefox, e usare le sue versioni. E se l’utente non lo specifica?

Gli sviluppatori sono già abituati a usare un subset di HTML e CSS o a fare salti mortali (fortunatamente alleviati dalla presenza di commenti condizionali in IE) per far funzionare i siti su IE6, IE7, Firefox e Safari. Quelli che non lo facevano prima sicuramente non si ricorderanno nemmeno che esiste questo tag! Non era più semplice rispettare gli standard in IE8 e forzare l’upgrade appena esce, come stanno facendo con IE7? Con IE9 e Firefox4 dovranno tutti implementare almeno 4 o 5 modalità di rendering? I nostri browser supereranno finalmente la soglia dei 2 GiB occupati in memoria appena avviati?

Ai posteri l’ardua sentenza, diceva il saggio.

Ormai la percentuale di SPAM nelle mail ricevute ha raggiunto il 90% e gli spammer, non contenti, da alcuni anni sfruttano anche i Blog e i CMS per impestare la rete con le loro schifezze.

Per quanto riguarda le mail è un continuo inseguimento: blacklist, filtri bayesiani, OCR sulle immagini, ecc. Ma anche i siti hanno dovuto rincorrere le continue innovazioni da parte degli spammer.

CAPTCHA

Sono quindi nati i CAPTCHA di vario tipo, che si basano sulla (presunta) incapacità dei bot di spam di “leggere” il testo contenuto in un’immagine. Il sistema ha funzionato per un po’, finché i sistemi si sono evoluti e hanno iniziato a usare tecniche di OCR sui CAPTCHA stessi, facendone perdere efficacia: sono diventati via via più difficili da decodificare, ma anche per l’occhio umano oltre che per i bot.

Ne sono nati quindi nuovi tipi: dal CAPTCHA matematico (che potete ammirare nel form dei commenti di questo Blog ) a quello “sexy”, che si basa sulla capacità di una persona di distinguere un rappresentante bello del sesso opposto da uno brutto.

Purtroppo hanno tutti lo stesso problema: una persona con problemi di vista o qualcuno che naviga con browser testuali non li può utilizzare. Sono allora nati gli aiuti sonori ai CAPTCHA (che “pronunciano” le lettere nel CAPTCHA, per esempio), ma si scontrano col problema dell’audio sui siti: se l’utente sta ascoltando musica in sottofondo deve spegnerla, ascoltare il CAPTCHA, compilare il form, quindi riaccendere la musica

In un periodo in cui bisogna rendere la vita più semplice possibile all’utente, tutte queste complicazioni sono anacronistiche, e allontanano gli utenti.

Vediamo quindi alcune alternative, magari non perfette, ma con una buona percentuale di sicurezza.

Il campo nascosto nel form

Una prima tecnica consiste nell’aggiungere un campo di testo normale in un form, quindi di nasconderlo tramite CSS. Questa tecnica si basa sul presupposto che i bot, per sfruttare il maggior numero possibile di form, non guardano quali campi compilare, e invece li compilano tutti.

Si può quindi usare un codice come questo:

<style>
 .nascosto { display: none; }
</style>

...

<form ...>
 ...
 <div class="nascosto">
  <label for="codicesegreto">Non scrivere nulla in questo campo</label>
  <input type="text" name="codicesegreto" />
 </div>
 ...
</form>

In questo modo i browser che supportano i CSS nasconderanno l’intero div (è un esempio, naturalmente. Va adattato a come stilizzate i vostri form) e l’utente non vedrà nemmeno il campo. I browser che non supportano i CSS lo mostreranno, ma con il messaggio all’utente di non compilarlo. I bot non avranno idea di cosa si trovano davanti e lo compileranno senza pensarci (pensare? un bot??).

Lato server basta controllare che il campo “codicesegreto” del form non contenga nulla. Per esempio, in PHP:

<?php
 if (isset($_POST["codicesegreto"]) && $ POST["codicesegreto"] != "") {
  print("Ciao, bot! PRRRRRRRRRRR");
  exit;
 }
 // Normale processo di verifica degli altri campi
?>

Il codice nascosto nel form

Un’altra tecnica consiste nel nascondere un codice segreto nel form, e modificarlo via Javascript appena il form viene visualizzato:

<form...>
 ...
 <input type="hidden" id="codice" name="codicesegreto" value="1000" />
 <script type="text/javascript">
  <!--
   document.getElementById("codice").value = "mille";
  -->
 </script>
 ...
</form>

Questa tecnica si basa sul presupposto che il bot non esegua il codice javascript contenuto nel form. I browser che supportano Javascript avranno quindi codicesegreto=”mille”, mentre quelli che non lo supportano avranno codicesegreto=”1000″. I valori, naturalmente, sono di pura fantasia, potete mettere quello che volete, anche valori casuali calcolati server-side prima di presentare il form, e salvati in sessione per una verifica successiva.

Lato server, al ricevimento dei dati dal form, basta appunto controllare cosa contiene quel campo. Se contiene “mille” si procede normalmente con l’analisi degli altri campi del form. Se contiene “1000″ si può presentare all’utente un nuovo form, chiedendogli solo “Sei davvero una persona o sei un bot?” con un tasto submit: “Sono una persona”. Solo le persone (che hanno disattivato javascript nel browser) dovrebbero clickare su questo nuovo form, e quindi procedere al submit del form.

In PHP si può fare una cosa del genere:

<?php
 session_start();

 if (isset($_POST["codicesegreto"]) && $_POST["codicesegreto"] != "mille") {

  $_SESSION["datiform"] = $_POST;
  ?>
   <form ...>
    <label>Sei davvero una persona o un bot?</label>
    <input type="submit" name="chidicicheiosia" value="Sono una persona!" />
   </form>
  <?php
  exit;

 } else {
  // Normale procedura di controllo dei campi e di submit del form
 }
?>

Questo “giro” è un po’ più oneroso per gli utenti che disabilitano Javascript, ma non gli preclude la possibilità di scrivere commenti o comunque di compilare il form. Se Javascript è attivo la procedura è totalmente automatica. Naturalmente bisogna predisporre anche la pagina aggiuntiva per il controllo della conferma, oppure modificare la logica di questa in modo da gestire sia il submit diretto che quello con conferma.

Vantaggi e svantaggi

Il vantaggio più evidente è la semplicità, sia per il programmatore che per l’utente.

L’utente non deve compilare campi aggiuntivi, non deve cercare di interpretare strane immagini deformate o fare calcoli matematici. Tutte operazioni che, spesso, non capisce nemmeno a cosa possano servire.

Il programmatore non dovrà più fare i salti mortali per distorcere il testo in modi astrusi, complicarsi la vita con le libgd, o cercare font non “OCR-izzabili”. Non dovrà nemmeno fare funzioni aggiuntive per rigenerare l’immagine al volo (via AJAX, magari) nel caso l’altra sia illeggibile. Il codice, sia HTML che PHP, è molto più pulito.

Inoltre il traffico sulla rete è molto ridotto: non c’è un’immagine che comunque occupa una decina di KiB, e c’è anche una richiesta HTTP in meno. In generale il sito è più leggero.

Altro vantaggio è che questi due sistemi possono essere combinati per raddoppiare l’efficacia.

Lo svantaggio è totalmente dipendente dall’intelligenza dei bot. Se i bot riusciranno ad adeguarsi a queste tecniche, queste perderanno d’efficacia. Per farlo, naturalmente, dovranno imparare ad interpretare sia i CSS che il Javascript, ma basterebbe adeguare un po’ gli stili e il codice JS facendo le cose in modo un po’ più complesso (richiamando funzioni o metodi di oggetti in JS, o usando selettori in CSS). A quel punto dovrebbero diventare veri e propri browser. Non escludo possa succedere, ma nel frattempo si potranno inventare nuove soluzioni.

Per ora dovrebbero essere più che sufficienti.

Purtroppo ho scoperto sulla mia pelle che APC non serve a niente se si usa PHP via CGI, perché tiene tutte le pagine precompilate in shared memory, che naturalmente viene liberata alla fine di ogni processo CGI.

Quindi se state usando PHP come CGI, lasciate perdere APC. eAccelerator funziona, perché salva i precompilati su disco oltre che in RAM, ma non supporta (che io sappia) il monitoraggio degli upload.

Dovrò decidermi prima o poi a passare PHP4 in CGI e promuovere PHP5 a modulo di Apache, ma servirà un po’ di tempo per verificare che funzioni tutto senza problemi.

Dopo il post per gli auguri di Natale sicuramente non ve ne aspettavate uno per gli auguri di buon anno, vero?

Voevo postarlo poco dopo mezzanotte, ma la baldoria prima e la stanchezza poi mi hanno fatto desistere. Non credo sareste comunque stati lì a quell’ora a leggerlo, quindi non penso vi cambi molto la vita.

Siccome a capodanno si elencano i buoni propositi per l’anno che sta arrivando, ho pensato di raccogliere qui i miei. Magari qualcuno è d’ispirazione anche per voi. Sono in ordine sparso, man mano che mi vengono in mente.

Studiare il D (e altri linguaggi)

Da quello che leggo in giro, D è un ottimo linguaggio di programmazione, e in realtà ho già dato un’occhiata alle specifiche del linguaggio e agli esempi sul sito ufficiale. Quello che ho visto mi ha favorevolmente impressionato. In pratica è un linguaggio che cerca di prendere le parti migliori di C/C++ e di Python/Ruby. Molto flessibile, dinamico (non del tutto, naturalmente) e soprattutto compilato. Le prestazioni dei programmi scritti in D sono ottime e, a giudicare dagli esempi, è anche semplice scrivere programmi. Mi ricorda vagamente il linguaggio E che esisteva sull’Amiga, anche se in quel caso derivava da Pascal e Oberon, quindi con una sintassi più rigida.

Una delle sorprese più gradite è stato scoprire che ci si potevano fare cose come Torus Trooper e TUMIKI Fighters (non fatevi ingannare dalla grafica, sono molto divertenti ) in modo quasi completamente cross-platform.

Anche Vala sembra interessante. Si tratta di un linguaggio inventato dal team di Gnome, ispirato a C#, e molto orientato a scrivere applicazioni per Gnome (anche se, dagli esempi, sembra adatto un po’ per tutto). Lo stanno già usando per scrivere Scratchpad e anche Mickeyl per riscrivere openmoko-terminal2. Il vantaggio principale rispetto a C# stesso è che è completamente compilato, quindi non ha bisogno di virtual machine o di ambienti di runtime, o anche solo di librerie aggiuntive. A detta degli stessi sviluppatori è ancora acerbo, e molte cose sono in via di sviluppo, ma quello che c’è ha già un bell’aspetto.

Tornare in Giappone

Questo probabilmente è un proposito che non riuscirò a portare a termine entro il 2008, ma ci spero comunque. Mi mancano l’ordine e la cortesia dei giapponesi, mi manca Akihabara, mi manca il cibo giapponese. Insomma, non vedo l’ora di tornarci.

Mi sono messo come limite la primavera del 2009. Ce la posso fare! Ganbatte!

Finire i programmi e i siti che ho in corso

Questa forse è la parte più difficile di questi buoni propositi. Purtroppo la parte che mi “prende” di più di un progetto è la preparazione, le prime fasi di stesura del codice, l’organizzazione dei moduli, mentre odio totalmente e profondamente la fase di debug. Di solito il dover debuggare un software è motivo sufficiente per abbandonarlo a sé stesso. Probabilmente aspetterò l’uscita della quarta edizione di D&D per rimettere mano (e riscrivere per la terza volta) il mio Mastertools, software (in Python+Gtk+SQLite) di gestione delle campagne, con annesso database di magie (già funzionante), talenti e oggetti magici (non ancora funzionanti).

Spero di riuscire nei prossimi giorni a buttare giù almeno le basi di due siti che ho in testa da almeno un paio di mesi e di un altro paio di programmini che sto progettando da altrettanto tempo. Ma non voglio rivelare niente, anche per scaramanzia.

Comprare l’Asus Eee

In realtà sto aspettando la versione con schermo a 8, 9 o 10 pollici. Mi andrebbero bene anche i 7″ della versione attuale, ma con risoluzione almeno 1024×600. Meglio ancora 1280×768. Una bella formattata alla flash, una bella Debian con Gnome al posto della Xandros, una SDHC da 16-32 Gb montata come /home e via!

Se non sarà l’Eee sarà sicuramente un altro subnotebook di caratteristiche analoghe: 1 Kg di peso, dimensioni molto ridotte. Gradirei molto anche una durata maggiore della batteria.

Mi sono accorto che il notebook che ho ora (Dell Inspiron 8600) non lo uso mai (praticamente solo per masterizzare partite di D&D): troppo pesante (3.5 Kg), troppo ingombrante (schermo 15,4″, quindi notebook di oltre 17″), e relativamente fragile, avendo un HD al posto di una flash. E la tastiera è comunque ridotta rispetto al fisso, quindi difficile da usare. In proporzione uso di più lo Zaurus, sia per leggere e-book sia per scrivere.

Migliorare la conoscenza di PHP, Javascript e Python

Programmando in PHP per lavoro, la prima parte di questo proposito è abbastanza semplice da portare a termine, basterà continuare a lavorare . Ci sono comunque diversi argomenti che mi piacerebbe approfondire. Per esempio ho l’impressione di star usando poco e male lo Zend Framework, e che abbia ancora molte qualità nascoste da esplorare. Per di più, sta uscendo la nuova versione 1.5 con supporto per View estese e Layout!

Javascript è ridiventato molto interessante (per me, naturalmente) di recente, grazie all’arrivo di librerie e framework come jQuery che nascondono abbastanza bene le differenze più ostiche tra i browser e permettono di concentrarsi meglio sul lavoro da svolgere, più che sulle incompatibilità tra le varie versioni. Spero di poterlo approfondire maggiormente.

Purtroppo ho un po’ lasciato in disparte Python per motivi di tempo, e comunque non ero un esperto nemmeno prima. Devo impormi di riprenderlo in mano e di studiarmi bene le caratteristiche della nuova 2.5 (decoratori e compagnia cantante).

Lo nascondo qui ma non fateci caso: mi piacerebbe anche studiare un po’ Ruby. Tra l’altro è appena uscita la 1.9 che sembra abbia prestazioni molto superiori alla precedente. Tutti ne parlano, ma ora che l’hype iniziale dato da Rails si sta esaurendo, forse è il momento giusto per vedere cosa offre di veramente vantaggioso rispetto agli altri (rails a parte).

Postare più frequentemente sul blog

Questo non sarà proprio facilissimo. A volte un argomento mi pare troppo scontato o trito per parlarne qui, e voglio evitare di parlare di politica o cose del genere (che sono una flame-bait non da poco). Per scrivere post tecnici preferisco informarmi bene ed evitare di scrivere porcherie non verificate, anche se a volte devo fidarmi di quello che trovo in giro, non avendo la possibilità di provarlo direttamente.

Ciononostante, cercherò di trovare qualche argomento di cui parlare. Magari portare avanti i propositi di cui sopra mi darà anche qualche spunto interessante.

Dulcis in fundo…

Ah, naturalmente riportare la pace nel mondo! (Ecco il link diretto al sito. O una variante, se la preferite, in fondo i gusti sono gusti).

E quale occasione migliore per fare un regalo ai miei (pochi) lettori?

Da un po’ di tempo stavo meditando di rilasciare il plugin per WordPress che ho scritto per migliorare un po’ questo blog. Non è niente di fantascientifico, solo una raccolta di widget che trovo utili per velocizzare la gestione del blog e per renderlo un po’ meglio graficamente.

Li trovate nella pagina dedicata: Shu widgets per WordPress.

Magari a molti questo non dice niente, ma per chi fa siti web la notizia è qualcosa che scuote le fondamenta stesse del loro lavoro. Pochissimi browser superano completamente l’Acid2, e Firefox NON è tra questi (lo sarà la versione 3, ora in beta). Lo superano Safari, Konqueror e Opera.

Perché è così importante? L’Acid2 è un test che mette alla prova il supporto ai CSS2.1 del browser. Se il supporto è implementato correttamente, il test riesce (e si vede una faccia sotto effetto di acidi ), mentre se ci sono degli errori di implementazione, la faccia sarà dall’irriconoscibile al rovinato. IE6 (e anche IE7) mostra solo un’accozzaglia di righe rosse, gialle e di pallini (qui una lista di risultati, anche se abbastanza vecchia).

Il pieno supporto all’Acid2 significa che serviranno molti meno salti mortali nella definizione dei CSS, per far apparire un sito come lo si vuole. E significa anche che si possono usare attributi CSS che finora erano preclusi.

Naturalmente non è tutto Acid2. Le caratteristiche messe alla prova sono solo una (piccola) parte delle specifiche CSS2.1, e rimangono ancora molte cose da sistemare anche al di fuori dei CSS (il motore Javascript, per esempio), ma questo significa semplicemente che la Microsoft, finalmente, si è resa conto che sta perdendo fette di utenti sempre più grosse, e che quindi deve darsi da fare per aggiornare il suo browser: la concorrenza fa sempre bene al mercato.

Speriamo bene anche per il resto, e intanto aspettiamo che la gente pass, se non a Firefox, almeno a Internet Explorer 7.

jQuery è una libreria in javascript per semplificare lo sviluppo client-side di siti, che offre in pochissimo spazio (20 Kb compressa, meno di 100 non compressa) funzioni utilissime per la navigazione e la modifica del DOM, per le richieste AJAX e per alcune animazioni di base (fading, folding, ecc.).

Per mantenere minimo l’impatto sui download è stato scelto di lasciare a plugin esterni la gestione di funzionalità aggiuntive, e di inglobare solo le più usate nel core. Uno dei plugin più famosi è UI, per la realizzazione di interfacce interattive.

Koller Juenger, nel suo blog, ha raccolto una lista di più di 240 plugin per jQuery, suddivisi anche per categoria e uso. Un lavoro titanico e molto utile.

Quando una persona diventa programmatore o sistemista, la maggior parte delle volte viene affascinato da cose a cui non dovrebbe nemmeno pensare. Un cristiano potrebbe chiamarle “tentazioni demoniache”, un buddista “ricchezze terrene”, ecc. ecc. Invece sono da evitare il più possibile, e da abbandonare per poter raggiungere la Vera Illuminazione. Vediamone qualcuna.

chmod 777

Questo semplice mantra (che per i file può anche essere “chmod 666″, notate il numero diabolico) permetterà a chiunque di andare a letto con la vostra ragazza, di venire a cena a casa vostra in qualsiasi momento, di “prendere in prestito” la vostra macchina, di leggervi la posta direttamente dalla cassetta, ecc. ecc. ecc.

Seriamente: Questo semplice comando permette, su sistemi Linux e Unix, di accedere a qualsiasi risorsa (a un file, in realtà, ma in Unix/Linux TUTTO è un file) senza alcuna limitazione. Guardatevi da esso, poiché è il male. A parte dare il permesso di esecuzione (che nelle directory serve per poterci entrare, ma nei file rende eseguibile il file stesso) concede pieni poteri sul file a qualsiasi utente: lettura, scrittura, modifica, azzeramento. Forse l’unica cosa che non si può fare è cancellarlo (servono permessi equivalenti sulla sua directory). Può sembrare che risolva tutti i propri problemi (non devo più diventare root per modificarlo!), ma ci sono un sacco di motivi per cui Windows è pieno di virus e Linux no. Il fatto che le distribuzioni non usino mai chmod 777 è uno di questi.

Se un fiile ha un certo set di permessi è proprio perché nessuno, per errore o intenzionalmente, lo modifichi. Aprendo in questo modo i permessi di accesso si consente a programmi impazziti, a servizi bucati da cracker o semplicemente a un errore di digitazione di fare danni seri. Pensate a quale sia la differenza tra un “rm -Rf /” dato da utente (cancella solo i file a cui ha accesso l’utente, quindi solo la sua home e pochi file in /tmp) e dato da root (cancella tutto il sistema operativo).

goto

Qui entriamo nel campo della programmazione. Ormai è risaputo che goto è la fonte di tutti i mali, l’anticristo, il limone sulla Nutella. Lo dicono perfino Dijkstra e Wirth! (I link sono alla Wikipedia italiana, ma quella inglese è più completa). goto vi farà uscire di strada in macchina (goto fosso), vi farà entrare nello sgabuzzino invece che in bagno (goto bin). Potreste perfino finire a letto con un uomo invece che con una ragazza (goto man)! Attenti!

Seriamente: goto, se usato male (e nel 99% dei casi viene usato male) rende “spaghetti-code” i vostri programmi. Fa perdere velocemente il flusso logico delle procedure/funzioni, e porta a errori inaspettati (“ma questo codice non doveva essere eseguito quando questa variabile ha questo valore!”). Linus Torvalds lo può usare perché lui sa quello che fa.

global

Qui parlo in generale delle variabili globali. C’è un motivo per cui sono state inventate la programmazione strutturata e quella ad oggetti. Le variabili globali sono una macchina del tempo rotta, che ci porta solo indietro di 50 anni: guerra (o primo dopoguerra), malattie, dispersi, fame, ecc. ecc.

Seriamente: usare variabili globali è pericoloso quanto e forse più che usare goto: queste variabili possono venire modificate da altre funzioni che non c’entrano niente con quello che stiamo facendo, ed è impossibile sapere con esattezza, guardando il codice, che valore hanno in un certo punto. Passate valori alle funzioni, impostateli in qualche variabile di classe, ma guardatevi sempre dall’usare variabili globali. Hanno senso solo in pochissimi casi, e, se siete dei principianti, in NESSUN caso.

In PHP questo comprende anche l’uso di register_globals. Questa direttiva (che per fortuna verrà disabilitata e sarà reso impossibile abilitarla conla versione 6 di PHP) prende tutte le variabili che arrivano dall’esterno del vostro script (quindi GET e POST, i cookies, i valori in sessione, le variabili d’ambiente) e le mette tutte in un minestrone, rendendole variabili globali. C’è un ordine preciso di “riempimento” di questo minestrone, ma vi sfido a capire, a colpo d’occhio, se una variabile sia stata passata da GET o se arrivi dalla sessione dell’utente. Molto meglio usare le superglobals: $_GET, $_POST, $_COOKIES, $_SESSION e $_ENV (oltre a $_SERVER).

addslashes()/stripslashes()/magic_quotes

Qui si parla specificatamente di PHP. Il giorno che queste funzioni verranno tolte da PHP probabilmente smetterà di piovere folgore dal cielo, o più probabilmente un\\\’infinita\` di pagine web l\’una coi caratteri più sballati dell\\\’altra, e parecchi casi di SQL-injection spariranno dalla rete.

Seriamente: poche cose in una pagina web hanno bisogno delle barre prima di un carattere. Può sembrare giusto prima di infilare una stringa in MySQL (per cui la ‘ è un carattere speciale e, se contenuta in una frase, fa “escapata” con \’), ma, per esempio, in PostgreSQL il modo giusto di fare l’escape è ” (due virgolette singole) e non \’, quindi i vostri script non funzioneranno cambiando DB. Usate mysql_real_escape_string(), pg_escape_string() o, meglio ancora, PDO o un framework come Zend Framework. Per passarle su un URL (un link con <a>, per esempio) la funzione giusta è urlencode(). addslashes non è quasi mai la risposta giusta. Vale la stessa considerazione di global: se siete principianti, addslashes() non è MAI la risposta giusta.

<font>, <b>, <i>, <frame> (guest stars: <table>, <br>)

Entriamo nel mondo del web dalla porta sul retro: HTML. Il poveretto era nato con buonissime intenzioni: l’ipertesto, la digitalizzazione e il collegamento delle informazioni, la diffusione della cultura. Ma tre bambini cattivi (non facciamo nomi, solo iniziali: MS, NS e MM) gli hanno regalato le caramelle fuori dalla scuola, e da allora si sta disintossicando in diverse comunità di recupero. Per fortuna ultimamente ha trovato un bel po’ di amici che lo stanno tirando fuori dal tunnel, ma ci sono ancora un sacco di bambini cattivi in giro!

Seriamente: L’HTML è nato per descrivere la struttura delle informazioni, non la loro rappresentazione sullo schermo. Usare editor WYSIWYG facilita sicuramente lo scrivere pagine web, ma avete mai provato a modificare il posizionamento di un’immagine senza usare quegli editor, o ad aggiungere un’immagine in mezzo alle altre, anche CON quegli editor? Da un po’ il W3C ha preso una posizione netta sulla questione: l’HTML deve descrivere solo COSA è una certa informazione, mentre il COME FARLA VEDERE è compito dei CSS. COME SI COMPORTA è compito di Javascript (o ECMAscript), e con questo il cerchio si chiude. font, b e i sono (finalmente) tag deprecati. Un testo non è “Arial 18px bold italic”, ma “titolo di sezione”, quindi <h2> (per esempio). Una frase importante non è “bold”, ma “importante” (strong) appunto! Prima si impara a usare i tag giusti, meglio è.

Ho messo come guest star <table> e <br> perché si devono ancora usare, ma solo quando è giusto usarli. Non si usa <table> per definire il layout di una pagina, ma solo per intabellare dati. Non si usa <br> per fare spazio con le righe vuote, ma solo per andare a capo senza chiudere un paragrafo (che è <p>).

Una malattia molto diffusa per chi si avvicina ai CSS è la DIVite (accompagnata dalla SPANite): quando non si sa cosa mettere, si mettono un div o uno span, dimenticando che esistono decine di tag che non usa nessuno. Una lista della spesa è <ul>, una lista di passi per una ricetta è una <ol>. Una lista di definizioni da vocabolario è <dl>. Un’etichetta da dare a qualcosa è <label>. La legenda di una tabella è <caption>. Una breve citazione è <q>, mentre una citazione lunga è <blockquote>. Un indirizzo è <address>. Ecc. ecc. Imparate a usare i tag giusti al momento giusto, e il vostro codice sarà molto pià leggibile (e modificabile, che è la cosa più importante). Quando ci sarete arrivati, date un’occhiata anche ai Microformati, tenendo conto che ci sono già estensioni per Firefox che li usano, e che in futuro saranno sempre più diffusi e richiesti. E non dimenticate di impostare il DOCTYPE corretto!

Conclusione

Per ora chiudo qui, ma sono sicuro che ho dimenticato un sacco di cose. La morale è sempre la solita: diffidate delle strade che sembrano troppo semplici. Sicuramente c’è qualcosa che non va.

Da qualche mese ormai uso Zend Framework per diversi siti, apprezzandone molto la flessibilità e la buona abitudine a non essere troppo invasivo. All’epoca la documentazione non era granché, ma sta migliorando molto col passar del tempo, e finalmente si vede qualcosa anche in italiano. Ho deciso quindi di raccogliere qualche link, sia per aiutare chi sta iniziando a usarlo per i propri siti, sia per avere un riferimento personale.

http://www.zftalk.com/

Dove si trovano link al canale IRC, oltre ad alcuni forum, purtroppo ancora poco frequentati (ma è il caso di riempirli, no? Vi si trovano anche raccolte di documentazione e siti. Una specie di portale sul mondo ZF.

http://akrabat.com/zend-framework-tutorial/

Qui si trova un ottimo tutorial. In generale il sito è un blog e spesso parla di ZF.

http://hades.phparch.com/…/rt::zend_framework::tutorial

Questo mi e` stato abbastanza utile per capire alcuni retroscena del framework.

http://www-128.ibm.com/developerworks/library/os-php-zend1/

La prima di 9 parti di un articolo pubblicato da IBM. Qualche mese fa era richiesta l’iscrizione (gratuita) al sito. Copre le basi di MVC e l’invio di mail.

http://blog.astrumfutura.com/categories/16-Zend-Framework

Qui ho iniziato capire come “distorcere” le view al mio volere. E` un blog che contiene anche altri articoli su PHP e sulla programmazione in generale. Qui ho linkato direttamente la categoria riferita a ZF.

Ce ne sono molti altri. Questa sera, cercando “Zend Framework” su Google ho visto decine di siti nuovi (rispetto a quando ho iniziato ad usarlo) che ne parlano.

Molto interessante il primo commento di questo post (che linka un post sul blog di Alex Netkachov) che spiega come convertire tutti gli errori di PHP (almeno versione 5) in eccezioni:

function errorHandler($errno, $errstr, $errfile, $errline) {
	throw new Exception($errstr, $errno);
}
set_error_handler('errorHandler');

In questo modo si ottiene anche un utile backtrace negli errori, in modo da scoprire, per esempio, dove è stata chiamata la funzione che ha generato l’errore, e i parametri passati.