Szerző Téma: mt_rand() példaprogram  (Megtekintve 3720 alkalommal)

mt_rand() példaprogram
« Dátum: 2015. augusztus 25. - 12:47:26 »
0 Show voters
Sziasztok! Ez egy példascript arra, hogy hogyan is lehet használni a PHP (egyik) randomszámot generáló függvényét, ami nem más, mint az <b>mt_rand()</b>. Találtam még egyet, ami ugyanezt a kimenetet eredményezi. Ennek a neve rand(). A scriptet date() függvénnyel egészítettem ki, ami kiírja a számítás időpontját akkor, ha a generálás gombra nyomtál. Egy kicsike hiba van benne, amit nem tudok ezzel a módszerrel megoldani, mégpedig az, hogy ha nincs értéke az űrlapoknak, akkor kiírja a 0-t is, és az \"Üres mező(k)\" kimenetet is, de csak abban az esetben, ha a linken frissítesz az oldalra. Ezt egy másfajta módszerrel sikerült korrigálnom, de nem jöttem rá, hogy így hogyan lehetséges  :crybaby:
 

<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">
<html>
<head>
<title>Randomszám generátor</title>
<meta http-equiv=\"content-type\" content=\"text/html;charset=utf-8\" />
</head>
<body>
<center>
 
<form method=\"post\" action=\"\" />
<center>
 
<h1>Írd be, hogy melyik két szám között generáljon random számot!</h1>
<input type=\"text\" name=\"rand\" value=\"\" /> <input type=\"text\" name=\"rand2\" value=\"\" />
<br />
<br />
<input type=\"submit\" value=\"Generál!\" />
</form>
<br />
<br />
<?php
$randomszam1 = $_POST[\"rand\"];
$randomszam2 = $_POST[\"rand2\"];
echo \"Randomszám: \" . \"<b>\" . mt_rand ( $randomszam1, $randomszam2 ) . \"</b>\";
if ( $randomszam1 == NULL || $randomszam2 == NULL )
{
   echo \" <b> Üres mező(k)!</b>\" . \"<br />\";
                        break;
}
echo \"<br />\" . \"Számítás időpontja: <b>\" . date( \"Y \" ) . date ( \"M \" ) . date ( \"d\" ) . \"<br />\";
?>
</body>
</html>

 
Lényeg: Létrehoztam egy űrlapot, ami egy integert (számot) vár. Ha stringet (leegyszerűsítve: betűt), vagy bármi mást (boolt, double értéket (másnéven float értéket)) írsz be, akkor nem ír ki semmit (igen, ebből látszik, hogy a PHP tudásom még nincs az egekben). A $_POST[\"rand\"] és $_POST[\"rand2\"] változókat a $randomszam1 és $randomszam2 változók kezelik. Az mt_rand() függvény megvizsgálja a két változó értékét, és aszerint generál egy random számot. Ezt a randomszámot íratjuk ki az echo() függvény segítségével. Az if else elágazás if ágával megvizsgáljuk, hogy a két változó kezel-e értéket, (vagyis írtunk-e valamit a két űrlapba, vagy sem). Ha írtunk, akkor a porgram nem foglalkozik az if ág további részeivel, hanem átugrik az alatta lévő echo függvényre, ami kiírja az aktuális dátumot. Ha viszont nincs értéke valamelyik (vagy mindkét) űrlapnak, akkor kiírja, hogy \"Üres mező(k)!\", és a break utasítás miatt a program az utána következő tartalmat, (vagyis az aktuális dátumot) már nem jeleníti meg.
FONTOS: A kisebb számot kell előre írni, a nagyobb számot pedig az utána következő űrlapba!
« Utoljára szerkesztve: 2015. augusztus 25. - 12:51:54 írta ReSIk »

Nem elérhető Szilard

  • Adminisztrátor
  • 1832
    • Profil megtekintése
mt_rand() példaprogram
« Válasz #1 Dátum: 2015. augusztus 25. - 13:03:50 »
0 Show voters
Idézetet írta: ReSIk date=1440499646\" data-ipsquote-contentapp=\"forums\" data-ipsquote-contenttype=\"forums\" data-ipsquote-contentid=\"57445\" data-ipsquote-contentclass=\"forums_Topic
Egy kicsike hiba van benne, amit nem tudok ezzel a módszerrel megoldani, mégpedig az, hogy ha nincs értéke az űrlapoknak, akkor kiírja a 0-t is, és az \"Üres mező(k)\" kimenetet is, de csak abban az esetben, ha a linken frissítesz az oldalra. Ezt egy másfajta módszerrel sikerült korrigálnom, de nem jöttem rá, hogy így hogyan lehetséges  :crybaby:
 



 

<!DOCTYPE html PUBLIC \"-//W3C//DTD XHTML 1.0 Strict//EN\" \"http://www.w3.org/TR/xhtml1/DTD/xhtml1-strict.dtd\">
<html>
<head>
<title>Randomszám generátor</title>
<meta http-equiv=\"content-type\" content=\"text/html;charset=utf-8\" />
</head>
<body>
<center>
 
<form method=\"post\" action=\"\" />
<center>
 
<h1>Írd be, hogy melyik két szám között generáljon random számot!</h1>
<input type=\"text\" name=\"rand\" value=\"\" /> <input type=\"text\" name=\"rand2\" value=\"\" />
<br />
<br />
<input type=\"submit\" value=\"Generál!\" />
</form>
<br />
<br />
<?php
if(ctype_alnum($_POST[\'rand\']) && ctype_alnum($_POST[\'rand2\') && !empty($_POST[\'rand\']) && !empty($_POST[\'rand2\'])) {
echo \"Randomszám: \" . \"<b>\" . mt_rand ($_POST[\'rand\'], $_POST[\'rand2\']) . \"</b>\";
echo \"<br />\" . \"Számítás időpontja: <b>\" . date( \"Y \" ) . date ( \"M \" ) . date ( \"d\" ) . \"<br />\";
}
?>
</body>
</html>

 
 
[admin]A jövőben kérlek kerüld az olyan scriptek publikálását, ami a kezdőknek (és senki másnak sem) segít, ha kérdésed van, azt a Kérdések / Segítség részleghez nyisd.[/admin]
« Utoljára szerkesztve: 2015. augusztus 25. - 13:05:58 írta Szilard »

Nem elérhető krisk

  • 2380
    • Profil megtekintése
mt_rand() példaprogram
« Válasz #2 Dátum: 2015. augusztus 25. - 20:01:33 »
+1 Show voters

A jövőben kérlek kerüld az olyan scriptek publikálását, ami a kezdőknek (és senki másnak sem) segít, ha kérdésed van, azt a Kérdések / Segítség részleghez nyisd.
 
[/quote]
Plusz még maga a leírás sem helytálló, mert az mt_rand() nem ugyanaz, mint a rand(). Az mt_rand() egy másik algoritmust használ (Mersenne Twister), a rand() pedig (elvileg) azt a PRNG-t használja, ami abban a C standard könyvtárban van, amivel fordították a php-t, ami vagy egy sima lineáris kongrugencia generátor, vagy egy trinomiális PRNG, legalább is ezek vannak a glibc-ben. Vagy valami tök más, elvégre ez PHP, aminek a standard könyvtára úgy el van bäszva, hogy kegyetlen (ld. még ezt.)
Ja, és ráadásul ezek egyike sem kriptográfiailag biztos, arra ott van a random_int(). Hogy miért van legalább 3 függvény ami kb. ugyanazt csinálja? Hát mert PHP.
Ha most kezdted a PHP-t, inkább kezdj neki valami másik platformnak, sok munkát megspórolhatsz magadnak.
« Utoljára szerkesztve: 2015. augusztus 25. - 20:03:37 írta Reynolds »

Nem elérhető Pedró

  • 3341
  • 2014 © Az év Szkriptere
    • Profil megtekintése
mt_rand() példaprogram
« Válasz #3 Dátum: 2015. augusztus 25. - 20:45:29 »
0 Show voters
Miféle más platformra gondolsz Reynoldok?

Nem elérhető krisk

  • 2380
    • Profil megtekintése
mt_rand() példaprogram
« Válasz #4 Dátum: 2015. augusztus 25. - 21:26:02 »
+1 Show voters
Idézetet írta: Pedró date=1440528329\" data-ipsquote-contentapp=\"forums\" data-ipsquote-contenttype=\"forums\" data-ipsquote-contentid=\"57445\" data-ipsquote-contentclass=\"forums_Topic
Miféle más platformra gondolsz Reynoldok?
 
Van egy csomó webszerver ami Python vagy Perl alapú, amik sokkal jobbak, mivel igazi programnyelvek, plusz az MVC (Model-View-Controller) paradigmát használják az összegányolt \"rakjnuk egy kis PHP-t meg egy kis javascriptet egy HTML kódba\" helyett. Lényegében a kód és a megjelenítési mód el van szigetelve, hasonlóan, ahogyan pl. egyre jobban azt mondják, hogy egy markup nyelv (pl. HTML) ne szóljon bele, hogy hogy jelenítődik meg az oldal (CSS).
Ez sok szempontból előnyös, mert így nincsenek problémák azzal, hogy a kódbázis az maga a tartalom, így pl. őrzőket kell rakni minden include-ba, hogy egyenként ne lehessen őket lefuttatni, stb. Problémás ez még akkor, ha valamilyen verziókezelő rendszert is használsz (git, svn, stb.) mert a rejtett mappáik (.git, .svn) elérhetőek alapjáraton ha Apache-t használsz (márpedig azt használsz, ha PHP-t is használsz).
Hasonlóan pl. el lehet különíteni a webalkalmazást és a szervert magát, így könnyen tudsz pl. webszervert váltani anélkül, hogy magát az alkalmazást újra kéne írnod.
Pytonra a Pylons-al van tapasztalatom, azt tudnám javasolni alternatívaként.

mt_rand() példaprogram
« Válasz #5 Dátum: 2015. augusztus 31. - 15:11:39 »
+5 Show voters
Idézetet írta: Reynolds date=1440530762\" data-ipsquote-contentapp=\"forums\" data-ipsquote-contenttype=\"forums\" data-ipsquote-contentid=\"57445\" data-ipsquote-contentclass=\"forums_Topic


Miféle más platformra gondolsz Reynoldok?
 
Van egy csomó webszerver ami Python vagy Perl alapú, amik sokkal jobbak, mivel igazi programnyelvek, plusz az MVC (Model-View-Controller) paradigmát használják az összegányolt \"rakjnuk egy kis PHP-t meg egy kis javascriptet egy HTML kódba\" helyett. Lényegében a kód és a megjelenítési mód el van szigetelve, hasonlóan, ahogyan pl. egyre jobban azt mondják, hogy egy markup nyelv (pl. HTML) ne szóljon bele, hogy hogy jelenítődik meg az oldal (CSS).
Ez sok szempontból előnyös, mert így nincsenek problémák azzal, hogy a kódbázis az maga a tartalom, így pl. őrzőket kell rakni minden include-ba, hogy egyenként ne lehessen őket lefuttatni, stb. Problémás ez még akkor, ha valamilyen verziókezelő rendszert is használsz (git, svn, stb.) mert a rejtett mappáik (.git, .svn) elérhetőek alapjáraton ha Apache-t használsz (márpedig azt használsz, ha PHP-t is használsz).
Hasonlóan pl. el lehet különíteni a webalkalmazást és a szervert magát, így könnyen tudsz pl. webszervert váltani anélkül, hogy magát az alkalmazást újra kéne írnod.
Pytonra a Pylons-al van tapasztalatom, azt tudnám javasolni alternatívaként.
 
[/quote]
Az a probléma hogy tájékozatlan vagy, és ezért butaságokat beszélsz.
Én amikor utoljára láttam, a php még mindig a világháló weboldalainak ~70%-át működteti, 2015-ben is.
Ez szerinted miért van?
\"mivel igazi programnyelvek\" -> Ezzel azt mondod, hogy a weboldalak ~70%-át, köztük a Facebookot, Wikipédiát,
vagy hogy fiatalabb start-upokat is említsek, a MailChimpet
és még számtalan más fontos piaci szereplőt egy nem igazi programnyelvben írták meg? Nyilván ez ugyan olyan mintha
paintben rajzolták volna meg azokat a weblapokat nem?
Ne érts félre, a php valóban nem egy jól felépített nyelv.
Viszont ha kicsit utánaolvasol annak hogy mi is a php, hogyan jött létre, akkor azért nem nehéz látni ennek a miértjét.
A php-t nem pontról pontra tervezve építették fel egy jó design alapján. A php felnőtt. Maga a nyelv eredeti készítője
sosem egy komplett programozási nyelvet akart készíteni.
Gyorsan és hatékonyan akart weboldalakat készíteni egy-két segéd makróval.
Ennyi, a php viszont népszerű lett, pont azért, mert gyorsan és hatékonyan lehet benne weboldalakat készíteni.
A közösség nagyon erős szerepet vállal a nyelv fejlesztésében, tehát a helyzet nyilván nem is hasonlítható mondjuk egy C#-éhoz,
ahol a Microsoft szakemberei folyamatosan teljes munkaidőben dolgoznak a nyelven a legelejétől.
A php felnőtt, kifejlődött, fontos látni hogy ez sokkal inkább hasonlít egy evolúciós folyamatra mint egy jól megtervezett ösvényre.
Tehát, lehet mondani hogy a php rettenetesen van tervezve? Igen. Lehet mondani rá hogy ez nem egy igazi programozási nyelv? Nem.
( Pontosabban lehet, csak az álszentség )
Az \"MVC paradigmát\" (becsületes neve szerkezeti minta) használó eszmefuttatásod tökéletesen bizonyítja hogy az ég világon semmit
nem tudsz a php-ról, elolvastál két blogpostot és talán ki is próbáltad, de ennyi, látszik a mélyebb tudás teljes hiánya.
Az MVC pattern használható php alatt is. De ez nagyon lealacsonyítóan hangzik, tekintve hogy a komoly php alkalmazások nagy része
használja ezt a design patternt, sok mással együtt. Mert vannak ám mások is, tulajdonképpen szinte az összes ami az ún. \"valódi programnyelveidben\" is megtalálható.
Meglepetés: https://github.com/domnikl/DesignPatternsPHP
Az a probléma hogy valószínűleg a legkomolyabb php kód amit eddig láttál a szomszéd kisfiúé volt, ott népszerű a
\"rakjnuk egy kis PHP-t meg egy kis javascriptet egy HTML kódba\" felállás, de lennél szíves nem egyből feltételezni hogy a világon
mindenhol máshol is ez a legnagyobb szint amire eljut egy php programozó?
 
Ez sok szempontból előnyös, mert így nincsenek problémák azzal, hogy a kódbázis az maga a tartalom[/quote]
Ez szimplán nem igaz semmilyen komoly rendszernél.
 
így pl. őrzőket kell rakni minden include-ba, hogy egyenként ne lehessen őket lefuttatni, stb[/quote]
 

\"6a22ec1372350bb64757502d070d8492.jpg\"
 
Te hallottál már a Front Controller nevű szerkezeti mintáról?
 
Problémás ez még akkor, ha valamilyen verziókezelő rendszert is használsz (git, svn, stb.) mert a rejtett mappáik (.git, .svn) elérhetőek alapjáraton ha Apache-t használsz (márpedig azt használsz, ha PHP-t is használsz).[/quote]
Ez is szimplán nem igaz. Valójában az egész eszmefuttatás elbukik ott hogy \"márpedig azt használsz [apachot], ha PHP-t is használsz\".
Én php-t használok, de Apache-ot nem.
De régebben használtam Apache-ot ÉS git verziókövetőt együtt, és alapjáraton nem voltak elérhetőek a rejtett git mappák.
Egyszerűen nem voltak elérhetőek a netről. Pedig nem tiltottam le külön. (Front Controller)
De amúgy letiltani Apache verziótól függően 3-5 plusz sorba kerül.
 
Hasonlóan pl. el lehet különíteni a webalkalmazást és a szervert magát, így könnyen tudsz pl. webszervert váltani anélkül, hogy magát az alkalmazást újra kéne írnod.
[/quote]
Ez php-ra is teljesen igaz. Sőt, sok esetben még az is mindegy hogy Windows vagy Linux alapú a szerver.
Igazából nem tudom hogy milyen php kódra gondoltad azt, hogy ennyire nem változás tűrő.
Én mint mondtam régen Apache hajtotta az alkalmazásainkat, most már más webszervert használunk, de az átállás miatt egyetlen
sornyi kódot sem kellett átírnunk. És egyetlen perci kimaradás sem volt a kiszolgálásban.
UI.: Ezt nem ellened írtam, csak szimplán nem tartom megalapozottnak a hozzászólásod a php-ról.

Nem elérhető krisk

  • 2380
    • Profil megtekintése
mt_rand() példaprogram
« Válasz #6 Dátum: 2015. augusztus 31. - 17:28:34 »
+3 Show voters
Idézetet írta: ChuckNorris date=1441026699\" data-ipsquote-contentapp=\"forums\" data-ipsquote-contenttype=\"forums\" data-ipsquote-contentid=\"57445\" data-ipsquote-contentclass=\"forums_Topic
Az a probléma hogy tájékozatlan vagy, és ezért butaságokat beszélsz.
Én amikor utoljára láttam, a php még mindig a világháló weboldalainak ~70%-át működteti, 2015-ben is.
Ez szerinted miért van?
 
Ez az oldal, mint az összes többi, nem konkluzív több okból sem, a legfontosabb talán az, hogy a Server headerben mindig benne van a mod_php ha létező Apache plugin, függetlenül attól, hogy használva-e van az adott oldal megjelenítésében, vagy sem. Szóval ez nagyjából azt mondja, hogy a weboldalak 70%-a mod_php pluginos Apache-n fut.
Plusz ez az adat nem releváns, az hogy sok ember használ olyan fórum/blogmotorokat, amiket egyszer felraknak és utána sosem nyúlnak hozzá, nem jelenti azt, hogy a PHP-t könnyű lenne fejleszteni, karbantartani vagy skálázni.
Ezen kívül az is kérdéses, hogy mennyi kód íródik PHP-ben, mert az, hogy sok ember használja a nyelvet nem jelenti feltétlen azt, hogy jól, biztonságosan vagy más módszerrel nézve optimálisan használják azt. És ez valószínűleg így is van, azért, amit be is vallottál.
 

\"mivel igazi programnyelvek\" -> Ezzel azt mondod, hogy a weboldalak ~70%-át, köztük a Facebookot, Wikipédiát,
vagy hogy fiatalabb start-upokat is említsek, a MailChimpet
és még számtalan más fontos piaci szereplőt egy nem igazi programnyelvben írták meg? Nyilván ez ugyan olyan mintha
paintben rajzolták volna meg azokat a weblapokat nem?
 
[/quote]
Addig, amíg vannak olyan emberek, akik meg tudnak bírkózni a programnyelv hiányosságaival, addig egyik programozási nyelv sem \"rossz\". Ez az adatpont sem lényeges, az, hogy hány weboldal használja nem jelent semmit, lehet, hogyha PHP helyett Whitespace-ben írták volna meg, akkor felével csökkent volna a fejlesztési idő.
Plusz a Facebook backendjét nem a PHP hajtja, hanem C alapú (ami megint nem egy abszolút tökéletes megoldás véleményem szerint, de ha a facebooknál ez működik, akkor én nem fogok beleszólni).
 

Ne érts félre, a php valóban nem egy jól felépített nyelv.
Viszont ha kicsit utánaolvasol annak hogy mi is a php, hogyan jött létre, akkor azért nem nehéz látni ennek a miértjét.
A php-t nem pontról pontra tervezve építették fel egy jó design alapján. A php felnőtt. Maga a nyelv eredeti készítője
sosem egy komplett programozási nyelvet akart készíteni.
Gyorsan és hatékonyan akart weboldalakat készíteni egy-két segéd makróval.
Ennyi, a php viszont népszerű lett, pont azért, mert gyorsan és hatékonyan lehet benne weboldalakat készíteni.
A közösség nagyon erős szerepet vállal a nyelv fejlesztésében, tehát a helyzet nyilván nem is hasonlítható mondjuk egy C#-éhoz,
ahol a Microsoft szakemberei folyamatosan teljes munkaidőben dolgoznak a nyelven a legelejétől.
A php felnőtt, kifejlődött, fontos látni hogy ez sokkal inkább hasonlít egy evolúciós folyamatra mint egy jól megtervezett ösvényre.
 
[/quote]
Tisztában vagyok a PHP történelmével, nagyon alap szinten. Értem, mit mondasz. De nem különösebben érdekel, mert lényegtelen a beszélgetés tartalmára nézve.
Az, hogy gyorsan lehet weboldalakat készíteni, az oké. Az, hogy hatékonyan lehet vele jó weboldalakat készíteni készíteni, az is oké. Az, hogy a készítmény hosszútávon, más programnyelvekhez/stackekhez képest fenntarthatóan kezelhető, azt is talán lenyelem. De hogy ezek közül az összeset egyszerre meg lehet valósítani anélkül, hogy az egyik tulajdonság semmissé váljon, abban biztos vagyok.
Az evolúciós folyamatod nagyon jó analógia, csak az a baj, hogy az embernek is megvan még a vakbele, meg a kislábujja, meg egyéb dolgok, amik semmiben nem segítik a fajunk fennmaradását, csupán felesleges dolgok, amik a bajt okozzák. Van rengeteg következetlenség is benne, ami nem segíti a biológusok meg a fiziológusok munkáját. Nyilván lehet PHP-ban is programozni, de a kérdés az, hogy akarsz-e.
 

Tehát, lehet mondani hogy a php rettenetesen van tervezve? Igen. Lehet mondani rá hogy ez nem egy igazi programozási nyelv? Nem.
( Pontosabban lehet, csak az álszentség )
 
[/quote]
Attól függ, mit tekintünk programozási nyelvnek. Ha egy Turing-teljes nyelvet programozási nyelvnek nevezünk, akkor nyilván lehet PHP-t annak hívni. De akkor a Brainfuck is programozási nyelv, meg az ASM is. Lehet benne játékokat írni? Lehet, meg is tették az NES-en. Érdemes írni benne játékokat? Nem igazán. A Brainfuck egy programozási nyelv? Igen. Akarsz benne írni egy magas szintű GUI-kezelő rendszert? Hát, maximum ha mazohista fétised van.
 

Az \"MVC paradigmát\" (becsületes neve szerkezeti minta) használó eszmefuttatásod tökéletesen bizonyítja hogy az ég világon semmit
nem tudsz a php-ról, elolvastál két blogpostot és talán ki is próbáltad, de ennyi, látszik a mélyebb tudás teljes hiánya.
Az MVC pattern használható php alatt is. De ez nagyon lealacsonyítóan hangzik, tekintve hogy a komoly php alkalmazások nagy része
használja ezt a design patternt, sok mással együtt. Mert vannak ám mások is, tulajdonképpen szinte az összes ami az ún. \"valódi programnyelveidben\" is megtalálható.
Meglepetés: https://github.com/domnikl/DesignPatternsPHP
 
[/quote]
Tudom, hogy lehet benne használni, de itt megint csak arról van szó, hogy a PHP-val sokkal könnyebb a rossz dolgot csinálni, mint a jó dolgot. Egy Pylons vagy egy akármelyik másik stack megköveteli, hogy ezt csináljad. A PHP, ami lényegében egy összetákolt CGI wrapper, vidáman fog műkdöni az MVC nélkül is.

Dupla hozzászólás automatikusan összefûzve. ( [time]2015. augusztus 31. 17:34:08[/time] )

Ez alatt az alábbit értem: Ha valaki egy hosszú távú projektet kezd el, amiben sok karbantartás és skálázás lesz, használhat Pythont, Railst vagy akármi mást, amiben be van építve az MVC, mint PHP-t egy MVC könyvtárral. Ellentétben ha valaki kezdő PHP-ben és csak most kezdte el az egészet, nem fog ezzel törődni és bele fog égni az agyába a rossz módszer. A PHP-ban sokkal könnyebb rossz kódot írni, mint jó kódot, ilyen egyszerű a probléma.
 

Az a probléma hogy valószínűleg a legkomolyabb php kód amit eddig láttál a szomszéd kisfiúé volt, ott népszerű a
\"rakjnuk egy kis PHP-t meg egy kis javascriptet egy HTML kódba\" felállás, de lennél szíves nem egyből feltételezni hogy a világon
mindenhol máshol is ez a legnagyobb szint amire eljut egy php programozó?
 
[/quote]
Lásd fentebb. Nyilván egy WordPress vagy egy phpBB nem ilyen elven működik, ezt nem is feltételeztem vagy írtam. De Pista is tudna olyan kódot írni, ami biztonságosabb, stabilabb, jobban karbantartható és skálzható, mint a gányolmány, amiről beszélünk, ha egy olyan rendszert használna, ami megkövetelné ezt a modellt.
 

 
Ez sok szempontból előnyös, mert így nincsenek problémák azzal, hogy a kódbázis az maga a tartalom[/quote]
Ez szimplán nem igaz semmilyen komoly rendszernél.
 
[/quote]
Dehogynem, láttam már olyat, hogy a weboldalt a .git mappával együtt töltötték fel. Ismét, nem a komoly rendszerekről van szó. Meg lehet úgy csinálni, hogy ne legyen szar, de nem lenne jobb, ha már eleve a jó megvalósítási módszert vésné a fejedbe a programnyelv?
 

 
így pl. őrzőket kell rakni minden include-ba, hogy egyenként ne lehessen őket lefuttatni, stb[/quote]
 

\"6a22ec1372350bb64757502d070d8492.jpg\"
 

[/quote]
A konfigurációs fájlok direkt betöltését megakadályozva muszáj őrzőket használni (mint a C-s #define _INCLUDE.INC_INCLUDED #ifdef ...), hogy megakadályozzuk, hogy valaki a nem megjelenítésre szolgáló állományokat direkt betöltse.
 

 
Problémás ez még akkor, ha valamilyen verziókezelő rendszert is használsz (git, svn, stb.) mert a rejtett mappáik (.git, .svn) elérhetőek alapjáraton ha Apache-t használsz (márpedig azt használsz, ha PHP-t is használsz).[/quote]
Ez is szimplán nem igaz. Valójában az egész eszmefuttatás elbukik ott hogy \"márpedig azt használsz [apachot], ha PHP-t is használsz\".
Én php-t használok, de Apache-ot nem.
 
[/quote]
Akkor te vagy az egyik szernecsés ember. Amúgy ha nem az Apache+MySQL+PHP kombót használod, akkor egy rails app deployment kb. ugyanannyi időbe telik, mint egy PHP deployment, szóval akkor már egyből nem olyan könnyen valósítható meg a dolog, mint gondolnád.
 

De régebben használtam Apache-ot ÉS git verziókövetőt együtt, és alapjáraton nem voltak elérhetőek a rejtett git mappák.
Egyszerűen nem voltak elérhetőek a netről. Pedig nem tiltottam le külön. (Front Controller)
De amúgy letiltani Apache verziótól függően 3-5 plusz sorba kerül.
 
[/quote]
Ami plusz munka, amit az átlag PHP programozó nem fog megtenni, mert ő \"gyorsan és hatékonyan\" akar weboldalt csinálni, nem az Apache konfig fájllal szarakodni.
 

 
Hasonlóan pl. el lehet különíteni a webalkalmazást és a szervert magát, így könnyen tudsz pl. webszervert váltani anélkül, hogy magát az alkalmazást újra kéne írnod.
[/quote]
Ez php-ra is teljesen igaz. Sőt, sok esetben még az is mindegy hogy Windows vagy Linux alapú a szerver.
Igazából nem tudom hogy milyen php kódra gondoltad azt, hogy ennyire nem változás tűrő.
Én mint mondtam régen Apache hajtotta az alkalmazásainkat, most már más webszervert használunk, de az átállás miatt egyetlen
sornyi kódot sem kellett átírnunk. És egyetlen perci kimaradás sem volt a kiszolgálásban.
 
[/quote]
Nem mondtam, hogy a PHP-nál nem lehet ezt megoldani, csak megjegyeztem, hogy a legtöbb framework (pl. Pylons) nem jön külön webszerverrel.


Minden megvalósítható minden programozási nyelvvel, azért programozási nyelv. Amit meg lehet írni PHP-ban, azt meg lehet írni Brainfuckban meg C-ben is, de nem mindegy, hogy milyen projekthez milyen eszközt választasz. A PHP kb. semmilyen weboldalhoz nem optimális, kis projekteknél kezdő programozóknál nem nyújt megfelelő biztonságos és rosszan felépített kódhoz vezet, nagyobb projekteknél pedig sokkal könnyebben, hatékonyabban, és skálázhatóbban lehet kódot fejleszteni más nyelvekben.
Maga a probléma nem a PHP-val van, hanem a közösséggel és a fejlesztői társadalommal. Kezdő programozóknak lett írva, nem profi fejlesztőknek, de a kezdőknek nem nyújt megfelelő védelmet. A legtöbb embernek fogalma sincs, miért rossz a PHP, miért nem jó összegányolni a tartalmat az appal és hogy vannak más, jobb alternatívák. Ezzel a programozók 90%-a bekerül egy olyan ördögi körbe, amiből nagyon nehéz kimászni.

Dupla hozzászólás automatikusan összefûzve. ( 2015. augusztus 31. - 17:46:23 )

Hogy ezt bemutassam, lássuk, mi a top 10 legfontosabb kérdés a Stack Overflow-on a php taggel:
 

  • How can I prevent SQL-injection in PHP? - ezt a mysqli úgy, ahogy megoldotta, de ha más adatbáziskezelőt használsz, akkor semmit nem ér.


  • Reference - What does this symbol mean in PHP? - minden szintaxis kb. benne van ebben a posztban, mellette posztokkal amik elmagyarázzák. Ezt nem a dokumentációnak kellene?


  • Why shouldn\'t I use mysql_* functions in PHP? - biztonsági kérdés, mert a mysql api még mindig bent van és vígan lehet használni, szóval az első kérdés igen is aktuális még most is.


  • How should I ethically approach user password storage for later plaintext retrieval? - ismét biztonsági kérdés, hogy oldjam meg, hogy ne tudják ellopni a jelszavakat de azért tudjak jelszóemlékeztetőt is küldeni.


  • How \'foreach\' actually works - érthetetlen szintaxis, amit SO-n kell elmagyarázni, a doksi helyett.


  • How to fix “Headers already sent” error in PHP - egy elbaszott PHP feature, amiben a PHP tagek előtti whitespace beleszámít a szövegbe és felülírja a HTTP fejlécet, amit akarsz küldeni.


  • How do you use bcrypt for hashing passwords in PHP? - biztonsági kérdés, az ötszáz közül épp melyik hashelő algoritmus a legjobb a jelszavak tárolásához.


  • Secure hash and salt for PHP passwords - hogy lehet jelszót tárolni és sózni, külön pont az MD5-ös lehetőség megemlítéséért. lol.


Mindezekből én azt szűröm le, hogy a felhasználók 90%-ának fogalma sincs, hogy hogy működik a nyelv, amiben programoznak, és akik értik, azok se tudják, hogy hogy lehet biztonságossá tenni az alkalmazásaikat.
« Utoljára szerkesztve: 2015. augusztus 31. - 17:46:23 írta Reynolds »

mt_rand() példaprogram
« Válasz #7 Dátum: 2015. augusztus 31. - 20:54:07 »
+3 Show voters
Idézetet írta: Reynolds date=1441034914\" data-ipsquote-contentapp=\"forums\" data-ipsquote-contenttype=\"forums\" data-ipsquote-contentid=\"57445\" data-ipsquote-contentclass=\"forums_Topic


Az a probléma hogy tájékozatlan vagy, és ezért butaságokat beszélsz.
Én amikor utoljára láttam, a php még mindig a világháló weboldalainak ~70%-át működteti, 2015-ben is.
Ez szerinted miért van?
 
Ez az oldal, mint az összes többi, nem konkluzív több okból sem, a legfontosabb talán az, hogy a Server headerben mindig benne van a mod_php ha létező Apache plugin, függetlenül attól, hogy használva-e van az adott oldal megjelenítésében, vagy sem. Szóval ez nagyjából azt mondja, hogy a weboldalak 70%-a mod_php pluginos Apache-n fut.
 
[/quote]
Ha azt mondod hogy a forrás nem konkluzív több okból sem, és aztán adsz egy okot, akkor egy fair vitában csak azt az egy okot veszik figyelembe.
A mod_php egy harmadik féltől származó plugin. Ez azt jelenti hogyha feltelepítesz egy sima apacheot akkor abban nem lesz mod_php.
Azt akarattal kell feltelepíteni.
Másrészt, az a \"mod_php header\" lehet hogy csak az általam megvizsgált weblapoknál nem volt jelen, de igazából nem számít, mert te azt állítottad hogy \"mindig jelen van\". Íme egy mod_php-s apache2 head válasza:
 

Array
(
    [Host] => localhost
    [user-Agent] => Mozilla/5.0 (Windows NT 6.1; WOW64; rv:42.0) Gecko/20100101 Firefox/42.0
    [Accept] => text/html,application/xhtml+xml,application/xml;q=0.9,*/*;q=0.8
    [Accept-Language] => hu-HU,hu;q=0.8,en-US;q=0.5,en;q=0.3
    [Accept-Encoding] => gzip, deflate
    [Connection] => keep-alive
    [Cache-Control] => max-age=0
)

 
Én nem látok mod_php headert, pedig még php-t is használtam.

Dupla hozzászólás automatikusan összefûzve. ( [time]2015. augusztus 31. 20:54:20[/time] )


Plusz ez az adat nem releváns, az hogy sok ember használ olyan fórum/blogmotorokat, amiket egyszer felraknak és utána sosem nyúlnak hozzá, nem jelenti azt, hogy a PHP-t könnyű lenne fejleszteni, karbantartani vagy skálázni.
Ezen kívül az is kérdéses, hogy mennyi jó kód íródik PHP-ben, mert az, hogy sok ember használja a nyelvet nem jelenti feltétlen azt, hogy jól, biztonságosan vagy más módszerrel nézve optimálisan használják azt. És ez valószínűleg így is van, azért, amit be is vallottál.
 
[/quote]
Beszíneztem pirossal két részt, amelyek 100%-os forrásmegjelelölés nélküli feltételezések, ezekre pontosan milyen a vita szabályait betartó érvelést vársz? Kérlek ettől tartózkodj.
Ha attól félsz hogy ez az eredmény ilyen elhagyatott random oldalak miatt jött össze, akkor hagy idézzek a mérő cég oldaláról:
 

Which websites do you analyze and crawl?
We currently crawl the Alexa top million sites.
 
[/quote]
Tehát valós, releváns, látogatott oldalakat néznek, nem pistike Wordpressét.
De itt a FAQ-juk, ahol még további kérdéskre is válaszolnak: http://www.w3cook.com/faq/home
Az a rész ahol a \"...hogy sok ember használja a nyelvet nem jelenti feltétlen azt, hogy jól....\" gondolatmenetedet fejtegeted, azon felül hogy feltételezés, elég durva sarkítás is. Itt is a programozók nagy részét akik php-val dolgoznak idiótának titulálod. Gondoljuk át még egyszer hogy hány weblapot hajt php, akkor hány php programozó van a világon? Nem gondolod hogy ahoz hogy egy ilyen kijelentést tegyél kicsit kevés bizonyítékot szolgáltattál?
 

 

\"mivel igazi programnyelvek\" -> Ezzel azt mondod, hogy a weboldalak ~70%-át, köztük a Facebookot, Wikipédiát,
vagy hogy fiatalabb start-upokat is említsek, a MailChimpet
és még számtalan más fontos piaci szereplőt egy nem igazi programnyelvben írták meg? Nyilván ez ugyan olyan mintha
paintben rajzolták volna meg azokat a weblapokat nem?
 
[/quote]
Addig, amíg vannak olyan emberek, akik meg tudnak bírkózni a programnyelv hiányosságaival, addig egyik programozási nyelv sem \"rossz\". Ez az adatpont sem lényeges, az, hogy hány weboldal használja nem jelent semmit, lehet, hogyha PHP helyett Whitespace-ben írták volna meg, akkor felével csökkent volna a fejlesztési idő.
Plusz a Facebook backendjét nem a PHP hajtja, hanem C alapú (ami megint nem egy abszolút tökéletes megoldás véleményem szerint, de ha a facebooknál ez működik, akkor én nem fogok beleszólni).
 
[/quote]
Azt írod hogy \"meg tudnak bírkózni a programnyelv hiányosságaival\" de egyetlen komoly konkrét hiányosságot sem írsz.
Az a link ami a php design hibáit taglalja az nem ezt jelenti, ott a tervezés hiányát róják fel a php ellen és nagyon korrektül vezetik le, de mint írtam az más.
A php-nak nincsenek olyan hiányosságai amik miatt egyértelműbben rosszabb lesz mint a vetélytársai, illetve rengeteg magas szintű fejlesztői eszközzel rendelkezik, amik egy rendes php developer számára sokszorosan meg is könnyítik a munkát.
Csak hogy párat kiemeljek, ilyen a php csomagkezelő a Composer (getcomposer.org), vagy magas szintű php framework-ök (Symfony2, Laravel, Zend Framework 2, Silex, stb...).
Illetve szeretnék eloszlatni pár félreértést: A SMF, a Wordpress és társaik NEM magas szintű php szoftverek. Ezeknek a programoknak az a céljuk hogy minél több helyen elfussanak, és ennyi.
A Facebookról: Amit mondasz (ismét) szimplán nem igaz, pontosabban túl-leegyszerűsíted a dolgot. A Facebooknak sok sok milliónyi kódsora php-ban van megírva. ( Facebook stack: http://stackshare.io/facebook/facebook) A Facebook először készített egy HipHop nevű fordítót, amivel a php kódot fordították át C-re, most már nem ezt használják hanem egy HHVM nevű technológiát, ami nagyon hasonlít a Java virtuális gépre, illetve egy Hack nevű programozási nyelvet, amit két szóval úgy lehetne leírni hogy fancy php.
De a végén bármit csinálsz, az nem változtat azon hogy a Facebookot nagyon nagy részben sok sok milliónyi php kód (is! mert van más is) hajtja.

Dupla hozzászólás automatikusan összefûzve. ( [time]2015. augusztus 31. 20:54:33[/time] )


 

Ne érts félre, a php valóban nem egy jól felépített nyelv.
Viszont ha kicsit utánaolvasol annak hogy mi is a php, hogyan jött létre, akkor azért nem nehéz látni ennek a miértjét.
A php-t nem pontról pontra tervezve építették fel egy jó design alapján. A php felnőtt. Maga a nyelv eredeti készítője
sosem egy komplett programozási nyelvet akart készíteni.
Gyorsan és hatékonyan akart weboldalakat készíteni egy-két segéd makróval.
Ennyi, a php viszont népszerű lett, pont azért, mert gyorsan és hatékonyan lehet benne weboldalakat készíteni.
A közösség nagyon erős szerepet vállal a nyelv fejlesztésében, tehát a helyzet nyilván nem is hasonlítható mondjuk egy C#-éhoz,
ahol a Microsoft szakemberei folyamatosan teljes munkaidőben dolgoznak a nyelven a legelejétől.
A php felnőtt, kifejlődött, fontos látni hogy ez sokkal inkább hasonlít egy evolúciós folyamatra mint egy jól megtervezett ösvényre.
 
[/quote]
Tisztában vagyok a PHP történelmével, nagyon alap szinten. Értem, mit mondasz. De nem különösebben érdekel, mert lényegtelen a beszélgetés tartalmára nézve.
Az, hogy gyorsan lehet weboldalakat készíteni, az oké. Az, hogy hatékonyan lehet vele jó weboldalakat készíteni készíteni, az is oké. Az, hogy a készítmény hosszútávon, más programnyelvekhez/stackekhez képest fenntarthatóan kezelhető, azt is talán lenyelem. De hogy ezek közül az összeset egyszerre meg lehet valósítani anélkül, hogy az egyik tulajdonság semmissé váljon, abban biztos vagyok.
Az evolúciós folyamatod nagyon jó analógia, csak az a baj, hogy az embernek is megvan még a vakbele, meg a kislábujja, meg egyéb dolgok, amik semmiben nem segítik a fajunk fennmaradását, csupán felesleges dolgok, amik a bajt okozzák. Van rengeteg következetlenség is benne, ami nem segíti a biológusok meg a fiziológusok munkáját. Nyilván lehet PHP-ban is programozni, de a kérdés az, hogy akarsz-e.
 
[/quote]
Hogy lenne már lényegtelen a php története a beszélgetés tartalmára nézve? Felróttad a php-nak hogy rosszul van megtervezve, én pedig először megindokoltam hogy miért is van ez, majd hogy miért nem számít, ehez szükséges egy előzetes tudás, a php történetére építettem azt az egész érvelést. Hogy lenne már lényegtelen?
 
Az, hogy gyorsan lehet weboldalakat készíteni, az oké. Az, hogy hatékonyan lehet vele jó weboldalakat készíteni készíteni, az is oké. Az, hogy a készítmény hosszútávon, más programnyelvekhez/stackekhez képest fenntarthatóan kezelhető, azt is talán lenyelem. De hogy ezek közül az összeset egyszerre meg lehet valósítani anélkül, hogy az egyik tulajdonság semmissé váljon, abban biztos vagyok.
[/quote]
Amit pirossal kiemeltem azt olvasd át még egyszer, mert valószínűleg nem ezt akartad írni.
De ez az egész bekezdés egy hatalmas feltételezés, hol néztél utána, milyen releváns forrásaid vannak, mennyi háttértapasztalatod van komoly php rendszerek fejlesztésében? De hogy azért reagáljak is, de igen, lehet php-val egyszerre hatékony, gyors, hosszútávon fenttartható és skálázható weblapokat készíteni, és nem, ez nem is nehéz. (Itt ismét nem a szomszéd kisfiú szintjére kell gondolni. De igen, neki nyilván nehéz lesz, én azokról a tisztességes php programozókról beszélek, akik ebből élnek, nekik semmivel nem nehezebb mint más programozási nyelveken dolgozó társaiknak) és mutatnék pár példát is:
 

és ezek csak kereskedelmi szereplők, nagyon sok magas szintű nyíilt forráskódú php is projekt létezik.
 
Az evolúciós folyamatod nagyon jó analógia, csak az a baj, hogy az embernek is megvan még a vakbele, meg a kislábujja, meg egyéb dolgok, amik semmiben nem segítik a fajunk fennmaradását, csupán felesleges dolgok, amik a bajt okozzák. Van rengeteg következetlenség is benne, ami nem segíti a biológusok meg a fiziológusok munkáját. Nyilván lehet PHP-ban is programozni, de a kérdés az, hogy akarsz-e.[/quote]
Ezzel nem mondasz semmit. Nem emeltél ki konkrét példát, de nincsen olyan hibája vagy következetlensége a php-nak amit magas szintű eszközök használatával ne lehetne elintézni egy csettintéssel. (Magas szintű eszközöket lásd feljebb). Ezeket az eszközöket mindenki használja aki rendes php kódokat ír napi szinten és ezzel nincsen semmi baj.

Dupla hozzászólás automatikusan összefûzve. ( [time]2015. augusztus 31. 20:54:47[/time] )


 

Tehát, lehet mondani hogy a php rettenetesen van tervezve? Igen. Lehet mondani rá hogy ez nem egy igazi programozási nyelv? Nem.
( Pontosabban lehet, csak az álszentség )
 
[/quote]
Attól függ, mit tekintünk programozási nyelvnek. Ha egy Turing-teljes nyelvet programozási nyelvnek nevezünk, akkor nyilván lehet PHP-t annak hívni. De akkor a Brainfuck is programozási nyelv, meg az ASM is. Lehet benne játékokat írni? Lehet, meg is tették az NES-en. Érdemes írni benne játékokat? Nem igazán. A Brainfuck egy programozási nyelv? Igen. Akarsz benne írni egy magas szintű GUI-kezelő rendszert? Hát, maximum ha mazohista fétised van.
 
[/quote]
Ezzel mit akarsz mondani? Remélem szerinted ez nem egy tisztességesen felépített érvelés. Erre nem vagyok hajlandó reagálni.
 

 

Az \"MVC paradigmát\" (becsületes neve szerkezeti minta) használó eszmefuttatásod tökéletesen bizonyítja hogy az ég világon semmit
nem tudsz a php-ról, elolvastál két blogpostot és talán ki is próbáltad, de ennyi, látszik a mélyebb tudás teljes hiánya.
Az MVC pattern használható php alatt is. De ez nagyon lealacsonyítóan hangzik, tekintve hogy a komoly php alkalmazások nagy része
használja ezt a design patternt, sok mással együtt. Mert vannak ám mások is, tulajdonképpen szinte az összes ami az ún. \"valódi programnyelveidben\" is megtalálható.
Meglepetés: https://github.com/domnikl/DesignPatternsPHP
 
[/quote]
Tudom, hogy lehet benne használni, de itt megint csak arról van szó, hogy a PHP-val sokkal könnyebb a rossz dolgot csinálni, mint a jó dolgot. Egy Pylons vagy egy akármelyik másik stack megköveteli, hogy ezt csináljad. A PHP, ami lényegében egy összetákolt CGI wrapper, vidáman fog műkdöni az MVC nélkül is.
Ez alatt az alábbit értem: Ha valaki egy hosszú távú projektet kezd el, amiben sok karbantartás és skálázás lesz, használhat Pythont, Railst vagy akármi mást, amiben be van építve az MVC, mint PHP-t egy MVC könyvtárral. Ellentétben ha valaki kezdő PHP-ben és csak most kezdte el az egészet, nem fog ezzel törődni és bele fog égni az agyába a rossz módszer. A PHP-ban sokkal könnyebb rossz kódot írni, mint jó kódot, ilyen egyszerű a probléma.
 
[/quote]
\"sokkal könnyebb a rossz dolgot csinálni, mint a jó dolgot\" - és hol a probléma? A megoldás nagyon egyszerű, meg kell tanulni jó dolgot csinálni.
Gondolkoztál már rajta hogy mit jelent ez megfordítva? Azt jelenti hogy a php hatalmas szabadságot ad a programozó kezébe. Igen, aki nem tudja mit csinál, annak az rossz, de az, aki ismeri a php-t és tapasztalt fejlesztő, az ugyan emiatt tud csodálatos dolgokat alkotni. Hogyan leszel tapasztalt fejlesztő? Csinálsz előtte sok sok rossz dolgot.
Ezen a logikán haladva nem gondolom azt, hogy egy gúsba kötés egy MVC rendszerbe hú de nagyon jó lenne.
Az MVC csak egy módszer. Több is van. Vannak ám az MVC-nek magának is változatai. Van sima Request-Response alapú felépítés,
ami bár hasonlít az MVC-re mégsem az. php-ban az összeset meg lehet csinálni.
A legnépszerűbb php framework például a Symfony2. Ez nem mondható teljesen MVC alapú rendszernek, ez egy Request-Response framework. Erről annyit kell tudni, hogy ez az egyik legmagasabb színvonalú modern php rendszer amit találni tudsz, és sok sok millióan használják. Azt akarod mondani hogy azért mert ez nem MVC, máris egy rossz rendszer?
( Olyan oldalakat is ez hajt, mint  Dailymotion vagy a BBC News... )
\"Ellentétben ha valaki kezdő PHP-ben és csak most kezdte el az egészet, nem fog ezzel törődni és bele fog égni az agyába a rossz módszer.\" - Aki kezdő php-ben és most kezdte el az egészet az ne akarjon üzleti szintű alkalmazást fejleszteni benne hanem tanulja meg a nyelvet rendesen.
\"és bele fog égni az agyába a rossz módszer\" - Ez (ismét) szimplán nem igaz. Én szerinted hogy kezdtem? Akkorákat gányoltam hogy ma már legszívesebben letagadnám az egészet, és ma már teljesen máshogy csinálom. Szerintem semmi olyan nem \"égett bele\" agyamba amit ne tudtam volna lecserélni.

Dupla hozzászólás automatikusan összefûzve. ( [time]2015. augusztus 31. 20:55:01[/time] )


 

Az a probléma hogy valószínűleg a legkomolyabb php kód amit eddig láttál a szomszéd kisfiúé volt, ott népszerű a
\"rakjnuk egy kis PHP-t meg egy kis javascriptet egy HTML kódba\" felállás, de lennél szíves nem egyből feltételezni hogy a világon
mindenhol máshol is ez a legnagyobb szint amire eljut egy php programozó?
 
[/quote]
Lásd fentebb. Nyilván egy WordPress vagy egy phpBB nem ilyen elven működik, ezt nem is feltételeztem vagy írtam. De Pista is tudna olyan kódot írni, ami biztonságosabb, stabilabb, jobban karbantartható és skálzható, mint a gányolmány, amiről beszélünk, ha egy olyan rendszert használna, ami megkövetelné ezt a modellt.
 
[/quote]
Fentebb kifejtettem hogy ez miért nem probléma.
 

 

 
Ez sok szempontból előnyös, mert így nincsenek problémák azzal, hogy a kódbázis az maga a tartalom[/quote]
Ez szimplán nem igaz semmilyen komoly rendszernél.
 
[/quote]
Dehogynem, láttam már olyat, hogy a weboldalt a .git mappával együtt töltötték fel. Ismét, nem a komoly rendszerekről van szó. Meg lehet úgy csinálni, hogy ne legyen szar, de nem lenne jobb, ha már eleve a jó megvalósítási módszert vésné a fejedbe a programnyelv?
 
[/quote]
Nem, nem lenne jobb. A php nem követeli meg verziókövető rendszer használatát, mégis miért kellene foglalkoznia neki azzal hogy vannak veszélyesen buta emberek? Ez nem egy reális elvárás.
 

 

 
így pl. őrzőket kell rakni minden include-ba, hogy egyenként ne lehessen őket lefuttatni, stb[/quote]
*what lady meme*
Te hallottál már a Front Controller nevű szerkezeti mintáról?
 
[/quote]
A konfigurációs fájlok direkt betöltését megakadályozva muszáj őrzőket használni (mint a C-s #define _INCLUDE.INC_INCLUDED #ifdef ...), hogy megakadályozzuk, hogy valaki a nem megjelenítésre szolgáló állományokat direkt betöltse.
 
[/quote]
Ismét felteszem a kérdést:
Te hallottál már a Front Controller nevű szerkezeti mintáról?
Ezen felül, pontosan ki mondta neked hogy a konfigurációs fájlokat meg amiket nem akarsz hogy elérjenek a netről, azt tedd ki a netre?
Tudtad hogy lehet ilyet is csinálni?
 
  • config.php

  • titkos_jelszavak.php

  • template.php


  • web/
    • index.php

     


Itt csak a web/ mappa érhető el a netről, azt állítod be Apache virtual hostnál a web directorynak.
Itt megint nem a php a hibás, hanem a nem gondolkodó lusta emberek.

Dupla hozzászólás automatikusan összefûzve. ( [time]2015. augusztus 31. 20:55:14[/time] )


 

 
Problémás ez még akkor, ha valamilyen verziókezelő rendszert is használsz (git, svn, stb.) mert a rejtett mappáik (.git, .svn) elérhetőek alapjáraton ha Apache-t használsz (márpedig azt használsz, ha PHP-t is használsz).[/quote]
Ez is szimplán nem igaz. Valójában az egész eszmefuttatás elbukik ott hogy \"márpedig azt használsz [apachot], ha PHP-t is használsz\".
Én php-t használok, de Apache-ot nem.
 
[/quote]
Akkor te vagy az egyik szernecsés ember. Amúgy ha nem az Apache+MySQL+PHP kombót használod, akkor egy rails app deployment kb. ugyanannyi időbe telik, mint egy PHP deployment, szóval akkor már egyből nem olyan könnyen valósítható meg a dolog, mint gondolnád.
 
[/quote]
Én nem igazán értem hogy itt mit szeretnél ezzel mondani vagy hogy mennyi időkre gondolsz deployment alatt, de leírom hogy nálunk hogy néz ki a deployment:
 
  • A git master branchbe pusholunk kódot/mergelünk egy másik branchet *ez a részünkről egy gombnyomás*

  • A kód letöltődik a szerverre

  • A szerveren lévő régi kódról készül egy backup

  • Az adatbázison lefutnak a szükséges változtatások (új táblák,mezők,stb)

  • Az új css,js fájlok és képek feltöltődnek a CDN-re (Amazon Cloudfront)

  • Az új kód élesítődik a szerveren

  • A rendszer kiküldi a deployment értesítőket


Ez az egész folyamat sosem tart tovább 10 másodpercnél, és legtöbbször 3-4 másodperc alatt már készen van.
A folyamat nagy részét php-ben íródott eszközök vezénylik le. Nem tudom hogy egy rails appnál ez hogy néz ki, de nem is gondolom hogy releváns.
 

 

 
Hasonlóan pl. el lehet különíteni a webalkalmazást és a szervert magát, így könnyen tudsz pl. webszervert váltani anélkül, hogy magát az alkalmazást újra kéne írnod.
[/quote]
Ez php-ra is teljesen igaz. Sőt, sok esetben még az is mindegy hogy Windows vagy Linux alapú a szerver.
Igazából nem tudom hogy milyen php kódra gondoltad azt, hogy ennyire nem változás tűrő.
Én mint mondtam régen Apache hajtotta az alkalmazásainkat, most már más webszervert használunk, de az átállás miatt egyetlen
sornyi kódot sem kellett átírnunk. És egyetlen perci kimaradás sem volt a kiszolgálásban.
 
[/quote]
Nem mondtam, hogy a PHP-nál nem lehet ezt megoldani, csak megjegyeztem, hogy a legtöbb framework (pl. Pylons) nem jön külön webszerverrel.
 
[/quote]
Nem látom ennek a relevanciáját.
 

Minden megvalósítható minden programozási nyelvvel, azért programozási nyelv. Amit meg lehet írni PHP-ban, azt meg lehet írni Brainfuckban meg C-ben is, de nem mindegy, hogy milyen projekthez milyen eszközt választasz.
 
[/quote]
Én ezt sosem vitattam.
 

A PHP kb. semmilyen weboldalhoz nem optimális, kis projekteknél kezdő programozóknál nem nyújt megfelelő biztonságos és rosszan felépített kódhoz vezet, nagyobb projekteknél pedig sokkal könnyebben, hatékonyabban, és skálázhatóbban lehet kódot fejleszteni más nyelvekben.
 
[/quote]
Amit mondasz ismét egyszerűen nem igaz, ez 100% feltételezés minden forrás nélkül. Én tiszteletben tartom a véleményedet, de nem szeretném ha butaságokat terjesztenél tényként. Mert ez egy vélemény, és a valóság nem ez.

Dupla hozzászólás automatikusan összefûzve. ( 2015. augusztus 31. - 20:55:28 )


Maga a probléma nem a PHP-val van, hanem a közösséggel és a fejlesztői társadalommal. Kezdő programozóknak lett írva, nem profi fejlesztőknek, de a kezdőknek nem nyújt megfelelő védelmet. A legtöbb embernek fogalma sincs, miért rossz a PHP, miért nem jó összegányolni a tartalmat az appal és hogy vannak más, jobb alternatívák. Ezzel a programozók 90%-a bekerül egy olyan ördögi körbe, amiből nagyon nehéz kimászni.
 
[/quote]
Eddig teljesen mást írtál. De nem számít. Viszont ez is egy hatalmas hülyeség (már ne haragudj de erre már nem tudok mást mondani).
\"Kezdő programozóknak lett írvanem profi fejlesztőknek,\" - nem igaz. Ferdítés. Sőt. Nem fontos a php történelme mi? Szélesítsd a tudásod.
\" de a kezdőknek nem nyújt megfelelő védelmet.\" - A \"védelem\" amit számon kérsz nagyon nagyon szubjektív. Én például nem szeretném ha a php gúsba kötne, nekem tetszik hogy ennyire szabad a nyelv és nem is gondolom problémának.
\"A legtöbb embernek fogalma sincs, miért rossz a PHP, miért nem jó összegányolni a tartalmat az appal és hogy vannak más, jobb alternatívák.\" - Szintén 100% szubjektív vélemény és fentebb kifejtettem, hogy mint objektív tény ez az állítás nem állja meg a helyét.
\"Ezzel a programozók 90%-a bekerül egy olyan ördögi körbe, amiből nagyon nehéz kimászni.\" - Forrás? Csak mert nem igaz.
 

Hogy ezt bemutassam, lássuk, mi a top 10 legfontosabb kérdés a Stack Overflow-on a php taggel:
 

  • How can I prevent SQL-injection in PHP? - ezt a mysqli úgy, ahogy megoldotta, de ha más adatbáziskezelőt használsz, akkor semmit nem ér.


  • Reference - What does this symbol mean in PHP? - minden szintaxis kb. benne van ebben a posztban, mellette posztokkal amik elmagyarázzák. Ezt nem a dokumentációnak kellene?


  • Why shouldn\'t I use mysql_* functions in PHP? - biztonsági kérdés, mert a mysql api még mindig bent van és vígan lehet használni, szóval az első kérdés igen is aktuális még most is.


  • How should I ethically approach user password storage for later plaintext retrieval? - ismét biztonsági kérdés, hogy oldjam meg, hogy ne tudják ellopni a jelszavakat de azért tudjak jelszóemlékeztetőt is küldeni.


  • How \'foreach\' actually works - érthetetlen szintaxis, amit SO-n kell elmagyarázni, a doksi helyett.


  • How to fix “Headers already sent” error in PHP - egy elbaszott PHP feature, amiben a PHP tagek előtti whitespace beleszámít a szövegbe és felülírja a HTTP fejlécet, amit akarsz küldeni.


  • How do you use bcrypt for hashing passwords in PHP? - biztonsági kérdés, az ötszáz közül épp melyik hashelő algoritmus a legjobb a jelszavak tárolásához.


  • Secure hash and salt for PHP passwords - hogy lehet jelszót tárolni és sózni, külön pont az MD5-ös lehetőség megemlítéséért. lol.


Mindezekből én azt szűröm le, hogy a felhasználók 90%-ának fogalma sincs, hogy hogy működik a nyelv, amiben programoznak, és akik értik, azok se tudják, hogy hogy lehet biztonságossá tenni az alkalmazásaikat.
 
[/quote]
Én nem tudom hogy ebből hogy vontad le ezt a következtetést. Sok helyen felrovod a doksi hiányosságát. A php doksi tényleg nem 100%-os, de igen is elég jól dokumentálja a nyelvet. Sok vád egyszerűen nem korrekt és nem néztél utána a dolgoknak.
A mysql_* függvényekről: Az összes függvény doksi oldalán a legelején egy rohadt nagy vörös dobozban leírja hogy ezt ne használd.
Az, hogy felrovod neki hogy miért van még bent az nevetséges. A függvények a  5.5.0 verziótól léptek deprecated státuszba. Ez azt jelenti hogy a következő főverzióból fognak kikerülni, addig visszafele kompatibilis. A php következő főverziója a php 7.0.0 lesz, akkor fognak kikerülni. (6.0.0 nem lesz kiadva). Ezt nevezik semantic versioningnek, ami az egyik legszélesebb körben elfogadott verziókövetés: http://semver.org/
A \"what this symbol means\" - Én valahogy megtaláltam erről mindent a doksiban: http://php.net/manual/en/language.operators.php
A foreachos kérdésről, el van magyarázva a doksiban a foreach. Az a SO-s kérdésre a válasz a belső működést írja le, ez inkább érdekesség mint létszükséglet.
A biztonsági kérdések a jelszavakról: nem látom hol a probléma.
\"How to fix “Headers already sent” error in PHP\" - Azért valljuk már be hogy a HTTP protokol annyira nem bonyolult. Először kiküldöd a fejléceket aztán a tartalmat. Ha először fejléceket, aztán tartalmat, aztán megint fejléceket akarsz küldeni, akkor hiányosak az ismereteid a legalsóbb szinteken.
 
Mindezekből én azt szűröm le, hogy a felhasználók 90%-ának fogalma sincs, hogy hogy működik a nyelv[/quote]
8 kérdés alapján 90%? Huha
Ez csak azt bizonyítja hogy sok kezdő van akik nagyon az alapoktól kezdik, de azért ezek közül sok kérdés (pl. a foreachos) nagyon nagyon nem csak a kezdőknek érdekesek.
 
és akik értik, azok se tudják, hogy hogy lehet biztonságossá tenni az alkalmazásaikat.[/quote]
Nem tudom pontosan kikre gondolsz az alatt hogy \"értik\", de lehet hogy itt nálad van a tévedés. SO-n van nagyon nagyon sok
nagyon színvonalas és magas szintű válasz, amik mellett nem értem hogy miért akarsz elmenni lehajtott fejjel.
Másfelől a SO egy erősen vitatható hely mint forrás, sokkal több a kezdő kérdező mint a profi válaszoló, de ezt felhánytorgatni nevetséges lenne.


Nagyon sok helyen a saját véleményedet és forrás nélküli eszmefuttatásodat írtad le. Szerintem nagyon jó hogy van határozott véleményed, de sok helyen ezeket tényként akartad használni, egy olyan helyen ahol sok a kezdő, akik erre nem fognak tudni mit mondani és el fogják fogadni tényként, ami káros. Kérlek ettől tartózkodj, mindig hangsúlyozd ki hogy mikor mondasz véleményt és mikor bizonyítható tényt.
UI.: Ne haragudjatok a dupla postok miatt, máshogy nem engedte elküldeni a fórum, nginx hibát írt.

 

SimplePortal 2.3.7 © 2008-2024, SimplePortal