Ohjelmointi

[a4]

https://twitter.com/amasad/status/1598042665375105024

Two days ago OpenAI released ChatGPT, a new language model which is an improved version of GPT-3 and, possibly, gives us a peek into what GPT-4 will be capable of when it is released early next year (as is rumoured). With ChatGPT it is possible to have actual conversation with the model, referring back to previous points in the conversation.

I wanted to try out if I could use this model as a pair programmer that I can give some instructions and it produces the code for me.   
https://towardsdatascience.com/i-used-chatgpt-to-create-an-entire-ai-application-on-aws-5b90e34c3d50

[-:)lauri]

Edellisissä viesteissäni kuvailema projektini on siis tehty Laravel 8 -versiolla käyttäen php 7.4 -versiota. Meidän palvelinporukka kuitenkin juuri linjasi työkaverilleni, että kivikautista teknologiaa varten ei enää kyhätä AWS-ympäristöä meidän firmassa, joten pitää minunkin siirtää projekti Laravel 9 -versioon ja php 8 -versioon.

Olin ottanut omaan projektiini asetukset työkaveriltani kun ajateltiin esimieheni kanssa, että on näin helpompi ohjeistaa palvelintiimiä sitten kun projektit tyrkätään eetteriin. Tosin tämä uusi tilanne muuttaa sen verran, että ainakin työkaverini projekti viivästyy. Toivottavasti ennätän itse tekemään tarvittavat muutokset, jotta oma projekti ei viivästy. Paljon olisi muutenkin vielä matkaa maaliin ja aikaa ehkä vain puolitoista kuukautta, joten kyllä tämä hieman stressitasoja nostaa.

Koneellani on useita eri projekteja, jotka nojaavat vanhempiin xamppin kehitysympäristöihin. Tarkoittaen, että koneeni asetuksia ei voi noin vain muuttaa ja alkaa rakentaa uusimmalla xamppilla projekteja. Koneen asetusten säätely yhteensopivaksi uusimman teknologian ja vanhempien teknologioiden välillä on työlästä, ja jos tulee joitain akuutteja ylläpidollisia velvoitteita, asetusten säätäminen ad hoc vanhan ja uuden ympäristön välillä mahdollisesti vain muutaman koodirivin tähden on vittumaista.

Pitää siis toisin sanoen hylätä xampp ja opetella äkkiä Docker riittävän hyvin, jotta pystyn jatkossa rakentamaan kehitysympäristön minkä aikakauden teknologiaversioille vain muutamalla rivillä koodia tiedostoon projektikansiossa.

Eli työmäärä nykyisessä projektissa lisääntyi kertaheitolla jonkin verran enkä ole varma kuinka paljon. Tiedän tosin mistä katsoa mallia, että Docker ympäristö saadaan pystyyn (ehkä),  joten siihen ei ehkä kulu paljoa aikaa. Enempi kysymys on siitä, onnistunko kopioimaan Laravel 8 -versiosta koodit Laravel 9 -versioon ja kuinka nopeasti niin, että ohjelma toimii myös tuolla uudella alustalla.

[-:)lauri]

^
Nyt on melkein pelit ja vehkeet. Olen saanut samaan docker-compose.yaml-filuun seuraavat palikat: serverinä nginx, koodikisrjastona php, tietokantana mysql ja kovasti tykkäämäni phpmyadmin tietokannan selaamista selaimessa varten. Tämä asetelma vaikuttaa toimivan nyt kuten pitää. Tosin en ole kokeillut vielä kaikkia yksityiskohtia. Pitää säätää myös jossain välissä nuo versiot staattisiksi. Nyt tää imee uusimmat versiot, mikä ei voi tulla kyseeseen joka kerta kun projekti käynnistetään vaan vain silloin kun versiota tietoisesti muutetaan. Pitää taikoa tähän vielä composer ja sen avulla uusin Laravel. Pitää tehdä oma rajapinta ilmeisesti myös Laravel-spesifille "php artisan" -komennolle, jotta voin ajaa Laraveliin sisäänrakennettuja komentoja.

EDIT: Nyt vaikuttaisi olevan palikat kohdallaan. Pitää vielä yrittää asentaa laravel ja katsoa, että se toimii. Tietokantayhteyden porttiasetuksia pitää kuitenkin säätää. Tarkoitus on pitää vanha xampp-päällä ja tämä uusi docker-versio päällä samaan aikaan kun pitää suunnitella rajapinta vanhan ja uuden järjestelmän välillä, jotta voi kopioida tietokantatietueet vanhasta järjestelmästä uuteen. Verkkosivujen portti on tässä nyt eri kuin xamppissa mutta tietokantayhteyden portti on ymmärtääkseni sama, mitä se ei saisi olla.

EDIT 10.02.02023: En ole vielä kokeillut toimiiko. Koodit on nyt paikoillaan Laravelin 9-versiossa. PHP taitaa olla 8.1 -versio. Ensi viikolla pitää saada toimimaan. Tänään olen rakentanut koko päivän vanhaan järjestelmään rajapintaa, josta saa tilattua tarvittavien tietokantataulujen sisällön. Helppo tehtävä, mutta perkeleesti täytyy näpytellä. Vielä jäi yksi end pointti yhtä taulua ja kaksi end pointtia liitetiedostojen siirtoa varten ensi viikolle. Sitten pitää saada toi docker-hässäkkä pystyyn ja tehdä uuteen järjestelmään cron-ajoksi tuo tietokantojen imurointi vanhasta järjestelmästä. Sitten on vielä toinenkin vastaavanlainen projekti mutta siinä ei kai tartte muuta kuin saada se dockerissa pystyyn. Sitten molemmat virman palvelinhemmojen avustuksella AWS:sään, jotta asiakas pääsee testaamaan. Jos pidetään kiirettä on ihan mahdollista, että ensikuun deadlineen ennätetään. AWS-hommat voivat kuitenkin edellyttää jotain, mitä en ole huomioinut. Sekin siis voi ottaa oman aikansa, että saamme testijärjestelmän eetteriin. Ei taida ihan ensi viikolla ennättää kaikkea tuota. Torstaina olisi taas palaveri asiakkaan kanssa ja ajatus oli alun perin, että olisi jotain näytettävää. Toivottavasti edes toinen järjestelmistämme olisi testivalmiudessa, mutta jos ei ole sitten ei ole.

EDIT: Oli ihan pakko naputella tuo rajapinta loppuun. Pääsee sitten maanantaina heti docker-viritysten kimppuun.

EDIT: Ei toimi docker-viritys. Oli pakko kokeilla tällä omalla koneella, miten tietokantayhteys onnistuu laravelilla ja eihän se onnistu. Nyt on sitten tenka på, miksi ei onnistu. Pitää copypeistata Udemy-kurssista dockeriin laravel-asetukset (ehkäpä tietokantayhteys onnistuu niin) ja vasta sitten pähkäilen, saisinko siihen liitettyä phpmyadminin. Olen käyttänyt jotain netistä löytämääni pohjaa ja se polku ei ole tuottanut tulosta.

EDIT 15.02.2023: Tänään kerkesin testailemaan tuota omalla koneella ja sain laravel-projektin toimimaan dockerissa tietokantayhteyksineen kuten pitääkin. Seuraavaksi pitää laittaa samat asetukset työkoneelle. Hieman tarvitsi jumpata. Ongelma mitä ilmeisemmin oli vain tietokanta-asetuksissa. Dockerissa piti laittaa palvelun nimi porttitietojen paikalle, jota en ollut tehnyt. Saa nähdä meneekö ihan tuolla muutoksella vai pitääkö rakentaa docker-projekti ihan tyhjältä pöydältä. Saatiin viikko lisää aikaa duunaa tätä jotta olisi asiakkaalle jotain näytettävää. Eli josko saisin tällä viikolla datan siirron kirjoitettua valmiiksi, niin saisi ensi viikolla projektin testipalvelimelle ja tehtyä datansiirron sinne.

[-:)lauri]

Pitää käyttää projektissa s3-tallennustilaa ja alustavasti vaikuttaa siltä, että pystyn systeemin tekemään. Hankaluutena oli, että s3:sta pitää käyttää suoraan frontendistä. Laravel tarjoaa liittymän suoraan backendistä, mutta jotta saadaan serverin resurssien kulutus minimiin, pitää tuo toteuttaa niin, että frontend neuvottelee suoraan s3:n kanssa eikä rasita backend-serveriä tiedostolla.

- Tiedoston tallentamisen algoritmi:

1. Pitää ensin palauttaa käyttäjän tokeni frontendiin kun sivu ladataan,
2. Sitten kun tiedosto ladataan pitää backendille lähettää tokenilla autentikoitava liitetiedoston nimi
3. backend rakentaa yksilöllisen nimen tiedostolle
4. backend tilaa s3:elta suoran url-osoitteen tallennusta varten. Osoitteessa tiedot tiedoston nimestä ilmeisesti kryptattuna.
5. backend palauttaa tuon suoran url-osoitteen frontendille. Samaten palautetaan yksilöllinen tiedoston nimi.
6. frontend puskee tiedoston s3:een käytteän tuota url-osoitetta
7. Kun frontend saa varmistuksen s3-palvelimelta, että tiedosto tallennettu, lähettää frontend tokenilla autentikoitavan tiedoston nimen backendille
8. backend tallentaa tiedostonimen backendin tietokantaan

- Tiedoston lataamisen/katsomisen algoritmi muuten sama, mutta backendin tehtävänä on palauttaa s3:sta löytyvä osoite tiedostonimellä ja tuo osoite sitten pitää ladata tyhjään selaimen tabiin ilman nimen tallentamista.

- Tiedoston poiston algoritmi kaiketi toimii samoin, mutta backendin pitää palauttaa url tiedoston deletoimiseen. Ja kun s3 palauttaa tiedon, että tiedosto poistettu, lähetetään backendille speksit poistaa merkintä tietokannasta.

Vaikuttaa alustavasti siltä, että löytyy speksit kuinka laravelin api-rajapinta voidaan rakentaa projektissa niin, että laravel tarkistaa, että käyttöoikeudet löytyy, ilman turhia kikkailuja, mutta se selviää kunhan pääsen koodiin käsiksi. Samaten löytyy ilmeisesti koodit lähes valmiina, kuinka tämä toteutetaan Nodella, josta vain copypeistaan ja konvertoin backendin koodit php:lle.

[-:)lauri]

Joo, toi docker on siinä mielessä hieman hankala alusta ainakin mun windows-koneessa, että se kadottaa aika-ajoin kaikki tiedostot. Kaksi kertaa kadotti tänään tiedostot.

1. Pitää ensin koodata
2. ottaa varmuuskopio tiedostoista
3. pitää buildata projekti dockerissa ja testata muutokset
4. pitää laittaa docker taas alas
5. paluu kohtaan 1.

Mä luulin, että tämä olisi yhtä sujuvaa, kuin xamppilla mutta eipä olekaan. Dockerilla sivujen ajo selaimeen tarkoittaa muutenkin, että jokaisen sivun lataaminen kestää useita sekunteja. Mun duuniläppäri on kyllä jo 5 vuotta vanha ja siinä on "vain" 16 gigaa rammia. Duunikaveri oli sitä mieltä, että mulla on niin arkaainen läppäri, että uutta pitäisi saada tilalle. Sillä on uusi läppäri, jossa 32 gigaa rammia ja normiajossa se varasi muistaakseni noin 12 gigaa rammia käyttöön. Tuo mun koneen ikä tai varmaankin vähäinen ram voisi olla yksi syy dockerin hitautueen. Pitääpä ottaa esimiehen kanssa puheeksi uusi läppäri.

[-:)lauri]

Pitääpä kokeilla jossain välissä laravel sailia. Sillä ainakin saa tuota domainia muutettua.

[-:)lauri]

En ole saanut aikaiseksi koodata Electron js -applikaatiota, joka listaisi C-asemalla olevat Xampp-softat ja joka avaisi valitun Xampp-softan komentopaneelin kun valitaan haluttu Xampp. Laitoin hetki sitten ChatGPT:n asialle. Eli jaoin tehtävän olettamiini työvaiheisiin, kuinka ongelma ratakaistaan Electron js sovelluskehyksessä ja sitten kysyin koodit tekoälyltä per työvaihe. Alustavasti näyttää siltä että koodit ovat toimivia. Pitää seuraavaksi suunnitella käyttöliittymä jakaa sen rakentaminen työvaiheisiin ja kysyä työvaiheittain koodit tekoälyltä. Eli huomaan tässä harjoittelevani koodaamisen ulkoistamista tekoälylle

Edit: Itse asiassa pyysin tekoälyltä just koko ohjelman koodeja varsinkin kun on niin pieni ohjelma. Sekin näköjään onnistui. Enää tarttee vain kopioida koodit ja ajaa ne omalla koneella. Tai no, haluan tietysti askarrella käyttöliittymän hieman visuaalisemmaksi kuin tuo simppeli tekstilista, joten tarvittaneen minultakin hieman css-askartelua.

[-:)lauri]

Ostin Udemystä aloittelijan kurssin AWS:sää. Mulla oli jo aiemmin ostamani ohjelmoijille ja järjestelmäarkkitehdeille tarkoitetut AWS-kurssit, mutta ehkä parempi aloittaa suosiolla aloittelija-tasolta sillä AWS on iso paketti ja jos alkeet ei ole hyvin hallussa voi olla vaikea hahmottaa järjestelmän isompiakaan kokonaisuuksia.

Syksyllä on duunissa koulutussessio, jossa olisi tarkoitus oppia tuo ohjelmoijan oppimäärä tai ainakin sertifikaattiin riittävä osa siitä. Olen kuitenkin niin hidas oppimaan, että piti ostaa ennakkoon noita kursseja, jotta ennättäisi omaksua jonkun tyhjää paremman käsityksen kuinka AWS toimii, jotta ei ole täysin kujalla, että mite kaikki eri AWS-kirjainyhdistelmät tarkoittavat.

Meillä on firmassa sellainen ajatus tässä taustalla, että me kehittäjät otamme jatkossa isomman vastuun myös palvelinten säätämisestä omiin ohjelmiimme sen sijaan että sälytämme kaiken palvelinhemmojen harteille. Eli sitä varten pitää nyt sitten opetella AWS:sää. En kyllä vielä tässä vaiheessa pistä yhtään vastaan. No eiköhän se ääni tässäkin kellossa muutu, kun aloittelijoiden kurssi AWS:stä sujahtaa yli hilseeni

[-:)lauri]

Meillä lopetti yksi koodaaja viime jouluna ja häneltä jäi toi pyytton-projekti osittain keskeneräiseksi. Siitä ei ole säästynyt meille kuitenkaan mitään dokumentaatiota, vaikka meillä on palvelu joka toimii kyseisen koodin toimivien osioiden pohjalta. Projektin vetäjä oli sitä mieltä, että palvelinhemmo osaisi auttaa selvittämään, kuinka tuo ohjelma toimii kun on sen palvelimen sille joskus kaksi vuotta sitten pystyttänyt. Ja kun palvelinhemmo totesi, ettei muista miten palvelin toimii tässä tapauksessa ja, että parempi kirjoittaa koko koodi alusta asti uudestaan kun ohjelman toimintalogiikka voi olla melko mahdoton ratkoa ilman dokumentaatiota, projektin vetäjä piti toivoa yllä, että kun esimiehemme palaa ensi viikolla lomilta, on vielä viimeinen oljen korsi, että hän tietäisi kuinka koodi toimii.

Otin tämän haasteena. Tietenkin. Ja eilen iltaan mennessä olinkin sitten saanut pääteltyä, kuinka tuo koodi toimii. Maanantaina sitten nähdään, auttoiko tämä asiaa yhtään, mutta odotusarvona on, että ehkäpä ei tarvitse aloittaa projektia nollasta asti, jotta saamme vietyä projektin viimein maaliin asti.

[-:)lauri]

Rakennan reactilla hakulomaketta, mutta en ole täysin varma kuinka sen tiedot lähetetään osoiterivillä palvelimelle. Haluaisin käyttää react router domin Link-komponenttia, sillä react router dom tarjoaa vaivattoman tavan pelata linkkien kanssa frontendissä, mutta vielä on enemmän kysymyksiä kuin vastauksia. Voiko link-komponentin querystringin generoida kokonaan dynaamisesti vai eikö voi. Toinen avoin kysymys on se, kuinka selaimen osoiterivi tykkää hakasulkeista query-parametrien avainkentissä ja jos selain urlenkoodaa hakasulkeet, meneekö selain sekaisin koko osoitteen kanssa tai jos ei mene, onko query string palautettavissa alkuperäiseen hakasulje-muotoon javascriptillä jotenkin kivuttomasti.

...tai jos sittenkin jättäisi tuosta avain-kentästä pois hakasulkeet. Enkoodaisi arrayn ensiksi json-muotoon ja sen jälkeen enkoodaisi url-muotoon ja laittaisi sen tavallisen tekstimuotoisen avaimen arvoksi. Javascript ja Laravel osaisivat todennäköisesti molemmat lukea arvon json-tekstiksi, jonka sitten vain dekoodaisi takaisin arrayksi. Eikä tulisi kaiketi ongelmaa sen kanssa, että selain rikkoisi query-stringin. Kyllä. Tämä on ihan kelpo vaihtoehto.

[-:)lauri]

Meillä on duunissa muutama asiakas, joilla käytössä yksi meidän vanhoista ja päivitystä odottavista järjestelmistämme. Jokaisella noista asiakkaista on hieman omanlaisensa toteutus tuosta samasta järjestelmästä. Tämä on tarkoittanut, että jokaisella heistä on pienin omin erikoisuuksineen kuitenkin oma kopio pääsääntöisesti samasta koodista. Tarkoitus olisi alkaa päivittämään tuota toteutusta ajan tasalle syksyllä. Alustavasti lähdemme siitä, että kaikilla noista asiakkaista olisi uudessa järjestelmässä käytössä sama koodi sisältäen kuitenkin asiakaskohtaiset eroavaisuudet. Ja tässä kohtaa pitäisi keksiä koodauskäytäntö, jolla noita asiakaskohtaisia ominaisuuksia voisi helposti lisätä tai poistaa käytöstä riippuen, kuka asiakkaista on kyseessä ja mitä mahdollisia kehitettäviä ominaisuuksia jatkossa tarvitaan kaikille (tietoturvaratkaisut) tai asiakaskohtaisia (asiakkailla jo nyt omat tarpeensa siinä, mitä tietoa tai ominaisuuksia kyseisen tiedonkäsittelyn kannalta tarvitsevat tai eivät tarvitse).

Olen tässä omalla koneella hieman harjoitellut ajatusta tuottaen backendiä Laravelilla ja frontendiä Reactilla. Ajatukseni on, että keskeiset React-komponentit ladataan dynaamisesti backendistä tilattavan asiakaskohtaisen json-tietorakenteen (malli siitä miltä Reactissa purettu json-tietorakenne tulee näyttämään) pohjalta.

Tämä ei ehkä ole semanttisesti täysin oikea tulokulma, sillä kaiketi tuota sivuhierarkia tulisi hallinnoida sitäkin Reaktissa ja että backend ei ottaisi siihen kantaa mitä fronendissä tehdään, mutta katsotaan nyt. Alustavasti tämä tulokulmani kuitenkin vaikuttaa intuitiiviselta suhteessa siihen, miten käyttöoikeudet vaikuttavat näytettävään sisältöön. Jos hallinnoisi tätä Reactissa pitäisi vielä erikseen hallinnoida tätä backendissä. Nyt kun sisältöä hallinnoidaan yhdessä paikassa backendissa, on ehkä helpompi olla tekemättä tietoturvan kannalta kohtalokkaita virheitä... tai näin olen ainakin alustavasti ajatellut.

[Jaska]

Olen tässä omalla koneella hieman harjoitellut ajatusta tuottaen backendiä Laravelilla ja frontendiä Reactilla. Ajatukseni on, että keskeiset React-komponentit ladataan dynaamisesti backendistä tilattavan asiakaskohtaisen json-tietorakenteen (malli siitä miltä Reactissa purettu json-tietorakenne tulee näyttämään) pohjalta.

Olen aprikoinut millaiseen keskusteluun tai tiedonjakoon -:)lauri:n ohjelmointiaiheiset viestit ilmeisesti palkkatöistään on tarkoitettu. En osaa kuvitella niitä foorumin jäsenille informatiivisiksi enkä edes työpaikan kolleegoille linkitettäviksi. Kun itse tietojärjestelmien rakentamista olen tehnyt,  asiat asiakkaille tehtävistä töistä olivat nimenomnaisesti kiellettyjä kertoa yrityksen ulkopuolelle virallista tiedotusta lukuunottanatta.
Lähinnähän nuo näyttävät itselle tehdyille asioiden jäsentämisille, joissa ajatus mahdollisista lukijoista ryhdistää omaa kirjoittamista. Onneksi jo ensimmäisestä rivistä näen, ettei viestissä ole mitään itselleni.

[-:)lauri]

https://support.google.com/mail/thread/5636906/is-there-anyway-to-add-timings-in-filters?hl=en

Ei ole mahdollista.

https://support.google.com/mail/thread/42032078/how-do-i-automatically-remove-labels-with-filters?hl=en

Ja toinen epäkohta, joka pikaisella haulla selvisi, oli se, että ei voi kirjoittaa filtteriä, joka voisi poistaa mitään muuta labelia, kuin inbox-labelin. Varjelkoon, että gmail on arkaainen ohjelma.

Ymmärrän kyllä, että jos sofistikoituneempien filtterien kirjoittamiseen olisi tarjottu mahdollisuus, osaamattomissa käsissä käyttäjät saisivat piilotettua itseltään kaikki viestit sen lisäksi, että ikuiset luupit saisivat selaimensa pysähtymään. Se taas aiheuttaisi ikävän käyttäjäkokemuksen, mikä puolestaan aiheuttaisi käyttäjien kaikkoamisen palvelun parista. En vain osannut taaskaan arvata, kuinka saatanan osaamattomat ovat käyttäjien kädet.

Tässä parhaimassa tapauksessa olisi projekti. Jos kirjoittaisi oman liitännäisen gmailiin. Tosin pahoin pelkään, ettei gmailin api mahdollista ajan mittaamista liitännäisillekään taikka vasta vuoroisesti tarjoa viestikohtaista eventtiä milloin mikäkin viesti on avattu.

[-:)lauri]

^
Juu ei ole projektia:

https://developers.google.com/apps-script/add-ons/gmail

[-:)lauri]

Kirjoitin yhden Laravel-harjoittelutyön viikossa alusta asti uusiksi. Laravelia tässä opetellut lisää. Nyt ohjelmasta tuli hieno. Se on sellainen jonkinlainen S2S-ohjelma. Olen kolmatta viikkoa yrittänyt kirjoittaa softaa uusiksi, mutta useamman kerran pitänyt aloittaa alusta, kun olen oppinut virheistäni lisää. Seuraavaksi pitää laittaa tekoäly ensin kommentoimaan koodia ja sitten pyytää sitä kirjoittaa testit jokaiselle funktiolle.

Toi testaaminen onkin seuraava iso juttu, mikä pitäisi opetella. Simppelit testit onnistuu minultakin, mutta kun luokillani on lukemattomia riippuvuuksia muista funktioista ja luokista. Niissä muissa luokissa ja funktioissa on mahdollisesti juuri yhteydenottoa muille palvelimille ja sieltä tulevan datan validointia testatessa, ei voi muodostaa aitoja yhteyksiä noille palvelimille, vaan pitää ensin yrittää sisäistää kuinka verkkoliikennettä feikataan Laravelissa ja sitten se, miten feikkaan sitä tilanteessa, jossa en operoi suoraan kyseisten funktioiden tai luokkien kanssa vaan niin että ne ovat kaukana tiedostopuussa.

Ehkäpä toi testaaminen tällaisissa tapauksissa toimii jotenkin niin, että mockataan noiden funktioihini liittämäni toisten funktioiden palauttaman datan jotenkin. En kyllä vielä osaa sitä tehdä.

Parin koepalloni perusteella ei ilmeisesti riitä, että jäljittelen hölynpölydatalla omien funktioitteni toimintaa, jos mikään osa on riippuvainen Laravelin toteutuksesta. Silloin pitää kaiketi opetella mikä luokka Laravelissa kuuluu mihinkin ryhmään ja sitten se, missä järjestyksessä Laravel käy nuo omat luokkansa läpi, jotta oppisi feikkaamaan oikeat luokat ja niiden tuottamaa dataa oikeassa järjestyksessä.