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.

h1. Putina istorie

h2. 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.

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).

h1. Problemele infoarena2

h2. 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.

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.

h2. ia_parameter_values

h3. 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.

h2. ia_score

h3. 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.

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.

h2. Id-uri VARCHAR(64)

h3. Id-uri VARCHAR(64)

Id-urile pentru utilizatori sunt numere, dar restul sunt VARCHAR(64) 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.

h2. Securitatea, si magia din wiki

h3. 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.

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

h2. Layer de logica

h3. 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.

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.

h2. Testele pe baza de curl

h3. 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.

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.

h2. ia_textblock, ia_textblock_history

h3. ia_textblock, ia_textblock_history

h2. ia_file

h3. ia_file

h2. Caching exagerat

h3. Caching exagerat

h1. Un plan de atac

h2. Un plan de atac

h2. Branching

h3. 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.

*LINK TO PRODUCING OSS*

h2. Responsabilitati

h3. 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".

h2. Ordine in tichete

h3. Ordine in tichete

h2. Demo-uri

h3. Demo-uri

* Framework-uri
* SqlAlchemy

* BL prin HTTP
* Wiki si atasamente in subversion.

h2. Arest la domiciliu

h3. Arest la domiciliu