En näköjään pääse somesovellusprojektin koodaamisessa eteenpäin edes aloittamalla ihan sen perusjutuista.
-
En näköjään pääse somesovellusprojektin koodaamisessa eteenpäin edes aloittamalla ihan sen perusjutuista. Taas joutui palaamaan suunnittelupöydän ääreen.
Miten ihmeessä mun kannattaisi hoitaa Mastodon API -kyselyt, jotta niihin liittyvä logiikka pysyy yksittäisessä pienessä moduulissa? Kyselyt pitää mun mielestä laittaa jonkunlaiseen prioriteettijonoon, josta ne poimitaan lähetettäväksi netin yli. Mastodon-palvelinten ilmoittamia rate limitejä pitää seurata ja kunnioittaa. Lisäksi pitää tunnistautua palvelimille ja käyttäjällä voi olla monta eri Mastodon-tunnusta samalla tai eri palvelimilla.
Tätä logiikan rajaamista hankaloittaa erityisesti se, että kyselyjen vastaukset tulee pätkittynä lyhyihin sivuihin, ja seuraavan sivun saamiseksi pitää lähettää uusi kysely palvelimelle. Kuitenkin uudella kyselyllä pitäisi olla pienempi prioriteetti, koska tavoitteena on noutaa sisältö jonkinlaisessa “breadth first” -järjestyksessä. Prioriteeteilla pitäisi voida olla hienoisia eroja, koska haluaisin voida noutaa läheisimmiltä kontakteilta tuuttauksia nopeammin kuin tuuttaajilta, joiden kanssa ei ole juuri tekemisissä. Ainakin valmius tähän saisi olla olemassa ilman, että puoli sovellusta pitää kirjoittaa uusiksi.
-
Tätä logiikan rajaamista hankaloittaa erityisesti se, että kyselyjen vastaukset tulee pätkittynä lyhyihin sivuihin, ja seuraavan sivun saamiseksi pitää lähettää uusi kysely palvelimelle. Kuitenkin uudella kyselyllä pitäisi olla pienempi prioriteetti, koska tavoitteena on noutaa sisältö jonkinlaisessa “breadth first” -järjestyksessä. Prioriteeteilla pitäisi voida olla hienoisia eroja, koska haluaisin voida noutaa läheisimmiltä kontakteilta tuuttauksia nopeammin kuin tuuttaajilta, joiden kanssa ei ole juuri tekemisissä. Ainakin valmius tähän saisi olla olemassa ilman, että puoli sovellusta pitää kirjoittaa uusiksi.
Tällä hetkellä ajatus on, että sovelluksen (tai sen taustapalvelun) käynnistyessä ladataan ensin kullakin tunnuksella koko saatavilla oleva rajallinen kotiaikajana ja sen jälkeen paikataan puuttuvat tuuttaukset ja tehostukset selaamalla jokainen syöte (seurattujen aikajanat, seuratut aihetunnisteet, jne) erikseen niin pitkältä ajalta kuin käyttäjä on määritellyt. Noudot voivat olla kesken, jos siinä menee hyvin pitkään ja käyttäjä haluaa luoda syötteestä koostesivun pian käynnistämisen jälkeen. Myöhemmin palvelimilta noudetaan säännöllisesti erilaisia päivityksiä ja epäsäännöllisesti sisältöä, joka riippuu käyttäjän toiminnasta ja asetetuista sisällönpoimintasäännöistä.
-
Tällä hetkellä ajatus on, että sovelluksen (tai sen taustapalvelun) käynnistyessä ladataan ensin kullakin tunnuksella koko saatavilla oleva rajallinen kotiaikajana ja sen jälkeen paikataan puuttuvat tuuttaukset ja tehostukset selaamalla jokainen syöte (seurattujen aikajanat, seuratut aihetunnisteet, jne) erikseen niin pitkältä ajalta kuin käyttäjä on määritellyt. Noudot voivat olla kesken, jos siinä menee hyvin pitkään ja käyttäjä haluaa luoda syötteestä koostesivun pian käynnistämisen jälkeen. Myöhemmin palvelimilta noudetaan säännöllisesti erilaisia päivityksiä ja epäsäännöllisesti sisältöä, joka riippuu käyttäjän toiminnasta ja asetetuista sisällönpoimintasäännöistä.
Ehkäpä prioriteetteihin liittyvä koodi on laitettava kokonaan sinne jonokäsittelijän sisälle, jotta myös sivutettu nouto pysyy siellä. Jonokäsittelijälle muualta koodista tulevien kyselypyyntöjen kaveriksi vain joku enum ilmaisemaan käskyn kategoriaa, jonka perusteella kyselyjen järjestys päätetään.
Vähän aiemmin tuli mieleen vaihtoehto, että kyselyn alullepanija liittäisi pyyntöön prioriteetin lisäksi prioriteettideltan, joka vähennettäisiin aina kyselyn prioriteetista siirryttäessä seuraavalle sivulle. Mutta tässäkin jonokäsittelijän logiikka leviää minusta jonokäsittelijän ulkopuolelle. Jos prioriteetteja pitäisi jotenkin hienosäätää, pitäisi se tehdä ympäri koodia kaikkialla siellä, missä jonokäsittelijälle lähetetään pyyntöjä. Kuulostaa minusta vähän bugihautomolta.
-
Ehkäpä prioriteetteihin liittyvä koodi on laitettava kokonaan sinne jonokäsittelijän sisälle, jotta myös sivutettu nouto pysyy siellä. Jonokäsittelijälle muualta koodista tulevien kyselypyyntöjen kaveriksi vain joku enum ilmaisemaan käskyn kategoriaa, jonka perusteella kyselyjen järjestys päätetään.
Vähän aiemmin tuli mieleen vaihtoehto, että kyselyn alullepanija liittäisi pyyntöön prioriteetin lisäksi prioriteettideltan, joka vähennettäisiin aina kyselyn prioriteetista siirryttäessä seuraavalle sivulle. Mutta tässäkin jonokäsittelijän logiikka leviää minusta jonokäsittelijän ulkopuolelle. Jos prioriteetteja pitäisi jotenkin hienosäätää, pitäisi se tehdä ympäri koodia kaikkialla siellä, missä jonokäsittelijälle lähetetään pyyntöjä. Kuulostaa minusta vähän bugihautomolta.
Meinaan kategorioita tyyliin juttukaverit, molemminpuoliset seuraajat ja vain seuratut. Kategoria, jonka kutsuva koodi hyvin tietää. Sitten voi prioriteettikoodissa keskitetysti päättää, mitä tiedolla tehdään, miten se vaikuttaa pyyntöjen keskinäiseen järjestykseen.
-
Meinaan kategorioita tyyliin juttukaverit, molemminpuoliset seuraajat ja vain seuratut. Kategoria, jonka kutsuva koodi hyvin tietää. Sitten voi prioriteettikoodissa keskitetysti päättää, mitä tiedolla tehdään, miten se vaikuttaa pyyntöjen keskinäiseen järjestykseen.
Noniin, tämän ketjun kirjoittaminen taisikin selkeyttää asiaa mulle jo aika paljon.
-
Noniin, tämän ketjun kirjoittaminen taisikin selkeyttää asiaa mulle jo aika paljon.
@nen Kirjoittaminen on ajattelua.
Kollegan kanssa on aina välillä pohdittu sitä että bugikorjaus tms joka äkkiseltään tuntui ihan ok:lta alkaa tuntua päättömältä ja väärältä kun sitä selittää commit-viestissä. Tai dokumentaatiossa. Että pitäis ensin kirjottaa dokumentaatio ja commit-viesti, ja sitten toteuttaa
Ja tämä vaihe skipataan kokonaan AI:n kanssa. Ei se ole ihme että alkaa putkahdella tutkimuksia AI:n käytön haittavaikutuksista ajattelulle 🤪
(sori tämä meni AI-räntiksi jo sitten)
-
@nen Kirjoittaminen on ajattelua.
Kollegan kanssa on aina välillä pohdittu sitä että bugikorjaus tms joka äkkiseltään tuntui ihan ok:lta alkaa tuntua päättömältä ja väärältä kun sitä selittää commit-viestissä. Tai dokumentaatiossa. Että pitäis ensin kirjottaa dokumentaatio ja commit-viesti, ja sitten toteuttaa
Ja tämä vaihe skipataan kokonaan AI:n kanssa. Ei se ole ihme että alkaa putkahdella tutkimuksia AI:n käytön haittavaikutuksista ajattelulle 🤪
(sori tämä meni AI-räntiksi jo sitten)
@Turre Joo sitähän se. Musta tuntuu että tällä tavalla yleisölle kirjoittaessa/puhuessa ajattelee myös huolellisemmin tai ainakin se jotenkin aktivoi eri tavalla kuin itsekseen mietiskely ja raapustelu. Harmi etten osaa puhua kumiankalle, kun tiedän, ettei se kuuntele kumminkaan, eikä edes yritä ymmärtää (minua ei noin vain huijata!). Johonkin asiaan perehtymättömälle kun innoissaan selittää mahdollisimman yleistajuisesti ja tiiviisti, mulla tulee yleensä ihan oivalluksia, jotka selkeyttää myös omaa ajattelua. Ei sitä turhaan sanota, että jos haluaa oppia jonkun asian hyvin, pitää opettaa.
Monesta siinä jää paitsi, jos ulkoistaa kirjoitushommat jollekin. Luulen, että ihan jokainen aliarvioi tosi arkisten rutiinijuttujen merkitystä omalle ajattelulle ja ymmärrykselle asioista, koska niiden yhteys voi olla hyvin näkymätön.
-
Noniin, tämän ketjun kirjoittaminen taisikin selkeyttää asiaa mulle jo aika paljon.
Ou jee. Kasassa jo 200–300 (uutta) riviä enimmäkseen luurankokoodia huolimatta melkoisista keskittymisvaikeuksista. 🦴
-
Ou jee. Kasassa jo 200–300 (uutta) riviä enimmäkseen luurankokoodia huolimatta melkoisista keskittymisvaikeuksista. 🦴
Onkohan tämä jo liioittelua?
-
Onkohan tämä jo liioittelua?
Nyt koodia on jo melkein 600 riviä, mutta varmaan puolet siitä lienee jotain harhapolkuja, jotka joutaa poistaa sitten joskus. Tuli vähän kirjoitettua jo ekaa toiminnallisuuttakin, eikä pelkkiä tyhjiä määrittelyjä ja muita luita.
Samalla siinä tuli myös ensimmäistä kertaa ikinä kirjoitetuksi async Rustia, kun ajattelin että se varmaan yksinkertaistaa asioita. Vähän kyllä jännittää, että mitä siitäkin tulee lopulta. En ole ennen uskaltanut siihen koskea.
-
Nyt koodia on jo melkein 600 riviä, mutta varmaan puolet siitä lienee jotain harhapolkuja, jotka joutaa poistaa sitten joskus. Tuli vähän kirjoitettua jo ekaa toiminnallisuuttakin, eikä pelkkiä tyhjiä määrittelyjä ja muita luita.
Samalla siinä tuli myös ensimmäistä kertaa ikinä kirjoitetuksi async Rustia, kun ajattelin että se varmaan yksinkertaistaa asioita. Vähän kyllä jännittää, että mitä siitäkin tulee lopulta. En ole ennen uskaltanut siihen koskea.
@nen async rustissa on sit sellanen ärsyttävä sudenkuoppa et kun alat tarvimaan Mutexia datan säilöön, ni muista käyttää async runtimen ( tokio? ) omaa Mutexia, ei std: : sync: : Mutex. Mä kompastun tohon joka hemmetin kerta.
-
@nen async rustissa on sit sellanen ärsyttävä sudenkuoppa et kun alat tarvimaan Mutexia datan säilöön, ni muista käyttää async runtimen ( tokio? ) omaa Mutexia, ei std: : sync: : Mutex. Mä kompastun tohon joka hemmetin kerta.
@jago Hyvä tietää! Onneksi mulla on niin vähän rutiinia, että joudun joka tapauksessa tsekkaamaan mutexit ja rwlockit ym. IDE:n täydennysehdotuksista. Iso todennäköisyys, että näen siinä heti vieressä runtimen oman version. Joskus on jotain hyviäkin puolia siinä, ettei osaa.
-
Nyt koodia on jo melkein 600 riviä, mutta varmaan puolet siitä lienee jotain harhapolkuja, jotka joutaa poistaa sitten joskus. Tuli vähän kirjoitettua jo ekaa toiminnallisuuttakin, eikä pelkkiä tyhjiä määrittelyjä ja muita luita.
Samalla siinä tuli myös ensimmäistä kertaa ikinä kirjoitetuksi async Rustia, kun ajattelin että se varmaan yksinkertaistaa asioita. Vähän kyllä jännittää, että mitä siitäkin tulee lopulta. En ole ennen uskaltanut siihen koskea.
En tiedä miten näin pääsi taas käymään, mutta lähitulevaisuudessa edessä hieman koodin selkiyttämistä...
Tämä kun ei mitään hankalaa matikkaa ole, niin koodin pitäisi olla minusta mahdollista tiivistää näytölle kerralla mahtuvaksi funktioproosaksi, joka on helpompi tajuta ja tarkistaa.
-
En tiedä miten näin pääsi taas käymään, mutta lähitulevaisuudessa edessä hieman koodin selkiyttämistä...
Tämä kun ei mitään hankalaa matikkaa ole, niin koodin pitäisi olla minusta mahdollista tiivistää näytölle kerralla mahtuvaksi funktioproosaksi, joka on helpompi tajuta ja tarkistaa.
Rivejä tuli naputeltua tänään lisää sellaiset 26% ja pakattuna koodia 18%. Jotain taisin poistaakin, eli suht tuottoisa päivä.
Välillä meinasin jäädä taas kunnon jumiin, mutta sängyssä silmät kiinni makoilu auttoi. Hoksasin virheitä ja unohtamiani juttuja siinä pötkötellessä.
-
Rivejä tuli naputeltua tänään lisää sellaiset 26% ja pakattuna koodia 18%. Jotain taisin poistaakin, eli suht tuottoisa päivä.
Välillä meinasin jäädä taas kunnon jumiin, mutta sängyssä silmät kiinni makoilu auttoi. Hoksasin virheitä ja unohtamiani juttuja siinä pötkötellessä.
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.
-
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.
-
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.
-
Nyt on paljon parempi. Tuo kahdesti viitattu silmukkafunktiokin on pilkottu pienempiin osiin.
Jaa-a, taidanpa kirjoittaa puolet taas uusiksi puhtaalta pöydältä...
-
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.
-
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/
