tuxletics-devel

[Tuxletics-devel] Post-0.1.0

[Tero K. <te...@us...>]

Moi!

Nyt kun kurssi j=C3=A4=C3=A4 taakse voimme paneutua paremmin siihen Pette=
rin jo=20
viime tapaamisessa esille nostamaan aiheeseen jatkosta. T=C3=A4ss=C3=A4 o=
mia=20
ajatuksiani tavasta jatkaa kehityst=C3=A4, kommentoikaa jotta l=C3=B6yd=C3=
=A4mme=20
yhteisen linjan.

Ensinn=C3=A4kin, useista projekteista oppineena, sanoisin ett=C3=A4 meill=
=C3=A4 tulisi=20
olla jokin yhteinen visio tai tavoite ohjaamassa etenemist=C3=A4. T=C3=A4=
ss=C3=A4=20
tapauksessa n=C3=A4kisin jonkin karkean listan Tuxletics 1.0:n=20
ominaisuuksista ajavan asian. Pitk=C3=A4n t=C3=A4ht=C3=A4imen tavoite kan=
nattaa sitten=20
jakaa osiin, eli t=C3=A4ss=C3=A4 k=C3=A4ytt=C3=A4isin sit=C3=A4 roadmap-i=
deaa, jonka=20
kokouksessakin toin esille.

Roadmapissa ei pit=C3=A4isi mielest=C3=A4ni olla p=C3=A4iv=C3=A4m=C3=A4=C3=
=A4ri=C3=A4, ainakaan tiukkoja,=20
vaan olen itse "when it's ready"-mallin kannalla. T=C3=A4ss=C3=A4 voivat =
jotkut=20
teist=C3=A4 olla eri mielt=C3=A4, mutta kompromissi lienee varmasti l=C3=B6=
ydett=C3=A4viss=C3=A4.

Sen sijaan roadmap listaisi versiot, joista k=C3=A4ytt=C3=A4isin numeroin=
tia=20
0.2.0, 0.3.0, ..., 1.0.0. Jokaiselle versiolle olisi sitten asetettu=20
v=C3=A4litavoitteet (ominaisuudet) ja tietysti jokainen versio sis=C3=A4l=
t=C3=A4isi=20
aiemmat tavoitteet. T=C3=A4m=C3=A4n rakentamisessa l=C3=A4htisin siit=C3=A4=
, ett=C3=A4 ensin=20
pohditaan ne 1.0:n tavoitteet, eli milloin peli on mielest=C3=A4mme "valm=
is".=20
Sitten sijoitamme ker=C3=A4tyt tavoitteet roadmapiin sopiviksi katsomiemm=
e=20
versioiden kohdalle ja tarkennamme ainakin seuraavan version tavoitteet=20
mennen matalammalle tasolle kuin 1.0:n tavoitteiden kohdalle. Ehk=C3=A4=20
lis=C3=A4=C3=A4mme matalamman tason tavoitteita joihinkin muihinkin.

Sitten toteutetaan aina seuraavan version tavoitteet ja julkaisun=20
j=C3=A4lkeen tarkistetaan roadmap, sill=C3=A4 tavoitteet voivat muuttua a=
jan my=C3=B6t=C3=A4.

Tuo projektin etenemisest=C3=A4. Kommentteja t=C3=A4h=C3=A4n?

Harkinnan arvoinen aihe on my=C3=B6s kehitysmallin tarkentaminen. T=C3=A4=
ll=C3=A4=20
hetkell=C3=A4 voisi sanoa, ettei meill=C3=A4 kehitt=C3=A4jiss=C3=A4 ole e=
sim. varsinaista=20
core-tiimi=C3=A4, vaan kaikilla on tasavertaiset oikeudet koodiin. Minull=
a on=20
periaatteessa projektin "johtajan" status kurssin roolijaon perusteella=20
ja SourceForgen admin-oikeuksien vuoksi.

Haluammeko ett=C3=A4 projektilla on "johtaja", jolla on viimeinen sana=20
mahdollisissa kiistakysymyksiss=C3=A4 vai onko meill=C3=A4 "core team", j=
oka=20
ratkaisee kiistakysymykset riitelem=C3=A4ll=C3=A4 kesken=C3=A4=C3=A4n ja/=
tai =C3=A4=C3=A4nest=C3=A4m=C3=A4ll=C3=A4?

Itse olen n=C3=A4hnyt yhden johtajan mallin toimivan useammin kuin monen=20
johtajan mallin, joten kallistuisin sille kannalle. Yhden johtajan malli=20
onnistuu mielest=C3=A4ni parhaiten kuin kyseinen johtaja sanelee=20
mahdollisimman v=C3=A4h=C3=A4n ja pyrkii kunnioittamaan muita ajatellen p=
rojektin=20
etua eik=C3=A4 omaansa, eli mit=C3=A4=C3=A4n rautahanskaista johtajaa emm=
e kaipaa. Jos=20
p=C3=A4=C3=A4dymme yhden johtajan mallin, t=C3=A4llainen pit=C3=A4isi my=C3=
=B6s valita.

Jos ja kun lis=C3=A4=C3=A4 kehitt=C3=A4ji=C3=A4 tulee mukaan, miss=C3=A4 =
vaiheessa heille=20
annetaan oikeudet laittaa koodia suoraan CVS:=C3=A4=C3=A4n?

Omasta mielest=C3=A4ni kannattaa odottaa ainakin jonkin aikaa, jotta n=C3=
=A4kee=20
uuden henkil=C3=B6n olevan kiinnostunut jatkamaan kehityst=C3=A4 pitk=C3=A4=
j=C3=A4nteisesti,=20
mutta toisaalta pyrki=C3=A4 antamaan oikeus pian ty=C3=B6n helpottamiseks=
i.

Tuo kehitt=C3=A4jien roolista. Sitten hieman konkreettisempaa.

Kuten kokouksessa sanoin, n=C3=A4en pari mahdollista kehityssuuntaa nyt=20
seuraaviin versioihin. Toinen on se, ett=C3=A4 hiomme tuon koodin siistik=
si=20
yhden lajin kanssa. Toinen puolestaan se, ett=C3=A4 teemme pikaisesti tue=
n=20
useille lajeille ja toteutamme toisen lajin tuon testaamiseksi.

Itse pohdin t=C3=A4t=C3=A4 ja ehdotan seuraavaa. Versioon 0.2.0 meill=C3=A4=
 ei ole=20
kiire, eli hiotaan siihen menness=C3=A4 lumipallonheiton koodi sellaiseen=
=20
kuntoon, ett=C3=A4 sen pohjalta voi laatia siististi muita lajeja. T=C3=A4=
m=C3=A4=20
tarkoittaa mm. sen erillisen Game/Event-luokan toteuttamista. T=C3=A4h=C3=
=A4n=20
p=C3=A4=C3=A4dyin mm. siksi, ett=C3=A4 jos j=C3=A4t=C3=A4mme koodin kaoot=
tiseksi ja alamme=20
lis=C3=A4ill=C3=A4 lajeja, ne pit=C3=A4=C3=A4 kaikki siisti=C3=A4 my=C3=B6=
hemmin.

Toisaalta tuo alkuvalikko on varsin riippumaton lajeista. Siit=C3=A4 vois=
imme=20
jakaa nyt asiakas- ja palvelinsovelluksen, joihin rakennamme 0.2.0:aan=20
menness=C3=A4 tuen useille lajeille. T=C3=A4ll=C3=A4 tavalla 0.3.0 voisi =
keskitty=C3=A4=20
uusien lajien luomiseen ja niiden vaatimien ominaisuuksien tukemiseen.

T=C3=A4m=C3=A4 ei ole mik=C3=A4=C3=A4n joka kantilta pureskeltu ja aivony=
styr=C3=B6it=C3=A4=20
nyrj=C3=A4ytellen l=C3=A4pi pohdittu ehdotus, eli kommentoikaa rohkeasti =
ja=20
antakaa parannus- ja vastaehdotuksia.

Viel=C3=A4 yksi asia n=C3=A4ihin yleisiin linjoihin liittyen. Meill=C3=A4=
 on=20
k=C3=A4yt=C3=A4nn=C3=B6ss=C3=A4 kaksi perustapaa siisti=C3=A4 nykyinen ko=
odi: evoluutio tai=20
uudelleenkirjoitus. Todellinen tapa on jossain tuolla v=C3=A4lill=C3=A4, =
mutta=20
kumpaa l=C3=A4hemp=C3=A4n=C3=A4? Itse kallistuisin ainakin lumipallonheit=
on kohdalla=20
l=C3=A4hemm=C3=A4s harkittua uudelleenkirjoitusta, jossa nyt kun tied=C3=A4=
mme mit=C3=A4=20
tarvitaan pohdimme v=C3=A4h=C3=A4n paremmin miten se kannattaa toteuttaa =
luokka-=20
ja metoditasolla. Samalla pit=C3=A4isi pohtia mik=C3=A4 kuuluu siihen=20
Game/Event-luokkaan ja mik=C3=A4 yhden lajin toteuttavaan=20
SnowBallThrow-luokkaamme.

Ett=C3=A4 t=C3=A4llaista. Pitk=C3=A4 viesti, mutta koettakaa kommentoida =
kunnolla. Ja=20
hei, nyt ei ole en=C3=A4=C3=A4 mik=C3=A4=C3=A4n tulipalokiire, miettik=C3=
=A4=C3=A4 rauhassa :)

Olen itse ensi viikon lomalla ja lukenen s=C3=A4hk=C3=B6postia hyvin=20
harvakseltaan, eli minulta ei kannata odottaa vastauksia ajatuksiinne=20
ainakaan ennen 27. p=C3=A4iv=C3=A4=C3=A4.


--=20
Tero Kuusela

"No man will make a great leader who wants to do it all himself, or to=20
get all the credit for doing it."

[Tuxletics-devel] Projektisuunnitelmat yms.

[Petteri K. <pz...@us...>]

Terve taas.

On Sun, 19 Dec 2004, Tero Kuusela wrote:

> T=C3=A4ss=C3=A4 tapauksessa n=C3=A4kisin jonkin karkean listan Tuxletics =
1.0:n
> ominaisuuksista ajavan asian. Pitk=C3=A4n t=C3=A4ht=C3=A4imen tavoite kan=
nattaa
> sitten jakaa osiin, eli t=C3=A4ss=C3=A4 k=C3=A4ytt=C3=A4isin sit=C3=A4 ro=
admap-ideaa, jonka
> kokouksessakin toin esille.

Jep, n=E4in munkin mielest=E4 voisi l=E4hte=E4 liikkeelle.

> Haluammeko ett=C3=A4 projektilla on "johtaja", jolla on viimeinen sana
> mahdollisissa kiistakysymyksiss=C3=A4

Emme halua :)

> vai onko meill=C3=A4 "core team", joka
> ratkaisee kiistakysymykset riitelem=C3=A4ll=C3=A4 kesken=C3=A4=C3=A4n ja/=
tai
> =C3=A4=C3=A4nest=C3=A4m=C3=A4ll=C3=A4?

Kyll=E4.

> Jos ja kun lis=C3=A4=C3=A4 kehitt=C3=A4ji=C3=A4 tulee mukaan, miss=C3=A4 =
vaiheessa heille
> annetaan oikeudet laittaa koodia suoraan CVS:=C3=A4=C3=A4n?

Mun puolesta ekan kontribuutioin j=E4lkeen, sill=E4 itse=E4ni ei ainakaan h=
uvita
tarkistaa jokaista uuttaa koodinp=E4tk=E4=E4 l=E4pi. Jos joltain meist=E4 l=
=F6ytyy
innostusta t=E4mm=F6isi=E4 tarkistuksia tekem=E4=E4n (suhteellisen nopeassa=
 ajassa),
niin sitten tietenkin voidaan enempi vahtia mit=E4 koodia tulee, jos tulee.

Roadmappia voidaan varmaan alkaa ty=F6st=E4m=E4=E4n tuolla tuxletics-sivuil=
la,
koska siell=E4 oli se twiki. Tein sinne jo RoadMap-sivun jonne vois pist=E4=
=E4
jotain ideoita jne.
http://tuxletics.sourceforge.net/cgi-bin/twiki/view/Users/RoadMap

Re: [Tuxletics-devel] Post-0.1.0

[Mauno <ma...@us...>]

Moro... Tuo Petterin tekemä roadman sivu (ircissä topicissa) on oikein 
hyvä tapa lähteä nyt etenemään.

Ois varmasti hyvä jos sovittais nyt yhteinen irc-tapaaminen, jossa 
kävisimme läpi noita ominaisuuksia mitä kukin haluaa ja mitä ei. Tai 
sitten vaan kirjoitetaan suoraan tonne roadmap sivuille vapaammin ensin 
ja muodostetaan sen pohjalta varsinainen roadmap.

Toi kuullostaa ihan hyvältä tavalta, että mietitään ne 1.0:n 
ominaisuudet ensin. Ja "when it's ready" malli on paras aikatauluille.

Mun mielestä aikaisempi johtamismalli on toiminut oikein hyvin meidän 
kohdalla (eli kiistakyssärit ratkaistu keskenään/äänestämällä) eli oon 
core-teamin kannalla.

Ja kuten aikaisemmin sovittiinkin niin usean pelin tuki ensin... Eli 
roadmappiin versioon 1.1 game/event luokat. Kun ollaan tuo game/event 
hierarkia päätetty niin sitten vois sen vanhan koodin 
uudelleenkirjoittaa sen mukaiseksi.

Toi Petterin jo kirjoittama alku tohon roadmappiin on mun mielestä 
oikein hyvä. Että 0.2 versiossa ois valmiina 2 lajia sekä moninpeli 
yhdellä koneella. O.3:nen vois sitten tuoda mukanaan sen 
verkkopelimahdollisuuden ja 0.4:sesta eteenpäin olisikin lajien lisäilyä 
ja hiomista kohti 1.0:aa.





Tero Kuusela wrote:
> Moi!
> 
> 
> Sitten toteutetaan aina seuraavan version tavoitteet ja julkaisun 
> jälkeen tarkistetaan roadmap, sillä tavoitteet voivat muuttua ajan myötä.
> 
> Tuo projektin etenemisestä. Kommentteja tähän?
> 
> Harkinnan arvoinen aihe on myös kehitysmallin tarkentaminen. Tällä 
> hetkellä voisi sanoa, ettei meillä kehittäjissä ole esim. varsinaista 
> core-tiimiä, vaan kaikilla on tasavertaiset oikeudet koodiin. Minulla on 
> periaatteessa projektin "johtajan" status kurssin roolijaon perusteella 
> ja SourceForgen admin-oikeuksien vuoksi.
> 
> Haluammeko että projektilla on "johtaja", jolla on viimeinen sana 
> mahdollisissa kiistakysymyksissä vai onko meillä "core team", joka 
> ratkaisee kiistakysymykset riitelemällä keskenään ja/tai äänestämällä?
> 
> Itse olen nähnyt yhden johtajan mallin toimivan useammin kuin monen 
> johtajan mallin, joten kallistuisin sille kannalle. Yhden johtajan malli 
> onnistuu mielestäni parhaiten kuin kyseinen johtaja sanelee 
> mahdollisimman vähän ja pyrkii kunnioittamaan muita ajatellen projektin 
> etua eikä omaansa, eli mitään rautahanskaista johtajaa emme kaipaa. Jos 
> päädymme yhden johtajan mallin, tällainen pitäisi myös valita.
> 
> Jos ja kun lisää kehittäjiä tulee mukaan, missä vaiheessa heille 
> annetaan oikeudet laittaa koodia suoraan CVS:ään?
> 
> Omasta mielestäni kannattaa odottaa ainakin jonkin aikaa, jotta näkee 
> uuden henkilön olevan kiinnostunut jatkamaan kehitystä pitkäjänteisesti, 
> mutta toisaalta pyrkiä antamaan oikeus pian työn helpottamiseksi.
> 
> Tuo kehittäjien roolista. Sitten hieman konkreettisempaa.
> 
> Kuten kokouksessa sanoin, näen pari mahdollista kehityssuuntaa nyt 
> seuraaviin versioihin. Toinen on se, että hiomme tuon koodin siistiksi 
> yhden lajin kanssa. Toinen puolestaan se, että teemme pikaisesti tuen 
> useille lajeille ja toteutamme toisen lajin tuon testaamiseksi.
> 
> Itse pohdin tätä ja ehdotan seuraavaa. Versioon 0.2.0 meillä ei ole 
> kiire, eli hiotaan siihen mennessä lumipallonheiton koodi sellaiseen 
> kuntoon, että sen pohjalta voi laatia siististi muita lajeja. Tämä 
> tarkoittaa mm. sen erillisen Game/Event-luokan toteuttamista. Tähän 
> päädyin mm. siksi, että jos jätämme koodin kaoottiseksi ja alamme 
> lisäillä lajeja, ne pitää kaikki siistiä myöhemmin.
> 
> Toisaalta tuo alkuvalikko on varsin riippumaton lajeista. Siitä voisimme 
> jakaa nyt asiakas- ja palvelinsovelluksen, joihin rakennamme 0.2.0:aan 
> mennessä tuen useille lajeille. Tällä tavalla 0.3.0 voisi keskittyä 
> uusien lajien luomiseen ja niiden vaatimien ominaisuuksien tukemiseen.
> 
> Tämä ei ole mikään joka kantilta pureskeltu ja aivonystyröitä 
> nyrjäytellen läpi pohdittu ehdotus, eli kommentoikaa rohkeasti ja 
> antakaa parannus- ja vastaehdotuksia.
> 
> Vielä yksi asia näihin yleisiin linjoihin liittyen. Meillä on 
> käytännössä kaksi perustapaa siistiä nykyinen koodi: evoluutio tai 
> uudelleenkirjoitus. Todellinen tapa on jossain tuolla välillä, mutta 
> kumpaa lähempänä? Itse kallistuisin ainakin lumipallonheiton kohdalla 
> lähemmäs harkittua uudelleenkirjoitusta, jossa nyt kun tiedämme mitä 
> tarvitaan pohdimme vähän paremmin miten se kannattaa toteuttaa luokka- 
> ja metoditasolla. Samalla pitäisi pohtia mikä kuuluu siihen 
> Game/Event-luokkaan ja mikä yhden lajin toteuttavaan 
> SnowBallThrow-luokkaamme.
> 
> Että tällaista. Pitkä viesti, mutta koettakaa kommentoida kunnolla. Ja 
> hei, nyt ei ole enää mikään tulipalokiire, miettikää rauhassa :)
> 
> Olen itse ensi viikon lomalla ja lukenen sähköpostia hyvin 
> harvakseltaan, eli minulta ei kannata odottaa vastauksia ajatuksiinne 
> ainakaan ennen 27. päivää.
> 
> 

Re: [Tuxletics-devel] Post-0.1.0

[Tero K. <te...@us...>]

Mauno wrote:
> Moro... Tuo Petterin tekem=C3=A4 roadman sivu (irciss=C3=A4 topicissa) =
on oikein=20
> hyv=C3=A4 tapa l=C3=A4hte=C3=A4 nyt etenem=C3=A4=C3=A4n.
>=20
> Ois varmasti hyv=C3=A4 jos sovittais nyt yhteinen irc-tapaaminen, jossa=
=20
> k=C3=A4visimme l=C3=A4pi noita ominaisuuksia mit=C3=A4 kukin haluaa ja =
mit=C3=A4 ei. Tai=20
> sitten vaan kirjoitetaan suoraan tonne roadmap sivuille vapaammin ensin=
=20
> ja muodostetaan sen pohjalta varsinainen roadmap.
>=20

IRC-tapaaminen olisi varmaan parempi, yleens=C3=A4 niiss=C3=A4 saadaan en=
emm=C3=A4n=20
aikaan kerralla kuin wikin ja postilistan kautta kuukaudessa...

Miten t=C3=A4m=C3=A4n viikon perjantai sopisi itse kullekin?

> Toi kuullostaa ihan hyv=C3=A4lt=C3=A4 tavalta, ett=C3=A4 mietit=C3=A4=C3=
=A4n ne 1.0:n=20
> ominaisuudet ensin. Ja "when it's ready" malli on paras aikatauluille.
>=20

Ok, t=C3=A4st=C3=A4 n=C3=A4kyy vallitsevan aika hyv=C3=A4 yksimielisyys.

> Mun mielest=C3=A4 aikaisempi johtamismalli on toiminut oikein hyvin mei=
d=C3=A4n=20
> kohdalla (eli kiistakyss=C3=A4rit ratkaistu kesken=C3=A4=C3=A4n/=C3=A4=C3=
=A4nest=C3=A4m=C3=A4ll=C3=A4) eli oon=20
> core-teamin kannalla.
>=20

T=C3=A4ss=C3=A4 enemmist=C3=B6 vaikuttaisi kallistuvan ydintiimin kannall=
e, eli edet=C3=A4=C3=A4n=20
t=C3=A4ll=C3=A4 mallilla. Ilmeisesti ydintiimin muodostaisimme me nelj=C3=
=A4 vai=20
haluaako joku j=C3=A4=C3=A4d=C3=A4 ulkopuolelle / onko jollakulla jotain =
t=C3=A4t=C3=A4 vastaan?

> Ja kuten aikaisemmin sovittiinkin niin usean pelin tuki ensin... Eli=20
> roadmappiin versioon 1.1 game/event luokat. Kun ollaan tuo game/event=20
> hierarkia p=C3=A4=C3=A4tetty niin sitten vois sen vanhan koodin=20
> uudelleenkirjoittaa sen mukaiseksi.
>=20

Siis vasta 1.0:n j=C3=A4lkeenk=C3=B6 ehdotat event-luokan toteuttamista?

> Toi Petterin jo kirjoittama alku tohon roadmappiin on mun mielest=C3=A4=
=20
> oikein hyv=C3=A4. Ett=C3=A4 0.2 versiossa ois valmiina 2 lajia sek=C3=A4=
 moninpeli=20
> yhdell=C3=A4 koneella. O.3:nen vois sitten tuoda mukanaan sen=20
> verkkopelimahdollisuuden ja 0.4:sesta eteenp=C3=A4in olisikin lajien li=
s=C3=A4ily=C3=A4=20
> ja hiomista kohti 1.0:aa.

Juu, hieman suppea vain viel=C3=A4, mutta eik=C3=B6h=C3=A4n se IRC-brains=
tormingin=20
avulla t=C3=A4yty ihan mukavasti :)


--=20
Tero Kuusela

"Knowledge rests not upon truth alone, but upon error also."

Re: [Tuxletics-devel] Post-0.1.0

[Mauno <ma...@us...>]

>> Ja kuten aikaisemmin sovittiinkin niin usean pelin tuki ensin... Eli 
>> roadmappiin versioon 1.1 game/event luokat. Kun ollaan tuo game/event 
>> hierarkia päätetty niin sitten vois sen vanhan koodin 
>> uudelleenkirjoittaa sen mukaiseksi.
>>
> 
> Siis vasta 1.0:n jälkeenkö ehdotat event-luokan toteuttamista?
> 


0.1.1:stä siis tarkoitin :)