In general fiecare a facut cum l-a taiat capul. Pe toti ne-a taiat cam stramb.
h2. Propuneri
h2. Organizare pentru infoarena3
Am adunat niste idei care sa ne ajute sa nu duplicam problemele din infoarena2. Nu ajunge sa ne plagem ca nu ne place codul, trebuie sa vedem cum facem mai bine.
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. Folosim branch-uri
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(svn merge) in trunk. Asta face trunk-ul sa fie mai stabil si sa nu mai contina "cod mort".
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".
Un branch poate sa faca oricine are access la subversion fara sa intrebe 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 branchul poate fi respins. Daca un branch este respins poti sa ii rezolvi problemele si sa il propui din nou pentru includere in trunk.
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 atomica in trunk, care sa nu introduca bug-uri. Este in continuare OK sa aplici 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.
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 sa rezolvi tichetele 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.
Un tichet "acceptat" trebuie sa aiba un owner care este responsabil sa rezolve acel tichet pana la o anumita data. Un dead-line 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 dead-line-uri ar fi un impuls interior pentru fiecare din noi.
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.
Asta este foarte similar cu sistem-ul mare de roluri din 'echipa infoarena':echipa-infoarena, care momentan 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?
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.
%{color:red}Ce urmeaza de aici este inca in constructie%
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
++0.0.1 time-based, ++0.1 feature-based, +1 never. Incepem la infoarena3 0.1; first public release is infoarena3 3.0
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.
h3. Folosim branch-uri
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.
Nu mai rupem trunk-ul, toata lumea face brach. Dam lejer acces la svn, dar dam in cap daca face prostii in trunk.
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
Orice idee de a adauga o dependinta porneste de la minus 100 de puncte.
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:
h3. Ce tehnologie folosim (debatable)
* 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.
Python(wsgi pur) + sql alchemy + o librarie de textile.
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.
h2. Plan de bataie
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.
Cum incepem development.
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
h3. Barebones read-only site
h2. Arhitectura infoarena3
Facem intai site-ul in modul read-only: all content, some macros, no forms, no security. Bagam teste de performanta pe el. What does done mean?
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. Coding camp public
h3. Python ca limbaj de programare
Chemam lumea pe santier sa praseasca form-uri si macro-uri.
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.
h1. Old text, de reintegrat.
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.
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 dezvoltare. Teoretic multe ar putea fi aplicate si pentru o dezvoltare in continuare a codului infoarena2.
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.
h3. Responsabilitati
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:
h3. Demo-uri
* 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.
S-a propus de multe ori sa folosim framework-uri si librarii avansate. Adaugarea unei dependinte necesita un efort mare de invatare pentru toti cei implicati care se poate dovedi eventual inutil. Inainte de a inghiti o noua dependinta trebuie sa ne asiguram ca se merita. Eu propun 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 de infoarena2 sau o chestie from-scratch. Acel demo trebuie sa demonstreze viabilitatea respective tehnologii, dar nu trebuie sa fie neparat imediat utilizabil in trunk.
h3. Wiki
Exemplu de demo-uri care ar merita facute:
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:
* '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.
* Cat de bine se poate integra SMF in cod python?
* Exista implementare textile in python. Trebuie modificata incat sa dea aceleasi rezultate cu textile din php. Se poate testa foarte usor, trebuie ca toata textila din infoarena2 sa se parseze identic.
* 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.
h3. Arest la domiciliu
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.
* Facem demo-uri si ne decidem ce tehnologii folosim.
* Facem un nou branch svn, cu structura de directoare etc.
* Facem schema bazei de date, cat sa acomodeze infoarena2.
* Chemam lumea la santier
h3. MVC
Facem un mare santier in Bucuresti la Leonard si Mircea acasa, unde putem chema utilizatori infoarena existenti deja sa ne ajute (eventual cu macro-uri, form-uri etc). Pentru asta avem nevoie de o structura de baza functionala si pentru asta nu ajuta numerele. Asta inseamna ca intai o sa ne adunam developerii infoarena2 pentru un fel de bootstrapping.
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.
h3. Ce se intampla cu infoarena2 si 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.
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.
h3. Barebones read-only site
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:
* 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. Coding camp public
Dupa acel mare santier lansam site-ul, care ar trebui sa fie utilizabil. O lansare de success inseamna ca vom avea multe commit-uri de acasa, eventual de la niste developeri noi. *Nu* vom avea un design nou si toata textila va fi importata fara modificari. Bineinteles ca toate astea sunt open to debate intr-o sedinta infoarena.
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.
