- One mobilszolgáltatások
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Milyen okostelefont vegyek?
- Mobil flották
- iPhone topik
- Huawei Mate 50 Pro - blendemonda
- Samsung Galaxy Watch6 Classic - tekerd!
- Honor 200 Pro - mobilportré
- Megérkezett a Google Pixel 7 és 7 Pro
- Samsung Galaxy Watch7 - kötelező kör
Új hozzászólás Aktív témák
-
cucka
addikt
-
cucka
addikt
válasz
#68216320
#17264
üzenetére
Ez esetben generáld le a képeket on-the-fly. Nem tudom, minek kell sz*pasd magad a base64-el. PHP-ból ugyanúgy ki tudsz szolgálni egy bináris jpeg filet, mint egy sima html-t, csak be kell állítani a megfelelő header-öket.
(Arra gondolj, hogy ha van egy html oldalad ahol van 100 ilyen generált kép, na az lassú lesz. Ez esetben fizess be egy nagyobb tárhelyre és generáld le előre a különböző verziókat. Esetleg csinálhatsz intelligens cache-elést, ahol a gyakran használt fileokat legenerálod előre, a ritkábbakat meg ad-hoc. Ez van, szarból nem lehet ostort fonni.) -
cucka
addikt
válasz
DNReNTi
#17244
üzenetére
A kérdésedre a válasz egyértelmű lesz, amint megérted, hogy mit is csinál a htaccess-ed.
Röviden: a mod_rewrite apache modult használod. Ez arra jó, hogy ha bejön egy kérés a webszervernek, akkor azt bizonyos feltételek esetén átváltoztatja egy másik request-é.
Például adott egy ilyen URL, hogy http://itcafe.hu/tema/php_kerdesek_2/hsz_17201-17300.html
Valószínű, hogy ez nem egy létező filera mutat egy szerveren, hanem a mod_rewrite átírja valami hasonlóra:
http://itcafe.hu/forum.php?name=php_kerdesek_2&from=17201&to=17300
Csak példa, nem tudom, hogy működik valójában a RIOS..Alapesetben az Apache webszerver egy adott könyvtárban található fileokat tud kiszolgálni. Tehát fenti esetben ha nem lenne mod_rewrite, akkor a hsz_17201-17300.html nevű filet kerené az URL-ben megadott könyvtárban.
A te esetedben ugyanez történik. Létrehozol egy rewrite szabályt, ami csak akkor teljesül, ha a hivatkozott tartalom nemlétező file és nemlétező könyvtár (ez a két RewriteCond). Az átírási szabály az átdobja a PHP-nek a kérést. (Ez a RewriteRule sor)Namost ez azt eredményezi, hogy MINDEN olyan kérést, ami egy nemlétező filera vagy könyvtárra mutat, azt át fogja dobni a PHP-nak. Ha írok egy szkriptet ami random fileokat kérdezget a szerveredtől, kb. mindegyik kérésem be fog hívni a php szkriptedbe (hacsak nem találom ki randomra egy létező file nevét a szerveren). Remélhetőleg innen te is össze tudod rakni, hogy az általad vázolt plusz szabály miért csak látszólagos megoldás a problémádra.
A valódi megoldást már leírták, ha így akarod használni a mod_rewrite-ot, akkor a PHP le kell tudja kezelni a hibás request-eket is. Pl.
<?php
function isRequestValid(){
//ezt neked kell megirni
}
if (!isRequestValid()){
http_response_code(404);
die();
}
//a program többi alkatrésze..
?> -
cucka
addikt
válasz
DNReNTi
#17242
üzenetére
A helyedben inkább az érdekelne, hogy ha a kliens lekérdezi a favicont, az miért eredményezi egy php program futását, ami ráadásul turkál valamit az adatbázisban.
(Gondolom egyrételmű, hogy maga a probléma, hogy szar a htaccess-ed.)mod: most látom, hogy pár hsz-el előbb bemásoltad. Én ebből azt olvasom ki, hogy ha a request se nem egy létező file, sem pedig létező könyvtár, akkor átdobja a kérést a php-nak. A fenti feltételek pont teljesülnek, ha egy nemlétező favicon.ico-t kérek a szerveredtől, ezért fog behívni a php-ba.
-
#17231
cucka
addikt
PumpkinSeed
#17229
cucka
addikt
válasz
PumpkinSeed
#17229
üzenetére
A php-ban valóban lassúak a függvényhívások, de ez adottság, nem kell vele foglalkozni. Egy tíz meg százezer soros OOP kódhalmazban nem tudsz mit kezdeni ezzel. Ha elég hardkór vagy, itt elolvashatod, hogy miért van pontosan: [link]
Ha olyan szinten vagy, hogy ez a szűk keresztmetszet, akkor használj HHVM-et, de a PHP7-be igért JIT compiler is hozhat javulást. Vagy egyszerűen vegyél még szervert, olcsóbb, mint azért fizetni a programozót, hogy csökkentse a függvényhívások számát.
Arról nem is beszélve, hogy a jó minőségű kód egyik jellemzője, hogy a függvények elég rövidek és pontosan egy dolgot csinálnak. Szóval sok a függvényhívás és jó mély a stack. -
#15569
cucka
addikt
DeltaPower
#15568
cucka
addikt
válasz
DeltaPower
#15568
üzenetére
Igen. Mondjuk az adatbázis index az konkrétan egy keresőfát épít fel az adott mezőben található értékekből.
Na ha üres a táblám és belerakom az első sort, az egy egy elemű keresőfa lesz. Ha berakom a második sort, akkor egy két elemű keresőfa.(#15562) DNReNTi
Ezzel nálam nem mennél át egy interjún
-
cucka
addikt
Nem igazán. A bináris fák keresőfák. Tehát pl. az adatbázisodban az indexek így vannak megcsinálva. Meg az adott nyelv implementációja is felhasználhatja.
A valóságban (meg főleg webprogramozásnál) legfeljebb normál fákkal találkozol, de azzal elég gyakran.(#15566) DeltaPower
1 "leágazás" miért nem lehet? Enélkül nehéz elképzelni egy 2 elemű bináris fát. -
#15498
cucka
addikt
DeltaPower
#15493
cucka
addikt
válasz
DeltaPower
#15493
üzenetére
Ez mintha egy captcha generátor lenne, azokban szokták ezeket a betűket kihagyni a vizuális hasonlóságuk miatt...
Jelszónál is érdemes. El sem hinnéd, hogy hány 1bites felhasználó van, aki a generált jelszót kézzel írja át, nem kopipészteli.
Amit érdemes kiszedni: 0,1 számjegyek, L, O, I betűk (kicsi és nagy) és p,q betűk.Ez a kód amúgy olyan, mint ha a "legszarabbul megírt jelszógeneráló függvény" versenyre készült volna. Nem működik, olvashatatlan, tesztelhetetlen és legalább még lassú is.
-
#15295
cucka
addikt
Sk8erPeter
#15293
cucka
addikt
válasz
Sk8erPeter
#15293
üzenetére
Csak én vagyok olyan ufó, hogy ha egy technológiával kell dolgoznom, amihez nem értek, akkor előtte elolvasok róla egy könyvet, hogy tudjam, miről van szó, én nem csimpánzként másolgatok össze vissza ismeretlen kódokat reménykedve abban, hogy véletlenül működni fog?
Ennek a topiknak a fele kb. ilyen triviális fasság, amit egy php könyv első 250 oldalának elolvasása után senki se tenne fel. Például biztos minden php könyvben van egy fejezet a filefeltöltésről. Mondjuk 40 oldal. Nem egy nagy kalad, egy délután alatt elolvasható, kitanulható alapszinten. Ehelyett szerintem még mindig azzal a foshalmazzal megy a küzdelem, amit ideposztolt. Nem fér a fejembe. -
#15292
cucka
addikt
trisztan94
#15286
cucka
addikt
válasz
trisztan94
#15286
üzenetére
Ettől a kódtól kiég a retinám b+
-
#15270
cucka
addikt
trisztan94
#15267
cucka
addikt
válasz
trisztan94
#15267
üzenetére
Jelszó hash-eléssel kapcsolatban lenne egy kérdésem.
A standard válasz erre, hogy "google bazmeg".
Amúgy ha php 5.5 van, akkor használd a password_hash(), password_validate() függvényeket.
Régebbi verziókhoz itt van megoldás: [link] procedurális és oop implementáció.
Nem kell feltalálnod a meleg vizet.Egy másik gyors kérdés.
Deklaálod globálnak
global $valtozo;
Vagy beannotálod
/**
* @var $valtozo
*/Nem próbáltam ki, de én ezekkel támadnám meg a problémát.
-
cucka
addikt
válasz
DNReNTi
#15266
üzenetére
Az első ciklusban érték szerinti értékátadást használsz a ciklusban. Ez úgy működik, hogy az $uj_tomb[0] értéke a $regi_tomb[0] értékének másolata. Tehát a háttérben egy darab memória tartalmát átmásolja egy másik memóriaterületre.
A második ciklusban referencia szerinti értékátadás történik. Ez úgy működik, hogy az $uj_tomb[0] semmi más, csak egy új név ugyanarra a memóriadarabra, amire a $regi_tomb[0] is mutat. Lényegében ez egy alias. Ha az egyik értékét módosítod, a másik is módosul. A memória, amire mutatnak, csak akkor fog felszabadulni, ha mindkét változót törlöd (unset) - ez fasza memory leak forrás, oda kell rá figyelni.
A harmadik ugyanaz, mint a második, csak for helyett foreach ciklussal. Többnyire ezt érdemes a for ciklus helyett használni.
Ja, és az ne zavarjon meg, hogy a tömbök 0. elemével írtam a példát, a fentiek bármilyen változóra igazak. Továbbá z objektumok érték szerinti átadása totál máshogy működik.
-
#15255
cucka
addikt
trisztan94
#15251
cucka
addikt
válasz
trisztan94
#15251
üzenetére
Hogy erted azt, hogy bebugyolaltam egy metodust egy masikbs?
Úgy, hogy a metódusaid többsége semmit sem csinál, csak meghív egy másik metódust. Tehát a kódod nagy része teljesen fölösleges zaj a kódbázisban. -
cucka
addikt
válasz
DNReNTi
#15232
üzenetére
Például olyan metódusokban nem szoktam használni ahol a szerver oldal ad át ellenőrzött paramétert, mondjuk egy user_id-t, azaz garantáltan nem jelent veszélyt.
És mi van, ha újra szeretnéd hasznosítani azt a metódust? Vagy csapatban dolgozol és a másik ember szeretné használni a metódusaidat? És ha mondjuk egy 1 év múlva lesz, amikor már nem emlékszel pontosan, hogy mely metódusokba építettél biztonsági lyukat lustaságból? -
-
#14989
cucka
addikt
fordfairlane
#14988
cucka
addikt
válasz
fordfairlane
#14988
üzenetére
Szerintem nincs félreértés. Annyi van, hogy objektumot csak explicit módon tudsz érték szerint átadni (értsd: manuálisan le kell klónozni, majd a másolattal hívni a kérdéses függvényt/metódust)
-
cucka
addikt
Arra jó, ha olyan függvényt szeretnél írni, ami a paraméteren végez műveleteket és nem tér vissza semmivel. (Vagyis hát visszatérhetsz, de minek szopasd magad még jobban?) . Más szóval a függvényednek mellékhatásai vannak.
Amúgy nem javaslom a használatát, előnyösebb, ha a függvények mellékhatásmentesek.(#14983) fordfairlane
Szerintem nem keverte senki, jól írták. (Referenciatípus az nem is tudom, hogy micsoda amúgy
) -
#14947
cucka
addikt
Sk8erPeter
#14945
cucka
addikt
válasz
Sk8erPeter
#14945
üzenetére
Az egész WP kódbázis olyan, mint a f*szom, egy igazi csődtömeg, bottal sem piszkálnám. Szóval ez a linkelt idézet teljesen beleillik a képbe.
-
cucka
addikt
válasz
CSorBA
#14937
üzenetére
A key a tömb belső pointeréhez tartozó kulcsot adja vissza. Lásd next, prev, end, current
pl így tudod kiiratni a kulcsokat.
$tomb["geza"] = array("gyumolcs" => "alma", "szin" => "piros");
$tomb["zsolt"] = array("gyumolcs" => "szilva", "szin" => "lila");
$tomb["agnes"] = array("gyumolcs" => "citrom", "szin" => "sarga");
while (null !== key($tomb)){
print key($tomb)."\r\n";
next($tomb);
}
mod: amúgy használj foreachet. ez a tömb belső pointeres dolog farokság. -
#14917
cucka
addikt
Sk8erPeter
#14914
cucka
addikt
válasz
Sk8erPeter
#14914
üzenetére
Félreérted. Ez igazából saját tapasztalat meg okosok is mondják, hogy nagyobb módosítások után érdemes refaktorálni. Vagy ha költőien akarod: ha nem teszel ellene, a kód mindig a rendezetlenség (spagettifikálódás) felé tart. Akkor is, ha nagyon ügyes meg hozzáértő vagy.
Meg aztán válaszoltál egy működő megoldással, ennél informatívabb nem lehetett volna, nem értem a felháborodást ezen, nem is gondoltam erre. -
#14912
cucka
addikt
Sk8erPeter
#14911
cucka
addikt
válasz
Sk8erPeter
#14911
üzenetére
a te kódodon gyönyörűen látszik, hogy hogyan kezd spagettifikálódni a rossz legacy kód, ha új fícsört kell hozzáadni.
-
cucka
addikt
válasz
rgeorge
#14489
üzenetére
Kód nélkül nehéz okosat mondani. Most érted, egy ilyen xml gyártás és elküldés nagyjából ugyanúgy néz ki php-ban, mint más nyelvekben, és a megoldási lehetőségek is nagyon hasonlóak. Szerintem a legalószínűbb, hogy a php-s fejlesztők balf*szok, ez ellen meg nem fogsz tudni sokat tenni. Vagy ráveszed őket, hogy csinálják meg, vagy nekiülsz te megcsinálni helyettük.
-
-
#14249
cucka
addikt
PumpkinSeed
#14248
cucka
addikt
válasz
PumpkinSeed
#14248
üzenetére
Oreilly PHP The good parts elég jónak tűnt. Meg van egy Expert PHP And MYSQL a Wroxtól, szintén nem rossz, meg ha jól rémlik, valami nagyon hasonló cucc az Apress-től is. PHP Fekete könyv szintén nem volt rossz, de nem tudom, van-e belőle friss kiadás.
Magyar nyelven a jó könyvek töredéke jelenik meg, szóval ez nagyon rontja az esélyeidet. Amire még érdemes odafigyelni, hogy friss php verzióval foglalkozzon a könyv. 5.x verziókban elég sok újítás volt, amikkel érdemes tisztában lenni, szóval 2010-2011 előtti könyvre én nem pazarolnám az időmet. A "24 óra alatt" könyveket felejtsd el.
-
#14232
cucka
addikt
PumpkinSeed
#14230
cucka
addikt
válasz
PumpkinSeed
#14230
üzenetére
Ha jót akarsz, akkor tényleg kidobod ezt a könyvet, pl. tisztán látszik, hogy register_globals használatára tanít, ami annyira rossz elképzelés volt, hogy az újabb verziókban már a bekapcsolása is fatal error-t ad.
(Amúgy mi az, PHP4 24 óra alatt? Abban voltak ilyen kódok) -
#14216
cucka
addikt
PumpkinSeed
#14214
cucka
addikt
válasz
PumpkinSeed
#14214
üzenetére
Ha a continue lefut, akkor nem fogja megnövelni a $asd-t, tehát végtelen ciklusba kerül.
Írd át for ciklusra és jó lesz. -
#14121
cucka
addikt
Tele von Zsinór
#14118
cucka
addikt
válasz
Tele von Zsinór
#14118
üzenetére
Néhány apróság:
- A PHPUnit egy automatizált teszt framework. Bármilyen típusú teszteket írhatsz benne, nem csak unit tesztet.
- Kétszer is gondold meg, mielőtt belevágsz abba, hogy egy webes UI-ra teszteket írj, mondjuk Seleniummal. Elég sokat lehet szívni a tesztek karbantartásával, TDD is nehézkes, stb. -
-
cucka
addikt
Kapcsolótáblára akkor van szükség, ha egy bejegyzésnek több szerőzje is lehet.
Tehát ha pl. a közeljövőben szeretnél olyan fícsört, hogy egy bejegyzést több felhasználó is szerkeszthet, és ezt a rendszer nyilván is tartja, akkor készíts kapcsolótáblát.Ha egy bejegyzésnek pontosan egy szerzője van, akkor a többiek által leírt megoldás a nyerő.
-
cucka
addikt
Azt, hogy az adott osztályt a gyökér namespace-ben keresse a php.
Amikor hivatkozol egy osztályra, azt mindig az aktuális namespace-ben fogja keresni a php. Tehát ha a kódodat berakod egy saját namespace-be, akkor így szólsz a php-nak, hogy a hivatkozott osztályt melyik namespace-ben keresse.
Ilyen esetekre van a "use", amivel be tudod húzni a "neveket" a saját namespace-edbe. -
#13520
cucka
addikt
fordfairlane
#13519
cucka
addikt
válasz
fordfairlane
#13519
üzenetére
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
Az 5-ös verzió 9 éve jelent meg, az 5.2 pedig 7 éve, szóval ezek már jó ideje lejárt lemezek.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.
A class loadert kezeli a framework, vagy megírod egyszer és jól van. Tény, nem túl elegáns, de azért ez nem akadálya a komoly programok fejlesztésének.
Az 5.3 pedig 4 éve jelent meg, szóval lassan már ez is lejárt lemez. Inkább baj, hogy mennyire bénán implementálták a namespace-eket.Ezen kívül vannak olyan tulajdonságai, ami arra csábítanak, hogy kuplerájt hagyjon maga után a programozó.
Azért ez sem megoldhatatlan probléma egy komoly projektnél. Ha én enterprise szoftvert fejlesztek php-ban, akkor miért kell érdekeljen, hogy a kezdő pistikék szar kódot is tudnak akár írni?Nincs szétválasztva a megjelenítés az alkalmazáslogikától, a PHP egyben template-nyelv is.
Ez mondjuk egy mvc framework dolga, nem a nyelvé. Ha írok egy egyszerű java programot, ami csinál valami számításokat, majd kiírja az eredményt a konzolra, akkor erre sem teljesül az alkalmazáslogika és a megjelenítés szétválasztása. Most ettől rosszabb nyelv lesz a Java?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.
Mert amúgy melyik nyelvben van szabványos URL-metódus mapping? Ezt mindenhol a library-k intézik. (Egyáltalán, hogy kéne elképzelni, hogy ez egy általános célú nyelv része legyen?)Szóval na, ez így távolról sem volt meggyőző.
-
#13518
cucka
addikt
fordfairlane
#13517
cucka
addikt
válasz
fordfairlane
#13517
üzenetére
Mit jelent az az "összetett programstruktúra", amit a php hiányosan támogat? Tudsz példát?
-
cucka
addikt
-
cucka
addikt
válasz
Lacces
#13305
üzenetére
Fát kell építeni és nem bonyolult.
1. Beolvasod az összes menüpont adatait egy tömbbe. Az adatbázisban eltárolod minden elemhez, hogy a struktúra hanyadik szintjén van, így aszerint rendezve tudod lekérdezni. Ezzel biztosítod, hogy egyszer végiglépkedve a tömbön fel tudd építeni a fát.
2. A tömbön végigmész és felépíted a fát. Egy elemet tárolhatsz egy tömb elemeként vagy objektumként is, mindegy, én OOP-t javaslok.
3. Szélességi kereséssel végigiterálsz a fán, kiírod a menüt. Ha OOP-sen építetted fel a fát, akkor a fa elemei "ki tudják írni magukat", szóval egész elegánsan megoldható. -
cucka
addikt
-
#13227
cucka
addikt
Sk8erPeter
#13221
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) -
#13217
cucka
addikt
Speeedfire
#13215
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. -
#13214
cucka
addikt
Speeedfire
#13213
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. -
#13212
cucka
addikt
Speeedfire
#13211
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. -
#13177
cucka
addikt
Speeedfire
#13176
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.
-
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.
-
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. -
#13122
cucka
addikt
fordfairlane
#13121
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.
#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. -
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. -
#13010
cucka
addikt
Sk8erPeter
#13008
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)
-
#13007
cucka
addikt
lordjancso
#13003
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.) -
#13001
cucka
addikt
Sk8erPeter
#12993
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. -
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? -
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? -
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. -
#12844
cucka
addikt
fordfairlane
#12843
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
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.
-
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. -
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. -
#12798
cucka
addikt
Peter Kiss
#12797
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
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. -
#12703
cucka
addikt
Sk8erPeter
#12701
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
#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ő?
-
cucka
addikt
válasz
Vision
#12640
üzenetére
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. -
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
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.
-
#12156
cucka
addikt
Speeedfire
#12155
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. -
#12153
cucka
addikt
Peter Kiss
#12151
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. -
#12149
cucka
addikt
Sk8erPeter
#12148
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. -
#12145
cucka
addikt
Sk8erPeter
#12144
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
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? ) -
#12140
cucka
addikt
Sk8erPeter
#12139
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
#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
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. -
#12034
cucka
addikt
Sk8erPeter
#12029
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
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. -
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
#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
#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? -
#11883
cucka
addikt
Peter Kiss
#11879
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.
-
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-é. -
#11864
cucka
addikt
Peter Kiss
#11862
cucka
addikt
válasz
Peter Kiss
#11862
üzenetére
"~2 éve nem is fejlesztek php-ban" - így egy kicsit világosabb, miért írtad azokat, amiket.
Márhogy pontosan mi lett világosabb ettől az információtól?
(Amúgy igen, maradtam a szkriptnyelv vonalon, de lehet, hogy 1 éven belül már java fejlesztő leszek, legalábbis ez a valószínű forgatókönyv)
Új hozzászólás Aktív témák
Hirdetés
- ThinkPad T14 Gen4 14" FHD+ IPS érintő Ryzen 5 PRO 7540U 16GB 256GB NVMe ujjlolv IR kam gar
- 16GB-os SODIMM (notebook) DDR4 RAM bazár - nézz be, lesz, ami kell neked!
- HP 15-af105nh laptop (15,6FHD/AmdQuad/4GB/128SSD/Magyar) - Akku X
- JOYOR S5 Pro 10" Elektromos Roller 26Ah Akkumulátorral Moddolt!
- XPS 13 9310 13.4" FHD+ IPS i7-1185G7 16GB 512GB NVMe ujjlolv IR kam gar
- Telefon felvásárlás!! Samsung Galaxy S23/Samsung Galaxy S23+/Samsung Galaxy S23 Ultra
- Így lesz a Logitech MX Keys magyar billentyűzetes
- VÉGKIÁRUSÍTÁS - REFURBISHED - Lenovo ThinkPad 40AC Thunderbolt 3 docking station
- ÁRGARANCIA!Épített KomPhone Ryzen 7 9800X3D 32/64GB RAM RTX 5070Ti 16GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! ASRock Z370 i5 8500 16GB DDR4 512GB SSD 2060 Super 8GB Zalman Z9 Plus Enermax 750W
Állásajánlatok
Cég: PC Trade Systems Kft.
Város: Szeged
Cég: PC Trade Systems Kft.
Város: Szeged