Keresés

Hirdetés

Új hozzászólás Aktív témák

  • Sk8erPeter

    nagyúr

    válasz Lacces #7983 üzenetére

    Nincs baj a XAMPP-pal, valóban jó kezdőknek, de mondjuk szerintem ez inkább Windows-nál igaz, mert Linux-disztribúciók esetén ahogy Tele von Zsinór említette, többnyire lehetőség van arra, hogy egyszerre lehúzd az összes függőséget pl. phpMyAdminhoz, ez ugyanúgy telepít is mindent, amire szükséged lehet. Windows-nál meg ez megoldandó kérdés, így ott EasyPHP, XAMPP, AppServ, amit általában elsők között említenek, mert ez egy csomagban felrak mindent, ami egy alapvető webszerverhez kellhet.
    Mondjuk IIS-nél is van ilyen függőség-ellenőrzés, erre példa a Drupal vagy Joomla, ha rámész Web Platform Installer használatánál, hogy töltse le őket, akkor eleve függőségként lehúzza a PHP-t és MySQL-t is. (Amúgy érdekes, hogy úgy tűnik, a Microsoft nyit az opensource-dolgok felé is.)

    "Furcsa mód, itt kérte telepítésnél a mysql, egy felhasználót, és egy jelszót! (úgyhogy így utólag értem már mire gondolsz, ha erre gondoltál)"
    Nem, nem erre gondoltam. :D Amikor telepíted a MySQL-t, kell egy root felhasználó is, aki az egésznek az adminisztrátora, mindenféle joggal. A phpMyAdminnál van egy kontrollfelhasználó is, ami pl. "könyvjelzőzni" tud bizonyos query-ket, naplózni különböző szempontok alapján, stb., ennek nem szabad megadni a root-jogot (ne legyen már mindenhez joga, mi van, ha pl. biztonsági rés vagy egyéb hiba maradt a "rendszerben", akkor ne csinálhasson bármit). Kell a phpMyAdminnak egy külön tábla MySQL-ben (persze ez elvileg nem kötelező), ebbe írogathat, de ahhoz hozzá is kell férnie.
    Amúgy egyáltalán nem fértél hozzá a MySQL-hez?

    "Tudom, hogy a var/www-ben kell lenni a weboldalnak amit kezelni akarok."
    Nem, oda rakod, ahova akarod, csak legyen elérhető a webszerver számára, és konfigold úgy a webszervert, hogy az adott domain document rootja ide legyen irányítva.

    "1. HOgyan tudom ezekután a böngészőből elérni a phpmyadmin-t?"
    Nem értem a kérdést.
    Húzd le az egész csomagot úgy, ahogy Tele von Zsinór mondta.

    2. kérdésre: a PHP futtatásához webszerver kell (vagy konzolon keresztül is tudod futtatni, de ezt most hagyjuk), különben nem fog futni a PHP interpretere, értelmezője/"fordítója", így a kódod nem fog "lefordulni".
    A HTML-kódok megjelenítéséhez ez nem szükséges, azok kódját a böngésző értelmezi és megjeleníti.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Sk8erPeter #7984 üzenetére

    Na basszus, erre csak elrontottam, tehát korrigálnám magamat:
    "Pl. konzolból futtatva, ha nem akarom, hogy bármit is írjon az stdoutra: curl example.com/cron.php"
    NEM, hanem:
    curl example.com/cron.php>NUL
    Tehát legyen átirányítva az stdout a NUL-ra, ha Windows-ban batch-fájlból vagy konzolból hívom meg az említett cURL-t.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #7999 üzenetére

    Akkor majd ezentúl Te is legyél türelmesebb, full 0-ról nem olyan egyszerű, mindenki végigszopja egyszer ezeket a folyamatokat, akiknek nem vezették a kezét. :D (És ez a párórás szívás még mindig semmi! Lesz ez még szarabb is! :D)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Siriusb #8003 üzenetére

    Hát igen. Amúgy miután ezeken a fázisokon végigment az ember, még mindig könnyű hibát véteni a konfigfájlban, aztán nézni, hogy most mi van má' megint (persze kellő szopás után viszonylag gyorsan rájössz a hibaüzenetekből, de akkor is idő megy vele). Ezért volt nekem felüdülés, vagy inkább kellemes meglepetés az IIS admin-felülete (alapvetően eléggé ódzkodtam tőle, míg ki nem próbáltam). Összekattintgatod, és egyszerűen mennek az oldalaid.
    Nem is igazán világos, normális grafikus felület miért nem készült még Apache-hoz - csak ilyen: [link], de próbáltam, még mindig elég silány, csak a konfigfájlt állítod, még mindig el lehet cseszni, és ettől kezdő nem kattintgatja össze az oldalt -, azért ennyire senki nem lehet konfigfájl-buzi. :D (na jó, de)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8005 üzenetére

    Ennek semmi köze a XAMPP-hoz! Legfeljebb annyiban, hogy ott alapból a php.ini-ben nem voltak elnyomva a hibajelzések.
    De ez nem "debugger", ne keverjük a fogalmakat. Ez csak simán kiírja a hibaüzeneteket.
    Kotord elő a php.ini-t, és keresd meg az error_reporting részt.
    Nézd meg, hogy jelenleg mi van beállítva.
    Én ezt a beállítást javaslom fejlesztésre:
    error_reporting = E_ALL | E_STRICT
    Ez a "legszigorúbb" hibajelzés, mindent kiír.
    Egy igényes programozó megszünteti a hibajelzések okát, nem pedig láthatatlanná teszi őket.
    Engem személy szerint kiráz a hideg attól a mentalitástól, hogy "ugyan már, ki nem szarja le a notice-okat, nyomjuk el, nem kell annak látszania, szedjük ki az error_reportingból, azt kész, meg van oldva". Na persze, majd amikor azzal fog a fejlesztő időt elkúrni, hogy rájöjjön, vajon miért nem működik valami (pl. tömbindexelésnél elgépelés miatt), akkor változtat a hozzáállásán. :) (vagy nem, az a menthetetlen eset)
    Aztán keresd meg a display_errors-t:
    display_errors = On
    Ha még alaposabban szeretnéd:
    display_startup_errors = On

    Viszont fontos hozzátenni, hogy ezek a hibajelzési beállítások csak a fejlesztési fázisra vonatkoznak. Utána szigorúan tilos kiíratni ezeket a hibákat! Többek közt az is egy sebezhetőségi pont. Az éles rendszeren kezeld a hibákat megfelelően, csakis belső naplózást használj a hibajelzések tárolására, ne írass ki belőlük egyet sem.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8017 üzenetére

    Most kezdőként komolyan webáruház fejlesztésével akarsz kezdeni? Szerintem tegyél le róla. Nem azért, mert képtelen lennél megcsinálni, hanem mert olyan szinten komplex, és elképesztő időelkúró tevékenység, de legfőképp azért, mert nagyon jó webshopmotorok vannak készen, amiket folyamatosan foltozgatnak az esetleges felfedezett biztonsági vagy egyéb hibák miatt. Így egyre nehezebb feltörni és megborítani őket.
    Ha PHP-t szeretnél tanulni, ne webshoppal kezdd, hanem előbb tanulgasd meg, hogy kell formokat validálni, feldolgozni, adatbázisba tölteni az adatait, onnan lekérni a feltöltött adatokat, aztán jöhetnek a komplikáltabb dolgok is.
    Persze ahogy érzed, de én a helyedben tuti, hogy a meglévő igen széles ingyenes webshop-kínálat ismeretében NEM épp webshop kódolásával cseszném el az időt. :D
    De ez igaz szerintem haladókra is, ha nem muszáj, akkor nem elejétől kezdve kellene megírni egy webshopmotort, hanem inkább továbbfejleszteni egy meglévőt.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz wolandino #8028 üzenetére

    wolandino, Lacces: Szívesen. :) Elég szépen összeszedett jegyzet, pedig igényes magyar nyelven írtakból azért nem lehet Dunát rekeszteni.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz #95092224 #8032 üzenetére

    Azt hogy próbálj ki mást :D, pl. az EasyPHP-t, az is elvileg portable.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8040 üzenetére

    Szerintem meg itt köze nincs a mutatókhoz a dolognak (hogy azt akarná "visszahozni").
    Mindenesetre én úgy gondolom, hogy ezzel csak olyan szinten érdemes foglalkozni, hogy tudd, ilyen szintaktika is van, értsd is meg, ha valakinek a kódjában ezt látod, de Te lehetőleg kerüld el messzire. Tök feleslegesen teszi nehezen olvashatóvá a kódodat, nem tudok olyan esetről, ahol ezt ne lehetne kiváltani másik, szebb, átláthatóbb módszerrel. Pl. egy stringnél tök felesleges beleerőszakolni ilyen módon egy összetettebb változót, akkor már inkább válassz alternatívákat.
    Pl. konkatenáld:
    vegyük az általad említett példát átalakítva:
    eredeti:
    echo " {$startYear}–{$thisYear} ";
    helyette szebb:
    echo $startYear . '-' . $thisYear . ' ';
    Nem kell szenvedni vele, hol is ér véget a kapcsos zárójel, plusz egy fejlesztőkörnyezetben jobban láthatóan ki van emelve a változónév (persze, felismeri az IDE, ezt is kiemeli, de amennyiben egyedi módon nem állítottad át valami nagyon elütő színre, akkor a stringen belül, a string default színével csupán félkövéríti, vagy hasonló, tehát akkor is nehezebben észrevehető egy ilyen változónév), ez is segíti az átláthatóságot.
    A printf, sprintf-hez hasonló behelyettesítős módszerek is ezerszer szebbek ennél a kapcsos zárójeles bohóckodásnál.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8042 üzenetére

    Ez minek a kódjából származik? Gondolom valami nagyobb keretrendszerszerűség. Persze ezt is szét lehetne bontani, hogy ne kelljen bogozgatni későbbi kódmódosításkor, de biztos az rengeteget gyorsít a kódon, ha egy sorba tömörítünk mindent. :D

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Peter Kiss #8044 üzenetére

    Hát ez kellemetlen. :D
    Ettől függetlenül nem értem, minek egy sorba nyomorítani az egészet. De félre ne értsd, nem fikázni akarom a kódolási szokásaidat. :D Ízlések és pofonok, csak nekem a hajam kettéáll a bogozandó kódoktól. :D (főleg, hogy feleslegesnek tartom a túlzott rövidítéseket)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8047 üzenetére

    "Főleg, hogy jobb is a konkatenálás, azt a szebb példát, annak külön örülök
    Így van egy Java feelingje az egésznek"

    Attól lesz Java feelingje, hogy van benne egy konkatenálás? :D Hmm.

    Ja, assign - hozzárendeli egy $temp, vagyis átmeneti változóhoz a $_POST tömb aktuális értékét. Itt a foreach ciklusban ugyanis bejár egy tömböt, vizsgálja a tömb értékeit. De gondolom ezt nem kell magyaráznom, ha csináltál már ilyet Java-ban.

    "az expected tömbben található értékek alapján, létrehoz változókat"
    Na, akkor elölről. Az első if-nél azt vizsgálja, a $_POST aktuális tömbindexének értéke ($temp-ben van most) nem üres-e és szerepel-e a $required tömbben. Ha a két feltétel teljesül, akkor valamit mondjuk nem töltöttél ki az űrlapon, berakhatjuk a $missing tömbbe, jelezvén, hogy ez a kulcs hiányzik mondjuk, pampogunk a júzernek, hogy töltse már ki legyen szíves az adott mezőt.
    Egyébként ha a $temp nem üres, az adott kulcs az $expected tömbben van, (pl. kitöltötte az elvárt mezőt), akkor hozzuk létre az azonos nevű változót (pl. $name).

    "Ha létrehozza is őket, akkor ezek sima egyszerű változók"
    Azok milyenek? ;] Gondolom azt a szót keresed, hogy "lokális" változó.
    Attól függ. Ha ez az egész pl. egy függvényben szerepel, akkor csupán lokális scope-ja lesz, a függvényen belül. De lehet akár globális is, ha mondjuk ez egy fájlban "kívül" szerepel ez az egész Onnantól a függvények számára a global kulcsszóval ezek a változók elérhetők, amennyiben nem szüntetted meg azóta pl. unsettel.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz PazsitZ #8050 üzenetére

    Amit most mutattál, az más, mint amiről én beszéltem! Abban a példakódban, amit Lacces mutatott, ott egy stringbe úgy erőszakoltak bele egy változót, hogy bohóckodtak a kapcsos zárójelekkel, amikor totál felesleges, lehetne átlátható módon konkatenálni is egy másik stringet (az általad mutatott példakódban Te meg épp ezt csináltad, jól), és akkor nincs belőle kavarodás. De szerintem korábban is pont ezt írtam, csak más szavakkal. :B

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Retekegér #8055 üzenetére

    Egyéni preferenciáktól, és attól, hogy a szerveren egyáltalán fent van-e és engedélyezve van-e (php.ini-ben) a MySQLi-kiterjesztés. Persze PHP 4-es verziójában még egyáltalán nem fogod tudni használni, mivel ott még nincs, de aki manapság 4-es PHP-t használ...az valahol leragadt az őskorban.

    Egyébként ha választani kell és lehet, érdemes inkább a MySQLi-kiterjesztést használni a klasszikus MySQL-kiterjesztés helyett.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8062 üzenetére

    Szerintem rossz a fájlod (vagy fájljaid) karakterkódolása.
    Rakd fel a Notepad++-t, nyisd meg a fájljaidat, és az "Encoding" menüpontban menj rá, hogy "Convert to UTF-8 without BOM". Ennek megfelelően a meta tagekben is legyen UTF-8 karakterkódolás.
    Meg nyomathatsz egy ilyen headert a PHP-fájljaid elején:
    header('Content-Type: text/html; charset=utf-8');

    Szerk.: Athlon64+ 16 másodperccel előbb írt. :DD

    (#8057) Retekegér: ja, szerkesztettem, mert eszembe jutott, mi van, ha az UW kicsit elmaradt a fejlődésben, és még mindig csak PHP 4 van fent... Mondjuk azért remélem nem. :D

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz PazsitZ #8065 üzenetére

    Ez a PHP-vel utólagosan eltávolítós módszer szerintem csak akkori végső megoldás, ha Te nem férsz hozzá a beolvasandó fájlokhoz, és annak eleve el van cseszerintve a karakterkódolása.

    #8066 Lacces: a preg_replace-es megoldást csak akkor használd, ha nagyon muszáj. :)
    "Notepad++ -ot már akartam, de linuxra nem jön fel a Wine nélkül. Keresek egy linuxos megfelelőt."
    Hasonlóan alacsony erőforrásigénnyel rendelkező, funkciógazdag szövegszerkesztőt én valahogy nem találtam Linuxra, meg mindegyiknek megvolt a maga hülyesége vagy hiányossága (Notepad++-hoz képest, ami elég jól bővíthető pluginekkel is), de most nincs kedvem egyenként felsorolni, mik voltak azok; kényelmi és egyéb szempontok is szólnak részemről a Notepad++ mellett - Wine-nal kicsit nyakatekert megoldásnak tűnik, de én sokszor Linuxon akkor is inkább a Notepad++-t használtam, pont így.
    Vagy ha komplett IDE-t akartam, amire a kis erőforrásigény kevésbé jellemző, akkor NetBeans-t használtam (ahhoz már nem kell Wine).

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8068 üzenetére

    Szerintem használd azt, ami neked kényelmesebb. Az Eclipse és a NetBeans egyaránt teljesen jó lehet. Nem hinném, hogy az Eclipse kevesebbet tudhatna a NetBeans-nél PHP-fejlesztéshez, szerintem mindkettő beállítható úgy, hogy hasonló képességű legyen, de majd szól valaki, ha mégis komoly hiányosságot fedezett fel valamelyikben.

    ... és mindkettő ingyenes... ez eléggé mellettük szól. :)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz raczger #8086 üzenetére

    Szóval akkor röviden összegezve: az az alkalmazás, ami az Androidos proginak szolgáltat adatokat 2 mp-enként, állításod szerint egyáltalán nem is kapcsolódik adatbázishoz, csak megkavar egy tömböt, kiírja az egyik tartalmát, meg csinál egy fájlba írást, igaz? ... és annak ellenére, hogy az Androidos progihoz semmiféle adatbázis-baszkurálás nem kell, azt mondják, durván túl van terhelve az adatbázisszerver. Eddig stimmel?
    "a két sql lekérdezés amit beszúrt nekem az az eredeti oldalamon szokott meghívódni"
    Ezalatt az "eredeti oldalam" alatt mit értesz? Úgy érted, a főoldalon lefut mondjuk egy látogatást mérő szkript, ami beszúrogat adatbázisba, a kis Androidos alkalmazás meg csak valami alkönyvtárban van? Annak a bizonyos scriptnek a lefutása függ sessiontől? (úgy értem, egy session alatt csak egyszer fut le?) Vagy úgy tűnik, minden alkalommal új sessiont kezdeményez? Mert mondjuk ilyen akkor elő szokott fordulni, ha az ember pl. DOMDocument segítségével olvasgat be adott URL-ről visszakapott adatokat. Ehhez hasonló esetben meg, ha valamiért mégis először a főoldalon le tud futni az a bizonyos script, akkor akár előfordulhat, hogy mindig újból és újból lefut... Látható is, hogy az adattábláid durván telítődnek? Vagy milyen változásokat látsz az adatbázisban?
    Bocs, hogy ennyi kérdéssel válaszoltam a kérdésedre, de ezek ismerete nélkül elég nehéz behatárolni szerintem így "külsősként" a problémát...

    ==

    (#8091) Athlon64+ : mutass kódot, ahogy raczger is írta.

    ===
    (#8090) CSorBA:
    Gyors guglizás alapján hátha ez segít, tapasztalatom nincs benne: [link].

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CSorBA #8094 üzenetére

    A phpMyAdminnak van egy config.inc.php fájlja a főkönyvtárában.
    Ebben néhány beállítás található, többek közt a blowfish_secret is, ezt nálam az a setup generálta, ami ott van a /setup cím alatt... ez generálta a config.inc.php-met is.
    Nálam localhoston így néz ki ez a blowfish_secret kód (egy sor a sok közül):
    $cfg['blowfish_secret'] = '4efe8f2e64de52.06461375';

    Valszeg ez nálad nincs beállítva. Vagy valami hasonló. :D

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz raczger #8098 üzenetére

    Hát ennyiből nem tudom, mondjuk azt nem írtad, az Android app helyesen megkapta-e minden alkalommal az adatokat, nem volt-e 404, vagy hasonló, ami miatt mégis a főoldal nyílt meg mondjuk, stb. - meg nem indított-e az Android-app túl sok requestet mindemellett...
    Majd írd meg, ha újból tesztelted, és ezeket mind vágod. :K

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz trickyy #8100 üzenetére

    Mivel a PHP az egyik legnépszerűbb nyelv a webfejlesztés terén, ezért ez bőven kínál munkalehetőségeket is. Na meg nagyon nagy mértékű támogatottságot élvez, így bőven találsz segítséget is hozzá (könyvek, e-tutorialok, e-bookok, fórumok, blogok, stb.), és szoftveres támogatást is (CMS-ek, keretrendszerek, stb.).
    Mindenképp megéri tehát belefogni, persze attól is függ, mennyire gondolod komolyan - ha jól csinálod, nagyon is kifizetődő lehet. Gondolj csak bele: valószínűleg honlapokra még nagyon sokáig szükség lesz... :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz coco2 #8102 üzenetére

    Azért ez annyiban sántít, hogy nem igaz, hogy csak ezekből lehet megélni, és "pénzt szedni". C#-os (webfejlesztésre fókuszálva ASP.NET-es), de akár Objective C-s (ld. IPhone) megoldások is bőven születnek; még mindig él a C++programozás, és még nyilván lehetne sorolni. Mindenféle területen lehet "pénzt szedni". De tény, hogy webfejlesztésben nem lehet elmenni a PHP mellett.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz coco2 #8113 üzenetére

    Nézd meg a tárolt eljárások meghívását PDO-val: [link]. Példákat is ír rá.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz CSorBA #8122 üzenetére

    Miért pont Java?
    Csak érdekel az indok, meg az, hogy egyikőtök sem említette a C#-ot, mint lehetséges alternatívát, ha már "nem scriptnyelvekről" beszélünk.

    ===

    (#8119) Bencom ™ : többiek a lényeget már elmondták, de amúgy a suliban, ahova jársz, nincs műszaki könyveket is elérhetővé tevő könyvtár? Elég jó írásos könyvek is vannak a PHP-ről.
    Amúgy mielőtt ilyenbe belevágsz, egy kicsit kisebb dolgokban gondolkodj, szerezz tapasztalatot. Lehet, hogy nagyon mainstreamnek tűnik, de PHP-ben először tanulj meg viszonylag szimpla dinamikus honlapokat készíteni. Aztán jöhet a komolyabb.
    Mindenesetre az elképzelésedre az ideális megoldás úgysem a PHP, de ezt már leírták előttem.

    (#8124) Bencom ™
    "ott pl óva intettek tőle honlapszervezésnél a "7 másodperces szabály miatt""
    Milyen 7 másodperces szabály? :F Nem tudok ilyenről...
    Ha arra gondolsz, hogy 7 másodperc után a felhasználók elhagyják az oldalt, akkor arra az a válaszom, hogy nem, az esetek többségében már hamarabb megteszik. Akkor már érdemesebb inkább 3 másodperces "szabályról" beszélni, bár ez a "szabály" szó itt elég vicces, túlságosan is könyvszagú kifejezés ebben az esetben.

    Egyébként azért ne úgy tekints a Java-ra, mint egy rémséges valamire, mert nagyon is jó nyelv az, főleg a platformfüggetlensége miatt (meg a bőséges támogatottsága miatt is), de a működési elve (virtuális gép, stb.) miatt sok esetben lassabb lehet egy adott program, mint más nyelven megírva (most ez elég általánosan hangzott, nyilván függ attól, hogyan írja meg valaki).

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz coco2 #8136 üzenetére

    Pedig de, az unset() teljesen jó erre a célra.

    Most amikor írtad, hirtelen felmerült bennem a kétség, ezért ki is próbáltam.
    Az array_values() függvénnyel pedig újraindexeled a tömböt.
    Próbáld ki ezt a kódot:

    $testarray = array('asd','blabla', 'foo', 'bar');
    echo 'unset ELŐTT: <pre>';
    var_dump( $testarray );
    echo '</pre>';

    unset($testarray[2]);
    echo 'unset UTÁN: <pre>';
    var_dump( $testarray );
    echo '</pre>';

    $testarray = array_values($testarray);
    echo 'kulcsrendezés után: <pre>';
    var_dump( $testarray );
    echo '</pre>';

    Egyébként nyilván az array_values függvény is végigmegy egyszer a tömbön. De ez nem feltétlenül "brutálisan lassú"... Nyilván attól is függ, mit tárolsz abban a 2-3 ezres tömbben.

    Szerk.:
    Na, most látom, be sem kellett volna ezt pötyögnöm, gyors Google-keresés után látom, hogy már született erről is fórumkérdés persze: [link].

    Szerk. 2.: na, meg is előztek. :)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz PazsitZ #8162 üzenetére

    "Szerintem felesleges könyvtárral bejlódni, nem feltételezem, hogy túl sok mindent találsz."
    Hát ezzel nem értek egyet. :N Attól függ, hol keresed. Pl. BME műszaki könyvtárrészlegén számomra meglepően sok hasznos infós könyvet lehet találni, tényleg nagyon nagy a kínálat, ami még meglepőbb, hogy egész sok viszonylag aktuális is van (jó, nyilván nem pont 2010-11-esekre kell gondolni, de érted), tehát azért időnként frissítik a kínálatot.

    ===

    (#8156) coco2 :
    "Azért azon a hiphop-on röhögtem egy jót"
    És mi vicces volt benne? Az, hogy a Facebook igénybe vette kódoptimalizálásra? :) Azért nem egy kinevetendő cégről van szó. :)
    [link]

    (#8151) coco2 :
    "míg a C++ nem tartozik a különösen keresett ismeretek közé"
    Azért ez ebben a formában nem teljesen igaz. Grafikai fejlesztésekre mind a mai napig az egyik legnépszerűbb nyelv...és ezen a területen nagyon is számít, hogy vágod-e a C++-t, vagy sem.

    "Én pld biztosra veszem, hogy meg tudnék írni egy webszervert akár asm-ben, de a hajam égnek áll az ötlettől, hogy akár C++-ban nekiessek. Irgalmatlan mennyiségű jobb sorsra érdemes idő megy el vele"
    Hát ez azért alaposan meglepett, hogy szerinted assembly-ben gyorsabb megírni egy elég komplex "alkalmazást". :) Persze ízlések és pofonok, ki mihez van hozzászokva, de nekem speciel az assembly-től áll égnek a hajam - tanultam, őszintén szólva nem voltam oda érte - persze nem mondom, hogy haszontalan, ha valaki vágja a témát, de én több perspektívát látok egy jól átlátható programnyelvben. De öröm, ha vannak még olyanok, akik ebben a nyelvben pengék.

    (#8163) coco2 : Erről a .NET kuka, Java kuka, C++ nem rúg labdába, assembly vissza fog jönni témáról egy kicsit beszélhetnél bővebben, mert őszintén szólva csak kikerekedett szemekkel olvastam, amiket írtál. :D De lehet, hogy csak velem van a baj, és rosszul értelmeztem, amiket írtál, de a jövőről beszéltél, és hogy a mai modern nyelvek meg majd mehetnek a levesbe, szerinted nem tovább fognak fejlődni ezek a nyelvek, hanem térünk vissza az őskorba, a magas szintű nyelvektől a leginkább gépközeliekig, aztán majd jöhet a gépi kódban programozás? :D Érdekes meglátások, csak nem értem az alapját...

    (#8165) coco2
    "Ha nem átlagos tesco gazdaságos számítógépekben, meg community szutyok freeware webszerver + mysql-ben gondolkodsz"
    A "community szutyok" alatt az Apache+MySQL párost érted?
    Hmm, az igen. Nézz pár statisztikát ezeknek a "szutykoknak" a nemzetközi felhasználtságáról. Furcsa, mennyi hülye van a világban, aki ilyen szutykokat használ, nem igaz?

    ===

    (#8154) CSorBA :
    "Egyidejű nagyszámú terhelésre optimálisabb."
    Na de minél? :F Mert ezt nem fejtetted ki. Feltételezve, hogy a Java-s alkalmazás jól van megírva, egy hasonlóan jól megírt C#-kódnál kétlem, hogy gyorsabb. (vagy nagyjából egyező a sebességük)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Bencom ™ #8166 üzenetére

    Utsó kérdésedre válaszolva: igen, a saját géped is szerverré tehető.

    A többire: akár elfogadod, akár nem, azért javasolta eddig nagyjából mindenki, aki hozzászólt, hogy előbb kicsit kisebb projektekben gondolkodj, mert nem lehet egyből ilyen durván fejest ugrani az ismeretlenbe. Vagy lehet, de akkor megvan az esély rá, hogy nagyot koppansz. Az meg lehet, hogy fájni fog.
    Amíg egy programozási nyelv alapjait sem ismered stabilan, addig szinte garantált, hogy az eleinte összeírogatott kódjaid nagy része később mehet a kukába. Haladó programozó is milliószor írja át a kódját, és jön rá, hogy van jóval egyszerűbb módszer is, plusz nagy projektnél a tapasztalt programozó is könnyen elveszti a fonalat, hogy mi nem stimmel. Kezdőként meg egy óriásprojekt átlátása lehetetlen.
    Több területen is tapasztalatot kellene szerezned a programozásban ahhoz, hogy azt lehessen mondani, hogy már belevághatsz.
    Ebben az esetben nem a szokásos magyar kishitűség beszél belőlünk, hanem szimpla reális hozzáállás. :) Hacsak nem vagy valami egetverő géniusz, akkor ennek nagy kockázatai vannak az alapján, amiket elmondtál: egyelőre nincsenek tapasztalt fejlesztőid, partnereid, túl kevés a programozási ismereted, minimális a programozói tapasztalatod - nem hangzik túl jól egy monstre projekthez. Ezért van szükséged a gyakorlásra, alapok lefektetésére, komolyabb felfejlesztésére, aztán csak utána jöhet a többi.

    "ezért nem érdemes c++-szal foglalkozni, mert az nagyságrenddel nehezebb a többinél? "
    Ez ízlés és tehetség kérdése... De az igaz, hogy egy menedzselt kódban sokkal kevesebb dologra kell odafigyelni. Meg pl. C#-ban könnyű úgy kódot írni, hogy úgy érzed, még a széket is a segged alá tolják.
    Ha valaki jól megtanulta a programozás alapjait, akkor C++-ban is könnyen ír alkalmazásokat, viszont jóval több a hibázási lehetőség.
    A C++-ban jól megírt alkalmazás viszont jóval gyorsabb tud lenni egy Java-s vagy C#-os alkalmazásnál, ez tény.

    "arról tud valaki valamit, amit fordfairlane említett az elején? arról még mindig egy szót sem tudok..."
    [link]

    "én pl elvből nem fizetek soha ingyenes játékért, de mindig megdöbbenek, hogy hányan, hány forintot/eurót ölnek akár hetente 1-1 ilyenre..."
    Elvből? Nem vágom. Mi ennek az elvnek az alapja? :F
    Elég sok ingyenes alkalmazás van, amiért a fejlesztő(k) szívesen fogad(nak) el támogatást, ha már időt ölt(ek) bele - amennyiben az elkészített alkalmazás bevált, megfelelt a célnak, és gyakran használod, akkor meg is érdemli a támogatást...
    Ezek szerint elvből nem donate-elsz? Furcsa dolgokat olvasok itt... :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz coco2 #8172 üzenetére

    Jaja, persze, hogy használnak assembly-t a mai napig, nem is mondtam, hogy nem. :) Épp ezért mondtam, hogy jó és értékes dolog, ha valaki manapság vágja ezt a nyelvet. Nagyon nem egyszerű, és szerintem iszonyatos szívás benne programozni (már kisebb projektet is nagyon nehéz benne átlátni), de van, aki ezzel együtt szereti.
    A C++-os állásokról írtak viszont szerintem kevésbé igazak: még mindig rendszeresen kapok hírlevelet informatikai állásokról, és még diákmunkában is keresnek C++-fejlesztőt. Tehát a mai napig akad rá kereslet.
    A C#-ról, Java-ról írtakkal viszont nem értek egyet. Persze, jöhet a jövőben olyan nyelv, ami "lenyomja" ezeket, népszerűbb lesz, és ezek a nyelvek veszíthetnek népszerűségükből, de az tény, hogy manapság ezek már nagyon fontos, és nagyon széles körben támogatott nyelvekké váltak. A Java-t már annyi platformon használják, hogy nehéz elképzelni, hogy a közeljövőben csak úgy eltűnik a süllyesztőben, ahogy predesztináltad. A C# meg szintén egyaránt fontos szerepet kapott a vastag- és vékonykliens-fejlesztés terén egyaránt; használják asztali, webes és szerveralkalmazásokhoz is; az XNA miatt a grafikában sem lett már elhanyagolható (persze, a C++ ezen a téren még mindig fontosabb, a teljesítményben nyújtott többletei miatt). Ezeken a nyelveken a programozás is elég kényelmessé vált és felgyorsult, ezt még inkább segíti az, hogy a fejlesztőkörnyezetek milyen nagy mértékben támogatják ezt a folyamatot. Nem beszélve a rengeteg library-ről, pluginről, frameworkről, stb.

    "Viszont én még C++-ban sem állnék neki nagyon alapos indok nélkül, asm-ben pedig már főleg nem. Te igen?"
    Dehogyis. :D Főleg nem egyedül.
    Ezek szerint valóban félreértettem, amit írtál, mert azt, hogy "Én pld biztosra veszem, hogy meg tudnék írni egy webszervert akár asm-ben, de a hajam égnek áll az ötlettől, hogy akár C++-ban nekiessek.", úgy értelmeztem, hogy assembly-ben még inkább állnál neki, mint C++-ban. :P Késő volt már úgy látszik.

    "A hiphopon azért is röhögtem erőset, mert át lehet forgatni egy PHP-t C++-ra, de az csak maga a kód részlet. Annak a kódnak van egy futási környezete is, ami nélkül használhatatlan. Ebből az egészből csak annyit látni, hogy lefordítani a PHP-t C++-ra, szóval ezt viccesnek tartom. Aranyos, de semmi más."
    Nyilván kell hozzá egy környezet is, amiben ez futhat is, ezen szerintem semmi meglepő nincs. :D Gondolom senki nem feltételezett mást. Ettől függetlenül továbbra sem értem, miért olyan nevetséges, ez egy kódoptimalizálási módszer, ami javíthat a teljesítményen, gyorsabb futási időket eredményezve. Ha a Facebooknak bevált, szar nem lehet. (Értsd: a sebességre többnyire nincs panasz a Facebooknál, még ha minden másra van is. Legalábbis kevésbé jellemző, hogy a gyorsaságával lenne probléma.)

    "szerverkapacitás kategóriában az asztali gépek az összes tartozékukkal együtt a normális minőséghez képest nem többek, mint kommunity szutyok. Kommersz hulladék mind. Szerverként azokat tartani technológiai netovábbnak legalábbis tájékozatlan dolognak nevezném."
    Hát szerintem akkor itt erősen összemosod a szerver és a webszerver fogalmát. Ki mondta, hogy egy Apache+MySQL páros csak asztali gépen futhat? :F Miért ne futhatna azokon a monstre szervergépeken, amikről éppen beszéltél? :F Lehet, hogy ismét csak félreérthetően fogalmaztál, de úgy tűnik, mintha azt feltételeznéd, hogy az Apache és a MySQL páros csak asztali gépeken fut a világ minden táján... Egy ilyen profi, megfelelően klimatizált, nagyon gondosan karbantartott szerverszobában is nyugodtan lehetnek ilyen "community szutykok" is, amiket éppen említettél.
    Ha óriási terhelések elbírásáról van szó, senki nem mondta, hogy valaki ingyenes "community szutykokat" (ettől a kifejezéstől eldobom az agyam, komolyan) használjon. Az nem arra való. Ha meg valakinek már óriási terheléseket kell kezelnie, nyilván megvan az anyagi háttere is ahhoz, hogy igazán komoly szerverhátteret tegyen az alkalmazásai mögé.
    Azért nem árthat, ha revideálod azt a véleményedet, miszerint az ingyenes, közösséggel megosztott webszerverek és ehhez kapcsolódó egyéb szoftverek mind szutykok (még ha óriási terheléseket nem is bírnak el, mégis valami oka van, hogy olyan mértékben népszerű, amilyen).

    Szerk.: OFF.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Bencom ™ #8173 üzenetére

    Az ingyenes dolgokért fizethető adományokat nem arra értettem, hogy az milyen szép dolog, ha fizet az ember azért, hogy egy játékban előnyre tegyen szert. Igaz, ezzel is támogatod közvetett módon a játék alkotóit, karbantartóit, de inkább arra gondolok, hogy ha valaminek valóban nagy hasznát veszed, használod hétköznapjaidban, akkor azért az nem egy rossz dolog, ha valamit vissza is csepegtetsz; persze nem kötelező, csak aki valamennyit rá tud szánni, de minimális reprezentatív összeg is valami. Régen szartam az ilyesmire, én sem fizettem semmiért, ha nem volt muszáj, aztán változtattam az álláspontomon. :D
    Egy példa: nővérem laptopjának vinyóját egy hardveres probléma esetén (alaplapot kellett cserélni, tök ugyanolyanra) a szervizben tök feleslegesen formattálták, majd újrahúzták rajta a Windows-t, így rengeteg adatát bukta, többek közt fontos fotóit; na, próbálkoztam kismillió profi, fizetős és ingyenes adatvisszaszerző programokkal, hogy visszahozzam az adatokat, de sajnos a legtöbb elvérzett; aztán megtaláltam a Linux-alapú Photorec-et, ami pont ilyenre lett kitalálva, és ezzel az adatainak nagyjából 85%-át sikerült visszaszerezni (egyetlen bajunk az volt, hogy ronda, generált neveket adott a visszaszerzett fájloknak, így elég sok fájlt utólag át kellett nevezgetni, de gondolhatod, hogy ezt akkor a legnagyobb mértékben leszartuk, mivel legalább sikerült visszaszerezni az adatokat). Máskor ugyanettől az alkotótól igénybe vettem a TestDisk-et is elszállt partíciótábla megmentésére, amikor bár nem reménykedtem már benne, de sikerült ezt is megmenteni... Na ekkor úgy döntöttem, hogy ez a fejlesztő megérdemel annyit, hogy támogassam őt valamennyivel, persze túl sok pénzt én sem tudtam erre áldozni. De legalább valamennyivel hozzájárultam, hogy inspirációt kapjon a további fejlesztéshez. Írt is egy köszönőlevelet. :D Szóval érted, van az az eset, amikor az ember úgy érzi, hogy még ha ingyenes is egy program, megérdemli, hogy mégis költs rá valamennyit, így megvan az a kellemes érzésed, hogy eldöntheted, mennyit tudsz szánni rá.
    Na, de ne OFF-oljunk. :P

    Ezt a könyvet már másnak is ajánlottam, amennyit olvastam belőle, az alapján jól összeszedett áttekintő anyag az alapismeretek elsajátítására: [Nagy Gusztáv: Web programozás alapismeretek].

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8193 üzenetére

    Ha nem láttad még kisbetűvel, akkor nézd meg a Google kezdőlapjának forráskódját. :) (Szerk.: nem mintha a Google-nek célja lenne a w3.org szerinti valid kód elérése.)
    Egyébként a "html" részt a w3.org is kisbetűvel írja, és azt hiszem, az elég jó referencia... :)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz coco2 #8195 üzenetére

    "És nem, nem fog kelleni 2-3 hónap majd a php doksihoz sem. Egy alig 100 oldalas magyar nyelvű szöveg file szerintem nagyon egyszerű és lényegre törő magyarázatokkal. Max 2 nap alatt át lehet rágni, aztán nekiállsz gyakorolni, kicsi logikai érzékkel 1 hét, és már oda neked az oroszlánt is."
    Most saját tapasztalatról beszélsz? :) Úgy tudom, még Te is viszonylag kezdő vagy PHP-ben (legalábbis a kérdéseid alapján, nincs is ezzel baj).

    Én saját tapasztalat alapján azt mondanám, hogy nem, 2-3 hónap még nem elég arra, hogy "oda neked az oroszlánt is". Bőven kell a tapasztalat ahhoz, hogy valaki elsajátítsa azt a szemléletet, ami kell ahhoz, hogy már viszonylag jó, legalább saját maga számára átlátható és könnyen módosítható kódokat írjon az ember. Meg hogy értse, hogy egyáltalán mit csinál.

    (#8197) Bencom ™ : speciel a DOCTYPE-ra nem vonatkozik a "mindent kisbetűvel"-elv.

    Jó lenne tudni, az NVU most mit csinál, ami miatt nem működik, nem ismerjük a körülményeket. Egyáltalán milyen kiterjesztésbe ment, stb.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz M.Úr #8204 üzenetére

    Nem, hanem a zzzinternet. :D
    A korábbiakkal viszonylag egyetértek, hogy a PHP-s fejlesztői meló nem tartozik épp a nagyon megbecsültek közé.
    "az ugye "honlap" (a weblap, weboldal szavakat általában nem ismerik)"
    Ezt viszont nem egészen értettem, mit akarsz ezzel mondani. :D A "honlap" gondolom a "homepage"-ből ered, amit tudtommal nagyjából egyenlőnek szoktak tekinteni a "website", "webpage" kifejezésekkel, most akkor nem mindegy, magyarul melyik megfelelőjét használja az ügyfél, ha úgyis hülye az egészhez, mint a s*ggem? :DD (szerk.: tisztelet a kivételnek)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8219 üzenetére

    "Meg furcsa, hogy beadandó, zh, vizsga idején is ha C# volt a téma, akkor megszívtam. De ugyanúgy szeretem azt a témát is. Csak befigyelt, hogy máshogy kell megvalósítani a programokat. (más gondolkodás kell, és a Java-ra jobban ráállt az agyam)"
    Már miért kellene más gondolkodás?
    Ha a nyelvek közötti differenciákról beszélünk (alacsonyabb szintű, gépközelibb nyelveket is belevéve a körbe), a programozás során lehet, hogy ott valamennyire elválik a dolog, hogy objektumorientáltan vagy "klasszikus" procedurális módszerekkel oldod meg a feladatot (végül is abból a szempontból nem mindegy, hogy objektumokban, azok privát vagy kívülről is elérhető, örökölhető, stb. metódusaiban, tagváltozóiban gondolkodsz, vagy mondjuk globális függvényekben, változókban, stb.), de alapvetően ugyanazt a szemléletet kell követni a tervezés során: megvalósítás szempontjából hogy nézzen ki a dolog - a tervezés az elsődleges lépés, jóval utána jön csak a megvalósítás.
    Ha C#-ra és Java-ra szűkítjük a kört, annyiból is egyértelműbb a dolog, hogy nyilvánvaló, hogy mindkettőnél az objektumorientált szemléletet fogod követni. Hogy a megtervezett sémát hogyan valósítod meg kódban, milyen library, framework, plugin, stb. segítségével, az a "gondolkodásmód" szempontjából mellékes, mindkettőben lehet nagyjából egy struktúra és szemlélet szerint írni a programjaidat (ha mondjuk úgy tervezted meg az alkalmazásodat, hogy az MVC-szemléletet fogod követni, akkor mindegy, hogy C#-ban vagy Java-ban állsz neki, mindkettőben megvannak a megfelelő eszközök ennek a megvalósítására).

    (#8216) Lacces :
    "Jogoknál. van olyan, hogy típus:
    - globális
    - adatbázis-specifikus.
    (mindkettő típus jelen van a felhasználónál)
    Mi a különbség kettőjük között?"

    Itt konkrétan melyik szót nem érted? :)

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz coco2 #8224 üzenetére

    Komolyan, kíváncsi lennék, ezeket a full szélsőséges véleményeket honnan szeded (mint az, amire legutóbb jó hosszan reagáltam, Te nem válaszoltál). Amúgy nyilván azért olyan népszerű az MVC-szemlélet, mert úgy van, ahogy Te mondod....

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz coco2 #8231 üzenetére

    Szerintem nem veszekszünk, szakmai vita az nem veszekedés. :N
    1.) MySQL: "Szóval részemről nem tartom jelentősnek a penetrációját." Az lehet, a világon elég sokan viszont igen. De nem is ez a lényeg: van egy ingyenes, folyamatosan javított, karbantartott adatbázisszerver, ami gondolhatod, hogy nem amiatt lett népszerű, mert "szutyok". Nem is állította senki, hogy ez hatalmas terheléseket bír el, de leszarozni azért, mert Te nem ismered eléggé, és mert nagy cégek nem ezt használják a viszonylagos korlátossága miatt, enyhén szólva túlzás. Választani bőven lehet alternatívát, de ez egyike az ingyenesek közül egész jól teljesítő adatbázisszervereknek.

    2.) A HipHop PHP-ről írt véleményed számomra nem egészen volt világos. Lehet, hogy félreérted a célját. Nyilván nem az optimalizált, kigyomlált kódba írogatnak a programozók a Facebooknál. :D Most ez nagyjából olyan, mintha arra gondolnál, hogy ki az a hülye, aki gépi kódot fog javítgatni. De jó lenne érteni, mire alapozva írtad ezt a "trehány munka"-hasonlatot...

    3.) "C# & Java: a roseb akar egy majdnem olyan hitvitába belefolyni, mint a "melyik a jobb a linux vagy a windows?" - mert ez majdnem olyan."
    Most ezt az én válaszomra írtad? Mert itt én sehol nem kezdtem el fejtegetni, hogy a C# vagy a Java a jobb. :N (Mindkettőnek megvannak az előnyei és hátrányai egyaránt. Ahogy az összes többi nyelvnek.) Te amellett érveltél (leegyszerűsítve), hogy ezeket a C++ lazán lenyomja minden szempontból, és ezek nyugodtan eltűnhetnek a süllyesztőben ("[...] ASM is létezni fog, és valószínűleg a C++ is, de a .NET és Java, ezek szerintem fele annyira sem kemény részei az informatikának. Azok eltűnhetnek mind2-en a süllyesztőben nagyon könnyen. Igazából nem többek, mint hogy valakinek kipattant a fejéből, hogy a 386-os procinál megjelent memory managert meg lehetne valósítani felsőbb programozási szinten is, és ráhúzott egy absztrakciós szintet a C++ fölé, abból lett garbage collector és társai. Ennyi a managed kódos világ összes misztériuma."), ebből az jön le, hogy méltatlanul népszerűek, én arra hívtam fel a figyelmed, hogy ha ezek olyan használhatatlan szarok lennének, akkor valószínű, hogy nem foglalkozna senki azzal, hogy ezeket továbbfejlessze, és megpróbálja a programozók munkáját segíteni. Nyilván üzleti érdeke is ez cégeknek, de most emögé összeesküvés-elméleteket gyártani és világuralmi törekvéseket feltételezni nem sok értelme van. Ahogy az MVC esetében sem.
    "Viszont ez az elmélet csak 2-3 éve lett felkapott (már csak a gazdasági válság indulása után) annak ellenére, hogy létezik 30 éve."
    30 éve létezik MVC? Ez nekem valóban új. :)

    Remélem ezeket az ellenérveket továbbra sem veszed "veszekedésnek", bár OFF, de jó néha szakmai témákról vitákba bonyolódni.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8239 üzenetére

    Nem néztem még meg a korábban bemásolt .htaccess-es cuccot, de előbb kérdés: egyáltalán be van kapcsolva a mod_rewrite Apache-ban? Azt sem árt tudni. :)
    Egy phpinfo() megmondja.

    ====

    Szerk.

    (#8241) coco2 :
    1. OK.
    2. Ez hogy jön ide? :F Kifejthetted volna bővebben, ez miként kapcsolódik a HipHop PHP-hez.
    3. Ez a válasz most elég furcsa. Nem értem ezt a "mutassá cash-flow adatokat, ha nem tudsz, akkó' nekem van igazam"-jellegű reakciót. Meg azt, hogy a cash-flow adatok megint csak hogy jönnek ide, amikor arról beszéltünk, milyen létjogosultsága van (van) a C#-nak és Java-nak az alacsonyabb szintű nyelvekhez képest.
    4. Wow, nem rossz. Ez mégsem változtat a korábbiakon, hogy attól még az MVC-nek is van létjogosultsága, mert szerinted szemét üzleti érdekek miatt lett ez is felkapott. :)

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz TonTomika #8238 üzenetére

    Mondjuk ez nem biztos, hogy megoldás, de ezt írod: "Backupból visszatettem a régebbi htaccess.txt-t"
    Az csak simán .htaccess, NEM htaccess.txt.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz biker #8247 üzenetére

    úgy érted, ha van egy ilyen képed a http://oldalad.hu/adsasd/asdasd/index.php fájlban, hogy pl
    <img src="blabla/akarmi.jpg" />
    akkor a
    http://oldalad.hu/adsasd/asdasd/blabla/akarmi.jpg elérési útvonalon fogja keresni?
    Mert akkor az nem meglepő. Vagy lehet, hogy félreértettem, amit írtál.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz fazr #8263 üzenetére

    Lenne még hozzáfűznivalóm:
    igen, lehetőleg egyezzenek a karakterkódolásaid.
    4. pontra: igen, sebezhetőséget jelent az, ha kiíratsz bármi "nyers" hibaüzenetet. Már eleve az egy sebezhetőség, hogy bármilyen információt árulsz el a rendszered belső működéséről. Akár mezőnevek, akár szintaktikai hibák adott lekérésben vagy máshol, akár elérési utak, vagy bármilyen, a külvilágra nem tartozó információ segíthet egy ártó szándékú látogatót a céljai elérésében. Ezt akkor hiszed majd el igazán, ha valaki gyakorlati példán mutatja be neked (mondjuk előadás keretében), hogy egy sebezhető rendszer adataihoz pl. kiírt hibaüzenetek alapján hogyan lehet még gyorsabban hozzájutni; akár bejuttatni saját, nem kívánt adatot a rendszerbe.
    PDO tényleg jó, és ha ezt kezded el használni, könnyebben rá fog állni a kezed és agyad az ORM-ek használatára.
    Most hirtelen még ennyi jutott eszembe.

    [ Szerkesztve ]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz fazr #8266 üzenetére

    Jaja, az strlen-re vonatkozó részt azért is töröltem egyből a szerkesztési időben, mert rájöttem, hogy igazad van, hogy problémát okozhat, arra az mb_strlen kell.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Lacces #8272 üzenetére

    "Viszont cserébe nem tudod az összes MySQL feature-t elérni (vagy spec parancsok). (Ez a hátránya)"
    Mégpedig?

    (#8273) Lacces :
    mivel még az elején vagy, még most felejtsd el az output bufferinget (ob_start(), stb.). Az esetek 95%-ában megoldható a problémád anélkül is. Vagy lehet, hogy mondhattam volna magasabb százalékarányt is.
    Cserébe szebb lesz a kódod.

    (#8276) Lacces :
    "Try / Catch-t ajánlom is, hogy hozzák be a PHP-ba."
    Már "behozták", Te is használod. :P

    "És akkor az E_ALL helyett E_ERROR-t használjak?"
    Ezt Te döntheted el, de szerintem érdemes E_ALL | E_STRICT beállítást használni (6-os PHP-nál az E_STRICT már az E_ALL része lesz). Ez a legszigorúbb hibaellenőrzés. De mivel a hivatalos doksi szerint épp ez a default beállítás, legegyszerűbb, ha ezt a második paramétert meg sem adod, aztán megfelelő módon lekezeled a hibákat, persze ez már egyéni döntés kérdése.

    A set_error_handler-t valahol a "főfájlod" elején, egyfajta inicializálásként add meg. Kukkantsd meg a példákat rá.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Brown ügynök #8278 üzenetére

    Milyen részoldalakra gondolsz?
    Példa is jöhetne, hogy érthető legyen. :K

    (#8279) Lacces :
    ja igen, a multiple statements támogatása valóban nincs meg jelenleg a PDO-nál, igaz, én fejlesztés során nem is nagyon szoktam érezni a hiányát, persze nyilván van olyan alkalmazás, ahol ez jól jönne. De fejlődik a PDO is, esélyes, hogy későbbi verziókban meglesz erre is a támogatás, hogy mikor, és tényleg lesz-e, azt nem tudom.

    Output buffering: pl. a Te példádban tuti, hogy felesleges. Van olyan eset, ahol elő lehet venni, mert jól jöhet, de mint mondtam, az esetek többségében csak ocsmány módszer. Mégis sajnos sokan alkalmazzák pl. arra, hogy már bármilyen output kiíratása után akárhol is tudjanak headereket küldeni, de nem jó gyakorlat. Headereket az output előtt kell kiküldeni.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Brown ügynök #8282 üzenetére

    Igen, és ennek eléréséhez include-olod azok tartalmát mindenhol, ahol kell, így elég egy helyen megírni.
    De ehhez határozottan NEM kell output buffering!
    Ennek megfelelően nem is szokták ilyen esetben ezt alkalmazni.

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz Tele von Zsinór #8284 üzenetére

    Bocs, hogy csak most válaszolok, nem volt időm itt is reagálni.

    A Decorator pattern asszem az, hogy mondjuk egy kész objektumot kiegészítesz runtime-ban még valamivel, amire szükséged van pluszban, igaz? Jól leegyszerűsítve. Akkor ezek szerint pl. gondolom itt PHP esetén valami olyasmire kell gondolni, ha a példát veszem, amit mondtál ("Cserébe nincs az összes view-edben a header és footer include."), hogy pl. van egy Page objektumod, ehhez pedig hozzácsapod a headert és a footert.
    Nem hülyeség végül is.
    Ezt amúgy melyik frameworknél alkalmazzák?
    Te ezt a megoldást szoktad választani? Csak kíváncsiságból érdekel. Én eddig ezt a megoldást nem igazán alkalmaztam.

    ================

    (#8285) Brown ügynök : ja, és Te gondolom minden oldaladnál a Decorator patternt alkalmazod, mi? ;]

    Sk8erPeter

  • Sk8erPeter

    nagyúr

    válasz biker #8721 üzenetére

    Végül is erőltetetten megoldható úgy, hogy valami API-t vagy web service-t a rendelkezésére bocsátasz annak a valakinek az általad nem kifejtett feladatra, és távoli szerverről szolgáltatsz adatokat. Persze ezt úgy is védeni kellene, hogy mondjuk csak adott domainről érjék el azokat az adatokat, hogy máshonnan ne terheljék feleslegesen a Te szerveredet.
    Persze kéne tudni, miről is van szó, de azt mondtad, nem kódobfuszkálással szeretnéd megoldani.

    ===

    (#8720) Speeedfire : "Ja és It's Work!" úgy érted, "It works!", igaz? Annak még van is valami értelme. ;]

    ===

    (#8723) Athlon64+ : mindezt Windows-on vagy UNIX-alapú szerveren?
    Windows alatt én is szívtam APC-vel, állítólag a fájlzárolási mechanizmusok különbözősége miatt, de mivel egy idő után a t×köm tele lett a szívással, végül inkább úgy döntöttem, ezt hagyom a francba.

    [ Szerkesztve ]

    Sk8erPeter

Új hozzászólás Aktív témák