Hozzászólások

Ez is turhetobb mar, ja.

Nem offendelodok, nem is szoktam vagod mar. De meglepodtem az ajanlaton, ez miben fed barmit is abbol amit irtam hogy zavar? Dugig van vizualis (szoveg es szam) zajjal, szintugy mint a tobbi fentebb emlitettek.

Meg a masodperc mutato is feleslegesen zavaro tenyezo, amit ki lehet valtani. Nem stopper ugye. Digitalis kijelzes elonyeit leszamitva ha maradnak a full mechanikus analog elkepzeleseknek, akkor inkabb mar ilyesmire gondolnek:
rwurl=https://imgur.com/CZTaKaU

rwurl=https://imgur.com/MP7gBFM
(ez mondjuk perfect lenne ha nem "disz" lenne az az 5-os, hanem az aktualis napot mutatna.)

rwurl=https://gearmoose.com/wp-content/uploads/2019/07/Miansai-M24-II-Watch.jpg

rwurl=https://imgur.com/2cmunz5

rwurl=https://www.gearhungry.com/wp-content/uploads/bfi_thumb/TIDno1Watch-6qym...
(masodperc mutato kiiktathato)

Ezekre ranezek es bumm, azonnal latom pontosan az idot. Letisztultak es szep kontrasztosak is, ha rosszak a latasviszonyok. En pl igy kepzelem el a felesleges vizualis (szoveg es szam) zaj nelkuli orat.

Ha nincsenek is oraszamok szamokkal kiirva, de a fo vonal-vezeto bejegyzesek a pontos orakra valoszinuleg jo otlet ha ott van, mivel ellenkezo esetben nehezkes lehet elso ranezesre megallapitani az adott (reszleges) orat a kismutatobol.

Van rá remény, hogy a "régi" beágyazások is életre kelnek valamikor?

Of korsz, tervben van. Van bulk-beagyazo segedprogim is amit nem reg reszeltem.

Csak addig nem akartam nekihasalni amig ki nem simitom a legtobb gyermekbetegseget a beagyazo motorral. Ami mostanra mar nagyjabol helyen is van.

Csak vigyaznom kell hogy ne nyomjam tul es lassan szetosztva vegezzem, mivel sok API csak meghatarozott lekerest enged havi szinten, mint pl az imgur. Igy ha azon tullepunk, akkor addig nincs friss beagyazas azon keresztul.

Meg egyszerre pl tobb 100 beagyazas bulkban ki is tudja fektetni a szerot, epp most tesztelgettem nem reg, igy arra is kell figyelnem hogy csak pici adagokban csinaljam, mondjuk egy heti anyag egyszerre, vagy csak par napos.

***

Masik kiotlott resz-megoldasom erre a kerdesre, hogy atirom kicsit a kimutatas motor mukodeset, es pl a kommentekben hash ID-k helyett csak siman az URL-eket hagyja meg motor. Es utana oldalmegnyitasonkent javascript-ben hash-eli a bongeszo oket, majd ugy kuldi egyesztetni a szerverrel.

Ez egy kis extra proci munka a kliensnek minden oldalnyitasnal. De cserebe azt nyerjuk vele, hogy minden "not found" URL-t fuggetlen ettol ki is tudok iratni a kijelzovel, azaz visszamenoleg legalabb link szintjen minden elerheto es kattanhato lesz.

300,000 visszamenoleges kommenttel elboldogulashoz valamennyivel megfontoltabb utemterv kell, mint "essunk neki mindnek". :)

Illetve megoldható, hogy az előnézet mégis triggerelje a beágyazást? Ha jól értem, egy tartalom egyszer embeddelődik függetlenül attól, mennyi postban hivatkozunk rá, így gondolom az előnézeti beágyazás sem okozna extra melót a masinának.

Megoldhato vegulis es igen, nem lenne merheto extra teher a gepnek. Ranezek mit tehetek majd erre is.

Ha mar orak, nem zavar benneteket rajta a csomo vizualis zaj?

Pl en gondolom ha vennek egyet, leheto legletisztultabbat valasztanam. Kerulnek minden felesleges szam es szoveges informaciot, ami elterelne a figyelmem arrol hogy a leghamarabb eszrevegyem ha rapillantok hogy hany ora. Azon felul vadulhatnak grafikai design teruleten, amennyire jolesik es igenyes.

A fentibb Orient kepnel rakat szam van rajta mindenhol, azok is maximalisan kicsik es kb egyforma meretuen, mintha csak torekedtek volna hogy minel nehezebb legyen kiolvasni az idot, ha ra-ra pillant az ember, kulonosen elegtelen fenyviszonyoknal. Odonke friss orajan se ertem hogy minek oran belul, es kivul is bejegyzeseket huzni, egy helyen nem lenne eleg? Viszont jo rajta hogy mutatja szambelileg, es irasbelileg is a napot.

PL a MIDO Commander Gradient legalabb kozelit a johoz mar. Nem sajnaltak vadulni design teruleten, de joval kevesebb zajjal. A koron belul az a felig attetszo szamsor felesleges zaj, eleg ha csak a mechanikus alkatreszeket latom. Es talan a kuslo koron megnovelnem a font-nagysagot, hogy meszebbrol rapillantva, vagy fontosabb, elegtelen fenyviszonyban is konnyen latszodjon. Itt is majd hogy nem hunyoritanom kell hogy kiolvassam, es az az eles tores az uveg szelen se segit a szitun, amivel megduplazodnak/megtornek a latott anyagok alatta, pedig ezek maximalisan beallitott marketing kepek/videok:
rwurl=https://i.imgur.com/eQEREle.png

azért kell cp-zni egyébként a devnullt mert valsz folyamatosan nyitva van a file és ha letörölnéd csak a file tünne le de a helyet ugyan úgy foglalná:)

oh ertem mar hogy oldja meg akkor. Mivel a fajl hivatkozasok csak linkek a linuxban. Igy ha hasznalva van a fajl es torlom, akkor a hivatkozasat nyirom csak ki, azaz unlinkelem. De a hely attol meg el lesz foglalva, mert a process meg tartja a kapcsolatot vele.

Igy meg csak telepakolja "semmivel" ugye, effektiv lenullazva azt.

szerk:
never mind, tul hamar kommenteltem. Idokozben sikerult a vegere jarnom, a "ncdu" brutko jo es konnyen kezelheto kis szerszamnak fest ilyesmire.

Ahogy levadasztam, par nap alatt felzavarta mysql logfile magat 25+ gigara. Impressziv.

Najsz, ahogy belekukkantottam tail-el, a MariaDB ezekkel szorgoskodik masodperc toredekente teleirkalni az adatbazisunk error logfajlat, mind a 25gigaban valoszinuleg:
rwurl=https://i.imgur.com/bY6q5fN.png
rwurl=https://i.imgur.com/JXXGcQM.png

Ejjel szerintem leallitom az RWt egy keveset, backuppolok mindent es megprobalok a vegere jarni. A novekedes tendenciat vizsgalva addig ki kell huzza a SSD kapacitasa mielott csordultig telik es gubancok lepnek fel.

Ahogy nezem lehet valami szoftver/verzio bug lehet, masoknak is kijott es nekik is felzavarta a fajl tartalmat brutalis magassagokba sebesen:
https://stackoverflow.com/questions/47831725/why-cant-i-upgrade-mysql-in...

Remelhetoleg a fixek amiket javasolnak a fenti oldalon helyreteszi a szitut nekunk is.

rwurl=https://i.imgur.com/4bdfJZH.png

Az a napi szinten izmosan felfele kuszo disk kapacitas taplalkozas eleg meredeknek hangzik. :D

Linux sys-admin tesok, mi taplalkozhat ilyen sebesen es hogy lehet a legesszerubben a vegere jarni? Ha megtellik fullra a disk szerintem gondban leszunk.

A tobbi teljesen kosernek nez ki, proci kapacitassal legfejjebb 60%korulig szoktunk elmenni. A memoria csordultig kihasznalt, de minden progi cachel ezerrel igy ertheto, a kihasznalatlan memoria ugye elvesztegetett memoria.

szerk:
never mind, tul hamar kommenteltem. Idokozben sikerult a vegere jarnom, a "ncdu" brutko jo es konnyen kezelheto kis szerszamnak fest ilyesmire.

Ahogy levadasztam, par nap alatt felzavarta mysql logfile magat 25+ gigara. Impressziv.

Ahogy sejtettem is es beszeltem rola a masik bugtopikban, bongeszo kompatibilitas kerdes volt a levesben. A Chrome tipusu bongeszok nem kovetik a szabvanyos windows.location.hash (anchoring) javascript utasitasokat.

Preposterous.

Foxnal ezert nem volt semmi baj vele, se nem lattam gubancot (sem azoknal akik fox derivans bongeszoket hasznaltak).

Irtam ra par perc alatt egy check-et, ami megnezi hogy milyen motor van a bongeszo alatt, es ha Chrome fajzat, akkor betolti az azzal mukodo kodot, a tobbi bongeszore meg a standardizaltat. :)

A link mindenkinel Mr. Spock-ra kellene ugorjon:
https://rewired.hu/comment/265291#comment-265291

Atirtam az aszinkronos kod szeleteket stabilabbra, es talaltam meg egy helyet a kodban ahol elfelejtettem ellenorizni a protokolt (es igy potencialisan http-re kuldte a szignalt, allando https helyett).

Itt (https://rewiredhu.cf/comment/265026#comment-265026) a bugtopikban targyalt kiotlott proof-of-concept megoldasbol kiindulva teljesen kukaztam az eddigi elkepzelesemet a requestAsync() fuggvenyre a RWHttp modulunkban, es kicsereltem frissre.

Eddig csak a sima szinkronos HTTP request-eket kezeltuk cURL-el, es custom HTTP kommunkaciot kezelo kodsoraink voltak ha aszinkronost akartunk elerni. De mostantol az aszinkronosak is cURL-ra vezetodnek at. Csak mivel a cURL nem tud aszinkronosan dolgozni, van egy kis kozvetitokent mukodo "worker" mikroszerviz szolgaltatasunk az RW forum mellett, aminek az a dolga hogy allandoan figyelje a delegalni valo beagyazas melokat, szoljon a szeronknak ha megkapta oket, es osztogassa szet oket a megfelelo helyekre azutan.

Igy mostmar nem kellene random hogy osszetorjon a kezdeti fazisban, vagy valahol menet kozben a beagyazas folyamat. Teszteltem rakat beagyaznivaloval is egyszerre, darabonkent, utolagos szerkesztesekkel es hasonlo korulmenyek kozott.

A tanulsag: nem jo otlet custom kodot irni egy brutal komplex szabvany kezelesere mint pl a HTTP protokol mert rakatnyi pitfall akadhat menet kozben, meg ha csak minimalis mennyisegu adatokat is kuldunk, azt is sajat magunk fele a szerverrol. Hanem hasznaljunk millio ember altal csatarozasok kozepette tesztelt library-t, mint a cURL pl. Ezek a libraryk robosztusan kezelik szinte az osszes hibatipust, ami elo tud torni. Ha nem is tud valamit a cURL amire szuksegunk van (aszinkron pl), akkor oldjuk meg kozbeiktatott trukkel a szukseges reszereket, es a megoldas utan folytassuk a tovabbi reszeit a munkanak cURL-el. Ez tortent most fentebb. :)

rwurl=https://i.imgur.com/EnVNdVP.jpeg
rwurl=https://i.imgur.com/HDNHJnv.mp4
rwurl=https://i.imgur.com/LLHeFPH.mp4
rwurl=https://i.imgur.com/YKSiSg2.mp4
rwurl=https://i.imgur.com/FJppVsw.jpg
rwurl=https://i.imgur.com/JB0KcA0.mp4
rwurl=https://i.imgur.com/IPqpgEk.jpg
rwurl=https://i.imgur.com/vp6UvCB.jpg

Tesla

Birom Musk fejet mint sirekes vallalkozo, de sohasem fogok Teslat venni. Kb amit csinal, az a kocsik iPhone-ja. Mindenki mas standard e-tolto csatit tesz a kocsijara, o meg proprietary-t. Nem javithatod vagy kontrollalhatod a kocsidat, mindent a Tesla ceg mond meg hogyan tehetsz vele. Szoftver felett is nekik van csak kontrolljuk.

Szoval fizessem ki a kocsi dijat, ugy hogy csak "hasznalhatom" igazabol ha megengedik, de kontrollom nincs felette. :D

Bár nekem ez így kicsit overkillnek tűnik.

Hat most pl beszelunk egy csomot reszletesen errol a bugrol (tobbek kozott mert szeretem reszletesen ismertetni a gondolataimat, hatha akadnak zsir otletek masoktol is amire nem gondoltam), de tobbi fejlesztesnel is rakatot irtam, ami elso latasra overkillnek tunhet. Amugy az ilyen jellegu munkadelegalas hasonlo esetekben normalis szokott lenni manapsag szvsz, mintsem mindent egy process-be irni es remelni hogy nem szakad bele. Belegondolva manapsag szinte ott probaljak delegalni a felmerulo melofolyamatokat, ahol csak tudjak. En probaltam vegsosoron realisan effektivre fogni a kerdest, azaz hogy csak ott delegalok ahogy kenyszerulok csomo ok miatt igy eljarni, feleslegesen nem nehezitem magamnak az eletet.

Majd elfelejtettem, de testing konnyuseg szempontjabol is eg es fold kulonbseg kis mikroszervizeket tesztelgetni es javitgani, mintsem egy hatalmas monolitikus, egybefuto kodszeletet. Es fejlesztes szempontjabol is.

Meg némileg ki is veszi a kontrolt a user kezéből

Az felett eleve nincs a felhasznalonak kontrollja (regebben se most sem) hogy sikeres e a kommentkuldes/beagyazas vagy sikertelen. Egyedul az felett van kontrolja hogy meg e nyomja a kommentkuldes gombot, vagy leirja e azt amit.

Ha (tegyuk fel) par percig dekkolni akar az elkuldott kommentje felett, es figyelni szeretne hogy sikerul e a teljes beagyazas, ugyanugy most is megteheti. Es ha ugy alakul sikertelen, editalhatja ennek fejeben nyugodtan a hozzaszolasat. Csak nem kenyszerul ujabban varni ha nem akar, de megteheti.

Ha pl. még processzálódik egy beágyazás, de a user szerkeszti a postot (törli a beágyazandót), az megszakítja a folyamatot? Részletkérdés, de ilyesmi halmazati felelősségeket vízionálok.

A "beagyazas" mint komplett folyamat 2 nagy, egymastol kialakitasban teljesen eltero reszbol all:
1) A kommentkuldesnel az RW szerver elkezd a kulso weboldallal egyezkedni a kello informaciokert APIkon keresztul, vagy sajat kotyvasztasu algoritmussal. Majd ha megkapta a kello adatokat a lepesek folyaman, akkor elmenti azokat az szepen rendszerezve adatbazisba, egy URL-bol generalt ID nev mogott.

2) Ha valamilyen a felhasznalo betolt egy topikot es/vagy kommentet, es abban a beagyazott URL-bol generalt ID megegyezik az adatbazisban eltarolttal, akkor grafikusan formazza es megjeleniti azokat, "beagyazas formaban" ugye.

A szerkesztes igy egyaltalan nem befolyasolja a beagyazas server oldali kimenetet. De abszolut befolyasolja a kimutatott anyag verziojat. Ha pl szerkesztesz es ugy dontesz megis kiveszed a beagyazott anyagot, akkor az sohasem fog latszani. Sarkitva kicsit, de ugy is felfoghatod igy az 1. pontot mint egyfajta cache-ing, a beagyazas kimutatasnak.

De ha valaki mas is be akarja agyazni es mar megvannak a hatter szamitasok, neki sokkal gyorsabban meg fog tortenni, mert nem kell a szeronak 2x ugyanazt elvegeznie.

Inb4: "de mi van akkor ha kitalalja valaki az ID-t es ugy akaratunk ellenere meglatja az elkezdett, majd meggondolt es mutatni nem szandekozott tartalmat, az RW backendrol kezzel lekerve?"
Good luck hasadra(billentyure)csapni es kitalalni egy SHA256 hashelt hosszusagu es custom Base64-ben encode-olt IDt, hogy azzal pont elcsiped az anyagot. :D Egyeduli mukodo modszer hogy birtokaban vagy mar eleve az eredeti linknek. De hogy lekerd az adatokat azzal kapcsolatban az RW backendrol meg hashelni es encode-olnod sem kell az URL-t hozza. Ugy is mukodik a backend, ha direkt linket adsz meg neki, majd o hasheli es encodolja helyetted mielott keresne az adatbazisban. Irtam is az RWMedia backend modul topikjaban reszletesen a mukodesrol. :)

(A load balance-ot általánosabban értettem a késleltetéssel kapcsolatban, amikor a szerver különböző időbeli rendelkezésreállását tekintjük különböző "resource"-nak.)

oh, okes akkor.

De most már értem, miért szükséges aszinkron, köszi a felvilágosítást!

szivesen! Mindig orommel beszelek a technikai megvalositasokrol is, egeszen reszletesen is akar. Orulok hogy erdekel valakit az RW technikai geek oldala is. :)

Valami ilyen megoldast otlottem ki, teljes atiras/atdolgozas es ReactPHP kitapasztalas helyett. Low-level modon kezelve a PHP kimutatas puffereket el tudom erni vegsosoron hogy:
- ellenorizni tudom szerver oldalrol hogy megerkezett e az elkuldott szignal, egy nagyon gyorsan kimutatott visszajelzessel.
- ezzel egy idoben el tudom a megszakitas header-eker kuldeni is, igy itt a kapcsolat meg is szakad szintugy gyorsan, es nem fogja le tobbet hosszas gondolkodassal a kliens bongeszot a tovabbi reagalastol.
- de a szerveren a beagyazas script tovabbra is fut a hatterben, es vegzi lassan a kiadott melokat.
- remelhetoleg ez a gyakorlatban great success, az aszinkronos mukodes szimulalasaban. :)

Proof of concept kodban mukodik kivaloan:

Mindjart nekiesek elesben is a RWHttp modulunkba belekodolni.

Azt hiszem levadasztam a gyokeret a szignal vesztesnek. Az RWHttp (https://rewiredhu.cf/content/kivanalom-rewired-20-rwhttp) modulunk aszinkronos HTTP request funcionalitasaban van.

Teljesen leegyszerusitve roviden ugy mukodik, hogy nyit egy friss kapcsolatot, de amint elkuldte a kello adatokat azonnal be is zarja azt es felszabaditja az eroforrasokat, nem varja meg hogy visszajelezzen a szero hogy "koszi megkaptam es megertettem".

Onmagaban nem kellene hogy problema legyen, de ugy fest lehet annyi kommunikacio van mar a lokalis halozaton is, hogy mire eljut az uzi a legkozelebbi router-ig, es jonne vissza a szerohoz, lehet utkozik valamivel mar es elveszik.

Van par megoldas ennek a kezelesere:
1) A legtisztabb ut a legnehezebb. At kell irnom ezt a megoldast egy joval stabilabban es robosztusabban felallitottra. Pl megtanulom kezelni a ReactPHP-t vagy hasonlo hosszu ideje tesztelt es bevallt aszinkronos library-ket. Azutan irok egy RWn kivuli masodik webszervert, aminek a kizarolagos dolga lesz hogy a weboldalunk mellett csucsuljon a szamitogepen es idozitse, delegalja az RW altal kiosztott beagyazas melokat a memoriaban.

2) Beagyazasnal a szerver 1 szignal/beagyaznivalo munka helyet mit tudom en 2-3at/beagyaznivalo is elkuld egymas utan roviddel. Ezzel amolyan brute force modon emelne sokkal az eselyet hogy ha el is veszik 1-2 valahol, a tobbi ugyanugy folytatja a munkat es remelhetoleg a hiba soha nem jon igy elo. A negativuma hogy minden egyes szignal ujabb kulon process-t nyit, ami igy mind extra memoriat is eszik, amibol viszont nem vesztegethetunk ha nem muszaj, mert szukos. Meg a masik nagy negativuma, hogy ronda megoldas, es csak ragtapasz igazabol a problemara, nem kezeli azt.

3) Megprobalom atirni a kerdeses kodsorokat hogy a server a kiadott utasitasokkal a sajat webcime helyett csak a localhost-ot celozza. A cel ezzel az lenne, hogy elmeletileg igy ki se kelljen mennie a signalnak a lokalis halozatra a routerig, majd vissza a szerverhez. Igy az egesz beszelgetes onmagaban a szerveren belul tortenne, es "nem lenne" mibe utkozzon es igy potencialisan vesszen a signal.

Nyilvan hogy a 3) megoldassal probalkozok szerintem, azutan ha valamiert elverzik ez a ravasz terv is, akkor megyek a joval nehezebb 1)-re. A 2) max ideiglenes mentoov megoldas lehet ha addig is ki kell tartson valami a kozeljovoben, amig meg nem oldom a szitut valamelyik masikkal.