Steven Levy és un reputat periodista nord-americà de la revista Wired i que ha col·laborat en múltiples revistes i periòdics com The New York Times, The New Yorker, Macworld o Rolling Stone i que centre els seus articles i llibres majoritàriament en tecnologia, informàtica, seguretat i privadesa. Doncs bé, aquest és el seu últim llibre, publicat al Juny de 2011.

"In the Plex: How Google Thinks, Works, and Shapes Our Lives", per Steven Levy.

El llibre tracta sobre el naixement i creixement de Google i el que el diferència de la resta de llibres que hi ha del mateix estil és que conté numeroses entrevistes amb els principals treballadors i directius de Google, ja que Steven Levy sempre ha mantingut una bona relació amb l’empresa i els seus fundadors.

A diferència de la biografia de Steve Jobs, de la qual ja us vaig parlar, aquest llibre no es centra en la vida dels fundadors de Google, sinó en l’empresa mateixa. Això sí, degut a totes les entrevistes que va fer el autor i que es publiquen en el llibre, són molts els que el consideren com el llibre oficial de Google.

El llibre està ple de anècdotes curioses sobre els origens de Google i els seus treballadors: Google prové del terme googol (), el quartel general de Google, anomenat Googleplex, prové del terme googolplex (), el valor inicial de l’oferta pública de Google fou de 2718281828 dòlars (que correspon als primers dígits del número d’Euler), com l’esposa de Matt Cutts, el responsable de Qualitat del motor de cerca, va passar a ser coneguda com la “porn cookie lady”, ja que li suggerí al seu marit que premiés amb una galeta cada vegada que algun treballador trobés una pàgina pornogràfica que escapava dels filtres familiars de Google, o com Wayne Rosing, el cap d’enginyeria, el dia que Google va sortir a borsa va advertir-los amb un bat de beisbol a la mà, que destrossaria qualsevol Porsche o BMW nou que trobés al pàrquing de la companyia.

Anècdotes a banda, per a mi la part més interessant és la que narra l’aventura que va suposar obrir el cercador especialitzat en Xina i tots els problemes que això li dugué a l’empresa (el govern xinès va arribar a atacar els servidors de correu de Google per interceptar correus de dissidents, cosa que provocà que Google deixés d’obeir les ordres del govern xinés de filtrar els resultats del motor de cerca). També molt interessant el capítol sobre GMail i de tota la polèmica que va sorgir quan la gent se n’adonà de que eixos anuncis tan encertats, sols podien significar una cosa: Google analitzava el contingut dels correus per posar la publicitat que més s’ajustava a les teves necessitats! I com no, el capítol que descriu el sistema de publicitat en Google (per mitjà de subhastes entre els anunciants), que ha fet de la companyia una de les més profitoses del sector tecnològic.

En definitiva, un llibre molt interessant si eres un poc friki i et pica la curiositat sobre alguns detalls de la companyia. Haig de dir, que la biografia de Steve Jobs em va enganxar més, però és cert que aquella la vaig llegir en castellà i aquesta l’he llegida en anglès, que sempre costa un poc més.

Val, val. M’han fixat com a Software Engineer Intern a Google. Però què vaig a fer allà?

Treballaré amb l’equip OCR (Optical Character Recognition), integrat dins de Google Research, que és l’equip de recerca de la companyia. La missió de Google és:

Organitzar la informació mundial i fer-la útil i accessible universalment.

I això òbviament passa per organitzar la informació escrita en llibres. L’equip d’OCR és un dels que treballa, per exemple, en el Google Books i el seu treball dins d’aquest producte és fer que els ordinadors puguen reconèixer el que hi ha escrit en els llibres. Una vegada sabem el que diu en una imatge escanejada d’una pàgina d’un llibre, podem fer que quan l’usuari cerque informació, no sols li apareguen dades que provinguen de pàgines web, sinó també de llibres. La meva tasca en concret serà millorar una part d’aquest procés.

Els escànners domèstics i aplicacions com l’Adobe Reader o el Google Docs tenen funcions de reconeixement de text des de fa molt de temps. No és l’OCR un problema resolt? En el següent vídeo, Remco Teunen explica quin és el treball que ha fet l’equip de OCR i què és el que li queda per fer. Remco és qui em va fer l’entrevista i qui serà el meu host (Google mai utilitza paraules com boss, supervisor, director, etc). La seva part dura 8 minuts, però si us interessa saber en què treballa l’equip de recerca de Google (Reconeixement de Veu, Traducció Automàtica, Machine Hearing i Machine Perception), us recomane que el veieu complet.

Doncs sí, com ho llegiu! Si res canvia i el govern dels EUA em dóna el visat J-1 que necessite per a treballar allà, el pròxim estiu (del 10 de Juliol al 12 d’Octubre) estaré treballant en la seu central de Google, a Mountain View!

El passat dilluns 12 vaig fer una entrevista amb un investigador de Google Research, a les 19.30h de la nit. Va durar un poc més de mitja hora, més culpa de les meves preguntes que no pas de les seves. Jo vaig eixir amb molt bona sensació de l’entrevista: tenia experiència relacionada amb el projecte, m’agradaven molt els dos projectes que em proposava i vaig saber demostrar-li que tenia els coneixements i la il·lusió per a fer el treball, que és del que es tractava. Unes hores més tard, rebia un correu de RH informant-me de que volien comptar amb mi aquest estiu i que els diguera les dates de començament i acabament de les pràctiques.

Avui, m’han cridat de matí des de Facebook i els he hagut de dir que no podia seguir fent entrevistes amb ells i per la vesprada m’han cridat els de Google per a donar-me tots els detalls sobre el contracte i demanar-me la meva pre-acceptació (encara no he firmat cap contracte, me l’enviaran per correu).

Com podreu comprendre, estic que me’n puge per les parets!  Per a qualsevol informàtic, treballar a Google és com treballar a la NASA o al CERN per a un físic, per a Ferrari per a un enginyer en mecànica, o que sé jo!

No obstant això, l’important no és estar ací o allà, és el que fas en el lloc. La grandesa de treballar a Google no és el propi fet de treballar allà i que tingues menjar i massatges gratis, sinó de tot el que pots fer i el que pots aprendre amb la enorme quantitat de dades i del personal humà que tenen. Quan tens la oportunitat de treballar i aprendre amb la gent que ha escrit els llibres i publicacions que has estat estudiant, amb la gent que marca les tendències en allò que t’apassiona: no pots negar-te, no vols fer-ho.

Fa mig any us descrivia el més prop que havia estat mai d’aquests genis, ara ja estic més prop. Moltes gràcies a tots els que m’han ajudat a assolir-lo i han confiat en mi: als meus pares i la meua germana, a Anna, als amics del poble i la universitat, professors d’institut amb els que he aprés un muntó, professors d’universitat amb els que he aprés més encara (especial agraïment a Moisés per confiar en mi oferint-me una beca quan encara no havia començat ni el 3r curs, i que ha sigut un factor clau) i moltes gràcies també a Ivan que en el seu moment m’ajudà a preparar el CV i em dona un bon grapat de consells.

Ho haig de reconèixer: sóc una persona amb sort, molta sort.

PS: Amb este subidón d’adrenalina, qui estudia ara?!

Ja us vaig comentar en l’anterior entrada els problemes que presenta la cerca dicotòmica amb cadenes ordenades per ordre lexicogràfic per a buscar alternatives a una cerca que conté algun error. Semblava doncs que l’ordre lexicogràfic no era suficient per a establir la relació que jo necessitava entre els noms de les persones, així que la segona idea que vaig tenir és la d’utilitzar la famosa distància de Levenshtein.

Sols comentar que quan estava escrivint aquest post em vaig adonar que tenia un greu error en el meu algorisme, de fet vaig haver de canviar-lo. Això em va servir per a entendre bé aquest nou algorisme que explique ací i millorar alguns aspectes en la implementació del meu programa. Eixe és el motiu pel qual m’ha dut quasi una setmana publicar aquesta entrada.

Avisar-vos també que aquest post és molt més llarg i pesat que l’anterior, això sí, molt més interessant també. Els algorismes que ací descric no són cosa meua i poden haver errors en la descripció de l’algorisme o la seva complexitat. Evidentment, aquest blog no tracta de ser una font de referència i no deuríeu de confiar excessivament en els detalls que s’expliquen ja que poden ser imprecisos o inclús erronis. Si us interessa el tema i voleu informació en la que pugueu confiar més, sols heu de cercar els termes en articles de la Wikipedia o els algorismes en publicacions de Google Scholar.

Fet aquest avís, comencem.

Distància de Damerau-Levenshtein

La distància de Levenshtein mesura la distància d’edició entre dues cadenes de text en termes d’insercions, esborrats i substitucions. Això és, el nombre mínim d’aquestes operacions que són necessàries per transformar una cadena A en una altra cadena B. Si volem comptar també les transposicions com a operacions, la mètrica s’anomena distància de Damerau-Levenshtein. L’algorisme utilitzat per a computar aquesta mètrica és un clàssic de qualsevol curs de programació dinàmica.

Intentaré explicar l’algorisme de manera breu. Imaginem que volem calcular la distància d’una cadena X a una cadena Y. Llavors és construeix una matriu D de |X|+1 files i |Y|+1 columnes. L’element indica quina és la distància de la subcadena a la subcadena . La fila 0 i la columna 0 representen les distàncies de la cadena a i de la cadena a respectivament ( és la cadena buida, aquella que no conté cap símbol).

Doncs bé, la fórmula per a calcular cada element de la taula és la següent.

Ací teniu un exemple de com quedaria matriu per a les cadenes hola i poal.

Si mirem l’element de la taula, veiem que la distància de Damerau-Levenshtein entre les dues cadenes és 2 (transformacion: hola->pola->poal). Fixeu-vos que és menor que la distància de Levenshtein (que no admet transposicions) i que seria 3.

La gràcia d’aquest algorisme és que pot anar construint-se fila a fila i columna a columna, de manera que el cost temporal de l’algorisme per a dues cadenes de longituds m i n és , a l’igual que el cost espacial.

El problema d’aquesta mètrica és el cost: no és lineal. No era una alternativa adequada simplement computar per a cada cerca la seva distància de Damerau-Levenshtein amb els noms de les persones i quedar-me amb aquelles amb un mínim error. Suposant que tenim n persones i la longitud dels seus noms és aproximadament l, el cost temporal d’aquesta cerca seria , un cost massa alt si el comparem amb el de la cerca dicotòmica ().

Millora d’Ukkonen

El primer que hem de tenir clar és que no necessitem saber la distància exacta entre dues paraules. Imaginem que un usuari s’equivoca escrivint la paraula que busca i escriu ocel. Què serà més probable, que l’usuari estigués buscant una paraula que està a una distància 1 (p.ex: ocell) o que estigués buscant una paraula a una distància 5 (p.ex: tomaca)? Realment, sols estem interessats en saber si la distància entre dues cadenes X i Y és menor o igual que un cert llindar k.

Si estem calculant la distància entre dues cadenes i tenim una fila per a la qual, cap element és menor o igual que k, llavors cap element de les següents files serà menor o igual que k.

A més, siga , l’última columna j per a la fila i tal que , llavors quan construïm la fila i sols haurem de fer-ho fins la columna , ja que els elements de les columnes posteriors tindran un valor .

Ací teniu un exemple de com quedaria la matriu per a les cadenes hola i poal, amb un valor de k igual a 1.

Si consultem el valor de l’element aquest sols és vàlid si . Si no és així, sabem que .

Doncs bé, tenint en compte aquesta millora, el cost temporal de l’algorisme es redueix a , segons diu la publicació d’on vaig treure l’algorisme.

Així i tot, no resulta interessant aplicar aquest algorisme sobre tots els noms ja que el cost estaria en . Per a k xicotetes és molt menor que de la idea original, però que encara es pot millorar.

Necessitava tenir els noms de les persones representats d’alguna manera per a estalviar-me treball reduir aquest cost. I ací és on entren en joc els tries.

Trie

Un trie no és més que un arbre de prefixes. El node arrel representa el prefixe de la cadena buida (o ). Cada aresta de l’arbre s’etiqueta amb un símbol de l’alfabet , de manera que el node representa el prefix format per la concatenació de tots els símbols en les arestes des de l’arrel fins a l’esmentat node.

Vegem-ho més clar en un exemple. Suposem que tenim els noms de Alan, Andrew, Leslie, Johan i John. El trie que representaria tots aquests noms és el següent.

Com vegeu, les fulles de l’arbre corresponen al nom complet d’alguna de les persones: allan, john, johan, andrew i leslie (recorreguent l’arbre en amplada).

Un dels avantatges d’utilitzar un arbre de prefixes és que el cost de buscar una persona no depèn del nombre de persones. Amb una cadena de longitud l, el cost de la cerca és . Simplement hem de descendir de nivell en nivell en l’arbre per a cada lletra del nom.

Compressió de camins

El problema dels tries, com ja podreu deduir de la imatge anterior és l’espai que ocupen en memòria. Suposant de nou que totes les cadenes tenen la mateixa longitud l, en el pitjor dels casos, cap de les n cadenes codificades en l’arbre tindrà un prefixe comú i en aquest cas el nombre de nodes és (encara que això sols passar quan ).

A primera vista sembla que no és gran cosa, ja que té el mateix cost temporal que mantenir els noms en un vector. El problema és que necessitem emmagatzemar per a cada node quins són els seus descendents.

Si volem mantenir el cost de cerca , necessitem determinar en cost per quina branca em de descendir quan busquem una cadena. La resposta en aquest cas és evident: Mantenir un vector de punters amb tants elements com símbols té l’alfabet amb el que treballem. Si hi ha algun descendent en el node per al símbol i, el punter apuntarà a aquest descendent. Mentre que si és nul, sabem que no hi ha cap descendent del node actual per al símbol i. D’aquesta manera, el cost espacial de mantenir l’arbre de prefixos és .

El cost ja no és tan atractiu com semblava. Suposem que el nostre alfabet té 26 caràcters (de la a a la z), que tenim 3 milions de persones i la longitud mitjana dels noms és de 30 caràcters. Suposant que els punters són de 4 bytes, com serien en un processador de 32 bits, mantenir aquesta estructura podria necessitar al voltant de 9GB!

Evidentment, en la realitat el nombre de nodes és molt menor ja que els noms sí que tenen prefixos en comú així i tot en la realitat no només tenim 26 caràcters en l’alfabet: els noms de les persones de IMDB inclouen també números, espais, símbols d’exclamació, caràcters accentuats i caràcters d’altres alfabets que no són el llatí (ciríl·lic o grec, per exemple).

Com solucionem aquest problema? En primer lloc, tractant de reduir el nombre de nodes i això pot fer-se fàcilment utilitzant compressió de camins en l’arbre. Què és la compressió de camins? Fixeu-se en el primer arbre que us he presentat. Veureu que molts dels nodes sols tenen un descendent. No seria possible unir en un únic node tots els nodes que tenen un únic descendent? Això és la compressió de camins i aquest trie s’anomena Radix Tree. Veieu com quedaria l’arbre anterior amb els camins comprimits.

Reduint l’espai dels nodes

Una altra millora que pot fer-se per a reduir l’espai és intentar reduir el nombre de punters que s’emmagatzemen en cada node. Havíem dit que si volem mantenir el cost de cerca en necessitem un vector de punters. Però no podem reduir aquest nombre? La resposta és sí, però a costa d’incrementar el cost de cerca.

Una possible millora és emmagatzemar els punters en un arbre de cerca (en el meu cas he utilitzat el map de la STL de C++). Així, en cada node sols s’emmagatzema un punter per a cada descendent i no per a cada símbol de l’alfabet (per tant, no tenim punters nuls que ocupen memòria). Si en un node no hi ha cap punter per al símbol que busquem, llavors no hi ha descendent per a aquest símbol. D’aquesta manera el nombre de punters en cada node es redueix considerablement, especialment a mesura que es descendeix en l’arbre, que és també quan més nodes hi ha. Penseu que és probable que tinguem noms començant en totes les lletres (el node arrel tindrà tants descendents com símbols té l’alfabet), en canvi és poc probable que tinguem molts noms amb el mateix prefix i amb l’última lletra diferent (els nodes de nivells inferiors tindran pocs descendents).

El problema és que ara el cost de cercar una cadena en el trie és , on p és el nombre de punters en els nodes (, normalment prou menor).

Amb totes aquestes millores, el meu programa ocupa ara mateixa 3686MB en memòria, que és bastant menys dels 9GB que comentàvem al començament. Hi ha que tenir en compte a més, que aquests 3686MB no són només del trie sinó també de mantenir els títols de les pel·lícules, el graf que relaciona pel·lícules i actors i tota la informació corresponent a cada persona i pel·lícula.

Comentaré també que em vaig endur una desagradable sorpresa al passar el programa d’una màquina de 32 bits a una de 64 bits: els punters van passar d’ocupar 4 bytes a ocupar-ne 8 i clar, emmagatzemar el mateix arbre necessitava el doble de memòria!

Cerca aproximada

Hem parlat molt de com emmagatzemar eficientment el trie, però encara no hem solucionat el problema que havíem plantejat: fer una cerca aproximada donada una cadena X. Ací és on unim l’algorisme de Damerau-Levenshtein explicat abans i els tries.

Hi ha dos coses importants a tenir en compte a l’hora de calcular la distància de Damerau-Levenshtein sobre distintes cadenes:

1. Al calcular la distància entre la cadena X i la cadena YZ, les |Y|+1 primeres files de la matriu de Damerau-Levenshtein seran iguals a les del càlcul de la distància entre la cadena X i la cadena Y.
2. Si per al càlcul de la distància entre una cadena X i una cadena Y, totes les columnes de la fila |Y| tenen un valor major que k, cap cadena amb el prefix Y estarà a una distància menor que k de X.

El trie permet estalviar temps ja què la matriu de Damerau-Levenshtein va calculant-se iterativament quan descendim en l’arbre, pel que havíem comentat en la propietat (1). A més, tenint en compte la propietat (2), si per a un node la distància a la cadena buscada és major que un cert llindar k llavors sabem que cap dels descendents d’aquest node tindrà un llindar menor, de manera que no hem d’explorar els descendents.

Algunes consideracions sobre les operacions que apareixen en el pseudocodi. L’operació el que fa és actualitzar la matriu D afegint |x| files i computant el valor dels nous elements i el vector C com he explicat en la millora de Ukkonen.

L’operació el que fa es tornar el valor de l’element tenint en compte que potser aquest element no ha arribat a calcular-se en l’operació update. Aquest valor és la distància que hi ha entre les cadenes v i w si aquesta distància és menor o igual que k, o k+1 en cas contrari.

La gràcia d’aquest algorisme és que té una complexitat temporal de , segons l’article que us citava abans. Això suposant que l’arbre de prefixos és complet i que cada node emmagatzema un vector de punters als possibles descendents (és a dir, sense tenir en compte les millores per a reduir espai).

Fixeu-vos que l’algorisme no depèn del nombre de cadenes en el trie! Això significa que podem trobar els noms que més s’aproximen a una cerca feta per l’usuari sense importar quants noms tenim emmagatzemats. Una considerable millora front al cost , això sí, sempre que k siga menuda, perquè el cost creix de manera exponencial amb k!

El gràfic que es mostra ací baix és el temps mitjà de resposta per part de l’oracle quan es busca el nom d’un actor que no existeix en la base de dades. El valor de k que utilitze és . Si usés un valor fixe per a k hi hauria molts suggeriments per a noms curts que realment no tenen massa sentit. Anem al cas extrem: imaginem que un usuari busca el nom a, té sentit suggerir-li els noms b, c, d, etc? La distància a tots ells és 1, però és que la longitud de la cadena era 1! Això significaria que l’usuari ha errat en el 100% de la cadena! Jo permet a l’usuari que s’equivoqui fins a un 25% de la longitud de la cadena. Però si la cadena cercada fos molt llarga el valor k seria molt gran, per això pose un límit al número d’errors a 3.

Dir que l’interval de confiança que es mostra és per a un valor crític del 95%. Crec que el gràfic no mereix més explicacions. El temps de resposta mitjà és de 0.208 segons amb totes les millores comentades. També apareix el temps de resposta utilitzant el càlcul de la distància de Damerau-Levenshtein sense la millora de Ukkonen (0.301 segons).

Encara millor?

Des del primer moment vaig tenir com a referència a Google i el seu “Did you mean…?“. I tenia ben clar que els de Google no podien utilitzar un trie gegantí perquè el vocabulari amb el que treballen és enorme: imagineu totes les paraules diferents que poden haver en la WWW i el que suposaria construir un trie com el descrit!

Google utilitza un enfocament basat en aprenentatge automàtic i processament del llenguatge natural. I aquesta va ser la ruta que em vaig proposar seguir i que us explicaré en el pròxim post.

Mentrestant els tries han funcionat prou bé: són ràpids i sobretot obtenen els resultats que l’usuari espera. I poden ser una alternativa senzilla en situacions amb un vocabulari i un alfabet més reduït. Per exemple, per a construir un corrector automàtic en un editor de textos.

Recordeu l’Oracle de Woody Allen? Ja us he parlat d’aquest xicotet projecte en altres posts, però us refrescaré la memòria. Es tracta d’una senzilla pàgina web que et permet trobar quina connexió uneix a dos persones del món del cinema (actors, directors, guionistes i productors). La idea és que si dos persones han treballat juntes en una pel·lícula, hi ha una distància de separació de 1. De la mateixa manera, Si la persona A ha treballat amb la persona B, i aquesta amb la pesona C, les persones A i C estan a una distància de 2. I així successivament.

No em centraré amb els detalls de com es calcula aquesta distància i la connexió (camí, en terminologia de grafs) perquè no és del que va aquest article, simplement dir que s’utilitza l’algorisme de cerca per amplada.

Des de les primeres versions, volia que el meu programa fora capaç de “tolerar” errades humanes. Per exemple, si un usuari escriu “Wody Allen” en lloc de “Woody Allen”, el meu programa fora capaç de suggerir-li una correcció automàtica. En els següents tres articles comentaré dues alternatives que ha utilitzat el programa per a solucionar el problema i finalment una tercera que encara no he implementat, però que us plantejaré ja que encara queden alguns detalls per polir i amb un poc de sort algú es decideix a aportar alguna idea.

Avise que el contingut de les pròximes entrades és molt tècnic. Per als dos primers articles necessitareu coneixements bàsics d’algorísmica i complexitat computacional, res que un alumne de primer o segon d’Enginyeria Informàtica no puga entendre. Per al tercer, a més, necessitareu coneixements bàsics d’aprenentatge automàtic, que inclou estadística bàsica (bàsicament, teorema de Bayes).

Cerca dicotòmica

La primera tècnica que vaig utilitzar per a proveir de correccions a l’usuari era l’algorisme de cerca dicotòmica o binària.

La idea és mantenir els noms de les persones en ordre lexicogràfic. No vaig a explicar l’algorisme de la cerca dicotòmica, perquè entenc que si heu arribat fins ací el coneixeu.

El que fa l’algorisme és suggerir com a correccions els noms més pròxims (en ordre lexicogràfic) al nom introduït per l’usuari. Per a veure com funciona l’algorisme, suposarem que els noms de les persones són nombres enters. Imaginem que tenim el següent conjunt de nombres en un vector ordenat ( indica l’índex de l’element i el nom de la persona):

Suposem que busquem la persona amb nom 6, llavors l’algorisme s’executaria de la següent forma:

Com que l’últim element considerat () és menor que el cercat, es proposarien com a correccions els elements 5 (posició ) i 7 (posició ). En el cas de que l’últim element considerat fora major que el cercat, es proposarien com a correccions els elements en les posicions i .

Fixeu-se que en cas de no trobar un element, sempre proposarem un element menor i un major. I a més, sempre seran els dos que més s’aproximen a l’element cercat.

El problema és que els noms no són enters i l’ordre lexicogràfic té un xicotet problema: Dos noms als que sols els hem canviat una lletra poden estar molt separats en ordre lexicogràfic. Ací un exemple que il·lustra el problema:

Suposem que en l’anterior situació, un usuari s’equivoca escrivint el nom de Jaume i escriu Jeume:

Llavors, les correccions proposades serien Javi i Toni i cap dels dos és el que l’usuari buscava.

Una possible millora és no sols considerar els dos noms al voltant del cercat, sinó considerar k noms més pròxims en ordre lexicogràfic (per exemple, amb k igual a 3, l’algorisme consideraria Jaume, Javi i Toni). Però aquesta solució no funciona massa bé quan el nombre d’elements en el vector és de més de dos milions i l’usuari s’equivoca en una de les primeres lletres del nom.

No obstant això, l’algorisme és molt eficient en quant a temps i memòria i sobre tot, és molt senzill. Suposant que tots els noms tenen aproximadament la mateixa longitud l, podem expressar la complexitat espacial i temporal (de cerca) en funció del nombre de persones n i aquesta longitud l (la suposició de la longitud l és sols per a simplificar les expressions de la complexitat).

La primera expressió es deriva del fet que tenim n noms i cada nom té una longitud de l caràcters. La segona expressió es deriva del fet que la cerca dicotòmica fa comparacions de cadenes, i per comparar dues cadenes de longitud l necessitem fins a l comparacions de caràcters.

Aquesta senzilla idea fou reemplaçada per una que donava millors resultats cara a l’usuari, però que té un fort inconvenient: l’ús de memòria. L’alternativa que presentaré en la pròxima entrada, és la que està implementada ara mateixa en l’Oracle.

El Firefox m’ha acompanyat des de que un amic el descobrira per allà el 2004 o 2005, en una de les primeres versions (repassant la història del navegador, possiblement seria la 1.0).

Sempre l’he utilitzat, l’he recomanat i l’he defès, i no crec que sense. Fins i tot vaig escriure una entrada fa uns anys quan Google anuncià el Chrome. En aquella ocasió criticava l’actitud de Google creant un nou navegador en lloc de col·laborar en el desenvolupament i perfeccionament de Firefox, especialment quan Google era, i és, el principal mecenes de la Mozilla Foundation (la desenvolupadora de Firefox).

Doncs bé, des d’avui mateix jo també li he donat l’esquena al Firefox. Encara que seguisc pensant que és un navegador excel·lent, fa temps que comença a quedar-se endarrere en quant al rendiment. Van ser famosos els seus problemes amb la gestió de memòria i eren coneguts alguns acudits al respecte entre els cercles més frikis.

Firefox ha millorat molt amb els anys, però quan l’utilitze note que no funciona com deuria. Em consumeix més memòria que el Chrome, la navegació entre pestanyes quan hi ha moltes obertes no és del tot fluïda, la reproducció de vídeos Flash a vegades es “penja”, etc. Encara que els benchmarks que circulen per Internet mostren que Firefox 7 és superior a Chrome 14, la meva sensació és de que em funciona pitjor en el portàtil del que deduisc que potser els problemes que tinc no siguen del Firefox 7 en general, sinó de la seva versió per a Mac OS X.

De moment, he dit adéu al Firefox i m’he posat a utilitzar un altre dels productes de Google. Ja veurem si em convenç o torne ràpid als braços de Mozilla. De moment, ja n’hi ha una cosa que no m’agrada del de Google: el corrector ortogràfic (almenys el català) és una porqueria.

Tot va començar un 12 d’octubre quan em vaig decidir a enviar una sol·licitud a Google per a passar tres mesos d’estiu treballant allí, dintre dels programes de internship que ofereixen. Des d’aquella primera entrevista el 27 d’Octubre fins a l’última que vaig fer aquest mateix dijous ha plogut molt i el procés a passat per distintes etapes. Ací intentaré donar-vos algunes pinzellades de tot i de quina és la meva valoració. Com que acostume a allargar-me excessivament amb les entrades, deixaré ací el resum per als més mandrosos: no treballaré aquest estiu per als de Mountain View.

Comencem pel principi, que se sol dir. Feia molt de temps que em rumiava pel cap la possibilitat de fer unes pràctiques en una empresa d’informàtica “real” (i no com la majoria de les que es troben per ací) i una de les possibilitats era Google. Que no diguen que ens conformem amb poca cosa. Així que gràcies a la inestimable ajuda d’Ivan vaig redactar un currículum vitae concís (un résumé que diuen els nord-americans) i una carta de presentació i la vaig enviar sol·licitant pràctiques a Europa i els Estats Units. Total, que perdia?

Sorpresa la meva quan tan sols tres dies després i havent intercanviat un parell de correus electrònics ja tenia concertada una entrevista amb un dels enginyers d’Europa. Aquella primera no va anar massa bé, però a l’entrevistador li va semblar que algú podria treure profit de mi, així que va passar la meva sol·licitud a una altra oferta diferent de la que tenia assignada en un principi i ací va començar realment tot el procés d’entrevistes.

Abans de Nadal, ja havia fet unes altres dues entrevistes i ja havia completat tot el procés d’entrevistes que determinen si estàs en condicions de treballar allí o no. Sols quedava una entrevista amb algun dels possibles Project Managers i si tot anava bé, a gaudir com a bon geek de l’ambient de Google!

Malauradament, per a les dates que jo estava disponible no pareixia que hi haguera cap projecte disponible per al meu perfil i interessos a Europa. Després de Nadal, em vaig posar en contacte amb la meva recruiter d’Europa per preguntar-li com estava la situació. Ella em va dir que enviarien la meva sol·licitud a Estats Units per veure si trobaven alguna cosa allí, ja que havia passat totes les entrevistes.

No vaig saber res més fins a finals de març quan vaig rebre una trucada telefònica, de nou des d’Europa, dient-me que definitivament no havien trobat res per ací. Pel que em va fer entendre la recruiter, jo ho donava per perdut, però: oh, sorpresa! A l’endemà, correu des de la mateixa seu de Mountain View. Havien trobat dos projectes que s’ajustaven al meu perfil!

Quan em van passar la descripció dels dos projectes vaig flipar. Eren projectes en el mateix departament de Google Research i estaven relacionats amb el reconeixement de formes i l’aprenentatge automàtic, que és al que em dedique en la beca! “Seria tan meravellós que m’agafaren!”, vaig pensar. Però també sabia que seria difícil, ja que al internship també poden optar estudiants de doctorat i aquests s’ajustarien millor als projectes de recerca. Vaig fer les dues entrevistes, una bastant mala i l’altra bastant bona, però ninguna de les dues va prosperar.

Uns dies després, una altra entrevista amb un dels enginyers que treballen en Google Images. Aquesta semblava més assequible a les meves possibilitats. Però, una vegada més, tampoc va prosperar la cosa.

I finalment, el passat dijous, l’última entrevista amb un dels enginyers del Street View. Aquesta va anar prou bé i Rob, que així li deien a l’entrevistador, es va interessar molt per la meva feina de becari i els meus projectes personals. Em va explicar quins eren els projectes que tenia en ment i jo li vaig donar les meves impressions.

Poc després de l’entrevista, i just abans de sortir cap al Palau de la Música per a escoltar el fabulós concert d’Els Amics de les Arts, em va trucar per telèfon el recruiter nord-americà. Em va comunicar que a Rob li havia agradat molt parlar amb mi (“peloteo?”, vaig pensar), però que finalment havia decidit quedar-se amb un altre candidat. Em digué que quedaven encara uns pocs projectes i que es posaria en contacte amb mi de nou per veure si m’interessaven. Jo ja li havia dit que tenia pendent una beca Erasmus i que no podia demorar-me més en decidir quan arribar a Estocolm. I ací és on vaig cometre la imprudència de dir “no” a Google (espere no haver de penedir-me’n mai).

Sóc una persona a la que li agrada tenir les coses clares, i a falta d’un mes per començar les possibles pràctiques o de poc més de dos per anar-me’n a Suècia no semblava adequat seguir fent entrevistes. Tampoc estava especialment animat, tenint en compte que ja havia passat per quatre potencials Managers i no n’havia convençut a cap.

Li vaig dir a que m’havia agradat i interessat molt tot el que m’havien contat els enginyers de Google sobre el seu treball i que em sentia capacitat per tornar a intentar-ho per a l’any següent. Ell em va informar que hi havia la possibilitat de fer les pràctiques a hivern i que estaria encantat de posar-se en contacte amb mi al setembre per continuar amb les entrevistes amb els Project Managers per a passar una temporada a l’hivern. I una vegada més, vaig haver de dir que “no”. A l’hivern jo estaria a Suècia, en ple Erasmus. Però li vaig prometre que em posaria en contacte amb ells per a tornar a fer les entrevistes que calgueren per a quan acabara l’Erasmus.

Amb què em quede d’aquests 6 mesos d’entrevistes? En primer lloc, haver aprés a estar més o menys tranquil en una entrevista de treball (mai n’havia fet cap), en anglès (jo mai havia parlat anglès en una conversa d’una hora de duració) i per a Google! Sobre l’anglès, he tret un lema personal que resumeix la meva experiència: “Saps més anglès del que penses la primera vegada i menys del que t’imagines la segona”. L’explicació, en un altre post.

En segon lloc, que el que estudiem a la universitat definitivament val per a alguna cosa. Jo sempre ho he tingut clar, però són molts els que diuen que el que allí s’ensenya “no val per a res”. Doncs bé xiquets, almenys, val per a passar les entrevistes de Google.

I finalment, l’actitud de la gent de Google. T’expliquen sense cap problema el seu dia a dia (excepte dades sensibles, clar) i els productes en els que treballes i a més amb un to molt amable i simpàtic. I com no, la varietat de nacionalitats que s’ajunten allí: irlandesos, alemanys, suïssos, anglesos, nord-americans, romanesos, indis i xinesos són alguns dels que jo he pogut conèixer.

En fi, tota una odissea mereixedora d’una entrada al blog. L’únic que em deixa amb un sabor agredolç a la boca és estar tan a prop i haver de ser tu qui diga “no”. Finalment, sols un recordatori (per a aquells que com a mi, us cau la bava amb la idea de treballar per a Google) que he procurat fer-me durant aquests mesos: Google és un mitjà, no un objectiu.

I això és el més a prop que he estat mai de Google.

Vaig començar-lo, amb ressaca per l’entrevista amb Google, amb una activitat que organitzàrem des de la Delegació d’Alumnes per a aconseguir nova gent interessada en col·laborar amb nosaltres. Ens reunírem tots els interessats un cap de setmana a un alberg d’un poblet a l’interior de València (Alborache) i allí transcorregueren eixes jornades. Bon ambient i útils, ja que ha servit per acostar sang nova a Delegació, que no diguen que allí estem els quatre de sempre.

Dues setmanes després, XXXIII Assemblea RITSI en Oviedo. Allà que ens n’anàrem tres personetes de la UPV a veure com estava la situació dels nostres estudis a la resta d’universitats, quin era l’estat de la professió i bé, això últim pareix que s’està calmant perquè comencem a adonar-nos que part del que demanàvem(potser el més demandat) és un privilegi injustificat, que qui ara el tenen, molt prompte perdran.

I la setmana passada, en tren cap la capital de l’Estat a “competir” en la fase regional del International Collegiate Programming Contest organitzat per la ACM, què és l’Associació d’informàtica més important i prestigiosa del món, junt amb l’IEEE que ho és de totes les enginyeries. En aquesta fase regional participaven equips enviats per universitats de França, Suïssa, Portugal i Israel (i com no, Espanya). Encara que en principi també entren dins de la SWERC (Southwestern Europe Regional Contest), Itàlia i mitja Àustria. No hi havia cap universitat d’aquests països present.

El resultat final va ser prou desastrós. 25 equips (nosaltres inclosos) sols aconseguiren resoldre 1 problema dels 10 plantejats en cinc hores! Això sí, nosaltres quedarem primers en la sessió d’entrenament i amb això ja en tinguérem prou… Però l’experiència va ser bastant gratificant, a banda de poder trobar-me amb alguns coneguts per allí (dos de la UPC i un de la UM).

I el dimecres, nova entrevista amb Google. La primera entrevista va ser prou desastrosa per a la oferta en qüestió, però com que la part de programari es veu que la vaig fer prou bé, en lloc de pegar-me una patada al cul i tirar-me al carrer, m’oferiren una altra oferta: Software Engineer Intern.

Total, que el dimecres a les 14.00h em cridà un tal Markus (alemany o suís per l’accent) des de Zuric i estiguérem 58 minuts parlant. La meva valoració? Positiva. Vaig saber contestar totes les preguntes i tots els “però” que em posava l’entrevistador (un paio bastant simpàtic, per cert). Així que espere que dintre d’una setmana es posen en contacte amb mi per dir-me si seguisc endavant (més entrevistes) o si “Bye, bye. Hasta otro ratito…”

I el dijous es van celebrar eleccions a delegat de centre en l’ETSINF i des d’ahir que ja no sóc vicedelegat. Després de dos anys intensos, deixe la “cúpula” per dedicar-me a afers més mundans, aliè a tots els embolics de la jet-set i a les mandangues d’alguns que els agrada jugar a ser “importants”.

Això sí, no deixe la representació d’alumnes ni la Delegació. Faltaria menys. Seguiré estant en l’Àrea d’Estudis i en diversos òrgans de govern. Però espere poder anar deixant-m’ho i introduir a nova gent que sàpiga donar-li un poc d’aire fresc a la representació, que ja comença a fer pudor.

En fi, no sé quan, però ja us posaré al corrent de totes les novetats.

Durant aquestes dues setmanes he estat ocultant passant per alt un xicotet secret: avui a les 15.00h tenia una entrevista amb Google. Quasi (gràcies per tot, Ivan) ningú sabia d’aquesta entrevista: ni amics, ni família. I ha sigut així perquè no volia posar-me més pressió damunt (els qui em coneixen ja saben com sóc), volia concentrar-me en l’entrevista.

Des de ja fa temps em ronda pel cap la idea de passar una temporada fent pràctiques en una empresa a l’estranger (res d’Espanya) i sabia que Google ofereix posicions d’Intern en diferents de les seves oficines. Així que em vaig dir: “I per què no?”.

El dia 12 d’Octubre els enviava el meu CV junt a una cover letter utilitzant el formulari que tenen en la seva pàgina web d’ofertes de treball i dos dies després rebia un correu electrònic d’un dels seus University Programmes Specialist.

En el correu em preguntava diverses coses com: quin eren els meus llenguatges de programació preferits, les meves principals àrees d’interés, disponibilitat horària, oficines de preferència per a fer l’Internship, etc.

A l’endemà vaig rebre un correu electrònic que em comunicava que m’havien concertat una entrevista per a la posició de Software Engineering, Google.com Intern en Europa.

Estava súper content perquè pel que havia llegit normalment tardaven prou en atendre les peticions, i jo en dos dies ja tenia una entrevista concertada! Però també estava acollonat, perquè m’oferien una oferta en una posició a la qual no havia enviat petició i tot per una frase dels requisits: “Strong understanding of IP networking, including the ability to analyze network behavior, performance and application issues using standard tools like tcpdump.”

“Oh gosh! Jo no tinc un super coneixement del protocol IP! Com vaig a afrontar l’entrevista? a la primera pregunta estic fora!”

Però bo, ja que m’havien contactat tan ràpidament, no perdia res intentant-ho, així que em vaig posar a indagar per Internet per conèixer més a fons el procés de contractació de Google i a repassar apunts de la Universitat sobre estructures de dades, programació, xarxes i sistemes operatius. Inclús he hagut d’estudiar els apunts de Xarxes del segon quadrimestre!

I com ha anat la cosa? Doncs a les 14.56h m’han trucat des de Dublin per a l’entrevista. Estava molt nerviós, massa nerviós. Mai havia fet una entrevista en angles, és més, mai havia fet una entrevista! El enginyer que m’entrevistava ha notat que estava un poc nerviós i m’ha dit mig en broma: “OK, there’s nothing to be scared! Relax!”. I ha començat les preguntes. Com? Amb xarxes!

Arg! Se m’ha caigut el món damunt. He pensat: “ja la tenim!”. Però bueno, m’havia estat preparant així que m’he dit: “anem a jugar”. Primera pregunta: “quina diferència hi ha entre un hub i un switch?”. Li ho he explicat tant bé com he sabut i semblava prou convençut. Ha seguit amb preguntes de xarxes com: “com sap un switch on enviar exactament els paquets?”. Jo sabia que un switch sols necessita de la capa d’enllaç (protocol Ethernet), així que he suposat que tindria alguna cosa a veure amb el protocol ARP i li he explicat com creia que funcionava. Ell m’ha dit que no era necessari el protocol ARP perquè el switch emmagatzema en una taula la correspondència “adreça MAC – port”, però que tenia bastant clara la diferència entre hub, switch i router.

Bueno, altres preguntes: quin és el rang d’adreces IP reservat a les xarxes privades, com em connecte a un ordinador d’una xarxa privada des de fora d’aquesta, etc. Esta última pregunta ha estat bé, perquè primer li he dit que utilitzant una VPN. Ell m’ha dit que és una opció, però imaginem que no en tenim una configura, li he explicat que en m’ha casa tinc un servidor casolà que funciona fent port forwarding i ha dit que ben pensat, que li agradava la solució i que podria funcionar, però m’ha preguntat si coneixia alguna altra forma i ací m’ha pillat, perquè no he recordat el tunneling! Algunes preguntes més han sigut sobre el funcionament de les ordres ping i traceroute de Linux. Eixes si que les sabia.

Ha seguit amb preguntes de sistemes operatius: què és un procés zombie, què és el que passa quan el pare mor abans que els seus fills, etc. I he anat contestant de les coses que recordava de SO1&SO2.

Després hem passat a les preguntes sobre estructures de dades i ací m’ha tornat a pillar. M’ha preguntat sobre arbres Red-Black Trees, B-Trees i R-Trees (a part de Binary Trees, llistes enllaçades i taules hash). Li he contestat sense problemes els dos últims casos, però dels RB-Trees, B-Trees i R-Trees li he donat una resposta que no n’estava segur. M’ha preguntat si sabia què era un arbre balancejat, i li he dit que sí. M’ha preguntat per quin no era balancejat entre un RB-Tree, un B-Tree i un Binary Tree i li he dit que el Binary Tree i llavors m’he donat compte que havia contestat mal la pregunta anterior (“I see your point“, li he dit), perquè havia dit que en el pitjor cas un arbre binari té cost O(log n), quan en realitat és O(n), que ocorre quan l’arbre està totalment desequilibrat. Li he contestat les dues preguntes de nou i xim-pum.

Després m’ha preguntat quins arbres solien utilitzar-se en les bases de dades per construir els índex i aquesta me la sabia perquè he estat treballant recentment amb MySQL. La resposta és R-Trees i B-Trees. I m’ha preguntat una altra pregunta mortal: I per què no s’utilitzen Red-Black trees? I aquesta si que no l’he sabuda contestar perquè no hem estudiat aquests arbres en la universitat! Però bo, m’ha dit “don’t worry” i m’ha explicat quina era la diferència entre aquests arbres i perquè s’utilitzaven per a les bases de dades (bàsicament perquè no són binaris i són necessaris menys accessos a disc).

Última pregunta “formal”: com crearia una llista a partir d’una altra eliminant els objectes duplicats. La meva solució: utilitzant una taula hash per saber si un determinat item ja l’hem inserit en la llista. Cost temporal O(n) (suposant que la taula hash està ben distribuïda), cost espacial O(n). I m’ha dit: “OK. Perfect.”

M’ha preguntat també si havia col·laborat amb algun projecte open-source i li he dit que com a programador no. Que havia llançat alguns projectes personals de codi obert i que esperava que algun dia algú s’unís a mi. M’ha preguntat sobre algun d’aquests projectes i li he parlat de l’Oracle de Woody Allen. Li he explicat com funcionava, m’ha preguntat sobre els algorismes que utilitzava, etc. “That’s cool!“, ha dit.

Al final m’ha preguntat si tenia alguna pregunta per a ell i li n’he fet algunes com ara: quina era la localització exacta per a l’oferta (Dublín o Zuric), en quins productes de Google estan involucrats els SRE, etc. Sobre la localització no m’ha sabut dir, però ell treballava en Dublín i que segurament seria allí. Després m’ha dit que els SRE (Software Reliability Engineers) en Dublín treballen sobre la infraestructura distribuïda de Google, no en cap producte en particular, però que segurament eixe no seria el treball d’un Intern perquè requereix bastant coneixement de com funciona la xarxa de Google i m’ha contat que un Intern que havia estat al seu càrrec l’any passat havia desenvolupat una aplicació semblant al top de Linux però que funcionava remotament.

Finalment li he preguntat si sabia quan rebria alguna notícia sobre el resultat de l’entrevista i m’ha dit que segurament en un parell de dies rebria un correu del Recruitment Manager donant-me el resultat i segurament convocant-me per a una segona entrevista. No sé si aquesta última part l’ha dita perquè ha quedat satisfet o si simplement ha sigut políticament correcte.

Coses a millorar: no haig de posar-me tant nerviós per a aquestes coses (em tremolaven les mans!), especialment quan no sé la resposta, perquè em limita la capacitat de pensar! En qualsevol cas, ha sigut una experiència gratificant. Ara ja sé com és una entrevista en una gran empresa (Google!), sé que entenc perfectament l’anglès oral i sé que em poden entendre a mi (espere no haver soltat molta espardenyada amb el meu nerviós) i, fins i tot, he aprés algunes cosetes sobre xarxes i arbres!

Sols faltaria que em digueren que passe a la següent fase, això ja seria l’hòstia!

Diuen que quart és el més xungo de tota la carrera. Per a no ser imprudent, no ho negaré, però també diré que el mateix deien de primer quan vaig entrar. El que sí és ben cert, és que en aquest quart curs, a diferència d’en el primer, totes les assignatures són relacionades directament amb la Informàtica, cosa que sempre motiva.

A diferència de tercer, quart torna a ser un curs d’assignatures anuals. De fet, són 4 assignatures anuals de les 6 assignatures de cada quadrimestre: Enginyeria del Programari (IDP), Arquitectura i Enginyeria de Computadors (AIC), Processadors de Llenguatges (PDL) i Xarxes (RDS). Aquestes quatre assignatures són el gros del curs i semblen, a priori de les més interessants. Els noms són bastant descriptius, però per si no us ha quedat clar fan referència al disseny de programari, a l’estudi del maquinari dels computadors, al disseny de processadors de llenguatges formals (bàsicament, compiladors) i a l’estudi de les xarxes d’intercomunicació entre computadors a tots els seus nivells (encara que amb físic pareix que no aprofundirem gaire, al cap i a la fi, això és cosa dels Telecos).

A banda de les quatre grosses, tenim al primer quadrimestre Enginyeria de Requisits (IDR) i Intel·ligència Artificial (IA). La primera fa referència al procés de recollida d’especificacions dels sistemes de programari i en la segona s’estudien algunes tècniques bàsiques d’Intel·ligència Artificial. La segona sembla a priori interessant, la primera crec que serà de les avorrides d’aquest any.

I al segon quadrimestre entraran en joc Enginyeria de Sistemes i Automàtica (ISA) i Aprenentatge i Percepció (APP). La primera tracta d’aplicar la informàtica als processos d’automatització industrial. D’aquest segon quadrimestre crec que m’agradarà més APP perquè està molt relacionada amb la meva beca de col·laboració.

En el segon quadrimestre també tindré una assignatura de cinqué curs que m’he agafat, de la branca de Llenguatges i Intel·ligència Artificial: Codificació de la Informació. Una assignatura on s’explicaran alguns conceptes bàsics de la Teoria de la Informació i Codificació i les seves aplicacions en algorismes de compressió i detecció i correcció d’errors.

Un total de 66 crèdits matriculats, molt per baix de la meva càrrega habitual (de 75 per amunt).

Sé que molts dels que lligen aquest blog ja han passat per aquestes assignatures i sé que molts d’ells se’n riuran al llegir que gaudiré d’assignatures com IDP, PDL o AIC. “Pobre il·lús”, pensaran. Deixeu-me que arribe a odiar-les per mi mateixa, pense jo.

Què espere d’aquest curs? Espere acabar de fer ferms els meus coneixements “bàsics” sobre això que li diem Informàtica en tots els seus àmbits, ja que aquest és l’últim any abans de “l’especialització” que ens obliguen a cursar en l’ETS d’Enginyeria Informàtica de València. Però sobretot, espere gaudir del meu últim any com a estudiant en la UPV i la ETSINF. Dic l’últim perquè tinc intenció de passar un any (o dos) en l’estranger, per acabar els meus estudis. Però en fi, d’això ja en parlarem.