Andrea Gandino

Per un Web inclusivo

2019-10-20T00:00:00+02:00

Come già accaduto a Catania il mese scorso, anche al WordCamp Verona di settimana scorsa si è discusso di accessibilità.

È un tema di cui ultimamente si sente parlare tanto, ma dubito che la maggior parte dei designer e sviluppatori abbia realmente coscienza di quanto le buone pratiche di accessibilità impattino direttamente sulla vita quotidiana delle persone con disabilità.

Recentemente, Domino’s, la catena americana di consegna di pizza a domicilio, è stata citata in giudizio proprio su un caso di mancata accessibilità. Essendo stata ritenuta responsabile di non avere un sito web fruibile da utenti con disabilità, Domino ha risposto come segue:

Ha fatto appello alla Corte Suprema,
Ha rilasciato un comunicato sul proprio sito, con l’obiettivo di mostrarsi attenta alle esigenze di tutti i propri utenti.

Ora, la Corte Suprema ha rispedito al mittente l’appello, imponendo all’azienda stessa di conformarsi al vigente Americans With Disabilities Act.

Il comunicato, invece, risultava, nella sua versione originale, scritto grigio scuro su grigio chiaro, con font sottile, con buona pace di ipovedenti e daltonici. Non il massimo se vuoi comunicare inclusività. Mentre vi scrivo, risulta evidente come debba essere arrivata la voce dalla regia, dato che si è ripiegato su un più tranquillo e certamente più leggibile Verdana debitamente contrastato. Bah.

Ad ogni modo, a Verona ho conosciuto Simone Mignami. Simone è uno sviluppatore ipovedente e ha intrattenuto brillantemente la platea nel primo talk pomeridiano, in cui parlava, appunto, degli aspetti pratici dell’accessibilità.

Non accade spesso, ma lo speech di Simone è stato uno di quelli che quando termina capisci che ti ha dato qualcosa.

Ho perso il conto di quante domande ho fatto a Simone a margine del suo intervento, e sperlo di non averlo infastidito troppo con la mia curiosità, ma, pur essendo quello dell’accessibilità un tema che mi è sempre stato piuttosto a cuore, sento di non conoscere abbastanza sull’argomento.

Più in generale, l’esperienza di vedere dal vivo come una persona ipovedente naviga il web o il proprio smartphone mediante la sintesi vocale penso che possa definirsi senza mezzi termini mind blowing, e credo che possa cambiare in maniera netta il modo in cui ci approcciamo a questo tema.

Simone ha una newsletter, cui mi sono prontamente iscritto. Se volete conoscere qualcosa di più sull’argomento, e se siete magari inclini oggi a farvi un favore, iscrivetevi pure voi, perché ne vale la pena.

Font a spaziatura fissa che (forse) non conoscete

2019-09-29T00:00:00+02:00

Il mio socio in affari vi potrebbe raccontare che ogni volta che si sposta a lavorare sul mio computer, due cose trova costantemente cambiate nel mio editor di testo: lo schema di colori e la famiglia di caratteri utilizzata.

È più forte di me, e sembrerà una sciocchezza: cambiare combinazione di colori e font mi consente di guardare alla mia quotidianità programmatoria con occhi sempre diversi. In particolar modo con l’avvento dei monitor 4k o superiori, l’esperienza tipografica è diventata decisamente gratificante.

Recentemente, poi, sono diventato fan dei font da programmazione con legature, un lusso che prima d’ora tendevo a concedermi e gradire solo in contesti applicativi diversi.

Quindi, eccovi una lista assolutamente parziale di font che mi sento di consigliare:

1. Fira Code

Ok, questo magari lo conoscevate, ma lo metto comunque in lista perché è il font con cui sto scrivendo questo stesso post, e in più ha tra le legature meglio realizzate tra quelle che ho analizzato.

Non gradite le legature? Non c’è problema: Fira Mono, suo gemello, non le ha.

2. Hasklig

Fork di Source Code Pro, font già buono di suo, aggiunge un set di legature alla famiglia originaria. Da provare, se si vuole qualcosa di “classico”.

3. Operator Mono

Questo è un font delizioso. Non ha legature, ok (ma del resto non c’è nessun obbligo a riguardo), ma ha carattere da vendere: inoltre, è uno dei pochissimi font monospace ad avere una variante corsiva completa.

Se guardate gli screenshot, magari potreste storcere il naso; ma se voleste utilizzarlo, vi renderete conto di come sia tutt’altro che fuori posto in un editor di testo.

Ah, è a pagamento, e non viene via necessariamente a buon mercato; la variante di riferimento per un utilizzo nell’editor di testo è la variante “Book”.

4. Code Saver

Per tornare a qualcosa di più classico, ma con una punta di innovazione, Code Saver potrebbe essere un’ottima scelta.

Dotato di variante corsiva, e di zero barrati, ha proporzioni decisamente bilanciate, e si rivela particolarmente efficace sia che stiamo scrivendo codice, sia che scriviamo un articolo.

5. Cascadia Code

Microsoft con i font ci ha sempre saputo fare, e parecchio, anche. Cascadia Code, appena rilasciato in una versione preliminare, ha tutte le carte in regola per essere il degno successore di Consolas.

La famiglia presenta eccellenti legature, ed ha forme particolari che, per creatività, richiamano vagamente quelle di Operator Mono.

Siccome il font è ancora in fase di sviluppo, e ad oggi non presenta né una variante grassetto (non necessaria, ma gradita), né caratteri accentati (ma una sollevazione popolare ha già reso esplicita la richiesta ai designer che ci stanno lavorando).

Un paio di consigli

Chiudo con un paio di suggerimenti che penso potranno tornarvi utili se come me vorrete finalmente lasciarvi cadere nella tana del Bianconiglio dei font monospace:

Se il font che state utilizzando non vi piace troppo a livello di rendering, tipicamente se vi sembra troppo “ciccio” (termine tecnico), provate a cambiarne l’aliasing. In Sublime Text, per dire, c’è una differenza sostanziale tra vedere i font con subpixel_antialias e gray_antialias. Inoltre, considerate che tanto dipende dallo schema di colori utilizzato: su Mac, per esempio, testo chiaro su fondo scuro tenderà ad apparire più grassetto di quanto non sia in realtà.
Sempre in Sublime Text, è possibile indicare all’editor di non voler applicare le legature al font in uso; questa pagina di documentazione dovrebbe fornirvi tutte le informazioni necessarie.

Alcune regole di buona programmazione

2019-09-20T00:00:00+02:00

Gran parte del mio lavoro consiste nell’avere a che fare con del codice che verrà eseguito da qualche parte. PHP, JavaScript, un server, un browser, importa relativamente.

Spesso capita di avere a che fare con codice scritto da altri e capirci poco. Ci sta: non possiamo essere nella testa di un’altra persona, e fare reverse engineering a volte prende più tempo del normale.

Succede altre volte, invece, di avere il proprio codice davanti agli occhi, e capirci poco comunque. Codice magari vecchio di solo qualche mese. Personalmente, quando mi ritrovo ad aver a che fare con qualcosa di mio scritto più di un anno addietro, guardo a quel codice come un archeologo guarderebbe un reperto sepolto da centrimentri di polvere, scoperto quasi per caso, trattandolo con la circospezione di chi non vuole rompere nulla.

Di recente, tuttavia, ho notato che questo accade sempre meno, ovvero riesco sempre più a guardare codice mio indiscutibilmente vecchio, senza per questo avere impulsi irrefrenabili che mi porterebbero alternativamente a sbattere la testa contro un muro, o riscrivere tutto quanto solo per capriccio.

Magari sono solo migliorato col tempo. Si impara sbagliando, dicevo settimana scorsa. Magari, però, mi sono messo in condizione di fare qualche favore al futuro Andrea che dovrà avere a che fare con il codice che scrivo oggi, usando qualche accorgimento che, mi sento di poter dire, funziona.

Segue ideale top five, snocciolata senza un ordine particolare:

5. Evitare di scrivere codice criptico

Certo, ogni volta che scriviamo del codice, a prescindere dalla funzione che andrà a svolgere, potremmo scriverlo in meno righe, meno caratteri, astraendo ad libitum. Ma saremo ancora in grado di guardarlo tra sei mesi e capire istantaneamente cosa fa?

Il codice va scritto per le persone, a volte anche per le nostre stesse controparti del futuro, quindi facciamoci il favore di renderlo intelleggibile.

4. Commentare, commentare commentare…

Studi recenti dimostrano che aggiungere un commento in corrispondenza della definizione di una classe, una funzione, o un passaggio di una routine convoluta non porta a sviluppare patologie incurabili. Se lo si fa seguendo uno standard, anche meglio.

3. …ma non commentare troppo

Stiamo scrivendo codice, non un sonetto in endecasillabi, quindi aggiungere un commento per ogni riga che scriviamo risulterà inevitabilmente ridondante. Vale, del resto, sempre il punto numero 5: se il codice necessita di essere spiegato passo-passo, forse non è sufficientemente chiaro di suo.

2. Consentire di poter alterare il funzionamento “dall’esterno”

Se stiamo scrivendo una libreria, probabilmente aggiungeremo dei parametri con cui inizializzarla e sfruttarla in maniera differente a seconda del valore dei parametri stessi.

Lo stesso concetto lo possiamo applicare praticamente ad ogni tipo di codice che scriviamo: rendere modificabile e prevedibile il risultato della sua esecuzione, senza toccare il cuore dello stesso.

WordPress, in tal senso, fornisce già di suo gli strumenti per permettere di intervenire “dall’esterno” utilizzando filtri e azioni.

1. Essere pigri è una buona cosa

La pigrizia generalmente è vista come concetto negativo. In programmazione, tuttavia, essere pigri può diventare velocemente un punto di forza del nostro skillset.

Essere pigri, per me, vuol dire anche ottimizzare il proprio flusso di lavoro. Ad esempio, se qualcosa può essere automatizzato, è bene che lo sia. Dici, “ma risparmio sì e no un paio di secondi!”.

Certo, ma quando andremo a sommare tutte le ottimizzazioni del workflow e valutare tutto il tempo che non avremo passato a fare operazioni noiose e ripetitive, beh forse saremo ancor più convinti che essere pigri, in questo campo, non sia poi così male.

Quello che serve

2019-09-09T00:00:00+02:00

Sono arrivato ad un punto della mia parabola lavorativa in cui mi sento di poter dire di avere maturato un po’ di esperienza in quello che faccio.

Nel nostro lavoro le ossa te le fai sbagliando. Ripetutamente. A volte a caro prezzo. Quando mi capita di descrivere la mia storia professionale, mi piace raccontare di aver preso più facciate nel muro di quante io voglia ricordare.

Non c’è una vera e propria formazione accademica. Impari facendo. Magari è vero per tutte le professioni del mondo e sono io, chiuso nella mia piccola bolla, a pensare ingenuamente che il web design sia in qualche modo differente.

Sebbene (spero) involontaria, sbagliare è un’attività insidiosa. Quando si è in proprio, a volte si sbaglia e non si sa neanche perché e, inanellando facciate, a volte capita di pensare di non essere bravi abbastanza, di non avere chances di farcela.

Occorre tener duro, e convincersi che quello che si fa possa rappresentare un valore per chi lo utilizza, e che il modo con cui si lavora faccia la differenza.

La nostra storia in Evolve è fatta di questi e tanti altri pensieri.

Recentemente, stiamo valutando se sia possibile aggiungere un’altra persona al nostro team, che dall’anno scorso può contare anche sul prezioso aiuto di Maria Laura.

Ok, ma come la trovi questa persona? Come fai a capire se la persona ha quel che serve per poter intraprendere un rapporto proficuo?

Beh, vai su LinkedIn, no?

Ecco, andare su LinkedIn porta invariabilmente a passare serate a scartabellare tra i risultati di ricerca, a leggere profili che non possono che raccontare storie parziali, sapendo che, in definitiva, l’unica idea degna d’essere presa in considerazione te la formerai solo parlando con quella persona per più di dieci minuti.

In questi anni mi sono formato un’opinione su cosa serva per far bene il proprio lavoro, e, di riflesso, cosa io cerchi in una persona che voglia lavorare insieme a noi.

A costo di suonare stucchevole, per lavorare bene serve umiltà. Per ammettere i propri errori, già che la formula per l’infallibilità non s’è ancora scoperta, e per considerare non necessariamente da buttare quei punti di vista che non sono nel nostro radar.

Serve razionalità, per imparare dagli errori, e non auto-crocifiggersi quando capita di sbagliare. Occorre non essere pigri, sfidare le proprie consuetudini, ché la nostra bolla gira anche troppo velocemente.

Ma più di tutto serve curiosità, che è la voglia di guardarsi intorno, di sperimentare e, magari, farne altri di sbagli. Diversi, migliori.

C’è una frase che qualcuno attribuisce a Michael Jordan, ma sulla cui paternità avrei qualche dubbio, conoscendo il soggetto. La sostanza rimane, però:

I can accept failure. I cannot accept not trying.

Bravo, Mike.

Psst! Vuoi farti una chiacchierata con noi? Scrivici!

Universi simulati

2019-09-03T00:00:00+02:00

Seguendo l’attuale tendenza secondo cui il cinema d’oltre oceano sia in grado di produrre esclusivamente remake di grandi pellicole del passato, leggo che un quarto capitolo della saga di Matrix è stato ufficialmente confermato.

Matrix, in particolare il primo dei tre, è stato straordinariamente grande un po’ perché ha avuto l’ardire di raccontare la fantascienza associandola a particolari segmenti di cultura e arte popolari, un po’ perché l’ha fatto introducendo al pubblico un concetto nuovo, forse stravagante, certamente inquietante, ponendoci una precisa domanda: e se fossimo tutti parte di una simulazione?

Come The Sims? Beh, sì. Anzi, meglio di The Sims. Matrix non simulava solo un soggiorno con area cottura, ma rappresentava una simulazione su scala planetaria, galattica, universale, che tenesse in considerazione il tutto.

Ora, siccome questo blog vorrei fosse anche un po’ un archivio di documenti che preferirei non smarrire, cosa che mi riesce particolarmente congeniale, riporto in questa sede il lavoro di un tipo, Nick Bostrom, di mestiere filosofo, che la domanda se l’è posta per davvero e l’ha affrontata con la serietà che si dedica ai grandi temi della conoscenza.

Ammettendo, cosa tutt’altro che scontata, di non distruggerci prima, cosa accadrebbe se la nostra potenza tecnologica crescesse a tal punto da consentire la creazione di una simulazione dettagliata quanto la nostra realtà? Sapremmo veramente trattenerci dal tirare su una macchina virtuale e curiosare dentro per vedere, chessò, quante volte su cento simulazioni l’esercito di Sparta tenga effettivamente testa a quello persiano?

Bene, Bostrom conclude che, delle tre seguenti opzioni, almeno una deve essere vera:

L’umanità si autodistruggerà molto prima di raggiungere uno stadio di sviluppo tecnologico che consenta la creazione di simulazioni…
… oppure l’umanità arriverà sì ad essere in grado di creare simulazioni, ma semplicemente sceglierà di non farlo o di non crearne un numero significante…
… oppure è praticamente certo che siamo, oggi, parte di una di quelle simulazioni.

Il ragionamento non fa una grinza. Pure Elon Musk, che sembra avere un’opinione educata su quasi tutto, è d’accordo su come sia non solo possibile, ma anche probabile che noi siamo attualmente parte di un software che gira da qualche parte.

George Smoot, Nobel per la fisica, asserisce che l’umanità potrebbe, un giorno, essere anche in grado di provare la propria appartenenza ad una simulazione.

Recentemente, ha ripreso l’argomento anche il New York Times in un articolo. Il pezzo, tuttavia, scoraggia l’idea di un’indagine volta a dimostrare la nostra essenza cibernetica, dato che l’ipotetica simulazione potrebbe essere spenta qualora i soggetti al suo interno ne scoprissero l’esistenza.

Non è poi così pazzesca come pensata; anche un trial clinico verrebbe annullato qualora il paziente venisse a conoscenza di stare ricevendo il farmaco o il placebo.

Detto questo, Matrix, che a questo punto spero concorderete con me essere molto più di un semplice film di fantascienza, ci viene ancora una volta incontro.

Nel tentativo di spiegare Matrix a Neo, Morpheus dice che, in fondo, ogni contatto tra noi e il mondo esterno è riconducibile ad un impulso elettrico interpretato dal cervello.

Cambia forse qualcosa sapere se quell’impulso è proveniente dal mondo naturale vero, qualsiasi cosa ciò voglia dire, o da un sistema computazionale?

In astratto, sì. Ma, essendo sempre stati all’oscuro della vera natura del nostro universo, arriveremmo anche a ritenere meno autentica la nostra esistenza? Credo di no.

Back to basics

2019-08-26T00:00:00+02:00

A questo punto penso sia evidente come il sottoscritto e il mio blog abbiamo un rapporto, diciamo, conflittuale.

Ora, siccome gli argomenti non mancano, e pure su quella storia della sindrome dell’impostore credo si sia finalmente fatto qualche passo avanti, è tempo di provarne un’altra.

Lavoro con WordPress praticamente la totalità del tempo che spendo in ufficio, ma è un fatto ormai conclamato che quando devo scrivere qualcosa di più lungo di un Tweet io passi invariabilmente per usare una qualche forma di Markdown.

Non credo che questo voglia dire necessariamente qualcosa di specifico riguardo a Gutenberg, il nuovo editor di cui la piattaforma WordPress si è dotata recentemente, quanto piuttosto che, a volte, è difficile spezzare un’abitudine, ammesso che ciò debba essere fatto.

In più, l’idea di tornare alle basi dello sviluppo e del design per il Web e creare qualcosa da zero, autonomamente, come mi piaceva fare anni e anni fa, quando ho iniziato a studiare per poter permettermi, un giorno, il lusso di svolgere questa professione, risale ormai a qualche mese addietro.

Quindi, ecco a voi la nuova edizione del sito del sottoscritto, basata su Jekyll, un generatore statico di pagine Web, che immagino tanti conosceranno. Per quelli che fossero nuovi al concetto, statico significa che su queste pagine non c’è neanche l’ombra di PHP, ma solo HTML (grazie a Liquid, il template engine su cui si basa Shopify), e CSS, linguaggio che, sotto la sapiente supervisione di Simone, sto imparando nuovamente ad apprezzare.

Niente PHP/WordPress? Nel 2019? Beh, sì, a seconda del tipo di progetto che si deve realizzare questo esperimento mi sta confermando come l’alternativa statica sia non solo percorribile, ma anche vincente, se quel che serve è un sito di contenuto che strizzi più di un occhio alle performance.

Statico vuol dire overhead ridotto al minimo, e time to first byte coincidente con la risposta stessa del server, dato che non ci sono computazioni da fare. Ah quindi ora fai 100% su Google Page Speed? No, beh, non crederete mica che non arrivi anche qui lo script di Google Analytics a guastare la festa, vero?

Un’alternativa a file_get_contents

2016-09-06T00:00:00+02:00

Le linee guida del gruppo Theme Review su WordPress.org sono molto stringenti in alcuni casi, e per una ragione più che buona: queste best practice, consigli e regole sono volte a far sì che il rischio che codice scadente venga pubblicato sia ridotto al minimo.

Una di quelle regole proibisce categoricamente le operazione dirette sui file, a meno che non siano eseguite attraverso la Filesystem API. A causa di questo vincolo, l’utilizzo di una funzione altrimenti molto utile come file_get_contents è proibito; non solo, qualora la usassimo, il plugin Theme Check ci segnalerebbe il suo utilizzo come un errore da correggere.

Per letture locali, comunque, esiste un modo per accedere ai contenuti di un file senza utilizzare file_get_contents:

$content = implode( '', file( $path_to_file );

che essenzialmente accede al file riga per riga, memorizza le righe stesse in un array, salvo poi unirle a formare una stringa unica.

Chiamate remote a URL con WordPress

2016-07-15T00:00:00+02:00

Quando si vuole integrare WordPress con sistemi esterni, spesso si passa per le API dei servizi stessi, ovvero effettuare chiamate in maniera programmatica a URL ben definiti, i quali rispondono con un set di dati che andremo poi ad elaborare.

Ora, tipicamente, quando detti servizi inseriscono nella documentazione degli esempi in PHP da seguire, il codice riportato fa uso di cURL, una libreria ampiamente diffusa che serve, appunto, a chiamare un URL e conservare il contenuto della risposta.

Sebbene perfettamente adeguato allo scopo, due sono, per quel che mi riguarda, i problemi nell’utilizzare cURL.

Per cominciare, la sua sintassi non è di immediata memorizzazione:

$curl = curl_init( 'https://andreagandino.com' );
curl_setopt( $curl, CURLOPT_POST, true );
curl_setopt( $curl, CURLOPT_POSTFIELDS, array( 'field1' => 'primo parametro', 'field2' => 'secondo parametro' ) );
curl_setopt( $curl, CURLOPT_RETURNTRANSFER, true );
$response = curl_exec( $curl );
curl_close( $curl );

Inoltre, su alcuni server cURL potrebbe, per ragioni di sicurezza, essere disabilitato, rendendo completamente vano il codice riportato sopra.

In casi come questo, WordPress viene incontro allo sviluppatore, mettendo a disposizione funzioni di alto livello che consentono non solo di bypassare la verbosità del codice precedentemente illustrato, ma di fornire anche un fallback, qualora cURL non sia disponibile.

È il caso delle funzioni wp_remote_get e wp_remote_post, le quali consentono di effettuare chiamate a URL remoti, senza preoccuparsi tropp dei dettagli tecnici sottesi alle chiamate stesse (per chi volesse approfondire, entrambe le funzioni si basano sulla classe WP_Http).

La parola chiave di tutto questo discorso è però l’aggettivo “remoto”.

Può capitare, com’è successo a noi quando stavamo progettando l’infrastruttura del nostro shop, di dover simulare, sulla stessa macchina, sia il server, sia un client; dal momento che WordPress, diciamo, valida gli URL che chiama tramite le proprie funzioni, ogni chiamata verso un indirizzo locale verrà irrimediabilmente rigettata.

Esiste, però, un filtro molto utile in questo caso che, se applicato, consente di “far credere” a WordPress che qualsiasi chiamata effettuata tramite la HTTP API sia diretta ad un host remoto, anche quando così non fosse.

add_filter( 'http_request_host_is_external', '__return_true' );

Ovviamente, questa direttiva deve tassativamente essere applicata esclusivamente in fase di sviluppo e, qualora decidessimo di utilizzarla, dovremo successivamente assicurarci che non faccia parte del sorgente di produzione.