Wednesday, 14 January 2009
Tuesday, 13 January 2009
usor off topic, despre indexare
Indexarea e modalitatea de a stoca informatie intr-un mod organizat, principalul obiectiv fiind extragerea informatiilor din index intr-un timp optimal. Unde se foloseste ? Peste tot ! Google news de ex. De bun simt e ca daca ai multe cautari de stiri, nu stai sa crawlezi tot netul pentru fiecare cautare, e mai "cinstit" sa faci asta o singura data, informatiile sa le pastrezi cumva structurat, diminuand extrem de mult timpul de cautare.
Cum ar trebui sa arate un index ? Depinde extrem de mult de modalitatea de cautare a informatiei. Exista mai multe tipuri de cautare (de ex keywords, fraza, cautare booleana, cautare cu expresii regulate, etc), stabilirea modului de cautare influentand structura indexului. In general indexul ca structura de date e un Hashtable, key fiind cuvantul, value fiind un obiect ce ar trebui sa descrie dependintele intre acel cuvant si toate documentele in care apare, pozitiile in care apare in fiecare doc, etc. Acest value e influentat de modalitatea de cautare.
In general intr-un index nu sunt tinute valori de tip text. Pentru optimizare la comparare, se folosesc hashcode-uri, cautarea pe int-uri fiind mult mai eficienta. Cuvintele care sunt indexate sufera o serie de prelucrari. Se aplica algoritmi de eliminare caractere nerelevante(".", ",", ";", etc.), eliminare de stop words, stemming, lemmatisation, etc. Stringul rezultat va fi codificat la int si retinut in index. Algoritmii prezentati reduc dimensiunea textului ce trebuie indexat la ceva considerat "relevant". De exemplu, regula celor 30 spune ca din 30% din cuvintele cu cele mai multe aparitii dintr-un document, 30% sunt cuvinte cheie (stop words), cuvinte cu relevanta mica la cautare.
De asemeni, pe partea de value in hashtable pot fi mai multe abordari. Documente sunt tinute fie sub forma de liste, obligatoriu sortate, pentru ca la cautarea a 2 cuvinte de ex, rezultatul ar trebui sa fie intersectia listelor de documente in care apare fiecare cuvant, intersectia pe 2 liste sortate facandu-se in O(m+n) fata de O(m*n) pentru liste nesortate. Tradeoff pentru listele sortate e dificultatea la adaugare si stergere, listele trebuie resortate dupa fiecare operatie de acest fel. O alta varianta ar fi folosirea unor arbori (binari de cautare, rosu-negru, etc.), adaugarea si eliminarea unei intrari rebalansand arborele, iar cautarea facandu-se rapid. Mai greu de implementat si cu mai multe resurse in memorie.
usor off topic, dar sper interesant :)
A few insights on Web pay-per-click advertising
Pentru cei care nu stiu inca in ce consta metoda (inainte de citirea articolului si eu ma numaram printre ei :)) o sa incerc sa le ofer o explicatie succinta. In linii mari, totul arata cam asa: administratorul unui site T (target site) accepa sa plateasca un alt site R, care ii face publicitate, cu o anumita suma de bani direct proportionala cu numarul de click-uri pe care utilizatorii care intra pe site-ul R il dau pe bannerele publicitare care ii redirecteaza catre T. Prin urmare, "gsp.ro" primeste bani de fiecare data cand tu dai click pe bannerul care te anunta de ultima oferta de la Orange sau de existenta unui showroom now in Bucuresti.
Si aici intervine partea interesanta! Studiile au aratat ca in general, rata click-urilor pentru bannere publicitare este una foarte mica, de doar 1-3%. Pana la urma tu ai vrut sa afli ce a facut Steaua la ultimul meci si nu te intereseaza sa-ti cumperi o combina frigorifica chiar daca aceasta este la incredibilul pret de XXX RON!! Rata fiind atat de mica, si pretul pentru fiecare click este calculat in consecinta. De aceea R este interesat sa produca cat mai multe cereri catre T pentru a-si imbunatati click-rate-ul si poate incerca sa realizeze acest lucru si prin metode mai putin "cinstite".
Cea mai simpla abordare ar fi ca administratorul lui R sa ruleze un program care emite periodic cereri catre T sub forma unui click fictiv. Ideea este insa ineficienta, deoarece, in cele mai multe cazuri administratorul lui T va stipula in contract o clauza conform careia alege sa plateasca doar pentru cereri cu IP-uri unice. Bineinteles, un atacator mai sofisticat poate incerca sa pacaleasca sistemul si de data aceasta, generand cereri cu IP-uri diferite. Metoda presupune un efort suplimentar, este mai dificil de implementat si de cele mai multe ori poate fi detectatata usor de catre T. Si asta deoarece, in majoritatea cazurilor nu va exista nici un browser la celalalt capat al conexiunii care sa primeasca raspunsul lui T. Administratorul lui R nu este interesat de continutul paginii "pageT.html". Iar daca aceasta contine si link-uri catre imagini sau alte elemente HTML, link-uri pe care un browser web le-ar interpreta in consecinta, atunci o cerere pentru "pageT.html" nu va mai fi urmata si de o alta cerere pentru elementele HTML continute in aceasta. Prin urmare, administratorul lui T poate afla daca cererea este sau nu valida si poate lua masuri.
Din aceasta cauza, poate una dintre cele mai utilizate metode de "pacalire" a site-ului target folosite azi este aceea de obligare a user-ului sa aceseze "pageT.html" prin realizarea unei pagini "pageR.html" care sa creasca click-count-ul de fiecare data cand un nou utilizator ajunge aici. In plus, intregul proces poate fi ascuns utilizatorului, care nu va afla niciodata ca este folosit de R pentru a obtine recompense financiare de la T. Dar, chiar daca atacurile sunt sau nu vizibile utilizatorului, si acestea pot fi depistate de administratorul lui T daca acesta hotaraste sa-si inspecteze colaboratorii. Daca admin-ul lui T intra pe site-ul lui R el va descoperii frauda si poate actiona in consecina, rupand contractul cu R pentru a-si cauta un partener mai serios.
Si acum, pentru ca am salvat ce este mai bun pentru final, pot sa afirm ca exista si o metoda de generare a click-urilor fictive care este imposibil de detectat de catre administratorul site-ului target. Metoda presupune existenta unui site suplimentar S cu care R sa colaboreze. Procedeul este simplu si inglobeaza 2 click-uri simulate: in momentul in care un utilizator face o cerere pentru "pageS.html" , S trimite un click fictiv catre R care la randul sau va genera un click pe baza celui primi de la S pe care il trimite lui T. Ultimul click are menirea de a-l pacali pe acesta din urma facandu-l sa creada ca S este sursa cereri => metoda de generare este destul de complicata, dar realizabila. In plus, atacul are si "avantajul" ca face site-urile target susceptibile la "spamming" indirect (daca prin contract R este obligat sa nu foloseasca spamming-ul pentru a-si mari click-count-ul, acum o poate face mascat, prin intermediul lui S. Administratorul lui T nu poate sa demonstreze ca exista o legatura intre S si R si prin urmare nu-l poate acuza pe R de practici necinstite).
Totusi, atacul are si unele "dezavantaje": este complet nefolositor in cazul advertising-ului de tip pay-per-sale (utilizatorul trebuie sa si achizitioneze unul din item-urile expuse la vanzare pe site-ul target) sau pay-per-lead ((utilizatorul trebuie sa aiba activitate suplimentara pe pagina pentru ca click-ul sa fie validat). Si avand in vedere ca siguranta advertisementului de tip pay-per-click poate fi sparta foarte usor, tot mai multi utilizatori isi indreapta atentia catre celelalte 2 metode de publicitate ...
Monday, 12 January 2009
Cate ceva despre web crawling
Partea care mi-a revenit mie a fost cea de crawl-are a paginilor de stiri si de extragere a a link-urilor stirilor si apoi de obtinere a continutului stirii ( eliminand tot ce nu tinea de stirea in format text - filmulete, poze, link-uri catre alte stiri, mesaje publicitare etc): de aceea am ales drept topic al acestui articol crawl-area pe internet.
O definitie pe care o puteti gasi pe wikipedia zice ca web crawler-ul este o aplicatie care face cautari in lumea WWW intr-o maniera automata pentru a aduna un anumit tip de informatie - actiunea in sine poarta denumirea de web crawling sau spidering. Site-uri care utilizeaza crawl-area pe internet sunt in special motoarele de cautare precum google. Evident, crawl-area in sine nu prea este utila daca nu se face ceva cu informatia adunata, cel mai adesea ea fiind indexata pentru a putea fi accesata intr-o maniera eficienta mai tarziu.Crawl-area este folosita si in spam-uirea utilizatorilor: pentru a aduna adrese de e-mail pe care vor fi trimise apoi tot felul de mesaje publicitare, de promovare a diverse site-uri sau produse ( chestiile din e-mail pe care multi dintre noi le sterg instant).
Cum functioneaza un Crawler?
Principial, trebuie sa existe un link sau o lista de link-uri de la care sa se plece: paginile asociate vor fi parsate, prelucrate si se vor extrage de aici anumite informatii, dar si link-urile care ne pot duce catre alte site-uri care sa fie prelucrate in aceeasi maniera - daca se doreste o crawl-are in adancime, altfel se poate rezuma totul la prelucrarea paginii principale. In cazul nostru s-a plecat de la 2 site-uri de stiri si s-au adunat continuturile stirilor - titlu + text, dar se pot extrage adrese de e-mail , preturile anumitor produse, review-urile unor filme - depinde de scopul aplicatiei + paginile din site unde putem gasi link-uri catre alte stiri. Am gasit un articol de la sun unde se spune ca de obicei crawler-ele ruleaza pe o singura masina si sunt mai putin inteligente decat virusii spre exemplu: un crawler pur si simplu trimite o cerere http pentru a obtine informatii de pe alte masini din Internet - la fel cum fac browser-ele web atunci cand introducem adresa unei pagini.
Lucrurile par nu foarte complicate, dar sunt anumite aspecte asupra carora ar trebui sa se insiste:
- trebuie sa existe o politica de selectionare a informatiei ce prezinta interes;
- pe de alta parte internet-ul este intr-o continua schimbare si ceea ce gasesti astazi pe o pagina se poate schimba in urmatoarea zi in mod considerabil( iar stirile pot fi updatate la fiecare ora sau la un interval relativ mic de timp) - trebuie stabilite niste criterii pentru recrawl-are;
- crawler-ul trebuie sa fie "politicos" si sa tina cont de anumite aspecte cum ar fi ca un anumit site nu poate primi mai mult de 1000 de cereri HTTP de la acelasi IP intr-un intervar de 30 secunde sau ca este indicat sa nu fie adunate informatii de pe anumite pagini - chestiile astea sunt mentionate in fisierul robots.txt ( mai multe detalii aici).
Monday, 22 December 2008
JavaScript în Tema3IE
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
(Post-ul ăsta a apărut şi pe blogul meu personal)
Tuesday, 2 December 2008
Prezentarea etapei a 2-a a proiectului
Monday, 24 November 2008
despre citrix
citrix e o firma de meseriasi specializata pe servicii de virtualizare si acces remote.
ideea de la care a plecat firma era incercarea de a oferi servicii (in principiu ms) intr-o interfata primitoare, prin intermediul netului. sa poti sa ai acces la "calculatorul tau" indiferent la ce calculator ai lucra. explic indata :)
printre certuri si impacari cu ms, s-a ajuns la un consens ca citrix sa poata folosi sursele de win (pana la 2003) pentru implementarea unui "enhanced win" numit initial WinFrame, mai apoi XenApp.
aplicatia este un serviciu remote care permite userilor sa ruleze aplicatii win (notepad, outlook, office, etc) de pe orice conexiune la net. Virtualizarea calculatorului personal se face pe server, a.i. eu sa pot accesa datele personale de pe pc, smart phones, etc. intr-un mediu securizat.
aplicatia a avut asa amploare incat a fost adoptata ca mediu de lucru de mai multe universitati.
watch this video: