ugrás a tartalomhoz

Archívum - Fórum téma

július 26, 2017

HTML linkek cseréje dinamikusan

sandrosdj · 2017. Júl. 26. (Sze), 13.14
Kedves fórumozók!

A következő problémára keresek stabilabb megoldást:

Adott egy HTML kód, melyben vannak linkek (nem szövegesen, azok is rendes html tag-ek).
Ezeket a linkeket runtime ki kellene cserélni úgy, hogy az eredeti link urlencode-al bekerülne az url paraméter értékeként.

Pl.:
eredeti html: <a href="http://om.g/?asd" style="border:1px">Link</a>
kimenet: <a href="http://redi.r/?url=http%3A%2F%2Fom.g%2F%3Fasd" style="border:1px">Link</a>

Jelenleg így csinálom:
preg_replace_callback('/<a\\shref="(.*?)">(.*?)<\\/a>/is', function($m) use($uzenet) {
										return '<a href="http://redi.r/?uzenet='.$uzenet.'&amp;&amp;url='.urlencode($m[1]).'">'.$m[2].'</a>';
									}, $original);
Ezzel az a gond, ha van utána más attribútum is, akkor az is az url része lesz a kimenetben.

Mit kellene változtatni a regex-en?
 

július 23

Egyszerű skálázódás

Hidvégi Gábor · 2017. Júl. 23. (V), 10.22
Már korábban is felmerült, de A frontend állapota 2017-ben című fórumtémában az egyik fő érv az állapot szerveroldalon történő kezelése ellen az volt, hogy ez jelentősen megnehezíti a backend munkáját, legrosszabb esetben az egész szolgáltatás jelentős lelassulását, leállását okozhatja. Mivel a téma fontos, ezért érdemes külön foglalkozni vele.

Elmélet

A skálázódás egy szolgáltatás fontos tulajdonsága, amely azt a képességét adja meg, hogy nagy terhelés esetén a rendszer hogyan viselkedik, mekkora válaszidők várhatóak. Ez utóbbi sokmindentől függ, külsőleg a kliens szerverhez való kapcsolódási sebességétől (például mobiltelefonon befolyásolja az időjárás, a térerő, az adott cellán lévő más felhasználók száma), valamint az egyes rendszerkomponensektől (milyen programkörnyezetet választottunk, mennyi adattal kell dolgoznunk, milyen kapcsolat van a részegységek között, mekkora a terhelésük stb.). Egy alkalmazás bármelyik összetevője lehet szűk keresztmetszet, ami kihatással van az egészre, így fontos a megfelelő tervezés.

Gyakorlat

Az első és legfontosabb, hogy folyamatosan mérni kell az egyes részek teljesítményét. Ha van hozzáférésünk, az operációs rendszer feladatkezelőjében láthatjuk, hogy az egyes processzek mekkora CPU terhelést okoznak és mennyi memóriát foglalnak, de lehetőség van szoftverből is figyelni az erőforrásokat, például a Nagios segítségével.

Sokszor a legegyszerűbb lehet a szerveroldalon a hardverelemek jobbra, gyorsabbra cserélése, a memória bővítése például jótékony hatással van mindenre: az operációs rendszer vagy az adatbázisszerver többmindent tud gyorsítótárazni, de ugyanígy a merevlemezek cseréje SSD-re is jelentősen javíthat a válaszidőkön.

Ha egy szerver már nem bírja, a legkönnyebb az adatbázist egy másik (virtuális) gépre áttenni.

július 22

SQL HIBA!! Nem értem miért az..

statesz · 2017. Júl. 22. (Szo), 19.47
PHPban lefuttatom ezt az sqlt de a weboldalon ez jelenik meg:
Error: SELECT `members_balance` FROM `members` WHERE `members_id` = $MEMBERS_ID$

Valaki tud segíteni???

Szerk: member azonosítóját kiszedtem, és $MEMBERS_ID$-val helyettesítettem. Publikus felületre ne írjunk ki semmilyen user azonosítót. - BlaZe

Steam id, mivel bejelentkezés. Szóval az id az enyém és publikus. mindegy nem ez a lényeg.
 

Könyv vásárlás

doctorwho · 2017. Júl. 22. (Szo), 18.32
Ezek közül melyik könyveket vásároljam meg, ha kezdő szintről legalább haladó szintig szeretném megtanulni a PHP-t?

https://www.libri.hu/konyv/laura_thomson.php-es-mysql-webfejlesztoknek.html

https://www.libri.hu/konyv/george_schlossnagle.php-fejlesztes-felsofokon.html


https://www.libri.hu/konyv/s_suehring.php-mysql-javascript-html5.html

PHP 24 óra alatt.
 

július 21

storygo.net vélemény

Radon · 2017. Júl. 21. (P), 11.13
Sziasztok. Véleményt szeretnék kérni a weboldalamról.
Az oldalon a storygo bemutatása cikkben van kis leírás, hogy miről is szól a weboldal. Főként használhatóság, kezelhetőség, hasznosság szempontok alapján kérnék véleményt.
Akinek 1 angol nyelvű bejegyzés jelenik meg, annak idegen nyelvű böngészőt érzékel az oldal, és angol tartalmat és menüket jelenít meg. Ekkor az oldal alján a zászló ikonnal tud nyelvet változtatni, és megjelenik a magyar tartalom.
Link
Köszi.
 

július 17

Senior Full Stack PHP/JS developer and Database Specialist

stilldesign_kn · 2017. Júl. 17. (H), 15.17
Törlésre jelölve, ez az állás rovatba való. - janoszen
 

július 15

Junior mentor program kerestetik

mahoo · 2017. Júl. 15. (Szo), 12.00
Sziasztok!

Keresek olyan back-end vagy front-end fejlesztői mentor programot, ami a képzés ideje alatt 'fizetést' biztosít tanulmányi szerződés fejében.

Ha esetleg valaki tud közeljövőben induló programról, legyen szíves értesítsen!

(PHP-és és némi front-endes tapasztalattal rendelkezem.)
 

július 10

A RAID mennyire véd data corruption ellen?

inf · 2017. Júl. 10. (H), 05.14
Olvastam pár cikket arról, hogy a hibás szektorok okozta data corruption ellen a RAID egyáltalán nem véd (leszámítva a ZFS-t), pl: raid-5-with-bad-fixed-sectors/. Ennek az az oka, hogy a HDD-be van építve a checksum készítő és ellenőrző kód, ami általában elég gyors, de emiatt nem feltétlen a legmegbízhatóbb. A cikkek, amiket olvastam viszont 3-4 évesek. Az érdekelne, hogy azóta változott e a helyzet, illetve, hogy van e olyan RAID verzió, amiben az ilyesmit már megoldották? Én leginkább azért szórnék be az itthoni szerverbe RAID-et, hogy védjen az ilyen jellegű adat sérüléstől is, nem pedig az üzemszünet megakadályozására. Nekem nem szempont, ha elszáll egy meghajtó, várnom kell pár napot és backup-ról kell visszaállítanom mindent. Max annyi számítana, hogy 1-2 hét esetleg kiesne, ha nem gyakran backupolok. Az sem tetszene, hogyha egy hibás szektor miatt tönkremenne az adatbázis, és emiatt kéne backupolni. Nagyjából ilyen elvek mentén van valami megoldás a problémára? Esetleg nincs értelme foglalkozni vele, mert annyira ritka az ilyen egy mai meghajtón?
 

július 6

Lekérdezés eredményének szűkítése formmal Symfonyban

mahoo · 2017. Júl. 6. (Cs), 20.20
Sziasztok,
nem nagyon talalok megfelelo informaciot, valoszinuleg nem jol keresem, az alabbi feladatra.

Adott egy lista a felhasznalokrol es azok jogairol, 3 adattabla, entitas alapjan (user,role,user_roles). Ezt a listat kellene szurni nev es jogok alapjan egy form segitsegevel.

Gondolom nem azt kellene csinalni, hogy a form elkuldesekor a querybuilder-hez 'manualisan' hozzafuzok 'where'-eket, hanem valahogy a form es query objektumokat kellene valahogy egyutt felhasznalni.

Tudna valaki tutorialt, mintat mutatni nekem, ami kozelebb visz a megoldashoz?
Koszonom!
 

A frontend állapota 2017-ben

Hidvégi Gábor · 2017. Júl. 6. (Cs), 11.19
Egy múltkori fórumtéma kapcsán többen is a manapság népszerűnek tartott React-et és Angulart javasolták kezdőknek, ebben az írásomban bemutatom részletesen, hogy mi a probléma ezekkel.

Bizonytalanság

Ezek a keretrendszerek alapból kliensoldali sablonozást valósítanak meg, ami egy annyira abszurd ötlet, hogy gyakorlatilag ezen bukik el az egész, minden más csak hab a tortán.

A működési elvük a következő: általában nyers adatforrásokkal (json) dolgoznak, amiket a kliens aktuális állapota alapján olvasnak be, majd átadják a sablonoknak, amikből végül HTML-t generálnak. A kulcs itt az, hogy az aktuális állapot (az esetek túlnyomó többségében) a kliensen van, amivel legalább két probléma van. Az egyik, hogy egy áramszünet vagy a böngésző bezárása/a lap újratöltése után ez az állapot elveszik. A másik, hogy nem veszik figyelembe az internet alaptörvényét.

Ezt az alaptörvényt Peter-Paul Koch, az egyik legismertebb frontendes így emeli ki:
The target environment is undefined. In most programming problems we start with with a well defined target environment (or at least the language semantics are well defined and we quickly learn where the platform-specific hacks are). In web programming each of the browsers is slightly different in about a hundred different ways.
Azaz lényegében fogalmunk sincs, hogy a kliensoldalon mi van, csak feltételezések. Nem tudhatjuk, hogy az a legújabb i7-es nyolc maggal, tizenhat szállal, hatvannégy gigabájt memóriával, vagy egy ötéves, 4.0-s Androidos telefon 512 megabájt RAM-mal. Mert a felhasználónak lehetősége van mindkettőt választani, ha az igényeit kielégíti.

Node egy Androidos böngésző ugyanolyan jó, mint a legújabb Chrome vagy Firefox? Ugyanúgy fog repeszteni? Ha a felhasználó számára lassú lesz az oldal, és emiatt otthagyja, az az ő baja, vagy a fejlesztő hibája?