Avainsana: koodaus

do while koodi <3

Yksi sovellus, kolme Java EE -käyttöliittymäkehystä

Sovelluskehityksessä käyttöliittymän rakentaminen ja käyttäjille näkyvien toimintojen toteuttaminen on yksi tärkeimmistä osuuksista, sillä hyväkin sovellus voi kaatua heikkoon käyttöliittymään. Java EE -sovelluskehityksessä on tarjolla useita erilaisia käyttöliittymäkehyksiä, jotka tarjoavat työkalut toimivan käyttöliittymän rakentamiseen, mutta käyttötarkoitukseen sopivan välineen valinta ei ole aina yksiselitteistä. Oli siis aika päivittää hieman tietoja erilaisten Java EE -käyttöliittymäkehysten osalta ja tutustua Vaadin 7:aan, Java Server Faces (JSF) 2:een PrimeFacesin kanssa ja Apache Wicket 6:een toteuttamalla yksinkertainen imgur-kuvaselaussovellus. Aikaisemmin olen kehittänyt sovelluksia käyttäen muun muassa Strutsia, JSF 1.2:sta ja Wicket 1.5:sta.

Java EE 6 -sovelluksia voi toteutta monella eri tekniikoilla ja tällä kertaa toteutin käyttöliittymäkerroksen usealla eri tavalla (Vaadin 7, JSF2, Wicket 6) ja pitäen taustapalvelut vakiona. Imgurin REST-APIn käsittelyyn käytin jokaisessa sovelluksessa Apache CXF:ää rajapinnan lukemiseen ja GSONia JSON-sanoman muuntamiseen Java-olioiksi. Vaikka kaikki kolme kehystä tukevat Java EE 6:n JSR 299 CDI:tä, tein Java Beanien injektoinnin Spring 3:lla, joka toimi varmasti myös vanhemman WebLogic 11g -sovelluspalvelimen kanssa. Jettyllä tai TomEE:llä ajettaessa ei olisi ollut mitään ongelmaa.

Sovellusten koodit löytyvät GitHubista (https://github.com/walokra/fotorest.git), vaikkakaan ne eivät ole mitenkään viimeisteltyjä. Ehkä niistä kuitenkin on jollekin hyötyä.

Sovellus 1: Vaadin 7

Vaadin on avoimen lähdekoodin Java-sovelluskehys Web-sovellusten rakentamiseen ja muistuttaa enemmän työpöytäsovellusten tekemistä esimerkiksi Java Swing -kehyksellä kuin perinteistä Web-sovelluskehitystä HTML:n ja JavaScriptin kanssa. Vaadin rakentuu Google Web Toolkitin päälle ja käyttää GWT:tä sivujen renderöintiin. Vaadin on suomalaisen Turussa pääkonttoriaan pitävän Vaadin Oy:n kehittämä. Vaadin 7 julkaistiin pari kuukautta sitten.

Vaadin tarjoaa perinteiselle Java-kehittäjälle helpomman lähestymisen Web-sovellusten kehittämiseen, kun käyttöliittymän rakentaminen onnistuu ilman HTML:n ja JavaScriptin kanssa askartelua. Vastaavasti HTML:ää osaavalle kehittäjälle Swing-tyylinen käyttöliittymän rakentaminen voi olla tuskastuttavaa. Vaadin tarjoaa itsessään kattavan valikoiman erilaisia käyttöliittymäkomponentteja ja erilaiset demot antavat hyvän kuvan mitä Vaatimella saa aikaan.

Yksinkertaisen imgur-selaajan toteutus Vaadin 7:lla luonnistui nopeasti, kun olin ensin sisäistänyt Swing-tyylisen käyttöliittymän idean. Toimivan ulkoasun ja muutamat toiminnot sai rakennettua suhteellisen helposti ja lopputuloksesta tuli siisti. Koska Vaadin-sovellus on käytännössä kasa Javascriptiä, on sen debuggaaminen hieman hankalampaa, mutta kehys tarjoaa avuksi kohtalaiset työvälineet (?debug-parametri). Käytin Vaatimen oletusteemaa, koska muut teemat eivät vielä uusinta versiota tukeneet. Uuteen kehykseen tutustumisessa auttoi myös Vaatimen laadukas dokumentaatio ja keskustelufoorumi, vaikkakin moni keskustelu ja netistä löytyvä esimerkki käsitteli aikaisempaa 6 versiota.

Fotorest-sovellus toteutettuna Vaadin 7:lla:
Fotorest Vaadin 7

Sovellus 2: JavaServer Faces 2 + PrimeFaces

JSF 2 eli Java Server Faces on Javan spesifikaatio Web-sovellusten komponenttipohjaisten käyttöliittymien rakentamiseen ja osa Java Enterprise Editionia. Sovellus koostuu HTML:ää ja Facelet-tageja sisältävistä -XML-tiedostoista, jotka kehys prosessoi ja tarjoilee käyttäjälle. JSF:n 2 -versio julkaistiin 2009 ja tuorein 2.2. versio huhtikuussa 2013.

Sovelluksen ulkoasun rakentaminen ei juurikaan eroa normaalista Web-kehityksestä, joten HTML ja CSS -osaaminen ovat tarpeen siistin käyttöliittymän aikaansaamiseksi. JSF:n tarjoamia ominaisuuksia ja komponentteja voi laajentaa muun muassa PrimeFaces tai RichFaces -komponenttikirjastoilla, joilla käyttöliittymään saa enemmän kilkettä ja parempaa käytettävyyttä.

JSF 2:n oli sovelluskehitysalustana suhteellisen tuttu, sillä olin käyttänyt sitä pienen prototyypin tekemiseen pari vuotta sitten, eikä vuosien aikana mikään ollut juuri muuttunut. Täten uutena asiana oli enemmänkin PrimeFaces -käyttöliittymäkomponenttien käyttäminen. Yksinkertainen kuvaselaaja syntyi lähes yhtä helposti kuin Vaadinta käytettäessä, vaikka osa toiminnoista piti koodata sivupohjiin ja osa Javan puolelle ja käyttöliittymän dynaamisessa päivittämisessä oli alkuun pieniä ongelmia. PrimeFaces tarjosi kattavan listan erilaisia käyttöliittymäkomponentteja ja niiden ulkoasua oli helppo muokata jQuery UIn ThemeRollerin avulla.

Fotorest-sovellus toteutettuna JSF 2 + PrimeFacesilla:
Fotorest JSF 2 + PrimeFaces

Sovellus 3: Apache Wicket 6

Apache Wicket on avoimen lähdekoodin komponenttipohjainen Web-sovelluskehys Javalle. Lyhyesti kuvattuna Wicket on kuin yhdistelmä Vaadin ja JSF -kehyksiä, sillä käyttöliittymä rakentuu HTML-sivupohjista ja tapahtumiin reakoivista komponenteista. Sovelluksen ulkoasun voi täten rakentaa HTML:llä ja lisätä toiminnot Javan puolelta juurikaan koskematta sivupohjiin. Wicket 6 julkaistiin syksyllä 2009.

Wicket ei JSF:n tavoin tarjoa peruskomponentteja enempää, mutta käyttöliittymän toiminnallisuuksien laajentamiseen voi käyttää useita jQuery-pohjaisia komponenttikirjastoja kuten Wicket – jQuery UI, jqwicket ja wiquery. Vaikka komponenttikirjastoja on useita, ovat niiden heikkous ajantasaisuus (esim. jqwicket vain 1.5 versiolle), eivätkä ne eivät ole aivan yhtä kattavia kuin mitä Vaadin tai JSF:n kirjastot tarjoavat.

Ideana HTML-sivupohjat ja työpöytäsovellusmaisen tapahtumapohjaisuuden yhdistelmä on hyvä, mutta jotenkin kokonaisuus ei ole yhtä miellyttävä kuin JSF 2 tai Vaadin. Kehittäjän kannalta Wicketissä on monia hyviä puolia, kuten toimintojen liittäminen komponentteihin ja niiden uudelleenkäyttö on kätevämpää kuin JSF 2:ssa ja sovelluksen kehittäminen on kohtalaisen selkeää, kun toiminnot ovat yhdessä paikassa eikä sekä sivupohjassa että Java-luokassa kuten JSF 2:ssa. Itseäni eniten Wicketin osalta harmittaa kuitenkin kattavien komponenttikirjastojen puute, joka tekee käyttöliittymän toiminnallisuuksien rakentamisesta hieman työlästä, kun asiat joutuu toteuttamaan itse. Yksinkertaista kuvaselaajaakin varten piti tehdä muutamia lisäluokkia, eikä valmista loputtomasti skrollaavaa taulukkokomponenttia ollut saatavilla.

Fotorest-sovellus toteutettuna Wicket 6:lla:
Fotorest Wicket 6

Yhteenveto

Kolme Java EE -käyttöliittymäkehystä ja kolme erilaista tapaa lähestyä käyttöliittymän rakentamista. Vaadin 7 tarjosi nopeasti siistiä Swing-tyylisesti komponenttien kera, JSF 2 + PrimeFaces luotti perinteisempään komponenttipohjaiseen HTML:ään ja tageihin ja Wicket 6 oli joukosta hieman työläämpi komponenttipohjainen ratkaisu. Kokonaisuutena Vaadin on selkeästi yhtenäisin paketti ja sekä JSF:n että Wicketin kanssa on hieman enemmän askarreltavaa, joka toki myös tarjoaa vapauksia.

Jokaisella kehyksellä sai aikaan suhteellisen pienellä vaivalla yksinkertaisen imgur-kuvaselaajan haun kera. Jos pitäisi saada nopeasti valmista, niin kenties toteuttaisin sen Vaatimella, jolloin aikaa ei mene niin paljoa käyttöliittymän kanssa taisteluun. Valmiiden sivupohjien kanssa JSF 2:llakin syntyy koodia nopeasti. Kaikissa kolmessa on kyllä omat jekkunsa ja ”ongelmansa” muun muassa sessioiden koon ja selaimen kuormittavuuden osalta.

Seuraavaksi tutustumislistalla JVM:ssä toimivien kehysten osalta on ehkä Spring MVC, Play Framework, Grails ja puhdas GWT. Lisäksi Node.js:llä toteutettu kuvaselain on jo osittain tehty.

Projekti Euler haastaa laskennallisilla pähkinöillä

Työskentelen päivisin pääasiassa Java EE -sovelluskehittäjänä, mutta koska 7,5 tuntia päivässä sovelluskehitystä ei aina ole riittävästi, päätin jatkaa vuosia sitten kesken jäänyttä taivaltani Projekti Eulerin parissa. Eli ratkaista erilaisia laskennallisia ongelmia vapaasti valittavalla ohjelmointikielellä. Tarkoituksenani on samalla opetella myös eri ohjelmointikieliä ja ohessa harjaantuvat myös matemaattiset ja algoritmilliset taidot. Kymmenen ensimmäistä ongelmaa ratkesi Pythonilla suhteellisen helposti.

Projekti Euler tarjoaa sarjan laskennallisia ja matemaattisia ongelmia tietokoneella ratkaistavaksi ja mahdollisuuden tavoitella erilaisia saavutuksia, kisailla kavereiden kanssa ja keskustella ratkaisuista muiden käyttäjien kanssa. Projekti alkoi Colin Hughesin toimesta vuonna 2001 mathschallenge.net -sivuston alaosiona ja on nimetty uraauurtavan sveitsiläisen matemaatikon ja fyysikon, Leonhard Eulerin, mukaan. Käytännössä projekti pyörii käyttäjien toimesta, jotka ehdottavat uusia pähkinöitä, ja lahjakkaiden matemaatikkojen ja ohjelmoijien tiimi muuntaa ne ratkaistaviksi ongelmiksi. Tällä hetkellä pähkinöitä on 367 ja uusia julkaistaan epäsäännöllisin välein.

Ratkaisemani ongelmat ja niiden koodit löytyvät ”theeuler” -repostani GitHubista. Ratkaisuista huomaa, että niissä ei ole tähdätty elegantteihin ratkaisuihin. Ehkä sitten myöhemmin. Ensimmäiset kymmenen tehtävää, jotka tähän mennessä olen suorittanut, ovat kohtuullisen helppoja ja sisältävät peruskäsitteitä alkuluvujen generoinnista suurimpaan yhteiseen jakajaan. Pythonilla pähkinät ratkesivat suhteellisen helposti, samoin Javalla. Seuraavaksi ehkä Scala ja JavaScript.

Pelkällä raa’alla voimalla ei ongelmia luultavasti enää alkupään jälkeen ratkaista, vaan vastauksen saaminen vapaasti asetetussa minuutin aikarajassa vaatii sekä tietoa että taitoa kehittää sopiva algoritmi. Koska ongelmat ovat matemaattisia, auttaa niiden ratkaisemiseen muun muassa matemaattisten teorioiden kuten lukuteorian tunteminen. Tuskin kuitenkaan pyyhin pölyjä hyllyssä olevasta Calculuksesta tai Betasta, sillä hakukone tarjonnee vastauksia teorioiden osalta.

Internetissä on tarjolla myös muita vastaavia projekteja, jotka tarjoavat ohjelmoijille keinon virkistää ja kehittää taitojaan. Code Academy opettaa ohjelmoimaan (JavaScriptiä) kädestä pitäen, CodeKata tarjoaa 21 harjoitusta paremmaksi ohjelmoijaksi tulemiseen koodauksen ja ajattelun kautta, Rubyn opetteluun voi seurata Ruby Koans -polkua, logiikkaongelmia voi ratkoa 99 Prolog ongelman kautta ja Python Challenge tarjoaa kuvavihjeellisiä pähkinöitä. Kaikilla sivustoilla on hieman oma lähestymisensä ohjelmoijien aktivoimiseen.

Eclipse 3.7 Indigo on askel parempaan

Kesäisin juhannuksen ja kesälomien ohella on yksi asia, jota etenkin sovelluskehittäjät odottavat: Eclipsen uuden version julkaisu. Tänä vuonna Eclipse -kehitysympäristöstä julkaistiin 3.7 -versio, joka on koodinimetty Indigoksi. Eclipse Foundation koordinoimaan vuosittaiseen julkaisuun osallistui 62:n Eclipse -projektia, joista kehitysympäristön ekosysteemi rakentuu.

Indigon suurimpia uudistuksia Java-kehittäjän näkökulmasta ovat muun muassa:

  • Egit 1.0: Git-versionhallinnan integroiminen
  • WindowBuilder: Graafisten SWT ja Swing -käyttöliittymien rakentamiseen
  • Jubula: Java ja HTML -sovellusten funktionaalisen GUI -testausten automatisoimiseen
  • m2eclipse: Mavenin integroiminen Eclipsen työtilaan
  • Mylyn 3.6 tukee nyt Hudsonin buildien monitorointia
  • Eclipse Marketplace tukee laajennusten lisäämistä vetämällä ja pudottamalla
  • Tuki WebKitille kaikilla alustoilla
  • Cocoa parannuksia OS X:llä

Tarkempaa listausta uudistuksista voi yrittää etsiä Indigon suunnitelma -wikistä.

Suunnitelluista uudistuksista Java 7 -tukea jouduttiin siirtämään, koska siihen liittyvät speksit olivat saatavilla liian myöhään ja virallinen julkistaminen (28.7.2011) on Indigon julkaisun jälkeen. Vastahan tässä Enterprise-sovellusten osalta (lue Oraclen palikat) päästiin Java 6:sta käyttämään, joten eipä sillä niin tarvetta.

Uusista ominaisuuksista WindowBuilder kuulostaa kätevältä, vaikka onneksi ei GUI-palikoita tarvitse rakennella. Nyt käsin tunkkaamisen asemesta elementtejä voi lähestyä kuten Netbeansin työkalujen kanssa on jo kauan voinut: valitse komponentti ja tiputa paikoilleen. WindowBuilderissa on kaksisuuntainen koodigenerointi, joka mahdollistaa yhteentoimivuuden käsinmuokatun koodin kanssa, joten ehkä se ei tuota yhtä sotkuista koodia kuin koodigenerointi yleensä.

Kokonaisuutena Eclipse 3.7 Indigo on jälleen askel parempaan kehitysympäristöön, vaikka mitään suuria, maata järisyttäviä, uudistuksia ei nähty, kuten ei viime vuonna Helioksenkaan osalta (lukuun ottamatta Marketplacea) tai pari vuotta sitten Ganymedessä, enkä edes muista mitä uudistuksia Galileo vuosi sitten toi. Saa nähdä vieläkö Eclipse hajonnee ikävän herkästi ja temppuilee. Rohkeat voivat koittaa vanhan Eclipse asennuksen importoimista Indigoon, joka yrittää asentaa vanhassa olleet laajennukset uuteen.

Eclipse 3.6 Helioksen myötä kehitysympäristö on taas parempi

Eclipsestä julkaistiin jokin aika sitten 3.6-versio eli tällä kertaa tuttavallisemmin Helios, joka jälleen tekee kehitysympäristöstä asteen paremman. Suuria muutoksia ei hyväksi havaittuun kaavaan ole tehty, vaan uudistuksina löytyy pieniä, mutta hyödyllisiä lisäominaisuuksia. Tarkemman listauksen uusista ominaisuuksista löytää Helioksen About-sivulta What’s New -osiosta (ja netistä: JDT ja platform), mutta tässä muutamia poimintoja.

  • Lisäosien asennus Eclipse Marketplacesta: Tarvittavien lisäosien asennus on nyt helpompaa Eclipsen sisältä löytyvän Marketplacen kautta. Hakusana ja pari kliksautusta, entisen update siten syöttelyn asemasta. Harmillisesti kaikki laajennukset eivät uutta tapaa vielä tue.
  • Web Tools Project sai tuen Java EE 6 -teknologioille kuten Servlet 3.0, JSF 2.0, JPA 2.0 ja EJB 3.1. (Jos niitä vielä pystyisi oikeasti toteutuksessä käyttämäänkin)
  • Formatoinnin kontrollointi: Window > Preferences > Java > Code Style > Formatter > On/Off Tags -kohdasta voi nyt kytkeä päälle annotaation, jolla voi disabloida koodin formatoinnin haluamalleen koodiblokille
  • ”rawtypes” -merkki @SuppressWarnings annotaatiolle: Kääntäjä tekee eron ilmoitettujen varoitusten osalta raw typen käytön ja geneeristen unchecked -operaatioiden osalta.
  • Export All: Formatterin asetuksista voi nyt viedä kaikki käyttäjän määrittelemä asetukset, ja ne voidaan tuoda kerralla. Kätevää, kun Eclipse tulee muutamia kertoja vuodessa asennettua uudestaan.
  • Pakettien nimien lyhenteet: Java-näkymissä voi lyhentää kustomoitavilla säännöillä pakettien nimet. esim. org.eclipse.ui={UI}, org.eclipse.ui.texteditor={T} ja org.eclipse.ui.internal.texteditor=[iT]. (Preferences > Java > Appearance > Abbreviate package names)
  • Lokaalin historian tyhjennyksen voi disabloida: Lokaalin historian kokoa siivotaan aina Eclipsen sammutuksen yhteydessä, mutta sen voi nyt disabloida. Tällöin historian koko kasvaa rajattomasti. (Preferences > General > Workspace > Local History)

Uusi Eclipse on nyt ollut muutaman viikon käytössä ja ihan toimivalta se edelleen vaikuttaa. Kenties hieman myös nopeampi kuin edellinen, ta sitten vain uusi asennus luo hyvää mielikuvaa. Asennuksessa tosin taas meni aikaa säätäessä kaikki kuten aikaisemmin ja Marketplace auttoi hieman lisäosien suhteen, mutta turhan vähän. Samalla vaihdoin Subclipsen käyttöön, joten Maven2-projekien tuonti versionhallinnasta oli kätevämpää. Laitoinpa samalla myös Atlassian Connectorit, jotka vaikuttavat ihan käteviltä. JBossin työkaluista piti tosin asentaa Nightly Build -versiot.

Pitäisikö Web-sovelluksilla olla yhtenäinen tyyli ja logiikka?

Nykyään suuri osa sovelluksista toimii Web-selaimissa ja sovellusten osalta on havaittavissa siirtymää työpöydältä Web-sovelluksiksi, jolloin aikaisemmin suhteellisen samanlailla toimivat ja näyttävät käyttöliittymät muuttuvat monimuotoisiksi. Web-maailmassa ei ole yhtenäistä tapaa toteuttaa asioita, vaan jokainen suunnittelija tekee kuten parhaimmakseen näkee ja sovellusten ulkoasut vaihtelevat suuresti. Perinteisten työpöytäsovellusten osalta eri sovellukset toimivat suurin piirtein samoilla periaatteilla ja toimintopainikkeet sekä näyttävät samoilta että löytyvät tutuista paikoista.

Usability Post kysyykin, pitäisikö Web-sovelluksilla olla yhtenäinen käyttöliittymä, eli ulkoasu näyttäisi ja toimisi visuaalisesti samoilla periaatteilla, kuten työpöytäsovelluksissakin eri käyttöjärjestelmissä sovellukset ovat usein yhtenäisiä keskenään. Tutut toiminnot näyttäisivät samoilta eri Web-sovellusten välillä, kun nyt painikkeiden ja komponenttien ulkoasut vaihtelevat enemmän tai vähemmän eri sovellusten välillä.

On totta, että sitä toivoisi sovellusten toimivan edes suurin piirtein samoilla periaatteilla, ettei aina tarvitsisi arpoa miten asiat nyt tässä toimivatkaan, mutta yleisesti ottaen on vaikea nähdä, että eri Web-sovellukset näyttäisivät peruspiirteiltään samanlaisilta, toimisivat samalla tavalla tai käyttäisivät samoja komponentteja. Web on visuaalisesti toinen maailma verrattuna työpöytäsovelluksiin, joka myös heijastuu sovellusten toimintoihin. Webin osalta ei oikeastaan odoteta, että eri sovellukset näyttäisivät yhtenäisiltä, vaan ollaan jo totuttu, että jokaisen sovelluksen kohdalla pitää aina oppia uudestaan perustoiminnot ja logiikka. Onneksi suunnittelijat tekevät sovellukset usein helposti opittaviksi ja joissa asiat toimivat kuten niiden olettaa toimivan. Tai ainakin näin haluaisi uskoa, sillä todellisuus on välillä aivan jotain muuta.

Kun asiaa ajatellaan pienemmällä skaalalla, olisi sovelluskehittäjällä hyvä olla karkealla tasolla välineet yhtenäisen käyttöliittymän toteuttamiseksi, ainakin saman asiakkaan sovellusten osalta. Toki usein saman kehittäjän sovelluksissa toistuvat samat ratkaisut ja uudestaan käytettävät palikat, joilla yhtenäisyyttä syntyy kuin itsestään. Miksi keksiä asioita uudestaan, kun ne ovat jo kerran toteutettu, ellei asiaa keksi ”paremmin”. Suunnittelun ja ratkaisujen avuksi löytyy myös apuvälineitä, joilla visuaalista ilmettä ja sovellusmaista toimintaa voidaan tukea.

Webissä ei ole yhtä ja oikeaa tapaa toteuttaa asioita, vaan monet ratkaisut ovat yhtä hyviä. Mallia voi ottaa esimerkiksi useilta suunnittelumalli-sivustoilta kuten UI Patterns, YPatterns ja UI Pattern Factory. Lisäksi erilaiset komponenttikehykset kuten JQuery UI ja Java EE -maailmassa RichFaces ja PrimeFaces tarjoavat omia ehdotuksiaan toiminnoille. Vaihtoehtoja on monia ja lopputulos on usein eri ratkaisujen yhdistelemistä, jolloin sovellus koostuu useista erilaisista käyttöliittymäratkaisuista. Harvoin eri valmiiden ratkaisujen mallit toimivat suoraan omiin tarpeisiin nähden ja niitä joudutaan vähintäänkin visuaalisen ilmeen osalta virittelemään.

Koska Web perustuu pohjimmiltaan HTML:ään ja CSS:ään, voidaan valmiita komponentteja yleensä muokata ulkoasultaan tarpeiden mukaan ja soveltaa toisaalla havaittuja hyviä asioita. Esimerkiksi Web-sovelluksen käyttöliittymää varten voidaan soveltaa Cappucino tai Sproutcore -kehysten Creative Commons Attribution Share-alike -lisenssin alaisuudessa olevia Ace- ja Aristo-teemoja, jotka näyttävät siisteiltä ja tarjoavat yhtenäisen ulkoasun eri komponenttien välille.

Molemmat teemat näyttävät nykyaikaisilta ja niillä on enemmän yhteistä kuin eroa, jonka voi todeta lyhyestä vertailusta. Enemmän teemojen toiminnasta saa selville, kun vierailee teemojen demosivuilla. Sproutcoren Ace-teemasta on havaittavissa yhtäläisyyksiä OS X:n Aqua-teemaan ja SproutCoren kehitys onkin Applen sponsoroimaa. Cappucinon Aristo-teema ei ole niin silmiinpistävä kuin Ace, keskittyy näyttämään hyvältä sekä Windowsissa että OS X:ssä ja sopii paremmin vakavampiin sovelluksiin.

Molempien teemojen soveltuvuus omaan käyttötarkoitukseen riippuu toteutettavasta sovelluksesta, mutta niistä voi ainakin ottaa hieman mallia, miltä peruskomponentit voisivat näyttää. Cappucinon Aristo-teema on hieman helpommin otettavissa testiin ja se on saatavissa PSD -kuvina ja kolmannen osapuolen CSS 3 toteutuksena. Sproutcoren Ace-teema löytyy vastaavasti vain sprite-kuvina, joten teemaus pitää hoitaa itse loppuun, mutta se tarjoaa kattavamman valikoiman eri komponentteja ja malleja.

Ikävä tosiasia valitettavasti on, että sovelluksen ulkoasun eteen joudutaan aina askartelemaan enemmän tai vähemmän. Esimerkiksi jos sovelluksessa otetaan käyttöön jokin valmis komponentti, pitää sen ulkoasua joko muokata vastaamaan muuta sovellusta, tai käyttää valittua kirjastoa kaikilta osin jokaisen komponentin kanssa, jolloin eroavaisuuksia on mahdollisimman vähän. Valituista ratkaisuista riippuen tämä on enemmän tai vähemmän helppoa. Esimerkiksi JQuery UI:n komponenteille voi määritellä haluamansa ulkoasun kätevästi Theme Rollerin avulla, mutta vastaavasti samanlainen teemanrakentaja tarvittaisiin myös RichFaces-komponenteille, joiden teemaus on suhteellisen työlästä ja osittain arpapeliä. Muutenkin aina tuntuu, että useat valmiit ratkaisut eivät toimi kuten niiden haluaisi toimivan, eikä niitä usein voi myöskään helposti muokata riittävällä tasolla.

Kaikenkaikkiaan Web-käyttöliittymä voi näyttää upealta, jos siihen viitsii panostaa, mutta Web-sovelluksilla ei mielestäni tarvitse olla yhtenäisiä periaatteita. Web on monimuotoinen ja asiat saavat toimia, kuten ne parhaimmikseen näkee, kunhan ne silti toimivat loogisesti ja ymmärrettävästi. Toki yhtenäiset ratkaisut helpottavat käyttäjän elämää. Toisaalta Webin käyttöliittymät eivät helposti vertaudu perinteisiin työpöytäsovelluksiin, ainakaan nykyisillä teknologioilla ennen HTML5:n ja CSS 3:n yleistymistä, joten sallittakoon niille myös omat tyylinsä, kunhan ne ovat hyvällä maulla toteutettuja.

Pitääkin tässä edistää työlistalle hautautunutta tehtävää jalostaa omaa visuaalisesti yksinkertaista komponettiteemaa eteenpäin ja rakentaa vastaava teemaus myös RichFaces-komponenteille, jolloin asiakkaan sovellus saisi vielä nykyistä yhtenäisemmän ulkoasun.

Kumiankka-metodi debuggauksessa

Ohjelmoinnissa koodin kirjoittamisen lisäksi on tärkeää osata debugata koodia, eli selvittää mistä ilmennyt ongelma johtuu ja miten se ratkaistaan. Ongelmanselvitykseen on olemassa erilaisia välineitä, mutta yksinkertaisimmillaan se voi olla esimerkiksi kumiankka, kuten Canterbury Linux User’s Groupin postituslistalla asia ilmaistiin.

Kumiankka-metodi debuggauksessa menee seuraavasti:

  1. Kerjää, lainaa, varasta, osta, valmista tai muuten hanki kumiankka (amme-tyyppiä)
  2. Aseta kumiankka pöydälle ja kerro, että tulet kohta käymään läpi hieman koodia sen kanssa.
  3. Selitä ankalle mitä koodisi pitäisi tehdä ja syvenny yksityiskohtiin kertomalla asiat rivi riviltä.
  4. Jossain vaiheessa tulet kertomaan ankalle mitä teet seuraavaksi ja sitten tajuat, että todellisuudessa se ei ole sitä, mitä oikeasti teet. Ankka istuu seesteisenä, onnellisena siitä tiedosta, että on auttanut sinua.

Toimii joka kerta, ja jos kumiankkaa ei ole saatavilla, voi korvikkeena käyttää myös toista henkilöä, joka istuu vieressäsi ja kuuntelee. Tosin, jos työskentelet avokonttorissa ja selität asioita kumiankalle, kannattaa se tehdä ääneti ajatuksissa, sillä muuten voit saada osaksesi outoja katseita. Englanniksi asia tunnetaan nimellä Rubber Duck Debugging.

Vaadin tarjoaa Swingiä Web-sovellusten kehitykseen

Web-sovellusten kehitys Javalla on täynnä erilaisten frameworkkien kuten Strutsin, Springin ja JSF:n hyödyntämistä, joista jokaisessa on hyvät ja huonot puolensa ja varsinainen toteutus on usein sekoitus HTML-merkkausta ja koodia. Java EE -sovelluskehitystä voi kuitenkin katsella myös hieman erilaisesta näkökulmasta: Suomalainen IT Mill on rakentanut kokonaisuuden nimeltä Vaadin, joka tuo Javan Swing -maailman Web-sovelluksiin. Lopputuloksena on sovelluskehys, jossa HTML:n koodaaminen unohdetaan lähes täysin ja sovellusta toteutetaan samalla periaatteilla kuin työpöytäsovelluksia, joka on kätevää, jos tykkää Java Swing -tyylisestä sovelluskehityksestä.

Vaadinta voi lyhyesti kuvata sanomalla sen olevan Swing-koodausta sekä hyvässä että pahassa. Web-sovelluksen toteutus Vaatimella on suhteellisen helppoa, mutta toisaalta se myös Swingin tapaan rajoittaa käyttöliittymäsuunnittelua. Toteutuksessa HTML:n ja komponenttien säätäminen jää pois, jolloin toteuttajat voivat keskittyä varsinaiseen toimintaan kuuntelijoiden ja tapahtumien parissa. Kokonaisuutena kehitys on tavallaan selkeämpää kuin esimerkiksi JSF:llä, jossa toiminnot hajoavat sekä sivuille että Java-luokkiin ja erilaisia säädettäviä XML:iä on useita. Totuus ei tietenkään ole aivan näin yksinkertaista, mutta melkein.

Sovelluskehityksen osalta Eclipselle on saatavilla WYSIWYG-editori ja sovelluksen debuggaus onnistuu normaalisti debug-moodissa ja käyttöliittymän osalta Firefoxin Firebug-lisäosalla, eli sen osalta ei ole mitään ihmeellistä. Käytettävissä on useita erilaisia komponentteja ja hyvä dokumentointi, joilla toimintoja rakentaa. Tutoriaalien avulla pääsee helposti alkuun ja näkee mistä asiassa on kyse. Vaadin on lisensoitu avoimen lähdekoodin Apache License versio 2.0 -lisenssillä, joten tarvittaessa sen laajentaminen ja bugien korjaaminen on mahdollista. Saatavilla on myös maksullista tukea ja palveluita.

Vaadin perustuu Google Web Toolkitin päälle, jota käytetään selaimelle piirtämiseen ja GWT:hen verrattuna Vaadin-sovellukset pyörivät palvelinpuolella, kun GWT on selainpuolen sovellus. Vaadin-sovellus on paljolti sidottu JavaScriptiin ja siinä on mielestäni myös sen heikoin lenkki, sillä suorituskyvyllisesti käytetty lähestymistapa ei ole kovin tehokas. Etenkin monimutkaisilla käyttöliittymäkomponenteilla ja ulkoasuilla selaimen JavaScript-suorituskyky tulee äkkiä vastaan, vaikkakin tällä saralla on etenkin Googlen Chrome ja Safari kunnostautuneet. Muuten komponentit toimivat hyvin riippumatta käytettävästä selaimesta.

Vaikka Vaadin tavallaan yksinkertaistaa rikkaiden Internet sovellusten (RIA) tekemistä, pidän itse enemmän perinteisestä Java Server Facesiin (JSF) pohjautuvasta Web-kehityksestä. JSF:n kanssa käyttöliittymän koodi on erikseen HTML:ssä, johon on lisätty tarvittavat sidokset ja dynaamisuutta. Tietenkin tässäkin tavassa on omat ongelmansa, etenkin kun JSF 1.2 ja käyttöliittymäkomponentit ovat mitä ovat. Ehkä taustani Web-koodaajana vaikuttaa siihen, että pidän enemmän siitä, että pääsen helpommin näkemään ja säätämään käyttöliittymää HTML-tasolta, eli tekemään juuri sitä, mistä ”perinteiset” Java-koodarit eivät tykkää. Ainakin saan tarkalleen mitä haluan, jos osaan sen HTML:llä, CSS:llä ja käytössä olevilla komponenteilla toteuttaa.

Vaadin on kuitenkin kätevä tapa toteuttaa Web-sovelluksia ja sillä saa kohtalaisen nopeasti aikaan hyvän näköistä jälkeä helposti. Toisaalta kuten kaikissa sovelluskehyksissä, on myös Vaatimessa asioita, jotka aiheuttavat kehittäjälle harmaita hiuksia. Nimi Vaadin tarkoittaa myös naaraspuolista poroa ja sanaa voidaan käyttää esimerkiksi lauseessa ”Vaadin parempia käyttöliittymiä!”.

Näköjään seuraava Vaadin Developer Meetup pidetään 3.12.2009 Pitäjänmäellä Helsingissä Logican tiloissa (ilmoittautuminen 26.11.2009 mennessä).

Esimerkkinä silloin vielä IT Mill Toolkit -nimellä tunnetulla Vaadin-kehyksellä hahmoteltu sähköpostisovellus:

iMail iMail