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

On tullut tässä kyllä mieleen, että aloitinkohan koko projektin teknisesti vaikeimmasta osasta, kun päätin kirjoittaa palvelinten kanssa keskustelemiseen liittyvän koodin ensin. Varmaan pitkästyttävin se ainakin on.

RE: https://mementomori.social/@nen/115990307530141543

Muistaakseni osasin vuosia sitten aika hyvin välttää tämmöiset tilanteet ennakkoon, ja olin välillä aika ylpeäkin koodistani. Harmi etten vain enää muista, miten sen silloin tein.

Toki tämänkertainen pulma on ollut aika monimutkainen sillä tavalla, että sitä on lähtökohtaisestikin ollut mahdoton mahduttaa omaan päähän edes osissa ilman että aina jotain unohtaa huomioida. Tässä voisikin olla hyvä paikka suunnittelutyökalulle, joka helpottaisi asioiden välisten riippuvuuksien hallintaa ja hahmottamista. Jotain, johon voi kaataa aivoista suoraan kaiken tajunnanvirran mahdollisimman vapaamuotoisesti ja sitten jäsentää, piirtää karttoja ja kaavioita, sitoa jotenkin koodiin ja tarkistaa että rakenne noudattaa suunnitelmaa.

Nyt on paljon parempi. Tuo kahdesti viitattu silmukkafunktiokin on pilkottu pienempiin osiin.

Jaa-a, taidanpa kirjoittaa puolet taas uusiksi puhtaalta pöydältä...

Tuhannen rivin merkkipaalu lähestyy taas ja tällä kertaa ei tunnu siltä, että pitää kirjoittaa kaikki tai puolet uusiksi.

Hauska muuten: jos mittaa koodin määrää pakkausalgoritmilla, niin koodia lisätessä saattaa koko pienentyä, kuten äsken kävi.

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.