jannis, to random
@jannis@hci.social avatar

🚀 Recently, an extension of our GEAR paper was published:

"Gaze-enabled activity recognition for augmented reality feedback"
https://doi.org/10.1016/j.cag.2024.103909

In this extended version, we added feedback to the gaze-enabled so that users get helpful assistance after their current activity was recognized.

Our code and the gaze data are available here: https://github.com/Interactions-HSG/GEAR

minioctt, (edited ) to webdev Italian

Il (tra i tanti!) delle è che saranno anche facili da o spesso, ma non per questo anche semplici… (o per caso non sono neppure facili e la mia mi fa sottovalutare la cosa?) 😫

  • 🅰️ Per quelle meno complesse, il metodo migliore è senza dubbio un bel wget -kp $URL, cioè scaricare la pagina con tutte le sue risorse collegate, e convertire i link da assoluti a relativi.
  • 🅱️ Quel però non è a conoscenza di tutte le risorse caricate dinamicamente, cioè dichiarate in posti diversi dall’HTML. Per prendere anche quelle (ed è spesso necessario, tutte le app moderne caricano roba così), bisogna aprire la app nel , e guardare le richieste di che macina con il normale uso.
    • 1️⃣ A questo punto, si può usare la funzione del browser per esportare le richieste in formato HAR, e poi tool come har-extractor o Har Extractor Online per ricavare i file effettivi da quel blob.
      • Ho notato però che Firefox in alcune situazioni genera corrotti (2 giochi fatti in Phaser avevo provato a scaricare, ed una volta estratti gli script tiravano errori; ho riprovato con Chromium, ed è andato tutto liscio), quindi a prescindere io userei l’altro per questa cosa. 🥴
      • Poi, non ho ben capito se per via di come il file HAR in sé è generato, se come quegli lo interpretano, o un misto delle cose, ma le risorse cross-domain (e credo anche caricate da iframe?) tendono a non venir estratte, quindi si deve andare poi a pescarle prelevando l’URL di ognuna a manina dai DevTools già aperti… 🤧
  • 🆎 Si potrebbero usare primo e secondo metodo insieme in linea di principio (copiando i file del primo passaggio su quelli del secondo, sovrascrivendo gli esistenti), ma nella pratica è inutile… se c’erano link assoluti da convertire in relativi nell’HTML, con spaventosa probabilità questi sono presenti anche nel o chissà dove, per cui, dato che bisognerà comunque andare a mano a modificarli da qualche parte, 1 o 2 file in più non cambiano (spesso) nulla.
  • 2️⃣ Se si è usato il secondo metodo, bisogna a questo punto effettivamente verificare che i link siano tutti corretti, le effettivamente scaricate, e la app funzionante indipendentemente dal dominio originale… il modo più efficiente che ho trovato è aprire già da subito un webserver locale sui file, navigarci nel browser, e controllare sia che tutto funzioni nel pratico, sia che tutte le di rete per risorse effettive (ossia, non contano chiamate di telemetria o simili) vadano al mio , anziché al dominio originale (attivando la colonna omonima della tabella nei lo si vede a colpo d’occhio).
    • Quando ci sono richieste che falliscono o che vanno su altri server, bisogna capire da dove nel codice queste partono, e fare le opportune per usare URL relativi. Quelle che partono dall’HTML o dal CSS (turns out, non molte, altrimenti avremmo usato direttamente wget) sono appunto una scemenza da sistemare… ma quando partono da , c’è poco da fare, con l’aiuto del debugger del browser (di nuovo, meglio Chromium, perché de-mininifica il JavaScript aggiungendo whitespace in automatico) si va a capire da che punto partono, e in base alla situazione si valuta che modifiche fare al . Poi, si testa ancora, e ancora si applicano , finché tutto non funziona. ♻️
    • In genere questo non è un problema, e anche per app più ostiche (come quella che ho ricaricato sulla ieri, Little Alchemy 2) si fa tutto in un quarto d’ora ben ristretto. Tuttavia, bisogna fare attenzione a quei programmi che caricano le risorse man mano che ne hanno bisogno e non tutto subito (in genere, maggior parte dei giochi, oppure parecchie React)… lì si può potenzialmente perdere un bel po’ di tempo, perché bisogna mettersi ad usare il raggiungendo idealmente il 100% del codice; cioè, cliccare tutti i bottoni, usare qualunque azione, giocare tutti i livelli… fino ad ora non ho mai incontrato , ma se succede, l’unica è navigare tra il codice già scaricato per vedere cos’è che manca (da qualche parte ci sono scritti i nomi delle risorse ancora da scaricare, per ovvi motivi). 🗡️
  • 🔚 Aggiustamenti finali: in base alla situazione, vanno fatte altre modifiche al source per ovviare a banali ma frequenti. La maggior parte riguardano i domini, che in certi casi sono hardcodati, e quindi o ci sono iframe che comunicano con la Messaging API e gli va cambiato il dominio (come per il gioco di ieri), o c’è del DRM che ostacola il (come il giochino dell’altro ieri) ecc… con si risolve tutto.
    • E alla fine di tutto, una cosa che mi piace fare ma che non sarebbe obbligatoria, è disattivare tutte le componenti potenzialmente dannose dell’ , ossia commentare via eventuali inclusioni e chiamate a sistemi di analitiche o pubblicità. 🚯

https://octospacc.altervista.org/2024/04/03/webaps-heist/

tdp_org, to webdev
@tdp_org@mastodon.social avatar

Just spotted that the Google HAR analyser has a "download redacted version of this HAR" button. That's pretty cool, redacting by hand is massively tedious and error prone.
https://toolbox.googleapps.com/apps/har_analyzer/

#HAR #webPerf #webPerformance #webDev

  • All
  • Subscribed
  • Moderated
  • Favorites
  • JUstTest
  • InstantRegret
  • rosin
  • modclub
  • Youngstown
  • khanakhh
  • Durango
  • slotface
  • mdbf
  • cubers
  • GTA5RPClips
  • kavyap
  • DreamBathrooms
  • ngwrru68w68
  • provamag3
  • magazineikmin
  • osvaldo12
  • tester
  • tacticalgear
  • ethstaker
  • Leos
  • thenastyranch
  • everett
  • normalnudes
  • anitta
  • megavids
  • cisconetworking
  • lostlight
  • All magazines