OOP-leken II: Nu kör vi ett strukturerat projekt!

Tack för bra input!
Ja, att vi ska ha så mycket tabeller som möjligt för att inte låsa upp sig i databasdesignen är bra. Jag har ju inte tänkt på allt och här är meningen att vi ska komma fram till en optimal lösning innan vi börjar jobba på det.

Jag har själv alltid jobbat med tabellprefix för fältnamnen, men det är självfallet något jag kan frångå om majoriteten tycker att det är bättre utan prefix.

Å andra sidan, ang. publiceringsdatum så tycker jag att det kan vara flexibelt, precis som jonthe12 instämde, att dela upp det i year, month, day. Å andra sidan klarar väl SQL av BETWEEN mellan två datum, så länge fältet man jämför med är ett äkta och korrekt formaterat date-fält?

I like this thread.

Vem slänger upp en github?

Jaap, är attributet märkt som datum så får man tillgång till en massa trevliga funktioner (http://dev.mysql.com/doc/refman/5.5/...unctions.html). För att få år, månad och dag skriver man bara SELECT YEAR(date), MONTH(date), DAY(date). Endast riktiga datum kan lagras (om man anger datatypen DATE eller liknande).

Största fördelen är nog framförallt att man kan jobba mot databasen lätt. Exempelvis om man vill ha datum senare/tidigare än ett valt. Har man ett attribut per del av datumet blir det ganska knepigt. Exempelvis hur specifierar man att man vill ha böcker mellan 2010-03-01 och 2011-04-01.
WHERE year > 2010 AND month > [problem] AND day [problem]....
Istället för att bara ange att date skall vara mellan två datum som du nämnde.

Angående tabellprefix så är det förstås en smaksak. Jag använda ofta prefix förr. Även i klasser. Men kunde aldrig förklara varför. Exempelvis $user->getUserId(); istället för $user->getId(); är ju oftast bara onödigt.

Gjorde en snabbt igår: https://github.com/diggan/OOP-leken

Kanske bättre vi använder en privat men då kostar det pengar, kanske använda någon annan sida för Git?

Ska fixa så att filerna laddas upp på en server nattligt också.

Varför de?

Du kan använda dig en vanlig server med SSH-access och låta folk pusha dit.
Hela iden med kolaborativ utveckling försvinner dock.

Tänk även på att man inte bara betalar per privat repo på Github, utan även hur många utvecklare som ska få tillgång till varje repo.

Ett litet tips är att jobba lite mer på riktigt den här gången.
Låt vem som helst forka orginal-projektet, i form av en publik repo, när personen i fråga känner sig klar, i form av fungerande tester och välskriven dokumentation så görs en pull-request.

Att låta 15 (relativa nybörjare) pusha till samma repo kommer att bli rörigt.
Om vi ignorerar de faktum att majoriten av koden kommer bli oläsbar, så kommer även merge-problem att dyka upp lite här och var. Folk som inte är vana vid git, eller någon slags versionhantering pushar sina ändringar till master, hela tiden, ignorerar omedvetet mergefel. Andra utvecklare klonar projektet - och fel sprids vidare.

Tack för alla svar! Superkul att det drivs på av andra användare, både amatörer (som jag) och proffsiga utvecklare som dessutom har erfarenhet av att jobba i större projekt.

Jag måste säga att vi kanske ska tillbaka till ritbordet och först reda ut hur vi ska skapa en sund hantering av hela projektet, d.v.s. skapa ett generellt regelverk för hur man ska hantera kod.

Som snouser säger kan det ju bli en soppa om vi är 15 amatörer som alla bidrar men inte riktigt vet hur vi ska jobba tillsammans på ett optimalt sätt.

Jag är tyvärr helt grön på detta, så någon med erfarenhet (gärna både bra och dåliga) får gärna dra lite om hur man bör jobba i ett projekt.
Hittills är vi i alla fall ett par stycken som visat intresse för att jobba med koden och det är då förstås önskvärt att slippa många kockar.

EDIT: Och ta det inte negativt när jag säger amatörer. Jag själv är en amatör som inte har stor erfarenhet av PHP OOP, eller ens PHP i en ordentlig projektstruktur.

Frågan är om vi dessutom ska utse en projektledare som ska hålla i trådarna. Förstås inte "diktatoriskt", utan den med god förståelse hur det är att driva ett projekt med flera utvecklare.

Jag kan trösta dig med att jag syftade på personer som jobbat med PHP i ett par veckor, kanske dagar. Inte dig med andra ord.


Innan jag kommer med lite tips på hur arbetsflödet skulle kunna se ut så undrar jag ifall någon här har någon erfarenhet av Githubs variant.

Forka => Bygga => Pull-Request => Merge

Inte så van vid git än men om jag skulle t.ex. skulle skriva en klass med några funktioner sparat i en php fil. Då ska den pushas till en egen bransh va?
Om jag sedan gör ändringar i koden?
Ny bransh?
eller bara vid stora ändringar?

Själv har jag ingen erfarenhet alls av git så skulle nog behöva en lektion i det där ifall vi ska köra på det.

Har jag förstått det rätt, man forkar - får då en kopia av mastern som man själv kan ändra i
vill man föreslå ändringen så kör man pull, andra kan sedan diskutera ändringen etc. och den kan sedan accepteras in i mastern?

Ungefär så. Den officiella tutorialen är bra: http://www.kernel.org/pub/software/s...ttutorial.html

Oj vad skoj! Kommer delta om man får chansen till det, är ingen naturbegåvning inom OOP, men detta ska följas!


Vad är skillnaden mellan authors och publishers?

Författare jämf. (bok-)förlag.