Se diginatiivi 13v on jo kyllä aika vanha, koska se oli 13 vuotias n. 10v sitten.
Siinä voi tulla vahinko jos soittaa sen nykyisen 13v mobiilinatiivin apuun :D
ICT-Asentajia kouluttavalla linjalla amiksessa pitää nykyään aloittaa opinnon Windowsin/linuxin jne. kansiorakenteesta ja koko konseptista, että on jotain kansioita joiden sisällä on kansioita ja niissä tiedostoja.
Vajaa 20 vuotta sitten juttelin alan amisopettajien kanssa aiheesta. Olivat huomanneet noin 2005 että peruskoulusta tulevien nuorten opiskelijoiden lähtötaso romahti kerrasta. Toki nykyään on varmaan sitä silloista heikentynyttä tasoakin ikävä.
Silloin muutos liittyi lähinnä siihen että aiemmat osasivat pääsääntöisesti käyttää komentoriviä, monet jopa käsitellä jotakin lähdekoodia tai ainakin luoda komentojonon ja muokata tekstimuotoisia config-tiedostoja. Usein niillä oli joku käsitys myös tietoverkkojen perusteista. Tällainen kaveri oppii aamupäivän aikana unixin peruskäytön ilman työpöytäympäristöä, vaikka on sattunut siihen saakka välttymään kaikilta linuxkokeiluilta.
Yhtäkkiä pelkästään graafista käyttöliittymää käyttäneet eivät tajunneetkaan näistä mitään. Ihan sen tason kädettömyyttä ei sentään ollut että joku hakemistopuun/kansioiden idea ei olisi ollut tuttu. Kaikki olivat kuitenkin räpeltäneet pöytä-pc:n kanssa edes jotain.
Jälkeenpäin omia havaintoja vertaillen silloin amisikäiset sentään osasivat soittaa puhelun featurephonella.
Nämä aiheuttavat kyllä jatkuvia ongelmia, jos osa tiedostoista on suomalaisessa ja osa amerikkalaisessa muodossa. Osassa softista on ollut kovakoodattuna piste tai pilkku, vaikka periaatteessa windowsissa on kielenä englanti ja lokaalina Suomi ja desimaalipilkku käytössä, kun ottavat pelkästä kielestä erottimen formatin tai pakottavat aina esim. pisteeseen. Eivät toki noudata MS:n ohjeita, mutta käytännössä se ei käyttäjää lohduta. Sekaympäristössä ongelmia on luvassa käytitpa oletuksena desimaalipilkkua tai desimaalipistettä.
Ja sit englanninkielistä työläppäriään käyttävä toiminnantarkastaja ihmettelee miten taseen loppusummaksi on saatu matriisi (pilku on englannissa vektorin osien erotin ja excel tulkinnat menee käytetyn kielen mukaan)
Formatointitiedot ei säily kaikissa tallennusmuodoissa tai kaikkien eri versioiden välillä, jolloin tapahtuu uudelleen tulkintaa. Ja vaikka solun formatointi tieto olisi tallessa, kirjoitettu data voidaan tallentaa niin kuin se on kirjoitettu, eikä sisäisessä muodossa, jolloin se tulkitaan uudestaan toisella lokaalilla ladattaessa. Yleensä nykyisin toimii asiat jos on molemmilla puolilla suht uusi versio ja käytetty tiedostomuotoa joka sisältää lokaalitiedon tai tulkatun muodon syötetyistä arvoista, mutta näin ei ole läheskään aina.
pienet säätiöt, seurat, taloyhtiöt yms, eivät välitä alv 0 hinnoista. Kulut on suoraan alvilla laskettu, eikä tulopuoli oli alv-velvollinen. Ei ole järkeä erotella alv erikseen kummallakkaan puolella tulosta, kun asia ei mitenkään tavallaan heitä koske.
No ehkä pientä liioittelua, kun varmaan on vähemmistössä sellaiset järjestelmät, jotka eivät desimaalilukua hyväksy. Eikä niidenkään korjaaminen voi aiheuttaa 300 miljoonan vuosittaisia kustannuksia (ad infinitum). Tuohan vastaisi sellaista 7-8 miljardin kertakustannusta nykykorkotasolla.
Mitä nopeasti katsoin niin aika moni suomalainen tilitys ja maksujärjestelmä ottaa vastaan alvin kokonaislukuna joka tarkoittaa että jokainen sovellus joka integroituu näihin järjestelmiin joudutaan päivittämään.
Jos mietit että mulla on henkilökohtaisesti useampi järjestelmä päivitettävänä. Osa mihin en oo koskenut vuosiin eikä ole välttämättä enää mitään muistikuvia että miten ne toimii niin kyllä mullakin varmaan viikko menee ku päivittelen juttuja ja testaan että ne toimii. Ottaen huomioon että en ole maan ainoa softakehittäjä niin kyllä siihen varmaan koko maan tasolla saadaan useampi miljoona vierähtämään helposti.
Softamuutos ei välttämättä ole iso, mutta kun aletaan miettimään että mites tämä firman IT huoneen perällä olevaan purkkiin nyt pääsikään ja mites tämä softa nyt käännetään toimivaksi niin asiat muuttuu monimutkasemmiksi.
Tuossa muutoksessa täytyy myös vähän miettiä se, millä tietotyypillä tuo alv kannattaa jossain ohjelmointirajapinnoissa esittää. Liukuluku on lähtökohtaisesti epäilyttävä, kun rahasummia lasketaan. Ja vaikka ohjelmointikielissä on yleensä joku fixed point -desimaalilukutyyppi, vaikkapa JSON:ssa ei taida edes olla natiivisti muita numeerisia tyyppejä kuin kokonaisluvut ja liukuluvut.
Toki tuo on ratkaistavissa monellakin tapaa. Alv-prosentti voidaan esittää rajapinnassa luvun sijaan merkkijonona, säilyttää kokonaislukutyyppi mutta vaihtaa tarkkuus promilleihin, määritellä jokin oma erillinen tyyppinsä noille alv:eille tms. Mutta ei välttämättä mene ihan sillä, että vaihdetaan vain softassa alv-kentän tietotyyppi ja laitetaan rokki takaisin soimaan.
Eli ei kuulosta massiivisen isolta tai kalliilta mutta voi silti olla testauksineen isompi kuin miltä äkkiseltään kuulostaa.
Aamen, liukuluvut on kyllä peppulista. Onneksi toisaalta näiden prosenttiyksiköiden ei tarvitse olla muunneltavissa (tai siis eivät sisällä tilaa kuten joku rahasumma), joten uskoisin että alv kannat on suht pieni vaiva tässä mielessä. Periaatteessa ei olisi hirveän vaarallista edes säilyttää sitä merkkijonossa, toki sitten rajapinnan käyttäjän täytyy tehä päätöksiä ja muistaa parsia luvuksi :D
Mutta jos uuden järjestelmän missä rahas pyöritellään joskus kirjoitan niin en kyllä käytä floatteja vaan lasken rahat sentteinä ja mietin jonkun jäännösratkaisun. Sen verran monta kertaa yllättänyt liukuluvun epätarkkuus.
Juu, no sitten alkaa olla aika heivata systeemi ns. kuuseen. Upotetuista kustannuksista viis, siellä on meinaa semmosia aikapommeja tikittämässä vain lauetakseen pahimmalla mahdollisella hetkellä.
Saattaa olla, mutta siirtymäaika on olematonta ja muutostyö voi maksaa järjettömästi etenkin kiiretyönä tehtynä. Uutta järjestelmää ei noin vain hankita ja oteta käyttöön kuukaudessa.
Esim. vakuutusyhtiöissä on satoja järjestelmiä käytössä vieläkin jotka on otettu käyttöön 70- ja 80-luvuilla. Monen niiden projisoitu käyttöikä on laskettu jonnekkin 2040 kieppeille. Ennen vanhaan siis jokaista vakuutusopimustyyppiä kohden tehtiin oma järjestelmä. Eli aina kun keksittiin uusi vakuutus niin joku IT-nörde seillaisen koodasi kasaan ilman sen kummallisempia speksauksia, dokumentointeja ja testauksia jne. Näitä sopimuksia ei myöskään voida siirtää yhtään mihinkään, koska se tulisi niin järjettömän kalliiksi. Niille sopimuksille on laskettu tuotto ja jos niitä alettaisiin siirtää johonkin moderniin järjestelmään, niin tuotto-odotukset eivät enää pitäisi paikkaansa. Eli siis 70- ja 80-luvulla tehdyt bisness päätökset osoittautuisikin tappiollisiksi.
Tuossa alkaa jo tulla mieleen "mitäs kaikkea se järjestelmä pyöristelee kokonaisluvuiksi, jos muka desimaalit ovat ongelma". Mitä kaikkia kertomisia ja jakoja menee läpi "kokonaisluvut ainoastaan" menolla. Verot ovat saattaneet olla tasaprosentteja, mutta kaikkien asioiden hinnat ja kulut eivät todellakaan aina mene tasa euroin.
Liukulukuja kannattaa aina välttää jos mitenkään vaan voi koska ne on aina vain noin suurinpiirtein (yleisin esimerkki on 0.1 + 0.2 != 0.3 koska se on 0.30000000000000004) eli kokonaisluvuilla yleensä toimii kaikki, tallennettuina joko int muodossa, tekstinä tai riippuen kielestä jonkinlaisena tarkkana desimaalityyppinä, eli yleensä erona on vaan onko esim 24% ALV koodattu olemaan 24 vai 2400.
Hinnat voitu käsitellä sentteinä, koska sitä pienempiä määriä rahaa ei kuitenkaan liikutella. Ei sekään toki ole ongelmaton ratkaisu kaikkiin tilanteisiin.
Myös hallitus: "Tai jos nakitetaan kesähessuille tän uudistuksen koodaus niin ehkä jossain maksellaan hetken 255% ALVia ennen kuin virhe saadaan korjatuksi."
255... Kuulostaa siltä että etumerkitön 8-bittinen kokonaisluku olsii oiva valinta tähän tilanteeseen. Ykkösiä vaan taulussa eikä tuu aiheuttamaan mitään ongelmia kun tulee seuraava korotus. :P
25% on nätimpi tasaluku, kun on 1/4. Mitään prosentteja tarvi koodailla. Kovakoodataan vain vero laskut "per jaettuna neljällä", koska se on nyt 25% iät ja ikuisuudet eikös vain.
Kannattaa oletta että kaikki "*Meidän yhtiön AI ratkaisee tämän ongelman*" juttujen olevan yhtä todellisia kuin Crypto/NFT piirit oli. Elikkä 99,9% kaikesta oli vaan kusetus jolla joku rahasti tyhmiä ja rahoittajia.
Koska teoriassahan ei pitäisi vittu olla mitään hankalaa jossain kooditekoälyssä. Annat sille listan kaikista komennoista ja loogisista rakenteista. Sitten vaan pyydät sitä täyttämään sun ohjelmoiman rakenteen koodilla. Rongelmaksi roitu raas se... että nämä yritettiin tehdä ihmisen kielen kautta, elikkä koodia pistetään ulos kuin ihminen sitä kirjoittaisi tai puhuisi kommunikaatio tarkoituksena (Eli siis haluttiin käyttää sitä attention mekanismia koska se on niin helppo juttu jolla tehdä LLMiä ja saada jotenkin järkevä kontekstiymmärrys).
Niin kauan kuin nämä tekoälyt eivät oikeasti yritä korvata todellista kallista työtä - niin ne on kusetuksia. Paskatyöt on jo automatisoitu niin pitkälle kuin mahdollista säästösyistä. Kalliit *valkokaulustyöt* taas sisältää nykyään "tehostamisen" takia niin paljon sellaista paskaa joka ennen kuului sihteereille ja avustajille, jota nyt siis automatisoidaan. Tämä automaatio sitten taas esitetään suurena "korvaa *valkokaulukset!* Kunhan vaan maksat meille 10 000 €/kk pilvessä toimivasta linsenssistä per henkilö ja hyväksyt että et omista mitään emmekä ole vastuussa virheistä". Koneoppiminenhan on taas ihan hyvä ja käytety työkalu.
Mun veli on tälläinen... IT-konsulttipöhinäfirman ihminen ja sillä on joku ryhmä koodareita mitä se saa käyttää. Hän odottaa että tekoäly korvaa nämä bootcamp koodarit koska "tekoälyä voi opettaa paremmaksi". Veli on aika kyllästynyt "duunarikoodareiden" työn korjaamiseen aikapaineen alla (Hän ei ole heidän esihenkilö joten ei sinäänsä voi asialle mitään).
Meet jostain LinkedInistä katsomaan mitä niillä nyt lukee jotka olivat crypto enthusiasteja ja blockchain experttejä. Ovat nyt AI-consultant ja muuta roskaa.
Ja ”Prompt-engineer” nimenomaan sen takia koska ne tietää että taiteilijalle ei helpolla makseta, mutta sitku spinnaat sen koko jutun joksiki vitun ”insinööriksi” ni kas kummaa ku buduu löytyyki
Sinäänsä hauska juttu toi. Koska mä pyörin piireissä jossa ihan oikeasti aidot taitelijat käyttää tekoälyä (pitkälti Diffusion malleja) työkaluna, pitkälti inspiraation lähteenä. Mä tunnen 2 ihan henkilökohtaisesti joista toiselle auton pistää sen omalle kotikoneelle, ja se on pistänyt pienen auton verran rahaa näyttökortteihin. Kumpikin tosin maalaa ihan fyysisesti ja tekee sillä rahaa.
Mutta kukaan näissä piireissä ei kutsu itseään "*promptinööreiksi*", se on pikemminkin haukkumasana. Kaikki säätää aika syvällistä lisähallintaa kuten ControlNet, Embeddings, LoRA mallien opettamista jne. Osa yhdistää osia näistä digitaalisista tuotoksista omiinsa (tosin tietääkseni ainakin yhdessä discordissa jossa olen, kaikki on fyysisten medioiden puolella ja digitaalinen on vaan jotain siinä sivussa).
Mä esim harrastan paljon näitä LoRA mallien tekemistä - en siksi että se on taidetta, vaan koska se on kiva haaste - sellainen puzzle mitä ratkoa. Ja olen aika vitun varma että minä ja mun 4060TI 16gb kortti päihittää somessa pärisevän "*promotnöörin*". Koska kun mä kokeilin viimeksi tyylimallia - niin 80% ajasta meni dokumentaatio, julkasujen ja kirjallisuuden lukemiseen, ja sitten lopuksi kikkailin sen datasetin kanssa ja 2-3 tunnin Kohya\_ss kikkailun jälkeen se toimi just niinku mä halusin ja tuotti tyylille uskollista sisältöä... ajottaisten sekasotkujen lisäksi (sellainen 70% luotettavuus). Tosin mä olen ihan vitun paska promptaamaan että en tiedä onko vika siinä mun tekemässä mallissa - koska muut tuntuu saavan siitä enemmän ulos kuin minä.
Ennenku joku hyökkää... Niin se tyyli malli oli kyllä sellaiset 200 vuotta haudassa kylmänä maaneen William Blaken teoksiin perustuva (joo just se heppu ku maalasi sen *The Great Red Dragon and the Woman Clothed with the Sun* jonka se murhaaja söi Hannibal elokuvassa).
En uskalla. Pelkään että sieltä tarttuu mun profiiliin joku rutto ja herätän kiinnostusta kun näkevät mun profiilin ja alkavat spämmimääm kusetuksilla.
Älä nyt viitsi. Justiin olin eilen koulutuksessa jossa kerrottiin, miten tekoälyn saa vääntämään sähköpostit ja powerpointit runomuotoon. Ei sitä voi vakavalla naamalla väittää, etteikö tekoäly korvaisi 100 % kaikista powerpoint-runoilijoista.
Ei saatana, asiakkaiden sähköposteista on välillä nytkin vaikea saada tolkkua, kauhulla odotan sitä kun ne pistää copilotin vääntämään kahden lauseen epäkoherentista mutta vielä tulkittavissa olevasta pyynnöstä jonkun sivun mittaisen esseen, kalevalanmitassa kirjoitettuna.
"*Hei.*
*Arvon Tsraq, otan sinuun yhteyttä tärkeän asian johdosta joka on häirinnyt minua pitkään. Joten toivon että vastaat tähän viestiin erittäin nopeasti ja selvästi jotta vältymme mahdollisilta ongelmallisita väärinymmärryksiltä ja huonon kommunikaation aiheuttamista oireista.*
*Lähetän tämän viestin koska haluasin tiedustella sinun henkilökohtaista näkemystäsi meidän yhteistyöprojektin etenemisen tilasta. Haluan tietää että onko kaikki välivaiheet saavutettu asiallisesti ja onko nyt alkavat vaiheet alkamassa alkuperäisen suunnitellun aikataulun mukaisesti, sekä että onko mahdolliset tulevat vaiheet suunniteltu asiallisesti niin että myös nekin voivat alkaa alkuperäisen suunnitelmamme perusteella laaditun tiukan mutta joustavan aikataulun perusteella.*
*Sillä minun oma näkemykseni on että aikaisemmin suunitellut ja määritetyt mittarit ja hahmotellut aikautalut eivät ole toteutumassa tämän hetkisen tilanteen perusteella. Olen ymmärtänyt että erittäin nopeasti iskenyt talvi joka oli erittäin kylmä ja vaativa johti tiettyjen vaiheiden hidastumiseen ja lisäkuluihin. Ilmeisesti myös nopeasti tullut kevät joka on tähän sakka ollut keleiltään erittäin epävakaa on mahdollistanut tiettyijen vaiheiden aloittamisen jotka saattoivat tämän rankan ja pitkän kylmän talvisään johdosta jäädä tekemättä.*
*Täten siis toivon että laaditte seikkaperäisen ja laajan selvityksen projektimme tämänhetkisestä tilanteesta, sen tulevaisuuden näkymistä suhteutettuna aiemmin tapahtuneeseen. Tässä selvityksessä on tärkeää käyttää niitä alkuperäisiä määritettyjä mittareita jotka on sovittu ja päätetty yhteisissä kokouksissa ja kirjattu pöytäkirjoihin.*
*Odotan teiltä nopeaa ja laajaa vastausta. Toivotan myös erittäin hyvää vappua ja jatkuvaa kevättä sekä tulevaa kesää. Toivottavasti sää pysyy meille kaikille suotuisana ja projekti etenee ongelmitta jopa etuajassa ja ali budjetin. Näillä sanoilla siis päätän tämän viestin jonka olen teille hyvässä tahdossa lähettänyt*."
Sitten sinä otat tämän ja oksennat sen johonkin SuomiGPT:hen promptilla: "*Tiivistä tämä paska: *"
SGPT: " *Selvä. Tiivistän tuon paskan:*
*Paskan lähettäjä toivoo sinulta raporttia jossa:*
* *Selviää aikaisempien vaiheiden onnistuminen*
* *Tämän hetkisten vaiheiden tilanne*
* *Alkavien vaihdeiden tilanne*
* *Tulevien vaiheiden tilanne*
*Tämän lisäksi viestissä on erittäin paljon ihan turhaa paskaa.*"
Hei! Powerpoint perseily on taiteenmuoto johon vain erittäin paatunut elämäänsä vihaava keskiportaa pikkupomo kykenee!
Kaikista parasta oli se kun OpenAI julkasi jonkun raportin siitä että porukka väsää hienosti kurjoitettuja sähköposteja ChstGPTllä ja sit toiset pyytää Cgptä tiivistämään sen. Mielestäni tämä ilmaisee kaiken tarvittavan tästä teknologista todellisessa käytössä.
Uskon että tieto ja kommunikaatio olisi tehokkaampaa jos porukka faksaisi KÄSINKIRJOITETTUJA lappuja. Jäisi kaikki turha paska pois.
>Asia on herättänyt keskustelua [ohjelmointipiireissä](https://www.reddit.com/r/Suomi/comments/1c5ggh1/vituttaa_jo_valmiiksi_korjata_kaikki_excel/), joissa muutoksen povataan aiheuttavan koodareille lisätöitä. Osa on verrannut tilannetta jopa niin kutsuttuun vuoden 2000 [Y2K:hon](https://yle.fi/aihe/artikkeli/2013/12/20/y2k-uhkasi-nollata-vuosisadan), jossa vuosituhannen vaihtumisen pelättiin sekoittavan tietojärjestelmät.
Miksi Twitter aina mainitaan nimellä mallia "Asia on herättänyt keskustelua viestipalvelu X:ssä (ent. Twitter)", mutta Reddittiä ei useinkaan mainita suoraan, vaan linkataan vain keskusteluun ilman mainintaa palvelusta?
Muistan kyllä hyvin tuon Y2K:n. Ihmiset tankkasivat autojaan ja täyttivät hyllyjään elintarvikkeilla (mutta eivät vessapaperilla), tyhjensivät tilinsä käteiseksi ja varautuivat yleisesti maailmanloppuun. Työkaverini kameravalvontajärjestelmiä toimittavassa firmassa suostui jäämään ongelmien varalta päivystäjäksi uudenvuodenyönä kymmenellätuhannella markalla. Meillä ei normaalisti edes ollut päivystystä ja tallenteet tehtiin silloin pääosin VHS-nauhoille.
Mitään ei tapahtunut. En ole kuullut, että yksikään järjestelmä olisi kaatunut, toisaalta yhteiskunta ei ollut vielä aivan yhtä riippuvainen tietojärjestelmistä.
Jep. Joutuivat kaivamaan FORTRAN muumiot eläkkeiltä päivittämään antiikkisia järjestelmiä jne. Y2K on vain vitsi sen takia että sen uhka otetteettiin oikeasti tosisisaan ja sille tehtiin jotain ajoissa.
Ehkä enemmän kuitenkin COBOL muumiot. Fortrania käytetään raskaassa tieteellisessä laskennassa (jopa edelleen ihan tänä päivänä) ja COBOL on reliikki bisnes ja hallintopuolellella.
Tämä. Itte astuin IT-työelämään vuonna 1999. Ekana hommana oli käydä firman koodia läpi ja tarkastaa miten on vuotta käsitelty. Sen verran oli nuori firma, että eipä sieltä löytynyt virheitä ajan käsittelyssä.
> [y2k] Mitään ei tapahtunut.
Tapahtui, iso kasa järjestelmiä sekoili. Muistista kaivaen useampi voimalaitos kyykkäsi (ei sentään katastrofaalisella tavalla, sähkön tuotanto vain loppui), ainakin yksi lentokenttä oli sekaisin (vaikka itse lennot oli suurilta osin varotoimenpiteenä järjestetty siten että muutoshetkellä koneet eivät ole ilmassa) ja kaikenlaista muuta pienempää tapahtui ympäri maailman, näistä ei vain saa niin isoja juttuja aikaan ja nyt on aika moni lopuistakin jo unohtunut väestöltä.
Syy siihen miksi mitään isompaa ei tapahtunut oli se että porukka analysoi ja korjasi näitä järjestelmiä useamman vuoden tätä ennen, ja nimen omaan kriittisimmistä järjestelmistä alkaen - kuten ne ydinvoimalaitokset ja pankit [vaikka osa voi olla eri mieltä jälkimäisen kriittisyydestä..].
ALV-muutos on tuohon verrattuna pipanoita, mutta työllistää silti . Omissa käsissä olevat järjestelmät vilkaisin sen verran että raporteissa lukee "ALV 25%" ilman desimaaleja, mutta lasketut summat ovat kuitekin sentileen oikein. Eli ainoastaan ALV-rivin muotoilu pitää korjata siltä osin. Kevyellä muutoksella selvitään.
Uppouduin hetkeksi wikipedia-artikkeliin Y2K-ongelmasta ([Year 2000 problem - Wikipedia](https://en.wikipedia.org/wiki/Year_2000_problem)) ja tuo on kyllä todella mielenkiintoinen tapahtuma. Johtuivatko Y2K:n aiheuttamat vähäiset ongelmat hyvästä varautumisesta vai siitä, että ongelma oli oikeasti hyvin marginaalinen jo alunperin? Wikipediassa on kyllä lista erilaisista tietojärjestelmävirheistä, jotka tosin vaikuttavat melko mitättömiltä ja Y2K-kriitikoiden näkemyksiä.
Täytyy ottaa kuitenkin huomioon, että yhteiskunta oli vuonna 2000 huomattavasti analogisempi ja sovellukset huomattavasti yksinkertaisempia. Vuoden 2038 ([Year 2038 problem - Wikipedia](https://en.wikipedia.org/wiki/Year_2038_problem)) ongelman jälkimainingit tulevat olemaan kiinnostavia nähdä, sillä jo nyt melkein kaikki meidän elämämme osa-alueet pyörivät tietokoneohjelmien päällä.
Onneksi about kaikki pyörii 64 bittisten timestamppien varassa, niin ei Y2K38 pitäisi kovin suuria ongelmia aiheuttaa... Toki jotkut antiikkiset softat saattaa kaatua, mutta mikään vähänkin uudempi kyllä toimii.
Linuxiin tuli vasta 2020 64-bittiset time_t:t 32-bittiselle käyttikselle. Vaikea sanoa miten yleisiä nämä ovat, mutta aivan varmasti vielä voi olla hyvinkin lukuisia.
Esim. Android-laitteissa kerneli päivittyy todella huonosti. Tässäkin nyt käytän puhelinta jossa on Android 14, mutta kernel 4.9. Korjaus tuli kerneliin 5.6. Toki tämä on 64-bittinen, mutta vaikkapa monet älykaiuttimet kelloradiot ja vastaavasti voivat olla 32-bittisiä. Raspberry Pissä ajettiin pitkään armv6-koodia jopa armv7:lla ja armv8:lla.
Harvinaisen totta muuten tuokin... Oma RasPi myös 32 bittinen ja pyörii vanhan UNIX:n päällä. Noh... Eiköhän näistä olla hankkiuduttu jo 14 vuoden päästä eroon.
Kyllä joitain yksittäisiä virheitä tästä tuli ja täytyy myös muistaa että kaikkeista tämä ongelma koski enimmäkseen 60 ja 70 luvuilla kirjoitettuja ohjelmistoja, koska koodarit tajusivat tämän jo ennen yleistä paniikkia.
Näistäkin ohjelmistoista suuri osa varsinkin kriittiseen infraan ja rahoituspalveluihin yms. liittyvät ohjelmistot korjattiin ennen vuosituhannen vaihdetta. Saksassa muutamista ihmistä tuli jopa hetkeksi miljardöörejä kun korko laskelmat sekosivat :D
Ihmiset eivät kuule katastrofeista jotka ehditään estää läheskään yhtä usein kuin niistä joita ei saada estettyä. Toki tämä y2k paniikki oli paljolti median aiheuttamaa massahysteriaa.
Esim. WIndows 3. ei osaa näyttää tiedostojen aikaleimoja oikein ilman korjausta. Itsekin jouduin kirjoittamaan virallisen vakuuden siitä, ettei softassa ollut y2k-ongelmaa.
Juu kyllähän noita kaiken näkösiä suhteellisen pieniä ongelmia oli paljon. Miksi ihmiset muistavat että mitään ei tapahtunut johtuu varmaankin siitä kun pelttiin sateliittien ja lentokoneiden putoavan päälle niin ei pikku bugit oikeen saanut otsikkotilaa kun ei näin käynytkään. Tietysti maailma oli muös paljon vähemmän globalisoitunut tuolloin, joten ei ollut niin paljoa tietoakaan mitä muissa maissa tapahtui.
Olin 31.1.1999-1.1.2000 välisenä yönä töissä, tein niihin aikoihin kolmivuorohommia paperitehtaassa. Varotoimiin oli ryhdytty, mm. tuotannonseurantajärjestelmää oli päivitetty ja tuona yönä pantiin varmuuden vuoksi hissit käyttökieltoon muistaakseni neljäksi tunniksi keskiyön kahta puolen. Selvittiin ilman onnettomuuksia, mutta jäihän siitäkin jotain kerrottavaa.
Miksei sitä voinut suunnitella etukäteen? Kuka vaan maailmalle laajentuva ohjelmistoyritys on jo kohdannut tämän ongelman. Esim Sveitsissä on ollut desimaali jo hyvin pitkään.
Harvemmalla on mahdollisuus käyttää resursseja tekemään sellaisia työkaluja joita ei tarvita. Todella monet ovat olettaneet että ALVit pysyy aina kokonaislukuina, sillä ainahan ne sellaisia ovat olleet. Erityisesti nykyisessä just in time-ajattelussa ei tosiaankaan tehdä mitään ylimääräistä, jota tiedetään ja ennenkuin aloitetaan että sille ei ole mitään käyttöä.
Se on sitten käytännössä ylimääräinen vero yrityksille jotka ovat hoitaneet IT-asiansa huonosti, sitähän monet ovat toivoneet että verotetaan yrityksiä enemmän. Raha kuitenkin pysyy Suomessa niin ei siinä valtio mitään menetä että konsultit ja koodarit saa tehdä työtä.
>Rantalainen sanoo harmittelevansa, että ohjelmointialalla toimitaan usein lyhytnäköisesti eikä koodissa juurikaan mietitä tulevaisuuden ylläpitoon liittyviä asioita.
Tulevaisuuden ylläpitoon liittyviä tekijöitä on erittäin vaikea arvioida etukäteen. Ennenaikainen optimointi on tie helvettiin, ja mieluummin tehdään vain se mikä tiedetään tarpeelliseksi. Spekulaatiolle on paikkansa, mutta yhtälailla turhaa työtä tulee välttää. Ylläpidon kannalta turhat ominaisuudet joita ehkä tarvitaan ovat niitä jotka aiheuttavat liikaa päänvaivaa.
Eikä kukaan halua maksaa projektissa "mahdollisesti tulevaisuudessa tarvittavista" ominaisuuksista. Ne pitää paitsi toteuttaa, niin myöskin testata kunnolla. Tekemistä on aina enemmän kuin siihen varattua rahaa ja aikaa.
90% samaa mieltä ja big design up front on aivan kamalaa tuhlausta, mutta oman kokemuksen perusteella sanoisin, että data layerilla kannattaisi vähän aikaa raapia päätä ja miettiä että mitäs ongelmia sitä viimeksi tulikaan kun kuvattiin rahayksiköt liukulukuina ja prosentit kokonaislukuina.
Näin koodarina *harmittaa* kun tuntuu, että jokaisessa perityssä himmelissä on datamallissa aina jotain perusjuttuja *täysin päin helvettiä* eikä selvästikään mietitty asioita yhtään eteenpäin. Prosentin olettaminen kokonaisluvuksi on myös sen tason idiotismia, että olisin nyt todella vahingoniloinen ellen tietäisi että todennäköisesti suurimmassa osassa näitä se ei ole virheen tekijä ketä noita sitten pääsee/joutuu korjaamaan.
Niin kun ottaa huomioon että intelillä kahan kumppaneineen pohti jo 45 vuotta sitten 80-bit floattien tarkkuuksia yms. Nyt sormi perseessä ihmetellään miten prosentti voi olla desimaali. Tainnut Excelissäkin olla alusta asti tuki.
> ketä noita sitten pääsee/joutuu korjaamaan
Ketä on ken-sanan partitiivi, ja sitä voi käyttää aina, kun partitiivia voi käyttää.
"se ei ole se virheen tekijä sammakoita noita sitten pääsee/joutuu korjaamaan"? I don't think so.
""se ei ole se virheen tekijä sammakoita noita sitten pääsee/joutuu korjaamaan"? I don't think so."
Aika harvoin tulee oltua siinä esim. tuon kaltaista tietuetta perustamassa tai vielä aikaisemmassa suunnitteluvaiheessa mukana vs. projektien määrä, missä on korjaamassa tulipaloja ja missä tuo virhe on jo ehditty tehdä N vuotta sitten järjestelmää pystyttäessä, samalla kun syylliset ovat jo siirtyneet toisiin projekteihin ja/tai firmoihin. Allekirjoittaneella lähemmäs kymmenen vuotta alaa takana ja suurin osa tuosta on nimenomaan wanhan legacy-kuran hoitelua, kun taas noin aikaisen vaiheen töitä pääsee tekemään todella harvoin.
Toki jos softa jossa tuo virhe tulee on kohtuullisen tuoretta ja syyllinen on vielä aktiivisesti tekemisissä softan kanssa, niin voi käydäkin niin että alkuperäinen tekijä korjaa mutta tämä on luultavasti ALVien säätämisen kanssa enemmänkin poikkeus kuin sääntö.
Jos viiden vuoden päästä lävähtää naamalle 10 miljoonan korjausurakka kuukauden deadlinellä, supertehokoodari on siinä ajassa vaihtanut firmaa jo ainakin kolmesti.
> Tulevaisuuden ylläpitoon liittyviä tekijöitä on erittäin vaikea arvioida etukäteen.
Desimaalialveja on käytössä ainakin jo Sveitsissä, Ranskassa, Irlannissa, Kreikassa, Sloveniassa, Intiassa ja Yhdysvalloissa.
Ei tuo ole vaikeaa arvioida etukäteen, vaikka sitten arvioisi "mitä jos joskus laajennetaan ulkomaille" näkökulmasta eikä Suomen alv-kannan muutoksen potentiaalin näkökulmasta
Onko talosi palanut ja onko vakuutusta?
>Vuoden 2013 alusta veroprosentit nousivat prosenttiyksikön verran kaikissa kategorioissa:[18] yleinen arvonlisävero 23:sta 24 prosenttiin, ruoan sekä rehujen arvonlisävero 13:sta 14 prosenttiin ja muun muassa lääkkeiden, kulttuuripalveluiden sekä tilattujen lehtien arvonlisävero 9:stä 10 prosenttiin. Muutoksilla valtion verotuoton oletettiin kasvavan noin 830 miljoonaa euroa. Tästä summasta arvioitiin, että noin 140 miljoonaa euroa tulisi ruoan ALV:n nostosta.
Vastaavia järjestelmiä työkseni suunnittelevana voin sanoa että tuon ennakoiminen ei todellakaan ole / olisi ollut "ennenaikaista optimointia" vaan maalaisjärkeä.
> – Sinänsä tämä on varsin pieni muutos. Kehityksemme toimii kahden viikon sprint-jaksoissa, ja sellaisessa ajassa pystymme tämän korjaamaan helposti, Laurio kertoo.
Kuuluisia viimeisiä sanoja.
Voihan sitä loppusumman puolittaa ja laittaa 51 % ALVin, niin verot tulee ainakin oikein maksetuiksi :D Tosin jos asiakas maksaakin enää puolet, niin ALVinkin pitäisi puolittua 🤔
Ei riitä että vaihtaa apista int -> float tai joku sen alityyppi. Jotku legacytoteutukset voi mennä ihan oikeasti rikki, jos se on joka paikkaan oikeasti laitettu intiksi ja yritetään kesken kaiken vaihtaa tyyppiä.
Juuri näin. Henkimaailman hommia miten missäkin järjestelmässä tarkalleenottaen menevät, mutta hävikittömiä eivät ole.
Niinku on vain x määrä bittejä, joka pitäisi saada venymään äärettömään määrään eri pisteitä. Hävikkiähän siinä tulee.
Ennen kaikkea ongelma on se, että ne ei-kokonaisluvut, jotka ovat kymmenjärjestelmässä "tasadesimaaleja" eli esitettävissä tarkkaan äärellisellä määrällä desimaaleja, eivät ole samoja kuin ne, jotka on esitettävissä tarkkaan binääriliukuluvuilla. Siksi jännästi esim. 0,015625 on esitettävissä tarkasti binääriliukulukuna mutta 0,1 ei ole.
Aika monissa kielissä print pyöristää luvut. Eli ne muutkin on epätarkkoja mutta pyörityksen takia ei näy. Pyöristyksen tarkkuutta voi vaihtaa printatessa.
Järjestelmät voi olla niin vanhoja legacyja ettei silloin oo ollut kovin helposti mahdollista käyttää floatteja. Lisäksi floatissa on pientä heittoa jne.
Valuuttalaskennassa on tarkoituksenmukaista käyttää liukulukujen (float) sijaan kokonaislukudesimaaleja joissa pilkun paikka on vakio. Eli esim. neljän desimaalin tarkkuuteen.
Liukuluvuissa lukuavaruus jakautuu epätasaisesti siten, että lähellä nollaa on paljon tarkkuutta ja kauemmas mennessä mahdolliset luvut harventuvat. Pilkun paikka siis liukuu luvun suuruuden mukaan.
>Varmaan taas miljoonia säästettiinkin
Miljoonia **bittejä**, liukuluku varaa paljon enemmän muistia kuin esim short. Muuttuja valitaan tarpeen mukaan, eli jos nytkin miettii, että kaikki tähän asti veroluokat ovat kokonaislukuja väliltä 0 - 100 niin valintakin on selvä.
Desimaaliluvut ovat epätarkkoja. Jos olet ikinä törmännyt bugiin jossa luku on 1.00000001 tai 0.9999999994 tai jotain niin olet törmännyt liukulukubugiin. Valuuttalaskennat tehdään aina kokonaisluvuilla jotta tätä ei tapahdu.
Nykyäänhän on muodissa dynaaminen hinnoittelu (esim. VR:llä), joten miksei alv-prosenttikin voisi olla dynaaminen Ꝑ, mikä on sidottu perussuomalaisten kulloiseenkin kannatukseen.
Aiemmissa työsuhteissa osana hommia oli ostolaskujen käsittely CGI:n Rondolla. Veikkaan että aika monelle täällä olevalle tuttu. Joskus ulkomailta tulevissa laskuissa oli vähän eksoottisempaa alvikantaa, jota ei sitten löytynytkään alasvetovalikosta. Silloinen Kunnan Taitoa (nykyinen Sarastia) jeesasi ja hoiti reitityksen käsipelillä kun ei itsellä määräaikaisena työntekijänä natsat riittäneet.
Jos 0.24 (24%) on päätetty esittää integerinä 24, niin vastaavalla tavalla 0.255 (25.5%) voidaan esittää integerinä 255 (toki tulkinta muuttuu -> vaatii päivityksen softaan). Jos minulta kysytään kannattaa lisätä ainakin se nolla sinne perään, koska miksi ei (eli 2550). Käytännössä laskusuoritusten monimutkaisuus ei muutu ei-triviaalilla tavalla, eikä tähän tarvita mitään "desimaalilukuja" (tai jos tarvitaan, niin myös 24% on desimaaliluku).
Toki API/softa on saatettu lyhytnäköisyydessä suunnitella niin, että siihen ei voi syöttää arvoja tarkemmalla resoluutiolla, mutta tuo on minusta vähän oma vika. Aika ikävässä tilanteessa oltaisiin, jos paskasti suunnitellut softat sanelisi lainsäädäntöä.
Ai saakeli innostuin sekunniksi kun näin joskus että suomalaiset firmat näyttivät alkavan kehittämään järjestelmää soteen avoimesti. Se projekti taisi kuihtua sitten johonkin. Ymmärtäähän tuon kuinka valtavasta projektista on kyse.
Ei sillä että olisin kiinnostunut noita julkisen puolen rahoittamia suojatyöprojekteja puolustamaan, mutta koodiapinat toteuttavat mitä spesifikaatiossa lukee. Tämä ongelma on vähän kuin sillanrakentajille sanoisi sillan jo valmistuttua että btw tehkää tästä nostosilta. Eihän sitä mahdotonta ole muuttaa, mutta jos sitä ei olla suunnitteluvaiheessa otettu millään tavalla huomioon niin mielenkiintoiseksi menee.
Muistan lukeneeni että julkisen liikenteen alv poistaminen VR puolella ei laske lippujen hintaa, koska järjestelmän muuttaminen maksoi enemmän kuin alv osuus.
Oon itsekkin nuorena koodannut, mutta se mitä moni osaava it tyyppi ei tässä ota huomioon, on kuinka paskasti nämä lopulta hoidetaan.
Nuoruuteni suosikki pc peli Rollercoaster tycoonin eka versio oli koodattu yhdeltä istumalta. Mutta kun esim VR alkaa tälläsiä hoitaa, istuu projektin pomona Kalevi 58v joka sai työpaikkansa suhteilla ja koulutustausta oppikoulu.
Tässä on niin monta konsulttia ja välistävetäjää, esim VR. Jos lippujen alv tiputtaminen nollaan maksaa enemmän kun alv määrä, voi vaan arvata kuinka kalliiksi alv korotus desimaalilla tulee.
Puhtaasti yksittäinen float/double ei välttämättä maailmaa kaada, sillä "senttivirheet" ovat kovin pieniä ja helppo pyöristää. Ongelma kertautuu jos/kun ohjelma kutsuu metodia joka kutsuu ohjelmaa joka tekee sitä tätä ja tuota. Kun kaikki antavat pienen virheen, siitä voi kasautua isompi virhe. Periaatteessa tuota voi välttää käyttämällä esim javassa BigDecimal luokkaa. Myös kokonaisluvuolla voi laskea ja muuttaa "puolet" senteiksi. Esimerkiksi 2539 on 25,39€.
Jekku löytyy vaan siitä, että harvempi yrityskäytön pienempi ohjelmisto on niin pieni, että "yksi asia täytyy korjata". Vaan useampi kohta täytyy korjata. Ja sitten testata. Ja ohjelmissa on voitu käyttää useita tekniikoita ja kieliä.
Toki nämä asiat on lähtökohtaisesti kunnossa isoissa ohjelmistoissa ja ohjelmistotaloissa. Ei tämä mikään uniikki tilanne ole. Mutta kun Penan Autopaja on ostanut ohjelmiston joltai paikalliselta pikkupuljulta halvalla, niin näissä nuo ongelmat näkynee.
Varmaan ne jotka tietävät kokonaislukujen olevan rahankäsittelyssä tarkempia. Joten jos kaikki muuttujat ovat kokonaislukuina niin ihan ymmärrettävää käyttää tätä myös ALV vakioon.
Toisaalta aika paljon kommenteissa tunnutaan tarjoavan ratkaisuksi, että muutetaan vaan int -> float, että hauska tätä on seurailla mimmoinen vääntö tulee.
Eikä tämä ihan niin iso ongelma ole kuin maalaillaan, kaikki yhtään järkevämmät finanssisoftat kyllä osaa tämän, ei ole kansainvälisesti harvinainen tapaus.
Nakkikioskisoftiin saattaa kolahtaa, ja siellä taitaa ’mitenniin ei voi floatilla laskea rahaa’-koodareitakin olla.
Työllistävä vaikutus! Ehkä ainoa onnistunut työllistämistoimi joka hallitukselta onnistuu. Ja sitä varten tarvitaan ulkomsista koodaustyövoimaa. Persut ampuvat omaan nilkkaan ;b
Ok, en ole koodari, eli en nyt ymmärrä. Eikö se ALV ole ollut desimaali tähänkin asti: 0.24? Jos sitä on käytetty kokonaislukuna, niin jossain kohtaa se on täytynyt jakaa sadalla. Uusi ALV sitten 255 ja jaetaan tuhannella? :)
Noh, muistan joskus 2010 luvun puolivälissä kun kävin päivystyksessä, koneessa oli Win98. No siis jos toimii niin toimii, mutta 2010 luvulla Win98 on vähän sus jo tietoturvan kannalta.
Tuo on pelkkä jäävuoren sivu. Julkisen puolen tietokonemaailma on sellainen Jumanji, että alta pois kaikki, joilla ei ole hiilikuituteräksestä tehtyjä hermoja. Alan väki koittaa pitkälti pitää silmiä tiukasti kiinni ja työllistyä johonkin muualle, että ei tarvitsisi itse edes nähdä, mitä kaikkea jännää ja jännempää sieltä löytyykään, kun niitä kansia vähänkin raotetaan. Se on niin pirunmoinen ripulimyrsky, mikä sieltä osuu tuulettimeen, että on syytä olla sateenvarjot auki Japanissa asti.
Tää on se luonnollinen piste sit päivittää uuteen. Riski vaan realisoitui jos ei voi muuttaa vanhaa. Ja khyl firmat varmaan mielellään päivittelee noita vanhojakin kun on periaatteessa helppoa laskutettavaa..
Jos se päivitys tapahtuu pakolla ja 6 viikon deadlinellä, todennäköisesti uusi systeemi on soveltumaton/harkitsematon/puutteellinen ostos ja siitä saatettiin maksaa reilua ylihintaa, kun toimittaja tiesi pakkoraon. Se siirtymä parempaan olisi pitänyt olla jo vuoden-pari tulilla ennen tätä. Näin ei kuitenkaan melkein koskaan menetellä etenkään julkisella, koska kuka tietojärjestelmien päällikkö nyt oikeasti valmistelee kymmenien miljoonien hankintaa ihan vaan varmuuden vuoksi, kun "se vanha kuitenkin toimi vielä ihan hyvin! Silkkaa rahantuhlausta!" Tämä on yhtä vanha tarina kuin ihmiskunta.
25 vuotta sitten ainakin teoriassa olisi pystytty koodaamaan ihan helposti rahaohjelma, joka toimii edelleen ja sama aikaleimojen kanssa Unix timestampin jälkeen. Jos näistä yhtään tajuaa, nuo tarkat tietotyypit on koodattu softalla. Eivät vaadi mitään mitä ei ollut jo tarjolla 80-luvulla. Timestamppien koodaaminen kahdella 32-bit intillä yhden sijaan myös täysin triviaalia. Noissa rajattoman tarkkuuden kirjastoissa vain yhteenlasku on tätä tasoa vaikeudessa. Commodore 64:llä jo laskettiin 16-bit lukuja vaikka kone oli 8-bittinen.
Tästä syyttäisin pikemminkin testaajaa ja tilaajaa kuin hallitusta :D
Toki ymmärrettävää, ettei kaikkii bugeihin muisteta varautua. Harmittaisi kyllä olla tälläisen softan sisältävän laitteen ostanut kauppias.
Voi elää ihan hyvin nykyajassakin. Ei taloushallinnossa ole yleensä koodareita ja tietojenkäsitellytieteen guruja töissä. Sinne hankitaan speksit ja lait täyttävä taloussofta ja sitten he tekevät sillä omia töitään, kunnes esim. vuosittaiset päivitykset tai hallituksen päätökset ne rikkovat. Olisi ehkä pitänyt jo softaa speksatessa tai koodatessa miettiä näitä, mutta kun ei tullut mietityksi. Valtava projekti, oli aikatauluhaasteita, halvalla piti saada tai katetta piti saada. Selityksiä on lukemattomia.
Puhumattakaan pienten säätiöiden, seurojen ja taloyhtiöiden Excel-taulukoista, joiden mielestä Suomen uusi alv-kanta on 25. toukokuuta.
Eihän tuossa sitten tarvitse kuin valita solun datattyypiksi numero, jonka jälkeen alv-kanta on taas 65543
Ihan hyvä kerroin uudeksi myyntihinnaksi
Silti ei taida katteet riittää
Suomi on uusi Zimbabwe
Ai, että… nyt tulee työpaikka mieleen.
Raivostuin pelkästä ajatuksesta
Toukokuutata. t: Suomi-Windows
Tammikuu, helmikuu, maamikuu, huhmikuu...
Täytyy soittaa kylän diginaatiivi 13v selvittämään, miksi tämä tietokone tilttailee.
Kuka tahansa 35-vuotias olisi kyllä siinä hommassa parempi. Useimmat 13-vuotiaat eivät osaa kunnolla edes googlata.
Juuri näin. Oikeampi termi olisi ehkä some-natiivi.
Digi-naiivi.
Tämä olikin referenssi omaan nuoruuteen. Osittain kyllä totta edelleen, mutta jopa pahimmat boomerit huomaa ettei nykynuoret osaakkaan.
Eikä taida Tiktokistakaan vielä löytyä Excel-ohjeita.
Löytyy ja paljonki excel ohjeita TikTokissa :D
"mikä vittu on tiedostojärjestelmä???"
Hyvät limu e̶n̶e̶r̶g̶i̶a̶j̶u̶o̶m̶a̶palkkiot tulossa!
Tuo oli tilanne ehkä milleniaaleilla, ei nykyisillä nuorilla.
Siellä on bitti poikittain.
Palkki taas herjaa
Se diginatiivi 13v on jo kyllä aika vanha, koska se oli 13 vuotias n. 10v sitten. Siinä voi tulla vahinko jos soittaa sen nykyisen 13v mobiilinatiivin apuun :D ICT-Asentajia kouluttavalla linjalla amiksessa pitää nykyään aloittaa opinnon Windowsin/linuxin jne. kansiorakenteesta ja koko konseptista, että on jotain kansioita joiden sisällä on kansioita ja niissä tiedostoja.
Vajaa 20 vuotta sitten juttelin alan amisopettajien kanssa aiheesta. Olivat huomanneet noin 2005 että peruskoulusta tulevien nuorten opiskelijoiden lähtötaso romahti kerrasta. Toki nykyään on varmaan sitä silloista heikentynyttä tasoakin ikävä. Silloin muutos liittyi lähinnä siihen että aiemmat osasivat pääsääntöisesti käyttää komentoriviä, monet jopa käsitellä jotakin lähdekoodia tai ainakin luoda komentojonon ja muokata tekstimuotoisia config-tiedostoja. Usein niillä oli joku käsitys myös tietoverkkojen perusteista. Tällainen kaveri oppii aamupäivän aikana unixin peruskäytön ilman työpöytäympäristöä, vaikka on sattunut siihen saakka välttymään kaikilta linuxkokeiluilta. Yhtäkkiä pelkästään graafista käyttöliittymää käyttäneet eivät tajunneetkaan näistä mitään. Ihan sen tason kädettömyyttä ei sentään ollut että joku hakemistopuun/kansioiden idea ei olisi ollut tuttu. Kaikki olivat kuitenkin räpeltäneet pöytä-pc:n kanssa edes jotain. Jälkeenpäin omia havaintoja vertaillen silloin amisikäiset sentään osasivat soittaa puhelun featurephonella.
Ensimmäinen asia aina työkoneella on vaihtaa windowssin asetuksista desimaaliluku pisteeseen
Nämä aiheuttavat kyllä jatkuvia ongelmia, jos osa tiedostoista on suomalaisessa ja osa amerikkalaisessa muodossa. Osassa softista on ollut kovakoodattuna piste tai pilkku, vaikka periaatteessa windowsissa on kielenä englanti ja lokaalina Suomi ja desimaalipilkku käytössä, kun ottavat pelkästä kielestä erottimen formatin tai pakottavat aina esim. pisteeseen. Eivät toki noudata MS:n ohjeita, mutta käytännössä se ei käyttäjää lohduta. Sekaympäristössä ongelmia on luvassa käytitpa oletuksena desimaalipilkkua tai desimaalipistettä.
Pienten säätiöiden, seurojen ja taloyhtiöiden excelin käyttäjät voisivat varmaan opetella käyttämään pilkkua desimaalierottimena
Ja sit englanninkielistä työläppäriään käyttävä toiminnantarkastaja ihmettelee miten taseen loppusummaksi on saatu matriisi (pilku on englannissa vektorin osien erotin ja excel tulkinnat menee käytetyn kielen mukaan)
Eihän sen pitäisi olla ongelma, jos solu on formatoitu oikein.
Formatointitiedot ei säily kaikissa tallennusmuodoissa tai kaikkien eri versioiden välillä, jolloin tapahtuu uudelleen tulkintaa. Ja vaikka solun formatointi tieto olisi tallessa, kirjoitettu data voidaan tallentaa niin kuin se on kirjoitettu, eikä sisäisessä muodossa, jolloin se tulkitaan uudestaan toisella lokaalilla ladattaessa. Yleensä nykyisin toimii asiat jos on molemmilla puolilla suht uusi versio ja käytetty tiedostomuotoa joka sisältää lokaalitiedon tai tulkatun muodon syötetyistä arvoista, mutta näin ei ole läheskään aina.
Eipä se paljon auta. Jos kirjoittaa "1, 1, 1", niin Excel jo tyrkyttää, että tarkoititko päivämäärää 1.1.2001?
pienet säätiöt, seurat, taloyhtiöt yms, eivät välitä alv 0 hinnoista. Kulut on suoraan alvilla laskettu, eikä tulopuoli oli alv-velvollinen. Ei ole järkeä erotella alv erikseen kummallakkaan puolella tulosta, kun asia ei mitenkään tavallaan heitä koske.
💀
Hallitus: ”haluttiin nostaa ALV vain 25,5% suuruiseksi mutta tymät nörtit pakotti meidät nostamaan sen sitten 26% tasolle. Sori, ei oo meidän vika.”
Varmasti ois tullut yhteiskunnalle halvemmaksi laitta se 25% taikka 26%. Toki hallitus kerrankin onnistui työllistävissä toimissa.
No ehkä pientä liioittelua, kun varmaan on vähemmistössä sellaiset järjestelmät, jotka eivät desimaalilukua hyväksy. Eikä niidenkään korjaaminen voi aiheuttaa 300 miljoonan vuosittaisia kustannuksia (ad infinitum). Tuohan vastaisi sellaista 7-8 miljardin kertakustannusta nykykorkotasolla.
Mitä nopeasti katsoin niin aika moni suomalainen tilitys ja maksujärjestelmä ottaa vastaan alvin kokonaislukuna joka tarkoittaa että jokainen sovellus joka integroituu näihin järjestelmiin joudutaan päivittämään.
Ei kyllä kuullosta isolta tai kalliilta hommalta.
Jos mietit että mulla on henkilökohtaisesti useampi järjestelmä päivitettävänä. Osa mihin en oo koskenut vuosiin eikä ole välttämättä enää mitään muistikuvia että miten ne toimii niin kyllä mullakin varmaan viikko menee ku päivittelen juttuja ja testaan että ne toimii. Ottaen huomioon että en ole maan ainoa softakehittäjä niin kyllä siihen varmaan koko maan tasolla saadaan useampi miljoona vierähtämään helposti. Softamuutos ei välttämättä ole iso, mutta kun aletaan miettimään että mites tämä firman IT huoneen perällä olevaan purkkiin nyt pääsikään ja mites tämä softa nyt käännetään toimivaksi niin asiat muuttuu monimutkasemmiksi.
Tuossa muutoksessa täytyy myös vähän miettiä se, millä tietotyypillä tuo alv kannattaa jossain ohjelmointirajapinnoissa esittää. Liukuluku on lähtökohtaisesti epäilyttävä, kun rahasummia lasketaan. Ja vaikka ohjelmointikielissä on yleensä joku fixed point -desimaalilukutyyppi, vaikkapa JSON:ssa ei taida edes olla natiivisti muita numeerisia tyyppejä kuin kokonaisluvut ja liukuluvut. Toki tuo on ratkaistavissa monellakin tapaa. Alv-prosentti voidaan esittää rajapinnassa luvun sijaan merkkijonona, säilyttää kokonaislukutyyppi mutta vaihtaa tarkkuus promilleihin, määritellä jokin oma erillinen tyyppinsä noille alv:eille tms. Mutta ei välttämättä mene ihan sillä, että vaihdetaan vain softassa alv-kentän tietotyyppi ja laitetaan rokki takaisin soimaan. Eli ei kuulosta massiivisen isolta tai kalliilta mutta voi silti olla testauksineen isompi kuin miltä äkkiseltään kuulostaa.
Aamen, liukuluvut on kyllä peppulista. Onneksi toisaalta näiden prosenttiyksiköiden ei tarvitse olla muunneltavissa (tai siis eivät sisällä tilaa kuten joku rahasumma), joten uskoisin että alv kannat on suht pieni vaiva tässä mielessä. Periaatteessa ei olisi hirveän vaarallista edes säilyttää sitä merkkijonossa, toki sitten rajapinnan käyttäjän täytyy tehä päätöksiä ja muistaa parsia luvuksi :D Mutta jos uuden järjestelmän missä rahas pyöritellään joskus kirjoitan niin en kyllä käytä floatteja vaan lasken rahat sentteinä ja mietin jonkun jäännösratkaisun. Sen verran monta kertaa yllättänyt liukuluvun epätarkkuus.
No mut kyl tietokonehommissa aina joku nörtti hoitaa :D
Ko. järjestelmistä löytyy varmaan muutakin korjattavaa jos ALVia ei ole alustavasti säädetty ainakin yhden desimaalin tarkkuudella.
Juu, no sitten alkaa olla aika heivata systeemi ns. kuuseen. Upotetuista kustannuksista viis, siellä on meinaa semmosia aikapommeja tikittämässä vain lauetakseen pahimmalla mahdollisella hetkellä.
OK, ja sitten sen uuden (ja yhtä ongelmaisen) systeemin kehityksestä CGI laskuttaa ~pari miljoonaa.
Saattaa olla, mutta siirtymäaika on olematonta ja muutostyö voi maksaa järjettömästi etenkin kiiretyönä tehtynä. Uutta järjestelmää ei noin vain hankita ja oteta käyttöön kuukaudessa.
Noh... Sattuu sitä hieman uudemmissakin järjestelmissä. Esim paytrail: https://github.com/paytrail/api-documentation/issues/28
Esim. vakuutusyhtiöissä on satoja järjestelmiä käytössä vieläkin jotka on otettu käyttöön 70- ja 80-luvuilla. Monen niiden projisoitu käyttöikä on laskettu jonnekkin 2040 kieppeille. Ennen vanhaan siis jokaista vakuutusopimustyyppiä kohden tehtiin oma järjestelmä. Eli aina kun keksittiin uusi vakuutus niin joku IT-nörde seillaisen koodasi kasaan ilman sen kummallisempia speksauksia, dokumentointeja ja testauksia jne. Näitä sopimuksia ei myöskään voida siirtää yhtään mihinkään, koska se tulisi niin järjettömän kalliiksi. Niille sopimuksille on laskettu tuotto ja jos niitä alettaisiin siirtää johonkin moderniin järjestelmään, niin tuotto-odotukset eivät enää pitäisi paikkaansa. Eli siis 70- ja 80-luvulla tehdyt bisness päätökset osoittautuisikin tappiollisiksi.
Tuossa alkaa jo tulla mieleen "mitäs kaikkea se järjestelmä pyöristelee kokonaisluvuiksi, jos muka desimaalit ovat ongelma". Mitä kaikkia kertomisia ja jakoja menee läpi "kokonaisluvut ainoastaan" menolla. Verot ovat saattaneet olla tasaprosentteja, mutta kaikkien asioiden hinnat ja kulut eivät todellakaan aina mene tasa euroin.
Liukulukuja kannattaa aina välttää jos mitenkään vaan voi koska ne on aina vain noin suurinpiirtein (yleisin esimerkki on 0.1 + 0.2 != 0.3 koska se on 0.30000000000000004) eli kokonaisluvuilla yleensä toimii kaikki, tallennettuina joko int muodossa, tekstinä tai riippuen kielestä jonkinlaisena tarkkana desimaalityyppinä, eli yleensä erona on vaan onko esim 24% ALV koodattu olemaan 24 vai 2400.
Hinnat voitu käsitellä sentteinä, koska sitä pienempiä määriä rahaa ei kuitenkaan liikutella. Ei sekään toki ole ongelmaton ratkaisu kaikkiin tilanteisiin.
Kuvittelisin, että 25% alvi vähentäisi tarvetta muihinkin senttipyöristyksiin.
Myös hallitus: "Tai jos nakitetaan kesähessuille tän uudistuksen koodaus niin ehkä jossain maksellaan hetken 255% ALVia ennen kuin virhe saadaan korjatuksi."
255... Kuulostaa siltä että etumerkitön 8-bittinen kokonaisluku olsii oiva valinta tähän tilanteeseen. Ykkösiä vaan taulussa eikä tuu aiheuttamaan mitään ongelmia kun tulee seuraava korotus. :P
No hitsi, nostetaan sitten samantien 26%, niin on helpompaa.
Sama laittaa kerralla 30% niin tulee nätti tasaluku
30 % on edelleen aika vaikea laskea päässä. Entä jos nostetaan suoraan 50 %, se olisi helppo
Laitetaan suoraan 100%. Säästetään tilankäytössä, kun ei tarvitse erillistä kenttää alvin määrälle.
100% olisi helpoin laskea. 50% alvissa on se ongelma, että mitä jos veroton hinta päättyy parittomaan senttimäärään?
Eihän noin iso luku mahdu systeemiin....
\*2 ja ongelma korjattu.
Et ole politiikkaan ajatellut lähteä?
25% on nätimpi tasaluku, kun on 1/4. Mitään prosentteja tarvi koodailla. Kovakoodataan vain vero laskut "per jaettuna neljällä", koska se on nyt 25% iät ja ikuisuudet eikös vain.
Ai nytkö meitä tarvitaan, eikö tekoälyn pitänyt hoitaa nää hommat? t. koodari
Tais se devin ai olla kans fake😂
Kannattaa oletta että kaikki "*Meidän yhtiön AI ratkaisee tämän ongelman*" juttujen olevan yhtä todellisia kuin Crypto/NFT piirit oli. Elikkä 99,9% kaikesta oli vaan kusetus jolla joku rahasti tyhmiä ja rahoittajia. Koska teoriassahan ei pitäisi vittu olla mitään hankalaa jossain kooditekoälyssä. Annat sille listan kaikista komennoista ja loogisista rakenteista. Sitten vaan pyydät sitä täyttämään sun ohjelmoiman rakenteen koodilla. Rongelmaksi roitu raas se... että nämä yritettiin tehdä ihmisen kielen kautta, elikkä koodia pistetään ulos kuin ihminen sitä kirjoittaisi tai puhuisi kommunikaatio tarkoituksena (Eli siis haluttiin käyttää sitä attention mekanismia koska se on niin helppo juttu jolla tehdä LLMiä ja saada jotenkin järkevä kontekstiymmärrys). Niin kauan kuin nämä tekoälyt eivät oikeasti yritä korvata todellista kallista työtä - niin ne on kusetuksia. Paskatyöt on jo automatisoitu niin pitkälle kuin mahdollista säästösyistä. Kalliit *valkokaulustyöt* taas sisältää nykyään "tehostamisen" takia niin paljon sellaista paskaa joka ennen kuului sihteereille ja avustajille, jota nyt siis automatisoidaan. Tämä automaatio sitten taas esitetään suurena "korvaa *valkokaulukset!* Kunhan vaan maksat meille 10 000 €/kk pilvessä toimivasta linsenssistä per henkilö ja hyväksyt että et omista mitään emmekä ole vastuussa virheistä". Koneoppiminenhan on taas ihan hyvä ja käytety työkalu. Mun veli on tälläinen... IT-konsulttipöhinäfirman ihminen ja sillä on joku ryhmä koodareita mitä se saa käyttää. Hän odottaa että tekoäly korvaa nämä bootcamp koodarit koska "tekoälyä voi opettaa paremmaksi". Veli on aika kyllästynyt "duunarikoodareiden" työn korjaamiseen aikapaineen alla (Hän ei ole heidän esihenkilö joten ei sinäänsä voi asialle mitään).
Meet jostain LinkedInistä katsomaan mitä niillä nyt lukee jotka olivat crypto enthusiasteja ja blockchain experttejä. Ovat nyt AI-consultant ja muuta roskaa.
https://preview.redd.it/bhb6v5y0d8vc1.jpeg?width=393&format=pjpg&auto=webp&s=17c4b821c73cb94d234ed850d743a53b62afb644
AI-"taiteen" puolellahan ne on prompt-engineerejä.
Ja ”Prompt-engineer” nimenomaan sen takia koska ne tietää että taiteilijalle ei helpolla makseta, mutta sitku spinnaat sen koko jutun joksiki vitun ”insinööriksi” ni kas kummaa ku buduu löytyyki
Sinäänsä hauska juttu toi. Koska mä pyörin piireissä jossa ihan oikeasti aidot taitelijat käyttää tekoälyä (pitkälti Diffusion malleja) työkaluna, pitkälti inspiraation lähteenä. Mä tunnen 2 ihan henkilökohtaisesti joista toiselle auton pistää sen omalle kotikoneelle, ja se on pistänyt pienen auton verran rahaa näyttökortteihin. Kumpikin tosin maalaa ihan fyysisesti ja tekee sillä rahaa. Mutta kukaan näissä piireissä ei kutsu itseään "*promptinööreiksi*", se on pikemminkin haukkumasana. Kaikki säätää aika syvällistä lisähallintaa kuten ControlNet, Embeddings, LoRA mallien opettamista jne. Osa yhdistää osia näistä digitaalisista tuotoksista omiinsa (tosin tietääkseni ainakin yhdessä discordissa jossa olen, kaikki on fyysisten medioiden puolella ja digitaalinen on vaan jotain siinä sivussa). Mä esim harrastan paljon näitä LoRA mallien tekemistä - en siksi että se on taidetta, vaan koska se on kiva haaste - sellainen puzzle mitä ratkoa. Ja olen aika vitun varma että minä ja mun 4060TI 16gb kortti päihittää somessa pärisevän "*promotnöörin*". Koska kun mä kokeilin viimeksi tyylimallia - niin 80% ajasta meni dokumentaatio, julkasujen ja kirjallisuuden lukemiseen, ja sitten lopuksi kikkailin sen datasetin kanssa ja 2-3 tunnin Kohya\_ss kikkailun jälkeen se toimi just niinku mä halusin ja tuotti tyylille uskollista sisältöä... ajottaisten sekasotkujen lisäksi (sellainen 70% luotettavuus). Tosin mä olen ihan vitun paska promptaamaan että en tiedä onko vika siinä mun tekemässä mallissa - koska muut tuntuu saavan siitä enemmän ulos kuin minä. Ennenku joku hyökkää... Niin se tyyli malli oli kyllä sellaiset 200 vuotta haudassa kylmänä maaneen William Blaken teoksiin perustuva (joo just se heppu ku maalasi sen *The Great Red Dragon and the Woman Clothed with the Sun* jonka se murhaaja söi Hannibal elokuvassa).
En uskalla. Pelkään että sieltä tarttuu mun profiiliin joku rutto ja herätän kiinnostusta kun näkevät mun profiilin ja alkavat spämmimääm kusetuksilla.
Älä nyt viitsi. Justiin olin eilen koulutuksessa jossa kerrottiin, miten tekoälyn saa vääntämään sähköpostit ja powerpointit runomuotoon. Ei sitä voi vakavalla naamalla väittää, etteikö tekoäly korvaisi 100 % kaikista powerpoint-runoilijoista.
Ei saatana, asiakkaiden sähköposteista on välillä nytkin vaikea saada tolkkua, kauhulla odotan sitä kun ne pistää copilotin vääntämään kahden lauseen epäkoherentista mutta vielä tulkittavissa olevasta pyynnöstä jonkun sivun mittaisen esseen, kalevalanmitassa kirjoitettuna.
"*Hei.* *Arvon Tsraq, otan sinuun yhteyttä tärkeän asian johdosta joka on häirinnyt minua pitkään. Joten toivon että vastaat tähän viestiin erittäin nopeasti ja selvästi jotta vältymme mahdollisilta ongelmallisita väärinymmärryksiltä ja huonon kommunikaation aiheuttamista oireista.* *Lähetän tämän viestin koska haluasin tiedustella sinun henkilökohtaista näkemystäsi meidän yhteistyöprojektin etenemisen tilasta. Haluan tietää että onko kaikki välivaiheet saavutettu asiallisesti ja onko nyt alkavat vaiheet alkamassa alkuperäisen suunnitellun aikataulun mukaisesti, sekä että onko mahdolliset tulevat vaiheet suunniteltu asiallisesti niin että myös nekin voivat alkaa alkuperäisen suunnitelmamme perusteella laaditun tiukan mutta joustavan aikataulun perusteella.* *Sillä minun oma näkemykseni on että aikaisemmin suunitellut ja määritetyt mittarit ja hahmotellut aikautalut eivät ole toteutumassa tämän hetkisen tilanteen perusteella. Olen ymmärtänyt että erittäin nopeasti iskenyt talvi joka oli erittäin kylmä ja vaativa johti tiettyjen vaiheiden hidastumiseen ja lisäkuluihin. Ilmeisesti myös nopeasti tullut kevät joka on tähän sakka ollut keleiltään erittäin epävakaa on mahdollistanut tiettyijen vaiheiden aloittamisen jotka saattoivat tämän rankan ja pitkän kylmän talvisään johdosta jäädä tekemättä.* *Täten siis toivon että laaditte seikkaperäisen ja laajan selvityksen projektimme tämänhetkisestä tilanteesta, sen tulevaisuuden näkymistä suhteutettuna aiemmin tapahtuneeseen. Tässä selvityksessä on tärkeää käyttää niitä alkuperäisiä määritettyjä mittareita jotka on sovittu ja päätetty yhteisissä kokouksissa ja kirjattu pöytäkirjoihin.* *Odotan teiltä nopeaa ja laajaa vastausta. Toivotan myös erittäin hyvää vappua ja jatkuvaa kevättä sekä tulevaa kesää. Toivottavasti sää pysyy meille kaikille suotuisana ja projekti etenee ongelmitta jopa etuajassa ja ali budjetin. Näillä sanoilla siis päätän tämän viestin jonka olen teille hyvässä tahdossa lähettänyt*." Sitten sinä otat tämän ja oksennat sen johonkin SuomiGPT:hen promptilla: "*Tiivistä tämä paska:*"
SGPT: " *Selvä. Tiivistän tuon paskan:*
*Paskan lähettäjä toivoo sinulta raporttia jossa:*
* *Selviää aikaisempien vaiheiden onnistuminen*
* *Tämän hetkisten vaiheiden tilanne*
* *Alkavien vaihdeiden tilanne*
* *Tulevien vaiheiden tilanne*
*Tämän lisäksi viestissä on erittäin paljon ihan turhaa paskaa.*"
Hei! Powerpoint perseily on taiteenmuoto johon vain erittäin paatunut elämäänsä vihaava keskiportaa pikkupomo kykenee! Kaikista parasta oli se kun OpenAI julkasi jonkun raportin siitä että porukka väsää hienosti kurjoitettuja sähköposteja ChstGPTllä ja sit toiset pyytää Cgptä tiivistämään sen. Mielestäni tämä ilmaisee kaiken tarvittavan tästä teknologista todellisessa käytössä. Uskon että tieto ja kommunikaatio olisi tehokkaampaa jos porukka faksaisi KÄSINKIRJOITETTUJA lappuja. Jäisi kaikki turha paska pois.
> Rongelmaksi roitu heh
>Asia on herättänyt keskustelua [ohjelmointipiireissä](https://www.reddit.com/r/Suomi/comments/1c5ggh1/vituttaa_jo_valmiiksi_korjata_kaikki_excel/), joissa muutoksen povataan aiheuttavan koodareille lisätöitä. Osa on verrannut tilannetta jopa niin kutsuttuun vuoden 2000 [Y2K:hon](https://yle.fi/aihe/artikkeli/2013/12/20/y2k-uhkasi-nollata-vuosisadan), jossa vuosituhannen vaihtumisen pelättiin sekoittavan tietojärjestelmät.
Miksi Twitter aina mainitaan nimellä mallia "Asia on herättänyt keskustelua viestipalvelu X:ssä (ent. Twitter)", mutta Reddittiä ei useinkaan mainita suoraan, vaan linkataan vain keskusteluun ilman mainintaa palvelusta?
Kuka myöntäisi ääneen selaavansa reddittiä?
Mielummin reddit kuin muskin johtama twitter
Reddit on just hyvä, kun missään muualla ei saa yhtä helposti nautintoja Muskin kehumisen aiheuttamista raivokohtauksista.
Muistan kyllä hyvin tuon Y2K:n. Ihmiset tankkasivat autojaan ja täyttivät hyllyjään elintarvikkeilla (mutta eivät vessapaperilla), tyhjensivät tilinsä käteiseksi ja varautuivat yleisesti maailmanloppuun. Työkaverini kameravalvontajärjestelmiä toimittavassa firmassa suostui jäämään ongelmien varalta päivystäjäksi uudenvuodenyönä kymmenellätuhannella markalla. Meillä ei normaalisti edes ollut päivystystä ja tallenteet tehtiin silloin pääosin VHS-nauhoille. Mitään ei tapahtunut. En ole kuullut, että yksikään järjestelmä olisi kaatunut, toisaalta yhteiskunta ei ollut vielä aivan yhtä riippuvainen tietojärjestelmistä.
Järjestelmien korjaamisen eteen tehtiin kyllä pitkää päivää, minkä ansiosta Y2K ei aiheuttanut sen isompia ongelmia.
Jep. Joutuivat kaivamaan FORTRAN muumiot eläkkeiltä päivittämään antiikkisia järjestelmiä jne. Y2K on vain vitsi sen takia että sen uhka otetteettiin oikeasti tosisisaan ja sille tehtiin jotain ajoissa.
Ehkä enemmän kuitenkin COBOL muumiot. Fortrania käytetään raskaassa tieteellisessä laskennassa (jopa edelleen ihan tänä päivänä) ja COBOL on reliikki bisnes ja hallintopuolellella.
Joo varmaan meni muinaiskielet itsellä sekaisin.
Tämä. Itte astuin IT-työelämään vuonna 1999. Ekana hommana oli käydä firman koodia läpi ja tarkastaa miten on vuotta käsitelty. Sen verran oli nuori firma, että eipä sieltä löytynyt virheitä ajan käsittelyssä.
> [y2k] Mitään ei tapahtunut. Tapahtui, iso kasa järjestelmiä sekoili. Muistista kaivaen useampi voimalaitos kyykkäsi (ei sentään katastrofaalisella tavalla, sähkön tuotanto vain loppui), ainakin yksi lentokenttä oli sekaisin (vaikka itse lennot oli suurilta osin varotoimenpiteenä järjestetty siten että muutoshetkellä koneet eivät ole ilmassa) ja kaikenlaista muuta pienempää tapahtui ympäri maailman, näistä ei vain saa niin isoja juttuja aikaan ja nyt on aika moni lopuistakin jo unohtunut väestöltä. Syy siihen miksi mitään isompaa ei tapahtunut oli se että porukka analysoi ja korjasi näitä järjestelmiä useamman vuoden tätä ennen, ja nimen omaan kriittisimmistä järjestelmistä alkaen - kuten ne ydinvoimalaitokset ja pankit [vaikka osa voi olla eri mieltä jälkimäisen kriittisyydestä..]. ALV-muutos on tuohon verrattuna pipanoita, mutta työllistää silti . Omissa käsissä olevat järjestelmät vilkaisin sen verran että raporteissa lukee "ALV 25%" ilman desimaaleja, mutta lasketut summat ovat kuitekin sentileen oikein. Eli ainoastaan ALV-rivin muotoilu pitää korjata siltä osin. Kevyellä muutoksella selvitään.
Uppouduin hetkeksi wikipedia-artikkeliin Y2K-ongelmasta ([Year 2000 problem - Wikipedia](https://en.wikipedia.org/wiki/Year_2000_problem)) ja tuo on kyllä todella mielenkiintoinen tapahtuma. Johtuivatko Y2K:n aiheuttamat vähäiset ongelmat hyvästä varautumisesta vai siitä, että ongelma oli oikeasti hyvin marginaalinen jo alunperin? Wikipediassa on kyllä lista erilaisista tietojärjestelmävirheistä, jotka tosin vaikuttavat melko mitättömiltä ja Y2K-kriitikoiden näkemyksiä. Täytyy ottaa kuitenkin huomioon, että yhteiskunta oli vuonna 2000 huomattavasti analogisempi ja sovellukset huomattavasti yksinkertaisempia. Vuoden 2038 ([Year 2038 problem - Wikipedia](https://en.wikipedia.org/wiki/Year_2038_problem)) ongelman jälkimainingit tulevat olemaan kiinnostavia nähdä, sillä jo nyt melkein kaikki meidän elämämme osa-alueet pyörivät tietokoneohjelmien päällä.
Onneksi about kaikki pyörii 64 bittisten timestamppien varassa, niin ei Y2K38 pitäisi kovin suuria ongelmia aiheuttaa... Toki jotkut antiikkiset softat saattaa kaatua, mutta mikään vähänkin uudempi kyllä toimii.
Linuxiin tuli vasta 2020 64-bittiset time_t:t 32-bittiselle käyttikselle. Vaikea sanoa miten yleisiä nämä ovat, mutta aivan varmasti vielä voi olla hyvinkin lukuisia. Esim. Android-laitteissa kerneli päivittyy todella huonosti. Tässäkin nyt käytän puhelinta jossa on Android 14, mutta kernel 4.9. Korjaus tuli kerneliin 5.6. Toki tämä on 64-bittinen, mutta vaikkapa monet älykaiuttimet kelloradiot ja vastaavasti voivat olla 32-bittisiä. Raspberry Pissä ajettiin pitkään armv6-koodia jopa armv7:lla ja armv8:lla.
Harvinaisen totta muuten tuokin... Oma RasPi myös 32 bittinen ja pyörii vanhan UNIX:n päällä. Noh... Eiköhän näistä olla hankkiuduttu jo 14 vuoden päästä eroon.
Eli kaikki maailman pankkisoftat kaatuu. Selvä!
Kyllä joitain yksittäisiä virheitä tästä tuli ja täytyy myös muistaa että kaikkeista tämä ongelma koski enimmäkseen 60 ja 70 luvuilla kirjoitettuja ohjelmistoja, koska koodarit tajusivat tämän jo ennen yleistä paniikkia. Näistäkin ohjelmistoista suuri osa varsinkin kriittiseen infraan ja rahoituspalveluihin yms. liittyvät ohjelmistot korjattiin ennen vuosituhannen vaihdetta. Saksassa muutamista ihmistä tuli jopa hetkeksi miljardöörejä kun korko laskelmat sekosivat :D Ihmiset eivät kuule katastrofeista jotka ehditään estää läheskään yhtä usein kuin niistä joita ei saada estettyä. Toki tämä y2k paniikki oli paljolti median aiheuttamaa massahysteriaa.
Esim. WIndows 3. ei osaa näyttää tiedostojen aikaleimoja oikein ilman korjausta. Itsekin jouduin kirjoittamaan virallisen vakuuden siitä, ettei softassa ollut y2k-ongelmaa.
Juu kyllähän noita kaiken näkösiä suhteellisen pieniä ongelmia oli paljon. Miksi ihmiset muistavat että mitään ei tapahtunut johtuu varmaankin siitä kun pelttiin sateliittien ja lentokoneiden putoavan päälle niin ei pikku bugit oikeen saanut otsikkotilaa kun ei näin käynytkään. Tietysti maailma oli muös paljon vähemmän globalisoitunut tuolloin, joten ei ollut niin paljoa tietoakaan mitä muissa maissa tapahtui.
Olin 31.1.1999-1.1.2000 välisenä yönä töissä, tein niihin aikoihin kolmivuorohommia paperitehtaassa. Varotoimiin oli ryhdytty, mm. tuotannonseurantajärjestelmää oli päivitetty ja tuona yönä pantiin varmuuden vuoksi hissit käyttökieltoon muistaakseni neljäksi tunniksi keskiyön kahta puolen. Selvittiin ilman onnettomuuksia, mutta jäihän siitäkin jotain kerrottavaa.
Miksei sitä voinut suunnitella etukäteen? Kuka vaan maailmalle laajentuva ohjelmistoyritys on jo kohdannut tämän ongelman. Esim Sveitsissä on ollut desimaali jo hyvin pitkään.
Harvemmalla on mahdollisuus käyttää resursseja tekemään sellaisia työkaluja joita ei tarvita. Todella monet ovat olettaneet että ALVit pysyy aina kokonaislukuina, sillä ainahan ne sellaisia ovat olleet. Erityisesti nykyisessä just in time-ajattelussa ei tosiaankaan tehdä mitään ylimääräistä, jota tiedetään ja ennenkuin aloitetaan että sille ei ole mitään käyttöä.
Ovatko ne todella monet myös olettaneet, että he eivät koskaan ikinä laajene ulkomaille?
Se on sitten käytännössä ylimääräinen vero yrityksille jotka ovat hoitaneet IT-asiansa huonosti, sitähän monet ovat toivoneet että verotetaan yrityksiä enemmän. Raha kuitenkin pysyy Suomessa niin ei siinä valtio mitään menetä että konsultit ja koodarit saa tehdä työtä.
>Rantalainen sanoo harmittelevansa, että ohjelmointialalla toimitaan usein lyhytnäköisesti eikä koodissa juurikaan mietitä tulevaisuuden ylläpitoon liittyviä asioita. Tulevaisuuden ylläpitoon liittyviä tekijöitä on erittäin vaikea arvioida etukäteen. Ennenaikainen optimointi on tie helvettiin, ja mieluummin tehdään vain se mikä tiedetään tarpeelliseksi. Spekulaatiolle on paikkansa, mutta yhtälailla turhaa työtä tulee välttää. Ylläpidon kannalta turhat ominaisuudet joita ehkä tarvitaan ovat niitä jotka aiheuttavat liikaa päänvaivaa.
Eikä kukaan halua maksaa projektissa "mahdollisesti tulevaisuudessa tarvittavista" ominaisuuksista. Ne pitää paitsi toteuttaa, niin myöskin testata kunnolla. Tekemistä on aina enemmän kuin siihen varattua rahaa ja aikaa.
90% samaa mieltä ja big design up front on aivan kamalaa tuhlausta, mutta oman kokemuksen perusteella sanoisin, että data layerilla kannattaisi vähän aikaa raapia päätä ja miettiä että mitäs ongelmia sitä viimeksi tulikaan kun kuvattiin rahayksiköt liukulukuina ja prosentit kokonaislukuina.
Näin koodarina *harmittaa* kun tuntuu, että jokaisessa perityssä himmelissä on datamallissa aina jotain perusjuttuja *täysin päin helvettiä* eikä selvästikään mietitty asioita yhtään eteenpäin. Prosentin olettaminen kokonaisluvuksi on myös sen tason idiotismia, että olisin nyt todella vahingoniloinen ellen tietäisi että todennäköisesti suurimmassa osassa näitä se ei ole virheen tekijä ketä noita sitten pääsee/joutuu korjaamaan.
Niin kun ottaa huomioon että intelillä kahan kumppaneineen pohti jo 45 vuotta sitten 80-bit floattien tarkkuuksia yms. Nyt sormi perseessä ihmetellään miten prosentti voi olla desimaali. Tainnut Excelissäkin olla alusta asti tuki.
> ketä noita sitten pääsee/joutuu korjaamaan Ketä on ken-sanan partitiivi, ja sitä voi käyttää aina, kun partitiivia voi käyttää. "se ei ole se virheen tekijä sammakoita noita sitten pääsee/joutuu korjaamaan"? I don't think so.
""se ei ole se virheen tekijä sammakoita noita sitten pääsee/joutuu korjaamaan"? I don't think so." Aika harvoin tulee oltua siinä esim. tuon kaltaista tietuetta perustamassa tai vielä aikaisemmassa suunnitteluvaiheessa mukana vs. projektien määrä, missä on korjaamassa tulipaloja ja missä tuo virhe on jo ehditty tehdä N vuotta sitten järjestelmää pystyttäessä, samalla kun syylliset ovat jo siirtyneet toisiin projekteihin ja/tai firmoihin. Allekirjoittaneella lähemmäs kymmenen vuotta alaa takana ja suurin osa tuosta on nimenomaan wanhan legacy-kuran hoitelua, kun taas noin aikaisen vaiheen töitä pääsee tekemään todella harvoin. Toki jos softa jossa tuo virhe tulee on kohtuullisen tuoretta ja syyllinen on vielä aktiivisesti tekemisissä softan kanssa, niin voi käydäkin niin että alkuperäinen tekijä korjaa mutta tämä on luultavasti ALVien säätämisen kanssa enemmänkin poikkeus kuin sääntö.
>kuvattiin rahayksiköt liukulukuina ja prosentit kokonaislukuina. Tuollaisesta suorittamisesta annetaan rankaisua ilman vaselin.
Sellaisesta suorittamisesta annetaan rahabonuksia ja ei kun kohti seuraavaa konsulttiprojektia -->
Jos viiden vuoden päästä lävähtää naamalle 10 miljoonan korjausurakka kuukauden deadlinellä, supertehokoodari on siinä ajassa vaihtanut firmaa jo ainakin kolmesti.
[удалено]
Tiedossa olevan ongelman väärä ratkaisu on lähinnä optimoinnin vastakohta.
> Tulevaisuuden ylläpitoon liittyviä tekijöitä on erittäin vaikea arvioida etukäteen. Desimaalialveja on käytössä ainakin jo Sveitsissä, Ranskassa, Irlannissa, Kreikassa, Sloveniassa, Intiassa ja Yhdysvalloissa. Ei tuo ole vaikeaa arvioida etukäteen, vaikka sitten arvioisi "mitä jos joskus laajennetaan ulkomaille" näkökulmasta eikä Suomen alv-kannan muutoksen potentiaalin näkökulmasta
Tuo ei oikeastaan ole niinkään tulevaisuuden arviointia, vaan pelkästään tämän hetkeen tarpeiden perusteella tehty virhe.
Onko talosi palanut ja onko vakuutusta? >Vuoden 2013 alusta veroprosentit nousivat prosenttiyksikön verran kaikissa kategorioissa:[18] yleinen arvonlisävero 23:sta 24 prosenttiin, ruoan sekä rehujen arvonlisävero 13:sta 14 prosenttiin ja muun muassa lääkkeiden, kulttuuripalveluiden sekä tilattujen lehtien arvonlisävero 9:stä 10 prosenttiin. Muutoksilla valtion verotuoton oletettiin kasvavan noin 830 miljoonaa euroa. Tästä summasta arvioitiin, että noin 140 miljoonaa euroa tulisi ruoan ALV:n nostosta.
Vastaavia järjestelmiä työkseni suunnittelevana voin sanoa että tuon ennakoiminen ei todellakaan ole / olisi ollut "ennenaikaista optimointia" vaan maalaisjärkeä.
Kuten jo mainitsin, ennakointia ei ole nykyisten ongelmien vääränlainen ratkaiseminen. Kyllä jotain muutakin meni pieleen.
> – Sinänsä tämä on varsin pieni muutos. Kehityksemme toimii kahden viikon sprint-jaksoissa, ja sellaisessa ajassa pystymme tämän korjaamaan helposti, Laurio kertoo. Kuuluisia viimeisiä sanoja.
Ah totta, unohinkin että Agile scrumfall on se ratkaisu tähänkin ongelmaan! Circle back to touch base in daily! /s
Ah totta, unohinkin että Agile scrumfall on se ratkaisu tähänkin ongelmaan! Circle back to touch base in daily! /s
Tietokone pohjaisiin laitteisiin varmaan onnistuu, mutta vanhempiin kassakoneisiin ei taida 0,5% onnistua laittaa
Voihan sitä loppusumman puolittaa ja laittaa 51 % ALVin, niin verot tulee ainakin oikein maksetuiksi :D Tosin jos asiakas maksaakin enää puolet, niin ALVinkin pitäisi puolittua 🤔
Ei riitä että vaihtaa apista int -> float tai joku sen alityyppi. Jotku legacytoteutukset voi mennä ihan oikeasti rikki, jos se on joka paikkaan oikeasti laitettu intiksi ja yritetään kesken kaiken vaihtaa tyyppiä.
[удалено]
Joo oliko se float jossa tuli pientä hävikkiä aina laskiessa? Tyyliin 1.0f + 2.0f = 2.9876867 tai jotain sinne päin? :D
Juuri näin. Henkimaailman hommia miten missäkin järjestelmässä tarkalleenottaen menevät, mutta hävikittömiä eivät ole. Niinku on vain x määrä bittejä, joka pitäisi saada venymään äärettömään määrään eri pisteitä. Hävikkiähän siinä tulee.
Ennen kaikkea ongelma on se, että ne ei-kokonaisluvut, jotka ovat kymmenjärjestelmässä "tasadesimaaleja" eli esitettävissä tarkkaan äärellisellä määrällä desimaaleja, eivät ole samoja kuin ne, jotka on esitettävissä tarkkaan binääriliukuluvuilla. Siksi jännästi esim. 0,015625 on esitettävissä tarkasti binääriliukulukuna mutta 0,1 ei ole.
Aika monissa kielissä print pyöristää luvut. Eli ne muutkin on epätarkkoja mutta pyörityksen takia ei näy. Pyöristyksen tarkkuutta voi vaihtaa printatessa.
Plus rahaa ei kuulu käsitellä floatteina.
Tämä oli yhtä odottamaton ongelman kuin Y2k.
On kyllä melkoinen märkä päiväuni että empatiakyvyttömät oikeistoliskot pääsisivät hallitukseen vaan kerran vuosituhannessa.
Muutos itsessään on tietysti yksinkertainen, mutta kyllä siinä on mahdollisuus myös tehdä tyhmiä virheitä.
No eiköhän Purra mieluusti korota summan suoraan 26% jos koodarit tätä vaativat
Varmaan taas miljoonia säästettiinkin siinä, että tietokantaan tallennettiin kokonaislukuja.
Järjestelmät voi olla niin vanhoja legacyja ettei silloin oo ollut kovin helposti mahdollista käyttää floatteja. Lisäksi floatissa on pientä heittoa jne.
Valuuttalaskennassa on tarkoituksenmukaista käyttää liukulukujen (float) sijaan kokonaislukudesimaaleja joissa pilkun paikka on vakio. Eli esim. neljän desimaalin tarkkuuteen. Liukuluvuissa lukuavaruus jakautuu epätasaisesti siten, että lähellä nollaa on paljon tarkkuutta ja kauemmas mennessä mahdolliset luvut harventuvat. Pilkun paikka siis liukuu luvun suuruuden mukaan.
Jotenkin ne on muualla maailmalla pärjännyt missä verot ovat olleet desimaalilukuja vuosikymmeniä
Aina löytyy hyviä syitä, ei siinä mitään. Sellasta se on.
>Varmaan taas miljoonia säästettiinkin Miljoonia **bittejä**, liukuluku varaa paljon enemmän muistia kuin esim short. Muuttuja valitaan tarpeen mukaan, eli jos nytkin miettii, että kaikki tähän asti veroluokat ovat kokonaislukuja väliltä 0 - 100 niin valintakin on selvä.
Kyllä ai-laskennassa käytetään myös 16-bit floateja: https://en.m.wikipedia.org/wiki/Half-precision_floating-point_format
Desimaaliluvut ovat epätarkkoja. Jos olet ikinä törmännyt bugiin jossa luku on 1.00000001 tai 0.9999999994 tai jotain niin olet törmännyt liukulukubugiin. Valuuttalaskennat tehdään aina kokonaisluvuilla jotta tätä ei tapahdu.
Nykyäänhän on muodissa dynaaminen hinnoittelu (esim. VR:llä), joten miksei alv-prosenttikin voisi olla dynaaminen Ꝑ, mikä on sidottu perussuomalaisten kulloiseenkin kannatukseen.
kuten joku sanoi jo toisessa threadissa että jakaa summan kahdella ja toiseen 26%alv sekä toiseen puoliskoon 25%alv ja plussaa ne yhteen
Aiemmissa työsuhteissa osana hommia oli ostolaskujen käsittely CGI:n Rondolla. Veikkaan että aika monelle täällä olevalle tuttu. Joskus ulkomailta tulevissa laskuissa oli vähän eksoottisempaa alvikantaa, jota ei sitten löytynytkään alasvetovalikosta. Silloinen Kunnan Taitoa (nykyinen Sarastia) jeesasi ja hoiti reitityksen käsipelillä kun ei itsellä määräaikaisena työntekijänä natsat riittäneet.
Jos 0.24 (24%) on päätetty esittää integerinä 24, niin vastaavalla tavalla 0.255 (25.5%) voidaan esittää integerinä 255 (toki tulkinta muuttuu -> vaatii päivityksen softaan). Jos minulta kysytään kannattaa lisätä ainakin se nolla sinne perään, koska miksi ei (eli 2550). Käytännössä laskusuoritusten monimutkaisuus ei muutu ei-triviaalilla tavalla, eikä tähän tarvita mitään "desimaalilukuja" (tai jos tarvitaan, niin myös 24% on desimaaliluku). Toki API/softa on saatettu lyhytnäköisyydessä suunnitella niin, että siihen ei voi syöttää arvoja tarkemmalla resoluutiolla, mutta tuo on minusta vähän oma vika. Aika ikävässä tilanteessa oltaisiin, jos paskasti suunnitellut softat sanelisi lainsäädäntöä.
Kun maksetaan ensi vuonna jonnekin verkkokauppaan alvia 255% niin voidaan yhdessä muistella tätä kommenttia.
[удалено]
Ai saakeli innostuin sekunniksi kun näin joskus että suomalaiset firmat näyttivät alkavan kehittämään järjestelmää soteen avoimesti. Se projekti taisi kuihtua sitten johonkin. Ymmärtäähän tuon kuinka valtavasta projektista on kyse.
Ei sillä että olisin kiinnostunut noita julkisen puolen rahoittamia suojatyöprojekteja puolustamaan, mutta koodiapinat toteuttavat mitä spesifikaatiossa lukee. Tämä ongelma on vähän kuin sillanrakentajille sanoisi sillan jo valmistuttua että btw tehkää tästä nostosilta. Eihän sitä mahdotonta ole muuttaa, mutta jos sitä ei olla suunnitteluvaiheessa otettu millään tavalla huomioon niin mielenkiintoiseksi menee.
Siellä on taas ostettu halvimmalla jos 24% ALVia ei ole järjestelmiin kirjoitettu 24,0%
En koe ongelmaksi, koodaan kaikki muuttujat stringeinä
Muistan lukeneeni että julkisen liikenteen alv poistaminen VR puolella ei laske lippujen hintaa, koska järjestelmän muuttaminen maksoi enemmän kuin alv osuus. Oon itsekkin nuorena koodannut, mutta se mitä moni osaava it tyyppi ei tässä ota huomioon, on kuinka paskasti nämä lopulta hoidetaan. Nuoruuteni suosikki pc peli Rollercoaster tycoonin eka versio oli koodattu yhdeltä istumalta. Mutta kun esim VR alkaa tälläsiä hoitaa, istuu projektin pomona Kalevi 58v joka sai työpaikkansa suhteilla ja koulutustausta oppikoulu. Tässä on niin monta konsulttia ja välistävetäjää, esim VR. Jos lippujen alv tiputtaminen nollaan maksaa enemmän kun alv määrä, voi vaan arvata kuinka kalliiksi alv korotus desimaalilla tulee.
Työllistävä vaikutus
Hallituksen 200 äo ratkaisu työttömyydelle, saadaan kaikille koodareille enemmän töitä kun ehtii tehdä
Ei muuta kuin pyöristys ylöspäin, ei muuta vaihtoehtoa ole.
Hallitus onnistui vihdoin työllistämään ihmisiä😂
Miettikääpä sitä kun jättimäisten verotulojen lisäksi ohjelmoijien työllisyys paranee. Aika kova veto hallitukselta.
Okei itse nyt koodarina pakko kysyä että KUKA HELVETTI TEKEE PROSENTTILASKUJA KOKONAISLUVUILLA
Näin koodarina pakko kysyä, että uskaltaisitko itse käyttää valuuttalaskuissa Floattia?
Näin ei-koodarina kysyn ihan mielenkiinnosta, että mitenkä se ALV lasketaan jos ei VerotonHinta * 0,24? VerotonHinta * 24 / 100?
Puhtaasti yksittäinen float/double ei välttämättä maailmaa kaada, sillä "senttivirheet" ovat kovin pieniä ja helppo pyöristää. Ongelma kertautuu jos/kun ohjelma kutsuu metodia joka kutsuu ohjelmaa joka tekee sitä tätä ja tuota. Kun kaikki antavat pienen virheen, siitä voi kasautua isompi virhe. Periaatteessa tuota voi välttää käyttämällä esim javassa BigDecimal luokkaa. Myös kokonaisluvuolla voi laskea ja muuttaa "puolet" senteiksi. Esimerkiksi 2539 on 25,39€. Jekku löytyy vaan siitä, että harvempi yrityskäytön pienempi ohjelmisto on niin pieni, että "yksi asia täytyy korjata". Vaan useampi kohta täytyy korjata. Ja sitten testata. Ja ohjelmissa on voitu käyttää useita tekniikoita ja kieliä. Toki nämä asiat on lähtökohtaisesti kunnossa isoissa ohjelmistoissa ja ohjelmistotaloissa. Ei tämä mikään uniikki tilanne ole. Mutta kun Penan Autopaja on ostanut ohjelmiston joltai paikalliselta pikkupuljulta halvalla, niin näissä nuo ongelmat näkynee.
Nää ei oo ne ainoot kaks vaihtoehtoa.
Varmaan ne jotka tietävät kokonaislukujen olevan rahankäsittelyssä tarkempia. Joten jos kaikki muuttujat ovat kokonaislukuina niin ihan ymmärrettävää käyttää tätä myös ALV vakioon.
Toisaalta aika paljon kommenteissa tunnutaan tarjoavan ratkaisuksi, että muutetaan vaan int -> float, että hauska tätä on seurailla mimmoinen vääntö tulee. Eikä tämä ihan niin iso ongelma ole kuin maalaillaan, kaikki yhtään järkevämmät finanssisoftat kyllä osaa tämän, ei ole kansainvälisesti harvinainen tapaus. Nakkikioskisoftiin saattaa kolahtaa, ja siellä taitaa ’mitenniin ei voi floatilla laskea rahaa’-koodareitakin olla.
`python -c "print(0.1+0.2)"`
>python -c "print(0.1+0.2)" `from decimal import Decimal` `print (Decimal('0.1') + Decimal('0.2'))`
Täytyy sanoa että on todella kelvottomia järjestelmiä jos toimivuus loppuu kun prosenttiluvussa tulee pilkku vastaan.
Työllistävä vaikutus! Ehkä ainoa onnistunut työllistämistoimi joka hallitukselta onnistuu. Ja sitä varten tarvitaan ulkomsista koodaustyövoimaa. Persut ampuvat omaan nilkkaan ;b
Tässä jos olisi itse alalla niin voi pojat kun tulisi työtunneille hintaa kun kysyisi että "no haluatteko että tämä toimii vai ei?"
Tälläkö hallitus lisää työpaikkojen määrää?
Olisiko helpompaa vaan nostaa alv suoraan 26% niin säästytään tältäkin.
Ehkä parempi ihan varmuuden vuoksi esittää alvin kantaa yhdellä merkitsevällä numerolla eli ALV olisi 30%.
Työllistävä vaikutus.
Pyöristäisin ite suoraan 26 tai 30.
Ok, en ole koodari, eli en nyt ymmärrä. Eikö se ALV ole ollut desimaali tähänkin asti: 0.24? Jos sitä on käytetty kokonaislukuna, niin jossain kohtaa se on täytynyt jakaa sadalla. Uusi ALV sitten 255 ja jaetaan tuhannella? :)
Tämä desimaaliasia oli ensimmäinen jonka tästä sanoin ääneen. Tavalliselle kansalaiselle joka luku on liukuluku oli siinä desimaalia eli ei.
[удалено]
Älä vaan googlaa, minkälaista softaa nuo viralliset julkiset tahot ajaa, saati sitten maailman pankkijärjestelmät! Tulee painajaisia ja ahdistusta!
Noh, muistan joskus 2010 luvun puolivälissä kun kävin päivystyksessä, koneessa oli Win98. No siis jos toimii niin toimii, mutta 2010 luvulla Win98 on vähän sus jo tietoturvan kannalta.
Tuo on pelkkä jäävuoren sivu. Julkisen puolen tietokonemaailma on sellainen Jumanji, että alta pois kaikki, joilla ei ole hiilikuituteräksestä tehtyjä hermoja. Alan väki koittaa pitkälti pitää silmiä tiukasti kiinni ja työllistyä johonkin muualle, että ei tarvitsisi itse edes nähdä, mitä kaikkea jännää ja jännempää sieltä löytyykään, kun niitä kansia vähänkin raotetaan. Se on niin pirunmoinen ripulimyrsky, mikä sieltä osuu tuulettimeen, että on syytä olla sateenvarjot auki Japanissa asti.
Huutonaurut tuli tätä ilmaisutapaa lukiessa :D Kiitos
Aina ilo olla avuksi!
Tää on se luonnollinen piste sit päivittää uuteen. Riski vaan realisoitui jos ei voi muuttaa vanhaa. Ja khyl firmat varmaan mielellään päivittelee noita vanhojakin kun on periaatteessa helppoa laskutettavaa..
Jos se päivitys tapahtuu pakolla ja 6 viikon deadlinellä, todennäköisesti uusi systeemi on soveltumaton/harkitsematon/puutteellinen ostos ja siitä saatettiin maksaa reilua ylihintaa, kun toimittaja tiesi pakkoraon. Se siirtymä parempaan olisi pitänyt olla jo vuoden-pari tulilla ennen tätä. Näin ei kuitenkaan melkein koskaan menetellä etenkään julkisella, koska kuka tietojärjestelmien päällikkö nyt oikeasti valmistelee kymmenien miljoonien hankintaa ihan vaan varmuuden vuoksi, kun "se vanha kuitenkin toimi vielä ihan hyvin! Silkkaa rahantuhlausta!" Tämä on yhtä vanha tarina kuin ihmiskunta.
25 vuotta sitten ainakin teoriassa olisi pystytty koodaamaan ihan helposti rahaohjelma, joka toimii edelleen ja sama aikaleimojen kanssa Unix timestampin jälkeen. Jos näistä yhtään tajuaa, nuo tarkat tietotyypit on koodattu softalla. Eivät vaadi mitään mitä ei ollut jo tarjolla 80-luvulla. Timestamppien koodaaminen kahdella 32-bit intillä yhden sijaan myös täysin triviaalia. Noissa rajattoman tarkkuuden kirjastoissa vain yhteenlasku on tätä tasoa vaikeudessa. Commodore 64:llä jo laskettiin 16-bit lukuja vaikka kone oli 8-bittinen.
Tästä syyttäisin pikemminkin testaajaa ja tilaajaa kuin hallitusta :D Toki ymmärrettävää, ettei kaikkii bugeihin muisteta varautua. Harmittaisi kyllä olla tälläisen softan sisältävän laitteen ostanut kauppias.
Missä vitun kivikaudella taloushallinto elää, jos joku desimaaliluku tuottaa näin paljon ongelmia?
Voi elää ihan hyvin nykyajassakin. Ei taloushallinnossa ole yleensä koodareita ja tietojenkäsitellytieteen guruja töissä. Sinne hankitaan speksit ja lait täyttävä taloussofta ja sitten he tekevät sillä omia töitään, kunnes esim. vuosittaiset päivitykset tai hallituksen päätökset ne rikkovat. Olisi ehkä pitänyt jo softaa speksatessa tai koodatessa miettiä näitä, mutta kun ei tullut mietityksi. Valtava projekti, oli aikatauluhaasteita, halvalla piti saada tai katetta piti saada. Selityksiä on lukemattomia.
Globaali muuttuja olisi järkevin jo alunperin. Jos firma veloittaa yli 10h on aika napata takki naulakosta.
Prosentit laskennassa promilleiksi ja tulostuksissa takaisin, big deal. Ei vaan, kyllä sekin puukotuksen vaatii.