Where communities thrive


  • Join over 1.5M+ people
  • Join over 100K+ communities
  • Free without limits
  • Create your own community
People
Activity
Lars J. Aas
@larsjaas
Tror du kan sette opp et Staut-bilde for Kristiansund-kampen med 200 tilskuere, ingen sesongkort ;)
Rune Jacobsen
@havremunken
Hehe ;)
Lars J. Aas
@larsjaas
Nye Safari skal visst støtte samme extensions-API som Chrome og Firefox nå (eller den som kommer da). Blir bra, om vi gidder ta opp RUSK-tråden igjen en gang...
Rune Jacobsen
@havremunken
(Noe sent tilbake i omløp her) Ja, det beveger seg visst mer og mer mot at Chrome-varianten blir en standard. Jeg har stadig lyst til å ta opp tråden, men sliter med mange baller i lufta... :|
Rune Jacobsen
@havremunken
Humm, at libido skiftet navn til Flabbergast fikk ikke min RUSK med seg her.
Altså, den modulen som viser "aka <gammelt nick>".
Lars J. Aas
@larsjaas
Ja, går tom for storage og får ikke oppdatert/registrert brukernavn har jeg sett.
Rune Jacobsen
@havremunken
Ah, right
Lars J. Aas
@larsjaas
Hmm, oppdaget r/accidentalpenis har blitt bannet fra reddit, nå som jeg akkurat hadde et bilde som ville regnet karma over meg...
Rune Jacobsen
@havremunken
Hahaha
Det må vel regnes som first world problem. :D
Lars J. Aas
@larsjaas
Rune Jacobsen
@havremunken
Hahaha
Rune Jacobsen
@havremunken
😁
Rune Jacobsen
@havremunken
Har tatt en titt på RUSK igjen for å oppdatere litt. Ser nyere Typescript er sintere på at 'items' på RUSKPage er en enkel property accessor noen steder og en getter andre steder. Endrer dette til å kreve en getter for å gjøre intensjonen klar - at dette ikke er noe man skal tukle med og sette utenfra.
Rune Jacobsen
@havremunken
Har begynt å bruke yarn i andre sammenhenger. Noen tanker om å bytte fra npm? Den største konsekvensen ville vel være å sjekke inn yarn.lock sammen med endringer i package.json.
Lars J. Aas
@larsjaas
Har ikke prøvd yarn før. Blir det fortsatt "npm install" for å dra ned dependencies? I såfall, kjør på :)
Hater den package-lock.json filen i alle fall, men man kan vel gå over til npm-shrinkwrap også som alternativ.
Lars J. Aas
@larsjaas
Bare å bytt. Har ikke jobbet i rusk-repoet på lang tid, så det får være opp til de som aktivt gjør noe å holde infrastrukturen som de vil...
Rune Jacobsen
@havremunken
Jeg tenker jeg skal komme med noen bedre argumenter først. ;) "npm install" byttes med "yarn". Raskere, bedre deduplisering, men vi har jo egentlig ikke SÅ mange dependencies at det gjør noe. Tenkte kanskje det var en god ting før jeg gikk til det skritt å prøve meg på en webpack-oppgradering eller noe sånt.
Ja, ingen fan av sånne lock-filer jeg heller, men fordelen med dem er jo at man da sørger for å være på eksakt samme versjon av ting.
Rune Jacobsen
@havremunken
Ok, nå kom jeg på det beste argumentet mitt. 'yarn upgrade-interactive' er ganske behagelig å bruke for management av dependencies. Det finnes ting for å gjøre det samme med npm, men jeg liker yarn sin bedre. Så skulle du dra ned en oppdatering i halvnær fremtid dukker det sikkert opp en ny forhatt lock-fil. ;)
Rune Jacobsen
@havremunken
Ser også at det sannsynligvis vil være en tanke å flytte fra Travis til Github Actions. Muligens vi kan få til auto-publisering litt smoothere på den måten også.
Rune Jacobsen
@havremunken
Har oppgradert til webpack 5 lokalt. Etter noen tilpasninger får jeg den til å både bygge og watche RUSK, men da klarer utvidelsen ikke lenger å finne sin egen config. Funky. Skal se om jeg finner ut av det i ledige stunder.
Rune Jacobsen
@havremunken
Ser ut til å ha med generering av source map å gjøre. Å bygge går fint, men sourcemap-generering ser ut til å mislike sterkt et eller annet i prosjektet vårt. Har forsøkt både med devtool og ny plugin, foreløpig uten mye hell. Litt forskjellige feil med forskjellige varianter også. Frustrerende.
Rune Jacobsen
@havremunken
Løst - av en eller annen grunn hadde det med webpack-chrome-extension-reloader å gjøre. Så lenge den var aktiv, kom det noen deprecations, og bakgrunnsscriptet sleit med å laste config. Disablet den, da gikk det bedre.
Skal gjøre et forsøk med https://github.com/rubenspgcavalcante/webpack-extension-reloader og se om den funker bedre. Den er ihvertfall noe mer oppdatert, kanskje den takler webpack5 bedre også. Also browser agnostic, hvis kremt noen skulle finne på å gjøre en innsats for Firefox-kompabilitet.
Rune Jacobsen
@havremunken

Det er vel omtrent to år siden noen gjorde noe seriøst med RUSK, så var litt rusten på dette, men moro å komme igang igjen. Har laget en ny modul, AdBop, som scroller forbi reklamen på toppen så toppen av forumet er i toppen av browseren. Greit for oss som ikke vil adblocke vekk 2mas sine inntekter. ;)

Ikke helt enig med meg selv om dette er korrekt oppførsel ennå, men har god tid før jeg tar sjansen på å publisere ny RUSK-versjon uansett, så den har tid til å modne litt.

Lars J. Aas
@larsjaas
Jeg vet ikke noe om hva som genererer penger for 2mas, om visning er nok eller om man faktisk må generere klikk.
RUSK kunne jo egentlig bakgrunnsloadet reklamen som vises for å generere masse ekstra penger for 2mas, mot en liten kommisjon, naturlig vis ;)
Rune Jacobsen
@havremunken
Nei, ikke jeg heller. Men håper det er nok at den loades, at det ikke er så farlig at jeg autoscroller forbi den. :D
Hehe, jepp, det hadde vært fint. Laget noen iframes og fylt dem med reklame. Det eneste som fikk lide var nettforbindelsen til brukerne. ;)
Lars J. Aas
@larsjaas
Alle med RUSK sitter med desktoper eller laptoper og må vel forventes å ha bredbånd i alle fall. Er selvsagt imot å ta opp båndbredde på metered mobilt bredbånd dog.
Vi kunne identifisere de ørevoks-ad'ene og erstatte de med reklame for playmobil eller lego eller blomsterduft eller star wars eller noe - det hadde vært god nok grunn til å ta ibruk RUSK for enkelte tror jeg :)
kunne vært en separat global greasemonkey-snutt forøvrig...
Rune Jacobsen
@havremunken
Hahaha, det hadde vært noe ja. :D
De ser ut til å settes inn med dynamisk loadet javascript de "nye" reklamene btw, usikker på hvor mye fleksibilitet det er til å tukle med dem.
Rune Jacobsen
@havremunken

https://chrome.google.com/webstore/detail/extensions-reloader/fimgfedafeadlieiabdeeaodndnlbhid

Ikke like bra som auto-refresh av extension på hver rebuild (som trigges på hver save av en fil i koden), men den greia virket jo bare 30% av gangene uansett. Skal gi den en sjanse.

Rune Jacobsen
@havremunken

Første naive implementasjon av key/value store er sjekket inn på master. Den bruker et pyttlite bibliotek - idb-keyval - som pakker inn IndexedDB og gjør APIet litt mindre hårete. Passer perfekt for oss som kun trenger et relativt dumt key/value store.

Selve implementasjonen er i Utility/KeyValueStore.ts - denne brukes av background.ts som ligger og sniffer på meldinger som vanlig.

For brukseksempel, sjekk modulen EM_Usertips.ts sin preprocess-funksjon. Den bruker to hjelpere fra KeyValue, GetValueog SetValue. I dette eksemplet brukes det med async/await, men i javascript er jo det bare sukker på toppen av Promises, så de er thenable og kan like godt brukes på den måten.

SetValue returnerer forøvrig en bool som indikerer om det gikk bra eller ikke. Litt salig blanding av promises og async på grunn av litt issues underveis - jeg pynter kanskje litt på det før noen ev. ny release, så får vi jo se hvordan ev. bruk blir også.

Og ja, jeg skal notere et eller annet sted at vi fjerner EM_Usertips.preprocess() før noen ny release. Uten at det er så veldig farlig det den gjør. :)
Rune Jacobsen
@havremunken
Har ikke ment noe i kode om det, men vi bør kanskje finne på en standard for hva key'ene skal være så det ikke blir bare rot. Skal vi si det så enkelt som at alle keys vi lagrer til key/value store har prefix f.eks. RUSK-{{Modulnavn}}-og så kommer nøkkelnavnet etter det? Så har man et ganske begrenset scope man trenger å bekymre seg for kollisjoner.
Rune Jacobsen
@havremunken
Ser det var et par unødvendig knotete ting i key/value-koden fra mine første eksperimenter. Gjør det litt mer "bulletproof" og korrekt med en innsjekk nå straks. Gjør ingen endringer i APIet, bare håndterer potensielle feilsituasjoner og behandler string som string istedenfor object og med unødvendig .toString(). :)
Og så ble en metode skrevet om fra async/await til promise - skal funke på samme måte men litt mer konsistent.
Rune Jacobsen
@havremunken

Så har jeg kommet dit at jeg ikke ser noe annet valg enn å lage "states" i PageContext. En state er bare en string. Den er enten satt eller ikke satt. Eksempel på bruk av states for å slippe enorm kompleksitet og for mye viten om andre moduler:

Hotkey-modulen må vite om brukeren er i et tekstfelt - det kan være en søkeboks eller innleggsfelt eller hva som helst - og ikke sniffe etter hotkeys når det er tilfelle. Så når et tekstfelt får fokus, kan vi sette en state 'userIsInTextField'. Dersom hotkey-modulen får en kandidat, sjekker den først om brukeren er i tekstfelt-state. Er den det, no-op.

(Ja, jeg vet den modulen ikke er aktiv på de verste sidene med tekstfelter, men quickReply og kun illustrerende eksempel osv)

State er kun "live" på siden man er på, de overlever ikke page reloads og har ingen levetid fra en side til en annen. Det er kun en måte RUSK kan rapportere om tilstand som potensielt andre deler av RUSK kan holde seg orientert om, da ved å sjekke PageContext.

Det er i utgangspunktet tre funksjoner tilgjengelig på PageContext:

SetState(state: string) - setter en state hvis den ikke allerede er satt.

ClearState(state: string) - tar bort en state dersom den er satt.

IsInState(state: string): boolean- sjekker om en state er satt eller ikke.

Rune Jacobsen
@havremunken
Det er jo ganske simpel kode men slang på noen unit tests så systemet kan si ifra når dette fuckes opp i fremtiden.
(Og ja, dette er for en ny modul jeg holder på med. Ikke kjempespennende, men noe jeg har tenkt på siden vi startet med RUSK.)
Rune Jacobsen
@havremunken

Tanke - hvis den nye key/value store funker som vi håper (og ikke funnet noen grunn til at den ikke skulle det ennå), så vil da "alle brukere jeg noensinne har sett" mappet opp mot bruker-id bo der. Vil det gi mening om UserTracker-modulen likevel har en bit i sync storage som bare er oversikt over de som den har fanget opp som har byttet navn? Id, nåværende nick, array med tidligere nicks. Hvis vi legger til noe datoting der så kan vi til og med velge å fjerne de eldste dataene når det nærmer seg en viss størrelse eller det har gått en viss tid.

Klart, med sidecar kunne vi også hatt en server-side tracking på dette, som på sett og vis kanskje gir mer mening.

Rune Jacobsen
@havremunken
@larsjaas Jeg vet ikke om det var deg-som-Putte som så det med Reitan-dobbel i poll i går, men Bye oppdaget en annen ting i dag - han la inn polls på to resultattips-tråder, med Seier, Uavgjort, Tap som opsjoner - kun de to første kom med. Som moderator kan jeg editere posten hans - hvis jeg legger til siste opsjon igjen, forsvinner den i "bit bucket". Hvis jeg derimot disabler RUSK og legger den til, dukker den opp. Så vi har kanskje noen issues der?
Lars J. Aas
@larsjaas
Det var meg ja, om det var noen tvil. Postet i tråden fra feil browser, så det ble postet som Putte - det var ikke meningen, men gadd ikke stresse med å prøve å rette det opp.