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.

Qualche tempo fa ho sco­perto name­bench, una uti­lity per tro­vare il ser­ver DNS più per­for­mante nella zona in cui siamo in quel momento.

Il suo uso è molto sem­plice, basta lo screenshot:

Quello che all’inizio mi ha sor­preso, però, è vedere il DNS sulla LAN bat­tuto rego­lar­mente da quelli esterni. Credo che il motivo sia dovuto sem­pli­ce­mente a que­stioni di caching: è più pro­ba­bile che i nomi da risol­vere siano già in cache sui ser­ver esterni che su quello interno.

Infatti, se ripe­tiamo i test il diva­rio fra il DNS interno e quello esterno ten­dono a dimi­nuire. Usando come domini da risol­vere quelli nella cache di Safari, otteniamo:

1. 179% più veloce;
2. 90% più veloce;
3. 73%.

Il DNS interno rimane sì il più veloce in ter­mini asso­luti, con ~2ms di miglior rispo­sta con­tro ~ 26ms del DNS esterno migliore ma dall’altra parte il tempo peg­giore di rispo­sta è di ~1,5s per l’interno e ~0,5 per l’esterno, con una distri­bu­zione delle rispo­ste net­ta­mente a favore del ser­ver esterno.

Un DNS interno può rima­nere indi­spen­sa­bile per risol­vere i nomi sulla LAN ma il suo bene­fi­cio come cache può essere impor­tante di quanto si pensi.

Il bello di Emacs è che c’è sem­pre qual­cosa di nuovo da imparare…

Di solito, per moni­to­rare i log e cose del genere uso tail -f ma oggi ho sco­perto che è pos­si­bile fare una cosa simile anche diret­ta­mente da Emacs.

Una volta aperto il file di log basta atti­vare il modo (minore) Auto Revert Tail con M-x auto-revert-tail-mode e il gioco è fatto.

Il fatto

L’altro ieri ero da un poten­ziale cliente e dopo la demo di rito, par­lando del più e del meno, salta fuori che poter col­la­bo­rare con una banca di cui non ha fatto il nome ma sicu­ra­mente ita­liana deve usare, nel suo stu­dio, il loro gestio­nale (o una parte di esso).

Scusa, ho capito bene?

Ogni giorno si parla di sistemi sem­pre più inte­grati, di livelli di astra­zione sem­pre più alti, di stan­dard sem­pre più evo­luti e c’è qual­cuno che è in grado di imporre con­di­zioni del genere?

Dove andremo a finire?

Capisco la que­stione della sicu­rezza e dell’evitare costi ma mi sem­bra la clas­sica ester­na­lità nega­tiva. Alla fine sarà il cliente a doversi sor­bire i doppi rein­se­ri­menti di dati ecc. ecc. Deprimente…

Dove MIA sta per “Missing In Action”, ovvia­mente. Se qual­cuno rie­sce a tro­vare una sin­gola men­zione nella pagina infor­ma­tiva, mi fac­cia sapere.

Perplesso, molto perplesso.

Poco più di un anno fa ho postato uno script per con­tare il numero di righe in un file e non mi ero nem­meno posto il pro­blema di veri­fi­care se fosse un pro­blema già risolto.

Ovviamente è così e anzi ho sco­perto che ci sono diverse pos­si­bi­lità. Prima di tutto esi­ste il comando spe­ci­fico: nl(1); poi pos­siamo usare anche “cat -n nomefile”; infine c’è anche “less -N”. Non escludo che ce ne siano altre, a que­sto punto.

Ho scelto pro­prio una bella ruota da re-inventare!

Ho già can­tato le lodi di Time Machine ma forse avrei dovuto riser­varle per quello che mi è suc­cesso un paio di set­ti­mane fa.

Ho instal­lato un Ubuntu su USB dal mio por­ta­tile. Dato che è una vita che non installo Linux o cose del genere (inciso: anche con Ubuntu non ci siamo ancora; credo che non ci saremo mai a que­sto punto) sono andato in auto­ma­tico: boot da cd, spe­ci­fica il disco di desti­na­zione nell’installer, aspetta che fini­sca e reboot.

Peccato che al riav­vio non sia par­tito pro­prio un bel niente. Credo che l’installazione abbia pastic­ciato con il boot loa­der e quindi mi sono ritro­vato con la mia mac­china inu­ti­liz­za­bile ma con tutti i dati al suo posto (il disco si vedeva rego­lar­mente par­tendo dal DVD Mac OS).

Che fare? Chiamo Time Machine in soc­corso! Una volta par­tito da DVD, ho for­mat­tato il disco e poi ho mon­tato il volume di bac­kup in rete e ho fatto il restore. Ha fun­zio­nato alla perfezione.

Beh, più o meno! Il limite di Time Machine è che lavora sui volumi logici e quindi non poteva ripri­sti­nare la par­ti­zione “rovi­nata” dall’installer di Ubuntu; ecco per­ché ho dovuto rifor­mat­tare il disco. Inoltre il restore in rete è lungo, circa quat­tro ore. Comunque non ci sono state sor­prese, che è la cosa più impor­tante in un restore, se non alcune biz­zar­rie già indi­cate in un post pre­ce­dente.

Nonostante l’avvento dell’IMAP, la migra­zione degli account di posta rimane sem­pre un pro­blema rognoso. Vuoi per la cri­ti­cità dei mes­saggi, vuoi per i vari pezzi del puzzle che devono inca­strarsi, vuoi per i diversi sce­nari che si pos­sono presentare.

In pas­sato usavo diret­ta­mente un client di posta, spo­stando i mes­saggi car­tella per car­tella. Funziona, certo, ma non è repli­ca­bile su larga scala.

Dovendo fare dei test di migra­zione mi sono messo alla ricerca di una qual­che uti­lity uti­liz­za­bile da linea di comando e ho tro­vato imap­sync che ha svolto il suo lavoro egregiamente.

Il fun­zio­na­mento di base è banale: imapsync --host1 h1 --user1 u1 --password1 p1 --host2 h2 --user2 u2 --password2 p2, ma sono coperti anche casi più par­ti­co­lari. È pre­sente anche la moda­lità dry, indi­spen­sa­bile per stru­menti di que­sto tipo.

Non è solo Safari che è arri­vato alla 4 ver­sione, c’è anche la bash!

La mag­gior parte delle novità sono di scarso inte­resse per un uti­liz­za­tore ele­men­tare come me, ma alcune sono comun­que degne di interesse:

• “There is a new ‘map­file’ buil­tin to popu­late an array with lines from given file. The name ‘rea­dar­ray’ is a synonym.”
• “There is a new shell option: ‘glob­star’. When ena­bled, the glob­bing code treats ‘**’ spe­cially — it mat­ches all direc­to­ries (and files within them, when appro­priate) recursively.”
• “There is a new shell option: ‘dir­spell’. When ena­bled, the file­name com­ple­tion code per­forms spel­ling cor­rec­tion on direc­tory names during completion.”
• “There is a new &» redi­rec­tion ope­ra­tor, which appends the stan­dard out­put and stan­dard error to the named file.”
• “The par­ser now under­stands ‘|&’ as a syno­nym for ‘2>&1 |’, which redi­rects the stan­dard error for a com­mand through a pipe.”
• “The shell pro­vi­des asso­cia­tive array varia­bles, with the appro­priate sup­port to create, delete, assign values to, and expand them.”

Fra le appli­ca­zioni che ho segna­lato qual­che tempo fa c’era MacFusion, ovvero un’interfaccia gra­fica per con­fi­gu­rare e usare MacFuse, uno file­sy­stem “user-level”.

Quest’applicazione mi inte­res­sava come sup­porto alle pro­ce­dure di instal­la­zione, per limi­tare al mas­simo l’interazione via shell remota. Volevo capire se era una cosa fat­ti­bile e se ne valeva la pena, anche tenendo conto delle limi­ta­zioni segna­late nelle FAQ.

Per l’uso di MacFusion sono richie­sti Mac OS X 10.5 e MacFuse. Avrei voluto instal­lare quest’ultimo tra­mite MacPorts ma pur­troppo è una ver­sione troppo vec­chia (1.7 con­tro l’attuale, 2.0.x); si tratta comun­que di un’operazione velo­cis­sima, che non richiede nem­meno il riav­vio, per cui anche l’installazione manuale è alla por­tata di chiun­que. Il pac­chetto com­prende, oltre all’estensione del ker­nel e alle varie libre­rie, un comodo pan­nello di controllo:

MacFusion invece con­si­ste solo nell’applicazione e, se lo desi­de­riamo, dell’eventuale icona nella barra dei menu.

A que­sto punto pos­siamo defi­nire i volumi remoti. L’operazione è molto sem­plice e riporto quindi solo gli screen­shot per la con­fi­gu­ra­zione dell’SSHFS, che credo si com­men­tino da soli:

Fin qui abbiamo par­lato dell’uso più stan­dard, quello che copre il 90% dei casi. Ma per essere utile nelle instal­la­zioni biso­gna veri­fi­care se è  pos­si­bile l’uso da linea di comando.

La ver­sione distri­buita sul dmg non con­tiene nes­suno stru­mento per il ter­mi­nale ma è sca­ri­ca­bile dalla repo­si­tory svn. Il link riporta anche le istru­zioni per il suo uso, molto sem­plice; altret­tanto sem­plice diventa la sua inte­gra­zione nelle ope­ra­zioni di deployment.

A que­sto punto abbiamo tutti i pezzi neces­sari e fun­zio­nanti. Vale la pena di usarli nel deploy­ment? A mio parere, dipende dall’approccio alla sicu­rezza che viene usato sul ser­ver di desti­na­zione: se fac­ciamo tutto come root, a par­tire dall’ssh ini­ziale, allora non cam­bia pra­ti­ca­mente nulla; se entriamo come utente “nor­male” e poi usiamo sudo, va ancora peg­gio, per­ché l’uso di sudo è ovvia­mente escluso a priori; infine, se abbiamo impo­stato i pri­vi­legi — magari tra­mite acl — in modo tale che l’utente dell’ssh possa anche por­tare a ter­mine l’installazione senza sudo allora pos­siamo trarne qual­che beneficio.

In quest’ultimo caso, il van­tag­gio prin­ci­pale con­si­ste nell’avere a dispo­si­zione l’intero “arse­nale” della pro­pria mac­china locale per ope­rare sul volume  del ser­ver remoto. Viceversa, il difetto prin­ci­pale è che l’uso dell’SSHFS può non essere una solu­zione com­pleta: se l’installazione pre­vede il riav­vio di un qual­che pro­cesso dovremo comun­que usare l’ssh.

Tuttavia, anche se non ne ho fatto l’uso esteso che pen­savo, mi sono tro­vato più di una volta nella neces­sità di usare MacFusion per veri­fi­che o inter­venti “al volo” e rimane uno stru­mento di grande utilità.