h1. IAP #1: Infoarena3

h1. IAP #3: Infoarena3

==Include(page="template/iap")==

|_. Data      | 2007-11-08                                      |
|_. Autor(i)  | ==User(type="tiny" user="fluffy")==             |
|_. Stare     | S-a dezbatut, acum e din nou *_IN-CONSTRUCTIE_* |

|_. Data      | 2007-11-08                              |
|_. Autor(i)  | ==User(type="tiny" user="fluffy")==     |
|_. Stare     | *_IN-DEZBATERE_* Propus pentru aprobare |

h2. Abstract
Pe scurt, codul din spatele site-ului infoarena2 este intr-o stare foarte proasta si trebuie rescris. Pagina aceasta incearca sa explice in detalii problemele din cod, si incearca sa demonstreze ca rescrierea soft-ului este cel mai bun mod de a avansa site-ul.

In sedinta din '24 octombrie':planificare/sedinta-20071024 eu ( ==user(user="fluffy")== ) am fost insarcinat sa scriu aceasta pagina. In urma sedintei din '7 noiembrie':planificare/sedinta-20071107 s-a decis sa reformulam aceasta pagina sub 'format IAP':propuneri. Propunerea a fost discutata si au venit cateva observatii din partea lui ==User(user="wickedman")== la care trebuie sa raspund.

In sedinta din '24 octombrie':planificare/sedinta-20071024 eu ( ==user(user="fluffy")== ) am fost insarcinat sa scriu aceasta pagina. In urma sedintei din '7 noiembrie':planificare/sedinta-20071107 s-a decis sa reformulam aceasta pagina sub 'format IAP':propuneri. Propunerea a fost discutata si au venit cateva observatii din partea lui ==User(user="wickedman")==

Am pus si un 'topic pe forum':http://infoarena.ro/forum/index.php?topic=2243.0, dar pana acum feedback-ul a fost sub asteptari.

Am pus si un 'topic pe forum':forum/index.php?topic=2243.0, dar pana acum feedback-ul a fost sub asteptari.
 
*Update:* Propun sa votam pe idea de a rescrie site-ul in python si sa aprobam acest IAP. Propunerea a devenit mult prea lunga si nu cred ca e practic sa intram in prea multe detalii de arhitectura. Daca o aprobam putem sa copiem bucati in planificare/development si sa facem IAP-uri pentru alte idei majore. Nimic din ce am scris nu ramane batut in cuie.

h2. Motivatie

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

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

Pentru noi nu are sens sa mentinem branch-uri stabile si instabile, pentru ca avem o singura instanta care este in productie la orice moment. Site-ul live o sa-l rulam direct din svn de pe branch-ul ultimului release; spre exemplu din _branches/infoarena3-3.2.7_. Daca apare un bug urgent il putem rezolva direct pe live cu commit in acel branch. *NU* vom rula din _tags/infoarena3-3.2.7_, care trebuie sa ramana read-only.

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.

Asta presupunem ca folosim layout-ul oarecum standard din subversion. Este discutabil daca acesta este bun pentru cazul nostru. O idee alternativa ar fi sa tinem branches doar pentru modificari mari si urate, trunk pentru ultima versiune si niste directoare release/infoarena3-A.B.C de unde rulam trunk-ul.

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:

Nu avem resurse sa facem QA mai avansat de atat. Daca facem review cu grija la ce intra in trunk si mentinem o suita de teste automate putem sa ne descurcam destul de bine.

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

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.

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

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

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

* 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 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

* 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

Pentru infoarena3 primul release public va fi 3.0. Putem denumi versiunile intermediare ca infoarean3-0.1

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

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

Chemam lumea pe santier sa praseasca form-uri si macro-uri.

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.