- A hozzászóláshoz be kell jelentkezni
Hozzászólások
Mi a szavazás alapja?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Szeretnénk bevezetni a git-et.
Volt egy-két kisebb demó projekt, amin próbálgattuk és nagyon pozitív az első benyomásunk.
Viszont úgy vettük észre, hogy itt talán egy kicsit nagyobb tanulási idő kell a dolgozók részéről mielőtt biztonságosan használni tudnák.
Emiatt van egy kis félelmünk a bevezetés miatt.
Azt remélem, hogy itt előjönnek esetleges problémák, amikbe esetleg mások belefutottak.
A szavazásnál nem csak a git hibáiból eredő problémákra vagyunk kíváncsiak, hanem még inkább a rossz használatból eredő problémákra.
Más kárán szeretnénk tanulni! :-)
Esetleg másoknak is hasznára válhat ez a szavazás, illetve az esetlegesen összegyűlt problémák és megoldásuk.
- A hozzászóláshoz be kell jelentkezni
Kétségtelenül hosszabb a tanulási görbéje, mint egy centralizált verziókövetőnek.
Egyébként szerintem csak akkor érdemes ilyen kis létszámnál git-et használni, ha a fejlesztők ki tudják használni a local branching-et, a git többi előnye szerintem itt elhanyagolható. Ha nem tudják, akkor jobb választás lehet az SVN, mivel gyorsabban tanulható.
Én amúgy alapvetően nagyon szeretem a gitet, de ettől függetlenül nem kell erőltetni. Ha nem a git a legjobb megoldás, akkor nem kell csak azért használni, mert manapság az a menő VCS.
- A hozzászóláshoz be kell jelentkezni
Szerintem se, 10 fo alatt siman svn, sot, a git-nek a local branchingje szerintem kifejezetten hatrany, mert politikai kerdest csinal abbol hogy miert kell mindig mindent commitolni (pusholni) a szerverre (svn-be mashova nem tudja, igy nem merul fel a kerdes), de manapsag ez a meno, ennyi.
Evek kellettek ahhoz is, hogy az emberek rajojjenek, hogy a Symbian egy otvarszar telefon-oprendszer, ma mar ez mindenkinek nyilvanvalo, including nokia. A git ennyire nem rossz, meg valamire a legalkalmasabb, de kis ceghez tullovesnek latom.
- A hozzászóláshoz be kell jelentkezni
Nem az emberek számától függ, hanem attól, hogy mit értesz verziókezelés alatt.
Vannak, akik csak azt értik alatta, hogy legyen egy hely, ahova egyszerűen belehányhatják a kódjukat, illetve ahonnan lehúzhatjuk a szomszéd irodában ülő kolléga kódját. Hogy az egymástól független feature-öket implementáló commitok össze-vissza vannak egymás után? Sebaj. Hogy egy commitba több, egymástól független változtatás is bekerül? Szóra sem érdemes. És hogy ehhez csak annyi kerül a commit message-be, hogy "bugfix"? Ugyan. Esetleg nap végén mindent commitolni kell, hogy "el ne vesszen"? Nem számít, ha kész sincs, esetleg még csak le se fordul? Smafu. Nos, ők nyugodtan használhatják továbbra is megelégedéssel a Subversiont (CVS-t, ClearCase-t, stb-t), felesleges még csak elgondolkodni is a bármi másra váltáson.
Ezzel szemben vannak, akik már rájöttek arra, hogy előnyös, ha egy commitba csak logikailag összetartozó változások kerülnek, mert az ilyenekből felépülő tiszta és áttekinthető history a későbbiekben nagymértékben segíti a kód megértését, ellenőrzését, bugok fixálását, stb. Kis logikai egységekből álló commitok létrehozásához viszont kell, hogy a verziókezelő aktívan segítse a usert, hogy támogasson olyan műveleteket, amik egyszerűen lehetővé teszik egy file-ban lévő módosítások csak egy részének commitolását, commitok egybeolvasztását illetve felosztását, commitok sorrendjének átrendezését, a log message megváltoztatását, stbstb. Aztán ha ezeket kiegészítik olyan eszközök, amikkel könnyen lehet a historyban bányászni, pl. greppelni log message-ben és/vagy a changesetben előforduló szavakra, blame/annotate esetén ignorálni az indentálás változásait vagy követni a kód mozgatását, valamint automatizáltan megkeresni az első commitot, amiben lévő változás miatt egy bugreportból származó teszt megbukik... és mindezt gyorsan teszik, akkor lassan eljutunk odáig, hogy manapság mit jelent a verziókezelés.
Ez az a pont, ahol az úgynevezett verziókezelő rendszerek többsége csúfosan elvérezik, és a git állva marad, meg talán a Mercurial, féllábon.
Még éveknek kell eltelniük addig, hogy az emberek rájöjjenek: a Subversion nem alkalmas verziókezelésre ;)
- A hozzászóláshoz be kell jelentkezni
Ott rontod el az egészet, hogy azt feltételezed, MINDENKINEK szüksége van a te általad felsőbbrendűnek tartott fícsörökre. De ez nem így van. A gittel sok a szívás, nem csak a betanulási szakasz alatt, hanem a brancheid menedzselésénél is. Ahhoz, hogy a párhuzamosan fejlesztett dolgok aztán később "kis logikai egységek" formájában kerüljenek betolásra befektetett munka kell. Nem mindig éri meg. Van ahol igen, van ahol nem.
A CC meg pont hogy nagyon durván támogat mindenféle okosságot, csak kicsit átláthatatlan svn-hez szokott aggyal. Az a label rendszer és a többi metaadat nagyon nagy rugalmasságot ad neki.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
"a te általad felsőbbrendűnek tartott fícsörökre."
Szerintem ezek alapvető feature-ök.
De lehet, hogy igazad van, és itt rontom el ;)
"Ahhoz, hogy a párhuzamosan fejlesztett dolgok aztán később "kis logikai egységek" formájában kerüljenek betolásra befektetett munka kell."
Mint ebben a szakmában sokminden máshoz, pl. tesztelés, dokumentálás, .... De jobban belegondolva, talán az ezekbe fektetett munka se mindig érné meg?
- A hozzászóláshoz be kell jelentkezni
>Szerintem ezek alapvető feature-ök.
Igen, ott rontod el, hogy dugóhúzót vársz el egy késtől. Az a bicska. Más cél, más eszköz.
>De jobban belegondolva, talán az ezekbe fektetett munka se mindig érné meg?
Van az a munka, ami emeli a minőséget, és van ami nem (vagy csak elhanyagolhatóan). Ez utóbbit kell lefaragni, és sok projektnél egy elosztott verziókezelő használata bizony ilyet generál.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
"Igen, ott rontod el, hogy dugóhúzót vársz el egy késtől. Az a bicska. Más cél, más eszköz."
Szerintem idő kérdése, és egyre többen keresik majd a kisollót is.
[szerk.: Vajon ha kb. húsz éve beszélgettünk volna verziókezelésről, amikor még az RCS volt a menő, de a CVS is létezett már, akkor a CVS-re is azt mondtad volna, hogy az a svájci bicska, mert már kliens-szerver és mert több file-t képes kezelni? Pedig az idő azóta CVS-t igazolta -- aztán persze azon is túllépett.
Egyébként grat a késes-bicskás hasonlathoz: már másik két hozzászóló is használta itt lejjebb, miközben autós hasonlat még egy se volt ;)]
"Van az a munka, ami emeli a minőséget, és van ami nem (vagy csak elhanyagolhatóan). Ez utóbbit kell lefaragni, és sok projektnél egy elosztott verziókezelő használata bizony ilyet generál."
És van, ahol a git használata és a befektetett munka komoly minőségbeli javulásban (és nem mellesleg év végi bónuszban) mutatkozik meg:
http://article.gmane.org/gmane.comp.version-control.git/76830
http://lwn.net/Articles/317154/ (utolsó idézet)
- A hozzászóláshoz be kell jelentkezni
Egyébként grat a késes-bicskás hasonlathoz: már másik két hozzászóló is használta itt lejjebb, miközben autós hasonlat még egy se volt ;)]
Csak neked: SVN után Git-et használni olyan, mintha traktorból terepjáróba ülne az ember. Mindkettő megy, csak nem mindegy, hogyan… :)
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
bar tfs-t hasznalunk (es szeretem is), teljesen egyetertek. viszont meg boven van mit megvaltoztatnom bent, mint, hogy az osszevissza commitok miatt idegeskedjek. alakul, csak lassan, mert paradigma valtas kell. az kiraly, ha nalatok ez igy megy, jo ilyet hallani.
- A hozzászóláshoz be kell jelentkezni
+1
Pont ezert szorgalmaztam anno a git hasznalatat, es ezert is valt be. Sokkal konnyebb managelni a kodot meg akkor is, ha rovid tavon tobb idonek tunik; hosszu tavon boven megterul. Ra kell szokni, es kell egy kis elhatarozas is az elejen, de nalunk a commit elemisege annyira alap lett, mint az egyseges kodolasi stilus.
Az elemi commitok elonye meg a git bisect, amivel nagyon gyorsan lehet regressziokat lokalizalni.
- A hozzászóláshoz be kell jelentkezni
Ertem en amit mondasz csak ehhez nem git kell hanem ertelmes emberek, pontosabban egy ertelmes ember minimum, a teamlead.
Eleve ha ket valtozashoz egy fajlba kell nyulni akkor valakit seggberugok. Na jo, ez igy nem igaz, de a rendszer szedje ossze reflectionnel meg builddel szepen indulaskor a dolgokat amiket amugy egy helyen modositgatna mindenki keresztul-kasul.
Ha neked egy fajlt kell ket eltero change-hez modositani, akkor serul a Single Responsibility Principle. Nem erdekel hogy config fajl, az is a forraskod resze.
Ezt nem a verziokezelonek kell tamogatnia, hanem annak az allatnak (alt. en szoktam lenni), aki minden egyes commitot szepen elolvas a tracban, meg kiosztja a feladatokat, es feltunik neki hogy ket modositas kerult egy commitba.
Namost erre ugye a git teljesen alkalmatlan, az ilyen bazar-stilusu fejlesztesre valo.
Erdekes modon en meg mindig qrva gyorsan kiszedtem SVN-bol az altalad emlitett infokat, igaz, hogy trac-cal meg fisheye-jal, meg webes feluleten, cserebe nem voltak szanaszet a feature branchek a fejlesztok gepein lokalisan, hanem lattad hogy az adott tickethez tartozo branch (mert minden nem "csereljuk ki a pirosat zoldre" ticket kapta a kulon kis branchet,igen, svn-ben meg cvs-ben) epp hogy fejlodik, jo, izomtibi kellett a verziokezelo masina ala, meg ha nem volt vmiert, akkor az emberek alltak at lokalis mercurialra meg egyeb csodakra, de az svn jobb helyeken eleg fontos volt ahhoz hogy sz.rrareplikalva legyen 99.99%-os uptime-mal.
Nem azt mondom hogy nem kellenek az altalad emlitett dolgok, azt mondom ,hogy ezeket forraskod- es fejlesztesszervezessel sokkal hatekonyabban lehet elerni.
Meggyozodesem hogy ez az egesz "onszervezo" csoport-felelossegesdi tobbek kozt azert indult utjara, mert marha kevesen voltak azok az emberek, akik fel tudtak ismerni az antipatterneket a commit logokba, let alone egyaltalan hogy napi 30-40 commitot atnezzenek, felig kezzel, felig continous buildszerveren levo stylecheck-lint-whatever toolokkal. De attol hogy a lovak koze dobod a gyeplod nem oldodik meg, csak feladod.
Innentol kezdve viszont azzal ervelni, hogy azert alljunk at erre a kaoszgepre, mert jobbak a menedzsment-funkcioi, es feltunesmentesen lehet vele szar kodot leadni (egy fajl tobb felelossegi korrel), ez nem erv. Azt se szeretem ha a fejlesztoknek tul sok kulonbozo env-juk van, mert nagyon hamar eljutnak a megertesi kapacitasuk vegere (oh, persze, minden fejleszto mindig mindent tud, meg nem lesz semmi baj, csak 4-5 env utan mindegyik zsenikenel beut a krach), hat meg ha van 20 szarrabranchelt working copy-juk is, hat az kulon orom.
Ugye anno egy masik git vitaban mar megegyeztunk, hogy a gittel mindent meg lehet csinalni de nem mindent erdemes. A kiscsoportos vallalati fejlesztesek toolja az SVN, iszonyatosan profin van erre belove, ezt tovabbra is tartom.
- A hozzászóláshoz be kell jelentkezni
"Ertem en amit mondasz csak ehhez nem git kell hanem ertelmes emberek"
Értelmes emberekre is szükség van; egy eszköz sem működik magától.
A hozzászólásod többi része alapján viszont azt gyanítom, hogy nem értetted meg, amit írtam.
- A hozzászóláshoz be kell jelentkezni
Mondasz ficsoroket, amikkel az van, hogy szep es jo, de kivitelezheto kozponti verziokezelessel, mig azt nem arulod el, hogy miert nem fog a rendszer szanaszet szaladni.
Lattam projektet bebukni tul eros kontroll miatt, de annak hianya miatt tobbet.
- A hozzászóláshoz be kell jelentkezni
Gyakori eset: fejlesztesz eppen egy uj funkcionalitast egy fajlban, es mikozben irod, eszreveszed, hogy egy masik fuggvenyben eliras van / hianyos a comment stb. Ekkor gitnel helyben javitod, majd amikor vegeztel, akkor atnezed a valtoztatasokat, es megfeleloen commitokra osztod (pl ez a kis fix meg egy kulon commitba).
Sot, olyan is van, amikor egy feature implementalasahoz tobb helyen is bele kell nyulni a kodba, ilyenkor kenyelmesebb megcsinalni az osszeset, ellenorizni, hogy jo-e, aztan 10 percet raszanni, hogy a valtoztatasokat darabokra szetszedje az ember, igy a refacoringok kulon commitokba mennek, es ha regressziot okoznak, akkor konnyu izolalni.
- A hozzászóláshoz be kell jelentkezni
"Ugye anno egy masik git vitaban mar megegyeztunk, hogy a gittel mindent meg lehet csinalni de nem mindent erdemes. A kiscsoportos vallalati fejlesztesek toolja az SVN, iszonyatosan profin van erre belove, ezt tovabbra is tartom."
+1, sőt, nemrég beláttam, hogy míg SVN-nel könnyen meg lehet oldani a repo-n belül ACL-eket, git és mercurial esetében ez borzalmas fájdalommal jár (ott kezdődik, hogy elkezd sok repo-d lenni, és ott ér véget, hogy feladod).
Igazából az SVN nagycsoportra is jó lenne (kliens oldalról meg a felépítését nézve), csak a jelenlegi szerver oldalt le kellene cserélni (amit néztem, amúgy nem is nagyon nehéz, csak terméket kellene készíteni hozzá, hogy megérje a belerakott munka).
- A hozzászóláshoz be kell jelentkezni
"Ez az a pont, ahol az úgynevezett verziókezelő rendszerek többsége csúfosan elvérezik, és a git állva marad, meg talán a Mercurial, féllábon."
Mondjuk ez az a rész, ahol bejön az, hogy a verziókezelőt jó lenne kiegészíteni valami projekt menedzsment rendszerrel és néz egy redmine-t (vagy bármi mást, mi azt használjuk) az SVN mellé.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Hmm, ez egy remek kis összefoglalás. Manapság már én is gittet használok és azt is preferálom mindenütt.
De igazad van, 90-es években dolgoztam olyan cégnél ahol csak azért vezették be a verzió kezelést, hogy a főnök is chekoutolni tudja a kódot. Azt nézegette, hogy lefordul-e hiba mentesen.
Aszondó vagyok nem baj ha az ember svájci bicskát használ vágásra. Lehet vele vágni és eljöhet az az idő amikor ki kell húzni egy dugót és akkor nem kell egy új eszközt megvenni.
--
GPLv3-as hozzászólás.
- A hozzászóláshoz be kell jelentkezni
"előnyös, ha egy commitba csak logikailag összetartozó változások kerülnek"
Ez igaz, de ez svn-ben is megoldható. A megoldás pedig az, hogy nem 1, hanem több working copy-t kell fenntartani, az egyik fejlesztést az egyikben, a másikat a másikban végzed. Ez azért jó megközelítés, mert így fordításkor csak az egyik lesz jelen, ezért nem fordulhat elő, hogy az egyik nem fordul vagy nem működik rendesen a másik kód nélkül. Ezt az ellenőrzést git esetén is illik megtenni...
Az SVN szinte mindenben állva marad az általad felsorolt kritériumokban, kivéve a "követni a kód mozgatását". Ez kétségtelenül nincs meg, de szerencsére nálunk ez igen ritkán okoz problémát, és akkor sem nehéz továbblépni rajta.
Nekem git-ben a local branch tetszik a legjobban, az is csak azért, mert kísérleti kódot jobb így átadni, mint patch fájlban, az svn brancheit meg egyszerűen nem szeretem.
- A hozzászóláshoz be kell jelentkezni
nem 1, hanem több working copy-t kell fenntartani, az egyik fejlesztést az egyikben, a másikat a másikban végzed.
Ezt hívják „workaround”-nak, bár még annál is csúnyább. Képzeld el tíz working copy-val,
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Vagy ez vagy pedig a fájloknak csak egy részét/részletét commitolod és reménykedsz, hogy önmagában is fordul a felcommitált rész, mert te külön nem fordítottad. Gányolás mindkettő. Nem hiszem, hogy lenne jó megoldás, függetlenül attól, hogy git vagy svn.
Nyilván 10 working copy-t használni nem csak nehézkes, de összefüggő munkáknál (pl. refactoring és rá épülő új funkció) szinte lehetetlen is. Csak független javításokat és fejlesztéseket tennék külön working copy-ba, ami nyilván nem lesz egszerre 10 db.
Tehát svn-ben a refactoringot vagy az új funkcióval együtt teszi fel az ember, ami nem túl szép, viszont garantáltan fordul, vagy ha más fájlokban van a refactoring, akkor sikerülhet külön is. Szerintem nem vészesen nagy a különbség, feltéve, ha az ember értelmes logot ír hozzá.
- A hozzászóláshoz be kell jelentkezni
Tehat akkor megiscsak ott vagyunk ahol az ipar is 20 eve, hogy minden task kulon agon kell menjen, nem pedig egy agon de kulon commitolva, mint amit mas szalakban hallhattunk. :)
--
Cuda ARM Development Kit az NVIDIA-tól | cythoon
- A hozzászóláshoz be kell jelentkezni
issue-nként külön branch-ot nyitunk, szükség esetén azokat rebase-sel mozgatjuk, majd merge a megfelelő ágba
http://hup.hu/szavazasok/20111220/vallalatunknal_legalabb_harom_ember_k…
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Ez kb. olyan kérdés, mint a #if kontra külön ág. Nem hiszem, hogy lenne jó válasz a kérdésre. A git extra képességei (avagy az svn korlátai) max. segíthetnek egyik vagy másik szenvedő ág fele való elindulásban.
- A hozzászóláshoz be kell jelentkezni
Gitben viszont a branchinggal es a changesetekkel ezt szepen el lehet szeparalni. En a refactoringot kulon branchen csinalom, forditom, tesztelem, ha megy, commit, ha vegesztem, johet a merge.
Mondjuk eleve, en a devel agat kulon tartom a mastertol, oda mindig a kesz, mukodo, stabil kod kerul, nalam a master az a Golden Master roviditese, innen mar deployra megy minden, mert vannak olyan korlatolt deploy megoldasok, amik csak a master aggal tudnak egyuttmukodni. Van a develop ag, itt zajlik az erdemi fejlesztes, vannak a kulon feature meg bugfix agak, innen mergelek eloszor a develop agba, ha az fordul-fut, akkor mehet a master agba, push, es deploy.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Igen, ez így tök jól hangzik. De Agile szempontból a refactoring feladata az, hogy mindig olyan munkát adj ki a kezeid közül, amit büszkén felvállalsz. Ha ilyen tökéletes kódból indulsz ki egy újabb fejlesztéshez, akkor a fejlesztés alatt végzett refactoring az új fejlesztésed szerves része. Ha így van, akkor miért kell neki külön branch?
- A hozzászóláshoz be kell jelentkezni
Mert a refactoring lehet, hogy a fejlesztes szerves resze, de biztos, hogy nem az uj feature szerves resze, igy en kulon kezelnem. Abban az esetben, ha a kod egy kis reszet kell refactoralni, nyilvan nem kell kulon branch, de ha egy nagyobb reszt refactoralsz, ott mar sokminden erintett lehet, azt kulon agra kell rakni.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
OFF:
Az Agile az az a metodologia, aminek a howto-jaban nem szerepel a user szo, a programozast pedig valamifele fizetett tevekenyseg (azt csinalom amit a vevo mond tekintet nelkul arra ez jo-e barkinek) es a maszturbacio (figyelek egy csomo dologra, ami feluton van a gamification es a szintiszta cargo cult kozott) kozott lehet meghatarozni leginkabb altala.
Szerintem a programozas feladata a felhasznaloi problemak megoldasa. Erre az Agile teljesseggel alkalmatlan, grepelj ra a user szora a manifesto-jukban - valami felsorolasban ott van, kb. hogy "a portasnak es a takaritonoknek is koszonni kell, ja, a usereknek is". De inkabb ne dugjak a scrum team kornyekere a budos pofajukat, a menedzserek jobban tudjak, mi kell nekik
ON:
Refactorolni azert refactorolsz, mert:
1) Rajottel, valamit rosszul fejeztel ki, talaltal egy jobb kifejezest
2) Olyan mertekben megvaltoztak az uzleti korulmenyek, hogy az valtozast igenyel.
Viszont a refactor - elmeletben - ortogonalis arra, mit fejlesztesz eppen. Pl. ha talalsz egy antipatternt a kododban, vagy rajossz hogy valamit altalanositani kene, amit eddig nem vettel eszre, es minden kulon kezeli, ez biza sok kodot igenyel.
A gyakorlatban mondjuk teny, hogy modulonkent szoktam en is kerni a kod kimosasat, mert meg nem lattam olyan menedzsert aki idot adott volna ra mashogy, mar ha a korulmenyek nem tettek lehetove az automatikus megoldasokat nyilvan.
- A hozzászóláshoz be kell jelentkezni
huhh, valami nagyon nagy trauma érhetett Téged az agile kapcsán :)
nem mondom, én is láttam már hogy mennyire félrehasználják, de legalább láttam jó példákat is :)
--
munka | szótár | blog | fotó
- A hozzászóláshoz be kell jelentkezni
Hat en elkuldtem a f.szba multkor a ThoughtWorks-ot mondvan, hogy ezt most hagyjak abba, mert ez mar egyenesen karos...
De amugy a gondolkodasmod az tenyleg ilyen coder-szabalyok a coderekert, ha elolvasod a manifestot, akkor latod.
En is csinaltam jo Agile-t mar, de fazok azoktol az emberektol akik ezt komolyan veszik, mert verprofik, akik semmit nem hajlandoak tenni a userert.
- A hozzászóláshoz be kell jelentkezni
Nemcsak elolvastam, de "tanítottam" is a manifestot, és van azért ott user- ill. business-centrikus rész is itt-ott. Inkább azon múlik, hogy mit akarsz belelátni és hogyan akarod (félre-)értelmezni :) Azt hiszem a rossz példáid inkább a félreértelmezés kategóriába sorolhatóak, de ettől még az agile nem feltétlen rossz...
--
munka | szótár | blog | fotó
- A hozzászóláshoz be kell jelentkezni
(OFF)
Ja, multkor a CD-s szerzokkel vitatkoztam, kiderult, hogy egyikuk szamara az Agile annyit jelent, "iterativ" - hat en igy neztem... Semmi lightweight, kokemenyen processek es toolok, ha iterativ, akkor neki Agile. Copliennel meg azon hisztiztem, hogy szep es jo, hogy a SCRUM-ot most patternekkel akarjak kiegesziteni, de irja mar meg pattern language-kent a scrum-ot valaki, hogy tudjak ervelni, mikor nem hasznalandoak az elemei.
En azt gondolom, a szoftverfejlesztesnek elveszett a fokusza, a fejlesztok nem latnak usert, a meghatarozo fejleszteseket mamutok vegzik, nem kisvallalkozasok. Ez nehany fejlesztonek igy jo (nem is akar embereket latni, azert lett fejleszto, hogy csak gepekkel kelljen erintkeznie), de a usernek nem az.
Anno azert a RUP-os oktatasban, tudom, nem szeretted Kapufat, de a RUP-nak es elozmenyeinek (Jacobson: Object-Oriented Software Engineering: A Use-Case Based Approach) volt egy ilyen patosza, hogy vannak valos felhasznaloi igenyek, a vilaggal baja van az atlagfelhasznalonak, es a problema szetelemzesevel egy nagyjabol atlatott folyamattal eloall annak megoldas ellentetparja.
Ez design, annak minden ertelmeben, ez elegancia, ez mernokseg, ez profizmus, ez valami, ami emberi (human) vagy ember feletti, ez felette van a homokozonak.
Nezd meg a SCRUM guideline-t, tegyel egy CSM vizsgat, szo nem lesz userrol, meg user problemakrol.
Azon fognak vitatkozni a programozok, hogy Jira legyen vagy mas, meg hithaborut inditanak a javarol meg az XML-rol.
A User Story-k katasztrofalisak, sehol nincs a use case metodologiahoz kepest, olyan mint kobaltaval szivmutetet csinalni.
Egy gamifikalt f.s az egesz Agile, a Hogy Tarts Retro- meetinget jatekoktol a falra tudnek maszni, mondom, gyerekek, itt van 80 bug, odakint meg emberek szopnak ezek miatt, mi lenne ha azzal foglalkoznank, hogy ezeknek az embereknek az eletet szisztematikusan jobba tennenk ahelyett hogy pszichologiai treninget tartunk rola, hogy "mindenki az ertekrendje alapjan a legjobbat adja" - egyszer megkerdeztem, es hogy tudnank ezeken az ertekrendeken surgosen valtoztatni, mert attol meg hogy az ellenseges katona is a tole telheto legjobbat adja, nekem ki kell iktatni ha jot akarok. Nagyon nem orultek nekem. De legalabb a ceg nyilvanvaloan all bele a foldbe.
Evek ota nem lattam olyat, hogy valaki civilizaltan tudjon modellezni, egyaltalan megertse azt, hogy mit kell nezni egy adott problemaban, egy explicit listat tudjon reflexbol felallitani, vagy mondjuk egy allapotgepet reflexbol teljesre rajzoljon, hogy tudja, hogy a felbontasa (resolution, nem division) a problemanak hogy szamit.
Megerzesre planning pokerezni, legalabb strip poker lenne (ahhoz kene tobb programozo-lany...) 10%+- -om van FPA -val, mi a fenenek becsulgessunk hasra? 3 hettel tevedek max 1 napot!
Ilyen sejteses tingli-tangli megy. Ennel van jobb. Ennel a 80-as 90-es evekben elobbre voltunk, en nem fogadom el, hogy ennek igy kell lennie, en lattam jobbat, es probalom megmutatni mindenkinek a sajat munkammal, hogy a szoftverfejlesztes az egy design folyamat, aminek a vegtermeke egy explicit vegrehajtasi terv (forraskod), de kozbe nem osemberes modszerekkel kortancot jarunk, mert ezt irja a Scrum Guide.
- A hozzászóláshoz be kell jelentkezni
Jajj ne már, sikerült annyi félreértést összeírnod, hogy muszáj reagálnom :)
Mondjuk kezdem azzal, hogy egyértek: sok cégnél annyira személytelenné és felhasználó- illetve üzletmentessé vált a fejlesztés, hogy elszakadnak a valóságtól. Ez sajnos ilyen szakma, de azért nem reménytelen a helyzet. Az is tény, hogy sokan úgy tanítanak / konzultálnak / gyakorolnak dolgokat, hogy nem értik meg a lényegét, így inflálódott el az is, hogy "agilis", és így került a rossz gyakorlatok által rengeteg félreértés a téma köré. Ez egy kicsit reménytelenebb, mert az ilyen típusú emberek tipikusan "hangosabbak".
DE. (jó nagy de...)
A Scrum esetében:
- Eleve azzal kezdi, hogy "itt van kb. 10 módszer, használd azt, amit jónak látsz belőle, és használd azt, amit ezen kívül a szervezeted szükségesnek tart". Tehát Egy_Igaz_Agilis_Út-ról beszélni eleve sarlatánság, minimum 1000 variáció létezik belőle. Innentől kezdve az, hogy "az agilis nem működik" finoman szólva egy figyelmeztető jel arra, hogy kivel állsz szemben :)
- Azt senki nem ígéri, hogyha ki akarod zárni a világot, akkor nem tudod kizárni (azaz továbbra is tudsz a világtól elszakadva fejleszteni), viszont ha ezt felismered és nem akarod kizárni a világot, akkor a Scrum ad egy feedback-loopot, amihez lehet igazodni... És az igazodás a megrendelőnél és a fejlesztőknél is ugyanaz a pont, ami pl. egy waterfall esetében Az_Aláírt_Specifikáció, addig Scrum esetében a Fontosnak_Gondolt_Problémák. Hogy ténylegesen jól gondolják-e a fontosságot, az ugye egy más kérdés, ami nem technológiai/módszertani, hanem inkább HR-/üzleti elemzés kérdés.
- Azt senki nem ígéri, hogyha X módszertant használsz, akkor hirtelen megtáltosodsz, és 40 órányi munkák végzel el 1 óra alatt, vagy hogy hirtelen nem lesz szükséged szaktudásra. Sokat küzdöttem olyan managerekkel, akik ilyen mondatot akartak kipréselni belőlem (hogy aztán 200 fős olcsó outsource "scrum team" csinálhassa a munkát), de hiába, ezt csak azok merik kijelenteni, akik nem végeznek igazi fejlesztést. Viszont a Scrum segít abban, hogy a 40 órányi munkád nagyobb arányban legyen értékes, mint waterfall esetében. És itt az értékes (illetve annak aránya és megváltozása) az elég emberfüggő, meg csoportfüggő, meg szervezetfüggő, meg üzletfüggő...
- Azt senki sem ígéri, hogy Scrum esetében megúszod a tervezést vagy az újratervezést, vagy éppen a fejlesztés kidobását (vagy ha ezt ígérik, akkor megintcsak nem csináltak még valódi fejlesztést). Az ígéret arról szól, hogy korábban kiderülnek a problémák, amikre reagálni kell. Aki látott már 4+ éves projekteket "sikerülni", az sejti, hogy mire gondolok, és sajnos nem csak az állami szférára jellemzőek, sokkal inkább a pointy-haired-boss/clueless-megrendelő tipikus esetei.
Van még egy csomó más apróság is, de ezeket ki kellett írni ide :) Ahogy látod, nálam a scrum inkább a termékfejlesztésről és nem annyira a szoftverfejlesztésről szól. Persze, a cél tipikusan szoftver, és mint ilyen kell hozzá véső meg kalapács (*), viszont a scrum jól segíti azt a fókuszt, hogy ne csak egy lefordított bináris legyen a végeredmény, hanem egy termék is. Ettől még van akinek scrum nélkül is természetes módon adódik a termékfejlesztés része, és van akinek scrummal sem megy...
(*) mint tudjuk, ezek a szoftverfejlesztés elengedhetetlen eszközei a debugger mellett. on different topic: a kőműveseknél mi a debugger? :)
- A hozzászóláshoz be kell jelentkezni
Nem kell bemutatni a szoftverfejlesztest, koszi, pontosan tudom mirol beszelek.
A scrum-bol nincs 10 fele, menj fel a scrum alliance honlapjara, szedd le az official scrum guide-ot, nyomj ctrl-f-et, ird be hogy user, enter, egy talalatod lesz, az is "scrum user" kifejezesben, tehat arra a szegeny okorre vonatkozik akire rahuztak vagy rosszabb esetben bevetettek ezt a cargo cult maszlagot, mert miertek amugy a guideline-ban nincsenek, csinald ezt es jo lesz neked, ez a doksi felepitese.
A scrum per definitionem kizarja a felhasznalot, es egyetlen menedzserfiguraval, a product ownerrel helyettesiti, mondvan tul nagy lenne a zaj. Ott van, nem en talaltam ki, ez az allaspont, es ez a keresztulvert allaspontja jopar agile coaching company-nak is.
Nem ertem, hogy egyfelol 2011-ben miert a hideghaborus waterfallhoz hasonlitgatja valaki a scrum-ot meg az agile-t, es beszel ugy mintha a 80-as 90-es evek nem tortent volna meg, nem fejlszetettek volna ki a spiralis modellt, nem lett volna rup. Az mas kerdes hogy a waterfall IS iterativnak volt szanva, igaz nem lightweightnek de ugye ehhez el kene olvasni a disszertaciot, annak megertesehez hogy akkor es ott miert nem lehettek a dolgok lightweightek pedig ismerni a konkret projektet, de legalabb tenyleg elolvasni a mythical man month-ot, ami egy mas projekten keresztul bemutatja a kor szokasait, nem csak hivatkozni a mai napig divatos szolasokra belole.
Nem azzal van bajom hogy az agile marhak code only gondolkodasmodja - kulonosen a helyettesitsunk futtathato unit tesztekkel tervezesi eljarasokat - fertozi az ipart, azzal is, de leginkabb azzal hogy jon fel egy generacio aki mar arra se emlekszik, hogy a regi modszerek bazdmeg tenyleg mukodnek, van rendes matematikai modell, ami nem Lantos-szintu, es ha egyszer volnal szives kitolteni vele egy excelt csak probakepp, kisulne, hogy tudunk jol becsulni, vagy ha megtanulnal rendesen uml-ezni, akkor kiszurnel olyan hibakat amikre nem is gondolsz, es erre persze csak akkor jossz ra ha mar megtanultal, es egy kis ideig csinalod komolyan, de ilyen ember lassan mar a sargolyon se letezik aki tenyleg tud meg modellezni es nem olyan oreg meg, hogy ne menedzser legyen.
Vegezetul: az agile per definitionem nem termekfejlesztes, hanem ugyfelkiszolgalas (menedzser-kiszolgalas a gyakorlatban). Lehet belelatni a sajat dolgaidat, de egy angolszotar meg a hivatalos doksik tenyleges elolvasasa sokat segit abban, hogy oszinten tudd elkuldeni a faszba azokat, akik ezt a tomeny marhasagot komolyan veszik - bele lehet latni termekfejlesztest is, meg code-only nirvanat is, de egyikrol se szol egyaltalan.
- A hozzászóláshoz be kell jelentkezni
"az agile marhak code only gondolkodasmodja - kulonosen a helyettesitsunk futtathato unit tesztekkel tervezesi eljarasokat - fertozi az ipart"
Test Driven Developmentre gondolsz? Én sem az Agile Manifestóban sem a Principles-ben nem látom a TDD kifejezést, de még a "test" szót sem.
"az agile per definitionem nem termekfejlesztes, hanem ugyfelkiszolgalass (menedzser-kiszolgalas a gyakorlatban)."
Igen, ez a tipikus esete, amikor Agile-nak hívjuk azt, ami nem is az. Az Agile valódi értékekre és valódi szereplőkre fókuszálásról szól. Ez van a Manifestóban és a Principles-ben. Egy fejszét is lehet gyilkolásra használni, de attól még rendeltetésszerűen használva favágó eszköz.
- A hozzászóláshoz be kell jelentkezni
Igen, a tagadoszavak, pl. a nem negaljak a mondat jelenteset, valoszinuleg ezert kerult bele.
- A hozzászóláshoz be kell jelentkezni
Az csak 3 betű. A következő iterációban majd javítom. :)
- A hozzászóláshoz be kell jelentkezni
Az a baj, hogy a Te prekoncepcióid ("keress rá a honlapon") távol állnak az én valóságomtól (követtem, elmeztem a pszichológiáját, oktattam, ...). Tényleg működik a scrum és tényleg felhasználó-központú. Hogy nem látod bele, azzal én nem leszek kevesebb, igaz Te sem. Viszont azzal, hogy hangosan tagadod, ami rengeteg embernél jól működik, azzal nemcsak magadnak ártasz, hanem azoknak is, akiknek fogalmuk sincs a témáról.
--
munka | szótár | blog | fotó
- A hozzászóláshoz be kell jelentkezni
En meg XP-ztem, mmint nem windows, hanem Beck-fele XP.
En is oktattam projektmetodologiakat, sot, tanultam oktataspszichologiat, csapatelmeleteket, szociologiat, es bar sok helyen mukodik a csapat egy scrum-szeru envben, en azt allitom, ezt nem a scrum-tol teszik, hanem attol hogy epp sikerult jo embereket kifogni, akik pontosan tudtak, hogy abbol a bullshithalmazbol mit kell nagyon gyorsan kihagyni.
Nem csak en mondom ezt, Coplient szoktam idezgetni ( The Agile Heart: An Interview with James Coplien - google cache (az eredeti 404) ), de nyilvan Uncle Bob se veletlenul indult el kulon utakon, bar o a masik iranyba indult el.
A sajat csapatom XP-t hasznalt anno. Lattam hogy mukodnek scrum coaching csapatok. Egyik elso ember voltam aki Lean-t vezetett be, mert epp az stimmelt.
Es orultem koveteltem, hogy egy hires scrum ceg surgosen alljon at RUP-ra, mert nem lehet kibirni, hogy nincsenek felelosok, hogy semmilyen formalitas nincs egy 20 000 fejlesztot foglalkoztato cegnel, hogy nincsenek hivatalos dokumentaciok, hanem szo szerint haveri kapcsolatokat kell kiepitenem szingapuri emberekkel, hogy a szingapurban fejlesztett projektben egy 3 soros patchet be tudjak varazsolni, mert ugye human interaction over processes and tools.
Utaltam hogy nincsenek meeting note-ok, nincsenek action-ok, senkin nincs szamonkerve soha semmi, hanem udvariasan vigyorgunk.
Es hiaba mondanad, "you're not doing agile right!", fullra scrum-kompatibilis a ceg! Egy szavad nem lehet ra, milliok mennek el trenerekre, 2-3 csapatonkent kulon scrum master aki tevedesbol se fejleszt vagy menedzsel. Ismert ceg, itt a HUP-on is volt rola szo, es az InfoQ-n is irtak (masok!) hogy a ceg latvanyos es komplett bukasat az okozta, hogy komolyan vettek a Scrum-ot. Es tudod mit? Ott voltam, siman igaz.
Ettol meg a lightweight methodok lehetnek jok. Nyilvan egy csomo ceg bukasat anno a RUP komolyanvetele okozta, azelott meg a Waterfalle.
De ettol meg az, hogy a scrum-ot nem szabad szo szerint venni, ez all. Ettol meg szerintem enterprise meretekben - ahol az innovacio es fejlesztes jelentos resze zajlik mai napig - nem mindent kell lightweight methodokra tenni.
Nagyon kerlek, ne hivd prekoncepcionak. 6 eve vezetek lightweight metodologiakkal teameket, es ezek kozul 9 honapot toltottem ennel a durvan scrum cegnel, kileptem, de gyakorlatilag beleoszultem. Elolvastam, ott voltam, csinaltam. Ez nem prekoncepcio, hanem a Scrum veszelyes es artalmas. Nekem szo szerint az volt.
- A hozzászóláshoz be kell jelentkezni
"Ez nem prekoncepcio, hanem a Scrum veszelyes es artalmas. Nekem szo szerint az volt."
Amivel Te találkoztál és veszélyes volt, az nem a Scrum volt, hanem a józan ész hiánya ("nincsenek meeting note-ok, nincsenek action-ok, senkin nincs szamonkerve soha semmi"), az agilis megnemértése illetve a szingapúri mentalitás (nem, ők nem nyugati módon dolgoznak, érdemes elolvasni Lee Kuan Yew könyveit, hogy megértsd egy kicsit őket). A Scrum nem mondja azt, hogy menj szembe a józan ésszel és hagyd ki ezeket, és aki ilyen módon állítja be a scrumot, az vagy nem a Scrumról beszél, vagy nem érti meg már az alapjait sem. Ha valakitől érdemes eltanulni a scrumot, akkor az Jeff Sutherland, érdemes rákeresni a Youtube videóira.
Abban teljesen igazad van, hogy egy csapat jó működését nem a scrum vagy más módszertan határozza meg, hanem az emberi alapanyag, az egyes módszertanok maximum keretet adnak annak, hogy mire fókuszáljon a csapat együttműködése. De ha Te is ezt hiszed, akkor miért gondolod egy egész nagy szervezet pusztán a scrum miatt bukott el, és nem az emberi alapanyag miatt? :) El bírom képzelni, ahogy a szervezet menedzsmentje ímmel-ámmal felsorakozott a scrum zászlóhordozó mögött, anélkül hogy megértenék (oh, láttam már ilyent több helyen is), majd úgy alakítják a dolgokat, hogy mindenféle sikertelenségért a módszertant lehet okolni, és nem az embereket, nem a szervezetet, de különösne nem a menedzsmentet. Vannak helyzetek, amikor a scrum vagy bármilyen módszertan sokat tud hozzáadni a csapathoz, és van amikor keveset. De olyant még nem látttam, hogy káros lett volna. Maximum a Te esetedben az a side-effektje, hogy a bevezetéssel egyidőben abbahagyták a többi jó gyakorlatot is, de azért ez nem a scrum oka...
--
munka | szótár | blog | fotó
- A hozzászóláshoz be kell jelentkezni
Oh, felre ne erts, nem csak Szingapurban nem volt Meeting Note, Nemetorszagban, Angliaban, Finnorszagban es Amerikaban se.
Ismet elmondom, hogy ez nem attol fugg, hogy "megerted-e" az Agile-t. Neves agilis trenerek es trenercegek mondtak meg hogy egyaltalan kit vegyenek fel. Fullra ertettek az Agile-t, sehol nem tudtal belekotni, hogy ez nem ugy van ahogy a nagykonyvben meg van irva.
Nekem az jott ki a kepletbol emiatt, hogy a nagy konyv nem passzol.
Jo, teny, egy dolgot nem szeretnek csinalni, embereket kirugdosni, es ez a csapatfelelosseggel egyutt eleg veszelyes.
De nezd, en megtettem azt a faradtsagot, hogy megprobaltam megerteni a szitut, kinyitottam az anyagokat, elolvastam az Agile Manifesto-t, elolvastam a Scrum guideline-t, beszeltem trenerekkel, scrum masterekkel, coachokkal, hogy mi hogy merre mennyi, es az jott le, hogy objektiven nezve nem skalazodik a dolog, teli van olyan dolgokkal, pl. hogy emberi interakciok processzek helyett, amik nagyvallalati kornyezetben nem jok. Nagyvallalati kornyezetben raadasul nagyon gyakran fontosabb lenne egy doksi mint hogy a kodon dolgozzanak.
Tobb mint evtizedes fejlesztoi tapasztalattal, aminek nagyjabol felet szakmai vezetokent (teamlead, project manager de vidve muszakit is, technical architect, ezek voltak a titulusaim eleddig) eltem le, nagyvallalatnal is, mikozben oktattam, inas-kepzest csinaltam, es akkor ez meg csak a profi vilag volt, ezek a munkahelyeim, azt kell mondjam, hogy nagyvallalati szinten az Agile, szo szerint veve nem mukodik.
Persze ha belelatjuk azt ami epp nekunk mukodik az mukodhet, de by the book, az Agile nem jo.
Felre ne erts,a masik irany se jobb, Craftmanship movement, tok jo hogy Bob bacsi megirta a Clean Code-ot, de lattad mar a FitNesse kodjat? Neztem... 6 eves projekt.. inline ez, inline az... ez effektiv maintenalhetetlen, ebben bizonyos refactorokat az eletbe nem lehet majd vegrehajtani (pl. kezdesnek egy oldalt nem tudsz atnevezni, mert sztringkonstanskent hivatkoznak forraskod kozepen a tobbiek ra).
- A hozzászóláshoz be kell jelentkezni
"teli van olyan dolgokkal, pl. hogy emberi interakciok processzek helyett, amik nagyvallalati kornyezetben nem jok."
Nézd, ahol a szoftverfejlesztés bonyolultsága nem haladja meg azt a komplexitást, amit egy szalagmunkás robot csinál, és ütemesen ugyanazt csinálja, ott egyetértek ezzel a kijelentéssel. Ahol viszont gondolkodni kell, ott az emberi interakcióknak lényegesen több szerepe van, mint bármilyen processnek. A módszertan is maximum azért kell, hogy legyen egy rendszeres kerete annak, hogy azok az emberek, akik elkerülnék ezt az interakciót, azok is belemenjenek. És pont a nagyvállalati környezet az, ahol a seggvédésért a processzek mögé bújnak az emberek, amikor minden lehetőséget megragadnak a felelősség-elhárításra... és újra hangsúlyozom: ez az a pont, ahol a scrum segít - amennyiben van, aki tud felelősségre vonni. Ha ilyen nincs, akkor persze mondhatod, hogy a scrum miatt összedőlt a szervezet, én továbbra is csak ellentmondok neked, mert rossz az ok-okozat következtetésed...
"Tobb mint evtizedes fejlesztoi tapasztalattal, [...] azt kell mondjam, hogy nagyvallalati szinten az Agile, szo szerint veve nem mukodik.
Erős kijelentés ez, hidd el. Én is tudok titulusokat mondani, és a mondat vége az, hogy működik. Az én világom a rossz? Vagy a világ szürke?
Amúgy mindig belekevered a szoftverfejlesztés részét (refactoring meg forráskód). Észrevetted, hogy én úgy hivatkozok a scrumra, hogy nem is érintem ezeket? Független tőle...
- A hozzászóláshoz be kell jelentkezni
Tudom hogy ki vagy Pisti, te is tudod en ki vagyok, en sajnalom a legjobban hogy nem irhatom ki a Fortune 500-as cegeket az oneletrajzomban mert baszottnagy NDA vonatkozik az outsourcingra sajnos, te kiirhatod a GE-t meg a Sun-t meg az MSCI-t, mert neked meg olyan szerzodeseid voltak.
Szo szerint veve, ha nincs arra processz, hogy hogy a francba kerjem el a forraskodot a masik reszlegtol (es a gugelnel van azert), ha nincs arra processz, hogy hogyan lehet API-t nyitni a teamek kozt, akkor kaosz van.
API keres az ugy zajlik, hogy tudod, hogy hol van a vegpont, ekkor elkezdesz leveleket kuldozgetni a nemet leanyvallalaton belul, hogy nem tudja-e valaki, ezert ki a felelos, majd az egyik fejleszto visszair, hogy o ezzel a masik fejlesztovel van kapcsolatban Szingapurban, es hogy ot kerdezzem meg esetleg. Ha kell valami modositas (nem perszonal, konkretan egy bug miatt a szabvany bizonyos resze nem teljesult), meg ugy is hogy kuldod a patch file-t, a programozo at fog teged iranyitani egy masik emberhez aki atiranyit a tenyleges programozohoz.
A ceg uj jelszava az accountability, fel evet vartam hogy legyen valami, nem lett. Az osszes Scrum trainer (ThoughtWorks-osok) allitottak, hogy de nem is lenne jo, team responsibility-nek kell lenni, majd amikor feldobtam, hogy oke, akkor vagjatok ki a teamet, en nem fogok sirni ertuk (pedig a szomszed iroda), akkor nyilvan mindenki nezett.
Egyszeruen 1000-1500 fos emberi tarsadalmakban kell dolgokat rogziteni. A Schonherzbe is rogzitettunk ilyeneket, a faluban is megvan, hogy kinek mit kell bejelentened,minek mi a modja, meg ha flexibilisek is vagyunk, mashogy nem megy, ez a process.
Bezzeg amikor arrol volt szo, hogy nekunk van egy menedzsmenttalalkozonk, demo lesz rajt,es kesz van felig az integraciojuk, akkor rogton volt processz (A Scrum), hogy a Scrum kifejezetten eloirja, hogy csak demo day-en lehet bemutatni barmit is,elobb egy nappal sem, a mi menedzsereinket is szivesen varjak az o demojukra.
Mondanad azt, nem kertem eleg szepen, ugyhogy mondok jobbat: ha bug volt a release-ben, amitol nem omlott ossze a site csak a fo use case-ek egy reszet nem lehetett vegrehajtani (tehat technikailag mukodott, csak semmire nem lehetett hasznalni) a felhasznalok 3 hetet varhattak a hibajavitassal, nem azert, mert bonyolult, nem, mar masnap benn volt a fix repoban, hanem azert, mert az a scrum vege.
Es ezutan az a vezetofejleszto, aki ezt igy lenyomta a torkodon (na nem mint team-tag, hanem mint a partner team leadje), a fejlesztoi team teljes tamogatasaval (mert mi _tiszta_ scrumot csinalunk, nem ugy mint mas cegeknel ahol _emiatt_ van a baj), elmegy, es eloadast tart Agile konferencian, hogy hogy kell jol agile-ozni. Es megtapsoljak. Mondtam, en nem fizetek ki 400-900 EUR-t csak azert hogy odamenjek es megverjem...
Es azert nem, mert hiaba vernem meg ott helyben, mindenki azt mondana ram, mint amit te is mondasz, hogy en ertettem felre valamit, pedig nem.
- A hozzászóláshoz be kell jelentkezni
Most megjelent előttem ennek a szervezetnek a belső politikai egymásra-taposása, machinációja és felelősség-tolása. Hidd el, a sikertelenségnek nem a scrum, hanem ez az elsődleges oka. A scrum nem a sikert/sikertelenséget, hanem a fókuszt segíti elő. Az meg hogy csodálkozol azon, hogy valaki A-t csinál és B-t mond, azt mutatja, hogy egyelőre kivontad magad ezekből a politikai dagonyákból, a lelki békéd szempontjából valszeg helyesen, csak éppen így könnyebb elhinned, hogy a scrum a főgonosz :)
A Google amúgy a legjobb példa arra, hogy a nem-teljesen, de azért mégiscsak agilis szervezet hogyan és miért tud remekül működni még ezzel a 30000+ alkalmazottal is. Majd egyszer írok erről hosszabban...
- A hozzászóláshoz be kell jelentkezni
Ez az egymasra tapososdi ez gyanusan a scrum-mal egyidos, 2007-ben lett bevezetve a scrum, es a reszvenyek fel evvel kesobb esni, majd elobb-utobb zuhanni kezdtek, ma mar tizedet se eri. Tenyleg semmi hibat nem lehetett talalni a viselkedesukben a "szabalykonyv"-ek alapjan, szarraolvastam az irodalmat hogy azt mondhassam, hulyek vagytok, itt nem is ez van leirva.. De ahogy a radiokabareban mondtak, a torveny az torveny...
Hat aze' vitatkoznek hogy a Google mostanaban termekszinten jol mukodik.
UX dizajnban is benne vagyok, es szerintem ami tortent itt a redesign-nal kapcsolatban azt leginkabb az "amokfutas" szoval lehet illetni, evszazados szabalyokat tortek meg, anelkul hogy az okok amik miatt a szabalyok leteznek eltuntek volna. Ilyet mar lattam, nalunk is eresztettek szabadjara nehany UX dizajnert, akik nagyon elo tudtak adni, hogy ez amolyan magikus tudomany amit foldi halando nem erthet, na, nem voltam kedvelt amikor elkezdtem megmutatni hogy a kiraly meztelen.
- A hozzászóláshoz be kell jelentkezni
Hat aze' vitatkoznek hogy a Google mostanaban termekszinten jol mukodik.
Amire utaltam az az, hogy belülről látom, hogy szervezetileg hogyan működik és azt jó "közel agilis" példának tartom. Az hogy egy adott termék Neked mennyire tetszik (pl. az új design), azt tartsuk kívül ezen a beszélgetésen.
--
munka | szótár | blog | fotó
- A hozzászóláshoz be kell jelentkezni
Jo, csak egy szervezetet az outputja alapjan ertekelsz elso korben.
Lassulo release cycle, elszabadulo fura dolgok, en ezt latom kivulrol.
Tudod, a code review mertekegysege wtf/minute, kivulrol egy cegrol a wtf/blogpost latszik kb.
Ettol meg lehet egyre jobban agilis, a kerdesem az, hogy ez a usernek is jobb-e.
- A hozzászóláshoz be kell jelentkezni
Kezd alakulni, most már nem a részvényárfolyamon, hanem az outputon méred a cég működését. Még ott kell néhányat előrelépned, hogy:
- nem csak egy-egy kiragadott usert mérsz, hanem a teljes/potenciális user-bázist (including közvetlen és közvetett üzleti értékeket),
- elkezded mérlegelni az output hasznosságát a befektetett munka arányában (including fejlesztési, üzemeltetési és szupport költségeket),
- előreveszed azokat a dolgokat, amik nagyobb hasznosságot hoznak kisebb befektetés alapján
... és rájössz, hogy ezeket már kitalálták, és példuál úgy is hívják, hogy scrum :)
Nem kell már sok :)
- A hozzászóláshoz be kell jelentkezni
"elkezded mérlegelni az output hasznosságát a befektetett munka arányában"
Kivulrol ezt nehez megitelni, marad az output...
Egyebkent szerintem kivetel nelkul mindegyik modszertannal az elso amit meg kell nezni, hogy mi az, ami felesleges, karos, mit kell kidobni belole. Nincs olyan ceg, ahol X modszertan valtoztatas nelkul mukodik, az csak az Idealis Eset ZRt falai kozott mukodik, masutt sehol. En peldaul nem szeretem, ha a nyakamon ulnek, hogy mit hogyan mikor csinalok, tehat az ezt kovetelo rendszerekben en nem leszek partner. Nekem kell egy ticket rendszer, ahol le tudom kovetni a munkam elorehaladasat es megiteleset, tehat olyan rendszerekben se vagyok partner, ahol ezek hianyoznak.
Nincs jo modszertan, se a SCRUM, se a XP, se semelyik modszertan nem jo. Vannak benne reszek, amik alkalmazhatoak es vannak reszek, amelyek nem. Mindig meg kell vizsgalni, hogy mi az, amit be lehet epiteni egy projektbe, es mi az amit nem. Szerintem ez a modszertanok lenyege.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
"Vannak benne reszek, amik alkalmazhatoak es vannak reszek, amelyek nem. Mindig meg kell vizsgalni, hogy mi az, amit be lehet epiteni egy projektbe, es mi az amit nem. Szerintem ez a modszertanok lenyege."
Ertsd: az egesz egy hatalmas ures locsogas a nagy semmirol, amit jol peldaztatok :)
--
cythoon
- A hozzászóláshoz be kell jelentkezni
A google-nel eleg egyszeru lenne merni az adatokat, ha a ceg latogatottsagi adatai nyilvanosak lennenek, mert weblapok... bar az androiddal mar ez se igaz, ott ra kell hagyatkozni a morzsakra.
A user bazisnal a Stockholm-szindroma jellegu dolgokat bele kell venni. Pontosan emiatt hivatkoztam a reszvenyarfolyamokra, mert bar a termekeket meg vettek, a reszvenyeken kezdodott erezni hogy lehet ez megse olyan jo. Hiaba ruhellem a valtozasokat pl. a google keresoindexeiben, sajnos nincs kapacitasom arra, hogy magamnak epitsek egy keresoindexet. Gmailrol mondjuk havonta megprobalok meggyozni valakit hogy fektessen be penzt es csinalunk egy jobbat:)
A befektetett munka aranyat hagyjuk ki. Az egyik hivatkozasi alap volt, hogy "mindenki a tole telheto legjobbat hozza ki magabol ennel a cegnel", valaszom az volt: "leszarom, akkor a toluk telheto legjobb a usernek nem eleg." Az olimpian a negyedik helyezett futo is a leheto legjobbat hozza ki magabol, az adottsagaihoz kepest. Senki nem fog emlekezni ra.
Innentol kezdve arrol beszelunk, hogy van egy problemacsoport (kereses, e-mail, online video, mittom), es minden arrol szol, hogy hogyan feszited ki a leheto legtokeletesebben a problemacsoport osszes elemet.
Hajlamos vagy lelkesedni dolgokert, lelkesedtel te mar a J2EE-ert es a GWT-ert is. Ez is elmulik majd :)
- A hozzászóláshoz be kell jelentkezni
Le vagyok nyűgözve. Már kb. 6+ éve nem találkoztunk személyesen, soha nem dolgoztunk együtt, de Te annyira ismerni vélsz, hogy azt is megmodnod, mit fogok holnap csinálni. Hihetetlen :)
--
munka | szótár | blog | fotó
- A hozzászóláshoz be kell jelentkezni
Azt nem mondtam, hogy holnap, csak en szeretem a pattern language gondolkodasmodot.
Marpedig ha a rendszer nem stimmel, akkor nem fog stimmelni a problema-megoldas parositasa sem, es ez latszik is.
Eddig meg amiert tomegek lelkesedtek es megmondtam, hogy be fog bukni, mind bebukott elobb-utobb. A J2EE is ilyen volt, a GWT is ilyen volt. Elmulik majd a git is talan.
- A hozzászóláshoz be kell jelentkezni
/o\
- A hozzászóláshoz be kell jelentkezni
rotfl :)
- A hozzászóláshoz be kell jelentkezni
No offence, de ego az szorult beled rendesen hallod :)
- A hozzászóláshoz be kell jelentkezni
Várjál, nem te voltál AZ arkitekt azzal a hihetetlen nagy arccal?
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
"Ez az egymasra tapososdi ez gyanusan a scrum-mal egyidos, 2007-ben lett bevezetve a scrum, es a reszvenyek fel evvel kesobb esni, majd elobb-utobb zuhanni kezdtek, ma mar tizedet se eri."
Azért 2008-ban beütött egy gazdasági válság; nem lehet, hogy annak több köze volt a részvények árfolyamának zuhanásához, mint a scrum-nak?
- A hozzászóláshoz be kell jelentkezni
Es szerinted a gazdasagi valsagot mi okozta? :D
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
"Fullra ertettek az Agile-t"
Az nem elég, azt meg is kell tudni valósítani. Ehhez pl. a szakmájukhoz is kell érteni.
A csapatfelelősség önmagában nem gond. Nálunk a csapatokban lehet tudni, hogy kik dolgoznak jól és gyengén, ami a fizetésemelésekben vagy szélsőséges esetben akár kirúgásokban látszódik is.
- A hozzászóláshoz be kell jelentkezni
+1
Még annyit tennék hozzá, hogy az "Individuals and interactions over processes and tools" nem azt jelenti, hogy az eszközöket és processzeket eldobjuk (pl. Bugzilla helyett sör melletti beszélgetés lesz), hanem azt, hogy az eszközök és processzek vannak az emberekért és nem fordítva. Magyarán minden processzt és toolt addig szabad csak használni, ameddig hasznos.
Az egyik CSM tréningen, amin voltam, a Waterfall kapcsán azt mondták, hogy nagyon jó módszertan, ha működik, akkor véletlenül se válts Scrumra. Így is van, a Scrum nem vallás, vannak elismert hátulütői és ebből fakadóan ezernyi variációja. De amiket Aadaam írt, azok nem a Scrum vagy az Agile hibái, hanem emberi baromságok.
- A hozzászóláshoz be kell jelentkezni
Kezd ez az egesz agile olyan lenni mint a vallas: mindenki azt lat bele amit csak akar mikozben a masikat szidja hogy miert nem erti, jo sokan elnek meg belole, a jozan emberek pedig az egeszet ugy ahogy van elkerulik :)
--
cythoon
- A hozzászóláshoz be kell jelentkezni
ahahaaaa
- A hozzászóláshoz be kell jelentkezni
Ja, tudod, protestans nevelest kaptam, nem a vallassal van bajom hanem a katekizmakkal, hogy ezt marpedig mindenkinek igy kell csinalnia, mert ez a szent ut.
- A hozzászóláshoz be kell jelentkezni
Idézek önmagamtól fentről, mert láthatóan elsiklottál felette:
"ha működik, akkor véletlenül se válts Scrumra"
"Scrum nem vallás, vannak elismert hátulütői és ebből fakadóan ezernyi variációja."
Tehát nincsen erőszakos térítés, kőbe vésett tételek és a katolicizmus tanításával ellentétben itt nem csak A Cégen keresztül juthatsz el az üdvösséghez. Ha az Agile principles a 10 parancsolat, akkor a Scrum a kereszténység az összes, egymásnak gyakran ellentmondó és gyökeresen eltérő ága. Ami mégis összeköti őket az jelen esetben nem Jézus és a megváltás, hanem a Product Owner és a backlogok. Az, hogy ezek a Jóistent, avagy a felhasználót háttérbe szorítják-e vagy sem, az egyéni hülyeség kérdése.
Bocsi a botcsinálta párhuzamért, de nem én kezdtem. Remélem nem sért senkit.
- A hozzászóláshoz be kell jelentkezni
És ha már a hasonlat, az sem eretnekség, hogy valaki backlog nélkül csinálja a scrumot. Uhh, lehet mégis, máglyára vele! :)
--
munka | szótár | blog | fotó
- A hozzászóláshoz be kell jelentkezni
"Nezd meg a SCRUM guideline-t, tegyel egy CSM vizsgat, szo nem lesz userrol, meg user problemakrol."
Bennem nem ez maradt meg a CSM vizsgám kapcsán. Mindenesetre elég gyakori, hogy az emberek megfeledkeznek róla, hogy a Scrum az egy Agile metodika. Így aztán ész nélkül nyomják a Scrum-ot úgy, hogy az alapvető Agile célokat és értékeket teljes elfelejtik.
Mindenesetre az Agile Manifesto és Principles minden pontja pont a felhasználóról, a fejlesztőről és az emberi tulajdonságaikról szól.
Pl.: "Our highest priority is to satisfy the customer". Tehát ha a customer nincs a Scrum fókuszában, akkor az nem Scrum.
- A hozzászóláshoz be kell jelentkezni
Lehet, hogy reg volt angol, vagy csak eletedben nem lattal meg szoftverfejlesztest, vagy valami nagyon speci kozegben dolgoztal, de az esetek 99.9999%-aban a customer nem kepviseli kozvetlen a user erdekeket, es orulni kell ha egyaltalan nem nagyon ellentetes vele.
- A hozzászóláshoz be kell jelentkezni
Igen, ez az amit én is írni szerettem volna, csak nem akartam túl hosszúra nyújtani. A customer és a user valóban nem mindig ugyanaz. Mivel az Agile alapvetően a hosszútávú, sikeres partneri viszonyra van kihegyezve, nem a letudjuk valahogy aztán viszlát filozófiára, a fejlesztés bármelyik tagja, maga a user, aki iterációnként megkap valamit, a Product Owner vagy egy mezei fejlesztő is szólhat, hogy szerinte nem jó irányba mennek a dolgok. Mivel az Agile világban nincs kommunikációs hierarchia, hanem a user és a fejlesztő vagy közvetlenül vagy majdnem közvetlenül érintkezik, így ez simán megvalósítható. Ha nem, akkor nem Agile-ról beszélünk.
- A hozzászóláshoz be kell jelentkezni
oke, es akkor most nezd meg a scrum guideline-t, amiben az van, hogy legyen egy db. product owner, aki kepvisel mindenkit [a gyakorlatban mindenkit aki nem fejleszto].............
Egy teljesen jo kooperaciot kovetel az Agile - a menedzserreteg (Customer) es a fejlesztok kozott. Az, hogy vannak userek is, arrol egy sor nincs sehol, a Scrum pedig egyenesen kizarja oket.
- A hozzászóláshoz be kell jelentkezni
"nezd meg a scrum guideline-t, amiben az van, hogy legyen egy db. product owner, aki kepvisel mindenkit"
Ezzel max. azt bizonyítjuk, hogy a Scrum nem feltétlenül Agile eszköz.
"Az, hogy vannak userek is, arrol egy sor nincs sehol"
Principles: "Working software is the primary measure of progress." A szoftver meg csak úgy működhet, ha a user használja. Tehát implicit ott van a user.
- A hozzászóláshoz be kell jelentkezni
Miert? Lattal mar cron jobot? Hol van ott a user?
Nagyon sok ismertebb figura van (pl. Coplien), aki nem irta ala az Agile Manifestot, mert nem foglalkozik a userrel. A working az nagyon szabadon ertelmezheto, nehany koder ezt ugy ertelmezi hogy lefordul, a jobbak mondjuk ugy, hogy bugmentes a (menedzserekkel ledumalt) specifikaciora nezve, de user, az nem kell hozza.
- A hozzászóláshoz be kell jelentkezni
"Lattal mar cron jobot? Hol van ott a user?"
Pontosan ez az, amiért "working software" a megfogalmazás. Az esetek jelentős részében ez usernél működőt jelent, de lehet pl. cron job is.
"A working az nagyon szabadon ertelmezheto, nehany koder ezt ugy ertelmezi hogy lefordul"
Vannak hülye emberek, de ez most hogy jön ide? Az Agile nem egy matematikai precizitással megfogalmazott valami, de attól még nem kell szándékosan félreértelmezni.
- A hozzászóláshoz be kell jelentkezni
"Vagy ez vagy pedig a fájloknak csak egy részét/részletét commitolod és reménykedsz, hogy önmagában is fordul a felcommitált rész, mert te külön nem fordítottad. Gányolás mindkettő. Nem hiszem, hogy lenne jó megoldás, függetlenül attól, hogy git vagy svn."
Git-et használva kétféleképpen lehet kezelni az ilyen eseteket:
- Miután az indexhez hozzáadtad a következő commitba szánt változtatásokat, lehetőséged van arra, hogy elrejtsd a working treeből az összes olyan változtatást, ami nem lesz része a következő commitnak (git stash --keep-index), így lefordíthatod és tesztelheted azt az állapotot, ami majd a következő commit lesz.
- Amíg egy commit csak a lokális repository-dban létezik, addig nincs kőbe vésve, és egyszerűen módosítható. Tehát a refaktorizálás + új funkció példádban megteheted, hogy teszteletlenül commitolod a refaktorizálást, majd miután az új funkciót is commitoltad, akkor utólag leellenőrzöd a refaktorizáló commitot, és ha gáz van, akkor kijavítod. Amikor már kész vagy, és mindkettő fordul és átmegy a teszteken, akkor push-olod a nyilvános/központi repository-ba.
"Tehát svn-ben a refactoringot vagy az új funkcióval együtt teszi fel az ember, ami nem túl szép, viszont garantáltan fordul, vagy ha más fájlokban van a refactoring, akkor sikerülhet külön is. Szerintem nem vészesen nagy a különbség, feltéve, ha az ember értelmes logot ír hozzá."
Például ha később egy bug levadászása során a bisect pont ezt a commitot hozza ki bűnösnek, akkor kérdéses, hogy a refaktorizálás okozta-e a hibát vagy az új funkció nem kívánt mellékhatása. Ez nyilván hátrány, bár arról lehetne vitatkozni, hogy "vészesen nagy" e. Én nem fogok, de örülök, hogy olyan eszközt használhatok, amivel mindez már nem probléma.
- A hozzászóláshoz be kell jelentkezni
Latod, itt kulonbozik az allaspont. Sajnalatos, hogy egyesek azon vergodnek hogy a _tool_ mit tud ahelyett hogy _mire van szukseg_.
Amit leirsz ket pelda, az tokeletes indok arra, miert _kell_ ket kulon agon tartani a fuggetlen modositasokat. _Erre_ van szukseged. Ezutan jon csak az, hogy nah akkor legyen egy olyan tool, ami ezt gyorssa es kenyelmesse teszi. Mint az irasodbol kitunik, a git sem az, pontosabban semmivel nem tobb, mint a tobbi tool.
--
cythoon
- A hozzászóláshoz be kell jelentkezni
Ha valaki nem hasznalja a gyakorlatban permanensen, annak valoban se nem gyors, se nem konnyu. gitnel meg a commit se egy modosithatatlan valami, a git commit --amend paranccsal barmit hozzafuzhetsz az elozo commithoz, amit kifelejtettel. Ezzel vegre el lehet kerulni a "missing source" cimu commitokat, pl.
Egyebkent pedig a git-nel a commitot es a push-t kulon kell kezelni. Az a gond, hogy az svn szemleleteben a ketto egy, tehat ha egyszer commitolsz, az egyreszt publikus, masreszt vegleges, egyiken se lehet valtoztatni. Git-nel az svn commit-nak nagyjabol a push felel meg, ez az, ami vegleges, es nem lehet rajta valtoztatni, csak egy masik push-sal. A commit azonban kulon eletet el, amig fel nem pusholjak, addig akarmit is lehet vele csinalni, meg visszavonni is lehet, ha az ember azt latja jonak.
A brancheles megint egy kulon dolog, amit megint a maga lenyegeben kell latni. Mig az svn szemleleteben a branch az majdnem egy kulon repo, addig a gitnel a branch nem mas, mint commitok egy halmaza. Hogy nalam hany branch van a lokalis gepemen, az a vilagon senkit nem erdekel. A kozponti repoban levo branchek az erdekesek, mert az publikus, azokat intaktnak kell hagyni amig nincs olyan commitod, ami megegyezes szerint belemehet (ez akar a projvez engedelyet is jelentheti, ezert tud a git alapbol patch mailokat irogatni). Ugyanakkor a git-nel a branch merge az opcionalisan hozza magaval a history-t is, tehat a logban nem csak az latszik, hogy mergeltuk az X fat, hanem az is, hogy az X faban mi tortent. Persze, van squash merge is, ami csak a merge commitot dobja be, illetve rebase is, ami csak a history-t jelzes nelkul, de ezeket normalis projvez kezlevagassal dijazza.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Pedig a rebase-sel nincs gond, csak mindenképpen kell merge commit (--no-ff), és így nem futnak külön szálak egymás mellett feleslegesen. Vagy más helyeken azért jár kézlevágás, mert a patch-ed nem a branch legutolsó publikus commitjához készült.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
Nyilvan en erre gondoltam, hogy nem csak rebaselunk orrba-szajba, hanem kell egy merge commit is, hogy megis mi a fene tortent itten.
Egyebkent nekem a merge --no-ff -re mar van aliasom, igy en mindig igy mergelek.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Latod, itt kulonbozik az allaspont. Sajnalatos, hogy egyesek azon vergodnek hogy a _tool_ mit tud ahelyett hogy _mire van szukseg_.
Attol hogy valamire nincs szukseged, meg nem jelenti azt hogy masnak se lehet. Nyilvan azert ervelnek git bizonyos funkcioi mellett, mert hasznaljak es jo nekik.
Mint az irasodbol kitunik, a git sem az, pontosabban semmivel nem tobb, mint a tobbi tool.
Konkretan mik azok az eszkozok amik ugy, vagy jobban tudjak gitnel a fent leirtakat?
- A hozzászóláshoz be kell jelentkezni
Azzal egyetértek, hogy a független módosításokat célszerű külön ágakon tartani.
Csak sajnos a gyakorlatban a módosítások igen gyakran függenek egymástól, mitöbb, egyenesen egymásra épülnek, és ilyen esetekben arra van szükségem, amit a git kínál. Ugyanis az eddigi tapasztalataim alapján az ilyen helyzeteket a gittel lehet a legegyszerűbben és leggyorsabban kezelni, ezért sokkal többet nyújt, mint a többi tool.
- A hozzászóláshoz be kell jelentkezni
Ennek kb. minden szava igaz.
- A hozzászóláshoz be kell jelentkezni
Alapszintu git hasznalathoz a kovetkezot kell tudni:
git clone; git commit -a; git push.
Ennyi. Ha ezzel valakinel problemaja van, akkor el kell gondolkodni rajta, hogy esetleg megvalnatok tole.
Kicsit praktikusabb hasznalathoz mar nem art egy git log, git branch, git checkout es git merge meg cherry-pick ismeret sem, de azok sem bonyolultak.
Ha teljesen mindent tudni akar az ember a gitrol, az tenyleg nagyon sok ido. De erre nagyon keves esetben van szukseg, altalaban az alapokra eleg ~2 ora.
Raadasul a git man oldalain egesz korrektul le van irva minden, de ha az sem eleg, tele van a net cheatsheetekkel, meg mindenfele howtoval es egyeb okossaggal. Tobbre link is van a git weboldalarol.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Illetve en csak dicserni tudom a freenode.net #git csatornajat. Jopofa kozosseg, elmondtam, mi a nyugom, rogton ket ember jott segiteni, par perc alatt rendberaktuk a repot.
En alapszinten amugy szinten irc-n tanultam meg valakitol a gitet, legalabbis a branches reszt, utana mar eleg egyszeru volt az eletem.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Előző és mostani munkahelyemen is SVN-t használunk, kisebb problémákkal (mergeléskor sikerült összekutyulni néha ezt-azt), de alapvetően megelégedéssel.
Viszont: a semmit se használ az meg WTF?!
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
Sajnos tudok olyan helyet, ahol a verziókezelés az, hogy megosztásról megnyitják a fájlt, módosítják, majd visszamentik. Ha nem lett jó és már túl sokat módosítottak rajta, akkor szólnak a rendszergazdának és megkérik, hogy állítsa vissza a fájl xy nappal korábbi változatát _backup_-ból.
És ez nem vicc.
--
trey @ gépház
- A hozzászóláshoz be kell jelentkezni
Követendő magatartás.:)
A rendszergazdának biztos állás.
A második backup után lehet a fejlesztőket cserélni.
- A hozzászóláshoz be kell jelentkezni
Az ilyen menjen csődbe, de nagyon gyorsan.
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
"És ez nem vicc."
Deee ez vicc!
----
올드보이
http://molnaristvan.eu/
- A hozzászóláshoz be kell jelentkezni
Ez a felállás nagyon könnyen migrálható git-re. Rendszergazda telepítse fel a bup nevű git alapú backup rendszert :)
- A hozzászóláshoz be kell jelentkezni
Azt azért tettem bele a szavazásba, hogy mindenki tudjon szavazni, aki akar. :-)
Az a része számunkra érdektelen.
- A hozzászóláshoz be kell jelentkezni
En is lattam olyan allami megrendelesekre dolgozo hw+sw ceget (iranyitastechnikai, ipari berendezesek), ahol e-mailben dobaljak a forraskodot, ma, Magyarorszagon.
- A hozzászóláshoz be kell jelentkezni
Szemelyesen ismerek olyan fejlesztot, akinek a verziokezelot az xcopy parancs testesiti meg.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Mondjuk ha jobban belegondolok... Valahol még mindig jobb, mint amikor az éles weboldal egyetlen példánya egy "test" nevű könyvtárból fut...
----------------
Lvl86 Troll
- A hozzászóláshoz be kell jelentkezni
"SVN-t használunk, kisebb problémákkal (mergeléskor sikerült összekutyulni néha ezt-azt)"
Ez nem kicsi probléma, hanem irtózatos baj, ha egyáltalán ilyesmi előfordulhat. Ezért kell az svn-ben még első használat előtt helyrerakni a diff3-cmd beállítást. KDiff3 pont megteszi erre a célra.
- A hozzászóláshoz be kell jelentkezni
En csak kuzdok a git bevezeteseert, sajnos nalunk a clearcase van musoron.
- A hozzászóláshoz be kell jelentkezni
Remelem elbuksz, en pont CC-t sirom vissza git utan ;)
--
cythoon
- A hozzászóláshoz be kell jelentkezni
Mi a probléma a gittel?
- A hozzászóláshoz be kell jelentkezni
Sajnos nem vezettem rola naplot (bar terveztem :), de ilyenek jutnak eszembe:
- Mar tobb embernel szallt szanaszet a local repo. Nyilvan nem napi szinten, de ilyen szetesesek nem voltak CC alatt soha.
- Nekem a staging es kommit kifejezetten idgesito, mert a semmiert kell 2x commitolni.
- En szerencsetlen Eclipse alol akarom hasznalni ahol van EGit plugin hozza, ez viszont kellemetlenul szar:
- Historyt nem mindig tudja abrazolni grafban (ismert limitacio).
- A 3utas merge az nem letezik EGit alatt, helyette kapsz egy olyat hogy conflict utan megnezheted mi a diff a ket >>>>>> jelekkel telehanyt fajl kozott, ami lenyegeben teljesen hasznalhatatlan.
- A commit textboxot siman kitorli az EGit plugin csak ugy magatol, amikor frissiti a git repot, igy egy staging utan mindig meg kell varnom amig befejezi az egyebkent hattermunkat, majd utana irom a commit uzenenetet, kulonben siman a kellos kozepen kitorli.
- Bar van 3utas merge, szokott olyanra conflictot jelezni, ahol kizarolag az egyik agon volt valtozas egy fajlban, tehat nem volt conflict.
- Mar elofordult olyan hogy valaki mas sikitott hogy hogyan kerult vissza egy korabbi modositas mikor ki lett szedve (a tortenetet nem ismerem, termeszetesen siman el is ronthatta az illeto).
- Sokszor van hogy ket kulonbozo verzioju repot szeretnek osszehasonlitani (full recursive diff), ehhez mindig ket kulon lokal repo kell, mert egyidoben csak 1 verzio lehet a git repoban, ami nem eppen kenyelmes, foleg hogy mindkettot allandoan szinkronizalni kell a masterrel.
- Nekem a history az maga a tragedia, az egvilagon nem talalok meg semmit benne.
- Nalunk mindenki klonozza a kozponti repot, ami nekem kifejezetten nyug, mert teljesen feleslegesen kell a ket repot allandoan kezzel szinkronizalni.
- Kis csapatban rettenet elonyos volt a CC, ahol latom hogy a masik eppen min dolgozik, bele tudok nezni hogy eppen mit ir, illetve commit utan rogton tudom diffelni a sajat verziommal, hogy eppen mit irt at. Igy kvazi sync utan meg is volt a kodreview.
--
cythoon
- A hozzászóláshoz be kell jelentkezni
Köszönöm, pontosan az ilyen hozzászólások érdekelnének!
- A hozzászóláshoz be kell jelentkezni
Ha én azt mondom, hogy nálam meg sohasem szállt még el a helyi repó (pedig kapott vad dolgokat), akkor az jelent valamit?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
igen, értesz a githez. nem szándékosan tönkretenni egy repot (az rm -rf .git kivételével) azért nem egyszerű, legfeljebb az ember nem tudja hogy kell megcsinálni, és inkább kitörli, majd újra létrehozza
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
"- Nekem a staging es kommit kifejezetten idgesito, mert a semmiert kell 2x commitolni."
egyik embert idegesíti, én viszont akkor tépem a hajam ha nincs külön staging meg commit. svn stílusú workflow esetén tényleg felesleges, de ha úgy el kezd az ember csinálni dolgokat, majd a végén be kéne őket commitolni logikai egységenként, marha hasznos tud lenni hogy nem egy command végére kell beírni mindent.
hasonló eset a pull/push is, bár ez mondjuk már az elosztott verziókezelők tulajdonsága, ami tény, hogy egy vállalati környezetben, ahol mindenkinek folyamatos kapcsolata van a szerverrel sokszor feleslegesnek tűnhet (vagy akár az is, ha olyan a policy). de pl. ha valaki úgy fejleszt hogy megcsinál egy (nagyobb) feature-t, azt több kis commitban elhelyezve, akkor viszont kimondottan hasznos, hogy így egy csomagban küldi el a szervernek
a local repo elszállásról pedig annyit, hogy az a git tapasztalat hiánya mikor van. amikor először kezdtem el használni git-et, én is nem egyszer hoztam olyan állapotba a repot, hogy törölnöm kellett, aztán újraclone-ozni. de aztán ahogy megtanultam rendesen használni, megszűntek ezek a bajok (meg gondolom most már az akkor elrontott repot is simán helyre tudnám hozni).
(az egit tényleg egy rakás f*s, de szerencsére a git command line elég barátságos jószág...)
"- Sokszor van hogy ket kulonbozo verzioju repot szeretnek osszehasonlitani (full recursive diff),"
most vagy én nem fogtam fel a problémát, vagy a git diff rev1 rev2 miért nem jó?
I hate myself, because I'm not open-source.
- A hozzászóláshoz be kell jelentkezni
> - Nekem a staging es kommit kifejezetten idgesito, mert a semmiert kell 2x commitolni.
git commit -a. Nem kell, ha nem akarsz.
> - Historyt nem mindig tudja abrazolni grafban (ismert limitacio).
git log --graph --pretty=format:'%Cred%h%Creset -%C(yellow)%d%Creset %s %Cgreen(%cr) %C(bold blue)<%an>%Creset' --abbrev-commit --date=relative
Ha command-line kell, szines-szagosan. Ott van meg git log --graph, meg a kulonbozo git guik, amik mindezt tudjak szebben.
> - Mar elofordult olyan hogy valaki mas sikitott hogy hogyan kerult vissza egy korabbi modositas mikor ki lett szedve (a tortenetet nem ismerem, termeszetesen siman el is ronthatta az illeto).
Akkor valaki valamit elbaszott. Es nem a git volt az.
> - Sokszor van hogy ket kulonbozo verzioju repot szeretnek osszehasonlitani (full recursive diff), ehhez mindig ket kulon lokal repo kell, mert egyidoben csak 1 verzio lehet a git repoban, ami nem eppen kenyelmes, foleg hogy mindkettot allandoan szinkronizalni kell a masterrel.
Egy git checkoutban az *osszes* verzio ott van. Ha diffelni akarsz ketto kozott, git diff rev1..rev2. Tetszoleges verziok kozott lehet. Ahol rev nem kell, hogy lokalisan ki legyen checkoutolva, eleg ha le van fetchelve. (Ertsd: git diff origin/jozsi/my-big-feature..origin/piroska/typo-fixes gond nelkul mukodik, de pl git diff origin/master..master is.)
> - Nekem a history az maga a tragedia, az egvilagon nem talalok meg semmit benne.
LOL.
> - Nalunk mindenki klonozza a kozponti repot, ami nekem kifejezetten nyug, mert teljesen feleslegesen kell a ket repot allandoan kezzel szinkronizalni.
Lehet commit hookot irni ami automatikusan pusholja is a megfelelo branchet. Ha epp ez kell. En kifejezetten szeretem, hogy nem megy rogton kozponti repoba, mert igy van lehetosegem elotte megegyszer atnezni, vagy osszehuzni tobb atmeneti commitot egy pofasabbra, es ugy kipusholni.
(Pl ha ebed elott eljutok egy olyan pontig, hogy most mar kezd alakulni, de ket irany van amerre tovabbmehetek, akkor git commit -m 'temp: figure out wtf to do next'. Megkajalok, eldontom, nekiallok. Kiderul hogy rossz iranyba mentem, reset az elozore, masik tovabb, commit, aztan rebase -i -vel osszehozom egy szep commitba. Mindenki boldog.)
> - Kis csapatban rettenet elonyos volt a CC, ahol latom hogy a masik eppen min dolgozik, bele tudok nezni hogy eppen mit ir, illetve commit utan rogton tudom diffelni a sajat verziommal, hogy eppen mit irt at. Igy kvazi sync utan meg is volt a kodreview.
Topic branchek es gyakori push + commit notification. Ezzel latod, hogy ki min dolgozik kb. Es masterre topic branchbol mergelsz, es megvan a code review is.
Egyebkent a bajaid fele abbol adodik, hogy az egit buta. Az a gitrol magarol nem mond sokat, csak annyit, hogy lehet hozza gyer frontendet is irni. De mihez nem lehet?
--
|8]
- A hozzászóláshoz be kell jelentkezni
Kérdés, hogy akkor mit érdemes eclipse alatt git-re használni. Egyébként most még jobban megkedveltem a git-et, köszi :D
- A hozzászóláshoz be kell jelentkezni
alt-tab + terminalt ;)
(Eletemben nem hasznaltam eclipse-t, igy fogalmam nincs milyen lehetosegek vannak)
--
|8]
- A hozzászóláshoz be kell jelentkezni
Lenyegeben az osszes kommented arrol szol, hogy _te_ hogyan hasznalod a gitet es nem erted hogy az _nekem_ miert nem jo, holott pontosan ez volt a post celja es nyilvan erre kivancsi a kerdezo is. (ertsd: az, hogy mindent meg lehet _valahogy_ oldani, szamomra nem jelenti azt, hogy az eszkoz jo.) Ezen magyarazatot ertsd oda az osszes alabbi valaszhoz.
"Historyt nem mindig tudja abrazolni grafban (ismert limitacio)."
Itt EGitrol volt szo (lasd: egy blokk az egesz bekezdes...), tehat cli nem jatszik.
"full recursive diff"
Kulon koszonet azert hogy azt nezed ki az emberbol hogy nem tudja hogy van git diff, de amit az nyujt az keves.
"Topic branchek es gyakori push + commit notification"
Igen, pont errol van szo, hogy teljesen felesleges muveleteket vegzunk (ertsd: gyakori push).
"Egyebkent a bajaid fele abbol adodik, hogy az egit buta."
Ami Egithez kotodik az kulon blokkban volt kiemelve pont azert hogy vilagos legyen mi minek koszonheto. Az, hogy cli-ben mukodik, engem nem fog segiteni, mikor eclipse alatt dolgozom.
"a local repo elszállásról pedig annyit, hogy az a git tapasztalat hiánya mikor van."
Hat igen, a dolgok 30 eve valtozatlanok:
"Blame the user, not the program" - Unix Haters Handbook
:)
--
cythoon
- A hozzászóláshoz be kell jelentkezni
Egit != Git. A problemaid fele abbol adodik, hogy az egit fos.
> Kulon koszonet azert hogy azt nezed ki az emberbol hogy nem tudja hogy van git diff, de amit az nyujt az keves.
Miben keves? Miben tud tobbet az a valami amit te full rekurziv diffnek nevezel annal, amit a git diff rev1..rev2 csinal?
> > "Topic branchek es gyakori push + commit notification"
> Igen, pont errol van szo, hogy teljesen felesleges muveleteket vegzunk (ertsd: gyakori push).
Tedd commit hookba, es nincs felesleges emberi muvelet, leemulaltad a centralised version controlt.
> Az, hogy cli-ben mukodik, engem nem fog segiteni, mikor eclipse alatt dolgozom.
Alt-tab szerintem eclipse alol is mukodik. Nem fog letorni a kezed. Es bar el kell hagyni az imadott editort (oh, jajj! mi lesz igy a vilaggal! KET KULONBOZO PROGRAM FUT EGYSZERRE! OMG!), az a fel pillanat, mig kiadja az ember a megfelelo git parancsot, sokkal kevesebb idot vesz el, mint ha azon puffog hogy az egit mekkora egy tragyadomb.
--
|8]
- A hozzászóláshoz be kell jelentkezni
"(Eletemben nem hasznaltam eclipse-t, igy fogalmam nincs milyen lehetosegek vannak)"
Reszemrol a szalnak vege :)
--
cythoon
- A hozzászóláshoz be kell jelentkezni
Ohm, es ha nem eclipse-t hasznalnal, hanem valami tisztesseges IDE-t, akkor mi lenne?
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
En ertem mi a problemad, de mondjuk egyszer tolts le egy 30 napos trial-t az IntelliJ full editionbol hogy tudd miert nem mernek az Eclipse-ert penzt kerni, az IntelliJ-ert meg miert igen :)
- A hozzászóláshoz be kell jelentkezni
Kosz a tanacsot, nincs szuksegem ra, ismerem mindkettot.
--
cythoon
- A hozzászóláshoz be kell jelentkezni
Tudod, tenyleg nem ertem a problemadat, es attol felek, nem vagyok egyedul.
- Nem tudod kulonvalasztani az eclipse korlatait a git korlataitol
- Az Eclipse-ben egy tobbek altal szidott frontend/implementacio van, aminek nagyon korlatozottak a lehetosege, ez alapjan iteled meg a git-et, negativan
- Mindezt vilagosan, erthetoen, jozanul elmondjak neked, te meg majdhogynem lehulyezed az embereket
Ezek csak tenyek voltak, amiket leszurtem a szalbol. Erteni most sem ertem. Tenyleg olyan nagy problema, legalabb kiprobalni, hogy milyen konzolbol hasznalni? Fejlesztokent nem tudom elhinni, hogy nincsenek olyan eszkozok, amiket konzolbol kell hasznalnod, nem tudom miert idegenkedsz akkor a git-tol ennyire.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Akkor most jött el az én időm, hogy valamelyest megvédjem sznikit!
Egyrészről szinte Ő volt az egyetlen, aki a topic-ra érdemben válaszolt.
A szavazás célja, hogy a git használatának problémáit előhozza, nem a git-ét, hanem a használatáét. Tehát az emberi hibákat és az eszközök hibáit, korlátait.
Ő leírta, hogy a használatánál milyen problémák jöttek (jönnek) elő. Ezen problémák között vannak (lehetnek) felhasználói hibák, és az alkalmazott eszköz hibái (egit).
Az egyetlen pici gond a hozzászólásával, hogy a véleményét is belevette, de ettől függetlenül a hozzászólása előre viszi annak megismerését, hogy milyen gondok lehetnek a git bevezetésével.
Nyilván az is fontos, hogy megismerjük, hogy az adott problémákra milyen megoldások lehetségesek. Erre algernon válasza valamelyest jó is volt.
Az egy másik kérdés, hogy mennyire értünk (értek) egyet szniki véleményével, de próbáljuk meg egymás véleményét tiszteletben tartani és nem a földbe döngölni, mert le merte írni, amire a szavazás megkérte.
"Mindezt vilagosan, erthetoen, jozanul elmondjak neked, te meg majdhogynem lehulyezed az embereket"
Ez oda-vissza igaz, sőt inkább vissza, ezért is kellett megszólalnom!
- A hozzászóláshoz be kell jelentkezni
Vilagosan leirtam mashol mar, hogy az egit limitacioi nem veletlenul kerultek egy kulon paragrafusba, nincs kedvem tovabbi 10 alkalommal ugyanezt elmagyarazni csak azert mert a lilaköd fanboiok keptelenek 2 mondatnal tobbet fejben tartani.
Ahogy a kerdezo is irta felettem, teljesen vilagos volt, mire kivancsi, ezert kerult alakult a felsorolas ugy, ahogy (git es egit, egit pedig kulon szekcioban) es azt is vilagossa tettem, hogy ezek egy resze siman lehetett user hiba is.
Hitvitat nem fogok a kerdesrol folytatni, van amiben pl szeretem a gitet es van amiben ruhellem. Ahogy a CC-t is.
Ezek a "probald az intellij-t" meg "Tenyleg olyan nagy problema, legalabb kiprobalni, hogy milyen konzolbol hasznalni?" beszolasok meg csak arrol arulkodnak, hogy _neked_ bejott az adott eszkoz es keptelen vagy elhinni, hogy masnak meg _nem_, mert ha kiprobalta volna, akkor _biztosan_ ugyanugy gondolna mint _te_. Srsly?
--
cythoon
- A hozzászóláshoz be kell jelentkezni
Nem, te nagyon tevedsz.
Azt lattam hogy kulon szalba szedted a git es az egit problemait, a gond az, hogy a velemenyedet ettol meg elso sorban az egit limitacioi befolyasoljak, magadban nem tudod kulonvalasztani a kettot, mert meg kevesse ismered a Git-et. Amit mindenki ajanl, hogy probald ki terminalbol vagy masik IDE-bol, hogy tenyleg ugyanolyan rossz-e. Ha igen, akkor fel lehet adni a Git hasznalatat, foleg, hogy nalad van jo, ertelmes, es bevalt alternativa. A Git nem diktatura, amiben kotelezo hinni, csak egy eszkoz.
Nem azert mondjuk, mert meg vagyunk gyozodve arrol, hogy neked ez jo lesz, ilyet jo erzessel nem allithat senki. Mindossze neked akarunk jot, amikor azt ajanljuk, hogy fuss neki egy olyan kornyezetbol a Git hasznalatanak, ahol nincsenek limitaciok, ahol jobban segitik a munkadat, ahol kenyelmesebben tudsz vele dolgozni, hogy kerek es egesz kepet kaphass rola. Ha nem kenyelmes, nem illeszkedik a workflow-ba, dobd el nyugodtan, ez is csak egy kobalta.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Es ennyire lamanak tartasz hogy ez meg nem jutott eszembe? :)
--
cythoon
- A hozzászóláshoz be kell jelentkezni
De most ezt ugye nem mondod komolyan? lehet, hogy a git neked nem jon be, hat istenem. De a CC-t visszasirni? Magyarazza mar nekem el valaki, hogy abban az elavult szarban mi a jo?
CC elonyei:
- a filozofiaja tok szar: egy teljes fejlesztoi generaciot sikerult raszoktatni a gondolkodas nelkuli commitolasra, es a reserved checkoutra, es a diff tool nem hasznalatara
- csak file szintu commit letezik, nicsnenek change setek vagy hivja mindenki, ahogy akarja, a lenyeg, hogy nincs, ha changeseteket akarsz, akkor labelezhetsz, mint egy guzu
- a kliens primitiv, mint egy faek, alapveto funkciok hianyoznak, szinte barmilyen komolyabb muveletnek csak parancssorbol erdemes nekifogni
- tavolabbi halozatos munkaban lassu, bocsanat iszonyatosan lassu, a kozismerten "chatty" prokolja miatt
- a konfiguracioja egyenesen tragedia: ket kulonfelekeppen konfiguralt szerveren levo vobokat egyszeruen nem tudsz egy kliens installaciobol hasznalni; csak a kliens teljes ujrainstallalasaval tudsz szervert (infrastrukturat) valtani; na jo turhatom konyekig a registryt allitgathatom a legmelyebb bugyrokat a home baseben, es parameterzehtem ujra az atria location brokert, stb, stb, na de miert is? ez a lesjanalt svn-ben is egyszeruen egy masik url megadasaval megvan
- draga, bocsanat a tudasahoz kepest iszonyatosan draga
- A hozzászóláshoz be kell jelentkezni
Huha, latom beizgultal :-)
Erdekes, hogy a CC pont azt kinalja amit altalaban a linux boyok imadnak: teljes customization es a cli is teljeskoruen tamogatott, ennek ellenere amit te szidsz benne az pont az, hogy az alap fapad UI az neked gagyi es konzol kell hozza. Sosem hittem volna hogy ilyet olvasok hupon :)
Viccen kivul, nalad keveredik a CC adminolasa es a felhasznalasa, tehat gondolom egyszemelyben csinaltad a kettot. En az admin reszet letojom leven semmi dolgom vele.
Azert az kemeny hogy mikozben a CC ugyanazt tudta mar 1994 ota mint a git, itt szidod hogy szar :) (snapshot es dynamic view, 3way merge, lenyegeben hasznalhatod ugy is ahogy a git "cimkez" de fajlonkenti verziozas + label eppenseggel tobbet nyujt mint a git..., az MVFS + view rendszer pedig siman szarra veri a git fele local repot ahol tobb workspace-d sem lehet (azt a script hacket inkabb ne emlegessuk amit erre "kitalaltak")
A tudasahoz, lehetosegeihez es foleg megbizhatosagahoz kepest pedig egyaltalan nem draga :)
"egy teljes fejlesztoi generaciot sikerult raszoktatni a gondolkodas nelkuli commitolasra, es a reserved checkoutra, es a diff tool nem hasznalatara"
Leccine.
"csak file szintu commit letezik, nicsnenek change setek vagy hivja mindenki, ahogy akarja, a lenyeg, hogy nincs, ha changeseteket akarsz, akkor labelezhetsz, mint egy guzu"
Tehat akkor megis vannak? Es mitol "guzu"? Hogy megnyomsz egy gombot? Normalis customizationben ugyanis ennyi a muvelet...
"a kliens primitiv, mint egy faek, alapveto funkciok hianyoznak, szinte barmilyen komolyabb muveletnek csak parancssorbol erdemes nekifogni"
Wow. Parancssor! Jesszumpepi!
"tavolabbi halozatos munkaban lassu, bocsanat iszonyatosan lassu, a kozismerten "chatty" prokolja miatt"
Erre valo a remote site es a snapshot view... ettol fuggetlenul alairom, lassu.
A CC szalat itt reszemrol lezarom mert offtopik, nem a CC volt a kerdes, csak ennyi kamuszoveget inkabb rendberakok.
--
cythoon
- A hozzászóláshoz be kell jelentkezni
Namost egyreszrol semmiben nem cafolod az altalam leirtakat, majd kamu szovegnek minosited, es polemizalsz. Nem a CC-rol akartam vitatkozni, csak szerettem volna tudni, hogy ki miert szereti. Ha mar.
- A hozzászóláshoz be kell jelentkezni
gitezunk, igaz, most jelenleg ketten vagyunk az uj projekten (egyelore csak azt hostoljuk giten, tobbi svn-en van). Megtanulni tenyleg nehezebb talan mint a subversiont, de szerintem nagyon megeri, nagyon bejon a distributed vcs. Elozo helyen szinten giteztunk, ott en vezettem be konkretan, azelotti helyen subversiont hasznaltunk, nekem az nem annyira jott be. Tobb munkahelyem eddig nem volt :D Az elozo helyen volt egyszer egy kisebb problema a rossz hasznalat miatt, kollega commit elott pullozott originrol, es osszekurta a working directoryjat vele, azt kellett ujrairnia, de ennyi. Akkor megtanulta gyorsan, hogy eloszor commitolni kell :) Vegulis nem basztam le erte, egyreszt csak a sajat cuccat baszta szet (igaz, hogy tulora lett belole nekem is, de legalabb tanult belole igy is).
--------------------------------
http://r1pp3rj4ck.wordpress.com/
- A hozzászóláshoz be kell jelentkezni
mi bajod volt az svn-nel, es mitol olyan jo neked a git?
Jo jatek meg elmondhatod magadrol hogy neked is Levi's 501 farmerod Adidas csukad git verziokezelod van, de ket embernel megis mire?
- A hozzászóláshoz be kell jelentkezni
Az svn hatranya ott kezdodik, hogy ha egy logot akarsz nezni, ahhoz is a server kell neki. Ha meg keresni is akarsz benne, az meg elegge elgondolkodtato tud lenni. Ket branch mergeleset nem eri meg osszehasonlitani a gittel, habar ugy hallottam, hogy az utobbi idoben mintha fejlodott volna e teren is. Ugy velem, hogy nem userek szamatol fugg, hogy erdemes-e gitet hasznalni. Egyszeruen gyorsabb, kenyelmesebb. Nem csak azert hasznal az ember scm-et, hogy masokkal megossza a forrast, hanem, hogy a sajat magan is segitsen.
--
HUP Firefox extension
- A hozzászóláshoz be kell jelentkezni
+1
én is rengetegetet használom, pedig ezek közül egyik sem többemberes projekt.
- A hozzászóláshoz be kell jelentkezni
Mondjuk nem gondolom hogy SVN-t trac nelkul hasznalni...
Merge-elesi gondokat az 1.6-ban mar gyakorlatilag teljesen lekuzdottek, 10 ev utan vegre.
A ketfazisu commit nekem nem kenyelmes, nekem az hibafaktor.
- A hozzászóláshoz be kell jelentkezni
Merge-elesi gondokat az 1.6-ban mar gyakorlatilag teljesen lekuzdottek, 10 ev utan vegre.
Ha meg a sebessege is emberi lenne, az igazan Istenes volna!
--
HUP Firefox extension
- A hozzászóláshoz be kell jelentkezni
A SVN-ben még mindig nagyon könnyen hízik a repó?
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
- A hozzászóláshoz be kell jelentkezni
Jó kis írás, köszi!
- A hozzászóláshoz be kell jelentkezni
Azt mar olvastam, az tomeny fassag. Atol meg hogy Joel nem latott jol hasznalt kozponti verziokezelot, nem jelenti azt hogy neked hu de dvcs kell.
- A hozzászóláshoz be kell jelentkezni
Nem az a kérdés, hogy jó-e nekünk a dvcs (git) filozófiája. Arra megvan a válasz: nagyon jó.
A kérdés az, hogy a bevezetésével mennyi és milyen súlyú problémával kerülhetünk szembe, illetve konkrétan mely problémákkal.
- A hozzászóláshoz be kell jelentkezni
Big fat +1
--
cythoon
- A hozzászóláshoz be kell jelentkezni
ezek aztán kemény szakmai érvek :) esetleg összefoglalod miért gondolod h neked egy DVCS megközelítés hátrányosabb lenne?
- A hozzászóláshoz be kell jelentkezni
Azt írja, hogy szubverzsönnel mennyire nehéz mergálni a kódot. Ami egész egyszerűen hülyeség. Mi kb 20-an vagyunk egy terméken, és nem szokott komoly gond lenni egy merge. Lehet nagyobb projekteknél gond, de ez is csak azt mutatja, hogy más célra más eszköz. Nincs egy univerzálisan jó verziókezelő sem, ahogy semmi másból sincs. Az elosztott verziókezelő két nagy hátránya, hogy nehezebb a beletanulás, és nehezebb maga a használat is, több műveletet igényel az egyén részéről.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Fent leirtam, semmi, csak az, hogy Distributed, nekem meg ahhoz hogy dolgozni tudjak, egy central authentikus verziokezelo kell (tamogatva mindazt a use case-t amit sz leirt), nem pedig egyesevel meggyozni embereket, hogy marpedig osszessegeben nagyobb kockazat ha hasznalja a distributed ficsoreit, mint amekkora szivas ha nem.
- A hozzászóláshoz be kell jelentkezni
Ahogy Gyuszk is leírta, lehet a git-et központosítva is használni, sokkal nagyobb kontrollal, mint a sima vcs-ekkel.
- A hozzászóláshoz be kell jelentkezni
Hát igen, attól hogy git még szépen le lehet szabályozni a dolgokat. Mi egyébként az svn -t hagytuk ott annó a gitért, és megérte.
- A hozzászóláshoz be kell jelentkezni
Az a problema, hogy nincsen olyan verziokezelo ami jo lenne, es ne lenne dvcs.
--
|8]
- A hozzászóláshoz be kell jelentkezni
Aruld mar el mi bajod az svn 1.6-tal :) Iszonyatosan azt tudja, amit neki kell.
- A hozzászóláshoz be kell jelentkezni
mert szimpatikusabb, mint az svn, tok mindegy, hany emberrol van szo. jobban kezreall, stb.
--------------------------------
http://r1pp3rj4ck.wordpress.com/
- A hozzászóláshoz be kell jelentkezni
CMVC a kozponti, sajat magunknak svn/git.
- A hozzászóláshoz be kell jelentkezni
Mercurial nem játszik? Mi most tértünk át rá pár hónapja, nem mondom, hogy nem kellett tanulni (persze ha a hginittel kezdtem volna... :-D ), de ezen felül teljesen jó eddig, és 2-3 fős projecteknél se gáz.
- A hozzászóláshoz be kell jelentkezni
Lehetne éppen az is. Előzetesen megnéztük a Mercurial-t és a Git-et is (még egy kicsit a Bazaar-t is :-), elolvastunk sok írást a témában és a git tűnik jobbnak a számunkra.
- A hozzászóláshoz be kell jelentkezni
Nálunk svn a repo, néhányan gittel használják. Mit nyomjak, ha jól tudom probléma nincs, de nem az A verziókezelő.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni
Nem kell, hogy a git legyen A verziókezelő. Elég ha hárman közös munkára használják.
Szerk.: Ha nincs közös git repo, akkor az "egyebet használ"-t.
- A hozzászóláshoz be kell jelentkezni
Szeretném megkérni azokat akik a "git-et használ kisebb/nagyobb problémákkal (leírom a hozzászólásban)."-ra szavaz, hogy röviden írja le milyen problémák voltak, vannak!
Előre is köszönöm, sokat segítene vele!
- A hozzászóláshoz be kell jelentkezni
egyebet: mercurial
- A hozzászóláshoz be kell jelentkezni
Szintén. Amúgy ma ez (git vs. hg) már inkább csak ízlések és pofonok kérdése.
- A hozzászóláshoz be kell jelentkezni
Bejelöltem, hogy git-et használunk kisebb problémákkal.
Valójában folyamatban van a bevezetése. Mindenképpen használni fogjuk, egyelőre tetszik!
A kisebb problémát a bevezetés és a tanulás folyamata miatt jelöltem meg.
- A hozzászóláshoz be kell jelentkezni
A cegnel svn van, en meg nem hasznalom, ha fogom, akkor csakis git-svn -en keresztul.
Korabban dolgoztam svn-nel, szerettem, de folyamatos online jelenletet igenyelt, ami nem mindig volt meg. Meg nekem valahogy nem tunik tobbnek, mitnhogy masolok egy mappat masik neven.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
Nálunk nagyon jól beválik. Önmagában is elég powerful, de mivel elterjedt és az emberek szeretik, rengeteg hasznos eszközzel lehet bővíteni a workflow -t (gerrit code review, jenkins CI, hook scriptek, cgit, stb stb).
Nálunk a következő a felállás:
- csapatvezetőnek van csak joga az origin/master felé pusholni, a többiek csak a gerritbe pusholhatnak (itt persze figyelni kell a rendszeres pull mellett azt, hogy a commit parentja mindig az origin/master teteje legyen)
- ugyanakkor ő is csak oda push -ol, a konzisztencia miatt
- ha egy változtatás rossz, akkor soronként kommentálni lehet, és pontozni, ilyenkor az illető megjavítja és --amend opcióval újra bepusholja gerritbe
- ilyenkor 1, 2, 3, 4, ... stb patch szintek jelennek meg ugyanannál a változtatásnál
- végül elfogadja a reviewer (jelen esetben az az 1 valaki), gerriten keresztül bemergeli masterba (az eredeti szerző neve megmarad a commitnál)
- A hozzászóláshoz be kell jelentkezni
Ez a topic pont kapóra jön, én erősen szorgalmazom a cvs-ről git-re áttérést nálunk :)
- A hozzászóláshoz be kell jelentkezni
+1
A fenti véleményütköztetések jól mutatják, hogy ez a téma is erősen hit kérdése.
A fentiekből is lehet sokat okulni, de szerintem túl sok benne a szájkarate.
Tisztelet a kivételnek!
Az én történetem:
Nem kellett csoportmunkában dolgoznom, egyéni harcos voltam, vagyok. Annak ellenére, hogy egyedül csinálok egy halom egymástól is függő projektet, valójában ugyanúgy kihasználom a lehetőségeket, mert a projekteket több helyen fejlesztem, különféle körülmények között. Ezért ha jövök megyek, itt is ott kell valamit csinálni, ez gyakorlatilag pont olyan mintha több ember dolgozna egy-egy projekten. A verziókövető használata nagyon megkönnyítette az életemet, sokkal könnyebben lehet rendben tartani az egész fejlesztési munkámat, pedig csak magamnak csinálom! Én nagyon gyűlölöm az általam egy kicsit is fölöslegesnek talált dolgokat, én szívesebben váltok egy jobbnak talált eszközre, mint használok egy előnytelen rendszert. Ezt azért mondom, hogy a korábbiakban hátrányként leírt commitolással való problémákat én nem érzem gondnak, inkább hasznosnak.
Régebben saját magam továbbképzése miatt cvs és svn-nel próbálkoztam, de nem tetszett a megoldás inkább csak el vette a kedvem. A git-et végre olyannak találtam ami sokkal rokonszenvesebb, hangsúlyozom az én verziókövetéssel kapcsolatos fogalmaim alapján. Nyilván ez is valamilyen ideológia szerint készült és ahhoz nyújtja a legjobb támogatást. Azaz, ahogy elhangzott ezt is csak okosan kell használni, mint eszközt ÖSSZESSÉGÉBEN én ezt találom a legmegfelelőbbnek.
Én úgy vélem a betanulási idő plusz költsége önmagában nem jelentős nekem max 20%-volt.
Ha átállásról van szó akkor nyilván még ennél kevesebb, mint 0-ról.
Ha a hasznosságát hosszútávon vizsgálom, akkor többlettanulási igény elenyésző (akkor is ha 2x nagyobb lenne a betanulási idő).
Az hogy ilyen körülmények között "ágyú"-e a git?
Szerintem egyáltalán nem, nekem inkább "svájci bicska".
Egy próbát megér demóként és gyakorlásként a kernel.org-ról letölteni egy elég nagy projektet, és matatni benne helyileg, és egy másik gépről (publikus repróként) is, érdemes a sebességét és a méretét megfigyelni.
(Ja, és ha valaki magas ívben tesz a divatra az én vagyok)
- A hozzászóláshoz be kell jelentkezni
Perforce, mert ezt kell... :-)
- A hozzászóláshoz be kell jelentkezni
Az egyik legfontosabb hozzászólás eddig ez.
Vagyis nem az számít, hogy hány ember dolgozna a git-tel, mert kevés emberrel is lehet jól használni és sok emberrel is szarul. Én használtam rövidebb ideig SVN-t, hosszabb ideig Bazaar-t és most Git-et. Ha sorrendbe kellene tennem őket, akkor az is így alakulna. Én úgy vettem észre, hogy az SVN a maga módján nem más, mint egy felturbózott CVS, amelyről pedig tudhatjuk, hogy igazából nem is verziókezelő rendszer. Az SVN összes előnye bármivel szemben az, hogy jobb a szoftver-támogatottsága: Szinte mindenhez van már plugin hozzá.
Akik a Git-re azt mondják, hogy nehézkes és kétszer kell commitolni, azoknak ajánlom a „git commit -a” parancsot (új fájloknál azért kell a „git add”) – de ezt már többen is mondták előttem. A nehézkességre pedig ajánlom ezt és ezt a linket. Ez utóbbit azért is, mert nagyon hasznos és SVN-nel kb. kivitelezhetetlen normálisan: issue-nként külön branch-ot nyitunk, szükség esetén azokat rebase-sel mozgatjuk, majd merge a megfelelő ágba. Így van egy olyan fejlesztési modell, ahol az egyes issue-k kódjai szépen elválnak egymástól.
Amúgy az a tapasztalatom, hogy bár elsőre a Git tanulási folyamata hosszabbnak, nehezebbnek tűnhet, de ha valaki egyáltalán nem rendelkezik verziókezelési gyakorlattal, akkor ez nem számottevő.
A grafikus git pluginok helyett javaslom a parancssoros eszközöket, pár aliassal nagyon kényelmessé tehetőek. Grafikus dologként egyedül a „gitk --all”-t használom.
Összegezve: megfelelő dokumentációval nekiindulva a Git kezesbárány, amely nagyban segíti a tényleges munkát. A jelenlegi tapasztalataim alapján már semmiképpen sem váltanék központosított verziókezelőre, mert egyszerűen nem adnak annyi előnyt, mint amennyi hátrányt.
-----
"Egy jó kapcsolatban a társunkat az ő dolgában kell támogatni, nem a miénkben."
rand() a lelke mindennek! :)
- A hozzászóláshoz be kell jelentkezni
A successful branching modelt hasznalom en is, tenyleg nagyon hasznos es mukodo dolog, a fejlesztest nagyban megkonnyiti. Olyan kodnal is el lehet kezdeni, ahol addig a git parancs csak a feloldasa volt az svn aliasnak. De a legjobb, ha mar a fejlesztes elso fazisatol igy fejlesztik a kodot. En a master agat megtartom tisztan mindig, es oda csak a vegleges kod kerul ki, a develop agon meg lehet bohockodni. Mondjuk neha van egy-egy typo, amire nem nyitok kulon bugfix agat, hanem csak ugy a developon becommittolom es vegig rebaselem a brancheket (a mastert kiveve), de ez mar lustasag.
--
Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal - A hozzászóláshoz be kell jelentkezni
"Ez utóbbit azért is, mert nagyon hasznos és SVN-nel kb. kivitelezhetetlen normálisan: issue-nként külön branch-ot nyitunk, szükség esetén azokat rebase-sel mozgatjuk, majd merge a megfelelő ágba."
Arra van mondásod, hogy miért volt ez nehéz SVN-nel?
- A hozzászóláshoz be kell jelentkezni
Egyeb: mindig azt, amit az adott ceg hasznal. Eddig egyik vcs-el sem volt komolyabb bajom. Ha rajtam mulik, akkor git-et hasznalok.
- A hozzászóláshoz be kell jelentkezni
voltak rossz elmenyeim a gittel, tok ures merget csinaltatott velem, nem jottem ra miert
szetszallt a local repo, lol (le ^C-ztem valamit, ugy latszik nem szabadott volna ;))
az egesz tul bonyolult es atlathatatlan
sok folosleges commit az tenyleg wtf
cvs, svn-nel soha ilyen gondom nem volt, de meg hg-val sem (bar szerintem a distributed nem egy jo modell, viszont ez szubjektiv velemeny)
--
NetBSD - Simplicity is prerequisite for reliability
- A hozzászóláshoz be kell jelentkezni
a cvs es fostalicska, en utalom is :(
kar, hogy joerg gitjen keresztul nem lehet kommitolni :P
- A hozzászóláshoz be kell jelentkezni
Én egy emberes verziókezelésre is git-et használok. Az ember beírja az adott könyvtárban állva, h "git init", aztán már mehetnek is a commitok. Nagyon kényelmes, ha elront valamit.
- A hozzászóláshoz be kell jelentkezni
Erről a topikról jut eszembe:
Chuck Norris nem tud elosztott verziókezelőt használni, mert a lokális repója valahogy mindig központivá válik.
----
Hülye pelikán
- A hozzászóláshoz be kell jelentkezni