Python, PHP vai joku muu?

Anonyymi

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.

18

328

    Vastaukset

    Anonyymi (Kirjaudu / Rekisteröidy)
    5000
    • 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

    1. Lopullinen varmistus. Suomi ja Ruotsi eivät liity Natoon

      Suomen ja Ruotsin liittyminen Natoon on estetty Erdoganin toimesta: https://www.is.fi/politiikka/art-2000008826412.html Tämä on pieni askel Erdogani
      Maailman menoa
      621
      2460
    2. Uskallatko laittaa tuntomerkkejä

      Samaan kommenttiin sekä itsestäsi, että kaivatustasi?
      Ikävä
      109
      2188
    3. Mitä tapahtui? Bachelor-Timo paljastaa, miksi suhde Sonjaan ajoi karille: "Ehkä ei kuitenkaan..."

      Rovaniemeltä kotoisin oleva Timo Harvey, 32, halusi sitoutua, löytää rakkauden ja asettua aloilleen. Kauden viimeisessä jaksossa Bachelor-Timo valitsi
      Bachelor
      13
      1545
    4. Martiinan "Ikuinen rakkaus", hah hah haaa

      Onko tämä lippisressukka nyt sitten taas se ikuinen rakkaus ? ? miksi ikiteini mara on niinkin tyhmä ja nolo ?
      Kotimaiset julkkisjuorut
      154
      916
    5. Stefulla taas korkki auki?

      Tästä taitaa tulla hieno päivä 😁
      Kotimaiset julkkisjuorut
      19
      803
    6. Zaharova yllättäisi sotilaallisesti

      Venäjän ulkoministeriön tiedottaja Maria Zaharova sanoi keskiviikkona, että Venäjän vastaus Suomen Nato-jäsenyyteen tulee olemaan luonteeltaan sotilaa
      Maailman menoa
      170
      779
    7. Mies olet kaunis sisältä ja ulkoa

      Haluan sut omakseni. Sinä jos kuka kelpaat :)
      Ikävä
      78
      740
    8. Naton vastustajat pääosin kouluja käymätöntä, ja vähemmän älykästä porukkaa

      monet myös työttömiä. Paljolti samaa jengiä joka myös vastustaa koronarokotuksia, ja puolustaa venäjää. Uutiset luetaan mm. MV-lehdestä. Veikkaan ett
      Maailman menoa
      264
      686
    9. olis ihan fllirttailla sulle mies

      Katsella silmiin ja leijua sun lähellä.
      Ikävä
      47
      623
    Aihe