Mitä Delphin tilalle

Olen käyttänyt Delphiä noin viidentoista vuoden ajan. Viimeisin versio taitaa olla XE5. Osa tekemistäni sovelluksistä käyttää tietokantoja. Tietokannat toimivat yleensä sisäverkossa, mutta myös käyttö netin kautta on tarpeen.

Delphin nykyinen hinnoittelu antaa aiheen pohtia, miten Delphin voisi korvata. En ole löytänyt hyvää vaihtoehtoa. Löytyykö täältä varteenotettavia ehdotuksia?
Ilmianna
Jaa

39 Vastausta



Tietokantoja nyt käyttää melkein millä tahansa työkalulla ja Delphi on niin ikään korvattavissa melkein millä vaan, että enempi tarkennus olisi hyvä olla.

Yleensä asioita joilla on merkitystä on se, että onko tarkoitus tehdä frontendiä vai backendiä, ja kuinka paljon tai pitkään kestää asian prosessointi, että tuleeko jotain tapahtumilla ajettavaa vai säikeillä ajettavaa tekniikkaa. Tehtävän sovelluksen elinkaari- ja ylläpitokysymykset sitten merkitsee myös ja valittu tekniikka vaikuttaa siihen. Delphillähän se on esimerkiksi nykyään Windows 10 ympäristössä vuosittain Delphin päivittäminen uuteen versioon ja sovelluksen testaaminen pari kertaa vuodessa Windows 10 insiderissa ja uuden version kääntö tarvittaessa.

Tietokannat sitten lisäksi oma lukunsa ja nekin vaikuttavat kokonaisuuteen.

Yleisesti ottaen työkalut valitaan projektin mukaisesti. Sahalla on huono vasaroida nauloja ja jne. Yhdellä työkalulla jos meinaa selvitä niin sitä sitten tekee käytännössä yhdenlaisia ohjelmia koska valittu työkalu on kuitenkin monessa muussa asiassa niin paska.
Ilmianna
Jaa
Eikö luonnollinen vastaus ole Lazarus. Koodi on joitain poikkeuksetta lukuunottamatta yhteensopivaa.
http://www.lazarus-ide.org/
Kommentoi
Ilmianna
Jaa
1 VASTAUS:
Tavallaan joo. Lazarus on myös Debianissa vakaa jos sattuu sellaista ominaisuutta arvostamaan, että ei tarvitse olla testailemassa ja kääntelemässä niitä sovelluksia uudemmaksi vähän väliä jos sillä on merkitystä.

Se Lazarus vaan on aika paljon sellaiseen vanhojen Delphi sovellusten ylläpitoon. Uusille sovelluksille voisi miettiä kyllä jotain sopivampaa ja vanhoja sovelluksia voi sitten vähitellen siirtää uudemmalle tekniikalle.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Lazarus kääntyy eri käyttöjärjestelmille sujuvasti samalla koodilla. Se on hyvä juttu. Ja sillä voi tehdä kompakteja exe-paketteja ilman monenlaisia ajonaikaisia kirjastoja tai ajonaikaista tulkkia. se on kätevää. Jos Pascalin aikanaan oppinut selkäytimeen, niin Lazarus lienee hyvä vaihtoehto. Uuden kielen haltuunotto vie aina aikansa, vaikka perusteet ovat kaikissa samat. L:n mahdollisuudet verkkosovellusten tai mobiilisovellusten suhteen, siitä en ole varma. Kumma, että esim. RichText-konmponentti ja mediaplayer-komponentti edelleenkin puuttuu Lazaruksen peruskomponenteisista.
Delphi ainakin pelittää näissä, mutta mikä on sen tulevaisuus... Hinnoittele ainakin itsensä ulos peruskäyttäjä markkinoilta.
Kommentoi
Ilmianna
Jaa
1 VASTAUS:
"Lazarus kääntyy eri käyttöjärjestelmille sujuvasti samalla koodilla. Se on hyvä juttu. Ja sillä voi tehdä kompakteja exe-paketteja ilman monenlaisia ajonaikaisia kirjastoja tai ajonaikaista tulkkia. se on kätevää."

.exe:t voi unohtaa koska ne on Windows juttu. Lazarus tekee Windows ympäristössä koodia vanhentuneita rajapintoja vasten joita poistetaan parhaillaan, että siitä lähinnä seuraa harmia. Lazaruksella ei näytä olevan mitään tulevaisuutta Windows ohjelmoinnissa.

"Kumma, että esim. RichText-konmponentti ja mediaplayer-komponentti edelleenkin puuttuu Lazaruksen peruskomponenteisista."

Nuo on Deplhiin tulleet alunperin siitä, että se VCL kirjasto oli tehty lähinnä wrappaamaan WinAPI:a, jota taas hävitetään parhaillaan.

Ihan hyvästä syystä tuollaisia ei ole kun Lazarus toimii muualla kuin Windowsissa. Ja jos jostain poikkeussyystä vielä tekohengittää vanhoja ohjelmia Windowsissa, ihan hyvä että saa katkottua riippuvuuksia pilaantuvasta WinAPI koodista.

Ohjelmointikieli on vähän sivuseikka, uuden omaksuu niin nopeasti.

Lazaruksella ja Delphillä on aika vähän käyttöä uusien sovelluksien tekemisessä.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Noniin, piti testailla Lazaruksen 1.8-RC3 versiota pitkästä aikaan. Omalla koneella käytössä 27" 4K näyttö, ollut jo kohta pari vuotta ja Lazaruksen IDE on ollut käyttökelvoton tällä näytöllä.

Windowsin puolella IDE näyttäisi nyt hyvältä. Dialogit, kuvakkeet ja fontit on sopusuhtaisia, ei tarvi tihrustella :)

Linuxin puolella ikävä kyllä edelleen 1.6 version tasolla, täysin käyttökelvoton, harmi kun mieluummin Linuxin puolta kyttäisin. Pitänee katsoa löytyisikö mitään säätöjä millä saisi Linuxin puolellakin toimivammaksi tämän.

No mitään vakavaa en Lazaruksella ole nyt kehittämässä, lähinnä viihdekäyttöä ja Pascal kielen muisteloa ja pitää tutustua tuohon Castle 3D-moottoriin :)
Kommentoi
Ilmianna
Jaa
1 VASTAUS:
Hehee! IDE korjautui Linuxin puolella kerta laakista (Ubuntu Gnome 17.04)

Seuraavat komennot näytti "resolution: 96x96 dots per inch", vaikka muutoin skaalatut asetukset Gnomessa onkin?

xdpyinfo | grep dots

Korjausasetus:
xrandr --dpi 144x144

Voila! Lazaruksen IDE näyttää nyt samalta kuin Windowsin puolella :)

Hienoa!
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
M-Kar, et taida olla Windows-fani muutenkaan, mutta tarkoitatko, että Windows on pian menneen talven lumia? Aika paljon sillä käyttöjärjestelmällä käyttäjiä kuitenkin on. Ja Windows-ohjelmille käyttöä siis myös?
"Nuo on Deplhiin tulleet alunperin siitä, että se VCL kirjasto oli tehty lähinnä wrappaamaan WinAPI:a, jota taas hävitetään parhaillaan.-"
Mitä tilalle on tulossa, vai tarkoitatko, että koko Windows on kuolemassa, ja että sitä ei kannata käyttää? Graafinen käyttöliittymä säilynee kaikkialla joka tapauksessa käyttöjärjestelmäsä riippumatta (käyttäjäsyötteet texboxilla, tapahtumat pyydetään klikkauksilla ym. kaikki tämä lomakkeilla jne. jne.) Jollakin kielellä näitä käyttäen aina ohjelmoidaan.

".exe:t voi unohtaa koska ne on Windows juttu."
Mikä se executable-tiedosto muissa järjestelmissä sitten on, ohjelma on aina jossain tiedostossa josta se käynnistetään ilmeiestikin?
Jos rajapinnat vanhenee, eikö Lazarustiimi pysty tähän reagoimaan uusilla ratkaisuilla?
Kommentoi
Ilmianna
Jaa
4 VASTAUSTA:
"M-Kar, et taida olla Windows-fani muutenkaan"

Suhtaudun neutraalisti. Ei minulla ole mitään Windowsia vastaan.

"mutta tarkoitatko, että Windows on pian menneen talven lumia?"

En. Kyllä Windows pysyy pitkään markkinoilla.

"Ja Windows-ohjelmille käyttöä siis myös?"

Windowsille tehty viimeisen 10v aikana olemattoman vähän natiiveja sovelluksia. Lähes kaikki Windowsilla käytettävät sovellukset toimivat standardilla HTML5 tekniikalla ja natiivisti on pääasiassa viihdesovelluksia ja sitten on muutama ikivanha ja isolla rahalla ylläpidetty työkalusovellus mitä modernisoidaan kaiken aikaa.

"Nuo on Deplhiin tulleet alunperin siitä, että se VCL kirjasto oli tehty lähinnä wrappaamaan WinAPI:a, jota taas hävitetään parhaillaan.-"

"Mitä tilalle on tulossa"

90-luvun alussa tuli jo MFC mikä wrappasi sitä samaan tapaan kuin VCL. 2000-luvun alussa tuli .NET ja nykyisin on natiivina WinRT.

Kaikkia vanhoja rajapintoja hävitetään joten sovellukset tarvitsisi vähintäänkin kääntää uusiksi Visual C++ 2015 versiolla, .NET 4.x:lle, WinRT:lle tai sitten tehdä standarditekniikalla.

Siellä on riippuvuuksia vanhaan WinAPI:n että odotettavasti korkeammantason rajapinnan käyttämä toiminto joka on riippuvainen WinAPI:sta, pitää sitä toimintoa WinAPI:ssa. Sitä mukaa kun korkeamman tason rajapinnat vanhenee, niitä riisutaan WinAPI:sta pois.

,"vai tarkoitatko, että koko Windows on kuolemassa"

En usko Windowsin katoavan mihinkään lähitulevaisuudessa. Paskat ysärisovellukset kyllä menee uusiksi. Uudet ohjelmat harvemmin ovat riippuvaisia Windowsista millään tavalla.

"Graafinen käyttöliittymä säilynee kaikkialla joka tapauksessa käyttöjärjestelmäsä riippumatta (käyttäjäsyötteet texboxilla, tapahtumat pyydetään klikkauksilla ym. kaikki tämä lomakkeilla jne. jne.) Jollakin kielellä näitä käyttäen aina ohjelmoidaan."

Tällä hetkellä lähes aina Javascriptillä tai kielellä josta saadaan käännettyä Javascriptiksi.

"Mikä se executable-tiedosto muissa järjestelmissä sitten on, ohjelma on aina jossain tiedostossa josta se käynnistetään ilmeiestikin?"

Suurin osa ohjelmista käynnistetään linkistä joka avaa ohjelman selainikkunaan.

"Jos rajapinnat vanhenee, eikö Lazarustiimi pysty tähän reagoimaan uusilla ratkaisuilla?"

Käytännössä ei. Lazarusta ohjelmoidaan kuin 90-luvulla ja tämän LCL kirjasto on kasa paskaa. Pascal kieleltä ollaan tuomassa LLVM:n, että sitä saadaan varmaan kohta käännettyä Javascriptiksi mutta kyllä tuohon tarvitsisi jonkun järjellisen käyttöliittymäframeworkin/kirjaston.

Lazarusporukka ei ole millään tavalla yrittänyt edes tehdä siitä nykyaikaista, intressit ovat ennemminkin muinaisten Delphillä kirjoitettujen sovelluksien siirtämisessä Lazaruksessa ajettavaksi, että niille saadaan lisää käyttöikää.

Tuon tason muutoksien tekeminen laajoissa ohjelmissa ei tapahdu heti, eikä Lazarusporukka ole vielä edes aloittanut joten ei ole syytä odottaa mitään merkittävää parannusta missään järjellisessä ajassa.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"M-Kar, et taida olla Windows-fani muutenkaan"

Suhtaudun neutraalisti. Ei minulla ole mitään Windowsia vastaan.

"mutta tarkoitatko, että Windows on pian menneen talven lumia?"

En. Kyllä Windows pysyy pitkään markkinoilla.

"Ja Windows-ohjelmille käyttöä siis myös?"

Windowsille tehty viimeisen 10v aikana olemattoman vähän natiiveja sovelluksia. Lähes kaikki Windowsilla käytettävät sovellukset toimivat standardilla HTML5 tekniikalla ja natiivisti on pääasiassa viihdesovelluksia ja sitten on muutama ikivanha ja isolla rahalla ylläpidetty työkalusovellus mitä modernisoidaan kaiken aikaa.

"Nuo on Deplhiin tulleet alunperin siitä, että se VCL kirjasto oli tehty lähinnä wrappaamaan WinAPI:a, jota taas hävitetään parhaillaan.-"

"Mitä tilalle on tulossa"

90-luvun alussa tuli jo MFC mikä wrappasi sitä samaan tapaan kuin VCL. 2000-luvun alussa tuli .NET ja nykyisin on natiivina WinRT.

Kaikkia vanhoja rajapintoja hävitetään joten sovellukset tarvitsisi vähintäänkin kääntää uusiksi Visual C++ 2015 versiolla, .NET 4.x:lle, WinRT:lle tai sitten tehdä standarditekniikalla.

Siellä on riippuvuuksia vanhaan WinAPI:n että odotettavasti korkeammantason rajapinnan käyttämä toiminto joka on riippuvainen WinAPI:sta, pitää sitä toimintoa WinAPI:ssa. Sitä mukaa kun korkeamman tason rajapinnat vanhenee, niitä riisutaan WinAPI:sta pois.

,"vai tarkoitatko, että koko Windows on kuolemassa"

En usko Windowsin katoavan mihinkään lähitulevaisuudessa. Paskat ysärisovellukset kyllä menee uusiksi. Uudet ohjelmat harvemmin ovat riippuvaisia Windowsista millään tavalla.

"Graafinen käyttöliittymä säilynee kaikkialla joka tapauksessa käyttöjärjestelmäsä riippumatta (käyttäjäsyötteet texboxilla, tapahtumat pyydetään klikkauksilla ym. kaikki tämä lomakkeilla jne. jne.) Jollakin kielellä näitä käyttäen aina ohjelmoidaan."

Tällä hetkellä lähes aina Javascriptillä tai kielellä josta saadaan käännettyä Javascriptiksi.

"Mikä se executable-tiedosto muissa järjestelmissä sitten on, ohjelma on aina jossain tiedostossa josta se käynnistetään ilmeiestikin?"

Suurin osa ohjelmista käynnistetään linkistä joka avaa ohjelman selainikkunaan.

"Jos rajapinnat vanhenee, eikö Lazarustiimi pysty tähän reagoimaan uusilla ratkaisuilla?"

Käytännössä ei. Lazarusta ohjelmoidaan kuin 90-luvulla ja tämän LCL kirjasto on kasa paskaa. Pascal kieleltä ollaan tuomassa LLVM:n, että sitä saadaan varmaan kohta käännettyä Javascriptiksi mutta kyllä tuohon tarvitsisi jonkun järjellisen käyttöliittymäframeworkin/kirjaston.

Lazarusporukka ei ole millään tavalla yrittänyt edes tehdä siitä nykyaikaista, intressit ovat ennemminkin muinaisten Delphillä kirjoitettujen sovelluksien siirtämisessä Lazaruksessa ajettavaksi, että niille saadaan lisää käyttöikää.

Tuon tason muutoksien tekeminen laajoissa ohjelmissa ei tapahdu heti, eikä Lazarusporukka ole vielä edes aloittanut joten ei ole syytä odottaa mitään merkittävää parannusta missään järjellisessä ajassa.
Tyhjä tynnyri kaikista eniten kolisee.
Kommentoi
Ilmianna
Jaa
M-Kar. Lazaruksella voi siis tehdä ohjelmia Mac ja Linux ypäristöön ja vähät välittää näinWIN:sta. Eli se pascal-kielikö siinä närästää ja sen rajoitetteet(?) vai koko tapa tehdä graafisia sovelluksia Lazaruksella. Kysehän on lopulta siitä, miten tehdää mahdollisimman joustavasti toimivia ja käytettäviä ohjelmia käyttäjille, jotka niitä tarvitsevat.
Kommentoi
Ilmianna
Jaa
Lazarusko kirjoitti:
M-Kar. Lazaruksella voi siis tehdä ohjelmia Mac ja Linux ypäristöön ja vähät välittää näinWIN:sta. Eli se pascal-kielikö siinä närästää ja sen rajoitetteet(?) vai koko tapa tehdä graafisia sovelluksia Lazaruksella. Kysehän on lopulta siitä, miten tehdää mahdollisimman joustavasti toimivia ja käytettäviä ohjelmia käyttäjille, jotka niitä tarvitsevat.
"Eli se pascal-kielikö siinä närästää ja sen rajoitetteet(?) vai koko tapa tehdä graafisia sovelluksia Lazaruksella."

Pascal kieli on kyllä kauhea ja sehän ei ole minkään standardin mukainen enää. Heikko ilmaisukyky.

Mutta tuohan ei rajoitu pelkästään siihen se ankeus, vaan pitää ottaa huomioon stabiilius. Lazarus on käytännössä stabiili vain tyyliin jollain Debianilla. Muualle jos haluaa turvapäivitykset niin pyöräytetään Lazarusta uudemmaksi mikä vaikuttaa yhteensopivuuksiin.

Lazaruksen LCL komponenttikirjasto on karmea, tuohan ohjailee siihen, että komponentit tallentavat omaa tilaansa komponentteihin. Eli jos teet vaikka tekstinsyöttökentän niin työkalu ohjaa siihen, että sen kentän sisältö ja muutokset siihen tapahtuisi siinä komponentissa.

Tuollainen sotku oikein kerjää bugeja. Joku voi todistaa vapaasti vääräksi näyttämällä miten Lazaruksella käytetään LCL:ää tilattomasti. En sano etteikö onnistuisi mutta varmasti järkyttävää säätämistä.

Lazaruksella sovellukset ovat hölmösti riippuvaisia käyttöjärjestelmästä tai laitearkkitehtuurista. Sillä ei oikein saa käännettyä sovellusta kertaalleen niin, että sama sovellus toimisi sellaisenaan vaikka iPadissa tai PS4:ssä tai missä nyt haluaakaan. Se ei nimittäin standardia HTML5 API:a ympäristönä vaan sisältää virityksiä millä käytetään natiivisti käännettyjä rajapintoja.

Kaikki nuo harmit voi kiteyttää niin, että ei ole olemassa mitään tilannetta missä Lazarus olisi hyvä vaihtoehto uuteen projektiin. Vanhojen Dephiviritysten tekohengitykseen käy jotka odottavat uudelleenkirjoitusta.

"Kysehän on lopulta siitä, miten tehdää mahdollisimman joustavasti toimivia ja käytettäviä ohjelmia käyttäjille, jotka niitä tarvitsevat."

Ja miksi sitten joka tilanteessa löytyy parempia?
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Yli 5 vuotta nyt koodaillut PHP/JavaScript/jQuery/HTML näitä web-juttuja työkseni. Olen aina vähän tympääntynyt kun Delphillä oli aikoinaan niin hienoa lätkästä kontrolleja vain lomakkeille ja klikata toiminto koodattavaksi. Nykyään kaikki koodit on pillun päreinä eri tiedostoissa ja niissä pitää copy-pasteilla #id ja class -arvoja tiedostojen välillä, refressiä, refreshiä, debuggaus on hankalampaa JavaScriptin puolella jne. Eikö siis oikeasti piru ole järkevämpää tapaa koodailla web-sovellusta?

Joskus kyllä kaiholla muistelen 1990-lukua (ja 2000-alkua), hienoa Delphi aikaa :)
Kommentoi
Ilmianna
Jaa
10 VASTAUSTA:
Tuo nyt kuullostaa siltä, että projektisi rakenne on jotenkin sotkuinen. Vaikka nuokin ovat ikivanhoja tekniikoita niin kyllä sitä pystyy PHP kielellä lätkimään komponentteja lomakkeelle. Ideana toki se, että PHP komponentit renderöidään palvelinpuolella. Sitä PHP sovellusta voi sitten täydentää päätelaitteissa ajettavilla komponenteilla mitä tekee vaikka sillä jQueryllä.

Jokaisen komponentin toki voi pitää siististi omassa tiedostossaan ja niiden liittämisen voi tehdä lomakkeelle kuten palvelinpuolella renderöitävien komponenttien asettelun, koska ne saa kapseloitua PHP koodin sisään.

Ei tuollaista copypaste helvettiä ole missään oikeasti.

Tekniikka toki mennyt reiluti eteenpäin noista jQuery ajoista.
Kommentoi
Ilmianna
Jaa
Ei ole "minun projekti", oli tehty talossa jo yli 2 vuotta ennen kun minä aloitin. Nykyisin on jo niin laaja ettei hevin modernisoida vaikka toki parannuksia on tehty vuosien varrella (bootstrap). Mutta edelleen sitä että JavaScript-tiedostot on omana, sitten php/css/html tiedostot omanaan, näiden välillä on pakko tunnisteita copy-pasteilla siirrellä jotta homma toimii sitten selaimessa.

Komponentit kuten grid on aika sekava tapa aina copy-pastella se js-koodihäkkyrä liittää js-tiedostoon ja ne alustukset, joskus pitää muodostaa vielä PHP-koodissa että saa tietyt ominaisuudet käyttöön, huoh! Tuon kanssa tulee aina joskus ikävä Delphi aikoja, kun lätkäsi sen gridin vain lomakkeelle ja propertyt naksutteli hiirellä kohilleen.

Minun mielipide, mutta minusta webbisovellukset ei tunnu "oikeilta" sovelluksilta, vaan ne on vähän kuin joku gallup-lomake ja postaa tiedot eteenpäin, responsiivisuutta vaikea saavuttaa.
Kommentoi
Ilmianna
Jaa
ex-delphisti kirjoitti:
Ei ole "minun projekti", oli tehty talossa jo yli 2 vuotta ennen kun minä aloitin. Nykyisin on jo niin laaja ettei hevin modernisoida vaikka toki parannuksia on tehty vuosien varrella (bootstrap). Mutta edelleen sitä että JavaScript-tiedostot on omana, sitten php/css/html tiedostot omanaan, näiden välillä on pakko tunnisteita copy-pasteilla siirrellä jotta homma toimii sitten selaimessa.

Komponentit kuten grid on aika sekava tapa aina copy-pastella se js-koodihäkkyrä liittää js-tiedostoon ja ne alustukset, joskus pitää muodostaa vielä PHP-koodissa että saa tietyt ominaisuudet käyttöön, huoh! Tuon kanssa tulee aina joskus ikävä Delphi aikoja, kun lätkäsi sen gridin vain lomakkeelle ja propertyt naksutteli hiirellä kohilleen.

Minun mielipide, mutta minusta webbisovellukset ei tunnu "oikeilta" sovelluksilta, vaan ne on vähän kuin joku gallup-lomake ja postaa tiedot eteenpäin, responsiivisuutta vaikea saavuttaa.
"Mutta edelleen sitä että JavaScript-tiedostot on omana, sitten php/css/html tiedostot omanaan, näiden välillä on pakko tunnisteita copy-pasteilla siirrellä jotta homma toimii sitten selaimessa."

Mokailut on taidettu tehdä projektin perustamisvaiheessa, että ei ole rakennetta mietitty.

On täysin normaalia että jokaisella komponentilla on oma tiedostonsa. Sitten ne vaan laittaa paikalleen siihen käyttöliittymänäkymään ja asetetaan propertyt.

PHP nyt on templatekieli siihen HTML:n tuottamiseen, että PHP komponentit upottaa siihen HTML:n ja ne menee suoraan käsi kädessä. Ulkoasu tyyli nyt on erillinen, kaikkien komponenttien laajuinen. Kuten se Bootstrap. Modifierit saa kirjoitettua sinne PHP templaten sekaan tai jQuery komponentteihin.

Ja ne jQuery komponentit toki saa käärittyä PHP:n sisään, että siinä käyttöliittymä näkymässä se komponentti lisätään samalla tavalla ja propertyt asetetaan samalla tavalla. Ei tarvitse mitään copy pastettaa.

"Komponentit kuten grid on aika sekava tapa aina copy-pastella se js-koodihäkkyrä liittää js-tiedostoon ja ne alustukset,"

Siis miksi muka on tuollaista? Mistä ihmeen copypastesta puhut?

"Minun mielipide, mutta minusta webbisovellukset ei tunnu "oikeilta" sovelluksilta, vaan ne on vähän kuin joku gallup-lomake ja postaa tiedot eteenpäin, responsiivisuutta vaikea saavuttaa."

Siis kun tekee PHP:llä softaa, se toimii sivulatauksina, oletusarvoisesti. Jokainen käyttöliittymä näkymä ja sen päivitys tapahtuu oletusarvoisesti sivulatauksena.

Se toki kestää aina sen sekunnin kun avaa jonkun. Kaikkia asioita ei kuitenkaan pysty näin tekemään vaan tarvitaan reaaliaikaisuutta tai tapahtumapohjaista käyttöliittymää, että asioita käsitellään ilman sivulatauksia. Sitä varten on sitten ne jQuery komponentit.

Tuohon aikaan silloin vuosien 2000-2010 välillä sovelluksia tehtiin näin, että pääosa suorituksesta oli palvelimessa mikä renderöi sen näkymän ja sitten oli niitä reaaliaikaisuutta vaativia komponentteja siellä mitkä sitä vaati. Aluksi oli Java Appletit ja ActiveX:t, sekä Flash swf:t ja sitten tuli jQuery.

2010 lokakuussa tuli Angular joka siirsin sen renderöinnin käyttöliittymäpuolelle, että siinä ei ole ollut mitään vaikeata saavuttaa viimeisen 6v aikana laajempaakin webbisovellusta ilman sivulatauksia. Onelma on siinä, että käytätte teknologiaa joka oli kova juttu 10v sitten.
Kommentoi
Ilmianna
Jaa
Niin kyllä tiedän PHP:n toiminnan ja että tämän projektin ikä on kohta 10v. Ne php:t on siellä palvelimella ja ne muodostaa sen html-matskut ohjelmallisesti, tyyliin
<input type="text" id="#abc_nappi" class="tyylinappi aaa eew" value="<?php echo $bla_bla;?>">

Sitten se JavaScript pitää muodostaa ja ladata erikseen, jotka koskee tuota yhtä "sivua", sinne pitää erikseen koodailla sitten tuo toiminnallisuus $("#abc_nappi").click(function.. tyyliin <- tämä on minusta sitä kyrsää hommaa, etenkin jos koodia on tosi paljon. Selaimen debug-tilasta on onneksi apua.

Ennen CSS:t oli ympätty myös tuonne php-koodiin ja onneksi ne on nyt bootstrapin tultua erilliset, osa järjestelmää.

Mutta itse kaipaan semmoista "visuaalista" suunnittelua, mikä oli Delphissä, olkoon kuinka 1990-lukua tahansa, eli olisi ikään kuin designtime näkymä. Tosi ärsyttävän vanhanaikaista pelailla noiden tunnisteiden kanssa. Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta.

Varmasti nämä webbihommat on kehittyneet vuosien varrella, mutta se ei minun ikeniä naurata, olen töissä naimisissa tämän projektin kanssa (ja moni muu) tekemisissä ja välillä aina kaipaan Delphin helppoutta.
Kommentoi
Ilmianna
Jaa
jqGrid-komponentti, se on yksi helevetti, yrjö meinaa lentää aina kun tuota pitäisi muokata tai tehdä uusi, hyi!
http://www.trirand.com/jqgridwiki/doku.php?id=wiki:jqgridexamples

Voi elämän kevät kun Delphissä vain lätkäsi sen gridin formille, aika minimaalista koodia sitten sen datan hakeminen siihen ja eventeistä sai eri toiminnot klikattua koodit niihin.
Kommentoi
Ilmianna
Jaa
ex-delphisti kirjoitti:
Niin kyllä tiedän PHP:n toiminnan ja että tämän projektin ikä on kohta 10v. Ne php:t on siellä palvelimella ja ne muodostaa sen html-matskut ohjelmallisesti, tyyliin
<input type="text" id="#abc_nappi" class="tyylinappi aaa eew" value="<?php echo $bla_bla;?>">

Sitten se JavaScript pitää muodostaa ja ladata erikseen, jotka koskee tuota yhtä "sivua", sinne pitää erikseen koodailla sitten tuo toiminnallisuus $("#abc_nappi").click(function.. tyyliin <- tämä on minusta sitä kyrsää hommaa, etenkin jos koodia on tosi paljon. Selaimen debug-tilasta on onneksi apua.

Ennen CSS:t oli ympätty myös tuonne php-koodiin ja onneksi ne on nyt bootstrapin tultua erilliset, osa järjestelmää.

Mutta itse kaipaan semmoista "visuaalista" suunnittelua, mikä oli Delphissä, olkoon kuinka 1990-lukua tahansa, eli olisi ikään kuin designtime näkymä. Tosi ärsyttävän vanhanaikaista pelailla noiden tunnisteiden kanssa. Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta.

Varmasti nämä webbihommat on kehittyneet vuosien varrella, mutta se ei minun ikeniä naurata, olen töissä naimisissa tämän projektin kanssa (ja moni muu) tekemisissä ja välillä aina kaipaan Delphin helppoutta.
" Ne php:t on siellä palvelimella ja ne muodostaa sen html-matskut ohjelmallisesti, tyyliin
<input type="text" id="#abc_nappi" class="tyylinappi aaa eew" value="<?php echo $bla_bla;?>"> "

Tai sitten voisit tehdä komponentin sinne <?php ?> tagien väliin. Näkymän alkuun joku dependencyt lisäävä pulikka <?php ?> tagien väliin jos komponentti on vaikka jQuery komponentti niin lisää sen automaattisesti sen riippuvuudet.

"Sitten se JavaScript pitää muodostaa ja ladata erikseen, jotka koskee tuota yhtä "sivua", sinne pitää erikseen koodailla sitten tuo toiminnallisuus $("#abc_nappi").click(function.. tyyliin <- tämä on minusta sitä kyrsää hommaa, etenkin jos koodia on tosi paljon. Selaimen debug-tilasta on onneksi apua."

Joo ei. Sinne <?php ?> tagien väliin voi laittaa myös komponentin mikä on jQuery komponentti. Sitten se dependency management huolehtii sen komponetti.min.js lisäyksestä sivulatauksiin.

Ongelma tuntuu olevan teillä se, että teillä ei ole järkevää komponettiarkkitehtuuria käytössä. Koodi pitää kirjoittaa niin, että tehdään komponentteja ja niitä sitten lätkitään siihen näkymään ja laitetaan propertyt paikalleen, ja se on sitten se ja sama onko komponentti backendissä ajettava PHP komponentti vai frontissa ajettava jQuery komponentti. Propertyt saa siitä PHP:stä menemään heittämällä.

Sitä jQuery komponenttia ei tarvitse mitenkään kummallisesti muodostella, käännetty komponentti.min.js toimii itsenäisesti PHP komponentin propertyt voi välittää siihen, että niitä kutsutaan samalla tavalla.

"Mutta itse kaipaan semmoista "visuaalista" suunnittelua, mikä oli Delphissä, olkoon kuinka 1990-lukua tahansa, eli olisi ikään kuin designtime näkymä."

No onhan semmoinen.. Brackets + Chrome ja läiskii niitä bootstrap komponentteja siihen.
Kommentoi
Ilmianna
Jaa
ex-delphisti kirjoitti:
jqGrid-komponentti, se on yksi helevetti, yrjö meinaa lentää aina kun tuota pitäisi muokata tai tehdä uusi, hyi!
http://www.trirand.com/jqgridwiki/doku.php?id=wiki:jqgridexamples

Voi elämän kevät kun Delphissä vain lätkäsi sen gridin formille, aika minimaalista koodia sitten sen datan hakeminen siihen ja eventeistä sai eri toiminnot klikattua koodit niihin.
Miksi käyttää sitten tuommoista? Saahan ne lomakkeet rakennettua lätkimällä bootsrap komponenteilla: http://getbootstrap.com/css/#forms

Ja Braketsilla kun tekee designiä niin näkee tuloksen reaaliajassa Chromen ikkunassa.

"Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta."

Se että muokataan vain yhtä osaa ohjelmasta on sitä, että on ne komponentit. Sen sijaan toiminnallisuuden pitäminen näkyvästä osasta tulisi pitää mahdollisimman hyvin erillään toisistaan.

Oikein tehdyssä käyttöliittymässä on data ja sitten käyttöliittymä rakentuu sen datan mukaan.

Redux tekee tempun hienosti Reactille: http://redux.js.org/

Siinä käyttöliittymän tila on yksi .json mitä käsitellään. Kyseinen rakenne käytännössä poistaa silmukat, lähes kaikki if lauseet yms. joten koodista tulee hyvin selkeää ja virheetöntä. Ei siis ole mitään kaikkea dataa leviteltynä ympäri komponentteja minkä kuuluisi heijastaa käyttöliittymän tilaa. Se data syötetään tuosta niille komponenteille ja käyttöliittymä rakentuu datan mukaan. Siellähän voi olla esimerkiksi jossain 0-10 komponenttia jossain listassa niin tuo tekee sen automaattisesti riippuen sitä mitä sieltä json:sta löytyy. Mitään silmukoita ei tarvitse tehdä, että map ja reduce toimivat.

Vuelle löytyy vastaava Vuex: https://vuex.vuejs.org/en/

PHP jutuissa tehdään vastaavasto palvelinpuolella, että rakentaa sen käyttöliittymän johonkin array rakenteeseen mikä syötetään näkyviin.
Kommentoi
Ilmianna
Jaa
"PHP jutuissa tehdään vastaavasto palvelinpuolella, että rakentaa sen käyttöliittymän johonkin array rakenteeseen mikä syötetään näkyviin."

Ali PHP array -> javascript json data ? Näin olen tehnyt yhdessä jutussa missä pitää muodostaa useita hakemuksia ja niistä xml mikä lähetetään eteenpäin toiselle osapuolelle.

Kitti linkeistä pitää tutkailla noita, jospa ajan tästä projektista saisi järkevämmän.
Kommentoi
Ilmianna
Jaa
ex-delphisti kirjoitti:
"PHP jutuissa tehdään vastaavasto palvelinpuolella, että rakentaa sen käyttöliittymän johonkin array rakenteeseen mikä syötetään näkyviin."

Ali PHP array -> javascript json data ? Näin olen tehnyt yhdessä jutussa missä pitää muodostaa useita hakemuksia ja niistä xml mikä lähetetään eteenpäin toiselle osapuolelle.

Kitti linkeistä pitää tutkailla noita, jospa ajan tästä projektista saisi järkevämmän.
"Ali PHP array -> javascript json data ?"

Siis tarkoitin, että käyttöliittymän data on PHP arrayssä siitä sitten tuodaan komponentit mitä näytetään.

Tai jos käyttää valmista frameworkkia, kuten Symfonyä niin siinähän on sitten ne Twig templatet.

Periaatetasolla templatessa ei saisi olla yhtään ehtolausetta. Jos näin on niin jossain on jotain pielessä.
Kommentoi
Ilmianna
Jaa
ex-delphisti kirjoitti:
Niin kyllä tiedän PHP:n toiminnan ja että tämän projektin ikä on kohta 10v. Ne php:t on siellä palvelimella ja ne muodostaa sen html-matskut ohjelmallisesti, tyyliin
<input type="text" id="#abc_nappi" class="tyylinappi aaa eew" value="<?php echo $bla_bla;?>">

Sitten se JavaScript pitää muodostaa ja ladata erikseen, jotka koskee tuota yhtä "sivua", sinne pitää erikseen koodailla sitten tuo toiminnallisuus $("#abc_nappi").click(function.. tyyliin <- tämä on minusta sitä kyrsää hommaa, etenkin jos koodia on tosi paljon. Selaimen debug-tilasta on onneksi apua.

Ennen CSS:t oli ympätty myös tuonne php-koodiin ja onneksi ne on nyt bootstrapin tultua erilliset, osa järjestelmää.

Mutta itse kaipaan semmoista "visuaalista" suunnittelua, mikä oli Delphissä, olkoon kuinka 1990-lukua tahansa, eli olisi ikään kuin designtime näkymä. Tosi ärsyttävän vanhanaikaista pelailla noiden tunnisteiden kanssa. Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta.

Varmasti nämä webbihommat on kehittyneet vuosien varrella, mutta se ei minun ikeniä naurata, olen töissä naimisissa tämän projektin kanssa (ja moni muu) tekemisissä ja välillä aina kaipaan Delphin helppoutta.
"Delphillä on se näkyvä osa ja sen toiminnallisuuden toteutus aina hyvin "lähellä" toisistaan, eikä tarvi eri tiedostoja selailla levyltä, muokata kun tekee yhtä kohtaa ohjelmasta."

Saahan sitä koodin hierarkian rakennettua noin millä tahansa välineellä, että komponentin visuaalinen puoli vastaa sen toimintoa.

Delphissä taas oli perustavanlaatuisesti komponentit rikki kun ne tallensivat omaa tilaansa komponenttiin.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Se mikä oli vanhan liiton aikaan mukavaa oli ohjelmien toiminnan nopeus. Kaikki tapahtui hetkessä. Selainpohjaisuus tarkoittaa jatkuvaa odottelua. Tietty hyötyohjelma täytyy saada koneelle ja käyttää siinä, nopeasti ilman viiveitä. Sekunti on pitkä aika odotella esim. tekstin käsittelyssä. Syöttö on tahmaista ja sitten odottaa selain ruudun päivitystä. Video-, audio-, graafinen-ym editointityö ei pelitä selainpohjaisilla sovelluksilla. Kaikki, mikä on verkossa on väistämättä hidasta.
Kommentoi
Ilmianna
Jaa
1 VASTAUS:
"Se mikä oli vanhan liiton aikaan mukavaa oli ohjelmien toiminnan nopeus."

Ohjelmat toimii nykyään nopeasti. Ei ole muutoksia siinä.

"Selainpohjaisuus tarkoittaa jatkuvaa odottelua."

Ei tietenkään tarkoita.

"Tietty hyötyohjelma täytyy saada koneelle ja käyttää siinä, nopeasti ilman viiveitä."

Selainpohjaisesti saa nopeammin kun ei tarvitse asennella mitään, toimii tietysti ilman viiveitä.

"Sekunti on pitkä aika odotella esim. tekstin käsittelyssä."

Sekunnin viive liittyy vain sivulataukseen. Tekstiä kirjoitettaessa ei ole ikinä ollut mitään sivulatausta.

Ja sivulataus liittyy siihen kun ladataan toinen käyttöliittymänäkymä. Siis silloin ennen muinoin joskus 6v sitten. Eihän enää tarvita mitään sivulatauksia ellei nimenomaisesti rajata vaikka käyttöoikeuksia eri osiin ohjelmia.

"Syöttö on tahmaista ja sitten odottaa selain ruudun päivitystä."

Ei ole missään mitään tahmaisuutta.

"Video-, audio-, graafinen-ym editointityö ei pelitä selainpohjaisilla sovelluksilla."

Ei ole mitään merkitystä koska 99.99% ohjelmista ei ole mitään hemmetin median editointia. Eikä sekään ole mitenkään selvää että ei muka onnistuisi.

"Kaikki, mikä on verkossa on väistämättä hidasta."

Todista. On ihan helposti laskettavissa aikavaatimukset.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
"Ei ole mitään merkitystä koska 99.99% ohjelmista ei ole mitään hemmetin median editointia." M-Kar.
No mitä ne sitten on? Suurin osa ihmisistä käyttää Office pakettia (WIN tai ilmaisversiot) suurimman osan ajastaan tietokoneellaan. Tai sitten käsittelevät kuvia tms.
"Hemmetin" media-alan ammattilaiset käyttävät 2D/3D-graafisia sovelluksia (Adoben paketit), videoeditointi on arkityötä filmi ja TV-puolella, muusikot tekevät musiikkia musiikkisoveluksilla. Radion ja studioiden ammattilaiset audiosovelluksilla. MIkä näistä ei pelitä verkkoversiona. Verkossa puuhaillaan lähinnä nettisivuja, Youtubea ja mobiiliksoveluksia tiirailemassa. Mitään ammattimaista ei voi puuhata mobiili/tableteilla.
Kommentoi
Ilmianna
Jaa
5 VASTAUSTA:
"No mitä ne sitten on?"

Esim. erilaiset viestintä, CRM, CMS, ERP, PIM, osto- ja myyntireskontra, tiketöinti, projektinhallinta, varastonhallinta jne. Erilaiset toimialakohtaiset sovellukset kuten potilastietojärjestelmät, erilaiset anturit mitkä kerää tietoa ja niitä käsitellään, hallintajärjestelmät ties mihin vempaimeen.

Tässä vaikka vähän näitä bisnessovelluksia mitä käytetään töiden tekemiseen: https://www.getapp.com/

Siinä nyt on jo pelkästään yli 5000 sovellusta.

Siitä on hyvä lähteä että suurimmassa osassa sovelluksia on jokin tietokanta mikä kerää tietoa. Jos tätä ei käsitä, ei tajua yhtään mitään millä ihmiset tekee töitä.

"Hemmetin" media-alan ammattilaiset käyttävät 2D/3D-graafisia sovelluksia (Adoben paketit), videoeditointi on arkityötä filmi ja TV-puolella, muusikot tekevät musiikkia musiikkisoveluksilla."

Eli marginaalista puuhastelua. Jostain kumman syystä niitä tuhansia kuvankäsittelyohjelmia ei löydy. Huomioi että Adoben sovellukset ei pääse edes promilleen kaikista ammattisovelluksista. Sinä nyt jotenkin käännät todellisuuden päälaelleen että melkein kaikki sovellukset olisikin jotain mediasovellusta ja sitten kukaan ei vaikka lähetä pikaviestiä tai sähköpostia. Tai vaikka maksa laskuja.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"No mitä ne sitten on?"

Esim. erilaiset viestintä, CRM, CMS, ERP, PIM, osto- ja myyntireskontra, tiketöinti, projektinhallinta, varastonhallinta jne. Erilaiset toimialakohtaiset sovellukset kuten potilastietojärjestelmät, erilaiset anturit mitkä kerää tietoa ja niitä käsitellään, hallintajärjestelmät ties mihin vempaimeen.

Tässä vaikka vähän näitä bisnessovelluksia mitä käytetään töiden tekemiseen: https://www.getapp.com/

Siinä nyt on jo pelkästään yli 5000 sovellusta.

Siitä on hyvä lähteä että suurimmassa osassa sovelluksia on jokin tietokanta mikä kerää tietoa. Jos tätä ei käsitä, ei tajua yhtään mitään millä ihmiset tekee töitä.

"Hemmetin" media-alan ammattilaiset käyttävät 2D/3D-graafisia sovelluksia (Adoben paketit), videoeditointi on arkityötä filmi ja TV-puolella, muusikot tekevät musiikkia musiikkisoveluksilla."

Eli marginaalista puuhastelua. Jostain kumman syystä niitä tuhansia kuvankäsittelyohjelmia ei löydy. Huomioi että Adoben sovellukset ei pääse edes promilleen kaikista ammattisovelluksista. Sinä nyt jotenkin käännät todellisuuden päälaelleen että melkein kaikki sovellukset olisikin jotain mediasovellusta ja sitten kukaan ei vaikka lähetä pikaviestiä tai sähköpostia. Tai vaikka maksa laskuja.
Työkalut valitaan tarpeen mukaan.

Eihän tuolla mitä sovelluksia ihmiset enimmäkseen käyttää ole hevonperseen väliä sille, joka kehittää vaikka grafiikkasoftaa.
Kommentoi
Ilmianna
Jaa
102030405060 kirjoitti:
Työkalut valitaan tarpeen mukaan.

Eihän tuolla mitä sovelluksia ihmiset enimmäkseen käyttää ole hevonperseen väliä sille, joka kehittää vaikka grafiikkasoftaa.
Ei niin, mutta ei pidä tuputtaa marginaalijuttuja keskusteluun kun ei ole missään erikseen puhuttu mistään erikoistarpeista.

Eikä se asiaan mitenkään vaikuta koska sellaista poikkeustarvettakaan ei oikein ole missä kannattaisi uuteen projektiin ottaa Lazarus tai Delphi.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"No mitä ne sitten on?"

Esim. erilaiset viestintä, CRM, CMS, ERP, PIM, osto- ja myyntireskontra, tiketöinti, projektinhallinta, varastonhallinta jne. Erilaiset toimialakohtaiset sovellukset kuten potilastietojärjestelmät, erilaiset anturit mitkä kerää tietoa ja niitä käsitellään, hallintajärjestelmät ties mihin vempaimeen.

Tässä vaikka vähän näitä bisnessovelluksia mitä käytetään töiden tekemiseen: https://www.getapp.com/

Siinä nyt on jo pelkästään yli 5000 sovellusta.

Siitä on hyvä lähteä että suurimmassa osassa sovelluksia on jokin tietokanta mikä kerää tietoa. Jos tätä ei käsitä, ei tajua yhtään mitään millä ihmiset tekee töitä.

"Hemmetin" media-alan ammattilaiset käyttävät 2D/3D-graafisia sovelluksia (Adoben paketit), videoeditointi on arkityötä filmi ja TV-puolella, muusikot tekevät musiikkia musiikkisoveluksilla."

Eli marginaalista puuhastelua. Jostain kumman syystä niitä tuhansia kuvankäsittelyohjelmia ei löydy. Huomioi että Adoben sovellukset ei pääse edes promilleen kaikista ammattisovelluksista. Sinä nyt jotenkin käännät todellisuuden päälaelleen että melkein kaikki sovellukset olisikin jotain mediasovellusta ja sitten kukaan ei vaikka lähetä pikaviestiä tai sähköpostia. Tai vaikka maksa laskuja.
Noista sovelluksien määristä vielä. Määrät ei oikein ole mielekäs mittari näiden sovellustyyppien vertailemiseen.

Hyvien GUI työkalujen kehittäminen graafiseen, insinöörityöhön, jne. on paljon työläämpää kuin yksinkertaisia numero ja tekstitietoa käsittelevien sovellusten tuotanto.

Toisin sanoen, kynnys tehdä vaikka uusi laskutusohjelma tyhjästäkin on hyvin matala verrattuna siihen, että tekee uuden GUI työkalun vaativampaan graafiseen, piirtotyöhön, jne.

Tämä enimmäkseen selittää käyttöliittymältään yksinkertaisten business sovellusten hyvin suurta lukumäärää. Tuo 5000 on sekin reippaasti alakanttiin.

Siitä huolimatta, erilaisia graafisia ja piirto-ohjelmia muilta osin käytetään melkein alalla kuin alalla. Käyttökohteita on hyvin paljon markkinointi, insinöörialat, rakennus, teollisuus jne.

Toisaalta, vaikka jonkin ohjelmatyypin käyttäjäkunta olisi lukumääräisesti pieni, sen merkitys yhteiskunnallisesti voi edelleen olla erittäin suuri. Tästä hyvänä esimerkkinä vaikkapa elektroniikkateollisuuden EDA ohjelmistot, joita ilman nykyaikaisten IC piirien ja siis tietokoneidenkaan suunnittelu ei olisi ollut mahdollista. Ohjelman käyttäkunta marginaalisen pieni, mutta koko yhteiskunta hyötyy sen tuomista tuloksista nykyisenkaltaisen tietotekniikan muodossa.
Kommentoi
Ilmianna
Jaa
102030405060 kirjoitti:
Noista sovelluksien määristä vielä. Määrät ei oikein ole mielekäs mittari näiden sovellustyyppien vertailemiseen.

Hyvien GUI työkalujen kehittäminen graafiseen, insinöörityöhön, jne. on paljon työläämpää kuin yksinkertaisia numero ja tekstitietoa käsittelevien sovellusten tuotanto.

Toisin sanoen, kynnys tehdä vaikka uusi laskutusohjelma tyhjästäkin on hyvin matala verrattuna siihen, että tekee uuden GUI työkalun vaativampaan graafiseen, piirtotyöhön, jne.

Tämä enimmäkseen selittää käyttöliittymältään yksinkertaisten business sovellusten hyvin suurta lukumäärää. Tuo 5000 on sekin reippaasti alakanttiin.

Siitä huolimatta, erilaisia graafisia ja piirto-ohjelmia muilta osin käytetään melkein alalla kuin alalla. Käyttökohteita on hyvin paljon markkinointi, insinöörialat, rakennus, teollisuus jne.

Toisaalta, vaikka jonkin ohjelmatyypin käyttäjäkunta olisi lukumääräisesti pieni, sen merkitys yhteiskunnallisesti voi edelleen olla erittäin suuri. Tästä hyvänä esimerkkinä vaikkapa elektroniikkateollisuuden EDA ohjelmistot, joita ilman nykyaikaisten IC piirien ja siis tietokoneidenkaan suunnittelu ei olisi ollut mahdollista. Ohjelman käyttäkunta marginaalisen pieni, mutta koko yhteiskunta hyötyy sen tuomista tuloksista nykyisenkaltaisen tietotekniikan muodossa.
"Noista sovelluksien määristä vielä. Määrät ei oikein ole mielekäs mittari näiden sovellustyyppien vertailemiseen."

Määrät kertoo miten sitä sovelluskehitystä tehdään.

"Hyvien GUI työkalujen kehittäminen graafiseen, insinöörityöhön, jne. on paljon työläämpää kuin yksinkertaisia numero ja tekstitietoa käsittelevien sovellusten tuotanto."

Työläys riippuu kompleksisuudesta.

"Tämä enimmäkseen selittää käyttöliittymältään yksinkertaisten business sovellusten hyvin suurta lukumäärää. Tuo 5000 on sekin reippaasti alakanttiin."

Ei noissa business sovelluksissa aina ole mikään yksinkertainen käyttöliittymä. Tuotannonohjauksessa aika paljonkin toimintoja ja sitten kun kirjanpitoväline sisältää varastonhallinnat, reskontrat, laskutukset yms. niin ovat aika kompleksisia käyttöliittymältään.

Huomioi että sillä ei ole oikeastaan väliä onko käsiteltävä tieto kuvaa, tekstiä vai numeroita. Enemmän merkitsee kuinka kompleksinen se on. Esim. Kelan järjestelmät käsittelevät tekstiä ja numeroita mutta kyllähän ne ovat aika valtavan monimutkaiset ja sitten sielä sekin, että muuttuu kerran neljässä vuodessa suunnileen kun tulee lakimuutoksia.

Ja se kompleksisuus kannattaa ymmärtää niin, että jos on jokin hyvin kompleksinen, vanha ohjelma niin siinä voi olla sen takia käytössä joku vanha tekniikka kun ei ole vielä saatu modernisoitua ohjelmaa.

Normaalisti sovellusohjelman koodi alkaa olla vanhaa kuraa n. kahdentoista vuoden aikana ja alkaa kaivata uudelleen kirjoitusta. Sitten jos sitä koodia on paljon niin tarvitaan rekryillä iso lauma kehittäjiä tekohengittämään ja samalla asteittain modernisoida kun koodi alkaa mädäntyä kelvottomaksi.

Ja paino sanalla sovellusohjelman. Systeemitason jutut ja middlewaret voivat olla hyvinkin pitkäikäistä perustekniikkaa softapinossa korkeammalle mentäessä muutostarvetta tulee enemmän. Sitä aiheuttaa jo sekin, että 12v aikana on perinteisesti rautateknologia mennyt 100x nopeammaksi, halvemmaksi, pienemmäksi ja jne. Pitää ymmärtää että ei voi loputtomiin rakentaa softaa sen varaan että jollain modeemilla soitellaan johonkin numeroon missä softa kuuntelee merkkikomentoja ja tulostaa tekstiä. Maailma muuttuu.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
"Siinä nyt on jo pelkästään yli 5000 sovellusta." M-Kar.
Kun verkko kaatuu, mikään noista 5000 sovelluksesta ei toimi.
Tottakai mainitsemasi sovellukset ovat arkea liike-elämässä, mutta ne ovat vain osa normaalikäyttäjien sovelluksista myös ammattilaismaailmassa. Mediasisältötuotantoa ja monien alojen suunnittelutyötä ei käytännössä voi tehdä, kuin koneelle asennetuilla sovelluksilla. Itse en laskisi tärkeää asiakastyötä vain verkkosovelluksen varaan. Töitä täytyy pystyä jatkamaan myös silloin kun verkko on kaatunut. En tästä halua väitellä, koska itsekin toteat, että mainitsemani alat eivät ole sinun heiniäsi vaan mainitsemasi bisnes sovellukset, jotka tietenkin ovat parhaiten toteutettavissa mainitsemillasi tekniikoilla.
Kommentoi
Ilmianna
Jaa
7 VASTAUSTA:
"Kun verkko kaatuu, mikään noista 5000 sovelluksesta ei toimi."

Riippuu siitä onko asennettuna paikalliselle serverille tai miten paljon sovellus on tehty sietämään katkoksia verkkoyhteydessä.

Käytännössä ei ole mitään syytä miksi ei toimisi.

"mutta ne ovat vain osa normaalikäyttäjien sovelluksista myös ammattilaismaailmassa."

Niin, löytyy lukemattomia muita mitä ei tuolla ole ja ne toimivat niinikään vastaavasti normaalilla arkkitehtuurilla missä käyttöliittymä pidetään erillään datasta.

"Mediasisältötuotantoa ja monien alojen suunnittelutyötä ei käytännössä voi tehdä, kuin koneelle asennetuilla sovelluksilla. "

Tuskin löytyy mitään sellaista sovellusta mitä ei voisi tehdä niin, että vain käyttöliittymä on paikallisesti asennettuna. Kaikki mediasovellukset nyt ainakin ovat sellaisia. Useimmat vielä onnistuu tekemään standarditekniikalla.

"Töitä täytyy pystyä jatkamaan myös silloin kun verkko on kaatunut."

Et edelleenkään perustellut miksi työnteko loppuisi siihen vaikka WAN-yhteys vähän pätkisi. Tuo on jotain harhaa että ei muka saisi tehtyä toimimaan myös ilman jatkuvaa verkkoyhteyttä.
Kommentoi
Ilmianna
Jaa
"Kun verkko kaatuu, mikään noista 5000 sovelluksesta ei toimi."

Eikä toimi myöskään mainitsemasi tv-teollisuuden mediasoftat. Katos ku ammattilaiskäytössä ne toimii pelkän keskusmuistin varassa ilman kovalevyjä ja kaikki työ on tallennettu verkkopalvelimille. Tosin nykyään kaikki vähänkin kriittiset järjestelmät on replikoitu useamalle palvelimelle ympäri maailmaa ja aina on varayhteys käytettävissä. Esim. yhdessä meidän myyntijärjestelmässä replikointipalvelimet sijaitsee hollannissa ja jenkeissä.
Kommentoi
Ilmianna
Jaa
code_red kirjoitti:
"Kun verkko kaatuu, mikään noista 5000 sovelluksesta ei toimi."

Eikä toimi myöskään mainitsemasi tv-teollisuuden mediasoftat. Katos ku ammattilaiskäytössä ne toimii pelkän keskusmuistin varassa ilman kovalevyjä ja kaikki työ on tallennettu verkkopalvelimille. Tosin nykyään kaikki vähänkin kriittiset järjestelmät on replikoitu useamalle palvelimelle ympäri maailmaa ja aina on varayhteys käytettävissä. Esim. yhdessä meidän myyntijärjestelmässä replikointipalvelimet sijaitsee hollannissa ja jenkeissä.
"aina on varayhteys käytettävissä"

Minkälainen varayhteys? Jos sattuu tilanne, että joku sabotööri laittaa ne harvat merikaapelit poikki, mitkä suomenkin yhdistää muuhun maailmaan, niin se on sitten siinä.

Vaikka joku varayhteys olisikin, se todennäköisesti olisi hyvin ruuhkainen tilanteen ollessa päällä.

Ei ole oikein vielä ollut sellaista aikaa, että internet olisi kunnolla poikki, esim niin, että vaikka Suomen yhteydet olisi eristyksissä. Tosin onhan niitä pieniä häiriöitä ollut aina välillä, esim soneralla ja elisalla, ettei ruotsin kautta menevä liikenne ole päässyt läpi puoleen tuntiin tai tuntiin. Kyllä se aika reippaasti rajoittaa . . . .

TV-teollisuuden softien toimimattomuus nyt ei olisi kovin iso menetys, niin heikkoa on tuo ohjelmatarjonta muutenkin.
Kommentoi
Ilmianna
Jaa
102030405060 kirjoitti:
"aina on varayhteys käytettävissä"

Minkälainen varayhteys? Jos sattuu tilanne, että joku sabotööri laittaa ne harvat merikaapelit poikki, mitkä suomenkin yhdistää muuhun maailmaan, niin se on sitten siinä.

Vaikka joku varayhteys olisikin, se todennäköisesti olisi hyvin ruuhkainen tilanteen ollessa päällä.

Ei ole oikein vielä ollut sellaista aikaa, että internet olisi kunnolla poikki, esim niin, että vaikka Suomen yhteydet olisi eristyksissä. Tosin onhan niitä pieniä häiriöitä ollut aina välillä, esim soneralla ja elisalla, ettei ruotsin kautta menevä liikenne ole päässyt läpi puoleen tuntiin tai tuntiin. Kyllä se aika reippaasti rajoittaa . . . .

TV-teollisuuden softien toimimattomuus nyt ei olisi kovin iso menetys, niin heikkoa on tuo ohjelmatarjonta muutenkin.
Mitä ne merikaapelit siihen vaikuttaa kun serveri on omassa lähiverkossa?
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Mitä ne merikaapelit siihen vaikuttaa kun serveri on omassa lähiverkossa?
Sovellus hakee vaikka fontit googlen palvelusta, siitä huolimatta että ajat sitä localhostina, myös tämä sivu tekee noin, luultavasti suurin osa verkkosovelluksista tekee noin. Pitääkö kertoa miksi ?
Kommentoi
Ilmianna
Jaa
r67ti7t8oiii kirjoitti:
Sovellus hakee vaikka fontit googlen palvelusta, siitä huolimatta että ajat sitä localhostina, myös tämä sivu tekee noin, luultavasti suurin osa verkkosovelluksista tekee noin. Pitääkö kertoa miksi ?
Ei vaikutakkaan jos on omassa verkossa.

Googlen fontit jos ei löydy, niin selain itseaisassa korvaa fontin seuraavalla listassa, että se ei vielä estä ohjelman toimintaa . . .
Kommentoi
Ilmianna
Jaa
10203040506 kirjoitti:
Ei vaikutakkaan jos on omassa verkossa.

Googlen fontit jos ei löydy, niin selain itseaisassa korvaa fontin seuraavalla listassa, että se ei vielä estä ohjelman toimintaa . . .
Sitä ennen haetaan cachesta.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti

Vastaa alkuperäiseen viestiin

Mitä Delphin tilalle

Olen käyttänyt Delphiä noin viidentoista vuoden ajan. Viimeisin versio taitaa olla XE5. Osa tekemistäni sovelluksistä käyttää tietokantoja. Tietokannat toimivat yleensä sisäverkossa, mutta myös käyttö netin kautta on tarpeen.

Delphin nykyinen hinnoittelu antaa aiheen pohtia, miten Delphin voisi korvata. En ole löytänyt hyvää vaihtoehtoa. Löytyykö täältä varteenotettavia ehdotuksia?

5000 merkkiä jäljellä

Peruuta