Stefano Verna

Faster TDD with iTerm and vim

2012-02-06T00:00:00+01:00

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:


#! /usr/bin/osascript
tell application "iTerm"
  tell the current terminal
    tell (first session Whose name contains "foo")
      text write ("echo bar" as text)
    end tell
  end tell
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:


function! Send_to_iTerm(command)
  let app = 'iTerm'
  if exists("g:itermux_app_name") && g:itermux_app_name != ''
    let app = g:itermux_app_name
  endif
  let session = 'iTermux'
  if exists("g:itermux_session_name") && g:itermux_session_name != ''
    let session = g:itermux_session_name
  endif

  let commands =  [ '-e "on run argv"',
                  \ '-e "tell application \"' . app . '\""',
                  \ '-e "tell the current terminal"',
                  \ '-e "tell (first session whose name contains \"' . session . '\")"',
                  \ '-e "set AppleScript''s text item delimiters to \" \""',
                  \ '-e "write text (argv as text)"',
                  \ '-e "end tell"',
                  \ '-e "end tell"',
                  \ '-e "end tell"',
                  \ '-e "end run"' ]

  let complete_command = "osascript " . join(commands, ' ') . " " . a:command
  system(complete_command)
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.:


let g:itermux_session_name = 'testing'
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!

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

2012-01-29T00:00:00+01:00

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.

Un esempio concreto

Prendiamo come esempio una azione classica azione custom che fa uso di CanCan:



class ItemsController < ApplicationController
  load_and_authorize_resource :project
  load_and_authorize_resource :item, :through => :project

  # /projects/:project_id/items/:id/add_tag?tag_id=XXX
  def add_tag
    @tag = Tag.find(params[:tag_id])
    authorize! :read, @tag
    @item.tags << @tag

    respond_with @item
  end
end

Il modello Item appartiene ad un Project. L'azione add_tag prevede un parametro aggiuntivo in GET, :tag_id. Cosa fa il metodo? Aggiunge il tag alla collezione dei tag dell'item stesso. Semplice ed indolore.

Le autorizzazioni più o meno implicite che CanCan esegue nel corso di questa azione sono le seguenti:


can? :show, @profile
can? :add_tag, @item
can? :read, @tag

Definiamo dunque nella classe Ability le seguenti regole:



def initialize(user)
  if user.present?
    can :show, Project, user_id: user
    can :add_tag, Item, project_id: user.projects
    can :read, Tag, public: true
  end
end

In pratica, stiamo dicendo a CanCan che:

un utente può accedere solo ai suoi progetti;
che può aggiungere tag ad un item solo se 1) ne è il proprietario e 2) se il tag stesso è pubblico.

Ora proviamo a scrivere il test secondo i suggerimenti nella Wiki.

Testare l'azione, Integration-style

La prima soluzione suggerita da CanCan per testare il controller è la seguente:



describe ItemsController do
  describe "#add_tag" do

    before do
      @user = Factory.create(:user)
      controller.stubs(:current_user).returns(@user)
    end

    context "if the user passes all the authorizations" do
      it "adds the specified tag to the item if authorizatio" do
        @project = Factory.create(:project, user: @user)
        @item = Factory.create(:item, project: @project)
        @tag = Factory.create(:tag, public: true)

        get :add_tag, project_id: @project, id: @item, tag_id: @tag

        @item.tags.should include @tag
        response.should be_success
      end
    end

  end
end

In pratica, ci comportiamo come nel più classico degli integration tests: prima creiamo tutti i modelli necessari per far funzionare l'azione, dopodichè la eseguiamo, e al termine controlliamo il risultato finale, sia in termini di modello modificato che di status code della risposta generata.

Fantastico! Anzi, no.

Certo, questo è un possibile metodo per testare l'azione del controller. Il vantaggio è l'estrema semplicità di scrittura. Il grosso contro è che in realtà non stiamo testando solo il controller, ma implicitamente anche una marea di altre cose:

I modelli dati in pasto all'azione vengono salvati su DB: se per caso il DB non fosse stato migrato correttamente, il test fallirebbe, a prescindere dalla non colpevolezza del codice del controller;
Se tra qualche giorno dovessimo aggiungere al modello Project un nuovo attributo :title con presenza obbligatoria (validates :title, presence: true), il test fallirebbe perchè non riuscirebbe più a creare un oggetto Project, ma, di nuovo, l'azione add_tag sarebbe totalmente innocente;
Se in futuro dovessero cambiare i meccanismi all'interno di Ability secondo i quali l'autorizzazione viene concessa, il test fallirebbe, e di nuovo non sarebbe colpa del controller.

Quindi, in altre parole, stiamo creando un test di difficile mantenibilità futura, in quanto troppo dipendente e legato a fattori ed oggetti esterni.

Un test del genere poi da solo non sarebbe sufficiente: in questo modo stiamo testando unicamente l'esecuzione con successo dell'azione, ma a questo punto dovremmo anche preoccuparci di testare il comportamento del controller nel caso in cui l'utente provi a lanciare l'azione senza avere uno dei permessi sopra citati, per assicurarci che venga adeguatamente bloccato. I test diventerebbero allora quattro, per una sola azione!


context "if the user passes all the authorizations" do
  it "adds the specified tag to the item" do
    # ...
  end
end

context "if the user cannot :show the Project" do
  it "raises a CanCan::AccessDenied exception" do
    # ...
  end
end

context "if the user cannot :add_tag to the Item" do
  it "raises a CanCan::AccessDenied exception" do
    # ...
  end
end

context "if the user cannot :read the Tag" do
  it "raises a CanCan::AccessDenied exception" do
    # ...
  end
end

Consideriamo ora anche il fattore velocità. I test di integrazione sono lenti per loro stessa natura: il loro compito è quello di riprodurre per filo e per segno quello che è il flusso normale di utilizzo dell'applicazione, con tutte le innumerevoli interazioni con la base dati e gli altri oggetti che compongono la logica dell'applicazione.

I quattro test del genere impiegano circa un secondo per venire eseguiti! Se consideriamo una applicazione semplice con una media di 4-5 azioni per 10 controller, arriviamo tranquillamente al minuto.

Se il tempo non sembra poi così alto, ricordiamoci che stiamo parlando di controller, la componente dell'applicazione che dovrebbe essere più snella in assoluto! Dev'esserci qualcosa di meglio per testare le quattro dannatissime righe di codice dell'azione!

Isolarsi da `Ability`: un primo passo verso la speranza

La solita Wiki ci suggerisce che è possibile testare il comportamento del controller indipendentemente da ciò che viene specificato dal file Ability. Vediamo come:


describe "#add_tag" do

  before do
    @ability = Object.new
    @ability.extend(CanCan::Ability)
    controller.stubs(:current_ability).returns(@ability)
  end

  context "if the user passes all the authorizations" do
    it "adds the specified tag to the item" do
      @ability.can(:show, Project)
      @ability.can(:add_tag, Item)
      @ability.can(:read, Tag)

      project = Factory.create(:project)
      item = Factory.create(:item)
      tag = Factory.create(:tag)

      get :add_tag, project_id: project, id: item, tag_id: tag

      item.tags.should include tag
      response.should be_success
    end
  end

end

Il test si basa sulla consapevolezza che CanCan fa uso del metodo current_ability del controller per sapere quale dev'essere l'oggetto con modulo CanCan::Ability da utilizzare per i test di autorizzazione.

Il comportamento standard del metodo current_ability è quello di restituire un'istanza della classe Ability, ma nel blocco before del test sostituiamo l'oggetto che l'applicazione normalmente restituirebbe con un suo alter-ego, che possiamo però modificare a piacimento a seconda dei test. Questa è una delle tecniche fondamentali di testing: viene chiamata stubbing.

Notate come nelle righe 15-17 non abbiamo più bisogno di specificare le relazioni tra progetto, item e tag, perchè prima dell'esecuzione del test, nelle righe 11-13 stiamo forzando un successo nell'autenticazione.

In altre parole, abbiamo a tutti gli effetti isolato il test sul controller dalla classe Ability dell'app. Sarà compito dei test sulla classe Ability controllare che esso autorizzi solo nel caso in cui i modelli sono legati tra loro in maniera corretta. Tutti i test sulle azioni dei controller danno per assodato questo fatto, bypassano la classe Activity e dunque eviteranno di spaccarsi nel caso di suoi cambiamenti futuri.

Non è compito del test su un controller assicurarsi che con determinati modelli venga fornita una certa autorizzazione. Il suo compito è quello di verificare il comportamento del controller a seconda delle possibili risposte di autorizzazione che gli vengono fornite da CanCan.

Attenzione: continuiamo ad aver bisogno di quattro differenti test per controllare il diverso comportamento del controller nelle varie casistiche di permesso autorizzato/non autorizzato — e i test continuano ad essere lenti perchè stiamo ancora scrivendo su DB — ma quantomeno abbiamo ottenuto qualcosa di più mantenibile!

Avanti tutta! Isoliamoci dai modelli!

Iniziamo ad intravedere la via del successo. Proviamo ad applicare il medesimo approccio di isolamento e stubbing anche ai modelli coinvolti.


describe "#add_tag" do
  before do
    @ability = Object.new
    @ability.extend(CanCan::Ability)
    controller.stubs(:current_ability).returns(@ability)
  end

  context "if the user passes all the authorizations" do
    it "adds the specified tag to the item" do
      @ability.can(:show, Project)
      @ability.can(:add_tag, Item)
      @ability.can(:read, Tag)

      project = stub_model(Project)
      item = stub_model(Item)
      tag = stub_model(Tag)

      Project.stubs(:find).with(project.to_param).returns(project)
      project.stubs(:items).returns(stub('Association', name: 'items', find: item))
      Tag.stubs(:find).with(tag.to_param).returns(tag)

      get :add_tag, project_id: project, id: item, tag_id: tag

      item.tags.should include tag
      response.should be_success
    end
  end
end

Nelle righe 14-16 invece che salvare su DB dei modelli veri, creiamo dei model stub: oggetti che hanno sembianze di modelli ActiveRecord correttamente salvati su DB — hanno per esempio id incrementali, fingono di essere istanze del modello specificato e rispondono a metodi ActiveRecord classici quali errors o to_param — ma che sono totalmente sintetici e non persistenti.

A questo punto, per portare a buon fine il test è necessario sapere come si comporta CanCan nella fase di caricamento delle risorse per questa azione (i comportamenti ben documentati nella Wiki):


@project = Project.find(params[:project_id])
@item = project.items.find(params[:id])

Nelle righe 18-20 ora siamo in grado di eseguire lo stubbing delle medesime chiamate, inducendo CanCan a ritornarci invece che modelli veri i nostri modelli farlocchi.

Di nuovo, abbiamo a tutti gli effetti isolato il test sul controller dai veri modelli dell'app, e da ActiveRecord in generale: se tra qualche giorno dovessimo aggiungere al modello Project un nuovo attributo obbligatorio, il test questa volta non fallirebbe più.

Il controller di per sé si aspetta che esistano dei modelli salvati su DB. Non è compito del test su un controller inizializzare e salvare modelli. E' sufficiente assicurarsi che il controller effettivamente effettui delle chiamate per fetcharli.

L'ultimo passaggio: un test che ne vale quattro (WHOA!)

Anche nell'ultima versione del test, continuiamo a forzare il successo dell'autenticazione mediante stubbing del metodo current_ability. Questo significa che se in un test forziamo il successo, dovremo automaticamente avere altri test per forzare anche l'insuccesso, di modo da poter verificare che l'azione effettivamente faccia uso delle Ability, e che dunque blocchi l'utente.

La soluzione per ridurre i test ad uno, e uno solo, è questa:


describe "#add_tag" do
  context "if the user passes all the authorizations" do
    it "adds the specified tag to the item" do
      project = stub_model(Project)
      item = stub_model(Item)
      tag = stub_model(Tag)

      should_authorize(:show, project)
      should_authorize(:add_tag, item)
      should_authorize(:read, tag)

      Project.stubs(:find).with(project.to_param).returns(project)
      project.stubs(:items).returns(stub('Association', name: 'items', find: item))

      Tag.stubs(:find).with(tag.to_param).returns(tag)

      get :add_tag, project_id: project, id: item, tag_id: tag

      item.tags.should include tag
      response.should be_success
    end
  end
end

E' cambiato poco, in superficie: il blocco before che stubbava il metodo current_ability del controller se ne è andato, e le tre chiamate ad @ability.can sono state sostituite da un fantomatico metodo, che ho chiamato should_authorize, con una semantica molto simile.

Cosa sta succedendo? Succede che andiamo ancora più alla fonte. CanCan, dopo aver caricato i modelli, fa subito uso del metodo authorize! del controller per testare l'autorizzazione da parte dell'utente. E' authorize! che fa uso del metodo current_ability finora simulato.

Andiamo a vedere il codice dell'helper RSpec should_authorize:


def should_authorize(action, subject)
  controller.expects(:authorize!).with(action, subject).returns('passed!')
end

Invece che stubbare current_ability, ora stiamo stubbando direttamente authorize!, facendolo passare sempre e comunque, ma non solo: utilizziamo il metodo expects invece che stubs. La differenza è piccola ma fondamentale. Il metodo expects non solo modifica la risposta, ma fa fallire il test se quel dato metodo, con quei dati parametri, non verrà effettivamente chiamato durante il corso dell'azione del controller. Questa variante di stubbing viene comunemente chiamata mocking, e ci permette di essere tranquilli sull'effettiva protezione implementata dal controller.

Non è compito del test su un controller assicurarsi che CanCan faccia uso della classe Ability per far passare o meno l'autorizzazione ad una azione. Ne tantomeno che il metodo authorize! lasci passare l'utente o lanci un'eccezione. Questo tipo di testing è già stato fatto a livello di gemma. Il controller deve semplicemente assicurarsi che il metodo authorize! messogli a disposizione dalla gemma stessa venga effettivamente chiamato.

Abbiamo finito? SRSLY?!

A questo punto possiamo — se solo Dio volesse — dirci soddisfatti. Abbiamo un solo test per il controller. Un test che totalmente isolato dal resto dell'app, che non si spaccherà se non per motivi reali e dipendenti dall'azione stessa, e che — non facendo uso del livello database — verrà eseguito in pochi millisecondi.

Scusate per il disagio del post. Spero che possa essere utile a qualcuno!

Ottimizzare la leggibilità del proprio sito con Compass /3

2012-01-22T00:00:00+01:00

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:

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


$phi-const: 1.61803399
$base-font-size: 15px
$base-line-height: $base-font-size * $phi-const
$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!

Ottimizzare la leggibilità del proprio sito con Compass /2

2012-01-12T00:00:00+01:00

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.

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


@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:


$base-line-height: 25px
$base-font-size: 15px

+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:


h1
  font-size: 24px
  margin-bottom: 15px

Ma dovremo invece scrivere qualcosa come:


h1
  +adjust-font-size-to(24px, 2)
  +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:


h1
  +adjust-font-size-to(24px, 1.5)
  +padding-leader(0.5, 24px)
  +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

Compose to a Vertical Rhythm, Richard Rutter
Scale & Rhythm, Iain Lamb
Vertical Rythm Module, Compass Documentation

Ottimizzare la leggibilità del proprio sito con Compass /1

2012-01-11T00:00:00+01:00

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:

Le successioni di Fibonacci;
Il celebre Modulor di Le Corbusier;
Il rapporto aureo;
La storica e tradizionale "scala tipografica";

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.

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.


body
  font-size: 16px
  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:


  body
    font-size: 16px
    line-height: 1.5em

    h1
      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:


body
  font-size: 16px
  line-height: 1.5em

  h1
    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!

rspec-given: e se fosse la soluzione?

2012-01-10T00:00:00+01:00

Tornando a bomba sui miei interrogativi passati, potrei aver trovato una soluzione in grado di permettere una maggiore descrittività ai test -- in stile Gherkin -- ma al tempo stesso "sicura" (ovvero che non utilizzi librerie TDD ancora in stato alpha).

La soluzione si chiama rspec-given è non è altro che una leggera DSL sopra ad RSpec, che permette di utilizzare dei blocchi Given, When e Then.

Esempio d'ordinanza:


describe Stack do

  def stack_with(initial_contents)
    stack = Stack.new
    initial_contents.each { |item| stack.push(item) }
    stack
  end

  Given(:stack) { stack_with(initial_contents) }

  context "when empty" do
    Given(:initial_contents) { [] }
    Then { stack.depth.should == 0 }

    context "when pushing" do
      When { stack.push(:an_item) }

      Then { stack.depth.should == 1 }
      Then { stack.top.should == :an_item }
    end
  end

end

Direi che la cosa migliore è provarlo per trovarne eventuali lati negativi o brutture. Vi faccio sapere.

TDD è meglio che fare Unit Testing a posteriori

2012-01-09T00:00:00+01:00

Forse non ce n'era il bisogno, ma se vi dovesse servire una ulteriore prova inconfutabile che scrivere i test mentre stai scrivendo il codice sia meglio che testare il codice a latere, eccola.

Questo è il codice del controller che avevo scritto per gestire una autenticazione OAuth verso Twitter in un precedente progetto:



class OauthController < ApplicationController

  def twitter_oauth
    oauth_consumer = TwitterUser.oauth_consumer
    request_token = oauth_consumer.get_request_token(:oauth_callback => team_twitter_callback_url(@team))
    session['request_token'] = request_token.token
    session['request_secret'] = request_token.secret
    redirect_to request_token.authorize_url
  end

  def twitter_oauth_callback
    oauth_consumer = TwitterUser.oauth_consumer
    request_token = OAuth::RequestToken.new(oauth_consumer, session['request_token'], session['request_secret'])
    access_token = request_token.get_access_token(:oauth_verifier => params[:oauth_verifier])

    client = TwitterUser.client(access_token.token, access_token.secret)
    user = TwitterUser.initialize_with_twitter_data(client.verify_credentials)
    user.team = @team
    user.access_token = access_token.token
    user.access_secret = access_token.secret
    user.save

    flash_message :notice, "A new Twitter account has been successfully added."
    redirect_to profile_path(@team)
  end

end

Codice che funziona, a prima vista. Ma un po' troppo complicato per essere un controller, o no? E cosa succede se per caso qualcosa va come non dovrebbe? Il codice è pronto a gestire tutti i casi?

Questo è il medesimo codice, ma riscritto in TDD:



class OauthController < ApplicationController

  def twitter_oauth
    request = TwitterProfile.oauth_authorization_request(twitter_callback_url)
    session['request_token'] = request.token
    session['request_secret'] = request.secret
    redirect_to request.authorize_url
  end

  def twitter_oauth_callback
    profile = TwitterProfile.new_from_oauth_authorization_response(session['request_token'], session['request_secret'], params[:oauth_verifier])
    profile.user = current_user
    if profile.save
      redirect_to profile_path(profile), notice: "A new Twitter account has been successfully added."
    else
      redirect_to new_profile_path, alert: "We were no able to add the Twitter account: #{formatted_record_errors(profile)}"
    end
  rescue OAuth::Unauthorized => e
    redirect_to new_profile_path, alert: "We were no able to add the Twitter account (#{e.message})"
  end

end

La differenza si nota, o sbaglio? Controller più snello, più comprensibile, modulare, e questo nonostante sia più complesso, dato che gestisce anche possibili errori durante l'autenticazione che il primo codice ignorava con disprezzo.

La cosa divertente del TDD è che la forma che prende il codice non viene decisa a priori, ma emerge in modo naturale durante la scrittura del test.

L'unica regola da seguire è: "se il test è troppo complicato da scrivere, spezza e modularizza". Il resto viene da se'.

Vendorer: un Bundler per mantenere dipendenze esterne

2011-12-16T00:00:00+01:00

Ottima idea (e un altro Somethingfile che si aggiunge alla project root).

Spinach e Turnip: alternative a Cucumber

2011-12-16T00:00:00+01:00

Negli ultimi tempi sembra esserci stata una presa di coscienza collettiva nel mondo Rails/BDD. Se fino a sei mesi fa eravamo in piena Cucumber-mania, la situazione pare essersi quantomeno ribilanciata. Bello Cucumber? No, il contrario. E' terribile, con quella miriade di steps globali ed espressioni regolari da dover domare evitando conflitti e ambiguità.

Ho avuto modo di provare Cucumber su un solo progetto di media grandezza (71 classi, ~5000 LOC), scontrandomi in prima persona con questi problemi. La gestione ed il mantenimento della suite di test è stata snervante al punto da portarmi ad utilizzare sui progetti successivi soluzioni più "leggere" come Steak.

Eppure l'idea di un "contratto" sempre aggiornato, testato e comprensibile per tutti i soggetti coinvolti nel progetto è incredibilmente allettante. Così come l'idea di poter descrivere le varie feature in maniera astratta, focalizzandosi unicamente sul business value che queste portano. Il linguaggio scelto da Cucumber per questo scopo si chiama Gherkin, ed il tempo ha confermato tutta la sua validità.

Dunque eccoci di fronte ad una seconda ondata di gemme, che cercano di raddrizzare il tiro di Cucumber, mantenendo ciò che di buono c'è -- Gherkin appunto -- e migliorando il rimanente.

Spinach

Ad Ottobre è uscito Spinach, frutto del lavoro della piccola realtà spagnola Codegram. Con Spinach:

Alla feature Gherkin Feature: Test how spinach works corrisponde una classe Ruby chiamata TestHowSpinachWorks;
Ad ogni step contenuto nella feature corrisponde un metodo nella classe TestHowSpinachWorks;
L'implementazione degli step non prevede l'uso di espressioni regolari per matchare più step in un solo colpo: uno step, una definizione;
E' possibile generare automaticamente lo scheletro di TestHowSpinachWorks tramite un generatore spinach --generate;

Molto leggero e totalmente privo di ambiguità. Non esistono step globali: se si vuole riutilizzare degli steps, è sufficiente estrapolare i relativi metodi di classe in un apposito modulo Ruby, da includere dove se ne vuole fare uso. Ma sembra evidente che Spinach porti ad un basso riutilizzo degli step definitions, e dunque ad una maggiore astrazione degli step, cosa buona e giusta.

Turnip

Un mese più tardi, il buon Jonas Nicklas -- autore di Carrierwave e Capybara -- ha ufficializzato la sua proposta: Turnip. Si tratta di un approccio sicuramente meno drastico:

Le espressioni regolari sono state eliminate, ma è possibile comunque "parametrizzare" le step definitions mediante placeholders, con maggiore comprensibilità e minori possibilità di degenero (i.e. step "there is/are :count monster(s)" do |count|);
Gli step globali continuano a poter esistere, ma è possibile anche raggrupparli in "scopes" e richiamarli sono nelle features che li necessitano (attraverso direttive @nome_scope presenti nella feature Gherkin);

Cosa ne pensate?

Sono sinceramente interessato a questi due nuovi tentativi. Sicuramente la direzione è quella giusta, ma mi domando se anche questi strumenti non nascondano delle problematiche. Siamo sicuri che Spinach non sia troppo rigido, non permettendo di parametrizzare del tutto gli step? D'altra parte, lo stesso Jonas in un suo celebre post passato, recitava come un mantra:

A step description should never contain regexen, CSS or XPath selectors, any kind of code or data structure. It should be easily understood just by reading the description.

Ma allora perchè lui stesso ha permesso di parametrizzare gli step descriptions, dando il via a possibili nuovi Pickle? Forse per permettere ai duri e puri di scrivere alà-Spinach, mantenendo però un ponte col passato?

Avete già avuto modo di provarli sul campo? Che idea vi siete fatti?

Far convivere repositories di WP Plugins con Github

2011-12-13T00:00:00+01:00

Senza questa guida probabilmente non ce l'avrei mai fatta. Il processo descritto tra l'altro è generalizzabile e si applica anche fuori dal seminato "WP Plugins" e "Github".

Search e replace di file multipli su Vim

2011-11-14T00:00:00+01:00

Questo era l'ultimo pezzo che mi mancava da Textmate, direi. La sostituzione becera su più file in contemporanea. Io l'ho risolta con greplace, un simpatico plugin.

Se usi Janus (lo usi, vero?), aggiungi questa riga in ~/.janus.rake:



vim_plugin_task "greplace", "git://github.com/vim-scripts/greplace.vim.git"

Perfetto, ora lancia un rake dalla cartella ~/.vim per installare automaticamente il plugin, e aggiungi quest'ultima riga in ~/.gvimrc.local:



" Command-Shift-R for greplace
map <D-R> :Gqfopen<CR>:ccl<CR>

Da questo momento, potrai continuare a ricercare utilizzando Ack con lo shortcut Cmd+Shift+F. Ma se, con il pannello dei risultati ancora aperto, provi a digitare Cmd+Shift+R, il pannello si trasformerà in un buffer con i medesimi risultati, ma modificabile. Effettua le tue sostituzioni tranquillamente su quel file con i metodi classici. Una volta terminato il lavoro, lancia il comando :Greplace -- così come suggerito in un commento nel buffer stesso -- e le modifiche effettuate sul buffer si rifletteranno sui vari file.

Già che ci sono, ti consiglio anche indentguides, io lo trovo fantastico.

E voi? Usate qualcosa di particolarmente fico? Fatemi sapere, son curioso :)

Sul fondamentale problema della stima costi/tempi

2011-11-05T00:00:00+01:00

Uno dei maggiori ostacoli che ho personalmente vissuto approdando in un contesto professionale è sicuramente stata la definizione delle specifiche iniziali, e relativa stima di costi e tempi.

Sembra banale dirlo, ma dal punto di vista pratico lo è meno. La differenza più grande nel passaggio da "amatori" a "professionisti" è proprio quella di essere in grado di garantire al 100% i risultati che vengono promessi. E per risultati non intendo soltanto l'output finale, ma anche le tempistiche e le modalità concordate.

Non ci si può permettere di andare ad istinto, non ci si può aspettare che tutto vada nel verso giusto, o che ci possa essere flessibilità altrui nell'accettare eventuali disguidi o intoppi. Al contrario, è fondamentale misurare ogni promessa fatta al cliente valutandola nella casistica peggiore che ci possa venire in mente, e avvisare fin da subito di qualsiasi situazione che possa sfuggire di mano o non dipendente dai propri mezzi/responsabilità.

La stima dei tempi non è un'attività "naturale" per l'essere umano: è sorprendente vedere come gli sviluppatori durante la fase specifiche sembrano come avvolti da un'aurea di immotivato ottimismo, che non gli fa lontanamente scorgere le miriadi di cose che potrebbero tranquillamente andare per il verso sbagliato (e che magari sono già andate storte in passato).

Tipicamente, l'errore umano di stima cresce esponenzialmente all'aumentare della complessità del task da stimare. E' difficile, se non impossibile, stimare con precisioni superiori alla "giornata/uomo" su task superiori alle 3-4 settimane. E' questa una delle motivazioni alla base di metodi di sviluppo agili, che incentivano uno sviluppo incrementale del progetto attraverso una serie di "sprint" da massimo una-due settimane.

In lavori su commessa, un cliente particolarmente illuminato potrebbe essere concorde ad uno sviluppo incrementale, ma pretenderà ad ogni modo (comprensibilmente aggiungo) una stima di tempi e costi per il caso peggiore, dunque il problema alla base rimane. Che si fa?

I consigli che posso dare sono pochi e generici. Sicuramente la stima è più un arte che una scienza perfetta, e come tale necessita di esperienza ed "occhio" per riuscire ad intuire da subito i punti "scricchiolanti" di un progetto. Cercate di suddividere ogni progetto in sotto-task elementari da 2-3 giornate massimo: su quelli il nostro cervello è in grado di stimare con precisione accettabile. Non promettetevi mai una consegna in X giornate -- come a trasformare una stima in qualcosa di scritto su pietra -- ma tenetevi su un range che sia tanto più ampio quanto sia poco conosciuto l'ambiente nel quale dovrete lavorare. Misuratevi sempre, e controllate a fine lavori di quanto avevato sbagliato, cercando di capire i punti che avevate sottovalutato.

E infine, leggete, leggete, leggete. Il primo passo verso delle migliori stime è essere coscienti di quanto possiamo fare schifo, e imparare da chi lo ha fatto da più tempo.

Tabs UJS con i data-behaviour

2011-10-23T00:00:00+02:00

Ho scoperto l'UJS in concomitanza della sua introduzione massiccia su Rails: ne sono rimasto immediatamente affascinato. Un coupling ancora meno stretto tra contenuto e comportamenti dinamici della pagina, utilizzando come strumento di comunicazione gli attributi HTML5 data-*? Fantastico! :)

Ho cercato da quel momento di impegnarmi a generare codice JS quanto più unobtrusive possibile; il vantaggio è evidente dopo i primi tentativi: nel tempo, arrivi a comporre una comoda libreria di comportamenti riutilizzabili in altri contesti senza nessun codice JS custom da introdurre.

Esempio: una tabbed interface

Quante volte vi sarà capitato di dover impostare una vista a tab? Io sono arrivato a questa soluzione, che considero difficilmente battibile, sia per chiarezza che per brevità:



$ ->

  $tab_scope_contents = {}

  $("[data-behaviour=tab]").each ->
    $tab = $(this)
    $tab_content = $($tab.attr("href") || $tab.find("a").attr("href")).hide()
    scope = $tab.data("tab-scope")
    $related_tabs = $("[data-tab-scope=#{scope}]")
    $tab_scope_contents[scope] = ($tab_scope_contents[scope] || $()).add $tab_content

    $tab.click ->
      $related_tabs.removeClass("selected-tab")
      $tab.addClass("selected-tab")
      $tab_scope_contents[scope].hide()
      $tab_content.show()
      false

    $related_tabs.eq(0).click()

Come si utilizza? Semplice: supponiamo di avere un HTML del genere:



<ul>
  <li><a href="#primo">Primo tab</a></li>
  <li><a href="#secondo">Secondo tab</a></li>
  <li><a href="#terzo">Terzo tab</a></li>
</ul>

<div id="primo">Primo contenuto!</div>
<div id="secondo">Secondo contenuto!</div>
<div id="terzo">Terzo contenuto!</div>

E' sufficiente aggiungere, per ogni tab handle, un attributo data-behaviour="tab" per specificare che vogliamo da quel link un comportamento di tipo "tab", e un attributo data-tab-scope="nome-dello-scope" per specificare a quale gruppo di tab appartenga:



<ul>
  <li><a href="#primo"   data-behaviour="tab" data-tab-scope="tabset1">Primo tab</a></li>
  <li><a href="#secondo" data-behaviour="tab" data-tab-scope="tabset1">Secondo tab</a></li>
  <li><a href="#terzo"   data-behaviour="tab" data-tab-scope="tabset1">Terzo tab</a></li>
</ul>

Boom. Il gioco è fatto. Ora, ovunque tu voglia tab, basta aggiungere due attributi all'HTML.

Cosa ne pensate?

Linear gradients su IE: Sinatra alla riscossa

2011-10-23T00:00:00+02:00

Con strumenti come Sass e Compass il CSS sta vivendo il suo primo vero rinascimento: la possibilità di astrarre, modularizzare e parametrizzare i fogli di stile ci permette di rendere più stimolante, rapido e mantenibile un lavoro altrimenti devastante a causa dei vari rendering engines da dover gestire.

E' ancora recente la scelta di Compass di introdurre nel suo core l'ormai fu Lemonade, estensione in grado di generare automaticamente immagini sprites attraverso comodi mixins. Non tutti sono particolarmente favorevoli ad arrivare un simile livello di automazione: non sono uno di questi. Personalmente, condivido ogni strada che possa essere prese per rendere meno tedioso un lavoro banale. :)

Un altro esempio di tedio, per esempio, arriva dalla direttiva linear-gradient, non supportata nativamente dall'amato Explorer, se non a mezzo di astrusi filtri di questo tipo:



=ie-linear-gradient($from, $to)
  :filter progid:DXImageTransform.Microsoft.Gradient(GradientType=0, startColorstr='#{$from}', endColorstr='#{$to}') // IE6 & IE7
  :-ms-filter quote(progid:DXImageTransform.Microsoft.gradient(startColorstr='#{$from}', endColorstr='#{$to}')) // IE8 & IE9
  :background-image -ms-linear-gradient(top, #{$from}, #{$to}) // IE10

=cross-browser-linear-gradient($from, $to)
  +ie-linear-gradient($from, $to)
  +background(linear-gradient($from, $to))

Purtroppo la renderizzazione di gradienti realizzati con questa tecnica è orribile, dunque non c'è altro rimedio se non tornare nei mitici '90s, e utilizzare a mo' di gradiente la famosa immagine larga 1xNpx. E qui entra in gioco Sinatra.

Prima il codice:



=ie-linear-gradient($from, $to, $height)
  background: mix($from, $to) image-url("/images/ie_gradients/#{red($from)}-#{green($from)}-#{blue($from)}-#{red($to)}-#{green($to)}-#{blue($to)}-#{$height}.png")

Questo mixin cosa fa? Prende come parametri i due colori limite del gradiente e l'altezza del gradiente stesso, e assume la presenza di una immagine che segua una nomenclatura predefinita, dipendente proprio dai 3 parametri di cui sopra. Imposta inoltre un colore solido di fallback, pari al mix fifty-fifty tra i due colori.

Ottimo, ormai siamo a cavallo, è sufficiente chiedere a Sinatra di completare il lavoro:



get '/images/ie_gradients/:r1-:g1-:b1-:r2-:g2-:b2-:height.png' do |r1, g1, b1, r2, g2, b2, height|

  # il path ricomposto dell'immagine
  path = File.join(File.dirname(__FILE__), 'public/images/ie_gradients',"#{r1}-#{g1}-#{b1}-#{r2}-#{g2}-#{b2}-#{height}.png")

  unless File.exists? path

    # ricompongo i colori esadecimali
    from = "#%02x%02x%02x" % [r1.to_i, g1.to_i, b1.to_i]
    to = "#%02x%02x%02x" % [r2.to_i, g2.to_i, b2.to_i]

    # assicuriamoci che l'altezza sia un intero
    height = height.to_i

    # ImageMagick, pensaci tu!
    `convert -size 1x#{height} gradient:#{from}-#{to} #{path}`
  end

  # passo l'immagine
  send_file path
end

Come potete vedere, Sinatra intercetta la richiesta del file, controlla se effettivamente il file esiste, e in caso di test negativo, la genera in automatico utilizzando brutalmente ImageMagick, estrapolando i vari parametri dal nome del file stesso.

La tecnica è ancora grezza, ma vedete il potenziale? Una volta che i file sono stati generati da Sinatra, magari in fase di prototipazione iniziale del layout -- continua a funzionare anche senza Sinatra.

Ovviamente, per la massima comodità, si potrebbe trasformare tutto ciò in estensione Compass. Non ne ho mai fatta una, dunque ho evitato di perdere tempo in questa fase. Ma cosa ne pensate?

Posso dire di aver switchato da Textmate a Vim

2011-10-10T00:00:00+02:00

Alla fine ce l'ho fatta. Non posso dire che sia stata semplice, ma è andata. Sono ormai un paio di settimane che sviluppo unicamente con MacVim.

A dirla tutta, è stato il 4° tentativo. I precedenti 3 erano andati miseramente a vuoto. C'era sempre qualcosa che non mi tornava, che mi faceva ritornare all'ovile. Questa volta, i motivi determinanti il cambio di risultato sono stati:

Un'esperienza pregressa accumulata nei precedenti 3 tentativi. Vim, come tutte le cose belle e complesse, va digerito con calma;
La totale latitanza degli autori di Textmate, per troppo, troppo tempo. Ok lavorare in stealth mode, ok concentrarsi sul prodotto invece che sul marketing, va bene tutto. Ma non pubblicare una bugfix release per Lion dopo 4 mesi mi sembra stupido, eccessivo e poco rispettoso del lavoro e tempo altrui;
La consapevolezza di switchare verso uno strumento dall'enorme diffusione e supporto, ora e nei secoli a venire, da poter utilizzare a prescindere dal sistema operativo e che ultimamente si sta riscoprendo collettivamente. Per dirla in tema: there's a plugin for that;
VimCasts un ottimo sito di screencast che apre mondi paralleli sull'utilizzo della potenza di Vim nei banali task quotidiani;
Janus, una distro MacVim che pone un rimedio a tutte le principali voglie di un utente Textmate: fuzzy file searching, ricerca di stringhe con Ack, e tutta una serie di piccole premure che rendono più intuitivo e immediato lo switch;
Un fork di MacVim con Project Drawer vero. Personalmente, per mantenere il focus su cosa sto facendo, ho bisogno di una visione ad alto livello dell'alberatura del progetto, sempre visibile. Plugin come NERDTree fanno il loro sporco lavoro di gestione dei file, percarità, ma i font enormi monospaced poco si adattano al ruolo di "mappa estesa" di un progetto;
Un compagno di viaggio col quale confrontarmi e scambiare opinioni ed entusiasmo nei momenti difficili :)

Se anche uno solo di questi punti fosse mancato, probabilmente sarei ripiombato nella cupa incertezza di un software morto da anni.

In questo esatto momento non credo di essere diventato particolarmente più produttivo di prima, ma posso dire con fierezza di non notare alcun rallentamento nel mio flusso di lavoro. Seguiranno a breve (spero), piccoli consigli e note sull'utilizzo di MacVim.

PS. Per puro caso ho scoperto ora l'ennesimo post-annuncio sul fantomatico Textmate 2.0. Per quanto mi riguarda, mi hanno perso per strada, per sempre. Come aspirante entrepreneur, fatico a quantificare l'idiozia delle mosse della Micromates. Erano avanti anni luce da qualsiasi altro editor in circolazione. Sono riusciti nell'impresa di dare il tempo al mondo di raggiungere quello che era lo stato dell'arte dell'editing testuale, e non solo: hanno letteralmente costretto fedeli utilizzatori a cercarsi alternative più sicure e mantenute. What a waste.

Un task Capistrano per backuppare il DB di produzione

2011-09-13T00:00:00+02:00

Recentemente, per riprodurre un bug che si presentava solo in produzione, ho pensato bene di creare un piccolo task Capistrano per copiare in locale l'intero contenuto del DB remoto. Il task funziona solo se il DB di produzione è MySQL. Troverete il risultato nella cartella backups del vostro progetto Rails. Eccolo:




require 'yaml'

desc "Backup the remote production database"
task :backup, :roles => :db, :only => { :primary => true } do
  filename = "#{application}.dump.#{Time.now.to_i}.sql.bz2"
  file = "/tmp/#{filename}"
  db = YAML::load(ERB.new(IO.read(File.join(File.dirname(__FILE__), 'database.yml'))).result)['production']
  run "mysqldump -u #{db['username']} --password=#{db['password']} #{db['database']} | bzip2 -c > #{file}"  do |ch, stream, data|
    puts data
  end
  `mkdir -p #{File.dirname(__FILE__)}/../backups/`
  get file, "backups/#{filename}"
end

Il costo del cambiamento nel mondo Agile

2011-08-28T00:00:00+02:00

Una delle assunzioni universali dell’ingegneria del software è quella che vede il costo necessario per modificare un programma crescere esponenzialmente nel tempo. Chi di noi non ha mai visto qualcosa di simile su un manualone di programmazione?

Ovviamente, un grafico del genere ci spinge a premunirci. Per evitare l’insorgere di costi inimmaginabili nel futuro, si tenta di prevedere ogni problematica con il più largo anticipo, stimando ogni futura evoluzione del progetto già dall’inizio dei tempi. Questo in effetti è ciò che tutti noi — ad un certo punto della nostra crescita professionale — abbiamo imparato volenti o nolenti a fare, pur sapendo quanto a tratti sia impossibile.

Durante gli ultimi decenni, enormi sforzi sono stati compiuti nella costruzione di nuovi linguaggi, paradigmi, strumenti e metodologie di lavoro in grado di alleviare il costo delle modifiche in corso d’opera. La lettura del libro “Extreme Programming Explained” di Kent Beck è stata illuminante. Si parte da una domanda: ma se per caso tutti questi sforzi avessero veramente portato a qualcosa? Se per caso, applicando i risultati ottenuti in questo senso, il costo di una modifica ad un software non crescesse in modo esponenziale nel tempo, ma seguisse una curva molto più lenta, tendente quasi ad un asintoto?

È questa la premessa tecnica fondamentale dell’Extreme Programming (e di tutte le metodologie agili in generale): se i costi crescessero in questo modo, lo sviluppo SW procederebbe con modalità totalmente differenti.

Le “grandi decisioni” verrebbero prese quanto più tardi possibile, per posticiparne il costo e per attendere di avere in mano il massimo quantitativo recuperabile di informazioni a convalidare l'investimento. Si implementerebbe solo il minimo indispensabile, e si introdurrebbero nuovi elementi al design complessivo solo quando questi semplificassero il codice già esistente, o rendessero il prossimo pezzo di codice più semplice da scrivere.

Non si spenderebbero più giornate o settimane a decidere in fase di specifica iniziale se investire o meno in una componente “rischiosa”, solo per la paura che eseguire la medesima modifica in un secondo tempo possa essere enormemente più costoso; si implementerebbe solo ciò che si rivela utile all’oggi, con la fiducia e la tranquillità di sapere che un domani sarà possibile estendere l'esistente senza aumenti di prezzo degni di preoccupazione.

Con questo cambiamento radicale di prospettiva ci sono le basi per impostare un processo di sviluppo del software nel quale — invece che attuare le grandi decisioni al “tempo zero” e limitarsi a piccole virate in seguito — siamo in grado, in ogni momento, di prendere decisioni strategiche e vederle realizzate tempi rapidi.

Buone vacanze!

2011-07-27T00:00:00+02:00

Il vostro fedelissimo a partire da giovedì si ritira per un paio di settimane di riposo in famiglia. E' stato un anno impegnativo e pieno di sfide, sotto tutti i punti di vista. Sono felice di poter dire, come si suol dire, di aver tenuto botta a un cambio di città e al primo anno di vita di weLaika. Ora tutta la stanchezza accumulata sta iniziando a farsi sentire sul serio. Ci si risente da metà agosto circa, fate i bravi!

I più bei bottoni CSS3 del mondo

2011-07-26T00:00:00+02:00

Chad Mazzola è riuscito a creare un set di bottoni CSS3 incredibilmente lickable, prendendo spunto dagli stili più celebri presenti nella rete. Da quando conosco questo set, ho smesso di cercare altrove.

Buffer è "ramen profitable"

2011-07-07T00:00:00+02:00

Joel Gascoigne su Buffer:

“Ramen profitable” is a term which is used a lot in the startup scene, and one you should get acquainted with if you haven’t already. I think Paul Graham does a good job of describing it, and he may have even invented the phrase:

At YC we use the phrase “ramen profitable” to describe the situation where you’re making just enough to pay your living expenses. Once you cross into ramen profitable, everything changes. You may still need investment to make it big, but you don’t need it this month.

We reached ramen profitability a couple of months ago and I can’t emphasise enough the impact it can have. I gradually dropped the number of days of contract development work I was doing as the revenue grew, and now I get to spend all my days on Buffer. We certainly have many new challenges ahead of us, but it is a very nice place to be.

Unique Value Proposition

2011-07-06T00:00:00+02:00

The UVP is hard to get right because you have to distill the essence of your product in a few words that can fit in the headline of your landing page. Additionally, your UVP also needs to be different and that difference needs to matter. First-time visitors spend 8 seconds on average on a landing page. Your UVP is their first interaction with your product - craft a good UVP and they might stay and view the rest of your site. Otherwise, they’ll simply leave.

Ash Maurya, dal suo libro Running Lean. Consigliato.

"Coming soon" pages? Evitale.

2011-07-04T00:00:00+02:00

By skipping the “coming soon” page, you can really focus on what matters. Instead of a “coming soon” page, put up a landing page for your product. Make it look like the product exists, and then when people try and sign up, show them a page letting them know that you’re not quite ready for them yet. The effort is the same, but this tiny change can give you massive rewards. By skipping the “coming soon” page, you gain validated learning about the emails you collect: they are people who thought your product existed and showed a real interest by trying to sign up. If you have people hitting the page and no one gives you their email, you know there’s a problem with your idea or the way you’re describing it.

Dal blog di Joel Gascoigne, un signore che negli ultimi tempi si può dire possa essere felice.

Why sharing knowledge is vital for success

2011-06-29T00:00:00+02:00

Sharing knowledge is one of the best things you can do to become a great team player and ultimately a leader. It is essential not only for the success of people around you, but for your own success in the first place. The more you share, the more people respect you. The more respected you feel, the more you’re willing to share. The more you give away, the more new opportunities come your way.

In weLaika siamo alla continua di strumenti che ci permettano di migliorarci. Abbiamo ancora un sacco da imparare, e proprio per questo motivo diventa vitale riuscire a trovare un modo per condividere nella maniera più rapida e costruttiva possibile i propri esperimenti, pensieri e scoperte con il resto del gruppo.

Non trovando nulla che ci abbia soddisfatto, stiamo lavorando da diversi mesi all'idea di uno strumento online che permetta di semplificare questo processo di comunicazione ed apprendimento. Nei prossimi post continuerò a stuzzicarvi sulla questione, siete già avvisati.

From idea to paying costumers in 7 weeks

2011-06-27T00:00:00+02:00

E' la prima volta che ne parlo in questo blog, ma è un topic che sto seguendo ormai da alcuni mesi con attenzione ed interesse: il minimum viable product. E' un concetto sviluppato ormai tre anni fa da Eric Ries in un più ampio contesto, quello denominato del Lean Thinking, riassumibile nello sviluppare sempre il minimo indispensabile per ottenere nuove interessanti informazioni dai propri clienti e visitatori, in modo da guidare i successivi sviluppi sulla base dei feedback registrati.

Questo articolo descrive con chiarezza gli step iniziali svolti per lanciare in poco tempo Buffer, una webapp per schedulare i propri post Twitter nel tempo, partendo da una semplice pagina statica iniziale.

Implementing DSL Blocks

2011-06-19T00:00:00+02:00

Una panoramica ultra-comprensibile e dettagliata sul mondo dei DSL in Ruby e sui vantaggi e svantaggi delle varie tecniche possibili per realizzarli. Incrocerete i problemi del metodo instance_eval spesso utilizzato in questi casi, scoprirete probabilmente per la prima volta mixico, una gemma prodotta anni addietro dal compianto Why.

Uscirete dal tunnel di questa lettura con una gemma, blockenspiel, in grado di ovviare alle problematiche dei vari metodi affrontati, semplificando l'enorme complessità della materia con un banale include, e col bonus aggiuntivo di poter riprodurre il comportamento di entrambe le sintassi DSL Ruby.

atk_icons: Agile Toolkit Icon Set su Compass

2011-06-07T00:00:00+02:00

Da un paio di progetti a questa parte sto facendo un uso massiccio di un iconset non particolarmente conosciuto: Agile Toolkit Icon Set. Trattasi di 128 iconcine 16x16 da poter utilizzare in un sacco di contesti, e che con uno sforzo minimo rendono immediatamente più attraente, usabile e caratterizzante un sito.

Con la solita logica DRY, ieri sera ho creato una piccola gemma che permette di sfruttare questo iconset su Compass con maggiore semplicità:




@import "atk_icons"

.button.delete
  /* this will add an :after pseudo-selector with the specified icon
  @include atk-icon-pseudo("basic-ex")

.button.add span.icon
  /* you can also set the icon to a sub-element
  @include atk-icon("basic-plus")

Per maggiori informazioni su come installare questa estensione Compass, consultate il README. Spero vi possa essere utile!

Propositi di inizio Giugno

2011-06-05T00:00:00+02:00

Dopo due mesi di vita di questo nuovo esperimento -- e assodato il fatto di essere in grado di reggere per davvero una media di 4-5 mini-post a settimana -- credo sia arrivato il momento di fare una piccola analisi sul da farsi. Gli obiettivi principali che cercherò di raggiungere nei prossimi mesi possono riassumersi in 3 punti.

Estendere il giro di nerd che visitano questo posto

Ho iniziato a scrivere con un target piuttosto specifico e ristretto: me. Sentivo il bisogno di selezionare e raggruppare in un unico luogo le montagne di link e progetti open che navigo e utilizzo settimanalmente, e mi sembrava che farlo in maniera pubblica e condivisa potesse essere potenzialmente più utile/divertente. Non nascondo la sorpresa nel leggere il counter dei lettori del feed.. A questo punto, se ci sono 20-30 lettori attivi, perchè non 50? Sarebbe sicuramente più divertente e stimolante. Non mi sembra di aver visto molti posti in cui oggi si possa discutere di Rails, web e dintorni in lingua italiana, sarebbe bello poter colmare questo vuoto!

Capire qualcosa di più su chi siete

Partiamo da un dato di fatto: non posseggo 30 amici così nerd da seguire questo posto con continuità. Ne deriva che probabilmente dev'esserci qualche forma di vita non meglio identificata che in silenzio legge. Non era un'ipotesi troppo preventivata all'inizio, ma dato che la cosa potrebbe essere divertente, perchè non conoscerci meglio? Questo punto porta direttamente al prossimo, ovvero...

Aumentare il coinvolgimento e la discussione

Per un blog di questo tipo, uno scambio continuo con chi legge sarebbe sicuramente cosa buona e giusta. Della serie: io consiglio a voi, voi consigliate a me. Sono sono un esperto in fidelizzazione, ma nel mio piccolo, il primo passo per cercare di convincervi a commentare è stato levare il sistema di commenti basato su Twitter e sostituirlo con Disqus, di modo da avere un modo super-rapido e poco spammoso per dialogare.

Se avete consigli/suggerimenti, o volete semplicemente de-lurkizzarvi, questo è il momento!

Pow e PHP

2011-06-01T00:00:00+02:00

However, there is a downside: Pow doesn’t play nicely with Apache (or any server listening on port 80). Life isn’t all greenfield, if in the course of the day you need to work on PHP or CGI legacy apps Pow is not so simple. Pow creates a firewall rule that redirects port 80 to its port; to access Apache you need to either toggle the firewall rule on and off or move Apache to a different port all together. And now you’re running two web servers. There has to be a better way.

Questo è esattamente il motivo per il quale ho dovuto disinstallare Pow: lavorando spesso e volentieri su Wordpress, avere un development stack compatibile con PHP è fondamentale. Potrebbe però salvarci rack-legacy, una gemma che permette di utilizzare Rack anche per far girare applicazioni PHP, sfruttando sotto il cofano il comando php-cgi.

Nuova piattaforma di Continuous Integration: Goldberg

2011-06-01T00:00:00+02:00

Nuova possibilità nel mondo dei CI leggeri (per un'anteprima, http://goldberg.c42.in/). La novità è che è pensato da zero per funzionare con RVM e Bundler, quindi è in grado di supportare differenti progetti con differenti versioni di Ruby e gemme.

Learning Advanced Javascript

2011-05-29T00:00:00+02:00

E' difficile trovare buoni esempi per spiegare in poche righe di codice alcuni degli aspetti più controversi e meno intuitivi del mondo Javascript. Le famose closures, il possibile cambio di contesto all'interno di funzioni, i diversi metodi per ottenere l'ereditarietà tra (pseudo) classi..

John Resig -- creatore di jQuery ed (ormai ex) Javascript Evangelist per Mozilla -- ha preparato una serie di slides interattive, dalle quali chiunque troverà qualcosina da imparare, in attesa di leggere il suo primo libro: Secrets of the JavaScript Ninja, in arrivo entro l'anno.

Aggiungere target="blank" sui link esterni con un Rack middleware

2011-05-23T00:00:00+02:00

Quante volte avete sentito, magari a termine dei lavori, la richiesta "tutti i link verso l'esterno dovrebbero aprirsi in un tab separato"? Questo è un tipico esempio di lavoro tremendamente noioso da fare per vie canoniche -- perchè richiederebbe un editing di tutti i link presenti in tutte le viste -- ma banale da realizzare passando per un middleware Rack.

In basso il codice. Il middleware usa Nokogiri per parsare tutte le pagine HTML (quelle con Content-Type impostato a text/html), e per ogni link trovato controlla il dominio: se non coincide con quello del server, aggiunge il fatidico attributo target al link.



require 'nokogiri'

module Rack
  class TargetBlank
    include Rack::Utils

    def initialize(app)
      @app = app
    end

    def call(env)
      @request = Rack::Request.new(env)
      status, @headers, @body = @app.call(env)
      @headers = HeaderHash.new(@headers)
      if is_html_content?
        body = edit_external_links(body_to_string)
        update_response_body(body)
        update_content_length
      end
      [status, @headers, @body]
    end

    private

    def edit_external_links(body)
      doc = Nokogiri::HTML(body)
      found_links = false
      doc.css('a[href]').each do |link|
        uri = URI(link['href'])
        if uri.absolute? and uri.host != @request.host
          link['target'] = 'blank'
          found_links = true
        end
      end
      found_links ? doc.to_html : body
    end

    def body_to_string
      s = ""
      @body.each { |x| s << x }
      s
    end

    def update_content_length
      length = 0
      @body.each { |s| length += Rack::Utils.bytesize(s) }
      @headers['Content-Length'] = length.to_s
    end

    def update_response_body(body)
      if @body.class.name == "ActionController::Response"
        @body.body = body
      else
        @body = [body]
      end
    end

    def is_html_content?
      @headers.key?('Content-Type') && @headers['Content-Type'].include?('text/html')
    end
  end
end

CoffeeBeans: AJAX con CoffeeScript su Rails

2011-05-21T00:00:00+02:00

Il pezzo che ancora mancava a Rails 3.1: scrivere anche le risposte AJAX in CoffeeScript. Con questo plugin è sufficiente creare viste con suffisso .coffee, e verranno automaticamente convertite in Javascript al momento del rendering.




alert "Hello world!"

L'unico svantaggio da verificare è la lentezza per processare questa compilazione live.

Usa oggetti Ruby nei form Rails con Informal

2011-05-21T00:00:00+02:00

Informal is a small gem that enhances a Plain Old Ruby Object so it can be used with Rails 3 form helpers in place of an ActiveRecord model. It works with the Rails form_for helper, and simple_form as well.

Non è impossibile da fare a mano (e Crafting Rails Applications ti spiega anche bene come fare), ma così è decisamente più comodo. Provata, funziona!

Batman.js

2011-05-21T00:00:00+02:00

Una interessante alternativa agli MVC lato client. Opzionalmente è in grado di occuparsi anche del lato server, in Node.js, con possibilità di condividere il codice e le validazioni dei modelli. Mi piace molto il binding automatico di comportamenti tramite attributi HTML5 data-:



<ul id="items">
    <li data-foreach-todo="Todo.all" data-mixin="animation">
        <input type="checkbox" data-bind="todo.isDone" />
        <label data-bind="todo.body" data-class-done="todo.isDone" data-mixin="editable"></label>
        <a data-event-click="todo.destroy">delete</a>
    </li>
</ul>

Se c'è una cosa che Backbone.js non sa fare, è farti essere rapido nelle cose banali. Qui mi sembra ci siano invece degli ottimi spunti.

Deploy rapidi con Capistrano

2011-05-11T00:00:00+02:00

Niente di che, percarità, ma quando cap deploy inizia a metterci cinque buoni minuti, averlo fa comodo.



namespace :deploy do
  task :fast, :roles => :app do
    run "cd #{current_path} && git pull origin master && rake deployer:all_rake_tasks RAILS_ENV=production && touch tmp/restart.txt"
  end
end

Ovviamente, fatelo partire con cap deploy:fast.

Tapir: indicizzatore di post per siti statici

2011-05-11T00:00:00+02:00

I ragazzi olandesi di 80beans hanno preparato in una settimana circa Tapir, un servizio (gratuito) basato su Tire in grado di fetchare ed indicizzare feed esterni con una cadenza di 15 minuti (o mediante notifica push da parte dell'autore). Una comoda API JSON(P) ti permette poi di effettuare ricerche in un secondo tempo.

Ottima idea, ben eseguita e a basso costo. Spero di trovare il tempo di utilizzarla su questo blog a breve.

Come assumere programmatori

2011-05-11T00:00:00+02:00

Filter out candidates who don't have a github/blog/portfolio

Pair with remaining candidates

You'll learn 95% of what you need to know from pairing. Can they code? How do they think through problems? Can they interact with teammates? When they don't know something, do they posture, or figure it out? It's pretty fucking simple, really.

Fortissimamente quoto.

24 tools da terminale che forse non conoscevi

2011-05-10T00:00:00+02:00

Ne conoscevo solo 9. Notevole tpp, un precursore di showoff:

tpp stands for text presentation program and is an ncurses-based presentation tool. The presentation can be written with your favorite editor in a simple description format and then shown on any text terminal that is supported by ncurses – ranging from an old VT100 to the Linux framebuffer to an xterm.

Subtle Patterns: sfondi Creative Commons per il tuo prossimo progetto web

2011-05-08T00:00:00+02:00

Ottima collezione di sfondi poco appariscenti, con possibilità di scaricarli anche come pattern Photoshop.

Vico: alternativa sensata a Textmate

2011-05-08T00:00:00+02:00

Vico is the result of a personal itch. My eyes want a beautiful looking, modern Mac text editor. But my fingers just want vi. Vico is inspired by some great software out there. The vi/vim command set beats anything in terms of efficiency and speed. TextMate has set a new standard in many ways, and the bundle community is still thriving.

In attesa di Texmate 2 (5 anni per una major release?! ormai ho i miei fondati dubbi sul suo arrivo), ho trovato questo nuovo text editor, Vico. Ha un'approccio interessante: unisce i keybinding di vi (insert mode, visual mode, etc.) alla compatibilità completa con i bundle di Textmate (!!). A quanto sto vedendo, funziona decisamente bene. Solo per OS X, ovviamente.

Un web proxy in Rack per cross-domain Ajax

2011-05-07T00:00:00+02:00

In weLaika stiamo lavorando allo sviluppo di un social-network con un'architettura logica a due livelli: da una parte uno storage ultra-performante su Google App Engine, dall'altra una serie di differenti frontend per l'utente finale. Il primo frontend è quello web -- al quale weLaika sta lavorando. Il secondo, e per ora ultimo, sarà realizzato con tecnologia Flash.

Tutti i frontend sono in grado di comunicare col backend tramite API. I metodi API sono stati suddivisi in "pubblici" e "privati". Quelli pubblici sono in grado di rispondere con formato JSONP e possono dunque essere utilizzati da applicazioni di terze parti, le API private sono invece pensate solo ed esclusivamente per i frontend "ufficiali" ed è possibile accedervi solo mediante richieste Ajax pure, quindi da pagine all'interno dello stesso dominio del backend (per maggiori info, date un'occhio alla same-origin policy).

Tutto bellissimo e sensato, ma come lavorare sul frontend web in locale, con la possibilità effettuare richieste Ajax verso il backend? I browsers non ce lo permettono (se non mediante hack vari, e non sempre comunque)!

Cross-domain Ajax con Rack e Net::HTTP

Così come suggerito anche da Yahoo, la soluzione è semplice: il server locale deve poter intercettare tutte le richieste Ajax, capire quali sono quelle da inoltrare verso un server remoto, fingersi client con quest'ultimo passando i medesimi parametri ricevuti dal browser (cookie compresi), ricevere la risposta (header compresi) e inoltrare il tutto al browser. Phew.

Tutto ciò in realtà è moderatamente semplice da fare. Ecco qui un middleware Rack in grado di comportarsi esattamente in questo modo, sfruttando la libreria standard Net::HTTP:




require "net/http"

class Rack::Proxy
  def initialize(app, &block)
    self.class.send(:define_method, :uri_for, &block)
    @app = app
  end

  def call(env)
    req = Rack::Request.new(env)
    method = req.request_method.downcase
    method[0..0] = method[0..0].upcase

    return @app.call(env) unless uri = uri_for(req)

    sub_request = Net::HTTP.const_get(method).new("#{uri.path}#{"?" if uri.query}#{uri.query}")

    if sub_request.request_body_permitted? and req.body
      sub_request.body_stream = req.body
      sub_request.content_length = req.content_length
      sub_request.content_type = req.content_type
    end

    sub_request["Cookie"] = req.env["HTTP_COOKIE"]
    sub_request["Accept-Encoding"] = req.accept_encoding
    sub_request["Referer"] = req.referer
    sub_request.basic_auth *uri.userinfo.split(':') if (uri.userinfo && uri.userinfo.index(':'))

    http = Net::HTTP.new(uri.host, uri.port)

    sub_response = http.start { |http| http.request(sub_request) }

    headers = {}
    sub_response.each_header do |k,v|
      headers[k] = v unless k.to_s =~ /content-length|transfer-encoding/i
    end

    [sub_response.code.to_i, headers, [sub_response.read_body]]
  end
end

Il suo utilizzo è molto semplice, un esempio pratico (da lanciare per esempio con thin -R config.ru start):




use Rack::Proxy do |req|
  if req.path =~ /api/
    URI.parse("http://www.api-server.com#{req.path}#{"?" if req.query_string}#{req.query_string}")
  end
end

run Rack::Directory.new(".")

In questo caso, facciamo partire un server Rack che normalmente serve tutti i files contenuti nella directory corrente (mediante il fantastico Rack::Directory), ma il middleware Rack creato, prima di passare la palla a Rack::Directory, controlla se l'URL non contiene la stringa "api". In caso affermativo, si comporta da proxy, forwardando la richiesta HTTP ricevuta al server www.api-server.com, sul medesimo path.

Spine: l'erede di Backbone.js

2011-05-07T00:00:00+02:00

Un po' di sana concorrenza nel mondo dell'MVC client-side ci voleva. Salutiamo tutti Spine.js, un framework MVC fortemente ispirato all'ormai popolare Backbone.js, ma con una serie di miglioramenti molto interessanti che lo avvicinano molto ad una impostazione Rails:

Migliore gestione dell'ereditarietà tra classi JS;
Ogni istanza di uno stesso record rimane sincronizzata alle altre;
Eliminazione del concetto di Collection presente in Backbone;
Layer di persistenza Ajax o con HTML5 local storage;
Aggiunta di qualche ulteriore helper nelle Viste (che in Spine diventano Controller)
Supporto dell'HTML5 history nei controller (che in Spine diventano Route)

Non vedo l'ora di provarlo, sembra ottimo.

Capistrano e i tunnel SSH

2011-05-03T00:00:00+02:00

Piccola scoperta involontaria di ieri: se avete un'accesso SSH al server di produzione ristretto su un solo IP pubblico, l'iter che fino a ieri seguivo per i deploy Capistrano era quello di creare un tunnel SSH tra me ed il server "gateway" via terminale tramite il comando:


ssh -f -N -L 12345:server-di-produzione.com:22 server-gateway.com

A questo punto era possibile connettersi alla porta 22 di server-di-produzione.com tramite la porta 12345 di localhost. Capistrano però ha già tutto predisposto: è sufficiente aggiungere la seguente variabile al proprio script di deploy:



set :gateway, "utente@server-gateway.com"

E in automatico creerà il tunnel al vostro posto. Urrà per il comando in meno da digitare!

mogenerator: mai più rigenerare le classi dei modelli Core Data manualmente

2011-05-03T00:00:00+02:00

mogenerator is a command-line tool that, given an .xcdatamodel file, will generate two classes per entity. The first class, _MyEntity, is intended solely for machine consumption and will be continuously overwritten to stay in sync with your data model. The second class, MyEntity, subclasses _MyEntity, won't ever be overwritten and is a great place to put your custom logic.

Dio, grazie.

Slow time

2011-05-02T00:00:00+02:00

Communication doesn’t always have to be in real time. It can be in what we call "slow time". You can post something and three hours later someone can get back to you and then four hours later someone else can get back to you. And everything will work out just fine. Slow time is "Maybe it takes two or three days to have this conversation. And we do it over periods of 15 minutes here, two minutes there, four minutes there." And that’s fine. It doesn’t need to happen all at once. Unless it’s really, incredibly, truly urgent. (Which most things aren’t. They’re made out to be that way, but they really aren’t that important.)

Condivido totalmente.

hookup

2011-05-02T00:00:00+02:00

Il solito Tim Pope con una nuova gemma che sfrutta gli hook Git per chiamare automaticamente bundle install e rake db:migrate non appena ce n'è bisogno.

ScottBot: a "that's what she said" bot

2011-04-29T00:00:00+02:00

To get scottbot started, I put it into an otherwise empty IRC channel and just fed it a few "funny" and "notfunny" messages, giving it feedback on each one. Within a few dozen it was getting pretty good at this. Which, coincidentally, is what she said.

Semplicemente geniale. Per un utilizzo più generico, senza necessità di training, affidatevi invece al filtro bayesiano TWSS:


> TWSS("you're not going fast enough")
true

39 differenti ombre CSS3-only

2011-04-23T00:00:00+02:00

Impressionante ed originalissimo lavoro di Doug Avery, visibile solo su Chrome. Alcuni spunti sono totalmente inediti.

Sinatra: un repository viewer web-based in.. 50 righe

2011-04-21T00:00:00+02:00

Sinatra, per piccole webapp, è un progetto semplicemente incredibile. Riesce a condensare dentro ad un DSL composto da pochissimi comandi gran parte delle features presenti in web framework ben più complessi e pesanti.

In weLaika stiamo lavorando ad una Intranet scritta in Ruby per una celebre università inglese: tra le specifiche compare anche una sezione nella quale sia possibile per i dipendenti poter navigare tra i vari commit di un repository SVN e, per ogni commit, poter visualizzare l'alberatura delle directory, ovviamente con la possibilità di poter scaricare i file presenti nelle varie loro versioni. Un repo viewer web-based, insomma. Il primo pensiero è stato: non dovremmo metterci ad integrare Ruby con WebSVN, vero?

Dopo una veloce ricerca, ho avuto la conferma di quanto SVN non sia esattamente il revision-system preferito dal popolo rubista. Poche gemme, poco utilizzate e documentate. Alchè mi sono ricordato di una interessante feature di Git (mai utilizzata dal sottoscritto fino ad ora): la possibilità di gestire localmente un repository SVN, via Git. E' infatti sufficiente effettuare un git clone leggermente diverso:

git svn clone http://ie7-js.googlecode.com/svn ie7-js

Per poter avere in locale un repo Git, in grado di committare (git dcommit) e updatare dal repository SVN originario (git rebase), in maniera del tutto trasparente. Non male! Ma a questo punto le possibilità di implementazione per il nostro repo-viewer si allargano incredibilmente. Siamo infatti in grado di poter usare una delle tante gemme in grado di interfacciarsi con repository Git: Grit, per esempio, usata attualmente su Github.

Ecco allora la sfida: siamo in grado di scrivere un clone di WebSVN in Sinatra, in meno di 50 righe di codice (viste comprese)? Ovvio che sì! Qui in basso avete un applicazione funzionante, in grado di soddisfare tutti i requisiti sopra elencati.




%w(sinatra grit).each { |gem| require gem }

mime_type :binary, 'binary/octet-stream'
set :repo, Grit::Repo.new('/Users/steffoz/dev/richcomments')

before %r{^/(\w+)} do
  commit_id = params[:captures].first[0..10]
  @commit = settings.repo.commits(commit_id).first
  halt "No commit exists with id #{commit_id}" if @commit.nil?
end

get "/" do
  @commits = settings.repo.commits
  haml :index
end

get "/:commit_id" do |commit_id|
  @tree = @commit.tree
  @path = ""
  haml :dir
end

get "/:commit_id/*" do |commit_id, path|
  @object = @commit.tree / path
  halt "No object exists with path #{path}" if @object.nil?
  if @object.is_a? Grit::Blob
    content_type :binary
    @object.data
  else
    @tree = @object
    @path = path + "/"
    haml :dir
  end
end

__END__

@@ index
%ul
  - @commits.each do |commit|
    %li
      %a{ :href => "/#{commit.id[0..10]}" }= "#{commit.id[0..10]} (by #{commit.author}, #{commit.committed_date})"

@@ dir
%h1= "Commit #{@commit.id[0..10]} - Path: #{@path}"
%ul
  - @tree.contents.each do |obj|
    %li
      %a{ :href => "/#{@commit.id}/#{@path}#{obj.name}" }= obj.name

Se poi consideriamo Almost Sinatra, che riesce a riscrivere le 5700 righe di Sinatra in 8 righe (!!!).. capite che la cosa inizia a diventare piuttosto esilarante. Se aveste problemi a comprendere lo script, son qui.

CSS3 Github buttons

2011-04-20T00:00:00+02:00

Belli, stilizzati con cura e semplicità. Disponibili anche tramite css3buttonsrailshelpers, se siete quei tipi di persone che aggiungono una gemma per degli stili CSS.

Update: per parcondicio, ecco i bottoni stile Facebook.

Icone social CSS-only

2011-04-20T00:00:00+02:00

Notevole esempio di cosa siamo già in grado di fare solo con del buon CSS e browser decenti (l'icona del feed che vedete in sidebar non è un'immagine). Nicolas Gallagher degenera poi nell'assurdo con la sua libreria di 84 icone vettoriali CSS-only. Chapeau.

Pattener: generatore di sfondi via SASS

2011-04-20T00:00:00+02:00

L'idea è interessante (qui ci sono degli esempi dei pattern generabili ad oggi). Spesso e volentieri mi trovo a dover generare sfondi noised, un'approccio del genere sarebbe perfetto. Certo, ci fossero dei pattern decenti -- gradienti, o noise, appunto -- sarebbe pure meglio. Ma si può sempre forkare.

Ruby: i tanti usi dei moduli

2011-04-17T00:00:00+02:00

Iper-dettagliato articolo in 4 parti di Gregory Brown sui moduli Ruby e i suoi molteplici utilizzi: namespacing, mixins, etc.

Nanoc, questo sito e prodotti derivati vari

2011-04-17T00:00:00+02:00

Per un sito estremamente nerd, ci vuole una piattaforma di pubblicazione estremamente nerd, mi sembra evidente. I miei bisogni erano fondamentalmente:

Rapidità nella scrittura;
Sintassi Markdown;
Possibilità di scrivere sia post "standard" che semplici link verso risorse esterne;
Codice pulito in uscita (HTML5);
Supporto per Compass, SASS e Slim;
Compressione automatica per gli assets Javascript;
Evitare totalmente qualsiasi problema di mantenimento della piattaforma (il tempo lo voglio dedicare per scrivere, grazie);

Mi è sembrato naturale dirigermi verso i vari progetti di generazione statica di siti web . Con questi tools, i post possono essere scritti su semplici file Markdown e backuppati su Github. Non ci sono security holes da gestire, nessun login/logout. Il deploy equivale semplicemente a lanciare un rsync remoto.

Fidandomi tendenzialmente del popolo di Github sono andato diretto su Jekyll, il pioniere nel campo. Son partito con entusiasmo, ma purtroppo non è andata come speravo: sebbene scritto bene, non è modulare a sufficienza per permettere troppe personalizzazioni. Avrei potuto forkare Jeckyll e modificarlo, ma non desiderando futuri problemi di mantenimento sono andato alla ricerca di alternative.

Alla fine sono approdato su Nanoc, un progetto non così popolare, ma a mio parere decisamente valido, sicuramente molto più modulare:

Permette di creare i propri filtri di conversione da file testuale a codice HTML, con possibilità di concatenazione multipla;
Permette di creare moduli helpers aggiuntivi per rendere più DRY le viste;
Permette di implementare anche dei Data Sources alternativi: questo vuol dire che i post possono essere salvati su file, ma non necessariamente. E' ad esempio possibile creare post da Twitter, Delicious o LastFM in poche righe di codice.
Permette di realizzare diverse rappresentazioni dello stesso post (i.e. JSON, XML ed HTML)

Con un'architettura così ben pensata, è stato sufficiente creare un paio di moduli aggiuntivi per arrivare esattamente ai miei bisogni. In particolare, ho scritto:

Un filtro Nanoc per tradurre i file Slim;
Un filtro Nanoc per comprimere i file Javascript con YUI;
Un filtro Nanoc che va in cerca di eventuali indirizzi mail e li encripta (date un'occhio alla mia mail nella pagina "Chi Sono");
Un task Rake per creare rapidamente lo scheletro per nuovi post ed aprire direttamente il file su Textmate;

Il codice sorgente del sito è disponibile su Github.. è immediato vedere che impostazione pulita riesce a regalare Nanoc.

Ruby: variabili di classe ereditarie e class_inheritable_accessor

2011-04-16T00:00:00+02:00

Oggi sono capitato di fronte ad un pattern interessante, immagino molto frequente nel caso di scrittura di plugin per Rails.

Immaginiamo, a scopo esemplificativo, di voler scrivere un semplice plugin Rails in grado di permettere questo tipo di chiamata all'interno dei tuoi modelli:




class Document < ActiveRecord::Base
  special_attribute :title
  special_attribute :description
end

La chiamata a special_attribute supponiamo faccia miracoli ai due attributi :title e :description del modello, ma andiamo oltre. Supponiamo che plugin debba anche essere in grado di restituire tutti gli attributi "speciali" tramite un metodo special_attributes:



Document.special_attributes
# => [ :title, :description ]

Come lo implementereste? Io farei qualcosa del genere:




module SpecialAttributesPlugin

  def special_attribute(attribute)
    @@special_attributes ||= []
    @@special_attributes << attribute
  end

  def special_attributes
    @@special_attributes ||= []
  end

end

# aggiungo il modulo ad ActiveRecord::Base
module ActiveRecord
  class Base
    extend SpecialAttributesPlugin::ActiveRecordAdapter
  end
end

In questo modo il risultato effettivamente è quello sperato! Cosa abbiamo fatto? Si è usata una variabile di classe chiamata @@special_attributes per memorizzare i vari campi.

Attenzione però, se complichiamo un po' il caso d'uso, ci troviamo di fronte ad comportamento inaspettato. Supponiamo che ci siano delle sottoclassi di Document, per esempio SpreadsheetDocument e TextDocument. Saremmo in questo caso davanti ad una STI (Single Table Inheritance) --- caso tutt'altro che raro nella realtà. Vediamo se tutto funziona ancora come ci aspettiamo:



class SpreadsheetDocument < Document
  special_attribute :author
end

SpreadsheetDocument.special_attributes
# => [ :title, :description, :author ]

Fin qui tutto bene! Aggiungiamo TextDocument ora:



class TextDocument < Document
  special_attribute :page_count
end

SpreadsheetDocument.special_attributes
# => [ :title, :description, :author, :page_count ]

Ahia, ecco il problema: :page_count è ovviamente l'inaspettato intruso, non è un attributo di SpreadsheetDocument. La spiegazione è semplice: una variabile di classe come @@special_attributes viene condivisa tra la classe padre e tutte le classi figlie. Non fa quindi al caso nostro. Proviamo con un'altra feature di Ruby: le variabili di istanza di classe.

Ruby è un linguaggio totalmente OOP, dunque tutto è un'oggetto, le classi non fanno eccezione. Possiamo fare in modo di aggiungere una variabile di istanza all'oggetto classe!




module SpecialAttributesPlugin

  def special_attribute(attribute)
    @special_attributes ||= []
    @special_attributes << attribute
  end

  def special_attributes
    @special_attributes ||= []
  end

end

# aggiungo il modulo ad ActiveRecord::Base
module ActiveRecord
  class Base
    extend SpecialAttributesPlugin::ActiveRecordAdapter
  end
end

Come si può notare, abbiamo fatto diventare @special_attributes una variabile dell'istanza. Ora riproviamo a testarne il funzionamento.



Document.special_attributes
# => [ :title, :description ] --> corretto!

SpreadsheetDocument.special_attributes
# => [ :author ] --> errato...

TextDocument.special_attributes
# => [ :page_count ] --> errato...

Ora effettivamente ognuna delle classi ha la sua variabile, differente da quella delle altre classi, ma le classi figlie non partono col valore della variabile della classe padre, Document! Sfortunatamente Ruby non possiede nulla semplice per ovviare a questo problema.. ma in qualche modo è comunque possibile arrivare al comportamento desiderato, in poche righe di codice:




module SpecialAttributesPlugin

  def special_attribute(attribute)
    @special_attributes ||= []
    @special_attributes << attribute
  end

  def special_attributes
    @special_attributes ||= []
  end

  def inherited(subclass)
    subclass.instance_variable_set "@special_attributes", special_attributes.dup
  end

end

# aggiungo il modulo ad ActiveRecord::Base
module ActiveRecord
  class Base
    extend SpecialAttributesPlugin::ActiveRecordAdapter
  end
end

Il giochetto è sfruttare la callback inherited(subclass), che viene chiamata quando viene generata una classe figlia. Agganciandoci a quest'evento, siamo in grado di inizializzare la variabile di istanza della classe figlia con quella della classe padre. Attezione però a non passare la medesima variabile al figlio, ma una copia, altrimenti padre e figli condivideranno il medesimo oggetto, con risultati non attesi.

Spero siate riusciti a seguirmi. Ora, per sentirci tutti meglio, arriviamo allo shortcut.. ActiveSupport estende di default l'oggetto Class per supportare il metodo class_inheritable_accessor. Possiamo riscrivere il plugin in questo modo, ottenendo il medesimo risultato:




module SpecialAttributesPlugin

  def special_attribute(attribute)
    class_inheritable_accessor :special_attributes
    self.special_attributes ||= []
    self.special_attributes << attribute
  end

end

# aggiungo il modulo ad ActiveRecord::Base
module ActiveRecord
  class Base
    extend SpecialAttributesPlugin::ActiveRecordAdapter
  end
end

Meglio, no?

Do worry... be happy

2011-04-15T00:00:00+02:00

Un'ora di lezione su come gestire il proprio business dal CEO bolognese di Balsamiq, Peldi Guillizzoni. Consigliato.

Adapt.js - Adaptive CSS

2011-04-15T00:00:00+02:00

Ennesima proposta per gestire CSS a più resoluzioni, suggerita dei creatori del grid system 960 e composta da un leggero script JS.

Adapt.js is a lightweight (940 bytes minified) JavaScript file that determines which CSS file to load before the browser renders a page. It is worth noting this is a proposed, not prescribed, approach to a problem with multiple solutions. Other methods include: building a separate site for mobile, or using a media queries to adjust layouts dynamically, with a polyfill for older browser support. Also a factor is how to handle image resolutions.

Nuova pipeline per gli assets in Rails 3.1

2011-04-14T00:00:00+02:00

Rails 3.1 sarà di default abilitato all'uso di Coffeescript e SCSS. Nonostante il trolling che si sta generando su Github, approvo. In weLaika utilizziamo entrambi gli strumenti in ogni progetto, insieme a Slim come templating HTML. Nonostante la solita spocchiosità, mi trovo d'accordo con DHH e i suoi tweet:

Real Men Write JavaScript Directly. I recall that being said about the JavaScript frameworks when they emerged. I also love how most of the arguments against CoffeeScript were the same we faced against Ruby back in the day. It's "cute", "toy", "just syntax". Here's the Rails gospel: Promote good ideas and technologies. See Ajax, REST, Atom, testing. Rails is a curated set of tech choices.

Placeholder Services

2011-04-13T00:00:00+02:00

Se non sono incredibilmente lenti, fanno comodo in fase di prototipazione.

PJAX

2011-04-13T00:00:00+02:00

PJAX loads HTML from your server into the current page without a full reload. It's ajax with real permalinks, page titles, and a working back button that fully degrades.

Piccola libreria sviluppata dal solito defunkt. Viene sfruttata per il nuovo Issue manager di Github (e verrà presto propagata in altre aree del sito). Lato server è particolarmente semplice supportarlo:


def my_page
  if request.headers['X-PJAX']
    render :layout => false
  end
end

Early Quora Design Notes

2011-04-13T00:00:00+02:00

Interessante post sulle decisioni di design prese per sviluppare Quora.

Another important decision was to be totally ruthless and make real design decisions. All too often in the past I'd find myself falling for some piece of UI and nurture it at the expense of the surrounding elements. Or worse, I'd try to appease someone who was giving feedback or pushing for specific agendas versus trying to create the best UI. This time, however, I was careful to form as few emotional bonds as necessary and really work on rational arguments for everything I designed. By eliminating all but the most important pieces, those that remained always have some concrete purpose.

Chameleon Project

2011-04-13T00:00:00+02:00

If you're an iOS developer, you're already familiar with UIKit, the framework used to create apps for the iPhone, iPod and iPad. Chameleon is a drop in replacement for UIKit that runs on Mac OS X. In many cases, your iOS code doesn't need to change at all in order to run on a Mac.

Progetto sicuramente con del potenziale. Twitterrific è stato sviluppato su questo Framework.

Solarized: colorscheme per il tuo text editor preferito

2011-04-12T00:00:00+02:00

Solarized is a sixteen color palette (eight monotones, eight accent colors) designed for use with terminal and gui applications. It has several unique properties. I designed this colorscheme with both precise CIELAB lightness relationships and a refined set of hues based on fixed color wheel relationships.

Mai ho visto tanto studi teorici dietro alla scelta dei colori da utilizzare all'interno di un editor di testo. Tendenzialmente preferisco uno sfondo nero e maggiore contrasto, ma proviamo a vedere l'effetto che fa. Disponibile anche per Textmate.

Cinque lezioni dopo un anno di weLaika

2011-04-11T00:00:00+02:00

Ebbene sì, un'anno è già passato. Il 2 Aprile 2010 ore 12.00, sette pischelli --- età media di 24-25 anni --- si riuniscono di fronte ad un notaio per firmare lo statuto ufficiale di weLaika; società sognata, pensata e definita durante mesi di focose discussioni e appassionati thread mail.

Sono stato, insieme a Matteo e Federico, tra i soci operativi dal primo giorno. Posso dire, con immensa soddisfazione, di essermi riempito le tasche con palate di informazioni su cosa vuol dire lanciare una startup da zero. Zero clienti, zero esperienza di gestione manageriale alle spalle.

Parecchie cose sono cambiate in un anno. Il numero di lavoratori IT full-time è passato da 3 a 6, più un paio di collaboratori saltuari che ci aiutano all'occorrenza. weLaika ha aperto il suo piccolo "dipartimento" di montaggio e ripresa video. Acmos Adv, agenzia pubblicitaria e di comunicazione già presente da qualche anno sulla piazza, è entrata a far parte di weLaika a tutti gli effetti, facendo lievitare il numero di stomaci da sfamare ad un totale di circa 15 e trasformando weLaika in una società multi-core in grado di coprire buona parte delle esigenze di comunicazione (web e non) di qualsiasi azienda.

Siamo solo all'inizio, e stiamo continuando a sbagliare una valanga di cose, ma qualche consiglio mi sento di poterlo condividere a chi volesse intraprendere la nostra stessa strada.

Un passo alla volta, con la dovuta calma

Decidi di fondare una startup informatica e il tuo gruppo è composto da 3 ragazzi neo-laureati in Ingegneria Informatica, con una forte esperienza tecnica ma che non hanno idea di cosa voglia dire tenere in piedi una baracca chiamata "Società cooperativa". Decidi di non voler tirare fuori un soldo, investendo unicamente sulle tue capacità e sul tuo tempo. Ti metti in testa di non voler evadere neanche un'euro (cosa che di per se' sarebbe superflua da dire, ma la realtà ci dice altro).

È normale che finirai per prenderti un sacco di legnate sui denti per qualche mesetto. Tutto ciò che non ti uccide ti fortifica, per carità, ma se tornassi indietro, probabilmente avrei cercato di bruciare un po' meno tappe tutte insieme. Magari prima una semplice società di persone, o magari più loffi ancora, e preferire delle semplici partite IVA per qualche mese. Meno spese, meno burocrazia, meno regole da seguire, meno cose da imparare tutte insieme.

C'è tutto un mondo di complicazioni là fuori che se sei un nerd con spirito ottimista e sognatore non ti immagini minimamente. Occhio a non tenerne conto, ci si fa male.

Intuisci i tuoi punti di forza

Sembra banale dirlo, ma se c'è un punto dopo il quale senti che tutto sta prendendo la piega giusta, è quello in cui capisci quanto vali e quali sono le carte che puoi spendere con i tuoi clienti. Putroppo, sarà molto difficile capirlo a tavolino. Dovrai incontrare qualcuno che molto semplicemente ti apra gli occhi, e te lo faccia notare. Ad ogni modo, sforzati ad intuire il prima possibile il perchè susciti curiosità/interesse, e quali sono stati i motivi per i quali un cliente abbia scelto proprio te.

weLaika vive di un continuo lavoro di formazione e ricerca su tutte le tecnologie web in grado di portare al minimo tempi di sviluppo e al massimo la produttività delle proprie risorse. Il nostro modus operandi si basa sulla scelta di pochi strumenti di lavoro predefiniti per tutto il team: Wordpress per siti "semplici", Rails per siti più complessi/gestionali/eshop, Sencha e Phonegap per applicazioni mobile cross-device, Websockets per funzionalità chat e push. Se ci si trova davanti a qualcosa di non risolvibile con gli strumenti a disposizione, si pensa sul lungo periodo, valutando con attenzione le alternative e cercando di rendere quanto più riutilizzabile e documentato il proprio lavoro. Periodicamente si rimettono in discussione le varie scelte fatte, per verificare se continuino ad essere le migliori.

Col passare dei mesi, ci siamo resi conto che con le nostre scelte operative eravamo in grado di offrire tempi e costi di sviluppo dimezzati rispetto ai nostri concorrenti, con qualità spesso e volentieri superiore. Capire il mercato nel quale si opera ed essere sicuri dei propri vantaggi permette una comunicazione col potenziale cliente meno titubante, più convincente e con percentuali di successo più alte.

Pretendi un contratto

Sembrerà scontato dirlo, ma perfavore, anche se sei agli inizi e non vedi l'ora di iniziare a dimostrare a tutti quanto vali, esigi la firma di un contratto prima di incominciare a lavorare. Non importa se hai davanti la Nike, il Comune di Roma o una piccola azienda familiare. Non fare mai l'errore di cedere su questo punto, non abboccare ai vari "non ti preoccupare, puoi fidarti". E' un rischio enorme, per te e per i tuoi clienti. Tra professionisti non ci deve essere bisogno di doversi fidare, è d'obbligo pretendere sicurezze, ricambiando con la stessa moneta.

E' fondamentale chiarire con precisione fino a dove arrivano i diritti e doveri di entrambe le parti, perchè anche con la buona fede più sincera è probabile che verbalmente non ci si stia intendendo sul serio, o che le cose cambino nel giro di qualche mese, a lavori iniziati. Non importa se il contratto sarà scritto in una forma non propriamente ineccepibile o magari presenterà qualche lacuna. I successivi saranno migliori. Ma avere un brutto contratto è meglio che non averne nessuno.

Specifiche, specifiche, specifiche

In ogni lavoro che prendete in carico, aggiungete una prima fase (pagata) di mockup e/o definizione delle specifiche del progetto. E' fondamentale, prima di iniziare a lavorare, avere la certezza che voi e il cliente abbiate in mente il medesimo risultato finale. Cose che per voi sono ovvie potrebbero non esserlo altrettanto per il vostro interlocutore, e viceversa. L'unico modo per capirsi con certezza è quello di sviscerare ogni blocco funzionale con quanto più dettaglio e realismo possibile.

So cosa state pensando, ma vi fermo subito. Si tratta nel 90% dei casi di tempo assolutamente non perso. Definire i progetti con un simile livello di dettaglio ci aiuta in primo luogo ad arrivare ad un preventivo dei tempi di sviluppo più realistico, con minori possibilità di firmare contratti con costi sotto-stimati, e in secondo luogo a scoprire con un certo anticipo tutta quella serie di "casi particolari" ed eccezioni che spesso spuntano fuori nel peggiore dei momenti costringendoti a corse contro il tempo.

Fai sentire la tua voce

Essere bravi è importante, ma farlo sapere a tutti è fondamentale. L'ingegnere informatico non è tipicamente la figura più socievole, comunicativa e propensa all'auto-celebrazione che esista. Spesso non ha idea di quanto valga il proprio lavoro, e quando tenta di esporre qualcosa al mondo lo fa solitamente con estrema goffaggine, controvoglia e utilizzando terminologie poco comprensibili ed attraenti. Questo è male, e trattare con noncuranza i problemi di comunicazione verso l'esterno può essere potenzialmente catastrofico.

In weLaika partiamo da questo punto di vista sicuramente svantaggiati, ed è per questo che gli sforzi devono essere maggiori rispetto alla norma. Abbiamo partecipato al Rails Rumble 2010 -- una gara mondiale di sviluppo di applicazioni web in 48 ore -- proponendo Boarrd. Abbiamo ottenuto una buona copertura mediatica e siamo addirittura riusciti a convincere un'ottimo studente USA a passare da noi l'estate per un'internship aziendale. Abbiamo trasformato i migliori framework e tool sviluppati internamente in progetti open source su Github (incurve, wp_sass_haml, rdiff-backup, WETableViewController) e abbiamo contribuito attivamente al miglioramento di progetti già esistenti (socky, guard-compass).

Ma possiamo fare di più. Una maggiore cura nel copyrighting del sito aziendale, una maggiore partecipazione a conferenze legate ai temi chiave di weLaika, ed un uso di twitter e blog costante saranno sicuramente i punti sui quali concentrarsi nel prossimo anno.

Siete arrivati fino a qui? Sul serio?

Grazie per avere condiviso con me questo viaggio nel tempo.

Pow: 37signals colpisce di nuovo

2011-04-09T00:00:00+02:00

Server e un DNS da installare sul proprio Mac per sviluppo locale di applicazioni Rack. Bundler e RVM compatibile. Installato immediatamente. Sembra abbia qualche tipo di bug relativo allo scaricamento tramite send_data, ma a parte questo é incredibilmente utile. Mi aspetto un progetto similare per Linux nel giro di un paio di settimane.

Prime Impressioni su Sphinx

2011-04-09T00:00:00+02:00

Per la prima volta ho avuto modo di testare funzionamento di Sphinx, uno dei più popolari motori di ricerca full-text in circolazione. L'ho preferito a Lucene per evitare il disagio di Java, e a Ferret per la maggiore affidabilità che mi sembrava dare dal punto di vista del supporto e della stabilità.

Installazione

L'installazione è stata incredibilmente semplice e rapida con homebrew:

brew install sphinx

In realtà mi sono reso presto conto che la ricetta homebrew non prevedeva il supporto per libstemmer (vedremo dopo a cosa serve), quindi ho modificato leggermente la ricetta in questo modo (sudo brew edit sphinx):



require 'formula'

class Sphinx < Formula
  url 'http://sphinxsearch.com/downloads/sphinx-0.9.9.tar.gz'
  homepage 'http://www.sphinxsearch.com'
  md5 '7b9b618cb9b378f949bb1b91ddcc4f54'
  head 'http://sphinxsearch.googlecode.com/svn/trunk/'

  fails_with_llvm "fails with: ld: rel32 out of range in _GetPrivateProfileString from /usr/lib/libodbc.a(SQLGetPrivateProfileString.o)"

  def install
    system "curl -O http://snowball.tartarus.org/dist/libstemmer_c.tgz"
    system "tar zxvf libstemmer_c.tgz"

    args = ["--prefix=#{prefix}", "--disable-debug", "--disable-dependency-tracking", "--with-libstemmer"]
    # configure script won't auto-select PostgreSQL
    args << "--with-pgsql" if `/usr/bin/which pg_config`.size > 0
    args << "--without-mysql" if `/usr/bin/which mysql`.size <= 0

    system "./configure", *args
    system "make install"
  end

  def caveats
    <<-EOS.undent
    Sphinx depends on either MySQL or PostreSQL as a datasource.

    You can install these with Homebrew with:
      brew install mysql
        For MySQL server.

      brew install mysql-connector-c
        For MySQL client libraries only.

      brew install postgresql
        For PostgreSQL server.

    We don't install these for you when you install this formula, as
    we don't know which datasource you intend to use.
    EOS
  end
end

Configurazione

A questo punto, il peggio è passato. Thinking Sphinx è una gemma ottimamente documentata e seguita dal suo sviluppatore, e ti permette di impostare degli indici di ricerca per i tuoi modelli Rails direttamente al loro interno, grazie ad un semplice DSL di questo tipo:



class User < ActiveRecord::Base
  devise :database_authenticatable, :registerable, :recoverable, :rememberable, :trackable, :validatable

  define_index do
    indexes first_name
    indexes last_name, :sortable => true
    indexes email
    indexes company
    indexes company_role
    indexes city
    indexes website
    indexes notes
    set_property :enable_star => true
    set_property :min_infix_len => 1
  end

end

Avviare Sphinx

Una volta impostati gli indici (per maggiori info su come funziona Sphinx rifatevi a questa pagina, per esempio), basta semplicemente far partire un rake task per convertire il DSL in file di configurazione Sphinx: thinking_sphinx:configure. Potete poi far partire il server Sphinx con thinking_sphinx:start. Giuro che è stato veramente così semplice.

Thinking Sphinx dispone di una serie di rake task aggiuntivi per coprire tutti i vostri bisogni:

rake thinking_sphinx:configure      # Generate the Sphinx configuration file using Thinking Sphinx's settings
rake thinking_sphinx:index          # Index data for Sphinx using Thinking Sphinx's settings
rake thinking_sphinx:rebuild        # Stop Sphinx (if it's running), rebuild the indexes, and start Sphinx
rake thinking_sphinx:reindex        # Reindex Sphinx without regenerating the configuration file
rake thinking_sphinx:restart        # Restart Sphinx
rake thinking_sphinx:running_start  # Stop if running, then start a Sphinx searchd daemon using Thinking Sphinx's settings
rake thinking_sphinx:start          # Start a Sphinx searchd daemon using Thinking Sphinx's settings
rake thinking_sphinx:stop           # Stop Sphinx using  Thinking Sphinx's settings
rake thinking_sphinx:version        # Output the current Thinking Sphinx version

Per ricercare facendo uso di Sphinx, rifatevi all'ottima guida, ma fondamentalmente si parla di fare cose come:


User.search(params[:search], :star => true, :order => :last_name).page(params[:page]).per(10)

E come forse vi state chiedendo sì, è già compatibile con will_paginate e Kaminari (dalla versione ~> 2.0.3).

Word stemming

Se avete installato Sphinx con il flag --with-libstemmer da me suggerito qualche riga più in alto, allora avrete anche la possibilità di configurare il word stemming italiano. Questo significa che Sphinx sarà in grado di gestire correttamente le forme singolari/plurali delle ricerche, fornendo risultati più rilevanti.

Conclusioni

Quello che abbiamo visto è la base. Sphinx è incredibilmente potente e permette, ad esempio:

La ricerca anche sulle relazioni delle entità;
Ordinare i risultati per peso raggruppandoli in slot temporali (utile per ricerche real-time);
Ricercare mediante più sintassi (da quella per operatori logici, a quella con wildcards);
Effettuare ricerche geospaziali;

L'unico svantaggio di Sphinx rispetto ad altri motori di ricerca full-text è che gli indici devono essere totalmente rigenerati quando anche solo un'elemento della tabella cambia. In realtà anche questo aspetto è stato pressochè risolto mediante delta indexes, praticamente trasparenti all'utente.

Insomma. Sphinx mi ha convinto.

Fuck you. Pay me.

2011-04-09T00:00:00+02:00

Presentazione di Mike Monteiro, Design Director di Mule Design, consigliata a chiunque sia alle prime armi col dover affrontare la sfida di gestire clienti, anche quando le cose non stanno andando come sperato (mi ricorda qualcuno). Spoiler: cercati un'avvocato.

My advice to them is usually: you need to talk to a lawyer about this stuff. There are two things I hear the most: "Lawyers are too expensive. I can't afford them". The second: "Are we at that pointalready do you think?". You are at the point where you need a lawyer when you've decided stop being a design amateur and become a design professional. That's the time when you need a legal professional to look at those contracts.

Crash Course: Design for Startups

2011-04-07T00:00:00+02:00

Piccoli, semplici, ottimi suggerimenti da Paul Stamatiou per iniziare ad entrare nel mondo del web-design senza sbagliare tutto. Consigliato a tutti i programmatori duri e puri là fuori: anche noi ce la possiamo fare. Coraggioso il suo reverse portfolio: tutti i propri lavori, dal più orrendo, al più recente.

Top ten reasons why I won't use your open source project

2011-04-07T00:00:00+02:00

Nei progetti open, così come in qualsiasi altro contesto, la comunicazione verso il mondo esterno è fondamentale per avere successo, trasmettere professionalità, stabilità e propagare interesse.

Create astonishing iCal-like calendars with jQuery

2009-01-27T00:00:00+01:00

According to my web designer experience, one of the most common requests from clients when it comes to Wordpress personalization, is to add a basic event calendar to their website.

Finding a good place to position a big table like a calendar within your Wordpress template is always a taught work. In addition, the <table> tag itself is often quite difficult to style in a good way.

One of the calendar solution that I came out with and that I'm particulary proud of is the one I built inside the freshly launched Graham Watson for President website.

View the online Demo!

I wanted it to be similar to the iPhone Calendar application (or, if you want, to the little calendar on the left bottom corner in iCal). And I also wanted to keep the code as little and sweet as possible (we don't like maintenance, do we?).

Here's the simple HTML code I used, the simplest you could ever come up with:

  
  

  <table cellspacing="0">
    <thead>
      <tr>
        <th>Mon</th><th>Tue</th><th>Wed</th>
        <th>Thu</th><th>Fri</th><th>Sat</th>
        <th>Sun</th>
      </tr>
    </thead>
    <tbody>
      <tr>
        <td class="padding" colspan="3"></td>
        <td> 1</td>
        <td> 2</td>
        <td> 3</td>
        <td> 4</td>
      </tr>
      <tr>
        <td> 5</td>
        <td> 6</td>
        <td> 7</td>
        <td> 8</td>
        <td class="today"> 9</td>
        <td>10</td>
        <td>11</td>
      </tr>
      <tr>
        <td>12</td>
        <td class="date_has_event">
          13
        </td>
        <td>14</td>
        <td>15</td>
        <td>16</td>
        <td>17</td>
        <td>18</td>
      </tr>
      <tr>
        <td>19</td>
        <td>20</td>
        <td>21</td>
        <td class="date_has_event">
          22
        </td>
        <td>23</td>
        <td>24</td>
        <td>25</td>
      </tr>
      <tr>
        <td>26</td>
        <td>27</td>
        <td>28</td>
        <td>29</td>
        <td>30</td>
        <td>31</td>
        <td class="padding"></td>
      </tr>
    </tbody>
    <tfoot>
      <th>Mon</th><th>Tue</th><th>Wed</th>
      <th>Thu</th><th>Fri</th><th>Sat</th>
      <th>Sun</th>
    </tfoot>
  </table>

All the magic takes place with some ninja CSS:

  
  
  table {
    border-collapse: separate;
    border: 1px solid #9DABCE;
    border-width: 0px 0px 1px 1px;
    margin: 10px auto;
    font-size: 20px;
  }
  td, th {
    width: 81px;
    height: 81px;
    text-align: center;
    vertical-align: middle;
    background: url(../img/cells.png);
    color: #444;
    position: relative;
  }
  th {
    height: 30px;
    font-weight: bold;
    font-size: 14px;
  }
  td:hover, th:hover {
    background-position: 0px -81px;
    color: #222;
  }
  td.date_has_event {
    background-position: 162px 0px;
    color: white;
  }
  td.date_has_event:hover {
    background-position: 162px -81px;
  }
  td.padding {
    background: url(../img/calpad.jpg);
  }
  td.today {
    background-position: 81px 0px;
    color: white;
  }
  td.today:hover {
    background-position: 81px -81px;
  }

Please note a couple of things here, as it's the trickiest part:

Make your images seamless. Draw only the top and right border of the cells inside the image: neighbour cells will continue the pattern. Then add the bottom and left border to the table via CSS to complete the work.
Use a single image for all the graphics whenever is possible to decrease the download speed time (just a single TCP three-way-handshake to manage, a single Apache request to be answered by your server, a single PNG header overhead to be downloaded).

In addition to the plain calendar structure, we obviously also want the events description to show up on mouse hover. To do that, just add this block inside the calendar cells:



<td class="date_has_event">
  13
  <div class="events">
    <ul>
      <li>
        <span class="title">Event 1</span>
        <span class="desc">Lorem ipsum dolor sit amet, consectetu adipisicing elit.</span>
      </li>
      <li>
        <span class="title">Event 2</span>
        <span class="desc">Excepteur sint occaecat cupidatat non proident, sunt in culpa qui officia deserunt mollit anim id est laborum.</span>
      </li>
    </ul>
  </div>
</td>

And use the beautiful, handy, lightweight Coda-like effect for jQuery to bring it to life (how I love jQuery?)

  
  
  $(function () {
    $('.date_has_event').each(function () {
      // options
      var distance = 10;
      var time = 250;
      var hideDelay = 500;

      var hideDelayTimer = null;

      // tracker
      var beingShown = false;
      var shown = false;

      var trigger = $(this);
      var popup = $('.events ul', this).css('opacity', 0);

      // set the mouseover and mouseout on both element
      $([trigger.get(0), popup.get(0)]).mouseover(function () {
        // stops the hide event if we move from the trigger to the popup element
        if (hideDelayTimer) clearTimeout(hideDelayTimer);

        // don't trigger the animation again if we're being shown, or already visible
        if (beingShown || shown) {
          return;
        } else {
          beingShown = true;

          // reset position of popup box
          popup.css({
            bottom: 20,
            left: -76,
            display: 'block' // brings the popup back in to view
          })

          // (we're using chaining on the popup) now animate it's opacity and position
          .animate({
            bottom: '+=' + distance + 'px',
            opacity: 1
          }, time, 'swing', function() {
            // once the animation is complete, set the tracker variables
            beingShown = false;
            shown = true;
          });
        }
      }).mouseout(function () {
        // reset the timer if we get fired again - avoids double animations
        if (hideDelayTimer) clearTimeout(hideDelayTimer);

        // store the timer so that it can be cleared in the mouseover if required
        hideDelayTimer = setTimeout(function () {
          hideDelayTimer = null;
          popup.animate({
            bottom: '-=' + distance + 'px',
            opacity: 0
          }, time, 'swing', function () {
            // once the animate is complete, set the tracker variables
            shown = false;
            // hide the popup entirely after the effect (opacity alone doesn't do the job)
            popup.css('display', 'none');
          });
        }, hideDelay);
      });
    });
  });

This is the CSS code used to style the popup div:

  
  
  .events {
    position: relative;
  }
  .events ul {
    text-align: left;
    position: absolute;
    display: none;
    z-index: 1000;
    padding: 15px;
    background: #E7ECF2 url(../img/popup.png) no-repeat;
    color: white;
    border: 1px solid white;
    font-size: 15px;
    width: 200px;
    -moz-border-radius: 3px;
    -khtml-border-radius: 3px;
    -webkit-border-radius: 3px;
    -border-radius: 3px;
    list-style: none;
    color: #444444;
    -webkit-box-shadow: 0px 8px 8px #333;
  }
  .events li {
    padding-bottom: 5px;
  }
  .events li span {
    display: block;
    font-size: 12px;
    text-align: justify;
    color: #555;
  }
  .events li span.title {
    font-weight: bold;
    color: #222;
  }

Please note how nice the box-shadow CSS property is when applied to the popup... unfortunately, this CSS3 property is still only implemented in WebKit browsers (Safari, Google Chrome), but more of them are about to support it.

Download the source files!

And... that's it. Simple and sweet, as we wanted. Obviously, you'll have to properly configure your preferred Wordpress plugin to output a code like the one I showed you, but that's the boring part of the lesson and I'll skip it :) Instead, let me just add a note...

Choosing the right Wordpress Plugin

There are plenty of pretty good Wordpress calendar plugins around to facilitate your backend work. I can tell you I tried them all, and the one that convinced me the most was Event Calendar.

With Event Calendar you can add a countless number of events to any post or page directly within the New and Edit page, there's a lot of great functions you can use to freely tweak the event-browsing experience within your PHP template -- but some work still should be done in this direction -- it's AJAX ready and the plugin itself is already localized in 19 languages.

Hope you've enjoyed the tut! I'll try to reply to your question in my free time :)

Stefano Verna

Faster TDD with iTerm and vim

iTerm anyone?

How to communicate with iTerm

Welcome iTermux!

Demo Time

Feedbacks appreciated!

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

Un esempio concreto

Testare l'azione, Integration-style

Fantastico! Anzi, no.

Isolarsi da Ability: un primo passo verso la speranza

Avanti tutta! Isoliamoci dai modelli!

L'ultimo passaggio: un test che ne vale quattro (WHOA!)

Abbiamo finito? SRSLY?!

Ottimizzare la leggibilità del proprio sito con Compass /3

Ottimizzare la leggibilità del proprio sito con Compass /2

Vertical Rythm con Compass

Ci fermiamo anche oggi

Referenze

Ottimizzare la leggibilità del proprio sito con Compass /1

Non comporre mai una pagina senza una scala tipografica

Mantieni un unico ritmo verticale nella pagina

Piccola digressione sull'em

Per oggi basta

rspec-given: e se fosse la soluzione?

TDD è meglio che fare Unit Testing a posteriori

Vendorer: un Bundler per mantenere dipendenze esterne

Spinach e Turnip: alternative a Cucumber

Spinach

Turnip

Cosa ne pensate?

Far convivere repositories di WP Plugins con Github

Search e replace di file multipli su Vim

Sul fondamentale problema della stima costi/tempi

Tabs UJS con i data-behaviour

Esempio: una tabbed interface

Linear gradients su IE: Sinatra alla riscossa

Posso dire di aver switchato da Textmate a Vim

Un task Capistrano per backuppare il DB di produzione

Il costo del cambiamento nel mondo Agile

Buone vacanze!

I più bei bottoni CSS3 del mondo

Buffer è "ramen profitable"

Unique Value Proposition

"Coming soon" pages? Evitale.

Why sharing knowledge is vital for success

From idea to paying costumers in 7 weeks

Implementing DSL Blocks

atk_icons: Agile Toolkit Icon Set su Compass

Propositi di inizio Giugno

Estendere il giro di nerd che visitano questo posto

Capire qualcosa di più su chi siete

Aumentare il coinvolgimento e la discussione

Pow e PHP

Nuova piattaforma di Continuous Integration: Goldberg

Learning Advanced Javascript

Aggiungere target="blank" sui link esterni con un Rack middleware

CoffeeBeans: AJAX con CoffeeScript su Rails

Usa oggetti Ruby nei form Rails con Informal

Batman.js

Deploy rapidi con Capistrano

Tapir: indicizzatore di post per siti statici

Come assumere programmatori

24 tools da terminale che forse non conoscevi

Subtle Patterns: sfondi Creative Commons per il tuo prossimo progetto web

Vico: alternativa sensata a Textmate

Un web proxy in Rack per cross-domain Ajax

Cross-domain Ajax con Rack e Net::HTTP

Spine: l'erede di Backbone.js

Capistrano e i tunnel SSH

mogenerator: mai più rigenerare le classi dei modelli Core Data manualmente

Slow time

hookup

ScottBot: a "that's what she said" bot

39 differenti ombre CSS3-only

Sinatra: un repository viewer web-based in.. 50 righe

CSS3 Github buttons

Icone social CSS-only

Pattener: generatore di sfondi via SASS

Isolarsi da `Ability`: un primo passo verso la speranza