Pe drum spre casă

Am fost acum câteva zile în Maica Domnului (pentru cine nu ştie, MD este o stradă în Bucureşti unde sunt concetrate magazinele de piese electronice & accessories), să-mi iau prostii (aveam nevoie de un multimetru, de nişte mufe, prostii de-astea). Ce contează în postu ăsta este că m-am lovit peste un mini trepied (de-ăla de 30 de cm) la reducere (20 de lei) şi mi l-am luat instant. Azi am avut prima ocazie să-l testez pe el şi noua mea cameră pe care am primit-o de la mama de Crăciun, pe drum de la şcoală spre casă:

Nişte bănci de beton pe lângă Transporturi
Nişte bănci de beton pe lângă Transporturi
Locul unde acum aproape 5 ani îmi căutam numele pe listele cu admişi. Era acolo, cam la roata tomberonului. Ultimul.
Locul unde acum aproape 5 ani îmi căutam numele pe listele cu admişi. Era acolo, cam la roata tomberonului. Ultimul.
Pe unde o sa fug pe seară :P
Pe unde o sa fug pe seară :P

Proiect IE

Proiectul de semestru la IE a constat în realizarea, în echipă, a unui site web care să prezinte activitatea unei firme / unui grup fictiv care îşi desfăşoară activitate în domeniul interfeţelor web. Până aici, simplu. Partea interesantă a fost că proiectul urma să fie punctat nu doar în funcţie de cum arată / cum satisface cerinţele punctuale, dar şi în funcţie de ce trafic web atrage, şi pe ce poziţie se află pe Google la o căutare după „interfeţe web”.

Cred că e în spiritul general al tipului de oameni care merg la genul ăsta de facultăţi (şi NU sunt legume) să se bage în competiţii (ştiu, sunt multe legume). Şi cum competiţia s-a prezentat singură de data asta, concurenţii n-au stat pe gânduri. Cam în acelaşi timp în care ne era prezentată tema de proiect, interfeteweb.com a fost cumpărat de unul din colegi. În următoarele două săptămâni, cei care s-au chiar interesat de proiect au vânat rapid cele mai multe domenii ieftine de cumpărat cu cuvintele interfete şi web. Noi, deşi eram relativ conştienţi de bătălia ce se dă, ne-am mişcat un pic mai târziu, dar am avut decizia şi banii să cumpărăm interfete-web.eu cât timp mai era liber.

Din păcate, pentru că am ales (nu ştiu de ce) să trecem printr-o firmă din România în loc să plătim live pe net cu cardu la cineva, deşi făcusem rezervarea, cineva mai ager a şi plătit înainte să putem noi să confirmăm ceva, deci am rămas fără domeniu aşa, la mustaţă (până la urmă am aflat că echipa lui Bogdan Zaharia a fost cea care ne-a luat domeniul). Evident, asta a însemnat recurgerea la soluţii de criză, şi astfel s-a născut interfete-web-beton.eu.

Ce a fost foarte ok pentru noi, care suntem crescuţi în proasta mentalitate de „totul se face în ultima clipă posibilă în care se poate face, sau chiar şi mai târziu” a fost că proiectul a impus nişte etape, ceea ce a însemnat că a trebuit să fim mai organizaţi. Pe lângă site, trebuia să întreţinem şi un blog, şi să postăm şi acolo, dar să scriem şi articole pe site, ca să generăm trafic. Soluţia pe care am găsit-o a fost să folosim Google Data API şi sa punem pe site dinamic toate chestiile ce le-am postat pe blog (şi cu ocazia asta am observat şi eu una alta despre Google Data API).

Ne-am promovat site-ul prin statusuri de messenger, şi se pare că avem muuulţi prieteni pentru că am avut foarte multe vizite. O vreme, chiar şi Google ne-a plăcut, chiar şi cu concurenţa puternică a unor colegi mai „strong”, eram undeva pe pagina 2, dar chiar înainte de prezentare am ajuns undeva pe poziţia 168 (nici noi nu ştim de ce).

Mai multe informaţii despre rezultatele proiectului sunt în prezentarea pe care am susţinut-o (cu mai mult succes ca cea de la CI), şi, evident, pe site.

hm2

Tema 4 IE

Am scris un pic înainte despre Tema 3 la IE, aia cu highlighter pe text (care, în tentativa de a o face mai „cool” am buşit-o). Ultima temă la IE a fost creearea unei interfeţe pentru o aplicaţie fictivă care caută în log-uri de diferite tipuri de clienţi de IM. Aplicaţia trebuia să aibă un screen de setări, configurabil (conturi / rezultate pe pagină) şi un screen pentru căutare, cu posibilitate de căutare simplă şi căutare avansată (după tip şi după dată).

Partea interesantă a fost că tema a dat mână liberă la metoda de implementare: putea să fie browserbased sau standalone sau whatever, java, javascript, c#, pygtk, ce-o fi. Eu am reuşit să mă apuc de temă după ce am încheiat ultimele modificări la site-ul pentru proiectul la IE (despre care o să scriu mai încolo), deci pe la vre-un 5AM. Prezentarea trebuia făcută la 10AM, odată cu predarea proiectului, deci nu era foarte multă vreme la dispoziţie.

Am ales să o fac în Javascript / PHP pentru că îmi era cel mai la îndemână, dar omg cât de urât am fost obligat să codez din lipsă de timp. Rezultatul final a trecut „testul” (cu toate că au existat dezbateri dacă aplicaţia chiar trebuia să facă o filtrare de date phony sau putea să afişeze orice), adică implementa în mare facilităţile cerute, chiar dacă ultimele chestii le-am făcut pe scări la EG-uri în faţa laboratorului şi chiar în timpul prezentărilor. Trebuie să spun aici ca am „furat” de la micvs ideea cu logourile aplicaţiilor de IM în interfaţă :P.

Rezultatul final e aici, dacă vreţi să aruncaţi un ochi. [notă: evident că am sfeclit ceva pe-acolo când am făcut versiunea de pus pe site, deci probabil are bug-uri].

hm

News Search Engine / Proiect CI

CI este singura materie de an 5 pe care o fac toţi studenţii, indiferent de specializare (though, în funcţie de ce specializare ai, ai un alt profesor). Presupun materia asta are numele pe care îl are ca să ofere flexibilitate şcolii în a pune acolo conţinutul pentru care are profesori la un moment dat, but this is just a wild guess. Motivul care mă face să zic asta este că materia se ocupă cu Information Retrieval, şi numele ei n-are-a face cu asta.

Anyway, întâmplarea fericită a făcut ca specializările C1 şi C2 (eu sunt la C1) să îl aibă ca profesor pe first-time appeareance Paul Chiriţă, care e un meseriaş în domeniu şi care a lucrat pe la tot soiu de meseriaşi (like Yahoo) şi care acum s-a întors în Bucureşti şi lucrează la Adobe. Anyway, cursu a fost interesant, am şi reuşit să merg la câteva, dar era lunea, la 8, în Leu, ceea ce nu este prea compatibil cu mine :).

Am ales, împreună cu Gia, Micvs şi Miki să alegem calea interesantă şi să facem un proiect (alternativa era un referat). Evident, materia a început în octombrie, noi am aproximativ ales tema prin noiembrie şi am avut prima întâlnire pe 17 decembrie, cand deadline-ul era 12 ianuarie. Tema pe care ne-am ales-o a fost un news search engine, adică partea de crawl (spidering), partea de indexare, partea de gestiune a queryurilor, şi chiar şi o interfaţă de test.

Contribuţia mea la proiect nu a fost atât de mare pe cât mi-aş fi dorit, şi am ajuns la Bucureşti la aproape o săptămână dupa ce Micvs şi Gia s-or apucat deja de treabă, dar totuşi sper ca am ajutat :).

So, un pic despre proiectul nostru: ne-am propus sa re-inventăm roata ca să ne dăm seama cam cum era făcută, aşa că părţile esenţiale le-am facut de la 0. Motorul nostru de căutare de ştiri este scris în Java, şi foloseşte RMI între diferitele module (web-crawler, indexer, clienţi) şi JDBC cu baza de date în care menţinem un cache. Practic, ce ne-am pornit la drum să facem a fost o reinventare a roţii (sau, ca să citez din ceva ce-am citit pe net: ce rost are să te apuci să reinventezi roata, hai să reinventăm motorul – de căutare :P).

Crawlerul nostru este antrenat acum pe două site-uri: bbc.co.uk şi theguardian.co.uk. Am mers pe conţinut în engleză pentru că e mai uşor de găsit, mai corect format şi stufos decât ce găseam în română, dar mai ales pentru că anumite componente ale unui SE (stemming, spre exemplu) funcţionează ca în teorie când le aplici pe limba engleză. Practic, un „spider” porneşte de la site-ul principal, şi găseşte link-uri către categoriile principale ale site-ului, de unde obţine linkuri către ştiri. Se extrage textul şi titlul ştirii din pagină (cu o expresie regulată, pentru fiecare site), şi se trimite, printr-un apel RMI, server-ului de indexare. După ce termină toate linkurile, se semnalizează server-ului că s-a încheiat parcurgerea site-urilor şi crawler-ul este apelat din nou după câteva ore.

Serverul de indexare întreţine, evident :), un inverted index. Index-ul este reprezentat în memorie ca un hashtable, în care cheile sunt hashuri (int) ale cuvintelor trecute printr-un stemmer simplu de limbă engleză, şi valorile sunt liste înlănţuite de referinţe la documente şi un vector de apariţii (poziţii în document în care apare cuvântul respectiv). De fapt, se menţine câte un vector de apariţii pentru titlu, conţinut şi sumar.

În timp ce primeşte toate ştirile dintr-o „transmisie”, serverul foloseşte un pachet numit classifier4j pentru a calcula asemănările între două texte pe care le primeşte. Dacă asemănările sunt prea mari ( > 95%), ştirea este considerată duplicată şi se ignoră. Dacă ştirea seamănă în proporţie > 80% cu un text, se consideră ca este despre acelaşi eveniment sau aceeaşi serie de evenimente ca şi ştirea cu care este comparată, astfel făcându-se clustering bazat pe evenimente. Comparaţia se face folosind un motor care se foloseşte de teorema cosinusului într-un vector space de cuvinte (classifier4j mai poate folosi un comparator bazat pe teorema lui bayes, dar nu ştiam despre ce era vorba şi era mai complicat de folosit pentru ce voiam noi). La indexing-time se mai calculează şi un sumar static al textului, reprezentat din cele mai importante două propoziţii din text (calculate şi ele folosind un algoritm bazat pe teorema cosinusului aplicată pe spaţiul documentului respectiv). La fiecare indexare, cache-ul este înlocuit (în mod sincronizat) cu cache-ul nou.

Aspectul la care micvs a insistat la construirea indexului a fost performanţa: parsări minime ( = 1) a oricărei liste, oricărui string, şi optimizări pentru tratare de queryuri, în detrimentul performanţei indexării, dacă a fost cazul.

Pentru tratarea query-urilor, server-ul primeşte de la aplicaţiile client o listă de cuvinte cheie, printr-un apel RMI. Serverul foloseşte inverted index-ul pentru a găsi documentele care conţin cuvintele respective, şi aceste liste sunt apoi intersectate. Fiecare document primeşte o notă, la query-time, bazată pe numărul de apariţii a cuvântului în textul documentului şi pe existenţa sau absenţa cuvântului căutat în titlu şi în sumarul documentului. Dacă căutarea se face după mai multe cuvinte, nota se acordă şi în funcţie de apropierea în cadrul documentului între cuvinte (adică e mai relevant un document care contine termenii de căutare mai apropiaţi – în special unul lângă celălalt).

Pentru prezentare, miki a lucrat la o interfaţă în java, aşa, de POC (proof of concept) ca să putem să arătăm cum se obţin rezultatele şi cum se grupează. Pe mine m-a ros nonstop faptu că nu am făcut ceva webbased pentru căutare, că pentru mine făcea mai mult sens să fie webbased, aşa că, după predarea proiectului, m-am jucat un pic, pentru prima dată ever cu nişte Servlet-uri. Promit că dacă o să chiar termin ceva o să le pun la mine pe site să le poată testa cine vrea :).

Oricum, a fost un proiect instructiv, şi, pe cât îmi displace mie Java, trebuie să recunosc că munca în echipă e mult mai clar definită când se programează în limbaje gen Java. Proiectul ăsta a fost şi primul proiect la care am reuşit să-i conving pe ceilalţi să folosim SVN pentru controlul codului, ceea ce pentru mine a fost o reuşită personală.

Partea mai puţin reuşită a fost prezentarea efectivă a proiectului, unde am mers direct după o noapte nedormită cu o prezentare încropită şi un proiect semi-finalizat. M-am bâlbâit nonstop la prezentare, şi când i s-o terminat la Gia bateria de la laptopu de pe care prezentam I froze. Evident, se pare că prezentările astea erau oarecum mai puţin colegiale şi mai mult „oficiale” aşa ca mi-am luat bobârnacu necesar peste nas, dar îl meritam pentru că am mers, într-adevăr nepregătit pentru o prezentare.