WebBiz

Estimare rata clickuri pentru reclamele online

Deoarece plata se face la numarul de accesari a unei reclame ideea este ca cele mai bune sa fie afisate primele astfel incat profitul motorului de cautare sa fie maximizat.

Pentru reclamele cu un numar mare de afisari exista deja o statistica deci ne intereseaza un mod de calcul pentru reclamele noi.

Calculul ratei de clickuri se face pornind de la o rata medie de clickuri si urmarind apoi imbunatatirea diferentei intre aceasta si rata reclamei respective numita divergenta KL, printr-un algoritm regresiv.

Se iau in calcul pe rand diversi factori si se observa imbunatatirile. Acesti factori sunt: reclame ale aceluiasi client, reclame care folosesc aceeasi termeni de cautare, calitatea reclamei(aspect, factorul de atragere a atentiei, reputatia clientului, relevanta, frecventa de cautare a termenilor).

Sistemul de fisiere Google

Sistemul de fisiere Google este un sistem de fisiere distribuit, in care datele sunt stocate astfel incat sa se asigure anumite conditii obligatorii: datele sa poate fi accesate repede(fara a exista limitari-”bootle necks”), ele sa fie bine pastrate(cu ajutorul sistemelor redundante), sistemele sa isi revina repede in urma erorilor(de fapt fiind vorba de un sistem de fisiere atat de mare si atat
de des accesat erorile si caderile de sistem sunt mai curand regula decat exceptiile), scalabilitate , disponibilitate, latime mare de banda.

Arhitectura sistemului de fisiere Google se bazeaza pe clustere, un cluster fiind format dintr-un server master si mai multe chunck-servere(servere pentru bucati); serverul master avand rolul de a coordona celelalte servere, fluxul de informatie netrecand prin el pentru a nu gatui reteaua.

Serverul master pastreaza doar 3 categorii de date (metadata):spatiile de nume ale fisierelor si bucatilor, maparea fisier-bucati si chunckserverele cu replici (redundante); de asemenea retine si versiunea de upadate a replicilor astfel ca in cazul schimbarilor de informatie datele sa ramana consistente si hotaraste care dintre chunckserverele cu replici este primar, adica asupra caruia se efectueaza o mutatie prima data; el functioneaza pe un sistem de mutexuri astfel incat sa nu
apara erori.

Modificarile asupra serverelor secundare se fac secvential(si nu sub forma de arbore de exemplu), pentru a folosi eficient banda si a nu gatui sistemul folosind numai serverul master.


Cachingul si motoarele de cautare

In proiectarea eficienta a sistemelor de caching trebuie sa se aleaga un compromis intre diverse optiuni: caching static sau dinamic, caching cu raspunsurile exacte la o anumita interogare sau a listelor asociate unor anumiti termeni care se ragasesc in cautari.

Cachingul listelor de raspunsuri are o rata de cache hit mai mare si prezinta si un grad mai mare de libertate (deoarece din termeni se pot forma interogari noi), dar are si dezavantajul faptului ca volumul de informatii e mult mai mare si ca urmare trebuie sa se aleaga numai un set restrans de raspunsuri care sa fie pastrat; acesta se alege pe baza algoritmului rucsacului pastrandu-se raspunsurile la termenii cu o frecventa mare in interogari dar si cu un numar mic de raspunsuri in acelasi timp; in cazul alocarii dinamice se evacueaza din cache raspunsurile care au acest
raport mic.

In urma observatiilor s-a hotarat ca cel mai bun algoritm se bazeaza pe alocare statica foslosind un compromis, astfel interogarile cele mai frecvente sunt retinute intr-o parte a cache-ului, iar in cealalta parte se pastreaza liste de raspunsuri pe baza algoritmului descris mai sus si care se numeste QTF-DF.

Cristi

De curand am observat, cu oarecare tristete, ca de cele mai multe ori judec o aplicatie dupa cat de usor se poate folosi. Nu dau atentie la "detalii" de genul: cat de complexa este, cate informatii colecteaza pentru procesare, etc...NU....daca nu are o interfata pe care sa o pot folosi usor atunci o las balta si caut alta.
Si am inceput sa ma gandesc la utilizatorii aplicatiilor realizare de mine...Oare ii ajuta atat de mult cat cred eu, sau interfata e greoaie si greu de folosit? Am inceput sa ma detasez putin de functionalitatea aplicatiei si sa testez interfata. Razultatul....nu mi-a fost chiar favorabil :D

Atunci am inceput sa ma documentez despre regulile realizarii unei interfete corecte. Cateva idei mai importante din cercetarea mea le gasiti aici

Marieta

De curand s-a pus problema sa construim o interfata pentru o aplicatie care cauta niste cuvinte cheie in log-urile de msn/yahoo/irc/skype. Parametrii cautarii sunt:

• username si parola utilizatorului
• serverul in care se cauta (msn/yahoo/..)
• cuvintele cheie
• numarul de rezultate pe pagina

Cautarea trebuie sa intoarca numarul de rezultate intr-o forma usor descifrabila si numele interlocutorului.

Implementarea pe care o propun eu este in Java. Putem folosi clasa JFrame din pachetul javax.swing.*. Aceasta abordare ne perminte sa creem usor butoane/etichete sau textfield-uri. Prelucrarea informatiilor din aceste elemente grafice se face cu ajutorul interfetei ActionListener, prin implementarea metodei actionPerformed.

Descrierea pas cu pas si implementarea propriu-zisa se vor putea download-a in curand de pe site-ul nostru.

Georgiana

Flex este un cadrul de lucru open-source pentru construirea de aplicatii web, care se implementeaza pe toate tipurile de browsere, desktopuri si sisteme de operare. Aplicatiile in Flex se pot dezvolta folosind platforma gratuita Flex SDK sau folosind Flex Builder de la Adobe.

Utilitarul Flex Builder este disponibil in limba engleza si japoneza. Pentru a-l testa gratuit timp de 60 de zile, puteti folosi linkul: http://www.adobe.com/ro/products/flex/.

O aplicatie implementata in Flex va fi disponibila in cateva zile si pe site-ul nostru.

Georgiana

Ne propunem sa folosim Javascript pentru a crea o interfata de cautare si evidentiere a cuvintelor intr-o pagina web. Care sunt notiunile pe care trebuie sa le cunoastem? Cat de experimentati trebuie sa fim? Orice browser va suporta aplicatia? Cam cum ar arata un model de implementare?

Raspunsurile la aceste intrebari le gasesti citind articolul complet.

Georgiana

Fiorosul "GET"

Ce-i un "GET"? De ce ghilimele? ... De ce "fiorosul"?

Un "GET" este un cuvant-cheie (Keyword) al standardului HTTP si sta la baza internetului modern si pre-modern. Traducerea sa in romana ar fi undeva inspre "ia", "adu", "baga mareeee!", "da-n'coa' !" si echivalentele. Probabil unii dintre cititori si-au facut o idee despre ce vrea sa spuna articolul de fata prin simpla citire a liniilor de mai sus. In romana de ne-specialitate un "GET" reprezinta o cerere HTTP a unei resurse aflata pe un anume server. In linii mari si datorita programelelor ce ruleaza pe acel server (sau de altfel pe majoritatea serverelor din ziua de azi) aceasta resursa nu e neaparat nevoie sa fie una statica, gen o pagina "clasica" web, ci poate sa fie o resursa dinamica, actualizata sau creeata la cerere. Programelele ce ruleaza pe acel server si ne fac noua viata mai usoara si mai colorata sunt de obicei un modul PHP, un daemon(serviciu) de baza de date, un modul ASP(sau ASPX), sau chiar solutii non-clasice de achizitii de date. In esenta deci, un "GET" sta la baza internetului actual.

Ghilimelele lui get au rolul lor, bine gandit in articolul de fata. Un "GET" NU este suficient pentru a identifica corect resursa si serverul. Pentru a fi functional, get apeleaza la "prietenul" sau, URI (sau URL). Un URI este prescuratrea pe initiale a Universal Resource Identifier, dar de obicei este numit URL sau Universal Resource Locator. URI nu este acelasi lucru cu URL, insa in exemplul de fata nu are chiar asa mare importanta din moment ce vorbim despre un anume tip de URI (un URI cuprinde mai multe protocoale ca ftp:// , http:// , mailto: , pe cand un URL este calea catre resursa dorita ; poate vom explica clar diferenta dintre un URI si un URL intr-un articol urmtor). Prin urmare, fiecare GET are nevoie de un URL pentru a avea sens in lumea informatica. O sintaxa corecta de get ar fi "GET http://parola:user@server.domeniu/cale_locala". Ca si mai sus, o parte dintre cititori incep sa aiba o banuiala la ce ar folosi ghilimelele... Imaginati-va ca aveti de implementat un browser (sau macar o parte mica a unui browser) web... in C de exemplu... se poate folosi ca MACRO stringul "GET" pentru a nu fi nevoie mereu sa-l scrieti in clar. Puteti folosi de exemplu #define get "GET" si pe urma pe undeva prin codul sursa char * uri = calloc(1024, sizeof(char)); strcat(uri, get); strcat(uri, url); request( ... , uri, ...); free(uri); . Evident, ar trebui undeva mai sus sa deschideti un socket, sa rezolvati eventual host-ul si pe urma sa scrieti cele de mai sus :D . E doar un exemplu!.. nu aruncati cu pietre :) .

Fiorosul "GET" a fost si va ramane o piatra de temelie in browserele web(cel putin pentru viitorul predictibil intr-o oarecare masura :D ). Il gasiti in orice si toate browserele actuale ca fiind combustibilul ce pune in functiune motorul browserului. Fara el web-ul ar functiona probabil altfel.

Mircea

RSS este o familie de formate de tip Web Feed folosita pentru a posta intr-o forma standardizata mesaje care sunt updatate cu o frecvena foarte mare, cum ar fi stiri, mesaje blog sau chiar format video si audio. De asemenea un document RSS contine si metadata cum ar fi date despre publicare si despre autor.

Streamurile de RSS pot fi citite folosind un RSS-reader. Un format de fisier XML standardizat permite informatiei RSS sa fie publicata doar o data si vizualizata de mai multe programe diferite.Utilizatorul foloseste un feed RSS bazandu-se pe URL-ul acestuia.

Prima versiune de RSS a aparut in 1999 si a fost dezvoltata de Netscape pentru a fi folosita pe portalul My.Netscape.com,numindu-se RDF Site Summary.Versiunea este cunoscuta ca RSS 0.9.RSS 0.91 a fost o versiune simplificata numita Rich Site Summary.
O noua versiune 2.0 a aparut in 2002 sub numele de Really Simple Syndication.

Incepand cu variantele 2.x versiunile paralele de RSS au putut depista si adopta inovatiile din celelalte. De asemenea RSS a devenit cea mai populara alegere pentru podcasting.

Cristi