In que­sti ultimi tempi ho sen­tito par­lare spesso dei pro e i con­tro dell’uso delle classi seman­ti­che nell’HTML¹.

L’approccio pre­di­cato fino ad ora era sem­pre stato più o meno que­sto: non usare nomi come rosso o destra per le classi per­ché così facendo leghi l’aspetto visuale al mar­kup, che dev’essere il più pos­si­bile seman­tico, ovvero, deve avere un signi­fi­cato sle­gato dalla pre­sen­ta­zione. Una cosa con­di­vi­si­bile, almeno fin­ché si tratta di usare una classe come rosso.

Nicole Sullivan² sostiene invece che que­sto approc­cio, come diversi altri, va ripen­sato e che l’uso di classi seman­ti­che per i CSS non è una buona idea. Più pre­ci­sa­mente, se vogliamo mas­si­miz­zare il riu­ti­lizzo di stili e classi in con­te­sti diversi, i nomi devono essere in qual­che misura astratti, sle­gati dal con­te­nuto e quindi neces­sa­ria­mente non semantici.

Anch’io mi sono con­vinto di que­sta cosa: usare una classe come fattura è sba­gliato esat­ta­mente come rosso, né più né meno. Ogni layer di un sistema deve par­lare il pro­prio lin­guag­gio e il lin­guag­gio dei CSS riguarda l’aspetto visivo. Di con­se­guenza anche le classi devono rispet­tare que­sta carat­te­ri­stica. Ad es. al posto di rosso pos­siamo usare, che so, enfasi o accent-color.

Questa cosa va di pari passo con l’altra pra­tica con­si­de­rata un anti­pat­tern, la cosid­detta “clas­site”, ovvero, un abuso delle classi. Nel momento in cui dob­biamo tro­vare i con­cetti visivi giu­sti per gui­darci nella scelta dei nomi, diventa natu­rale usare più classi con meno pro­per­ties³. Questo porta ad avere ele­menti con più classi asso­ciate, una per ogni tratto visivo che vogliamo applicare.

Basta usare que­sto approc­cio per qual­che tempo per capire che i CSS risul­tanti sono molto più leg­geri e molto più riu­ti­liz­za­bili anche se non è sem­pre facile tro­vare dei nomi per le classi che sod­di­sfino al 100%.

Stavo scri­vendo un post dopo aver letto l’annuncio di que­sto stru­mento per il con­trollo dei CSS quando mi è venuto in mente che forse sarebbe più inte­res­sante discu­tere dell’evoluzione gene­rale del (mio) modo di creare appli­ca­zioni¹ per il web. Quindi ho but­tato nel cestino il post sui CSS.

Oltre il “plain text”

Una delle ragioni del suc­cesso del web è il fatto di essere basato su for­mati testuali: se voglio vedere com’è fatta una pagina, un foglio di stile, uno script, basta che lo apra con un qual­siasi edi­tor di testo. Anche su tutti i pro­cessi che stanno a con­torno del lavoro crea­tivo vero e pro­prio bene­fi­ciano di que­sta sem­pli­cità. Una volta creato un file, que­sto è pronto per svol­gere la sua fun­zione senza pas­saggi inter­medi, basta cari­carlo sul sito.

Tutto que­sto, però, è sem­pre meno vero per­ché la pres­sione per otte­nere pre­sta­zioni sem­pre migliori sta por­tando sem­pre di più verso un con­te­nuto che, se ancora si può tec­ni­ca­mente defi­nire “plain text”, risulta illeg­gi­bile in modo diretto. ².

Poi ci sono l’ottimizzazione delle imma­gini o, come abbiamo visto, i con­trolli di qua­lità ecc. Insomma, si può dire che i pro­cessi usati nel creare delle appli­ca­zioni “tra­di­zio­nali”, con lin­guaggi com­pi­lati e anche il sem­plice sito sta­tico, si asso­mi­gliano sem­pre di più.

I pros­simi passi

Sono per­ciò arri­vato alla con­clu­sione che è sen­sato usare gli stessi stru­menti in tutti casi.

Quindi, anche se devo ancora pro­gram­mare la que­stione nel det­ta­glio, sicu­ra­mente comin­cerò a spo­stare i pro­getti sotto Jenkins; da lì vedrò poi di deci­dere caso per caso le ope­ra­zioni da fare. In alcuni casi gli stadi del pro­cesso saranno delle sem­plici otti­miz­za­zioni, in altri ci saranno anche tutte le varie bat­te­rie di test ma l’infrastruttura di base sarà la stessa.

Dopo aver par­lato dell’uso dei fil­tri con Git, penso sia una buona idea descri­vere gli usi degli hook in pre com­mit, ad esem­pio, per fare dei con­trolli pre­ven­tivi di qualità.

JavaScript non è cat­tivo, sono i bro­w­ser che lo dipin­gono così

Chiunque abbia un po’ di dime­sti­chezza con JavaScript se che ci sono delle dif­fe­renze fra le varie imple­men­ta­zioni dei bro­w­ser che pos­sono dare pro­blemi, anche molto gravi¹ , a par­tire da un codice appa­ren­te­mente senza difetti.

Un caso clas­sico è l’uso della vir­gola dopo l’ultimo ele­mento di una col­le­zione: lo stan­dard lo proi­bi­sce ma quasi tutti i bro­w­ser lo inter­pre­tano senza pro­blemi. La frase “quasi tutti i bro­w­ser” di solito signi­fica “tutti tranne Explorer” ed è così anche in que­sto caso ma a parti inver­tite. Qui è Explorer che applica alla let­tera le spe­ci­fi­che inter­rom­pendo il par­sing e lasciando gli utenti a piedi².

Un altro caso clas­sico, que­sta volta appli­ca­bile a tutti i bro­w­ser, è l’uso di varia­bili non dichia­rate. In que­sto caso la cosa è più sub­dola per­ché non si tratta di un errore dalle con­se­guenze vistose, ma spe­ci­fico per qual­che bro­w­ser, bensì di una cosa per­fet­ta­mente legale che può cau­sare pro­blemi solo in certe con­di­zioni. Neanche que­sta è una bella prospettiva!

Insomma, è neces­sa­rio un qual­che stru­mento che ci per­metta di con­trol­lare la qua­lità del codice che scri­viamo prima che venga man­dato nella repo.

JSLint e JSHint

Per con­trol­lare la qua­lità di JavaScript cono­sco due stru­menti: JSLint e JSHint.

Il primo è quello più famoso, è in cir­co­la­zione da molto e fa un lavoro egre­gio nel segna­lare una serie ster­mi­nata di pos­si­bili problemi.

Il secondo è una deri­va­zione di JSLint, creata con l’intenzione di dare uno stru­mento un po’ più adat­ta­bile alle con­ven­zioni usate in un certo progetto.

Ho scelto JSHint pro­prio per que­sta ragione per­ché negli ultimi tempi mi sono abi­tuato a scri­vere le vir­gole prima dell’argomento suc­ces­sivo³:

var items = [
    'a'
    , 'b'
    , 'c'
];

Il pro­blema è che JSLint non ne vuol sapere di con­si­de­rarlo valido.

Come invo­care i controlli

Il pro­blema con entrambi que­sti stru­menti è che sono scritti essi stessi in JavaScript e quindi, visto che dob­biamo invo­care i con­trolli da Git, ci serve un inter­prete al di fuori del browser.

Per fare que­sto, l’avrete già capito, pos­siamo usare Node.js, che pos­siamo instal­lare con MacPorts o Homebrew o a mano; poi ci serve npm per instal­lare i moduli di Node.js, in par­ti­co­lare node-jshint, che con­sente di usare JSHint con Node.js.

Node.js ed npm sono molto sem­plici da instal­lare. Per quanto riguarda JSHint biso­gna solo avere l’accortezza di instal­larlo nella direc­tory dei moduli con­di­visa, defi­nita da npm come instal­la­zione glo­bale.

Una volta instal­lato il tutto ci serve un script di shell che invo­che­remo dall’hook di pre-commit di git. Questo script ha il solo com­pito di leg­gere l’output di JSHint ed emet­tere l’eventuale segnale d’errore, visto che la uti­lità di suo non lo fa anche se ci sono pro­blemi. Limitandoci al minimo indi­spen­sa­bile:

#!/bin/sh
#
# Verifica la conformità dei file js alle linee guida stabilite.

RESULT=$(node-hint public/scripts/*.js)

if [ "$RESULT" != 'Lint Free!' ] ; then
    echo "$RESULT"
    exit 1
fi

Lo script appena mostrato va messo in .git/hooks/pre-commit.

Altre pos­si­bi­lità

In que­sto caso spe­ci­fico, ovvero, quello del con­trollo dei file JavaScript ci sono altre pos­si­bi­lità. Per TextMate ci sono un paio di bund­les: js-tools e javascript-tools che fanno que­sto e molto altro; per Emacs la situa­zione è meno strut­tu­rata e, come sem­pre, biso­gna arra­bat­tarsi per adat­tare le varie info che si tro­vano in rete alla pro­pria situa­zione; per ora ne fac­cio tran­quil­la­mente a meno.

Eccoci all’ultima pun­tata della serie dedi­cata a Org!

Nel post pre­ce­dente accen­navo alle cose che mi pia­ce­rebbe appro­fon­dire. Ecco qual­che dettaglio.

Esportare i docu­menti di Org

In diverse occa­sioni ho comin­ciato ad usare l’esportazione. Ho pro­vato i for­mati prin­ci­pali (testo, HTML e PDF) con buoni risul­tati. So che sem­bra una cosa da poco, ma se penso a quanto tempo ho dedi­cato in pas­sato per tro­vare una solu­zione decente dovrei fare i salti di gioia.

Non che abbia qual­cosa con­tro pro­grammi come Word, Pages od OpenOffice, cerco però di tenere il numero di stru­menti al minimo pos­si­bile e, se pos­si­bile, avere un for­mato comune o almeno facil­mente mani­po­la­bile¹.

La cosa fun­ziona bene a suf­fi­cienza da farmi acca­rez­zare l’idea di but­tare WordPress e pas­sare a un sistema basato su file. Un giorno, forse…

Org per la programmazione

Se usiamo Emacs² per il codice sor­gente, Org è uti­lis­simo già solo per il fatto di poter col­le­gare diret­ta­mente i todo con il punto pre­ciso del codice³, che è esat­ta­mente il modo in cui lo uso adesso. Ma vor­rei esplo­rare altre possibilità.

Prima di tutto è pos­si­bile inse­rire diret­ta­mente del codice in un docu­mento di Org e – cosa molto comoda – pos­siamo edi­tare il fram­mento di codice in un buf­fer dedi­cato, in modo tra­spa­rente e con tutte la faci­li­ta­zioni spe­ci­fi­che per il lin­guag­gio usato in quel frammento.

Questo blocco di codice può essere trat­tato in diversi modi: può essere trat­tato come esem­pio let­te­rale; può essere espor­tato il risul­tato della sua valu­ta­zione; pos­sono essere espor­tate entrambe le cose o, infine, nes­suna delle due.

A que­sto punto, siamo pra­ti­ca­mente dalle parti del lite­rate pro­gram­ming, che rimane sem­pre una que­stione che mi affa­scina assai.

Prima di Org, la cosa più vicina all’ideale che ho incon­trato è Scribble ma lavora solo con Racket⁴ e, per quanto mi possa pia­cere, non è rea­li­stico pen­sare che si usi solo un lin­guag­gio in un pro­getto web: biso­gna poter gestire anche JavaScript, SQL e HTML, a meno di gene­rarli tutti.

Org approc­cia la que­stione in modo neces­sa­ria­mente meno sofi­sti­cato, trat­tando i fram­menti di codice al pari di tutti gli altri sistemi per il lite­rate pro­gram­ming, ovvero, come sem­plice testo. Questo signi­fica che non sap­piamo se il sor­gente che sarà assem­blato è sin­tat­ti­ca­mente valido fino a quando non verrà com­pi­lato o eseguito.

I van­taggi, però, sono grandi e sono sem­pre quelli che mi hanno fatto pas­sare a que­sto ambiente: inte­gra­zione, fles­si­bi­lità ed effi­cienza. Per ora mi sono limi­tato a gio­carci un po’, con fram­menti di codice qua e là ma alla prima occa­sione lo testerò più seriamente.

Se siete arri­vati a leg­ger fin qui, allora apprez­zete Org: che io sap­pia, non esi­ste miglior esem­pio di ciò che si può fare con Emacs.

Nelle pun­tate precedenti

• Org: cos’è cam­biato dopo tre mesi di utilizzo
• L’agenda di Org
• I todo con Org
• Come uso Org
• Cosa manca a Org?
• OmniFocus e Org, pro e contro
• Addio a OmniFocus

Siamo quasi giunti alla fine di que­sta car­rel­lata su Org. In vista della chiu­sura volevo accen­nare ai cam­bia­menti che ha por­tato l’uso di que­sto sistema in sosti­tu­zione ad OmniFocus.

Le cose da fare e le cose collegate

A grandi linee il mio modo di gestire i todo è rima­sto simile a prima. Certo, adesso il sistema è molto più fles­si­bile, pre­ciso e non tor­ne­rei più indie­tro, ma non ha cam­biato molto il modo di affron­tare le cose da fare.

Con Org è però molto più facile pas­sare senza solu­zione di con­ti­nuità dal brain­stor­ming alla pia­ni­fi­ca­zione, dal pren­dere appunti allo scri­vere docu­men­ta­zione. A seconda del con­te­sto un’outline può rap­pre­sen­tare: la strut­tura di un docu­mento d’analisi o una lista delle cose da fare o anche essere tutte e due le cose con­tem­po­ra­nea­mente o posso sce­gliere di farle con­vi­vere all’interno dello stesso documento.

Metamorfosi dei file di progetto

Per que­sto motivo, alcuni dei file che un paio di mesi fa erano nati come pro­getti si stanno tra­sfor­mando len­ta­mente in dos­sier che riguar­dano più il cliente che il sin­golo pro­getto. Per ora è un aspetto mar­gi­nale ma credo che diven­terà più impor­tante con l’andar del tempo.

Addio “pro­gram­ma­zione”?

Ho invece quasi com­ple­ta­mente abban­do­nato la pro­gram­ma­zione delle cose da fare. È un fatto piut­to­sto iro­nico per­ché una delle cose che mi man­ca­vano in Omnifocus era quella di poter riem­pire in modo semiau­to­ma­tico una gior­nata in base al tempo sti­mato per le diverse azioni.

Adesso che con Org avrei gli stru­menti per fare qual­cosa di simile, non ne sento più il biso­gno. Sì, cerco comun­que di sti­mare il tempo neces­sa­rio a fare qual­cosa ma solo per con­fron­tarlo a con­sun­tivo. Scelgo le cose da fare in base al momento; alcune forse riman­gono più indie­tro di altre – su que­sto vor­rei essere meno appros­si­ma­tivo – ma nel com­plesso la mag­giore flui­dità non mi dispiace affatto.

Ho invece rico­min­ciato ad usare le sca­denze, anche se in un modo forse diverso dal solito. Ho preso l’abitudine di segnare la sca­denza – e non la data dell’evento – agli appun­ta­menti, in modo da vederli “arri­vare” con qual­che giorno di anticipo.

Attualmente uso la data di pro­gram­ma­zione solo per i com­piti che si ripetono.

La review settimanale

Anche la review set­ti­ma­nale si è un po’ sem­pli­fi­cata. Da una parte non devo più pia­ni­fi­care det­ta­glia­ta­mente la set­ti­mana che viene; dall’altra tendo ad aggiun­gere le cose da fare senza aspet­tare il fine set­ti­mana per deci­dere cosa farne¹.

Dato che l’appetito vien man­giando, mi va già stretto il sem­plice con­teg­gio delle ore lavo­rate durante la set­ti­mana. Vorrei stu­diare qual­che modo per estrarre le infor­ma­zioni sulle atti­vità e farne qual­che con­si­de­ra­zione pseudo-statistica; tanto per vedere l’andamento del tempo dedi­cato ai vari pro­getti. Ma ne par­le­remo più avanti.

Nelle pun­tate precedenti

Per chi si fosse sin­to­niz­zato solo ora:

• L’agenda di Org
• I todo con Org
• Come uso Org
• Cosa manca a Org?
• OmniFocus e Org, pro e contro
• Addio a OmniFocus

Come ho già detto, Org si basa su dei sem­plici file di testo, sud­di­visi con i cri­teri che più ci aggra­dano, ma non ho ancora spie­gato come sia pos­si­bile otte­nere una vista d’insieme di que­sti file¹.

Tutto sott’occhio

Questa vista d’insieme esi­ste ed è la cosid­detta agenda, che rac­co­glie diversi tipi di rias­sunti, in particolare:

• un’agenda vera e pro­pria, che mostra le cose da fare nel periodo di tempo considerato;
• un’elenco dei todo, che mostra tutti i punti in qual­che modo aperti, senza tenere in con­si­de­ra­zione la data;
• una vista fil­tra­bile in base a diversi cri­teri come i tag, lo stato dei todo o anche una ricerca full-text;
• una time­line, sia gene­rale che per un sin­golo file;
• una vista dei pro­getti bloccati;
• infine, non poteva man­care la pos­si­bi­lità di defi­nire delle viste personalizzate.

Non voglio appro­fon­dire tutti que­sti aspetti: sarebbe troppo lungo e forse non molto inte­res­sante; inol­tre non uso – ancora? – delle viste per­so­na­liz­zate, per cui non avrei sug­ge­ri­menti par­ti­co­lari. Mi inte­ressa solo fare qual­che con­fronto con OmniFocus.

Modalità con­te­sto vs l’agenda

Omnifocus usa la moda­lità con­te­sto per pre­sen­tare la lista delle cose da fare². Complice anche la loro imple­men­ta­zione essen­ziale³, i todo pos­sono essere pre­senti solo come da fare o come già fatti.

Dall’altra parte, visto che l’agenda di Org mette a dispo­si­zione delle viste basate su le parole chiave dei todo, diventa sem­pli­cis­simo fil­trare velo­ce­mente e in modo molto pre­ciso le cose che vogliamo vedere.

Risulta anche molto più natu­rale mani­po­lare il loro stato. Un solo esem­pio: con OmniFocus, per essere sicuro di chiu­dere le ultime cose prima di stac­care, facevo in modo che alcune azioni risul­tas­sero dispo­ni­bili solo verso sera. Adesso con Org le fac­cio par­tire quando voglio e le chiudo quando penso sia oppor­tuno, cosa uti­lis­sima in com­bi­na­zione con la regi­stra­zione del tempo dedi­cato a un certo compito.

Altri usi, altri van­taggi dell’agenda

Ci sono altre due situa­zioni in cui l’agenda vince facil­mente il con­fronto con OmniFocus e sono la vista dell’agenda in com­bi­na­zione con le regi­stra­zioni delle atti­vità e l’elenco dei pro­getti bloccati.

Le regi­stra­zioni delle atti­vità per­met­tono di vedere la suc­ces­sione delle varie cose fatte durante il giorno (ma anche per un periodo di tempo più ampio) minuto per minuto. Cosa uti­lis­sima quando devo fare un reso­conto det­ta­gliato della gior­nata⁴.

L’elenco dei pro­getti bloc­cati riguarda tutte quelle voci che non hanno un’azione da com­piere defi­nita. Di default, Org con­si­dera bloc­cati i pro­getti che non hanno almeno una voce clas­si­fi­cata come TODO.

Nel mio caso, ho solo aggiunto qual­che altra clas­si­fi­ca­zione di todo da igno­rare, anche se, dal mio punto di vista, un pro­getto bloc­cato non è solo quello che non è stato pia­ni­fi­cato ma anche quello che è “fermo”, vuoi per­ché in attesa di infor­ma­zioni da qual­cuno, vuoi per­ché non sono riu­scito a por­tarlo avanti.

Forse è pos­si­bile gene­rare un’agenda per­so­na­liz­zata con que­sta infor­ma­zioni; dovrò approfondire.

Nelle pun­tate precedenti

Per chi si fosse sin­to­niz­zato solo ora:

• I todo con Org
• Come uso Org
• Cosa manca a Org?
• OmniFocus e Org, pro e contro
• Addio a OmniFocus

È pas­sato un po’ di tempo dall’ultima volta in cui ho par­lato di Org. Nel frat­tempo, ho com­ple­tato la migra­zione da OmniFocus senza grossi pro­blemi o pentimenti.

I todo

Quando ho intro­dotto Org mi sono dimen­ti­cato di par­lare della gestione dei todo; forse per­ché allora non avevo ancora appro­fon­dito la que­stione. Cercherò di rime­diare ora.

Anche sotto que­sto aspetto, que­ste due appli­ca­zioni sono agli anti­podi: con OmniFocus un task o è da fare o è fatto; con Org, come sem­pre, c’è l’imbarazzo della scelta! Gli stati dei todo non si limi­tano a “da fare / fatto” ma pos­sono essere quanti vogliamo e pos­sono rap­pre­sen­tare sia degli stati che dei cri­teri di classificazione.

Todo come indi­ca­tori di stato

Nel primo caso, usando le parole chiave¹ come indi­ca­tori di stato, è pos­si­bile dei creare dei veri e pro­pri flussi di lavoro, ad es. posso defi­nirne uno come (sequence "TODO" "STARTED" "|" "DONE" "CANCELLED") il cui signi­fi­cato è: gli stati TODO e STARTED sono quelli che neces­si­tano un’azione da parte nostra; DONE e CANCELLED, sepa­rati dal primo gruppo tra­mite la pipe, sono gli stati che indi­cano la chiusura.

Todo come classificatori

Il secondo modo di usare le parole chiave dei todo è come stru­mento di clas­si­fi­ca­zione. Ad es. (type "io" "tu" | "DONE") indica che una certa cosa la puoi fare tu o la posso fare io; un’altro esem­pio che non neces­sita di spie­ga­zioni potrebbe essere: (type "casa" "lavoro" | "DONE").

La pos­si­bi­lità di avere più stati e con un embrione di flusso di lavoro rende molto più sem­plice gestire delle atti­vità che hanno biso­gno di essere por­tate avanti a più riprese durante la gior­nata. Ma per fare avere un pano­rama più com­pleto su que­sto aspetto dovremo par­lare dell’agenda, cosa che faremo prossimamente.

Nelle pun­tate precedenti

Per chi si fosse sin­to­niz­zato solo ora:

• Come uso Org
• Cosa manca a Org?
• Addio a OmniFocus
• OmniFocus e Org, pro e contro

Uno dei test che si fa rara­mente è quello di simu­lare il com­por­ta­mento di un sito o dell’attività di rete sulla WAN, in modo da avere un’idea suf­fi­cien­te­mente pre­cisa di come giri con una con­nes­sione in edge, ad esempio.

In realtà, la cosa non è dif­fi­cile se si è dispo­sti a spor­carsi le mani con il firewall. Per i pigri come me, però, c’è speed­li­mit: un pan­nello delle pre­fe­renze con cui impo­stare i para­me­tri che ci ser­vono, ovvero, per quali porte e per quali host limi­tare la banda ad un certo valore appli­cando anche un ritardo sulla comu­ni­ca­zione a piacere.

Il fun­zio­na­mento di Org ruota intorno a dei sem­plici file di testo, la cui orga­niz­za­zione è com­ple­ta­mente libera: ognuno si costrui­sce il giu­sto mix in base ai pro­pri gusti e alle pro­prie esi­genze. Per ora, il mio sistema è più o meno questo.

Organizzazione dei file

Venendo da OmniFocus ho creato un file .org per quasi ogni pro­getto, tranne che per le cosette di rou­tine che sono riu­nite in un unico file chia­mato main.org. In aggiunta, c’è un file inbox.org che serve per rac­co­gliere velo­ce­mente le cose da fare e che rivedo rego­lar­mente durante la giornata.

All’interno dei file .org

Ognuno di que­sti file, inbox.org escluso, con­tiene almeno due voci di primo livello: INBOX e Main. INBOX serve a sem­pli­fi­care lo smi­sta­mento delle cose da fare dall’inbox.org: quando rivedo que­sto file, ogni voce viene smi­stata al pro­getto di appar­te­nenza e poi apro il file .org del pro­getto per la rifi­ni­tura, piaz­zan­dola al punto desi­de­rato della sezione Main, che rac­co­glie l’outline vera e pro­pria del progetto.

Non sono sod­di­sfatto al 100% di que­sto sistema: è troppo mac­chi­noso. Un modo per snel­lire la pro­ce­dura potrebbe essere quello di eli­mi­nare tout court inbox.org, magari in com­bi­na­zione con l’agenda, che vedremo in seguito.

Nelle pun­tate precedenti

Per chi si fosse sin­to­niz­zato solo ora:

• Cosa manca a Org?
• Addio a OmniFocus
• OmniFocus e Org, pro e contro

Dato che non esi­ste il soft­ware per­fetto è giu­sto anche vedere cosa non va con Org, ed è anche abba­stanza sem­plice: non vi piace Emacs? Odierete Org.

Opzioni, opzioni, opzioni…

Le opzioni sono ster­mi­nate. Mi vien quasi da dire che Org non è un pro­dotto finito, ma solo un semi­la­vo­rato che tocca a noi diroz­zare. Non trovo punto di snodo in cui non sia stata pre­vi­sta un’opzione¹. Questo, però, più che un difetto è una carat­te­ri­stica di fondo. Se la toglies­simo spa­ri­rebbe anche il prodotto.

UX, inte­gra­zione con Mac OS X

Un po’ meno scu­sa­bile – ma sem­pre com­pren­si­bile, visto che si tratta di un major mode di Emacs – è la user expe­rience non certo raf­fi­nata. Inoltre, dato che Emacs gira su un sacco di sistemi ope­ra­tivi diversi, l’integrazione con Mac OS X non è delle migliori anche se è comun­que meglio di quello che ci si aspet­te­rebbe da un’applicazione del genere.

L’inbox

L’unica cosa di cui sento vera­mente la man­canza è la gestione dell’Inbox di Omnifocus. Se siamo in Emacs – e abbiamo con­fi­gu­rato la cosa come si deve – la cat­tura delle cose da fare è per­fetta. Se siamo in altre appli­ca­zioni, però, non abbiamo la pos­si­bi­lità di defi­nire una scor­cia­toia da tastiera uni­ver­sale per spe­dire qual­cosa nell’Inbox, come invece si fa con Omnifocus. Inoltre non ho ancora tro­vato un modo sod­di­sfa­cente di re-indirizzare gli ele­menti dall’Inbox ai pro­getti di competenza.

Se siamo dispo­sti a per­dere un po’ di tempo, pos­siamo otte­nere un risul­tato simile anche con Org ma non è una cosa per tutti. Nemmeno io mi sono ancora deciso a risol­vere il pro­blema ade­gua­ta­mente, figu­ria­moci l’utente “stan­dard”²

E l’iPhone??

L’integrazione con l’iPhone è una que­stione inte­res­sante. Esiste un’applicazione (molto fru­gale) che si sin­cro­nizza attra­verso DropBox ma non è asso­lu­ta­mente para­go­na­bile per fea­tu­res e user expe­rience ad OmniFocus per iPhone/iPad, anche per­ché sul ver­sante desk­top la sin­cro­niz­za­zione non è auto­ma­tica ma va espli­ci­ta­mente invocata.

Tuttavia, OmniFocus ha delle pre­sta­zioni agghiac­cianti, almeno con un iPhone 3G, e la prima cosa che chiedo ad un’applicazione di que­sto tipo è un tempo di rispo­sta rapido, il più rapido pos­si­bile; tutto il resto è secondario.

Se usate l’app come Inbox tem­po­ra­nea, allora vale la pena pro­varla, altri­menti non è un gran­ché. Fino ad ora l’ho usata pochissimo.

Nelle pun­tate precedenti

Per chi si fosse sin­to­niz­zato solo ora:

• Addio a OmniFocus
• OmniFocus e Org, pro e contro