Non sono passati nemmeno 10 giorni da quando avevo detto “aaa è improbabile che aggiornerò ancora #MBViewer, dovrei provare a far iniziare a funzionare il progetto definitivo #alternativo migliore…” 🥴️
Però poi mi sono resa conto che: magari del #progetto alternativo non è semplice progettare tutta l’interfaccia e il suo funzionamento (cosa che va fatta, essendo una cosa da #costruire da zero), ma certamente non si posso comunque granché se prima non preparo dei #componenti logici che so già che mi dovranno servire… e allora, tanto vale iniziare a lavorare per quelli, integrandoli nella #app che (per quanto #spaghetti) è già esistente e funzionante, e acchiappare un bel 2 in 1 (espandere quel #programmino, e nel mentre accumulare codice che mi servirà per quel molto altro più tardi). 📦️
La prima cosa un po’ intricata che serve è il supporto all’ingestione di dati da #piattaforme diverse, con #schemi diversi. L’idea è di avere un solo #schema di dati che la app usa per lavorare internamente, per evitare di avere spaghetti, ma questo vuol dire che bisogna fare qualche tipo di conversione. Ci sarebbero diversi approcci: 🔪️
Il più classico sarebbe quello di scrivere (come degli schiavi indiani) delle #procedure di codice per tradurre ogni tipo di entità #API dai #formati esterni a quello interno, e viceversa… il che non solo è una pazzia, e richiede un botto di #lavoro (va scritto un numero di #funzioni complesse pari alle piattaforme da supportare, moltiplicato per 2), ma finisce per dare #rogne: appena decidiamo che lo schema di API interno va modificato o allargato, ecco che bisogna modificare in ognuna di quelle parti, ed ecco che magari escono nuovi errori e problemi. Ehhh, no, non ci sto dentro. 😩️
La mia idea, invece, è di usare un #documento di #trasformazione, almeno per quando le task sono semplicemente selezione e riassegnazione di chiavi di #dati (per operazioni più complesse, il codice è più appropriato del #markup). Era questo che avevo già provato a fare mesi fa (e funzionava eh!), ma, riguardandolo ora, mi stavo rendendo conto che lo strano #formato JSON da me inventato ha dei #limiti abbastanza forti, tra cui penso sia un casino tremendo usare 1 solo documento di #traduzione per fare sia avanti che indietro. Quindi, ho iniziato a ripensarlo da capo, ma ho pensato abbastanza in fretta che, beh… #JSON non va bene per sta roba, lo si vede anche dal come devo mettermi a scrivere chiavi tipo “__robo__“; JSON abuse, doing I am. Però l’idea credo sia bona… 😋️
E allora, fortunatamente sono tornata sana giusto in tempo, prima di #impazzire ancora una volta dopo mesi con Jason; almeno, abbastanza sana per capire che è meglio impazzire con #XML, se proprio proprio, in questo caso. E, boh, ci ho perso 1 giornata e qualcosa (soprattutto l’altra sera in cui, mezza drogata di sonno, mezza cringiata per colpa della situazione, ho iniziato ad andare un pochino mentale), ma bene o male l’ho fatto funzionare un minimo. C’è stato di tutto in mezzo ovviamente; tra cui, il #godere per aver sistemato un #bug, eccetto scoprire poco dopo che, no, nulla era sistemato… e averci dovuto perdere un’altra mezza giornata. 📆️
https://octospacc.altervista.org/wp-content/uploads/2024/01/image-9-960x451.pngIn #screenshot, i documenti di trasformazione: a sinistra, quello XML nuovissimo, credo definitivo; al centro, quello JSON vecchio: a destra, quello JSON nuovo che ho sperimentato per pochi quarti d’ora. 💎️Questa è una di quelle cose capaci di stupirmi anche se fatte da me: la sola #idea di poter raggiungere il 90% di quello scopo intricato semplicemente #componendo un documento XML in maniera adeguata, e avere vita facile per ogni #modifica, la trovo #pazza in concetto. Comunque, ho dovuto (iniziare a) scrivere una mega-funzione totalmente #originale per questa cosa perché, come già avevo constatato mesi fa, ma riconfermato appunto ieri, tutte le #librerie in giro per fare trasformazioni di dati così sono troppo generiche, a quel punto usare quelle sarebbe anche peggio che fare tutto in #codice. E credo di aver cercato fin troppo in giro. E, ahimè, prima o poi soffrirò di nuovo, perché dovrò scrivere pure la #funzione di traduzione inversa! 😵💫️
Che centra con la #applicazione mezza kangata? In pratica, avendo integrato questo #sistema già da ora, MBViewer può visualizzare (alcuni) #feed#RSS, e (con qualche problema, per ora) #profili#Mastodon, il che non è male. È male, invece, il mio aver scoperto solo ora che su Firefox avviene un problema con il parsing dei feed RSS, che dovrò sistemare… ma su #Chromium funziona tutto. Oh well. Ohhh, it’s so well. I #glitch non finiscono mai, la tortura della #programmazione è eterna!!! 😭️
Is there some markup language you really like?
Do you have a vision of what a perfect markup language should look like?
Do you write your UIs without a markup language, just with code?
Masto pals, does anyone know of a good, but inexpensive resource to learn #HTML and/or #PHP specifically for their application to #WordPress?
I'm more looking for online courses or tutorials vs books and I don't have any prior #programming or #markup languages knowledge. I do have basic WordPress knowledge.
My writing app is based on Markdown, but only has very simple formatting available.
A long requested feature is subscript and superscript, so are footnotes and endnotes, and even partial word emphasis.
Due to using regex for highlighting, these are somewhat tricky to achieve, but I'm wondering if this syntax may serve the purpose. Here in the editor, and how it renders.
These aren't features used often in fiction writing, so perhaps the syntax can be forgiven.
We have decided and finally planned to migrate our instance to glitch-soc, which will give us many more features, but more importantly, will move us from upstream mastodon, to a fork that will not be (necessarily) under control of Gargon's opinion of what mastodon should be, as we think our own view has diverged with his.
On top of that, it'll provide us with much more customisation options, and easier controls to limits (such as display name and bio, which we will likely extend soon after that)
We will attempt to migrate this on July 4th, on 9 AM UTC (2 AM PDT, 5 AM EDT).
I'm experimenting with plain-text markup (sometimes called "markdown") and converting public domain works from Project Gutenberg. Here is a proof-of-concept rendering of "Alice in Wonderland". I would love feedback!
For the record the basic conversion took only minutes, but… the verse sections needed quite a bit of tweaking. The entire thing including adding a few images took less than an hour.
This "Booklet" format contains a tiny bit of javascript to collapse and expand sections to help navigate the longer work. This is a bit like an accordion fold with a single section open at a time.
@brunty OK, I'll admit, I love #XML too: I wrote two books about it and was a member of the original #W3C XML WG and chaired the XML Core WG afterwards. 🙂
But all the same, when I was chairing XML 2007, I did invite @douglascrockford to give a closing keynote about #JSON, just to remind the aficionados that there was more to #markup than XML.
This is hilarious. A #Google engineer invented #zx to make command line scripting easier with #NodeJS, because at a certain point #shell scripts get too complicated and you need a Real #Programming Language.
This is exactly #Perl’s use case from thirty-six years ago. But the kids want #JavaScript everywhere and would rather it take more work to convert their ascended #Bash scripts to a vastly different syntax.
@ndw Reading your bio. I’m almost reluctant to point out that the same “worse is better” cycle applies to #markup languages. #JSON was a reaction to #XML, #Markdown was a reaction to #HTML, and both have since acquired layers to add back what they threw away.