Vinkkejä, miten opiskella hyväksi ohjelmoijaksi?

Hah! Matti karvaperse ei taaskaan onnistunut tuomaan esiin muuta kuin asenteitaan. Hah! Toisen kerran. Mene pölvästi jonnekin häpeämään olemassaoloasi.

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?

"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.

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.

Lue lisää

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.

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.

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.

Lue lisää

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ä.

"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.

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.

Lue lisää

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ä.

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.

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.

Lue lisää

Oudoksuttavaa kyllä, on useasti todettu, että eihän siinä ole mitään järkeä yksinkertaistaa yleisesti sovittuja ja toimiviksi todettuja organisaatio- ja johtamismallin muodollisuuksia.

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?

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?

Lue lisää

Ei niitä Windowsin vikoja korjaile kukaan muu kuin Microsoft.

Aina voidaan poistaa haavoittuva toiminto käytöstä jos on kiire.

"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?

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?

Lue lisää

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.

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?

Lue lisää

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.

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.

Lue lisää

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. ;)

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. ;)

Lue lisää

"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.

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. ;)

Lue lisää

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.

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.

Lue lisää

"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.

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.

Lue lisää

"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.

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ä.

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.

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ä.