Hirdetés
Új hozzászólás Aktív témák
-
cucka
addikt
Na most ha pl 20 ember chatel akkor ez mennyire terheli meg a szervert? Illetve webhosting szolgáltató hogy értékeli az ilyet, például alapból limitálva van a processzor időm és belassulhat az egész site emiatt?
Ha normálisan van beállítva a mysql, akkor a lekérdezések nagy részét cache-ből fogja lökni, meg amúgy is kis adatmennyiségekről van szó - tehát ha normálisan írod meg a php részét, akkor kb. észre sem lehet majd venni a szerver terhelést.ha valaki küld új üzenetet akkor és csak akkor a script kiküldené az összes aktív kliensnek, na de hogy oldom meg, hogy apache csak úgy küldjön adatot kérés nélkül a klienseknek
Ajax-al sehogy nem oldod meg, mert csak a kliens kérdezgetheti a szervert, ezért aszinkron. Azt hiszem az Operában van valamilyen technológia, amivel megoldható, de az Opera 1% körüli részesedése miatt ez kb. annyit sem ér, hogy utánanézzekEgyébként memory táblákkal szerintem fölösleges pöcsölni, mint ahogy file-ba mentéssel is. Chat log-nál sok sor lesz a táblában de mindegyikben kevés adat, ezért indexeléssel teljesen jól meg lehet oldani a dolgot. (pl. ha a kliens már úgy kérdezi meg a szervert, hogy az x. id-jú mezőtől kérem az adatokat, akkor onnan könnyű gyors lekérdezést írni)
Természetesen ha több száz felhasználós chat-et szeretnél, akkor oda el lehet gondolkozni más technológiákon (pl. java kliens és/vagy szerver oldalra)
-
#34784256
törölt tag
Köszi a választ, végülis ezt hoztam össze az ötletedből ( meg a google-ból ):
<script>
document.write('screen.Height/Width: x=' + screen.width + ' y=' + screen.height);
document.write('<a href="get_image.php?x=' + screen.width + '&y=' + screen.height + '">KLIKK IDE</a><br>');
document.write('window.innerHeight/Width: x=' + window.innerWidth + ' y=' + window.innerHeight);
document.write('<a href="get_image.php?x=' + window.innerWidth + '&y=' + window.innerHeight + '">KLIKK IDE</a><br>');
document.write('document.body.clientHeight/Width: x=' + document.body.clientWidth + ' y=' + document.body.clientHeight);
document.write('<a href="get_image.php?x=' + document.body.clientWidth + '&y=' + document.body.clientHeight + '">KLIKK IDE</a><br>');
document.write('document.documentElement.clientHeight/Width x=' + document.documentElement.clientWidth + ' y=' + document.documentElement.clientHeight);
document.write('<a href="get_image.php?x=' + document.documentElement.clientWidth + '&y=' + document.documentElement.clientHeight + '">KLIKK IDE</a><br>');
</script>Hálistennek minden böngészőben máshogy működik, úgyhogy végülis nem fogom használni
-
cucka
addikt
Nincs olyan, hogy állandóan, háttérben futó php script. Ha ilyesmit akarsz, akkor valamilyen nem scriptnyelvvel kell megvalósítani és gyakorlatilag kell írni egy kis saját webszervert hozzá.
A 20-30 másodpercenkénti lekérdezés fika, de ha gyorsítani akarsz a dolgon, akkor használj állandó mysql kapcsolatokat (lásd mysql_pconnect() ), ezzel elég sok időt tudsz spórolni.. -
Speeedfire
félisten
Valószínű prefork lehet, mert valóban nem fogadta el. Ellenben abba is hagytam a nagy erőforrás miatt az apache projektet. Lecseréltem lighttpd-re, ha a youtube-nak megfelelt akkor nekem is megfelel.
Fele annyit memóriát eszik jelenleg, a cpu meg meg sem mozdul 1 szál mellett.
Csak itthoni használatra kell, a router admin felületével szenvedek, na meg akarok 1-2 statisztiai oldalt készíteni.
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
Ja, ezzel jó lehet: [link].
Köszi!
Nem tudom, miért nem jutott eszembe, hogy mivel nem webszerveren keresztül futtatom a scriptet, nem állítódnak be a megfelelő változók...Ahtlon64+: na ez az argumentumos megoldás viszont nagyon melósnak tűnik. Ha tételezzük fel, lenne 30 site, annak mindegyikénél be kéne állítani a megfelelő argumentumokat, az annyira nem lenne szimpi. Persze ugyanúgy, mint a cURL-es megoldásnál, végig lehet rohangászni akár batch-fájlon keresztül az ütemezendő fájlokon, ciklussal, rögzített könyvtárstruktúra esetén, mindegyik szükséges változót beállítva, argumentumként átadva, de ennél a cURL-es megoldás szerintem ezerszer egyszerűbb.
Pl. konzolból futtatva, ha nem akarom, hogy bármit is írjon az stdoutra: curl example.com/cron.php. De köszi az ötletet!Sk8erPeter
-
modder
aktív tag
Az a baj még a "szeretnék megtanulni programozni" kérdésekkel, hogy sokan elfelejtik, hogy a programozás nem csak arról szól, hogy kódolok, és akkor ha elég sokat kódolok, akkor készen lesz és jó lesz. Ahogy a kovács szakma sem csak arról szól, hogy ütöm a forró vasat, és akkor jó lesz.
Nagyon sok munkát kell fektetni abba, -- amit már az előző hozzászólásomban meglebegtettem -- hogy jól meg tudd tervezni a kódod, és algoritmus érzék kell hozzá. Ezeket lehet fejleszteni. Ha két részre osztanám a programozói tudást: szintaxis+könyvtárak és tervezés+algoritmus, akkor a tanulásba beleölt idő nagy részét utóbbi kettő fogja kitenni. -- véleményem szerint
[szerk.]
és persze törekedni kell arra, hogy a források után angolul kutatunk, hiszen magyarul csak limitált forrás elérhető, főleg az újabb technológiákból.[ Szerkesztve ]
-
Lacces
őstag
Olyan furcsa működik...
Újra kreáltam. De most bele mentem az adatbázisba és ott. (Elsőnek még a főoldalon és ott adtam meg az adatbázist...)Jogoknál. van olyan, hogy típus:
- globális
- adatbázis-specifikus.
(mindkettő típus jelen van a felhasználónál)Mi a különbség kettőjük között?
Amikor létrehoztam a felhasználót, hogy csak Select, Insert és Update jogokat kapjon, akkor automatikusan megadta az összes jogot, az adatbázis-specifikus részben.
De kipróbáltam és ott is módosítottam S, I, U jogokra . És ugyanúgy jó. Működik. -
Speeedfire
félisten
Ohh, nem értem mit mondasz. De valóban, egy ciklussal kijjebb tettem és most okés.
'nap_1' => string '9:45-6:30' (length=9)
'nap_2' => string '7:15-5:30' (length=9)Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
MODERÁTOR
Akkor megválaszoltad. Pont ez a gond, hogy itt, így egy üres objektumot kapok vissza. Megfogalmazás, jobban nem tudtam, mint hogy semmi az amit kapok. Mit kéne akkor tennem, hogy keresés esetén false, legyen a visszatérés?
Lol. Megszámolom a sorokat
[ Szerkesztve ]
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
MODERÁTOR
Köszi a segítséget! Megoldódott.
$query->count() ezt rányomtam az objektumomra, majd megvizsgáltam ha igaz volt akkor visszadobtam, ha nem akkor elküldtem a false -t.
mobal,
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
-
-
cAby
tag
Sikerült megcsinálni, mostmár normálisan működik!
Mostmár csak annyi bajom lenne, hogyha olyan elemet akarok betenni kedvencnek, amihez görgetni kell lefelé az oldalon, akkor miután megnyomom, hogy kedvenc az oldal tetejére ugrik.Meg lehet azt csinálni, hogy az oldal állása ugyan az legyen, mint kattintás előtt?
-
Speeedfire
félisten
Aha, minden egyes ciklus lefutásnál meglestem és hát valóban, ő beállította magának, hogy ha ilyen sok van akkor ez biza update lesz.
A fene a p*ofáját, hogy ennyire okos.
Már csak meg kell neki mondani, hogy ez nem update, hanem insert lesz. Keresgélek, de szerintem menni fog.
Nem igazán tudom, hogy lehetne hozzáadni a modellhez, szóval...Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Speeedfire
félisten
Márpedig elég intelligens állat a yii.
Ha csak 1 fájlt akartam feltölteni akkor a model scenario értéke insert volt, ha többet akkor pedig update.
Most, hogy minden egyes ciklusban példányosítottam, jó lett.
Rá nem jöttem volna.Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
Érdekesség, hogy ez a szintaxis a PostgreSQL-lel való kompatibilitás miatt került bele:
SELECT Syntax - LIMIT clause
"For compatibility with PostgreSQL, MySQL also supports the LIMIT row_count OFFSET offset syntax."Egyébként:
"LIMIT takes one or two numeric arguments, which must both be nonnegative integer constants (except when using prepared statements).
With two arguments, the first argument specifies the offset of the first row to return, and the second specifies the maximum number of rows to return. The offset of the initial row is 0 (not 1):
SELECT * FROM tbl LIMIT 5,10; # Retrieve rows 6-15
To retrieve all rows from a certain offset up to the end of the result set, you can use some large number for the second parameter. This statement retrieves all rows from the 96th row to the last:SELECT * FROM tbl LIMIT 95,18446744073709551615;
With one argument, the value specifies the number of rows to return from the beginning of the result set:SELECT * FROM tbl LIMIT 5; # Retrieve first 5 rows
In other words, LIMIT row_count is equivalent to LIMIT 0, row_count."A phpMyAdmin is utóbbi szintaxist használja.
Persze teljesen jó az említett OFFSET-et tartalmazó szintaxis, meg talán kifejezőbb is a query általa, de említésre méltó az idézett változat is, hátha valaki azt ismeri jobban - MySQL query-knél én utóbbit gyakrabban szoktam látni kész kódokban (nyilván a másikra is bőven akad példa).[ Szerkesztve ]
Sk8erPeter
-
MODERÁTOR
Most úgy van, hogy első körben ellenőrzöm a kérelmet, tehát, hogy a controller és az akció megvan -e. Utána pedig magát a tartalmat, pl.: egy bejegyzés megtalálható e. Ebben a két külön esetben dobok egy 404 -et ha nincs.
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
Sk8erPeter
nagyúr
"Kivételkezelést akkor érdemes használni, amikor egy mély hívássorozat alján keletkezik valahol egy kivételes hiba, és ezt sokkal fentebbi függvényben akarod lekezelni. Ilyen például az adatbázis absztrakciós rétegekben egy mysql hiba, ami, ha jó a kódod, ritkán fordul elő, és általában elég csak annyira foglalkozni vele, hogy loggolod."
1.) Nem értem, ez miért változtat azon az állításomon, hogy átláthatóság szempontjából mindenképp jobb. Azt hittem, a privátban kitárgyalt kód meggyőző volt ennek alátámasztására.
2.) A MySQL-hiba jobb esetben - pl. elég ritka, hogy az adatbázishoz tartozó service lehal - valóban ritkán fordul elő. De azért ne csináljunk úgy, mintha csak ennyire szélsőséges esetekre lehetne alkalmazni a kivételeket."Ha a kivételkezelést általános programozási gyakorlattá teszed, annak megvan az a hátránya, hogy később, ha ránézel a kódra, nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod (ahogy említetted, amíg ténylegesen nem történt ilyen exception, akkor stacktrace), és amikor refaktorálod a kódot, fogni fogod a fejed."
Ezt pontosan azért nem értem, mert az előző hozzászólásomban éppen azt hoztam fel a kivételek egyik előnyeként, hogy a lehető legegyszerűbb kideríteni, honnan származik a kivétel, és naplózás esetén nálam legalábbis alap, hogy a kivételek forrását is naplózom: melyik fájlban keletkezett a kivétel, melyik függvényben, a fájlnak pontosan melyik sorában, mikor, stb. Ezeket az exceptionökből a lehető legegyszerűbb feladatok egyike kideríteni, így pontosan ezért nem értem, miért is lenne érv jelen esetben az, hogy "nem biztos, hogy fogod tudni, a kivételedet hol dobod" - dehogynem, pontosan fogom tudni: lásd pl. getFile(), getLine(), getTrace() vagy épp getTraceAsString() függvények...Régen, mielőtt a kivételkezelést egyáltalán alkalmaztam volna, pontosan az volt a bajom, hogy sok esetben nehezen visszakövethető, hogy konkrétan hol is történt a hiba, és milyen jellegű is volt. Most meg pl. ránézek a naplóra, és egész pontosan meg tudom nézni, hol és mi is történt, valamint a kivétel mikor keletkezett.
"Ha az osztályodat majd újra fel akarod használni, nem szabad megfeledkezni arról, hogy milyen kivételeket dobhat. Amíg jól van dokumentálva a kódod, addig nem biztos, hogy fejtörést fog okozni, de ha már kevesebb időt töltesz a dokumentálással, valahol újra fel akarod használni a kódodat, szintén fogni fogod a fejed, mert fejlesztés során olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak, ahogy az osztályod egyre többet tud."
Kezdjük azzal, hogy szerintem a rossz dokumentáció egyik esetben sem segít a későbbi fejlesztésekben, ebből a szempontból teljesen lényegtelen, hogy most kivételeket dobálsz, vagy az adott esetben túlságosan is kövérre hízó, macerás if-else blokkokat alkalmazod.
Ha pedig említetted az error tömbök visszaadását: ha épp a szar dokumentáció és az újrafelhasználás a példa, akkor hogyan emlékezz vissza, hogy mi is volt a megfelelő hibakezelési mód? Pl. hogy az error tömböd milyen formában érkezik, vegyünk egy példát:
$functionReturnValue = $myClass->myMethod();
if( $functionReturnValue['status'] == FALSE ){
......
}
else {
....
}Aztán kiderül, hogy basszus, nem is $functionReturnValue['status'] a megfelelő vizsgálandó visszatérési érték indexe, hanem mondjuk $functionReturnValue['result'].
Ha viszont eldobsz egy kivételt a hiba forrásánál, az garantált, hogy itt minél előbb megtudod, hol keletkezett a hiba (pl. ha fent van egy Xdebug extension, akkor az még szép táblázatos formában ki is írja neked), és nem próbálod folytatni a programkódot a rossz visszatérési értékekkel, stb.De hogy még reagáljak arra is érdemben, hogy "olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak":
erre röviden az az egyszerű reakció, hogy ha az egész try-catch blokkod legvégére a kivételosztályok ősosztályának elkapását is elintézed, akkor nyilván nem mondok újat azzal, hogy így minden kivételt elkapsz, azt is, ami specifikusan nem volt lekezelve.
Ezeket pedig szintén naplózhatod, és akkor tudod, hogy még milyen kivétel nincs lekezelve.
Pl.:
try {
$stuff = new MyClass();
// exceptiont fogsz eldobni, mégpedig így:
// throw new MyNewException( 'asdasd' );
$stuff->myMethod();
} catch ( MyOldException $e ){
...
} catch ( AnyOtherException $e ){
...
} catch ( Exception $e ){
...
// itt elkapod a többit!!!
}Így tehát azt az esetet is lekezelted, amit előre nem láttál - a másik esetben sokkal nehezebb ennyire általános receptet adni az "egyéb" kategóriába eső hibák megfelelő kezelésére és naplózására.
Sk8erPeter
-
Sk8erPeter
nagyúr
"nem talál egy oldalt, akkor exception-t dobjon, amikor az egy belekalkulált működés, szerintem; az exception számomra egy kerülő megoldás, ahol ide-oda ugrálunk a kódban.
Itt tulajdonképpen arról van szó, hogy milyen 'hiba' vagy kivételes eset fordulhat elő többször, amire számítani kell, és mi a valódi hiba (ez utóbbi esetben érdemes kivételt használni). Nem láttam még olyan keretrendszert, ami kivételdobásokra alapozta volna a működését."Akkor az általad használt Kohana egy szar, mert pl. minden egyes HTTP status code-ra létezik benne exception?
Vegyük az említett példának megfelelőt: HTTP_Exception_404.
Aztán itt bal oldalt láthatod szépen a többit is, ami pl. validálás kapcsán említésre méltó, az a Validation_Exception.
Aztán ott a Kohana_Exception, a Kohana_Request_Exception és a Kohana_View_Exception.Azt hiszem, abban egyetérthetünk, hogy valószínűleg a Kohana alapvetően nem átgondolatlan struktúrára épül.
Hadd említsek egy másik példát: remélem abban is egyetértünk, hogy a Symfony nem egy tákolmány keretrendszer, és valószínűleg nem érdemtelenül népszerű.
Egy - számomra legalábbis - elég meggyőző érv még a témában:
[link]
"Symfony really relies on PHP exceptions for error reporting, which is much better than the way PHP 4 applications work. For instance, the 404 error can be triggered by an sfError404Exception."Akkor most már láthattál egy keretrendszert, ami kivételdobásokra alapozta a működését.
Sk8erPeter
-
PazsitZ
addikt
Azt most már tudjuk, mi a szar, de a temérdek jobb, átláthatóbb, refaktorbarát alternatív javaslatot még nem találtam meg a hsz.-eidben.
Aki pedig azt állatja, hogy minden függvényt azzal kezd, hogy /** */, az biztos ráér programozni
Az annotáció pedig megkönnyíti a további fejlesztést, az autocomplete felhasználás során.
Mert meg sem kell nyitnod függvényt tartalmazó fájlt tudni fogod a be-ki-meneti paramétereket, típusukat és kivételeket, amit dobhat.
Ehelyett ha lehagyod, jobb esetben tízszer nyithatod a fájlt és böngészheted a függvényt, mit miként adj át és várj viszont. Utóbbi minden bizonnyal gyorsabb.A tömbös indexes hibakezeléses megoldásos pedig aranyos, de ne akard már itt megmagyarázni, hogy ez a frankó, mert már nem tudom, hogy sírjak vagy nevessek.
[ Szerkesztve ]
- http://pazsitz.hu -
-
Sk8erPeter
nagyúr
"Azt hiszem érthető voltam, de akkor leírom érthetőbben: amikor refaktorálod (átírod, javítod) a kódot, nem fogod tudni, hol dobtad az exceptiönt, amíg tényleg nem dobtál egyet.
Például van a form validáló osztályod, ami dobhat 4féle exception-t, te meg szeretnéd tudni, hol dobja, akkor legjobb esetben is ctrl+ffel keresel rá. Ha pedig a stacktrace-t akarod használni, ahhoz generálnod kell egy olyan hibát, ami ezt az exceptiont dobja."
Azt hiszem, én is érthető voltam, amikor leírtam, hogy egy általános jellegű Exception elkapásával minden kivételt el lehet kapni, és a kivétel keletkezésének módjáról mindent meg lehet tudni. Ha azt szeretnéd megtudni, hol dobja, és egész addig nem tudod, amíg nem keletkezett egy pontosan olyan specifikus hiba, akkor valóban az a megoldás létezik, hogy generálsz olyan hibát, vagy rákeresel. És? Nem értem a logikádat, ez miben tér el attól, ha te mondjuk ragaszkodsz a hibatömbös megoldásodhoz. Ha a hibatömbös hibakezelés forrásaira szeretnél rátalálni, akkor még a klasszikus exceptionökre vonatkozó backtrace-es megoldás sem áll a rendelkezésedre, de szerencsére mivel a PHP elég kényelmes nyelv, még erre is igénybe lehet venni egy plusz segítséget (kicsit mintha a bal kezeddel vakarnád meg a jobb füledet a tarkód mögül): debug_backtrace().
Még egy dolog: ha definiálsz saját exception osztályokat, akkor azoknak többnyire elég normális, egyedi neve van.
Pl. legyen épp ValidationException a neve.
Mondjuk ennek eldobása egy egyszerű globális fv.-en belül így néz ki:function blabla(){
// .......
if( $hiba_van ){
throw new ValidationException( 'ezért meg azért' );
}
// .......
}a Te megoldásod meg valami ehhez hasonló:
function blabla(){
// .......
if( $hiba_van ){
$errorArray['status'] = FALSE;
$errorArray['msg'] = 'ezért meg azért';
return $errorArray;
}
// .......
}Ha már Te mindenhol az ugyanilyen jellegű hibatömbös megoldást alkalmazod, és Ctrl+F-es módszer, akkor szerintem több esély van gyorsan megtalálni a throw new ValidationException részt.
De a tömbös megoldást továbbra sem kínál beépítetten backtrace megoldást."Nyilván, ha valaki idiótán programoz, arra nincsen mentség."
Ez önmagában igaz. De arra, amire reagáltál, ez valahogy kicsit sántít. Pl. ha már újrafelhasználásról beszélünk, nem tudom, valakinek miért kellene kitalálnia, hogy a kódot elkészítő illető pontosan milyen tömbindexeket használt. Ja, hát nézze át az egész kódot, ha már szar a dokumentáció, hisz' bár a függvényt készítő ember nem ért rá odaírni három sort, ha három kivételt dob a fv. elejére, de a kódot felhasználó illető majd nyilván rá fog érni átnézni a komplett kódot. Itt pedig ez az indexeléses módszer nem biztos, hogy olyan intuitív megoldás, hogy ránézésre, már az első példa láttán lehet tudni, hogy mi is a helyzet többféle alkalmazásnál.Sk8erPeter
-
Sk8erPeter
nagyúr
Ez sajnos nem volt egy túlzottan érdemi reakció.
Pl. miután kijelentetted, hogy nem igazán tudsz olyan frameworkről, ami exceptionökre építené a működését, megmutattam a Symfony-t, mert próbáltam érdemben vitatkozni, nem csak általánosságban beszélni. A Symfonynál meg most hirtelen nem tudom, milyen meggyőzőbb frameworköt kellene neked mutatnom, hogy az exceptionök létjogosultsága valamennyire világosabbá váljon.Egyébként a gyakorlati ellenpéldákat én is hiányolom, ha már kritizálod azoknak a programozási szokásait, akik a kivételek használatára építenek. Azt érezteted, hogy a kivételekre építés rossz programozói gyakorlat (tehát valamit rosszul csinál az, aki erre alapozva kezeli a program menetében felmerülő hibákat), miközben nálunk okosabb emberek komplett keretrendszert építettek erre. Én jobban hajlanék az érveid elfogadására, ha alátámasztanád őket konkrét példákkal - attól függetlenül, hogy "minden probléma egyedi". Igen, a formvalidálás problémája is egyedi, meg az is, hogy hogyan kezelj le egy 404-es hibát. Én mindkettőre elmondtam a saját megoldásom (privátban komplett pszeudokódot is mutattam, ezt alátámasztandó), úgy tűnt, belátod az átláthatóság előnyeit kivételkezelésnél. De saját példát is mutathatnál, mert én nyitott vagyok más megoldásokra, ha az érdemi javulást hozhat a kódban.
Ha valaki vitatkozik az álláspontoddal, nem azért teszi, mert feltételezi, hogy hülyeségeket beszélsz, épp az a jó szakmai vita ismertetőjele, hogy szakmai szempontokkal győzzük meg egymást (én erre törekszem), nem pedig bezárkózásunknak adunk jelet.
A magasabb szintű programozói nyelvekben meg a kivételkezelés nagyon nem ördögtől való.
Kicsit számomra is olyan ez a vita, mintha arról beszélnénk, hogy mennyire nem éri meg objektumorientáltan programozni, mert az akár lassulást is hozhat. Ugyanez igaz C++-ra is: az OOP-s megoldás továbbra is lassabb marad, ezzel nyilván nem mondtam újat.
De ettől még megkérdőjelezni az OOP előnyeit nem érdemes, mert tény, hogy az átláthatóságban, követhetőségben, az objektumok logikai összetartozásában, kapcsolódásában, annak szemléltetésében, az emberi gondolkodáshoz való hasonlóságában, stb. annyi előnye van, ami miatt bőven van létjogosultsága (ez sem új, de elmondom).
Ettől függetlenül mégis hosszas érvek vannak, amik miatt pl. a Drupal még mindig nem állt át a teljes objektumorientáltságra: Drupal programming from an object-oriented perspective. De ennek nagyon sok történelmi gyökere is van (PHP 4 miatti kompatibilitás - most már erre nem terveznek).Sk8erPeter
-
Sk8erPeter
nagyúr
Igen, és itt aztán a visszatérési értéket megint csak vizsgálni kell, és akkor visszajutottunk ugyanoda, ahonnan elindultunk.
Vegyük azt a megközelítést, amit Te mondasz, tök egyszerű példával. Itt beletettem még annyit, hogy két különböző paraméterrel hívom meg a logErrors függvényt, ez is szándékosan jó butított példa. A syntax highlighting miatt inkább felraktam pastebinre:
http://pastebin.com/KxH2Fmk9Na, akkor vegyük azt a megközelítést, amiről én beszélek (bár privátban hasonló jellegű megoldást mutattam), aktualizálva a példához:
http://pastebin.com/PVKe4uNANem tudom, ki hogy van vele, de nekem a második, háromsoros kód jobban áttekinthető. A korábbiaknál meg annyi van bent pluszban, hogy van két saját kivételosztály, ami tömböt is tud fogadni.
(#9007) modder : azzal egyetértek, hogy nem mindig egyértelmű, mire szabad/érdemes exceptiont használni. De pl. egy form injection probléma tipikusan olyan, ami miatt érdemes lehet exceptiont dobálni. Ahogy egy adatbázis-kapcsolódás is.
A 404-es hiba meg ilyen alapon ugyanúgy gyakran előfordulhat, ha valaki elcseszi a keresett URL-t, esetleg van hivatkozás Google-ön keresztül olyan oldalra, amit azóta már töröltek, vagy magán az oldalon van rossz hivatkozás van; de tulajdonképpen ezt is meg lehetne oldani sima error tömbökkel, ahogy az összes többi hibát is. Tulajdonképpen mindkettő megoldás alkalmazható minden problémára, kérdés, mire melyiket érdemes - bár az valóban érdekes felmérés lehet, mennyit ront a GYAKORLATBAN a teljesítményen az, ha valaki exceptionökre áll rá.
Ha valaki tud ilyen felmérésről, ne tartsa magában!===
(#9008) Athlon64+ : nem is kell "mindenhol" kivételeket hajigálni.
[ Szerkesztve ]
Sk8erPeter
-
Sk8erPeter
nagyúr
Na ja. Asszem így már nagyjából összeért az álláspontunk. Csak kár, hogy eddig is PHP-ról beszéltünk (nem C-ről és nem is C++-ról), így egy kis időt megspórolhattunk volna.
Miután legalább egy órát elb@sztam azzal, hogy a kivétel vs. nem kivétel témában olvassak, olyan remek újdonságra jutottam, hogy nincs jó megoldás. Mintha ezt eddig nem tudtuk volna.
A lényeg: rengetegen amellett állnak ki, hogy a kivételeket tényleg csak kivételes esetekben érdemes dobálni (egyet muszáj idéznem: "Exceptions should be a truly rare thing, UserHasDiedAtKeyboard type situations." ), sokan mások meg azt állítják, hogy ez totálisan attól függ, hogy mennyire a teljesítményt helyezed a középpontba pl. a gyorsabb átláthatóság előnyeivel szemben. Kábé ugyanott tartok, mint ahonnan mi is elindultunk, annyi különbséggel, hogy csomó időm ráment, és hogy legalább megtudtam, hogy UNIX-nál van olyan hiba, hogy Printer on Fire.
Mivel én az eddigi kivételdobálásoknál PHP esetén semmiféle észrevehető teljesítménybeli különbséggel nem találkoztam, asszem nem fogom átírni a kódjaimat úgy, hogy hibatömbbel térjek vissza, és a kódolási szokásaimat sem fogom rossznak tekinteni a vitánk miatt.
Egy C++-alkalmazásnál már nagyon is megfontolandó az, amiről beszéltünk. De természetesen az már másik fórumtémába tartozik.
Egyébként magas szintű nyelvek (pl. C#) előszeretettel alkalmaznak kivételeket különböző esetekre, nem véletlen, hogy számtalan előre definiált exception class van, amiket akár "helyben", egy rövidebb, beágyazott try-catch blokkban is el lehet kapni (ugyanez igaz általunk definiált exceptionökre is), így meg feltételezem, kisebb teljesítményvesztéssel kell számolni.Szerk.:
A TÉNYLEGES, gyakorlati teljesítményveszteségről viszont normális áttekintő cikket, méréseket továbbra sem találtam, csak a szájkoptatást, hogy csúnya nagy költségei vannak, pedig tényleg nagyon érdekelne, egy alkalmazásnál a két eset összehasonlításakor miféle teljesítménykülönbségekkel kell számolni.[ Szerkesztve ]
Sk8erPeter
-
Speeedfire
félisten
Mi nem működik?
mobal: A fejlesztőknek ehhez nincs beleszólása. Ezt a google csinálja meg neked, ha authority site lesz az oldalad, ami nagyon sok munka.
Jól kell seo-zni az oldalt, de még akkor sem biztos a siker. Az enyém is csak mini authority site.Nálam pl ilyen.
[ Szerkesztve ]
Fotóim https://fb.com/toth.szabolcs.art || IG: http://instagram.com/_tothszabolcs_ || Weblapom http://szabolcs-toth.com
-
Sk8erPeter
nagyúr
Készítettem neked egy megoldást:
<?php
$evil = "function lp0(){echo base64_decode('UmVhZCB0aGF0IG1vdGhlcmZ1Y2tpbmcgbWFudWFsISEh');}lp0();";
eval($evil);Ha kíváncsi vagy a kimenetre: http://ideone.com/dfDiG.
Sk8erPeter
-
PazsitZ
addikt
-
MODERÁTOR
Szét spammellek! Na igen. Az a gond, hogy átirányít majd vissza és semmi. Azt észrevettem, hogy más code -dal lök vissza mint amit kaptam.
Tessék a kód:
<?php
$fb = new FacebookConnect();
if(!empty($_POST["fb"])) {
$user = $fb->get_user();
print_r($user);
}
?>
<html>
<head>
<title>Regisztráció</title>
</head>
<body>
...Ez a lényeg, a body után pedig befejezem a nézetet. Semmi komolyság egyenlőre, csak tesztelgetés
"Ott szimatol a sarkadban vasfogait csattogtatva, minden egyes hétköznapod: kirúzsozott medvecsapda."
-
Sk8erPeter
nagyúr
Igen, és még annyit hozzátennék, hogy ha nem akar egy gány fájlba írós megoldást választani, aminek eredményeként az adatok jóval nehezebben kezelhetőek, ergo a szavazás aktuális állása jóval nehezebben követhető, akkor elengedhetetlen egy tök ingyenesen elérhető és könnyen kezelhető adatbázis (MySQL).
Vagy legalább ha MySQL-szerver fenntartására nincs mód, akkor már SQLite, vagy hasonló.
Mondjuk ha már webes felületen szavaznak, akkor miért is ne lehetne mód telepíteni egy MySQL-szervert...Szerk.: meg szerintem vagy keressen egy normális scriptet, vagy annál még az online, ingyenesen megtehető szavazások is jobbak. Pl. most ezt találtam: [link]
[ Szerkesztve ]
Sk8erPeter
-
modder
aktív tag
ha még mindig nem megy, próbáld meg a webszerveren állítani az output buffert
pl Apachenál SendBufferSize 0Amúgy ha apache modulként van fönt a PHP, el tudom képzelni, hogy automatikusan flusholja az apache output bufferét is. (nálam működött ez annó). Ha nem apacheot használsz vagy fastcgi van, akkor lehet, hogy nem ilyen egyszerű a helyzet. mindenképpen nézz utána a webszerver output bufferének is.
(sőt, akár még a böngésző is bufferelhetni, azt mondják )
[ Szerkesztve ]
Új hozzászólás Aktív témák
- Redmi Note 13 Pro 5G - nem százas, kétszázas!
- Bambu Lab 3D nyomtatók
- Automata kávégépek
- Elektromos cigaretta 🔞
- Samsung Galaxy S23 Ultra - non plus ultra
- Politika
- AMD Ryzen 9 / 7 / 5 7***(X) "Zen 4" (AM5)
- Futás, futópályák
- Tőzsde és gazdaság
- Következő lett a következő HarmonyOS verzió neve
- További aktív témák...
- Figyelőkamera (autóba, lakásba) + 32GB SD kártya
- Raptor PC / Xeon E5-1660 - 16 szál / RTX 4060 / 64GB RAM / 2db Intel Ipari SSD / Foxpost
- Samsung telefonok felvásárlás! +36203990877
- Apple készülék felvásárlás azonnal! Iphone, Ipad, Apple Watch, MacBook +36203990877
- RÉSZLETFIZETÉS.SZLA.GAR. LENOVO LEGION SLIM 5 16AHP9 Ryzen 7-8845HS , RTX 4060 közel 3 év garancia
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest