
Smashing Magazine ha pubblicato negli scorsi giorni un interessante articolo su jQuery. Vengono presentate ben 45 tecniche-plugin per sfruttare in pieno jQuery.
January 31st, 2009 | javascript, jQuery No Comments »

Smashing Magazine ha pubblicato negli scorsi giorni un interessante articolo su jQuery. Vengono presentate ben 45 tecniche-plugin per sfruttare in pieno jQuery.
January 30th, 2009 | CSS No Comments »

Son venuto a conoscenza di questo utilissimo tool da ItalianWebDesign che ringrazio infinitamente!
Il servizio permette di calcolare velocemente la larghezza, padding e margin delle colonne/div dei nostri layout. Read more →
January 29th, 2009 | browser, Mozilla Firefox No Comments »
Quella che segue è una guida per la creazione di test case per browser web, per esempio per creare test case che mostrino bug in HTML, CSS, SVG, DOM o JS.
Ci sono sempre eccezioni a tutte le regole quando si creano test case. La cosa più importante è mostrare il bug senza travisamenti. Questo non è qualcosa che si può fare semplicemente seguendo alcuni passi. Dovete essere consapevoli di quello che state facendo.
La prima fase nella costruzione di un test case è trovare in primo luogo un bug. Ci sono quattro modi per farlo:
Se avete una pagina web che mostra un problema, andate alla fase successiva. Altrimenti dovrete creare un test case iniziale da voi. Questo aspetto viene trattato nella sezione “Creare test case da zero” più avanti.
Avete una pagina dalla resa scorretta.
Fate una copia della pagina e di tutti i file in essa usati, e aggiornate i collegamenti in modo da farli puntare tutti alle vostre copie dei file. Assicuratevi che la resa continui ad essere scorretta, ed in caso contrario scoprite il perché. Create una copia dei file originali il più fedele possibile all’ambiente originale, in modo da riprodurre il bug. Per esempio, invece di caricare i file in locale, metteteli sul server e fate le vostre verifiche da li. Assicuratevi che i tipi MIME siano quelli giusti, ecc.
Una volta che avete approntato la vostra pagina con tutte le sue dipendenze, mostrando al contempo lo stesso problema, incorporate le dipendenze una ad una.
Per esempio, cambiate questa marcatura:
<link rel="stylesheet" href="foo.css">
… in questa:
<style type="text/css"> /* contenuto di foo.css */ </style>
Ogni volta che fate questo, verificate di non aver interrotto alcun URI relativo e che la pagina mostri ancora il problema. Se la pagina cessa di mostrare il problema, o avete fatto un errore nell’inserimento dei file esterni oppure avete trovato un bug correlato al modo in cui era collegato un determinato file. Passate al file successivo.
Una volta che avete inserito quante più dipendenze possibili nel file di test, cominciate a ridurre il file.
Andate a metà del file. Cancellate tutto dalla metà fino alla fine ( senza preoccuparvi se il file è ancora valido o no). Verificate che l’errore ricorra ancora. Se l’errore non ricorre più, isolate la parte e rimuovete la metà superiore o una parte più piccola.
Continuate in questo modo finché non avrete rimosso quasi tutto il file e non siano rimaste 20 righe (o meno) di marcatura, o almeno la parte più piccola necessaria a riprodurre il problema.
Ora, cominciate a pensare. Guardate il file. Rimuovete quelle parti che non hanno chiaramente effetti sul bug. Per esempio se il bug consiste nel fatto che il testo “gli investimenti sono buoni” è rosso ma dovrebbe essere verde, sostituite il testo con la sola parola “test” e verificate che sia ancora del colore sbagliato.
Rimuovete tutti gli script. Se c’è bisogno degli script, provate a simulare quello che fanno gli script e quindi rimuoveteli. Per esempio, sostituite questo:
<script>document.write('<p>test<\/p>')</script>;
..con:
<p>test</p>
…e verificate che il bug sia ancora presente.
Unite insieme tutti i blocchi <style>.
Cambiate la marcatura presentazionale con i CSS. Per esempio, cambiate questo:
<font color="red">
…in:
span { color: red; } /* nel foglio di stile */
<span> <!-- nella marcatura -->
Fate lo stesso con gli attributi style="" (rimuovete gli attributi, ed inserite il codice in un blocco <style>).
Rimuovete tutte le classi, ed usate invece i nomi di elemento. Per esempio:
.a { color: red; }
.b { color: green; }
<div class="a"><p class="b">This should be green.</p></div>
…diventa:
div { color: red; }
p { color: green; }
<div><p>This should be green.</p></div>
Fate lo stesso con gli ID. Assicuratevi di usare un DOCTYPE strict:
<!DOCTYPE HTML PUBLIC "-//W3C//DTD HTML 4.01//EN">
Rimuovete tutti gli elementi <meta>. Rimuovete tutti gli attributi lang e qualsiasi altra cosa non necessaria a mostrare il bug.
Se avete immagini, sostituitele con immagini molto semplici, ad esempio:
http://hixie.ch/resources/images/sample
Se uno script è necesssario, rimuovete quante più funzioni potete, unite insieme le funzioni e mettete il codice inline invece che nelle funzioni.
La fase finale è garantire che il test possa essere usato rapidamente. Deve essere possibile osservare il test e determinare se è stato superato o no in circa 2 secondi.
Ci sono molti trucchi per farlo, che vengono trattati in altri documenti come le CSS2.1 Test Case Authoring Guidelines:
http://www.w3.org/Style/CSS/Test/guidelines.html
Assicuratevi che il vostro test mostri il fallimento anche se non è in esecuzione alcuno script. Assicuratevi che il test non appaia vuoto se fallisce.
Articolo originale: http://hixie.ch/advocacy/writing-test-cases-for-web-browsers
Autore: Ian Hickson
Traduzione: Gabriele Romanato (3 gennaio 2008)
January 28th, 2009 | php, sicurezza No Comments »
Questo articolo nasce da una recente discussione avuta con un mio lettore, Massimo, che ringrazio per la lunga chiacchierata!
Lo scopo di questo articolo non è insegnare ad usare le sessioni con il PHP, bensì quello di spiegare cosa non fare quando si lavora con le sessioni!
Molto probabilmente seguiranno altri articoli che tratterano di SQL Injections e le altre tecniche da cui bisogna salvaguardare i nostri progetti onde evitare spiacevoli sorprese; nel frattempo tratterò semplicemente alcuni consigli da seguire quando si ha a che fare con le sessioni.
January 27th, 2009 | browser, Web Designing No Comments »
TomStardust ci ha parlato ieri di come scegliere la risoluzione adatta quando si progetta un sito.
L’articolo è raggiungibile al seguente link: La risoluzione giusta per un sito web
Il pezzo più importante dell’articolo riguarda in base a cosa fare la scelta della risoluzione. Se si tratta di un nuovo sito è bene scegliere un layout che oscilli tra i 90o e i 1400 pixel, mentre se si rinnova la veste grafica di un sito esistente sarebbe più indicato effettuare la scelta in base al target degli utenti che visitano il nostro sito. In entrambi i casi però potrebbero esserci valori sfalzati perchè non sempre gli utenti navigano con la finestra a tutto schermo e spesso, specie se si hanno monitor grandi, succede che la finestra occupi solo una parte.
Proprio per questo problema ho voluto creare un piccolo sondaggio: