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.

© Alex for /dev/random, 2009. | Permalink | No comment | Add to del.icio.us
Post tags: conferenze, PHP, phpday, Programmazione, Web

Feed enhanced by Better Feed from Ozh

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.

© Alex for /dev/random, 2009. | Permalink | No comment | Add to del.icio.us
Post tags: javascript, Linux, Web, zend framework

Feed enhanced by Better Feed from Ozh

Qualche giorno fa ho finalmente aggiornato Wordpress dalla ormai vetusta 2.3 alla versione 2.6, e nel frattempo ho scritto 3 post con la nuova versione. Forse è un po’ presto per dare un giudizio, ma non è mia intenzione nemmeno scendere troppo nei particolari.

I pregi

Innanzitutto devo fare un plauso e un ringraziamento particolare a Keith Dsouza, per il suo ottimo plugin Wordpress Automatic Upgrade. Ha fatto tutto lui: backup del sito e del DB, scaricamento della nuova versione,  messa offline del sito, disattivazione dei plugin, update del DB, riattivazione dei plugin, riattivazione del sito. E, come se non bastasse, mi ha aggiunto una voce a tutti i plugin nell’interfaccia di amministrazione, che mi permette di scaricare la nuova versione di ognuno senza dover fare FTP/SFTP a mano.

Complimenti anche al team di Wordpress. Nonostante la differenza di versione, l’update del database è andato liscio come l’olio, e il mio tema personalizzato e i widget che ho scritto hanno continuato a funzionare senza problemi. Non che usi funzioni astruse, ma è bello sapere che le API sono abbastanza stabili.

Le rognette

Il nuovo backend di amministrazione, invece, non mi piace moltissimo. Ho già messo mano al css per allargare tutto, perché era assurdamente limitato a 988 pixel. La mia configurazione di bottoni in WP Super Edit non permetteva all’editor WYSIWYG di rientrare in così poco spazio.

Trovo abbastanza assurda anche la nuova disposizione delle opzioni nell’interfaccia per scrivere post. All’inizio è abbastanza naturale: titolo in alto, testo a seguire, poi c’è la finestra di inserimento tag, quindi quella delle categorie e solo dopo i recommended tags e gli available tags. OK, vengono forniti da un plugin, ma qui sembra che le API siano un po’ cambiate, perché cliccando sugli available tags, non vengono automaticamente aggiunti ai tag per il messaggio, e si vedono solo dopo che aggiungo manualmente un tag. Un po’ contorta la spiegazione, ma speriamo che la nuova versione del plugin risolva il problema.

Ma la cosa peggiore è dopo. Ci sono le opzioni avanzate in basso. Si possono compilare senza problemi, e mi sta anche bene che siano qui, visto che nella maggior parte dei casi andranno bene i default, ma dopo aver scrollato in basso, bisogna tornare su per trovare, in alto a destra, il bottone per la pubblicazione.

Preferivo il design più compatto del vecchio tema, che aveva in questa posizione la selezione delle categorie, e il pulsante di pubblicazione sotto il post. In questo modo era più facile avere (su uno schermo 1280×1024) tutte le informazioni importanti del post sott’occhio. Il nuovo tema mi pare più “arioso” e dispersivo.

I plugin

Ho apprezzato invece la nuova gestione di contenuti multimediali, anche se preferivo la capacità del “vecchio” Flexible Upload di decidere al volo le dimensioni delle thumbnail da creare. Ora vanno impostate due dimensioni (thumbnail e medium) che rimarranno le stesse per tutte le immagini. Potrebbe capitarmi di uploadare un’immagine 600×50 e volerla tenere magari 300×25, invece di essere costretto a ridimensionarla a 200×16.6666.

Devo ancora testate l’inserimento di video, audio e media (?) nei post, mentre ne ho approfittato per riorganizzare un po’ i plugin e aggiungere il Subscribe To Comments, in modo da avere una segnalazione via email quando vengono aggiunti commenti a un post di vostro interesse, e WP-Syntax, per colorare la sintassi dei listati in base al linguaggio di programmazione usato.

Devo ancora esplorare molte funzioni del backend, ma non le usavo nemmeno prima… Per ora le funzionalità che uso sono quelle di base e, nonostante tutto, mi ci trovo abbastanza bene.

© Alex for /dev/random, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: Wordpress

Feed enhanced by Better Feed from Ozh

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.

© Alex for /dev/random, 2008. | Permalink | One comment | Add to del.icio.us
Post tags: Web

Feed enhanced by Better Feed from Ozh

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.

© Alex for /dev/random, 2008. | Permalink | No comment | Add to del.icio.us
Post tags: css, html, microsoft, Web

Feed enhanced by Better Feed from Ozh

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.

© Alex for /dev/random, 2008. | Permalink | One comment | Add to del.icio.us
Post tags: browser, css, javascript, PHP, Web

Feed enhanced by Better Feed from Ozh

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.

© Alex for /dev/random, 2007. | Permalink | One comment | Add to del.icio.us
Post tags: Natale, PHP, Web, Wordpress

Feed enhanced by Better Feed from Ozh

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.

© Alex for /dev/random, 2007. | Permalink | No comment | Add to del.icio.us
Post tags: browser, css, Web

Feed enhanced by Better Feed from Ozh