Főiskolát / egyetemet...

Egyéb

...végeztem.
48% (442 szavazat)
...elkezdtem, de nem fejeztem be (legalább a 3. félévem elkezdtem)
16% (151 szavazat)
...elkezdtem, de nem fejeztem be (nem kezdtem el a 3. félévem)
7% (61 szavazat)
...elkezdtem, jelenleg is hallgató vagyok vagy előreláthatólag szeptembertől kezdek.
17% (153 szavazat)
...nem végeztem, soha nem jelentkeztem.
8% (77 szavazat)
...nincs még érettségim.
4% (34 szavazat)
Összes szavazat: 918

( muczy v | 2011. 06. 29., sze – 08:02 )

Szegeden a programtervező informatikus BSc-t elvégeztem, az MSc-t most csinálom (annak a 3. féléve jön szeptembertől), de ennél tovább nem tervezem menni (pl. PhD).

+1. Én kényszerből választottam a diplomamunkámat, de a mai napig abból élek, hogy ahhoz megtanultam egy hatalmas területet (pont ezért akartam kerülni, mert iszonyú széleskörű téma volt, és 1/20 ennyi munkával is lehet volna 5-öst kapnom)

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Ez miért szomorú? Ezek óriási területek, képtelenség öt év alatt megtanítani. Az egyetemen tanulni tanítanak meg, illetve szemléletet, elveket tanulsz. Lényegében módszertant. Megtanulod, hogyan kezdj neki egy probléma megoldásának. Eszközöket, módszereket kapsz ahhoz, hogy ha képes vagy a feladatot jól megfogalmazni, s lebontani részfeladatokra, akkor ez utóbbiakat meg tudd oldani.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Ha jól csinálja az intézmény, nagyon nehéz puskázni. Nem tudom, ma mi a szokás. Régen is volt, de nem jellemzően. Aki meg magol, az minek megy egyetemre? Jó, mondjuk jogot gondolom elsősorban magolni kell, de műszaki tárgyakat érteni volna jó.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Amikor a HUP-on meg a prog.hu-n jelentkeznek a hazival egyenek, hogy akkor most leccilecci, akkor neha ugy elgondolkodok, hogy vajon tenyleg a megfelelo emberek vannak-e a megfelelo szakon, vagy a felet ki kellene rugdosni a francba, hogy menjen inkabb dolgozni. Mert abbol aztan nagyon sokat fog tanulni, ha bemasolja a megoldast. De hat cel a kettes, nemdebar?
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Én fizikus vagyok, de a matematika jelentős részét csak magolni lehet (szerintem ilyen pl a diffgeom attól még totál érheted, sőt....). Pl az analízsi vizsgám egyik tétele úgy kezdődött, hogy Def 1-17. Tény hogy érthetőek, és logikusak, ami segít(het)i a megjegyzést.

------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

+1

Aki azt gondolja hogy az elmult evtizedek osszes tudasat majd o jol megerti (teljes melysegeben) az kvazi vegig akarja jarni az elodok utjanak cirka negyedet (ha a sok sallangot es zsakutcakat levagjuk). Ez kulonosen matematikanal igaz, mert ott nem tudod meguszni azzal hogy "mar elavult". Sok sikert hozza.

Az en tapasztalatom az, hogy az egyetemi tudas 95%-a eltunik 3 even belul, mivel ugysem hasznalod es nem is fogod. Utolag visszanezve banja az ember hogy ennyi ido elment a semmire, de ez eppugy igaz a tobbi iskola szintre is :)

Én fordítva ülök a lovon, dolgozom már vagy húsz éve, de csak két éve járok főiskolára. Ha a jelentkezéskor tudom, amit most, tuti elkerülöm. A suli eddigi egyetlen pozitív eredménye egy-két sorstárs akiket itt ismertem meg. De ennyi sületlenséget, ostobaságot, elavult ismeretet régen láttam összegyűjtve. Erősen megbántam hogy belekezdtem, és most már csak "csakazértis" csinálom végig. A jövő héten rendes, fizetős tanfolyamra megyek a munkahelyem jóvoltából. Egy hét alatt hasznosabb tudásnak leszek birtokában mint a főiskolán két év alatt.

Ave, Saabi.

valahol azert problema van, ha allitolag kozepiskolaban is csak tanulas modszertant tanitanak... akkor mire is vannak az oktatasi intezmenyek, ha jo kapitalista beallitottsag szerint magunknak tanuljunk/oldjunk meg mindent, ok meg csak besegitenek?

[insert line here]
B.C. 3500 - DIY Vehicle / A.D. 30 - DIY Religion / A.D. 1991 - DIY OS

Nem pont az a lényege a diplomamunkának, hogy valamit újat csinálj? Az egyetemi tananyag csak a hátteret/kiindulási alapot adja.

Nálunk, fizikus szakon mindenesetre alapkövetelmény, hogy a diplomamunkával valami új kutatási eredményt érjen el az ember. Aztán abból lehet cikket is írni (nekem is van már egy elfogadott, egy további elbírálás alatt), ami jól jön PhD felvételinél, vagy munkahelykeresésnél.

Szerintem a felsőoktatási intézményeknek nem az a célja, hogy aki oda jelentkezik abba beleverjék a tudást, akkor is ha nem érdekli. Az a középiskola, és az általános. Igen is hulljon ki az oda nem való ember, és ne papírgyár legyen az egyetem. Véleményem szerint egy jó egyetem/főiskola jó szemléletet, és lehetőséget adjon a tanulásra, és ne abban legyen király, hogy mindenkinek papírt ad, és mindent a fejébe akar verni. Azt én tökéletesen természetesnek veszem, hogy egy diplomamunka elkészítéséhez igen is utána kelljen járnod, utánatanulnod, hisz az a szakterületed lesz valamilyen módon. Ergo érdekel, tehát minél többet hozzátanulsz. Szerintem így jó, ahogy van. Ami nagyon hiányzik az oktatásból az a pénz.
------
3 fajta matematikus létezik. Aki tud számolni, és aki nem.

Amikor "ott jártam" őszintén szólva elég kevés ember tekintetéből láttam az értelmet kicsillanni. Hiába ülte az végig az összes előadást/gyakorlatot, annyira volt elég, hogy isteni jegyzeteket készített, amit kitűnően lehetett használni vizsgákra, miután a gépiességből fakadó elírásokat kiszűrte az ember. Nem a fokozat teszi az embert, azabaj, sőt. Egyemista-képzésen én úgy vettem észre, hogy sokkal inkább elméleti a tanulmányok menete -- bár nem kizárt, hogy nem a megfelelő helyről vettem mintát. Az élet ettől függetlenül ad némi visszaigazolást, ami nem teljesen ellentétes, sajnos

par szazalekrol beszeltem, max 10-15. a tobbibol nemhogy az ertelmen nem sut, alapveto problemak vannak. volt, hogy ugy adtak be beadandot, hogy netrol copypastelt kod volt benne (angol kommenteket bennehagyta...), es amikor nem fordult, es kerdeztem, hogy ez a kod mit csinal, csak hummogott. vagy hogy par MSc -s szerint oket az utolso evben mar at kene engedni hiszen mar itt szenvednek 5 eve... kozben az iparhoz koze nincs, hasznalhato tudashoz meg plane, mert minden este party van, meg koncert, meg mozi, otthon leulni, kodolni, az mar smafu.

Az én tapasztalataim pontosan ugyanezt mutatják. Van egy kisebbség, aki azért van ott, mert ezzel akar foglalkozni, és a jól felfogott saját érdekében meg is akarja ismerni minél szélesebb körben a szakterületét, még akkor is, ha egy-egy téma nem mindig a szíve csücske.

Emellett van a hatalmas adag ballaszt, akiről feltételezhető, hogy csak betévedt melegedni, mert messziről sem ugatja az alapokat sem. Persze a gond inkább azzal van, hogy annyira nem is izgatja, csak valahogy legyenek meg a vizsgák. Úgy viszont tényleg WC-papírnak jó a diploma.

Az én egyik kedvenc ilyen sztorim, amikor a programtervező hallgató közölte velem a félév végi javító ZH-környékén (mintegy mentség gyanánt), hogy őt annyira nem érdekli a programozás. :D

Nem sok újat* tanulnál MSc-n, tapasztaltam másik egyetemen első MSc-sként. Viszont már most vannak olyan dolgok állások, pályázatok, egyetemi kutatások amikre csak MSc-vel lehet jelentkezni. BSc-n szinte minden tárgy minden óráján bent voltam, MSc-n meg csak amin muszáj volt. Tanárok egy része támogatta is, hogy dolgozzunk inkább és tartsunk mi is órát a céges tapasztalatainkról a többieknek. Szerintem legyen meg az MSc papír is, még jól jöhet.

*Ez informatikára vonatkozik, mert matekból és (szakirányomból adódóan) villamosmérnöki tárgyakból elég sok újat tanultunk.

( GCS v | 2011. 06. 29., sze – 08:19 )

Sajnos / szerencsére kettőt is végeztem. :-|

( Protezis | 2011. 06. 29., sze – 08:20 )

Hiányzik egy nagyon fontos lehetőség: "Befejeztem, de nyelvvizsga hiányában nem kaptam még meg a diplomámat"

Ezeket az embereket sosem értettem. Előre látható, hogy mikor lesz meg, és előre tudható, hogy kell hozzá nyelvvizsga.

Amúgy az a lehetőség is kimaradt, hogy az abszolutórium megvan, tehát kvázi nem járok oda, de mégsincs diplomám, de nem hagytam ott. Januárban tervezem megszerezni. Nyelvvizsgám meg már mióta van.
----
Hülye pelikán

+1

bar en informatikusoknak az angolt eleve kotelezove tennem (pl. spanyol kozepre nem adnam ki a diplomat nekik angol nelkul)

ellenben noverem nemzetkozi gazdalkodason volt, na ott aztan ment a parasztkodas:
"egy uzleti kozep/felsofok es egy felsofok kell, a felsofok nem lehet angol" (halistennek volt kint Parizsban egy evet, de meg a francia nyelvvizsgarendszer mekkora egy paraszt rendszer)

Szemely szerint en nem voltam rigo utcain, de anyam pl. megszenvedett vele. A fo problema: ketnyelvu vizsga, ez onmagaban sokat nehezit (a tolmacsolas kulon szakma), foleg, hogy nekem sokmindent konnyebb angolul megfogalmazni, mint magyarul (lenyegesen egyszerubb nyelv, es elegge kiskoromtol beszelem, hala szuleimnek). TIT/TELC-en letettem meg kb. 15 evesen a kozepfokot, 17 evesen meg 3%-kal csusztam le a felsofokrol, ott is 25 korul volt akkoriban a vizsgadij (nem tudom mennyit emelkedett, ma 21 vagyok).

Ezenkivul angoltanaraim (kulontanarok, tobb is volt, aki ezt mondta) sorozatosan mondtak, hogy tobben nem mentek at regen kozuluk, akik nagyon vagtak az angolt, es csomo ismerosuk, aki szinte remegve puskazott/lesett a kettesert meg megkapta a nyelvvizsgat (nem reprezentativ minta, de azert eleg sok angol tanar jott hasonlo, de megsem ugyanazzal a remsztorival). AZ angoltanarok ugy fogalmaztak, hogy "nem tartom kiegyensulyozottnak azt a vizsgarendszert".

Amit meg mondanak, hogy erdemes a rigo utcanal, az az alapfok, az allitolag ott a legegyszerubb, de a kozep mar szenvedes

Felsofokokkal meg eleve az a baj, hogy nem csak nyelvtudast nez, hanem titkarnoi kepessegeket is (ez nem csak rigo utca, ez mindenhol) :)

A felsofok mar nem olyan egyszeru a TELC-nel sem :) De kozepbol valoban az a legkonnyebb.

A felsofoknal meg rosszul fogalmaztam, de igazabol a lenyeg, hogy nem eleg onmagaban a nyelvtudas, az nem csak a nyelvtudasrol papir, hanem arrol is, hogy meg tudsz olyan dolgokat csinalni az adott nyelven, ami sokaknak magyarul se megy

Nekem nincs rigós nyelvvizsgám, van nyelvtudásom és van külföldön szerzett diplomám. Amikor honosítani akartam a diplomámat nem fogadták el, mert 1999.11.nn. dátummal állították ki nyelvismereti certemet Angliában, és csak 2000.01.01. -től fogadnak el ilyen papírt idehaza. Nagy bánatomban gyötrődtem amikor felvettek mellém egy kollégát felsőfokú angollal, aki egy mondatot nem tudott elmondani makogás nélkül.

---
http://youtu.be/wzEahz7pa7k

Én voltam sokféle nyelvvizsgán, SZVSZ az a baj a Rigó utcaival, hogy rosszak a súlyozások. Túl sok súly van a nyelvtanon, és túl kevés a kommunikációs készségen. Szóbelin azért nem volt rossz a helyzet, a nyelvtan nem nagyon érdekelte őket, de gondolom ez meg erősen tanártól függ. (Kb. 3 éve voltam legutóbb.)

Egyébként most vagyok a harmadik külföldi munkahelyemen, de nyelvvizsgát még senki sem kért sehol. Csak a különböző magyar felsőoktatási oklevelekhez kérnek, phd-hoz pl. kettőt. Mégis mi a fenének?

különböző magyar felsőoktatási oklevelekhez kérnek, phd-hoz pl. kettőt. Mégis mi a fenének?

Mondjuk egy PhD-vel rendelkező hivatásostól el lehet várni, hogy olvassa a nemzetközi szaksajtót, konferenciákra tudjon járni, eszmét cseréljen, esetleg publikálni legyen képes. Az MSc saccra a belépő szintű kutatói fokozat; ma már ne akarjunk csak magyarul kutatni.

Egyébként most vagyok a harmadik külföldi munkahelyemen, de nyelvvizsgát még senki sem kért sehol

Persze, hogy nem; elég nekik, ha elvégzed a munkádat. A diplomáddal azonban az egyetem tanúsít valamit rólad, a nevét adja a képesítésedhez. Szerintem nem a nyelvvizsga megkövetelése a gáz, hanem az, hogy az emberek egy középfokú C nélkül kezdik meg a felsőfokú tanulmányaikat -- minden továbbtanulni vágyónak már a középiskolában meg kellene tudnia szereznie egy ilyet. (Ehhez gyakran az iskolai feltételek sem adottak, pedig elvileg nem ördöngösség: heti kettő dupla óra, amelyből legalább az egyik dupla óra anyanyelvi tanárral van.)

Mondjuk egy PhD-vel rendelkező hivatásostól el lehet várni, hogy olvassa a nemzetközi szaksajtót, konferenciákra tudjon járni, eszmét cseréljen, esetleg publikálni legyen képes.

Pontosan így van. Pont az a baj, hogy egy nyelvvizsga ezek egyikét sem igazolja, ez a problémám vele.

Egyébként sincs szükség kettő nyelvre, angol elég. Még soha senkivel nem beszéltem a szakmámról németül vagy franciául vagy eszperantóul. Ellenben jópár hónapom ráment a második nyelvvizsgára.

Nyilván semennyire, most éppen ezzel szívok. Viszont, egy évvel államvizsga előtt tudom meg, hogy kell a nyelvvizsga, akkor most diplomám sem lenne. Szóval akkor előny volt, hogy érveltem a tanulmányi és vizsgaszabályzatban foglaltakkal.

Másik dolog az, hogy nem mindenkinek egyszerű megtanulni a nyelvet. Próbáltam. Pont olyan ez, mint a tánc. Azt is próbáltam. Hiába tudom a lépéseket, nem tudom szépen csinálni. Úgy meg semmit sem ér az egész.

Szóval a nyelvet nekem mindig rosszul tanították. Az elején értettem, tudtam követni. Utána viszont megőrült a tanár, már nem magyarázott el mindent részletesen, a többiek bírták a tempót, én meg nem tudtam követni, mert nem értettem, így lemaradtam. És akkor már nem tud az ember bekapcsolódni, fogalma sincs, miről van szó. Talán "érezni" kellett volna. Azt meg hogyan?

Ha tudsz módszert, hogyan tanulhatnék meg angolul, akkor írd!

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

"Ha tudsz módszert, hogyan tanulhatnék meg angolul, akkor írd!"

Beíratkozol egy nyelvvizsgatanfolyamra? Szemfülesebbek eleve vesznek fel nyelvvizsgára készítő kurzust, de az sok esetben kevés, vagy nagyon sok privát utánajárás is kell.

Effektíve megérheti beíratkozni egy nyelvizsgára felkészítő tanfolyamra!

Ha meg sikeresen nyelvvizsgázol, a HÖK visszatéríti neked a nyelvvizsga (csak a vizsga! nem a tanfolyam!) árát. Legalábbis felénk.

Volt kollégám, aki még úgy szerezte a diplomáját, hogy neki nem kellett nyelvizsgáznia. Kiszámolta, ha beiratkozik egy tanfolyamra, rendesen odateszi magát (de legalább azon túl sok plusz utánajárást nem igényel, mint egy bénábban szervezett kurzus esetén), akkor kb. 6-12 hónapon belül visszahozza az árát, ha a közalkalmazott bértáblában nézzük a nyelvvizsga után járó pótlékot. Persze ez "akkori áron" számolva, de gyanítom ma is hasonló lehet az arány.

Nekem volt olyan problémám, hogy megvolt a német nyelvvizsgám, de mivel Németországban csináltam itthon nem fogadták el, és nem kaptam diplomát. Persze honosítottam és így megkaptam, de sajnos ez időbe tellett, mert nincs minden héten felsőfokú honosításra lehetőség...

Szóval sajnos olyan is van akinek megvan a nyelvtudása is és a nyelvvizsgája is, de a rendszer nem fogadja el a papírját...

Bár valóban gyakoribb az, akinek se tudása se papírja...

Mi szamit sikeresnek?

Ha a "tud normalisabb munkat szerezni normalis fizetesert, munkajat normalisan, jol elvegzi, a szukseges dokumentaciot el tudja olvasni szukseg eseten valami egyszerubb levelet ossze tud takolni max egy kis szotarazassal, ha kerdese van vmi forumon" elfogadhato annak, akkor igen, nem kell tul veszes nyelvtudas.

De azzal, hogy tudok 5-10 percnyi bullshitet magyarazni (szoban) valami random bullshit temarol, azzal nem biztos, hogy elorebb vagyok. Perpill angollal ugy vagyok, hogy a kiejtesem katasztrofalis*, de ha egy szakkonyvet el kell olvasni angolul, nem fogok panaszkodni, maximum nehany szot kikeresek a szotarbol.

----------------
Lvl86 Troll

( csabezs | 2011. 06. 29., sze – 08:25 )

Elkezdtem, befejeztem, de még nincs nyelvvizsgám...
(amúgy még a "régi rendszerben" hangszertanár-kamaraművész)

( RaptoR | 2011. 06. 29., sze – 08:39 )

Aktuális a kérdés, épp hétfőn államvizsgáztam. :) Immáron hivatalosan is fizikus vagyok (fizikai anyagtudomány szakirány az ELTE-n).

( taurus | 2011. 06. 29., sze – 08:52 )

Ha minden igaz szeptembertől villamosmérnökin rajtolok, majd meglátjuk befejezem-e.

-------------------------------------------------------------------
Semmi közöm ahhoz, ami aktuális. Az mindig látszat...

( uid_18247 | 2011. 06. 29., sze – 09:08 )

3 év után azt mondtam, köszönöm, ebből a moslékból nekem nem kell több. Nem bántam meg, hogy nem lett diplomám, azzal együtt is valószínűleg pontosan ugyanezt csinálnám, talán 20k-val többért.
------------------------------------
Az 1337-es számú linuxfanboy

+1

Én még 3 év előtt mondtam azt, hogy pápá. Azóta is azt csinálom, amit előtte, és még sokminden mást is. Lehet mondani, hogy nem értek semmihez, jöhetnek a kövek, de aki azt mondja, hogy attól több, hogy beseggel x algoritmust, ahelyett, hogy megértené, hogy hogy kell teremteni, az se érti teljesen az életét. Diákhitel felvétele kihagyva, életunt "szakmai zsenik" szemétkedéseit átélni nem akartam, egy alapjaiban rothadó iparágat tovább görgetni szintén nem.

Megnyugatat a tény, hogy a szavazásban "belőlem" van a legkevesebb. Jelenleg ott tartunk, hogy egy rendszerben, ahol a diploma kezd szinte semmit se érni (már nem etalon, még csak előszűrésnek is felesleges), az alkalmazók jó része kezd valós referenciák alapján munkatársakat keresni. Aki mondjuk nem húzza az idejét, és nekivág pár referenciamunkát csinálni, akár csak saját project-et, akár kispályás vállalkozóként, tapasztalatom szerint hatalmas kapcsolati hálót tud építeni, és szó nélkül képes munkát találni.

Ettől függetlenül későbbiekben tervezem az egyetemi oktatási anyagok egy részének áttekintését, némely tárgyaknál az előadók által írt könyvek nagyon jók.

+1

3. év után búcsúztam önszántamból, gondoltam jobban járok ha hasznosat tanulok. Igazam lett. Ezzel együtt egy jó egyetem alapozó félévei (3-5) felbecsülhetetlenül jól tudnak jönni.
Most pont azt csinálom amit csinálni szerettem volna/szeretek és a velem együtt jó nevű egyetemre jelentkezők, akik közben végeztek 4-5en azt csinálják amit szerettek volna, kb. fele ennyi fizetésért.
Egyáltalán nem bántam meg a döntésemet. A hozzánk jelentkező fejlesztő kollégák interjúztatásai (közel 50-100 ember) és vezetése alapján 2-3 év tapasztalatával azt tudom mondani hogy egyáltalán nem függ a papírtól hogy az adott kolléga mit tud, 50-50%ban váltak be diplomás ill. nem diplomás emberek.

Ezzel együtt pl. olyan orvos kése alá nem feküdnék be, aki nem fejezte be tanulmányait :)

( zolee1988 v | 2011. 06. 29., sze – 09:21 )

kb 3 alkalommal mentem be, levelezős voltam. nem tetszett, ott hagytam :P nem érzem, hogy kevesebb lennék
--
Én TUDOM, hogy igazam van. És ha nincs is, akkor is NEKEM van igazam, mert én vagyok az Admin. Ennyi!

( Celtic v | 2011. 06. 29., sze – 09:29 )

Elkezdtem Pecsen (masfel ev), elkezdtem Obudan (eddig 10 felev), de nem tudom befejezni. Lenne vissza cca. 10 tarygam (szakirany), de a szoftverszigorlat vegleg megfogott, igy most beadom a kerelmet, hoyg bocsassanak el. (Masik lehetoseg, hoyg szeptembertol 50+ ezer Ft-ert felveszem a szoftszigot, de semmi esely ra, igy inkabb feladom)

--
http://www.micros~1

Ahogy a valszámot is. A tanárnak mindegy, hogy a quicksort-ot, a piros-fekete fát és a többi finomságot bemagolod vagy megérted. A lényeg, hogy le tudd írni. Én kb. 2x leírtam a teljes szigó anyagát, a kódokat még többször. Mindenkinek más a taktikája. Hónapokkal előre készülni kell rá, és bár vért kell izzadni, mégis jó hogy így van. A diplomádnak értéke lesz.

---
Informatikai Biztonság Wiki
http://osbuda.hu/biztonsag
https://facebook.com/informatikai.biztonsag

hajajj... en anno assemblybol vizsgan azt a feladatot kaptam, irjak faktorialis szamolot. megirtam, valami ilyesmit:

mov ecx,input
mov eax,1
@: imul eax,ecx
loop @
mov output,eax

a tanar 2 meterrol odapillantott a monitorra es ravagta, hogy rossz. fel ora volt meggyozzem ot arrol, hogy ez mukodik, es azt csinalja, amit kert. kiderult, hogy o oran (amire nem jartam be) valami 20 soros megoldast tanitott...
akiknek gozuk se volt miert mukodik de bemagoltak 1:1-be azok siman atmentek persze...

halozatokbol is kb egyedul irtam 2-es vizsgat, akik bemagoltak az OSI layereket meg minden elmeletet es definiciot azok jobbat irtak, mint en aki akkor mar a suli rendszergazdaja volt ;)

A'rpi

Nem kérdezted, de - nem a "közös" aláírásunk miatt ;) - azt mondom, ne add fel. Ha ennyit szoptál már vele, ne menjen kárba az összes eddigi erőfeszítésed... Fel a fejjel, ma már majd' mindenkinek adnak diplomát... Neked is, csak engedd! (Respect, az én ugyanilyen project-em földbe állt egy külföldi munkalehetőség miatt, és nem tudom, neki fogok-e valaha futni ismét. Nem nekem hiányzik; a piacnak...)

http://www.micros~1

50e, mikozben itt a lakas hitele a nyakamban. Es 50e Ft-ert ugyanannyi eselyem van, mint most, amikor ingyen mentem. De ma sem tudom, hogy
a) keves az esti kozepiskolas matek (valoszinuleg az, hiszen a nappali is az)
b) Csink tanit az ELTEn is, es neha elfelejti, hol is van (valoszinuleg ez is all)

Most elmennek kb. ket felev matek korrepetalasra (nem, nem felsofoku, kozepfoku, kb. a "matekos" gimikben tanitott matek szintje) es 40 evesen egy csomo "izgalmas" dolgot gyomyoszolnek a fejembe algebrabol es geometriabol, akkor lenne eselyem a beugrora. De 10 ev tanulas utan belefaradtam, annyit nem er az egesz, hogy tovabb probalkozzak. (foleg igy, hoyg en is latom, a megfelelo elokepzettsegem hianyzik hozza)

--
http://www.micros~1

Nyilván téged ez nem motivál, de ha egyszer rászánom magam, hogy engedjek a kényszernek, pontosan az általad vázoltakkal kell nekem is kezdenem. A középiskola mellé többet jártam, mint bele, és még benne sem volt senki, aki fel tudta volna kelteni az érdeklődésem a matematika/fizika irányába. Elteltek az évek azóta, és a gondolkodásom is fejlődött, a szemléletem is - de ettől még mindig csonthülye vagyok hozzá, és nem lehet tetőt rakni alap és falak nélkül. Igaz, nekem nincs hitelem - viszont olyan állásom / életem sincs, ami mellé beférne az, hogy ne foglalkozzak semmi mással, csak a - mindennapi munkavégzésemet nem segítő - tanulással... Ahogy mások is, én is a szaktanfolyamokban hiszek inkább, és a certificate-ekben. De a hitem keveseket érdekel az íróasztal/telefon/vacancy másik oldalán. Checkmate.

“We live on a placid island of ignorance in the midst of black seas of infinity, and it was not meant that we should voyage far.” - Howard Phillips Lovecraft

( NagyZ v | 2011. 06. 29., sze – 09:48 )

foiskolai diploma pipa, az egyetemi jovo majus, ha a csillagok is ugy allnak.

( locsemege v | 2011. 06. 29., sze – 12:34 )

Én a BME-n végeztem. Akkor még nem volt MSc meg BSc. Mai terminológiával ez gondolom, MSc lenne. Netről nem lehetett copy-paste-elni az anyagot, hiszen nem volt elterjedt a net Magyarországon. Ahol volt, ott is 33.6 kb/s volt a sebesség. És IBM kompatibilis PC-m sem volt. Volt egy ZX Spectrumom. Azon meg nem volt copy-paste. :)

Nem értek egyet azokkal, akik azt vallják, elég a gyakorlat. Lényegében bármikor kiszúrom, hogy egy elektronikát lelkes, amatőr hobbysta, vagy villamosmérnök tervezett. Tapasztalatból valóban sokat tudnak az amatőrök, de nincsenek tisztában elvi alapokkal, így nem figyelnek a finomságokra. Összetettebb eseteket méretezni sem tudnak, mert hiányzik a tudásukból az az ismeret, amellyel ezt megtehetnék.

Aztán néha látok fórumokon tömény hülyeségeket, amelyeket tűzzel-vassal irtani kell.

Hogy egy hasonlattal éljek, olyan ez, mint egy házat felépíteni alap és koszorú nélkül. Lehet, áll a ház, be is bizonyíthatja az amatőr, hogy így van. Aztán jön egy vihar 140 km/h-s széllökésekkel, s nézzük meg utána is.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

( uid_4263 v | 2011. 06. 29., sze – 13:30 )

Mérnök informatikus bsc -t második nekifutásra úgy tűnik, hogy befejezem (némi egészséges csúszással).
Egy külön szavazást szerintem megérdemelne, hogy akik 2006 óta jelentkeztek valahova mérnök infó bsc -re, hogy is állnak. Meggyőződésem hogy 10-ből 9 ember minimum csúszik...

--
http://neurogadget.com/

Mit értesz a mérnöki szakok szopóra történő belövésén? Amikor még nem volt kreditrendszer, akkor is el lehetett végezni az egyetemet. Nem lehet, hogy arról van szó, hogy élve a tologatás lehetőségével, a végén halmozódik minden, s azt úgy már valóban nem lehet?

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

( Sea-you | 2011. 06. 29., sze – 14:12 )

Nincs, soha nem is terveztem. Ami erdekel megtanulom, ami nem azt nem. Sose szarmazott hatranyom belole mivel tudasalapu a szakma.

Persze, csak nem mindegy a rendszerezés. Irodalom annyi van, mint csillag az égen. Elárulom, az egyetemnek nem az a lényege, hogy hozzájutsz olyan irodalomhoz, amihez nélüle nem. Persze ne olyanoktól hallgass meg véleményt, akik nem járnak be előadásokra. Mellesleg vannak kimeneti követelmények is, és adnak a végén arról igazolást, hogy ezen elvárásoknak megfeleltél.

Szerk.: Mellesleg épp egy hardware-es tapasztalatokkal rendelkezőnek mondod, hogy minden, ami IT, kivéve hardware. <flame> Erre mit mondjak? Á, megvan: amit csinálsz - vélelmezem a hozzászólásodból -, az csak software. ;) </flame>

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Egyetertek, a rendszerezes nem mindegy, ugyanakkor az is igaz, hogy nem kell feltetlenul egyetem ahhoz, hogy megfeleloen felepitve tanulj meg egy adott temat. Kimeneti kovetelmenyek pedig ugyanugy leteznek a munkahelyeden is, ha szorult beled eleg igenyesseg akkor nem fogsz selejtet kiadni a kezedbol. Mivel en kifejezetten nem szeretem ha tanitanak, inkabb azt valasztottam, hogy magam tanulom meg azt ami erdekel. Annal is inkabb, mivel manapsag a legtobb allashirdetes is egyetemi/foiskolai vegzettseget _vagy_ egyenerteku tapasztalatot kovetel, igy nem is feltetlenul szukseges...

helyes a sejtes :) Nem szeretek - es halistennek nem is kell - hardverrel foglalkoznom.

A programozáshoz nem árt némi hardware ismeret. Például ilyet nem csinálunk PIC-en, ha az órajelfrekvencia elég magas:

bsf PORTB, 4
bsf PORTB, 7

Ugyanez LATB-vel már jó lesz. Vagy a kettő közé egy NOP. Esetleg kettő. Ez persze kiderül, ha megnézi az ember a katalóguslapot, a jelterjedési időket, s számol.

tr [:lower:] [:upper:] <<<locsemege
LOCSEMEGE

Szerintem a matek előadások azért nagyon jók is tudnak lenni, az előadó legtöbbször sokkal nagyobb tudású, mint a gyakorlatvezetők, akik néha felsőbbéves hallgatók. Nálunk sokszor élmény volt az előadókat hallgatni. A magas szinvonalú nyugati és amcsi egyetemeken pedig még inkább így van ez.

Jah, nálunk a mateknél előadás ÉS gyakorlat is van mindig (ha jól rémlik), és az a 8 félév analízis Simonnal nagyon nagy élmény volt. Csak gyakorlaton nem lehet mindent megtanulni, ugyanis a gyakorlat lényege egészen más, mint az előadásé. Persze ha szűklátókörű mérnököket képzünk, akiknek nem kell tudniuk a miértet, akkor nem kell az előadás.
----
Hülye pelikán

( foxpaw | 2011. 06. 29., sze – 15:22 )

Mi a helyzet a több diplomára hajtókkal (végeztek+járnak), PhD hallgatókkal, perverz egyetemimádókkal? :-)
---------------
Értelmezési hiba! Elolvassa újra? I/N

Mi a helyzet a több diplomára hajtókkal (végeztek+járnak), PhD hallgatókkal, perverz egyetemimádókkal? :-)

Gyanitom, ha valaki masodik diplomajat, vagy egy diploma letetele utan elkezdett egy doktorit is, akkor mar talan esetleg veletlenul csak-csak szorult mar bele annyi minimalis esz (tudom, eszet nem osztanak egyetemen, de az elvegzesehez nem art), hogy switch-case szeruen vegigmenjen a kerdesen, es tudjon egy egyszeru igennel/nemmel valaszolni arra a rem primitiv kerdesre, hogy

- vegzett-e mar el egy egyetemi kepzest?

Aki masoddiplomajat hallgatja, PhD kepzessel erre nemre valaszol, az szerintem keresse fel vizsgabizottsagat, kedvenc TO-s nenijet/bacsijat, es adja vissza nekik a diplomajat :)

----------------
Lvl86 Troll

( Aadaam v | 2011. 06. 29., sze – 17:02 )

BME-n vegeztem. Felvetelizteto voltam nagyvallalatnal sokaig.

Azok, akik ugy erzik, diploma nelkul nem kevesebbek, az esetek nem elhanyagolhato %-aban olyan kevesek, hogy felfogni se tudjak, hogy kevesek.

De komuvesekre is szukseg van, nem kell mindenkinek mernoknek lenni.

(rant)
A kozhiedelemmel ellentetben a BME-s tananyag nem f.ssag f.ssag hatan, hanem standard cucc, ha atmesz a becsi muszakira vagy a london universityre, felevrol-felevre ugyanezek a targyak mennek, nyilvan az eloadok kvalitasai es preferenciai valtozoak mindig.

Nade, hogy miert hasznos ez:

Szinten a kozhiedelem azt tartja, hogy minden projekt mas-es-mas, es a platformok kulonboznek.

Ez nem igaz.

Konkret pelda: a 90-es evek masodik feletol kialakult a webes rendszerek MVC architekturaja, amibe most nem megyek bele, az, hogy egy webes keretrendszer hogy mukodik, ez standard, sot, nemcsak a webes mukodik igy, de pl. 3d jatekok is.

Volt olyan delikvens, aki idejott, hogy o XY cegnel vezeto fejleszto, o a felelos az architekturaert, amugy van egy ELTE-s diplomaja (sz'al neha nem oszt nem szoroz, igen), kerdezem, nagyon jo, bemelegito kerdes, mi az az MVC. Gondolnad kapasbol. Hat a roviditest nem tudta feloldani. De azt se tudta, mi az a design pattern.

Konkret pelda 2: az egyetemen lenyeletnek veled egy sokevtizedes tapasztalatot arrol, hogy dolgok hogy jonnek egymas utan.

Ezt bevihetjuk edzsajlba, meg iteralhatjuk, meg spiralozhatjuk, de ettol meg alapvetoen ugyanaz marad, a "micsinalunk - hogycsinaljuk - megcsinaljuk - kiprobaljuk - kiadjuk" ciklus _nagyon_ melyen kek beleverve lenni a fejekbe.

Ehhez kepest rengeteg embert latok toporogni, aki nem kepes elindulni egy szoftverrel. Egyszeruen adsz neki egy feladatot es nem tudja, merre induljon vele. A programterv, hat ilyenrol oskolat nem vegzett ember hallani se hallott.

A 95%-a nem tudja sehogy se dokumentalni a szoftvereket (a getBasz - visszaadja a Basz valtozo erteket c. API-kommentekbol generalt HTML-halmaz nem dokumentacio es nem szokott semmifele plusz infot hordozni a fuggveny/valtozonevekhez kepest), akkor se, ha template-et adsz neki oda. Hiaba tanulta, nem tudja megmondani, mi a fontos, es ez nem csak a doksiban fog latszani aztan.

Szoval nem az a baj, hogy nem tudja beirni word-be, az a baj, hogy nem tudja megmondani, mi a lenyeg, meg dolgok hogy epulnek egymasra, csak osztonszeruen potyog, es ettol nem csak az lesz vacak, amit a wordbe gepel, hanem az eclipse-be gepeltet is fecskenyal tartja ossze, nem pedig koherens gondolat arrol, hogy es miert ugy epitunk szoftvereket.

Ennek a kettonek a csunya esete, amikor beepul valami az architekturaba nagyon az elejen, amit senki nem kert. Mert keptelen azt kifejteni, amit mondanak neki, hanem talal egy olyan dolgot, ami szerinte azt fogja eredmenyezni, amit mondtak. Marha nehez kikaparni, es rendszerint - megfeleloen gyenge jellemu vezetessel, marpedig ebbol sok van - orokre bennragad a mocsok a rendszerben.

Szoval ilyenek. Nyilvan az egyetem nem ved, csak ezek a delikvensek, akik ezeket a koszokat belepakoljak a rendszereikbe arra se kepesek, hogy megertsek, miert baj az amit csinalt. Az ilyenekkel pedig inkabb csak a baj van es nem minden pozicioban szeretem oket latni.

Ettol meg okeztam le mosogep-szerelo kislakatos vegzettsegu fejlesztot felvetelin, mert eros mernokokkel egy tehetseges, de kepzetlen programozo tud hasznos munkat vegezni. De ha nincsenek ott az eros mernokok, akkor az a szokasos f.s lesz.
(/rant)

Szvsz ezt erdemes teruletenkent elvalasztva nezni:
- (sw)fejlesztesnel nagyreszt igaz
- uzemeltetesnel mar sokkal kevesbe
- itsecben meg hasznos lehet, amit az egyetemen tanulsz (itsecben kb. barmi hasznos lehet :) ), de iszonyu keves, es altalaban rosszul fokuszalt

--
Fontos feladatot soha ne bizz olyan gepre, amit egyedul is fel tudsz emelni!

Tény, hogy ~10 éve volt, de én németesként megismertem mind a BME, mind az Uni Karlsruhe tananyagát, és míg a BME-n van egy félév PT, addig KA-ban a Software Engineering négy félév. Következő feladat: Keressünk "Übersetzerbau" = Compiler Construction tárgyat a BME kötelező tantervében. Nem, a formális nyelvek nem az.
UKA Formale Systeme -> első előadáson nagyon örültünk, mert mindent tanultunk már a BME-n a "Matematikai Logika" tárgy keretén belül. Ez az öröm egészen az első előadás végéig tartott, ugyanis a BME tárgyon egy félév alatt annyi hangzott el.

Folytassam? :)

Amit ebből ki akarok hozni, az az, hogy nagyon sok tennivaló lenne a BME infó tantervével. Pl. el kéne dönteni, hogy villamosmérnököt képzünk, vagy infóst. Mert sok esetben sajnos két szék között a földre ülés esete forog fent.

Ez persze messzire vezet, és igen, hasznosak tudnak lenni az olyan emberek, akik mindenhez értenek kicsit ÉS _baromi gyorsan beletanulnak bármibe_, de azért az átlag BME infós diplomával rendelkező ember nem ilyen, _és_ a szakterületét sem ismeri rendesen.

Tény, hogy nem követtem az utóbbi pár év tantervváltozásait, de amikor a BSc indult, ott azért nagyrészt a "régi" tárgyak lettek átnevezve / felhasználva, és a BME-ről érkező interjúalanyok nem mutatnak őrületes fejlődést a korábbi tantervhez képest. Pl. még mindig van, aki egyetemen azt tanítja, hogy C-ben nem használunk goto-t, design patternek közül alig tudnak párat, ott is csak a nevüket főleg, egyszerű algoritmusokkal is gondok vannak...stb.

Üdv,
Gergely

PS: Agile & (R)UP-ra még majd visszatérünk :)

Na, megint itt a vallásháború, de nem bánom :)

Én a goto-t C-ben nem kivételkezelésre használom. (Ha jól sejtem, te itt a vízesésszerű, vagy másként, "beskatulyázott", veremszerű hibakezelésre gondolsz, amivel mintegy destruktorokat lehet C-ben csinálni.) Az én stílusom és az általam jelenleg követendő coding style itt szöges ellentétben van -- személyesen az (akár mélyen) beágyazott if-ekben hiszek (és a 2-es mélységű, space-ekből álló behúzásokban, valamint a kötelezően használandó kapcsos zárójelekben).

Mindegyik stílus mellett több érv szól (és persze mindegyikkel vissza is lehet élni). A goto-nál pluszként lehet említeni, hogy (1) az indentáció gyakorlatikag képtelen elszállni, (2) a kilépési fázisoknak neve van (= értelmes label-ek).

A beágyazott, fenti stílusú if-ek mellett szól, hogy (1) a kapcsos zárójelek rengeteg editor-ban lehetővé teszik a közvetlen ugrást a blokk szélei között -- a folding editor-ok be is tudják csukni az egész blokkot, (2) az igazán fontos pont azonban az, hogy a block scope változók láthatóságának végét is explicite tudom szabályozni (ami ugye a static tárolási osztálytól eltekintve egyben az élettartam vége is). A C99 ill. a C++98/C++03 lehetővé teszi, hogy a változót / objektumot olyan későn vezessed be, amilyen későn csak akarod; a láthatóság/élettartam végét azonban ott is csak úgy tudod kijelölni, hogy explicit blokkot (kapcsoszárójeleket) használsz. Ebben az esetben pedig már adott az indentáció, és akkor az if is, a goto pedig nem kell.

A fentiben természetesen az az indíték, hogy a nem file scope változók láthatóságát a lehető legszigorúbban korlátozni kell, a lehető legszűkebb forráskódszakaszra. Az én számomra kritikus fontosságú, hogy egy változó használatának végét is explicite jelöljem. (Ami a jelenleg követendő coding style-omra egyáltalán nem igaz, sajnos.)

Részletesebben egyszer kifejtettem itt:

http://groups.google.com/group/comp.lang.c/msg/4de897c4ba902811?dmode=s…
http://groups.google.com/group/comp.lang.c/msg/637e60376869619e?dmode=s…

A goto (nagyon ritka) felhasználási területe számomra inkább az, amikor sokat lehet vele spórolni, az érthetőség rontása nélkül:

http://groups.google.com/group/comp.unix.programmer/msg/50ecb837eb24015…

Erről jut eszembe egy régi kódom, amikor specifikációból kódoltam egy backtracket sudoku megoldóhoz. Amikor valamihez kellett, eszembe jutott, hogy jé én már írtam egyet, előszedtem, és néztem. Néztem, hogy ez mit csinál, és miért, és mikor írtam én le.
Itt a fő függvény.

bool Backtrack()
{
int tart(-1);
StepForw(tart);

while(81 > tart)
{
do
{
kerul:
++table[tart];
if (':' == table[tart])
{
table[tart]='0';
StepBack(tart);
if (-1 == tart) return false;
goto kerul;
}
} while(!Fit(tart));

StepForw(tart);
}

return true;
}

Sajnos az indentálást nekem lenyeli a code tag.
Szóval próbáltam lerajzolni valamiféle folyamatábrát, de a harmadik újrakezdésnél feladtam.

Ezzel most nem akartam mondani semmit a goto hasznosságáról vagy gonoszságáról, csak gondoltam megosztom.
----
Hülye pelikán

Az eredeti függvény indentálva: 


bool Backtrack()
{
  int tart(-1);
  StepForw(tart);

  while(81 > tart) {
    do {
kerul:
      ++table[tart];
      if (':' == table[tart]) {
        table[tart]='0';
        StepBack(tart);
        if (-1 == tart)
          return false;
        goto kerul;
      }
    } while(!Fit(tart));

    StepForw(tart);
  }

  return true;
}

Itt van átalakítva, goto nélkül, egyetlen return utasítással a függvény végén. Egy plusz logikai változót vettem fel. 


bool Backtrack()
{
  int tart(-1);
  bool match(false);

  StepForw(tart);

  while(!match && 81 > tart) {
    do {
      ++table[tart];
      match = (':' == table[tart]);
      if (match) {
        table[tart] = '0';
        StepBack(tart);
      }
    } while (match && -1 != tart || !match && !Fit(tart));

    if (!match) {
      StepForw(tart);
    }
  }

  return !match;
}

Nem ismerek olyan kifejezést, hogy főbenjáró bűn. Ez az axiomatikus szemlélet, ami szembemegy a mérnökivel. A mérnöknek _elég jó_ megoldások kellenek. Ha megspórol fél órát, és aztán soha többet nem kerül elő, akkor bármit szabad. Ez előkerült utólag, mint érdekesség. Normális kódba én se raknék ilyet, ez csak egy leadandó volt a sok közül.
----
Hülye pelikán

Valóban túl sarkosan fogalmaztam, ezt általában próbálom elkerülni. Egyszerűen nem akartam, hogy úgy tűnjön, ezt a típusú goto használatot preferálom (mivel az egész goto téma az én hozzászólásomból indult). A te indokod is megértem, de ha jól értem amit írsz, akkor megegyezhetünk abban, hogy az idézett kód inkább negatív példa.

Mivel ebben a szálban (sajnos azt kell mondjam, hogy mostanában kivételesen) nem a személyeskedés és az anyázás dominál, hanem kultúrált keretek között szakmai témákról beszélgetünk, fontosnak tűnt, hogy ha valaki kezdő esetleg olvassa, nehogy félreértse, és hibás következtetést vonjon le.

Üdv,
Gergely

En ertem hogy ha valaki kernelt fejleszt, akkor nem bizik meg a fordito optimalizaciojaban, de ettol meg ezt a stilust itt ne reklamozzuk.

Ha egy label-t loop-nak hivnak, akkor szerintem mindketten pontosan tudjuk, melyik language construct-nak kell ott allnia.

Bovebben Dijsktra Strukturalt Programozas c. konyvenek elso reszeben.

Vagy rossz helyre ment a hozzászólásod, vagy én látom rosszul, mire ment válaszként; vagy csak simán nem értem.

Én a saját fennhatóságom alatt álló kódban lényegében sosem használok goto-t. Többnyire ragaszkodom a single exit-hez is. Miből gondolod, hogy a goto-t reklámozom? Csak próbáltam felsorolni néhány érvet, amit a goto-hívők szoktak emlegetni; azért, hogy a hozzászólásom kiegyensúlyozottabb legyen. Ettől én még abszolút strukturáltprogramozás-hívő vagyok (= "goto considered harmful").

... Ja, értem már; az utolsó link alatti kódra gondolsz. Igen, valóban, természetesen, az egy ciklus, azonban a "nagy spórolás" az, hogy a folytatásnak rengeteg feltétele van (a ciklusfeltétel összetett), valamint az egyes részfeltételek kiértékelése között block scope változókat rángatok be. Természetesen át lehet írni "rendes" ciklusra, azonban úgy éreztem, hogy ebben a kivételes esetben 1 db goto-val sokkal tömörebb, ugyanakkor továbbra is érthető kódot lehet csinálni.

"Többnyire ragaszkodom a single exit-hez is."

Szerintem ezt meg fontold meg. Az if-dzsungel btw valojaban ugyanolyan goto mint ami ellen hadakozol, csak nem annyira explicit. A masik, hogy ha egy fuggvenyben pl az elso 5 lepes hibaellenorzes, akkor en celszerubbnek erzem azt hogy:

if (var == null) return;
if (var.bigyo() == null) return;
stb. (eltekintve most attol hogy ezt osszevonhatod akar egy sorba)

mint hasznalni az egymasba agyazott 5 if-et es mire odaersz hogy csinalnal is valamit, mar 5 indent melyen vagy.

Igen, lattam hogy azt irtad "tobbnyire", szoval lehet nem adtam ujat a szalhoz, de ki tudja.

+1 egy az egyben ezt szoktam csinalni, tobb ifes visszateresi ertekes fuggveny egymas utan az if-dzsungel helyett (es nalam is az volt az elozmeny, hogy eltevedtem egy tobbszintes if-else dzsungelben, igy inkabb scratch-bol ujrairtam egy 200 soros kodreszletet, mert nem is volt eppen a legkitesztelhetobb helyen). Remelem nem csak mi csinaljuk igy :)

masik, hogy ha egy fuggvenyben pl az elso 5 lepes hibaellenorzes, akkor en celszerubbnek erzem azt hogy [...] mint hasznalni az egymasba agyazott 5 if-et es mire odaersz hogy csinalnal is valamit, mar 5 indent melyen vagy

Félig egyetértek, és ez valóban egy közkedvelt minta. "Zárjuk ki a problémás eseteket, aztán dolgozzunk tiszta helyzetben."

Nekem ezzel a következő a bajom. Tegyük fel, hogy 5 ilyen vizsgálat van. Jó eséllyel egy-két vizsgálat elvégzéséhez új lokális (block scope) változó(ka)t kell bevezetni. Már csak azért is, mert ha a vizsgálat sikeres, akkor az adott block scope változó(ka)t a függvény későbbi részében valamire használni is akarjuk. Ha az "if-eket előre!" mintát alkalmazzuk, akkor:

  • C89 esetén az összes ilyen változót ki kell hányni a függvény elejére,
  • C99 és egyéb, "kóddal kevert deklarációkat" támogató nyelv esetén a változók bevezetését le lehet vinni ugyan az adott if alá is, a scope végét azonban nem lehet a függvény végénél feljebb hozni.

Ha csak read-only vizsgálatokat végzünk az elején (korai visszatéréshez), akkor jó eséllyel összenyomható egy vagy kettő if-be: 


if (var == null || var.bigyo() == null) {
  return;
}

vagy 


if (var != null && var.bigyo() != null) {
  /* code */
}

és máris nem vagyunk olyan mélyen.

Mindegy, igazából hármas-négyes behúzási szintig közömbös, hogy mit használ az ember.

Utána viszont eljön az a függvény, amiben 10 behúzás kell, és nem, nem lehet szétvágni apróbb függvényekre (erről lentebb). Ilyenkor a két space-es indent-tel könnyedén elférek 80 karakter szélesen továbbra is, a kernel CodingStyle viszont hiába handabandázik:

if you need more than 3 levels of indentation, you're screwed anyway, and should fix your program,

akkor is megszületik a 

radeon_get_atom_connector_info_from_object_table()

, ahol a 80-as szélességből már csak az indentációval kicsúsznak. (Igen, a 80-as szélesség továbbra is fontos, hogy több ablak elférjen egymás mellett.)

Miért nem lehet bizonyos függvényeket szétvágni:

  • iszonyatos mennyiségű lokális változóval dolgozik az algoritmus, amit megvalósít (ilyenkor jönnek néha az ad-hoc "ctx" struktúrák),
  • a logika egyszerűen annyira szétágazó, hogy nem lehet értelmesen vágni, csak ad-hoc módon,
  • ad-hoc vágásnál meg a kódot megérteni vágyó olvasó nem azért szentségel, mert 6 képernyős a függvény, hanem mert 6 mélységű a hívási lánc. (Sok ilyen Java forrást láttam: kicsi osztályok, kicsi metódusok, csak éppen ötmillió van belőlük, és sokkal átláthatatlanabbak együtt, mint egy kilapított függvény.)

Mindenesetre ezekhez nem ragaszkodom a végsőkig; ha a projektnek van kódolási stílusa, akkor azt követem a saját ízlésem helyett. Rant vége :)

Az általam preferált coding style rendelkezik az általad leírt összes előnnyel, és kiküszöböli a te megoldásod hátrányait is. Pszeudókód: 


ResultType func(param1, ...) {
    ResultType result = RESULT_OK;
    // Egyéb függvény scope-ú változók

    LOGV(func, param1, ...); // Bemenet TRACE szintű naplózása, production kódba nem fordul bele

    // Általunk írt kód hívása
    {
        ResultType res = func2(params...);
        if (res != RESULT_OK) {
            LOGE(...); // Hiba log
            result = res;
            goto error;
        }
    }

    // Külső könyvtár hívása, legyen mondjuk open
    {
        LOGV(); // Trace szintu log, külső fgv.hívás paraméterei
        int res = open(...);
        if (res < 0) {
            LOGE(..., res, errno, strerror(errno));
            result = ERRNO2RESULTTYPE(errno); // Hibakód konverzió
            goto error;
        }
    }

    // Itt kezd látszódni az előnye
    if (valami_helyzet_van) {
        if (valami_mas_helyzet_van) {
            if (hiba) {
                result = hibakód;
                goto error; // Bárhonnan a hibakezelő ágra tudok ugrani mint egy exceptionnél
            }
        } else {
            if (meg_mindig_helyzet_van) {
                if (masik_hiba) {
                    result = hibakód;
                    goto error; // Bárhonnan a hibakezelő ágra tudok ugrani mint egy exceptionnél
                }
            }
            // Itt normál esetben lefutó kód van
            ...
        }
    }   
error:
    // A hibakezelő / felszabadító kód egy helyen van
    if (result != RESULT_OK) {
        // Hiba esetén felszabadítandó erőforrások
        // Felszabadítás a foglaláshoz képest fordított sorrendben     
        if (erőforrásN) {
            free(erőforrásN)
        }
        ...
    }
    // Mindig felszabadítandó erőforrások
    // Felszabadítás a foglaláshoz képest fordított sorrendben
    // Általános esetben előfordulhat, hogy a két erőforrásosztályt 
    // nem lehet egymástól független módon kezelni, a gyakorlatban 
    // ez azonban azt jelzi, hogy a függvény túl nagyra nőtt 
    // és fel kell darabolni kisebb részekre.   
    if (eroforrasK) {
       free(eroforrasK);
    }
    ...
    LOGV(..., result); // Kilépés TRACE szintű logja, production kódba nem fordul bele 
    return result;
}

A legfontosabb különbség, hogy egyetlen rollback kód van, egy helyen, mindig az fut le. Emiatt könnyebb karbantartani. Bárhol történik is a hiba, mindig egy lépésben a hibakezelő részre lehet ugrani. Nálad ez olyan esetben, ahol több egymásba ágyazott if-ed van különböző (nem hiba) állapotok lekezelésére, már nem ilyen egyszerű.

Kérem, hogy ne akadjunk fenn az 1 db feleslegesen lefutó if-en a rollback részen, ezt nyilván ki lehet küszöbölni a gyakorlatban, ha szükséges, itt viszont feleslegesen bonyolította volna a példát.

Nyilván, teljesítménykritikus kódrészeknél mindez másképp nézhet ki, azonban teljesítménykritikus kódoknál nem szoktunk erőforrásokat foglalgatni, hacsak nem nagyon muszáj.

Nem állítom, hogy ez az egyetlen jól használható felépítés, de tény, hogy ez nekem jól bevált, többmillió eszközön üzemel probléma nélkül, és a fejlesztések során jelentős időt spóroltunk meg a következetes alkalmazásával más "kontrollcsoportokhoz" képest, akik nem ezt a stílust követték.

Üdv,
Gergely

Ui: Távol álljon tőlem bármilyen háború, pláne vallás...

Két észrevétel:

  1. Itt az
    error

    label alatt látszania kell az összes 

    eroforrasK

    változónak.

  2. Nevezett
    eroforrasK

    változókat a függvény elején mind valamilyen érvénytelen értékre kell inicializálni, ugyanis a hibakezelő kódra ráugorhatunk már azelőtt is, hogy az adott erőforrást egyáltalán megpróbáltuk volna inicializálni. Vagyis ha a felépítés során hiba keletkezik és ugrunk, akkor eldobjuk a meglévő scope-ot, és az érvénytelen init értékekre hagyatkozva állítjuk elő újra ezt az információt (több, egymástól független if-fel).

Ez azonban valóban csak ízlés kérdése, és nem vitatom, hogy a fenti szerkezet nagyon robusztus tud lenni; másoktól is olvastam, hogy bevált számukra.

Ennek a "kisimított" if-es lebontásnak egyébként van egy olyan előnye, hogy a felépítés közbeni ownership transfer-t nagyon rugalmasan kezeli. Például valahonnal előrántunk egy új fd-t (

open()

, 

socket()

, 

pipe()

stb.), erre ráültetünk egy stdio stream-et 

fdopen()

-nel, plusz az eredeti fd-t -1-re állítjuk. A kilapított hibakezelő rész "ingyen" adja a függetlenséget, extra erőfeszítés nélkül tudja vizsgálni, hogy most 

close(fd)

vagy 

fclose(strm)

kell-e (vagy egyik se).

1. Itt az error label alatt látszania kell az összes eroforrasK változónak.
Igen. Ha ez problémát kezd okozni (túl sok erőforrásK van), akkor ez egy jó jelzés, hogy a kérdéses függvényt át kell szervezni, fel kell darabolni.

2. Nevezett eroforrasK változókat a függvény elején mind valamilyen érvénytelen értékre kell
A változók inicializálása valamilyen fix érvénytelen értékre (pl. NULL) szerintem általában is követendő minta.

Példa: Ha a pointereid nem inicializálod NULL-ra, akkor amikor a takarító részhez érsz a függvényedben, nem fogod tudni eldönteni, hogy a pointer értéke érvényes címre mutat, vagy csak a nem inicializált változóban van szemét.

Hogy az IDE aláhúzza-e, az megint egy jó kérdés, én erre nem alapoznék coding style-t. Bonyolultabb kódnál, ahol a preprocesszort használják rendesen, hajlamos azért szétesni. A fordító adhat warningot, de sajnos relatíve kevés a -Werror-t használó projektek száma, tehát jó esély van arra, hogy ez csak egy lesz a sokszáz warning közül, és végül ott leszel majd egy nemdeterminisztikus runtime hibával (pl. ha ez egy nem inicializált fgvpointer).

Persze a legjobb a kettő ötvözete lenne, meg kéne nézni, hogy pl. a Clang static analyzerének meg lehet-e mondani, hogy a deklarációnál történt default érték inicializációt ne vegye figyelembe.

Üdv,
Gergely

Kerdes: es mi van akkor, ha a felszabadito kodreszlet egy #define deklaracio? Tudom, hogy ez a vegen kodtobbszorozes, viszont fel lehet hasznalni a C scope-ok elonyet is, anelkul, hogy nagyon megszivatnank magunkat, mert csak a lokalis valtozokat kell helyben rollbackelni, arra meg lehet fuggveny, vagy scope-lokalisan #define makrot irni.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Hogy tisztazzuk: A Karlsruhe-i egyetem nem koveti az ajanlast, az altalam jelzett harom (TUWien, UL, BME) igen.

Sz'al a kivetelt hoztad peldanak.

Ez nem azt jelenti, hogy a BME tanterve tokeletes, en csak azt mondtam, hogy ez egy standard alapu tanterv, ahol a domainteruletek egyike egyebkent az elektronika, ami nyilvan f.nak se hianyzik, ellenben ebbol van tanero. Lehet rajt vitatkozni.

Nem olyan ember kell aki mindenhez ert kicsit, nem olyan ember kell aki gyorsan beletanul mindenbe: olyan ember kell akinek olyan melysegu ismeretei vannak, hogy nincs mibe beletanulnia, mert a dolgok csak a felszinen kulonboznek.

Nyilvan a legtobb ember fel se kepes ismerni, hogy vannak olyan melysegek, ahol a dolgok mar nem kulonboznek; a masik fele meg az az embereknek, akik keptelenek a melysegi tudast alkalmazni gyorsan a gyakorlatban. En azokkal az emberekkel szeretek dolgozni, akik a ketto kozott vannak, baromi hatekonyan kepesek iszonyat gyakorlatiasan alkalmazni a rendkivul mely tudasukat. Mert ez a jo mernok.


Hogy tisztazzuk: A Karlsruhe-i egyetem nem koveti az ajanlast, az altalam jelzett harom (TUWien, UL, BME) igen.

Erre valami linket kérnék.


Ez nem azt jelenti, hogy a BME tanterve tokeletes, en csak azt mondtam, hogy ez egy standard alapu tanterv, ahol a domainteruletek egyike egyebkent az elektronika, ami nyilvan f.nak se hianyzik, ellenben ebbol van tanero. Lehet rajt vitatkozni.

Nem azt vitatom, hogy standard alapú vagy sem, hanem a "hagyományok" miatt a BME-n feláldoznak értékes időt olyan dolgokra, amiket a végzettek 90+ %-a soha nem fog használni, még elvek szintjén sem. Erre egyébként érdemes lenne valami felmérést végeznie a végzettek között a BME-nek, hogy azt képezzenek amire szükség van.
10 év távlatában szerintem gyenge érv, hogy az oktatók mihez értenek. Ilyen alapon taníthatnának Algolt meg Fortrant is, nem? Ennyi idő alatt megoldható lett volna a tanterv fejlesztése mellett az oktatók képzése is.


Nem olyan ember kell aki mindenhez ert kicsit, nem olyan ember kell aki gyorsan beletanul mindenbe: olyan ember kell akinek olyan melysegu ismeretei vannak, hogy nincs mibe beletanulnia, mert a dolgok csak a felszinen kulonboznek.

Ez nagyon ingoványos talaj: mi az ami még a felszín, és honnan kezdődik, ahol már minden ugyanaz? Pl. hiába tervez valaki egy jó rendszert úgy, hogy ért PHP alapú web alkalmazásokhoz, ha ugyanezt C++-ban kellene megcsinálni, akkor az elvek nyilván ugyanazok, de a "felszín" ismerete nélkül hibás tervezési döntéseket fog hozni -> ismerned kell a szerszámaidat, és gyorsan bele kell tudni tanulni új szerszámok helyes használatába.


En azokkal az emberekkel szeretek dolgozni, akik a ketto kozott vannak, baromi hatekonyan kepesek iszonyat gyakorlatiasan alkalmazni a rendkivul mely tudasukat.

Mivel konstans időd van a tudás elsajátítására, minél mélyebb a tudásod egy adott területen, annál inkább kénytelen voltál fókuszálni rá, és kevesebb egyéb területtel találkozhattál. Itt jön be a gyors tanulás képessége, hogy az alapokból egy merőben új területen is produktív munkát tudj végezni. Erre lehet mondani, hogy a mélyben minden ugyanaz, de a felszíni különbségeket ismerni kell -> folyamatos, gyors tanulás.

Egyébként szerintem kb. ugyanarról beszélünk, csak pont kifordított koordinátarendszerrel.

A TUWien-e itt, picit ateszervezett most ugy nez ki, de hasonlo: http://www.informatik.tuwien.ac.at/lehre/studienplaene/informatik-archi…

(Tegyuk hozza, a TUWien-en kulon van muszaki informatika es software engineering BSc)

A masikat nem talalom :S

Emberekkel beszelgettunk anno 1-2 eve, es vettuk vegig,hogy ki mit, melyik felevben tanul. Kiderult, hogy 1-1 volt az akkori logika. De ennek jopar eve. Az egyik Becsben tanult a masik Londonban, es vagy university of london vagy royal university of london volt a neve.

A tantervek alapjat rendszerint ez a doksi kepezi, az un. SEEK (Software Engineering Educational Knowledge): http://sites.computer.org/ccse/SE2004Volume.pdf

Elvileg a vilag legtobb szoftvermernok kepzesenel figyelembe veszik ezt az ajanlast. Nyilvan a masik, amit figyelembe fognak venni, hogy mibol van tanero.

A diakok altalaban szidjak, de ha megnezed, elolvasod, utolag egy teljesen logikusan osszerakott tanmenetrol van szo.

Az meg, hogy beletanulni vmibe gyorsan es mely ismeretek - ez a ketto nem fugg sosze. Vannak emberek, akik gyorsan tudnak tanulni, es vannak, akiknek mely ismereteik vannak, ezert kevesebb ujdonsag szamukra barmi, ezek bar kepeznek kozos halmazt, nem azonosak.

A nezopont pedig esetunkben - szamomra - nagyon is lenyegi kulonbseg.


Az meg, hogy beletanulni vmibe gyorsan es mely ismeretek - ez a ketto nem fugg sosze. Vannak emberek, akik gyorsan tudnak tanulni, es vannak, akiknek mely ismereteik vannak, ezert kevesebb ujdonsag szamukra barmi, ezek bar kepeznek kozos halmazt, nem azonosak.

A nezopont pedig esetunkben - szamomra - nagyon is lenyegi kulonbseg.

Ezek után nagyon kiváncsi vagyok, hogy te mit értesz mély ismeretek alatt, mert tényleg lehet, hogy nem értünk egyet. :)

Azt tudni kell rolam, hogy en alt. dynamic language architect vagyok, tehat architekt feladatokat latok el, viszont dinamikus nyelvi (python, php, javascript) kornyezetekben, rendszerint nagy webes projekteknel (CDN-ek, sharding, nosql, amit akarsz kb.)

Namost a PHP-ra pl. nagyon jellemzo, hogy relativ gyorsan tanulhato nyelv, nem kezdek el escape-elni hello worldot,mindenki el tudja kepzelni hogy nez ki a PHP-s hello world.

Volt hogy tortenetesen mindenfele infos diplomaval rendelkezo menedzsment valtasnal egyebkent PHP-s rendszert elkezdtek atirni javara.

A gyerekek gyorsan beletanultak, egy baj volt:

modul.jsp:
<%
import jdbc.*
String my_sql_query = "SELECT * FROM .... WHERE ..." +SessionContext.getParam("mittom");
%>

Egy baj van ezzel, hogy ez nem java. Marmint technikailag az, de sz'al nem.

A masik veglet a PHP-ban a 7 vagy 8 absztraktosztaly volt, ezt a PHP annyira nem szereti. Javascriptbe se szeretem amikor C++-nak nezik a rendszert, plane ha az orokles-emulacio nem kifejezetten gyors.

Nyilvan melysegi ismeretek meglete eseten szet tudod valasztani, hogy az adott feladathoz melyek azok a mintak, amiket at kell vinned. Pl. az adat szetvalasztasa a folyamattol nem egy rossz otlet egyik nyelvbe se.

De ez fuggetlen attol, mennyire gyorsan szivod fel egy uj nyelv szintaxisat pl.

OK, akkor mégis (nagyjából) ugyanarról beszéltünk, csak nálam a beletanulás nem azt jelenti, hogy tudom, hogy $-t írok PHP-ban a változónév elé, hanem azt, hogy tudom az adott nyelven hogyan kell implementálni a különböző mintákat, mely minták működnek és melyek nem, tehát az adott környezetben egy adott feladatot hogyan kell megoldani.

Pl., ahogy írod is:
PHP-ban ugye a request scoped természete miatt próbáljuk a beparseolandó és futtatandó kód mennyiségét kezelhető szinten tartani, tehát ha 1-az-1-ben portolunk Java kódot PHP-ra, akkor az jó eséllyel lassú lesz, de legalább használhatatlan. :)

Ugyanakkor (szerintem) DB kezelésnél PHP-ban is és Java-ban is a PDO / PreparedStatement minta a követendő, még az esetleges teljesítményvesztés árán is, mivel sokkal karbantarthatóbb lesz a kód, amit kapunk.

Abban igazad van, hogy ezeknek a felismeréséhez szükség van megfelelő előképzettségre és absztrakciós készségre.

Konkrétan, ha egy jó, professzionális hozzáállású mérnök Java előképzettséggel kerül PHP projektre, akkor szerintem:
- 1-2 nap alatt belejön a szintaxisba
- szerénységet / tiszteletet tanúsít az új platform felé (felismeri, hogy valószínűleg megvolt a tervezési döntés minden funkció mögött, ami ha nem logikus első pillantásra, akkor utánaolvas)
- nem próbálja ráerőltetni a Java patterneket, ugyanakkor nyitott a PHP saját mintái irányába
- meglátja a szépséget az új platformban
- rövid időn belül hatékony, a platformnak megfelelő rendszert tervez, és kódot ír.

Konkrétan, ha egy jó, professzionális hozzáállású mérnök Java előképzettséggel kerül PHP projektre, akkor szerintem:
- 1-2 nap alatt belejön a szintaxisba
- szerénységet / tiszteletet tanúsít az új platform felé (felismeri, hogy valószínűleg megvolt a tervezési döntés minden funkció mögött, ami ha nem logikus első pillantásra, akkor utánaolvas)
- nem próbálja ráerőltetni a Java patterneket, ugyanakkor nyitott a PHP saját mintái irányába
- meglátja a szépséget az új platformban
- rövid időn belül hatékony, a platformnak megfelelő rendszert tervez, és kódot ír.

Na igen, ebben egyetertunk :)

Altalaban a masodik pont szokott hianyozni, ami magaval hozza a harmadik hianyat, es ebbol sok esetben a negyedik nem jon ossze.

Szerintem az == és a === különbséggel semmi probléma nincs, gyengén típusos nyelveknél ez valójában hasznos, és megszokott. Csak tudni kell, hogy mit írsz le az adott nyelven...

Egyébként nem igaz az, hogy PHP-ban nem lehet igényesen kódolni, érdemes megnézni akár a Symphony / Doctrine környékét, akár a Drupal (7+)-t. Sok Javas, C/C++-os projekt megirigyelhetné.

Ha már itt tartunk, mennyi hiba is származik abból, hogy a C-ben az értékadás = és az összehasonlítás == ? Persze, az ember általában nem rontja el, de tegye már fel az a kezét, aki egyszer sem írt véletlen egy if-nél összehasonlítás helyett értékadást két változó közé. Az ellen nem véd a statikus tag előrerakása.

Vagy a másik kedvenc a C-ben a *, mint dereferencia operátor. Különösen aranyos tud lenni egy olyan kód, ahol pointer-pointer dereferenciálás van szorzásokkal megtömve.

Ugye milyen igénytelen a =, := és a ^ ? :)

Egyébként a === -nek is megvan a maga szerepe PHP-ben (és más dinamikusan típusos nyelvben, méghozzá általában a típusbiztos összehasonlítás. Szerintem kicsit kifejezőbb, mint a következő:

if ((gettype($foo) == gettype($bar)) && ($foo == $bar)) { ... }

----------------
Lvl86 Troll

"egyszerű algoritmusokkal is gondok vannak...stb."

:)) Ismerosnel most keresnek .NET fejlesztoket, jelentkezett oda is par erdekes arc. Egyik pl. "Freelancer Silverlight Developer" cimmel jelentkezett, majd mikor szoba kerult, hogy mondja mar el, hogy megis milyen az a preorder es postorder bejaras egy fanal csodalkozott, hogy egyaltalan minek kerdeznek ilyet tole, mert az algoritmusokat ugy is googlerol nezi ki. Vagy a masik, aki az UML-re azt mondta, hogy o csak Visual Studioban tud olyat kesziteni. Bar a primet ketseg kivul egy badogos(!) vitte.

Igaz, a sajat interjuztatasaimrol is tudnek meselni. Kedvencem pl. az a programozotipus, amely ket evig dolgozott valamin, de keptelen elmondani, hogy hogyan epitette fel a kodjat. Masik, aki csak kodot mutatva gepen kepes elmagyarazni ugyanezt.

----------------
Lvl86 Troll

Ifjoncaimnak egy idoben kotelezo volt UML-t csinalniuk. Nagyon egyszeru, megkaptak a ticketet, egy b.ottnagy rendszer karbantartoikent, meg volt adva, hogy milyen tipusfeladatoknal milyen UML nezeteket szeretnek latni, mielott belekezdenek a megoldasba.

Ez foleg azoknal volt requirement, akik teamlead poziciok fele kacsintgattak, de alap volt az, hogy addig ne kezdj implementalni, amig nem tudod eldadogni, mit szeretnel csinalni.

A hasznalando rajzoloprogram Visio volt, windows-only ceg, minden gepen fent, es annyira nem rossz mint amennyire default install volt.

Na, tortent, hogy videki irodaban lead developer beosztasu figura megallt a srac monitora mogott, es megkerdezte: "mi ez a program? visio. Es mit csinalsz benne? UML-abrat. Azt meg minek??"

Sajnos itt tartunk ma, Magyarorszagon, bar mashol is.

ThoughtWorks-os cica elemzest keszit tablanal, valami szoveges-nyilas jelolesrendszerrel. Mondom, mi ez "sajat jelolesrendszerem, ugy talaltam ki". Mondom: "UML sequence diagram esetleg?" "Az UML rossz, nem hasznalom" Nem hiszem, hogy egyaltalan ismeri...

Te nem az IBM-nel dolgozol? Ki is vette meg a rational-t?:)

Sok volt a ganyolas, es valamit ki kellett talalni, hogy ne utolso pillanatban kelljen azon gondolkodni, hogy ezt most visszab.sszuk-e vagy sem, mert a projektmenedzsment a "minden fost a rendszerbe bele" logikan mukodik altalaban. Lehetett mas jelolesrendszert is alkalmazni, de itt azert gyakorlasrol es egyetemistakrol is szo volt.

De nekem kozismerten eros minosegkontrollom van, a legtobb enterprise programozo gyulolni szokott, mert gyorsabban kodolok mint ok, ellenben a kodjaik tobb mint felet visszab.szom.

Nyilvan azert kodolok gyorsabban, mert pontosan tudom mit csinalok, es azert tudom pontosan mit csinalok, mert szarratanultam a modellezest.

Es ezert aztan tudom, hogy lehet jobbat is leadni mint amit ok adnak.

de, ott. van olyan projektjunk, amiben a modelleket rationalbol generaljuk, haaaat.... nem a szivem csucske:)

en altalaban idopocsekolasnak erzem az UMLes bohockodast, mert _ha_ ismerem a codebaset, amit piszkalok, akkor a fejemben megvan a rajz, es az implementacio _jo lesz elsore_ (strukturalisan). nyilvan ehez rutin kell, es ez idovel jon meg, ezt nem kene neked se elfelejtened :)

egy nagy codebasenel, meg ha nem ismeri az ember, az A minuszotos lapra plotterrel tolt UML se helyettesiti az atnyalazast. ;)

Az UML-nek két fő felhasználási területe van szerintem:
- kommunikációs segédeszköz emberek között, hogy ne kelljen minden alkalommal azon vitatkozni, hogy a fekete rombuszban végződő nyíl mit is jelent. Ilyenkor nem cél, hogy a teljes rendszer összes elemét tartalmazza az ábra, hanem hogy a megértést segítse. Nem is szokott azért A0-ás plotter kelleni. A1-es elég :) A toolok is főleg rajzprogramok közül kerülnek ki (Visio, Dia ... stb.), bár korlátozott kódgeneráló képességük ezeknek a tooloknak is szokott lenni.

- MDA / MDD és egyéb "M" kezdetű bűvszavas rendszereknél bemeneti nyelv. Ilyenkor ugye tényleg minden csavart le kell modellezni UML-ben, ami szép nagy modelleket eredményez, amiket ráadásul folyamatosan karban kell tartani, verziókezelni ... stb. Ezek a modellek önmagukban már nem alkalmasak a kommunikációra, mivel elveszik a lényeg -> valakinek le kell gyártania és karbantartania a kivonatolt modelleket, amikről már lehet beszélni. Nem tudom, hogy az újabb Rational termékek mennyire segítenek ebben, a régebbiek nem álltak a helyzet magaslatán.

A gond akkor van, amikor ezt a két területet elkezdik keverni: sokan akkor utálják meg az UML-t.

Persze semmi sem tökéletes, főbb problémák:
- Use case diagram: Azok, akikkel a use case-ekről diagrammok segítségével kommunikálnál (jellemzően nem a fejlesztők, hanem a megrendelő, a marketinges, a PM ... stb.), fogalmuk nincs az UML-ről, tehát felejtős, hogy egy a rendszert jól leíró use case diagrammot (extends, includes, sztereotípiák) megértsenek. Akkor meg minek? Jobban jár az ember ha gyárt színes szagos diagrammokat az Office csomagjában dobozokkal, kis emberekkel, mindenki számára érthető képekkel / ikonokkal.

- Dinamikus viselkedést leíró diagrammok: sajnos a legtöbb fejlesztő ezeket már nem ismeri / nehezen olvassa. Sok esetben a pszeudókód nálam jobban bevált. Emellett bonyolultabb viselkedéseket egyszerűen gyorsabb pszeudókóddal leírni, mint sequence diagrammokat vagy statechartokat rajzolgatni.

Viszont a statikus struktúrák leírására szerintem kiválóan alkalmas, én ötletelésnél papíron is UML-t szoktam rajzolgatni.

Bocsassatok meg, hogy elohuzom a sajat cikkem a kalapbol, tudom, ilyet nem illik:

http://adamnemeth.hu/2009/11/28/architect-dolgok-modellezes-a-gyakorlat…

A dinamikus mukodesnek az a lenyege, hogy tisztabb kodot szokott eredmenyezni a statechart/action flow -ban megrajzolt algoritmus, ill. OOP programozasnal, vagy kliens-szerver (esetleg egyeb halozati) osszehatasnal gyakran elvesznek reszletek a kodban, amit egy sequence diagramm kepes megvilagitani.

Tipikusan sequence diagrammkent szoktuk elmagyarazni pl. az OAuth mukodeset, ezt mar sokszor rajzoltam le.

Masik tipikus eset security tokenek fizetesnel ill. digitalis webshopokban (tehat ahol a termek maga egy fajl)

(Hasonloan "erzed" hogy csunya, ha latod a vonalakat az action flow-ban, mert feltunnek asszimetriak, amik szovegesen nem feltetlen.)

A use case-eknek pedig a szoveges szabalya (aktor ige targy modositok, trigger, precond, postcond) pedig sokkal fontosabb mint a use case diagrammosdi, az UML nem csak diagrammokbol all.

Bocsassatok meg, hogy elohuzom a sajat cikkem a kalapbol, tudom, ilyet nem illik:

Miért ne illene? Az a legjobb, ha már kész, felépített cikket tudsz bedobni az álláspontod alátámasztására.

Én személy szerint nem szeretem túllihegni az UML-t, de a legelső két dolog, amit számomra új, de már létező kód megkóstolásakor kézzel lefirkálok, az egy hevenyészett osztálydiagram ill. szekvenciadiagram. Ezek bármilyen "szintű" kódnál használhatók; olyannál is, ami Java-ra csak úgy fordul valami "még magasabbról", és alkalmazásszerverben fut, és üzleti feladata van; meg olyannál is, ami a Linux kernelben fut. (Például az smp boot-nál megérteni azt, hogy a boot CPU hogyan rugdalja életre a másodlagos CPU-kat, hát ahhoz sok sikert szekvenciadiagram nélkül. A tizenkétszeres mélységben egymásba ágyazott ill. összelinkelt driver / net_device / device struktúrákat is mindig valamilyen ad-hoc osztálydiagrammal támadom meg, tollal, papíron.)

Amikor a futásidejű LR(1) parser generátorommal bohóckodtam, az egész kódolást egy irdatlan osztálydiagram szervezte.

Oh, itt frissdiplomasok meg meg kepzes alatt levoek voltak, es egy 10 eves rendszer atkerulve outsourcingba maintenancre :)

Es igy nem lehet nagyon ismerete a codebase-rol, hanem azt kell eroltetni, hogy mi az ami allando, meg picit erovel fel kell ismertetni a rendszer sajat mintait (meg nincs meg a felismereshez szukseges rutin), es ehhez az UML egy jo eszkoz.

Boochs bacsi ugyanis nem volt hulye. Tovabbi ket kollegajaval nagyon jol raerzett arra, hogy egy ismeretlen rendszer/feladat eseten mi a lenyeges, mit kell abrazolni, es igy, figyelembe venni.

Az UML pedig - kommunikacios nyelv. Fejlesztok kozott, fejleszto-ugyfel kozott, fejleszto-onmaga kozott.

Itt pedig a kod mutogatasa nagyjabol annyit er, mint A- -os lapra rajzolas. Azt mondd meg, mik a lenyegi komponensek, es mi a strukturalis kapcsolat kozottuk, vagy mi zajlik kozottuk. Hogy hogy lehet ezt jol elmondani, annak a nyelve az UML.

Es ezert csinaltak az UML-t, hogy a fejukbe legyenek verve azok a kommunikacios sablonok, amik menten el kell tudniuk magyarazni a hiba okat, vagy a fejlesztes lepeseit, akar nekem, akar kesobb a beosztott programozoknak.

Nem hiszek a generalt orias UML-ekben, az a modellezes meggyalazasa, nem nagyon hiszek a vizualis programozasban sem, nem valtozik attol a helyzet, hogy vonalat huzol fuggvenyhivas (vagy property-hozzaadas) helyett.

Abban hiszek, hogy azok a nezetek, amit az UML definial segitenek abban, hogy elvalasszuk az ocsut a pelyvatol.

Nyilvan en se rajzolok mindig UML-t mikozben kodolok, de barmikor PM jon, vagy meetingre doksit kell csinalni, pillanatok alatt tudom, hogy mi az a 3 lenyeges abra, egyenkent max 10 elemmel (7 az ajanlott), amit fel kell rajznolni tablara / bele doksiba, hogy masodpercek alatt vilagosodjon meg a masik.

Egyvalamit kifelejtettem: az UML-t papíron kellett volna bemutatnia a felvételiző jóembernek, aki "csak Visual Studioban tudja elkészíteni".

"de alap volt az, hogy addig ne kezdj implementalni, amig nem tudod eldadogni, mit szeretnel csinalni."

Egyébként azt vettem észre, hogy egyes kezdő programozóknál, akiknél még nincs meg a rutin, hajlamosak beleesni abba a hibába, hogyha a projekt-menedzsmenttől jön egy sürgős feladat, akkor annak egyből nekikezdenek ahelyett, hogy végiggondolták volna magukban. Csak ugye az, hogy valaki ül egy helyben és csak gondolkodik, az nem jár látható eredménnyel és ezt a projektvezetők annyira nem szeretik. :)

----------------
Lvl86 Troll

A nemszeretik szerintem is tulzas, helyzet- es hataridofuggoen mondjuk a harmadik-negyedik oraban vagy a masodik-harmadik vegiggondolt nap utan szoktam a sraccal leulni egyutt vegiggondolni, de azt gondolom mindenki erzi, hogy ha ket nap alatt nem jutott ertelmesre, akkor valami loket kell. :)

(Ill. helloworldnel orakrol beszelunk.)

De egyebkent pont ez volt a baj, hogy lenduletbol nekiestek, es ezert volt kotelezove teve az, hogy mondjak, el, mit csinalnak.

A nem-UML valtozatban rendszerint MVC alapon volt vegigkerdezve, hogy mely entity-ket, mely service-eket, mely taskokat, mely controller-eket es mely template-eket modositanak, csak ez nem java, hogy az osztalyneve ValamiEntity legyen, ill. nem minden modulban (amit ujonnan irtunk, abban mar igen.)

Tipikusan buntetve volt a javascript generalasa PHP-bol, a keretrendszer nelkuli DOM-piszkalas, a hosszan gondolkodo controllerek, barmifele probalkozas ami versenyhelyzetet eredmenyez a rendszerben, cserebe volt egy 2 oldalas "mit ne", egy 2-3 oldalas "mikor hogy modellezz" meg egy 10 oldalas altalanos guideline, az teli abrakkal, bibliografiai hivatkozasokkal, ha magyarazat kellett.

(Nem volt elvaras a 10 oldalas ismerete; a 2 oldalas bulletlist 14-es betumerettel vegignezese elvaras volt.)

"Hát mert nem halad a kóddal."

Amennyire én tapasztaltam, egy kezdő programozót nagyon könnyű "belestresszelni" a rögtön nekiesek hibába néhány egyszerű kérdéssel (pl. "hogy haladsz?", "nekikezdtél már [kódolni]?" stb.).

A probléma - szerintem - az, hogy a projektvezető is néha olyan, mint egy rossz megrendelő (és az se biztos, hogy van neki elég mély ilyen irányú szakmai ismeretsége, hogy belelásson abba, hogy mégis mit csinál egy kódcsákányoló) aztán számára az effektív munkavégzés az, hogy valaki kódol, mint a gép.

Szóval ilyen szempontból a [projekt]menedzsmentet is le kell néha "rázni", hogy mondják el mi a feladat, egyezzünk meg a határidőkben, aztán mindenki menjen a maga dolgára...

(Egyébként számomra a másik, ami nagyon idegesítő az az, amikor van szintén egy sürgős feladat, látható, hogy mindkét programozó a haját tépi már idegességében, ("mi a faszé' nem működik ez a kib. szarkupac" és hasonló kirohanások :) de azért odaáll mögéjük és 3 percenként óramű pontossággal megkérdezi, hogy "hogy haladtok?"...)

----------------
Lvl86 Troll

(Egyébként számomra a másik, ami nagyon idegesítő az az, amikor van szintén egy sürgős feladat, látható, hogy mindkét programozó a haját tépi már idegességében, ("mi a faszé' nem működik ez a kib. szarkupac" és hasonló kirohanások :) de azért odaáll mögéjük és 3 percenként óramű pontossággal megkérdezi, hogy "hogy haladtok?"...)

Egy ügyfelünknél tapasztaltam, hogy egy rendszerösszeomláskor a fél infós vezetés ott toporgott a rendszergazda mögött és kérdezgette, hogy mi történt, mikor lesz kész, miért nincs még mindig kész...
Az egyik DBA csak nézte, nézte, majd kifakadt és elküldte hangosan az egész managementet a picsába, hagyják azt az embert dolgozni!
Miután az öltönyösök eltávoztak, elmagyaráztuk a rendszergazdák főnökének hogy mi történt és mi fog előreláthatóan történni, miközben a rendszergazda végre nyugodtan dolgozhatott. A főnöke meg kinn elmagyarázta a managementnek, mi a helyzet. Érdekes, így hamarabb helyreállt a béke.

Ave, Saabi.

>Érdekes, így hamarabb helyreállt a béke.

Nyílván mérted, hogy ha hagyjátok hogy cseszegesség a rendszergazdit akkor mennyi az idő, aztán újra elrontottad a rendszert, és kipróbáltad a másik módszerrel, és úgy gyorsabban megjavult. Érzed, hogy hol ebben a hiba?
----
Hülye pelikán

"Hát mert nem halad a kóddal."
Nem a projektmenedzser kompetenciája, hogy megmondja mennyi kódsornak kell elkészülnie egység idő alatt. Meglátásom szerint alapvetően ez a beledumálás azoknak a hibája, akik fejlesztőkből (vagy egyéb tech közeli ember) lettek projektmenedzsernek (vagy projektmenedzser szerűnek) kinevezve, mert nehézkes elszakadni a "rögzült" dolgoktól.

projektvezető is néha olyan, mint egy rossz megrendelő
Akkor neki van egy kis problémája.

aztán számára az effektív munkavégzés az, hogy valaki kódol, mint a gép
Meg még egy kicsi.

[projekt]menedzsmentet is le kell néha "rázni
Az ilyet talán igen, de ez meg nem projektmenedzsment.

3 percenként óramű pontossággal megkérdezi
Ez sem az.

en mondjuk ugye architektnek szoktam inkabb magamat mondani, az viszont teny, hogy a mas platformrol jovo pm neha necces tud lenni...

en buszke vagyok arra, hogy 2-3 orankent ranezek a delikvensre, nem ismerek mas modszert arra, hogy az agyi lefagyasokat elkeruljuk, haladni kell. Mondjuk az is igaz, en tudok ertelmes dolgot kezdeni az ekkor beszerzett informacioval, tehat ha para van mar fel napja, akkor vagy kidebuggoljuk (megtervezzuk) egyutt, vagy megtalalom azt az embert, aki tud segiteni, akar csapaton belul vagy kivul. Esetleg feladatot valtatok.

persze olyan is van, hogy hagyom az illetot szopni, mert valahol neki ez most kell, de a beleorulos uresjaratnak valtozo, de erezheto hatarok felett nincs ertelme.

a mas platformrol jovo pm neha necces tud lenni
Az szuper, mert a projektmenedzsment platformfüggetlen dolog lenne, legalábbis amennyire én tudom.

2-3 orankent ranezek a delikvensre
Architektként oké, projektmenedzserként nem.

en tudok ertelmes dolgot kezdeni az ekkor beszerzett informacioval
Ha a projektmenedzser számára nem feltétlen szükséges ez az információ, akkor ez sem projektmenedzsment feladat.

megtalalom azt az embert, aki tud segiteni, akar csapaton belul vagy kivul
Ez már nem annyira architekt feladat. Csapaton kívül semmiképp. Csapaton belül még esetleg szódával elmegy, bár necces.

hagyom az illetot szopni
Ez sem architekt feladat. Persze más kérdés (delegálási), ha a projektmenedzser úgy dönt (már ha egyáltalán persze nyílik lehetősége ilyen döntésre), hogy minden egyes feladathoz az architektet rendeli felelősként és rá bízza, hogy a feladatokat lentebb bontsa és az egyes részfeladatokhoz a rendelkezésére álló erőforrásokból elhelyezzen embereket úgy, hogy a feladat egésze ne sérüljön (=hatáirdőre, költségre, eredményre vonatkozóan). De az is lehet, hogy saját hatáskörben tartja ezt a feladatot.

Ezek csak magánvélemények, nem állítom, hogy más meglátások nem léteznek vagy nem lehetnek eredményesek. De én (szívem szerint) azért elkülöníteném az architekti és a projektmenedzseri feladatokat. Mondjuk azt se mondhatnám, hogy nem láttam még olyat, ahol mindkét pozíciót ugyanaz tölti be. Nyílván ilyenkor vannak előnyei is ennek a fajta megoldásnak, de ugyanúgy hátrányok is akadnak.

"Persze más kérdés (delegálási), ha a projektmenedzser úgy dönt (már ha egyáltalán persze nyílik lehetősége ilyen döntésre), hogy minden egyes feladathoz az architektet rendeli felelősként és rá bízza"

Működhet. Volt projvezemmel nem olyan rég beszéltük, hogy a volt munkahelyemen talán akkor haladtak legjobban a projektek, amikor megvolt a feladatlista, először mindenki szabad rablásban azt a feladatot választotta magának, amelyiket akarta (így legalább választhatott mindenki olyat magának, ami érdekelte is, nem volt annyira a rákényszerítés érzése) a maradék meg a hagyományos módon lett szétosztva.

Nekünk is jobb volt, mert "nem baszogatott senki minket" meg a projveznek is, mert neki is kevesebb dolga volt azzal, hogy ki mit csináljon. :)

Szóval működhet a laza irányítás is csapaton belül. Persze azért nem muszáj teljesen felügyelet nélkül hagyni a dolgokat, mert mindig vannak "jaj, csak ezt ne" feladatok.

----------------
Lvl86 Troll

Amikor szétkapkodják a feladatok nagy részét a csapattagok, akkor az nem laza irányítás, hanem irigylésre méltó csapatműködés. Ez legalább a motivációs kérdéseket is megoldja részben, hiszen nem rányomták a melót, hanem ő vállalta be, azért annak sokkal másabb a színezete.

hat igen. a mostani melohelyemen ez egy egetvero kulonbseg a tobbihez kepest... akkor jovok es megyek, amikor akarok, senki nem kerdezgeti, hogy kesz vagyok-e mar a koddal, megy-e mar, stb. neha osszeulunk kavezni, akkor az ember magatol beszamol, hogy hogy all, es kesz.

persze ehez olyan emberek kellenek :)

Igen, cserebe ott, ahol egy startupnal 0.75-os szorzo van (emberora / egysegnyi munka), ott nalatok egy 8-as.

En amikor eloszor szamoltam ujra FPU-t multinal durvan meglepodtem, pedig ott valamivel kevesebb mint negyszeres kulonbseg volt "csak".

Nyilvan ez multinal megengedheto, startupnal nem.

na, varjunk mar. startupnal olyan emberek vannak ott, akik akarjak tolni. vagy arra gondolsz, amikor penzert felvesznek startupba kodereket? ha azt mondja nekem valaki, hogy holnapra kell ez meg az, akkor kesz lesz, de akkor se nezze es zavarjon meg 2 orankent.

es mondom, ez teljesen mindegy, hogy startup vagy multi, vagy akarmi, a hangsuly az embereken van, es azok hozzaallasan...

Sajnos az akarjak tolni, a hozzaallas, es a hol nem alkotnak aciklikus grafot :)

En azt vettem eszre, a multinal az emberek jolerezni magukat mennek be. Megcsinaljak ok, amit mondanak neki, de amugy lesz.rjak. Ha nem ez a hozzaallasod, felorlodsz egy multiban, ezt en mar tobbszor tapasztaltam, es erosen gondolkozom, megegyszer akarom-e.

Szoval rendkivul okos, tehetseges, es kitarto emberek is "ellustulnak" egy multiban.

Amit fontos lenne megerteni, hogy a teljesitmenyed Gauss-gorbet alkot a stresszel: kozel se akkor vagy a szellemi csucson, ha nincs stressz, sot. Azok, akik szeretnek velem dolgozni, azok azert szeretnek - sot, imadnak - mert vegig azt erzik, hogy csostul megy belejuk az endorfin, napokon, heteken keresztul.

De ehhez az kell, hogy abba a 8 oraba te mindent beletegyel, es olyan emberek, akik kikovetelik toled ezt. Ez nemcsak ebben a szakmaban van igy: ha egy szinesz nem igy all fel a szinpadra, az eloadas lagymatag lesz, tudhat barmennyit, lehet barmekkora tehetseg. De ekkor a kavezgatos, akkor megyek be amikor akarok hozzaallas kizart. Valamit valamiert. Kinek melyik fajta boldogsag fontosabb, es mikor.

Orulok, hogy tanultad, amilyen eloadasokat en lattam, ott roppant ovatosan bantak a kovetkeztetesekkel.

Mindenki motivacioja mas, nekem pl az idokorlat kifejezetten demotivalo. Attol hogy valaki jol teljesit, nem feltetlenul orul is neki. Erre utaltam hogy nem szivesen dolgoznek nalad.

A te leirasodban mintha osszemosnad a teljesitmenyt az oromerzettel ("imadnak engem"), de igazabol ebbe mar nem akarok belemaszni.

Nyilvan mindenkit mas modszerrel motivalok, van akit bekenhagyok, cserebe olyan szintu feladatot kap, hogy kapaszkodnia kell, es rajta is szamon van kerve reszletesen, csak esetleg nem olyan surun. Egyszeru feladatokat, ha huzza a delikvens a szajat (marpedig epp nincs mas, aki megcsinalja), akkor viszont idolimitet kap: uncsi feladat, na de megy-e 5 perc alatt ugy, hogy megfelelj a code style guide-nak?

Nem mosom ossze az oromerzetet a teljesitmennyel: az emberek egy resze szeret porogni, a mas resze nem. Azok, akik szeretnek porogni, jo erzessel gondolnak vissza erre, masok nem. Azok az emberek orulnek annak, hogy egy olyan kornyezetben lehetnek, ahol mindenki a maximumot nyujtja es sajat hatarait feszegeti. Masok nem.

Ettol egyebkent az az allitasom, hogy a stresszgorbe nem monoton csokkeno, meg teljes egeszeben igaz marad, kulonben lehetne benyugtatozva vezetni meg hasonlok.

"Megcsinaljak ok, amit mondanak neki, de amugy lesz.rjak."

Nem feltétlen baj az ilyesmi ember sem. Volt egy munkatársam, akivel nagyon jól össze tudtunk dolgozni. Ő alapvetően kódolni, kivitelezni szeretett én meg inkább tervezést, utánajárást vagy, amikor szöszölni lehetett valamivel (pl. tényleg ki kellett optimalizálni valamit).

Sokszor úgy nézett ki a munkánk, hogy leültünk, megnéztük mi a feladat közösen terveztünk rá valamit, ha olyan volt, akkor esetleg megcsináltam a kódvázat, ő befejezte én meg csináltam tovább a magam részét a feladatból. Egymás munkáját jól ki tudtuk egészíteni, haladtunk is.

"kozel se akkor vagy a szellemi csucson, ha nincs stressz, sot."

Stressz nagyon emberfüggő. És van ezernyi más motiváló tényező, alapvetően én nagyon nem a stresszre alapoznám. De egy egészséges hajtás az kell, de az teljesen biztos, hogy hamar felmondanék ott, ahol szándékosan feleslegesen stresszes helyzetbe hoznak. Másrészt a stressz vagy a túlfeszített munkatempó könnyen kiégeti az embereket. (Persze, ez rövid távon egy munkaadót nem biztos, hogy érdekel.)

Egyik barátomon látom, hogy mennyit és hogy dolgozik. Nem vagyok biztos benne, hogy nem fogja idővel megsínyleni az egészsége és nem fog kiégni 10 éven belül.

"De ehhez az kell, hogy abba a 8 oraba te mindent beletegyel, es olyan emberek, akik kikovetelik toled ezt. "

Ez szvsz hülyeség, főleg egy szellemi munkánál, ahol lényegében alkotni kell valamit. Pl. többször volt olyan, hogy inkább kértünk kulcsot és maradtunk még 1-2 befejezni valamit, miután már a társaság nagyja lelépett, minthogy megerőszakoljam magam és csak azért is bemenjek délelőtt dolgozni, mikor tudtam, hogy ugyanúgy semmi kedvem nem lesz. Néha az sem árt, ha ilyeneket figyelembe vesznek a munkaidő tervezésekor.

(Egyébként ilyennel ordas nagy fasságokat el lehet követni. Pl. ha épp fizetési nehézségek vannak, amit a vezetés rosszul kommunikál le (leginkább sehogy csak sumákol) és a csökkenő munkamorálra azt találja ki mentő ötletként, hogy mivel ők kora reggel ott vannak, ezért mindenki bejön reggel pontosan. Nyilvánvalóan egyenes ágú következménye lesz, hogy akkor mindenki nap végén annyival hamarább óramű pontossággal fogja eldobni a billentyűzetet és még jobban le fogja szarni az egészet.)

Ja és az ember nem egy gép, ami mindentől elzárva egyenletesen termeli neked a kódot, mindig lesznek ingadozások a munkamorálban.

----------------
Lvl86 Troll

Nem fogok cegneveket mondani, a tobbseguk titkositva is van altalaban, de:

Van olyan ceg, ahol a dolgozok evente megkapjak a ceg azevi csucskeszuleket, amikor a hardver mar kesz, de a szoftver meg csiszolas alatt van. Ez igy rendben is lenne, egy baj van: alig nehany embert ismerek, akinek privatban ne a konkurrens gyartok keszulekei lennenek, a csucskeszulekek legtobbszor csak porfogok az asztalon, esetleg asszonynak vagy mas, nagyon kozeli - mert hivatalosan cegtulajdon - helyre odaadva.

Igy aztan senki nem szol vissza, hogy az a rendszer, amit nem mellekesen naponta fejleszt, egy f.s. Erre kezdenek rajonni a fogyasztok is mondjuk...

Ebben a cegben en egyetlen embert ismerek, aki kiegeskozeli allapotig odateszi magat. A domainterulete le van szukitve. Ebben az egyben a ceg vilagelso, minden egyes hw review megemlekezik errol a momentumrol, bar a korites (nem informatikus) nem teszi nagyon lehetove hogy az egesz egy megvetelre erdemes termek legyen.

Ha nincs ez az allapot, ez a vilag - ez mar nem hozzaallas, ez mar nagysageendekkel tobb - akkor hiszem azt, maximum kozepszerut lehet alkotni. Nem feltetlenul rosszat, de semmikeppen nem kiemelkedoen jot. Semmi olyat, amit naponta sokezren kinyitnak, es naponta elegedettek, boldogok vele. Kellenek ezek az orultek.

Nem kell mindenkinek ebben az allapotban lenni. Kellenek az alapozoemberek, lehet olyan reszt talalni, megfelelo korlatokkal, amik kevesebb lelkesedessel se rontanak a termeken, akar kreativ, akar szoszolos reszrol legyen szo. De akkor is kell ez a hajtomag. Enelkul nincs semmi plusz.

A vilag tobbsege kozepszeru, igy van ez jol, ezt jelenti az, hogy kozep. Amit en allitok, hogy ha nem kozepszerut akarsz, nem felsokozep-kategoriat, hanem "na ez igen"-t, akkor ez a nyugodt resz nem mukodhet. Latok rnegeteg hazugsagot, dragan eladott vackot, de az igazi, hazugsagmentes minoseg mashogy nem megy.

Ezt ereztek, erzik azok az emberek, akik velem dolgozhatnal. En ezeket az embereket keresem.

Az amit leirtal, az teljesen oke es ertheto: jo embereket keresel. De ne ess abba a hibaba (vagy legalabb celszeru tudni rola, foleg ha mas szol erte), hogy azt gondold hogy amit te kitalaltal az az udvozito megoldas. Lasd peldanak a porgest, a motivacio kerdest es a stressz gorbeket. Ezt csak azert mondom, mert lehet hogy sok jo embert elkergetsz a stilusoddal, pont azokat akiket keresel.

Az a baj, hogy te egy tok mas szempontbol szemleled a helyzetet, es nem nagyon latod az alkalmazottaid szempontjait. Te vezeto vagy, es neked akkor jo, ha dol a penz a ceghez. Azonban, a programozas nem csak munka, valahol hivatas es muveszet is egyben. Nem csak arra kell osztonozni az embereket, hogy dolgozzanak, hanem hogy szeressek is, amit csinalnak. Es ha valami nem tetszik, akkor leulni megbeszelni vele, kompromisszumokat kotni. En hiszem, hogy reszben ez is hozzatartozik egy jol mukodo csapat mindennapjaihoz. Ha erzik, hogy fontos a velemenyuk, es szeretik azt, amit eppen csinalnak, akkor sokkal jobb es minosegibb munkat fognak vegezni. A nyomas csak akkor hatekony eszkoz, ha mar minden mas lehetoseg sikertelennek bizonyult, vagy ha mar nagyon szorit a hatarido. A korbacs csattogtatasa csak az elegedetlenseg magjainak elhintesere jo, masra nem surun.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

A vezetonek nem az a dolga, hogy doljon a penz: a vezetonek az a dolga, hogy az alattalevok erdekeit kepviselje. A programozonak meg az a dolga, hogy a felhasznalok (nem a megrendelok!) igenyeit kielegitse.

Ha a felhasznalok elegedettek, dol(het) a penz.

Ertem en hogy az informatika hivatas es muveszet, nincs ezzel baj, sok cikkem van ebben a temaban. Viszont azt a fost amit az erre hivatkozo programozok le szoktak adni, nem vagyok kepes annak hivni. Akinek ez tenyleg hivatasa - talalkoztam par ilyennel - azt nem kell hajtani, es a hibait is csak meg kell jegyezni, fel ora mulva ott a kesz javitas. De az erre hivatkozok tobbsege a kozepszerutol az abszolut hasznalhatatlanig tarto pojaca.

Ismert, hogy nem hiszek a kompromisszumokban: ha olyan termeket akarsz kiadni a kezeid kozul, amiben nincsenek kompromisszumok, akkor a munkad soran se lehet sok; neha kell, de ha valaki a porgetest "korbacsnak" erzi azt egyszerubb kihagyni.

Sok jol mukodo csapat max haveri korkent mukodik jol: rengeteg erterspajz fost lattam, aminek csapattagjai jol ereztek magukat egymassal, de a munka eredmenye nem tette boldogga a felhasznalokat. Az a kerdes, hogy csinalj olyan csapatot, ami attol erzi jol magat, hogy a felhasznalot boldogga teszi.

"De az erre hivatkozok tobbsege a kozepszerutol az abszolut hasznalhatatlanig tarto pojaca."
Ahol ilyen produktivba kimegy, ott nem a programozoval, hanem a HR-essel es a vezetessel van baj, nem lett megfeleloen felmerve a programozo tudasa, es nem lett probaido vegen seggberugva.

"nem hiszek a kompromisszumokban"
Nem is kell allandoan kotni. De erdemes lehet arra odafigyelni, amit a munkatarsaid mondanak, mert te sem vagy tevedhetetlen, es lehetnek jo otletek is. A kompromisszum nem mindig negativ dolog, neha nagyon hasznos.

"munka eredmenye nem tette boldogga a felhasznalokat"
Nem akarom azt mondani, de itt megint csak nem a programozo a hibas, hanem a projektmenedzser, meg az architekt. A felhasznalo nem attol lesz boldog, ha uj technologiak vagy innovativ megoldasok vannak a termekben, hanem ha kielegiti az igenyeit a program. Ha nem elegiti ki az igenyeit a program, akkor szar volt a programterv, szar volt a kommunikacio, szar volt az igenyfelmeres. Csupa-csupa olyan dolog, amiert a programozo meg csak kozvetve sem felelos.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

Nem tudom, lattal-e mar probaidon seggberugott programozot, en csak keveset.

Sajnos nagy a nyomas a multis felveteliztetokon altalaban, hogy 10% felett legyen a felveteli ratank, pedig kb. az az egeszseges, sot neha az alatt. A HR-esek viszont felvett emberre kapnak bonuszt.

Valtozo kinek a kompromisszumaiban hiszek, azokat a kompromisszumokat nem szoktam megkotni, amik minosegcsokkenest eredmenyeznek. Egy nagyvallalatnal rengeteg a kompromisszum a kompromisszum kedveert, ezeket irtom; vagy ha ket fiatal programozo odajon hogy nekik nem tetszik az MVC - ilyen is volt mar - de ertelmes javaslata nincs, csak unja a szabalyokat, akkor szoktam. Van amikor ki kell torni, volt hogy dobtam az MVC-t is; na de nem webappnal. 3-4 eve belementem egyszer egy hasonlo "legyen jo a gyerekeknek" kompromisszumba, de a program effektiv atadhatatlan lett, atadtuk, de az ugyfel soha nem hasznalta utana :(

(Ill. a masiktol a "mindenki velemenye egyforman szamit"-tol szoktam meg menekulni... nagyon sokan akarnak nemely nagyvallalatban velemenyt alkotni... ilyenkor be szoktam kerni az illeto munkait, megnezem, majd azt mondom hogy "de hisz ez egy hulye, meg nem rugtatok ki? Ja hogy ti senkit..."

Azt gondolom, egy rossz program barhol rohadhat; rohadhat a PM-en, rohadhat a tul pushy ugyfelen, rohadhat az architekten, rohadhat a programozon, rohadhat a QA-n. Gondold meg, hogy mindenki perfekt munkat vegez, csak a programozo termeke bugos, vagy nem erti a feladatot, akkor mi van? Minimum csuszas, amig megbeszeljuk vele 25x, hogy ezt nem igy kene,rajovunk,nincs mas megoldas, kirugjuk, ujat keresunk, beletanul, stb... Nyilvan bizonyos szintu kompromisszumot muszaj kotni, ez a kompromisszum neha az, hogy a programozo nem boldog, viszont van munkahelye, cserebe minden egyes leadasanal veszekedes van, hogy a checklist az checklist.

A QA-n is megakad a program kulso szerkezeti hibakert, nalam belson fog; azon szoktak vitatkozni velem, hogy a belso minosegnek mi ertelme, mi a f.sz az a design patterns, minek szolok bele hogy hol generalodjon a javascript, volt aki bejelentette, hogy "de 2010-ben ennyi memorianak mar kell lenni" (foglalt volna maj' egy gigat), mondtam, nem egyedul vagy abban a memoriaban, es a progid 10 megabyte-on is szepen elfutna, azon kivul hogy lusta vagy gondolkodni semmi nem indokolja az ekkora eroforrasigenyt.

Es persze enterprise-nal legtobbszor az architect van leoltva, itt most nem mondok termeknevet, mert a threadben szerepel egy illeto aki ott dolgozik, es nem hiszem hogy tehet arrol, hogy bizonyos termekeik... nem tul hatekonyak memoriaban evek ota.

De ettol meg en igyekszem olyan programokat kesziteni, amitol a felhasznalo boldog, es fejlesztesei karbantarthatoak, mert arrol szol, amit a felhasznalo csinal. Ez nehez,es a vilag nem ilyen, de hiszem hogy erosnek kell lenni, es hiszem hogy nem kell mindenkinek elprogramokat gyartania, akkor se, ha amugy elprogramozo lenne.

Igy mar kicsit maskepp nez ki a dolog. Egyre azonban felhivom a figyelmedet: A "minden velemeny egyforman szamit" nem azt jelenti, hogy mindenkiet el kell fogadni, hanem azt, hogy mindenkiet meg kell hallgatni. Lehet, hogy utana azt mondod: "de hisz ez hulyeseg", es annyiban hagyod, viszont a masik oldalrol pozitiv, hogy nem robotkent es rabszolgakent kezeled a munkatarsat, hanem tarskent.

Enterprise-nal meg persze, hogy az architekt van letolva - mert ot latjak. A tizedik javascript programozot a vezetoseg sosem fogja latni, meg talan a nevet sem fogja tudni, fuggetlenul attol, hogy valojaban o volt a problema forrasa vagy sem.
-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( T_chris | 2011. 06. 29., sze – 17:52 )

Nincs rám illő választási lehetőség.
- - - - - - - - - - - - - - - - - - - - - - - - - - - -
- - -> Kérjük a humoros aláírást itt elhelyezni. <- - -

( saxus | 2011. 06. 29., sze – 17:56 )

Igazabol csak arra voltam kivancsi, hogy hanyan vannak itt naplopok.

----------------
Lvl86 Troll

( doncarlos v | 2011. 06. 29., sze – 22:50 )

...elkezdtem és ősszel kezdem a 11 félévet :) \o/

( hrgy84 | 2011. 06. 30., cs – 02:31 )

.. nem vegeztem, nem is akarok. Egyreszt en nem tudok munka mellett hatekonyan tanulni (kiprobaltam, nem ment), masreszt mivel elsosorban rendszergazda vagyok es nem programozo, igy nincs feltetlen szukseg arra, hogy diplomat lengessek, mert attol egy szerver se kezd el mukodni. Cserebe van egy OKJ-s Rendszerinformatikusi papirkam. Sokat nem er, de legalabb lehet emlegetni.

Ja, azt mondtam, hogy OKJ-s papirom is? :-)

-- 

Ki oda vagyik, hol szall a galamb, elszalasztja a kincset itt alant. | Gentoo Portal

( csarlee v | 2011. 06. 30., cs – 06:32 )

Az elsőre szavaztam bár főiskolát _és_ egyetemet is végeztem, diplomám is kettő van...

( tombenko v | 2011. 07. 02., szo – 23:54 )

Végeztem. Nem is egy szakot. Nem is egy szinten. Sőt, most is csinálok egyet.
--
Fight / For The Freedom / Fighting With Steel