In questi giorni mi sono chiesto se il catpcha fosse veramente la soluzione al problema Bot per SocialCibus. Così mi sono letto diversi articoli in rete. Alcuni di questi parlavano di un 3-10% di utenti che, quando vedono un captcha, lasciano perdere la registrazione, altri abbandonano solo dopo aver sbagliato una o due volte l’inserimento del testo.
Posso tenere fuori i bot e dentro gli esseri umani senza captcha? E’ la domanda che si sono posti in tanti.
Continue reading
Stavo cercando di creare un sistema di notifiche (tipo wall di FB) di ciò che accade agli utenti del mio nuovo sito di ricette e mi sono imbattuto in un problema: ereditarietà con Doctrine e relazioni diverse per ogni figlio.
Premetto che il sito è realizzato con Sf 1.4 e Doctrine 1.2.
Accantonato per il momento l’utilizzo di database documentali e varianti, rimanendo nel mondo del relazionale, per l’implementazione del sistema di notifiche ho fatto il seguente ragionamento:
ci sono principalmente due modi per memorizzare le informazioni su “cosa sta accadendo” (es. nuova ricetta di un amico, commento ad una mia ricetta, follow, like, etc.):
Naturalmente ho scelto la seconda, che sicuramente è la soluzione più pulita e performante.
Di seguito lo schema (semplificato) dei modelli da “notificare”.
Ed eccoci a modellare le notifice: per realizzare la mappatura alle varie tipologie di notifica ho deciso di utilizzare l’ereditarietà con aggregazione di colonne di Doctrine.
Bene, ora ho quello che mi serve… o quasi. Considerando che subject_id sia l’id del soggetto della notifica (es. Ricetta o Commento) mi serve una relazione con il repository del soggetto stesso, cosicchè possa avere direttamente l’oggetto relativo alla notifica:
Come aggiungo le relazioni? Ho provato con le relazioni “classiche”:
Funziona! Ma… il problema è che alla creazione del database le relazioni le crea… TUTTE nella stessa tabella, quindi abbiamo Notification che ha come constraint tutte le relazioni definite, con Recipe, Comment, Like e Follow.
Il che non funziona affatto, poichè ad ogni inserimento avremo errori di chiavi importate inesistenti nella tabella Notification. Sigh!
Ricominciamo ed eliminiamo le relazioni dallo schema.yml.
Cercando in rete ho trovato un attributo che fa al caso mio: Doctrine::EXPORT_CONSTRAINTS
Quindi ho modificato i modelli dicendo di non esportare le constraint:
Si può fare anche direttamente nello schema.yml ma non ho indagato otre, perchè già così… FUNZIONA!!!
Buon divertimento
A volte può capitare di essere pronti per il deploy di una applicazione quando ci accorgiamo di aver dimenticato di creare gli script per aggiornare il database in produzione.
Con Symfony, Doctrine e un sistema di versioning è possibile rimediare molto facilmente.
Questa è la mia ricetta:
che rappresenta il database in produzione (verosimilmente il file che è adesso in produzione 
oppure con il sistema di versioning)
in un posto sicuro
con la copia “vecchia” recuperata
(se necessario con il parametro env settato)
appena creato dalla procedura in
(se è la prima volta che migri ce n’è uno solo altrimenti apri solo l’ultimo)
all’ultima versione
Buona migrazione a tutti.
Talvolta è utile poter caricare alcuni helper dal controller o dal modello, per esempio mi è capitato di dover formattare una data o utilizzare alcuni dei miei helper direttamente dal controller.
Per far questo è sufficiente inserire il codice seguente nel metodo in cui si ha la necessità:
sfLoad::helpers(array('helper1', 'helper2', ...));
Buon coding.
UPDATE: per sf 1.4
$this->getContext()->getConfiguration()->loadHelpers('Partial');
$this->getContext()->getConfiguration()->loadHelpers(array('helper1', 'helper2', ...));
Ho appena patchato il plugin sfJqueryReloaded (il trunk) per abilitare il supporto a jq_drop_receiving_element(), ultimo tassello mancante per poter riscrivere il tutorial ajax di symfony anche con jQuery.
Potete trovare la demo riscritta in http://cart.demo.keasoft.it/ e la patch (in attesa di approvazione dai lead del plugin) qui jQueryHelper.php.diff
Buon divertimento
A volte capita di dover far convivere sulla stessa macchina di sviluppo diverse versioni si Symfony. Ci sono diverse soluzioni per poter realizzare il nostro scopo e qui vi esporrò quella che utilizzo più frequentemente.
Presupposto che la maggior parte delle applicazioni siano scritte per SF 1.0 oppure che questo sia già installato via PEAR e presupposto che vogliamo installare anche la 1.1 e la 1.2 sulla stessa macchina, procediamo come segue:
L’installazione classica di SF da manuale via PEAR è la seguente (la versione corrente è la 1.0.18):
$ pear channel-discover pear.symfony-project.com
$ pear install symfony/symfony-1.0.18
In questo modo quando lanciamo il comando
$ symfony -V
otterremo la versione appena installata
symfony version 1.0.18
Ora procediamo con l’installazione di Symfony 1.1 da SVN: prendendo spunto dal manuale prendiamo la versione corrente, non quella di sviluppo ma quella stabile (ad oggi la 1.1.3).
Prepariamo la directory che ci servirà come deposito di SF 1.1 e 1.2
$ mkdir ~/symfony_rep
$ cd ~/symfony_rep
Ora prendiamo l’ultima release del ramo 1.1
$ svn co http://svn.symfony-project.com/tags/RELEASE_1_1_3
$ ln -s RELEASE_1_1_3 1.1
Facciamo la stessa cosa per la 1.2 (se ne avete bisogno) ma in questo caso non essendo ancora stata rilasciata la stabile dovremmo prendere la versione di sviluppo come da manuale
$ svn co http://svn.symfony-project.com/branches/1.2
Ottimo, abbiamo tutte e tre le versioni installate, ora non ci resta che aggiungere 2 alias per rendere l’utilizzo della versione 1.1 e 1.2 più semplice.
$ alias sf11='~/symfony_rep/1.1/data/bin/symfony'
$ alias sf12='~/symfony_rep/1.2/data/bin/symfony'
Questi alias per comodità potete inserirli nel vostro ~/.bashrc così che siano sempre disponibili ad ogni riavvio (o apertura di nuove shell).
Se tutto è andato bene, digitando i vari sf11 e sf12 doveste ottenere il seguente risultato:
$ sf11 -V
symfony version 1.1.3 (/home/VOSTROUTENTE/symfony_rep/RELEASE_1_1_3/lib)
$ sf12 -V
symfony version 1.2.0-DEV (/home/VOSTROUTENTE/symfony_rep/1.2/lib)
Buon lavoro!