mastodon.bida.im is part of the decentralized social network powered by Mastodon.
Un'istanza mastodon antifascista. autogestita, italofona con base a Bologna. Rispettosa di privacy e anonimato.

Server stats:

863
active users

Learn more

#applicazione

0 posts0 participants0 posts today

Robot Umanoidi Made in China: Un Mercato da 75 Miliardi di Yuan Entro il 2029

📌 Link all'articolo : redhotcyber.com/post/robot-uma

Il settore dei robot umanoidi in sta registrando una crescita significativa, con numerose aziende e istituti di ricerca che, alla fine del 2024, hanno presentato importanti progressi nella , e di questi robot, consolidando il ruolo di primo piano della nelle tecnologie avanzate. Il Beijing Humanoid Robot Innovation Center ha recentemente lanciato RoboMIND, un insieme di normativi per l’intelligenza multi-incarnazione destinato a migliorare l’addestramento dei robot umanoidi.

il blog della sicurezza informatica · Robot Umanoidi Made in China: Un Mercato da 75 Miliardi di Yuan Entro il 2029Con un mercato stimato a 75 miliardi di yuan entro il 2029, la Cina accelera nello sviluppo di robot umanoidi. Scopri le ultime novità e prospettive future.
Possibile impiegare una mezza giornata sana a implementare delle funzioni in JavaScript molto particolari riguardo i cookie, e sistemarne alcune già esistenti, solo per sistemare due cose apparentemente stupide come: far aggiornare subito un contatore in una app di esempio, e far fungere il cambio di lingua in una app vera? …Evidentemente si. 😊

È un maleficio e una benedizione avere il mio mini-framework per le webapp multi-pagina (aka, vecchio stile e non cosiddette single-page)… chiaramente, è lavoro in più concesso al letterale etere, che mi risparmierei se altre librerie mi andassero bene. Dall’altro lato, però, se ho questo robo è perché non trovai proprio nient’altro che funzionasse alla base nel modo in cui mi serviva, e quindi ceppa. A distanza di mesi di non-lavoro però devo confermare che l’idea è stata geniale (il che è molto dire, in genere il mio codice marcisce peggio), e davvero la API che ho ideato è l’ibrido migliore possibile per app che automagicamente girano sia senza script lato client che senza un server di backend. 🤑

Però, ecco, se c’è una rogna del comunicare tra client e server senza script lato client… sono i cookie (“biscuit” per i britannici). Si vede che sono del millennio precedente, con le loro stringhe marce da parsare in un certo modo. Vabbè, avevo già implementato funzioni di lettura e scrittura dei biscotti più o meno base ma, via via, sono uscite fuori difficoltà così scomode, che oggi ho dovuto implementare una tale serie di cosi di [de]serializzazione, che la mia stima per #HTTP esplode un pochino. Principalmente: come faccio a rinnovare un cookie arbitrario, ossia di cui potrei non prendere il riferimento di durata all’interno del codice (perché voglio una funzione di utilità che rinnova un qualunque cookie conoscendone solo il nome), se il client da specifica non ha modo di inviare al server le flag usate per piantare i cookie? 🤯

Ho trovato giusto qualche utente online che piangeva di questa cosa, nemmeno tantissimi, e quindi giustamente neanche nessuno che proponeva soluzioni; probabilmente, molti si arrendono all’hardcodare le flag dei cookie da qualche parte e riutilizzarle ogni volta, oppure allo scrivere codice verboso, per rinnovare a mano ogni volta. …Io non ci sto, quindi me la sono inventata io la soluzione: uso un “metacookie”, aggiornato automaticamente dal server ogni volta che tramite la API è settato un qualunque cookie, che semplicemente contiene come suo valore le flag extra per ogni cookie, e che quindi il server può ripescare da lì per rinfrescare i cookie in maniera perfetta. Ci posso conservare dentro anche informazioni non-standard, ad esempio data ed ora di scrittura di un cookie per poterlo rinnovare solo se è più vecchio di un tot… senza esagerare, però, perché (da standard?) un singolo biscottino non può essere più grosso di 4KB, quindi se questo si ingrossa succede un patatrac. 🤗

Concettualmente credo sia semplice, ma a livello pratico mi ci sono comunque volute una caterva di funzioni, perché, tracciando la logica… Quando il server vuole settare un cookie: lo manda al client senza problemi, ma intanto deve serializzarlo ottenendone le varie parti (o, viceversa se è già un oggetto e non una stringa), quindi (se necessario) serializzare anche i dati dal metacookie per aggiornare i campi lì e poi deserializzarlo per inviare anche quello di nuovo al client, nel frattempo conservando i nuovi dati sul cookie per eventuali operazioni successive nella stessa richiesta (prima non avveniva, quindi i dati non si aggiornavano senza una nuova richiesta). Quando il server riceve biscotti: ovviamente deve serializzare quelli, altrimenti non sarebbe possibile prendere e poi aggiornare tutti i datelli, e praticamente ripeti cosa è già fatto ma con meno giri. E… nonostante questo, ancora non ho la perfezione in mano, ma mi manca pochissimo. E… anche oggi, l’aggiornamento di WuppìMini esce domani. 🤭

https://octospacc.altervista.org/2024/07/14/spacoweb-piu-croccante/

Notizia divertentissima scoperta oggi… scusate per come condivido questo #articolo di #Repubblica, ma è l’unico che ho trovato sull’argomento (e, in ogni caso, devo fare della critica), e la versione web ha un paywall che non sono riuscita a bypassare in alcun modo (ci ho provato per mezz’ora 🥰️), quindi vi beccate la pagina del quotidiano (che ho però un po’ tagliuzzato per rendere più facile da leggere anche su telefono). Le lacrime si sprecano, da un lato per come è riportato il misfattone della “app pirata“, dall’altro per le ragioni per cui il criminone è stato possibile.

Facciamo che prima racconto la mia versione, e poi insulto i portavoce. Gente sconosciuta (che ha fatto bene a rimanere tale, considerando le accuse semplicemente sbagliate che ora i rosiconi stanno sparando) si è divertita a reversare un po’ la comunicazione tra la app proprietaria merdosa di turno, e le bici di questo servizio RideMovi della città di #Bologna. Con la conoscenza ottenuta, che al 95% è un file con una lista di chiavi, hanno fatto un’applicazione (open-source, di appena qualche centinaio di righe di codice) con un’icona abbastanza spassosa: come dice l’articolo, c’è una lingua tipo quella dei Rolling Stones, che lecca una bicicletta arancione come quelle del servizio, che però non è “malconcia”, è semplicemente disegnata male come tutto il resto… tra cui il loro motto scritto a mano: “abbiamo il sicuro affuturato“. Minchia se lo abbiamo, quando cose di questo tipo si lasciano programmare a babbuini ignoranti, che non si rendono conto che la sicurezza va fatta sul server, non sul client, un fatto che sapevo pure a 11 anni io (non ironicamente)! 😋

Ora, non so se si tratta di ignoranza fine a sé stessa, o di ignoranza che porta a fallire nel parlare di cose tecniche ad un pubblico normale, ma comunque l’ignoranza dell’amministratore delegato traspare… “È stata hackerata la nostra app“… no testina, hanno letto il traffico HTTP o Bluetooth e hanno preso appunti, o avranno al limite scompattato il vostro APK… “Qualcuno ha trovato un sistema per bypassare i livelli di sicurezza“, si, i livelli del tutto inesistenti… e ancora, “violando il nostro sistema operativo“, qui mi rifiuto di commentare. La cosa che non capisco qui, perché non è ben approfondita, riguarda le azioni della Polizia… che stanno ad appostarsi a fà, ad evitare che qualcuno abbandoni malamente le bici, o anche altro? Spero non a controllare come le bici sono state prese, anche perché il ritiro del mezzo non credo conti allo stesso modo in cui conta un biglietto per i mezzi pubblici. E in ogni caso, per quanto non so di tutti i reati che stanno contestando, certamente dirò che urlare alla “violazione di proprietà intellettuale” è un’abuso: per usare questa app terza non si stanno violando né brevetti, né marchi, né diritti d’autore… al massimo i programmatori potrebbero essere accusati, ma non ci giurerei (e spero di no, sarebbe una schifezza). 🥴

L’unica pagina che questo progetto “pirata” ha sembra essere questo profilo Mastodon: @RideGodi@mastodon.bida.im. …Ci saranno per caso delle ragazze magiche dietro, considerando il modo in cui alcuni loro messaggi si chiudono? Sembra una cosa detta a caso, ma hanno ragione: esiste ancora la #magia se esiste una app che, nonostante sia tirata su alla bene e meglio, è superiore a quella ufficiale per prendere a noleggio i mezzi disponibili: senza Internet, senza abbonamento telefonico, senza profili che mettono a rischio la propria privacy, e solo per effetto collaterale senza soldi… accendete il Bluetooth, premete un tasto, e tirate un bel sospiro: esiste ancora, per fortuna, la magia. Sulla pagina è stato pubblicato (spezzettato) anche un manifesto; che dire, di per sé ci può stare, probabilmente se vivessi a Bologna me la sarei inventata io questa roba, non andrò a mentire. 😳

Per preservare la magia (perché Bida è sempre sul filo di morte), ho archiviato su Archive.today il profilo, e sia lì che su Archive.org (se non si è buggato, maremma malefica) alcuni dei link da lì ulteriormente raggiungibili. Non perché servirà a qualcosa di pratico dopo che questi (…forse!) sistemeranno le falle, ma perché la traccia deve rimanere… popolo, godi! Comunque, peccato che la cosa debba finire così, perché gli intenti degli autori erano più o meno condivisibili, ma il problema è — qui devo purtroppo concordare con i piani alti — che tutta la gente anarchica a convenienza, e non anarchica per morale, ha iniziato a usare le bici fregandosene di ogni cosa, lasciandole in posti sbagliati, facendole del tutto scaricare… e questo appunto va a causare grossi problemi al prossimo: sia a chi paga, sia a chi scrocca ma si comporta bene. Non approvo minimamente che la “app pirata” venga usata così, voglio essere chiara… 😑

https://octospacc.altervista.org/2024/06/26/6898/

Colpo di #genio estremamente radicale per risolvere un annoso #problema: il creare una data #webapp, che non abbia bisogno di grande interattibilità (vedi un social network, o un CMS), senza dover mantenere 2 #codebase separate e quindi impazzire, facendola funzionare sia con un #server che totalmente senza… ossia, come unire in una sintesi circa accettabile i due maggiori paradigmi del #frontend? 🤔

  • Quello antico, delle prime #piattaforme #web, dove il server genera tutto l’HTML e il browser lo visualizza com’è, spesso con (quasi) zero #JavaScript (vedi la Spacc BBS). 📦
  • Quello moderno, dove nel #backend si espongono API (spesso JSON REST), e il fronte viene sviluppato a parte come app che gira totalmente lato #client, con il #browser che richiede pezzetti di dati e fa i suoi iperprocessamenti. 💱

Ormai quello antico non si usa quasi mai per #progetti nuovi, perché gli svantaggi sono pesanti appena si vuole andare un po’ più in là: per tappare i buchi nel progetto medio si finirebbe a dover scrivere talmente tanto #codice #ClientSide, che a questo punto era meglio fare tutto nel secondo modo, senza menzionare i modelli e le #API da esporre nel server che altrimenti non si sarebbero implementati. Però, le webapp antiche girano bene anche sul computer tascabile meno performante (average Ximi), sui browser vecchi, e spesso sono le uniche che vanno quando tutto il resto ti lascia a piedi. D’altro canto però, anche se in teoria quella #app potrebbe funzionare #offline, magari mostrando dati cachabili, se è sviluppata in modo attaccato al server ecco allora che non si può fare nulla: muore il server, muore tutto. 💣

Quindi la mia #idea paxxerella, dato che devo fare banalmente una #applicazione come frontend per un altro servizio già esistente, ma voglio i vantaggi appena millantati: sviluppare con i paradigmi #ServerSide in un framework JS adatto, che giri sia in Node che nel browser. A quanto pare, qualcuno ci ha pensato prima, e qualcosa di già fatto ho trovato (Express+FrontExpress, Koa+Koa-Client, Rill)… ma è tutta roba ormai abbandonata, che o non funziona (ho provato) o ha altre #rogne. Te pareva che trovavo mai qualcosa di buono già pronto… Però, in un quarto d’ora ho tirato su uno #script scheletrino, giusto per poter partire per questa via. ☠️

Rapido #esempio: questo #programma (giusto da #dimostrazione, non fa nulla se non mostrare questo testo e far navigare tra pagine) gira sia come server su #NodeJS, che come script in una pagina #HTML totalmente #locale, e l’esperienza non cambia. Percepisco il potenziale, continuerò così. 😤

https://octospacc.altervista.org/2024/02/07/frontendare-lato-client-come-fossimo-nel-backend/

#Android è letteralmente un #incubo appena tenti di fare qualcosa di un attimo #particolare 😭

Ricordate la mia idea di riciclare il vecchio #Huawei come #touchpad? Alla fine, #KDEConnect in questo modo funziona molto bene, ma mi secca che sia totalmente vuoto se c’è un #display #LCD da sfruttare, e vorrei approfittare per usare questo #smartphone per mostrare #animazioni carine, magari un orologio, ecc… E, per maggiore #flessibilità, vorrei semplicemente avere una pagina #web sullo #schermo. Però, ovviamente, nel frattempo l’area di #tocco del #mouse deve poter ricevere i miei input. E quindi? 😶

  • Ho provato in una decina di modi ad aggiungere un WebView al layout dell’app, con caratteristiche e mezzi diversi, ma non c’è verso di far si che questo sia visibile a tutto schermo, ma allo stesso tempo non si prenda lui tutti gli input… ho provato non so quanti consigli dai forum, tempo buttato. 🙄
  • Ho tentato facendo ereditare il componente KeyListenerView dalla classe WebView anziché View, ma questo ne rompe il funzionamento e gli #input se li prende tutti la pagina web aperta. 🥲
  • Ho cercato su Neo Store (F-Droid + repo terze) e Google Play #applicazioni che facessero da #browser web fluttuante, ma nessuna di quelle che ho provato permetteva di rendere il #popup “trasparente” ai #tocchi. 😮‍💨
  • Ho cercato su #Internet per esempi di #codice di app fluttuanti, ma tutti sono un #casino da implementare ora così in una app nuova da zero (o meglio, non ci sono tutorial buonissimi), e ho buttato tempo e speranze appresso a un sacco di app esempio già pronte — o applicazioni #OpenSource con altri scopi che potessi #riadattare — che non ne vogliono sapere di compilarsi. 😤

Ovviamente, se gli strumenti funzionassero davvero, e fosse solo la #piattaforma in sé ad essere antipatica, non avrei perso tutto questo tempo. Invece no, appresso ad #AndroidStudio, Gradle, Java, le dipendenze di #build troppo vecchie perché la app è abbandonata, e se provi a sistemare fai solo danni, e quando la #app finalmente si compila devi aspettare un minuto buono ogni volta che fai un cambiamento e vuoi inviarlo al #dispositivo o emulatore… è una #schifezza. 😩

…Tuttavia, la #pazienza è la #virtù di chi sa bramare il #superfluo in modo realistico, e dunque, alla fine, ho trovato una #demo che riuscissi a #compilare (https://github.com/mjlong123123/TestFloaWindow), infilarci dentro una #WebView, e vedere il tutto #magicamente funzionare come volevo. Che assoluta #goduria, guardate il #video sotto. Ora farò giusto qualche #aggiustamento minimo necessario al mio #UseCase, e poi avrò finito. Non farò una vera e propria #applicazione, non ho voglia, ma comunque caricherò i miei #sorgenti modificati (e l’APK pronto che legge un file #HTML da archiviazione locale) qui: https://gitlab.com/octtspacc/OcttBitsOfFun/-/tree/main/AndroidFloatingWebView (i #file appariranno quando avrò fatto). 💣

Il #programma ora visualizza la pagina di errore di Android, perché il file che dovrà caricare non esiste ancora, e le dimensioni della #finestra dovranno essere sistemate. Quello che è importante è che in sé #funziona. 😁

https://octospacc.altervista.org/2024/01/17/overlay-webview-su-android-a-scopi-ricreativi/

Da quando abbiamo dovuto spostare la #comunità #Spacc sulla #messaggistica #Matrix necessariamente dopo il ban di #Durov, gli sticker #cringe da usare in #chat sono mancati troppo. Per questo una #settimana fa ho iniziato a #sviluppare #MatrixStickerHelper, una #webapp (tutta #ClientSide) che permette di gestire facilmente e in maniera più automatizzata possibile la propria collezione di pacchetti, per i client della #piattaforma che li supportano tramite le #integrazioni. 🚀

Nei giorni passati ora ci ho lavorato parecchio, e ho avuto sia modo di smussare di più gli spigoli della #UX (che però deve essere ancora parecchio levigata, ahimè), sia, cosa essenziale, aggiungere #features importanti. Ecco quindi che, qualche centinaio di righe di #codice più tardi, stasera la #applicazione supporta l’importazione di pacchetti #sticker da #Telegram, sia quelli statici che quelli #animati (non ancora quelli #video). Eccovi una #demo e, come sempre, aiuti e pareri sullo #sviluppo sono graditi. 🕷️ (Nella #registrazione, la parte dove vengono aggiunti sticker da #URL di Telegram è velocizzata 8x, purtroppo codificare quei #media in buona #qualità è costoso).

L’ultima versione, appena #aggiornata, è sempre disponibile a https://hub.octt.eu.org/MatrixStickerHelper/… provatela! 🙃

https://octospacc.altervista.org/2024/01/08/gli-sticker-da-telegram-a-matrix/

Dopo qualche giornata di lavoro, finalmente rendo disponibile la mia #webapp per gestire gli #sticker su #Matrix, #MatrixStickerHelper. È purtroppo un po’ complessa e quindi fino ad ora ho fatto giusto il minimo sindacale che mi permette di rilasciarla, e spero di continuare man mano ad aggiungere le funzioni importanti. 🙏

Per inviare gli sticker in #chat, ho sempre usato il Maunium sticker picker, il cui problema però è che bisogna usare uno strumento CLI scomodissimo per aggiornare i pacchetti, da caricare poi su qualche server #web statico. Veramente una #rottura, quindi ho deciso di creare una #app in cui si fa login semplicemente, si vedono i pacchetti che già si hanno, a cui si possono aggiungere nuovi sticker (soon), o aggiungerne di nuovi, spero prima o poi anche direttamente da LINE o Telegram. 🥳

Quando le parole non bastano, ci sono gli sticker, tutti che variano tra il #cute e il #cringe. #Applicazione messa su https://hub.octt.eu.org/MatrixStickerHelper/, se la testaste un po’ mi fareste un favore. 💞

Per ora, come ho detto, è proprio agli albori, e nemmeno l’importazione da file locale funziona… ma quella da URL JSON si, quindi perlomeno si possono già importare pacchetti creati da altre persone con i mezzi vecchi. Per provare subito, ecco una pagina di link a pacchetti pronti da copincollare nella app: https://octospacc.altervista.org/paste/887/?ppt=4434dcaa8646fbf1400fa65308d87f4d01880a113836a338c9227b70a60fb337. 🖇️

https://octospacc.altervista.org/2024/01/03/matrix-sticker-helper/

Pubblico anche qui perché, perché no… Scocciandomi del fatto che non ci sia un #client #Matrix per #mobile che sia ben curato a tutto tondo, sia stabile che performante che ricco di funzioni, ed essendo fissati quelli di #Element con il non ottimizzare la versione #web #flagship del loro client (che è progettato solo per #desktop)… ho forkato appunto #ElementWeb, e ora vedrò cosa posso fare per mantenerlo, ma portandolo in una direzione più consona ai dispositivi mobili. 📱

Qui 2 #screenshot dimostrative, per mostrare come appare la versione originale di questa #applicazione su un viewport (su browser desktop) molto stretto (a sinistra in entrambe), a confronto con il mio #fork che gira sul mio #telefono in verticale (sulla destra). Per creare veramente un’esperienza ideale servirà temo abbastanza #lavoro, ma in 2 #giorni scarsi ho già quantomeno reso la #app agibile su #smartphone, finalmente! ⚒️

Se questa #roba vi serviva, o vi intriga, vi chiedo di provarla, sollevare problemi e richieste, e possibilmente #contribuire. È tutto su #Git, incluso il #link alla #webapp, e a breve i file #APK per #Android. Ecco a voi #Spaccamient: https://github.com/Spacc-Inc/Spaccamient. 🙏

https://octospacc.altervista.org/2023/12/28/825/

#FLOSS#FOSS#libre