Väärä ketteryys ja oikea ketteryys

No niin, tämä teema on kypsynyt jo hetken aikaa mietintämyssyn alla, on tehnyt mieli kirjoittaa omia ajatuksiani tästä. Osittain kypsyttelyyn on vaikuttanut se, että olen työstänyt kollegan kanssa Agile Engineering Practises koulutusta osana Certified Scrum Developer koulutusta, jossa pyritään parantamaan valmiuksia tehdä sitä oikeaa Scrummia, käytännön tasolla ongelmia ratkaisten siis. Powerpoint kalvojen sijaan tällä kurssilla tuotetaan ja testataan jatkuvasti sitä toimivaa softaa siis, sikäli ei riitä että osaa puhua, vaan tässä pitää osata soveltaa.

Olen törmännyt asiakkaiden kanssa yllättävän usein siihen että ollaan olevinaan ketteriä, tai ollaan tekevinään Scrummia tai Leaniä, ja kuitenkin ollaan katkeria menetelmää kohtaan ja koetaan että se ei toimi. Tässä ei toki ole vielä ihmeellistä, ei kaikki toimi kaikille, mutta kun olen udellut lisää syitä tyytymättömyyteen, paljastuu pian etteivät he usein ole tehneet tosiasiassa mitään ketterää ollenkaan, vaikka sertifikaatit on taskussa ja johdon siunaus. Ei ihme että on tyytymättömyyttä kun odotukset ja tulokset eivät kohtaa. Joten mietitäänpä paria oikean ja väärän agilen tunnusmerkkiä.

1. Manuaali kädessä

Ensimmäinen mieleentuleva tunnusmerkki väärästä ketteryydestä on lähteä toteuttamaan sitä manuaali toisessa kädessä otsa rypyssä. Tai vaikka tämä artikkeli käteen printattuna. Tämähän on ketteryyden irvikuva ja paradoksi. Ketteryyden ydin on sopeutua ja kehittyä, ei toistaa vanhaa. Oikea ketteryys ei lähde vanhan toistamisesta (tosin se voi olla tarpeen opiskeluvaiheessa), vaan jatkuvasta kehittymisestä ja eteenpäin menosta, ja sopeutumisesta. Tässä piilee toki yksi sudenkuoppa: monet agile menetelmät ovat jopa vaarallisia jos valikoi vain piirteen sieltä toisen täältä, koska piirteet tukevat toisiaan. Mutta on silti väärä lähtökohta pyrkiä toteuttamaan niitä fanaattisesti ja itseisarvoisesti sokkona toistellen – ei ole sellaista kuin täydellinen menetelmä, kehittymisen varaa on aina.

Oikea ketteryys? Se lähtee siitä että myönnetään että ihmiset voivat tehdä virheitä, etenkin alueille jotka ovat entuudestaan vieraita, tuntemattomia. Rakennetaan sisään itsetarkistelu ja jatkuva kehittyminen niin että se on yhtä arkipäiväistä kuin hengittäminen. On ok tehdä virhe, on väärin toistaa sitä. Tehdään jatkossa aina paremmin, tehokkaammin, fiksummin. Projektimenetelmän nimellä ei ole väliä. Onko se Scrum, Lean, Kanban, vai jotain mitä tulee tulevaisuudessa, se ei merkitse. Se mikä merkitsee on sisäänrakennettu kyky toipua ja kehittyä.

2. Scrummerfall

Suurin murhe ketterillä tiimeillä on perinteinen Scrummerfall – aloitetaan jäykästä vesiputousmallisesta projektista jossa on tiukka budjetti ja deadline, ja tiukka lista ominaisuuksia joista ei voi tinkiä. Tehdään raskas upfront määrittely – suunnittelu – ja paljon handoffeja ja tarpeetonta dokumentaatiota – ja sitten toteutusvaiheessa sanotaan: ok, aloittakaa Scrum. Siinä ei paljon sopeuduta, iteroida, priorisoida, eikä olla ketteriä. Näissäkin oloissa voi saada aikaan jotain, mutta lähtökohtaisesti ketteryyden hyödyt on jo menetetty ennen kuin peli on edes käynnistynyt. Ongelmana on että ketteryyden ostaminen vaatii näkemystä ja osaamista myös, ja vasta viime vuosina on esim. Product Owner koulutuksista tullut kovia hittejä. Lisäongelmana on ketteryyden kilpailuttaminen – mitä muuta siinä voi käyttää kriteerinä kuin referenssejä ja uskottavuutta? Tai tuntihintaa? 😉

Oikea ketteryys? Se lähtee osaavasta product ownerista jolla on selvillä tarpeet, ja kyky tai tuki priorisoida ne siten että aloitetaan tärkeistä ja edetään kohden vähemmän tärkeitä. Jos tarpeet ovat liian suuria on aika paloitella ja priorisoida lisää. Jos tuntuu että kaikki tarpeet ovat ykkösprioriteetin tärkeitä niin varmaan on syytä joustaa aikataulussa ja budjetissa sitten sen mukaan, ja puhua vaiheista – eikä big bang päivityksistä. Oikea ketteryys priorisoi ja tuottaa jatkuvasti demonstroitavaa liiketoiminnallista arvoa. Näin pidetään ostajat tyytyväisenä ja sitoutuneena ja päädytään siihen vähemmistöön it-projekteja jotka onnistuvat.

Vesiputousmallista tulikin mieleen: Katsokaapa wikipediasta anti-patterns artikkeli, ja katsokaa mitä waterfall projektimallista sanotaan 😉

3. Jätetään suunnittelu ja dokumentointi pois, mutta ei myöskään testata tai toimiteta

Ok, nämä ovat aika ilmeisiä heikkouksia. Otetaanpa vaarallisempia mukaan. Yksi helmasynti on mennä käsikirjan mukaan pitämään pystypalaverit aamuisin, iteroimaan vähän, ja keventää suunnittelua ja dokumentointia, kerätä kivoja velocity raportteja, ja kuvitella tekevänsä Scrummia. Kaikki nämä ovat hyvästä, mutta mikään niistä ei oikeastaan ole sellaista mitä ei voisi vesiputouksessakin tehdä, ja mikään näistä ei ole ohjelmiston tilaajan kannalta olennaista. Näitä usein tehdään koska ne on helppoa ottaa käyttöön, niihin ei liity muutosvastarintaa paljoakaan, ja eivät vaadi teknistä osaamista juurikaan. Kun hyödyt ja kustannukset laitetaan puntariin, molemmat ovat vähäisiä. Ei se Scrummia ole.

Oikea ketteryys hyökkää vaikeampien asioiden kimppuun, tässä pari oikean ketteryyden tunnusmerkkiä: Projekti toimittaa joka Sprintin aikana loppuun asti tehtyä, demonstroitavaa toiminnallisuutta jolla mennään eteenpäin. Näin säilytetään sitoutuminen, usko, visio ja mielenkiinto. Sovelluskoodi on kauttaaltaan testattua, ja testejä voidaan ajaa milloin vain, toistuvasti, koko ajan. Testikattavuutta ja testiraporttien historiaa voidaan helposti seurata. Testaus kattaa yksikkötestausta, integraatiotestausta, hyväksyntätestausta, ja suorituskyky-, kuorma-, ja toipumistestausta. Testit toimivat koodin dokumentaationa suurelta osin. Miksi näin ei tehdä? Tämä vaatii osaamista, ohjelmistoja, ja harjoittelemista ja soveltamista. Se on investointi. Investointi antaa takaisin varmuutta ja rohkeutta tehdä muutoksia ja korjauksia. Ääripäässä käytetään TDD menetelmää, joka ei ole enää testausta vaan suunnittelua, se ei siis ole testaajan osaamista vaan jokaisen tiimin sovelluskehittäjän. TDD on niin hieno ja monelle myös vaarallinen juttu että se taitaa ansaita joskus ihan oman artikkelin.

Kuulin muuten jenkkiprojektista jossa oli neljä sprinttiä vedetty läpi ilman että oli kertaakaan pystytty toimittamaan ulospäin yhtään mitään. Tässä kannattaisi ehkä vetää hätäkahvasta ja pistää homma seis ja tiimi opiskelemaan lisää. Ketteryys ei ole tekosyy osaamattomuudelle vaan se oikeastaan vaatii osaamista ja itseohjautumista. Se ei myöskään sovi kaikille.

Scrum ja kumppanit ei ole maaginen ratkaisu kaikkiin sovelluskehityksen kiputiloihin. Jos mitään, ne ovat välineitä joilla kivut pyritään nostamaan esille jotta ne voidaan ratkaista ja kehittyä.

4.Cowboy coding

Edelleen yksi kipeimpiä väärinymmärrettyjä ketteryysteemoja on sekoittaa ketteryys cowboy koodaukseen. Olen törmännyt joskus tilanteeseen missä tiimi iloisesti hyväksyy että dokumentointia vähennetään ja keskitetään, suunnittelua ei tehdä raskaasti etukäteen vaan matkan varrella, mutta on jätetty esim. testaus pois tai hunningolle tai projektityön jälkeiseksi ei-kuulu-meille asioiksi. Sitten alkaa cowboy koodaus: Tehdään suttuista spagettikoodia juuri tarpeeksi että saadaan ns ’happy scenario’ manuaalisesti testatuksi läpi, miettimättä virhetilanteita, uudelleenkäytettävyyttä, ylläpidettävyyttä, arkkitehtuuria, jne. Ketteryys ei ole tekosyy unohtaa näitä asioita, se vaatii osaamista pohjalleen. Muuten meillä on tiimi tuuliajolla ulapalla vailla suuntaa tai taitoja. Siitä ei ketteryydenkään nimessä hevillä selvitä.

Eli oikea ketteryys rakentuu kohtuulliselle osaamiselle ja riittävälle arkkitehtuurille. Itse suosin kovasti Architectural Spike termiä jossa tehdään kevyt arkkitehtuuri alussa jonka uskotaan riittävän projektin vaatimuksiin. Mieluiten pieni POC tueksi poistamaan tekniset riskit jos arkkitehtuuri on kovin uusi. Sen jälkeen astuu peliin Emergent Architecture jossa voidaan muuttaa arkkitehtuuria tarpeen mukaan. Käyttäisin tässä itse esimerkkinä Eiffel-tornin rakentamista ketterästi. Voi kokeilla rakentaa vastaavaa kapistusta metri kerrallaan ketterästi, oppien matkalla virheistä ja tehden aina paremmin, mutta mahtaako siitä tulla mitään? Olisiko sittenkin parempi alunperin karkeasti arvioida tornin korkeus, rakennusmateriaalit, tehdä pari lujuuslaskelmaa? Vai sopiiko ketteryys ollenkaan jos projektin muuttujat ovat jo tiedossa ja kokemusta on? Kuitenkin, spike vaihe ei pitäisi olla liian raskas, tai liian pitkä, muuten riskeerataan jatkuva toiminnallisuuden toimitus ja sitä myöden sitoutuminen.

Pelkkä emergent design ei mielestäni riitä, vaan alkuarkkitehtuurin tulee olla riittävä että sillä voidaan edetä jonkin matkaa ja että se ei välittömästi mene uusiksi. Muuten haaskataan taas aikaa ja energiaa. Good enough siis.

5. Tuuliajolla muuttuvien vaatimusten kanssa

Vielä yksi väärän ketteryyden tunnusmerkki joka tulee mieleen on product ownerin kykenemättömyys sitoutua mihinkään suuntaan. Ideana olisi kuitenkin edetä kohden visiota, vaikka yksityiskohdat voivat muuttua. Jos hankkeella ei ole visiota tai matkan varrella se muuttuu rajusti, tulee aika kallis hanke jonka tyytyväisyys ei ehkä ole huippuluokkaa. Tämä vaatii ammattitaitoa ostajalta, product ownerilta, mutta tarpeen vaatiessa myös Scrum masterilta. Vastuu onnistumisesta on yhteinen, ja jos muutos itsessään muodostuukin riskiksi, sitä pitäisi hallita iteraatioissa.

Eli pähkinänkuoressa:  Väärän ketteryyden tunnusmerkkejä ovat:

– hallitsematon muutos

– vajavainen tai puutteellinen testaus

– puutteellinen arkkitehtuuri

– puutteellinen visio

– kyvyttömyys sitoutua ketteryyteen työtapana

Tässä oli omia näkemyksiä siihen miten niitä voisi korjailla, mutta meikäläisen näkemykset eivät ole tärkeitä. Se mikä on tärkeää on oma halu kehittyä ja olla taitavampi joka päivä.

Ja tässä piti tietysti puffata tätä uutta kurssia, mutta enpä puffaisi sitä ellen uskoisi että se on hyödyllinen 😉  Sitäpä ei enää tälle vuodelle ehtinyt toteuttaa, mutta ensi vuosi on uusi vuosi ja uudet kujeet.

http://www.tieturi.fi/kurssit/kurssi.html?course=83904030&category=Ketteryys%2B%2528Agile%2529&city=Helsinki&training=21.03.2012

Ja tietysti muita ketteriä koulutuksia:

http://www.tieturi.fi/kurssit/koulutus.html?&category=Ketteryys+%28Agile%29

 

Tiedätkö jotain muita ketteryyden sudenkuoppia? Aihe on kiinnostava ja siinä on kehittymisen varaa. Blogihan on siitä kiva että sitä voi helposti kommentoida.

Mainokset

Oracle Certified Master, Java EE 5 Enterprise Architect läpi

Jep, aikamoinen nimeys. Tuohan tunnettiin aiemmin lyhenteellä SCEA. Nyt esim. OCEA epävirallisesti, ja versiota 6 saati sitten 7 ei ole vielä saatu aikaiseksi, joten tein tuon version 5 nyt. Serttihän muuttui juuri niin, että nyt se vaatii virallisia Oracle kursseja käydyksi, eli ehdin niukin naukin suorittaa sen vielä käymättä itse kouluttautumassa (asioita jotka jo tiedän ja joita koulutan) 😉

Kyseessä on aika rankka sertti, jossa mitataan kykyä suunnitella uskottava arkkitehtuuri annetun määrittelyn perusteella. Harjoitus ladataan verkosta, sitten toteutetaan oma dokumentaatio, joka muodostuu määrätyistä UML kaavioista ja sanallisesta dokumentaatiosta, esim. riski ja mitigaatiolista, oletukset, jne. Rankka on usein samalla hauska ja palkitseva, ja niin tässäkin tapauksessa.

Ajattelin kirjailla pari vinkkiä niille jotka kenties vielä tekevät näitä tulevaisuudessa. Paljonhan on taas netissä jo tarjolla. Oma tehtäväni oli sähkö ja vesilaitoksen järjestelmä (Utilities), ja kuten etukäteen arvasin, määrittelyssä oli (tahallisia) ristiriitoja ja virheellisyyksiä ja puutteita, jotka arkkitehdin tulee lukea rivien välistä ja tulkita halutulla tapaa, ja mikä tärkeintä, dokumentoida oletukset ja riskit.

Pientä haastetta toi uuden alustan piirteet. Toisaalta en uskaltanut käytellä liiaksi Java EE 6 piirteitä joita aidosti olen käyttänyt jo pitkään, koska sertti koski version 5 piirteitä, ja eroja on aikalailla (JSF 2, CDI, JPA 2.. 😉 – toisaalta kaikki vanhat suunnittelumallit ja arkkitehtuurit joihin aiemmin vedottiin sai heittää romukoppaan joska J2EE design patterns kirja on kirjoitettu joskus 1998, ja parhaatkin pattern opukset ovat kymmenen vuoden takaa vähintään.

Itse ratkaisun yksityiskohtiahan ei saa kommentoida, mutta tehtävästä on mahdollista keskustella noin yleisen suunnittelun tasolla.

Eli tässä niitä ohjeita:

– Lue määrittelyt useita kertoja, yritä lukea rivien välistä, ja käy läpi mitä keskusteluryhmissä puidaan, ja mitä toimialalla on yleensä tehty. On syytä ymmärtää esim. käytetyt alakohtaiset jenkkitermit oikein.

– Tee hyvä ja selkeä assumptions lista jossa perustelet miten tulkitsit ristiriitoja ja selitä miten päädyit arkkitehtuuriisi. Tässä laatu ja selkeys menee ohi määrän, arvostelijat lukevat valtavan määrän näitä ja mitä eivät ymmärrä, niin siihen eivät hyvin reagoi.

– Panosta täydelliseen UML yhteensopivuuteen, halutulla versiolla. Itse sain siitä aika helposti täydet pisteet. Käytä hyvää välinettä. Itse käytin Enterprise Architectia, mutta sinällään mikä hyvänsä muu kuin Powerpoint toiminee 😉

– Spesifi vinkki: Jostain kumman syystä arvostelijat haluavat näemmä että näyttökerros kuvataan omana kerroksenaan myös luokkakaaviossa ,eli varaudu laittamaan JSP/JSF sivut/Facelet templatet myös luokiksi. Omasta mielestäni en olisi näin luokkakaaviota sotkenut mutta näemmä oli syytä että saa hyvät/riittävät/täydet pisteet.

– Iteroi ja istu designin päällä hyvän aikaa ennen kuin lähetät sen, itsellä on ainakin malttamaton mieli ja piti pakottaa itsensä työstämään tätä vielä muutama iteraatio kun aloin olemaan varsin tyytyväinen.

– Automatisoi loppuratkaisun paketoiminen ja tuplatarkista että lähetät kaikki mitä tarvitaan ja kaikkien uusimmat versiot.

Jep, enempiä en taida uskaltaa tähän kirjotella. Mutta toki JavaRanchin forumeilta löytyy erittäin hyödyllisiä lisävinkkejä kaikkiin Java sertifikaatteihin.

Terveisiä mobiiliseminaarista

Jep, pidin juuri esityksen Android tableteista Tampereen Tieturi Forum seminaarissa. Esityksessä kun tuli mainittua tabletin käyttö sisällöntuotantoon niin tässäpä kirjoittelen taas Xoom tabletilla blogiani. 🙂  Hauskaa miten tässä toteutuu juuri käsittelemäni online/offline kyvykkys, eli kirjoittelen artikkelin ihan offline, tallennan sen offline, ja lähetän WordPressiin (pilveen) kun verkkoyhteys löytyy.

Mielenkiintoista tulevaisuuden kannalta kyllä jako HTML 5 vs tabletin ohjelmoiminen. HTML 5 tuo selkeästi paljon juttuja jotka aiemmin vaativat oikeaa ohjelmointia päätelaitteessa. Ja tottakai on kovasti etuja jos  voi ratkaisun tehdä puhtaasti palvelinpäässä. Mutta HTML 5 toki standardoidaan vasta 2013 – ehkä… Ja selainten tuki ominaisuuksille on suorastaan karmea, tulee 1995 browser wars mieleen. Yritäppä esim. löytää video tai audioformaatti jota kaikki HTML 5 yhteensopivat selaimet tukevat samalla kertaa…

Pidin muuten esitykseni Xoom tabletilla, käyttäen DropBox pilvipalvelua (editoin esityksen pilveen ja latasin sen pilvestä xoomiin), ja käyttelin QuickOffice/Documents 2 Go sovellusta niiden esittämiseen.

Xoomissa on mukavasti mini HDMI liitäntä (720p), johon meikäläisellä on micro-to-fullsize piuha (micro type D to full size type A), jolla sen saisi hdmi tykkiin tai näyttöön kiinni. Toisin kuin iPad ykkösen surkuhupaisa vain joissain sovelluksissa tuettu näytön peilaus, android tableteissa (ja iPad 2:ssa) toimii täysi näytön peilaus eli mitä näkee näytöllään näkee myös ruudulla/videoscreenillä. Videotykki ei valitettavasti tukenut HDMI:tä, osasin varautua siihenkin ja taskussa oli HDMI-to-VGA konvertteri 😉

Varauduin verkkoyhteyden puutteeseen myös ottamalla mukaan Android USB kaapelin, jonka avulla Android micro-usb portti muuttuu täyskokoiseksi usb naarasliitännäksi, johon voi tuupata vaikka muistitikun, kameran, siirtokovalevyn, näppiksen, hiiren, tai vaikka ps3 ohjaimen, jos siltä tuntuu. Toisin kuin ipadeissä, Androidissa toiminto on täydellinen ja sen avulla voi myös siirtää tavaraa ulos tabletista, ja täysin rajoittamatta sisään. Honeycombissahan tuli USB Host tuki ja Ice Cream Sandwichin myötä se on myös kännyköissä aikanaan. Mietiskelin vähän ottaisiko lomalle aikanaan mukaan kameroiden kaveriksi tabletin kannettavan sijasta, sinne mahtuisi muutamakin muistikortillinen tyhjentää raakamuotoisena. iPadissa ei saa tosiaan musiikkia tai kuvia aivan helposti ulos mutta niissäkin voi toki dumpata asioita pilvipalveluun kuten DropBox tai iCloud. Odotin jotain demo-efektejä mutta hienostihan tuo toimi.

Esityksen aikana tuli vielä kysymystä Android tabletista yrityskäytössä. Osasin kertoa että kalenterin ja sähköpostin synkronoinnilta ei voisi juuri enempää toivoa (synkkaa esim. henk koht kalentereita useampia Googlen palvelimelta, ja samaaan näkymään firman Exchange serveriltä, samoin sähköpostit monesta paikkaa), mutta VPN:n suhteen en osannut kommentoida miten pelittää kun en ole tullut aiemmin kokeilleeksi. Oli puhetta siitä että olisi kiva jos mobiililaitteella voisi selata myös niitä (säälittäviä) firmasovelluksia jotka toimivat vain lähiverkossa/vaativat vpn yhteyden eivätkä toimi suoralla yhteydellä. Uteliaisuuttani katsoin miten Xoomissa homma toimisi, ja selvisi että Androidissa on ollut vpn sisäänrakennettuna toimintona jostain 1.6 versiosta asti. Eli omassa Honeycombissani naps, asetuksista uusi VPN yhteys päälle, sinne serverin ip, ja viidessä minuutissa oli vpn pystyssä kännykkä wi-fi tukiaseman yli, ja intranet auki selaimessa (sharepoint portal server). Eli hienosti pelitti. Ja muita hauskoja yrityskäyttövirityksiä on mm. pari omaa tekemääni sovellusta työajan seurantaan ja kalenterihallintaan. Ja tietysti löytyy telnet, ping, ftp clienttia sun muuta kivaa.

Mitähän muuta yrityskäyttö-tabletilta voisi vaatia?

JavaFX 2.0

No niin, blogiin ei ole tullut kirjoituksia hetkeen, piti sairastaa kausiflunssa manalasta, ja työkiireet ovat vieneet muut ajat. Mitään erityistä kirjoittamisen arvoista ei ole myöskään tutkaan ilmestynyt hetkeen. Ajattelin kirjailla kuitenkin taas vähän ajatuksiani ettei täysin unohdu tämä blogi.

Yksi työkiireistä on JavaFX 2.0 ohjelmointikurssin teko, se alkaakin olla valmis ja toteutuu jo ensi vuoden tammikuusta alkaen varmasti – ensimmäiset ovat jo ilmoittautuneet mukaan. JavaFX ei varmaan ole kaikille – serveripään web sovelluksia tekeville mielenkiinto on korkeintaan mietoa, mutta kaikille joita rikas käyttöliittymäelämys työasemassa kiinnostaa, ja kaikille joille Swing on tuttu, tässä voi olla jotain uutta.

http://www.tieturi.fi/haku.html?q=javafx

 

Rikas käyttöliittymä on aina oma juttunsa. Se mahdollistaa asioita jotka webissä ovat mahdottomia tai ainakin hankalia. Se antaa suorituskykymielessä kyvyn käyttää työaseman resursseja paremmin hyödyksi. Mutta se vaatii sen virtuaalikone-asennuksen myös, plus lisäkirjastot. Ja tämäpä onkin se kynnyskysymys sille miten JavaFX 2 tulee tai ei tule leviämään. Asennus tulee olla helppo ja vaivaton ja suorastaan idioottivarma.

Olen tainnut kirjailla jo aiemmin Java 6 virityksistä jotka auttavat tässä. JavaScript deployment toolkit joka osaa tarkistaa onko sopiva Java ja asentaa sen tarvittaessa. Modulaarinen Java jossa voidaan asentaa ensin kernel ja sitten lisäosia – saadaan nopeasti jo jotain käyntiin. Java Quickstarter joka esilämmittää virtuaalikoneen jo koneen käynnistyessä. Java 7 ei lisännyt mitään yhtä dramaattista, toki Java 8 jigsaw tulee viemään modulaarisuutta pidemmälle ja toivon että sensijaan että ladataan 15megan JVM + JavaFX kirjastot, jigsawn myötä voi valita osat joita ladataan ja ehkä asennuspaketti saataisiin viiteen megaan tai alle. Hienosäätöähän tämä on mutta kun kyse on siitä, miten pitkään käyttäjä katsoo harmaata ruutua tai ’ladataan javaa’-tekstiä, pienetkin erot ratkaisevat.

Uskon että JavaFX 2.0 tulee olemaan menestys, koska se pohjautuu tällä kertaa Java kieleen ja sillä on vain annettavaa, mitään uutta kieltä tai tapaa ei tarvi opetella, vaan kyse on vain rajapinnoista. Uusia moduuleita tulee mukaan kuten charting, animaatiot, efektit, käytännössä ilmaiseksi. Se ei varmasti tule pyyhkäisemään tieltään web ohjelmointimalleja kuten JSF frameworkit tai Vaadin, mutta Suomessa on tehty Rich Client sovelluksia ennenkin ja tullaan tekemään – kaikki ei ole edelleenkään webissä, ja tulevaisuuden sovelluksissa tulee tyypillisesti olemaan jokatapauksessa kyse palvelinpään RESTful web serviceistä joita kutsutaan milloin mistäkin clientista.

Nyt kun vielä JavaFX pelaisi iPad:issä.. Tiedän että sitä demottiin iPadissä jo viime JavaOne seminaarissa, mutta ei se vielä oikeasti ole saatavilla. Ja miksi, ah miksi, se ei toimi jo Androidissa… No, retorinen kysymys, vastaus tähän lienee eräs oikeusjupakka jota vieläkin puidaan.. 😉 Mutta näiden suhteen on paljon odotettavaa, ja ellei JavaFX luikertele tableteihin ja kännyköihin, sen maailmanvalloitus tulee jäämään pahasti rajoittuneeksi.