Hogyan is csináljam?

Hogyan is csináljam?
2016-11-17T22:55:06+01:00
2016-12-07T21:22:37+01:00
2022-10-20T02:45:33+02:00
  • Csak ez nem bizonyít és támaszt alá semmit.

    Ennyi erővel minden légbőlkapott spekulációt igaznak kellene elfogadni. De nem fogadunk. Ez már csak így működik az érvelésben és a vitában.

    Oké, akkor fordítsuk meg. Figyelj, mert az ellenkezőjét fogom mondani annak, amit eddig:

    A codecool-ra alapozva, egyetem nélkül nem lehet ugyanarra a szintre eljutni, mint egyetemmel.

    Hoppá, csak nem egy légbőlkapott állítás? Hát ezt bizony akkor nem lehet elfogadni. Affranc. Niacinnak biztos nem fog tetszeni. Jajj, mi lesz?!
    Mutasd a teljes hozzászólást!
  • Ez érdekesen hangzik. Az biztos, hogy gyakorlati szempontból többet nyújt, mint az egyetemi képzés. Ott fejleszteni nem tanít meg senki. Ezzel persze nem azt mondom, hogy az egyetem hasznontalan, az átadott elméleti ismeretek jó része nagyon fontos a munkád során is.

    Ha jól értem, te kb. a képzés 1/3-ánál tartasz, könnyen lehet, hogy lesz itt még bőven szó a fontos elméleti témákról is. De ha nem, akkor is hiánypótló ez a suli, még ha nem is hibátlan :) Ha a szakma szeretetét és a kritikus gondolkodást sikerül átadni, akkor már nagyon jól álltok.
    Mutasd a teljes hozzászólást!
  • - Mennyire gyakoroltatják be az alapszintű algoritmikus gondolkodást, a problémák részekre bontását? Tudnál példákat mondani, hogy milyen feladatokat kell megoldanotok?


    Szerintem ez elég alap dolog, nem is nagyon lehet programozni nélküle, a legegyszerűbb for-ciklus is egy algoritmus. Pythonban kezdtünk, először funkcionális (lineáris? - ezalatt azt értem, amikor a programban a funkciók elhelyezkedésének sorrendje is számít) megközelítéssel, aztán áttértünk OOP-re még pythonon belül, majd Java-ra. A részekre bontásra folyamatosan törekedünk, single responsibility-t alkalmazunk, ahol lehet, meg MVC modellt és különböző egyedi megvalósításait. Egyébként biztosan van aki jobban tudna ezekre válaszolni, én a nevekkel általában bajban vagyok.. :)


    - Beszélnek-e programszerkezetről, architektúráról?

    Beszélni nem beszélnek, mert nem nagyon van frontális oktatás, online tananyagot kapunk az aktuális projekthez szükséges elméletekről. Ha jól gondolom, az MVC pl ide tartozik.

    - Vannak-e alapszintű elméleti ismeretek (nagyordó-jelölés, egyszerű véges automaták, stb.)? Ezeknek elmondják a tényleges gyakorlati hasznát?

    Ilyesmiről nem volt szó.

    - Automatizált teszteket írtok-e?

    Igen, épp most tanuljuk a JUnit-Mockito párost.

    - Használtok verziókezelőt? Ha igen, milyet?

    Gitet használunk.

    - Folyamatos integráció van?

    Csapatokban dolgozunk, természetesen igen.

    - Mennyire tudatosítják az egyes paradigmák (objektumorientált, funkcionális) alapelveit, mennyire gyakoroltatják ezek használatát?

    Ez a mennyire elég nehezen megválaszolható képzés. Minden nap ezeknek az alkalmazásával dolgozunk, folyamatos visszajelzést kapunk arról, hogy megfelelő-e.

    - Milyen nyelv(eke)t használtok?

    Python, JavaScript, Java, SQL, HTML. Scratch :)
    Mutasd a teljes hozzászólást!
  • Egy tanárnak (iskolának) mondjuk van annyi előnye, hogy legalább tudja, hogy milyen tudások léteznek már, amit meg lehetne tanulni, de egy amatőrnek még ezzel is meg kell küzdeni, olyan ez mint  a pecázás, ha tudod hol a hal, meg mikor jön, hamarabb megfogod. :)
    Mutasd a teljes hozzászólást!
  • Én azt mondom, hogy szerintem a codecool-féle képzésre alapozva is el lehet érni olyan szintre a szakmában, mint egy egyetemi képzéssel. Nincsen rá különösebb alapom, legfeljebb annyi, hogy az egyetemen oktatott tananyag az egyetemen kívül is elérhető és megtanulható, a lényeg pedig - ahogy többen is mondták - úgyis a tapasztalat.

    Tökmindegy, hogy ki az istencsászár, vagy a hülye, a vitában az állítások számítanak és az érvek, mindegy, hogy ki írja. Márpedig te ezt írod:

    a codecool-féle képzésre alapozva is el lehet érni olyan szintre a szakmában, mint egy egyetemi képzéssel

    Majd mondod, hogy részedről nincs alapja, csak ez:

    hogy az egyetemen oktatott tananyag az egyetemen kívül is elérhető és megtanulható

    Azt hiszed, hogy nem értem, mit írsz. De értem. Csak ez nem bizonyít és támaszt alá semmit. Sem az nem következik belőle, hogy ugyanoda eljuthatsz, sem az, hogy hatékonyabban. (Meg aztán azt a pár száz éves jelenséget kellene megmagyaráznod, hogy miért üzemeltetünk iskolákat, ha nélkülük is lehetséges és ugyanannyi munkával meg lehet mindent tanulni könyvekből is. Régen is elérhető volt minden, ez nem csak az internettel jött el.) De továbbra is várom az érveket.

    Ha ezt cáfolni tudod, akkor van miről beszélni, ha nem, akkor nincs.

    Nem, neked kell az állítást alátámasztani, mert te állítasz. Ennyi erővel minden légbőlkapott spekulációt igaznak kellene elfogadni. De nem fogadunk. Ez már csak így működik az érvelésben és a vitában.

    Ugyanakkor anélkül, hogy tényekkel (tényekre épülő logikai levezetéssel), vagy konkrét tapasztalattal meg tudnám cáfolni, én sem kötök bele abba, amit te mondasz (már ha mondasz egyáltalán valamit).

    Semmi gond, második szálként cáfolhatod.
    Mutasd a teljes hozzászólást!
  • Figyelj, ez már tényleg annyira értelmetlen, hogy azon is vitázni akarsz, hogy hogyan kell vitázni. Legyen gyereknap, bevallom, hogy én tökhülye vagyok, te meg az istencsászár akinek mindenben igaza van, és így talán beszéhetünk a lényegi dolgokról.
    De tényleg, térjünk vissza az alapokhoz.

    Én azt mondom, hogy szerintem a codecool-féle képzésre alapozva is el lehet érni olyan szintre a szakmában, mint egy egyetemi képzéssel. Nincsen rá különösebb alapom, legfeljebb annyi, hogy az egyetemen oktatott tananyag az egyetemen kívül is elérhető és megtanulható, a lényeg pedig - ahogy többen is mondták - úgyis a tapasztalat.

    Ha ezt cáfolni tudod, akkor van miről beszélni, ha nem, akkor nincs. Ugyanakkor anélkül, hogy tényekkel (tényekre épülő logikai levezetéssel), vagy konkrét tapasztalattal meg tudnám cáfolni, én sem kötök bele abba, amit te mondasz (már ha mondasz egyáltalán valamit).

    Ui.: a tökhülye/istencsászár felállás maradhat, amíg neked jólesik.
    Mutasd a teljes hozzászólást!
  • Amúgy az sem véletlen, hogy a legtöbb hallgató a beadandóknál utólag készít tervet a már kész implementációhoz. Erre szimplán az a válasza a hazai felsőoktatás védelmezőinek, ami minden kritikára, hogy biztos mind lusta, trehány, a valóságban viszont a nem lusta, nem trehány hallgatók többsége is ezt csinálja, mert ha csinálnak is előtte valamilyen tervet, az úgysem lesz alkalmas arra, hogy beadják, úgyhogy csinálnak utólag egy tankönyvi tervet is.

    Nem véletlen, de szerintem simán a tapasztalat hiányából adódik. Nem feltétlenül tudják elsőre, fejben átgondolni mi fog működni. Ez csak hosszú évek tapasztalatával jön, ezt önmagában nehéz oktatni szerintem.

    Szerintem hasznosabb lenne különbontani a két feladatot (rendszerterv készítés és specifikációk alapján rendszer tervezés) egymástól.

    A rendszerterv készítést egy olyan rendszerhez kellene adni, amiről már tudják hogy működik, ergo tudják mit kell ledokumentálni és ezen tudják gyakorolni hogy kell egy elképzelést tervbe önteni.
    A rendszerterv alapjáni fejlesztést meg értelemszerűen egy rendszerterv alapján.

    Gyakorlatilag a diák is ezt csinálja mikor utólag dokumentál.

    Nem feltétlenül lehet elvárni tapasztalat nélkül hogy elsőre meg tudja tervezni hogy is fog működni a rendszer, és az tényleg működjön is.
    Mutasd a teljes hozzászólást!
  • A 90-es években nagy felhajtás volt a CASE körül, a betűszót (Computer-Aided Software Engineering) a CAD (Computer-Aided Design) mintájára alkották. Az ideálisnak tekintett munkafolyamat az volt, hogy a tervezők által véglegesített UML-ből egy eszközzel kódot generálnak, és az implementációt beosztott fejlesztőknek adják ki. "Itt ez a függvény, ezek a paraméterek, ez a visszatérési érték, ezt kell csinálnia, töltsd ki a közepét." Nem magamtól találom ki, ez tényleg így működött, több ismerősöm is dolgozott ilyen helyeken. Nem zárom ki, hogy létezik még olyan hely, ahol ez hasonlóan megy, tehát lehet, hogy nem volt jogos azt mondanom, hogy a módszer teljesen megbukott.

    Itt szerintem összemosol több dolgot.

    1. Az itt ez a függvény ezt kell csinálnia dokumentációs megoldással nincsen semmi baj, ezt kell egy high-level rendszertervnek csinálnia. A rendszer főbb részeinek viselkedését és kapcsolódását írja le. Ez gyakorlatilag komponensek API-járól és köztük lévő kommunikációs protokollokról szól. Ezzel önmagában nincs semmi gond. De nem az utolsó szögig lemenően.

    2. A második része, hogy a modellben próbálsz minél több dolgot leírni, olyan dolgokat is amiket előre úgysem tudsz megjósolni, és úgysincs kőbe vésve. Ez a user hibája nem az eszközé. Nem kell az utolsó sorig lemenően mindent dokumentálnia modellben. Nem is lehet, hiszen akkor a modellben programoznál, és valójában nem is kellene semmit kitölteni, és a modell átvenné a source repository szerepét is, valamint az architect egy személyben effektíve lekódolná az egész projektet a modellben a tervezési fázisban, ami több okból sem működik
    - idő
    - a tervezési fázisnak nem kellene az egész projekt implementálását tartalmaznia,
    - egy ember implementálja az egész rendszert? mennyi ideig tart az? pont az lenne a cél hogy párhuzamosítani lehessen
    - először megírjuk az egész rendszert, anélkül hogy valaki futtatná és tesztelné? Hallottam emberekről, akik ezt meg tudják csinálni. De nem kell hozzá két kéz sem, hogy megszámoljam őket. És nem hiszem, hogy ők egy modellező eszközben szeretnék megírni a kódot.

    3. Kódgenerálás, különös tekintettel a modell és kód közötti oda-vissza transzformációkra. Ez vagy működik vagy nem, vagy hiba vagy nem, de nem önmagában jó vagy rossz. Csak egy feature az eszközkészletben ami vagy megvan vagy nincs.

    4. Hol tároljuk a diagramokat. Erre igazán nincs jó válasz. Hasznos azokat a modellező eszközben tárolni, mert akkor könnyen lehet módosítani őket. Viszont kellemesebb őket valami dokumentumba beágyazva olvasni. Ezért van rengeteg dokumentáció generálási funkciók a case eszközökben. Az már a case eszközök egy tulajdonsága hogy mennyire állnak az utadba, ha te tulajdonképp egy kis módosítást szeretnél csinálni, és nem akarod órákon keresztül generálni az egész doksi halmazt.

    Az viszont nagyon határozott véleményem, hogy ez a folyamat túl merev ahhoz, hogy jó szoftver legyen az eredménye. A visszacsatolási ciklusok rendkívül hosszúak, ha vannak egyáltalán.

    Ez viszont nem az eszközről szól, hanem a szoftverfejlesztési metodológiáról: waterfall vagy iteratív? Az előre megtervezünk mindent, az a waterfall, és igen, erről már nagyon régen bebizonyosodott hogy túl merev, nem képes gyorsan az igények változására reagálni. De ez nem a CASE eszközről vagy az UML-ről, és nem is a kódgenerálásról szól.

    A szakma mai élvonala, amennyire én az általam olvasott cikkek, általam látogatott/interneten nézett konferenciák alapján látom, teljesen elvetette ezt a filozófiát, és legfeljebb dokumentációs segédletként használják az UML-t. Ennél többet egyébként senki más nem állított, te sem, tehát nem értem, mire fel a nagy felháborodás.

    Ez nem feltétlenül van így. Vannak kódgeneráló eszközök, ahol a modellben definiálsz dolgokat és ebből generálsz sok mindent, akár roundtrip-el is. De ne felejtsük el azt az egy dolgot, hogy ez nem feltétlenül a projekt elején történik, és jellemzően nem a high-level rendszertervből, és jellemzően nem is a lead architekt csinálja hozzá a modellt sem, és végül de nem utolsó sorban, nem mindent.

    A felháborodás szerintem annak köszönhető hogy összemostál egymástól jórészt független dolgokat és egyöntetűen állítottad rájuk hogy elavult és nem használják, holott az csak egy dologra igaz, és egy másikre esetleg félig.

    A téves analógia úgy néz ki, hogy az architect, mint egy építész, megtervezi a rendszert, a programozók pedig kőművesek módjára megépítik.

    Már csak azért is téves az analógia, mert nem is ez az elképzelés senkinél.

    A tervezési feladatok sem egyszintűek, és az építészetben is van építész mérnök és építőmérnök.
    Ennek nagyjából megfelel szoftverfejlesztésben az architect és designer megkülönböztetés, és persze további szinteket is be lehet vezetni a munkamegosztás céljából.

    A valóság pedig az, hogy az architect és a fejlesztők munkája a tervezés egy-egy fázisa, az építőket pedig a fordítóprogram vagy az értelmező helyettesíti. A fejlesztés minden szinten iteratív folyamat.

    De nem vagyok benne biztos, hogy valaha valaki is értelmezte úgy ahogy azt te állítod, hogy tették. Szerintem túlságosan leegyszerűsítetted a képet a múltról is, és egyes helyek hibájából általánosítottál arra, hogy mindenhol az volt.

    Egyébként nagyon eltértünk az eredeti témától, szegény Matyenko barátunk, ha még olvassa az üzeneteket, lehet, hogy alaposan újragondolja a pályaválasztást.

    Az sose baj, ha tudja mibe ugrik bele
    Mutasd a teljes hozzászólást!
  • Ismételten és rendkívül nyomatékosan kiemelem, hogy senki soha nem állította itt, hogy magával az UML-lel lenne a baj, hanem a hozzá kapcsolódó elavult munkafolyamattal. Tehát a gond sem az, hogy ki mit ért bele az UML-be. Nem bírom ésszel felérni, hogy lehet valakinek olyan csőlátása, hogy annyit lát az egészből, hogy ÚÚÚEMELL ROSSZ, és habzó szájjal a védelmére kel. Bár az is tény, hogy csak magát égeti le.
    Mutasd a teljes hozzászólást!
  • Látom az lesz a gond, hogy ki mit ért bele az UML-be, és mit nem.
    Mutasd a teljes hozzászólást!
  • A sw beadandók témáját, működési logikáját a hallgató választja, alakítja menet közben is akár, ezért nem érdekes előre az UML. Vegyünk egy példát: malom játékot talál ki beadandónak, egyedül a nyelv a megkötés. (ami éppen tanul abban a félévben)

    1. lépés: keresés a Youtubon, ki hogyan programozta le a malom játékot az éppen tanult nyelvre.
    Van találat = öröm és bódottsá, nincs találat: nem baj, legyen más a programom

    2. lépés: Saját kód készítés közben akadály merül fel.
        2a: Youtube mit hoz erre.
        2b: Stackowerflow és társai mit mondanak.
        2c: Tankörben valaki?
    Van találat = öröm és bódottsá..., nincs találat: nem baj, legyen másképp a szabály, a logika, a kinézet, a működés! Belefér a megoldásba ez a lehetőség!

    Nem írom végig, de belátható, hogy az UML miért csak a legvégén fog elkészülni. Mások a célfüggvények egy beadandónál.

    Na most vegyünk egy "hitelkérelem elbírálási" üzleti folyamatot támogató szoftvert. és nézzük azt. Kell előre definiálni a kóderek számára az üzleti logikát, a diszkussziókat stb. stb. (rendszerterv)? Kell! Van rá univerzális eszköz. Van.

    A prioritások eltérése ne legyen már a felsőoktatás bűne!
    A felsőoktatás feladata az elmélet, a szemlélet és esetleg néhány konkrét eszköz használatának átadása. Ezt többé kevésbé meg is valósítja.
    Mutasd a teljes hozzászólást!
  • A 90-es években nagy felhajtás volt a CASE körül, a betűszót (Computer-Aided Software Engineering) a CAD (Computer-Aided Design) mintájára alkották. Az ideálisnak tekintett munkafolyamat az volt, hogy a tervezők által véglegesített UML-ből egy eszközzel kódot generálnak, és az implementációt beosztott fejlesztőknek adják ki. "Itt ez a függvény, ezek a paraméterek, ez a visszatérési érték, ezt kell csinálnia, töltsd ki a közepét." Nem magamtól találom ki, ez tényleg így működött, több ismerősöm is dolgozott ilyen helyeken. Nem zárom ki, hogy létezik még olyan hely, ahol ez hasonlóan megy, tehát lehet, hogy nem volt jogos azt mondanom, hogy a módszer teljesen megbukott.

    Az viszont nagyon határozott véleményem, hogy ez a folyamat túl merev ahhoz, hogy jó szoftver legyen az eredménye. A visszacsatolási ciklusok rendkívül hosszúak, ha vannak egyáltalán.

    A szakma mai élvonala, amennyire én az általam olvasott cikkek, általam látogatott/interneten nézett konferenciák alapján látom, teljesen elvetette ezt a filozófiát, és legfeljebb dokumentációs segédletként használják az UML-t. Ennél többet egyébként senki más nem állított, te sem, tehát nem értem, mire fel a nagy felháborodás.

    Az egész probléma onnan ered, hogy a szoftverfejlesztésre gyártási folyamatként tekintenek, pedig az színtiszta tervezés. A téves analógia úgy néz ki, hogy az architect, mint egy építész, megtervezi a rendszert, a programozók pedig kőművesek módjára megépítik. A valóság pedig az, hogy az architect és a fejlesztők munkája a tervezés egy-egy fázisa, az építőket pedig a fordítóprogram vagy az értelmező helyettesíti. A fejlesztés minden szinten iteratív folyamat.

    Erre a hierarchikus gondolkodásra értettem, hogy elavult, és úgy látom, aki jóhiszeműen olvasta az eredeti hozzászólásomat, egyből értette is, de így remélem, minden kétséget sikerült eloszlatni.

    Egyébként nagyon eltértünk az eredeti témától, szegény Matyenko barátunk, ha még olvassa az üzeneteket, lehet, hogy alaposan újragondolja a pályaválasztást.
    Mutasd a teljes hozzászólást!
  • Nem az UML-el, mint eszközzel van a baj, hanem a szemlélettel, ahogyan a szoftvertechnológiát oktatják. A gyakorlatban nem úgy, nem arra a célra, és nem annyi UML diagram készül, mint ahogy előadják. Ahogy egyébként a szoftverfejlesztési modellek is elavultak, amiket oktatnak. Te folyton a szemléletátadással érvelsz, mikor véded a hazai felsőoktatást, holott pont ebben bukik meg leginkább. Egyszer megkérdeztem, milyen szemlélet, mert nagyon nem mindegy milyen, szerintem a rossz szemlélet sokkal nagyobb kárt okozhat, mint ha nem lenne semmilyen szemléletátadás.

    Nem, konkrétan arra kérdeztem rá balazsbotond-tól, miért mondja, hogy megbukott koncepció és hogy eltűnt, mikor nem látom eltűntnek, tehát nem biztos hogy ugyanarról beszélt mint amire én gondoltam.

    De szerintem konkrétan nem az UML oktatásáról beszélt, mikor azt mondta, hogy megbukott és eltűnt, szóval megvárnám mire gondolt mielőtt jobban belebonyolódnánk.
    Mutasd a teljes hozzászólást!
  • Nem az UML-el, mint eszközzel van a baj, hanem a szemlélettel, ahogyan a szoftvertechnológiát oktatják. A gyakorlatban nem úgy, nem arra a célra, és nem annyi UML diagram készül, mint ahogy előadják. Ahogy egyébként a szoftverfejlesztési modellek is elavultak, amiket oktatnak. Te folyton a szemléletátadással érvelsz, mikor véded a hazai felsőoktatást, holott pont ebben bukik meg leginkább. Egyszer megkérdeztem, milyen szemlélet, mert nagyon nem mindegy milyen, szerintem a rossz szemlélet sokkal nagyobb kárt okozhat, mint ha nem lenne semmilyen szemléletátadás.

    Amúgy az sem véletlen, hogy a legtöbb hallgató a beadandóknál utólag készít tervet a már kész implementációhoz. Erre szimplán az a válasza a hazai felsőoktatás védelmezőinek, ami minden kritikára, hogy biztos mind lusta, trehány, a valóságban viszont a nem lusta, nem trehány hallgatók többsége is ezt csinálja, mert ha csinálnak is előtte valamilyen tervet, az úgysem lesz alkalmas arra, hogy beadják, úgyhogy csinálnak utólag egy tankönyvi tervet is.
    Mutasd a teljes hozzászólást!
  • "UML-hegyek" alatt én a szörnyűséges UML-vezérelt fejlesztést értettem, amikor a nagyvállalatnál a vezető rendszertervező úr megrajzolja a diagramot, és a kis majmocskák szorgosan lekódolják. Ez tudtommal (remélhetőleg) teljesen eltűnt, de az egyetemen nekünk azt sugallták, hogy ilyen a szép "szoftvermérnöki" munka.

    Nem látom a különbséget. Jelenleg a tipikus helyzet, hogy a UML diagramok más dokumentumokba beágyazásra kerülnek. Netán azt szeretnéd, hogy a környező dokumentumokban leírható bővebb magyarázat elmaradjon, és csak az UML diagramokból szeretnéd kisilabizálni, mi is a kövelmény (és aztán mehet mindenki vissza pontosításra ahelyett hogy a doksi szabadszöveges részét elolvasta volna).

    Vagy esetleg az a bajod, hogy bizonyos feladatokat delegál a lead architect delegál?

    Nem látom mi az ami szerinted rossz és mi az ami szerinted eltűnt.
    Mutasd a teljes hozzászólást!
  • Az egyetemeken szoftvertechnológia néven oktatott 90-es évekbeli, gyakorlatban teljesen megbukott módszereket (pl. CASE eszközök használata, UML-hegyek) legfeljebb mint elrettentő példát tartom hasznosnak.

    Jézusom, hol élsz te? Ezek nem megbukott módszerek.

    Mégis hogyan akarsz egy követelmény specifikációt vagy rendszertervet elkészíteni?

    Irkafirkával úgy, hogy senki nem tudja milyen jelölés alatt mit értel? Erre van az UML, hogy legyen egy kvázi szabvány aminek a jelölései alatt mindenki ugyanazt érti.

    Esetleg szabványos jelölésekkel de kézzel A0-s papírhegyeket elpazarolva? És ezt utána hogy juttatod el a projekt összes tagjának? Erre vannak a CASE eszközök.
    Mutasd a teljes hozzászólást!
  • Alapvetően egyetértünk, egyes UML-diagramok nagyon hasznosak, én is használom, amiket említettél, főleg dokumentációs célra.

    "UML-hegyek" alatt én a szörnyűséges UML-vezérelt fejlesztést értettem, amikor a nagyvállalatnál a vezető rendszertervező úr megrajzolja a diagramot, és a kis majmocskák szorgosan lekódolják. Ez tudtommal (remélhetőleg) teljesen eltűnt, de az egyetemen nekünk azt sugallták, hogy ilyen a szép "szoftvermérnöki" munka.
    Mutasd a teljes hozzászólást!
  • pl. CASE eszközök használata, UML-hegyek

    Pedig most is alkalmazzák őket, csak te olyan területen mozogsz, ahol nem. UML-t pl. napi szinten használnak nagyon sok helyen. Class, Seq, Package, meg State diagramot leginkább. Az UML többi része valóban ritkábban használt. De az előbbit nem ismerő emberrel gyakran olyan beszélni, mint a kottázást nem ismerő zenésszel. Abban igazad van, hogy a szoftverfejlesztés sok ágában a CASE eszközök a 90-es évek formájában nem jól alkalmazhatók (vagy csak dokumentációra). Viszont dolgozz klasszikus ipari területen, ott ezek még mindig léteznek és használtak.
    Mutasd a teljes hozzászólást!
  • Jól hangzik.

    Kicsit tudnál bővebben írni arról, hogy mit csináltok? Nagyon kíváncsi vagyok.

    Például:

    - Mennyire gyakoroltatják be az alapszintű algoritmikus gondolkodást, a problémák részekre bontását? Tudnál példákat mondani, hogy milyen feladatokat kell megoldanotok?
    - Beszélnek-e programszerkezetről, architektúráról?
    - Vannak-e alapszintű elméleti ismeretek (nagyordó-jelölés, egyszerű véges automaták, stb.)? Ezeknek elmondják a tényleges gyakorlati hasznát?
    - Automatizált teszteket írtok-e?
    - Használtok verziókezelőt? Ha igen, milyet?
    - Folyamatos integráció van?
    - Mennyire tudatosítják az egyes paradigmák (objektumorientált, funkcionális) alapelveit, mennyire gyakoroltatják ezek használatát?
    - Milyen nyelv(eke)t használtok?
    Mutasd a teljes hozzászólást!
  • Nem kell ugyanazt, mert amit eddig állítottál, az légbőlkapott feltételezés volt. Most valamit kellene alátámasztásként írni, de inkább engem minősítesz.

    "Minden alkalommal, amikor valamire nem tudsz érdemben reagálni, megpróbálod kifordítani a vitát és olyan dolgokat próbálsz a számba adni, amit nem mondtam, szóhasználaton akadsz fönt."

    1. Mi nem volt érdemi reagálás?
    2. Hol fordítottam ki a vitát? Konkrétan rákérdeztem az állításaidra és hogy azokat mivel támasztod alá. Ez mióta a vita kifordítása?
    3. Az, hogy egy gondolatot eddig állításként fogalmaztál meg, most meg átminősíted feltételezésre, az nem szóhasználati, hanem nagyon is érdemi és értelmezési kérdés.

    Az előző hozzászólásomban minden ponton a vita elfogadott eszközeivel éltem, ha nem érted, vagy nem ismered, akkor olvass utána (alkalmazd az on-demand önképzés keretében végzett elméleti tanulást).

    Mintha nem is velem vitáznál, hanem egy képzeletbeli valakivel. Teljesen szürreális és semmi értelme.

    Mert nem a te állításaidat és válaszaidat idéztem? Semmi szürreális nincs ebben. A vita így működik, már az ókori görög filozófusok óta. Olvass el a vitáik közül egy párat - ismét egy önképzési lehetőség, ez egyben mutatja is, hogy mennyire nem elég pár frameworköt ismerni tetszőleges szakmai szituációkhoz.

    Nem akarlak meggyőzni, higgy amit akarsz.

    Azt kell megérteni, hogy amikor leírsz (közölsz) egy állítást, akkor az onnantól független a személyedtől, meg azétól is, aki olvassa. Nem miattam, hanem az állításodért magáért kell igazolni - addig az csak spekuláció és feltételezés. Az pedig, hogy erre felhívom a figyelmet, nem kifordítása semminek és nem is szürreális.
    Mutasd a teljes hozzászólást!
  • Annyit tudok megerősíteni, hogy igényes problémamegoldásra és önfejlesztésre nevelnek. És valós problémákon gyakorlunk, céges környezethez hasonló rendszerben.
    Szakmai tapasztalat híján nyilván nem tudom, mennyire van arról szó, amit mondasz, de a cégek visszajelzései alapján (most, a hetedik hónaptól péntekente megnézik a partnercégek a heti projektjeink demóit) elég jó, ami itt folyik.
    Mutasd a teljes hozzászólást!
  • Belefáradtam, hogy minden második válaszomban ugyanazt kell elmondanom, mert láthatóan addigra elfelejted. Minden alkalommal, amikor valamire nem tudsz érdemben reagálni, megpróbálod kifordítani a vitát és olyan dolgokat próbálsz a számba adni, amit nem mondtam, szóhasználaton akadsz fönt. Olyan, mintha egy tanuló algoritmushoz beszélnék (persze azzal a különbséggel, hogy az nem felejtené el, amit két lépéssel előbb mondtam). Mintha nem is velem vitáznál, hanem egy képzeletbeli valakivel. Teljesen szürreális és semmi értelme.
    Nem akarlak meggyőzni, higgy amit akarsz.
    Mutasd a teljes hozzászólást!
  • Előre is elnézést mindenkitől, de kicsit elterelném a beszélgetést a vérre menő küzdelemről.

    Én autodidakta fejlesztő vagyok, hobbiként kezdtem programozással foglalkozni, amiből később szenvedély lett, majd állás, és valahol a folyamat közepén mentem el egyetemre, hogy meglegyen "a papír".

    Az a tapasztalatom, hogy Magyarországon és ha jól látom, a világon máshol sem oktat senki szoftverfejlesztést. Programozást igen (létezik az említett OKJ-s képzés), és számítástudományt is (mérnök- és programtervező informatikus szakok), de jó fejlesztő csak magától lesz az ember.

    Az egyetemeken szoftvertechnológia néven oktatott 90-es évekbeli, gyakorlatban teljesen megbukott módszereket (pl. CASE eszközök használata, UML-hegyek) legfeljebb mint elrettentő példát tartom hasznosnak.

    Ellenben amikor elkezdtem az interneten kutakodni, hogyan lehetnék jobb a szakmámban, itt is, ott is kis kincsesbányákra találtam - kiváló könyvekre, színvonalas szakmai blogokra, konferenciák érdekes vieóira.

    Mindig érdekelt, hogy miért nincs olyan képzés, ami a fejlesztést oktatja, de azt nagyon magas, közel egyetemi színvonalon. A kérdésem pedig az, hogy a CodeCool vajon ezt az űrt próbálja betölteni? Mert ha igen, akkor mindenképp jó iránynak tartom, és az alapján kéne megítélnünk, hogy ezt a célt sikerül-e elérnie. Ha viszont az a célja, hogy futószalagon pár hónap alatt olyan kódmajmokat képezzen, akik teletömhetik az önéletrajzukat a legújabb divatszavakkal, hogy megcsípjenek egy zsíros junior fejlesztői állást, akkor nagyon szomorú leszek.
    Mutasd a teljes hozzászólást!
  • "Most komolyan úgy akarsz vitatkozni, hogy minden egyes feltételezést alá kell támasztanom"

    Vitatkozni biztosan lehet így is, viszont vitázni csak érvekkel lehet. Pár hozzászólással ezelőtt még nagy mellénnyel kérted tőlem számon a statisztikát, most te meg még az állításaidat is feltételezéssé minősíted. Ha valami feltételezés részedről, az sem baj, akkor azt fogalmazd úgy és kész. Akkor beszélhetünk arról, hogy milyen gondolatok mentén lehet megalapozott egy feltételezés. Olyan állításokra amúgy sem kértem soha igazolást, amit magam is elfogadok, ld. előző bekezdés. Épp ezért én pl. nem kérem bizonyítását annak, hogy egy belépő junior szinthez elég egy CC, mert ezzel egyetértek. Azokba a gondolatokba érdemes részleteiben belemászni, amiben nem értünk egyet.

    De tudod mit? Neked biztosan menni fog.

    Majd eljön ez is, de egyelőre maradjunk a te állításaidnál/feltételezéseidnél.

    Bizonyítsd hát be tényekkel, hogy amit feltételezek az lehetetlen, vagy legalábbis statisztikailag esélytelen. Vagy pedig egyszerűen fogadd el, hogy nem az.

    Ez pedig nem így működik a logikában. Azzal, hogy bárki nem bizonyítja az állításaidat, azok nem válnak bizonyítottá. Továbbá én sem mondom, hogy lehetetlen, tehát azon ne vitázzunk - de azt továbbra is igazolnod kell, hogy nem csak egy valószínűtlen elméleti lehetőségről beszélsz. Erről pedig két módon győzhetsz meg (engem): vagy statisztikával (lehet az közösen elfogadott anekdotikus észrevétel is), vagy közösen elfogadott gondolatok logikai következményeivel. Itt pedig ráadásul igaz az is, hogy ha állítasz valamit, akkor annak logikai következményeit is állítod.
    Mutasd a teljes hozzászólást!
  • "Mutass csak egyetlen Bsc/Msc-n oktatott tárgyat, melynek a tananyagához nem lehet tankönyvet/szakirodalmat találni. Amennyiben lehet, akkor azok önerőből feldolgozhatóak."

    Lehet tankönyvet találni, nem állítottam az ellenkezőjét. Azt sem vitatom, hogy önerőből feldolgozhatók. De az állítás az volt, hogy "a CC + öntanulás ugyanoda eljuttathat, mint egy egyetem". Itt tehát a könyvek hozzáférhetősége csak egy kis részlet. Egy egyetemi oktatást kellene figyelembe venni, minden körülményével, eseményével és következményével, szemben a CC és/vagy az öntanuláséval. Meg ugye akkor a CC is minek van, hiszen az összes anyag netes tutorialból/docból is elérhető. Sőt, az általános iskola is minek van. Most vagy fölösleges az összes oktatási forma, vagy ugye nem csak azon múlik, hogy egy oktatási forma anyagai mennyire hozzáférhetők. (Vagy akár szerinted tömegesen hülyék a szülők, amikor korrepetálni viszik a gyereket, ahelyett, hogy hát ott a tankönyv, tanulja meg a gyerek és kész.)

    "Jelen esetben Junior szoftverfejlesztői állásról van szó, mint célról. Oda pedig szerintem egyértelműen eljuttathat a CC + öntanulás."

    Egyetértek.

    "Egy Junior szoftverfejlesztői álláshoz nem kell se ergonómia, se FizikaIII, se anyagismeret, stb."

    Még akár ezzel is egyetértek.

    De. Az állítás nem ezek voltak, hanem ez: "a CC + öntanulás ugyanoda eljuttathat, mint egy egyetem".

    "Az egyetemi papírnak nagyobb értéke van a piacon és nagyobb a feltételezhetően ismert háttértudás egy egyetemet végzett illető esetén, de ennyi."

    Még ezzel is egyet tudok érteni.
    Mutasd a teljes hozzászólást!
  • Oh thx! :D Már azt hittem, hogy megint egy uj tekkknologia roviditese, amirol f1ngom nincs, de akkor ez egy iskola/kepzes neve.

    Akkor most mehet tovabb a 3. VH :D 
    Mutasd a teljes hozzászólást!
  • A codecool nevű programozó suli. OP kérdezett róla, én ide járok, így leírtam a tapasztalataimat, majd megjelent pár egyetemellenes user, meg pár olyan, aki minden gyakorlatorientált képzést lenéz és kitört a harmadik világháború...
    Mutasd a teljes hozzászólást!
  • Mi a rák az a CC? Visszalapoztam 3 oldalt ebben a végtelen topicban, de felidegesit, hogy nem lelem a választ o.O

    dubitoergosum: nem neked szegezem a kerdest, csak elvitte a cica az [új hozzászólás a semmibe] gombot a lap aljáról... :D
    Mutasd a teljes hozzászólást!
  • Most komolyan úgy akarsz vitatkozni, hogy minden egyes feltételezést alá kell támasztanom, amíg el nem jutunk az axiómákig és minden egyes fogalmat definiálnom kell? Ezt jobb helyeken bizonyításnak hívják. Én bevallom, hogy ilyen komplexitású kérdés kimenetelét nem tudom teljes biztonsággal megjósolni.
    De tudod mit? Neked biztosan menni fog. Bizonyítsd hát be tényekkel, hogy amit feltételezek az lehetetlen, vagy legalábbis statisztikailag esélytelen. Vagy pedig egyszerűen fogadd el, hogy nem az.
    Mutasd a teljes hozzászólást!
  • Én így szoktam társasozni és teljesen jól megy. Teljesen mindegy, hogy aki nekem továbbadja a szabályokat, az milyen módon tanulta meg őket, ha tudja. A lényeg, hogy nekem személyesen nincs szükségem a játék elkezdése előtt minden bemagolni. Ha olyan eset fordul elő, hogy nem egyértelmű, mit kell csinálni, akkor elolvasom én is. Ha pedig olyan játékot játszunk, amit senki nem ismer, akkor nyilván először átfutjuk a játékmenetet és a szabályokat.
    Mutasd a teljes hozzászólást!
Tetszett amit olvastál? Szeretnél a jövőben is értesülni a hasonló érdekességekről?
abcd