Rotazione di immagini via jQuery
Posted by Davide | Filed under Javascript
Proprio poco tempo fa, mi chiedevo quando sarebbe stato possibile gestire la rotazione di immagini in una pagina web, tramite l’utilizzo di Javascript e dei canvas HTML
Beh, ecco la risposta, un ulteriore tassello che credo permettera’ a breve la creazione di animazioni senza l’utilizzo di Flash.
Via: Ajaxian
Portabilizzare la console di Firebug
Posted by Davide | Filed under Javascript
Prima della versione 1.2 di Firebug, l’unico problema in cui gli sviluppatori Javascript si potevano imbattere nel suo utilizzo era la necessita’ di scrivere una funzione di inizializzazione della console.
Tale funzione aveva il compito di definire le funzioni della console nel caso la classica console.log e sorelle venissero eseguite in browser senza Firebug.
Nelle versioni di Firebug 1.2 e successive e’ stata introdotta la funzione loadFirebugConsole, senza la quale la console non parte. Questo richiede un refactoring della funzione di inizializzazione; gia’ che dovevo metterci le mani, ho pensato: perche’ non modificare la funzione in modo tale da poter usare le i metodi della console anche su Opera ed il suo tool di debugging, Dragonfly?
Detto fatto: Opera implementa una funzione simile alla console.log, chiamata opera.postError, che useremo per fare l’overload di tutti i metodi definiti nella console. Ecco il codice finale.
if ( typeof window.loadFirebugConsole == 'function' ) {
window.loadFirebugConsole();
} else {
if ( !(window.console && window.console.log) ) {
if ( window.opera && window.opera.postError ) {
fConsole = window.opera.postError;
} else {
fConsole = function() {};
}
window.console = {
log: fConsole,
debug: fConsole,
info: fConsole,
warn: fConsole,
assert: fConsole
}
}
}
Ispirazione:
http://traviscline.com/blog/2008/04/02/firebug12-console-is-not-defined/
http://dev.opera.com/forums/topic/231622
Come evitare che Javascript vi rallenti il browser
Posted by Davide | Filed under Javascript
Uno dei problemi standard di chi si occupa di Javascript e’ quello relativo alla semplicita’ con cui un blocco di codice particolarmente dispendioso (in termini di tempo d’esecuzione e risorse) vi faccia freezare il browser per un tot di secondi.
Il problema e’ relativo al fatto che Javascript e’ un linguaggio single-threaded; in parole povere, mentre per esempio si eseguono cicli di istruzioni lunghe che si interfacciano con la struttura DOM di una pagina, il browser non trova una finestra di tempo dove poter fare un refresh del proprio contenuto, congelandosi.
Mi e’ capitato giustappunto oggi, dovendo lavorare sul DOM di una tabella piuttosto lunga, andando alla ricerca del posto esatto dove inserire nuove righe pervenutemi tramite Ajax.
Dato che il fulcro del progetto e’ proprio la prestazione dell’applicativo, sono subito andato alla ricerca di una possibile soluzione. Beh, ho scoperto un po’ di cose.
In questo articolo di debuggable.com viene proposta un’ottima soluzione (gia’ sperimentata e funzionante!) basata sull’inserire le nostre istruzioni ciuccia-risorse all’interno di una coda; ogni istruzione sara’ eseguita ed intervallata da un tot di millisecondi di pausa,
Qualcosa di simile e’ stato implementato anche in jQuery; ancora non mi sono documentato abbastanza, ma sembra una libreria, gestita direttamente dal core del framework, che si occupa di rendere il piu’ possibile smooth le animazioni.
Risorse web per developers
Posted by Davide | Filed under Web Development
Trovata tramite Ajaxian, ecco una bella pagina piena di link a risorse per gli sviluppatori web.
Utile anche per capire che tipo di strumenti utilizzano i nostri omologhi!
Come vi ho detto in un articolo di qualche giorno fa, io ormai non posso più fare a meno di un buon debugger PHP.
E voi? Quali sono i vostri strumenti essenziali?
Debugging con PHP e XDebug
Posted by Davide | Filed under PHP
Diciamolo: a (quasi) tutti piace PHP per la propria facilità d’uso. Semplice da installare e configurare, altrettanto da programmare. Ma quando il gioco si fa duro, ecco che si sente la mancanza di quegli strumenti che rendono un linguaggio di programmazione solido. Nello specifico, di un debugger.
Ok lo ammetto, per anni anche io mi sono districato tra echo e print_r inseriti nelle pagine per andare alla ricerca degli errori. Naturalmente la musica è cambiata non appena ho perso quell’oretta necessaria ad installare e configurare un debugger PHP. Vediamo come.
Per prima cosa, installiamo Xdebug.
Xdebug è un modulo PHP, probabilmente già disponibile attraverso il vostro pacchettizzatore di fiducia sotto Linux. Altrimenti, sorgente compilabile o modulo per Windows sono disponibili sul sito ufficiale.
Il modulo va copiato nella extension_dir di PHP (verificarne la locazione nel php.ini).
Sempre nel php.ini, vanno aggiunti alcuni parametri di configurazione. Nel mio caso, ne sono stati necessari solo alcuni, ma controllate la documentazione in caso fosse necessario specificarne di diversi:
[XDebug]
zend_extension = "path/to/xdebug.so"
xdebug.remote_enable = On
xdebug.remote_log = "/path/to/logs/xdebug.log"
Riavviate quindi Apache e verificate la corretta installazione del modulo tramite il classico phpinfo().
Ora che disponete del motore, passiamo all’abitacolo: il client. La lista è lunga, io ho fatto in tempo a testarne positivamente un paio, ovvero VIM e Eclipse. Eclipse in particolare, nella forma del PHP Development Tools, permette un debugging completo, con breakpoints, watch e tutto il necessaire. La configurazione sotto Eclipse dovrebbe essere piuttosto semplice: basta settare XDebug come debugger principale, al posto dello Zend, gli altri parametri dovrebbero essere già a posto.
Un’altra funzionalità della quale non riesco più a fare a meno è quella del profiling. Tramite questo processo siamo in grado di individuare quali parti del nostro programma impiegano la maggior percentuale del tempo totale di esecuzione, permettendoci di risolvere eventuali colli di bottiglia.
Per abilitare il profiling, è necessario tornare sul php.ini e aggiungere queste righe:
xdebug.profiler_enable = On
xdebug.profiler_output_dir = "/path/to/profiles/"
Il profiler non necessita di un client; è sufficiente aggiungere il parametro XDEBUG_PROFILE=1 alla nostra pagina web per avviarlo (es. http://localhost/test.php?XDEBUG_PROFILE=1).
In quella che avete settato come directory di xdebug.profiler_output_dir, verranno creati dei file del formato cachegrind.out.xxxx; apriteli con kcachegrind (Linux) o wincachegrind (Windows) per vedere come si è comportato il vostro script.
