Digitalisaatio - hyvät ja huonot puolet

[Hyrava]

Hah.

Onko tässä REST APIn pakottamisessa motiivina se, että protokollan pitää olla sellainen, että sitä pystyy käpistelemään JavaScriptin fetch-APIlla? Ja kun mitään muuta kuin sitä JavaScriptiä ei osata eikä viitsitä opetella, niin halutaan sitten pakottaa kaikki muutkin käyttämään sitä.

Ihan millä tahansa konekielelle käännettävällä kielellä tuollaisen tekeminen on nimittäin aika monta tuhatta riviä koodia, jos ajatellaan, että yhdelle riville tulee yksi lauseke. JavaScript ja muut skriptikielet ovat tietysti asia erikseen, mutta niillä ei kovin tehokkaaseen lopputulokseen ikinä päästäkään.

JavaScript on vielä siitäkin hyvin huono kieli, että mitään ohjelmoijan itse päättämää sisältöä ei saa sokettien yli menemään, vaan ainoat mahdollisuudet ovat käyttää fetch-APIn kautta HTTP-protokollan tarjoamia metodeja ja sitten webSocket-apin kautta käyttää websoketteja. Tuki uusille jutuille vaihtelee selaimittain.

Ei niitä tuhansia rivejä koodia itse tarvitse kirjoittaa kun monissa kielissä on valmiit kirjastot REST API:n käsittelyyn. Viimeksi tänä aamuna toteutin yhden REST API -testaus-skriptin pythonilla alle vartissa. Varmaan joku kymmenkunta riviä kaikkineen ja ajastakin meni suurempi osa API:n dokumentaation lukemiseen kuin itse koodaamiseen. Tuo REST API vaan on niin helppokäyttöinen ja yleisesti käytössä.

Yleensä aina vituttaa jos joutuu jotain random ASCII- tai binääriprotokollaa käyttämään kun kaiken joutuu tekemään itse kun valmiita kirjastoja ei ole olemassa.

 

[lizard]

Esimerkiksi kotiverkossa https'n käyttäminen on kuitenkin vähän ongelmallista, ei niinkään ohjelmoijan vaan konfiguraation kannalta: TLS'n käyttämistä varten palvelimena toimivan laitteen pitää tarjota sertifikaatti, joka on kirjoitettu tietylle hostnamelle. Kotiverkossa taas hostnamejen konffit ovat yleensä mitä sattuu. Tavallisesti myname.local resolvoituu, mutta niin DHCP kuin DNS palvelimien konffit voivat olla vähän mitä sattuu. Eli se palvelin ei oikein voi olla varma, millä nimellä se näkyy verkossa. Ja jonkun uuden certin generoiminen vaikkapa Let's Encrypt'llä taas vaatii jotain port forwardeja reitittimeen. Ollaan valitettavan kaukana siitä, että Matti Meikäläinen voisi kirjoittaa selaimeen https://purkki.local ja homma toimisi luotettavasti kuin se junan vessa.

Jonkun custom tekstipohjaisen protokollan käyttö ei paranna tilannetta mitenkään. Pikemminkin hankaloittaa entisestään tilanteessa, joissa mukana on jonkinlainen palomuuri.

 

[JCSH]

Onko tässä REST APIn pakottamisessa motiivina se, että protokollan pitää olla sellainen, että sitä pystyy käpistelemään JavaScriptin fetch-APIlla? Ja kun mitään muuta kuin sitä JavaScriptiä ei osata eikä viitsitä opetella, niin halutaan sitten pakottaa kaikki muutkin käyttämään sitä.

Oli käytössä sitten JavaScript, C++, Java/Kotlin, Python tai vaikkapa Swift, niin REST API:n käytölle HTTP(S):n yli löytyy valmiit kirjastot, joilla tuo hoituu parilla rivillä koodia.
Katsos kun ammattilaisilla koodareilla ei ole aikaa tai kiinnostusta lähteä koodaamaan sitä omaa HTTPS:n hanskausta nollasta, kerta pitää keskittyä oikeasti tuottaviin töihin.

 

[Sompi]

Ei niitä tuhansia rivejä koodia itse tarvitse kirjoittaa kun monissa kielissä on valmiit kirjastot REST API:n käsittelyyn. Viimeksi tänä aamuna toteutin yhden REST API -testaus-skriptin pythonilla alle vartissa. Varmaan joku kymmenkunta riviä kaikkineen ja ajastakin meni suurempi osa API:n dokumentaation lukemiseen kuin itse koodaamiseen. Tuo REST API vaan on niin helppokäyttöinen ja yleisesti käytössä.

Eipä yllättänyt, että joku laittaa esimerkiksi jotain Pythonilla tehtyä.

Yleensä aina vituttaa jos joutuu jotain random ASCII- tai binääriprotokollaa käyttämään kun kaiken joutuu tekemään itse kun valmiita kirjastoja ei ole olemassa.

Eihän tuollaisessa ajattelussa ole mitään järkeä. Se koko REST API on vain yksi väliin tuleva protokolla lisää. Jos se jätetään pois, niin tehtävää on vähemmän. Jos se REST API taas on siinä välissä, niin saatat joutua kirjoittamaan itse kymmeniätuhansia koodilausekkeita sen takia. JavaScriptissä ja Pythonissa tietysti REST APIn käsittelyyn tarvittavat jutut löytyvät kielen omista standardifunktioista valmiina, mutta useimmissa kielissä niin ei ole.

Sinä et siis tehnyt REST API-toteutusta, vaan sinä toteutit sen protokollan, joka sen REST APIn hyötykuormana on.

Jos ajatellaan protokollapinon tasolla, niin mikä tahansa protokolla, joka voi toimia REST APIn hyötykuormana, voi toimia myös suoraan TCP:n hyötykuormana. TCP:tä ei tarvitse toteuttaa ohjelmassa, koska se tapahtuu käyttöjärjestelmäytimen tasolla. REST API taas ei ole tuettu käyttöjärjestelmäytimessä, joten sen pitää olla toteutettu ohjelmassa. Ohjelmabinääri kasvaa sen takia koko ja kaikki tulee kompleksisemmaksi. Tietoturva-aukkojenkin todennäköisyys kasvaa.

Ihan vaikkapa joku irkkaaminen on aivan hyvin mahdollista REST API:n yli protokollapinolla IRC/REST/TCP/IP, mutta "jostain kumman syystä" kukaan ei sitä RESTiä tuohon väliin tunge. Se "joku syy" saattaisi olla vaikkapa se, että se olisi vain turhaa painolastia.

Samaten ohjelmoitsijan näkökulmasta REST APIn käyttäminen ei ikinä missään tapauksessa (paitsi lelukieli JavaScriptin tapauksessa jolla normaaleja soketteja ei edes pysty käsittelemään kielen rajallisuuden takia) vähennä ohjelmoijan työmäärää. Sen sijaan se kyllä voi lisätä sitä moninkertaisesti, jos käytetystä ohjelmointikielestä ei löydy valmista toteutusta REST APIa varten. Sen sijaan raaka TCP-soketti on helppo käpistellä vaikka assemblyllä, koska nykyaikaiset käyttöjärjestelmät tarjoavat sitä varten valmiit palvelut.

REST APIn pudottaminen pois välistä vähentää asiaan kuluvaa ohjelmoijan työaikaa.

 

[JCSH]

Eipä yllättänyt, että joku laittaa esimerkiksi jotain Pythonilla tehtyä.


Eihän tuollaisessa ajattelussa ole mitään järkeä. Se koko REST API on vain yksi väliin tuleva protokolla lisää. Jos se jätetään pois, niin tehtävää on vähemmän. Jos se REST API taas on siinä välissä, niin saatat joutua kirjoittamaan itse kymmeniätuhansia koodilausekkeita sen takia. JavaScriptissä ja Pythonissa tietysti REST APIn käsittelyyn tarvittavat jutut löytyvät kielen omista standardifunktioista valmiina, mutta useimmissa kielissä niin ei ole.

Sinä et siis tehnyt REST API-toteutusta, vaan sinä toteutit sen protokollan, joka sen REST APIn hyötykuormana on.

Jos ajatellaan protokollapinon tasolla, niin mikä tahansa protokolla, joka voi toimia REST APIn hyötykuormana, voi toimia myös suoraan TCP:n hyötykuormana. TCP:tä ei tarvitse toteuttaa ohjelmassa, koska se tapahtuu käyttöjärjestelmäytimen tasolla. REST API taas ei ole tuettu käyttöjärjestelmäytimessä, joten sen pitää olla toteutettu ohjelmassa. Ohjelmabinääri kasvaa sen takia koko ja kaikki tulee kompleksisemmaksi. Tietoturva-aukkojenkin todennäköisyys kasvaa.

Ihan vaikkapa joku irkkaaminen on aivan hyvin mahdollista REST API:n yli protokollapinolla IRC/REST/TCP/IP, mutta "jostain kumman syystä" kukaan ei sitä RESTiä tuohon väliin tunge. Se "joku syy" saattaisi olla vaikkapa se, että se olisi vain turhaa painolastia.

Samaten ohjelmoitsijan näkökulmasta REST APIn käyttäminen ei ikinä missään tapauksessa (paitsi lelukieli JavaScriptin tapauksessa jolla normaaleja soketteja ei edes pysty käsittelemään kielen rajallisuuden takia) vähennä ohjelmoijan työmäärää. Sen sijaan se kyllä voi lisätä sitä moninkertaisesti, jos käytetystä ohjelmointikielestä ei löydy valmista toteutusta REST APIa varten. Sen sijaan raaka TCP-soketti on helppo käpistellä vaikka assemblyllä, koska nykyaikaiset käyttöjärjestelmät tarjoavat sitä varten valmiit palvelut.

REST APIn pudottaminen pois välistä vähentää asiaan kuluvaa ohjelmoijan työaikaa.

Sä nyt selvästi elät puhtaasti jossain harrastelija maailmassa, josta sulla ei ole mitään kosketuspintaa oikeaan ammattilaiseen softatyöhön.
Jos joku lähtee koodaamaan clienttia, joka käyttää tuollaista kotiautomaation julkista rajapintaa, niin se tullaan käytännössä aina kirjoittamaan sellaisilla kielillä ja frameworkeillä, että tuo HTTP(S) REST API:n käyttöön löytyy kaikki valmiit työkalut. Jolloin se on todellakin vain muutama rivi koodia hoitaa tuon rajapinnan käyttö.

 

[Sompi]

Sä nyt selvästi elät puhtaasti jossain harrastelija maailmassa, josta sulla ei ole mitään kosketuspintaa oikeaan ammattilaiseen softatyöhön.
Jos joku lähtee koodaamaan clienttia, joka käyttää tuollaista kotiautomaation julkista rajapintaa, niin se tullaan käytännössä aina kirjoittamaan sellaisilla kielillä ja frameworkeillä, että tuo HTTP(S) REST API:n käyttöön löytyy kaikki valmiit työkalut. Jolloin se on todellakin vain muutama rivi koodia hoitaa tuon rajapinnan käyttö.

Sinulla, kuten monella muullakin täällä, näyttää olevan jokin pakkomielle kaikenlaisen harrastelun vaikeuttamiseen.

Edelleenkään se REST API ei vähennä ohjelmoijan työmäärää, vaan lisää sitä. Kaikki, mikä toteutetaan REST APIn päällä, voidaan toteuttaa myös paljon kevyemmin myös suoraan TCP:n päällä.

Sinä haluat jostain syystä pakottaa kaikki käyttämään ohjelmointikieliä, joista löytyy REST APIn käyttöön tarkoitetut funktiot valmiina. Tuo halu pakottaa kaikenlaista näyttää olevan melko toistuva kaava tässä keskustelussa.

 

[lizard]

Edelleenkään se REST API ei vähennä ohjelmoijan työmäärää, vaan lisää sitä. Kaikki, mikä toteutetaan REST APIn päällä, voidaan toteuttaa myös paljon kevyemmin myös suoraan TCP:n päällä.

Olet väärässä. Jos kirjoitat custom protokollan, sinun pitää joko:
1) Käyttää olemassaolevan protokollan porttia
2) Ottaa käyttöön uusi porttinumero

Noh, molemmat näistä ovat erittäin huonoja vaihtoehtoja. Väliin osuvat palomuurit tai muut liikennettä analysoivat purkit voivat blokata yhteyden tuntemattoman portin tai tuntemattoman payloadin takia. Yhdenkin ongelman selvittely räjäyttää homman näpeillesi, etkä välttämättä pysty korjaamaan sitä muuta kuin muuttamalla toteutuksen käyttämään yleisiä standardeja. Tästä samasta syystä likimain kaikki verkkopavelut käyttävät http(s)'ää, vaikka ne eivät selaimelle esitettävää sisältöä käyttäisikään.

 

[Sompi]

Olet väärässä. Jos kirjoitat custom protokollan, sinun pitää joko:
1) Käyttää olemassaolevan protokollan porttia
2) Ottaa käyttöön uusi porttinumero

Ei tuossa ole mitään ihmeellistä. Ykkösvaihtoehto ei ole ongelma, koska sitä kyseistä olemassaolevaa protokollaa ei kuitenkaan hostata siinä etähallittavassa laitteessa. Myöskään uuden porttinumeron käyttöönotossa ei ole mitään ongelmaa. Käytettäväksi ne porttinumerot on tehty.

Noh, molemmat näistä ovat erittäin huonoja vaihtoehtoja. Väliin osuvat palomuurit tai muut liikennettä analysoivat purkit voivat blokata yhteyden tuntemattoman portin tai tuntemattoman payloadin takia.

Noin voi käydä myös, jos sen REST APIn payloadina on jotain "tuntematonta". Ratkaisu on olla käyttämättä niin huonoja palomuureja. TCP:n kaikki portit on kuitenkin tarkoitettu käytettäväksi ja internetin käyttäjän olisi tarkoitus päättää mitä siitä menee läpi, eikä reititinvalmistajan.

Tästä samasta syystä likimain kaikki verkkopavelut käyttävät http(s)'ää, vaikka ne eivät selaimelle esitettävää sisältöä käyttäisikään.

Syy taitaa olla pikemminkin se, että suuri osa ohjelmoijista osaa nykyään kirjoittaa vain JavaScriptiä, jonka kanssa muu ei oikein ole mahdollista.

 

[Sompi]

Tästä tulee mieleen sellainen kuvio, että ensin joku reititinvalmistajalle töissä olevista pöhisijöistä koostuva komitea jonkun täynnä hienoja pöhinäominaisuuksia (joista suurin osa ei edes lopputuotteessa toimi kunnolla) olevan reitittimen toimintoja suunnitellessaan päättää, että laitetaanpa reitittimeen SPI-palomuuri, jota ei saa mitenkään pois päältä, ja joka blokkaa kaikenlaisen "tuntemattoman" liikenteen. Sitten kun huomataan, että se SPI-palomuuri estääkin osan ihan normaalista internetin käytöstä, niin toinen samanlaisista pöhisijöistä koostuva IoT-laitteita tekevän firman komitea päättääkin toteuttaa IoT-laitteen käyttämän protokollan olemassa olevien SPI-palomuurin "hyväksymien" protokollien päällä, jolloin kaikessa päädytään käyttämään raskasta REST-APIa HTTP:n yli. Tätä sitten hypetetään kuin kyse olisi jostain uudesta ja mullistavasta innovaatiosta, vaikka oikeasti vain luotiin keinotekoinen ongelma ja siihen ratkaisu, jonka myötä lopputilanne on paljon huonompi kuin ongelman olemassaoloa edeltänyt tilanne.

 

[oongee]

Edelleenkin se HTTP on yksi monista telnet-protokollista,

[..]

Täällä tuntuu hyvin monella olevan ihan perusasiat hukassa.

Tämä usein toistamasi väite siitä, että HTTP ja jotkut muut protokollat ovat "telnet-protokollia" on hyvin kummallinen. Se osoittaa lähinnä sen, että et tiedä itse, mistä puhut, vaikka väität asioiden olevan muilla hukassa.

Telnet ei todellakaan ole mikään simppelein mahdollinen protokolla, vaan siihen sisältyy kaikenlaista historiallista painolastia, jossa client ja serveri voivat esim. neuvotella keskenään yhteydellä käytettävistä käytänteistä. Esim. client-päässä syötettyjen merkkien kaiutus takaisin käyttäjälle voi neuvottelun lopputuloksesta riippuen olla clientin tai serverin tehtävä.

Et ole selvästikään koskaan implementoinut telnet-protokollaa kun et asiaa tunne.

Väität HTTP-protokollaa vaikeaksi toteuttaa, koska sen määrittely on monisivuinen. Todellisuudessa simppeli täysin standardin mukainen HTTP-serveri on varsin helppo toteuttaa kun vaan jättää ei-pakolliset osat toteuttamatta.

Alla verrokiksi luettelo telnet-protokollan määrittelyistä. Suosittelen tutustumaan, ennen kuin jatkat muiden protokollien kutsumista telnet-protokolliksi tai käytät telnettiä esimerkkinä mahdollisimman simppelistä protokollasta.

• RFC 854, Telnet Protocol Specification
• RFC 855, Telnet Option Specifications
• RFC 856, Telnet Binary Transmission
• RFC 857, Telnet Echo Option
• RFC 858, Telnet Suppress Go Ahead Option
• RFC 859, Telnet Status Option
• RFC 860, Telnet Timing Mark Option
• RFC 861, Telnet Extended Options: List Option
• RFC 885, Telnet End of Record Option
• RFC 1073, Telnet Window Size Option
• RFC 1079, Telnet Terminal Speed Option
• RFC 1091, Telnet Terminal-Type Option
• RFC 1096, Telnet X Display Location Option
• RFC 1123, Requirements for Internet Hosts - Application and Support
• RFC 1184, Telnet Linemode Option
• RFC 1372, Telnet Remote Flow Control Option
• RFC 1572, Telnet Environment Option
• RFC 2941, Telnet Authentication Option
• RFC 2942, Telnet Authentication: Kerberos Version 5
• RFC 2943, TELNET Authentication Using DSA
• RFC 2944, Telnet Authentication: SRP
• RFC 2946, Telnet Data Encryption Option
• RFC 4248, The telnet URI Scheme
• RFC 1143, The Q Method of Implementing TELNET Option Negotiation
• RFC 1571, Telnet Environment Option Interoperability Issues
• RFC 1041, Telnet 3270 Regime Option
• RFC 2355, TN3270 Enhancements
• RFC 1205, 5250 Telnet Interface
• RFC 2217, Telnet Com Port Control Option
• RFC 4777, IBM's iSeries Telnet Enhancements

 

[Sompi]

Tässä yhteydessä telnet-protokollalla tietysti tarkoitetaan sellaisia ASCII-protokollia, joita pystyy käyttämään myös tavallisella telnet-asiakasohjelmalla. Kyllähän se nyt pitäisi keskustelun kontekstista käydä selväksi jokaiselle asian ymmärtävälle.

Kyllä minä olen muutamankin HTTP-toteutuksen tehnyt (sekä palvelin- että asiakastoteutuksia) ja myös yhden varsin vajavaisen ihan varsinaisen telnet-protokollan toteutuksen.

 

[pulatunnus]

Tästä tulee mieleen sellainen kuvio, että ensin joku reititinvalmistajalle töissä olevista pöhisijöistä koostuva komitea jonkun täynnä hienoja pöhinäominaisuuksia (joista suurin osa ei edes lopputuotteessa toimi kunnolla) olevan reitittimen toimintoja suunnitellessaan päättää, että laitetaanpa reitittimeen SPI-palomuuri, jota ei saa mitenkään pois päältä, ja joka blokkaa kaikenlaisen "tuntemattoman" liikenteen. Sitten kun huomataan, että se SPI-palomuuri estääkin osan ihan normaalista internetin käytöstä, niin toinen samanlaisista pöhisijöistä koostuva IoT-laitteita tekevän firman komitea päättääkin toteuttaa IoT-laitteen käyttämän protokollan olemassa olevien SPI-palomuurin "hyväksymien" protokollien päällä, jolloin kaikessa päädytään käyttämään raskasta REST-APIa HTTP:n yli. Tätä sitten hypetetään kuin kyse olisi jostain uudesta ja mullistavasta innovaatiosta, vaikka oikeasti vain luotiin keinotekoinen ongelma ja siihen ratkaisu, jonka myötä lopputilanne on paljon huonompi kuin ongelman olemassaoloa edeltänyt tilanne.

Jos tuosta siivoo täytesanat pois, niin pari tärkeää juttua. Palomuurireitinvalmistajat/palvelut pyrkii suodattaan haitta liikenteen ja oletuksena voi olla tiukka, sienestäjä linja, missä päästetään vain tunnetut turvalliset läpi.

Toinen, asioita kannattaa satandartisoida, ja niitä määritellessä huomioida kokoanisuus, skaalatuvuus jne. myös palomuuri palveluiden tarjoajat/kehittäjät/ylläpitäjät.

IoT puolella on protocolla tarjontaa ja yksittäisen idea ei ole olla ratkaisukaikkeen. Anturin, jonkin toimilaitteen tarpeet on eri kuin jonkin palvelun, keskittimen jne. Jos laite on nettiin yhteydessä, niin vaatimukset ihan eri, kuin se että se on jossain laite ethernetverkossa. Jos laite on yhteydessä nettiin, eli käytännössä jos siinä tuki netti protokollille, niin se pitää toimia ympäristössä mikä on vihamielinen, missä IP:t vaihtuu, missä reitit vaihtuu, missä osoitteen muutoksia, palomuureja tai sen kaltaisia, yhteys ei ole pysyvä, voi olla tarve minimoida liikenne, tai sitten ei.

Telnet protokolla on vanha, jostain syystä se ei ole pärjännyt kilpailussa. Tietenkin joku taisi kuvailla että HTTP on telnet protokolla, eli sillä ajatuksella toki edelleen vahvasti käytössä. tai no HTTPS.

Suomessa on kehitetty protokollia ja jos jotain yksinkertaista kuningas ajatusta joka vastaa tarpeisiin, niin jos edes vastaa harrastajien tarpeisiin niin ei muuta kuin julkaiseen. Jos niin yksinkertainen että se ei tarvi käyttää vanhoja koodi kirjastoja , niin sen voi toki toteuttaa ihan ilman vanhoja rasitteita. Isoinjuttuhan siinä on nyt ne ylemmänkerron asiat.

Jos tota lähdet miettiin, niin pririsoinnit, ja se että skaalattavissa laitteiden välisestä miljoonien, miljardien yhteyuksien toteutuksiin.

 

[Vaateri]

Tässä yhteydessä telnet-protokollalla tietysti tarkoitetaan sellaisia ASCII-protokollia, joita pystyy käyttämään myös tavallisella telnet-asiakasohjelmalla. Kyllähän se nyt pitäisi keskustelun kontekstista käydä selväksi jokaiselle asian ymmärtävälle.

Yleensä keskusteluissa käytetään yleisesti ja yhteisesti hyväksyttyä terminologiaa eikä itse keksittyjä ja huonosti määriteltyjä. Ellei sitten tarkoituksellisesti halua hämmentää.

 

[pulatunnus]

Tässä yhteydessä telnet-protokollalla tietysti tarkoitetaan sellaisia ASCII-protokollia, joita pystyy käyttämään myös tavallisella telnet-asiakasohjelmalla. Kyllähän se nyt pitäisi keskustelun kontekstista käydä selväksi jokaiselle asian ymmärtävälle.

Kyllä minä olen muutamankin HTTP-toteutuksen tehnyt (sekä palvelin- että asiakastoteutuksia) ja myös yhden varsin vajavaisen ihan varsinaisen telnet-protokollan toteutuksen.

ASCII-protokolla IoT mailmaan , jo ihan pelkän luettavan tekstin joutuu kodaan ASCII merkeisin ja takaisin.

 

[Kautium]

Toivottavasti aloittaja on varautunut toimimaan yksityisyrittäjänä, sillä noin jääräpäisellä, vanhoillisella ja teknologiavastaisella asenteella ei tarvitse pelätä palkatuksi tulemista ainakaan mihinkään IT-firmaan.

Itse asiassa on riski työnantajalle, jos asiakkaalle sattuu vahingossakaan paljastumaan, että firmassa on töissä henkilö, joka ilmeisesti ihan vakavissaan kirjoittaa tuollaista tuubaa mm. salauksen pois jättämisestä "kun ei sitä sisäverkossa tarvitse" ja siihen nämä muut telnet-protokollat ja harrastajien vaikeuttamiseksi suunnitellut salaliittoskenaariot päälle. Aprillipäivänä tämä ketju olisi ihan ok kamaa, mutta tällaisenaan vähän kylmää.

Ja ei, tässä ei ole kyse vihamielisestä suhtautumisesta henkilöön tai harrastuksiin.

 

[pulatunnus]

UDP:ssä on se ongelma, että paketit eivät välttämättä mene perille, eikä lähettäjä tiedä siitä mitään.

Kumpi on helpompi koodata, TCP pino, vai UDP, jos kaiken tekee itse, ja tarve varmistaa että data meni perille, niin ehkä ei kiinnosta meniko IP paketti perille, vaan yllemmällä tasolla perille meno, joten turhaa työtä säästyisi UDPllä.

IoT mailmassa ei välttämättä edes laite tasolla kiinnosta meneekö jokainen paketti perille, joten sen selvittelyn resurssit voi käyttää muuhun.

En nyt tässä esite että UDP olisi fiksuvalinta, mutta voisiko sillä saavuttaa jotain muitakin etuja, jos se kenttälaite vain tuuppaa paketti verkkoon, vs että siellä olisi jotain kaksisuuntaisia yhteyksiä (palveluita). Tai se kaksisuuntaisuus olis erillinen, jopa erillinen fyysinen portti, parametrointai varten.

 

[Sompi]

Toivottavasti aloittaja on varautunut toimimaan yksityisyrittäjänä, sillä noin jääräpäisellä, vanhoillisella ja teknologiavastaisella asenteella ei tarvitse pelätä palkatuksi tulemista ainakaan mihinkään IT-firmaan.

Melkoisia olkiukkoja taas. Se siis tekee minusta "teknologiavastaisen", että haluan tehdä asiat kunnolla ja niin, että ne toimivatkin oikeasti.

Itse asiassa on riski työnantajalle, jos asiakkaalle sattuu vahingossakaan paljastumaan, että firmassa on töissä henkilö, joka ilmeisesti ihan vakavissaan kirjoittaa tuollaista tuubaa mm. salauksen pois jättämisestä "kun ei sitä sisäverkossa tarvitse" ja siihen nämä muut telnet-protokollat ja harrastajien vaikeuttamiseksi suunnitellut salaliittoskenaariot päälle. Aprillipäivänä tämä ketju olisi ihan ok kamaa, mutta tällaisenaan vähän kylmää.

Haluan myös tehdä teknologian kehittämisestä kaikille mahdollista, minkä ei pitäisi olla mitenkään negatiivinen asia. Sinä vain omituisella rikkinäisellä logiikallasi väännät senkin tuolla tavalla huonoksi asiaksi.

 

[Kautium]

Melkoisia olkiukkoja taas. Se siis tekee minusta "teknologiavastaisen", että haluan tehdä asiat kunnolla ja niin, että ne toimivatkin oikeasti.

Olkiukko olisi jotain, jossa vääristelen sanomisiasi. Sitähän en ole tehnyt. Sinä nimenomaan olet itse moneen otteeseen tuonut täällä ilmi nuo asiat.

Et ole missään antanut olettaa, että haluaisit "tehdä asiat kunnolla", vaan nimenomaan juuri päinvastoin ideologian vuoksi ikivanhoihin menetelmiin nojautuen, joiden ongelmia sinulle on yritetty selostaa useiden muiden toimesta. Kirjoitustesi perusteella luulet osaavasi kaiken paremmin kuin muut, eikä siinä sinäänsä mitään, niin moni muukin on luullut hetkellisesti uran alkuvaiheessa, kunnes yleensä opiskelun ja kokemuksen myötä on alkanut ymmärtämään kuinka vähän loppujen lopuksi tiesikään.

Haluan myös tehdä teknologian kehittämisestä kaikille mahdollista, minkä ei pitäisi olla mitenkään negatiivinen asia. Sinä vain omituisella rikkinäisellä logiikallasi väännät senkin tuolla tavalla huonoksi asiaksi.

Ei teknologian kehittämisen mahdollistaminen ole huono asia, enkä ole sellaista väittänyt missään. Se vaan pitä tehdä oikeaoppisesti ja turvallisesti. Lisäksi sen ei pidä olla itseisarvo, johon kaikki yritykset pakotetaan.

 

[Sompi]

Et ole missään antanut olettaa, että haluaisit "tehdä asiat kunnolla",

Koko ajan olen nimenomaan kritisoinut toimimattomia toteutuksia.

vaan nimenomaan juuri päinvastoin ideologian vuoksi ikivanhoihin menetelmiin nojautuen ... Kirjoitustesi perusteella luulet osaavasi kaiken paremmin kuin muut

Tuo on taas sitä olkiukkoilua.

Ei teknologian kehittämisen mahdollistaminen ole huono asia, enkä ole sellaista väittänyt missään. Se vaan pitä tehdä oikeaoppisesti ja turvallisesti. Lisäksi sen ei pidä olla itseisarvo, johon kaikki yritykset pakotetaan.

Minusta vaikuttaa siltä, että sinä määrittelet "oikeaoppisuuden" tarkoitushakuisesti niin, että se tekee omien toteutusten tekemisestä mahdollisimman hankalaa. Myöskään "turvallisuus" ei tarkoita mitään muuta kuin kompleksisuuden lisäämistä kaiken salaamalla (vaikka laite ei edes olisi ulkoverkossa) ja kaikkien pakottamista käyttämään sitä salausta. Käytännössähän nykyisellään noiden etähallittavien laitteiden etähallinta tapahtuu jollain reikäisellä kännykkä-äpillä laitevalmistajan pilven kautta, ja siinä on jo valtava määrä hyökkäyspinta-alaa, josta loppukäyttäjä ei edes pääse omalla toiminnallaan mitenkään eroon.

Asioiden yksinkertaistaminen ja hallinnan siirtäminen loppukäyttäjälle olisi jo valtava harppaus turvallisempaan suuntaan. Salauksen pitää tietysti olla myös mahdollista ja sitä on vähintäänkin suositeltavaa käyttää ulkoverkossa kulkevan datan suojaamiseksi. Salauksen pakottamisesta on kuitenkin vain haittaa.

Kun asiat pidetään riittävän yksinkertaisina, niin mistään "oikeaoppisuudesta" ei tarvitse edes puhua enää, koska riittävä yksinkertaisuus antaa paljon vapaammat kädet itse toteutuksen suhteen, kun noudatettavia sääntöjä ei paljoa ole.

 

[Kautium]

Koko ajan olen nimenomaan kritisoinut toimimattomia toteutuksia.

Niin, mutta hyvin kummallisilla perusteluilla ja tarjoamalla tilalle vieläkin kummallisempia ja monin eri tavoin ongelmallisempia vaihtoehtoja.

Näitä sinulle on tässä rautalangasta perusteluiden kanssa taivuteltu, mutta ei tunnu uppoavan.

Minusta vaikuttaa siltä, että sinä määrittelet "oikeaoppisuuden" tarkoitushakuisesti niin, että se tekee omien toteutusten tekemisestä mahdollisimman hankalaa. Myöskään "turvallisuus" ei tarkoita mitään muuta kuin kompleksisuuden lisäämistä kaiken salaamalla (vaikka laite ei edes olisi ulkoverkossa) ja kaikkien pakottamista käyttämään sitä salausta. Käytännössähän nykyisellään noiden etähallittavien laitteiden etähallinta tapahtuu jollain reikäisellä kännykkä-äpillä laitevalmistajan pilven kautta, ja siinä on jo valtava määrä hyökkäyspinta-alaa, josta loppukäyttäjä ei edes pääse omalla toiminnallaan mitenkään eroon.

Asioiden yksinkertaistaminen ja hallinnan siirtäminen loppukäyttäjälle olisi jo valtava harppaus turvallisempaan suuntaan. Salauksen pitää tietysti olla myös mahdollista ja sitä on vähintäänkin suositeltavaa käyttää ulkoverkossa kulkevan datan suojaamiseksi. Salauksen pakottamisesta on kuitenkin vain haittaa.

Kun asiat pidetään riittävän yksinkertaisina, niin mistään "oikeaoppisuudesta" ei tarvitse edes puhua enää, koska riittävä yksinkertaisuus antaa paljon vapaammat kädet itse toteutuksen suhteen, kun noudatettavia sääntöjä ei paljoa ole.

Hankaluus ei ole itseisarvo tietenkään. Tietoturva, dokumentointi, yhteensopivuus, standardit jne sen sijaan voivat hyvinkin olla.

En myöskään ole kiistänyt niiden kaiken maailman pieruappien mahdollisia ongelmia, enkä varsinkaan puolustellut niitä. Siitä huolimatta se että jossakin kikkareessa on kehno tekninen toteutus, ei tarkoita että niin olisi kategorisesti kaikkialla, eikä se varsinkaan ole peruste sille, että pitäisi tehdä tilalle jokin vieläkin huonompi, vanhanaikaisempi ja turvattomampi malli.

Pelkästään tuo jankkauksesi siitä, että liikenteen salaus lisää tarpeetonta kompleksisuutta, on mielestäni vuonna 2023 niin typerä kommentti, että se asettaa samalla kaiken muunkin sanomasi kyseenalaiseksi.

 

[herra57]

Kodin automaatiosysteemin on varmaankin hyvä olla sellainen joka tarjoaa pohjan kaikkien mahdollisten laitteitten liittämiseen siihen.

Olisi kiva kuulla minkälainen protokollapino olisi käyttäjä Sompin mielestä hyvä perusta systeemiin johon tulevaisuudessa kenties mukaan liitetään saunan kiukaan käynnistys, leivinuunin laittaminen täysille ja vesihana valumaan täysillä? Otetaan lisäksi huomioon että talon WiFi verkkoa käytetään 5 lapsen pelailuun 20 parhaan naapurin kaverinsa kanssa kun he ovat vierailemassa.

Nyt ollaan perustamassa firmaa johon investoidaan isot rahat ja ollaan varmoja että systeemi saadaan myytyä suunnilleen jokaiseen kotiin maailmassa jota tukee täysin voittamattomat markkinointiargumentit. Systeemiarkkitehdin paikka on vielä avoinna.

 

[JCSH]

Edelleenkään se REST API ei vähennä ohjelmoijan työmäärää, vaan lisää sitä. Kaikki, mikä toteutetaan REST APIn päällä, voidaan toteuttaa myös paljon kevyemmin myös suoraan TCP:n päällä.

Tämä on vain totta siinä sun omassa harrastelija maailmassa, missä lähdet koodaamaan sitä koko helvetin protokollapinoa itse. Ammattilaiset käyttävät niitä valmiita kirjastoja, joilla sen HTTP requestin pystyy tekemään kirjaimellisesti tyyliin 1-3 rivillä koodia.

Sinä haluat jostain syystä pakottaa kaikki käyttämään ohjelmointikieliä, joista löytyy REST APIn käyttöön tarkoitetut funktiot valmiina. Tuo halu pakottaa kaikenlaista näyttää olevan melko toistuva kaava tässä keskustelussa.

Kaikille moderneille kielille kyllä löytyy ne kirjastot. Jos nyt välttämättä haluat harrastella sillä Brainfuckilla, niin ok, se on sun oma valinta. Mutta älä valita sitten, kun kaikki muut käyttävät jotain helpompaa vaihtoehtoa.

 

[Sompi]

Kaikille moderneille kielille kyllä löytyy ne kirjastot. Jos nyt välttämättä haluat harrastella sillä Brainfuckilla, niin ok, se on sun oma valinta. Mutta älä valita sitten, kun kaikki muut käyttävät jotain helpompaa vaihtoehtoa.

Ai nyt moderni kieli määritelläänkin sen mukaan, löytyykö sen standardifunktioista REST APIn käsittelyyn tarkoitetut funktiot. Taitaapa sitten suurin osa kehityksessä olevista tietokoneohjelmista olla kirjoitettu epämoderneilla kielillä.

Kuinka monta kertaa tässä keskustelussa onkaan mainittu sanat "moderni", "nykyaikainen" tai joku arbitraarinen vuosiluku, ja käytetty sitä ainoana perusteluna milloin minkäkin teknisen asian hyvyydelle tai huonoudelle. Nyt on sen lisäksi vielä kehitetty "oikeaoppisuuden" käsite, jota ennustan muuteltavan aina sen mukaan, mikä milloinkin on suurkorporaatioille hyödyllisintä.

Minua ei kiinnosta mielivaltaiset mitääntarkoittamattomat ominaisuusmäärittelyt, vaan se, toimiiko käytössä oleva teknologia tai sitä käyttävä laite ylipäätään oikein, ja hallitseeko sitä laitteen valmistaja vaiko loppukäyttäjä itse. Kaikki tuo "nykyaikaisuudesta" pöhiseminen on vain sanahelinää, jolla on tarkoitus manipuloida yleistä mielipidettä ja siirtää huomio pois varsinaisista ongelmista.

Kiinnostaisi kyllä tosiaan sekin, miten joku salatun HTTP-yhteyden yli toimiva REST API edes mahtaa toimia jossain lähiverkossa, jossa sertifikaatteja ei kuitenkaan saa oikein mitenkään sellaisiksi, että esimerkiksi mikään valtavirran web-selain ne hyväksyisi. Tietysti tuo ei ole ongelma, jos se etäkäytettävä laite tehdään riippuvaiseksi valmistajan pilvestä, jonka kautta hallinta tapahtuu - se vain sitten taas tuo yhtälöön melkoisen määrän muita ongelmia.

Jos kaiken vanhan ja toimivan rikkomiseen perustuvan pöhinän sijaan edes joskus keskityttäisiin tuottamaan jotain toimivaa, niin miten paljon parempi paikka maailma olisikaan. Teknologian on tarkoitus helpottaa ihmisen elämää ja vähentää manuaalisen työn tarvetta - tuo jälkimmäinen on koko teknologian kehitystä eteenpäin motivoiva voima. Kummallista, miten monilta ihmisiltä puuttuu kokonaan kyky tehdä jotain loppuun asti valmiiksi ja sen jälkeen nauttia työnsä tuloksista.

 

[Kautium]

Ymmärrätkö Sompi itsekään tuosta "pöhinästä" muita syytellessäsi, että itse pöhiset juuri siinä omassa dinosaurus-teknologian kuplassasi?

Osa vanhemmastakin teknologiasta on ihan toimivaa, eikä niitä väkisin ole kukaan muuttamassa, mutta IT-maailmassa vanha tuppaa jäämään... niin no... vanhaksi aika nopeasti tarpeiden ja maailman muuttuessa ympärillä. Erityisesti tietoturva/tietosuoja on muuttanut tarpeita nopealla syklillä. Olet ihan väärällä alalla, jos haluat koko ajan kuvitella, että kaikki on jo valmista, eikä kehitystä ole tarvetta edistää.

 

[love_doctor]

Kiinnostaisi kyllä tosiaan sekin, miten joku salatun HTTP-yhteyden yli toimiva REST API edes mahtaa toimia jossain lähiverkossa, jossa sertifikaatteja ei kuitenkaan saa oikein mitenkään sellaisiksi, että esimerkiksi mikään valtavirran web-selain ne hyväksyisi. Tietysti tuo ei ole ongelma, jos se etäkäytettävä laite tehdään riippuvaiseksi valmistajan pilvestä, jonka kautta hallinta tapahtuu - se vain sitten taas tuo yhtälöön melkoisen määrän muita ongelmia.

IoT-laitteissa aika usein on niin, että kun ostat laitteen kaupasta, siinä ei ole mitään liitäntöjä tai nappeja. Esim. rämpytät valoa kolme kertaa päälle ja laitat puhelimesta bluetooth-etsinnän päälle, kun laitteessa on vastaava mainostus päällä. Lisäät laitteen valvotusti oman älykodin appsiin. Jos naapuri ehtii kaapata laitteen ennen sua, initiaation voi tehdä uudestaan. Jos naapurissa on paljon hakkereita ja laitteet kaapataan jatkuvasti uudestaan, kusipelti on keksitty. Samantyylinen tämä on kuin WPS. Ei taviksella ole tämän parempaa tietoturvaa ikinä.

Kun laite on tunnistettu, puhelin esim. pitää olla kytketty wlaniin ja puhelin jakaa mitään kyselemättä wlanin kirjautumisasetukset bluetoothin yli laitteelle (protokolla voi olla vaikka salaamaton telnet). Sitten laite testaa yhteyden toimivuuden lataamalla nuo kirjautumisasetukset SSID:n ja geolokaation kera pilveen Kiinaan. Tämän jälkeen laite voi kommunikoida salaamattomalla telnetillä Kiinaan ja REST API toimii sinne kiinalaisen pilvipalvelun suuntaan. Pilvipalvelu osaa reitittää oikean kännyappsin komennot oikealle node-laitteelle. Tietoturva on nyt kunnossa koska selaimessa näkyy lukko. Puhelin toimii pilvipalvelun kanssa, oli lähiverkkoa tai ei. Laite pingaa lähiverkossa tuota pilviserveriä ja salaamaton telnet toimii telia-asiakkaan kolminkertaisen ipv4-nattauksenkin yli. Koska puhelin jakoi saman wlanin salasanan laitteelle kuin mitä itsekin käyttää, laite kommunikoi oikein hyvin lähiverkossakin ja mielellään jakaa kaiken luettavissa olevan liikenteen ja laitteiden tiedot sen telnetin yli Kiinaan. Laite ei kuitenkaan välttämättä käytä lähiverkkoa mihinkään muuhun, esim. komentojen vastaanottoon pilven sijaan/lisäksi.

 

[Paapaa]

Eli mitäs kaikkea me ollaan nyt opittu:

• kodinkoneisiin tarvitaan Telnet-tuki
• REST API on raskas ja monimutkainen
• ASCII- ja Telnet-protokollat parraat
• Ikävää kun yksi käyttäjä ei voi pakottaa teollisuutta takaisin 70-luvulle
• Iisalmen poliisipäällikkö voi räjäytellä etänä turvatyynyjä
• hätäjarruavustin on hengenvaarallinen koska välikaasu ja urkujalkio
• 70-luvulla teknologia oli huipussaan, sen jälkeen kaikki on ollut vain pöhinää

Mitä tärkeää unohtui? Voitaisiin taas palata ketjun aiheeseen kun tuon yhden ruokkiminen loppuisi.

 

[jyppi]

Eli mitäs kaikkea me ollaan nyt opittu:

• kodinkoneisiin tarvitaan Telnet-tuki
• REST API on raskas ja monimutkainen
• ASCII- ja Telnet-protokollat parraat
• Ikävää kun yksi käyttäjä ei voi pakottaa teollisuutta takaisin 70-luvulle
• Iisalmen poliisipäällikkö voi räjäytellä etänä turvatyynyjä
• hätäjarruavustin on hengenvaarallinen koska välikaasu ja urkujalkio
• 70-luvulla teknologia oli huipussaan, sen jälkeen kaikki on ollut vain pöhinää

Mitä tärkeää unohtui? Voitaisiin taas palata ketjun aiheeseen kun tuon yhden ruokkiminen loppuisi.

Ihme ettei Cobolia olla vielä mainittu.

 

[JCSH]

Ai nyt moderni kieli määritelläänkin sen mukaan, löytyykö sen standardifunktioista REST APIn käsittelyyn tarkoitetut funktiot. Taitaapa sitten suurin osa kehityksessä olevista tietokoneohjelmista olla kirjoitettu epämoderneilla kielillä.

Ai niin että kukahan täällä nyt rakentelee niitä olkiukkoja?
En ole missään vaiheessa puhunut mitään standardifunktiosta vaan siitä, että noille kielille löytyy kirjastot tuon HTTP(S):n hanskaamiseen. Jopa niinkin moderniin kieleen, kuten siihen 70-luvulla luotuun C:hen.

 

[David ":DA" Imodium]

Ai niin että kukahan täällä nyt rakentelee niitä olkiukkoja?
En ole missään vaiheessa puhunut mitään standardifunktiosta vaan siitä, että noille kielille löytyy kirjastot tuon HTTP(S):n hanskaamiseen. Jopa niinkin moderniin kieleen, kuten siihen 70-luvulla luotuun C:hen.

Mitäs ne kirjastot ovat?

 

[teppo mörkö]

Eli mitäs kaikkea me ollaan nyt opittu:

• kodinkoneisiin tarvitaan Telnet-tuki
• REST API on raskas ja monimutkainen
• ASCII- ja Telnet-protokollat parraat
• Ikävää kun yksi käyttäjä ei voi pakottaa teollisuutta takaisin 70-luvulle
• Iisalmen poliisipäällikkö voi räjäytellä etänä turvatyynyjä
• hätäjarruavustin on hengenvaarallinen koska välikaasu ja urkujalkio
• 70-luvulla teknologia oli huipussaan, sen jälkeen kaikki on ollut vain pöhinää

Mitä tärkeää unohtui? Voitaisiin taas palata ketjun aiheeseen kun tuon yhden ruokkiminen loppuisi.

• 3Gtä nopeampaa nettiyhteyttä ei tarvitse mihinkään
• Nettiä käytetään iltalehti.fi lukemiseen, todistaa yo. pointin
• auton akku kestää maksimissaan neljä vuotta
• auton vaihdetta ei pysty vaihtamaan pienemmälle ilman välikaasua
• kaikki nämä ovat soijakoodarien pakottamia juttuja

 

[pulatunnus]

Tämä on vain totta siinä sun omassa harrastelija maailmassa, missä lähdet koodaamaan sitä koko helvetin protokollapinoa itse. Ammattilaiset käyttävät niitä valmiita kirjastoja, joilla sen HTTP requestin pystyy tekemään kirjaimellisesti tyyliin 1-3 rivillä koodia.

Vähän keinotekoiselta kuullostaa asetetut rajat, jotain valmista voidaan käyttää, mutta ei jotain toista.
Siis oletus että kuitenkin kelpaa valmiit ethernet kerroksen koodit, samoin IP kerroksen, ja niiden päällä voidaan mennä, Telent protokolla valmiina osittain kelpaa, mutta sitten halutaan koodata sen päälle kaikki itse. Jos tarkoitus vain tuupata palvelimelle dataa, ilman suojauksia, niin kai se onnistuisi UDP paketteja lähettämällä. Jos taasen tehdään palvelinta, jotain tarkoitusta varten, niin ehkä kananttaisi keskittyä siihen itse asiaan, voisi päästä maaliin, vs lähteä koodaileen omia protokollia ja niiden ympärille uniikkeja suojakerroksia jne.

Sen ymmärrän että jos on joskus jokin asian opetellut ja alkaa sujuun rutiinilla, niin sitä herkästi tekee sillä, vaikka tietäisi olevan parempiakin vaihtoehtoja.

Komponenttihinta kysymyskään ei tänäpäivänä, jos siis jotain sulautettua kotikutoista rakentelee, niin microkontolereissa on toki eroa mitä kaikkea niissä on, mutta se ethernet niissä maksaa, jos Wifi kelpaa kotipuuhasteluun, niin pääse jo halvalla ja varsin avointa kehitysvälinettä löytyy.

 

[jetblack]

Nyt kyllä tarvisi jonkun koodarisankarin Danske bankille hommiin. Näin nykyaikana niilläkin on niinkin ihmeellinen asia että verkkopankissa ja mobiilipankissa tehdyt maksut/laskut eivät näy ristiin. Eli jos esim kännykällä luet laskun viivakoodin ja pistät sen odottamaan hyväksymättä niin sitä ei voi hyväksyä verkkopankissa koska se ei näy siellä, ja sama toisinpäin. Onko tämä joku vain danskebankin ihmeellisyys vai onko yleisempikin asia. Kai tähänkin on joku oikeakin syy, siis muu kuin koodareiden osaamattomuus tai laiskuus, mutta mikä se sitten olisi? Varmistin asian vielä asiakaspalvelusta ja sanoivat että valitettavasti asian nyt vaan on niin.

 

[Rokka]

Vaikuttaa että toiminnallisuus on tietoisesti suunniteltu sellaiseksi että maksu viedään pankin järjestelmiin vasta kun se hyväksytään, sitä ennen se on tallennettuna vain paikallisesti puhelimeen. Kuulostaa ihan validilta ratkaisulta,mutta vaikea arvioida kun ei tiedä kaikkia päätökseen vaikuttaneita tekijöitä.

Koodaajilla ei kuitenkaan ole (todennäköisesti) asian kanssa mitään muuta tekemistä kuin että he ovat vain toteuttaneet sen mitä on speksattu. Syyttävä sormi pitää siis osoittaa kehitysprojektin ylemmälle tasolle.

 

[leffo]

Tässä juuri kiteytyy se vittumainen asenne. Eli koska sinua itseäsi ei kiinnosta muut kuin virran mukana kulkeminen, valmiit tuotteet ja niiden kuluttaminen, niin kaikkien muidenkin elämä pitää tehdä mahdollisimman hankalaksi ja estää kaikenlainen itse tekeminen.

Sä taas haluat että yritykset ja heidän asiakkaansa maksavat sellaisten asioiden toteuttamisesta jotka kiinnostavat lähinnä sinua ja muutamaa hassua muuta. Ei ole minusta yhtään sen hienompaa.

Nyt kyllä tarvisi jonkun koodarisankarin Danske bankille hommiin. Näin nykyaikana niilläkin on niinkin ihmeellinen asia että verkkopankissa ja mobiilipankissa tehdyt maksut/laskut eivät näy ristiin. Eli jos esim kännykällä luet laskun viivakoodin ja pistät sen odottamaan hyväksymättä niin sitä ei voi hyväksyä verkkopankissa koska se ei näy siellä, ja sama toisinpäin. Onko tämä joku vain danskebankin ihmeellisyys vai onko yleisempikin asia. Kai tähänkin on joku oikeakin syy, siis muu kuin koodareiden osaamattomuus tai laiskuus, mutta mikä se sitten olisi? Varmistin asian vielä asiakaspalvelusta ja sanoivat että valitettavasti asian nyt vaan on niin.

No, se on toteutettu noin. Olisiko toteutuksen muuttamiseen jokin oikeakin syy?

Jos kerran ne laskut näkyy hyvin molemmilla tavoilla sen jälkeen kun ne on hyväksytty? Epäilemättä sulla on joku hemmetin hyvä syy syöttää laskuja, mutta jättää ne hyväksymättä. Ja se olisi kiinnostavaa kuulla se hyvä syy?

 

[jetblack]

Sä taas haluat että yritykset ja heidän asiakkaansa maksavat sellaisten asioiden toteuttamisesta jotka kiinnostavat lähinnä sinua ja muutamaa hassua muuta. Ei ole minusta yhtään sen hienompaa.



No, se on toteutettu noin. Olisiko toteutuksen muuttamiseen jokin oikeakin syy?

Jos kerran ne laskut näkyy hyvin molemmilla tavoilla sen jälkeen kun ne on hyväksytty? Epäilemättä sulla on joku hemmetin hyvä syy syöttää laskuja, mutta jättää ne hyväksymättä. Ja se olisi kiinnostavaa kuulla se hyvä syy?

lasku siis voi olla hyväksytty mutta jos haluan esim aikaistaa maksupäivää eli maksaa heti eikä vasta joskus eräpäivänä niin jos olen luonut laskun verkkopankissa niin en voi sitä maksaa heti pois (tai muokata) mobiilissa vaan pitää erikseen kirjautua verkkopankkiin.

ja hemmetin hyvä syy välillä on se että ei ole rahaa vaan pitää miettiä kumpi (minä tai vaimo) maksaa minkäkin laskun kun tuloissa ja laskuissa on välillä isojakin heittoja.

eli jos olen luonut verkkopankissa vaikka 5 laskua jotka eivät ole tulleet e-laskuna ja ne ovat hyväksytty veloitettavaksi eräpäivänä niin mobiilipankissa ei ole näkyvissä tulevia laskuja / veloituksia tililtä. sama toisin päin.

 

[leffo]

lasku siis voi olla hyväksytty mutta jos haluan esim aikaistaa maksupäivää eli maksaa heti eikä vasta joskus eräpäivänä niin jos olen luonut laskun verkkopankissa niin en voi sitä maksaa heti pois (tai muokata) mobiilissa vaan pitää erikseen kirjautua verkkopankkiin.

Joo tuo on eri asia. Tuntuu kyllä vähän hölmöltä toteutukselta että hyväksyttyä maksua ei voi jälkikäteen muuttaa "väärästä" systeemistä.

 

[love_doctor]

Joo tuo on eri asia. Tuntuu kyllä vähän hölmöltä toteutukselta että hyväksyttyä maksua ei voi jälkikäteen muuttaa "väärästä" systeemistä.

Voi olla PEBKAC, mutta minusta S-pankilla oli myös hiukan sivuava ongelma siinä, että jos maksoin laskuja mobiililla, verkkopankki ei ikinä ehdottanut e-laskujen automatisoimista, joten mobiilimaksamisesta rangaistiin sillä, että työ oli taas tehtävä manuaalisesti uudestaan kuukauden päästä. Vasta kun joskus jaksoin maksaa PC:llä, tuli mahdollisuus automatisoida koko vaiva pois. Jossain vaiheessa sitten minusta mobiiliappsiin tuli mahdollisuus automatisoida laskut. Nyt on taas pari vuotta siitä kun viimeksi tarvi automatisoida joku säännöllinen lasku, niin ei ole mitään muistikuvaa, miten tuo meni.

 

[jetblack]

ja tässä toinen esimerkki. verkkopankkiin on tullut e-lasku vakuutusyhtiöltä sanotaan vaikka 1000€ ja se on hyväksytty maksettavaksi eräpäivänä joka voi olla vaikka 2kk päässä. kun katson mobiilipankissa tilin tietoja niin näyttää että erääntyviä maksuja ei ole, niin voi helposti vetäistä käyttötilin saldon alle 1000€ juuri väärällä hetkellä.

 

[Kautium]

ja tässä toinen esimerkki. verkkopankkiin on tullut e-lasku vakuutusyhtiöltä sanotaan vaikka 1000€ ja se on hyväksytty maksettavaksi eräpäivänä joka voi olla vaikka 2kk päässä. kun katson mobiilipankissa tilin tietoja niin näyttää että erääntyviä maksuja ei ole, niin voi helposti vetäistä käyttötilin saldon alle 1000€ juuri väärällä hetkellä.

Vaikuttaa bugilta. Ei tuollaiselle oikein ole mitään muuta toiminnallista perustelua. Kannattaa laittaa viestiä pankin aspaan.

Samaan hengenvetoon pitää mainita, että OP:n verkkopankki on ollut käytettävyydeltään viimeisimmän muutama vuosi sitten tehydyn uudistuksen jälkeen melkoista kakkelia. Asiat saa lopulta kyllä hoidettua ja vaikka sivuston nopeus onkin parantunut alkuvaiheesta, niin monia toimintoja pitää etsiä joskus hyvin epäloogisista paikoista jne. Mobiilisovellus on astetta parempi, mutta siinäkin on omat ongelmansa.

S-pankin mobiilisovelluksessa taas tökkii, kun se kysyy suunnilleen jokaisen maksun jälkeen, että "haluaisitko jättää palautetta" ja siitä jää joskus vähän epävarma fiilis, että menikö koko laskutapahtuma edes läpi. Samaten se herjailee joskus siirron jälkeen yhteysvirhettä, vaikka kaikki olisi ok. Jotenkin sitä olettaisi, että edes näin kriittisissä palveluissa olisi tehty kunnollinen käytettävyystestaus ennen kuin sovellus rykäistään tuotantoon.

 

[leffo]

Mulla oli S-pankin mobiilipankki käytössä n. 2020-2022 tai 2023 alkuvuoteen asti, kunnes se lakkasi toimimasta korotetun käyttöjärjestelmäversiovaatimuksen takia.(mun mielestä tuo on oikea sana vaikka vähän hassun pitkä) Alunperin siinä ei esimerkiksi pystynyt katsomaan e-laskuja, myöhemmin sellainen toiminnallisuus lisättiin, mikä näin jälkikäteen ajatellen luulisi olleen iät ja ajat. Tätä olisi joskus kaivannut koska vaikka mulla lähes kaikki e-laskut meni automaattisesti, on se silti vähän hyvä niiden perään katsella. Mobiilipankkiin pystyisi tuollaista pikkuasiaa varten nopeammin kirjautumaan.

Enimmäkseen kylläkin käytin mobiilipankkia lähinnä verkkopankkiin kirjautumisessa, koska olen jälkimmäistä ja tietokonetta tottunut käyttämään kaikessa, ja toisinaan katsoin siitä nopeasti korttitilin saldon, koska käytän sitä "prepaidina" ja lataan aina kuukausittain sille rahaa. Silloin tällöin siitä on rahat loppuneet koska en ole muistanut ladata sitä. Nykyisin olen oppinut että noi maksut voi ohjelmoida etukäteen aina kuukausittain tapahtuvaksi, jolloin ei tarvitse muistaa sitä säännöllisesti tehdä.

Mobiilipankissa tuntuu kauttaaltaan olevan sellainen B luokan meininki, kun verkkopankissa on täysi toiminnallisuus. Samaten yhden toisen ihmisen kanssa törmättiin Nordean mobiilipankissa sellaiseen että kortin maksurajoja ei pysty muuttamaan mobiililla.


Ketjun aiheen suhteen kuitenkin pankkipalvelujen digitaalisuus on fantastista!
Mä en ole koskaan joutunut maksamaan mitään laskuja perinteisillä menetelmillä kuten niillä siirtolomakkeilla, tai laskuautomaatilla.(olen saattanut huvikseen joskus kokeilla laskuautomaattia, en voi muistaa) Verkkopankissa on onnistunut lähes kaikki paitsi käteisen tallentaminen, mitä ei ole juuri tullut tehtyä.
Samaten mobiilipankki vain tuo lisää vaihtoehtoja ja tekee joidenkin asioiden tekemisen helpommaksi. Tulevaisuudessa osaan valita puhelimen paremmin ettei se samantien muutamassa vuodessa "vanhenisi", tuota ekaa ostaessa valitettavasti luulin ja varmaankin tiedostamatta oletin että älypuhelimet ovat pohjimmiltaan kuin tietokoneet, ja vanhaakin voi hyvin käyttää niin kauan kuin se teknisesti toimii.

 

[Paapaa]

Samaten yhden toisen ihmisen kanssa törmättiin Nordean mobiilipankissa sellaiseen että kortin maksurajoja ei pysty muuttamaan mobiililla.

Kokeilin juuri ja kyllä samat asetukset löytyvät niin verkosta kuin mobiilisovelluksesta maksurajojen suhteen. Eli tuo ei pidä paikkaansa.

 

[leffo]

Kokeilin juuri ja kyllä samat asetukset löytyvät niin verkosta kuin mobiilisovelluksesta maksurajojen suhteen. Eli tuo ei pidä paikkaansa.

No silloin tuntui pätevän, 3 vuotta sitten. Toisaalta kyse ei ollut mun tilistä vaan hänen, ehkä hän ei löytänyt oikeaa kohtaa, yritti kyllä aikansa.

 

[poskiholisti]

Nordean mobiilisovellus alkaa olemaan kyllä aika kattava ja käytettävä paketti. Hoituu niin päivittäiset raha-asiat ja sijoituspuolen juttujakin pystyy hanskaamaan. Sijoituspuolen kattavuudessa tokikaan ei päästä vaikkapa Nordea Investor-palvelun tasolle, mutta mobiililaitteen rajoitteet huomioonottaen suoritus on vallan kelvollinen. Nordea Wallet eli kulutuksenseurantasovellus poistui kesällä ja toiminnallisuudet löytyvät nykyään tuosta "pääsovelluksesta" jopa kattavammin kuin aiemmin. Eli tämän osalta digitalisaatio toimii.

 

[Antw]

Nordean mobiilisovellus alkaa olemaan kyllä aika kattava ja käytettävä paketti. Hoituu niin päivittäiset raha-asiat ja sijoituspuolen juttujakin pystyy hanskaamaan. Sijoituspuolen kattavuudessa tokikaan ei päästä vaikkapa Nordea Investor-palvelun tasolle, mutta mobiililaitteen rajoitteet huomioonottaen suoritus on vallan kelvollinen. Nordea Wallet eli kulutuksenseurantasovellus poistui kesällä ja toiminnallisuudet löytyvät nykyään tuosta "pääsovelluksesta" jopa kattavammin kuin aiemmin. Eli tämän osalta digitalisaatio toimii.

OP:n mobiilisovellus on ollut myös jo pidemmän aikaa loistava, tulee käytettyä päivittäin ja useitakin kertoja päivässä. Käyttökokemus mielestäni erittäin sulavaa, ja asiointi tallentuu helposti "lihasmuistiin".

 

[Paapaa]

Ketjun aiheen suhteen kuitenkin pankkipalvelujen digitaalisuus on fantastista!

Tämä! Pankkiasiointi on varsin usein tarvittu palvelu ja siinä digitaalisuus on tuonut valtavia hyötyjä:

• Ei tarvitse nostaa rahaa, voi maksaa sähköisesti
• Ei tarvitse juuri koskaan käydä konttorissa, sillä lähes kaikki onnistuu omalta koneelta: laskunmaksu, tilien avaamiset, sijoitukset, kortin tilaaminen, tunnusluvun uusiminen/tarkistaminen, lainan hakeminen ja poismaksaminen, käyttörajojen muuttaminen, tilitietojen selaus jne.
• Tiliotteet säilötään automaattisesti ja niiden selaus ja niistä etsiminen on aiempaa helpompaa.
• Saa asioida koska tahansa. Tämä on aivan käsittämättömän iso asia, ettei asioiden hoito ole sidoksissa toimistoaikoihin.
• Asiointi on paljon nopeampaa kun ei tarvitse matkustaa konttoriin, odotella omaa vuoroa, selittää asiaa virkailijalle.
• Turvallisempaa, sillä mukana ei kulje käteistä, automaatilla ei tarvitse näpytellä koodeja ja vilautella kortteja. (Tilanne oli huonompi kun piti kirjoitella tunnuslukulistoista koodeja, nykyään ei enää tarvitse).
• Asuntolainassakin kohta ei tarvitse sitä älytöntä paperisen osakekirjan toimittamista pankin säilöön, sillä homme on menossa digitaaliseksi.
• Jne.

Sama koskee toki muutakin asiointia, vaikkapa verotusasioiden hoitamista.

 

[Hyrava]

Tämä! Pankkiasiointi on varsin usein tarvittu palvelu ja siinä digitaalisuus on tuonut valtavia hyötyjä:

• Ei tarvitse nostaa rahaa, voi maksaa sähköisesti
• Ei tarvitse juuri koskaan käydä konttorissa, sillä lähes kaikki onnistuu omalta koneelta: laskunmaksu, tilien avaamiset, sijoitukset, kortin tilaaminen, tunnusluvun uusiminen/tarkistaminen, lainan hakeminen ja poismaksaminen, käyttörajojen muuttaminen, tilitietojen selaus jne.
• Tiliotteet säilötään automaattisesti ja niiden selaus ja niistä etsiminen on aiempaa helpompaa.
• Saa asioida koska tahansa. Tämä on aivan käsittämättömän iso asia, ettei asioiden hoito ole sidoksissa toimistoaikoihin.
• Asiointi on paljon nopeampaa kun ei tarvitse matkustaa konttoriin, odotella omaa vuoroa, selittää asiaa virkailijalle.
• Turvallisempaa, sillä mukana ei kulje käteistä, automaatilla ei tarvitse näpytellä koodeja ja vilautella kortteja. (Tilanne oli huonompi kun piti kirjoitella tunnuslukulistoista koodeja, nykyään ei enää tarvitse).
• Asuntolainassakin kohta ei tarvitse sitä älytöntä paperisen osakekirjan toimittamista pankin säilöön, sillä homme on menossa digitaaliseksi.
• Jne.

Sama koskee toki muutakin asiointia, vaikkapa verotusasioiden hoitamista.

Tästä ei voi olla kuin samaa mieltä. Itse olen tainnut joutua käymään pankin konttorissa viimeisen 20v aikana 2 vai 3 kertaa jonkun asian takia ja varmaan nekin asiat hoituisivat jo nykyään sähköisesti. En edes tiedä missä nykyään olisi lähin pankkikonttori kun niitäkin on ainakin kaksi lähintä suljettu viimeisen 5v aikana.

 

[Drinkkeri]

Tämä! Pankkiasiointi on varsin usein tarvittu palvelu ja siinä digitaalisuus on tuonut valtavia hyötyjä:

• Ei tarvitse nostaa rahaa, voi maksaa sähköisesti
• Ei tarvitse juuri koskaan käydä konttorissa, sillä lähes kaikki onnistuu omalta koneelta: laskunmaksu, tilien avaamiset, sijoitukset, kortin tilaaminen, tunnusluvun uusiminen/tarkistaminen, lainan hakeminen ja poismaksaminen, käyttörajojen muuttaminen, tilitietojen selaus jne.
• Tiliotteet säilötään automaattisesti ja niiden selaus ja niistä etsiminen on aiempaa helpompaa.
• Saa asioida koska tahansa. Tämä on aivan käsittämättömän iso asia, ettei asioiden hoito ole sidoksissa toimistoaikoihin.
• Asiointi on paljon nopeampaa kun ei tarvitse matkustaa konttoriin, odotella omaa vuoroa, selittää asiaa virkailijalle.
• Turvallisempaa, sillä mukana ei kulje käteistä, automaatilla ei tarvitse näpytellä koodeja ja vilautella kortteja. (Tilanne oli huonompi kun piti kirjoitella tunnuslukulistoista koodeja, nykyään ei enää tarvitse).
• Asuntolainassakin kohta ei tarvitse sitä älytöntä paperisen osakekirjan toimittamista pankin säilöön, sillä homme on menossa digitaaliseksi.
• Jne.

Sama koskee toki muutakin asiointia, vaikkapa verotusasioiden hoitamista.

Mutq ei toimi itse koodatulla foliohattulinuxilla

 

[tatulpin]

Mutq ei toimi itse koodatulla foliohattulinuxilla

Jep, pankit vois sallia tilin käytön telnetin yli.

 

[poskiholisti]

Jep, pankit vois sallia tilin käytön telnetin yli.

Vähän aiheen sivusta, mutta ei tästä ole edes kymmentä vuotta kun pankit lopettivat FTP-pohjaiset PATU-yhteydet yritysten ja pankkien välillä

 

[Sompi]

Samaan hengenvetoon pitää mainita, että OP:n verkkopankki on ollut käytettävyydeltään viimeisimmän muutama vuosi sitten tehydyn uudistuksen jälkeen melkoista kakkelia. Asiat saa lopulta kyllä hoidettua ja vaikka sivuston nopeus onkin parantunut alkuvaiheesta, niin monia toimintoja pitää etsiä joskus hyvin epäloogisista paikoista jne. Mobiilisovellus on astetta parempi, mutta siinäkin on omat ongelmansa.

OP:lla oli se perus-html:llä tehty pda.op.fi-osoitteesta löytynyt versio verkkopankistaan, joka toimi kaikilla selaimilla hyvin. Sitten se korvattiin sillä "saavutettavalla" javascript-paskeella, joka ei varmastikaan ole yhtään sitä perus-html-versiota saavutettavampi, koska näkövammaisten selaimet ovat huonoja parsimaan monimutkaisia javascript-sivuja. Paremmin saavutettavuutta olisi parannettu ihan vain tekemällä vanhaan pda.op.fi-verkkopankkiin sellainen muutos, että sivu olisi päivitetty käyttämään HTML:n viitosversiota ja lisätty sinne semanttiset tagit, jotta näkövammaisten selaimet osaavat jäsennellä sivun sisällön paremmin.

Tuo uusi "saavutettava" verkkopankkihan ei edes suostu toimimaan, jos selain ei ole joko Firefox, Chrome tai Internet Explorer. Sitä vanhaa pda-versiota tuli aina käyteltyä lynxillä, jossa minimalistisemman koodikantansa ansiosta on varmasti vähemmän tietoturva-aukkoja kuin vaikkapa Firefoxissa.