Putem sa incercam niste "boost-uri" de motivare prin CodingCamp-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).

h2. Problemele infoarena2

h2. Ce a mers prost in infoarena2

Pe parcursul dezvoltarii infoarena2 noi (Cristi, Leonard, Mircea, Vali, etc...) am facut un numar de greseli majore la care acum simtim efectele. Daca am incepe din nou programarea la proiectul infoarena3 nu am sa face din nou aceleasi greseli si rezultatul ar fi mult mai bun. Daca stim care au fost gresile si cum sa le 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 fara o rescriere, dar nu toate. Multe dintre aceste greseli 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 o rescriere de la 0.

h3. PHP
 
Infoarena2 este un site traditional bazat pe php/mysql si foarte putin javascript. Nu folosim clase si nici exceptii din php. In mod similat nu folosim decat tabele MyISAM in MySQL, fara foreign key, fara constraints si fara tranzactii. Pentru layout nu folosim nici un sistem de templating, doar html presarat cu snippet-uri php. Infoarena2 foloseste absolut minimumul de tehnologie pentru un proiect web-based.
 
Aceasta decizie fost facuta in vara 2006 pentru a face site-ul simplu si usor de programat. Ne-am gandit ca sunt mai multi oameni care stii si vor sa lucreze cu php/mysql procedural decat cu orice altceva. Este discutabil daca sunt mai multi oameni interesati in php decat in python sau ruby, cel putin dintre utilizatorii nostri. Probabil ca multi ar fi tentati sa ajute la un proiect care foloseste feature-uri avansate de programare absente in C/C++/Pascal (si php). Dar oricum nu am reusit sa bagam pe nimeni din exterior in echipa de development. Mai mult, am ajuns in situatia in care nici noi noi vrei sa programam in php/mysql, sau cel putin nu in modul in care este folosit in infoarena. PHP este un limbaj foarte util pentru multe lucruri, dar pentru infoarena2 nu a functionat.
 

h3. Tabelul ia_parameter_values
Una 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.

Acest tabel face codul de runde si probleme sa devina mult mai complicat decat este necesar, si a avut consecinte infioratoare:
* Editorul de task-uri si runde a intarziat si e greu utilizabil.
* Securitatea per task/runda este un hack mizerabil.
* *Nu avem* mai multe tipuri de probleme si concursuri (unul dintre scopurile infoarena2).
* Rundele inca nu ruleaza automat.
 
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).

h3. Tabelul 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. Ideea era sa tinem scoruri per runda cu task_id NULL si eventual statistici per task/round cu user_id NULL. Astfel puteam sa tinem toate scorurile in acelasi tabel. Din pacate am ajuns in situatia de a avea mai putine statistici decat in infoarena1. Asta cred ca este singurul punct in care infoarena1 depaseste infoarena2.

Este un tabel oribil si mi-e rusine de ce am facut acolo. Este incet, urat si greu de facut query-uri.

Acest tabel ar trebui spart in mai multe tabele fara coloane nulabile, si fara oroarea de score_id.

Acest tabel ar trebui spart in mai multe tabele fara coloane nulabile. Idea fundamental gresita de aici a fost economisirea numarului de tabele din baza de date. Este ca si cum ai incerca sa folosesi cat mai putine functii facand copy-paste in main().

Tabelele ia_score si ia_parameter value sunt niste greseli majore si grosonale care demonstreaza ignoranta in design-ul bazelor de date. Noi am pornit pe idea fundamental gresita de a "economisi" numarului de tabele din baza de date. Este similar cu a economisi numarul de functii dintr-un program facand copy-paste la cod, sau numarul de struct-uri folosind void* si aritmetica explicita de pointeri.

h3. Id-uri VARCHAR (64)