Moi
Osaako joku kertoa, että mitä ongelmia tuollaisen kombinaatioon voisi liittyä?
Osa skripteistä on ns. cli puolelle tarkoitettu ja osa, kuten nodejs, "tavanomaisiin" verkkosovelluksiin.
Eniten itseäni askarruttaa tuo cli puolen paluuarvo ja sen jatkokäsittely?
Pääohjelma tehdään PHP:llä - se siis kutsuu eri skriptejä niiden edellytämällä tavalla.
Tietoturvasta tässä ei tarvitse välittää - tulee omaan käyttöön.
Kuulostaa purkalta. Miksi sinä nyt tuommoista joudut tekemään?
Monet palvelimet, kuten Apache, tukevat kyllä useiden eri kielten käyttämistä eri osissa, joten sen ei itsessään pitäisi olla kovin vaikeaa. Ongelmia syntyy esimerkiksi tiedon välittämisestä eri alustojen välillä.
Tarkoituksena on käyttää käytännössä yhtä ja samaa parametriä, jolla kutsutaan kutakin skriptiä.
Skriptien palauttamat datat tallennetaan kantaan, josta niistä sitten web-käyttöliittymän kautta voi tarkastella.
Bonuksena kenties skriptikohtaiset painikkeet käyttöliittymään, joka suorittaa sen uudestaan - ikään kuin päivitystoiminto.
Jaa, minkä takia? Kukin näistä skripteistä tarjoaa ratkaisun omalta osaltaa, joten siitä syystä purkkaa viritellään.
Ja osittain siitäkin syystä, että "parametrisointi" on hyvin yksinkertainen, joten kehtais kenties kokeillakin.
Eli ymmärsinkö oikein? Skriptisi ovat ulkoisia ohjelmia (komentoriviohjelmia?), joita PHP-palvelin ajaa ja tallentaa niiden palauttamat tiedot tietokantaan ja näyttää ne nettisivun käyttäjälle. Eli sivusi avulla voi ikään kuin etäkäyttää näitä ulkoisia ohjelmia.
PHP:ssä voi ajaa ulkoisia ohjelmia exec-komennon avulla. Funktio palauttaa ulkoisen ohjelman tulosteen viimeisen rivin:
Kaiken tulosteen keräämiseen voi käyttää hieman monimutkaisempaa proc_open-komentoa.
fergusq kirjoitti:
(01.08.2016 17:35:33): Eli ymmärsinkö oikein? Skriptisi ovat ulkoisia...
Suurinpiirtein noin.
Nodejs pyörii ilmeisesti omana pannuna omassa portissa ja kyse lienee vain apachen confista, jotta PHPllä tehdyt kutsut menee oikein.
Rubyt on ulkoisia ohjelmia eli komentorivipohjaisia ja niistä ilmeisesti tuolla proc openilla saadaan paluuarvot talteen.
Ja siinäkin on ilmeisesti oma pieni palvelintoiminto.
En tosin tunne tuota Rubya niin hyvin, että osaisin sanoa toimiiko ne myös "palvelimena".
Voikkaan, että ei.
Ja toisaalta taas, jos tallenna Ruby paluuarvot esim. tiedostoon palvelimelle, niin sieltähän ne saa myös luettua PHPn avulla.
Näitä vaihtoehtoja tuntuu aina löytyvän...
Helpoin tapa ulkoisen ohjelman ajamiseen ja koko tulosteen nappaamiseen PHP:ssä on shell_exec.
Nodejs:llä ja Rubyllä voi kummallakin tehdä sekä suoritettavia skriptejä että jatkuvasti käynnissä olevan palvelimen, ihan oman maun mukaan saat valita.
Oletko harkinnut Perlin ja Pythonin lisäämistä projektiin? Niilläkin on omat vahvuutensa.
jlaire kirjoitti:
Nodejs:llä ja Rubyllä voi kummallakin tehdä sekä suoritettavia skriptejä että jatkuvasti käynnissä olevan palvelimen, ihan oman maun mukaan saat valita.
Oletko harkinnut Perlin ja Pythonin lisäämistä projektiin? Niilläkin on omat vahvuutensa.
Toistaiseksi ei ole "hyödyllistä" koodia noille kielille, joten ei tarvetta.
Mutta ehkä sellaisia löytyy tulevaisuudessa...
Kuten aavistelinkin, niin ennen kuin itse kokonaisuutta pääsee rakentamaan, niin sitä ennen esim. Rubyn kanssa saa hakata tovin.
Sain ongelman ratkaistua, mutten testannut, että menikö siinä samalla muuut toimivat osat rikki. Jonkinlaisia versioriippuvuuksia.
Kuinkahan taaksepäin yhteensopivia nuo Ruby koodit ovat?
Alustavasti ajattelin tallentaa yhteen tauluun käytetyn parametrin ID:n kera.
Kutakin ruby, node jne skriptiä kohden tulee oma taulu, johon tuon ID:n avulla tallennetaan tiedot.
Kukin skripti palauttaa eri tietoa, joten tarvitaan eri sarakkeet (tietojen kyselymäinen käyttö helpottuu).
Toisaalta, voisin kenties tallentaa vain yhteen tauluun objektit mjonoina ts.sarjallistaa ne yhteen tauluun ja luoda kullekin skriptille vain oman sarakkeen.
Se voi olla hieman hätäinen ratkaisu...
Mihin ylipäätään tarvitset scriptejä? Mikset vaan tee logiikkaa suoraan backendissä, ja näin et tarvitse kuin yhden backendin (olkoon se sitten NodeJs, PHP tai vaikka Ruby on rails).
groovyb kirjoitti:
Mihin ylipäätään tarvitset scriptejä? Mikset vaan tee logiikkaa suoraan backendissä, ja näin et tarvitse kuin yhden backendin (olkoon se sitten NodeJs, PHP tai vaikka Ruby on rails).
Nyt en ymmärrä. Miksi keksiä pyörä uusiksi?
Skriptit tekevät oman asiansa ja pyrin vaan kokoamaan niiden paluuarvot keskitetysti kantaan.
Pääohjelma (PHP) hoitaa näiden kutsumisen ja tallentaa paluuarvot kantaan.
Nythän sinä pitkälti olet keksimässä pyörää uusiksi, kun ajat backendissä shell scriptejä. Backendissä voit tehdä kaiken mitä serverillä tarvitsee tehdä. On enemmänkin poikkeus, jos scriptejä joutuu ajamaan. Ja nekin scriptit mitä ehkä backend voi tarvita, ajetaan yleensä ajastetusti joko backendin päässä, tai esimerkiksi crontabilla (vaikka sähköpostien massalähetykset, tai ajastettujen työnkulkujen suorittamiset). Puhumattakaan siitä, että aiot suorittaa eri backendeillä scriptien ajoja (NodeJs, PHP), ja erikseen kuitenkin rubylla, joka taasen ei itsessään toimi web frontin backendinä (as in Rails extensio).
Mikäli ajat scriptejä serverillä, on ne syytä ainakin olla samaa ohjelmointikieltä ja täten ylläpidettävyys paranee. Backendin joudut enivei toteuttamaan mistä scriptejäsi kutsut, joten loogista olisi portata scriptit suoraan myös sinne, koska niitä ei tarvita.
groovyb kirjoitti:
Nythän sinä pitkälti olet keksimässä pyörää uusiksi, kun ajat backendissä shell scriptejä.
Eli siis on parempi koodata kaikki olemassaoleva uusiksi kuin käyttää olemassaolevaa? Kukahan sen lystin aina maksaisi? Ja backend ei ole mikään maaginen asia, jossa ei voisi ajaa skriptejä. Se on se koko taustajärjestelmä, joka nyt koostuisi myös niistä skripteistä.
Kauanko ajattelit, että noiden skriptien muuntaminen yhtenäiselle kielelle veisi? Ei ole edes tietoa miten suuria kokonaisuuksia ovat, joten aika heikoilla tiedoilla nyt ehdotellaan uudelleenkirjoittamista. Entä kauanko pitäisi testaukseen varata aikaa?
Kyllä tuo juurikin olisi pyörän keksimistä uudelleen. Olemassaolevien hyväksikäyttö on paljon parempi ajatus. Niitä voi sitten ajan kanssa ja tarpeen mukaan ehkä modernisoida tai yhtenäistää.
Toki scriptejä voi ajaa. Mutta ei tuollaista kenellekään voi suositella, saatika että tuollaiseen ratkaisuun helposti pääsisi kukaan itseään kunnioittava ohjelmoija. En tiedä kauanko muuntamiseen menisi, mutta äkkisältään voisin olettaa, ettei kauaa. Jos scriptit pamahtaa verkkoon voin antaa arvion kyllä.
Ja mikäli käytössä on ruby -scriptejä, todennäköisesti tekisin koko kikkareen railsillä, jolloin scriptit toimisivat suoraan koodista ilman shell -ajoja, enkä valitsisi PHP:ta käyttöön lainkaan. Ja jos NodeJS on pystytetty, todennäköisesti scriptit toimivat myös Web -palvelimen kautta web servicenä joko perinteisenä SOAP:lla, tai Restinä. ja näitä pystyykin kutsumaan backendin controllerista suoraan (tai clientistä), ilman että ajetaan nodejs:n tulkilla shellissä.
Mielestäni pyörä tehdään uudestaan tässä, kun halutaan ohittaa valitun softakielen härpäkkeet custom scripteillä, vain ja ainoastaan siitä syystä ettei jakseta portata. porttauksen voi toki tehdä vaiheittain, mutta jos ainut syy on se ettei jaksa/viitsi, on scriptien käyttöä turha perustella.
Ruby on ainoa, joka tässä tulee cli:n kautta.
Nodejs toimii omana verkkopalveluna eli sinällään vastailee kutsuihin.
Ja mitä aikaisemmin on tullut juteltua oikeiden koodareiden kanssa, niin vastaanotto on ollut hieman samaa tasoa.
Kyselin mm. Angularista, että onko siihen valmiina jotain käyttäjä entiteettiin liittyviä juttuja.
Naureskelivat vain partaansa ja kehuiva, ettei sellaisia ole ja mitä nyt tuommosia kyselet.
Ajattelin vain, kun on aika yleistä, että verkkopalvelussa on tunnistettuja käyttäjiä ja että jos on niin helevetin hyvä ohjelmistokehys nimenomaan verkkopalveluita varten, niin "ehkä" siinä vois olla jotain siihen liittyvää...
Eivät tienneet tai ymmärtäneet kokonaiskuvaa vaikka ovat koko työuransa koodanneet ja tekevät pelejä tällä hetkellä.
Päätin sitten itse perehtyä asiaan ja kummasti löytyi käyttäjiin liittyvää.
Sinällään ymmärrän koodareiden ammattiylpeyden ja minkä tahansa ammatin, mutta joskus ylpeys käy lankeemuksen edellä.
Ei niitä siporex harkkojakaan kukaan itse tee vaan kasaa valmiit osat reunaehtojen mukaan.
Eikä porttauksessa ole jaksamisesta kyse.
Otona teko ei vain yksinkertaisesti mahdollista sitä.
Ja toisaalta, vaatimustaso ei edellytä, että pitäisi olla yhden teknologian kanssa naimisissa.
Sanoisin, että tulevaisuudessa voisi olla enemmän tällaisia "kehysstäkkejä".
Ja nykyaikana vaaditaan yhä laajempaa osaamista mm. eri kehyksistä.
Nykyään on kieltämättä muotia pilkkoa backendi hyvinkin pieniin REST-palasiin, jotka kommunikoivat keskenään kieliriippumattomalla tavalla. Palasia voi jokainen koodaaja toteuttaa omalla lempikielellään ja PHP-kikkareita voi portata yksi kerrallaan vaikka Haskelliksi ilman, että kukaan huomaa. Web scale microservices on paras ja mongodb!!!
No enemmänkin pointti on siinä että miksi ylipäätään on kannattanut tehdä asiat eri scripteillä homman alussa. ja vielä eri teknologioilla. Mitä tulee Angulariin, ei se natiivina mitään käyttäjäentiteettejä tuekaan. se on vain framework, sillä voi toteuttaa luonnollisesti moisen ominaisuuden, mutta ei se mikään sisäänrakennettu juttu ole. se on vain Framework, tässä tapauksessa hauskasti toteuttaa MVW patterniksi (Model-View-Whatever) nimettyä malliaan (MVVM tyyppiset bindaukset tuossa on käytössä tosin). Yleisesti, tunnettuihin palikoihin kyllä löytyy valmiita esimerkkejä biljardi, kuten esittämäsi autentikointi ja käyttäjäentiteetti Angularilla. Se onkin asia erikseen, kannattaako AuthTokeneita väkertää pelkästään clientissä ja generoida sessio clientissä pyörivässä javascriptissa, ilman minkäänlaista palvelimella pyörivää toteutusta.
Pointti oli se, että näitä skriptejä ei ole itse tehty.
Sen nyt luulisi aika nopeasti käyvän ilmi.
Kysehän on nimenomaan olemassaolevien skriptien ja koodien hyödyntämisestä.
Ja mitä tulee Angular esimerkin pointtiin, niin mielestäni se on aika lyhytnäköistä rajata kysymys koskettamaan vain ja ainoastaan pelkkää ohjelmistokehystä eikä sen käsittämää "ekosysteemiä".
Siinähän se idea on, kuten suurin piirtein jokaisen kehyksen buzzwordit osoittaa:
modular, flexible, extendable, portable, jne.
Angularin tapauksessa se on lyhyesti "superheroic", joka on vielä tyhjänpäiväisempi.
No mutta Angular on vain kehys. Mitään muuta se ei ole. Se mitä sillä voi tehdä aikaansaa sitten "ekosysteemin". Suosittelisin tutustumaan myös muihin javascript frameworkkeihin, ja ymmärtämään mitä ne tekee.
Aikanaan, kun trendi kasvoi puhtaasti js:n päälle tehtyihin sivustoihin, kuten SPA sivustot (Single page application, esimerkkinä nyt vaikka Gmail), alkoi syntymään laajempi tarve js kehyksiin, jotta sivustoja saataisiin edes jonkin normin mukaan tehtyä. Täten syntyi KnockoutJS, AngularJS ja moni muu, jotka joko kokonaan tai osittain perustuu MVVM ohjelmistomalliin. Tällöin vielä serveristreamiin (WebSocket based) perustuvia kilkkeitä ei juuri ollut, kuten SignalR, Railsin Action Cable ja niinpoispäin.
Käytännössä, clientissä pörräävät applikaatiot toteutettiin (ja toteutataan yhtä) esimerkiksi juuri tuolla angularilla, joka controllereissaan toteuttaa ajaxin kautta kutsut serverille. Eli itse sovelluslogiikka on clientin controllereissa, mutta ne taasen kutsuvat operaatiota serverin päästä, vaikka sitten varmentaa käyttäjän käyttäjätunnukset tietokantaa vasten.
esimerkki, kun sivu N ladataan, Angularissa oleva controller kutsuu 10 viimeisintä uutista serveriltä (Backendiltä, olkoon se sitten PHP, Rails, C# jne yms). Serveriltä palautuvat kikkareet pusketaan angularin modeleihin, jotka taasen bindataan näkymään. Kun valitaan joku uutinen, controller lähettää bindatusta uutisesta vaikka id:n serverin ko. metodiin, palauttaen uutisen kokonaisuudessaan. Tämä uutinen bindataan taasen uuteen angularin modeliin, jne etc yms.
Näin Angular toimii kehyksenä. Se mitä sillä voi tehdä, on kiinni siitä mitä palveluja (service) ja controllerilogiikkaa sillä haluaa lähteä rakentamaan. mutta by default, se tarjoaa dokumentoidun ja testatun tavan toteuttaa js:n päälle rakennettu sivusto. Toimien kehyksenä js -sivustolle. Mutta ei se mikään maaginen kaikenkattava härpäke ole. Se on tasan niin kattava kehyksen ulkopuolisilta osilta, kuin mitä siihen koodaat tai kopioit jonkun muun koodia.
Aihe on jo aika vanha, joten et voi enää vastata siihen.