- HiFi műszaki szemmel - sztereó hangrendszerek
- Bluetooth hangszórók
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Nyáron jönnek a gyártói DGX Spark verziók
- Milyen RAM-ot vegyek?
- Intel Core Ultra 3, Core Ultra 5, Ultra 7, Ultra 9 "Arrow Lake" LGA 1851
- ThinkPad (NEM IdeaPad)
- Amlogic S905, S912 processzoros készülékek
- AMD Navi Radeon™ RX 6xxx sorozat
- Itt vannak az ASUS legszerényebb NVIDIA Blackwell architektúrás VGA-i
Új hozzászólás Aktív témák
-
#9038
Sk8erPeter
nagyúr
Peter Kiss
#9037
Sk8erPeter
nagyúr
válasz
Peter Kiss
#9037
üzenetére
És ki/mi határozza meg, hogy hol a "helye"?
Szerk.:
Amúgy attól az új bal oldalt szereplő Ubi-menütől én őszintén szólva kimentem a fazonomból. Valahogy nagyon zavart, persze mondjuk az is hozzátartozik, hogy egy régi fos gépre telepítettem melóhelyen, mert azt gondoltam, az legalább gyorsan fut majd rajta - hát nem futott gyorsan. A menü megjelenésére meg külön várni kellett... -
#9036
Sk8erPeter
nagyúr
Speeedfire
#9034
Sk8erPeter
nagyúr
válasz
Speeedfire
#9034
üzenetére
Nem is mondtam egy szóval sem, hogy nincsenek hibái. Viszont biztos, hogy a Yii-t össze lehet hozni Ubuntun is, az, hogy Laccesnek nem sikerült, nem azt jelenti, hogy Ubuntun még ezt sem lehet működésbe hozni.
Webfejlesztgettem Ubuntu alatt is, érdekes módon nekem nem volt olyan problémám, hogy bugok miatt képtelen voltam használni a terminált... 
Nyilván rengeteg bugja van, de nem pont a Yii telepítése az, ami kiveri a biztosítékot.
Félre ne értsd, nem tisztem védeni az Ubuntut, jelenleg nem is használom (egyszóval: kb. leszarom), de mondjuk az is igaz, hogy a Linux disztrók közül a "felhasználóbarátsága" miatt az egyik legnépszerűbb, nyilván nagyon sokan használják, így gondolom nem gyengén derülnek ki hibái (nem is beszélve az egységsugarú júzerekről ). Aztán lehet, hogy fostenger, nem tudom, konkrét, alátámasztott szakmai véleményt erről még nem olvastam, pedig jobb olyat olvasni, mint azt, hogy "az egy szar, mert a Pisti is megmondta". ===
(#9035) Athlon64+ : ennél jobban alátámasztott szakmai véleményt még soha nem olvastam.
![;]](//cdn.rios.hu/dl/s/v1.gif)
-
#9033
Sk8erPeter
nagyúr
Speeedfire
#9032
Sk8erPeter
nagyúr
válasz
Speeedfire
#9032
üzenetére
Micsoda megoldás.
Abból, hogy valakinek egyedi hibák miatt nem sikerült megcsinálnia valamit Ubuntun, az az egyenes ágú következtetés, hogy "ne használj Ubuntut", BIZTOS csakis az Ubuntu és a fejlesztői lehetnek a hibásak!... 
-
#9028
Sk8erPeter
nagyúr
Lacces
#9026
Sk8erPeter
nagyúr
Sehol nem írtam PHP CPL-ről...
A többire meg annyit javasolnék, hogy mielőtt másoktól várnád, hogy szinte vezessék az egeredet, hova kattints, és pötyögnének a billentyűzeteden, próbálj alaposan utánaolvasni, biztos hatmillió tutorialt találsz róla. Ha meg olyan alapvető kérdések merülnek fel, hogy mi az a command line vagy terminal, akkor előbb annak kellene utánanézni, és csak utána foglalkozni a komolyabbakkal. -
#9024
Sk8erPeter
nagyúr
Lacces
#9023
Sk8erPeter
nagyúr
Veled jól járnak a könyvesboltok.
Nem tudom, mit nem értesz a Server Faulton fent lévő válaszon.
Mondjuk nem ártana, ha utánaolvasgatnál, hogyan csináld, mielőtt pánikolsz (ez nagy általánosságban is igaz), pl. nagyon gyors keresés után itt is megvan az, amit írtál: [link]. Vagy még jobb: [link].
Ott van halál egyértelműen az is, hogy mitől működik (többek közt):
"Tip: In order to use the yiic tool as shown above, the CLI PHP program must be
on the command search path. If not, the following command may be used instead:
path/to/php /wwwroot/yii/framework/yiic.php webapp /wwwroot/blog"
Ebből egyértelmű, hogy a PHP terminálban használható változatának elérési útja alatt kell végrehajtani azt, amit írtál, vagy környezeti változók közé kell tenni a PHP CLI elérési útját, ÉS még ezenkívül nyilván léteznie is kell a /wwwroot/yii/framework/yiic.php elérési út alatt a megfelelő fájlnak... (remélem nem kell hozzátennem, hogy ez a wwwroot könyvtár nem a Szentírás, attól függ ez az elérési út is, hogy hova rakod...)Egyébként ha fogalmad sincs, mit csinálj, miért nem olvasgatsz magyar fórumokat? Ott volt a link hozzá a hivatalos honlapon:
http://www.yiiframework.com/forum/index.php/forum/33-hungarian/ -
#9018
Sk8erPeter
nagyúr
modder
#9014
Sk8erPeter
nagyúr
Na ja. Asszem így már nagyjából összeért az álláspontunk. Csak kár, hogy eddig is PHP-ról beszéltünk (nem C-ről és nem is C++-ról), így egy kis időt megspórolhattunk volna.
Miután legalább egy órát elb@sztam azzal, hogy a kivétel vs. nem kivétel témában olvassak, olyan remek újdonságra jutottam, hogy nincs jó megoldás.
Mintha ezt eddig nem tudtuk volna. A lényeg: rengetegen amellett állnak ki, hogy a kivételeket tényleg csak kivételes esetekben érdemes dobálni (egyet muszáj idéznem: "Exceptions should be a truly rare thing, UserHasDiedAtKeyboard type situations."
), sokan mások meg azt állítják, hogy ez totálisan attól függ, hogy mennyire a teljesítményt helyezed a középpontba pl. a gyorsabb átláthatóság előnyeivel szemben. Kábé ugyanott tartok, mint ahonnan mi is elindultunk, annyi különbséggel, hogy csomó időm ráment, és hogy legalább megtudtam, hogy UNIX-nál van olyan hiba, hogy Printer on Fire. 
Mivel én az eddigi kivételdobálásoknál PHP esetén semmiféle észrevehető teljesítménybeli különbséggel nem találkoztam, asszem nem fogom átírni a kódjaimat úgy, hogy hibatömbbel térjek vissza, és a kódolási szokásaimat sem fogom rossznak tekinteni a vitánk miatt.
Egy C++-alkalmazásnál már nagyon is megfontolandó az, amiről beszéltünk. De természetesen az már másik fórumtémába tartozik.
Egyébként magas szintű nyelvek (pl. C#) előszeretettel alkalmaznak kivételeket különböző esetekre, nem véletlen, hogy számtalan előre definiált exception class van, amiket akár "helyben", egy rövidebb, beágyazott try-catch blokkban is el lehet kapni (ugyanez igaz általunk definiált exceptionökre is), így meg feltételezem, kisebb teljesítményvesztéssel kell számolni.Szerk.:
A TÉNYLEGES, gyakorlati teljesítményveszteségről viszont normális áttekintő cikket, méréseket továbbra sem találtam, csak a szájkoptatást, hogy csúnya nagy költségei vannak, pedig tényleg nagyon érdekelne, egy alkalmazásnál a két eset összehasonlításakor miféle teljesítménykülönbségekkel kell számolni. -
#9011
Sk8erPeter
nagyúr
Sk8erPeter
#9009
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#9009
üzenetére
"felmérés" helyett inkább simán teljesítménymérésre gondoltam.
(#9010) Speeedfire : bárcsak közérthetőbben írtad volna le, mit szeretnél.
-
#9009
Sk8erPeter
nagyúr
modder
#9005
Sk8erPeter
nagyúr
Igen, és itt aztán a visszatérési értéket megint csak vizsgálni kell, és akkor visszajutottunk ugyanoda, ahonnan elindultunk.
Vegyük azt a megközelítést, amit Te mondasz, tök egyszerű példával. Itt beletettem még annyit, hogy két különböző paraméterrel hívom meg a logErrors függvényt, ez is szándékosan jó butított példa. A syntax highlighting miatt inkább felraktam pastebinre:
http://pastebin.com/KxH2Fmk9Na, akkor vegyük azt a megközelítést, amiről én beszélek (bár privátban hasonló jellegű megoldást mutattam), aktualizálva a példához:
http://pastebin.com/PVKe4uNANem tudom, ki hogy van vele, de nekem a második, háromsoros kód jobban áttekinthető. A korábbiaknál meg annyi van bent pluszban, hogy van két saját kivételosztály, ami tömböt is tud fogadni.
(#9007) modder : azzal egyetértek, hogy nem mindig egyértelmű, mire szabad/érdemes exceptiont használni. De pl. egy form injection probléma tipikusan olyan, ami miatt érdemes lehet exceptiont dobálni. Ahogy egy adatbázis-kapcsolódás is.
A 404-es hiba meg ilyen alapon ugyanúgy gyakran előfordulhat, ha valaki elcseszi a keresett URL-t, esetleg van hivatkozás Google-ön keresztül olyan oldalra, amit azóta már töröltek, vagy magán az oldalon van rossz hivatkozás van; de tulajdonképpen ezt is meg lehetne oldani sima error tömbökkel, ahogy az összes többi hibát is. Tulajdonképpen mindkettő megoldás alkalmazható minden problémára, kérdés, mire melyiket érdemes - bár az valóban érdekes felmérés lehet, mennyit ront a GYAKORLATBAN a teljesítményen az, ha valaki exceptionökre áll rá.
Ha valaki tud ilyen felmérésről, ne tartsa magában!===
(#9008) Athlon64+ : nem is kell "mindenhol" kivételeket hajigálni.
-
#9006
Sk8erPeter
nagyúr
modder
#9001
Sk8erPeter
nagyúr
Ez sajnos nem volt egy túlzottan érdemi reakció.
Pl. miután kijelentetted, hogy nem igazán tudsz olyan frameworkről, ami exceptionökre építené a működését, megmutattam a Symfony-t, mert próbáltam érdemben vitatkozni, nem csak általánosságban beszélni. A Symfonynál meg most hirtelen nem tudom, milyen meggyőzőbb frameworköt kellene neked mutatnom, hogy az exceptionök létjogosultsága valamennyire világosabbá váljon.Egyébként a gyakorlati ellenpéldákat én is hiányolom, ha már kritizálod azoknak a programozási szokásait, akik a kivételek használatára építenek. Azt érezteted, hogy a kivételekre építés rossz programozói gyakorlat (tehát valamit rosszul csinál az, aki erre alapozva kezeli a program menetében felmerülő hibákat), miközben nálunk okosabb emberek komplett keretrendszert építettek erre. Én jobban hajlanék az érveid elfogadására, ha alátámasztanád őket konkrét példákkal - attól függetlenül, hogy "minden probléma egyedi". Igen, a formvalidálás problémája is egyedi, meg az is, hogy hogyan kezelj le egy 404-es hibát. Én mindkettőre elmondtam a saját megoldásom (privátban komplett pszeudokódot is mutattam, ezt alátámasztandó), úgy tűnt, belátod az átláthatóság előnyeit kivételkezelésnél. De saját példát is mutathatnál, mert én nyitott vagyok más megoldásokra, ha az érdemi javulást hozhat a kódban.
Ha valaki vitatkozik az álláspontoddal, nem azért teszi, mert feltételezi, hogy hülyeségeket beszélsz, épp az a jó szakmai vita ismertetőjele, hogy szakmai szempontokkal győzzük meg egymást (én erre törekszem), nem pedig bezárkózásunknak adunk jelet.
A magasabb szintű programozói nyelvekben meg a kivételkezelés nagyon nem ördögtől való.
Kicsit számomra is olyan ez a vita, mintha arról beszélnénk, hogy mennyire nem éri meg objektumorientáltan programozni, mert az akár lassulást is hozhat. Ugyanez igaz C++-ra is: az OOP-s megoldás továbbra is lassabb marad, ezzel nyilván nem mondtam újat.
De ettől még megkérdőjelezni az OOP előnyeit nem érdemes, mert tény, hogy az átláthatóságban, követhetőségben, az objektumok logikai összetartozásában, kapcsolódásában, annak szemléltetésében, az emberi gondolkodáshoz való hasonlóságában, stb. annyi előnye van, ami miatt bőven van létjogosultsága (ez sem új, de elmondom).
Ettől függetlenül mégis hosszas érvek vannak, amik miatt pl. a Drupal még mindig nem állt át a teljes objektumorientáltságra: Drupal programming from an object-oriented perspective. De ennek nagyon sok történelmi gyökere is van (PHP 4 miatti kompatibilitás - most már erre nem terveznek). -
#9004
Sk8erPeter
nagyúr
modder
#8999
Sk8erPeter
nagyúr
"Azt hiszem érthető voltam, de akkor leírom érthetőbben: amikor refaktorálod (átírod, javítod) a kódot, nem fogod tudni, hol dobtad az exceptiönt, amíg tényleg nem dobtál egyet.
Például van a form validáló osztályod, ami dobhat 4féle exception-t, te meg szeretnéd tudni, hol dobja, akkor legjobb esetben is ctrl+ffel keresel rá. Ha pedig a stacktrace-t akarod használni, ahhoz generálnod kell egy olyan hibát, ami ezt az exceptiont dobja."
Azt hiszem, én is érthető voltam, amikor leírtam, hogy egy általános jellegű Exception elkapásával minden kivételt el lehet kapni, és a kivétel keletkezésének módjáról mindent meg lehet tudni. Ha azt szeretnéd megtudni, hol dobja, és egész addig nem tudod, amíg nem keletkezett egy pontosan olyan specifikus hiba, akkor valóban az a megoldás létezik, hogy generálsz olyan hibát, vagy rákeresel. És? Nem értem a logikádat, ez miben tér el attól, ha te mondjuk ragaszkodsz a hibatömbös megoldásodhoz. Ha a hibatömbös hibakezelés forrásaira szeretnél rátalálni, akkor még a klasszikus exceptionökre vonatkozó backtrace-es megoldás sem áll a rendelkezésedre, de szerencsére mivel a PHP elég kényelmes nyelv, még erre is igénybe lehet venni egy plusz segítséget (kicsit mintha a bal kezeddel vakarnád meg a jobb füledet a tarkód mögül): debug_backtrace().
Még egy dolog: ha definiálsz saját exception osztályokat, akkor azoknak többnyire elég normális, egyedi neve van.
Pl. legyen épp ValidationException a neve.
Mondjuk ennek eldobása egy egyszerű globális fv.-en belül így néz ki:function blabla(){
// .......
if( $hiba_van ){
throw new ValidationException( 'ezért meg azért' );
}
// .......
}a Te megoldásod meg valami ehhez hasonló:
function blabla(){
// .......
if( $hiba_van ){
$errorArray['status'] = FALSE;
$errorArray['msg'] = 'ezért meg azért';
return $errorArray;
}
// .......
}Ha már Te mindenhol az ugyanilyen jellegű hibatömbös megoldást alkalmazod, és Ctrl+F-es módszer, akkor szerintem több esély van gyorsan megtalálni a throw new ValidationException részt.
De a tömbös megoldást továbbra sem kínál beépítetten backtrace megoldást."Nyilván, ha valaki idiótán programoz, arra nincsen mentség."
Ez önmagában igaz. De arra, amire reagáltál, ez valahogy kicsit sántít. Pl. ha már újrafelhasználásról beszélünk, nem tudom, valakinek miért kellene kitalálnia, hogy a kódot elkészítő illető pontosan milyen tömbindexeket használt. Ja, hát nézze át az egész kódot, ha már szar a dokumentáció, hisz' bár a függvényt készítő ember nem ért rá odaírni három sort, ha három kivételt dob a fv. elejére, de a kódot felhasználó illető majd nyilván rá fog érni átnézni a komplett kódot. Itt pedig ez az indexeléses módszer nem biztos, hogy olyan intuitív megoldás, hogy ránézésre, már az első példa láttán lehet tudni, hogy mi is a helyzet többféle alkalmazásnál. -
#9000
Sk8erPeter
nagyúr
modder
#8998
Sk8erPeter
nagyúr
"nem talál egy oldalt, akkor exception-t dobjon, amikor az egy belekalkulált működés, szerintem; az exception számomra egy kerülő megoldás, ahol ide-oda ugrálunk a kódban.
Itt tulajdonképpen arról van szó, hogy milyen 'hiba' vagy kivételes eset fordulhat elő többször, amire számítani kell, és mi a valódi hiba (ez utóbbi esetben érdemes kivételt használni). Nem láttam még olyan keretrendszert, ami kivételdobásokra alapozta volna a működését."Akkor az általad használt Kohana egy szar, mert pl. minden egyes HTTP status code-ra létezik benne exception?
Vegyük az említett példának megfelelőt: HTTP_Exception_404.
Aztán itt bal oldalt láthatod szépen a többit is, ami pl. validálás kapcsán említésre méltó, az a Validation_Exception.
Aztán ott a Kohana_Exception, a Kohana_Request_Exception és a Kohana_View_Exception.Azt hiszem, abban egyetérthetünk, hogy valószínűleg a Kohana alapvetően nem átgondolatlan struktúrára épül.
Hadd említsek egy másik példát: remélem abban is egyetértünk, hogy a Symfony nem egy tákolmány keretrendszer, és valószínűleg nem érdemtelenül népszerű.
Egy - számomra legalábbis - elég meggyőző érv még a témában:
[link]
"Symfony really relies on PHP exceptions for error reporting, which is much better than the way PHP 4 applications work. For instance, the 404 error can be triggered by an sfError404Exception."Akkor most már láthattál egy keretrendszert, ami kivételdobásokra alapozta a működését.
-
#8997
Sk8erPeter
nagyúr
modder
#8995
Sk8erPeter
nagyúr
"Kivételkezelést akkor érdemes használni, amikor egy mély hívássorozat alján keletkezik valahol egy kivételes hiba, és ezt sokkal fentebbi függvényben akarod lekezelni. Ilyen például az adatbázis absztrakciós rétegekben egy mysql hiba, ami, ha jó a kódod, ritkán fordul elő, és általában elég csak annyira foglalkozni vele, hogy loggolod."
1.) Nem értem, ez miért változtat azon az állításomon, hogy átláthatóság szempontjából mindenképp jobb. Azt hittem, a privátban kitárgyalt kód meggyőző volt ennek alátámasztására.
2.) A MySQL-hiba jobb esetben - pl. elég ritka, hogy az adatbázishoz tartozó service lehal - valóban ritkán fordul elő. De azért ne csináljunk úgy, mintha csak ennyire szélsőséges esetekre lehetne alkalmazni a kivételeket."Ha a kivételkezelést általános programozási gyakorlattá teszed, annak megvan az a hátránya, hogy később, ha ránézel a kódra, nem biztos, hogy fogod tudni, hogy a kivételedet hol dobod (ahogy említetted, amíg ténylegesen nem történt ilyen exception, akkor stacktrace), és amikor refaktorálod a kódot, fogni fogod a fejed."
Ezt pontosan azért nem értem, mert az előző hozzászólásomban éppen azt hoztam fel a kivételek egyik előnyeként, hogy a lehető legegyszerűbb kideríteni, honnan származik a kivétel, és naplózás esetén nálam legalábbis alap, hogy a kivételek forrását is naplózom: melyik fájlban keletkezett a kivétel, melyik függvényben, a fájlnak pontosan melyik sorában, mikor, stb. Ezeket az exceptionökből a lehető legegyszerűbb feladatok egyike kideríteni, így pontosan ezért nem értem, miért is lenne érv jelen esetben az, hogy "nem biztos, hogy fogod tudni, a kivételedet hol dobod" - dehogynem, pontosan fogom tudni: lásd pl. getFile(), getLine(), getTrace() vagy épp getTraceAsString() függvények...Régen, mielőtt a kivételkezelést egyáltalán alkalmaztam volna, pontosan az volt a bajom, hogy sok esetben nehezen visszakövethető, hogy konkrétan hol is történt a hiba, és milyen jellegű is volt. Most meg pl. ránézek a naplóra, és egész pontosan meg tudom nézni, hol és mi is történt, valamint a kivétel mikor keletkezett.
"Ha az osztályodat majd újra fel akarod használni, nem szabad megfeledkezni arról, hogy milyen kivételeket dobhat. Amíg jól van dokumentálva a kódod, addig nem biztos, hogy fejtörést fog okozni, de ha már kevesebb időt töltesz a dokumentálással, valahol újra fel akarod használni a kódodat, szintén fogni fogod a fejed, mert fejlesztés során olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak, ahogy az osztályod egyre többet tud."
Kezdjük azzal, hogy szerintem a rossz dokumentáció egyik esetben sem segít a későbbi fejlesztésekben, ebből a szempontból teljesen lényegtelen, hogy most kivételeket dobálsz, vagy az adott esetben túlságosan is kövérre hízó, macerás if-else blokkokat alkalmazod.
Ha pedig említetted az error tömbök visszaadását: ha épp a szar dokumentáció és az újrafelhasználás a példa, akkor hogyan emlékezz vissza, hogy mi is volt a megfelelő hibakezelési mód? Pl. hogy az error tömböd milyen formában érkezik, vegyünk egy példát:
$functionReturnValue = $myClass->myMethod();
if( $functionReturnValue['status'] == FALSE ){
......
}
else {
....
}Aztán kiderül, hogy basszus, nem is $functionReturnValue['status'] a megfelelő vizsgálandó visszatérési érték indexe, hanem mondjuk $functionReturnValue['result'].
Ha viszont eldobsz egy kivételt a hiba forrásánál, az garantált, hogy itt minél előbb megtudod, hol keletkezett a hiba (pl. ha fent van egy Xdebug extension, akkor az még szép táblázatos formában ki is írja neked), és nem próbálod folytatni a programkódot a rossz visszatérési értékekkel, stb.De hogy még reagáljak arra is érdemben, hogy "olyan exceptionöket fog dobálni az osztályod, amire nem számítottál korábban, és újra meg újra le kell őket kezelni. Nem is beszélve arról, hogy az exceptiönök szaporodhatnak":
erre röviden az az egyszerű reakció, hogy ha az egész try-catch blokkod legvégére a kivételosztályok ősosztályának elkapását is elintézed, akkor nyilván nem mondok újat azzal, hogy így minden kivételt elkapsz, azt is, ami specifikusan nem volt lekezelve.
Ezeket pedig szintén naplózhatod, és akkor tudod, hogy még milyen kivétel nincs lekezelve.
Pl.:
try {
$stuff = new MyClass();
// exceptiont fogsz eldobni, mégpedig így:
// throw new MyNewException( 'asdasd' );
$stuff->myMethod();
} catch ( MyOldException $e ){
...
} catch ( AnyOtherException $e ){
...
} catch ( Exception $e ){
...
// itt elkapod a többit!!!
}Így tehát azt az esetet is lekezelted, amit előre nem láttál - a másik esetben sokkal nehezebb ennyire általános receptet adni az "egyéb" kategóriába eső hibák megfelelő kezelésére és naplózására.
-
#8994
Sk8erPeter
nagyúr
mobal
#8985
Sk8erPeter
nagyúr
"csak amennyire tudom szeretném elkerülni a kivételeket"
Szerintem ez egyáltalán nem indokolt. Még ha a futási időhöz hozzá is teszel párszázadmásodpercnyit, a kivételkezelés akkor is ezerszer átláthatóbb hibakezelési forma, mint pl. a hatezer soros if-else blokkok. A kivételkezelésnél ezenkívül a saját kivételosztályaidat is felhasználhatod, az Exception osztály felülbírálásával, amibe tetszőleges kódot pakolhatsz, többek közt pl. naplózást, ami igen fontos lehet, és esetfüggő lehet, mit, hogyan és hova szeretnél naplózni. Viszont egy form esetén pl. nyilván nem naplózol, ha egy mezőt nem töltöttek ki. Ha az if-else blokkos megoldást választod, akkor viszont naplózási igény esetén azt valahogy bele kell tákolnod a blokkjaidba, nem marad egy szeparált helyen, ahogy pl. a kivételosztályaidat kigyűjtheted egy teljesen különálló fájlba. Nem beszélve arról, hogy a kivétel forrása (melyik sorban, melyik fájlban dobódott, stb.) nagyon könnyen felderíthető a kivétel elkapásakor, teljesen mindegy, hol, melyik függvényen belül dobtad el, azt a try-catch blokkban elkapod, majd lenyomozod, mi is volt a baj.
Egy szó, mint száz: a kivételkezelés szerintem épp, hogy nem egy kerülendő dolog, hanem érdemes alkalmazni.Egyébként pl. a PDO-nál is lehet "hagyományos úton" is hibákat kezelni, meg lehet úgy is inicializálni, hogy megmondod neki, hogy kivételeket dobjon, ne visszatérési értékeket kelljen vizsgálgatni, ami csak feleslegesen csinál a kódodból spagettikódot. Nem tudom, hogy vagytok vele, de én maradok a kivételkezelésnél.
-
#8984
Sk8erPeter
nagyúr
Speeedfire
#8983
Sk8erPeter
nagyúr
válasz
Speeedfire
#8983
üzenetére
Az ötlet jó, egy ilyen jellegű megoldás pl. ehhez hasonló lehet: [link]
Ez a cikk írójának saját megoldásával korábbi Drupal-verzióhoz azt csinálta, hogy a request URI-t felbontotta, és eszerint futtatott le egy keresést. Ezt a keresést mondjuk be kellene helyettesíteni egy alias-kereséssel, ráadásul itt nem gondol az ékezetes karaktereket tartalmazó URL-ekre, amiből manapság már bőven van (lásd pl. drupal.hu).
Persze ez most a felvetésedre nem megoldás, szóval nem egy kész, hűdefasza kód, de legalább valaki próbált nyekeregni egy kicsit erőltetetten a témában, azért linkeltem.
Igazából én is csak most kerestem rá, eddig nem jutott eszembe alias szerint keresgélni és javaslatokat mutatni, de tényleg jó ötlet lehet, főleg, hogy az aliasok jobb helyeken adatbázisban, külön erre szentelt táblában találhatók, így normális indexeléssel egy ilyen táblában való kutakodás elég gyors lehet. -
#8975
Sk8erPeter
nagyúr
raczger
#8974
Sk8erPeter
nagyúr
válasz
raczger
#8974
üzenetére
.htaccess fájlba tetted? Mondjuk gondolom igen. Elég furcsa, hogy nem működik. Végül is lehet, hogy az Options direktíva buzerálását le tudja tiltani a szolgáltató, mondjuk eléggé hülyeség lenne a részükről.
[link]
Pedig ez olyan opció, ami állítható.De inkább közelítsük meg másfelől a kérdést: akkor a rewrite rule-lal lehetne valamit babrálni.
Vegyük példának a Drupalt, ott is minden egyes kérés, ami nem fájlrendszerben létező fájlra vagy könyvtárra vonatkozik, ráfut az index.php-re:# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
### ...........
# Pass all requests not referring directly to files in the filesystem to
# index.php. Clean URLs are handled in drupal_environment_initialize().
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^ index.php [L]
</IfModule>A drupal_environment_initialize() függvény kezeli a továbbiakat.
A korábbi, 6-os verziónál még így nézett ki:
# Various rewrite rules.
<IfModule mod_rewrite.c>
RewriteEngine on
# Rewrite URLs of the form 'x' to the form 'index.php?q=x'.
RewriteCond %{REQUEST_FILENAME} !-f
RewriteCond %{REQUEST_FILENAME} !-d
RewriteCond %{REQUEST_URI} !=/favicon.ico
RewriteRule ^(.*)$ index.php?q=$1 [L,QSA]
</IfModule>Tehát itt explicite a q paraméternek adódott át a kérés, ezt a Drupal pedig lekezelte magának.
-
#8973
Sk8erPeter
nagyúr
raczger
#8972
Sk8erPeter
nagyúr
-
#8969
Sk8erPeter
nagyúr
modder
#8967
Sk8erPeter
nagyúr
Érdekesség, hogy ez a szintaxis a PostgreSQL-lel való kompatibilitás miatt került bele:
SELECT Syntax - LIMIT clause
"For compatibility with PostgreSQL, MySQL also supports the LIMIT row_count OFFSET offset syntax."Egyébként:
"LIMIT takes one or two numeric arguments, which must both be nonnegative integer constants (except when using prepared statements).
With two arguments, the first argument specifies the offset of the first row to return, and the second specifies the maximum number of rows to return. The offset of the initial row is 0 (not 1):
SELECT * FROM tbl LIMIT 5,10; # Retrieve rows 6-15
To retrieve all rows from a certain offset up to the end of the result set, you can use some large number for the second parameter. This statement retrieves all rows from the 96th row to the last:SELECT * FROM tbl LIMIT 95,18446744073709551615;
With one argument, the value specifies the number of rows to return from the beginning of the result set:SELECT * FROM tbl LIMIT 5; # Retrieve first 5 rows
In other words, LIMIT row_count is equivalent to LIMIT 0, row_count."A phpMyAdmin is utóbbi szintaxist használja.
Persze teljesen jó az említett OFFSET-et tartalmazó szintaxis, meg talán kifejezőbb is a query általa, de említésre méltó az idézett változat is, hátha valaki azt ismeri jobban - MySQL query-knél én utóbbit gyakrabban szoktam látni kész kódokban (nyilván a másikra is bőven akad példa). -
#8964
Sk8erPeter
nagyúr
Peter Kiss
#8963
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8963
üzenetére
Jaja, vágesz, szerencsére szép lassan fejlődget a PHP. Most moddert UTÁNOZVA (
) feliratkoztam én is a PHP Internals levlistára, ott éppen arról tárgyalnak, hogy a C#-os getter-setterhez hasonló metódusokat a __get() helyett vagy mellett be lehetne tenni a core-ba.Egyetértek, totál semmi értelme annak a kódnak, amit írt. Igazából ezt most ezzel együtt már harmadjára írom le.
De megmondom őszintén, annak az eval()-os példának sincs túl sok, amit imént írtál. Beraktad egy stringbe, kiértékelted, és? -
#8954
Sk8erPeter
nagyúr
Speeedfire
#8943
Sk8erPeter
nagyúr
válasz
Speeedfire
#8943
üzenetére
Ezt már korábban írtam, de ennek ebben a formában nem sok teteje van:
isset($_POST['hirlevel']) ? $hirlevel = 'igen' : $hirlevel = 'nem';Így tulajdonképpen nem indokolt, hogy miért ne használd inkább az if-else formát.
Akkor már itt is leírom úgy, ahogy még értelme is van ezt a formát használni:
$hirlevel = isset($_POST['hirlevel']) ? 'igen' : 'nem';
Így még teljesíti is azt a célt, hogy érdemben lerövidíti a kódot, és nem kell ugyanazt a változónevet ismételgetni (ahogy pl. egy if-else feltételvizsgálatnál). Meg utóbbi formában gyorsan átlátható, milyen értéket szeretnél egyből hozzárendelni, és milyen feltételtől teszed azt függővé. -
#8939
Sk8erPeter
nagyúr
Sk8erPeter
#8938
Sk8erPeter
nagyúr
válasz
Sk8erPeter
#8938
üzenetére
Kifejtem kicsit, miért írtam, hogy picit "gányolás" a második megoldás. Önmagában természetesen a különböző azonosítóval ellátott id-khoz ugrálás egyáltalán nem gány, sőt, gyakran alkalmazott módszer, gondolom ezzel nem mondtam újat (lásd akár Wikipédia, stb.).
Az említett módszer viszont nem minden esetben működik. Vegyük azt az esetet, hogy a formot egy teljesen más feldolgozó fájlba irányítjuk, majd a feldolgozó fájlból PHP segítségével (header fv.-nyel) visszairányítjuk, a visszairányítás után a megfelelő üzeneteket kiírjuk, stb... Ebben az esetben hiába rakjuk a feldolgozó fájl neve mögé a hashmarkos fragmentet, azt a szerveroldal nem fogja megkapni, tehát nem is tudjuk beállítani a visszairányítós részhez.
Erre is van azonban kerülő megoldás: ha a formba beleteszünk pl. egy hidden mezőt, amiben eltároljuk annak a div-nek (vagy más HTML-elemnek) az azonosítóját, amihez majd ugrani szeretnénk a form feldolgozása után, és így állítjuk össze a címet, amihez szeretnénk átirányítani a felhasználót:
(legegyszerűbb példával)// visszairányítás
$filepath = 'test_jump.php';
$id_of_div = $_POST['id_of_div'];
header('Location: '.$filepath.'?#'.$id_of_div);
die();Ebben az esetben (ha már nem AJAX-szal küldjük el a formot) viszont figyelni kell arra is, hogy a form validálása/feldolgozása után kiírt üzenetek (ez vagy az a mező hiányzott, stb.) is a meghatározott id-jű div-be kerüljenek. Persze az is megoldható, hogy csakis hiba esetén írjon ki valamit, és akkor viszont annak megfelelően módosítjuk a fragmentet...
Na, ezek miatt írtam, hogy alaposan megbonyolítja a kódot, és innentől akár már nevezhető gányolásnak is. Bár lehet, hogy erős szó rá. -
#8938
Sk8erPeter
nagyúr
cAby
#8937
Sk8erPeter
nagyúr
Igen, AJAX-szal.
Persze lehet gányolni is, pl. úgy, hogy egyes bekezdéseknek id-t adsz, majd megoldod, hogy odaugorjon a feldolgozást követően a böngésző, ahogy itt ebben a példában ugrabugrál a linkekre kattintva: [link], formhoz úgy lehet megoldani, ha pl. ha a hash-sel kiegészített cím van az action attribútumban.
Pl. action="test_jump.php?#blabla" -
#8929
Sk8erPeter
nagyúr
cAby
#8924
Sk8erPeter
nagyúr
Na, akkor most kezdd elölről, egy másik sessionnel. Küldj rá egy session_destroy-t, majd kezdd elölről a folyamatot.
Nagyon nagy csoda lenne valóban, ha a PHP csak úgy magától kitalálná, hogy te melyik azonosítójú elemet is szeretted volna kedvencek közé menteni, mivel szerveroldalon a form elküldése után csak annyi látszik, hogy létezik mondjuk a $_POST['add'], vagy épp a $_POST['del'], tehát megnyomtad a hozzáadó gombot, vagy megnyomtad a törlő gombot, de annak SEMMI nyoma nincs, hogy te most melyik azonosítóhoz tartozó hozzáadó-törlő gombot nyomtad meg. Mégis honnan a büdös francból kellene látnia a szerveroldalnak, hogy mi a szándékod?A CIKLUSON BELÜL van egy ilyen részed:
if ( $_POST['add'] )
{
$_SESSION['fav' . $row['id']] = 'true';
}
if ( $_POST['del'] )
{
$_SESSION['fav' . $row['id']] = 'false';
}Ergo az $sql = "SELECT * FROM items WHERE sitelink = '" . $site_link . "'"; query-d összes eredményén végigrohangászol, majd ha épp létezik szerveroldalon a $_POST['add'] vagy a $_POST['del'], akkor az aktuális cikluslépés sorazonosítójához tartozó sessionváltozóba eltárolod a "true" értéket.
Így ha egyszer megnyomtad azt a szaros gombot, akkor elméletben mindegyik adatbázisban megtalált azonosítóhoz tartozó session-változónál true lesz az érték.De lassan kifogyunk a magyarázat-kombinációkból.
Szerk.:
... és ahogy látom, modder nagyjából ugyanazt írta le közel egyidőben, mint én, más szavakkal.Egyébként könnyebb lenne látnod az egész eredményét, ha mondjuk adott felhasználóhoz nemcsak sessionbe mentenéd a kedvenceit, hanem úgy, ahogy van is értelme, adatbázisba. Mert így csak a munkamenet erejéig fognak élni a kedvencek.
-
#8927
Sk8erPeter
nagyúr
Peter Kiss
#8925
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8925
üzenetére
Minél lehet gyorsabb?
Annál kétlem, hogy gyorsabb, mintha ráküldesz egy COUNT(*)-ot az eredeti táblára, az eredeti WHERE feltételekkel, mint az, ha subquery-be teszed az eredeti query-t, max. egyszerűbb megírni.
De ez a számolgatásra történő optimalizálás továbbra sem értem, hogy jön ide.
Ha ráküldesz egy SELECT-et a bejegyzésekre, és lószart sem ad vissza, akkor abból elég egyértelmű, hogy nincs egy darab bejegyzés sem. A megadott dátumok meg eleve korlátozást jelentenek a bejegyzésekre, így nem mindent kérünk le egyszerre, és csak utána szűrünk. A szűrt feltételeknek megfelelő bejegyzéseket lekérjük, és ezután már tudni fogjuk, hogy van-e eredménye a lekérdezésnek.
Azt is lehetne csinálni, hogy először szépen lekérdezed, hogy van-e egyáltalán a feltételeknek megfelelő bejegyzés, majd ha van, akkor egy újabb query-vel ismét lekéred a feltételeknek megfelelő bejegyzéseket, de ekkor már pl. ki is íratod őket, de szerintem teljesen felesleges kétszeri query-t ráküldeni, ha a feladat úgyis csak az, hogy jelenítsük meg az adott dátumhoz tartozó postokat. Ha nincs ilyen, akkor azt jelezzük. -
#8923
Sk8erPeter
nagyúr
Peter Kiss
#8921
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8921
üzenetére
"Keress egy nagy adatbázist, és számoltasd meg valamilyen feltétel után, hány darab rekord van benne. Utáne tedd meg ugyanezt EXISTS-cel. Na, látod?! "
Ez nem tudom, hogy jön ide.
Ha van egy archívum, amiből csak az adott napra eső bejegyzéseket szeretnéd megjeleníttetni, ráküldesz egy SELECT-et. Akkor már megvan, hány bejegyzést is sikerült lekérni, ezt megtudni pedig nem egy erőforrásigényes feladat a lekérés után."Nyilván, ha kell neki minden post, és nem csak az, hogy van-e benne, akkor okés, csak nem nyálaztam vissza, mi volt a lényeg, csak odáig láttam, hogy true / false jön ki belőle."
Akkor indokolatlan a kötekedés."Egyébként, ha én ORM-et fejlesztek, akkor akár azt ics megcsinálhatom, hogy módosítom on-the-fly a query-t, hogy az adatbázis számolja össze az összes sort, ne pedig a memóriában történjen meg ugyanez."
Ezt kifejthetnéd bővebben is. -
#8922
Sk8erPeter
nagyúr
cAby
#8918
Sk8erPeter
nagyúr
Basszus, adj már egy értelmezhető nevet is a kedvenceidnek... Pl. az adattábládban a különböző azonosítók mellé vegyél fel még egy mezőt, aminek az a neve, hogy mondjuk "fav_name", vagy hasonló, és aztán lekéréskor pedig írasd ki, hogy melyik azonosítót is adtad hozzá a kedvencekhez. Akkor meglátod, hogy valóban jól működik-e.
Nézd is meg, mit csinálsz, ne csak azt csekkold, hogy egy azonosító a sok közül kedvencek közé lett mentve.
Pl. ha a hozzáadható kedvencek a következők: alma, béka, cékla, dió, eke, és én épp a békát szeretném kedvencek közé menteni, akkor nem szeretném, ha helyette ekét kapnék az arcomba.Az index.php-det egyébként így kezded:
<?php
session_start();
?>
<?php
$sql = ......
ahelyett, hogy a tökéletesen felesleges záró- és nyitótaget kiszednéd:
<?php
session_start();
$sql = ...... -
#8913
Sk8erPeter
nagyúr
cAby
#8912
Sk8erPeter
nagyúr
"Index.php-ben is nyilván van ilyen ciklus"
Szerintem ez a kódod alapján nem annyira nyilvánvaló."Így működik ahogy akarom, felveszi a listába és onnan el lehet küldeni e-mail-ben."
Honnan fogod tudni, MELYIKET kell felvenni a listába?
Hadd "idézzek" a kódodból:if ( $_SESSION['fav_' . $row['id']] == 'false' )
{
echo "<form action='index.php' method='post'>
<input type='submit' name='add' value='add' />
</form>";
}
elseif ( $_SESSION['fav_' . $row['id']] == 'true' )
{
echo "<form action='index.php' method='post'>
<input type='submit' name='del' value='del' />
</form>";
}Itt kiraksz egy formot, de magában a formban egy darab azonosítót nem rejtesz el (mondjuk egy hidden inputtal, vagy másképp), így nem tudom, honnan szeded, hogy mondjuk épp az 5-ös azonosítójút szeretném eltárolni a kedvencek közé.
Egyébként itt az if-elseif vizsgálat nem túl ésszerű - inkább azt kéne vizsgálnod, hogy mondjuk true értéke van-e, ha igen, kirakod a törlőformot, KÜLÖNBEN (simán else) a hozzáadó formot.Amúgy ha mutatsz egy hasonló kódot, akkor nem ártana a teljeset, hogy el tudjuk dönteni, valamilyen kód indokolt-e egyáltalán.
Az például nem túl szép megoldás, hogy az ismeretlen eredetű $sum_items mennyiségig végigmész az elemeken, és egyesével, cikluslépésenként kéred le adatbázisból a különböző azonosítójú elemeket.További tipp: ha azt szeretnéd, hogy egy form ugyanoda legyen elküldve, ahol ki is van írva, akkor érdemes az action attribútumot inkább üresen hagyni a formnál (action=""), ez egy valid megoldás, és könnyebben "költöztethető" - tehát ha az index.php helyett megváltoztatod a fájl nevét asdasdasd.php-re, akkor is működni fog.
-
#8911
Sk8erPeter
nagyúr
Peter Kiss
#8910
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8910
üzenetére
Nem igazán értem, miért kellene feltétlenül limitálni. Sehol nem írta, hogy az example.com/archive/2011/01/27 oldal megnyitására csak egyetlen darab postnak kellene megjelenni - na meg miért is feltételezzük, hogy aznap csak egyetlen cikk íródott...
"Nem tudom, hogy a count() mit csinál a háttérben"
Nem Kohanáztam soha, de nem nehéz kitalálni, hogy a count a query által visszaadott vagy érintett sorok számát jelenti...
És ja, kb. 5 másodperces Guglizás alapján ki is derül: [link].A lényeg: mivel egy napon nem feltétlenül csak egy cikk készülhetett, ezért nem hiszem, hogy korlátozni kellene a lekérdezés eredményét (legalábbis eddig erről nem volt szó), így a count teljesen jó annak eldöntésére, hogy van-e egyáltalán eredménye a lekérdezésnek...
===
(#8909) cAby : finoman szólva ocsmány a kód (Te kérdezted meg a publikumot
), és azt sem értem, mitől működik nálad úgy, ahogy akarod (sanszos, hogy nem is úgy működik, ahogy kellene), amikor teljesen indefinit, hogy a form elküldésével melyik valamit akarod a kedvencek közé tenni.
Az index.php-dben meg vidáman használod a $row['id']] változót, ami számomra teljesen ismeretlen, hogy honnan kéne, hogy valami valós értéket kapjon. (A fav.php-dben van egy $row az adatbázis-lekérés eredményét megjelenítő cikluson belül, de annak ehhez köze nincs.) -
#8894
Sk8erPeter
nagyúr
Peter Kiss
#8892
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8892
üzenetére
Köszi szépen, ezt jó tudni!
Nekem új a copy-on-write, mert ezek szerint ha egy buzinagy tömböt átadok pl. egy függvénynek, akkor amennyiben az nem vár referenciát, nem is másolódik le az egész tömb, amennyiben a paraméterként kapott tömböt nem módosítom - pedig erre eddig más nyelvekben tanultak miatt gondosan odafigyeltem. Ergo nem is muszáj referenciát odatenni (csak ha az eredeti tömböt amúgy is módosítani szeretnénk).
Ez hasznos infó volt! -
#8890
Sk8erPeter
nagyúr
Peter Kiss
#8888
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8888
üzenetére
Erre próbáltam azóta forrást találni, de nem sikerült - tudsz ilyet, ahol ezt igazolják?
Nem világos számomra, miért másolódna le.
Elvileg ez csak egy másfajta módszer feltételvizsgálatra.Példa:
$is_true = false;
$test_array = array('blabla'=>'asdasd', 'qweqweqw'=>123, 45, 123, 232);
$test_array['blabla'] = ($is_true) ? 'yxcyxc' : 'qwertz';Itt nem világos, hogy az $is_true feltételvizsgálathoz minek másolódna le az egész $test_array tömb.
-
#8887
Sk8erPeter
nagyúr
Speeedfire
#8886
Sk8erPeter
nagyúr
válasz
Speeedfire
#8886
üzenetére
Ja, hát azt még eddig nem mondtad, hogy pontosan ugyanarra készül a form, csak egyik esetben ki lesz egészítve egyebekkel is.
Na mindegy, azért jól elvoltunk. -
#8885
Sk8erPeter
nagyúr
Speeedfire
#8884
Sk8erPeter
nagyúr
válasz
Speeedfire
#8884
üzenetére
Nem sebességről beszéltem.
Logikus és átlátható struktúráról. Legalábbis amennyire értettem, egyik form regisztrációra szolgálna, a másik meg valami teljesen más feladatra. De ahogy érzed, ez csak tanács volt, nem kötekedés! -
#8883
Sk8erPeter
nagyúr
Speeedfire
#8882
Sk8erPeter
nagyúr
válasz
Speeedfire
#8882
üzenetére
Mondjuk szerintem praktikusabb lenne teljesen szétválasztani a dolgot.
Akkor megvizsgálod, hogy mik a feltételek, ha mindenképp meg kell jeleníteni egyik vagy másik formot, akkor bizonyos feltételek fennállása esetén x formot jeleníted meg, más feltételek esetén pedig y formot. De ne kelljen minden egyes elem létezéséhez vizsgálgatni, majd azok értékét a vizsgálatok eredménye szerint beállítgatni, hanem legyen egy kész formod mindkettőre (mivel ezek szerint úgyis teljesen eltér a kettő "témája").
Persze nem akarok okoskodni, csak tanács, kevesebb szívás van vele, és jobban elkülöníthető.Szerk.:
"Amúgy ezzel is megy."
Azért megy, mert már kiszedted az "if" szócskát, ami az előbb teljesen értelmetlenné tette az egészet.
Egyébként meg így sincs túl sok értelme szerintem, mert akkor tök felesleges a "?:"-operátor, nem ilyen használatra való. -
#8881
Sk8erPeter
nagyúr
Speeedfire
#8880
Sk8erPeter
nagyúr
válasz
Speeedfire
#8880
üzenetére
Egyébként itt az if és "?:" operátor keveréke a kódodban eleve rossz, szóval rosszul használod a kiértékelést, most akkor el kell döntened, hogy mit használsz:
if-fel:
if(isset($_GET['kategoria'])){
$button='Next';
}
else{
$button='Register';
}vagy inkább (!!):
$button='Register';
if(isset($_GET['kategoria'])){
$button='Next';
}"?:" ("ternary") operátorral:
$button = ( isset($_GET['kategoria']) ? 'Next' : 'Register' );
U.i.: hozzáteszem, azért nem épp a "kategoria" $_GET-érték meglététől tenném függővé egy regisztrációs űrlap gombjának feliratát (a regisztrációs folyamat köv. lépése vagy épp maga a regisztráció elkezdése). Persze ez egyéni döntés kérdése.
-
#8876
Sk8erPeter
nagyúr
Speeedfire
#8874
Sk8erPeter
nagyúr
válasz
Speeedfire
#8874
üzenetére
Korábban definiálj egy default szervert, ServerName localhost és a többi értékkel, az mindenképp kerüljön bele, aztán jöhetnek a VirtualHostok. Aztán persze ez is lehet külön VirtualHost. Mondjuk nem lenne szar látni a teljes konfigfájlt, mit alkottál eddig, így úgyis csak nyújtani tudjuk a témát, mint a rétestésztát.
-
#8872
Sk8erPeter
nagyúr
Speeedfire
#8871
Sk8erPeter
nagyúr
válasz
Speeedfire
#8871
üzenetére
Csodás.
Csak arra céloztam, hogy ha még nem műxik, akkor mutasd meg, addig mivel próbálkoztál, gondolom ez már a működő változat.
Egyébként már épp gondoltam, hogy írok cikket VirtualHostokról, de közben találtam egy egész jót:
XAMPP telepítése, helyi mail szerver beállítása és domének kialakítása.===
(#8869) mobal :
"/etc/hosts akart lenni, persze most megint nem tudom, hogy ez linux esetén van e."
Őőőő, miért, talán Windows esetén lenne? -
#8868
Sk8erPeter
nagyúr
sekli
#8856
Sk8erPeter
nagyúr
Igen, ez lehetséges, viszont általában itt nem szokott megállni egy tudomány. Egy egyszerűnek kikiáltott oldal többnyire azzal indul, hogy "csak annyi kéne, hogy ...... és semmi más", aztán majd úgyis felmerül az igény valami jobbra, szebbre, könnyebben kezelhetőre, stb... akkor meg már egy túlságosan leegyszerűsített dolog nem lesz egyszerű, amihez ráadásul nem készül annyi modul, smink (theme, template), stb.
Ezért is gondolom úgy, hogy hosszú távon is jobban járna egy népszerű és folyamatosan bővített, moduláris CMS-sel, főleg, ha még nem igazán lát bele a dolgok mélyébe.Azért ajánlottam a WordPress-t, mert többnyire ezt szokták klasszikus blogolós feladatokra ajánlani, meg többektől hallottam már, hogy a felülete tényleg kezdők számára is intuitív - a Drupal eléggé tanulós. Joomlát meg elvből nem ajánlanék senkinek, a topicban már több ízben kifejtettem, miért nem.
-
#8867
Sk8erPeter
nagyúr
Speeedfire
#8866
Sk8erPeter
nagyúr
válasz
Speeedfire
#8866
üzenetére
Azért legközelebb azt is mutasd meg, mit raktál a konfigfájlba, mert néma gyereknek az anyja se látja a fától az erdőt.
===
(#8859) mobal : mi az a hosts.etc? Én olyanról még soha nem hallottam.
-
#8855
Sk8erPeter
nagyúr
sekli
#8854
Sk8erPeter
nagyúr
Nem próbáltam még, de számomra ez alapján nem annyira szimpatikus:
"Simple - simple to install and easy to modify. The entire site is stored in a single HTML-file - no database is needed. You edit your entire site with your favorite HTML-editor, upload the content file and get a dynamic website!"
Nem igazán értem, hogy amennyiben mindenféle adatbázis nélkül működik, szimplán HTML-editorral kell szerkeszteni, majd feltölteni a tartalmat, akkor ez mitől lesz a klasszikus értelemben vett CMS. Ahogy azt sem, hogy ez mitől nevezhető "dinamikusnak"...
A klasszikus CMS-ekben azért mód van a tartalmak különböző szempontok szerinti kigyűjtésére, rendszerezésére, szerepkörök állítgatására, és így tovább, lásd: [Tartalomkezelő rendszerek].
Ez ennyi alapján ezekből elég kevés szempontnak felel meg. Kicsit komolytalannak tűnik.
De leírhatnád, szerinted miért is jó ennek a használata azonkívül, hogy gondolom ad valamiféle keretet a szerkesztendő oldalaknak - nem próbáltam még, így érdekelne, de nekem már az elég gyanús, hogy nincs szükség adatbázisra. -
#8853
Sk8erPeter
nagyúr
rii
#8852
Sk8erPeter
nagyúr
Egyszerű blogolásra elvileg WordPress a legkönnyebb megoldás.
Nem ajánlom, hogy mindenféle összeollózott free PHP-kódokkal szutykolj, mert nagyon sok a hibás, és az olyan, ami tele van biztonsági résekkel. Ráadásul egy népszerű, komplett CMS-hez sok tutorialt és modult is találsz, egy összeollózott kódhoz meg általában nem a legjobb a dokumentáció sem... -
#8851
Sk8erPeter
nagyúr
Tele von Zsinór
#8850
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#8850
üzenetére
Jaja, ez így van.
Csak a motornak kell lekezelnie megfelelően a különböző (sub)domaineket. -
#8849
Sk8erPeter
nagyúr
Speeedfire
#8848
Sk8erPeter
nagyúr
válasz
Speeedfire
#8848
üzenetére
Szerintem sem az.
-
#8847
Sk8erPeter
nagyúr
Speeedfire
#8846
Sk8erPeter
nagyúr
válasz
Speeedfire
#8846
üzenetére
Na, akkor jó.
Amúgy érdekes téma, mit sorolnak direkt marketingbe, én alapvetően a keresőoptimalizálást nem sorolnám ide, mert marketing tanulmányok alapján (jó, ez lóf@sz, amit én tanultam belőle) ez számomra valahogy már kiesik ebből a fogalomból - itt mégis részben ezt is említik, mint szempontot: [Wikipedia - Direct_marketing]
"Online Tools
[...]
Search: 49% of US spending on Internet ads goes to search, in which advertisers pay for prominent placement among listings in search engines whenever a potential customer enters a relevant search term, allowing ads to be delivered to customers based upon their already-indicated search criteria.[12] This paid placement industry generates more than $10 billion dollars for search companies. Marketers also use search engine optimization to drive traffic to their sites." -
#8845
Sk8erPeter
nagyúr
Speeedfire
#8844
Sk8erPeter
nagyúr
válasz
Speeedfire
#8844
üzenetére
"Seo ebben a kategóriában nem nagyon szokott lenni, inkább direkt marketing."
Ezt a megjegyzésedet most nem igazán értettem. Az nem direkt marketing a szó szoros értelmében, ha javítanak a keresőoptimalizálási technikákkal a találati listán való megjelenésben. Mivel ebben még nincs semmi közvetlen kapcsolatfelvétel az értékesítés ösztönzésére...
Arra céloztam, hogy ha a teljesen különálló témák különböző domaineken vannak, az még javíthat is a Google-féle értékelésen, mert nem keverik a szezont a fazonnal azonos domain alatt.A Yii-t nem ismerem, de gondolom valami hasonló gondolatmenetet kéne követni, mint ahogy itt a többnyelvűsítésre különböző aldomaineket hoznak létre: [link].
-
#8843
Sk8erPeter
nagyúr
Speeedfire
#8841
Sk8erPeter
nagyúr
válasz
Speeedfire
#8841
üzenetére
Szerintem annyira nem hülyeség maga az alapötlet, hogy más aldomainen van, ha más témakörről van szó, így legalább jobban elkülöníthető, ráadásul a cím is könnyebben megjegyezhető, aztán lehet, hogy SEO-val kapcsolatos előnyei is vannak.
Egyébként mindezt nem Yii-vel akarod megoldani? Csak mert szerintem tuti van rá valami beépített megoldás, hogy subdomainek vagy teljesen más domainek szerint elkülönítve jelenjen meg más tartalom, legalábbis ha Drupalban van erre mód (azonos motor kapcsolódik más-más domainekhez, és az más-más tartalmat jelenít meg - sőt, akár más-más modulok is tartozhatnak ezekhez), akkor feltételezem, hogy egy olyan népszerű frameworkben is megoldották, mint a Yii. Saját megoldás készítgetése előtt azért nézz körül alaposan a Yii doksijában.
===
(#8842) Coyot : jogos a reakció.
-
#8837
Sk8erPeter
nagyúr
Scobbyka
#8835
Sk8erPeter
nagyúr
válasz
Scobbyka
#8835
üzenetére
Azért előbb kifejthetnéd, hogy ha csak ez van a fájlodban, és nem használod még template-ezésre sem, mi a büdös francnak echo-zni stringként a táblázatot, amikor sima HTML-ként is kiírhatnád, és nem rontanád a teljesítményt feleslegesen.
Plusz nem ártana valid kódot használni.Többiről bővebben: [link].
-
#8824
Sk8erPeter
nagyúr
CSorBA
#8821
Sk8erPeter
nagyúr
A "kirohanásom" oka az volt, hogy nem szeretem, amikor valaki felrak egy hibákkal és sebezhetőségekkel telerakott hosszú példát, amiből aztán kezdők nagyon rossz mintát vehetnek, mert gyorsan megörülnek, hogy "jujj de jó, itt egy kész példa, akkor nekem már nem is kell megtanulnom programozni".
===
(#8822) Speeedfire : hát ha valaki ebből szűri ki a lényeget, akkor az rövid és hosszú távon is nagyon rosszul jár.
Ezért érdemes megnézni, mit linkel az ember, nehogy rossz példát mutasson.
Amikor nagyon kezdő voltam, és ilyen linkeket találtam, én is mindig megörültem, hogy de jó, valaki most megmutatja nekem, hogy kell. Aztán később kapartam az arcom, amikor kezdtem belejönni.Amúgy a kód még csak említést sem tesz a sessionök használatáról.
-
#8820
Sk8erPeter
nagyúr
Speeedfire
#8818
Sk8erPeter
nagyúr
válasz
Speeedfire
#8818
üzenetére
Na ezt a kódot inkább nem kellett volna...
Sorban, amit csak elsőre észrevettem, így még tuti lehetnek benne hibák:
$jelszo1 = $_POST['jelszo1'];
eleve ez az ugyanolyan nevű változónak átadás, meg az, hogy nem is csekkolja, létezik-e egyáltalán a $_POST tömbben a 'jelszo1' kulcson valami, vagy még el sincs küldve ez az érték.
Ezért lehet kapni egy ocsmány notice-t, ha nincs kikapcsolva.
Meg vegyíteni ilyen durván a magyar nyelvet az angollal szintén nagyon rossz szokás.
Plusz ez a megoldás:
$statusz = "OK";
vagy épp
$statusz= "HIBA";
Ahelyett, hogy mondjuk true, false vagy hasonló, értelmes értékekkel dolgozna.
Na meg hibakezelésre a kivételkezelés a szép.
Vannak szimpla szintaktikai hibák is, pl.:
if (emptyempty($jelszo1))Ha hiba van, akkor egyszerűen megjeleníti az üzenetet, majd egy "Vissza" linket, ahelyett, hogy mondjuk a form tetején megjelenítené a hibát.
Jujj... de csak most látom a legrosszabbat:
$parancs = mysql_query("INSERT INTO regisztracio (felhasznalo,jelszo,email,regisztralt) VALUES('$felhasznalo','$jelszo','$email',NOW())");
Nem gáz ám, hogy lazán lehet SQL Injectiont alkalmazni...
Ja, de van egy valosf() függvény, az még előbb lehet, hogy megtalálja, ha nem engedélyezett karakter van benne. De akkor is, ettől a kódtól feláll a szőr a hátamon, abszolúte nem újrafelhasználható, pl. ha ugyanezt valaki kimásolja, és máshol alkalmazza, azt a függvényt meg nem küldi rá korábban, akkor ott van lazán az SQL Injection.Aztán a sikeres regisztráció megtörténte után számomra rejtély, hogy mi a büdös francnak rak ki egy "regisztráció" linket, és csak azt.
Később:
$belepoid = $_GET['belepoid'];
Ez már megint ellenőrzés nélkül, plusz nehogy már hozzá legyen csapva az URL-hez a 'belepoid'...Vegyük a kilepes.php-t:
$parancs = "UPDATE regisztracio SET belepoid='' where felhasznalo='$felhasznalo'";
mysql_query($parancs);
//OLDAL TARTALMA
echo"Sikeresen kiléptél.";Ez most komoly?
Úgy léptet ki, hogy a belepoid mező tartalmát üres stringre állítja?Ez a kód botrányosan szar.
Ha javasolhatom, ezt többet ne ajánlgasd senkinek referenciaként. -
#8814
Sk8erPeter
nagyúr
Tele von Zsinór
#8813
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#8813
üzenetére
Ez egy nagyon jó módszer.
-
#8798
Sk8erPeter
nagyúr
Louloudaki
#8797
Sk8erPeter
nagyúr
válasz
Louloudaki
#8797
üzenetére
Jaja, engem mezei felhasználóként rohadtul nem érdekelne, hogy a szerver szerint mennyi az idő, legfeljebb az, hogy mennyi időm van még a sorsolás lezárásáig.
Látványosabb is, meg egyértelműbb is. -
#8796
Sk8erPeter
nagyúr
Louloudaki
#8795
Sk8erPeter
nagyúr
válasz
Louloudaki
#8795
üzenetére
Szívesen.
Ha sorsolás, és azt akarod megmutatni, pontosan hány másodperc van még a sorsolás lezárásáig, akkor nem igazán látom be, miért nem visszaszámlálóval oldod meg...
"nem is akarok másodpercenként servert kérdezni időről, be is halna az egész"
Én is erről beszéltem korábban... de épp Te magad írtad, idézlek:
"szerveridőt lekérdem phpval, majd kiíratom a html fájlomba, és azt szeretném, hogy onnantól kezdve a másodpercek is ketyegjenek meg frissüljön az idő magától [.....] nem flash, és nem kliens oldali idő kell."
Ezt lehetett úgy értelmezni, hogy nem akarsz kliensoldalon számolgatni. De akkor félreérthető volt: tehát a megoldás, hogy először szerveroldalról berakod a pontos időt a kliensoldalon megjelenő kódba, majd kliensoldalon számolsz tovább. Ha nem visszaszámlálót szeretnél, hanem csak egy normál órát, akkor itt van egy: [link].Ja, egyébként a jQuery Countdown-nal felfelé is tudsz számoltatni: [link] (bár a visszaszámláló még mindig indokoltabb).
-
#8794
Sk8erPeter
nagyúr
Louloudaki
#8791
Sk8erPeter
nagyúr
válasz
Louloudaki
#8791
üzenetére
Akkor sem indokolt, hogy másodpercenként AJAX-os kéréseket intézz a szerver felé...
Használd ezt a visszaszámláláshoz, ez elintézi neked, ki is írja, testreszabható:
jQuery Countdown
Nyilván úgy inicializálod, hogy mondjuk egy script tagbe berakod PHP-vel a kezdeti időt.
Egy oldalon én is pont sorsoláshoz ezt használtam fel.
Ezzel azt is meg tudod oldani, hogy a visszaszámlálás lejártakor meghívsz egy tetszőleges függvényt - pl. újrakezded a visszaszámlálást. Nagyon hasznos, visszaszámlálásokhoz "must-have".Egyébként mint említettem, ha nagyon parázol a kliensoldal pontossága miatt, akkor se másodpercenként korrigálj és vesd össze a kliensoldali számláló értékével.
De ha szerveroldali idővel inicializálod a visszaszámlálót, akkor a kliensoldal nem lesz annyira pontatlan, hogy emiatt különösebben meg kellene ijedned.(#8792) cAby: Szívesen!
-
#8790
Sk8erPeter
nagyúr
cAby
#8789
Sk8erPeter
nagyúr
Ja, már minden világos.
Akkor ez egy jó megoldás lehet (kipróbáltam, műxik):<?php
$_GET_array = $_GET;
$_GET_array['price_asc'] = 'true';
$path_ascending_for_markup = $_SERVER['SCRIPT_NAME'].'?'.http_build_query($_GET_array, '', '&');
$_GET_array['price_asc'] = 'false';
$path_descending_for_markup = $_SERVER['SCRIPT_NAME'].'?'.http_build_query($_GET_array, '', '&');
?>
<div>
<a href="<?php echo $path_ascending_for_markup;?>">Növekvő ↑</a> |
<a href="<?php echo $path_descending_for_markup;?>">Csökkenő ↓</a>
</div>(A $_GET tömböt szándékosan adtam át egy másik változónak, mert közvetlenül módosítani szerintem nem szép (ahogy a $_POST tömböt sem szoktam közvetlenül módosítani).)
-
#8788
Sk8erPeter
nagyúr
cAby
#8787
Sk8erPeter
nagyúr
Én is erről a formról beszéltem, amit kitöltenek... Akkor az index.php-n lévő formodat (ahova beírják a keresendő kulcsszót) egészítsd ki azzal, amit mutattam. Aztán a keres.php oldalon elhelyezhetsz még egy linket, ami a $_GET['price_asc'] értékét módosítja, tehát van egy link, ami a jelenlegi keresendő érték+'&price_asc=false' vagy épp true.
-
#8786
Sk8erPeter
nagyúr
cAby
#8785
Sk8erPeter
nagyúr
Pl. úgy megoldható, ha kiegészíted a jelenlegi keresőformodat így:
<form ........>
<div class="form-elements-wrapper">
...................
<label for="price_asc">Rendezés:
<select id="price_asc" name="price_asc">
<option value="true"<?php if(isset($_GET['price_asc']) && $_GET['price_asc'] == 'true'){echo ' selected="selected"';}?>>Növekvő</option>
<option value="false"<?php if(!isset($_GET['price_asc']) || $_GET['price_asc'] == 'false'){echo ' selected="selected"';}?>>Csökkenő</option>
</select>
</label>
....................
</div>
</form>A pontok helyére nyilván helyettesítsd be a saját attribútumaidat, illetve mezőidet.
-
#8784
Sk8erPeter
nagyúr
Peter Kiss
#8783
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8783
üzenetére
Jaja, teljesen egyetértek.
Legfeljebb első oldalbetöltéskor lekéri a szerveridőt, aztán tovább már csak kliensoldalon számol.
Különben tökéletesen feleslegesen zabál fel rengeteg szabad erőforrást a szervertől. -
#8782
Sk8erPeter
nagyúr
Louloudaki
#8781
Sk8erPeter
nagyúr
válasz
Louloudaki
#8781
üzenetére
Vagy jQuery, vagy más, teljesen mindegy.
Amúgy miért kell neked másodpercenként AJAX-szal lekérni a szerveridőt?
Miért nem jó itt kliensoldali számolgatás, és legfeljebb ritkábban szerveroldali időlekérés az ellenőrzés/korrekció érdekében? -
#8778
Sk8erPeter
nagyúr
fulton
#8773
Sk8erPeter
nagyúr
Nem ártana ellenőrizni, hogy mi a hiba konkrét oka. Hibaellenőrzés nálad sehol nincs.
Ráadásul erről szokj le, hogy előbb kiíratod a sikerről szóló üzenetet, mielőtt egyáltalán az érdemi feladatot végrehajtanád.
Azt az ellenőrzések UTÁN írasd ki - előbb csekkold le, hogy a levél egyáltalán elment-e, majd attól függően írj ki bármit is.Pl. leellenőrizhetnéd az $smtp változót is, illetve a $sentmailt is:
magyar nyelvű doksi:
factory
sendA kommentek között meg van egy lehetséges példa hibaellenőrzésre:
To handle errors when sending mail use the following. Great for checking if the SMTP server accepted all the addresses.$send = $mail->send($to, $headers, $body);
if (PEAR::isError($send)) { print($send->getMessage());}===
Egyébként mi értelme van PHP-vel kiíratni itt a formot?
<?php
echo 'Ez egy teszt mail mert a * már * * * és remélem menni fog<br><br><br><br>';
echo '<form method="post">'
. 'Név: <input type="text" name="nev"><br>'
. 'Téma: <input type="text" name="theme"><br>'
. 'E-mail Címed: <input type="text" name="email"><br>'
. 'Üzeneted:<br> <textarea name="message" rows=5 cols="40">Ide írhatod az üzeneted!</textarea><br>'
. '<input type="submit" name="submit" value="küldés">'
. '</form>';
if(isset($_POST['submit'])) {
...HELYETT (!!) lehetne így:
Ez egy teszt mail mert a * már * * * és remélem menni fog<br><br><br><br>
<form method="post">
Név: <input type="text" name="nev" /><br>
Téma: <input type="text" name="theme" /><br>
E-mail Címed: <input type="text" name="email" /><br>
Üzeneted:<br> <textarea name="message" rows=5 cols="40">Ide írhatod az üzeneted!</textarea><br>
<input type="submit" name="submit" value="küldés" />
</form>
<?php
if(isset($_POST['submit'])) {
...Ami statikus rész, úgysem változik, azt felesleges PHP-val kiíratni.
De vegyíteni is lehet a kettőt:
<?php
if( !empty($tokmindegy) ) :
// itt jön a HTML-rész...
?>
<form method="post">
.........
</form>
<?php
// HTML-rész vége...
endif;
?> -
#8776
Sk8erPeter
nagyúr
cAby
#8772
Sk8erPeter
nagyúr
Az se rossz, de hogy az URL elmenthető és elküldhető legyen úgy, hogy azt megnyitva eleve növekvő sorrendben jelenjenek meg a dolgok, lehet, hogy ésszerűbb lenne azt is inkább GET metódussal átadni. De nehogy ez alapján tegyél bármit is közvetlenül a lekérdezésbe.
Inkább pl. így nézhet ki egy URL vége:
keres.php?page=2&asc=truePHP-ban pedig:
if( !empty($_GET['asc']) ){
// akkor növekvő sorrendben mutatja a találatokat
}Az empty függvény itt ellenőrzi a változó meglétét is (isset - tehát nem kapsz notice-t, ha a csekkolás után felhasználod a változót), meg azt, hogy az nem üres vagy hamis értékű-e.
-
#8769
Sk8erPeter
nagyúr
Peter Kiss
#8768
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8768
üzenetére
Mondjuk ezt most nem nagyon értem, miért is kerülő megoldás. Nálam amikor crash-elt, be is volt töltve az extension, és engedélyezve is volt, épp ezért crash-elt.
Ezzel legfeljebb azt kerülöd el, hogy amennyiben nincs engedélyezve, vakvágányra fusson. -
#8767
Sk8erPeter
nagyúr
biker
#8766
Sk8erPeter
nagyúr
Ja, hát még mindig van, amire a Flash vagy a Silverlight az üdvös megoldás, pl. tipikusan az ilyen 3D-s, "bejárom a szobát"-jellegű dolgokra.
De komplett honlapot építeni erre az számomra nem túl tetszetős. Ha vegyítve van, az már valamennyire okés.Amúgy a 3 hét alatti elkészítés igen korrekt idő... Akkor ott túl sok tökölésre nincs lehetőség.
-
#8765
Sk8erPeter
nagyúr
Peter Kiss
#8763
Sk8erPeter
nagyúr
válasz
Peter Kiss
#8763
üzenetére
Legutóbb én pont IIS-en + FastCGI PHP-vel próbáltam az APC-t, és hasonló eredménnyel - az oldalak állandóan crash-eltek.
(#8764) Speeedfire : ja, az open source-t mindenki láthatja, ez igaz. Ettől függetlenül saját kódba is bőven lehet tenni biztonsági réseket, és nincs "több szem többet lát"-alapon történő hibafelderítés, igaz, itt a bugokat valóban talán tovább tart felfedezni épp a rendszer ismeretlensége miatt.
-
#8762
Sk8erPeter
nagyúr
CSorBA
#8760
Sk8erPeter
nagyúr
"Drupalban nem vagyok annyira otthon, de úgy vélem, ha valamire nem jó a Joomla, akkor nem a Drupálhoz nyúlnék, hanem sajáthoz
Azt hiszem ezzel Te is így lehetsz."
Nem, mert én eleve a Drupallal kezdenék.
Na, de tulajdonképpen pont erre akartam kitérni, hogy manapság már nagyon megfontolnám, hogy érdemes-e belekezdeni saját rendszer megírásába - az esetek többségében nem biztos, hogy megéri beáldozni azt a rengeteg hasznos munkaórát, amit csak példaként azzal töltök, hogy egy szép fastruktúrát építsek a menürendszeremhez, hogy akár több egymásba ágyazható menüpontom is legyen. Persze ilyenkor jól jön, amikor az embernek van korábbról kódja, csak valahogy a saját kódjaimmal eleve úgy vagyok, hogy állandóan találok benne valami javítanivalót, így rengeteg időt eltöltök a kód felülvizsgálatával. Na mindegy, pl. egy ilyen eleve megvan egy CMS-ben, vagy akár egy framework is ezeket a feladatokat sokkal könnyebbé teszi. Most, hogy talán mondható, hogy eléggé belejöttem a Drupalhoz való modulfejlesztésbe, tényleg egyre kevésbé látom a határait, hogy hogyan oldjak meg dolgokat rugalmasan, egyre inkább híve vagyok annak, hogy komplett saját rendszer helyett érdemes felhasználni egy meglévőt, aminek a hibáit sokan felülvizsgálják, javítják, nem kell saját óriási erőforrásokat (pénz, idő, fáradság) szánnom erre a részre is.
Azt is megértem, hogy Te ragaszkodsz a Joomlához: miután az ember átesik azon a szakaszon, hogy "hű, de gyűlöllek, nem értek semmit, nem értem, ezt miért nem tudom elkészíteni, na akkor debuggoljunk megint több órát", majd sikerei vannak vele, és rájön a dolog hátterére, már egészen kezd hozzánőni a szívéhez.
Egyébként a CMS-ekkel készített, igazán igényes honlapok elkészítéséhez szerintem elengedhetetlen a PHP-ismeret: sokszor a számtalan modul felrakása, próbálgatása, majd a jobb füled bal kézzel, a tarkód mögül történő megvakarása helyett lehet, hogy a fejlesztői API segítségével csak néhány sort kell kódolnod a megfelelő helyen, és még erőforrás-takarékos is marad a dolog.Bocs, hogy ennyit ugatok a témáról, csak lököm, ami hirtelen eszembe jut.
Na meg még mindig érdekel a dolog, hogy ki mit gondol a CMS-ekről, és miért - főleg, ha negatív véleménnyel van róluk.===
(#8758) biker: jah, akkor jó.
Gondolom azért nem két perc volt összehozni, ahhoz túl igényes. Bár őszintén szólva fogalmam sincs a Flash-alapú fejlesztésről, hogy milyen segédeszközöket lehet hozzá felhasználni - valószínűleg nem is fogok tudni erről a témáról komolyabban semmit. Inkább a csillivilli dolgokhoz valami JS-alapú UI-t igyekszem használni, bár tudom, a Flash-eshez képest ez még mindig korlátosabb, vagy talán nehézkesebb. Bár attól függ, pl. az Ext JS elég komoly dolgokra képes.===
(#8759) Speeedfire :
"Lényeg, hogy érdemes cms-t használni/ismerni szerintem. Kisebb munkákhoz pikk-pakk, egyedi rendszerhez meg framework."
Na, épp ez az, amit felvetettem. Hogy egyedi igényekhez is bőven használható pl. egy Drupal. Ezt próbáltam megérteni, vajon mi az oka, hogy sokan ennyire ragaszkodnak ahhoz az állásponthoz, hogy egyedi és profi dolgokhoz márpedig csak egy framework jó.
Aztán persze lehet, hogy tényleg simán elképzelhető olyan honlap, aminél könnyebb összehozni framework segítségével, mint CMS-sel.===
(#8761) Athlon64+ : na igen... ez amúgy érdekes probléma. Kíváncsi lennék, Windows-on mi a workaround az APC helyes működtetésére.
-
#8757
Sk8erPeter
nagyúr
CSorBA
#8748
Sk8erPeter
nagyúr
Ja, látom ezt a template-et alkalmaztad.
Nekem a Joomla már akkor komolytalanná vált, amikor széjjeldobálta a fél éve legfrissebb verziója az oldalamat mindenféle PHP-s hibával, ami az E_STRICT bekapcsolása miatt történt - de nem kevéssel, hanem úgy minimum ötvennel, vagy többel. Egy sokak által használt CMS-nél ugyan figyeljenek már azokra az alapvető programozási technikákra, amikkel az ilyen hibadobálások elkerülhetők. Nem, az nem érv, hogy "dehát ne legyen E_STRICT" - de, fejlesztés alatt igenis legyen.
Aztán nekem személy szerint valahogy gyorsan elment a kedvem a Joomlától, nem láttam benne a potenciált, hogy annyira testreszabható lenne, mint a Drupal, hogy bizonyos felhasználók kezéből kivegyem az irányítást, és csak valami apró részletre adjak jogot, nem tartottam átláthatónak és következetesnek a kódját (ami fejlesztői szempontból - ha modulokat akarok írni, stb. - nem mindegy), és valahogy számomra összecsapottnak tűnt. Senki ne vegye sértésnek, aki Joomla-rajongó.
Megerősítve láttam azokat az érveket, amiket a Joomla ellen írtak különböző fórumokon.
Ahogy a Drupalt használtam, eleinte az is rettenetes káosz volt számomra, de már kezdetektől fogva úgy éreztem, hogy ez egy alapvetően egészen profi rendszer, csak még nem ismerem ki magam rajta - nem volt az az érzésem, mint Joomlánál, hogy mintha egy könnyen összedőlő kártyavárba akarnék berendezkedni (inkább mintha egy erődítménybe).
Nem akarok papolni a Drupal mellett, de számomra a Joomla emellett akkor is komolytalan marad.
Ettől függetlenül természetesen elhiszem, hogy egész jó honlapokat össze lehet benne hozni.Ja, és bocsánat, mielőtt elfelejtem: kollégámmal majdnem egyszerre kezdtünk fejleszteni két tök különböző oldalt, ő Joomlát használt, én Drupalt. Az ő oldalát nagy meglepetésünkre egyszer csak feltörték (valami török zene szólt egy iframe-ből az index.php cím alatt), az enyémet nem, és - lekopogom - eddig azóta sem törték fel. Lehet, hogy ebből nem feltétlenül szabad messzemenő következtetéseket levonni, de valahogy az volt az érzésem, hogy ez valamelyest utal az egyik vagy másik rendszer megbízhatóságára is.
Ahogy sok fórumon azt is olvastam, amikor még vacilláltam, melyik legyen, Joomla vagy Drupal, hogy állítólag a Joomla elég sok biztonsági rést tartalmaz(ott) - lehet, hogy ezeket azóta mind befoltozták, és lettek helyettük újak, nem tudom. Mindenesetre a régebbiek ezek szerint egész jól támadhatók.Azt nem tudom, Joomlához milyen tempóban jelennek meg security update-ek a felfedezést követően, de Drupalhoz nagyon gyorsan elkészítik, ha találnak biztonsági rést, így ez kellő prioritást élvez a fejlesztők munkájában - számomra ez is elég pozitív.
===
(#8749) biker : az már valamennyire közelít a rendes árhoz. Kár, hogy az egész oldal Flash-alapú, pedig jó lenne, de én ezekről az oldalakról valahogy ösztönösen menekülök...
===
(#8752) mobal: én fentebb egy kicsit fáradtan, de próbáltam elmondani a szempontjaimat, hátha érdekel ez a vélemény is a Joomla vs. Drupal témáról.
(#8754) mobal: "Hát nem tudom. Szerintem semmi gond nincs a Joomlával, semmi ilyet nem olvasok róla."
Pedig ezeket a véleményeket kb. 5 perc Guglizás alapján meg lehet találni, én is ugyanezeket olvastam, amikről Speeedfire beszél, pedig elején mindkettőre nyitott voltam.
Ahogy fentebb láthatod, ki is próbáltam mindkettőt, és végül saját tapasztalat alapján döntöttem. Választottam a nehezebbet, de profibbat.===
(#8753) Speeedfire :
ja, világos. Attól még, mert valaki össze tud dobálni mondjuk egy blogos oldalt Wordpress-ben, attól még tényleg nem ő lesz a webfejlesztők királya, ez tény. Amúgy értem, mit akarsz mondani, mintha a CMS-ek használatától valaki venné a bátorságot, hogy elmondhassa magáról, hogy ő profi weboldalakat tud készíteni, pedig az anyja vasporosát. "CSorBA: Mutatós oldal, bár nem értem a joomla-sokat, hogy miért nem szeretik használni az apache mod_rewrite modulját."
Tényleg, ezt én is megfigyeltem, hogy ez valahogy náluk rendszerint lemarad. (tisztelet a kivételnek) Drupal már a kezdetek kezdetén felajánlja, hogy ezt igazán bekapcsolhatnád, mert van rá mód (ha van). -
#8746
Sk8erPeter
nagyúr
CSorBA
#8743
Sk8erPeter
nagyúr
És mi ezzel a filozófiával a probléma? Úgy tűnt, mintha ezt negatív dolognak akarnád beállítani.
(#8744) Speeedfire : "4. Adjuk el pofátlanul drágán (a sz*rt)."
Ezt a hozzáállást megint nem értem. Miért kellene, hogy szar legyen?
Attól még, mert valaki ingyenes CMS-sel dolgozik, vesz hozzá egy igényes sablont, mert mondjuk nincs pénze külső, brutális pénzekért dolgozó dizájnerre, vagy csak simán talált egyet, ami neki megfelel, és aztán még módosítgatja az oldalt ízlésének és az igényeknek megfelelően, nem értem, miért kellene, hogy szar legyen egy weboldal!
Azt meg el kell fogadni, hogy ami jól néz ki, megfelel az igényeidnek, azt általában igenis meg kell fizetni.Tudod, mi a nevetséges? Amikor hozzánk bejött az irodába egyszer egy csávó, hogy ő 35 ezer Ft-ért (!!!) komplett ingatlanközvetítő portált akar összetett keresővel, admin-felülettel, képfeltöltési lehetőséggel, stb.
Azt hittem, eldobom az agyam... -
#8740
Sk8erPeter
nagyúr
Speeedfire
#8739
Sk8erPeter
nagyúr
válasz
Speeedfire
#8739
üzenetére
Persze, a frameworköknek is bőven megvan a létjogosultsága, ez nem is kérdés.
Csak az én kezdeti véleményemet befolyásolták fórumos hozzászólások is (nem feltétlenül itt, és most nem linkelek konkrétakat, mert honnan tudjam már, hol vannak azok), miszerint elsősorban kezdőknek valók a CMS-ek, ami ebben a formában baromság.
Arra lennék kíváncsi, hogy vajon mi az oka a CMS-ek degradálásának."Viszont itt van is egy kis hátulütője a dolognak. Sok zugweblapkészítő wp-t használ, de ha már kell valami extra dolog, akkor sírnak rínak a megrendelőnek, hogy ezt nem tudja kivitelezni."
Ez nem látom be, miért a CMS-ek hátulütője. Ez a zugweblapkészítő gyökérségét (finomabban: hozzá nem értését) igazolja, ez a szememben nem a CMS-ek "hátulütője". -
#8738
Sk8erPeter
nagyúr
Speeedfire
#8737
Sk8erPeter
nagyúr
válasz
Speeedfire
#8737
üzenetére
Igen, de az "inkább kezdőknek való" résszel már abszolúte nem értek egyet, pont azóta, mióta jobban belemerültem a Drupal-fejlesztésbe. Ahogy elnézem a Drupal-közösséget, ott is nagyon nagy számban fordulnak elő jó programozók, nem olyanok, akik tegnap kezdték. Tulajdonképpen most már nem látom be, hogy mitől lenne "profibb" mondjuk egy keretrendszerrel, a széles körű testreszabást lehetővé tévő grafikus admin-felület nélkül összehozni egy honlapot, mint egy CMS-sel. Drupal-modulfejlesztés sokszor bizonyos komplikáltabb feladatokat alaposabb PHP-ismeret nélkül egyszerűen lehetetlen összehozni. Viszont az egész "rendszer" átgondoltsága és a meglévő API-k miatt radikálisan redukálódik (ezt a két szót most muszáj volt egymás mellé raknom, annyira jól hangzik
) a fejlesztésre fordítandó idő. Nemrég már némi Drupal-tapasztalattal hoztam össze egy egyszerű, többnyelvű céges honlapot, egyszerűbb kódolásra is szükség volt, de nagyon gyorsan össze tudtam kalapálni. De komolyabb célokra is esélyes, hogy a Drupalt választanám. A jól megírt és szintén alaposan testreszabható jogosultsági rendszer (szinte a legapróbb részletekig beállítható, melyik felhasználónak mire van jogosultsága), valamint a cache-elési mechanizmusok, a security és egyéb update-ek gyors megszületése, valamint a mögötte álló nagy közösség is mellette szólnak.
Igazából a modulfejlesztés széleskörűsége miatt nem is nagyon látom a Drupal alatti fejlesztés korlátait, ami miatt feltétlenül át kellene térni inkább keretrendszerre - persze bizonyára vannak olyan feladatok, amik esetleg gyorsabban összehozhatók épp egy komolyabb frameworkkel, de akkor talán még mindig egálban van a kettő, mivel a Drupalnak ugye elég komoly grafikus alapú admin-felülete is van, meg a meglévő modulok miatt rengeteg megoldás már tálcán van kínálva a hivatalos honlapon.Az mondjuk lehetséges, hogy épp a nagy felhasználói bázis miatt talán több a kísérlet a rendszerek feltörésére. Bár tudtommal a biztonság kérdésében is egész jól helytáll (most hirtelen mondjuk nincs előttem erről szóló kimutatás).
Ezek miatt a szempontok miatt érdekelne, hogy ki miért tartja mondjuk kevesebbre a CMS-eket, miért gondolja úgy, hogy akkor is a framework a nyerő egy profi környezetben. (Bár gyorsan hozzáteszem, elég sok profi környezetben használják a Drupalt is.)
Itt nyilván elég sok szempont van, érdekelnének a különböző vélemények. -
#8736
Sk8erPeter
nagyúr
Tele von Zsinór
#8733
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#8733
üzenetére
köszi, ez a példa teljesen érthető.
Amúgy közben megnéztem a Wikipédiás, JavaScriptes példát is, az is teljesen világossá teszi, hogy tulajdonképpen mire is való az egész.Mostanában én a Drupalra és az ahhoz való modulírogatásra vagyok rákattanva, meg azonbelül is van template-ezés, szerintem nagyon jól átlátható.
Egyébként Ti hogy álltok a CMS-kérdéshez?
Régebben, amikor belecsöppentem az egészbe, és még nem sokat tudtam erről a témáról, fura módon azt gondoltam, a CMS-ek inkább kezdőbbeknek való, gyors honlap-összepakolásra. Amióta a Drupalt használom, rájöttem, hogy ennél sokkal komolyabb dologról van szó - nagyon komplex dolgokat is össze lehet hozni egyéni modulírással vagy mások moduljának felhasználásával, a modulírásba való beletanulás után egészen gyorsan, szóval nagyon ki van ez találva. Nektek mi a véleményetek ezekről? Ahogy elnézem, sokkal szívesebben használtok frameworköket, mint pl. bármilyen CMS-eket. -
#8735
Sk8erPeter
nagyúr
biker
#8731
Sk8erPeter
nagyúr
Hát nem tom, szerintem egy "jól" összezagyvált kódot visszafejteni úgy, hogy aztán sikerüljön értelmezni is, mi mit csinál, aztán megváltoztatni mindent úgy, hogy értelmes változó- és függvénynevek legyenek a kódban, ismét felkommentezni, hogy következő hozzányúláskor ne kelljen már megint hajadat tépni, hogy átlásd, nem egy egyszerű munka.
Nem tartom magam amatőrnek (ha az az állítás, hogy csak azok ellen véd), de nem szívesen vállalkoznék ilyenre...
Persze gondolom a query-ket meg stringeket nem lehet összezagyválni, úgyhogy az sokat segít.
Az ismerősöd meg lehet, hogy szintén nem szívesen vállalkozna egy visszafejtegetésre, vagy kis túlzással ennyi idő alatt már meg is írná inkább magától az egészet.
Aztán lehet, hogy vannak zsenijelöltek, akiknek mindez pikkpakk megy, most így hirtelen nehéz elképzelni, hogy lehet egy "jól" obfuszkált, más által megírt kódot visszafejteni, értelmezni, majd annyira belejönni, hogy máshol is alkalmazni tudd, mindezt normális idő alatt, hogy ne érezd úgy, hogy ezzel értékes, valós pénzt kínáló munkaórákat dobálsz ki az ablakon...Ettől függetlenül még mindig választhatod az API-t vagy web service-t, csak ezt is elég melós lehet megírni jól.
-
#8730
Sk8erPeter
nagyúr
mobal
#8725
Sk8erPeter
nagyúr
-
#8729
Sk8erPeter
nagyúr
biker
#8721
Sk8erPeter
nagyúr
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. -
#8728
Sk8erPeter
nagyúr
Tele von Zsinór
#8284
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?
-
#8283
Sk8erPeter
nagyúr
Brown ügynök
#8282
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. -
#8280
Sk8erPeter
nagyúr
Brown ügynök
#8278
Sk8erPeter
nagyúr
válasz
Brown ügynök
#8278
üzenetére
Milyen részoldalakra gondolsz?
Példa is jöhetne, hogy érthető legyen.(#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.
-
#8277
Sk8erPeter
nagyúr
Lacces
#8272
Sk8erPeter
nagyúr
"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.
"É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á.
-
#8264
Sk8erPeter
nagyúr
fazr
#8263
Sk8erPeter
nagyúr
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. -
#8251
Sk8erPeter
nagyúr
biker
#8247
Sk8erPeter
nagyúr
ú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. -
#8242
Sk8erPeter
nagyúr
Lacces
#8239
Sk8erPeter
nagyúr
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? 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. -
#8232
Sk8erPeter
nagyúr
coco2
#8231
Sk8erPeter
nagyúr
Szerintem nem veszekszünk, szakmai vita az nem veszekedés.
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.
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. (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.
-
#8228
Sk8erPeter
nagyúr
coco2
#8224
-
#8223
Sk8erPeter
nagyúr
Lacces
#8219
Sk8erPeter
nagyúr
"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? -
#8205
Sk8erPeter
nagyúr
M.Úr
#8204
Sk8erPeter
nagyúr
Nem, hanem a zzzinternet.
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. 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? (szerk.: tisztelet a kivételnek) -
#8198
Sk8erPeter
nagyúr
coco2
#8195
Sk8erPeter
nagyúr
"É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.
-
#8194
Sk8erPeter
nagyúr
Lacces
#8193
Sk8erPeter
nagyúr
-
#8175
Sk8erPeter
nagyúr
Bencom ™
#8173
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.
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. 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.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].
-
#8174
Sk8erPeter
nagyúr
coco2
#8172
Sk8erPeter
nagyúr
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. 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. 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. 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? Miért ne futhatna azokon a monstre szervergépeken, amikről éppen beszéltél? 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.
-
#8168
Sk8erPeter
nagyúr
Bencom ™
#8166
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?
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... -
#8167
Sk8erPeter
nagyúr
PazsitZ
#8162
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. 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.
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? É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? 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) -
#8138
Sk8erPeter
nagyúr
coco2
#8136
Sk8erPeter
nagyúr
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.
-
#8135
Sk8erPeter
nagyúr
CSorBA
#8122
Sk8erPeter
nagyúr
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? 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).
-
#8118
Sk8erPeter
nagyúr
Tele von Zsinór
#8117
Sk8erPeter
nagyúr
válasz
Tele von Zsinór
#8117
üzenetére
Akkor biztos szarul ért a PHP-hez.
Amúgy köszi a választ.
Webfejlesztgettem Ubuntu alatt is, érdekes módon nekem nem volt olyan problémám, hogy bugok miatt képtelen voltam használni a terminált... 
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Mintha ezt eddig nem tudtuk volna. 
Új hozzászólás Aktív témák
Hirdetés
- Milyen autót vegyek?
- Milyen légkondit a lakásba?
- HiFi műszaki szemmel - sztereó hangrendszerek
- Szombathely és környéke adok-veszek-beszélgetek
- Bluetooth hangszórók
- Óvodások homokozója
- AMD Ryzen 9 / 7 / 5 9***(X) "Zen 5" (AM5)
- Samsung Galaxy S22 és S22+ - a kis vagány meg a bátyja
- Motorolaj, hajtóműolaj, hűtőfolyadék, adalékok és szűrők topikja
- VoidXs: Tényleg minden játék optimalizálatlan?
- További aktív témák...
- ZBook Fury 16 G9 16" FHD+ IPS i7-12850HX RTX A2000 32GB 512GB NVMe magyar vbill ujjlolv IR kam gar
- AKCIÓ!!! GAMER PC: Új i5-14400F +RTX 4060/5060/4070/5070 +16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ!
- Elite Dragonfly G3 13.5" FHD+ IPS érintő i5-1235U 16GB 512GB NVMe ujjlolv gar
- Újszerű 17.3" FHD (1920x1080) IPS 40pin 144Hz matt LED kijelző. AUO B173HAN04.9
- Lenovo kezdő laptop (i3 6th, 500 GB, 4 GB) reklámáron! AkciÓÓ!
- Amazon Kindle 10th Generation ébresztős tok
- Samsung Galaxy A54 5G , 8/128 GB , Kártyafüggetlen
- LG 65C3 - 65" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
- AKCIÓ! "ÚJ" Microsoft Surface 5 13,5 notebook - i5 1235U 8GB RAM 256GB SSD Intel Iris Xe IGP 27% áfa
- Honor Pad X8 64GB, Wi-Fi, 1 Év Garanciával
Állásajánlatok
Cég: Promenade Publishing House Kft.
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest