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().
h3. 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 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.
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.
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 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 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 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.
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.
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.
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". 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 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 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 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 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 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) 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.
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. 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, iar daca BL-ul nu are greseli atunci UI-ul nu poate sa strice nimic (decat experienta utilizatorului). A se vedea punctul urmator.
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, si in PHP este mult mai important sa testezi codul.
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, 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 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.
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, 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.
h3. ia_textblock, ia_textblock_history
