Ohjelmointi

[-:)lauri]

Yritän tässä motivoida itseäni pientä grafiikkaprojektia varten. Olen joskus pleistoseenikaudella väsännyt nämä kiemurtelevat viivat. Ne kaipaisivat hieman päivitystä. Tuo oli omalla mittapuullani silloin kova saavutus, että sain linjat piirtymään kuvaruutuun ilman kulmia, kun piti opetella peruskoulupohjalta ymmärtämään kuutioisen Bezier-käyrän matematiikkaa ja keksiä kuinka muuttaa se koodiksi.

Tuossa annetaan tasaisen epäsäännöllisesti jokaiselle viivalle kuvaruudun keskipiste, jonka kautta ne sitten kulkevat, mutta efekti jää kyllä luvalla sanoen aika olemattomaksi.

Projektissa, jonka ajankohtaa en vielä tiedä olisi ajatus antaa viivoille tuon keskipisteen lisäksi kolmas ulottuvuus, sekä aika, jossa niiden olisi palattava keskipisteeseen. Se miten organisoida tuo viivojen paluu keskipisteeseen vaatii sisäisen koreografin löytämistä itsestäni. Eli pitänee jakaa kiemurtelu sykleihin. Ehkäpä joka kahdeksannella kerralla kaikki viivat palaavat keskipisteeseen samaan aikaan ja joka neljännellä kerralla vain puolet. Muilla kerroilla ehkä vain yksittäin tai kaksittain. Tuo pitää kyllä kirjoittaa niin että voin kokeilla erilaisia asetuksia, joilla saada hyvä koreografia aikaiseksi.

Samaten pitäisi voida säädellä nopeutta tuossa keskipisteeseen palaamisessa, pois lähtemisessä ja sitten siellä kehällä. Esimerkiksi jotenkin, että keskipisteeseen tultaessa vauhti kiihtyy ja keskipisteestä lähtiessä vauhti hidastuu ja kehällä taas vauhti kiihtyy. Tai ehkäpä noita pisteitä ajassa, milloin kuljetaan täysiä ja milloin vähemmän täysiä pitäisi voida antaa vaikka kuinka mielivaltaisesti ja sitten ohjelma laskisi tarvittavat kiihtyvyydet ja hidastuvuudet automaattisesti. Siis tämäkin helpposäätöisyys sitä varten, että voisin kokeilla sopivia asetuksia. Eetterissä pitäisi toimia niin, että säädöt olisivat numeroarvoja, niin ettei turhaan laita ohjelmaa laskeman samoja säätöarvoja reaaliajassa.

Olisi myös kova juttu jos löytyisi joku ilmainen radiokanava, jonka voisi ilman tekijänoikeuskorvauksia laittaa soimaan tuohon taustalle mutta niin että musiikin rytmiä voisi selaimessa javascriptillä seurata ja laskea nuo syklit ajassa kappaleen rytmin perusteella. Ehkäpä jotenkin näin saisin kaipaamaani selkärankaa tuohon touhuun.

Se mihin projekti tulee kyllä törmäämään tälläkin kertaa on laskutoimitusten suunnaton määrä suhteessa eri selainten resursseihin. Jo tuo nykyinen pärehimmelini, jossa kirjaimia lukuun ottamatta kaikki tapahtumat generoidaan selaimessa reaaliajassa, syö selaimen resursseja suunnattomasti. Työkoneella vauhti on aika verkkaista suhteessa nopeuteen, jolla linjat vipeltävät tällä omalla koneellani.

Ehkä pitää omalla koneella laskea joku minuutti parametreja valmiiksi ja laittaa ohjelma eetterissä vain piirtämään ne näytölle kerta toisensa jälkeen. Tai sitten joku serverivaihtoehto, jossa serveri laskisi esimerkiksi kerran viikossa sopivan märän parametreja, joita sitten piirrettäisiin sivulla viikko putkeen non stoppina. Seuraavalla viikolla uusi setti valmiiksi laskettuja parametreja. Ehkäpä näin saisi suurimman osan kuormasta hitaammilta selaimilta pois. Jos noita parametreja on riittävästi, homma vaikuttaa riittävän freshiltä vaikka samaa animaatiota seuraisi useamminkin.

[a4]

^
Maallikkona sain vain tällaista aikaan: https://onecompiler.com/html/3zjng5gv6

[-:)lauri]

^
Hieno. Siitä se lähtee!

Tuossa minulla jokainen yksittäinen kiemura rakennetaan satunnaisesta määrästä "Cubic Bézier curve with four control points" -kurveja, jotka ovat liitetty toisiinsa niin, että tangentti pysyy yhden suuntaisena kahden kurvin välillä.

https://en.wikipedia.org/wiki/B%C3%A9zier_curve#/media/File:B%C3%A9zier_3_big.gif

[-:)lauri]

^^^
Jotenkin pitää ratkaista omassa tulevassa koodissa myös nuo kuvaruutujen reunat. Minäkin käytän tuossa nyt hieman väkivaltaa. Eli estääkseni linjan päätymisen selaimen reunojen ulkopuolelle niin vaikka tangentin suunta säilyykin, sen pituus ilmeisestikään ei ja lopputuloksena viiva edelleen kimpoaa reunasta.

EDIT:
Ai kamala kun tuli rikollinen ajatus mieleen. Mitä jos hoitaisi tuon voimavektoreilla. Voimakentän A keskus voisi kulkea Bezier kurvia pitkin, kuten nykyisen viivan ensimmäinen piste sitä pitkin on kulkenut. Sitä Bezier kurvia ei kuitenkaan vastaisuudessa piirrettäsi näkyviin. Sitten olisi sivun keskellään paikallaan pysyvä voimakentän B keskus. Sitäkään ei piirrettäisi näkyviin. Viiva piirrettäisiin jatkossa noiden kenttien voiman tunnistavan pisteen mukaan. Nyt voisi rytmikkäästi vaihdella kenttien A ja B voimakkuuksia ja viiva hakeutuisi vuoronperään kuvaruudun keskustaan tai Bezier kurville kiemurtelemaan.

Ihan näin helppoa tuo ei varmaankaan ole, mutta kyllä vaikuttaa nyt ad hoc kokeilemisen arvoiselta. Kyllä on jämpti.

EDIT EDIT:
Tuossa taitaa olla se ongelma, että jos voiman keskus Bezier kurvilla liikkuu ortogonaalisessa suunnassa sivun keskustassa olevaan voiman keskustaan nähden, viivamme alkaa hyvissä ajoin liikkua sivuttain ennen kuin se on Bezier kurvilla liikkuvan voiman keskustassa. Jos Bezier kurvilla liikkuva voiman keskus tekee silmukan ennen kuin viivamme kärki on siinä ihan liki, viivan kärjen liike saattaa hidastella ja kiihdytellä oudosti. Ehkäpä virtauskenttä olisi ratkaisu pulmaan. Pitäisi vain keksiä, kuinka sellainen tässä tapauksessa generoidaan.
Virtauskenttä syntyy helposti satunnaisilla arvoilla, mutta nyt kun se ei saisi olla satunnainen vaan sen virtaussuuntien syntyä ja muuttua nimenomaan kenttien A ja B perusteella, minulta on ainakin vielä ideat loppu...

1. Jos lähtee siitä, että Bezier-kurvi on laakso ja piirtoalueen kaskusta syvänne, jotka syntyvät kun toinen katoaa ja katoavat kun toinen syntyy, voitaneen jonkun "korkeuskäyräfunktion" avulla määritellä oikeaan suuntaan sojottava vektori piirtoalueen jokaiseen pisteeseen. Näin saadaan syntymään virtauskenttä, jonka suunta vaihtelee noiden kahden entiteetin välillä ja niiden ehdoin eikä satunnaisesti. ...Eli pitää piirtää virtuaali canvas:lle esimerkiksi Besier kurvi paksulla mustalla viivalla, blurrata canvas, jakaa canvas esim. 10 pikselin kokoisiin neliöihin ja sitten vektoreiden origot noiden neliöiden oikeaan alakulmaan. Kuvan ylälaidassa myös neliön vasempaan yläkulmaan ja kuvan vasemmassa reunassa neliöiden vasempaan alakulmaan. oikeassa yläkulmassa myös kyseiseen yläkulmaan. Sitten mitata pikselin tummuus jokaisen neliön keskeltä per vektori, jonka kulmaan vektori on kiinnittynyt. Asettaa vektori osoittamaan siihen suuntaan, mikä neliöistä on tummin. Näin pitäisi virtauskentän per yksi freimi olla valmis. Tätä proseduuria tuskin kuitenkaan pyöritetään selaimella 60 kuvan sekuntivauhdilla.

2. Tai ehkä sittenkin on palattava alkuperäiseen suunnitelmaan. Pitää määritellä syklin ajallinen pituus ja sitten laskea viivojen kulkemat kuviot valmiiksi niin, että syklin päättyessä, kukin viiva kulkee piirtoalueen keskustan läpi. Jos sykli on neljä sekuntia ja nopeus on 60 freimiä sekunnissa, 240 kuljetun pisteen kohdalla pitää jokaisen viivan olla takaisin piirtoalueen keskustassa. Pitää laskea kontrollipisteet valmiiksi x määrälle kurveja niin, että vikan kurvin vika kontrollipiste on piirtoalueen keskustassa. Sitten laskea jokainen kurvi niin, että kurvien yhteenlaskettu määrä pisteitä on sama kuin olisi 240/x määrä pisteitä per kurvi.

Vaikuttaa pahasti siltä, että tämä menee serveripuolen renderöimiseksi.

[-:)lauri]

Tabinesta, vs coden liitännäisestä on ilmeisesti beta vaiheessa oleva ohjelmointiin erikoistunut tekoälychatti olemassa. Esittelyvideon perusteella se vaikuttaa fiksummalta kuin chatgpt liitännäisen chatti. Tosin chatgpt tekoälychatti vs codessa on 3.5, että sikäli se alkaa tosiaan olemaan jo vanhempaa sukupolvea verrattuna internetissä toimivaan heidänkin versioon 4 verrattuna.

[-:)lauri]

Käytän seuraavassa niin paljon sanoja frontend ja backend, että avaan niitä hieman. Frontend tarkoittaa web-applikaation selaimessa näkyvää sivuston ulkoasua, eli onko käytössä mikä fontti, missä kohtaa selainta teksti näytetään tai mitä tietoa selaimessa esimerkiksi näytettäväksi backendiltä tilataan. Backend vastaa sitä osaa applikaatiosta, joka pyörii serverillä ja joka vastaa käyttäjän tekemisten tallentamisesta sekä frontendin tilaamien tallennettujen tietojen palauttamisesta frontendille.

Mikäli applikaatiot voidaan toteuttaa ilman JavaScript-pohjaisia frontend-kirjastoja kuten Reacteja ne tietysti on hyvä varmasti niin toteuttaa, mutta esimerkiksi React- tai Vue-kirjastot ovat web-kehityksessä sen verran arkipäivää meidänkin firmassa, että omien jQuery-kirjaston ympärille rakentamieni frontend "kirjastojen" käyttöä ei ole syytä suosia, vaikka niiden hyödyntäminen omaa työskentelyäni merkittävästi nopeuttaisikin. Meillä on yksi vanha järjestelmä elinkaarensa aivan äärimmäisessä loppuvaiheessaan, jossa niitä käytän, kun meillä on jo korvaava tuote käytössä, jossa käytössä uusimmat web-teknologiat.

Luin kuitenkin hiljattain uutisen koskien modernia React-kehitystä, että siinä oltaisiin ainakin joissain tapauksissa siirrytty suosimaan React ja Next -kirjastojen käyttöä tai kaiketi pelkkää Next-kirjaston käyttöä. Ymmärsin artikkelista, että siinä missä React on frontend-kirjasto, Next olisi React-pohjainen backend/frontend-kirjasto tarkoittaen, että selkeän frontend ja backend jaon sijaan olisi web-kehityksessä ainakin lähitulevaisuudessa luvallista sulauttaa molemmat applikaation osa-alueet on toisiinsa. Tämä sopisi minulle loistavasti ja tätähän fullstack-kehitys on ennen Reackteja ja muita frontend-kirjastoja ollutkin. Ei ole ollut tavallaan selkeästi kahta eri applikaatiota vaan yksi applikaatio, joka sisältää sekä backendin ja frontendin.

Jos taas frontend ja backend on erotettu omiksi kokonaisuuksikseen, edellyttää se helposti esimerkiksi MVC-hierarkian tai muun vastaavan proseduurin rakentamista erikseen niin fronendiin  ja backendiin siinä missä perinteisissä järjestelmissä riittää vain yksi sellainen. Tosin vaikka erillinen frontend ja backend edellyttävät enempi koodaamista, Niin jos applikaation jossain elinkaarensa vaiheessa olosuhteet sitä vaativat, on siinä toteutuksessa näppärää päivittää kerralla esimerkiksi koko frontend, joitain sen osia tai rakentaa saman aikaisesti toimivia useampia erilaisia frontendejä samalle backendille ilman, että tarvitsee koskea backendiin.

Mutta lukemassani toisessa artikkelissa, jossa puitiin sitä, kannattaako tietokantaspesifikoodi abstrahoida niin, että tietokantaimplementaatio on helppo vaihtaa muuttamatta muuta koodia, niin on kuulemma hyvin harvinaista, että koskaan muutettaisiin tietokantaa kesken applikaation elinkaarta ja silloinkin kun sitä silloin muutetaan, muutetaan sitä helposti niin paljon, että edes pelkän abstrahoinninkaan uudelleen kirjoittamisella ei hommasta selvitä tarkoittaen, että ylimääräiset abstrahoinnit voivat olla täysin turhia.

Toisin sanoen voinen varmaan aika luottavaisesti edistää ohjelmointitaitojani pitäen sitä mielessäni, että ellei applikaatio ole sellainen, että sen frontendin, backendin tai ominaisuuksiensa kehitystä ei ole tarkoitus ulkoistaa eri eri tiimeille puhumattakaan eri firmoille, voin keskittyä tavallaan perinteiseen fullstack-kehitykseen ja pohtia frontendin ja backendin erottamista omiksi kokonaisuuksiksi joskus myöhemmin.

Tämä tarkoittaa, että pitää yrittää ripeästi tutustua Laravel + Intertia + React kokoonpanoon. Kokoonpano mahdollistaa sen, että voisin rakentaa applikaation sekä Laravelilla että Reactilla ilman, että Laravel-implemetaatio ja React-implementaatio pitäisivät olla kaksi erillistä järjestelmää. Inertia toteuttaa nimittäin tarvittavan proseduurin Laravelin ja Reactin väliselle kommunikaatiolle.

Mikäli tulevaisuudessa backend ja fronend pitää kuitenkin voida erottaa omiksi kokonaisuuksiksi inertian korvaaminen backendissä tarkoitukseen soveltuvalla api-koodilla ja fronendissä React Router -kirjastolla ja MVC-tyyppisellä koodilla on varmasti tehtävissä hyvin vähäisellä vaivalla sillä frontend-kirjasto React ja backend-kirjasto Laravel ovat jo paikallaan.

Tietysti myös serveriasetukset paljolti määräävät voiko backend vastata myös frontendin renderöinnistä vai olisiko hyvä, että frontendin renderöinnistä vastaa käyttäjän selain. AWS:n sereveless-ympäristö edellyttää, että frontendin renderöinnistä vastaa käyttäjän selain. Tai siis ei edellytä, mutta serverin tietyillä käyttöasteilla AWS:n hintaa saadaan merkittävästi huokeammaksi, mitä vähemmän sitä serveriä, jolla backend on, käytetään. Ideaalitilanne olisi AWS:n serverless-serverin hyödyntämisessä oman applikaation api ja AWS:n tarjoama valikoima valmiita apeja, joita selain käyttää. Jotta selain osaisi niitä käyttää, edellyttää se JavaScriptiä. Jotta muutkin ohjelmoijat ymmärtäisivät kirjoittamaani JavaScriptiä tai minä ymmärtäisin nyt kirjoittamaani koodia puolen vuoden kuluttuakin on ihan perusteltua käyttää yleisessä käytössä olevia valmiita JavaScript-kirjastoja kuten Reactia tai Vueta sen sijaan, että innovoisin omia ratkaisujani jQueryllä.

Olisiko muilla ajatuksia pohdintoihini?

[Hayabusa]

MVC, poika sinä alat oppia!

[a4]

[Hippi]

[-:)lauri]

 

[-:)lauri]

Jos tekee evoluutioalgoritmin pohjalta oppivan tekoälyn, mitkä olisivat hyviä ehdokkaita perintötekijöiksi? Tekoälyn painokertoimet ennen opettelua?

[a4]

Jos tekee evoluutioalgoritmin pohjalta oppivan tekoälyn, mitkä olisivat hyviä ehdokkaita perintötekijöiksi? Tekoälyn painokertoimet ennen opettelua?

Kysy tekoälyltä.

En ole perehtynyt aiheeseen mutta voin vilkaista.
Nopeasti tulee mieleen että perintötekijät voisi pitkän kaavan mukaan antaa muodostua evoluution avulla. Nopeampi tapa voisi olla määritellä lähtötilanne karkeasti oman tavoitteen mukaiseksi.

Syväoppivat hermoverkot voisivat olla näppäriä:

Verkon matalimmat kerrokset säätyvät (oppivat) tunnistamaan esimerkiksi kuvien alkeellisia piirteitä, muun muassa reunoja ja kaaria, ja syvemmät kerrokset aina monimutkaisempia kokonaisuuksia, ilman ihmisen etukäteen määrittelemiä kriteereitä.

Useimmissa käytännön sovelluksissa hermoverkkojen opetus on ohjattua (supervised learning), jolloin opetusaineisto on annotoitua eli esimerkiksi kuhunkin kuvaan on liitetty tieto oikeasta vastauksesta. Opetuksessa hermoverkon painokertoimet optimoituvat niin, että verkon tuottaman ennusteen ja oikean vastauksen välinen erotus olisi mahdollisimman pieni.

https://www.duodecimlehti.fi/duo15753

[-:)lauri]

^
Ajatus oli tuo, että painokertointen ollessa perintötekijöitä osa niistä mutatoituu seurraavalle sukupolvelle, mikäli mutaatio on hyödyllinen tai ainakaan se ei haittaa. Pikkuhiljaa ympäristössä oikein toimiminen pitäisi parantua, kunhan mutaatiot eivät ole liian suuria.

[ROOSTER]

Minulla tahtoo mennä hermot kun välillä joutuu ohjelmoimaan hellan kellon.

Loppukäyttäjän jättäminen liian vähälle huomiolle oli Nokiallekin se suurin erehdys. Ottaen huomioon, miten valtavasti hienoa työtä ohjelmat lähes erehtymättömästi tekevät siellä taustalla, tuntuu käsittämättömältä, miten huonoja monet käyttöliittymät edelleenkin ovat.

Yhden kun opettelee kunnolla niin ei tee mieli ostaa toisenlaisella toimivaa kampetta.

Välilehti on mielestäni hyvä ehdokas uudeksi kirosanaksi.

[Hippi]

Minulla tahtoo mennä hermot kun välillä joutuu ohjelmoimaan hellan kellon.

Olen omastani havainnut, että se pysyy huomattavasti paremmin ajassaan kuin esim. mikrouunin kello, jota joutuu suunnilleen kuukauden välin pistämään aikaan. Onneksi mikrossa on vääntimet tätä varten ja niiden käytön oppi kohtalaisen helposti.

Lieden kellon säätäminen taas on itse perkeleestä, joten olen tyytynyt siihen, että se on puoli vuotta kerrallaan ympäröivän maailman kanssa samassa ajassa ja sitten taas puolivuotta aika heittää tunnilla johonkin suuntaan, jota nyt en muista. Teen joka ilta polvirukouksia, ettei tule sähkökatkoa, että veisi kellon nollille. On aivan sietämätöntä joutua klikuttelemaan ja yhtä aikaa painelemaan jotain pieniä napukoita, jotta saa numerot kellossa vaihtumaan, etenkin kun käyttöohjeessa ohje on väärin.