Qix.it

Gola profonda

2010-06-30T09:26:58+02:00

No, non questa qui, ma un nuovo servizio lanciato dal team di Liquida: Wikideep, un bel motore di ricerca per pescare contenuti dai wiki sparsi per la rete. E' un servizio davvero ben fatto, anche dal punto di vista tecnico (che è poi quello che a me intriga di più): nei miei passaggi periodici in Liquida ho avuto occasione di parlarne con Pio che l'ha sviluppato, e spero che prima o poi pubblichi qualcosa sull'architettura di Wikideep perchè ne varrebbe davvero la pena. Nel frattempo, andate a dargli un occhiata.

Quant’è bello l’Ipad

2010-05-31T08:38:41+02:00

Stamattina, passando in edicola per prendere il settimanale ATM, sono rimasto a bocca aperta davanti a una pila di iPad nuovi di zecca, e dato che costavano poco mi sono detto: perchè no? E quindi dopo un road test di mezz'ora sui mezzi pubblici, ecco le mie prime impressioni.

I pro. E' leggerissimo! E cosa ancora più incredibile, alla Apple hanno fatto il miracolo: si piega senza rovinarsi. Lo schermo poi è nitido e con un contrasto fantastico: i caratteri sono davvero neri, la pagina bianca, e in condizioni di luminosità normale non affatica assolutamente gli occhi. Ma la cosa più incredibile è il multi touch, per chi non l'avesse mai sperimentato funziona così: si piegano indice e pollice fino a farli quasi toccare, li si porta sull'angolo dell'iPad, lo si afferra, e si fa un movimento diagonale. A quel punto, parte un'animazione (fatta così bene che sembra davvero di spostare un oggetto fisico), e l'iPad cambia pagina. Fantastico! C'è anche una modalità per chi odia far sbirciare i vicini in metropolitana, che permette di piegare il device fino a oscurare completamente i contenuti. Devo dire che le hanno pensate davvero tutte! Il collegamento dati poi ha funzionato a meraviglia, anche in galleria: sono riuscito a leggere senza interruzioni per una ventina di minuti.

I contro. Mi aspettavo qualche animazione alla Harry Potter, ma le fotografie sono tutte statiche: poco male, tanto trovo i video assolutamente noiosi e non li guardo nemmeno sul PC e tantomeno in televisione, e in movimento poi mi avrebbero probabilmente fatto venire il mal di mare. Il suo vero problema però è che costa troppo poco: in metropolitana ce l'avevano quasi tutti. Peccato, speravo di fare un figurone, ma nessuno mi ha degnato neanche di un'occhiata di invidia o curiosità. Anzi, ho visto addirittura un modello più compatto, che sembra offrire contenuti gratuiti. Sarà vero?

Concludo con una foto, per farvi apprezzare il design rivoluzionario di questo splendido oggetto.

Yes, I am a data geek / 3

2010-05-26T09:27:28+02:00

Un piccolo intermezzo in cui vi racconto come far inserire a MySQL un grafico ASCII nei risultati di una query.

Spesso un grafico è la soluzione migliore per cogliere a colpo d'occhio la distribuzione e l'andamento di una serie di dati. Il problema è che, per la maggior parte delle persone, fare un grafico vuol dire estrarre i dati, importarli in Excel (o equivalente), aggiustare il formato delle celle, e smanettare qualche minuto con il mouse per trovare la rappresentazione giusta.

Io invece sono un pigro, e se posso fare tutto da linea di comando con qualche pressione di tasto in più, e qualche movimento del mouse in meno, sono contento. E poi i grafici ASCII fanno tanto vintage. :P

Come esempio prendiamo una tabella le cui righe hanno un campo data, e proponiamoci di esaminare i giorni in cui si raccolgono il maggior numero di dati, e la loro distribuzione. La tabella dei post di un blog è un esempio calzante, io userò la tabella che raccoglie i post dal database di test di BlogBabel. Il campo che ci interessa è uno solo, date_published, un campo di tipo datetime che raccoglie appunto la data di pubblicazione. Come prima cosa, vediamo quale è il suo valore massimo per capire con che tipo di numeri abbiamo a che fare

mysql> select
    ->    cast(date_published as date) as day,
    ->    count(*) as num
    -> from crawler_entry
    -> group by day
    -> order by num desc
    -> limit 1;
+------------+-------+
| day        | num   |
+------------+-------+
| 2010-05-21 | 22837 | 
+------------+-------+

Ci sono probabilmente modi più sofisticati di fare la stessa cosa, ma per i nostri scopi va bene quanto vedete qui sopra: facciamo un cast del campo datetime a date in modo da ridurlo al valore del giorno scartando ora minuti e secondi, raggruppiamo e contiamo le righe ottenendo i singoli totali per giorno (se avessimo un campo valore nelle singole righe useremmo sum() invece di count()), ordiniamo i risultati per i totali in ordine discendente, e teniamo solo il primo scartando tutto il resto. Phew, più lungo da spiegare che da fare.

A questo punto, possiamo studiare un altro po' i dati per decidere quanti sono i giorni singoli e quali sono quelli con un totale significativo, in modo da limitare l'insieme dei risultati generati e renderlo più facilmente analizzabile. Proviamo ad esempio a vedere quanti sono i giorni che hanno almeno 1000 post

mysql> select count(day) from (
    ->    select cast(date_published as date) as day
    ->    from crawler_entry
    ->    group by day
    ->    having count(*) > 1000
    -> ) as aggregate;
+------------+
| count(day) |
+------------+
|         79 | 
+------------+

Il meccanismo è lo stesso che abbiamo usato sopra: facciamo un cast del campo datetime a date, raggruppiamo in modo da avere i singoli totali, e infine usiamo i risultati come una tabella virtuale di cui contiamo le righe. Semplice, no?

A questo punto abbiamo tutte le informazioni che ci servono per estrarre i risultati definitivi e creare il nostro grafico ASCII: quale è il valore massimo del dato (22.000 e rotti), quale è la soglia minima che ci interessa (1.000), quante righe otterremo (79). Pronti? Via!

mysql> select
    ->    cast(date_published as date) as giorno,
    ->    concat(lpad(count(*), 7, ' '), ' ', rpad('', count(*) / 1000, '#')) as `numero di post`
    -> from crawler_entry
    -> group by giorno having count(*) >1000
    -> order by giorno desc;

Gli elementi di base sono gli stessi che abbiamo già visto sopra: il campo data ottenuto con il cast, il raggruppamento per avere i totali singoli, un limite per ottenere solo le righe con totale maggiore di 1.000, l'ordinamento discendente per giorno. La novità introdotta in questa query è il campo che abbiamo chiamato numero di post, che sono poi le singole barre del nostro grafico ASCII. Per ottenerlo:

facciamo un pad a sinistra del valore numerico del totale, in modo che sia allineato a destra
facciamo un padding di una stringa vuota che usi il carattere # come riempimento, e lo ripeta per un numero di volte uguale al totale diviso per 1.000 (la nostra soglia minima)
concateniamo i due valori ottenuti (il totale allineato e i #) con uno spazio

Il risultato è una cosa così

+------------+---------------------------------+
| giorno     | numero di post                  |
+------------+---------------------------------+
| 2010-05-25 |    4597 #####                   | 
| 2010-05-21 |   22837 ####################### | 
| 2010-05-20 |   21067 #####################   | 
| 2010-05-19 |   16395 ################        | 
| 2010-05-18 |   14056 ##############          | 
| 2010-05-17 |   12090 ############            | 
| 2010-05-16 |    5683 ######                  | 
| 2010-05-15 |    4623 #####                   | 
| 2010-05-14 |    8579 #########               | 
| 2010-05-13 |    8506 #########               | 
| 2010-05-12 |    8310 ########                | 
| 2010-05-11 |    7390 #######                 | 
| 2010-05-10 |    7113 #######                 | 
| 2010-05-09 |    3639 ####                    | 
| 2010-05-08 |    2863 ###                     | 
| 2010-05-07 |    5291 #####                   | 
| 2010-05-06 |    5339 #####                   | 
| 2010-05-05 |    5381 #####                   | 
| 2010-05-04 |    4959 #####                   | 
| 2010-05-03 |    4832 #####                   | 
| 2010-05-02 |    2653 ###                     | 
[... snip...]

Semplice, no?

Yes, I am a data geek / 2

2010-05-24T15:33:20+02:00

Mi ero ripromesso di raccontare un po’ delle esperienze tecniche fatte con Blogbabel, poi i mesi passano e non sembra mai essere il momento buono, così ho deciso di buttare giù qualche appunto sperando di trovare nei prossimi giorni le motivazioni per arricchirli ed espanderli.

Se dovessi scegliere una sola delle tante cose imparate in questi ultimi anni, non avrei molti dubbi nell'indicare la dimestichezza con le basi dati relazionali. Non solo perchè giocare con i dati mi diverte, ma anche perchè credo sia un aspetto spesso trascurato da chi sviluppa, e di importanza fondamentale per le prestazioni e la congruenza delle informazioni presentate.

Il mio percorso in questo senso con BlogBabel è stato forzato da due condizioni: le risorse hardware limitate (per un anno e mezzo BlogBabel ha convissuto su un vecchio Celeron 900 con poca RAM e dischi lenti insieme ad altre applicazioni), e la mole di dati che cresceva a ritmo esponenziale (quando ho passato a Liquida, il db era già maggiore di 50Gb).

Le ottimizzazioni fatte al db hanno quindi seguito fasi successive: completato un ciclo, si rendeva necessario dopo poco tempo passare a un livello di ottimizzazione superiore per non dover buttare altro hardware dentro al progetto. Semplificando, le fasi di ottimizzazione che ho attraversato sono state:

analisi delle query e ottimizzazione degli indici
denormalizzazione di alcuni campi e tabelle, per ottimizzare filtri e ordinamento nei join
calcolo periodico (batch) dei dati aggregati più importanti
creazione di trigger per l'alimentazione online di aggregati
spostamento dei trigger su una coda di eventi processata da programmi esterni
utilizzo di più livelli di aggregati ibridi batch e online

L'insegnamento principale che ho tratto da questo lungo e laborioso processo è che non tutti i dati devono essere sempre consistenti: molte informazioni (e spesso sono quelle più onerose da generare) possono avere fluttuazioni nella loro consistenza rispetto al resto dei dati, senza per questo avere un impatto significativo sull'usabilità o sull'esperienza utente; quello che importa è che siano "periodicamente consistenti".

Da cui discende un altro aspetto fondamentale: anche se a prima vista elaborare alcuni tipi di dati o reagire a certi eventi direttamente all'interno del database, sembra l'operazione più semplice e lineare, è in realtà il modo migliore per incrementarne in maniera esponenziale la complessità e i rischi.

Nei prossimi giorni vedrò di trovare il tempo per entrare un po' nei dettagli di questi argomenti, sempre che a qualcuno interessi.

Blogbabel 3.0

2009-11-16T15:21:48+02:00

Come alcuni di voi si saranno accorti, settimana scorsa Blogbabel ha cambiato aspetto. Avrei voluto scrivere qualcosa prima, ma il poco sonno accumulato in queste ultime settimane e un ritorno di influenza mi hanno fatto rimandare fino ad ora.

Le modifiche rilasciate sono il primo risultato della collaborazione con il team di Liquida (che per chi non lo sapesse ha rilevato Blogbabel ormai quasi due mesi fa), e non sono state solo cosmetiche ma hanno avuto un impatto significativo anche sul backend, la struttura dei dati raccolti, l'ottimizzazione per i motori di ricerca e l'usabilità. Non sto a ripetere qui l'elenco di cosa è cambiato, altri l'hanno fatto prima di me e anche il comunicato stampa di Banzai è abbastanza trasparente al riguardo.

Quello che posso aggiungere a quanto già scritto, sono le mie impressioni dopo un paio di mesi di lavoro a stretto contatto con il team di Liquida. Partiamo dalla cosa più importante: le aspettative che mi ero creato durante la fase di negoziazione, che hanno avuto un peso rilevante nella scelta di vendere a Liquida, sono state ampiamente soddisfatte e anzi superate.

Da Liquida ho trovato entusiasmo, e non solo quel tipo di entusiasmo che dovrebbe contraddistinguere le startup con investitori alle spalle, persone giovani e capaci nel team, e progetti interessanti da sviluppare. Certo, in Liquida non manca tutto questo e quando passo da loro in ufficio mi sembra di respirare una boccata d'aria rispetto all'atmosfera stagnante e piuttosto deprimente del mio lavoro "normale". Quello che non mi aspettavo è l'accoglienza riservata a Blogbabel, l'energia creativa che ho visto spendere in brainstorming su come valorizzare il lavoro fatto in questi anni, l'attenzione per le specificità del progetto. La differenza emotiva per me che sviluppo rispetto agli anni precedenti è stata enorme, l'entusiasmo (per un progetto che ho partorito e amato per molto tempo) contagioso e mi sono ritrovato a lavorare e immaginare Blogbabel come non succedeva ormai da tanto.

Insieme a questo, trovare nel gruppo persone davvero in gamba con competenze specifiche su SEO, design, usabilità e altre discipline in cui da solo mi barcameno con scarso successo, è servito a scaricarmi da responasabilità che mal sopporto e farmi concentrare su quello che mi piace di più e credo di saper fare meglio: lo sviluppo e la modellazione dei dati.

Come dicevo sopra, il risultato è solo l'inizio di quello che sembra sarà un lavoro lungo, intenso e (speriamo) pieno di soddisfazioni. Nei prossimi giorni, appena mi sono ripreso un po', vedrò di pubblicare qualche post su alcune tecniche che ho utilizzato per ottimizzare l'accesso ai dati, condito magari da considerazioni un po' più generali sulle specificità di servizi web di medie dimensioni (o grandi, se guardiamo alle dimensioni del db di Blogbabel che è arrivato a una cinquantina di Gb di dati "live"). Se nel frattempo avete qualche curiosità particolare, chiedete pure nei commenti.

Yes, I am a data geek / 1

2009-09-11T13:42:51+02:00

Riprendo a parlare di cose serie, dopo i deragliamenti di questi giorni, con il primo di una serie aperiodica di post sulla manipolazione dei dati. E' un argomento che mi ha sempre affascinato, e in questa serie descriverò per ogni post un piccolo problema che mi è capitato di dover risolvere lavorando, e una delle sue possibili soluzioni. Edit: questo post è anche su Stacktrace, pensavo fosse troppo semplice per Stacktrace ma Antonio la pensa diversamente.

In questo primo post vi racconto un problemino che mi è capitato sottomano giusto ieri in ufficio: come calcolare degli aggregati periodici (ad esempio ogni 5 minuti) da un elenco di rilevazioni del traffico di un servizio. I dati che ho ricevuto erano in formato Excel, ma per semplificarci la vita senza inciampare in tabelle pivot e soprattutto dato che siamo geek, per trattarli utilizzeremo un database relazionale (nel mio caso MySQL).

Iniziamo a dare un'occhiata ai dati, che sono semplici e consistono in righe ognuna composta da due colonne: l'ora di rilevazione, e il numero di kbyte inviati. Ogni riga rappresenta una singola transazione. Disegniamo una semplice tabella MySQL, con una chiave primaria generica (potremmo anche farne a meno) e un indice sul campo con l'ora di rilevazione:

CREATE TABLE `test` (
  `id` int(11) NOT NULL auto_increment,
  `tstamp` time NOT NULL,
  `size` int(11) NOT NULL,
  PRIMARY KEY  (`id`),
  KEY `idx_tstamp` (`tstamp`)
) ENGINE=InnoDB;

Carichiamo i dati (io ho usato la console di Python, ma ci sono altri mille modi per farlo tra cui LOAD DATA LOCAL INFILE), e vediamo come si presentano un paio di righe:

mysql> select * from test limit 2;
+----+----------+------+
| id | tstamp   | size |
+----+----------+------+
|  1 | 07:02:06 |    2 | 
|  2 | 07:02:09 |    2 | 
+----+----------+------+

Il primo problema è: come facciamo a raggruppare tutte le righe in intervalli di 5 minuti? Se proviamo a disegnare un paio di serie di minuti, la risposta è abbastanza evidente (almeno per chi come me + abituato a ragionare in modo visuale):

minuti                indice per l'aggregazione
 0  1  2  3  4        0
 5  6  7  8  9        1
10 11 12 13 14        2

Capito come fare? Semplice: basta dividere il minuto per l'intervallo che vogliamo considerare (in questo caso 5), e scartare i decimali utilizzando la funzione floor. Vediamo come si fa in MySQL:

mysql> select tstamp,
       floor(minute(tstamp)/5) as indice
       from test limit 2;
+----------+--------+
| tstamp   | indice |
+----------+--------+
| 07:02:06 |      0 | 
| 07:02:09 |      0 | 
+----------+--------+

Ovviamente per aggregare le nostre righe, oltre all'indice dei minuti avremo bisogno anche l'ora:

mysql> select
      hour(tstamp) as ora,
      floor(minute(tstamp) / 5) as intervallo,
      sum(size) as traffico from test
      group by ora, intervallo
      order by tstamp limit 3;
+------+------------+----------+
| ora  | intervallo | traffico |
+------+------------+----------+
|    7 |          0 |        6 | 
|    7 |          1 |     1604 | 
|    7 |          2 |       42 | 
+------+------------+----------+

Funziona? Direi di si, peccato solo che i risultati aggregati siano poco eleganti: due campi diversi per ora e intervallo, nessuno dei quali formattati, non aiutano certo la leggibilità. Possiamo fare di meglio: un campo unico per ora e intervallo, formattato e con il giusto padding (lo zero per ore e minuti a singola cifra), un intervallo descrittivo che non sia l'indice opaco che funziona per MySQL ma dice molto poco a chi dovrà utilizzare i dati, e aggiungiamo anche un campo ulteriore con il numero di pacchetti del periodo oltre alla somma del traffico:

mysql>
      select concat(
          lpad(hour(tstamp), 2, '0'),
          ':',
          lpad(floor(minute(tstamp) / 5) * 5, 2, '0'),
          '-',
          lpad(floor(minute(tstamp) / 5) * 5 + 5, 2, '0')
       ) as periodo,
       count(*) as trasmissioni,
       sum(size) as traffico
       from test
       group by hour(tstamp), floor(minute(tstamp) / 5)
       order by tstamp limit 3;
+----------+--------------+----------+
| periodo  | trasmissioni | traffico |
+----------+--------------+----------+
| 07:00-05 |            3 |        6 | 
| 07:05-10 |            1 |     1604 | 
| 07:10-15 |            3 |       42 | 
+----------+--------------+----------+

Chiaro? No? Ok, guardiamo in dettaglio come è costruita la query.

Il primo campo che estraiamo è il periodo su cui vengono aggregati i dati, composto con valori diversi uniti dalla funzione concat, che altro non fa che unire insieme in un unico campo i valori che gli vengono passati: l'ora, il separatore ':', il primo minuto dell'intervallo, il separatore '-', l'ultimo minuto dell'intervallo. Su ora e minuti facciamo poi il padding premettendo uno zero se il numero è in singola cifra, utilizzando la funzione lpad. Il secondo e il terzo campo sono le semplici funzioni aggregate di conteggio del numero di righe dell'intervallo, che ci restituisce il numero di trasmissioni, e la somma del traffico.

Dato poi che in questa query non abbiamo estratto l'indice di aggregazione come campo visibile, dobbiamo dichiararlo esplicitamente come clausola del group by invece di richiamarlo per nome come abbiamo fatto nella query precedente.

A questo punto, se dobbiamo passare i dati a qualche collega che deve importarli in Excel per generare un grafico, ci basta passare la query al client mysql come valore dell'argomento '-e', aggiungere '--batch' in modo da ottenere i risultati come campi delimitati da tabulatore, e redirigere l'output su un file.

Piccoli chiarimenti

2009-09-10T13:36:14+02:00

Gli ultimi giorni sono stati abbastanza faticosi, cosa che certo non aumenta il mio già scarso interesse per le polemiche intorno a BlogBabel. Credo ci sia però bisogno di qualche chiarimento, in particolare rispetto al post di Gianluca che propone una versione astiosa, grottesca, offensiva e con molte falsità di una trattativa svoltasi nei mesi scorsi.

Qualche mese fa avevo messo in giro la voce che avrei voluto vendere BlogBabel, e tra gli altri si era fatto avanti anche Gianluca facendosi tramite dell'interesse di due aziende. Fin da subito l'affare sembrava poco chiaro: delle due aziende potevo incontrarne solo una, ma sapevo già che non avrei dovuto accettare una loro offerta; la seconda non era interessata a vedermi, e avrebbe comprato a scatola chiusa. Non ho grandi esperienze di trattative commerciali, ma nei miei 15 anni di lavoro per grandi aziende, spesso su progetti da milioni di euro, una cosa così non l'avevo mai vista e mi era sembrata da subito poco seria. Decido comunque di proseguire, per vedere dove si sarebbe andato a parare.

In circa un mese e mezzo riesco ad incontrare una volta solo la prima azienda (quella la cui offerta, secondo Gianluca, avrei dovuto rifiutare), mentre per la seconda scrivo una paginetta generica su BlogBabel ma non si arriva poi a discutere di come è strutturato il servizio, come si può trasferire, cosa serve per farlo girare, e tantomeno cosa vorrebbe farne il possibile acquirente. Nel frattempo, ricevo ogni tanto le telefonate dell'“assistente” di Gianluca, che sostiene che la seconda offerta è sempre valida e si sta considerando come procedere, fino a quando mi viene chiesto un appuntamento per discuterne con Gianluca.

Decidiamo di prendere una pizza vicino a casa mia (se non altro per minimizzare lo sforzo dedicato a una trattativa che già mi sembrava doomed), e Gianluca mi presenta l'offerta: 60.000 euro (non 80 come hai scritto, Gianluca...), non trattabili, da accettare entro una manciata di ore pena il ritiro immediato, senza niente di scritto e nessun dettaglio su chi/cosa/come. Come ulteriore fattore di pressione nei miei confronti, mi viene detto che una società di consulenza è già pronta per sviluppare un servizio simile a BlogBabel, nel caso io non avessi voluto vendere o avessi fatto difficoltà. Peccato che io abbia una certa esperienza su grandi progetti IT in ambito Enterprise (caro Gianluca, non puoi pensare sempre di avere a che fare con dei fessi, sono 15 anni che faccio questo mestiere...), e so benissimo quanto tempo ci vuole, quanto costa, e quale di solito è il risultato di operazioni di questo tipo, e la pressione sia quindi in senso opposto (“volete il software? io ce l'ho pronto, me lo pagate il 40% in meno rispetto alla società e ve lo installo domani, con il resto pagate il supporto e la manutenzione da chi vi pare, ecc.”).

Dato che la serata non butta bene e l'offerta mi sembra molto poco seria, provo a far scoprire Gianluca per capire cosa veramente ci sia sotto, e inizio a tirare sul prezzo e a prospettare soluzioni diverse e più articolate. Di fronte, come prevedibile, mi trovo un muro e soprattutto con il passare dei minuti la maschera di affabilità di Gianluca e del suo “assistente” si fa sempre più tirata e alla fine scompare del tutto, quando diventa chiaro che non ho nessuna intenzione di proseguire a certe condizioni.

E qui finisce la storia, fino a quando Gianluca decide di dare sfogo al suo rodimento interiore con il post dell'altro ieri. Caro Gianluca, nonstante le tue indubbie capacità di comunicatore credo che questa volta tu abbia decisamente esagerato, andando contro i tuoi stessi interessi:

dare del pazzo incapace a chi da 15 anni lavora nell'IT ad alti livelli per aziende di grandi dimensioni, e sostenere di converso che l'unica speranza per un progetto è che venga preso da te e “rimesso in ordine” sta facendo sorridere parecchie persone di qua e di là dell'Atlantico
adottare un comportamento mafioso (“o fai come dico io o ti distruggo la reputazione”) credo darà da pensare ad alcune aziende che in passato hanno avuto rapporti con te
non so quanti dei tuoi clienti saranno contenti di sapere che pubblichi informazioni commerciali su una trattativa che dovrebbe essere riservata, oltretutto facendolo in modo grottesco e falsandone i dati; inoltre, mi chiedo con che coraggio ti affideranno in futuro un'altra trattativa da condurre per conto loro, visto come hai gestito questa
provare a ridicolizzarci pubblicamente con affermazioni false o distorte prima o poi ti si potrebbe ritorcere contro, il mondo del web italiano è piccolo e chissà che in futuro le nostre strade non si incrocino di nuovo

Da te ci aspettiamo delle scuse, che so già che non verranno mai. Credo di avere imparato un po' a conoscerti in questi anni, e la correttezza o l'educazione non mi sembrano il tuo forte. Poco male, per fortuna ci muoviamo in ambienti differenti, e spero che anche se dovessi avere la sfortuna di incontrarci in futuro, avrai il buon senso di girare alla larga ed evitare di aggiungere altre falsità a quelle che hai già scritto.

Perchè BlogBabel non è più in vendita

2009-09-08T19:53:59+02:00

Immagino che alcuni di voi si staranno chiedendo come mai l'asta per BlogBabel è stata ritirata da ebay. Sapevo che la chiusura avrebbe scatenato i (pochi) soliti noti, e che le voci di corridoio sarebbero state che BB non aveva raggiunto un prezzo adeguato, o peggio. Quello che è successo è in realtà molto più semplice: tra le tante offerte e manifestazioni di interesse ricevute in questi giorni ce ne sono state due (edit: tre) particolarmente significative, che al di là del mero trasferimento di codice, dati e dominio prevedevano una collaborazione con idee chiare, e risorse adeguate per sostenerle.

Non è difficile quindi capire che offerte di questo tipo, dove la maggior parte del valore economico dell'operazione non è attribuito alla vendita ma a quello che succede dopo, siano difficilmente paragonabili a quelle "anonime" che avrei ricevuto negli ultimi minuti dell'asta, e proseguire con questo formato non avrebbe solo fatto un torto a chi ha le migliori idee imprenditoriali e può dispiegare risorse significative, ma anche a tutta la fatica e l'impegno messo in BlogBabel in questi anni.

Da qui la sospensione dell'asta che rientra nei termini previsti da ebay, dato che le due offerte in questione altro non sono state che la prosecuzione di colloqui avviati parecchi mesi fa, cui la messa in vendita di questi giorni ha solo dato una accelerata finale. Spero quindi che chi aveva intenzione di partecipare all'asta (per non dire dei soliti, per fortuna pochi, facinorosi che hanno circondato BlogBabel in questi anni) si astengano dal ricorrere ad ebay perchè ne ricaverebbero poche soddisfazioni, dato che gli incontri dei mesi scorsi con chi ha presentato le due offerte sono documentabili in maniera oggettiva.

Questi ultimi giorni sono stati un vero tour de force, ma sono molto soddisfatto di come si è conclusa la vicenda e sono convinto che lo spirito e la tecnologia di BlogBabel verranno valorizzate al massimo nell'immediato futuro, grazie anche a un gruppo di persone entusiaste e con le idee molto chiare.

Un'ultima considerazione su ebay: lo uso da anni sia come venditore che come acquirente, ma non avrei mai pensato che mettere in vendita BlogBabel sarebbe stata una mossa così azzeccata. In un mercato tutto sommato stagnante e molto poco tendente al rischio come quello italiano, le trattative si trascinano per mesi e spesso chi compra adotta di proposto una tattica attendista, ben sapendo che le opportunità sono davvero poche. Mettere all'asta un servizio (e vi assicuro che se non avessi ricevuto offerte complesse che con l'asta poco avevano a che fare, BlogBabel sarebbe stata venduta su ebay) ha innescato due meccanismi: da un lato ha fatto intravedere ad alcuni la possibilità di acquistare qualcosa ad un prezzo basso, inferiore a quello reale e alla portata di budget tutt'altro che faraonici; dall'altro, ha spinto chi già aveva interesse ad un'acquisizione ad accelerare i tempi per cercare di raggiungere un accordo prima della scadenza dell'asta, costringendo a spingere sull'acceleratore e permettendo anche di saltare parecchie delle pastoie burocratico/aziendali (budget, approvazioni, ecc.) tipiche di processi di vendita normali.

Dov'è il nome di chi ha comperato? Per ora da nessuna parte, ho firmato un accordo di riservatezza e per una volta, finalmente, non tocca a me gestire modi e tempi di comunicazione. E credo, d'ora in poi, nemmeno più trattare con i soliti pochi facinorosi. Delle soddisfazioni di questi giorni sicuramente la più a buon mercato, ma non per questo meno gustosa.

PS -- se siete tra quelli che hanno collaborato a BlogBabel in passato, abbiate un pochino di pazienza: non mi sono dimenticato di voi.

PPS -- la frase "migliori idee imprenditoriali" è un po' forte e qualcuno se l'è presa, scusatemi ma a questo punto sono davvero cotto e non mi esprimo con chiarezza, avrei dovuto scrivere "le idee imprenditoriali più vicine allo spirito originario di BB"; quello che volevo esprimere era che certe idee (incluse quelle di una terza offerta discussa in extremis e seguita da una puntatona su ebay) mi sembravano valorizzare il mio impegno di questi anni, altre (l'utilizzo come strumento di SEO massiccio ad esempio) un po' meno.