Diferente pentru propuneri/3-infoarena3 intre reviziile #22 si #23

Nu exista diferente intre titluri.

Diferente intre continut:

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.
h2. Un plan de atac
h2. Idei pentru un plan de atac
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.
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. Branching
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".
Un asemenea sistem ar mentine mai multa ordine in tichetele din trac.
Un asemenea sistem ar mentine mai multa ordine in 'tichetele din trac':http://hackers.devnet.ro/report/3. Un tichet ar fi pus la un milestone doar daca cineva isi asuma efectiv responsabilitatea sa-l rezolva. Momentan ticketele sunt sortate in categorii de genul "viitor", "viitor indepartat" si "get out of my face".
h3. Demo-uri
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.
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.
Exemplu de demo-uri care ar merita facute:
* *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?
* *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 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.
* *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.
h3. Arest la domiciliu
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!*).
# 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 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.
 
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.

Nu exista diferente intre securitate.

Topicul de forum nu a fost schimbat.