- Yettel topik
- Samsung Galaxy S22 Ultra - na, kinél van toll?
- Magisk
- Mobil flották
- Egy szenzor, két zoomkamera: újraírta a Huawei a mobilfotózás történetét
- Bemutatkozott a Poco X7 és X7 Pro
- Xiaomi 11 Lite 5G NE (lisa)
- Samsung Galaxy A56 - megbízható középszerűség
- Google Pixel topik
- Samsung Galaxy A55 - új év, régi stratégia
Új hozzászólás Aktív témák
-
Gardaai
senior tag
-
DNReNTi
őstag
Igen, mindezt tudom. És közben meg is van a megoldás. Gyakorlatilag egész idő alatt - nincs erre szebb szó, bocsánat - saját magamat szopattam. Már a kezdettől fogva. Van egy Router nevű osztályom, gondolom a szerepét nem kell magyarázni. Ez az ami az URL paraméterek alapján a megfelelő oldalakat építi fel, illetve nem megfelelő kérés esetén hiba oldalra dob. Pl: egy nem létező favicon esetén is. No én voltam annyira ügyes, hogy ezt kikommenteltem a teszt miatt, ráadásul az index-be írtam magát a tesztet, mer már annyira bepukkantam.
Tehát a htaccess átirányított mindent az indexre ahogy addig is, de nem volt ami feldolgozza. Magyarul kezdettől fogva minden jól működött, egyszerűen csak láma voltam. 
-
DNReNTi
őstag
"Gondolom egyrételmű, hogy maga a probléma, hogy szar a htaccess-ed."
Igen, arra már rájöttem korábban: "Kiderült: hibás volt a htaccess-em".Egy másik szabály amivel szintén jó:
RewriteCond $1 !favicon.ico$"ha a kliens lekérdezi a favicont, az miért eredményezi egy php program futását"
Na igen. Csak arra tudok gondolni, hogy mivel maga a fájl nem létezik így a RewriteCond %{REQUEST_FILENAME} !-f szabály nem vonatkozik rá (hiszen az csak a létező fájlokra igaz, ha nem tévedek). Az ikon request valamiért 200-as HTTP statust kap. Azaz annak ellenére, hogy valójában nincs, így gondolom mivel a fentebb írt szabályon már túl van, és a szerver OK statust ad neki, így a htaccess átirányítja. Ilyet nem mostanában szívtam.Tehát a valódi kérdés inkább: miért ad a szerver 200-as statust egy nem látező fájlra?
Szerk:
A szerkesztett írás alapján kipróbáltam egy nem létező fájlra hivatkozva: ugyan úgy megszívat. -
#15296
Sk8erPeter
nagyúr
cucka
#15295
Sk8erPeter
nagyúr
Nem tudok vitatkozni. Amit viszont egyszerűen nem tudok elhinni, hogy hogy lehet - fórumos hozzászólások alapján - többéves tapasztalat alapján ilyen ostoba szar hibákon elvérezni, hogy nem veszi észre, hogy kliensoldalon rossz elemmel játszadozik. Ha gyorsan meg akarom tudni, hogy jó-e a selectorom, fogom, és bedobom a böngésző fejlesztői panel konzoljába a megfelelő szintaktikával, és egyből megtudom, hogy milyen elemeket kapok vissza... Ami még rosszabb, hogy arra se sikerült rájönni, hogy egyáltalán szerveroldalon vagy kliensoldalon van-e a probléma, ami megint teljesen triviális volt. De biztos majd egy spagettikód megoldja, keressünk hát gyorsan egyet!
Amúgy majdnem írtam, hogy tényleg szar, hogy a topicban nincsenek szakmailag érdekes problémák, de aztán rájöttem, hogy valószínűleg azért, mert aki szakmailag érdekes problémával találkozik, az sanszos, hogy már megtanulta értelmezni a hibaüzeneteket, valami sejtése van a debuggolásról (ami NEM a die() és egyéb bullshitek), meg utánanéz, mielőtt nekiesne, mint tót az anyjának.
(#15294) moltam88 :
Hát bizony, ez valóban nem meglepő.![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#15293
Sk8erPeter
nagyúr
cucka
#15292
Sk8erPeter
nagyúr
-
#15275
Tele von Zsinór
őstag
cucka
#15270
Tele von Zsinór
őstag
5.5-től az általad írt függvényeket érdemes, 5.3.7 felett pedig használható azoknak a userland megvalósítása.
trisztan94: írtam egy hosszabb postot, miért jók ezek a függvények:
[link] -
#15274
Sk8erPeter
nagyúr
cucka
#15269
Sk8erPeter
nagyúr
-
-
DNReNTi
őstag
Tökéletesen érthető a különbség, köszi.
Amit továbbra sem értek, hogy miért nem működött a call_user_func_array() az érték szerint átadással összerakott tömbbel? Továbbá a harmadik, foreach() megoldás nem működött jól. Utóbbit mondjuk lehet benéztem valahol, erre mindjárt vissza is térek.
-
#14963
Sk8erPeter
nagyúr
cucka
#14947
Sk8erPeter
nagyúr
Nem nézegettem még a kódját ilyen szinten, de most elég nagyot csalódtam a WordPress-ben (legalább tudom, minek a kipróbálásával ne akarjam tölteni egy percemet sem
), hogy ilyen elképesztő ordas nagy baromság ott virít szépen a dokumentációban, ami elvileg arra való, hogy a fejlesztők és érdeklődők tanuljanak belőle. Először azt hittem, viccelnek, aztán majd ott lesz a vigyorgós fej, hogy jól van, csak vicceltünk, ne vegyél mindent olyan komolyan, de sajnos komolyan gondolják. Ez az "olyan, mint a f*szom, egy igazi csődtömeg, bottal sem piszkálnám" mondatrészleted igen érdekesen hangzik, remélem, azt vágod.
Furcsa egy (ön)kritika. 
Mondjuk ezen legalább jót röhögtem. 
-
#14919
Sk8erPeter
nagyúr
cucka
#14917
Sk8erPeter
nagyúr
Ez esetben én kérek elnézést, tényleg félreértettem a hozzászólásodat, eredetileg számomra eléggé oltósnak tűnt (mintha maga a gyorsmegoldás lenne a világ legrondábbja), de valószínűleg csak igen rossz pillanatban olvastam.
(#14918) fordfairlane :
Igaz, feleslegesen sértődtem be. -
#14914
Sk8erPeter
nagyúr
cucka
#14912
Sk8erPeter
nagyúr
Köszönöm, remek, hogy mindezt elmondtad
Mondjuk eleve vicc, hogy most akkor kezdhetek el mentegetőzni, de felmerül a kérdés, hogy 1. miért nem csináltad meg szépen, ahogy illik (talán mert sok idő lett volna, és nincs kedved hozzá?) 2. ha mindenki így áll hozzá, és saját seggét vakarászva, utólag okoskodva kritizál, akkor a kérdezőnek hogy oldódik meg a problémája. Igaz, utólag aztán elszégyellheti magát, hogy hát bizony ő milyen tudatlan, és akkor jól megmondtad. Neki is, de azért nekem is, hát nehogy már.
Elmondtam az elején, hogy pár percnyi szabadidőmben adtam tüneti gyorskezelést. Egy büdös szóval nem utaltam rá, hogy ezt így kellene csinálni (a Notepad++-ba gyorspötyögős dolgokat nem tartom annak). Az ilyen echózott megoldás gusztustalan lehet, igazad van, simán hívhatod spagettikódnak. Igazából szebb lett volna valami template-szerű megoldás, a fordfairlane által említett alternatív szintaktika, és így tovább. (De könyörgöm, nézz már rá a korábbi kódra. Remélem, nem várod el, hogy megtanítsam a kérdezőnek a PHP-alapokat is.) Jó, mondjuk a válaszolónak is felelőssége van abban, hogy az ember hogyan kódol a továbbiakban, ezt aláírom. (Ismét felmerül a kérdés: amennyiben mindenki minden architekturális és egyéb mintát, kódolási stílust a kérdezőknek meg akar tanítani, ki a tököm fog válaszolni? Nem beszélve arról, hogy a PDO-sítást sem végeztem el ilyen alapon, mert nincs se kedvem, se időm rá. Én rohadék.)
Viszont tényleg kíváncsian várom a gyorsmegoldásodat, amit 5 percbe sokkal szebben lehetett volna sűríteni, csak úgy, hogy ne használd fel a kódomat még csak részben sem, mert úgy utólag könnyű. Szóval kérlek, állj elő a mutatvánnyal 5 perc alatt, ami mindenféle architekturális elképzelésednek megfelel.(#14913) fordfairlane :
Hidd el, én is külön szoktam tenni, template-ezni (vagy ahhoz hasonló megoldást használni) már csak azért is kell, hogy az ember saját magát ne szopassa, meg azért, mert egyébként undormány kód születik. Ja, ez is ronda. (Ja, én is használom az alternatív szintaktikát.) -
rgeorge
addikt
Ezzel kezdtem, elküldtem neki a hibás XML-t megjelölve, hogy bekerül egy ns1 névtér, amitől értelmezhetetlen lesz az eredmény. Azóta állítólag sok mindent állított, de mindig változatlan xml pottyant ki a végén. Nyilván nem mi, a hívó fél rontjuk el az XML-t, neki kéne javítani, de nagyon úgy néz ki, hogy képtelen rá, én meg nem értek a PHP-hoz, csak látom a neten, hogy más is találkozott már ilyen problémával.
-
Hege1234
addikt
vagyis hogy néznének ki ezek a sorok helyesen ?
<?php
echo "<div class='nyelvvalaszt'>
<a class='hun' href='./index.php?lang=hun&menu=$_GET[menu]&active=$_GET[active]'>Magyar</a>
<a class='de' href='./index.php?lang=de&menu=$_GET[menu]&active=$_GET[active]'>Deutch</a>
</div> ";
?><div class='"; if($_GET["active"] == "masszazs") echo "active_"; echo"content_box'style='margin: 25px 36px -19px -97px;'>
-
#13519
fordfairlane
veterán
cucka
#13518
fordfairlane
veterán
Minden olyan dolgot, ami ahhoz kell, hogy bonyolult szoftvert lehessen készíteni. Eleve csak az 5-ös verzióban kapott a PHP tisztességes obejktumkezelő rendszert. Az 5.2-ben jutott el odáig, hogy használható lett a class loadere, aminek az implementációja még mindig egyedi, ezért további szabványosítást igénylő (PSR-0). Az 5.3-tól van csak namespace-kezelés.
Ezen kívül vannak olyan tulajdonságai, ami arra csábítanak, hogy kuplerájt hagyjon maga után a programozó. Például, hogy bármikor keverheted a html-t a PHP kódrészekkel. Nincs szétválasztva a megjelenítés az alkalmazáslogikától, a PHP egyben template-nyelv is. Nincs szabványos URL - metódus mapping, ez nem a PHP futtatókörnyezet része, hanem webszerver- és egyéb komponenesektől függő dolog. Ezernyi apróság, ami megnehezíti az alkalmazásfejlesztést.
-
#13235
Sk8erPeter
nagyúr
cucka
#13227
Sk8erPeter
nagyúr
Jaja, ez így szebb lehet, habár annyi hátránya mondjuk van, hogy így kétszer kell végigmenni a tömbön 1 helyett, ami meg lehet, hogy felesleges (bár sanszos, hogy futási időben nem tesz hozzá sokkal többet, max. ha óriástömbről van szó).
Asszem amúgy 5.3-tól vannak lambdák, igazából illene már az osztott tárhelyeken áttérni erre, ha még nem tették. -
#13219
Sk8erPeter
nagyúr
cucka
#13214
Sk8erPeter
nagyúr
Félreértetted, eddig sem tömbindexekről volt szó, arra kérdezett rá, hogy hogyan vizsgálja, hogy "asszociatív tömb értéke" üres-e. Tehát pontosabban az asszociatív tömb kulcsainak/indexeinek értékét szeretné vizsgálgatni, hogy az egyenlő-e az üres stringgel.
Egyébként meg pont ebben az esetben nem látom be, miért is ne lenne jó akár az empty()-t is használni, hacsak nem azért, mert nem fejezi ki pontosan a kódot kutatva, mire is szeretnénk vizsgálgatni (üres string); de működést tekintve jelen esetben az elvártak szerint működne... Ha bármely olyan eset igaz abból, ami az empty() esetekre vonatkozik, akkor nem íratunk ki semmit.
-
#13215
Speeedfire
félisten
cucka
#13214
Speeedfire
félisten
A példa tömb fentebb van.
if($specs) {
$table = '<table>';
$table .= sprintf ('<tr><td colspan="2"><strong>%s</strong></td></tr>',
Shop::t('Product Specifications'));
$data = 0;
foreach($specs as $key => $spec) {
if($spec != '') {
$table .= sprintf('<tr> <td> %s: </td> <td> %s </td> </td>',
$key,
$spec);
$data++;
}
}
$table .= '</table>';
if($data != 0) {
echo $table;
}
} -
#13213
Speeedfire
félisten
cucka
#13212
-
#13180
Speeedfire
félisten
cucka
#13177
Speeedfire
félisten
Hogy kell elképzelni ezt az átfordítja a másikra?
Lényegében talán elég lenne csak átírni a shop user model-jét. Ha erre írok egy interface-t akkor elvileg nem is kell minden egyes attributomot átírni igaz?Csak, mert a 2 user táblában még a nevek is máshogy vannak.
Sk8erPeter: Van a yii-ben migrálás, de nem próbáltam még ki ezt a dolgot.
Ugye van a saját rendszerem yii-ben és adott egy yii extension. Semmi extra, elég alap szerintem. Viszont nem a 0-ról kell kezdeni a fejlesztést.
Saját user tábla | shop user tábla:
Lényegében a shop user tábláját szeretném valahogy megoldani, hogy a saját rendszerbe mentse őket, úgy hogy közben egy db attributumot se kelljen átírni sehol sem.
-
H.O.D.
senior tag
Kezd világos lenni. Tehát egy statikus osztálynak nincs is __construct metódusa, ez akár hellopisti() is lehet és az "inicializálás" is csak annyiból áll, hogy az osztály értékeinek beállítására ezt a metódust használom és a többi metódus ezzel dolgozik tovább.
A lényeg, amit el akarok érni, egy interface, ahol teszem azt. termék paramétereket akarok lekérni egy id alapján, pl.:
$a = Product::get($id);
vagy használjak "hagyományosat":
$n = new Product;
$a = $n -> get($id);Melyik a jobb megoldás?
-
H.O.D.
senior tag
Hogy mit tudok és mit nem, azon most ne témázzunk, nem ez volt a kérdés. Ha egy 15 éves megkérdezi, mi az az OTTO motor, elmondod neki, vagy elküldöd a fenébe, mert nincs jogosítványa?
Tekintsünk el a kódtól, első próbálkozás statikus osztályokat illetően, nyilván nincs kész, de arra
megfelelő volt, hogy megértsem az elvet.Tehát akkor a kérdés: hogyan kell/lehet, oééetve lell-e egy statikus osztályt inicializálni? Nyoévám me, példányosítással, de akkor hogyan? Értelmes fellelhető forrás hiányában arra gondoltam, ez megtörténik az osztály bármely metódusának/elemének használatakor.
__autoload()-dal töltöm be, ha abba teszek egy xy::__construct()-ot, az lehet megoldás?
Köszi előre is!
-
Remélem tudtok segítein. Van egy oldal, amiben a tartalomban span-ban, p-ben, divben, th,td,ben lévő szövegeket ki kell cserélem linkre. Ezt hogyan tudom megcsinálni. Most jelenleg preg_replace-t használok de img-ben meg a-ban is cserél aminek következtében szétesik az oldal a hibás html miatt
-
#13008
Sk8erPeter
nagyúr
cucka
#13001
Sk8erPeter
nagyúr
Először is: nyugi, tudtommal egyelőre csak a lehetőségekről és miértekről beszélgetünk, és nem én akarom így vagy úgy megoldani, mert engem nem érint, hanem visszakérdeztem, hogy támaszd alá picit jobban, amit mondtál, mert érdekelt, de a hsz.-ed végére kissé behergelted magad.
"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."
Őő, ja, de ez nyilvánvaló, szerintem erről nem is érdemes témázni, mivel evidens.Amit viszont én szögeznék le előre a félreértések elkerülése érdekében, mert fontos, hogy alapvetően én is jobbnak látom a cronos megoldást, valszeg én is azzal csinálnám, ha én lennék a fejlesztője, mivel ütemezett feladatra használjunk ütemezőt, végül is pont arra való. Tehát én nem a cron ellen beszélek, hanem érdekes témának láttam megvizsgálni a másik oldal lehetőségeit is, ha már felvetették a többiek, hogy meg lehetne oldani anélkül is, tehát azt is érdemes megbeszélni, hogy mi történne abban az esetben, ha NEM cronnal történne a dolog. Én pedig csak azokra a dolgokra reagálok/kérdezek rá, amik esetleg elsőre teljesen egzakt fogalmazás híján (számomra) kérdésesek lehetnek (vagy legalábbis engem érdekelnek). Oké?
Úghogy az "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" (kicsit behergelődött) mondatot nem vettem magamra, mert nem rám vonatkozik.Lock-okra:
Igazából direkt előre kihangsúlyoztam, hogy elsősorban magára az ellenőrzésre kérdeztem rá, nem pedig az írási műveletekkel kapcsolatos aggályaidra, mert mint említettem vala, az még érthető is, de nekem úgy tűnt, hogy a lock-ok emlegetése kapcsán Te rátapadtál kőkeményen az írás-témára. De aztán utána meg simán az ellenőrzés-téma kapcsán is azt emlegetted, hogy a többiek várni fognak az erőforrásokra. Most szűkítsük le a kört simán arra, hogy kiolvasod az értéket ÉS az utsó módosítás dátumát, majd utóbbinál még egy összehasonlítást is végzel az aktuális dátummal, megnézed, amúgy mi a pálya, kéne-e frissíteni. Akkor itt még ne vegyük azt, hogy mi van, ha igen (akkor növelni kéne) - ebben az esetben ugye Te sem arra gondoltál, hogy írási művelet híján drasztikusan csökken a szerver teljesítménye nagy felhasználószám esetén?Egyébként az ütemezett scriptben feltételezem, nem árt ellenőrizni, hogy a júzer épp online-e, mert ha offline, akkor gondolom nem kéne növelni a mannáját, szóval akkor a böngészőből való kilépés esetén küldeni kéne egy requestet a szerver felé, hogy na cső, akkor távoztam, azt meg beírni adatbázisba, hogy most már nincs szükség buzerálásra az adott júzernél.
Mondjuk jobb lenne ismerni jobban egy ilyen játék működését, én ilyeneket nem szoktam tolni (kinek van ilyenre ideje?), úgy kicsit könnyebb lenne beszélni az elméleti lehetőségekről.===
(#12995) Tele von Zsinór :
na ja, ez az ütemezős dolog jó példa, alapvetően ez így tök jogos. De tényleg jobban kéne ismerni egy ilyen játék működési elvét, mert konkrét implementációt nem tudok, csak sejtéseim vannak róla. -
Soak
veterán
Nem értem miért vagy igy rápörögve a lock-ra . Ugyan megint csak találgatok, de gondolom a játék nem úgy néz ki jellemzően, hogy 1 embert támad 50.000 . Innentől kezdve (még ha lock-olnánk is, de azzal eddig magyaráztam, nem kell) InnoDB motor row-level lock-nál miért olyan nagy probléma ha lockolunk egy sort? Ha még egyszerre 3-5 ember akarja elérni (nem értem hogy miért updatelné egyszerre 3-5, de ugye találgatunk csak) akkor se lenne dráma.
-
oleslie
aktív tag
>Ahol nem elérhető a cron, azok a kétpálcás php webhosting megoldások....
Értem, tehát a rendelkezésre állás. Az, hogy a szerver soha nem kerül 100% leterhelt állapotba lóf*sz.
cron legyen, ez a fontosch, különben kétpálcás?
kicsit reklámozom magam.
Több mint 2 év alatt (2,5 HJE) 2x indítottam újra a szervert. Egyszer ram bővítés, másodjára kernel frissítés miatt. A szokásos (web, levelezés, mysql) mellett futnak játékszerverek is. És ennek ellenére soha nem volt gondom. Azért lennék sufnihosting (kétpálcás?), mert TE nem tudsz önállóan beállítani bármilyen elcseszett scriptet, ami esetleg problémát okozna? Nemhiszem
stat -
#13003
lordjancso
senior tag
cucka
#13001
lordjancso
senior tag
Részben egyetértek veled akkor, ha a manát "globálisan" láthatóvá teszi a fejlesztő az oldalon. Tehát mondjuk meg lehet nézni a játékosok adatlapját és ott valós mana értéket szeretnél látni (persze itt is meg lehet kerülni a cron-t). Én így képzeltem el a játékát:
A belépett játékos csak a saját manájával van elfoglalva, csak azt látja, semmilyen körülmények között nem tudhatja, hogy mennyi manája van az ellenségnek vagy a többi játékosnak.
Így elég csak belépéskor ellenőrizni, hogy a legutóbbi manahasználat óta mennyi idő telt el, majd megjelenítés előtt megnövelni a mana értékét a kiszámolt mennyiséggel.
Minden manahasználatkor logolod annak az idejét. Minden manamegjelenéskor elvégzed a vizsgálatot, hogy mennyi idő telt el és mennyivel kell megnövelned a manádat (ez jól megírt játéknál ez nagyon egyszerűen kivitelezhető).Ha lehet látni a másik manáját (mondjuk adatlapon keresztül), akkor is elég csak az adott (éppen nézett) játékos manáját vizsgálni és updatelni.
Szerintem ez lenne a leginkább erőforráshatékony megoldás, mert így egy, maximum kettő játékos manáját kell számolgatni. Főleg ha van sok tíz-százezer játékosod.
Persze a cron is jó dolog, abszolút nem vagyok ellene, én is használom napi szinten, de csak akkor, ha valóban indokolt. Ebben az esetben én nem tartanám annak (értsd, nem cron-nal csinálnám a fejlesztő helyében).
-
oleslie
aktív tag
ok. pontatlan volt a megfogalmazás.
Nem mindenhol tudsz beállítani cronjob -ot.
Az, hogy a cron (vagy ablakOS -en a megfelelője) elérhető e a rendszeren, nem kérdéses. De az, hogy TE, mint felhasználó, hozzáférsz e, már igen.
Valamint: fölösleges bonyolítani az oldalt egy ily módon időzített scripttel, miközben az adatbáziskezelővel kényelmesen, és nem utolsó sorban gyorsabban, kevesebb erőforrást felhasználva meg lehet oldani a feladatot.
Az erőforrásigény téged valószínűleg addig nem fog érdekelni, amíg nem töltesz fel vmilyen hibás scriptet cronra, azzal túlterheled a szervert (láttam már ilyet), amit annak az üzemeltetője úgy old meg, hogy törli a problémás dolgokat, TE pedig old meg ahogy tudod (csináltam már ilyet). -
#12993
Sk8erPeter
nagyúr
cucka
#12989
Sk8erPeter
nagyúr
"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."
Ezt nem igazán értettem. Miért, mi benne a bonyolult?"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."
Az írásra vonatkozó rész még okés, de maga az ellenőrzés miért lenne olyan nagy gond? Eleve az aktuális manna értékét ki kell olvasni, akkor még az utolsó írási művelet dátumát kiolvasni, majd aktuális dátummal összevetni minden, csak nem egy igazán erőforrás-igényes művelet. (Jó, ha nagyon akarom, ilyen alapon az aktuális dátum és idő lekérdezése miatt szükséges OS-szintű rendszerhívás is erőforrás-igényes.)
Hangsúlyozom, itt az ellenőrzéssel kapcsolatos aggályaidra reagáltam elsősorban, nem az írási műveletekre. Bár hozzáteszem, az ilyen szinten egyszerű félóránkénti (!) írás csak elég durva felhasználószámnál jelenthet szerintem gondot, szóval picit úgy érzem, ebben az esetben túl van parázva a dolog. Ha ötpercenkénti írási műveletekről lenne szó, akkor jogos.(#12990) Soak :
hogy a másik oldalhoz is szóljak
"> A cron pedig simán futhat akár 30 másodpercenként is.
Alapból nem, de nyilván megoldható."
Ezt hogy érted? Az adott script futtatása olyan időközönként fut, ahogy konfigurálod... Itt mi az, hogy "alapból"?"> 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?
Fejleszteni nem kell, mert már megtették mások, ezért nem nehezebb semmivel mint egy cron job-ot beállítani. 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) ."
Másik daemont fejleszteni? Nem világos. Mire? Az időzített feladatok futtatására? Vagy nem vágom. -
Soak
veterán
A mana érték egy játékban sokszor frissül, ergo rengeteg olvasási művelet lesz.
Jah, épp ezért lehetne megoldani egyszerűen, hogy ha belovassuk akkor már a jó értéket jelentítsük meg (egy egyszerű matematikai müvelet és kész), nem lesz semmivel nagyobb terhelés, mert csak akkor írunk ha változás történik.
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.
é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.A cron pedig simán futhat akár 30 másodpercenként is.
Alapból nem, de nyilván megoldható.
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?
Fejleszteni nem kell, mert már megtették mások, ezért nem nehezebb semmivel mint egy cron job-ot beállítani. 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) .
Persze vannak hátrányai is, meg előnyei is.
DeltaPower : Nem 30sec, hanem 30perc, igaz. Nem a sebesség miatt irtam feltétlenül, csak ha belegondolok, hogy a kérdező valószínűleg mit akar elégni akkor nem vagyok benne biztos, hogy 30percenként érdemes frissiteni. Mi van ha egy felbuffolt embernek 1 perc alatt megtellik? Tudom, hogy kicsit tovább gondoltam mint az alap kérdés, de ha már ugyis megnézzük mennyi a manna az adatbázisban éppenséggel frissitett adatot is vissza adhatunk, akcio után meg a jo adatot beirjuk.
-
LonGleY
veterán
Hisz mi raktuk bele, tudnánk hogy kell kikapcsolni (teljesen saját motor).
De ez nem áll széndékunkban, az oldalnak www-vel kell mennie mindenhol.A lentebbi szabállyal [1. melléklet] az app.php végzi a routingot (Slim Framework), így az alap URL működik: www.blahblah.hu. Viszont ha be van kapcsolva a www-re való átirányítás [2.melléklet], akkor a www nélküli URL-ről indítva www.blahblah.com/app.php az eredmény. Az oldal így is működik, de a cél az lenne, hogy az app.php ne látszódjon.
-
#12848
DeltaPower
addikt
cucka
#12841
DeltaPower
addikt
2. Én még nem láttam olyan projektet, ahol megkövetelték volna, vagy időt adtak volna arra, hogy ilyesmivel szarakodjunk.
Ez engem például rettentően zavar. Arra viszont volt már több példa, hogy visszajött egy projekt néhány hónap után, mert olyan terhelést produkált az ez idő alatt felhízott adatbázisával, hogy a hosting szolgáltató egyszerűen lekapcsolta az oldalt. Ilyenkor aztán lehet fejvesztve kapkodni hogy mit is kellene módosítani rajta. -
#12847
lordjancso
senior tag
cucka
#12844
lordjancso
senior tag
Elnézést a nem teljesen pontos megfogalmazásomért. Az idézett mondtatot így helyesbíteném:
De ha te tudod, hogy az az optimális és teljesítményhatékony megoldás, alapból azt használod nem?(#12845) Speeedfire:
Ne haragudj, de nem értem, hogy mire szeretnél kilyukadni. Ne használjuk "beépített függvényt"?!?! Durva fogalomzavar az, amivel éppen szemben állsz.
-
#12843
fordfairlane
veterán
cucka
#12841
fordfairlane
veterán
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.
Nekem is ez a tapasztalatom, szinte soha nem a PHP az oka a lassú végrehajtásnak. Majdnem mindig az I/O a szűk keresztmetszet, jellemzően az adatbázis kezelése.
-
#12842
lordjancso
senior tag
cucka
#12841
lordjancso
senior tag
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
De ha te tudod, hogy az az optimális megoldás, alapból azt használod nem? Legalább is feltételezem.
Tehát ilyen esetben ez nem plusz igény, hanem csak a saját tudásod leginkább szakszerű felhasználása. -
Soak
veterán
Nem értem ezt a hozzászólás.(Hogy jön ide 10 millio? hogy jön ide az adatbázis? Nem erről volt szó.) Nyilván nem azon fog megfeküdni az alkalmazás, hogy require_once vagy require, viszont ha ez a hozzá állás akkor mindenhol ez lesz és sok kicsiből már összejön esetleg 5-8% ami egy nagy forgalmú websitenál jelentheti azt, hogy erősebb szerverbe kell fektetni vagy még kihuzza addig ameddig van stabil cash flow és akkor már egyszerűbb.
A forma1-es autó sem azért könnyű mert felnijei 2kg-val könyebbek mint egy ugyanakkora hagyományos technikával gyártotté, hanem mert mindenhol meg van fogva ez a kicsi (nyilván sarkitottam, de szerintem érthető) . Plusz ha erre külön fel kell venni egy programozót, hogy optimalizáljon akkor rossz csapattal lett elindítva a projekt, mert az inkompetenciát ki kell fizetni mindenképpen (kérdés hogy mikor), ez nem érv a hatékony megoldások ellen.
-
alitak
senior tag
A firebird szervet innen lokálisan a gépről egy kliensprogrammal (FlameRobin) elérem. PHP-val a szerverről nem érem el. A PDO elképzelhető, hogy nincs telepítve, a szerver üzemeltetés rész nem nálam van. Rákérdezek. Van arra esély, hogy ha az ibase_connect() segítségével nem tudok csatlakozni, attól a PDO-val menni fog a dolog?
-
#12704
Sk8erPeter
nagyúr
cucka
#12703
Sk8erPeter
nagyúr
Ja, így már érthető, de nem azt mondtad korábban, hogy HA NULL AZ ÉRTÉKE, mert akkor egyből érthető lett volna:
http://php.net/manual/en/function.isset.phpisset — Determine if a variable is set and is not NULL
már eleve ez van a doksiban.
Szerintem is totál degenerált dolog ez ilyen formában, mivel rohadtul félrevezető...Viszont ez működik:
$a = array(0=>null);
var_dump( array_key_exists(0, $a) ); // --> TRUE!visszatérve arra, amit írtál:
var_dump(in_array('s', array_keys(get_defined_vars()))); //-> TRUE
na ne már... ezt minden validálásnál így csinálod? Az összes, adott scope-ban elérhető változót lekéred egy tömbbe, és végigszaladgálsz rajtuk, csak hogy megtudd, egyetlen adott tömb egy adott kulcsa létezik-e? Akkor már nem értelmesebb kissé a fentebb említett array_key_exists()? Kicsit kevésbé tűnik erőforrás-igényesnek, eleve kevesebb adatból kell kibogozni a kérdésünkre a választ. -
#12701
Sk8erPeter
nagyúr
cucka
#12697
Sk8erPeter
nagyúr
"Tehát az isset true-val fog visszatérni bármilyen változóra, ami nem létezik"
Hogy micsoda?
Ha van egy ilyened:
$valami;
az isset($valami) FALSE-szal fog visszatérni;
A $valami = 1; után már TRUE-val.
Hogy térne vissza true-val? Vagy csak elírtad?"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."
Az előbbi azt igazolja, hogy de igen, van köze hozzá (PHP 5.3.8-ban legalábbis biztosan, Te nem tudom, hányas változatról beszélsz, hol volt ez valaha érvényes (4-esnél simán lehet, ezt nem tudom), én az általad említett dologgal nem találkoztam még).
Ahogy arra is false-t ad vissza, ha a $nincsilyen változód nincs beállítva sehol hogy, és nyomatsz egy olyat, hogy isset($nincsilyen->tokmindegy), ahogy ugyanez igaz a $nincsilyen['tokmindegy'] ellenőrzésére is.
Ez most akkor pont annak ellenkezője, amit írtál, szóval nem értem az állításodat."(Ennek eldöntésére a get_defined_vars() való)."
Hmm?
Hogy jön ide a get_defined_vars(), amikor csak egyetlen változó meglétét szeretnéd ellenőrizni? Ez a függvény egy komplett tömböt ad vissza az adott scope-ban elérhető lokális/globális/szerver/környezeti változókról, tehát tartalmazni fogja a $GLOBALS tömb dolgait, a $_SERVER dolgait, és így tovább... ezután ezen a tömbön fogsz kiadni egy isset()-et, és akkor ugyanott vagy, vagy ezt most hogy értetted?
Nem az array_key_exists() vagy property_exists() és társai valamelyikére gondoltál?"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."
Mondjuk akkor még lehet értelme, ha a "", 0, 0.0, "0", NULL, FALSE, array() és értékadás nélkül deklarált $var változók közül egyik sem felel meg neked, és megköveteled, hogy mindegyiktől különbözzön mondjuk adott mező Ha például egy adott mezőt kötelező kitölteni, vagy mondjuk 0-nál (0.0-nál) nagyobb szám megadására van szükség, akkor végül is ellátja a feladatát, de ettől függetlenül azzal egyetértek, hogy általános validációra nyilván alkalmatlan. -
#68216320
törölt tag
Teljesen érthető, nagyon köszönöm.
A típusegyenlő (===) vizsgálatok is jó ötletnek tűnnek. Használni kezdem őket az új forrásaimban.
Éppen most dolgozom egy saját project admin felületén. Eddig procedurális módon csináltam mindent, de kezdek áttérni a objektum alapú kódra. Szóval, van tanulni valóAz a helyzet nálam, hogy a PHP nyelv tanulásának kezdetén igen kevés és nem korszerű képzést kaptam. Mint szerintem nagyon sokan, mások forráskódjaiból próbáltam elsajátítani a továbbiakat. Illetve a 24órás sorozat tankönyve volt meg. Úgy tűnik viszont, hogy nem megfelelő forráskódokhoz jutottam hozzá és a hibák amik bennük voltak rögzültek bennem. Hiányzott egy ilyen fórum, ahol kiderülnek az ilyenek. Ugyanis bár próbáltam tesztelni az elkészült forrásokat, de nagyon sok hibás gondolatmenetre, rosszul alkalmazott eszközre nem derül fény ettől. Ezért elnézést is kérek mindenkitől, ha itt a fórumban hibák vannak az általam alkalmazott technikákban, de ha nem osztom meg a gondolataimat bizonyos helyzetekben, akkor ezek nem derülnének ki sohasem. Viszont, a következő hozzászólásaimban óvatosabb leszek már és az én úgy tudom, illetve szerintem kifejezésekkel fogom kezdeni őket, hogy másokat ne tévesszen meg esetleg hibás mivoltukkal, ahogy kezdetben velem tették más oldalak.
-
lakisoft
veterán
trükk nélkül.
MSSQL, Oracle, postgreSQL mind mind támogatja az tárolt eljárások használatát, sőt a MySQL is elkezdte elég intenzíven.Az adatbázis kapcsolattal sem kell foglalkozni, tőlünk sokkal okosabb emberek már előre megírták és framworkbe pakolták.
Szerk.: Alkalmazás szinten miért kell megoldani adatbázis szintű problémákat?
-
#12164
Peter Kiss
őstag
cucka
#12153
Peter Kiss
őstag
Nem, a különbség nem csak szintaktika, és nekem nem ekvivalens a kettő. Ha én valahol egy interface-t (vagy egy sima általános object-et várnék (stdClass?)) várok, akkor nem mondhatom minden egyéb teszt nélkül neki azt, hogy __toString() mert egyből meghalhat (attól eltekintve, hogy valószínűleg nem ezért várunk egy adott típusú elemet).
A különbség elvi, PHP-ban egészen pontosan elvi hiba. Eleve, magic gyűjtőnév alatt vannak, ez messze nem tervezés eredménye, shol sem lehet arra számítani, hogy ezek ott vannak az adott objektumban.
@Swifty
Ez még példának is rossz volt... A __toString()-t soha sem használjuk ilyenre... Semmilyen production kódba nem írunk ilyet így... MVC-ben főleg nem így dolgozunk... -
Swifty
csendes tag
Persze... Csak példát mondtam...
Lényeg az, hogy az adott funkción keresztül megkapod az objektum tartalmát string-ként... Amit persze örököltethetsz, fejlesztheted, stb...
Viszont a saját metódusod használata így nézne ki:
echo $foo->mivanbennem();A magic method-dal meg:
echo $fooSőt:
echo 'Ez van az objektumban: '.$foo -
#12151
Peter Kiss
őstag
cucka
#12149
Peter Kiss
őstag
Ez a magic methodos dolog sántít, mivel, ha csinálok egy ilyet:
class Foo {}
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).
---
Ez típusossági problémát már kicsit túlpörgitek, ha valamit osztály segítségével lehet rendesen leírni, használjunk osztályt.
Ha valami jó primitívként, használjunk primitívet, akár úgy, hogy a metódus bemenő paraméterét felülvágjuk (pl. strval()-lal), senki sem izgat, ilyen módon engem nem zavar, hogy nem kell kiírni mindenhová, hogy int, float, string (array, class/interface név nekem elég, callable még jó lenne, de legalább van Closure).
Abban az esetben, ha valami primitívnek tűnik, de nem az, akkor C#-ban és Java-ban is bevezetek egy olyan saját típust, ami segít leírni, miről is van szó (SSN-t nem numerikus értékként, string-ként használunk, hanem van rá SocialSecurityNumber nevű osztály), ezt szinte mindenhol meg lehet tenni. -
#12150
Sk8erPeter
nagyúr
cucka
#12149
Sk8erPeter
nagyúr
"A dinamikusan típusosság miatt nehéz használni a NuSoap-ot?"
Ezek szerint mégis elbeszélünk egymás mellett. Ki a francot érdekel a NuSOAP? Engem nem, mert nem erről beszéltem, nem a NuSOAP library fikázása volt a cél, már megint terelődik a téma egy halott irányba. Most tényleg el kell, hogy magyarázzam még többféleképpen is, hogy nem a library-vel magával van bajom, hanem azzal, hogy a típusosság hiánya miatt nem lehet egy ilyen tök felesleges időelb@szó munkát automatizálni ÚGY ÁLTALÁBAN PHP-ben, hogy pár klikkel ezt a részét megoldjam, és az ÉRDEMI programozási feladatokkal foglalkozzak?"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."
Ebben eddig is egyetértettünk, ennek kapcsán eddig is egy nyelvet beszéltünk. Igen, így van, de ez megint csak egy magasztos, tök általános jellegű állítás, a téma kapcsán nem visz sehova, ez már kezd szinte marketingszagú lenni.
IGEN, meg kell oldani egy feladatot. Szeretnél SOAP-ban kommunikálni? Kell hozzá egy WSDL. Nézzük meg ezt mondjuk C#-ban: Visual Studio megnyit, ide-oda klikk-klakk, és kész van a kódból a WSDL-generálás. Na, akkor most csináljuk meg ezt PHP-ben. Előveszünk egy library-t (hangsúlyozom, teljesen mindegy, melyiket), és elkezdjük tanulmányozni a doksiját, hogy vajon hogyan kell legeneráltatni vele egy WSDL-t úgy, hogy az működjön is; tanulmányozhatjuk ismét ennek megfelelően a saját kódunkat is, hogy megnézzük, hogy melyik metódus mit is ad vissza (ahelyett, hogy kódírás közben mondjuk a már legenerált WSDL-ből kapnánk hintet). Akkor most a doksiban olvasottak alapján kipróbáljuk, hogy vajon működik-e az, ahogy értelmeztük a dolog működését. Ób@sszameg, nem működik, akkor most mi a szar van? Debuggoljunk, vagy kezdjünk el korábbi kérdések után kutakodni a neten. Tök jó, máris egy csomó idő elment egy ilyen baromsággal.
Miből következik ez? A típustalanságból. Hiába kántálunk arról, hogy mi lehet a választás alapja igények szerint, mi mire jó, és hogyan is kell szépen kódolni. Tök mindegy a téma szempontjából. Kár, hogy nem lehet automatizálni ilyen jellegű feladatokat például PHP-ben.
Jó lenne azt érezni, hogy érted, miről beszélek.A magic methoddal kapcsolatos dolgokról meggyőztél, elfogadom az érveidet.
-
#12148
Sk8erPeter
nagyúr
cucka
#12145
Sk8erPeter
nagyúr
"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."
Egyáltalán nem értem, ez hogy jön az említett SOAP-os példához, ahol számít a típusosság, és számít olyan szempontból is, hogy mennyire lehet automatizálni az ebből történő WSDL-készítést, vagy mennyire nem."..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ő?"
Már megint leegyszerűsíted a kérdést, és mintha szándékosan vezetnéd vakvágányra a témát. Nem sikerült megismernem a NuSOAP-nál sokkal értelmesebben megírt 3rd party library-t, a konkrét probléma megoldására. Igen, az mondjuk igaz, hogy komplex példákat nem nagyon említenek a hivatalos doksiban, ami mondjuk az ő f@szságuk. Egy library-hez mellékelt dokumentáció sokszor minősíti magát az egész library-t is. Ha szar a dokumentáció, lehet akármilyen faszán megírva a lib, nehéz vele mit kezdeni, és gáz, ha órák mennek el a source-ban lévő kommentek olvasgatásával. Mindegy, ez most csak a téma elterelődése megint, szóval ne erről beszéljünk. A NuSOAP-os parát így sikerült magamnak megoldani: http://stackoverflow.com/questions/6986350/generating-wsdl-with-nusoap-return-struct-with-various-types-int-string-arr
Nem értem, melyik részt nem érted abból, hogy ezzel tök felesleges munkaidő ment el, mert lehetetlen ilyesmi kódot legeneráltatni egy IDE-vel PHP-t használva, mert nem lehet felismerni a típusokat. Tehát típustalanság = a példában szar.
Már elég sokadszor tereled a témát magasztos elvekre, hogy legyen átlátható a kód, és akkor király minden, de ez egyszerűen nem kapcsolódik a konkrét témához, amivel próbálom veled érzékeltetni, miért is tud problémás lenni a típustalanság. Tehát amiről beszélünk már jópár hsz. óta.
Mint látható, igény van rá, és hogy reagáljak arra, amit mondtál, igen, a gyakorlatban is van rá szükség. Vagy szerinted ha nem lett volna rá a gyakorlatban szükség, akkor töltök vele egy percet is, hogy ilyesmivel szopassam magam PHP-ben?
Kezd így kicsit fárasztó lenni a beszélgetés, hogy elbeszélünk egymás mellett.----
magic metódusok részre:
"Megint itt tartunk, hogy valaki Java-ban akar programozni PHP-ben"
Úgy tűnik, itt én értettem félre az eredeti témát, én a magic methods-ról beszéltem, ami szerintem igen csúnya:
http://php.net/manual/en/language.oop5.magic.php
bár tény, hogy végül is félreérthetetlenné teszi a dolgot, de nekem ennek kapcsán kicsit olyan érzésem van, mintha ez is egyfajta erőltetett megoldás lenne, mint sok másik.A függvény overloading (típusok szerint) mondjuk PHP-ben valóban értelmetlen, ezt el kell fogadni, ezzel egyetértek. Ebben az esetben mondjuk kerülő megoldásként például különböző nevű függvényt lehet definiálni, és a nevével egyértelművé tenni, hogy mi is a helyzet.
-
#12144
Sk8erPeter
nagyúr
cucka
#12140
Sk8erPeter
nagyúr
Én nem gondolom úgy, hogy a típusosság kérdése irreleváns, rossz kérdés. 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. Tudom, hogy már sokat szoptam a SOAP-os, WSDL-generálós példámat, de megint elő kell hoznom, mint egy kritikus példát, ahol a típusosság kérdése nagyon nem irreleváns, hanem épp, hogy kritikus jelentőségű. 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, amivel már meg lehet kezdeni egy SOAP-alapú kommunikációt, és objektumok tömbjét és egyéb komplexebb típusú elemeket tudj vele előre deklarálni, akkor azokat rendkívül elvesztegetett fejlesztői munkaóráknak találom, nem hiszem, hogy normális fejlesztőnek WSDL-kódok debuggolásával kellene tökölnie. Mint említettem korábban, mindez például C#-ban (de akár Java-ban is) pár klikk egy megfelelő IDE-ben (Visual Studio, NetBeans, Eclipse, vagy egyéb), nagyjából 10 perc alatt meg is vagy vele, normális teszteléssel együtt fél óra. Mindez részben annak köszönhető, hogy a típusok szigorúbb szabályokat adnak a kódnak, és a kiegészítő eszköz is képes ezek felismerésére (meg annak köszönhető, hogy mindezt már valakik elkészítették).
Mondom, ez csak egyetlen kiragadott példa a rengeteg lehetőség közül.
De az is sokat segíthet a debuggolásban, ha a figyelmetlen típuskutyulásokkal kapcsolatos hibák miatt a fejlesztőkörnyezet vagy a compiler még időben ugat, hogy valamit rosszul csináltál."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?)"
Jaja, ez teljesen igaz, hogy ez ilyen módon csak félmegoldás, annyit ér, mint halottnak a csók, ettől függetlenül legalább valami minimális megszorítást adhat a függvény várt argumentumaira. Sajnos sok ilyen következetlenség van a PHP-ban (ezért tákolmány).===========
(#12141) modder :
"Vagy olvassak inkább arról, hogy milyen király php-ban a "magic metódusokkal" megoldott függvény túlterhelés, és egy 20 éves nyelvnél még mindig ilyen tákolmány megoldásokat kell alkalmazni?"
Brrr, ne is mondd, hányadék.
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. Sajnos kiderült, hogy utóbbi.Amúgy már alig várom, hogy jöjjön egy troll megjegyzés valamelyikünknek címezve, hogy "hádefigyeljé' má, akkó anyádé' használsz PHP-t, köccccsööög??!"
-
modder
aktív tag
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.
Ez igaz, és erre mondtam, hogy ha alapvetően egy nyelv szabályokra épül, kevesebb lehetőség van a gányolásra. Érted, ha át akarsz kelni egy szakadékon, sétálhatsz fél kilométert a hídig, vagy átkelhetsz rajta egyenesen, de akkor lehet, hogy eltöröd a lábad.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ű. 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.
Nyilván arra akarok kilyukadni, hogy ha multidimenziós tömb helyett az ember objektumhierarchiát használna ezekre a feladatokra, az sokkal átláthatóbb kódot eredményezne. de hát az olyan nehéz, mert akkor definiálni kell osztályt... meg mi az, hogy egy tömb vagy lista csak egyféle típusú elemekből állhat, fúj
És akkor arról még nem is ejtettem szót, hogy a mai fejlesztőkörnyezetek type hinteket adnak az objektumokra, de a tömb elemekre sosem fognak.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.
Valamivel ki kell tölteni a helyet abban a könyvben. Remek érv Egyébként nem azért hoztam fel, mert haskellben kell programozni, hanem azért, mert jó, ha az embernek van viszonyítási alapja. Vagy olvassak inkább arról, hogy milyen király php-ban a "magic metódusokkal" megoldott függvény túlterhelés, és egy 20 éves nyelvnél még mindig ilyen tákolmány megoldásokat kell alkalmazni? -
#12139
Sk8erPeter
nagyúr
cucka
#12138
Sk8erPeter
nagyúr
"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."
Na ezzel teljesen egyetértek.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, mintha a kettő között lennél, hogy jó is, meg nem is.
Mondjuk erre lehet mondani egy klisészerű mondatot, hogy "igénytől függ". Sztem a korábban említettek miatt nem jó, hogy nem kell megadni a típust. 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){
...
}
tehát deklarálja, hogy itt tömböt fogunk várni. -
modder
aktív tag
Ne feledd, a szkriptnyelvek alapvetően rövid programok írására lettek kitalálva.
Jajj, erről meg is feledkeztem, most újabb érvet adtál a kezembe
Szóval igen, valóban remek eszköz egy nem gyakorlott ember kezében, hogy a logikára tudjon koncentrálni, és ne a nyelvi megszorításokra. Ezzel nem vitatkozom.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. És akárki akármit mond, minél nagyobb vagy bonyolultabb egy rendszer, annál több szabály szükséges ahhoz, hogy jól működő, olvasható, módosítható kód szülessen benne.
Ha már szóba került a Drupal. Nekem úgy tűnik, hogy nagyon sok energiát fektetnek abba, hogy minél jobb legyen a rendszer, gyorsabb. 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), amik. azt eredményezik, hogy egy drupal oldalletöltés több száz megabyte memóriát igényel.
--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?
A Haskell-t kezdtem el tanulgatni, és ott ez így működik. 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, és nem kell találgatnunk csak a függvény nevére alapozva. -
#12127
Sk8erPeter
nagyúr
cucka
#12125
Sk8erPeter
nagyúr
"Attól népszerű, mert egy könnyen tanulható, nagyon megengedő szabályokkal ellátott szkriptnyelv."
Lényegében én is ezt írtam, csak kicsit hosszabban kifejtve. De gondolom továbbolvastad.
Igen, végül is ennek része lehet az is, hogy nem kap az arcába a gányoló fejlesztő mindenféle hibákat, ha olyasmiket követ el, amikről eddig szó volt (ez a hátránya is a nyelvnek, ahogy arról már korábban beszéltünk)."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"
Korábban is írtad, hogy kvázi egy dilettáns majom, de miből gondolod ezt amúgy? (Csak kérdezem, nem tisztem megvédeni.)A phpsadness-t nem ismertem, de jónak tűnik.
-
bobace
addikt
Szerencsére magamnak csinálom. Ez a "tanulóprojektem" phpban. Sajnos ennél ki is jött a legnagyobb problémám, nincs rendes programozó agyam
Nem tudok ennyi féle problémát előre látni... Persze, gondolom gyakorlat teszi..
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. Csak szerettem volna igényesen megjeleníteni, hogy mely tételek vannak már úgymond rendezve, csak bírnám legalább valamelyiket leprogramozni -
bobace
addikt
Ez így volt a rendszerben ez a check és system, ezeket nem én találtam ki,csak kopizon, ahová láttam, hogy kell.. Ez egy egyedi CRM rendszer része, amit nem én csináltam.
A megoldás az lenne, hogy 200 Ft-ból kiegyenlít időrendben amennyit tud. Ha mondjuk az 50-50-90-90-200 időben 50-200-90-50-90, akkor 50-90-50-et egyenlít ki, és marad 10. De ha mondjuk 200-50-50-90-90, akkor nyilván a 200-at. Nem tudom, hogyan lenne a leglogikusabb, lehet hogy nagyság szerinti sorba kéne rakni, nem időben? Bár ott meg ha nincs keret a legnagyobbon, és megáll a dolog, akkor meg kisebbek nem lesznek kiegyenlítve, holott arra lenne egyenleg.. Ezt én sem tudom, mi a legéletszerűbb, leglogikusabb.
-
bobace
addikt
Az megesik, hogy ezer sebből vérzik, hisz én írtam, és én nagyon kicsit értek hozzá
- annyit kellene neki tudni, hogy vannak benne fizetetlen tételek, amiket ki akarok egyenlíteni. Egy-egy befizetésnél megvizsgálja, hogy mely tételeket kell kiegyenlíteni, és van-e rá fedezet. Egyszerre több tétel is lehet, mondjuk van kint 50+200+100 és bejön 180 vagy akármennyi (plusz az előző egyenlegem, mondjuk 15), ami kevesebb mint a kintlévő összeg (350), de amire van fedezet, azért azt állítsa át fizetvére (100+50). Azt érzem, hogy ez nem gyenge feladat, egyelőre annak is örültem volna, ha az 50-re rájön, hogy azt állítsa át első körben.
-a check a szintaktikát ellenőrzi, ha rossz, dob egy hibaüzit. Teszteléskor jól jött sokszor. -
#11862
Peter Kiss
őstag
cucka
#11856
Peter Kiss
őstag
@cucka
"~2 éve nem is fejlesztek php-ban" - így egy kicsit világosabb, miért írtad azokat, amiket.
"Na, hát csak kibújt a szög a zsákból." ---
@Swifty
Az valóban nem érdekes, hogy újoncként vagy itt, vagy nem, az annál inkább, ahogyan bevágódtál a beszélgetésbe.Sokkal jobb így, rengeteg off-fal ez a topik, nem? Igazán barátságos lett!
-
#11833
Peter Kiss
őstag
cucka
#11832
Peter Kiss
őstag
Szkriptnyelvség: behányunk valamit valahová és valami kijön, ezt lehet könnyen levetkőzni.
Lambdák vannak típusos nyelvekben is, .NET-be egészen durván jelen vannak.
Ezt az általánosítást ne ferdítsd már el a hülyeség irányába.
Egyedi szoftvert is kell általánosítani, mert különben túl bonyolult lesz a megvalósítása, ez kimerülhet pl. egy IStatus interface egy metódusában is, de jelen van, mert kell.Nálam az a keretrendszer, amivel nem lehet dolgozni, szarnak minősül. A "jól van megírva" dolognak két oldala van, maga a keret kódja penge, vagy az, ami kívülről lehet látni, mivel keretrendszert nem azalapján ítélünk meg, mi van benne, így a külsőleg látható elemekből kell döntést hoznunk arról, jó-e vagy sem.
Utolsó bekezdéshez annyit, hogy idézted a mondandó felét, illetve a kérdésedre még ebben a kis részben is megvan a válasz.
-
PazsitZ
addikt
Alapvetően abban egyetértek, egy házi 2 formos php kódot, lehet felesleges OOP-ben megírni.
Továbbá, ha már adott is egyegyszerűbb kód, felesleges egy csv felolvasást köré 5-10 osztályt felhúzni.Viszont, ha én kezdenék bele, akkor már fognék egy framework-öt, ami segítségével oldanám meg a dolgokat.
Alapvetően a PHP-s framework-ök is OOP irányba mennek, amit az én észrevételeim alapján a nyelv is egyre inkább támogat.
Abban van igazság, hogy ez script nyelv, de ettől még nem a register globals és levegőbe lógó függvények szempontjából kell használni szvsz.Amennyiben pedig elkezdesz egy OOP framework-kel dolgozni, akkor viszont igenis namespace és osztálystruktúrát kell használni, nem kavarni a dolgokat.
A TDD hasznos dolog, kellő rálátás esetén jobban ki is kényszeríti a szebb kódot, SRP-t, amiből már könnyen jön a panaszolt "overgeneralization".
(#11820) Soak:
Egyébként nem olyan könnyű eltalálni a balanszot.
Egyik oldalról ott van az a szabály, hogy csak a kért feature-t fejleszd, ne űrhajót.
Másik részről viszont rá lehet/kell érezni, mi az, ami a következő iterációban biztos be lesz rendelve. Ebben az esetben pedig nem árt, ha kicsit előre gondolkozva tervezel, kellő mértékben absztrakt a kódod, hogy ne kelljen szétdúrni és gyors-hatékony lehess. -
#11821
Peter Kiss
őstag
cucka
#11817
Peter Kiss
őstag
Nem írtam le a szkriptnyelveket, de a PHP pont olyan, ami simán le tudja vetkőzni magáról a szkriptnyelvségét, és klasszul lehetne használni, csak épp az elterjedtsége ellenére is kevesen próbálkoznak kiaknázni minden lehetőségét.
Mit vett át funkcionális nyelvekből?
Java-ban nem szeretnék fejleszteni, .NET-ben lehetőségem van minden nap (@Soak: termelő vállalatnál kell ügyviteli és termeléstámogató szoftvereket fejleszteni, sajnos eddig szinte csak legacy [és szar] kódokat kellett támogatni). De akkor végül is azt mondod, hogy PHP-val hegesszen mindenki úgy, hogy csak az adott problémára koncentráljon, legyen kész, és rendben is van a dolog?
Overgeneralization-től még nagyon messze vagyunk, nyilván nem kell minden üzleti problémára egy mindent tudó solver-t írni, de azért arra oda kell figyelni, ne legyen semmi sem túlságosan összedrótozva. Premature optimization valóban veszélyes lehet, de igazából csak azt fenyegeti, aki rettentően unatkozik, és valamilyen oknál fogva előre látni véli a rossz teljesítményű pontokat.
Azért, mert dolgoznod kellett egy rosszul megírt keretrendszerrel, még nem jelenti azt, hogy mindenhol rémeket kell látni.TDD-hez nem elég a modularitás, mert simán tudsz olyan kódot írni (OO vagy nem OO), amit egyszerűen nem bírsz tesztelni, vagy nagyon nagy mocskot kell csinálnod, ezzel szemben egy interface-ből stub-ot/mock-ot hegeszteni nem nagy mutatvány. (Smoke tesztnek tényleg nincs köze az OO/nem OO dologhoz (bármit lehet rosszul tesztelni), de nem is azért írtam.)
-
#11815
Peter Kiss
őstag
cucka
#11808
Peter Kiss
őstag
Tudom, hogy a PHP script nyelv, de az is baj, hogy ebből nem bír kinőni, pedig egyre komolyabb dolgokra képes, illetve a Zend is próbál mindig jobban arra sarkallni, hogy objektumokkal dolgozzunk. Ezt annyira komolyan gondolom, hogy hobbiként fejlesztett rendszeremben a super global tömböket se kell használni.
Emellett nem is szeretek úgy gondolkodni, hogy van egy feladat, aztán azt a lehető legegyszerűbb, legrövidebb módon oldjuk meg, mert mi történik akkor, ha jön egy hasonló? Duplikálás. Nyilván a fenti kérdés egy kis dologra vonatkozott, de, ha esetleg van valami cifra folytatása, már megérhette, illetve abban az esetben, ha több helyen kell valamit használni (itt például a táblázatos történetet, a parser sántít).
Azt mondom, nem érdemes kicsiben gondolkodni.Mikor van hatalmas előnye annak, ha mindent a lehető legabsztraktabb módon írunk le? Akkor, ha tesztelni is akarjuk a kódunkat! Ha valaki fejlesztett már TDD módon úgy, hogy nem csak a covarege-et nézte, és gyártott a smoking test-eket, akkor tudhatja, hogy a jó tesztek kikényszerítik a fentebb látható kódstruktúrát, mert egyszerűen kell.
Mindenki elindulhat a saját útján, én megmutattam egyet, én hogyan csinálnám, akinek tetszik, használja, akinek nem, az ne (csak nehogy egyszer én legyen a projektvezetője
).---
#11809
"amennyiben valaki már érti" - ez a varázsgondolat
Ha jó a kód, ordít magáról, hogyan kell használni. Nyilván, a PHP-nak itt vannak korlátai, de azért nem olyan rossz a helyzet. A fenti kódra szerintem senki sem tudná azt mondani, hogy nem tudja használ (a parser itt is kivétel, annak még bőven alá kellene dolgozni).---
#11810
Nem vagyok programozó, szoftverfejlesztést szeretem, illetve az architect jellegű kérdésekkel, megoldásokkal foglalkozni.---
#11814
Egyik tervezési mintát sem kell vakon követni, hiszen nem előírások, csak megfigyelt jó fogások, vagy épp rosszak. Amit mindig be kell tartani: egy osztály/metódus egy problémát oldjon meg, mindig mondja el, mire van szüksége a működéséhez, és minden a lehető legabsztraktabb maradjon. Ha valaki ezeket szemmel tartja, nagy baj nem történhet. -
#11812
Sk8erPeter
nagyúr
cucka
#11811
Sk8erPeter
nagyúr
"Nem az, ha valaki az informatikában megmondja a tutit, hogy csak és kizárólag egy módszer az elfogadható, na ő téved"
Na igen, én is ezt fejtegettem, hogy ne akarjuk itt megmondani a "one and only" módszereket.Azutánira: szintén egyetértek, ha valaki igazi OOP-s környezetet akar, akkor álljon át valamelyik webes Java-technológiára vagy például ASP.NET-re.
Persze ettől függetlenül nem megkérdőjelezhető az OOP létjogosultsága sem a PHP-ben.
Ahogy az is igaz, hogy amennyiben valaki az előbb említettekben IS programozik, annak az agya nyilván sokkal inkább rááll az OOP-s gondolkodásra, és nem valószínű, hogy engedni akar belőle (tehát ennek mentén fog kódolni PHP-ben is, amivel nincs baj). Viszont ez nem jelenti azt, hogy egy procedurális kód szar (sőt, nagyon jó is lehet, és nagyon nem arra utal, hogy az aszerint kódoló fejlesztő keveset tud [ettől a megjegyzéstől az agyam kinyílt]). -
sztanozs
veterán
Amit a felhasználó írhat be, az el is lesz írva... Láttam én már nagy adatbázisokat (neveket, címeket) a felhasználók (vagy akár az operátorok) által felvíve - rémálom volt. Hát ha még mezőnév is általuk definiálható, akkor kész az idegbaj. Persze nem most, majd pár száz/ezer rekord múlva
Tehát a htaccess átirányított mindent az indexre ahogy addig is, de nem volt ami feldolgozza. Magyarul kezdettől fogva minden jól működött, egyszerűen csak láma voltam. 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mondjuk ezen legalább jót röhögtem. 
é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.
Hogy jön ide a get_defined_vars(), amikor csak egyetlen változó meglétét szeretnéd ellenőrizni? Ez a függvény egy komplett tömböt ad vissza az adott scope-ban elérhető lokális/globális/szerver/környezeti változókról, tehát tartalmazni fogja a $GLOBALS tömb dolgait, a $_SERVER dolgait, és így tovább... ezután ezen a tömbön fogsz kiadni egy isset()-et, és akkor ugyanott vagy, vagy ezt most hogy értetted?
Ezek szerint mégis elbeszélünk egymás mellett. Ki a francot érdekel a NuSOAP? Engem nem, mert nem erről beszéltem, nem a NuSOAP library fikázása volt a cél, már megint terelődik a téma egy halott irányba. Most tényleg el kell, hogy magyarázzam még többféleképpen is, hogy nem a library-vel magával van bajom, hanem azzal, hogy a típusosság hiánya miatt nem lehet egy ilyen tök felesleges időelb@szó munkát automatizálni ÚGY ÁLTALÁBAN PHP-ben, hogy pár klikkel ezt a részét megoldjam, és az ÉRDEMI programozási feladatokkal foglalkozzak?
Új hozzászólás Aktív témák
Hirdetés
- SD-kártyát vennél? Ezért ne csak a GB-ot nézd! – Tech Percek #9
- AMD K6-III, és minden ami RETRO - Oldschool tuning
- Macron betiltatná az EU-ban a közösségi médiát a 15 év alattiaknak
- Gaming notebook topik
- Atomenergiával dübörögnek tovább az Amazon adatközpontok, SMR-ek is jöhetnek
- Luck Dragon: Asszociációs játék. :)
- Plazma TV topic
- Háztartási gépek
- f(x)=exp(x): A laposföld elmebaj: Vissza a jövőbe!
- Trollok komolyan
- További aktív témák...
- Apple Ipad 10.generáció
- Új HP Pavilion x360 14-ek Érintős hajtogatós Laptop Tab 14" -35% i5-1335U 8/512 FHD IPS Iris Xe
- RTX 4080 SUPER,16GB. Ryzen 7 7800X3D, 32 RAM Fury RGB! Garancia!
- Asztali PC , i7 9700K , RX 5700 XT , 32GB DDR4 , 500GB NVME , 1TB HDD
- Dell Inspiron 5406 2-in-1i5-1135G7 16GB DDR4 3200 512GB NVME 14" FHD Érintőkijelző W11Pro
- Keresem : Lenovo Legion 5 16IRX9 83DG0037HV
- ÁRGARANCIA!Épített KomPhone i3 10105F 8/16/32GB RAM RX 6500 XT 4GB GAMER PC termékbeszámítással
- ÁRGARANCIA!Épített KomPhone i9 14900KF 64GB RAM RTX 5080 16GB GAMER PC termékbeszámítással
- Samsung Galaxy Xcover 5 64GB Kártyafüggetlen, 1Év Garanciával
- BESZÁMÍTÁS! Apple MacBook Pro 14 M4 MAX 36GB RAM 1TB SSD garanciával hibátlan működéssel
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest