PASCAL koodin kääntäminen

Kyllä optimointivipuja voi käyttää normaaleissa ohjelmissa.

Sellaiset while silmukat eivät kuitenkaan ole normaaleja ohjelmia.

Eikös FreePascal lähdekooditiedoston pääte ole *.PAS, kun taas *.PP tiedostopääte viittaa johonkin, en tiedä mihin.

Anonyymi kirjoitti:

Eikös FreePascal lähdekooditiedoston pääte ole *.PAS, kun taas *.PP tiedostopääte viittaa johonkin, en tiedä mihin.

Voi kokeilla myöskin Lazaruksella. Se käyttää kääntämisessä FPC:tä ja sen käyttämä pääte on *.LPR (Lazarus PRoject). Muutenkin tuo on helpompi kääntää Lazaruksen kautta: Valitsee ensin Projekti -> Uusi projekti ja sieltä "yksinkertainen ohjelma". Tähän sitten korvaa lähdekoodin ja painaa Play-nappulaa. Tämän jälkeen käännetty ohjelma on kotihakemistosi alla ~/tmp/project1 nimellä, mikäli et editoinut projektin otsakkeita. Näin ainakin tämä toimii Ubuntu:ssa.
Oisko kuitenkin parempi koodata unitteja jo heti alusta lähtien? Helpompi sitten tehdä vaikka Android-ohjemia jatkossa..

VÄITE: "Kaikki aika mitä sijoitat tähän kieleen menee aivan varmasti hukkaan niin työmarkkinoilla kuin muuallakin"

FAKTA: työmarkkinoiden osalta tilanne on tällä hetkellä valitettavasti tuo. Johtuu yritysjohtajien kollektiivisesta hulluudesta. Jatketaan C ja "C " -kielten käyttöä, vaikka on yleisesti tiedossa, että niiden käyttö johtaa tietoturvaltaa heikkoon koodiin ja myöhemmin siihen, että joku onnistuneesti tekee tietomurron.

Jos ne systeemit koodattaisiin Objectpascalilla (olipa kääntäjänä sitten Delphi tai Freepascal) niin tuollaisia mokia ei tulisi. Ilmeisesti erityisesti jenkkien NSA painostaa yrityksia jatkamaan C ja "C " -kielten käyttöä, koska tämä takaa sen, että NSA:lle työskentelevät tutkijat jatkossakin löytävät muiden yritysten koodista tietoturvareikiä, ja tämä tarjoaa NSA:lle helpon tavan toteuttaa yritysvakoilua.

Sensijaan jos aiot itse perustaa oman yrityksen, niin mikään ei estä koodaamasta kaikkea yrityksen tarvitsemaa tietotekniikkaa joko Delphillä tai FreePascalilla. Fiksuinta lienee tehdä koodista sellaista, että se kääntyy tarvittaessa molemmilla.

Jos kirjoitat koodin sekaan myös assemblyä, niin Delphi tukee vain Intel/Borland -syntaksia, joten unohda se sekava AT&T syntaksi, ja FreePascalia varten käytä {$asmmode intel} sekä {$mode delphi} -määritettä.

Vain M-Kar väittää, että C -koodia voisi jotenkin validioida Haskellilla ?

Kumman luulet olevan luotettavampaa?

Senkö, kun Delphi -ohjelmaan laitetaan {$R } jolloin jokainen talulukon indeksi automaattisesti tarkistetaan, ja jos indeksi on luvaton, ei synny tietoturvareikää, vaan ERangeCheckError -poikkeus.

Vai senkö, että kun C ja "C " -kielet eivät osaa indeksejään itse tarkistaa, niin ilmeisesti noiden kielten lähdekoodi ajetaan jonkin Haskell -tarkistimen läpi. Ja se tarkistinko pystyy aina ja kaikissa tilainteissa selvittämään lähdekoodin perusteella, ettei mihinkääm taulukkoon viitata laittomalla indeksillä ja varoittamaan tuosta ?

Epäilen suoraan, ettei tuollainen käännösaikainen tarkistus millään voi kattaa kaikkia tilanteita. Siksipä Delphi ei luota pelkkään käännösaikaiseen tarkistukseen, vaan tarkistaa ajonaikaisesti esim: A[i] tyyliset viittaukset, jossa A on taulukko ja i on indeksi.

Mistäpä se Haskell -tarkistus voisi pelkästä lähdekoodista selvittää, mikä tulee ajonaikana olemaan tuon i -muuttujan arvo ?

Se on hyvä kysymys, miksi yritysten johatjat valitsee tietoisesti sellaisia ohjelmointikieliä, joilla tietoturvariskien ja -reikien syntyminen on lähes taattua.
Ehkä moni yritysjohtaja on salaliitossa NSA:n kanssa, ja tuon tarkoituksena on antaa NSA:lle helppo pääsy yritysten tietojärjestelmiin. Tosin, kun tietoturvareikiä on, niin NSA:n lisäksi kuka tahansa rikollinen voi tehdä samoin.

Keskimääräisellä rikollisella ei toki ole NSA:n tasoista tietotekniikkaosaamista.

MUTTA: kun Intiassa on ties kuinka monta köyhää, mutta riittävän älykästä työtöntä koodaajaa, niin ehkä rikolliset palkkaavat noita etsimään tietoturvareikiä ja kehittämään niihin toimivia hyökkäyksiä, joita rikolliset sitten maksua vastaan saavat käyttöönsä.

Anonyymi kirjoitti:

VÄITE: "Kaikki aika mitä sijoitat tähän kieleen menee aivan varmasti hukkaan niin työmarkkinoilla kuin muuallakin"

FAKTA: työmarkkinoiden osalta tilanne on tällä hetkellä valitettavasti tuo. Johtuu yritysjohtajien kollektiivisesta hulluudesta. Jatketaan C ja "C " -kielten käyttöä, vaikka on yleisesti tiedossa, että niiden käyttö johtaa tietoturvaltaa heikkoon koodiin ja myöhemmin siihen, että joku onnistuneesti tekee tietomurron.

Jos ne systeemit koodattaisiin Objectpascalilla (olipa kääntäjänä sitten Delphi tai Freepascal) niin tuollaisia mokia ei tulisi. Ilmeisesti erityisesti jenkkien NSA painostaa yrityksia jatkamaan C ja "C " -kielten käyttöä, koska tämä takaa sen, että NSA:lle työskentelevät tutkijat jatkossakin löytävät muiden yritysten koodista tietoturvareikiä, ja tämä tarjoaa NSA:lle helpon tavan toteuttaa yritysvakoilua.

Sensijaan jos aiot itse perustaa oman yrityksen, niin mikään ei estä koodaamasta kaikkea yrityksen tarvitsemaa tietotekniikkaa joko Delphillä tai FreePascalilla. Fiksuinta lienee tehdä koodista sellaista, että se kääntyy tarvittaessa molemmilla.

Jos kirjoitat koodin sekaan myös assemblyä, niin Delphi tukee vain Intel/Borland -syntaksia, joten unohda se sekava AT&T syntaksi, ja FreePascalia varten käytä {$asmmode intel} sekä {$mode delphi} -määritettä.

Vain M-Kar väittää, että C -koodia voisi jotenkin validioida Haskellilla ?

Kumman luulet olevan luotettavampaa?

Senkö, kun Delphi -ohjelmaan laitetaan {$R } jolloin jokainen talulukon indeksi automaattisesti tarkistetaan, ja jos indeksi on luvaton, ei synny tietoturvareikää, vaan ERangeCheckError -poikkeus.

Vai senkö, että kun C ja "C " -kielet eivät osaa indeksejään itse tarkistaa, niin ilmeisesti noiden kielten lähdekoodi ajetaan jonkin Haskell -tarkistimen läpi. Ja se tarkistinko pystyy aina ja kaikissa tilainteissa selvittämään lähdekoodin perusteella, ettei mihinkääm taulukkoon viitata laittomalla indeksillä ja varoittamaan tuosta ?

Epäilen suoraan, ettei tuollainen käännösaikainen tarkistus millään voi kattaa kaikkia tilanteita. Siksipä Delphi ei luota pelkkään käännösaikaiseen tarkistukseen, vaan tarkistaa ajonaikaisesti esim: A[i] tyyliset viittaukset, jossa A on taulukko ja i on indeksi.

Mistäpä se Haskell -tarkistus voisi pelkästä lähdekoodista selvittää, mikä tulee ajonaikana olemaan tuon i -muuttujan arvo ?

Se on hyvä kysymys, miksi yritysten johatjat valitsee tietoisesti sellaisia ohjelmointikieliä, joilla tietoturvariskien ja -reikien syntyminen on lähes taattua.
Ehkä moni yritysjohtaja on salaliitossa NSA:n kanssa, ja tuon tarkoituksena on antaa NSA:lle helppo pääsy yritysten tietojärjestelmiin. Tosin, kun tietoturvareikiä on, niin NSA:n lisäksi kuka tahansa rikollinen voi tehdä samoin.

Keskimääräisellä rikollisella ei toki ole NSA:n tasoista tietotekniikkaosaamista.

MUTTA: kun Intiassa on ties kuinka monta köyhää, mutta riittävän älykästä työtöntä koodaajaa, niin ehkä rikolliset palkkaavat noita etsimään tietoturvareikiä ja kehittämään niihin toimivia hyökkäyksiä, joita rikolliset sitten maksua vastaan saavat käyttöönsä.

Lue lisää

"FAKTA: työmarkkinoiden osalta tilanne on tällä hetkellä valitettavasti tuo. Johtuu yritysjohtajien kollektiivisesta hulluudesta. Jatketaan C ja "C " -kielten käyttöä, vaikka on yleisesti tiedossa, että niiden käyttö johtaa tietoturvaltaa heikkoon koodiin ja myöhemmin siihen, että joku onnistuneesti tekee tietomurron."

Aika vähän mitään C tai C on käytösssä. Nykyään on aika paljon Java, C#, Python, Javascript, Typescript, Dart, Rust, PHP, Go..

"Vain M-Kar väittää, että C -koodia voisi jotenkin validioida Haskellilla ?"

Tuo näyttää olevan fakta: http://web1.cs.columbia.edu/~junfeng/09fa-e6998/papers/sel4.pdf

"Sensijaan jos aiot itse perustaa oman yrityksen, niin mikään ei estä koodaamasta kaikkea yrityksen tarvitsemaa tietotekniikkaa joko Delphillä tai FreePascalilla. "

Mutta mitä järkeä?

"Senkö, kun Delphi -ohjelmaan laitetaan {$R } jolloin jokainen talulukon indeksi automaattisesti tarkistetaan, ja jos indeksi on luvaton, ei synny tietoturvareikää, vaan ERangeCheckError -poikkeus."

Se että tapahtuu poikkeus, mahdollistaa myös turvareiän. Oikea tapa on tietenkin varmistaa se, että indeksin ei ole mahdollista osoittaa mihin sattuu.

"Vai senkö, että kun C ja "C " -kielet eivät osaa indeksejään itse tarkistaa, niin ilmeisesti noiden kielten lähdekoodi ajetaan jonkin Haskell -tarkistimen läpi."

Ei mitään tuollaista tehdä. Huipputurvallinen C-koodi tehdään niin, että ensiksi toteutaan koodi Haskellilla ja käytetään tätä spesifikaationa, ja sen perusteella voidaan verifioida C-kielinen koodi.

"Ja se tarkistinko pystyy aina ja kaikissa tilainteissa selvittämään lähdekoodin perusteella, ettei mihinkääm taulukkoon viitata laittomalla indeksillä ja varoittamaan tuosta ?"

Formaalissa verifioinnissa todistetaan että mitään väärää indeksiä ei ole mahdollista tulla. Sehän on bugi.

"Epäilen suoraan, ettei tuollainen käännösaikainen tarkistus millään voi kattaa kaikkia tilanteita."

Formaalin verifioinnin idea on todistamisessa, että ei ole mahdollista sellaiset sivuvaikutukset, että toimisi väärin. Voi olla hyvä idea vaikka kirjoittaa Haskellilla joku ohjelman pätkä. Se kieli ohjaa ohjelmoijaa tekemään siistiä koodia varmaankin paremmin kuin mikään muu kieli.

No siinä muutama: https://www.creativebloq.com/web-design/examples-ui-design-7133429

Jostain syystä ei löydy yhtään koodiesimerkkiä, että Lazaruksella olisi tehty mitään noin hienoja. En sano etteikö onnistuisi mutta taitaa olla vain typerän kömpelö työkalu käyttöliittymäohjelmointiin.

Anonyymi kirjoitti:

No siinä muutama: https://www.creativebloq.com/web-design/examples-ui-design-7133429

Jostain syystä ei löydy yhtään koodiesimerkkiä, että Lazaruksella olisi tehty mitään noin hienoja. En sano etteikö onnistuisi mutta taitaa olla vain typerän kömpelö työkalu käyttöliittymäohjelmointiin.

Lue lisää

Pascal/Delphi/Lazarus on kultti, johon kuuluvien ihmisten on hankala tunnustaa, että aika on ajanut heidän ohi. Heidän tehtävänsä on julistaa, kuinka helposti hienoja juttuja sillä voi tehdä ja usein he etsivätkin kissojen ja koirien kanssa sovelluksia, jotka on kyhätty sillä. Vuosi vuodelta lista on suppeampi.

Anonyymi kirjoitti:

Pascal/Delphi/Lazarus on kultti, johon kuuluvien ihmisten on hankala tunnustaa, että aika on ajanut heidän ohi. Heidän tehtävänsä on julistaa, kuinka helposti hienoja juttuja sillä voi tehdä ja usein he etsivätkin kissojen ja koirien kanssa sovelluksia, jotka on kyhätty sillä. Vuosi vuodelta lista on suppeampi.

Lue lisää

Ja sitten ei kuitenkaan löydy yhtään hienoa juttua mitä olisi tehty Lazaruksella.

Anonyymi kirjoitti:

Pascal/Delphi/Lazarus on kultti, johon kuuluvien ihmisten on hankala tunnustaa, että aika on ajanut heidän ohi. Heidän tehtävänsä on julistaa, kuinka helposti hienoja juttuja sillä voi tehdä ja usein he etsivätkin kissojen ja koirien kanssa sovelluksia, jotka on kyhätty sillä. Vuosi vuodelta lista on suppeampi.

Lue lisää

Siinä vaiheessa fpc alkaa vaikuttaa kultakimpaleelta, kun on seurannut ties kuinka monetta typedef:iä structiin ja päätyy lopulta "void *" määrittelyyn jolla otetaankin tietorakenteesta alku pois..
fpc:n hyöty alkaa kirkastua kummasti, kun tällaista koodaustapaa ei oikein suosiolla hyväksytä - syntaksiltaan se näyttää jo niin epämiellyttävältä, että houkutusta "oikoteihin" ei niin vain tule, kuin eräällä muulla kielellä operoidessa.
Mitähän muita hyötyjä? Olioiden jälkeen tulee huomanneeksi, että objective-pascalin lisäksi on tarjolla vielä kolmas tie, joka on keveämpi kuin oliot, mutta ilmaisuvoimaisempi kuin funktionaalinen ohjelmointi. Joka väittää, että c ja pascal ovat 1:1 syntaksiltaan kun korvataan rakenteita toisikseen on kyllä nykyään pahasti hakoteillä.
Totta kyllä, kielten erojen johdosta paluu Pascaliin voi osoittautua hankalaksi, vaan se on erittäin opettavaista, kun joutuu opettelemaan koodaustavan uudestaan sellaiseksi, mikä toimii ekosysteemissä oikein eikä vain kirjoittaa Pascalia C/C :n syntaksilla..

Anonyymi kirjoitti:

Siinä vaiheessa fpc alkaa vaikuttaa kultakimpaleelta, kun on seurannut ties kuinka monetta typedef:iä structiin ja päätyy lopulta "void *" määrittelyyn jolla otetaankin tietorakenteesta alku pois..
fpc:n hyöty alkaa kirkastua kummasti, kun tällaista koodaustapaa ei oikein suosiolla hyväksytä - syntaksiltaan se näyttää jo niin epämiellyttävältä, että houkutusta "oikoteihin" ei niin vain tule, kuin eräällä muulla kielellä operoidessa.
Mitähän muita hyötyjä? Olioiden jälkeen tulee huomanneeksi, että objective-pascalin lisäksi on tarjolla vielä kolmas tie, joka on keveämpi kuin oliot, mutta ilmaisuvoimaisempi kuin funktionaalinen ohjelmointi. Joka väittää, että c ja pascal ovat 1:1 syntaksiltaan kun korvataan rakenteita toisikseen on kyllä nykyään pahasti hakoteillä.
Totta kyllä, kielten erojen johdosta paluu Pascaliin voi osoittautua hankalaksi, vaan se on erittäin opettavaista, kun joutuu opettelemaan koodaustavan uudestaan sellaiseksi, mikä toimii ekosysteemissä oikein eikä vain kirjoittaa Pascalia C/C :n syntaksilla..

Lue lisää

Jos nyt saisi sen ensimmäisenkin Pascalilla kirjoitetun ohjelman minkä koodi ei ole kuraa verrattuna nykyisiin työkaluihin.

void * -määrittelyt eivät ole nykypäivää.

Lopeta tuommonen panettelu.

{$AppType GUI}
{$AppType CONSOLE}

$AppType on kääntäjän direktiivi jolla kerrotaan sovelluksen tyyppi. GUI kertoo kääntäjälle sovelluksella olevan käyttöliittymän ja CONSOLE kertoo ettei käyttöliittymää ole. Oletusarvo on GUI, ellet sitä ole mitenkään määritellyt. Joten hyvin aiheellinen huomautus sinulta, jalon ohjelmointi ympäristön ystävä.

"JOS ei toimi omassa koneessasi, etsi Microsoftin palvelimelta WinHelp.Exe ja asenna se."

Miten se asennetaan macOS:n?

"Sitä sopii kysyä, miksi monessa yrityksessä koodaillaan C:llä ja/tai C :lla, vaikka Delphin käyttö johtaisi laadukkaampaan lopputulokseen, ja vähemmillä työtunneilla !"

Vaikka siksi kun Delphillä ei ole mitään käyttökohdetta missä sillä tekisi yhtään mitään. Ei sovellu ajureihin, ei kerneliin, ei systeemitason kirjastoihin, ei käyttöliittymiin, ei taustajärjestelmiin, ei turvallisuuskriittisiin kohteisiin...

Sillä Delphillä ei yksinkertaisesti tee yhtään mitään. Kasa paskaa se on.

Anonyymi kirjoitti:

"JOS ei toimi omassa koneessasi, etsi Microsoftin palvelimelta WinHelp.Exe ja asenna se."

Miten se asennetaan macOS:n?

"Sitä sopii kysyä, miksi monessa yrityksessä koodaillaan C:llä ja/tai C :lla, vaikka Delphin käyttö johtaisi laadukkaampaan lopputulokseen, ja vähemmillä työtunneilla !"

Vaikka siksi kun Delphillä ei ole mitään käyttökohdetta missä sillä tekisi yhtään mitään. Ei sovellu ajureihin, ei kerneliin, ei systeemitason kirjastoihin, ei käyttöliittymiin, ei taustajärjestelmiin, ei turvallisuuskriittisiin kohteisiin...

Sillä Delphillä ei yksinkertaisesti tee yhtään mitään. Kasa paskaa se on.

Lue lisää

Delphi on mailman paras, ja on ollut alusta lähtien. Ja soveltuu erittäin hyvin kaikkiin luettelemiisi kohteisiin ja paljon muuhun.

Anonyymi kirjoitti:

Delphi on mailman paras, ja on ollut alusta lähtien. Ja soveltuu erittäin hyvin kaikkiin luettelemiisi kohteisiin ja paljon muuhun.

Edelleenkin puuttuu ne esimerkit.

Anonyymi kirjoitti:

Edelleenkin puuttuu ne esimerkit.

Mitkä esimerkit sinulta puuttuu?

Anonyymi kirjoitti:

Mitkä esimerkit sinulta puuttuu?

Koodiesimerkit, että näyttäisi miten Delphillä tehdään asiat paremmin kuin muilla työkaluilla.

Anonyymi kirjoitti:

Koodiesimerkit, että näyttäisi miten Delphillä tehdään asiat paremmin kuin muilla työkaluilla.

Tee nyt joku niillä muilla, niin koitan saada vastaavan Delphillä.

Anonyymi kirjoitti:

Tee nyt joku niillä muilla, niin koitan saada vastaavan Delphillä.

Vaikka tämä: https://fabricweb.z5.web.core.windows.net/pr-deploy-site/refs/heads/master/theming-designer/index.html

Nätisti toimii kaikissa mahdollisissa laitteissa ja saa suunniteltua nykyaikaisen Microsoft teeman sovelluksille. Lähdekoodit tuohon on Githubissa.

Anonyymi kirjoitti:

Vaikka tämä: https://fabricweb.z5.web.core.windows.net/pr-deploy-site/refs/heads/master/theming-designer/index.html

Nätisti toimii kaikissa mahdollisissa laitteissa ja saa suunniteltua nykyaikaisen Microsoft teeman sovelluksille. Lähdekoodit tuohon on Githubissa.

Lue lisää

Tuossa sivussasi (M-K...) on liikaa virheitä. Ei siitä mitään tolkkua saa.

Sisältää määrittelyvirheitä:
external "React"

Sisältää mukaanottovirheitä:
react-dom.production.min.js
react.production.min.js

Anonyymi kirjoitti:

Tuossa sivussasi (M-K...) on liikaa virheitä. Ei siitä mitään tolkkua saa.

Sisältää määrittelyvirheitä:
external "React"

Sisältää mukaanottovirheitä:
react-dom.production.min.js
react.production.min.js

Lue lisää

Mikä (M-K...) ? Mitä virheitä?

Laitoin linkin ohjemaan, se toimii kaikilla nykyään käytössä olevilla tietokoneilla. Testasin myös 7v ikäisellä tabletilla missä on Chromen päivitykset loppuneet aikaa sitten ja hyvin toimii siinäkin. Toimii myös 9v vanhalla Windows 7 läppärillä missä selain päivitetty Firefox 78:n.

Jos se ei sinulla toimi, oletusarvoisesti sinä teet jotain väärin. Esimerkiksi olet sotkenut jotain asetuksia, et ole päivittänyt tai jotain muuta vastaavaa.

Anonyymi kirjoitti:

Mikä (M-K...) ? Mitä virheitä?

Laitoin linkin ohjemaan, se toimii kaikilla nykyään käytössä olevilla tietokoneilla. Testasin myös 7v ikäisellä tabletilla missä on Chromen päivitykset loppuneet aikaa sitten ja hyvin toimii siinäkin. Toimii myös 9v vanhalla Windows 7 läppärillä missä selain päivitetty Firefox 78:n.

Jos se ei sinulla toimi, oletusarvoisesti sinä teet jotain väärin. Esimerkiksi olet sotkenut jotain asetuksia, et ole päivittänyt tai jotain muuta vastaavaa.

Lue lisää

Privacy Badger valvoo yksityisyyden säilyttämistä, ja estää haitalliset sivustot. Tuskin siellä on mitään katsomisen arvoista Linux ympäristöön tottuneelle, mainitaanhan jo linkissä Windows.

Anonyymi kirjoitti:

Privacy Badger valvoo yksityisyyden säilyttämistä, ja estää haitalliset sivustot. Tuskin siellä on mitään katsomisen arvoista Linux ympäristöön tottuneelle, mainitaanhan jo linkissä Windows.

Lue lisää

Ei ole haitallinen sivusto, ja ohjelma toimii kaikissa käyttöjärjestelmissä.

Anonyymi kirjoitti:

"JOS ei toimi omassa koneessasi, etsi Microsoftin palvelimelta WinHelp.Exe ja asenna se."

Miten se asennetaan macOS:n?

"Sitä sopii kysyä, miksi monessa yrityksessä koodaillaan C:llä ja/tai C :lla, vaikka Delphin käyttö johtaisi laadukkaampaan lopputulokseen, ja vähemmillä työtunneilla !"

Vaikka siksi kun Delphillä ei ole mitään käyttökohdetta missä sillä tekisi yhtään mitään. Ei sovellu ajureihin, ei kerneliin, ei systeemitason kirjastoihin, ei käyttöliittymiin, ei taustajärjestelmiin, ei turvallisuuskriittisiin kohteisiin...

Sillä Delphillä ei yksinkertaisesti tee yhtään mitään. Kasa paskaa se on.

Lue lisää

VALHE:"Ei sovellu ajureihin, ei kerneliin, ei systeemitason kirjastoihin, ei käyttöliittymiin, ei taustajärjestelmiin, ei turvallisuuskriittisiin kohteisiin."

FAKTA:

Delphi soveltuu erinomaisesti:

* systeemitason kirjastoihin (DLL)

* käyttöliittymiin (laadukas käyttöliittymä ja on helppo toteuttaa)

* taustajärjestelmiin

* turvallisuuskriittisiin kohteisiin

FreePascal soveltuu erinomaisesti:

* ajureihin

* kerneliin

Laiteajureihin siis Delphi ei sovellu, mutta FreePascal soveltuu erinomaisesti niihinkin.

Lisäksi kannattaa huomata: vaikka Delphi ei varsinaisiin laiteajureihin sovellukaan, niin usein ei edes tarvitse kirjoittaa varsinaista laiteajuria, vaan voi koodata Delphillä DLL:n , joka itse käyttää esim. FTDI:n laiteajureita (jotka voi ilmaiseksi imuroida FTDI:n nettisivulta). Eli se FTDI:n varsinainen laiteajuri keskustelee laitteessa olevan FTDI -muunnosmikropiirin kanssa, ja Delphillä tehty DLL (tai EXE, kuinka vain halutaan), keskustelee suoraan tuon FTDI:n varsinaisen laiteajurin kanssa, mutta samalla välillisesti muun osan laitteistosta kanssa (sen FTDI:n laiteajurin ja mikropiirin välityksellä).

em. tavalla Delphillä tehty DLL toimii melkein kuin oikea laiteajuri, vaikkei se virallisesti laiteajuri olekaan.

macOS:llä ei ole käytännön merkitystä. Vähemmistökäyttis, miksi sille pitäisi koodata mitään ?

Ja turvallisuuskriittisiin kohteisiin Delphi on parempi valinta kuin C tai C .

Kas kun Delphissä löytyy {$R } joka sekä C:stä että C :sta puuttuu !

Jos koodaaja erehtyy käyttämään väärää indeksiä taulukkoon, niin C:llä ja C :lla tehty ohjelma surutta lukee tietoa, joka ei sille kuulu, tai ylikirjoittaa tietoa (ja siten tärvelee sen).

Jos DELPHI:llä koodaaja erehtyy käyttämään väärää indeksiä taulukkoon (kun on käytetty em. {$R } ) niin syntyy poikkeus, joka syntyy ENNEN väärää muistiviittausta, siis ennen kuin väärä muistiviittaus ehtii toteutua !

Tämähän on turvallisuuskriittisissä kohteissa erinomainen ominaisuus, kuinhan koodaaja ymmärtää, että se {$R } ei ole olemassa siksi, että se jotenkin oikeuttaisi huolimattoman koodaustyön, vaan siksi, että jos kaikesta huolellisuuspyrkimyksestä huolimatta koodaaja tekee virheen, niin Delphi -ohjelmassa syntyy ERangeError -poikkeus, siinä missä C tai C -ohjelmassa vastaava koodausvirhe = katastofi, eli puskurin ylivuotohaavoittuvuus.

OpenSSL:ssä havaittiin vuonna 2014 HeartBleed -nimiseksi nimetty puskurin ylivuotohaavoittuvuus. Jos OpenSSL olisi alunperinkin tehty FreePascalilla, niin moista haavoittuvuutta ei olisi koskaan tapahtunut.

Mutta kun se välttämättä päätettiin kirjoittaa C:llä, vaikka FreePascal olisi ollut kaikilta osiltaan parempi vaihtoehto, niin tuo haavoittuvuus ei tule jäämään viimeiseksi, vaan tulevaisuudessa niitä haavoittuvuuksia löytyy lisääkin.

Kuinkahan kauan rikolliset muuten hyödynsivät tuota HeartBleed -haavoittuvuutta ennen sen julkituloa? Entä kansalliset tiedustelupalvelut?

Vai siksikö noita koodataan C -kielellä, että nuo kansalliset tiedustelupalvelut voisivat jatkossakin löytää (ja hyödyntää) haavoittuvuuksia pitkäänkin, ennen kuin suuri yleisö saa tietää haavoittuvuuden olemassaolosta ?

C-kielen käyttö on siis kädenojennus kansallisille tiedustelupalveluille, että jatkossakin olisi haavoittuvuuksia heidän hyväksikäytettäväksi (ja samalla myös rikollisten).

Jos oikeasti haluttaisiin parempaa tietoturvaa, niin C ja C pitäisi hylätä kokonaan ja siirtyä FreePascaliin niiden sijasta.


***

Anonyymi kirjoitti:

VALHE:"Ei sovellu ajureihin, ei kerneliin, ei systeemitason kirjastoihin, ei käyttöliittymiin, ei taustajärjestelmiin, ei turvallisuuskriittisiin kohteisiin."

FAKTA:

Delphi soveltuu erinomaisesti:

* systeemitason kirjastoihin (DLL)

* käyttöliittymiin (laadukas käyttöliittymä ja on helppo toteuttaa)

* taustajärjestelmiin

* turvallisuuskriittisiin kohteisiin

FreePascal soveltuu erinomaisesti:

* ajureihin

* kerneliin

Laiteajureihin siis Delphi ei sovellu, mutta FreePascal soveltuu erinomaisesti niihinkin.

Lisäksi kannattaa huomata: vaikka Delphi ei varsinaisiin laiteajureihin sovellukaan, niin usein ei edes tarvitse kirjoittaa varsinaista laiteajuria, vaan voi koodata Delphillä DLL:n , joka itse käyttää esim. FTDI:n laiteajureita (jotka voi ilmaiseksi imuroida FTDI:n nettisivulta). Eli se FTDI:n varsinainen laiteajuri keskustelee laitteessa olevan FTDI -muunnosmikropiirin kanssa, ja Delphillä tehty DLL (tai EXE, kuinka vain halutaan), keskustelee suoraan tuon FTDI:n varsinaisen laiteajurin kanssa, mutta samalla välillisesti muun osan laitteistosta kanssa (sen FTDI:n laiteajurin ja mikropiirin välityksellä).

em. tavalla Delphillä tehty DLL toimii melkein kuin oikea laiteajuri, vaikkei se virallisesti laiteajuri olekaan.

macOS:llä ei ole käytännön merkitystä. Vähemmistökäyttis, miksi sille pitäisi koodata mitään ?

Ja turvallisuuskriittisiin kohteisiin Delphi on parempi valinta kuin C tai C .

Kas kun Delphissä löytyy {$R } joka sekä C:stä että C :sta puuttuu !

Jos koodaaja erehtyy käyttämään väärää indeksiä taulukkoon, niin C:llä ja C :lla tehty ohjelma surutta lukee tietoa, joka ei sille kuulu, tai ylikirjoittaa tietoa (ja siten tärvelee sen).

Jos DELPHI:llä koodaaja erehtyy käyttämään väärää indeksiä taulukkoon (kun on käytetty em. {$R } ) niin syntyy poikkeus, joka syntyy ENNEN väärää muistiviittausta, siis ennen kuin väärä muistiviittaus ehtii toteutua !

Tämähän on turvallisuuskriittisissä kohteissa erinomainen ominaisuus, kuinhan koodaaja ymmärtää, että se {$R } ei ole olemassa siksi, että se jotenkin oikeuttaisi huolimattoman koodaustyön, vaan siksi, että jos kaikesta huolellisuuspyrkimyksestä huolimatta koodaaja tekee virheen, niin Delphi -ohjelmassa syntyy ERangeError -poikkeus, siinä missä C tai C -ohjelmassa vastaava koodausvirhe = katastofi, eli puskurin ylivuotohaavoittuvuus.

OpenSSL:ssä havaittiin vuonna 2014 HeartBleed -nimiseksi nimetty puskurin ylivuotohaavoittuvuus. Jos OpenSSL olisi alunperinkin tehty FreePascalilla, niin moista haavoittuvuutta ei olisi koskaan tapahtunut.

Mutta kun se välttämättä päätettiin kirjoittaa C:llä, vaikka FreePascal olisi ollut kaikilta osiltaan parempi vaihtoehto, niin tuo haavoittuvuus ei tule jäämään viimeiseksi, vaan tulevaisuudessa niitä haavoittuvuuksia löytyy lisääkin.

Kuinkahan kauan rikolliset muuten hyödynsivät tuota HeartBleed -haavoittuvuutta ennen sen julkituloa? Entä kansalliset tiedustelupalvelut?

Vai siksikö noita koodataan C -kielellä, että nuo kansalliset tiedustelupalvelut voisivat jatkossakin löytää (ja hyödyntää) haavoittuvuuksia pitkäänkin, ennen kuin suuri yleisö saa tietää haavoittuvuuden olemassaolosta ?

C-kielen käyttö on siis kädenojennus kansallisille tiedustelupalveluille, että jatkossakin olisi haavoittuvuuksia heidän hyväksikäytettäväksi (ja samalla myös rikollisten).

Jos oikeasti haluttaisiin parempaa tietoturvaa, niin C ja C pitäisi hylätä kokonaan ja siirtyä FreePascaliin niiden sijasta.


***

Lue lisää

"* systeemitason kirjastoihin (DLL)"

.dll on jaettu kirjasto mitä käytetään Windowsissa.

Nykypäivänä tehtäessä jaettuja, natiivisti toimiva kirjastoja, ne ovat lähes aina linuxeissa toimivia .so -tiedostoja, eli "shared object". Eli joko kehitetään itse alustaa tai sitten tehdään jotain sulautetumpaa ja jaetaan joku komponentti usealle prosessille.

Windowsia ei enää käytetä niissä hommissa missä tarvitaan jaettuja kirjastoja.

"* käyttöliittymiin (laadukas käyttöliittymä ja on helppo toteuttaa)"

Yhtään esimerkkiä Delphillä tehdystä laadukkaasta käyttöliittymästä ei löydy. Kaikki laadukkaat käyttöliittymät kun ovat alustariippumattomia että sama käyttöliittymä toimii natiivisti iOS ja Android, tai selaimella.

"* taustajärjestelmiin"

Yhtään esimerkkiä Delphillä tehdystä laadukkaasta taustajärjestelmästä ei löydy. Pitäisi saada kontitettua Kubernetesilla tai Dockerilla Linux-palvelimissa.

"* turvallisuuskriittisiin kohteisiin"

Turvallisuuskriittisiin kohteisiin ohjelmien tekeminen on reguloitua ja edellytetään sertfiointeja. Delphillä ei onnistu. Jos vaikka tekee lentokoneen ohjelmistot Delphillä niin sellaisella lentokoneella ei saa lentää.

"* ajureihin"
"* kerneliin"

Ja kuitenkaan FreePascalia ei käytetä näissä. Yksinkertaisesti vaikka siksi, että ei haluta monimutkaistaa vaan käännetään kaikki samalla kääntäjällä.

"Lisäksi kannattaa huomata: vaikka Delphi ei varsinaisiin laiteajureihin sovellukaan, niin usein ei edes tarvitse kirjoittaa varsinaista laiteajuria, vaan voi koodata Delphillä DLL:n , joka itse käyttää esim. FTDI:n laiteajureita (jotka voi ilmaiseksi imuroida FTDI:n nettisivulta)."

No miten saat sen vaikka Rasbianiin? Muista, että Windowsia ei käytetä missään missä ohjaillaan laitteita omilla laiteajureilla. Sitä varten laitetaan Arduino tai Raspberry Pi ja siellä yleensä joku Linuxia käyttävä tai vaikka FreeBSD/OpenBSD.

"macOS:llä ei ole käytännön merkitystä. Vähemmistökäyttis, miksi sille pitäisi koodata mitään ?"

Aika monilla ihmisillä on läppäreitä. Apple valmistaa maailman suosituimpia läppärimalleja missä on macOS, joten käyttöliittymän pitää tietysti toimia macOS:ssa. Muuten käyttöliittymä on paska.

"Ja turvallisuuskriittisiin kohteisiin Delphi on parempi valinta kuin C tai C ."

Ei ole kun puuttuu vaadittavat sertifioinnit. Jää tyyppihyväksynnät saamatta. Delphille ei edes ole mahdollista saada niitä sertifiointeja kun lähdekoodeja ei löydy.

C-kielelle löytyy kääntäjiä joita voi käyttää. C :aa on mahdollista käyttää rajoitetusti, joutuu nimittäin kytkemään pois läjäpäin toimintoja että käytetään kielestä rajatumpaa versiota.

Ja vaikka toimisi kohteissa missä ei tarvita tyyppihyväksyntää, tai jos haluaa jollain muulla kielellä toteuttaa koodia mihin tarvitsee luvat silloinkin Delphi on kelvoton kun löytyy vaikka jotain pointtereita ja muuta typerää. Tuollaisissa tilanteissa valitaan ennemmin joku vahvasti tyypitetty funktionaalinen kieli joihin saa työkaluja formaaliin todistamiseen. Delphille ne puuttuvat.

"Vai siksikö noita koodataan C -kielellä, että nuo kansalliset tiedustelupalvelut voisivat jatkossakin löytää (ja hyödyntää) haavoittuvuuksia pitkäänkin, ennen kuin suuri yleisö saa tietää haavoittuvuuden olemassaolosta ?"

OpenSSL koodattu C-kielellä koska silloin kun se tehtiin, ei ollut olemassa parempia. Sen kirjaston kun piti kääntyä kaikissa käyttöjärjestelmissä. Yleisesti saatavilla olevilla kääntäjillä ja piti olla hyväksyttävissä osaksi käyttöjärjestelmiä ja oltava käytettävissä lukemattomissa sovelluksissa. FreePascal oli vuonna 1998 täysin keskeneräinen ja kaikki unixit käännettiin näiden omilla C-kääntäjillä, kokonaan. Täysin älyvapaa idea tunkea jotain beetavaiheen Pascalia noin keskeiseen kirjastoon.

C-kieli tehtiin unixin kehitystä varten, ja oli alusta saakka sementoitu niin vahvasti siihen että kaikki kirjastot ja matalan tason koodi tehty sillä. Millään muulla ei ole ollut mitään sijaa tässä 50-vuoden aikana käytännössä. C-kieli on käyttöjärjestelmien matalan tason defacto standardi. Jotain C :aa käytetty myös rajoitetusti.

Oikeasti vasta hiljattain on tullut uusi kieli korvaamaan matalan tason juttuja ja sitä rakennetaan hitaasti hartaasti kernelistä ja kääntäjästä lähtien koko pino, ja siinä keskeisenä ideana on varmistua siitä että koodiin on mahdollisimman vaikeata saada virheitä ja että todistetaan virheettämyys. Sitä on suunnattu sinne turvallisuuskriittisiin kohteisiin: https://cakeml.org/

Eikä tuolla paljoa tee muualla mitään kun käytännössä pitää rakentaa noiden olemassa olevien palikoiden ja työkalujen varaan koodia, että on hygieniaa koodiin mitä ei ole formaalisti verifioitu. Tuo lienee tällä hetkellä helpoin tapa saada sertifioimattomalle koodille luvat. Paitsi ydinvoimalassa sekään ei käy vaikka koodi on teknisesti virheetöntä. Siellä kun edellytetään laatusertifiointien ohella salassa pidettyä toteutusta. ESA ja NASA sitten sopivat paremmin tuollaisen käyttäjiksi ettei tule 100 miljoonan euron vahinkoja jonkun bugin takia.

Anonyymi kirjoitti:

"* systeemitason kirjastoihin (DLL)"

.dll on jaettu kirjasto mitä käytetään Windowsissa.

Nykypäivänä tehtäessä jaettuja, natiivisti toimiva kirjastoja, ne ovat lähes aina linuxeissa toimivia .so -tiedostoja, eli "shared object". Eli joko kehitetään itse alustaa tai sitten tehdään jotain sulautetumpaa ja jaetaan joku komponentti usealle prosessille.

Windowsia ei enää käytetä niissä hommissa missä tarvitaan jaettuja kirjastoja.

"* käyttöliittymiin (laadukas käyttöliittymä ja on helppo toteuttaa)"

Yhtään esimerkkiä Delphillä tehdystä laadukkaasta käyttöliittymästä ei löydy. Kaikki laadukkaat käyttöliittymät kun ovat alustariippumattomia että sama käyttöliittymä toimii natiivisti iOS ja Android, tai selaimella.

"* taustajärjestelmiin"

Yhtään esimerkkiä Delphillä tehdystä laadukkaasta taustajärjestelmästä ei löydy. Pitäisi saada kontitettua Kubernetesilla tai Dockerilla Linux-palvelimissa.

"* turvallisuuskriittisiin kohteisiin"

Turvallisuuskriittisiin kohteisiin ohjelmien tekeminen on reguloitua ja edellytetään sertfiointeja. Delphillä ei onnistu. Jos vaikka tekee lentokoneen ohjelmistot Delphillä niin sellaisella lentokoneella ei saa lentää.

"* ajureihin"
"* kerneliin"

Ja kuitenkaan FreePascalia ei käytetä näissä. Yksinkertaisesti vaikka siksi, että ei haluta monimutkaistaa vaan käännetään kaikki samalla kääntäjällä.

"Lisäksi kannattaa huomata: vaikka Delphi ei varsinaisiin laiteajureihin sovellukaan, niin usein ei edes tarvitse kirjoittaa varsinaista laiteajuria, vaan voi koodata Delphillä DLL:n , joka itse käyttää esim. FTDI:n laiteajureita (jotka voi ilmaiseksi imuroida FTDI:n nettisivulta)."

No miten saat sen vaikka Rasbianiin? Muista, että Windowsia ei käytetä missään missä ohjaillaan laitteita omilla laiteajureilla. Sitä varten laitetaan Arduino tai Raspberry Pi ja siellä yleensä joku Linuxia käyttävä tai vaikka FreeBSD/OpenBSD.

"macOS:llä ei ole käytännön merkitystä. Vähemmistökäyttis, miksi sille pitäisi koodata mitään ?"

Aika monilla ihmisillä on läppäreitä. Apple valmistaa maailman suosituimpia läppärimalleja missä on macOS, joten käyttöliittymän pitää tietysti toimia macOS:ssa. Muuten käyttöliittymä on paska.

"Ja turvallisuuskriittisiin kohteisiin Delphi on parempi valinta kuin C tai C ."

Ei ole kun puuttuu vaadittavat sertifioinnit. Jää tyyppihyväksynnät saamatta. Delphille ei edes ole mahdollista saada niitä sertifiointeja kun lähdekoodeja ei löydy.

C-kielelle löytyy kääntäjiä joita voi käyttää. C :aa on mahdollista käyttää rajoitetusti, joutuu nimittäin kytkemään pois läjäpäin toimintoja että käytetään kielestä rajatumpaa versiota.

Ja vaikka toimisi kohteissa missä ei tarvita tyyppihyväksyntää, tai jos haluaa jollain muulla kielellä toteuttaa koodia mihin tarvitsee luvat silloinkin Delphi on kelvoton kun löytyy vaikka jotain pointtereita ja muuta typerää. Tuollaisissa tilanteissa valitaan ennemmin joku vahvasti tyypitetty funktionaalinen kieli joihin saa työkaluja formaaliin todistamiseen. Delphille ne puuttuvat.

"Vai siksikö noita koodataan C -kielellä, että nuo kansalliset tiedustelupalvelut voisivat jatkossakin löytää (ja hyödyntää) haavoittuvuuksia pitkäänkin, ennen kuin suuri yleisö saa tietää haavoittuvuuden olemassaolosta ?"

OpenSSL koodattu C-kielellä koska silloin kun se tehtiin, ei ollut olemassa parempia. Sen kirjaston kun piti kääntyä kaikissa käyttöjärjestelmissä. Yleisesti saatavilla olevilla kääntäjillä ja piti olla hyväksyttävissä osaksi käyttöjärjestelmiä ja oltava käytettävissä lukemattomissa sovelluksissa. FreePascal oli vuonna 1998 täysin keskeneräinen ja kaikki unixit käännettiin näiden omilla C-kääntäjillä, kokonaan. Täysin älyvapaa idea tunkea jotain beetavaiheen Pascalia noin keskeiseen kirjastoon.

C-kieli tehtiin unixin kehitystä varten, ja oli alusta saakka sementoitu niin vahvasti siihen että kaikki kirjastot ja matalan tason koodi tehty sillä. Millään muulla ei ole ollut mitään sijaa tässä 50-vuoden aikana käytännössä. C-kieli on käyttöjärjestelmien matalan tason defacto standardi. Jotain C :aa käytetty myös rajoitetusti.

Oikeasti vasta hiljattain on tullut uusi kieli korvaamaan matalan tason juttuja ja sitä rakennetaan hitaasti hartaasti kernelistä ja kääntäjästä lähtien koko pino, ja siinä keskeisenä ideana on varmistua siitä että koodiin on mahdollisimman vaikeata saada virheitä ja että todistetaan virheettämyys. Sitä on suunnattu sinne turvallisuuskriittisiin kohteisiin: https://cakeml.org/

Eikä tuolla paljoa tee muualla mitään kun käytännössä pitää rakentaa noiden olemassa olevien palikoiden ja työkalujen varaan koodia, että on hygieniaa koodiin mitä ei ole formaalisti verifioitu. Tuo lienee tällä hetkellä helpoin tapa saada sertifioimattomalle koodille luvat. Paitsi ydinvoimalassa sekään ei käy vaikka koodi on teknisesti virheetöntä. Siellä kun edellytetään laatusertifiointien ohella salassa pidettyä toteutusta. ESA ja NASA sitten sopivat paremmin tuollaisen käyttäjiksi ettei tule 100 miljoonan euron vahinkoja jonkun bugin takia.

Lue lisää

""Ja turvallisuuskriittisiin kohteisiin Delphi on parempi valinta kuin C tai C ."

Ei ole kun puuttuu vaadittavat sertifioinnit. Jää tyyppihyväksynnät saamatta. "

Vaikkapa lentokoneen ohjausjärjestelmästä:

Koodaapa omasi C -kielellä, minä koodaan omani siten, että lopullinen käännös tehdään Freepascalilla, mutta kehitysvaiheessa varaan oikeuden käyttää sekä Delphiä (windowsille) että Kylixiä (Linuxin vanhalle versiolle).

Veikkaanpa, että se C-kielellä koodattu versio aiheuttaa jossain vaiheessa vakavan onnettomuuden, FreePascal versio sensijaan toimii hyvin.

Jos jokin sertifiointitaho todella on sellainen, että hyväksyvät C-kielellä tehdyn toteutuksen, mutta eivät Freepascalilla käännettyä, niin hulluja ovat -> toivottavasti päätyvät itse siihen koneeseen, joka putoaa, koska C -koodaaja on tehnyt sellaisen virheen, jota Freepascalilla koodaaja ei olisi koskaan tehnyt.

Kirjoituksessa oli muitakin virheitä, muun muassa väitettiin, ettei laitepohjaimia tehdä windowsille !

Omassa WINDOWS -koneessani on esim. hiiri, näppäimistö, ja tulostin, ja kaikille noille on laiteohjaimet.

Jos haluaisin vaikkapa mitata jotakin jännitettä siten, että sovellusohjelma (WINDOWSissa toimiva) sen jännitteen mittaustuloksen saa automaattisesti, niin esim yhdistelmällä:

Mikrokontrolleri (Atmel AVR ATmega328) FTDI:n muunnosmikropiiri, mikä liitetään joko 5V tai 3,3V logiikkatasoilla ATmega328:aan (eri versio FTDI -piiristä), ja USB -liittimen kautta PC -tietokoneeseen.

Ohjelmistopuoli PC -tietokoneessa:

FTDI:n laiteajuri ja...

JOKO:

käytetään sarjaporttiemulointia, jolloin esim. SynaSer (nykyisin osa Synapse -luokkakirjastoa) Delphi mahdollistaa keskustelun mikrokontrollerin kanssa suoraan Delphi -ohjelmasta (välittäjänä toimii FTDI -laiteajuri asennettuna windowsiin sekä FTDI -mikropiiri).

TAI:

Jos ei haluta käyttää sarjaporttiemulointia, niin FTDI:n laiteajuri ja FTDI:n tekemä DLL mahdollistaa sen oman API -rajapinnan käytön suoraan Delphi -ohjelmasta.

Näin Delphi soveltuu siis myös laiteläheiseen ohjelmointiin, eli sillä voi tehdä ohjelman, joka seuraa reaalimaailman suureita (esim. jännitettä) ja vastaavasti voi ohjata reaalimaailmaa tuon mikrokontrollerin välityksellä.

Tämäntyyppisissä sovelluksissa on aivan järjetöntä tehdä käyttöliittymää web -selaimessa toimivaksi, jollei moiseen ole jotakin erityistä tarvetta.

Oletuksena Delphin omat VCL -komponentit toimivat tässä hyvin.
Toki uudemmissa Delphi -versioissa löytyy sitten FireMonkey -komponentit jos perinteistä VCL -tyyliä ei jostain syystä haluta käyttää.

Toki Delphilläkin VOI tehdä selaimella toimivan käyttöliittymän, eli Delphi ohjelma toimii http -palvelimena. Se ei vain yleensä ole tarpeen, mutta mahdollista se on , JOS siihen on jokin erityinen tarve, mutta 99% tapauksista tällaista tarvetta ei ole.

Jos suunnittelisin vaikkapa varaustenhallintajärjestelmän lentoyhtiön käyttöön, niin Delphi sopisi tuohon mainiosti.

Vaativin osa suunnittelua olisi oikean tietokantajärjestelmän valinta.
Delphi toki osaa toimia niin PostgreSQL:n, MySQL:n, kuin myös kaupallisten Microsoft ja Oracle -tietokantojen kanssa.

Ennemminkin pulmaksi tulee se, että mistä tietää, mikä tietokanta on luotettavuudeltaan ja toimintavarmuudeltaan erinomainen ?

JOS tietokanta keksii omia aikojaan jumiutua tai seota, niin ongelma pitäisi saada nopeasti ratkaistua, sillä toimimaton taustajärjestelmä aiheuttaisi lentoyhtiölle jättitappiot, ja pitkään jatkuessaan tilanne ajaisi lentoyhtiön konkurssiin.

Tässäkin: Kunhan tietokanta on laadukas, niin Delphi soveltuu tähänkin paremmin kuin esim. Java.

Java ohjelmassahan tilanne on tämä:

Kun Java -ajoympäristö (JVM) päättää, että on aika tehdä muistinsiivousajo, niin tuon muistinsiivousajon aikana koko systeemi on täysin jumissa siihen asti, kunnes se muistinsiivousajo on valmis.

Mietipä tilannetta: Olet töissä lentoyhtiön lähtöselvitystiskillä.

Asiakas eli matkustaja tulee laukkuineen lähtöselvitystiskille ja ojentaa sinulle passinsa ja paperikopion lentolipustaan:

Kun yrität tarkistaa lentolipun tietoja tietokoneella, niin juuri silloin joko oman koneesi tai jonkin taustajärjestelmän JAVAlle tehty koodi liipaisee em. muistinsiivousajon käyntiin. Sitten voit vain odottaa, että se muistinsiivousajo tulisi valmiiksi, mitään muuta et voi tehdä.

Jos sekin systeemi olisi koodattu Delphillä, tätäkään ongelmaa ei olisi.

Anonyymi kirjoitti:

""Ja turvallisuuskriittisiin kohteisiin Delphi on parempi valinta kuin C tai C ."

Ei ole kun puuttuu vaadittavat sertifioinnit. Jää tyyppihyväksynnät saamatta. "

Vaikkapa lentokoneen ohjausjärjestelmästä:

Koodaapa omasi C -kielellä, minä koodaan omani siten, että lopullinen käännös tehdään Freepascalilla, mutta kehitysvaiheessa varaan oikeuden käyttää sekä Delphiä (windowsille) että Kylixiä (Linuxin vanhalle versiolle).

Veikkaanpa, että se C-kielellä koodattu versio aiheuttaa jossain vaiheessa vakavan onnettomuuden, FreePascal versio sensijaan toimii hyvin.

Jos jokin sertifiointitaho todella on sellainen, että hyväksyvät C-kielellä tehdyn toteutuksen, mutta eivät Freepascalilla käännettyä, niin hulluja ovat -> toivottavasti päätyvät itse siihen koneeseen, joka putoaa, koska C -koodaaja on tehnyt sellaisen virheen, jota Freepascalilla koodaaja ei olisi koskaan tehnyt.

Kirjoituksessa oli muitakin virheitä, muun muassa väitettiin, ettei laitepohjaimia tehdä windowsille !

Omassa WINDOWS -koneessani on esim. hiiri, näppäimistö, ja tulostin, ja kaikille noille on laiteohjaimet.

Jos haluaisin vaikkapa mitata jotakin jännitettä siten, että sovellusohjelma (WINDOWSissa toimiva) sen jännitteen mittaustuloksen saa automaattisesti, niin esim yhdistelmällä:

Mikrokontrolleri (Atmel AVR ATmega328) FTDI:n muunnosmikropiiri, mikä liitetään joko 5V tai 3,3V logiikkatasoilla ATmega328:aan (eri versio FTDI -piiristä), ja USB -liittimen kautta PC -tietokoneeseen.

Ohjelmistopuoli PC -tietokoneessa:

FTDI:n laiteajuri ja...

JOKO:

käytetään sarjaporttiemulointia, jolloin esim. SynaSer (nykyisin osa Synapse -luokkakirjastoa) Delphi mahdollistaa keskustelun mikrokontrollerin kanssa suoraan Delphi -ohjelmasta (välittäjänä toimii FTDI -laiteajuri asennettuna windowsiin sekä FTDI -mikropiiri).

TAI:

Jos ei haluta käyttää sarjaporttiemulointia, niin FTDI:n laiteajuri ja FTDI:n tekemä DLL mahdollistaa sen oman API -rajapinnan käytön suoraan Delphi -ohjelmasta.

Näin Delphi soveltuu siis myös laiteläheiseen ohjelmointiin, eli sillä voi tehdä ohjelman, joka seuraa reaalimaailman suureita (esim. jännitettä) ja vastaavasti voi ohjata reaalimaailmaa tuon mikrokontrollerin välityksellä.

Tämäntyyppisissä sovelluksissa on aivan järjetöntä tehdä käyttöliittymää web -selaimessa toimivaksi, jollei moiseen ole jotakin erityistä tarvetta.

Oletuksena Delphin omat VCL -komponentit toimivat tässä hyvin.
Toki uudemmissa Delphi -versioissa löytyy sitten FireMonkey -komponentit jos perinteistä VCL -tyyliä ei jostain syystä haluta käyttää.

Toki Delphilläkin VOI tehdä selaimella toimivan käyttöliittymän, eli Delphi ohjelma toimii http -palvelimena. Se ei vain yleensä ole tarpeen, mutta mahdollista se on , JOS siihen on jokin erityinen tarve, mutta 99% tapauksista tällaista tarvetta ei ole.

Jos suunnittelisin vaikkapa varaustenhallintajärjestelmän lentoyhtiön käyttöön, niin Delphi sopisi tuohon mainiosti.

Vaativin osa suunnittelua olisi oikean tietokantajärjestelmän valinta.
Delphi toki osaa toimia niin PostgreSQL:n, MySQL:n, kuin myös kaupallisten Microsoft ja Oracle -tietokantojen kanssa.

Ennemminkin pulmaksi tulee se, että mistä tietää, mikä tietokanta on luotettavuudeltaan ja toimintavarmuudeltaan erinomainen ?

JOS tietokanta keksii omia aikojaan jumiutua tai seota, niin ongelma pitäisi saada nopeasti ratkaistua, sillä toimimaton taustajärjestelmä aiheuttaisi lentoyhtiölle jättitappiot, ja pitkään jatkuessaan tilanne ajaisi lentoyhtiön konkurssiin.

Tässäkin: Kunhan tietokanta on laadukas, niin Delphi soveltuu tähänkin paremmin kuin esim. Java.

Java ohjelmassahan tilanne on tämä:

Kun Java -ajoympäristö (JVM) päättää, että on aika tehdä muistinsiivousajo, niin tuon muistinsiivousajon aikana koko systeemi on täysin jumissa siihen asti, kunnes se muistinsiivousajo on valmis.

Mietipä tilannetta: Olet töissä lentoyhtiön lähtöselvitystiskillä.

Asiakas eli matkustaja tulee laukkuineen lähtöselvitystiskille ja ojentaa sinulle passinsa ja paperikopion lentolipustaan:

Kun yrität tarkistaa lentolipun tietoja tietokoneella, niin juuri silloin joko oman koneesi tai jonkin taustajärjestelmän JAVAlle tehty koodi liipaisee em. muistinsiivousajon käyntiin. Sitten voit vain odottaa, että se muistinsiivousajo tulisi valmiiksi, mitään muuta et voi tehdä.

Jos sekin systeemi olisi koodattu Delphillä, tätäkään ongelmaa ei olisi.

Lue lisää

"Koodaapa omasi C -kielellä, minä koodaan omani siten, että lopullinen käännös tehdään Freepascalilla, mutta kehitysvaiheessa varaan oikeuden käyttää sekä Delphiä (windowsille) että Kylixiä (Linuxin vanhalle versiolle)."

Lentokoneen ohjausjärjestelmissä ei saa käyttää mitään Windowsia, eikä mitään Linuxia. Koodi jota käännetään sinne ei myöskään saa olla Pascalia kun yhtään Pascal kääntäjää ei ole olemassa millä olisi sertifioinnit. Ainoastaan C, Ada, rajoitettu C , Spark ja rajoitettu Java ovat mahdollisia. CakeML on ainoa jonka järjellisellä vaivalla voisi saada luvalliseksi.

"Veikkaanpa, että se C-kielellä koodattu versio aiheuttaa jossain vaiheessa vakavan onnettomuuden, FreePascal versio sensijaan toimii hyvin."

Väärin meni tämäkin. C-kielistä koodia voidaan verfioida formaalisti Haskellilla toteutettua specifikaatiota vasten. C-kielisen koodin virheettömyys on siis mahdollista varmistaa niin täydellisesti kuin mahdollista. Pascalille sellaiset puuttuu.

Pascalille ei sellaisia ole tulossakaan, sillä vuonna 1983 valmistui Ada -kieli turvallisuuskriittisiin kohteisiin ja se laajennettiin Pascalin pohjalta erkaantuen omaksi kielekseen.

"Jos jokin sertifiointitaho todella on sellainen, että hyväksyvät C-kielellä tehdyn toteutuksen, mutta eivät Freepascalilla käännettyä, niin hulluja ovat"

Ei laisinkaan. Katsos kun on se formaali verifiointi että voidaan todistaa virheettömäksi.

"Omassa WINDOWS -koneessani on esim. hiiri, näppäimistö, ja tulostin, ja kaikille noille on laiteohjaimet."

Hiiri ja näppäimistö ovat standardisoituja, että ne eivät tarvitse mitään ajureita. Tulostimille sellaisia vielä on (mutta ei välttämättä tarvitse) mutta ei tuollaista ohjelmointia käytännössä ole. Microsoft luopunut lähes täysin noista markkinoista että Windowsille kehitettäisiin laitteenohjauskoodia. Windows kun päivittyy, myös IoT versio, niin usein että se on käytännössä kelvoton.

Tulostimissa ne ajurit kuitenkin voi saattaa olla ja niiden syy on lähinnä suunnitellussa vanhenemisessa. Idea siis se, että tulostinvalmistaja tekee jonkun ns. kertakäyttöisen mustesuihkutulostimen missä mustekasestit ei kestä juuri mitään, uudet maksaa melkein yhtä paljon kuin uusi tulostin ja Windowsin päivittyminen rikkoo ajurit jossain kohtaa että pitää uusia se tulostin.

"Jos haluaisin vaikkapa mitata jotakin jännitettä siten, että sovellusohjelma (WINDOWSissa toimiva)"

Ja sitten Windows päivittyy niin voi lakata toimimasta. Siksi Windowsia ei näissä käytetä oikeastaan ikinä vaan käytetään jotain Arduinoa tai Raspberry Pi:tä ja tehdään se ajuri sinne johonkin vakaana pysyvään alustaan, ja tehdään sinne API sille jännitteen kyselylle. Sitten Windowsissa voidaan kysellä siltä API:lta sitä jännitettä.

Windowsissa noista laiteajurijutuista on luovuttu ajat sitten.

"Tämäntyyppisissä sovelluksissa on aivan järjetöntä tehdä käyttöliittymää web -selaimessa toimivaksi, jollei moiseen ole jotakin erityistä tarvetta."

Voit sinä sen käyttöliittymän tehdä .NET:n WinFormsilla, React:lla tai vaikka Delphillä jos siltä tuntuu mutta ne ajurit pitää saada pois siitä Windowsista että eivät ole rikki Windowsin päivittyessä.

Mutta silloinkin se selaimessa toimiva on kätevämpi kun ei tarvitse asennella mitään ohjelmaa vaan kun se Raspberry Pi hoitaa sen ajurin niin se voi samalla hostata sitä sovelluksen käyttöliittymää niin ei tarvitse tunkea sitä johonkin Windowsin storeen. Saako sinne Delphillä tehtyjä ohjelmia edes vietyä miten helposti?

"Jos suunnittelisin vaikkapa varaustenhallintajärjestelmän lentoyhtiön käyttöön, niin Delphi sopisi tuohon mainiosti."

Eli kun asiakas varaa lentomatkan selaimella lentoyhtiön nettisivulta tai jos asiakas ostaa jonkun pakettilomamatkan niin siellä on API jolla matkatoimisto voi hoitaa sen varausprosessin asiakkaalle.

Miten siis teet Delphillä sen käyttöliittymän sinne selaimeen helpoiten? Entä millä työkalulla käännät API:n specifikaation Delphikoodiksi vaikka sinne Amazonin Linux-palvelimeen tai sekä rakentaa API:n queryjen Delphikoodin selaimeen? Nuohan tehdään koneellisesti specifikaatiosta että ei tarvitse itse kirjoittaa niitä kahteen kertaan ja toimii sitten käyttöliittymät ja taustajärjestelmä yhteensopivina helposti.

"Vaativin osa suunnittelua olisi oikean tietokantajärjestelmän valinta."

No ei ole. Kirjoittaa koodin vaikka ORM:lla ja antaa sen abstraktoida. Se tietokanta on sitten vaihdettavissa toiseen. Onkos Delphissä nykyään joku vakio ORM että ei tarvitse ylläpitää riippuvuuksia johonkin lisäpalikkaan?

"Ennemminkin pulmaksi tulee se, että mistä tietää, mikä tietokanta on luotettavuudeltaan ja toimintavarmuudeltaan erinomainen ?"

PostgreSQL, MySQL, MSSQL ja Oraclen kanta ovat kaikki luotettavuudelta ja toimintavarmuudelta erinomaisia. Näiden erot tulee muualta.

Anonyymi kirjoitti:

""Ja turvallisuuskriittisiin kohteisiin Delphi on parempi valinta kuin C tai C ."

Ei ole kun puuttuu vaadittavat sertifioinnit. Jää tyyppihyväksynnät saamatta. "

Vaikkapa lentokoneen ohjausjärjestelmästä:

Koodaapa omasi C -kielellä, minä koodaan omani siten, että lopullinen käännös tehdään Freepascalilla, mutta kehitysvaiheessa varaan oikeuden käyttää sekä Delphiä (windowsille) että Kylixiä (Linuxin vanhalle versiolle).

Veikkaanpa, että se C-kielellä koodattu versio aiheuttaa jossain vaiheessa vakavan onnettomuuden, FreePascal versio sensijaan toimii hyvin.

Jos jokin sertifiointitaho todella on sellainen, että hyväksyvät C-kielellä tehdyn toteutuksen, mutta eivät Freepascalilla käännettyä, niin hulluja ovat -> toivottavasti päätyvät itse siihen koneeseen, joka putoaa, koska C -koodaaja on tehnyt sellaisen virheen, jota Freepascalilla koodaaja ei olisi koskaan tehnyt.

Kirjoituksessa oli muitakin virheitä, muun muassa väitettiin, ettei laitepohjaimia tehdä windowsille !

Omassa WINDOWS -koneessani on esim. hiiri, näppäimistö, ja tulostin, ja kaikille noille on laiteohjaimet.

Jos haluaisin vaikkapa mitata jotakin jännitettä siten, että sovellusohjelma (WINDOWSissa toimiva) sen jännitteen mittaustuloksen saa automaattisesti, niin esim yhdistelmällä:

Mikrokontrolleri (Atmel AVR ATmega328) FTDI:n muunnosmikropiiri, mikä liitetään joko 5V tai 3,3V logiikkatasoilla ATmega328:aan (eri versio FTDI -piiristä), ja USB -liittimen kautta PC -tietokoneeseen.

Ohjelmistopuoli PC -tietokoneessa:

FTDI:n laiteajuri ja...

JOKO:

käytetään sarjaporttiemulointia, jolloin esim. SynaSer (nykyisin osa Synapse -luokkakirjastoa) Delphi mahdollistaa keskustelun mikrokontrollerin kanssa suoraan Delphi -ohjelmasta (välittäjänä toimii FTDI -laiteajuri asennettuna windowsiin sekä FTDI -mikropiiri).

TAI:

Jos ei haluta käyttää sarjaporttiemulointia, niin FTDI:n laiteajuri ja FTDI:n tekemä DLL mahdollistaa sen oman API -rajapinnan käytön suoraan Delphi -ohjelmasta.

Näin Delphi soveltuu siis myös laiteläheiseen ohjelmointiin, eli sillä voi tehdä ohjelman, joka seuraa reaalimaailman suureita (esim. jännitettä) ja vastaavasti voi ohjata reaalimaailmaa tuon mikrokontrollerin välityksellä.

Tämäntyyppisissä sovelluksissa on aivan järjetöntä tehdä käyttöliittymää web -selaimessa toimivaksi, jollei moiseen ole jotakin erityistä tarvetta.

Oletuksena Delphin omat VCL -komponentit toimivat tässä hyvin.
Toki uudemmissa Delphi -versioissa löytyy sitten FireMonkey -komponentit jos perinteistä VCL -tyyliä ei jostain syystä haluta käyttää.

Toki Delphilläkin VOI tehdä selaimella toimivan käyttöliittymän, eli Delphi ohjelma toimii http -palvelimena. Se ei vain yleensä ole tarpeen, mutta mahdollista se on , JOS siihen on jokin erityinen tarve, mutta 99% tapauksista tällaista tarvetta ei ole.

Jos suunnittelisin vaikkapa varaustenhallintajärjestelmän lentoyhtiön käyttöön, niin Delphi sopisi tuohon mainiosti.

Vaativin osa suunnittelua olisi oikean tietokantajärjestelmän valinta.
Delphi toki osaa toimia niin PostgreSQL:n, MySQL:n, kuin myös kaupallisten Microsoft ja Oracle -tietokantojen kanssa.

Ennemminkin pulmaksi tulee se, että mistä tietää, mikä tietokanta on luotettavuudeltaan ja toimintavarmuudeltaan erinomainen ?

JOS tietokanta keksii omia aikojaan jumiutua tai seota, niin ongelma pitäisi saada nopeasti ratkaistua, sillä toimimaton taustajärjestelmä aiheuttaisi lentoyhtiölle jättitappiot, ja pitkään jatkuessaan tilanne ajaisi lentoyhtiön konkurssiin.

Tässäkin: Kunhan tietokanta on laadukas, niin Delphi soveltuu tähänkin paremmin kuin esim. Java.

Java ohjelmassahan tilanne on tämä:

Kun Java -ajoympäristö (JVM) päättää, että on aika tehdä muistinsiivousajo, niin tuon muistinsiivousajon aikana koko systeemi on täysin jumissa siihen asti, kunnes se muistinsiivousajo on valmis.

Mietipä tilannetta: Olet töissä lentoyhtiön lähtöselvitystiskillä.

Asiakas eli matkustaja tulee laukkuineen lähtöselvitystiskille ja ojentaa sinulle passinsa ja paperikopion lentolipustaan:

Kun yrität tarkistaa lentolipun tietoja tietokoneella, niin juuri silloin joko oman koneesi tai jonkin taustajärjestelmän JAVAlle tehty koodi liipaisee em. muistinsiivousajon käyntiin. Sitten voit vain odottaa, että se muistinsiivousajo tulisi valmiiksi, mitään muuta et voi tehdä.

Jos sekin systeemi olisi koodattu Delphillä, tätäkään ongelmaa ei olisi.

Lue lisää

"Kun Java -ajoympäristö (JVM) päättää, että on aika tehdä muistinsiivousajo, niin tuon muistinsiivousajon aikana koko systeemi on täysin jumissa siihen asti, kunnes se muistinsiivousajo on valmis."

Paitsi että ei ole. Vain se prosessi missä se JVM on, voi pysähtyä hetkeksi ja sekin on optimoitu.

"Kun yrität tarkistaa lentolipun tietoja tietokoneella, niin juuri silloin joko oman koneesi tai jonkin taustajärjestelmän JAVAlle tehty koodi liipaisee em. muistinsiivousajon käyntiin. Sitten voit vain odottaa, että se muistinsiivousajo tulisi valmiiksi, mitään muuta et voi tehdä."

Helposti jokainen service sisältää oman sulautetun Tomcatin ja ajetaan omassa prosessissa, että muistinsiivousajo on vain per palvelu.

Sen lisäksi vähänkään kriittisessä kohteessa ne palvelut on kahdennettu vähintään kahdelle eri palvelimille, että kyselyjä kun tehdään niin ne ohjautuvat useammalle palvelimelle. Jokainen palvelu itseasiassa voidaan vaikka ajaa usealla fyysisellä serverillä jos niin halutaan mutta noin yksinkertaisissa sovelluksissa tuota ongelmaa tuskin tulee. Pointti siis on se, että sovellusten logiikkaa ajaa kaksi tai useampi palvelinta ja kannat sitten on vielä on erillään. Garbage collection ei oikeasti aiheuta jossain varaustenhallintajärjestelmässä mitään ongelmaa.

Suurempi huomionaihe on oikeastaan tietokantojen suunnittelu. Jos suinkin mahdollista niin palastelee eri palveluille omat tietokannat että niitä voi hajauttaa myös usealle palvelimelle. Helpommin joutuu odottelemaan tietokantaa kuin vaikka viidellä serverillä olevaa bisneslogiikkaa.

Sen lisäksi, kohteissa joissa ei saa suoritus katketa, kuten vaikka lentokone, on olemassa se reaaliaika versio Javasta.

Anonyymi kirjoitti:

"Kun Java -ajoympäristö (JVM) päättää, että on aika tehdä muistinsiivousajo, niin tuon muistinsiivousajon aikana koko systeemi on täysin jumissa siihen asti, kunnes se muistinsiivousajo on valmis."

Paitsi että ei ole. Vain se prosessi missä se JVM on, voi pysähtyä hetkeksi ja sekin on optimoitu.

"Kun yrität tarkistaa lentolipun tietoja tietokoneella, niin juuri silloin joko oman koneesi tai jonkin taustajärjestelmän JAVAlle tehty koodi liipaisee em. muistinsiivousajon käyntiin. Sitten voit vain odottaa, että se muistinsiivousajo tulisi valmiiksi, mitään muuta et voi tehdä."

Helposti jokainen service sisältää oman sulautetun Tomcatin ja ajetaan omassa prosessissa, että muistinsiivousajo on vain per palvelu.

Sen lisäksi vähänkään kriittisessä kohteessa ne palvelut on kahdennettu vähintään kahdelle eri palvelimille, että kyselyjä kun tehdään niin ne ohjautuvat useammalle palvelimelle. Jokainen palvelu itseasiassa voidaan vaikka ajaa usealla fyysisellä serverillä jos niin halutaan mutta noin yksinkertaisissa sovelluksissa tuota ongelmaa tuskin tulee. Pointti siis on se, että sovellusten logiikkaa ajaa kaksi tai useampi palvelinta ja kannat sitten on vielä on erillään. Garbage collection ei oikeasti aiheuta jossain varaustenhallintajärjestelmässä mitään ongelmaa.

Suurempi huomionaihe on oikeastaan tietokantojen suunnittelu. Jos suinkin mahdollista niin palastelee eri palveluille omat tietokannat että niitä voi hajauttaa myös usealle palvelimelle. Helpommin joutuu odottelemaan tietokantaa kuin vaikka viidellä serverillä olevaa bisneslogiikkaa.

Sen lisäksi, kohteissa joissa ei saa suoritus katketa, kuten vaikka lentokone, on olemassa se reaaliaika versio Javasta.

Lue lisää

"Kun Java -ajoympäristö (JVM) päättää, että on aika tehdä muistinsiivousajo, niin tuon muistinsiivousajon aikana koko systeemi on täysin jumissa siihen asti, kunnes se muistinsiivousajo on valmis."

Paitsi että ei ole. "

Ja M-Kar valehtelee jälleen !

Hyvä esimerkki laadultaan heikosta palvelusta, joka on tehty JAVAlla, löytyy täältä:

http://siirretytnumerot.fi/

Aina, kun tuohon palveluun tulee lyhyen ajan sisällä paljon kyselyitä, niin palvelu menee jumiin, eli kun JVM (Java -ohjelman tarvitsema virtuaalinen JAVA -kone) käynnistää ns. roskienkeruuajon, niin sillä aikaa, kun ns. roskienkeruuta tehdään, niin tuo palvelu ei toimi.

Jos vastaava olisi tehty Delphillä, sen toimivuus olisi erinomainen, se toimisi aina, ja mitään roskienkeruuajojen aiheuttamia katkoksia ei olisi.

Aikaisemmin, kun sokeiden oikeuksia ei loukattu (kuten tänä päivänä vammaislain vastaisesti tehdään), sama palvelu oli saatavissa myös ilmaisnumeroon 0800 0 2202 soittamalla; mutta ikävä kyllä samaa JAVAlla tehtyä taustajärjestelmää oli käytetty sekä netti- että puhelinpalveluun, eli kun JAVA -taustajärjestelmään tuli häiriö, se rikkoi samalla sekä netti- että puhelinpalvelun.

Mutta M-Karin mielestä JAVAlla tehty helposti rikkoutuva palvelu on varmaankin tehty "siistimmin" kuib vastaava Delphillä tehty, aina moitteettomasti tehty palvelu.

Delphillä tehdyn ohjelmiston osalta suurimpia ongelmien syitä ovat:

1) Sähkökatkos

2) Laitevika tietokoneessa

3) Tietoliikennehäiriöt

4) Tietokannan huonon laadun aiheuttamat ongelmat

Jos koodaan Delphi -ohjelman niin, että se ei käytä tietokantoja, vaan olen itse koodannut kaiken perinteisten tiedostojen varaan, niin luotettavauus on heti huomattavasti parempi kuin muuten vastaava ohjelma, joka käyttää tietokantoja.

tietokannat ovatkin monen ohjelmiston ns. akilleen kantapää, eli heikkolaatuinen tietokantajärjestelmä aiheuttaa koko ohjelman toimimattomuutta.

Eli M-Kar kuvittelee, ettei JAVA -ohjelma jumiutuisi täysin, kun roskiensiivousajo alkaa.

Tosiasia: JAVA -ohjelmat jumiutuvat aina, kun roskiensiivousajo alkaa.
Tämä on Java -ohjelmien normaali tapa toimia. Jos on Javalla tehty ohjelma, niin sellaista käyttävällä firmalla on tasan 2 vaihtoehtoa:

1) Hyväksytään se, että aina välillä ohjelma on jumissa, kun JVM tekee niitä roskiensiivousajojaan

tai

2) koodataan ohjelma uusiksi Delphillä. Samalla päästään eroon JAVA:lle tyypillisestä jumittelusta.

Anonyymi kirjoitti:

"Kun Java -ajoympäristö (JVM) päättää, että on aika tehdä muistinsiivousajo, niin tuon muistinsiivousajon aikana koko systeemi on täysin jumissa siihen asti, kunnes se muistinsiivousajo on valmis."

Paitsi että ei ole. "

Ja M-Kar valehtelee jälleen !

Hyvä esimerkki laadultaan heikosta palvelusta, joka on tehty JAVAlla, löytyy täältä:

http://siirretytnumerot.fi/

Aina, kun tuohon palveluun tulee lyhyen ajan sisällä paljon kyselyitä, niin palvelu menee jumiin, eli kun JVM (Java -ohjelman tarvitsema virtuaalinen JAVA -kone) käynnistää ns. roskienkeruuajon, niin sillä aikaa, kun ns. roskienkeruuta tehdään, niin tuo palvelu ei toimi.

Jos vastaava olisi tehty Delphillä, sen toimivuus olisi erinomainen, se toimisi aina, ja mitään roskienkeruuajojen aiheuttamia katkoksia ei olisi.

Aikaisemmin, kun sokeiden oikeuksia ei loukattu (kuten tänä päivänä vammaislain vastaisesti tehdään), sama palvelu oli saatavissa myös ilmaisnumeroon 0800 0 2202 soittamalla; mutta ikävä kyllä samaa JAVAlla tehtyä taustajärjestelmää oli käytetty sekä netti- että puhelinpalveluun, eli kun JAVA -taustajärjestelmään tuli häiriö, se rikkoi samalla sekä netti- että puhelinpalvelun.

Mutta M-Karin mielestä JAVAlla tehty helposti rikkoutuva palvelu on varmaankin tehty "siistimmin" kuib vastaava Delphillä tehty, aina moitteettomasti tehty palvelu.

Delphillä tehdyn ohjelmiston osalta suurimpia ongelmien syitä ovat:

1) Sähkökatkos

2) Laitevika tietokoneessa

3) Tietoliikennehäiriöt

4) Tietokannan huonon laadun aiheuttamat ongelmat

Jos koodaan Delphi -ohjelman niin, että se ei käytä tietokantoja, vaan olen itse koodannut kaiken perinteisten tiedostojen varaan, niin luotettavauus on heti huomattavasti parempi kuin muuten vastaava ohjelma, joka käyttää tietokantoja.

tietokannat ovatkin monen ohjelmiston ns. akilleen kantapää, eli heikkolaatuinen tietokantajärjestelmä aiheuttaa koko ohjelman toimimattomuutta.

Eli M-Kar kuvittelee, ettei JAVA -ohjelma jumiutuisi täysin, kun roskiensiivousajo alkaa.

Tosiasia: JAVA -ohjelmat jumiutuvat aina, kun roskiensiivousajo alkaa.
Tämä on Java -ohjelmien normaali tapa toimia. Jos on Javalla tehty ohjelma, niin sellaista käyttävällä firmalla on tasan 2 vaihtoehtoa:

1) Hyväksytään se, että aina välillä ohjelma on jumissa, kun JVM tekee niitä roskiensiivousajojaan

tai

2) koodataan ohjelma uusiksi Delphillä. Samalla päästään eroon JAVA:lle tyypillisestä jumittelusta.

Lue lisää

"Ja M-Kar valehtelee jälleen !"

Mikä?

"Hyvä esimerkki laadultaan heikosta palvelusta, joka on tehty JAVAlla, löytyy täältä:"

Mistä tiedät, että palvelu on tehty Javalla?

"Aina, kun tuohon palveluun tulee lyhyen ajan sisällä paljon kyselyitä, niin palvelu menee jumiin"

Tuollainen ei liity ohjelmointikieleen vaan siihen miten palvelu on toteutettu. Puuttuu esimerkiksi kahdennus.

"Jos vastaava olisi tehty Delphillä, sen toimivuus olisi erinomainen, se toimisi aina, ja mitään roskienkeruuajojen aiheuttamia katkoksia ei olisi."

Delphin heikkouksien takia sitä ei ole tähänkään palveluun valittu.

"sama palvelu oli saatavissa myös ilmaisnumeroon 0800 0 2202 soittamalla"

Koko palvelu vaikuttaa joltain vuoden 2003 viritelmältä. Siihen aikaan ei aina tehty normaaleja kahdennuksia kuten nyt.

"Delphillä tehdyn ohjelmiston osalta suurimpia ongelmien syitä ovat"

Tuollaisia ongelmia ei oikein ole Javalla tehdyissä palveluissa kun Javalla toimii normaalit laadukkaat tietokannat ja kahdennukset. On aivan normaalia, että tietokanta sekä sovellus ovat fyysisesti eri laitteissa, kahdennettuma. Eli yhtä palvelua hoitaa vaikka kaksi serveriä tietokannoille ja kaksi sille taustajärjestelmälle. On aivan normaalia, että välillä esimerkiksi uudelleenkäynnistetään tietokone niin kahdennus tekee sen, että mitään katkoksia ei ole.

"Jos koodaan Delphi -ohjelman niin, että se ei käytä tietokantoja, vaan olen itse koodannut kaiken perinteisten tiedostojen varaan"

Tietokantakin on tiedostoissa. Ne tiedostot vaan pitää tietenkin olla kahdella eri tietokoneella, että virtakatkokset eivät sotke palvelua. Lisäksi yhtä tiedostoa ei voi samanaikaisesti useampi käyttäjä muuttaa. Siinä kun on vaikka 100 megan tiedosto jota päivitetään yhden käyttäjän toimesta niin muut odottaa. Tuo jos mikä aiheuttaa jumittamista.

"Tosiasia: JAVA -ohjelmat jumiutuvat aina, kun roskiensiivousajo alkaa."

Miten se serverin 1 Java-ohjelman siivousajo vaikuttaa serverin 2 Java-ohjelmaan?

Tai edes samalla serverillä oleviin Java-ohjelmiin kun Javalla tehdyt palvelut käyttävät omaa Java-ajoympäristöjään? Kahdella serverillä voi siis olla 50 Javalla tehtyä palvelua käynnissä kahdennettuina ja yksittäisen roskienkeruu ei vaikuta millään tavalla kokonaisuuteen kun palvelut toki sisältävät oman välimuistinsa.

On aivan normaalia, että palvelun kuorman kasvaessa lisätään servereitä. On vaikka 5 serveriä taustajärjestelmälle, yksi kuorman tasaaja ja kaksi tietokannalle, että on sitten 8 serveriä. Ei tuollaisessa minkään yksittäisen microservicen roskien kerääjä tunnu missään.

Löytyy wrapper-kirjastot, joiden avulla ei parhaimmassa tapauksessa tarvitse muuttaa mitään. Joskus kokeilin kääntää koodia ja ainoat ongelmat olivat "C:\..." tyyppiset hakupolkumäärittelyt, jotka aikoinaan olin tehnyt koodiin. Nykyään en enää koodaisi samalla tavalla..
Keskeytykset ei ole ongelma, jos käytät fpc:tä dos:ssa(kuten borlandiakin):
https://www.freepascal.org/docs-html/rtl/go32/executinginterrupts.html
Sen sijaan linux-puolelle porttaaminen vaatii ymmärrystä siitä, miten keskeytysjärjestelmä linux-puolella toimii. Periaatteessa wrapperien kautta käytetyt keskeytykset ovat porttautuvia suoraan, mutta asm-blokin sisältä tehdyt on vähän eri juttu, pl. bios-kutsut. Muun muassa rekisterimäärittelyt on erit ja se miten keskeytyskäsittelijä koodataan, koska se on itse asiassa kernelin puolella. Saatat siis joutua kirjoittamaan jonkinlaisen driverin keskeytyskäsittelijällesi?
Assembler-blokkeja joutunee kanssa hiukan säätämään, koska borland tasm ei ole free-pascalissa käytetty assembler:
https://wiki.freepascal.org/Asm
-aika geneerinen asm se kuitenkin on ja itse asiassa tukee ainakin neljää eri murretta: standard, gas, intel ja att. Eli ei ole mahdoton saada toimimaan.
Toisekseen, en myöskään viitsi kirjoittaa precompiler-direktiivejä suoraan koodiin niiden sekavuuden takia vaan käytän mieluiten Lazarus-editorin kautta fpc:tä, jolloin se on "rasti ruutuun ja menoksi" tyyppinen ratkaisu. Tokihan sinne tulee sitten Lazaruksen konfigurointi-tiedosto mukaan, mutta IDE pitää huolen kääntäjäasetuksista.
Ja Lazarus-IDE tunnetusti on kirjoitettu lazaruksella eli fpc-kääntäjällä.

Anonyymi kirjoitti:

Löytyy wrapper-kirjastot, joiden avulla ei parhaimmassa tapauksessa tarvitse muuttaa mitään. Joskus kokeilin kääntää koodia ja ainoat ongelmat olivat "C:\..." tyyppiset hakupolkumäärittelyt, jotka aikoinaan olin tehnyt koodiin. Nykyään en enää koodaisi samalla tavalla..
Keskeytykset ei ole ongelma, jos käytät fpc:tä dos:ssa(kuten borlandiakin):
https://www.freepascal.org/docs-html/rtl/go32/executinginterrupts.html
Sen sijaan linux-puolelle porttaaminen vaatii ymmärrystä siitä, miten keskeytysjärjestelmä linux-puolella toimii. Periaatteessa wrapperien kautta käytetyt keskeytykset ovat porttautuvia suoraan, mutta asm-blokin sisältä tehdyt on vähän eri juttu, pl. bios-kutsut. Muun muassa rekisterimäärittelyt on erit ja se miten keskeytyskäsittelijä koodataan, koska se on itse asiassa kernelin puolella. Saatat siis joutua kirjoittamaan jonkinlaisen driverin keskeytyskäsittelijällesi?
Assembler-blokkeja joutunee kanssa hiukan säätämään, koska borland tasm ei ole free-pascalissa käytetty assembler:
https://wiki.freepascal.org/Asm
-aika geneerinen asm se kuitenkin on ja itse asiassa tukee ainakin neljää eri murretta: standard, gas, intel ja att. Eli ei ole mahdoton saada toimimaan.
Toisekseen, en myöskään viitsi kirjoittaa precompiler-direktiivejä suoraan koodiin niiden sekavuuden takia vaan käytän mieluiten Lazarus-editorin kautta fpc:tä, jolloin se on "rasti ruutuun ja menoksi" tyyppinen ratkaisu. Tokihan sinne tulee sitten Lazaruksen konfigurointi-tiedosto mukaan, mutta IDE pitää huolen kääntäjäasetuksista.
Ja Lazarus-IDE tunnetusti on kirjoitettu lazaruksella eli fpc-kääntäjällä.

Lue lisää

Jos jonkun vanhan koodin saa toimimaan niin voi olla järkevää kirjoittaa ulkoa päin ajettavia testejä läjä mihin mallintaa kaikki vaatimukset.

Sitten kirjoittaa sen koodin uusiksi nykyaikaisella välineellä niin saa sen sotkun pois.

Anonyymi kirjoitti:

Löytyy wrapper-kirjastot, joiden avulla ei parhaimmassa tapauksessa tarvitse muuttaa mitään. Joskus kokeilin kääntää koodia ja ainoat ongelmat olivat "C:\..." tyyppiset hakupolkumäärittelyt, jotka aikoinaan olin tehnyt koodiin. Nykyään en enää koodaisi samalla tavalla..
Keskeytykset ei ole ongelma, jos käytät fpc:tä dos:ssa(kuten borlandiakin):
https://www.freepascal.org/docs-html/rtl/go32/executinginterrupts.html
Sen sijaan linux-puolelle porttaaminen vaatii ymmärrystä siitä, miten keskeytysjärjestelmä linux-puolella toimii. Periaatteessa wrapperien kautta käytetyt keskeytykset ovat porttautuvia suoraan, mutta asm-blokin sisältä tehdyt on vähän eri juttu, pl. bios-kutsut. Muun muassa rekisterimäärittelyt on erit ja se miten keskeytyskäsittelijä koodataan, koska se on itse asiassa kernelin puolella. Saatat siis joutua kirjoittamaan jonkinlaisen driverin keskeytyskäsittelijällesi?
Assembler-blokkeja joutunee kanssa hiukan säätämään, koska borland tasm ei ole free-pascalissa käytetty assembler:
https://wiki.freepascal.org/Asm
-aika geneerinen asm se kuitenkin on ja itse asiassa tukee ainakin neljää eri murretta: standard, gas, intel ja att. Eli ei ole mahdoton saada toimimaan.
Toisekseen, en myöskään viitsi kirjoittaa precompiler-direktiivejä suoraan koodiin niiden sekavuuden takia vaan käytän mieluiten Lazarus-editorin kautta fpc:tä, jolloin se on "rasti ruutuun ja menoksi" tyyppinen ratkaisu. Tokihan sinne tulee sitten Lazaruksen konfigurointi-tiedosto mukaan, mutta IDE pitää huolen kääntäjäasetuksista.
Ja Lazarus-IDE tunnetusti on kirjoitettu lazaruksella eli fpc-kääntäjällä.

Lue lisää

Freepascalilla oletus on (ikävä kyllä) gas eli at&t syntaksi.

Tuo syntaksi on vaihtoehtoinen assembly -syntaksi suoraan helvetistä.

Eli suomeksi sanottuna: älä käytä !

Jos assemblyä aiot FreePascalilla kirjoittaa, tee näin:

{$mode Delphi}
{$asmmode Intel}

at&t vai halusi tunkea ne näppinsä joka paikkaan, ja luoda ikioman (täysin kelvottoman) syntaksinsa.
Tuota ei kukaan täysijärkinen halua käyttää.
Mutta Linux -piireistä löytyy hämärähörhäjä, joille tuo sekopäinen syntaksi on ainoa oikea.

Mitään logiikkaa tuossa at&t syntaksissa ei ole.

Moni sanoo, että siinä on vain lähde ja kohde eri päin kuin intel/microsoft/borland -syntaksissa.

MUTTA:

Entä ne käskyt, joissa:

a) vasen ja oikea argumentti eivät ole "lähde ja kohde" vaan normaalisti vasen on sekä lähde että kohde, ja oikea ei ole kumpikaan, vaan enemmänkin "määrite".

Esimerkki tällaisesta käskystä:

SHL EAX, CL ; Tässä EAX = lähde JA kohde, ja CL = Määrite

b) on 3 argumenttia, eli kohde, lähde, määrite.
Esimerkki tällaisesta käskystä:

SHL EDX, EAX, CL ; Tässä EDX=kohde, EAX = lähde, ja CL = Määrite

Millaiselta sekasotkulta nuokin 2 esimerkkiä näyttäisivät at&t -syntaksilla ?

Pelkällä Reactilla nyt ei ole tarkoituskaan tehdä front-endiä. Sehän on vain kirjasto millä voi toteuttaa käyttöliittymäkomponentit.

Tuohon projektiin nyt tarvitsee miettiä toki myös ohjelmointikieli, IDE millä tehdään, käyttöliittymän tilan hallinta..

Jos te teitte monimutkaiseksi niin vika varmastikin tekijöissä.

Lazaruksen ongelmat ovat käyttöliittymien teossa ovat valtavia. Siksi ette tehneet sillä työpaikan sovelluksen käyttöliittymää.

Anonyymi kirjoitti:

Pelkällä Reactilla nyt ei ole tarkoituskaan tehdä front-endiä. Sehän on vain kirjasto millä voi toteuttaa käyttöliittymäkomponentit.

Tuohon projektiin nyt tarvitsee miettiä toki myös ohjelmointikieli, IDE millä tehdään, käyttöliittymän tilan hallinta..

Jos te teitte monimutkaiseksi niin vika varmastikin tekijöissä.

Lazaruksen ongelmat ovat käyttöliittymien teossa ovat valtavia. Siksi ette tehneet sillä työpaikan sovelluksen käyttöliittymää.

Lue lisää

Mitä sinä käytät, kun noin sekasin saat itsesi.

Anonyymi kirjoitti:

Mitä sinä käytät, kun noin sekasin saat itsesi.

En tee ohjelmia monimutkaisesti. Sinulla oli ne ongelmat.

Anonyymi kirjoitti:

En tee ohjelmia monimutkaisesti. Sinulla oli ne ongelmat.

Taas tämä on luisumassa sekavuutesi vuoksi väärille raiteille. Olisi parempi ettet yrittäisi keskustella ennen kuin olet kunnossa.

Anonyymi kirjoitti:

Pelkällä Reactilla nyt ei ole tarkoituskaan tehdä front-endiä. Sehän on vain kirjasto millä voi toteuttaa käyttöliittymäkomponentit.

Tuohon projektiin nyt tarvitsee miettiä toki myös ohjelmointikieli, IDE millä tehdään, käyttöliittymän tilan hallinta..

Jos te teitte monimutkaiseksi niin vika varmastikin tekijöissä.

Lazaruksen ongelmat ovat käyttöliittymien teossa ovat valtavia. Siksi ette tehneet sillä työpaikan sovelluksen käyttöliittymää.

Lue lisää

No toki Reactilla oli käytössä se material-ui yms. Mutta silti ei ole voittanutta (mielekkyydessä) kuten Lazaruksella/Delphillä voit tiputella komponentteja formille ja näet sen käyttöliittymän editorissa design time -tilassa.

En nyt toki Lazaruksella lähtis webissä toimivaa sovellusta ensinnäkään tekemään, mutta silti, silti ihmettelen että 20v sitten oli niin helppoa suunnitella käyttöliittymä kuten Delphillä, nykyään joutuu väkertämään koodi-tasolla (TypeScript) kuten tuossa Reactilla käyttöliittymän teossa. Puolen vuoden väkertämisen jälkeen business-tyypit sano että homma seis, koko homma olisi ottanut varmasti 2,5 vuotta. Itse en tuota Reactia ollut valitsemassa, mutta kerkesin sillä tekemään sen oman osuuden front-end:sta.

t. Ex-Delphisti

Anonyymi kirjoitti:

No toki Reactilla oli käytössä se material-ui yms. Mutta silti ei ole voittanutta (mielekkyydessä) kuten Lazaruksella/Delphillä voit tiputella komponentteja formille ja näet sen käyttöliittymän editorissa design time -tilassa.

En nyt toki Lazaruksella lähtis webissä toimivaa sovellusta ensinnäkään tekemään, mutta silti, silti ihmettelen että 20v sitten oli niin helppoa suunnitella käyttöliittymä kuten Delphillä, nykyään joutuu väkertämään koodi-tasolla (TypeScript) kuten tuossa Reactilla käyttöliittymän teossa. Puolen vuoden väkertämisen jälkeen business-tyypit sano että homma seis, koko homma olisi ottanut varmasti 2,5 vuotta. Itse en tuota Reactia ollut valitsemassa, mutta kerkesin sillä tekemään sen oman osuuden front-end:sta.

t. Ex-Delphisti

Lue lisää

Eiköhän tuo ole käyttämistäsi työkaluista kiinni.

Olen Delphiä käyttänyt ja ei sillä niitä komponentteja ainakaan ennen oikein pystynyt kunnolla design vaiheessa laittamaan. Esimerkiksi testaamaan sitä miten menu toimii puhelimella, tabletilla ja läppärillä, miten reagoi kun kääntää näyttöä 90 astetta, scrollataan alas päin 3 ruudullista ja miten jokin liukuu toisen osan päälle ja jne. Tuollaisia ei varmasti ollut 20 vuotta sitten.

Kynällä ja paperilla toimi helpommin. Ja toimii kynä ja paperi vieläkin ihan hyvin.

Reactilla voi käyttää Chromea kun se päivittää realtime näkymää, että sen kun läiskii komponentit DOM:n niin näkyy reaaliajassa miten käyttäytyy. Yksinkertaisen käyttöliittymän suunnittelee parissa tunnissa.

"En nyt toki Lazaruksella lähtis webissä toimivaa sovellusta ensinnäkään tekemään"

No käytännössä kaikki sovellukset tehdään toimimaan webissä jos ei ole jotain erityistä syytä. Yleensä on vain se web versio ja toimii joka paikassa. Android ja iOS versiot tehdään välillä natiivikäännöksin että saa käytettyä kaikia antureita tai jos suorituskyvystä tekee tiukkaa. Sitä varten sitten on esimerkiksi React-native ja Flutter. Tai tekee niinkuin Koronavilkussa jossa muistaakseni oli erikseen Android ja iOS versiot käyttöliittymästä.

"Puolen vuoden väkertämisen jälkeen business-tyypit sano että homma seis, koko homma olisi ottanut varmasti 2,5 vuotta."

Jos jotain yli 15-vuotta vanhaa ohjelmaa säädetään uusiksi nykyaikaiseksi niin siinä on vähän muutakin uusittavaa kuin käyttöliittymän design. Urakka melkein pitäisi aloittaa API:sta kun 15-vuotta sitten yleensä käytettiin XML-viestejä käyttäliittymän ja taustajärjestelmän välillä niin helpompaa uusia sekin sitten. API:a uusittaessa ihan hyvin aikaa hinkata käyttöliittymää ennen kuin kirjoittaa riviäkään logiikkaa.

Ei sinne sitten oikein jäisi vanhasta koodista kuin joku tietokanta.

Anonyymi kirjoitti:

Eiköhän tuo ole käyttämistäsi työkaluista kiinni.

Olen Delphiä käyttänyt ja ei sillä niitä komponentteja ainakaan ennen oikein pystynyt kunnolla design vaiheessa laittamaan. Esimerkiksi testaamaan sitä miten menu toimii puhelimella, tabletilla ja läppärillä, miten reagoi kun kääntää näyttöä 90 astetta, scrollataan alas päin 3 ruudullista ja miten jokin liukuu toisen osan päälle ja jne. Tuollaisia ei varmasti ollut 20 vuotta sitten.

Kynällä ja paperilla toimi helpommin. Ja toimii kynä ja paperi vieläkin ihan hyvin.

Reactilla voi käyttää Chromea kun se päivittää realtime näkymää, että sen kun läiskii komponentit DOM:n niin näkyy reaaliajassa miten käyttäytyy. Yksinkertaisen käyttöliittymän suunnittelee parissa tunnissa.

"En nyt toki Lazaruksella lähtis webissä toimivaa sovellusta ensinnäkään tekemään"

No käytännössä kaikki sovellukset tehdään toimimaan webissä jos ei ole jotain erityistä syytä. Yleensä on vain se web versio ja toimii joka paikassa. Android ja iOS versiot tehdään välillä natiivikäännöksin että saa käytettyä kaikia antureita tai jos suorituskyvystä tekee tiukkaa. Sitä varten sitten on esimerkiksi React-native ja Flutter. Tai tekee niinkuin Koronavilkussa jossa muistaakseni oli erikseen Android ja iOS versiot käyttöliittymästä.

"Puolen vuoden väkertämisen jälkeen business-tyypit sano että homma seis, koko homma olisi ottanut varmasti 2,5 vuotta."

Jos jotain yli 15-vuotta vanhaa ohjelmaa säädetään uusiksi nykyaikaiseksi niin siinä on vähän muutakin uusittavaa kuin käyttöliittymän design. Urakka melkein pitäisi aloittaa API:sta kun 15-vuotta sitten yleensä käytettiin XML-viestejä käyttäliittymän ja taustajärjestelmän välillä niin helpompaa uusia sekin sitten. API:a uusittaessa ihan hyvin aikaa hinkata käyttöliittymää ennen kuin kirjoittaa riviäkään logiikkaa.

Ei sinne sitten oikein jäisi vanhasta koodista kuin joku tietokanta.

Lue lisää

No viivästykseen oli yksi syy myös tuo back-end, että se olisi pitänyt tehdä myös uusiksi isolta osin (UI:n lisäksi). Ihmettelen vain miksi tämmöistä asiaa ei otettu huomioon vaan yli-optimaalisesti sanottiin että 6-9 kk koko homma on valmis, en koskaan uskonut tuohon aikatauluun.

"Reactilla voi käyttää Chromea kun se päivittää realtime näkymää, että sen kun läiskii komponentit DOM:n niin näkyy reaaliajassa miten käyttäytyy. Yksinkertaisen käyttöliittymän suunnittelee parissa tunnissa."

Mutta kyse ei ole kovin yksinkertaisesta käyttöliittymästä, vanhassa on paljon käytetty esim. jqGridia (jonka käyttö vanhassakin on täysin anaalista vs Delphi), Reactille lähtivät tekemään alusta taulukoilla jotenkin tuon Gridin korvaamisen, paginoinnit yms. olikohan 2-3 erilaista toteutusta tehty se jqGridin korvaus, noihin meni ihan saamaristi aikaa.

Delphillä sä asemoin Gridin siihen formille ja luet siihen datan, ei mitään ylimääräistä copy-paste koodia aina jostakin toisesta puolen koodia jne. Copy-pasten copy-pastea huh huh! Ja sitten jos se Gridi päivittyy, käyt sen copy-paste -koodin läpi kaikkialta.

Niin mobiili-hommat on erikseen, en ole niitä koskaan tehnyt, enkä luultavasti tule tekemäänkään. Mutta toki nykyään isojakin sovelluksia pystytään tekemään web-tekniikoin, kuten paljon käyttämäni VSCode.

t. Ex-Delphisti

Anonyymi kirjoitti:

No viivästykseen oli yksi syy myös tuo back-end, että se olisi pitänyt tehdä myös uusiksi isolta osin (UI:n lisäksi). Ihmettelen vain miksi tämmöistä asiaa ei otettu huomioon vaan yli-optimaalisesti sanottiin että 6-9 kk koko homma on valmis, en koskaan uskonut tuohon aikatauluun.

"Reactilla voi käyttää Chromea kun se päivittää realtime näkymää, että sen kun läiskii komponentit DOM:n niin näkyy reaaliajassa miten käyttäytyy. Yksinkertaisen käyttöliittymän suunnittelee parissa tunnissa."

Mutta kyse ei ole kovin yksinkertaisesta käyttöliittymästä, vanhassa on paljon käytetty esim. jqGridia (jonka käyttö vanhassakin on täysin anaalista vs Delphi), Reactille lähtivät tekemään alusta taulukoilla jotenkin tuon Gridin korvaamisen, paginoinnit yms. olikohan 2-3 erilaista toteutusta tehty se jqGridin korvaus, noihin meni ihan saamaristi aikaa.

Delphillä sä asemoin Gridin siihen formille ja luet siihen datan, ei mitään ylimääräistä copy-paste koodia aina jostakin toisesta puolen koodia jne. Copy-pasten copy-pastea huh huh! Ja sitten jos se Gridi päivittyy, käyt sen copy-paste -koodin läpi kaikkialta.

Niin mobiili-hommat on erikseen, en ole niitä koskaan tehnyt, enkä luultavasti tule tekemäänkään. Mutta toki nykyään isojakin sovelluksia pystytään tekemään web-tekniikoin, kuten paljon käyttämäni VSCode.

t. Ex-Delphisti

Lue lisää

"Ihmettelen vain miksi tämmöistä asiaa ei otettu huomioon vaan yli-optimaalisesti sanottiin että 6-9 kk koko homma on valmis, en koskaan uskonut tuohon aikatauluun."

Tuossa ajassa itseasiassa saa aikaiseksi paljon, yksikin ohjelmoija.

"Mutta kyse ei ole kovin yksinkertaisesta käyttöliittymästä, vanhassa on paljon käytetty esim. jqGridia "

jqGrid... No material-ui:ssa on DataGrid mikä tekee saman, ja tuo ei ole mikään monimutkainen. Projekti vaan alkaisi siitä, että ensiksi huolehtii siitä että backend palauttaa taulukon JSON:na mikä on suoraan yhteensopivaa DataGridin kanssa, ja sillä on API mistä koodin voi generoida API kuvauksesta ja E2E testit toimivat. Sitten generoi koodin vanhaan backendiin ja tarvittaessa frontendiin tekee adapteria että toimii jqGridin kanssa.

Tuo remontti voidaan viedä tuotantoon ja sen tarkoitus olisi varmistaa että on API kuvaus on, toimii ja se on dokumentoitu. Sitten on helppo jatkokehittää päivittämällä käyttöliittymä material-ui:n niin siinä ei ole oikeasti yhtään mitään nysväämistä sen saamiseksi toimimaan backendin kanssa kun actionit voi generoida API kuvauksesta. Sen kun asettelee vain ne DataGridit sinne ja containereihin ne actionit.

Missä se aika sitten menee niin riippuu siitä minkälainen tunkio se vanha backend on. Jos siellä ei vaikka ole mitään siistiä frameworkkia, että voisi generoida koodin niin se on varmastikin tärkeämpää kuin joku käyttöliittymän päivitys kun se jQuery versio kuitenkin on olemassa jo ja toimii.

"Reactille lähtivät tekemään alusta taulukoilla jotenkin tuon Gridin korvaamisen, paginoinnit yms. olikohan 2-3 erilaista toteutusta tehty se jqGridin korvaus, noihin meni ihan saamaristi aikaa."

Siellä material-ui:ssa on se DataGrid, että ei tarvitse.

"Delphillä sä asemoin Gridin siihen formille ja luet siihen datan, ei mitään ylimääräistä copy-paste koodia aina jostakin toisesta puolen koodia jne. Copy-pasten copy-pastea huh huh! Ja sitten jos se Gridi päivittyy, käyt sen copy-paste -koodin läpi kaikkialta."

Formille asettelu on sama kuin copypaste. Kaikki formille asettelut pitää käydä läpi kun komponenttia vaihdetaan. Siellä on ns. kytkentä, riippuvuus.

Eli miksi teitte 2-3 erillistä komponenttia itse kun material-ui:ssa on valmis DataGrid ? Ja sitten kun muuttelette omia komponentteja niin kun niihin on riippuvuus niin joutuu tekemään muutoksia. DataGrid päivittyy sitten kun päivittyy material-ui ja se taas on material-ui:n kehittäjistä kiinni miten muuttelevat. Tuskinpa tarkoituksella muuttavat.

Eli jos alkuperäinen versio oli vaikka Delphillä tehty niin prosessi on täysin sama kuin Delphistä jQuery / jqGrid toteutukseen muuttaminen. Eli ensiksi varmistetaan että API toimii sinne backendiin ja että voidaan API kuvauksesta generoida koodi.

Ideahan siinä ohjelmoinnissa on pitää aina kaikki palikat helposti muutettavina kun niitä kuitenkin tarvitsee muuttaa vaikka Delphi -> jqGrid -> DataGrid

Tuollaiset muutokset ovat yleensä ajankohtaisia noin 12 vuoden välein. Silloin joskus 1994 kun Delphi tuli niin oli helposti se tilanne, että backendiä oltu edes kunnolla eroteltu ja oli vaikka riippuvuuksia vaikka tietokantamoottoriin. Ensimmäinen steppi Delphi version jälkeen oli tietenkin rakentaa vuosituhannen vaihteen jälkeen se HTTP API mikä toimii XML sanomilla ja käyttää sitä Delphi käyttöliittymää sillä niin sai sen backendin vaihdettavaksi, tietokantamoottorin vaihdettavaksi, käyttöliittymän vaihdettavaksi, helpompi backup ja jne.

Sen jälkeen voikin vaihtaa käyttöliittymän vaikka palvelimella renderöidyksi, että käyttäjä kun painelee nappeja niin lähtee pyyntö renderöidä käyttöliittymä uusiksi.

Sitten jQuery käytännölliseksi kun se jqGrid voitiin vaihtaa päivittämään sisältöä selaimessa tekemällä se API kutsu, niin sivulataukset tehtiin vasta sitten kun koko näkymä vaihtui. Komponentit saatiin toimimaan itsenäisesti. Ennen jQueryä oli kyllä sellainen välivaihe että käytettiin Java appletteja, ActiveX palikoita ja Flash pökäleitä mutta ne eivät olleet standardeja.

Ne oli aika kauheita mutta noin niinkuin ohjelmiston elinkaaren kannalta ymmärrettävä ratkaisu kun voitiin tehdä ohjelma suurelta osin standardin mukaiseksi ja siirtää vanha komponentti Java- tai Visual Basic ohjelmasta selaimeen. Delphin VCL komponetteja ei saanut siirrettyä selaimeen.

Reactilla tehtäessä ideana on poistaa palvelimella renderöitävät käyttöliittymät selaimella renderöitäväksi niin poistuu sivulataukset kokonaan. Ennen Reactia oli jo Angular mikä teki saman tuohon mutta se oli turhan hidas.

Pointti siis se, ohjelman elinkaaren aikana tulee muutoksia, ideana on pitää komponentit vaihdettavina. Suuret kustannukset muutoksille tulee käytännössä siitä minkälainen tunkio se vanha koodi on.

Anonyymi kirjoitti:

No viivästykseen oli yksi syy myös tuo back-end, että se olisi pitänyt tehdä myös uusiksi isolta osin (UI:n lisäksi). Ihmettelen vain miksi tämmöistä asiaa ei otettu huomioon vaan yli-optimaalisesti sanottiin että 6-9 kk koko homma on valmis, en koskaan uskonut tuohon aikatauluun.

"Reactilla voi käyttää Chromea kun se päivittää realtime näkymää, että sen kun läiskii komponentit DOM:n niin näkyy reaaliajassa miten käyttäytyy. Yksinkertaisen käyttöliittymän suunnittelee parissa tunnissa."

Mutta kyse ei ole kovin yksinkertaisesta käyttöliittymästä, vanhassa on paljon käytetty esim. jqGridia (jonka käyttö vanhassakin on täysin anaalista vs Delphi), Reactille lähtivät tekemään alusta taulukoilla jotenkin tuon Gridin korvaamisen, paginoinnit yms. olikohan 2-3 erilaista toteutusta tehty se jqGridin korvaus, noihin meni ihan saamaristi aikaa.

Delphillä sä asemoin Gridin siihen formille ja luet siihen datan, ei mitään ylimääräistä copy-paste koodia aina jostakin toisesta puolen koodia jne. Copy-pasten copy-pastea huh huh! Ja sitten jos se Gridi päivittyy, käyt sen copy-paste -koodin läpi kaikkialta.

Niin mobiili-hommat on erikseen, en ole niitä koskaan tehnyt, enkä luultavasti tule tekemäänkään. Mutta toki nykyään isojakin sovelluksia pystytään tekemään web-tekniikoin, kuten paljon käyttämäni VSCode.

t. Ex-Delphisti

Lue lisää

Niin tosiaankin, kyllähän sitä vaihtaisi vuoden 1995 Delphi ohjelman vaikka suoraan Reactille mutta silloinkin homma lähtee sitä, että käyttöliittymä juttelee backendin kanssa HTTP API:lla ja JSON sanomilla.

Olen kyllä nähnyt niiden 90-luvun Delphi ohjelmien koodia ja ne oli kyllä ihan järkyttävää kuraa. Hiton työlästä muuttaa yhtään mitään kun koodi sellaista spagettia ja täynnä omituisia riippuvuuksia.

Anonyymi kirjoitti:

Niin tosiaankin, kyllähän sitä vaihtaisi vuoden 1995 Delphi ohjelman vaikka suoraan Reactille mutta silloinkin homma lähtee sitä, että käyttöliittymä juttelee backendin kanssa HTTP API:lla ja JSON sanomilla.

Olen kyllä nähnyt niiden 90-luvun Delphi ohjelmien koodia ja ne oli kyllä ihan järkyttävää kuraa. Hiton työlästä muuttaa yhtään mitään kun koodi sellaista spagettia ja täynnä omituisia riippuvuuksia.

Lue lisää

Eli tämä(kö?)
https://material-ui.com/components/data-grid/

Ainakaan tuossa esimerkissä ei ole SubGridin mahdollisuutta, eli Gridista saa ali-gridin avattua, myös Excel- että PDF export puuttuu. Nämä on siis jqGridissa olemassa.

Tuossa konversiossa oli välissä vielä semmoinenkin kikare kuin GraphQL, joka oli omiaan hidastamassa asioita.

t. ex-Delphisti.

Anonyymi kirjoitti:

Eli tämä(kö?)
https://material-ui.com/components/data-grid/

Ainakaan tuossa esimerkissä ei ole SubGridin mahdollisuutta, eli Gridista saa ali-gridin avattua, myös Excel- että PDF export puuttuu. Nämä on siis jqGridissa olemassa.

Tuossa konversiossa oli välissä vielä semmoinenkin kikare kuin GraphQL, joka oli omiaan hidastamassa asioita.

t. ex-Delphisti.

Lue lisää

"Ainakaan tuossa esimerkissä ei ole SubGridin mahdollisuutta, eli Gridista saa ali-gridin avattua, myös Excel- että PDF export puuttuu. Nämä on siis jqGridissa olemassa."

Tuon tason eroavaisuudet melkeinpä tarkoittaa sitä, että käyttöliittymä pitäisi suunnitella uudestaan Googlen spekseillä niin on helpompi käyttäjälle kun toimii samalla tavalla muiden Googlen sovellusten kanssa Android- ja Chromebook laitteissa.

Tai jos sovellus on vahvasti tehty tuollaisen ominaisuuden varaan niin pitää miettiä sitä UI frameworkkiä, että onko se oikea. Löytyy melkoisen paljon frameworkkeja jotka tehty laajennettavaksi tai teemoitettavaksi, että voi tehdä sen pohjalta haluamanlaisia. Microsoftin frameworkissa esimerkiksi vastaava palikka sisältää ryhmittämistä. Tai sitten vaan tekee DataGridin pohjalta itse jotain container componentteja.

"Tuossa konversiossa oli välissä vielä semmoinenkin kikare kuin GraphQL, joka oli omiaan hidastamassa asioita."

Tuo ainakin tarkoittaa sitä, että backendiin tulee valtava remontti ja työ oikeastaan kannattaisi aloittaa siitä. Se ei nyt ole ihan selvää missä kannattaa käyttää GraphQL:ää ja missä REST:iä. Ja jos tuohon GraphQL:n on päädytty ja kun mainitset jotain Exceliä:ä ja SubGridiä niin haiskahtaa joltain ERP:ltä ja tuollaisessa se on ihan järkevä valinta. UI:n uusiminen kuullostaa järjettömältä ennen kuin se API on tehty toimimaan vanhalla UI:lla ja GraphQL:llä.

Ei sillä frontendillä mielestäni pitäisi sillä tavalla olla edes kiire kun kuitenkin siitä tulee käyttäjille näkyvä muutos. Kyllä se jQuery toimii ihan hyvin vieläkin vaikka suurin osa käyttöliittymästä renderöidään palvelimessa. Kannattaa ne resurssit käyttää aina siihen missä vähennetään eniten teknistä velkaa tai millä saadaan ohjelmaan lisäarvoa.

React tuo joo lisäarvoa kun sivulataukset vähenee mutta niin voi tehdä se GraphQL myös kun voi vähentää kyselyjä millä täytetään niitä jqGrid sisältöjä.

Anonyymi kirjoitti:

"Ainakaan tuossa esimerkissä ei ole SubGridin mahdollisuutta, eli Gridista saa ali-gridin avattua, myös Excel- että PDF export puuttuu. Nämä on siis jqGridissa olemassa."

Tuon tason eroavaisuudet melkeinpä tarkoittaa sitä, että käyttöliittymä pitäisi suunnitella uudestaan Googlen spekseillä niin on helpompi käyttäjälle kun toimii samalla tavalla muiden Googlen sovellusten kanssa Android- ja Chromebook laitteissa.

Tai jos sovellus on vahvasti tehty tuollaisen ominaisuuden varaan niin pitää miettiä sitä UI frameworkkiä, että onko se oikea. Löytyy melkoisen paljon frameworkkeja jotka tehty laajennettavaksi tai teemoitettavaksi, että voi tehdä sen pohjalta haluamanlaisia. Microsoftin frameworkissa esimerkiksi vastaava palikka sisältää ryhmittämistä. Tai sitten vaan tekee DataGridin pohjalta itse jotain container componentteja.

"Tuossa konversiossa oli välissä vielä semmoinenkin kikare kuin GraphQL, joka oli omiaan hidastamassa asioita."

Tuo ainakin tarkoittaa sitä, että backendiin tulee valtava remontti ja työ oikeastaan kannattaisi aloittaa siitä. Se ei nyt ole ihan selvää missä kannattaa käyttää GraphQL:ää ja missä REST:iä. Ja jos tuohon GraphQL:n on päädytty ja kun mainitset jotain Exceliä:ä ja SubGridiä niin haiskahtaa joltain ERP:ltä ja tuollaisessa se on ihan järkevä valinta. UI:n uusiminen kuullostaa järjettömältä ennen kuin se API on tehty toimimaan vanhalla UI:lla ja GraphQL:llä.

Ei sillä frontendillä mielestäni pitäisi sillä tavalla olla edes kiire kun kuitenkin siitä tulee käyttäjille näkyvä muutos. Kyllä se jQuery toimii ihan hyvin vieläkin vaikka suurin osa käyttöliittymästä renderöidään palvelimessa. Kannattaa ne resurssit käyttää aina siihen missä vähennetään eniten teknistä velkaa tai millä saadaan ohjelmaan lisäarvoa.

React tuo joo lisäarvoa kun sivulataukset vähenee mutta niin voi tehdä se GraphQL myös kun voi vähentää kyselyjä millä täytetään niitä jqGrid sisältöjä.

Lue lisää

GraphQL päädyttiin varmaan siksi, koska siinä on se skeema ja vähentää niitä kyselyitä front-endin kanssa, aika uusi tuttavuus itelle, mutta näin ymmärsin. Mutta.. aivan pirun iso urakka tehdä koko back-end uusiksi. Noh, tämä sinällään menee offtopiciksi koko Lazaruksesta/Pascalista.

Ite sen verran vanhan liiton tyyppi, että jos graafista sovellusta pitää tehdä, niin edelleen miellytävin ja nopein omasta mielestäni on juuri Delphi/Lazarus. Joskus olen kokeillut Qt/C , Angular ja sitten työn puolesta jQuery/UI ja React.

Tätä apuohjelmaa olen tehnyt yhteensä noin pari tuntia ja risat, varsinaisia koodirivejä tosi vähän siihen verrattuna mitä saa aikaan, etenkin tuo SynEdit on ihan loistava, osaa värittää tuon XML-dokumentin syntaksin ja paljon muitakin syntakseja tukee :) Tämä nyt on tällä lähinnä omaan testauskäyttöön, varsinaisen pääprojektin avuksi.

https://tinyurl.com/y2zox8f5

Anonyymi kirjoitti:

GraphQL päädyttiin varmaan siksi, koska siinä on se skeema ja vähentää niitä kyselyitä front-endin kanssa, aika uusi tuttavuus itelle, mutta näin ymmärsin. Mutta.. aivan pirun iso urakka tehdä koko back-end uusiksi. Noh, tämä sinällään menee offtopiciksi koko Lazaruksesta/Pascalista.

Ite sen verran vanhan liiton tyyppi, että jos graafista sovellusta pitää tehdä, niin edelleen miellytävin ja nopein omasta mielestäni on juuri Delphi/Lazarus. Joskus olen kokeillut Qt/C , Angular ja sitten työn puolesta jQuery/UI ja React.

Tätä apuohjelmaa olen tehnyt yhteensä noin pari tuntia ja risat, varsinaisia koodirivejä tosi vähän siihen verrattuna mitä saa aikaan, etenkin tuo SynEdit on ihan loistava, osaa värittää tuon XML-dokumentin syntaksin ja paljon muitakin syntakseja tukee :) Tämä nyt on tällä lähinnä omaan testauskäyttöön, varsinaisen pääprojektin avuksi.

https://tinyurl.com/y2zox8f5

Lue lisää

"Noh, tämä sinällään menee offtopiciksi koko Lazaruksesta/Pascalista."

Se topikki vähän siirtyi siihen että mitä sillä Pascalilla tai Lazaruksella oikein tekee.

"Ite sen verran vanhan liiton tyyppi, että jos graafista sovellusta pitää tehdä, niin edelleen miellytävin ja nopein omasta mielestäni on juuri Delphi/Lazarus."

Oletko nyt ihan varma?

Elmin kaltainen sovelluksen tilan hallinta on ihan pakollinen käyttöliittymäohjelmoinnissa. Siis ideana se että kaikki ohjelman tila on yhdessä objektissa ja on tasan yksi funktio mikä päivittää tilan antamalla sille aiemman tilan sekä actionin. Ja edut on ilmiselviä kun kaikki tilat on yhdessä objektissa ja muuttuu yhdellä funktiolla niin ei ole mahdollista saada ohjelmaa johonkin omituiseen tilaan. Helpoin tapa poistaa bugit käyttöliittymästä niin ei tarvitse aikaa kuluttaa debuggailuun.

Tuollaisen toteuttaminen on onnistuu tietenkin millä tahansa kielellä mutta melkoista nysväämistä tuo Pascalilla olisi.

Anonyymi kirjoitti:

GraphQL päädyttiin varmaan siksi, koska siinä on se skeema ja vähentää niitä kyselyitä front-endin kanssa, aika uusi tuttavuus itelle, mutta näin ymmärsin. Mutta.. aivan pirun iso urakka tehdä koko back-end uusiksi. Noh, tämä sinällään menee offtopiciksi koko Lazaruksesta/Pascalista.

Ite sen verran vanhan liiton tyyppi, että jos graafista sovellusta pitää tehdä, niin edelleen miellytävin ja nopein omasta mielestäni on juuri Delphi/Lazarus. Joskus olen kokeillut Qt/C , Angular ja sitten työn puolesta jQuery/UI ja React.

Tätä apuohjelmaa olen tehnyt yhteensä noin pari tuntia ja risat, varsinaisia koodirivejä tosi vähän siihen verrattuna mitä saa aikaan, etenkin tuo SynEdit on ihan loistava, osaa värittää tuon XML-dokumentin syntaksin ja paljon muitakin syntakseja tukee :) Tämä nyt on tällä lähinnä omaan testauskäyttöön, varsinaisen pääprojektin avuksi.

https://tinyurl.com/y2zox8f5

Lue lisää

"Tätä apuohjelmaa olen tehnyt yhteensä noin pari tuntia ja risat, varsinaisia koodirivejä tosi vähän siihen verrattuna mitä saa aikaan, etenkin tuo SynEdit on ihan loistava, osaa värittää tuon XML-dokumentin syntaksin ja paljon muitakin syntakseja tukee :)"

Minulla VSCode tekee tuon jo. Ja siihen on helppoa tehdä lisäosia jos tarvitsee jotain.

Anonyymi kirjoitti:

"Noh, tämä sinällään menee offtopiciksi koko Lazaruksesta/Pascalista."

Se topikki vähän siirtyi siihen että mitä sillä Pascalilla tai Lazaruksella oikein tekee.

"Ite sen verran vanhan liiton tyyppi, että jos graafista sovellusta pitää tehdä, niin edelleen miellytävin ja nopein omasta mielestäni on juuri Delphi/Lazarus."

Oletko nyt ihan varma?

Elmin kaltainen sovelluksen tilan hallinta on ihan pakollinen käyttöliittymäohjelmoinnissa. Siis ideana se että kaikki ohjelman tila on yhdessä objektissa ja on tasan yksi funktio mikä päivittää tilan antamalla sille aiemman tilan sekä actionin. Ja edut on ilmiselviä kun kaikki tilat on yhdessä objektissa ja muuttuu yhdellä funktiolla niin ei ole mahdollista saada ohjelmaa johonkin omituiseen tilaan. Helpoin tapa poistaa bugit käyttöliittymästä niin ei tarvitse aikaa kuluttaa debuggailuun.

Tuollaisen toteuttaminen on onnistuu tietenkin millä tahansa kielellä mutta melkoista nysväämistä tuo Pascalilla olisi.

Lue lisää

"Elmin kaltainen sovelluksen tilan hallinta on ihan pakollinen käyttöliittymäohjelmoinnissa. Siis ideana se että kaikki ohjelman tila on yhdessä objektissa ja on tasan yksi funktio mikä päivittää tilan antamalla sille aiemman tilan sekä actionin. Ja edut on ilmiselviä kun kaikki tilat on yhdessä objektissa ja muuttuu yhdellä funktiolla niin ei ole mahdollista saada ohjelmaa johonkin omituiseen tilaan. Helpoin tapa poistaa bugit käyttöliittymästä niin ei tarvitse aikaa kuluttaa debuggailuun."

Kyllä niillä tiloilla nysväämistä oli ihan tarpeeksi Reactinkin kanssa puuhatessa, useEffect yms. Sitten siellä oli jotain automatiikkaa "prettier", joka yritti "itse" koodailla ja sekoitti palettia entisestään, esim. alla kuvattuun koodin lisäsi noita argumentteja, itse lisäsin vaikka a:n, prettier lisäsi b, c ja d

useEffect (
() => {
// toimintoa
}, [a, b, c, d]
);

Lisäksi koko Reactihan vilisee useSate ja setState -funktioita, mitä nuo on muuta kuin eri tilojen asettamisia?

Tämä oli hauska itestä, kirjoittavat kuin olisi jokin uusi asia =D (maksumuurin takana).

"Kirjoittamisen sijaan ohjelman logiikka ja visuaalinen ilme muodostetaan pääasiassa valmiista elementeistä. Esimerkiksi valikoita ja lomakkeita varten on elementit, jotka raahataan sellaisinaan näkymään."

https://www.tivi.fi/uutiset/low-code-vahentaa-koodin-kirjoittamista-kayttoliittyman-ja-visuaalisen-puolen-tekeminen-on-huomattavasti-nopeampaa/a7db9c71-d8b3-4b6e-ade9-21a396b8ef3f

Anonyymi kirjoitti:

"Tätä apuohjelmaa olen tehnyt yhteensä noin pari tuntia ja risat, varsinaisia koodirivejä tosi vähän siihen verrattuna mitä saa aikaan, etenkin tuo SynEdit on ihan loistava, osaa värittää tuon XML-dokumentin syntaksin ja paljon muitakin syntakseja tukee :)"

Minulla VSCode tekee tuon jo. Ja siihen on helppoa tehdä lisäosia jos tarvitsee jotain.

Lue lisää

"Minulla VSCode tekee tuon jo. Ja siihen on helppoa tehdä lisäosia jos tarvitsee jotain." Apuohjelmaan tulee toki muutakin toimintoa, ei ole pelkkä "xml-editori".

Anonyymi kirjoitti:

"Minulla VSCode tekee tuon jo. Ja siihen on helppoa tehdä lisäosia jos tarvitsee jotain." Apuohjelmaan tulee toki muutakin toimintoa, ei ole pelkkä "xml-editori".

Reactissa on toki hyvänä puolena se, että esim. niissä "Sliceissa" voi olla vaikka lista objekteja ja sitten kun muokkaat sitä listaa (lisäät tai poistat ym.), niin se komponentin osa joka käsittelee sitä tietoa listasta, renderöi automaagisesti sen listan sisällön mukaan sen näkymän.

Eli toki hyvät puolet tuommosessa on.

Delphissä tosin olen aikoinaan käyttänyt vähän vastaavaa tapaa jo 10v sitten, eli harvoin käsittelen tietoja yksittäisinä muuttujina vaan Recordeina. ListBox.Items voi sisältää hyvin vaikka seuraavia objekteja

TFontInfo = Record
family: String;
weight: String;
style: String;
filePath: String;
end;
PFontInfo = ^TFontInfo;

Sitten kun klikkaat itemiä, se "renderöi" tuon objektin tiedot Dialogille kokonaisuutena, sama myös tietojen muokkauksessa, eli ne kulkeutuu tavallaan yhteen paikkaan myös tässä Pascal -toteutuksessa.

Varmasti oli omaa kokemattomuutta, kun keväällä vasta tutustuin Reactiin, sain Chrome-selaimen niin juntturaan että se piti tappaa prosessi-listauksesta suoraan pois, eli kyllä Reactillakin pystyy sotkemaan asiat jos ei tiedä mitä tekee.

t. ex-Delphisti

Anonyymi kirjoitti:

"Elmin kaltainen sovelluksen tilan hallinta on ihan pakollinen käyttöliittymäohjelmoinnissa. Siis ideana se että kaikki ohjelman tila on yhdessä objektissa ja on tasan yksi funktio mikä päivittää tilan antamalla sille aiemman tilan sekä actionin. Ja edut on ilmiselviä kun kaikki tilat on yhdessä objektissa ja muuttuu yhdellä funktiolla niin ei ole mahdollista saada ohjelmaa johonkin omituiseen tilaan. Helpoin tapa poistaa bugit käyttöliittymästä niin ei tarvitse aikaa kuluttaa debuggailuun."

Kyllä niillä tiloilla nysväämistä oli ihan tarpeeksi Reactinkin kanssa puuhatessa, useEffect yms. Sitten siellä oli jotain automatiikkaa "prettier", joka yritti "itse" koodailla ja sekoitti palettia entisestään, esim. alla kuvattuun koodin lisäsi noita argumentteja, itse lisäsin vaikka a:n, prettier lisäsi b, c ja d

useEffect (
() => {
// toimintoa
}, [a, b, c, d]
);

Lisäksi koko Reactihan vilisee useSate ja setState -funktioita, mitä nuo on muuta kuin eri tilojen asettamisia?

Tämä oli hauska itestä, kirjoittavat kuin olisi jokin uusi asia =D (maksumuurin takana).

"Kirjoittamisen sijaan ohjelman logiikka ja visuaalinen ilme muodostetaan pääasiassa valmiista elementeistä. Esimerkiksi valikoita ja lomakkeita varten on elementit, jotka raahataan sellaisinaan näkymään."

https://www.tivi.fi/uutiset/low-code-vahentaa-koodin-kirjoittamista-kayttoliittyman-ja-visuaalisen-puolen-tekeminen-on-huomattavasti-nopeampaa/a7db9c71-d8b3-4b6e-ade9-21a396b8ef3f

Lue lisää

"Lisäksi koko Reactihan vilisee useSate ja setState -funktioita, mitä nuo on muuta kuin eri tilojen asettamisia?"

Niiden käytössä pitää olla harkintaa. Tuo useState/setState on oikeastaan vaarallinen, että jos on komponentit A ja B joissa omia tiloja ja sitten ohjelman toiminta riippuu siitä missä tiloissa ovat, niin on hankala tehdä yksikkötestiä millä varmistaa kaikkien mahdollisten tilojen yhdistelmät että toimii oikein.

Siksi käyttöliittymäohjelmoinnissa tehdäänkin komponentti C missä on kaikki tilat, ja sisältää komponentit A ja B tilattomina niin tilan muutoksiin liittyvät yksikkötestit on yhdessä komponentissa.

Tuota käyttöliittymäkomponenttien hierarkiaa suunnitellessa täytyy olla aina tilan käsittely olla niin, että jos on useammassa komponentissa setState/useState niin niillä ei saa olla mitään tekemistä sen toisen komponentin kanssa missä tilaa käsitellään, eli aivan kuin olisivat eri sovelluksia.

Aivan kuten jQueryllä tehtäessä niin että saa pidettyä homman kasassa niin palvelin kun renderöi näkymän niin jQueryllä tehdyillä komponenteilla ei oletusarvoisesti saa olla mitään kommunikointia keskenään siellä selaimessa, ei ilman globaalia tilan käsittelyä. Käytännössä jQuery komponentteja sai yhdistettyä client puolella rakentamalla observer patternia document objectiin jossa globaali tilan käsittely oli siinä tai pitämällä palvelimessa.

Reactissa on viimeiset 5v käytetty käyttöliittymän globaalin tilan hallintaan Reduxia että on tilat samassa paikassa ja saa tehtyä hierarkioita, että globaali tila muuttuu samalla funktiolla. Tuolla sitten käytännössä poistui ne useStatet ja setStatet. Nykyään Reactissa on myös useReducer koukku, että reactilla itsessään tiloja kasattua mutta siinä ei ole globaalia tilaa mitä laajemissa käyttöliittymissä tarvitsee väistämättä.

Tuo reducer funktiolla tilojen kasaaminen ja globaalit tilan käsittely ovat aivan pakollisia käyttöliittymäohjelmoinnissa, että jos käyttää työkalua ei ole, se pitää tehdä siihen. Lazarus on hyvä esimerkki mistä puuttuu.

Olen sitten nähnyt lukemattomia Delphillä tehtyjä ohjelmia joissa on ihan naurettavia bugeja juurikin siinä, että globaalia tilaa ei ole huomioitu mitenkään ja komponenttien välillä on sivuvaikutuksia. Vasen käsi ei aina tiedä mitä oikea tekee.

"Kirjoittamisen sijaan ohjelman logiikka ja visuaalinen ilme muodostetaan pääasiassa valmiista elementeistä. Esimerkiksi valikoita ja lomakkeita varten on elementit, jotka raahataan sellaisinaan näkymään."

Valmiista komponenteista ne näkymät muutenkin tehdään. Yksi komponentti mikä näkyy ruudulla on käytännössä yksi rivi koodia. Sillä ei ole väliä siirtääkö siihen tekstin pätkän vai jonkun graafisen laatikon kun lopputuloksena kuitenkin on tekstiä, eli lähdekoodia ja kuitenkin näkee reaaliajassa ikkunassa miltä näyttää. Sillä on aika paljon väliä myös miten helposti uuden komponentin tekee ja toimiiko se standardilla tavalla. Ihmisiä lähinnä vitutti jotkut Java appletit.

Oletus on, että kaikki toimii suoraan ja heti kun avaa linkin. Firmat eivät jaksaneet maksaa siitä että joku tyyppi käy asentamassa ohjelmia jos jokin päivitys reistaili niin tuo muuttui jo vuosituhannen vaihteessa. Kaapelimodeemi, ADSL ja taloyhtiöiden 10M yhteydet kun alkoivat myös yleistyä vuosituhannen vaihteen jälkeen niin sama oletus oli sitten kotikäyttäjilläkin vähitellen sitä tahtia kun lankapuhelin modeemit katosivat.

"Tämä oli hauska itestä, kirjoittavat kuin olisi jokin uusi asia =D (maksumuurin takana)."

Konsepti ei ole uusi mutta toteutus on erilainen, kun esimerkiksi voidaan kertoa että onko storena joku Excel tiedosto, tietokanta schema vai mikä ja sitten valmis komponentti näyttää sen ja toimii standardilla tavalla.

Anonyymi kirjoitti:

"Minulla VSCode tekee tuon jo. Ja siihen on helppoa tehdä lisäosia jos tarvitsee jotain." Apuohjelmaan tulee toki muutakin toimintoa, ei ole pelkkä "xml-editori".

"Minulla VSCode tekee tuon jo. Ja siihen on helppoa tehdä lisäosia jos tarvitsee jotain." Apuohjelmaan tulee toki muutakin toimintoa, ei ole pelkkä "xml-editori".

Pointti vähän oli se että on aika paljon helpompi laajentaa VSCodea kuin rakentaa erillistä apuohjelmaa.

Anonyymi kirjoitti:

"Minulla VSCode tekee tuon jo. Ja siihen on helppoa tehdä lisäosia jos tarvitsee jotain." Apuohjelmaan tulee toki muutakin toimintoa, ei ole pelkkä "xml-editori".

Pointti vähän oli se että on aika paljon helpompi laajentaa VSCodea kuin rakentaa erillistä apuohjelmaa.

Lue lisää

Niin muutta TYKKÄÄN Delphin/Lazaruksen kaltaisesta softasta ja on MUKAVA välillä kokeilla tämän kaltaista ympäristöä, kuten tuolla aiemmin jo kirjoitin. Kyse ei ole helppouden hakemisesta. Lisäksi aion tällä apusoftalla testailla jaettujen kirjastojen käyttöä.

Ihme hommaa vaikka kyse on OMASTA harrastus-projektista, niin EI SAISI VAAN Lazaruksella tehdä mitään. Jos te muut siellä inhoatte Lazarusta, älkää käyttäkö sitä, me muut jotka pidämme, voimme varmasti käyttää ilman saarnaamista että muitakin parempia välineitä on olemassa, olkoot!

t. Ex-delphisti

Anonyymi kirjoitti:

"Ihmettelen vain miksi tämmöistä asiaa ei otettu huomioon vaan yli-optimaalisesti sanottiin että 6-9 kk koko homma on valmis, en koskaan uskonut tuohon aikatauluun."

Tuossa ajassa itseasiassa saa aikaiseksi paljon, yksikin ohjelmoija.

"Mutta kyse ei ole kovin yksinkertaisesta käyttöliittymästä, vanhassa on paljon käytetty esim. jqGridia "

jqGrid... No material-ui:ssa on DataGrid mikä tekee saman, ja tuo ei ole mikään monimutkainen. Projekti vaan alkaisi siitä, että ensiksi huolehtii siitä että backend palauttaa taulukon JSON:na mikä on suoraan yhteensopivaa DataGridin kanssa, ja sillä on API mistä koodin voi generoida API kuvauksesta ja E2E testit toimivat. Sitten generoi koodin vanhaan backendiin ja tarvittaessa frontendiin tekee adapteria että toimii jqGridin kanssa.

Tuo remontti voidaan viedä tuotantoon ja sen tarkoitus olisi varmistaa että on API kuvaus on, toimii ja se on dokumentoitu. Sitten on helppo jatkokehittää päivittämällä käyttöliittymä material-ui:n niin siinä ei ole oikeasti yhtään mitään nysväämistä sen saamiseksi toimimaan backendin kanssa kun actionit voi generoida API kuvauksesta. Sen kun asettelee vain ne DataGridit sinne ja containereihin ne actionit.

Missä se aika sitten menee niin riippuu siitä minkälainen tunkio se vanha backend on. Jos siellä ei vaikka ole mitään siistiä frameworkkia, että voisi generoida koodin niin se on varmastikin tärkeämpää kuin joku käyttöliittymän päivitys kun se jQuery versio kuitenkin on olemassa jo ja toimii.

"Reactille lähtivät tekemään alusta taulukoilla jotenkin tuon Gridin korvaamisen, paginoinnit yms. olikohan 2-3 erilaista toteutusta tehty se jqGridin korvaus, noihin meni ihan saamaristi aikaa."

Siellä material-ui:ssa on se DataGrid, että ei tarvitse.

"Delphillä sä asemoin Gridin siihen formille ja luet siihen datan, ei mitään ylimääräistä copy-paste koodia aina jostakin toisesta puolen koodia jne. Copy-pasten copy-pastea huh huh! Ja sitten jos se Gridi päivittyy, käyt sen copy-paste -koodin läpi kaikkialta."

Formille asettelu on sama kuin copypaste. Kaikki formille asettelut pitää käydä läpi kun komponenttia vaihdetaan. Siellä on ns. kytkentä, riippuvuus.

Eli miksi teitte 2-3 erillistä komponenttia itse kun material-ui:ssa on valmis DataGrid ? Ja sitten kun muuttelette omia komponentteja niin kun niihin on riippuvuus niin joutuu tekemään muutoksia. DataGrid päivittyy sitten kun päivittyy material-ui ja se taas on material-ui:n kehittäjistä kiinni miten muuttelevat. Tuskinpa tarkoituksella muuttavat.

Eli jos alkuperäinen versio oli vaikka Delphillä tehty niin prosessi on täysin sama kuin Delphistä jQuery / jqGrid toteutukseen muuttaminen. Eli ensiksi varmistetaan että API toimii sinne backendiin ja että voidaan API kuvauksesta generoida koodi.

Ideahan siinä ohjelmoinnissa on pitää aina kaikki palikat helposti muutettavina kun niitä kuitenkin tarvitsee muuttaa vaikka Delphi -> jqGrid -> DataGrid

Tuollaiset muutokset ovat yleensä ajankohtaisia noin 12 vuoden välein. Silloin joskus 1994 kun Delphi tuli niin oli helposti se tilanne, että backendiä oltu edes kunnolla eroteltu ja oli vaikka riippuvuuksia vaikka tietokantamoottoriin. Ensimmäinen steppi Delphi version jälkeen oli tietenkin rakentaa vuosituhannen vaihteen jälkeen se HTTP API mikä toimii XML sanomilla ja käyttää sitä Delphi käyttöliittymää sillä niin sai sen backendin vaihdettavaksi, tietokantamoottorin vaihdettavaksi, käyttöliittymän vaihdettavaksi, helpompi backup ja jne.

Sen jälkeen voikin vaihtaa käyttöliittymän vaikka palvelimella renderöidyksi, että käyttäjä kun painelee nappeja niin lähtee pyyntö renderöidä käyttöliittymä uusiksi.

Sitten jQuery käytännölliseksi kun se jqGrid voitiin vaihtaa päivittämään sisältöä selaimessa tekemällä se API kutsu, niin sivulataukset tehtiin vasta sitten kun koko näkymä vaihtui. Komponentit saatiin toimimaan itsenäisesti. Ennen jQueryä oli kyllä sellainen välivaihe että käytettiin Java appletteja, ActiveX palikoita ja Flash pökäleitä mutta ne eivät olleet standardeja.

Ne oli aika kauheita mutta noin niinkuin ohjelmiston elinkaaren kannalta ymmärrettävä ratkaisu kun voitiin tehdä ohjelma suurelta osin standardin mukaiseksi ja siirtää vanha komponentti Java- tai Visual Basic ohjelmasta selaimeen. Delphin VCL komponetteja ei saanut siirrettyä selaimeen.

Reactilla tehtäessä ideana on poistaa palvelimella renderöitävät käyttöliittymät selaimella renderöitäväksi niin poistuu sivulataukset kokonaan. Ennen Reactia oli jo Angular mikä teki saman tuohon mutta se oli turhan hidas.

Pointti siis se, ohjelman elinkaaren aikana tulee muutoksia, ideana on pitää komponentit vaihdettavina. Suuret kustannukset muutoksille tulee käytännössä siitä minkälainen tunkio se vanha koodi on.

Lue lisää

"Delphin VCL komponetteja ei saanut siirrettyä selaimeen"

VALHE!

Delphin VCL komponenteilla pystyi tekemään ActiveX -sovelluksen.

Ja Delphi jopa osaa itse tuottaa html -lähdekoodin web -sivusta, joka lataa tuon ActiveX -sovelluksen ja käynnistää sen.

Ainoa on se, että jos halutaan, että sovellusta on helppo päivittää, niin muistaakseni pientä "viilausta" piti tehdä siihen, että html -koodi tarkistaa sovelluksen versionumeron, ja jos uudempi on tarjolla, lataa sen uudemman, eikä käytä välimuistissaan olevaa vanhempaa versiota (kuten oletuksena tapahtuisi, jos et itse laita asiaa kuntoon).

Toimi Microsoftin selaimella oikein hyvin !

Itse en kannata tuota M-Karin puffaamaa "aina käyttöliittymä selaimeen" -tyyliä.

Oikein on:
"käyttöliittymä selaimeen" silloin, kun sellaiseen on jokin erityinen tarve.
Jos tuollaista erityistä tarvetta ei ole, Delphin VCL ajaa asiansa oikein hyvin.

Kaupallisesti järkevä ratkaisu:
Ohjelman VCL -komponentteja käyttävä EXE maksaa X euroa.
Ja Applen koneiden käyttäjiä varten samasta sovelluksesta web -selaimessa toimiva versio, joka maksaa 2 * X euroa.

Applen koneiden käyttäjillä on tunnetusti varaa maksaa ylimääräistä, joten miksei sitten ottaisi asiakkaalta rahoja pois, kun sitä maksukykyä kerran on ?

Anonyymi kirjoitti:

"Delphin VCL komponetteja ei saanut siirrettyä selaimeen"

VALHE!

Delphin VCL komponenteilla pystyi tekemään ActiveX -sovelluksen.

Ja Delphi jopa osaa itse tuottaa html -lähdekoodin web -sivusta, joka lataa tuon ActiveX -sovelluksen ja käynnistää sen.

Ainoa on se, että jos halutaan, että sovellusta on helppo päivittää, niin muistaakseni pientä "viilausta" piti tehdä siihen, että html -koodi tarkistaa sovelluksen versionumeron, ja jos uudempi on tarjolla, lataa sen uudemman, eikä käytä välimuistissaan olevaa vanhempaa versiota (kuten oletuksena tapahtuisi, jos et itse laita asiaa kuntoon).

Toimi Microsoftin selaimella oikein hyvin !

Itse en kannata tuota M-Karin puffaamaa "aina käyttöliittymä selaimeen" -tyyliä.

Oikein on:
"käyttöliittymä selaimeen" silloin, kun sellaiseen on jokin erityinen tarve.
Jos tuollaista erityistä tarvetta ei ole, Delphin VCL ajaa asiansa oikein hyvin.

Kaupallisesti järkevä ratkaisu:
Ohjelman VCL -komponentteja käyttävä EXE maksaa X euroa.
Ja Applen koneiden käyttäjiä varten samasta sovelluksesta web -selaimessa toimiva versio, joka maksaa 2 * X euroa.

Applen koneiden käyttäjillä on tunnetusti varaa maksaa ylimääräistä, joten miksei sitten ottaisi asiakkaalta rahoja pois, kun sitä maksukykyä kerran on ?

Lue lisää

"Delphin VCL komponenteilla pystyi tekemään ActiveX -sovelluksen."

Ei ole sama asia. ActiveX pökäleet on jotain Windows juttuja. Selaimella toimivat ovat alustariippumattomia eikä ActiveX pökäleet ole toimineet aikoihin edes Windowsissa.

Katsos kun pääasia ei ole se, että toimii selaimessa vaan että toimii kaikissa mahdollisissa laitteissa missä on selain.

"Ja Delphi jopa osaa itse tuottaa html -lähdekoodin web -sivusta, joka lataa tuon ActiveX -sovelluksen ja käynnistää sen."

Ja sen pitää käynnistyä iPhonessa.

"käyttöliittymä selaimeen" silloin, kun sellaiseen on jokin erityinen tarve.

Ei nykyään ole mitään "erityistä tarvetta" vaan nykyään on sellainen oletus, että mitään ei tarvitse asentaa ja kaikki toimii joka laitteella. Jos jotain pitää asentaa tai rajoitetaan toimivuutta, siihen pitää olla joku syy.

Ja Applen koneiden käyttäjiä varten samasta sovelluksesta web -selaimessa toimiva versio, joka maksaa 2 * X euroa.

"Ohjelman VCL -komponentteja käyttävä EXE maksaa X euroa.
Ja Applen koneiden käyttäjiä varten samasta sovelluksesta web -selaimessa toimiva versio, joka maksaa 2 * X euroa."

Eli 3x euro.

Sen pitää toimia myös Playstationissa, Androidissa, iPhonessa, Ubuntussa, ChromeOS:ssa, Xboxissa ja kaikissa muissakin laitteissa ja kaikissa versioissa myös mitä on ihmisillä.

Parempi tehdä 0,5x euron hinnalla joka paikkaan kun nykyajan työkaluilla on tuottavampaa tehdä kuin VCL komponenteilla eikä tule typeriä rajoitteita.

Siihen pitää aina olla jokin erityinen syy tehdä kalliimmin ja huonommin.

"Selainsovellukset eivät koskaan korvaa työpöytäsovelluksia, se on tietoturvan vuoksi mahdotonta."

Käyttöliittymä ajaminen selaimella ei vaikuta tietoturvaan.

Anonyymi kirjoitti:

"Selainsovellukset eivät koskaan korvaa työpöytäsovelluksia, se on tietoturvan vuoksi mahdotonta."

Käyttöliittymä ajaminen selaimella ei vaikuta tietoturvaan.

Onhan se paljon kiinni minkä ohjelman liittymästä on kysymys, mutta jos selaimelle annetaan mahdollisuus muokata, kopioida, siirtää ja luoda käyttöjärjestelmässä ajettavia sovelluksia, samalla tavalla kuin työpöytäsovellukset tekevät, eihän sellaista järjestelmää uskalla käynnistää ollenkaan. Itsestään selvä asia.

Anonyymi kirjoitti:

Onhan se paljon kiinni minkä ohjelman liittymästä on kysymys, mutta jos selaimelle annetaan mahdollisuus muokata, kopioida, siirtää ja luoda käyttöjärjestelmässä ajettavia sovelluksia, samalla tavalla kuin työpöytäsovellukset tekevät, eihän sellaista järjestelmää uskalla käynnistää ollenkaan. Itsestään selvä asia.

Lue lisää

"Onhan se paljon kiinni minkä ohjelman liittymästä on kysymys, mutta jos selaimelle annetaan mahdollisuus muokata, kopioida, siirtää ja luoda käyttöjärjestelmässä ajettavia sovelluksia, samalla tavalla kuin työpöytäsovellukset tekevät, eihän sellaista järjestelmää uskalla käynnistää ollenkaan. Itsestään selvä asia."

Varmaankin viimeiset 25-vuotta on voinut tehdä pikakuvakkeita selaimella ajettaviin ohjelmiin laittamalla pikakuvakkeeseen linkki haluttuun osoitteeseen.

Selaimella ajettava ohjelma ei voi sitä ohjelmallisesti tehdä, eikä käyttöliittymän ajaminen edellytä sitä että ohjelma tekisi itse pikakuvakkeen itselleen.

Selaimet tavallisesti tekevät automaattisesti "viimeeksi käytetyt" listaan linkit mistä voi käynnistää jotain mitä on itse aiemmin käyttänyt mutta käyttöliittymää ajava ohjelma ei voi tuollaisia tehdä, eikä sen tarvitsekkaan.

Anonyymi kirjoitti:

"Onhan se paljon kiinni minkä ohjelman liittymästä on kysymys, mutta jos selaimelle annetaan mahdollisuus muokata, kopioida, siirtää ja luoda käyttöjärjestelmässä ajettavia sovelluksia, samalla tavalla kuin työpöytäsovellukset tekevät, eihän sellaista järjestelmää uskalla käynnistää ollenkaan. Itsestään selvä asia."

Varmaankin viimeiset 25-vuotta on voinut tehdä pikakuvakkeita selaimella ajettaviin ohjelmiin laittamalla pikakuvakkeeseen linkki haluttuun osoitteeseen.

Selaimella ajettava ohjelma ei voi sitä ohjelmallisesti tehdä, eikä käyttöliittymän ajaminen edellytä sitä että ohjelma tekisi itse pikakuvakkeen itselleen.

Selaimet tavallisesti tekevät automaattisesti "viimeeksi käytetyt" listaan linkit mistä voi käynnistää jotain mitä on itse aiemmin käyttänyt mutta käyttöliittymää ajava ohjelma ei voi tuollaisia tehdä, eikä sen tarvitsekkaan.

Lue lisää

Höpö höpö, lopeta tuo lässyttäminen.

Anonyymi kirjoitti:

Höpö höpö, lopeta tuo lässyttäminen.

Et oikeasti ole kertonyt yhtään mitään tapaa miten selain vaarataa tietoturvan.

Monissa käyttöjärjestelmissä on ennemminkin päinvastoin. Jos asentaa jonkun sovelluksen niin se saa mellastaa miten haluaa kyseisellä käyttäjätilillä. Selaimella ajettaessa toiminta on suojatumpaa.

Anonyymi kirjoitti:

"Selainsovellukset eivät koskaan korvaa työpöytäsovelluksia, se on tietoturvan vuoksi mahdotonta."

Käyttöliittymä ajaminen selaimella ei vaikuta tietoturvaan.

"Käyttöliittymä ajaminen selaimella ei vaikuta tietoturvaan"

Missä vaiheessa myönnät olevasi väärässä?

Riittäisikö se, jos julkaisen 2 tiedostoa:

BrowserInterceptorForFirefox.DLL

ja

LaunchFirefoxWithInterceptor.EXE

ylläolevat siis soveltuvat FIREFOXin vakoilemiseen.

Jos halutaan vakoilla Google Chromea, niin vielä 2 tiedostoa lisää:


BrowserInterceptorForChrome.DLL

ja

LaunchChromeWithInterceptor.EXE


Kun käyttäjä kopio nuo 2 tiedostoa (valitse oikein mitkä 2, sen mukaan, mitä selainta käytät) samaan hakemistoon, missä selaimen pää-EXE -tiedosto on,

niin tämän jälkeen tuo BrowserInterceptorForXXXXX.DLL

pystyy vakoilemaan selaimen TCP/IP -liikennettä selväkielisenä (siis salaamattomana) myös silloin, kun yhteys web -palvelimeen on toteutettu https -protokollalla.

Tässä toki on kyse siitä, että tietoisesti asennat nämä 2 tiedostoa omalle koneellesi, jolloin ko. koneen selainta voi helposti vakoilla.

Näppärä idea esim, jos selaimesi muistaa käyttäjätunnuksesi ja salasanasi jollekin sivustolle, mutta sinä et.

Tällöin voit tuon DLL:n avulla tallentaa selväkielisenä tiedostoon selaimen ja web -palvelimen välisen dataliikennöinnin molempiin suuntiin.

Lokitiedostosta voit sitten etsiä unohtamasi käyttäjätunnuksesi ja salasanasi.

Helppoa ja näppärää, omalla koneellasi.

Toki, jos joku haluaisi vakoilla jonkun toisen konetta, johon vakoilijalla ei ole fyysistä pääsyä noita DLL ja EXE -tiedostoja asentelemaan, silloin homma on vaikeampi, koska
silloin koneen tietoturva pitäisi pystyä murtamaan moisten asentamiseksi.

Silloin ei varmaankaan myöskään riitä, että se lokitiedosto menee sen saman koneen kiintolevylle, missä selainta ajetaan, vaan vakoilija varmaankin haluaisi nämä tiedostot itselleen.

Varsinkin, jos aikoo murtaa 64 -bit selaimen tietoturvan, niin homma on vaikea, koska tuossa tilanteessa ei tyypillisesti pysty kovin montaa tavua ajettavaa koodia koneelle ujuttamaan.

32- bit -puolella moinen murtautuminen on helpompi toteuttaa.

Mutta suurin osa käyttäjistä käyttää jo nyt 64 -bittistä selainta.

"täällä meuhkaavien olisi syytä jättää se ohjelmointi vähemmälle. Ja ottaa vaikka lapio ja lähteä kaivamaan ojaa. Saisitte älykkyyttänne vastaavan homman"

No HahHauskaa !

Entäpä, jos koodaan esittämäni pienet apuohjelmat selaimen vakoilemiseksi selväkielisenä, myös silloin, kun selain keskustelee palvelimen kanssa salattua https -protokollaa käyttäen ?

Omalle koneelleni voin tietenkin asentaa mitä haluan, ja käyttää hyödykseni, jos vaikkapa unohdan jonkun sivuston salasanan, mutta selain muistaa sen puolestani.

Mutta jos haluat koodin itsellesi, maksa siitä !