- Liittynyt
- 30.10.2019
- Viestejä
- 53
...
Se tekee tismalleen niin kuin on tehnyt aina ennenkin 80-luvulta asti uutta opetellessaan: lasketaan kädet suoraan saveen ja aloitetaan käytännön projekti nollapisteestä. Toisinsanottuna hypätään altaan syvään päätyyn ja joko uidaan tai upotaan...
Mulla on aina ollut tapana, että pitkän etukäteistyön, tutorial-videoiden ja loputtoman kirjalistan sijaan luen ehkä pari sivua ohjeita, jotta pääsen alkuun. Sitten lähden heti tekemään jotain isompaa projektia, sen suuremmin miettimättä, mihin kaikkeen se homma voi matkalla kaatua. Teoriaa opiskellaan lennosta lisää vasta sitten, kun seinä tulee vastaan – ei koskaan etukäteen varastoon.
Nobel-palkittu Richard Feynman kiteytti tän aikoinaan täydellisesti:
Mulla tää tapa ihan kaikessa omatoimisessa opiskelussa aina jostain ala-asteelta lähtien tehdä opettelun yhteydessä jotain konkreettista jonka tekeminen vaatii niitä taitoja joita olet opiskelemassa. Myös työelämässä itseoppimisen mutta myös alaisteni opettamisen ohjausmetodina.
Otin projektille nää selvät askelmerkit:
Koska mulla on aikaisempaa pelikehityskokemusta ja jopa oman pelimoottirinkin rakentelua niin mä päätin lähtee tekemään tyhjistä oman pelienginen SDL3-kirjastoja hyödyntäen. Nykyinen versio tän päivän jäljiltä löytyypi täältä: thengine
Se ei ole kaunein ja kattavin eikä varmaankaan toimivin mutta mutta se on suunniteltu helposti laajennettavaksi, ylläpidettäväksi sekä ymmärrettäväksi. Valitsin hyvin Microsoft XNA Framework-tyylisen arkkitehtuurin koska olin kokenut sen aiemmassa elämässäni hyväksi ja se kantaa nuo kaikki kolme peruspilaria. Yhtään koodiriviä en ole kirjoittanut, olen toiminut arkkitehtina ja pyytänyt Geminiä tekemään.
Onnistui koodiprojekti tai ei, sä saat silti sen kaikkein tärkeimmän: käytännön kokemuksen ja ymmärryksen siitä, mitä olet tehnyt viedäksesi sitä eteenpäin. Lisäksi sulta jää projektista AINA sormenjäljet ja historia – esimerkiksi GitHub-repo kaikkine committeineen. Se commit-historia ja tapa ratkoa dynaamisia ongelmia kertoo tekijästään ihmisenä ja ammattilaisena älyttömän paljon.
Parhaassa tapauksessa onnistut sekä opiskelutavoitteessasi että itse projektissa. Virheet ovat parhaita keinoja oppia, ja niitä tekee jokainen. Virheen tekemisen pelko ei saisi koskaan olla esteenä sille, että edes ALOITTAA jotain uutta ja siistiä.
Mutta jokatapauksessa sulla on näytettäväksi oma sormenjälkesi joka kertoo Commit-by-Commit ne askeleet joita olet maalisi saavuttamiseen joutunut kävelemään.
Miten vanha koodariparta oppii uutta? (Pohjustus, elämänfilosofiaa ja pelimoottoriprojekti)
Mitäs veikkaatte, mitä tapahtuu, kun vanha koodariparta päättää loikata kunnolla ulos omalta turva-alueeltaan – eli siitä perinteisestä, manuaalisesta ohjelmistokehityksestä?Se tekee tismalleen niin kuin on tehnyt aina ennenkin 80-luvulta asti uutta opetellessaan: lasketaan kädet suoraan saveen ja aloitetaan käytännön projekti nollapisteestä. Toisinsanottuna hypätään altaan syvään päätyyn ja joko uidaan tai upotaan...
Mulla on aina ollut tapana, että pitkän etukäteistyön, tutorial-videoiden ja loputtoman kirjalistan sijaan luen ehkä pari sivua ohjeita, jotta pääsen alkuun. Sitten lähden heti tekemään jotain isompaa projektia, sen suuremmin miettimättä, mihin kaikkeen se homma voi matkalla kaatua. Teoriaa opiskellaan lennosta lisää vasta sitten, kun seinä tulee vastaan – ei koskaan etukäteen varastoon.
Nobel-palkittu Richard Feynman kiteytti tän aikoinaan täydellisesti:
Visio ja tavoite: Agentit testiin
Sä et tee kaavoilla hevon hittoja jos ei tajua miten homma oikeasti toimii. Harrastusta ohjelmoinnista mulla on takana vuodesta -81 ja softainssin uraa 90-luvun puolivälistä, mutta agenttiavusteisesta sovelluskehityksestä kokemusta oli hyvin vähän. AI-kokemus rajoittui lähinnä chatbotteihin ja kuvageneraattoreihin. Google Pron myötä sain käyttööni Antigravity-kehitystyökalun, ja jokin aika sitten päässä klikkasi taas: päätin testata, mihin nää agentti-poloiset oikeasti pystyvät, kun niitä ohjaa tiukoilla arkkitehtuurisilla raameilla. Mun opiskelumetodin ymmärtää seuraavasta kolmesta bulletista:Mulla tää tapa ihan kaikessa omatoimisessa opiskelussa aina jostain ala-asteelta lähtien tehdä opettelun yhteydessä jotain konkreettista jonka tekeminen vaatii niitä taitoja joita olet opiskelemassa. Myös työelämässä itseoppimisen mutta myös alaisteni opettamisen ohjausmetodina.
Otin projektille nää selvät askelmerkit:
- (visio)Päätavoite: Opetella ja ymmärtää agenttiavusteista softakehitystä dynaamisesti.
- (project)Käytännön työkalu: Aloittaa alusta asti oma C++ pelimoottoriprojekti (thengine) tämän tavoitteen saavuttamiseksi. C++ kieltä ei tarvinnut opetella, se on *jotenkin* hallussa..
- (method)Metodi: Tehdä sivuprojektia (thengine ja sitä käyttävä testipeli) niin pitkälle kuin pystyy, ja opiskella lisää vasta kun vauhti tyssää.
Koska mulla on aikaisempaa pelikehityskokemusta ja jopa oman pelimoottirinkin rakentelua niin mä päätin lähtee tekemään tyhjistä oman pelienginen SDL3-kirjastoja hyödyntäen. Nykyinen versio tän päivän jäljiltä löytyypi täältä: thengine
Sieltä löytyy tämän päiväisen session lomilta koodit, testiaplikaatio ja jonkin verran jo dokumentaatiotakin josta näkee mihin se pystyy.
Se ei ole kaunein ja kattavin eikä varmaankaan toimivin mutta mutta se on suunniteltu helposti laajennettavaksi, ylläpidettäväksi sekä ymmärrettäväksi. Valitsin hyvin Microsoft XNA Framework-tyylisen arkkitehtuurin koska olin kokenut sen aiemmassa elämässäni hyväksi ja se kantaa nuo kaikki kolme peruspilaria. Yhtään koodiriviä en ole kirjoittanut, olen toiminut arkkitehtina ja pyytänyt Geminiä tekemään.
Lisäksi mainittava on se, että kaikki on tehty Gemini 3.5 Flash (Medium) mallilla, eli sillä nopeimmista tarjotuista. Kun suunnitelmat purkaa arkkitehtuurisiksi ja loogisiksi paloiksi ennenkuin ne antaa agentille niin token-saldoa säilyy pirusti.
Mulla meni varmaan ajallisesti enemmän aikaa tuon CLAUDE.md-tiedoston kirjoittamiseen (omasta päästä!) kuin siihen agentin käskyttämiseen...
Sitten sitä elämäntapafiliosofiaa:
Älä pelkää virheitä – jätä sormenjälkesi
Moni jättää aloittamatta, koska pelkää tekevänsä virheitä tai epäonnistuvansa. Ongelmien sijaan pitäisi kuitenkin katsoa mahdollisuuksia. Vaikka se sun konkreettinen työn alla oleva projekti (kuten pelimoottori) joskus kaatuisi tai jäisi kesken, se ei tarkoita, että sun alkuperäinen opiskelutavoitteesi epäonnistui.Onnistui koodiprojekti tai ei, sä saat silti sen kaikkein tärkeimmän: käytännön kokemuksen ja ymmärryksen siitä, mitä olet tehnyt viedäksesi sitä eteenpäin. Lisäksi sulta jää projektista AINA sormenjäljet ja historia – esimerkiksi GitHub-repo kaikkine committeineen. Se commit-historia ja tapa ratkoa dynaamisia ongelmia kertoo tekijästään ihmisenä ja ammattilaisena älyttömän paljon.
Parhaassa tapauksessa onnistut sekä opiskelutavoitteessasi että itse projektissa. Virheet ovat parhaita keinoja oppia, ja niitä tekee jokainen. Virheen tekemisen pelko ei saisi koskaan olla esteenä sille, että edes ALOITTAA jotain uutta ja siistiä.
Mutta jokatapauksessa sulla on näytettäväksi oma sormenjälkesi joka kertoo Commit-by-Commit ne askeleet joita olet maalisi saavuttamiseen joutunut kävelemään.
