Commenti

Faster TDD with iTerm and vim

A couple of weeks ago Josh Davey released turbux, a great vim plugin that aims to keep your TDD feedback loop faster and less prone to unnecessary context-switches through the use of split sessions and tmux.

Before you continue reading this post, check out the announcement post on his blog, so you know what we're talking about.

iTerm anyone?

Anything that can speed up our TDD loop has to be taken very seriously, so I tried to port the same concepts to my personal development habits.

In my day-to-day work I make use of iTerm 2, a great replacement to the default Mac terminal application. iTerm provides both split and tab sessions; furthermore, it supports the use of AppleScript to automate many aspects of its behavior.

I asked myself whether I really needed to add an "extra layer" to my usual stack — that is, tmux — or rather if I could achieve the same result without it. Turns out it was not the case.

How to communicate with iTerm

Man, I hate AppleScript. Approximately 90% of the entire time spent on this small project was just to learn the minimum necessary to write this:

1 #! /usr/bin/osascript
2 tell application "iTerm"
3   tell the current terminal
4     tell (first session Whose name contains "foo")
5       text write ("echo bar" as text)
6     end tell
7   end tell
8 end tell

This code searches in the current iTerm window for a session named "foo", and sends the command echo bar to it. As you might have guessed, we just built a bridge between vim and an iTerm session.

Welcome iTermux!

Next step was to fork the turbux plugin, rename it into itermux (how original, right?) and replace its Send_to_Tmux() function with a parametrized version of the snippet mentioned above:

 1 function! Send_to_iTerm(command)
 2   let app = 'iTerm'
 3   if exists("g:itermux_app_name") && g:itermux_app_name != ''
 4     let app = g:itermux_app_name
 5   endif
 6   let session = 'iTermux'
 7   if exists("g:itermux_session_name") && g:itermux_session_name != ''
 8     let session = g:itermux_session_name
 9   endif
10 
11   let commands =  [ '-e "on run argv"',
12                   \ '-e "tell application \"' . app . '\""',
13                   \ '-e "tell the current terminal"',
14                   \ '-e "tell (first session whose name contains \"' . session . '\")"',
15                   \ '-e "set AppleScript''s text item delimiters to \" \""',
16                   \ '-e "write text (argv as text)"',
17                   \ '-e "end tell"',
18                   \ '-e "end tell"',
19                   \ '-e "end tell"',
20                   \ '-e "end run"' ]
21 
22   let complete_command = "osascript " . join(commands, ' ') . " " . a:command
23   system(complete_command)
24 endfunction

As you can see, I've made it possible to change the name of the iTerm app and the name you want to give to the iTerm session dedicated to testing, i.e.:

1 let g:itermux_session_name = 'testing'
2 let g:itermux_app_name = 'iTerm2'

Demo Time

I've prepared a small video to show how cool it is the final result. I've been using this setup for two weeks now, and it's been so rewarding.

Feedbacks appreciated!

Download it, install it, and let us know what you think of it!

Commenti

Come testare i propri controller in isolamento: un esempio reale con CanCan

TL;DR Questo è un post per sviluppatori Rails di media esperienza. L'obiettivo di questo (lungo) tutorial è quello di guidare il lettore passo passo verso le possibili tecniche per testare i propri controller, evidenziandone problematiche e vantaggi. Arriveremo al termine del tutorial ad un soluzione rapida e mantenibile, che testi in completo isolamento il controller e che farà uso di strumenti come stubs e mocks.

Nella stragrande maggioranza dei progetti ci si ritrova a dover gestire autorizzazioni e ruoli per gli utenti. La gemma più popolare per questo compito è senza dubbio CanCan. Mi sembra questo un ottimo esempio concreto da sfruttare per la trattazione.

Nella Wiki del progetto su Github, il buon Ryan Bates elenca un paio di possibili suggerimenti per approcciarsi al problema dei test funzionali. Nei passati progetti ho cercato di seguirli diligentemente, ma la verità è che sono esempi pessimi se seguiti nel mondo reale.

Partiamo con l'analizzare meglio i problemi.

Continua a leggere

Commenti

Ottimizzare la leggibilità del proprio sito con Compass /3

Bene, dopo una sfarinatura su come mantenere un ritmo verticale tramite Compass, su come impostare una scala tipografica, su come gestire in maniera ottimale i font-size mediante em, arriviamo all'ultimo passaggio: come scegliere in maniera ottimale line-height e font-size per il tag <body>, ovvero le dimensioni che saranno di riferimento per l'intero sito?

La soluzione non è ovviamente farina del mio sacco, ma si rifà al concetto di Golden Ratio Typography, ideato da Chris Pearson.

L'impianto della trattazione si basa su due evidenze provabili empiricamente da chiunque:

  • Le proprietà font-size e line-height sono legate linearmente: per mantenere un testo leggibile, se una aumenta l'altra dovrà aumentare proporzionalmente;
  • Similmente, larghezza del corpo del testo (da qui in poi line-width) e line-height sono legate linearmente: più la larghezza aumenta, più difficile diventa per l'occhio umano seguire le linee di testo, e dunque diventa necessario aumentare anche l'interlinea.

Chris Pearson si è spinto oltre, cercando di legare numericamente queste grandezze, facendo uso del famoso rapporto aureo:

Line heightLine width

Quindi, è sufficiente scegliere il font-size di riferimento, per esempio 16px, e line-height e line-width verranno da sè:

1 $phi-const: 1.61803399
2 $base-font-size: 15px
3 $base-line-height: $base-font-size * $phi-const
4 $base-line-width: $base-line-height * $base-line-height

In linea teorica, il concetto termina qui. Dal punto di vista pratico però, i nostri schermi lavorano su un'unità di misura non "spezzabile": il pixel. Il calcolo riportato porterebbe ad una interlinea di 24.27px, ovviamente non realizzabile. Occorrerebbe portarlo a 24px, ma non sarebbe l'arrotondamento ottimale.

Matematicamente parlando, ciò che bisogna realizzare è un "minimizzatore" di errore, in grado di ricercare il minimo locale. Trovare dunque la combinazione di pixel "interi" per font-size, line-height e line-width che globalmente più si avvicinano ai valori aurei.

Non si tratta di calcoli piacevolissimi, e fortunatamente Chris Pearson ha creato il Golden Ratio Typography Calculator, che fa tutto il lavoro sporco per noi. Possiamo fissare sul calcolatore il font-size prescelto, o piuttosto la larghezza del contenuto, o entrambi. Il buon calcolatore ci restituirà il line-height ottimale, oltre a suggerirci eventuali cambiamenti di dimensioni che potrebbero ulteriormente migliorare la resa.

Niente. Dovrei aver finito, siete pronti per rendere i vostri blog super-leggibili. La mia parentesi tipografica si chiude temporaneamente.

Per un po' ritornerò a parlare di codice, tante cose bollono in pentola!

Commenti

Ottimizzare la leggibilità del proprio sito con Compass /2

Al termine del post precedente, abbiamo visto come mantenere tutte le interlinee multiple tra di loro permetta una maggiore leggibilità del testo. Per essere più chiari, ecco un esempio di ciò di cui stiamo parlando.

Nel mondo web, l'unità base di spazio verticale è rappresentata dalla regola CSS line-height.

Line height

Una line-height rimane costante nella pagina fino a quando non intervengono cambi di font-size, margin, padding o border. A questo punto tipicamente il flusso si spezza producendo interlinee non multiple.

Riuscire a impostare dimensioni di margin, padding e border tali da preservare il flusso verticale in tutta la pagina richiede una serie di calcoli non particolarmente complessi, ma sicuramente poco divertenti.

Fortunatamente Compass include un modulo poco documentato ma ottimo in grado di alleviare di molto questo problema.

Vertical Rythm con Compass

Una volta importato il modulo tramite la direttiva

1 @import "compass/typography/vertical_rhythm"

siamo pronti a partire specificando il font-size e la line-height che abbiamo scelto per il corpo principale del testo:

1 $base-line-height: 25px
2 $base-font-size: 15px
3 
4 +establish-baseline

Il mixin +establish-baseline si occupa proprio di impostare questi due valori sul selettore body (utilizzando come unità di misura l'em per evitare problemi di resize su browser legacy).

Una volta proceduti col seguente setup del modulo, l'unica regola da ricordare è questa: le proprietà `font-size`, `line-height`, `margin`, `padding` e `border` non vanno mai toccate manualmente, perchè spezzerebbero il ritmo. Per modificarle è necessario passare attraverso appositi mixin di Compass.

Supponiamo di voler stilizzare il tag h1, portando il font-size a 24px, e aggiungendo del margine in basso. Non possiamo più fare:

1 h1
2   font-size: 24px
3   margin-bottom: 15px

Ma dovremo invece scrivere qualcosa come:

1 h1
2   +adjust-font-size-to(24px, 2)
3   +padding-trailer(3, 24px)

Il primo mixin utilizzato, +adjust-font-size-to, oltre ad impostare il nuovo font-size, modificherà la line-height dell'elemento in modo tale da preservare l'interlinea originaria di 25px, od un suo multiplo. Il secondo parametro, impostato nell'esempio a 2, imposterà un line-height effettivo di 25px * 2 = 50px.

Il mixin +padding-trailer, similmente, imposterà un padding-bottom in em pari esattamente a 26px * 3 = 75px. Esistono ovviamente tutta una serie di mixin analoghi per gestire allo stesso modo margini, padding e bordi superiori e inferiori.

E' importante ricordare di utilizzare numeri interi come parametri per tali mixin, a meno che la somma totale non risulti comunque essere un intero:

1 h1
2   +adjust-font-size-to(24px, 1.5)
3   +padding-leader(0.5, 24px)
4   +padding-trailer(1, 24px)

Questo esempio è comunque valido in quanto 1.5 + 0.5 + 1 = 3, che continua ad essere un numero intero.

Ci fermiamo anche oggi

Nel prossimo post andremo ad analizzare l'ultima questione fondamentale per la leggibilità: in base a quali parametri dovremo andare a scegliere il $base-line-height e $base-line-height ottimale per la nostra pagina.

Referenze

Commenti

Ottimizzare la leggibilità del proprio sito con Compass /1

Nel recente restyling di questo blog mi sono concentrato sul rendere la lettura di ogni pagina il più piacevole possibile. Era un campo inesplorato per me, e sono talmente eccitato delle scoperte fatte e del risultato ottenuto che non posso non riassumervi qualcosa.

Innanzitutto, non stiamo parlando di tematiche specifiche per il web. I tipografi si occupano di questa materia da centinaia d'anni, ed è proprio dalle loro regole d'oro che bisogna partire.

In questa prima parte inizierò col descrivere le regole teoriche, nel prossimo post vedremo come applicarle in assoluta semplicità grazie ai vari mixin di Compass.

Non comporre mai una pagina senza una scala tipografica

Una delle regole fondamentali è questa: ogni variazione di font-size che si desidera introdurre nella pagina deve seguire una scala predefinita e regolare.

Non esiste una sola scala possibile; esistono differenti scale celebri e riconosciute come "naturali e piacevoli alla vista" in campo tipografico:

La scelta di una di queste scale va fatta a seconda del contesto e del proprio gusto personale. Per quanto mi riguarda, ho deciso di utilizzare la scala tipografica, con un'unica differenza, ovvero quella di scegliere un font-size di 15px (invece che 16px come consigliato) per il contenuto principale della pagina (il corpo del post). Sul perchè di questa scelta ci torneremo nel prossimo post.

La scala tipografica

Tutti gli altri font-size seguono la medesima scala: nel mio caso ho scelto 18px per gli h3, 21px per gli h2 e gli 24px per gli h1.

Mantieni un unico ritmo verticale nella pagina

Il concetto astratto di leggibilità si posa in gran parte sul concetto ben più materiale di interlinea (in inglese, leading): è lo spazio fra la linea di base di una riga e quella della successiva.

Conservare l'interlinea immutata nel flusso dell'intera pagina aiuta immensamente a renderla più piacevole e coerente.

Progettare una pagina con ritmo verticale significa scegliere una interlinea di riferimento e fare in modo che tutte le interlinee presenti nella pagina presenti siano un suo multiplo.

Piccola digressione sull'em

L'em è una unità di misura relativa: il suo valore in pixel dipende direttamente dal font-size assegnato all'elemento stesso.

1 body
2   font-size: 16px
3   line-height: 1.5em

Nell'esempio, l'interlinea varrà 16px * 1.5 = 24px, e mi permetterà quindi di ottenere uno spazio vuoto tra le righe di testo pari a 24px - 16px = 8px.

Altra cosa fondamentale da ricordare è che la direttiva line-height viene ereditata dagli elementi del DOM sottostanti:

1   body
2     font-size: 16px
3     line-height: 1.5em
4 
5     h1
6       font-size: 18px

In questo caso, il tag h1 avrà anch'esso un line-height pari a 1.5em, ma questa si tradurrà in una interlinea pari a 18px * 1.5 = 27px.

Ultima cosa da ricordare riguardo all'em:

1 body
2   font-size: 16px
3   line-height: 1.5em
4 
5   h1
6     font-size: 1.5em

Se è proprio la direttiva font-size ad avere una misura espressa in em, allora questa sarà una misura relativa al font-size dell'elemento padre. Nel nostro caso, il font-size per l'elemento h1 sarà di 16px * 1.5 = 24px, con una interlinea pari a 24px * 1.5 = 36px.

Impostare tutte le grandezze in em ci permette dunque di far discendere tutte le proporzioni direttamente da un'unico parametro, il font-size che si stabilisce per il body.

Per oggi basta

Nel prossimo post vedremo:

  • come arrivare matematicamente al un valore di interlinea ottimale per la propria pagina;
  • come ruscire ad ottenere un ritmo verticale facendo uso degli em;
  • come applicare tutta questa teoria ai nostri fogli di stile Sass con dei semplici mixin.

Aspetto i vostri commenti!