- Rendkívül ütőképesnek tűnik az újragondolt Apple tv
- OLED TV topic
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Hobby elektronika
- 3D nyomtatás
- Intel Core i5 / i7 / i9 "Alder Lake-Raptor Lake/Refresh" (LGA1700)
- Házi barkács, gányolás, tákolás, megdöbbentő gépek!
- Nyomtató topik
- TV antenna és jelerősítés
- Gaming notebook topik
Hirdetés
-
Retro Kocka Kuckó 2024
lo Megint eltelt egy esztendő, ezért mögyünk retrokockulni Vásárhelyre! Gyere velünk gyereknapon!
-
Killing Floor 3 - Nyúlfarknyi videón a folytatás
gp A franchise új része sajnos még mindig nem kapott megjelenési dátumot.
-
Bemutatkozott a Redmi 13 4G
ma Ne keverjük össze a Redmi Note 13 4G-vel vagy a Redmi 13C 4G-vel.
Új hozzászólás Aktív témák
-
MODERÁTOR
válasz Aethelstone #8900 üzenetére
Lehet, de lehet neki csak ennyi tizedesig kell.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
nagyúr
válasz Aethelstone #8900 üzenetére
Orai peldakodbol kimasoltam azt a reszt, azota mar atirtam PI-re
Amit el szerettem vna erni, hogy a gombom random pontjai random szammal legyenek eltolva ugymond kifele-befele, hogy ne szabalyos gomb legyen. Ezaltal hasonlitana a feladatban meghatarozott "aszteroidara".
-
MODERÁTOR
válasz Aethelstone #8903 üzenetére
Ez is igaz, de nem tudom, hogy grafikában hány tizedesig illik használni a Pi.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
veterán
-
Chesterfield
senior tag
Sziasztok!
Java SE ismeretek megszerzése után, ha EE irányba mennék tovább, szükségem van ezeknek az ismeretére?
- Maven
- Git,
- Spring alap
- JPAköszi
-
ToMmY_hun
senior tag
válasz Chesterfield #8908 üzenetére
Első kettőre és a harmadikra amúgy is, azok nem EE specifikus dolgok.A kérdésedre válaszolva pedig igen, ezekre vagy alternatívájukra szükség lesz.
[ Szerkesztve ]
C programmers never die, they are just cast into void.
-
Aethelstone
addikt
válasz Chesterfield #8908 üzenetére
Git-re nem feltétlenül, SVN is nagyon sok helyen van. Nyilván nem hátrány az ismerete
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
MODERÁTOR
válasz Chesterfield #8908 üzenetére
Maven helyett mondjuk én már a Gradle-t nyomatnám.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
MODERÁTOR
válasz Aethelstone #8912 üzenetére
"hiába érkeznek az ifjú titánok gradle/git ismeretekkel".
Minek szekresszek xml-t ha nem muszáj? Miért kell ragaszkodni a mavenhez? Kevesebbet tud.
Az svn-ről meg nem tudok nyilatkozni. Az van ami van, ha nem akarnak váltani nem ha akarnak meg úgyis tudnak.
Szerk.: vállalati környezet persze egy kizáró ok, ezzel tisztában vagyok.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
nagyúr
válasz Aethelstone #8912 üzenetére
> A cégek jellemzően maven/svn kombót használnak
Azert az SVN nagyon nem skalazodik, ahogy en latom, a nagy cegek inkabb Perforce-rol mennek lassan git-re.
A Google-nal pl. sajat, Mercurial-ra epulo VCS van, mivel egyetlen repo van az egesz cegnel.
[ Szerkesztve ]
while (!sleep) sheep++;
-
MODERÁTOR
válasz Aethelstone #8915 üzenetére
Ezt szerintem projektje válogatja. Jelenlegi munkahelyemen van vagy 200 branch.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
MODERÁTOR
válasz Aethelstone #8917 üzenetére
Ha kvázi egy szoftvert csinálsz 50 féle hardverre. Máshogy szerintem nem tudod megoldani jól.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
Aethelstone
addikt
Persze, nyilván feladatfüggő. Mi egy szoftvert csinálunk kb. 10 féle OS-re. Persze a differenciálás főleg a build környezet feladata, mert a kód kb. ugyanolyan, de a telepítőcsomagok jócskán eltérnek (msi, deb, rpm, apk, stb)
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
Chesterfield
senior tag
köszi a válaszokat
-
floatr
veterán
Re maven/gradle: a gradle megítélésem szerint még elég kiforratlan dolog, és elég gyerekcipőben jár a támogatása az egyes IDE-kben. Sajnos én addig nem tudom eléggé komolyan venni a dolgot. Mondom ezt úgy, hogy egy nagyobb projektcsomagot migrálunk most gradle-re. Akinek egy maven-féle XML szerkesztése gondot jelent, az válasszon más pályát
Re SVN/GIT: nagyon menő egy ideje a GIT, és mindenki migrál veszettül, ész nélkül sajnos. A legtöbb projekt ugyanis nem igényli a GIT modelljét, ellenben komplikáltabb a használata. Tapasztalatom szerint még az SVN használata is kihívás sokaknak, nemhogy a GIT. Biztos van helye a GIT-nek is (pl nagy projekt kis, 1-2 személyes, javarészt független alprojektekkel), bár én eddig még sehol nem láttam indokoltnak, leszámítva azt az esetet, amikor egy ügyfél előtt pozicionálunk arculatot.
-
nagyúr
válasz Aethelstone #8917 üzenetére
Minden feature vagy fix egy branch nalunk.
while (!sleep) sheep++;
-
Lortech
addikt
Gradle Android/studio-nál megkerülhetetlen.
Git akkor komplikáltabb, ha komplikáltabb dolgokra használod. Sokaknál azt veszem észre, hogy git előtt csak egyszerű dolgokra használta a vcs-t, git után ráérez és elkezdi jobban érdekelni a dolog.
Nagyon egyszerű felhúzni új repót, gyors, hatékony, jól skálázódik, jól testreszabható, tök jó támogató eszközök épültek köré, jól üzemeltethető.
Az SVN a jelenlegi workflowt, amit használunk, nehezen tudná jól támogatni, legalábbis az én munkámat dev leadként. Mondhatnám én is, hogy akinek gondot jelent pár nap alatt belerázódni a GIT-be, az válasszon más pályát. Sima alkalmazásfejlesztőknek kb. három mondatban le tudom írni adott projekten az össz teendőjét gittel. Kb. 6 éve az összes projektemen git mellett döntök, SVN-ről váltottam, azóta soha eszembe nem jutott SVN-t használni, ha nem adottság. Ha SVN-t, neadjisten CVS-t, vagy CC-t látok (ügyfélnél), hamar idegrángásom lesz tőle és általában felrakok fölé egy GIT-et.#8908 eredetire: igen, mind a 4-re szükséged van, de ha nem senior pozíció, akkor alap szinten ismerni elég ezeket. Komolyabban úgyis munka közben tudod megtanulni.
[ Szerkesztve ]
Thank you to god for making me an atheist
-
MODERÁTOR
"Akinek egy maven-féle XML szerkesztése gondot jelent, az válasszon más pályát "
Én ilyet nem mondtam, csak azt, hogy minek irogassak XML-t ha nem muszáj.
"és elég gyerekcipőben jár a támogatása az egyes IDE-kben."
Csak ismételni tudom magam. Idea, megnyitom mint gradle projekt és kész. Semmit nem állítok neki az ég világon.
Gitre, #8924.
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
floatr
veterán
Szerintem feature branchingre inkább való az SVN. Az kétségtelen, hogy programozó sejtekbe csoportosulva a GIT jobban skálázódhat, de finoman szólva nem ez határozta meg a felhasználási területeket egyetlen projektnél sem -- legalábbis nálunk.
(#8924) Lortech Tisztában vagyok vele, hogy a gradle irányába folyik még a Duna is, de egyelőre általános felhasználásra kicsit még kísérleti szaga van. Kell neki még egy kis idő, de hiánypótló az ANT után.
A GIT meg nyilván felhasználás kérdése, ha kell, akkor kell. Én viszont a GIT-tel vagyok úgy, hogy az utóbbi években kialakított workflow-t csak megnehezítené. Nemrég írtam egy scriptet is SVNhez, hogy még azzal se kelljen időt pocsékolni, hogy kattintgat az ember a branchek között, meg a history-ban merge előtt, nem sokból tartana GIT-re átírni, de csak a változtatás kedvéért teljesen feleslegesnek érzem a változtatást. Én inkább érzem arculati tényezőnek, mint valóban hasznos eszköznek. Kicsit olyan érzésem van vele kapcsolatban, mint amikor az ember összekötött kézzel akar úszni, hogy más is láthassa, hogy tud összekötött kézzel is úszni.
-
WonderCSabo
félisten
En dolgoztam SVN-nel is, git-tel is, es az utobbira szavazok. Nem teljesen ertem hogy azt mondod "feature branchingre inkább való az SVN", mikozben az SVN-ben egy branchet eleg pain letrehezni (hiszen valojaban masolas tortenik), mikozben git-ben csak egy pointer allitodik at pillanatok alatt.
-
Chesterfield
senior tag
Itt vajon miért kapom swingben a következő hibaüzenetet?
Exception in thread "AWT-EventQueue-0" java.lang.NumberFormatException: For input string: "1 0000"
private void bt0ActionPerformed(java.awt.event.ActionEvent evt) {
if (kiiras.getText().length() < 20) {
String outPut=kiiras.getText() + "0";
outPut= outPut.replaceAll("\\s+", "");
outPut=String.format("%, d", Integer.parseInt(outPut));
kiiras.setText(outPut);
}
}Ez a "0" gomb lenne egy számológépben.
Valamiért mintha nem távolítaná el a space-eket a formázott kiírásból.[ Szerkesztve ]
-
fordfairlane
veterán
válasz WonderCSabo #8928 üzenetére
Nem a brancs a nehéz SVN-ben, hanem a merdzs.
x gon' give it to ya
-
floatr
veterán
válasz WonderCSabo #8928 üzenetére
Nem történik másolás Ha neked másolás történt, amikor SVN alatt brancheltél, akkor valamit nem jól csináltál.
Én pont emiatt akadtam össze egy indiai fejlesztőcsapattal, mert korábban nem használtak VCS-t, de az SVN túl sok volt nekik. Minden egyes branch, amit létrehoztak, előzmény nélküli volt, egy teljesen új artifact, korábbi entitásoktól relációmentesen. Azóta is csak tippelek, hogy mi a bánatot csináltak rosszul.
Egy dolog van, ami sebességbeli probléma lehet. Az SVN közvetlenül a központi repository-ban dolgozik, ott hozza létre a bejegyzéseket. Ez ha rosszul van méretezve, lassú is lehet, értsd itt lassú alatt azt, hogy 2-5 másodperc. GIT esetében a saját gépeden lévő repositoryban hozod létre a branchet, amit csak te használsz, nyilván nincsen érdemi hálózati bottleneck, és más júzerekkel sem kell küzdenek a processzidőért. Ellenben ha feltolod a központi repóba, akkor megcsinálja ugyanazt, amit az SVN (nem másolás). Lehet hogy ez gyorsabb valamilyen oknál fogva a GIT esetében (nem 5 másodperc, hanem 2), de erős túlzásnak érzem azt, hogy ez a 2 vs 5 másodperc valakinek probléma.
(#8930) fordfairlane ha valamit elk.tál, akkor elég nehéz tud lenni. De akkor GIT branch/mergenél meg a push a kellemetlen
[ Szerkesztve ]
-
Aethelstone
addikt
válasz WonderCSabo #8933 üzenetére
Részlet az SVN doksiból:
http://svnbook.red-bean.com/en/1.7/svn.branchmerge.using.html
"Subversion's repository has a special design. When you copy a directory, you don't need to worry about the repository growing huge—Subversion doesn't actually duplicate any data. Instead, it creates a new directory entry that points to an existing tree. "
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
WonderCSabo
félisten
válasz Aethelstone #8934 üzenetére
Valoban, ezt en is most olvastam el. Ugy emlekeztem tok szopas volt a branching, lehet ez mar nem igy van... Mindenesetre a szerver komm miatt megis lassabb lesz. A merge-el viszont nagyon sokat szivtunk anno, de most olvasom az is fejlodott SVN-ben az evek soran.
[ Szerkesztve ]
-
Sirpi
senior tag
válasz Chesterfield #8929 üzenetére
A parseInt nem kezeli a belső szóközöket.
Hazudnék, ha cáfolnám annak tagadását, hogy ez az ital nem nélkülözi a koffeinmentesség megnemlétének hiányát. Na most akkor van benne koffein, vagy nincs?!
-
Aethelstone
addikt
válasz WonderCSabo #8935 üzenetére
A merge GIT esetében sem valami leányálom, hiszen a problémát sosem az okozza, ami simán megy, hanem az, amit kézzel kell basztatni. Ehhez meg már semmi köze a verziókezelőnek. Nekem spec. a GIT-es push/pull/commit szarakodás tudja kiverni a biztosítékot, de ez is nyilván ízlés és gyakorlat dolga. Ahogy a kolléga korábban írta, a GIT inkább a sejtszerűen elhelyezkedő fejlesztői csoportoknak kiváló, ahol mondjuk nincs állandó kapcsolat a központi repóval, mert vpn, stb. kell hozzá.
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
floatr
veterán
Első körben tisztázzuk, hogy céges környezetben, céges fejlesztési policy-val nézem ezt az egészet. Nálam a GIT rögtön ott bukik meg, hogy localhost-on van (lehet) olyan munkád a céges projekten, aminek nincsen nyoma a céges/központi repóban. A branch létrehozása egy mozdulat, ha a céges projekteken bíbelődsz valamit, az nem saját kis mitymuty, tessék létrehozni egy branchet akár kísérleti jelleggel a központi repóban, egy hosting/rendszergazda/devops kollégának meg legyen az a dolga, hogy ennek a feltételeit megteremti.
Minden branch minőségbiztosítási okok miatt meg kell hogy legyen központilag, lefedve egy task management rendszerrel úgy, hogy bármikor bárki tudja folytatni, review-olni, vagy épp merge-ölni DEV/UAT/PROD környezetbe.
#8933) WonderCSabo a másolás egy logikai művelet. Ellentétben néhány más rendszerrel, SVN alatt nincsen olyan speciális művelet, hogy branch, mivel nincsen erős kötöttség arra vonatkozóan, hogy a repoban mit hova teszel. Branch-et úgy csinál, hogy egy másik branch (URL) adott állapotáról egy referenciát készít az új URL-en. Meg kell határoznod a saját workflow-dat, hogy milyen elnevezéseket és kötöttségeket használsz. Ez nyilván lehet az eredeti ajánlás szerinti is, bár az csak egy viszonylag egyszerű munkafolyamatra jó.
(#8937) Aethelstone rebase
[ Szerkesztve ]
-
WonderCSabo
félisten
válasz Aethelstone #8937 üzenetére
Kene egy SCM topik. Vagy mar van?
-
nagyúr
> Nálam a GIT rögtön ott bukik meg, hogy localhost-on van (lehet) olyan munkád a céges projekten, aminek nincsen nyoma a céges/központi repóban.
Ez irrelevans, mert a localhoston SVN eseteben is lehet olyan munka, aminek nincs nyoma a ceges repoban. SVN eseteben sem koveted az osszes fajlrendszerbeli valtozast. Szoval egyszeruen felreerted ezt a dolgot.
while (!sleep) sheep++;
-
Lortech
addikt
SVN-nel ugyanúgy lehet olyan munkád, aminek nincs nyoma a központi repóban (egyszerűen nem tolod fel, ha nem akarod), a GIT viszont segít abban, hogy ha ezt akarod, kényelmesen meg tudd oldani, akár központi repóhoz fordulás nélkül, de úgy, hogy commitok (vagy stashben a változások) meglegyenek.
Nálam van, hogy 5+ feature branch között váltogatok napon belül, ha segítek vagy reviewzok kollégáknak. Eközben a saját munkám 1-2..n branchen van, amiket vagy feltoltam a remote-ba vagy nem, nincs jelentőségük, lényeg, hogy az infó megvan, és könnyen tudok váltani köztük. Van egy csomó olyan köztes állapota az elvégzendő munkának, aminek vcs historyban nincs különösebb keresnivalója, mert a végeredmény szempontjából nem hordoz értéket, mégis a köztes állapotnak is meg kell lennie, hogy később vissza tudjak rá váltani, ha folytatom a munkát rajta. Ugyanakkor más számára nem mindig hordoz értéket és így teljesen felesleges a feltöltésével időt vesztenem. A kész feature / javítás / akármi pedig úgy fog visszakerülni a masterbe / egyéb protected branchbe, hogy az csak azokat a commitokat és olyan üzenetekkel tartalmazza, ami a módosítás egésze szempontjából lényeges, és a historyban megőrzendő információ.
Ez nem azt jelenti, hogy nálunk a kollégák 2 hétig a saját kis játszóterükben szórakozhatnak, és ha elüti őket az autó, akkor annyi a munkának. Már csak a CI miatt is sokkal rövidebb életciklusú (vagy folyamatos integráció) branchek szükségesek. Erről git-nél és SVN-nél is le lehet szoktatni őket, ebből a szempontból én nem látok nagy különbséget. Pl. ha látom, hogy kolléga egyik remote branchre sem commitolt egy hete (van róla stat), akkor azért megkérdem, hogy mi a hasfájása.[ Szerkesztve ]
Thank you to god for making me an atheist
-
floatr
veterán
Nekem meg nem irreleváns, mivel a GIT egy eszközt ad a kezedbe arra, hogy személyes maszatolást csinálj anélkül, hogy nyoma legyen. Local history gyakorlatilag a nullával egyenértékű, ha meg mindent betolsz két lépésben, akkor meg csak feleslegesen bontottad ketté a GIT révén a folyamatot. Mindegy, nem akartam nagyon vitába keveredni, de én csak a divatot látom ebben az egészben az esetek 90%ában.
-
nagyúr
> a GIT egy eszközt ad a kezedbe arra, hogy személyes maszatolást csinálj anélkül, hogy nyoma legyen
Arra ad eszkozt, hogy ha epp maszatolni vagy kenytelen, akkor azt ne masok szeme elott csinald. Ertsd: elkezdesz valamit, es fel nap utan rajossz, hogy total rossz irany. Vagy csak valamivel kiserletezel, bejon egy gyors bugreport, amit fixalni kell -- SVN-hasznalok altalaban ilyenkor azt csinaljak, hogy lemasoljak a kiserletuket egy masik konyvtarba :\
En ugy latom, hogy aki SVN-t hasznal uj projekt eseteben, az elsosorban azert teszi, mert nem erti vagy nem probalta meg a modern VCS-eket (tokmindegy, hogy git, hg, vagy mas). Ez eleg radikalis velemeny, tudom. (es nem szemelyes, egyaltalan)
[ Szerkesztve ]
while (!sleep) sheep++;
-
MODERÁTOR
SVN-t és a Gitet is lehet rosszul használni.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
Aethelstone
addikt
Egy szónak is száz a vége, mindenki azt használ, amit
1. akar
2. lehetősége van rá (céges policy pl.)Nagyon szép világ lenne, hogy ha az lenne a legnagyobb problémánk, milyen verziókezelőt használjunk
Ugyanez igaz az Ant/Maven/Gradle/mittomén témakörre is. Ez benne a szép, hogy nem vagyunk Visual Studiohoz kötve
[ Szerkesztve ]
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
-
nagyúr
válasz Aethelstone #8946 üzenetére
Nalunk eleg kritikus pont, mert ugye nincs iroda, 100% remote az egesz ceg.
while (!sleep) sheep++;
-
floatr
veterán
Épp arra próbáltam rávilágítani, hogy nincsen olyan h nem "mások szeme előtt maszatolsz". Nem vagy kénytelen összevissza másolgatni, mert ha létezik olyan a projektben, ami vakvágány, kivezetett branch, akkor azt megfelelő archív helyre mozgatod a repoban. Aki gyors munka miatt marhaságot csinál, azon a GIT sem segít. Épp ezért mondom azt, hogy szvsz egy totális félreértés a GIT hypetrain, ami egy olyan forrásból indul ki, ami bizonyos körökben fel van magasztalva már-már hites meggyőződéssel, és ezért nézem rossz szemmel azt, amikor erről indítanak, mert többnyire (tisztelet a kivételnek persze) fogalmuk sincsen h miért, csak azt látják, hogy "mindenki GIT-et használ". Elég radikális vélemény, tudom, mert a hype-széllel szemben témázok.
[ Szerkesztve ]
-
MODERÁTOR
válasz Aethelstone #8946 üzenetére
+1
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
Aethelstone
addikt
Nem érzem, hogy releváns különbségek lennének a két rendszer (svn, git) között. Én dolgoztam nemzetközi projektben SVN alapokon és 4-5 fős, helyi csapatban is GIT-tel. Mindkettő használható volt, oda kellett figyelni a hülyeségeikre és minden flottul ment. Minden másra ott a Mastercard
MI 10T Pro 8/256 , Arsenal FC - Go Gunnarz...
Új hozzászólás Aktív témák
A topicot kiemeltem. Valaki nem akar egy nyitó hsz-t írni?:))
Állásajánlatok
Cég: Alpha Laptopszerviz Kft.
Város: Pécs
Cég: Ozeki Kft.
Város: Debrecen