I am now working on my own chess API and it’s actually pretty fun. I learned that using bitboards is apparently very efficient. So I now use 8 64bit bitboards, 2 for the color and 6 for the pieces (I thought about just using 7 because you COULD theoretically represent the colors in one bitboard, but using 2 makes it faster at the expense of an extra 64 bit, which is neglegible). Gonna continue on this in the upcoming days :3
https://apisof.net exposes platform-specific framework information for apis and types. For example, I now know that this Zune enum type is Windows only :)
Should you design APIs based on what you (the owning team) think is the best way to expose your domain, or do you make compromises based on the needs of your API's consumers?
(API here refers to any element of the public contract of your service/subsystem/app/domain/context, such as HTTP endpoints or events.)
You start from any conventions you've agreed on with other teams regarding API design.
Then you focus on what's best for your domain model.
And when you find reality has needs beyond what both convention and model dictate, you inspect and adapt. That means revisiting a convention or remodeling your domain boundary.
Updated my Gaming Library page, you can click the title on the spine of a game and it'll open a dialog with more info about it. Recently integrated the PSN API to show trophies and even an icon if relevant. APIs are cool. (manually mapping API IDs to your Notion list, not so cool, but it is necessary!)
PS: Don't try to change the completed status — rude. Also I didn't copy the idea from somebody I look up to with their NYC checklist, nope. 🙃
Modern current code should run asynchronously if possible and useful. Slowly but steadily, it is being implemented in almost all popular programming languages, including WebDev.
Is there a more efficient way to check if two accounts follow each other via Mastodon's API, other than fetching followers of both accounts and finding a match?
Why is it so fun to create APIs? Something about it is so oddly satisfying, the image down below is part of my API documentation and its just pure dopamine to look at xD I could do this kind of stuff forever… #api#rustlang#axum#programming#technology#coding#dev#development
Ieri non ho assolutamente portato a zero la batteria del tablet per tutto il tempo che ci ho messo a provare #app diverse e a vedere cose per risolvere l’ennesimo problema causato dalle nuove versioni di #Android… ok, in tutta onestà la batteria l’ho finita nel bus più tardi, però comunque, una buona parte della carica è sparita solo nel tempo perso prima. 😶🌫️️
Un altro po’ mi sembrava di star usando iOS per non riuscire a fare una cosa così banale come: aprire un file #HTML direttamente nel #browser, ed averlo funzionante, con anche il caricamento di tutte le risorse embeddate, senza ricorrere ad un webserver locale che causa solo rogne in più… come ho detto su OTIDroid, questa cosa sembra una cazzata, ma è sorprendente quanto è difficile da Android 11 in su:
Firefox Fenix non ha mai supportato i percorsi file:///, #mannaggia a te Mozilla
Firefox legacy funzionerebbe, solo che la versione più recente (v68.11.0) è comunque antica e quindi molte nuove #API web non vanno
I #navigatori Chromium, da quando sono aggiornati per targettare le nuove API Android, non riescono più a vedere qualsiasi file su /sdcard/, ma solo quelli multimediali (utilissimo eh?); e si, hackerare il manifest per portare indietro l’API target rompe la app
La più recente versione di Chromium precedente a tutte queste novità che ho trovato (~v79.0.3945.94) è comunque molto vecchia, stesso problema di Firefox
Evidentemente nessuno ha voglia di creare un browser che funziona correttamente, (nemmeno io, in quel momento volevo solo fare un po’ di programmazione HTML), maremma maiala… ma, per fortuna mi torna in mente che una #soluzione ci sarebbe: le app che usano la #WebView di sistema funzionano ancora normalmente (senza codice aggiornato per lo #storage) se hanno un target SDK vecchio ma, proprio perché il motore che usano è quello di sistema aggiornato, la compatibilità con gli standard è massima. 😤️
Sorprendentemente, di #browserini così che siano allo stesso tempo non mezzi rotti, abbiano un target vecchio, e il permesso di lettura dell’archiviazione, non ce ne sono molti. L’unico che ho trovato è “Tint Browser“, che funzionerebbe già così senza fatica, e stavo per usare quello… ma ha uno strano bug che fa sparire tutte le schede aperte sia alla chiusura della app, che la rotazione dello schermo… e non viene aggiornata da 10 anni, quindi mi sa mi sa che il #problema non sarà risolto. 🕸️
Ho però notato che virtualmente qualunque altra app WebView browser non si rompe se subisce quelle modifiche che ho detto all’AndroidManifest.xml, probabilmente perché sono così semplici che non hanno codice chissà quanto specifico a certe versioni delle API… quindi ne ho semplicemente scelto uno che mi piaceva, ho usato un editor di #APK per portare indietro il valore android:targetSdkVersion del blocco <uses-sdk> (mentre il permesso READ_EXTERNAL_STORAGE c’era già quindi non ho dovuto scriverlo io), e in mezzo minuto il problema è risolto. 🌚️
Tra gli infiniti che si trovano ho preso questo “SmartCookieWeb” comunque, ha delle funzioni avanzate carine. L’APK già modificato, in caso ne aveste bisogno, l’ho caricato qui sul mio server.
Una cosa strana però: teoricamente è stato Android 11, cioè target 30, ad introdurre lo spacc più totale dei #permessi di accesso all’archiviazione locale, quindi a regola impostare il 29 (Android 10) sarebbe sufficiente a visualizzare il permesso di gestire tutti i file nelle impostazioni al posto di quello per soltanto i media… eppure io ho dovuto scrivere 28 (Android Pie). Sarà un fatto del mio Android 12 forse, boh, anyways the fog is coming fuck you Google. 👁️
Building Objects in the API Lifecycle (dev.to)
Table of Content Table of Content Preface Introduction Why are entities bad for...