kantapaikka.net

Yleiset => Tekniikka => Aiheen aloitti: Juha - helmikuu 03, 2019, 10:01:17

Otsikko: Ohjelmointi
Kirjoitti: Juha - helmikuu 03, 2019, 10:01:17

Eräs harrastus. Voi varmaan luokitella joksikin tekniikaksi.

Havainto on, että jos luo omaa softaa, niin aivan kuin täytyisi opetella puhumaan kieltä, jonka puitteita on rakentamassa. Jänski havainto.

Jotain "tilapäiskieltä", ellei sitten ajattele ohjelmoinnin osuudeksi vaikka käytettyä kääntäjää, jota käyttää valmiina. Kääntäjien omia kieliäkin on paljon, ja osa kuolee ajastaan, ja uusia syntyy.

En ehkä osaa jutella aiheesta ammattimaisesti. Muutenkin aika hakusessa, tosin käytännössä haen harrastukseen ulottuvuutta vähän sieltä sun täältä, kuten yleensä rakenteluissa teen.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 17, 2019, 16:41:44
Katsoin juuri lyhyen tutoriaalin (https://www.youtube.com/watch?v=5wtnKulcquA) (n. 50min) Angularista. Onko kyseinen kirjasto täällä muille kuinka tuttu? Itselleni ovat javascript-kirjastoista Vue ja React suhteellisen tuttuja. Työssäni olen käyttänyt Vueta mutta harrastelun parissa tutustunut myös Reactiin. Nyt kiinnostaa Angular. Lähinnä siksi, että olen käsityksessä, että siihen löytyisi valmiita komponentteja enemmän kuin noihin kahteen muuhun. Olenko käsityksineni oikeassa vai joko nuo kaksi muuta kirjastoa ovat menneet Angularin ohi myös muussa kuin suosiossa?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 26, 2019, 17:34:48
Ovat duunissa vaihtamassa Drupalin Wordpressiin järjestelmissä, joissa Drupal on ollut käytössä. Drupalia en tunne mutta Wordpressiä olen joskus hieman tutkaillut. Tosin itse en ainakaan toistaiseksi ole vastannut meilllä järjestelmistä, joissa olisi käytetty kumpaakaan. Drupalissa tai jossain sen komponentissa on joku varsin tuore tietoturvariski. Tiedä sitten onko tuolla vaikutusta siihen, että ovat meillä siirtymässä pois Drupalista. Onko jollain muulla kokemusta noista CMS-alustoista?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 01, 2019, 14:46:38
Okei, web devauksen front-end ei siis ole palstalaisille juurikaan tuttua? Miten on back-endin laita?
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - maaliskuu 01, 2019, 17:57:28
Lainaus käyttäjältä: Tuottavuusloikka - maaliskuu 01, 2019, 14:46:38
Okei, web devauksen front-end ei siis ole palstalaisille juurikaan tuttua? Miten on back-endin laita?
Itse lähinnä vaniljamies mutta seuraan ketjua.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - maaliskuu 02, 2019, 02:30:38

Muistan lukeneeni, että netissä on ilmaisia yleissivistäviä ohjelmointikurseja myös vasta-alkajille. Olisiko läsnaolijoilla nimetä hyviä ja kertoa kokemuksia. Esimerkiksi Javascript olisi otollinen nettisivustolla opetettavaksi. Ehkä suomalaisilla opinahjoilla olisi nettiopetusta aivan suomen kielelläkin?

Itseäni en voi sanoa vasta-alkajaksi. Kolmenkymmenen ensimmäisen vuoden aikana käytin kolmeakymmentä ohjelmointikieltä. Sittemmin lisäkieliin tutustuminen on harventunut enkä lukuakaan ole pitänyt. Ohjelmistorakennuskaan ei enää ole isolla painolla ollut. Mutta olisi itsekin hauska katsoa miten nyt ohjelmantekoa ajatellaan.

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 02, 2019, 02:57:06
Ilmaisista suomen kielisistä ohjelmointikursseista netissä ei tule itselleni muita mieleen kuin Helsingin yliopiston tietojenkäsittelytieteen laitoksen ylläpitämän MOOC (https://mooc.fi/)in kautta tarjotut kurssit ja sielläkin ensimmäinen suomen kielinen javascript-kurssi näki päivänvalon vasta viimevuonna nimikkellä "Full stack open 2018". Tai ainakaan itse en ole törmännyt muihin ilmaisiin netissä oleviin suomen kielisiin ohjelmointikursseihin (kuin MOOCin tarjoamat) puhumattakaan, että kurssi käsittelisi javascriptiä. En ole tuota MOOCin kurssia käynyt, mutta sen perusteella, mitä olen sellä joskus kauan sitten tutustunut JAVAan ja hiljattain tekoälyyn, kurssien laadun pitäisi olla ihan hyvä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - maaliskuu 03, 2019, 08:56:31
Lainaus käyttäjältä: a4 - maaliskuu 01, 2019, 17:57:28
Lainaus käyttäjältä: Tuottavuusloikka - maaliskuu 01, 2019, 14:46:38
Okei, web devauksen front-end ei siis ole palstalaisille juurikaan tuttua? Miten on back-endin laita?
Itse lähinnä vaniljamies mutta seuraan ketjua.
Sama juttu - ei mitään kinky-juttuja.  ;D
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - maaliskuu 03, 2019, 20:36:07
Lainaus käyttäjältä: Hayabusa - maaliskuu 03, 2019, 08:56:31
Lainaus käyttäjältä: a4 - maaliskuu 01, 2019, 17:57:28
Lainaus käyttäjältä: Tuottavuusloikka - maaliskuu 01, 2019, 14:46:38
Okei, web devauksen front-end ei siis ole palstalaisille juurikaan tuttua? Miten on back-endin laita?
Itse lähinnä vaniljamies mutta seuraan ketjua.
Sama juttu - ei mitään kinky-juttuja.  ;D
Ketjun otsikon ja selkeän avausviestinsä mukaisesti tässä hieman harrastukseen ulottuvuutta vähän sieltä sun täältä:

Rakkauden koodi
Yle TV2
Deittiohjelma, jossa paritus perustuu henkilöiden dataan ja algoritmiin, ei ulkonäköön, aatteisiin tai toiveisiin.

Seuraava esitys Yle TV2 ke 6.03.2019 klo 11:30. 5/8.
Tuossa esittelyssä yksi sanavalinta viittaa johonkin kinkyyn mutta energiajuomalla siitä selvitään.
https://areena.yle.fi/1-4456083

Docstop: Team Whack - kaikki on hakkeroitavissa
Kuusiosainen sarja Yle Areenassa 4.3. alkaen
Kolme ammattihakkeria paljastaa kuinka sinunkin elämäsi voidaan sekoittaa. Kohteeksi joutuvat yksityiset älylaitteet, henkilöauto ja kokonainen taloyhtiö. Tavoitteena on auttaa suojautumaan hyökkäyksiltä. O. Jani Pyylampi

Hippi ainakin mainitsi jossain viestissään olleen kiinnostunut taloyhtiönsä toiminnasta, joten ehkä tästä saa jotain niksejäkin.
Monien naapureilla on myös autoja.
https://areena.yle.fi/1-4664681
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - maaliskuu 03, 2019, 22:18:15
Lainaus käyttäjältä: a4 - maaliskuu 03, 2019, 20:36:07
Docstop: Team Whack - kaikki on hakkeroitavissa
Kuusiosainen sarja Yle Areenassa 4.3. alkaen
Kolme ammattihakkeria paljastaa kuinka sinunkin elämäsi voidaan sekoittaa. Kohteeksi joutuvat yksityiset älylaitteet, henkilöauto ja kokonainen taloyhtiö. Tavoitteena on auttaa suojautumaan hyökkäyksiltä. O. Jani Pyylampi

Hippi ainakin mainitsi jossain viestissään olleen kiinnostunut taloyhtiönsä toiminnasta, joten ehkä tästä saa jotain niksejäkin.
Monien naapureilla on myös autoja.
https://areena.yle.fi/1-4664681

Trailerin perusteella meille taas tarjoillaan formaattiteeveetä. Ihan kuin olisin nähnyt pätkän jostain usa-versiosta: hakkerit juonivat luolassaan ja menivät sitten kikkailemaan jonkun auton kanssa. Olisiko tullut peräti laatusarjoistaan tunnetulta Kutoselta. Tai sitten olen nähnyt reissun päällä. Anyway, täytyy vilkaista jos kotimainen olisi tehty laadukkaammin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - maaliskuu 04, 2019, 19:33:04
Lainaus käyttäjältä: Hayabusa - maaliskuu 03, 2019, 22:18:15
Lainaus käyttäjältä: a4 - maaliskuu 03, 2019, 20:36:07
Docstop: Team Whack - kaikki on hakkeroitavissa
Kuusiosainen sarja Yle Areenassa 4.3. alkaen
Kolme ammattihakkeria paljastaa kuinka sinunkin elämäsi voidaan sekoittaa. Kohteeksi joutuvat yksityiset älylaitteet, henkilöauto ja kokonainen taloyhtiö. Tavoitteena on auttaa suojautumaan hyökkäyksiltä. O. Jani Pyylampi

Hippi ainakin mainitsi jossain viestissään olleen kiinnostunut taloyhtiönsä toiminnasta, joten ehkä tästä saa jotain niksejäkin.
Monien naapureilla on myös autoja.
https://areena.yle.fi/1-4664681

Trailerin perusteella meille taas tarjoillaan formaattiteeveetä. Ihan kuin olisin nähnyt pätkän jostain usa-versiosta: hakkerit juonivat luolassaan ja menivät sitten kikkailemaan jonkun auton kanssa. Olisiko tullut peräti laatusarjoistaan tunnetulta Kutoselta. Tai sitten olen nähnyt reissun päällä. Anyway, täytyy vilkaista jos kotimainen olisi tehty laadukkaammin.
Tällaiselle tavalliselle pulliaiselle, näin muutaman jakson katsottuani, ohjelma vaikuttaa ihan silmiä avaavalta ja helposti lähestyttävältä. Ilman sitä jenkien ylidramatisoitua toistontoistoa ja actionvauhdikkuutta.
Kaikki jaksot nyt Areenalla.
Aika kuumottavaa settiä, jos vähänkin omaa mielikuvitusta. Uhrit jopa melko järkyttyneitä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 08, 2019, 22:17:55
Tein puolitoista vuotta sitten asiakkaalle suhteellisen monimutkaisen ajanvarausjärjestelmän, eikä mulla ollut sen valmistuttua silloin eikä vielä nytkään käsitystä, miksi se toimi. Siinä on reilu tuhat riviä koodia, mutta selkeesti niin monimutkaisella tavalla tehty, että en pysty seuraamaan koodia ja sanomaan mitä tapahtuu tarkalleen ottaen missä ja miksi (en tietenkään kommentoinut silloin koodia).

Tehtiin siihen päivitys jouluna ja nyt siinä on ilmennyt ensi kertaa pugi. Pari päivää ihmetellyt koodia, että mistä ihmeestä pugi mahtaisi johtua. On käynyt mielessä, että koodi kirjoitettaisiin uusiksi, mutta tässä tuskin on kahta kuukautta varattu yhden pugin korjaamiseen aikaa. Jos ensi viikon alussa ei selviä, pitänee keksiä joku äärettömän ruma purkkaratkaisu, joka tottakai tekee koodin seurattavuuden entistäkin vaikeammaksi.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 08, 2019, 22:36:46
Suurin ongelma, miksi koodia oli vaikea tehdä järkeväksi oli fullcalendar javascript -kirjasto. Se oli valittu lisäosaksi, mutta se ei todellakaan taipunut tarkoitukseen ilman koko ajanvarauslogiikan uudelleen kirjoittamista. fullcalendar onkin näytöllä lähinnä vain koodin suoritusta hidastavana joskin toki visuaalisena elementtinä, eikä meillä tuolloin tietenkään ollut siinä mitään Reactia tai Vueta tekemässä hommasta yhtään helpompaa, vaan piti jQueryllä parsia softa kasaan.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - maaliskuu 09, 2019, 09:00:17
Lainaus käyttäjältä: Tuottavuusloikka - maaliskuu 08, 2019, 22:17:55
Tein puolitoista vuotta sitten asiakkaalle suhteellisen monimutkaisen ajanvarausjärjestelmän, eikä mulla ollut sen valmistuttua silloin eikä vielä nytkään käsitystä, miksi se toimi. Siinä on reilu tuhat riviä koodia, mutta selkeesti niin monimutkaisella tavalla tehty, että en pysty seuraamaan koodia ja sanomaan mitä tapahtuu tarkalleen ottaen missä ja miksi (en tietenkään kommentoinut silloin koodia).

Ai kamala, en kyllä kehtaisi tunnustaa etten ymmärrä omaa koodaustani. Joku tuhannen rivin ohjelmanpätkä on minun silmissäni vielä pieni nyssäkkä, jonka hallitsemisessa ei pitäisi olla mitään ongelmaa.

Joskus todella muinoin tehtiin vielä ohjelmia, jotka olivat kuin lautasellinen keitettyä spagettia. Sen jälkeen kun tajuttiin, että ohjelmaan pitää pystyä kohtuullisella vaivalla tekemään muutoksia, koska maailma sen koodinpätkän ympärillä ei pysähdy. Ympäristö ja tarpeet muuttuvat, joten se väistämättä heijastuu myös uusina vaatimuksena ohjelma toimntaan. Nuo spagettikoodit muuttuivat kertakäyttötuotteiksi, koska joskus oli taloudellisempaa tehdä koko roska uudelleen ja paremmin.

Jotta ohjelmasta saa ylläpidettävän,  on sen toimintalogiikka ensin purettava auki. Siihen kynä ja paperi tai seinä ja post-it laput ovat edelleen parhaat välineet ainakin minun mielestäni. Varmaan koneella on nykyisin helppo tehdä toimintakaavioita, mutta niistä tulee aivan liian siistejä ja valmiin näköisia heti ensimmäisellä yrityksellä, joten puutteita on vaikeampi nähdä. Tuollainen lappuhahmotelma on helpompi purkaa ja rakentaa uudelleen ja etenkin isomman toiminnallisen kokonaisuuden voi hahmottaa helpommin.

Vasta kun toimintalogiikka on pöytätestattu, voi lähteä sitä toteuttamaan kooditasolle ja kukin yksittäinen toiminto omana moduulinaan / lohkonaan. Vähän varmaan kielestä sitten riippuu, miten noita toteutetaan, mutta varmasti jäsennelty tapa toteuttaa koodia mahdollista millä kielellä tahansa.

En kehu omaa työtäni, vaan firmani tapaa tehdä työtä, kun kerron, että joskus 90-luvun alussa suunnittelemani suuri laskentaohjelma oli vielä viime syksynä käytössä. Ohjelman looginen runko säilyi muuttumattomana, mutta siihen liitettiin vuosien mittaan uusia moduuleita ja moduuleiden toiminnallisia yksityiskohtia muutettiin lähes vuosittain. Muutokset johtuivat juuri vaatimusten muuttumisesta ei siitä, että vain virheitä olisi korjattu. Tosin kyllähän noin suureen ohjelmaan virheitäkin mahtui sinne lillukanvarsiin, mutta perustoiminta oli jokseenkin järkkymätön. Koodin rivimäärää en pysty arvoimaan, mutta oman ryhmämme koodaamia moduuleita oli toista sataa ja sen lisäksi vielä pakettiin kuului muiden järjestelmien tuottamia palveluita.

Se, että tuo nyt loppusyksystä haudattiin, johtui siitä, että firmamme koko tietojärjetelmät ollaan uusimassa aivan uudelle pohjalle ja noista vanhoista ohjelmista ei jää jäljelle kuin kauniit muistot.

Harmikseni olen huomannut, että uudessa järjestelmässä dokumentaation taso on huomattavasti heikompi ja koodauskin kuuluu hoidettavan ilman kokonaisuuden hahmottamista.

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 09, 2019, 15:09:01
Nää projektit meillä menee yleensä sillä tavalla, että asiakkaalla on jokin paremmin määrittelemätön idea, jota lähdetään vain sokkona toteuttamaan ja sitten pikkuhiljaa, se mitä kaikkea asiakas haluaa eli mitä pitää tehdä, selkiytyy. Jos asiakkaalta edellytettäisiin selkeät speksit heti alkuun ennen koodaamisen alkua suunnitelmia voisikin tehdä. Nyt ei juuri voi sillä ne usein muuttuvat lennossa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - maaliskuu 09, 2019, 17:25:49
Jos nyt ajatellaan ajanvarausjärjestelmää, niin onhan sen outoa, että sitä tehdään niin toimeksiannolla "me halutaan ajanvarausjärjestelmä, tuossa on kassillinen rahaa, katotaan mitä tulee".

Asiantunteva palvelun toimittaja lypsää siitä asiakkaasta irti, mitä sen värkin halutaan tekevän ja millaisin tiedoin. Jos asiakkaalla on vain idea, niin silloin asiakkaan kanssa yhdessä voidaan tehdä se toiminnallinen kuvaus, jonka jälkeen sitten toimittaja täsmentää speksit. Käyttöliittymän layoutit voidaan myös piirrellä yhdessä tai toimittaja voi piirtää ne mallit ja tehdä siitä karkean tason demon. Mitä pidempään asiakas on mukana suunnittelussa ja hyväksyy suunnittelun tuloksen, sen vähemmän tulee muutostarpeita enää siinä vaiheessa, kun homma on valmis.

Mutta tietenkin, jos toimittaja haluaakin lypsää vain rahat asiakkaaltaan, niin sitten lähdetään pelkästä ideasta rakentamaan sitä risumajaa ja tilkitään ja paikataan sitä sitten moneen kertaan.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 09, 2019, 17:33:55
Niinhän me lypsimmekin kaikki tarpeelliset tiedot mutta kun parin viikon työn jälkeen asiakkaalla on uusi idea, jolloin järjestelmä meni osittain uusiksi. Sitten taas parin viikon päästä uusi idea, jolloin järjestelmä meni taas osittain uusiksi ja niin edelleen. Mitkään alkuperäiset suunnitelmat eivät ole enää voimassa kun järjestelmä on valmis. Sitten kun noita pyritään tekemään nopeasti, jotta muut työt eivät kaatuisi niskaan, dokumennoinnin kanssa on aina vähän niin ja näin. Tässä siitä yksi esimerkki, jolloin sille olisi pitänyt varata riittävästi aikaa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 09, 2019, 17:54:07
Paraikaa on juuri saatettu valmiiksi toinen projekti, jossa meillä on vastaavanlainen asiakas, joka myös huomasi, että kun systeemi toimi tavalla, jota he olivat meiltä tilanneet, että niiden sisäiset prosessit eivät olleetkaan yhteensopivia tämän tilaamansa tuotteen kanssa, joten tilattua tuotetta piti lähteä muuttamaan. Kun uusi muutos oli valmis, ilmaantui uusi ongelma heidän sisäsen järjestelmänsä kanssa ja niin edelleen. Ja tätä kehitystä on jatkunut reilu puolivuotta alunperin allokoidun 2 kuukauden sijaan. Tällä kertaa en tosin itse ole vastannut osista järjestelmässä, jotka ovat edellyttäneet tuota jatkuvaa muuttamista tavalla, jota ei ole oikein voinut automatisoidakaan, mutta ei tämä ole selvästi mitenkään epätavallista, että asiakkaat eivät tiedä alunperin, mitä se on mitä ovat meiltä tilaamassa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - maaliskuu 10, 2019, 01:27:29

Minäkin olen ollut mieluummin tekemässä hyviä projekteja. Yrityksen tarkoituksena puolestaan on tuotta voittoa. Paras osallistumani ohjelmistoprojekti tapahtui kolmekymmentä vuotta sitten. On jäänyt mieleen. Asiakkaan konepajatyyppisen yksikön johto oli kypsyttänyt tuotannonohjausideaansa  puolenkymmentä vuotta ja tiesi mitä halusi. Tämä oli onnistumisen avaintekijä. PC-tekniikka oli kehittynyt tasolle, jossa työasemien verkko oli hyvä alusta järjestelmälle. Kymmenkunta ammattilaista teki järjestelmää vuoden ja tulos oli hyvä. Ohjelmiston tekijäyritys palkitsi projektin osallistujat  vuoden parhaan projektin kunniakirjoilla polkupyörien kera. Vasta pari vuotta sitten kunnan asuintalooni asuttama narkkari pölli pyörän eikä poliisi sitä tietenkään löytänyt. Tietojärjestelmän valmistuttua asiakkaan tuotannonohjausideologian kehittäneellä yksikönvetäjällä alkoholiongelma paheni ja kerran hän sai kymmenen minuuttia aikaa kerätä tavaransa ja poistua yrityksestä lopullisesti.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - kesäkuu 13, 2019, 11:18:49

Teksturissa eräs kätevin ominaisuus on se, kun maalaa tekstiä, sama teksti näkyy muuallakin korostettuna. Näin muuttujien sijainti on helppo bongata, esim aliohjelmia väsätessä.

Nyt on käytössä Geany, mikä on uusi teksturi, Gnome- ympäristössä. Kate:ssa oli tuo kiva piirre, jota kaipaa paljon. Kun muistia koneessa 4G, niin kannattaako KDE-n ohjemistoja asentaa. Tiedä tästäkään. Muuten Geany vaikuttaa ihan ok-teksturilta. Tällaiset työkalut tulisi tietysti tehdä täysin itse.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - kesäkuu 13, 2019, 14:15:26
Lainaus käyttäjältä: Juha - kesäkuu 13, 2019, 11:18:49
Tällaiset työkalut tulisi tietysti tehdä täysin itse.
Teksturikin on sen verran vaativa ohjelma, että muutamaan vapaan koodin ohjelmaan ymmärtämiseen saakka tutustumisessa ja kelvollisen itselleen tekemisessä on aivan mieletön työ.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - kesäkuu 13, 2019, 15:50:50

Tietysti, jos tekee hyvän :))

Aikaa siinä menisi, totta.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - kesäkuu 13, 2019, 16:56:39
Eikös tuo samojen kirjainten/kirjainyhdistelmien korostus ole aika monessa koodieditorissa joko vakiona tai lisäosana asennettavissa?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - kesäkuu 13, 2019, 17:11:29
Lainaus käyttäjältä: Tuottavuusloikka - kesäkuu 13, 2019, 16:56:39Eikös tuo samojen kirjainten/kirjainyhdistelmien korostus ole aika monessa koodieditorissa joko vakiona tai lisäosana asennettavissa?

Äh. Ei valikoista suoraan, joten ei olemassa.

Ok. Toiminto löytyy Geany:ssä, tosin manuaalista. Manuaalit näyttävät hyvältä, ja toiminnallisuuksia näköjään paljon. Hitokseen näköjään panostettu asiaan.

BTW Se seikka, että konfiguraatiotiedostot saa editointiin, ja ne listataan valikossa suoraan otettaviksi, on aika ammattimainen käytäntö minusta.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - kesäkuu 13, 2019, 17:16:33
Mä käytän töissä PhpStormia ja Visual Studio Codea, joista ainakin jälkimmäisessä tuo korostus on vakiona. PhpStormista en muista, että onko vakiona, löytyykö asetuksista vai edellyttäisikö se jonkun lisäpalikan asentamista. Käytän minä notepad++ -ohjelmaakin, mutta enempi muistiinpanoalustana. Siinä korostusta ei tule ainakaan vakiona.
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - kesäkuu 13, 2019, 17:28:22
Lainaus käyttäjältä: Jaska - maaliskuu 10, 2019, 01:27:29Paras osallistumani ohjelmistoprojekti tapahtui kolmekymmentä vuotta sitten.
.. Kymmenkunta ammattilaista teki järjestelmää vuoden ja tulos oli hyvä. Ohjelmiston tekijäyritys palkitsi projektin osallistujat  vuoden parhaan projektin kunniakirjoilla polkupyörien kera. Vasta pari vuotta sitten kunnan asuintalooni asuttama narkkari pölli pyörän eikä poliisi sitä tietenkään löytänyt. Tietojärjestelmän valmistuttua asiakkaan tuotannonohjausideologian kehittäneellä yksikönvetäjällä alkoholiongelma paheni ja kerran hän sai kymmenen minuuttia aikaa kerätä tavaransa ja poistua yrityksestä lopullisesti.

Minkälaisia vaikutuksia oli niillä muilla, epäonnistuneemmilla projekteilla?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - kesäkuu 13, 2019, 18:05:44

Kun hyvä mahdollisuus verrata editoreita, uuteen siirtymisen alussa, niin tuntuma tekemiseen korostuu.

Kun Kate:lla korvaa tekstiä, korvausprosessin päätteeksi ilmoitetaan, kuinka monta korvausta tehtiin. Geanyssä homma tuntuu sujahtavan, muttei tiedä, mitä tarkemmin tapahtui.

Geanyn tapa olla ilmoittamatta, on vähän kuin unix-komennot, oletuksen. rm -rf *, etkä saa mitään ilmoitusta kun asiat kadonneet, jos luvat kunnossa. Toisaalta kiva, mutta kun koodatessa aina epävarmuutta tekemisessä, niin kaikki lisätuntuma on plussaa.

Ehkä varmuus voi näissä kommunikaatiovaje-systeemeissä syntyä, kun aikansa vääntelee, jolloin kaikki ilmoitukset keskeyttävät tärkeämmät.

Joten ...
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - kesäkuu 15, 2019, 21:43:11

Luokkiin perustuva ohjelmointi on selkein, rakentelussa. Varmaan menee vielä aikaa, kun sujuvuus tähän tulee. Sen huomasin, että vaistomaisesti yritin tehdä rakentelusta jotenkin luokkien tapaan toimivia. Sitten ajattelin, että parempi nojautua suoraan PHPn valmiisiin luokkarakennelmiin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Lenny - kesäkuu 16, 2019, 04:47:01
Lainaus käyttäjältä: Vihervasemmisto - kesäkuu 13, 2019, 17:16:33
Mä käytän töissä PhpStormia ja Visual Studio Codea, joista ainakin jälkimmäisessä tuo korostus on vakiona.
Atom ja Visual Studio Code lienevät suosituimmat editorit tällä hetkellä.

Vimillä ja Emacsilla tulee myös aina olemaan oma kannattajakuntansa. Myös silloin kun nämä nykyiset hipsterieditorit ovat jo vaihtuneet uusiin :D

Yhteistä kaikille hyville editoreille on laajennettavuus. Uudet editorit ohjelmoidaan JavaScriptillä, ja jos sieltä ei löytyisi esim. nyt tuota sanojen korostusta, sen voisi tehdä itse aika vaivattomasti.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - kesäkuu 16, 2019, 07:22:49
Lainaus käyttäjältä: Lenny - kesäkuu 16, 2019, 04:47:01
Lainaus käyttäjältä: Vihervasemmisto - kesäkuu 13, 2019, 17:16:33Mä käytän töissä PhpStormia ja Visual Studio Codea, joista ainakin jälkimmäisessä tuo korostus on vakiona.

Atom ja Visual Studio Code lienevät suosituimmat editorit tällä hetkellä.


Miksi nuo puuttuvat, esim debianin ohjelmistolähteistä?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Lenny - kesäkuu 16, 2019, 09:47:51
Lainaus käyttäjältä: Juha - kesäkuu 16, 2019, 07:22:49
Lainaus käyttäjältä: Lenny - kesäkuu 16, 2019, 04:47:01
Lainaus käyttäjältä: Vihervasemmisto - kesäkuu 13, 2019, 17:16:33Mä käytän töissä PhpStormia ja Visual Studio Codea, joista ainakin jälkimmäisessä tuo korostus on vakiona.

Atom ja Visual Studio Code lienevät suosituimmat editorit tällä hetkellä.


Miksi nuo puuttuvat, esim debianin ohjelmistolähteistä?

Hyvä kysymys. Luultavasti lisenssisyistä. Debian on melko tarkka siitä, että lisenssi on kosher open source (mieluiten GPL) ja että käännösprosessi on suoraviivainen. VSC ja Atom ovat molemmat itse asiassa selainpohjaisia, ja niiden asennuksen mukana saattaa tulla ties mitä tauhkaa, varsinkin tuon Microsoftin ohjelmiston (VSC). Tämä vain mutua, en jaksa etsiä selitystä.

Esimerkiksi Emacs sen sijaan on täysin kosher, eli GPL-lisenssi.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - kesäkuu 16, 2019, 10:08:52

Ok.

Eräs vaikuttava (objektiivistyylinen) hahmo näissä tuntus olevan Richard Stallman. Kuulin pätkän sen tarinaa ohjelmistoista, youtubesta.

Ubuntukaan ole ihan niin varma, mitä luullaan, vaikka linux-pohjainen. Samoin Mint. Mintti alkoi näyttää vähän epäselkeältä, joten vaihdoin. Nyt on käytössä Debian ja oliko tässä toisessa jokin Pureos.

Vakaa järjestelmä on hyvä olla, yhtenä. Siihen ei tulisi asentaa epäselvyyksiä. Muut saa olla vaikka räkäisiä, systeemeiltään.

Hyvä kuitenkin, että lisenssit tuovat jotain selkeyttää nettimaailman rakenteluun.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - heinäkuu 14, 2019, 09:16:34

Hippi puhunut ohjelmoinnista, ja projekteista, siis rakentamistavasta, jossa tiedetään tarkasti, mitä halutaan, ja rakennetaan se juttu täsmällisesti.

Kyseessä on eri "marja". Joskus voi käyttää selkeästi top-down-rakentamista, joka oli myös Pensadorin mentelmissä nro1. Bottom-up on tuohon nähden yhtä sählinkiä. Ja sen huomaa. Peruuteluissa ei rajaa, aiemmista. Sama, mitä väsäili.

Eilen Safiirin kanssa jutskasin Luonto-ketjussa energiansäästöstä, ja botttom-up vinkkelistä, siis kapokulmasta lähtien, päädyin hyvin lokaaleihin puitteisiin, ja sen mukaiseen toimintaan, josta ei ihmeitä sovellu, suurempiin ympyröihin.

Rakentelussa samaan törmännyt oman kämpän suhteen. Sen hoksannut, että jos tekee BT-projekteja, tai askareita, niin simppelipalikat rulettaa. On oltava atomaarisia elementtejä, joistä väkertää kompleksisempaa, ja niin, että purku-juttu on varmistettu, eikä kynnyksellinen, hajoitus/rakennus-operaationa.

Ohjelmoinnissa sama, siis kun puhutaan rakentelusta, johon otsikko suoremmin viittaa. Rakentelu yleisemmin on tietysti sitä, mikä pätee ohjelmointiikin, eli jos puhuu rakentamisesta, niin se on yleensä helppo nähdä osana ohjelmointia, siinä missä matematiikka yleensä on tapana liittää esim talouteen, tai moneen tieteeseen.

TD-tyyli on myös erityisen huono, joissain tapauksissa. Yhteiskuntia tyypillisesti rakennetaan TD-tyylillä. Tästä on pitkällistä kokemusta. Jokainen on muka niin hyvä, aiempaan nähden. Sama hankaluus kömpii usein esteeksi, huomaamatta. Sitten sanotaan, että minkäs ihmiselle voi. Tällaisia me ollaan.

Ihminen itse, on rakentamiseen nähden muuta kuin off-topic. Kun puhutaan rakentamisesta, niin vaikuttavin taso löytyy tältä suunnalta. Tässä jotain reunapuitteista, rakenteluun liittyen.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - heinäkuu 14, 2019, 09:26:42
Lainaus käyttäjältä: Lenny - kesäkuu 16, 2019, 09:47:51Debian on melko tarkka siitä, että lisenssi on kosher open source (mieluiten GPL) ja että käännösprosessi on suoraviivainen. VSC ja Atom ovat molemmat itse asiassa selainpohjaisia, ja niiden asennuksen mukana saattaa tulla ties mitä tauhkaa, varsinkin tuon Microsoftin ohjelmiston (VSC). Tämä vain mutua, en jaksa etsiä selitystä.


Juuritason lähestymistapa, siis rakennepainotteisuus on kiva juttu. Tämä näkyy joskus käyttäjäepäystävällisyytenä. On hyvä, että on myös käyttäjäystävällistä, inhimillisiin liittymiin panostamista, jota on tietysti pakko olla, jos kaupallistetaan tavallisempien kuluttajien suuntaan tuotteita, joissa ei tarvitse insinööritaitoja, tai pohja-tason rakenteluosaamiseen liittyviä.

Tieteessä ja tutkimuksessa on selkeä ammatillisuus hyväksyttyä. Sitä suojellaan, ja vaalitaan, jonkin verran, myös tökerösti, jolloin turmeltumista ajatellen, turvaamisen voi nähdä karhunpalveluksena pohjatason laatuedellytyksille.

Kun mennään tietotekniikkaan, niin perustavan tason ammatillisuus on jotain, mitä voidaan kuvata toisella tapaa. On jopa halveksivaa suhtautumista pohjatason rakenteluun. Nörtti on eräs tällaiseen viittaava. Ei kovin ihmisläheinen tapaus, eikä sallittu, tällä alueella. Muilla alueilla meriitti.

Lobotomia on hankala juttu, siis se, että osaamisalueet ovat liian eristyksellisiä, eri toiminta-alustoihin nähden. Kun yleiskulkemista arvostetaan, niin samalla voidaan tallata invalidiksi ne erikoiskärjet, joihin voi järkevästi ottaen rakentaa yleistä.

Yhteiskuntaa ja rakentamista voi arvioida anarkismin vinkkelistä, ilman että ketään selkeää hihhulia olisi hyppelämässä koneistoissa. Anarkismin vahvin muoto löytyy, ilman tällaista hassutusjoukostoa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - heinäkuu 19, 2019, 18:02:45
Lainaus käyttäjältä: Hippi - maaliskuu 09, 2019, 09:00:17
Lainaus käyttäjältä: Tuottavuusloikka - maaliskuu 08, 2019, 22:17:55
Tein puolitoista vuotta sitten asiakkaalle suhteellisen monimutkaisen ajanvarausjärjestelmän, eikä mulla ollut sen valmistuttua silloin eikä vielä nytkään käsitystä, miksi se toimi. Siinä on reilu tuhat riviä koodia, mutta selkeesti niin monimutkaisella tavalla tehty, että en pysty seuraamaan koodia ja sanomaan mitä tapahtuu tarkalleen ottaen missä ja miksi (en tietenkään kommentoinut silloin koodia).

Ai kamala, en kyllä kehtaisi tunnustaa etten ymmärrä omaa koodaustani.

Asiakas halusi, että muutamme jälleen toimintalogiikkaa, koska nyt kun on paljon dataa, järjestelmä on aivan sairaan hidas. Muutenkin vitutti tuo "musta aukko" niin paljon, että kirjoitin juuri koko ajanvarausjärjestelmän uusiksi. Nyt se on yksinkertaisempi ja koodista ottaa nyt selvän. Useampi sata riviä koodia meni aiemmin kalenterien käsittelyyn ja nyt kalenterien toiminta edellyttää ehkä vain noin 100 riviä koodia. Renderöin nyt kaiken datan myös serverillä niin pitkälle valmiiksi kuin mahdollista, jotta javascriptin ei tarvitse juuri muuta tehdä kuin näyttää dataa, eli sain javascriptin for-loopit minimiin. Poistin fullcalendar-ajanvarauskäyttöliittymänä ja korvasin sen jqueryn datepickerillä. Aavistelinkin jo, että ongelmia aiheutti tuo fullcalendar. Tapamme käyttää fullcalendar-komponenttia tässä kohtaa ei ollut optimaalista. Sitä kun ei ole suuniteltu varausten näyttötapaan, jota me tuossa järjestelmässä tuossa kohtaa käytämme. Aiemmin sivun lataus tietyissä tapauksiissa kesti useita sekunteja. Nyt se latautuu käytännössä välittömästi (max 1.5 sek riippuen nettiyhteydestä/selaimesta). Fullcalendar toimii moitteettomasti toisaalla järjestelmässä kun sitä käytetään kyseisen palikan ohjeiden mukaan, joten palikka sinällään ajaa asiansa, mutta tässä tämän tyyppisessä ajanvaraussysteemissä se ei selvästi ollut oikea valinta. (Silloin kun sain järjestelmän vastuulleni, esimieheni ei tykännyt ideasta käyttää tässä kohtaa muita kalenterikomponentteja kuin järjestelmästä jo löytyvää fullcalendar-komponettia, mutta kun joka tapauksessa tarvitsimme myöhemmässä vaiheessa datepickeriä, ja lisäsimme sen järjestelmään, nyt avautui sen käyttöön oiva mahdollisuus).
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - heinäkuu 19, 2019, 19:04:52
Sitten meni pitkä aika sen selvittämiseen, miten saan listan otsikoita klikattaessa aukeamaan niiden alla olevan piilossa olevan tavaran jqueryllä. Silleen geneerisesti, että ei olisi tuo avaussysteemi kiinni siitä kuinka monta tasoa listassa on. Olen sen joskus aiemminki tehnyt toisaalle ja ajatelin, että tämähän on ihan helpppo muutaman sekunnin homma. Varman meni tunti ja tuloksetta. Kun pääsin kotiin, ajattelin käyttää vaikka koko viikonlopun tuon perkeleen selvittämiseen. Jostain syystä kotiin päästyäni homma selvisi ekalla yrittämällä ja nyt ihmettelen jälleen, miksi en ajatellut asiaa näin käytännönläheisesti duunissa. Pitäisi ilmeisesti tauottaa päivä fiksummin niin katsantokanta asioihin lähtisi aina ikään kuin alusta ja osaisi kyseenalaistaa omaa tapaa tuottaa ratkaisuja. Tosin ongelmani on se, että kun tulee eteen pulma, joka ei tahdo mitenkään ratketa, se motivoi niin paljon lisää, että sitä ei malta pitää paussia, vaan sitä mielummin hakkaa päätään seinään.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 07, 2019, 13:54:57
Pitää seuraavaksi selvittää Redux- ja Axios-kirjastojen toiminta Reactin kanssa. Kovinkaan kummoinen projektin ei tarvitse olla, kun tuo Redux tulee jo tarpeeseen. Ei muuta kuin, että jos moduulien hierarkia on syvä, tuo joka moduudille eventtien välittäminen, jotta pohjimmainen voi eventtiä kutsua, vie tarpeettomasti aikaa verrattuna siihen, että keskittää nuo eventit yhteen paikkaan ja tarpeen vaatiessa kutsuu niitä sitten, mistä moduulista tahansa ja homma on sillä selvä. Axios taas tulee siihen, että saa React-yhteensopivasti yhteyden backendiin.

EDIT: Ongelma Axiossissa minun kannaltani on, että javascriptin "lupaukset" ovat minulle vielä toistaiseksi olleet hepreaa. Se mitä niistä yleisesti ymmärrän, on että ne ovat tervetullut ominaisuus, mutta en vain ole saanut aikaiseksi tutustua konseptiin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 08, 2019, 02:04:25
Ehkäpä sitä uskaltaa ottaa käyttöön "lupaukset". Nyt olen tässä hieman kokeillut ja ikään kuin ne osaisivat odottaa siihen asti kun iteraatiot ovat valmiita.

Tuo on ollut javascriptissä ongelmana, että jos pitää käydä paljon dataa läpi, niin miten estää tiettyjen koodin osien toteutumisen ennen kuin tuo data on käyty läpi. Ratkaisut eivät ole olleet aina erityisen helppoja toteuttaa puhumattakaan kauniita.

Lupaukset vaikuttaisivat pikaisella testillä ratkaisevan tämän pulman. Olen luullut, että lupauksia voisi käyttää vain rajatuissa tapauksissa, mutta ilmeisesti niitä voi todella käyttää ihen jo iteraatioiden valmistumisen odottamisesta lähtien, mikä olisi kyllä aivan saatanan hyvä ominaisuus, jos todellakin näin on. Tulee heti mieleen useita projekteja, joissa eteen tulleet suurimmat pulmat olisivat ratkeneet käyttämällä lupauksia.

Tosin ongelmaksi voi mudostua se, että asiakkailla voi olla käytössään vanhoja selaimia, jotka eivät tue lupauksia. Pitää selvittää, mikä on tilanne. Lupaukset on tosin otettu käyttöön vuonna 2015 (linkki (https://medium.com/free-code-camp/es5-to-esnext-heres-every-feature-added-to-javascript-since-2015-d0c255e13c6e)), samoin kuin näyttäisi olevan map-funktiokin, ja sikäli kun olen tuota map-funktiota surutta käyttänyt jo kaksi vuotta, eikä asiakkaat ole ilmoittaneet siihen liittyvistä ongelmista, ilmeisesti lupauksiakin voisi alkaa turvallisesti käyttämään myös.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - joulukuu 08, 2019, 02:57:06
^ Ihan munkkilatinaa itselleni mutta erittäin eksoottista ja jännittävää luettavaa. :)
Sokkona googlasin avainsanoilla tällaista, ymmärtämättä mistä on kyse:

With any of the following Polyfills, you'll be able to use the Promise API in any old webbrowser in the same way you do with new browsers. (https://ourcodeworld.com/articles/read/316/top-5-best-javascript-promises-polyfills)

Liittyikö pohdintoihisi mitenkään?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 08, 2019, 03:17:58
Lainaus käyttäjältä: a4 - joulukuu 08, 2019, 02:57:06
^ Ihan munkkilatinaa itselleni mutta erittäin eksoottista ja jännittävää luettavaa. :)
Sokkona googlasin avainsanoilla tällaista, ymmärtämättä mistä on kyse:

With any of the following Polyfills, you'll be able to use the Promise API in any old webbrowser in the same way you do with new browsers. (https://ourcodeworld.com/articles/read/316/top-5-best-javascript-promises-polyfills)

Liittyikö pohdintoihisi mitenkään?

Joo kiitos ja kyllä valitettavasti liityy. Olen tyypillisesti käyttänyt babel-nimistä polyfill-kirjastoa, joka kääntää kaikki uusimmat javascript-toteutukset (ei pelkästään lupauksia) vanhojen selainten kanssa yhteensopivaksi javascriptiksi, mutta näiden polyfill-kirjastojen käyttö edellyttää hieman enemmän säätöä, kuin jos voisi kirjoittaa koodia ilman niitä. Ongelma on useimmissa tapauksissa lähinnä vain kosmeettinen, mutta kiusa se on pienikin kiusa, joka näiden eri kääntäjien mukaan ottamisesta aiheutuu.

Tuolla fiilikset ketjussa kerroin yhdestä tilanteesta, joka tuli vastaan kun käytössä olevat kirjastot eivät lopulta sitten kutenkaan ole yhteensopivia vaikka "käyttöohjeissa" niin luvataankin, ja korjausta on vaikea lähteä tekemään kun koodi, johon ohjelma nojaa, ei ole omaa. Tämä on yksi keskeisimmistä syistä, miksi välttelemme duunissa asiakasprojekteissa ylimääräisiä kirjastoja ja näemme itse sen vuoksi hieman enemmän vaivaa, kuin että ottaisimme käyttöön jonkun valmiin komponentin. Joskus tulevaisuudessa saatamme nimittäin tulla tilanteeseen, että käyttämämme kirjastot eivät mahdollista softan laajentamista haluttuun suuntaan ja jokin pienikin muutos kyseiseen suuntaan voi edellyttää taustalla toimivan koodin uudelleenkirjoitttamista varsin radikaalilla tavalla, johon emme halua lähteä. Itselläni kun on tapana edelleen kirjoittaa myös paljon tarpeetontakin koodia ja senkin parseroinnissa on joskus ihan riitämiin päänvaivaa ilman ulkopuolisten kirjastojen mukaan mahdollisesti tuomista ongelmista huolimatta :)
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - joulukuu 08, 2019, 13:13:17
Maallikkona kysyn tyhmiä: Onko perusongelmana käyttöympäristön eli kaiketi netin nopea kehitystahti ja siitä seurannut monimuotoisuus selaintenkin osalta? Vaatisiko jonkinlaista betatestausviritystä?

Pelipuolella ainakin kova julkaisutahti ja sutki markkinointi kaiketi pakottaa julkaisemaan etenkin nettimoninpelejä beta-ja alfatestien avulla ja silti usein paikkaustiedostoja tarvitsevina tuotteina. Nyt myös somekanavat on valjastettu mukaan jatkuvaan ja sitouttavaan mainostus-, mikromaksu-, tuki-ja palautekäyttöön pelikohtaisesti pelaajayhteisöilleen.
Sosiaalisuus on kovaa valuuttaa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 08, 2019, 14:34:43
Lainaus käyttäjältä: a4 - joulukuu 08, 2019, 13:13:17
Maallikkona kysyn tyhmiä: Onko perusongelmana käyttöympäristön eli kaiketi netin nopea kehitystahti ja siitä seurannut monimuotoisuus selaintenkin osalta? Vaatisiko jonkinlaista betatestausviritystä?

Pelipuolella ainakin kova julkaisutahti ja sutki markkinointi kaiketi pakottaa julkaisemaan etenkin nettimoninpelejä beta-ja alfatestien avulla ja silti usein paikkaustiedostoja tarvitsevina tuotteina. Nyt myös somekanavat on valjastettu mukaan jatkuvaan ja sitouttavaan mainostus-, mikromaksu-, tuki-ja palautekäyttöön pelikohtaisesti pelaajayhteisöilleen.
Sosiaalisuus on kovaa valuuttaa.


Ongelma, jota pyrimme välttelemään ovat nuo lisäpalikat.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 24, 2020, 22:40:00
Haluaisin tehdä asiakkaalle lisäosan softaan, millä he voisivat rakentaa itselleen mieleisensä www-lomakkeen. Heillä on järjestelmä, jossa tällaiselle olisi aika-ajoin tarvetta. Ei kuitenkaan onnistu pikkunäpertelynä. Alustoja, joissa nettisivun sisällön paikat ja ulkoasun saa itse päättää, myydään ymmärtääkseni isolla rahalla nettisivujen tekoon, kuten https://www.wix.com/
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - tammikuu 24, 2020, 23:00:35
^  Ei taida auttaa?

https://zapier.com/learn/forms-surveys/best-online-form-builder-software/

Google Forms esim. vaatinee, että datat tallennetaan Googleen, ei vapaavalintaiseen paikkaan. Kuulee huhuja, että se hukkaisi dataa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 24, 2020, 23:31:21
Joo kiitos. Pitäisi siis kaiketi rakentaa tuollainen. Varmaan pitäisi tarkastella noita javascript-kirjastoja. Esimerkiksi jollekin React-kirjastolle voisi löytyä käyttöä. Niitä kun voi muokata tarpeen mukaan. Lomakkeiden pitää olla nimittäin tietyntyyppisiä sen lisäksi ettei olla suunnittelemassa tätä varten tietokannan siirtämistä AWS:ltä esimerkiksi Googlelle. En usko, että valmiita palikoita löytyy.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - tammikuu 25, 2020, 13:32:44
Semmoinen kuin CSS Grid (https://www.w3schools.com/css/css_grid.asp) tuli vielä mieleeni, kun se mahdollistaa webbisivun elementtien järjestämisen helposti ja vieläpä ikkunan kokoon mukautuvalla tavalla. Mikä voi ehkä tehdä ennalta määrätymättömän määrän elementtejä sommitelusta helpompaa. En tiedä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - maaliskuu 04, 2020, 20:59:29
Ehkä tää sopis tänne. Oon vaan tätä miettinyt, kun kirjoittaessani tälle palstalle aika usein klikkaan "Esikatselu." Sivun javascript -koodeissa (ks. mm. otteet alla) ei taida olla BBCode -tulkkia, joka esikatselun generoisi? Sen sijaan BBCoden kääntänee html:ksi Kantiksen palvelimen PHP -koodi. Mikä tuntuu vähän haaskaukselta palvelimen resurssien kannalta. (Ja mikä on joskus hidastakin, vaikkei siitä haittaa olekaan.)

function previewPost()
{
if (window.XMLHttpRequest)
{
// Opera didn't support setRequestHeader() before 8.01.
if ('opera' in window)
{
var test = new XMLHttpRequest();
if (!('setRequestHeader' in test))
return submitThisOnce(document.forms.postmodify);
}
// !!! Currently not sending poll options and option checkboxes.
var x = new Array();
var textFields = ['subject', 'message', 'icon', 'guestname', 'email', 'evtitle', 'question', 'topic', 'f775bb74a'];
var numericFields = [
'board', 'topic', 'last_msg',
'eventid', 'calendar', 'year', 'month', 'day',
'poll_max_votes', 'poll_expire', 'poll_change_vote', 'poll_hide'
];
var checkboxFields = [
'ns'
];

for (var i = 0, n = textFields.length; i < n; i++)
if (textFields[i] in document.forms.postmodify)
{
// Handle the WYSIWYG editor.
if (textFields[i] == 'message' && 'oEditorHandle_message' in window && oEditorHandle_message.bRichTextEnabled)
x[x.length] = 'message_mode=1&' + textFields[i] + '=' + oEditorHandle_message.getText(false).replace(/&#/g, '&#38;#').php_to8bit().php_urlencode();
else
x[x.length] = textFields[i] + '=' + document.forms.postmodify[textFields[i]].value.replace(/&#/g, '&#38;#').php_to8bit().php_urlencode();
}
for (var i = 0, n = numericFields.length; i < n; i++)
if (numericFields[i] in document.forms.postmodify && 'value' in document.forms.postmodify[numericFields[i]])
x[x.length] = numericFields[i] + '=' + parseInt(document.forms.postmodify.elements[numericFields[i]].value);
for (var i = 0, n = checkboxFields.length; i < n; i++)
if (checkboxFields[i] in document.forms.postmodify && document.forms.postmodify.elements[checkboxFields[i]].checked)
x[x.length] = checkboxFields[i] + '=' + document.forms.postmodify.elements[checkboxFields[i]].value;

sendXMLDocument(smf_prepareScriptUrl(smf_scripturl) + 'action=post2' + (current_board ? ';board=' + current_board : '') + (make_poll ? ';poll' : '') + ';preview;xml', x.join('&'), onDocSent);

document.getElementById('preview_section').style.display = '';
setInnerHTML(document.getElementById('preview_subject'), txt_preview_title);
setInnerHTML(document.getElementById('preview_body'), txt_preview_fetch);

return false;
}
else
return submitThisOnce(document.forms.postmodify);
}


En saa oikein selvää, miten esikatselun luonti ihan tarkkaan ottaen tapahtuu. Jonkin verran relevantteja koodeja on myös täällä (https://kantapaikka.net/Themes/default/scripts/script.js?fin20), mutta en löydä mitään avainkohtaa.

Mietin, että oisko Kantista teoriassa mahdollista toteuttaa "yhden sivun sovelluksina" niin että BBCoden tulkkaus tapautuisi selaimessa? Mikä sen estäisi? En ole pro. Jonkun tyhmän kurssin käynyt muutama vuosi sitten.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 05, 2020, 14:21:57
Tein tänään PHP:llä rajapinnan. Huomenna pitää testata Postmanilla toimiiko kaikki endpointit. Sitten olisi vuorossa autentikointi ja viimeiseksi, mutta ei vähäisimmäksi frontend. Haluaisin käyttää frontendin kirjastona reactia, mutta todennäköisesti päädyn jquery-ratkaisuun.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 15:25:09
^piti sitten kuitenkin lisätä vielä muutama endpointti rajapintaan, että ei tässä vielä kummoisiakaan testejä päässyt suorittamaan. Itse asiassa vieläkin pitää tehdä ainakin kappale endpointteja, joka ei ole täysin ongelmaton, sillä sen pitäisi tehdä niin paljon eri asioita ja ehdollisesti.

Tässä on välissä sopivasti viikonloppu, että saa ongelma muhia alitajunnassa pari päivää. Ehkäpä ratkaisu syntyy maanantaina tuoreilla aivoilla nopeastikin. on tässä ollut pari päivää niin kiinni projektissa, että lyhyenkin etäisyyden otto on varmasti paikallaan.

Pitää muuten myös muistaa jossain välissä dokumentoida tää rajapinta, että on sitten joku tietolähde kuinka systeemi toimii. Sinällään tää on kyllä hirmu simppeli rajapinta mutta ei auta. Kun aikaa kuluu kuukausi tai kaksi sitä ei muista itsekään, miten homman on tehnyt ja silloin ohjeet ovat arvokkaita.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - maaliskuu 06, 2020, 15:45:17
^ Tuossa oli pari hyvää yleispätevämpääkin niksiä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 15:51:52
^Opin hiljattain aivan fantastisen uuden niksin.

Kun kirjoittaa esimerkiksi luokkia, niissä voi olla sellaisia ominaisuuksia, joita voisi käyttää uudestaan, mutta kun niissä on usein sellaista koodia mukana, joka on projekti- tai toimintokohtaista, jolloin niitä ei voi käyttää sellaisenaan uudestaan. Tähän pulmaan opin, että lähettää callbackeja kyseisten luokkien metodeille, jotka voi toteuttaa kyseisten luokkien ulkopuolella. Eli näin voi kirjoittaa mahdollisimman geneeristä koodia ainakin joihinkin luokkiin ja silloin kun niiden proseduurit olisivat käytettävissä muuallakin.

Tässä on siis selkeät hyötynsä (olen jo toisessa projektissa käyttänyt tätä tapaa), mutta myös haittansa.

Noista haitoista sen verran, että esimerkiksi tässä rajapintahommelissa, jota olen värkännyt, olisi muutama paikka, jossa voisin vähentää koodin määrää huomattavasti yllä kuvaamallani tavalla. Kokemuksesta kutenkin tiedän, että koodin luettavuus kärsii myös, jos sitä abstrahoi liikaa esim. juuri tällaisella kikkailulla. Eli olen hieman kahden paikkeilla, lähteäkö abstrahoimaan luokkieni metodeita vai jätänkö ne tällaisiksi.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 16:04:07
class Dog {
    function talk() {
        print('Dog say wuf!');
    }
}
$dog = new Dog();
$dog->talk(); // Dog say wuf!


Tuota ei voi käyttää nyt kuin koiran tapauksessa, mutta pienellä abstrahoillilla tuota saadaan käytettyä kaikissa tapauksissa, joissa entiteetin pitäisi puhua:

class Mammal {
    function talk($func) {
        $func();
    }
}
$dogTalk = function() {
    print('Dog say wuf!');
}
$catTalk = function() {
    print('Cat say meow!');
}
$dog = new Mammal();
$dog->talk($dogTalk); // Dog say wuf!
$cat = new Mammal();
$cat->talk($catTalk); // Cat say meow!
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - maaliskuu 06, 2020, 16:41:21
Täällä  (https://itewbm.tistory.com/entry/Strategy-Pattern-Head-First-Design-Patterns)puhutaan semmoisesta kuin Strategy pattern. Olen lukenut ton kirjan, mutta siitä on liian kauna, että osaisin mitään selittää.   :-[  Tää on vissiin raskaampi ratkaisu kuin sun käyttämäsi, EK Möhkäle?


(https://t1.daumcdn.net/cfile/tistory/126539144B96D2F52A)

Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - maaliskuu 06, 2020, 17:11:23
Onko sinulla tai teillä ammattikoodareilla koskaan ollut tällaista työprojektia? (videon alussa): https://kantapaikka.net/index.php/topic,54.msg53990.html#msg53990
Trailerissa ei näy kuinka kaveri saa hetken monitoria tuijotettuaan totaalisen paskahalvauksen.
Kyseessä on jonkinlainen tiimin sisäinen open source-koodaus.
Ehkä hän vain tajusi koodaavansa republikaaneille algoritmia vaalivoittoon.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 17:15:53
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 06, 2020, 16:41:21
Täällä  (https://itewbm.tistory.com/entry/Strategy-Pattern-Head-First-Design-Patterns)puhutaan semmoisesta kuin Strategy pattern. Olen lukenut ton kirjan, mutta siitä on liian kauna, että osaisin mitään selittää.   :-[  Tää on vissiin raskaampi ratkaisu kuin sun käyttämäsi, EK Möhkäle?


(https://t1.daumcdn.net/cfile/tistory/126539144B96D2F52A)

Laitoit erinomaisen linkin. Samasta asiasta tässä on kyse. Tai jos hiusta mennään halkomaan - ja miksemme menisi - niin siinä missä sun esimerkki sopii kaikkiin tilanteisiin, kuten esimerkiksi myös siihen, että kirjoittaa koko luokkametodin uusiksi, tuo mun niksi kirjoittaa vain pienen osan metodia uusiksi. tai sama asia sekin tietysti on silla kyse on siitä että abstrahoidun koodin tai sen osan toteuttaa yksilöllisesti luokan ulkopuolella. Eli ei tämä mun niksi sinällään mikään järjetön oppi ollut, mutta kun ei ole vuosiin tarvinnut juuri muuta kuin proseduraalista koodia, oliohjelmoinnin design patternit tuppaavat unohtumaan.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 17:19:25
^voisin kuvitella, että oliohjelmoijille asia tulee selkärangasta, mutta itselläni on tullut liian harvoin tilanteita vastaan, joissa voisin hyödyntää jo kirjoittamaani koodia. Viimeaikoina kun työnkuva on muuttunut enempi saman asian toteuttamiseksi hieman erilaisilla variaatioilla, asia on alkanut taas koskettaa koodiani.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Lenny - maaliskuu 06, 2020, 17:29:59
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 04, 2020, 20:59:29
Mietin, että oisko Kantista teoriassa mahdollista toteuttaa "yhden sivun sovelluksina" niin että BBCoden tulkkaus tapautuisi selaimessa? Mikä sen estäisi? En ole pro. Jonkun tyhmän kurssin käynyt muutama vuosi sitten.

Oma kysymyksensä on myös että miten tällainen foorumi voisi toimia yhden sivun sovelluksena. Vähän kuten Facebook vai?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 17:32:26
Lainaus käyttäjältä: a4 - maaliskuu 06, 2020, 17:11:23
Onko sinulla tai teillä ammattikoodareilla koskaan ollut tällaista työprojektia? (videon alussa): https://kantapaikka.net/index.php/topic,54.msg53990.html#msg53990
Trailerissa ei näy kuinka kaveri saa hetken monitoria tuijotettuaan totaalisen paskahalvauksen.
Kyseessä on jonkinlainen tiimin sisäinen open source-koodaus.
Ehkä hän vain tajusi koodaavansa republikaaneille algoritmia vaalivoittoon.

Ei ihan mutta melkein. Tai kärjistäen tuollaista se käytännössä on kun ryhtyy kehittämään jonkun toisten kirjoittamaa koodia varsinkin ilman dokumentaatiota. Ei aina, mutta ohjelmiston koon kasvaessa ja seikkaperäisen dokumentaation puuttuessa varsin normaalia. Ainakin meidän firmassa. Vaikka saan projekteihin kolleegoiltani paljon enemmän ohjeita, kuin vain että: "you figure it out", koodi on varsinkin meidän vanhemmissa järjestelmissä (jotka eivät käytä nykyaikaisia hyvin dokumentoituja kirjastoja) aluksi aika usein "matrixia", ja aika lailla ollaan tyhjän päällä kun pitää selvittää - mahdollisesti rivi kerrallaan - kuinka jokin järjestelmän käyttötapaus etenee koodissa alusta loppuun asti.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - maaliskuu 06, 2020, 17:58:40
Häiriköin vielä ummikkona sen verran tätä ketjua että kysyn, perustuen elokuvasta omaksumaani faktaan jossa sodan aikaisessa kuunteluasemassa opittiin tunnistamaan vihollisen morsettajat heidän "käsialastaan" eli tavastaan morsettaa, jotta kehittyykö koodareille yksilöllinen koodaustyyli, oma tunnistettava "käsiala"?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 18:10:28
Lainaus käyttäjältä: Lenny - maaliskuu 06, 2020, 17:29:59
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 04, 2020, 20:59:29
Mietin, että oisko Kantista teoriassa mahdollista toteuttaa "yhden sivun sovelluksina" niin että BBCoden tulkkaus tapautuisi selaimessa? Mikä sen estäisi? En ole pro. Jonkun tyhmän kurssin käynyt muutama vuosi sitten.

Oma kysymyksensä on myös että miten tällainen foorumi voisi toimia yhden sivun sovelluksena. Vähän kuten Facebook vai?

Tuon tyyppisestä konversiosta olisi varmaankin kyse? Ja tämän järjestelmän php-alusta ei kaiketi suoraan tue tuollaista vaihtoehtoa? Vai tarjoaako Simple Machinesin backend esim. json-rajapinnan?

Erona siis se, että siinä missä nykyisellään serveri palauttaa jokaisen kutsun yhteydessä jokaisen sivun kaiketi valmiina html-koodeina, yhden sivun aplikaatiossa serveri palauttaisi ensiksi yhden valmiin mutta geneerisen html-sivun ja sen jälkeen geneerisen sivun javascript tilaa serveriltä päivittämättä sivua esim. json-muotoisen paketin dataa, jonka perusteella geneerisen sivun html muokataan javascriptillä sen näköiseksi, kuin pitää.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 18:16:28
Lainaus käyttäjältä: a4 - maaliskuu 06, 2020, 17:58:40
Häiriköin vielä ummikkona sen verran tätä ketjua että kysyn, perustuen elokuvasta omaksumaani faktaan jossa sodan aikaisessa kuunteluasemassa opittiin tunnistamaan vihollisen morsettajat heidän "käsialastaan" eli tavastaan morsettaa, jotta kehittyykö koodareille yksilöllinen koodaustyyli, oma tunnistettava "käsiala"?

En tietysti tiedä mutta uskoakseni kyllä. Itse koodi on kaikilla koodareilla identtistä. Tai oikeammin, kielestä riippuen on vain yksi tai ehkä vain muutama tapa kirjoittaa jokin komento. Siinä uskoakseni kuitenkin jo tulee "persoona" näkyviin, millaisilla komentojen "ryppäillä" tietyn tyyppiset keskenään samankaltaiset ongelmat yleensä ratkaisee eri projekteissa. Ongelmat voi ratkoa joko yksittäisellä komennolla tai sitten useamman komennon "ryppäillä" ja noita komentojen "ryppäitä", joilla voidaan ratkoa käytännössä mikä tahansa matemaattisesti ratkaistava ongelma, voi olla yhtä monta kuin on koodareitakin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 18:38:17
^tietysti ohjelmoinnissa pyritään usein noudattamaan erilaisia hyväksi havaittuja yleisiä käytäntöjä kuten olio-ohjelmointia ja siinäkin design patterneja, jotka minimoivat turhan persoonallisuuden. Mutta koska yleiset käytännöt eivät aina ratkaise spesifejä ongelmia, koodareiden koodit eivät voi aina olla kuin korkeintaan yleisellä tasolla keskenään identtisiä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - maaliskuu 06, 2020, 18:52:43
Lainaus käyttäjältä: a4 - maaliskuu 06, 2020, 17:58:40
Häiriköin vielä ummikkona sen verran tätä ketjua että kysyn, perustuen elokuvasta omaksumaani faktaan jossa sodan aikaisessa kuunteluasemassa opittiin tunnistamaan vihollisen morsettajat heidän "käsialastaan" eli tavastaan morsettaa, jotta kehittyykö koodareille yksilöllinen koodaustyyli, oma tunnistettava "käsiala"?

Wanhaan Hywään Aikaan esimerkiksi meillä käytetty Cobol mahdollisti hyvinkin erilaisen käsalan. Omasta porukastani, jota vuosien mittaaon oli melkoisen paljonkin, tunnistin hyvin monen tekijän käsialan.

Pahimmissa tapauksissa ns. tippaleipäaivoinen koodari oli tehnyt ohjelman, joka muistutti risukasaa. Logiikkaa ja jästentelyä siitä ei tahtonut löytää, mutta jotenkin se vain toimi. Jos siinä oli virhe, joka olisi pitänyt löytää ja korjata, ja korjata vielä niin, että mikään muu ei mennyt rikki, oli tosiaan haasteellista, kuten nykyään sanotaan :D

Tunnistettavia juttuja oli mm. tapa jäsennellä ohjema,  kommentointi ja sen laatu, muuttujien nimeäminen ja sen järkevyys ja sekin, miten käytti isoja tai pieniä kirjaimia koodissa. Cobolissa ne on samanarvoisia.

Kun meiltä sitten ulkoistettiin tekninen toteutus, niin palvelufirma sitten yhdenmukaisti tuota käsialaa melkoisesti eikä aina kovin hyvään suuntaan mielestäni.

Näistä moderneimmista kielistä minulla ei ole kokemusta, joten niistä en osaa kyllä sanoa mitään.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 20:24:21
Lainaus käyttäjältä: Eläimen kokoinen möhkäle - maaliskuu 06, 2020, 18:10:28
Lainaus käyttäjältä: Lenny - maaliskuu 06, 2020, 17:29:59
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 04, 2020, 20:59:29
Mietin, että oisko Kantista teoriassa mahdollista toteuttaa "yhden sivun sovelluksina" niin että BBCoden tulkkaus tapautuisi selaimessa? Mikä sen estäisi? En ole pro. Jonkun tyhmän kurssin käynyt muutama vuosi sitten.

Oma kysymyksensä on myös että miten tällainen foorumi voisi toimia yhden sivun sovelluksena. Vähän kuten Facebook vai?

Tuon tyyppisestä konversiosta olisi varmaankin kyse? Ja tämän järjestelmän php-alusta ei kaiketi suoraan tue tuollaista vaihtoehtoa? Vai tarjoaako Simple Machinesin backend esim. json-rajapinnan?

Erona siis se, että siinä missä nykyisellään serveri palauttaa jokaisen kutsun yhteydessä jokaisen sivun kaiketi valmiina html-koodeina, yhden sivun aplikaatiossa serveri palauttaisi ensiksi yhden valmiin mutta geneerisen html-sivun ja sen jälkeen geneerisen sivun javascript tilaa serveriltä päivittämättä sivua esim. json-muotoisen paketin dataa, jonka perusteella geneerisen sivun html muokataan javascriptillä sen näköiseksi, kuin pitää.

Paitsi, että kaiketi javascriptillä voisi tilata tämän valmiin html-sivunkin serveriltä ja korvata sivun olemassaoleva html sillä, jolloin kyseessä olisi tavallaan myös yhden sivun applikaatio. Vaikea tosian sanoa, mitä sillä tässä tapauksessa voitettaisiin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - maaliskuu 06, 2020, 21:24:47
Lainaus käyttäjältä: Eläimen kokoinen möhkäle - maaliskuu 06, 2020, 18:10:28
Lainaus käyttäjältä: Lenny - maaliskuu 06, 2020, 17:29:59
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 04, 2020, 20:59:29
Mietin, että oisko Kantista teoriassa mahdollista toteuttaa "yhden sivun sovelluksina" niin että BBCoden tulkkaus tapautuisi selaimessa? Mikä sen estäisi? En ole pro. Jonkun tyhmän kurssin käynyt muutama vuosi sitten.

Oma kysymyksensä on myös että miten tällainen foorumi voisi toimia yhden sivun sovelluksena. Vähän kuten Facebook vai?

Tuon tyyppisestä konversiosta olisi varmaankin kyse? Ja tämän järjestelmän php-alusta ei kaiketi suoraan tue tuollaista vaihtoehtoa? Vai tarjoaako Simple Machinesin backend esim. json-rajapinnan?

Erona siis se, että siinä missä nykyisellään serveri palauttaa jokaisen kutsun yhteydessä jokaisen sivun kaiketi valmiina html-koodeina, yhden sivun aplikaatiossa serveri palauttaisi ensiksi yhden valmiin mutta geneerisen html-sivun ja sen jälkeen geneerisen sivun javascript tilaa serveriltä päivittämättä sivua esim. json-muotoisen paketin dataa, jonka perusteella geneerisen sivun html muokataan javascriptillä sen näköiseksi, kuin pitää.

Joo, jotain tällaista. html -sivu joltain http -palvelimelta ja sit json'eita rest (https://fi.wikipedia.org/wiki/REST) -apilta. Mä en oikein käytä enää Facbeookia, niin en osaa siihen ottaa kantaa. Ei siinä tarvis olla mitään tapahtumavirtaa. Se vois mahdollisesti olla jopa aika lailla saman näköinen kuin nykyinen Kantis. Vissiin vois olla vaan yks elementti, jonka sisältöä päivitettäis aina klikkausten perusteella. Tai sit osa elementeistä piilossa tai jotain, en tiedä.

Jonkun ihmeen kautta löysin jonkun vanhan selainohjelmoinnin nettikurssin. Sielläkin näköjään tehtiin chatteja, niin kuin tää (http://web-selainohjelmointi.github.io/#vk-2-t16) tai tää (http://web-selainohjelmointi.github.io/#vk-5-t36). Keskustelupalstalla json'iin pitäis kai sit pakata BBCodea. Ja lisäksi pitäisi pitäisi selaimessa pyöriä kääntäjän, joka aina pyydettäessä kääntäisi BBCodet html:ksi. En osais ite tehdä tällaista. Kuvat esim. yksi ratkaisematon ongelma, että tulisko jotain cross-site -ongelmaa, jos sivulle ladattaisi kuvia eri lähteestä kuin mistä sivu itse on tullut. En tiedä, kun ei oo käytännön kokemusta.  :(
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 21:50:42
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 06, 2020, 21:24:47
Lainaus käyttäjältä: Eläimen kokoinen möhkäle - maaliskuu 06, 2020, 18:10:28
Lainaus käyttäjältä: Lenny - maaliskuu 06, 2020, 17:29:59
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 04, 2020, 20:59:29
Mietin, että oisko Kantista teoriassa mahdollista toteuttaa "yhden sivun sovelluksina" niin että BBCoden tulkkaus tapautuisi selaimessa? Mikä sen estäisi? En ole pro. Jonkun tyhmän kurssin käynyt muutama vuosi sitten.

Oma kysymyksensä on myös että miten tällainen foorumi voisi toimia yhden sivun sovelluksena. Vähän kuten Facebook vai?

Tuon tyyppisestä konversiosta olisi varmaankin kyse? Ja tämän järjestelmän php-alusta ei kaiketi suoraan tue tuollaista vaihtoehtoa? Vai tarjoaako Simple Machinesin backend esim. json-rajapinnan?

Erona siis se, että siinä missä nykyisellään serveri palauttaa jokaisen kutsun yhteydessä jokaisen sivun kaiketi valmiina html-koodeina, yhden sivun aplikaatiossa serveri palauttaisi ensiksi yhden valmiin mutta geneerisen html-sivun ja sen jälkeen geneerisen sivun javascript tilaa serveriltä päivittämättä sivua esim. json-muotoisen paketin dataa, jonka perusteella geneerisen sivun html muokataan javascriptillä sen näköiseksi, kuin pitää.

Joo, jotain tällaista. html -sivu joltain http -palvelimelta ja sit json'eita rest (https://fi.wikipedia.org/wiki/REST) -apilta. Mä en oikein käytä enää Facbeookia, niin en osaa siihen ottaa kantaa. Ei siinä tarvis olla mitään tapahtumavirtaa. Se vois mahdollisesti olla jopa aika lailla saman näköinen kuin nykyinen Kantis. Vissiin vois olla vaan yks elementti, jonka sisältöä päivitettäis aina klikkausten perusteella. Tai sit osa elementeistä piilossa tai jotain, en tiedä.

Jonkun ihmeen kautta löysin jonkun vanhan selainohjelmoinnin nettikurssin. Sielläkin näköjään tehtiin chatteja, niin kuin tää (http://web-selainohjelmointi.github.io/#vk-2-t16) tai tää (http://web-selainohjelmointi.github.io/#vk-5-t36). Keskustelupalstalla json'iin pitäis kai sit pakata BBCodea. Ja lisäksi pitäisi pitäisi selaimessa pyöriä kääntäjän, joka aina pyydettäessä kääntäisi BBCodet html:ksi. En osais ite tehdä tällaista. Kuvat esim. yksi ratkaisematon ongelma, että tulisko jotain cross-site -ongelmaa, jos sivulle ladattaisi kuvia eri lähteestä kuin mistä sivu itse on tullut. En tiedä, kun ei oo käytännön kokemusta.  :(

Juu, ei tuo yhden sivun applikaation formaatti tosiaan edellytä mitään reaaliaikaista feediä serveriltä selaimeen, vaan kaikki voisi toimia käyttäjäkokemuksena kuten nytkin, sitä lukuunottamatta, että sivut eivät vain joka napin painalluksena latautuisi uudestaan, vaan vain sen sisältö. Samalla luulisin, että BBC-koodin voisi varmasti lähettää backendille, joka sen kääntää ja joka palauttaa sen html-koodina olettaen, että php-kääntäjä on riittävä. Tai miksei BBC-koodia voisi kääntää myös selaimessa. Noita javascript-kirjastoja tuohon tarkoitukseen kun joka tapauksessa löytyy interwebistä. Nopealla haulla löysin ainakin yhden (https://www.npmjs.com/package/js-bbcode-parser) (joskaan en tiedä kuinka kattava tuo on).

Javascriptissä on valmis funktio (muistaakseni JSON.stringify('xxx')) joka muuttaa kaiken tekstin BBC-koodilla taikka ilman tekstiksi, jonka voi lähettää serverille ja jonka palauttaman json-tekstin voi palauttaa takaisin esim. BBC-koodiksi jos se sitä palauttaa tai missä muodossa tahansa se tekstin palauttaakin käyttäen JSON.parse('yyy') -funktiota. Tai no yleensä tuo teksti, jota tuo funktiopari ymmärtää pitää olla objektissa tai listassa. Mutta joka tapauksessa tuo tekstin tai koodin lähettely selaimen ja serverin välillä on varsin simppeliä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - maaliskuu 06, 2020, 23:13:31
Lainaus käyttäjältä: Eläimen kokoinen möhkäle - maaliskuu 06, 2020, 21:50:42
Juu, ei tuo yhden sivun applikaation formaatti tosiaan edellytä mitään reaaliaikaista feediä serveriltä selaimeen, vaan kaikki voisi toimia käyttäjäkokemuksena kuten nytkin, sitä lukuunottamatta, että sivut eivät vain joka napin painalluksena latautuisi uudestaan, vaan vain sen sisältö. Samalla luulisin, että BBC-koodin voisi varmasti lähettää backendille, joka sen kääntää ja joka palauttaa sen html-koodina olettaen, että php-kääntäjä on riittävä. Tai miksei BBC-koodia voisi kääntää myös selaimessa. Noita javascript-kirjastoja tuohon tarkoitukseen kun joka tapauksessa löytyy interwebistä. Nopealla haulla löysin ainakin yhden (https://www.npmjs.com/package/js-bbcode-parser) (joskaan en tiedä kuinka kattava tuo on).

Javascriptissä on valmis funktio (muistaakseni JSON.stringify('xxx')) joka muuttaa kaiken tekstin BBC-koodilla taikka ilman tekstiksi, jonka voi lähettää serverille ja jonka palauttaman json-tekstin voi palauttaa takaisin esim. BBC-koodiksi jos se sitä palauttaa tai missä muodossa tahansa se tekstin palauttaakin käyttäen JSON.parse('yyy') -funktiota. Tai no yleensä tuo teksti, jota tuo funktiopari ymmärtää pitää olla objektissa tai listassa. Mutta joka tapauksessa tuo tekstin tai koodin lähettely selaimen ja serverin välillä on varsin simppeliä.

Juu, noi yksityiskohdat vaikuttais selkeiltä. Tuosta linkkaamasta node.js -kirjastosta semmoinen huomio, että sen tukema BBCode ei kyllä ole ihan sama kuin tämän palstan koodi. Joitan esimerkkejä (jotka ei toimi täällä):

[b class="fancy"]text[/b]
[b class=fancy]text[/b] 
[h1]text[/h1]

Tai tässä itse asiassa kaikki kirjaston tukemat BBCodet ja niitten html -käännökset:

BBCode                                               | HTML
---------------------------------------------------- | -------------------------------------------------------------
[br]                                                 | <br>
[b]text[/b]                                          | <strong>text</strong>
[b class="fancy"]text[/b]                            | <strong class="fancy">text</strong>
[b data-value="10"]text[/b]                          | <strong data-value="10">text</strong>
[i]text[/i]                                          | <em>text</em>
[i class="fancy"]text[/i]                            | <em class="fancy">text</em>
[i data-value="10"]text[/i]                          | <em data-value="10">text</em>
[u]text[/u]                                          | <u>text</u>
[u class="fancy"]text[/u]                            | <u class="fancy">text</u>
[u data-value="10"]text[/u]                          | <u data-value="10">text</u>
[h1]text[/h1]                                        | <h1>text</h1>
[h1 class="fancy"]text[/h1]                          | <h1 class="fancy">text</h1>
[h1 data-value="10"]text[/h1]                        | <h1 data-value="10">text</h1>
[h2]text[/h2]                                        | <h2>text</h2>
[h2 class="fancy"]text[/h2]                          | <h2 class="fancy">text</h2>
[h2 data-value="10"]text[/h2]                        | <h2 data-value="10">text</h2>
[h3]text[/h3]                                        | <h3>text</h3>
[h3 class="fancy"]text[/h3]                          | <h3 class="fancy">text</h3>
[h3 data-value="10"]text[/h3]                        | <h3 data-value="10">text</h3>
[h4]text[/h4]                                        | <h4>text</h4>
[h4 class="fancy"]text[/h4]                          | <h4 class="fancy">text</h4>
[h4 data-value="10"]text[/h4]                        | <h4 data-value="10">text</h4>
[h5]text[/h5]                                        | <h5>text</h5>
[h5 class="fancy"]text[/h5]                          | <h5 class="fancy">text</h5>
[h5 data-value="10"]text[/h5]                        | <h5 data-value="10">text</h5>
[h6]text[/h6]                                        | <h6>text</h6>
[h6 class="fancy"]text[/h6]                          | <h6 class="fancy">text</h6>
[h6 data-value="10"]text[/h6]                        | <h6 data-value="10">text</h6>
[p]text[/p]                                          | <p>text</p>
[p class="fancy"]text[/p]                            | <p class="fancy">text</p>
[p data-value="10"]text[/p]                          | <p data-value="10">text</p>
[color=#FF0000]text[/color]                          | <span style="color:#FF0000">text</span>
[size=9]text[/size]                                  | <span style="font-size:9px">text</span>
[img]https://www.example.com/image.jpg[/img]         | <img src="https://www.example.com/image.jpg">
[img=https://www.example.com/image.jpg]              | <img src="https://www.example.com/image.jpg">
[email]info@example.com[/email]                      | <a href="mailto:info@example.com">info@example.com</a>
[email=info@example.com]text[/email]                 | <a href="mailto:info@example.com">text</a>
[url]https://www.example.com[/url]                   | <a href="https://www.example.com">https://www.example.com</a>
[url=alert('hello world')|onclick]text[/url]         | <a onclick="alert('hello world')">text</a>
[url=https://www.example.com target=_base]text[/url] | <a href="https://www.example.com" target="_base">text</a>
[url=https://www.example.com]text[/url]              | <a href="https://www.example.com">text</a>
[a=anker]text[/a]                                    | <a href="#anker" name="anker">text</a>
[list]text[/list]                                    | <ul>text</ul>
[*]text[/*]                                          | <li>text</li>

https://www.npmjs.com/package/js-bbcode-parser

Tai siis vielä kerran "tai", että on tossa paljon tuttujakin, mutta ainakin "quote" taitaa puuttua, joka on aika tärkeä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 06, 2020, 23:35:02
Joo tuo on kyllä hyvä huomio. Lainaus on kieltämättä yksi keskeisimmistä toiminnoista, jonka pitäisi minimissään onnistua, enkä suoraan sanottuna tiedä kuinka se on tässä simple machinesissa tehty. Tuossa javascript-kirjatossa oli kuitenkin ohjeet kuinka kirjoittaa noita koodi-konversioita itse. Ehkä simple machines toteuttaa lainauksen parseroinnin myös regexillä kuten tämä javascript kirjastokin, joten sen voisi kaiketi copypeistata sieltä tuohon javascript-kirjaston koodiin. Ja se tuskin on suuri haitta, jos softa tukisi sellaisiakin bbc-ish -koodeja, joita simple machines ei tue?

Eli tuolla oli tällainen malli kuinka bbc- "rivin vaihto" -koodi muutetaan html- "rivin vaihto" -koodiksi:
import bbCodeParser from 'js-bbcode-parser';

const parser = bbCodeParser.create({
    '\\[br\\]': '<br>'
});
console.log(parser.parse('This is a text[br]with HTML Break.'));
Otsikko: Vs: Ohjelmointi
Kirjoitti: Lenny - maaliskuu 07, 2020, 04:36:39
Lainaus käyttäjältä: Eläimen kokoinen möhkäle - maaliskuu 06, 2020, 18:10:28
Lainaus käyttäjältä: Lenny - maaliskuu 06, 2020, 17:29:59
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 04, 2020, 20:59:29
Mietin, että oisko Kantista teoriassa mahdollista toteuttaa "yhden sivun sovelluksina" niin että BBCoden tulkkaus tapautuisi selaimessa? Mikä sen estäisi? En ole pro. Jonkun tyhmän kurssin käynyt muutama vuosi sitten.

Oma kysymyksensä on myös että miten tällainen foorumi voisi toimia yhden sivun sovelluksena. Vähän kuten Facebook vai?

Tuon tyyppisestä konversiosta olisi varmaankin kyse? Ja tämän järjestelmän php-alusta ei kaiketi suoraan tue tuollaista vaihtoehtoa? Vai tarjoaako Simple Machinesin backend esim. json-rajapinnan?

Erona siis se, että siinä missä nykyisellään serveri palauttaa jokaisen kutsun yhteydessä jokaisen sivun kaiketi valmiina html-koodeina, yhden sivun aplikaatiossa serveri palauttaisi ensiksi yhden valmiin mutta geneerisen html-sivun ja sen jälkeen geneerisen sivun javascript tilaa serveriltä päivittämättä sivua esim. json-muotoisen paketin dataa, jonka perusteella geneerisen sivun html muokataan javascriptillä sen näköiseksi, kuin pitää.

Totta kai php:lla voi tehdä sellaisen sivun, mutta SMF ei toimi sillä tavalla. SMF on niin vanha softa, että ei ensimmäisten versioiden aikana koko konseptia edes ollut olemassa.

Kävin vain miettimään, että minkälainen foorumi olisi toiminnallisesti "yhden sivun palveluna". Siis käyttäjän näkökulmasta. En oikein keksi mitä etua sellaisesta olisi toiminnallisesti.

Tällainen keskustelufoorumi on käytännössä yhtä kuin tietokanta, jota kysellään kevyen web-käyttöliittymän avulla. Viestilistaus haetaan kannasta. Viesti haetaan kannasta. Viesti kirjoitetaan ja lisätään kantaan, ja niin edelleen. Kaikki hyvin staattisia toimintoja, joihin ei tarvita mitään reaaliaikaisesti päivittyvää taustasivua.

Tietoturvaan vakavasti suhtautuvalle tällainen staattinen sivu on myös kiva, koska voi vaikka ottaa javascriptin kokonaan pois päältä. Tämä foorumi toimii oikein hyvin ilmankin.

On tästä SMF:n staattisuudesta myös haittapuolia. Esimerkiksi vaikka plugarit kuten tuo etusivun chat toimisi paljon järkevämmin "yhden sivun sovelluksena".

Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - maaliskuu 07, 2020, 08:14:54
Lainaus käyttäjältä: Eläimen kokoinen möhkäle - maaliskuu 06, 2020, 23:35:02
Joo tuo on kyllä hyvä huomio. Lainaus on kieltämättä yksi keskeisimmistä toiminnoista, jonka pitäisi minimissään onnistua, enkä suoraan sanottuna tiedä kuinka se on tässä simple machinesissa tehty. Tuossa javascript-kirjatossa oli kuitenkin ohjeet kuinka kirjoittaa noita koodi-konversioita itse. Ehkä simple machines toteuttaa lainauksen parseroinnin myös regexillä kuten tämä javascript kirjastokin, joten sen voisi kaiketi copypeistata sieltä tuohon javascript-kirjaston koodiin. Ja se tuskin on suuri haitta, jos softa tukisi sellaisiakin bbc-ish -koodeja, joita simple machines ei tue?

Eli tuolla oli tällainen malli kuinka bbc- "rivin vaihto" -koodi muutetaan html- "rivin vaihto" -koodiksi:
import bbCodeParser from 'js-bbcode-parser';

const parser = bbCodeParser.create({
    '\\[br\\]': '<br>'
});
console.log(parser.parse('This is a text[br]with HTML Break.'));


Jep. kun oon puhunut BBCode -kääntäjästä, en oo vissiin miettinyt, miten yksinkertainen "markup langeuage" tms. BBCode on. Kääntäjät ja tulkit ohjelmointikielille on legendaarisen vaikeita kirjoittaa. Ite oon semmoisen kirjoittamisessa opiskelukontekstissa kerran aika surkeasti epäonnistunut (vaikka kurssista sentään läpi pääsinkin). BBCodessa tägit voi tosiaan kääntää yksitellen, ihan vaan säännöllisillä lausekkella (https://fi.wikipedia.org/wiki/S%C3%A4%C3%A4nn%C3%B6llinen_lauseke), ja jos esim. tägipareja puuttuu, tulee vaan oudon näköistä html:ää, jollaista sisltävät viestit Edward sit poistaa.  ::)

EDIT. Tai ei hän niitä quote tägejä nyt voi ihan yksitellen sentään kääntää html:ksi. Tai riippuu varmaan vaikka mistä, että voiko. Mitä selain tekee, jos sille tulee vastaan avattu tägi, jota ei koskaan suljeta? Vähänkö sekoilen tässä ketjussa, huh!
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - maaliskuu 07, 2020, 08:27:00
^^ Niin joo, vois kuvitella tilanteen, jossa käyttäjäkunta kasvaisi hirveesti ja palvelin rupeaisi BBCodea kääntäessään nikottelemaan. Ilmeisesti varsin epätodennäköinen skenaario. Sit yhden sivun keskustelupalsta skaalautus edullisemmin. Seuraava kasvun raja ois kenties LAMPin M, eli MySQL. Pystyiskö johonkin ei-relationaaliseen (https://fi.wikipedia.org/wiki/NoSQL) tietokantaan sit tallentamaan paremmin json'eita kuin sitä, mitä SMF MySQL -tietokantaansa nykyisin tallentaa? Nyt on tunne, että oon vähän ylikierroksilla.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Lenny - maaliskuu 07, 2020, 09:00:14
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 07, 2020, 08:27:00
^^ Niin joo, vois kuvitella tilanteen, jossa käyttäjäkunta kasvaisi hirveesti ja palvelin rupeaisi BBCodea kääntäessään nikottelemaan. Ilmeisesti varsin epätodennäköinen skenaario. Sit yhden sivun keskustelupalsta skaalautus edullisemmin. Seuraava kasvun raja ois kenties LAMPin M, eli MySQL. Pystyiskö johonkin ei-relationaaliseen (https://fi.wikipedia.org/wiki/NoSQL) tietokantaan sit tallentamaan paremmin json'eita kuin sitä, mitä SMF MySQL -tietokantaansa nykyisin tallentaa? Nyt on tunne, että oon vähän ylikierroksilla.

Tuo on totta, että joku Facebookin kaltainen palvelu on käytännössä pakko toteuttaa asiakavetoisesti, eli iso osa prosessoinnista tapahtuu selaimessa. Pääasiallinen motivaatio tällaisella "yhden sivun palvelulla" ei kuitenkaan ole minun nähdäkseni tekninen, vaan käyttöliittymä. Nämä palveluthan ovat luonteeltaan tällaisia "striimejä", jossa sivulle tipahtelee dataa reaaliaikaisesti. Ne ovat siis ikään kuin videoita, siinä missä tällainen staattinen foorumi on kuva. Täysin erilainen paradigma, johon tarvitaan myös toisenlaiset työkalut. Edelleen en näe miksi staattinen foorumi tarvitsee tällaista dynaamista striimausta.

Maailmalla on kyllä aika massiivisia SMF-saitteja, joissa ei ole mitään skaalautumisongelmia.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - maaliskuu 07, 2020, 11:02:02
Lainaus käyttäjältä: Vaaraton Norsu - maaliskuu 04, 2020, 20:59:29Ehkä tää sopis tänne. Oon vaan tätä miettinyt, kun kirjoittaessani tälle palstalle aika usein klikkaan "Esikatselu." Sivun javascript -koodeissa (ks. mm. otteet alla) ei taida olla BBCode -tulkkia, joka esikatselun generoisi? Sen sijaan BBCoden kääntänee html:ksi Kantiksen palvelimen PHP -koodi. Mikä tuntuu vähän haaskaukselta palvelimen resurssien kannalta. (Ja mikä on joskus hidastakin, vaikkei siitä haittaa olekaan.)

Samaa mieltä. Näissä on ideoinnin paikkaa. Toisaalta ...

Palvelinpuolella toimii tavanomaisempi koodauskieli. Mitä javascript oikeastaan on, tuohon nähden? Onko koodaus, ja sen rakentamismahdollisuutta oikeasti harkittu harkittu selainympäristöön?

Itse niin vähän käyttänyt javascriptiä, ja sitäkin aikoja sitten, että en osaa sanoa mitään.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - maaliskuu 09, 2020, 11:52:35
Mielenkiintoinen ohjelmointilinkki, joka antaa vastauksena json -tiedoston. Joka klikkauksella erilaisen. Takana kai jonkinlainen REST api.

http://api.icndb.com/jokes/random?firstName=Vaaraton&lastName=Norsu

Sopisi hyvin yhden sivun sovelluksen yhdeksi elementiksi.

EDIT. Linkki: http://www.icndb.com/
Otsikko: Vs: Ohjelmointi
Kirjoitti: Vaaraton Norsu - maaliskuu 09, 2020, 12:03:48
Tänne voi lähettää jsonin, ja saada vaihdossa muokatun version siitä:

https://www.yodaspeak.co.uk/

Siihen vaan tarvitsee luoda käyttäjätili.

Esimerkki: Haetaan edellisen viestin linkistä vitsi...

Vaaraton Norsu does not follow fashion trends, they follow him. But then he turns around and kicks their ass. Nobody follows Vaaraton Norsu.

Sitten syötetään tän ketjun linkkiin ja saadaan...

Vaaraton norsu follows not fashion trends, him, they follow him. But he turns around and kicks their ass then.  Nobody follows vaaraton norsu.

Äh joo, tein tämmöisen yrityksenä huvittaa veljenpoikaa, ja siinä oli jotain vaikeuksia cross-site scripting -rajoitusten kanssa.

Japanese rendition of vaaraton norsu's first visit to tokyo, godzilla is.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 10, 2020, 11:31:53
Onni on kun palvelimen tietokannalla eri asetukset kuin asetukset kehitysympäristössä. Onnen tunnetta lisää vielä se, kun pitää näissä olosuhteissa paikallistaa virhe toisen kirjoittamasta koodista.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 12, 2020, 12:50:10
Tänään opin php-kirjasto lumenin autentikaation tekemisen oikeaoppisesti kehitysympöristöön. Seuraavaksi pitäisi pystyttää sama testipalvelimelle. Ei ole katkua kuitenkaan, kuinka se tehdään. Ei viitsi kamalasti itse testailla palvelimen säätöjä kun siinä voi lakata muut testijärjestelmät toimimasta eli pitää varmaan kysellä apuja palvelinjampoiltamme.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 12, 2020, 16:09:16
Tai siis, ei kai siinä hätätilassa muuta kuin tiedostojen kopypaste testipalvelimelle, mutta kun haluaisin asentaa sen siten kuin se on suunniteltu asennettavan, tyyliin käyttämällä palvelimelle mahdollisesti asennettuja applikaatioita. Siinä kohtaa huomaan kuitenkin tietäväni proseduurista vähemmän kuin uhkarohkeuteni kokeilemiseen edellyttäisi.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 25, 2020, 16:02:00
^copypastella mennään.

Toisen rojektin saan tehdä reactilla. Vihdoinkin saan tehdä reactia! Esimies harmitteli, ettei itse osaa reactia, mutta pohti, että kun firmassamme on käytetty reactia muuallakin, niin eikai se haittaa, vaikka tämä tehdään reactilla.

Heti alkoi rojekti edistyä, kun pääsin eroon jQuery-räpellyksistäni. Ei jQuery muuten olisi ongelma, mutta kun sen käytössä ei ole konventionaalisia ratkaisuja, virheieiden edessä on vaikeampi löytää neuvoa interwebistä. Muutenkin tämä on hieman isompi projekti niin on hyvä että löytyy vakiintuneet käytännöt ja ohjeet kuinka lisätä ominaisuuksia. jos pitäisi keksiä omat käytännöt tätä projektia varten, siinä olisi kamala muistaminen. Nyt ei tarvitse pahemmin pelätä sitä että kukaan ei osaisi lukea koodia, jos osaa reactia.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 07, 2020, 15:33:08
Päivitettiin asiakkaan palvelu ajantanaiselle php-alustalle viime syksynä ja sen jälkeen on havaittu aika-ajoin siellä täällä yhteensopivuusongelmia kirjoitetun vanhan php:n ja uuden php:n välillä. Asiakkaalla oli iso projekti tässä hiljattain ja tietysti juuri sen yhteydessä yhteensopivuusongelmat pääsivät isoon rooliin kun sen ansiosta tietokantaan tallentui ihan perkeleesti ylimääräistä dataa niin, että projektin saurantatilastot eivät pidä nyt lainkaan paikkaansa. Sitten kun kukaan meistä tämän projektin kehittäjistä ei ole mikään tietokantaasiantuntija, ei olla keksitty hakuja, joilla voisi hakea tietokannasta näppärästi sellaiset rivit, jotka ovat turhia. Tai siis on, mutta haarukoimme ne nyt useammalla haulla eivätkä nämä hakumme paljasta välttämättä kaikkia ongelmarivejä. Tietokannssa on toisin sanoen liikaa dataa, jotta voisimme käydä nykyisillä hauilla kaikki tapaukset läpi ja siten varmistaa, että kaikki ylimääräinen on poistettu.

Ongelmana on taulu x, josta pitäisi hakea kaikki ne rivit, joissa kentän y arvo on useammin kuin kerran per kentän arvo z. Eli jos taulusta x löytyy kentän y arvo 2 useammin kuin kerran ja molemmista riveistä löytyy kenttä z arvolla 3, pitäisi uudempi tietue poistaa. Ongelma on mysql-kysely, joka pystyy listaamaan rivit, joissa tuollaisia duplikaatteja. Intuitio ei ainakaan vielä riitä muodostamaan tarvittavaa mysql-kyselyä.

Kellään ideoita?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 07, 2020, 15:52:07
Lainaus käyttäjältä: Eläimen kokoinen möhkäle - huhtikuu 07, 2020, 15:33:08
Päivitettiin asiakkaan palvelu ajantanaiselle php-alustalle viime syksynä ja sen jälkeen on havaittu aika-ajoin siellä täällä yhteensopivuusongelmia kirjoitetun vanhan php:n ja uuden php:n välillä. Asiakkaalla oli iso projekti tässä hiljattain ja tietysti juuri sen yhteydessä yhteensopivuusongelmat pääsivät isoon rooliin kun sen ansiosta tietokantaan tallentui ihan perkeleesti ylimääräistä dataa niin, että projektin saurantatilastot eivät pidä nyt lainkaan paikkaansa. Sitten kun kukaan meistä tämän projektin kehittäjistä ei ole mikään tietokantaasiantuntija, ei olla keksitty hakuja, joilla voisi hakea tietokannasta näppärästi sellaiset rivit, jotka ovat turhia. Tai siis on, mutta haarukoimme ne nyt useammalla haulla eivätkä nämä hakumme paljasta välttämättä kaikkia ongelmarivejä. Tietokannssa on toisin sanoen liikaa dataa, jotta voisimme käydä nykyisillä hauilla kaikki tapaukset läpi ja siten varmistaa, että kaikki ylimääräinen on poistettu.

Ongelmana on taulu x, josta pitäisi hakea kaikki ne rivit, joissa kentän y arvo on useammin kuin kerran per kentän arvo z. Eli jos taulusta x löytyy kentän y arvo 2 useammin kuin kerran ja molemmista riveistä löytyy kenttä z arvolla 3, pitäisi uudempi tietue poistaa. Ongelma on mysql-kysely, joka pystyy listaamaan rivit, joissa tuollaisia duplikaatteja. Intuitio ei ainakaan vielä riitä muodostamaan tarvittavaa mysql-kyselyä.

Kellään ideoita?


SELECT
    first_name, COUNT(first_name),
    last_name,  COUNT(last_name),
    email,      COUNT(email)
FROM
    contacts
GROUP BY
    first_name ,
    last_name ,
    email
HAVING  COUNT(first_name) > 1
    AND COUNT(last_name) > 1
    AND COUNT(email) > 1;


tuolta -> https://www.mysqltutorial.org/mysql-find-duplicate-values/ löytyi yo malli. Pitääpä huomenna kokeilla.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - huhtikuu 07, 2020, 19:14:16
^
Ryhtymättä paneutumaan mysql:n mahdollisiin rajoituksiin sql:ssä totean, että oikean puun alla haukutaan.

Rivit, joissa nimettyjen kenttien arvoyhdistelmä esiintyy usean kerran, etsitään sql:llä ryhmittämällä GROUP BY määreellä niiden kenttien mukaan, joiten toistumista haetaan ja COUNT() funktiolla (>1) katsotaan mitkä arvoyhdelmät toistuvat

Ne rivit joilla first_name, last_name, email on arvoyhdistelmissä, jotka esiintyvät useamman kerran haetaan sql:llä tähän tapaan (kyseisen järjestelmän piirteet huomioiden)

select c.*
from contacts c
inner join (select first_name, last_name, email, count(*)
        from contacts
        group by first_name, last_name, email
        having count(*) > 1
      )  b
      on b.first_name = c.firstname and b.last_name = c.last_name and b.email = c.email
order by  c.last_name,  c.first_name, c.email

Jos halutaan kustakin monikosta vain se, jonka yksikäsitteisen kentän personid arvo on pienin, niin

select c.*
from contacts c
inner join (select first_name, last_name, email, count(*) cnt, min(personid) minpid
        from contacts
        group by first_name, last_name, email
        having count(*) > 1
      )  b
      on b.first_name = c.firstname and b.last_name = c.last_name and b.email = c.email and b.minpid = c.personpid
order by  c.last_name,  c.first_name, c.email

Googlella haku on tämän tyypin ongelmien ratkaisutapa (tässä esim. 'mysql find duplicate rows')

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 08, 2020, 09:16:49
Kiitos Jaska. Sain kuitenkin ratkottua ongelman tuolla löytämälläni tavalla. Näin saimme tulostettua kaikki oleelliset rivitiedot, joissa sama data oli useammin kuin kerran ja sitä myöten saimme korjattua ongelmamme.
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - huhtikuu 10, 2020, 17:49:47
Voisiko joku osaava tehdä tuonne "Testaa itsesi ja vertaa muihin"-ketjuun  näistä  (https://www.poliisi.fi/instancedata/prime_product_julkaisu/intermin/embeds/poliisiwwwstructure/85693_Arvomerkkitaulu_2018.pdf?2bc6946f3a68d788) testin.

Haluttaisi tietää kuinka laajaa on poliisien arvomerkkien tuntemus.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - huhtikuu 10, 2020, 18:52:17
Lainaus käyttäjältä: ROOSTER - huhtikuu 10, 2020, 17:49:47
Voisiko joku osaava tehdä tuonne "Testaa itsesi ja vertaa muihin"-ketjuun  näistä  (https://www.poliisi.fi/instancedata/prime_product_julkaisu/intermin/embeds/poliisiwwwstructure/85693_Arvomerkkitaulu_2018.pdf?2bc6946f3a68d788) testin.

Haluttaisi tietää kuinka laajaa on poliisien arvomerkkien tuntemus.
Tee se itse:
https://www.flexiquiz.com
https://www.classmarker.com/online-test-maker/
https://myelearningworld.com/top-10-free-online-quiz-makers-for-teachers-and-educators/

Tämä näytti helpolta ja ilman sisäänkirjautumista:
https://www.quiz-maker.com

Tässä valmis testi:
http://www.quiz-maker.com/QWF9QT4
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - huhtikuu 10, 2020, 19:23:11
Lainaus käyttäjältä: a4 - huhtikuu 10, 2020, 18:52:17
Lainaus käyttäjältä: ROOSTER - huhtikuu 10, 2020, 17:49:47
Voisiko joku osaava tehdä tuonne "Testaa itsesi ja vertaa muihin"-ketjuun  näistä  (https://www.poliisi.fi/instancedata/prime_product_julkaisu/intermin/embeds/poliisiwwwstructure/85693_Arvomerkkitaulu_2018.pdf?2bc6946f3a68d788) testin.

Haluttaisi tietää kuinka laajaa on poliisien arvomerkkien tuntemus.
Tee se itse:
https://www.flexiquiz.com
https://www.classmarker.com/online-test-maker/
https://myelearningworld.com/top-10-free-online-quiz-makers-for-teachers-and-educators/

Tämä näytti helpolta ja ilman sisäänkirjautumista:
https://www.quiz-maker.com

Toki tekisin itse, nopeasti ja tehokkaasti, mutta kun olen aina asemoinut itseni enemmän johtoportaaseen, niin ei oikein sovi itse noita tehdä.

Olin jo 17-vuotiaana johtohommissa (kaapelia vetämässä).
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - huhtikuu 10, 2020, 19:54:42
Lainaus käyttäjältä: a4 - huhtikuu 10, 2020, 18:52:17
Tässä valmis testi:
http://www.quiz-maker.com/QWF9QT4

Päähän jää joskus outoja asioita. Mielestäni kuvassa Reinikaisella on väärät natsat, koska tämä kohtaus oli mielessä
https://areena.yle.fi/1-4025040?seek=520
Mutta ilmeisesti oikea vakanssi sitten löytyi Artturi Sakarillekin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - toukokuu 04, 2020, 22:36:13

Ohjelmoinnissa on kieliä, siis jotain kielelliseltä vaikuttavaa rakentelua.

Kun kielellisyyttä ajattelee vapaammin tietokoneiden ohjelmamaailmassa, niin vahvat komentorivisysteemejä pitävät atk-järjestelmät, kuten Unix tai Linux, on oikeastaan myös kielellinen juttu. Samaa on mm SQL, joka tuntuu vähän operoivammalta, johonkin enemmän kasattuun liittyen.

Molemmat EMsta operoivat tasoilla, jotka vastaavat enemmän sitä toiminnallisuutta, mihin ihminen venyy normaalikielen käytössä. Ihmisen kieli, sen eri muodoissaan, kattaa tavallista arkea, tai vaikka jotain spesifisempää.

Käyttäjätason ATK, tavallisia käyttäjiä ajatellen, avautuu eri systeemeissä, vähän eri tavoin kielelliskäytöllisenä, jos funtsii kytkennällisyyksiä, joita järjestelmä mahdollistaa, tai sulkee pois. Jotkin systeemit avaavat maailman sisäänsä, ristiinniveltyvästi. Osa toimii boksityylisemmin.

Maailma isona voi olla verkostoitunut, kuten vaikka netti. Toisaalta, sitä uhkaa samanlainen boksiutuminen. Oli se suomalainen filosofiopiskelijan alku, josta tullut kuuluisuus myöhemmin, joka meni ennustamaan tällaista. Himanen oli nimi.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 01, 2020, 15:20:10
Osaako joku neuvoa. Algoritmi riittänee (ellei sen ymmärtäminen mene tähtitieteeksi).

Pitäisi siis kirjoittaa javascript-ohjelma, jossa voisi piirtää ajoratoja niin, että se muodostaa ajoradan reunat "viivakomponentein". Eli jos hiirellä piirtää polun:


     |
     |
     |
     |


ohjelma konvertoisi polun "leveäksi" poluksi:


    | |
    | |
    | |
    | |


Jos piirretty polku on ympyrä tai neliö, eli että ilmaa sisältävä kuvio on symmetrinen kuvion keskipisteen suhteen, toteuttaa jo tämä (https://editor.p5js.org/lazydistribution/sketches/pM24V_i1H) ohjelma idean. Ongelman muodostaa kuitenkin tilanne, jossa viiva ei ole symmetrinen kuvion keskipisteen suhteen.

Mulla siis on ajatuksena kehitellä auto-tekoäly-simulaatio, joka oppisi ajamaan ajorataa pitkin niin, että sillä on sensorit, jotka havaitsevat ajoradan reunat, jotta se oppisi etäisyyttä reunoihin säätelemällä ajamaan ajorataa pitkin. Ajattelin, että reunat olisi hyvä olla viivoilla piirrettävissä, koska simulaatiossa "sensorit" on laskentatehoa säästäen helppo laittaa havaitsemaan viivoja. Toki jos javascriptille löytyy joku algoritmi, joka tunnistaa reunat pikselien värisävyjen muutoksista, sellainenkin sopii. Mulla on varasuunitelmana se, että ajorata piirretään kuusikulmioina. Kennorakenne onkin ehkä kaikkein näppärin tapa rakentaa ajorata, mutta sekään ei voi osoitella kuin vain muutamiin suuntiin kun taas vapaalla viivalla piirretty ajorata voisi olla minkä muotoinen tahansa eli ajorata voisi osoittaa milloin mihinkin suuntaan.

Löytyykö ideoita, kiitos? Varmaan löytyy Stackoverflowsta, mutta en osaa vielä määritellä hakusanoja ainakaan googlelle oikein, jotta löytäisin googlella etsimäni. Tällä hetkellä paksujen viivojen piirtämistä käsittelevät artikkelit tarjoavat javascriptille tai muille ohjelmille lineWeight() -funktiota tai vastaavia funktioita, mutta ei tietoa, miten kyseiset funktiot sen viivanleveyden käytännössä toteuttaa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 01, 2020, 15:26:48
^
Tossa pitäisi kai ottaa piirretystä polusta edellinen piste x-1 ja seuraava piste x+1 ja määritellä niiden perusteella, mihin suuntaan ajoradan reunapiste/pisteet on piirrettävä suhteessa tarkasteltavaa pisteeseen x0, jonka ajoradan reunuspisteet kulloinkin piirretään. Ja riippuen siitä, kummalle puolelle piste x0 sijoittuu pisteiden x-1 ja x+1 välille piirrettyä viivaa, piirretään "kulman" pienemmälle puolelle yksi piste ja kulman suuremmalle puolelle useampi piste.

Olisikohan joku tällainen haettu algoritmi suusanallisesti selitettynä?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - syyskuu 01, 2020, 20:11:24
Emmätiä, mutta luulisin, että jos meillä on viiva joka esittää tien keskiviivaa, niin reuna on kummallakin puolella tien leveyden puolikkaan etäisyydellä kohtisuoraan keskiviivan pisteen tangenttia vastaan
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 02, 2020, 18:36:24
Löysin viivan normaalien laskukaavan ja se vaikuttaa lupaavalta.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 03, 2020, 11:50:16
https://editor.p5js.org/lazydistribution/sketches/TBG409hmCX (https://editor.p5js.org/lazydistribution/sketches/TBG409hmCX)


Ainakin simppelin kuvion reunaviivat onnistuu, kun saa viivojen normaaleista suunnan, että mihin päin pitää piirtää reunaviiva kuvion sisäpuolella ja kuvion ulkopuolella. Pitää tosin liitttää toi siihen "sketsiin", jossa kuvio piirretään hiirellä, jotta sitten ihan oikeasti näkee, toimiiko tämä implementaatio. Ei ole suuria toiveita sen suhteen. Toistaiseksi vaikuttaa kuitenkin siltä, että olen ymmärtänyt, kuinka noiden normaalinen kanssa toimitaan. Tosin en ole matemaatikko taikka fyysikko, joten se, miten olen ongelman tässä ratkaissut, voi olla alan ammatilaisten silmissä kamala.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 03, 2020, 12:28:17
Olen css-ohjelmoinnissa täysi turisti. Olen nyt tantrajoogannut kaksi työpäivää simppelin pdf-tiedoston kanssa tuloksetta. Serverillä pyörii Domphp-kirjasto, joka konvertoi html-koodin pdf-tiedostoksi, tukien jossain määrin paremmin css-tyylejä kuin toinen vastaava TCPDF-kirjasto. Molemmat ovat täysiä susia, mitä tulee tarkkojen määritysten säätämiseen html-tyyleillä, jos kohta todennäköisempää, etten vain osaa CSS-tyylien määrittelyjä tarpeksi hyvin Domphp-vaatimusten näkökulmasta.

Pitäisi jakaa sivu neljään yhtä suureen osaan ja sitten asemoida sisältö neljään keskenään samanlaiseen lokeroon niin, että vaihtuvien tietojen paikat kussakin lokerossa on määritelty. Kyseesssä on postikorttitulostusta varten tulostettava arkki. Arkille siis menee neljä korttia. Saan homman toimimaan selaimessa, mutta en ilmeisesti css-ohjelmointitaidoissani olevien aukkojen vuoksi niin, että Domphp onnistuisi konvertoimaan saman pdf-tiedostoksi.

Sain kasaan kahden päivän aikana yhden version, joka vaikuttaa tulostavan yhden sivun kuten pitääkin, mutta kun tiedostossa voi olla useampia sivuja. Olen yrittänyt ohjelmoida html-koodin ja css-tyylit lukuisia kertoja eri tavoin, mutta homma ei ota edistyäkseen.

Viimeisin oljenkorteni on palata implemataatiooni, joka tulostaa yhden sivun oikein ja kokeilla konvertoida html-tekstiä sivu kerrallaan pdf-tiedostoiksi, ja lopulta yhdistän nuo irtonaiset yhden sivun pdf-tiedostot yhdeksi pdf-tiedostoksi. Tätä pdf-sivujen "mergeämistä" varten latasin libmergepdf-kirjaston ja ensivaikutelma on positiivinen. Seuraava ongelma on kuitenkin se, että pdf-sivun koko on ollut mulla todennäköisesti väärä. Postikorttitulostuksessa sivun koko on erilainen kuin DomPHP-kirjastossa valmiiksi olevat enkä osaa sanoa, onnistuuko tuon yhden sivun generointi oikein enää jos menen sorkkiman kirjaston koodia sivukoon osalta. Kaiken järjen mukaan homman pitäisi olla simppeli, mutta tämä kaksi päivää on osoittanut, että pärehimmelini löytää kuin löytääkin aina vain uuden tavan tuottaa minulle pettymys.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 03, 2020, 14:41:40
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 03, 2020, 11:50:16
https://editor.p5js.org/lazydistribution/sketches/TBG409hmCX (https://editor.p5js.org/lazydistribution/sketches/TBG409hmCX)


Ainakin simppelin kuvion reunaviivat onnistuu, kun saa viivojen normaaleista suunnan, että mihin päin pitää piirtää reunaviiva kuvion sisäpuolella ja kuvion ulkopuolella. Pitää tosin liitttää toi siihen "sketsiin", jossa kuvio piirretään hiirellä, jotta sitten ihan oikeasti näkee, toimiiko tämä implementaatio. Ei ole suuria toiveita sen suhteen. Toistaiseksi vaikuttaa kuitenkin siltä, että olen ymmärtänyt, kuinka noiden normaalinen kanssa toimitaan. Tosin en ole matemaatikko taikka fyysikko, joten se, miten olen ongelman tässä ratkaissut, voi olla alan ammatilaisten silmissä kamala.


Joo, ei onnistunut: https://editor.p5js.org/lazydistribution/sketches/l1WvLMcPlb (https://editor.p5js.org/lazydistribution/sketches/l1WvLMcPlb). Sen pitäisi piirtää normaalin mukaan pitkä viiva ja sitten muodostaa piste siihen kohtaan, jossa normaalin mukaan piirretty pitkä viiva leikkaa järjestyksessä seuraavan normaalin mukaan piirretyn pitkän viivan ja lopulta piirtää reunaviiva noiden pisteiden kautta. Joko algoritmissani on feelua, toteutuksessa on feelua tai molemmissa. Täytyy siis jatkaa opintoja.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 03, 2020, 18:24:02
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 03, 2020, 14:41:40
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 03, 2020, 11:50:16
https://editor.p5js.org/lazydistribution/sketches/TBG409hmCX (https://editor.p5js.org/lazydistribution/sketches/TBG409hmCX)


Ainakin simppelin kuvion reunaviivat onnistuu, kun saa viivojen normaaleista suunnan, että mihin päin pitää piirtää reunaviiva kuvion sisäpuolella ja kuvion ulkopuolella. Pitää tosin liitttää toi siihen "sketsiin", jossa kuvio piirretään hiirellä, jotta sitten ihan oikeasti näkee, toimiiko tämä implementaatio. Ei ole suuria toiveita sen suhteen. Toistaiseksi vaikuttaa kuitenkin siltä, että olen ymmärtänyt, kuinka noiden normaalinen kanssa toimitaan. Tosin en ole matemaatikko taikka fyysikko, joten se, miten olen ongelman tässä ratkaissut, voi olla alan ammatilaisten silmissä kamala.


Joo, ei onnistunut: https://editor.p5js.org/lazydistribution/sketches/l1WvLMcPlb (https://editor.p5js.org/lazydistribution/sketches/l1WvLMcPlb). Sen pitäisi piirtää normaalin mukaan pitkä viiva ja sitten muodostaa piste siihen kohtaan, jossa normaalin mukaan piirretty pitkä viiva leikkaa järjestyksessä seuraavan normaalin mukaan piirretyn pitkän viivan ja lopulta piirtää reunaviiva noiden pisteiden kautta. Joko algoritmissani on feelua, toteutuksessa on feelua tai molemmissa. Täytyy siis jatkaa opintoja.

Riisuin kaiken !ylimääräisen, eli kirjoitin kokonaan uuden. Nyt jälki on jo ihan tyydytävää: https://editor.p5js.org/lazydistribution/sketches/r60EQ2cVg (https://editor.p5js.org/lazydistribution/sketches/r60EQ2cVg). Tällä kertaa lasken sivulinjat suoraan normaalien antamista pisteistä (kunhan olen siirtänyt ne keskellä viivoja), sen sijaan, että hifistelisin leikkauspisteiden kanssa kuten edellisellä kerralla tein. Kunhan ei edellytä liian tarkkaa resoluutiota - jota en edellytä - tämä on jo hyvä suoritus. Vaatimuksethan olivat:
Vaatimukset ovat tällä erää ainakin tyydyttävästi täytetty, kunhan ei piirrä liian jyrkkiä mutkia. Eli tuo kolmas kohta vielä edellyttää ehkä hiomista. Jos nimittäin piirtää turhan jyrkän mutkan, pisteet menevät ikävästi ristiin ja tulos on ehkä visuaalinen haitta. Tosin minun taidoillani se tulee tehdasasetuksina.


Onko kellään ideoita miten nuo muodostuvat ikävät silmukat liian jyrkissä mutkissa saadaan pois?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 03, 2020, 18:45:32
^
Jos tossa tekisi niin, että jakaisi pinta-alan ruudukoksi ja piirtäisi pisteet sillä perusteella, missä kohtaa linja leikkaa ruudun jonkun sivun. Jos ruudun yhden sivun linja ylittyy useaman kerran lasketaan noiden kahden ylityskohdan keskiarvo ja käytetään sitä. Tämä näin alustavasti ajateltuna ehkäisisi sitä, että ei pääsisi muodostumaan tilanteita, jossa pisteitä olisi ruudun kokoista aluetta pienempi pisterykelmiä. Koska en nyt äkkiseltään keksi yhtään ongelmatilannetta tässä lähestymistavassa, lienee siinä niitä useampiakin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - syyskuu 05, 2020, 09:00:38
^ Ei valitettavasti mitään käryä aiheesta. :) Hiirellä piirtelystä tuli mieleen vain ratkaisu jossa piirretyn viivan paksuutta kasvatetaan halutun tien levyiseksi. Tarvittaessa voidaan piirtää paksun viivan päälle toisella värillä tai kumilla astetta ohuempaa viivaa, joloin syntyy tien reunat. :P

Ongelmanratkaisu jo itsessään on silti kiehtovaa ja opettavaista.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 05, 2020, 10:14:43
^
Joo. Tietysti siellä on metodi joka paksuntaa viivan mutta se lisää vain pikseleitä "viivan" molemmin puolin, joten viiva paksunee. Ajatus olisi kuitenkin saada tuon paksun viivan reunat vektorigrafiikkana. Kun laitan tekoälyä ja/tai evoluutioalgoritmiä noudettavan "formulan" noiden vektorien piitämän polun sisäpuolelle, voin helposti laskea jos ja missä kohtaa räikkönen törmää radan reunoihin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - syyskuu 05, 2020, 10:21:16
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 05, 2020, 10:14:43
^
Joo. Tietysti siellä on metodi joka paksuntaa viivan mutta se lisää vain pikseleitä "viivan" molemmin puolin, joten viiva paksunee. Ajatus olisi kuitenkin saada tuon paksun viivan reunat vektorigrafiikkana. Kun laitan tekoälyä ja/tai evoluutioalgoritmiä noudettavan "formulan" noiden vektorien piitämän polun sisäpuolelle, voin helposti laskea jos ja missä kohtaa räikkönen törmää radan reunoihin.
Mieluummin Grosjean. Kun ja milloin törmäilee. :D Siihenhän evoluutio perustuu ja syntyy myös niitä Räikkösiä. :)
Entäs jos laittaa tekoälyn tai ihmiskuskin pysyttelemään paksun ajolinjan sisäpuolella? Voidaanko helposti laskea kun ja missä kohtaa tekoräikköset ajavat ulos radan reunoista?

Paksummalla lompakolla: World's First Autonomous Racing Series | Roborace (https://www.youtube.com/watch?v=JE4fw0FdAvQ)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 05, 2020, 11:11:56
^Esitin pulman stackowerflowssa (https://stackoverflow.com/questions/63749593/how-to-programmatically-draw-a-thick-line-javascript) ja ilmeisesti ongelmani on onnistuttu nyt ainakin määrittelemään yhdensuuntaisten "korkeuskäyrien" laskemiseksi. Tosin haulla "parallel contours" ei tule ainakaan googlehaun kärkeen mitään apuja mitä osaisin ainakaan tältä istumalta.

Tuo kuvapinta-alan ruudukoksi jakaminen ja tarkistaminen, mitkä ruudut ja millä tavalla ottavat osumaa kun kuvio on piirretty vaikuttaisi olevan toistaiseksi parasta mitä internet tarjoaa. Ja ainakin tuo ongelma kulkee nimellä marching squares.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 05, 2020, 15:46:55
Joo, ei ole löytynyt vastausta. Eli marching squares vaikuttaisi lähestymistavalta. Siinä piirtoalue jaetaan ruudukoiksi ja piirretään viiva sen perusteella ruudun yli, ylittääkö ruudun jokin sen kulmien konfiguraatio raja-arvon. Näitä eri konfiguraatioita on yhteensä 16 kappaleta:

(https://lh3.googleusercontent.com/proxy/U9WNcbEcWVikzcOMIswWCzwlKuGcjnVOfg6jhysfwmnfObXF6-Eay4_qkHIuXbh9hKG8UNyPsTBOmiVE9ayx3-D_OaQg_LjSKLtfiKHnqD3AvcTVYHySXpvEZfuBHw-fVwvx6zsm)
Eli esim. kuten yo kuvan Case 1 -kohdassa, jos raja-arvo ylittyy vain vasemman alakulman kohdalla, piirretään viiva ruudun alimmasta viivasta ruudun vasemman puoleiseen viivaan ja niin edelleen. Lopullinen kuvio määräytyy sen perusteella, millä alueella raja-arvo on ylittynyt.

(https://thumbs.gfycat.com/CheapCavernousHousefly-size_restricted.gif)
Tyypillisin esimerkki marching squares -tekniikan hyödyntämisestä on klassisten metapallojen simuloiminen. Interpoloimalla noiden pisteiden sijaintia ruudukon viivoilla, jotka yhdistetään, saadaan riittävän pieniä ruutuja käyttämällä kulmikkaan viivan sijaan pyöreitä muotoja kuten yo-kuvasta näkee (tosin yo-kuvan resoluutio on niin pieni, että pikselit näkyvät, mutta se ei liity marching squares -interpolointiin).

Seuraava ratkaisualgoritmini:
Jotta saataisiin metapallojen sijaan metaviivaa, pitää ensinnäkin piirtoviivan pisteiden kodalla ylityttää raja-arvoja riittävä laajalta alueelta kuvapinta-alueella olevaa ruudukkoa, mikä edustaa siis viivan paksuutta ja toisekseen pitää varmistaa, että piirtoviivalla on riittävän usein pisteitä, jotta raja-arvon ylittävä alue on riittävän tasainen, eikä sellainen perhosen toukkamaisesti piirtoviivan pisteiden kohdalla pullea ja piirtoviivan pisteiden välissä kapea. Tämän jälkeen valitaan, mikä tahansa kuva-alalta löytyvä viiva ja aletaan yhdistelemään viivoja aina seuraavan lähimmän viivan kanssa.

PS. marchin squares on mulla jo valmiina (https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB). Siksi ratkaisualgoritmini ei sitä enää sisältänyt)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 05, 2020, 16:42:23
^

Nyt toi antaa piirtää (https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB). Tossa on vielä selkeesti hiomista. Tuossa ei ole interpolaatiota mukana, mikä tekee viivasta kulmikkaan. Tuossa on nyt kaksi vaihtoehtoa. Joko interpoloida noita pisteitä kussakin ruudussa, jolloin kulmat ainakin vähenevät tai sitten käyttää funktiota joka ottaa koko viivan ja pyöristää sen muulla keinoin, jälkimmäinen edellyttäisi, että nuo syntyneet viivat olisivat pisteittensä puolesta järjestyksessä, jossa ne ei vielä ole. Tosin koska saattaa olla tarve värittää ajorata ja ympäristö eri väreillä (silmää miellyttämään) nuo pisteet tulee joka tapauksessa yhdistää eli sitten voi katsoa josko tuon rosoisuuden saisi minimiin. Samaten piirrettäessä ei ole vielä riittävästi pisteitä, että jos piirtäessä kaahailee ei muodostu yhtenäistä kuviota.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 05, 2020, 18:18:49
^
Nyt on ongelma. Molemmat ääriviivat koostuvat nyt siis pienistä viivoista, jotka ovat keskenään sekaisin samassa listassa. Jotenkin pitäisi nyt kyetä järjestää ääriviivat, omiin listoihinsa ja vieläpä sinä järjestyksessä, kuin ne näyttävät olevan kuvaruudulla.  Kellään ideoita miten?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 06, 2020, 03:03:02
Vaikuttaa siltä, että homma etenee. Tässä on tarvinnut tehdä hieman kompromissiä sen suhteen, kuinka tarkkaan viivaa seurataan ja kuinka pehmeä viiva rakennetaan. Mun tarttee kyllä tota jotenkin vielä hioa, mutta periaatteessa tämä alkaa riittämään: https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB (https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB). En keksinyt keinoa tehdä tuota interpolaatiota, joten jouduin turvautumaan viivan pyöristäjään se vie nyt saatanasti aikaa että se muodostaa tuon viivan. Pitää tutkia vielä, miten saan tähän interpolaation. Se lienee nopeampia tapa pyöristää rosoisuus kuin tuo käyttämäni viivan pyöristäjä.

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 05, 2020, 18:18:49
^
Nyt on ongelma. Molemmat ääriviivat koostuvat nyt siis pienistä viivoista, jotka ovat keskenään sekaisin samassa listassa. Jotenkin pitäisi nyt kyetä järjestää ääriviivat, omiin listoihinsa ja vieläpä sinä järjestyksessä, kuin ne näyttävät olevan kuvaruudulla.  Kellään ideoita miten?

Meni saatanasti aikaa, että sain ratkottua tämän pulman. Jos tuota ei olisi ratkaissut, nyt käyttämääni viivan pyöristysfunktiota ei olisi voinut käyttää kun se ei olisi osannut yhdistää oikeita pisteitä toisiinsa kun ne eivät olleet järjestyksessä.

Edit: eivät ne kaikki ole järkässä vieläkään mutta riittävän hyvin kuitenkin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - syyskuu 06, 2020, 11:49:51
^
Olisiko tässä mitään ideaa, tai sisältyikö tämä jo kokeiluihisi?: ..at the position of each of these points we simply draw a circle of a given radius (20 pixels in my case).
https://bitesofcode.wordpress.com/2020/04/09/procedural-racetrack-generation/
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 06, 2020, 13:00:29
^
kiitos. Pitääpä tutustua.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 07, 2020, 10:35:27
^^
Stana! Tuohan vaikuttaa loistavalta. Kuten jo alunperin hieman ounastelinkin, joku on ajatellut saman asian paljon paremmin kuin minä. Ainakin kuvien peusteella tuo näyttää lupaavalta. Tuo on vieläpä tehty pyyttonilla jo valmiiksi. Ei tarvitsisi erikseen konvertoida javascriptistä pyyttoniksi, jos ihan tuolla pohjalla onnistuu myös testaus pysyykö auto radallaan.

Olen tosin vielä kokonaan ylenkatsonut vaihtoehtoa, jossa testataan pikselin värin perusteella, ollaanko ajoradalla vai sen ulkopuolella. Se olisi varmaankin helpoin toteutttaa sillä ei tarvitsi pohtia sitä kuinka rata määriteltäisiin vektoreissa vaan voisi piirrellä ajoradan miten huvittaa vaikkapa Paintilla, ladata kuva sisään ohjelmaan ja sitten vaan katsoa pikseleiden värien perusteella, ollaanko radalla vai sen ulkopuolella.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 07, 2020, 10:53:28
^
Samaten tuo pikselien värien lukeminen mahdollistaisi varmasti myös radan vektorisoimisen.

EDIT tosin ainut juttu vektorisoimisesta, jonka nopeasti löysin, ehdottaa tuon marching squaresin käyttöä siihen. Ja ilmeisesti löytyy valmis kirjasto tuota varten: https://github.com/OSUblake/msqr
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 07, 2020, 16:47:25
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 06, 2020, 03:03:02
Vaikuttaa siltä, että homma etenee. Tässä on tarvinnut tehdä hieman kompromissiä sen suhteen, kuinka tarkkaan viivaa seurataan ja kuinka pehmeä viiva rakennetaan. Mun tarttee kyllä tota jotenkin vielä hioa, mutta periaatteessa tämä alkaa riittämään: https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB (https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB). En keksinyt keinoa tehdä tuota interpolaatiota, joten jouduin turvautumaan viivan pyöristäjään se vie nyt saatanasti aikaa että se muodostaa tuon viivan. Pitää tutkia vielä, miten saan tähän interpolaation. Se lienee nopeampia tapa pyöristää rosoisuus kuin tuo käyttämäni viivan pyöristäjä.

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 05, 2020, 18:18:49
^
Nyt on ongelma. Molemmat ääriviivat koostuvat nyt siis pienistä viivoista, jotka ovat keskenään sekaisin samassa listassa. Jotenkin pitäisi nyt kyetä järjestää ääriviivat, omiin listoihinsa ja vieläpä sinä järjestyksessä, kuin ne näyttävät olevan kuvaruudulla.  Kellään ideoita miten?

Meni saatanasti aikaa, että sain ratkottua tämän pulman. Jos tuota ei olisi ratkaissut, nyt käyttämääni viivan pyöristysfunktiota ei olisi voinut käyttää kun se ei olisi osannut yhdistää oikeita pisteitä toisiinsa kun ne eivät olleet järjestyksessä.

Edit: eivät ne kaikki ole järkässä vieläkään mutta riittävän hyvin kuitenkin.

Tätä voisi kehittää. Ongelmana on nyt se, että jos haluaa interpoloida noita pisteitä, joiden kautta viiva piirretään ja ilman tuota raskasta laskentaa olemassaolevian pisteiden pehmentämiseksi, pitää piirtää reunoilta burrattu viiva ja interopoloida marching squares -viivoja. Ongelma on nyt, että sitä ei voi laskea piirretyn kuvion vektorigrafiikasta suoraan koska pisteet eivät ole tasaisin välimatkoin eivätkä riitävän lähellä toisiaan. Tämän voisi ehkä kiertää niin, että piirtäisi viivan viivatyökaluilla pikseligrafiikaksi, generoisi siitä kuvan ja laskisi tuon kuvan pikselien perusteella, mikä on minkäkin ruudukon pisteen opasitetti. Näin viiva olisi yhtenäinen marching squaresin laskettavaksi sen lisäksi, että nyt noiota pisteitä voisi mahdollisesti myös interpoloida.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 08, 2020, 11:17:32
Sitten olisi ajatus kokeilla evoluutioalgoritmia, josko jo pelkästään se riittäisi opettamaan tietokonetta ajamaan rata läpi ilman, että se törmäisi seinään.

Tämä edellyttää nyt ainakin että:
- auto pystyy mittaamaan etäisyytensä seinään
- auto pystyy perimään voimavektorin, joka määrää auton liikkeen suunnan suhteessa tuohon etäisyyteen.

Pitäisi vaan keksiä, miten tuon käytännössä toteuttaa. Ideaalitilanteessa suhtautuminen olisi portaaton. Eli mitä lähempänä seinää ollaan, sitä päinvastaisemmaksi suhteessa seinän normaaliin voimavektorin on muututtava ja taas toisin päin, jotta voimat, jotka ajavat autoa radalla eteenpäin vaikuttaisivat, sitä kauempana seinien etäisyyden aiheuttama voimavektori saa vaikuttaa.

Eli mikä tai mitkä olisi tässä se periytyvä komponentti? Monissa internetin evoluutioalgoritmiesimerkeissä, joissa liikkuminen on jonkun evoluutio-objektin perityvä ominaisuus, peritään kylmästi vain vakiokokoinen voimavektori, mutta voiko se olla vakio myös tässä tapauksessa? Jotenkin ajattelisi että sen voimakkuuden pitäisi elää sitä mukaan, mitä lähempänä tai kauempana seinästä ollaan.

Luonnonvalinnan perusteella kelpoisin auto voisi olla sellainen, jonka kulkema matka lyhimmässä ajassa on suurin eli nopeus olisi suurin, eli sellaisten yksilöiden jälkeläisiä syntyisi eniten. Toisin ei varmaan ihan tällä selviä, sillä nopeasti seinään ajavat olisivat tällä perusteella myös kelpoisia, mitä emme luonnollisesti halua.

Mulla on algoritmi kasassa täällä: https://editor.p5js.org/lazydistribution/sketches/dRyjs1clO (https://editor.p5js.org/lazydistribution/sketches/dRyjs1clO). Nyt tuo ratkoo nk. Knapsack-ongelmaa (https://en.wikipedia.org/wiki/Knapsack_problem). Knapsack-ongelma on lasekennallisesti NP-ongelma (https://en.wikipedia.org/wiki/NP-completeness), eli ongelma, jossa kaikkien ratkaisujen järjestelmällinen läpikäyminen on usein mahdotonta, ja jossa siksi oppiva systeemi todennäköisesti löyttää parhaimman kombinaation nopeammin. Mutta kyseinen koodi on taivutettavissa muidenkin ongelmien evolutiiviseen ratkomiseen. Evoluutioalgoritmi on pääpiirteiltään seuraava:


1: list of solutions. In this example they can be either 1 or 0

2. function to generate new population

3: fitness function to evaluate results

4: selection function to select next generation to generated

5: crossover function

6: mutation function
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 10, 2020, 15:56:24
^
jos tossa perityviä tekijöitä olisi kaksi. Ensimmäinen kokonaisuus koskisi randomeita voimavektoreita ja toinen kokonaisuus, mille indeksille osuvaa voimavektoria milloinkin käytetään riippuen etäisyydestä seinään.

Ei kun tekoäly. Mikä tekoäly löytää fiksuimman tavan suhtatua seiniin ja eteenpäin kuljettuun matkaan on kelpoisin. Eli kyllä tämä edellyttää tekoälyn luomista. Tuo aiempi olisi karvalakkiversio tästä koska siinä arvot ovat muuttumattomia. Tekoäly voisi ehkä päätellä tarvittavat voimavektorit itsenäisesti. Tosin en ole varma onnistuuko tämä. Pitäisi olla itseoppiva tekoäly. Tähän asti olen tutustunut vasta opetettavan tekoälyn algoritmeihin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 13, 2020, 16:36:23
Googlella on tarjolla ainakin Colaboratory Notebooks -lisäosa Google driven kylkeen pyyttonia varten, jossa pääsee ilmatteeksi käyttämään ainakin jonkun verran Googlen GPU tai TPU laskentatehoa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 08, 2020, 15:35:55
Lainaus käyttäjältä: Jaska - lokakuu 08, 2020, 15:25:22
Lainaus käyttäjältä: Jaska - syyskuu 20, 2020, 17:05:13
...
Keijon sivusto on viime vuodet ollut Googlen käyttöön tarjoamassa kotisivutekniikassa. Googlen oman informaationsa julkaisemiseen hankkima kotisivutekniikka on yrityspuolelle käytettävissä nimellä G Suite ja henkilöpuolelle Google Sivustot (Google Sites). ...

Google vaihtelee kaiken aikaa palveluidensa nimiä. Nyt G Suiten nimeksi on vaihtumassa  Google Work Space. Kumpikaan ei ole pelkkä sivustotekniikka vaan maksullinen kokoelma Googlen palveluita - joista Sivustot on yksi - jotka ovat suppeampina tarjolla ilmaiseksi myös kuluttajille

Oletko tutustunut github (https://github.com/)in tarjoamaan ilmaiseen verkkosivu-vaihtoehtoon? Osoite on siellä muotoa: username.github.io

Github on tarttunut mulla mukaan sen vuoksi, että työn puolesta meillä on gitissä vesionhallinta. Vaikka meillä ei ole työnpuolesta sivuja githubissa hostattuina, sen kuitenkin saa myös hostaamaan ja ainakin yhden ilmaisen verkko-osoitteen per käyttäjä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - lokakuu 09, 2020, 01:20:37

Keijon sivuja ajatellen Googlen sivustojen tekniikanvaihdossa riesana on
- tekniikanvaihdon oleellinen pyrkimys oli tehdä sivuja jotka mukautuvat eri laitteille. Esimerkiksi isoa määrää leveitä sanataulukoita ei helposti saa kännykän ruudulla katsottavaksi. Koko taulukon tukikin on poistettu uudesta tekniikasta
- ulkoasun mahdollisuuksia on karsittu rajusti joten Googlen muunnos ei edes voi tuottaa entisen näköistä sivustoa
- käytännössä tarvittaisiin hyvä webbisivujen rakentamisen osaaminen html:llä vaikka se ollaan piilottavinaan (minulla ei kehuttava)
- javaskriptiä voi periaattteessa upottaa sivuihin frameissa, mutta en ole onnistunut. Framessa ei nähdä sivussa kehyksen ulkopuolelle
- sivun rakentaminen on aikamoista "yritä ja epäonnistu" puuhaa, kun sivunrakennuskone ei toimi virheettä
- minulla on niukasti aikaa tuohon askarointiin enkä ole motivoitunutkaan Google Siteen perehtymiseen. Dokumentointi ja ohjeistus lähinnä puuttuu
- toiseen tekniikkaan vaihto ei myöskään kiinnosta. Tämä on ollut ihan harrastelua vain
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 09, 2020, 01:33:18
Tarjoaako muuten noi Googlen sivustot myös tietokannan?

En ole tutustunut Githubin spekseihin riittävän hyvin tietääkseni, tarjoavatko ne, mutta mikäli olen oiken ymmärtänyt, Github ei ylläpidä tietokantaratkaisuja. Sivusto kun on ylipäätään rakentunut versionhallinnan ympärille ja kun sivun houstaus on sekin vasta varsin tuore lisä en näe tietokantaratkaisujen oikein palvelevan alkuperäistä ideaa. Mutta kuten todettu, en tiedä mikä Githubilla on asiassa politiikka.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - lokakuu 09, 2020, 05:37:50
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - lokakuu 09, 2020, 01:33:18
Tarjoaako muuten noi Googlen sivustot myös tietokannan?
Ehei, ei mitään niin konstikasta. Sivu koostuu otsikko-osasta ja osastoista, joissa on kuvia ja tekstejä. Fontti- ja värivalikoima on minimaalinen. Voidaan upottaa kehyksiä. joihin  tehdään HTML:llä konstikkaampaa sisältöä. Systeemi tekee sivusta omat esitysmuodot tietokoneelle, tabletille ja puhelimelle.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 22, 2020, 19:34:40
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - lokakuu 22, 2020, 18:40:21
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - lokakuu 22, 2020, 14:23:35
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - elokuu 28, 2020, 04:45:02
Mulla on tässä joku ~50 Mbps -nettiliittymä. Haluaisin gigan nettiliittymän. Taloyhtiön kaapelia pitkin vaikuttaisi olevan tilattavissa kuitenkin vain max 300 Mbps. Kannattaako hommata gigan mobiililiittymä ja siihen sopiva mobiilireititin? Onko tuollainen gigan mobiiliyhteys kuinka hyvä sijoitus vai kannattaako idea kuopata alkuunsa?

Kolmas päivä kun olen ladannut ilmaisia soitinääniä. Noita on ollut useampi giga. Nyt olisi ollut nopeammasta nettiliittymästä hyötyä. Latausnopeus mulla on - kun kuuntelen samalla musiikkia ja surffailen somessa - joku 30-34 Mbps. Tietenkään yksittäistä pakettia harvoin saa ladattua muutenkaan nopeammin kuin ehkä korkeintaan sen 4-5 Mbps, mutta kun kovin montaa pakettia ei voi samanaikaisesti laittaa lataukseen mun kaistaleveydellä, ettei mene netiyhteys täysin tilttiin.

Tosin noita ääniä on nyt ensinnäkin ihan perkeleesti ja toisekseen samantyyppisiä ääniä löytyy ties minkälaisiin kansiorakenteisiin jemmattuina.

Ainakin osa äänitiedostojen nimistä sisältää soittimen nimen, että ehkäpä jonkinlainen ohjelma olisi mahdollista kirjoittaa, joka keräisi ja sijoittaisi noiden soittimien nimien perusteella äänet omiin kansioihinsa.

Koska en tunne kaikkia alan termejä, pitäisi varmaan ensiksi kirjoittaa ohjelma, joka luokittelee samanlaisen kirjoitusasun perusteella äänitiedostot ryhmiksi. Näin minun ei tarvitsisi opiskella kaikkia alan termejä itse ainakaan vielä tässä vaiheessa musiikkiharrastustani.

Tuo luokitteluohjelma on kyllä tällä hetkellä minulle liian vaikea taski repästä stetsonistani. Löytyiköhän jokin tuollainen luokittelualgoritmi jostain valmiiksi, jonka voisi kopioida omalle koneelle, jotta ei tarvitsisi tuhlata niin paljon aikaa asiaan?

Toisaalta tämä olisi kyllä oiva paikka harjoitella luokittelutekoälysovelluksen kirjoittamista. En kuitenkaan ole tekoälyopinnoissani niissäkään vielä niin pitkällä, että tällaiset luokittelualgoritmit olisivat tulleet käsitellyiksi. Mutta mulla on kyllä käsittääkseni ostettu Udemystä yksi tekoälykurssi, jonka aikana uskoakseni käydään luokittelualgoritmi(t) läpi. Tai jos ei löydy kyseisestä kurssismateriaalista, ei se kamalan kallista (yleensä) ole ostaa kurssia Udemystä, jossa asia käydään läpi.

Jos otan tästä itselleni tekoäly-taskin nyt, ja jos algoritmin kirjoittaminen/tekoälyn opettaminen ei käy käden käänteessä, musan tekemisen harjoittelu siirtyy hamaan tulevaisuuteen. Kaiken rehellisyyden nimissä tilanne on kuitenkin se, että käytännössä musiikin tekemisesssä pitäisi opetella noiden virtuaalisoittimien käyttö, jotta ei olisi riippuvainen näistä valmiista soittimien äänistä. Mulla on muutenkin ideoita päässä, miltä kappale tai jotkin sen äänet voisivat kuulostaa, mutta kun ei löydy prikulleen oikelanlaisia ääniä tai efektejä näistä valmiskirjastoista. Tai oikeamamin vaikka löytyisikin, mistä vitusta noviisi pelkän randomin tiedostonimen perusteella tietäisi, että kappas' tätä olenkin etsinyt. Että ennemmin tai myöhemmin on ryhdyttävä joka tapauksessa opetteleman noiden virtuasalisoittimien käyttöä ihan tosissaan, sikäli jos musiikkiharrastukselle haluaa tulevaisuuden.

Mutta tämä luokittelualgoritmi olisi kyllä ihan mielenkiintoinen haaste. Extrana voisi sitten joskus kirjoittaa luokitteluohjelman, joka kävisi tiedostojen musiikkidatan läpi ja luokittelisi tiedostot äänen tyylin perusteella omiin ryhmiinsä. Sellainen luokittelutapa olisi siis se ideaali tässä. Mutta koska laskentatehoa taikka taitoja ei ole riittävästi, äänidatan analysointiin kykenevä tekoäly jää tällä erää tulevaisuuden haasteeksi.

Tai hetkinen, ehkäpä löytyy joku kaupallinen palvelu jostain, joka tarjoaisi tällaisen äänen tyylilajin perusteella tapahtuvan luokittelun kohtuuhintaan? Toi löytyyköhän sittenkään? Muistelen nimittäin, että varsinkin jos äänitiedosto on pitkä, laskentateho ei yksinkertaisesti vielä nykymaailmassa riitä millään tietokoneella tekoälyn harjaannuttamiseksi tehtävään. Sama ongelma tekstin analysoinnin kanssa; onelinerit on helppo luokitella, mutta twiitti alkaa jo olla siinä rajoilla, että onnistuuko luokittelu enää. Tosin nää soittimien äänet ovat muutaman sekunnin pätkiä korkeintaan, että näihin saattaisi jonkun tehokkaan koneen laskentateho jo nykyään riittääkin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 22, 2020, 19:54:08
^

https://moises.ai/ periaatteessa tekee tuon tai ainakin jonkinlaisen luokittelun ja ainakin normisoittimien osalta. Pitäisi vaan saada käyttöön versio, jolle syötetään yhden äänitiedoston - jossa kaikki äänet sekaisin - sijaan lukuisia ääniä omissa tiedostoissaan takaisin ja ohjelma kertoisi, mikä äänitiedosto sisältää minkäkin instrumentin/äänen.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 22, 2020, 20:06:17
^
tässä on ainakin lupaava otsikko: Sound Classification with TensorFlow (https://www.iotforall.com/tensorflow-sound-classification-machine-learning-applications) (Tensorflow on googlen käyttämä tekoälykirjasto, joka on tekoälykirjastoista yksi suosituimmista)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 22, 2020, 20:33:53
^jos oikein ymmärsin tuossa musiikki on oma ryhmänsä. Mikä on tietysti aivan liian epätarkka luokka sikäli kun kaikki instrumentit todennäköisesti äänitiedostoissa menisivät kyseisen otsakkeen alle. Tässä tarvittaneen ohjaamatonta oppimista, jossa kone itse ryhmittelee. Tuossa olisikin listaa läpikäymiseksi ja oikean ryhmittelymenetelmän löytämiseksi -> https://en.wikipedia.org/wiki/Unsupervised_learning#Approaches mikäli tämä menee siihen, että pitää tuo softa kirjoittaa kokonaan itse.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 22, 2020, 21:10:52
^
äänten luokittelu ohjaamattomalla oppimisella on haettaessa kaiketi niin uusi innovaatio, että kaikki löytämäni linkit ohjaavat lähinnä tieteellisiin artikkeleihin, joissa jokaisen abstrakteissa ollaan varovaisen optimistisia, että ohjaamaton oppiminen voisi olla hyvä lähestymistapa äänten luokitteluun. Sen enempää nuo abstraktit kuin itse artikkelitkaan eivät minua auta, koska matemaattinen notaatio ei ole minulla niin hyvin hallussa, että ymmärtäisin papereissa esitettyjen kaavojen yhteydessä, että mitä niissä tarkalleen otaen lasketaan. Matemaattinen notaatio kun on vielä hyvin kaukana siitä, miten nuo laskut kirjoitetaan tietokoneen (ja minun) ymmärtämään muotoon.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 22, 2020, 22:16:49
^

Ilmeisesti tässä olisi käytettävä restricted Boltzmann machine -kompositiota nimikkeellä (Convolutional) Deep Belief Neural Network. Tämä systeemi - jos oikein ymmärsin - on taitava kuvien luokittelussa. Edellyttääkö tämä, että äänitiedosto muutetaan jonkinlaiseksi kuvadataksi, jonka pikselit sitten vedetään kyseisen Deep Belief -neuroverkon läpi?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Melodious Oaf - lokakuu 22, 2020, 23:44:52
^

Toi kuulostaa aika vaikealta ratkaisulta. Oletko varma että sulla on siihen oikea ongelma?

Onko ongelma se, että kuulet päässäsi jonkun tietyn soundin, tietäisit soittimien nimiä, mutta et löydä juuri oikeita softasoittimia?

Vai oliko se niin, että sulla on vähän vastaavanlaisia soittimia eri nimillä eri kansioissa ja kansiohierarkioissa ja haluaisit keskenään vastaavanlaisia nopeasti vertailtavaksi, jotta hyvän soundin löytäminen helpottuu?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 23, 2020, 00:42:07
^

Joo tuo spekuloimani on vaikea ratkaisu ja sanoinkin tuonne tämän episodin alkuun, että mun taidot eivät tällä hetkellä riitä tuollaisen aikaansaamiseksi kun tai paremminkin kun taitoni eivät riitä vielä siihenkään, että tekisin ohjelman, joka ryhmittelisi tiedostonimet samankaltaisten nimien perusteella.

Mä siis latasin juuri monta gigaa ilmaisia wav-tiedostoja eri sample-valmistajilta, jotka tarjoavat demopaketteja valikoimistaan ilmatteeksi koepalloiksi. Eri valmistajilla on keskenään eri kansiorakenne ja nimeämistapa tiedostoilleen. Jollain on soittimen nimi kansiossa ja tiedostonimet kansion sisällä epäkuvaavasti geneerisiä tyyliin "001_sound.wav" ja osassa kansion nimi voi olla joko "loop" tai "one shot" ja tiedostonimessä soittimen nimi jossain kohtaan tyyliin "01_kickA.wav". Siis parhaimmissa tapauksissa. Osassa kuitenkaan kansion nimestä tai tiedoston nimestä ei voi päätellä onko kyseessä loop vai one shot tai edes sitä, minkälainen soitin tai ääni kyseessä.

Nää pitäisi saada järjestykseen, josta kävisi nopeasti selväksi, mitkä samplet ovat keskenään saman kuuloisia. Pääsisin myös eroon keskenään toisistaan poikkeavista kansiorakenteista ja nimeämistavoista. Muutenkaan kaikki näistä äänistä eivät ole soittimien ääniä suoraan vaan ne voivat olla raskaastikin syntetisoituja ja myös nämä olisi syytä saada jotenkin luokiteltua. Tavoite olisi, että kun kuuntelen yhden filun kansiosta, tietäsin tyylilajin, jollaisia äänet kyseisessä kansiossa ovat. Sitten vain nimeäisin kansion kuvaavalla nimellä ja jatkossa tietäisin mistä hakea minkäkintyyppisiä ääniä.

Toki tässä on vielä sekin ongelma tuon tekoälyohjelman kanssa, että vaikka tietokone osaisikin jakaa äänitiedostot samankaltaisuuksien perusteella ryhmiin, useimmissa tapauksissa kone ryhmittelee eri perustein kuin ihminen, sillä kone käsittelee erinäköistä dataa kuin ihminen luonnonilmiöitä ryhmitellessään, mutta koko tämä tekoälyjuttu tosiaan ei ehkä ole tämän hetken ongelma muutenkaan.

Tämä ei nimittäin varsinaisesti liity siihen, että kun mulla on mielessä saundeja, joita tarvitsisin mutta en löydä. Kaikki visioimistani saundeista eivät ole välttämättä suoraan edes soittimien ääniä vaan vähintään vahvastikin koneellisesti sämplättyjä. Se että saisin näppärästi kyseisiä saundeja keskittymiseni herpaantumatta, edellyttää todennäköisesti, että opettelen käyttämään käytössäni olevan LMMS:n -ohjelman instrumenttia, jolla voidaan ainakkin mainospuheiden perusteella tuottaa ihan millainen ääni tahansa jos sitä vain osaa käyttää.

Olen huomannut, että kun selaa noita sämplefiluja eikä löydy välittömästi oikeaa ääntä, kohta olen jo unohtanut millaista ääntä lähdin alunperin edes etsimään. Järkeilen että jos taas voisin muokata yhtä ääntä oikeaan suuntaan tietäisin kokoajan mitä etsin, kun ääni muuttuisi kokoajan lähemmäksi tavoitetta.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Melodious Oaf - lokakuu 23, 2020, 19:49:58
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - lokakuu 23, 2020, 00:42:07
Olen huomannut, että kun selaa noita sämplefiluja eikä löydy välittömästi oikeaa ääntä, kohta olen jo unohtanut millaista ääntä lähdin alunperin edes etsimään. Järkeilen että jos taas voisin muokata yhtä ääntä oikeaan suuntaan tietäisin kokoajan mitä etsin, kun ääni muuttuisi kokoajan lähemmäksi tavoitetta.

Toi on hyvä kuvaus ongelmasta.

En osaa hyvin neuvoa, kun erittäin harvoin käytän mitään sampleja ja vissiin ajattelen aika pitkälti perinteisten soitinten pohjalta.

Mutta yksi ongelman syy on se, että oot ladannut ison määrän kaikenlaista sekalaisesti järjestettyä. Mulla on käytössä Logic, ja siinä (oletan että myös muissa ohjelmissa) ohjelmiston omia looppeja ja sampleja on tägätty valmiiksi niin, että samanlaiset soundit löytyy samoista kategorioista, kun niitä selaa.

Käsin täytyy tehdä jonkinlainen erottelu erilaisten äänityyppien välillä. Mutta oisko se jotenkin helpompaa, jos lisäät studio-ohjelmaan omia untagged sampleja. Ne saattaa mennä kaikki vaikka samaan hakemistoon, ja sitten käyt kerran käsin läpi ja luokittelet.

Tietysti siinä pitäis sen verran tuttuja olla ne eri tyypit, että tietäis mitä ne on ja miten ne haluaa luokitella tai kannattaa luokitella.

Jos saisit jostain foorumeilta tai videoista tai jostain selville, minkälaista metodia jotkut sun kanssa samaa hommaa tekevät on käyttäneet, se saattais auttaa tossa. Mä en usko että niiden kaikkien samplejen jakainen uudestaan hakemistoihin on oikeasti mikään järisyttävän iso homma.

Mun on myös vähän vaikea samaistua tohon että kuulee päässään tietyn soundin ja sit hakee just sitä. Mun kokemus on, että aina on tiettyjä rajoitteita joiden puitteissa toimitaan. Totta kai pitää ensin osata jotain ja tietää jotain. Tyyliin että osaan soittaa tällasta peukkubassoa, tai että jos laitan tällasen kaiun, se tekee sitä ja tätä. Siinä muodostuu tietty osattujen asioiden repertuaari, joita voi käyttää luovassa prosessissa, ja luovaan prosessiin kuuluu olennaisena osana myös ne rajoitteet. Että toimit sen puitteissa mitä osaat ja tiedät -- ja sit taas toisaalta erilaiset vahingossa keksityt jutut ja muut vastaavat :D

Mitä toi nyt sit antaa tähän? No. Jos lataat vaikka 13 teraa sampleja, ei siellä välttämättä ole sellaista kuin olit mielessäs miettinyt. Ja sulla voi myös olla liikaa vaihtoehtoja. Jotkut kai tekee konemusaa silleen että ne ensin mikrofoniin ääntelee sitä ideaansa, ja sit yrittää softainstrumenteilla ja muulla rakentaa sitä sen jälkeen. Tää nostaa sellasen idean esiin, että voitko sä kehittää jonkun tavan saada esimerkiks tietyn idean aivan viitteellisesti taltioitua silleen että muistat sen perusteella, mitä siihen piti tulla. Sit jos se prosessi ja vertailu tai muu hieman venähtää, se ei välttämättä enää tukahduta koko sitä toimintaa aivan samalla tavalla.

Mut noita tekemisen tapoja on niin monia, että ei toikaan mikään absoluuttinen idea oo. Aivan varmasti sellanen tapa voi olla myös, että etsii aluks nimenomaan jotain soundia ja semmosta että joo, tää kuulostaa nyt aika hyvältä, ja siitä sit lähtee se biisin tai muun vastaavan rakentaminen. Esimerkiksi J. Karjalainen taitaa olla vähän ton tyyppinen biisintekijä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 23, 2020, 20:20:51
^

Hyviä huomoita, kiitos. Mä oon laittanut noi lataamani sämplefilukansiot omaan kansioon, jotta tiedän mitkä ovat tän LMMS-softan omat oletusasennuksen yhteydessä tulleet filut ja mitkä on näitä mun lisäämiä filuja. Noita lataamiani sämplefiluja vaan on niin helvetisti, että en ajatellut ryhtyväni niiden manuaaliseen parsimiseen omiin tyllilajinsa mukaisiin kansioihin. En ole vielä keksinyt miten tulen niitä hyödyntämään vai tulenko ollenkaan.

Tuota "J. Karjalaisen tapaa" tässä itsekin haen, mutta se edellyttää, että osaan käyttää koneen virtuaali-instrumentteja yhtä hyvin kuin J. Karjalainen perinteisiä instrumentteja. Siihen mulla on vielä matkaa, mutta se polku on varmasti aika pitkälle kuljettava, jos haluan toteuttaa visioitani Karjalaisen tapaan.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 20, 2020, 22:47:00
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - joulukuu 20, 2020, 21:41:59
^
Vittu kun tekisi mieli jatkaa tuon ongelman ratkomista. Päivän mittaan pulpahtanut mieleen uusia ideoita, joita olisi kiva kokeilla. Saatana.

Ajatus on siis rakentaa yhden asiakas-applikaation asetusten asettamiseen ja säätämiseen tarkoitettu webbikäyttöliittymä ilman React- tai Vue- kirjastoja. Kyseiset kirjastot ainakin olisivat aavitusken verran overkill. Tarve tällaiselle syntyy siitä, että muutamien asiakas-applikaatioiden asetukset pitää laittaa manuaalisesti suoraan tietokantaan, mikä on hyvin riskialtista ja minkä turvallisen käyttämisen osaamista ei voi edellyttää ellei tunne tietokantojen toimintaa riittävän hyvin.

Meillä on joitain tällaisia projekteja, joissa ei ole asetusten tekoa varten näppärää käyttistä ja ne vievät aikaa esimerkiksi minulta tai muilta kehittäjiltä aina kun asetuksiin halutan muutoksia. Meillä on esimerkiksi kymmeniä asiakkaita yhdessä tällaisessa ongelmatapauksessa ja 15%-20% minun työstäni on tällä hetkellä jo tuon yhden projektin asetusten säätämistä, mikä ei ole ideaalitilanne lainkaan, sillä olen ensisijaisesti ohjelmoija enkä tekninen tuki, ellei kohdatut ongelmat edellytä juuri ohjelmointiosaamista.

Simppeleitä webbilomakkeita oppii käyttämään lähes kuka tahansa ja jotta teknisen tuen ei tarvitisisi meillä toimia teleoperaattorina asiakkaan ja minun välillä, olisi hyvä, että tekninen tuki voisi suoraan säätää asetuksia, jos asiakas ottaa yhteyttä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 20, 2020, 23:20:56
^
kaksi isompaa haastetta on navigointi ja dynaamisesti muuttuva lomake. Periaatteessa lomakkeen voisi tehdä staattiseksi sekoittamalla php-koodit html-koodin sekaan, mutta koska backend on api, staattinen html-sivu ei oikein tule kyseeseen.

Navigointihaasteeseen keksin päivällä ideoita mutta tuo lomakkeen oikeanlainen dynaaminen muuttelu edellyttää vielä hiukka sulattelua.

Päivän ideat liittyivät siis navigointiin: päivitän sivun url-osoitteen vain get-komentojen yhteydessä ja post-komennot toimivat vain taustalla. Näin sivuilla ehkä voi surffailla osoiteriviä muuttelemalla edes takas ilman ongelmia.

Sivujen lomakkeiden dynaaminen rakentelu on vielä mietintämyssyn alla. Periaatteessa pitää vain pystyä generoimaan tietynlainen lomake tietynlaista nappia painettaessa ja tiettyyn paikkaan, mikä tuskin on vaikea taski. Enempi tulee ehkä haastetta datan hallinnassa eli kaikki kentät pitää nimetä niin, että tietojen luku voidaan automatisoida backendissä mahdollisimman kivuttomasti. Nää on näitä tapauksia, joissa pitää keksiä yleinen sääntö ennen kuin kaikkia osasia on välttämättä edes olemassa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 21, 2020, 00:01:34
^
Ai niin ja tokeni. Tokeni pitää tallentaa selaimen välimuistiin asetettavaan keksiin. Ja jotta ei syödä käyttäjän selaimen resurseja, pitää edellinen keksi todennäköisesti poistaa käytöstä ennen uuden keksin asettamista. Käytössäni on jwt-tokeni, joka generoidaan tunniksi eteenpäin joka kerta kun backendia kutsutaan. Jos sivuja päivittää alle tunnin välein, sivuilla pysyy sisäänkirjautuneena vaikka kuinka pitkään, jos taas kuluu yli tunti edellisestä päivityksestä, kirjautuu käyttäjä automaattisesti ulos.

Tää on firman käyttöön tarkoitettu sivu, jota on tarkoitus käyttää firman koneilla. Edellyttääkö GDPR, että myös tällaisessa tapauksessa pitää antaa käyttäjän valita hyväksyykö hän keksien tallentamisen?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 21, 2020, 01:04:36
Voisikohan tuohon tehdä vielä sellaisen tietoturvaratkaisun backendiin, että tiettyä routea voi kutsua vain tietyistä ip-osoitteista (https://stackoverflow.com/questions/36398081/only-allow-certain-ip-addresses-to-register-a-user-in-laravel-5-2). Tyyliin duunin sisäverkosta. Tosin meillä on ympäri maapallon toimintaa ja sisäverkko vain Suomessa. Pitääpä joskus tiedustella, firman verkkoasiantuntijoilta, että onnistuisikohan tällainen ip-rajaus jotenkin vai ovatko työntekijöittemme ip-osoitteet Suomen ulkopuolella mitä tahansa milloinkin. Onnistuessaan tämä rajaisi sisäänkirjautumisen mahdollisuuden vain firman koneille.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 05, 2021, 18:35:47
^
Mä oon tossa joululoman aikana kehitellyt mielessäni tota ja pikkuhiljaa alkaa oleen tuo logiikka pääpiirteittäin selkee.

Meillä on siis järjestelmä, jota laajennetaan plugineilla ja jokainen plugini tarvitsee omat asetussivunsa. Nyt alkaa olla geneerinen lähestymistapa selkeissä tapauksissa kohdallaan asetussivuja varten. Mulla on myös olemassa kaksi poikkeustapausta, joiden kanssa toivottavasti keksin geneerisen tavan käsitellä niitäkin ja selkeästi. Jotain koodia pitää siis aina kirjoittaa tyhjältä pöydältä tulevissakin tapauksissa, mutta jos saan ne keissit selkeästi erotelluiksi omiksi jutuikseen, ehkä tämän voisi yrittää laittaa toimimaan jollekin pluginille, jolta asetussivut vielä puuttuvat.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 12, 2021, 16:25:50
Selvitin miten GuzzleHttp-kirjasto toimii. On yksi prokjekti töissä, jossa pitää optimoida koodia ja tuo kirjasto lienee vastaus kysymykseeni. Projektissa tehdään kymmeniä ellei peräti satoja kyselyitä ulkoiseen apiin ja nyt kun nuo apikyselyt tehdään peräkkäin, siinä menee pahimmillaan jopa minuutti, että kaikki kyselyt on käyty läpi. Kukaan nettiä käyttävä ei kuitenkaan odottele niin kauaa, että selaimessa tapahtuisi jotain. Guzzle mahdollistaa hakujen tekemisen rinnakkain eli sen avulla on mahdollista hakea vaikka kymmeniä hakuja samaan aikaan (mikäli api sen mahdollistaa), mikä nopeuttaa hommia merkittävästi. Pitäisi yrittää kirjoittaa implementaatio projektiin tuota kirjastoa käyttäen ensi viikolla. Kokeilin äsken tässä omalla koneellani, kuinka tuota kirjastoa käytetään ja vaikutti erittäin lupaavalta. Täytyy ottaa kirjasto käyttöön.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 14, 2021, 04:05:19
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 06, 2020, 03:03:02
Vaikuttaa siltä, että homma etenee. Tässä on tarvinnut tehdä hieman kompromissiä sen suhteen, kuinka tarkkaan viivaa seurataan ja kuinka pehmeä viiva rakennetaan. Mun tarttee kyllä tota jotenkin vielä hioa, mutta periaatteessa tämä alkaa riittämään: https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB (https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB). En keksinyt keinoa tehdä tuota interpolaatiota, joten jouduin turvautumaan viivan pyöristäjään se vie nyt saatanasti aikaa että se muodostaa tuon viivan. Pitää tutkia vielä, miten saan tähän interpolaation. Se lienee nopeampia tapa pyöristää rosoisuus kuin tuo käyttämäni viivan pyöristäjä.

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 05, 2020, 18:18:49
^
Nyt on ongelma. Molemmat ääriviivat koostuvat nyt siis pienistä viivoista, jotka ovat keskenään sekaisin samassa listassa. Jotenkin pitäisi nyt kyetä järjestää ääriviivat, omiin listoihinsa ja vieläpä sinä järjestyksessä, kuin ne näyttävät olevan kuvaruudulla.  Kellään ideoita miten?

Meni saatanasti aikaa, että sain ratkottua tämän pulman. Jos tuota ei olisi ratkaissut, nyt käyttämääni viivan pyöristysfunktiota ei olisi voinut käyttää kun se ei olisi osannut yhdistää oikeita pisteitä toisiinsa kun ne eivät olleet järjestyksessä.

Edit: eivät ne kaikki ole järkässä vieläkään mutta riittävän hyvin kuitenkin.

Siirryin tässä marching squares -implementaatioon.

Valmiina
- marching squares
- muotojen ulommaisten ääriviivojen tunnistus

Kesken
- ei tunnista päällekkäisiä muotoja. Eli ympyräradan keskellä oleva reikä jää tunnistamatta
- piirtotyökalu, jolla piirretään autorata

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 16, 2021, 11:06:06
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - maaliskuu 14, 2021, 04:05:19
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 06, 2020, 03:03:02
Vaikuttaa siltä, että homma etenee. Tässä on tarvinnut tehdä hieman kompromissiä sen suhteen, kuinka tarkkaan viivaa seurataan ja kuinka pehmeä viiva rakennetaan. Mun tarttee kyllä tota jotenkin vielä hioa, mutta periaatteessa tämä alkaa riittämään: https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB (https://editor.p5js.org/lazydistribution/sketches/2ZEKC6eFB). En keksinyt keinoa tehdä tuota interpolaatiota, joten jouduin turvautumaan viivan pyöristäjään se vie nyt saatanasti aikaa että se muodostaa tuon viivan. Pitää tutkia vielä, miten saan tähän interpolaation. Se lienee nopeampia tapa pyöristää rosoisuus kuin tuo käyttämäni viivan pyöristäjä.

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - syyskuu 05, 2020, 18:18:49
^
Nyt on ongelma. Molemmat ääriviivat koostuvat nyt siis pienistä viivoista, jotka ovat keskenään sekaisin samassa listassa. Jotenkin pitäisi nyt kyetä järjestää ääriviivat, omiin listoihinsa ja vieläpä sinä järjestyksessä, kuin ne näyttävät olevan kuvaruudulla.  Kellään ideoita miten?

Meni saatanasti aikaa, että sain ratkottua tämän pulman. Jos tuota ei olisi ratkaissut, nyt käyttämääni viivan pyöristysfunktiota ei olisi voinut käyttää kun se ei olisi osannut yhdistää oikeita pisteitä toisiinsa kun ne eivät olleet järjestyksessä.

Edit: eivät ne kaikki ole järkässä vieläkään mutta riittävän hyvin kuitenkin.

Siirryin tässä marching squares -implementaatioon.

Valmiina
- marching squares
- muotojen ulommaisten ääriviivojen tunnistus

Kesken
- ei tunnista päällekkäisiä muotoja. Eli ympyräradan keskellä oleva reikä jää tunnistamatta
- piirtotyökalu, jolla piirretään autorata

Valmiina
- marching squares
- muotojen ulommaisten ääriviivojen tunnistus
- tunnistaa päällekkäiset muodot, eli ympyrän keskellä oleva muoto leikkaa ympyrään reiän.
- turhien koordinaattien minimointi. Voi edellyttää jatkokehittelyä.
- piirtotyökalu, jolla piirretään autorata

Kesken
- jos piirtää rinkulan keskelle ei tunnista enää muotojen reikiä. (Tosin ei niin olennainen koska autorata on yhtenäinen viiva jolla vain yksi uloin ääriviiva.)

https://editor.p5js.org/lazydistribution/sketches/m5Yp7cLe0
Eli tuo on nyt periaatteessa sellainen kuten pitääkin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 17, 2021, 13:32:34
^
vaikea kyllä suoralta kädeltä sanoa, mistä johtuu, että Chromella ja Edgellä tuo pyörii ongelmitta, mutta esimerkiksi Firefoxilla ei.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - maaliskuu 17, 2021, 21:10:43
En pieneen kokeiluun huomannut eroa Chromella ja Firefoxilla piirtäessä (ubuntu). esim kuvio ∅
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 18, 2021, 10:42:47
Jaa, olisikohan windows tässä se ongelma. Kokeilin omalla koneellani (windows) ja sitten työkoneella (windows) niin firefoxilla ei juuri onnistunut.
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - maaliskuu 19, 2021, 19:58:32
Ei ainoastaan koneen, vaan myös yksilön päänsisäinen käyttöjärjestelmä vaikuttaa ohjelmoinnissa.

Lainaus käyttäjältä: https://www.tivi.fi/uutiset/tv/1c363f3a-346e-4ae7-a81b-b2da747242ce?ref=ampparit:affeVaikka ohjelmointikielellä on selkeitä yhtenevyyksiä luonnollisiin kieliin, eivät aivojen kielijärjestelmät aktivoituneet tavanomaiseen tapaan koodeja lukiessaan. Vastaavasti taas ongelmanratkaisukohdassa aivot käyttivät alueita, jotka normaalisti eivät loogisia pulmia käsitellessä aktivoidu. Vaikuttaakin siltä, että koodaus on aivoissa ihan omanlaisensa juttu, joka poikkeaa perinteisestä ongelmanratkomisesta tai kielellisistä rakenteista.

Jäämme odottamaan jatko-osaa: Koodarin aivot II - Huonon softan vastaisku.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 19, 2021, 20:23:41
Lainaus käyttäjältä: ROOSTER - maaliskuu 19, 2021, 19:58:32
Ei ainoastaan koneen, vaan myös yksilön päänsisäinen käyttöjärjestelmä vaikuttaa ohjelmoinnissa.

Lainaus käyttäjältä: https://www.tivi.fi/uutiset/tv/1c363f3a-346e-4ae7-a81b-b2da747242ce?ref=ampparit:affeVaikka ohjelmointikielellä on selkeitä yhtenevyyksiä luonnollisiin kieliin, eivät aivojen kielijärjestelmät aktivoituneet tavanomaiseen tapaan koodeja lukiessaan. Vastaavasti taas ongelmanratkaisukohdassa aivot käyttivät alueita, jotka normaalisti eivät loogisia pulmia käsitellessä aktivoidu. Vaikuttaakin siltä, että koodaus on aivoissa ihan omanlaisensa juttu, joka poikkeaa perinteisestä ongelmanratkomisesta tai kielellisistä rakenteista.

Jäämme odottamaan jatko-osaa: Koodarin aivot II - Huonon softan vastaisku.

Mielenkiintoista tietoa. Tuota tarkkaavaisuuden säätelyä olen huomannut tarvitsevani omassa työssäni paljon. Jos koodaan, en pysty pitämään mielessäni mitään muuta. Jos taas koko ajan on häiriötekijöitä, koodaaminen muuttuu varsin haastavaksi.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - maaliskuu 20, 2021, 01:33:36

Voi sitä joskus tuurillakin ohjelmoida, siis löytää jotain hyviä ratkaisuja, sähläämiseen perustuen  8)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 20, 2021, 02:03:03
Vertaisin ohjelmointia ristisanatehtävien ratkomiseen.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - maaliskuu 20, 2021, 02:31:12

En vertaisi. Ohjelmoidessa minulla on ollut määritelty päämäärä tai tiedostettu tarve, ei pyrkimys jonkun toisen vihjaileman tuloksen tavoittamiseen. Tehdessä saattaa oivalluksia tuloksen ominaisuuksista toki tulla.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - maaliskuu 20, 2021, 07:52:03
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - maaliskuu 19, 2021, 20:23:41
Jos koodaan, en pysty pitämään mielessäni mitään muuta. Jos taas koko ajan on häiriötekijöitä, koodaaminen muuttuu varsin haastavaksi.

Varmaan on paljon ihmisestä kiinni miten paljon häiriöitä sietää. Minulle taas ei koskaan tuottanut ongelmaa siirtyä tehtävästä toiseen ja taas palata tekemään sitä, mikä jäi kesken. Pieni vilkaisu muistiinpanoihin ja niiden avulla "lataan tilanteen aktiiviseksi". Ai mitäkö ne muistiinpanot on? Ihan kynällä ja paperilla tehty pieni merkintä tilanteesta sen jäädessä kesken.

Moni nykyään ei pidä arvossa kynää ja paperia, mutta minulle ne ovat välttämättömiä, jos haluan pääni toimivan tehokkaasti ja haluan muistaa tärkeän asian. Kynä ja paperi on myös tarpeen ohjelman rungon hahmottelemisessa. Piirrän sen yleensä kuvana. En tiedä miten eräajoympäristöön laadittavan ohjelman tekeminen poikkeaa muista, mutta luulisi kaikessa tarvittavan loogisen rakenteen pohtimista. Sitä voisi verrata dekkarin kirjoittamiseen, jossa juonen säikeet on pidettävät kasassa niin, että lopulta on murhaaja selvillä ja pidätettynä.

Joku voisi kysyä, miksi käyttää kynää ja paperia, kun on loistavia piirustusohjelmia, joilla saman voi tehdä. Piirustusohjelmalla tehtynä joku kaavio ei näytä hahmotelmalta, vaan liian valmiilta. Kynällä tehtynä se on todellakin hahmotelma, eikä käy luonnon päälle kumittaa joku kohta ja piirtää uudelleen tai heittää roskiin koko yritelmä ja aloittaa alusta. Piirros ei ole lopputulos, vaan kartta, joka pitää ajatukset oikealla tiellä. Sitä vilkaisemalla on helppo jatkaa siitä, mihin edellisellä kerralla jäi, kun joutui jotain muuta tekemään välillä.


Ei ole tarjota linkkiä, mutta olen joskus jostain lukenut tai kuullut, että perheellisen on paljon helpompi töissäkin sietää häiriöitä ja asiasta toiseen poukkoilua. Kotielämässähän lasten ollessa pieniä päässä oleva moniajo on ihan tuiki tavallista ja pulassa olisi, jos ei siihen pysty. :)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 20, 2021, 10:25:45
Lainaus käyttäjältä: Hippi - maaliskuu 20, 2021, 07:52:03
Ei ole tarjota linkkiä, mutta olen joskus jostain lukenut tai kuullut, että perheellisen on paljon helpompi töissäkin sietää häiriöitä ja asiasta toiseen poukkoilua. Kotielämässähän lasten ollessa pieniä päässä oleva moniajo on ihan tuiki tavallista ja pulassa olisi, jos ei siihen pysty. :)

Jos muistan oikein, niin tutkimusten mukaan ihminen ei juuri moniajoon pysty, ellei se tapahdu laadun ja tai tehokkuuden kustannuksella. On sitten eri asia paljonko keskeyttäminen stressaa ja se stressaa varmasti vähemmän jos on keskeytyksiin tottunut, että sikäli suhtautuminen keskeytyksiin vaihtelee varmasti.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 25, 2021, 13:34:01
https://www.tivi.fi/uutiset/tv/cfea7217-f4da-432d-a962-0a56a69adf10?ref=ampparit:b3a7

Hyvä artikkeli koodaamisesta. Noin 40% työstä menee laadun varmistamiseen.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - maaliskuu 25, 2021, 14:26:38

Viime vuosituhannella olen kirjannut systeemityön viitteelliseksi aikanormiksi
2 kk määrittely
2 kk suunnittelu
2 kk koodaus
2 kk testaus
2 kk käyttöönotto
------------------------
10 kk = 3500 lähdekoodiriviä

Edellä linkattu  TiVin juttu ei minusta kehuja kaipaa
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - maaliskuu 25, 2021, 14:34:16
^
Yleensä määrittelyyn ja suunnitteluun käytetään liian vähän aikaa, jolloin tuloksena on juuri se, että koodauksessa ja testauksessa turhaantuu aikaa paljon enemmän kuin siihen pitäisi kulua ja lopputuloksena on tilkkutäkki eikä kuninkaallinen silkkipeite :)
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - maaliskuu 25, 2021, 14:36:51
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - maaliskuu 25, 2021, 13:34:01
https://www.tivi.fi/uutiset/tv/cfea7217-f4da-432d-a962-0a56a69adf10?ref=ampparit:b3a7

Hyvä artikkeli koodaamisesta. Noin 40% työstä menee laadun varmistamiseen.


Koodaus taitaa olla usein umpihankea. Kun ei ole, on oikeastaan koodiston käyttelyä.

No, olipahan todettu. Joitain eroja koodaukseen kuitenkin liittyy. Nyt on koodausta, ja koodausta. Ei oikein eroa, että millaista viimein on.


Lainaus käyttäjältä: Hippi - maaliskuu 25, 2021, 14:34:16Yleensä määrittelyyn ja suunnitteluun käytetään liian vähän aikaa, jolloin tuloksena on juuri se, että koodauksessa ja testauksessa turhaantuu aikaa paljon enemmän kuin siihen pitäisi kulua ja lopputuloksena on tilkkutäkki eikä kuninkaallinen silkkipeite :)

Kaikista parasta on debugata koodia, jonka toiminnan tarkoitus on sen verran epäselvää, että mielensä suorastaan nyrjäyttää toiseen,... tai ehkä jopa hajanaisempaan tarkastus-uskoon.

Olisiko sitten jokin muoto avoimesta koodauksesta. Mistä näitä aina tietää.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - maaliskuu 25, 2021, 14:52:08
^
Toiminnan tarkoitus ei pitäisi enää olla yhtään epäselvää siinä vaiheessa, kun koodaaminen on aloitettu. Sen pitäisi olla kristallinkirkas jo määrittelyvaiheen lopussa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 25, 2021, 15:11:50
Meidän firmassa määrittely ja suunnittelu tapahtuvat käytännössä koodatessa. Aloituspalaverissa arvioidaan paljon menee aikaa tekemiseen ja aikaa on minun aikanani varattu johonkin projektiin korkeintaan 3 kuukautta.

EDIT: Aloituspalaverissa asiakas antaa siis visionsa, mitä haluaa ja me arvailemme, mitä se tarkoittaa työtunteina koodata. Usein asiakas muuttaa kesken kaiken visioitaan, joten määrittelyä ja suunnittelua ja koodin mahdollista uudelleen kirjoittamista tapahtuu projektin edetessä ja aikaa toki neuvotellaan tuolloin aina päivä, viikko tai pari lisää, mutta tilanne on hyvin usein se, että sellaiset asiakkaat, jotka tietävät mitä haluavat ennen kuin ovat päässeet kokeilemaan alkuperäisiä visioitaan on meidän asiakkaista hyvin harvassa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - maaliskuu 25, 2021, 18:47:52
Kun täältä tukea työtehtäviisi olet etsinyt, niin jonkinlaiselle ns. protoilullehan puuhasi ovat näyttäneet.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - maaliskuu 25, 2021, 18:55:28
^
Minulle tulee noista Hömpän koodaustouhuista aina niin elävästi mieleen tämä klassikkokuva:

(https://humisevaharju.files.wordpress.com/2011/10/keinu.png?w=500&h=428)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 26, 2021, 07:03:06
^
:D
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 26, 2021, 07:57:21
Lainaus käyttäjältä: Jaska - maaliskuu 25, 2021, 18:47:52
Kun täältä tukea työtehtäviisi olet etsinyt, niin jonkinlaiselle ns. protoilullehan puuhasi ovat näyttäneet.

Juu aika vähän täällä käsittelemäni ongelmat koskevat mitään isoja kokonaisuuksia vaan lähinnä vain yksittäisiä ongelmia.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - maaliskuu 26, 2021, 09:04:21
Lainaus käyttäjältä: Hippi - maaliskuu 25, 2021, 18:55:28
^
Minulle tulee noista Hömpän koodaustouhuista aina niin elävästi mieleen tämä klassikkokuva:

(kuva löytyy Hipin alkuperäisestä postauksesta)

Tuo kuva on tosiaan kiertänyt iät ja ajat. Onko "vanhoilla parroilla" käsitystä kuinka kaukaa tuo oikein on peräisin?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - maaliskuu 26, 2021, 09:13:32
Vaikka ei olekaan partaa, niin vastaan silti :)

Minulla on kirja (=sidottu nippu paperia, jotka on kansien välissä) nimeltään Siistiä sisätyötä - Kopiohuumoria vuodelta 1989. Kirjan on toimittanut Ulla Löppönen ja siinä on hyvin paljon sellaisia kuvia, jotka edelleen kiertävät netissä. Monet kuvat ovat vain saaneet sievemmän ulkoasun, sillä kirjan kuvitus on jokseenkin karu.

Kirjasta löytyy mm. iltaloma-anomuksen lomake, Puurakenteinen Turmion tiet - mihin alkoholi johtaa jne jne jne.
Pitääpä lukaista taas kerran, sillä edellisestä kerrasta taitaa olla jo parikymmentä vuotta :D

https://www.booky.fi/tuote/lipponen_ulla/siistia_sisatyota_kopiohuumoria/9789517175715

Samaisessa kirjassa on myös toinen klassikko:

(https://www.kirkonkello.fi/wp-content/uploads/2014/01/projektin-vaiheet.jpg)

Kirjan ilmestymisen aikoihin meidänkin firmassa oltiin todella tohkeissaan projektityöskentelystä. Pomot olivat siitä lukeneet ja ilmoittivat, että  "nyt aletaan tekemään hommia projektityömenetelmin". Lopputulos oli aikalailla tuon kuvan kaltainen, sillä vain työskentelytavan nimitys muutettiin, mutta ei työskentelytapaa ja sillä lähdettiin tekemään erästä valtavaa uudistusta aikataululla, joka ennen kului ns. vuosiylläpitoon. Jollekin oli tullut käsitys, että projektina tehty työ ei vie aikaa juuri ollenkaan. Eihän siitä hyvä seurannut.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Juha - maaliskuu 26, 2021, 09:51:34
Lainaus käyttäjältä: Jaska - maaliskuu 25, 2021, 18:47:52Kun täältä tukea työtehtäviisi olet etsinyt, niin jonkinlaiselle ns. protoilullehan puuhasi ovat näyttäneet.

Joku sen hakemani käsitetyyppilaadun noukkimisessa kunnostautui. Protoilua kuvaavampi voisi olla suoramuotoinen ilmaisu: koodaushaahustelu. Ehkä näitä koodaustapoja on muitakin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - toukokuu 07, 2021, 17:15:54
Ollu työteliäs viikko. Projektina on ollut töissä päivittää yhden systeemin cakephp 1.2 versio cakephp 2.10 versioon. Päivittäminen versiosta 1.3 versioon 2.0 vei neljä työpäivää. Muut versiot työllistivät sitten ehkä reilun päivän. Tähän varattiin hiaman yli 30 työpäivää ja asiakkaalle luvattiin tätä valmiiksi kesäkuun alkuun, mutta sain onneksi tehtyä suurimman työn jo nyt viikossa. Kerrankin on tai ainakin pitäisi olla hyvin aikaa testata ja etsiä ja korjata yhteensopivuusongelmia. Voi tosin olla, että päivitetään tämä myös jo cakephp 3.x versioon samoin kuin voi olla, että php päivitetään 5.4 versiosta johonkin uudempaan, kun kerran näin nopeasti päästiin alkuperäiseen tavoitteeseen.

Kun jo kokeilinkin uudempaa Xamppia, jossa php-versio 7.2 niin se ei osaa enkoodata ISO-8859-1-ääkkösiä oikein, vaikka html-sivulla, php.ini-filussa ja cakephp:n asetuksissa enkoodaus-parametri on asetettu ymmärtääkseni ihan oikein arvolle ISO-8859-1. Jos olen laittanut asetukset oikein ja päätetään ottaa käyttöön 7.2 versio, pitänee käydä yksitellen läpi data, joka liikkuu tietokannan ja sivun välillä, jotta ääkköset tallentuisivat ja näkyisivät oikein, mikä tarkoittaa samalla, ettei noista asetuksista ole mitään hyötyä.

Seuraa myös kolme tyhmää kysymystä. Jos palvelimella on käytössä php 7.2, niin onko siinä jotain rajoituksia, kuinka vanhaa MariaDB:tä voi käyttää? Vai ovatko php:n ja MariaDB:n APIt pysyneet samana tässä vuosien saatossa? Sitä vaan, että pitääkö tuo vanha, ja jo järkyttävän iso tietokanta ajaa uuteen MariaDB:hen tässä samalla kun jos uusitaan php versiosta 5.4 versioon 7.2 tai uudempaan?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - toukokuu 07, 2021, 20:01:37
Jos haluaisi tutustua Javascript-kieleen tai harjata vähäistä ruostunutta osaamista, niin mikä olisi passeli materiaali?

Tällaiseen törmäsin netissä: https://javascript.info/js  Tykkään mukana olevista paikan päällä toimivista ohjelmakoodinpaloista. Ja esitystapakin on selväjärkistä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - toukokuu 07, 2021, 20:29:50
^
toi vaikuttaa pikaisesti silmäiltynä oikein hyvältä.

Opettelin itse joskus Actionscriptin, joka Javascriptin tavoin perustui ECMA-standardeihin. Actionscriptistä siirtyminen Javascriptiin ei siten olut iso taski. Riitti kun etsi googlella Javascriptin varattuja sanoja. Muuten syntaksi oli melkein samanlaista. Joskus luin jonkun O'Reillyn kirjan Javascriptin objekteista, mutta muuten oppinut lähinnä vain googlettamalla apuja eteen tuleviin ongelmiin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - toukokuu 27, 2021, 13:44:33
https://www.kauppalehti.fi/uutiset/kl/c6f3acba-5173-48aa-a40b-6842ea3d081e?ref=ampparit:c7e2

Nyt se on tutkittu. Keskeytysten liika määrä laskee koodarin tuottavuutta dramaattisesti. Tuottavuus kestää kaksi keskeytystä per päivä, mutta ei juuri enempää.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - heinäkuu 03, 2021, 16:32:13
https://lazydistribution.github.io/sceditor-tweet/

Olen tässä yrittänyt hakkeroida hieman tuota SCEditoria, jotta onnistuisiko saada se tukemaan twitter-medikomponentteja kuten se tukee youtube-mediakomponentteja. Tuossa mun kokeilussa on kuitenkin lukuisia ongelmia. Ensinnäkään se ei osaa liittää twitter-komponenttia kuin vain antamalla osoitteen tweettiin twitter-ikonia painamalla ja toisekseen tuo implementaatio lisää twitter-komponentin viestikentän loppuun vaikka sen pitäisi ilmaantua siihen kohtaan, missä kursori on. Tuossa on myös sellainen pulma, että jotta sain tuon toimimaan edes noin, pitää twitter-komponetti rakentaa SCEditorin ulkopuolella body-elementtiin ja siirtää se SCEditoriin vasta kun twiitti on latautunut body-elementtiin.

En ole löytänyt dokumentaatiosta ohjeita, kuinka tavaraa liitetään siihen kohtaan, missä kursori on. Eli tuossa implementaatiossa twiitti upotetaan käyttämällä instance.getBody() (https://www.sceditor.com/api/sceditor/getbody/) -metodin palauttamaa dom elementtiä, johon html-elementti upotetaan kun sen pitäisi käyttää jotain toista metodia. Esimerkiksi instance.insert(...) (https://www.sceditor.com/api/sceditor/insert/) vaikuttaisi olevan oikea metodi, mutta onnistun tulostamaan tuolla tekstikenttään korkeintaan geneeristä objektinotaatiota "[HTMLQuotationElement]" tms.

https://github.com/lazydistribution/lazydistribution.github.io/tree/master/sceditor-tweet

Tuolla on koodit. Implementaatio on index.html-tiedostossa.

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 25, 2021, 02:48:31
Katselin juuri Tensorflow 2.0 Udemy -kurssilla syvästä vahvistusoppimisesta (deep reinforcement learning) teoriaa kaksi ja puoli tuntia. Täytyy sanoa, että kontentti menee orastavan pälvikaljuni yli korkealta ja lujaa. Vihdoinkin Udemy-kurssi, joka ei missään nimessä aliarvioi katselijaansa. Vaikka kurssi on Tensorflow-kurssi, käsittelee kurssi käytännössä tekoälylaskentaa matematiikan kautta sen sijaan, että kävisimme läpi vain Tensorflow-funktioita.

Kurssi onkin siinä mielessä ihan erilainen kuin pari muuta tekoälykurssia, jotka kahlasin läpi vuosi, pari sitten. Siinä missä edelliset kurssit kävivät funktioita läpi ja totesivat funktioiden virittelyn olevan sellaista matematiikkaa, jota ei kurssilla käsitellä, tämä kurssi käsittelee lähinnä pelkkää matematiikkaa ja algoritmeja, koska kurssin vetäjän mukaan on tärkeämpää ymmärtää, mitä tekee kuin vain copypeistata valmista tavaraa. Edellisen kerran kuin olen kuullut jonkun opettajan edellyttävän jonkun taidon oppimisessa asioiden ymmärtämistä, oli kyseessä rakas urheiluvalmentajani, joten tämä Udemy-kurssi onkin jo tehnyt lähtemättömän vaikutuksen minuun ts. kurssin vetäjällä on mielestäni ongelmanratkaisuun ihan oikea asenne.

Koko kurssi on muutenkin sekä huojentava, että inspiroiva.

Se on ollut huojentava siksi, että kouluttaja painottaa ja näyttää kerta toisensa jälkeen, kuinka kaikki data on tietokoneelle lopulta samaa dataa ja toisekseen sitä, kuinka kaikki laskennalliset ongelmat koskevat käytännössä perusalgebralla hallittavaa geometriaa; kuinka löydetään yksi- tai useampiulotteisen kuvaajan alin kohta; tekoälylaskenta on käytännössä geometriaa. Kun on siis onnistunut ensin muutamaan datan oikeaan muotoon ja syöttää sen Tensorflow- ja Keras-funktioille, hoitaa tietokone tekoälylaskennan. Periaatteessa tässä ei siis ole mitään kovinkaan monimutkaista opeteltavaa. Jos vielä lähdetään siitä, että datan konvertoiminen aina yhteen ja samaan muotoon onnistuu, haaste insinööreillä liittyy enää vain siihen, mitä funktioita kannattaa minkäkin ongelman yhteydessä valita, missä järjestyksessä ja kuinka monta kertaa niitä toistaen.

Mistä päästäänkin tuohon inspiroivaan osaan. Jotta osaisi valita valmiista Tensorflow- ja Keras-funktioista oikeat, oikeassa järjestyksessä ja annostellen niitä oikein, pitää ymmärtää mitä ne tekevät. Ja jotta ymmärtäisi, mitä ne tekevät, pitää ymmärtää matematiikka, jota ne laskevat, sillä ilman ymmärrystä, mitä ne laskevat, on valmiiden funktiokokoelmien copypeistailu vähänkään kurssimateriaalista poikkeavien ongelmien kohdalla (kouluttajan mielestä) yhtä tyhjän kanssa. Osaan kyllä päätellä miksi. Uusien ajattelua vaativien ongelmien ratkaisutaitojen opetteleminen on äärettömän inspiroivaa. Pitkästä aikaa voin jopa oppia taitoja, joista on hyötyä muuallakin kuin vain kurssimateriaalin ongelmien kohdalla. Ja tässä kurssissa on paljon jo itsessään materiaalia sekä neuvoja, kuinka ja mistä lähtökohdista opeteltavan matematiikan konsepteja kannattaa lähestyä. Eli kurssi puhuu juuri sillä kielellä, jota minä oppilaana ymmärrän, jos kohta opeteltavat konseptit operoivat vielä ainakin toistaiseksi omaa pohjakoulutustani muutamaa vuosikurssia ylemmällä asteella.

Maksoin kurssista aikoinaan 30-40 euroa. On ollut kyllä hintansa väärti.
Otsikko: Vs: Ohjelmointi
Kirjoitti: kertsi - elokuu 25, 2021, 08:15:34
^
Kiinnostavaa ja informatiivista. Kiitos sepustuksesta.

Tämä oli varsinkin kiinnostavaa, ja menee yli ymmärrykseni: "kaikki laskennalliset ongelmat koskevat käytännössä perusalgebralla hallittavaa geometriaa; kuinka löydetään yksi- tai useampiulotteisen kuvaajan alin kohta; tekoälylaskenta on käytännössä geometriaa" (boldaus minun).

Tuo kuvaajan alimman kohdan löytäminen, onko se jonkinlaista optimointia?

Miten niin nimenomaan (perusalgebralla hallittavaa) geometriaa?

Onko tekoälytutkimuksessa jotain osia, jotka eivät mahdu kognitiotieteen alle, tai joita ei voisi opiskella kognitiotieteen puolella (sielläkin kai käytetään kuvaamasi kaltaisia laskennallisia menetelmiä)? (Kognitiotieteessä on kyllä toisaalta sellaista, mikä ei mahdu tekoälytutkimuksen alle, esimerkiksi kognitiivista psykologiaa, neurotiedettä, kognitiivista semiotiikkaa, kognitiivista kieltiedettä jne.) Eli missä menee raja kognitiotieteen ja tekoälytutkimuksen välillä?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 25, 2021, 13:03:51
^

Tässä kurssin esittelyvideo: https://www.youtube.com/watch?v=bjBequbntXw ja joo kyse on alimman kohdan löytämisessä optimoinnista: https://en.wikipedia.org/wiki/Gradient_descent
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 25, 2021, 14:32:21
Lainaus käyttäjältä: kertsi - elokuu 25, 2021, 08:15:34
Onko tekoälytutkimuksessa jotain osia, jotka eivät mahdu kognitiotieteen alle, tai joita ei voisi opiskella kognitiotieteen puolella (sielläkin kai käytetään kuvaamasi kaltaisia laskennallisia menetelmiä)? (Kognitiotieteessä on kyllä toisaalta sellaista, mikä ei mahdu tekoälytutkimuksen alle, esimerkiksi kognitiivista psykologiaa, neurotiedettä, kognitiivista semiotiikkaa, kognitiivista kieltiedettä jne.) Eli missä menee raja kognitiotieteen ja tekoälytutkimuksen välillä?

Riippuu tekoälytutkimuksen tyypistä. Sellainen osa tekoälytukimusta, jossa mallit pyrkivät jäljittelemään aivojen toimintaa voisi varmaan sijoittaa kognitiotieteen alle, mutta aika usein kun tekoälyssä tiedon prosessointi ja esim. ihmismäiset erheet korjataan tilastomatematiikalla, en ole varma olisiko sitä oikein sijoittaa kognitiotieteen alle sillä kyse on enempi erheettömästä matematiikasta.
Otsikko: Vs: Ohjelmointi
Kirjoitti: kertsi - elokuu 25, 2021, 15:31:27
Kognitiotiede tutkii kyllä myös tietoilmiötä sinälläänkin, ja muidenkin olioiden kuin vain ihmisen tiedonkäsittelyä, eli kaikenlaista kognitiota. Ja erilaisia simulaatiomalleja, neuroverkkoja jne..
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 25, 2021, 16:33:04
^
Tietojenkäsittelytieteessä on kyllä tosiaan paljon päällekkäisyyttä kognitiotieteen kanssa tai siltä se minustakin näyttää. Tietojenkäsittelytiede ottaa tietämiseen kuitenkin varsin radikaalin lähestymistavan rajaamalla sen vain laskennalliseksi ongelmanratkaisuksi.

Ongelma on mielestäni siinä, miten tieto, äly tai oppiminen ymmärretään; antroposentrisesti, mikä antaa mahdollisesti väärän kuvan tietokoneiden tietämisestä, älystä ja oppimisesta, sillä toistaiseksi prosessissa ei ole havaittu kovinkaan paljoa päällekkäisyyttä aivojen tavassa tietää, älytä tai oppia. Tosin tiedämme aivoistakin vielä aika vähän, joten ties vaikka runsaasti yhtäläisyyksiä löytyisikin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 04, 2021, 01:35:03
Ovelasti docker muutti just politiikkaansa. Aiemmin kyseessä on ollut MIT-lisenssillä toiminut open source -projekti, mutta pari päivää sitten muuttivat lisenssiään niin, että jos sitä käyttää liiketoiminnan välineenä tarkoittaen, että yritys on tietyn kokoinen ja/tai liikevaihto on tietty, dockerin käytöstä pitää alkaa maksaa. Meillä on firmassa valmistauduttu koko vuosi ehkä jo kaksi siihen, että siirrämme kaikki palvelumme docker-pohjaisiksi tarkoittaen, että meillä tiettävästi valtaosa projekteista ovat jo docker-pohjaisia, (jotta kehitysympäristö olisi aina tismalleen sama kuin testi- ja tuotantoympäristö). Nyt meni meidän firmassa kertaheitolla speksit uusiksi sillä emme ole - jos oikein ymmärsin - maksamassa Dockerin käytöstä ja se tie nousi siten pystyyn. Saa nähdä, paljonko tämä docker-seikkailu on aiheuttanut meille turhaa työtä ja keksitäänkö tilalle jotain yhtä näppärää.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - syyskuu 04, 2021, 17:27:23
Mikä on docker?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 04, 2021, 17:51:08
Lainaus käyttäjältä: Jaska - syyskuu 04, 2021, 17:27:23
Mikä on docker?

Mä en ole käyttänyt sitä, että en ole ihan varma, mutta se on vähän niin kuin virtuaalikone, muttei ole virtuaalikone. Se ei siis tarjoa paikkaa käyttöjärjestelmälle kuten virtuaalikoneet, mutta tarjoaa virtuaalisen ympäristön tai on tavallaan virtuaalinen käyttöjärjestelmä itsessään ohjelmistoille. Siinä on sellainen kuin contaner, johon ladataan tarvittavat ohjelmat ja sitten sen containerin voi laittaa pyörimään mille tahansa koneelle, jolla on docker, mäkille, linuxille tai windowsille ja container toimii noilla kaikilla alustoilla ilman, että tarvitaan käyttöjärjestelmäkohtaisia asetuksia erikseen säätää projektia varten. Saman containerin mitä on rakentanut windowsilla voi sitten laittaa sellaisenaan pyörimään helposti esim. linux-serverille ilman, että tarvitaan säätää mitään.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 17, 2021, 17:42:58
Opin tänään, että dataa voi palauttaa selaimeen, vaikka laittaa headeriksi jonkun muun http-statuskoodin kuin 200. Olen luullut tähän asti, että manööveri olisi mahdoton. Olin tämän hetken työprojektissani tekemässä yhteen apiin virheilmoituksia sekä dokumentaatiota ja vahingossa huomasin, että näytölle tulee edelleen jsonia vaikka olin laittanut headeriin statuskoodiksi 404. Tätä ominaisuutta olen kaivannut niiiiin monta kertaa projekteissa kuin kuuta nousevaa, sillä tämä avaa mahdollisuuden käyttää virallisia statuskoodeja ja silti palauttaa yksilöllinen virheilmoitus. Viimeinkin! Mitä tästä opimme: ei kannata uskoa ennakkoluulojaan.

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 17, 2021, 18:02:22
^
Tähän mennessä olen kiertänyt ongelman siten, että palautan headerissa normaalin 200 responssin ja erottelen virheet onnistuneista pyynnöistä sitten ajaxin success-funktiossa, johon kaikki http-statuskoodilla 200 varustetut serveriltä palautuvat responssit saapuvat. Tällä uudella tavalla on mahdollista käyttää ajaxin error-funktiota virheiden nappaamiseksi, jolloin saa sovelluksen toimimaan myös semanttisesti oikein. Olenkin ihmetellyt, mihin sitä error-funktiota noin niin kuin tarvitaan... ...ellei sitten ole kehittämässä sovellusta. Itse asiassa tuo, että dataa tulee, vaikka serveri palauttaa error-koodin, olisin voinut päätellä siitä, että kun olen Laravelilla rakennellut apia, niin ajaxin error-funktioon palautuva - olikos se "responseText" - muuttuja sisältää Laravelin vakio-html-sivun virheviestille jos pyyntö epäonnistuu. Mutta kun ei heti hoksaa niin ei heti hoksaa. Mitä tästä opimme: ennakkoluulot ovat varsin ongelmallinen ominaisuus, sillä ne estävät päättelemästä oikeaa vastausta vaikka asian hoksaamisen pitäisi olla ilmeistä.


EDIT: success- ja error-funktiot ovat siis jQuery-kirjaston ajax-funktioita, joita käytämme käytännössä kaikissa firman järjestelmissä, muutamaa oikein vanhaa ja muutamaa tuoreempaa frontend-implementaatiota lukuun ottamatta. Suurin osa järjestelmistämme kun on rakennettu jQuery-aikakaudella.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 17, 2021, 18:54:40
^
Voi hyvänen aika niitä lukuisia pärehimmeleitäni, joilla olen yrittänyt tuoda yksilöllistä virhevistiä näytölle. Aina ei nimittäin ole ollut sellainen palvelu kehityksen alla, jossa olisin voinut palauttaa kaikki virheet status-koodilla 200, vaan on pitänyt käyttää semanttisesti oikeita statuskoodeja. Useimmissa tapauksissa olen tyytynyt vain printtaamaan virheet log-tiedostoon ja kun asiakas on soittanut kohtaamastaan virheestä, joku meidän teknisestä asiakaspalvelusta kysyy kellonaikaa ja etsii serverien joukosta oikean ja katsoo sen log-tiedostosta, että mihin virheeseen asiakas on mahdollisesti törmännyt tai ulkoistaa tämän taskin esim. minulle tai ylipäätään järjestelmän kehittäjälle. Nyt kun jatkossa onkin mahdollista palauttaa virheestä yksilöllinen virheviesti näytölle, asiakas osaa jatkossa antaa jo heti kättelyssä yksilöllisen virheilmoituksen tekniselle asiakaspalvelijalle, jonka perusteella voin katsoa suoraan koodia ja löytää asiakaspalautteen perusteella ongelmakohta sieltä, sen sijaan, että pitää ekaksi metsästää mahdollisesti useita minuutteja log-tiedosta yksilöllistä ja juuri kyseiseen virheeseen liittyvää viestiä.

Meillä on selkeästi backend-porukkaa firmassa suurin osa, sillä tätä frontendin piiriin lukeutuvaa osa-aluetta ei ole mun tiimissä kukaan osannut tai viitsinyt valistaa minua jos vaikka olisikin osannut. Silloin kun aloitin firmassa, siellä oli yksi frontend-osaaja eri tiimissä kuin missä minä olen. Nyt heitä on jo useampia, joskaan yksikään heistä ei ole edelleenkään kanssani samassa tiimissä. Mutta näissä vanhemmissa projekteissa, joita en siis ole ollut mukana kaikkia alusta asti rakentamassa, on luotettu log-tiedostoon, sillä kaikissa niissä käytäntö on tosiaan ollut printata ongelmat log-tiedostoon, ja mitä perinnettä olen kuuliaisesti jatkanut ja sitten kissojen ja koirien kanssa joutunut etsimään sieltä oikeaa aikaleimaa, kun asiakas soittaa kohtaamastaan geneerisestä virheviestistä, josta ei siitä ota välttämättä mitään selvää.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 05, 2021, 15:00:55
Onni on järjestelmä, jota käyttää robotti, joka on riippuvainen IE-selaimesta, ja jota ei ole päivityksen spekseissä mainittu. Just tehtiin iso järjestelmäpäivitys asiakkaalle ja oli sitten käytetty ES6-javascriptiä nykyselainten vaatimusten puitteissa. Luultiin jo, että kaikki meni kivuttomasti, mutta nyt sitten tuli tulipalohälytys, että heidän robottinsa mennyt mukkelis makkelis kun käyttää IE-selainta eikä sivut sillä toimi, kuten pitäisi. Onneksi järjestelmässä ei ole paljoa javascriptiä kun sivu on perinteinen staattinen php-html -sivusto, eli javascriptin downgreidaus onnistui nopeasti ja kivuttomasti. Hyvä, että tuli nyt ilmi. Seuraavan päivityksen yhteydessä mahdollisesti kirjoitetaan koko järjestelmä javascriptillä, joten tiedetäänpähän nyt valmiiksi, mitä pitää spekseissä huomioida. Voisi nostaa hiukka lämpöä jos koko systeemi olisi kirjoitettu nykyisille selaimille sopivalla javascriptillä ja selviäisi, että asiakas tarvitsee IE-sopivan implementaation.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 06, 2021, 14:29:20
Aloitin aamulla duunissa uuden projektin (vanhaan järjestelmään). Kun en keksinyt, kuinka toteutan tarvittavat toiminnot staattiselle php-html-sivulle, rakensin frontendin ja backendin. Haukkasin ratkaisullani hiukka liian ison palasen, sillä tehtävään oli allokoitu alun perin puoli päivää, mutta meni jo nyt ylitöiksi ja huomenna homma jatkuu. No isoin duuni on onneksi jo tehty ja esittelinkin jo projektin tänään tiimille.

Sain hyvät ohjeet, kuinka uutta ominaisuutta halutaan käyttää. Nyt se päivittää tekstiä tietokantaan samalla kun kirjoittaa, mutta ajateltiin, että laitetaan tallennus kuitenkin painikkeen taakse, niin pienempi vaara, että asiakas ylikirjoittaa vahingossa jonkun tärkeän tiedon.

Samaten kun siinä voi nyt kirjoittaa dataa useampaan tietueeseen samaan aikaan, ajateltiin että tehdään näytä-piilota valinta sille päivitetäänkö yhtä tietuetta vai useampaa tietuetta. Tämäkin todennäköisesti auttaa, että ei vahingossa ylikirjoita jotain tärkeää.

**************

Sen verran pieni systeemi, että mitään valmiita frontend- taikka backend-kirjastoja ei ole käytössä, jos kohta frontin puolella käytän kyllä jQuery-kirjastoa backendin kanssa keskusteluun, datan manipilointiin ja sen näytölle tulostamiseen. Backendia esittää ajax.php -sivu ja sen takana tietokantaluokka tietokantatoimintoja varten. Kun ajax.php-sivun toiminnallisuuksia kutsutaan, palauttaa se halutun json-datan. Frontendiä esittää html-templatet html-tietorakenteita varten sekä backendin kanssa keskustelevat funktiot sekä toiminnallisuus, joka muuttaa backendin palauttaman json-datan html-templateja apuna käyttäen html-koodiksi, joka lopuksi tyrkätään näytölle haluttuun paikkaan.

alla hiukka frontin toiminnallisuutta. Voi olla virheitä kun printtasin tämän ulkomuistista, mutta idea kaiketi tulee selväksi

"app"-id:llä varustettu elementti, johon valmis html-tulostetaan ja html-template.

<ul id="app"></ul>

<div hidden id="template-list-item">
    <li>
        <label>
            <span>{date}</span>
            <span>{text}</span>
        </label>
    </li>
</div>


backendistä tuleva json-data

[
    {
        "template": "template-list-item",
        "date": "06.10.2021",
        "text": "Testiteksti 1"
    },
    {
        "template": "template-list-item",
        "date": "07.10.2021",
        "text": "Testiteksti 2"
    }
]


json-datan konvertointi html-dataksi (html-tekstiksi), ja sen tyrkkääminen sivulle

function backendResponse(data) {
    $('#app').html(json2HTML(data));
}

function json2HTML(data) {
    let html = '';
    for(let i = 0; i < data.length; i++) {
        let template = String($('#' + data[i].template).html());
        for(let j of data[i]) {
            if(Array.isArray(data[i][j])){
                data[i][j] = json2HTML(data[i][j]);
            }
            template = str_replace('{' + j + '}', data[i][j], template);
        }
        html += template;
    }
    return html;
}

function str_replace(pattern, fill, str) {
    while(str.indexOf(pattern) !== -1) {
        str = str.replace(pattern, fill);
    }
}


**************************

backendissä ajax.php. Todennäököisesti on virheitä, samasta syytä kuin edellä.

Rajapinta: eli url-osoitteessa lähetetään action-parametrinä funktion nimi, jota kutsutaan ja jolle lähetetään get- ja post-paramentrit

if (isset($_GET['action'])) {
    $action = strtolower($_GET['action']);
    if (ctype_alnum($action)) {
        unset($_GET['action']);
        if (is_callable($action)) {
            $params = array_merge($_GET, $_POST);
            $action($params);
        }
    }
}
json(['data' => 'Not found!'], 404);


rajapintaosassa kutsutun funktion toteutus (palautettavan datan luonti)

function index($params) {
    $date = $params['date'];
    $results = notes::allFromDate($date);
    $output = [];
    foreach($results as $key => $item) {
        $output[] = [
          'template' => 'template-list-item',
          'date' => $item['date'],
          'text' => $item['text'],
        ];
    }
    json($output);
}


json-dataksi konvertointi ja sen palautus

function json($data, $status = 200) {
    switch($status) {
        case 404:
            header('HTTP/1.0 404 Not Found');
            break;
        case 200:
        default:
            header('Content-Type: application/json; charset=utf-8');
            break;
    }
    echo json_encode(deep_utf8_encode($data));
    exit;
}

function deep_utf8_encode($data) {
    if (is_string($data)) {
        $data = utf8_encode($data);
    } elseif (is_array($data)) {
        foreach($data as $key => $item) {
            $key = deep_utf8_encode($key);
            $data[$key] = deep_utf8_encode($item);
        }
    }
    return $data;
}
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 06, 2021, 16:57:16
^
Tuossa yllä siis hieman ideaa mitä systeemiä noudattaen tuon toteutin. Mun toteutuksessa on vielä hiukka kauneusvirheitä ja puutteita. Tietokantaluokka "notes" on huono. Tosin se on valmis luokka ja sitä ei siksi voi mielin määrin uudelleen kirjoittaa. Samaten tietokannan käyttö ja tietokantaan syötettävien muuttujien sanitointi pitäisi hoitaa keskitetysti tietokantaluokassa, kun nyt niihin liittyvää koodia on hiukka joka puolella jo ajax.php-filua. Samaten $action-funktion kutsu rajapintaosiossa pitäisi varmaan laittaa try-catch rakenteeseen ja sitten heittää exceptioneita jos muuttujia sanitoidessa tai tietokanta-ajossa ilmenee virheitä. Näin käyttäjä osaisi infota meidän asiakaspalvelijaa kohtaamistaan virheistä. Tarttee viimeistään johonkin tulevaan rojektiin miettiä näitä muita hienouksia.

addorupdate-funktion on tällä hetkellä suurin ongelma, sillä se on periaatteessa notes-luokan toteutus. Se pitäisi saada suurin piirtein alla olevan näköiseksi: ajax.php-filussa

function addorupdate($params) {
    $date = notes::sanitize('datetime', $params['date']);
    $text = notes::sanitize('string', $params['text']);
    $results = notes::addorupdate($date, $text);
    json($results);
}


ja sitten sanitizen toteutus notes luokassa. Tässä tosin pitäisi sitten lisäksi heitellä erroreita/exceptioneita, mikäli operaatiot eivät onnistu. Mutta alkuun kai joku tällainen voisi toimia. En kyllä osaa käyttää tuota mysqli_real_escape_string-tietokanta-funktiota. En ole varma tarvitseeko mysqli_real_escape_string-funktiota kutsua samalla mysql-objektilla kuin millä suoritetaan itse tietokanta-ajo. Jos pitää, sanitize-funktio ei käy vaan pitää, joka sanitoida muuttujat erikseen ennen tietokanta-ajoa. Ainakin dbo-tietokantarajapinnan käytössä muuttujat sanitoidaan samalla näkyvyysalueella kuin tietokanta-ajo suoritetaan, että voi hyvin olla, ettei mun ajatus tässä kohtaa toimikaan.

public static function sanitize($case, $data) {
    $conn = db_connection();
    switch(strtolower($case)) {
        case 'datetime':
            $data = date('Y-m-d H:i:s', strtotime($data));
            break;
        case 'string':
        default:
            $data = mysqli_real_escape_string($conn, $data);
            break;
    }
    return $data;
}
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 25, 2021, 10:12:51
Meillä ruvetaan töissä värkkäämään jo toista isoa portaalia uusiksi ja valitun kehityspolun perusteella minunkin ehkä kannattaisi ihan tosissaan alkaa opetteleen Pyyttonia. Pyyttonia olen kirjoitellut noilla tekoälykursseilla, mutta niissä se Pyyttonin kirjoittaminen on ollut proseduraalista kun tekoälykurssit eivät varsinaisesti ole olleet pyyttonikursseja. Ja koska tämä meidän uuden web-applikaation backendissä koodi tuskin tulee olemaan proseduraalista, pitää ottaa Pyytton backend-kielenä nyt kunnolla hallintaan.

Uuden portaalin frontend tullaan tekemään Reactilla. React onkin minulle sitten enempi tuttu, mutta tämä tarkoittaa senkin kohdalla, että sitäkin taitoa on syytä alkaa säännöllisesti päivittämään.

Tämä uudistus ei tule ainakaan toistaiseksi vaikuttamaan omiin työprojekteihini, sillä toimin vanhojen PHP-HTML-projektiemme ylläpito- ja kehitystehtävissä, mutta ainakaan näitä nyt mulla vastuualueinani olevia vanhoja järjestelmiä ei tulla ylläpitämään enää vuoden 2024 jälkeen, joten nyt olisi kolme vuotta aikaa ottaa Pyyttoni kunnolla haltuun.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 25, 2021, 10:22:03
^
Tämän uudistuksen jälkeen meillä töissä on vielä ainakin yksi php-html-applikaatio ja yksi hyvin pieni php-html-applikaatio, mutta olettaisin, että näidenkin kohdalla tullaan ennemmin tai myöhemmin siirtymään Pyyttonilla värkättyyn backendiin ja johonkin Reactin kaltaiseen frontend-kirjastoon.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 26, 2021, 14:04:47
^
selvisi että uudistus toteutetaan microservice-periaatteella. Jos olen oikein ymmärtänyt, tämä tarkoittaa, että järjestelmän ominaisuudet toteutetaan kukin itsenäisinä järjestelminä tarkoittaen, että nuo ominaisuudet voidaan toteuttaa millä kielellä tahansa.

Hiukka jo mietinkin, että mitä aikovat tehdä tiimin PHP-koodareille jos siirtyvät Pyyttoniin. Todennäköisesti eivät tee mitään. Toteuttavat kaiketi ohjelman, joka kokoaa ominaisuudet yhdeksi ohjelmaksi Pyyttonilla ja sen jälkeen kukin ominaisuus voidaan ohjelmoida kielellä, joka on olemassa oleville ohjelmoijille tutuin. Eli tyyliin että ominaisuus voidaan ohjelmoida Pyyttonin sijaan esimerkiksi PHP:lla.

Tosin en kyllä otsikkotasoa kummallisemmin tutustunut suunnitelmiin, että en osaa sanoa tarkoittaako Pyyttonin mainitseminen samalla myös sitä, että PHP-koodaritkin siirtyvät pikkuhiljaa kukin Pyyttoniin, mutta pelkästään tieto, että toteutustapa on microservice, sallii ominaisuuksille minkä kielen tahansa, kun pääohjelmaa ei varsinaisesti kiinnosta, miten ja millä kielellä ominaisuudet on toteutettu, kunhan niiden avaamat käyttöliittymät pääohjelmalle ovat pääohjelman tiedossa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 05, 2021, 11:09:00
Pyyttonin opiskelussa ollaan edetty decoraattoreihin tai siis juuri sain käytyä dekoraattori-osion läpi. Decoraattorit olisivat mahdollisia myös javascriptissä. Ihan ekaa kertaa elämässäni tutustuin tässä konseptiin. Nimi on ennestään tuttu, mutta mitään katkua ei ole ollut, miten ne tarkalleen ottaen toimivat. Pyyttonikurssilla konsepti käytiin juuri seikkaperäisesti läpi.

Olen tähän asti opetellut ohjelmoimaan ilman niitä, mutta ottaen huomioon, että varsin usein tulee tehtyä oma funktionsa, joka ohjaa switch-rakenteella ohjelman avainsanan perusteella oikeaan funktioon, olisi mulla ainakin noissa tilanteissa juuri decoraattorin mentävä aukko. Tähän asti on pitänyt aina etsiä ja päivittää erikseen tuota switch-funktiota, jos jossain kohtaa ohjelmaa tarvitsee uuden ohjauksen. Dekoraattori-periaatteella rakennettu funktio voidaan kuitenkin rakentaa pyyttonissa ja javascriptissa niin, että siihen voi tallentaa aina uuden ohjauksen siinä kohtaa koodia missä uusi ohjaus tulee tarpeeseen ilman, että joutuisi decoraattori-funktiota erikseen päivittää. Pitääpä tsekata miten decoraattorit toteutetaan php:n puolella. En siis tiedä sitäkään taipuuko kenties php decoraattoreihin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 06, 2021, 01:34:09
Onko 343 euroa vuoden opiskeluoikeudesta Courseran verkkokursseille hintansa väärti?

Opetuksesta näyttäisi vastaavan yliopistot eri puolilla maailmaa, joten vaikka opettajien ammattitaidosta homma ei kiinni jäisikään, en ole ihan varma osaavatko he painottaa kursseillaan samoja asioita kuin ohjelmoinnin ammattilaiset yksityisellä sektorilla. Tieteellisissä aiheissa voisin olettaa yliopistoilta löytyvän cutting edge -osaamista ohjelmointiin, mutta miten on yksityisen sektorin sovelluskehityksen osaamisen kanssa. En ole yliopistolla opiskellut, mutta ammattikouluissa kylläkin ja niissä kursseilla läpikäydyt yksityisen sektorin kuvitteelliset projektit ovat olleet niin luokattoman heikkolaatuisia, että ei ole ainakaan minulle mikään yllätys, että it-alalla on jatkuvasti huutava pula osaavista ohjelmoijista, vaikka kouluista valmistuu satoja ohjelmoijaspettarilla varustettuja janttereita joka vuosi.

Minun rima on muutenkin vedetty juuri nyt korkealle. Tämä Udemyn ensimmäinen osa neliosaisesta pyyttonin deep dive -kursssista, jota olen käynyt läpi, on sen verran laadukasta tavaraa, että en ole yhtä laadukkaaseen kurssiin vielä koskaan elämässäni törmännyt. Toki tämä on vain minun subjektiivinen arvioni. Jos pyyttoni on hallussa, tämä kurssi voi tuntua pitkästyttävältä. Mutta minun kohdallani kaikki palaset ovat loksahtaneet yllättävän hyvin kohdalleen. Okei, ehkä tässä hiukka liikaa painotetaan itsestäänselvyyksiä, mutta sallittaneen kurssin vetäjälle hieman taiteellisia vapauksia selittää itsestään selvää logiikkaa auki, sillä kaikki ihmiset eivät ehkä täysin hahmota modaalilogiikkaa. Kurssin vetäjä on Fred Baptiste (https://www.linkedin.com/in/fbaptiste), jolla on ammatillista osaamista CNN:n insinöörinä aivan mediamaailman it-osaamisen huipulta ja ainakin minun on helppo nähdä soveltavani näitä oppeja suoraan käyttämilläni kielillä työprojekteissani.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 06, 2021, 04:41:49
Ostin juuri reilulla 200 eurolla udemykursseja (13 kpl). Coursera tuskin tulee ihan hetkeen ajankohtaiseksi :D
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 06, 2021, 21:21:15
Pari viikkoa sitten kun asensin Visual Codeen jonkun pyyttonin lisäpalikan, se ehdotti, että asentaisin pyyttonin koneeseen, vaikka mulla oli jo silloin pyyttoni koneella. En tiedä mitä tässä parin viikon aikana on tapahtunut, mutta nyt kun avasin Visual Coden ja käynnistin kyseisen lisäpalikan, kaikki pelasi niin kuin pitikin ja saatoin ajaa kirjoittamaani pyyttonia ohjelman terminaalissa. Mahtoikohan mulla jäädä pari viikkoa sitten tuo lisäpalikka käynnistämättä(?), se selittäsi. Harmi kun en osaa käyttää sujuvasti Visual Codea niin tällaiset mystiset ongelmat ovat arkipäivää.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 26, 2021, 18:18:44
Tajusin viimein kysyä esimieheltäni, että onko projektissamme mahdollisuutta tallentaa sellaista customoitua logi-tiedosto johonkin paikkaan. Olihan siinä ja nyt sain väsättyä ensimmäisen vedoksen virheloggauksesta. Eli jos ilmenee tilanne, että jossain tietueessa ei ole tarvittavaa tietoa ja ajo pysähtyy sen tietueen osalta, tulee siitä merkintä logiin. Tämä ajo ei olisi niin suuri pulma, jos joku valvoisi sitä, mutta kun se tehdään tausta-ajona, jota kukaan ei valvo. Jos joku tekee pistotarkistuksen kolmannen osapuolen järjestelmään ja meidän järjestelmään ja transaktiot eivät täsmää varastotilanteen kanssa, puuttuvia artikkeleita olisi tai voisi olla työlästä paikantaa. Nyt kun tuosta ajosta jää rekisteriin merkintä jos joku artikkeli ei meidän päästä lähdekään, niin kyseinen artikkeli löytyy ainakin useimmissa tapauksissa suhteellisen näppärästi tuosta logi-tiedostosta.

Pitää tosin vielä logittaa suoritetun tietokantahaun ehdot jos kolmannen osapuolen API palauttaa virheen, niin voimme sitten jälkikäteen ajaa manuaalisesti tietokantahaut ja todeta, missä kohtaa joku tarvittava tieto puuttui tai oli väärää tietotyyppiä.

Olen tätä järjestelmää kehittänyt nyt yli puolivuotta ja olisin kaivannut logitusmahdollisuutta jo aiemmin. Kun on hidas sytytys, pitää tulla toimeen ilman elämää helpottavia tietoja.  :D
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 26, 2021, 21:06:46
Tuli mieleen tuosta Skepsiksen palstan serverin kuormitusongelmia tuottavasta puurakenteesta, että eikö sitä voisi tehdä niin, että viesti-taulussa olisi kenttä, jossa sen viestin id, johon viesti on vastaus. Näin voisi hakea yhdellä simppelillä lauseella halutun viestiketjun kuten nykyisessä systeemissä, mutta kun hakutuloksessa tulisi myös tieto, mihin viestiin viesti on vastaus, selaimessa voisi rakentaa enemmän tai vähemmän helposti tuon puurakenteen. Tosin tämä edellyttäisi backendistä API-toteutusta, johon selain ottaisi yhteyttä. Nyt backend ilmeisesti rakentaa näkymän valmiiksi ennen kuin se lähtee selaimeen.

Tai kun siellä ilmeisesti jo on tuo tieto mihin viestiin mikäkin viesti on vastaus ehkäpä jokaiseen viestiin pitäisi lisätä viestiketjun ekan viestin id. Tuon kentän arvolla voisi simppelisti hakea kaikki viestit, joissa tuon kentän arvo on sama, ja siinä olisi kaikki kyseisen viestiketjun viestit. Nuo frontendiin ja siellä sitten puutoteutus.

Tai ottaen huomioon, että heillä ilmeisesti on tiedot jo tällä hetkellä molemmista rakenteista (viestiketjun kaikki viestit ja mihin viestiin mikäkin viesti on vastaus), herää kysymys, miten ihmeessä tuo tietokanta on toteutettu jos tuon puurakenteen duunaaminen syö resursseja liikaa.

Vai mikä olikaan se Hipin ehdotus tähän ongelmaan?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - marraskuu 27, 2021, 00:22:29
Viestitaulussa on tietenkin vastatun viestin id ja tieto ketjusta missä viesti sillä hetkellä sijaitsee sekä tieto joka ilmaisee viestien talletusjärjestyksen esim. tallettamisen aikaleimana tai nousevasti annettuina tunnisteina.
Kieli pitkällä odotan yksinkertaista ratkaisuasi. Ongelmaa pohdin Tietokoneketjussa (https://kantapaikka.net/index.php/topic,32.msg113917.html#msg113917) ja jäin odottamaan ratkaisua, joka ei olisi resurssisyöppö. Tästä syystähän Skepsis kertoi poistaneensa vastaushierarkian esittämisen käytöstä.
Tehtävähän on ihan klassinen puun läpikäynti esijärjestyksessä, jolla saadaan vastaushierarkia linearisoitua. Tehtävä tavallisesti ratkaistaan rekursiivisilla funktiokutsuilla tai vastaavalla ei-rekursiivisella pinokäsittelyllä ja se tietenkin löytyy netistä hakukoneella.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - marraskuu 27, 2021, 07:51:46
Eipä ole Hipillä ratkaisua, kun kokemusta on vain yhden tyyppisistä relaatiotietokannoista ja käytöstä. Niissäkin ratkaisu voi olla useamman laatuinen sen mukaan, miten kanta on toteutettu ja onko esim. normalisointi viety miten pitkälle.

Joka tapauksessa ideana on kannan suunnittelun yhteydessä suunnitella myös indeksit, joita enimmäkseen tulisi käytettäväksi. Tuossa foorumitapauksessa olisi kaksi vaihtoehtoista indeksiä – toinen, jolla saadaan "päähaulla" haettu data siihen esim. tämän foorumin esitysjärjestykseen ja toinen, jolla saadaan puujärjestykseen. Lisäksihän tarvitsee ehkä tehdä yksittäiseen viestiin liittyvät lisähaut vähän riippuen siitä, miten viestin data on kantaan sommiteltu. [Omassa duunissani voi lisähakuja tulla moneen kymmeneen, jopa pariin sataan, tauluun asiakastunnisteella sen jälkeen, kun ensin asiakkaat on haettu esiin tarvittavassa järjestyksessä eli kaikki asiakkaaseen liittyvät data ei ole suinkaan yhdessä taulussa]

Käyttäjä ilmoittaa foorumille tullessaan, kumpaako esitysmuotoa kyseisellä käyntikerralla haluaa käyttää. Tuo kai on myös mahdollistaa muuttaa lennostakin käyttöliittymässä. Mutta tämä täppä ilmoittaa, kumpaako indeksiä hakutoiminto käyttää. Ja kuten Jaska jo sanoi, niin kunkin viestin rivillä on tieto siitä, mihin viestiin se on vastaus tai jos se on uusi nollatason viesti, niin tämä puuttuu. Lisäksi indeksissä tulisi olla viestin aikaleima, jotta hakutulos pysyisi loogisessa järjestyksessä ajan mukaan.

Tuossa nyt vähän aamuväsyneenä kirjoitettuna ajatus auki tietämättä ollenkaan millainen on ko. fooruminen kantarakenne.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 28, 2021, 17:07:07
Viikonloppu mennyt siinä, että nikkaroinut php:lla mvc-kirjaston nollasta. Sain eilen duunattua kuitenkin myös skriptin, joka tuottaa satunnaisia viestejä, jotka linkittyvät toisiinsa satunnaisiesti ja tietenkin eri järjestyksessä kuin missä järjestyksessä viestit on luotu. Eli vastannee haluttua keskustelupalstatoteutusta. Menin nokkelana tekemään sen javascriptillä. Olisi kantsinut tehdä se php:llä niin konvertointi sql-queryksi ei olisi niin monen stepin takana. Seuraavaksi pitää saada data tietokantaan sekä sen palautus näytölle ja johonkin kohtaan prosessia pitää vielä keksiä se viestin järjestely puuksi ja sitten pääsisi testailemaan tuota serverin kuormittavuutta.

EDIT: Tässä alla poiminta noista lorem ipsum -viesteistä ekan viestiketjun alusta. Eli id-siinä järjestyksessä kun viestit on luotu ja parent_id randomissa järjestyksessä jos kohta kuitenkin valittu jo olemassa olevien id-numeroiden joukosta. Muu sisältö tietueisiin generoituu paria poikkeusta lukuun ottamatta satunnaisesti.
        [
            'id' => 1,
            'parent_id' => null,
            'topic_id' => 1,
            'user_id' => 8,
            'created' => '2020-07-15 05:46:37',
            'modified' => null,
            'user_name' => 'Konsta Kehittäjä',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Ut etiam non arcu duis a at vestibulum quis arcu metus bibendum sagittis amet luctus. Nec sem aliquet lorem massa justo accumsan ultricies commodo a volutpat mollis feugiat aenean. ',
        ],
        [
            'id' => 2,
            'parent_id' => 1,
            'topic_id' => 1,
            'user_id' => 8,
            'created' => '2021-06-13 00:24:50',
            'modified' => null,
            'user_name' => 'Konsta Kehittäjä',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Mauris nunc felis elit nunc vel maecenas habitant dictumst posuere sed mollis volutpat aliquam praesent ac sit suscipit at dignissim nunc fames a. Aliquam tempus pellentesque morbi sit nisi erat nullam justo eu metus diam ut congue scelerisque donec curabitur rhoncus ridiculus ut velit integer massa. Nunc ut posuere sed est amet at at.',
        ],
        [
            'id' => 3,
            'parent_id' => 2,
            'topic_id' => 1,
            'user_id' => 3,
            'created' => '2021-09-29 07:36:07',
            'modified' => null,
            'user_name' => 'Tero Testaaja',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Semper pellentesque ac duis rutrum donec amet diam eros imperdiet eleifend nullam dolor hac tempor fusce proin sed et convallis quam neque urna. Nam amet eros donec tellus vestibulum sollicitudin luctus vitae massa amet dignissim urna quam a turpis aliquam facilisis magna tellus et at vestibulum.',
        ],
        [
            'id' => 4,
            'parent_id' => 2,
            'topic_id' => 1,
            'user_id' => 5,
            'created' => '2020-09-07 23:22:14',
            'modified' => null,
            'user_name' => 'Kaarlo Koodari',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Et facilisis sed curabitur sapien augue luctus tempor purus et lorem. Nibh leo pretium ligula ultrices sem molestie accumsan ornare nunc sit augue euismod tincidunt cras augue justo molestie neque vel turpis sed cras bibendum curabitur vel lacus. Dictumst eget massa porttitor sed ante risus morbi congue. In orci ultrices quis justo phasellus mollis pellentesque nec egestas neque in hac felis id arcu in ultrices ornare velit quis turpis posuere dui. Sit maximus non eget amet nec sollicitudin ultrices elementum neque ut molestie eu ut vestibulum mauris viverra. ',
        ],
        [
            'id' => 5,
            'parent_id' => 1,
            'topic_id' => 1,
            'user_id' => 6,
            'created' => '2021-10-08 12:31:15',
            'modified' => null,
            'user_name' => 'Mirka Merkkaaja',
            'heading' => 'Tempus et hendrerit u',
            'body_text' => 'Sapien eget metus laoreet velit lacus leo ac congue suscipit magna morbi tempor in duis ut nam euismod imperdiet magna finibus ultricies congue.',
        ],
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 29, 2021, 17:08:09
Tässä tein karvalakkiversion. En ole ihan varma miten tuo sql-aika testataan. Ovatko nuo lukemat edes sinne päin?

sql-haun keston  mittasin näin:

        $start_sql_time = microtime(true);
       
        $sql = "SELECT * FROM {$this->table_name}";
        $res = $conn->query($sql, PDO::FETCH_ASSOC);
       
        $end_sql_time = microtime(true);


toi "Sivun latauksen alusta siihen kun sisältö latautunut" riippuu paljolti siitä, paljonko aikaa kuluu, että serveriltä saapuu kaikki data selaimeen.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 29, 2021, 17:18:07
Tässä koodi tuon puun rakentamiselle javascriptillä selaimessa tietokantadatan perusteella. Käytännössä copypeistasin sen täältä: https://typeofnan.dev/an-easy-way-to-build-a-tree-with-object-references/

function treeSort(data) {
    const output = [];
    //console.log(data);
    for(let arr of data) {
        const idMapping = arr.reduce((acc, el, i) => {
            acc[el.id] = i;
            return acc;
        }, {});
        let root;
        arr.forEach(el => {
            // Handle the root element
            if (el.parent_id === null) {
                root = el;
                return;
            }
            // Use our mapping to locate the parent element in our data array
            const parentEl = arr[idMapping[el.parent_id]];
            // Add our current el to its parent's `children` array
            parentEl.children = [...(parentEl.children || []), el];
        });
        //console.log(root);
        output.push(root);
    }
    return output;
}


Toi siis laittaa viesti-tietueen children-muuttujaan viestit, joissa parent_id on kyseisen viesti-tietueen id. Toisessa kohtaa sitten rekursiivisella funktiolla (displayTree) rakennetaan html koodi (alla) ja lopuksi täräyttää tuon koodin näytölle.

function displayTree(tree) {
    let html = '';
    for(let i = 0; i < tree.length; i++) {
        let data = tree[i];
        let children = '';
        if(data.children && data.children.length > 0) {
            children = '<ul>' + displayTree(data.children) + '</ul>';
        }
        html += '<li><div><b>' + data.id + '</b> ' + data.headline_text + '</div>' + children + '</li>';
    }
    return html;
}


Edit: html-koodin rakentaminen hiukka fiksummin sekä siinä olleen bugin korjaus (aiemmin ollut turha str-muuttuja ylikirjoitti itsensä niin, että alkavat li-tagit eivät tallentuneet html-muuttujaan)

Edit, edit: jostain syystä tuo kommentoitu rivi tuotti jokaisen viestiketjun alkuun yhden tyhjän bulletin. Eli en saanut tästä vielä semanttisesti tyydyttävää html-koodia kun lista on tehty pelkillä ul-tageilla.

Edit, edit, edit: nyt sain toimimaan tuon äskön vielä kommentoidun rivin. Virhe tapahtui tuota funktiota aiemmin.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - marraskuu 30, 2021, 12:22:56
Tähän viikonloppurojektiin voi tustustua osoitteessa: https://github.com/lazydistribution/tree_structure_testing. Sieltä voi myös downloadaa sen omalle koneelle.

Edit. toteutin tuon ajastuksen paremmin. Nyt ajatus toimii staattisella TimerFeature-toiminnolla. Aiemmin aikaleima sql-ajosta ja tietokantarivien määrä tallennettiin responssiin jo modelissa, nyt ne tallennetaan TimerFeature luokkaan. Nyt siis vasta Response-luokassa (luokka, jossa lopullinen json-tulostetaan) liitetään nuo seurattavat arvot responsiin selaimelle.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - joulukuu 19, 2021, 00:00:09
Ilman koodaustaitojakin voi näköjään rakennella sovelluksia: https://www.appgyver.com/

Tein parissa minuutissa tämän: https://platform.preview.appgyver.com/322116/kantisapp/page.Page1
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 23, 2021, 16:08:11
Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - lokakuu 06, 2021, 14:29:20
backendistä tuleva json-data

[
    {
        "template": "template-list-item",
        "date": "06.10.2021",
        "text": "Testiteksti 1"
    },
    {
        "template": "template-list-item",
        "date": "07.10.2021",
        "text": "Testiteksti 2"
    }
]


json-datan konvertointi html-dataksi (html-tekstiksi), ja sen tyrkkääminen sivulle

function backendResponse(data) {
    $('#app').html(json2HTML(data));
}

function json2HTML(data) {
    let html = '';
    for(let i = 0; i < data.length; i++) {
        let template = String($('#' + data[i].template).html());
        for(let j of data[i]) {
            if(Array.isArray(data[i][j])){
                data[i][j] = json2HTML(data[i][j]);
            }
            template = str_replace('{' + j + '}', data[i][j], template);
        }
        html += template;
    }
    return html;
}

function str_replace(pattern, fill, str) {
    while(str.indexOf(pattern) !== -1) {
        str = str.replace(pattern, fill);
    }
}


Koska html-sivu on käytännössä puurakenne, pitää fundeerata tätä yo-juttua hiukka uusiksi, kun tosiaan selvisi, että datan järjestäminen puurakenteeksi voidaan tehdä frontendin puolella, säästäen näin serveriltä resursseja.

Tuossa tuo ylempi koodiblokki on hiukka pelkistetty sillä usein se näyttää enempi tältä


[
    {
        "template": "template-list-item",
        "date": "06.10.2021",
        "text": "Testiteksti 1",
        "rows": [
            {
                "template": "template-article",
                "header-text": "Item header 1",
                "content-text": "Lorem ipsum..."
            },
            {
                "template": "template-article",
                "header-text": "Item header 2",
                "content-text": "Lorem ipsum..."
            }
        ]
    },
    {
        "template": "template-list-item",
        "date": "07.10.2021",
        "text": "Testiteksti 2",
        "rows": [
            {
                "template": "template-article",
                "header-text": "Item header 1",
                "content-text": "Lorem ipsum..."
            },
            {
                "template": "template-article",
                "header-text": "Item header 2",
                "content-text": "Lorem ipsum..."
            }
        ]
    }
]


Eli data tulee backendistä valmiiksi puu-rakenteessa vaikka tuon voisi ehkä tuoda frontendiin yksiulotteisena listana kuten alla

[
    {
        "id": 1,
        "parent_id": null,
        "template": "template-list-item",
        "date": "06.10.2021",
        "text": "Testiteksti 1"
           
    },
    {
        "id": 2,
        "parent_id": null,
        "template": "template-list-item",
        "date": "07.10.2021",
        "text": "Testiteksti 2"
    },
    ...
    {
        "id": 120,
        "parent_id": 2,
        "template": "template-article",
        "header-text": "Item header 1",
        "content-text": "Lorem ipsum..."
    },
    ...
    {
        "id": 245,
        "parent_id": 1,
        "template": "template-article",
        "header-text": "Item header 1",
        "content-text": "Lorem ipsum..."
    },
    ...
    {
        "id": 246,
        "parent_id": 1,
        "template": "template-article",
        "header-text": "Item header 2",
        "content-text": "Lorem ipsum..."
    },
    ...
    {
        "id": 428,
        "parent_id": 2,
        "template": "template-article",
        "header-text": "Item header 2",
        "content-text": "Lorem ipsum..."
    }
]


Ja sitten järjestellä se puuksi alla olevan funktion kaltaisella algoritmilla frontendissä

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - marraskuu 29, 2021, 17:18:07
Tässä koodi tuon puun rakentamiselle javascriptillä selaimessa tietokantadatan perusteella. Käytännössä copypeistasin sen täältä: https://typeofnan.dev/an-easy-way-to-build-a-tree-with-object-references/

function treeSort(data) {
    const output = [];
    //console.log(data);
    for(let arr of data) {
        const idMapping = arr.reduce((acc, el, i) => {
            acc[el.id] = i;
            return acc;
        }, {});
        let root;
        arr.forEach(el => {
            // Handle the root element
            if (el.parent_id === null) {
                root = el;
                return;
            }
            // Use our mapping to locate the parent element in our data array
            const parentEl = arr[idMapping[el.parent_id]];
            // Add our current el to its parent's `children` array
            parentEl.children = [...(parentEl.children || []), el];
        });
        //console.log(root);
        output.push(root);
    }
    return output;
}


Tai en tiedä. Koska tietokannat ovat kaikki erilaisia, datan laittaminen moniulotteiseen listaan eli puuhun jo backendin puolella on osoittautunut hiukka purkkaratkaisuksi kun koodia ainakaan nykyisellään ei voi jälleen käyttää. Vaan jokaisen eri tietokannan ja frontend -implementaatioiden kohdalla tämä on ollut aina ihan erilainen prosessi. Oletan kuitenkin, että implementoimalla tuo id ja parent_id-konsepti, voitaisiin ehkä erottaa parent_id:n käsittely ja sitten tietokannasta otettavan tietueen käsittely ja vakioida työvaiheita.

Kaikki palautuu siihen, onko se kuinka työlästä luoda parent_id-arvo ja liittää se jokaiseen tietokannasta saatuun tietueeseen. Kysymys siis kuuluu, tarvitaanko kuinka paljon sisäkkäisiä looppeja ja jos tarvitaan, onko se sama vaiva, että rakentaa suoraan sen puun, eli että unohtaa suoraan tuon koodin jälleenkäyttömahdollisuuden.

Tässäkin on kyllä vielä se mutta, onko koodi luettavampaa kummalla tavalla. Vanha tapa vai tämä uusi tapa?

Kiehtoo siis ainakin vielä ajatus että voisi koristella yksiulotteista listaa, sillä sen käsittely vaikuttaa ainakin näin ennakkoon simppelimmältä kuin moniulotteisen listan koristelu. Pitää nyt sitten vain odottaa inspiroitumista, jotta saisi kokeilluksi tätä uutta lähestymistapaa.

Tuossa olisi siis ehkä hyvä saada tuo tietueen käsittely niin simppeliksi, että se olisi aina samantyyppinen taski ja että olisi joku erillinen tietokantakohtainen funktio, joka käsittelisi tietokantatietueiden relaatiot, ja tämä olisi käytännössä ainut kohta, joka muuttuisi eri järjestelmissä ja missä kohtaa tarttisi aina hiukka miettiä. Tämä mahdollistaisi sen, että jos olisikin tietokanta-taulu, johon jo tallennetaan tuo parent_id-arvo, ei tarvitsisi miettiä lainkaan :P mutta tietueiden käsittely olisi silti samanlaista kuin muulloinkin - yksiulotteisen listan iterointi läpi, missä kunkin tietueen avain-arvo -parit ajettaisiin esimerkiksi switch-rakenteen läpi lopputuloksena frontendiin lähetettävä yksiulotteinen lista (haluaisin kuvailla tätä switch-vaihetta datan koristeluksi sillä tai vaikka tässä vaiheessa määritellään vain avaimet ja arvot, niiden perusteella frontend kuitenkin tietää piirtää tavaran näytölle). Tietysti switch-rakenne elää hiukka sen mukaan, millainen on design frontendissä, mutta se silti määriteltäisiin tässä aina samassa switch-kohdassa. Näin olisi mahdollisimman paljon vakioituja työvaiheita.
Otsikko: Vs: Ohjelmointi
Kirjoitti: kertsi - joulukuu 25, 2021, 12:03:51
En ole juurikaan seurannut tätä keskustelua, enkä tiedä onko jo mainostettu, mutta täällä olisi pilvin pimein ilmaisia ohjelmointi- yms. kursseja, esim. https://fitech.io/fi/opinnot/machine-learning-with-python/

Tässä kaikki FITECH-kurssit (https://fitech.io/fi/opinnot/?fit_course_types=upcoming&orderby=start_date&fit_topic=3766%2C1085%2C974%2C1358%2C3518%2C1421%2C1409%2C1397%2C1712%2C3792%2C1217%2C3083%2C1271%2C3946%2C3816%2C1055%2C1229%2C1250%2C767%2C737%2C1301%2C3106%2C3640%2C1013%2C1367%2C1181%2C1451&fbclid=IwAR0PEp2-MnaDb0Yfalj8gtR-UtrJLXoaYcM8rCtSij0DWVsMkUxWXKHkuqY) (joita voi listasta suodattaa).



Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - joulukuu 25, 2021, 12:13:30
^
Kiitos, tuohan vaikuttaa hyvältä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 04, 2022, 12:39:46
Pitäisi suunnitella MySQL-tietokanta puumaiselle listalle, jossa kullakin nodella on mahdollisesti toisistaan poikkeava määrä tavaraa.


[
    [
        'id' => 1,
        'parent_id' => 0,
        'created' => '2022-01-04 00:00:00',
        'modified' => null,
        'name' => 'Ensimmäinen kategoria'
    ],
    [
        'id' => 2,
        'parent_id' => 1,
        'created' => '2022-01-04 00:00:00',
        'modified' => null,
        'name' => 'Ensimmäinen myyjä',
        'url' => 'www.ensimmäinen-myyjä.com'
    ],
    [
        'id' => 3,
        'parent_id' => 2,
        'created' => '2022-01-04 00:00:00',
        'modified' => null,
        'name' => 'Ensimmäinen tuote HELGA',
        'url' => 'www.ensimmäinen-myyjä.com/eka-tuote',
        'description' => 'HELGA -kevät mallisto',
        'price' => 5.00
    ],
]


Eli jokainen node on samanlainen neljän (viiden) ensimmäisen avaimen kohdalla: id, parent_id, created, miodified (ja name). Mutta sitten tulevat nuo eroavaisuudet. Tarkoitus olisi kuitenkin saada data ulos tietokannasta juuri ylläolevassa muodossa. Onko ajatuksia?

Olen ajatellut, että eka taulu sisältäisi arvot 'id', 'parent_id, 'created' ja 'modified' ja esim. 'node_content_link_id', jossa taulun id, mistä puolestaan löytyisi kyseisen noden sisällön taulun nimi ja sisällön id. Eli kategoria-noden taulu olisi tyyliin 'category' ja siellä arvot id ja 'name', myyjä-noden taulu olisi 'seller', jossa arvot 'name' ja 'url' ja tuote-noden taulu, jossa arvot 'name', 'url', 'description' ja 'price'.

node-taulu

[
    'id' => 256,
    'parent_id' => 244,
    'created' => '2022-01-04 00:00:00',
    'modified' => null,
    'node_content_link_id' => 1
]


node_content_link-taulu

[
    'id' => 1,
    'content_table_name' => 'category',
    'content_table_id' => 1
]


category-taulu

[
    'id' => 1,
    'name' => 'Ensimmäinen kategoria'
]


Sitten vuan pitäisi keksiä MySQL-haku, joka palauttaa ylläolevan listan edellä mainitusta tallennusHELVETISTÄ, saatana!
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 04, 2022, 13:21:00
Eli nyt kun hiukan pohdin, tämä alla oleva MySQL-query taitaa olla tuo tarvitsemani sql-haku:

SELECT
  *
FROM
  node as no
  INNER JOIN node_content_link as li ON no.node_content_link_id = li.id
  INNER JOIN li.content_table_name as co ON li.content_table_id = co.id


Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 04, 2022, 13:36:30
Tuo palauttaa kaikki tietueet, eli siellä olisi tuolla sql-haulla nyt mukana node-taulun id, liitostaulun id ja sitten se sisältötaulun id, joista kaksi jälkimmäistä eivät sisältyneet alkuperäiseen suunnitelmaani. Mietinkin, että eihän tuo voi noin toimia, mutta sikäli kun niitä id-arvoja tarvitaan tallentamiseen, niin kyllä taitaa olla parempi ottaa nekin ulos tietokannasta jo tässä vaiheessa, jotta saa sitten helposti tallennettua tiedot takaisin tietokantaan. Muussa tapauksessa pitäisi tallentaessa tehdä tuo yllä ollut haku vielä uudestaan id-arvojen selvittämiseksi.

EDIT: eli yhden kategoria-tietueen osalta palautusarvo tietokannasta näyttäisi seuraavalta:

[
    'id' => 256,
    'parent_id' => 244,
    'created' => '2022-01-04 00:00:00',
    'modified' => null,
    'node_content_link_id' => 1,
    'id' => 1,
    'content_table_name' => 'category',
    'content_table_id' => 1,
    'id' => 1,
    'name' => 'Ensimmäinen kategoria'
]


ja jos käyttöliittymän kannalta turhan datan sitten vielä "pakkaisi" yhteen muuttujaan, voisi palautus arvo näyttää selaimessa joltain seuraavan kaltaiselta

[
    'id' => 256,
    'parent_id' => 244,
    'created' => '2022-01-04 00:00:00',
    'modified' => null,
    'name' => 'Ensimmäinen kategoria',
    'base64' => 'bm9kZV9jb250ZW50X2xpbmtfaWQ9MSZpZD0xJmNvbnRlbnRfdGFibGVfbmFtZT1jYXRlZ29yeSZjb250ZW50X3RhYmxlX2lkPTE='
]


EDIT: eri taulujen id-avaimet pitäisi tosin nimetä kukin eri tavalla, jotta ne tulisi PHP:n puolelle kivutta. PHP-listassa kun ei voi olla samoja avaimia.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 04, 2022, 15:23:31
Onko joku keksityn hyvän tavan laittaa selaimen javascript-moottori odottamaan, että DOM on valmis, ennen kuin javascript jatkaa koodin suorittamista, kun tyrkkää string-muodossa olevan html-merkkauksen www-sivulle?

Javascript suorittaa normaalisti kirjoitetun koodin odottamatta, vaikka DOMin päivittäminen on jollain funktiolla kesken, ellei javascriptiä erikseen käske odottaa jotain tapauhtumaa. Jos joku funktio on riippuvainen siitä, että kaikki data on DOMissa valmis, pitäisi jotenkin onnistua kertoa javascriptille, että se odottaisi DOMin valmistumista.

En vain tiedä, onko javascriptissä tällaista DOM-kuuntelijaa. Silloin kun sivu latautuu ekan kerran, siellä on javascriptissä funktio, jonka javascript suorittaa kun DOM on rakennettu valmiiksi, mutta jos päivitän DOMia tämän jälkeen ilman että lataan koko sivua uudelleen, en tiedä, minkä funktion javascript suorittaa silloin, kun DOM on jälleen valmis.

Osaan kyllä laittaa järjestelmän odottamaan tietyn tägin ilmaantumista selaimeen, että jos lisäisin jokaiseen String muotoiseen HTML-merkkaukseen loppuun tällaisen tägin ja jonka poistaisin, kunhan se olisi sinne ilmaantunut. Tämä ylimääräisten tägien lisäily ja poistelu vain vaikuttaa purkkaratkaisulta. Toivoisin tähän kohtaan jonkun geneerisen ratkaisun. Yritin etsiä interwebistä ohjeita, mutta en mielestäni löytänyt juuri muita ratkaisuja kuin laittaa järjestelmä odottamaan jonkun tietyn tägin ilmaantumista sivulle.

Muutenkin voi olla, että olen ajatellut tämän jo alun perinkin hiukka huonosti. Jos tuo String-muotoinen html-merkkaus on massiivinen, saattaa hitaampi selain jäädä jumiin, eli mun pitäisi harjoitella sellaistakin vaihtoehtoa, että tulostaisin datan näytölle pienissä osissa joiden välillä vapauttaisin resurssit koodin suorittamisesta näytölle. DOMin päivitys kestäisi silloin kyllä kauemmin tulla valmiiksi, kuin nyt kun tyrkkään kaiken sisällön kerralla, mutta tuollainen osissa selaimen renderöinti ei tappaisi hitaampaa selainta.

Löytyi toki myös alla oleva esimerkki. En vain tiedä, miten tuon pitäisi toimia ts. miten sitä käytetään. Kun laitoin tuon koodirimpsun kohtaan juuri ennen kuin DOMia päivitin, vaikutti siltä, että done()-funktiota kutsuttiin ennen kuin domia päivitin (else-koodiblokkia ei edes kutsuttu).

if( document.readyState !== 'loading' ) {
console.log( 'document is already ready, just execute code here' );
done();
} else {
document.addEventListener('DOMContentLoaded', function () {
console.log( 'document was not ready, place code here' );
done();
});
}
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 05, 2022, 05:48:43
^
Opiskelin tuossa juuri työnantajani kuukausittaisen opiskelu-ajan raameissa yhden tunnin mittaisen udemy-kurssin ajatuksesta, johon mm. facebookin ja instagramin DOM-manipulaatiot perustuvat, ja vaikuttaisi sen perusteella siltä, että lähestymistapani on ylipäätään liian yksinkertainen tehtävään, jota yritän ratkoa. Eli jos näytölle tulee paljon tavaraa, niin sen sijaan, että odottaa, että kaikki latautuu DOMiin ennen kuin lisää latautuneisiin tageihin toiminnallisuuksia, pitäisi toiminallisuus lisätä tageihin aina samaan aikaan kuin lisätään HTML-merkkaustekstiin kukin tagi. Näin lienee varminta, että toiminnallisuus myös aktivoituu samalla hetkellä kun kukin tagi viimein ilmaantuu DOMiin.

EDIT, pitää tosiaan tuon perusteella miettiä tarkkaan kannattaako jatkaa nykyistä tapani kirjoittaa koodi jos kohta muutoksin. Eli jatkaisin toiminnallisuuden krjoittamista erikseen ja html-rakentelun erikseen, mutta tällä kertaa niin, että tuo funktio, joka rakentaa html-koodin, osaisi aiemmasta poiketen liittää tuo aiemmin koodissani esittelemäni toiminnallisuus sinne sekaan.

Toisaalta virtuaalisen DOM -kirjaston rakentamin (kuten React -jota tosiaan facebook ja instagram käytävät) saattaisi olla parempi lähestymistapa. Ehkä se tietäisi muutaman rivin enemmän koodia, mutta se korjaisi samaan aikaan muutaman muunkin ongelmakohdan, kuten sellaisen, että kaikkea dataa ei tarvitsisi päivittää DOMissa joka kerta uudestaan, kun joku yksittäinen atribuutti tai arvo muuttuu jossain tagissa, vaan kuten virtual dom mahdollistaisi, vain tuo tagi.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 05, 2022, 09:37:52
^
Nyt näyttäisi siltä, että sain myös tuon virtual DOMin koodin toimimaan tässä mun koneella. Tämä avannee uusia mahdollisuuksia. Pitää vaan keksiä käyttökohteita. Varmasti pienemmissä sovelluksissa toimiva ratkaisu, jos kohta tuo mun alkuperäinen toimii vielä pienemmissä sovelluksissa. Kuitenkin vaan sitten rohkeasti Reactia, mikäli tarvitsee isompaa systeemiä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 20, 2022, 16:48:52
Mä olen nyt viimeisimmäksi yrittänyt duunaa geneeristä ascii-taulukkogeneraattoria php:lla*, mutta jostain syystä wordwrap-ominaisuus on tuottanut sellaisia ongelmia, ettei rojekti oikein etene. Tein yhden "version" jo valmiiksi, kun tein nämä listat (https://kantapaikka.net/index.php/topic,163.msg130513.html#msg130513), mutta tuossa koodi oli riippuvainen sekä ladatun tiedoston tietorakenteesta, että otsikkorivin wordwrap-toiminto puuttui, ja jouduin itse rivittämään otsikon.

Mulla on nyt tässä uusimmassa versiossa ainakin aihio wordwrapille.

Löytyy tuo aihio testiketjusta: https://kantapaikka.net/index.php/topic,3.msg131290.html#msg131290

Se toimii muuten oikein, mutta se käyttää edelleen vain yhtä rivin maksimipituuden arvoa, vaikka sen pitäisi käyttää jokaiselle taulukon sarakkeelle kyseisen sarakkeen maksimileveyttä. Eipä tullut aiemmin mieleen kun ei ollut tarvetta rivittää muita sarakkeita kuin vain taulukon viimeisintä saraketta. Samoin tuossa on edelleen se ongelma, että tämä aihionikin on edelleen liikaa riippuvainen tietorakenteesta. Tarkoitan, että mulla on nyt listoja listojen sisällä, joissa osa avaimista tekstinä ja osa numeroina. Tekstiavaimia varten pitää kirjoittaa omat funktiot kun taas numeroavaimia varten voi käyttää PHP:n omia funktioita.

Pitäisi päästä tilanteeseen, jossa taulukko-kirjasto käsittelisi vain kaksiulotteisia listoja. Eli listoja, jotka sisältäisivät tiedot vain taulukon jokaisen rivin tiedoista. Ulompien listojen pyörittelystä vastaisi sitten muut ohjelman osat. Tämä auttaisi siinä, että valmistamaani taulukkokirjastoa voisi käyttää myös jatkossa kokonaan erilaisen datan kanssa. Vielä ei kuitenkaan ole kaikki menetetty wordwrap-toimintoni osalta, sillä seuraavaksi pitää vain poistaa ulommat listat ja jättää jäljelle tosiaan vain operaatiot koskien kaksiulotteista listaa. Sekä katsoa missä kohtaa iteroin rivitystä tehdessäni läpi sarakkeita, jotta voin esitellä PHP:n omalle wordwrap()-funktiolle oman sarakekohtaisen leveyden.

Mutta jokaisella pilvellä on hopeareunuksensa. Tässä projektissa olen jostain kumman syystä opetellut käyttämään array_reduce()-funktiota. Nyt osaan käyttää sitä. Tosin vanhaa taulukon iterointia sekään ei voita, mutta joissain tapauksissa array_reduce-iterointi vaikuttaa mielestäni luonnollisemmalta vaihtoehdolta kuin perinteinen taulukon iterointi foreach-loopissa. Saas nähdä tulenko milloin käyttämään juuri oppimaani jossain työprojektissani.

* En ole katsonut mallia mistään, mutta sittenkin olisi pitänyt, sillä näitä on käsittääkseni tehty läpi koko tietokoneiden käyttöhistorian ajan sillä mahdollisesti edelleen se yleisin koodarien käyttämä käyttöliittymä on joku tekstikäyttöliittymä. Mutta jotta käyttäisin valmista sovellusta, pitäisi löytää PHP-kielellä toimiva sellainen kirjasto, jossa olisi tuon wordwrap-toiminto, sillä kovin pitkiä tekstejä ei ole mielekästä pakottaa yhdelle riville. Listojakin kun voisi olla ihan kiva välillä voida katsoa kännykän ruudulta ilman että joutuu kääntelemään luuria. Ties vaikka saisi tyrän liian aktiivisesta "luurinkääntelystä". Olisi tosin senkin vuoksi hyvä ollut katsoa mallia jostain kun tässä on kokoajan käynyt eri parempia ja parempia versioita tehdessä selväksi, että millainen politiikka olisi järkevää siinä miten organisoida ja jaotella koodi omiin kategorioihinsa ja selvittää niiden työtehtävät. Jossain valmiissa sovelluksessa nämä on ja ajateltu valmiiksi eikä tarvitsisi aloittaa kokoajan alusta kun huoman, että olisi parempi organisoida koodi toisella tapaa.

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 20, 2022, 16:49:18
^

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - marraskuu 30, 2021, 12:22:56
Tähän viikonloppurojektiin voi tustustua osoitteessa: https://github.com/lazydistribution/tree_structure_testing. Sieltä voi myös downloadaa sen omalle koneelle.

Edit. toteutin tuon ajastuksen paremmin. Nyt ajatus toimii staattisella TimerFeature-toiminnolla. Aiemmin aikaleima sql-ajosta ja tietokantarivien määrä tallennettiin responssiin jo modelissa, nyt ne tallennetaan TimerFeature luokkaan. Nyt siis vasta Response-luokassa (luokka, jossa lopullinen json-tulostetaan) liitetään nuo seurattavat arvot responsiin selaimelle.

Toinen syy, miksi rojekti ei oikein etene, on se, että en edelleenkään tiedä, miten Ajax-endpontin koodi olisi järkevintä organisoida, ja se taas liittyy tuohon tähän viestiini ylle lainaamaani asiaan kosien aiempaa projektiani, jossa idea oli tehdä mahdollisimman kevyt "API".

Jos tuossa viime marraskuisessa rampagessa idea oli alun perin testailla vain puurakenteen renderöintiä, niin tein sen yhteydesssä ja siihen tarpeeseen sivuprojektina kevyen apin. Tälläkin kertaa mulla on ollut pääasiallisena motivaationani listata saksitut-ketjuun päätyneiden viestien lukumäärät per nimimerkki ascii-listaan ja sitten taas tälläkin kertaa on ollut vahvasti mukana yritelmä vastata kysymykseen mahdollisimman lightway-tietorakenteesta ajax-kutsuja varten, mikä tarjoaisi kuitenkin riittävästi järkeviä käytäntöjä, joita noudattamalla koodia on helppo seurata.

Viime marraskuun projekti oli edelleen ja selvästi liian raskas, koska en kokenut luontevaksi ottaa sitä nyt käyttöön. Se kelpaa hyvin argumentiksi sen käytännöllisyyttä vastaan.

Kehitinkin nyt siis vieläkin kevyemmän version, jos kohta endpointtien määrittely ei nyt edellisestä poiketen tässä versiossa tyydytä (en kamalasti pohtinut tätäkään toteutusta kunhan vain roiskin MVC-ratkaisuni mahdollisimman nopeasti pöytään). Nyt kuitenkin haluaisin ehkä sittenkin kirjoittaa endpointit samoin kuin ne voidaan kirjoittaa esimerkiksi Laravelin MVC-kirjastossa. Eli tyyliin funktiokutsu, joka ottaa parametreinä vastaan url-osoitteen loppuosan, jota ajaxilla kutsuttu ja sitten käsittelijä rakenteeltaan: ClassNameController@methodName, jossa ekana controller-luokan nimi sitten @-merkki ja sen jälkeen controller-luokassa olevan metodin nimi, joka kyseisen ajax-kutsun backendissä käsittelee.

Esimerkki endpointista jollaista haluaisin käyttää olisi seuraava:

Route::get('/users', 'UserController@index');
Route::post('/upload', 'FileController@upload');


nyt mulla kuitenkin on tällainen lista-toteutus

return [
    '/users' => 'UsersController@index',
    '/upload' => 'FileController@upload',
];

Mulla on käytössä App-niminen luokka, joka käsittelee nuo listana esitellyt endpointit, kun ajattelin esitellä suoraan App-luokan, jos jatkossa tarvitsee jotain järeämpää, mutta ehkäpä pitäisi duunaa nyt vain suosiolla tuo Route-luokka ja lisätä sitten joskus myöhemmin App-niminen luokka jos järeämpää tarvitsee. Mieluummin liian yksinkertainen ja pysytellä yleisimmissä nimeämiskonventioissa, jotta ei sido käsiä siinä mitä käyttöä tällä on jatkossa. On vain niin hankala tietää etukäteen käyttötarpeita.

Tää on tällainen ikuisuuskysymys sekä selvästi ikuisuusprojekti. Samaten voisi olla vieläkin fiksumpaa nähdä se vaiva ja ladata joka kerta käyttöön Laravel näihin pikku projekteihinkin. Oppisi käyttämään sitäkin pelkän näpertelytason osaamisen sijaan.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 21, 2022, 18:33:16
Joku seuraavista projekteista voisi olla tuo mun localhost-kansion www-navigoinnin uudelleen väsääminen. Alla kuva nykyisestä. Siinä silmä lepää. Eli visuaalisesti perusrakenne on jo mieleiseni.

Musta painike on kansio, muun värinen painike yleensä jotain muuta sisältöä, kuten esimerkiksi suoritettava tiedosto.

Ongelma on, että jos availen kansioita tuosta pitemmälle kansiorakenteen syövereihin ja avaan sieltä jostain jonkun sivun selaimeen ja sen jälkeen painan selaimesta back-nappia, tuo palaa kansiorakenteen juureen eikä siihen näkymään, jossa oli tuo äsköinen kansiorakenne auki. Tämä on ongelma. On hiukka epäkäytännöllistä joutua klikkailemaan taas kaikki kansiot auki siihen viimeisimpään näkymään jos paikka oli edellisellä kerralla oikea, mutta tiedosto oli väärä.

En käytä nyt juurikaan osoiteriviä kuin sen käyttämisen mahdollistamaa selaimen historiaakaan. Pitäisi käyttää jotta selaimen back nappi löytäisi oikean sisällön. Toinen vaihtoehto varmaan olisi tallentaa viimeisin kansiorakenne keksiin. Luullakseni lähestymistapani tulee kuitenkin olemaan osoiterivi. Silloin sivu toimisi semanttisesti oikein.

Toinen idea olisi uusi feature. Se olisi sellainen, että esimerkiksi tekstitiedoston tai muun suoritettavan tiedoston kohdalla kun painaisi riville ympättyä toista nappia avautuisi teksti/koodi tuohon sivulle grafiikan päälle. Näin voisi tarkistaa ennen sivun avaamista ettei suoritettava koodi saa aikaan ei-toivottuja sivuefektejä koneella.

Kolmaskin idea on. Eli riville voisi lisätä kolmannen, neljännen tai ehkä viidennenkin painikkeen, jota/joita painamalla, kansion tai tiedosto avautuisi joko vs codeen, notepad plus plussaan tai kansion ollessa kyseessä, ehkäpä windows power shelliin.

Tämä kolmas idea parantaisi käyttökokemusta kun ei tarvitsisi avata välttämättä erikseen exploreria, että saa koodin auki ohjelmaan.

Neljäs idea liittyy tuohon kolmanteen. Voisi lisätä painikkeen, josta lisätään kansioon uusi kansio tai tiedostotyyppi.

Viides idea tarkoittaisi neljännen idean jatkamista niin että luodun kansion saisi haluamallaan sisällöllä. Mulla on tuolla muutama template-kansio järjestelmässä jotka olisi kiva kopioida uuteen paikkaan ja sitten avata esimerkiksi vc code uuteen kansioon. Näin ei tarvitsisi windowsin omaa exploreria.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 22, 2022, 16:57:15
^
Koska tämä olisi spa-sivu (single page application), selaimen back-napin toimiminen edellyttää tässäkin tapauksessa, että selain pystyy lukemaan sisällön kannalta järkevää tietoa osoiteriviltä, osatakseen ohjeistaa backend valmistamaan oikeanlaista dataa.

Pitäisi siksi keksiä järkevä protokolla tuohon osoiteriviin.

Jos vaikka vain laittaisi kansioiden nimet peräkkäin erikoismerkillä toisistaan erotettuina: ehkäpä hieman kuten tässä (https://stackoverflow.com/questions/21403290/generating-a-tree-structure-from-string-list) tapauksessa. Sitten laittaa nuo rivit peräkkäin ja erottaa ne toisistaan jollain muulla erikoismerkillä. Lopulta enkoodaa syntyneen yhden rivin tekstin, jotta sen voi laittaa osoiteriville. Jos näkymässä on suljettuna oleva kansio tai filu, niitä ei luonnollisesti tarvitsisi sisällyttää tuohon osoiteriville. Seuraavaksi selain ottaisi tuon osoitteen ja lähettäisi sen backendille. Backendin tulisi osata selvittää kyseisestä tekstirimpsusta kansiorakenne ja palauttaa sen perusteella oikeasisältöinen json-data-paketti selaimelle.

Edellinen-notaatio näyttäisi piippu- ja tuplapiippu-tapauksessa aseuraavan laiselta ilman enkoodausta (selain ei ymmärrä tätä osoitteeksi)
https://mozilla.org/level one|two|three||level one|another||level one|aaa|bbb|ccc||level one|aaa|bbb|aaa

Ja sitten enkoodauksen kanssa (selain ymmärtää tämän osoitteeksi)
https://mozilla.org/level%20one%7Ctwo%7Cthree%7C%7Clevel%20one%7Canother%7C%7Clevel%20one%7Caaa%7Cbbb%7Cccc%7C%7Clevel%20one%7Caaa%7Cbbb%7Caaa

Tämä on alustava sotasuunnitelma, kuinka rakennan url-osoitteen kansiorakenteelle. Onko muilla ideoita, kuinka kansiorakenne olisi näppärä laittaa selaimen osoiteriville?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 24, 2022, 03:49:35
^
Tässä onkin saanut jumpata, että sain backendin ymmärtämään tuota tekstinotaatiota. Olisi pitänyt heti alkuun muuttaa kukin rivi id ja parent_id -muotoon niin olisin saattanut jo heti alussa hyödyntää tota mulla jo viime marraskuulta valmiiksi ollutta javascript-implementaatiota puurakenteen luomiseksi. Pienillä muutoksilla se istui näppärästi php-koodiin.

Sen jälkeen eksyin useiksi tunneiksi rekursiivisten funktioiden mielettömyyteen.

Vihdoinkin backend palauttaa oikean informaation tuolla notaatiolla... ...tai niinhän mä luulen. Sekin ottaa oman aikansa, että saa frontendin toimimaan niin, että se lähettää backendille tarpeellisen notaation. Backend palauttaa kunkin painikkeen notaation, mutta en ole ihan varma riittäkö, että tyrkkää notaation kylmästi vain osoitteen jatkeeksi.

Vielä kun ajattelin tehdä frontendin reactilla niin tämä saattaa kestää. Backend on tehty ainakin tältä tiedostolistauksen osalta Laravelilla.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - huhtikuu 26, 2022, 14:58:18
p5.js kirjasto ei ole tehty modulaariseen ohjelmointiin. Tai sitten react-p5 -kirjastossa on bugeja. Tai sitten en vaan osaa käyttää sitä. Tai sitten kaikki edelliset yhteensä.

Yritin rakentaa react-p5 -kirjastolla grafiikkaa reactissa, mutta tyhjän olisi saanut pyytämättäkin. Kaikki grafiikka ei siinä päivity näytölle riippuen siitä, missä komponentissa ne olisi tarkoitus piirtää näytölle. Yhdessä komponentissa grafiikka piirtyy näytölle kun taas toisessa komponentissa ei. Jos tuon komponentin, jossa grafiikka ei päivity näytölle, näytölle renderöinnin toteuttaa pääohjelmassa niin tuo äsköinen vielä toimivasti palikat renderöinyt komponentti lakkaa päivittämästä osan komponenteista näytölle. Eikä interweb tunne juurikaan keskustelua kuinka p5.js kirjastoa käytetään modulaarisessa ympäristössä.

Pitää joko yrittää luoda grafiikka vanilla-javascriptilla reactissa tai sitten pitää tehdä grafiikka erikseen ja ladata se sivulle. Melkein kiinnostaisi tää jälkimmäinen. Eli jos vain lataisi grafiikan iframeen ja löisi sen taustalle pörräämään. Mulla nimittäin on versio haluamastani grafiikasta jo tehty, joten tarvetta sen uudelleen kirjoittamiselle reactissa ei varsinaisesti ole. Tekisi tosin siksi mieli kirjoittaa se uusiksi reactissa, että olisi sitten tuosta grafiikastani modulaarinen versio olemassa, jonka myötä opittuja käytäntöjä voisi hyödyntää muissa modulaarisissa projekteissa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - toukokuu 02, 2022, 18:00:40
^^
Pitänee mennä Stack Overflow:hun kyselemään typeriä. En nimittäin tiedä, kuinka tarvitsemani navigointi toteutetaan Reactissa tai että millaista navigointia ylipäätään Reactissa tarvitsen.

Olen kerran aiemmin tehnyt vanilla javascriptilla systeemin, jossa laitan osoiteriviin kuuntelijan, joka aktivoituu joka kerta, kun osoiteriviä muutetaan. Aktivoituessaan kuuntelija tilaa backendistä tiedot osoiterivillä olevien tietojen perusteella, jotka näytetään sitten sivulla. Eli kuten homma toimii staattistenkin nettisivujen kanssa. Tämän tyyppistä toiminnallisuutta suunnittelin myös nyt tuohon "explorer"-projektiini.

Reactiin on saatavissa React Router -lisäpalikka, joka operoi selaimen osoiterivin kanssa, mutta tietääkseni sitä käytettäessä pitää esimerkiksi osoitteiden olla staattisesti määriteltyjä kun taas minulla ne määräytyvät dynaamisesti. Mutta koska en tunne Reactia riittävän hyvin, pitää mennä kyselemään.

Samaten pitää siirtyä queryparametrien käyttöön. Päinvastoin kuin ekaksi ajatelin, että osoite olisi muotoa localhost/toc/public/www||www|assets, jossa www-kansion sisältö tulisi suoraan kauttaviivan perään, pitää muuttaa tuo esimerkiksi muotoon localhost/toc/public/?q=www||www|assets, tämä mahdollistaa sen, että voin välittää backendille näppärästi muutakin tietoa halutusta näkymästä kuin pelkän kansiorakenteen.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - toukokuu 03, 2022, 15:11:54
^
Löysin React Router -videoita, joiden perusteella näyttäisi siltä, että RR:n tarjoama Link-komponentti olisi sellainen jollaista tässä tarvitsen. En tosin tiedä, mitä tapahtuu jos vain osoitteen query-parametrit muuttuvat, eli että kutsuuko RR silloinkin asiaankuuluvaa komponenttia vai pitääkö tehdä vielä jotain muutakin. Mutta tällä hetkellä vaikuttaa lupaavalta, että RR hoitaa sittenkin pulman.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - toukokuu 06, 2022, 14:32:29
^
Mun ei muuten tartte frontendissä määritellä erikseen linkkien sisältöä. Kun kukin nappi tekee vain yhden asian kerrallaan jo olemassa olevalle url-osoitteelle tai query-parametreille, voin rakentaa osoitteet valmiiksi backendissä. Jos siis oikein tajusin. Pitää tosiaan olla tekemättä mitään tälle projektille niin tulee näitä oivalluksia, jotka kertyessään säästävät minut turhalta työltä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - toukokuu 29, 2022, 17:24:53
Hesarissa tuli vastaan arvio että tietotekniikan osuus maailman energiankulutuksesta on vuonna 2030 21%.
Sekä termi green coding.

Perl-ojhelmointikieli vie jopa 80 kertaa enemmän energiaa kuin vanha C-kieli. Javascriptin sähkönkulutus on nelinkertainen C-kieleen verrattuna.

https://www.hs.fi/visio/art-2000008830814.html (maksumuuri)
Podcast: https://www.hs.fi/visio/art-2000008839656.html
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - kesäkuu 04, 2022, 10:31:17
Kun esimerkiksi valtionpäämies haluaa poistaa vaimonsa nakukuvan verkosta, se yleensä onnistuu. Tavalliselle kansalaiselle ei.

Miten tuo suodattaminen teknisesti tapahtuu? Annetaanko hakukoneille lista kielletyistä kuvista? Tai teksteistä. Itse kuvahan aina joissain osoitteissa säilyy, mutta se ei näy hakukoneen kautta etsijöille.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - kesäkuu 04, 2022, 10:46:50
^
Ehkäpä siellä on lista kuvan www-osoitteista. Aina kun löytyy uusi osoite kuvalle, lisätään se listaan. Sitten poistetaan listan osoitteet hakutuloksesta. En kyllä yhtään tiedä onko tämä ainut keino.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Lenny - kesäkuu 04, 2022, 10:47:31
Lainaus käyttäjältä: a4 - toukokuu 29, 2022, 17:24:53
Perl-ojhelmointikieli vie jopa 80 kertaa enemmän energiaa kuin vanha C-kieli. Javascriptin sähkönkulutus on nelinkertainen C-kieleen verrattuna.

Erittäin mielenkiintoinen ja ajankohtainen huomio, kiitos! Tietotekniikassahan trendi näyttää olevan jatkuvasti kohti monimutkaisempaa, kohti korkeampia abstraktiotasoja, kohti suurempaa tuottavuutta. Toisaalta taas pelkästään sen lopputuotteena olevan koodin tehokkuuden tarkastelu on liian yksinkertaista, koska pitäisi ottaa huomioon myös ohjelman kirjoittamiseen käytetyt resurssit. Ehkä artikkelissa näin tehtiin, en lukenut.

Lisäys: mietin asiaa minuutin ja eihän niillä kehittämisresursseilla ole mitään merkitystä siihen verrattuna että jotakin koodinpätkää ajetaan miljoonilla koneilla. Loppujen lopuksi tietotekniikan tuottavuuden kasvu hyödyttää vain ohjelmistoteollisuutta, ja loppukäyttäjä maksaa ympäristörasituksen. Toki myös ohjelmistokehittäjät joutuvat miettimään kysymystä omien järjestelmiensä osalta, esim. pilvipalvelut.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 01, 2022, 15:05:32
Tein dataplotterin omalle koneelle. Liitteenä muodostettu kuva, jossa vaaka-akselilla tuoreimman Human Development Index (Dashboard 1: Quality of human development) (https://hdr.undp.org/data-center/documentation-and-downloads) -raportin sijoitus ja pystyakselilla tuoreimman Economic Freedom Index 2022 (https://www.heritage.org/index/ranking) -raportin sijoitus.

Länsimaat oikealla ylhäällä ja kehitysmaat vasemmalla alhaalla. Eli ainakin tämän vertailun osalta kehittyneimmät maat ovat kehittyneimpiä niin ihmisten elinolosuhteiden osalta kuin taloudellisessa vapaudessa. Ei mikään ylläri. Noissa raporteissa on yhteensä niin monta featurea, että niistä saa vaaka- ja pystyriveille heitettynä muodostettua vähän vajaa 2000 kpl eri kuvaa. Mulla oli joskus vuosia sitten vastaava, mutta meni vanhan koneen kovalevyn kanssa kierrätykseen. Siinä vanhassa oli vähemmän tilastodataa, mutta mahdollisuuksia vaikuttaa minkä maiden dataa näytetään.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 07, 2022, 08:27:18
Lainaus käyttäjältä: -:)lauri - tammikuu 05, 2022, 09:37:52
^
Nyt näyttäisi siltä, että sain myös tuon virtual DOMin koodin toimimaan tässä mun koneella. Tämä avannee uusia mahdollisuuksia. Pitää vaan keksiä käyttökohteita. Varmasti pienemmissä sovelluksissa toimiva ratkaisu, jos kohta tuo mun alkuperäinen toimii vielä pienemmissä sovelluksissa. Kuitenkin vaan sitten rohkeasti Reactia, mikäli tarvitsee isompaa systeemiä.

Nyt löysin käyttökohteen virtual domilleni. Localhost-kansioni selainpohjaisesta "explorerista". Aiemmassa versiossa ollut tapa rakentaa apista tuleva data ensiksi tekstitksi, jonka selain muuttaa html-koodiksi ei toimi tässä uudessa systeemissä, kun teksti vie enemmän muistia, kuin selain pystyy käsittelemään (voi olla että, johtui bugista, että apin datasta tekstiksi -konversiossa ei ole enkoodatu tietyjä tekstejä ja syntyi tavallaan ikuinen looppi joka täytti selaimen muistin). Niinpä pitää tekstin sijaan muuttaa data suoraan html-muotoon ilman tekstivaihetta. Tein jo toimivan version, jossa data muuttuu suoraan html-elementeiksi. Mutta siinä kaikki työvaiheet ovat yhdessä "isossa" javascript-tiedostossa onnellisesti sekaisin. Haluan kuitenkin erotella eri työvaiheet toisistaan ts. pilkkoa koodi osiin sen ylläpidettävyyden ja uudestaan käytettävyyden kanalta järkevästi. Voin siis luontevasti katsoa nyt myös tuon virtual dom -korttinikin. Olen jo aloitellut toteutusta. Siihen kuuluu ainakin seuraavat työvaiheet.


Olen nyt suorittanut tyovaiheen 6. Tietenkään en tiedä vielä ymmärtääkö virtual dom -ratkaisuni puu-ratkaisuani, mutta pikaisella silmäilyllä vaikutti siltä, että puu muodostuu kuten pitää.

Tämä on tietenkin vasta virtual dom -idean opettelua. Duunissa voi tulla vastaan tilanteita, joissa voi olla tarvetta isommille datan käsittelyille selainpuolella, johon tuo tekstipohjainen konversio ei sovi, eikä Reactia tai muuta vastaavaa frontend-frameworkkia voi käyttää. Näitä silmällä pitäen on hyvä saattaa tää oma kevyt-versio virtual domista siihen pisteeseen, että näen ja ymmärrän kuinka sen kanssa toimitaan.

Yllä olevia työvaiheita edeltää työvaihe, jossa tilataan tiedot serveriltä (api) selaimeen. Yritän tehdä siitäkin geneeristä ja kokonan omaa koodiblokkia, jotta voin jatkossa copypeistata myös sen muihin rojekteihin. Idea on siis automatisoida mahdollisimman pitkälle se miten selain tilaa apista tiedot.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 07, 2022, 08:49:55
^
Tuli just mieleen, että olen käyttänyt teksipohjaista ratkaisuani duunissa ja yhdessä tapauksessa on tilanne se, etten kontrolloi kaikea tietoa, mitä sen läpi kulkee, tarkoittaen, että ennemmin tai myöhemin syntyy ikuisia looppeja. Epätodennäköistä kylläkin, mutta koska ei ole mahdotonta erittäin epäotodennäköisessä tilanteessa voi ongelmia ilmetä. Siinä on kuitenkin käytössä ikuisen loopin katkaisu, mutta jos onnistuu kirjoittaa satoja rivejä tesktiä ja lyö sen "ikuiseen" looppiin, voi selaimen muisi täyttyä ennen loopin katkaisua. Tosin kyse on selaimen ylälaidassa näkyvästä muistilapusta, joten kovinkaan todennäköistä ei ole, että sille kirjoitettaisiin muutamaa sanaa tai lausetta pitempiä elämäkertoja.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 07, 2022, 13:18:42
^^
^
Pääsin työvaiheeseen 7. Worked like a charm! Nyt on koodi sen verran hyvin ilman ylimääräisiä osia, että pitää säilyttää tämä projekti tällaisena ja palata sitten tästä kopioimaan tarpeen niin vaatiessa ja räätälöidä se paremmin juuri siihen rojektiin, missä tästä olisi apua.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 22, 2022, 19:34:04
^
Ollu kyllä melkoista ton uuden systeemin opettelu. Tuossa oli sellainen bugi, että se ei aina osannutkaan poistaa näytöltä oikeita elementtejä. Alkuperäinen indeksiin perustuva pienimmästä suurimpaan -systeemi ei monimutkaisemmassa ympäristössä toiminut. Piti kerätä poistettavat indeksit yhteen ja sitten ajaa indeksit käänteisessä järjestyksessä. Tämän lisäksi se ei tunnistanut aina elementtiä, jonka sisältä piti käänteisen indeksin mukaan poistaa, joten piti laittaa jokaiselle tuollaiselle parent-elementille yksilöllinen id-arvo ja ottaa myös se talteen. Lopuksi sitten ottaa kyseisellä id-arvolla elementti ja poistaa sen sisältö viimeisimmästä ensimmäiseen. Nyt vaikuttaa toimivan ainakin eteen tulleissa tilanteissa. Pitää kuitenkin jatkaa applikaation kehittelyä, jotta tulee kaikki tällaiset lastentaudit esille. Samalla opettelen moduuleihin perustuvan ohjelmointitavan, jotta saa paremman vastaavuuden reaction ja vuen kanssa ts. systeemi olisi tarvittaessa muunnettavissa vain pienellä vaivalla jommallekummalle alustalle.

Tämän siitä saa kun koko frontend-ura on perustunut JQueryn käyttöön ja kun nyt sitten "ekaa kertaa" rakentaa systeemin ihan vain vanilla javascriptilla niin maailma on kyllä huomattavan erilainen. Paljon on tullut ihan uusia mielenkiintoisia juttuja eteen.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - syyskuu 23, 2022, 09:25:39
Pääkaupunkiseudun lippujärjestelmä on koodattu mielenkiintoisella tavalla.

HSL:n it-järjestelmä taipuu kankeasti – varoittaa uhkaavasta miljoonalaskusta (https://www.tivi.fi/uutiset/tv/82e8a0a4-8205-4e35-84aa-501106693d4a)
Lainaa
HSL:n mukaan alv:n väliaikainen poistaminen vaatisi järjestelmämuutoksia, joiden arvioidaan kustantavan miljoona euroa. Lisäksi muutos viivästyttää käynnissä olevaa lippujärjestelmän uudistamishanketta, mikä aiheuttaisi viiden miljoonan euron lisäkustannukset.

Kenellekään ei suunnitteluvaiheessa ilmeisesti tullut mieleen, että arvonlisäverokanta saattaisi muuttua ja mahdollisesti mennä nollaan.  :(
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - syyskuu 23, 2022, 10:41:09
^
Onpa aika uskomaton juttu :O

Ihan pienellä miettimisellä en keksinyt, miten yksi palikka voidaan saada tehtyä niin, että sen muuttaminen tai poistaminen käytöstä maksaisin hyvän kokoisen projektin verran.

Tosin konsulttityö on kallista ja hidasta. Muistanpa noin 10 vuoden takaa omassa duunissani tapauksen, jossa yhdessä tietokannan päivityssovelluksessa (cobol eräajo) oli virhe. Olin aikaisemmin kyseistä ohjelmaa ylläpitänyt, joten tunsin sen hyvin. Olin jo koodista etsinyt virheen paikankin valmiiksi ja korjauksena oli erään luvun poisto arvolistasta. Kun saimme meidän toteutustyön tekevästä firmasta hintalapun korjaukselle, niin kolmen merkin poistaminen, kääntäminen, linkkaaminen, testaus ja tuotantoon siirto yhteensä maksoivat 5100 euroa. Jos homma olisi edelleen ollut meillä, niin kyseessä olisi ollut parin tunnin homma päästä päähän.

Tuosta jäi kyllä niin kitkerä muisto, että varmaan hautaan asti sen muistan.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hiha - syyskuu 23, 2022, 13:48:35
Lainaus käyttäjältä: Hayabusa - syyskuu 23, 2022, 09:25:39
Pääkaupunkiseudun lippujärjestelmä on koodattu mielenkiintoisella tavalla.

HSL:n it-järjestelmä taipuu kankeasti – varoittaa uhkaavasta miljoonalaskusta (https://www.tivi.fi/uutiset/tv/82e8a0a4-8205-4e35-84aa-501106693d4a)
Lainaa
HSL:n mukaan alv:n väliaikainen poistaminen vaatisi järjestelmämuutoksia, joiden arvioidaan kustantavan miljoona euroa. Lisäksi muutos viivästyttää käynnissä olevaa lippujärjestelmän uudistamishanketta, mikä aiheuttaisi viiden miljoonan euron lisäkustannukset.

Kenellekään ei suunnitteluvaiheessa ilmeisesti tullut mieleen, että arvonlisäverokanta saattaisi muuttua ja mahdollisesti mennä nollaan.  :(

Todellakin kuulostaa käsittämättömältä. Siksi sen täytyy olla totta.

Ehkä tuollainen monumentaalinen epäpätevyys on kuitenkin parempi kuin toinen mahdollinen selitys. Siinä HSL valehtelee kylmästi sosialisoidakseen itselleen rahan, jolla ilmeisesti haluttaisiin tukea joukkoliikennettä yleisesti sekä pienituloisia.

"Jos matkakuluja halutaan alentaa, se on syytä tehdä suoralla valtiontuella HSL:lle." (Pekka Sauri, HSL)
Otsikko: Vs: Ohjelmointi
Kirjoitti: Melodious Oaf - syyskuu 23, 2022, 15:36:27
Ilmeisesti tossa ongelma ei ole ihan se, että on joku yksi muuttuja siellä, joka on niin huonosti toteutettu että sen arvoa ei vaan saada millään muutettua a) ollenkaan tai b) niin että alv voi olla nollassa ja kaikki toimii.

Vaan siis ongelma on sen tyyppinen, että HSL:llä on tosi paljon kumppaneita, käytännössä erillisiä yhtiöitä, joilla kaikilla on omat erilliset myyntijärjestelmänsä ja niille erilaisia kanavia ja niin pois päin.

HSL:n järjestelmän taas pitää toimia niiden kaikkien erillisten järjestelmien kanssa yhteen, ja siitä tulee se ongelma, että jos alv:sta luovutaan, jonkun pitää katsoa ne ihan kaikki läpi ja varmistaa että kokonaisuus edelleen toimii.

Siis tyhmää joo, mutta ei nyt ihan niin tyhmää, että nimenomaan HSL:n järjestelmään itsessään ois koodattu alv niin typerällä tavalla että sitä ei pysty muuttamaan muuta kuin miljoonabudjetilla.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - syyskuu 23, 2022, 17:21:45
Aivan varmasti tyhmiä on muuallakin kuin HSL:llä. Muistuu mieleen, että näilläkin palstoilla joku suorastaan kieltäytyi ymmärtämästä arvonlisäveron käsitettä ja määräytymistä. Olisiko sittemmin hakeutunut töihin lippujärjestelmien pariin?  ;)
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - syyskuu 23, 2022, 18:01:46
HS kirjoittaa asiasta (https://www.hs.fi/kaupunki/art-2000009081533.html):
HSL:n selvityksen perusteella alvin poisto on osoittautumassa erittäin mutkikkaaksi käytännössä. Pelkästään tekniset muutokset HSL:n ja sen kumppaneiden lukuisissa myyntijärjestelmissä aiheuttavat miljoonaluokan kustannukset, ja ovat osoittautuneet osittain jopa mahdottomiksi.

Väliaikainen veronalennus lykkäisi HSL:n nykyiseen lippujärjestelmään suunnitellut tietoturvapäivitykset. Se lykkäisi myös uuden lippujärjestelmän käyttöönottoa arviolta kuudella kuukaudella.

Pelkästään HSL:n menetykset ovat noin kuusi miljoonaa euroa.


HSL ilmoittaa (https://www.hsl.fi/hsl/uutiset/uutinen/2022/09/pidamme-ehdotettua-alv-poistomallia-epaonnistuneena-ja-ehdottamme-tilalle-vaihtoehtoista-mallia) myös, ettei muutos ole mahdollinen aikataulussa eli ensi vuoden alkuun ja ehdottaa että raha annettaisiin HSL:lle, joka alentaisi sillä lippujen hintoja.

Tuolle saa nauraa naurismaan aidatkin. Paitsi että maksumiehiksi laitettaisiin kaikki.

Sitä en suostu uskomaan, ettei järjestelmässä ALVia voisi vaihtaa. Ongelman täytyy olla siinä ettei ole ajateltu että ALV voisi olla nolla, jolloin jotkut järjestelmäliittymät jäisivät pois käytöstä.

Vaikea ymmärtää HSL:n järjestelmää, jossa ALVin poisto lisäisi kustannuksia ja nostaisi matkalippujen hintoja.

Otsikko: Vs: Ohjelmointi
Kirjoitti: Melodious Oaf - syyskuu 23, 2022, 21:15:50
Lainaus käyttäjältä: Jaska - syyskuu 23, 2022, 18:01:46
Sitä en suostu uskomaan, ettei järjestelmässä ALVia voisi vaihtaa. Ongelman täytyy olla siinä ettei ole ajateltu että ALV voisi olla nolla, jolloin jotkut järjestelmäliittymät jäisivät pois käytöstä.

Myönnän että on mahdollista, että tossa on HSL:llä joku ihan kumma lehmä ojassa, josta en tajua mitään.

Mutta eikö semmonenkin periaatteessa olis mahdollista, että ongelma ihan todella on kaikkien niiden eri yhtiöiden erilliset myyntijärjestelmät ja se, että niissä arvonlisäveroa saatetaan käsitellä eri tavoin ja että niiden kytky HSL:n systeemeihin ei ole aina samanlainen?

Ne ei halua että tollasta muutosta tehdään ainakaan just tolla aikataululla, mutta tohon saattaa myös liittyä halu lypsää ja ajaa omaa taloudellista etua. Siihen taas saattaa kuulua jotain taustatekijölitä, mitä on ulkoapäin vaikea edes nähdä tai arvata.

Viestimällä asioista ulospäin just niin kuin ne nyt tekee ne tietysti pyrkii johonkin.

Nythän tommosella viestimisellä vois olla mahdollista myös pelata aikaa tai vähentää mainehaittaa sillä, että jos jotain ongelmia sitten tulee, ei voida sanoa ettei ne olis edes yrittänyt niitä välttää.

Ja tietysti siinä voi olla monta tekijää samassa  :D
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - syyskuu 23, 2022, 21:34:49
^
Luulisin, että maksujärjestelmä on HSL:n ja maksulaitteet asennetaan kuhunkin bussiin aina, kun bussifirma ottaa ajaakseen HSL:n reittejä. Minusta ne ainakin näyttää ihan samanlaisilta riippumatta siitä, minkä firman autoon ole noussut.

Sitä paitsi ei kai niissä maksupäätteissä sitä ALV:n laskemista pyöritetä vaan jossain palvelimella, mihin kukin tapahtuma välittyy.

Jos se nyt jotain järkevästi on tehty, niin matkastani Jumboon välittyisi vain "Yksi BC matka Hipin saldosta pois". Ei maksupääte, vaan joku palvelin välittää näytölle takaisin viestin "OK, saldo on nyt xx,xx euroa". Se miten se "yksi BC matka" on hinnoiteltu on siellä palvelimella tiedossa ja nyt siitä sitten osa on matkan hintaa ja osa ALV:a, joka viedään kirjanpitoon miten nyt viedäänkään. Tuosta pitäisi vaan saada nypittyä tuo ALV pois.

Noin siis kuvittelen sen toimivan.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Melodious Oaf - syyskuu 23, 2022, 21:45:18
^ No sulla on varmasti parempi kyky hahmottaa ja kuvitella tämän tyyppisiä asioita kuin minulla, ehkä luontaisestikin, ja sitten tulee vielä työhistoria ja kokemus siihen päälle.

Mulla ei ole edes kuin satunnaisia kokemuksia HSL:n matkustajana, niin se on aika lailla eos täällä päässä sitten lopulta
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - syyskuu 23, 2022, 21:50:38
^
No joo, ihan mielikuvituksesta tuon tempaisin. En ole tuon tyyppisiä sovelluksia koskaan ollut mukana tekemässä. :D
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - syyskuu 27, 2022, 16:53:01
Tämä herättää kysymyksiä IT-porukan moraalista.

Lainaus käyttäjältä: https://www.is.fi/digitoday/tietoturva/art-2000009097454.htmlTiistaina julkitulleiden asiakirjojen mukaan Vastaamon tietoturva olisi ollut jopa vuosia retuperällä. Erään todistajan mukaan yhtiön tietoturvaohjelmistot ja palomuurit toimivat minimitasolla. Se ei ollut hänen mielestään riittävää, koska yhtiön palvelimilla oli arkaluonteista sisältöä.

Yhden vanhan työntekijän mukaan Vastaamon tietoturvaan ja it-infrastruktuuriin oli panostettu taloudellisesti ja resurssein hyvin vähän, jos edes sitäkään. Ex-työntekijän mukaan Vastaamolla mentaliteetti oli ollut, että "tehdään sitten, kun on pakko".
...
It-arkkitehtuurin kannalta kriittinen järjestelmä oli esimerkiksi laiton versio.

– Lähinnä hankittiin ilmaisia työkaluja, muun muassa virtualisointialusta oli piraattiversio, ilman ostettua lisenssiä, todistaja sanoi.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - syyskuu 27, 2022, 21:11:51
Tietomurron kohteeksi joutuneen Vastaamon tietojärjestelmien heikko laatu on ollut julkisuudessa murrosta alkaen. Nyt on saatu yksityiskohtaisempaa tietoa. Käytössä muistaakseni oli ex-toimitusjohtaja Ville Tapion hutaisemaa koodia. Tässä selvästi on "säästetty" ohjelmistokuluissa käyttäen mm. piraattiversioita. Yrittäjätoiminta luisui liiaksi laittomuuden puolelle seurauksena ikävä suuri tietovuoto, jossa potilastiedot vuosivat.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - syyskuu 28, 2022, 07:07:36
Lainaus käyttäjältä: ROOSTER - syyskuu 27, 2022, 16:53:01
Tämä herättää kysymyksiä IT-porukan moraalista.

En tiedä onko olemassa luotettavia tutkimuksia eri ammattikuntien moraalista.
Eiköhän kuitenkin IT-miehet ja -naiset suurilta osin ole "puolel hyvien".
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 30, 2022, 15:50:01
Lainaus käyttäjältä: -:)lauri - huhtikuu 20, 2022, 16:49:18
^

Lainaus käyttäjältä: Viihde- ja hömppäpöhinä - marraskuu 30, 2021, 12:22:56
Tähän viikonloppurojektiin voi tustustua osoitteessa: https://github.com/lazydistribution/tree_structure_testing. Sieltä voi myös downloadaa sen omalle koneelle.

Edit. toteutin tuon ajastuksen paremmin. Nyt ajatus toimii staattisella TimerFeature-toiminnolla. Aiemmin aikaleima sql-ajosta ja tietokantarivien määrä tallennettiin responssiin jo modelissa, nyt ne tallennetaan TimerFeature luokkaan. Nyt siis vasta Response-luokassa (luokka, jossa lopullinen json-tulostetaan) liitetään nuo seurattavat arvot responsiin selaimelle.

Toinen syy, miksi rojekti ei oikein etene, on se, että en edelleenkään tiedä, miten Ajax-endpontin koodi olisi järkevintä organisoida, ja se taas liittyy tuohon tähän viestiini ylle lainaamaani asiaan kosien aiempaa projektiani, jossa idea oli tehdä mahdollisimman kevyt "API".

Jos tuossa viime marraskuisessa rampagessa idea oli alun perin testailla vain puurakenteen renderöintiä, niin tein sen yhteydesssä ja siihen tarpeeseen sivuprojektina kevyen apin. Tälläkin kertaa mulla on ollut pääasiallisena motivaationani listata saksitut-ketjuun päätyneiden viestien lukumäärät per nimimerkki ascii-listaan ja sitten taas tälläkin kertaa on ollut vahvasti mukana yritelmä vastata kysymykseen mahdollisimman lightway-tietorakenteesta ajax-kutsuja varten, mikä tarjoaisi kuitenkin riittävästi järkeviä käytäntöjä, joita noudattamalla koodia on helppo seurata.

Viime marraskuun projekti oli edelleen ja selvästi liian raskas, koska en kokenut luontevaksi ottaa sitä nyt käyttöön. Se kelpaa hyvin argumentiksi sen käytännöllisyyttä vastaan.

Kehitinkin nyt siis vieläkin kevyemmän version, jos kohta endpointtien määrittely ei nyt edellisestä poiketen tässä versiossa tyydytä (en kamalasti pohtinut tätäkään toteutusta kunhan vain roiskin MVC-ratkaisuni mahdollisimman nopeasti pöytään). Nyt kuitenkin haluaisin ehkä sittenkin kirjoittaa endpointit samoin kuin ne voidaan kirjoittaa esimerkiksi Laravelin MVC-kirjastossa. Eli tyyliin funktiokutsu, joka ottaa parametreinä vastaan url-osoitteen loppuosan, jota ajaxilla kutsuttu ja sitten käsittelijä rakenteeltaan: ClassNameController@methodName, jossa ekana controller-luokan nimi sitten @-merkki ja sen jälkeen controller-luokassa olevan metodin nimi, joka kyseisen ajax-kutsun backendissä käsittelee.

Esimerkki endpointista jollaista haluaisin käyttää olisi seuraava:

Route::get('/users', 'UserController@index');
Route::post('/upload', 'FileController@upload');


nyt mulla kuitenkin on tällainen lista-toteutus

return [
    '/users' => 'UsersController@index',
    '/upload' => 'FileController@upload',
];

Mulla on käytössä App-niminen luokka, joka käsittelee nuo listana esitellyt endpointit, kun ajattelin esitellä suoraan App-luokan, jos jatkossa tarvitsee jotain järeämpää, mutta ehkäpä pitäisi duunaa nyt vain suosiolla tuo Route-luokka ja lisätä sitten joskus myöhemmin App-niminen luokka jos järeämpää tarvitsee. Mieluummin liian yksinkertainen ja pysytellä yleisimmissä nimeämiskonventioissa, jotta ei sido käsiä siinä mitä käyttöä tällä on jatkossa. On vain niin hankala tietää etukäteen käyttötarpeita.

Tää on tällainen ikuisuuskysymys sekä selvästi ikuisuusprojekti. Samaten voisi olla vieläkin fiksumpaa nähdä se vaiva ja ladata joka kerta käyttöön Laravel näihin pikku projekteihinkin. Oppisi käyttämään sitäkin pelkän näpertelytason osaamisen sijaan.

Kirjoitin jälleen uuden. Tällä kertaa vieläkin simppelimmän. Myös tuo haikailemani route-notaatio mukana.

Mitä tulee tuohon selainpohjaiseen kansioexploreriini, pitää ottaa luokat Laravelista ja laittaa ne tähän. Laravel-toteutuksessa ei olisi muutoin vikaa, mutta kun se ei toimi vanhemmilla konfiguraatioilla kuin kaikkein tuoreimmilla ja just ilmaantui yksi projekti, jota pitäisi edistää vanhemmilla konfiguraatioilla. Olisi mukava jos kansioexplorerini toimisi siitä huolimatta, millä versiolla kulloinkin pelailen. Ehkäpä tämä olisi juuri esimerkillinen tilanne tuolle itse rakentamalleni backend-kirjastolleni.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 30, 2022, 16:19:33
Lainaus käyttäjältä: -:)lauri - toukokuu 06, 2022, 14:32:29
^
Mun ei muuten tartte frontendissä määritellä erikseen linkkien sisältöä. Kun kukin nappi tekee vain yhden asian kerrallaan jo olemassa olevalle url-osoitteelle tai query-parametreille, voin rakentaa osoitteet valmiiksi backendissä. Jos siis oikein tajusin. Pitää tosiaan olla tekemättä mitään tälle projektille niin tulee näitä oivalluksia, jotka kertyessään säästävät minut turhalta työltä.

Olen nyt pyöritellyt tovin tuota ja huomannut, että selain enkoodaa ja dekoodaa erikoismerkit kiusallisella tavalla. Muutoin ei olisi ongelmaa, mutta kun kansioiden ja tiedostojen nimissä voi olla noita enkoodauskirjasimia tyyliin plussia, prosentti-merkkejä ja numeroita. Oikeaa kansioita tai tiedostoa ei vaan löydy jos ja kun selain tulkitsee jonkun tärkeän merkin enkoodaukseksi. Huomasin, että kun mulla on esimerkiksi kaks kansiota "http://localhost/toc" ja "http://localhost/toc2" ja kun osoiterivillä on myös nuo lainausmerkit, selain tulkitsee numeron 2 enkoodaukseksi koska lainausmerkki siinä vieressä enkoodautuu prosenttikirjasimiksi tms. ja dekoodaa tuon numeron 2 prosenttimerkkien kanssa pois osoitteesta, tulkiten osoitteen "http://localhost/toc2" osoitteeksi "http://localhost/toc". En saa nyt toc2-kansiota auki selaimesta vaan se avaa ja sulkee toc2-painikkeesta toc-kansion.

Pitää ilmeisesti sittenkin base64-enkoodata nuo osoitteet osoiteriville, jotta saan ongelman pois päiväjärjestyksestä. Pitää vain askarrella sivun ylälaitaan haamukenttä, jossa näkyisi osoitteet ihmisen ymmärtämässä muodossa ja johon voisi syöttää osoitteet ihmisen ymmärtämässä muodossa. Softa sitten vain pyöräyttäisi osoitteen osoiteriville base64-muodossa. Näin voisin säilyttää ominaisuuden, että voin tarvittaessa kirjoittaa tavoittelemani osoitteen, jos en jaksa selata sitä kansiopuusta nappeja klikkailemalla auki.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 20, 2022, 11:51:43
Alko uusi rojekti töissä ja pääsen tekemään sen "uusimmalla" teknolokialla; Laravelin 8:lla. Aloittelinkin jo mutta paljon on nyt pähkäiltävää.

Pitäisi ladata ui mutta en tiedä, pitäisikö ladata vue vai react -yhteensopiva ui vai tarvitaanko kumpaakaan tai edes ui:ta. Tein jo yhden lomakkeen ja siinä ei tarvita laravel ui:ta, mutta ehkäpä se olisi kehittämisen kannalta hyvä idea ladata se, kun se avaa enemmän mahdollisuuksia frontendin kehittämiseen. Ehkäpä otan vue-yhteensopivan ui:n käyttöön, kun Udemystä löytyi hyvä tutoriaali vue-yhteensopivan Laravel-projektin pystyttämiseksi.

Samaten Laravelin autentikointi ja tietoturva -käytännöt eivät ole minulle entuudestaan tuttuja, eivätkä ne vaikuta toimivan ihan noin vain. Framewokkiin lähetetyllä lomakkeilla tulee olla yksilöllinen tokeni, mutta jos tarvitsen staattiselle sivulle yhden ja toisen api-kutsuun, en tiedä, kuinka molemmat saadaan staattista sivua ladattaessa. Staattiselle lomakkeelle yhden tokenin saa helposti, mutta api-kutsun tokenin saaminen vaikuttaa vielä täysin mystiseltä.

Sitten pitäisi voida kirjautua yleiseen osioon tokenilla ja ylläpitopuolelle perinteisin käyttäjätunnuksin.

Projekti ei ole kamalan laaja, mutta onneksi olemme saaneet puhuttua sille pitkän kehitysajan. Eniten kun mulla menee aikaa Laravelin opetteluun ym osin ???
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 24, 2022, 19:11:07
^
datepicker-lisäpalikka on sitten veikeä komponentti. Ajatus oli duunaa toi vanilla javascriptillä ja Bootstrapin css-tyyleillä mutta ilmeisesti datepicker-komponenttia ei saa ilman jQuerya. Input-kentän "date" olisi ollut muuten hyvä, mutta esimerkiksi mun selain tarjoaa amerikkalaista päiväyksen esitystapaa, enkä tiedä kuinka pakottaa date-päiväys suomalaiseksi päiväykseksi, joten pakko yrittää saada sama lopputulos aikaiseksi lisäpalikalla. Saa nähdä, saanko text-input-kentän addon-napilla toimimaan kuten tuo vakiona tuleva date-kenttä, sillä erolla, että päiväyksen formaatti olisi datepickerillä tehtynä oikea.

Edit (27.10.2022): nuo pulmat ratkesivat suhteellisen kivuttomasti. Seuraavaksi pitää ratkoa miten kuluva päivä voidaan valita nyt kun sen on saanut eri väriseksi kuin muut kalenteripäivät ja kuinka kääntää kalenterin tekstit suomeksi. Taidan vain hakkeroida javascriptillä nuo tekstikentät ja muutan tekstit sillä tavalla myös suomen kielelle. Varmaan löytyisi tähän kylkeen joku kielikirjastokin, joka hoitaisi homman kotiin, mutta koska tarvitsemani muutokset ovat niin pieniä, tämä suunnittelemani kirjastoa huomattavasti ohuempi purkkaratkaisuni lienee tässä kohtaa perusteltu.

Edit (28.10.2022): Piti laittaa timeoutilla odottamaan sata millisekuntia, kun lataaminen kestää kauemmin kuin minkä javascript ottaa ennen kuin uusi näkymä widgetistä on näytöllä. Sitä vaan, että jos ei odota, alkuperäiset tyylit eivät muutu. Täytyy tarkistaa olisiko tuossa promiset käytössä, jos on, ei ehkä tartte timeouttia, vaan voi laitaa softa odottamaan latautumisen valmistumisen eksaktia kohtaa.

Pitäisi yrittää löytää muuttuja, jolla saa vaihdettua vuosia nopeasti. Se on muistaakseni yksi asetus, joka pitää laittaa päälle, mutta en tiedä, onnistuuko ihan sillä, vai pitääkö sekin toiminnallisuus kirjoittaa ihan itse jollain toisella tavalla. Tuo olisi aika kriittinen toiminto kun kalentereissa pitää pystyä laitamaan päivämääriä eri vuosille. Toivottavasti onnistuu ilman purkkaratkaisuja.

Samaten valittu päivä ei jostain syystä jää värjätyksi. Pitää ehkä googlailla, olisiko joku vakiomuuttuja, jonka asettaa päälle ja sitten sinne tallentuisi automaattisesti joku luokka, jonka voisi sitten css:llä korostaa taustavärillä. Ei tosin ole tällä hetkellä kriittinen asia. Varmasti onnistuu käyttö ilman tuotakin ominaisuutta.

Edit: En malttanut antaa olla vaan ratkaisin tuon vuosi-ongelman. Se tosiaan oli vain yhden muuttujan takana. Tosin meni tyylien märittelyyn taas tovi aikaa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 27, 2022, 11:56:08
^^
Lähdin liikkeelle helpoimman kautta. Olen rakentanut sivuston lähes kaikki sivut ulkonäöllisesti ja toiminnollisesti kuntoon. En ole ui:ta ladannut vielä, mutta mikäli onnistuu jo kirjoittamieni css- ja javascript-rivien siirto ui-ympäristöön päivitän järjestelmän ui-versioon. Ensi viikolla ehkä pääsee pohtimaan myös jo tietokantatauluja ja niiden sisältämien tietojen linkittämistä sivuille. Säästänen autentikoinnin ratkaisemisen viimeisiksi, sillä se on vielä aikalailla mysteeri vaikka jonkin laisia aihioita, kuinka tehdä se, on mieleeni jo juolahtanut.

Edit: Esittelin juuri tähän asti kasaan saamaani materiaalia asiakkaalle ja he olivat selvästi tyytyväisiä. Esimies oli myös. Alun perin esimies oli spekuloinut asiakkaalle, että ryhtyisin ensiksi rakentamaan taustalogiikkaa ja että sen vuoksi ei olisi tänään juurikaan näytettävää, mutta kun keksin lähteä rakentamaan ensin käyttöliittymää oli tavallaan "paljonkin" nyt näytettävää. Ensi palaverissa ei sitten tosin ole yhtä "paljon" uutta näytettävää, kun seuraavaksi alan ratkoa taustalogiikkaa, mutta toivottavasti saan paljon siitäkin ratkottua ennen uutta palaveria, jotta näkisivät edes jonkinlaista kehitystä projektissa (lähinnä, että sivuolla olisi tyhjien kenttien sijaan myös jotain tietokantasisältöäkin).

Edit (28.10.2022): Nyt on visu muuten kuosissa, mutta virhetilanteita varten tuleva sivu puuttuu ja ylläpito-sivut puuttuvat. Samaten tietueiden poisto on toteuttamatta. Pitää kysellä esimieheltä, millaista ideaa hän kannattaa. Laitanko listaukseen riville delete-napin, josta painamalla tietue poistuu vai jonkun valintaboksin kullekin riville ja listan alle napin, josta painamalla poistuu valitut tietuerivit, vai miten. No tämän kerkeää kyllä myöhemminkin. Ensi viikolla todennäköisesti pääsen siirtymään tietokannan rakentamiseen.

Edit: Pitää ensi viikolla asentaa vanhan palvelun tietokanta ja projekti, jotta voin paikallistaa minkä kentän arvo tallentuu mihinkin tietokantatauluun ja mihinkin ko. taulun kenttään. Onneksi ei ole kuin muutama taulu, mutta kenttiä on niissä todella paljon kun sivullakin on täyttökenttiä paljon. Täytän lomakkeet kirjoittamalla tekstikentiin uuden avaimet ja päivämääräkenttiin nousevalla/laskevalla logiikalla ja sitten paikallistan näin tietokantatauluista, mikä arvo on tallentunut mihinkin. Ehkei tuo ihan kamalan vaikea taski sitten olekaan... ...No ensi viikolla selvinnee. Esimies on messuilla kaiketi maanantaita lukuun ottamatta koko viikon, että olen aikalailla yksin projektin kanssa. Vanha järjestelmä on minulle entuudestaan tuntematon. Ehkäpä maanantaina saan vanhan järjestelmän asennettua ja ongittua esimieheltä, mistä mikäkin lomake löytyy niin onnistunee loppuviikko ilman opastusta. Ajatus on siis ottaa vanhasta järjestelmästä tietokanta ja syöttää niiden tietueet tähän uuteen järjestelmään.

Edit (08.11.2022): Viime viikko meni yhden akuutin projektin kanssa ja tällä viikolla taas päässyt tämän projektin pariin. Tää tietokantarivien liittäminen sivuille on kyllä varsin aikaa vievää puuhaa. Pitää olla pirun tarkkana, että kaikki oikeat muuttujat tulee luetuiksi oikeissa paikoissa. Sinällään kyllä hyvä, kun tekee tuota blokeissa, että eri routejen kohdalla pysyy muistissa kuinka samankaltainen operaatio tehtiin edellisessä routessa niin ei tarvitse testailla ihan niin usein kuin jos olisi tehnyt alusta loppuun aina yhden osion kerrallaan. No joo ehkä isommassa projektissa olisi ehkä fiksua tehdä jokin kokonaisuus kerralla valmiiksi, jotta asiakas pääsee testailemaan palvelun valmiita osia. Nyt kun tämä on ainakin toistaiseksi edennyt nopeasti on mahdollista, että koko palvelua testailemaan pääsee myös suht nopeasti. Kaikki riippuu siitä kuinka nopeasti onnistun toteuttamaan autentikoinnin ja kuinka nopeasti tämä saadaan vuorovaikuttamaan isäntäsoftan kanssa. Voi olla, että pitää tallentaa routeihin vielä muitakin avaimia kuin tuo yksi muuttuja. Samaten pitää muistaa muuttaa edit-buttonin toteutus form-muotoon sillä vain sillä tavalla voidaan varmistaa, että ei pääse hakkerit aktivoimaan editointia sivuston ulkopuolelta (liittyy tähän (https://en.wikipedia.org/wiki/Cross-site_request_forgery)). Muut buttonit toimivatkin jo form-periaatteella. Sitten kokonaan oma leikkinsä on se, kuinka vanhan järjestelmän tietokantarivit syötetään tälle uudelle järjestelmälle. Voi olla että menee tietokannan fundeeraaminen vielä uusiksi.

Edit (10.11.2022): Nyt on softan oma tietokanta liitetty käyttöliittymään. Seuraavaksi pitää rakentaa listoihin sekä paginointi, haku että sorttaukset. Tosin tämän palikan kehittämisessä pitää kaiketi yrittää opetella syöttämään tietokantaan riittävästi hölynpölysisältöä, jotta näkee kaikki tekemänsä jutut livenä. Laravelilla tuo pitäisi olla helppoa, mutta kun en muista, kuinka se tehtiin, menee siinäkin sitten oma aikansa, että palautan proseduurin mieleeni.

Samaten pitää tehdä lomakkeiden kenttien kohdalla validointi, että syötetty tieto kelpaa tietokantaan sekä laitettava käyttöliittymään asianmukaiset virheilmoitukset, jos on johonkin kenttään syötetty tietoa väärässä muodossa.

Näiden jälkeen pääsen varmaan autentikoinnin kimppuun. Ensi viikolla pitäisi olla uutta näytettävää asiakkaalle, mutta kuten jo viime kerralla ounastelin, eniten oli näytettävää silloin. Tällä kerralla olisi kiva jos olisi tuo listojen toiminnallisuus saatu tehtyä mutta voi olla, että menee sen osalta tuonnemmaksi.

Pitää myös palaveerata esimiehen kanssa tuosta tietorakenteesta. Olen nyt laittanut tämän toimimaan niin, että kaikkia lomakkeita voi täyttää lähes missä järjestyksessä tahansa. Pitää varmistaa josko olisi kanssani sama mieltä, että tarjotaan noita yksityiskohtaisempia lomakkeita vasta sen jälkeen kun niillä lomakkeilla on tallennettua tietoa, joihin nämä yksityiskohtaisemmat liittyvät "alilomakkeina".

Edit (22.11.2022): ollu hiukka muita projekteja mutta pääsin tämän kimppuun taas eilisestä. Asiakas oli viime viikolla jälleen tyytyväinen. Nyt on listojen haku, sorttaus ja sivutus (poislukinen pikalinkki vikalle ja ekalle sivulle). Samaten kaikki käyttäjältä tulevat tiedot validoidaan nyt. Liitin softan myös isäntäsoftaan. Seuraavaksi pitää selvittää miten isäntäsoftasta tullut hyväksytty ohjaus kirjaa asiakkaan sisään tähän mun palikkaan. Esimiehen kanssa käytyjen keskustelujen perusteella olen tehnyt tämän tähän asti ihan niin kuin oli ajatellutkin, joten ei tartte muuttaa mitään.

EDIT (2.12.2022): Seuraavaksi pitää tutustua Laravelin http-lisäpalikkaan guzzleen, jotta keskustelu isäntäsoftan kanssa onnistuu.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - lokakuu 27, 2022, 14:50:08
^^^
Yritän lähteä kehittämään seuraavanlaista sisäänkirjautumista.

1. Tähän microserviceen tultaessa pääpalvelusta, mukana annetaan tokeni.
2. Tietokannasta poimitaan kirjautumistiedot tokenilla.
3. Syötetään kirjautumistiedot normaalille login-logiikalle.
4. Ohjataan oikealla roolilla käyttäjä oikeaan paikkaan.

En tiedä onnistuuko kohta 3. En tiedä, mutta veikkaan, että middlewaressa pitäisi muuttaa tokeni pyynnöksi, jossa käyttäjätunnus ja salasana, mutta kun en tiedä, onnistuuko se enää tässä vaiheessa, vai olisiko pyyntö pitänyt muuttaa jo joskus paljon aiemmin kirjautumistiedot sisältäväksi pyynnöksi. Toivottavasti ei ja että tämä lähestymistapani toimii.

Sitten en tiedä tallentuuko sisäänkirjautumistiedot sivulle siihen tokeniin, jonka Laravel generoi automaattisesti vai pitääkö kaiken lisäksi hakkeroida sisäänkirjautumistidot jotenkin esimerkiksi sivujen header-tietoihin vielä erikseen.

Edit (28.10.2022): Sain nyt sivut siihen pisteeseen, että sisäänkirjautuminen voidaan tosiaan ratkaista myöhemmin. Nyt sivut toimivat järkevästi. Jokaisessa routessa on ylimääräisenä parametrina tietueen id sitä varten, että selatessa sivustoja voidaan tietueen tietoja käsitellä eri sivuilla. Muutoin routet toimivat Laravelin käytäntöjen mukaan poislukien tuo ylimääräinen parametri.

Edit (22.11.2022): Joo elikkäs nyt asiakas tulee isäntäsoftasta tähän softaan kuten pitää. Nyt vain pitää keksiä kuinka tuo kohta 3 tehdään. Eka pitää tutustua hieman laravelin autentikointiin, jotta selkeytyy voinko ohjata käyttäjän suoraan mahdolliseen login-controleriin tms. vai onnistuuko sisään kirjautuminen kokonaan toisen controllerin kautta.

Edit (2.12.2022): Näyttäisi siltä, että Laravelilla on ajateltu myös minua. Näin alustavasti vaikuttaa siltä, että autentikointi edellytti minulta ehkä noin 6 riviä koodia. Tuossa kohtaa kun olen validoinut tokenin, riittää kappale Laravelin valmiita funktioita kirjaamaan käyttäjä sisään. Hieman sessioiden resetointia sitä ennen ja lopuksi oleelliset routet yhden autentikointimiddlewaren taakse piiloon. Eli tämä oli lopulta helppo taski.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - joulukuu 07, 2022, 13:35:14
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
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 27, 2023, 18:07:29
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 02, 2023, 13:00:09
^
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 11, 2023, 17:12:28
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 13, 2023, 17:23:49
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 13, 2023, 18:46:09
Pitääpä kokeilla jossain välissä laravel sailia. Sillä ainakin saa tuota domainia muutettua.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - kesäkuu 17, 2023, 22:34:53
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - heinäkuu 01, 2023, 23:15:59
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 :D
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - heinäkuu 01, 2023, 23:55:22
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - heinäkuu 02, 2023, 00:54:58
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - heinäkuu 16, 2023, 15:03:45
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 (https://reactrouter.com/en/main/hooks/use-routes)) 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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Jaska - heinäkuu 31, 2023, 02:51:19
Lainaus käyttäjältä: -:)lauri - heinäkuu 16, 2023, 15:03:45

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 (https://reactrouter.com/en/main/hooks/use-routes)) 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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 08, 2023, 20:12:33
Lainaus käyttäjältä: -:)lauri - elokuu 08, 2023, 19:51:53
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 09, 2023, 13:06:01
^
Juu ei ole projektia:

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

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 18, 2023, 14:40:07
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ä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 25, 2023, 23:47:34
Yritän tässä motivoida itseäni pientä grafiikkaprojektia varten. Olen joskus pleistoseenikaudella väsännyt nämä kiemurtelevat viivat (https://lazydistribution.github.io/). 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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - elokuu 26, 2023, 08:20:36
^
Maallikkona sain vain tällaista aikaan: https://onecompiler.com/html/3zjng5gv6

::)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 26, 2023, 12:07:26
^
Hieno. Siitä se lähtee!

Tuossa minulla jokainen yksittäinen kiemura rakennetaan satunnaisesta määrästä "Cubic Bézier curve with four control points (https://en.wikipedia.org/wiki/B%C3%A9zier_curve)" -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
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - elokuu 26, 2023, 15:44:04
^^^
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 (https://www.youtube.com/watch?v=BjoM9oKOAKY), 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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 03, 2023, 02:01:26
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 17, 2023, 01:15:54
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?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - syyskuu 17, 2023, 07:58:21
MVC, poika sinä alat oppia!

(https://i.pinimg.com/originals/fe/b2/97/feb297877ecd01a5c672899453b71ebb.jpg)
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - syyskuu 17, 2023, 08:01:20
(https://media.tenor.com/eq3cq662rOEAAAAC/gene-cousineau-henry-winkler.gif)
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - syyskuu 17, 2023, 12:08:37
(https://media1.giphy.com/media/ZP3AeakRzpzFcYdLQe/giphy.gif)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 17, 2023, 12:16:57
 :D
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 26, 2023, 16:29:47
Jos tekee evoluutioalgoritmin pohjalta oppivan tekoälyn, mitkä olisivat hyviä ehdokkaita perintötekijöiksi? Tekoälyn painokertoimet ennen opettelua?
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - syyskuu 27, 2023, 07:56:57
Lainaus käyttäjältä: -:)lauri - syyskuu 26, 2023, 16:29:47
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
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - syyskuu 27, 2023, 08:53:03
^
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - syyskuu 27, 2023, 10:13:22
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - syyskuu 27, 2023, 10:30:14
Lainaus käyttäjältä: ROOSTER - syyskuu 27, 2023, 10:13:22
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.
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - syyskuu 27, 2023, 10:56:29
Lainaus käyttäjältä: Hippi - syyskuu 27, 2023, 10:30:14
Lainaus käyttäjältä: ROOSTER - syyskuu 27, 2023, 10:13:22
Minulla tahtoo mennä hermot kun välillä joutuu ohjelmoimaan hellan kellon.
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.

Me ollaan tässäkin samiksia. Luultavasti meillä on myös samanmerkkinen hella.   ;D :-* 8)
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - syyskuu 27, 2023, 18:24:22
Lainaus käyttäjältä: -:)lauri - syyskuu 26, 2023, 16:29:47
Jos tekee evoluutioalgoritmin pohjalta oppivan tekoälyn, mitkä olisivat hyviä ehdokkaita perintötekijöiksi? Tekoälyn painokertoimet ennen opettelua?

Bing:

Evoluutioalgoritmin pohjalta oppiva tekoäly voi olla hyödyllinen monissa sovelluksissa. Perintötekijät voivat olla esimerkiksi painokertoimia, jotka määrittävät, kuinka paljon kunkin ominaisuuden tulisi vaikuttaa tekoälyn päätöksentekoon. Ennen opettelua painokertoimet voidaan asettaa satunnaisesti tai valita järkevillä oletusarvoilla. Painokertoimien arvot voivat myös muuttua oppimisen aikana, kun tekoäly pyrkii optimoimaan suorituskykyään 1.

On tärkeää huomata, että tekoälyn kehittäminen on monimutkaista ja vaatii huolellista suunnittelua ja testausta. Eettiset kysymykset, kuten tekoälyn etiikka ja algoritmien oikeudenmukaisuus, ovat myös tärkeitä ottaa huomioon 2.

Toivottavasti tämä vastaus auttaa sinua! Kerro minulle, jos voin auttaa sinua jollain muulla tavalla.


ChatGPT:

Evoluutioalgoritmin pohjalta oppivan tekoälyn suunnittelu vaatii tarkkaa harkintaa perintötekijöiden ja alkuperäisten painokertoimien valinnassa. Tässä on muutamia seikkoja, jotka kannattaa ottaa huomioon:

Alkuperäiset painokertoimet: Alkuperäiset painokertoimet voidaan asettaa satunnaisesti tai käyttää jotakin lähtökohtaa, joka liittyy tekoälyn tavoitteisiin. Alkuperäiset painokertoimet voivat vaikuttaa suuresti siihen, kuinka nopeasti ja kuinka hyvin tekoäly oppii, joten niiden valintaan kannattaa panostaa.

Yksilölliset piirteet: Evoluutioalgoritmin avulla voit mukauttaa tekoälyn yksilöllisiä piirteitä. Voit harkita, mitkä tekijät ovat tärkeitä tekoälyn suorituskyvylle ja asettaa niille korkeammat alkuperäiset painokertoimet.

Risteytys ja mutaatio: Evoluutioalgoritmissa risteytyksen ja mutaation avulla luodaan uusia yksilöitä. Voit harkita, miten nämä operaatiot vaikuttavat painokertoimiin. Esimerkiksi voit lisätä mutaation todennäköisyyksiä painokertoimille, jotka ovat epäsuotuisia suorituskyvyn kannalta.

Kohdefunktion määrittely: Sinun on määriteltävä kohdefunktio, joka arvioi tekoälyn suorituskykyä. Tämä voi olla esimerkiksi ennusteen virhe tai muu tavoitearvo, joka halutaan minimoida tai maksimoida. Kohdefunktion määrittely vaikuttaa siihen, miten evoluutioalgoritmi arvioi yksilöiden soveltuvuutta.

Sukupolvien määrä ja koko: Määritä, kuinka monta sukupolvea evoluutioalgoritmi suorittaa ja kuinka monta yksilöä kussakin sukupolvessa on. Liian pieni sukupolvien määrä tai yksilöiden määrä voi hidastaa oppimisprosessia, kun taas liian suuri voi vaatia paljon laskentaresursseja.

Risteytysstrategia: Valitse risteytysstrategia, kuten yhden pisteen risteytys tai tasapainottava risteytys, joka sopii ongelmaan ja yksilöiden representaatioon.

Valintamenetelmä: Päätä, miten valitset yksilöt seuraavaan sukupolveen. Voit käyttää esimerkiksi turnajaisvalintaa, rulettipyörävalintaa tai muita menetelmiä.

Evoluutioalgoritmin parametrit: Säädä evoluutioalgoritmin parametreja, kuten risteytyksen ja mutaation todennäköisyyksiä, sukupolvien määrää ja muita hyperparametreja, kokeilujen perusteella.

On tärkeää huomata, että evoluutioalgoritmin tehokkuus voi vaihdella suuresti ongelman luonteen ja tavoiteltavan suorituskyvyn perusteella. Siksi on suositeltavaa suorittaa kokeita erilaisilla asetuksilla ja hyperparametreilla löytääksesi parhaan mahdollisen kokoonpanon tekoälyn oppimista varten. Evoluutioalgoritmiin perustuva oppiminen vaatii usein paljon resursseja ja aikaa, joten kärsivällisyys ja jatkuva optimointi ovat avainasemassa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: a4 - syyskuu 27, 2023, 19:06:50
Lainaus käyttäjältä: -:)lauri - syyskuu 27, 2023, 08:53:03
^
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.

Tämä sai itseni pohtimaan ajattelun ja evoluution samankaltaisuuksia.

Ajattelu simuloi tapahtumaketjuja joissa tapahtuu toimivuuteen perustuvaa valintaa.
Ajattelussa tapahtuu muutoksia ja ne voivat säilyä muistissa.
Muisti tallentaa ja tuottaa ajattelua.
Ajattelu on jatkuvassa vuorovaikutuksessa aistiympäristön kanssa.
Ajattelu saa ajatuksia toisten ajattelusta.

Siksi kai evoluutiota on sanottu sokeaksi kellosepäksi tai muurahaisia parviälykkäiksi.
Tai toisin sanoin ihmisaivot ovat vain evoluution kautta rakentunutta itsetietoisuuteen yltävää solujen parviälykkyyttä. 
Samoin evoluutioalgoritmeilla ja neuroverkkojen ajattelulla voidaan rakentaa itsetietoisuuteen yltävää koneellista ja algoritmista parviälyä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hippi - lokakuu 05, 2023, 09:00:35
Lainaus käyttäjältä: ROOSTER - syyskuu 27, 2023, 10:56:29
Lainaus käyttäjältä: Hippi - syyskuu 27, 2023, 10:30:14
Lainaus käyttäjältä: ROOSTER - syyskuu 27, 2023, 10:13:22
Minulla tahtoo mennä hermot kun välillä joutuu ohjelmoimaan hellan kellon.
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.

Me ollaan tässäkin samiksia. Luultavasti meillä on myös samanmerkkinen hella.   ;D :-* 8)

Niin taitaa olla monella muullakin :D

(https://media2.riemurasia.net/albumit/mmedia/uf/sqo/afan/504224/2115931521.jpg)
Otsikko: Vs: Ohjelmointi
Kirjoitti: ROOSTER - lokakuu 05, 2023, 10:16:09
^
Lapsuudessani meillä oli kotona SLEV-merkkinen sähköliesi. Taisi silloin olla kaikilla muillakin, elettiinhän yhtenäiskulttuurin kulta-aikaa. Jos SLEV -keittiönkiukaita vielä valmistettaisiin, niissä tuskin olisi nykyisenkaltaista, vaikeasti ohjelmoitavaa kelloa. Tai ei se oikeasti ole vaikea, pitää vain hoksata logiikka...Toisaalta, hellan käytön ei pitäisi olla asia joka vaatii keskittynyttä miettimistä ja logiikan peruskurssia.

Tuo SLEV on lyhenne sanoista Sähkö-Lämpö-Elektro-Värme ja yhtiön perusti Erik Isomaa 1939.

Lainaus käyttäjältä: https://fi.wikipedia.org/wiki/Erik_IsomaaIsomaan vanhemmat olivat konepajatyöläinen Immanuel Isomaa ja Ida Nikonen. Kolmetoistalapsinen perhe muutti 1918 Pietarsaareen. Isän kuoltua 1923 Isomaa joutui jättämään koulun kesken. Hän meni töihin Junnilan sähköasennusliikkeeseen 13-vuotiaana, missä tutustui myös sähkökojeiden ja laitteiden valmistukseen. Strengbergin tupakkatehtaassa työskennellessään hän hankki kirjekurssien avulla lisätietoja tekniikasta ja toimi vapaa-aikanaan radioasemalla lähestystekniikan hoitajana.

Tuo 13-vuotiaana töihin meno ei ole ehkä niin rankkaa mitä nykyihminen helposti ajattelee. Minäkin menin reippaasti duuniin (vakituiseen koko- ja jokapäivätyöhön) jo 14-vuotiaana keskikoulun jälkeen (sen jälkeen alkoi opiskelu innostaa enemmän). Silloin työtehtävät olivat helpompia oppia, eikä tahti ollut nykypäivän luokkaa. Vaihtoehtoisia töitä oli tarjolla, joten siksikin hyvistä ihmisistä yritettiin pitää kiinni. Kulttuuri oli erilainen, mitähän nykyään sanottaisiin kun 14-vuotias maalari saapuisi sutimaan makuuhuonetta uuteen kuosiin, yksin.

Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 29, 2024, 23:45:50
Olen kipuillut laravelin Pool-luokan kanssa ja vasta nyt keksin kysellä ChatGPT:ltä olisiko rinnakkaisten http-pyyntöjen tekemiselle Laravelissa järkeviä vaihtoehtoja. ChatGPT ohjasi laracast-palstan keskusteluun (https://laracasts.com/discuss/channels/laravel/multiple-async-calls-in-parallel-without-pool), jossa oli linkki videoon

https://www.youtube.com/watch?v=IJXzc46MFPM

jossa esiteltiin jotain tällaista kirjastoja, joka mahdollistaa asian.

Ennen kuin videolla päästiin kyseisen kirjaston esittelyyn, siinä esiteltiin alkuun muita vastaavia kirjastoja. Kuinka ollakaan, yksi tällainen kirjasto on ilmeisesti Guzzle. Sikäli hassua, että laravelin http-client on rakennettu guzzlen ympärille, eika ChatGPT osannut ottaa asiaa esille, kun kyselin vaihtoehtoja Pool-luokalle.

Haasteena on mulla ollut, miten käsitellä 429 virheet ja 401 virheet kun suoritetaan rinnakkaisia ajoja. 429 virhetyyppi edellyttää mahdollisesti useampia uusintapyyntöjä ja 401 virhe yhtä uusintapyyntöä.

Näiden haasteiden ratkaiseminen php:llä on monimutkaista. Tai siis vain sikäli monimutkaista, että kun olen tuota koodia pyörtiellyt muutaman päivän Pool-luokkaa käyttäen, en saa siitä sellaista, että koodin kulkua olisi vaivatonta seurata, ja tämä jos mikä, on hyvä indikaattori sille, että kummallisia virheilmoituksia on luvassa.

Guzzle kuitenkin näyttäisi tarjoavan mahdollisuuden hoitaa 429 virheet middlewaressaan:
<?php declare(strict_types=1);
require 
'vendor/autoload.php';

use 
Psr\Http\Message\{RequestInterfaceResponseInterface};
use 
GuzzleHttp\{ClientHandlerStackMiddlewareRetryMiddleware};

$maxRetries 3;

$decider = function(int $retriesRequestInterface $requestResponseInterface $response null) use ($maxRetries) : bool {
    return 
        
$retries $maxRetries
        
&& null !== $response 
        
&& 429 === $response->getStatusCode();
};

$delay = function(int $retriesResponseInterface $response) : int {
    if (!
$response->hasHeader('Retry-After')) {
        return 
RetryMiddleware::exponentialDelay($retries);
    }

    
$retryAfter $response->getHeaderLine('Retry-After');

    if (!
is_numeric($retryAfter)) {
        
$retryAfter = (new DateTime($retryAfter))->getTimestamp() - time();
    }

    return (int) 
$retryAfter 1000;
};

$stack HandlerStack::create();
$stack->push(Middleware::retry($decider$delay));

$client = new Client(['handler'  => $stack]);

Ja guzzle mahdollistaa rinnakkaisajot näin:
<?php
use GuzzleHttp\Client;
use 
GuzzleHttp\Promise;

$client = new Client(['base_uri' => 'http://httpbin.org/']);

// Initiate each request but do not block
$promises = [
    
'image' => $client->getAsync('/image'),
    
'png'   => $client->getAsync('/image/png'),
    
'jpeg'  => $client->getAsync('/image/jpeg'),
    
'webp'  => $client->getAsync('/image/webp')
];

// Wait on all of the requests to complete. Throws a ConnectException
// if any of the requests fail
$results Promise\unwrap($promises);

// Wait for the requests to complete, even if some of them fail
$results Promise\settle($promises)->wait();

// You can access each result using the key provided to the unwrap
// function.
echo $results['image']['value']->getHeader('Content-Length')[0]
echo 
$results['png']['value']->getHeader('Content-Length')[0]

Ja käyttäen yhtä ja samaa Client objektia näyttäisi homma tältä:
<?php
// [... 429 virheen käsittelystä vastaava koodi ...]
$client = new Client([
    
'base_uri' => 'http://httpbin.org/',
    
'handler'  => $stack
]);
// [... rinnakkaisista ajoista vastaava koodi ...]

Tällä konfiguraatiolla enää tarvitsisi minun huolehtia php:llä vain 401 virheen käsittelystä ja guzzle hoitaisi 429 virheen käsittelyn. Homma muuttui kertaheitolla kertaluokkaa paria helpommaksi.

Pitää yrittää vielä etsiä ratkaisua, jossa myös tuo 401 virhe voitaisiin käsitellä Guzzlen $stack-objetissa tai vastaavalla Clientille annattevan config objektin määrittelyllä. ChatGPT 4 ei selvästi osaa oikein auttaa. Hakee vastauksia kysymyksiini jatkuvasti Bingiltä. Ellen osaa kysyä oikeita kysymyksiä ei ChatGPT osaa kysyä Bingiltä oikein.

Nyt kun osasin kysyä suoraan ChatGPT:ltä, miten tokenin vanhentumisesta aiheutunut 401-virhe hoidetaan middlewaressa sieltä se tuli kuin apteekin hyllyltä:

<?php

use GuzzleHttp\Exception\RequestException;
use 
Psr\Http\Message\RequestInterface;
use 
Psr\Http\Message\ResponseInterface;
use 
GuzzleHttp\Middleware;

// Oletetaan, että meillä on funktio, joka hakee uuden tokenin
function getNewToken() {
    
// Logiikka uuden tokenin hankkimiseksi
}

$middleware Middleware::retry(function($retriesRequestInterface $requestResponseInterface $response nullRequestException $exception null) {
    
// Tarkistetaan, onko vastaus 401 Unauthorized
    
if ($response && $response->getStatusCode() === 401) {
        
// Logiikka uuden tokenin hankkimiseksi ja requestin uudelleenasettamiseksi
        
$newToken getNewToken();
        
// Asetetaan uusi token pyynnön Authorization-headeriin
        
return $request->withHeader('Authorization''Bearer ' $newToken);
    }

    return 
false// Ei uudelleenyritystä, jos ei ole 401-virhe
});

$stack HandlerStack::create();
$stack->push($middleware);

$client = new Client(['handler' => $stack]);

// Tee pyyntöjä Guzzle-clientillä...

ja vielä kun kysyin voiko nuo hoitaa kahdessa erillisessä middlewaressa, jotka molemmat laitetaan stack-objektiin push-komennolla? Niin kyllä se ChatGPT:n mukaan onnistuu.

Neljä päivää pähkäillyt, kuinka hoitaa nuo normaalit virhetilanteet niin kuin ne olisi järkevintä hoitaa, ja nyt vasta selvisi, että miten. Kaiketi olisin voinut kysellä joltain työkaverilta, mutta omilla harrasteluprojekteilla ei oikein kehtaa vaivata työkavereita.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - tammikuu 30, 2024, 00:54:55
On tuossa kyllä pari mahdollista virhetilannetta mitä tämäkin ratakasisu aiheuttaa. Koska nuo ajot ovat rinnakkaisia niin ajot eivät tiedä toisten ajohen statuksesta mitään ja jos ajot eivät toimi yhtä noipeasti 429 virheiden hoitaminen ei onnistu optimaallisesti. samoin jos yksi joutuu päivittämään tokenin niin mahdollisesti kaikki joutuu sen päivittämään. Tosin kun yksi on jo uusinut tokenin muiden ei tarvitsisi uusia sitä. Tokenin uusimisen voi vielä hallita helposti, mutta 429-onglema on tosiaan se, että serveri palauttaa Retry-After arvona eri lukuja riippuen siitä kuinka kauan yksi ajo kestää ja se ajo joka kestää pisimpään, antaa sen oikean retry arvon. Jos nopein ajo jo odottaa se odottaa liian vähän aikaa.

Ettei vaan pitäisi sittenkin vain käyttää Pool-luokkaa, kun kerran olisi optimaallista että 429 virheen sattuessa odotettaisiin niin kauan kuin on suurin Retry-After arvo sanoo ja ei tarvitsisi kuin luoda kertaalleen uusi token jos edes yksi palautusarvoista on ollut 401... Kylläpä tämä on pulmallista.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 03, 2024, 20:05:59
Opin juuri, miten Laravelin service providerissa korvataan injektoitu interface oikealla luokalla. Nyt on sitten oma projekti täynnä ratkaisuja :D
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 07, 2024, 11:08:37
Tietäkö joku, onko keinoa VS Codessa estää Github Copilottia lukemasta projektien ympäristömuuttujatiedostoja?

Omalla koneellani käytän kaikkia mahdollisia VS Coden -tekoälylaajennoksia surutta mutta firman koneella ja siten firman VS Codessa en ole käyttänyt tekoälylaajennoksia. Olen käyttänyt ChatGPT:tä selaimessa ja kysellyt neuvoa sitä kautta, joten se tapa estää tekoälyä pääsemästä käsiksi autentikointitietoihin.

Ilmeisesti voisi kuitenkin olla mahdollista laittaa laajennokset myös suoraan VS Code -koodieditorissa firman konella. Joku kysyi tietoturvaosastolta asiaa, niin kuulemma vasta testailevat tällaisia apureita, mutta että ilmeisesti kunhan noudataa firman tietoturvaohjeistusta, niin voisi käyttää.

Mulla ei ole firmankaan VS Codessa sellaisia asetuksia, että voisin käyttää firman repoja kirjautumatta joka kerta erikseen sisään, joten tuskinpa Github Copilotkaan pääsisi koneeltani käsiksi kaikken arkaluonteisimpiin materiaaleihin, poislukien projekteissani olevat ympäristömuuttujatiedostot.

Vaika noissakaan ympäristömuuttujatiedostoissa ei ole varsineisesti arkaluonteista tietoa, niin niilläkin tiedoilla saa firman yhteiset verkon yli tarjolla olevat testaysympäristöt sekaisin. Ainakin palvelimella olevien projektien, joita kehitän, testausympäristöjen tietokannat voi tyhjentää. Joten ennen kuin uskallan laittaa firman koneeseen noita laajennoksia, olisi hyvä, jos voisi jotenkin määritellä tiedostot, joita Github Copilot ei voi lukea.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 07, 2024, 13:16:42
ChatGPT ehdottaa, että tekisin PowerShell-skriptin, joka ajaa ympäristömuutujat Windowsin ympäristömuuttujiksi ja toisen skriptin, joka poistaa ne sieltä. Tallentaisin ne projektikansion ulkopuilelle enkä avaisi niitä koodieditorissa, jossa tekoälyapurieita sillä hetkellä päällä.

Eli noiden tekolyapureiden käyttämisen hintana tulisi ehkä tällaisia lisärutiineita.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 08, 2024, 04:38:07
Mitä eroa ympäristömuuttujien asettamisella on windowsin ja linuxin välillä? Onko jommalla kummalla mahdollista luoda erilaisia "profiileita", joilla erilaiset ympäristömuuttujat? Esimerkiksi pyyttonissa voidaan kaiketi määritellä kullekin projektille oma pyytton-ympäristö omine muuttujineen(?) Onistuuko jokin tällainen windowsilla tai linuxilla?
Otsikko: Vs: Ohjelmointi
Kirjoitti: Lenny - helmikuu 08, 2024, 08:38:23
Lainaus käyttäjältä: -:)lauri - helmikuu 08, 2024, 04:38:07Mitä eroa ympäristömuuttujien asettamisella on windowsin ja linuxin välillä? Onko jommalla kummalla mahdollista luoda erilaisia "profiileita", joilla erilaiset ympäristömuuttujat? Esimerkiksi pyyttonissa voidaan kaiketi määritellä kullekin projektille oma pyytton-ympäristö omine muuttujineen(?) Onistuuko jokin tällainen windowsilla tai linuxilla?

Tokihan tuo on mahdollista molemmissa luomalla tiedosto, jossa asetetaan "Muuttuja=arvo" ja sitten ajetaan sisään komentoriviltä tarpeen mukaan. Muuttujat ovat sitten voimassa siinä konsolisessiossa josta ne on ajettu. En näe mitään eroa Windowsin ja Linuxin välillä tässä asiassa.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - helmikuu 08, 2024, 12:49:47
Lainaus käyttäjältä: Lenny - helmikuu 08, 2024, 08:38:23
Lainaus käyttäjältä: -:)lauri - helmikuu 08, 2024, 04:38:07Mitä eroa ympäristömuuttujien asettamisella on windowsin ja linuxin välillä? Onko jommalla kummalla mahdollista luoda erilaisia "profiileita", joilla erilaiset ympäristömuuttujat? Esimerkiksi pyyttonissa voidaan kaiketi määritellä kullekin projektille oma pyytton-ympäristö omine muuttujineen(?) Onistuuko jokin tällainen windowsilla tai linuxilla?

Tokihan tuo on mahdollista molemmissa luomalla tiedosto, jossa asetetaan "Muuttuja=arvo" ja sitten ajetaan sisään komentoriviltä tarpeen mukaan. Muuttujat ovat sitten voimassa siinä konsolisessiossa josta ne on ajettu. En näe mitään eroa Windowsin ja Linuxin välillä tässä asiassa.

Mietin tätä käydessäni pyyttonilla. ;D

Asiattomuuden jälkeen komppaan asiallisesti Lennyä. Ei noissa pitäisi olla käytännössä mitään eroa. Oletan, että Laurin sovellus pyörii sovelluskerroksessa ja ehkä kutsuu jotain käyttöjärjestelmätason palveluja tarvittaessa. Jälkimmäistä vartenhan ovat asennuksessa paikoilleen pistetyt ympäristökirjastot. Pythonkin on jo niin monennessa versiossa, että aika spesiaalitapaus saa olla, että ei toimisi win/lin vaikka toisessa toimii.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Lenny - helmikuu 08, 2024, 13:20:02
Lainaus käyttäjältä: -:)lauri - tammikuu 29, 2024, 23:45:50Guzzle kuitenkin näyttäisi tarjoavan mahdollisuuden hoitaa 429 virheet middlewaressaan

Kysymys liittyen näihin koodiblokkeihin: miten teit nuo? Ihmettelen nimittäin mistä nuo fontin värit tulevat. Tässä tummassa teemassa on pakko pitää valkoista (tai hyvin vaaleaa) tausta blokissa, koska muuten nämä nimeomaiset värit menevät puuroksi. Valkoinen tausta taas sattuu päähän muuten tummassa teemassa.

Onko värit siis bb-koodilla laitettu?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 08, 2024, 18:43:51
Lainaus käyttäjältä: Lenny - helmikuu 08, 2024, 13:20:02
Lainaus käyttäjältä: -:)lauri - tammikuu 29, 2024, 23:45:50Guzzle kuitenkin näyttäisi tarjoavan mahdollisuuden hoitaa 429 virheet middlewaressaan

Kysymys liittyen näihin koodiblokkeihin: miten teit nuo? Ihmettelen nimittäin mistä nuo fontin värit tulevat. Tässä tummassa teemassa on pakko pitää valkoista (tai hyvin vaaleaa) tausta blokissa, koska muuten nämä nimeomaiset värit menevät puuroksi. Valkoinen tausta taas sattuu päähän muuten tummassa teemassa.

Onko värit siis bb-koodilla laitettu?

En minä värejä laittanut tarkoituksella, mutta kun laittaa koodi-blokin alkuun php-avaustägin "<?php" se näyttäisi värittävän koodin.

<?php

function jepa() {

}


function jepa() {

}
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - helmikuu 08, 2024, 18:53:28
Lainaus käyttäjältä: Hayabusa - helmikuu 08, 2024, 12:49:47
Lainaus käyttäjältä: Lenny - helmikuu 08, 2024, 08:38:23
Lainaus käyttäjältä: -:)lauri - helmikuu 08, 2024, 04:38:07Mitä eroa ympäristömuuttujien asettamisella on windowsin ja linuxin välillä? Onko jommalla kummalla mahdollista luoda erilaisia "profiileita", joilla erilaiset ympäristömuuttujat? Esimerkiksi pyyttonissa voidaan kaiketi määritellä kullekin projektille oma pyytton-ympäristö omine muuttujineen(?) Onistuuko jokin tällainen windowsilla tai linuxilla?

Tokihan tuo on mahdollista molemmissa luomalla tiedosto, jossa asetetaan "Muuttuja=arvo" ja sitten ajetaan sisään komentoriviltä tarpeen mukaan. Muuttujat ovat sitten voimassa siinä konsolisessiossa josta ne on ajettu. En näe mitään eroa Windowsin ja Linuxin välillä tässä asiassa.

Mietin tätä käydessäni pyyttonilla. ;D

Asiattomuuden jälkeen komppaan asiallisesti Lennyä. Ei noissa pitäisi olla käytännössä mitään eroa. Oletan, että Laurin sovellus pyörii sovelluskerroksessa ja ehkä kutsuu jotain käyttöjärjestelmätason palveluja tarvittaessa. Jälkimmäistä vartenhan ovat asennuksessa paikoilleen pistetyt ympäristökirjastot. Pythonkin on jo niin monennessa versiossa, että aika spesiaalitapaus saa olla, että ei toimisi win/lin vaikka toisessa toimii.

Niin siis käytän duunissakin paljon Laravel-php -kirjastoa, ja siinä on .env-tiedosto sitä varten, että saa laitettua projektille ympäristömuuttujat.

Ongelma kuitenkin muodostuu tekoäkyapureiden kanssa. Vaikka ne eivät tällä hetkellä siirrä koodia käyttäjän koneelta verkon yli muualle, niin kun kehitys kehittyy koskaan ei tiedä milloin se alkaa siirtää koodia esim. omaksi opetusmateriaalikseen. Kun tekoäly sitten harjoittelee arkaluontoisella materiaalilla, se ehdottaa sitä kohta jollekin toiselle käyttäjälle ja huonolla mäihällä meidän firman arkaluontoiset tiedot ovat pian julkisia. Pitää olla extravarovainen.

Jos saisi nuo ympäristömuuttujat projektin ulkopuellelle, niitä ei ehkä niin helposti tekoälukoodieditorilla availe. Eli jonkilaiset  käyttöjärjestelmätason skriptit pitäisi ilmeisesti kirjoittaa, jotta saisi näppärästi eri projekteille eri ympäristömuuttujat.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 01, 2024, 13:22:49
Lainaus käyttäjältä: -:)lauri - tammikuu 30, 2024, 00:54:55On tuossa kyllä pari mahdollista virhetilannetta mitä tämäkin ratakasisu aiheuttaa. Koska nuo ajot ovat rinnakkaisia niin ajot eivät tiedä toisten ajohen statuksesta mitään ja jos ajot eivät toimi yhtä noipeasti 429 virheiden hoitaminen ei onnistu optimaallisesti. samoin jos yksi joutuu päivittämään tokenin niin mahdollisesti kaikki joutuu sen päivittämään. Tosin kun yksi on jo uusinut tokenin muiden ei tarvitsisi uusia sitä. Tokenin uusimisen voi vielä hallita helposti, mutta 429-onglema on tosiaan se, että serveri palauttaa Retry-After arvona eri lukuja riippuen siitä kuinka kauan yksi ajo kestää ja se ajo joka kestää pisimpään, antaa sen oikean retry arvon. Jos nopein ajo jo odottaa se odottaa liian vähän aikaa.

Ettei vaan pitäisi sittenkin vain käyttää Pool-luokkaa, kun kerran olisi optimaallista että 429 virheen sattuessa odotettaisiin niin kauan kuin on suurin Retry-After arvo sanoo ja ei tarvitsisi kuin luoda kertaalleen uusi token jos edes yksi palautusarvoista on ollut 401... Kylläpä tämä on pulmallista.

Joo tein sitten itse ja säästin. 429 virheen tarkistus jää ikuiseen luuppiin. Enkä ole ennättänyt kokeilla kunnolla hahmotelmaani 401 ja 403 virheiden käsittelylle, ties vaikka nekin jäisivät ikuiseen luuppiin. Pitää yritää ratkoa nuo joskus kun on aikaa eikä duunissa ole liian kiirettä. Viime aikoina saaanut oppia töissä paljon uutta ja luonnollisesti osa opinnoista on sitten vappaa-ajasta pois :D
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 21, 2024, 16:59:52
Lainaus käyttäjältä: -:)lauri - maaliskuu 01, 2024, 13:22:49Joo tein sitten itse ja säästin. 429 virheen tarkistus jää ikuiseen luuppiin. Enkä ole ennättänyt kokeilla kunnolla hahmotelmaani 401 ja 403 virheiden käsittelylle, ties vaikka nekin jäisivät ikuiseen luuppiin. Pitää yritää ratkoa nuo joskus kun on aikaa eikä duunissa ole liian kiirettä. Viime aikoina saaanut oppia töissä paljon uutta ja luonnollisesti osa opinnoista on sitten vappaa-ajasta pois :D

Tällä viikolla on ollu aikaa väkertää tätä. Muuten saanut tuon toimimaan, mutta jos headereissa ei tule retry afteria, tuo korottaa odotusaikaa jokaiselle haulle eksponentiaalisesti: 2s, 4s, 8s... aina 64 sekuntiin asti.

Ongelma:

Jos on 20 haettavaa tietuetta ja ratelimit on 5 tietuetta kerralla ekat tulee heti ja tokat kun on odotettu 2 sekuntia. Nyt seuraaville 5:lle tulisi myös 2 sekuntia (jos se kerran riittää), mutta tää mun implementaatio korottaa tuossakin kohtaa exponentiaalisesti hakua, joten se odottaa 4 sekuntia seuraaville 5:lle ja lopuille 5:lle sen 8 sekuntia.

Pitää jotenkin tallentaa tuo odotustaika, joka riittää ja sitten käyttää sitä, mutta jos ei riitä, sitten korotetaan eksponentiaalisesti. En vain vielä tiedä, miten tuo tallentaminen kannattaa tässä implementaatiossa tehdä.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 22, 2024, 12:29:01
^
nyt tuo tallentaminen toimii, eli ei kasvata odotusaikaa, ellei tarvitse. Seuraavaksi alkaa sitten testaaminen. Pitää yrittää keksiä mahdolliset ongelmatpaukset.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 22, 2024, 17:22:20
^^
muutaman tunnin manuaalisella testaamisella sanoisin, että toimii. Seuraavaksi voisi kirjoittaa unit-testit niin ei tarvitsisi manuaalisesti testata kaikkea. Sen jälkeen voisi lisätä tuon päälle jonkun sovelluksen ja kun unit testit olisivat paikoillaan olisi ikään kuin elämä helpompaa, kun onnistuisi paikalistaa virheen aiheuttaja ilman 6 tunnin manuaalista testaamista.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 22, 2024, 18:42:41
^
Tuossa helpotti huomattavasti se, että määritin request-objektin ja response-objektin. Pitää vielä määritellä listaobjekti request-objekteille ja listaobjekti response-objekteille. Näin minulla olisi niin hyvä kontrolli, kuin PHP-kieli mahdollistaa siihen, ettei luokkieni välillä ja niiden sisällä käsitellä tietotyyppejä, joita ne eivät osaa käsitellä. Tai siis tietysti luokkien sisällä käytän tavallisia listoja, eli luokkien sisällä on mahdollista luoda virheellisiä tietotyyppejä, mutta tärkeintä olisi, että luokkia ei voi käyttää kuin tiedetyillä tyypeillä, jolloin on paremmat saumat tosiaan paikallaistaa virhe juuri siihen luokkaan, jossa virhe tapahtuu.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 22, 2024, 21:21:09
^
No enhän minä malttanut. Tein myös nuo listausobjektit. Nyt tuota mun härdelliä ei pysty käyttämään, ellei luokille anna oikeantyyppistä objektia.
Otsikko: Vs: Ohjelmointi
Kirjoitti: Hayabusa - maaliskuu 23, 2024, 08:32:58
Jos Lauri ei lopeta lomalla koodausta, T-X tulee ja terminoi.
(https://images-wixmp-ed30a86b8c4ca887773594c2.wixmp.com/f/5daf088f-84ae-4be1-9ebe-a92116b4245c/d8gtor8-942b8ff0-bf60-4941-b37a-15ea869a5b31.jpg/v1/fill/w_1178,h_678,q_75,strp/terminator_3___t_x_by_moviesbro-d8gtor8.jpg?token=eyJ0eXAiOiJKV1QiLCJhbGciOiJIUzI1NiJ9.eyJpc3MiOiJ1cm46YXBwOjdlMGQxODg5ODIyNjQzNzNhNWYwZDQxNWVhMGQyNmUwIiwic3ViIjoidXJuOmFwcDo3ZTBkMTg4OTgyMjY0MzczYTVmMGQ0MTVlYTBkMjZlMCIsImF1ZCI6WyJ1cm46c2VydmljZTppbWFnZS5vcGVyYXRpb25zIl0sIm9iaiI6W1t7InBhdGgiOiIvZi81ZGFmMDg4Zi04NGFlLTRiZTEtOWViZS1hOTIxMTZiNDI0NWMvZDhndG9yOC05NDJiOGZmMC1iZjYwLTQ5NDEtYjM3YS0xNWVhODY5YTViMzEuanBnIiwid2lkdGgiOiI8PTExNzgiLCJoZWlnaHQiOiI8PTY3OCJ9XV19.3sN7OZ9E2aCVJPhIcfW1sng7jVuGaUf5EaUym-1UhDc)
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 23, 2024, 18:32:05
Ei ole ollut VS Code auki tänää sekuntiakaan, joten toistaiseksi sujunut loma suunnitelmien mukaan.

Minkäköhänlainen rasti olisi ohjelmoioda laskluri sosiaalituille? Olisi helpompi seurata julkista keskustelua noista esim. asumistukien leikkauksista, kun olisi jokiu käsitys mikä niiden vaikutus olisi eri ihmisten taloudelliseen itsemääräämisoikeuteen; ihmisten jotka siis elävät joko kokonaan tai osittain tukien varassa.

Kelan sivuilla on eri laskurit eri tukimuodoille (https://www.kela.fi/laskurit), mutta ymmärtääkseni jokaisen laskuriin täytyy syöttää samoja tietoja yhä uudestaan ja uudestaan. Aivan turhaa näpyttämistä. Olisipa rasti ruutuun-lomake, minkä tuen osalta haluaa tiedot tuen määrästä, johon on oikeutettu ja sitten tuo yksi lomake, joka kysyy rastitettujen tukimuotojen kannalta olennaiset tiedot.

Onko Kelalla kenties api, josta saisi tarvittavat tiedot tällaiselle laskurille?
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 23, 2024, 21:36:52
Löysin hyvän väriteeman VS Codeen: Rainglow-väriteema-kirjastossa oli useampi tumma vaihtoehto, jotka miellyttivät silmää.
Otsikko: Vs: Ohjelmointi
Kirjoitti: -:)lauri - maaliskuu 24, 2024, 19:12:21
https://aijs.io/editor

Jos kiinnnostaa tehdä simppeleitä javascript-taideteoksia, joita siis selain jaksaa pyörittää, tuo vaikuttaa olevan hyvä vaihtoehto p5.js sivuston editorille. Tosin tämä edellyttää, että on joko ChatGPT-avain tai Gemini-avain, jotta saisi apua tekoälyltä, mutta jos on avain ja omaksi iloksi koodailu kiinnostaa, tuota kannattaa kokeilla.