Home

Welcome to the ese2012-team5 wiki!

Protokolle:

Wie kommunizieren? Joel schaut nur auf mailing-list, intern in Gruppe wird Facebook verwendet
Neu anfangen oder Codebasis von jemandem nehmen? neu anfangen, anhand vorhandener aufgaben
Nächstes Meeting wird von einer person unseres teams geleitet Person noch zu bestimmen,Struktur überlegen
Es werden immer einzelne Features festgelegt, diese werden auf nächste Woche implementiert, dann werden wieder neue festgelegt
Pro Woche müssen insgesamt 2 Punkte gemacht werden. Mit Joel diskutieren wie viel Punkte ein jeweiliges Feature geben soll.

Features:

As a visitor, I can register in the system with username/password, picture and a list of interests. Critical 1.00 Points
As a seller, I can enter and edit items that are "inactive" Critical 0.25 Points
As a seller, I can turn "inactive" items into "active" items to sell Critical 0.25 Points
As a seller, I can turn "active" items into "inactive" items to edit them Critical 0.25 Points
As a buyer, I can buy an active item at the fixed priced indicated. Critical 0.25

Spätere Features:

Sicherheit: Ganze sicherheit(nicht registrierter user kann nicht auf alle seiten zugreifen), man kann allem sagen ob es public ist oder nicht! auf jeder seite user überprüfen! passwort verifizieren. -> mit hash oder rsa arbeiten
nicht authentifizierter User sieht nur Items, welche angeboten werden, z.b. 4 random items
Passwort änderbar, rücksetzen falls man es vergisst -> mail mit neuem pw schreiben
Account mit geld laden (kreditkarte, rechnung, paypal)
Wir sind frei im Design, Kunde muss einfach zufrieden sein (schlicht, farbe weniger wichtig, usability)
Organization (User können beitreten, user erlauben dass man im Namen von Firma Items bestellen kann)
Email versenden wird häufig verwendet -> schauen wie das geht, später Email zu User hinzufügen
Activity Log
Mehrsprachigkeit
Als Seller kann ich alte Beschreibung eines Items wieder zurückholen (Backup, Versionierung)
Bilder auch für items möglich
wir müssen sagen wenn userstory zu gross oder zu schwierig ist! evt aufsplitten.
im moment nur 1 repository, schon jetzt verschiedene branches machen! auf master branch nur funktionierendes laden. dann "integration-branch" wo immer entwickelt und gepusht wird.
häufig committen und lokale branches machen! nie committen wenn etwas nicht läuft
coach schaut auf design (application) documentation & testing für kunde ganzen shop sehr einfach gestalten

aaron schaut auf sinatra wegen fileupload -> sendet es an mailing list
html als nächster anlaufpunkt nach sinatra -> nicht bei ruby schauen
passwort überprüfen mit ajax (aber viel aufwand) -> andere möglichkeit: liveüberprüfung, session verwenden (kann sachen speichern die im letzten formular eingegeben wurden)
passwort mit hash-> tutorial github zombiecalypse -> kapitel über hashen
userhirarchie -> einfachste möglichkeit: relation
löschen etc. -> formular verwenden, rest über url ansprechen
möglichst viele routen! weniger mit if/else
arbeit aufteilen in controller, views und models