ChatGPT-vel komolan fejlesztenek emberek?

Fejlesztés

Röviden.

Symfony 7-ben írok egy rendszert. A miérteket hagyjuk, de kénytelen vagyok custom route loadert írni alá a doksik alapján.

Adatbázisból szedem ki az url-eket, több nyelven és onnan töltöm fel dinamikusan.

Nagyon sok doksit átolvastam, átnéztem fórumokat. Nem jöttem rá hogy kéne felvinni több routingot egy name alatt több nyelven.

Tehát ha pl twig-ben azt mondom, hogy {{ path('homepage') }} akkor irányítson át az aktuális nyelv alapján a megfelelő oldalra, pl /hu/fooldal vagy /en/homepage

Attribute-k segítségével ez elvileg megoldható a controllerek alatt, de itt nem jöttem rá hogy lehetne, a doksik alapján se.

Persze megoldható, hogy suffix-al a  route name mögé beteszem a locale-t, pl homepage_hu, homepage_en, stb, aztán twig-ben a path mögé mindig befűzöm a locale-t, vagy írok rá egy twig function a path helyett.

 

Gondoltam nézzük meg az AI-t, mit mond. 2-3 kérdés után eljutottam oda, hogy adott megfelelő példakódokat. Az alapján csak simán adjam hozzá újra és újra a Route-kat, különböző locale paraméterekkel. Persze próbáltam már, de megnéztem úgy is ahogy ő írta. Hát nem működött. Nyilván.

Mondom neki, ez nem megy, felülírják egymást az azonos name-k. Erre visszaírja,  hogy jaaa, ha felülírja, akkor tegyem mögé sufffix-ban a locale-t, bla-bla. Azt a végén ugyanazt találta ki ami már nekem is eszembejutott.

Szóval, többen is írtuk már, hogy kb találgat az AI, próbálkozik. Azt nem értem, hogy valóban emberek fejlesztenek vele? Vagy ezt csak a kezdők használják? Hisz végül is ha azt nézzük ugyanúgy eljutottam ugyanarra a pontra simán google-zással is.

Persze nála gyorsabban megvoltak a válaszok, csak épp döntsem el, hogy most mikor "kamuzik". Nála csak egy állítást látok, viszont ha stacko-n találok egy választ amit 100-an értékeltek, akkkor az közel 100%-os biztosság. Ugyanígy a doksiban olvasva szintén többet ér mint egy benyomott AI komment.

A megfelelő kérdésekkel sincs baj, hisz kb 3 kérdés után megvolt a válasz.

Szóval én azt hiszem maradok a doksiknál és a google kereséseknél.

  • 2167 megtekintés

( plt | 2024. 05. 17., p – 17:53 )

Az "intelligens mosópor" megvolt? A ChatGTP csak egy nyelvi modell.

( bzt | 2024. 05. 17., p – 18:05 )

Szerkesztve: 2024. 05. 17., p – 18:20

Tehát ha pl twig-ben azt mondom, hogy {{ path('homepage') }} akkor irányítson át az aktuális nyelv alapján a megfelelő oldalra, pl /hu/fooldal vagy /en/homepage

Ezt miért nem inkább egy HTTP rewrite-al oldod meg? Nem terhelné se az adatbázisszervert, se a szkriptfuttatás a webszervert minden egyes oldalbetöltésnél.

Csak egy helyben futtatott szkript kell, ami kiolvassa az adatbázisból az URL-eket és legyárt hozzá egy, a webszereverdnek megfelelő HTTP rewrite konfig fájlt, amit meg beinclude-olsz a webszervered konfigjába. Ezt a szkriptet csak akkor futtatod le, ha új URL születik, egyébként nem (a te route megoldásod minden egyes oldallekérést terhelné).

Apachenál RewriteRule, nginx-nél simán rewrite és lighttpd-nél is rewrite, stb. Nem tudom, hogy a nyelvet konkrétan honnan veszed, de mindegyik tud HTTP header-re, browser-re, query-re vagy cookie-ra is match-elni.

Pl. nginx alatt valami ilyesmi kell (feltéve, hogy a nyelvkód sütiből jön):

if ($http_cookie ~* "lang=en") {
  rewrite ^/homepage$ /en/homepage
  rewrite ^/about& /en/about
    ...
}
if ($http_cookie ~* "lang=hu") {
  rewrite ^/homepage$ /hu/fooldal
  rewrite ^/about& /hu/rolunk
    ...
}

Ha angolnál csak elé akarod rakni, hogy "en", akkor oda elég egyetlen sor is, 

rewrite ^(.*)$ /en/$1

Magához a honlap kódjához hozzá sem kell nyúlni, a Symfony 7 routing marad, ami volt, csak a nyelvspecifikus URL-ek kellenek bele, semmi más.

Egyrészt ha frameworköt használok, akkor ragaszkodom hozzá, hogy úgy menjen minden ahogy ott kitalálták, a doksi szerint.

Semmiképp sem lenne előnyös egy meglévő url-t elfedni egy új-al. Amikor php-ból akarsz url-t generálni, akkor se a konkrét url megadádával teszed, hanem csak egy kódnevet adsz át neki. A háttérben ő pedig előbányássza az url-t. Így az url-t bármikor megváltoztathatom, a kódban nem kell a template-k alatt átírni.

Ez így jó is, ez így van kitalálva. Persze így dolgozik a php is, de van cache.

az pedig nem utolsó szempont, hogy egy htaccess-t problémás admin felületre kivezetni. Nálam az a lényeg, hogy adminban át lehet írni az url-ejket, bármelyik nyelven.

Nem értettél meg.

Amikor php-ból akarsz url-t generálni, akkor se a konkrét url megadádával teszed, hanem csak egy kódnevet adsz át neki.

Ugyanúgy php-ból generálod ugyanazzal a framework hívással az URL-eket itt is, csak route helyett webszerver konfig fájlt csinálsz belőlük kimenetnek.

A háttérben ő pedig előbányássza az url-t.

Pontosan ugyan úgy itt is. A különbség csupán annyi, hogy nem minden egyes oldalbetöltést terhelsz az előbányászással, hanem csupán csak akkor futtatod le, amikor változtatsz valamelyik URL-en.
A php által az adatbázisból előbányászott URL kerül a a rewrite konfigfájlba (tekintsd úgy, mintha ez egy routing cache lenne). Ha az adatbázis változik, újra lefuttatod és frissül a "cache".

egy htaccess-t problémás admin felületre kivezetni

Nem kell hozzá semmiféle külön admin, mehet akár egy hook-ból is, automatikusan, a már meglévő admin felületről hívva. Vagy mehet akár függetlenül cron-ból is éppen, az már tökmindegy, a lényeg, hogy nincs szükség külön adminfelületre hozzá, hisz ez a szkript pontosan ugyanazzal az interfésszel bányássza elő az URL-eket, ahogy egyébként is tennéd.

Mégegyszer, minden ugyanaz, annyi csak a különbség, hogy a nyelvfüggetlen URL-eket a rewrite konfigba írod, a nyelvfüggő URL-eket meg hagyod, hadd menjenek a szokásos Symfony 7 route szerint.
(Mivel a rewrite már a HTTP kérésben lecseréli az URL-t, ezért az sem probléma, ha a nyelvfüggetlen URL-ek is bennmaradnak a Symfony 7 routingjában, senkit nem fognak zavarni.)

Nem jöttem rá hogy kéne felvinni több routingot egy name alatt több nyelven.

Fordítva ülsz a lovon. Felveszel egy oldalt, mondjuk "/hu/fooldal" routinggal, egy másikat pedig "/en/homepage" routinggal. Mindkettőnek megadod ugyanazt az aliast ("homepage"). Szóval nem egy oldalhoz veszel fel több routingot, hanem minden routing külön oldal.

Nyugi, ismerem a rewrite-t. 10+ éve is használtam.

Ha nem lenne nyelvi routing, csak semleges egységes, akkor is be kell töltenie egyszer azt is. Nem nyersz vele komolyabb erőforrást. ezzel csak bonyolítanád a rendszert.

Ugyanúgy betöltődnek az url-ek a framework alól, csak nem  nyelvi verziók, hanem az amit te rewrite-val töltenél be.

Az admin felület alatt arra gondoltam, hogy ott szerkesztik alapból az url-eket és fordítják le.

Értem, hogy mit akarsz mondani, de fejlesztés oldalról ez a megoldás nem valid. Ha frameworkben dolgozol, akkor nem írunk fölé custom megoldásokat, max akkor ha azt az igényt nem lehet megoldani benne. Viszont ha valami általános igényre nincs benne megoldás, akkor az azt jelenti, hogy az a framework szar.

 

Nem azért nem fejlesztel fölé egyedi dolgokat mert nem  tudom megoldani, hanem mondhatni ez egy irányelv. Így lesz a kód egységesebb. Ha egy másik fejlesztő belenézne a kódomba és meg akarná érteni, akkor az említett részben a routingolást kell kidoskiznia és már értené is. Ha adatbázis lekérdezéseket szeretné megérteni, akkor megnézi a doctrine doksijait és megy is. Így olyan termék lesz a végeredmény amibe könnyebb fejleszteni, könnyebb megérteni.

Mondom én, nem érted, hogy mit mondok.

Ha nem lenne nyelvi routing, csak semleges egységes, akkor is be kell töltenie egyszer azt is.

Hát ez az, de csak kellene az a nyelvi routing, amit ezidáig nem is tudtál máshogy megoldani (és nem is fogsz tudni, csak durva gányolás árán, mert alapból nem tud több route-ot).

Ugyanúgy betöltődnek az url-ek a framework alól, csak nem nyelvi verziók, hanem az amit te rewrite-val töltenél be.

Na de pont azt mondom, hogy rewrite-al dobd át a nyelvi verzióra. Ekkor a framework-nek már csak egyetlen egyszer kell betöltenie a routing-ot, és azt is már csak a nyelvkódos URL-hez, tehát egy route kell csak egy oldalhoz. Pont ez a lényeg, nem kell szétbarmolni hozzá a már meglévő Symfony routingot, azzal is működik.

Az admin felület alatt arra gondoltam, hogy ott szerkesztik alapból az url-eket és fordítják le.

Na, erre nincs semmi szükséged. A már meglévő URL szerkesztőt használod, nincs külön felület. Lekéred a már meglévő routing táblát az adatbázisból, kiegészítve az oldal nyelvfüggetlen alias-ával, végére biggyeszted, hogy "GROUP BY lang" és ennyi. Ezt írod a rewrite fájlba, match-nek az alias-t, célnak meg az URL-t. Az oldalhoz az alias-t bárhogy felveheted, bármilyen adatbázismezőben tárolhatod, nem kell belenyúlni a Symfony routingjába. Ha akarod, tárolhatod akár a routing táblában is nyelvkód nélkül, vagy sima oldal paraméterként, teljesen tök mindegy, a lényeg, hogy a Symfonyt nem kell átírnod hozzá.

Ha frameworkben dolgozol, akkor nem írunk fölé custom megoldásokat

Sosem beszéltem custom megoldásról! Pont azt mondom, hogy a Symfony 7 routing tábláját használod, épp csak előre kigenerálsz belőle egy rewrite-os "cache"-t, ami megoldja neked a nyelvek szerinti átpasszolást, hogy továbbra is elég legyen az egy route egy oldalhoz.

Ha egy másik fejlesztő belenézne a kódomba és meg akarná érteni,

Nem hiszem, hogy bármelyik másik fejlesztő boldog lenne, ha azt látná, hogy belebarmoltál a Symfony 7 framework alapértelmezett routingjába átírva a vanilla php kódot... Vagy hogy a rendszergazdátok repdesne az örömtől, hogy Symfony frissítés után mindig patchelgetnie kell.

Ha nem tetszik az ötlet, szíved joga, de azt lásd, hogy amit javasoltam, az bármilyen stock framework-el működik, garantáltan szopásmentes és jövőbiztos.

Biztos, hogy PHP-val nagyobb az erőforrásigény, mint htaccessel? Még apacsban is ki lehet kapcsolni a htaccess értelmezését, mert lassít. Más webszervereken meg nincs is. A PHP meg már elég jól gyorsítja a kódot. Én nem látom a lényegi erőforráskülönbséget, de PHP route esetén a kód nem webszerverfüggő.

Biztos, hogy PHP-val nagyobb az erőforrásigény, mint htaccessel?

Egészen biztos. De nyugodtan meg is mérheted.

Rewrite esetén egyszer felparseolja a szöveges fájlt, aztán felparseolt formában tárolja és helyben használja a memóriából a webszerver, semmilyen más erőforrásigény sem másik processzel való kommunikáció nincs a dologban. Ha rendesen van megírva, akkor a regexpeket is eleve felparseolt, tokenizált formában tárolja, és még Linux syscall hívásokra sincs szükség, helyben, a webszerver felhasználói memóriájában lerendez mindent.

Ezzel szemben PHP esetén:
1. össze kell állítani a php környezet a http fejlécek konvertálásával, query és post értelmezéssel stb.
2. php interpreter indulásának is van overheadje, potenciálisan másik processz, át kell neki adni a környezetet
3. a php-ból ki kell építeni a kapcsolatot az adatbázisszerver felé
4. az sql query-t át kell adni az adatbázisszervernek a kapcsolaton keresztül
5. a query-t a szervernek fel kell parseolni és tokenizálni kell (ezt mindig meg kell tenni, mert a query szövegesen érkezik a kapcsolaton keresztül)
6. a query-t le kell futtatni (külön lemezművelet, nem biztos, hogy az eredmény cache-elve van)
7. az eredményt át kell adni a php-nak a kapcsolaton keresztül
8. a php-nak a nyers kommunikációt át kell alakítania php változókká (jellemzően a db plugin és esetleg a PDO dolga)
9. az eredményt fel kell dolgozni php-ból (a tényleges Symfony routing)

Más webszervereken meg nincs is.

Minden webszerver tud rewrite-ot, direkt belinkeltem több dokumentációját is, hogy hogyan. A fenti mintám például nginx-es.

A PHP meg már elég jól gyorsítja a kódot.

Nem a php értelmezés a gyenge láncszem, hanem a rengeteg IPC, socket írás-olvasás (ezekhez rengeteg Linux syscallra és felhasználói-kernel memória közti másolásra is szükség van), no meg a különböző adatreprezentációk közti másolgatás és folyamatos konvertálgatás. A php interpreter elenyésző szelete csak a teljes overheadnek egy adatbáziskapcsolatot használó szkript esetén.

Az 1-tők 9-ig minden pont lezajlik akkor is ha a te rewrite megoldásodat használja valaki -.- Ugyanúgy van routing, csak max nem 20 routingot tölt be, hanem csak 5-öt. Ugyanúgy van query, de mondjuk 2-vel kevesebb, bár mivel sf a routingot cacheli, így query sincs annyi.

Nem akarok végbebenő vitákba belemenni, nem látom értelmét. A lényeg, hogy értek mindent, hidd el, de nem tartom jónak az ötletedet több okból se.

Az 1-tők 9-ig minden pont lezajlik akkor is ha a te rewrite megoldásodat használja valaki

Nem. Már mindjárt a legeslegelső pont se fut le a rewrite-os URL-re.

Ugyanúgy van routing, csak max nem 20 routingot tölt be, hanem csak 5-öt.

Nincs. A rewrite kizárólag a webszerver memóriájában történik.

Ugyanúgy van query

Nincs. A webszervernek egyáltalán még csak kapcsolata sincs az adatbázisszerverrel, hogy hajthatna akkor végre query-t?

A lényeg, hogy értek mindent, hidd el

Ez nem hit kérdése, pontosan tudom a válaszaidból, hogy nem értesz az egészből semmit sem. Mégegyszer: a rewrite a webszerver memóriájában történik, php és sql nélkül. A módosításához kell csak a Symfony, a sima oldallékéréshez nem, az egyből még a webszerverben átdobódik arra a nyelvkódot tartalmazó egyedi URL-re, amit egyébként is lekezelnél Symfony-ból.

Nekem mondjuk mindegy, gányold csak szét a Symfony-dat, de aztán ne lepődj meg, ha problémába ütközöl majd a frissítésnél és lassú lesz az egész.

Ez nem hit kérdése, pontosan tudom a válaszaidból, hogy nem értesz az egészből semmit sem. Mégegyszer: a rewrite a webszerver memóriájában történik, php és sql nélkül.

Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset, amiről beszéltek, a te megoldási javaslatod lényegesen kevesebbet tud nyújtani, ráadásul, ha a webszerver processze akar írni ilyen fontosságú konfigurációt, amibe szinte mindent bele lehet írni, az a melegágya a biztonsági problémáknak.

Nekem mondjuk mindegy, gányold csak szét a Symfony-dat, de aztán ne lepődj meg, ha problémába ütközöl majd a frissítésnél és lassú lesz az egész.

Látszólag te akarod szétgányolni, azzal, hogy minden kényelmi, biztonsági és framework szintű funkciót külön-külön megbaszol a teljesítmény oltárán. A helyzet viszont az, hogy az esetek nagyon-nagy részében a kutyát nem érdekli az, hogy mennyivel kevesebb CPU és memória lenne elég a kiszolgáláshoz, ha amúgy marginálisan kicsi a forgalma és egyébként is ott van a CPU és memória, kihasználatlanul.

Ahogy ugye a mondás szól: “Premature optimization is the root of all evil”.

https://iotguru.cloud

Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset, amiről beszéltek, a te megoldási javaslatod lényegesen kevesebbet tud nyújtani, ráadásul, ha a webszerver processze akar írni ilyen fontosságú konfigurációt, amibe szinte mindent bele lehet írni, az a melegágya a biztonsági problémáknak.

Szerintem ez a legfontosabb, ami miatt aki kicsit is foglalkozott már webes rendszerek biztonságával, abban fel sem merül, hogy a webszerver (nopláne a php) processze írhassa ilyen szinten a saját konfigját (legjobb esetben leginkább semennyire sem). Szerintem a "melegággyal" még finoman is fogalmaztál, hosszú távon ezt én öntökönlövésnek tartom. Itt határozottan igaz, hogy a security és a performance egymás ellenségei. :)

Én már nem akartam ebbe komolyabban belemenni, de természetesen megoldható, lightweight routingolás megírása. Rewrite átadja fullban az url-t és egy kvázi pár soros php script feldolgozza cache-ből. De oh wait, ezt a symfony pontosan így csinálja :)

Jelenleg az egyáltalán nem optimalizált rendszerem 7ms alatt lefutott localban, 4MB-os ram használattal.

Egyébként  nginx-et használok webszervernek, amióta konténerekben dolgozom, és fpm-et használok azóta csak nginx-et tolom mellé.

Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset

Látom, Te sem érted. Két, egymástól független dologról van szó. Na mégegyszer:
1. amikor változik az URL, akkor egy Symfony-s php szkript lekéri a routingot az adatbázisból, és a nyelvkód nélküli URL-eket kiírja egy rewrite fájlba, mint amolyan cache-t. Ez csak akkor fut le, amikor VÁLTOZIK a routing.
2. az oldallekérés közben NINCS adatbáziskapcsolat, a nyelvkód nélküli URL-ek a webszerver memóriájában íródnak át nyelvkódos URL-ekké. Ez MINDIG lefut, de nem használ se php-t, se sql-t.

te megoldási javaslatod lényegesen kevesebbet tud nyújtani,

Francokat. Épp ellenkezőleg, lehetővé teszi, hogy egy oldalhoz több URL-t is fel tudj venni, amit jelenleg az OP nem tud vanilla Symfony-val megoldani.

amibe szinte mindent bele lehet írni

Miért is? A fájlba írást az Ő általa írt php végzi, az Ő általa admin felületen megadott adatokból. Ennyi erővel már az is gáz lehetne, hogy admin-ból egyáltalán megadható az URL, mert bármit bele lehet abba is írni.
Elfeledkezel róla, hogy nincs felhasználói adat sehol, csakis admin által biztosított adat kerül egy admin által készített template-be. Ha ez törhető, akkor az azt jelenti, hogy az egész admin felületük törhető...

Látszólag te akarod szétgányolni, azzal, hogy minden kényelmi, biztonsági és framework szintű funkciót

Miről beszélsz, miféle framrework szintű funkció? A Symfony alapból NEM is kezel több URL-t egy oldalhoz! Az én megoldásomnál NEM kell a Symfony kódjához hozzányúlni, a Ti megoldási javaslatotoknál ellenben igen, szétgányolás nélkül nem is implementálható Symfony-ba, amit akartok.

Látom, Te sem érted. Két, egymástól független dologról van szó.

Pontosan ezt írtam én is: két külön dologról beszéltek.

Francokat. Épp ellenkezőleg, lehetővé teszi, hogy egy oldalhoz több URL-t is fel tudj venni, amit jelenleg az OP nem tud vanilla Symfony-val megoldani.

Egyrészt behozva egy csomó egyéb, jellemzően biztonsági problémát; másrészt meg tud oldani, csak neked nem tetszik az a megoldás, jössz mindig egy olyan megoldással, ami egy csomó körbetákolást igényel, hogy ránézésre biztonságos legyen, nemhogy valójában is.

Én a helyedben elgondolkodnék azon, hogy miért nincs a megoldási javaslatod benne egyik webes keretrendszerben se (vagyis az, hogy a webszerver rewrite rule fájlokat írja át röptében a PHP vagy egyéb framework), mert szerintem megint olyan dologba szólsz bele, amiről közel nulla tapasztalatod van...

https://iotguru.cloud

Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset

Látom, Te sem érted. Két, egymástól független dologról van szó.

Pontosan ezt írtam én is: két külön dologról beszéltek.

Francokat, még véletlenül sem ezt írtad (direkt beidéztem azt is, amit írtál, hogy mindenki lássa). Még csak nem is arról volt szó, hogy mi miről beszélünk, hanem arról, hogy fingod sincs, miről szól a megoldásom.

Arról hordtál össze mindenféle baromságot, hogy "Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset", ami nyilván nem igaz.
Amire én írtam, hogy "Két, egymástól független dologról van szó", az meg kizárlóag az EGYIK megoldás két komponensére vonatkozott, és még csak nem is a két megközelítésre, mint ahogy hitted!

Jól van fiam, egyes, leülhetsz.

Még csak nem is arról volt szó, hogy mi miről beszélünk, hanem arról, hogy fingod sincs, miről szól a megoldásom.

Szerintem te nem érted, hogy mi a különbség. :)

Arról hordtál össze mindenféle baromságot, hogy "Ha nem adatbázisból dolgozik a rewrite a webszerver oldalán, hanem statikusan fájlból, akkor nem ugyanaz a featureset", ami nyilván nem igaz.

Pedig nyilván igaz, hogy nem ugyanaz a featureset, erre még te is rájöttél, mert elkezdted körbetákolni, különféle módosításokkal: cron, reload, külön fájl, ecetera. És még mindig nem néztük meg, hogy mivel véded meg a fájlt, hogy ne lehessen bele bármit írni, nem csak rewrite rule halmazt...

Jól van fiam, egyes, leülhetsz.

Tudod, magas lóról nagyot esni... :D

https://iotguru.cloud

LOL.

Jó kedvemben vagyok, ezért tételesen válaszolok a hülyeségeidre :-)

Szerintem te nem érted, hogy mi a különbség. :)

Senkit nem érdekel, hogy szerinted mi, amikor feketén-fehéren le van írva. Átlagos intelligenciával rendelkező egyének el tudják olvasni, sőt, meg is tudják érteni.
Hogy te nem tartozol ebbe a csoportba, az nem az én bajom.

Pedig nyilván igaz, hogy nem ugyanaz a featureset

Bizonyítsd! Mi az a feature ebben az esetben, ami nem megoldható, ha az adatbázis kimenetét használat előtt egy fájlban cache-eled!

elkezdted körbetákolni, különféle módosításokkal: cron, reload, külön fájl

Na ezzel alaposan beszaladtál tátott szájjal a faszerdőbe.Tanulj meg olvasni! Sehol semmi módosítás, ezeket már mind a legeslegelején leírtam. Sőt, a cron-ra is utaltam már az első válaszomban. Ott áll feketén fehéren, az nem az én bajom, hogy nem tudsz olvasni.

Jól van fiam, egyes, leülhetsz.

Te mostanában nagyon szeretsz tátott szájjal a faszerdőben szaladgálni. :D

Tényleg javaslom, hogy ül le és gondolod egyszer végig, hogy vajon miért nem használja egyik elterjedt keretrendszer sem az általad javasolt megoldást. Vagy mindenki balfasz, akinek ez a fő szakterülete vagy te vagy balfasz ehhez a területhez és a problémák töredékét se látod át.

https://iotguru.cloud

Bocs, de lehet több url-t felvenni egy "oldalhoz", azaz egy controller alatti method-hoz. Tökéletesen működik.

A symfony kódjához amúgy se kell hozzányúlni, hisz a symfony kódját a vendor alatt nem szerkesztjük.

Sajnos jól mondják, totál szétgányolnád a rendszert olyan megooldással ami lényegében megoldható a fw alatt.

Nekem az a gyanúm, hogy fingod nincs se a php se a symfony működéséről/használatáról. Mintha el se olvasnád amit írunk, vagy nem is értenéd.

Te írtad:

Nagyon sok doksit átolvastam, átnéztem fórumokat. Nem jöttem rá hogy kéne felvinni több routingot egy name alatt több nyelven.

Én erre, és csakis erre adtam egy olyan működő megoldást, amihez nem kell belenyúlni a Symfony kódjába.

Sajnos jól mondják, totál szétgányolnád a rendszert olyan megooldással ami lényegében megoldható a fw alatt.

Ha megoldható, akkor meg mi a fészkes fenének indítottad ezt az egész topikot???

Aki pedig azt hiszi, hogy ha hozzá sem nyúl a kódhoz, azzal "szétgányolná a rendszert", az már bocs, de hülye. Pont az a lényeg, hogy nem nyúlsz a framework kódjához, vanilla Symfony-val működik, így garantáltan jövőbiztos. Ha valóban "szétgányolná a rendszert", akkor nem lehetne jövőbiztos, ugyebár.

Ha nem értesz a keretrendszerhez, akkor érthető, hogy nem érted meg a kifejezéseket, kulcsszavakat se. Ez nem baj, de akkor ne írj rá tanácsot.

A routing name nem az adott controller methodja tehát a cél amit bedrótozol egy url alá, hanem az adott routing named id-je.

Ha azt mondod, hogy van egy routingod, annak adhatsz egy nevet amire hivatkozhatsz. 

 

Továbbra is félrebeszélsz. A te htaccess-ed se írja meg saját magát. Azt is implementálni kell a kódban.

Nem az a "jövőbiztos", hogy kikerülöd  fw-t és nem dolgozol vele, hanem az, ha folyamatosan frissen tartod a vele írt kódodat és frissíted, karbantartod.

Továbbra is félrebeszélsz. A te htaccess-ed se írja meg saját magát. Azt is implementálni kell a kódban.

Nem én beszélek félre. Nem beszéltem htaccess-ről se (az eredeti posztomban konkrétan nginx példa díszeleg, még csak nem is apache-os). És nem beszéltem Symfony framework kód módosítás implementálásáról se.

Az én javaslatom a már meglévő Symfony kódbázis mellett (és nem pedig azt módosítva) implementálandó, de minek is magyarázom?

Nem az a "jövőbiztos", hogy kikerülöd fw-t és nem dolgozol vele

Nem kerülöm ki. Csak cache-elem az fw kimenetét egy olyan formátumban, amit történetesen csont nélkül megeszik a webszerver. De úgysem érted, hiába.

Ezt most komolyan kérded? Tényleg azon lovagolsz, hogy a "name-el ellátott egyedi routing céljául megadott controllerrel rendelkező" helyett egyszerűen "oldalt" írtam? Ha nem értetted, akkor nem velem van a baj, bocs.
A "nem jöttem rá hogy lehetne" magyarul azt jelenti, hogy nincs megoldásod, és mivel ezt egy olyan IT fórumra írtad ki, ahol kérdezni szoktak... (Ráadásul a Fejlesztés kategóriába).

Vita nem is volt. Nézd, én csak tippet adtam, hogy hogyan kell hatékonyan megoldani azt, amivel küzdesz, te meg nem értetted, mert eggyel alacsonyabb rétegben van megvalósítva, mint amihez értesz.

Ha nem érted, hogy a rewrite-ot pontosan ennek a problémának a hatékony megoldására rakták bele a webszerverekbe, arról nem tehetek, az már nem az én bajom.

Nem vagyok tapasztalt az ngix működésében, de úgy tudom, nem tudja azt a funkciót, amit a .htaccess, azaz, hogy a mappába bemásolt fájlt a kérelem idején olvassa és értelmezi. Amennyiben a webszerver konfigurációjában kell beállítani a rewrite-ot, az valóban elég hatékony lehet, de azt meg a php nem fogja tudni legenerálni. (Vagy legenerálja, de nem tudja felolvastani a webszerverrel.)

A .htaccess esetén pedig nem csak felolvassa a fájlt és értelmezi, hanem minden kérelem esetén a gyökérkönyvátrtól egészen kiszolgáló mappáig minden mappát át kell néznie, és el kell döntenie hogy van-e ott .htaccess, módosult-e, és ha igen értelmezni is a tartalmát. Azt nem tudom, tárolja-e a htaccess-ekben lévő szabályokat, vagy kérelmenként értelmezi, a forrást még sosem láttam.

Így van, kell az nginx-nek egy signalt küldeni, hogy újraolvassa a konfigot. Ezt csak az admin teheti meg.
Konfigot egyébként nem írhat a php, csak egyetlen egy fájlt, amit a megfelelő helyen include-ol az nginx konfig, és azt az egyetlen egy fájlt is csakis admin által biztosított adatokból generálja.

De ha valaki nagyon nagyon biztonságosra akarja megcsinálni, akkor cron-ból percenként futtatható egy szkript, ami megnézi, változott-e a Symfony routing (sima timestamp check), és ha igen, akkor újragenerálja a rewrite konfigot és küld egy signalt az nginx-nek. Ekkor sem a fájlt író szkript, sem a létrehozott fájl nem lesz a webszerver user nevében. Az egyetlen hátránya ennek a megoldásnak, hogy URL módosítás után várni kell max. 1 percet, mire érvénybe lép, viszont atombiztos (mert nem is a webszerver futtatja a rewrite generálót).

Egy átlagos osztott környezetben felhasználóként nincs módod befolyásolni a webszerver működését. Ez a megoldás csak akkor jöhet szóba, ha a teljes szervert a PHP kód készítője üzemelteti. Ez szerintem azért a ritkábbik eset. Gyanítom ez az egyik oka annak, hogy a Simphony is a PHP routingot támogatja, hogy minden környezetben működhessen.

Valahogy így gondolom én is, ez a symphony-revproxy oda-vissza kooperáció csak egy monolit környezetben, nagyjából csak "single instance" esetében működhet jól.

Se nem túl biztonságos, se nem túl üzembiztos/konzisztens egy elosztott-clusteres környezetben.

Érdemes a layereket (felelősségeket, határokat) tisztán és egyszerűen tartani még akkor is ha ez néhány CPU ciklussal többe kerül adott esetben.
 

zászló, zászló, szív

( zsolt | 2024. 05. 17., p – 18:17 )

Programozóként Geminit használom inkább. Kódot írni az se nagyon tud, viszont egészen jól kiváltja a hosszas guglizásokat és többnyire releváns linkeket ad összefoglalóval együtt. Tipikus iskolapéldákat különben sokszor jól hoz mind a kettő, de az nem programozás, csak minták visszaböfögése.

Pontosan.

Tegnap pl. egy konkrét célra kerestem egy library-t. Régebben órákat töltöttem volna a 80 alternatíva doksijainak bogarászásával, most viszont leírtam Gemininek a pontos igényeimet, javasolt 4-et, amiből 3 "ágyúval verébre" megoldás lett volna, viszont az egyik szinte semmivel sem tud többet, mint ami nekem kell, totál minimál megoldás és nagyon egyszerű. Kb 5 perc volt eldönteni, melyiket fogom használni.

( Raynes v | 2024. 05. 17., p – 19:10 )

Persze, ezt írom én is mindig, nem veszi el az AI a fejlesztők munkáját. Nem alkalmas arra, hogy tuti működő és megbízható kódot írjon. Arra jó, amire most te is használtad, nem volt ölteted, megkérdezted az AI-t, az vázolt valamit, ami arra lehet jó, hogy irányt keress, ötletet, merre indulj el. Megcsinálni nem fogja senki helyett, ezt csak a média, meg a marketingesek akarják mindenkinek bemesélni, meg az NVidia, hogy eladhassa az AI-hoz a túlárazott, méregdrága GPU-it.

Épp úgy nem váltja ki az AI a fejlesztői munkát, ahogy a gépi fordítók se váltották ki soha a tolmácsokat, fordítókat, nem tették mellőzhetővé a nyelvtanulást, stb.. Az AI persze hasznos, de csak egy segédeszköz, mint egy jó IDE, debugger, language server, stb.. A világot nem váltja meg önmagában.

Amire nagyon jó, az az ötletelés, ihletkeresés, pl. ha valami dizájn, logó, vizuális megvalósításhoz keres valaki ötletet, vagy pl. nagy mennyiségű statisztikai adaton tanítja be az AI-t, hogy korrelációkat keressen bizonyos tényezők között, pl. orvosi felvételeken daganatokat szoktak vele kerestetni, persze kutatási anyagban, hátha lát összefüggést utólag. Ilyenre kiváló.

“Windows 95/98: 32 bit extension and a graphical shell for a 16 bit patch to an 8 bit operating system originally coded for a 4 bit microprocessor, written by a 2 bit company that can't stand 1 bit of competition.”

Épp úgy nem váltja ki az AI a fejlesztői munkát, ahogy a gépi fordítók se váltották ki soha a tolmácsokat, fordítókat, nem tették mellőzhetővé a nyelvtanulást, stb.

Bizony!

https://youtu.be/WzUnEfiIqP4

https://youtu.be/c2DFg53Zhvw

( osod88 v | 2024. 05. 17., p – 21:11 )

A fejlesztés az túlzás, de powershell, bash, python scripteket, ansible, cloudformation, terraform templateket, hasonlókat simán iratok vele.

Van hogy néha félremegy amit generál, hülyeséget csinálna, félreért vagy kitalál nem létező funkciókat, ez tény. De legalább ad egy használható megoldás vázlatot hogy hogyan is kéne kinézzen a működő kód.

Ahol viszont logikára, tervezésre, összetett gondolkodásra volna szükség, azt nem érdemes egyben megpróbálni vele. Azt még nem tudja mint egyszerű nyelvi modell.

De apróbb részletekre lebontogatva a bonyolult feladatokat nagyon jól lehet vele haladni. Szerintem az a gond hogy sokan egy kész feladatleírást bevágnak neki, aztán csodálkoznak hogy hülyeség jön ki a végén.

"Everything fails, all the time."

( arpi_esp v | 2024. 05. 17., p – 21:16 )

Szerkesztve: 2024. 05. 17., p – 21:17

> Persze nála gyorsabban megvoltak a válaszok

ez a lenyeg... nyilvan az AI elott is lehetett guglizni, forumokban keresni/kerdezni stb, de az AI az osszeset elolvasta mar es vagja a valaszokat, jot is rosszat is, epp mikor mit dob a VELETLENBGENERATOR.

> Azt nem értem, hogy valóban emberek fejlesztenek vele?

allitolag igen. es allitolag a fizetos gpt 4.x jobb, mint az ingyen elerheto 3.5-os

https://chatgpt.com/share/38864043-5132-497a-a6f2-0c4e762362e2

Ezt GPT-4 -el sikerült elérni, ami fizetős. Nem mindig ad helyes választ, és símogatni kell a lelkét (rávezetni a helyes megoldásra), hogy kifacsarjon az ember belőle értelmes választ.

( Feltéve, hogy van ehhez valakinek cérnája )

 

De van amikor ez sem segít, és bekamuzik valami baromságot:

https://chat.openai.com/share/b59ff260-1d04-494b-bf23-90dab234dbda

<artifactId>spring-ai-starter</artifactId>

^ No persze.

Amit viszont hasznosnak találtam az a Bito Ai Code Assistant IDEA -hoz. (Van VSCode -hoz is)

es allitolag a fizetos gpt 4.x jobb, mint az ingyen elerheto 3.5-os

Hat jobbnak tenyleg jobb, de egyelore a "fejlesztenek vele" az azt jelenti, hogy megetettem vele egy-egy temaban az osszes doksit, amit meg tudtam szerezni ertelmes formaban, aztan tudok tole kerdezni, es valaszol. Valamit. Gyakran egesz jot, raadasul, de azert a bugot nem javitja meg, amivel kapcsolatban kerdezek tole.

( NagyZ v | 2024. 05. 18., szo – 09:58 )

opensource libraryk hasznalatanak megertesere sokkal gyorsabb mint guglizni, multkor kb 1 ora beszelgetesbol hasznalhato kliens/szerver part kodolt le nekem ugy, hogy azt csinalta amit akarok, olyan libraryben, amit eletemben nem hasznaltam :)

( nagyjoco | 2024. 05. 18., szo – 16:52 )

Szerkesztve: 2024. 05. 18., szo – 16:54

A CodePilot eléggé berobbant, a chatgpt chatablak messze nem a legoptimálisabb felület komolyabb  felület támogatására, és akkor még finoman fogalmaztam. Egy újabb eszköz a szerszámosládában, hozzáértők kezében jelentős produktivitás emelkedés érhető el, aki meg nem tud programozni, azon meg ez se segít. Szakértelem és szorgalmas munka nélkül ugyanis nem lehet értéket teremteni nyelvi modellel sem, bármit is hordanak össze a marketingesek. 

Ha tartós rendszert építesz és okos csapatot nevelsz, akkor száz kiadásban sem érheti baj; ha csak a gépekre hagyatkozol, akkor egyszer jól jársz, máskor rosszul; de ha sem a rendszer nem bírja a terhet, sem a csapat nem tanul a hibákból, akkor minden egyes kiadás kockázat.

( tigrincs | 2024. 05. 19., v – 09:02 )

En Power Apps -hoz hasznalom. Leginkabb abban tud segiteni, hogy megertsek egy uj funkciot. De az elo magusoktol lehet igazan sokat tanulni. Es azert eleg sokszor ordas nagy baromsagokat tud irni.

( mbael | 2024. 05. 19., v – 10:26 )

Szerkesztve: 2024. 05. 19., v – 10:27

Fejleszteshez nem hasznalom, de mondjuk copywrite placeholder szovegek legeneralasahoz UI-hoz igen, lorem ipsum helyett

Nyelvi model, igy ajanlott akkent is kezelni.

( sz332 v | 2024. 05. 19., v – 12:27 )

Excel automatizálást kellett írnom kollégáknak, 90%ban megírta a basic kódot a maradékhoz egy kis Google kellett. A lényeg hogy 10 perc alatt megoldódott az egész. 

( nagy_peter v | 2024. 05. 20., h – 02:37 )

Azon is sok múlik, hogy melyik AI-t kérdezed. A GPT-3 turbó, és a 3.5 általában csak a legegyszerűbb feladatokkal birkózik meg, míg mondjuk a GPT-4 komplett funkciókat megvalósít egész jó minőségben.
Nyilván a rendszer logikájának a kitalálását ne hagyd rá, de mondjuk ha megkéred, hogy nézze át a kódodat biztonsági vagy optimalizálás szempontjából, néha nagyon jó ötleteket ad.

Nagy Péter

( gabrielakos v | 2024. 05. 21., k – 14:22 )

Igen, fejlesztenek. én is használom. seniorként kifejezetten hasznos hogy egy csomó boilerplate-t megír nekem. a hülyeséget kiszúrom / úgyis tesztelem.

Amikor valami új dologba kezdek kifejezetten hasznos hogy sokezer oldal doksi elolvasása helyett csak felteszem a kérdést és jól válaszol.

Nem "okos kreativitást" kell elvárni tőle hanem nagy tömegű információ gyors és jó összefoglalását, keresését.

zászló, zászló, szív