Szerkesztő:Madbence/Szoftver labor 4 tanácsok - Laptörténet

Schulcz Ferenc: Egy plusz megoldás belinkelve.

2018-05-28T07:10:54Z

Egy plusz megoldás belinkelve.

← Régebbi változat		A lap 2018. május 28., 09:10-kori változata
105. sor:		105. sor:
	=Continuity=		=Continuity=
	2012 tavaszán csináltuk meg a tárgyat (4-en voltunk a csapatban), az [https://www.box.com/s/d00d89c73e5fb7293cb5 elkészült dokumentáció] összesen 214 oldal (elérhető [https://www.box.com/s/65ea95ccb2382f5284f7 nagyon hipszter Helvetica] betűtípussal is). [https://github.com/madbence/fearlesscode_szoftlab Forráskód] (kizárólag okulási célokkal!)		2012 tavaszán csináltuk meg a tárgyat (4-en voltunk a csapatban), az [https://www.box.com/s/d00d89c73e5fb7293cb5 elkészült dokumentáció] összesen 214 oldal (elérhető [https://www.box.com/s/65ea95ccb2382f5284f7 nagyon hipszter Helvetica] betűtípussal is). [https://github.com/madbence/fearlesscode_szoftlab Forráskód] (kizárólag okulási célokkal!)

			''Update:'' mi pedig 2018 tavaszán csináltuk, a kód, a doksi és néhány bónusz jó tanács elérhető [https://git.sch.bme.hu/schulczf/killer_sokoban itt]. (Jeles értékelést kaptunk.)

Schulcz Ferenc: Update: Google Docs ötlete hozzáadva.

2018-05-28T07:02:36Z

Update: Google Docs ötlete hozzáadva.

← Régebbi változat		A lap 2018. május 28., 09:02-kori változata
24. sor:		24. sor:

	Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni. El lehet kezdeni tanulni a [http://en.wikipedia.org/wiki/LaTeX LaTeX]-et ([[Dokumentumszerkesztés\|Van is rá tárgy]]). A [https://www.sharelatex.com/ ShareLaTeX] oldalon lehet kollaborálkodni is, illetve ha éppen nincsenek kéznél a binárisok, neten, [http://manuels.github.com/texlive.js/website/ on-the-fly is lehet pdf-et generálni] (az [http://github.com/kripken/emscripten emscripten] csodákra képes :D).		Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni. El lehet kezdeni tanulni a [http://en.wikipedia.org/wiki/LaTeX LaTeX]-et ([[Dokumentumszerkesztés\|Van is rá tárgy]]). A [https://www.sharelatex.com/ ShareLaTeX] oldalon lehet kollaborálkodni is, illetve ha éppen nincsenek kéznél a binárisok, neten, [http://manuels.github.com/texlive.js/website/ on-the-fly is lehet pdf-et generálni] (az [http://github.com/kripken/emscripten emscripten] csodákra képes :D).

			'''''Update''' --[[Szerkesztő:Schulcz Ferenc\|Schulcz Ferenc]] ([[Szerkesztővita:Schulcz Ferenc\|vita]]) 2018. május 28., 07:02 (UTC)'': Legalábbis 2018-ban már előre kiadott docx fájlokat kellett kiegészíteni, és ezeket kellett dokumentációként leadni. Mi az egészet felraktuk egy Google Drive mappába, és ott Google Docs-szal kényelmesen lehetett csapatban szerkesztgetni.

	===UML===		===UML===

Madbence: /* Kommunikáció */

2013-01-31T23:04:50Z

Kommunikáció

← Régebbi változat		A lap 2013. február 1., 01:04-kori változata
12. sor:		12. sor:
	Ha mindenki kolis, az a legjobb. Egyéb esetben a [http://www.skype.com/ Skype] jó helyettesítő, valamint a levlista (tudom ajánlani a [http://groups.google.com Google Groups]-ot).		Ha mindenki kolis, az a legjobb. Egyéb esetben a [http://www.skype.com/ Skype] jó helyettesítő, valamint a levlista (tudom ajánlani a [http://groups.google.com Google Groups]-ot).
	A legjobb a napi szintű kommunikáció, de egy héten '''''mindenképpen''''' legalább 2 összejövetelt tartani kell. Egy a feladatok kiosztására, egy a haladás összegzésére, a felmerült problémák orvoslására. Egy komoly problémára lehetőleg ne a leadás előtti napon kerüljön sor. Oké, a leadás dél körül szokott lenni, és reggel 8 és dél között kemény 4 óra van, de azért próbáljátok ne ilyenkor befejezni. Vagy ha már így jártok, mindenképpen nézzetek körül, hol fogjátok olyan gyorsan kinyomtatni (és műanyag bugyit szerezni hozzá! :D), hogy még vissza is érjetek.		A legjobb a napi szintű kommunikáció, de egy héten '''''mindenképpen''''' legalább 2 összejövetelt tartani kell. Egy a feladatok kiosztására, egy a haladás összegzésére, a felmerült problémák orvoslására. Egy komoly problémára lehetőleg ne a leadás előtti napon kerüljön sor. Oké, a leadás dél körül szokott lenni, és reggel 8 és dél között kemény 4 óra van, de azért próbáljátok ne ilyenkor befejezni. Vagy ha már így jártok, mindenképpen nézzetek körül, hol fogjátok olyan gyorsan kinyomtatni (és műanyag bugyit szerezni hozzá! :D), hogy még vissza is érjetek.

			Gyakorlatilag '''a siker kulcsa a kommunikáció''', minden ezen múlik. A feladatokat érdemesebb minél atomibb, minél kisebb részekre bontani, és '''folyamatosan''' egyeztetni. Máshogy nagyon nehéz (egész egyszerűen amiatt, hogy mindenki a saját munkatempójához, gondolkodásmódjához szokott, és a kooperációhoz meg kell ismerni egymást).

	Ha valamelyik csapattag nem lesz elérhető (nyaral, beteg, meghal), azt illik előre bejelenteni.		Ha valamelyik csapattag nem lesz elérhető (nyaral, beteg, meghal), azt illik előre bejelenteni.

Madbence: /* Államforma */

2013-01-31T22:59:42Z

Államforma

← Régebbi változat		A lap 2013. február 1., 00:59-kori változata
5. sor:		5. sor:

	===Államforma===		===Államforma===
	Az egyes csapatoknak formálisan kell egy vezetőt választania adminisztrációs okokból, ezen kívül a tárgy mást nem követel meg. Ezt a hierarchiát azonban érdemes komolyan venni, ugyanis a demokrácia csak elméletben hangzik jól.		Az egyes csapatoknak formálisan kell egy vezetőt választania adminisztrációs okokból, ezen kívül a tárgy mást nem követel meg. Ezt a hierarchiát azonban érdemes komolyan venni, ugyanis a demokrácia csak elméletben hangzik jól. (Kivételek persze vannak.)

	Tehát kelleni fog egy '''''vezető''''', aki ''mindenkinek'' ki tudja osztani a ''konkrét'' feladatát, és meg tudja szabni, hogy azt ''pontosan mikorra'' kell elkészítenie. Az a módszer, hogy "''Ki mit szeretne csinálni?''", teljesen életképtelen, egyel jobb fokozat az "''Itt egy lista, mindenki kiválaszt 2-3 itemet, és beírja, hogy mikorra készíti el''", de ez sem nagyon tud működni. Én személyesen azt a módszert találtam a legcélravezetőbbnek, hogy "''Te X-et fogod csinálni, Y-ra elkészíted, ez neked megfelel?''" (ha nem, miért nem, csinálnál-e helyette Z-t, ami W-re elkészül?). Az ezzel járó konfliktusokat pedig el kell viselni (sosem fog semmi simán menni). Amikor faszán működik a csapat, azt biztosan észre fogjátok venni, ugyanis olyankor nem akarjátok egymást vízbe fojtani.		Tehát kelleni fog egy '''''vezető''''', aki ''mindenkinek'' ki tudja osztani a ''konkrét'' feladatát, és meg tudja szabni, hogy azt ''pontosan mikorra'' kell elkészítenie. Az a módszer, hogy "''Ki mit szeretne csinálni?''", (szinte) teljesen életképtelen, egyel jobb fokozat az "''Itt egy lista, mindenki kiválaszt 2-3 itemet, és beírja, hogy mikorra készíti el''", de ez sem nagyon tud működni. Én személyesen azt a módszert találtam a legcélravezetőbbnek, hogy "''Te X-et fogod csinálni, Y-ra elkészíted, ez neked megfelel?''" (ha nem, miért nem, csinálnál-e helyette Z-t, ami W-re elkészül?). Az ezzel járó konfliktusokat pedig el kell viselni (sosem fog semmi simán menni). Amikor faszán működik a csapat, azt biztosan észre fogjátok venni, ugyanis olyankor nem akarjátok egymást vízbe fojtani.

	===Kommunikáció===		===Kommunikáció===

Madbence: Bővítettem a szoftlab "kedvcsinálót"

2013-01-21T06:40:16Z

Bővítettem a szoftlab "kedvcsinálót"

Változtatások megtekintése

Madbence: /* Git */

2013-01-20T14:35:34Z

Git

← Régebbi változat		A lap 2013. január 20., 16:35-kori változata
27. sor:		27. sor:
	A [http://mercurial.selenic.com/ Mercurial] egy elosztott verziókezelő (DVCS), az a jó benne, hogy lokálisan is lesz repód. Nem nagyon ismerem, inkább a git-et preferálom		A [http://mercurial.selenic.com/ Mercurial] egy elosztott verziókezelő (DVCS), az a jó benne, hogy lokálisan is lesz repód. Nem nagyon ismerem, inkább a git-et preferálom
	====Git====		====Git====
	[http://git-scm.com/ Az áltimét verziókezelő], ha tudod kezelni, mással nem is érdemes foglalkozni. Írtam hozzá régebben egy [[Szerkesztő:Madbence/Git tutorial\|tutorialt]], ~~előbb utóbb felrakom. ([[Szerkesztő:Madbence\|lennon]] ([[Szerkesztővita:Madbence\|vita]]) 2013~~. ~~január 19., 23:11 (CET))~~		[http://git-scm.com/ Az áltimét verziókezelő], '''ha tudod kezelni, mással nem is érdemes foglalkozni'''. Írtam hozzá régebben egy [[Szerkesztő:Madbence/Git tutorial\|tutorialt]], még most is viszonylag használhatónak tartom.

	=Kód=		=Kód=
	Előbb-utóbb kódolni is kell, érdemes nem szarozni vele túl sokat. Érdemes minél egyszerűbb, logikusabb kódot írni, aminek az előállítására az alábbi algoritmus rendkívül jó:		Előbb-utóbb kódolni is kell, érdemes nem szarozni vele túl sokat. Érdemes minél egyszerűbb, logikusabb kódot írni, aminek az előállítására az alábbi algoritmus rendkívül jó:

Madbence: Hierarchia átalakítva

2013-01-19T23:12:56Z

Hierarchia átalakítva

← Régebbi változat		A lap 2013. január 20., 01:12-kori változata
2. sor:		2. sor:
	=A csapat=		=A csapat=
	Ha levlistán vadászol csapattagokat, vagy akarsz csapatot találni magadnak, mindenképpen érdemes jelezni, hogy milyen területen tartod magad jónak, hiszen lehet, hogy 5 profi Java kóder zseniálisan jól összerakott, és megtervezett kódot tud írni, ha a dokumentáció rossz, nagyon le tudja rontani a teljesítményt.		Ha levlistán vadászol csapattagokat, vagy akarsz csapatot találni magadnak, mindenképpen érdemes jelezni, hogy milyen területen tartod magad jónak, hiszen lehet, hogy 5 profi Java kóder zseniálisan jól összerakott, és megtervezett kódot tud írni, ha a dokumentáció rossz, nagyon le tudja rontani a teljesítményt.
	==Államforma==		===Államforma===
	Az egyes csapatoknak formálisan kell egy vezetőt választania adminisztrációs okokból, ezen kívül a tárgy mást nem követel meg. Ezt a hierarchiát azonban érdemes komolyan venni, ugyanis a demokrácia csak elméletben hangzik jól.		Az egyes csapatoknak formálisan kell egy vezetőt választania adminisztrációs okokból, ezen kívül a tárgy mást nem követel meg. Ezt a hierarchiát azonban érdemes komolyan venni, ugyanis a demokrácia csak elméletben hangzik jól.

	Tehát kelleni fog egy '''''vezető''''', aki ''mindenkinek'' ki tudja osztani a ''konkrét'' feladatát, és meg tudja szabni, hogy azt ''pontosan mikorra'' kell elkészítenie. Az a módszer, hogy "''Ki mit szeretne csinálni?''", teljesen életképtelen módszer, egyel jobb fokozat az "''Itt egy lista, mindenki kiválaszt 2-3 itemet, és beírja, hogy mikorra készíti el''", de ez sem nagyon tud működni. Én személyesen azt a módszert találtam a legcélravezetőbbnek, hogy "''Te X-et fogod csinálni, Y-ra elkészíted, ez neked megfelel?''". Az ezzel járó konfliktusokat pedig el kell viselni (sosem fog semmi simán menni).		Tehát kelleni fog egy '''''vezető''''', aki ''mindenkinek'' ki tudja osztani a ''konkrét'' feladatát, és meg tudja szabni, hogy azt ''pontosan mikorra'' kell elkészítenie. Az a módszer, hogy "''Ki mit szeretne csinálni?''", teljesen életképtelen módszer, egyel jobb fokozat az "''Itt egy lista, mindenki kiválaszt 2-3 itemet, és beírja, hogy mikorra készíti el''", de ez sem nagyon tud működni. Én személyesen azt a módszert találtam a legcélravezetőbbnek, hogy "''Te X-et fogod csinálni, Y-ra elkészíted, ez neked megfelel?''". Az ezzel járó konfliktusokat pedig el kell viselni (sosem fog semmi simán menni).

	==Kommunikáció==		===Kommunikáció===
	Ha mindenki kolis, az a legjobb. Egyéb esetben a [http://www.skype.com/ Skype] jó helyettesítő, valamint a levlista (tudom ajánlani a [http://groups.google.com Google Groups]-ot).		Ha mindenki kolis, az a legjobb. Egyéb esetben a [http://www.skype.com/ Skype] jó helyettesítő, valamint a levlista (tudom ajánlani a [http://groups.google.com Google Groups]-ot).
	A legjobb napi szintű kommunikáció, de egy héten '''''mindenképpen''''' legalább 2 összejövetelt tartani kell. Egy a feladatok kiosztására, egy a haladás összegzésére, a felmerült problémák orvoslására. Egy komoly problémára lehetőleg ne a leadás előtti napon kerüljön sor.		A legjobb napi szintű kommunikáció, de egy héten '''''mindenképpen''''' legalább 2 összejövetelt tartani kell. Egy a feladatok kiosztására, egy a haladás összegzésére, a felmerült problémák orvoslására. Egy komoly problémára lehetőleg ne a leadás előtti napon kerüljön sor.
14. sor:		14. sor:
	=Kollaboráció=		=Kollaboráció=
	Szükség lesz a közös munkára, és illik a Dropboxnál komolyabb technológiákat is igénybe venni.		Szükség lesz a közös munkára, és illik a Dropboxnál komolyabb technológiákat is igénybe venni.
	==Doksi==		===Doksi===
	Erre a célra érdemes valamilyen Wikit beüzemelni, mi a [https://bitbucket.org/ bitbucket] szolgáltatását használtuk, a repó mellé kap az ember egy wikit is, ami szintén repóként működik. Érdemes megoldani, hogy a Wikiből on-the-fly lehessen pdf doksit generálni, mi erre a célra egy Wiki2LaTeX toolt csináltunk, ami a Wiki saját markupjából LaTeX kódot generált, így gyakorlatilag pár kattintás volt az aktuális Wiki tartalmából dokumentációt gyártani.		Erre a célra érdemes valamilyen Wikit beüzemelni, mi a [https://bitbucket.org/ bitbucket] szolgáltatását használtuk, a repó mellé kap az ember egy wikit is, ami szintén repóként működik. Érdemes megoldani, hogy a Wikiből on-the-fly lehessen pdf doksit generálni, mi erre a célra egy Wiki2LaTeX toolt csináltunk, ami a Wiki saját markupjából LaTeX kódot generált, így gyakorlatilag pár kattintás volt az aktuális Wiki tartalmából dokumentációt gyártani.

	Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni.		Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni.
	==UML==		===UML===
	Érdemes valahogy (értsd: legálisan, vagy illegálisan) valamilyen editort ehhez beszerezni, mi az [http://www.sparxsystems.com/ Enterprise Architect]-et választottuk (találtunk egy "ingyenes" letöltési lehetőséget), de igaziból úgyis csak nyilakat meg dobozokat kell rajzolni, szóval ami ezt tudja, az rendben van. Ha tud menteni vektoros formátumba, az külön orgazmus, mert még ki is fog nézni valahogy a doksi.		Érdemes valahogy (értsd: legálisan, vagy illegálisan) valamilyen editort ehhez beszerezni, mi az [http://www.sparxsystems.com/ Enterprise Architect]-et választottuk (találtunk egy "ingyenes" letöltési lehetőséget), de igaziból úgyis csak nyilakat meg dobozokat kell rajzolni, szóval ami ezt tudja, az rendben van. Ha tud menteni vektoros formátumba, az külön orgazmus, mert még ki is fog nézni valahogy a doksi.
	==Verziókezelés==		===Verziókezelés===
	LZ biztos mindenkit bevezetett a verziókezelés rejtelmeibe Szofttechből, csak éppen a többség nem hitte el, hogy ez valami értelmes dolog. Értelmes dolog, és meg kell tanulni használni.		LZ biztos mindenkit bevezetett a verziókezelés rejtelmeibe Szofttechből, csak éppen a többség nem hitte el, hogy ez valami értelmes dolog. Értelmes dolog, és meg kell tanulni használni.
	===SVN===		====SVN====
	Hagyományos verziókezelő szoftver a [http://subversion.apache.org/ Subversion], valószínűleg valami ilyesmi rendszerről volt szó szofttechen, igaziból mindent tud, amit kell. [http://tortoisesvn.net/ TortoiseSVN] must have jutility, nélküle el se kezdjétek.		Hagyományos verziókezelő szoftver a [http://subversion.apache.org/ Subversion], valószínűleg valami ilyesmi rendszerről volt szó szofttechen, igaziból mindent tud, amit kell. [http://tortoisesvn.net/ TortoiseSVN] must have jutility, nélküle el se kezdjétek.
	===Mercurial===		====Mercurial====
	A [http://mercurial.selenic.com/ Mercurial] egy elosztott verziókezelő (DVCS), az a jó benne, hogy lokálisan is lesz repód. Nem nagyon ismerem, inkább a git-et preferálom		A [http://mercurial.selenic.com/ Mercurial] egy elosztott verziókezelő (DVCS), az a jó benne, hogy lokálisan is lesz repód. Nem nagyon ismerem, inkább a git-et preferálom
	===Git===		====Git====
	[http://git-scm.com/ Az áltimét verziókezelő], ha tudod kezelni, mással nem is érdemes foglalkozni. Írtam hozzá régebben egy [[Szerkesztő:Madbence/Git tutorial\|tutorialt]], előbb utóbb felrakom. ([[Szerkesztő:Madbence\|lennon]] ([[Szerkesztővita:Madbence\|vita]]) 2013. január 19., 23:11 (CET))		[http://git-scm.com/ Az áltimét verziókezelő], ha tudod kezelni, mással nem is érdemes foglalkozni. Írtam hozzá régebben egy [[Szerkesztő:Madbence/Git tutorial\|tutorialt]], előbb utóbb felrakom. ([[Szerkesztő:Madbence\|lennon]] ([[Szerkesztővita:Madbence\|vita]]) 2013. január 19., 23:11 (CET))
	=Kód=		=Kód=
35. sor:		35. sor:
	# Profit!		# Profit!

	==Editor==		===Editor===
	Érdemes a Notepadnál komolyabb cuccot használni, de azt figyelembe kell venni, hogy beadásnál parancssorból kell majd fordítani, szóval [http://maven.apache.org/ Maven] ne legyen feltétele a fordításnak.		Érdemes a Notepadnál komolyabb cuccot használni, de azt figyelembe kell venni, hogy beadásnál parancssorból kell majd fordítani, szóval [http://maven.apache.org/ Maven] ne legyen feltétele a fordításnak.

	Én [http://www.sublimetext.com/2 Sublime Text 2]-t használtam, de ha szereted a memóriazabáló IDE-ket, akkor ott az [http://www.jetbrains.com/idea/ IDEA], [http://netbeans.org/ NetBeans], [http://www.eclipse.org/ Eclipse] (ebben a sorrendben ajánlanám őket).		Én [http://www.sublimetext.com/2 Sublime Text 2]-t használtam, de ha szereted a memóriazabáló IDE-ket, akkor ott az [http://www.jetbrains.com/idea/ IDEA], [http://netbeans.org/ NetBeans], [http://www.eclipse.org/ Eclipse] (ebben a sorrendben ajánlanám őket).
	==Kommit-policy==		===Kommit-policy===
	Mivel állítólag a kódolás csapatmunka, nem illik a master ágba csak úgy belekommitkodni, szóval érdemes mindenkinek saját ágon dolgoznia, és ott ''gyakran'' kommittolnia. A gyakran úgy van értve, hogy ha a kommit megfogalmazásában szerepel az és szó, akkor már elfelejtettél egy kommitot. Magyarul a kommitok atomiak, 5-10 sor kód legyen bennük max (nyilván lehet, hogy több is lesz, de célszer ilyen nagyságrendben mozogni).		Mivel állítólag a kódolás csapatmunka, nem illik a master ágba csak úgy belekommitkodni, szóval érdemes mindenkinek saját ágon dolgoznia, és ott ''gyakran'' kommittolnia. A gyakran úgy van értve, hogy ha a kommit megfogalmazásában szerepel az és szó, akkor már elfelejtettél egy kommitot. Magyarul a kommitok atomiak, 5-10 sor kód legyen bennük max (nyilván lehet, hogy több is lesz, de célszer ilyen nagyságrendben mozogni).

	Parasztság syntax erroros kódot kommittolni, ilyet ne tegyünk, ellenkező esetben a vétkes sarokba állítható tetszőleges időtartamra.		Parasztság syntax erroros kódot kommittolni, ilyet ne tegyünk, ellenkező esetben a vétkes sarokba állítható tetszőleges időtartamra.
	==Kódolni nehéz==		===Kódolni nehéz===
	Fogadjuk el, hogy ''úgyis'' szar kódot fogunk írni elsőre, ne is próbáljunk mentegetőzni. Te sem, és én sem tudok ''elsőre'' jó kódot írni. Viszont a szar kódot újra kell írni, de minimum refaktorálni.		Fogadjuk el, hogy ''úgyis'' szar kódot fogunk írni elsőre, ne is próbáljunk mentegetőzni. Te sem, és én sem tudok ''elsőre'' jó kódot írni. Viszont a szar kódot újra kell írni, de minimum refaktorálni.

	Ökölszabály, hogy ha egy egység (egy osztály) nem fér ki az editorban egy (max másfél) képernyőre, az a kód szar. Persze a szar kód is működhet, leadás előtt az ember meg annak is nagyon örül, ha egyáltalán lefordul, szóval ez a kód esztétikai értékét növelni, amire meg mondjuk a jó kóder tud áldozni az idejéből.		Ökölszabály, hogy ha egy egység (egy osztály) nem fér ki az editorban egy (max másfél) képernyőre, az a kód szar. Persze a szar kód is működhet, leadás előtt az ember meg annak is nagyon örül, ha egyáltalán lefordul, szóval ez a kód esztétikai értékét növelni, amire meg mondjuk a jó kóder tud áldozni az idejéből.
	==Kommentok==		===Kommentok===
	A kommentek alapvetően azért kellenek, hogy legyen miből doksit generálni. Ha kommentek nélkül nem érti valaki a kódot, akkor az a kód ismét csak szar, újra kell írni/tervezni.		A kommentek alapvetően azért kellenek, hogy legyen miből doksit generálni. Ha kommentek nélkül nem érti valaki a kódot, akkor az a kód ismét csak szar, újra kell írni/tervezni.
	==Kódolási stílus==		===Kódolási stílus===
	Többnyire minden editor csuklóból tud kódot formázni, ettől még érdemes valami egységes kódolási stílust betartani, és speciel sírva tudok fakadni a nem konzisztens whitespace használaton. Mindegy, hogy mit választotok, legyetek konzisztensek, a kód ne nézzen ki úgy, mint egy marék hányás.		Többnyire minden editor csuklóból tud kódot formázni, ettől még érdemes valami egységes kódolási stílust betartani, és speciel sírva tudok fakadni a nem konzisztens whitespace használaton. Mindegy, hogy mit választotok, legyetek konzisztensek, a kód ne nézzen ki úgy, mint egy marék hányás.
	==Debug==		===Debug===
	Debuggolni nem könnyű, főleg egy grafikus játékot. Azért próbáljuk meg, és lehetőleg a ''System.out.println'' legyen az utolsó megoldás erre.		Debuggolni nem könnyű, főleg egy grafikus játékot. Azért próbáljuk meg, és lehetőleg a ''System.out.println'' legyen az utolsó megoldás erre.
	=~~Tervezés~~=		=Egyéb megfontolásra érdemes dolgok=
	A konzulens tanácsait érdemes megfogadni, ő azért van ott, hogy ne csinálj hülyeséget (illetve megbasszon, ha hülyeséget csináltál).		A konzulens tanácsait érdemes megfogadni, ő azért van ott, hogy ne csinálj hülyeséget (illetve megbasszon, ha hülyeséget csináltál).

	Ha nekiálltok tervezni UML diagramokat, ''mindig'' legyen fogalmatok arról, hogy ez kódban hogyan fog kinézni, illetve ''működni'' fog-e majd így a kódban. Ezzel a módszerrel elég sok alapvető hibát ki lehet szűrni. Ha ez nem megy, akkor jön az a szégyenteljes megoldás, hogy a cuccot le kell kódolni, majd a kódból kell előállítani a doksit (ugye alapvetően pont fordítva kéne).		Ha nekiálltok tervezni UML diagramokat, ''mindig'' legyen fogalmatok arról, hogy ez kódban hogyan fog kinézni, illetve ''működni'' fog-e majd így a kódban. Ezzel a módszerrel elég sok alapvető hibát ki lehet szűrni. Ha ez nem megy, akkor jön az a szégyenteljes megoldás, hogy a cuccot le kell kódolni, majd a kódból kell előállítani a doksit (ugye alapvetően pont fordítva kéne).
	=Konzulens=		===Konzulens===
	A mi konzulensük tök jó fej volt, gyorsan válaszolt az emailekre (egyszer hajnali háromkor írtam neki, egy óra múlva már meg is jött válasz :D). Ha valami nem világos a feladatban, vagy nem vagytok biztosak benne, hogy jó úton haladtok, érdemes írni neki, hiszen értekeléskor így is úgy is visszajelzést kaptok a haladásról, csak éppen lehet, hogy a pontjaitok látják ennek kárát.		A mi konzulensük tök jó fej volt, gyorsan válaszolt az emailekre (egyszer hajnali háromkor írtam neki, egy óra múlva már meg is jött válasz :D). Ha valami nem világos a feladatban, vagy nem vagytok biztosak benne, hogy jó úton haladtok, érdemes írni neki, hiszen értekeléskor így is úgy is visszajelzést kaptok a haladásról, csak éppen lehet, hogy a pontjaitok látják ennek kárát.
	=Ha nem megy=		===Ha nem megy===
	Ha nem tudtok együtt dolgozni (valaki képtelen kódolni, rendes UML doksit csinálni, stb), de azért a motiváció megvan, akkor érdemes valami hatékony megoldást keríteni. Ez kb úgy tud működni, hogy mindenki ''csak'' arra a területre fog korlátozódni, amihez ''tényleg'' ért, magyarán a balanszot (mindenki kódol, mindenki dokumentál, mindenki UMLezik) el kell tolni egy jobb irányba. Az ezzel járó lustálkodást, többletmunkát csapaton belül kell lerendezni.		Ha nem tudtok együtt dolgozni (valaki képtelen kódolni, rendes UML doksit csinálni, stb), de azért a motiváció megvan, akkor érdemes valami hatékony megoldást keríteni. Ez kb úgy tud működni, hogy mindenki ''csak'' arra a területre fog korlátozódni, amihez ''tényleg'' ért, magyarán a balanszot (mindenki kódol, mindenki dokumentál, mindenki UMLezik) el kell tolni egy jobb irányba. Az ezzel járó lustálkodást, többletmunkát csapaton belül kell lerendezni.
	=Értékelés=		===Értékelés===
	Minden feladatra kaptok egy értékelés a konzulenstől, a doksiban be lesz karikázva mi nem tetszett neki. Ezt érdemes feljegyezni, ugyanis az összefoglalásban meg fogja nézni, hogy kijavítottátok-e.		Minden feladatra kaptok egy értékelés a konzulenstől, a doksiban be lesz karikázva mi nem tetszett neki. Ezt érdemes feljegyezni, ugyanis az összefoglalásban meg fogja nézni, hogy kijavítottátok-e.
	=Feladatok=		=Feladatok=

Madbence: Saját tapasztalataim/tanácsaim szoftlab4-re.

2013-01-19T22:11:00Z

Saját tapasztalataim/tanácsaim szoftlab4-re.

Új lap

Személyes tapasztalataim, illetve tanácsaim az utókornak.
=A csapat=
Ha levlistán vadászol csapattagokat, vagy akarsz csapatot találni magadnak, mindenképpen érdemes jelezni, hogy milyen területen tartod magad jónak, hiszen lehet, hogy 5 profi Java kóder zseniálisan jól összerakott, és megtervezett kódot tud írni, ha a dokumentáció rossz, nagyon le tudja rontani a teljesítményt.
==Államforma==
Az egyes csapatoknak formálisan kell egy vezetőt választania adminisztrációs okokból, ezen kívül a tárgy mást nem követel meg. Ezt a hierarchiát azonban érdemes komolyan venni, ugyanis a demokrácia csak elméletben hangzik jól.

Tehát kelleni fog egy '''''vezető''''', aki ''mindenkinek'' ki tudja osztani a ''konkrét'' feladatát, és meg tudja szabni, hogy azt ''pontosan mikorra'' kell elkészítenie. Az a módszer, hogy "''Ki mit szeretne csinálni?''", teljesen életképtelen módszer, egyel jobb fokozat az "''Itt egy lista, mindenki kiválaszt 2-3 itemet, és beírja, hogy mikorra készíti el''", de ez sem nagyon tud működni. Én személyesen azt a módszert találtam a legcélravezetőbbnek, hogy "''Te X-et fogod csinálni, Y-ra elkészíted, ez neked megfelel?''". Az ezzel járó konfliktusokat pedig el kell viselni (sosem fog semmi simán menni).

==Kommunikáció==
Ha mindenki kolis, az a legjobb. Egyéb esetben a [http://www.skype.com/ Skype] jó helyettesítő, valamint a levlista (tudom ajánlani a [http://groups.google.com Google Groups]-ot).
A legjobb napi szintű kommunikáció, de egy héten '''''mindenképpen''''' legalább 2 összejövetelt tartani kell. Egy a feladatok kiosztására, egy a haladás összegzésére, a felmerült problémák orvoslására. Egy komoly problémára lehetőleg ne a leadás előtti napon kerüljön sor.

Ha valamelyik csapattag nem lesz elérhető (nyaral, beteg, meghal), azt illik előre bejelenteni.
=Kollaboráció=
Szükség lesz a közös munkára, és illik a Dropboxnál komolyabb technológiákat is igénybe venni.
==Doksi==
Erre a célra érdemes valamilyen Wikit beüzemelni, mi a [https://bitbucket.org/ bitbucket] szolgáltatását használtuk, a repó mellé kap az ember egy wikit is, ami szintén repóként működik. Érdemes megoldani, hogy a Wikiből on-the-fly lehessen pdf doksit generálni, mi erre a célra egy Wiki2LaTeX toolt csináltunk, ami a Wiki saját markupjából LaTeX kódot generált, így gyakorlatilag pár kattintás volt az aktuális Wiki tartalmából dokumentációt gyártani.

Lehet mindenféle WYSIWYG editorokkal bohóckodni (MS Word,Open Office), de csak mazochistáknak tudom javasolni.
==UML==
Érdemes valahogy (értsd: legálisan, vagy illegálisan) valamilyen editort ehhez beszerezni, mi az [http://www.sparxsystems.com/ Enterprise Architect]-et választottuk (találtunk egy "ingyenes" letöltési lehetőséget), de igaziból úgyis csak nyilakat meg dobozokat kell rajzolni, szóval ami ezt tudja, az rendben van. Ha tud menteni vektoros formátumba, az külön orgazmus, mert még ki is fog nézni valahogy a doksi.
==Verziókezelés==
LZ biztos mindenkit bevezetett a verziókezelés rejtelmeibe Szofttechből, csak éppen a többség nem hitte el, hogy ez valami értelmes dolog. Értelmes dolog, és meg kell tanulni használni.
===SVN===
Hagyományos verziókezelő szoftver a [http://subversion.apache.org/ Subversion], valószínűleg valami ilyesmi rendszerről volt szó szofttechen, igaziból mindent tud, amit kell. [http://tortoisesvn.net/ TortoiseSVN] must have jutility, nélküle el se kezdjétek.
===Mercurial===
A [http://mercurial.selenic.com/ Mercurial] egy elosztott verziókezelő (DVCS), az a jó benne, hogy lokálisan is lesz repód. Nem nagyon ismerem, inkább a git-et preferálom
===Git===
[http://git-scm.com/ Az áltimét verziókezelő], ha tudod kezelni, mással nem is érdemes foglalkozni. Írtam hozzá régebben egy [[Szerkesztő:Madbence/Git tutorial|tutorialt]], előbb utóbb felrakom. ([[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 23:11 (CET))
=Kód=
Előbb-utóbb kódolni is kell, érdemes nem szarozni vele túl sokat. Érdemes minél egyszerűbb, logikusabb kódot írni, aminek az előállítására az alábbi algoritmus rendkívül jó:

# Kódolj
# Ha kész van, nézd meg, hogy bonyolult-e. Ha igen, kezd elölről.
# Profit!

==Editor==
Érdemes a Notepadnál komolyabb cuccot használni, de azt figyelembe kell venni, hogy beadásnál parancssorból kell majd fordítani, szóval [http://maven.apache.org/ Maven] ne legyen feltétele a fordításnak.

Én [http://www.sublimetext.com/2 Sublime Text 2]-t használtam, de ha szereted a memóriazabáló IDE-ket, akkor ott az [http://www.jetbrains.com/idea/ IDEA], [http://netbeans.org/ NetBeans], [http://www.eclipse.org/ Eclipse] (ebben a sorrendben ajánlanám őket).
==Kommit-policy==
Mivel állítólag a kódolás csapatmunka, nem illik a master ágba csak úgy belekommitkodni, szóval érdemes mindenkinek saját ágon dolgoznia, és ott ''gyakran'' kommittolnia. A gyakran úgy van értve, hogy ha a kommit megfogalmazásában szerepel az és szó, akkor már elfelejtettél egy kommitot. Magyarul a kommitok atomiak, 5-10 sor kód legyen bennük max (nyilván lehet, hogy több is lesz, de célszer ilyen nagyságrendben mozogni).

Parasztság syntax erroros kódot kommittolni, ilyet ne tegyünk, ellenkező esetben a vétkes sarokba állítható tetszőleges időtartamra.
==Kódolni nehéz==
Fogadjuk el, hogy ''úgyis'' szar kódot fogunk írni elsőre, ne is próbáljunk mentegetőzni. Te sem, és én sem tudok ''elsőre'' jó kódot írni. Viszont a szar kódot újra kell írni, de minimum refaktorálni.

Ökölszabály, hogy ha egy egység (egy osztály) nem fér ki az editorban egy (max másfél) képernyőre, az a kód szar. Persze a szar kód is működhet, leadás előtt az ember meg annak is nagyon örül, ha egyáltalán lefordul, szóval ez a kód esztétikai értékét növelni, amire meg mondjuk a jó kóder tud áldozni az idejéből.
==Kommentok==
A kommentek alapvetően azért kellenek, hogy legyen miből doksit generálni. Ha kommentek nélkül nem érti valaki a kódot, akkor az a kód ismét csak szar, újra kell írni/tervezni.
==Kódolási stílus==
Többnyire minden editor csuklóból tud kódot formázni, ettől még érdemes valami egységes kódolási stílust betartani, és speciel sírva tudok fakadni a nem konzisztens whitespace használaton. Mindegy, hogy mit választotok, legyetek konzisztensek, a kód ne nézzen ki úgy, mint egy marék hányás.
==Debug==
Debuggolni nem könnyű, főleg egy grafikus játékot. Azért próbáljuk meg, és lehetőleg a ''System.out.println'' legyen az utolsó megoldás erre.
=Tervezés=
A konzulens tanácsait érdemes megfogadni, ő azért van ott, hogy ne csinálj hülyeséget (illetve megbasszon, ha hülyeséget csináltál).

Ha nekiálltok tervezni UML diagramokat, ''mindig'' legyen fogalmatok arról, hogy ez kódban hogyan fog kinézni, illetve ''működni'' fog-e majd így a kódban. Ezzel a módszerrel elég sok alapvető hibát ki lehet szűrni. Ha ez nem megy, akkor jön az a szégyenteljes megoldás, hogy a cuccot le kell kódolni, majd a kódból kell előállítani a doksit (ugye alapvetően pont fordítva kéne).
=Konzulens=
A mi konzulensük tök jó fej volt, gyorsan válaszolt az emailekre (egyszer hajnali háromkor írtam neki, egy óra múlva már meg is jött válasz :D). Ha valami nem világos a feladatban, vagy nem vagytok biztosak benne, hogy jó úton haladtok, érdemes írni neki, hiszen értekeléskor így is úgy is visszajelzést kaptok a haladásról, csak éppen lehet, hogy a pontjaitok látják ennek kárát.
=Ha nem megy=
Ha nem tudtok együtt dolgozni (valaki képtelen kódolni, rendes UML doksit csinálni, stb), de azért a motiváció megvan, akkor érdemes valami hatékony megoldást keríteni. Ez kb úgy tud működni, hogy mindenki ''csak'' arra a területre fog korlátozódni, amihez ''tényleg'' ért, magyarán a balanszot (mindenki kódol, mindenki dokumentál, mindenki UMLezik) el kell tolni egy jobb irányba. Az ezzel járó lustálkodást, többletmunkát csapaton belül kell lerendezni.
=Értékelés=
Minden feladatra kaptok egy értékelés a konzulenstől, a doksiban be lesz karikázva mi nem tetszett neki. Ezt érdemes feljegyezni, ugyanis az összefoglalásban meg fogja nézni, hogy kijavítottátok-e.
=Feladatok=
Mire kell figyelni az egyes heti leadott anyagokban. (Majd lesz... [[Szerkesztő:Madbence|lennon]] ([[Szerkesztővita:Madbence|vita]]) 2013. január 19., 23:11 (CET))
=Continuity=
2012 tavaszán csináltuk meg a tárgyat (4-en voltunk a csapatban), az [https://www.box.com/s/d00d89c73e5fb7293cb5 elkészült dokumentáció] összesen 214 oldal (elérhető [https://www.box.com/s/65ea95ccb2382f5284f7 nagyon hipster Helvetica] betűtípussal is). [https://github.com/madbence/fearlesscode_szoftlab Forráskód] (kizárólag okulási célokkal!)