“Rezolvând problema greşită”

Traducere a articolului “Solving the wrong problem” de pe blogul Programming in the 21st Century. Judecând după adresa de e-mail a autorului, el se numeşte James Hague.

~*~

Ocazional, deşi ştiu că nu-i o idee bună, arunc o privire peste discuţiile ce se ţin asupra textelor mele, să văd care-i atmosfera generală, poate am făcut vreo eroare grosolană pe care nimeni n-a catadicsit să mi-o semnaleze. Cele mai suprinzătoare comentarii au fost cele despre viteza cu care mi se încarcă saitul, şi anume că majoritatea paginilor implică doar două cereri (n.t. către server) – fişierul HTML şi fişierul CSS – un total mai mic de 10 kb, lucru considerat impresionant.

O contribuţie la această viteză o are şi norocul. Folosesc găzduire shared, şi nu am control peste ceea ce fac alte saituri de pe serverul meu.

Pe de altă parte însă, am o imagine clară a modului cum interacţionează oamenii cu un blog: îl citesc. Persoana mea e singura excepţie – tot ce fac ceilalţi oameni cu saitul este să ceară fişiere şi să le citească. Nu e nimic magic în a servi fişiere simple şi statice. Ce-i surprinzător este că majoritatea celor ce implementează software pentru bloging încearcă să rezolve problema greşită.

O bază de date SQL în care să ţii articole şi pe care să le aduci la cerere pentru a le potrivi în temă? Asta e o soluţie ce rezolvă problemele administratorilor de bloguri, nu pe ale cititorilor – şi totuşi cititorii plătesc preţul printr-o pagină ce se încarcă mai încet sau chiar nu se încarcă deloc ( spre exemplu, după ce primeşte o menţiune pe un sait important).

Cândva, Sita lui Eratostene (un algoritm ce găseşte numerele prime până la o limită superioară) era populară pentru a compara limbaje de programare ca performanţe. Algoritmul era bun dacă dispuneai de puterea de calcul necesară – dar să presupunem că îţi trebuiau primele 8000 de numere, pentru o aplicaţie în care timpul e un factor important. Te-ai mai chinui să efectuezi calculele la fiecare rulare? Bineînţeles că nu. Deja le ştii. Ajunge să rulezi programul o dată în timpul dezvoltării aplicaţiei, şi cu asta basta (n.t. o dată obţinută lista de numere, ea poate fi consultată într-un fişier static).

Cookies pentru a urmări vizitatorii? Scripturi Google Analytics? Ele rezolvă o problemă ce-i complet a deţinătorului de sait: “Cum fac să ştiu exact cât trafic primesc”. Cititorilor nu le pasă.

Butoane pentru Google+ şi Twitter şi Facebook? Nu rezolvă problemele nicicui. Poţi să tweetui cu uşurinţă şi fără un buton special. Saiturile de agregare precum Google Reader (ba chiar până şi motorul de căutare Google) au echivalentul unor butoane “like”, de ce să te apuci să duplici funcţionalitate? Important este că doar o mică porţiune din cititori îşi bat capul să folosească astfel de butoane, însă toate imaginile şi tot codul de scripting asociat cu ele încetinesc pagina pentru toată lumea.

~*~

Am tradus articolul pentru că-mi pare a exprima o viziune aproape absentă între internauţii români – indiferent de care parte a panoului de control se află. Simplitate şi eleganţă ca filosofie de design, când aţi văzut aşa ceva ultima oară în practică?