Javatankar

Wikipedias nersläckning och risken med klientkod

2012-01-18T10:05:00.000+01:00

Idag är engelska wikipedia nerstängd i protest mot ett par amerikanska lagförslag. Sättet de släckt ner på påminner mig om riskerna med klientkod - kod som körs på klientsidan riskerar i princip alltid att manipuleras. Jag noterade att orginalsidan snabbt blinkar till innan den blockeras av meddelandet om nedstängning. En snabb undersökning av sidans struktur visar att det wikipedia har gjort är att sätta synlighetsegenskapen hos innehållet till osynligt. Den som vill se innehåller kan välja att modifiera denna egenskap till att den skall visas. Detta kan till exempel göras genom att exekvera javascript i addressfältet (en relativt okänd möjlighet) enligt nedan:

javascript:alert(content.style.setProperty("display", "inline"));

Det första javascript: som kommer först talar om att det är javascript som följer (jämför med http: etc), sedan använder jag ett anrop till alert() för att förhindra att resultatet av körningen visas i en ny sida vilket skulle motverka syftet. Sist sätter jag om synlighetsegenskapen till inline, och voila!

Jag surfar med Safari där jag testat skriptet. Samma teknik funkar i andra browsers också, men det kan skilja i detaljer. Kommentera gärna vilka andra browsers det fungerar på.

Trådar utan trassel i Swing

2012-01-11T17:20:00.001+01:00

Något som trots sin enkelhet tog mig många år att förstå är trådmodellen i javas grafiska gränssnitt AWT (uttalas swing). Det var inte förrän jag läste en bok trådning, Java Concurrency in Practice, som poletten trillade ner. Det hela är (på något plan) väldigt enkelt - swing är singeltrådat och körs i en enda tråd som vi kallar swing-tråden. Detta innebär i sin tur att vi kan fastställa ett par enkla levnadsregler för att du ska slippa trådningsbuggar i ditt användargränssnitt:

Inga klasser i swing är trådsäkra om det inte uttryckligen står annat i dess javadoc (men det gör det troligtvis inte).
Kod i metoder som triggas av händelser i gränssnittet körs i swing-tråden och kan därmed interagera med swing utan risk för trådningsproblematik.
All annan kod som interagerar med swing skall exekveras i swing-tråden, vilket med fördel görs av en Runnable med hjälp av SwingUtilities.invokeAndWait() eller SwingUtilities.invokeLater().

Vill du dessutom undvika att göra gränssnittet slött eller apatiskt till och från så bör du köra alla icke-triviala uppgifter i någon annan tråd än swing-tråden, eftersom swing kommer att vänta på att den senare blir ledig igen innan det kan rita om eller reagera på stimuli från användaren.

Lycka till, och kom ihåg var du hörde det först!

Enhetstestning med attrapper

2012-01-10T09:14:00.001+01:00

En attrapp (mock) är enligt ordboken ett objekt som är konstruerat för att se ut som ett annat objekt, utan att för den skull ha några utav dess egenskaper. Exempel från IRL kan vara en mobilattrapp i telebutiken, en vette vid andjakt eller en uppblåsbar pansarvagn i krig. Det de alla har gemensamt är att de är enklare och billigare att producera än den äkta varan, och det är precis dessa egenskaper vi är ute efter när vi använder attrapper i enhetstester: Istället för att själva subklassa de perifera klasserna till önskat beteende så låter vi ett attrappramverk generera dem "i förbifarten". Mitt självklara val av ramverk är sedan några år tillbaka Mockito.

Attrapper används för att interagera med den testade klassen. Dels kan de prepareras för att svara på ett förutbestämt sätt när de anropas, dels används de för att verifiera de blir anropade på ett enligt testfallet väntat sätt.

I koden nedan visar jag ett mycket enkelt exempel på hur en attrapp kan användas för att testa den adapter jag skrev om igår. I koden skapas attrappen med ett anrop till Mockito.mock och efter att den testade klassen anropats verifieras att attrappen stimulerades på väntat sätt med hjälp av Mockito.verify.


import org.mockito.Mockito;
import org.testng.annotations.Test;
import javax.swing.JTextArea;

@Test
public class OutputStreamAdapterTest
{
    public void testFlush()
    {
        JTextArea textArea = Mockito.mock(JTextArea.class);
        new OutputStreamAdapter(textArea).flush();
        Mockito.verify(textArea).repaint();
    }

    public void testWriteChar()
    {
        JTextArea textArea = Mockito.mock(JTextArea.class);
        new OutputStreamAdapter(textArea).write('a');
        Mockito.verify(textArea).append("a");
    }

    public void testWriteString()
    {
        String str = "Hello, World!";
        JTextArea textArea = Mockito.mock(JTextArea.class);
        new OutputStreamAdapter(textArea).write(str.getBytes());
        Mockito.verify(textArea).append(str);
    }
}

Designmönster: Adapter

2012-01-09T10:58:00.000+01:00

Ett designmönster som är både kraftfullt och enkelt är adaptermönstret. Det går precis som det låter ut på att anpassa ett objekt så att det passar ihop med ett annat objekt. Tänk på en sådan där reseadapter du har när du är ute och åker som gör att din mobilladdare passar i eluttaget i Storbritannien, så har du en bra bild av vad adaptermönstret går ut på. Ibland tänker man sig att adaptern kapslar in den anpassade klassen och kaller den då istället för "wrapper". Personligen tycker jag "adapter" är ett bättre och tydligare namn.

För ett par dagar sedan behövde jag skriva information till en textruta i ett grafiskt användargränssnitt. Komponenterna som skrev informationen skrev till den vanliga utströmmen System.out. Jag skrev då en adapter som anpassade textrutan till OutputStreams gränssnitt, varpå jag kunde koppla ihop den med en PrintStream dit den vanliga utströmmen kunde styras om med hjälp av anropet

System.setOut(new PrintStream(new OutputStreamAdapter(messageArea),
                              true /* autoflush enabled */));

Koden för adaptern såg ut som följer:


import javax.swing.JTextArea;
import java.io.OutputStream;

/**
 * Adapts the text area to emulate an output stream reader.
 */
class OutputStreamAdapter extends OutputStream
{
    private final JTextArea textArea;

    public OutputStreamAdapter(JTextArea out) 
    {
        this.textArea = out;
    }

    @Override public void write(int i) 
    {
        textArea.append(String.valueOf((char) i));
    }

    @Override public void write(byte[] bytes) 
    {
        textArea.append(new String(bytes));
    }

    @Override public void flush() 
    {
        // Instead of flushing, force repaint
        textArea.repaint();
    }

    @Override public void close() { }
}

Ordning i Google Guava

2012-01-04T20:26:00.000+01:00

Ett klassbibliotek som ligger mig varmt om hjärtat är Google Guava. Det innehåller en hel del smått och gott och är utmärkt komplement till Javas API när du bygger en icke-trivial applikation. Jag kommer med jämna mellanrum publicera små godbitar för att sprida kunskapen om (och förhoppningsvis användningen av) detta bibliotek. Först ut blir klassen för ordning, com.google.common.collect.Ordering:

Klassen Ordering är en utökning av Comparable och representerar ordning och de operationer som hör ihop med detta begrepp. En mängd färdiga ordningar finns, exempelvis den naturliga, en explicit (partiell) ordning, och en godtycklig ordning som är konsistent under programmets körning. Stöd finns bland annat för att kombinera ordningar (och funktioner), vända ordningsföljd, tillåta nullvärden (och då definiera om de kommer före eller efter övriga värden). En användbar metod är sortedCopy(iterable) som returnerar en sorterad kopia av argumentet och max- och min-metoderna som returnerar det högsta respektive lägsta värdet eller värdena.

I exemplet nedan använder jag ordningar och funktioner för att avgöra vem som vunnit en auktion. Koden kan utläsas som att det högsta värdet hämtas genom att naturliga ordningen appliceras på resultatet av sammansättningen av två funktioner. Den ena funktionen skapad av Functions.forMap slår upp ett bud i mappningen givet en budgivare, den andra returnerar beloppet på detta bud.

Map<Bidder, Bid> auctionBids = ...;
Bidder highestBidder
  = Ordering.natural()
            .onResultOf(compose(BID_AMOUNT_FUNCTION,
                                forMap(auctionBids)))
            .max(auctionBids.keySet());

Paradigmen påminner mycket om den som används i funktionella språk och kan kräva en del övning innan den sitter i ryggmärgen. Fördelen är kod med låg komplexitet och hög uttrycksfullhet. Fundera gärna en stund vad som krävts för att göra motsvarande jobb utan Guavas hjälp i form av lokala variabler, loopar och if-satser...

Kampanj för verklig tid

2012-01-04T09:57:00.010+01:00

En svaghet i java är tid- och datumhantering. Både Date och Calendar är föränderliga och således inte trådsäkra. Det är dessutom inte särskilt intuitivt och tämligen krångligt att arbeta med de objekten om du jobbar med datum. Lösningen heter joda-time och finns på http://joda-time.sourceforge.net/

Här finns allt du behöver för att hantera datum och tid på ett enkelt sätt, utan att för den skull begränsa dina möjligeter. Med normalt användande så är det DateTime-objektet man använder. Det är oföränderligt (och således trådsäkert) och serialiseringsbart.

Det enkla är enkelt:

DateTime now = new DateTime();
DateTime inAnHour = now.plusHour(1);
DateTime someonesBirthday = DateTime.parse("2009-09-30T21:12");
DateTime thisDate2011 = now.withYear(2011);

Naturligtvis går det att lägga på andra tidszoner (eller köra utan) och även andra kalendersystem och lite annat godis som intervallhantering. Självklart kan du också skapa ett DateTime-objekt från ett Calendar- eller Date-objekt rakt av.

DateTime nowInKuwait
  = now.withChronology(IslamicChronology.getInstance());
DateTime now = new DateTime(new Date(System.currentTimeMillis()));

Det går också att få lokaliserade namn om du vill det:

String nameOfTodayDay
  = now.dayOfWeek().getAsText(Locale.getDefault());

Tyvärr är det fortfarande otroliga mängder legacy-kod som kräver Date eller Calendar, så det går inte att glömma dem helt. Men det är en bra ide att försöka!

Arbetsprov bästa verktyget vid rekrytering

2012-01-04T09:56:00.000+01:00

Jag har under mina snart åtta år hos min nuvarande arbetsgivare assisterat vid rekrytering av utvecklare. Ett av de viktigaste hjälpmedlen för mig har varit de arbetsprov kandidaterna får göra för att visa sina kunskaper i javaprogrammering. Provet är relativt enkelt och tar ungefär en arbetsdag att göra om man är van med teknikerna som behövs och ett par extra dagar annars. Något som har slagit mig är den otroliga variationen i kvalitet på de inlämnade svaren. En tung meritförteckning är inte på något sätt synonymt med goda resultat.

Jag har nyligen registrerat mig på Freelancer och noterar genast den stora mängden uppdrag som erbjuds av studenter, uppdrag där de vill ha hjälp att lösa lätta, på gränsen till triviala, programmeringsproblem. Det här tyder på ett ointresse att lära sig, vilket kommer att medföra i bästa fall en medioker prestation i yrkeslivet. Du vill inte vara den arbetsgivare som anställer en av dessa...

Att det skulle förhålla sig på detta sätt var för mig inte helt oväntat. Efter att ha rättat ett tjugotal arbetsprov kan jag avslöja att jag bedömt cirka 20% av dem som rena plagiat. Kandidaten har googlat, hittat liknande kod, kopierat den och tagit bort all dokumentation om ursprung, för att sedan göra några modifieringar och lämna in koden så som sin egen.

Samtidigt finns det en liten del av kandidaterna som är värda sin vikt i guld. Arbetsprovet brukar visa detta tydligt, och efter en diskussion om lösning med kandidaten kan man försäkra sig om att lösningen är hennes egen.

Detta visar vikten av att använda ett arbetsprov vid rekrytering. För dig som vill veta vem du anställer är arbetsprovet bästa verktyget!

Trevliga nyheter i Mockito 1.9

2012-01-02T15:49:00.001+01:00

Det har tillkommit en hel del behändig funktionalitet i senaste Mockito-släppet. En av dem är möjligheten att göra enradsattrapper:

Car boringStubbedCar 
    = when(mock(Car.class).shiftGear())
       .thenThrow(EngineNotStarted.class).getMock();

En annan är möjligheten att mycket enkelt göra djupa attrapper, vilket är särskilt användbart vid testning av existerande kod:

Foo mock = mock(Foo.class, RETURNS_DEEP_STUBS);
when(mock.getBar().getName()).thenReturn("deep");
assertEquals("deep", mock.getBar().getName());

Mockito är ett mycket användbart och väldesignat testramverk för att skapa attrapper. Mer information om Mockito hittar du på http://code.google.com/p/mockito/.

Kraftfulla enums

2012-01-01T15:54:00.000+01:00

Nyckelordet enum är i Java kraftfullare än vad man i första anblicken kan tro. Varje konstant är nämligen ett fullfjädrat objekt. Detta innebär att du kan skapa subklasser i uppräkningen av dina konstanter. Istället för att skriva switch-satser över uppräkningens konstanter så bör du ofta lägga till en metod i definitionen av uppräkningen istället. Koden nedan ersätter en separat fabrik och ev tillhörande gränssnitt. Dessutom riskerar du inte att missa något fall när du lägger till ytterligare en konstant. Vill du läsa mer om uppräkningar i Java rekommenderar jag kapitlet Enums and Annotations i Effective Java, Second Edition av Joshua Bloch.

public enum GameStateType 
{ 
    WAITING_FOR_PLAYERS { 
        public GameState createState(GameComponent component) { 
            return new WaitingForPlayers(component); 
        } 
    }, 
    SELECTING_DEALER { 
        public GameState createState(GameComponent component) { 
            return new SelectingDealer(component); 
        } 
    }, 
    PLAYING_TRICK { 
        public GameState createState(GameComponent component) { 
            return new PlayingTrick(component); 
        } 
    }, 
    DETERMINING_WINNER { 
        public GameState createState(GameComponent component) { 
            return new DeterminingWinner(component); 
        } 
    }, 
    GAME_FINISHED { 
        public GameState createState(GameComponent component) { 
            return new GameFinished(component); 
        } 
    }; 
 
    public abstract GameState createState(GameComponent component); 
}

Ny medbloggare

2012-01-01T11:59:00.000+01:00

Jag har glädjen att meddela att min vän och före detta kollega Tomaz anluter sig som författare till denna blog! Tillsammans har vi över tjugofem års erfarenhet av utveckling i java och har under en lång tid agerat sparringpartners i diskussioner om kod, design och problemlösning, både yrkesmässigt och privat. Nu kommer vi förhoppningsvis ta en del av dess diskussioner ut i etern. Välkommen ombord Tomaz!

Hastigt om kastning

2011-12-30T01:23:00.001+01:00

Jag lyckades med en juholtare för ett par dagar sedan. Jag stötte på en kodsnutt med följande särdrag:

int a = ...;
int b = ...;
double f = 1 - (double) a / b;

Lika snabbt som felaktigt drog jag slutsatsen att "det där kan ju inte fungera som tänkt eftersom division binder hårdare än kastningen till flyttal". Jag skickade några minuter senare ett mail till teamet om mitt fynd och undrade hur vi skulle gå vidare med detta. Senare samma dag slog det mig att jag kanske förhastat mig. Jag lade några minuter på att slå i Javas språkspecifikation och fann snart att kastningen kommer att utföras före divisionen. Pinsamt. Ytterst pinsamt.

Lärdom av detta är ju att jag borde ha friskat upp minnet genom att slå upp hur uttryck beräknas i språkspecifikationen eller skrivit ett test innan jag drog förhastade slutsatser. En annan, och kanske än viktigare erfarenhet, är att liknande uttryck bör skrivas med parenteser för att tydligt visa avsikten eller på ett sådant sätt att inget missförstånd kan uppstå:

double f = 1 - a / (double) b;

Har du inte ett eget referensexemplar av senaste språkspecifikationen kan du köpa den från amazon.co.uk eller läsa den online. I den finns alla sliskiga detaljer om hur språket är konstruerat och därmed ett måste för den sanna javanörden...

Språkval

2011-12-28T22:56:00.000+01:00

Bland oss utvecklare är det mycket vanligt att vi under samtal och i epost blandar svenska och engelska ord om vartannat. Många av de termer vi behöver är vi dessutom vana att se uteslutande i dess engelska skepnad. Jag upplever att språket ibland blir lidande av denna blandning. Att skriva på svenska är för mig effektivt, vilket är en förutsättning för bloggens fortlevnad. Jag kan vidare lättare uttrycka nyanser i svenskan och ha ett mer varierat och tilltalande språkbruk. Därför har jag valt att blogga i huvudsak på svenska. Detta är min ambition - naturligtvis kommer det slinka in en och annan engelsk term av slentrian eller för att jag inte finner ett svenskt alternativ. För att underlätta för er läsare har jag nu lagt upp en ordlista för de svenska termerna.

Reflektioner om reflection...

2011-12-28T14:16:00.000+01:00

Till att börja med vill jag berätta att jag sedan länge är en stor vän av reflection. Idag har dock mitt tålamod provats ordentligt just på grund av detta. Därav läge att samla mina tankar kring reflection och vad som krävs en tillämpning för vinna min uppskattning. Grundprincipen visar sig vara ganska enkel och dogmatisk: Inga strängar skola användas för att referera till identifierare i kod.

Detta eftersom en sträng som referens orsakar följande otyg:

Metoder kommer att markeras som oanvända och därmed sannolikt uppfattas som död kod och riskera att raderas av misstag.
Sökning på metodanvändning kommer inte heller att fungera, så det blir mycket svårare att exempelvis hitta var medlemmar anropas (till exempel för att sätta objektegenskaper).
Felstavningar fångas inte vid kompilering, och om det dessutom saknas rimlig felhantering så kan ett litet svårupptäckt stavfel göra att koden inte beter sig som förväntat.
Omarbetning av kod blir farlig då utvecklingsmiljön inte nödvändigtvis fångar strängreferenserna vid namnbyten etc.

Som ni förstår har jag precis sågat spring-injection vid fotknölarna. Och det står jag för. Motbevisa mig gärna.

Några exempel på reflection där jag tycker det är fantastiskt är testramverket Mockito som på ett mycket elegant sätt låter dig skapa attrapper att jobba med. I tillämpningar som JAXB (för att mappa javaobjekt till XML) fungerar det också bra. Vid några tillfällen har jag också funnit hjälpmetoder som dynamiskt jämför två objekt med avseende på likhet eller skapar en strängrepresentation vara värdefulla.

Att använda dynamiska ombud som hjälpmedel för att representera metodanrop är dessutom helt underbart och spar otroliga mängder kod samtidigt som läsbarheten ökar markant. Sen har jag en mängd egna tillämpningar som jag med all sannolikhet kommer visa upp här i bloggen vid senare tillfälle...