En näköjään pääse somesovellusprojektin koodaamisessa eteenpäin edes aloittamalla ihan sen perusjutuista.

Tunnistin, että nämä actorit on se mitä olen koko ajan ollut tekemässä, ja otin mallia, että miten ne kannattaa toteuttaa: https://ryhl.io/blog/actors-with-tokio/

Aijettä, nyt on kiva. Pelottava tuhat riviä meni vihdoin eilen rikki ja tuntuu että koodi paranee joka raapaisulla. Harmi etten oikein tiedä, miten tätä voisi testata jo tässä vaiheessa mielekkäästi.

Taas sain hyviä oivalluksia sängyssä heräillessä. Koodi selkeytyi ja lyheni. Vastaavaa tuskin olisi tapahtunut, jos olisin sivuuttanut aiemman koodin kanssa tuskailun ja ulkoistanut ongelmanratkaisun tylsimmät vaiheet vaikkapa jollekin tehokkaalle orpojenmurskaajatekstitursottimelle.

Abstrakti ajattelu on liian ilmaisuvoimaista, jotta pelkästään se riittäisi toimivaan suunnitelmaan. Siinä on liikaa vapauksia. Se auttaa suunnistamaan, mutta ei kerro millaista maastossa on edetä ja mitä käytännön komplikaatioita ja rajoitteita mihinkin paikkaan liittyy. Tarvii työntää kädet saveen, kokea ja kokeilla.

Tämän nyt tiesin valmiiksi, mutta tulipa taas mieleen tästä mun ähinästä, ja miten projekti on ollut melko sekavaa kohellusta, joka on vähitellen selkiytynyt. *LOKSAHTELUN ääniä*

Abstrakti ajattelu on liian ilmaisuvoimaista, jotta pelkästään se riittäisi toimivaan suunnitelmaan. Siinä on liikaa vapauksia. Se auttaa suunnistamaan, mutta ei kerro millaista maastossa on edetä ja mitä käytännön komplikaatioita ja rajoitteita mihinkin paikkaan liittyy. Tarvii työntää kädet saveen, kokea ja kokeilla.

Tämän nyt tiesin valmiiksi, mutta tulipa taas mieleen tästä mun ähinästä, ja miten projekti on ollut melko sekavaa kohellusta, joka on vähitellen selkiytynyt. *LOKSAHTELUN ääniä*

@nen kiinnostava ketju! Substanssista en ymmärrä riittävästi pysyäkseni perillä sanoistasi, mutta on ilo lukea, miten kuvaat prosessiasi, varsinkin tämä viimeisin.

Oon vain harrastelija, mutta ajattelen että koodaaminen on ensisijaisesti monimutkaisten asioiden palastelua niin pieniksi ja selkeiksi erillisiksi osiksi, että ihmisen rajallinen käsityskyky voi ymmärtää jokaisen niistä yksitellen. Samoin osien välisten yhteyksien pitäisi olla riittävän yksinkertaisia, jotta niitäkin voi käsittää järjellä.

Rupesin aivoja lepuuttaakseni naputtelemaan koodiksi niitä Mastodon API:n tietotyyppejä(?), joita tarvitaan tööttäysten tulkitsemiseen. Tähän mennessä oon joutunut kirjoittamaan niille jo 138 eri nimeä ja kenttää, eikä vieläkään ole valmista. Aika paljon niin yksinkertaiselta tuntuvaan juttuun.

Ja tosi puuduttavaa hommaa. Vähän lannistavaakin, kun koko ajan jostain putkahtaa esiin läjäpäin lisää kirjoitettavaa, vaikka vähän väliä tuntuu, että nyt urakka on loppusuoralla.

Valmis! Ja toimi näemmä heti ekalla yrityksellä, kun syötin sille esimerkki-Account- ja -Status-JSONit*. HAHAHA!

Siis wtf.

MUAHAHAHAHAA

HAH HAH HAH

(*vaan mitenhän ihmeessä tämä lause pitäis kirjoittaa?)

Kai tuolla on pakko olla ainakin joku virhe, joka ei vain jostain syystä aiheuta kaatumista nyt juuri tuolla esimerkillä.

Siis 1293 riviä koodia, joka oli vielä tosi tylsää kirjoittaa. Kyllä siellä jotain pitäisi olla pielessä, edes jotain typoja, varsinkin kun en koko ajan jaksanut olla skarppina. Mutta hauska yllätys kuitenkin, ettei ohjelma sentään kaadu testiin, enkä silmämääräisesti löydä mitään vikaa mistään.

Koodi toimii ilman virheilmoituksia ja tuntemattomia kenttiä myös kaikilla niillä vajaalla 900 tuhannella tuuttauksella, joita mulla on syksystä alkaen tullut säilöttynä tällaisia testejä varten. Ihan kiva! Siinä on kuitenkin jo joitain Mastodonin päivityksiäkin ollut välissä.

Vähän syvemmällä luotauksella löytyi yksi bugi ja muutama dokumentoimaton kenttä. Nyt mua ei voi syyttää noituudesta.

Koodaaminen on nyt silleen eskaloitunut, että harkitsen tosissani Rustin derive-makrojen opettelua. Aloin nimittäin kirjoittaa *kaikille* Mastodon API-structeille jo toista funktiota, joka käy läpi niiden kaikki kentät ja tekee jokaiselle jonkun yksinkertaisen operaation (rekursiivinen tarkistus ei-tuettujen kenttien varalta + debug-HTML datan tarkasteluun). En harkitsisi makroihin turvautumista pelkästä mukavuudesta, vaan siksi koska käsin tehdessä ja tarkistaessa saattaa sattua näkymättömiä huolimattomuusvirheitä ja jotkut kentät unohtua huomioida.

https://github.com/dtolnay/proc-macro-workshop

Makrot ei olleetkaan kauhean vaikeita tajuta. Niiden debuggaus vaikuttaa haastavalta, mutta onneksi sille ei ole ollut vielä kovin paljon tarvetta. Enumeille en jostain syystä saanut derive makroa toimimaan oikein. Tai siis yksinkertaisessa testissä ne kyllä toimi, mutta ei tositoimissa.

Jaa taisinkin sitten löytää ja korjata ko. virheen about heti tuon kirjoittamisen jälkeen.

Tältä näytti Mastodon-sovelluksen silmin mun tehostama oma tööttäys, jossa kvööttään itseäni. Aika runsaasti asiaa sinänsä tosi pienessä jutussa.

Alkuperäinen on tässä: https://mementomori.social/@nen/115196352692497558

Muutin tänään myös aiemmat käsin tehdyt metodit derive-makroksi. Koodin koko pieneni 11%, mutta bzip2-pakattu koko vain 3.6%.

Nyt on myös kaikki debug-HTML-hommelit implementoitu. Esim. instanssilta tulevassa JSON-datassa olevat tunnistamattomat asiat saa halutessaan hehkumaan punaisella: