Maanalainen vallankumousliike alkoi kurssin edetessä vaatia minua kirjoittamaan myös oppimispäiväkirjaa. Olen kuitenkin tämän kurssin itsevaltias ja styranki, joten en suostu, paitsi vähän. Koska tämä on kivaa, kirjoitanpa tällaisen tuntoja, tunnustuksia ja tunnontuskia kirjoituksen. Luurankoja en esille kaiva, mutta jotain taustoja aiheiden ja tekniikoiden valinnoista kertonen. Tämä ei sitten ole mallioppimispäiväkirja.
Tarjoan tämän myös esille jo raakana rohkaistakseni teitäkin kirjoittamaan ja julkaisemaan omanne. Täydentelen ajan kanssa.
Mitä enemmän Korppiin ja sen tekemiseen tutustuu, sitä mielenkiintoisempaa on huomata, kuinka se muistuttaa niin paljon sitä ohjelmistotyötä, mistä minulla on kokemus tai mitä olen kuullut ohjelmistotyöstä yliopiston ulkopuolella.
Esitys oli rehellinen, mutta hieman ehkä turhan kyyninen tekijöitä itseään, ja heidän tekemistään kohtaan. Täytyy kyllä myöntää, että edellisviikon kenraaliharjoitus, eli Korpin esittely Johdatus Ohjelmistotekniikkaan -kurssilla, oli vielä kyynisempi. Taisin silloin asiasta Minnalle mainita, joten sävy taisi hiukan muuttua.
Ei, ei siinä kyynisyydessä sinänsä mitään pahaa ole, mutta ehkei siihen niin suuri tarve olisi, kuin mitä esitys antoi ymmärtää. Kuten myöhemmin Markku Rossi SSH:lta esityksessään sanoi, jokaisen ohjelmistokehittäjän tulisi oikeutetusti tuntea ylpeyttä tekemisestään. Myönnän, että Korpissa on joitakin sotkuja. Niistä saa mm. kivoja artikkeleita kirjoitettua — kröhöm — mutta ihan niin sotkuinen ja sekava, kuin esityksestä välillä saattoi väärin tulkita, ei Korppi ole.
Yksi ongelma esityksessä oli terminologinen. Kehittäjät puhuivat monesti kehityksestä, vaikka mielestäni olisi voinut käyttää termiä ylläpito. Myös code and fix tuli monesti esiin hieman siinä valossa, että se olisi ainoa tapa, millä Korppia on kehitetty. Monesti se on ollut tapa suunnitella ylläpitoa, ja tämän ymmärrän, vaikkei akateeminen minäni sitä haluaisikaan hyväksyä. Ongelma ei ole tekijöissä, vaan organisaatiossa: ei ole tarpeeksi resursseja — aikaa, tekijöitä tai rahaa, vaan aina on kiire. Minkäs silloin teet? Varsinainen kehitys taas on usein tapahtunut projekteissa, joissa taas asiaa on suunniteltu hyvinkin perusteellisesti. Ja tietääkseni kaikki suuremmat ominaisuudet ja vipstaakelit on suunniteltu juuri projekteissa, ylläpidossa on saatettu tehdä sitten joitain sovittamisia yksilöiden tahdon (ja mieltenailahtelujen) takia. Olen sortunut jälkimmäiseen, kiitos Korppilaiset taipumisesta :)
Ah, se Korppi viiden vuoden päästä -kysymys oli hyvä. Sitä pitäisi pohtia useammin. Tuonpa oman näkemykseni tarjolle: Viiden vuoden päästä Korppi on kasa työkaluja ja komponentteja, joita yhdistelemällä on luotu joukko sovelluksia, kullekin laitokselle mukautettuja, joilla kursseja ja opintokirjanpitoa hallinnoidaan. Erona nykytilanteeseen on parempi mukautuminen, niin laitoksen, kuin Korpinkäyttäjä-yksilön tarpeisiin. Näppärä opiskelija tai luennoija voi tehdä Korpin juuri haluamakseen, ottaen siihen mukaan vain itselleen tarpeelliset toiminnot ja jopa lisäten joukon omia, kokonaan uusia toimintoja. Korpin voi myös silloin varsin helposti integroida muiden järjestelmien yhteyteen. (Heh, sori Korppilaiset, jos asetin paineita.)
Tarkoituksena ensimmäisessä demossa oli keskustella niistä työkaluista, mitä ohjelmoidessa on kukin tullut käyttäneeksi. Alla on keräämäni, ehkä hieman vajaa lista. Ehdottakaa täydennyksiä! IDEt jätin tarkoituksella pois.
Grep on jokaisen ohjelmoijan paras ystävä. Se kertoo mistä tiedostoista löytyy tai ei löydy haluttu säännöllisenä lausekkeena ilmaistu merkkijono. Kuullostaa tylsälle, mutta kun kerran käyttää, ei sovelluskohteille enää loppua näy. Niin paljon on tästä alastamme vain tiedon etsintää. Find on sopiva kumppani grepille, se näet etsii tiedostoja tiedostojärjestelmästä eri atribuuttien mukaan. Atribuutteja voi olla vaikkapa tyyppi (tiedosto, hakemisto), luontiaika tai nimi. Täten findilla saa vaikkapa rajoitettua grepin etsimään merkkijonoa kaikista java-lähdekooditiedostoista.
Emacs ja Vim ovat tekstieditoreita, joilla on ikävä taipumus paisua jokapaikanhöyliksi, paitsi Vimillä, joka on hieman rauhallisempi paisunnassaan. Emacs on hieno esimerkki työkalusta, joka on laajennettavissa ja muokattavissa. Se on suurelta osin kirjoitettu omalla Lisp-murteellaan, EmacsLispillä. EmacsLisp on myös se teknologia, jolla Emacsia voi laajentaa ja muokata. Valmiita laajennoksia löytyy niin postin ja nettiuutisten lukemiseen, kuin monien ohjelmointikielten kirjoittamiseen, tai vaikkapa psykologiin, joka Emacsista löytyy vakiona. "Kaikki paitsi keittiöallas" on mukana tai ainakin saatavilla, kuten Emacsin mainoslause sanoo (ja keittiöallas löytyy myös, ohjelman ikonista).
Vim taas on kätevä ja näppärä, ja varsinkin voittaa Emacsin mielestäni puhtaassa tekstin tuottamisessa ja editoinnissa, paitsi jos teksti on Lisp-koodia. Tähän touhuun on Emacsiin saatavilla, paitsi jo valmiit varsin hienot vermeet, myös todella hieno editorilaajennos Slime.
Niin, Vimin taas tekee Emacsia kätevämmäksi tekstintuottoon Vimin tekstin editointikomennot, jotka monelle aloittelijalle ovat kauhistus. Vim on näet moodillinen editori, eri moodeissa toimivat eri komennot. Vimissä ei juurikaan ole Emacsmaisia "paina control ja sen lisäksi 12 muuta näppäintä tallentaaksesi tiedoston" -tyylisiä sormiakrobatioita. Ei, Vimissä on komentokehote, jolta komennot syötetään. Erityisesti säännöllisillä lausekkeilla tehtävät etsi ja korvaa -toiminnot ovat hienoja, ja helposti rajoitettavissa haluttuun alueeseen tekstistä, jonka alueen voi myös rajata säännöllisillä lausekkeilla. Muuten komennot ovat yleensä yhden tai kahden näppäimen perättäisiä painalluksia. (Juu, kirjoitan tätä Vimillä).
Diff etsii ja näyttää erot kahdesta tekstimuotoisesta tiedostosta. Diffin tuloksen voi antaa patchille, joka osaa muokata tämän tiedon avulla lähdetiedostosta kohdetiedoston tekemällä diffin listaamat muutokset lähdetiedostoon.
Onhan noita versiohallintatyökaluja muitakin, omat mieltymykset ja yleisyys vain tuovat CVS:n ensimmäisenä esille. CVS:n mainospuheet ovat selkeät. Oletko koskaan kaivannut lähdekoodisi vanhaa versiota takaisin? Oletko alkanut muokkaamaan jaettua lähdekooditiedostoa vain huomataksesi, että kaverisi on ylikirjoittanut sen hävittäen juuri eilen tekemäsi tärkeät muutokset? Eikö olisi hyvä säilyttää lähdekoodi yhdessä paikassa helposti ja hallitusti jaettavasti.
Minä pidän CVS:stä juuri sen keräämän historiatiedon tarkkuuden takia. Toiset inhoaa CVS:ää sen tarjoamien lähdekoodin kehityksen haarauttamisen työkalujen hankaluuden vuoksi. Jos et tykkää, kokeile muuta, vaikka sitten sitä Subversionia, kun se on nyt niin hip ja pop. Kunhan pysyt erossa Microsoftin SourceSafesta, sillä jos MS ei ole sitä korjannut, toimii se lähinnä silppurina.
Mozilla ja Firefox selainten kehittäjät ovat kehittäneet monia ohjelmointia auttavia työkaluja. Nämä työkalut auttavat varsinkin hajautetun laajan ohjelmistokehityksen osallisia, mutta on niistä apua jo parin henkilön projekteillekin. Eniten meillä käytössä oleva Mozilla-työkalu on Bugzilla, vaatimus- ja virhetietokanta, johon voi tallentaa uudet vaatimukset ohjelmistolle ja ohjelmistosta raportoidut virheet, bugit. Bugzilla ohjaa myös näiden käsittelyä, tarjoaapa jopa äänestys- ja muistutusmahdollisuuden, sekä piirtää graafeja bugien määrän kehityksestä (alaspäin?).
Kaikki haluavat nykyään piirrellä ohjelmansa palloina, tikku-ukkoina ja laatikoina. Kaikki tahtovat maksaa itsensä kipeäksi UML-piirtelytyökalusta nimeltä Rational Rose. Noh, onhan siinä Rosessa hyviäkin puolia, aina se jonkun tavallisen piirtelytyökalun, kuten Dian tai sen Microsoft Vision voittaa, sillä Rose hallitsee yhteyden piirretyjen kaavioiden ja kaavioiden sisältöjen välillä. Joskus se jopa on hallitsevinaan joitain yhteyksiä piirtelyiden ja lähdekoodin välillä, mutta tässä on fundamentaalisia, Rosesta riippumattomia ongelmia. Ja taitaa ne muut kaupalliset CASE-välineet maksaa aika lailla Rosen verran.
Jos haluaa päästä halvemmalla, voi kokeilla ilmaista ArgoUML:ää tai sen kaupallista versiota Poseidonia. Poseidon on kuulemma vakaampi.
UMLGraph on hieman toisenlainen tapa tehdä UML-kaavioita. Se näet generoi UML:n javadoc-kommenttien sisällöstä ja java-tiedostojen luokkamäärittelyistä. Tämä ei tarkoita, että UMLGraph olisi vain Java-työkalu, mutta sen käyttöön tulee osata Javaa.
CRC-kortit, Class-Collaboration-Responsibility -kortit, ovat mielestäni hienoin tapa, valkotaulun ja ohjelmoinnin lisäksi, suunnitella ohjelmia. Kortit ovat noin täkäläisen tavallisen postikortin kokoisia. Niissä on ylhäällä luokan nimi, vasen kaksi kolmannesta listaa luokan vastuut ja oikea kolmannes luokan yhteistyökumppanit.
Muistakaa silti, käytitte sitten UML:ää tai CRC:tä, että teette olio-ohjelmointia. Olio-ohjelmointia, ei luokkaohjelmointia.
Make on vanha tuttu monesta osasta koostuvan ohjelman kääntämisen aputyökalu. Se tutkii, mitkä tiedostot pitää kääntää uudelleen, ja mitä muita toimia tästä seuraa. Tämän make tekee sille annetun Makefile-tiedoston avulla.
Jos haluat Makefilen tabulaattorisidonnaisuuden vihastuttamana kiusata itseäsi XML:llä, löytyy makelle varsinkin java-maailmassa kovasti käytetty kumppani Ant.
Javadoc on työkalu, joka kerää javalähdekoodin javadoc-kommenteista lähinnä ohjelmointirajapintadokumentaation. Javadocia voi laajentaa omilla docleteilla (ohjekelisäkkeillä?). Vastaavia järjestelmiä on muillekin ohjelmointikielille tarjolla.
Perl teki nämä kaikille tutuksi, nyt niitä ilman ei voi enää elää. Mene ja opiskele heti, ettet ole yhtä tyhmä kuin minä.
Jännää oli, kuinka keskustelu pysyi vahvasti ohjelmankoodin kirjoittamis-, kääntämis- ja käsittelytyökaluissa, mutta prosessia ja työskentelyä yleensä varten tehtyjä työkaluja sai hakea kissojen ja koirien kanssa. Tämä kertoo todella paljon alastamme. Valitettavasti.
Nyt olen tuon kielivuodatuksen jäljiltä vähän puhki, joten tyydynpä tekemään pienen viittauksen. Tämä Stallmanin haastattelu on oikein hyvää luettavaa, mutta minusta hän kompastuu taas viimeisessä kappaleessa omiin oppeihinsa: Jos et ole meidän kanssa, olet meitä vastaan. Kaikki ovat vapaita, toiset vaan ovat vapaampia kuin toiset. Osoittakaa taas arvon lukijat minun olevan väärässä!
Yritetäänpä uudestaan. Kävin tässä välissä kuuntelemassa kolmen uuden professorin virkaanastujaispuheet (tänään on 24.11.2004, jos ketä kiinnostaa kaivaa proffien nimet esille). Missä sinä olit, jos et ollut heitä kuuntelemassa? Olihan yksi professoreista tuore tietojärjestelmätieteen professori! Noh, ensimmäisenä heistä puhui äidinkielen professori. Hän pohti mm. kielen monimuotoisuutta – puhuttua, kirjoitettua, ilmehdittyä, viitottua, … – sekä analogioiden löytämisen vaikeutta, varsinkin tieteen matemaattisen vahvoilla analyysimalleilla. Nannaa, sano! Laitan linkin, jos löydän puheet joskus verkosta.
Niin, monet mainostavat kovasti vapaan ohjelmistokehityksen kollektiivisuutta, toiset (paitsi vapaan softan kannattajat) puhuvat avoimuudesta tai halpuudesta. Rosenqvist osaa tapauksellaan minusta hienosti tuoda esiin sen, mikä vapaassa (ja avoimessa?) ohjelmistokehityksessä on todella tärkeää: vapaus täyttää itse omat tarpeensa, oli sitten kyse työkaluista, ajanvietteestä tai itseilmaisusta. Noh, mitäpä tuohon enää lisäämään.
Olette monet pohtineet Rosenqvistin sanomaa enemmän tai vähemmän epäillen hänen hieman radikaalia näkemystään. Avatkaa silmänne. Ohjelmointi ja ohjelmistojen tekeminen on helppoa, ja ennen kaikkea kivaa. Se on jotain, mitä kukaan ei ole voinut ennen meitä tehdä. Jotkut ovat ajatelleet, toiset ovat säveltäneet, mutta siinä laajudessa, kuin voimme tietokoneita nykyään käyttää, vastaavaa tilaisuutta ei ole maailmanhistoriassa tätä ennen ollut. Noh, ehkä kirjoitustaito :)
Koska tuo ohjelmointi on helppoa, sen voi oppia ja ohjelmoida voi kuka tahansa, jolta kiinnostusta tai tarvetta löytyy. Eikä todellakaan ole heidän heikkoutensa, jos heidän koodinsa laatu ei täytä meidän vaatimuksia. Kuten tuolla myöhemmin tulee ilmi, me olemme oman alamme ammattilaisia, ja meidän on ilo olla ylpeitä meidän osaamisestamme. Mutta meidän ei tarvitse osoittaa ylpeyttämme kritisoimalla heitä, joilta vastaavaa tietoutta ei löydy. He tietävät jotain enemmän kuin me, me voimme auttaa heitä siinä, mitä me tiedämme paremmin kuin he. Miten me voimme auttaa? Paras tapa mielestäni on opettaa muita ja tehdä heille (ja meille!) työkaluja, joilla voimme paremmin tehdä sen, mitä he ja me tarvitsemme.
Toinen näkemys: Pupesoft tekee sen minkä lupaa. Mitä muuta haluat?
Tästä päästäisiin mielenkiintoiseen keskusteluun siitä, mitä muita kuin toiminnallisia vaatimuksia ohjelmistolle on asetettu, mitä on ohjelmiston laatu. Tämän keskustelun jätän kuitenkin arkkitehtuurikurssille.
Vielä kolmas näkemys, tämä heille, joita Pupesoftin koodi arveluttaa: Mulla on koodi, miksen jo parantaisi sitä? Kyllä siitä koodimassasta aineistoa jokuseen opinnäytteeseenkin riittäisi ;-)
Pari melkein unohtunutta muistikirjamerkintää vielä talteen. Rosenqvist kommentoi "…katsomalla, mihin korjaukset kasautuu, tilintarkastaja saa selville…" Kivaa! Tutkimalla tilinpidon toimien historiaa saadaan selville riippuvuuksia ja kenties heikohkoja kohtia tilinpidossa. Toimisikohan tuo lähdekoodille? ;-)
"Firman täytyisi sopeutaa prosessinsa uuteen softaan mahdollisesti tuhoten pääprosessit." Lainaus lienee yksi parhaimmista syistä tukea sovitettujen ohjelmistojen kehittämistä.
Eclipse on laajennettava muokkainkehys, joka mielletään usein vain kohtalaisen mukavaksi Java-kehittimeksi. Kyllä sillä onnistuu muidenkin ohjelmointikielien käyttö, ja jos ei onnistu, on Eclipse tehty helpoksi laajenta. Helpon laajennettavuuden takia Eclipselle löytyykin paljon lisätyökaluja. Aloita tutustuminen osoitteesta: http://www.eclipse.org/
JUnit taas on ohjelmoijatestikehys Java-kielisten ohjelmien kehittämiseen. Ennen ohjelmoijatestit tunnettiin nimellä yksikkötesti, mutta nykyään niistä käytetään yksikkötesti-termin ylikuormittumisen estämiseksi termiä ohjelmoijatesti.
Ohjelmoijatestejä käytetään Extreme Programming -ohjelmointityylisuunnan lisäksi myös testilähtöisessä kehityksessä (Test Driven Development). Idea tässä on perin pelottava: toteutetaan ohjelmoijatesti ennenkuin kirjoitetaan bittiäkään varsinaisesta toteutuksesta. Ajetaan testi, ja huomataan, ettei se mene läpi. Muutetaan toteutusta mahdollisimman yksinkertaisesti ja selkeästi niin, että testi menee läpi. Varmistetaan testin kattavuus, jos testi ei ole kattava, muokataan sitä ja jälleen toteutusta. Lopetetaan, kun testi on kattava, menee läpi ja toteutuskin on riittävä.
Teimme tämän hieman toisin demoissa. Kirjoitimme heti aluksi kunnon testin, jonka jälkeen muokkasimme toteutusta niin kauan että se toimi.
(Kirjoitan tätäkin pätkää Nääsvillen Oliopäivien iltana (kts. alla).) Yksi asia, minkä täällä Nääsvillessä kuulin, ja jonka toivon muistaneeni mainita demoissa on seuraava. Kun kirjoittaa ensin testin, tulee itse käyttäneeksi sitä rajapintaa, jota on kehittämässä. Tällöin huomaa huomattavasti helpommin, mitä ongelmia rajapintaan ja sen käyttöön on suunnitteluvaiheessa saattanut jäädä. Eat your own dog food!
Jokusen kerran olen tainnut sanoa niin tietoturvan, kuin tietoliikenteen (protokollien) yhteydessä, että jättäkää ne ammattilaisille. Tämä ei tarkoita sitä, etteikö tekijästä voisi tulla ammattilainen. Perusteluni on ollut aina, että jollet tiedä, miten sinusta tulee ammattilainen, lopeta haaveilu ja keskity omaan ammatilaisuuteesi. Markku Rossin luento tuki tätä ajatusta mielessäni.
Joo, tiedän, että tuo näyttää kovin eliittiajattelulle, mutta sori vaan, noin olen maailmaa ympärilläni tulkinnut. Jos joku osoittaa minulle olevani väärässä, olen erittäin iloinen siitä. Siihen asti olen kuitenkin sitä mieltä, että asioihin kasvetaan, oli ne sitten ammatteja tai luonteita tai muita kiinnostuksia elämässä. Toiset ohjaa enemmän kasvuaan itse, toiset jättää ohjauksen maailmalle.
Itse ollut SSH:n kanssa tekemisissä ollessani töissä Data Fellowsilla. Siellä tuotteistimme joitakin SSH:n teknologioita, mm. Markun mainitsemaa SSH Toolkitiä. Markun luento olikin mukava muistutus kaikista niistä opeista, mitä olen saanut molemmilta yrityksiltä. Käynpä niitä tässä lyhyesti läpi.
Ohjelman kehittäjä on ammattilainen ohjelmien kehittämisessä. Kukaan muu ei tunne ohjelmien kehittämisen oppeja niin hyvin kuin hän. Ja ammattilainen on aina ylpeä tekemisestään. Ammattilaisen tulisi myös aina voida olla ylpeä tekemisistään, ja saada tehdä työnsä niin, että hän voi olla siitä ylpeä.
Kyllä se vaan niin on, että ne jotka osaavat, he tekevät. Jos on tarve ja jos on taito, niin tulosta syntyy. Mikä tässä on ihmeellisintä on se, että tulosta syntyy myös hyvin vailinaisissa tai jopa vihamielisissä ympäristöissä.
Toinen mielenkiintoinen piirre on se, että kun osataan, tehdään myös se, mitä täytyy tehdä. Tarpeellinen, juuri tarpeellinen, eikä ylimääräistä, silti huomaten myös sen yksityiskohdan, mikä muuten olisi jäänyt varjoon piiloon. Tästä ilmiöstä on hyvä esimierkki seuraava. Jos suunnitellaan, tehdään se siksi, että siitä on hyötyä, ei siksi että täytyy suunnitella.
Pienin askelin, testaillen, kokeillen, rauhallisesti eteenpäin. Ohjelmaa, sovellusta tai järjestelmää ei ymmärrä, ennenkuin se on olemassa. Ohjelmiston lähdekoodi on ohjelmiston suunnitelma.
Jahas, veljekset jälleen tukkanuottasilla. Markku toi hyvin esille sen, etteivät C ja C++ ole kuolleita kieliä. Ei edes Lisp ole, eikä Smalltalk, eikä varsinkaan Cobol, vaikka markkinamiehet mitä yrittää sanoa. Eikä myöskään mikään kieli ole parempi kuin toinen. Koko vertailu on mieletön, ellei sitten kyseessä ole jonkin kielen eri murteiden välisten kielen määritelmästä löytymättömien ominaisuuksien tai tulkinnanvaraisuuksien vertailu.
Kyllä, jotenkin tähän taloon on päässyt syntymään sellainen tyhjiö, ettei täällä opeteta tarpeeksi ohjelmointia, saatikka ohjelmointikieliä, minun mielestäni. Varsinaisia ohjelmointikursseja on ihan mukavasti, tosin olen kärkäs ehdottamaan niihin sisältömuutoksia. Se minua vain ihmetyttää, että kun tällä tietotekniikan ja informaatiotekniikan alalla ollaan kuitenkin varsin kiinni noissa tietokoneissa, ja ainut tapa saada tietokoneet tekemään jotain on ohjelmoida ne tekemään se jotain, niin miksi ihmeessä ohjelmointi jätetään lapsipuolen asemaan suurella osalla kursseista? Ohjelma on lopulta se ainut väline osoittaa ajatuksensa ja ideansa oikeaksi. Ohjelma on kuin todistus matemaatikolle. Tämä onkin suurin anti, mitä matematiikasta on meille, taas mielestäni.
Ohjelmoimaan oppii ohjelmoimalla ja tutkimalla muiden kirjoittamia ohjelmia. Ohjelmoimaan oppii vielä paremmin opiskelemalla ohjelmointia usealla eri kielellä ja usealla eri tavalla ohjelmoida (lue: eri ohjelmointiparadigmalla, jos niin haluat). C, C++ ja Java ovat lopulta hyvin samanlaisia kieliä, jos niitä vertaa vaikkapa Smalltalkiin, Haskelliin tai Lispiin, jotka jo keskenään ovat hyvin erilaisia kieliä. Kysymys ei ole se, eikö meillä opeteta C/C++:aa, vaan se, eikö meillä opeteta muuta kuin Javaa. Tiesittekö muuten, että sulautettua ja laiteläheistä suunnittelua tehdään hyvällä menestyksellä jopa Lispillä *.
C-ihmiset rauhoittukaa. Arvostan kieltänne plussilla ja ilman paljon enemmän kuin voisi alkuun luulla. Hienoja ja tarpeellisia kieliä molemmat, vaikka suuret ajattelijat mitä tahansa väittävät. Ja tulisi niistä enemmän meilläkin puhua, vaikka kunnon perusopinnoilla kielellä kuin kielellä ei uusien kielien opiskelu ole ongelma. Jos se ongelmalta tuntuu, kannattaa etsiä ongelmaa katsomalla peiliin.
Ja voisitteko ystävällisesti kertoa yksityispostina minulle sen henkilön nimen, joka täällä opettaa C:n ja C++:n olevan huonoja ja kuolleita kieliä, ja Javan olevan tehokas ja hienompi kieli kuin C/C++, niin minä käyn pikku visiitillä hänen luonaan. Kökönjauhanta saa siltä osin luvan loppua.
Aloitimme varsinaisen demoaiheen, eli Naked Objects -oliomalliin tutustumisen. Turhat risut pois: annetaan demoissa linkki ohjeisiin, tehdään niistä suomennettu lyhennelmä, erittäin lyhyt sellainen, ja käsketään osallistujia toteuttamaan Vesa Lappalaisen ohjelmointikurssilta tuttu Kerho-ohjelma. Ja hyvinhän se meni, eikä aikaakaan mennyt turhan paljon. Positiivinen alku, seuraavissa demoissa sitten vähän enemmän ideologiasta ja työkalusta.
Ai, Naked Objectsista on myös .Net-versio. Joor feivriit neiked zänneel, joor feivriit neiked peidz…
Juu, kaikille ei NO tuntunut sopivan. Väitän tässä törkeästi, että tottumus on toinen luonto, kyllä se NO on paljon loogisempi käyttää, jos ei vain ole ensin ylitottunut nykyisiin käyttöliittymiin. Minna kommentoi tätä tuoreeltaan: Mietitäänpä pelien peruskäyttöliittymää. Pelilaudalle raahataan sotilaita, aseita, … mitä milloinkin tarvitaan. Ei niitä valita perinteisen ohjelman tyyliin yläpalkista File > New > … Samoin olioita (niitä aseita) käytetään ölleröä klikkaamalla. Niissä voidaan navigoida toisten ölleröiden kautta. Mitäs Nakedin oliolla tehdään? Virkistävää vaihtelua nuo NO:n käyttöliittymät edes, jookosta?
Integraatio on päivän sana. Yrityksen tietojärjestelmät tulee saada toimimaan yhteen. Tuohan on selvää, sillä karsitaan päällekkäisyyksiä ja tehdään työnteosta joustavampaa. Ongelma on iso, sillä tietojärjestelmät yrityksessä ovat usein yksistään jo isoja, saati sitten niiden yhteisjoukon koko. Puhumattakaan ongelman koosta, kun huomioidaan kytkentöjen määrä, joka tarvitaan, jotta ohjelmat voivat kommunikoida minkä tahansa toisen (tarpeellisen) ohjelman kanssa. Geneerisyyttä ja sopimuksia peliin. Välikerroksia ja tietomuuntimia, yhteisiä formaatteja ja käytäntöjä. Niinpä saadaan ongelma ratkaistua.
Sitten tuo orkestraatio kolahti. Hetkinen, eikös tuota tässä ole taas kyse analogioista? Millä tavalla tämä touhu eroaa ohjelmoinnista? Millä tavalla tämä touhu eroaa sovelluskehityksestä? Joose varmaan tykkää kyttyrää seuraavasta, mutta sanonpa kuitenkin: ei sen tulisi erota. Kyse on lopulta samasta asiasta, tällä hetkellä vaan tuolla integraatiopuolella homma ei ole edennyt ihan samalle tasolle kuin ohjelmistokehitys on jo ylettynyt hätäisesti kurottautumaan. Lopulta, onkos tuolla sovellusintegraatiotouhulla niin paljon eroa tavan sovelluskehitykseen? Pitäisikö vain oppia tekemään yhteentoimivia ohjelmia?
Myöhemmin Microsoft saapui esittelemään meille tavallaan omaa näkemystään asiasta. Otetaanpa nyt vähän takapakkia. Vanhassa tietokoneessa nimeltä Amiga oli myöhemmissä käyttisversioissa mukana järjestelmä, AREXX, jonka avulla käyttäjä ja ohjelmat pystyivät ohjelmallisesti ohjaamaan toisia ohjelmia. Erona perinteiseen skriptikielimaniaan oli se, että ohjelmiin oli kirjoitettu mukaan AREXX-portteja, joiden kautta ohjelmien toimintaa pystyttiin ohjaamaan. Nykyään esimerkiksi Mac OS X:n AppleScript lienee vastaavanlainen järjestelmä.
Mitä tapahtuisi, jos voitaisiin luoda yleisesti hyväksytty (ja turvallinen, sori Joose) vastaavanlainen järjestelmä, ja saada se laajalti käyttöön?
Joosen luento herätti paljon keskustelua, mutta Jonne mokasi aikataulun, joten NO-testaukselle jäi turhan vähän aikaa. Ohjelmoija- testien osalta se on kuitenkin aikalailla JUnit-touhua, mutta niitä hyväksymistestejä ois voinut tehdä. Heips! Nythän mun pitäs aktivoitua ja kirjoittaa demo 6:een hyväksymistestit! Hihii!
Santtu, niinkuin Joosekin, on kolleegani Soneran työajoiltani. Kuten luennolla kävi ilmi, keskustelimme Santun kanssa Sonera-aikoina paljonkin asioista, jotka ulkopuolisista olisivat saattaneet kuullostaa aivan muulta kuin työnteolta.
Teimme ja tutkimme silloin, kaipa tuosta saa nyt jo puhua, hajautettua olioarkkitehtuuria. Lyhyesti alusta oli sellainen, että pystyimme käynnistämään olion johonkin tietokoneeseen, hakemaan sen sieltä nimen, tunnisteen tai myöhemmin palvelukuvauksen avulla, käyttämään sitä ohjelmakoodissa, tai jopa kirjoittamaan ohjelmat niin, että jos ne löysivät lisää hyödyllisiä olioita verkosta, ne pystyivät ottamaan oliot käyttöönsä. Jokainen olio siten julkaisi itsestään kuvauksen, ja muut oliot pystyivät rekisteröitymään kuuntelemaan noita kuvauksia. Ketään ei varmaan yllätä, että nuo kuvaukset perustuivat ontologioihin.
Ei kannata kuitenkaan muistella turhaan menneitä, eikä tuudittautua siihen olotilaan, että asiat olisivat jääneet tuolle mallilleen. Me käytimme tuohon aikaan Javaa ja CORBAa työkaluinamme — kyllä, CORBAlla voi tehdä dynaamista koodia, uskallan väittää, että jopa kaikkea sitä mitä näillä XML/WS/SOAP-härpäkkeillä, mutta järkevämmin ja nopeammin. Harmi vaan, että sitä CORBAa pitää opiskella, eikä voi vain XML:ää suoltaa. Äh, nyt meinaa taas mennä CORBAn ylistykseksi. Kokeilkaa itse, mutta käyttäkää jotain muuta kieltä kuin C:tä tai C++:aa. Java, ja varsinkin Python ovat mukavia kieliä totutella CORBAan.
Jäin tuon luennon jälkeen pohtimaan asiaa, josta on jo aikoinaan tullut Santunkin kanssa puhuttua. Kaikille lienee selvää, että minulla on kohtuullisen vahvat oliolasit päässäni. Niinpä kaikki tuo ontologia-puhe näyttää minun silmissäni jälleen yhdeltä olio-ohjelmoinnin ilmentymältä. Kuitenkin on selvää, ettei pelkkä ontologia riitä sovelluksen kehitykseen. Se auttaa paljon, mutta se jättää paljon pois. Kaikki se poisjäävä on sitä, minkä pitäisi olla meidän erikoisalaamme. Kaikki se on sitä, minkä olemassaolon ymmärtäminen on yksi ohjelmistoarkkitehtuurikurssin pääasia, mielestäni. Kaikki se poisjäävä on sitä, mitä me teemme tietotekniikan ammattilaisina.
Vaan ovatko nämä kaksi luokittelua, oliot ja ontologia, toisiinsa kietoutuneita vai ortogonaalisia? Voidaanko toinen toteuttaa hyödyllisesti ilman toista (ontologia), ja onko toinen vain toisen tuki (oliojäsennys)? Vai ovatko ne toisillensa hyödyksi vain kudottuna vahvaksi kankaaksi? Olisi helppo äänestää tuon kangasteorian puolesta, aspektit ja muut moniulotteiset kiinnostuksen jaot kun ovat niin tapetilla nykyään, mutta pelkäänpä, ettei asia ole noin yksinkertainen. Luulen sen olevan vielä yksinkertaisemman.
Elikkä, tehtävänä tehdä kirjojenvarausjärjestelmä, vähän kuin kirjastossa. Koodatkaa!
Idea toimi ihan hyvin, osallistujat pohtivat, haastattelivat asiakasta, jakautuivat ryhmiin, ja saivat varsin pitkälle edenneen ensiversion softasta aikaiseksi. Hienoa. Toiset kiroilivat kehystä, toiset tykästyivät. No, dokumentaatio on mitä on, ja tehty vielä aiemmalle versiolle.
AYBABTU, vaan oli ne työkalut ihan kätsyn näköisiä. Kuinka vaan kävis niillä jonkun ison (oikean?) järjestelmän teko? Onko silloin vielä hyötyä siitä, että saa käsin käydä heittelemässä nappeja verkkosivuille?
Saattoihan tuossa ehkä käydä hieman niinkin, ettei esitys täysin palvellut kuulijakuntaansa. Ehkä tämä pitää laskea esityksen yleisyyden piikkiin, hankala on räätälöidä jokaiselle sopiva esitys, jos on kiertueella julistamassa jotain yleistä sanomaa. Ehkäpä olisi aiheellista Microsoftin pohtia, tulisiko sanoma sovittaa kuulijakuntaan hieman. Aiemmin päivällä he olivat käyneet ammattikorkealla, muistaakseni, ja sanoma oli mielestäni hieman ammattikorkeakoululle sopiva, tai meidän peruskursseille. Itse olisin kaivannut lisää tietoa ja kommenttia Microsoft Researchista, sieltä kun tuntuu nykyään varsin päteviä ihmisiä löytyvän. Alikoski meni myöhemmin illalla ehdottamaan, että josko he tekisivät tulevaisuudessa kierroksen korkeakouluissa vaikkapa Eric Meyerin kanssa. Toivottavasti tämä idea saa kannatusta Microsoftin suuressa ja mahtavassa johtoportaassa.
Sivunmennen sanoen, ja kuten Tuovisen Teron päiväkirjasta voi myös lukea, on aika jännää, miten Microsoftiin on todella vaikea, ainakin minun, asennoitua neutraalisti. Puolet luennosta olin kuulevinani rankkaa FUDia, puolet pyyteetöntä itsearvostusta. eiväthän he ole toiminnassaan yksin, pahempiakin esimerkkejä löytyy, mutta kai se on tuo monop… anteeksi, markkinajohtajuus, joka saa niskakarvat nousemaan pystyyn, jopa aiheetta. Eilen Iso Sininen, tänään Billy-boy, kukalie huomenna? Välistä täytyy kuitenkin pysähtyä ihailemaan kuinka he ovat saaneet kaiken sen aikaan, mitä ovat saaneet. (Hei, mä tykkäsin Visual Basicista aikoinani, ja Basicista yleensä, vaikka ei MS:llä sen syntyyn ole mitään sanomista, olivatpahan aika yleinen Basic-toimittaja.) Miten he ovat sen saaneet aikaan, se onkin sitten eri keskustelun asia. Kaikesta heidän toiminnastaan en voi olla iloinen… Markkinajohtajalla on vastuunsa, jopa suurempi vastuu, kuin pikkupelaajilla.
Toinen osuus, eli Iljan ensimmäinen, sisälsi aika hyviä lausahduksia. No, niistä rikkaista käyttöliittymistä en koskaan päässyt selville. Vaan hyvä kysymys oli: haluaako ihmiset maksaa laskuja wapilla? Niinpä, miksi koetetaan tehdä kaikki samat asiat joka kerta uudestaan ja uudestaan uusille laitteille ja tekniikoille? Miksi ei voisi välillä pysähtyä pohtimaan, millä uusilla tavoilla voi uutta laitetta tai teknologiaa käyttää?
Aha, Vesa ja Minna auttoivat tuon rikkaan käyttöliittymän ymmärtämisessä. Olin väärinkuullut Iljan sanoneen, että skriptien käyttö selaimissa olisi typerää, kun hän olikin sanonut, että skriptien käyttämättömyys selaimissa on typerää. No, nytpä tuli sekin virhe oikaistua, ja kaipa nuo skriptilliset liittymät ovat niitä rikkaita liittymiä.
Toinen hyvä kommentti oli "uusmediabisnes kuoli siihen, että käyttöliittymä ja data oli erillään, vähän bisneslogiikkaa käyttöliittymässä". Nih, MVC ja kerrosliittymätkö rulaa? Voisiko myös alkaa pohtimaan vaihtoehtoista mallia, jossa aktiiviset kohteet itse täyttäisivät vastuunsa.
Ja vielä kolmas, Iljan toiselta puoliskolta: Antakaa käyttäjän myös itse päättää, mitä tiedoilla tehdä.
Mutta markkinahumu ja tuotearvonnat eivät kuulu yliopistoissa esiintymiseen. Siitä Microsoftille piiiiiiitkä PR-miinus. :(
Ai, kaikille teille, joilla oli hauskaa Microsoftin fysiikkasimun esittelyn yhteydessä (minä myös hymyilin äänekkäästi, kunnes Lappalaisen Vesa muistutti tästä): Miettikääpäs mitä tapahtuisi, jos painovoima yllättäen pienenisi. Apua mietiskelyyn voitte hakea muistelemalla sitä demoa. Filosofit joukossamme voivat pohtia, kuinka hankalaa on ihmisen kuvitella mitään muuta kuin sen mihin hän on tottunut.
<vitsi>Ai2, C# on tuomittu häviämään.</vitsi>
Jahas, väsymys iski, näemmä. Olisi alussa ollut hyvä pitää vähän pidempi rupeama kehyksen parissa. Hiljalleen edistyimme siltikin.
Dokumentaatio ja opastus ontuu NO:ssa, juu. Yleiskuva kehyksestä tuntui silti olevan jälkeenpäin perin positiivinen. Pomoa kehityksen ohjastukseen olisi osa kaivannut, osa ei.
Demojen tulos löytyy joko zippinä tai selailtavassa muodossa.
Kirsi Koponen kirjoittaa Pupesoftin luennon osuudessaan seuraavasti: Odotetaanko kaikilta palkatuilta 24/7 panosta, vai palkataanko edes niitä, jotka eivät siihen ole valmiita? Tämä toi mieleeni ehkä jo joidenkin teidän tunteman kauhutarinan, jonka on kirjoittanut erään suuren pelikustantajan erään ohjelmoijan parempi puolisko. Hrrr… kylmää…
Tuomas Turpeinen pohti WM-data osuudessaan, ettei sovelluskehityksessä ja -integraatiossa kuitenkaan ole kyse avaruusraketin rakentamisesta. Taas villi assosiaatio, tarjolla joko html tai pdf muodossa. Heti alussa kerrotaan hieman avaruusrakettien rakentamisen historiasta. Kannattaa lukea koko kirjoitus.
Seuraavaksi päiväkirjoista poimittuja palasia ja kommenttejani niihin.
Näin sanoi Arkko: Vähän kyllä pisti mietityttämään kun Jarmo Rosenqvist sanoi ettei tiedä mitä heidän sovellukseen liitetty vapaa koodi todellisuudessa tekee, "Kunhan se tekee mitä tarvii". Luulisi että tämä olisi jonkin asteinen tietoturva riski, koodihan voi tehdä taustalla vaikka mitä. Kannattaa huomioida, että kyseisessä tapauksessa tekijöitä on ollut aika vähän. Varmaankin he silti ovat hieman tarkempia tulevien, täysin ulkopuolisten koodilisäysten kanssa. Kaikki kun maailmassa eivät ole kilttejä.
Itse olen huomannut, että töissä nuoret ohjelmoijat yrittävät tehdä täydellistä koodia. Onko tähän syynä näyttämisen halu vai yritetäänkö tehdä maailmasta parempaa koodaamalla täydellistä koodia mihin palaa rahaa. Vanhemmat koodaajat toisaalta tekevät sen mitä sopimuksessa lukee eikä vahingossakaan yhtään enempää.Joo ja sitten jäi epäselväksi mikä ontologia oikein on ? "Oppi olevasta". Se on se filosofien määritelmä, meidän määritelmän voi tarkistaa Santun kalvoista.
Olisi ohjelmistotuotannon kannalta hyvä jos asiakkaalla ja toimittajalla olisi sama käsitys asioista. Suurimmat ongelmat ohjelmistotuotannossa olen kohdannut asiakastapaamisissa. Puhutaan samoilla sanoilla mutta täysin eri asioista. Niinpä, jos kulttuuri on erilainen, kuinka sen oppisi ymmärtämään. Päättymäisillään olevien syksyn sovellusprojektien loppuesitystilaisuudessa kyselin, kuinka projektit olivat oppineet puhumaan asiakkaan kieltä. Useampi oli alussa tämän ongelman kanssa painiskellut, toiset olivat saaneet tulkin väliin.
Millä tavalla tuota voisi sitten helpottaa? Noh, meillä on vapaa opiskeluoikeus, opiskelkaa perusteita usealta alalta. Työelämässä, jostain luetun esimerkin mukaan, jos pitää tehdä kirjanpito-ohjelma, laitetaan kehittäjät ensimmäiseksi kirjanpitokurssille. Siellä oppii peruskäsitteet ja termit, ja niin helpottuu kommunikaatio asiakkaan kanssa. Yleistiedosta ei myöskään ole haittaa, kirjastossa on paljon kirjoja luettavaksi. Tai nukittakaa ryijyjä, tai kutokaa mattoja, tai harjoitelkaa vaikka vatsatanssia. Uudet asiat opettaa, uusien asioiden parissa tutustuu uusiin ihmisiin, joiden maailmankuvan kanssa vuorovaikutus saa meidänkin maailmankuvamme laajenemaan. Ja ymmärrys lisääntyy.
Näin kirjahutti Hastrup: En oikeastaan pidä tekstitilassa toimivista ohjelmista sekavuuden ja heikon opittavuuden vuoksi. Entäs Emacsin tutoriaali? Onko siitä apua? Tämä on todella tiedusteleva kysely, sillä itse olen monesti yrittänyt lukea Emacsin ja Vimin tutoriaaleja, mutta väsähtänyt kesken matkan. Mukavampi on kokeilla ja testata (ja sitten käyttää päivä asian tekemiseen, joka olisi hoitunut parilla napinpainalluksella, jos vain olisi sattunut oikealle sivulle opaskirjassa).
Agoralla tuskin onnistuu, kun edes syntaksiväritystä ei ilmeisesti ole asennettu.
M-x font-lock-mode[RET], eli joko Alt-X tai Escape ja sitten X, jonka
jälkeen komento font-lock-mode ja enter/return/rivinvaihto.
Satuin demotilaisuutta seuraavana päivänä kyseisen kurssin luennolle, ja jonkun kalvon yläreunassa puhuttiin "UML-menetelmästä". Ehkä kaikki peruskurssit ovat opiskelijoiden harhaanjohtamista.
Näinpä, joskus iskee valtava voimattomuuden tunne.
Olen aiemmin oppinut, että testien tuloksen pitäisi olla vakio — eikä siis riippua satunnaisluvusta — jotta tulos olisi aina toistettavissa ja olisi selvää, läpäiseekö ohjelmistoversio testit vai ei.
Hyvä kommentti! Yritän uida verkosta sillä, että satunnaisluvut ovat kovin riippuvaisia
satunnaisgeneraattorin siemenluvusta, eli kiinnitämme siemenluvun, ja saamme aina
saman sarjan satunnaislukuja, jos satunnaislukugeneraattori on hyvä.
Siis pseudosatunnaislukugeneraattori on hyvä. Tietty jos luvut generoidaan
verkkodatasta ja mikrofonin äänittämästä taustahälinästä…
Tarkoituksena oli toteuttaa Naked Objects -menetelmän tutkimusvaihe kirjaston lainausjärjestelmälle, mutta pieleen taisi mennä. Demo-ohjeen mukaan vaiheessa pitäisi toistaa olioiden ja niiden vastuiden määrittelyä, prototyypin toteuttamista ja toimintaskenaarioiden kokeilua protolla.
Näinhän siinä taisi käydä. Toisaalta on hyvä huomata, että oppi (muilta kursseilta)
on mennyt perille. Toisaalta huomaan, että olisin voinut olla hieman vaativampi.
3d-luonnosteluohjelma Teddy
Teddy
on kiva, kaikkien tulee kokeilla Teddyä!
Loi lausumahan Hyvärinen:
…mutta olen ajatellut siirtyä Eclipseen. En ole tutkinut minkälaiset kalut siinä
on J2EE kehittäjälle, todenäköisesti loistavat. Täytynee tutkia jossain vaiheessa,
kun on enemmän aikaa.
Monet päätyvät, ainakin Tomcatin yhteydessä, tähän:
http://www.sysdeo.com/eclipse/tomcatPlugin.html
. Korppi pyörii tuon kanssa Mac OS X:ssä ja Eclipsessä ihan mukavasti, jos vain
ottaa huomioon 256 Mt keskusmuistin aiheuttaman hitauden. Rakas Joulupukki, saanko
lisää muistia?
Olisi tehnyt mieli kysyä tässä yhteydessä, että ovatko he esimerkiksi ohjelmoineet C:llä oliomaisesti, jolloin dynaamisen sidonnan ja perinnän jäljittelemistä voisi tulkita jonkinlaisena Patternina.
Ovat. ;)
Tosin täytynee seuraavaksi tutkia oman koodin lukemista paperilta, kun siitä niin moni muukin Jonnen lisäksi näköjään suosittelee ;)
Kiitos. Juuri tuo paperiltaluku mielestäni auttaakin tuohon omaan sokeuteen. Kannattaa
kuitenkin olla virkeänä kun alkaa lukemaan.
Generoija saattaa olla kyllä loppupeleissä väkevämpi, kuin koodaaja.
Tästä voi puhua enemmän niiden 50-luvun assembler-koodaajien kanssa, jotka
60-luvun FORTRAN-koodaajat selätti, jotka 70-luvun Pascal-koodaajat selätti,
jotka 80-luvun C-koodaajat selätti, jotka 90-luvun Java-koodaajat selätti,
jotka 2000-luvun generoijat selättää.
Kalermo sanoin sivalsi:
Se alkoi LinuxPPC:stä (mikä se on?)
Applen tietokoneissa nykyään käytetyn PowerPC-prosessorin päällä pyörivä
Linux-versio (jakelupaketti).
Jos kehittäjät yhdistäisivät tietämyksensä, saataisiin tehtyä parempia ohjelmistoja.
Näinhän se on.
Siellä "tiedettiin tarkkaan mitä haluttiin, mutta kukaan ei ollut innostunut kuvaamaan sitä jollekin ohjelmistotalolle". Tuli kuulema tunne että softa olisi lähes tehty siinä ajassa mikä menee vaatimusten määrittelyyn ohjelmistotaloa käytettäessä. Mielestäni tämä kuulosti kauhistuttavalta: kokevatko kaikki asiakkaat näin?
Prosessit ovat kuulema huonoja.
Nyt on kommunikaatiokatkos tapahtunut. Prosesseista en osaa sanoa, ovatko ne huonoja
vai eivät. Eri prosessit sopivat eri työstämisiin paremmin kuin toiset. Se, mitä
kritisoin, on tiettyyn prosessiin pakottaminen. On tietty olemassa tilainteita,
joissa prosessia tulee seurata tarkasti, vaan pelkään enemmän olevan olemassa
tilanteita, joissa prosessi vain häiritsee työtä. Mielummin määritellään tilat
(ei tila niikuin state, vaan tila niikuin space), joissa
tietoa saa muokata vapaasti, ja rajankäynnit näiden tilojen välille, jolloin tilojen
sisältämän tiedon tulee olla mielekästä. Viitettä pukkaa: A Better Mythology
for System Design (
http://www.pliant.org/Better-Mythology.pdf).
Koponen ylös kirjasi:
Rosenqvist toi esille mielenkiintoisen asian avoimesta ohjelmistokehityksestä: virtuaalinen velka.
Aiheesta voi lukea lisää tuolta aiemmassa Turpeisen Tuomaan
kirjoituksen kommentissa antamastani villi assosiaatio -linkistä.
Mitä kertoo opiskelutaustasta, jos on opiskellut yhden kurssin tähtitiedettä?
Rosenqvistin tapauksessa se taisi olla kurssillinen meteorologiaa.
Tämä vaatii varmaan harjaantuneisuutta, sillä minusta paperilta koodirivien katselu on suorastaan tuskallista :-\.
Laita paperit seinälle ja astu pari askelta taaksepäin. Auttaa kummasti, ja on
huomattavasti mukavampaa kuin katselu nykyisillä ohjelmilla.
Kulmala katsoi mainitakseen:
Tietotekniikan laitos tuottaa tietotekniikan osaajia, mutta missä on toimialakohtainen tietämys? Juuri tämän takia yritykset haluavat Jyväskylään tupsulakkien (DI) koulutusohjelman, sillä heidän koulutuksensa on monipuolisempi.
Tämäpä mielenkiintoinen väite, miten tupsulakit ovat monipuolisempia
koulutukseltaan? He lukevat tekniikkaa, tekniikkaa ja tekniikkaa, sekä hieman
taloutta. Meillä on alan lisäksi hieman taloutta tarjolla tai matematiikkaa,
sen lisäksi vapaa opinto-oikeus luonnontieteisiin, useisiin yhteiskuntatieteen
aloihin, sekä läjäpäin kieliä ja humanistisia aineita tarjolla. Tarjonnasta ei
täällä ainakaan ole pulaa.
Lappalainen lausahti:
Toisaalta seuraavalla luennolla Markku Rossi toi esille melko yleisen Watts S. Humphreyn lanseeraaman lausahduksen, joka väittää koodikatselmoinnin olevan jopa viisi kertaa tehokkaampaa kuin ohjelmoijatestaus.
Lieköhän Watts S. puhunut lainkaan ohjelmoijatestauksesta? Ajatusmalli on sen
verran uusi, että olisi hyvä varmistaa, olisiko tuo Humphreyn lausadus
liittynyt sittenkin perinteisempään testaukseen.
Tyypillisen asiakas- tai tuotetietokannan toteuttamiseen elegantti ratkaisu -
kunhan käyttäjät (ja myös koodaajat) saadaan omaksumaan uusi tapa toimia. Mutta
eiväthän kaikki sovellukset ole tuollaisia. Usein tiukka kontrolli ja suoraviivainen
prosessi on itsestäänselvyys.
Kysymys onkin, onko tuo uusi tapa toimia kenellekään muulle kuin hyvin
nykyohjelmistokehitysmalliin perehdytetylle ohjelmistokehittäjälle?
Eivätkä kaikki sovellukset ole tällaisia, joissakin on selkeä prosessi.
Joihinkin vain on määrätty liian kiinteä prosessi, joka ei sitten toimi.
Miettikääpä esimerkiksi, millaisen prosessin tekisitte terveyskeskuksen
laboratorion näytteiden käsittelyyn ja analyysin tulosten tallentamiseen.
Ehdottakaa sitten prosessia tuttavapiirin laboratorionhoitajalle. Varatkaa
keskustelun ajaksi paljon evästä :)
Jos taas teet laajempaa tietojärjestelmää tai kompleksista sovellusta
ylipäänsä, niin oliot (tai luokat, kummin vaan) auttavat jäsentämään
ongelmaa. Itse asiassa on hauskaa, että proseduraalista ohjelmointia kutsutaan
myös rakenteiseksi ohjelmoinniksi. Oman kokemukseni mukaan kun sillä syntyy
lähinnä spagettikoodia, josta rakenteen hahmottaminen on mahdotonta.
Rakenteisesta ohjelmoinnista ja spagettikoodista: Rakenteisesta ohjelmoinnista
alettiin puhua, kun kieliin tuli mukaan ehdollisia silmukkarakenteita ja
proseduuri-abstraktio. Sitä ennen ehdolliset silmukat oli tehty if- ja
goto-lauseilla, sekä proseduurit goto-lauseilla ja globaaleilla muuttujilla.
Onhan tuo nykyajan rakenteinen koodauskin joskus spagettimaista, mutta
katsokaapa vanhoja ohjelmia, joissa saa hyppiä mihin tahansa goto:lla tai jopa
laskennallisella goto:lla.
Tämä ei tietenkään ole suora seuraus. Ehkä ongelma on siinä, että suunnittelu
jää vähemmälle ja aletaan vaan koodaamaan. Kun taas päätetään
käytetään olioita, niin rakenteen suunnittelu tulee luonnostaan ongelma-alueen
palastelun muodossa.
"What is Software Design?"
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm
Moilanen bitein raapusti:
Akateemisissa piireissä on ikäänkuin muotia haukkua Microsoftin tuotteita,
käyttöjärjestelmiä jne. En ole oikein ikinä ymmärtänyt tätä, että vain periaatteen
vuoksi pitää haukkua jotakin.
Jahas, tämä microsoft-myytti. "Akateemisissa piireissä" ei ole muotia haukkua
Microsoftia, ei sen enempää kuin muuallakaan. Microsoftia haukutaan paljon
syyttä, tai vääristä syistä, mutten usko näiden haukkujien löytyvän
"akateemisista piireistä". Microsoft on tehnyt paljon hyvää, mutta moni heidän
tekemänsä asia ei ole niin hyvä. Varsinkaan ei ole hyvä asia, että he ovat
käytännössä monopoli, ja tuntuvat tiedostavan tämän seikan turhan
täydellisesti.
Luennoitsijoilta olikin hyvä pointti se, että Windows on krakkereiden suosiossa
pelkästään ylivoimaisen yleisyytensä vuoksi.
Tämä oli myös hyvä esimerkki siitä, kuinka tilastoja voi tulkita ihan miten
huvittaa. Jos Windows olisi alustana turvallinen, ei sitä haittaisi se, että
se on yleisin. Sitäpaitsi, eikö se olisi hyökkäysten kohteena, jos se olisi
ainoa järjestelmä? Voitte myös pohtia seuraavaa analogiaa: mitä tapahtuu
eläinlajille, jonka kaikki yksilöt ovat yhtä identtisiä kuin Microsoftin
markkinaosuus (jopa oli rinnastus!), kun se kohtaa ensimmäisen voimaisan
virus-peräisen epidemian?
Vai voisiko olla, että Microsoft Windows on suosittu hyökkäysten kohde, koska se on niin helppo kohde? Ei tarvitse enää olla edes osaava tekijä, kun voi verkosta ladata pienen etsimisen jälkeen kasapäin ohjelmia, jotka tekevät hyökkäykset puolestasi. Hakusana: script kiddies.
Sinänsä ihan tärkeä pointti, akateemisessa maailmassa ei usein anneta ajankohtaista
tietoa tämänkaltaisista asioista [tarkoittanee: yhden ohjelmistovalmistajan
ratkaisuista].
Miksiköhän ei? Vanha tarina: kun aloitin opinnot, opiskelin ohjelmointia
Pascalilla. Kun menin töihin, oli työkielenä C ja C++, ja osalle tämäkin jo
menneisyyden taakka Javan rinnalla.
Yliopiston tarkoitus ei ole valmistaa tämän päivän työkalujen osaajia, vaan ennemminkin huomisen työkalujen tekijöitä. Silti, olisi hyvä tuntea niitä tämän päivän työkalujakin. Meillä opetus pyrkiikin siihen, ettei uuden työkalun opiskelu enää ole ongelma. Selkeämmin sanottuna tämä löytyy Joni Niemelän päiväkirjasta.
Myllynen otti ja ihmetteli:
Luennolla keskusteltiin siitä, olisiko parempi tehdä nopeaa koodia vähemmän oliomaisesti vai hitaampaa koodia oikeasti olioita käyttäen.
Kysymys: onko toimintanopeus ainoa koodin laadukkuuden mittari?
Toinen kysymys: perustuuko toimintahitaus olioiden käyttöön vai huonoon
oliokielitoteutukseen?
Kiinnostaisi muuten tietää, kuinka suuri ero on tämänhetkisellä Korppiin
(esimerkiksi vuosittain) käytetyllä rahamäärällä ja Oodin lisenssi- ym.maksuilla.
Tämä kysymys on esitetty useassa päiväkirjassa, ja siihen olisi tietty kiva
kuulla vastaus. Tiedän Oodista tavattoman vähän, mutta tiedän, että sen
käyttöönotto maksaa paljon, käyttö maksaa paljon, ja mikä ikävintä, jos
haluamme sitä mukauttaa paremmin meille sopivaksi, tulee meidän tehdä ehdotus
Oodi-johtokunnalle (tai mikä lieneekään nimeltään), jossa sitten kaikki
osalliset pähkäilevät ja pohtivat, aletaanko muutosta tekemään, miten ja millä
aikataululla. Järjetöntä. No, ainakin päästäisiin maksamaan lisenssimaksuja
Oraclelle…
Ohjelman vaatimuksista ja etenkin koodaajastahan se riippuu, nikä kieli tulee
valituksi milloinkin.
Oih, kunpa riippuisikin. Valitettavan usein valinta tapahtuu aivan toisin
(olemattomin) perustein. Yleisempiä perusteita on muotikieli tai naapurifirman
kanssa kilpailu (Dilbert-stripistä: Haluatko tietokantasi vaaleanpunaisena vai
purppuraisena?).
Myllyperkiö sanoiksi puki:
Toinen asia mikä minua jäi mietityttämään luennolta, on tämä jatkuva
Korppi-järjestelmän kasvattaminen uusilla sovellusprojekteilla. Onko järkevää
kasvattaa jo ennestään hitaasti toimivaa järjestelmää uusilla huonosti
suunnitelluilla ja toteutetuilla komponenteilla, …
Kovin on heikko usko ihmisillä sovellusprojektien tuotosten tasoon. Mitähän
voisimme asialle tehdä? Miten Korppi toimii hitaasti? Mitäpä vastaisit heille,
jotka tarvitsevat uuden ominaisuuden Korppiin, mutta heiltä sen haluaisit kieltää?
Oletko valmis kasvattamaan Korppia hyvin suunnitellen ja toteuttaen tarvittavan
tai halutun uuden ominaisuuden?
Ja kun tuota Korpin olemassaolon oikeutta on kovasti pohdittu, niin muistutetaanpas taas, että Korppi tekee todella paljon muutakin kuin kerää ihmisten ilmoittautumisia tentteihin. Opiskelijat taitavat nähdä Korpista vain todella pienen vilauksen. Omilla kursseillani tuo ilmoittautuminen on ollut vain pieni osa, enemmän on ollut hyötyä kalentereista, postilistoista, kyselylomakkeista ja varsinkin arvostelulomakkeista.
Varsinkin ontologioiden selitys jäi mielestäni erittäin huonolle tasolle ja
pelkästään esityksestä ei olisi saanut tietoa irti mitä ontologia oikein
pohjimmiltaan tarkoittaa.
Määritelmiä on monia, eri aloilla omansa. Ehkäpä se, että luennolla esitettiin
useita erilaisia määritelmiä heikensi meidän alan määritelmän näkyvyyttä.
Mäkisen Aapo aprikoi:
Mielestäni Korppi-opintotietojärjestelmän kehitystyössä on nähtävissä hyvin moni
ohjelmistotekniikan perinteisistä ongelmista, jotka tiedostettiin vuoden 1969
NATO-konferensissa. On ironista että alan asiantuntijoita kouluttavassa laitoksessa
on meneillään prosessi, jossa on läsnä paljon alan klassisempia ja ilmeisempiä
ongelmia.
Mielestäni vielä ironisempaa on, että samaan törmää myös laitoksen
ulkopuolella, varsinkin ohjelmistoteollisuudessa, joka on luonut ne opit,
joita teille täällä jaamme.
Muuten, NATO-konferensseja oli kaksi, ensimmäinen vuonna 1968 ja toinen vuonna 1969. Ensimmäinen oli se enemmän sykähdyttävä, toinen se enemmän järkyttävä.
historiallisesti C:n ominaisuuksia on arveltu yhdeksi keskeisimmistä
tietoturva-aukkojen lähteeksi
ja myöhemmin:
Syynä tähän on virheherkkä C:n merkkijo. C:n merkkijonolle varattu liian pieni
tila on aiheuttanut monia puskurinylivuotohaavoittuvuuksia.
Syyttäisin tuossa mielummin ohjelmoijan kokemattomuutta kuin itse
ohjelmointikieltä. Mistä tuo ensimmäinen historiallinen arvelu on kotoisin?
Niemelä tarinan loi:
Oikeastaan tuntuu hölmöltä, kun olen elänyt telnet-aikaa ja lähettänyt viestejä
verkon ylitse tietäen, ettei salasana ollut kryptattu.
Noh-noh (taputtaa selkään). Kannattaa muistaa, että silloin telnet-aikaan
käyttäjiä oli vähemmän, ja he ymmärsivät enemmän, mitä olivat tekemässä. Moni
tiedosti vaarat ja vajaavuudet, mutta tiedosti myös sen, että jos he alkavat
ilkeilemään, saattaa pilkka, oman tai naapurin, osua pian omaan nilkkaan.
Nykyään asia on toisin. Tykkäsin aikoinaan sanoa, ettei Internet ollut vielä
valmis suurelle yleisölle. Eikä ole vieläkään. Mutta juna meni jo…
Miten laajoja järjestelmiä on voitu kehittää ilman testejä?
Vastaus lienee itsestään selvä. Suurissa järjestelmissä puhutaankin kriittisestä
massasta, jolloin bugin korjaaminen tuottaa kaksi uutta. Miksi näin käy? Koska
korjatessa rikotaan jotain, minkä ei tiedetä rikkoutuvan. Testeillä tällaisenkin
järjestelmän bugikorjaamisen saisi toimimaan. Esimerkkinä voisi mainita batmudin.
Tätä kysymystä sietäisi pohtia jokaisen.
Gang of three, Pitkänen Raimo, Savolainen Antti, Räisänen Jussi, kyseli:
Epäselväksi jäi se, mitä Rossi sanoi merkistöongelmista. Voisiko joku kertoa,
mistä oli kyse?
Itse olen huomannut ongelmaksi jo tiedostojen nimet, sisällöstä puhumattakaan.
Ääkköset ja muut oudot häkkyrät eivät vieläkään tunnu välittyvän oikein, ellei
molemmissa päissä piuhaa ole saman arkkitehtuurin samalla
käyttöjärjestelmäversiolla toimivat identtisesti konfiguroidut tietokoneet. Ja
elämme vuotta 2004…
Pöyhönen ihmetteli:
Jos taloushallintotyyppi voi oppia ohjelmoimaan, miksei ohjelmistokaveri voi oppia
perusteita taloushallinnosta ilman, että hänelle tarvitsee vääntää asioita
rautalangasta kuten vähä-älyiselle…
Epäilys omaa osaamista ja alan valintaa kohtaan. Onko meistä mihinkään? Miksi
teemme tätä, kun kuka tahansa voi hypätä puikkoihin ja tehdä itselleen parhaan
ratkaisun todella lyhyessä ajassa? Milloinkahan niitä siivouskursseja oikein
järjestetään ja missä?
Niinpä. Dilbert-sarjakuvan roskakuski on suuri idolini.
Saarela oivasti uteli:
Luennolla oli yksi kysymys mikä särähti korvaan: käsitelläänkö prosessimenetelmiä
kuten UP yliopistolla missään muualla kuin Ohjelmistotuotannon kurssilla?
Ainakin kahdella muulla, JOT ja jossain määrin se Tietojärjestelmien
olioperustainen suunnittelu (tjsp. jonka nimeä en näemmä ikinä jaksa varmistaa
ja opetella).
Tietäväinen kommentoi:
Toisaalta olen yhtä mieltä opetuksen yleistettävyyttä
ajavien opettajien kanssa, toisaalta pelkään tulevaisuuden
työmarkkinaseksikkyyteni puolesta. Itseopiskelu olisi tietysti
vaihtoehto, mutta siinä on aina omat riskinsä.
Kannattaa rohkeasti aloittaa itseopiskelun opiskelu jo nyt, sillä ei teille
kukaan tule työelämässä oppia päähän kaatamaan. Kursseilla on yleensä kyllä
hyvät ruoat, mutta…
Tuomainen tarinoi:
Hieman oudolta kuulosti myös se, miten myöhäisessä vaiheessa ohjelmistokehityksen
perustyökaluja on otettu käyttöön.
Työkaluja ei valitettavasti osata ottaa käyttöön, ennenkuin niille nähdään
selkeä tarve ensimmäisen kerran.
Mikäli tämä ei tunnu hyvältä, kannattanee valita jokin heikosti tyypitetty kieli.
Mielummin ehkä myöhäisen sidonnan kieli, ainakin välivaiheena. Heikosti
tyypitetyt kielet vaativat todella vahvaa mieltä :)
"Palataan asiaan myöhemmin." Ei palattu.
Palattiin, mutta se tapahtui siellä luennon jatkoilla. Lyhyesti, kapselointi
ja tiedon piilottaminen menevät usein käsitteinä sekaisin. Kapseloitaessa
yhdistetään tieto ja toiminta. Tieto voidaan sitten piilottaa näkyvistä ja
käytettävistä vaikkapa noiden toiminteiden taakse. Termit muodostavat hyvän
alustan väittelyille, mutta esittämäni näkemys on ainoa oikea totuus. Lisään
kuitenkin johonkin vielä Parnasin perin mielenkiintoisen
kommentin, joka koskettaa hieman tätäkin aihetta.
Tuovinen tiivisti:
Rosenqvist puhui kaksi tuntia asiasta, joka mielestäni voisi tiivistää sanoihin
vapaa lähdekoodi ja ketterät menetelmät.
Kiitos, hyvin tiivistetty.
Yleensäkin generoituun koodiin luottaminen on vähintäänkin kyseenalaista.
Silti kaikki kääntävät ohjelmansa konekieleksi, mutteivät itse kirjoita
ohjelmia konekielellä. Juuh, tätä tulikin jo kommentoitua.
Turpeinen kyseenalaisti:
Alkuperäiseen kysymykseen. Olikohan siis tästä tietotekniikan koulutuksesta mitään hyötyä. Kuvitellaan tilannetta, jossa toimitusjohtaja soittaa softan kehittäjille "haluan että huomiseen mennessä tulostuksissa kaikki perjantaipäivät merkitään lihavoidulla ja vihreällä". Tuleekohan seuraava loppupäivä ja yö vietettyä koneen ääressä korjaten niitä tuhatta tiedostoa, joissa tulostetaan viikonpäiviä vai tehtyä vartissa muutos siihen yhteen moduuliin, joka hoitaa viikonpäivien tulostuksen. (Okei, fiktiivinen esimerkki…)
Jälleen hieno kysymys, pohtikaapas!
Esityksestä ei selvinnyt erityisen tarkasti, miten SSH:lla hoidetaan sovellusten suunnittelu. … Eli heidän koodinsa ei ole ainakaan erityisen yksityiskohtaisesti mietittyä.
Kuinka pitkälle suunnittelua pitää jatkaa? Riittääkö luetella metodit? Vai
pitääkö piirtää sekvenssi- ja tilakaaviot, kuinka yksityiskohtaiset? Missä
vaiheessa suunnittelu muuttuu ohjelmoinniksi? Minun näkemys näistä asioista on
sama kuin artikkelissa "What is Software Design?"
http://www.bleading-edge.com/Publications/C++Journal/Cpjour2.htm (sama
artikkeli, johon on viittattu aiemmin kohdassa
iter, iter, …).
SSH:n yhteydessä suunnitelmien puutteesta kärsivien kannattaa tutustua IETF:n spesifikaatioihin, joiden mukaan noita SSH:n ohjelmiakin kirjoitetaan. Kaipaatteko vielä lisää suunnittelua? ;) No, jättäväthän nuo mm. käyttöliittymän kokonaan määrittelemättä, mutta toiminnallisuus on aika vahvasti speksattu.
Toinen asia mitä ihmettelin oli se, että itse tietokannan ja sen hajauttamisen kanssa on ongelmia. Tästä tuli mieleen,
että eikö yliopistolla tutkita tietokantoja ja niiden hajauttamista yms. muuta toimintaa? Käsittääkseni Informaatioteknologian
tiedekunnassa on asiantuntijoita tällä alueella. Miksi heitä ei oteta mukaan ja pyritä tekemään opiskelijavoimin pro graduja
aiheesta silmälläpitäen Korppia ja sen ongelmia?
Korpin tietokantaa ja hajauttamista on gradussakin käsitelty, ja se gradu
tullee ihan kohta ulos. Mitä tulee tuohon yhteistyöehdotukseen
IT-tiedekunnassa, noh, toivon, että joku yläkerrasta lukee tämänkin kommentin.
Lisäksi Korpin kehittäjät eivät ole vapaaehtoisia.
Kyllä he ovat, ei ole tarvinnut ketään pakottaa kehittämään Korppia, ja
kehittämisen on saanut lopettaakin. :)
Onko Arwidsonin lähdekoodi lopulta vapaata? Tuskin kaikkea näytetään julkisesti ihmisille.
Arwidsonin/Pupesoftin lähdekoodin vapauden voi jokainen käydä itse tarkistamassa
osoitteesta http://www.pupesoft.fi/softa/
Mielestäni luennon sisältö ei tehnyt täysin oikeutta luennon otsikolle, "Tietoturvaohjelmistojen toteutus".
Otsikon piti kyllä olla jotain tyyliin "tietoturvaohjelmistojen
tietoturvallinen ohjelmointi", ei tyyliin "tietoturvan ohjelmointi".
Miten SSH-tyypit ohjelmoivat C:llä, joka on täynnä tietoturva-aukkoja.
C ei ole täynnä tietoturva-aukkoja. C:llä ohjelmoijan tulee vain
huomioida paljon sellaisia asioita, jotka Java-ohjelmoija voi unohtaa. Tästä
helpotuksesta Java-ohjelmoija sitten maksaa koodin hitautena joissain
tapauksissa, ja pitkästä matkasta koodista laitteistoon useissa
tapauksissa.
Ja vielä se, että yliopisto täyttäisi koko opiskeluviikon
aamusta iltaan luennoilla, jolloin työssäkäyvilläkin olisi mahdollisuus opiskella
tehokkaasti vaarantamatta työskentelyään sekä
itse työelämässä että yliopistolla.
Yliopisto järjestää opetusta opiskelijoitaan varten. Yliopiston opiskelijoiden
päätyö on opiskelu. Ansiotyön tekeminen opiskeluaikana ei ole kiellettyä, ja
se jopa avartaa maailmankatsomusta mukavasti. Kuitenkin, jos ansiotyö alkaa
häiritsemään opiskelua, kannattaa pysähtyä ja katsoa peiliin. On myös
oppilaitoksia, joista voi nopeasti parissa vuodessa valmistua ansiotyöhön.
Yleensä myös luennoilla ja demoissa istuminen ei riitä kurssin suorittamiseen, vaan näiden lisäksi on opiskeltava ja harjoiteltava kurssin asioita itsenäisesti. Tätä varten on myös tapana jättää aikaa opiskeluviikkoon. Puhumattaaan sivuaineiden kaipaamasta ajasta.
Kaupallisten ohjelmistojen eduksi voitaneenkin nähdä, että niitä on kehitetty pitempään.
Jaa, onkohan? Ok, MS-DOS on ollut olemassa 80-luvun alkupuolelta, UNIXeja on kehitetty
70-luvulta asti, jopa ei-kaupallisesti. Koskas Emacsin kehitys aloitettiin?
Vai pitäisikö tuohon laskea mukaan se Lisp-koneiden editori, josta Emacs on saanut
vaikutteensa, silloin saattaisi kyllä tuo kaupallisuus-vaade täyttyä.
Kaupallista ohjelmisto käytettäessä vastuu ainakin osittain siirtyy sovelluksen
kehittäjäle.
Lukekaapas joskus niitä kaupallisten ohjelmien lisenssipapereita. Kenen on
vastuu?
Molemmat edeltävät kommentit kyllä kilpistyvät kaupallisen ohjelman määritelmään. Onko kaupallinen ohjelma kuten kaupasta ostettu peli tai reseptikirjanpito-ohjelma, vai onko se kuten ydinvoimalan ohjausjärjestelmä?
Itselle tulee sellainen olo tätä kirjoitaessani, että sitä oppii sitä mitä haluaa oppia. Kun on luonut oman kantansa, hakee sitä vahvistavia asioita ja jättää huomioimatta päin vastaisen asiat. Kuinka siinä voisi olla puolueeton?
Siinäpä jälleen hyvää pohdittavaa.
Yeah right, keskiverto korkeakouluopiskelija oppinee uudet työkalut suhteellisen kivuttomasti, elleivät ne ole aivan susia.
Kiitos! :-)
Kurssin tarkoituksena, nimestään huolimatta, oli tutustuttaa opiskelijat siihen mikä heitä tulevaisuudessa odottaa. En voi väittää ohjelmaa täysin suunnitelluksi, mutta sitäkin onnistuneemmaksi, ainakin jos kattavuutta mitataan. Ensimmäisenä oli kotoinen vaihtoehto, joka akateemisesta syntysijastaan huolimatta tuntuu päivä päivältä enemmän oikealta ohjelmistokehitykseltä. Ja se on hienoa, meillä on siten talon sisällä oikea ohjelmistotuote opeteltavaksi, tutkittavaksi ja käytettäväksi.
Saimme nauttia ohjelmistokehityksestä, joka ei ollut tekijäyrityksensä rahansaannin kohde, vaan rahansaannin apuväline. Ja ryökäleet jakavat vielä softaansa ilmaiseksi ja ovat siitä ylpeitä. Syystäkin. Ei siitä norsunluutorinitutkijoiden henkisen tarpeen täyttävän elvistelenpä-miljoonilla-…äh… Kaikilla on oikeus ohjelmointiin, vaikka ohjelmistopatenttienpuolustajapellet mitä tahansa yrittää.
Tietoturvaa, eli ohjelmointia tarkasti ja vahvasti määritellysti, muistaen varmentaa kaiken ja siivota vielä jälkensäkin. Ohjelmointi on vielä hyvin rautaläheistä, ja resurssitkin niukat…
Sitten, yritys, joka auttaa toisia tietojärjestelmänsä eri osien yhteiskäytön rakentamisessa. Paljon ohjelmia, paljon rajapintoja, pajon yhdistettävää, paljon tekemistä. Esiiintyjä töissä asiantuntijana.
Agenttiohjelmointi, ontologiat; varsin erilainen tapa ratkaista tietojenkäsittelyn ongelmia, kuin mitä aiemmat esiintyjät ovat esitelleet. Varsin erilainen myös esiintyjä, tieteen mies teollisuudessa tutkimassa.
Viimeisenä se lähes ainoa lajissaan, tai ainakin suurin. Montako vastaavaa ohjelmistotuottajaa kuin Microsoft osaatte luetella maailmasta?
Varsin kattava läpileikkaus alasta siis, mitä jäi puuttumaan? Ehdotuslistalla oli myös tietoturva-aukkojen etsijöitä, känny- ja tekstiviestipelien tekijöitä, sekä XML määrittelijöitä. Ehkä ensikerralla. Oikeita pelifirmoja olisi varsin mukava saada mukaan, mutta onhan tuo Agora Gamelab pelifirmojen edustajia yliopistolla käyttänyt.
Eli, osallistujat oppivat, miten ohjelmistoja suunnitellaan, ja millä työkaluilla, siellä oikeassa elämässä. Osallistujien tehtäväksi jäikin sitten ymmärtää ja yhdistää saamansa tiedot. Oppimispäiväkirja on tämän prosessin arviointiin mitä mainion työväline (siinä muuten teille yksi ohjelmistojen suunnittelutyöväline lisää).
Demot, noh, demot olikin sitten toinen juttu. Aiemmin mietin, että olisimme demoissa käyneet syvemmälle Eclipsen syövereihin tutustuen sen laajennosten tekoon, mutta oma opiskeluaika loppui kesken. Sitäpaitsi toinenkin hyvä kokeiluidea muhi takaraivossa - Naked Objects.
Tutustuin Naked Objectsiin Oslossa Ecoopissa kesällä 2004. Siellä sitä esitteli muiden muassa herra MVC, se alkuperäinen MVC eikä tämä nykyajan hapatusmukamvc. Kaunistahan tuo NO on. Oliot hoitavat itse vastuunsa, kuten pitääkin. Oliot näyttävät siltä kuin ovat, ja niitä käytetään, niiden kanssa kommunikoidaan kuten ne näyttävät. Ei outoja menuseikkailuja, ei käsittämättömiä graafisia taidepläjäyksiä. Olio näyttää julkisen naamansa ja toiminnot vaativat toimintaa myös käyttäjältä. Kirjoitan tätä muuten Nääsvillen Oliopäivien ensimmäisen päivän iltana hotellissa . Huomenna on hypesanapaneeli, ja minä en ollut hän joka ehdotti Naked Objectsia tuonne. Minä ehdotin monadeja :-) Toivottavasti menee läpi, kaikki kolme.)
Niin, hyvin nuo demot mielestäni onnistuivat, vaikka välissä meinasi väsymys iskeä ja innostus laantua. Pieni tutoriaali alkujärkytyksen jälkeen olisi varmaan ollut paikallaan. Ja yllättävän hyvin tuo NO tuntui taipuvan, saatikka osallistujat tuohon kehitysrymäytykseen. Oikeasti ihailin sitä, kuinka he jakaantuivat ryhmiin kuin itsestään, valitsivat työstön kohteet ja toimivat yhdessä. Se, mitä jäin kyllä ihmettelemään, oli kommunikoinnin puute. Herpakköntsö sentään, mitä me olemme opiskelijoille opettaneet, kun he eivät jaa tietoa keskenään, eivät tee yhteistyötä, eivät jaa koodia, eivät lue toisten koodia? Miksette? Miksi ette?
Noh, tulosta syntyi, ja seuraava kokeilu on sitten vuorossa ohjelmistoarkkitehtuurin kurssilla. Kiitos kaikille demoihin osallistuneille, teidän kanssa oli hienoa tehdä tutkimusmatka ketterien kehitysmallien ja alastomien olioiden maailmaan.
Ja kiitos kaikille kurssille osallistuneille. Olitte aktiivinen ja hyvä yleisö vieraileville luennoitsijoille. Tämän kuulin heidän monesti sanovan. Ettekä päästäneet heitä helpolla, mikä on hyvä, sillä se osoittaa, että teillä on tallella tervettä kriittisyyttä sopivissa määrin.
Yleisesti, kaipa se oma näkemys saa taas tulla esille, taustalla jyllää aika voimakkaana nuo ketterät menetelmät. Kehotan taas kaikkia tutustumaan ketterien menetelmien tausta-ajatuksiin osoitteessa http://www.agilemanifesto.org/.
Oikeastaan luentojen osalta opin aika vähän uutta, mikä ei liene ihme. Korpin tekemisen kommervenkkejä, Pupesoftin ajatusmaailmaa ja Microsoftin uutuuksia lukuunottamatta asiat olivat (syystäkin) tuttuja. Joosen integrointiongelman suuruutta kyllä vähän hämmästelin, kun oletin tilanteen olevan paljon ruusuisemman. Niin se potkii maailma takaisin. Antoisaa oli myös käydä keskusteluja luennoitsijoiden kanssa luentojen ulkopuolella, mutta näistä te ette valitettavasti päässeet osallisiksi.
Demoista sain paljon oppia, lähinnä siitä, miten ei pidä demoja järjestää. En kuitenkaan tarkoita tällä sitä, että demot olisivat epäonnistuneet mielestäni, päinvastoin! Demot onnistuivat oikein hienosti, mutta olisivat voineet olla vielä paremmatkin. Hieman enemmän ohjeistusta ja hieman enemmän sitä ruoskaa on luvassa ensikerralla. Meinaan myös unohtaa, ettei kaikki minulle selkeät käsitteet ole aina selkeitä muille. (Koettakaa opettaa täysin tietokonetta käyttämättömälle ihmiselle tietokoneen käyttöä.)
Opintopäiväkirja oli onnistunut valinta kurssin suoritustavaksi. Olisin tietty voinut paljon paremmin ohjeistaa asioita. Pelkään, että taas on päässyt valloilleen tuo oppi siitä, ettei toisten töitä saa katsoa. Toisten töitä ei saa kopioida ja plagioida, se on yksinkertaisesti tyhmää. Toisten töitä saa kuitenkin lukea, ja niistä saa oppia. Niitä saa kommentoida, jopa kritisoida ja arvostaa.
Eli seuraavalle kerralle: demo- ja opintopäiväkirjaohjeistusta lisää, kenties jopa DTD tai vastaava pakolliseksi [lisää tähän ilkeänviekas hymy].
Opiksi voitaneen myös sanoa seuraavan kappaleen sisältöä, johon en ehkä ilman tätä kurssia olisi törmännyt.
Törmäsin kurssin aikana paneelikeskusteluun, joka oli pidetty 25. kansainvälisessä ohjelmistotekniikan konferensissa Portlandissa Oregonissa vuonna 2003. Paneelin aiheena oli modulaarisuus nykyään (Modularity in the New Millenium). Yhteenveto paneelista löytyy osoitteesta http://portal.acm.org/citation.cfm?id=776923&jmp=references&dl=portal&dl=ACM.
Paneelissa David L. Parnas sanoi seuraavasti, lainaus edellämainitusta yhteenvedosta:
To a man with a hammer, everything looks like a nail. To a Computer Scientist, everything looks like a language design problem. Languages and compilers are, in their opinion, the only way to drive an idea into practice.
My early work clearly treated modularisation as a design issue, not a language issue. A module was a work assignment, not a subroutine or other language element. Although some tools could make the job easier, no special tools were needed to use the principal, just discipline and skill.
When language designers caught on to the idea, they assumed that modules had to be subroutines, or collections of subroutines, and introduced unreasonable restrictions on the design. They also spread the false impression that the important thing was to learn the language; in truth, the important thing is to learn how to design and document.
We are still trying to undo the damage caused by the early treatment of modularity as a language issue and, sadly, we still try to do it by inventing languages and tools.
Olen olettanut Parnasin aiempien tuotosten kuvaavan siirtymistä oliomaiseen ohjelmointitapaan. Nyt tämä hänen kommenttinsa saa kyseiset tuotoksen aivan uuteen valoon. Hieman kyllä hermostuttaa, kun uudet ideat, mitä muutos synnyttää, pyörivät silti työkalujen ja ohjelmointikielten ominaisuuksien ympärillä. Kuinka heittää vasaran kädestään? Kuinka riisua oliolasit? Kuinka ymmärtää, mitä ja miten ohjelmoida? Miten opettaa muille, kuinka ohjelmoida? Yksi ympyrä taisi taas sulkeutua.
Dijkstran suosikkilausumani lisään kyllä tänne loppuun!
… What is actually happening, I am afraid, is that we all tell each other and ourselves that software engineering techniques should be improved considerably, because there is a crisis. But there are a few boundary conditions which apparently have to be satisfied. I will list them for you:
Now under these five immutable boundary conditions, we have to try to improve matters. This is utterly ridiculous. Thank you.
(Applause).
Lähde E. Dijkstra, Conference of Software Engineering, 1969, sivu 10. http://homepages.cs.ncl.ac.uk/brian.randell/NATO/nato1969.PDF