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.
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 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.
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 valoroase decat codul php. Daca am fi alti omaeni care am rescrie codul probabil ca am face aceleasi prostii, si atunc ar mai bine sa ne tina de treaba la infoarean2.
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). Vom pastra lectiile infoarena2, care sunt mult mai valoroase decat codul php. Daca am fi alti oameni care am rescrie codul probabil ca am face aceleasi prostii, si atunci ar mai bine sa ne tinem de treaba la infoarena2.
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.
Infoarena2 este un site traditional bazat pe php/mysql si foarte putin javascript. Nu folosim clase si nici exceptii din php. In mod similar nu folosim decat tabele MyISAM in MySQL, fara foreign key-uri, constraint-uri, view-uri sau tranzactii. Pentru layout nu folosim nici un sistem de templating, doar html presarat cu snippet-uri php. Infoarena2 foloseste absolut minimumul de tehnologie posibil 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.
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 stiu 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 limbaj 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 nu mai vrem sa programam in php/mysql, sau cel putin nu in modul in care este folosit in infoarena2. 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.
Una dintre tintele infoarena2 a fost sa avem mai multe tipuri de runde si probleme. Deoarece 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. Acest tabel si gandirea din spatele lui a facut codul de runde si probleme sa devina mult mai complicat decat este necesar, si a avut consecinte absolut infioratoare:
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).
* *Nu avem* mai multe tipuri de probleme si concursuri (scopul original).
* 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).
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. Asta este o solutie acceptabila pentru o baza de date. Eu (Leonard) am incercat aceasta transformare dar *nu am reusit* (din cauza repercursiuni in restul site-ului). Consider ca inlocuirea acestui tabel e mai dificila decat rescrierea de la 0.
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.
Tabelul ia_score are coloanele: score_id, user_id, task_id, round_id si score (aproximativ). Primele 4 coloane sunt sunt nulabile, asa ca tabelul nu poate avea 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 *nu a mers* si am ajuns in situatia de a avea chiar mai putine statistici decat in infoarena1. Asta cred ca este singurul punct in care infoarena1 *depaseste* infoarena2.
Acest tabel ar trebui spart in mai multe tabele fara coloane nulabile, si fara oroarea de score_id.
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 toate id-urile drept numere, spre exemplu task_id int si task_name string. task_name se poate obtine foarte usor din task_id adaugand un join trivial.
MySQL *nu* face 'index pe hash-uri':http://dev.mysql.com/doc/refman/5.1/en/create-index.html pentru tabele pe disc (doar pentru tabele din memorie). MySQL sorteaza id-urile alfabetic tinand cont de colatii (latin2 pentru noi). Tinand string-uri peste tot crestem dimensiunile tabelelor, iar asta este oribil pentru tabele de genul ia_score sau ia_job. S-ar merita de facut niste teste de performanta, se poate compara un tabel de scor exclusiv numeric cu unul plin de string-uri.
MySQL *nu* face 'index pe hash-uri':http://dev.mysql.com/doc/refman/5.1/en/create-index.html pentru tabele pe disc (doar pentru tabele din memorie). MySQL sorteaza id-urile alfabetic tinand cont de colatii (latin2 pentru noi). Tinand string-uri peste tot crestem dimensiunile tabelelor, iar asta este oribil pentru performanta tabelelor de genul ia_score sau ia_job. Aici s-ar merita de facut niste teste de performanta. Spre exemplu putem compara un tabel de scor exclusiv numeric cu unul plin de string-uri.
h3. Tabele de wiki: ia_textblock, ia_textblock_history, ia_file.
Tabelele ia_textblock si ia_textblock_histor au aceasi structura, doar ca ia_textblock tine ultima versiune. Asta inseamna ca orice fel de istorie are nevoie de query-ul complicate pe baza de UNION. Ar trebui sa tinem un singur tabel, eventual cu un tabel aditional care duplica doar datele cele mai recente.
Ultima versiune a unei pagini de wiki se tine in ia_textblock, iar versiunile precedente se tin in ia_textblock_history cu aceasi structura. Asta inseamna ca orice fel de istorie are nevoie de query-uri complicate folosind UNION. Ar trebui sa tinem un singur tabel, eventual cu un tabel aditional care duplica doar datele cele mai recente.
Atasamentele sunt un sistem distict, sunt fisiere pe disc sub-ordonate unui textblock din baza de date. Manipularea atasamentelor este FOARTE neplacuta, si pot aparea desincronizari in diverese locuri. Securitatea atasamentelor depinde de cea a textblock-urilor (si indirect a problemelor) in moduri complicate si imprevizibile. Ar fi mai bine sa avem un singur suport de "BLOB-uri" versionate.
Atasamentele sunt un sistem complet distict, sunt fisiere pe disc sub-ordonate unui textblock din baza de date. Manipularea atasamentelor este FOARTE neplacuta, si pot aparea desincronizari in diverese locuri. Securitatea atasamentelor depinde de cea a textblock-urilor (si indirect a problemelor) in moduri complicate si imprevizibile. Ar fi mai bine sa avem un singur suport de "BLOB-uri" versionate.
Nu avem suport de redenumire si stergere care sa pastreze istoria, si nici o idee resonabil de design care ar permite asa ceva in baza de date. Trebuie investigat daca se poate folosi subversion in loc de MySQL pentru fisiere versionate.
Nu avem suport de redenumire si stergere care sa pastreze istoria, si nici o idee simpla de design care ar permite asa ceva in baza de date. Trebuie investigat daca se poate folosi subversion in loc de MySQL pentru fisiere versionate.
h3. 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 trebuie totusi sa fie subordonata problemelor. Noi am realizat asta adaugand un "descriptor de securitate" ca string pentru fiecare pagina de wiki. Pagina problema/adunare are la securitate un string "task: adunare", si asa vizibilitatea paginii depinde de vizibilitatea task-ului. Este un sistem prea generic, incurcat si greu de folosit sau extins.
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 probleme/useri/runde/news/blog sunt doar un caz oarecare de pagina wiki. Securitatea paginilor de probleme trebuie totusi sa fie subordonata problemelor. Noi am realizat asta adaugand un "descriptor de securitate" ca string pentru fiecare pagina de wiki. Pagina problema/adunare are la securitate un string "task: adunare", si asa vizibilitatea paginii depinde de vizibilitatea task-ului. Este un sistem prea generic, incurcat si greu de folosit sau extins.
Ar fi mai bine ca orice url de format problema/xxx sa intre prin controller-ul de task-uri, care isi 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.
Ar fi mai bine ca orice url de forma problema/xxx sa intre prin controller-ul de task-uri, care isi subordoneaza textblock-urile care incep cu problema/xxx. Similar am avea controllere de news, blog, user page care subordoneaza tot ce incepe cu stiri, blog sau utilizator/yyy. Pentru restul paginilor am avea un controler *distinct* de wiki. Codul pentru bucatile de editare si istorie a textblock-urile poate fi refolosit in 1000 de moduri. *Nu* este acceptabil sa nu poti ajunge de la editarea de enunt la editarea limitei de timp fara sa modifici in address bar.
Am avea tabele ia_news, ia_blog_post si ia_wiki care sunt "deasupra" lui ia_textblock, iar ia_textblock ar fi folosit doar pentru versionarea unor bucati de text. Securitatea private/protected/public (care este *foarte* utila si absolut ok) poate fi un simplu enum in ia_wiki. Acel enum trebuie editat folosind un simplu dropdown.
Efortul necesar pentru o astfel de transformare in infoarena2 mi se pare absolut enorm.
Efortul necesar pentru o astfel de transformare fundamentala in infoarena2 mi se pare iarasi absolut enorm.
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.
Infoarena2 pretinde ca foloseste o arhitectura MVC, dar MVC este o notiunea prea 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". Un controller este in principiu o functie php din www/controllers. Acel controller face ceva cu requestul, de obicei niste query-uri in baza da date, si apoi constrieste un hash de "date pentru afisat" care il trimite la un view.
Url-urile sunt parsate in index.php si in functie de o logica complicata si nu foarte interesanta fiecare request http este pasat la un "controller". Un controller este o functie php din www/controllers. Acel controller face ceva cu requestul, de obicei niste query-uri in baza da date, si apoi constrieste un hash de "date pentru afisat" care il trimite la un view.
View-urile nu sunt functii, sunt fisiere .php 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 se poate folosi 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.
View-urile nu sunt functii, sunt fisiere .php din www/views. Executia unui view este o operatie sinucigasa, care se trimite direct pe teava. Nu se poate executa cod dupa un view. Fisierul de view se executa folosind continutul hash-ului de data ca variabile globale. In acel view se poate folosi textile, care poate executa macro-uri care(de obicei) se duc iar 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 larg acceptata in industrie (dar nu de pentru noi in vara 2006).
Problema este ca noi din controllere ne ducem direct in baza si logica fragila de genul securitate este imprastiata intre functiile de UI si de DB. Este riscant (error-prone) sa combini logica site-ului cu parsarea requestului sau construirea query-ului. Aceasta problema are o rezolvare destul de clara si larg acceptata in industrie, de care noi nu stiam in vara lui 2006.
Intre codul de controller (UI) si codul de baza de data (DB) se mai pune niste cod de "business logic" (BL). Tot ce inseamna parsarea request-ului se face in UI si 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. Daca BL-ul nu are greseli atunci UI-ul nu poate sa strice nimic in baza (doar experienta utilizatorului). A se vedea punctul urmator.
Unul dintre avantajele majore este ca se pot scrie usor teste pentru BL. Daca BL-ul nu are greseli atunci UI-ul nu poate sa strice nimic in baza (doar experienta utilizatorului). Apeland functii doar de BL este mult mai usor sa verifici corectitudinea unui macro sau controller.
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. Asta face ca in limbajele dinamice sa fie mult mai important sa testezi codul.
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. In limbajele dinamice sa fie mult mai important sa testezi codul. Multe lucruri prinse de un compilator de C++ scapa pana in browser folosind PHP.
Teste curente sunt facute pe baza de 'curl':http://www.php.net/curl, curl fiind o librarie de access HTTP. Testele construiesc un request complet http pe care il trimit pe fir, asteapta ca apache sa raspunda, iar apoi verifica niste chestii din request. Contruirea requestului se face folosind 'array':http://www.php.net/manual/en/function.array.php, si verificarile se face cu functii de genul preg_match si strstr. Ambele faze sunt greu de facut, dar avantajul acestui sistem ca testeaza tot codul si este foarte "realist".
Teste curente sunt facute pe baza de 'curl':http://www.php.net/curl, o librarie de access HTTP. Testele construiesc un request complet http pe care il trimit pe fir, asteapta ca apache sa raspunda, si apoi verifica niste chestii din request. Contruirea requestului se face folosind 'array':http://www.php.net/manual/en/function.array.php, si verificarile se face cu functii de genul preg_match si strstr. Ambele faze sunt greu de facut, dar avantajul acestui sistem ca testeaza 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 foarte util 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, sau folosind ceva de genul 'selenium':http://www.openqa.org/selenium/
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, sau folosind ceva de genul 'selenium':http://www.openqa.org/selenium/.
h3. Caching exagerat
Infoarena2 suporta mai multe forme de caching:
# Cache de textile parsat, inainte de executia macro-urilor. Majoritatea request-urilor nu executa codul de textile.
# Cache de imagini redimensionate. Cand se cere o imagine redimensionata ea este salvata pe disc si se evita operatiile de grafic pentru avatari etc.
# Cache de obiecte din baza de date, folosind memcached sau eaccelerator. Acest cache tine obiecte de genul useri, task-uri si runde.
* Cache de textile parsat, inainte de executia macro-urilor. Majoritatea request-urilor nu executa codul de textile.
* Cache de imagini redimensionate. Cand se cere o imagine redimensionata ea este salvata pe disc si se evita operatiile de grafica pentru avatari etc.
* Cache de obiecte din baza de date, folosind memcached sau eaccelerator. Acest cache tine obiecte de genul useri, task-uri si runde.
Acest ultim mod de caching are inclusiv suport de write-through (cand se salveaza un obiect se sterge varianta din cache) care a fost foarte complex de implementat. Codul de cache este bagat prin multe functii db_ si nu este deloc usor de inteles. Se combina cod de DB, BL si caching in aceleasi functii.
Suportul de write-through nu este de fapt foarte util pentru ca evaluatorul si partea de web nu folosesc acelasi cache. Eventual am fost fortati sa facem rundele sa traiasca doar 5 secunde in cache. Acest caching nu imbunatateste mult timpul de raspuns: Am masurat de mult timpii de raspuns cu si fara cache la paginile de enunt si diferentele erau nesemnificative. Acest mod de caching complica prea mult codul si nu aduce nimic folositor.
h3. Interfata utilizator.
Acest ultim mod de caching are inclusiv suport de write-through (cand se salveaza un obiect se sterge cache-ul) care este foarte complex de implementat. Codul de cache este bagat prin foarte multe functii db_ si nu este deloc usor de inteles. Se combinat cod de DB, BL si caching in aceleasi functii.
In infoarena2 nu exista nici un mod definitiv de face construi un form sau un tabel. Exista mai multe sisteme prin cod dar nici unul nu functioneaza definitiv. Avem tabele paginate ca macro-uri, dar sunt niste hack-uri destul de urate. Avem doua moduri "inteligente" de construit tabele (format_table si dataset-uri) dar unele sunt facute de mana. Avem un sistem de form-uri automate (pentru ia_parameter_values), dar este folosit doar partial si e foarte limitat. Nu avem un mod simplu si standard de face escape in html.
Suportul de write-through nu este de fapt foarte util pentru ca evaluatorul si partea de web nu folosesc acelasi cache. Eventual am fost fortati sa facem rundele sa traiasca doar 5 secunde in cache. Mai mult, acest caching nu imbunatateste mult timpul de raspuns: Am masurat timpii de raspuns cu si fara cache la paginile de enunt si diferentele erau nesemnificative. Acest cod de caching complica mult codul si nu aduce nimic folositor.
In general fiecare a facut cum l-a taiat capul. Pe toti ne-a taiat cam stramb.
h2. Un plan de atac
h2. Organizare pentru infoarena3
Unele probleme din infoarena2 nu origineaza neaparat in cod, dar in modul nostru de lucru. Aici am pus niste idei pentru a imbunatati procesul de dezvoltari. Teoretic ar putea fi aplicate si in infoarena2.
Multe dintre probleme infoarena2 au aparut din cauze non-tehnice, si anume dintr-un proces de dezvoltare haotic. Am adunat niste idei pentru cum putem lucra mai eficient.
h3. Branching
h3. Folosim branch-uri
Nu am 'folosit eficient branch-uri':http://producingoss.com/en/vc.html#branches. 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. Astfel de schimbari trebuie facute intai intr-un branch special si abia apoi copiate(svn merge) in trunk.
In infoarena2 nu am 'folosit eficient branch-uri':http://producingoss.com/en/vc.html#branches. 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. Astfel de schimbari trebuie facute intai intr-un branch special si abia apoi copiate (cu svn merge) in trunk. Asta face trunk-ul sa fie mai stabil si sa nu mai contina "cod mort".
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.
Un branch poti sa faci oricand daca ai access subversion, fara sa intrebi pe nimeni. Intr-un branch este OK sa experimentezi cu absolut orice fara sa-ti faci griji ca strici site-ul pentru altii. Cand consideri ca este gata de copiat in trunk poti sa chemi pe cineva sa se uite peste modificari. Modificarile pot fi acceptate in trunk, sau pot aparea observatii si branch-ul poate fi respins. Daca un branch este respins poti sa ii rezolvi problemele si sa il propui din nou pentru includere in trunk.
Ne dorim sa punem doar modificari aproximativ atomice in trunk, care sa nu introduca bug-uri. Este in continuare OK sa punem bugfix-uri si tweak-uri minore de CSS direct in trunk. Branch-urile sunt necesare pentru feature-uri de genul blog, latex, array_validate, dataset-uri, caching, tag-uri, etc.
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 responsabil sa rezolve acel tichet pana la o anumita data.
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 sa rezolvi tichetele pana la o anumita data. Bineinteles ca nu avem cum sa fortam pe nimeni sa lucreze la infoarena, dar se presupune cine vrea sa ne ajute nu vrea sa frece menta.
Un tichet "acceptat" trebuie sa aiba un owner care este responsabil sa rezolve acel tichet pana la o anumita data. Un deadline nu inseamna "ar fi frumos sa avem #123 rezolvat pana luna viitoare". Un deadline inseamna ceva de genul "eu rezolv #124 pana maine si #125 poimaine". Astfel de deadline-uri functioneaza ca o motivatie suplimentara.
Asta este foarte similar cu sistem-ul mare de roluri din 'echipa infoarena':echipa-infoarena, care pare sa functioneze destul de bine. Pe langa dead-line-uri per-tichet vom avem si un om care se ocupa de development in mod global, care acum este ==user(user="fluffy")==. *TODO:* de detaliat ce face dev lead?
h3. Milestone-uri semnificative
Milestone-urile din infoarena2 au fost foarte foarte confusing. Am impartit tichetele vag dupa prioritati, si le-am pus in milestone-uri, dar nu ne-am tinut de treaba. Cu cat un tichet era mai naspa si infricosator cu atat l-am pus undeva in viitor. Daca nimeni nu isi asuma responsabilitatea pentru un tichet atunci acel tichet nu va fi facut, indiferent de milestone-ul in care e pus.
Propun sa avem 2 tipuri de milestone-uri:
* Time-based, care incrementeaza versiunea cu _0.0.1_. Acolo punem tichete pentru care stim ca avem oameni sa le faca intr-un interval de timp relativ scurt. Le vom sincroniza aproximativ cu sedintele asociatiei sau cu rundele de concurs.
* Feature-based, care incrementeaza versiunea cu _0.1_. Acolo punem tichete majore, care merita o incrementare a versiunii. Cand gasim oameni mutam tichetele in _+0.0.1_. Cand ramanem fara tichete intr-un astfel de milestone ii facem release.
h3. Quality Asurrance
Noi am rulat in mare parte site-ul direct din trunk si am avut de multe ori bug-uri mari pe site-ul live. Motivul principal a fost ca sa nu stagnam development-ul prin birocratie excesiva. Este totusi destul de riscant si neprofesional sa rulam direct din trunk.
Putem sa avem un site special de development pe trunk, dar care este marcat explicit pentru testing. Site-ul poate sa sa se updateze singur la ultimul trunk si sa ruleze teste automate folosind un dataset redus (pentru a minimiza efectele unei gauri de securitate). Scripturile necesare nu sunt deloc greu de scris. Ramanem totusi la idea de a rula din svn, nu are sens sa facem o procedura separata de upgrade/deployment.
Noi avem o singura instanta care este in productie la orice moment. Asta inseamna ca nu are sens sa mentinem branch-uri separate stabile sau instabile. Noi nu facem "release-uri" publice in sensul standard si e posibil ca layout-ul standard subversion sa nu fie foarte util. Propun sa ne facem un layout custom:
* branches/more-ajax: Sandbox-uri pentru schimbari majore
* trunk/: Bleeding edge. De aici rulam site-ul de test. Bugs welcome!
* release/infoarena-3.1.7: De aici rulam site-ul live. Facem commit cu multa grija.
* external/smf-2.1.9: Pentru pachete externe care au nevoie de merge; echivalent vendor.
Cand stabilizam copiem ultimul trunk in release/ si testam un pic (o saptamana) pana e stabil. Abia dupa asta migram live pe ultimul release, si facem doar fix-uri pentru bug-uri majore. Ideal ar fi sa nu scriem in release dupa ce migram site-ul live.
h3. Cum alegem tehnologie
De multe ori s-a discutat ca infoarena sa folosesca o anume librarie avansata sau framework. Folosirea unei librarii externe este o decizie majora care trebuie analizata cu grija. O dependinta externa trebuie sa satisfaca urmatoarele conditii:
* Sa fie simplu de inclus. Sa existe macar pachete debian si fedora; sau sa poata fi copiata direct in svn. *Nu* se accepta installere din afara distributiilor de linux.
* Sa ne ajute cu ceva major care ar fi foarte greu sa facem de la 0.
* Sa fie cunoscuta si dezvoltata activ. Altfel probabil ca respectiva librarie nu e foarte buna.
* Sa nu impuna restrictii asupra arhitecturii site-ului. Asta elimina cam toate framework-urile.
* Scalabil, testabil, etc.
Mai mult, cine propune o dependinta trebuie sa dovedeasca ca indeplineste toate conditiile de mai sus. Putem sa facem asta prin tichete speciale de "investigare". Individul responsabil de un asemenea tichet trebuie sa invete tehnologia respectiva si sa ne ajute sa decidem daca merita folosita. Rezultatul unui asemenea tichet este un demo, care poate fi un branch sau o chestie from-scratch. Acel demo trebuie sa demonstreze viabilitatea respectivei tehnologii, dar nu trebuie sa fie neparat imediat utilizabil in trunk.
Idei de demo-uri:
* Wiki extern: putem folosi wiki din exterior si construi site-ul peste el?
* 'SqlAlchemy':http://www.sqlalchemy.org: De facut o schema sql alchemy pentru tabelele de scoruri. Cat de usor se fac query-uri de statistici si cat de rapide sunt?
* 'Selenium':http://www.openqa.org/selenium/: Cineva sa faca niste teste folosind Selenium peste infoarena2. Cum anume pot fi stocate in svn si rulate de oricine?
* Form-uri: Nu avem o solutie definitiva pentru facut si validat form-uri. Cineva sa ia o asemenea librarie si sa faca CRUD de task-uri, si sa demonstreze ca e sensibil mai usor decat manual.
* Tabele: Demo de tabel de scoruri prin AJAX. Cristi: this means you.
* BL prin HTTP: Se poate face un BL accesibil direct prin http, fara a scrie controllere pentru fiecare functie? Poate evaluatorul sa acceseze functii de BL de pe live, fara access TCP la baza de date?
* Wiki in subversion: Ar avea sens sa tinem textblock-uri si atasamente in subversion? Demo de manipulare cu teste de viteza.
Probabil ca aceste demo-uri vor fi de fapt formulate sub forma de IAP-uri. Momentan inca nu am decis exact ce tehnologie folosim in infoarena3. Vom incepe sa facem IAP-uri doar cand structura de baza a site-ului este functionala
h2. Arhitectura infoarena3
Ca sa evitem probleme tehnice din infoarena2 ne trebuie un o arhitectura clara si solida pe care sa putem construi. Trebuie sa evitam a ne "infunda" din nou. Acum nu avem inca nici un fel de cod scris si totul poate fi schimbat foarte usor.
h3. Python ca limbaj de programare
Propun sa scriem infoarena3 in python. Este un limbaj foarte OK pentru programarea web, cu multe librarii disponibile. Este recunoscut pentru a fi foarte foarte curat si a incuraja un stil frumos de cod. Avem oameni disponibili sa programeze in python.
Este foarte dificil sa faci o alegere desteapta intre limbaje de programare, atat de dificil incat majoritatea discutiilor pe acest subiect sunt neproductive. Noi am dat cu banul si am ales python. Nu exista motive foarte bune pentru python dar nici motive foarte bune pentru a alege altceva.
h3. Baza de date
Propun sa folosim 'SQLAlchemy':http://www.sqlalchemy.org/ pentru a manipula baza de date, sau macar partea de expresii SQL. Ne scapa de a formata de mana conditii de where pentru chestiile simple, si suporta mai multe baze de date. Trebuie investigat cu multa grija si testata performanta.
Vrem sa suportam minim MySQL pentru productie si SqlLite pentru development. Ar fi foarte util sa putem rula site-ul in modul de development fara o procedura complexa de setup.
Avem nevoie de o schema a bazei de date inainte de a ne apuca serios de lucru. Probabil ca o sa scriem direct modelul sql alchemy. Cateva idei:
* Atasamentele intra in baza de date ca blob-uri. Facem cache pe disk in serveru' de web; dar doar cache.
* Refacem ia_textblock, face doar stocare versionata de blob-uri. De investigat merge cu ia_file.
* Id-ul numerice peste tot.
* ia_task si ia_task_classic, ia_task_output
* ia_round si ia_round_classic. ia_round_archive?
* ia_wiki separat: contine textblock si securitate private/protected/public.
* ia_blog separat: contine data de publicare, autor, tag-uri (in ia_blog_tag)
* Bagam id-uri de topic-uri smf in ia_task si ia_blog.
* Spargem ia_score
* ia_log din start. Il folosim pentru teste.
h3. Wiki
La baza site-ului vom avea o componenta de versionare de fisiere. Aceasta componenta nu stie absolut nimic de useri, probleme, securitate sau tag-uri. Orice semnificatie a fisierelor este data doar de mai sus. De la aceasta componenta ne dorim urmatoarele:
* Fetch rapid, cu cache transparent pe disc. Nu servim fisiere direct baza de date.
* Istorie completa a modificarilor
* Delete reversibil, care sa apara in istorie
* Mutare/copiere pastrata in istorie.
* Posibilitatea de a distruge complet o revizie
Nu avem nevoie de:
* Directoare. Ne trebuie doar fisiere.
* Meta-date. Versionam doar blob-uri; eventual cu cateva coloane strongly-typed (mime type?)
* Notiuni de securitate.
* Schimbari atomice pe mai multe fisiere.
Este dificil sa satisfacem toate cerintele folosind tabele de SQL, dar se poate face. Multe cerinte pot fi relaxate pana aproape de nivelul infoarena2. O varianta interesanta ar fi sa folosim subversion pentru versionare, dar din pacate nu se mapeaza perfect pe ce vrem noi. De investigat si discutat.
h3. MVC
Avem ca si in infoarena2 un singur entry-point in tot site-ul. Acolo analizam requestul (ne uitam la url si query string) dupa care pasam munca la un controller. Un controller este o functie python care se ocupa de un request de la cap la coada. Controllerele nu se cheama niciodata unul pe altul.
Multe controllere vor folosi probabil suportul de versionare. Trebuie sa putem refolosi usor codul de editare si istorie si sa il integram in alte componente. Ne dorim un editor integrat de task-uri si de profil de utilizator.
Doar componentele mari ale site-ului vor avea propriile controllere. Pentru un tabel rapid sau un raport solutia preferata este sa facem un macro.
h3. Securitate
Securitatea se va face in codul de BL si va fi implementata distinct pentru fiecare tip de entitate. Fiecare utilizator va avem anumite permisiuni global iar pentru unele entitati vom putea adauga drepturi per-utilizator. Incercam sa facem securitatea cat mai simplu; in cod. Incercam sa evitam securitate declarativa dar prea complexa, cum e cea din windows. Nu vom suporta:
* Id-uri globale de obiecte securizabile.
* Grupuri de obiecte.
* Logica de allow/deny.
* Ierarhii.
* Grupuri de utilizatori.
Fiecare utilizator va avea anumite drepturi globale. Aceste drepturi pot fi editate doar de administratori, folosind checkbox-uri sau dropdown-uri pe pagina de cont. Aceasta pagina trebuie sa fie accesibila din pagina de profil. Drepturile globale vor fi hard-codate la un moment dat, dar le putem schimba din cod.
* Daca utilizatorul este admin
* Daca poate propune probleme
* Daca poate posta pe blog
* Daca poate edita enunturi de probleme (pentru neclaritati).
* Daca este moderator pe forum (challenge!)
Pentru probleme o sa avem o lista in care pot fi adaugati useri cu drepturi.
* Propunator: Aproximativ orice
* Reviewer: Modificari in enunt, download de teste.
* Altceva?
Pentru runde putem incepe prin a permite accesul doar administratorilor, dar ulterior putem adauga o lista de useri cu drepturi:
* Responsabil: poate sa modifice orice.
* Tester: poate submita la probleme in afara concursului.
* Invitat: pentru concursuri private sau finale live.
h3. Logica de concursuri
Vrem sa suportam mai multe tipuri de probleme sau runde, fara sa oprim evaluatorul. Asta este foarte realizabil daca nu ne incurcam cu sisteme multe prea generice. Nu o sa mai avem descriptori de securitate si ia_parameter_values, toate datele noastre vor fi accesibile in SQL curat. Asta inseamna ca putem sa facem query-uri complexe pentru determinat ce job-uri trebuie evaluate.
h3. Integrare SMF, textile.
Integrarea SMF o se faca in cea mai mare parte cu query-uri direct in tabele de SMF. Tabele SMF sunt relativ inteligibile. Pentru cazurile in care nu ne ajunge putem investiga un mod de a chema cod php din python in acelasi request. Aproape sigur se poate, dar s-ar putea sa ne restranga la mod_python. Daca se poate atunci putem sa evitam sa duplicam codul de header/footer spre exemplu, dar nu este critic.
Exista un parser textile pentru python dar nu esti dezvoltat activ. Asta nu e o problema; il introducem in repository si il modificam pentru ce avem nevoie. Putem face teste automate ca sa verifice ca output-ul este foarte similar. In infoarena2 am incercat sa modificam cat mai putin parser-ul de textile pentru a putea lua update-uri upstream. Asta nu s-a intamplat si cred ca e mai bine sa modificam fara mila.
h2. Plan de bataie
Ajunge cat am batut campii, trebuie sa ne apucat si de munca. Primul release public se va numi infoarena 3.0 si are ca criteriu implementarea intregii functionalitati infoarena2. Pana atunci vom face dezvoltarea intr-un branch separat din acelasi repository.
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".
h3. Ce se intampla cu infoarena2 si trac.
Un asemenea sistem ar mentine mai multa ordine in tichetele din trac.
Infoarena2 intra in maintenance-only mode; unde nu reparam decat chestii foarte necesare. Facem release 2.1.5 si trecem la layout-ul de repository propus pentru infoarena3. Bagam toate tichetele intr-un milestone de "Infoarena 2.99 blue-sky" si mutam in 2.1.6 doar tichetele pentru care putem asigna un om.
h3. Demo-uri
Pentru infoarena3 facem tichete de investigare si 2 milestone-uri: "3.0" si "3.99 blue-sky" cu aceasi semnificatie. Momentam lucram in branches/infoarena3, facem switch la trunk cand dam release de 3.0. O sa avem si alte branch-uri de research pentru 3.0.
S-a propus de multe ori sa folosim framework-uri si librarii avansate. Adaugarea unei dependinte necesita un efort mare de invatare care se poate dovedi eventual inutil. Inainte de a inghiti o noua dependinta trebuie sa ne asiguram ca se merita. Are sens sa face tichete speciale de "investigare". Individul responsabil de un asemenea tichet trebuie sa invete tehnologia respectiva, si sa ne ajute sa decidem daca merita folosita. Rezultatul unui asemenea tichet este un demo, care poate fi un branch de infoarena2 sau o chestie from-scratch. Acel demo trebuie sa demonstreze viabilitatea respective tehnologii.
h3. Barebones read-only site
Exemplu de demo-uri care ar merita facute:
Ca prim pas trebuie sa facem intai partile de content. Daca avem tot continutul importat putem sa facem teste foarte realiste si sa vedem cat de viabile sunt ideile noastre. Nu incepem cu pagina de inregistrare utilizator. Ne trebuie:
* *SqlAlchemy*: O schema sql alchemy pentru tabelele de scoruri, inclusiv teste de performanta.
* *Selenium*: Cineva sa faca niste teste folosind Selenium, probabil peste infoarena2. Cum anume pot fi stocate in svn si rulate de oricine?
* *Form-uri*: Nu avem o solutie definitiva pentru facut si validat form-uri. Cineva sa ia o asemenea librarie si sa faca CRUD de task-uri, si sa demonstreze ca e sensibil mai usor decat manual.
* *Tabele*: Demo de tabel de scoruri prin AJAX. Cristi: this means you.
* *BL prin HTTP*: Se poate face un BL accesibil direct prin http, fara a scrie controllere manuale? Poate evaluatorul sa acceseze functii de BL de pe live, fara access local la baza de date?
* *Wiki in subversion*: Ar avea sens sa tinem textblock-uri si atasamente in subversion? Demo cu teste de viteza.
* Schema sql alchemy pentru baza de date.
* Script import baza de date
* Servire textile cu macro-uri
* Cateva macro-uri (scoruri!)
* Cateva form-uri (editare probleme!)
h3. Arest la domiciliu
h3. Coding camp public
Facem intai un numar de demo-uri pentru a ne decide ce anume folosim in infoarena3. Ne adunam cativa oameni si contruim baza (index.py, structura de directoare, server debaza de date). Apoi chemam lumea pe santier. Facem un mare coding camp la Leonard si Mircea acasa, care sa dureze o saptamana intreaga sau chiar 2. Putem invita si utilizatori infoarena care vor sa ne ajute. Sigur ne putem face cu totii timp sa lansam infoarena3 (concediu). O lansare de success inseamna un site utilizabil la care va continua dezvoltarea si in timpul liber (*because it's fun!*).
Dupa ce avem site-ul in forma read-only aproximativ complet putem sa facem coding camp-uri cu multa lume pentru a continua dezvoltarea. Aducem oameni, ii invatam cum sa faca branch-uri si ii punem sa faca form-uri si macro-uri.
