- Telekom otthoni szolgáltatások (TV, internet, telefon)
- Windows 11
- CentOS Linux
- A franciáknak elege van abból, hogy minden gyerek mobilozik
- Debian GNU/Linux
- Sokat fogyaszt az AI, egyre több az adatközpont, kell az atomenergia
- Facebook és Messenger
- LibreOffice topik
- Kodi és kiegészítői magyar nyelvű online tartalmakhoz (Linux, Windows)
- Hálózati / IP kamera
Új hozzászólás Aktív témák
-
cucka
addikt
válasz Swifty #11870 üzenetére
Benevezek én is a versenyre, várom a zsűri véleményét
Ez egy függvény, ami egy tömböt ad vissza, elemei html táblázatok (ugye gondolunk arra, hogy talán el szeretné őket helyezni az oldalon). További előnyei, hogy nem csak 3 oszlopra működik, mellékhatásmentes és el lehet olvasni (azt az egész képernyőt betöltő sorodat hamarabb újraírom, mint hogy értelmezzem, mit csinál).
[link]
Ja, és normál esetben elég nagy fasság ilyen függvényeket írni, legalábbis mvc-ben a függvény első fele az m vagy a c dolga (ízlés dolga), a második fele pedig a v-é.[ Szerkesztve ]
-
cucka
addikt
válasz Peter Kiss #11879 üzenetére
Jaja, az fopen végére kell egy "or return array()". (Vagy lehet dobni kivételt is, ízlés szerint)
Plusz a html összerakó rész megcsinálható 2 sorban, kell hozzá 1 darab array_map meg 2 darab implode és megspórolható a dupla ciklus. Ha valakinek van kedve, elszórakozhat ezzel.
[ Szerkesztve ]
-
cucka
addikt
válasz bobace #11965 üzenetére
Két kérdés:
- Pontosan mit akar csinálni ez a program? Ezer sebből vérzik, így nehéz megragadni a problémát.
- a system->check_mysql pontosan mit csinál? Összerakod a query-det mindenféle sql injection ellenőrzés nélkül, majd lefuttatod, az eredményét pedig odaadod a check függvénynek. Ha sql injection történik, akkor a check függvény mit fog csekkolni? -
-
cucka
addikt
válasz bobace #11977 üzenetére
Ez az a kérdés, amire nem fogsz választ kapni. Például itt a köv. bemenő adat, időrendben:
számlák 180, 50, 53, 90, 108
befizetés 200Namost
- kifzetheted a 180-at. Ez egy optimum, mert a legrégebbi számlát egyenlítetted ki.
- kifizethetsz 50+53+90-et. Ez egy optimum, mert a legtöbb számlát egyenlítetted ki.
- kifizethetsz 90+108-at. Ez is egy optimum, mert így fizetted ki a legnagyobb összeget.Az egy üzleti döntés, hogy a fenti esetekből melyiket választod (és nem csak ez a 3 eset van). Mindhárom megközelítés helyes, de ezt a megrendelővel kell tisztázni, hogy milyen működést szeretne látni a programban.
-
cucka
addikt
válasz bobace #11980 üzenetére
Végül is mivel alapvetően prepaid rendszerű a dolog, így mindegy melyik optimumot választanám, mert az egyenleg a mérvadó, ha most marad 20 Ft a számláján mindegy, majd következő alkalommal beszámítja a rendszer.
Pont, hogy ellentmondasz magadnak. Ha az egyenleg a mérvadó, akkor nem mindegy, hogy melyik optimumot választod, hanem pont hogy azt kell, amelyiknél a lehető legnagyobb mértékben csökken a kifizetetlen tartozás. Egyébként szerintem a 3 közül talán ezt a legnehezebb leprogramozni, mert az egyszerű mohó (greedy) algoritmus ilyenkor nem fog optimális eredményt adni.
Egyébként ez tök jó feladat, ha tanulóprojektről van szó és szeretnél fejlődni, akkor javaslom, hogy kódold le mind3 esetet. -
cucka
addikt
válasz bobace #11982 üzenetére
A mohó algoritmusok úgy működnek, hogy minden egyes iterációban a lokális optimumot választják.
Például ha az a célod, hogy a legrégebbi számlákat kell kiegyenlíteni, akkor a mohó algoritmus minden egyes lépésben kiválasztja a legrégebbi számlát, amit ki tud egyenlíteni (ez a lokális optimum) a meglévő keretből és kiegyenlíti. Elég könnyű belátni, hogy így a végén is optimumhoz jutunk.
Ha viszont az a célod, hogy a lehető legnagyobb összeget kel kiegyenlíteni, akkor a mohó algoritmus minden egyes lépésben kiválasztja a legnagyobb összegű számlát, amit ki tud egyenlíteni (ez a lokális optimum) a meglévő keretből. Szintén elég könnyű belátni, hogy ez összességében nem fog optimális eredményhez vezetni.
Pl. ha a számláid összege 80, 40, 50 és a rendelkezésre álló pénz 100, akkor a mohó algoritmus kiegyenlíti a 80-as számlát és megáll, miközben az optimális a 40 és 50 kiegyenlítése lenne.[ Szerkesztve ]
-
cucka
addikt
-
cucka
addikt
válasz Sk8erPeter #12029 üzenetére
Ha valaki esetleg meghallgatja, nagyon röviden leírhatná a konzekvenciákat, hogy mit hoznak ki a dologból.
Elolvastam a leiratot, csak fűrészelik a fingot, simán kihagyható az egész. -
cucka
addikt
válasz modder #12119 üzenetére
Ami előnye (lenne), hogy nem kell mindenhol kiírni a típust, de ez nem feltétlenül jelent dinamikus típusosságot.
Nem igazán. A dinamikus típusosság lényegében nem más, mint rengeteg cast-olás, amit megcsinál neked a fordító/interpreter/akármi. Például a design pattern-eknél látható borzasztó objektum hierarchiák nagy részét egyszerűen ki lehet dobni egy dinamikusan típusos nyelvben.
Vagy ott van az, hogy egy függvény visszatérési értéke tetszőleges lehet: így kivételek nélkül is megoldhatod a hibakezelést. Ne feledd, a szkriptnyelvek alapvetően rövid programok írására lettek kitalálva.Vannak más nyelvek, ahol gyönyörűen meg van oldva, hogy ha létrehozol egy változót, onnantól már nem változtathatsz a típusán, és ki sem kell írni a típusát sehol.
És melyik ez a nyelv? Vagy most az új C++ auto kulcsszavára gondolsz?(#12122) Sk8erPeter
Nem, én nem hiszem, hogy csak a típustalanság miatt népszerű ennyire, én nem tudom, ezt honnan szeded.
Attól népszerű, mert egy könnyen tanulható, nagyon megengedő szabályokkal ellátott szkriptnyelv. Nyilván, ha statikusan típusos lenne, akkor ezek a tulajdonságok nem lennének érvényesek.Szerintem a PHP-val rengeteg probléma van, de ezek nem abból adódnak, hogy a nyelv dinamikusan típusos - egy részük annak köszönhető, hogy Rasmus Lerdorf nem értett a programozási nyelvek fejlesztéséhez, a másik részük meg annak, hogy a mai napig nem ért .
Olvassatok phpsadness-t, megéri.[ Szerkesztve ]
-
cucka
addikt
válasz modder #12132 üzenetére
A baj az, hogy a nyelv "kinőtte magát". Az emberek már nem kis dinamikus weboldalakra akarják használni, hanem bonyolult funkciókat megvalósító portálokat írnak benne.
Enterprise javaban is meg lehet oldani bármilyen szkriptelési feladatot, csak nem éri meg.
PHP-ban is meg lehet oldani enterprise szintű feladatokat, csak szintén nem éri meg.Egyébként nagyon magasan van az a léc, ahova a php ne lenne elég. Az, hogy a kód milyen minőségű lesz, elsősorban a fejlesztőn múlik itt is, mint minden más nyelvben.
De van egy csomó hülyeség, amit a PHP megenged (pl. minden lószart hatalmas multidimenziós tömbökben tárolunk végig a program futása során),
Miért, ha külön-külön változókban tárolnák, akkor az mitől lenne jobb? A php a tömböket ígyis-úgyis referencia szerint adja át, tehát nem látom, hol az overhead, amit említettél.A Haskell-t kezdtem el tanulgatni, és ott ez így működik.
A Haskell egy (majdnem) tisztán funkcionális nyelv, ott minden máshogy működik. Típus annotációk egyébként vannak szinte minden nyelvben, talán egyedül a php a kivétel, ahol ez nem lenne teljesen egyértelmű a rossz automata cast-olási szabályok miatt.Szintén Haskell könyvben taglalják több paragrafuson keresztül, hogy mennyire jó, hogy ha megnézzük egy metódus szignatúráját, abból egyből látszik, hogy mit csinál egy függvény
Valamivel ki kell tölteni a helyet abban a könyvben.
Taglalhatnák azt is, hogy a gyakorlati életben milyen jó eszköz a Haskell, meg hogy hogyan tudja leegyszerűsíteni a fejlesztést, de hát az egy elég rövid könyv lenne.(#12127) Sk8erPeter
Korábban is írtad, hogy kvázi egy dilettáns majom, de miből gondolod ezt amúgy?
Ez így túlzás, hogy dilettáns majom. A php egy olyan nyelv, amit nem megterveztek, hanem összegányoltak, élen vele. Jelenleg pedig nem tetszik az a hozzáállása, hogy a visszafele kompatibilitást meg kell őrizni bármi áron. Szerintem a PHP6 egy reboot kellett volna legyen, ahol végre felülvizsgálják a korábbi tévedéseket, nem ez történt. -
cucka
addikt
válasz Sk8erPeter #12139 üzenetére
Amúgy nekem most nehéz eldöntenem az írásaid kapcsán, hogy a típusosság kérdésében melyik "oldalra" állsz
Azért, mert szerintem ez egy rossz kérdés, irreleváns. Egy nyelv kapcsán fontos kérdés, hogy olvasható-e a kód, megvannak-e a szükséges 3rd party lib-ek és ezek jók-e, mekkora szívás a programodat deploy-olni, van-e megfelelő szaktudású embered, stb. Ehhez hasonló dolgokat érdemes számításba venni, amikor nyelvek/technológiát választunk.Habár függvénydefinícióknál szerencsére PHP-kódokban is látni már olyat, hogy mondjuk
function tokmindegy(array $tomb){
Ez a fícsör a php-ban igazi kókányolás. Működik objektumokra és tömbökre, de nem működik primitív típusokra. (Így mi értelme az egésznek?) -
cucka
addikt
válasz modder #12141 üzenetére
A tömbös példámat rosszul fogalmaztam meg. Nem arra akartam kilyukadni, hogy ha tömböt használsz az nem hatékony, hanem hogy ezzel a megoldással simán elszalad a ló a fejlesztővel, hogy ja, csak dobjunk bele mindent ami kell egy hatalmas tömbbe, mert az milyen egyszerű.
Éppenséggel osztályok és absztrakciók gyártásával is elszaladhat a ló.
Egy kisméretű projektnél az absztrakció nem fog mást jelenteni, mint hozzáadott komplexitást, tömb wrapper objektumokat, fölösleges boilerplate kódot. Egy nagyméretű projektnél sok ember fog dolgozni a kódon nyilván más a helyzet.Aztán jön a másik fejlesztő, és dolgoznia kell egy ilyen multidimenziós tömbön, és fogja a fejét, hogy vajon mi az isten lehet ebben a tömbben.
A jó kód egyet jelent az olvasható, érthető kóddal. Ez pedig elsősorban a fejlesztőn múlik, nem a nyelven.A Haskell nem azért működik így, mert funkcionális nyelv, hanem mert típusos nyelv, és azt mondták a kitalálói, hogy ha van módszer arra, hogy megkíméljük a fejlesztőt attól, hogy mindig kiírja a típust, akkor használjuk.
A Haskell azért működik, mert olyan emberek alkották, akik a progamozási nyelvek szakértői.
A Php egy garázsprojektnek indult, egy lelkes amatőrtől.
Nézd meg a Python vagy a Ruby típusrendszerét (meg magukat a nyelveket), ha kíváncsi vagy olyan dinamikusan típusos nyelvekre, amelyek faszák és jól ki vannak találva.
Ja, és meglepő lehet, de használják a funkcionális nyelveket a versenyszférában, Haskell-ről és Erlang-ról tudok, de más is lehet. (Lisp? ) -
cucka
addikt
válasz Sk8erPeter #12144 üzenetére
Nagyon nem mindegy, hogy adott fejlesztőkörnyezettel, kiegészítő eszközökkel milyen szinten tudsz akár automatizáltan is együttműködni a kódoddal.
Igen, a statikusan típusos nyelvek itt előnyben vannak. Csak ugye még mindig ott tartunk, hogy elméletileg mi mindent lehet megcsinálni egy nyelvvel/technológiával, nem pedig ott, hogy a gyakorlatban mire van szükség. Az ilyen elméleti előnyöket tekintve a legkirályabb fejlesztői környezet a JavaEE, aztán mégis, a PHP-ban jellemző feladatok többségére valahogy nem kívánnád azt használni, mert a sok előny hátrány lesz.Amikor olyan dolgokkal kell órákat elcseszned a drága idődből, hogy kitaláld, hogy vajon a PHP-alapú NuSOAP-library mit nem szeret a kódodból ahhoz, hogy mondjuk legeneráljon neked egy nyomorult WSDL-t
..akkor az azt jelenti, hogy belefutottál egy nem túl jó 3rd party lib-be. Gondolod, hogy más nyelveknél ez nem fordul elő?Amikor C++ után először kezdtem PHP-ben OOP-zni, először nem is értettem, hogy ez most csak ilyen vicces trükkös megoldás, amit kényszermegoldásként be lehet vetni, ha nagyon muszáj, nagyon őrülteknek, vagy pedig egy bevett szokás.
Megint itt tartunk, hogy valaki Java-ban akar programozni PHP-ben . A függvény túlterhelés értelme, hogy típusos nyelvekben biztosítsd, hogy a függvényed több fajta bemenő típussal is boldoguljon. Tehát ha pl. egy függvény kap egy számot paraméterként, és szeretnéd, hogy működjön egészre meg lebegőpontosra is, akkor ezt kell használni.
A PHP egy gyengén típusos nyelv, nincsenek típus annotációk, így értelemszerűen a függvény túlterhelés is teljesen értelmetlen lesz ebben a kontextusban. Lehet úgy is mondani, hogy ha a fejlesztés során erre van szükséged, akkor rosszul tervezted meg a programodat.
Képzeld, Python-ban meg az osztáyoknál nincsenek láthatósági szabályok (private, protected), oszt' mégis nagyon jól működik minden. (De persze, magic method-al bele lehet taknyolni ott is ) -
cucka
addikt
válasz Sk8erPeter #12148 üzenetére
Szerintem nem beszélünk el egymás mellett.
Meggátolja a dinamikus típusosság, hogy az IDE type hint-eket adjon? Igen, ez a szkriptnyelvek egyik hátrányos tulajonsága.
A dinamikusan típusosság miatt nehéz használni a NuSoap-ot? Nem, azért nehéz, hanem mert nincs rendesen megcsinálva.
Meg lehetne csinálni rendesen? Igen.Én pusztán csak annyit állítok, hogy vannak értelmes okok amögött, hogy a szkriptnyelvek miért olyanok, amilyenek. A java féle statikusan típusos, erősen oop nyelvek se nem rosszabbak, se nem jobbak. Azt is állítom, hogy a programozás leginkább feladatok, problémák megoldásáról szól, tehát elméleti viták helyett gyakorlati alkamazásokra kéne inkább fókuszálni, itt dől el, hogy mi jó és mi nem.
A magic method pedig egyáltalán nem csúnya.
A java teljesen oop, tehát minden adat objektum, minden program egy objektumban van, így aztán az összes objektum közös metódusai (pl. a toString) itt találhatók meg és innen öröklődnek. Na ezeket hívjuk php-ban magic method-oknak. Ez a két dolog szemantikailag ekvivalens, tehát amikor azt mondod, hogy csúnya, akkor pusztán annyit mondtál, hogy számodra vizuálisan kevésbé tetszetős, mert mittomén, nem tetszik, hogy __-val kezdődik a nevük. -
cucka
addikt
válasz Peter Kiss #12151 üzenetére
Akkor ettől ennek még nem lesz egyetlen __ metódusa sem, mivel nincs base object (saját rendszerben mindenki csinálhat magának, nyilván).
Te a programozó vagy, a te szemszögedből a két megoldás teljesen ekvivalens.(#12150) Sk8erPeter
Oké, felfogtam, tényleg elbeszéltünk egymás mellett.(#12152) Swifty
Hanem hogy egyes esetekben (pl. __toString) el tudod érni akár azt is, hogy egy MVC-ben az objektumod legenerálja mondjuk a View-ot...
Egyrészt nem javaslom, hogy így használd az mvc-t, másrészt ezt egy tetszőleges metódussal is meg tudod valósítani. -
cucka
addikt
válasz Speeedfire #12155 üzenetére
array_merge
(#12154) Swifty
Igen, pontosan így van, ahogy írod - a különbség pusztán szintaktikai. -
cucka
addikt
válasz lakisoft #12496 üzenetére
A jelenleg piacon lévő adatbázis kezelők nagy többsége ismeri a tárolt eljárásokat, és ismeri a dinamicSQL-t is. Miért nem azt használjátok?
Alapvetően két oka van:
- A tárolt eljárásként írt kódot nehézkes verziókövetővel használni
- Az adatbázisok által biztosított fejlesztői eszközök a 60-as évek színvonalát idézikA bevált megoldás a felvetésedre egy ORM használata.
-
cucka
addikt
válasz lakisoft #12498 üzenetére
1. Trükkel vagy natívban? Mutass kérlek egy ilyen megoldást.
2. Biztosan nem vagyok képben, csak szőrmentén foglalkozok velük, szóval engem érdekelne, hogy milyen kulturált fejlesztőeszközök vannak? PL/SQL szkripteket írtam már Oracle alá, na az egy határ szar volt, szóval ennél jobbra gondolok . (Így látatlanban sanszos, hogy az Oracle támogat valamilyen java-s megoldást, tekintve hogy övék a java is) -
cucka
addikt
Erre milyen számszerű választ vársz? Vagy milyen alternatívára gondolsz? A file-okon kívül milyen más módon tudsz akármilyen adatot tárolni egy szerveren?
Az egy értelmes kérdés lenne, hogy a nagy mennyiségű adatot milyen módon tárold (sima file, sql, nosql), vagy hogy hogyan oldd meg, hogy ne kelljen 50-100 mb adatot a memóriában tárolni ahhoz, hogy kiírd.
Amit kérdeztél, az kb. olyan, mint ha megkérdeznéd, hogy a http protokoll megfelelő-e weboldalak kiszolgálásához.[ Szerkesztve ]
-
cucka
addikt
válasz #68216320 #12696 üzenetére
Hogy világos legyen az empty és az isset közötti különbség:
A következő két feltétel ekvivalens, leszámítva egy notice-t:
isset($v)
$v !== null
Tehát az isset true-val fog visszatérni bármilyen változóra, ami nem létezik, vagy létezik és a típusa/értéke null. Jól látható, hogy a neve ellenére az isset()-nek valójában semmi köze ahhoz, hogy egy változó (vagy tömb index) definiált-e vagy sem. (Ennek eldöntésére a get_defined_vars() való).
Az isset() abban az esetben működik biztonságosan, ha soha, semmilyen körülmények között nem használod a null értéket egyetlen változódnál sem. Felhasználó által post-olt űrlapok esetén ez alapból adott, mert minden értéked a tömbben string vagy array típusú, a kód többi részében viszont a te feladatod ezt biztosítani.És a következő két sor szintén ekvivalens
empty($v)
!isset($v) || $v != true
Az empty() az ekvivalens feltétel második fele miatt problémás. Itt a != operátort látod, ami azt jelenti, hogy a php itt a $v értékét előbb át fogja cast-olni bool típusúra. Ezért van az, hogy a "", "0", "0.0" stringekre az empty egyaránt igazzal fog visszatérni. A gyarkolatban ebből az következik, hogy az empty() teljesen alkalmatlan bármire, visszatérési értékének semmi köze ahhoz, hogy "üres"-e a változó értéke vagy sem. Javaslom, soha, semmilyen körülmények között ne használd az empty()-t, ez egész egyszerűen egy rosszul kitalált nyelvi elem a php-ban.(Egyébként is, a php-ban az == és != operátorok nem tranzitívak, ez elég ok ahhoz, hogy kerülendők legyenek. Helyette javasolt a === és !==, illetve úgy megírni a kódot, hogy tisztában legyél vele, melyik változód milyen típusú.)
Ez így nagyjából érthető?
[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #12701 üzenetére
Hogy térne vissza true-val? Vagy csak elírtad?
Ja, igen, fordítva"Jól látható, hogy a neve ellenére az isset()-nek valójában semmi köze ahhoz, hogy egy változó (vagy tömb index) definiált-e vagy sem."
Egy példa arra, amikor egy tömb index definiálva van, isset szerint viszont mégsem:$a = array(0=>null);
$r = isset($a[0]);
var_dump($r); //-> FALSE
var_dump($a[0]); //-> NULL
var_dump(count($a)); //-> int(1)Ugyanez globális változóra. A $s az isset szerint nem létezik, valójában pedig igen.
$s = null;
$r = isset($s);
var_dump($r); //-> FALSE
var_dump($s); //-> NULL
var_dump(in_array('s', array_keys(get_defined_vars()))); //-> TRUE -
cucka
addikt
válasz alitak #12726 üzenetére
Az első azt mondja, hogy nem tud csatlakozni a szerverhez. Ellenőrizni kell, hogy egyáltalán fut-e azon a szerveren az adatbázis és hogy a tűzfalban engedélyezve van-e a kapcsolat (kifele és befele is, nem elfelejtve, hogy melyik portról van szó).
A második azt mondja, hogy a PDO nem találja a megfelelő adatbázis drivert, szóval lényegében el sem jut oda, hogy megpróbáljon csatlakozni. -
cucka
addikt
válasz Peter Kiss #12797 üzenetére
Minden byte memória számít, mint ahogyan minden processzoridő.
Szerintem meg ami igazán számít, az a programozó ideje. Tehát kétszer is gondold meg, hogy tényleg megéri-e kevésbé jó minőségű, nehezebben érthető kódot írni és erre pazarolni az idődet pusztán azért, hogy megspórolj 5 ms-t oldalletöltésenként. -
cucka
addikt
Ha 10 milliós oldalletöltésed van, akkor a teljesítmény problémák elsősorban az adatbázis oldalon fognak előjönni, esetleg rosszul implementált algoritmusoknál, vagy olyan helyzetekben, amikor hiányzik egy jó cache.
Ilyen baromságokkal, hogy most az include vagy a require_once gyorsabb, sehol, semmilyen környezetben nem érdemes foglalkozni. Ha ott tartasz, hogy ezen múlik a programod teljesítménye, akkor gyenge a vas, erősebbet kell venni és kész. Nem mellesleg a vas olcsóbb, mint fizetni hónapokig egy programozót, hogy ilyen, ezredmásodperc töredékét jelentő dolgokra vadásszon.[ Szerkesztve ]
-
cucka
addikt
Arról van szó, hogy egy webalkalmazásnál a require_once és az include közötti teljesítmény különbségnek (meg a többinek, ami a topikban előjön) olyan minimális impaktja van, hogy egész egyszerűen nem érdemes vele foglalkozni.
A Forma1-el ellentétben a webfejlesztés nem verseny, a cél nem az, hogy a weboldal a lehető leggyorsabb legyen (mert akkor első körben a php-t kéne lecserélni mondjuk c-re), hanem hogy elég gyors legyen.[ Szerkesztve ]
-
cucka
addikt
Nem cél a gyors website? Elég sok irodalom van fent arról, mikor elemzik, hogy 100-200ms mennyit jelent értékesítési szempontból
Ezt a célt viszont nem úgy fogod elérni, hogy lecserélgeted a require_once-t include-ra, meg kicseréled a ?: operátort if-re. Értem én, hogy gyorsabb, de
1. A require_once pont azért lassabb, mert több funkciót lát el, amely funkciókra szükség van.
2. Én még nem láttam olyan projektet, ahol megkövetelték volna, vagy időt adtak volna arra, hogy ilyesmivel szarakodjunk.
3. Nem igazán jellemző, hogy nagy oldalaknál a php alkalmazásszerver lenne a szűk keresztmetszet, plusz ezt a részt elég jól lehet skálázni.Szóval valóban, elméletileg igazad van, tényleg lehet ilyen 2ms-okat gyorsítani, ha ilyesmivel foglalkozol, a valóság és a tapasztalat viszont az, hogy ilyen értelmetlen optimalizálásokkal nem éri meg foglalkozni és ezért senki nem is teszi.
[ Szerkesztve ]
-
cucka
addikt
válasz fordfairlane #12843 üzenetére
Igen, plusz a PHP jól skálázódik. Lehet elé rakni load balancert, szétdobhatod akárhány alkalmazásszerverre. Session kezelés a kérdéses, de arra meg ott a memcached, vagy más elosztott cache. Plusz html-t elég hatékonyan lehet cache-elni.
(#12842) lordjancso
De ha te tudod, hogy az az optimális megoldás, alapból azt használod nem?
Az optimális megoldás azt jelenti, hogy:
- a programod hibamentes
- a kód tiszta, könnyen olvasható, érthető
Ezek a fontos dolgok, amikre fókuszálni kell. Az teljesen irreleváns, hogy nyersz-e egy helyen fél ms-t vagy nem nyersz. -
cucka
addikt
válasz LonGleY #12942 üzenetére
A www-re váltást úgy kapcsolhatod ki, hogy törlöd a htaccess-ből azt a részt, amit ide is bemásoltál.
A php oldalon a framework valószínűleg onnan tudja, hogy a www aldomainre irányítson, hogy van egy konfigurációs opciója, ahova meg van adva. Nézd meg az alkalmazás konfig file-ját. -
cucka
addikt
Egyszerűbb talán, de jobb semmiképp.
A mana érték egy játékban sokszor frissül, ergo rengeteg olvasási művelet lesz. Továbbá biztosítani kell, hogy ez esetben óránként (vagy akármikor) csak és kizárólag egyszer fusson le, ezt nem teljesen triviális jól megcsinálni.
A cron pedig simán futhat akár 30 másodpercenként is. Továbbá a cron az maga egy daemon, ami pont arra van, hogy megoldja ezt a problémát, minek erre fejleszteni egy másik daemont?[ Szerkesztve ]
-
cucka
addikt
Jah, épp ezért lehetne megoldani egyszerűen, hogy ha belovassuk akkor már a jó értéket jelentítsük meg
A cron lényege, hogy valamit időzítve futtasson, mondjuk jelen esetben egy írási műveletet. Ettől te még akárhányszor kiolvasod, a helyes értéket fogod kapni, a frissítés ugyanis nem az olvasások számától függ, hanem az eltelt időtől.épp ezért irtam, hogy el kell tárolni egy utolsó frissitést plusz egy mana/h-t és nem is kell frissiteni feltétlenül.
Lehet így is, csak fölösleges minden egyes olvasási műveletnél lefuttatni az ellenőrzést, hogy kell-e frissíteni, tekintve, hogy az olvasások száma várhatóan sokkal nagyobb, mint az írásoké. Plusz ez web, itt több szálon történik a dolog, tehát lock-okat is kell alkalmazni, szóval tovább rontod az alkalmazásod teljesítményét.
Van egy ütemezett feladat, ennek futtatására van standard módszer (cron). Miért kéne ehelyett egy bonyolultabb és lassabb megoldást alkalmazni? (Annak eldöntése, hogy kell-e frissíteni, az minden, csak nem atomi művelet, ezért kell gondolni a párhuzamosságra is)Alapból nem, de nyilván megoldható.
Ok, akkor 1 percenként, na .Ha már feltételezem a LAMP környezetet akkor miért ne? Sokkal jobban illeszthető a környezetbe és egyszerűbben is konfigolható. ( a futás gyakoriságától kezdve a kiépitett logolásig) .
Miért, egy cron által meghívott php script miért nem illeszthető jól bele a környezetbe?[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #12993 üzenetére
Először is szögezzük le, hogy alapnak veszem, hogy egy játéknál nem oldal újratöltéssel oldjuk meg a kliensoldali frissítéseket, hanem ajax-al. Játékról van szó, tehát rengeteg request-el lehet számolni.
A dátum kiolvasása, összehasonlítása és az új mana érték beírása valóban nem erőforrás-igényes, viszont:
- Távolról sem nevezhető atomi műveletnek, tehát valamilyen lock-ot kell használj, ami viszont nagyon is erőforrás igényes. (Leginkább azért, mert az összes többi folyamat, ami ugyanazt az erőforrást használja, várni fog a lock miatt)
- Ahhoz, hogy a kliens nézőpontjából a mana érték frissítése úgy tűnjön, mint egy ütemezett feladat, minden egyes request-nél az összes játékos manáját ellenőrizni kell és frissíteni. Ez az összes olyan requset-re igaz, ahol a mana szerepel az adatok között. Felszorzod az ellenőrzés időigényét a játékosok magas számával, hozzáveszed, hogy elég sok request lesz, majd hozzáteszed, hogy minden egyes ellenőrzésnél lockolod az erőforrást, amire a többi request várni fog.Az eredmény az lesz, hogy beraktál egy k*rvanagy aknát a forráskódodba, ami akkor fog robbanni, amikor a júzereid száma elkezd nőni. A rendszered szép egyenletesen fog skálázódni egészen addig, amíg a request-ek száma túl kicsi ahhoz, hogy a lock komoly fennakadást okozzon, efölött pedig hirtelen és drasztikusan fog lecsökkenni a teljesítménye.
Ja, és ezt az egész baromságot pusztán azért, mert valamilyen hülye okból kifolyólag nem vagy hajlandó arra, hogy az ütemezett feladatot a pontosan erre a célra kitalált feladatütemezővel futtasd. Most komolyan, ez miért éri meg bárkinek?
(#12997) oleslie
Miért kell túlbonyolítani cron-al, ami nem mindenhol elérhető?
A cron mindenhol elérhető. Linuxon, Unixon, OSX-en mind alapból ott van, Windows-on szintén, csak ott máshogy hívják.
Ahol nem elérhető a cron, azok a kétpálcás php webhosting megoldások, de hadd ne ez legyen a mérce.[ Szerkesztve ]
-
cucka
addikt
válasz lordjancso #13003 üzenetére
Az ütemezett feladatot feladatütemezővel futtatjuk, mert egyrészt pont erre találták ki, másrészt mert ez megkímél egy csomó jövőbeli problémától. Semmilyen komoly érv nem szól amellett, hogy ne így tegyük, különösen annak fényében, hogy az alkalmazáslogika lényegében ugyanaz bármilyen esetben. Ha gondoljátok, akkor fűrészelhetitek a fingot ebben a témában tovább, én kiszállok.
(#13004) oleslie
Egy valamire való hosting szolgáltatónál az ütemezett feladatok futtatása megoldható. Nyilván nem fogod megengedni a júzernek, hogy turkálja a crontab-ot, de vannak erre UI eszközök, vagy megoldhatja egyedi kérésre a rendszergazda, teljesen mindegy.
(És ha szar a kód és beakasztja a szervert, akkor teljesen mindegy, hogy az cron-ból futtatva vagy http request következményeként fogja beakasztani.) -
cucka
addikt
válasz Sk8erPeter #13008 üzenetére
Jókat írsz, egy apróság kivételével: a manafrissítés tekinthető egy tranzakciónak, ami a következő elemekből áll:
- dátum kiolvasása
- dátum ellenőrzése/összehasonlítása
- mana frissítése, ha szükséges
A lock a tranzakció elején jön létre és a végén szűnik meg. Tehát írási művelet híján sem fogod tudni kikerülni a lock létrehozását és törlését, így a megoldásod overhead-je ígyis-úgyis a request-ek számával lesz arányban.A lock természetesen akkor is szükséges, ha cront futtatsz, az előny abban áll, hogy az, hogy hányszor fut le a szkript egy konstans és nem függ semmilyen más külső tényezőtől (pl. a http requestek számától)
[ Szerkesztve ]
-
cucka
addikt
válasz #68216320 #13062 üzenetére
Igen, ini_set, amennyiben nincs kikapcsolva a szerveren.
Változót értékadás nélkül nem tudsz létrehozni.(#13064) tildy
altalaban mondjuk nem kell, de ha fuggvenyt irsz, neha erdemes odairni, milyen bemeneti paramot varsz
Jó ötlet, sajnos primitív típusokra ez nem működik.[ Szerkesztve ]
-
cucka
addikt
válasz H.O.D. #13119 üzenetére
Igazából a probléma, hogy a kódod tele van OOP kulcsszavakkal, csak jól láthatóan nem igazán tudod, mire használd ezeket.
Egyrészt, amit írsz, az nem OOP kód, lényegében egy namespace-t készítesz egy osztályba csomagolva. Ennyi erővel akár használhatnál namespace-t is.
A másik, hogy a kódodból és a hosszászólásodból jól látszik, hogy az alapvető OOP-s fogalmak hiányoznak, tehát első körben javaslom, ezeket pótold be. (Például a konstruktort nem manuálisan hívod, hanem példányosításnál fut automatikusan. Statikus adattagok konstruktorban történő inicializálása azt jelenti, hogy nem érted, mit jelent a static kulcsszó.). Nehéz úgy segíteni, ha nem egy bugot kell kijavítani, hanem ilyen alapvető gondok vannak a kóddal.[ Szerkesztve ]
-
cucka
addikt
válasz fordfairlane #13121 üzenetére
Én nem javasolnék singletont ilyen esetben. Meg úgy őszintén, jól el kell gondolkoznom, hogy mikor fordult elő utoljára, amikor singletonra lett volna szükségem. Attól, mert egy osztályból várhatóan csak egy példány lesz, még nem indokolt a singleton használata.
-
cucka
addikt
válasz H.O.D. #13126 üzenetére
Statikus adattagot így tudsz inicializálni:
class Test{
static $data = 5;
}Nyoévám me, példányosítással, de akkor hogyan?
A statikus adattagok/metódusok az osztályhoz köthetők, nem az objektumpéldányhoz. Tehát pont az a lényeg, hogy függetlenek attól, hogy létrejön-e akár 1 példány abból az osztályból vagy sem.arra gondoltam, ez megtörténik az osztály bármely metódusának/elemének használatakor.
A statikus adattag akkor jön létre, amikor az osztály kódját értelmezi a php.
Ezt próbáld meg megérteni: a statikus adattag az lényegében egy globális változó. A trükk, hogy becsomagolod egy osztályba, az osztály nevén keresztül tudod elérni, így nem szennyezed a globális névteret. Egy osztály, ami csak statikus dolgokat tartalmaz, az lényegében nem egy osztály, hanem egy névtér. Akkor használunk ilyet, ha
- a nyelv nem támogatja a névtereket (pl. régebbi php verziók)
- a nyelvben nincsenek globális változók (pl. java)__autoload()-dal töltöm be, ha abba teszek egy xy::__construct()-ot, az lehet megoldás?
Nem. Az autoload arra van, hogy megtaláld a hivatkozott osztály file-ját és include-old. A konstruktor meg az a speciális metódus, amely egy osztály példányosításánál fut le. A kettőnek semmi köze egymáshoz. -
cucka
addikt
válasz H.O.D. #13136 üzenetére
Tehát egy statikus osztálynak nincs is __construct metódusa,
PHP-ban nincs olyan fogalom, hogy statikus osztály. Felejtsd el.
Minden osztálynak van __construct metódusa. Ha te nem írod meg, akkor a PHP csinál neki egy alapértelmezett üres metódust.Szerintem fogj egy PHP-s könyvet, ami az OOP-ra van kihegyezve, és olvasd el. Továbbra is ott tartunk, hogy írsz valami kódot, amiben vannak OOP-s kulcsszavak, de az egésznek semmi értelme OOP szemszögből.
Egy Product osztály az OOP irányból nézve nem a termékekkel kapcsolatos segédfüggvények gyűjteménye, hanem egy termék reprezentációja a kódodban. Egy Product objektumban tehát nincs getProduct() metódus, mert maga a Product objektum a termék. Az adattagok a termék adatai, a metódusok pedig a terméken végezhető műveletek. Ezt figyelembe véve a kérdésed blődség, teljesen irreleváns, hogy statikus vagy nem statikus az a metódus, aminek semmilyen keresnivalója nincs a termék osztályban.
Persze, biztos össze tudsz kalapálni szaktudás nélkül is valamit, ami úgy-ahogy működik és vannak benne OOP kulcsszavak, csak nem ez a jó irány.
[ Szerkesztve ]
-
cucka
addikt
válasz Speeedfire #13176 üzenetére
Hogy lehet 2 rendszert összekapcsolni?
Nehezen. Vagy átalakítod az egyik adatbázist a másik formátumra, vagy készítesz egy köztes réteget, ami az egyik kérést átfordítja a másik rendszer számára.Mivel gyanítom, a két rendszer funkciólistája nem egyezik meg 100%-osan, mindkét megoldásban benne van a szívás rendesen, plusz mindkét rendszert tökéletesen ismerned kell.
[ Szerkesztve ]
-
cucka
addikt
válasz Speeedfire #13211 üzenetére
Mit jelent az, hogy a tömb értéke üres?
PHP-ban nincs olyan, hogy egy asszoc. tömb egyik eleme üres, valamilyen értéke kell legyen. Az üres elem megfelelője egy null érték lehet, ilyenkor az isset false-al fog visszatérni, viszont a tömb kulcsai között ott lesz az is, amihez a null érték tartozik. Tehát vagy isset()-el vizsgálod (ez nem "látja" a null értékeket), vagy mondjuk az array_key_exists() függvénnyel (ez pedig "látja"). Az empty() pedig egy teljesen elb*szott dolog, azt ne használd semmire.[ Szerkesztve ]
-
cucka
addikt
válasz Speeedfire #13213 üzenetére
Ezt nem igazán értem, eddig tömb indexekről volt szó.
Nem tudom sem azt, hogy mit ellenőrzöl, sem azt, hogy mi a célod az egésszel, vagy hogy mit miért iratsz ki, szóval próbáld ennek tükrében megfogalmazni a dolgokat . Kiiratást és html-t pedig kár idekeverni, annak, hogy a php hogyan kezeli a tömböket/üres elemeket/stb. az égvilágon semmi köze ehhez. -
cucka
addikt
válasz Speeedfire #13215 üzenetére
Ez szerintem így teljesen jó, a feltétel az if-ben ki fogja szűrni az üres stringet és a null elemeket.
Ha kicsit átrendezed a kódot, a data változóra nincs is szükség.(#13216) Rolly
CSV fileban az adat mező nem tartalmazhat újsor karaktert. Ha mégis erre van szükség, akkor ki kell escape-elni, ez esetben pedig nem okozhat gondot feldolgozás során.[ Szerkesztve ]
-
cucka
addikt
válasz Sk8erPeter #13221 üzenetére
Amúgy én úgy csinálnám, hogy az üres értékeket eleve kiszűröm a tömbből:
$specs = array_filter($specs, function($v){ return $v!=''; });
(Igen, ez lambda, szóval php akárhányas alatt nem fut)
Új hozzászólás Aktív témák
- EAFC 24
- VR topik (Oculus Rift, stb.)
- Politika
- NVIDIA GeForce RTX 4080 /4080S / 4090 (AD103 / 102)
- Samsung Galaxy S24 - nos, Exynos
- Folyószámla, bankszámla, bankváltás, külföldi kártyahasználat
- Autós topik
- Kerékpárosok, bringások ide!
- eMAG/edigital vélemények - tapasztalatok
- Az Apple megszerezné a klubvilágbajnokság közvetítési jogait
- További aktív témák...
- Panasonic Lumix DC-G9 (V-Log L kiegészítéssel, 4 akkuval)
- Commlite CM-EF-NEX Auto-Focus Adapter (Canon EF - Sony E)
- Üzletből, garanciával, legújabb Asus Vivobook 17" i7-1355U 10 mag 5GHz/16RAM/1TBSSD/17,3"FULLHD
- Üzletből, garanciával DeLL XPS 15 9500 i7-10750H 32GBRAM 1TBSSD/GTX1650Ti 15,6"4KTOUCH
- i5 12400f 3070 gamer pc
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: Ozeki Kft.
Város: Debrecen