- sziku69: Szólánc.
- Luck Dragon: Asszociációs játék. :)
- sziku69: Fűzzük össze a szavakat :)
- gban: Ingyen kellene, de tegnapra
- gerner1
- D1Rect: Nagy "hülyétkapokazapróktól" topik
- Luck Dragon: Alza kuponok – aktuális kedvezmények, tippek és tapasztalatok (külön igényre)
- djculture: Az elvileg már senkinek nem kellő HDD-k ára is egekbe emelkedett 4 hónap alatt
- eBay-es kütyük kis pénzért
- Gurulunk, WAZE?!
-
LOGOUT
LOGOUT
Új hozzászólás Aktív témák
-
hiperFizikus
senior tag
-
Mivel void, azaz nincs a függvénynek visszaadott értéke, amivel utána tovább dolgoznánk, igaza lehet a VSCode-nak, hogy valóban kár awaitelni.
Na, megoldódott.
Nem a void a gond, hiszen a semmit is visszaadja, ha await-elsz rá.
Egy ostoba typo volt a gond a meghívott fv-ben.
Már minden jó.
Azért köszi a támogatást, és sorry a vaklármáért!
-
Szia, végül siker, az egyik körben a scope túl nagy volt, és rájöttem, felesleges a szülőket zárni, mindig a testvéreket elég, mert nem lehet több szülő eleve nyitva, csak egy, mert azok is egymás testvérei, így ez egy felesleges kör volt
[link]
Csak kellett 1-2 rúd beigli hozzá
-
hiperFizikus
senior tag
Elolvastam az agresszív zárójelezés eszmefuttatásodat. Egyre hülyébb vagy, ráadásul ebben semmi újdonság nincs, előtted már kitalálták a delegáltakat de sebaj. Végülis tölthetnéd rosszabbul is a túl sok szabadidődet, mintsem újra feltalálni a kereket, csak egyre hülyébb formákban.
Csak légyszi minket kímélj meg ettől!Kérlek linkeld be, linkelj be róla valamit, nem baj ha nem is pontosan ugyan olyan mint az enyém, mert rengeteg időmet elveszi, és ha a te észrevételed segítene, az valóba jó lenne ♥
-
Nézd a falfestés is ezeréves történet, mégis vannak erre szakosodott emberek. És azért a webfejlesztés jóval bonyolultabb dolog, mint a falfestés...
Ez egy fórum. A jellegéből fakadóan egészen konkrét apró elakadásoknál tudunk segíteni, pláne annak, akinek már van valami alap tudása.
De ilyen általános kérdésre, mint hogy nem értek hozzá, de légyszi segítsetek már ingyen berakni egy képgalériát a weboldalamra (de vajon konkrétan milyen weboldalról, milyen keretrendszer, milyen programnyelven, hol van hostolva, milyen a frontend, milyen frontend keretrendszer van használva stb...) ja és tegnapra kellene, mert unom már, hogy mennyi ideje szarakodok vele, na hát az ilyen kérdésekkel őszintén nem tudunk mást kezdeni, mint sok sikert kívánni hozzá, vagy valaki felajánlja, hogy jó pénzért ránéz.
Esetedben a második megtörtént, szóval azért nem volt hiábavaló, hogy írtál ide. -
Nézd a falfestés is ezeréves történet, mégis vannak erre szakosodott emberek. És azért a webfejlesztés jóval bonyolultabb dolog, mint a falfestés...
Ez egy fórum. A jellegéből fakadóan egészen konkrét apró elakadásoknál tudunk segíteni, pláne annak, akinek már van valami alap tudása.
De ilyen általános kérdésre, mint hogy nem értek hozzá, de légyszi segítsetek már ingyen berakni egy képgalériát a weboldalamra (de vajon konkrétan milyen weboldalról, milyen keretrendszer, milyen programnyelven, hol van hostolva, milyen a frontend, milyen frontend keretrendszer van használva stb...) ja és tegnapra kellene, mert unom már, hogy mennyi ideje szarakodok vele, na hát az ilyen kérdésekkel őszintén nem tudunk mást kezdeni, mint sok sikert kívánni hozzá, vagy valaki felajánlja, hogy jó pénzért ránéz.
Esetedben a második megtörtént, szóval azért nem volt hiábavaló, hogy írtál ide. -
Ha köcsög vagyok - és most ezzel az leszek - mondhatnám, hogy hát lehet is haza menni, hiszen ugyanúgy nem lesz itt se megoldás, akárcsak a chatgpt-nél...
Bedobok valami motiválót, fizetek pár nagy tábla csokit, annak megfelelő összeget ha valaki beledrótozza nekem! Aztán lehet hogy magam zabálom fel a csokikat ha kielemzem, 'script kiddy-ként' egy másik működő forráskódból, csak találjak egy agyon nem bonyolítottat..
-
hiperFizikus
senior tag
-
-
hiperFizikus
senior tag
-
hiperFizikus
senior tag
-
És ha kiderül, hogy az egy halva született nyelvhez méltóan egy halott topik?
![;]](//cdn.rios.hu/dl/s/v1.gif)
Szerintem ilyen esetben a legbiztosabb módszer, ha hiperfizikus magával vitázna, és magával beszélné meg ezeket a dolgokat, mint egy átlag szanatórium körüli sétánál szokta. Külön javaslom a hangos vitát, azok sokkal eredményesebbek, ne csak úgy fejben, esetleg magában motyogva játszódjon le a vita.
Nap kommentje. -
hiperFizikus
senior tag
Nem neked akartam válaszolni, de már mindegy is
Ezzel az eszmefuttatással a bolondságon kívül csak az a baj, hogy ezek a programnyelvek ingyenesek, opensource-ok, azaz nem kell újat csinálni azért, hogy megspórold az árukat.
bolondság ide - bolondság oda
: most a Lolita programnyelvem kifejezését csinálom, és most 177 képernyő oldal körül mozgok vele, ami olyan 5310 sor, de mivel még nincs készen és még kavarom, ezért végül is kevesebb is lehet .
Hogy mikorra lesz készen ?
Tudjátok, ha egy kellemetlenebb baki miatt elakadok, akkorborulaz időterv .
-
hiperFizikus
senior tag
-
Jó kérdés. Mivel a localstorage egy faék key-value tároló, ez őrült sérült nem tud lenni.
Ráadásul a javascript csak egy szálon tud futni, szóval ne keverjük össze az aszinkron futást a párhuzamos futással.
Ergo szerintem olyan versenyhelyzet elő tud fordulni, hogy több böngészőfül felülírja egymás adatát, de ettől még nem lesz sérült az adatbázisod.
Azaz egyedül a felülírásra kellhet odafigyelned, már ha erre is tényleg oda kell figyelned, vagy pedig elfogadjuk természetesnek, hogy ha A kulcsot az egyik fül B-vel, a másik meg C-vel akarja feltölteni, akkor az fog nyerni, amelyik utoljára módosította. -
Jó kérdés. Mivel a localstorage egy faék key-value tároló, ez őrült sérült nem tud lenni.
Ráadásul a javascript csak egy szálon tud futni, szóval ne keverjük össze az aszinkron futást a párhuzamos futással.
Ergo szerintem olyan versenyhelyzet elő tud fordulni, hogy több böngészőfül felülírja egymás adatát, de ettől még nem lesz sérült az adatbázisod.
Azaz egyedül a felülírásra kellhet odafigyelned, már ha erre is tényleg oda kell figyelned, vagy pedig elfogadjuk természetesnek, hogy ha A kulcsot az egyik fül B-vel, a másik meg C-vel akarja feltölteni, akkor az fog nyerni, amelyik utoljára módosította.Azaz egyedül a felülírásra kellhet odafigyelned, már ha erre is tényleg oda kell figyelned, vagy pedig elfogadjuk természetesnek, hogy ha A kulcsot az egyik fül B-vel, a másik meg C-vel akarja feltölteni, akkor az fog nyerni, amelyik utoljára módosította.
Ugye a javascript kód egy oldalon egyetlen szálon fut, tehát egyetlen oldalon ilyen nem történhet. Az is feltételezhető, hogy ha több tabon fut ugyanazon a domainen található különféle script, az szintén egy szálon fog futni, dacára annak, hogy külön tabok futhatnak külön szálon. Tehát ebben az esetben egy localStorage.setItem(kulcs, walamiMuvelet(localStorage.getItem(kulcs))) atomi műveletnek tekinthető.
Nem vagyok expert abban, hogy _pontosan_ hogyan is működnek a modern böngészők javascript futtatókörnyezetei, de nagyon remélem, hogy azonos domaint egy szálon kezelnek. Mert ha nem így van, akkor a Jóisten irgalmazzon nekünk, meg a scriptjeinknek, hogy mi lesz a végeredmény, ugyanis ez teljesen szembemegy a böngészőben futó javascript alapelveivel.
-
Szerintem erre nem a getTimezoneOffset kell neked, hanem csak egy sima kivonás
A getTimezoneOffset azt adja meg, hogy adott lokál dátum hány perccel tér el UTC időtől.
A példámban pl. magyar gépen futtatva, magyar időzónára 60 percet ad meg, ami korrekt.
Csak ennyit tud, nincsenek paraméterei.
Csináltam egy js fiddle-t: JSFiddle - Code PlaygroundNagyon szépen köszönöm
Az alap működést azt ismerem. Azt hittem meg lehet paraméterként adni mihez képest viszonyítsa.
A kivonás eszembe jutott, csak szebben szerettem volna megoldani.
A dátum-nál nem igazán lehet a paramétereket megtalálni.
pl a "timezone:" paramétert se találtam sehol, pedig azt tudtam, hogy létezik.
Jó pár órám rá ment mire kiagyaltam, hogy is volt.
Mert itt is pl bal oldalon ott van minden dátumhoz tartozó dolog, de paraméterek szinte egyiknél sincsenek feltűntetve. -
Nem igazán kellene megszakítanod a már futó html lekérdezést. Tegyél ki spinnert, jelezd valahogy, hogy éppen fut egy lekérdezés.
Vaaagy oldd meg szerver oldalon, hogy egy ilyen bagatell html hívás ne tartson másodpercekig.Találtam egy elég egyszerű megoldást rá. Sorszámozom az ajax hívásokat, az aktuális sorszámot elküldöm a szervernek is. Amikor megérkezik a válasz, az tartalmazza a hívás sorszámát is. Ellenőrzöm, hogy az utolsó sorszámú hívásra jött-e, ha igen, akkor megjelenítem a tartalmát. Kicsit Frédi-Béni megoldásnak hangzik.
Nem tart másodpercekig, mert nem bonyolult a feldolgozó része, valami miatt néha 1-1 hívásra a válasz késett és az borította fel a rendszert. Spinnert ez miatt nem tennék bele, mert csak lassúnak tűnne, pedig gyors valójában.
-
hiperFizikus
senior tag
Nem csak ennyi, mert veled ellentétben nekünk fingunk sincs, hogy mit jelent az a, b, e1, mfb stb változó név. Megláttam a kódodat, és csak legyintettem...
De majd egyszer rájössz, hogy csak magaddal szúrsz ki az idióta nevezéktanoddal.Már sztanozsnak is akartam válaszolni, hogy a kedvetekért majd mindent megteszek ♥
Hogy mit jelentenek ? - keveset :
1. a baloldali betűk minőséget, a jobboldali számok db menyiséget .
2. az x, y, z, leggyakrabban a ciklusváltozók .
3. az xa1, y,a1, za1 félék listákat és tömböket .
4. az n számlálót: ; n++ ; n = n + 1 ;
5. az m1, m2, cikusokban stringet fűzök rájuk .
6. c1, c2, c3, c4, c5 sietős dobálózást változókkal, kevésbé fontos sok értékhez
7. e1, e2, e2, e3, e4 amikor sok fontos értékhez részére kellenek
8. az a1, a2, a3, b1, b2, b3 valamelyik kódrészen kezdő értékek részére
*. ilyesmiket ...cm. néha meg nem vagyok tökéletesen következetes velük, mert pl. sietek, mert pl. már fáradt vagyok .
Ez nem igazán nevezéktan, hanem csak a betűszám azonosítókkal villámgyorsan tudok kódot szerkeszteni !
-
Számomra a kérdés továbbra is a miért? Értem én, hogy másként, meg szabadabban gondolkodás. De ha mindez kontra produktív, akkor miért?
Mondok egy példát: az ember általában ülve, guggolva kakil. Évezredek alatt kialakult jó gyakorlat ez. Majd jön egy szabad gondolkodó, és addig erőlködik, míg sikerül neki fejen állva szarni, ráadásul jó hígat. Ezzel akkor ő most mit ért el, mit bizonyított be?"Évezredek alatt kialakult jó gyakorlat ez."
Fun fact, hogy nem jó gyakorlat, csak ez kényelmes. -
hiperFizikus
senior tag
-
hiperFizikus
senior tag
Számomra a kérdés továbbra is a miért? Értem én, hogy másként, meg szabadabban gondolkodás. De ha mindez kontra produktív, akkor miért?
Mondok egy példát: az ember általában ülve, guggolva kakil. Évezredek alatt kialakult jó gyakorlat ez. Majd jön egy szabad gondolkodó, és addig erőlködik, míg sikerül neki fejen állva szarni, ráadásul jó hígat. Ezzel akkor ő most mit ért el, mit bizonyított be?Azt hogy a szabadgondolkodók nem egyformák !
Biztosan készítettek róla egy selfit .
-
Na, kezd végre érdemi beszélgetés kialakulni. Nagy respekt!
Azt előre szögezzük le, hogy PHP-ról régen tovább fejlődtem Asp.Net Core C#-ra
Beszélhetünk backendről és frontendről, de ezt a PHP-zást kérlek felejtsd el. Egy aranyos script nyelv, ami mindenre IS jó, de a PHP és a webfejlesztés története olyan, mint hogy mindenki rendőrnek születik (PHP használata), csak van aki tovább tanul (kb. bármelyik más nyelvet hozhatnám).
Igen, a webshopnál egyetértünk, hogy miért lett ilyen, és ott csak a legszükségesebb dinamikus dolgok vannak js-ezve. Ahol a nagy terhelés + gyors renderelés a lényeg az SSR megkerülhetetlen, a js dolgok többsége is lazy load-olva van.A folkloradatbázist nem akarom védeni, csak elmesélem, hogy miért lett ilyen, amilyen.
Magát az adatbázist és a fölötte lévő API-t (ami ismét meglepetés, de nem PHP-ben, hanem Java-ban készült) a múzeumosok kezelik, fejlesztik. Én (nem egyedül persze) csak a frontendet kellett, hogy elkészítsem, aminél a lényeg, hogy minél interaktívabb legyen.
Tudom, állami megrendeléseknél szokás a pénz lenyúlás, de mi potom pénzből csináljuk, ergo fontos volt, hogy ne évekig pöcsöljön rajta papíron létező 20 fős programozó csapat tíz milliárdokért, hanem szuper gyorsan, nagyon gazdaságosan, határidőkre elkészüljünk (nem vagyunk NER-esek ) .
Így adta magát a vuejs használata. Nem kell mindent nulláról megírni, hanem a lényegre tudunk koncentrálni (API kapcsolatok, bonyolult UI megvalósítások, UX minél barátibb legyen). Ettől még 100%-ig saját produktum az egész. Ha megnézed pl. az egyes eseményeket, ott a szegmens térképet, esemény térképet, szerintem látni fogod, hogy miről beszélek (az API néhol bűn lassú, erről mi nem tehetünk).
Ráadásul azért 2022-t írunk, az SPA-k is egyre SEO barátabbak tudnak lenni (nézd meg, hogy vannak meta tagjeink pl. illetve egészen kicsi js, css méretekkel dolgozunk), illetve sitemap-et be lehet küldeni google-nek az API-ról is. -
Jelenleg is van olyan rendszerem, ami pure js-re alapoz.
Miközben van egy rakás olyan rendszerem, amik meg vuejs-t használnak.
Szerintem kategorikusan kijelenteni, hogy a keretrendszerek használata rossz, és kerülendő, és aki ezeket használja, az már nem is lesz a saját munkája, butaság.
Nyilván írod ezt, mert fogalmad sincs, hogy mi is az, és mire jó egy angular / react / vuejs és mikor mit érdemes használni.Abszolút eset függő, hogy mikor érdemes valamelyiket alkalmazni a fentiek közül, és mikor érdemes pure js-el menni. Kategorikusan kijelenteni, hogy csak ez vagy csak az butaság.
Amivel nem is lenne baj, ha nem pont kezdőket vinnél ezzel félre, szóval sajnálom, de ezúttal muszáj volt beleszólnom.Kettő példa mindkét esetre:
1. Orvostechnikai Eszközök - Orvosi Eszközök Boltja - Medimarket.hu - pure js, kivétel a kosár (knockoutjs), checkout (knockoutjs), és a termék oldali képnézegető (sveltejs). SEO és pagespeed miatt webshopoknál általában kerülendő a nagy frontend keretrendszerek használata, itt többnyire server side rendering van használatban.
2. Folklóradatbázis | Folklóradatbázis (azureedge.net) - teljes egészében vuejs-el készül, egészen sokat tudó komplex rendszer, maximálisan saját kód, leszámítva a vuejs-t. Néprajzi múzeum folklor adatbázisának kutatók felé szánt publikus adatbázisa, nem kritikus a SEO, és a pagespeed.Látod, ez egy jelentős különbség edari hozzáállásához képest. Te ész érvekkel és példákkal cáfolod meg most a kijelentésemet, ami így elfogadható és érthető.
Azt természetesen nem lehet elvárásként kezelni, hogy pl az említett Webáruház amelynek szerves része az adatgyűjtés / adatmódosítás, regisztrált felhasználók kezelése, etc. szimplán PHP & SQL kombóval működjön. Megoldható persze, de nem feltétlen éri meg vele bajlódni. Plusz ugye PureJS-el kivitelezhetetlen
Megnéztem viszont a Folklóradatbázist is. Látom, hogyan épül fel és mit csinál, illetve azt is, hogy miért így.
Viszont az is itt van a szemem előtt, hogy konkrétan én magam is építettem hasonlóképpen működő site-ot, igaz, PureJS használatával, mert leültem megírni. Amikor viszont azt megosztottam veletek, elég negatív hangvételűek voltak a kommentek, pl hogy "Miért JS végzi a CSS feladatát?", "Miért kell az adatokat máshonnan betölteni?", etc.
Látom azt is, hogy itt nem csak adatok megjelenítéséről van szó, mint nálam volt. Szintén van adatbáziskezelés, regisztráció, felhasználói adatbázis, stb.
Persze a mögöttes dolgokat nem láthatjuk (pl PHP, SQL), már amennyiben vannak.
Ezzel a megoldással egyébként az a baj (szerintem és aszerint, amit erről hallottam, tehát lehet, nincs igazam), hogy a böngészőmotorok általi előre-sorolását mindössze annak köszönheti, hogy mekkora napi látogatószámmal rendelkezik, mert habár adatok tekintetében folyamatosan bővül, az alap HTML közben mit sem változik. -
-
PHP -> szerver oldal, érted a PHP egy szerveren fut, még ha az történetesen localhost is, azaz a te géped a szerver.
Ajax -> kliens oldal, a js böngészőben fut, bárkinek a gépén, ne zavarjon meg, hogy ez a bárki éppen te magad is lehetsz a saját gépeden, ami egyben PHP szerverként is funkcionál a fejlesztés idején.Szerver és kliens oldal, két egymásról semmit sem tudó, tökéletesen független dolog, amik HTTP-n keresztül kommunikálnak.
HTTP request: bármelyik oldal tud http requestet indítani és válasz json-t fogadni.
Api-hoz ez úgy jön, hogy a böngészőben futó kliens oldal Ajax-al (régen, most már Fetch-el) tud http requestet indítani a szerver oldal felé.
És dehogynem kellett, amikor a kártyákat lekérted a js kódodban, a 4-dik sor fetch parancsa egy HTTP GET hívást indít az api felé.
De nyugi, aggodalomra semmi ok a belinkelt dokumentumok pont erről magyaráznak hosszan, és mi is megpróbálunk a magunk szerény módján segíteni. -
Elküldtem a tisztán javascriptes dokumentációt. Erre ezt írtad vissza: "A link nem jó, mert jquery, php ..stb, és emiett érthetetlen. Engem csak js alatt érdekelne."
Szóval, ha téged csak js alatt érdekel a fetch api, ami egyébként egy js api, és a küldött dokumentáció csak js dokumentáció, akkor mégis mi az isten nem érthető rajta, és hogy jön ide jquery, php stb... ???
Nem nézlek le, csak hülyeségeket írsz és tippre jóval hamarabb írsz, kérdezel hülyeséget, minthogy elolvasnád, amit küldtem, illetve átgondolnád, hogy hányadikán is van elseje. -
Tényleg nem kell queryselector, a kolléga hibásan mondta.
Class nem erre való. Persze azzal is meg lehet oldani, de ebben az esetben az id tényleg szebb megoldás."fletch" api-ra nem kereshettél valami túl erősen.
Vagy már akkor is hibásan írtad a nevét
Fetch API - Web APIs | MDN (mozilla.org) - itt ami inkább érdekes lehet neked, az a Related topics alatt a using Fetch API, az tele van példákkal.Köszönöm a választ.
Miért "szebb" az id?
A link nem jó, mert jquery, php ..stb, és emiett érthetetlen. Engem csak js alatt érdekelne.
Sok minden jön ki a keresésre, yt videók, minden, de vagy csak beszélnek róla, vagy alig mondanak valamit, vagy össze vissza mindent egyben, nem csak js. -
hiperFizikus
senior tag
-
hiperFizikus
senior tag
Abba ne hagyd! Ráadásul nem vagy egyedül, van itt még jó pár hasonszőrű kolléga. Engem nagyon szórakoztattok, ráadásul ki tudja, hátha más nagy zsenik is így kezdték.
Azért a helyedben lehet elgondolkoznék egy barátnő beszerzésén inkább.Barátnőt ? - csak ha ténylegesen Magyarországra költözhetnék .
-
Nem azt írtam, hogy a ts-nek semmi előnye, csak hátránya, hanem azt írtam, hogy a nyakló nélküli használata kontraproduktív is tud lenni (hangsúlyozom, kisebb projekteken), azaz van olyan eset, ahol az előnyei már nem tudják ellensúlyozni a hátrányait.
És igen, nyilván van csomó eset, ahol az előnyei vannak túlsúlyban. -
Sőt nem 1-2 olyan kisebb frontend projektet láttam, ahol totál kontraproduktív a ts erőltetése.
Végy egy kis frontend projektet szórd meg react + readux + rxjs + typescripttel (hm, így nézve már hirtelen nem is kicsi a projekt), máris hónapokig 4-5-en fognak dolgozni rajta, és a végeredmény is röhej szar lesz, végül mindenki elmenekül a karbantarthatatlan foskupacról, amibe belement 1-2 fejlesztői év, de amúgy 2 fejlesztő max 1 hónap alatt röhej lazán (és a legfontosabb, hog jól, karbantarthatóan), össze tudta volna rakni.Én láttam már olyan "csapatmunkát", ahol egyebet sem csináltak, mint keresték a felelőst, rugdosták egymást kifelé a cégből, meg pocsékolták a project-re szánt pénzt teljes sebességgel. Ha most filozol a magyar állami szféra hasonlóságain, lehet, nem tévedtél el nagyon. Olyan helyre a typescript tökéletes
Félre ne értsd, nem azt az ördögtől való véleményt kívánom védeni, amit @sztanozs leírt, mert azért legszívesebben fényes nappal kötözném cölöphöz az ürgét, és raknék alá gyújtóst élő egyenes YouTube közvetítésben példamutatóan mindenki okulására - burn b1tch burn !
- viszont van a tolvajok igazsága is, és annak fényében vannak éppen "szélesebb-látókörű" előnyök. -
Akkor úgy mondom, hogy nem így érdemes. De nyilván mindenki olyan szar megoldást kókányol össze, amilyet akar. Csak aztán ne a programnyelv legyen az oka, ha szarul fog működni, és minden baja lesz.
Már miért ne a programnyelv hibája legyen?
Python, go, typescript, bőven van rühellnivaló sza* amire ráfér a negatív marketing -
https://javascript.info/fetch-api
Ez jó kérdés. Tudtommal redirectkor a payload csak az eredeti url-re megy, a redirektelt címre nem fog, fel is vetne biztonsági problémákat. Mivel írtad, hogy a szerver oldalt te vezérled, miért ne tudnád a payloadot tovább passzolni mondjuk az urlben.
-
De érted (vagy nem, akkor is megpróbálom, légyszi ne szívd mellre). Ezt két lépésben kell megcsinálni.
1. lépés: eltünteted a számokat bármilyen hihetetlen is, amíg nem tünteted el őket, addig sosem lesz egyenlő az inp51ort és az inport21 (juhú, már ezen is mekkorát röhögtem, mert az import lenne a helyes, de ne legyünk nyelvtan nácik, elsőre sikerült megállnom, másodikra elbuktam, my bad).
2. lépés: összehasonlítod a maradék stringeket, és yaaaay pont azt az eredményt fogod kapni, amit elvársz.
Nyugi értette itt mindenki a problémád
Amúgy meg számomra addig nem igazi probléma a probléma, amíg jsfiddle, codepen link nincs benne, addig csak beszélgetek, szórakozok, élcelődök. De ezt tudhatnád. -
De kár, hogy nincs Like gomb PH!-n
Néha már tényleg úgy érzi az ember, hogy van aki minimál google-özés nélkül (vagy angoltudás nélkül? de akkor minek erőltetni a programozóságot, kb. mintha vakként akarnék festő lenni) is ide esik be a legapró-cseprőbb hülyeséggel is.[Link] Kár, hogy nincs a PH!-n Bann gomb
Úgy bírom, hogy az EGOizmusban szenvedő alanyok (veled az élen) nem értik meg a kérdést, hanem kitalálnak helyette mást amit megválaszolnak, mindezt csak azért, hogy utána le lehessen degradálni a kérdezőt... Az itt leírt válasznaklóf*szt, még az sem történt a legkevesebb köze SINCS a kérdésemhez!
Itt nem én vagyok az, aki nem hajlandó rákeresni semmire (a nyelvtudásom pedig köszöni, jól van) hanem ti vagytok azok, akik képtelenek elolvasni, értelmezni a kérdező kommentjét. Gondolkodj egy kicsit és rá fogsz jönni: Ebben itt nem én vagyok a hülye!Bzozoo: Ki a retek mondta azt, hogy el akarom tüntetni belőle a számokat? Senki! Nem ez a feladat! Hanem az, hogy a program egyenlőnek tekintsen 2 stringet akkor, ha azokban csak számbeli eltérés található. Ettől függetlenül a számok meglehetősen fontosak!
Szerk.: Ha el akarnám távolítani a számokat és úgy összevetni, majd pedig utólagosan ismét egyesíteni a Stringeket a számokkal, akkor megtenném. Mindössze egy egyszerűbb és szebb megoldásra lettem volna kíváncsi!
-
LOL No comment
Matematikus vagy, aki állítása szerint tud deriválni, de azért fórumban rákeres, hogy 2X5 vajon mennyi is, mert még sosem volt szüksége eddig pont a szorzótáblára
Bearanyoztad a napom, köszönöm!
Peace!Úgy érzem sok minden nem értesz még abból a kevésből sem, amit leírtam. Na ez a No Comment
-
Tanulni mindig jó és hasznos. Kiábrándítani nem akarlak, de ez nem olyan ötlet, amiből valaha is haszon lesz, mindegy, hogy a google látja-e vagy sem.
Tanuláshoz irányok, amiket javaslok:
1. Szerver oldali frameworkök. Ha eddig PHP-ztél, és elégedett vagy vele, akkor valami értelmesebb PHP frameworköt javaslok, mint pl. Laravel, Yii, vagy azt se tudom mik a trendi PHP frameworkök mostanában.
2. Kliens oldali frameworkök. Ezek valóban nem barátai a SEO-nak, de manapság egyre kevésbé megkerülhetőek. Vuejs, React, Angular, Svelte (még talán ez utóbbi a legmegfelelőbb a SEO barát weboldalak kicsit erősebb interaktív irányba felokosítására).
3. Ezt csak nagyon óvatosan mondom, mert ez nagyon szubjektív, de én a helyedben elgondolkodnék az aranyos, játszós nyelv PHP helyett (öhm, tudom hogy most szereztem egy rakás ellenséget, és sokan a szívükhöz kapnak), valami komolyabb, teljesítmény orientált nyelvre váltani backenden pl. Java (Spring), C# (Asp.Net Core), Go (nem tudom milyen frameworkök léteznek hozzá) mennek mostanában. Én személy szerint az Asp.Net Core-ra esküszök, de mondom ez nagyon szubjektívKöszönöm, hogy ilyen részletesen leírtad!
@Bzozoo: Neked is köszönöm.Mindkettőtöknek igaza van amúgy, mind a naiv és béna kivitelezésben, mind a lehetőségek ismeretének hiányában. De ezért kérdezek, hogy tanulhassak.
-
-
"viszont mivel az oldal ettől még görgetés után dinamikusan épül fel" - oké, akkor elárulom azt is, hogy a Google majdnem tökéletesen ignorálja azt a tartalmat, amihez görgetni kell.
Igen, ezért csináltam úgy (kényszer-öszvérmegoldásként), hogy a HTML tartalommal feltöltve és frissen tartva van szerver oldalon, így a Google is látja és indexeli - aztán a kliensen betölt, és a JS lecseréli a legfrissebbre.
Na de ez se nem szép, se nem hatékony. Rossz irány volt.
Úgyhogy ezt el is engedem, és hagyom a dinamikus tartalomgenerálást. Lesznek szerver oldalon pár percenként PHP-val frissített, statikus, tartalommal szépen feltöltött oldalak, a Google-nek lesz mit indexelnie. Nem lesz olyan szép és kreatív mint most (amit amúgy nagyon szeretek), ellenben nem csak a családom és én fogom ismerni és látni... Remélhetőleg.Így igazából használom azt a szerver oldalon generálós módszert, amit a mostani megoldáshoz csináltam (PHP):
1) HTML template jól elkülöníthető kulcsszó-sztringekkel (pl. ahova az első cikkhez tartozó kép linkje megy, az websiteData_imageSource_1, ahova az adott title, az mondjuk websiteData_Title_1 stb.)
2) PHP, lekéri a friss adatokat SQL-ből, aztán az eredményeket egy egyszerű sztringcserével a kulcsszó-sztringek helyére pakolja, majd elmenti (a megfelelő mappába index.html-ként).Oké, nagyon alap-alap-alap megoldás, de működik. Vagy tanuljak valami normális keretrendszert inkább? Semmit nem ismerek, sose használtam, csak pár nevet láttam még: React, Vue.js, Next.js, ilyesmik.
Szívesen tanulok, ha azt mondjátok, hasznos lehet, és hogy a mostani faék-egyszerűségű módszerem nem jó. Ehhez szívesen vennék egy ajánlást, mit tanuljak meg. (Bár azt se tudom, a jelenlegi cPaneles szolgáltatónál telepíthetek-e egyáltalán bármit, ami ezekhez lenne szükséges.)A cél: híraggregátor oldal. A jelenlegi formájában olyan, mint a Fb, görgetsz, töltődik. Szeretem, tetszik, de sajnos rossz ötlet volt. Nem Google-barát, ebből nem lesz haszon őszire.
Inkább váltok valami 1.000.001. standard híroldal-kinézetre. Ehhez mondjuk szerintem nem kell semmi extra, elég a PHP --> SQL --> PHP --> HTML irány, de hátha ti mást mondotok.Köszönöm.
-
Nagyon tetszenek az ilyen szép és egyszerű megoldások! Köszönöm.
(Remélem, lassan (gyorsan) már nekem is beugranak majd az ilyenek, és nem csak extra nagy körökkel tudok célba érni. ) -
Ha egy url /-el kezdődik, akkor az jelenti azt, hogy a root url-hez képest.
Azaz a helyes megoldás a "/js/script.j?v=1.0.0"
A teljes elérési útvonalas megoldás is jó még, de ennek csak akkor van értelme ha pl. CDN-t használsz.
A // kezdetű ugyanez, csak az megengedi mind a http, mind a https-t, egy időben divat volt, de http-t már senki nem használ, szóval értelmetlen.Köszönöm szépen a részletes magyarázatot! (Már sokadjára!
) -
Ne lighthouse-ban (böngésző F12) nézd, hanem a pagespeed weboldalán a google-nek: PageSpeed Insights (web.dev)
És itt is igaziból mostanra egyedül a mobilos szám számít, a google már csak ezt veszi bele a rangsorolásba.Hú, akkor máris oda a sikerélmény. Ez gyors volt.
Viszont ahogy nézem, lassú nettel (Lassú 4G emulálása) csinálja azokat a teszteket, és attól azért nem lehet csodát várni egy képeket (is) tartalmazó oldal esetében.
De végig megyek mindenen, hátha valamit tudok még faragni.
Köszönöm. -
Látod - látod :D
Itt kezdődik a webfejlesztés. Cms fölé template-et minden hülye be tud húzni, az fölé minden hülye össze tud kókányolni valamit. Aztán meg megy a csodálkozás, hogy miért lett szar a végeredmény.
Örülök, hogy te normálisan állsz hozzá.Meg is érte rendbe rakni:
Bár még van mit csinálnom rajta, de legalább egy kis sikerélmény.
Köszönöm a tanácsokat. -
Css és Js file-okat valóban érdemes összevonni (ezt hívják bundle-nek).
Viszont ettől függetlenül a SEO legnagyobb barátja a server side rendering. Minden más, ami nem server side renderelődik, kétesélyes hogy megjelenik a google bot számára.
800kbyte js, óriási. Ha a google bot valami css, js-t nem tud X másodperc (de ez inkább kisebb, mint 1) alatt betölteni, akkor inkább hagyja a fenébe, nincs ideje szarakodni a lassú weboldalakkal.
Nem véletlenül írtam le, hogy nem kellene mindeféle szart behúzkodni kliens oldalra, mint pl. axios, amik csak totál feleslegesen növelik a bundle size-ot, és lassítják le az oldalt, rontják a pagespeedet. Cserébe legalább semmit sem adnakKöszönöm a tanácsot.
A 800kB-nyi JS-t sikerült 250kB-ra összehúznom, és a felesleges CSS-eket is kigyomláltam, (eddig észre sem vettem, hogy ilyen rengeteg felesleges volt benne...) így a kezdeti 1MB-ból lett 650kB. Ami még így is sok, de majd innen folytatom.Viszont most már egyértelműen szóba áll velem a Google - legalábbis a fájlok mennyisége már nem zavarja.
A server side renderingen sokáig agyaltam, hogyan lehet megoldani, de trükkös, mert dinamikus a tartalom (görgetés után tölt az újabb és újabb tartalom), és ezt így nem lehet szerver oldalon generálni.
Arra gondoltam, hogy segítsem a SEO-t, pár percenként belegenrálom az index.html megfelelő részébe az aktuálisan legfrissebb 4 elemet (4-esével tölt görgetésnél), így az szerver oldalon lesz, és a Google is egyből látja. Aztán betöltésnél törlöm azt a div-et, és jön helyére egyből a friss.
Ez a terv egyelőre - jobb több nap alatt sem jutott eszembe.Köszönöm a segítséget.
-
jsfiddle, codepen működő példát ha küldenél nekünk, talán nagyobb kedvvel nézne rá bárki is.
Működni működik, csak nem tudom, hogy nem csinálok-e felesleges loopokat. [link]
Átírtam sima JS-re, nem tudom pontosan, hogy hogy működik a jsfiddle TS/Babel.
@inf3rno:
Optional Chaning (?.) MDN -
A kettőt összekombinálni is lehet ám
Pl. csak a html file-ra beállítani, hogy mindig töltse le a böngésző. A többi file-t pedig hagyni a böngésző a megadott verzió szám alapján eldöntse, hogy le kell-e töltenie.Mert a nálad lévő módszer tök jó, de mi van akkor, ha maga a html file cachelődött be a böngészőben? Akkor hiába raksz ki egy új html file-t, amiben megemelted a css, js verziókat, ha erről a böngésző mit sem fog tudni, és vígan használja az előző html-edet, benne a régi verziójú css, js hivatkozásokkal?
Na ez teljesen jogos.
Akkor módosítok én is. @nevemfel: De itt nem csak arról szól a dolog, hogy ha a "?v=1.0.0" lett cache-elve, akkor ha az a verzió át van írva bármi másra (tehát nem egyezik), akkor tölti le újra? Mármint a fájlokba ez nem néz bele, hogy abban milyen verzió van benne, hanem ez itt a html fájlban a változtatás csak kvázi egy flag, hogy halló, kliens, töltsd el újra.
Vagy rosszul használom? -
Az a baj, hogy ez nem js kérdés.
Önmagában, amit vizsgálnak valóban tud biztonsági probléma lenni, azaz a hiba jelzésük korrekt.
Bármikor előfordulhat, hogy amit ily módon betöltesz, abban van valami vicces javascript.
Ezt ők nyilván nem is fogják tudni helyetted megoldani. Gondolnám, hogy valahogy lehet azért a checkmarx-ot paraméterezni, hogy mire riasszon be, és mire nem.Szóval a lehetőséeig szerintem az alábbiak:
1. újraírod a programodat, hogy abszolút ne használj ilyen js oldani utólagos kód betöltéseket (pl. mindent server side renderelsz, vagy ezeréves jquery helyett elkezdesz modern frameworköket használni Vuejs/React/Angular)
2. felparaméterezed a checkmarxot / felveszed a supportjukkal a kapcsolatot, hogy ignorálja ezt a biztonsági hibát.Sajnos jelenleg ez a verzió van, és a support válaszát várom.
De jelenleg nálunk sok, az elődöm által írt tool megy ilyen és hasonló megoldással, tehát az újraírás az elkövetkező időszakban nem opció.
A kérdésem ide azért jött, hogy lehet-e megoldás js/jquery-ben, ha support nem fogja ignorálni a hibát. -
Szia!
Szólok, hogy nem azért nem válaszolunk, mert nem foglalkozunk a problémáddal, hanem mert nem küldtél példa jsfiddle / codepen kódot, amúgy meg szvsz rajtad kívül senkinek fingja sincs, hogy mi lehet az a checkmarx
Ok, értem.
Checkmarx integrates automated software security technologies into DevOps
A probléma, ami most kezdte el csak zavarni a rendszert: DOM-based vulnerabilitiesjsfiddle a kódot most dobtam össze (ne a szerkezetét nézzétek
), illetve a stackoverflow-ról szedtem egy escapeHTML megoldást, próbaképpen...
"data" lesz amit visszakapok, ez lehet ilyen formában, vagy json-ba ágyazva, igazából mindegy, ezért ezt használtam.Most nálam a sima .append van beállítva erre checkmarx ezt mondja nekem: "The application's $.post embeds untrusted data in the generated output with append"
Sajnos legtöbb esetben csak url címre és sima string-re találok megoldást, az én verziómra nem.
Az a hab a tortán, hogy konkrét megoldási lehetőséget sem ajánl fel checkmarx, csak a sebezhetőséget írja le, tehát nem tudom milyen módon tudnám a számára elfogadható megoldást megcsinálniBár nem fontos szerintem a program php-s, és a $.post() is egy php-t hív meg, onnan jön vissza az eredmény(data) ide.
Remélem így elég lesz/lehet
-
![;]](http://cdn.rios.hu/dl/s/v1.gif)
Nap kommentje.
: most a Lolita programnyelvem kifejezését csinálom, és most 177 képernyő oldal körül mozgok vele, ami olyan 5310 sor, de mivel még nincs készen és még kavarom, ezért végül is kevesebb is lehet . 
Új hozzászólás Aktív témák
- Forza sorozat (Horizon/Motorsport)
- Okos otthon - Home Assistant, openHAB és más nyílt rendszerek
- Kamionok, fuvarozás, logisztika topik
- Vicces képek
- Arc Raiders
- Honor Magic7 Pro - kifinomult, költséges képalkotás
- Allegro vélemények - tapasztalatok
- Hálózati / IP kamera
- Miskolc és környéke adok-veszek-beszélgetek
- Projektor topic
- További aktív témák...
- 24 magos AMD Threadripper alapú munkára kiváló félgép, 128GB RAM-mal
- HP ZBook Fury 15 G7 i7-10850H 32GB 512GB SSD Quadro T2000 4GB FHD HUN bill, szép állapotban eladó
- Eladó MacBook Pro 16,1 2019 CTO
- új 0 km es garanciás lenovo loq rtx 5050 8gb
- Eladó teljesen újszerű karcmentes Samsung Galaxy Watch Ultra
- VADIÚJ Microsoft Surface Pro 12 12" Snapdragon X Plus 16GB 256GB Tüzes Ezüst gar:2028.02.09.
- Xiaomi Redmi Note 13 Pro 5G 256GB, Kártyafüggetlen, 1 Év Garanciával
- 64GB DDR5 RAM Kit!
- Apple iPhone 15 Pro Max Blue Titanium 512GB használt karcmentes 100% akku 6 hónap garancia
- Dell 7430 2in1 360 áthajtós touchos! i7-1265U 16GB 1000GB SSD FHD IPS 1 év gar
Állásajánlatok
Cég: Laptopműhely Bt.
Város: Budapest