C - Vizsgára való felkészülés segítése

Fórumok

Segítséget szeretnék kérni vizsgára való felkeszüléshez.
A kérésem az lenne, hogy aki tudna majd segíteni ha elakadok az jelezze nekem.
A felvetődő problémákat és megoldásokat majd itt is megosztom hátha valakinek segít majd!

Előre is köszönöm mindenkinek a segítséget!

Hozzászólások

általános felkészítés kéne, vagy specifikus problémában segíteni?
előbbire jószívvel ajánlom ezt: https://infoc.eet.bme.hu
utóbbira meg, nyugodtan dobd fel ide (vagy stackoverflow, etc.), s biztos lesz, aki az adott problémában segít.
--
blogom

Az általános felkészülés megvolt. A Kernighan és Ritchie féle "A C programozási nyelv" könyv elolvasva/megtanulva. Egész jó tudást tudott adni, az órákon és gyakokon is odafigyeltem, tehát az elmélettel nincs gond.
Inkább a gyakorlattal van, ott is amiatt, mert a programot papíron kell csinálni!
Általában mindig valami matematikai problémát kell megoldani és van rajzolós feladat is!
Pl.: e természetes számot kell kiírni az első n tagjával, tömb nélkül
vagy pl. a rajzolósnál egy háztetőt kell kirajzolni vagy egy kockát az átlóival, vagy pl. egy nagy t, n, z, l, h betűt aminek a magasságát a felhasználó adja be.
Általában a rajzolósoknál akadok meg, mert a ciklusokba belekavarodok. Ehhez kellene valamiféle segítség. Ha tudtok valamiféle frankó feladatgyűjteményt akkor azt ne tartsátok magatokba!
Ha lesz valami problémám amit nem tudok megoldani azt majd feldobom ide!
Előre is köszönök mindent!
Az oldalt pedig ismerem, de köszönöm a linket!

egy embernek kell annyi logikájának lenni, hogy odaképzeli a hiányzó pontosvesszőt, s úgy oldja meg a feladatot. hisz nyílván való, hogy mi a feladat szándéka.
aki meg olyan fasz, hogy ezen kukacoskodik és azt írja hogy "semmi" meg hasonlók a kimenet, az meg is érdemli, hogy kibasszák. ráaádsul az ilyen ember annyira hülye, hogy nem fogja fel, hogy ő _VIZSGÁZÓ_ és nem a vizsgáztató, s itt nem ő osztja az észt, hanem legjobb tudásának megfelelően válaszol a kérdésekre.
(esetleg ha intelligens, megoldja a feladatot, s a végén zárojelben odaírja megjegyzésként, hogy milyen hibát talált a kiírásban. - hátha kap plusz pontot.)

Tudod elég gáz, hogy ha a vizsgáztató olyan követelményt támaszt a vizsgázóval szemben (papírra írjunk szintaktikailag helyes, működő kódot), amin ő is elhasal.

De legyen, bassza ki. Viszont legközelebb ne szivassa ezért, mert ha megteszi, akkor ő van eltévedve, de nagyon. Ugyanis ő közvete a diák alkalmazottja, az a dolga, hogy tanítsa, nem azért, hogy tekintély alapon szivassa. Az már 25 éve nem menő, és ha ezt nem képes megérteni, akkor legyen bármekkora szakember, őt kell kibaszni az egyetemről, hogy a lába ne érje a földet.

Nem kell odaképzelni - pontosabban de, és a válaszban leírni, hogy a programozó szándéka szerint ezt és ezt kéne kiírnia, viszont jelen formájában nem fog lefordulni, mert hiányzik egy pontosvessző a sor végéről.

Egyébként anno minket is szivattak papíron programozással még anno Turbo Pascal-ból... De legalább korrekt volt a tanár, mert amikor egyszer valamit nagyon benézett, és hülyeség került a táblára, akkor bólogatott, és azt mondta, hogy "Írják oda a füzetbe pirossal, hogy ezt a S... F... rontotta el."

Onnan, hogy hibás egy feladat, semmi sem "nyilvánvaló"! Lehet, hogy a feladat készítőjének az, de senki másnak nem. Ha gondolatolvasásból kell vizsgázni, akkor persze "basszák ki", de itt nem erről van szó!

A _VIZSGÁZÓ_ és a _RABSZOLGA_ között érzek némi árnyalatnyi különbséget. Azért a pénzért, amit az állam befizet (vagy a _VIZSGÁZÓ_), igazán kaphatna rendes feladatokat. Ha pedig nem azt kap, akkor kérjenek elnézést és nem az a módja, hogy "kibasszák", mert "az észt osztja".
Alapjaiban felháborító ez a felfogás!!!

-1

csak azért, mert egy vizsga papíron van prog-ból, még nem ítélném el. szerintem sokkal többet számít az, hogy mi a tárgy célja (alap bevezetés, ahol a legkomolyabb program, amit számonkérnek szűk ötven sor, vagy egy sokadéves, mély, adott technológiában elmélyülő tárgy), és hogyan javítják.
--
blogom

nekem a fentiek alapján az az érzésem, hogy ez egy alapozó tárgy, első félév, egyetem.

itt nem az a kérdés, hogy valami hasznos-e, hanem hogy megérted-e, mi az a ciklus, a feltétel, milyen lehetőségeid vannak egy általános programozási nyelvben. középiskolából kikerült, algoritmust soha az életben nem látott emberekről beszélünk. jobb esetben előkerült matekon, hogy mi az algoritmus, esetleg a legnagyobb-közös-osztó kiszámolását felírták algoritmikus formában, de ennyi (amennyire beszélgettem az évfolyamtársaimmal, nem, ilyen egyáltalán nem kerül elő a középiskolában). és erre, a rajzolj egy V-betűt, vagy rajzolj egy háromszöget, aminek a szélei másmilyenek, mint a közepe, ráadásul akkorát, amekkorát a felhasználót mond, tökéletes feladat.

de te mégis, hogyan szűrnéd ki azt, hogy az adott hallgató érti-e az alap vezérlési szerkezeteket? negyedik hét, egyetem, eddig volt 3*1,5 óra előadás, 3*1,5 óra tantermi gyakorlat, és 3*1,5 óra számítógépes gyakorlat.
szerintem, ezen a szinten, ha gép előtt kellene megoldani ezt a feladatot, akkor az átmenők 20-30 százaléka fals-pozitív lenne, aki nagyon sokadik próbálkozásra bemakkolta a helyes ciklus-fejléceket, elágazásokat, de halvány lila fingja nincs arról, miért is azt kellett írnia.

ha ez egy sokadéves, haladó tárgy, akkor viszont igazat adok mindenkinek.
--
blogom

Egyetemrol kikerulteket elnezve az a 20-30% fals pozitiv nem oszt, nem szoroz. Tok jo, hogy elmeletben vag komoly matekot meg algoritmuselmeletet, amit egy reszuk meg hasznalni is tud, de ez programozoi munkahelyek hany szazalekara kell, 10, esetleg 20? Cserebe olyanokrol, hogy clean code, tdd meg design patterns meg nem is hallott, a cegnek nem hasznosabb mint az, aki az utcarol beesett egy ev otthoni hobbikodolassal. Es nem, rohadtul nem jo az a szoveg, hogy ezeket szivja fel egyetem mellett, mert pont ez lenne az egyetem dolga. Nem veletlen talalkozok egyre tobb kollegaval, akik otthagytak a francba az egyetemet.

Pedig igaza van. Amíg nem fogják fel a felsőoktatásban, hogy bizony létezik egy olyan szakma, hogy szoftvermérnökség, ami nem csak abból áll, hogy a ciklus leállási feltételét bizonyítjuk be papíron, hanem abból is, hogy hogyan írunk tiszta kódot, hogyan írunk tesztelhető kódot, hogyan és mit dokumentálunk, hogyan keresünk hibát és oldunk meg problémát, addig ne is várd, hogy a cégek elvárják a diplomát az állásokhoz. A cégeknek szoftvermérnökök kellenek. Az egyetemi oktatás nem képest ezt megadni nekik.

Pont azon derülök, hogy itt bizony ilyeneket is tanítunk (ugyanis, hogy, hogy nem, belülről látom a dolgot).

Csak sajnos a hallgatók sok esetben képtelenek arra, hogy túllássanak a vizsgákon, hogy összerakják az egyetemi tudásukból a gyakorlatot. A topicnyitó gondolkodásán ugyanezt látom. Nem lát tovább a típuspéldáknál, meg a "rajzolós" feladatoknál. Hiába tanítunk átfogó, általános gondolkodást, ezt nem mindenki képes fogni, túl akarnak élni.

Aztán jönnek az "egyetem fölösleges, nem értenek hozzá, stb."-típusú kisebbrendűségi-érzetes megjegyzések. Pedig mindkettőnek (felsőfokú végzettségnek, meg annak hiányának) van létjogosultsága.

Hatszáz embert meg nem fogsz tudni hatékonyabban tanítani. Nem mindenkinek való a dolog, annak idején valaki(k) kitalálta(ták), hogy legyen mindenki felsőfokú végzettséggel.

Csak nem mindegy, mit kértek számon. Ha egy szoftvermérnöki képzésen fontosabb az R^n topológiája vagy éppen a pontos bzionyítása a Cauchy-egyenlőtlenségnek, miközben a programozás beadandóban lehet non-clean code is, ha helyesen fut, addig tökmindegy, hogy mi az, amit hallanak tőletek a hallgatók.

+sok. A paraszt arra fog keszulni, amit szamonkertek. Ha a mateknak kisebb lenne a hangsulya, es nagyobb a programozasi technikaknak, sokkal jobb emberek kerulnenek ki. Sajnos meg mindig a matek az, amit inkabb szamonkernek minden szamteches kepzesen, en pont ezert is vetettem el az otletet, hogy egyetemre menjek: a kesobbiekben kifejezetten nem volt terv, hogy matekos allasba menjek, mert nem erdekel a matek.
--
Blog | @hron84
Üzemeltető macik

Az igazan szomoru az, hogy amikor 10 ev szakma utan eljutsz oda, hogy most akkor kene a matek, mert vegre kaptunk egy olyan feladatot ami nelkul nem lehet, addigra mar fogalmad sincs, mert anno kontextus hijan a vizsgara tanultad meg es utana gyorsan el is felejtetted.

Mit nem adnek azert, ha leulhetnek valakivel most 1:1 egy par ora statisztika / analizis orara.

--
Pásztor János
Sole Proprietor @ Opsbears
Development Lead @ IXOLIT

3 pénzt óránként?

̢̢͇̜͍̮̤͆͗̀̇̏̚͝ḅ̳̭͇̺̺̣͐̓̾̔̾͆̕ṃ̡̧͍̖̮͖̈́͗́̑̆͋͘ȁ̢͎̟̰͖̘̹̅̋̆͒̚͝s̨̖͎͕̲̜̰͗́̓̀̀͗̚n̲̝̠̰͓̪̈̀̈̔̀͂̄ͅi͖̖̬̮͖̭̱̓͗͛͆̿̇͘

Nem az egyetem fölösleges, hanem a MAGYAR informatikai diploma. Leszámítva azt a cirka 10%-ot, akiknek ez kell majd. Persze biztos neked van igazad, és az informatikai cégek a hülyék, hogy saját academy-ket indítanak, hogy fizetés mellett megtanítsák azt, amit egyetemen kellett volna. Persze mint tudjuk a magyar felsőoktatás lényege nem a hallgatók felkészítése, hanem a jól bejáratott professzori kar munkával ellátása, akkor is ha az amit tanít 20 éve elavult, vagy mostanra marginalizálódott. De mondhatom egy volt kollégám esetét is, ahol vizsgán azért bukott, mert a prof tudta rosszul, a srác meg azzal dolgozott minden nap..

„hogy itt bizony ilyeneket is tanítunk”
tudom, ezt a kört néhányszor lefutottuk, de mikor?

én úgy saccra a szakirányig megvagyok mindennel (láttam minden tárgyat), és clean code-dal, meg TDD-vel nem igazán találkoztam. főleg nem gyakorlatban, segítve, ahogy azt illene.

helyette a következőkkel igen:
- „az első dolgom mindig, hogy a GCC optimalizációját kikapcsolom, mert én úgyis jobban tudom.”, és xor-csere ftw - prog1 labor
- Java 1.6. Azóta megjelent a hetes, de lehet, már a nyolcas is. Annyira nem követem. - 2012. nyár, szofttech, Java előadás
- tesztjegyzőkönyv - szlab4
- a tesztelés abból áll, hogy az alkalmazás elé írok valamit, ami szöveges bemenetet fogad, és szöveges kimenetet ad. majd megírom a bemeneteimet, s az elvárt kimeneteimet. mindet lefuttatom, kézzel, majd kézzel összehasonlítom az aktuálist az elvárttal. - szlab4
- a szoftverfejlesztés abból áll, hogy a tárgyhonlapról kimásolod a következő kódrészletet, majd a laborvezető elmondja, miért is szerepel ott, ami. - az összes AUT-os prog. tárgy
- python2 - 2015, szlab5
- 45 perc telefonálgatás a labor elején, hogy az R épületben lévő gépeken miért nem indul az SQL Developer - szlab5
- Java (1.6, persze) fordítás make fileokkal - szlab5

na, most ha ezek után elmegyek szakirányra, s elmondjátok, hogy:
- ja, amit eddig a tesztelésről tanultál, az totál hülyeség (most belenéztem a prog3 unit testes diáiba, fáj)
- ja, a GCC optimalizáció annyira nem is buta
- ja, van ilyen, hogy Clean Code
akkor már kicsit késő, nem?

és erre nem mentség az, hogy „bezzegmiaMITen”, mert a képzést egyben fogja mindenki megítélni.

a többire nagyjából pluszegy. bár azt fenttartom, hogy egy szoftverfejlesztői képzés igencsak hiányzik az egyetemi palettából.
--
blogom

És épp ez a probléma: nincs szisztematikus szoftverfejlesztő mérnök képzés. Mert az, hogy egy szabvál vagy szakirány tárgy tanítása során elmondod, hogy amúgy van clean code, meg unit testing, az minden, csak nem szisztematikus. És pont egy mérnöknek kéne ezt a legjobban tudnia: amit nem szisztematikusan csinálsz, annak nem lesz kiszámítható végeredménye.

Csak ez attól is függ, ki kerül be ide. Nagyon sokféle tudással, sokfelől jönnek. Van, akinek ezek simán mennek, el is kerülnek jó helyekre. Sokaknak viszont nem, rajtuk az egyetem se segít. Aztán vannak, akik nem tudnak, de akarják csinálni, őket lehet formálni.

Én pl. olyan vagyok, hogy kb. mindent, amit nekemszórtak az egyetemen fel tudtam használni, mert az előadóim rámutattak az összefüggésekre. Sok mindent nem tudok, de mivel rengeteg mindenben erős szemléletet kaptam, gyorsan tanulok új dolgokat (pl. reactive programozást álomszépen lehet a hardvertervezéshez kapcsolni). Ehhez persze elég sok nyitottság kell az új ismeretekre. És nagyon sok bizalom az oktatók felé.

Kinek való:
A B.Sc.-re azt mondanám, hogy az a gombnyomogató, akinek ha megmutatják, mit kell csinálni, akkor megérti és meg tudja csinálni. Az M.Sc. pedig az, aki önálló tervezésre képes.

A kimemet: Nagyon függ az évfolyamtól. A mostani hallgatóim pl. szerintem kifejezetten jók lesznek. Próbálok minél többet belefűzni a gyakorlati tapasztalataimból az órákba, csak megjegyzik néhányan.

A nem működő dolgokról: ha utánaolvasol az egyetemeket érintő intézkedéseknek, nem lesz meglepő. De ez politika, ami frowned upon.

"Kinek való:
A B.Sc.-re azt mondanám, hogy az a gombnyomogató, akinek ha megmutatják, mit kell csinálni, akkor megérti és meg tudja csinálni. Az M.Sc. pedig az, aki önálló tervezésre képes."

Eddigi tapasztalataim alapján semmi köze a diploma szintjének ahhoz, amit leírtál. A jó munkahelyeken eltöltött évek számának van. Lehet egy szoftvermérnök diplomának lenne köze, de egy progmat/műinfónak nincs.

Nem csak attól függ. Az egy dolog, hogy egy adott alapanyagból mit lehet kihozni. A más kérdés, hogy mit akartok kihozni. Ma Magyarországon nincs célirányos szoftvermérnöki képzés, vagy progmat, van műinfó, de egyik sem az. Nincsen szisztematikusan képzés szintjén modern szoftverfejlesztési és mérnöki ismeretek oktatása.
Te is sokat említed a szemléletet. A clean code, a TDD is mind csak szemlélet. Ugyanúgy, mint a SOLID alapelvek. Lehet nélkülük is élni, csak nem érdemes úgy programozni, hogy nem alkalmazod. Elvek csak.

Ugyanígy lehet mechanikát Newton-formalizmussal számolni, de igazán a Hamilton-formalizmus az, ami valamit mond is a rendszer lényegéről. Aki tanult fizikát, az tudja.

A diploma szintje egyáltalán nem határozza meg azt, hogy ki milyen feladatkört fog ellátni. Az határozza meg, kinek mennyi tapasztalata van, úgymond mennyi "szíváson" esett át a munkában. Tanulhatsz te rengeteg elméletet, meg lehet kurvajó szemléleted, ha nem tudod, hogy a gyakorlatban egy-egy feladat esetén milyen problémák állhatnak elő.

Az pedig nem politika, hogy mit tanítasz alacsony költségvetésből. Persze a matematika oktatása olcsóbb, mint átnézni 600 ember beadandóját sorról-sorra és elmondani nekik, mi nem jó, és hogyan kellett volna megcsinálni, hogyan szép, hogyan "mérnöki" és ami a legfontosabb: miért nem jó, amit csinált (hiába működik), és miért jobb az, amit te tanítasz. Ehhez idő és ember, de ami a legfontosabb: akarat kell.

Panaszkodtál, hogy rosszak az eszközök, van-e telepítve SQL Server, whatever. Ez sajnos finanszírozás. Úgy értesülök, évek óta közbeszerzés stop van informatikai eszközökre. Csodálatos dolog ez egy informatikai karon.

Mint ahogy az oktatók motiváltsága is sokszor múlik anyagi dolgokon. Hajlandó vagy-e hétvégén is dolgozni, hallgatókkal konzultálni, vizsgasort írni, beadandókat javítani havi 100ezer forintért? Hozzátéve azt is, hogy a fizetésed soha nem fogja elérni az iparét? Hosszú távon ki lehet benne égni. Nagyon sokan 300 százalékosan dolgoznak nálunk, megbecsülés meg kb. 0. Amennyire látom, csak a szakma, tanítás szeretete miatt maradnak. Pedig elég komoly szakemberek is vannak köztük, pl. tudtommal Mo. egyik legjobb FPGA-sa is nálunk van (ezt a hallgatók persze nem szokták tudni).

Én nem panaszkodtam az eszközök miatt. Másrészt az, hogy van-e eszköz, az valóban pénzkérdés. Az, hogy a meglévő eszköz használva van-e, nem az. Másrészt talán pont a BME VIK ami sok forrást tud bevonni nem állami szektorból is.

Most az oktatók motiváltságával jössz, pedig a motiváltságnak égvilágon semmi köze nincsen ahhoz, hogy strukturális, úgymond elvi hiba van a tantervvel, és nem a kivitelezéssel, azaz a tanterv implementációjával van csak baj.

jupp. az sql developer nem indult el, mert a fasztudja milyen policy beállítás, meg a java valami virtualizált dologban, és húdesecure win7 a hallgatói géptermekben. wifi persze nincs, ha valaki nem a nagyközös gépekkel szeretne szenvedni, hanem tényleg haladni. (kábelnet van, nem azért nincs wifi, hogy nenézzdmegamegoldástaneten!)
de ugyanezt eljátszottuk akkor is, amikor java webstart dolgot kellett írni, természetesen 1.6-ban.
jah, az úgy nem volt meg, hogyha kedden van egy labor, akkor hétfőn bemenjen valaki, és kipróbálja. inkább ment a fejvakargatás 45 percig (1,5 órás labor!), mire valaki telefonon megmondta, hogy mitmerrehogyan.
--
blogom

Mondjuk a motiváltság kérdése érdekes, én speciel teljesen másképp fogom fel a dolgot. Én befektetésnek tartom a jövőmbe, nem mellesleg a hallgatók jövőjébe. Tartok programozás jellegű tárgyat mester képzés utolsó félévében, persze itt szerencsés helyzetben vagyok, nem kell az if-then mélységeit taglalnom, a tárgy inkább, komplex matematikai problémák megoldásáról szól. Mivel "örököltem" a tárgyat szerencsés is vagyok, mert egy nagyon élhető értékelési rendszert kaptam, amin nem fogok változtatni. A lényege, hogy a hallgató hozza a témát és valósítja meg tetszőleges nyelven. Én az órákon mutatok pár lehetséges utat, viszont mivel mindig kevés hallgató van, megvan az a luxusom, hogy az órák menetét a csoportra tudom szabni. Van, olyan félév ahol sokat kell "melóznom", van olyan, hogy sétagalopp. De a minőségből nem engedek, a tárgyfelelős Prof meg mindig nagyon örül a sok szép feladatmegoldásnak. Azzal is tisztában vagyok, hogy ez egy nagyon ideális helyzet, de sok melóm van abban, hogy ezt fenntartsam, viszont nagyon élvezem.

Az az igazság, hogy kevés olyan intézmény van, ahol jól használható tudást adnak át. Itt a hangsúly az átadás alatt van, hiszen úgy egy félév alatt sokkal több ismeretet lehet szerezni, mintha apró morzsákból próbálja meg a hallgató összeállítani a teljes "képet" önállóan. Természetesen kell az önálló munka, csak jó ha nem a 0 szinttől indulva.

Disclaimer: a következő post nem reprezentálja a munkaadóm, feleség/gyerek/család/kutya véleményét, szigorúan magánvélemény stbstbetcetc.

Egy kicsit továbbmennék a költségvetésen. Elöljáróban, IT jellegű egyetemi oktatáshoz nincs közöm, de egész jól látom, hogy milyen ipari mennyiségű a bürokrácia a felsőoktatásban. Lentebb/fentebb többen hozták pozitív ellenpéldának az online kurzusokat: a kettő között az egyik hatalmas különbség, hogy utóbbinál nincs szakalapítás, szakindítás, akkreditáció, KKK [képzési és kimeneti követelmények, vagy valami hasonló izé, egy újabb felesleges bürokratikus szar, de legalább fél-egy évre meg lehet vele borítani a felsőoktatást...], nincs MAB, nincs oktatási minisztérium és a többi. A dolog legegyszerűbb része az, hogy Béla beül a (virtuális) padba, Jóska meg elmondja neki, hogy SOLID.

Jóskának ezt 3-5 évvel korábban dokumentálnia kellett, el kellett fogadtatnia átlagosan 60+-os "az igazi emberek PDP-11-en kódolnak assembly-t, pillangószárnnyal" típusú emberekből álló bizottságokkal, a 0. perctől prezentálnia kellett használható irodalmat (ha egy kurzust egy képzésben akkreditálni akarsz, akkor vannak formai követelményei, többek közt irodalomlistát kell adnod hozzá - ha ma megpróbálnál egy bleeding edge Java 1.9-es [tudom, még nincs, példa] kurzust indítani, mire az elindul, a hallgató már joggal mondja, hogy a 2.1 környékén mit akarsz még ezzel az őskövülettel...).

Mostanában nagyon megy a duális képzés, mindenhol azt kell nyomatni (még olyan területeken is, ahol __semmi__ értelme vagy kifejezetten megvalósíthatlan), programozóknál minden valószínűség szerint hasznos lesz. Úgyhogy valami változás van, de amíg ilyen szinten túlszabályzott az egész, lesznek bajok.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Programozásról passz, de a felsőoktatás kezd kacsintgatni az on-line kurzusok irányába - vannak egyetemek/főiskolák, amik coursera-n is ott vannak ill. saját on-line kurzusokat visznek. MOOC néven szoktak rá itthon hivatkozni.

Egyébként személyes véleményem, hogy alapozó tárgyaknál (prog. alapjai, alapszintű algoritmizálás, ez a szint) bűn mindenféle on-line dolgokban gondolkodni, az még az a szint, ahol tényleg minden összefüggést fel kell fedezni és megismerni, különben később nagyon visszacsap, és erre többé-kevésbé alkalmatlan a saját időbeosztásban (értsd: este 10-kor), megosztott figyelemmel (mert közben megy a facebook, a Skype, a háttérben a TV stb.) tanulás.
Afölött (tfh. egy prog. alap meg van, egy Java meg van, egy adatbázisok meg van) már belefér, pl. egy Java Servlet programozásra már bőven jó, az már az a szint, amit akár "fél füllel" is lehet követni, mert gyakorlatilag egy API és a hozzá tartozó contract-ek és mondjuk best practice-k bemutatása.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Viszont jelenti azt, hogy kaptál egy elvileg jól megtervezett, egymásra épülő képzést (még ha a tartalmával, felépítésével nem is kell egyetérteni), tudományos szemléletmódot (sokan elfeljtik, hogy az egyetemeknek az oktatáson kívül a kutatás is feladata, ehhez pedig kell az, hogy az oktatásban a tudományos szemléletet is átadják, "kinevelendő" a következő kör oktatót-kutatót, ezért kell pl. az összes bizonyítás).
Ha fogsz egy kerettantervet, végignézed a kurzuslistát, és mindegyiknek megfeleltetsz egy-egy coursera-s kurzust és hozol róla papírt, attól még messze nem biztos, hogy az egyes papírok mögötti tudásanyag közti összefüggést is felfedezted, felfedeztették veled. Egy diplománál elvileg igen.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Igen, és az állami elismerésnek vannak feltételei (ami azt illeti, túl sok feltétele van). Amiket következetesen, megadott időközönként újra és újra ellenőriznek (erre van az időnkénti akkreditációs eljárás). Hogy ez a rendszer (mint itthon kb. minden) az élhetetlenségig túl van szabályozva, az egy más kérdés. Hogy te nem értesz egyet a KKK-k/tantervek összeállítóval, szintén.

az oktatók valóban teljesítették azokat az elvárásokat, amelyeknek papíron megfelelnek.

Ezek melyikek lennének?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az, hogy egy tanterv megfelel a KKK-nak papíron, még nem jelenti azt, hogy az adott oktató valóban le is adja a tananyagot és számon is kéri úgy, hogy tudd.
A KKK és az akkreditáció sokat nem ér, részt vettem már ilyenben. Legtöbb esetben a tantárgyak felelősei egyetemi tanárok, vagy docensek, mivel papíron ez kell a KKK megfeleléshez, miközben ténylegesen PhD-sok oktatják olyan, amilyen szinten a tárgyakat.

Igen, láttunk már karón varjút, de tapasztalatom szerint messze ez a kisebbség. Egyébként mi a baj a PhD-hallgatókkal (egyébként többnyire nem sima PhD-hallgatók, hanem tanársegédek)? Ha megkapják a PhD-t és a pályán akarnak maradni, akkor a következő félévben már mint adjunktus mennek be ugyanazokat az órákat megtartani. Sőt, tovább megyek: pár éve még adjunktus is simán csinálta a PhD-ját a docensi fokozatért...

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az, hogy az akkreditációban nem a PhD-sok számítanak, hanem a profok, de a hallgatóknak a tudást a PhD-sok adják át. Ezt az ellentmondást nem oldja fel semmi. Így az akkreditációnak köze nincs a valósághoz, pláne nem ahhoz, hogy bármilyen garanciát adjon arra, hogy milyen tudású hallgatók jönnek ki a képzés végén.

A docens/tanár a képzés/kurzus szakmai felelőse, ő határozza meg a tananyagot, koordinálja az egyes csoportvezetők munkáját stb. Előadásos tárgyakat többnyire nem szoktak átadni (papíron semmiképp, mert több szempontból kitűnne, óraterhelés, akkreditáció stb.), az meg nem elvárható, hogy 20-30 fős csoportokban 300 hallgatós évfolyamoknak mind a prof tartsa a gyakorlatokat/laborokat, mert az az jelentené, hogy még 1 órás gyakorlatokkal is meg van a féléves óraterhelése egy kurzussal (egy-két félévig még lehet is csinálni, hogy 12 órát oktatsz egy nap, ismerek is ilyet, de hosszabb távon fenntarthatatlan)

de a hallgatóknak a tudást a PhD-sok adják át

Meg az önálló tanulás/munka, a kötelező/ajánlott irodalmak tanulmányozása etc. Csak a hallgatók szeretik elfelejteni, hogy mit jelent a "kredit" és a 30 óra, és a kettő közti összefüggés... (egy két kredites tárgyhoz kapcsolódó elvárt 60 órányi munka a 12 kontakt órába nehezen fér bele...)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ugyan nem a Princetonon, de már van egyetem, aminek első évét elvégezheted a Coursera-n. Magyarul kreditet kapsz érte. Jó drágán, de még mindig sokkal olcsóbban, mintha on-site lenne. Teljes MBA képzés is van, ha jól hiszem. Csak idő kérdése, hogy komplett diplomát csinál meg így, mert ahogy lehet Java vizsgát tenni ellenőrzött vizsgaközpontban, úgy ennek sincs semmi akadálya. Max egy egyetemi év olyan szakokon, ahol labor fontos lehet.

Egyszer megkérdeztem valakit az egyetemről, aki jelenleg most már igen magas helyen van a ranglétrán, hogy miért csak a villanyból kivélt mérnök infó, illetve a matekból képzet progmat/inf van csak. A válasz az volt, hogy egyrészt megcsinálhatnák a tantervet, beadhatnák az aktuális oktatási minisztériumnak, aminek kb. annyi eredménye lenne, hogy elköltenének másfél milliót meg egy csomó időt. Másrészt nem lenne hozzá ember aki vinni tudná, mert aki volt, az is elment az oktatásból.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Még mindig azt mondom, hogy ez egy alapozó tárgy. Ha egy másod, harmadéves tárgy lenne, akkor teljes mértékben egyetértenék veled - de nem az. olyan embereknek __is__ kell megtanítanod, hogy mi az az algoritmus, a programozást eszik-e, vagy isszák, akik még egy Hello worldöt nem írtak életükben, és algoritmust sem láttak soha.

de megismétlem magam: „de te mégis, hogyan szűrnéd ki azt, hogy az adott hallgató érti-e az alap vezérlési szerkezeteket?”
--
blogom

gyakorlás, gyakorlás, gyakorlás.

pl.: a rajzolásra van itt néhány példa: http://vik.wiki/A_programoz%C3%A1s_alapjai_I._-_1._kisZh
Ha megcsinálod mind a nyolcat, ami itt van (a négy háromszöges tulajdonképpen csak kettő), akkor utána nem hiszem, hogy a többi bármilyen problémát okozhatna. Ülhet melletted gyakorlás közben valaki, de szerintem annak két kimenetele lehet:
- nem csinál semmit, te gyakorolsz, mint egyedül. a pénzt meg tulajdonképpen kidobtad az ablakon. ha problémád van, hagy rajta gondolkozni egy napot, s következő nap segít egy kicsit.
- az első szembejövő problémádnál elárulja a megoldást. ezzel mindent szerzel, csak éppen rutint, s feladatmegoldási késséget nem.

ha a C-t, mint alapozó tárgyat tanuljátok, akkor nem tudod elkerülni, hogy megtanuld az adatszerkezeteket (láncolt lista, dinamikus tömb, etc.), a memóriakezelést, a többit, tényleg, pöpecül, papíron.

btw, melyik egyetem?
--
blogom

Köszönöm a rengeteg hozzászólást, most így egybe írok Mindenre!
Egyetem első év, programozás alapjai. A vizsgán olyan jellegű feladatok vannak, hogy pl. rajzolj ki egy n magasságú háztetőt. Ezeket csillagokkal kell kirajzolni. Egyértelmű, hogy amiatt kell ezt csinálni, hogy fejlődjél és értsd a vezérlési szerkezeteket, de én ennek nem látom értelmét.
Az első körbe jelentkeztem duális képzésre és az biztos, hogy a cégnél már többet tanultam programozni, mint az egyetemen. Ha nem duálisra mentem volna nagy valószínűséggel még az aláírások se lenne meg!
Köszönöm a linkeket! Nagyon hasznosak lesznek!

+1. Én anno másod- és harmadévben fogtam néhányszor a fejem egy-két "kolléga" "szakmai" "kérdésein" (kicsit precízebben: ugyanabban a teremben ülő zöldség picsogásán, hogy valami nem megy). Nálunk az ilyen papíros prog. alap vizsgán még át lehetett menni úgy (sőt: úgy KELLETT átmenni), hogy bemagoltad az órán előadott kódot, kb. változónév szintig és azt írtad le.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

> bemagoltad az órán előadott kódot, kb. változónév szintig és azt írtad le.

Ez ellen iszonyú nehéz oktatóként küzdeni. Én pl. dokumentumba gyűjtöm az összes feladatötletemet, ami kreatív pillanataimban eszembe jut. Cél, hogy kiszűrje, ki gondolkozik, ki nem. Az a hitem, hogy aki mérnöknek való, az össze tudja rakni az ismereteiből a megoldást, nem típuspéldázom. Nyilván kap támpontokat, de gondolkodni tanuljon meg, ne visszaadni.

Ezt persze pontozni is nehezebb, meg a hallgatóknak is egy terror, gondolom, nem is vagyok túl népszerű :-)

Saját sztori... Leányzónak labirintust kellett rajzolni (téglalap random kettéoszt (pozíció, irány), a falon egy lukat hagy, majd a két félre ugyanezt rekurzívan, amíg tovább lehet osztani). Elmagyaráztuk, papíron rajzolgatva, lépésenként az algoritmust, a kilépési feltételt - mindent, olyan másfél óráig... Utána kérdés tőle: de ezt hogy magyarázzam meg a gépnek? Beadott egy olyan programot, amiben a kockás papíron "megtervezett" labirintust rajzolta ki - és megkapta rá az elégségest...

A másik kollegina valamilyen elektronika laboron (fősuli, utolsó év) műveleti erősítők mérése feladathoz kapott két szimpla 15V-os tápegységet. Nagyon nem ment neki ebből a műverősítőnek szükséges +/- 15V-ot összerakni...

+1. És ha a topicnyitónak ezzel gondja van, akkor azért az elgondolkodtató, ha azt mondja, hogy a "cégnél többet tanult programozásról". IMHO legfeljebb kódolásról.

A programozás: bármilyen feladatot (adott nehézségi fokon) meg tud oldani, nem a bemagolt típuspéldákat.

Kíváncsiságból megnéztem, hogyan néz ki a BME kettő féléves programozás oktatása ma.

C: 56 tanóra felesben tanítás+papírprogramozás és 28 tanóra számítógépes gyakorlat és egy egyszerűbb házi feladat.
https://portal.vik.bme.hu/kepzes/targyak/VIEEA100/
https://portal.vik.bme.hu/kepzes/targyak/VIEEA101/

C++: 56 tanóra felesben tanítás+papírprogramozás és 28 tanóra számítógépes gyakorlat és egy egyszerűbb házi feladat.
https://portal.vik.bme.hu/kepzes/targyak/VIIIA114/
https://portal.vik.bme.hu/kepzes/targyak/VIIIA115/

Egyébként a villamosmérnök hallgatók is ugyanezt kapják.

Azóta egy kicsit átalakították, most ez az aktuális:
prog1.: https://portal.vik.bme.hu/kepzes/targyak/VIEEAA00/
prog2.: https://portal.vik.bme.hu/kepzes/targyak/VIIIAA00

A prog1 egyébként az egyik legigényesebb tárgy, amivel az egyetemen találkoztam, Czirkos nagyon profin csinálja. A prog vonalon magasról ver mindenkit.

régen a villamosmérnököknek csak heti 2*2 óra volt, mostmár nekik is 3*2 óra (előadás, gyak, labor), ha jól sejtem.
--
blogom

Sajnos mihelyst nagyon elmentünk a témától törölni fogom a topickot!

Viszont érdekes dolgok hangoztak el itt szóval lehet, hogy érdemes lenne létrehozni egy topicok, ahol meg lehet ezeket vitatni!

Mindig is az lesz. Az még hagyján hogy az akadémisták sose (vagy csak keveset) dolgoztak az iparban és fingjuk sincs az egészről, cserébe az egyetemnek nem is az a célja, hogy az iparba készítse fel a hallgatókat. Az már egy másik probléma hogy a kedves szülőkbe a "diploma = állás" propaganda bele van nevelve, az meg megint egy másik hogy NINCS alternatíva, amit elfelejtenek említeni "az egyetem nem mindenkinek való" károgó kollégák.

Ebből következik ami jelenleg megy, 600 gólya intézményenként, egy része rájön hogy nem érdekli, a talpra esettebb része rájön hogy inkább network-ölésre használja az egyetemet és kilép az iparba diploma nélkül, megint egy másik része befejezi de önmaga sem tudja minek.

Mindenkinek más a célja, az enyém a pénz keresés, ahhoz pedig nem matematikailag és szakmailag kell okosnak lenni ;)

"cserébe az egyetemnek nem is az a célja, hogy az iparba készítse fel a hallgatókat"

Hát akkor mi a franc? Amúgy nem lenne rossz se műinfó, se a progmat képzés, ha megmaradt volna a 20-30 évvel ezelőtti létszámon, mert évi pár tucat kutató beállítottságú emberre is szükség van. Ott hibáztak hatalmasat, amikor a felsőoktatásban tanulók bővítésekor nem új szakot hoztak létre, hanem ezeken emeltek drasztikusan létszámot, mindenkit belekényszerítve a kvázi-kutató skatulyába. Én ezért is hagynám meg a tantervüket, jelentősen csökkentett létszámmal, és új szakokat indítanék.

Alternatíva meg van, menjen el olyan szakra, ahol megkapja nagyjából ugyan azt a matekot, bizonyítások nélkül, pl alkalmazott fizikus/vegyész, már ha van affinitása ezen területekhez, és csináljon egy tdk-t mondjuk a Cern adatainak feldolgozásáról. Vagy egy közgáz-pénzügyi diploma, és akkor az állások egy jelentős részére máris van komoly domain tudása.

De értelmesen is lehetne tömeget képezni. Mostani matek nagyját le lehetne adni bizonyítások nélkül, gyakorlati példákon keresztül, aztán elméleti alapok egy egyszerűbb nyelven (pl python) keresztül bemutatva (algoritmusok, design patterns, tdd, clean code), majd specializáció, pl big data, enterprise szoftverek, web, c/c++, embedded. Utóbbin kívül hardverfelépítést meg flipflopokat szigorúan kukázni. A pénzt ugyan úgy megkapnák, csak használható emberek jönnének ki.

"cserébe az egyetemnek nem is az a célja, hogy az iparba készítse fel a hallgatókat. " Olyan ez, mintha azt mondanád, hogy egy orvosképzésen nem az a cél, hogy "iparban" dolgozó orvosokat, hanem Nobel-díj esélyes kutatókat képezzünk, vagy mondjuk egy tanárképzésnek nem az lenne a célja, hogy iskolákban dolgozó tanárokat, hanem pedagógiakutatókat képezzünk. Vagy mondjuk egy gépészmérnök ne egy gyárban vegyen részt termékfejlesztésen majd a végzés után. Ne légy hülye.

azt hiszem, ez az én saram is, szóval bocs.

btw, ezt a témát már többször végigjártuk itt, s általában ez a vége. vagyunk néhányan, akik csalódtunk az egyetemben, mert nem azt kaptuk, amivel foglalkozni szeretnénk. s vannak néhányan, akik élvezték, szerették, azt kapták, amire vártak - ők nyilván védik a rendszert, mert szerintük jó. ez teljesen szubjektív, ez így van rendjén.
--
blogom

De aki kibukott, vagy abbahagyta, és ugyanolyan sikeres a szakmában, az pont azt bizonyítja, hogy semmivel sem kevesebb, mint azok, akik elvégezték :D Ennyit ér az egész.
Nem véletlenül nem kérnek szinte egyik munkahelyen sem diplomát, a top magyarországi IT munkahelyeken sem.

"Nem véletlenül nem kérnek szinte egyik munkahelyen sem diplomát"

A valosagban nem, ellenben az allashirdetesekben... no persze, tudni kell szurni, de akkor is... A HR-esek felevel kellene valami melyrehatot csinalni, ami elindit egy felfogasvaltast...
--
Blog | @hron84
Üzemeltető macik

Hiába végzel el bármiféle képzést, ha csak a vizsgán való X érdemjegyre hajtasz, és nem arra, hogy az életben is tudd használni, azaz tartósan (és ne csak vizsgára) tudd.

Nehézség: lexikálisan könnyű felkészülni vizsgára, de hamar el is felejtődik. A gyakorlás, a szívás maradandóbb, mélyebb tudást ad. Az oktatási intézmény lehetőségei általában a lexikális oktatás és lexikális számonkérés területén merül ki. A vizsgán még tudod 5-ösre ...
Viszont ha a képzés tematikája mentén nem csak a vizsgán való megfelelésre hajtasz, akkor sokat érhetsz el később az életben. Erre viszont az oktatási intézmény nem ösztönöz, ez csak a te döntésed.

Az oktatási intézményt nélkülöző, a szisztematikus oktatás mellőzésének viszont van egy veszélye: valós probléma, hogy valaki "szakácskönyvből" sémákkal dolgozva ugyan első körben ügyesnek látszik, azonban ahogy komolyodik a probléma, kibukik az alapok hiánya.

Egyúttal az érem másik oldalát is megnézve az is jó kérdés, hogy a munkafolyamat mely szintjére kell ténylegesen az adott területen képzett

- okleveles mérnök
- mérnök
- technikus (ma már nincs sajnos ilyen képzés - pedig igen jó szakembereket adott)
- szakközepet vagy gimnázium+szakma képzést kapott szakember
- szakmunkás

A "mindenhova mérnököt" politikailag is erősen támogatott téves irány nem csak azt rontotta el, hogy az alsó 3 képzés értéktelen lett, hanem hogy a mérnökképzés szintjének sem tett jót a tömegképzés erőltetése.

"Hiába végzel el bármiféle képzést, ha csak a vizsgán való X érdemjegyre hajtasz, és nem arra, hogy az életben is tudd használni, azaz tartósan (és ne csak vizsgára) tudd."
Viszont a számonkérésnél sem a megértés, azaz a tényleges tudás a lényeg, azt vizsgálják, hogy a leadott anyagot bemagoltad-e. Így viszont értelmetlen az egész. Azért a vizsgákra és a kettesre hajtanak az emberek, mert a kettest az oktatás jobban értékeli, mint a tudást.

Formális oktatásra valóban szükség van, pontosabban arra, hogy egy-egy tudományterületet, szakterületet szisztematikusan ismerjen meg az ember. Ez nem vita tárgya. A vita tárgya az, hogy amit nálunk szisztematikusan oktatnak, az mennyire fontos a valóságban.

Én már régóta vallom a következőt:
A magyar informatikaoktatás jeleneg strukturálisan rossz. Ugyanis van mérnökinformatikus képzés, van programtervező informatikus képzés, meg gazdságinformatikus képzés alapszinten, meg pár mesterképzés.
Én úgy látom, hogy a következőnek lenne értelme:
1. szoftverfejlesztő alapképzés. Az ember megtanulja, hogyan kell modern módszerekkel, módszeresen szoftvert fejleszteni, és kinevelik belőle a cowboy codingot. Megtanulja, hogyan kell dokumentációt írni, hogyan kell csoportmunkát csinálni, megtanulja, hogyan kell modern szoftvertervezési mintákat használni. Tanul imperatív, objektumorientált, funkcionális, deklaratív programozást. Ez az alapkézés.
2. Különféle mesterképzések: műszaki informatikai, gazdasági informatikai etc. Ezek arról szólnak, hogyan lehet műszaki problémákat (pl. telekommunikáció, képfeldolgozás, robotika, gyártástámogatás, stb) szoftveresen támogatni. Illetve gazdasági folyamatokat hogyan lehet szoftveresen támogatni, gazdasági problémákat szofveresen modellezni (ERP rendszerek, logisztika, accounting stb.). Vagy éppen egészségügyi problémákat, téképészeti dolgokat stb. hogyan kell szoftveresen modellezni, milyen fogalomkörök léteznek az adott területen belül, amit szoftveresen lehet támogatni.

Mivel aki részt vett az alapképzésen, az már tud modern elvek szerint sokféle módon szoftvert fejleszteni, ezért tudni fogja, hogy speciális szakterületen a szoftverfejlesztési tudását alkalmazni.
Aki pedig szoftverelméleti kérdéseken akar elmélyedni (akár algoritmuselmélet, akár más dolgok), az is mehetne saját mesterképzésére.

Elsőként offtopic: akár/lehetőleg privátban: melyik volt az az egyetem, ahol ennyire rossz tapasztalataid voltak?

Utána: az elképzelés papíron szép, de ha lehet, még a mostaninál is rosszabb lenne. Mondjuk azt, hogy jó, legyen nagyon gyakorlatorientált a képzés, és még több gyakorlati órát bele. Elsőként ki kellene dobni az összes elméleti tárgyat. Utána az összes alapozó tárgyat egy nyelvre kéne belőni, hogy ne a minden félévben más nyelvvel ismerkedjen a hallgató, hanem igaz, hogy egy nyelven, de gyönyörű kódot írjon. És akkor kapnál egy raklap Google-képes C# kódert, aki nem tudja megmondani, hogy miért tetű lassú a kódja -- ami mondjuk cserébe tényleg nagyon szép és jól dokumentált. Egy csomó kódert, aki ha kap egy grafikai problémát, akkor egy darabig néz azokra a fura egymás alá/mellé írt számokra, aztán bezárja az ablakot és felcsapja a StackOverflow-t, hogy neki most milyen openGL/DX hívás kell. Egy csomó kódert, aki több oldalnyi imperatív (de tényleg szép, és jól dokumentált...) kódot ír ahelyett, hogy simán modellezne egy állapotgépet.
Szükség van ilyenekre? Utána nem az következne, hogy de hát az iparnak Java kóderre van szüksége, és a hülye felsőoktatás miért C#-ot képez (vagy fordítva, esetleg a pár ezer másik nyelvvel, természetesen cégenként, projektenként eltérve)?

Azokat az elméleti alapozó kurzusokat (legyen az a matek, lásd a fenti példában a lineáris algebra, vagy egy formális nyelvek / automaták, lásd az állapotgép) nem ok nélkül rakták bele a tantervbe, a gyakorlatiasabb órákon egyszerűen szükség van rá, hogy a hallgató tudja is, hogy mi miért történik, és ne csak azon a szinten legyen, hogy ha meghívod ezt az API-t, akkor valami mágia és ez lesz az eredmény.

A duális képzéses elképzelés akár működhetne is úgy, hogy a BA-s felvételi előfeltételévé tesznek egy 2 éves OKJ-s képzést, ami tényleg arról szól, amit fentebb írtál: egy nyelven tudjon szépen, csoportosan kódolni, mindenből kb. az abszolút minimumot. Innentől kezdve az egyetem számolhatna azzal, hogy a programozás alapjainál nem azzal kell szórakoznia, hogy szintaxist tanít, hanem ott kezdődhetne a tényleges algoritmizálás (most ugye az előadás része inkább az algoritmizálás, a gyakorlat meg egy egyetemfüggő random nyelv szintaxisa), nem lenne az, hogy az első félévben a duális képzőhely és a hallgató néznek egymásra, hogy akkor most mi a franc legyen, mert az egyiknek nincs még semmi használható tudása, a másiknak meg kapacitása betanítani.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Szerintem félreértettél. Sehol nem állítottam, hogy a szoftverfejlesztésnek nincs elmélete. A matematikai logika, a számításelmélet alapjai, az automataelmélet és a formális nyelvek teljesen kötelező dolgok. Meg a gráfelmélet, a diszkrét matematika.

De mondjuk a fizika, a jelek és rendszerek (aka elektromosságtan), az irányításelmélet, a differenciálegyenlet-rendszerek, meg úgy általában az analízis az nem. Az úgymond az "analóg" mérnökök felségterülete, műszaki problémák megoldásához kell, de szoftverfejlesztéshez nem. A formális nyelvek meg igen.
Nem, nem kell kidobni az összes elméleti tárgyat, ezt a dolgot csak te látod bele a kommentembe.
Én csak annyit mondtam, hogy a szoftverfejlesztési és a nem szoftverfejlesztési, úgymond 'business domain' dolgokat különítsük el. A business domain ezesetben lehet automatizálás (irányítórendszerek), lehet ERP, lehet egészségügy, lehet térinformatika, lehet gépészet, bármi más, ami nem szoftverfejlesztés.
Mert mi az informatika lényege? Számítógépes (azaz szoftveres) támogatást adunk a való világban folyó problémák megoldásához. Ennek két vetülete van: 1. a szoftverfejlesztési vetület, amely minden probléma számítógépes támogatásához kell, és 2. a problémaspecifikus vetület, amelynek vannak külön szakemberei (gépészek, egészségügyi mérnökök, térképészek stb.).
Hogy értsed: szoftverfejlesztési vetület az, hogy egy tömböt hogyan kell rendezni, és hogyan hatékony (adastruktúrák, algoritmusok elmélete), míg a business domainbe tartozik, hogy éppen miknek a tömbjét kell rendezni, hogy megkapjuk a várt eredményt (mondjuk egy logisztikai probléma megoldásánál).

Sehol nem állítottam, hogy egy nyelvre kéne belőni minden tárgyat. Például lehet elméleti síkon (legalábbis alapszinten használt fogalmakkal) a konkurens programozást (szemaforok, lockok, liveness, stb.) és megnézni gyakorlaton, hogy X, Y és Z nyelven ez hogyan valósul meg. És fel lehetne venni a Konkurrens programozás elmélethez Konkurres programozás C# nyelven/Java nyelven/C++ nyelven gyakorlati kurzust, mindenkinek igénye szerint, miben akarja képezni magát.

Remélem jobban sikerült megértetnem, szerintem hogyan lenne értelmesebb a képzés.

A legtöbb, amit írsz, AFAIK most sincs benne a kötelező modulokban, ami kötelező, az a tényleg szükséges fejlesztői ismeret.

Itt pl. lentről felfelé halad a tanterv, gyakorlatilag minden szintet érintve, mind elméleti [HW, OS, hálózatok, adatbázisok, grafika, multimédia, mesterséges intelligencia stb.] mind gyakorlati [assembly, C, sh, Java/C#, SQL, Flash stb. és egy kötelező kurzus keretében Prolog/Haskell/Smalltalk is, hogy visszatérjek a fenti kommentedre] oldalról. Szabadon választhatónak ott vannak, amiket írsz, de egyik se kötelező, az már érdeklődési területtől függ.

De mondjuk a fizika, a jelek és rendszerek (aka elektromosságtan), az irányításelmélet, a differenciálegyenlet-rendszerek, meg úgy általában az analízis az nem

Analízissel részben egyetértek, a többit nem tudom megítélni, mert nálunk nem volt kötelező. Az analízisen tanultakat tényleg szinte soha nem használtam azóta sem, de azért egy megugorható dolog...

Szerk.: Az egy nyelves dolog meg két oldalról jött: egyrészt nincs idő (értsd: kreditszám) több nyelvre "kóderkurzusra" (mármint ami tényleg csak azzal foglalkozna, hogy abban az adott nyelvben hogyan kell fejleszteni). A "mindenki válasszon, amit akar" meg több szempontból veszélyes, elsőként alaphangon több oktatóra lenne szükség (nem feltétlenül akarok Java/C# kódot látni egy C++ fejlesztőtől, és viszont; ha pedig ugyanolyan színvonalú a három nyelvű kódja, akkor egyikben sem jó igazán), másrészt retek nehéz lenne összeegyeztetni a három féle kurzus tematikáit/értékelését

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Az ELTE-n lehet hogy nincs benne programtervezőben. De egy mérnök-informatikus alapképzésben igen.

És épp ez a hülyeség: alapképzés egyféle kéne, hogy legyen: szoftverfejlesztési. Hiszen minden informatikai támogatás a valós életbeli problémák megoldásáról szoftverekről szól. Akár legyen az TCP protokoll (hiszen az is szoftver), akár legyen az egy OCR. Az is szoftver. Még ha vannak hardveresen gyorsított (vagy teljesen hardveres) megvalósításai.
Mesterképzés meg lehet sokféle.

A multimédia, az AI (szakértői rendszerek) is mester dolog szerintem (mármint olyan értelemben, hogy nem szoftverfejlesztés, hanem business domain).

Nézz meg egy BME infó tantervet:
https://www.vik.bme.hu/page/800/
Analízis (ráadásul szigorlattal), fizika több félévben, valszám, viszont van egy csomó olyan specializáció, ami helyett (hiszen ezek már business domain dolgok) lehetne tanítani a szakmai törzsanyagot alaposabban. Vagy éppen nincs funprog, a deklaratív is csak választható (elágazó) tárgy. És ez az ország top mérnökképzése informatika terén elvileg.

vagy nézd meg mondjuk Győrt, Veszprémet, hogy mi az informatikus mérnököktől elvárt kötelező (alap)ismeret. Tele van 'analóg' műszaki ismerettel, amire sok szükség nincs szoftverfejlesztésnél, más domainhez tartozik. Nincs szoftverfejlesztő mérnökképzés igazán az országban.

Szerk. a több nyelves részhez: igen, az igényes oktatáshoz több oktatóra van szükség. Meglepő?

Mivel a legtöbb esetben nem strukturális átalakítást végeztek, hanem elvágták az 5 éves tanterveket a hatodik/hetedik félévnél.
Csak azt felejtik el, hogy nyugaton például PhD-hoz nem kell mesterképzés.
Például egy MIT PhD megkezdéséhez elég egy alapképzés: http://www.eecs.mit.edu/academics-admissions/graduate-program/faqs#1
A hallgatók a képzés közben kapnak egy mester oklevelet.
Vagy mondjuk egy Stanford PhD-hoz. http://www-cs.stanford.edu/admissions/faq#a1

De persze a magyar felsőoktatás jobban tudja, mint a világ top IT intézményei.

És épp ez a hülyeség: alapképzés egyféle kéne, hogy legyen: szoftverfejlesztési

Majd wachag mindjárt jön, és leírja, hogy ez "hivatalosan" miért rossz ötlet, én csak a saját tapasztalataimból tudok kiindulni: egyik kurzus keretében egy szoftverfejlesztéses projektben szándékosan úgy alakították ki a csoportokat, hogy legyen benne mindhárom alapszakosból (pti, mérnök, gazdasági informatikus), hogy a korábbi években tapasztaltaknak (pti-sek összeálltak, és a maradék mérnök/gazdaságis semmire nem haladt) véget vessenek.

Ha másra nem, arra tökéletes volt az a projekt, hogy lássam, hogy jobb, ha a mérnökurak maradnak a drótjaiknál meg a kis műszereiknél, és nem szabad kódhoz engedni őket :) [a gazdaságinformatikus meg írogassa a projektjelentéseket, managernek még jó lesz az :) ]

Nem ugyanaz a tudás kell egy HW tervezőnek és egy programozónak (a gazdinfót én sem értem, hogy miért kell ennyire külön)

igen, az igényes oktatáshoz több oktatóra van szükség. Meglepő?

De PhD-s ne tartson órát (ezt ugye te írtad) és túl van fizetve a felsőoktatás (ezt azt hiszem valaki más).

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

1. Ha az intézményben nincs pti, meg mérnök meg gazdinfós egyszerre, akkor mi van? Akkor nincs kurzus? Ne hülyéskedj. A másik meg: valóban nem ugynaz a tudás kell a HW tervezőnek, de nézd meg, mi kell az iparnak? HW tervező vagy profi szoftverfejlesztő? Melyikből kell több, mire kell hangsúlyt fektetni? A HW tervezés tipikus mesterképzési dolog. (Hint: a mesterképzésnek nem feladata a PHD előkészítés, Amerikában el is különül a dolog. A mesterképzés ipari vagy tudományos specializáció). Viszont szoftvert fejleszteni mindegyiknek kell.

Sehol nem írtam, hogy PhD-s ne tartson órát. Hanem: azt az önbecsapást, önellentmondást, miszerint a KKK-t profok neve alatt akkreditálják, de a valós oktatásban már nem kapnak szerepet (csak a név kell), azt adjuk fel. Valljuk be, hogy nálunk Magyarországon a tárgyak felelősei PhD-sok. Igen, szarabbul állunk, mint a nyugati profok, ahol mondjuk Fizika 1-et (klasszikus mechanikát) oktat a húrelmélet kitalálója a Stanfordon, de legalább nem lesz ellentmondás a papír és a valóság között és senki nem hazudik senkinek. Ez az önbecsapás végigmegy az egész magyar felsőoktatáson, generálunk statiszikákat, hogy így de milyen jó, úgy de milyen jó az oktatás, miközben a diploma nem feltétele a munkavégzésnek, és nem is várják el (ezzel jelezve a hozzáadott értékét az emberanyaghoz), valamint a teljes magyar felsőoktatás annyiból gazdálkodik (az összes egyetem összes képzése), mint a bonni egyetem. Vicc az egész, túl komolyan veszik, akik benne vannak, de az európai képzésekhez képest rendszerszinten sehol nem vagyunk. Persze vannak emberek, profok, akik személyesen, egyenként ismertek külföldön, ezek kiemelkedő eredmények, de rendszerszinten sehol nincs az egész.

mi kell az iparnak? HW tervező vagy profi szoftverfejlesztő? Melyikből kell több, mire kell hangsúlyt fektetni?

Az utóbbi évekről nem tudok nyilatkozni, amikor még oda jártam, akkor a diplomás pályakövető szerint a mérnökösök tudtak inkább elhelyezkedni a szakmában.

Viszont szoftvert fejleszteni mindegyiknek kell.

Nem tudom, a személyes véleményem, hogy "isten ments, bármit, csak azt ne", ebben szerintem nem fogunk kiegyezni :)

valamint a teljes magyar felsőoktatás annyiból gazdálkodik (az összes egyetem összes képzése), mint a bonni egyetem. Vicc az egész, túl komolyan veszik, akik benne vannak, de az európai képzésekhez képest rendszerszinten sehol nem vagyunk

És ezt a kört (mert ez egy öngerjesztő folyamat: nincs pénz - alacsonyabb a színvonal, mint máshol - nem vesszük figyelembe a munkaerőpiacon - állami szinten nem is adunk rá pénzt) az egyetemeknek kéne megtörnie? (Akiknek ugye pont nincs erőforrása, hogy megtörjék ezt a kört)

Az oktatás egyébként még egész jó, ahol mindig nagyon kijön a pénz/erőforráshiány, az a kutatás. Ha itthon találta volna ki / fedezte volna fel a húrelméletet (a megfelelő aláhúzandó) egy prof, lehet, hogy ő is fizika 1-et tanítana - csak itthon ha bele akarsz fogni egy kutatásba, azt többnyire azzal kell kezdened, hogy keresel hozzá valami pályázatot/kutatói ösztöndíjat, hogy meg tudd teremteni a feltételeit - és ez tudományterülettől függetlenül így van (a fenti példánál maradva a húrelmélet megalkotásának a feltétele pl. az, hogy akár több évig főállásban kutathass és ülhess a whiteboard előtt, amit itthon nem tudsz megtenni)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

1. De azt nézd meg, hogy az elhelyezkedett mérnökök mit csinálnak? Hw-fejlesztést vagy sw-fejlesztést? Egy párhuzamos hasonlat: elhelyezkedni a gépész is el tud a szakmában, csak nem mindegy, hogy gépsorokat felügyelő üzemmérnök lesz belőle, vagy termékfejlesztő mérnök. Mindkettő gépész feladat, mégsem mindkettőre képzik az embert.

"Nem tudom, a személyes véleményem, hogy "isten ments, bármit, csak azt ne", ebben szerintem nem fogunk kiegyezni :)"
Pedig talán DE. Nekik is meg KELL tanítani a szoftverfejlesztést. Én is mérnök-informatikus szakra jártam, de láttam a hasztalanságát (meg azt, hogy egyetem befejezése nélkül is kerestem annyit projekt vezetésével, mint a többiek végigszopott értelmetlen diplomával), ezért inkább dolgoztam. A legtöbb mérnök-informatikusból is szoftverfejlesztő lesz. Nézz csak meg álláshirdetéseket, ahol diplomát írnak elő (de valójában nem kérnek): mérnök végzettséget várnak el. Épp ezért nekik is tudniuk KELL a helyes szoftverfejlesztést.

Ha nincs elég pénz, akkor két dolgot lehet tenni (az elmúlt két országgyűlési választás megmutatta, hogy az ország nagy többsége nem akar több pénzt adni az oktatásra): vagy kevesebb terjedelemben oktatunk (kevesebb tantárgy, tényleg csak a szükségesek, ami értéket ad a diplomának, és nem lesz az ipar számára egy elhagyható dolog), vagy kevesebb embernek oktatunk.

Az egyetem ne karba tett kézzel üljön, hanem tegye meg azt, ami szerinte ahhoz kell, hogy a munkája megkerülhetetlen legyen a munkaerőpiacon is. Jelenleg nem az. Mindig könnyű másra mutogatni, ezt az egész ország baromi jól tud. De változtatni te is csak ott tudsz, hogy rendszerszinten jobb lehgyen minden, amiben döntési jogköröd van. Te nem vagy oktatási miniszter. Így a saját szinteden kell megoldani a dolgokat.

A duális képzés bevezetése például egy erős jel arra, hogy inkább az iparban kapjanak képzést a hallgatók, mert amit az egyetemen kapnak, az nem elegendő ahhoz, hogy értékes szakemberek legyenek.

"vagy kevesebb embernek oktatunk"

Az egyetemek (és a főiskolák is) elsősorban a hallgatók száma alapján jutnak bevételhez. Költségtérítés esetén ez triviális, de az államilag támogatott hallgatók után is fejenként fizet az állam. Szóval az, hogy kevesebb embert oktatnak, pont nem enyhít a kevés pénz problémáján.

kevesebb tantárgy,

Három év múlva kuka, mert nem megy át az akkreditáción, ami az állam által előírt feltétel.

vagy kevesebb embernek oktatunk.

Kb. a következő félévben kuka, mert a nagyjából hasraütés-szerű finanszírozás (AFAIK már kikerült a 2011-es felsőoktatási törvényből, hogy 2012-re rendeletben meghatározzák a finanszírozás módját, mert azt máig nem sikerült) nagyjából azért hallgatószám-arányos.

mérnök végzettséget várnak el.

Az úgy jobb lenne, ha átneveznénk a szakokat, és lenne egy hardware-mérnök informatikus és egy szoftvermérnöki szak?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Info az nem kizárólag programozás, pl ott van a robotika, biomatika ott pont kell irányításelmélet, diffegyenlet rendszerek, analízis, meg még egy csomó minden más, pl lie csoportok, lyapunov, gradiens reduction, variáció elmélet, meg még pár nyalánkság a modern módszerek megértéséhez. A bizonyítás is azért kell, mert így lehet megérteni magát a módszert, sőt lyapunov módszere bizonyítás nélkül nem is használható.

A használható tudás meg nem a gyakorlati tudás, hanem a gyakorlatban is alkalmazható tudás. Kicsinek tűnik elsőre a különbség, pedig az első jelenti azt, hogy megtanítunk sémákat a hallgatónak, és azokat alkalmazza, míg a másik az, hogy kap egy mély elméleti tudást, valamint a kulcsot, hogy használja a gyakorlatban. Ezzel a másodikkal sokkal könnyebb fejlődni, ha változnak a trendek könnyebb követni, és pár év múlva, amikorra az első elavul, a volt hallgató szentségel, míg a másodiknál meg sem érzi a váltást.

Mondjuk az a személyes véleményem, hogy sok helyen robotikából eleve elavult dolgot tanítanak (csak lineáris irányításelméletet), de azért jobb helyen már tanítják a nemlineárist is (mondjuk ez nem csak kicsiny hazánkra jellemző, hanem ez a világ átlaga). Személy szerint mivel ezt a területet kutatom én megmutatom a srácoknak a legújabb dolgokat, valamint próbálom minél érthetőbben és egyszerűbben elmagyarázni, megmutatva a "bűvésztrükk" mögötti dolgokat is.

Amúgy az oktatási rendszerünk nem az amerikai rendszer, hanem a német, pl nálunk ezért van a PhD után Habil fokozat is, ami csak pár országban van a világon, szóval a MIT és a Stanford rendszerével való hasonlítás nem fair. Nem ez a baj a mai felsőoktatási rendszerekkel. Pl ha már amerikai példánál vagyunk akkor ne felejtsük el, hogy azért ott van rengeteg szar egyetem is, ami bőven rosszabb mint a mi egyetemeink. Szerintem a probléma ott van, hogy mit és hogy akarunk oktatni persze át is kell konvertálni, de ha bemész egy Stanford-ra ott is azt látod, hogy csomó matek, csak érthetően elmagyarázva, átbeszélve. De ez megint világjelenség, van pár egyetem akik átálltak, és már nem a sablonokat tolják a ma divatos kompetencia alapú oktatást már rég elfelejtették.

Egyébként iparból hallottam már olyanokat, hogy nem érdekli őket, hogy pontosan mit tud a kedves hallgató, mert olyan rendszereket úgysem láthattak mint ami náluk van (mert saját). Őket egy dolog érdekli, hogy az adott saját tanfolyamukon mennyire gyorsan képesek megtanulni és mennyi a "hibaszázalék". Persze ez egyedi eset, de ilyen is van.

En az egesz vilagodban azt birom, hogy elegansan sikerult kihagyni az informatika temakorebol az uzemeltetoket, akiknek szinten szuksege lenne egy egysegesitett altalanos kepzesre. Mert jelenleg csak a nagyon valtozatos OKJ-rendszeru kepzesek vannak, iskolafuggoen elavult kontenttel. Sem egyseges iranyvonal, sem egyseges kovetelmenyrendszer nem korvonalazodik, viszont szamolatlanul jonnek a semmihez se erto uzemelteto-jeloltek.

Pontosabban, en eddig ketfele jelolttel talalkoztam: a verpistikekkel, akik a szomszedsag gepeinek "rendbetetele" utan uzemeltetonek ereztek magukat, de az ISO-OSI retegrol azt hittek, valami CD-kkel kapcsolatos dolog, meg a profi uzemeltetokkel, akik par evvel a hatuk mogott is tobbet tudnak felmutatni, mint a masik csoport barmely tagja. Es kesz, ez a paletta ket szine.

Az uzemelteteshez szukseges lenne egy alapozo szoftverfejlesztoi kepzes nagyon light-os matekkal (bash scriptinghez sosem lesz szukseged az egyetemi matek 85%-ara, az inkabb a szoftverfejlesztok terulete), valamint betekintessel legalabb 5-6 programnyelvbe ugy, hogy kozben valamelyik scriptnyelv a fo irany (python leginkabb, arra van egy csomo ember). Funprog, OO prog alapok, hogy eligazodjon a kodban, halozati alapismeretek, es sok-sok, nagyon-nagyon sok gyakorlati pelda kulonfele rendszerekkel, Windowssal, Linuxszal, BSD-vel, lasson minel tobbet es tobbfelet. Aztan lehetne szakosodni, bevenni az iparagi kepzesek egy reszet a tananyagba (Windows eseten pl az MCSA kepzes elemeit, Linux eseteben ugye ott az RHCS, halozatosnal adja magat a CCNA).

Es maris sokkal jobb minosegu emberanyag lenne az uzemeltetesben is, illetve a cegeknek is jobban lehetne valogatni. Az a problema, hogy nullkilometeres uzemeltetokent nagyon nehez elhelyezkedni, mert annyira valtozatos a kepzesek minosege, hogy meg azt sem lehet egy jeloltrol feltetlezni, hogy latott mar IP cimet.
--
Blog | @hron84
Üzemeltető macik

A matek abszolút nem tanítása, és a vizsgán a bemagolt bizonyítások szó(használat) szerinti visszakérése között nagyon sok átmenet van ám.

"aki nem tudja megmondani, hogy miért tetű lassú a kódja -- ami mondjuk cserébe tényleg nagyon szép és jól dokumentált"

Azt hiszem ebben a fél mondatban gyönyörűen kijön a felfogásbeli különbség. Egyrészt ne dokumentációt írjon, hanem olvasható kódot. Másrészt amit leírtál az kívánatos, ne optimalizáljon (idejekorán és feleslegesen), mert az többnyire az olvashatóság rovására megy, és a kód 9x%-a úgy sem lesz kritikus. Az optimalizáció ráér, ha kiderül, hol vannak bottleneckek, mert a fejlesztési idő döntő része arra megy el, hogy más által megírt kódot értelmezel.

A dokumentáció és a szép kód szó szerinti idézet volt persicsb-től, aki ezeket emelte ki, mint tanítandó dolgokat.

Nem azt mondom, hogy álljon neki mikrooptimalizálni, azt mondom, hogy, miközben írja a kódot, tudja, hogy az úgy abban a formában O(n!) idejű és inkább gondolkodjon el rajta.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Ha a bizonyítást bemagolod, akkor - ne haragudj - félreértetted a lényeget. Soha nem magoltam be bizonyítást. Legfeljebb a kezdőötletet kellett megjegyezni, utána a többi lépés általában logikusan következik.

Imho az analízis a közgazdaságtanos dolgoknál elég használható.

A legtöbb hallgatónál két külön dolog, hogy mi lenne a kívánatos, meg hogy mire van ideje, képessége. Lásd kutatóképzés kiterjesztése több száz emberre, akiket nem is érdekel az adott anyag, mert nem azért jöttek, hanem mert nem volt más választásuk informatikai területen.

Amúgy külön vicces, hogy amiről beszélek, azt még a fizikus oktatásban is felfogták. Általános alapozó matek tárgyakban elvétve van bizonyítás, csak tudd használni, és értsd. Mert az nem igaz, hogy csak akkor érted, ha be is tudod bizonyítani. És mivel nem in medias res, semmihez nem kapcsolódva oktatják, hanem közben klasszikus mechanikán már látod is, hogy mire jó, sokkal könnyebb abszolválni az anyagot. A bizonyítós, mélyebb analízist meg meghagyják az elméleti fizika szakirányra. Ezek után senki sem fogja nekem megmagyarázni, hogy informatikusokat kétszer annyi ideig, bizonyításokkal együtt kell szivatni matekkal, mert állítólag így majd jobban megértik, meg majd egyszer talán így hamarabb tanulnak meg új dolgokat.

Baromi jo, hogy neked ez logikusan mukodik... de gondolod, hogy ezzel mindenki igy van? Mert a sajat peldad arra jo, amire az en peldam: semmire. Az emberek tobbsege - meglepetes - de a szamara unalmas, vagy haszontalannak erzett dolgokat bizony bemagolja. A tortenelem is milyen szep logikus sztori lenne - de a legtobben valamiert megiscsak bemagoljak az evszamokat a vizsgara, es utana ket honappal azt se tudjak, mikor koronaztak meg szerencsetlen Szent Istvant.
--
Blog | @hron84
Üzemeltető macik

Mint írtam, az egyetem nem való mindenkinek. Aki csak kódolni akar, esetenként kevesebb mögöttes rálátással, az vígan meglehet nélküle.

A matematikáról: amúgy meg vicces, hogy a tananyag 1%-a (mert az egész képzésnek ekkora része a bizonyításos rész) miatt csipogtok ilyen hevesen. Ami még ráadáaul nem is mély dolog, csak az alapok, kb. a minimum (BME villanyon/infón első félév analízis jobb helyen gimnáziumi anyag...).

Népszerű még szidni a gráfelméletet meg a lineáris algebrát, hogy minek. Ez meg végképp mosolyogtató (gráfelmélet: keresések, social web; lin. algebra: 3D).

Hozzáteszem: komoly bajok vannak szerintem a mérnök informatikus képzéssel, de pont ezek szerintem nem oda tartoznak.

+1

a matematikai bizonyítás már csak azért is egy nagyon hasznos tudás, mert azon keresztül megtanulod, mikor teljes egy feladat megoldása. mint a vicc szerint, „3 prím, 5 prím, 7 prím, 9 - mérési hiba, 11 prím, 13 prím”.

rengeteg olyan emberrel találkoztam évfolyamcsoportokban, aki matek vizsgán egyszerűen azt sem látta, hogy az általa adott bizonyítás egy feladatra („megnéztem egy esetre, arra igaz, akkor biztos a többire is”, vagy „nem tudtam olyan esetet mondani, amikor nem igaz”, etc.) miért nem jó. és akkor kötsögtanszékezik, meg reklamál, meg hisztizik, hogy miért nem kapott pontot.

és egy fejlesztőnek __tudnia kell__ belátni, hogy az általa adott megoldás minden esetet lefed. és nem hiszem el, hogy üzemeltetésnél ugyanez nem jön elő, és fél-megoldásokkal (ami eszembe jutott, azt lefedtem) el lehet lenni.
--
blogom

Most már kicsit visszavehetnél a pökkhendiségből, leírtam párszor, hogy a baj a MAGYAR INFORMATIKA egyetemi képzéssel van, nem az egyetemekkel általánosságban. De amíg egy egyetemeken oktató(?) reakciója a kritikára abban kimerül, hogy homokba dugott fejjel mantrázza "az egyetem nem való mindenkinek", addig ez nem is fog változni..

"Népszerű még szidni a gráfelméletet meg a lineáris algebrát, hogy minek. Ez meg végképp mosolyogtató (gráfelmélet: keresések, social web; lin. algebra: 3D)."

És a kikerülő informatikusok 80%-a csak moziban fog 3d-t látni életében :) Ennyi erővel tényleg minden létező domain ismeretet is meg lehetne tanítani, és előbányászni hozzá egy volt diákot, aki tanúsítja, hogy egyik munkájánál milyen hasznos volt. Az általad írt két matek tárgy a szakirányra tartozó tárgyak mintapéldányai. Bevezetés legyen, a tudja minek olvasson utána szinthez, de több nem kell alapozásnak. És ha lehet az a több se száraz tantermi anyag legyen, hanem programozási gyakorlat.

Azért azt elárulhatnád, hogy pontosan mit értesz műinfó alatt, mert azért eléggé szerteágazó. szerintem ha elkezdenénk összeszedni nagyon hosszú lenne a lista. Amit kifogásolsz az néhány helyen létszükséglet. Szerintem egyébként közel vagyunk ahhoz, hogy a "műinfó" "szétesik" sok apró darabra és sok tudományág lesz belőle.

+1

Játsszunk el a gondolattal, anno a saját csoporttársaim ezeket mondogatták (gazdaságinformatika):
- "dehát ez a sok matek hülyeség"
- "dehát ez a sok gazdasági tárgy felesleges" (akkor miért jössz gazdaságinformatikára, te hülye?)
- "dehát kicsit sok az infós tárgy"
- "dehát minek nekünk jog?" (btw egy félév, kifejezetten IT-s jogászkodás)
- stb.

Gyakoraltilag olyan, mintha az illető egy darab választható JavaScript gányolás fejlesztés óráért iratkozott be egy 3.5 éves képzésre.

Powered by az én adóm (is). Köszönjük.

És ez nem informatikai, hanem logisztikai probléma, a logisztika domainjébe tartozó algoritmus máris. Hasonlóan mondjuk egy legrövidebbút kereséshez a GPS-nél.
Azt sokan elfelejtik, hogy hiába az algoritmuselmélet, sok algoritmusnak nem informatikai felhasználása (domainje) van, csak éppen informatikusok azok, akik szoftvert építenek az adott algoritmusokra.
Mint ahogy gyártórendszerek ütemezése sem informatika, de attól még algoritmusok vannak hozzá, amelyet az adott domain használ.

Persze az informatikaoktatást is lehetne úgy csinálni, mint az orvosképzést: 5 év osztatlan képzésben megtanulsz minden elméletet, általánosan, majd utána még 3 évig szakképzed magad. Mindeközben informatikusból nagyságrendekkel több kell, mint orvosból. Jelenleg az informatika (pontosabban a szoftverek) az élet minden területére rohamos léptékben veszi be magát, az egyik következő szint az IoT és az okosotthonok lesznek. Épp ezért kell sajnos vagy nem sajnos, célirányosan képezni embereket. Ha nem tetszik ez, ne hívjuk ezt egyetemnek meg mérnökségnek (sokan inkább a craftsmanship szót használják engineering helyett), de akkor az oktatási rendszer is készüljön fel arra, hogy mit kell képezni az ipar számára. Mert az oktatási rendszer az nem l'art pour l'art létezik, annak célt kell szolgálnia. A közoktatás is célt szolgál, a felsőoktatás is. És az akadémia is.

Oké, akkor annak a meghatározása, hogy egyszálú programban legkevesebb hány függvényhívás történik két függvény meghívása között. Tök más (és tisztán szoftverfejlesztői) probléma, a megoldás ugyanaz lesz: fogj egy gráfot (a pontok a függvényhívások, az élek az egymás utániságot fejezik ki, mindegyiknek azonos a súlya), és keress rajta legrövidebb utat.

Szerk.: ha már szerkesztetted és még egy bekezdést hozzátettél. Ez továbbra is papíron szépen hangzik (fentebb írtam én is, bár én 2[OKJ-s kóder]+3[szoftvermérnök/hardwaremérnök]+2[mesterképzés] osztásban), de van az, hogy interdiszciplinaritás. Hol húzod meg a határt, hogy mi a tisztán informatikai és "egyéb" feladat?

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Igen, ez valóban gráfelmélet, de itt a másik rész: nem kell tudnod a bizonyítását sok gráfelméleti problémának ahhoz, hogy alkalmazni tudd azt. Az, hogy egy adott problémát gráffal kell és lehet modellezni, majd utána gráfelméleti algoritmusokkal megoldani, az egy alkalmazása a legrövidebb út problémának. Magukat a fogalmakat kell ismerni, tudni kell használni, de a bizonyítás nem annyira lényeg.

Mint ahogy egy gépész sem feltétlenül tudja levezetni korrektul a Hamilton-mechanikát és az Euler-Lagrange egyenleteket, de tökéletesen tud gépelemeket tervezni és alkalmazni a mechanikát. És ő ugyanúgy mérnök, és használja a fizikát, de nem fizikus.

Szerintem tényleg el kell különíteni az elméleti informatikai dolgokat (számításelmélet) meg a számításelmélet alkalmazását. Alkalmazni ugyanolyan jól tud egy mérnök alaptudományos dolgokat szoftverfejlesztőként, mint gépészként a fizikát.

Tudom, sok helyen a matematikus szakból, matematikusok által oktatkva alakult ki a programozás oktatás, így elméleti megközelítést használnak és várnak el, valahol meg villamosmérnökök által, így inkább mérnöki, 'alkalmazói' megközelítést.

Az informatika tudományos szinten talán ott tart, mint a fizika/klasszikus mechanika a 18-ik században: nagyon komoly tudományos munka után elkezdődött azon mérnöki tudományok kialakulása is, amelyek ezeket a tudományos, úgymond elméleti ismereteket csak alkalmazói szinten ismerték, hiszen nekik nem az elméleti probléma mély megértése a feladata, hanem a valóságban felmerülő problémák megoldásánál alkalmazni azt.
Az informatika is szét fog, szét KELL hogy váljon ilyenekre.

Sehol nem állítottam, hogy nincs szükség elméleti informatikára. Azt állítottam, hogy szoftverfejlesztő mérnököknél nem az elmélet mély megértése a lényeg, hanem az alkalmazása. Ehhez persze a fogalomköröket ismerni kell, de a lényeg: a szisztematikus alkalmazhatóság a lényege a dolgoknak. És a szisztematikus alkalmazhatóságnál nem formális bizonyítások a lényegek.

nem.

ez azért kell, hogyha elér rakod egy komplex, de __informatikai__ feladatot, akkor képes vagy belátni, hogy a te megoldásod jó, és helyes. nem csak azt, hogy az általad kitalált néhány teszt-esetre jó. nem csak azt, hogy két hónap tesztelés alatt nem jött elő olyan eset, amit nem jól kezeltél le. hanem azt képes vagy belátni, hogy __minden__ esetet kezeltél, és __minden__ esetet helyesen kezeltél. ami feltételezéssel éltél, azzal élhettél adott esetben. ami következtetést levontál az adataidból, azt levonhatod. etc. ez márpedig informatikai feladat.

ha ezt nem érted meg, akkor nem tudok rajtad segíteni.

(az egyszerűbben jegyzed meg, meg az az eset, hogy pl.: az intervallum gráf definícióját lehet, beseggeltem volna így is, úgy is, de így, hogy tételt tanultam hozzá, meg bizonyítást, évekkel később is rémlik legalább az, hogy létezik ilyen, hogy intervallum-gráf - és jön szembe olyan probléma, ahol ez segített már. ellenben egy olyan definíció sem ugrik be, amihez nem tanultunk legalább egy tételt, bizonyítással, pedig 4 év középsikola és 2 félév egyetemi matek alatt volt néhány.)
--
blogom

Oké, kivesszük az összes bizonyítást. Tegyük fel, hogy életedben nem láttál semmilyen bizonyítást.

Igazold az alábbi algoritmus helyességét és teljességét (mert mondjuk ezzel az algoritmussal viszel fel valakit a holdra, bonyolítasz napi millió dolláros nagyságrendű tranzakciókat stb.):


random algoritmus

Hogy állnál neki?

Vannak dolgok, amiket tudni kell formálisan bizonyítani, és ahhoz nem árt néhány bizonyítási stratégia ismerete.

[fentebb valaki emlegette a középiskolai oktatást. Tiltsuk be a Pythagoras-tétel bizonyítását, mert oldalhosszok számításához nincs rá szükség?]

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Mert minden helyzetben megengedheted magadnak, hogy felvegyél egy matematikust (bármi lehet: anyagi, patent, stb.).

A második felére meg: ha egyik fejlesztő sem látott még életében bizonyítást (mert e mellett kardoskodtok), akkor vak vezet világtalant, hiába bámulják ketten.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Függ tőle az életem? Mi van? :D Tudod többnyire nem egy ember fejleszt szoftvereket, hanem egy heterogén csapat, és mindenkinek meg van a maga felelőssége. Ti mekkmestereket akartok képezni, akik mindenhez értenek egy kicsit, de igazán semmihez se. Nem nekem kell hinni a matematikusnak, hanem az én főnökömnek. Aki egy elte/bme-s mekkmesternek, aki 1-2 féléven át tanulta adott dolgozt bizonytalan lelkesedéssel, miért hinne jobban, mint egy azért nagyon komolyan megfizetett szakembernek?

Igen, ha tényleg az életed függ tőle (mármint a cég élete), akkor fel KELL venni egy vagy több elméleti szakembert. Ez nem kérdés. Például biztosítóknál életbevágó a business számára a korrekt elmélet. Rengeteg matematikus dolgozik is náluk. Az elméleti szakembernek helye van. De ez nem jelenti azt, hogy mindenkiből elméleti szakembert kell faragni. A matematikusok is így gondolják: nem kell mindenkinek formális logikával és bizonyításelmélettel foglalkoznia ahhoz, hogy tudjon értelmes matematikát csinálnia.

Nem sikerült megértened a hasonlatot. A matematikusnak a bizonyítások a szakmái, ezért alkalmazza a bizonyításelméletet mint alaptudományt. De nem kell szakembernek lennie benne. Egy mérnök pedig alkalmazza az elméleti ismereteket, de nem kell szakembernek lennie az alaptudomámyból. Van a saját szakmájának elmélete és gyakorlata, azt kell tudnia. Egy építészmérnök sem fizikus, egy gépész sem fizikus, és egy vegyészmérnök sem kémikus és egy orvos sem biológus. Igen, értenek valamilyen szinten a fizikához/kémiához/biológiához, de nem szakemberei annak a területnek, mert a tudásuk/idejük nem fizikai/kémiai/biológiai alapkutatás, hanem alkalmazás.
És nem 1 tétel bizonyításáról beszélünk, hanem arról, hogy mire kell egy informatikai mérnök oktatásban helyezni a hangsúlyt.

Ehhez még annyit: sokkal inkább ne lásson bizonyítást, de írjon tiszta kódot, unit és integrációs teszteket, meg legyen a csapatban tesztelő, aki feature, cdc meg system teszteket ír, és akkor az alkalmazási esetek 99%-ában kódminőségben, bugok számában és x év után fenntarthatóságban/fejleszthetőségben köröket fognak verni a te matematikailag bizonygató csapatodra.

És igen, ha kell lesz külön matematikus, lesz külön security expert, devops, hálózatos, domain expert meg főleg (scrum, helló!), és nem arra fog építeni a project, hogy de hát a Józsi 20 éve egyetemen tanult security-t, majd ő megoldja a már akkor 10 éve elavult tudásával.

Egy pillanatig nem írtam sehol, hogy a kódbázis 100%-át formális módszerekkel bizonyítani kell. De ha egy millió soros mondjuk ERP kódbázisban van egy 500 soros pénzügyi tranzakció ütemező, akkor rohadtul nem árt, ha az egy rosszul lekódolt algoritmus miatt nem áll neki végtelen ciklusban utalásokat indítani és ezt az algoritmusról (nem a kódról!) ezt be is tudod bizonyítani...
De ha ilyen messze nem akarsz menni: nem árt, ha a "ránézésre ok"-on túl tudsz egy kicsit menni és értelmesen érvelni, hogy miért nem fog végtelen ciklusban rohangászni a kódod. Vagy a futási ideje/memória igénye elszállni a francba.

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Egyre mélyebbre ásod magad.. az alkalmazási terület egy szeletében, a kód 0.05%-áért tanuljon az egyetemen _mindenki_ matematikusnak :) Ráadásul abból indulsz ki, hogy arra az anyagra még nyugdíj előtt egy évvel is emlékezni fog, és eleve ötösre rakta le azt a tárgyat.

Ja, hogy nálad a fenti belefér? A főnök gondolom retek boldog lesz, amikor egyik reggel a céges számlán van egy nulla, mert ja, sry, arra nem volt unit test...

És igen, azt továbbra is retek fontos (lenne) lenne tudni eldönteni, hogy egy-egy algoritmus/kód hogyan fog lefutni. Találkoztál bármelyik Windows Update topickal, ahol próbálták megfejteni, hogy miért eszik 10-12 órán át egy teljes magot és 2 giga ram-ot a wuasrv? Ja, a unit testek náluk is lefutnak... (és íme még egy tisztán fejlesztői gráfelméleti és logikai feladat... és aki az utóbbit megkérdőjelezné, az MS-WUSP specifikáció a CNF leírásával kezdődik)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

Megint nem választ írtál, hanem leírtad sokadszorra ugyan azt.. még egyszer ne fáradj vele, a laptopon itt fogyott el a felbontás :)

Azt meg te szülted valahonnét, hogy aki nem tud minden bizonyítást fejből, annak nulla az algoritmikus tudása. Eddig mission-critical kódrészletről volt szó..

A bizonyítások logikáit meg középiskolában tanuljuk :D Mi ezeket kilencedikben tanultuk. Indukció, reductio ad absurdum, egzisztenciabizonyítás vs. konstruktív bizonyítás és a többiek.
Szerinted akkor elég, ha tudja a delikvens az X tételről, hogy milyen módon bizonyítjuk be? Magát a logikai lépéseket nem kell tudnia, csak azt, hogy "Az X tételt az Y-ból, azt pedig a z kifejezésre vonatkozó teljes indukcióval tudjuk belátni". És nem kell értenie, miért pont az Y, és az Y állításból miért következik X?

Pont ezt magyarázom, hogy értenie kellene, hogy miért Y és miért Y-ból X, de nem az van, amit itt többen próbálnak magyarázni, hogy "betűről-betűre" be kell magolni. És minél több ilyet lát, annál nagyobb valószínűséggel fogja adott esetben megtalálni, hogy adott problémánál neki az Y kell, mert ha abból kihozza X-et, közelebb kerül a megoldáshoz.

Egy hasonlat: integrálás. Gyakorlatilag az egész gyakorlati oktatása nem szól másról, mint hogy mintákat gyakoroltatknak, reménykedve, hogy ha egyszer szükség lesz rá (ha máskor nem, vizsgán), a hallgató látja majd, hogy adott feladaton melyik mintákat kell követnie. (mást ugye nem tudnak, mert algoritmikusan eldönthetetlen) Próbálnak egy _készséget_ kifejleszteni. (arról lehet vitatkozni, hogy ugyanezt mondjuk a GoF-nál is lehetne, mert az se szól másról: korábbi mintákat illesztünk egy éppen felmerülő problémára)

BlackY
--
"en is amikor bejovok dolgozni, nem egy pc-t [..] kapcsolok be, hanem a mainframe-et..." (sj)

"arról lehet vitatkozni, hogy ugyanezt mondjuk a GoF-nál is lehetne, mert az se szól másról: korábbi mintákat illesztünk egy éppen felmerülő problémára"
Pont erről vitatkozunk: jelenleg a világban nem igazán megy a szisztematikus szoftverfejlesztés, pláne nem azon az összetettségi szinten, ahol a mostani szoftverrendszerek tartanak, hiszen akkor jóval kevesebb lenne a hibaarány, a regresszió meg egyéb hasonló dolgok.
Készségszintűnek kell lennie a jó minőségű szoftverépítésnek. És jelenleg ezt a készséget csak vállalatok oktatják. Míg az integrálást meg tanítjuk mindenkinek, hogy készség legyen. Kérdés: melyiknek van általánosságban nagyobb haszna?

Ha kellően értelmes, rátermett, logikusan gondolkodni képes - és megvannak az alapjai hozzá, akkor bőven elég, hogy adott ismert tétel bizonyításánál milyen főbb kiindulási lépéseket érdemes számba venni, hol van esetleg szokatlan/váratlan lépés a bizonyítás menetébe (és az miért jó) - az egyes rész lépések ekkor már jönnek maguktól.
Az X és Y összefüggését (hogy miért Y-t vesszük elő X-hez) jó, ha ismeri, jó, ha tudja a miért4et, de nem feltétel.

Azért nagyon kíváncsi vagyok, ki emlékszik bizonyításokra akár csak egy évvel is diploma utána.

De mondok neked viccesebbet is. Amerikai egyetem, aerospace BA, diffegyenletekben nem hogy bizonyításokat nem tanulnak, hanem kézzel megoldást is alig. Helyette matlab, orrba-szájba, mert az iparban úgyis azt fogják használni. És láss csodát, nem tételeket bizonyítani tudó magyar mérnökök landoltak egy LEO rakéta első fokozatával.

Anno nekem sem tetszett a kicsitépernagytékkel teleszórt ddifegyenletesdi szabályozásból, elsősorban azért, mert nem azért tanították, hogy tudjuk, hogyan működik a szoftver, ami számol, hanem azért, hogy mi is azt használjuk.
Anno sok dolgot belénk töltöttek "tudás" címszóval - ezeket szépen elfelejtettem, mert nem használom - viszont tudok mihez nyúlni (könyv a polcon), nem ilyedek meg egy sormintának tűnő képlettől, vagy épp egy 2-3 oldalas levezetéstől. És ami fontosabb: van esélyem rá, hogy megértsem, hogy mi van leírva, van esélyem rá, hogy értem is azt, ami történik, amit a szoftver csinál.
Van, ahol nem cél érteni, csak az a fontos, hogy csinálják - aztán bejön egy láb kontra méter probléma, és kopp van, de nagyon...

A matematikai bizonyításokat nem csak önmagukért tanítják. Tanulj meg módszereket, hogy egy-egy állításról hogyan, milyen eszközökkel lehet szabatosan megmondani, hogy helyesek-e vagy sem, tanulj meg logikusan, lépésenként összerakni érveket, meglévő ismeretekre alapozva juss el "A"-ból "B"-be.

A matematika ebben az esetben eszköz. Eszköz arra, hogy tudj jól és helyesen érvelni, problémákat több nézőpontból kezelni, etc. etc...

A tudomány nem hit kérdése - ahogy középiskolai osztályfőnököm mondta anno, hinni ott a tornyosban kell, nem a tábla előtt, amikor valaki tétován úgy kezdte a mondatot felelés közben, hogy "Azt hiszem...".
Ha nem hiszed, hogy jó, akkor:
-ne használd,
-nézd meg, és értsd meg a bizonyítását, hogy utána ne hit kérdése legyen az, hogy jó vagy sem.

Erre van egy tapasztalatom: egyik rettegett tárgy (Elektromágneses terek) szóbeli vizsgáján volt egy rondább számítási rész. Mondtam, hogy ezt fejből nem tudom, de tudom, mi jön ki belőle, mondta a vizsgáztató, hogy épeszű ember ezt nem is tudja fejből. Sokszor ennyiből áll a dolog egy szóbeli vizsgán.

neked ennyiből áll. A csoportodba járó egyetlen lány meg végigbőgte a vizsga előtti éjszakát, hogy hülye és meg fog bukni.
A hosszú bizonyításokat megtanulta persze, viszont az alapfogalmakkal negyed annyira sincs tisztában mint te.

Neked se jó, neki se jó, kinek jó, akkor?

̢̢͇̜͍̮̤͆͗̀̇̏̚͝ḅ̳̭͇̺̺̣͐̓̾̔̾͆̕ṃ̡̧͍̖̮͖̈́͗́̑̆͋͘ȁ̢͎̟̰͖̘̹̅̋̆͒̚͝s̨̖͎͕̲̜̰͗́̓̀̀͗̚n̲̝̠̰͓̪̈̀̈̔̀͂̄ͅi͖̖̬̮͖̭̱̓͗͛͆̿̇͘

mondjuk, így kapásból egy olyan tárgyat sem tudnék mondani, ahol nem engednek át kettessel, mindenféle bizonyítás ismerete nélkül. (bme-vik, info)

mondjuk olyan vizsgáztatóval se nagyon, aki azt várja el, hogy szóról-szóra seggeld be a bizonyítást, s álmodból felkeltve, egyből tudd mondani. erre van a felkészülési idő, meg egyebek - s többnyire, ha látják rajtam, hogy a gondolatmenet nagyrészt megvan, többre értékelik, mint akinek semmi.
(az más kérdés, hogy erre egyszer találkoztam ellenpéldával, de az egy eléggé speciális eset volt)
--
blogom

Ha az alapokkal sincs tisztában, akkor igenis fusson neki újra, mert lehet, hogy "görbül", de hogy a rá épülő dolgoknál vérpisálás lesz, vagy valódi tudását tekintve maximum egs szinten maradva végigmegy, és az "iparba" kikerülve tökéletes példája lesz a semmihez sem értő diplomásnak.

Lehet, de a gyakorlat azt mutatja, hogy elég ahhoz, hogy valaki diplomát szerezzen.

Aztán két nap alatt képtelen megoldani egy (ida;szöveg;id1;id2;id3...) formátumú CSV DB-be gyúrását (ida,id1),(ida,id2),... párokban, úgy, hogy az összes keret adott volt, már soronként kapta egy stringtömbként a CSV rekordját és csak be kellett (volna) csűrni egy DB-be. (Ami nehezítés volt, hogy a meglévőket ki kellett hagyni, viszont könnyítés, hogy nem töröltünk semmit, csak hozzáadásra szólt a funkció).

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Tegyük hozzá, hogy sajnos. Az ilyen, ipari felhasználásra alkalmatlan magológépek egyébként jó eséllyel maradnak bent a pihésdíj :) megszerzésére, és sajnálatos módon tőlük kell(ene) a következő generációknak tanulni... Persze tisztelet a kivételnek, mert ismertem nagyon jó fej és komoly tudással bíró doktoranduszokat is - az más kérdés, hogy azóta bőven otthagyták az egyetemi oktatói/kutatói munkát...

Nem nekem kell igazolni, főleg formálisan a gyakorlatban futó algoritmusok összetettsége olyan, amit elemi eszközökkel nem is fogsz bizonyítani.
Igen, vannak olyan dolgok, amiket formálisan kell tudni bizonyítani, de ez nem jelenti azt, hogy mindenkit a formális bizonyításra kell oktatni. Nem ez a hangsúly. Sosem tagadtam, hogy kellenek elméleti szakemberek. Kellenek. De messze nem annyi, mint olyan szakember, aki alkalmazni tud.

A 70-es évekbeli szoftverválság sem azért volt, mert nem tudtunk formálisan bizonyítani dolgokat. Hanem azért, mert a gyakorlati alkalmazás nem volt kellően szisztematikus.

Most is egyfajta szoftverválság van, egyre több az eldobható szoftver (mobilappok tipikusan), egyre kisebb a time-to-market, emiatt még jobban, szisztematikusabban kell tudni szoftvert építeni. És ezen nem segít, ha a formális bizonyításokkal szarakodjuk el az időt, ahelyett, hogy a szisztematikus szoftverépítés lenne a lényeg egy mérnök szakon.
Egy elméleti informatikai szakon, szakirányon persze, hogy fontos, és ezek a szakemberek is a megfelelő helyeken alkalmazásba kerülnek.

A gráfelméletben a legtöbb "klasszikus" bizonyítást lényegében algoritmus adja: útkeresés (Dijkstra, Floyd), hálózati folyamok (Ford-Fulkerson), párosítás (magyar módszer). Nehogymár egy informatikusnak, programozónak tanuló ember számára egy algoritmus megértése gondot okozzon...

Óh, simán:

- játszol valamilyen játékkal? AI útvonalkeresése: gráfelmélet.
- használsz valami social web dolgot? Ismerős keresése: gráfelmélet
- Hálózat méretezés: gráfelmélet (pl. hálózati folyamok alapján)
- Spanning tree protokoll: gráfelmélet - feszítőfa keresése
- Megfelelő routing irány választása: gráfelmélet - útvonalkeresés
- webes keresés: gráfelmélet, csoportok keresése gráfon belül
- debuggolásnál amikor visszanézed, hogy honnan jön egy hibás adat, tulajdonképpen egy mélységi keresést hajtasz végre, megfelelő kritériumokkal - gráfelmélet

Ezek több tématerületről összebogarászott alkalmazások.

És a vicc az, hogy amikor te a gyakorlatias elvek mentén oldod meg a dolgokat, akkor is tulajdonképpen a gráfelméletet használod, csak kicsit keszekuszán.

Talán így tudnám megfogalmazni az egyetem előnyét: fel lehet ismerni a dolgok közötti mélyebb összefüggéseket, összeköttetéseket. (Off: Tudtad például, hogy ami most reaktív programozás címen egy divatos dolog kezd lenni, annak jelentős részét (pl. reactive streams, actor model) digitális áramkörök tervezésénél, szimulációjánál évtizedek óta használják, még ha más formában is?)

A hasonlat még mindig:
elméleti informatika - klasszikus elméleti fizika vs
alkalmazott informatika (amiket felsoroltál, mind alkalmazásai egy elméleti koncepciónak) - gépészmérnökség, építészmérnökség.
Egy építészmérnök sem tudja bizonyítani az Euler-Lagrange egyenletet, mégis tud forgatónyomatékkal meg energiával számolni.

ezek többsége egyébként mind olyan probléma, amiket lazán odaadnak, hogy oldd meg.
és igen, az egyetem nem frontend dizájnereket képez, és nem is az a dolga.

(halkan jegyzem meg, sosem gondoltam volna, hogy egy egyetemi képzésről szóló vitában többször is wachag mellé állok. elnézést kérek, utólag is :-D)
--
blogom

Még mindig ott tartunk, hogy egy mérnök képzésében nem az alaptudomány elméleti szakembereit képezzük. Hanem mérnököket. Akik az alkalmazott tudományban profik. Erről megy a vita, de az elméleti szakemberek ezt nem látják be.

Az alaptudomány elméleti szakembereire is szükség van, ezt soha senki nem tagadta. Csak fel kéne fogni, hogy az informatika 70 év alatt lett annyira komplex szakma, hogy szükség van a felsőoktatáson belül is az elméleti szakemberek és a mérnökök képzésének teljes szétválasztására. Mint ahogy ezt nyugaton csinálják is. A Stanfordon és az MIT-n is van scientific mesterszak meg PhD, meg industrial, a computer sciencen belül.

És ezek az alkalmazott tudomány beli szakemberek képesek... Mire is?

Elé rak valaki egy helyes megoldást pszeudo-kódban, s azt átfordítja Python kódra? Kap egy Photoshop fájlt, s html leírást csinál belőle?

Mert a fentiek alapján egy bárhogyan megfogalmazott problémára nem tud helyes, algoritmikus választ adni - sosem látott arra példát, hogy egy problémára hogyan kell helyes, teljes választ adni.

De legyen, fordítsuk meg azt a lovat: az általad emlegetett gyakorlati szakemberek mire lesznek használhatóak?
--
blogom

A legtöbb esetben nem is az a probléma, hogy mi a helyes algoritmus. Hiszen a gyakorlatban készítendő szoftverek esetében nem ezzel van a gond. Nem algoritmikus problémák szoktak lenni, nem emiatt van szoftverkrízis, a 70-es években sem emiatt volt (pedig akkor a fejlesztők még komolyabb szinten voltak eméleti ismeretekkel).

Ezek a gyakorlati szakemberek a szoftverkrízist oldják meg. Mert még mindig nem általános dolog az, hogy tudunk szisztematikusan szoftvert építeni. Mert nem erre készítik fel az informatikus mérnököket.
A szisztematikus szoftverépítés az bizony fontos dolog. És ha bizony olyan a szoftver, aminek van bizonyítandó része, akkor a szisztematikusságnak része az is, hogy kell elméleti szakember a bizonyításokra.
Viszont rengeteg szoftver nem ilyen.

"De legyen, fordítsuk meg azt a lovat: az általad emlegetett gyakorlati szakemberek mire lesznek használhatóak?"

Olyan kódot írnak, amitől nem hányja el magát egy másik gyakorlati szakember, és azt a kódot 5 év múlva elővéve is gyorsan meg fogja érteni, és gyorsan és hatékonyan tudja módosítani, kijavítani. Olyan szoftvert fog írni, amit a megrendelő kér, könnyen alkalmazkodik a menet közben változó követelményekhez.

Ismeri a használt keretrendszerek erősségeit, gyengeségeit. Ami a gyakorlatban sokkal fontosabb, lévén 99.99%-ban mások által már megírt algoritmikusokat írna újra az elméleti szakember is, többnyire rosszabbul, mint egy kitesztelt keretrendszer vagy lib.

Összességében: gyorsabban, olcsóbban hatékonyabb szoftvert ír, mint egy elméleti szakember, olyat, ami 5 év múlva nem lesz fenntarthatatlan. Ahol meg kritikus rész van, jöhetnek az elméleti szakemberek, de jobb, ha nem engedjük őket kódot írni.

Az algoritmizálás kapcsán pedig te is alaposan kifordítottad a mondanivalónkat, örülök, ha máshogy nem sikerül vitatkozni vele :)

"És ezek az alkalmazott tudomány beli szakemberek képesek... Mire is? "

Arra, hogy elé raknak egy feladatot és megoldja, míg az elméleti szakember az 5. könyvet írja róla, miközben még mindig nem oldotta meg a feladatot.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Ugye nem azt akarod mondani, hogy csak akkor tudok hatékonyan debuggolni, ha a legelvontabb gráfelméleti tétel bizonyítását is kenem-vágom? :D A példáid továbbra is csak azt bizonyítják, amit mi is mondunk, hogy igen, részterületeken van haszna. Bár a legtöbb példádnál még erősen lehetne kötekedni, hogy ki mit ért ugye alap bevezetésen, és tényleg kell-e annál több egy Bsc-t végzett embertől.

Amit a reaktív programozásról írsz meg egy vicc, abban az értelemben, hogy senki sem fog abból bármit is felhasználni amit akár csak 5 éve kényszerből bevágott az egyetemen, ha azóta nem foglalkozott vele. Hanem újra meg fogja tanulni. Igen, némileg gyorsabban, mint aki sosem tanulta, de azt hiszem ezt hívják premature optimizationnek, ami tudjuk, hogy micsoda :)

Továbbra is azt mondom, hogy - akár egy új szak égisze alatt - 2-3 félévre való anyagot ki lehetne dobni a mostani tantervből, és hasznosabbakkal helyettesíteni, sok tárgyat ami ma első félévben elveszi a hallgatók nagy részének az életkedvét is, msc-re lehetne száműzni.

" - debuggolásnál amikor visszanézed, hogy honnan jön egy hibás adat, tulajdonképpen egy mélységi keresést hajtasz végre, megfelelő kritériumokkal - gráfelmélet"

tulajdonképpen lélegzel is közben, nem?
Máris megindokoltuk a biológia végtelen mélységben való bemagoltatásának szükségességét, vagy mi?

Képzeld, van olyan embedded fejlesztés, ahol
- nincs debugger
- van, de ha rá van kötve, nem működik valami másik periféria (áramköri okok miatt)
- egy debuggere van az egész csoportnak (nem olcsó dolgok ezek), és épp más használja.
- te hozod létre a processzoros rendszert, és a board bringup elején még nincs debugger vonalad

Olyan is van, hogy
- nincs operációs rendszer
- "csak" RTOS-ed van

És lehet így is élni. Te ilyenkor szitkozódnál, szidnád az eszközt, stb, vagy megoldanád nélküle? (Nyilván nem ilyen helyen dolgozol, feltételezem, nem láttál ilyet, tehát a dolog teoretikus).

A HUP jelentős része néha nem lát túl a saját magas szintű világán, pedig meg merem kockáztatni, hogy a szoftverfejlesztés nagyobb része embedded (távközlés, autóelektronika, lakásautomatizálás, whatever). Nekem ebből a szempontból szerencsém van, többfajta absztrakciós szinten láthattam (dolgozhattam) szoftverfejlesztést. Persze nem tagadom, az embedded vonalban mozgok inkább.

Nagyszeru, de unalmas mar nagyon. Huszonkettedszerre is, ezt adjatok le embedded szakiranyon, aki meg pl enterprise java fejlesztonek keszul, azt normalis kodot irni tanitsatok meg, mert legutobb is a phd-s "szakerto" olyan kodot adott ki a kezei kozul nulla teszttel, hogy a project kollektive elhanyta magat.

Szerintem azért ennyire nem kellene szétdarabolni az info szakot, tény viszont, hogy valamennyire kellene. Személy szerint nem vagyok nagy híve a BSc-MSc felállásnak, mert sok párhuzamosság van benne, mivel ha valaki nem annak az egyetemnek a BSc-jéről jön ahol az MSc-t csinálja, nem nagyon lehet tudni, hogy mit és milyen mélységig tanult. Az lenne a jó és hangsúlyozottan egy ideális esetről beszélek, ha BSc-n lenne az alapozó tudás egységesen, ami megtanítaná az alapokat széleskörűen és felkészít az MSc-re. Amivel lehetne specializálódni, de ez jó lenne arra is, hogy a hallgató belekóstoljon sokfajta területbe, ami után eldöntheti, hogy mi érdekli. Valamint legyen lehetősége kedvezményesen, egyetemi emberek támogatásával vizsgákat megcsinálni, pl üzemeltetésben MS, vagy RedHat... hálózatoknál Cisco-sat... meg még van pár jó, több területen is. Akinek ez elég lenne, az mehet az iparba, aki pl kódolni akar, vagy akármi. Ezután jöhetne az MSc ahol már specializálódhatna, pl robotika, enterprise rendszerek... stb. És felkészítene a PhD-ra. Majd mehetne a PhD, ami egyébként kétféle lehet megint, az alkalmazott és az elméleti.

Az egész mögött az áll, hogy egy gazdaság akkor tud sikeres lenni, ha magas hozzáadott értékkel termel. Ezt a következő struktúra biztosíthatja:
- Akadémiai elméleti kutatás
- Akadémiai alkalmazott kutatás
- Alkalmazott kutatás
- Innováció

Ha bármelyik elem hiányzik, borul a műsor.

Akadémiai elméleti kutatásban jellemzően elvekkel foglalkoznak, hogy a saját szakterületemet mondjam, pl itt fejlesztik az új szabályozástechnikai elveket/módszereket (ezt csinálom én) (viszont tekintettel kell valamennyire lenni arra is, hogy ne legyen végtelen számításigénye, meg azért az ismert módszerek valami hiányosságát megoldja, szóval nem csak öncélúan kell csinálni)

Az Akadémiai alkalmazott kutatás fogja és a fent létrehozott elveket/módszereket "ráhúzza" problémaosztályokra amik a gyakorlatban felmerülnek.

Alkalmazott kutatás, jellemzően az iparban van, ahol a fenti két kutatás eredményeit alkalmazzák cég szinten,

Innováció meg maga a termék készítése.

Jellemzően az utolsó kettőhöz MSc kell, a felső kettőhöz meg PhD (persze ez nem szent írás, akár egy BSc-s is értheti mit írt le a kutató mondjuk az elméleti kutatásban, és alkalmazhatja is, de ha struktúrában gondolkodunk, akkor ez szokott lenni a célszerű.

A 20. században jellemzően úgy ment, hogy a felső kettő volt valami kutatóhelyen, az alsó kettő meg az iparban, de a 21. században a cégek elkezdtek költeni arra, hogy az akadémiai alkalmazott kutatást is csinálják, PhD-sokat vesznek fel erre a célra. Egyébként itthon ezt az állam jelentős adókedvezménnyel támogatja, de ez még inkább külföldön divat, de itthon is elkezdődött már ez a folyamat.

A kutatóhely meg azért nagyon jó, ha az egyetemen van, mert így a kutató oktat is. Én azt vallom, hogy akkor értettem meg valamit, ha egyszerűen el tudom magyarázni. A hallgatónak is jó, mert első kézből tud meg új módszereket, amiket majd kamatoztathat az iparban, vagy megtetszik neki a kutatás és jön PhD-zni.

Egy példa, hogy én hogy csinálom: a Rodrigues formula 2 táblás levezetése után, bekarikázom a táblán azt a 3-4 egyszerű pontot amit meg kell érteni és megjegyezni az ötletet. Mindig elmondom az elején a hallgatónak, hogy mindig kérdezzen ha valamit nem ért, mert ha én elmondok valamit és ő nem érti, az az én hibám, viszont ha ő nem kérdez akkor az ő hibája. Nincs hülye kérdés, a lényeg, hogy összerakja a képet. Sajnos tapasztalat, hogy keveset kérdeznek, szóval próbálok feltenni kérdéseket, de csodát azért nem tudok tenni.

( Rodrigues formula robotikában fontos a homogén koordináta transzformációknál a forgatásért felelős, gyakorlatiasabban ez írja le egy robotkar rész forgatását, van egy másik módszer is amit elmondok a Denavit–Hartenberg módszer, de én a Rodrigues formulát preferálom, mert azt egyszer megérti az ember, végigszámolja, kap egy 3x3-as mátrixot amit leprogramoz, és el is felejtheti, jobb softwareben meg már le is programozták helyette. )

Minden tiszteletem mellett, megint jon valaki egyetemrol, ahol egy szukebb terulettel - bizonyara remek szinvonalon - foglalkozik, es onnantol minden problema egy szog.

Ezen a bsc az msc-re keszit fel dolgon kellene leghamarabb tullepni, a bsc az munkara keszit fel. Az msc meg jobb helyeken egy teljesen kulonallo dolog, nem egy ujabb huzzuk le meg negy felevre phd elott lepcso. Ja es ha a bsc utan tenyleg kell az msc, akkor miert hirdettek meg rendszeresen kevesebb helyet, mint a vegzos bsc-sek szama?

Egyáltalán nem ezt írtam. BSc-n a megvalósításra kell, hogy felkészüljön a hallgató, de mellette fel kell készítenie az MSc-re is. Ez nem azt jelenti, hogy mindenkinek MSc kell, egy viszonylag kis hányad aki megy MSc-re. Ahogy írtam az "iparban" is több szinten lehet dolgozni, de azt ne vitassuk el, hogy fontos az, hogy a hallgató eljusson a következő szint belépő részéhez. Mivel az is egy nagyon fontos szint, mint ahogy a BSc is az és a PhD is. Egyik nem lehet meg a másik nélkül. Ha pl csak MSc-s lenne a cél, akkor nem lennének emberek akik lekódolják, összerakják a terméket. Ez nem azt jelenti, hogy az adott területen MSc-s nem tudná megcsinálni, de nyilván azért ment tovább MSc-re, vagy esetleg még tovább PhD-ra, mert másképp érdekli az adott terület, mást szeret csinálni. A lényeg, hogy mindenki megtalálja a saját helyét, ahol jól érzi magát, azt amit szeret csinálni. Mivel ez egy olyan láncolat ahol minden eleme egyaránt fontos még kisebbségérzésének se kell lennie az embernek, egyszerűen más érdekli. Ezért nem kellene elvitatni mástól azt amit szeret csinálni, mert az is éppolyan fontos mint amit te csinálsz.

"Egyáltalán nem ezt írtam. BSc-n a megvalósításra kell, hogy felkészüljön a hallgató, de mellette fel kell készítenie az MSc-re is."

Ugyan már, ennek semmi értelme. Miért kéne _bárminek_ több, egymással összeegyeztethetetlen dolgot jól csinálnia? (nem szokták a bármik).

Az újdonsült hallgató elé kell tolni egy papírt, hogy mit akar a bsc után: dolgozni, kutatni, még nem tudja. És akkor 3 részre lehet osztani a szakirányt. Nem olyan bonyolult ez. Viszont megvan az az előnye, hogy nem megy a kutatóképzés rovására a kóderek képzése, és viszont.

szerk: mármint, úgy értem, nem érzem azt, hogy bármi felvetett probléma szükségszerű lenne, inkább csak szarul van megcsinálva. (esetleg még az, hogy kevés a pénz, de.. na!)

̢̢͇̜͍̮̤͆͗̀̇̏̚͝ḅ̳̭͇̺̺̣͐̓̾̔̾͆̕ṃ̡̧͍̖̮͖̈́͗́̑̆͋͘ȁ̢͎̟̰͖̘̹̅̋̆͒̚͝s̨̖͎͕̲̜̰͗́̓̀̀͗̚n̲̝̠̰͓̪̈̀̈̔̀͂̄ͅi͖̖̬̮͖̭̱̓͗͛͆̿̇͘

-1
"Az újdonsült hallgató elé kell tolni egy papírt, hogy mit akar a bsc után: dolgozni, kutatni, még nem tudja."
/"Ugyan már, ennek semmi értelme."/

Nem igazán tudom elképzelni, hogy a BSC-t végző kutató mit csinálna az elképzelésed szerint.
Márpedig a BSc -> MSc -> PhD egy adott terület különböző szintjei, és aki eléri a PhD szintet, elvileg az ismeri a legmélyebben, nyilván azokból lehetnek leginkább a kutatók.

"Nem igazán tudom elképzelni, hogy a BSC-t végző kutató mit csinálna az elképzelésed szerint."

eee.. ez értelemszerűen az msc-t jelenti? (és msc-ből sem a gyakorlati irányokat)

Egyébként miért engem -1-ezel, nem én mondtam hogy bsc alatt a kutatóknak kéne tanítaniuk az iparba készülőket is. (ez annak az elképzelésnek a sokkal durvább, megvalósított változata, amit -1-ezel)

̢̢͇̜͍̮̤͆͗̀̇̏̚͝ḅ̳̭͇̺̺̣͐̓̾̔̾͆̕ṃ̡̧͍̖̮͖̈́͗́̑̆͋͘ȁ̢͎̟̰͖̘̹̅̋̆͒̚͝s̨̖͎͕̲̜̰͗́̓̀̀͗̚n̲̝̠̰͓̪̈̀̈̔̀͂̄ͅi͖̖̬̮͖̭̱̓͗͛͆̿̇͘

Ha programozást nézzük akkor nem feltétlenül kell kutató az oktatáshoz, viszont vannak területek ahol nagyon is jó. Pl amikor a processzorokról tanultunk, kifejezetten jó volt egy idős prof aki részt vett ilyesmiben (konkrétan Cell procik bizonyos problémáinak megoldásában), vagy a saját területemen az irányításelméletben, ahol hagyományosan két út létezik, a lineáris kontroll ami Kálmán Rudolf szerint is a 60-as években elavult, vagy a nemlineáris kontroll (a problémák túlnyomó többsége ilyen), ott meg Lyapunov módszere a meghatározó, de az meg nagyon nehéz a megvalósítása, maga az elv könnyű, de a feladat megoldásánál egy méretes és bonyolult bizonyítás is kell (ezzel ellenőrizzük, hogy tényleg a megoldást találtuk meg, mert nagyon nem triviális). Ilyenkor kifejezetten jó, ha tudok mutatni a saját kutatásaimból olyan módszereket amit vagy a profom, vagy én találtam ki, amivel könnyebb lesz a hallgató élete. Ez már BSc-n is jó, ott nyilván a módszer bizonyítását kell számon kérni. Nyilván ezzel programozó szakirányon nem találkozik az ember, csak ha kifejezetten a robotika érdekli.

Naja, csak az a gond, hogy ebből én nagyon keveset láttam nálunk. Látom, hogy vannak kutatások, de az egész egyetem alatt egy tanár próbált bevonni minket valamibe.

Plusz, nem igazán láttam feltétlen átfedést azok között, akik fiatalon órát adnak és azok között, akik mélyebben benne vannak egy-egy kutatási projektben, vagy ha vannak is, nem nagyon tükröződik vissza. Amikor meg egyenesen a 80-as évek jön szembe - miközben felnézek bármely hírportálra, láthatod, hogy mi megy most - mint state of the art, azt nem részletezném.

A kérdezésről: három eset van:
- kérdezel, segít megpróbálja elmondani másképp, látszik a felkészültsége, gyakorlata, és meg tudja indokolni, hogy mit miért csinál és bőven mutat neked utakat a tananyagon túl is. Jobb esetben még tanárként is jó. Sajnos ez a ritka.
- kérdezel valamit, de ó a Főméltóság, akinek a Tudásával milliókat lehet majd keresni (dollárban!!!111), benne van a könyvben, hogy képzeli, hogy nem tudja, stb. Jobb esetben néha ért is ahhoz, amit csinál, és nem csak azért alakítják hozzá a tantervet, mert nem hajlandó új dolgot megtanulni. Szerencsére ez is ritka, viszont annál kártékonyabb.
- kezdő tanársegéd, nulla/minimális szakmai tapasztalattal: ha kérdezel, nem biztos, hogy választ kapsz, esélyes, hogy a Googlehoz irányít, nem látszik rajta a biztos tudás, ami jellemzően véget ér az órai anyaggal. Általában jószándékú, de ez még nem biztos, hogy elég a minőségi oktatáshoz.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Te vagy saxus?

Elmondom még egyszer a szálat:
1. hrgy gyakorlati alkalmazást kért
2. leírtam, hogy pl. debuggoláskor, amikor megérted a kódod, tulajdonképpen fejben mélységi keresést hajtasz végre
3. jött soultrane, aki valami egészen mást hozott be (debugger írás, sok köze nincs ehhez a szálhoz), mert jólesett neki
4. gondoltam, mesélem neki, hogy néha olyat is kell
5. saxus erre hitetlenkedett
6. mondtam neki gyakorlati tapasztalataimat

- itt tartunk.

Sok értelme amúgy nincsen, szemmel láthatóan haters gonna hate dologba ment át itt mindenki.

> mert legutobb is a phd-s "szakerto" olyan kodot adott ki a kezei kozul nulla teszttel, hogy a project kollektive elhanyta magat.

Láttam fordítva is, rossz kódot írni nem csak phd-s "szakértő" tud, ez nem bizonyít sokat. 3rd-party szoftverbe fejlesztgettem bele, hát néha élmény, miket produkáltak.

Aki meg enterprise java kódot akar fejleszteni, az ne _mérnök_ informatikusnak menjen. Vagy legalább tájékozódjon a képzés céljairól, publikusak.

Szerinted aki software engineer akar lenni (igen, ez egy létező szakma a világban, tessék utánanézni), az mégis hova menjen, ha ne _mérnök_ informatikusnak?
És a szoftvermérnök nem olyan villamosmérnök, aki tud programozni.

A legjobb definíciója talán a szoftvermérnöknek: "the application of a systematic, disciplined, quantifiable approach to the development, operation, and maintenance of software"
Hol tanítanak ilyet az országban?

A mérnökinformatikus szak erről szól ugyebár: "A képzésen a hallgatók az informatikai rendszereknek hangsúlyosan a műszaki területeken való alkalmazásait, illetve rendszertechnikai elemeit ismerik meg, legyen az számítógép, távközlési hálózat, digitális rendszer, mérés- és irányítástechnikai megoldás, operációs rendszer."
"Szakképzettség megnevezése: mérnökinformatikus – Computer Science Engineer"

Azaz ők nem szoftvermérnökök.
http://www.felvi.hu/felveteli/szakok_kepzesek/szakleirasok/!Szakleiraso…

A programtervezősök tanulnak olyat, aminek a legtöbb köze van as szoftvermérnökséghez, de ők Computer Scientist diplomát kapnak, nem Software Engineer diplomát.
"Szakképzettség megnevezése: programtervező informatikus – Computer Scientist

Képzési idő: 6 félév

A szakon elsősorban szoftverfejlesztő szakemberek képzése folyik, a hallgatók az ehhez szükséges elméleti, módszertani, technológiai ismereteket szerzik meg. "
http://www.felvi.hu/felveteli/szakok_kepzesek/szakleirasok/!Szakleiraso…

Ja és a Computer Scientist megnevezés kurvára mást takar, ők az elméleti szakemberek, akik algoritmuselméleti, bonyolultságelméleti stb. ismeretekkel rendelkeznek. De ők nem szoftvermérnökök. Még mindig nem vagy képes felfogni, hogy a magyar informatikai felsőoktatásban hiányzik a szoftvermérnök képzés?

Remek, büszke vagyok a képességedre, most akkor indokold meg azt is, hogy miért is kell újrafeltalálni a spanyol viaszt? Magas szintű nyelveknél egyeseknek már sikerült eljutni oda, hogy ne csak az eszközökön pöcsöljünk, hanem a feladatot oldjuk meg. Talán ideje lenne "lentebb" is. (Bár nem vagyok szakértője a témának, nekem olybá tűnik, vannak, akiknek mégis sikerült abszolválni a problémákat, csak egyesek szeretik újra feltalálni a spanyol viaszt.)

Egyébként ha már szóba kerültek a debuggerek: másik nagy szívfájdalmam, hogy azokat az eszközöket sem mutatják be jellemzően a hallgatóknak, amelyek egyébként már többtíz évesek. Integrált debugger pl. már a Turbo Pascal 3-ban is volt mégis rengeteg hallgató kerül ki az egyetemekről, hogy printf helyi megfelelőjével "debuggol". (Arról meg ne beszéljünk, hogy az egyetlen általam ismert komolyabb kezdeményezés a debuggolás innoválására a coding canvas/debugger canvas és mindenki más rezignáltan elfogadja, hogy nincs/szar/ősi módszerek vannak.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

> Remek, büszke vagyok a képességedre, most akkor indokold meg azt is, hogy miért is kell újrafeltalálni a spanyol viaszt? Magas szintű nyelveknél egyeseknek már sikerült eljutni oda, hogy ne csak az eszközökön pöcsöljünk, hanem a feladatot oldjuk meg. Talán ideje lenne "lentebb" is.

Mert van, ahol nincs debugger. Vagy egyáltalán lehetőség rá. Leírtam, milyen gyakorlatban előforduló esetekben találkoztam ezzel. Létező fejlesztésekben. Write only vagy?

> (Bár nem vagyok szakértője a témának, nekem olybá tűnik, vannak, akiknek mégis sikerült abszolválni a problémákat, csak egyesek szeretik újra feltalálni a spanyol viaszt.)

Van, ahol van. Van, ahol nincs. Sok embedded program amúgy olyan időzítésigényes, hogy nem fogsz tudni töréspontozni, léptetni, stb..

Minden szoftverfejlesztő életében eljön az első olyan bug, amit nem lehet debuggerrel megoldani. És nem kell hozzá az, hogy embedded környezetben dolgozzon. :)

Saxus fő gondja az, hogy évtizedekig sikerült úgy diplomát adni sokaknak, hogy nem láttak működő debuggert (vagy legalábbis élesben nem jutott eszükbe, hogy használni kéne), ebben a helyzetben a debugger mint eszköz felhasználási korlátairól kár vitatkozni.

Mi pl. JIT fejlesztésben gyakran kerülünk szembe olyan problémákkal, hogy nemhogy debugger, de még naplózás sem működik, mert az is annyira megváltoztatja a VM állapotát, hogy már nem jön elő a hiba. Marad a heap dump és sok MB generált assembly kód bogarászása. Ettől függetlenül a debugger mint eszköz annyira fontos, hogy írunk is magunknak (meg pl. az Android ART debuggerét javítottuk fel). :)

Saxusnak: érdemes megnézni az egyik első hozzászólásban is javasolt infoC honlapot, ami az új BME info Prog Alapjai 1 tárgyhoz tartozó hivatalos segédlet. Szerintem szépen össze van rakva az anyag és maga az oldal is, látszik, hogy szívvel - lélekkel készül (Adventi naptár!). Pl. 1. vagy 2. órán jön elő a debugger használat. Ugyanígy nagyon jó a Digitális technika tárgy is ahhoz képest, amivel minket fárasztottak még 2 félévig.

Sajnos, a 2. félévtől kezdve már nem ilyen rózsás a helyzet. Látszik, hogy sok munka van a tantervben, és van fejlődés, de nem mernek végigmenni az úton, amin elindultak.

A fő gond a BME infóval ugyanis, hogy egy bottom-up megközelítésben kezd el oktatni (Digit, C alapok), de utána nem viszi végig ezt a koncepciót, hanem elkezd kapkodva ugrálni: C++ alapok, Java alapok, Szoftvertechnológia minimális gyakorlattal, kis .NET, kis Android és web, kis adatbázisok, hálózatokból meg van 2 félév de minek.

Gyakorlatilag mindenbe belekapnak és hallgató fejében egy jó nagy massza lesz, amit vagy saját maga fel tud oldani, vagy kijönnek Msc diplomával, és amikor megkérdezem, hogy mondjon egy tervezési mintát, akkor a válasz "Tanultuk, de már nem emlékszem." Sajnos ez most történt velem két hónapja, nem csak illusztráció. Ebben nem az a szörnyű, hogy valamit nem tudott, hanem az, hogy nem gondolt arra, hogy egy szoftverfejlesztői pozícióra felvételkor ezt megkérdezhetik tőle.

Mielőtt azt mondjátok, hogy ez extrém példa: sajnos nem. Bővülni szeretnénk, voltunk az állásbörzén, behívtunk sok embert interjúra, és mindenki elbukott legkésőbb a tesztfeladaton.

Üdv,
Gergely

A zemberekbe nem nevelődik bele, hogy amit ír, az lehet rossz, kerülhetnek bele bugok.
Ezért nincs a legtöbb programban rendes(==>megfelelő adatokat naplózza) logolás, mert egyszerűen nem is gondolnak rá, hogy kellhet. Fejükbe vertek "dolgokat", amiket nem tudnak összekapcsolni. Mintha odaöntenének egyetemen egy vödör legót a fejedbe, majd elvánák, hogy rakd össze a 8265 homlokrakodót, magadtól.

De nagyon fontos, wachag figyelmébe is ajánlom, hogy az egyetemen nem tanítanak, hanem oktatnak. Az a kurvanagy különbség, hogy az oktatót kurvára nem érdekli, hogy érted-e, vagy lemaradtál-e (pedig ez lenne a dolga, ha már fizetünk érte).

Ez nem csak a friss diplomás programozók esetében jelenlévő probléma... Nem mai alkalmazás, könyvtárak között végez fájlmásolgatást/konverziót/ilyesmit. Nem egy űrtechnológia, megy szépen végig a beállított könyvtárakon, aztán ha van feldolgozandó fájl valamelyikben, akkor megmókolja, átpakolja oda, ahova kell, és megy tovább. Egyszerűnek tűnik a dolog, de NFS-en meg samba-val felhúzott könyvtárakról van szó - ha valamelyik leszakad, akkor a program az adott könyvtárhoz érve beáll, mint a faszög... Mit felejtett el a program elkövetője...? És nem, nem javítja - az üzemeltető oldja meg, hogy működjön, de legalább riasszon, ha valamelyik könyvtár nem érhető el...

" Bővülni szeretnénk, voltunk az állásbörzén, behívtunk sok embert interjúra, és mindenki elbukott legkésőbb a tesztfeladaton."
És ezzel rengeteg magyar cég így van, nem véletlenül indítanak saját képzéseket. Így persze meg kidobott pénz az egyetemi képzés egy része (nem az egésze).

+1 Egyetértek a debugger nézettel. A debugger már tűzoltásra való, arra sem feltétlen a legjobb. Sokkal fontosabb az automatikus tesztek írása. Ez az egyik legfontosabb lépése a programozásnak (tervezésnek).

-1 Nem gondolom, hogy a debugger/teszt kérdése függene attól, hogy magas/alacsony szintű nyelvet használunk.

Ok, igazad van, nyilán mindig, mindenki tökéletes tesztet ír elsőre.

(Ezek után nem is értem, hogy a Visual Studio fejlesztői minek pazarolták arra az időt, hogy tettek egy debug test opciót.)

Hozzáteszem, ha megbukik valami egy teszten és kódolvasásból nem egyértelmű, hogy hol a hiba a tesztet szoktam elindítani debugra és onnan mászok bele a kódba.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

"- debuggolásnál amikor visszanézed, hogy honnan jön egy hibás adat, tulajdonképpen egy mélységi keresést hajtasz végre, megfelelő kritériumokkal - gráfelmélet"

Komolyabb válasz, erre az érvre.

Ebből az érvelésből az is következik, hogy tetszőleges X egyetemi bölcsészkari nyelv alapszak tanmenetébe bele kell, hogy tartozzon a molekuláris idegtudomány elsajátítása is.

- a beszédértés vagy a beszédprodukció funkcióját összetett mentális műveletek valósítják meg -> ismerni kell ezeket a mentális műveleteket is

- ezeknek a mentális műveleteknek a hardvere az emberi agy -> ismerni kell az emberi agy felépítését és működését is

- az agy felépítésével és működésével az idegtudomány foglalkozik, ennek fontos területe a molekuláris idegtudomány -> ismerni kell ezt is - QED

----
"Kb. egy hónapja elkezdtem írni egy Coelho-emulátort, ami kattintásra generál random Coelho-kompatibilis tartalmat."
Instant Coelho

Első komolyabb munkahelyemen, 2-3 hónap után jött elő, hogy az ügyfél szeretne egy ilyen „grafikont” a honlapjára: http://www.personal.kent.edu/~rmuhamma/GraphTheory/MyGraphTheory/Diagra…
Itt például elég sokat segített, hogy beugrott: ez egy intervallum-gráf, az adatszerkezet is reprezentálható gráfként, uccu neki. Egyébként egy ideig tuti törtök volna a fejünket, hogy:
- hogyan lehet a grafikonnak minimális magassága,
- nem lesz-e túl lassú,
- etc.
S valszeg, 2-3 mérnöknap alatt megszültünk volna valami hasonlót, ám nekem erőteljesen szúrta volna az oldalamat, hogy biztosan nem-e hibás az a megoldás, amit adtunk. (és erre tessék mondani olyan területet, akinek a feladata lett volna ezt megoldani...)

A gráfban való útkeresésnek is vettem már hasznát. Még ha a legtöbb nyelvben van is gráf-implementáció (3rd party, de jó könyvtár), akkor is, azt legalább illik tudni, hogy milyen algoritmussal kereshetsz benne utat. Erre tippre a Google Forms-t tudnám hozni, ahol kijelezzük, hány százaléknál állsz a kérdőívben. Ha nem triviális ugrások vannak az oldalak között, akkor én elsőre egy gráfban keresnék leghosszabb utat. És ezt ugyancsak nem tudom odaadni a logisztikusnak, hogy oldja meg.

Nem rémlik példa, de mintha az elmúlt egy évben valahol hasznát vettem volna annak is, hogy hallottam már páros gráfokról.
--
blogom

Megint egy kicsit sikerült eltévedni. Nem az a probléma, hogy megtanítjátok az alapokat, hanem az, hogy azt várjátok el, hogy olyan szinten értse, mintha ez lenne a fő csapásirány, nem pedig a szoftverfejlesztés. Nem azt mondom, hogy nem kell egy alapozó tudás, a "tudjam, hogy ezt eszik-e vagy isszák" szint elérése, de ennél több a többségnek nem kell.

Épp az a gond, hogy az egyetem nem való mindenkinek. Az egyetemnek (legalábbis az elején) elsősorban pont arról kellene szólnia, hogy egy rendszerszerű szemléletet ad át annak, akinek erre szüksége van, a konkrét szakirányok pedig arra kellene, hogy jók legyenek, hogy aki akar egy-egy témában elmerülni, az megtehesse. Vagyis legalább az első pár félévnek mindenkinek valónak kellene lennie.

Kicsit olyan, mintha azt mondanád, az áltsuli nem való mindenkinek, vagy a gimi. Igen, az oktatás feladata az (nem), hogy csak az okosokat oktassa, a hülyék maradjanak maguknak hülyék, eszünkbe ne jusson javítani a dolgokon.
--
Blog | @hron84
Üzemeltető macik

> mintha ez lenne a fő csapásirány, nem pedig a szoftverfejlesztés

Ha szoftverfejlesztés alatt kódolást értesz, akkor arra nem az egyetem való, hanem a "Tanuljuk meg az XY programozási nyelvet 24 óra alatt" sorozat. Ha valami értelmeset szeretnél csinálni, akkor úgyis értened kell a mögöttes tartalmat, ezek pedig manapság sokszor pénzügyi, matematikai problémák.

Ezt viccnek szánod, pedig tényleg így van. Aki "komoly" szoftverekkel akar foglalkozni, az igenis értse a business logic-ot. Nyilván nem kell az egész teamnek másodállásban orvosnak lennie, de legyen olyan ember a csapatban, aki érti az adott domaint. Nem a frontend devekről van szó ofc. :)

Én láttam orvosi szoftver fejlesztését közelről, bizony, voltak ott orvos végzettségű emberek is a szoftverfejlesztők mellett.

Nem is kell. De ha egy projekten nincs olyan ember, aki ért a business domainhez, az eleve halott dolog. Mint amikor alapul egy startup, mert van adott három dolog: pénz, ötlet meg fejlesztő. De business oldalról nincs szakember. Na, az ilyen startup hamar elhal, mert csinálnak ugyan működő dolgokat, de azt senki nem használja, mert a business része nem felel meg a célközönségnek :D

Nem feltétlenül a BA fogja a low level szakmázást csinálni a projektben. A példámnál maradva, egy orvosi probléma mögötti logikát nagyon nehéz olyan alacsony szintre lefordítani, hogy elég legyen egy kóder droid, aki begépeli Visual Studio-ba a cuccot.

Akiket én ismerek, ott keményen benne vannak orvosok is a napi munkában. Nyilván nem mindegy, hogy orvosi projekt alatt egy kórházi ERP-ját értjük, vagy mondjuk egy orvosi eszközt működtető, képelemző algoritmussal megtámogatott megoldást.

"Nem feltétlenül a BA fogja a low level szakmázást csinálni a projektben. "
Nem is feladata. Feladata érteni ahhoz a területhez, aminek a szoftveres támogatását csinálják, és érteni annyira az informatikához, hogy el tudja mondani úgy a szakmai részt, hogy egy informatikus is megértse. Nem kell tisztában lennie modern keretrendszerekkel, modern szoftverfejlesztési elvekkel, modern metodológiákkal. Tipikusan olyan emberek ők, akiket érdekel 1-1 szakma szakmai része (de nem szakembere annak), és régebben programozó volt.

"Nyilván nem mindegy, hogy orvosi projekt alatt egy kórházi ERP-ját értjük, vagy mondjuk egy orvosi eszközt működtető, képelemző algoritmussal megtámogatott megoldást."
Nyilván nem, és az utóbbi sok esetben nem termékfejlesztés, hanem kutatás, hiszen lehet, hogy nincs is jó algoritmus, nem ismert még a szakmai része sem a dolognak.
Ez más, mint amikor minden szakmai részlet ismert már (azaz tekinthetjük úgy, hogy a kutatás lezárult), de nincs jó minőségű szoftver az adott területen. Dolgoztam ilyenen, meglévő kutatási témákat öntöttünk használható szoftverbe, mert a kutató által használt bemeneti file-ból kimeneti file-ba dolgozó algoritmust megvalósító program minden, csak nem éppen általánosan felhasználható, normális UI-val rendelkező szoftver. Ehhez persze a meglévő kódot teljesen át kellett gyúrni (sőt, igazából újraírni), hogy lib legyen belőle, stb. És ez már szoftvermérnöki feladatkör, nem pedig business domain.

Nem! Nem! Nem! Nem! Nem! Nem! Nem! Nem! Nem!

Nem XY programozási nyelvet kell megtanulni, hanem szoftvert fejleszteni. Abba az algoritmikus gondolkodáson kívül valamilyen szintű algoritmikus ismereteken át a karbantarthatóságig és mindenféle pattern, és best practicle beletartozik.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

+1, Értse meg a feladatot, tudjon hozzá módszert és eszközt választani, tudja ezeknek megfelelően részekre bontani. Nem kell, hogy az utolsó eljárás/függvény/objektum nevét, paraméterezését, mellékhatásait és hülyeségeit is 100%-os pontossággal ismerje - az a kódolással foglalkozó emberke feladata, akinek nem feltétlen felsőfokú képzésre van szüksége, hanem gyakorlatra, és az általa használt nyelv/eszköz ismeretére.

A vicc az, hogy nálunk (BME MIT) a tárgyak - mondjuk a szakirány biztosan - az ipar (pl Bosch) kérései alapján lettek összerakva.

Vagy nézhetjük az új tantervet: az iparban (Ericsson, NI, Duolog, talán LightWare, de Google, Microsoft is) ma használt módszereket tanítunk már első félévben, digitális technikán (minimumra vettük a Karnaugh-táblát, meg ezeket a vackokat, erre van szoftver. Aztán persze pont amiatt, hogy ezeket kivettük, gyakran nem áll össze a kép, mert kimarad egy logikai lépés az anyagból.). Az is fura, hogy még ezekre a kurrens dolgokra is azt mondják, hogy elavult. Pedig ebből elég nagy a kereslet.

Amúgy a vicc az, hogy vígan meg tudunk abból élni, hogy cégek számára tanfolyamot tartunk az egyetemi óráink tematikájából. Nagy az igény rá, a cégeknek meg imho tiszta ráfizetés, mert küldik pénzért azokat, akik korábban megtanulhatták volna.

Mondjuk ha már kérések és tanársegédek és hasonlók. Igazából nem lenne rossz, ha az egyetemen több olyan ember tanítana, aki dolgozott is az iparban és járt már az egyetem falain kívül.

Egy szóval sem mondom, hogy mindenki hülye, aki tanít, de amikor a velem együtt kezdett próbál tanítani engem, de végül én jövök rá, hogy mi a hiba vagy nekem kell rámutatni, hogy gyakorlatban miért (nagyon) nem jó ötlet ezt vagy azt csinálni, akkor azért picit hadd minősítsem már a rendszert, amit fentebb védeni próbáltál.

Szóval jó dolgok ezek, mikor egy-egy cég próbálja előrerugdosni az oktatást (nálunk is aktívan próbálják bevonni a cégeket), de lenne hova fejlődni jócskán.

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

Az "iparból" a jelenlegi jövedelmi viszonyok között jó gyakorlati szakembert nem fog tudni teljes állásra elcsábítani egyik hazai felsőoktatási intézmény sem. A lelkesedés, meg a tanítani vágyó lélek kevés a jövedelmi különbségek áthidalásához.
Más a '90-es években is azt mondtuk nem egy tárgyra, hogy nem azt tanítják, amire az iparban szükségünk lesz, hanem azt, amit a tanszéken dolgozók le tudnak jól-rosszul adni.
Voltak persze kivételek: méréselméletetből például egy iparból érkezett oktatónk volt - a tárgy nevével ellentétben bőven kaptunk jól használható, gyakorlati ismereteket is tőle.
Aztán ez abban csúcsosodott ki, amikor olyan 6-7 év gyakorlattal visszamentem kiegészítő képzésre az egyetemi diploma megszerzéséért... Hogy is mondjam csak... Volt talán 2-3 olyan oktató, akinek a tárgyát érdemes volt csinálni - de rájuk anno nappalin is felnéztünk, mert szakmailag, emberileg és pedagógiailag(!) nagyszerű emberek, aztán volt néhány olyan tárgy, ami "ránézésre" hasznosnak tűnt, de azzal a tapasztalattal/gyakorlattal, ami akkor megvolt nekem, nagyjából helyet is cserélhettem volna az oktatóval - és naprakészebb lett volna a leadott anyag, és volt egy rakat "na ez mi a fenének" tárgy is - a matek meg fizika szigorlatot nem sorolom ide, de például egy gépgyártástechnológia (forgácsolás, képlékeny alakítás) egy olyan oktatóval, aki egyetemi tanárként nem küldhető csak úgy nyugdíjba, ellenben féléves feladatként kiad olyat, hogy kézzel írva/rajzolva (kézzel keretezett papíron...) készítsen a hallgató egy megadott forgácsoló megmunkálási módról néhány oldalas leírást.
A legnagyobb poén a kieg. képzésen egyébként az volt, hogy tárgycserebere miatt majdnem az egyik csoporttársunk (aki egyébként nagyon jó fej tanszéki mérnök volt anno) került be az indexbe, mint tárgyjegyző - ugyanis adott témában ő volt az, aki a nappalisokat okosította :-D

Ebben egyébként szerintem nem csak a fizetés a ludas, hanem maga a rendszer is. Ugye egyetemek kutatóhelyként is szolgálnak, ami szép meg jó, csak nem biztos, hogy mindenki alkalmas rá, viszont arra meg nagy szükség lenne, hogy jó minőségben tudást átadjanak egyesek. Egyszerűen olyan nincs, hogy mindenki mindenre alkalmas.

Találkoztam már olyannal, aki semmire nem alkalmas, olyannal, aki nagyon jó kutató, de tanárnak csapnivaló, olyannal, aki tényleg jó tanár és olyannal is, akinek tényleg nagy tudása van, esetleg tapasztalt szakember is, de egyszerűen borzasztó előadásokat/gyakorlatokat tartott. (A mellékes apróságot, hogy egy-egy szomszédból áttévedő valamilyen tanár szakot végző hallgatók hány dolgot szoktak emlegetni, hogy mi hogyan és miért megy szembe azzal, amit tanítanak, már ne is említsük. :)

Egyébként a rakat mi a fenének tárgyakkal mindig el lehet vitatkozni. Fizika igen hamar pofán fogja csapni az embert, amint picit dolgozni is akar valamivel, ami valami kézzelfogható dologgal fog dolgozni, akár csak tárolt adatok szintjén. Én most tervezgetek hobbi szinten valamit, ott hamar szembejött az, hogy le kell porolnom a fizika, elektro-, irtech- és digrendszerek ismeretem.

De hozhatnám példának a vállalati információs rendszerek című tárgyat, amit nálunk sokan nem értenek, hogy ugyan minek, viszont vizsgán úgy mentem át, hogy nekem azokat gyakorlatban kellet tudni. De ugyanígy ad egy csomó olyan plusz szemléletmódot, ami hasznos lehet akkor, ha valami processzt kell leírni, modellezni majd azt számítógéppel megtámogatni. (De itt is mondhatnék példát, ahol végül gyakorlatilag a VIR-es ismereteket felhasználva kellett egy mini-ERP-t összerakni az egyik hobbiprojektemhez, mert követhetetlen volt a hozzávalók beszerzése Excelben a mennyisége és az árusok száma miatt.)

Szóval nem feltétlen haszontalanok ezek, csak ha rosszul, használhatatlanul tanítják meg. Probléma meg leginkább itt van, hiába erőlködnek itt egyesek, hogy dejólvanezígy.

(És mielőtt kapnék egy erős visszatámadást, hogy mert a hallgatók kitartása, motivációja és a többi - amivel szintén van nem kevés baj -: talán a tanároknak is el kellene gondolkoznia azon, hogy miért veszti el sok hallgató a motivációt a felénél.)

----------------
Lvl86 Troll, "hobbifejlesztő" - Think Wishfully™

És sok esetben volt olyan tárgyam, amikor azt mondta az oktató, hogy nem lesz gyakorlati jegyes ZH, mert nincs kedve ennyi Zh-t javítani, menjen mindenki vizsgázni. Amikor az oktató is leszarja a színvonalat....persze volt olyan oktató, akinél már az is nagy szó volt, hogy meglett a ZH-d. Nem is felejtettem el az anyagot, hiszen hetente végig kellett számolni a példákat, hogy értse az ember.

Ezt magánban megírnád, melyik egyetem, melyik oktatója?
(Amúgy ilyesmi szövegeket én is szoktam mondani, de csak marháskodva, általában valami TVSz szabályos bonyodalmak voltak a háttérben).

Az oktató és a színvonal: erre fentebb írtam.
Sokszor egyébként előfordult velünk, hogy tanítottunk, elmondtunk volna többet is, de egyszerűen a hallgatóság befogadóképessége nem bírta.

Ha nagyon érdekel, én konkrétan összevesztem a TO-val, amikor két évvel neptun átállás után félév közepén közölték, hogy mostanra vették fel az előfeltételeket, és eszerint az egyik tárgyamhoz már egy ideje kellett volna egy másik, és hogy akkor azt törlik. Én meg mondom ez az egy tárgy volt, amiért nem passzíváltam a félévet, a többi keresztféléves, akkor lesznek szívesek vagy utólag passziválni és törölni a féléves tandíjat, vagy nem félév közepén nekiállni köcsögösködni. A válaszukat gondolom kitaláltad :) Mivel akkor már teljes állás mellett csináltam, és nulla előnyét láttam a későbbiekre, otthagytam. Majd talán egyszer normális egyetemen, külföldön.

Csak, hogy ONtopic legyek.

Sikerült a vizsga! :)

"Az sem bátorítja a középiskolásokat, hogy az terjed az informatikus szakokról, hogy az első félévben az évfolyam felét rendre megbuktatják matematikából. Ez a szintű informatikai pályaorientáció Horváth szerint abból az időszakból maradt meg, amikor egy informatikusnak a gép működésétől kezdve, a fizika és a matematika elméleti részletein keresztül a programokig mindenhez kellett értenie. És régen ez a buktatási arány lehet, hogy indokolt is volt, mivel korábban tényleg csak a legkiválóbb matekosok lehettek jó szakemberek, de mára már és annyira leegyszerűsödtek az egyes részfeladatok, hogy nem kell mindenkinek a legjobbnak lennie minden területen.

Ráadásul a felsőoktatással sincs minden rendben, amit jól mutat, hogy 2015-ben már 52 százalék volt a felsőoktatásban a lemorzsolódás, nagyon sokan otthagyják a képzést. Ennek az az oka, hogy a felsőoktatási képzés munkaerőpiaci relevanciája egyre kisebb. A hallgató így sok esetben ugyanolyan jó állásokra pályázhat attól függetlenül, hogy kettő vagy négy év egyetem van a háta mögött. Ezt a hallgatókon kívül a vállalkozások is érzik, és most már úgy vannak vele, hogy mindegy, hogy másod-, harmad-, vagy negyedéves informatikus vesznek fel, mert úgyis mindenkit ugyanarra a féléves céges képzésre kell elküldeni."

http://index.hu/gazdasag/2016/03/04/informatikushiany_munkaeropiac_okta…

>szakma egyik legnagyobb vesztesége: az, hogy a lányok azért nem mennek informatikusnak, mert a társadalom férfiszakmának állítja be az IT-állásokat, miközben nem tudunk semmilyen okról, ami miatt a lányok kevésbé lehetnének jó programozók, mint a fiúk.

A lányok azért nem mennek informatikusnak mert kúúúrvára nem érdekli őket. Valamint minden évfolyam 99%-a nyomorék így pasizni sem lehet értelmesen.

De ja a társadalom hibája :D

Hm, hát nem tudom, melyikőtök a hímsovinisztább, ha szerinted a női létből fakad a cipőimádat. Szerintem meg szocializációs kérdés, ha egy lányt hejcegnőnek nevelnek, akkor odalesz a cipőkért és nem lesz belőle programozó. Én is kissé furcsának találtam ezt a cipővásárlásos megjegyzést, lévén ismerek műszaki vonalon mozgó nőket, és nem jellemző rájuk ez a fajta viselkedés, van aki egyenesen utál vásárolni. De szerintem inkább úgy kell nézni ezt a dolgot, hogy kitaláltak egy szöveget, amivel az eddig nem érdeklődő nőknek felkelthetik az érdeklődését, oszt' kész, ti meg itt nekiálltok vitatkozni rajta :D

Szögezzük le, hogy a csajok is lehetnek jó programozók. Nekem is volt olyan női tanárom, aki országosan elismert, és matematikából is penge volt. A másik meg nem csak hogy értette a az adatbázis elméletet, de baromi jól elő is tudta adni. Le a kalappal előttük!

De, ha bármelyik a cipővásárlásról vagy a prezentáció készítésről beszélt volna a lényeg helyett, akkor ott helyben körberöhögtem volna mindkettőt. (Nyilván sosem volt ilyen.)