Mi a véleményetek a Budapesti Metropolitan Egyetem négy hónapos programozó képzéséről?

Közösségi kerekasztal

Mi a véleményetek a Budapesti Metropolitan Egyetem négy hónapos programozó képzéséről?
http://metujump.hu/
A fiam érdeklődik iránta, de elég borsos az ára és nem biztos benne, hogy milyen eséllyel biztosítanak állást a képzés végén?
http://metujump.hu/?utm_source=lead&utm_medium=hwsw&utm_campaign=masodi…

Esetleg van valakinek tapasztalata velük?

  • 7885 megtekintés

( s_balazs | 2017. 10. 03., k – 11:08 )

Nem ismerem, de az a benyomásom hogy csak lehúzás (bár árat nem találtam az oldalon).

Azt ígérik hogy 4 hónap alatt HTML, CSS, Javascript, Java és néhány ma használatos keretrendszer/eszköz használatát tanítják meg nulláról. Ez valószínüleg abból áll, hogy az oktatás végére a tananyag alapján összeraknak egy darab honlapot és kizárólag az ehhez az egy projekthez szükséges infókat kapják meg a tanulók. Egyszerűen nincs idő ennél mélyebben belemenni, így aztán max arra jó, hogy felkeltse a gyerkőc érdeklődését, de piaci haszna - ahogy ígérik - nem sok lesz, ráadásul holnapra már el is avul a megszerzett tudás (NodeJS, TypeScript, Angular, SpringBoot, stb - ezek ki fognak kopni vagy egy major verzióugrással tök más API-t fognak nyújtani, ezért teljesen értelmetlen dolog az alapok helyett célirányosan ezeket tanítani. Kb mint középsuliban adatbáziskezelés helyett azt mutogatni, hogy az MS Access-ben mit lehet összekattintani).

Mi lenne egyébként a cél ezzel a sulival? Értékelhető papírt nem ad, tudást is csak legfeljebb annyit, mint egy betanított munkás kap. Léteznek ingyenes online kurzusok a neten, azokkal szerintem jobb alapokat lehet szerezni.

Szerk: Megtaláltam az árat és ennyit biztosan nem ér a mega a tudás. Viszont ha feltett szándéka a fiadnak, hogy legalább 6 hónapot lehúz az általuk felajánlott helyen (és nem teszik ki a próbaidő alatt), akkor legalább visszakaptátok a pénzt és még az önéletrajzába is tud referenciát írni. Így talán már érdekesebb a sztori.

Minimum 330 eFt bruttó fizetést ígérő állást ajánlanak a végén. És ez összefügg tandíj a fizetési konstrukcióval.

It mint hirdetés már előkerült, de sok konkrétum nem.
https://hup.hu/cikkek/20170817/betor_a_programozokepzesek_piacara_a_bud…
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox

Ha nagyon hiszékeny akarok lenni, akkor azt tudom elképzelni, hogy saját részre képeznek junior fejlesztőket - ezért is olyan a képzés tematikája, mintha egy álláshírdetésből lenne kimásolva az elvárások/előnyök rész. Így abban az esetben ha pályakezdőként megfelel egy ilyen betanított munka, amiben idővel azért tovább lehet fejlődni, akkor kezdésnek tényleg lehet egy alternatíva. A 330.000 Ft-tól nem kell azért hasra esni, pár év gyakorlattal rá lehet duplázni bárhol.

Viszont azt a forgatókönyvet sem lehet elhanyagolni, hogy esetleg nem kap a fiad állást és akkor buktad a befizetett pénzed felét (mert ugye csak a felét adják vissza), azaz 600.000 Ft-ot. Na ennyit nem ér szerintem a megszerzett tudás.

Minél többet nézem, annál inkább az a gyanúm ,hogy egy konkrét projektre, ami már fut, vagy nemsokára indul, képeznek ki embereket, a csak az adott munkához kellő tudással.
Ez persze nem baj, így tényleg garantálva van az elhelyezkedés, meg ha a projekt jó/érdekes, akkor nem kidobott tudás a fenti tanfolyam, és utána a projekten való munka...

Úgy tudom, hogy van több olyan cég Magyarországon, akik felvesznek kezdőket, és megtanítják őket programozni, aztán pedig projektekre teszik őket.

Úgy tudom, hogy ezért nem pénzt kérnek, sőt, fizetést adnak az embernek. Feltételezem, alá kell írni valamit, hogy a tanfolyamért cserébe 1 évig vagy akármeddig nem lép az ember ki a cégtől.

Azt nem tudom, hogy abszolút 0-ról tanítanak-e, vagy mi az elvárt alap. Feltételezem, vagy hobbi programozókat, vagy egyetemen fél éven keresztül kitanított programozókat képeznek tovább.

( persicsb | 2017. 10. 03., k – 11:16 )

LOL.
"1.290.000 Ft + ÁFA"
Ennyi pénzt sokkal értelmesebben is el lehet költeni.
Még két-három félév egyetem is többet ér szakmailag, mint ez a szar.

Ja, ilyen ar mellett mar vicces a munkahely garanciajuk, ha nem is sikerul elhelyezniuk, ennek a felet megtartva meg mindig kurvasokat keresnek. Olyan, mintha felpumpalnak az arat, hogy be tudjak vallalni a garit.

----------------------
"ONE OF THESE DAYS I'M GOING TO CUT YOU INTO LITTLE PIECES!!!$E$%#$#%^*^"
--> YouTube csatornám

Ha nem jó a nappali, mert dolgozol már, akkor ma a távoktatás forma népszerű (az esti képzés megszűnt). Szerencsére igen sok műszaki felsőoktatási intézmény indít nappali képzés mellett távoktatási formában is BSc képzést, csak el van dugva a honlapjukon.
Ezek a képzések ugyanúgy államilag támogatott képzések (ingyenesek), és szintén 7-8 félév hosszúak, a végén pedig ugyanúgy normál főiskolai (BSc) diplomát adnak.

ELTE-n levelező képzés csak tanári kiegészítőben van. De más egyetemen biztosan elérhető a levelező formula is.
Ami biztos, hogy Magyarországon bőséges a választék normális állami egyetemeken programozói szakokból. Itt reális idő alatt, és nem 4 hét rapid képzésben millióért, használható tudás szedhető össze. Eddig a GDF-et tartottam a magyar felsőoktatás mélypontjának. De ez a Metropolitan úgynevezett Egyetem mindenben alulmúlja. Pofátlanságban különösen.

A GDF-nek főleg a híre szar. Állítólag már nem, de sokáig az volt a lényeg, hogy a pénz meglegyen, nagyon simán lehetett másokat beküldeni vizsgára magad helyett, stb. Mármint ezt hallottam, egy olyan embertől, aki elég jól megélt abból, hogy az X főiskolán tanulva eljárt a gdf-re vizsgázni.

Illetve hát...
Szóval a magyar IT-s felsőoktatás, pontosabban az ott szerzett papír nem elsősorban az ott elsajátított tudás miatt fontos. Ezek az intézmények egy előszűrést végeznek a munkahelyeknek. Ha valaki egy jó nevű intézményben végzett, arról a leendő munkáltató tudja, hogy a korosztálya egyik legjobb képességű embere volt (hiszen bejutott), képes és hajlandó volt éveken keresztül szopni értelmetlen fasságokkal (hiszen megcsinálta), és - szerencsés esetben - még szakmai tudást is szerzett, na nem az oktatás miatt, hanem főleg annak ellenére.
Na ez nem volt meg a GDF-en.

Logikusan végiggondolva valahol az oktatás erőssége és a kirúgási léc magassága környékén keresendőek az okok. És az első ilyen szelekciós léc végülis a felvételi pontszám. Ha valahol be lehet alacsony képességgel csúszni és nem akarják kirúgni a fizető hallgatóságot, akkor ez azt eredményezi, hogy bizony alacsony lesz az a léc, amiáltal a néhány értékes mellett sok-sok kevésbé értékes végzős kerül ki. Egyúttal indikálja azt a folyamatot is, hogy kevés kivételtől eltekintve az erős felvételi pontszámmal rendelkező miért válasszon kevésbé jóhírű fizetős oktatási intézményt valamely jóhírű állami ösztöndíjas intézmény helyett?

http://www.felvi.hu/bin/content/vonal17a/html/meg/meg_63.html

BME bejutás: 375 pont
Óbudai bejutás: 343 pont
Gábor Dénes bejutás (Budapest): 282 pont a nappali, 280 pont a távoktatás
280 pont alatt senki nem vehető fel hazai felsőoktatási intézménybe.

Nem tudom, hogy mennek manapság a dolgok.

Én 20 éve jártam a GDF-re. Rossz volt a híre. Ugyanezeket mondták, mint amit itt olvasok: nem rúgnak ki senkit, bárki bekerülhet.

Ez mind igaz volt, de ez nem a teljes kép:
- ugyan bárki bekerülhetett, és ugyan senkit nem rúgtak ki, viszont az összes szigorlaton és a diplomavédésen magasan volt a mérce. Semmit nem tudok arról, hogy lehetett-e mást maga helyett beküldeni, sosem próbáltam, de mivel kérték a személyit, azért kétségeim vannak. Nekem az volt a benyomásom, hogy be lehet járogatni, lehet tanulgatni, megértve vagy megértés nélkül sokat magolva előre lehet jutni valameddig de konkrétan elvégezni nem könnyű. Akikkel együtt kezdtem (kb. 10 értelmes ember), azok közül ketten csináltuk végig és kaptunk diplomát.
- összehasonlítva a Kandóval, ahová korábban jártam, a tanárok és a tananyag sokkal magasabb színvonalú volt a GDF-en.

Szerintem ezt a nehéz egyetem jó, mert az a színvonal hülyeséget el kell felejteni. BME-n volt ennek nagy hagyománya, de amennyire hallom, már ott sem nagyon menő ez a szemlélet, a fiatalok mindenképpen mást képviselnek már.

Azért lesz nehéz egy egyetem, mert a tanár megnehezíti, ha a tanár segít akkor akár Analízisből is sokan mennek át.
Ajánlom nézd meg az MIT-s Analízis órákat. Fent van youtube-on. Ott a Prof úgy magyaráz, hogy ne legyen nehéz, és az MIT-re nem mondanád azt, hogy színvonaltalan.

Nézd a dolog másik oldalát is. Melyik előadó vehető rá arra, hogy hajlandó legyen hétvégén is oktatni?
Még gondolatkísérlet szintjén is legfeljebb PhD-sekből lehetne összeverbuválni egy szombat-vasárnap dolgozni hajlandó oktatói gárdát. Az szvsz nem használna a levelezős képzésnek ha csak PhD-s oktatói gárdával érintkeznének. És még az is kérdéses, hogy belőlük összejönnének-e az oktatók szükséges számban.

Miért ne tudnának?
Szerintem te nem vagy képben arról, mit jelent a levelező képzés.

A jogszabály ( https://net.jogtar.hu/jr/gen/hjegy_doc.cgi?docid=A1100204.TV ) szerint háromféle képzési szervezési mód van:
"(1) A felsőoktatásban a képzés, a képzési és kimeneti követelményekben foglaltak szerint megszervezhető teljes idejű képzésként, részidős képzésként, továbbá távoktatásként. "
Ezek közül a részidős képzés kétféle munkarendű lehet:
"(3) A részidős képzés lehet esti vagy levelező képzés munkarendje szerint szervezett képzés. A részidős képzés időtartama - kivéve a szakirányú továbbképzést - a teljes idejű képzés tanóráinak legalább harminc, legfeljebb ötven százaléka lehet. A szakirányú továbbképzés időtartama a teljes idejű képzés tanóráinak legalább húsz, legfeljebb ötven százaléka lehet."
A levelező munkarendű képzésre pedig az alábbi vonatkozik:
"25. levelező képzés munkarendje: olyan oktatásszervezési rend, mely szerint - az érintett hallgatókkal kötött eltérő megállapodás hiányában - a hallgatók tanóráira tömbösítve, legfeljebb két hetenként munkanapokon vagy a heti pihenőnapon az intézményben, valamint a képzés fennmaradó részében a távoktatás módszereinek alkalmazásával kerül sor;"

Azaz a levelező képzést legfeljebb két hetenként, munkanapon vagy szombaton, és a teljes idejű képzés óráinak LEGALÁBB 30%-át kitevően kell megtartani.
Ha egy héten van mondjuk 20 kontaktóra, akkor annak 30%-a 6 kontaktóra, ez a minimum HETENTE, amit le kell oktatniuk levelező képzés esetén.
Ha kéthetente van kontakt, akkor az kéthetente 12 kontaktóra MINIMUM. Ha még ritkább a kontakt alkalom, akkor egy-egy alkalomra még több kontakórának KELL jutnia.

A kötelező gyakorlat nem cáfolat. Feltételezem nem aktív rendőri szolgálat mellett akar valaki esti bsc-n tanulni 12 órás műszakokkal úgy, hogy plusz ügyeleti időben bármikor riaszthatják. Szvsz infós munkák mellett jól lehet tanulni. És olyan is létezik, hogy munkaadói szerződéssel tanul valaki felsőoktatásban. Ilyenkor a munkaidő igazodik az egyetemi órákhoz.
Aminek szerintem értelme lenne, hogy az előadás videók készüljenek és azok akár zárt loginos hálózatból de elérhetőek legyenek. Mint az MIT-nél, sőt ott nem is zárt a rendszer. Persze ebben az a kockázat, hogy a gimi utáni nappalisok előadások helyett "majd megnézzük netről" jelszóval nem járnának be előadásokra. Majd vizsgaidőszakban (jobb esetben még ZH előtt) derül ki, hogy 24 óra alatt kellene 28 órányi előadást rapid megnézni úgy, hogy meg is értsék, plusz még aludni is kellene. Estin viszont valóban hasznos lenne.

kemény jelenlét van az előadásokon vs kötelező gyakorlat nem cáfolat

> Aminek szerintem értelme lenne, hogy az előadás videók készüljenek és azok akár zárt loginos hálózatból de elérhetőek legyenek.
nem. olvasd el a fentebbi linken kisg eszmefuttatását arról, maga az előadás (s annak a felvétele) miért rossz ötlet.

--
blogom

Define "kemény jelenlét"!

Szerintem a gyakorlat pont úgy van megszervezve legalábbis az ELTE-IK-n ahogy azt kisg ideálisnak tartja. Kicsi csoportok, interaktivitás, meg persze ami kimaradt de fontos, folyamatos számonkérés.
Ez a gyakorlat lényege. És a gyakorlat a kérdések és mindenféle interakció helye. Természetesen az előadással kapcsolatban is lehet kérdezni.
Ha egyáltalán nem lenne gyakorlat csak előadás igaza lenne. De mivel van az előbb irt módon, én nem adok igazat ebben neki.

csak szerintem beszélünk el egymás mellett?

kemény jelenlét: az előadás elején körbemegy a jelenléti ív a ~500 hallgató között. az előadás végén kihívnak belőle ~10 embert. aki a papíron rajta van, de személyesen nem tudja bemutatni az igazolványát, az ellen fegyelmit indítanak. ~70%-on kötelező a részvétel.

nagyvonalakban. ha nagyon érdekel, keresd meg a pontosítását, tavaly az összes ELTEs ismerősöm ettől volt hangos.

a kar szerint a hallgatók előadásra-nem-járása a bukás oka, ezért mostantól kötelező bejárni.
--
blogom

a „ne írjon fel a barátod” faékegyszerűségű ellenőrzése.

a VIKen anno ujjlenyomatot kért a terminál véletlenszerűen (s mindenkinek kártyát kellett csippantania az előadás elején-végén), vagy mehettél a könyvtárba személyesen megmutatni magad és az igazolványod.
de a VIK csak a gólyákkal csináltatta ezt, meg beszart az összes terminál, így a rendszert is elengedték néhány év alatt.
--
blogom

Ha azt hiszik, hogy az a kizárólagos ok, akkor azzal én se értek egyet. De azt azért érdemes figyelembe venni, hogy ha "gyakorlaton" kellene elmondani az elméletet is, akkor az mennyi plusz terhelés lenne. kb, durván az oktatói létszám duplája kellene lennie, és akkor is kb elviselhetetlen lenne az óraterhelés. Fáradt, kimerült tanár meg megpecsételné a hallgatók tanulmányait.

Szerintem az sem jó, ha a hallgató csak ott van az előadáson, de érdemes lenne valamennyire értenie is, és legalább gyakorlat előtt elolvasni az előadásanyagot.

Az meg, hogy a hallgatók strébernek tartják a kérdező diákot az a hallgatók bűne. Én mindig azt mondom, hogy kérdezni az órán nem ciki, még ha ált. iskolás anyagba kérdez bele akkor is. A ciki az, ha a zh-n / vizsgán nem tudja. De ezt persze nagyon nehéz elérni, mert középiskolában ez ment.

Lehet számon kérni az oktatón az interaktivitást, ha kb közelharcot kell azért vívni, hogy kérdezzenek. Az interakcióhoz mindkét fél kell. Ha a hallgató nem aktív, csak űl és néz ki a fejéből, akkor nem lehet interaktív oktatást csinálni. Akkor pont, hogy a hallgató teszi akár a gyakorlatot frontális oktatássá. Gyakorlatvezető persze megcsinálhatja, hogy ad órán kidolgozandó feladatot és körbejár nézi, hogy mi a probléma. De erre sok teremtípusban nem, vagy csak nehezen megvalósítható, valamint sok idős oktató van, akitől nem elvárható, hogy egy gyakorlat alatt több km-et gyalogoljon körben a teremben.

( Jason v | 2017. 10. 03., k – 12:56 )

Én eleve az összes ilyen "4 hónapos képzés milliókért"-t elkerülném messze. (met*j*mp, c*dec**l, greenf*x, matrit*l ... you name it)

- Nagyon erősen domain-specific tudás.
- Nagyon-nagyon rövid idő alatti információdömping.
- Munkahelygarancia? Nebasszonfel, képzetlenek sehova se kellenek.

EPAM Academy esetleg, ők maguknak képeznek.

Hogyne kellenének, egyik cégtől előző munkahelyem egy egész osztályt vett. Kirúgva nem lesznek, mert akkor valamelyik managernek felfelé be kéne ismernie, hogy kidobott az ablakon egy valag pénzt, a két éves szerződés végére az értelmesebbje meg simán jobb lesz, mint egy közepesen lusta frissdiplomás.

> Én is hallom hogy munkaerőhiány van itthon a szektorban, de tényleg a "közepesen lusta frissdiplomás" lett a léc amit meg kell ugorni?
nekem volt olyan egyetemista évfolyamtársam, aki negyedik félév egyetemen se ment át prog2ből (cpp), s mellette egy nemmagyar multinál cpp fejlesztő volt.

egyébként valszeg az a nagy előnye ezeknek, hogy tudnak válogatni előre, és a megrendelő (leendő munkahely) igényére szabni a négy hónapos képzést.
nem kénytelenek a mucsaröcsögei középiskolában középszintű matekot duplázó, GTA-t játszani szerető gyereket felvenni, ha egy egyszerű algoritmus megértése is problémát okoz neki.
és nem kénytelenek az évekkel ezelőtt összeállított tananyagot letolni, csak mert az van akkreditáltatva - én még láttam tavaly Java 1.3-as előadást a BME-n, pl.
--
blogom

Jó, én meg olyanról tudok, aki bevgrafon bukta az egyetemet, közben a magyar demoscene egyik oszlopos tagja (volt).
Tantóbácsinak nem tetszett, hogy a gyerek többet tud, így grafika beadandón mindig meg lett baszarintva.

"tudnak válogatni előre"
Akkor miért kerül a _usernek_ 1M+ forintba? Miért nem a cég fizeti?

> Jó, én meg olyanról tudok, aki bevgrafon bukta az egyetemet, közben a magyar demoscene egyik oszlopos tagja (volt).
félre ne érts, nem akarom azt állítani, hogy az egyetem _csak_ emiatt olyan embereket enged ki magából, amilyeneket, mert minden bemenő ember egy szar motiválatlan valaki.

> Akkor miért kerül a _usernek_ 1M+ forintba? Miért nem a cég fizeti?
Gondolom motiváció, hogy el is végezd, de ez csak egy tipp.
Ha annyira tré vagy, hogy az összes _vizsgán_ átcsúszol kettessel, de egy szaros Hello World-öt nem tudsz megírni egyik tanított technológiával sem, akkor nyugodtan kirúghassanak.

Az egyedüli aggályosság az a „visszafizetjük a befizetett tandíjad felét” lehet, mert ha nagyon megúszós képzést kapsz (napi 1 IT-s, a 20 emberre), akkor aggályos. (ehhez mondjuk ismerni kéne a részleteket, valszeg azért vállalás is van abban a szerződésben az oktatók részéről.)
Én mondjuk akkor nem vállalnám arccal a megúszós oktatásban való részvételt, szóval szerintem a fenti fröcsögés kritika („ennek a felet megtartva meg mindig kurvasokat keresnek”) kicsit alaptalan. Terembérlettel, több IT-ssal, anyag összeállítással, adóval, etc-vel a fele nem biztos, hogy annyira megérős.
--
blogom

"Az egyedüli aggályosság az a „visszafizetjük a befizetett tandíjad felét” lehet, mert ha nagyon megúszós képzést kapsz (napi 1 IT-s, a 20 emberre), akkor aggályos."

Pedig sanszos hogy ilyesmi.
Valaki korábban a fele pénzre 600-at írt, az ugye azt jelenti, hogy 10 jelentkezőre 6 milla tuti van. Tegyél melléjük egy jó oktatót nettó 400-ért (bérköltség <800e), legyen még 300k költség wc-papírra, áramra, fiszemfaszomra, ezen kívül meg használod az intézmény kihasználatlan kapacitását. 2,5 milla profitod máris van.
És ha közülük valaki elhelyezkedik 3 hónapon belül nettó 220-ért (ami annyira nem nagy challenge), akkor +600e fejenként. Ha 10-ből 1 jó, márpedig ennyit nem nehéz elérni, akkor ez 3 milla 4 hónap alatt.
Ezen kívül 4-7 hónapig ingyen használod a befizetett másik 6 millájukat, az se rossz.

"Jó, én meg olyanról tudok, aki bevgrafon bukta az egyetemet, közben a magyar demoscene egyik oszlopos tagja (volt)."
Igaz nem IT, de én meg olyan embert ismerek személyesen, akit idegenforgalom szakon húztak meg 3x szállodamenedzsmentből, miközben családi vállalkozásként egy 4 csillagos szállodát üzemeltetett a Balaton mellett.

Nekem meg az jut eszembe, hogy amikor elkezdtünk főiskolára / egyetemre járni, mennyire úgy gondoltuk, hogy mi már mindent tudunk, mert demókat írtunk, meg ez meg az.

Aztán kiderült, hogy a főiskolán azért mégis tudnak a tapasztalt hobbi programozóknak még újat mondani :-)

Szóval simán el tudom képzelni azt, hogy valaki visz egy családi szállodát, de fogalma sincs olyan dolgokról, amit mondjuk egy nagy szállodalánc irányításáról tudni kéne. Vagy valaki király demókat csinál, és mondjuk penge 3D-s grafikából, de vannak olyan részei a teljes anyagnak, amit sosem használt, nem is tud róla.

Ezek az emberek simán lehet, hogy félvállról vették a félévet, mert úgyis tudom, gondolták, aztán kiderült, hogy a vizsgán mást kérdeznek.

Hogy saját példát mondjak: már nem emlékszem, hogy táblázatkezelés (értsd: Excel) vagy szövegszerkesztés (értsd: Word) tantárgyból bizony az első vizsgám elégtelen lett. Akkor már évek óta használtam mindkettőt, simán úgy voltam vele, hogy jó, hát erre nem kell tanulni. Megcsinálom csukott szemmel.
Aztán nem. Már nem emlékszem, hogy mit kértek, de olyan funkciókat, amiket nem használtam se azelőtt, se azóta.
Második vizsgára jól felkészültem, így az már sikeres lett.

De közben mondhattam volna a haveroknak azt is, hogy pikkel rám a tanár, pedig évek óta Word-ben írok funkcionális specifikációkat a munkahelyemen, meg ez meg az.

"Aztán nem. Már nem emlékszem, hogy mit kértek, de olyan funkciókat, amiket nem használtam se azelőtt, se azóta."

Igazából ez a kurva nagy probléma... persze, utólag lehet mondani, hogy adtak egy szemléletet, lófaszt se adtak, csak elavul balfaszságokat. :)

Sajnos én azt látom, hogy az informatikus képzés végletesen szétszakadt... a piacnak kellenének az érettségi és felsőoktatás közötti technikusi képzések fejlesztőkből, de ilyen nincs. Aztán van az egyetemi képzés, amelyben elavult dolgokat oktatnak szakmában soha nem dolgozott tanárokkal vagy cutting edge dolgokat, amire viszont a piac nem kíváncsi.

Klasszikus egyetem pedig nincs az informatikából... ha például a szakma krémjét akarod megismerni az orvostudományban, akkor megtalálod őket egy egyetemen egy kupacban és az egyetemtől távolodva egyre csökken a szakmai színvonal, minél problémásabb egy eset annál inkább az egyetemek felé navigálják a beteget, mert ott összpontosul a friss tudás. Informatika esetén ez fordítva van, minél közelebb mész az egyetemhez, annál kevesebb kurrens szakértőt találsz meg. Ha van egy problémád, arra nem az egyetemen kapsz megoldást, az egyetem kullog a piac mögött. Alapvetően nem tudom, mivel lehetne ezt megváltoztatni... :/

Van amikor a krém elég csak...

Én se vagyok sajnos egy atom-faszommekkora-pró aminek kéne lennem, de amilyen emberek beesnek ma egy senior dev hirdetésre... néha el se olvasták a leírást. Meg volt aki az interjún szembesült vele (pl. ma), hogy ami ki van írva, AZ a feladat (és ez nem a 1492 buzzword-ös faszlengetős hirdetmény).

( _Franko_ v | 2017. 10. 03., k – 17:03 )

Alapvetően egy létező munkaerőpiaci gap-et töltenek fel egy régóta létező és működő oktatási módszerrel: a technikusi szintet, ami korábban is érettségi utáni 1-2 éves tisztán szakmai képzés volt sok gyakorlattal, csak ilyen képzés jelenleg nincs szoftverfejlesztői vonalon, csak rendszergazdai vonalon. Alapvetően pont arra jó, amire kellenek is a munkás kezek: legyen elég code monkey, akik laza felügyelettel megcsinálják azt, amit a tapasztaltabbak megterveznek vagy elképzelnek. A jelenlegi munkakörök 90 százalékához nem kell egyetemi végzettség és az egyetemen végzettek és cégeknél elhelyezkedők 90 százaléka nem használja az egyetemi tudását, sőt, ki kell néha verni a fejéből az elavult tudást.

Sajnos az egyetemek nem járnak a szakma élén, hanem mögötte kullognak jó pár évvel...

Szerintem is.
Viszont így pont az egyénileg végzett munka készségfejlesztő hatása vész el, szvsz egyetemi kurzuson is sokszor többet ér a gyakorlati oktatásnál az otthon elkészítendő kötelező program(ok), akkor tanulja meg az ember, hogy mire kell gondolni ha nem fordul le a szar...

----------------
Bruce Lee

"az otthon elkészítendő kötelező program(ok), akkor tanulja meg az ember, hogy mire kell gondolni ha nem fordul le a szar..."

Na, pont ezt kell kiverni a frissdiplomás fejéből, hogy mindig mindent egyedül próbáljon megoldani... elmegy egy egyetemre és gyakorlatilag öt éven át arra készítik fel, hogy kussoljon, az az egyetlen jó megoldás, amit a tanár ismer; ezen felül egyedül oldja meg a feladatokat és egyedül szopjon mindennel.

Aztán elmegy egy céghez, ahol persze csoportmunka van, minden tegnapra kell, ezerféle megoldás van és persze lehet változtatni a feladaton is, ha nagy szopásnak néz ki... szóval ott az új ember, aztán forgolódik, mint Travolta, hogy ez mi. Rosszabb esetben minden piszlicsáré szarral heteket szop, mert azt tanulta meg, hogy heteket kell szopni és a just working megoldások helyett jelentéktelen apróságokra is keresi a legjobb megoldást.

Code monkey meg alig van, mindenki csapatvezető meg architekt akar lenni azonnal, mert egyetemi végzettséggel az jár.

> Na, pont ezt kell kiverni a frissdiplomás fejéből, hogy mindig mindent egyedül próbáljon megoldani... elmegy egy egyetemre és gyakorlatilag öt éven át arra készítik fel, hogy kussoljon, az az egyetlen jó megoldás, amit a tanár ismer; ezen felül egyedül oldja meg a feladatokat és egyedül szopjon mindennel.

Wut? Pont azzal szívok én is az egyetemen, hogy ezt hogyan verjem ki a fejükből.

mikor bemegyek az AUT-os szakirányos laborra, s a laborvezető a szemem előtt másolja ki a megoldást a megoldókulcsból (majd viccesen elnevetgél rajta, hogy semmi köze az anyaghoz)
vagy Gajdos/LZ/etc. a fejed levételét, és többszörös kirúgást ígér, ha a _magic_ plágium ellenőrzőjük szerint akár csak beszélgettél is a társaddal a feladatról.

azért a három+ év alatt el tudja venni egy-két kollégád az ember kedvét az egésztől.

ha az egyetemen
- csak szakmailag kompetens emberek tanítanának (minden tiszteletem, de sajnos ez messze nem így van, lásd doktoranduszok kötelező óraadása [1][2])
- átlátható, számon kérhető, megfellebbezhető lenne minden oktatói döntés (vö.: „én magukról különböző eszközökkel a középiskolai felvételi eredményüket is megszereztem, s ez alapján osztottam önöket 12 vagy 45 fős gyakorlati csoportba”)

még lenne néhány ötletem, no...

1: bár a normálisabbja ott is felkészül legalább a gyakorlat anyagból, hogy megoldókulcs nélkül menjen. továbbá bevallja, hogy nem ért hozzá, s bevon egy levelezésbe azzal, aki igen. a többség meg csak hebeg-habog.

2: mégjobb, mikor az eggyel felettem járó BSc-s srác tart (ingyen!) gyakorlatot, s egy kérdésre nem tud válaszolni, mert egy nappal előtte megoldotta közösen az oktatóval a feladatsort.

--
blogom

Oktatóként én láttam a másik oldalt is:

1. Prog1-en mindegy volt, hogy C-t vagy Pascal-t tanítasz, mert pontosan ugyanannyi hallgató bukik meg. (Akkoriban villany még Pascalt kapott, infó meg C-t)

2. Bepanaszolnak a Prog1 előadónál, hogy miért zaklatom őket a komplex számokkal (2. Prog1 gyakon, amikor már tudták mi az a a ciklus, csináltunk egy Mandelbrot halmaz rajzoló programot csak azzal a tudással, amit addig már vettek - hogy ne a println("Hello world"); -ön unatkozzanak.)

3. Projektlaboron (kb. az egyetlen értelmes gyakorlat) megy a megúszósdi

4. Vizsgákon a 2-esre optimalizál (pont LZ-nek kiváló grafikonjai vannak erről)

Ettől még a tananyagban (még a mostaniban is) óriási gondok vannak, a teljesség igénye nélkül:
- Prog2 (C++) oktatása teljesen elhibázott - rosszkor, rossz céllal (OOP) tanítják. Kb. olyan, mint azok a videók, ahol Porschéba ültetik a tanulóvezetőt

- Fizikának semmi értelme infón, de legalább elvesz 2 (?) félévet

- Cserébe szoftver technológia oktatása elégtelen (Karlsruhéban 4 féléves tárgy volt)

- Maga az egyetemi előadás mint oktatási módszer egy elavult, mind a hallgató, mind az oktató idejét pazarló eszköz.

Még tudnám folytatni...:)

PS: A digit + a Prog1 (C) anyag kellemes meglepetés volt, amikor legutóbb néztem, ott jól működött a tárgyak reformja.

Úgy hallottam, hogy a német egyetemeken a minőséget próbahallgatóval is próbálják egyengetni, aki egyetemi dolgozóként évek alatt a hallgatókkal együtt végighallgatja a teljes oktatást, aztán ami nem illeszkedik a minőségi képzésbe, rossz az érték/idő aránya vagy rossz a sorrendje vagy bármi javítandót feljegyez, azt a részt tárgyon belül is módosítják. Így a következő évfolyam már a felette járó évfolyam próbahallgatója által javított, jobb minőségű oktatást kap.
Szerintem a makroökonómia és hasonló tárgyak meg lennének gyomlálva rendesen.

Valoban nevetseges volt, amikor megprobaltak elmagyarazni mindenfele haromszogekkel meg egyenesekkel a gorbe alatti teruletet es a fuggveny meredekseget egy pontban a BME-VIK-en.
Azonban (emekeim szerint) a mikrookonomia targyban nagyon sok fontos ismeretet rejtettek el. Neha tul jol :)

A hibat foleg abban latom, hogy megprobaltak egy felev, talan 2.5 kredites targyaba betuszkolni mindent.

Egy egyetemet vegzett mernoknek (vegyesztol az informatikusig) igenis szuksege van tisztesseges elmeleti es foleg praktikus gazdasagi kepzesre, amennyiben nem szeretnek koderszakmunkaskent megoregedni. Nem feltetlen ide ertendo a $subject "egyetem"...

Mikróból nekünk Miskolcon csak előadás volt (közgázosokkal közösen), a közgázosoknak gyakorlat is. Vizsga ugyanaz mindkét társaságnak: írásban elmélet+feladatok és szóbelin ismét elmélet.
Előadáson feladatok maximum érintőlegesen, úgyhogy mentünk konzultálni mi is. Úgy alakult, hogy az adott konzultáción csak műszakosok voltunk, aminek kellően megörült a gyak-vez.: "De jó, hogy mind műszakisok, legalább nem kell elmagyaráznom, mi az a derivált".
Mint kiderült, az akkori közgázosok hozzánk képest gyógymatekot tanultak, azért volt a közgáz 1-be (mikro) belesomva némi matek gyorstalpaló is.

> 3. Projektlaboron (kb. az egyetlen értelmes gyakorlat) megy a megúszósdi
> 4. Vizsgákon a 2-esre optimalizál (pont LZ-nek kiváló grafikonjai vannak erről)

Hm. Szerintem a teljes szofttech oktatás el van baszva abban a formában. Az elején száraz elmélet (amikor még nem írtál ~100 sornál komplexebb dolgot), s semmit nem értettem meg belőle, mert nem láttam a problémákat sem, amikre megoldást nyújtana ez az egész.

Aztán meg ez alapján a nem tudás alapján kéne csinálni egy labort, amiben 4-5 zöldfülűt összeborítanak, hogy csináld.
- nem standard eszközökkel
- ami standard eszköz, ott is oktatás, segítség nélkül
- és borzasztóan széthúzva az egészet
- megfejelve egy adag bürokráciával

Nekünk anno saját teszt frameworköt kellett írni, ami egy kötegfájlban az stdinre küldött adatokat, majd az stdoutot hasonlította össze az elvárttal. Persze javac-vel, kézzel fordítva. Azért ennél voltak kifinomultabb módszerek már 2015-ben.

A verziókezelést hála égnek nem saját eszközökkel (pl.: WinRar) kellett megoldani, de kb. soha senki nem nézett rá arra, amit csinálunk. Volt olyan, akinek egy merge problémát okozott, s ha az összes verziókezelés oktatás annyi, amennyit LZ letolt belőle (nem keresem ki a videót most), akkor nem is csodálom.

Ráadásul a megoldandó probléma szét van húzva 14 hétre, mikor általában egy hétvége alatt lefejleszthető. Annak lenne értelme, hogy egy komplexebb dolgot, féléveken keresztül bütykölgetünk, rotált csapattagokkal, etc. De ennek így, hogy egy hétvége alatt megvagy, majd elfeljted az egészet. Pont az nem jön át, miért kell azt a rengeteg doksit írni. És persze minden hétfőn legyél ott abban a 10 perces időablakban, hogy beadhasd személyesen, mert csak...

na, kisírtam magam.

A többire viszont +1.
--
blogom

Kb. egyezik a véleményünk.

Hozzáteszem, hogy projektlabornál (most nem tudom hogy hívják), gyakvezér függő volt, hogy ki mit tartott fontosnak. Nálam pl. emlékeim szerint JUnit volt az elvárás.

Kis színes: az LZ féle verziókezelés slideok tőlem származnak, amikor 2005-6 magasságában tartottam egy vendégelőadást nála. 2010-ben már erőteljesen ráfért volna a frissítés.

Mára egyébként kikristályosodott az, hogy az egyetlen skálázódó módszer, ha single master van (+ persze bugfix-only release branchok), de csak nagyon sok ellenőrzés (code review, egyre keményedő automata tesztek) után kerülhet be bármi a masterre.

Az összes többi dolog, amit ki szoktak emelni és hosszan vitázni róla (pl. git vs mercurial, 1 vagy sok repó) implementációs részlet, amit meg lehet csinálni jól is meg rosszul is...

A single master módszernek nagyon fontos folyománya, hogy a félkész és production feature-öket is egy kódbázisban kell tárolni, emiatt mögé kell tenni a megfelelően moduláris és konfigurálható szoftverarchitektúrát és build rendszert.

Ez a 3 dolog együtt teszi lehetővé, hogy gyorsan tudjon haladni a fejlesztés, de ne forduljon át az egész gányolásba.

> A single master módszernek nagyon fontos folyománya, hogy a félkész és production feature-öket is egy kódbázisban kell tárolni, emiatt mögé kell tenni a megfelelően moduláris és konfigurálható szoftverarchitektúrát és build rendszert.

ez érdekesen hangzik. azt mondod, hogy a különböző feature branchek létezése szerinted nem helyes?
--
blogom

Vigyázat, hosszú lett. :)

Először definiáljuk a fogalmakat, bár tény, hogy itt a HUP-on sokkal színesebb vita szokott kialakulni, ha ezt nem tesszük meg. :)

Számomra a feature branch egy olyan "long-running" fejlesztői ág, amin egy jelentős méretű fejlesztőcsapat hetekig, hónapokig a mastertől (mainline-tól) elvágva fejleszt valamilyen über-király új feature-t. Ez az, amit károsnak tartok (és az ipari tapasztalatok is ezt mutatják, hogy a skálázódás egyik nagy akadálya, ha ilyen branchokat hozunk létre).

Sajnos a "branch" szó több jelentéssel bír, mivel a verziókezelők egyik funkciója a branchok létrehozása, mint az közismert :)

Az, hogy a fejlesztő csinál a kedvenc verziókezelőjében a következő változtatása számára egy branchot, amit aztán felpushol és egy Pull / Merge Request-hez használ, vagy éppen onnan pushol Gerrit-be szerintem nem "feature branch" a fenti értelemben, hanem a rendelkezésre álló eszközeink normál "state of the art" felhasználása, hiszen pont emiatt használunk elosztott verziókezelőt, hogy a készülő változtatásainkat könnyen kezelhessük egymástól izoláltan.

Annak idején a ClearCase-ben próbálták feloldani ezt a dilemmát, amikor bevezették a Stream fogalmát a Branch mellett, de ez az elnevezés nem terjedt el a szakmában.

Miért káros tehát a long-running feature branch? Nézzük a következő, természetesen kizárólag a képzeletünkben létező történetet.

Adott egy nagyobb termék, aminek az új verziójához jelentős kódmódosításra, refaktorálásra lesz szükség, hogy az új killer feature-t támogassa a rendszer. A szerteágazó változtatások miatt egy long-running feature branchot hoznak létre.

Természetesen úgy indul neki mindenki, hogy majd a masterre érkező módosításokat szépen mergelgetik be a feature branchra. Ez addig működik is, amíg a feature branchon nem túrják át a kódot jelentősen -- de áttúrják, hiszen pont emiatt hozták létre a branchot, hiszen a kis módosítások mehetnének közvetlenül a masterre.

Innentől a mergeljünk a masterről egyre nagyobb kihívás lesz, lelassul a haladás, zuhan a morál (divergáló branchokat szinkronban tartani senki sem szeret). A projektvezető feje elkezd kéken villogni, ahogy csökken a csapat sebessége (a Scrum grafikonokon a napnál is világosabb, hiszen a mergelés nem feature!). A technikai vezető (senior fejlesztő / architekt) egy idő után beadja a derekát: majd visszamergelés előtt egy menetben bemergeljük a master változtatásait.

Ez az a pont, ahol a fejlesztők teljesen felhatalmazva érzik majd magukat arra, hogy a minőségi elvárásokat kicsit könnyítsék: hiába vannak review-k, ha a test coverage csökkenésére vagy a kódban megjelenő hack-ekre az a válasz, hogy majd a visszamergelés előtt megcsináljuk, most haladjunk!

A feature branchon dolgozó fejlesztők nem érzik ugyanazt a fajta (pozitiv) stresszt, mint amikor olyan kódon dolgozol, ami bármikor kimehet élesbe.

Elérkezünk oda, hogy az új feature a branchon nagyjából működik. Természetesen formális system test nem volt rajta, azok a tesztelők a masteren dolgoznak, és nincs is erőforrásuk a feature branchot tesztelni. Nem baj, majd visszamergelés _után_. Merthogy az idő véges, már így is van kisebb-nagyobb (általában nagyobb) az eredeti optimista tervekhez képest.

Tehát megérkezik a parancs: minél hamarabb (ASAP!) vissza kell mergelni a masterre. Jön a masterről mergelés rohammunkában, a remény alapú system teszt (csak nem romlik el semmi!), és megy is vissza az egész masterre.

Ezután, projekt mérettől is függően néhány napra - hétre - hónapra elszabadul a pokol, a master teljesen destabilizálódik, a system teszt csillió hibát jelent, és csak jelentős személyes áldozatok (túlórák) árán lehet újra visszaterelni a fejlesztést a normál ügymenetbe, amíg a következő feature branch meg nem érkezik.

Az ilyen feature branchok nagy csapdája, hogy nem kényszerít rá arra, hogy az új csodafeature-t élesben teszteld, jól elkülöníthető részekre bontsd fel (pl. a korábbi API-t tartsd meg wrapperen keresztül, amíg minden modul át nem állt).

Ez abból a tévhitből is fakad, hogy a verziókezelés a szoftver architektúrától független valami. A valóság ezzel szemben az, hogy a szoftver architektúrája (és build / konfigurációs rendszere) jelentősen behatárolja, hogy a verziókezelés (illetve általában a CM - configuration management) hogyan, milyen eszközökkel valósítható meg.

Pl. részt vettem egy olyan fejlesztésben, ami 5 telephelyen folyt, ClearCase MultiSite alapon, telephelyenként külön branchon. A szoftverben volt 1 db fájl, ami az összes képernyő id-jét tartalmazta. Tehát ezt a fájlt mindenkinek 1000x módosítania kellett. El tudjátok képzelni mi volt ott, minden milestone előtt?

És végül néhány prominens képviselője a single master irányzatnak:
- Linux kernel
- Android
- Google általában (az új belső verziókezelőjükben: "branching is possible but discouraged")
- Facebook
- Windows (amennyit tudni lehet róla)

Ja, nem, a feature branch azt jelenti, hogy van egy taskod, és azt egy külön branchen csinálod, tesztel(teted jenkinssel, etc). Pl. "legyen egy gomb a termékeknél, ami instant 20% kedvezményt ad rá, 3.14 órára". Ez egy fícsör. Na ezt nem a masteren fogod.
Ha nagy a szar, az már epic inkább, abból leágaznak ugye a sztorik, (már persze kinél hogy) és az alatt fícsörözöl.
Oké, láttam már ennek ellentétét is XD

"Ez abból a tévhitből is fakad, hogy a verziókezelés a szoftver architektúrától független valami. A valóság ezzel szemben az, hogy a szoftver architektúrája (és build / konfigurációs rendszere) jelentősen behatárolja, hogy a verziókezelés (illetve általában a CM - configuration management) hogyan, milyen eszközökkel valósítható meg."

Ahja. És bónuszban ehhez hozzájön, hogy mondjuk a Git ebből a szempontból nem verziókezelő, hanem egymástól függetlenül verziózott fájlok halmaza, amelyet ráadásul jelentősen megkavar az elosztott jellege. Jellemző szopás, amikor próbálnak valami release folyamatot kialakítani Git alapokon és köré kell építeni egy hatalmas adminisztrációs bürokráciát, hogy senki ne tudja könnyedén eltoszni.

> És bónuszban ehhez hozzájön, hogy mondjuk a Git ebből a szempontból nem verziókezelő, hanem egymástól függetlenül verziózott fájlok halmaza,
Ez egyre érdekesebb ez a topic. Kifejtenéd ezt, kérlek? Mi az, ami verziókelezőbb a gitnél, s a git miért nem az?
Ty!
--
blogom

Nincs szerintem egzakt definíció, én azt mondanám, hogy egy verziókezelőnek kell legyen ACID szerű működése, de a Git esetén nincs ilyen... ez ugyanúgy ad egy csomó dologban előnyt, mint a NoSQL az RDBMS-hez képest, de ad egy csomó hátrányt, amikor inkább RDBMS kellene NoSQL helyett, de erőltetve van a NoSQL, csak azért, mert az cool és fancy.

Mondjuk ilyen lehet egy adott időpontra visszaállni és abban mondjuk hibát keresni, mert valahol az a release fut. És Git esetén előfordul, hogy valaki beletett egy módosítást a local repójába, ott kicsit pihentette, készült egy build egy másik repóból, kiment mondjuk fejlesztői környezetbe, majd ezek után emberünk csinált egy remote push-t vagy pull-t és ha hibát keresnél, akkor azt látod, hogy valami nem stimmel. Oké, distributed rendszer, ilyen... de nem lehet az egész repót mindig tag-elni.

Láttam már olyat is, hogy a local commit dátummal játszott a fejlesztő, mert valami elbaszott és próbálta takarítani a nyomokat... jelentős bizalom kell a push engedélyezéséhez. Ha meg ez nincs meg, akkor a pull jelentős adminisztrációs teher tud lenni.

Nem véletlen az a sok szűkített frontend és workflow, ami Git elé tehető, hogy az ember ne csináljon véletlenül hülyeséget... sajnos a fejlesztők nagyon-nagy része nem Linux kernelfejlesztő, annak megfelelő fegyelemmel, hanem eléggé balfasz tud lenni.

van olyan verziókezelő, ami tudja ezt (meg még a szokásos néhány dolgot) OOB?

Szerintem ez annyira nem gáz - kb. bárhova tévedek a világban, a git alapjai ugyanazok - a workflow-t meg megbeszéljük/elmondják helyben.
Sokkal rosszabb lenne, ha mindenki a saját worklfow-jához írna, íratna saját verziókezelőt, aminek a nyűgjeit lehet megint megismerni.

S kb. bármilyen megoldás hozná azt a plusz adminisztrációs terhet, amit lent említesz, imho.
--
blogom

Ezért jó a Gerrit (vagy akár Github / Gitlab), mert ott ha jól van beállítva, akkor nem tud agyatlanul pusholni. Gerriten pl. kizárólag refs/for/branchneve virtuális branchra pusholhat, és ott is csak oda, ahova joga van. A pushból pedig a Gerrit changeseteket gyárt, és már lehet is reviewzni.

Trükközés a historyval meg egyéb nyalánkságok kizárva.

"Ezért jó a Gerrit (vagy akár Github / Gitlab), mert ott ha jól van beállítva, akkor nem tud agyatlanul pusholni. Gerriten pl. kizárólag refs/for/branchneve virtuális branchra pusholhat, és ott is csak oda, ahova joga van. A pushból pedig a Gerrit changeseteket gyárt, és már lehet is reviewzni."

Ahja. Ezt viszont behoz egy csomó olyan adminisztrációs terhet, amivel általában senki nem számol, amikor átállnak Git-re.

"Trükközés a historyval meg egyéb nyalánkságok kizárva."

Ahja. Végül is le lehet butítani annyira a Git-et, hogy az már nem Git. Csak akkor meg miért? :)

Attól, hogy a szerveren Gerrit fut, lokálban nyugodtan lehet Git wizardkodni naphosszat. Nem érzem, hogy ez elvenné a Git Wizardok szabadságát.

De (ahogy fentebb írod) a developerek többsége nem Git Wizard...sőt korábban SVN wizard sem volt, pedig ott is lehetett volna akár privát branchokat csinálni, a többség mégsem csinálta, inkább nyavajgott, hogy "de hát nem tudok commitolni, mer' conflict van".

Van ennek egy speciális esete, ami működhet. Egy nagy új verzió fejlesztése előtt azt mondod, hogy akkor a régi verzióban állj, nincs több új feature. Az eddigi master két részre szakad, régi és új master (részletkérdés, hogy melyiket hogy fogod hívni). A régibe még mehetnek apró bugfixek, amiket persze merge-ölni kell az újba, de ez elvileg nem lesz bonyolult, vagy éppen az a bug már nem is fog létezni a másik ágban. Amit az újba fejlesztenek, az már nem megy vissza a régibe. Integrációs tesztekből, környezetből ideiglenesen szintén kettő lesz, de mind a kettőt szépen naprakészen lehet tartani a branchekkel összefüggésben. Aztán ha kész az új feature, a régit lehet dobni (vagy még megtartani szerződés szerint X ideig).

A Google-nél valóban single master van, és szerintem nagyon jól működik. (És meg van spékelve még avval is, hogy monolitikus a repó.)

Ezt, amit itt leírtál, release branchnak is szokták hívni, és az természetesen szükséges, és jól is működik. Leginkább azért, mert a release branchon minimális a commitok száma a masterhez képest, és pont az a cél, hogy csak minimális módosítások legyenek benne, hogy kisebb legyen a mellékhatások kockázata.

Ha a jelenleg (pubikusan) használt state of the art elosztott verziókezelőket nézzük (Git, Mercurial), akkor a minden changeset (ami nálam nem egyenlő a feature-rel, egy feature általában több changeset) saját branchra kerül a verziókezelőben, ami megy fel code review-ra (merge / pull request, gerrit change), és a review során adott esetben lefutnak az automata tesztek is.

Ezt én a normál napi felhasználásnak tekintem, nem feature branchnak.

Feature branch számomra az a long-running branch, ahol sok fejlesztő dolgozik hetekig - hónapok, jelentősen divergálva a mastertől. Ezt tartom károsnak.

Igen, ezért kezdtem úgy fentebb, hogy tisztázzuk ki mit ért rajta. :)

A normál napi fejlesztés részeként létrehozott branchokat, amiket valójában a verziókezelőink korlátaiból fakadóan kezelünk branchként és amit később egy lépésben fogunk reviewzni és mergelni nem szoktam külön feature branchnak nevezni, hiszen a kódreview rendszer ezeket a branchokat kb. eltünteti a többi felhasználó elől és egy changesetbe / pull requestbe csomagolja.

"Na, pont ezt kell kiverni a frissdiplomás fejéből, hogy mindig mindent egyedül próbáljon megoldani... elmegy egy egyetemre és gyakorlatilag öt éven át arra készítik fel, hogy kussoljon, az az egyetlen jó megoldás, amit a tanár ismer; ezen felül egyedül oldja meg a feladatokat és egyedül szopjon mindennel."

Ez valami új probléma lehet mert anno a Schönherzben remekül működött a csapatmunka.

--
Gábriel Ákos

Az egyedül gondolkodás lett volna hangsúlyos, mert sajnos sok a másik véglet is, aki annyira sem önálló, hogy állandóan a másikat basztatja, hogy "szerinted ez jó így?", "én így csinálnám, és te?" és társaival, közben meg a másik sem halad. Az az egészséges, ha az általad emlegetett "hetekig szopás"-ból AZT tanulja meg, hogy egyedül is el tud érni eredményt (még ha nem is annyira szuper mint ha súgott volna a senior), ergo nem kell rettegnie a döntéshozataltól. Nyilván akinek esze van eleinte kér segítséget, de anno dolgoztam olyan kollégával, aki még X hónap után is hárompercenként kért támogatást, mert nem merte a saját logikája alapján elkezdeni a munkát, folyamatosan megerősítésre várt. Állati idegesítő volt.

----------------
Bruce Lee

( dejo v | 2017. 10. 04., sze – 09:26 )

A fiam már levelezik velük. E-mailben folyik a felvételi. :)
Eddig kötelezettségvállalás nincs.
--
Tertilla; Tisztelem a botladozó embert és nem rokonszenvezem a tökéletessel! Hagyd már abba!; DropBox