Antonio Cosentino

Chi come me si occupa di sviluppo web saprà per certo che qualsiasi progetto, per quanto semplice, è composto da un abbondante numero di compiti, o tasks per dirla all’inglese, che vanno completati per raggiungere il nostro obiettivo.

Suddividere un progetto in task è utile per diversi motivi: oltre ad aiutarci a non tralasciare niente, infatti, serve anche a ridurre lo stress derivante dalla visione del progetto nell’insieme, specialmente quando si è all’inizio. Il frazionamento in tanti task ci aiuta a concentrarci sul singolo aspetto su cui stiamo lavorando senza percepire il peso del progetto e allo stesso tempo procedere con sicurezza fino al completamento dello stesso. Penso che molti saranno d’accordo con me sul fatto che “depennare” un compito da una lista sia appagante da un punto di vista psicologico e può aiutarci a mantenere alta la motivazione perché ci fa percepire i progressi che stiamo facendo.

A proposito di “depennare”: per anni la mia to-do list è stata gestita nel modo più classico possibile: carta e penna o, per un breve periodo, una lavagna. Questa soluzione però non era granchè  e spesso mi è capitato addirittura di perdere alcuni appunti o comunque in generale di trovarmi sommerso dal disordine… Così ho deciso, un paio di anni fa, di passare ad una soluzione più professionale.

La mia prima scelta cade su Things, applicazione per MacOs prodotta dalla Cultured Code, una software house tedesca.

Il costo dell’applicazione per Mac non è proprio bassissimo, al momento costa € 39,99 (e se non ricordo male al tempo costava anche di più), però il prodotto è davvero ben fatto e le opinioni raccolte sono ottime, così decido di procedere. Things ha anche un’applicazione per iPhone (€ 7,99) e dopo qualche mese, era il 2010, esce anche l’applicazione per iPad (€ 15,99). Naturalmente ho scaricato anche queste app, anche se i prezzi erano decisamente alti rispetto allo standard. Per più di un anno gestisco il mio lavoro con Things e tutto sommato mi trovo bene. L’unica cosa che proprio non mi piace è che il sync tra i dispositivi (Mac, iPhone e iPad) si può fare solo via Wi-fi. Questo per me è un grosso limite perché non mi ricordavo mai di fare il sync e spesso mi sono ritrovato fuori dall’ufficio con i task non sincronizzati sui miei dispositivi mobile. Leggo però sul loro blog che stanno lavorando per un “sync over the air” e quindi decido di dargli fiducia e attendere che questa feature venga rilasciata.

Purtroppo però questo non succede, anche dopo diversi mesi. Per la cronaca, la prima volta che parlarono di questa funzionalità era a metà del 2010 e la public beta è stata rilasciata solo a Febbraio del 2012, quindi sostanzialmente ci sono stati quasi due anni di sviluppo e ancora non c’è stato un rilascio ufficiale. Le motivazioni di tutta questa attesa, fornite attraverso il blog, sembrano (a mio avviso, ma non solo) piuttosto assurde, soprattutto visto e considerato che loro una soluzione di sync la offrono già e si tratta solo di farla diventare cloud.

In tutto questo tempo la mia pazienza si esaurisce e così, a Luglio del 2011, decido di abbandonare definitivamente Things e passare a Wunderlist.

Wunderlist, neanche a farlo apposta, è sviluppato anch’esso da una software house tedesca, la 6Wunderkinder. La prima cosa che mi stupisce è il costo: il software è FREE su tutte le piattaforme (Mac, iPhone e iPad). Non male, considerando che per avere una situazione simile con Things avevo dovuto spendere circa € 65,00.

Inoltre l’applicazione sembra ben curata, sia nel design che nelle funzionalità e, a differenza di Things, esiste una web app, quindi è possibile consultare i task attraverso il browser. Le informazioni, essendo sincronizzate con un server web, sono aggiornate in real time su tutti i dispositivi. Pur non essendo sicuramente al livello di Things, che in quanto a cura dei dettagli resta secondo me imbattibile, decido che queste funzionalità per me valgono il cambio di software e così per diversi mesi porto a termine i miei task con Wunderlist.

Dopo alcuni mesi (Gennaio 2012) la 6Wunderkinder, la società berlinese che produce Wunderlist, annuncia un nuovo prodotto chiamato Wunderkit. Sostanzialmente si tratta di una versione “potenziata” di Wunderlist, tant’è che inizialmente trovo bizzarra la scelta di mantenere entrambi i prodotti. L’idea è però quella di rilasciare Wunderkit come servizio a pagamento, quindi da questo punto di vista la scelta potrebbe avere un senso.

Le differenze fondamentali sono le seguenti:

• Wunderkit è una app collaborativa. Non serve quindi solo a gestire i task di una singola persona ma è pensata per i team, con tanto di possibilità di assegnare i task ad altri componenti del nostro gruppo di lavoro, condividere con loro note, aggiornamenti di stato ecc.
• L’app presente molti aspetti social: è possibile seguire utenti, seguire dei workspaces (che possono essere pubblici o privati), commentare ecc.
• Essendo stato introdotto il concetto di workspaces (che possono essere intesi come i vari progetti) esiste un livello ulteriore di suddivisione dei task.
  Ad esempio nel progetto Sito Abc posso suddividere i miei task in varie categorie, as esempio layout, back-end, front-end e seo ottenendo quindi una maggiore organizzazione.

Dato che queste nuove funzionalità coincidono con alcune mie esigenze e che dispongo di un invito alla versione beta decido di provare Wunderkit. Purtroppo non c’è la possibilità di migrare i task da Wunderlist a Wunderkit (trattandosi di prodotti provenienti dalla stessa software house mi sarei aspettato una funzionalità di questo tipo) quindi faccio un lavoro manuale di re-inserimento dei task nel nuovo software.

Dopo l’entusiasmo iniziale comincio ad evidenziare alcuni problemi:

• L’applicazione per Mac non è una vera e propria app, ma quello in gergo si chiama wrapper, ovvero un “contenitore” della web app. Il che non sarebbe comunque male, se non fosse per i numerosi bug, e qui passo al punto 2.
• Ci sono davvero troppi bug. È vero, stiamo parlando di un software in versione BETA, ma a volte si verificano delle cose molto spiacevoli: workspaces che spariscono (fortunatamente solo temporaneamente), note che spariscono, necessità di riavviare l’app e addirittura l’impossibilità di avviare l’app. Spesso questi problemi sono dovuti a problemi del server e lo staff di 6Wunderkinder è molto reattivo nel rispondere e nel comunicare via Twitter eventuali malfunzionamenti. Rimane comunque il problema che a volte ci è sembrato di perdere irrimediabilmente i nostri task e questa non è mai una sensazione piacevole.
• Nonostante la cura nel design, a mio avviso c’è qualcosa di sbagliato proprio nel modo in cui è stata progettata l’interfaccia. In questo tipo di applicazioni la cosa più importante è il “focus” ovvero la possibilità di concentrarsi su un task in particolare e dimenticarsi di tutto il resto, eliminando quindi le distrazioni. L’interfaccia di Wunderkit invece non sembra focalizzata sui task ma sui vari aspetti social e più volte ho avuto la sensazione di non capire dove mi trovavo. Altre volte mi è capitato di scrivere un aggiornamento di stato pensando di scrivere un task. Inoltre la gestione dei contenuti pubblici e privati non è chiarissima e più di una volta mi è rimasto il dubbio su cosa fosse pubblico e cosa fosse privato.
• Pur esistendo una versione nativa per iPhone (davvero ottima) non esiste al momento una versione nativa per iPad.

Procedo comunque con Wunderkit, che nel frattempo annuncia, a metà Febbraio, che il prodotto sarà reso free per tutti, a differenza di quanto previsto in partenza.

Poi un giorno mi imbatto in questo ottimo articolo scritto da Ryan Carson, il fondatore e CEO di Treehouse. L’articolo fondamentalmente parla di come lui gestisce la propria giornata ed è una vera e propria fonte di ispirazione. Alcune cose sono per me assolutamente impensabili (ad esempio la sveglia alle 4:54 AM) mentre rimango molto incuriosito dal software da lui utilizzato per la gestione dei todos: Asana.

Dopo aver visitato il sito ufficiale www.asana.com scopro subito una cosa interessante: dietro ad Asana c’è Dustin Moskovitz che, come saprà chi conosce un po’ la storia di Facebook, (ma anche chi ha semplicemente visto il film “The social network”) è uno dei co-fondatori di Facebook, probabilmente il più influente da un punto di vista tecnico. Moskovitz non fa più parte del team di Facebook da alcuni anni e questa è la sua nuova creatura, uno strumento che ha l’obiettivo di semplificare il task management per i team.

Asana mi conquista subito. Anche in questo caso, come in Wunderkit, il punto centrale è la web app. La cosa però che balza subito all’occhio è come l’interfaccia, estremamente minimale, sia pensata in modo che i task siano al centro di tutto. La modalità di immissione dei task è la cosa che più mi piace: attraverso le combinazioni di tastiera (che sono riassunte anche nella parte bassa dell’interfaccia) è possibile fare tutto quello che ci serve, senza dover utilizzare il mouse. Sembrerà banale ma questo è un vantaggio enorme in termini di velocità di utilizzo. 

Ecco brevemente le altre funzionalità:

• Possibilità di contrassegnare un task come today, upcoming o later
• Possibilità di assegnare un task a se stessi oppure ad un compagno di team (ovvero un’altra persona che è stata inclusa nel progetto)
• Tags: questa è una delle funzionalità più interessanti. Possiamo creare dei tag personalizzati e poi assegnarli ai task. Il grosso vantaggio è che un singolo task può avere più tag. Inoltre i tag possono essere pubblici (quindi visti anche dai nostri compagni di team) oppure privati (visti soltanto da noi)
• Possibilità di modificare più task contemporaneamente. Questa è una funzionalità ottima che non ho mai trovato nei software provati in precedenza.
• Possibilità di ordinare i task in base a priorità.
• Schermata My Tasks:questo è esattamente quello che intendevo quando parlavo di focus. Qui vediamo solo i task che abbiamo contrassegnato come today o come upcoming. In questo modo non siamo costretti a visualizzare la valanga di task che ci aspettano e possiamo concentrarci sul lavoro che dobbiamo svolgere oggi.
• Email quotidiana riassuntiva dei task da svolgere oggi. Purtroppo non è possibile scegliere l’ora dell’invio della mail e la mail viene inviata per quella che è la mattina presto nella west coast americana, ma è già quasi pomeriggio per noi. È probabile comunque che questa funzionalità verrà introdotta in seguito.

Personalmente mi sento di raccomandare Asana, oltre che per i motivi sopra elencati, per questi motivi:

• Non ho riscontrato alcun malfunzionamento o bug, fin’ora tutto ha funzionato alla perfezione.
• Il team di sviluppo è molto veloce nel rilasciare nuove feature e ho potuto personalmente riscontrare l’introduzione di nuove funzionalità, che trattandosi di una web app sono comparse automaticamente.
• Citando una frase dal post di Ryan Carson: la società che sta dietro ad Asana ha recentemente ricevuto un finanziamento di circa 9 milioni di dollari. C’è da credere quindi che non si tratti di un servizio che potrebbe chiudere da un momento all’altro e questo dovrebbe darci un’ulteriore sicurezza nel riporre lì le nostre informazioni.

Concludo questo post con l’ottimo video di introduzione ad Asana, buona visione!

Alcuni giorni fa mi sono ritrovato, per un progetto sul quale sto lavorando, ad avere la seguente esigenza: assicurarmi che l’utente, utilizzatore di alcune funzionalità di una webapp, abbia Javascript abilitato.

Perchè un utente dovrebbe aver disabilitato Javascript?
Bella domanda. Effettivamentedisabilitarlo non porta nessuna utilità, anzi, rende buona parte del web inutilizzabile. Insomma, non è come disabilitare Flash, lì ci sono diversi vantaggi (performance del browser tanto per dirne uno) ma qui sinceramente non ne vedo.
Detto questo, il fatto che sia poco sensato non significa che un utente non possa farlo. Disabilitare Javascript è una cosa che chiunque può fare e se il nostro sistema non prevede questa eventualità potrebbero esserci dei risultati inaspettati.

Come quasi sempre accade quando mi trovo di fronte a questi dilemmi, cerco sul web e vado a caccia di informazioni. Leggendo nei vari forum e siti specializzati vedo che gli approcci a questo tipo di problema sono i seguenti:

Utilizzare il tag noscript
Tutto quello che noi scriviamo all’interno di noscript viene mostrato solo agli utenti con Javascript disabilitato, gli altri non vedono nulla.

VANTAGGI
Nessun accorgimento particolare da parte nostra: il tag noscript è supportato praticamente da sempre in tutti i browser.

SVANTAGGI
Questa soluzione è ottima per chi vuole mostrare un avviso a chi non ha Javascript. Non va invece bene per chi vuole impedire a chi non ha Javascript di eseguire determinate azioni e visualizzare alcuni contenuti.

Rilevare il browser dell’utente con uno script server side
Rilevando il browser utilizzato possiamo capire se è un browser che supporta Javascript oppure no ed eseguiredel codice in base a questa informazione.

VANTAGGI
È una soluzione relativamente semplice da implementare.

SVANTAGGI
Questo risolve il nostro problema solo in parte: in questo modo possiamo infatti capire se la versione del browser supporta Javascript (quindi fondamentalmente se non è un browser obsoleto) ma non se Javascript è attivo.

Strutturare la nostra webapp in modo che Javascript non sia essenziale
Questa è sicuramente la soluzione migliore ed è quella suggerita dai “perfezionisti”. Se strutturiamola nostra webapp in modo che Javascript serva solo a migliorare la funzionalità ma non sia determinante, possiamo realizzare un prodotto solido e compatibile con tutti. Questa è ad esempio la soluzione che adotta Facebook: se provate ad entrare senza Javascript troverete molte cose diverse (una di quelle che salta all’occhio è il pulsante “invia” sui commenti, che di solito non c’è). Tuttavia la funzionalità globale è inattaccata. Insomma, è tutto meno bello, ma comunque funziona.

VANTAGGI
È la soluzione più sicura e possiamo utilizzare degli script lato server come “backup” nel caso gli script lato client (Javascript appunto) non funzionino.

SVANTAGGI
Non sempre è possibile: se la nostra webapp è fortemente incentrata su Javascript è probabilmente meglio impedire l’utilizzo a chi non ha Javascript piuttosto che fornire una funzionalità zoppicante. Inoltre questa soluzione richiede molto lavoro in più. Si pensi ad esempio ad uno script di validazione di un form: dovremmo fare in modo che ad ogni validazione effettuata con Javascript corrisponda anche una validazione fatta con PHP (o ASP ecc.) nel caso la validazione con Javascript non funzionasse.

La mia soluzione
Dopo aver analizzato le possibilità ho deciso di procedere con una soluzione differente realizzando un mio script. L’approccio dello script è il seguente:

• Utilizzare Javascript per creare qualcosa che sia rilevabile lato server
• Utilizzare PHP per verificare la presenza di questo elemento. Se non è presente significa che Javascript non è stato in grado di generarlo e quindi che presumibilmente è disabilitato

Dopo aver riflettuto su cosa potessi creare con Javascript che potesse essere rilevato lato server ho pensato a queste due soluzioni:

• Creare un cookie con Javascript e poi utilizzare PHP per verificarne la presenza.

• Modificare il valore di un campo hidden in un form e verificare con PHP se questo valore corrisponde.

Dato che nel mio caso specifico avrei fatto questa verifica dopo l’invio di un form, ho deciso di utilizzare la seconda soluzione.

Come funziona?
All’interno del form ho aggiunto un campo hidden in questo modo:

Ora ci serviremo di jQuery per modificare il valore di questo campo.

Prima di tutto includiamo jQuery:

Dopodichè utilizziamo jQuery per scrivere il valore “yes” all’interno del nostro campo hidden:

In questo modo avremo, nella pagina di destinazione del form, una variabile POST chiamata “jscheck” che conterrà il valore “yes” solo se Javascript è stato in grado di scrivere questo valore prima dell’invio.

A questo punto possiamo eseguire del codice diverso a seconda dei due casi (Javascript attivato e Javascript disattivato).

Ecco un esempio in PHP:

Per chi volesse vedere e scaricare una versione completa e funzionante dello script, ho creato una versione liberamente scaricabile chiamata Jscheck. Ecco i link utili:

• Live Demo
• Download dello script (Github)

Questo post si riallaccia ad un mio post di qualche mese fa, in cui spiegavo come ero riuscito ad inserire alcune stazioni radio italiane su iTunes e linkavo un ottimo sito che spiegava la procedura da seguire.

Quel sistema per me ha funzionato benissimo fino a ieri, poi stamattina improvvisamente la sorpresa: un messaggio di errore mi informava che non era possibile riprodurre il file e che quindi non potevo più ascoltare Radio Deejay all’interno di iTunes. Molto probabilmente il tutto è stato causato da un aggiornamento di Mac Os X Lion scaricato stanotte.

Ho deciso così di trovare un’altra soluzione e dopo un po’ di test vari sono riuscito a far funzionare di nuovo tutto. Di seguito descriverò la procedura che ho seguito, dato che molto probabilmente tornerà utile a qualcuno. A conti fatti credo che questi step siano anche più semplici di quelli da seguire col sistema “vecchio” e soprattutto questa volta non c’è nessun file da scaricare.

Cercherò di spiegare il tutto nel modo più semplice possibile, utilizzando anche con un po’ di screenshots.

Pronti? Si parte!

La prima cosa da fare è creare una nuova Playlist di iTunes.

In basso a sinistra nell’interfaccia di iTunes sono visualizzate tutte le Playlist già presenti.

Non dobbiamo fare altro che cliccare  sul pulsante “+” che serve appunto per creare una nuova Playlist. Dopo averla creata possiamo rinominarla a nostro piacimento, io l’ho chiamata Radio Deejay:

Adesso bisogna andare nell’elenco delle stazioni radio di iTunes, che è nella parte superiore della sidebar di sinistra. Clicchiamo su Radio e ci si aprirà un elenco di generi musicali che, a loro volta, contengono tutte le stazioni radio.

Scegliamo un genere musicale, apriamolo e scegliamo una stazione radio casuale. Sì, avete capito bene, potete sceglierne una qualsiasi e tra poco capirete perchè.

Io ho scelto di utilizzare JAZZRADIO.com che tra l’altro è una stazione niente male.

Ora viene la parte divertente: dopo aver scelto la stazione radio dobbiamo semplicemente trascinarla sopra alla playlist che abbiamo creato poco fa (nel mio caso la Playlist Radio Deejay). In questo modo abbiamo inserito questa stazione radio nella nostra Playlist.

Adesso torniamo a selezionare la nostra Playlist e dovremmo trovare al suo interno la stazione che abbiamo scelto. Facciamo tasto destro (o ctrl+click) sul nome della stazione e clicchiamo su Informazioni.

Al nostro click si aprirà una schermata simile alla seguente:

Qui dobbiamo cliccare su Modifica URL e otteremmo una schermata con dentro un lungo indirizzo web. Dobbiamo semplicemente copia/incollare al posto di quell’indirizzo il seguente:

http://mp3.kataweb.it:8000/RadioDeejay

Il risultato quindi deve essere questo:

Ora clicchiamo OK sia su questa finestra che su quella aperta in precedenza e facciamo Play sulla nostra stazione radio. Partirà Radio Deejay e automaticamente il nome della stazione radio si aggionerà.

Ora potete godervi nuovamente la vostra radio preferita su iTunes :)

Alcuni dettagli: questa procedura è stata testata con Mac Os X Lion 10.7.3 e iTunes 10.5.3. ma credo che funzioni senza problemi anche con altre versioni.

Se volete darmi del feedback su questa procedura potete farlo su Twitter, il mio username è @ilkose 

Diverso tempo fa un cliente mi ha chiesto di implementare, se possibile, la seguente funzionalità: mostrare gli ultimi feedback eBay ricevuti, in un box all’interno del proprio sito. Fino a quel momento era presente un link che rimandava alla pagina originale dei feedback su eBay, ma si voleva saltare questo step e mostrare direttamente i commenti. La cosa naturalmente doveva avvenire in modo automatico, niente copia/incolla per capirci.

Pensando che una cosa del genere fosse già prevista, vado alla ricerca di un widget o qualcosa del genere, più o meno come fanno Twitter o Facebook, tanto per citarne due. Scopro invece, con una certa sorpresa, che eBay non prevede nulla di tutto questo. Non solo non offre widgets per i feedback, ma non esiste neanche un feed RSS per estrarre queste informazioni in modo “pulito”.

Parte quindi la mia consueta ricerca per il web, per vedere se qualche sito o servizio esterno ha la soluzione che fa per me. Purtroppo però non trovo niente di interessante. Esistono diverse soluzioni per mostrare le inserzioni ma, a quanto pare, dei feedback non si è occupato nessuno. In realtà a dire la verità qualcuno se n’è occupato (loro) ma quello che viene mostrato è solo il numero di feedback, mentre a me serve la lista dei commenti.

Alla fine decido di fare da me e di sviluppare lo script in PHP. In qualche ora ottengo il risultato desiderato, metto online e la missione è compiuta.

Nei mesi successivi diverse persone mi chiedono come possono fare a ricreare qualcosa del genere. Mi rendo conto quindi che tutto sommato questa esigenza non era così strana e che in molti hanno bisogno di un box come quello. 

Da qui quindi la decisione di ottimizzare lo script in modo che sia personalizzabile e di rilasciarlo gratuitamente con licenza open source. A questo punto serve solo un nome: decido di chiamarlo Feedbackbox (sì lo so, non ho esagerato con la fantasia) e per condividere il codice sorgente decido di utilizzare l’ottimo GitHub.

Per chi volesse utilizzare Feedbackbox ecco i due link fondamentali:

• Live Demo
• Download (GitHub)

 <? 
 include "feedbackbox.php"; 
 feedbackbox("kultmedia", "10"); 
 ?> 

Nell’esempio riportato qua sopra kultmedia non è altro che lo username eBay, mentre 10 è il numero di commenti mostrati, che possiamo modificare a piacimento.

Lo script permette inoltre una completa personalizzazione dell’output, attraverso CSS.

Ecco le classi modificabili:

ul.feedbackboxlist  (elenco dei commenti)

ul.feedbackboxlist li (singolo commento)

ul.feedbackboxlist li a.username (nome utente / link)

ul.feedbackboxlist li span.text (testo del commento)

Nel file example.php incluso nello zip scaricabile da GitHub troverete comunque un esempio già funzionante che potrete prendere come riferimento.

Qualche giorno fa mi sono ritrovato di fronte alla seguente esigenza: cercare un mio tweet risalente ad agosto del 2011. Per la precisione si trattava di un tweet inviato di fronte alla sede di Twitter, nella splendida San Francisco. Recitava “Tweeting from Twitter”, una cosa molto inception ora che ci penso. “Facile”, ho pensato, “sono passati solo 4 mesi, lo troverò in un attimo”. 

Come sempre, la prima soluzione che adotto è quella ufficiale, in questo caso Twitter advanced search. Trovo però subito due ostacoli: 

• Nei vari parametri di ricerca non c’è modo di specificare un range di date
• Anche cercando per parole chiave, la ricerca sembra andare indietro solo di poche settimane, quindi non abbastanza per il mio obiettivo

Probabilmente questa, più che una falla, è una scelta fatta per limitare il carico sui loro server e posso capirne le motivazioni.

Decido quindi di trovare un’alternativa: le API di Twitter sono tra le più aperte in assoluto, quindi sono abbastanza fiducioso nel trovare un servizio che mi permetterá di raggiungere il mio scopo.

Dopo aver dato un’occhiata ai miei bookmarks su Pinboard mi viene in mente che in realtà avevo già fatto qualcosa del genere utilizzando il servizio Searchtweetsbydate. Peccato però che nel frattempo il servizio è stato chiuso e non trovo neanche spiegazioni sul motivo, dato che il dominio risulta del tutto abbandonato. Stessa identica sorte anche per Searchtastic.

Proseguo la ricerca e vedo che molti parlano di Topsy. Gli dò una possibilità ma vedo che la ricerca si comporta piuttosto male e trova dei Tweet con una logica che non ho ben capito ma che mi dà l’impressione di essere casuale.

Teoricamente a questo punto mi sarei dovuto arrendere, se non fosse che ormai è diventata una questione di principio e che non mi interessa neanche più tanto trovare quel tweet specifico (nel frattempo ho anche dimenticato perchè mi serviva…) ma capire com’è possibile che io non possa avere un archivio facilmente consultabile dei miei tweet. Sono miei d’altronde, per la maggior parte sono cose poco interessanti, ma sono i miei tweet… :)

La ricerca così continua e mi imbatto in due soluzioni a pagamento (o quasi):

Twistory

L’idea è interessante: sostanzialmente permette di effettuare un’integrazione tra i tweet e il proprio calendario. Attraverso questo servizio, quindi, un utente può avere i propri tweet all’interno di iCal (o simili) in modo ordinato. Non male, però la versione gratuita permette di andare indietro nel tempo solo di un mese. La versione a pagamento teoricamente non ha limiti (in realtà c’è un limite anche qui di 3200 tweet ma pare che questo sia imposto dalle API di Twitter).

Backup my tweets

Permette di archiviare i propri tweet per avere una consultazione più rapida e funzionale. Il servizio è a pagamento, ma il pagamento è barattabile con un tweet promozionale che viene inviato direttamente dal servizio dopo aver fatto il login via Twitter (attraverso OAuth).

Queste due opzioni sono piuttosto abbordabili (anche perchè i costi sono minimi), ma rimango dell’idea che per questo tipo di servizio ci deve essere una soluzione gratuita.

E così, analogamente a quanto successo quando dovevo realizzare il mio url shortener, decido di cercare una soluzione self-hosted e faccio una ricerca sul buon vecchio GitHub.

Qui mi imbatto in Tweet Nest, una app PHP che promette subito bene e con un ottimo sito di presentazione.

Scarico quindi la sorgente e installo sul mio server. L’installazione è molto semplice, gli step fondamentali sono i seguenti:

• Creare un database (nel mio caso MySql ma l’app supporta praticamente tutti i tipi di database)
• Uploadare i file via FTP
• Modificare i permessi di alcuni file in modo che abbiano l’accesso in scrittura
• Creare dei file htaccess che serviranno perchè possa funzionare il mod_rewrite e per la protezione di alcune cartelle
• Lanciare la pagina di setup che, passo dopo passo, ci porterá alla fine dell’installazione

Finita l’installazione rimane solo una cosa da fare: lanciare le pagine di aggiornamento che permettono all’app di sincronizzare i tweet e i dettagli dell’utente. Queste pagine sono, per motivi di sicurezza, protette da password (che abbiamo impostato in fase di installazione).

Questa sincronizzazione sarebbe da eseguire periodicamente e per ottenere questo risultato possiamo anche impostare un Crontab con una frequenza da noi stabilita, in modo da non doversi più preoccupare delle pagine di aggiornamento.

Il risultato è davvero ottimo: l’interfaccia è semplice e ben fatta, con qualche richiamo allo stile grafico di Twitter. Sulla colonna di destra è visualizzato l’archivio mensile e la ricerca ci permette di trovare i nostri tweet alla velocità della luce. Inoltre, volendo, è anche possibile personalizzare l’aspetto grafico nei minimi dettagli. Trattandosi di una soluzione self-hosted, tutte le informazioni sono memorizzate nel nostro database e questo è un vantaggio non indifferente.

In conclusione, ecco la pagina del mio archivio di tweets. Ho scelto di renderla pubblica ma volendo è anche possibile proteggerla da password, trattandosi di uno script interamente open source.

Dato che il titolo del post potrebbe lasciare spazio a strane interpretazioni, chiarisco subito: non sto pensando di mollare tutto per trasferirmi in un’isoletta nei Caraibi… :)

Parlo invece dell’omonima azienda italiana di Web Hosting, come penso si potesse dedurre, considerando il tipo di contenuti di questo blog.

Faccio anche un’altra premessa: questo post non ha intenti diffamatori, voglio solo raccontare una mia recente esperienza, che purtroppo è piuttosto negativa. Tutto quello che sto per raccontare è dimostrabile, lo dico nel caso qualche rappresentante dell’azienda dovesse passare da queste parti (anche se ne dubito) e fare il “permaloso”.

Bene, detto questo possiamo cominciare, anche perché avevo promesso di diventare più sintetico.

Partiamo dal 2003 (alla faccia della sintesi). Io ero un aspirante Web Designer e cominciavo a fare i primi esperimenti sul Web. Fino a quel momento, quando dovevo pubblicare qualcosa online, mi affidavo a quei servizi di hosting gratuito che ti permettevano di avere un po’ di spazio web in cambio di qualche banner pubblicitario. C’erano ad esempio Altervista, Digilander e altri di cui adesso non ricordo il nome.

Un giorno però arriva inevitabilmente il momento in cui ho bisogno di un dominio vero e di un hosting e così, basandomi sul “fattore popolarità”, mi ritrovo ad acquistare il primo dominio + hosting su Aruba.

A parte le procedure d’ordine un po’ complesse e a volte illogiche (come ad esempio l’illusione di poterti scegliere uno username e password personali, quando poi in realtà dovrai per sempre utilizzare un lunghissimo username numerico e una password impossibile da ricordare) il servizio non mi sembra male e quindi decido che quello sarà il mio hosting di riferimento.

Da quel giorno ho portato circa una trentina di miei clienti su Aruba. Non sono tantissimi, certo, però facendo un rapido calcolo sono circa € 1200 (facendo una media di 40 euro a servizio) che Aruba fattura annualmente grazie a me e al fatto che i miei clienti si sono affidati a me per la scelta dell’hosting. Tutto questo senza che io ci guadagnassi niente dato che Aruba non offre un programma di affiliazione per chi rivende i loro servizi.

In linea di massima tutto funzionava, più o meno bene, quindi il mio riferimento è rimasto invariato per diversi anni.

Col tempo però il mio livello di soddisfazione scendeva gradualmente. Un po’ perché aumentavano le mie esigenze (i progetti web su cui lavoravo cominciavano ad avere dei volumi di traffico grandi e io avevo bisogno di strutture tecniche differenti) e un po’ perché, secondo il mio modestissimo parere, il loro servizio col tempo è peggiorato in vari aspetti. Inutile che io vi ricordi degli outage recenti, di cui uno abbastanza clamoroso, in cui sono stati coinvolti migliaia di utenti.

Pian piano quindi ho cominciato a spostare un po’ di siti altrove e a registrare i nuovi domini e servizi presso altre società, di cui non farò il nome altrimenti questo post potrebbe sembrare promozionale (ma se proprio volete saperlo contattatemi in privato).

Ed è proprio mentre stavo facendo una di queste operazioni di spostamento che mi è capitata questa vicenda assurda che voglio condividere con voi.

Ecco lo scenario:

dominio .com (senza hosting) registrato presso Aruba e in stato Transfer Lock, da trasferire verso un altro provider italiano.

Faccio quindi il mio ordine sul nuovo provider il quale, giustamente, mi chiede l’Auth Code del dominio. Vado nel mio pannello di controllo su Aruba per effettuare lo sblocco e recuperare queste informazioni. Ma un messaggio di errore mi informa che l’operazione è impossibile e che devo contattare l’assistenza. Qui comincia il mio calvario… Dato che conosco già le risposte che si ottengono telefonicamente, passo direttamente all’apertura del seguente ticket:

01/12/2011 11:10

Buongiorno, ho la necessità di trasferire il dominio in oggetto verso un altro provider. Ho provato a seguire la procedura di sblocco attraverso l’apposito tool presente nel pannello di amministrazione ma ottengo un errore e mi viene detto di utilizzare l’assistenza. Vorrei quindi sapere come procedere per sbloccare il dominio e ottenere l’auth-code. Grazie e saluti.

Attendo qualche giorno ma nessuno mi degna di una risposta. Così ci riprovo, cercando di dosare il più possibile il tono polemico. In fondo sono passati “solo” 4 giorni:

05/12/2011 15:07

Giusto per capire, avete intenzione di rispondere prima o poi al ticket o avete intrapreso la strada dell’indifferenza?

Anche qui non succede assolutamente niente per diversi giorni e intanto io devo cercare di spiegare al mio cliente cosa sta succedendo. Finalmente dopo ben 11 giorni dall’apertura del ticket ricevo la seguente risposta:

12/12/2011 12:19

Gentile cliente,

abbiamo provveduto ad inviarle

L’Authorization Code come da lei richiesto.

rimaniamo a disposizione

Distinti saluti.

E contemporaneamente ricevo anche la seguente e-mail:

Gentile cliente,

come da Sua richiesta pervenuta in data 12/12/2011 riportiamo di

seguito l’Authorization Code necessario al trasferimento del dominio in oggetto

(segue l’auth code)

Sì avete letto bene, la mail parla di una richiesta pervenuta in data 12 dicembre. Peccato che la mia richiesta era stata fatta il 1 dicembre…

Alla fine sono finalmente riuscito ad avviare la procedura di trasferimento ma non si può certo dire che sia stata un’operazione indolore.

In conclusione il mio consiglio è il seguente:

andate altrove se potete, un fornitore di servizi internet con un supporto tecnico che impiega quasi due settimane per rispondere (tra l’altro per un problema causato da loro stessi, senza il quale non avrei avuto bisogno dell’assistenza) non è un fornitore serio, credo che su questo punto non si possa neanche discutere. Neanche il fatto di essere low cost è una scusa che regge, visto che ho trovato dei provider con costi molto simili e con un supporto tecnico impeccabile.

Sappiate però che anche andarsene non è facile, quello che mi è successo ne è la prova, quindi armatevi di pazienza. Quando sarete riusciti a portare il tutto da un’altra parte potrete finalmente tirare un sospiro di sollievo, come sto facendo io ora! :)

Quella che fino a settimana scorsa era solo una notizia non confermata (o un rumor per dirlo all’americana) è stata ufficializzata attraverso un post sul blog ufficiale: Facebook ha comprato Gowalla.

Per chi non lo conoscesse, Gowalla è un servizio location-based che fu lanciato nel 2009, quando ancora i servizi basati sulla propria posizione geografica non erano una cosa così scontata, anzi, erano un mondo quasi inesplorato. Curiosamente anche quello che sarebbe poi diventato il suo grande rivale, Foursquare, fu lanciato lo stesso giorno, in occasione del SXSW del 2009.

Da lì fu quindi chiaro a tutti che la sfida era aperta tra queste due società. Io personalmente ho fin da subito preferito Gowalla, credo principalmente per una questione di design. Ricordo di aver iniziato ad usare l’app di Gowalla nel novembre del 2009, quando ancora in Italia c’erano pochissimi utenti, tant’è che mi sono ritrovato ad essere il fondatore di alcuni spot di un certo rilievo, tra cui ad esempio il Forum Di Assago e Piazza Del Popolo a Roma.

Pian piano che i mesi passavano però diventava sempre più chiaro che la gara, in termini di numero di utenti, la stava vincendo Foursquare. Io, per quanto mi riguarda, non sono mai passato “alla concorrenza” (pur avendo un account) perchè ho sempre preferito l’approccio visivo e l’usabilità di Gowalla. Bastava guardare i loro stamp personalizzati (per i luoghi più importanti) per capire come il design per il team Gowalla fosse un elemento fondamentale nel loro prodotto.

A quanto pare però non bastava. Foursquare macinava sempre più utenti, giorno dopo giorno. Sinceramente non ho mai capito veramente perchè; qualcuno dice che sia perchè Gowalla è ad Austin, nel Texas, mentre Foursquare è nella city, la cara vecchia New York. Qualcuno dice che Gowalla aveva un nome che rendeva meno l’idea. Qualcuno dice che Ashton Kutcher ha fatto molta promozione gratuita (o forse no) a Foursquare. Qualcuno dice che Gowalla aveva un meccanismo meno chiaro, probabilmente per via delle items, funzionalità che poi è stata tolta con gran dispiacere di alcuni accaniti collezionisti virtuali.

Motivazioni a parte, Gowalla stava perdendo. Da qui una decisione un po’ burrascosa, presentata qualche mese fa: re-inventarsi completamente. Venne presentata una nuova versione di Gowalla che cercava di essere non più una semplice check-in application ma una Social Guide. I check-in vennero convertiti in stories, la condivisione sui social network divenne leggermente più macchinosa e l’applicazione (che inizialmente era anche un po’ buggosa) improvvisamente non mostrava più molte delle informazioni che piacevano tanto ai “Gowallers”. Io stesso a questo punto mi ritrovavo un po’ spiazzato. Nel frattempo Gowalla fu bersagliata di accuse di “aver rovinato tutto” da parte dei fedelissimi e non, tant’è che a un certo punto la loro bacheca su Facebook venne chiusa per non rendere pubblica quella sassaiola. Tanta gente se ne andava e ci teneva a farglielo sapere, quasi fosse stata vittima di un tradimento.

Visto questo scenario capisco come sia facile accettare, senza neanche pensarci più di tanto, una proposta di acquisizione. Dopo aver perso nel tentativo di lancio e di ri-lancio è abbastanza facile aggrapparsi alla prima cosa interessante che arriva. Se poi questa si chiama Facebook ed è il social network per eccellenza, dire di no è praticamente impossibile. Guardando la vicenda in quest’ottica mi è facile capire la gioia espressa pubblicamente dal team di Gowalla, che a breve si trasferirà fisicamente negli uffici di Facebook a Palo Alto e si metterà al lavoro sui servizi di localizzazione come Facebook Places e sulla nuova funzionalità Timeline.

Quelli che rimangono un po’ a bocca asciutta sono però gli utenti: tutte le acquisizioni fatte fin’ora da Facebook avevano come conseguenza immediata la chiusura del servizio e questo caso non è un’eccezione. Gowalla come lo conosciamo chiuderà i battenti verso fine Gennaio 2012 lasciando agli utenti una magra consolazione: ci sarà a quanto pare un modo per esportare la propria attività in modo che non vada persa. Per molti come me si tratta di due anni di viaggi, spostamenti ecc. che effettivamente sarebbe un peccato perdere. Non è chiaro al momento cosa si inventeranno a riguardo… Personalmente spero che, dato che a questo punto pare evidente che bisognerà cercare un’alternativa, verrà magari offerta la possibilità di importare tutto in un altro servizio. Naturalmente non sarà un cosa facile (gli spot differiscono a seconda del servizio) ma sarebbe sicuramente utile.

Quello che invece ho trovato abbastanza folle sono i vari commenti di persone che hanno detto “chiuderò subito il mio account per evitare che i miei dati vadano a Facebook”. Questo mi sembra abbastanza nonsense per diversi motivi:

• É stato ufficialmente dichiarato che Facebook non ha acquistato i dati da Gowalla.
• É abbastanza buffo cercare di tutelare la propria privacy quando si è iscritti ad un servizio dove sostanzialmente dici pubblicamente dove ti trovi e cosa stai facendo. Soprattutto considerando che gran parte degli utenti ha collegato il proprio account Gowalla a Facebook, autorizzando quindi lo scambio di queste informazioni.
• Credo che al giorno d’oggi sia abbastanza impossibile evitare che Facebook abbia i nostri dati, in un modo o nell’altro. Triste, forse, ma vero.

Cmq tornando alle alternative, credo che le possibilità più interessanti siano queste:

• Foursquare
• Path
• Google+ (che tra le altre cose permette anche di registrare la propria posizione)
• Facebook Places (che al momento non sembra granchè ma non è escluso che dopo questa acquisizione diventerà qualcosa di più interessante)

Staremo a vedere insomma!

Sono sempre stato un accanito sostenitore di Flavors.me fin dal giorno in cui è stato presentato (poco più di 2 anni fa). Il concetto era molto semplice: avere una “presenza online” realizzabile in pochi, semplici step che permettesse di aggregare i contenuti provenienti dai vari servizi (social network, video, foto, ecc.). La cosa che subito mi colpì era il loro design editor che permetteva in tempo reale di costruire il layout secondo le proprie preferenze e offrendo il giusto compromesso tra facilità di utilizzo e possibilità di personalizzazione. Essendo un Web Designer avrei dovuto guardare con scetticismo un servizio del genere, invece ne sono stato subito conquistato, tant’è che l’ho utilizzato per realizzare il mio sito personale.

Ora Flavors presenta l’evoluzione del proprio servizio, con la versione 2.0: non più solo uno strumento per costruire il proprio sito web, ma una piattaforma che permette di gestire le nostre interazioni sociali da un unico punto. Seguire una persona su Flavors, infatti, significa ricevere automaticamente aggiornamenti da tutti i suoi canali (quelli collegati al suo account, ovviamente) funzionalità che, nella giungla di servizi in cui ormai quasi tutti siamo presenti, facilita parecchio le cose. Inoltre è anche possibile filtrare queste connessioni come preferiamo, quindi è molto semplice vedere solo quello che ci interessa. Non mi dilungo ulteriormente nella spiegazione, questo video spiega già tutto benissimo. Buona visione!

P.S. Ebbene sì, a 2:37 ci sono anch’io! ;)

Se per caso anche voi come me avete l’abitudine di lavorare ascoltando musica da iTunes oppure la radio, sicuramente troverete interessante la possibilità di utilizzare iTunes anche per ascoltare le principali stazioni radio italiane.

Per noi Mac user, Radio Deejay (la radio che ascolto principalmente) ha realizzato un’applicazione apposita, basata su Microsoft Silverlight e scaricabile da questo link. Tuttavia l’applicazione non è eccezionale e trovo comunque più comodo poter avere tutto dentro iTunes, ad esempio per poter fare Play/Stop da tastiera o per avere un’applicazione in meno aperta.

Questo tutorial spiega molto bene come fare e la soluzione proposta funziona perfettamente anche con OS X Lion (appena testato) e con le principali radio italiane.

***** UPDATE 9 FEBBRAIO 2012 ***********

Dato che questo sistema a me ha smesso di funzionare ho scritto una nuova mini-guida, con una procedura relativa nello specifico a Radio Deejay.

Per leggerla clicca qui

**********************************************

Sebbene non sia mia intenzione utilizzare questo blog per parlare di hardware (non essendone un esperto) questa volta mi piacerebbe parlarvi del FRITZ!WLAN Repeater, un ottimo prodotto che si propone come una soluzione semplice ed efficace per estendere la copertura della vostra rete Wireless.

Sono da ormai diversi anni un fanatico dei prodotti di AVM, un’azienda tedesca conosciuta principalmente per la FRITZ!Box, un “oggettino” che molti già conosceranno e che è in grado di fare tutte queste cose:

• Modem ADSL
• Router LAN / WAN
• Access Point WI-FI
• VOIP (permette di utilizzare uno o più telefoni analogici come telefoni VOIP)
• Print server (permette di utilizzare una stampante USB come una stampante di rete)
• NAT (potete collegare una pendrive o un hard disk USB e farli diventare una unità di storage nella vostra rete)
• Possibilità di utilizzare DNS dinamici e un’ottima gestione degli accessi dall’esterno
• VPN
• tanto altro…

Il tutto gestito da un eccellente pannello di controllo con una quantità imbarazzante di opzioni (a chi non piacciono le opzioni?). Beh sì, come avrete immaginato leggendo queste righe sono un entusiasta possessore di questo oggetto, al punto che l’ho già ri-acquistato (non sto a dirvi che brutta fine ha fatto la mia prima Fritz!Box, è una lunga storia, ma vi basti sapere che non si è rotta da sola…).

C’era una sola cosa che la mia FRITZ!Box non poteva fare (ma non posso fargliene una colpa): coprire decentemente tutta la casa col segnale WI-FI. Pur non vivendo in una reggia, infatti, ho la necessità di portare il segnare su tre diversi piani, che chiamerò A, B e C dal più alto al più basso. Il mio studio (e quindi anche la Fritz!Box) si trova nel piano C e in questo modo riuscivo a coprire solo i piani C e B.

Fino a qualche settimana fa la soluzione al problema è stata la seguente: dato che il piano A è raggiunto dalla rete attraverso cavo Ethernet, ho installato un altro access point (un D-Link DWL G700-AP) che creava una nuova rete WI-FI.

La situazione quindi era la seguente:

• Piano A: coperto dalla rete D-Link
• Piano B: coperto dalla rete D-Link e dalla rete Fritz!Box
• Piano C: coperto dalla rete Fritz!Box

Una soluzione funzionante, se non per i seguenti problemi:

• Ovviamente non esisteva un roaming tra le due reti. Questo significava che se per caso rispondevo ad una telefonata VOIP sul mio iPhone dovevo stare attento al muovermi tra i piani, in quanto avrei potuto perdere il segnale della rete a cui ero inizialmente collegato e far cadere la chiamata. Inoltre spesso ci si ritrovava collegati alla rete sbagliata, con un segnale quindi bassissimo.
• L’access point della D-Link era semplicemente penoso. Richiedeva un reboot almeno una volta il giorno, in quanto si impallava con una facilità estrema. Ricordo ancora una conversazione avuta con l’assistenza tecnica della D-Link, quando il prodotto era ancora in garanzia:
  
  lei: “faccia le seguenti prove… [segue lista di prove non pertinenti al problema e che in nessun modo avrebbero potuto risolverlo]”
  io: “mi sta dicendo che state escludendo del tutto la possibilità che il mio prodotto sia difettato?”
  lei: “sì”.
  io: “ok, grazie [click]”. 

E così, dopo aver accettato questa situazione “instabile” per molto tempo, un bel giorno mi sono detto: sono disposto a spendere € 90,00 per risolvere questo problema? Dato che la risposta è stata “Sì” sono passato all’acquisto di questo oggetto, sempre ovviamente targato AVM: http://www.fritzshop.it/fritz_wlan_repeater.php

Il setup è semplicissimo e tengo a precisare che questo prodotto funziona anche se il vostro Access Point di partenza non è una Fritz!Box.

Collegando il repeater ad una normale presa di corrente si attende l’avvio (circa una trentina di secondi) e siamo pronti per la configurazione. Inutile dirvi che ho collocato il repeater nel piano B, ovvero quello intermedio. Facendo una scansione delle reti WI-FI disponibili vedremo un nuovo network chiamato FRITZ!WLAN Repeater N/G a cui dovremmo connetterci. La rete risulterà protetta da chiave WPA e la password che dobbiamo inserire è: 00000000. A questo punto saremo connessi a questo “network provvisorio” che ci servirà per la configurazione del repeater.

Dobbiamo quindi entrare nell’interfaccia web, digitando nella barra dell’indirizzo del nostro browser l’indirizzo http://fritz.repeater. Se per caso non dovesse funzionare (cosa che ovviamente è successa a me) provate a digitare direttamente l’indirizzo IP, che di default è 192.168.178.2 (a differenza delle Fritz!Box che di solito hanno come indirizzo di default 192.168.178.1). Una volta entrati nell’interfaccia web non dobbiamo fare altro che seguire il Wizard di configurazione che ci chiederà alcune informazioni basilari, come il nome della rete WI-FI principale (che ci farà scegliere da un elenco in base alle reti disponibili) e la relativa password.

Finita questa procedura il repeater si riavvierà e la rete provvisoria a cui eravamo connessi sparirà (niente panico, è giusto che sia così). Riconnettiamoci quindi alla nostra rete principale e godiamoci la nostra nuova copertura WI-FI! :)

Esiste anche una procedura molto più semplice che richiede però che il nostro Access Point supporti la modalità WPS (cosa che alla mia Fritz!Box manca non trattandosi dell’ultima generazione). In questo caso infatti basta premere un pulsante su entrambi i dispositivi entro un breve periodo di tempo e il gioco è fatto.

Un dubbio che avevo era se il Fritz!Wlan Repeater fosse in grado di memorizzare i settaggi anche in caso di interruzione della corrente, o se richiedesse ogni volta una ri-configurazione. Fortunatamente la risposta è stata positiva, il dispositivo si ricorda perfettamente le impostazioni anche se viene scollegato o se manca la corrente quindi un altro punto a favore di questo dispositivo.

In conclusione, ora ho una sola rete WI-FI che copre perfettamente tutti i piani, non riavvio nulla da settimane e tutto funziona benissimo.

Dimenticavo: questo dispositivo ha anche diverse funzioni multimediali, come ad esempio un trasmettitore FM integrato, su cui non mi sono soffermato perchè personalmente non sto sfruttando queste funzionalità, ma se volete approfondire vi rimando alla pagina ufficiale del prodotto.

Tempismo!

Inauguro questo blog parlando della mia recente esperienza nel realizzare un url shortener personalizzato, una pratica molto “di moda” dopo la diffusione di Twitter. Il famoso vincolo dei 140 caratteri ha infatti creato la necessità di usare link il più corti possibile. Certo, ci sono vari servizi già pronti per l’uso e gratuiti come Bit.ly, TinyURL e moltissimi altri, ma la tentazione di averne uno personale era per molti geek come me irresistibile! :)

Ecco un esempio del risultato finale che ho ottenuto: http://kos.ee/kult 

Ma partiamo dall’inizio.

Il dominio

Il primo step è stato proprio la scelta del dominio. Ci sono vari tool sparsi per la rete che facilitano la ricerca dei domini disponibili, alcuni di questi specializzati proprio nella ricerca di domini corti. Il più famoso probabilmente è Domai.nr, che aiuta a trovare dei domain hack ovvero dei domini in cui l’estensione contribuisce a formare la parola o il marchio (ad esempio pep.si, youtu.be, ecc.).

Il servizio è piuttosto utile e veloce, ma presenta alcune pecche: molto spesso propone delle soluzioni con domini da uno/due caratteri mostrandole come disponibili, ma in realtà quasi sempre i registrar hanno come requisito minimo che il dominio abbia almeno 3 caratteri. Non sempre quindi ciò che ci viene mostrato da Domai.nr può essere effettivamente acquistato. Inoltre, per quanto il servizio cerchi di essere “intelligente”, non può certo competere con la nostra creatività e vi assicuro, cercare il proprio short domain richiede tutta la nostra inventiva! ;)

Ho “giocato” un po’ con questo tool, provando le parole chiave che in qualche modo hanno a che fare con me, quindi: Kultmedia, Kult, Cosentino, Kose (il mio soprannome da anni) ecc. Purtroppo non sono riuscito a trovare niente di realmente interessante e ho quindi preferito provare un approccio più “manuale” alla ricerca.

Prima di tutto ho trovato questa ottima lista su Wikipedia che ci mostra quali sono tutte le estensioni disponibili nel mondo. Spesso infatti i provider / registrar hanno una scelta piuttosto limitata. Persino Godaddy, registrar a cui mi affido spesso, ha a disposizione non più di una quarantina di estensioni.

Ho capito quindi che l’approccio corretto era:

1. Trovare l’estensione giusta
2. Trovare il registrar in grado di registrare quell’estensione

Naturalmente la difficoltà non sta solo nel trovare un dominio interessante, ma nel trovarlo anche libero. Per fare questi controlli in modo veloce mi sono servito del Bulk domain search tool offerto da 101domain, che permette di cercare anche più domini contemporaneamente.

Dopo un paio di ricerche scopro qualcosa di soprendente: il dominio co.se risultava libero. Ancora incredulo (un dominio di sole due lettere è qualcosa di veramente raro e ottimo per il nostro scopo) decido di inviare l’ordine direttamente con 101domain in quanto abilitato all’acquisto di domini .se (Svezia). Faccio quindi il mio ordine e relativo pagamento e attendo con impazienza l’attivazione.

Qui le cose si complicano… Dopo alcuni giorni senza alcuna notizia decido di aprire un ticket. L’attivazione doveva richiedere dalle 48 alle 72 ore, tempo che era già abbondantemente passato. Purtroppo anche al mio ticket seguono giorni di silenzio assoluto. Nessuna risposta, eppure anche i ticket secondo le FAQ dovevano essere gestiti entro 48 ore. Comincio a leggere un po’ di forum sparsi per la rete e scopro che a quanto pare l’assistenza di 101domain è piuttosto scadente e che c’è in giro gente molto più arrabbiata di me.

Fortunatamente avevo pagato con Paypal quindi mi appello all’unica “arma” ancora a mia disposizione: la contestazione. Apro quindi una contestazione Paypal spiegando le mie ragioni e attendo. Dopo poche ore ricevo il rimborso dell’importo pagato, l’annullamento dell’ordine e una mail che mi spiega che quel dominio, pur risultando libero, è in realtà bloccato dalle autorità svedesi e quindi non può essere acquistato. Contento di aver recuperato i miei soldi (un po’ meno dell’aver dovuto usare le “maniere forti” per farmi valere) torno alla ricerca del mio dominio.

Sono quasi sul punto di comprare kose.li quando un mio amico, Paolo, mi illumina suggerendo kos.ee (Estonia). L’idea mi sembra ottima ma anche qui trovo un ostacolo: pare infatti che per possedere un dominio in Estonia sia necessario possedere lì la residenza o un’attività. Cerco un modo per “aggirare” questo vincolo e scopro che 101domain offre un servizio di Trustee ovvero un servizio di presenza locale in Estonia. Purtroppo però non mi fido più molto di loro e proseguo la mia ricerca fino a trovare l’eccellente Marcaria.com che fin da subito si rivela la soluzione al mio problema, ad una cifra più che ragionevole. Concludo l’ordine e dopo qualche giorno sono il felice possessore del dominio kos.ee.

Il servizio

Bene, ora ho il mio dominio, ma cosa ci faccio?

Da diverso tempo Bit.ly ha reso disponibile nella versione free una funzionalità che prima era riservata ai possessori di un account Pro: i custom short domain.

Procedo quindi subito alla configurazione, molto semplice:

1. Aprire un account gratuito su Bit.ly
2. Puntare i DNS del nostro dominio sul server di Bit.ly
3. Comunicare a Bit.ly il nostro custom domain (ed eventualmente metterlo come predefinito)

Il sistema funziona alla perfezione e trovo subito alcune funzionalità davvero interessanti: la possibilità di monitorare i click sui nostri short link, la presenza di estensioni per i browser più diffusi ecc. Nel complesso un ottimo servizio.

Mi scontro però con due cose che non mi piacciono molto:

• Non è possibile fare il forward del dominio “base” (ad esempio http://kos.ee) a un sito da noi scelto. Il nostro dominio infatti rimanderà automaticamente alla homepage di bit.ly e non è possibile modificare questa impostazione (se non comprando la versione Enterprise alla cifra astronomica di $995,00 al mese, che si possono permettere solo alcuni mostri sacri come Pepsi e il New York Times).
• La stringa generata nel nostro short url non è altro che un alias della stringa col dominio bit.ly. Per rendere meglio l’idea: kos.ee/s6zkws è esattamente la stessa cosa di bit.ly/s6zkws. Questo significa che, pur avendo un dominio custom, non avremo mai delle stringhe semplici perchè la nostra stringa deve essere univoca non solo per il nostro dominio ma per tutto il database degli utenti bit.ly.

Insomma, il nostro dominio è diventato un “mirror” di Bit.ly. Il controllo che abbiamo è quindi fortemente limitato.

Decido di cercare un’alternativa e per un po’ valuto l’idea di acquistare CloudApp Pro, a una cifra ragionevole: $45,00 all’anno. Oltre all’ottimo servizio di condivisione file, infatti, viene offerto anche un url shortener personale.

C’è un altra idea che mi frulla in testa: farmelo da solo e ospitarlo su un mio server. “Sono pur sempre uno sviluppatore”, mi dico, “che sarà mai?”. Ma prima che io possa valutare seriamente l’idea di “fare da me” mi imbatto in questo fantastico script PHP open source: Yourls. 

L’installazione è piuttosto semplice, si copiano i file nello spazio web, si fanno un paio di modifiche al file di configurazione (in cui dobbiamo inserire i parametri per la connessione a un database MySql) e il gioco è fatto. Inoltre la documentazione sul sito è completa e dettagliata.

Dopo aver fatto funzionare il tutto mi rendo conto di avere davanti uno strumento ottimo, che non ha niente da invidiare ai vari servizi già provati ma col vantaggio di essere self-hosted e quindi mio al 100%. Posso creare degli indirizzi corti e semplici come ad esempio http://kos.ee/kult e inoltre ho potuto indirizzare il dominio “base” al mio sito personale. Le statistiche dei click ci sono, si possono modificare i link già creati e ci sono addirittura diversi tipi di Bookmarklet che possono essere inseriti nel nostro browser con estrema facilità. Insomma, lunga vita a Yourls, un piccolo “gioiellino” che consiglio a tutti.

Con questa storia (piuttosto lunga a quanto pare, spero di non avervi annoiato) si conclude il mio primo post su questo blog, mi auguro che la mia esperienza possa tornare utile a qualcuno! :)

P.S. alla fine quelli di 101domain hanno risposto al mio ticket. Peccato che fosse già passata più una settimana dalla chiusura del “caso”… Se non altro però hanno avuto l’accortezza di correggere l’errore nel loro tool di ricerca, ora il tentativo di registrare quel dominio dà esito negativo, com’è giusto che sia.