Új hozzászólás Aktív témák
-
Sk8erPeter
nagyúr
válasz
Thrawnad #18380 üzenetére
A mysql_* kezdetű függvényeket felejtsd el, elavult, nem támogatott, és amúgy is 2016 van, használj PDO-t vagy MySQLi-t, ÉS paraméterezett lekérdezéseket, változóbehelyettesítés (mint nálad a
nap='$ma'
) a query-ben egyáltalán nem szabad, hogy szerepeljenek. Ez az első lépés, még ha kényelmetlen is lesz az átírás, ez már szinte kötelező (tisztább, szárazabb, biztonságosabb érzés). -
Sk8erPeter
nagyúr
"Ezek működnek. De egyik sem scriptet hív."
Ez mondjuk elég fontos lehet, hogy van már olyan, ahol műxik. Van futtatási jogosultsága annak a júzernek, aki ezt futtatni próbálja? Pl. az a júzer benne van olyan csoportban, akinek van joga ehhez, vagy van explicit joga a futtatásra?
Ha nincs, az para."Viiszont amin most túrázok, az sem scriptként meghívva, sem a konkrét parancsot meghívva shell_exec-cel, nem megy."
Nem túl konkrét, hogy min túrázol. -
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
DiabloCorsa #18160 üzenetére
DOMDocument::loadXML-lel betöltöd az XML-fájlt, getElementsByTagName segítségével a tageket tudod betölteni, bejárod az így kapott eredményhalmazt, getAttribute segítségével pedig az attribútumok értékeit tudod lekérni. Az utóbbi oldalon a kommentek között egy egész értelmes példakódot is találsz.
Írj, ha ez alapján sem jön össze. -
Sk8erPeter
nagyúr
válasz
Speeedfire #18155 üzenetére
Sejtem, hogy ilyesmi módon akarja futtatni a scriptet, csak az nem derült ki, hogy a kép elérési útja pontosan mitől nem jó, és hogy azonos szerveren találhatóak-e a képek és maga a script - ha nem, akkor a relatív elérési út nyilván nem lesz jó, meg engedélyek is közbeszólhatnak, ezért kérdezem tőle, hogy pontosan hogyan próbálkozik, hátha így gyorsabb lesz az oknyomozás.
-
Sk8erPeter
nagyúr
válasz
fordfairlane #18116 üzenetére
Nem árt felhívni a kolléga figyelmét, hogy ez csak akkor működik, ha a második és harmadik tömbnek legalább annyi eleme van, mint az elsőnek. Persze az elvárt, hogy mindnek ugyanannyi eleme legyen.
(#18126) deedetette:
Ez általános algoritmizálási kérdés, érdemes végiggondolnod, hogy oldanád meg pszeudokóddal.
- az első feladat esetén növelgetsz egy változót, ha 60-nál nagyobb számot találsz
- a második feladatnál pedig tárolnod kell a ciklusban való rohangászás során az addig megtalált maximális számot (első legnagyobb), illetve a második legnagyobbat, és hasonlítgatni a ciklusban épp vizsgált új tömbelemmel, meg az eddig megtalált első és második legnagyobb számmal (nagyobb-e, mint az addigi második legnagyobb szám, illetve még kisebb-e, mint az első legnagyobb). Persze mindig frissítgetned kell az első/második legnagyobb számot is, ha találsz azok korábbi értékeinél még nagyobbat a ciklusban való lépegetés során. -
Sk8erPeter
nagyúr
válasz
DNReNTi #18105 üzenetére
Amúgy a PHP Stormnak annyiból teljesen igaza van, hogy az a jó konvenció, hogy a boolean változók getterei is-zel kezdődnek (isXY()). A getXY() elnevezés kevésbé tűnik szépnek kódolvasáskor. (Pl. mittomén, leírva a $user->isAdmin() sokkal jobban mutat és logikusabban olvasható, mint pl. a $user->getIsAdmin().)
Mondjuk az isIsDraft tényleg hülye név, ezt igazán felismerhetné a PHP Storm, hogy épp is az eleje a változónak is... -
Sk8erPeter
nagyúr
válasz
DNReNTi #18102 üzenetére
Szerintem ez jó kiindulási alap:
https://gist.github.com/Maaiins/0d39341d6cd61718e8de
Itt például a function ${GET_OR_IS}${NAME}() részt átírhatnád function get${NAME}()-re, hátha ez megoldja. -
Sk8erPeter
nagyúr
válasz
#68216320 #18085 üzenetére
Az első mindenképpen ocsmány megoldás, mivel így nem válik szét a megjelenítés és az adatok validálása, feldolgozása, adatbázisba írása (meg hasonló műveletek). A form kiírásának semmi köze nem szabadna, hogy legyen ahhoz, hogy aztán mit kezdesz az adataiddal. Szóval mindenképp válaszd külön a kettőt. Ezért szokás szétválasztani a különböző rétegeket (lásd MVC-szemlélet és társai).
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #18061 üzenetére
"error-t dobott arra, hogy objektumot nem akar tárolni és azt hittem, hogy nem lehet"
Az elég durva lenne... Egyébként nem valószínű, hogy az volt a hiba, hogy objektumot "nem akar tárolni", hanem valami ennél PICIKÉT konkrétabb és értelmesebb hiba fordult elő. -
Sk8erPeter
nagyúr
válasz
martin66 #18029 üzenetére
"A baj, pedig az, hogy ez mögé illeszti be a plugin magát"
Nem a the_content() függvényhívás részeként kerül kiírásra?A WordPress lelkivilágának ismerete nélkül elég nehéz erre a kérdésre válaszolni, igazából végig kellene debuggolni, hogy hol kerül beszúrásra a plugined tartalma, meg érteni kéne, az általad idézett rész, tehát hogy "Add WP filter for automatic shortcodes" mire vonatkozik (milyen automatic shortcodes, mi az?), mert nem tűnik túl logikusnak, hogy egy SZŰRŐ adjon hozzá tartalmat egy posthoz (ettől még persze működhet így a WordPress
), látni kéne a plugined kódjának többi részét, hátha abból összeállna a kép, mert az általad berakott kódrészletek és a screenshot nem sokat segít.
Egyébként ahol tuti értenek hozzá, az a WordPress Development Stack Exchange site: http://wordpress.stackexchange.com/
Itt is megkérdezhetnéd - angolul -, itt sokkal valószínűbb, hogy belátható időn belül kapsz hathatós segítséget.(#18031) PumpkinSeed:
Pályakezdőként is nyugodtan lehet jelentkezni megfelelő Java-tudással egy junior pozícióra.(Ezt az első bekezdésedre írom.) Persze ez más nyelvre is igaz. Jó esetben az ilyen szinten elvárható tudást nézik (legyenek stabilak az alapok, értsd, mi miért működik úgy, ahogy, legyenek azért ismereteid a többszálúságról is, stb.), meg a képességet, hogy alkalmas vagy látszólag arra, hogy aztán később a cég jó szakembere legyél, ha belejössz. Megértem, hogy neked nem jött be a nyelv, van ilyen, a lényeg, hogy abban fejlessz, ami közelebb áll hozzád.
Egyébként az oktatás színvonalával kapcsolatos felháborodás természetesen jogos, mert elvárható lenne, hogy adott egyetem/főiskola/OKJ-s képzés/stb. az embernek valóban naprakész (!), használható tudást adjon, sajnos ritkán mondható ez el, és sajnos el kell fogadni, hogy az ember kénytelen kőkeményen képezni saját magát, így kell áthidalnia a problémát, erre utaltam.(#18032) mobal:
Nem tudom, hogy elolvastad-e az egész hozzászólásomat.Éppen ott van, hogy - idézem - "Ettől még egy egyetem elvégzése sem garancia semmire"...
De azért ha valaki végigcsinál egy nevesebb egyetemet, az talán annyira utal, hogy képes valahogy átszenvedni magát a megpróbáltatásokon.
Egyébként nem értem, miért kellene befejezni a témát, még ha OFF-ba is kell rakni, ez programozáshoz kapcsolódó beszélgetés, nem pedig a karácsonyi bejgliről dumálunk, és bőven érintheti a PHP-fejlesztőket is (mint a mellékelt ábra mutatja), és így megoszthatjuk egymással a gondolatainkat, ettől is pörögnek a topicok. (Meg amúgy mostanában vagy csend van, vagy érdektelen kérdés sajna.) -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #18027 üzenetére
"meg is értem, hogy nagy a kereslet Java szakember irányába, mert abból tényleg szinte nulla a szakember"
Ekkora hülyeséget hogy lehet leírni?Már hogy lenne nulla szakember Javából? Lehet, hogy Te nem találkoztál komoly, hozzáértő szakemberekkel abban a jelenleg még kicsi világban, amiben szakmai téren mozogsz, de rengeteg ilyet találni - ha már itt tartunk, inkább nehéz kifogni jó szakembert PHP-s területről, mint Javásról. Nem véletlenül fizetik meg jól. Nyilván itt is bőven vannak kóklerek, mint mindenhol. És ugyanez igaz lehet C#-vonalra (nagyon jó és nagyon rossz szakemberek is vannak, és jók tudnak lenni a fizetések), felesleges is azon rugózni, melyik a jobb. Ott dől el igazán a kérdés, hogy valaki melyikre állt rá jobban - aztán lehet később váltani, csak nehézkes (meg ugye az adott nyelvből tudsz felmutatni igazán komoly szakmai tapasztalatot, és akárki akármit mond, hogy nem a nyelv számít, hanem az algoritmusok, meg a programozási szemlélet, blabla, ez a gyakorlatban bullshit, mert igenis számít, hogy mennyire vagy ráállva a nyelvhez kapcsolódó infrastruktúrára). Sőt, egyébként C/C++ területen is van kereslet, és ott is komoly fizetéseket el lehet érni, mivel ezek sokszor kapcsolódnak speckó területekhez (pl. beágyazott fejlesztés, ilyesmik), meg léteznek jó Python-állások, stb., de ha megnézed az állásajánlatokat, akkor tényleg brutálisan sok Javás kínálat van.
Egyébként uncsi picit visszatérően olvasgatni a topicokban, hogy sokan mindig valaki másokat hibáztatnak azért, ha nem sikerült kiképezni magukat valamilyen nyelvből. Igen, az oktatás többnyire szar, ritka a pozitív kivétel, ezért kell autodidakta módon tanulni, jó forrásokból, és rengeteg energiát, időt, szorgalmat kell rááldozni, és folyamatosan képezni magadat, utánanézni, megérteni, ha valamit nem látsz át. Ez ilyen, nem fogja megtanulni helyetted senki. (BTW nekem sem tanította senki a webfejlesztést, és nem a BME-t szidtam azért, amiért elhanyagolható a jó webfejlesztés-oktatás (konkrétan ASP.NET-hez kapcsolódóan találkoztam csak ilyennel egy szabvál keretében).)
Hogy egy olyan szeletével találkoztál a Java-programozásnak, ami épp az adott területhez kapcsolódó gyengébb infrastruktúra (keretrendszerek, fejlesztőeszközök, és minden egyéb, ami befolyásolja a fejlesztést) miatt nagyon nagy szopókör volt, vagy rosszul választottad meg az eszközöket, az még önmagában egyáltalán nem minősíti magát a nyelvet (mert arról nem írtál, hogy maga a nyelv miért lenne hibás ezért).(#18024) szupermacs:
Annyiból szokott számítani a szakmailag RELEVÁNS papír, hogy legalább annyiról tanúskodik, hogy képes vagy magad átvergődni különböző megpróbáltatásokon, tehát képes vagy tanulni, megoldani problémákat. Ettől még egy egyetem elvégzése sem garancia semmire, olyan ocsmány munkát végző emberekkel lehet találkozni még komoly egyetemeken is, hogy elkeserítő, de itt legalább szerencsére számtalan nagyon jó példával is lehet találkozni. Egyébként jó esetben állásinterjún úgyis kiderül, hogy mennyire lehetsz alkalmas a feladatok elvégzésére (azért írom, hogy "jó esetben", mert van, hogy élesben kiderül, hogy mégsem az igazi a munkavállaló, vagy épp az interjú menete van elcseszve, és az interjúztató szopatja feleslegesen a munkakeresőt).
A Python tanulásnak egyébként azért lehet jó, mert hozzászoktat a megfelelő kódstrukturáláshoz (kényszerítve vagy az indentálásra (behúzásra)), meg viszonylag gyorsan tanulható, és nem túl nehéz belekezdeni sem a kódolásba (mint általában a scriptnyelveknél).(#18001) PeachMan:
Valami ilyesmi, de azért a user is tudja módosítani a saját avatarját.De maga a feltöltés menete nyilván ne a felhasználó osztályában legyen implementálva, csak áthív egy másik osztály megfelelő metódusára.
-
Sk8erPeter
nagyúr
válasz
#68216320 #17999 üzenetére
Nem, nem az a baj vele, hogy nem "hordozható", hanem hogy túl sok mindent akar csinálni az osztályod - éppen ahogy j0k3r! írta, és tök igaza van -, olyat is, ami nem tartozik az ő hatáskörébe, és hogy idézzem a kollégát, "A te esetedben a User osztálynak csak annyi dolga kellene, hogy legyen, hogy egy ilyen entitást leírjon". Tehát ha van egy felhasználó osztályod, akkor az írjon le felhasználóra vonatkozó attribútumokat (milyen tulajdonságai vannak) és műveleteket (miket tud a felhasználó csinálni), de ne lehessen vele tök más felhasználókat is szerkesztgetni, törölgetni, hozzáadni, mert az már nem tartozik rá, hogy az adatbázisban milyen egyéb felhasználók vannak, főleg nem szabad itt, hogy azokat még kezelgetni is tudja. Ilyesmire tényleg egy külön osztály való, aki kezeli ezeket az entitásokat egy "magasabb" szinten, és ő tudhat is róla, hogy milyen felhasználók vannak.
-
Sk8erPeter
nagyúr
válasz
#68216320 #17993 üzenetére
Ez így tényleg ronda, eleve kerülendő globális változókat használni, de miért nem passzolod át egyszerűen akár a konstruktorban, akár valamelyik metódus paramétereként a szükséges változót?
(#17989) mobal:
Jól hangzik elméletben, de a szolgáltatók többségénél még mindig nem MariaDB van, hanem MySQL. -
Sk8erPeter
nagyúr
Elméletileg nem, aztán a gyakorlat lehet, hogy adott esetben mást mutat, de ha még jobb esetekben nincs is probléma az átállással, gondolj bele, a weben fent lévő cuccok közül vajon hány készülhetett olyan módon, hogy ott nem jelent gondot egy komolyabb váltás... hát olyanokból arányaiban elég "kevés" lehet (a nagy többséghez képest).
-
Sk8erPeter
nagyúr
válasz
Speeedfire #17985 üzenetére
Végül is a MariaDB sem ismert a "kommersz körökben", akármi legyen is az.
A hostingcégek többsége még mindig a MySQL-t nyomatja érthető módon, mivel pl. a szintén népszerű PHP-alkalmazások többsége is erre alapoz, ez az örökség még elég sokáig fent fog maradni, nehéz elképzelni hirtelen váltást, mert így menne a kukába az összes régi webes cucc is, ami MySQL-re épített. Ha viszont alternatívák után kell nézni, akkor a PostgreSQL elég népszerű, az nem valószínű, hogy ennél a MariaDB népszerűbb lenne, főleg már csak amiatt sem lehet az, mert utóbbi JÓVAL újabb, a PostgreSQL-re rengeteg alkalmazás épül. Persze abban igazad van, hogy valószínűleg kevésbé fájdalmas az átállás MariaDB-re MySQL-ről, mint pl. PostgreSQL-re, gondolom erre gondoltál.
-
Sk8erPeter
nagyúr
válasz
Speeedfire #17983 üzenetére
Nem azt kérdeztem, hogy miért MariaDB a MySQL helyett, mert az értelemszerű, hogy "jobb", azt kérdeztem, miért pont MariaDB, miért nem mondjuk PostgreSQL (vagy más). De pont ezt így le is írtam.
"Mármint MySQL oké, hogy nem, csak miért MariaDB, miért nem PostgreSQL, vagy ilyesmi"
-
Sk8erPeter
nagyúr
válasz
GGAllin #17974 üzenetére
"Linux(Xubuntu) alól akarom futtatni a Wamp Servert de valami nem jó"
Jaja, az eléggé nem jó, hogy Windows-cuccot akarsz Linuxra erőltetni, olyat, aminek ráadásul tökéletes alternatívái vannak Linux-oldalon. Érdekelne, hogy mi az oka?Egyébként a Wine-emulációk még mindig nagyon korlátosak, még ha egész sok Windows-progi fut is így Linuxon, az esetek többségében tapasztalható valamiféle hiányosság. Persze nem is elvárható, hogy minden menjen.
(#17979) mobal:
Miért épp az?Mármint MySQL oké, hogy nem, csak miért MariaDB, miért nem PostgreSQL, vagy ilyesmi.
Azért, mert újabb, vagy csak mert MySQL-utód, vagy van valami egyéb oka, pl. szakmai vagy simán ízlésbeli szempontok? (Csak kíváncsi vagyok, félre ne értsd, nem azért kérdezem, hogy aztán vitatkozzak, hogy hádepedignemis, csak érdekel.
)
-
Sk8erPeter
nagyúr
válasz
The DJ #17957 üzenetére
Én a helyedben megkérdezném itt:
Joomla Stack Exchange
http://joomla.stackexchange.com/
Biztos vannak olyan arcok, akik még ilyen ősrégi fosokhoz is értenek, mint az 1.5-ös Joomla. Vagy érdemibbet tudnak mondani, mert ahogy elnéztem az itt aktív közösséget, senki nem ért a Joomlához (és ez javukra legyen mondva).
-
-
Sk8erPeter
nagyúr
A file függvény fájlnevet vár első paraméterül, Te pedig a $current változót passzolod át neki, ami a beolvasott fájl tartalmát, meg az ahhoz fűzött további adatokat tartalmazza. Ez így eleve nem lesz jó.
Azt írod, hogy fopen($path), de közben a $path változó értéke nincs beállítva (vagy legalábbis itt nem osztottad meg velünk). Ha a kódodból és hsz.-edből jól vettem le, az eredeti fájlt szeretnéd módosítani úgy, hogy hozzáírsz még adatot, tehát akkor az általad $file-nak nevezett változót kellene átadnod neki. De szerencsésebb lenne ezt inkább $filename-nek elnevezni, hiszen épp csak egy fájlnév, nem a fájlt reprezentáló objektum vagy ilyesmi (tehát félrevezető a név).
Az fopen két paramétert vár, csak egyet adtál meg. Ez a hibaüzenetekből egyértelműen kiderül, ha nincsenek kijelezve a hibaüzenetek, fejlesztés idejéig igazából kötelező (hogy időben észrevedd, meg hogy ne legyen ilyesmi, hogy nem érted, mi van). Mivel csak írni szeretnél a fájlba, passzold át még neki a "w" paramétert.
Aztán a foreach-ben ha jól értem ilyen jó fáradt fejjel, ki akarod szedni a már meglévő sorokat. Na de aztán nem teszed bele igazából azokat az értékeket, amik "újak", csak kiszedsz - tehát pl. egy üres fájlnál nem írsz vissza a fájlba semmit. Így nem meglepő, hogy az egész nem is működik. -
Sk8erPeter
nagyúr
válasz
don_peter #17917 üzenetére
"Kiíratásnál pedig ezt:
localStorage.getItem("lastname");
Az oldal frissítése után nem ír ki semmit."
És ennek mégis mi a frászért kellene bármit is kiírnia?Nem tároltad el sehova a függvény visszatérési értékét, nem használtad fel sehol... mit vársz, mit kellene tennie ettől a sortól?
Szóval nem, nem jól használod.(#17910) don_peter:
"És igen, megfeledkeztem arról, hogy a PHP az szerveroldali megoldás bár ajax-al nyilván megoldható a textarea kiolvasása, de sokkal jobb és közelibb egy javascript."
Ennek a mondatnak mi értelme van? Az AJAX az Asynchronous JavaScript and XML-ből alkotott mozaikszó, szóval hogy miért választod külön a kettőt, az rejtély. Mi az, hogy "sokkal jobb"? Minél jobb? Mi az, hogy "közelibb"? Mihez képest van közelebb, és az miért lesz bárkinek is jó?Tehát: van a kliensoldali, böngészőfüggő mentés, meg a szerveroldali. Ha nem para, hogy böngészőadatok ürítésekor elvész az addig megírt piszkozat, vagy hogy egyáltalán böngészőfüggő a dolog, tehát nem folytathatja az emberke bárhol az addig megkezdett szövegét, akkor maradhat a kliensoldali tárolás. Ha nem szeretnéd, hogy klienshez, böngészőhöz kötődjön a tartalom, vagy hogy a böngésző oldalspecifikusan tárolt adatainak törlésekor elvesszen a tartalom, akkor küldd el a piszkozatot szerveroldalra, és ott tárold (lásd Gmail-piszkozat). Persze itt azért figyelj rá, hogy ne tudjon kismillió darab piszkozatot tárolgatni a júzer, hogy tömködje feleslegesen piszkozatokkal az adatbázisodat, mármint ha ez gondot jelent.
IP-cím változása hatására nem kell, hogy a session is megszűnjön, erre ismét jó példa a Gmail. Vagy a Drupal is így oldja meg. Nézz utána, hogy kell megoldani.
(#17905), (#17907):
"elmegy a NET"
Akarod mondani net. Ez a szó NEM egy mozaikszó! Nem értem, emberek miért írják csupa nagybetűvel, nem kell. Lásd ezt."COOKIE lehet járható út?"
Akarod mondani cookie. Ez sem mozaikszó."persze mehet egy kis ajax-al is a dolog"
Akarod mondani AJAX.Pont azt nem írod csupa nagybetűvel, amit meg kell?
-
Sk8erPeter
nagyúr
válasz
PowerBuldog #17903 üzenetére
Hát ez aztán rettentően értelmes feladat, ha tényleg azt kellett csinálni, hogy be kell olvasni egy XML-fájl tartalmát DOMDocumenttel, aztán úgy, hogy SEMMIT nem csináltál vele, csak simán kiíratni a tartalmat...
Remélem, csak Te értettél félre valamit, és nem ilyen retardált feladatot kaptál.
Mellesleg ez szinte semmiben nem különbözik a korábbitól, mi a frász értelme van ennek, hogy most csak annyit változtattál, hogy másképpen olvasod be, és beállítasz egy fejlécet is (mellesleg helyes, hogy beállítod)?Amúgy korábban nem véletlenül tanácsolta neked fordfairlane, hogy ellenőrizd már azt a nyomorult query stringet, hogy azonbelül az elvárt bemeneti paramétert megkapod-e egyáltalán...
-
Sk8erPeter
nagyúr
válasz
fordfairlane #17890 üzenetére
Pedig itt sztem igaza van Trisztánnak, valami feedback azé' legalább egy header formájában nem ártana.
(Még egy sima echózás is jobb lenne még exit előtt, mint egy tök üres lap hiba esetén, ami akármi mástól is lehetne (pl. fatal error elrejtett hibaüzenetekkel), kezdő jól beszophatja az ilyeneket, amikor elírja mondjuk a query stringet, vagy ilyesmi.)
(#17881) fordfairlane:
Hát igen, ez így elég jól hangzik, de 220 ezret akkor sem szánnék monitorra (csak ha fürdenék a lóvéban). Jelenleg elégedetten használok egy Dell P2414H-t, árkategóriáján belül az is igen jóféle (legalábbis az volt, amikor vettem), az én igényeimet szerencsére kielégíti, bár lehet, hogy azért, mert nincs is túl sok igényem.Csak a színhűség (kalibrálás megoldotta), meg a minimum 24" (el tudnék viselni mondjuk 27"-et...), plusz hogy ne legyen túlzottan széjjelvilágított, ronda feketéje a monitornak, meg persze ne legyen durva utánhúzása (alacsony késleltetés), legalábbis most ami eszembe jut (meg nyilván digitális csatlakoztatási lehetőségek).
Egyébként abszolúte elhiszem, amit írsz, hogy igényesebb szemnek feltűnnek ezek a zavaró tényezők, sok fanatikus nem véletlenül ragaszkodik a jobbfajta CRT-monitorjához. Örülök, hogy számomra ezek nem zavaróak, meg is őrülnék akkor minden monitortól, amihez oda kell ülnöm.Ha kicsit odafigyelek erre, még így is zavar pl. melóhelyen a 24"+19" monitorokból az utóbbi, ami távol áll az igényes monitortól (az is Dell, de az önmagában nem jelent semmit).
-
Sk8erPeter
nagyúr
válasz
fordfairlane #17867 üzenetére
Uhh, ez igen minőségi darab, de a 220 ezres ára miatt valószínűleg nem fogok rárepülni.
(Pedig jól jönne egy 27"-es a 24" mellé.)
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #17777 üzenetére
Pont most írta, hogy "A xampp\mysql\data\mysql\user.frm, user.MYD, user.MYI felülírása friss telepítésből származóval megoldotta."
-
Sk8erPeter
nagyúr
"persze hogy sql hívások set names nélkül, hogy törne le a keze aki írta a php jquery naptárat"
A többesszámot a hívásoknál nem értem, a SET NAMES 'valamilyen_karakterkészlet' (pl. SET NAMES 'UTF8' (aposztróf nélkül is működne itt amúgy)) utasítást egyszer kell csak kiadni, a csatlakozás után, és kész.
Persze lehet, hogy erre utaltál, csak félreérthetően hangzott.
(Ahogy a "php jquery naptár" is furán hangzik.)
-
Sk8erPeter
nagyúr
válasz
supercow #17761 üzenetére
"A másik részt nem értem."
Mivel odaírtad, hogy max="50", ezért a böngésző helyes implementáció esetén már vagy eleve a bevitel során, vagy a fókuszváltás/elküldés/stb. során jelzi a validációnál, hogy érvénytelen számot adtál meg, ergo nem is enged tovább, nem tudod elküldeni az űrlapot (csak ha trükközöl webfejlesztő panel segítségével, vagy ha például a böngésző nem is támogatja a HTML5-öt). Itt meg nem ez a cél, hanem a figyelmeztetés arra, hogy a felhasználó nagy számot adott meg - de ettől még egyébként elfogadható a nagy szám is, csak meg kell győződni róla, hogy a felhasználó tényleg azt akarta-e.
Igaz, a javasolt ellenőrzési módszer is csak kliensoldalon zajlik, tehát ez sem egy atombiztos megoldás, de lehet, hogy a kérdezőnek ez is elegendő, ez nem derült ki. -
Sk8erPeter
nagyúr
válasz
TigerCat #17736 üzenetére
"PHP, CSS5"
Hát lehetőleg a CSS5-öt ne írd bele, mert jelenleg olyan még nem létezik.Szerintem a HTML5, CSS3-ra gondoltál.
Amúgy nem Javascript, hanem JavaScript, nem Ajax, hanem AJAX (mozaikszó). Ezek hibás leírása zavaró lehet egy álláshirdetésben.
Mellesleg nem biztos, hogy érdemes ragaszkodni a PHP-hoz, nem az a webfejlesztés alfája és omegája. Más területekről is komoly szakemberek érkezhetnének.
Egyébként nem biztos, hogy érdemes úgy keresni, hogy valaki ne csak komoly fejlesztő, hanem egyben jó rendszergazda is legyen, mert bár lehet, hogy utóbbi feladatok közül a nálatok érdekeseket is lazán elvégezné (pl. a mailszerver beállítását), de mondjuk nem akar oprendszereket telepíteni (amire nálatok nincs is szükség gondolom az ő esetében, de ezt nem tudhatja), és megijedhet a "rendszergazdai feladatok" kulcsszótól...Mellesleg szerintem is nagyon rossz ötlet, hogy mindenféle népszerű keretrendszert is (nemcsak a CMS-eket) kizártok a játékból.
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #17677 üzenetére
Igazából miért ezzel a borzalmasan ronda spagettikóddal oldod meg a problémát?
-
Sk8erPeter
nagyúr
válasz
rantottsajt #17655 üzenetére
Hogy jött ki a 10000?
-
Sk8erPeter
nagyúr
"debuggolj. írasd ki echo-val a különböző változók értékeit"
Ezen azért kuncogtam. A debuggolás NEM AZ, hogy kiíratsz!!! Persze része lehet a hibakeresésnek, adott esetben nem para, ha nem a képernyőt írod tele, hanem legalább naplózol, de pont ez a baj, hogy számtalan PHP-fejlesztő azt hiszi, hogy az a jó hibakeresési módszer, ha telerakja a kódját echózásokkal (persze nem is naplóz véletlenül se), és nem tudja, hogy léteznek valódi debuggolási módszerek egy fejlesztőkörnyezetben (IDE), az Xdebug felhasználásával. Tehát bármily meglepő, PHP-ban is ugyanúgy lehet debuggolni, mint másik nyelvekben. Tök jól végig lehet lépkedni a kódon, hogy épp hol tart, vagy csak kifejezetten az általad manuálisan elhelyezett töréspontokon (breakpoint) megállni, lehet watch expressionöket elhelyezni (így a kód adott pontjára érve bizonyos változók értéke kiírásra kerül egyből a fejlesztőkörnyezetben), sőt, jó fejlesztőkörnyezetben lehet feltételes töréspontokat is elhelyezni (conditional breakpoint), ami azt jelenti, hogy csak bizonyos feltételek teljesülése esetén áll meg a kód adott pontján (ezzel például tök jól lehet rászűrni a problémás esetekre, amikor mondjuk nem akarsz minden esetben megállni, hanem csak akkor, amikor gáz van).
Igazából az van, hogy szerintem nagyon sokan úgy vannak a debuggolással, hogy "na majd egyszer azt is kipróbálom, most addig is jó lesz az echo", pedig egyszer kell belőni a környezetet - ehhez segítségnek ott van az Xdebug wizardja -, meg egyszer kell kipróbálni, ez mire is jó - tehát megtanulni debuggolni -, aztán rengeteg időt tud megspórolni. -
Sk8erPeter
nagyúr
válasz
MineFox54 #17627 üzenetére
1. Nem konkatenálunk SQL-utasítást escape-eletlen inputtal, SOHA, semmilyen körülmények között (azt sem érdemes felhozni mentségnek, hogy de hát az szerintem megbízható adat, mert nincs olyan kívülről érkező adat, amit megbízhatónak érdemes tekinteni - ez a paranoiás szemlélet célravezetőbb), és amennyiben lehetséges, prepared statementeket KELL használni a különböző paraméterekre. És jelenleg lehetséges, mivel MySQLi-t használsz, szóval mindenképp állj át arra.
2. Az ilyen jellegű mezőkhöz aliasokat illik használni (pl. itt SUM(tav) AS distance vagy hasonló), aztán az aliasnak megfelelően hivatkozni rájuk (pl. itt $row['distance'] - szándékosan nem használtam magyar változónevet).
A konkrét érdekes eltéréshez nehéz többet hozzátenni, több infót kellene tudni, mi változhat a különböző futtatások között.
-
Sk8erPeter
nagyúr
"http://x-profit.hu ezt ismeri valaki? amilyen gáz a honlapjuk, nem tudom, mit tudhat a cucc"
Ezt látom, amikor megnyitom, mivel szándékosan Click to play-re vannak állítva a Flash-tartalmak:Gratulálok nekik. 2015-ben még mindig egy full Flash-alapú oldal.
Utána azért kíváncsiságból már rákattintottam, de mivel a dizájn is ilyen borzasztó gusztustalan 2000-es évek eleji (az izgő-mozgó gifek korát idézi), ezért nem is néztem tovább. Most tényleg egy ilyen igénytelen szar után képes lennél még fizetni is nekik? -
Sk8erPeter
nagyúr
válasz
fordfairlane #17589 üzenetére
Oszd meg majd a szerzőkkel is, hátha átemelik.
-
Sk8erPeter
nagyúr
válasz
#68216320 #17587 üzenetére
Hát igen, az az egyik példa phpMyAdmin-alternatívának, úgy tudom, a phpMyAdmin egyáltalán nem működik MySQLi-kiterjesztés nélkül (pl. PDO-val).
Igazából ha korábban MySQLi-t használtál, akkor nem szabad, hogy nagy érvágás legyen átállni PDO-ra. A PDO-nak más szintaktikája van, szerintem egy fokkal könnyebben használható (számomra legalábbis jobban "kézreáll" az API), a prepared statementeknél használhatóak nevesített placeholderek (érdemes használnod, nem pedig a MySQLi-ből megszokott kérdőjeleket, persze ezek is működnek, sőt, van olyan eset, amikor pont erre van szükség (pl. amikor dinamikusan állít össze az ember egy előkészített utasítást)), és egyéb előnyei is vannak, valószínűleg nem lesz túl sok problémád az átállással.
Szoktam linkelgetni a topicban Tele von Zsinór kolléga PDO-val kapcsolatos cikkét, fusd át, mert igazából minden lényeges dolog benne van az elinduláshoz (pl. ami fontos, hogy a kapcsolat inicializálásakor a karakterkódolást kapásból UTF-8-ra állítja, ÉS hiba esetén exceptionök dobására utasítja a PDO-t). -
Sk8erPeter
nagyúr
válasz
cidalain #17568 üzenetére
Pedig ebben semmi misztikus nincs, többek közt az Accept-Language fejlécből megállapíthatóak a böngésző nyelvi beállításai - a böngésző ugyanis elküldi a szervernek, hogy a felhasználó - a beállítások szerint - melyik nyelvet preferálja, illetve mely további nyelveket kívánja elfogadni a kliens (ami a böngésző):
http://www.w3.org/International/questions/qa-accept-lang-localesAztán persze a szerver azt kezd ezzel az információval, amit akar - például ignorálhatja, vagy épp ennek felhasználásával állapítja meg az épp megjelenítendő nyelvet.
PHP esetén az Accept-Language fejléchez a $_SERVER['HTTP_ACCEPT_LANGUAGE'] változón keresztül férsz hozzá.
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #17537 üzenetére
Mi van a /php/controller.php fájl 19. sorában? Ott csatlakozol az adatbázishoz, vagy mi történik?
Fel tudsz amúgy dobni egy phpinfo-t az oldaladra?
"Amúgy miért működik a JS rendellenesen azért mert ez nem jó?"
Be sem töltődik a teljes dokumentum, 500 Internal Server Error van 1,1 perc után (durva timeout), az okozhat ilyet, például ha a dokumentum "ready" eventjének elsülése hatására futna le a JavaScript-kódod. -
Sk8erPeter
nagyúr
Hoppá, tényleg, teljesen igazad van, a Visual Studio Community tök ingyenes, tegnap megfeledkeztem róla, ráadásul a fejlesztők többségének elegendő is ez az ingyenes változat (nem is csak alapvető dolgokra!).
(#17523) mobal:
PHP után főleg megváltás. -
Sk8erPeter
nagyúr
"beleszocializálódtam a Visual Studioóba, más már azután "szar". No offense
"
Na ezzel az állítással nem tudok vitatkozni.Gyorsan meg lehet szokni a jót, a gyorsat. Egyébként az Eclipse és NetBeans egyáltalán nem tökéletesek, sőt, például a Visual Studio kategóriáján belül sokkal jobb és sokkal gyorsabb, de előbbiek előnye, hogy ingyenesek (persze nyilván E.-ben és NB.-ben C#-támogatás nincs, Visual Studióban meg nincs Java-támogatás, de érted
).
(#17517) biker:
Hát ez bizony ilyen ("szörnyű"), hogy meg kell szokni, hogy másik szoftverben nagy eséllyel máshol vannak a dóóógok...
Amúgy nem akarlak én meggyőzni semmiről, de ebben a topicban már nem is tudom, hányszor szenvedtél azzal, hogy próbálsz echózni, loggolni, kísérletezgetni, másképpen futtatni, átmenetileg sorokat kikommentezni, ahelyett, hogy debuggolnál. Tök mindegy, mit használsz a célra, de nem árt megtanulnod az előnyeit, egyszer melós lehet, de aztán rengeteg időt spórolhatsz vele. -
Sk8erPeter
nagyúr
válasz
fordfairlane #17513 üzenetére
Hát ez elég furcsa, hogy a munkahelyen nem IDE-ket használtok, hanem szövegszerkesztőket.
"Két kollégám használ Netbeanst, és ők sokat szidják a lassúsága miatt"
A sok fájlművelet miatt komoly szűk keresztmetszet tud lenni a HDD - ahogy az Eclipse-nél is. Persze sok munkahelyen nem adnak sajnos SSD-ket a fejlesztők "alá". Meg persze számít szerintem a JVM miatti relatív lassúság is. Ettől függetlenül nem kell mai szemmel komoly erőgépnek tekinthető konfiguráció - de mondom, tényleg nem bánik kíméletesen az erőforrásokkal, sima szövegszerkesztőnél viszont mindenképp SOKKAL hatékonyabb fejlesztést tesz lehetővé - ez mondjuk nem is kérdés, ezért furcsállom, hogy nem IDE-ket használtok egy munkahelyen, ahol kifejezetten a fejlesztés van a középpontban. (Ha nem bírná a céges gép, hogy IDE-t használok, komolyan, saját laptopomon nyomnám a fejlesztést bent is (pedig az én laptopom sem mondható egy erőgépnek, de néha tapasztalt röccenésen kívül bírja az iramot), hacsak céges policy nincs, ami ezt nem engedi.)És nem hiányzik nektek a tisztességes refaktorálási lehetőség, a runtime kódanalizálás, gyorssegítség a hibák kijavítására, számtalan kódírást gyorsító feature, az annotált kommentek alapján történő dokumentáció-tippek és igazából minden olyan, amit egy IDE nyújt, de egy szövegszerkesztő nem? Hát hogyan fordulhat az elő?
Kódírást gyorsító szolgáltatások nyilván sok sima szövegszerkesztőben is léteznek, de ezek legtöbbször nem gondolkodnak normálisan "projektszinten", vagy csak részleges támogatást nyújtanak (pl. valamilyen módon van lehetőség fájlok logikai összeszervezésére, egyfajta projektnézetre, de az alapján sokszor csak részleges kódkiegészítési lehetőségek vannak, valahol korlátokba lehet ütközni, legalábbis én ezt tapasztaltam, pedig sokat kipróbáltam).
Igazából annyi plusz feature van egy IDE-ben egy szövegszerkesztőhöz képest, hogy nem is érdemes végigmenni rajta... de hogy nélküle miért jó fejleszteni, azt nem értem.Konkrétan egyébként milyen szövegszerkesztőket használtok?
-
Sk8erPeter
nagyúr
Tehát azért szenvedsz, azért nem tudsz debuggolni (lévén, hogy csak egy szövegszerkesztőt használsz (amiért amúgy fizettél), nem egy IDE-t), és azért nem tudsz rengeteg egyéb műveletet elvégezni, olyanokat, amiket egy IDE nyújt (tehát ha feltételezünk egy normális fejlesztői környezetet), hogy ne terhelje a gépedet? Nem tom, nekem ezek az érvek viccesek, amikor valaki ezen spórol, miközben lóvéért fejleszt, és a saját munkaideje saját magának kerül pénzbe (pl. ha egyéni vállalkozó vagy). Csak mert ugye léteznek ugye olyan alternatívák is, amik egy fillérbe sem kerülnek, és integrált fejlesztőkörnyezetek, mint például az Eclipse vagy a NetBeans - igen, ezek nem kíméletesek az erőforrásokkal, de működnek, gyorsítják a fejlesztést, ingyenesek, tudsz bennük PHP-kódot debuggolni (ezzel a ráfordítandó munkaóráid számát adott esetben jelentősen csökkentve = profit).
(#17511) fordfairlane:
Ebben tökéletesen igazad van, de általában ezek a műveletek kellőképpen felhasználóbarát módon vannak megoldva egy IDE-ben, nem beszélve arról, hogy normális fejlesztőkörnyezetben az ember úgyis IDE-t használ. Persze akár más kliens is lehet, ami a műveletet felhasználóbaráttá teszi.Itt említ lehetőségeket.
-
Sk8erPeter
nagyúr
Ja, lehet, hogy az Xcode-ra, nem vágom.
(Sorry, nem szimpatizálok az Apple-cuccok agyatlanul túlárazott jellegével, meg a hozzá kapcsolódó sznob kultúrával.
)
A PhpStorm szerintem is jó, meg úgy általában a JetBrains-cuccok (pl. Python-fejlesztéshez a PyCharm is nagyon bejött, korábban az Eclipse PyDev pluginjét használtam, de a PyCharmban fejlesztés sokkal jobbnak és pörgősebbnek bizonyult; Java-fejlesztéshez az IntelliJ IDEA-val még nincs érdemi tapasztalatom, de azt is nagyon dicsérik).
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
cidalain #17502 üzenetére
Szerk.:
(#17499) MineFox54:
Most látom a szerkesztés után írott szövegedet."én abban kézzel be tudom állítani az útvonalat"
Úgy érted, szeretnél egy űrlapot, azon szeretnél két mezőt kiindulási ponthoz és célponthoz, és úgy szeretnéd működtetni az egészet? Mert akkor módosítja a dolgot, ez esetben Google Maps API-ra lehet szükséged, de simán JavaScript elég hozzá, nem kell PHP.
Szóval ha jól értem, kb. azt akarod, hogy a Google Maps weboldalán (https://www.google.hu/maps) látható működést átültesd a sajátodra.A hivatalos példák hasznodra lehetnek:
https://developers.google.com/maps/documentation/javascript/examples/Szükséges lesz viszont JavaScript-tudás.
-
Sk8erPeter
nagyúr
-
Sk8erPeter
nagyúr
válasz
MineFox54 #17497 üzenetére
Ennek mi köze a PHP-hez? Legalábbis az itt írt további hsz.-ed alapján bőven elég beágyazni az útvonalat, aztán annyi.
Ha viszont valahogy dinamikusan szeretnéd megtervezni az útvonalat, nem egy konkrét, rögzített útvonalat akarsz megjeleníteni, akkor tedd fel értelmesebben a kérdésedet.(#17495) biker:
És a Macesek nagy sztárolt IDE-jében (már ha az, nem csak egy szerkesztő, fogalmam sincs a Mac-cuccokról, nem is nagyon izgatnak) nem lehet PHP-kódot debuggolni? -
Sk8erPeter
nagyúr
Igazából a feladat egyszerű, mint a lepkefing, pár perc alatt megoldható.
Végigmész az adott könyvtár fájljain (az alapján, amit írtál, feltételezem, hogy egy helyre vannak ömlesztve, nem kell rekurzíve bejárni a könyvtárakat), reguláris kifejezéssel ellenőrzöd, hogy illeszkedik-e a fájlnév az általad megadott mintára, ha igen, akkor space mentén "szétrobbantod" a stringet, majd ebből kiszeded. Legalábbis ez egy nagyon gyorsan bepötyöghető megoldás. Szépségével nem foglalkoztam a kódnak, ez működik:$filename_pattern = '/^[a-z]+ \d+ \S+\.asd\.txt$/';
$dir = '.';
$filenames = scandir($dir);
foreach($filenames as $filename) {
if (!is_dir("$dir/$filename")) {
if(preg_match($filename_pattern, $filename)) {
$filename_pieces_by_space = explode(" ", $filename);
$measurement_location = $filename_pieces_by_space[0];
$measurement_id = $filename_pieces_by_space[1];
echo $measurement_id, ': ', $measurement_location . PHP_EOL;
}
}
}A reguláris kifejezés jelentése: a string eleje és vége között a következők vannak: bármilyen a és z közötti karakter egynél többször, szóköz, bármilyen szám egynél többször, szóköz, bármilyen nem whitespace karakter egynél többször, majd pont, "asd", pont, txt.
Itt az explode eredményeként a harmadik elem a tömbben ilyen lesz, mint a "90n00004.asd.txt", ha ebből további infó kell, akkor nyilván pontok mentén kell szétrobbantani.(#17485) biker:
Hát ennyi infóból ember legyen a talpán, aki megmondja, mi a baj.
Azért remélem, azóta nem vágtál eret. -
Sk8erPeter
nagyúr
válasz
fordfairlane #17465 üzenetére
Atyaisten, csak most néztem bele én is a PHPMailer kódjába, ez tényleg brutális, tényleg egy gigantikus osztály, semmi tisztességesen szétválasztott kód. A SwiftMailer Swift_Message osztálya pl. picit rövidebb, és ez csak osztály a sok közül, itt legalább Dependency Injection van.
(#17480) don_peter:
"Magyar Angol keverék a jó"
Ez viccnek is rossz.Főleg, hogy ha már "magyar" vagy "angol", akkor kis kezdőbetűvel írjuk.
(De a kód legyen angol, a programozás nyelve angol, akár tetszik, akár nem.
)
-
Sk8erPeter
nagyúr
válasz
creation #17459 üzenetére
"Sajnos nem jöttünk rá mi lehet az ok. Ráment két napunk, viszont nincs ilyenre idő"
A Programozás topicban nem véletlenül mondtam már a legelején, hogy DEBUGGOLJATOK egy normális fejlesztőkörnyezet bevetésével. Ne csak próbálkozzatok, szenvedjetek, toporogjatok egy helyben, hanem vizsgáljátok meg normálisan az ügyet, a klienstől a szerver felé utazó adatokat, azokat a körülményeket, amiktől a szerveroldalon elvérzik az autentikáció. De úgy tűnt, erre nem vagy nyitott, meg még azt sem mondtad meg sokszori kérdéseimre sem, hogy egész pontosan hol is vérzik el a dolog, plusz ugye normális hibakezelés sem volt a kódodban.(#17461) creation:
"Valóban nem, de legalább működik"
A Swift Mailer is működik, nem tudom, miért ne működne. Meg hogy honnan van egyáltalán összehasonlítási alapod, ha egyiket sem használtad még soha.(#17460) fordfairlane:
Lehet, szerencsére nem nézegetem egy ideje, direkt raktam előre a Swift Mailert. -
Sk8erPeter
nagyúr
válasz
creation #17457 üzenetére
Ezek szerint továbbra sem sikerült kideríteni, mi a frász köze van a használt kliensnek ahhoz, hogy szerveroldalon nem működik az autentikálás?
Pedig engem érdekelt volna, brühüh.
A levelezős problémára annyi a megoldás, hogy valami normális library-t használsz hozzá, mint például a Swift Mailer vagy a PHPMailer, és nem szenvedsz azzal a fostos beépített mail() függvénnyel önmagában. Tégy jót az emberiséggel, és ne próbáld vérrel és verítékkel megoldani azt a problémát, amit más már megtett helyetted. -
Sk8erPeter
nagyúr
válasz
creation #17444 üzenetére
Itt már írtam neked, de nem találtad fontosnak a válaszadást...
(Lehet, hogy más reakciójára vársz, de akkor is illene legalább böffenteni valamit válaszként.
) Akkor hogyan haladjunk tovább? Le kéne szűkíteni a potenciális problémákat, tudni kéne, nézegettél-e naplókat, a szerver beállításainak változtatgatásaival próbálkoztál-e, vagy csak default módban üzemel, mivel próbálkoztál a probléma megoldásának érdekében, stb., de persze nekem teljesen mindegy, nem nekem kell.
-
Sk8erPeter
nagyúr
válasz
creation #17433 üzenetére
http://prohardver.hu/tema/programozas_forum/hsz_8649-8649.html
Végül is itt is folytathatjuk. -
Sk8erPeter
nagyúr
válasz
cidalain #17430 üzenetére
"+1 kérdés: mit jelent az hogy "thread safe" meg "non thread safe" verzió?"
Guglizás megvolt már?
http://php.net/manual/en/faq.obtaining.php#faq.obtaining.threadsafety
"What does thread safety mean when downloading PHP?
Thread Safety means that binary can work in a multithreaded webserver context, such as Apache 2 on Windows. Thread Safety works by creating a local storage copy in each thread, so that the data won't collide with another thread.So what do I choose? If you choose to run PHP as a CGI binary, then you won't need thread safety, because the binary is invoked at each request. For multithreaded webservers, such as IIS5 and IIS6, you should use the threaded version of PHP."
-
Sk8erPeter
nagyúr
válasz
cidalain #17428 üzenetére
A forráskód csak akkor érdekes, ha te magad akarod buildelni a PHP-t, megkapva a szükséges futtatható állományokat és a többi szükséges fájlt. Nyilván nem akarsz ezzel szarakodni, ez esetben meg ott van a letölthető zip, abban van egy install.txt, van egy manual installation része, az jó részletesen leírja a teendőket. Tulajdonképpen "csak" a meglévő webszerveredhez kell igazítani az itt kibontott cuccot.
-
Sk8erPeter
nagyúr
válasz
MineFox54 #17424 üzenetére
Ezt elkerülheted egy normális fejlesztőkörnyezet használatával - de ilyet akár egy szintaktika-kiemelős szövegszerkesztő is egyértelműen mutat, mint pl. a Notepad++ -, meg azzal, hogy bekapcsolod a hibajelzést fejlesztés idejéig... (pl. ezért parse errort kellett volna, hogy kapj fehér képernyő helyett, a fehér képernyő fejlesztés idején ugyebár nem túl beszédes)
-
Sk8erPeter
nagyúr
válasz
Des1gnR #17388 üzenetére
Jé, csak nem mégis van valami API-szerűség a Volánnál?
Magyar állami szervezetnél ez egészen meglepő.
Azt sikerült leszűkíteni, hogy konkrétan milyen kulcsokra van szükség ahhoz, hogy a dolog működjön? Nekem nem volt kedvem próbálkozni, csak gyorsan indítottam egy Postmant, a honnan, hova, honnan_settlement_id, honnan_eovx, honnan_eovy és ennek hova_* változataival simán nem működik, üres objektum a válasz a JSON-változatnál. A Postmanhez telepített Postman Interceptor pedig cookie-kat is beállít, szóval annak hiánya elvileg nem para, de összesen az egésszel töltöttem kb. 3 percet, szóval annyiból nem derült ki, mi a hiány.
Felraktam inkább ide a képedet (szétvágva kettőbe), mert az ilyen külső képmegosztók kényükre-kedvükre egy idő után simán törlik a képeket (pl. ha egy ideje nem nézték):
-
Sk8erPeter
nagyúr
válasz
Des1gnR #17386 üzenetére
Most úgy érdemes nézelődnöd, hogy a webfejlesztő panel hálózati fülén bekapcsolod, hogy őrizze meg a korábbi requesteket is, így újratöltődésnél nem fog mindig "elölről" kezdődni a requestek felsorolása, hanem megőrzi a lap-újratöltődés előttieket is, így láthatod, hogy az űrlap elküldésekor milyen adatok utaztak ide-oda.
Pl. Chrome vagy Opera esetén a Network fülön a "Preserve log" checkboxot most érdemes bepipálni, hogy lásd az eredményeket, pl. látszik, hogy a Keresés gomb megnyomása után először a
http://ujmenetrend.cdata.hu/uj_menetrend/volan/ajax_response_gen.php
címre megy egy request, megnézheted, itt milyen adat utazik, majd a talalatok.php-ra kattintva is meg tudod nézni a küldött/fogadott adatokat:Ez sokat segíthet a nyomozásban.
-
Sk8erPeter
nagyúr
Önmagában az, hogy GET-metódussal vagy POST-tal küldöd az adatokat a szerver felé, az tökéletesen mindegy. Szóval nem értem, az eltérő metódus miatt miért változtatna a megoldáson. A válasz feldolgozása már érdekesebb. Valószínűleg pont olyan változóneveket várnak, ami az űrlap elemeinél látható, tehát ezt is lehet tudni. Ami viszont már valóban gondot jelenthet, az az, ha az adatok megjelenítése, az eredménytáblázat felépítése csak JavaScripttel történik, és nincs benne a törzsben az elvárható módon az adat, tehát a válasz kikotrása egyáltalán nem biztos, hogy triviális egy szarul felépített oldalnál.
Egyébként vicc, hogy nincs egy normális hivatalos API-ja a Volánnak.
(#17371) DS39:
Regexszel kiszedni a választ valami brutális overkill. Vannak rendes dokumentum-feldolgozó könyvtárak, azokat kell használni.Hogy Google Translate-hez minek csináltál ilyen regexes adatkiszedős valamit, az meg számomra rejtély, amikor van rendes API-ja (elég régóta).
-
Sk8erPeter
nagyúr
válasz
Des1gnR #17369 üzenetére
Ha Windows Phone-ra szeretnél fejleszteni, akkor miért a PHP topicban vagy?
A feladat megoldásának semmi köze nincs hozzá, a szervertől kapott választ kell feldolgoznod az általad használt nyelvvel. (A Te szempontodból teljesen mindegy, hogy a VOLÁN-nál milyen szerveroldali nyelvet használnak.)
-
-
Sk8erPeter
nagyúr
válasz
CSorBA #17344 üzenetére
Ha beépített megoldást is találnál rá, annak is végig kellene szaladnia a tömbön (igaz, a beépített megoldás minimálisan gyorsabb lehet, mint a saját kódod), szóval nem fogod tudni megspórolni, de nem túl bonyolult:
$testArray = array(
0 => array(
"id"=> "214",
"valami"=> "asd"
),
1 => array(
"id"=> "123",
"valami"=> "asd"
),
2 => array(
"id"=> "982",
"valami"=> "asd"
),
);$newArray = array();
foreach($testArray as $currentItem){
$newArray[$currentItem['id']] = $currentItem;
}Eredménye:
array (
214 =>
array (
'id' => '214',
'valami' => 'asd',
),
123 =>
array (
'id' => '123',
'valami' => 'asd',
),
982 =>
array (
'id' => '982',
'valami' => 'asd',
),
)Lehetne még array_walk segítségével is, de itt pár mérés alapján sokkal lassabb tud lenni, mint a foreach, úgyhogy inkább csak érdekességként mutatom:
$newArray = array();
array_walk($testArray, function($item, $key){
global $newArray;
$newArray[$item['id']] = $item;
}); -
Sk8erPeter
nagyúr
Rakj fel kérlek egy olyan jsFiddle-példát, amit én is linkeltem neked, bővítsd az enyémet, vagy valami (aztán mentsd is el, és linkeld be ide), hogy látható legyen, a saját kódodnál mi is a gond, és milyen opciókat szeretnél pluszban betenni, mert az általam korábban mutatott kód működik. Amúgy ez már sokkal inkább a JavaScript topicba hajlik, folytathatjuk ott is.
-
Sk8erPeter
nagyúr
válasz
Sk8erPeter #17316 üzenetére
Bővítettem még tök random adatokkal, és itt is teljesen jól jelenik meg a dátum:
http://jsfiddle.net/8vkse4bu/1/ -
Sk8erPeter
nagyúr
Itt úgy tűnik, hogy maga a dátum jól jelenik meg, felraktam a példádat:
http://jsfiddle.net/8vkse4bu/
Több adattal nem próbáltam ki, segítene, ha felraknál több adatot is mondjuk pastebinre, vagy ugyanígy bedobnád jsFiddle-példán, ami nálad rosszul jelenik meg.Amúgy az egyik hivatalos példában is ilyen bénán jelenik meg a dátum, ahogy említetted:
http://jsfiddle.net/gh/get/jquery/1.7.2/highslide-software/highcharts.com/tree/master/samples/stock/rangeselector/input-format/ -
Sk8erPeter
nagyúr
Mi a hozzá tartozó kliensoldali kódod?
Egyébként azt nézem, hogy az összes demóban dátumnál alapértelmezetten az 1970. január 1. óta eltelt milliszekundumok számát használják fel (pl. ennél a demónál, ebben a fájlban), szóval valszeg be kellene explicite állítanod, hogy te milyen dátumformátumot használsz, VAGY tök felesleges az adatbázis-oldali átalakításod (inkább utóbbira tippelek).
Szóval milyen JavaScript-kódot használsz hozzá?
Ja, és a dátumot hol, hogyan szeretnéd megjeleníteni?Szerk.:
http://api.highcharts.com/highstock#rangeSelector.inputDateFormat
Itt azt írja:
"inputDateFormat: String
The date format in the input boxes when not selected for editing. Defaults to %b %e, %Y. Defaults to %b %e %Y,."
Hogy most akkor melyik, azt nem tudom.Érdekes, hogy két formátum van.
Még ezek lehetnek érdekesek:
inputDateParser: Function
A custom callback function to parse values entered in the input boxes and return a valid JavaScript time as milliseconds since 1970.inputEditDateFormat: String
The date format in the input boxes when they are selected for editing. This must be a format that is recognized by JavaScript Date.parse. Defaults to %Y-%m-%d. -
Sk8erPeter
nagyúr
Megnézted a fogadott JSON-adatokat, az alapján a kapott adatok helyesek? Kliensoldalon hogy jeleníted meg a chartot? Nekem kicsit furcsa, hogy behánysz össze nem illő adatokat egymás mellé, pl. dátumot a valamilyen downstream/upstream csatornák adataival, persze nem is ismerem a library API-ját, de mielőtt utánanéznék, nem ártana legalább egy kis példakimenet (a kapott JSON-adatok legalább egy része, hogy el tudjuk képzelni, milyen adatokat is akarsz megjeleníteni).
Amúgy angolul a data már eleve többesszám, nem kell odatenni még egy s-t is a végére, hogy az legyen...
-
Sk8erPeter
nagyúr
Things you must know about PHP7 --> hát ez a "spaceship operator" rettentő értelmes:
https://wiki.php.net/rfc/combined-comparison-operatorTehát most már tudok olyat csinálni, hogy
if( ($a <=> $b) === -1 || ($a <=> $b) === 0) { ... }Hát csodálatos.
-
Sk8erPeter
nagyúr
válasz
Joci93 #17285 üzenetére
cidalainnal értek egyet, van olyan feladat, ami eleve értelmetlen, így nem biztos, hogy megéri elvállalni, szépen türelmesen el kell magyarázni a megrendelőnek, hogy baromságot akar. Aztán hátha meggondolja magát, vagy tovább kell állni (már ha van választási lehetőség). Nem akar adatbázist valami degenerált indokból, de azért valahol mégis, meg szeretne query-ket is írni kézzel, amit ja, akár phpMyAdminban is megtehetne, ha ez a kattanása, de nem, ő a spanyolviaszt akarja felfedezni.
De ha már muszáj elvállalnod, és valahova menteni kell, illetve fel is kell tudni dolgozni a tárolt adatot, akkor a txt-t vagy bármi behányt szöveget azonnal felejtsd el, valami normálisan és hatékonyan feldolgozható formátumban mentsd el, legyen az JSON, XML, stb. Ha már az SQLite is szóba kerülhet, mint lokális, fájlba írós adatbázis, akkor már nem igazán értem, miért ne lehetne egy tisztességes adatbázis (nem lebecsülve az SQLite-ot, de nagyobb adatmennyiség esetén már nyilván nem ez a hatékony megoldás), onnantól már csak egy lépés.
Mi is pontosan az indoka a megrendelőnek arra, hogy nem lehet adatbázist használni?Amúgy ha már SQL parsert kell használnod, akkor nehogy elkezdd kézzel összetákolni, mert rohadt nagy szopás tud lenni egy parser, inkább használj fel egy kész könyvtárat:
https://code.google.com/p/php-sql-parser/
http://stackoverflow.com/questions/283087/php-mysql-sql-parser-insert-and-update/283115#283115Szerk.:
(#17290) PumpkinSeed: pont megelőztél.Amúgy egyetértek.
-
Sk8erPeter
nagyúr
válasz
DNReNTi #17252 üzenetére
Vaze.
Egyébként a favicon.ico fájl lekérése a gyökérből (amennyiben pl. nincs beállítva favicon egyéb módon) böngészőfüggő, van, amelyik cseszegeti érte a szervert, van, amelyik nem. Szóval ez esetben, tehát most, hogy kiderült, hogy többek közt a favicon.ico-ra irányuló requestek is lefuttatták az index.php-dben lévő adatbázis-tömködést, nem meglepő, hogy több beillesztés is történt, és hogy ez böngészőfüggő volt.
-
Sk8erPeter
nagyúr
válasz
DNReNTi #17239 üzenetére
Meg tudod mutatni a .htaccess vonatkozó részletét, ami a hibát okozta?
Hogy mitől lehet böngészőfüggő, de ez csak tippelgetés: ha ez a teszt az adatbázisba való beillesztésre csak simán be volt dobva egy akármilyen oldalra, tehát minden oldalbetöltéskor lefutott, akkor lehet akár a böngészőnek egy előtöltési mechanizmusa, tehát pl. amint beírtad a megnyitandó URL-t, máris elindulhatott egy előtöltés a teljesítmény növelése érdekében, pl. Chrome-nál van ilyen opció:
https://support.google.com/chrome/answer/1385029?hl=hu-HU
"Hálózati műveletek előrejelzése az oldalbetöltések teljesítményének növelése érdekében"
vagy angolul "Predict network actions to improve page load performance”
Ha minden egyes kérést figyelgetsz, akkor látható, hogy már abban a pillanatban elindul egy request, amikor csak bepötyögted az URL-t, vagy amint kiegészítette autocomplete segítségével a böngésző - tehát még meg sem nyomtad az Entert, máris megpróbál egy részletet előtölteni gyorsítótárba, hogy aztán amikor ténylegesen megnyitod, akkor gyorsabban betöltsön az oldal.
De most ez csak ötlet, a (század)másodpercre pontos adatokból, meg egyéb infókból lenne kideríthető, hogy pont ez lehetett-e az oka, vagy valami más. -
Sk8erPeter
nagyúr
válasz
Des1gnR #17232 üzenetére
Általános tanácsot nem lehet adni, mivel minden webshop más lehet, de mindenesetre az összes termékoldal összes HTML-kódját lementeni nyilván értelmetlen, ebből ki kell bányászni első letöltés után a szükséges adatokat, aztán eldobni a HTML-kimenetet. Vagy DOMDocument osztállyal, vagy erre/másra építő library-vel, mindenesetre valamilyen DOM-feldolgozó módszerrel.
-
Sk8erPeter
nagyúr
válasz
PumpkinSeed #17229 üzenetére
"Igen tudom, bár javasoltam egy alternatív megoldást a problémára."
Ami hibás.Az str_split()-nek az egész tömböt adod át, nem indexelted. Egyébként van foreach-ciklus, ami ennél sokkal szebb kódot eredményez, és az ilyen jellegű indexeléssel sem kell foglalkoznod.
"Amúgy nem lehetséges, hogy néha az ilyen alternatív megoldás gyorsabb? Tegyük fel, hogy a kód
ugyan olyanugyanolyan hatékonysággal van megírva mint a függvényben, de mivel itt függvényhívás nélkül fut le, ezért valamivel gyorsabb."
Nem valószínű, mivel a PHP könyvtári függvényeit C-ben írják, aztán optimalizált kód lesz belőle a buildelés során, nagy eséllyel ez gyorsabban fog működni, mint a Te kódod, amit már PHP-ben írsz (a fenti kódodnál meg aztán végképp gyorsabban fog működni...). Persze ettől még a különbséget nem biztos, hogy megérzed. (Na meg el lehet képzelni rossz implementációt is még a beépített függvényeknél is.)
Ha arra vagy kíváncsi, hogy azonos környezetben, azonos feltételekkel, ugyanolyan hatékonysággal van valóban megírva a kód, de még valaki hozzátesz egy függvényhívást is, akkor melyik lesz a győztes, akkor igen, jól sejted, ELMÉLETBEN az, amelyik nem teszi hozzá a függvényhívás overheadjét - a gyakorlat viszont megint más, mert ez már olyan minimális különbség, hogy nem fogod tudni mérni sem, hogy melyik a gyorsabb, sőt, aktuális szerverterheltségtől függően össze-vissza fog változni a különbség.
Szóval azon nem éri meg agyalni, hogy inkább a könyvtári függvényt használod, vagy feltalálod a spanyolviaszt.
Azon, hogy milyen overheadet teszel hozzá egy-egy függvényhívással, akkor éri meg agyalni, amikor pl. egy helyen ugyanazt az értéket kéred le többször is, tök feleslegesen. Rengetegen elkövetik azt a hibát, hogy egy értéket/referenciát/akármit eltárolhatnának egy változóban, és később felhasználhatnák, de ugyanazt a kódot leírják többször is (erre is vonatkozik a DRY (Don't Repeat Yourself) elv).
Na, kezdek elkalandozni, remélem, megválaszoltam a kérdésedet. -
Sk8erPeter
nagyúr
válasz
PumpkinSeed #17225 üzenetére
Ja, strpos(), strstr() és társai, vagy multibyte stringeknél ezek megfelelői, tehát mb_strpos(), mb_strstr(), stb...
Amúgy ne vedd sértésnek, de azért mielőtt olyanokat állítasz, hogy "erre szerintem nincs beépített függvény", miközben ez eléggé alapvető elvárás, hogy beépített könyvtári függvény/metódus legyen egy stringben keresős módszer, nem árt utánanézni...
-
Sk8erPeter
nagyúr
válasz
Speeedfire #17222 üzenetére
Nem tiszta ennyiből a feladat, de akkor mondjuk annak a mindig meghívogatott metódusnak legyen egy default értékkel ellátott második paramétere is, ellenőrizd ezt a paramétert a metódus törzsében, és ha ez egy egyéb értékkel egyenlő, akkor csináld meg azt a másik esetet. Persze csak ha ez nem vezet gányoláshoz, de ennyi infóból ezt lehetett kihozni kerülő megoldásként, amivel még nincs is nagy para.
(#17223) Joci93:
Ez stringek tömbje? Tehát egy tömb, amiben több string is található?
Menj végig a tömbelemeken, és stringtartalom-keresős függvényekkel nézd meg, benne van-e az általad keresett string az aktuális elemben... -
Sk8erPeter
nagyúr
válasz
Speeedfire #17219 üzenetére
Engem is nagyon érdekelne, hogy mit akarsz csinálni, ami miatt ilyen felmerült.
És hogy miért nem más módszerrel csinálod - amúgy ha ez nem volt tiszta egyből, hogy ilyet konstruktorból nyilvánvalóan nem lehet, akkor nem ártana legalább egyszer szépen végigdebuggolnod egy példány létrehozásának folyamatát, azt, hogy mikor melyik metódusba ugrik bele, és így tovább, meg átnézni az OOP-t jobban, mert itt valami alapok nagyon hiányoznak.
Új hozzászólás Aktív témák
Hirdetés
- Huawei P30 Liter 128GB Kártyafüggetlen 1Év Garanciával
- Makulátlan MacBook Air M1 99%-os Akkuval és 2+ Év iStyle Garanciával!
- AKCIÓ!!! GAMER PC: Új RYZEN 5 4500-5600X +GTX 1660 SUPER +16-64GB DDR4! GAR/SZÁMLA! 50 FÉLE HÁZ!
- Asus TUF 16 FA607PI - 16" 2,5K 165Hz - Ryzen 9 7845HX - 32GB - 1TB - RTX 4070 - Win11 - 1,5 év gari
- Eladó Logitech G735 gyári dobozban, kiváló állapotban!
- ÁRGARANCIA!Épített KomPhone i3 10105F 16/32/64GB RAM RX 6600 8GB GAMER PC termékbeszámítással
- BESZÁMÍTÁS! GigabyteA620M R5 7500F 32GB DDR5 500GB SSD RX6700XT 12GB Bitfenix Nova Mesh Enermax 750W
- BESZÁMÍTÁS! SAPPHIRE NITRO+ RX 7900 XTX 24GB GDDR6 videokártya garanciával hibátlan működéssel
- AKCIÓ! Dell Latitude 5440 14 FHD üzleti notebook - i5 1335U 8GB RAM 256GB SSD Intel Iris Xe
- Bomba ár! Dell Latitude E6510 - i5-560M I 4GB I 250GB I DVD I 15,6" HD+ I Garancia!
Állásajánlatok
Cég: CAMERA-PRO Hungary Kft
Város: Budapest
Cég: PCMENTOR SZERVIZ KFT.
Város: Budapest