This version of Java is not distributed by Sun (d’oh!)

Only continue if you want to trust the publisher

Hmmmmmmmmmmmmmmm…..

Jep, ja vuoden ensimmäinen posti, hauskaa alkavaa vuotta vain kaikille, saa nähdä mitä kaikkea tuo tullessaan!

JavaFX kurssi on valmis ja ensi toteutus ensi viikolla. Hauskoja harjoituksia tuli tehtyä!

Nyt sitten vain odottelemaan versioita 4.01 ja 4.0.3 ja tietysti maagista versiota 4.1 (Jelly Beans? :

4.0.2

The Android 4.0.2 update was released on 28 November 2011, and fixed minor bugs on the Verizon Galaxy Nexus, the launch of which was later delayed.

4.0.3

The Android 4.0.3 update included a number of bug fixes and optimizations, and offers improvements to graphics, databases, spell-checking, Bluetooth functionality, and other features. New APIs were released for developers, including a social stream API in the Contacts provider, Calendar provider enhancements, new camera apps enhancing video stabilization and QVGA resolution, and accessibility refinements such as improved content access for screen readers.

Täytyy sanoa että olen Android luureista aiemminkin pitänyt, mutta tässä uudessa on jotain kovin rakastettavaa. Android 4.0:han pohjautuu jo tableteista tuttuun 3.0 Honeycombiin eli uutta on mm. Holographic UI ja usb-portin viritykset. Neljä täysversiota on antanut aikaa hioa yksityiskohtia ja niitä tässä luurissa piisaakin. Pari pääjuttua jotka tulevat heti mieleen on huimasti parannettu kamera, ja widgetit.

Kamera on nyt ‘zero shutter lag’ mallia eli kuvanotto on käytännössä salamannopea, toki tarkennus ja salama vievät hetkisen aikaa mutta kuva vetää vertoja pokkareille ja jopa päihittää useimmat halvat mallit kevyesti. Lisäksi kameraan on lisätty panoraamatoiminto jolla voi pyyhkäistä laajaa maisemaa, sopii erityisen hyvin lomakuviin, maisemakuviin yleensä, ja vaikkapa asunnon myyntiesittelyyn Kameran tarkkuutta myös nostettu, nyt onnistuu 1080p video ja viiden megapikselin kuvat. Juuri enemmästä ei näillä linssitekniikoilla ole enää hyötyäkään. Ruutu on toki myös 4.65″ HD 12080x720p super amoled, komealtahan se näyttää. Joitain häiritsee että luuri suurenee leveyssuunnassa, itseäni ei. Koko on itseasiassa nyt juuri aika passeli, kirjoittamiseen ja katseluun ja siihen että se ei huku taskun pohjalle.

Face detect unlock on ihan hauska party trick muttei toimi kovin hyvin kun valaisuolosuhteet vaihtelevat – face detection rajapinta on kuitenkin koodaajille mielenkiintoisia mahdollisuuksia omaava ja auttaahan se tarkentamaan kasvoihin oikein.

Ja businesspuhelimessa toimii sähköpostit, kalenterit, itse synkkaan molemmat sekä Googlen että firman Exchangen kanssa, ja tietysti jo aiemmin testattu VPN yhteys sekä aiemmin kypsytellyt firman omat softat. Vielä kun on yhteys DropBox:iin jonka kautta jakelen dokumentit tablettien, kannettavien, koti ja työkoneiden ja puhelinten välillä niin kivasti pelittää. Useampi luento jo pidetty tabletilla, ehkä olisi aika kokeilla seuraavaksi puhelimella

Widgeteistä jo mainitsin. Ei niissä mitään ihmeellistä, mutta niitä on vain hiottu jatkuvasti ja nyt ne ovat komeita, interaktiivisia, tulevat monessa eri koossa, ja monisivuisesta ‘työpöydästä’ voi koostaa juuri haluamansa näköisen. Ja Windows Phonen valttikortti, People sovellus on tännekin apinoitu, kivasti saa kuvat ruudulle kuten tuolla Googlen sivuilla mainostellaan.

Android Beam on vielä testaamatta, kun ei ole juuri muita ICS luureja lähellä, mutta odottelen sitä mielenkiinnolla. Tietysti parannettu musasovellus, kuvankäsittelysovellus, selain, maps, jne. Itse ostin välittömästi luuriin kunnon navigointisoftan. Kaksi niistä oli susia, onneksi markettiin saa palauttaa vartin sisään sovelluksen joka ei toimi ilman isompia prosesseja. Toinen oli selkeästi tehty aikanaan siten että se oletti puhelimen olevan tablet ja ahnehti tilaa enemmän kuin ruudulla oli. Toinen ei vain käynnistynyt. Kolmas kerta toden sanoi ja nyt on kiva suomalainen naisääni, Leena, ohjastamassa perille. Muita ostettuja softia mitä käytän on kunnon sound recorder saneluita varten, ja hyvä podcast/newsreader. Myös office paketti on ostettuna. Nämähän ovat siitä kivoja että kerran ostettuna voi asennella kaikkiin android laitteisiin, myös Xoom tablettiini, ja hinta vaihtelee parin euron tai sentin ja muutaman kympin välillä. Joulun aikaan oli erikois-alessa suosittuja softia 25 senttiä kipale, tuli hieman latailtua

Loistava puhelin siis, ensimmäinen johon olen jokseenkin täysin tyytyväinen. Miinus akkukesto. Pitänee alkaa kantamaan ydinreaktoria selkärepussa, tai näillä säillä propellihattu ja tuulivoimala.

Lambda expression on siis uudenlainen syntaksi. Skeptikoiden mielestä tämä on sama kuin anonyymin luokan käyttö, eli kutsutaan jotain metodia, ojennetaan parametrina anonyymi luokka jossa on algoritmi sisässä. Esim. Comparator toteutus. Lambda Expression on kuitenkin syvemmälle menevä muutos joka muuttaa Java-kielen syntaksia. Tällä hetkellä päällimmäisin muutos on uusi operaattori: ->

Tässähän ei ole mitään uutta, Scalassa ja C# kielessä on ollut jo tämä piirre aikansa, mutta hiljaa hyvä tulee.. Tässä esimerkki Lambda Expression käytöstä:

Eli mitäpä tuo tarkoittaa? Määritellään tavallaan anonyymi ilmassa roikkuva funktio, joka ei näytä kuuluvan mihinkään luokkaan. Funktio ottaa parametrinaan muuttujan x, ja määrittelee operaattorin perään sille algoritmiksi: palauta x + 1. Tietysti tässä tapauksessa lambda expression olettaa vahvasti että x on arvo jolle +1 on laillinen operaatio, esim. numeroarvo. Tuo ei tietysti yksinään tee mitään, vaan tätä täytyy käyttää jossain. Määritellään rajapinta joka sisältää metodin joka ottaa sisään arvon ja palauttaa toisen:

interface MyCalculator {
  public double operate (double input);
}

Tähän asti tuttua kamaa. Seuraavaksi määritellään lambda expression ja asetetaan muuttuja viittaamaan siihen:

MyCalculator mc = (x) -> x+1;
System.out.println(mc.operate(1));

Eli näillä tulostuu tietysti ruudulle kaksi. Eiköhän tässä ole teaseriksi sopivasti, palataan asiaan joskus kun tiedän näistä enemmän. Aikaisinhan tässä liikkeellä ollaan

Ei mikään suuri salaisuus, että näitä tullaan näkemään eritoten Java 8 Collections-rajapinnoissa. Juuri kun suuri osa koodaajista alkaa olla toipunut Java 5 Generics tyyppiparametrien käytöstä..

Harmi ettei vielä ole EE 6 serttiä tarjolla, siinä vasta kiintoisa alusta..

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.

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.

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?

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.