Infoarena3

Codul din spatele site-ului infoarena2 este intr-o stare foarte proasta si
trebuie rescris. Asta este o propunere foarte ambitioasa si riscanta si este
nevoie de o explicatie detaliata pentru a demonstra ca rescrierea soft-ului
din spatelei site-ul de la 0 este cea mai buna modalitate de a avansa site-ul.

Putina istorie

Site-ul infoarena1 a fost scris acum vreo 4-5 de Cristi pentru a fi prezentat
la infoeducatie, un concurs de soft de la Galaciuc. Site-ul era foarte
impresionant si a castigat concursul chiar timp de 2 ani la rand. Mai mult,
site-ul era atat de bun incat a intrat in "productie" si a adunat o comunitate
in jurul lui care a produs un numar impresionant de probleme si concursuri.

Soft-ul din spatele site-ului a ramas aproape identic cu ce a venit Cristi la
Galaciuc; s-au facut doar niste schimbari absolut necesare si bug-fix-uri. Am
incercat sa punem pe picioare site-ul trac, sa bagam codul in subversion dar
in realitate nimeni nu s-a atins de cod. Au crescut niste lucruri pe langa
cod; cum ar fi un "portal editabil" de informatica si o integrare foarte
neplacuta cu soft-ul media-wiki. Eventual am ajuns la concluzia ca nu se poate
face nimic si trebuie rescris de la 0.

In vara lui 2006 ne-am adunat 5-6 flacai, ne-am dus in munti si ne-am incuiat
in casa ca sa facem infoarena2 (multumim din nou lui vali). Intre noi il aveam
doar pe Cristi cu o oarecare experienta in web-development, in rest eram in
cea mai mare parte incepatori in php, mysql, etc. Site-ul nu a fost terminat
acolo in munti si a fost nevoie de un numar de "coding camp"-uri pentru a pune
site-ul pe picioare si a ajunge macar la nivelul de functionalitate din
infoarena1. Site-ul a fost eventual lansat spre sfarsitul lui 2006, dar parti
de genul editarea de runde si probleme (o cerinta critica) a fost finalizata
doar in 2007.

Softul infoarena2 este mult mult mai bun decat cel din infoarena1. Acest lucru
se poate vedea cel mai bine din calitatea si dimensiunile site-ului. Este
suficient doar ca numarul de probleme din arhiva este mai mult decat dublu,
dar acum este posibil pentru comunitatea site-ului sa ne ajute
mult mai mult.

Din pacate dezvoltarea la site-ul infoarena2 a stagnat de multa vreme. Au mai
fost tentative de coding-camp-uri si chiar s-au adaugat feature-uri

noi, dar progresul este mult prea incet. Exista multe cauze pentru
aceasta stagnare, dar eu (Leonard) consider ca problema este este calitatea
codului. Infoarena2 este un soft complicat si incurcat in care este mult prea
dificil sa faci modificari, iar asta scade motivatia developerilor.

Putem sa incercam niste "boost-uri" de motivare prin coding-camp-uri dar
scopul este sa avem un grup de indivizi care lucreaza de acasa in timpul lor
liber. Pentru asta trebuie ca programarea sa fie usoara si distractiva, iar in
infoarena2 nu este cazul. Soft-ul nostru este mult mai "frumos" decat multe
produse comerciale, dar la infoarena2 nu exista motivatia financiara (si nici
nu vrem sa existe).

Problemele infoarena2

Pe parcursul dezvoltarii infoarena2 noi (Cristi, Leonard, Mircea, Vali,
etc...) am facut un numar de greseli majore la care acum simtim efectele. Daca
incepem din nou programarea la proiectul infoarena3 nu o sa facem din nou
aceleasi greseli si site-ul va fi mult mai bun. Daca stim ce am gresit si cum
sa evitam nu vom ajunge din nou in aceasi situatie.

Poate parea trist ca aruncam la gunoi aproape un an de efort, dar nu este
cazul. Vom pastra tot continului site-ului, care valoreaza enorm (si asta tine
de fapt infoarena.ro in viata). Si vom pastra lectiile infoarena2, care sunt
mult mai valoreasa decat codul efectiv scris in php. Ar fi cu totul altceva
daca alti oameni ar rescrie codul, ei probabil ca ar face aceleasi prostii si
ar fi mai bine sa se tina de treaba la infoarean2.

Am facut o lista cu ce anume am gresit in infoarena2 si cum putem face mai
bine (in infoarena3). Este posibil sa reparam multe dintre probleme in
infoarena2, fara o rescriere, dar multe dintre aceste greseli gresite vizeaza
arhitectura fundamentala a site-ului. Acestea nu pot fi reparate decat
printr-un efort enorm, iar acel efort cumulat ar fi mai mare decat rescrierea
de la 0.

ia_parameter_values

Unul dintre tintele infoarena2 a fost sa avem mai multe tipuri de runde si
probleme. Fiecare tip de runda sau de problema are alti "parametri", ne-am
gandit sa tinem toti acei parametri intr-un sigur tabel de forma "id-obiect",
"nume-parametru", "valoare". Este o idee foarte proasta care nu are absolut
nici un merit.

Ar trebui sa avem pentru fiecare tip de problema sau runda un tabel de genul
ia_classic_task, care contine o coloana task_id si apoi cate o coloana pentru
fiecare parametru. Eu (Leonard) am incercat aceasta transformare dar nu am
reusit (din cauza repercursiuni in restul site-ului) si am renuntat.

ia_score

Tabelul ia_score are coloanele: score_id, user_id, task_id, round_id si score.
Primele 4 coloane sunt sunt nulabile, asa ca tabelul nu are PK. Idea era sa
tinem scoruri per runda cu task_id NULL si eventual statistici per task/round
cu user_id NULL. Este un tabel oribil si mi-e rusine de ce am facut acolo.

Este prea greu sa faci query-uri in tabel si din pacate infoarena1 avea de
fapt mai multe statistici decat infoarena2. Asta cred ca este singurul punct
in care infoarena1 depaseste infoarena2.

Acest tabel ar trebui spart in mai multe tabele fara coloane nulabile. Idea
fundamental gresita de aici este economisirea numarului de tabele din baza de
date, care este o prostie. Este ca si cum ai incerca sa folosesi mai putine
functii facand copy-paste.

Id-uri VARCHAR

Id-urile pentru utilizatori sunt numere, dar restul sunt VARCHAR cu niste
validari facuta in cod prin regex-uri. Ar fi mai bine sa avem task_id ca numar
si task_name ca string absolut peste tot. task_name se poate obtine foarte
usor din task_id adaugand un join trivial.

MySQL nu face index pe hash-uri DOC LINK HERE pentru tabele pe disc, el
sorteaza id-urile tinand cont de colatii (latin2). Tinand string-uri peste tot
crestem dimensiunile tabelelor, si asta este oribil pentru tabele de genul
ia_score sau ia_job. S-ar merita de facut niste teste de performanta comparand
un tabel de scor exclusiv numeric cu unul plin de string-uri.

Securitatea, si magia din wiki

Pe parcursul dezvoltarii infoarena2 ne-am dorit sa evitam pe cat posibil
functionalitatea magica din wiki, si am mers prea departe. Am pornit de la
idea ca orice pagina este o pagina de wiki, si paginile de runde sau probleme
sunt doar un caz oarecare de pagina wiki. Securitatea paginilor de utilizatori
si de probleme este totusi subordonata problemelor, si asta am realizat
adaugand un "descriptor de securitate" ca string pentru fiecare pagina de
wiki. Pagina problema/adunare are la securitate un string "task: adunare", asa
ca vizibilitatea depinde de vizibilitatea task-ului. Este un sistem prea
generic, incurcat si greu de folosit sau extins.

Ar fi mai ok ca orice url de format problema/xxx sa intre prin controller-ul
de task-uri, care subordoneaza textblock-urile care incep cu problema/xxx.
Similar am avea controllere de news, blog, user page care subordoneaza tot ce
incepe cu news, blog sau user/costel. Pentru restul paginilor am avea un
controler DISTINCT de wiki. Codul pentru bucatile de editare si istorie poate
fi refolosit in 1000 de moduri, dar nu este acceptabil sa nu poti ajunge de la
editarea de enunt la editarea de problema fara sa modifici in address bar.

Nu este nimic gresit in a avea tabele ia_news, ia_blog_post si ia_wiki care
sunt "deasupra" lui ia_textblock, iar ia_textblock sa fie folosit doar pentru
versionarea unor bucati mari de text. Securitatea private/protected/public
(care este FOARTE utila si absolut OK) poate fi un simplu enum in ia_wiki.

Efortul necesar pentru o astfel de transformare in infoarena2 mi se pare
absolut enorm.

Layer de logica

Infoarena2 pretinde ca foloseste o arhitectura MVC, dar MVC este o notiunea
foarte larga si vag definita. Nu este interesanta o discutie detaliata asupra
ce inseamna MVC, asa ca voi discuta doar ce se foloseste efectiv in site-ul
infoarena2.

Url-urile sunt parsate in index.php si in functie de o logic complicata si nu
foarte interesanta fiecare request http este pasat la un "controller", care
este in principiu o functie php de prin www/controllers. Acel controller face
ceva cu requestul, de obicei baga niste request-uri in baza, si apoi face un
hash de "date pentru afisat" care il trimite la un view.

View-urile nu sunt functii, sunt fisiere .php oarecare din www/views. Lansarea
unui view este o operatie sinucigasa, se executa fisierul de view folosind
hash-ul de date si se trimite direct pe "teava". In acel view este posibil sa
se foloseasca textile, care poate executa macro-uri care(de obicei) se duc
pana in baza. Asta inseamna ca poti sa te duci in baza dupa executia
controller-ului, dar nu mi se pare nimic rau in asta. Macro-urile sunt
efectiv niste mini-controllere.

Problema este ca noi din controllere ne ducem direct in baza si logica fragila
de genul securitate este imprastiata si combinata cu cod jegos de
parsat/validat request-ul (in controller) sau construit query-uri sql (in
functiile de db). Aceasta problema are o rezolvare destul de clara si
bine-cunoscuta (dar nu de catre noi in vara 2006).

Intre codul de controller(UI) si codul de baza de data(DB) sa mai pune niste
cod de "business logic"(BL). Tot ce inseamna parsarea request-ului se face in
UI, tot ce inseamna contruirea de SQL se face in DB. BL contine de fapt tot
codul cu adevarat interesant pentru functionarea corecta a site-ul. Codul de
DB nu trebuie sa aiba grija decat sa construiasca query-uri (si sa evite sql
injection) iar codul de UI se ocupa de a vedea ce butoane a apasat
utilizatorul.

Unul dintre avantajele majore este ca se pot scrie usor teste pentru BL, iar
daca BL-ul nu are greseli atunci UI-ul nu poate sa strice nimic (decat
experienta utilizatorului). A se vedea punctul urmator.

Testele pe baza de curl

PHP este un limbaj foarte fragil, unde este foarte usor sa faci greseli
grosolane. Asta este o problema generica a limbajelor dinamice de genul php,
python, ruby, javascript fata de limbajele de genul C, C++, C# si java, si in
PHP este mult mai important sa testezi codul.

Teste curente sunt facute pe baza de curl, curl fiind o librarie de access
http. Testele construiesc un request complet http pe care il trimit pe fir,
asteapta ca apache sa raspunde si apoi verifica niste chestii din request (in
cea mai mare parte prin preg_match si strstr). Ambele faze sunt greu de facut,
dar are ca avantaj ca se trece prin tot codul si este foarte "realist".

Pentru a usura testarea am facut controllerele noastre de editare sa accepte
un parametru de form absent drept "nu vreau sa editez acest parametru". Asta
este necesar in teste dar e un comportament artifical care a "nascut" niste
bug-uri foarte urate. In retrospectiva a fost o idee proasta, care a introdus
o cuplare oribila intre controllere si codul de test. Ambele sunt acum foarte
greu de modificat.

Ar fi mai bine sa testam functii BL care nu au nici o treaba cu HTTP. Daca
BL-ul este ok atunci sigur bug-urile din UI nu pot sa strice nimic in baza.
UI-ul se poate testa apoi de mana.

ia_textblock, ia_textblock_history

ia_file

Caching exagerat

Un plan de atac

Branching

Nu am folosit eficient branch-uri. Absolut toate modificarile le-am facut
direct in trunk iar asta nu este o idee buna. Exista mereu schimbari mari,
care au nevoie de mai multe commit-uri pentru a fi complet functionale, iar
Astfel de schimbari trebuie facute intai intr-un branch special si abia apoi
copiate in trunk.

In asa fel trunk-ul devine mult mai stabil si nu este nimic rau in a abandona
o idee. In trunk-ul infoarena2 avem cod mort pentru idei abandonate, care acum
este dificil de extras. Branch-uri ar fi trebuit sa facem pentru cache-ing, editoare de probleme,
validate_array, tag-uri, blog, dataset-uri etc.

LINK TO PRODUCING OSS

Responsabilitati

Codul infoarena este open-source, iar oamenii lucreaza doar in timpul lor
liber. Dar daca vrei sa ajuti infoarena atunci trebuie sa te tii de treaba si
rezolvi tichetele pana la o anumita data. Ar ajuta mult ca un tichet
"acceptat" sa aiba un owner care este trebuie sa rezolve acel tichet pana la o
anumita data.

Bineinteles ca nu avem cum sa fortam pe nimeni sa lucreze la infoarena, dar se
presupune ca un individ care vrea sa ne ajute cu adevarat nu vrea sa frece
menta. Astfel de dead-line-uri ar fi un impuls interior pentru fiecare din
noi. Atentie: nu ma refer la dead-line-uri de genul "ar fi frumos sa avem #123
rezolvat pana luna viitoare", ma refer la lucruri de genul "eu rezolv #124
pana maine si #125 poimaine".

Ordine in tichete

Demo-uri

• Framework-uri
• SqlAlchemy
• Selenium
• Form-uri
• Tabele
• BL prin HTTP
• Wiki si atasamente in subversion.

Arest la domiciliu