Tarinoita "konepellin alta"

Communities Suomi (Finland)
1

Tarinoita “konepellin alta”…Tarinassa myös pieni opetus lopussa.

Trailmapin OSM-datan päivittymisessä on ollut arviolta vajaan kuukauden ongelma, jossa OSM-datasta poistetut väylät eivät ole poistuneet kartalta eivätkä reitityksestä. Ongelman nosti minulle tiedoksi yksi OSM-polkukartoittajista, Tatu, 3 päivää sitten. Siitä alkoi intensiivinen salapoliisityö ongelman juurisyyn selvittämiseksi.

Lopullinen syy löytyi OSM-maailman keskeisimmistä työkaluista (osmium, libosmium, pyosmium), joihin elokuussa 2025 tehty bugikorjaus oli tuottanut sivuvaikutuksena Tatun havaitseman bugin. Bugi ilmeni kun Geofabrikista ladattuja OSM-datan palasia (ns. ekstrakteja) päivitti OSM-työkaluilla ajantasalle (esim. pyosmium-up-to-date). Bugin luonteesta kertoo se, että Geofabrikin ylläpitäjä ei uskonut ensimmäistä bugiraporttiani, koska ei saanut sitä heti toistettua ja “olisihan tälläinen bugi huomattu jo aiemmin, on niin iso vaikutuksiltaan”. Geofabrik on maailman merkittävin OSM-datan jakelija, jota käyttää suurin piirtein kaikki sovellukset, jotka eivät käsittele koko maapalloa (“planet”-tiedostoa).

Tein lisää selvitystyötä ja nyt bugi on tunnustettu ja korjaus tulee aikanaan. Trailmapissa on tehty paikko siirtymällä OSM-työkaluissa vanhempiin versioihin, joissa ei tuota bugia ole.

Kiehtovaa miten hyvin näin merkittävä bugi oli onnistunut piileskelemään useamman kuukauden. Trailmap:kin törmäsi tosin siihen vasta kun päivitin ym. OSM-työkalut niiden uusimpiin versioihin. Sitten vaadittiin vielä tarkkaavainen kartoittaja.

Keskeiset avoimen lähdekoodin OSM-työkalut ovat melkoisen isoja kokonaisuuksia vanhaa ja uutta koodia, josta ei liikoja arkkitehtuuri yms. dokumentteja löydy. Vastuu niiden päivittämisestä ja vikakorjauksista lepää pitkälti pienellä joukolla ylläpitäjiä - samalla kun projektien käyttäjiä on paljon ja moni käyttäjistä myös spämmaa aika surutta ylläpitäjiä kaikenlaisilla kysymyksillä ja vaatimuksilla, joihin olisivat itsekin voineet ensin tehdä hieman selvitystöitä pohjalle. Nämä projektit kaipaavat siten kaiken avun mitä niille voidaan antaa, jotta OSM:n perusta pysyy kunnossa.

Kun havaitsette jotain outoa OSM-dataan liittyvää, niin reippaasti vain lapaa pystyyn ja ilmoitusta - tällä tapaa ne bugit löytyy ja joskus päästään tälläisen isomman vonkaleen jäljille.

(Loppuun vielä kuriositeettina hetki kun ohjastamani Claude Code löysi juurisyyn ongelmalle. Nämä tekoälyapulaiset ovat kyllä mielettömän hyödyllisiä juuri OSM-työkalujen kaltaisten isojen koodimassojen selvittelytyössä. Ilman Claudea olisi tässä mennyt todennäköisesti useampi päivä enemmän.)

image
image2048×1012 265 KB

5 Likes
2

Minä teen työni paikkatiedon kaupallisella puolella ja sielläkin on kiistatta bugeja. Alalla vallitsee jonkinlainen hurmos siitä, että avoin on aina parempi, mutta tuo sinun mainio tarina kertoo enemmän siitä, että sekä jonkun omistamassa tai avoimessa koodissa haasteet ovat suunnilleen samat. Ohjelmistobugin löytyminen on aina kiinni tuurista ja usein myös jonkun ihmisen sinnikkyydestä selvittää joku outo ilmiö. Ainoa ero avoimen ja kaupallisen ohjelmiston välillä on siinä kenen vastuulla korjaus on, eli avoimessa teoriassa voit korjata sen itse - kaupallisessa sinun pitää pyytää joku korjaamaan se - mahdollisesti rahaa vastaan.

Olen paljon raportoinut kaupallisella puolella ohjelmistobugeja. Se on aina juuri tuon kaltainen prosessi, jossa selvität ongelmaa monelta kantilta ja koetat lopulta yksilöidä sen syyn. Kun siihen ongelman ytimeen lopulta pääsee kiinni sen raportoiminen on helppoa, mutta matka sinne on yleensä hyvin työläs. Teoriassa kai voi sanoa. että tuo ei toimi korjatkaa, mutta kyllä oma kokemukseni on, että sillä raportilla bugikorjauksen toivominen on aika uskon varassa.

Jaan murheesi - teen tuota jos nyt en joka päivä niin ainakin kuukausittain ja se on kyllä kieltämättä aika paljon sinnikkyyttä vaativaa hommaa. Toisaalta sitten kun se homma tulee kuntoon ja ohjelmisto tekee sen mitä lupaa, niin onhan se palkitseva hetki.

3

@tikola tuosta omasta tarinasta ja vastaavista aiemmista nousee pari asiaa pinnalle: 1) Reippaiden käyttäjien & käyttäjäyhteisöjen merkitys bugien havainnoimisessa (käytännössä siis joukkoistettu testaus) ja 2) Avoin lähdekoodi + tekoälytyökalut (“AI coding agents”) uutena vahvana yhdistelmänä.

Tekoälytyökalujen merkityksestä avoimelle lähdekoodille ei ole vielä kovin paljoa keskusteltu ja kommentit ovat hajanaisia, puolesta ja vastaan. Omat havainnot, erityisesti OSM-kontekstissa, ovat kuitenkin erittäin positiivisia: isoja & tyypillisesti heikosti dokumentoituja projekteja on nyt merkittävästi helpompi ottaa käyttöön, korjata bugeja ja laajentaa niiden ominaisuuksia. OSM:lle tällä on mielestäni suuri (positiivinen) merkitys, koska OSM-maailman ohjelmistotyökalut ovat pitkälti avointa lähdekoodia (+ Mapbox suljettu hiekkalaatikko).

4

Joukkoistettua se testaus on kaupallisellakin puolella, eli toki valmistaja jotain testaa, mutta kaikkea ei testata ja lopulta se toimivuus sitten siellä käyttäjäpäässä selviää, jonka voi katsoa olevan ihan samanlaista joukkoistettua testausta. Tuo AI Agenttihomma on kiistatonta - kerro minulle mikä tässä koodissa menee pieleen, niin se kyllä kertoo sen aika luotettavasti ja erittäin nopeasti.

5

Samat mekanismit molemmin puolin, mutta painotukset eroavat.

Alkuperäiseen keissiin liittyen Geofabrikin Frederik vei bugiraportin eteenpäin ja ratkaisuna aiemmin tehty koodimuutos työkaluihin perutaan (revert): Change in behaviour when applying diffs that delete objects with same version number · Issue #403 · osmcode/libosmium · GitHub - ratkaisu löytyi nopeasti kun pieni ryhmä näiden työkalujen ytimessä olevia toistensa tuntevia tekijöitä pallotteli vaihtoehdot lävitse. Avoimessa lähdekoodissa on hienoa tämä läpinäkyvyys prosessiin - suljetuissa ohjelmistoissa ei aina tiedä mitä (josko mitään) tapahtuu omille bugiraporteille (jollei satu olemaan isompi asiakas toimittajalle).

6

No tuo on totta - suljetussa korjauksella on joku korjaavan organisaation priorisointisysteemi ja se tuskin on missään läpinäkyvä. Joskin aika hyvä oletus on se, että ne korjataan ensiksi millä se korjaava firma tienaa eniten rahaa.