- Samsung Galaxy S23 Ultra - non plus ultra
- Samsung Galaxy S23 és S23+ - ami belül van, az számít igazán
- Milyen okostelefont vegyek?
- Yettel topik
- Vivo X200 Pro - a kétszázát!
- MIUI / HyperOS topik
- Fotók, videók mobillal
- One mobilszolgáltatások
- Nem minden Nothing Phone (3) születik egyenlőnek
- Samsung Galaxy S25 Ultra - titán keret, acélos teljesítmény
Új hozzászólás Aktív témák
-
#13675
Peter Kiss
őstag
Speeedfire
#13674
Peter Kiss
őstag
válasz
Speeedfire
#13674
üzenetére
Szerintem a lényeg nagyobb verzióváltáskor az a nyelvi újdonságok, pl. finally, 5.4-ben meg pl. lett trait.
-
#13673
Peter Kiss
őstag
Peter Kiss
őstag
-
#13653
Peter Kiss
őstag
Speeedfire
#13649
Peter Kiss
őstag
válasz
Speeedfire
#13649
üzenetére
Mi lenne, ha optimalizálnád azt a tárolt eljárást?
-
#13553
Peter Kiss
őstag
FehérHolló
#13552
Peter Kiss
őstag
válasz
FehérHolló
#13552
üzenetére
Most felraktam a PhpStorm-ot, ahogyan időm engedi, próbálgatom, mindenképp javult az 5-öshöz képest. Még az is lehet, hogy vásárlás lesz, Visual Studio-hoz már úgyis megszoktam a Resharper-t.
-
#13551
Peter Kiss
őstag
FehérHolló
#13550
Peter Kiss
őstag
válasz
FehérHolló
#13550
üzenetére
Van, fizetős
: PhpStormAz 5-ös nekem nem jött be, a 6-ost még nem próbáltam.
-
#13549
Peter Kiss
őstag
FehérHolló
#13548
Peter Kiss
őstag
válasz
FehérHolló
#13548
üzenetére
Netbeans
-
#13547
Peter Kiss
őstag
Sk8erPeter
#13546
Peter Kiss
őstag
válasz
Sk8erPeter
#13546
üzenetére
Egy dologgal érveltél a Drupal mellett, az pedig a Symfony2 volt. Attól, hogy sokat írsz, még nem mondasz többet.
Ha akarod, emellé még odacsaphatjuk a közösséget, de ez megvan máshol is, illetve saját rendszer esetén is ott lehet. Egyébként, ha a Drupal is úgy lenne fejlesztve (meg sok más is), hogy lehetne rá automatizált teszteket írni, akkor sokkal élhetőbb lenne az adott rendszer (Drupal, Drupal modul, más keret, miegymás), legyen szó bármelyikről. Az ezelőtt említett keretrendszek (legyen CMS vagy nem) kicsit sem felelnek meg ennek az elvárásnak, ki sem látszanak a global-ból és a static-ből, így nem is csoda, hogy kell a közösség, hogy mindent észrevegyen.
-
#13545
Peter Kiss
őstag
mobal
#13540
Peter Kiss
őstag
A Kohana hasonló az előző kettőhöz. Valószínűleg mindegyiknél abból indultak ki, hogy kellene valami keret az apróságainknak, de akkor használjunk osztályokat, de még tegyünk hozzá valami feature-t, és még egyet, még egyet...
A Symfony2 ezek mellett egy ASP.NET MVC szintű cucc, bár több ponton szerintem túllőttek a célon, illetve az annotációkkal történő játék nekem nagyon nem jön be (majd esetleg akkor, ha a PHP-nak sajátja lesz), de Potencier bácsi és csapata azért érti a dolgát. Valószínűleg én is előbb a Symfony2-t nézegetném, mint a Zend Framework-öt. (Akár máshogyan is lehetne érzékeltetni az előbbi 3 és a Symfony2 viszonyát: PHPMailer vs. Swiftmailer)
---
@Sk8erPeter
Hiába raknak a Drupal alá Symfony2-t, amíg "bizonyos kódrészletek kompatibilitási okokból megmaradnak", magyarul a szarkupacból egy egész halom lesz. Nice move. (Igazából akármit csinálhatnak, annyi minden van Drupal alá, hogy azok miatt nem lesz soha semmilyen nagy megtisztulás.) -
#13539
Peter Kiss
őstag
mobal
#13538
Peter Kiss
őstag
Lehet, hogy nem a jobbik.
A másik kettővel az a baj, hogy nem objektum orientáltak, hanem class orientáltak, vagy még azok sem, mert helyenként durván összekeverednek a felelősségek, emellett hirdetik, hogy új PHP verzióra van, meg minden, de olyan elemek vannak mindegyikben (Codeigniter-ben), amelyeket a PHP 5 óta nem szabadna használni (&$, illetve metódusoknál/függvényeknél function &akarmi referenciázás még objektumok esetén is, pedig ott már egy internal handler mindent intéz, de így csúnya dolgok alakulhatnak ki amellett, hogy lassú, mint a sz.r).
-
#13526
Peter Kiss
őstag
Speeedfire
#13525
Peter Kiss
őstag
válasz
Speeedfire
#13525
üzenetére
Egy keretrendszer fájljait nem igazán okos ötlet felülírni. Látszik, hogy nincs erre biztosítva rendes lehetőség, hiába van benne, gyakorlatilag öntött vasként üzemel. Widget-ek CMS-hez vannak, a Yii meg nem az lenne, elvileg. A felépítésével is vannak problémák, de te magad is belefutottál a múltkor a nem túl jól megírt kód problémáiba, mikor nem tudtad elkapni a PDO-nak vagy minek a kivételeit.
-
#13523
Peter Kiss
őstag
Speeedfire
#13522
Peter Kiss
őstag
válasz
Speeedfire
#13522
üzenetére
widgets - 3 nagyobb ilyen rész is van benne
framework\web\js\
minden gyanús, ami a Component-től származikÉs miegymások. Persze, amire nincs szükség, nem kell használni, de ahelyett, hogy CMS-t próbálna belőle készíteni a fejlesztője, rendbe rakhatná a kódbázisát, mert jelenleg tele van fekete mágiával.
-
#13505
Peter Kiss
őstag
Sk8erPeter
#13497
Peter Kiss
őstag
válasz
Sk8erPeter
#13497
üzenetére
A "már valaki egyszer megcsinálta, csak valószínűleg jobban" érvelés szerinted mennyire jól alátámasztott?
Eleve azt felvetni, hogy a CMS készítők csak azért, mert már feldobtak valamit a netre, bárkinél jobbak lehetnek? Ezt tényként kezelni? Láttad te már a Drupal forrását? A modulokét? Szerinted normális emberek csinálták? #13493; Drupal és az igényesség, mi?
Egy Drupal alapú fejlesztést az első problémás, egyedi igény meg tudja ölni, az a baj. Ilyenkor mi történt, történik? Tételezzük fel, hogy a Drupal alap nem teljesen ismeretlen, csak a most szükséges modulokat kell beszerezni (esetleg megvenni, most is találtam, külsőre tiszta jó is volt), az első probléma ott jelentkezik, ha a modulok nem akarnak találkozni. Tételezzük fel, hogy sikerül megoldani idő és némi szenvedés árán, jön egy probléma, amit meg kell oldani, de nincs rá modul. Oké, megtanulunk Drupal modult írni (ha már le lettünk fikázva a kódírási képességeink miatt, akkor vajon a Drupal-hoz írt modulunk az már penge?
), ez szintén nem kevés idő, aztán meg vagy működik vagy nem. Jönnek még igények, vagy van modul, vagy nincs, leküzdjük (idő, pénz, sárm), de pl. amikor jönne egy olyan, hogy auditálva kellene minden (mert az egyik alkalmazott csinált valami f.szságot), akkor máris meghaltunk, mert általában ez senkinek sem jut eszébe (modulkészítőknek sem). Ja, igen, riportok is kellenének, legyen benne minden, ami csak elképzelhető, mert XY összefüggést akarom látni. Oké, ott tartunk, hogy kivitelezhetetlen a jelenlegi rendszerrel, újat kell építeni. Mennyibe is kerül ez? Hát nem 2 millióba. Alapból egy nagyon komoly üzleti döntés, de akkor, ha még elegendő pénz sincs, még nagyobb súlyú.---
Ha nem is a Drupal-t vesszük alapul, láttad már, hogyan épülnek fel a PHP-s keretrendszerek? Én egyelőre a kisebbeket nézegetem, a CakePHP csoda, hogy működik, a Yii pedig tele van olyan dolgokkal, amelyeknek semmi keresnivalója egy ilyen rendszerben (2.0-át hirdetik úgy, hogy nulláról újraírva, pedig egy nagy sz.rt lesz úgy
). Zend-et még csak karcoltam, mást szerintem még nem néztem. -
#13494
Peter Kiss
őstag
Sk8erPeter
#13493
Peter Kiss
őstag
válasz
Sk8erPeter
#13493
üzenetére
Egy CMS olyan rugalmas, mint az öntött vas egy saját fejlesztéshez képest.
-
#13492
Peter Kiss
őstag
Sk8erPeter
#13491
Peter Kiss
őstag
válasz
Sk8erPeter
#13491
üzenetére
Ehhez nem CMS kell, az a baj.
-
Peter Kiss
őstag
válasz
Tele von Zsinór
#13471
üzenetére
Ha a kódnak erős függése van raa, hogy webszerveren fusson, akkor nem fog működni alapból. Kell egy proxy script, ami pl. cURL-lel meghívja az adott URL-t, és ebben az esetben ezt kell futtatni a megadott módon.
-
#13450
Peter Kiss
őstag
Sk8erPeter
#13449
Peter Kiss
őstag
válasz
Sk8erPeter
#13449
üzenetére
Ha furcsállná, miért az van bent, ami.
-
#13447
Peter Kiss
őstag
spammer
#13446
Peter Kiss
őstag
válasz
spammer
#13446
üzenetére
1. Értelmetlen. Használj prepared statement-eket!
2. htmlentities -
#13440
Peter Kiss
őstag
pvt.peter
#13428
Peter Kiss
őstag
válasz
pvt.peter
#13428
üzenetére
Semennyire. A csatlakozáshoz szükséges adatok tárolói mind private-ok, hol lehet őket beállítani? Konstruktorban csatlakozik a szerverhez (miért is?), de be lehet zárni menet közben a kódban, így a későbbi részek meg is haltak, ha használni akarják. Állapotot tartalmazó cuccok nem lehetnek static változóban sosem. Ennél durvább már csak az lehetne, ha ehhez hasonló kóddal perzisztens kapcsolatokat használna valaki.
Ha jól emlékszem, a mysql nem is tud SQL tranzakciókat kezelni.
@Sk8erPeter
Van értelme wrapper-t csinálni, mert a mysqli és a PDO még nem az, illetve mind a kettő ocsmányul néz ki, plusz sosem tudhatod, mikor mondják azt, hogy PDO nincs, csak mysqli, akkor cserélhetsz mindenhol mindent, emellett meg tudja könnyíteni a tranzakciókezelést, be tudsz szúrni pl. PDO driver-specifikus beállításokat, ilyesmi.
-
#13402
Peter Kiss
őstag
Speeedfire
#13399
Peter Kiss
őstag
válasz
Speeedfire
#13399
üzenetére
Az gáz azért.
-
#13398
Peter Kiss
őstag
Speeedfire
#13396
Peter Kiss
őstag
válasz
Speeedfire
#13396
üzenetére
Névterezve van minden? Mert a catch-et is úgy kell megírni: \Exception
try {
$data->queryAll();
} catch (\Exception $e) {
echo 'Hiba lépett fel!'
} -
#13316
Peter Kiss
őstag
Vision
#13315
Peter Kiss
őstag
válasz
Vision
#13315
üzenetére
A switch olyan rugalmas, mint az öntött vas. Egy tömbbe vagy egy kicsivel inteligensebb cuccba kell pakolni; ha megvan az elküldött key ebben a tárolóban, akkor a hozzá tartozó value kell, ha nincs, kell egy default.
1-esre semmiképp sem kellene átírni, mert nem mond semmit magáról; szövegesen értelmesebb, pl.: red.
-
#13286
Peter Kiss
őstag
spammer
#13285
Peter Kiss
őstag
válasz
spammer
#13285
üzenetére
PHP telepítése Windows 7, 8-ra (Vista-ra is szerintem) - csak röviden.
-
#13284
Peter Kiss
őstag
spammer
#13283
Peter Kiss
őstag
válasz
spammer
#13283
üzenetére
Nem fog menni. PHP Windows-on 8859-1-gyel (vagy hasonló single byte coding-gal) dolgozik, ha fájlnevekről van szó. De ettől függetlenül sosem szerencsés ilyen jellegű fájlneveket adni.
Windows-on miért kell EasyPHP? Ott az IIS (neked ráadásul 8-as), amire fel lehet pattintani a legújabb PHP verziót is, és megy, mint a szél.
-
#13279
Peter Kiss
őstag
#68216320
#13278
Peter Kiss
őstag
-
#13204
Peter Kiss
őstag
Sk8erPeter
#13202
Peter Kiss
őstag
válasz
Sk8erPeter
#13202
üzenetére
Jobban nem lehet érzékeltetni, hogy semmi sem kell a tárhelyen hozzá.
-
#13200
Peter Kiss
őstag
Speeedfire
#13199
Peter Kiss
őstag
válasz
Speeedfire
#13199
üzenetére
Ez egy eszköz, mint a Notepad vagy a Netbeans.
-
#13190
Peter Kiss
őstag
#36268800
#13189
Peter Kiss
őstag
válasz
#36268800
#13189
üzenetére
Layout-ot alapvetően HTML elemekből áll, amelyeket CSS-sel cicomáznak ki. Ami plusz dolog jöhet akármelyik nyelvet is nézzük, az a dinamikus változók kiírása, dinamikus blokkok kijelölése, feltöltése. Template engine-ek léteznek, csak ezekkel szerintem az a baj, hogy a PHP maga már az, de pl. amit szoktak alkalmazni, azok a "HTML helper"-ek, ilyet magad is csinálhatsz, mert egyébként ki tudja, milyet tudnál használni (pl. legfaékebb és ocsmányabb megoldással van egy HTML osztályod, aminek pl. van valamilyen metódusa, pl. HTML::Img($src, $alt = ""), ami kitol magából egy full <img /> tag-et csak az src="" attribútumot megadva).
-
#13156
Peter Kiss
őstag
Vision
#13155
Peter Kiss
őstag
válasz
Vision
#13155
üzenetére
Abszolult igazuk van rá, így nem is értem, hogy miért tart már a 4. verziónál az ASP.NET MVC, illetve miért van 20 millió PHP framework, ami MVC mintát követ ráerőltetés nélkül.
És az anyja mindenit, működik! 
Egyébként is, hogy jön ide, hogy valami stateless-e vagy sem?
-
#13152
Peter Kiss
őstag
syC
#13151
Peter Kiss
őstag
Fájlokat a $_FILES super global-ban keressük, nem a $_POST-ban
move_uploaded_file()-lal odamozgatod, ahová akarod, vagy maradhat a helyén is, úgyis fel lehet dolgozni
HTML oldalról a <form /> tag-ből hiányzik az enctype="multipart/form-data"Interneten (például máris a php.net-en) találsz írásokat arról, hogyan kell kezelni a fájlfeltöltéseket.
-
#13143
Peter Kiss
őstag
H.O.D.
#13136
Peter Kiss
őstag
válasz
H.O.D.
#13136
üzenetére
Mindkettő rossz. Active record-nak hívják, akárhogy is csinálod, ahol az entitásod egyben felel azért, hogy mentve legyen minden adott típusú elemed, illetve a lekérdezésért is ez felel. Az ilyen jellegű keveredések károsak.
Ha a legegyszerűbb értelmes megoldást szeretnéd, akkor kell
valami, ami kezeli a "tárhelyet" (adatbázis backend mellett ez jelenti az adatbázis-kapcsolatot, illetve a query-k végrehajtását),
valami, amivel le tudsz kérdezni, menteni tudsz (DAO),
és az entitásod (Product) -
#12850
Peter Kiss
őstag
DeltaPower
#12848
Peter Kiss
őstag
válasz
DeltaPower
#12848
üzenetére
Ha ilyen történt, akkor az adatbázis-indexelési gond volt, ez az esetek többségében nem sikerül senkinek sem normálisan megcsinálnia (nincsenek indexek vagy haszontalanok).
Persze a query-k is lehetnek sz.rok.
-
#12797
Peter Kiss
őstag
CSorBA
#12796
Peter Kiss
őstag
válasz
CSorBA
#12796
üzenetére
Az a baj, hogy szerintem 1-1 fájllal tesztelte ezeket (nem olvastam végig a hozzászólását). A nagyobb különbség akkor jön elő, ha pl. a class loader-ben _once van használva, és az adott kérés kiszolgálásához szükség van 100 osztály betöltésére; egészen biztos vagyok benne, hogy hashmap van használva a nyilvántartáshoz, hogy mi töltődött be, valószínűleg gyors is a hash, csak épp emiatt lesz egy csomó ütközés, ami egy adott elem betöltésének visszakövetését jól lelassítja.
Az, hogy most mennyivel lassabb, észrevehető-e egyáltalán, hasonló kérdés ahhoz, mint mikor egyszer megkérdezték, hogy PHP-val történő képmanipuláció után azonnal engedje el az erőforrásokat, vagy majd a PHP kitakarít maga után a script végén. Minden byte memória számít, mint ahogyan minden processzoridő.
-
#12795
Peter Kiss
őstag
Dave-11
#12793
Peter Kiss
őstag
válasz
Dave-11
#12793
üzenetére
A require-t érdemesebb, "erősebb" hibát dob. (A hiba az hiba, include esetén nagyobb az esély, hogy figyelmetlenségből elhagyunk valamit.)
Plusz info, hogy a _once verziók sokkal lassabbak, csak akkor használd ezeket, ha tényleg van esély arra, hogy kétszer töltenél be valamit (láttam már class loader-ben is _once-t, facepalm).
-
#12741
Peter Kiss
őstag
Mbazsika
#12740
Peter Kiss
őstag
válasz
Mbazsika
#12740
üzenetére
Használd a sasql_fetch_assoc-ot a sasql_fetch_row helyett.
-
#12677
Peter Kiss
őstag
rezme
#12676
Peter Kiss
őstag
Hiányzik:
line_shadow.png
/wp-content/themes/hades/imagesChrome console kimenet:
Viewport argument value "device-width;" for key "width" not recognized. Content ignored. Note that ';' is not a separator in viewport values. The list should be comma-separated. /:36
Viewport argument value "1.0;" for key "initial-scale" was truncated to its numeric prefix. Note that ';' is not a separator in viewport values. The list should be comma-separated. /:36
Viewport argument value "1.0;" for key "maximum-scale" was truncated to its numeric prefix. Note that ';' is not a separator in viewport values. The list should be comma-separated. /:36
Viewport argument value "0;" for key "user-scalable" was truncated to its numeric prefix. Note that ';' is not a separator in viewport values. The list should be comma-separated. /:36
Resource interpreted as Script but transferred with MIME type text/html: "about:blank". techport.hu:47
Uncaught ReferenceError: TWTR is not defined techport.hu:478
GET http://techport.hu/wp-content/themes/hades/images/line_shadow.png 404 (Not Found) techport.hu:120És ez PHP topik.
-
#12668
Peter Kiss
őstag
biker
#12666
Peter Kiss
őstag
Igen, PHP estében teljesen normális.
Ami szerintem nem normális, hogy azonos tulajdonságot két különböző típussal akarsz leírni, illetve ezeket a típusokat össze is hasonlítod. Sokkal ésszerűbb, ha az üzleti logikádba nem kevered bele ezt a '-' dolgot, ezt elég csak a UI oldalon mutatni (ott a 0 [talán] hülyén néz ki).
-
#12658
Peter Kiss
őstag
#68216320
#12657
Peter Kiss
őstag
-
#12654
Peter Kiss
őstag
Fenris69
#12653
-
#12438
Peter Kiss
őstag
SektorFlop
#12437
Peter Kiss
őstag
válasz
SektorFlop
#12437
üzenetére
foreach ($this->errors as $key=>$value);
echo $value. '<br>';Bejárod a tömböt anélkül, hogy bármit csinálnál, csak épp a bejárás után még megmarad a $value benne az utolsó elemmel, amit kiíratsz.
-
#12374
Peter Kiss
őstag
Peter Kiss
őstag
Az isset() egyébként sem függvény.
-
#12216
Peter Kiss
őstag
lezso6
#12215
Peter Kiss
őstag
válasz
lezso6
#12215
üzenetére
Nekem már sikerült ilyenbe belefutnom, nem volt őszinte a mosolyom. Ami igazából fontos a példából, hogy ne használjunk referenciákat, de nem csak azért, mert ilyen eredmények születhetnek, hanem Do-not-use-PHP-references.
-
#12176
Peter Kiss
őstag
Swifty
#12166
Peter Kiss
őstag
válasz
Swifty
#12166
üzenetére
Minden nyelvben a ToString(), toString() és a __toString() arra való, hogy az objektum aktuális állapotát dumpoljuk, ahogyan ezt tehetnék akár a var_dump(), print_r() segítségével is. Ha valami ki akarunk szedni, mint szöveg az objektumból, akkor arra megvan a pontos metódusunk.
-
#12164
Peter Kiss
őstag
cucka
#12153
Peter Kiss
őstag
Nem, a különbség nem csak szintaktika, és nekem nem ekvivalens a kettő. Ha én valahol egy interface-t (vagy egy sima általános object-et várnék (stdClass?)) várok, akkor nem mondhatom minden egyéb teszt nélkül neki azt, hogy __toString() mert egyből meghalhat (attól eltekintve, hogy valószínűleg nem ezért várunk egy adott típusú elemet).
A különbség elvi, PHP-ban egészen pontosan elvi hiba. Eleve, magic gyűjtőnév alatt vannak, ez messze nem tervezés eredménye, shol sem lehet arra számítani, hogy ezek ott vannak az adott objektumban.
@Swifty
Ez még példának is rossz volt... A __toString()-t soha sem használjuk ilyenre... Semmilyen production kódba nem írunk ilyet így... MVC-ben főleg nem így dolgozunk... -
#12151
Peter Kiss
őstag
cucka
#12149
Peter Kiss
őstag
Ez a magic methodos dolog sántít, mivel, ha csinálok egy ilyet:
class Foo {}
Akkor ettől ennek még nem lesz egyetlen __ metódusa sem, mivel nincs base object (saját rendszerben mindenki csinálhat magának, nyilván).
---
Ez típusossági problémát már kicsit túlpörgitek, ha valamit osztály segítségével lehet rendesen leírni, használjunk osztályt.
Ha valami jó primitívként, használjunk primitívet, akár úgy, hogy a metódus bemenő paraméterét felülvágjuk (pl. strval()-lal), senki sem izgat, ilyen módon engem nem zavar, hogy nem kell kiírni mindenhová, hogy int, float, string (array, class/interface név nekem elég, callable még jó lenne, de legalább van Closure).
Abban az esetben, ha valami primitívnek tűnik, de nem az, akkor C#-ban és Java-ban is bevezetek egy olyan saját típust, ami segít leírni, miről is van szó (SSN-t nem numerikus értékként, string-ként használunk, hanem van rá SocialSecurityNumber nevű osztály), ezt szinte mindenhol meg lehet tenni. -
#12103
Peter Kiss
őstag
trisztan94
#12102
Peter Kiss
őstag
válasz
trisztan94
#12102
üzenetére
Meg kell győzni őket a jó oldaláról.
Viszont, ha már váltani akarsz, nem biztos, hogy a Yii lesz a legjobb. Nem használtam, csak a doksiát nézegetve nekem nem jött be (szerintem messze áll az ASP.NET MVC-től és a kapcsolható ORM-ektől).
-
#12101
Peter Kiss
őstag
Lacces
#12099
Peter Kiss
őstag
válasz
Lacces
#12099
üzenetére
Próbáltál valami okosat mondani ezzel a kódbiztonsággal kapcsolatban, de valahogy nem sikerült. Itt nem arról van szó, hogy egy fejlesztő mennyire ügyes, hanem egyáltalán a lehetőségek milyenek: egy gyengén típusos nyelvnek esélye sincs egy típusos, fordított nyelvvel szemben, de, ha nagyobb képet nézem, akkor az vicc például, hogy a DateTime osztály működése PHP-s verziókon keresztül billeg, hibásan működik, ez nem megengedhető.
-
#12089
Peter Kiss
őstag
Inv1sus
#12085
Peter Kiss
őstag
válasz
Inv1sus
#12085
üzenetére
Hirtelen Apache-ra tippelvén:
.htaccess a gyökérbe:
<IfModule mod_rewrite.c>
RewriteEngine on
RewriteRule ^$ Public/ [L]
RewriteRule (.*) Public/$1 [L]
</IfModule>---
@(#12088) Speeedfire
A PHP kb. egyetlen előnye, hogy ingyenes infrastruktúrára is fel lehet pakolni akármilyen alkalmazást. Ha nekem megvan már a Windows-környezetem, miért dobjam ki az ablakon? -
#12086
Peter Kiss
őstag
Speeedfire
#12084
Peter Kiss
őstag
válasz
Speeedfire
#12084
üzenetére
ASP-ről nem is volt szó, de mit tud akármelyik PHP-s MVC rendszer, amit a .NET nem tud, helyből, mindenféle kiegészítő nélkül? Melyik alatt van Entity Framework vagy NHibernate? Melyik keretrendszer/nyelv kódbiztonsága a nagyobb?
-
#12082
Peter Kiss
őstag
trisztan94
#12081
Peter Kiss
őstag
válasz
trisztan94
#12081
üzenetére
ASP.NET MVC-ről váltani? Mi indokolja ezt?
-
#12069
Peter Kiss
őstag
CSorBA
#12067
Peter Kiss
őstag
-
#11915
Peter Kiss
őstag
coco2
#11914
Peter Kiss
őstag
-
#11897
Peter Kiss
őstag
coco2
#11895
Peter Kiss
őstag
Mi lenne, ha nem a WAMP-ot használnád? IIS + PHP 2 perc alatt telepíthető (Windows XP és régebbiről nem nyilatkozom), adatbázist meg telepíteni se kell, ha pl. MySQL-ed van, akkor abból van "portable". Esetleg, ha ez nem fekszik, XAMPP vagy kézzel összelegózod az összetevőket.
-
#11891
Peter Kiss
őstag
Lacces
#11890
Peter Kiss
őstag
válasz
Lacces
#11890
üzenetére
A PHP ad rá "keretet" (http://php.net/manual/en/session.customhandler.php), több gyakorlatilag nem is kell, mert onnantól egyértelmű, mikor mit kell csinálni, a megvalósítás pedig már nagyban függ attól, mi van a rendszer körül.
-
#11889
Peter Kiss
őstag
Lacces
#11888
Peter Kiss
őstag
válasz
Lacces
#11888
üzenetére
Bármikor célszerű lehet, ha nagyobb kontrollt szeretnél a session-ök fölött (néha a biztonságot is említik itt), de számolni kell a remote call költségeivel, viszont, ha több alkalmazás függ elvileg azonos session-öktől, akkor kötelező adatbázisba (vagy más tárolóba) központosítani mindent (ugyanez ll arra is, ha az alkalmazást elosztott környezetben szolgálod ki több webszerverről).
-
#11879
Peter Kiss
őstag
Swifty
#11878
Peter Kiss
őstag
válasz
Swifty
#11878
üzenetére
Sebesség: talán az enyém gyorsabb.
Ez a premature optimization. Nem tudom megmondani, igaz lehet-e, szerintem nem/mérhetetlen különbség.Memória használat: biztos, hogy kevesebb memória kell az enyémnek.
Téves, alapból nem lehet biztos.
- felolvasod az egész fájlt egyszerre, bent is tartod a parse végéig a memóriában
- parsolt adatokat értelem szerűen szintén bent tartod ($tables, második foreach-ben már talán a GC kitakarította a felolvasott cuccokat), emellett az első megoldásodban háromszor használtál ternary operátort egymás után, ami pontosan 2 db teljes tömbmásolást jelent. Ehhez jön, hogy ez borzasztó drótozott megoldás volt.
A kódod fut 5.3-as PHP verzióbál régebbin is, ott nem volt még normális szemétgyűjtés, szóval veszélyes lehet.Hossz: az enyém rövidebb.
Csak nem lehet elolvasni.
Átláthatóság: egyén függő. Ki mit ismer jobban.
Jó OO kódot mindenki elolvas, mert értelmes, egyszerű elemekből áll.Bővíthetőség/kiterjeszthetőség: Athlon64+ kódja könnyebben származtatható. Az enyém "direkt" kód erre a problémára.
Az enyémben a parser szar, legalább egy absztrakció hiányzik.Hibakeresés: egyén függő. Talán a kód hossza miatt mondanám, hogy az enyémben könnyebb.
@ operátort használsz, szerinted azzal mennyire egyszerű a hibakeresés?---
@cucka: Ez már legalább olvasható, könnyen szétszedhető az említett két darabra. A resource létrejöttének az ellenőrzése tényleg kellene.
---
Érdekes, hogy csak én olvastam fel CSV-ként.
-
#11869
Peter Kiss
őstag
Sk8erPeter
#11868
Peter Kiss
őstag
válasz
Sk8erPeter
#11868
üzenetére
Ki tudják törölni a felesleget.
-
#11867
Peter Kiss
őstag
Sk8erPeter
#11863
Peter Kiss
őstag
válasz
Sk8erPeter
#11863
üzenetére
És akkor most menjek a modkerbe? Menjen már most valaki más, mindig én vagyok a hunyó.
Vagy előtte még megvitatjuk, mit szabad és mit nem kérdezni? Ezt meg szabad egyáltalán kérdeznem? Mit tettem?! -
#11862
Peter Kiss
őstag
cucka
#11856
Peter Kiss
őstag
@cucka
"~2 éve nem is fejlesztek php-ban" - így egy kicsit világosabb, miért írtad azokat, amiket.
"Na, hát csak kibújt a szög a zsákból." 
---
@Swifty
Az valóban nem érdekes, hogy újoncként vagy itt, vagy nem, az annál inkább, ahogyan bevágódtál a beszélgetésbe.Sokkal jobb így, rengeteg off-fal ez a topik, nem? Igazán barátságos lett!
-
#11851
Peter Kiss
őstag
Swifty
#11850
Peter Kiss
őstag
válasz
Swifty
#11850
üzenetére
Igen, valóban kötődik hozzá, de vajon egy webszerver vagy a programozástechnika kötődik-e hozzá jobban (esetleg a második egyáltalán nem?), nehéz kérdés.
Ha jól rémlik, egy felvetődött problémára adott konkrét megoldás-válasz kombinációm indította el mások elméletgyártását, ennek következtében tűzzel-vassal védtem az enyém, és ez így is lesz. Volt már hasonló, akkor is leugattak (igen, neked is sikerült *), és ez nem is fog változni, következőnél újra le fog ez játszódni.
(Ágyúval verébre dologról jutott eszembe, ki csinált ilyesmit (tömbbe fogott össze pl. SQL query egy rekordját):
$user = array("ID" => "1", "Name" => "Bruce Wayne");
Ettől nem értelmesebb egy User osztály, ami, ha csak POPO is, de már értelmesebbé teszi az összes kódrészletet, ami használja?)
* azzal, hogy megkérdezted "mi a f*szt keresel itt", plusz kötözködésként nevezted meg az érvekkel alátámasztott nézeteimet, míg mások annyit mondtak, "felesleges bonyolítás" (ezért is mennyit fogok még kapni vajon).
-
#11842
Peter Kiss
őstag
Swifty
#11834
Peter Kiss
őstag
válasz
Swifty
#11834
üzenetére
Amennyiben ez PHP topik, akkor nem szeretnék látni semmit sem, ami MySQL vagy Apache (és hasonló jellegű) témával foglalkozik, köszi mindenkinek!
Nem tudom, mennyire vagy benne a témában, de egy idő óta (segítek: utoljára arról volt szó, mennyire kell ráállni PHP-ban az iobjektum orientáltságra, hogyan építsük fel a kódjainkat, hogy ne szívjunk nagyot véletlenül se, ilyesmi) a tiéd volt az első off topik hozzászólás, amiben senkinek sem segítettél, illetve nem a PHP-tól beszéltél. Csak azért, hogy lekiabálj valakit (főleg ilyen alapon), nem kell írni.Látod, most bekattintom az off topikot.
-
#11833
Peter Kiss
őstag
cucka
#11832
Peter Kiss
őstag
Szkriptnyelvség: behányunk valamit valahová és valami kijön, ezt lehet könnyen levetkőzni.
Lambdák vannak típusos nyelvekben is, .NET-be egészen durván jelen vannak.
Ezt az általánosítást ne ferdítsd már el a hülyeség irányába.
Egyedi szoftvert is kell általánosítani, mert különben túl bonyolult lesz a megvalósítása, ez kimerülhet pl. egy IStatus interface egy metódusában is, de jelen van, mert kell.Nálam az a keretrendszer, amivel nem lehet dolgozni, szarnak minősül. A "jól van megírva" dolognak két oldala van, maga a keret kódja penge, vagy az, ami kívülről lehet látni, mivel keretrendszert nem azalapján ítélünk meg, mi van benne, így a külsőleg látható elemekből kell döntést hoznunk arról, jó-e vagy sem.
Utolsó bekezdéshez annyit, hogy idézted a mondandó felét, illetve a kérdésedre még ebben a kis részben is megvan a válasz.
-
#11830
Peter Kiss
őstag
DerStauner
#11827
Peter Kiss
őstag
válasz
DerStauner
#11827
üzenetére
Vannak rá kész lib-ek, szóval nem az. Google a barátod.
-
#11825
Peter Kiss
őstag
Peter Kiss
őstag
Számomra itt a beszélgetés folyamán kicsit úgy tűnik, mintha két dologról lenne szó: az egyik, hogy megoldunk egy problémát, azt hogyan programozzuk le, a másik, hogy előbb megépítjük a környezetet, és azt hogyan programozzuk le. Nem tudom, lehet, hogy nekem tűnik így. Mindegy, tegyük túl magunkat a felhozott kódolási anti-pattern-eken:
@Soak: Abban az esetben, ha van egy üzleti problémánk, akkor semmiféle képpen sem fogunk attól többet fejleszteni, mint amennyi szükséges. Vegyük azt, hogy egy teljesen új dologról van szó, nem kell régi vacakkal foglalkoznunk, és emellett van egy keretrendszer (ez lehet bármi, .NET, Zend Framework, mindegy), amiben dolgozunk. Tételezzük fel, hogy tiszta a megvalósítandó üzleti logika, gyakorlatilag csak fejlesztenünk kell. Hogyan érdemes ezt elkezdeni?
Írunk teszteket, amelyek lefedik nagyvonalakban, amit szeretnénk kivitelezni, ilyen fázisban még a teszt is ocsmány lesz, mert csak körbelőjük, mit is szeretnénk. Ha ez megvan, megírjuk az első kódot, teszt, kódírás/refaktor/újabb teszt, innen már tudjuk, TDD.
Ha így fejlesztünk, akkor észrevetjük, hogy az elején nagyon sokat kódolunk (leginkább a tesztek megírása miatt, nem az interface-ekre (vagy akár a mock-okra, stub-okra) gondolok, mert az relatíve kevés időt vesz igénybe), ellenben automatán tudunk mindent tesztelni (UI-t nehézkes ilyen szempontból, törekedni kell arra, hogy ott a lehető legkevesebb hiba fordulhasson elő). Mikor jó egy unit teszt?
Ha azt és csakis azt teszteli, amit kell, gyorsan lefut, és egyértelmű a leírása. Ahhoz, hogy a teszt ilyen legyen az kell, hogy maga a tesztelendő kód is felvegye ezt a jelleget, normálisan megírt OO kód nélkül ez lehetetlen.
Persze, a unit tesztek önmagukban kevesek, hiszen attól, hogy egy-egy rész jól működik, a big-picture még lehet, hogy sz.rt se ér, ehhez integrity test-ek kellenek.
Mit látunk ezen a ponton?Összevetve egy nem TDD-s csapattal, sokkal több időt töltöttünk mindenféle kód (production + ami a teszthez kell [és a világos megoldáshoz!]) megírásával, viszont sosem kell amiatt aggódnunk, hogy nagy hibát vétenénk, ha kalapálunk valamit, segítenek a tesztek. Hibát keresni is sokkal gyorsabb lesz, hiszen rengeteg dolgot fejlesztési időben ki tudunk szűrni, illetve a kiadott verzióban is kevesebb lesz az utólagos hibák száma.
Azt már említeni se merem, hogy léteznek olyan eszközök, amelyek kódolás alatt automatán futtatják a teszteket, így mindig up-to-date lehetsz (PHP-hoz nem tudom, van-e ilyen).
-
#11821
Peter Kiss
őstag
cucka
#11817
Peter Kiss
őstag
Nem írtam le a szkriptnyelveket, de a PHP pont olyan, ami simán le tudja vetkőzni magáról a szkriptnyelvségét, és klasszul lehetne használni, csak épp az elterjedtsége ellenére is kevesen próbálkoznak kiaknázni minden lehetőségét.
Mit vett át funkcionális nyelvekből?
Java-ban nem szeretnék fejleszteni, .NET-ben lehetőségem van minden nap (@Soak: termelő vállalatnál kell ügyviteli és termeléstámogató szoftvereket fejleszteni, sajnos eddig szinte csak legacy [és szar] kódokat kellett támogatni). De akkor végül is azt mondod, hogy PHP-val hegesszen mindenki úgy, hogy csak az adott problémára koncentráljon, legyen kész, és rendben is van a dolog?
Overgeneralization-től még nagyon messze vagyunk, nyilván nem kell minden üzleti problémára egy mindent tudó solver-t írni, de azért arra oda kell figyelni, ne legyen semmi sem túlságosan összedrótozva. Premature optimization valóban veszélyes lehet, de igazából csak azt fenyegeti, aki rettentően unatkozik, és valamilyen oknál fogva előre látni véli a rossz teljesítményű pontokat.
Azért, mert dolgoznod kellett egy rosszul megírt keretrendszerrel, még nem jelenti azt, hogy mindenhol rémeket kell látni.TDD-hez nem elég a modularitás, mert simán tudsz olyan kódot írni (OO vagy nem OO), amit egyszerűen nem bírsz tesztelni, vagy nagyon nagy mocskot kell csinálnod, ezzel szemben egy interface-ből stub-ot/mock-ot hegeszteni nem nagy mutatvány. (Smoke tesztnek tényleg nincs köze az OO/nem OO dologhoz (bármit lehet rosszul tesztelni), de nem is azért írtam.)
-
#11815
Peter Kiss
őstag
cucka
#11808
Peter Kiss
őstag
Tudom, hogy a PHP script nyelv, de az is baj, hogy ebből nem bír kinőni, pedig egyre komolyabb dolgokra képes, illetve a Zend is próbál mindig jobban arra sarkallni, hogy objektumokkal dolgozzunk. Ezt annyira komolyan gondolom, hogy hobbiként fejlesztett rendszeremben a super global tömböket se kell használni.
Emellett nem is szeretek úgy gondolkodni, hogy van egy feladat, aztán azt a lehető legegyszerűbb, legrövidebb módon oldjuk meg, mert mi történik akkor, ha jön egy hasonló? Duplikálás. Nyilván a fenti kérdés egy kis dologra vonatkozott, de, ha esetleg van valami cifra folytatása, már megérhette, illetve abban az esetben, ha több helyen kell valamit használni (itt például a táblázatos történetet, a parser sántít).
Azt mondom, nem érdemes kicsiben gondolkodni.Mikor van hatalmas előnye annak, ha mindent a lehető legabsztraktabb módon írunk le? Akkor, ha tesztelni is akarjuk a kódunkat! Ha valaki fejlesztett már TDD módon úgy, hogy nem csak a covarege-et nézte, és gyártott a smoking test-eket, akkor tudhatja, hogy a jó tesztek kikényszerítik a fentebb látható kódstruktúrát, mert egyszerűen kell.
Mindenki elindulhat a saját útján, én megmutattam egyet, én hogyan csinálnám, akinek tetszik, használja, akinek nem, az ne (csak nehogy egyszer én legyen a projektvezetője
).---
#11809
"amennyiben valaki már érti" - ez a varázsgondolat
Ha jó a kód, ordít magáról, hogyan kell használni. Nyilván, a PHP-nak itt vannak korlátai, de azért nem olyan rossz a helyzet. A fenti kódra szerintem senki sem tudná azt mondani, hogy nem tudja használ (a parser itt is kivétel, annak még bőven alá kellene dolgozni).---
#11810
Nem vagyok programozó, szoftverfejlesztést szeretem, illetve az architect jellegű kérdésekkel, megoldásokkal foglalkozni.---
#11814
Egyik tervezési mintát sem kell vakon követni, hiszen nem előírások, csak megfigyelt jó fogások, vagy épp rosszak. Amit mindig be kell tartani: egy osztály/metódus egy problémát oldjon meg, mindig mondja el, mire van szüksége a működéséhez, és minden a lehető legabsztraktabb maradjon. Ha valaki ezeket szemmel tartja, nagy baj nem történhet. -
#11807
Peter Kiss
őstag
Sk8erPeter
#11806
Peter Kiss
őstag
válasz
Sk8erPeter
#11806
üzenetére
Procedurálisan nem lehet szép kódot írni, mert minden lóg a levegőben (illetve a globális hipertérben). Ilyen esetekben maximum egy-egy függvény feladatát lehet a minimálisra szorítani, de rendszer nem lesz abból se. PHP esetében pedig még az is kihullik, hogy típusellenőrzést lehessen jól láthatóan végezni (kikötöda paraméter típusát a metódusok paraméterlistájában).
Az OOP nem tudja garantálni a normális kódot, mivel nincs normálisan definiálva (lehet egyáltalán?), hogy mit is jelent az OOP (sokaknál kimerül a class-ok használatában, de ekkor van az, hogy class oriented lesz a design).És nem baromarcú, csak keveset tud.
-
#11805
Peter Kiss
őstag
Louro
#11804
: 
), ez szintén nem kevés idő, aztán meg vagy működik vagy nem. Jönnek még igények, vagy van modul, vagy nincs, leküzdjük (idő, pénz, sárm), de pl. amikor jönne egy olyan, hogy auditálva kellene minden (mert az egyik alkalmazott csinált valami f.szságot), akkor máris meghaltunk, mert általában ez senkinek sem jut eszébe (modulkészítőknek sem). Ja, igen, riportok is kellenének, legyen benne minden, ami csak elképzelhető, mert XY összefüggést akarom látni. Oké, ott tartunk, hogy kivitelezhetetlen a jelenlegi rendszerrel, újat kell építeni. Mennyibe is kerül ez? Hát nem 2 millióba. Alapból egy nagyon komoly üzleti döntés, de akkor, ha még elegendő pénz sincs, még nagyobb súlyú.
Új hozzászólás Aktív témák
Hirdetés
- Házimozi haladó szinten
- Házimozi belépő szinten
- OLED TV topic
- Óvodások homokozója
- Milyen asztali (teljes vagy fél-) gépet vegyek?
- Milyen processzort vegyek?
- Milyen videókártyát?
- ldave: New Game Blitz - 2025
- sziku69: Fűzzük össze a szavakat :)
- Luck Dragon: Asszociációs játék. :)
- További aktív témák...
- LG 65C3 - 65" OLED evo - 4K 120Hz 1ms - NVIDIA G-Sync - FreeSync Premium - HDMI 2.1 - PS5 és Xbox!
- Lenovo S10-2 Intel Atom retró csajszis netbook eladó
- Intel X540-T2 dual-port 10GbE RJ45 hálózati vezérlő (10Gbit, 2 port, áfás számla, garancia)
- Telefon felvásárlás!! iPhone 12 Mini/iPhone 12/iPhone 12 Pro/iPhone 12 Pro Max
- Apple iPhone 14 Pro 128GB Kártyafüggetlen, 1Év Garanciával
Állásajánlatok
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest
Cég: Promenade Publishing House Kft.
Város: Budapest