Diferente pentru propuneri/3-infoarena3 intre reviziile #48 si #49

Nu exista diferente intre titluri.

Diferente intre continut:

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
Pentru infoarena3 primul release public va fi 3.0. Putem denumi versiunile intermediare ca infoarean3-0.1
%{color:red}Ce urmeaza de aici este inca in constructie%
 
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. Orice 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 distributiei 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 buna de nimic.
* Sa nu impuna restrictii asupra arhitecturii site-ului. Asta elimina cam toate framework-urile.
* Scalabil, testabil, etc.
h3. Ce tehnologie folosim
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 viabilitateai respective tehnologii, dar nu trebuie sa fie neparat imediat utilizabil in trunk.
Momentan propun sa folosim urmatoarele tehnologii:
* Python: Limbaj de programare.
* 'WSGI':http://docs.python.org/lib/module-wsgiref.html: Interfata cu server-ul de web.
* Apache2 cu 'mod_python':http://www.modpython.org sau 'mod_wsgi':http://www.modwsgi.org/: Server de web in productie.
* 'wsgiref.simple server':http://docs.python.org/lib/module-wsgiref.simpleserver.html: Server web pentru development.
* 'SqlAlchemy':http://www.sqlalchemy.org/: Interfata cu baza de date.
* MySQL ca baza de date in productie.
* SqlLite ca baza de date pentru development.
* SMF ca forum. De investigat integrarea.
* ???: librarie de textile.
Idei de demo-uri:
Vrem sa putem rula site-ul in development mode fara nici un fel de configuratie, cu un server de web in linie de comanda pe un port mare.
* 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.
h2. Plan de bataie
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 face IAP-uri doar and structura de baza a site-ului este gata.
Cum incepem development.
h2. Arhitectura infoarena3
h3. Barebones read-only site
Ca sa evitem probleme tehnice din infoarena3 ne trebuie un o arhitectura clara si solida pe care 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.
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?
h3. Python ca limbaj de programare
h3. Coding camp public
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.
Chemam lumea pe santier sa praseasca form-uri si macro-uri.
Este foarte dificil sa faci o alegere desteapta intre limbaje de programare. Am dat cu banul si am ales python. Nu exista motive foarte bune pentru python dar nici nu vad motive foarte bune pentru a alege altceva. Este foarte dificil sa compari inteligent limbaje de programare, atat de dificil incat majoritatea discutiilor pe acest subiect sunt neproductive.
h1. Old text, de reintegrat.
h3. Baza de date
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.
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 testat 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.
h3. Responsabilitati
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
h3. Demo-uri
h3. MVC
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. Securitate
Exemplu de demo-uri care ar merita facute:
h3. Logica de concursuri
* '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.
h2. Plan de bataie
h3. Arest la domiciliu
h3. Barebones read-only site
* 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
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?
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.
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.
Chemam lumea pe santier sa praseasca form-uri si macro-uri.

Nu exista diferente intre securitate.

Topicul de forum nu a fost schimbat.