tietotekniikan opukset

Kuinka oleellista tietotekniikkaa opiskellessa on hiffata käytännössä kaikkea termistöä ja teoriaa esim. käyttöliittymä, komponenttikirjasto tai miten koodi muutetaan konekielelle yms. ja opetella miten ne liittyy ohjelmointiin vai kannattaako aluksi vaan tehdä niitä yksinkertaisia tehtäviä?

Ensimmäisenä kannattaa ihan opetella silmukat, rekursiot yms. asiat. Tämä onnistuu parhaiten lukemalla joku tuollainen tietorakenteita ja algoritmeja käsittelevä kirja (kuten tuo Lafore) kunhan ensin jonkun kielen syntaksi on hallussa. Tämmöisen kirjan opettelu opettaa sitä ongelmanratkaisua, jota siis ohjelmointi pohjimmiltaan on. Parempi siis lähteä perusteista liikkeelle. Ei kukaan 4-jakoisella punttailuakaan aloita... ainakaan toivottavasti. ;)

Kääntäjäteknologian tunteminen ei ole kovin oleellista, mutta kääntäjän toiminnan tunteminen kyllä varmasti auttaa kirjoittamaan parempaa koodia. Kääntäjiä käsittelevissä kirjoissa käsitellään toisaalta usein työkaluja kuten lex ja yacc, jotka ovat suht hyödyllisiä tuntea. Näiden ymmärtäminen toisaalta vaatii sitten tietojenkäsittelyteorian tuntemista (ts. säännölliset kielet, äärelliset automaatit jne.). Tämä on jo sitten aika pitkälti matikkaa ja modernin kääntäjän ohjelmoiminen on jo sitä rakettitiedettä. :)

Tosiaan kun on oppinut jonkun ohjelmointikielen, niin tietojenkäsittely on pohjimmiltaan ymmärtää miten joku ongelma ratkaistaan tehokkaasti. Esimerkkinä voi vaikka ottaa korttipakan korttien järjestämisen maittain kasvavassa järjestyksessä. Tässä on esim. kaksi tapaa:

1. Otat pakan käteen ja käännät päältä kortin ja laitat sen pöydälle. Jatkat korttien kääntämistä ja lisäät seuraavan kortin aina oikeaan kohtaan pöydällä olevaan pakkaan. Kun olet kääntänyt pakasta kaikki kortit, niin pöydällä on pakka, jossa kortit järjestyksessä.

2. Heität kortit ilmaan ja keräät ne kasaan. Tarkastat onko pakka järjestetty. Jos ei, niin heität kortit uudestaan ilmaan ja jatkat.

Ei ole kovin vaikea keksiä kumpi tapa järjestää kortit nopeammin. Tietojenkäsittelyn ideana on keksiä systemaattisia nopeita tapoja suorittaa yksinkertaisia proseduureja. Tietojenkäsittelyn tutkimus on käytännössä keksiä nopein mahdollinen tapa suorittaa joku toiminto. Tietokoneohjelman teko on periaatteessa ongelman hajoittamista sellaisiin osiin, että osat ovat ratkaistavissa. Tässä on siis vaikeutena sekä osien tunnistaminen, että jokaisen erillisen osan määrittävän ongelman ratkaiseminen. Ensimmäinen opitaan yleensä kokemuksella kun taas toinen on sitä mitä ohjelmointikirjat opettaa...
 
10% ALENNUS KOODILLA PAKKOTOISTO
muistelisin naksu jostain, että olit tefyä lukenut tkk:ssa. Aloititko ohjelmoinnin vasta tkk:n kursseilla vai jo aiemmin?

Olen kyllä ollut ihan tietotekniikan osastolla vaikka luin sitten tietojenkäsittelyteoriaa ja matikkaa pääasiassa. Ohjelmoinnin aloitin 11-vuotiaana QBasicillä ja vuotta myöhemmin opettelin C:n ja x86 prosessorin assemblyn ja sitä tuli oltua aika monta vuotta töissä koodaajana yläasteen lopussa ja lukiossa koulun ohessa (IT-boomin aikoihin pääsi kuka tahansa tohelo töihin ;)).

Kun tuossa ekassa postauksessa mainitsit, että olet tekniikkaa lähdössä lukemaan, niin TKK:lleko? Jos haluaa nopeasti päästä tekemään jotain yksinkertaisia ohjelmia, niin suosittelen tosiaan edelleen Javan sijasta seuraavia kirjoja:

How to Design Programs
Structure and Interpretation of Computer Programs

Jälkimmäinen näistä ampaisee 1. kappaleen jälkeen tosiaan liikkeelle aika kovaa, mutta ensimmäinen kappale on hyvää luettavaa. Tuon jälkeen voi sitten lähteä vaikka sen Javan kimppuun. Ei tuo loppua kohdenkaan ihan mahdoton ole. Luin sen aikanaan lukion 1. luokalla TKK:lla opiskelevan kaverin suosituksesta, joten se ei mitään ihmeempiä taustoja esim. matikasta vaadi (eikä siis oleta, että on aikaisemmin ohjelmoinut).
 
Mutta kuinka paljon tite-DI tekee koodausta? Miten tite-DI:n ja titeinssin työkuvat eroaa? Entä onko ohjelmistoarkkitehdit hc-osaajia verrattuna peruskoodareihin?

DI ja inssi saattavat tehdä ihan samaa työtä. Työnkuva riippuu enemmän firmasta ja sovellusalueesta kuin koulutuksesta. Mun mielestä uran alussa kannattaa koodata vaikka sitten myöhemmin suuntautuisi johonkin muuhun.

Ohjelmistoarkkitehdeillä on melkein poikkeuksetta jonkunlainen koodaritausta. Jotkut ovat hyviä koodareita, jotkut keskinkertaisia ja jotkut vain entisiä koodareita :). Ohjelmistoarkkitehdin työt on jonkun verran monipuolisempia kuin koodarin ja osaamista pitäisi olla laajemmalta alueelta (eri tekniikoita, tuotteita, jne.). Ulospäinsuuntautuneisuudesta ja bisneksen tajuamisestakaan ei ole haittaa.
 
Allekirjoittaneen vinkki kouluun lähtijöille: nauttikaa kesästä älkääkä stressatko etukäteen. Kyllä ne asiat teille koulussa opetetaan.

Perustelu: Itse suoritin TTY:llä täysin nollapohjalta kaksi C++ -kurssia. Homma alkaa sen verran alkeista, että kyllä jokainen pysyy tahdissa mukana jos on normaaliälyllä ja jonkinlaisella motivaatiolla varustettu. Työtä se vaati aika paljon, mutta loppujen lopuksi suoriuduin kursseista hyvillä arvosanoilla, vaikka en käynyt luennoilla ja vain muutamissa harjoituksissa. Osaanotto noihin olisi tosin voinut olla järkevää, sillä aika paljon jouduin tuskailemaan yritys-erehdys-menetelmällä harjoitustöiden kanssa.

edit: tietysti onhan opiskelu varmasti helpompaa, kun on jo pohjatiedot hankittuna ja sinänsä voi olla järkevää lueskella jos haluaa päästä tulevaisuudessa helpommalla. Mutta samat asiat pystyy silti oppimaan ja kursseista suoriutumaan niin hyvin kuin haluaa, vaikka ei ennakkotietoja yhtään olisikaan.
 
Allekirjoittaneen vinkki kouluun lähtijöille: nauttikaa kesästä älkääkä stressatko etukäteen. Kyllä ne asiat teille koulussa opetetaan.

Tämä on totta. Toisaalta on hyvä tietää, että siellä TKK:lla ei vielä opi kovinkaan hyväksi ohjelmoijaksi, koska se vaatii paljon käytännön vääntämistä. Tämä vaikka opiskelisi tietotekniikkaa. Tästä syystä kesäduuneissa tuli tavattua kaikenlaista säätäjää, joiden puolesta melkein häpesi, koska olivat dippainssejä. Riippuen suuntautumisesta, niin sitä ei välttämättä joudu koodaamaan juuri ollenkaan.

Oma tapani lähestyä opintoja oli valita vain sellaisia kursseja, jotka olivat sisällöltään liian raskaita, jotta suurella todennäköisyydellä en jaksaisi perehtyä niihin itsenäisesti tutkinnon suoritettuani. Tämän takia luin esim. vain minimimäärän software engineeringiä, koska syventävät kurssit aiheessa olivat aika kevyitä ja mikään ei estänyt lukemasta vapaa-ajalla tuota minkä aika monen kurssin kohdalla teinkin.

Jos haluaa osaamisessaan erottua mahdollisimman paljon AMK-inssistä, niin suosittelisin opiskelemaan seuraavia: formaalit menetelmät, rinnakkais ja hajautetut järjestelmät, tietojenkäsittelyteoria, logiikka, matematiikka, kääntäjäteknologia, tiedon louhinta, koneoppiminen, hahmontunnistus, tietokonenäkö... TKK:lla siis käytännössä seuraavan laitoksen tarjontaa:

http://www.ics.tkk.fi/fi/

Tällä vaihtoehdolla menee sitten opiskelun vaikeuden suhteen siitä mistä rima on korkein, joten motivaatiota kannattaa olla riittävästi. Myös ohjelmistotekniikan labralla on joitain mielenkiintoisia tietokantoja käsitteleviä kursseja (ei siis miten käytät tietokantaa, vaan miten ohjelmoisit itse tietokantamoottorin).

Hyvä kysymys on toisaalta sitten miten hommat erottuvat AMK-inssistä. Erona on periaatteessa se, että keskittymällä esim. mainitsemiini asioihin, niin sitä pitäisi voida tehdä melkein mitä tahansa työtä tietotekniikan saralla, mutta toinen juttu on onko esim. Suomessa sitä. Sellaiset paikat, joissa oikeasti pääsee ratkaisemaan vaikeita softaongelmia (joissa vaikeus ei ole järjestelmän koon ja epäselvien vaatimusten aiheuttama, vaan esim. algoritmien ja tietorakenteiden keksiminen ja kovien suorityskykyvaatimusten täyttäminen) on aika kiven alla täällä pohjolassa. ;)
 
Olisiko fiksu veto tehdä yliopistolla(tite-DI) ensin vain matematiikkaa parina ensimmäisenä vuotena lukien samalla omatoimisesti tietotekiikkaa ja sitten vasta siirtyä yliopiston tietotekniikan kursseihin?
 
Olisiko fiksu veto tehdä yliopistolla(tite-DI) ensin vain matematiikkaa parina ensimmäisenä vuotena lukien samalla omatoimisesti tietotekiikkaa ja sitten vasta siirtyä yliopiston tietotekniikan kursseihin?

Heti mukaan vaan titen kursseille, jotta saat edes jotain hajua mitä tuleman pitää. Omatoiminen opiskelukin on tällöin tuottoisampaa.
 
Sori kun nostan vanhan ketjun, mutta harkitsen vakaasti yrittämistä yliopistoon sisään tietotekniikalla. Mitkä kirjat olisivat hyviä osata pääsykokeita ajatellen? Mieluiten suomeksi. En tiedä juuri mitään ohjelmoinnista jne.

Eli pääsykokeita silmälläpitäen. Mitä minun tulisi osata ja mitkä olisivat hyviä kirjoja tuohon tarkoitukseen?
 
Donald E. Knuth:n tuotantoa suosittelen lukemaan jos tietojenkäsittelytiede kiinnostaa.

Ja jos joku haluaa opetella oikeasti ohjelmoimaan niin (mielestäni) kannattaisi aloittaa C-kielellä. Perusteluina on:
- kun aloittaa kielellä joka ei "suojaa" tai peitä käyttäjän virheitä niin oppii ihan oikeasti joskus välttelemäänkin niitä virheitä.
- Yksinkertainen kieli jolla on helppo päästä alkuun.
- C:stä on helppo halutessaan harpata C++:n ja/tai javaan.
- Koodin/algoritmien profilointi/analysointi helppoa. Ohjelman nopeus riippuu pääpiirteessään vain omasta ohjelmastasi, eikä minkään garbage collectorin tai tulkin toteutuksesta.
- C-osaajia haetaan rekry ilmoituksissa suht. paljon vaikkapa verrattuna ruby/python osaajiin (tai siis ainakin niissä joita olen seuraillut). Ja mitä olen huhuja kuullut niin listassa ensin mainituilla on palkkakin yleensä vähän parempi. (jos näin maallisia ajatellaan)

Ja vielä tuosta, joissain viesteissä mainitusta, tiettyyn kapeaan osaamisalueeseen keskittymisestä, oman "kokemukseni" mukaan vähintään 95% koodaushommista on jotain muuta kuin varsinaista algoritmien suunnittelua. Ja yleensä vähänkään monimutkaisempien algoritmien suunnitteluun osallistuu läjäpäin kaikenlaisia "asiantuntijoita" eli ohjelmoija ei välttämättä suunnittele mitään kovin matemaattista vaan hommana on vain valmiiksi suunnitellun matemaattisen mallin siirto ohjelmakoodiksi.

Yleensä noilla "kapeilla aloilla" saa olla paras jos haluaa saada juuri sen alan hommia joskus jatkossakin. Parempi vaihtoehto on, omasta mielestäni, opiskella perusteet hyvin, syventyä opiskeluaikana muutamaan eri aiheeseen paremmin ja jatkaa tuota syventymistä sitten työelämässä paremmin. Näin siis siinä tapauksessa jos myös työskentely alalla kiinnostaa. Toisaalta kyllähän niitä apuraha tutkijoitakin aina johonkin yliopistoon (tms. laitokseen) mahtuu.

Ja yleensä noissa pääsykokeissa matematiikka on painoarvoltaan korkealla (ainakin ollut).

Eriäviä mielipiteitä odotellessa...
 
Donald E. Knuth:n tuotantoa suosittelen lukemaan jos tietojenkäsittelytiede kiinnostaa.

Ja vielä tuosta, joissain viesteissä mainitusta, tiettyyn kapeaan osaamisalueeseen keskittymisestä, oman "kokemukseni" mukaan vähintään 95% koodaushommista on jotain muuta kuin varsinaista algoritmien suunnittelua. Ja yleensä vähänkään monimutkaisempien algoritmien suunnitteluun osallistuu läjäpäin kaikenlaisia "asiantuntijoita" eli ohjelmoija ei välttämättä suunnittele mitään kovin matemaattista vaan hommana on vain valmiiksi suunnitellun matemaattisen mallin siirto ohjelmakoodiksi.
Tämä on itseäni askarruttanut. Miten matematiikkaa käytännössä tarvitaan näissä suunnitteluhommissa? Kuinka HC-tason matematiikka tarvitaan?
 
Tekniikan aloille luulisi tietotekniikasta olevan hyötä.Jos haluaa itsenäisesti opiskella esim. ohjelmointia ja tietotekniikkaan liittyvää, niin kannattaako lähteä liikkeelle jostakin tietotekniikan perusopuksesta vai ohjelmointikirjasta?

Netistäkin löytyy hyviä materiaaleja joita kannattaa tsekata varsinkin jos ei halua ostaa vielä kirjaa tai ei tiedä minkä kirjan hankkisi.

Java:
http://java.sun.com/docs/books/tutorial/
http://cs.joensuu.fi/~vouti/tjdoku/JAVA/index.html
http://javala.cs.tut.fi/show.do?category=java_perusteet

C/(C++):
http://cs.stadia.fi/~silander/ohjelmointi/
http://cpp.mureakuha.com/cpp/cppperusteet.htm


Itseltäni löytyy seuraavat kirjat:
Pentti Hirvonen:Ohjelmoinnin alkeet C-kieltä käyttäen,
Päivi Hietanen: C++ ja olio-ohjelmointi,
Mika Vesterholm-Jorma Kyppä: Java-ohjelmointi,

Pitäisi vielä löytää melkein Javan J2ME:n kirja tai mieluummin joku hyvä ja yksinkertainen nettisaitti.
 
Tämä on itseäni askarruttanut. Miten matematiikkaa käytännössä tarvitaan näissä suunnitteluhommissa? Kuinka HC-tason matematiikka tarvitaan?

Tjaa, mahtaakohan tähän olla mitään yleispätevää vastausta?
Suunnittelussa pitäisi ensin tunnistaa ongelma, joka halutaan ratkaista ja osata esittää se matemaattisessa muodossa. Tämä ei vielä kovin syvällistä matematiikan tuntemusta vaadi - taikasana: boolean algebra. Varsinaisessa ongelman ratkaisussa pärjää edelleen vähän heikommillakin pohjilla, mutta löydetyn ratkaisun tehokkuuden ja aukottomuuden arvioinnissa korostuu enemmän matematiikan ymmärrys ja kiinnostus algoritmien pyörittelyä kohtaan.
Omiin työtehtäviin liittyvän matematiikan (kapean?) osa-alueen sujuva hallinta auttaa kummasti päivittäisissä työtehtävissä ja uralla eteenpäin. Toisaalta jos insinöörin koulutuksen matematiikka tuntuu liian vaikealta, niin sitten kannattaa miettiä muita hommia.
 
Tämä on itseäni askarruttanut. Miten matematiikkaa käytännössä tarvitaan näissä suunnitteluhommissa? Kuinka HC-tason matematiikka tarvitaan?

Ala on niin laaja, ettei yksiselitteistä vastausta voi antaa, mutta varmaan suurimmassa osassa suunnittelijan tehtävistä ei matematiikkaa tarvitse kärkistettynä kuin oikean veroprosentin laskemiseen. Mutta mikä sitten lasketaan matematiikkaan, ja mikä loogiseen päättelykykyyn. Tarkoitan nyt nimenomaan perustietojärjestelmiä, joiden parissa Suomessa suurin osa ilmeisesti työtään tekee. Hitech-jutut on sitten erikseen. Noissa perushommissa riittää että kirjoitettu koodi on jokseenkin järkevää ja toimii. Jos järjestelmän arkkitehtuuri ja tietokannan pää on huonosti suunniteltu tai niitä käytetään väärin, niin joku koodinpätkän infernaalinen optimointi on melko turhaa hifistelyä. Esim. jos koodi tekee yhden turhan silmukan vrt. että siinä yhdessä silmukassa luodaan turhia transaktioita (joiden takia tehdään turhia temppuja monta kertaa peräkkäin), SQL on huonoa ja kaiken lisäksi kannan indeksit ja suunnittelu on vituillaan ja saadaan kunnon lukko eskalaatiot. Yksinkertainen esimerkki.

Itse siis pidän tavallisen suunnittelijan tärkeimpinä asioina sellaista laajaa (mielellään useamman) ohjelmointikielen tuntemista, että koodista saa lyhyttä ja selkeää. Siihen lisäksi perusalgoritmien ja yleisimpien ohjelmarakenteiden tuntemista. Silloin jos pitää alkaa rakentelemaan jotain helvetillisiä viritelmiä, niin tietää että mentiin metsään. Todennäköisesti siihen on joku valmis ja parempi toteutus jo jossain. Lisäksi toinen tärkeä asia on se järjestelmäkokonaisuuden tuntemus ja ymmärrys siitä, että mihin se aika, sepun aika ja muistinkäyttö kuluu yhdessä ketjussa.

Tuo edellä mainittu Mika Vesterholm-Jorma Kyppä: Java-ohjelmointi-kirja lienee paras suomenkielinen Java-kirja. Ja on itseasiassa ihan hyvä perusteos Javasta. Muista kotimaisella kirjoitetuista tietotekniikan teoksista en osaa sanoa juuri mitään.
 
Kernighan-Richie eli valkoinen raamattu ja se on siinä. Javaa, C++aa ja muuta kannattaa toki lukea myös, mutta ensin kannattaa aloittaa... alusta. Vuosi oli 1978 ja ...
 

Latest posts

Suositut

Back
Ylös Bottom