1. Fredrik Wendt

    Fredrik är född i Skövde men har jobbat med systemutveckling i Göteborg sedan sommaren 2000. Han ogillar beskrivningen "han jobbar med datorer" - intresset och fokuset är att allt han utvecklar är till för att förbättra, förenkla eller bara underlätta för människor. Fredrik intresserar sig därför inte bara för UX och HCI, utan även för metodik och processer och förespråkar lättviktiga processer när det handlar om utveckling. Fredrik är Certified Scrum Master och har huvudsak jobbat i "agila" projekt sedan 2005.

Fredrik Wendt har bl a skrivit följande inlägg på jsolutions.se.

  1. Helios Eclipse på 5 sekunder

    Läste via The Tired Architect följande citat:

    I tested the Helios Eclipse Java development package on my desktop computer, which is running Ubuntu 10.04 and has a six-core i7 980X. The new version of Eclipse takes roughly five seconds to start up on this system and uses several hundred megabytes when idle.

    I mina ögon intressant:

    • ny version av Eclipse ute, bara att tanka hem
    • five seconds – fem, verkligen fem? Eller är det tills han får upp splash-bilden? :)
    • desktop computer – varför skilja på desktop och laptop (enda skälet som jag ser det är att det är enklare att köra tre skärmar från en stationär än en laptop)
    • several hundred megabytes – minne är fortfarande kung
    Eclipse Helios Is Here

    Eclipse Helios Is Here

  2. Optimera Stockholm

    FS-data såg till att jsolutions.se var nere ett par dagar (inte första gången) så jag plitade ner mina anteckningar (på min egen blog) från .SE:s heldag om webboptimering, kallad Optimera Stockholm.

    Tänkte bara komplettera med att videos och presentationer nu lagts ut. Trimlabb höll en presentation om webbplatsoptimering som budskaps- och innehållmässigt var väldigt väldigt likt det jag presenterade på dotNetForum och JavaForum i februari – rekomenderas varmt alltså ;)

  3. final new static mock

    Jag måste säga det – Mockito smakar väldigt bra. Tidigare använde jag EasyMock och jMock och idag läste jag mig in på JMockit, som skriver:

    Design considerations for production code

    The problem with imposing restrictions on the design of production code is that there are good reasons for making classes final, for directly obtaining instances of collaborators with the new operator, and for using APIs based on static methods. There is nothing inherently wrong with using these three Java language keywords, after all.

    Fine. Jag kan köpa det. Men sedan går man vidare och säger

    The JMockit mocking API is simple, consistent, and minimal.

    Nu börjar det bli jobbigt att hålla med :) Låt oss ta deras exempelkod:

       public void testDoOperationAbc(final DependencyXyz mock)
       {
          new NonStrictExpectations()
          {
             AnotherDependency anotherMock;
    
             { anotherMock.doSomething("test"); result = 123; }
          };
    
          new ServiceAbc().doOperation("some data");
    
          new Verifications()
          {{
             mock.complexOperation(true, anyInt, null); times = 1;
          }};
       }

    och så jämför vi med samma sak i Mockito:

        public void testDoOperationAbc(final DependencyXYZ mock) {
            when(anotherMock.doSomething("test")).thenReturn(123);
            new ServiceAbc().doOperation("some data");
            verify(mock.complexOperation(eq(true), anyInt(), eq(null)));
        }

    eller BDD-style:

        public void doOperationCallsComplexOperation(final DependencyXYZ mock) {
            // GIVEN
            given(anotherMock.doSomething("test")).willReturn(123);
    
            // WHEN
            new ServiceAbc().doOperation("some data");
    
            // THEN
            verify(mock.complexOperation(eq(true), anyInt(), eq(null)));
        }

    I min värld är Mockito det mockningsramverk som är minst i vägen. För nyskriven kod vet jag vad mitt val faller på. Det är inte lika ”komplett” eller kraftfullt som andra ramverk, men så är det också inte i vägen. Måste man prompt använda final och static eller mocka privata metoder kan PowerMock hjälpa till.

  4. Bra verktyg för dåliga test?

    Jag sprang idag över denna demo av SpryTest – ett verktyg med vilket man kan få hjälp att skriva test som masserar legacy code (dvs kod som inte täcks av test). Nej, jag ser verkligen inte detta som en silver bullet och är tveksam till att använda det över huvud taget.

    (Läs mer…)

  5. Kort om FOSDEM10

    FOSDEM är stort. Mängder med folk trängs på en liten yta och varannan människa är expert på XMPP, PosgreSQL, SIP, Gnome, Mozillas byggmiljö, hur dålig Javas type inference är … Här kommer halvt uppstädade anteckningar, i väntat på att presentationerna läggs ut.

    Groovy

    Luca höll en väldigt enkel introduktion till Groovy (med tanke på den extremt kunniga publiken i Free Java-rummet). Min behållning var att se hur Groovys closure syntax ser ut, t ex såhär:

    alist = ['hej','på','dej']
    alist.sort{ element ->
     element[-1]
    }
    // sorterar på sista bokstaven i varje element
    // (en sträng hanteras som en lista av tecken, precis som i Python t ex)
    
    20.times { attr ->
     println("This is iteration ${attr}")
    }
    // man verkar använda särskilda metoder som tar closure som argument
    
    alist = alist.collect{ el ->
     el + "\o/"
    }
    // finns grep också
    println al

    Efterföljande presentation i samma rum (Free Java) började med att säga ”So, I know a way to make Groovy closures work at least 20 times faster” :)

    Lamba + JSR 292

    Genast åkte kompetensnivån upp i taket – precis som tidigare år. Har man inte koll på hur JVM:en egentligen fungerar (eller iaf har läst Java Lang Specen), och kan läsa det jad eller annan dekompilator spottar ur sig så börjar man känna sig utanför. Inte pga tonen mellan folk (Javafolk är i allmänhet tvärtom väldigt trevliga och ödmjuka), utan helt enkelt pga att det är på den nivån som många argumenten ligger (om inte rent av de flesta).

    Remi gick iaf igenom förslagen för hur lambda kan komma att implementeras, både vad gäller syntax, scope-frågan och även hur det skulle kunna implementeras i språket.

  6. WikiMedia får ett lyft – äntligen

    All heder åt wikis, men varför finns ingen wiki som hängt med i web 2.0-teknikväxlingen? Nu har äntligen både WikiMedia (motorn) och WikiPedia fått sig ett litet lyft men jag saknar ännu den wiki där man gränslöst växlar mellan läsnings- och redigeringsläge. På en företagswiki är man troligtvis i 90 % av tiden ute efter att läsa. Att göra småjusteringare (fixa sökvägar, typos, lägga till en länk till något närbesläktat) borde verkligen inte kräva att man skall lära sig en ny syntax, vänta på att sidan laddar om, välja preview, och sedan spara sidan – cykeln är helt enkelt för lång och för mycket ”i vägen”.

    (Läs mer…)

  7. Borde Flash överges?

    IE6 har äntligen gått i graven, amen! (Tas till och med upp i Tech Radar från Thoughworks!) Hur är det då med Flash?

    Nu när vi har HTML5, video, canvas, geoloc, animationer och kraftfullt CSS (även om det borde vara mer objektorienterat som tidigare diskuterat av bl a Nicole Sullivan) kan man fråga sig om Flash kommer överleva, eller kanske varför det skulle få stanna kvar. Steve Jobs bloggar sällan men har i 1700 ord gett sig på Adobes Flash och han hävdar att deras sandbox är ett problem (läs Techcrunchs sammanfattning)

    Jag gissar att det är just pga denna sandbox som Flash inte kommer dö ut. Tänk bara all reklam som cirkulerar på världens webb. Vem vill släppa lös ett JavaScript-monster som petar på hela DOMen och springer runt och skräpar ner på sin sida, bara för att man vill tjäna pengar genom reklam? Jag gissar att reklamfinansierad media älskar Flash pga att det kommer i någon form av sandlåda som är begränsad till de pixlar de får.

  8. Tiobe höjer C över Java

    För första gången på fyra år är inte längre Java det mest populära språket på Tiobes popularitetslista. Överst på tronen står åter C som tog ett ganska stort kliv framåt – själv väntade jag mig att det berodde på alla dynamiska språk som jag tycker ökar i popularitet och faktiskt användande.

  9. Thread.sleep gör stor skillnad

    Jag har varit uppe alldeles för sent många nätter i mitt liv (min mamma kan intyga detta). På senare år har jag dock sett till att bara acceptera och utnyttja de timmar under vilka jag verkligen upplever en kreativ boost, för att sedan tvinga mig till sömns på olika sätt. Orsaken är att jag helt enkelt inte känt att jag presterat på normal nivå dagen efter.

    En undersökning från 2003 bekräftar detta och sammanfattar:

    Conclusions: Since chronic restriction of sleep to 6 h or less per night produced cognitive performance deficits equivalent to up to 2 nights of total sleep deprivation, it appears that even relatively moderate sleep restriction can seriously impair waking neurobehavioral functions in healthy adults. Sleepiness ratings suggest that subjects were largely unaware of these increasing cognitive deficits, which may explain why the impact of chronic sleep restriction on waking cognitive functions is often assumed to be benign.

    Jag använder zenity och cron enligt följande:

    # m h  dom mon dow   command
    */10  21    * * 0-4 /home/ceda/bin/go-to-bed.sh
    */5   22-23 * * 0-4 /home/ceda/bin/go-to-bed-late.sh
    
    #!/bin/sh
    DISPLAY=`w | egrep "ceda.*x-sess" | tr -s ' ' | cut -d ' ' -f 3`
    if test -n "$DISPLAY" ; then
    /usr/bin/zenity --display $DISPLAY --info --text="Det e dags att dricka upp ditt te och sova nu!"
    fi
    

    go-to-bed-late.sh ser likadan ut fast använder en mindre vänlig formulering i dialogrutan. :)

    PS. zenity stödjer bara ASCII-tecken. DS

  10. När ska man mocka?

    Där jag jobbar nu mockar jag ungefär en gång i veckan. Nästa vecka kör vi vårens fjärde möte i JDojo@Gbg och temat för denna gång är just mockning. Vi kommer använda Mockito som jag tycker är mer lättanvänt verktyg än t ex EasyMock. En fråga som alltid dyker upp efter att man petat lite på ämnet brukar vara ”Vad är skillnaden mellan en stub och en mock?” I Mocks Aren’t Stubs har Fowler summerat det ganska bra tycker jag:

    • Dummy objects are passed around but never actually used. Usually they are just used to fill parameter lists.
    • Fake objects actually have working implementations, but usually take some shortcut which makes them not suitable for production (an in memory database is a good example).
    • Stubs provide canned answers to calls made during the test, usually not responding at all to anything outside what’s programmed in for the test. Stubs may also record information about calls, such as an email gateway stub that remembers the messages it ’sent’, or maybe only how many messages it ’sent’.
    • Mocks are [...] objects pre-programmed with expectations which form a specification of the calls they are expected to receive.

    Mockist Approach vs Stubborn Approach

    Detta är ett känsligt ämne – att påstå något om något som någon identifierar sitt arbete med. Jag brukar hävda att med stubborn approach (dvs när man bygger stubs eller fakes för sina collaborators/samarbetsklasser) så tenderar man att tappa fokus när man flyttar sin testverksamhet mellan olika klasser. Att använda en Mockist Approach (dvs när man mockar samarbetsklasserna runt sin ”enhet under test”) skulle på så sätt kunna hjälpa till att bibehålla fokus på den klass man utvecklar.

    Detta påstående brukar väcka lagom mycket anstöt för att få igång en givande konstruktiv diskussion där erfarenheter delas mellan debatörrer. Vad betyder det t ex när ett test med ett mockat beteende fallerar, jämfört med att använda en stub som kanske kan vara den verkliga (enda) implementationen?

  11. On top putting

    Jag vet inte vem som gör översättningarna åt Google, men det brukar leta sig in ganska grava/roliga fel emellanåt. Grava i meningen att de missar att kommunicera själva konceptet. Idag såg jag ett nytt exempel på detta i Google Calendar. Jag kollade inställningarna för mina kalendrar, och mer specifikt – de som jag prenumererar på. Rubriken över dessa, dvs andra kalendrar, löd: ”Kalendrar som bara jag kan visa”. Den riktiga översättningen borde vara i stil med ”Kalendrar jag endast/bara kan se/läsa [men inte skriva eller ändra i]”.

    Endast läsa

    Only View - Endast läsa

    Ett annat sådant exempel är Google Books där man kan välja att se en virtuell hylla i sitt bibliotek, antingen som en lista, Listvy (List view), eller som framsidor, Täckt vy (Cover view). Borde givetvis ha varit Omslagsvy eller motsvarande.

    Cover View - Täckt vy

    Cover View - Täckt vy

  12. Fler committers

    I London har precis eventet ”Graduate Open Source Jumpstart London 2010” avslutats. IBM bjöd in ett antal öppen källkodsprojekt att hjälpa intresserade komma igång att bidra. Tanken är att varje ”graduate” vid slutet av dagen skall ha bidragit konkret till det projekt de deltagit i, t ex genom att ha fått committa kod, skriva use case, förbättra dokumentation eller bara rapportera buggar. Målet är att få dem alla att känna att de kommit igång och kan fortsätta bidra på egen hand nästa dag, och dagen efter det osv.

    (Läs mer…)

  13. Delta i undersökning om effektivitet inom testning

    CITCON-listan är mottagare denna gång av en inbjudan från Tanjila Kanij vid Swinburne University of Technology, där man ber om deltagande genom en webbenkät som skall ta knappt 25 minuter att fylla i.

    ”[we are] conducting a survey to find out the key factors that influence the performance of software testers”

    Om du känner dig träffad (eller känner någon som borde känna sig träffad) så är URL:en till webbenkäten http://benambra.org/survey/

  14. Apropå bananens böj

    Mistaeks I Hav Made skriver intressant om Make It Easy som jag ännu inte hunnit få användning för, men som ser ut att ha viss potential:

    To create a builder (or ”maker” in the framework’s lingo) that can be used multiple times:

    Maker<Banana> anIllegallyCurvedBananaWithinTheEU =
        a(Banana, with(curve, 45.0));
    Banana naughtyBanana = make(anIllegallyCurvedBananaWithinTheEU);

    To define makers in terms of other makers:

    Maker<Banana> aBananaThatCanBeUsedInTheManufactureOfSmoothies =
        anIllegallyCurvedBananaWithinTheEU.but(with(ripeness,1.0));
  15. JavaScript User Group i Göteborg snart?

    Efter presentationerna av JSConf i december och tisdagens och onsdagens dotnet- och Javaforum (där jag gav introduktion till webboptimering) har det hoppat fram personer ur sina vrår och frågat mig om det blev något av den där JavaScript User Group-idén jag skrev om för ett tag sedan.

    (Läs mer…)

Nästa sida