Vinkkejä, miten opiskella hyväksi ohjelmoijaksi?

Hei,

olen työtön maisteri, joka luki aikoinaan tietojenkäsittelyä sivuaineena. Jouduin pitkäaikaistyöttömäksi ja ammatillisessa kuntoutuksessa tein IT-hommia. Sen opiskelua suositeltiin jatkamaan.

Miten kannattaisi opiskella ohjelmointia? Ei ole varmaankaan taloudellisesti järkevää kirjautua oppilaitokseen, kun opintotukikuukaudet on jo käytetty. Kannattaako lainata kirjastosta yliopistokurssien kirjasuositukset ja opiskella ne vai lukea tiedeartikkeleja vai tehdä omia projekteja ja opiskella Googlen avulla? Vai koettaa säästää jostain aina parikymppiä ja käydä kurssi kerrallaan avointa yliopistoa tai ammattikorkeakoulua?

Sen verran olen tiedettä tehnyt, että pystyn omaksumaan sivun https://arxiv.org/list/cs/recent artikkeleja, mutta vaikkapa Donald Knuthin kirjat Art of Computer Programming on liian tiivistä tavaraa minulle?

Eniten kiinnostaisi vaikkapa Python, R, data-analyysi ja tekoäly, kun olen aika matemaattinen ja tilastoista tykkäävä henkilö. Mutta varmaan töihin päästäkseen olisi osattava myös ne peruskurssit ja opeteltava assemblystä alkaen asiat, koska kaverini kertoi, että joissain työssä voi pahimmillaan joutua ylläpitämään suljetun lähdekoodin projekteja ja koodaamaan konekieltä.
Ilmianna
Jaa

35 Vastausta



Harvemmin assembleria missään tarvitsee. Ennemminkin ohjelmoijan tarvitsisi olla tietokoneen kanssa vähän vastaava kuin myytinmurtajien Jamie Hyneman on siellä verstaassa.

Jos tarvitsee jotain tehdä, se sitten tehdään. Ja tärkeintä on asenne, että jos ei onnistu niin se on oma vika eikä siinä välttämättä kukaan auta. Pitää kyetä tekemään itse.

Se että osaa kirjoittaa koodia jollain kielellä ei riitä. Sen tekee intialaiset halvemmalla ja osittain myös tietokoneohjelmat kirjoittavat koodia puolesta. Vähintäänkin pitäisi osata pureskella konseptin ja maksajan toiveiden pohjalta määritelmä ja sen pohjalta toimiva ohjelma, mielivaltaisilla työkaluilla. Ohjelmointikieli esimerkiksi on vain yksi työkaluista ja se voi vaihdella tilanteen mukaan. Muita olennaisia työkaluja on testijärjestelmät, versionhallinta ja sen sellaiset.

Tämäkään ei oikein aina riitä vaan mielellään pitäis ymmärtää liiketoiminnan päällekin jotain. Kuten muillakin aloilla, vaatimukset kasvavat kaiken aikaa.

Tärkeimmät kirjat pitäisi lukea ja sen lisäksi myös tehdä jotain toimivaa, oikeasti nykyaikaisilla tavoilla. Koulun penkin kuluttaminen on hidasta eikä siellä oikein opeteta kuin alkeisperusteita.
Kommentoi
Ilmianna
Jaa
4 VASTAUSTA:
Hah! Matti karvaperse ei taaskaan onnistunut tuomaan esiin muuta kuin asenteitaan. Hah! Toisen kerran. Mene pölvästi jonnekin häpeämään olemassaoloasi.
Kommentoi
Ilmianna
Jaa
sdtsdt kirjoitti:
Hah! Matti karvaperse ei taaskaan onnistunut tuomaan esiin muuta kuin asenteitaan. Hah! Toisen kerran. Mene pölvästi jonnekin häpeämään olemassaoloasi.
Ööh.. Mitä sinä onnistuit tuomaan esiin?
Kommentoi
Ilmianna
Jaa
"Jos tarvitsee jotain tehdä, se sitten tehdään. Ja tärkeintä on asenne, että jos ei onnistu niin se on oma vika eikä siinä välttämättä kukaan auta. Pitää kyetä tekemään itse."

Ei välttämättä kannata tehdä kaikkea itse, jos on yrittäjä.

Voi olla järkevämpää keskittyä siihen, mikä on omaa ydinaluetta, ja teettää muut asiat muualla.

No ohjelmistotuotannossa toki tämä tulee ihan luonnostaan kirjastojen käytön, jne. kautta.
Kommentoi
Ilmianna
Jaa
102030405060 kirjoitti:
"Jos tarvitsee jotain tehdä, se sitten tehdään. Ja tärkeintä on asenne, että jos ei onnistu niin se on oma vika eikä siinä välttämättä kukaan auta. Pitää kyetä tekemään itse."

Ei välttämättä kannata tehdä kaikkea itse, jos on yrittäjä.

Voi olla järkevämpää keskittyä siihen, mikä on omaa ydinaluetta, ja teettää muut asiat muualla.

No ohjelmistotuotannossa toki tämä tulee ihan luonnostaan kirjastojen käytön, jne. kautta.
Kyse ei ole siitä, että tekisi kaikkea itse. Kyse on siitä, että kykenee tekemään itse. Ongelmat pitää voida ratkaista. Vaikka olisi valmis kirjasto, sitä pitää osata käyttää ja saada toimimaan.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
"Jos tarvitsee jotain tehdä, se sitten tehdään. "

No jopas. Sen verran olen kuitenkin opiskellut, että tiedän, että ongelmia olevan ylinumeroituvan monta ja ohjelmia numeroituvan monta. Suurinta osaa mahdollisista tarpeista ei voi millään toteuttaa. Älä siis jaa vääriä neuvoja, kiitos!
Kommentoi
Ilmianna
Jaa
4 VASTAUSTA:
NP täydellisiä ongelmia on, mutta sehän tarkoittaa sitä, että tarkka ratkaisu ei ole laskettavissa polynomisessa ajassa. Ei kuitenkaan tee mahdottomaksi jos vaihtoehtoja on kohtuullisesti tai jos voidaan laskea mahdollisesti epätarkka ratkaisu.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
NP täydellisiä ongelmia on, mutta sehän tarkoittaa sitä, että tarkka ratkaisu ei ole laskettavissa polynomisessa ajassa. Ei kuitenkaan tee mahdottomaksi jos vaihtoehtoja on kohtuullisesti tai jos voidaan laskea mahdollisesti epätarkka ratkaisu.
Eräitä yksityiskohtia lukuunottamatta täydellisiä ongelmia on kuvaa hyvin toimintamenetelmiä parannettaessa liian vähäisiä tuotannollisia resursseja. Kaikesta huolimatta ei kuitenkaan tee mahdottomaks mallintaa kokonaiskuvaa käyttäen hyödykseen esimerkiksi nykysukupolvia henkisesti rasittavaa elämäntyyliä. Täytyy siitä huolimatta että maailmalla on viime aikoina tapahtunut paljon, todeta, että voidaan laskea mahdollisesti epätarkka näyttelee keskeistä osaa pohdittaessa vastuuntuntoisten yhteistyökumppaneiden aatteellisia intressejä.
Kommentoi
Ilmianna
Jaa
"NP täydellisiä ongelmia on, mutta sehän tarkoittaa sitä, että tarkka ratkaisu ei ole laskettavissa polynomisessa ajassa. Ei kuitenkaan tee mahdottomaksi jos vaihtoehtoja on kohtuullisesti tai jos voidaan laskea mahdollisesti epätarkka ratkaisu."

Mahdottomalla tarkoitan sitä, että Turingin kone laskee numeroituvan monta ongelmaa mutta ongelmia on ylinumeroituvan monta. Jos vaikkapa tehtävänä on tulostaa satunnaisen reaaliluvun desimaaliesitys, niin todennäköisyydellä nolla tehtävä voidaan tehdä tietokoneella, koska vain pienellä osalla desimaaliluvuista on äärellisen monta desimaalia.
Kommentoi
Ilmianna
Jaa
Akateeminenalkaja kirjoitti:
"NP täydellisiä ongelmia on, mutta sehän tarkoittaa sitä, että tarkka ratkaisu ei ole laskettavissa polynomisessa ajassa. Ei kuitenkaan tee mahdottomaksi jos vaihtoehtoja on kohtuullisesti tai jos voidaan laskea mahdollisesti epätarkka ratkaisu."

Mahdottomalla tarkoitan sitä, että Turingin kone laskee numeroituvan monta ongelmaa mutta ongelmia on ylinumeroituvan monta. Jos vaikkapa tehtävänä on tulostaa satunnaisen reaaliluvun desimaaliesitys, niin todennäköisyydellä nolla tehtävä voidaan tehdä tietokoneella, koska vain pienellä osalla desimaaliluvuista on äärellisen monta desimaalia.
Laitetaan pilkku ja perään nollia ja desimaalien määrä voidaan leikata siihen kohtaan miten ruudulle sopii ja mikä ollut laskentatarkkuus.

Käytännön hommat sitten on semmoista että nyt on vaikka yhdessä palvelimessa se ohjelma mutta kun käyttäjiä tulee lisää niin se ei skaalaudu, että palastellaanpa se koodi niin että voidaan skaalata resurssia lisäämällä palvelimien määrää.

Tai lisätäänpä vaikka haku toiminto sinne mikä toimii reaaliakaisesti, muutetaan datan rakennetta niin että se voi hoitaa niitä asioita mitä ei alkuperäisissä suunnitelmissa ollut. Ja sitten tehdään näitä asioita kun ohjelmalla on vaikka 5000 käyttäjää että pidetään silti kaikki aiemmin tehdyt asiat ehjänä.

Niin ja sitten pitää päivittäää sitä tekniikkaa ettei mätäne ja uudella alustalla tulee muutoksia ja pitää muutella oma koodi yhteensopivaksi.

Ja olkoot se tilanne mikä tahansa niin pitäis kyetä tekemään ja samassa ohjelmassa voi olla saman asian tekemiseen useita eri tekniikoita joita on kerrostunut sinne vuosikausien aikana. Ei siis pidä olla mikään ongelma käyttää eri ohjelmointikieliä tai eri tietokantamoottoreita tai eri testijärjestelmiä.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Taidat olla aikuinen? Sitten opiskele Pythonia (uusinta). Rivi riviltä ja sisennykset koodissa, että mitä ne merkkaa, mikä mikäkin rivi suoritetaan ensisijaisesti jne.. Sitten vaan naputteleen ja koodaan :) Minulla on hankaluutena se että en tiedä mitä koodais, kun tuntuu kaikki olevan jo valmiina :D
Ilmianna
Jaa
Sanoisin, että kirjoja, artikkeleita, jne. kannattaa lukea ja teoriaa on varmasti hyvä osata.

Mutta kannattaa myös alkaa heti koodata mahdollisimman paljon itse ja toteuttaa omia projekteja, mitkä kiinnostaa. Vaikka edellä todettiin, ettei pelkkä koodaustaito yksin ratkaise kaikkkea, niin se on siitä huolimatta tärkeä perustaito jota kannattaa parantaa, jos se on heikko. Koodaamaan oppii parhaiten tekemällä itse.

Ohjelmointiala on sinäänsä mukava ala, että materiaalia on internetissäkin valtavan paljon saatavilla ja työkalut ei maksa juuri mitään.

Koulun hyvä puoli on se, että jos tyhjästä aloittaa opiskelun esim. netissä, niin voi olla vaikeaa tietää se, mitä asioita kannattaa opiskella ja missä järjestyksessä. Tässä mielessä koulunkin käynti tai kurssilistojen tutkiminen toki kannattaa, kun se antaa raamit ja aihepiirit.

Assembylä ei ylemmän tason ohjelmoinnissa taida juuri tarvita. Lähinnä se lienee tarpeellinen enempi mikrokontrollereissa, signaaliprosessoreissa, jne. kun halutaan viimeisetkin mehut irti raudasta minimi virrankulutuksella?
Kommentoi
Ilmianna
Jaa
12 VASTAUSTA:
Tuskin sielläkään tarvitsee välttämättä... Assembler lähinnä siellä missä pitää suoraan jutella raudan kanssa, että saadaaan korkeamman tason kielelle rakennettua kutsu siihen raudan käsittelyyn.

Tosin kuin jotkut kuvittelee, suorituskyky ei oikeasti ole ollut mikään ongelma vuosikymmeniin.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Tuskin sielläkään tarvitsee välttämättä... Assembler lähinnä siellä missä pitää suoraan jutella raudan kanssa, että saadaaan korkeamman tason kielelle rakennettua kutsu siihen raudan käsittelyyn.

Tosin kuin jotkut kuvittelee, suorituskyky ei oikeasti ole ollut mikään ongelma vuosikymmeniin.
Oudoksuttavaa kyllä, on useasti todettu, että eihän siinä ole mitään järkeä yksinkertaistaa yleisesti sovittuja ja toimiviksi todettuja organisaatio- ja johtamismallin muodollisuuksia.
Kommentoi
Ilmianna
Jaa
Eikös Assemblyä joudu vääntämään jos vaikka Windowsista löytyy tietoturva-aukko ja se pitäisi paikata nopeasti eikä ehdi jäädä odottamaan firman omaa päivitystiistaita? Vai heksakoodistako ne bugit paikataan?
Kommentoi
Ilmianna
Jaa
Akateeminenalkaja kirjoitti:
Eikös Assemblyä joudu vääntämään jos vaikka Windowsista löytyy tietoturva-aukko ja se pitäisi paikata nopeasti eikä ehdi jäädä odottamaan firman omaa päivitystiistaita? Vai heksakoodistako ne bugit paikataan?
Ei niitä Windowsin vikoja korjaile kukaan muu kuin Microsoft.

Aina voidaan poistaa haavoittuva toiminto käytöstä jos on kiire.
Kommentoi
Ilmianna
Jaa
"Jos tarvitsee jotain tehdä, se sitten tehdään. Ja tärkeintä on asenne, että jos ei onnistu niin se on oma vika eikä siinä välttämättä kukaan auta. Pitää kyetä tekemään itse."

"Ei niitä Windowsin vikoja korjaile kukaan muu kuin Microsoft. "

Eikö vastauksissasi ole ristiriita?
Kommentoi
Ilmianna
Jaa
Akateeminenalkaja kirjoitti:
"Jos tarvitsee jotain tehdä, se sitten tehdään. Ja tärkeintä on asenne, että jos ei onnistu niin se on oma vika eikä siinä välttämättä kukaan auta. Pitää kyetä tekemään itse."

"Ei niitä Windowsin vikoja korjaile kukaan muu kuin Microsoft. "

Eikö vastauksissasi ole ristiriita?
Ei. En sano missään, että assembleria tarvitsisi osata.

En myöskään sano missään, että pitäisi korjata ohjelmia ilman niiden koodeja. Sellaista tarvetta ei oikeastaan ole.
Kommentoi
Ilmianna
Jaa
Akateeminenalkaja kirjoitti:
"Jos tarvitsee jotain tehdä, se sitten tehdään. Ja tärkeintä on asenne, että jos ei onnistu niin se on oma vika eikä siinä välttämättä kukaan auta. Pitää kyetä tekemään itse."

"Ei niitä Windowsin vikoja korjaile kukaan muu kuin Microsoft. "

Eikö vastauksissasi ole ristiriita?
Ongelmasi näkyy olevan se, että kuvittelevat olevan sellainen tarve hankkia ohjelmoija, että se korjaa ohjelmia johon ei ole lähdekoodeja. Ei tuossa ole yhtään mitään järkeä.

Jos siellä on turvareikä niin se joko on auki kunnes korjaus saadaan tai jos on kiire niin toiminto kytketään pois päältä.

Ohjelmia ei korjata ilman lähdekoodeja. Sitä otetaan vanha ohjelma ja käytetään sitä että saadaan testit sille miten ohjelman pitäisi toimia, ja sitten tehdään uusi ohjelma.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
Tuskin sielläkään tarvitsee välttämättä... Assembler lähinnä siellä missä pitää suoraan jutella raudan kanssa, että saadaaan korkeamman tason kielelle rakennettua kutsu siihen raudan käsittelyyn.

Tosin kuin jotkut kuvittelee, suorituskyky ei oikeasti ole ollut mikään ongelma vuosikymmeniin.
Raudan suorituskyky ei olekkaan ongelma, vaan se, että miten sitä rautaa saadaan hyödynnettyä maksimaalisesti.

Noissa laitteissa, missä energiankulutus pitää minimoida, niin niissä se assembler vielä voi olla tärkeä työkalu, siis inline assemblerina juurikin.

Sitten jos täytyy virrankulutus saada vielä pienemmäksi, niin seuraava vaihe on oman piirin toteutus tarvetta varten.

Nykyään niitä tehdään enenevissä määrin FPGA piireinä, ja lähinnä vain ison volyymin tuotteissa sitten ASIC piireinä.

Softalla asian tekeminen kuluttaa yleensä noin 10 - 100 kertaa enemmän tehoa kuin raudalla tekeminen.

Raspi ja kännykät toistaa hyvin HD videota olemattomalla virrankulutuksella, kun niissä on spesiaali rauta sitä varten. ;)
Kommentoi
Ilmianna
Jaa
102030405060 kirjoitti:
Raudan suorituskyky ei olekkaan ongelma, vaan se, että miten sitä rautaa saadaan hyödynnettyä maksimaalisesti.

Noissa laitteissa, missä energiankulutus pitää minimoida, niin niissä se assembler vielä voi olla tärkeä työkalu, siis inline assemblerina juurikin.

Sitten jos täytyy virrankulutus saada vielä pienemmäksi, niin seuraava vaihe on oman piirin toteutus tarvetta varten.

Nykyään niitä tehdään enenevissä määrin FPGA piireinä, ja lähinnä vain ison volyymin tuotteissa sitten ASIC piireinä.

Softalla asian tekeminen kuluttaa yleensä noin 10 - 100 kertaa enemmän tehoa kuin raudalla tekeminen.

Raspi ja kännykät toistaa hyvin HD videota olemattomalla virrankulutuksella, kun niissä on spesiaali rauta sitä varten. ;)
"Raudan suorituskyky ei olekkaan ongelma, vaan se, että miten sitä rautaa saadaan hyödynnettyä maksimaalisesti."

Ei rautaa tarvitse hyödyntää maksimaalisesti. Tärkeintä on keskittyä siihen, että oma koodi on mahdollisimman siistiä ja hallittavaa. Sitten kun oma koodi on optimoitu mahdollisimman hallittavaksi, kunnollisella testeillä niin vasta sitten voi miettiä jotain suorituskykyoptimointeja.

Tosiasia kun on, että käytännössä yleensä kaikki aika menee hyvin hoidetuissa projekteissa siihen hallittavuuden optimointiin. Se kun hyödyttää automaattisesti sivutuotteena siirrettävyyttä, nopeutta, vähentää bugeja, testattavuutta ja jne.

Suorituskykyoptimointeja tehdään normaalisti vain silloin kun normaalilla hallittavuuden optimoinnilla suorituskyky on jossain alle siedettävien rajojen niin sinne sitten jotain inplace algoritmia tms. viilauksia. Silloinkin assembler on aika vieras juttu. Ei ole oikein missään.
Kommentoi
Ilmianna
Jaa
102030405060 kirjoitti:
Raudan suorituskyky ei olekkaan ongelma, vaan se, että miten sitä rautaa saadaan hyödynnettyä maksimaalisesti.

Noissa laitteissa, missä energiankulutus pitää minimoida, niin niissä se assembler vielä voi olla tärkeä työkalu, siis inline assemblerina juurikin.

Sitten jos täytyy virrankulutus saada vielä pienemmäksi, niin seuraava vaihe on oman piirin toteutus tarvetta varten.

Nykyään niitä tehdään enenevissä määrin FPGA piireinä, ja lähinnä vain ison volyymin tuotteissa sitten ASIC piireinä.

Softalla asian tekeminen kuluttaa yleensä noin 10 - 100 kertaa enemmän tehoa kuin raudalla tekeminen.

Raspi ja kännykät toistaa hyvin HD videota olemattomalla virrankulutuksella, kun niissä on spesiaali rauta sitä varten. ;)
Niin ja semmoinen asia vielä, että suorituskyvyn parantuminen tapahtuu automaattisesti muutenkin kuin hallittavuutta optimoimalla. Kääntäjät, ajoympäristöt ja rauta paranee kaiken aikaa ja suorituskykyoptimoinnit on helposti hukkaan heitettyä aikaa.
Kommentoi
Ilmianna
Jaa
M-Kar kirjoitti:
"Raudan suorituskyky ei olekkaan ongelma, vaan se, että miten sitä rautaa saadaan hyödynnettyä maksimaalisesti."

Ei rautaa tarvitse hyödyntää maksimaalisesti. Tärkeintä on keskittyä siihen, että oma koodi on mahdollisimman siistiä ja hallittavaa. Sitten kun oma koodi on optimoitu mahdollisimman hallittavaksi, kunnollisella testeillä niin vasta sitten voi miettiä jotain suorituskykyoptimointeja.

Tosiasia kun on, että käytännössä yleensä kaikki aika menee hyvin hoidetuissa projekteissa siihen hallittavuuden optimointiin. Se kun hyödyttää automaattisesti sivutuotteena siirrettävyyttä, nopeutta, vähentää bugeja, testattavuutta ja jne.

Suorituskykyoptimointeja tehdään normaalisti vain silloin kun normaalilla hallittavuuden optimoinnilla suorituskyky on jossain alle siedettävien rajojen niin sinne sitten jotain inplace algoritmia tms. viilauksia. Silloinkin assembler on aika vieras juttu. Ei ole oikein missään.
"Ei rautaa tarvitse hyödyntää maksimaalisesti. "

Siis se riippuu edelleenkin ympäristöstä. Jos on kyse matalavirtaisesta sulautetusta laitteesta, niin se, miten rautaa voidaan hyödyntää voi suoraan määrittää sen, mitä voidaan ylipäätänsä tehdä, koska saatavilla oleva energia ja toisaalta se miten paljon laite saa lämmetä voi olla hyvinkin tikuasti rajattuja.

Kokoajan yleistyy, esim. mittalaitteet joiden pitää haravoida energiansa ympäristöstä, ilman pääsyä verkkovirtaan tai ilman akkujen latausmahdollisuutta.

Tällaisissa tapauksissa laskennan energiatehokkuusvaatimukset on ihan eri luokkaa.

Siinä oikeastaan tasapainoillaan sen välillä, mitä kannattaa laskea laitteessa, vai kannattaako lähettää kaiki sensoridata eteenpäin ja laskea pilvessä. Mutta koska se lähetyskin vie aikalailla tehoa, niin siksi laitteessa voi hyvinkin kannattaa laskea aika paljon.

Toisaalta, jotkut tällaiset laitteet, antavat tuloksen käyttökohteeseen heti, eli se ei yleensä voikkaan kulkea pilvestä siinä välissä.

Sitten toinen ääripää on luonnollisesti vaativampi laskenta, missä taas se, miten energiatehokkaasti hommia tehdään määrittää suoraan sähkölaskun.

Esim. GPU laskennalla voidaan päästä noin 1/10 siitä energiankulutuksesta mikä perinteisellä CPU laskennalla.
Kommentoi
Ilmianna
Jaa
102030405060 kirjoitti:
"Ei rautaa tarvitse hyödyntää maksimaalisesti. "

Siis se riippuu edelleenkin ympäristöstä. Jos on kyse matalavirtaisesta sulautetusta laitteesta, niin se, miten rautaa voidaan hyödyntää voi suoraan määrittää sen, mitä voidaan ylipäätänsä tehdä, koska saatavilla oleva energia ja toisaalta se miten paljon laite saa lämmetä voi olla hyvinkin tikuasti rajattuja.

Kokoajan yleistyy, esim. mittalaitteet joiden pitää haravoida energiansa ympäristöstä, ilman pääsyä verkkovirtaan tai ilman akkujen latausmahdollisuutta.

Tällaisissa tapauksissa laskennan energiatehokkuusvaatimukset on ihan eri luokkaa.

Siinä oikeastaan tasapainoillaan sen välillä, mitä kannattaa laskea laitteessa, vai kannattaako lähettää kaiki sensoridata eteenpäin ja laskea pilvessä. Mutta koska se lähetyskin vie aikalailla tehoa, niin siksi laitteessa voi hyvinkin kannattaa laskea aika paljon.

Toisaalta, jotkut tällaiset laitteet, antavat tuloksen käyttökohteeseen heti, eli se ei yleensä voikkaan kulkea pilvestä siinä välissä.

Sitten toinen ääripää on luonnollisesti vaativampi laskenta, missä taas se, miten energiatehokkaasti hommia tehdään määrittää suoraan sähkölaskun.

Esim. GPU laskennalla voidaan päästä noin 1/10 siitä energiankulutuksesta mikä perinteisellä CPU laskennalla.
"Siis se riippuu edelleenkin ympäristöstä."

Ei riipu. Vaatimusmäärittelystä asia on kiinni.

"Jos on kyse matalavirtaisesta sulautetusta laitteesta, niin se, miten rautaa voidaan hyödyntää voi suoraan määrittää sen, mitä voidaan ylipäätänsä tehdä, koska saatavilla oleva energia ja toisaalta se miten paljon laite saa lämmetä voi olla hyvinkin tikuasti rajattuja."

Energiankulutus määrittää aika suoraan paljon tulee lämpöä. Pienempi energiankulutus tarkoittaa sitä, että energia riittää pidemmälle. Tarvittaessa energian määrää voidaan lisätä kasvattamalla energiavarastoa mutta se taas lisää kokoa ja massaa.

Jos energiankulutusta kutistaa niin käytännössä se vaikuttaa tiedonkäsittelynopeuteen kuinka nopeasti saadaan laskettua asioita. Harvemmin kuitenkaan laskenta kestää niin pitkään, että se olisi ajallisesti mikään ongelma. Hyvin usein kannattaa laskea ylimääräistä ja tiivistää dataa kun tiedon siirto on hitaampaa kuin se että käyttäisi aikaa sen tiivistämiseen ja käsittelisi tiivistettynä.

"Kokoajan yleistyy, esim. mittalaitteet joiden pitää haravoida energiansa ympäristöstä, ilman pääsyä verkkovirtaan tai ilman akkujen latausmahdollisuutta."

Tuohon ollut valmis tekniikka ns. suoraan kaupanhyllyltä varmaan 40v. Kaikki vaan parantunut kaiken aikaa.

"Siinä oikeastaan tasapainoillaan sen välillä, mitä kannattaa laskea laitteessa, vai kannattaako lähettää kaiki sensoridata eteenpäin ja laskea pilvessä. Mutta koska se lähetyskin vie aikalailla tehoa, niin siksi laitteessa voi hyvinkin kannattaa laskea aika paljon."

Tuo on helposti laskettavissa kun tietää kuinka paljon energiaa laskeaa vaikka kaksi lukua yhteen, paljon vie energiaa kun haetaan muistista bitti ja paljon vie energiaa kun persistoidaan bitti ja paljon energiaa kun lähetetään bitti.

"Toisaalta, jotkut tällaiset laitteet, antavat tuloksen käyttökohteeseen heti, eli se ei yleensä voikkaan kulkea pilvestä siinä välissä."

Millä tavalla se eroaa jos saimaalla oleva mittalaite lähettää datan ensiksi vaikka haminan datakeskukseen ja siitä sitten turussa oleva päätelaite käy kyselemässä, kuin että turussa oleva päätelaite ottaa suoraan yhteyden saimaalla olevaan mittalaitteeseen?

Ei pysty keksimään mitään tilannetta missä se olisi järkevämpää ottaa yhteys suoraan saimaalle jossa olisi laite kuuntelemassa yhteyksiä.

"Sitten toinen ääripää on luonnollisesti vaativampi laskenta, missä taas se, miten energiatehokkaasti hommia tehdään määrittää suoraan sähkölaskun."

Toki, mutta älä unohda sitä, että vuosien 1965-2013 välillä energiatehokkuus parani 100x aina 6v välein raudassa ja kääntäjät ja ajoympäristöt parantuivat myös kaiken aikaa. Tuo on siis hyötysuhteen parantumista mikä tapahtunut ilman, että ohjelmistokehittäjän tarvitsisi nysvätä itse yhtään mitään. Helposti päivittämällä ajoympäristöä ja kääntäjää saattoi tulla 2x parannus.

Pointti on se, että ohjelman rakenteen optimointi tuo automaattisesti hyötysuhteen parantumista kun nopeutuminen on siinäkin sivuvaikutus.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Opettele ohjelmiston suunnittelun periaatteet, tämä onnistuu internetistä ilman kirjojakin

Opettele jokin yleisesti käytetty ohjelmointikieli niin, että hallitset sen perusteet ja hyödynnä ykköskohdassa oppimaasi tehdessäsi ohjelmointikokeiluita. Tähän tarvitset kääntäjän, jotta saat suoritettavaa koodia jos kieli sen vaatii

Perehdy esimerkiksi open sourcen kautta olemassaolevaan koodiin ja aloita muokkaamalla olemassa olevia ohjelmia

Laadi lopulta itse jokin toimiva ohjelma

Opettele tekemään samat asiat jollakin toisellakin yleisellä kielellä

Suorita siinä sivussa jokin tutkinto vaikka AMK:sta, mutta voit toki etsiä töitä ilman tutkintoakin. Voi olla vaan vaikeampi päästä edes haastatteluun.
Ilmianna
Jaa
Olen yrittänyt opetella ohjelmointia tekemällä tehtäviä sivulta https://www.ohjelmointiputka.net/postit/ . Osa vaatii niin paljon laskentaa, että Python ei taida riittää niihin. En tiedä, onko tuo järkevin tapa opetella ohjelmointia. Tosin Eliittihakkerit taitaa vaatia vaan kekseliäisyyttä eikä sillä ole ohjelmoinnin kanssa paljoa tekemistä.
Ilmianna
Jaa
Python on hyvä alku. Hanki kirjat Learning Python ja Programming Python, Mark Lutz, O'Reilly, niistä pääsee mukavaan matkaan.

Mitä haluat tehdä? Jos esim tekoälyä, osta Russell-Norvigin kirja Artificial Intelligence, A Modern Approach, 3's painos. Jos luonnollisen kielen käsittelyä, osta Jurafsky-Martinin kirja asiasta. Jos signaalien käsittelyä, ks esim Amazon.
Kommentoi
Ilmianna
Jaa
3 VASTAUSTA:
Lähinnä kiinnostaisi data-analyysi ja koneoppiminen. Mutta ekaksi tarvitsisi varmaankin hyvät Bash-skriptaustaidot, jolla voisi ladata datatiedostoja netistä, yhdistellä niitä ja heittää ne vaikka R:lle, joka laskisi niistä tunnuslukuja. Koneoppiminen vaatii varmaan aika paljon GPU-laskentaa ellei käytä jotain Amazonin pilveä.
Kommentoi
Ilmianna
Jaa
Esim KDD (Knowledge Discovery in Databases) on iso asia. HY:llä esim Mannila et al. ovat saaneet aikaan hyviä papereita.

Mitä tulee koneoppimiseen, otetaan tässä neuroverkot. Hyvä kirja on Simon Haykin: Neural Networks, A Comprehensive Foundation, Prentice-Hall.
Kommentoi
Ilmianna
Jaa
Jos vakavissasi haluat oppia ja harjoittaa ohjelmointia: Käsiini saapui kirja Maciaszek--Liong: Practical Software Engineering, Pearson. >800 sivua. Koskee "oikeiden"ohjelmistojen tekemistä Java-kielellä, mikä kieli vielä nykyäänkin on käyttökelpoinen ja hyvä.
Kommentoi
Ilmianna
Jaa
+Lisää kommentti
Hae vaan ahkerasti, kyllä opettavat töissä ohjelmointia. Voit vaikka tutustua c# kieleen ja sit osaat alkeet, nii et ole täysin ulapalla. Netissä on materiaalia, kannattaa käydä siellä työpaikoilla kahtomassa mitä tarvitaan. Tai sitten voit käydä foorumeilla keskustella asioista niin siitäkin saa käsityksen. Kerro että tiedät teorian, mutta et käytäntöä (koodin syntaxia).
Ilmianna
Jaa
Niin on joo assemblyä harvemmin tarvitsevat yleensä käyttöjärjestelmien suunnittelijat tarvitsevat assemblyä.

Mutta niin korkealle et ilmeisesti olekaan opettelemassa?
C:täkin harvoin tarvitsee paitsi sitten joissain grafiikkakiihdyttimien ohjemoinnissa se on olennainen osa.

Tee aluksi sellainen arvauspeli jossa pitäisi arvata mikä numero tulee nopasta ja tietokone arpoo sitten mikä olisi oikea vastaus, näin aluksi?
Ilmianna
Jaa
Kun nyt opiskelee ensiksi perus tietotyypit, funktiot ja miten tietoa välitetään aliohjelmille ja miten tulos palautuu. Python on hyvä ja tietysti moni muukin. Assemblyä ei tarvitse juuri missään ja C:täkin lähinnä systeemiä lähellä olevissa jutuissa. Tuskin data-analyysissä hyötyä.

Tekee aluksi vaikka miten toisen asteen yhtälö ratkaistaan. Sitten vaikka leikkimielinen psykiatri, jonak tekoäly vastailee potilaalle. Aikoja on kuulemma vaikea saada - joten kyllä konekin voi niitä huolia kuunnella.
Ilmianna
Jaa
Osa tämän ketjun vastauksista taitaa olla tuotettu puppusanageneraattorilla. Paljon hienoja sanoja peräkkäin ilman mitään sisältöä.
Ilmianna
Jaa
Basic on melkein kuin assembleria

10 PRINT "No terve!"
20 GOTO 10
30 END

Eli goto käskyllä hypätään suoraan osoitteeseen 10, kyse on iki-loopista sillä ikinä ei päädytä osoitteeseen 30.
Ilmianna
Jaa

Vastaa alkuperäiseen viestiin

Vinkkejä, miten opiskella hyväksi ohjelmoijaksi?

Hei,

olen työtön maisteri, joka luki aikoinaan tietojenkäsittelyä sivuaineena. Jouduin pitkäaikaistyöttömäksi ja ammatillisessa kuntoutuksessa tein IT-hommia. Sen opiskelua suositeltiin jatkamaan.

Miten kannattaisi opiskella ohjelmointia? Ei ole varmaankaan taloudellisesti järkevää kirjautua oppilaitokseen, kun opintotukikuukaudet on jo käytetty. Kannattaako lainata kirjastosta yliopistokurssien kirjasuositukset ja opiskella ne vai lukea tiedeartikkeleja vai tehdä omia projekteja ja opiskella Googlen avulla? Vai koettaa säästää jostain aina parikymppiä ja käydä kurssi kerrallaan avointa yliopistoa tai ammattikorkeakoulua?

Sen verran olen tiedettä tehnyt, että pystyn omaksumaan sivun https://arxiv.org/list/cs/recent artikkeleja, mutta vaikkapa Donald Knuthin kirjat Art of Computer Programming on liian tiivistä tavaraa minulle?

Eniten kiinnostaisi vaikkapa Python, R, data-analyysi ja tekoäly, kun olen aika matemaattinen ja tilastoista tykkäävä henkilö. Mutta varmaan töihin päästäkseen olisi osattava myös ne peruskurssit ja opeteltava assemblystä alkaen asiat, koska kaverini kertoi, että joissain työssä voi pahimmillaan joutua ylläpitämään suljetun lähdekoodin projekteja ja koodaamaan konekieltä.

5000 merkkiä jäljellä

Peruuta