Ohjelmointi

[-:)lauri]

^

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

[-:)lauri]

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.

[kertsi]

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..

[-:)lauri]

^
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.

[-:)lauri]

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ää.

[Jaska]

Mikä on docker?

[-:)lauri]

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.

[-:)lauri]

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.

[-:)lauri]

^
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.

[-:)lauri]

^
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ää.

[-:)lauri]

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.

[-:)lauri]

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.

Koodi [Valitse] Laajenna


<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

Koodi [Valitse] Laajenna


[
    {
        "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

Koodi [Valitse] Laajenna


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

Koodi [Valitse] Laajenna


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)

Koodi [Valitse] Laajenna


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

Koodi [Valitse] Laajenna


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;
}


[-:)lauri]

^
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

Koodi [Valitse] Laajenna


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.

Koodi [Valitse] Laajenna


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;
}


[-:)lauri]

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.

[-:)lauri]

^
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.