Varför jag gillar Grails

Jag har utvecklat webb-applikationer i Grails sedan 2007, efter det att jag först bekantat mig med Groovy tidigare det året.

Språket Groovy såg dagens ljus redan i augusti 2003, då James Strachan skickade ut ett meddelande (nästan lika legendariskt som det Linus Torvalds skickade ut i början på 90-talet - men då alltså om Linux) om att han börjat vidareutveckla språket Java, genom att skapa det dynamiska JVM språket Groovy.

Grails började utvecklas en bit före 2007 (av Graeme Rocher) och hade då namnet "Groovy on Rails", vilket klart signalerade att det var en rip-off av Ruby on Rails. Efter att några jurister dykt upp med verbala påkar, ändrades namnet till kort och gott Grails. Logotypen för också tanken till the quest for the Holy Grail.

Tidigare, hade jag byggt webb-applikationer i Java m.h.a. ramverk, som Struts, WebWork och Spring-MVC. De hade alla det gemensamt att det var mycket att konfigurera. Centrala delar av applikationens arkitektur skrevs i diverse XML filer. Databas-lagret hanterades av Hibernate eller (Gud förbjude) Entity EJBs. Dessutom var man helt beroende av generator-verktyg som XDoclet, för att inte drunkna i allt manuellt arbete conf/xml skrivande.

Grails ändrade helt på allt detta genom principen on configuration by convention.

Domänklasser och databaser

Skriver man en GroovyBean klass (t.ex. Person.groovy) och placerar den i katalogen grails-app/domain, så är allt som har med konfigurering av DB persistens klart!

Grails hanterar via Spring Framework och Hibernate alla kopplingar och konfigureringar helt utan att man behöver lägga sig i. Man kan dock tweaka varje aspekt om det behövs, för att t.ex. anpassa sig till legacy data.

Webbaktioner

Skapar man en klass med ett gäng metoder (t.ex. PersonController.groovy) och lägger klassen i katalogen grails-app/controllers, så har man en färdig webb-tjänst för URI:er liknande denna

http://myhost/myapp/person/show/17

Fragmentet /person/ pekar ut PersonController och fragmentet show pekar ut action-metoden med samma namn i just den klassen, samt 17 anger DB id for person-objektet i fråga.

GSP - Groovy Server Pages

Webb-vyer skriver man i GSP, som är samma ide som JSP, men med Groovy i stället. Det innebär att man primärt skriver HTML assisterad av ett rik flora av taglibs. Här och där spränger man in Groovy uttryck som hämtar ut data från olika GroovyBeans.

Så här hänger det ihop: Antag att URI:n ovan anropas. Först selekteras kontrollern Person varpå anropas aktionmetoden show() där parametern params.id har värdet 17. Metoden show() hämtar upp person-objektet från databasen på följande enkla sätt:

def thePersonFound = Person.get(params.id)

Metoden show() förväntas sedan returnera en map med dataobjekt som ska exponeras (t.ex. [bean:thePersonFound]. Eftersom aktionmetoden heter show, så anropas motsvarande GSP i katalogen views/person/show.gsp, som genererar HTML och skickar (via SiteMesh - se nedan) detta till webbläsaren.

Antag att person-klassen innehåller bl.a. property:n String name, då går det att söka via namnet

def p = Person.findByName('Anna Conda')

eller

def p = Person.findByNameLike('Ann%')

Detta är så kallade dynamiska finders och genereras automatiskt baserat på vilka properties som finns deklarerade i domänklassen. Det finns också en hel del andra sätt att söka på och sammanställa databas-information.

Egna taglibs

På liknande sätt som ovan, så skapar man lekande lätt egna taglibs genom att skriva en klass (t.ex. UtilsTagLib.groovy) och placera denna i katalogen grails-app/taglib. Varje metod blir en tag som kan användas på en GSP-sida.

Sidlayoter

Layout för en hel webbsida hanteras (bakom kulisserna) av SiteMesh. Som Grails programmerare behöver man bara fixa till en GSP sida med övergripande layout för webbplatsen och markera ut var innehållet (content) ska petas in. Det innebär att genererad  HTML från en vy strippas på HEAD sektionen och innehållet innanför BODY taggen substitueras in på rätt plats i layout GSP:n och resultatet skickas till webbläsaren.

Transaktionella tjänsteobjekt

Skapar man en klass (t.ex. BusinessService.groovy) innehållande deklarationen

static transactional = true

samt placerar klassen i katalogen grails-app/services, så vips har man ett transaktionellt tjänsteobjekt, som bakom kulisserna använder Springs transactional-service och transaktion-hanteringen hos databasen.

Detta innebär bl.a. att om en av metoderna kastar ett undantag (runtime exception) så görs det en roll-back på transaktionen. Vidare, så propageras aktuell transaktion om den transaktionella tjänstemetoden anropar andra tjänstemetoder i samma eller andra tjänsteobjekt.

Och mer där till...

Så här kan jag hålla på och rada upp fördelar/egenskaper, såsom att det finns mycket bra stöd för AJAX-anrop, att det är mycket enkelt att skapa REST baserade webbtjänster, o.s.v.

Det är enkelt att konfigurera stöd för 2nd-level cache och olika typer av databaser som MySQL, Oracle, PostgreSQL, MS SQL-Server etc. Det finns också stöd för ett flertal NoSQL databaser, såsom MongoDB, SimpleDB, Redis, CouchDB med flera.

Grails är rent tekniskt ett plugin-ramverk, vilket innebär att alla system-tjänster är plugins. Gillar man inte Tomcat eller Hibernate, så går de att byta ut. Det finns idag ett mycket stort utbud av Grails-plugins, som gör att arbetet går ännu snabbare, eftersom många gånger hittar man en plugin, som redan implementerar det man hade tänkt sig att göra själv.

Mitt senaste Grails projekt

När jag inte undervisar för Informator (i ämnen såsom Groovy&Grails, Android, C++, Erlang, Linux, Cloud Computing, ...), så är jag CTO och lead-architect för en startup, där vi byggt en SaaS applikation i Groovy och Grails, samt driftsatt den i Amazon AWS molnet. Är du nyfiken på vad det är så kollar du in webbplatsen ProposalsFactory.

Mer om Groovy

Den 21 februari håller jag ett frukost-seminarium om Groovy och GPars. Med GPars biblioteket kan man skriva applikationer, vilka enkelt och bekvämt utnyttjar moderna datorers förmåga att exekvera många aktiviteter parallellt (multi-cpu/core/threading).
Läs hela agendan och anmäl dig här


Blev du nyfiken på Groovy och Grails, så kör jag också kursen Webbapplikationer med Groovy och Grails, för Informator under våren.

Läs mer

Varför jag gillar språket Groovy

Programspråket Groovy kan (lite löst) uttryckas som Java++, dvs en naturlig utvidgning av Java syntaxen för att kortare och bättre lösa ett programmeringstekniskt problem.

Groovy är mitt favoritspråk, eftersom jag kan skriva Java program, som är korta och begripliga utan att förvilla mig i en massa syntaktisk jox. Så låt mig få visa ett konkret exempel på hur det går att korta ned ett Java program till ett mycket kortare Groovy program.

En kopp Java att starta med

Följande Java program hämtar en XML fil (från Brottplatskartan) med de senaste rapporterade brotten/olyckorna och listar trafikolyckorna i kronologisk ordning.

Programkoden i Java är på 150 rader och GitHub gist:en nedan visar både kod och utdata:


Så här kompilerar och exekverar du Java programmet:

Yes> javac -d target/classes src/java/CrimesList.java
Yes> java -cp target/classes CrimesList

Lite mysigare med Groovy

I första steget byter jag namn på filen, så att filändelsen är *.groovy, samt kapar bort en del överflödigt Java jox.

Inga semi-kolon

Vi behöver inte semikolon, så bort med dem i slutet av varje programrad.

GroovyBeans

Det finns en inre JavaBean klass, som vi direkt kan göra om till en GroovyBean i stället. Vi behöver inte getters och setters, eftersom Groovy tillhandahåller dem för oss (kompilerade), om vi deklarerar data-innehållet som properties. Standard metoder som toString(), equals(), hashCode() låter vi kompilatorn generera via annoteringar. Vi utnyttjar också att Java-klassen Date har nya metoder, såsom parse() och passar på att använda spaceship-operatorn (<=>) för att köra compareTo() metoden. Detta gjorde att en JavaBean på nästan 90 rader kan kapas ned till 20 rader. Inte illa!

Lite mer finlir

I huvud-metoden main() gör jag bara några mindre justeringar, vad beträffar utskrifter och en liten closure-loop istf for-each dito.

Ett första resultat

Så här ser Groovy klassen ut (med utdata) och den består av endast 80 rader.


Så här kompilerar och exekverar du Groovy programmet:

Yes> groovy src/groovy/CrimesList_shorter.groovy

Ännu mysigare Groovy

Men, det finns mer 'Java-jox' att kapa bort.

Groovy-Script

I Java måste ju all kod vara innesluten i en klass. I Groovy kan vi använda skript i stället. Så, bort med den omgivande applikations-klassen. Jag flyttar också omkring lite kod, så att koden i main() hamnar längsdt ned och Crime-bönan hamnar överst.

Bort med onödiga konstruktorer

Vad ska man med en konstruktor till egentligen? Groovy ger alla klasser utan konstruktor en speciell konstruktor, som tar namn-givna parametrar. Mycket tydligare, än parameter-positionen.

new Crime(title: e.title.text(), date: Date.parse('yyyy-MM-dd HH:mm:ss', e.date.text()), place: e.place.text(), description: e.text.text())

Mer Groovy

I det andra steget tar jag bort alla return-uttryck och använder mig av Groovy closures överallt där det tidigare fanns loopar.

Groovy XML-Parser

Slutligen, strutar jag i att använda Java's XML-DOM parser och kör med Groovy's egen som har en del finesser. Först, hämtar jag data och bygger upp ett XML träd.

new XmlParser().parse(url)

Från detta träd av XML noder, filtrerar jag ut alla 'event' noder, som en lista.

new XmlParser().parse(url).event

Denna node-lista bygger jag sedan om, så att varje node blir ett Crime objekt i stället.

new XmlParser().parse(url).event.collect {e -> new Crime(...)}

Slut-resultatet

Så, jag började med en Java klass på 150 rader och slutar här nedan med ett Groovy-script på blott 30 rader. Visst är det mysigt?


Så här kompilerar och exekverar du Groovy programmet:

Yes> groovy src/groovy/CrimesList_shortest.groovy

PS

Tråkigt nog, hann det inträffa några fler trafik-olyckor mellan att jag körde Java programmet och Groovy programmen.

Läs mer

Liten kurs i kompetensstrategi – del 3

Välkomna till tredje och sista delen i ”kursen”. I detta inlägg bockar vi av den sista punkten på listan och knyter ihop säcken. 

1. Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?
2. Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?
3. Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?
4. Varför är det inte fler organisationer som mäter och följer upp värdet av utbildningsinsatser?
5. Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?

5. Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?
Vi har konstaterat att det finns goda skäl att kombinera olika utbildningsmetoder för att nå bästa utbildningseffekt. Såväl pedagogiska som ekonomiska. På motsvarande sätt känns det uppenbart att en utbildning bör kombineras med praktisk tillämpning för att få bästa effekt. Varför är det då inte fler organisationer som väver samman praktiskt arbete med en utbildning? Jag tror det hänger ihop med det vi lärt oss från barnsben. I skolan lär man sig och på arbetsplatsen arbetar man. För femtio år sedan kanske det resonemanget höll men knappast idag. I dagens kunskapssamhälle behöver både organisationer och dess anställda utbilda sig kontinuerligt, och ibland omskola sig helt, för att möta en värld i allt snabbare förändring. Av ekonomiska och praktiska skäl behöver en större del av utbildningen ske på arbetsplatsen och vävas ihop med de dagliga arbetsuppgifterna.
Vad ska man göra då?
Grunden är att ta fram en kompetensstrategi och tillhörande plan, dvs tänka till kring vilka kompetenser organisationen behöver och se till att det finns en plan för realisering. Det bör vara tydligt i planen hur kompetensbehoven är kopplade till organisationens operativa behov. Vi tar ett exempel. 
Om behovet är att bli  bättre på leverantörsuppföljning så bör utbildningsinsatsen kopplas till faktiska förbättringsbehov inom just det området, t.ex. att i samband med utbildningsinsatsen ta fram mätetal och rapporter som är relevanta för den specifika organisationens leverantörsuppföljning. 
Detta är relativt enkelt att åstadkomma om utbildningsinsatsen är skräddarsydd för den egna organisationen men går även att åstadkomma vid punktinsatser för en anställd. Oavsett om utbildningen är för en intern gruppering eller enskild person krävs ofta uppföljning och stöd för att säkerställa att det faktiska värdet realiseras. Detta stöd kan vara svårt att åstadkomma internt och då kan det vara en bra investering att komplettera utbildningsinsatsen med konsult/mentor-stöd.
Sammanfattningsvis kan vi konstatera att en kombination av utbildningsinsats och praktik i den egna organisationen slår två flugor i en smäll. Dels värdeskapande arbete för organisationen men även förstärkt lärande genom att teorin får praktiseras – en av grundpelarna för ett långsiktigt lärande.
Med det sagt är mini-kursen avklarad. Jag hoppas att du har fått ut något av den och att den sått ett frö till en mer genomtänkt utbildningsstrategi.
Du får jättegärna höra av dig med  dina synpunkter och erfarenheter. Var inte rädd för att ifrågasätta eller argumentera. Det är så vi lär oss ännu mer!

Jag nås lättast på ola.kallgarden@olingo.se men det går naturligtvis även att kommentera på bloggen!  

Läs mer

Liten kurs i kompetensstrategi - del 2

Välkomna till andra delen i ”kursen”. I första delen klarade vi av de två första frågeställningarna och i denna del ska vi ta oss an ytterligare två.
  

1.       Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?

2.       Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?

3.       Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?

4.       Varför är det inte fler organisationer som mäter och följer upp värdet av utbildningsinsatser?

5.       Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?

3. Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?

Det finns olika sätt att ta till sig kunskap. På individnivå föredrar vi olika typer av inlärningsstilar som t.ex. auditiv, kinestetisk samt visuell. Olika inlärningsstilar kan kopplas till olika utbildningsmetoder. Detta har det forskats en hel del kring. Om man generaliserar forskningen en aning kan man konstatera att man gör bäst i att kombinera olika utbildningsmetoder.  Tydligt från forskningen är även att den bästa inlärningseffekten uppnås om eleven får chansen att praktisera teorin.  
Med dagens pedagogiska kunskap och tekniska förutsättningar finns det inga teoretiska gränser för vad som går att åstadkomma i utbildningsväg. Det är fantasin och plånboken som sätter gränserna. Och vanan. Jag vågar påstå att det är vanan som gör att de flesta organisationer lägger en betydligt större del av utbildningsbudgeten på klassiska kurser än alternativa utbildningsmetoder. Det känns tryggast så.  
Vad ska man göra då?
 Till att börja med ska man ta fram en utbildningsstrategi och tillhörande kompetensplan (se del 1).  Utifrån de identifierade kompetensbehoven ska man se över de utbildningsalternativ som marknaden erbjuder. Både på grupp- och individnivå. Det troliga är att en mix av utbildningsmetoder ger den bästa effekten. Se över hur klassiska kurser kan varvas med andra metoder och medier. Se till att inte missa praktiserandet. Våga testa simuleringar, e-learning och scenariobaserade övningar.
Kurser kan även kombineras med expertstöd så att kompetensutveckling kan kombineras med värdeskapande aktiviteter på hemmaplan (se mer på punkt 5 i nästa inlägg).    

4. Varför är det inte fler organisationer som mäter och följer upp värdet av utbildningsinsatser?

Om man nu lägger ner en ansenlig mängd pengar på att utbilda sin organisation, är det då inte rimligt att följa upp värdet? Självklart borde man det. Problemet är att det är svårt att på ett objektivt sätt följa upp utbildningsinsatser.
Vad ska man göra då?
Det bästa är att använda sig av en etablerad modell som t.ex. Kirkpatrick. På det sättet får man åtminstone någonting att hålla sig i vid uppföljningen. Kirkpatrick delar in uppföljningen i fyra delar:

·         Reaktion – Individens subjektiva reaktion till utbildningsinsatsen

·         Lärande – Mätbart resultat för individen, t.ex. testresultat och certifieringar

·         Beteende – Hur har utbildningen förändrat individens och/eller gruppens beteende

·         Resultat – Hur har förändringen i beteende hos individ och grupp påverkat organisationens resultat

De första två delarna, reaktion och lärande, är lätta att mäta med hjälp av enkäter och tester. De två sistnämnda är betydligt svårare men Kirkpatrick ger en del tips på hur man kan gå tillväga.

Så ja, då var del 2 avklarad. I nästa inlägg knyter jag ihop säcken!

Liten kurs i kompetensstrategi - del 1

Läs mer

Liten kurs i kompetensstrategi - del 1

I förra inlägget påstod jag att många IT-organisationer saknar en tydlig kompetensstrategi och/eller plan för att säkerställa rätt kompetens.  Sammanfattningsvis ställde jag följande frågor:

1.       Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?

2.       Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?

3.       Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?

4.       Varför är det inte fler organisationer som mäter och följer upp värdet av utbildningsinsatser?

5.       Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?

För mig är det lite obegripligt att det ser ut som det gör eftersom det inte är så svårt att få till. Faktiskt.
Jag vill även vara tydlig med att det självklart finns organisationer som har en strategisk, men ändå pragmatisk, syn på kompetensutveckling. Jag tänkte dela med mig av erfarenheter från dessa organisationer och samtidigt bemöta frågorna ovan. Det blir totalt tre delar som blir utspridda över veckan som kommer.

1.       Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?

Det finns flera anledningar och ursäkter. Den vanligaste anledningen är att många IT-organisationer har en otydlig bild av framtida kundkrav, samt genomgår så mycket förändringar, att man inte kan eller orkar ta tag i kompetensplaneringen. De nuvarande behoven vill man inte få konkretiserade eftersom det finns risk att de förtydligar att man sitter med fel kompetens. Man ställs då inför en jobbig situation att byta ut personal och/eller göra en kompetensomläggning modell större. Då kan det vara skönare, åtminstone på kort sikt, att sticka huvudet i sanden.  Ungefär som att kissa i byxorna.
Vad ska man då göra?
Framför allt gäller det för IT att förstå sin roll i företagets, eller kundens, utveckling. Hur ser strategin ut för företaget/kunden och vilken position har IT-organisationen i företaget som helhet? Det är självklart även viktigt för IT att hålla sig uppdaterad kring nymodigheter i IT-världen så att man ligger steget före och kan föreslå nya och bättre tjänster. Helst innan kunden själv föreslår det. Det var inte mycket snack om molntjänster för tio år sedan…
Ett steg i att bättre förstå de nuvarande behoven är att först skaffa sig en tydlig bild av vilka IT-tjänster man faktiskt levererar. Det kan tyckas självklart men det är häpnadsväckande många IT-organisationer som fortfarande inte har en tydlig bild av sin egen tjänsteleverans. När man vet vilka tjänster som levereras är det lättare att koppla dessa till leveransprocesser och kompetensbehov.  

2.       Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?

Den elaka gissningen är att man är rädd för att få reda på hur det verkligen ligger till. Den lite mindre elaka gissningen är att man tror sig ha ”rätt bra koll” på vad personalen kan. En tredje gissning är att det saknas en effektiv process för att hålla informationen uppdaterad.  Vad ska man då göra?
Man ska se till att ha en fungerande process och verktyg för att dokumentera kompetens. De flesta organisationer har mer eller mindre utnyttjade verktyg för detta (kolla med HR!). Oftast är dessa ganska enkla och möjliggör för den anställde och/eller chefen att fylla i enskilda individers kompetensnivåer inom ett antal områden. Nyckeln är förstås att identifiera och sätta upp de områden som kompetensnivån ska jämföras emot, samt ha en tydlig process för när och hur kompetensen ska dokumenteras.
För de områden där den egna personalen saknar nödvändig kompetens får man ta sig en funderare. Kan denna kompetens enkelt ”sourcas” från annat håll, t.ex. underleverantörer eller konsulter? Om svaret är nej får man överväga rekrytering som alternativ till att utbilda den egna personalen. Även denna typ av information bör ingå i kunskapsinventeringen.

Det var allt för det här inlägget. Nu kan du gå vidare till del 2!

Liten kurs i kompetensstrategi - del 2

Läs mer

Kunskapssamhälle utan utbildningsstrategi

Det finns inte en IT-organisation i Sverige som skulle påstå att kompetens är oviktigt. Hur kommer det sig då att de flesta av Sveriges IT-organisationer, både privata och offentliga, saknar både strategi och plan för kompetensutveckling?

Mönstret upprepar sig i så gott som samtliga organisationer jag möter: två varianter av utbildning. Den ena på individnivå där varje anställd får löfte om att gå en eller flera kurser. Oftast fastslagna i ett utvecklingssamtal i början av året. Inte sällan baserat på den anställdes önskan om att få gå en viss utbildning, snarare än kopplat till organisationens faktiska behov.

Den andra varianten är på organisationsnivå där en hel grupp, ibland en hel avdelning, får gå en viss kurs.

Båda dessa varianter är punktinsatser och risken är stor att utbildningsinvesteringen är bortkastad om det inte finns en tydlig plan för att omvandla utbildningsinsatsen till värdeskapande insatser i det dagliga arbetet.

• Varför är det inte fler organisationer som har en tydlig bild av nuvarande och framtida kompetensbehov?
• Varför är det inte fler organisationer som har en uppdaterad kompetensinventering?
• Varför är det inte fler organisationer som kombinerar olika typer av utbildningsmetoder?
• Varför är det inte fler organisationer som ser mäter och följer upp värdet av utbildningsinsatser?
• Varför är det inte fler organisationer som ser till att kombinera kompetenshöjning med värdeskapande insatser på hemmaplan?

Många frågor i det här inlägget. I mitt nästa inlägg tänker jag bemöta några av dessa genom att beskriva ett alternativ till den förlegade utbildningsdogm som, enligt mig, fortfarande råder.          

Läs mer

Nyheterna i Groovy

Efter nyåret släpptes lanseringskandidaten av Groovy 2.1 och går allt vägen, så har vi den skarpa versionen i slutet av januari. Groovy 2.x bjuder på många nyheter och förbättrar språket både vad gäller funktionalitet och prestanda.

Men hallå! Vad är Groovy?

Enkelt uttryckt är det Java++, en bättre variant av Java helt enkelt. Ungefär som C++ är en bättre variant av C. Det går att blanda Java och Groovy hur enkelt som helst. Tack vare den familjära syntaxen går rekord-snabbt för en Java programmerare att börja använda Groovy och det är mycket enkelt att smyga in lite Groovy här och där i en befintlig Java applikation.

Språket Groovy genomgår just nu en mycket intressant vidare-utveckling, som började för lite drygt ett och ett halvt år sedan med version 1.8. Denna version var knökfull av nya egenskaper och när språkets utvecklingsteam planerade för version 1.9 insåg de vad de borde ha gjort redan för version 1.8, nämligen att börja på nästa major version, dvs 2.x. Så 1.9 blev helt sonika omdöpt till 2.0 och på den vägen är det.

AST Annotations

Den mest iögonfallande nyheten i version 1.8 var möjligheten att generera ny kompilerad kod i samband med att ett Groovy program startar. Detta kallas för AST Transformations, där AST betyder Abstract Syntax Tree. I (mycket) korta drag så när ett Groovy program laddas för exekvering, så kompileras det först till Java byte-code. Under denna process så byggs det upp en intern trädrepresentation av programkoden (AST), som i flera olika steg transformeras.

Med AST-T kan man lägga till egna transformationer, dvs dynamiskt skapa ny kod, som kommer med i kompileringen. Nu är detta inget man gör i den dagliga programmeringen, utan man använder färdiga transformationer, som finns tillgängliga i form av kod-annoteringar. Genom att applicera en eller flera AST annoteringar, så utökas en Groovy klass med kompilerad kod. Låt oss kika på några exempel, intressanta för varje Java programmerare.

@ToString

Hur många gånger har man inte "mekaniskt" skrivit en toString() method i Java och för varje klass-ändring så måste denna uppdateras eller genereras på nytt. Det finns alternativ; såsom Jakarta Commons Lang ToStringBuilder, som dynamiskt (reflektivt) skapar output. Emellertid, om du använder Groovy i stället, så räcker det med att annotera din klass med @ToString, så är saken biff.

import groovy.transform.*
@ToString class Person {
    String first, last
    int age
}

def p1 = new Person(first:'Anna', last:'Conda', age:17)
println "p1 = ${p1}"

Vilket ger utskriften

p1 = Person(Anna, Conda, 17)

Vill man se attributnamnen också, lägger man till @ToString(includeNames=true) och utskriften blir i stället

p = Person(first:Anna, last:Conda, age:17)

@EqualsAndHashCode

En annan trist uppgift i Java, är att underhålla metoderna hashCode() och equals(). De behöver implementeras båda två och är viktiga för att ens objekt ska kunna förekomma i olika typer av list:or och map:ar. Med Groovy, så lägger du bara till @EqualsAndHashCode och kan gå vidare med mer intressant programmeringsuppgifter. Så här kan det se ut

import groovy.transform.*
@ToString(includeNames=true) 
@EqualsAndHashCode
class Person {
    String first, last
    int age
}
//...
def p2 = new Person(first:'Per', last:'Silja')
def p3 = new Person(first:'Per', last:'Silja')

assert p2 == p3
assert p1 != p3
assert p2.hashCode() == p3.hashCode()

@Log4j

Loggning är ett annat område av rutin-programmering och innebär att man typiskt i en konstruktor skapar ett log objekt, lite olika beroende på om man använder Log4J, Commons-Logging, SLF4J eller java.util.logging. Varför inte låta en annotering sköta om detta i stället. Här ett exempel för Log4J.

@Log4j class Controller {
    Controller() {
        log.debug("Created");
    }
    void doit() {
        log.info("Calling doit()");
        //...
    }
}

Och så vidare...

Det finns många fler AST annoteringar, såsom @AutoExternalizable som bygger writeExternal() och readExternal() method i gränssnittet Externalizable (vanlig optimering), @Immutable som gör en klass read-only, @Singleton som implementerar singleton-mönstret, och mång fler.

Exkvera snabbare

Det hur många som helst andra nyheter i Groovy från versionerna 1.8, 2.0 och 2.1, men jag tänkte uppehålla mig kring området prestanda. Groovy är ju ett dynamiskt programspråk, med bl.a. s.k. duck-typing. Det här innebär att en hel del kontroller och omvandlingar sker under exekveringen, vilket ibland tar lite för lång tid. Därför har prestanda-förbättringar av språket varit högt prioriterat av användarna. Det finns två parallella spår för att möta detta.
Det första spåret är att ge programmeraren mer kontroll över var kompilatorn kan generera byte-code, som har samma prestanda som motsvarande Java-kod. Det här görs med annoteringar.

@CompileStatic

Med annoteringen @CompileStatic markerar man att en metod eller klass inte behöver det "dynamiska" stödet utan resultatet blir Java-style byte-code.

@TypeChecked

Med annoteringen @TypeChecked markerar man att en metod eller klass ska kompileras med statisk typ-kontroll, vilket innebär att problem som kanske dyker upp först under exekveringen kan hittas redan vid kompileringen.
Med båda dessa annoteringar, så har man det bästa från två världar Java statiska typ-kontroll och prestanda, samt Groovy's dynamiska beteende där man behöver det.

Invoke Dynamic

Det andra spåret är att använda det nya stödet i Java 7 för dynamiska språk (byte-code instruktionen invokeDynamic). Detta arbete påbörjades redan i Groovy 2.0, men väntas vara mer genomarbetat och tillgängligt i nya versionen 2.1.
I korta drag, så exekverar man ett Groovy program med den nya switchen --indy och ser till att Groovy använder Java 7 i botten.

groovy --indy myCoolApp.groovy

Mer om Groovy

Vecka 5

Under vecka 5 kommer jag tillbaka och bloggar hela veckan om Groovy relaterade saker.

Concurrency for the Modern Age

Om du inte har fått nog efter den veckan, så kommer jag att hålla ett frukost-seminarium den 21 februari om hur man med Groovy och GPars biblioteket kan skriva applikationer, som enkelt och bekvämt utnyttjar moderna datorers förmåga att exekver många aktiviteter parallellt (multi-cpu/core/threading).

Läs hela agendan och anmäl dig här

Läs mer

Skillnaderna mellan SkyDrive och SkyDrive Pro

Microsofts onlinelagringsplats för filer heter ju SkyDrive nu när SharePoint 2013 lanseras så dyker även en till produkt med namnet SkyDrive Pro upp. Vad är det för skillnad mellan dessa? Vi går igenom detta här nedan:

Vad är SkyDrive?

SkyDrive är en lagringsplats i molnet som gör det möjligt för dig att lagra filer och komma åt dem via olika enheter. SkyDrive är gratis och tillgängligt för dig som har ett Microsoftkonto (Live, Hotmail etc.). Känner du till Dropbox så är SkyDrive en liknande produkt. I nya Office (2013) så logger du in med ditt Microsoftkonto och kommer enkelt åt dina personliga dokument I SkyDrive.

Via SkyDrive kan du även dela filer med andra.

Vad är SkyDrive Pro?

SkyDrive Pro är en dokumentlagringstjänst som också ger möjlighet att synkronisera dokument men är avsett främst för företag. För Office 365 användare så kommer kopplingen till SkyDrive pro att göra att du kan synkronisera utvalda filer i SharePoint lokalt och därmed få tillgång till dem via olika enheter som Windows Phone, Windows 8 platter och inom en snar framtid även IOS, dvs iPhone eller iPad etc. SkyDrive Pro synkroniserar automatiskt filerna när du är online.

När SkyDrive Pro är uppsatt så fungerar denna produkt även hos företag med egna servrar i den utsträckning som företaget valt.

Så vad händer med SharePoint Workspace?

SharePoint Workspace är ju den product som i Office 2010 hanterade offlinesynkronisering. Från och med Office/SharePoint 2013 så ersätts SharePoint Workspace av SkyDrive Pro och är nu den funktion som hanterar offline synkronisering. De företag som eventuellt använder andra delar av SharePoint Workspace kan köra 2010 versionen i SharePoint 2013.

Hur mycket lagring erbjuder SkyDrive Pro?

Med Office 365 eller SharePoint online så får varje användare 7GB allokerat. I företagsuppsatta versioner av SharePoint 2013 så anges denna datamängd av administratören.

Vem har tillgång till SkyDrive Pro?

I de flesta versioner av Office 2013 och Office 365 så ingår SkyDrive Pro.

SkyDrive Pro är normalt sett anslutet till din personliga lagringsplats i SharePoint men du kan välja att ansluta andra bibliotek i organisationen till din SkyDrive Pro om du har tillräckliga rättigheter. Om ditt företag har egna SharePointservrar så kan SkyDrive Pro sättas upp enligt företagets möjligheter och övriga struktur.

Läs mer