“Non si potrebbe fare…?”

Come se non bastasse il lavoro di rifa­ci­mento, è arri­vata sulla scri­va­nia la richie­sta di una ver­sione che:

1. possa essere usata in assenza di connettività;
2. non richieda alcuna pro­ce­dura d’installazione;
3. sia mul­ti­piat­ta­forma;
4. sia ese­gui­bile diret­ta­mente da una chiave USB.

Insomma, non pro­prio un qual­cosa da fare nei rita­gli di tempo!

Cosa usare?

All’inizio avevo pen­sato ad una qual­che appli­ca­zione in Java, usando Swing o SWT ma non ho pra­ti­ca­mente nes­suna fami­lia­rità con appli­ca­zioni desk­top di quel tipo; inol­tre non è affatto scon­tato che Java sia sem­pre installata.

Sul lato .Net, cono­sco qual­cosa di più ma non ho idea se sia fat­ti­bile uno svi­luppo multipiattaforma.

“The sim­plest thing…”

Poi mi è venuto in mente che avrei potuto rispar­miare un bel po’ di lavoro usando una ver­sione rivi­si­tata di quella su web, con la parte ser­ver che gira diret­ta­mente sul com­pu­ter dell’utente. Fattibilissimo, certo, ma non pro­prio una cosa che non richiede alcuna installazione

Infine, credo di aver tro­vato una solu­zione in Tcl, tra­mite i cosid­detti StarKit e StarPack: un colos­sale (ma leg­ge­ris­simo, in MB) uovo di colombo.

In poche parole, uno StartKit con­sente di impac­chet­tare un’intera appli­ca­zione in una spe­cie di disco imma­gine. Questo disco imma­gine con­tiene anche tutti i file ausi­liari, binari o meno, anche per diverse piattaforme.

Fin qui niente di par­ti­co­lare. In fondo, con l’avvento delle mac­chine vir­tuali è diven­tata prassi comune distri­buire diret­ta­mente dei dischi imma­gine. C’è però da supe­rare l’ostacolo dell’installazione, visto che per ese­guire uno StarKit serve comun­que un inter­prete Tcl più una serie di librerie.

E qui entrano in scena gli StarPack, che accor­pano uno StarKit e l’interprete in unico file, con­fi­gu­rato per par­tire con un dop­pio click. Il peso? Pochi MB!

Nei pros­simi giorni vedremo un po’ più in det­ta­glio come fun­ziona que­sta tecnologia.

Life goes on

Nel frat­tempo, sul fronte del refac­to­ring, ho ter­mi­nato l’accorpamento di tutto l’SQL. Adesso dovremo comin­ciare a tagliare i ponti con le sezioni che si appog­giano a Joomla.

PS · Va pre­ci­sato che con l’arrivo ormai pros­simo dell’HTML 5, diven­terà con­ce­pi­bile pen­sare a solu­zioni che pos­sano girare in com­pleta auto­no­mia, senza alcuna con­nes­sione. Tuttavia, il sup­porto da parte di Explorer è ancora incompleto.

Quando si ha a che fare con un’applicazione già in pro­du­zione, soprat­tutto su web, diventa impor­tante tro­vare il modo più effi­cace per rag­giun­gere i risul­tati desiderati.

Ad esem­pio, nel pro­getto a cui sto lavo­rando, dopo aver deciso alcuni obiet­tivi a medio ter­mine, ho dovuto pia­ni­fi­care la strada per arri­varci. Anzi, ho dovuto rinun­ciare a par­tire subito nella dismis­sione di Joomla per con­cen­trarmi su sull’estrazione di tutti gli sta­te­ment SQL spar­pa­gliati ovunque.

Senza que­sto lavoro pre­pa­ra­to­rio, che è in corso (insieme a tutto il resto, ovvia­mente), rimuo­vere Joomla sarebbe stato sem­pli­ce­mente troppo rischioso.

Oltre a quello, però, c’è anche la neces­sità di riu­scire ad avvi­ci­narsi all’obiettivo un passo alla volta. Perché il pro­blema non è solo quello di mini­miz­zare i rischi ma anche di ade­guare il ritmo dei cam­bia­menti alle esi­genze del progetto.

A pic­coli passi

Il motivo fon­da­men­tale è che quando stiamo riscri­vendo una por­zione di codice siamo, per così dire, vul­ne­ra­bili: se arriva una segna­la­zione di un qual­che mal­fun­zio­na­mento, in un modo o nell’altro, dob­biamo met­tere da parte quello che stiamo facendo e dare un’occhiata al problema.

Più il refac­to­ring che sta­vamo facendo è ampio, più è pro­ba­bile che il sor­gente che stiamo modi­fi­cando possa essere coin­volto nelle altre modi­fi­che la segna­la­zione ci potrà richie­dere. Può capi­tare, certo, ma è sem­pre una buona cosa evi­tarlo, quando pos­si­bile: meno stress, meno incertezze.

Per non rima­nere a metà del guado

Sto impa­rando quindi a “fram­men­tare” i refac­to­ring in modo che non por­tino via più di un paio d’ore al mas­simo. Si tratta di tempi biblici rispetto a quelli descritti nella let­te­ra­tura XP, lo so, ma biso­gna anche tener conto del fatto che in que­sto pro­getto si tratta di inter­venti su un codice estre­ma­mente destrutturato.

I risul­tati comin­ciano a vedersi. Fra qual­che tempo, sarà diver­tente andare a con­fron­tare il codice dell’inizio con quello che verrà fuori da tutto que­sta trafila.

Nel codice che sto riscri­vendo ci sono tante di quelle dupli­ca­zioni e una così scarsa strut­tu­ra­zione che non posso fare a meno di chie­dermi come sia pos­si­bile durante la pro­gram­ma­zione fare scelte evi­den­te­mente deboli – se non com­ple­ta­mente sba­gliate – e con­ti­nuare a farle, ancora e ancora.

È solo per­ché non c’è tempo? Perché “tanto è la stessa cosa”? Per paura di dover ritoc­care del codice?

Under pres­sure

Mi viene il dub­bio che molte volte non serva tanto sapere chissà quanti pat­terns o algo­ritmi ma fare quello che sap­piamo essere la cosa giu­sta. E per que­sto, a volte, ci vuole un po’ di corag­gio e pren­dere quel minimo di tempo neces­sa­rio. Spesso, la ten­ta­zione di pas­sare oltre, di far finta che il pro­blema non esi­sta, di pen­sarci domani è troppo forte, siamo troppo stan­chi o sem­pli­ce­mente non ce ne frega niente ma almeno dovremmo sen­tirci almeno un po’ in colpa!

O forse è più un pro­blema di luci­dità. Sappiamo che qual­cosa non va ma non riu­sciamo a deci­dere come porvi rime­dio. In ogni caso, coin­volge sem­pre l’aspetto psi­co­lo­gico, non di com­pe­tenza tecnica.

Non ho ancora deciso cosa met­tere al posto del php, anzi, vor­rei riman­dare la deci­sione fino a quando non avrò siste­mato il resto.

La lista (una lista?) della spesa

Cos’è “il resto”? Ad esem­pio, vor­rei pas­sare da MySQL a PostgreSQL, da MooTools a YUI; vor­rei eli­mi­nare orrori come l’implementazione della navi­ga­zione tra­mite POST, usando un approc­cio il più pos­si­bile ade­rente a prin­cipi del REST.

Per comin­ciare…

Come prima cosa dob­biamo eli­mi­nare la dipen­denza da Joomla. Per quello che posso capire, l’unica cosa vera­mente usata in Joomla è la parte rela­tiva alla sicu­rezza: gli account sono defi­niti lì ed è stato svi­lup­pato un sistema di auto­riz­za­zione che, in parte, vi si appoggia.

Per quanto riguarda l’autenticazione, la mia inten­zione sarebbe comun­que di pas­sare a DACS, in modo da farla finita con il codice di auten­ti­ca­zione all’interno di un’applicazione e che usa un qual­che database.

Prima di quello, però, il punto più facil­mente attac­ca­bile è quello dell’autorizzazione, che dovrebbe essere reim­ple­men­ta­bile in modo che non usi il data­base. A livello molto sche­ma­tico, dovrebbe bastare che l’utente auten­ti­cato passi il gruppo di appar­te­nenza per vedersi resti­tuiti i suoi privilegi.

Dopo qual­che set­ti­mana pas­sata a spe­gnere incendi, fra poco potrò forse comin­ciare un ridi­se­gno in grande in stile (1, 2). È un’applicazione che mi ha già fatto scri­vere un paio di post, si tratta di una massa informe di MySQL+PHP, che usa Joomla 1.0, con una user expe­rience pros­sima allo zero. L’obiettivo dei pros­simi mesi sarà la sua radi­cale revi­sione, al ter­mine della quale potreb­bero rima­nere solo i dati già salvati.

Mi pia­ce­rebbe quindi docu­men­tare qui le fasi salienti di que­sto cam­mino. È una scom­messa un po’ azzar­data, lo so, per­ché que­ste ripro­get­ta­zioni a volte si per­dono nel nulla o ven­gono sca­val­cate da altre urgenze, soprat­tutto in un sito già in pro­du­zione o più banal­mente non avrò tempo né voglia di tenere il dia­rio in modo puntuale.

Vediamo come va a finire… ;-)

Dato che lavoro pra­ti­ca­mente solo in ambito web mi capita a volte di pen­sare con un po’ d’invidia a chi svi­luppa appli­ca­zioni desk­top, dove ha a dispo­si­zione stru­menti come l’Interface Builder.

“Usa i dati, Luke…”

Stamattina, però, sen­tendo “The MDN show” mi è venuto in mente un post di Luke Wroblesky letto poco tempo prima.

In quel post viene fatto notare come il design su web sia sem­pre più legati a fat­tori quan­ti­ta­tivi (spe­ri­men­tali, quasi) che deri­vano dall’analisi dei dati degli utenti.

According to Gemmell

Viceversa, nel pod­cast, Matt Gemmell dà una serie di con­si­gli – uti­lis­simi, peral­tro – sull’usabilità delle appli­ca­zioni desk­top e mi sono reso conto che non esi­stono stru­menti ana­li­tici come sul web; non che io sap­pia, per­lo­meno. È vero che la situa­zione è diversa, a par­tire dagli ovvi pro­blemi di pri­vacy, ma credo la cosa sarebbe fattibile.

Ad esem­pio, sarebbe uti­lis­simo sapere quali sono le fun­zioni più usate; come ven­gono impo­state le pre­fe­renze e così via. Possibile che non ci abbia mai pen­sato nessuno?

Il grande ppk ha tor­chiato tutti i bro­w­ser basati su WebKit che è riu­scito a tro­vare, per veri­fi­care se sia poi vero che la dif­fu­sione di que­sto motore di ren­de­ring impli­chi neces­sa­ria­mente una mag­giore uniformità.

I risul­tati sono sco­rag­gianti: non ce n’è uno uguale all’altro.

Tanto tempo fa… Un prologo

Qualche anno fa mi ero messo a scri­vere un fra­mework di auten­ti­ca­zione e auto­riz­za­zione per WebObjects. L’obiettivo era quello di creare un sistema inte­grato in cui i prin­ci­pali aspetti della sicu­rezza fos­sero affron­tati e messi in col­le­ga­mento con il DirectToWeb. Fu un mezzo fallimento.

Funzionava, sì, ma era troppo mac­chi­noso da impo­stare e uti­liz­zare. Uno dei motivi fu quello di voler usare un data­base per memo­riz­zare le con­fi­gu­ra­zioni, obbli­gan­domi anche a pre­ve­dere un’interfaccia di gestione per aspetti che è quasi sem­pre pre­fe­ri­bile affron­tare con un buon edi­tor di testo.

Flash for­ward

L’altro ieri mi tro­vavo a met­tere le mani su un’applicazione fatta in Joomla (oh, the hor­ror… Risparmio le impre­ca­zioni per un codice che grida vendetta).

Anche Joomla usa un data­base die­tro le quinte per archi­viare le sue con­fi­gu­ra­zioni e con­sente un approc­cio sem­plice ad alcune delle fun­zioni di CMS ma rende le ope­ra­zioni di sta­ging molto, troppo com­pli­cate: non posso pro­vare una con­fi­gu­ra­zione in locale, fare il com­mit nella repo­si­tory e poi fare il deploy­ment ma devo repli­care le modi­fi­che sul data­base di pro­du­zione; inol­tre non ho nes­sun con­trollo di ver­sione se non facendo il dump delle tabelle.

Anche in WordPress, come segna­lavo qual­che giorno fa, alcune ope­ra­zioni con­cet­tual­mente sem­plici e stan­dard sono più com­pli­cate del previsto.

Un anti-pattern?

A que­sto punto, comin­cio a sospet­tare seria­mente che que­sta solu­zione sia in realtà un anti-pattern bello e buono; forse dovremmo essere un po’ più par­si­mo­niosi nell’uso dei database.

Questa inter­vi­sta ad Avy Briant è da vedere. Avevo sen­tito par­lare di lui qual­che anno fa a pro­po­sito di DabbleDB (una spe­cie di FileMaker online, molto ben fatto).

Non di solo SmallTalk vive l’uomo

La cosa che mi aveva incu­rio­sito, durante l’intervista di qual­che anno, fa era che Briant aveva scelto SmallTalk per il bac­kend, ovvero SeaSide. E que­sto, in un momento in cui si sen­tiva par­lare di Ruby on Rails e pra­ti­ca­mente chiun­que, per un pro­getto da zero avrebbe usato quello.

A quel tempo ho pen­sato che fosse una cosa degna di nota, certo, ma che potesse essere il clas­sico caso di uno che aveva voluto dimo­strare di poter usare un lin­guag­gio ormai piut­to­sto eso­te­rico (anche se tenuto in altis­sima con­si­de­ra­zione dai con­nois­seurs).

La cas­setta degli attrezzi

Poi ho visto l’intervista su InfoQ e ho capito che mi sono com­ple­ta­mente sba­gliato. Ad un certo punto dell’intervista, durante la spie­ga­zione del pro­cesso per creare Trendly, Briant spiega che si è ispi­rato dalla visua­liz­za­zione della sto­ria degli ascolti in last.fm e per arri­vare a una ver­sione sod­di­sfa­cente ha scritto il codice per la sua appli­ca­zione almeno sei volte. E sem­pre per motivi diversi, tutti validi.

La morale della storia

Ci sono un paio di punti che fanno riflet­tere, a parte la per­se­ve­ranza nel con­se­guire il risul­tato:  1) rifare da zero, senza paura; 2) saper vedere i vicoli cie­chi e cam­biare strada radi­cal­mente, se necessario.

Non è una cosa sem­plice e spesso non siamo cambi così radi­cali sono asso­lu­ta­mente impro­po­ni­bili. Ma ci invita a guar­dare con ulte­riore atten­zione alle virtù della riscrit­tura radi­cale e a pro­vare a dimen­ti­care la ricerca del lin­guag­gio definitivo.

Durante la svi­luppo, si lavora di un sito situato ad un altro indi­rizzo rispetto a quello uffi­ciale, per ovvi motivi che non sto qui nean­che a spiegare.

Questo modo di lavo­rare è più dif­fi­cile con WordPress per­ché le infor­ma­zioni rela­tive all’URL del sito sono con­ser­vate nel data­base e quindi fuori dal con­trollo degli stru­menti di sviluppo.

Dopo molte ricer­che infrut­tuose mi sono imbat­tuto in que­sto post, che spiega il trucco: biso­gna defi­nire le varia­bili WP_SITEURL e WP_HOME in wp-config.php. Anche gli altri con­si­gli — che già seguivo — sono degni di nota e sono di appli­ca­zione più generale.