Tag: java

vilket_är_lättast_AttLäsaTyckerDu

Jag har skaffat mig en åsikt: det_är_lättare_att_läsa_vanlig_text_så_här, änAttLäsaDetNärDetStårSammanSkrivetUtanNågonWhiteSpace. De flesta känner till att vi mnäskionr kan lsäa ord unta srröte poerblm bara start- och slutbokstaven står på rätt plats. FrsöökGröaSmmaaSakMedDtetaTxbtelcok. Så, jag har skaffat mig åsikten att underscore är en bra idé att använda i t ex namn på test(metoder). I JavaScript brukar de flesta testramverk erbjuda följande mönster:

TestCase("Nu testar vi logiken i UserManager", {
    "lägga till en användare": function() {
        var before = this.userManger.getUserCount();
        this.userManager.addUser("Fredrik", "Wendt");
        var after = this.userManger.getUserCount();
        assertThat(after, equals(before + 1));
    }
});

Det är då ganska lätt att se vad som gått fel när en rapport säger:

In Suite "Nu testar vi logiken i UserManager", the test "lägga till en användare" failed.

I Java kan vi inte använda blanktecken som del av identifierare. I Java 7 kan man iaf använda 1_000_000 för att skriva ut en miljon, yay! Men det löser inte problemet med att få läsbara namn på test(metoderna). Understreck till räddning!

Ett problem som följer med understreck är att Eclipse rätt ur lådan inte stödjer att hoppa inom identifierare som innehåller just understreck: ctrl+höger hoppar alltså till slutet av hela identifieraren. Med AnyEditTools (finns på Eclipse Marketplace) blir detta problem ett minne blott, och man får också hjälp att konvertera mellan Camel Case och Underscores. Perfekt julklapp! :)

Typ-smocka med Mockito

Jag stötte på en riktig fuling idag när jag skulle skriva ett test likt det nedan. Hittade “lösningen” på mailinglistan efter att ha läst ett par buggar/feature requests.

Som jag förstår det går det inte att lösa pga Javas Type Inference i metodanrop. I exemplet nedan kan raden med when aldrig fungera utan man får gå på doReturn istället.

package demo;
 
import static java.util.Arrays.asList;
import static org.mockito.Mockito.doReturn;
import static org.mockito.Mockito.mock;
import static org.mockito.Mockito.when;
 
import java.util.Collection;
 
import org.junit.Test;
 
public class GenericCollectionStubTest {
 
    @Test
    public void onGoingStubFails() {
        Car bmw = mock(Car.class);
        Reseller reseller = mock(Reseller.class);
        Collection cars = asList(bmw);
 
        //when(reseller.getModels()).thenReturn(cars);
 
        doReturn(cars).when(reseller).getModels();
    }
}

Raden med when misslyckas med följande meddelande:

The method thenReturn(Collection<capture#1-of ? extends Vehicle>) in the type OngoingStubbing<Collection<capture#1-of ? extends Vehicle>> is not applicable for the arguments (Collection<capture#2-of ? extends Vehicle>)

Java störst under 2011 enligt Ohloh

I denna mätning, som baserar sig på de repositorier som Ohloh bevakar, är Java det mest committade språket. Vet inte om justering görs pga dess pratighet också? Mätvärdena är relativa (procent), hade varit kul att se om C-kodsbidrag faktiskt gått ner, eller om det bara är de andra som ökat (och därmed tar större del av kakan).

Data från Ohloh

Data från Ohloh

Scandev on Tour, Stockholm 2011

Jag var iväg på Scandev on tour i Stockholm och hade en bättre dag än väntat. Huvudattraktionen för mig att åka dit som deltagare var pga Gojko Adzic: jag ville se om han verkligen är så vattentät som han verkar!

Key Note, Bruce Eckel

Dagen började med kort introduktion av Emily Bache som lämnade över till Bruce Eckel. Han feluppskattade tyvärr sin tid och missade den stora poängen med sin presentation, vilket var väldigt synd. Oklart varför han missade så grovt då det enligt egen utsago var fjärde gången han höll denna presentation. I princip så pratade han om språk och vad nästa stora språk bör ha för egenskaper. Han petade flera gånger på brister i Python, Java och C++ (nämnde inte C# en enda gång enligt mina anteckningar). CoffeeScript med jQuery förekom i hans bilder mot slutet och dessutom i koden som presenterades.

Kul med en lite mer teknisk key note! Hans egna tavlor som bakgrundsbilder till presentationerna var möjligen gav dock emellanåt för kass kontrast mot texten. Hans budskap var helt OK men jag måste säga att presentationen i sig var rätt beige.

Ruby on Rails, Shay Friedman

Jag gick sedan till Shay Friedmans presentation om Ruby on Rails. Det var antligen den mest politiskt inkorrekta presentationen under dagen (konferensen saknar för övrigt code of conduct och/eller ett manifest). Med minsta marginal snublade han nog över på rätt sida gränsen till godtagbart.

Jag hade föredragit dubbla tempot och något som stack ut från “my first 5 minutes”-spåret, kanske kika lite under huven och få se något intressant. Shay använde dock 3.1 vilket är rykande färskt med SCSS och CoffeeScript medskeppat som “standard”. Klart inspirerande och skall jag bygga sidbaserad webb (eller måhända JSON-backend) så ligger detta varmt till hands. Stort minus för att han inte körde testen en enda gång … Det hade bland annat undvikit hans två felsteg: att försöka ladda applikationen innan databasen var uppdaterad.

WCF Future

Detta var fullständig slöseri med tid, tyvärr. “You might have heard of web sockets, it’s w3c standard …”

Visualize Quality, Gojko Adzic

Efter lunchen kom dagens höjdpunkt. Gojko Adzic började lite före utsatt tid med att fiska bland publiken (han kände väl till svenskars fåordighet som åhörare) kring vad folk förväntade sig för att så småningom komma igång och helt enkelt presentera ett ganska ofärdigt material med tankar kring vad kvalitet är.
Gojko menade att t ex code quality aldrig är oviktigt, men det är inte lika viktigt i förhållande till att ett system uppfyller ett eller flera affärsvärden. David Harvey föreslog att föredragets ämne borde varit “Visualize Value” vilket jag instämmer i.

Innehållet var i övrigt bra presenterat, väl underbyggt och genomtänkt (mannen är riktigt vattentät) och ämnet hade jag snarare sammanfattat såhär:

To remove stake holder’s need for visibility (they ask for control) we need undisputibale visualization (of metrics).

Han gav exempel på tre P:n som är traditionella kvalitetsmätpunkter: Process effectiveness (such as code quality); Product status; Product Performance (have we delivered something that is actually used by users?). Han gav också förslag på andra sätt att hitta och visualiser mätvärden: Low tech testing dashboard, Risk/Test heat maps and charts, effect maps, Attribute-component-capability charts.

Intressant, framför allt bra presenterat och det föreslagna lär – rätt genomfört – otvetydigt ge bra underlag för diskussion och insyn i den egna verksamhet.

Long Term Value of Acceptance Test, Gojko Adzic

Var egentligen skåpmat och handlade om att inte dokumentera flöden i test, utan att med hjälp av smart marknadsföring (för att få stake holders intresserade) genom specification workshops få till kör- och testbar dokumentation av affärsregler, dvs företagets verksamhet. Han pekade ut TextTest som ett bra verktyg som steg i rätt riktning – dvs separera dokumentationen (testet) från det som behövs för att göra det kör-/testbart (scriptet, systemstart etc). Presenterades på ett bra och oklanderligt sätt, rubricerades som Living documentation vilket tydligen skall vara accepterbar benämning även i biznizkretsar.

Verktygstips: Relish, Speclog och Concordion.

Code Debt, David Harvey

Jag åkte på att ställa upp som försökskanin och parprogrammerade fem rader JavaScript med David Harvey. (Egentligen tror jag att jag skrev kanske femton tecken pga ovana vid Mac+eng tangentbord men men :)

David visade i alla fall på ett konkret exempel av hur kod kan evolvera fram i två riktningar – en som är lätt att arbeta med (den jag fick utöka) och en som hade en mindre positiv utveckling (Jörgen Lundberg åkte på denna elakare version och gav kommentaren: Wow). Presentation var helt OK. Den kunde varit bättre genom att fokusera mer på konkreta tips och åtgärder (eller strategier) än att belysa problemet.

Akka, Jonas Bonér

Jonas visade på vad Akka erbjuder – lösningar på problemen concurrency, scalability och fault-tolerance (that self-heal). En av lösningarna på desa problem är Akkas Actor. Detta “mönster” presenterades, med – min min smak – lite för enkla exempel. Ping-pong och self.reply("Hi " + name) funkar visserligen bra – det är lätt att läsa på en vägg med stor text – men det ger alltid lite extra när presentatören visar produktionskod och tar exempel från verkligheten.
För att hantera del av clustringen används gossip (som ger eventual consistency).

Sammanfattningsvis

Allt i allt var den dag över förväntan. Folkets Hus var kanon som lokal och allt flöt på kanon med mat och annat. Jag saknar dock open space eller någon form av mer inbjudande deltagande – i Göteborg fanns 2010 fish bowl som gör eventet till lite mer än bara “an eyes forward event” (som Bruce Eckel själv använde som benämning i sin key note).

Java CMS-party i Göteborg

David Jensen och folket på Redpill Linpro i Göteborg ser till att ordna ett releaseparty (släppfest på svenska?) för version 4 av Javabaserade CMS-motorn Alfresco. Om du är sugen att haka på (torsdag 13 oktober kl 16) verkar det vara fritt fram via anmälan till en grupp på Meetup.

Alfresco Logo

Att välja rätt List-implementation

Jag har stött på tillfällen då man undrar vilken implementation av en kollektion, t ex java.util.List man bör välja. Ibland behöver man använda så lite minne som möjligt, ibland vara så snabb som möjligt, osv. Jag har oftast löst det med att skriva enhetstest och långkörarjobb som gör något om och om igen, så får det stå över natten och när man kommer tillbaka nästa dag undersöka resultat, loggar och JVM-data.

Skärmbild över statistik från körning med Caliper

Skärmbild över statistik från körning med Caliper

Idag hittade jag Caliper via  Jesse Wilssons bloginlägg om LinkedList vs ArrayList (ur kö-perspektiv). Den korta tråden av kommentarer visar dock på hur irrelevant enhetstestbaserade undersökningar kan vara (även om de kör över tid så att GC får arbeta). På en JVM sitter ofta många system och “delar” GC och minnesrymd.

Helt irrelevant finner jag det absolut inte – även om systemet under test inte beter sig som under skarp last så upplever jag att man kan få ökad förståelse om hur olika implementationer beter sig och ju mer delar man har av ett pussel – ju lättare är det att se hela bilden och dra rätt slutsatser.

Kata: Authentication Filter in Java EE

This is an exercise I’ve used to demonstrate how awkward unit testing can be if you can’t use a mocking framework. It’s an almost real work life situation (disclaimer: you should perhaps use container based authentication and JAAS) where we’re using API:s in a Java EE Server, adding two collaborators and then writing the logic combining it all.

No group has (yet) completed the entire task within 90 minutes – you might want to start/focus on using one collaborator only (I suggest the LDAP collaborator).

Originally posted on codingdojo.org.

When cleaning up a folder at work, I found this old document – it’s some form of a logical flow chart of the filter to write.

Here we go …

Background

In this Kata, your a programmer at ABC Corp and you’re making a new web app from scratch. After the head architect started working on this, it’s now up to you to make sure these tasks are completed:

  • allow authentication using request parameters
  • all authentication/login attempts should be verified agains LDAP
  • successful logins should be recorded in the single sign on registry

However, you’re not the only programmer (team) adressing this web app, so the LDAP is written by another team and what you have right now is this interface:

 public interface LdapAuthenticationGateway {
   boolean credentialsAreValid(String userName, String password);
 }

and the single sign on registry is also written by another team, leaving you with this interface:

 public interface SingleSignOnRegistry {
   boolean tokenIsValid(String token);
   String registerNewSession(String userName);
   void endSession(String token);
 }

Your job basically is to write one or more javax.servlet.Filter that handles incoming requests and act according to whether there’s a cookie with a SSO token, username+password parameters etc.

It’s assumed that there’s some form of DependencyInjection framework in place – to get a handle to the SingleSignOnRegistry or the LdapAuthenticationGateway, you’ll simply have to provide something like:

 public void setSingleSignOnRegistry(SingleSignOnRegistry registry) {
   ...
 }

About this kata

This “real life” scenario has been used to demonstrate how mocking (using Mockito) can be useful. We’ve combined it with BDD and JDojo@Gbg will try to practice TDD using this kata (without mocking) next time around.

(“Real life” is quoted – proper JEE authentication should be tied into the container etc etc … The point with this exercise is that it’s fairly easy to explain how it should work and what needs to be done here with “real” Java EE API:s, and then focus on the “How to develop” aspect (TDD), but also to show/talk about the difference between mocking and stubbing.)

JavaForum 2011Q2

Igår var det JavaForum 2011Q2 som denna gång hölls på Ullevi Konferenscenter – en lokal jag tyckte funkade mycket bra. Jag hade anmält mig som talare på ämnet Clean Code med förhoppning om att få till lite diskussion – det är ändå inget jättenytt eller kontroversiellt ämne.

Jag hade 30 minuter och använde 21 av dem till att agitera med presentationen nedan. Övriga 9 minuter höll jag tyst bäst jag kunde för att få lite diskussion och det gick – det var olika deltagare som ställde frågor och svarade. Ett par småskratt och målet med kvällen nåddes.

Kanske kommer någon in och betygar min prestation på Speakerrate?

Clean code
View more presentations from Fredrik Wendt

Finns också som PDF.

VNC-studsare

Jag hade för fem år sedan en egenskriven blogg. Sedan åt jag upp databasen. På den fanns iaf instruktioner för hur man lätt kunde sätta upp VNC på windows så att man kan hjälpa en människa i nöd.

Eftersom både jag och t ex min far befinner oss bakom en NAT/router så är det inte helt rättframt. För att lösa detta satte jag upp en VNC-studsare – en bit Java som knöt ihop två TCP-koppel. Idag skulle vi behövt detta. Eftersom jag inte hittade det så skrev jag ihop det på nytt.

De övergripande instruktionerna är att servern (den som behöver hjälp) ansluter med “reverse” (x11vnc -connect host:port) och klient (den som ger hjälp) till samma port på studsservern.

Mer detaljerade Windows-instruktioner får vänta tills nästa gång.

Studsserver

Kör VncBouncern. Den skriver ut porten som används.

Linux

Lite kommandon:

x11vnc -connect localhost:`netstat -lnp | grep java |tr ':' ' ' | tr -s ' ' | cut -d ' ' -f 4`
vncviewer 192.168.1.157:`netstat -lnp | grep java |tr ':' ' ' | tr -s ' ' | cut -d ' ' -f 4`-encodings "copyrect hextile corre rre"

Bakgrunden till -encodings är att när man ansluter till sin egen maskin för att testa så säger vncviewern “Same machine: preferring raw encoding”, och det går apslött.

Ämnen för Java-TDD

Tittar på att gå ett steg längre med TDD-workshops och lämna de grundläggande ämnena. Följande har efterfrågats:

  • testning med/av legacy code
  • vad är bra respektive dåliga test
  • funktionell eller acceptansdriven testning (ATDD)
  • beteende driven utveckling (BDD)

Egna saker jag själv skulle vilja gräva lite mer i och ägna ett par timmar åt:

  • hamcrest (matchers)
  • dotmesh (methods)
  • making EasyMock suck less
  • making Mockito suck
  • easyB
  • Fitnesse

I allmänhet så saknar jag en diskussion om hur lättredigerade test (wiki?) versionshanteras ihop med koden de testar eller är skrivna mot. Detta är ju högst intressant när man går in och gör en hot-fix för en produkt som rört sig mycket under ett år, och en kund som har produkten i drift sedan ett drygt år tillbaka vill sin fix. Hur kör man samma testsvit som man hade för ett år sedan på ett enkelt sätt? Hur är egentligen inte svårt. Jag har bara inte sett många bra lösningar, ännu. TextTest, xUseCase och liknande plain text-ramverk är en bra lösning. Frågan är bara om testen är tillräckligt tillgängliga för ATDD – hur får man kunden att känna att det är hans/hennes test?