Kuinka monta rajapintaa voi realistisesti osata?
Esimerkiksi JS-rajapintaa?
Onko jo React ja Angular liikaa yhdelle ihmiselle?
Absoluuttinen totuus on kolme.
Luulen, että pelkkä React on muuttunut muutaman vuoden sisällä sen verran, ettei sitäkään voi osata realistisesti, kun se muuttuu sitä vauhtia.
Aloin kyllä arvostamaan React:ia sen kirjaston laajuuden takia, mutta sitten ajattelinkin, että ehkä best of all worlds olisi ottaa React:ista funktioita ja tehdä muut osat Svelte:llä tai esimerkiksi yhdistää Angular:ia tai React:ia.
Riippuu nyt ihan siitä, mitä tarkoittaa "rajapinta" ja "osata". Itse sanoisin, että helposti kymmeniä voi osata. Mutta varmaan harvemmin kymmeniä samaan tarkoitukseen, pikemmin yhden tai muutaman useisiin tarkoituksiin.
Ei ohjelmoinnissa tarvitse muistaa ulkoa jokaista detaljia, vaan pitää tietää pääperiaatteet ja muistaa suunnilleen, mitä ominaisuuksia on olemassa, jotta vastaukset ongelmiin löytää alle minuutissa. Eikä osaaminen vaadi välttämättä kaikkien ominaisuuksien käyttämistä. Esimerkiksi mielestäni voi osata käyttää hyvin C++:n standardikirjastoa, vaikka ei olisi käyttänyt puoliakaan sen ominaisuuksista tai ei edes muistaisi oman käytön kannalta vähiten olennaisia.
Eri asia sitten pysyä mukana jossain jatkuvasti muuttuvassa. Ei tule vastaan osaamisen raja vaan opettelun. Joten jos haluaa osata monta rajapintaa, kannattaa valita stabiileja ja hitaasti kehittyviä kuten BIOS ja POSIX eikä mitään uutta.
Itseasiassa olen yrittänyt nojautua POSIX:iin kuten BSD:eissä ja C:ssä, mutta vaikuttaa siltä, että moni juna on ajanut näistä ohi. Kysyin tästä joskus, niin joku sanoi, että POSIX kehittyy liian hitaasti, joten ehkä se on se syy, miksi monet projektit poikkeavat standardeista.
Mutta kysymys voisi olla relevantti esimerkiksi kysymykseen vanilla-JS vs JS-framework. Usein sanotaan, että JS-framework on nimensä mukaisesti aihio, ja vanilla-JS on usein siksi edelleen muotoiltavampi ja nopeampi. Mutta missä tilanteissa framework ja mikä framework on sopivampi. React kuulostaa hyvältä Facebook App:seihin, mutta en sinänsä ymmärrä, miksi joku haluaisi tehdä sivustaan Facebook App:n. Luultavasti moni ajattelee, että React on "riittävän hyvä" usein, vaikka se ei ole täydellisesti sopiva.
JS:n suhteen ajattelin itse opiskella ensin vain Svelte:ä ja vanilla-JS:iä, mutta sitten huomasin, että Svelte on kesken, joten sitten ajattelin, että jos hakisin React:sta puuttuvia funktioita Svelte-projektiin.
Joissain harjoittelupaikoissa on vaadittu tiettyjen rajapintojen käyttöä, toisissa taas ei ole ollut mitään väliä mitä kirjastoja käytetään, kunhan homma toimii. Eli riippuu ihan siitä, mitä työnantaja tai asiakas haluaa käytettävän.
Tämä kyllä taitaa olla enemmän niin, että jotkut jutut on pakko osata niissä olevan legacyn takia. Esim. React, Java, ...
React ja Java legacya. Nice.
noutti kirjoitti:
React ja Java legacya. Nice.
Tarkoitan, että kuten C:nkin tapauksessa, kielissä on varmasti kirjastoja ja funktioita, joita ei ole tehty muille frameworkeille, joten niitä pitää käyttää sen takia. Ties kuinka kauan jotkut isotkin firmat käyttävät vieläkin Angular:ia vain sen takia, että siinä on sentään kaikki funktiot.
Siten esimerkiksi Svelte + wrapatty React tai Clojure + Java:sta funktioita.
Vaikka olen suhtautunut React:iin kriittisesti, niin aloin itseasiassa opiskelemaan sitä tämän takia.
Moni lähde sanoo kuitenkin, että React on työläs kirjasto.
Itseasiassa hybridiprojekteissa on potentiaalisesti paljon arvoa, koska sitten voi käyttää toisen kielen nopeaa accessibility:ä ja toisen kielen hienostuneita ominaisuuksia.
Esimerkiksi React:n laajuus, mutta Svelte:n kompaktius.
mavavilj kirjoitti:
Tarkoitan, että kuten C:nkin tapauksessa, kielissä on varmasti kirjastoja ja funktioita, joita ei ole tehty muille frameworkeille, joten niitä pitää käyttää sen takia. Ties kuinka kauan jotkut isotkin firmat käyttävät vieläkin Angular:ia vain sen takia, että siinä on sentään kaikki funktiot.
"siinä on sentään kaikki funktiot"
Mitä nämä mahtaa olla Javan tapauksessa jonka otit taas esiin?
Tässä on javan "funktiot": https://docs.oracle.com/en/java/javase/21/docs/
Siis Java:lle on paljon kirjastoja.
Esimerkiksi:
Kuten joku sanoi jossain, niin business-käytössä on aika paljon turvallisempaa käyttää ensisijaisesti kieltä, jolle on todennäköistä saada tukea kuin käyttää kieltä, joka vaatii enemmän itse tekemistä.
Siis kannattaa Java:n tapauksessa käyttää kieltä, jolla voi kutsua Java:a.
Esimerkiksi taas React:n tapauksessa on kirjastoja, jotka ovat virallisesti sille, kuten:
Tämä tietysti motivoi myös, miksi joissain tapauksissa Ruby, PHP yms. ovat välttämättömiä osata hyödyntää, jos haluaa päästä helpommalla.
Sitten voi tietysti ajatella myös sitä, että jos pitää valita esim. seuraavista:
-React
-PHP
-Ruby
Mitä sä nyt taas jankkaat. Mene poika ohjelmoimaan, äläkä sössötä. Nämä sun avaukset ovat lapsellisia. ”Mitä jos sitä tai tätä” en palkkaisi tuollaista taunoa, vaikka muistaisit ulkoa kaikki Javan funktiot. Rakenna jotain niin opit jotain! Ei mitään väliä millä kielellä! Ratkaise jokin vaikea ongelma, älä keksi ongelmia!
No joku olisi voinut analyysillä ennustaa, että RoR kuolee nyt ja sen korvaa Python ja JS. Vaikka se oli vuosia sitten erittäin suosittu. Itseasiassa sen suosio on laskenut jo pitkään. Piikin keston mukaan kyseessä on ilmiselvästi hype-teknologia.
https://www.reddit.com/r/rails/comments/17qvwsz/
Tuosta kommentista huomaa, että sinulla ei ole minkäänlaista käryä mistä jauhat. Jos erehtyy linkkarissa kirjoittamaan RoR:in, niin headhuntterit tulevat puhelinlankoja pitkin hakemaan projekteihin mukaan. Vaikka uusia projekteja ei RoR:illa enää aloiteta samaa tahtia, kuin ennen, niin ylläpitotöitä löytyy vallan mainiosti vielä.
Tarkoitan, että RoR:n sijaan olisi voinut nähdä etukäteen, että on kätevämpää luoda JS framework, ja näin ei tarvitse opiskella RoR:ia. Ties vaikka RoR:t konvertoidaan JS:ksi kokonaan myöhemmin.
mavavilj kirjoitti:
Tarkoitan, että RoR:n sijaan olisi voinut nähdä etukäteen, että on kätevämpää luoda JS framework, ja näin ei tarvitse opiskella RoR:ia. Ties vaikka RoR:t konvertoidaan JS:ksi kokonaan myöhemmin.
RoR on ensisijaisesti MVC patternin toteuttava ohjelmistokehys, ei se ole mikään suoraan js:llä korvattava vaan rinnasteinen kaikkiin muihin vastaaviin frameworkeihin kuten C# MVC ASP.Net, PHP laravel jne
Yleisellä kielellähän voi toteuttaa minkä paradigman tahansa. Ajattelin, että siirtymässä JS:ään on nimenomaan osin tästä kyse.
Pythonin sija taas on helppo, koska se tarjoaa myös helpot SQL-integraatiot yms.
Mitenhän on muuten RoR projektien nykyinen ROI. Ovatko ne menettäneet tuottajilleen rahaa vai tuottaneet? Esim. nyt kun muut siirtyvät muihin teknologioihin?
Kaikki kielet tarjoaa helpon SQL integraation, käytännössä joka ainut ja osa vielä ORMien kautta entistä helpotetumpana.
ROI riippuu siitä tuottaako koko ohjelmistohanke hyötyä. Se sadan tonnin verkkokauppa ketterimmällä menetelmällä tehtynä ei eroa hitaasta menetelmästä jos sen kautta ei ole yhtään kauppaa saatu tehtyä.
Lähtökohtaisesti kuitenkin ROI on parempi mitä tehokkaammin tuote saadaan rakennettua, ja Ruby on railsillä kyllä nopeasti rakentelee verkkoapplikaatioita. Isoin ongelma siinä Suomen kamaralla lienee tekijöiden saatavuuden kanssa eikä niinkään tekniikka itsessään. Rvm käyttöönotto ja kontitus poisti tuota aikaisempaa problematiikkaa rubyversioiden yhteensopivuudesta eri rubygems paketteihin ja varsinaisesta ylläpidosta, koska tuotantoylläpito ja optimointiosaamista oli ainakin aiemmin haastava löytää Suomesta.
Kysymykseni koski sitä, että jos ennuste muuttuu. Eli jos joku on ennustanut, että RoR on hyvä alusta, ja sitten sen suosio väheneekin huomattavasti. Firmoillehan voi syntyä kustannuksia nimenomaan sitä kautta, että kehittäjiä on vähemmän. Facebook:ikin ennusti ensin HTML:n varaan: https://www.reddit.com/r/webdev/comments/zqlfa/
Jos on pysynyt PHP:ssä niin häviää ehkä vähemmän migraatiokuluissa, vaikka softa ei olisi latest and greatest. Itseasiassa ehkä PHP:n käyttäjät eivät ole edes kiinnostuneita Python:sta PHP:n käyttökohteissa:
https://www.clariontech.com/hubfs/Website usage Phython vs PHP-webp.webp
Ehkä siihen on muuten syy, miksi https://www.ohjelmointiputka.net/oppaat/:ssa ei ole RoR:ia tai edes Ruby:ä. Eikä ole muuten edes https://www.w3schools.com/, joka on yleensä hyvä referenssi ajantasaisille teknologioille.
Java ja Ruby opas ois kyl kova sana ohjelmointiputkaan.
Mavavilj vois varmaan tehdä joutessaan?
wy5vn kirjoitti:
Java ja Ruby opas ois kyl kova sana ohjelmointiputkaan.
Mavavilj vois varmaan tehdä joutessaan?
Ja töitäkin olisi tarjolla. Tässä taisi vilahtaa jossain vaiheessa joku työpaikkailmoitus. :D
Kysymyksen voisi myös uudelleenmuotoilla siten, että kuinka monta tekniikkaa W3Schools:ista voi realistisesti hallita.
Jos uuden kielen tai frameworkin oppii hallitsemaan parissa viikossa tai kuukaudessa, ei mitään oleellista ylärajaa ole.
Jos ei monen vuoden yrittämisen jälkeen hallitse yhtäkään ohjelmointikieltä kunnolla, yläraja saattaa olla tällaisen henkilön kohdalla nolla.
jlaire kirjoitti:
Jos uuden kielen tai frameworkin oppii hallitsemaan parissa viikossa tai kuukaudessa, ei mitään oleellista ylärajaa ole.
Jos ei monen vuoden yrittämisen jälkeen hallitse yhtäkään ohjelmointikieltä kunnolla, yläraja saattaa olla tällaisen henkilön kohdalla nolla.
Tekniikoita pitää myös käyttää aktiivisesti tai ne unohtuvat. Lisäksi ekosysteemi kuten C++ on jo liian iso yhdelle ihmiselle kaikkine kirjastoineen, joista osa muodostaa oman alikielensä sinänsä. On eri asia tietää kielen sallimat konstruktiot, ja se, miten kirjasto hyödyntää niitä.
Minun mielesätä rajapinta on SOAP/REST, jne. Siis rajapinnat keskustella 2 ohjemiston välillä tai useamman.
Framework on yhtä kuin ohjelmistokehys eli valmiiksi tehty luokkakirjasto koodata nopeasti.
Sitten on nk. Vanilla JavaScript, PHP, Java EE, jne.
Hyvin harva osaa edes yhtä teknologiaa kunnolla. Suurin osa kaupallisestakin koodista on hirveää roskaa, mutta jos asiat tapahtuvat ruudulla suurin piirtein oikein, niin sillä ei usein ole väliä.
Ei tarvi osata yhtäkään kunnolla, kunhan suurinpiirtein tietää mitä framework tarjoaa niin osaa sitten hakea yksityiskohtaisempia tarkennuksia
SQ kirjoitti:
Ei tarvi osata yhtäkään kunnolla, kunhan suurinpiirtein tietää mitä framework tarjoaa niin osaa sitten hakea yksityiskohtaisempia tarkennuksia
Tarvittavan osaamisen taso riippuu siitä, mitä muita ehtoja on asetettu. Jos on aikaa aina opetella uusia asioita työnteon lomassa, niin todennäköisesti työteho jää alhaisemmaksi, tai vaihtoehtoisesti työn jälki on huonompaa, mikä hidastaa sen jälkeen kaikkien työntekoa, kun jokainen joutuu käyttämään aikaa huonon koodin purkkaamiseen.
Koittakaa ymmärtää kuinka järjetön tämäkin keskustelu on!
Aihe on jo aika vanha, joten et voi enää vastata siihen.
