Sattumalta tulee vapaa-aikaa ja ajatukseni on tehdä erikoistuneeseen käyttötarpeeseen ohjelmisto, jota käytetään selaimella pilvestä.
Tunnen vuosien takaa basic-, fortran ja C -ohjelmointia, mutta niillä en tehnyt nettijuttuja. Nyt olisi ajatus siirtää samaa aluetta nettiin muidenkin käyttöön.
Alustavan kaavion mukaan yhdessä sovelluksessa olisi noin 20 tiedostoa (modulia).
Ohjelma käyttää tietokantaa ja on vuorovaikutuksessa käyttäjän kanssa; kyselee tietoja, päivittää tietokantaa ja antaa tuloksia.
Ohjelmassa olisi hyödyksi käyttää vähän kaaviomaista grafiikkaa. Pylväskaavioita ja monikulmioita yms, jotka piirretään datan avulla havainnollistamaan tulosta.
HTML ei sovellu, mm. koska koodia ei haluta nähtäväksi, vaikka jopa HTML sinänsä riittäisi aika pitkälle.
Olisiko parempi tutustua PHP- vai Python-ohjelmointiin? En ole löytänyt vertailua.
Python, PHP vai joku muu?
18
1431
Vastaukset
- Anonyymi
Teet niin tyhmiä rajauksia, etten usko sinun pystyvän toteuttamaan aikeitasi, tai edes ymmärtämään asiaan liittyviä ohjeita, unohda koko juttu, ei sinusta ole siihen ainakaan 10 vuoteen vielä.
- Anonyymi
En uskalla käyttää windowsia.
- Anonyymi
No jos ei jaksa opetella kuin yhden kielen, niin sitten JavaScript, jolla hoituu backend (esim. Node.js/Express) ja samalla kielellä voi käskyttää selainta.
Jos taas haluaa opetella kaksi kieltä, niin sitten vaikka Pythonilla (esim. Django) backki, ja JavaScriptillä selainpuoli.
JavaScriptin syntaksi on lähempänä C :aa.- Anonyymi
Ei windows edes toimi, aina se on nurin!
- Anonyymi
Eli siis tarkoitus on tehdä palvelinpuolella toimiva ohjelma joka tekee jotain datalle, ja selaimessa sitten käyttöliittymä.
Tällaisessa kannattaa käyttää mahdollisimman paljon valmiita komponentteja, että kieltä tärkeämpää on ymmärtää vaatimukset ja minkälaiset integraatiot löytyy.
Muutama olennainen kysymys..
Millaista se data on? Eli onko kyseessä jotain missä sopivinta on key-value, tripletstore tms. graafi, relaatiodataa, dokumenttikanta vai ihan vaan joku logi?
Kuinka paĺjon dataa on ? Alle 100 megaa? Yli neljä gigaa?
Minkälaisia samanaikaisia käyttäjämääriä olisi tarkoitus palvella? Valitaan aivan eri työkalut jos tekee lähiverkkoon jonkun Raspberry Pin joka palvelee muutamia ihmisiä kuin että palvelu olisi tarkoitus skaalata kymmenelle tuhannelle.
Tarvitaanko redundancyä?
Pitääkö voida skaalata horisontaalisesti lisäämällä tietokantanodeja?
Pitääkö datan olla konsistenttia, eli aina luettaessa saadaan viimeisin tieto tai virhe?
Entä partition tolerance, pitääkö järjestelmän toimia vaikka jotain viestejä putoaa tai viivästyy verkon takia?
Tarvitseeko datalle voida tehdä ad hoc queryjä?
Haittaako jos sähköjen katkeaminen hukkaa dataa?
Miten käyttäjän autentikointi ja auktorisointi on tarkoitus tehdä? Kanta, propertyfile, .htpasswd, LDAP, OAuth2, webauth, OTP Auth jne.
Onko ratkottava logiikka ns. bisneslogiikkaa vai jotain matemaattisempaa?
Tuleeko hakutoimintoa?
Noilla kysymyksillä voi ratkoa sen backendpuolen että mikä framework ja kieli sinne.
---
Selaimen päähän tarvitsisit sitten jonkun palikan millä visualisoida dataa.
Valmiita palikkaa tähän olisi vaikka D3.js, React-vis, Webdatarocks, ApexCharts, Chart.js, Echarts, Frappe Charts..
Käyttöliittymässä pitäisi miettiä ulkoasu, että tarvitseeko sen näyttää Androidilta, Windowsilta, Twitteriltä vai miltä?
Käyttöliittymäohjelmointiin itsessään jos tarvitsee niin toimisi React ja joku frontframework ulkoasun mukaan. Käyttöliittymäpuolelle on monia kieliä kuten backendiin mutta visualisoinnin integroimisen helpottamiseksi tässä voisi käyttää Typescriptiä.
Selaimessa toimiva käyttöliittymäkoodi näkyy joka tapauksessa maailmalle mutta jos itse käyttöliittymän logiikkakin halutaan salata ja toimia puhtaasti sivulatausten varassa niin voi sen Reactin jättää pois. Taulukotkin voi renderöidä palvelimella että lähetetään valmiiksi renderöity kuvatiedosto. Sivulataukset vaan hidastavat, ja taulukoiden renderöinti palvelimella kuormittaa palvelinta, eikä siinä oikein mitään salattavaa ole kun visualisointikirjastojen koodi on kuitenkin julkista. Pari riviä Typescriptiä mikä lataa palvelimelta sen visualisointidatan ja näyttää komponentissa ei itse bisneslogiikkaa kuitenkaan paljasta.
---
Sen lisäksi, koko kehittäminen lähtee API kuvauksesta. Eli mitä se ohjelma tekee. Se on vaikka vain CRUD: https://en.wikipedia.org/wiki/Create,_read,_update_and_delete
Mieluiten kirjoittaa sen API kuvauksen vaikka OpenAPI:lla niin löytyy työkaluja joilla voi vaikka generoida koodia joillekin kielille. Toinen vaihtoehto jota voi käyttää on GraphQL. Riippuu niinikään sovelluksesta mitä kannattaa käyttää: https://www.mobilelive.ca/blog/graphql-vs-rest-what-you-didnt-know/
---
Tarkenna vähän sitä minkälaisen sen sovelluksen pitäisi tarkalleen olla niin voisi vähän tarkentaa tuosta millä välineillä tekee? PHP:tä tuskin kannattaa ottaa käyttöön uuteen sovellukseen jos voi valita, vaikka sillä toki onnistuu kytkemään käyttöliittymän ja datan tallennuksen. Python valitaan usein tekoälysovelluksiin, testaukseen ja datatutkijoiden käyttöön.
Ei ole mitenkään selvää, että ongelmaa kannattaisi ratkoa yhdellä kielellä vaikka onkin mahdollista kirjoittaa backend sekä frontend yhdellä kielellä.- Anonyymi
Windowsilla ei voi edes tulostaa!
- Anonyymi
Kun luottamus omiin kykyihin on heikko, voi olla vaikeaa edes yrittää, mikä heikentää edelleen uskoa omiin mahdollisuuksiin. Tämä voi hankalimmillaan johtaa mielenterveyden ongelmiin kuten masennukseen tai ahdistukseen sekä edesauttaa syrjäytymistä. Siksi on tärkeää, että itsetunnon ongelmiin haetaan tarvittaessa apua.
- Anonyymi
Kysymys oli tosiaan Python vs PHP. Kummalla lähtisi tehtävää lähestymään?
Millaista se data on?
V: Puhtaasti numeroarvoja ja lyhyitä tekstiarvoja, MYSQL-tietokanta riittää.
Kuinka paĺjon dataa on ? Alle 100 megaa? Yli neljä gigaa?
V: Arviolta 5 taulua, isoimman koko alle 10.000 riviä ja alle 30 saraketta desimaalilukuja, muut selvästi pienempiä eli ei paljon mitään. Toiseksi isoin kasvaa hitaasti, 5 saraketta ja x riviä. Siivous jos joku muu kasvaa paljon.
Minkälaisia samanaikaisia käyttäjämääriä olisi tarkoitus palvella?
V: Arviolta max 100 yhtäaikaista.
Tarvitaanko redundancyä?
V: Enpä usko että tarvitaan. Varmuuskopiointi tietenkin on, mutta sekin vain päivittäin.
Pitääkö voida skaalata horisontaalisesti lisäämällä tietokantanodeja?
V: Ei
Pitääkö datan olla konsistenttia, eli aina luettaessa saadaan viimeisin tieto tai virhe?
V: Ei. Käsittelyssä tarvittava data ei muutu, tallenteet kertyvät ja niitä katsellaan omaan tahtiinsa.
Entä partition tolerance, pitääkö järjestelmän toimia vaikka jotain viestejä putoaa tai viivästyy verkon takia?
V: Ei vaikuta tämän tyyppiseen järjestelmään
Tarvitseeko datalle voida tehdä ad hoc queryjä?
V: Ylläpito voi tehdä, ei käyttäjät.
Haittaako jos sähköjen katkeaminen hukkaa dataa?
V: Hukka on hyvin vähäistä, ei haittaa ja on varsin epätodennäköistä.
Miten käyttäjän autentikointi ja auktorisointi on tarkoitus tehdä?
V: Tämä on jo tehty nykyisessäkin, käyttäjätunnus ja salattu salasana tietokannassa sekä yksi muu käyttäjän attribuutti.
Onko ratkottava logiikka ns. bisneslogiikkaa vai jotain matemaattisempaa?
V: Pääosin matemaattista tiedonkäsittelyä
Tuleeko hakutoimintoa?
V: Käyttäjän tunnistus, tietojen täyttämisen yhteydessä valintalistojen haku ja talletettujen tietojen raportointi kiinteillä valinta-avaimilla.
Selaimen päähän tarvitsisit sitten jonkun palikan millä visualisoida dataa.
V: tällä hetkellä data piirretään JS Graphics ja riittää jatkossakin.
Käyttöliittymässä pitäisi miettiä ulkoasu, että tarvitseeko sen näyttää Androidilta, Windowsilta, Twitteriltä vai miltä?
V: Käyttö vain selaimella tietokoneella ja tabletilla, kännykkää ei.- Anonyymi
Windows vuotaa ja vakoilee, ei kiitos!
- Anonyymi
"Kysymys oli tosiaan Python vs PHP. Kummalla lähtisi tehtävää lähestymään?"
Onko jotain syytä miksi rajoittaa näihin kahteen? Liittyykö se jotenkin hostaukseen?
Näistä kahdesta, nginx palvelin, PHP7 , Symfony 5.4 frameworkilla, on paljon suorituskykyisempi kuin Python. Mutta kun kyse on matemaattisesta tiedonkäsittelystä niin niin Pythonilla todennäköisesti kivempi kirjoittaa funktionaalisempaa koodia, siinä lazy evaluationia ja kivempi data-analyysia tehtäessä. Tuolla käyttäjämäärällä Pythonin hitaampi suorituskyky ei pitäisi haitata, etenkin kun ne raskaammat laskennat on kuitenkin kirjastoituna. Pythonyssä numpy ja vastaavat kilkkeet ovat kivoja.
Mutta kun se PHP:n valtti Pythoniin nähden oli se suorituskyky mutta kun löytyy suorituskykyisempiä ja paremmilla työkaluilla varustettuja ekosysteemejä niin en nyt tuota ottaisi, että jos suorituskykyä haluaa niin sitten ennemmin vaikka vert.x.
---
Tämän kuvauksen perusteella, relaatiokanta varmaan on ihan hyvä valinta tässä että jos se on jo MySQL, sen vaihtamisesta ei tässä kohtaa saa mitään hyötyä. Melkein millä tahansa välineellä saa integraatiot siihen että se ei rajoita.
Aloittaisin hommat siitä, pidä olemassa oleva data MySQL:ssä ja muotoile ensiksi rajapinta palveluille OpenAPI:lla, sopiva työkalu tähän on esimerkiksi Swagger: https://swagger.io/
Sitten kun ajatus kirkastuu paremmin mikä on sopivin kieliekosysteemi niin sen OpenAPI kuvauksen voi generoida koodin pohjaksi, että voi sitten ohjelmoida niin Django/Flask frameworkeilla Pythonilla tai Symfony/PHP:llä, tai jos suorituskykyä kaipaa niin vaikka vert.x, ja saa generoitua koodin myös fronttiin mihin voit kytkeä datan piirron.
Avainjuttu siis on se, että sillä on melko vähän merkitystä mikä se kieli on kun sinulla on deklaratiivisesti muotolitu API kuvaus jolla kuitenkin yhdistellään valmiita palikoita kuten MySQL kantaa ja frontissa olevaa grafiikan piirtoa. Enemmän ratkaisee palikat mitä saa siihen kiinni ratkaisemaan ongelman. - Anonyymi
"Käyttö vain selaimella tietokoneella ja tabletilla, kännykkää ei."
Tarkoitin ulkoasutyyliä. Että jos on kaikki softat Googlelta niin voi tehdä sen softan googlen ulkoasutyylillä. Jos on kaikki softat Microsoftilta niin voi tehdä Microsoftin ulkoasutyylillä.
Tai sitten joku muu.
- Anonyymi
Edellä joku huuteli ettei Windowsilla voi tulostaa. Lieneekö sitten ulostamista, mutta sujuvasti tulee.
- Anonyymi
Eihän windows tulostakaan!
- Anonyymi
Joku traumatisoitunut potilas, kannattaa ignoorata. Mitähän se edes hakee tuolla windows sekoilulla, että okke hyvä, nyt ihmiset vaihtaa joukolla linuxiin ='D. Ja käytän kyllä ite molempia, molemmissa omat ja hyvät puolet.
- Anonyymi
PHP:ta upotetaan yleensä HTML:n sekaan - voi siis vaikka täyttää taulukon luomalla sen PHP:llä oikeaan kohtaan HTML-koodia. Näin syntyy dynaaminen verkkosivu joka näyttää eri käyttäjille kustomoituja näkymiä helposti. Admin tunnukset? Ei ongelmaa! Näytetään admin-kentät sivusta.
Python-puolella homma menee ennemminkin niin päin, että generoidaan html - ei siis sinällään täytetä mitään sapluunaa vaan luodaan sellainen. Tällaista varten on olemassa mm. generaattoreita, joilla voi luoda kyselylomakkeen helposti ja saada tiedot suit sait tietokantaan.
Molempi parempi siis. Skriptauksen nopeus voi tulla kuitenkin esteeksi - jos näin käy, pitää luultavasti koodata homma nopeammilla ohjelmointikielillä - enkä tässä kohtaa välttämättä jättäisi edes C:tä pois laskuista. Jokin datan näyttämiseen soveltuva ohjelma voi myös toimia palvelimella siten, että kuva generoidaan dynaamisesti tietokannasta reaaliajassa - käyttäjä luulee hakevansa .png-tiedoston, mutta vastatta on ohjelma. HTTP antaa kehittäjälle yllättävän vapaat kädet teknologian valinnan suhteen - mutta väärillä valinnoilla on aina seurauksensa jotka joko tulevat vastaan heti tai alkavat vaikuttaa käytettävyyteen jossakin vaiheessa käyttäjämäärän kasvaessa..- Anonyymi
PHP toki lähti siitä, että se on templatekieli mutta ei se ohjelmointi ole aikoihin ollut sellaista. Backendiä tehtäessä ei oikeastaan ole mitään HTML:ää. Backendissä tehdään lähinnä HTTP:llä toimivia servicejä mutta kieli on vapaa.
Kyllä sen suorituskyvyn saa hoidettua jos vain on rahaa maksaa enemmän palvelimista. Yleensä pyritään optimoimaan tuota että palvelinkustannukset pysyvät pieninä.
Siellä suorituskykyyn vaikuttaa sitten aika monta tekijää, että se ei pelkällä kielellä ratkea. Tapahtumapohjainen palvelin, käyttöliittymään liittyvän prosessoinnin pitäminen poissa, tietokannan suunnittelu ja valitseminen oikein, skaalattavuus, cachet ja myös api suunnittelu ovat merkittäviä.
Se lähtee kuitenkin siitä, että tunnistaa mistä palveluista se sovellus koostuu ja rakentaa jokaisen palvelun omaksi komponentiksi. Ne voi kirjoittaa vaikka eri kielillä jos siltä tuntuu, tarpeen mukaan. Itse esimerkiksi kirjoitan parhaillaan sovellusta joka koostuu useasta palvelusta joista puolet on kirjoitettu Javalla ja puolet Pythonilla, ja näitä sitten kysellään käyttöliittymästä ja palvelut myös kommunikoivat keskenään.
- Anonyymi
K: Onko jotain syytä miksi rajoittaa näihin kahteen? Liittyykö se jotenkin hostaukseen?
V: Koski siis isoa linjaa. Scriptiä tulee väkisinkin mukaan.
Eroaako PHP ja Python toisistaan jotenkin turvallisuusmielessä? Taitaa mysql olla kuitenkin se kriittisin osa turvallisuuden kannalta.- Anonyymi
Mutta miksi rajoittaa näihin? Mihin unohtui Java, Go, Scala, Ocaml/Reason, Typescript jne. ?
Turvallisuusmielessä kielellä ei ole niinkään merkitystä vaan sillä, että onko se API miten suunniteltu, sanitoitu syöte, onko palvelimet konfiguroitu oikein ja pidetäänkö päivitettynä.
Joka tapauksessa, lähde siitä että muotoilet sen API:n OpenAPI 3 kuvauksena jota käytät contractina niin käyttöliittymälle sekä backendille. Tällä tehdään se iso linja ja siitä ilmenee sitten aika hyvin ne palvelut mitä sinne backendiin tarvitsee kuin käyttöliittymän komponentit.
Jokainen palvelu voidaan tarvittaessa tehdä eri kielellä, mutta samalla kielellä toimittaessa voi löytyä helpommin keinoja sille, että palvelut voivat keskustella keskenään backendissä ilman, että kutsutaan HTTP API:a. Eri palveluissa tai kaikissa palveluissa käytettävät kielet valitaan sen mukaan mitä niiden olisi tarkoitus tehdä.
Ketjusta on poistettu 4 sääntöjenvastaista viestiä.
Luetuimmat keskustelut
Pupuhuhdasta löytyi lähes sadan kilon miljoonalasti huumeita
Pupuhuhdasta löytyi lähes sadan kilon miljoonalasti huumeita – neljä Jyväskylän Outlaws MC:n jäsentä vangittu: "Määrät p561886Persut petti kannattajansa, totaalisesti !
Peraujen fundamentalisteille, vaihtkaa saittia. Muille, näin sen näimme. On helppo luvata kehareille, eikä ne ymmärrä,481638- 521574
Nähtäiskö ylihuomenna taas siellä missä viimeksikin?
Otetaan ruokaöljyä, banaaneita ja tuorekurkkuja sinne messiin. Tehdään taas sitä meidän salakivaa.51517Sinäkö se olit...
Vai olitko? Jostain kumman syystä katse venyi.. Ajelin sitten miten sattuu ja sanoin ääneen siinä se nyt meni😅😅... Lis61495Housuvaippojen käyttö Suomi vs Ulkomaat
Suomessa housuvaippoja aletaan käyttämään vauvoilla heti, kun ne alkavat ryömiä. Tuntuu, että ulkomailla housuvaippoihin61405Hyvää yötä ja kauniita unia!
Täytyy alkaa taas nukkumaan, että jaksaa taas tämän päivän haasteet. Aikainen tipu madon löytää, vai miten se ärsyttävä81306Lepakot ja lepakkopönttö
Ajattelin tehdä lepakkopöntön. Tietääkö joku ovatko lepakot talvella lepakkopöntössä ´vai jossain muualla nukkumassa ta121281Revi siitä ja revi siitä
Enkä revi, ei kiinnosta hevon vittua teidän asiat ja elämä. Revi itte vaan sitä emborullaas istuessas Aamupaskalla41163Kello on puoliyö - aika lopettaa netin käyttö tältä päivältä
Kello on 12, on aika laittaa luurit pöydälle ja sallia yörauha kaupungin asukkaille ja työntekijöille. It is past midni41138