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.

Back from one leg land

Vacanţa de iarnă e de obicei pentru mine un moment deosebit de destindere, de reîntâlnire cu prieteni, de mers la munte, la ski … Anul ăsta nu s-a apropiat de nimic de genul ăsta. Aveam o problemă mai veche la piciorul drept (pentru prieteni, „Creierul”) şi îmi propusesem să o repar în 2008 (asta e o problema pe care o am de minim 8 ani), ceea ce s-a şi întâmplat. Faptul că am fost şchiop două săptămâni după operaţie efectiv m-o scos din uz, pentru că parte din procesul de gândire la mine înseamnă plimbatu din stânga-n dreapta cu pixu-n gură.

Singurul lucru care l-am făcut cu adevărat vacanţa asta a fost să dorm. Mult. Prea mult. Atât de mult încât creierul meu a devenit o murătură.

Mi-a fost foarte greu să îmi revin la timp să trimit tema 3 la LPD, şi nici după săptămâna asta de presesiune nu mă simt complet în formă. Dar am făcut şi am văzut lucruri interesante, şi pentru mine asta e întotdeauna un lucru care mă entuziasmează. O să scriu în posturi viitoare despre aventurile programatice cu webservices, cu freakin’ java, cu o interfaţă pentru o aplicaţie scrisă cu php şi js în quick & dirty mode, cu un motor de căutare de ştiri scris de pe la un 0 în java, cu un pic de yPHP, cu noi experiente prin C# …

Colinde pentru părinţi

Vă ziceam de curând că exploratorii noştri vor cânta la biserică colinde pentru părinţi. Azi la 18 s-a întâmplat chestia asta, şi din ce am văzut, am auzit şi mi s-a povestit, a ieşit nemaipomenit. Au fost acolo şi explo, şi temerari şi lideri şi seniori. Evenimentul a avut loc la biserica din centru (a domnului preot Vanca). Vă las în compania cercetaşilor de la Alba Iulia :) :

meeting JavaScript

Tema 3 la Interfeţe Evoluate ne-a cerut să scriem, folosind Javascript pentru scripting, un webbased thingie care sa faca highlight pe cuvinte / fraze dintr-o pagina web, încărcată dinamic (eventual folosind Ajax). Ceva foarte simplu, menit să ne familiarizeze, presupun, cu Javascript.

Eu fug de Javascript încă de la începuturile experimentărilor mele web-astice, pentru ca ce am văzut atunci arăta foarte foarte aiurea pentru mine. E drept, cred, ce se spune despre Javascript, că e un limbaj Ok de scripting, dar care e folosit în cel mai hidos mod. Acum ceva vreme era folosit pentru nenorociri de-alea de animaţii de prost gust, ceasuri ascii care fug după mouse şi alte nenorociri care nu au ce căuta într-o intefaţă bună.

Acum vedem însă tot mai puţine utilizări negative (cel puţin din punct de vedere vizual) a Javascript, şi tot mai multe exemple pozitive. Nu ştiu exact istoria, şi sunt sigur că o călătorie scurtă pe wikipedia vă poată lămuri mai bine ca mine, dar eu cred că Javascript a început să devină widely accepted ca un limbaj de scripting serios odată cu trecerea la Web2.0, care, printre alte calităţi, se defineşte prin interfeţe web mult mai responsive. Dezvoltarea Javascript-ului ca limbaj a permis Web2.0 să existe, şi, la fel, nevoia de creştere a calităţii interfeţelor a dus la dezvoltarea limbajului. Cele mai populare trăznăi ce le folosim azi, Gmail, Y!Mail, Noul WordPress, dar şi vechiul, aproape tot ce e Google-ish, toate folosesc la greu Javascript.

De ce avem aşa super nevoie de Javascript? Well, înainte de web2.0 şi de toată nebunia cu superinterfeţele web, problema comunicării cât mai responsive cu clientul se putea rezolva în două moduri. Prima strategie era cea locală (client-side scripting): aveai un script care încărca totul în pagina curentă, în javascript, şi atunci puteai interacţiona cu utilizatorul (să validezi date, să îi dai nişte opţiuni diferite în funcţie de alegerile pe car ele face …) într-o manieră limitată la informaţiile care existau la încărcarea paginii. Şi cum să trimiţi toate posibilităţile înseamnă cantitate mare de date şi cantitate mare de date e un big no-no pentru interfeţe web, interacţiunea era limitată.

A doua strategie (server-side scripting) implica de cele mai multe ori reîncărcarea paginii şi procesarea opţiunilor cu server-ul. Necazul era că şi pe legăturile rapide (gen intraneturi) se observa reîncărcarea paginii, iar pe legăturile lente (sau no, normale) asta devenea o problemă serioasă.

Toate problemele astea au primit o soluţie unică, elegantă şi foarte foarte folosită azi de toate aplicaţiile web ce le folosim frecvent: AJAX. Asynchronous Javascript And XML. Deşi tehnologiile care fac AJAX posibil există de prin 95, W3C a propus un draft pentru chestia asta doar în 2006. Ideea e relativ simplă, AJAX se bazează pe un obiect Javascript  (da, JavaScript e şi OO :P) care face o cerere HTTP către un server şi înregistrează un handler (o funcţie) care se apelează în momentul când cererea întoarce ceva sau dă un timeout. Răspunsul cererii se presupune a fi un XML, deşi din ce am încercat eu se poate folosi şi HTML ca răspuns, dar nu sunt sigur de alte tipuri de date.

Avantajul cel mare e că toată bucătăria se întâmplă în culise, utilizatorul are o experienţă fluentă, care seamănă cu experienţele cu interfeţe ne-web. Există şi limitări. Deşi, teoretic, se pot cere fişiere oricât de mari, având în vedere că totul se întâmplă peste un mediu care are performanţe variabile indiferent de locaţie, se preferă ca răspunsurile să fie minime. O limitare de securitate care am observat-o (nu ştiu exact când a fost introdusă) este că cererile XMLttpRequest (obiectul de care vă ziceam) nu pot fi făcute decât către serverul de la care a fost încărcată pagina care execută scriptul.

Desigur, problema asta se poate rezolva urgent cu un urlfopen pe partea se server, şi asta e mirific la AJAX, posibilitatea de a trece peste limitările iniţiale impuse de modelul Web prin pasarea lor către partea celalată (client <-> server).

Anyway, pentru cine este interesat, tema mea 3 la IE este aici. Si, ca sa o testati, puteti incerca sa folositi pagina asta şi asta :)

Am devenit mult mai interesat după tema asta să investighez mai îndeaproape JavaScript şi, mai ales AJAX pentru yPHP (pentru început, un modul de formuri dinamice şi de verificare a formurilor pentru început :P). Vorbind de tehnologii, am înţeles că jQuery (ăla de aici, nu ăla care ţine de baze de date şi Java) e util. Are cineva vreo experienţă cu trăznaia asta? I will give it a try, and post here on the results :)