Elképesztő mértékben nő a kód nélküli programozás használata

Elképesztő mértékben nő a kód nélküli programozás használata
2022-10-07T08:09:46+02:00
2022-11-13T19:06:20+01:00
2022-11-13T19:25:31+01:00
  • azért a wordpress nem webshop motornak készült, arra ott van a prestashop és hasonló vacak.
    Mutasd a teljes hozzászólást!
  • És az agilitástól könnyen eljutunk a kód nélküli programozáshoz, ami azt jelenti hogy olyan programot írunk, amivel mások úgy érezhetik hogy ők készítik/tervezik meg a programot. De valójában ez is csak a mi munkánkat könyíti majd meg, és nem tesz pótolhatatlanná. A munkánk nagy része most is abból áll, hogy config vagy leíró fileokat készítünk és szerkesztünk. Van úgy hogy hetekig egy pár sor kódot írok.

    Az elején páran lenézték a wordpress "szerkesztőket", de biztos vagyok benne hogy senki sem próbált mondjuk egy webshopot összerakni benne. Mert ha igen, akkor nagyon hamar rájött, hogy ez nem annyira egyszerű történet. Az ügyfél első pár kérése után összeomlanánk, hogy hogy a p..ba lehet abba a sz..rba bármit kicsit módosítani. Aztán lehet hogy nem is kell semmit módosítani, csak egy másik config filet kell letölteni és átszerkeszteni. Na de akinek fogalma sincs hogy ezt kell csinálni? Sokan az Excelt nem tudják használni. A feleségem jobban keres az Excel tudásával, mint én programozóként. Annyira nem triviális az Excel használata sem, kell hogy értsen hozzá az, aki azt használja. Aki csak a szumma gombot ismeri mint én, meg színezni tud vele, nem ért hozzá. A főnököm például Excelben tervezte/rajzolta meg a számítógép hálózatot, a házát, a  házának butorzatát, sorolhatnám hogy még milyen extrém dolgokat tud vele csinálni. Szakemberre mindig szükség lesz, csak a feladata, a munkavégzés menete változik. Majd amikor egy robotnak mondom meg hogy mit csináljon, még akkor is, addig amíg én mondom meg hogy mit csináljon, nélkülözhetetlen vagyok.
    Mutasd a teljes hozzászólást!
  • Érdekes lett volna, ha sikerül leírni legalább egyet. Mondhatni merész vállalkozás. De hát Scott is meghalt mielőtt elérte a Déli-sarkot.
    Mutasd a teljes hozzászólást!
  • A végén rámondják az áment az nem az agilitással van összefüggésben, nem is írta ezt senki. Én csak arra reflektáltam, hogy manapság a megtervezünk előre valamit és azt fejlesztjük (vízesés) módszer már idejét múlt, ettől agilisebben kell dolgozni ma már, ahol legfeljebb adott sprintre megbeszélt dolgok vannak szigorúan megtervezve, de még ez se ennyire vaskalapos szabály.
    Mutasd a teljes hozzászólást!
  • Hali!

    Szerintem nem egyenlő, de neked – ezek szerint – a szövegértéssel/-értelmezéssel is problémáid vannak, nem csak az agilis módszertanokkal. Nekem tutira nincs több kérdésem (mondjuk, nem is volt).

    Mutasd a teljes hozzászólást!
  • Szóval szerinted az, hogy

    majd a végén egy architect rámondja legfeljebb az áment és ennyi

    egyenlő az agilis módszertanok összességével?
    Azt hiszem nincs több kérdésem...
    Mutasd a teljes hozzászólást!
  • Hali!

    ez sok mindenre magyarázattal szolgál

    Arra biztosan, hogy fogalmad sincs az agilis (fejlesztési) módszertan(ok)ról.

    Mutasd a teljes hozzászólást!
  • ez sok mindenre magyarázattal szolgál ))
    Mutasd a teljes hozzászólást!
  • meggondolt és jóváhagyott terv szerint mennek a dolgok

    Ezen már 20 éve túl vagyunk. Manapság, ami megfontolt az legfeljebb az adott sprint, de mág az se biztos.
    Mutasd a teljes hozzászólást!
  • Azért az régen rossz, ha az architect a végén mond rá valamit, nem pedig egy megfontolt-meggondolt és jóváhagyott terv szerint mennek a dolgok. Ezek az alkalmazások
    lesznek aztán rugalmasan paraméterezhetők ott, ahol senki nem várja el tőlük, ellenben merevek és fejlesztői részről hisztérikus szemforgatásba menően rugalmatlanok ott, ahol a felhasználó szeretne valami változást eszközölni 
    Mutasd a teljes hozzászólást!
  • Na igen, ha van egy saját rendszered, akkor ahhoz jó eséllyel találsz embert vagy alvállalkozót, akik a még szükséges fejlesztéseket elvégezzék, nem vagy kiszolgáltatva a low-code-ot gyártó cég kedvének és alkalmazkodóképességének. Ideális esetben persze a gyártó cég (vagy partnerei) rögtön ugrik és szolgálja is ki a te spéci igényeidet, de hát olyan sosincs, hogy épp minden ideális legyen...
    Mutasd a teljes hozzászólást!
  • A végén úgyis átellenőrzi az eredményt a mérnök és megteszi, ha kell a kellő változtatásokat, de a mai eszközök mellett lehet már erre sincs szükség. A lényeg, hogy a munka nagy részét nem ő végzi, hanem akár egy technikus, vagy manapság egy teljesen laikus ember. A méretezési és egyéb dolgokat úgyis a program kalkulálja ki, ezt csak legfeljebb ellenőrizni kell, ha mondjuk péncélszekrényt rak az emeletre, akkor ott megkettőzi a gerendát és így tovább. Ezek simán automatizálható dolgok voltak már ezelőtt 30 éve is, amikor még én is technikus voltam.
    Mutasd a teljes hozzászólást!
  • "miért ne tervezhetne új eszközökkel akár a raktáros is."

    Azért nem tervezhet, mert rossz lesz az eredmény. Egy családi ház tervezésénél nagyon sok szempontot figyelembe kell venni: lépcső méretezése, vizesblokkok, támfalak, közlekedők, helyi sajátosságok, stb...

    Jó a hasonlatod, egy raktáros meg tud tervezni egy belső teret az Ikea összekattintgatós cuccával. Ha expert user, akkor a Sweet home 3D-vel.
    Mutasd a teljes hozzászólást!
  • Tervezni régen (90-es évek) is tervezhettett a technikus is (sőt voltak katalógusok is komplett házterv sablonokkal és csak módosítani kellett sok esetben) ma nem tudom hogy ez hogy van, de elvben miért ne tervezhetne új eszközökkel akár a raktáros is. Persze engedélyeztetni, statikát ellenőrizni stb. a mérnöknek kell a végén, de a munka nagy részéhez nem ő kellett régen se.

    Fejlesztésnél is kb ugyanez lesz. Fejleszteni bárki fejleszthet, nem kell hozzá mérnöknek lenni, majd a végén egy architect rámondja legfeljebb az áment és ennyi, de itt még ennyi se kell.
    Mutasd a teljes hozzászólást!
  • Példaként a tervezést hoznám.
    A tervrajzkészítésben hatalmas lépések történtek a papírra rajzolás óta.
    A CAD nagy lépést tett a komponensekből építéssel, ilyesmi a no-code megközelítés is a grafikus felületen összekattintgatással.
    De valahogy a mérnökök helyett máig nem a raktárosok tervezik a raktárakat, még CAD segítséggel sem. Meg nem orvosok a klinikákat.
    Ez nagyon párhuzamos világ szerintem (bár nyugatabbra szeretik az IT-s fejlesztőt is mérnöknek tekinteni, itthon még nem érzem)
    Mutasd a teljes hozzászólást!
  • A low code olyan problémák esetén nyújt segítséget, amiket már jól megértettünk, és képesek is vagyunk olyan flowt biztosítani a megoldásukra, amiket valóban könnyen tud használni akár egy programozásban nem jártas ember is.

    Ez a low code dolog (mint, ahogy sok minden más is az IT világában) nem új keletű egyébként, bizonyos időközönként mindig új erőre kap, hogy na majd most jól le lesznek cserélve a programozók ezek miatt.

    A legnagyobb hibájuk a tesztelhetetlenségük és az, hogy nem hagynak túl sok mozgásteret a valódi programozóknak, ha olyan igény merül fel, aminek lekezelésére nem képesek ezek a rendszerek.

    Vettem már részt nem egy olyan projektben, aminél a vállalat pont az ilyen merev, low-code szoftvermegoldásokat próbálta kibővíteni, és a vége az lett, hogy egy idő után kivezették teljesen, és saját kódon futtaták a bizniszüket.

    Szóval azért még ne rohanjon mindenki az egyetemre, vagy a szakmunkásképzőbe én azt javaslom. :)
    Mutasd a teljes hozzászólást!
  • Csak annyit mondtam, hogy az általam ismert Nagy Rendszerek korántsem tűntek igazán jól összerakottnak és kellően rugalmasnak, vagy ha igen, akkor nem a programozásukkal, hanem a szakszerű paraméterezésükkel és a hozzáfejlesztésekkel megy el rengetek idő. Vagy csak simán blöffölnek amikor eladják őket és nem is teljesítik az ígéreteiket.
    Azt mondom, hogy a WP egy agyonsztárolt valami, miközben a funkcióinak nagy része csak az erőforrásokat zabálja (illetve a hibalehetőségeket szaporítja), és az alapfícsöröket minden magára kicsit is adó webes nagyjából két hét alatt össze tudná rakni.
    Azt mondom, hogy a SAP-ot nem ismerem, csak innen-onnan hallom, hogy a kezdeti nagy ígéretek és a bevezetés után a kisebb cégek gúzsba kötött kézzel ülnek, sem váltani, sem fejlődni nem tudnak, mert túl kicsik, túl egyediek, túl nem érdekesek az SAP-nek, miután már eladták nekik a lelküket.
    (Ugyanez kicsiben: Ombrello Digital saját CMS csodarendszere, eladják egy portál alá, hogy az aztán mindenre IS jó lesz, de semmiféle további fejlesztési igényt nem szolgálnak ki, mert az nem eléggé általános és ezért az nekik zsákutca, nem kérnek belőle.)
    Azt mondom, hogy láttam olyan "összekattintós" vállalatirányítási rendszert, amihez az "utaskísérői" és "pilótavizsgát" a fejlesztő cég aranyáron méri, ami szintén felvet némi kérdéseket az általuk kifejlesztett megoldást illetően.
    Egy szóval nem mondtam, hogy nem lehet ezt jól csinálni, csak azt, hogy nem nagyon csinálják jól.
    Ehhez képest neked annyi ellenérved van, hogy hülyeségeket írok és elrobogott az idő mellettem, hát kösz
    Mutasd a teljes hozzászólást!
  • Huhhh, hát teljesen univerzális eszköz gondolom nem létezik, csak maximum egy CRM vagy ERP vagy más hasonló dolgot összerakó valami, ami kb. úgy működik, hogy a Nagy Közös Okosságból a hozzáértő szakik kimazsolázzák a már létező, illetve hozzáillesztik/lefejlesztik a még nem létező dolgokat.
    Mutasd a teljes hozzászólást!
  • Sziasztok!

    Kipróbánék ilyen platformot, de nem tudom melyik lenne jó. Ingyenes verzió van ilyenből? Valakinek tapasztalata, hogy melyik ingyenes és jól használható? Teljesen kezdőként vágnék bele, ilyennel még nem találkoztam. 

    Köszönöm!
    Mutasd a teljes hozzászólást!
  • Mi itt mind filozofálhatunk a "nagy rendszerek" elvi síkjairól, a puding próbája az evés, és sem a SAP, sem a WP pont nem jó példa arra, hogy "programozói tudás nélkül" csak úgy összekattingatunk valamit és az egy valóban jó, további support és fejfájás nélküli produktum lesz. 

    Ha egy hülyeséget többször leírnak, attól ugyanaz a hülyeség marad. Ezzel csak azt lehet nyilvánvalóvá tenni, hogy megszállottan ragaszkodik valaki a hülyeséghez. A világ megközben elszalad mellette. Illetve igazából már rég elszaladt, azért ragaszkodik görcsösen a régi, de már rég el is avult dolgokhoz, koncepciókhoz, "igazságokhoz".

    Ok, nem "programozók", hanem hasonló tudású "összekattingatók" meg üzemeltetők kellenek, de akkor végül is mit nyerünk az egészen? 

    Nem, nem hasonló tudásúak kellenek. Egy WP és egy SAP használatához sem kell tudni programozni. Sőt, még a valódi programozóknak sem ugyanazt kell tudniuk, mint 10-20-30 évvel ezelőtt. Ma már az átlagprogramozónak semmit nem kell tudnia pl. I/O portokról, megszakításokról, memórialapozásról, regiszterekről, stb. - függetlenül attól, hogy továbbra is azok működnek a dolgok mélyén. Viszont sokkal többet kell tudnia UI tervezésről és a UX-ről, sokkal többet kell tudni elosztott rendszerekről, hálózati koncepciókról, skálázódási megfontolásokról.

    De azokról sem mélységében: nem kell tudnia hogyan működik a képernyőre rajzolás, hogyan működik az egér, hogyan működik az érintőképernyő, nem kell tudnia protokollcsomagot értelmeznie, nem kell még azt sem tudnia, hogy a műveletek a processzor vagy az operációs rendszer szintjén hogyan kerülnek párhuzamosításra. Még rendezési algoritmusokat sem kell tudnia, mert az adatbáziskezelő vagy a keretrendszer rendez helyette. Nem a működés módját, hanem csak hatásait és sajátosságait kell ismernie és értenie, és azt, hogy melyiket hogyan és melyik eszközzel lehet hatékonyan kezelni, kihasználni, megvalósítani.

    Az meg, hogy összekattingatják -e a programokat, vagy szöveggel írják, szintén teljesen irreleváns. Nem ez határozza meg a végeredmény minőségét. Attól egyetlen program sem lesz jobb, hogy sok kódot kell írni hozzá, és attól sem rosszabb, hogy a létrehozására szolgáló eszköz intenzíven épít az egér használatára is.

    Az új sem rosszabb, és a régi sem feltétlenül jobb. Ilyesmivel az áltatja magát, aki mellett elszaladt a világ, és nem hajlandó tudomást venni róla.
    Mutasd a teljes hozzászólást!
  • Mi itt mind filozofálhatunk a "nagy rendszerek" elvi síkjairól, a puding próbája az evés, és sem a SAP, sem a WP pont nem jó példa arra, hogy "programozói tudás nélkül" csak úgy összekattingatunk valamit és az egy valóban jó, további support és fejfájás nélküli produktum lesz. Ok, nem "programozók", hanem hasonló tudású "összekattingatók" meg üzemeltetők kellenek, de akkor végül is mit nyerünk az egészen? Nyilván elveszítjük a célszerszám adott feladatra kihegyezett tudását és gyorsaságát, cserébe meg nyerünk valamennyi rugalmasságot, és persze időt is, bár a múltkori egyik példám szerint még azt sem mindig...
    Hogy mennyire nem a levegőbe beszélek, konkrétan Őket is ismerem: CyCortex: #1 Vállalatirányítási rendszer Excel-káosz ellen
    Egy valóban nagyon profi és jó rendszert alkottak, de nyilván adott alkalmazásban az adatbázis szerkezete és felépítése rettentően távol áll az ideálistól, tehát sebességben máris veszítünk jó sokat. Ergonómiában szintén nem állnak valami túl jól, mert pl. a sokadik termékszinten kedvezménycsomagokat összerakni és azt napi szinten használni távolról sem leányálom, de nyilván valamit valamiért. Cserébe pár nap alatt egész jó kis raktárnyilvántartót lehet vele alkotni, de most jön a nagy pofon: CyCortex: #1 Vállalatirányítási rendszer Excel-káosz ellen
    Különösen a Tanfolyamok része a mellbevágó, vagyis felhasználóként és óránként 15-25ezer forintért szívhatod magadba a tudást, az admin és a fejlesztői részről meg ugye jobb nem is beszélni...
    Mutasd a teljes hozzászólást!
  • SAP-os környéken is dolgozok és külön 20-30 ember foglalkozik az egyedi, helyi igények kielégítésével.

    Igen, pontosan ezt mondtam. Hogy egy csomó ember dolgozik rajta, csak éppen ők nem programozzák a SAP-ot, hanem támogatják, adminisztrálják és maximum lekérdezéseket, jelentéseket írnak hozzá. Azokra az emberekre pedig, akik az egyedi, helyi igényekhez illesztéssel és valóban a SAP programozásával foglalkoznak, nem állandóan van szükség, hanem a bevezetéskor pár hétre, esetleg hónapra. Meg utána alkalmilag, ha jelentősen változnak a folyamatok.

    Csak ugye ha valakinek nulla a szövegértése, meg még 2022-ben is M$-nak írja a Microsoftot....

    Ennyit a nagy rendszerek általánosságáról.

    Ha történetesen nem lennének általánosságban igazak a leírtak a SAP-ra, még az se mondana általánosságban semmit a nagy rendszerek általánosságáról. Amihez képest az, hogy a te személyes példád sem mond semmit általánosságban még a SAP általánosságáról sem, már csak ráadás.

    Csak ha ugye valaki a halmazelmélet alapjaival sincs tisztában, és még 2022-ben is M$-nak írja a Microsoftot...
    Mutasd a teljes hozzászólást!
  • Te aztán mindenhez IS értesz! ;-(

    Dolgoztál már élesben?

    SAP-os környéken is dolgozok és külön 20-30 ember foglalkozik az egyedi, helyi igények kielégítésével.

    Ennyit a nagy rendszerek általánosságáról.
    Mutasd a teljes hozzászólást!
  • Úgy, ahogy programozó + rendszergazda = devops, itt meg a "programozó" + tesztelő = nevezzük akkor fejlesztőnek, ha így jobban tetszik.

    Ez azért nem így van. :)
    A devops a fejlesztői infrastruktúrát tervezi/implementálja/tartja karban, nem egy rendszergazda, aki belenyúl a termékbe.

    A tesztelő + programozó meg hát... tényleg ír teszteket a fejlesztő, de nem attól lesz valaki tesztelő, hogy teszteket ír és futtat.
    Mutasd a teljes hozzászólást!
  • Nem elírás. Tesztelők alatt azokat értem, akik napi 8-10 órában ott ülnek alkalmazottként és végignyomogatják az egyes teszt eseteket manuálisan újra és újra, hibákat keresnek, illetve újjaban már gyakorlatilag ők is javítják azokat vizuális eszközökkel és akár tovább is fejlesztik. 

    Nem. A tesztelő az tesztel. A tesztelő bele sem nyúlhat a játék működésébe, semmilyen szinten. Ennek nem csak az az oka, hogy nem is ismeri azt, és nincs meg a szakértelme hozzá, de az  is, hogy az a tesztelő, amelyik tudja hogyan van belsőleg "lekódolva" a program, az sokkal rosszabb tesztelő, mint az, amelyik nem tudja ezt.

    Mert ő eleve nem azzal a szemmel néz az egészre, nem azok az elvárásai, és nem úgy viselkedik a játékkal, mint a majdani, a játék belső működéséről aztán tényleg semmit, de semmit nem tudó játékos fogja ezeket csinálni. Márpedig a tesztelés célja az, hogy azokba a problémákba és bugokba, amikbe utóbbiak (ti. a majdani játékosok) is belefuthatnának, már ő fusson bele, és így azok javításra, korrigálásra, finomításra kerülhessenek még kiadás előtt.

     Lehet, hogy őket "fejlesztőnek" hívják hivatalosan

    Nem. A fejlesztőket hívják fejlesztőnek, a tesztelőket meg tesztelőnek.

    itt meg a "programozó" + tesztelő = nevezzük akkor fejlesztőnek

    Ilyen a nagy játékoknál nincs. Akkor van ha egyedül ír valaki valamit, vagy maximum pár emberrel közösen. De már akkor se nagyon, illetve akkor is érdemes a fent említett okoknál fogva a tesztelés derekát kvázi laikus tesztelőkre bízni, akik semmit sem tudnak arról, hogy a játék belül hogyan működik, még annyira sem, mint annak úgymond fejlesztői, akik a korábban leírtak értelmében szintén inkább laikusok, mint programozók (abban az értelemben, hogy nem C vagy egyéb generikus nyelvű kódot írnak, illetve idejük >95-99+%-át mással töltik).


    A fentiek egyébként játékokon kívül kb. minden más szoftverre is igazak, csak a játékok tipikusan azok, amiknél a tipikusan legkevesebb alapfeltételezéssel lehet élni azt illetően, hogy a majdani felhasználók milyen háttérismeretekkel rendelkeznek a használat módját illetően. Részben azért, mert minden játék ad hoc szabályok alapján működik, részben azért, mert a játékokkal 3 évestől 99 éves korig, a 8 általánosos betanított munkástól a Nobel-díjas professzorig mindenki játszhat, illetve játszik is majd. Szemben a célprogramokkal, amik használói köre általában szűkebb és tájékozottabb az adott alkalmazási területet illetően.
    Mutasd a teljes hozzászólást!
  • A bölcsészetet ajánlanám. Az átképzési trendeket figyelve lassan hiány lesz a szakmában. :)
    Mutasd a teljes hozzászólást!
  • Akkor most vége a szakmánknak, vagy van még remény? Mire képezzük át magunkat?
    Mutasd a teljes hozzászólást!
  • Játékfejlesztő cégnél még nem dolgoztam, de nagyon meglepnek, amiket írsz.

    Nagyobb cégeknél a fejlesztők és a tesztelők még földrajzilag is különválnak. (A tesztelők is ált. mérnökök, csak teljesen más skillset kell, mint a fejlesztőknek.) Nyilván a fejlesztők is írnak teszteket, de azok inkább unit vagy komponenstesztek, minél több komponenst érint a teszt, annál inkább megy át a tesztelőkhöz.

    jatekoknal pedig, ahol meg ehhez programozonak se kell lenni illetve automatikus teszteles gyakorlatilag nem letezik

    Fontos a manuális tesztelés, ami a felhasználók szemszögéből tesztel, de biztos lehetsz benne, hogy a különböző szinteken sok az automatizált teszt. Gondolj bele mi lenne, ha minden nahyobb patch után újra végig kellene játszani mondjuk egy Skyrim-et 50-szer.

    A No Man Sky-ról például cikkeztek is, hogy "virtuális szondákkal" tesztelik automatizáltan a virtuális világot.
    Mutasd a teljes hozzászólást!
  • Nem tesztelők (azt szerintem véletlenül írta el),

    Nem elírás. Tesztelők alatt azokat értem, akik napi 8-10 órában ott ülnek alkalmazottként és végignyomogatják az egyes teszt eseteket manuálisan újra és újra, hibákat keresnek, illetve újjaban már gyakorlatilag ők is javítják azokat vizuális eszközökkel és akár tovább is fejlesztik. Lehet, hogy őket "fejlesztőnek" hívják hivatalosan, de a lényeg, hogy ez már rég nem azt jelenti, hogy valaki leül és C kódot gépelget egy editorba, hanem teljesen mást. Úgy, ahogy programozó + rendszergazda = devops, itt meg a "programozó" + tesztelő = nevezzük akkor fejlesztőnek, ha így jobban tetszik.
    Mutasd a teljes hozzászólást!
  • AAA szintu jatekoknal mar kenytelenek bizonyos reszeket megirni koddal, illetve ritka esetben magat a motort is. (Lasd EA Games)

    Az pedig hogy manualis tesztelok mennek fejleszto iranyba nem ritka uzleti alkalmazasoknal sem (sot jobb helyeken a TDD, BDD teszteket is a manualis tesztelok irjak meg), jatekoknal pedig, ahol meg ehhez programozonak se kell lenni illetve automatikus teszteles gyakorlatilag nem letezik meg gyakoribb. Es ki tudna jobban es gyorsabban javitani mondjuk a bugokat, esetleg uj featurekat betenni, mint aki teszteli is a programot. Ez koltseghatekony modszer is, illetve csak osszekotnek ket amugy is osszetartozo munkafolyamatot.
    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