Yritin ostaa junalipun Jyväskylään. VR:n netissä toimiva lippupalvelu ei kuitenkaan hyväksynyt paluun kellonaikaa, vaan antoi siitä itsepintaisesti virheilmoituksen. Lippu jäi ostamatta.
Monen kokeilun ja turhan yrityksen jälkeen paljastui, että vika olikin lähtöajassa. Kun lähtöä siirsi riittävästi eteenpäin, paluun kellonaika kelpasi:
Lopulta ongelman syy selvisi: lipunmyyntijärjestelmä vertaa lähtö- ja tuloaikoja merkkijonoina, ei numeroina. Tällä logiikalla kello 6 aamulla on myöhempi aika kuin kello 22 illalla (koska "6" > "22"). Lähtövaraus esim. 1:15 onnistuu, kunhan paluu on 20 jälkeen, koska merkkijonoina "1:15"<"20". Aamukymmenestä eteenpäin varaus toimii oikein, koska nelinumeroisissa luvuissa käsittely merkkijonoina tuottaa saman tuloksen kuin numeerinen vertailu.
On siinä asiakkaalla ihmettelemistä, mitä hän oikein tekee väärin. Ei mitään, kyse on ohjelmoijan mokasta.
Tämä ei ole mikään tavallinen bugi. Matkalippujen myynti on VR:n ydinliiketoimintaa. Yhä suurempi osa lipunmyynnistä tapahtuu netissä. Lipunmyyntijärjestelmä on siten VR:n operatiivinen tietojärjestelmä. Siinä ei voi olla tällaista bugia. Ei vain voi.
Ikään kuin tässä ei vielä olisi tarpeeksi, muistin törmänneeni samankaltaiseen vikaan kaksi vuotta aiemmin. Silloinkin liian varhainen lähtöaika (kolme numeroa) antoi virheilmoituksen, mutta sentään oikeaan kenttään.
Valitukseni jälkeen tämä bugi sentään korjattiin. Nyt samassa kohdassa on uusi, entistä kummallisempi vika, joka on Twitter-vastauksesta päätellen ollut VR:n tiedossa. Sitä ei vain ole korjattu. Eikö VR ole kuunnellut lainkaan asiakaspalautetta? Eikö sen IT-toimittaja ole testannut järjestelmää lainkaan?
Numeroiden vertaaminen merkkijonoina on alkeellisin mahdollinen virhe, jollaisia yleensä tekevät peruskoululaiset ensimmäisissä ohjelmointiharjoituksissaan. Sen pitäisi paljastua vähäisessäkin testauksessa, Äkkiseltään ei tule mieleen toista näin alkeellista IT-ongelmaa. Tekisi mieli puhua suorastaan törkeästä osaamattomuudesta yhdistettynä täydelliseen piittaamattomuuteen. Onko muulla kuin monopoliyhtiöllä varaa tällaiseen?
Kenelle me, jotka olemme kärsineet tästä ongelmasta ja tuhlanneet sen vuoksi aikaamme -- tehden lopulta testauksen, joka kuuluisi IT-yritykselle -- voimme lähettää laskun?
Muokattu klo 16:10: vian taustalla ei näytäkään olevan lähtöajan numeromäärä vaan väärien tietotyyppien vertailu, kiitos @mvarti (Mikko Vartiainen).
Lisäys 19:50: VR ei ilmeisesti pidä kiirettä bugin korjauksella, kun ei ole pitänyt tähänkään asti. Vähintään sen pitäisi lisätä varaussivulle varoitusteksti, joka kertoo miten ongelman voi kiertää. Nyt monelta jää lippu ostamatta tämän vuoksi. Ironista on, että palvelun oma avusteteksti antaa ymmärtää kellonajan kelpaavan monessa eri muodossa.
Lisäys 2.10.2014 klo 15: Bugi näyttää tulleen korjatuksi. Ilmeisesti julkinen kohu sai VR:n laittamaan vauhtia rattaisiin.
 |
| Paluuaika väärin kirjoitettu -- mitä ihmettä? |
 |
| No nyt kelpasi! |
On siinä asiakkaalla ihmettelemistä, mitä hän oikein tekee väärin. Ei mitään, kyse on ohjelmoijan mokasta.
Tämä ei ole mikään tavallinen bugi. Matkalippujen myynti on VR:n ydinliiketoimintaa. Yhä suurempi osa lipunmyynnistä tapahtuu netissä. Lipunmyyntijärjestelmä on siten VR:n operatiivinen tietojärjestelmä. Siinä ei voi olla tällaista bugia. Ei vain voi.
Ikään kuin tässä ei vielä olisi tarpeeksi, muistin törmänneeni samankaltaiseen vikaan kaksi vuotta aiemmin. Silloinkin liian varhainen lähtöaika (kolme numeroa) antoi virheilmoituksen, mutta sentään oikeaan kenttään.
 |
| Elokuu 2012: VR-lipunmyynti ei hyväksy numeroa 9, pitäisi olla 09. |
Valitukseni jälkeen tämä bugi sentään korjattiin. Nyt samassa kohdassa on uusi, entistä kummallisempi vika, joka on Twitter-vastauksesta päätellen ollut VR:n tiedossa. Sitä ei vain ole korjattu. Eikö VR ole kuunnellut lainkaan asiakaspalautetta? Eikö sen IT-toimittaja ole testannut järjestelmää lainkaan?
Numeroiden vertaaminen merkkijonoina on alkeellisin mahdollinen virhe, jollaisia yleensä tekevät peruskoululaiset ensimmäisissä ohjelmointiharjoituksissaan. Sen pitäisi paljastua vähäisessäkin testauksessa, Äkkiseltään ei tule mieleen toista näin alkeellista IT-ongelmaa. Tekisi mieli puhua suorastaan törkeästä osaamattomuudesta yhdistettynä täydelliseen piittaamattomuuteen. Onko muulla kuin monopoliyhtiöllä varaa tällaiseen?
Kenelle me, jotka olemme kärsineet tästä ongelmasta ja tuhlanneet sen vuoksi aikaamme -- tehden lopulta testauksen, joka kuuluisi IT-yritykselle -- voimme lähettää laskun?
Muokattu klo 16:10: vian taustalla ei näytäkään olevan lähtöajan numeromäärä vaan väärien tietotyyppien vertailu, kiitos @mvarti (Mikko Vartiainen).
Lisäys 19:50: VR ei ilmeisesti pidä kiirettä bugin korjauksella, kun ei ole pitänyt tähänkään asti. Vähintään sen pitäisi lisätä varaussivulle varoitusteksti, joka kertoo miten ongelman voi kiertää. Nyt monelta jää lippu ostamatta tämän vuoksi. Ironista on, että palvelun oma avusteteksti antaa ymmärtää kellonajan kelpaavan monessa eri muodossa.
 |
| Kellonaika kelpaa eri muodoissa... NOT. |
Aika uskomaton moka, kun on tottunut laadukkaita Amerikkalaisia palveluita käyttämään.
VastaaPoistaNäitä on ollut yllin kyllin pitkin matkaa. Accentureko edelleen näitä tekee? Käyttöliittymässä oli pitkään virhe, joka esti saapumisajan käyttämisen hakukriteerin vaikka näyttö tarjosi tällaista vaihtoehtoa. Nyttemin TÄMÄ virhe on korjattu
VastaaPoistaNiin, miten se monopoli saisi ne yksityiset firmat kuriin, jotka toimittavat tällaisia järjestelmiä?
VastaaPoista"Numeroiden vertaaminen merkkijonoina on alkeellisin mahdollinen virhe"
VastaaPoistaEi ihan näinkään. Numeroiden vertailu onnistuu kyllä myös merkkijoina. Silloin vain on varmistettava että molemmat vertailtavat merkkijonot ovat muotoiltu oikein.
Esimerkkitapauksessasi olisi kellonaikaa voitu verrata muodossa
"06:00" vs. "22:00". Eli 24- tuntisessa järjestelmässä ei olisi ollut mitään ongelmia.
Toki myös päivämäärä tulisi vielä ottaa huomioon ensisijaisena vertailutekijinä
Aikojen vertaaminen aikatyyppisenä datana voi olla myös virhealtista. Tässä datassa pitää huomioida aikavyöhyke ja kesäaika, jos aika tallennetaan täydellisenä aikaleimana. Ehkäpä koodari ei muistanut API-dokumentaatiosta ulkoa, miten tämä aika koodataan ja oikoi kätevästi merkkijonojen suuruustarkistuksella. Tämä kun on mahdollista moderneissa kielissä kätevästi :)
VastaaPoistaVaimolle kävi niin, että VR:n automaagi ei voinut tulostaa lippua sen jälkeen kun se oli maksettu. Eli rahat meni, ei lippua ja aspassa ei osattu neuvoa kunnolla. VR = Venaa Rauhassa.
VastaaPoistaSinne Accenturen tuotepäällikölle terveisiä että jospa laitat sinne määrittelydokumenttiin jatkossa että päivämäärien parsinnassa käytetään vaikkapa momentjs-kirjastoa niin ei tarvitse alusta asti ruveta keksimään.
VastaaPoistaKai Järvinen ymmärrät että "6" > "22" ei päde vaan kyseessä on yksinkertaisemmin "6" > "2", jonka jälkeen vertailu pidemmälle on turhaa. Nuo vertailut voi tehdä huoletta merkkijonovertailuina kunhan tieto on ensin saatettu määrämuotoon - "0600" vs. "2200" palauttaa aina oikean tuloksen riippumatta tiedon tyypistä.
VastaaPoistaVR:n kädettömyydestä ollaan samaa mieltä - vieläkö verkkokauppa on tunteja kiinni joka yö "eräajojen" vuoksi?
Aika hurjaa vaatia potkuja tälläisten virheiden tekijöille.
VastaaPoistaEt voi tietää taustoja mistä tämä johtuu. Oliko esim. homma annettu ylityöllistetylle koodariparalle 2h varoitusajalla, kun ensin hommaa on kierrätetty managementin palavereissa kuukausitolkulla?
Managementille tässä pitäisi antaa huutia: missä on kunnollinen testaus? Oliko nekin rahat "säästetty" johdon boonuksiin.
Kai Järvinen ymmärrät että "6" > "22" ei päde vaan kyseessä on yksinkertaisemmin "6" > "2"
VastaaPoistaYmmärrän toki, itsekin näitä nuoruudessani tehneenä. Tietokoneen kannalta vertailu tapahtuu tavu kerrallaan (jolloin 6>2), mutta käyttäjän ja sovelluslogiikan näkökulmasta 6>22. Juuri tämä on se virhe.
Aika hurjaa vaatia potkuja tälläisten virheiden tekijöille.
Jos lääkäri erehtyy vasemmasta ja oikeasta, onko vika sairaalan johdon? Oli kiire tai ei, näin alkeellista mokaa ei yksinkertaisesti saa tehdä.
Jos sairaalan johto teetättää jatkuvasti lääkärillä ylityötunteja ja lääkäri väsyneenä tekee virheen, kenen on vastuu? Entä jos lääkärille kerrotaan vamman olevan vasemmassa kädessä, mutta unohdetaan mainita, että käsi onkin vasen edestä päin katsoen?
PoistaMiksi nykyään kaikkien pitää lynkata julkisesti kaikkia? Jokainen meistä tekee virheitä, ja niiden jatkuva alleviivaaminen ei ole millään tasolla rakentavaa.
VastaaPoistaJos tällainen virhe pääsee tuotantokäyttöasteelle, on aivan kohtuullista lynkata selväsanaisesti. Jos taas oltaisiin tuon palvelun tekijävaiheessa ja sen työryhmässä niin siellä hyväntahtoinen ohjaus riittää. Ja tietenkin siinä testausvaiheessa, siellä voisi ohjata kannustavasti... tai edes testata.
Poista"Jokainen meistä tekee virheitä, ja niiden jatkuva alleviivaaminen ei ole millään tasolla rakentavaa. "
VastaaPoistaVäärin. On ymmärrettäviä virheitä ja sitten on täysin käsittämättömiä virheitä ja näitä jälkimmäisiä ei saa tehdä.
Vai tarjoatko samaa selitystä kun ajat autolla päin punaista 2 promillen kännissä ja poliisi tulee kyselemään että mitäs tämä tämmöinen on?
Se, että ei osaa verrata kahta (triviaalia) kellonaikaa, on tätä jälkimmäistä osastoa.
Korjausten viipyminen vaikuttaa näin täysin ulkopuolisen silmään siltä, että toimittaja (Accenture?) laskuttaa näistä suolaisesti ja VR pyrkii minimoimaan muutosten tilaukset ja siksi lykkää niitä.
VastaaPoistaVR:n verkkokaupan Android-sovelluksen ensimmäiset versiot olivat varsin bugisia, alkaen siitä, että kirjautuminen sisään Veturi-asiakkaana ei toiminut monellakaan laitteella. Uutta versiota sovelluksesta ei tullut ainakaan puoleen vuoteen ja bugit olivat korjaamatta, vaikka VR varmasti sai kitkerää palautetta runsain mitoin. Tuoreessa versiossa viime kesäkuulta (reilu vuosi ensimmäisen version jälkeen) näyttäis enimmät ongelmat olevan korjattuna, ainakin omalla kapulallani kokeiltuna.
Normi päivä.
VastaaPoistaOnhan VR:n ohjelmisto toimittaja sentään laadukkaista ohjelmistoistaan tunnettu Tieto :D
Bugi ei todennäköisesti ole ainoa.. Ja niitä jätetään hyvin yleisesti tahallaan toimitettuihin järjestelmiin, jotta niitä voidaan laskuttamalla "korjata" jatkossa.. Näillä nuo talot takoaa rahaa
Eipä ole, vaan vaan A:la alkava verrokki. Sinällään molemmat kykenevät tuottamaan hyvää laatua, tässä tapauksessa ongelma lienee että softa on viety Intiaan kohdattava jossa kukaan ei välitä paikan vertaa asiakkaalle toimitettavan tuotteen laadusta ja koodin ovat vain juuri "yliopiston" portista ulos kävelleet...
PoistaYrittäkääpä ostaa auto-juna menopaluuta Helsingistä Rovaniemelle. Osoittautui myös liki ylitse-pääsemättömäksi, kun lähtöpaikaksi laittoi Pasilan lastauspaikan.
VastaaPoistaJohtunee siitä, ettei junasta voi jäädä paluusuuntaan Pasilan autojuna-asemalle. Autovaunut vain irrotetaan perästä ja muu juna jatkaa Pasilan aseman kautta Helsinkiin käymättä autojuna-aseman laiturissa.
VastaaPoistaVarmaankin Javascripti virhe. Koodari on unohtanut muuttaa merkkijonon numeroksi ennen vertailua. Merkkijonoja sitten vertaillessa verrataan merkkijonojen merkkejä järjestyksessä - eli "6" > "2". "6" tulee merkkikoodistossa "2" jälkeen, joten se on suurempi. Aika tyypillinen Javascript virhe, joka johtuu kielen huonosta suunnitellusta ja koodarin huolimattomuudeesta (useimmat kielet heittävät virheilmoituksen käännösvaiheessa, kun yrität vertailla kokonaisia merkkijonoja keskenään relaatio-operaattoreilla). Toivottavasti raportoit virheen VR:llä.
VastaaPoistaHei, älkääs haukkuko Accenturea tästä. Kyllä ne on virheensä tehneet mutta satun tietämään että tällä kertaa sen javascript-frontin teki ihan joku muu taho ...
VastaaPoista" Lähtövaraus esim. 1:15 onnistuu, kunhan paluu on 20 jälkeen, koska merkkijonoina "1:15">"20"."
VastaaPoistaMillä perusteella "1:15" > "20"?
Minusta tässä vaikuttaa silitä, että nämä kaksi bugia ovat toisistaan riippuvaisia. Suunnittelija ajatteli, että tunnit syötetään etunollien kanssa. Tällöin homma toimi. Sitten joku virittelijä muutti systeemiä niin, ettei etunollaa tarvittu ottamatta huomioon muutoksia muualla. Yksinkertainen tapa olisi ollut normalisoida aika etunollalliseksi heti syötön jälkeen.
VastaaPoistaLuultavasti ihmiset yleensä syöttävät kellonajat etunollan kanssa, joten virhe tulee harvoin esiin. Etunollan edellyttäminen tällaisissa systeemeissä ei ole niin harvinaista.
Petterin kaikesta päätellen piti kirjoittaman että "1:15" < "20" koska sitähän siinä verrataan: lähdön on oltava ennen tuloaikaa.
VastaaPoistaSuurin moka tässä on ylipäätään että jos aikoja nyt joka paikassa merkittäisiin ISO 8601-formaatissa niin kaikki merkkijonovertailut olisivat aina oikein. Päivämäärienkin välillä.
Yllä piti kirjoittaman että *paluuaika.
VastaaPoistaMutta, systeemi neuvoo että päivämäärän voi kirjailla myös 06:00 muodossa, millä muuten onnistuukin. Ilmeisesti on siis jälkikäteen vaadittu että 6:00-muotoa voisi käyttää ja muutosta ei ole testattu...
Kyseinen bugi on muuten vain etusivun portaalissa. Mutta joo, mitäpä muuta sitä voi odottaa, kun palkkaa aina sen halvimman koodarin kalleimmasta firmasta.
VastaaPoistaVirheet ei ole sallittuja! Ristiinnaulittakoon! Ristiinnaulittakoon!
VastaaPoistaVirheet eivät ole sallittuja! Korjattakoon! Korjattakoon!
VastaaPoistaSuurin osa bugeista vaikuttaa yksinkertaiselta, mutta bugin havaitseminen kirjoitus / testausvaiheessa voi olla yllättävän vaikeaa. Esimerkiksi tyypitön ohjelmointkieli JavaScript mahdollistaa tuommoisten bugien syntymisen helposti. Vahvasti tyypitetyssä kielessä tuommoinen vertailu jäisi kiinni jo käännösvaiheessa. Ohjelmoijalla ei todennäköisesti ollut muuta vaihtoehtoa kuin kirjoittaa tuo koodi JavaScript -kielellä. Kokeneemmalla ohjelmoijalla typpikonversio tulee selkärangasta, mutta se voi joskus vain unohtua. Käyttöliittymän testaus vaatii erityistä huolellisuutta: Ihmisen on vaikea ymmärtää, että jos ajan tarkastaminen toimii 10:00 - 22:00 ja se toimii 06:00 - 18:00 niin se ei toimisikaan yhtäkkiä jollain toisella vertailulla. Toisaalta ihmistestaaja voi syöttää ajan 06 eikä "6", jolloin bugia ei saa kiinni. Lisäksi vielä, jos olisi tehty jonkinlainen automatisoitu regressiotestipatteri, joka olisi ajanut automaattisesti kaikki mahdolliset kellonajat virhettä ei olisi välttämättä huomattu lainkaan, koska tällöin kellonajat olisi luultavasti automaattsesti oikeassa muodossa "06:00" - "12:00" ja automaattinen testi ei saisi virhettä kiinni. Regressiotesti olisi saanut viheen kiinni ainoastaan, jos siihen olisi tehty ikäänkuin virhettä ennakoiden syötteitä "6:00" eikä "06:00", mutta tämäkin vaatii sen että testin kirjoittaja aavistaa virheen synnyn. Todennäköisesti tuo ominaisuus on tehty ikäänkuin auttamaan käyttäjää, työmääräksi on arvioitu joku 2-3 tuntia ja siksi toteutusporukka ei ole ajatellut rekrytöidä muutosta tekemään 20 hengen testaustiimiä. Koodaajan syyllistäminen tuosta on siis mielestäni täysin turhaa.
VastaaPoistaYlipäänsä VR:n sivujen käyttöliittymän suunnittelu on kelvotonta ja käytettävyy kehnoa. Sen pitäisi pullauttaa koko valitun päivän junayhteydet kerrallaan, mistä olisi sitten helppo valita järkevä juna.
VastaaPoistaSe että se näyttää yksi tai kaksi junaa yhdellä näytöllä ei ole mitään muuta kuin käyttäjien kiusaamista. Sen jotenkin ymmärtäisi että halutaan käyttäjä viipymään sivustolla mahdollisimman pitkään, jotta saadaan mainoksille mahdollsiimman paljon näkyvyyttä, mutta käsittääkseni VR:n sivulla ei ole muita kuin VR:n omien palveluiden mainoksia.
Tällaiset yksityiskohdat vain kertovat siitä ettei sivuston suunnittelijalla ole juurikaan tervettä järkeä.
Korjasin "1:15" < "20", kiitos tarkkaavaisuudesta.
VastaaPoistaKritiikkini ei kohdistu pelkkään virheeseen vaan siihen, että VR on ollut tietoinen tästä pitkään, eikä ole saanut sitä korjattua - ei edes varoitustekstiä sivulle kertomaan, että ylimääräistä nollaa käyttämällä varaus onnistuu.
Mahdollisesti bugi johtuu kirjoituksen jälkimmäisestä ongelmasta. Aikoinaan varaus epäonnistui juuri silloin, kun etunollaa ei käytetty. Koodia korjattiin niin, että jos asiakas kirjoitti "6", sivu vaihtoi sen itse muotoon "06".
Jossain vaiheessa tämä automaattinen täydennys lienee pudonnut pois ja silloin vertailu on lakannut toimimasta oikein.
Potkut Petterille kun ei osaa kirjoittaa suurempi kuin -merkkiä oikein päin
VastaaPoistaEn tiedä lukeeko kukaan tänne asti, mutta huvittavintahan tässä on se, että erilaisen web 2.0 / html5 -rinki**kkarit ylistävät html:ää ja javascriptiä, eivätkä suostu näkemään, että silloin ennen vanhaan kun APIna oli win16, win32, delphi, visualbasic, java swing tai mitä näitä nyt on, niin näissä kaikissa oli vahvasti tyypitetyt time- ja date-komponentit erikseen. Nyt kun on "kehitytty", niin web-teknologiat ovat paljon huonompi tapa tehdä mitään.
VastaaPoistaWebbiinkin on rakennettu myöhemmin frameworkkeja, jotka "kääntävät" koodin sivuksi. Mainitaan nyt Yesod, Ur/Web ja tällaiset. Ikävä vaan suomalaiset koodarit ja toki myös alihankitut intialaisheput ovat täysin kädettömiä eivätkä ymmärrä näistä mitään. Sen siitä saa kun yliopistossa kovasti koittaisivat opettaa moderneja työkaluja ja lintsaavat luennolta, ruikuttavat gradun tarpeettomuudesta ja ovat jo 1-2 vuoden jälkeen lähes kokonaan työelämässä "ratkomassa" näitä ongelmia.
Silti, vaikka webbiin olisi jotain "oikeita" ratkaisuja, jotka estävät tällaisia bugeja, niin webin ongelmana on se, että myös umpisurkeat noviisitekniikat pitävät päänsä pinnalla (php), vaikka niitä saa jatkuvasti olla korjaamassa.
Tätä ihmettelin Tivin kolumnissani: miksi kylpyhuoneremontin tekijältä vaaditaan märkätilasertifikaatti, mutta web-sovelluksia pääsee koodaamaan kuka tahansa (jos vain yritys palkkaa).
VastaaPoistaLuultavasti sitä nollaa ei oltu koskaan lisätty ennen vertailua. Koodaajat ovat testanneet sen toiminnan ilman etunollaa vain yksittäisenä ilman tuota meno-paluun testaamista. En usko, että vahvemmin tyypitettykään kieli olisi auttanut.
VastaaPoistaKuten bugit yleensäkin, tämä on varsin yksinkertainen jälkikäteen, mutta testatessa välttämättä tapaus ei tule mieleen.
Tämä toki osoittaa merkkijonona vertaamisen riskejä. Koodi, jonka toimivuus perustuu muualla tehtyihin oletuksiin ei ole kovin vakaata. Samoin virheilmoituksen raportoinnissa on ongelma. Siinä oletetaan, että menomatkan aika on oikein. Kysehän on näiden kahden arvon epäsuhdasta keskenään.
Petteri, löytämäsi bugi osoittaa käytännössä automaattisten testien puuttumisen tai niiden puutteellisen toteutuksen.
VastaaPoistaVR:n lippukauppa on varmasti yksi heikoimmin toteutetuista lippukaupoista Suomessa. Olen itse törmännyt sivulla useampaan bugiin ja lukuisiin featureihin, jotka osoittavat puutteellista ymmärrystä käytettävyyssuunnittelusta ja suoranaista piittaamattomuutta käyttäjän tarpeista. Näitä bugeja ja featureita ei myöskään korjata, vaikka monet niistä ovat varmasti ylläpitäjän tiedossa. Ulkoistettu kehitysprojekti on varmaankin ylittänyt budjetin niin pahasti, että VR on viheltänyt pelin poikki ja beta-vaiheessa ollut viritelmä on julkaistu sellaisenaan.
Tällaisen monopolin ei selvästi tarvitse välittää asiakkaistaan, joten ongelmaan on kaksi ratkaisua:
1) vapautetaan raideliikenne kilpailulle, jolloin kilpailutilanne pakottaa VR:n huolehtimaan riittävästä palvelutasosta
2) määritetään mitattava vähimmäistaso palvelulle, mikä VR velvoitetaan tuottamaan
Järviseen yhtyen, koodaajat ulos ja Accenturelle julkinen ripitys.
VastaaPoistaTäällä on monenlaista neuvoa Javascript, uudet web teknologiat ym skeidaa. Vanhana cobol -koodaajana (nyt saa nauraa) ja nykyisin satoja php/MySql -ohjelmia tehneenä minulla on tapana ottaa käyttöliittymän syöte haltuuni, vaikkapa PHP -ohjelmassa. Jos minulle tarjotaan kellonaikaa, niin otan sen vastaan nöyrin mielin vaikka 6, 06, 6.0, 6:0, 6.00, 6:00 ja muut kombinaatiot 06... Se vaan on helvetin helppoa tarkistaa, mitä käyttäjä oikeasti tarkoittaa. Ei käyttäjän antamaa merkkijonoa voi suoraan vertailla mihinkään, sen validiteetti täytyy tutkia ja tarvittaessa antaa palaute jos se ei nyt mihinkään kellonaikaan matchaa. Helpompi käyttäjälle voi olla valintaluettelo tms.
Suoraan sanoen hävettää näiden isojen ITC -talojen toiminta.
Se oikea ratkaisu onkin enemmän "algoritminen" kuin kielitekninen. Uusilla kielillä voidaan koodata formaalit säännöt, jotka estävät tietynlaisten virheiden muodostumista koodatessa. Tämä on iso apu, mutta ei mikään lopullinen turvaverkko.
VastaaPoistaIsompi periaate on, että käyttäjän syöte jäsennetään ja analysoidaan ja tehdään tarkasti tiedossa olevalla datalla bisnesoperaatiot. Tähän riittää COBOL. VR:n kauppa on loistoesimerkki siitä, kun iso valtion organisaatio haluaa jotain ja lopputulos on hyvin kaukana siitä, mikä on totuttu laatutaso jo ihan ilmaisissa open source -kauppakomponenteissa.
Vikahan on oikeasti siinä, että VR ei ole itsellä hallussa koodarin koodaria. Jos olisi, tuo olisi jo korjattu. Toki pitäis varmaan osata sopia myös jos päätyy ostamaan palveluna koko järjestelmän. Esim. Takuuna pitäis tuollaiset korjaantua, mutta jos ei oo sovittu niin ei sit oo takuutakaan. Tai jos ostaa, niin sopii että omat koodarit tai 3 osapuoli voi saatua avointa / yhteisomistettua koodia muokata.
VastaaPoistaOnkos muuten ikinä saatu tietoa, miksi Suomeen piti rakentaa oma VR-lippukauppasysteemi kun maailma on niitä täynnä jo valmiiksi. Samoin pitää joka kylään rakentaa oma bussilippusysteemi vaikka jostain ulkomaan kaupungista löytyy valmis parempi joka hoitelee satakertaisen liikenteen tarpeet.
VastaaPoistaTiedostosta out.js:
VastaaPoistaMatkahakuHelper.queryContext.find("[name=returnTimeTab1]").val()<MatkahakuHelper.queryContext.find("[name=startTime00Tab1]").val()
Tuossa nimenomaan verataan naiivisti JQueryllä noudettujen kenttien arvoja toisiinsa, ja stringejä kun ovat, niin vertailu menee niiden aakkosjärjestyksen mukaan.
Aika luokatonta koodia noin yleensäottaen.
Olisi myös mukavaa maksaa pankkikortilla, vaikka käyttääkin yrityksen tunnuksia. Nyt siellä on mahdollista vain luottokorttimaksut...
VastaaPoistaJos koodi ei edes ymmärrä jakaa minuuteja ja tunteja osiin... tuo on osoitus siitä että webkoodaajista ollaan tekemässä oikeita ohjelmoijia, mutta kokemus, osaaminen ja koulutus ei ole kunnossa. 80-luvulla oltiin keksitty jo lähes kaikki ohjelmointiin liittyvä, nykyiset ohjelmoijat keksivät näitä nyt uudelleen, minä itse tästä hyvänä esimerkkinä. Esim futuurit ja promiset kehitettiin jo 1976-77, nykyiset itseoppineet eivät ymmärrä enää edes perustietorakenteita, joita 80-luvulla koodattiin muistipaikkatasolla ja sen ajan ihmisille stringin ja integerin vertailun ongelmat ovat ilmiselviä. Nykyään katsotaan että jos osaa jQueryä tai Angularia tai jotain on client-side guru
VastaaPoistaOnkohan kukaan VR:n ongelmista kärsinyt koittanut konkreettisesti selvittää: "Kenelle me, jotka olemme kärsineet tästä ongelmasta ja tuhlanneet sen vuoksi aikaamme -- tehden lopulta testauksen, joka kuuluisi IT-yritykselle -- voimme lähettää laskun?"
VastaaPoistaLähes kaksi vuosikymmentä testaajana toimineena olin itseeni melkein pettynyt oivaltaessani ensi kertaa eilen että sen sijaan että _raportoin_ käyttäjänä näkemiäni ongelmia, raportin perään pitäisi aina lähettää reklamaatio ja vaatia hyvityksiä menetetystä ajasta.
Tässä tapauksessa virhe estää maksamasta alkujaankaan palvelusta, eli yritykselle saattaa koitua jo siitä vahinkoa - vähintään sen verran että tarvitsee sen asiakaspalvelijan aikaa. Omassa tuoreimmassa tapauksessani joka oivalluksen tuotti maksan kuukausihintaa palvelusta, joka ei ollut viiteen päivään käytössäni.
Ehkä laatutietoisuuden voisi toivoa palaavan jos kustannukset asiakkaille aiheutetusta lisätyöstä tosiaan tulisivat ohjelmistoa tekevän organisaation näkyviksi kustannuksiksi reklaamatioiden kautta?
Omassa tapauksessani lähetin reklaamaationi asiakaspalveluun, josta se välitettiin hallintoon - aiheuttanee siis vähintään käsittelyssä työtunteja sielläkin päässä. Odotan vielä mielenkiinnolla mikä vastaus tulee olemaan ja päätän onko tarvetta etsiä muita reittejä oikeudenmukaisen palvelun arvioimiseen.
Petter Järvinen kirjoitti
VastaaPoista"
Mahdollisesti bugi johtuu kirjoituksen jälkimmäisestä ongelmasta. Aikoinaan varaus epäonnistui juuri silloin, kun etunollaa ei käytetty. Koodia korjattiin niin, että jos asiakas kirjoitti "6", sivu vaihtoi sen itse muotoon "06".
Jossain vaiheessa tämä automaattinen täydennys lienee pudonnut pois ja silloin vertailu on lakannut toimimasta oikein."
Mainitsemasi korjaus on tehty aikoinaan varsinaiseen nettikauppaan shop.vr.fi. Etusivun hakulaatikko, jossa nyt löytynyt bugi on, on tehty täysin eri koodipojalta. Kuten joku mainitsikin, niin se on ilmeisesti eri toimittajan tekemä.
Etusivun hakulaatikkokin tarkistaa ja lisää etunollan, mutta tätä tietoa ei käytetä kellonajan tarkistuksessa eikä muuteta syöttökenttään. Tarkistettu tieto talletetaan lomakkeen piilotettuun kentään, joka lähetettäisiin sitten varsinaiseen nettikauppaan shop.vr.fi.
Onko Petteri itse virheitä tekemätön jumala? Ei ole.
VastaaPoistaPitäisikö Petterille antaa kenkää tästä syystä? Ei. Paitsi Petterin itsensä mielestä pitäisi.
Petteri saa toki ilmoittaa bugista ja vaatia sitä korjattavaksi mutta se, että haluaa antaa kenkää koodin kirjoittajalle on jo sen luokan aivopieru, että pitäisi miehen "statuksella" ymmärtää asia. Ilmeisesti ei kuitenkaan ole vielä ymmärtänyt, että kaikki koodaajat tekevät virheitä ja virheiden määrä on suhteellisen vakio koodin määrän suhteen.
Jos tästä pitää jotain syyttää se on QA joka ei ole huomannut virhettä. Tässäkin tapauksessa QA:n erottamisen vaatiminen osoittaa junttimaista öykkäri-asennetta. Siinä ei vain ole mitään muuta järkeä kuin, että Petteri nyt haluaa puhaltaa vähän höyryjä.
Virheettömiä järjestelmiä ei ole. Virheiden tekeminen on myös välttämätöntä. Jos niitä ei tehtäisi, myös testaaminen olisi loogisesti turhaa.
VastaaPoistaVirheitä tekemällä niiden etsimisen, löytämisen ja korjaamisen prosesseja voidaan parantaa.
Kannustusta paineiden alla raataville. Tehkää virheitä. Me muut yritämme kannustaa johtoa ja omistajaa keskittymään korjaavien prosessien parantamiseen. Eikä missään nimessä tuomitsemiseen tai rankaisuun.
Rangaistus mielessä on lopputulos usein virheen mahdollisimman tehokas piilottaminen. Se ei palvele ketään.
Monenlaista projektia tehneenä. Ei ole yksi tai kaksi kertaa, kun esimerkiksi asiakas ei halua maksaa testauksesta. Silloin niille heitetään jotain kuraa, testaavat miten lystäävät ja sitten vaativat korjauksia jos jaksavat. Normalisti näissä tilanteissa testaus jää joko täysin tekemättä tai erittäin huonosti tehdyksi ja sen kyllä sitten saa ne loppukäyttäjät nähdä. Mutta ketäpä siitä voisi syyttää? Tilaajaa, ei toimittajaa.
VastaaPoistaSiis tarkoittaako tämä, että Accenturen "tasoinen" ohjelmistotalo uskaltautuu päästämään ulos jotakin tuollaista ilman, että ovat itse testanneet niitä? Jättävät kaiken testaamisen asiakkaalle ? Voihan hyttysen uloste. Siinä kyllä olet oikeassa, että asiakkaan eli VR:n pitää testata tai testauttaa. Mutta että joku itseään ohjelmistotaloksi kutsuva kehtaa päästää ulos noin kriittistä sovellusta ilman testausta niin... No, todennäköisesti ovat testanneet kyllä, mutta eivät sitten riittävän hyvin. Ei toimittaja eikä asiakas. Ei se nyt niin tuulesta temmattua ole, että päitä pitäisi tippua ja työsuhteita lakata. Mutta jos niin käy, niin sitten ne päät pitäisi kuulua kyllä joillekin ylempänä oleville kuin koodareille. Sehän on kaikille selvää, että täysin virheetöntä koodia ei ole olemassakaan. Eli siihen pitää varautua ja jos tätä ei ole tapahtunut niin ne jotka ovat jättäneet varautumatta, ovat vastuussa. Ei koodarit.
VastaaPoistaLukiko asiakkaan määrittelyissä, että miten syötteen tarkiste tulee tehdä? Mikäli sitä ei ole seikkaperäisesti kuvattu, ei siinä voi olla bugia. Määrittely voi toki olla puutteellinen, ja jos ohjelma täyttää määrittelyn, se on toimiva. Eikös asiakas ollut tehnyt use ja test caset? Nimimerkillä, juuri yksi tällainen projekti menossa. Halusivat maksaa vain ohjelmoinnista, eivät konsultoinnista, määrittelystä tai testauksesta. Näin ollen teen määrittelyn täyttävää koodia, se vastaako se sitten asiakkaan tarpeita, tai toimiiko se sellaisissa tilanteissa joita ei ole määrittelyssä määritelty. Ei ole mun ongelma.
VastaaPoistaTästä on kyllä varoitettu asiakasta, mutta ei. Koodaus on se mistä ne voivat kuulemma maksaa, eivät halua maksaa oheispalveluista. Voipi olla että kostautuu moninkertaisesti. Projektihenkilöillä on mittava osaaminen, mutta jos sitä ei hyödynnetä, niin sitten koodi on juuri sitä tasoa mtiä se on kuin se tulee halvimmalta mahodlliselta Intialaisella koodarilla. Jos joku teistä on työskennellyt näiden kanssa outsourcingin merkeissä, niin tietää että tulos on vähintäänkin katastrofaalinen. Ja yksinkertaisimmistakin asioista tarvitsee keskustella useita päiviä, tai sitten kirjoittaa niille esimerkkikoodi, että homma menee maaliin.
Täällä on mielenkiintoisesti vastassa mielipiteet, joiden mukaan virheitä KUULUU sattua ja kunnollinen testaus poistaa ne.
VastaaPoistaToiset taas koittavat sanoa, että esim. 30 vuoden kokemuksella softa-alasta tällaisia virheitä EI PITÄISI sattua enää.
Kun tällaisia sivustoja tehdään, oikeellisuus ei voi olla pelkän testauksen varassa. Testaus ei pysty ikinä osoittamaan virheettömyyttä, se pystyy ainoastaan näyttämään, jos virhe löytyy. Tässä kannattaa opetella sen verran peruslogiikkaa, että osaa erottaa toisistaan eksistentiaali- ja universaalikvanttorit.
Kunnollisessa firmassa näitä koodeja vertaisarvioidaan koodikatselmuksissa, ammattitaitoiset seniorit ja leadit ampuvat pois bugeja, eksploratiivista testausta tehdään myös implementaatiopäässä ja yksikkötestejä rakennetaan ohjelmiston mukana. Yksikkötestausta ei voi täysin ulkoistaa, se ohjaa koko implementaatiota.
Täällä parikin sanoi, että epäilee staattisten kielten auttavan. Kannattaa kaivaa käsiin vaikka Delphi 2.0 jostain historiallisesta arkistosta ja kokeilla tämän date-komponentteja. Ennen vanhaan näille datoille oli vakiokomponentit lomakenäkymässä. Se turha työ, mitä nyt web-koodissa tehdään, kuului kielen standardi-API:iin ennen vanhaan. Delphikään ei ollut täydellinen, mutta kyllä takapakkia on otettu luotettavuuden osalta, kun sovellukset ovat siirtyneet natiivisovelluksista web-sivuille. Koko HTML:n ja JS:n ja PHP:n ja muiden web-teknologioiden historia on yksi "clusterf*ck". Täysin inkompetentit häslärit on päästetty laatimaan näitä. Vaikka olisi miten osaava it-ihminen, näiden huonojen teknologioiden käyttö vaarantaa työn laadun välittömästi.
Toinen outo ajatus oli siinä, miten tilaajan tulee speksata tarkistetaanko syötön oikeellisuus ja miten se tehdään.
VastaaPoistaEiköhän ole sanomattakin selvää, että ohjelmoija itse vastaa oikeellisuustarkistuksista. Merkkijonojen suuruusvertailu ilman moninkertaisia tarkistuksia on yksinkertaisesti surkeaa työn laatua.
Tottakai työnlaatu on surkeaa, jos tilaaja sitä haluaa. Jos esimerkiksi testaukseen budjetoidaan 3500 euroa, niin kuinka kattavan testauksen luulet sillä saavan? Jos suoritatte kattavat code reviewit ja laadukkaan raportoidun testauksen tuollasummalla, niin tilataan kyllä mielellään palvelut teiltä jatkossa. Monesti pihistely ja aikataulutus johtaa vääjäämättä tämänkaltaiseen tilanteeseen ja silloin on ihan turha valittaa toimittajalle asiasta.
VastaaPoistaTämä on jossain määrin filosofinen kysymys. Mitä testauksella pitäisi hakea? Mitä koodaajan voidaan olettaa tekevän oma-aloitteisesti?
VastaaPoistaVoiko softayritys tehdä halvan tarjouksen ja tuottaa sekundaa, ja vetäytyä vastuusta syyttämällä tilaajaa siitä, ettei tämä maksanut testauksesta?
Minusta alkeelliset käyttöliittymän virheet ovat koodaajan vastuulla. Toimintalogiikan, poikkeustilanteiden hallinnan, kuormituspiikkien ym. virheet paljastuvat sitten testauksessa.
Softafirmojen työntekijät ovat erittäin moraalittomia, kun suostuvat jättämään työn puolitiehen.
VastaaPoistaOnhen se selvä, että jos itse tekee kunnolla ja joku toinen huolimattomasti, tämä toinen voittaa kilpailun, koska tarjoaa työn halvemmalla. Miksi tähän ylipäänsä päädytään? Missä on ammattiylpeys ja "moraali" ja kunnia ihmisellä? Miksi nykyään sopimukset ovat niin kelvottomia, että näin pääsee käymään. Jopa paljon haukutut kristilliset periaatteet (tee muille niin kuin toivoisit itsellesi tehtävän) voittavat tässä kurjan talousoptimoinnin selkärangattomuuden. En pystyisi ikinä itse toimimaan näin, ehkä siksi olenkin työtön enkä it-alan töissä alan tutkinnosta ja lähes kymmenen vuoden työkokemuksesta huolimatta. Näin kelvottoman laadun tekeminen on itselle kynnyskysymys työtä vastaanottaessa. Muille se on naurun paikka "tyhmyydestä". Siis siitä, kun koitan heille tuoda parempaa elämää parempien julkisten palvelujen kautta. "En mä tarvitse hyviä julkisia palveluita, olen itse 6000 eur/kk tienaava koodari ja ostan ne yksityiseltä. Saan päinvastoin sadistista nautintoa, kun köyhät kärsivät huonoista palveluista"
Petteri, kiitos blogistasi.
VastaaPoistaKuinka sinut tai joku muu teräväpäinen saataisi koekäyttäjäksi terveydenhuollon järjestelmiin? Ja vielä niin, että istuisit lääkärin vieressä seuraamassa kun hän taistelee tiensä sairauskertomusohjelmien ja niiden kylkiin keinotekoisesti kiinniruuvattujen, muiden ohjelmantoimittajien aikanaan laatimien lisäosien läpi hektisimmässä työtilanteessa.
Testaajia ei ole näkynyt peruskäyttäjän kamppailua seuraamassa. Tämä on tietysti kiinni talomme it-tuen intresseistä ja rahoista. Laitoin kolmisen vuotta toistuvasti viestiä siitä, että eräs potilaan diagnoosi oli Harry Potter-tyyppisessä naurettavassa kirjoitusvirhemuodossa, jossa lisäksi yhdyssanan sisälle oli laitettu sulkumerkit. Ei iso bugi, mutta aika huvittavan kuvan antaa potilaalle sairaalan "diagnooseista" ja huilellisuuden laadusta. Diagnoosit myös kirjautuvat ikiajoiksi potilaan sairauskertomukseen.
Ymmärrän toki, ettei ohjelmaan pujahtaneita kirjoitusvirheitäkään pääse kuka tahansa korjaamaan, mutta toistuvasti ilmoitettunakaan niitä ei meinannut saada oikaistua. Peruste oli juuri tuo, että lisätyö maksaa maltaita.
Analoginen tilanne olisi se, että potilaalle määrättäisi kuulolaitteen sijasta silmälasit ja hän saisi vaihtaa ne lisämaksua vastaan.
Koska ohjelmoinnista en älyä mitään, pitäydyn vaina käyttäjäkokemukseen. Tällä hetkellä joissakin koneissa täytyy säilyttää XP koska aikanaan ostettu kuvausohjelma ei ymmärrä W7:aa, eikä tiettävästi näköpiirissä ole työn alla (ainakaan samaan hintaan) välikappaletta, jolla tuo sinänsä kökkö kuvausohjelma saataisi ruuvatuksi toimimaan W7:ssa. Näin ollen tietoturvan kannalta kai epästabiili XP on edelleen käytössä näissä koneissa, joissa kuvausohjelmaa käytetään - ja myös sairauskertomusohjelma on kuvausohjelman kanssa rinnan auki.
Konkluusio: VRn ohjelma tökkii, mutta näkisittepä mitä terveydenhuollossa tapahtuu.
t.H
Olisit Petteri myöntänyt, että se potkujen antamis -kommentti oli aivopieru, niin olisit säilyttänyt uskottavuutesi. Näkemyksesi perusteella kaikki virheitä tekevät koodajat pitäisi eroittaa. Ei taitaisi jäädä kovin montaa koodajaa jäljelle. Myös vertauksesi lääkäreihin on hölmö. Kyllähän lääkäritkin sekoittavat vasenta ja oikeaa jatkuvasti, aina vaan ei ole kyse amputaatiosta, leikkauksesta tai muusta kriittisestä.
VastaaPoistaMyös näkemyksesi alkeellisten ja ei-alkeellisten toimintojen testausvastuusta on aika tolkuton. Kuka ihme määrittää mikä on alkeellinen ja mikä ei. Johan tässäkin keskustellussa on todettu, että softamaailmassa lähestulkoon kaikki on jo tehty aikoja sitten. Eli periaatteessa kaikkihan menisi tuon alkeellisten toimintojen piiriin.
Mitä järkeä on panostaa testauksessa johonkin kuormituspiikkien hallintaan junan lipunmyyntisoftassa? Koska sellaista kuormitusta edes tapahtuu? Eikö tärkeämpää olisi saada perustoiminnan testaus kuntoon, että se tärkein asia, eli lippujen osto varmasti onnistuu. Nyt nähtiin miten kävi, kun ei testausta tehty kunnolla (ehkä kuormituspiikkitestaus oli tehty...).
Ei koodaaja korvaa testaajaa. Aivan sama kuin tietokirjailija käyttää oikolukusoftaa ja/tai oikolukijaa. Kokeileppa Petteri itse kääntää oikoluku pois Wordistä ja pistät seuraavan kirjan suoraan painoon, kun olet sen ihan itse tarkastanut. Kirjoittaminenhan harjoitellaan jo peruskoulussa, ei pitäisi enää ammattilaisella virheitä syntyä.
Ja hyvin Petterin ajatuksia mukaillen täällä joku haukkui koodin "luokattomaksi" yhden bugin perusteella. Ainakaan tässä keskustelussa ei ole tullut muita bugeja ilmi. Miten ihmeessä koodi voi olla tämän perusteella "luokatonta". Tälläisiä kommentteja kuuluu yleensä juuri koulunsa päättäneiden suusta. Ja yleensä "luokatonta" on vain tälläisten ihmisten ymmärrys koko softa-alaa kohtaan.
Petteri voisi kirjoittaa kirjan ohjelmoinnista jotta tällaisilta virheiltä vältyttäisiin.
VastaaPoista"Eiköhän ole sanomattakin selvää, että ohjelmoija itse vastaa oikeellisuustarkistuksista."
VastaaPoistaKai tuossa haettiin sitä, että jos määrittely on ympäripyöreätä toivomuksia, oletetaan asioita ja määrittely on paperilappu missä muutama ranskalainen viiva niin homma karkaa käsistä äkkiä äärimmäiseen suureen määrään asioita joita pitää huomioida, tai osata lukea tilaajan ajatukset mitä hän on tarkoittanut.
Yksiselitteisin tapa määritellä ohjelmistoprojektit on määritellä milloin ohjelma on valmis, ja se tehdään hyväksymistestauksella.
Ensiksi tilaajapuoli tekee tai maksaa sen tekemisestä, että määrittelee hyväksymistestit jotka tilaaja hyväksyy. Sitten aloitetaan ohjelmointi ja ohjelmointiosuus on valmis sitten kun kaikki hyväksymistestit menee läpi.
Tämä on selkeä tapa. Ei ole mitään tulkinnanvaraisuuksia, eikä tarvitse vääntää siitä kuuluko jokin hintaan vai ei. Jos toimittajapuolella menee aikaa viikkoja ylimääräistä, se menee toimittajan piikkiin. Jos tilaaja unohtanut määritellä jotain ja se halutaan siihen lisätä, se voidaan laskuttaa lisätöinä.
Pitäisikö yritysten luoda palkitsemissysteemi bugin löytäneille käyttäjille? Samalla yritykset voisivat näyttää, että he arvostavat käyttäjien mielipidettä.
VastaaPoistaItse havaitsin Veikkauksen verkkopalveluista tietoturva-aukon muutama kuukausi sitten. Tämä bugi mahdollisti tietyissä tilanteissa samaan toisen käyttäjän tilin haltuun. Ilmoitin testailujen jälkeen kilttinä poikana tästä Veikkauksen asiakaspalveluun. Vika paikattiin parissa arkipäivässä.
Se, että sain sähköpostilla kiitokset asiakaspalvelusta ja postin kautta pari pyyhettä kotiin, laittoi miettimään olisiko sittenkin pitänyt toimia toisin…
Kokeileppa Petteri itse kääntää oikoluku pois Wordistä ja pistät seuraavan kirjan suoraan painoon, kun olet sen ihan itse tarkastanut.
VastaaPoistaYlempänä nimitettiin aivopieruksi sitä, että olen vaatinut potkuja koodaajalle. Molemmille vastaan yhteisesti:
Kaikki teemme virheitä. Jos koodi päätyy ikuiseen looppiin, muuttujanimeen tulee kirjoitusvirhe tms. kyse on tavallisesta virheestä, joita voi sattua kenelle tahansa.
Numeroiden suuruusvertailu merkkijonoina (ainakin ilman moninkertaisia oikeellisuustarkistuksia) on niin alkeellinen käsitetason virhe, että se osoittaa epäpätevyyttä. Huolimaton koodaaja voi pitää paikkansa, epäpätevä ei.
Numeroiden suuruusvertailu merkkijonoina (ainakin ilman moninkertaisia oikeellisuustarkistuksia) on niin alkeellinen käsitetason virhe, että se osoittaa epäpätevyyttä. Huolimaton koodaaja voi pitää paikkansa, epäpätevä ei.
VastaaPoistaNykyaikaisessa ohjelmistotuotannossa sanoisin että vika on prosesissa. Tuollaisiakin mokia ihmiset tekee ja sen takia pitäisi olla automatisoitu testipenkki, jossa kone syöttelee kellonajat kaikissa mahdollisissa muodoissa ja raportoi kehittäjälle.
Aina pitää olla tuommoisella masiiviseen käyttöön menevällä ssyteemillä testaus jossa halutaan rikkoa systeemi. Ei muuten koskaan saavuteta kohtuullista laatua
Eli jos potkuja jaeltaisiin toimittajan projektipäällikkö ja testaussuunnittelija olisivat parempia kohteita.
Verkkokaupan uudistuessa jokunen vuosi sitten, autojunat lähtivät puolityhjinä pohjoiseen. Sain itse tietää, että juna on täysi. Ymmärsin ettei voi pitää paikkaansa, ja soitin puhelinpalveluun. Selvisi, että jos syötti auton korkeudeksi (enintään) 165 cm:ksi niin järjestelmä tarjosi vain ja ainoastaan 165 cm paikat. Kokeileekohan VR:n puhelinpalvelu edelleen käsin, onko korkeampia paikkoja vapaina? Entä verkkokauppa, osaako nyt toimia fiksusti?
VastaaPoistaVerkkokaupan uudistuessa jokunen vuosi sitten, autojunat lähtivät puolityhjinä pohjoiseen. Sain itse tietää, että juna on täysi. Ymmärsin ettei voi pitää paikkaansa, ja soitin puhelinpalveluun. Selvisi, että jos syötti auton korkeudeksi (enintään) 165 cm:ksi niin järjestelmä tarjosi vain ja ainoastaan 165 cm paikat.
VastaaPoistaVoi perhana jos tämä pitää paikkansa! Olisi Tampere-Rovaniemelle halunnut autojunan viime keväänä, ja oli niin kovin täyttä. Koska oli eka kerta niin tuli vaan oletettua että kai se sit on oikeasti niin täynnä, mutta tulipahan ajettua sitten halki suomen...
Moni täällä saa varmaan VR:n emailia, mainoksia, tarjouksia? Minä pahoitin (trendikkäästi) mieleni siitä miten luokattoman huonosti ne toimii geemailin kanssa. Yksi maailman yleisemmistä email-palveluista, ja viesti on lukukelvoton? Laitoin sitten ko palvelun tekijälle palautetta heidän omien sivujen palauteosoitten kautta... sain virheilmoituksen että se mail ei toimi. Upeata!
VastaaPoistaLiityin VR:n veturi-palveluun. Jo 4 kerralla pääsin rekisteröitymisessä eteenpäin, kunnes homma tyssäsi ilmoitukseen "Epäonnistui".
VastaaPoistaMillään salasanalla ei päässyt sisään, ja uudelleen ei voinut rekisteröityä, koska sähköposti oli kuulemma jo käytössä.
Yritin pari kertaa unohdin salasanani -toimintoa, mutta salasananvaihtomaileja ei kuulunut/näkynyt. Koko projekti oli senverran vastatuulessa, että tein välillä jotain muuta ja huomasin, että kaikki 4 salasananvaihtomailia olivatkin saapuneet. Viivellä, mutta kuitenkin. Yksikään niistä ei toiminut.
Jonotin puhelin-aspaan, jossa hieman tympääntyneen kuuloinen asiakaspalvelija sanoi, että "ei voi tehdä mitään, pitää odottaa 30 min".
Lounaan jälkeen ihme ja kumma tapahtui. Viimeisin salasananvaihtomailissa ollut salasana toimi! Tietysti halusin heti vaihtaa tilalle oman salasanan, mutta sehän ei onnistunut millään. Ohje kuuluu "6-18 merkkiä, ei skandinaavisia, ei erikoismerkkejä". Koska käyttöliittymä on VR-laatua, ei epäkelvosta salasanasta saa minkäännäköistä visuaalista vastetta tai ilmoitusta.
Aikani salasananvaihtolomakkeen kanssa painittuani hoksasin säännön. Se onkin 6-14 (ei 18!) merkkiä. Käyttämäni salasanaohjelmisto luo oletusarvoisesti 15-merkkisiä, joten ...
Tätä VR-sotkua pitäisi jonkun nuuskia vähän tarkemmin. Miten on mahdollista, että yhteen projektiin on valikoitunut noin iso joukko ammattitaidottomia räpeltäjiä.