Categoria: javascript

  • Greasemonkey e localStorage

    Tentando di scrivere una nuova e più completa versione dello script FFHideByKeyword mi sono scontrato con un subdolo e fastidioso bug di Greasemokey, il famoso script engine per Firefox che permette di modificare il comportamento ed il layout di una pagina HTML. Il bug in questione è legato all’utilizzo del localStorage, una tecnologia introdotta con HTML5 alternativa ai vecchi cookie, tecnologia che uso per archiviare le parole chiave indesiderate scelte dall’utente. La tecnologia è supportata dai maggiori browser [è possibile fare un test a questo indirizzo: HTML5 test], fornisce delle API chiare e facili da usare, e mi è quindi sembrato un peccato non sfruttarla.
    Ma veniamo al bug. La parte subdola sta nel fatto che non tutte le API sono disponibili, e quella che manca è la proprietà window.localStorage.length, che riporta il numero di coppie chiave/valore presenti nello storage. La proprietà è molto importante, perché in assenza di iteratori conoscere questo valore è l’unico modo pulito per accedere agli elementi, con un classico ciclo for:


    for (var i = 0; i < window.localStorage.length; i++) { k = window.localStorage.key(i); myFunction(window.localStorage.getItem(k)); }

    Ho usato il termine pulito perché in effetti è si possibile usare un metodo alternativo, ma sinceramente lo trovo brutto e per nulla ottimizzato. Il seguente ciclo potrebbe funzionare, ma non l'ho testato:


    var i = 0;
    if (window.localStorage.key(i) != null) {
    do {
    k = window.localStorage.key(i);
    myFunction(window.localStorage.getItem(k));
    i++;
    } while (window.localStorage.key(i) != null);
    }

    Il bug è facilmente verificabile.
    Il seguente codice HTML è funzionante:








    mentre il seguente userscript no:


    // ==UserScript==
    // @name Length Test
    // @namespace me
    // @description A test for localStorage.length
    // @include http://www.google.it/
    // ==/UserScript==

    var out = document.getElementById("ghead");
    window.localStorage.setItem("test", "test");
    out.innerHTML += "Getting data: " + window.localStorage.getItem("test") + "
    ";
    window.localStorage.setItem("test1", "test1");
    out.innerHTML += "Total count: " + window.localStorage.length;

    Qui c'è la segnalazione, direi scarsamente considerata, e qui il thread nel Google Group relativo. In attesa di un bugfix, lo sviluppo dello script è interrotto.

    [tags]greasemonkey, ffhidebykeyword[/tags]

  • #hidebykeyword, la gestione delle keywords

    Una breve spiegazione sulla gestione attuale delle keywords.
    Per aggiungere una keyword all’elenco di quelle che si vuole nascondere bisogna inserirla nell’apposto campo e premere Hide. Se non c’è il match tra la kw e i post, questa rimane visualizzata nel campo di inserimento, viceversa i post spariscono e la kw appare sotto al campo di inserimento assieme al relativo conteggio. Premendo Unhide i post relativi vengono mostrati, e la kw viene rimossa dall’elenco: a meno di agire dalle impostazioni del browser, questo è l’unico modo per eliminare una kw dalla lista. Ciò significa che le kw sono persistenti. Se non è stato fatto Unhide, ma la kw e il suo conteggio “spariscono”, vuole dire che la timeline attualmente mostrata non contiene più i post incriminati, “passati più in basso” per fare spazio a quelli nuovi. Ma la kw in questione è ancora attiva, e se ad un successivo refresh [o ricezione di nuovi dati] viene rilevata una corrispondenza la kw torna a fare il suo lavoro di pulizia.
    Tutto questo, ovviamente, a meno di bug nello script.
    In Chrome è possibile visualizzare ed editare l’elenco delle proprie kw tramite -> Strumenti -> Strumenti per sviluppatori -> Storage -> Local storage. La prossima versione dello script consentirà una gestione più flessibile delle kw tramite un mini pannello di controllo a scomparsa.

    [tags]friendfeed, hidebykeyword[/tags]

  • #hidebykeyword v0.7.2.1

    “Piccolo” bugfix che dovrebbe far contenti gli utenti Firefox, sembra che lo script sia ora completamente funzionante, risolvendo il problema dei post che non venivano nascosti a fronte di una keyword già presente nello storico, visibile o meno nell’elenco. Ho capito che la gestione delle keyword è un argomento piuttosto sentito, quindi la prossima release sarà dedicata proprio a questo. Allo stato attuale, le keyword vengono registrate nel localStorage, e ci rimangono anche se nessun post le contiene, a meno che non si faccia click su Unhide, nel quel caso vengono eliminate. L’intenzione è di realizzare un’area nascosta per default, che viene mostrata cliccando su “qualcosa” [da definire], e che contiene le keyword archiviate, area nella quale sarà possibile aggiungere/togliere keywords indipendentemente da quelle che vengono già mostrare nella UI attuale. Mi sembra un buon modo per gestirle, ma sono ovviamente ben contento di sentire eventuali altre opinioni. In relazione a questo, volevo ricordare che la pagina dello script su Userscripts.org presenta due utili tab, “Discussions” e “Issues” [vabbè, c’è pure “Fans”, ma mi pare eccessivo], che potrebbero [dovrebbero, eh] essere usate per contenere suggerimenti e discussioni circa lo script.

    As usual, lo script, su GitHub e Userscripts.

    Alla prox

    [tags]friendfeed, social, hidebykeyword[/tags]

  • #hidebykeyword v0.7.2

    Un altro aggiornamento allo script, migliorie legate all’usabilità. Con questa nuova versione, infatti, è possibile aggiungere una keyword alla blacklist semplicemente premendo il tasto Enter nel box di input, bypassando il click sul tasto Hide. Come al solito, qui il repository e qui la pagina su Userscripts.

    Enjoy, e alla prox :)

    [tags]hidebykeyword, friendfeed[/tags]

  • #hidebykeyword , aggiornamenti

    Aggiornamenti importanti riguardanti l’hidebykeyword!
    Sembra che la lotta estenuante contro Chrome sia finita, e che finalmente questa scheggia di browser possa godere appieno delle potenzialità del mio script. Inizialmente ho temuto di dover sviluppare una versione specifica per Chrome, ma per fortuna sono riuscito a mantenere lo script crossbrowser, semplificando così la manutenzione/gli aggiornamenti; è bastato in realtà fare un detect del browser ove richiesto, e utilizzare funzioni aventi funzionalità uguali in entrambi. La novità di rilievo è la variazione della soluzione di storage per la blacklist delle parole, passando dai cookies al localStorage implementato in HTML5 [in questo sito è possibile vedere il livello di supporto del proprio browser alle nuove specifiche]: codice più snello e leggibile, una ventina di righe di codice in meno che su un totale di circa duecento hanno un peso rilevante.
    Lo script è disponibile sia su Userscripts sia su Github: le due versioni sono ora in sync, ma in teoria il primo è per le versioni stabili, mentre il secondo per le release di sviluppo. Ogni commento è ben accetto, qui, su Friendfeed, per email, dove vi pare.

    Enjoy it e alla prox

    [tags]friendfeed, hidebykeyword, greasemonkey[/tags]

  • JS Benchmarking

    Ho colto l’occasione dell’arrivo del nuovo PC in ufficio per un poco di sano benchmarking dei vari browser disponibili sulla piazza.
    In particolare sono andato a testare le performance del motore Javascript, componente direi fondamentale dei vari siti che navigo quotidianamente. Ho usato due tools online legati al test del codice Javascript, il SunSpider Benchmark e il Kane JSBenchmark.
    Ho volutamente tralasciato il test sulla velocità di avvio dei browser, così come l’occupazione della RAM, perchè trovo più utile la velocità di esecuzione di una pagina piuttosto che il tempo necessario a far partire il programma.
    Le piattaforme testate sono in realtà due: Windows XP SP3 sul PC dell’ufficio, in esecuzione su un processore Intel i3-530 a 2.4GHZ con 2GB di RAM, e Ubuntu 9.10 sul mio laptop, in esecuzione su un processore Intel T3200 a 2GHz con 3GB di RAM.
    I browser testati sono: in XP, Chrome 4.1.249.1036, Firefox 3.6.2, Opera 10.51b3315, Internet Explorer 8.0.6001.18702; in Ubuntu, Chrome 5.0.307.11, Firefox 3.5.8, Opera 10.00beta4402, Epiphany 2.28.0 [con motore Webkit, e quindi assimilabile ad un Safari, ad esempio].

    I test sono realizzati monitorando l’esecuzione di diversi algoritmi, e valutati o attribuendo un punteggio alle performance [Kane] oppure misurando i tempi di esecuzione [SunSpider].

    Ecco i grafici riassuntivi.
    Nota1: per il Kane, un valore alto indica prestazioni migliori, mentre per il SunSpider viceversa.
    Nota2: cliccare sulle singole immagini per vederle ingrandite.

    Kane JSBenchmark - Windows
    Kane JSBenchmark - Windows

    Kane JSBenchmark - Linux
    Kane JSBenchmark - Linux

    SunSpider Benchmark - Windows
    SunSpider Benchmark - Windows

    SunSpider Benchmark - Linux
    SunSpider Benchmark - Linux

    E’ chiaro che il confronto numerico Windows/Linux non è possibile, girando i due sistemi su due macchine differenti; il confronto può essere fatto in modo percentuale, al limite.

    Qualche conclusione.
    Opera: l’ultima versione è veramente veloce, sia rispetto agli altri browser, sia rispetto alla versione 10.00;
    Explorer: incredibilmente lento, mi aspettavo un risultato migliore;
    Firefox: si comporta mediamente bene;
    Epiphany: da considerare, visti i risultati;

    Io, a prescindere dai risultati, uso Chrome su entrambi i sistemi.

    Alla prox

    [tags]javascript, benchmark, browser[/tags]

  • Hide by keyword

    L‘hide by keyword su FriendFeed, sembra che ci siamo.
    Mancava, e in parecchi ne soffrivano l’assenza.
    Ho pensato che sarebbe stato un bel regalo al miei socialamici, e mi ci sono messo di buona lena.
    Sono arrivato ad una versione abbastanza funzionante, almeno su Firefox, e quindi la rilascio al mondo. Chrome è il prossimo obiettivo.
    Questa feature l’ho implementata tramite l’estensione Greasemonkey per Firefox, ed è di conseguenza richiesta per il funzionamento dello script; Chrome non richiede alcuna estensione, perchè dalle ultime (ultima?) versioni questi userscripts vengono gestiti automaticamente.

    Come funziona? Installando lo script apparirà nella sidebar (indipendentemente dal tema) un box nel quale scrivere la parola (d’ora in poi KW) che ci irrita, con a fianco un comodo link chiamato Hide; cliccando sul link i post (non i commenti) contenenti la KW scompariranno dall’elenco, e la KW verrà aggiunta sotto il box, con a fianco un numero indicante quanti post sono stati nascosti e un link Unhide per tornare a mostrare i post bannati. Se la KW scritta non scompare dall’entry box in seguito al click su Hide, vuol dire che nessun post contiene la stessa. Ah, la ricerca è case insensitive.
    Ogni KW che riporta almeno un match viene salvata immediatamente in un cookie (che ho chiamato ffhbk_kws), in modo che la lista delle KW possa essere recuperata in automatico in seguito ad un refresh della pagina.

    Tutto qui.

    Questo che segue è un piccolo elenco di browser compatibility:

    Firefox3.5/Linux: funzionante
    Chrome4/Linux: non funzionante
    Chrome-dev/Linux: parzialmente funzionante
    Konqueror/Linux: non testato
    Opera/Linux:non testato
    Galeon/Linux: non testato

    Firefox3.5/WinXP: funzionante
    Chrome4/WinXP: non funzionante
    Opera/WinXP: non testato
    Safari/WinXP: non funzionante (1)
    IE/WinXP: non testato

    Firefox3.5/Windows Vista: non testato
    Chrome4/Windows Vista: non testato
    Opera/Windows Vista: non testato
    Safari/Windows Vista: non funzionante (1)
    IE/Windows Vista: non testato

    Firefox3.5/Windows Seven: funzionante
    Chrome4/Windows Seven: non testato
    Opera/Windows Seven: non testato
    Safari/Windows Seven: non funzionante (1)
    IE/Windows Seven: non testato

    Chrome/OSX: funzionante
    Firefox/OSX: non testato
    Safari/OSX: non testato

    (1) l’estensione GreaseKit, che permette di sfruttare gli userscripts in Safari, è disponibile solo per OSX.

    Lo script, nella sua versione stabile, è disponibile su userscripts.org, mentre per la versione di sviluppo ho aperto uno spazio su GitHub.
    Ora come ora le due versioni sono le medesime.
    Ogni commento/suggerimento è il benvenuto (qui, su FF, sulla pagina di UserScripts.org), così come una eventuale partecipazione al progetto (l’accesso al git tree).

    Per tenervi aggiornati, seguite l’hashtag #hidebykeyword su Friendfeed.

    Alla prox

    [tags]friendfeed, hide by keyword, greasemonkey[/tags]

  • Python 2.5

    Dopo aver mosso i primi passi con Maya e 3D Studio, mi e’ tornata la voglia di perdere un po’ di tempo con la grafica 3D.
    Essendo il mio tempo libero gia’ ridotto agli sgoccioli, ho preferito lasciare da parte affannose ricerche su Astalavista e eterni download con Emule per utilizzare qualche strumento piu’ open/free, e la mia scelta non poteva che cascare su Blender. Comunque questo non e’ un post su Blender, magari ne faro’ uno se i miei esperimenti porteranno a qualcosa di buono, percio’ passo a Python.
    Ho scaricato l’ultima release di Blender, la 2.44, l’installer per Windows (per ora ci smanetto al lavoro nella pausa pranzo, e qui ho Xp), poi l’ho installato ed eseguito; il programma apre una finestra a console, dove finiscono i vari messaggi di esecuzione, e leggendo le varie righe mi accorgo di due cose: 0) e’ stato compilato per usare Python2.5, 1) non trova un interprete Python esterno da usare.
    La prima non mi stupisce, indica che Blender e’ bello aggiornato, mentre la seconda mi stupisce un po’, visto che Python ce l’ho bello installato… poi ci penso un attimo e mi rendo conto che 2.5 != 2.4, quindi tutto ok. Il programma parte comunque, visto che ha il motore Python interno, ma potrei avere problemi con script che estendono il core, percio’ provvedo tosto tosto all’installazione della nuova versione.
    Tutto procede liscio, alla fine mi ritrovo le due versioni installate, c:\Python2.4 e c:\python2.5, e Blender, ma va!, dice che ha trovato un Python engine. Bene, chiudo Blender e aspetto di trovare un buon tutorial per partire.
    Visto che mi rimane un po’ di tempo prima delle 14, ne approfitto per vedere cosa e’ cambiato nel mio sistema, e quindi provo a lanciare un paio dei programmi che ho scritto… e qui’ la prima piacevole sorpresa: finalmente hanno sostituito quelle orrende icone con il serpentello sorridente con qualcosa di piu’ bello, wow! Io da parte mia avevo gia’ provveduto a cio’ con un po’ di lavoro grafico.

    Qualche immagine per spiegarmi meglio.

    Icone 2.4 (sorgente/binario)

    Icona sorgente 2.4 Icona binario 2.4

    Mie icone (sorgente/binario)

    Mia icona sorgente Mia Icona binario

    Icone 2.5 (sorgente/binario)

    Icona sorgente 2.5 Icona binario 2.5

    Direi che ora le icone sono guardabili, anche se le mie continuano a piacermi parecchio…
    Comunque, venendo al sodo, ho provato ad eseguire alcuni miei script, quelli console-based hanno continuato a funzionare senza problemi, mentre quelli GUI-based (GTK e WX) hanno avuto bisogno della reinstallazione delle librerie per Python2.5
    Per ora non ho ancora nessuna linea di codice che utilizzi le nuove features di Python, non appena effettuero’ qualche test anche su questo verrete prontamente aggiornati!

    Python rulez!

    Alla prox

    [tags]python, python2.5, icone[/tags]

  • Liste nascoste: IE ok

    Dopo un po’ di lavoro sono riuscito a sistemare la visualizzazione con IE6, che ad essere onesti non aveva colpe: e’ bastato scrivere correttamente i tag relativi alle liste.
    Ora pero’ mi chedo: cosa succede con gli altri browser? Hai per caso Safari, Konqueror o Opera per i vari OS? Mi lasci un commento con il risultato della prova?
    Grazie!

    Alla prox